클라우드 모범 사례는 서버에 여러 디스크(볼륨)를 계속 보유하는 것입니까?

Question

에서옛날물리적 서버의 경우, 아무리 간단한 응용 프로그램이 호스팅되더라도 서버에 항상 최소 두 개의 디스크(볼륨)가 있는 것이 좋습니다(적어도 제가 일했던 장소에서는).

하나는 운영 체제(OS)용 디스크이고 다른 하나는 애플리케이션용 디스크입니다. 여기에는 여러 가지 이유가 있었습니다.

1. 응용 프로그램이 디스크를 채우거나 I/O로 망치는 방식으로 디스크를 종료한 경우에도 일반적으로 로그온하여 무슨 일이 일어나고 있는지 확인할 수 있으며 OS는 무슨 일이 일어났는지 알려주기 위해 이벤트를 계속 기록할 수 있습니다.
2. 단일 볼륨에서 사용 가능한 I/O를 놓고 경쟁하여 애플리케이션 성능에 영향을 미치는 OS를 중지했습니다.
3. 백업/복원은 OS를 재구축할 수 있으므로 애플리케이션 디스크만 걱정하면 됩니다.
4. 애플리케이션 디스크는 OS에 영향을 미치지 않으므로 관리(예: 마운트 해제)할 수 있습니다.

기본적으로 클라우드 서버에는 디스크가 하나만 있습니다. 이 다중 디스크 접근 방식이 클라우드에서 여전히 의미가 있는지 생각하게 된 이유는 무엇입니까? 위의 사항을 고려하면 (1), (3) 및 (4)는 여전히 적용될 수 있지만 (2) 디스크가 가상이므로 클라우드 공급업체가 내가 볼 수 없는 방식으로 관리하는 스토리지 하위 시스템에 매핑되므로 적용 가능성은 낮습니다.

그렇다면 이 모범 사례는 클라우드에서 여전히 따를 가치가 있는 것으로 보입니까?

아니면 클라우드 환경에서 여러 볼륨을 사용하는 것이 그다지 중요하지 않은 이유를 놓쳤습니까?

Answer 1

컴퓨터를 서비스로 임대한다고 해서 별도의 데이터 디스크를 사용하려는 결정이 크게 바뀌지는 않습니다.

물론 기본값을 변경할 수 있습니다. 인스턴스에 추가 디스크를 생성하고 추가하기 위해 API가 존재하는 이유는 무엇입니까?

하나의 디스크는 관리하기가 더 간단합니다. 특히 인스턴스가 OS 및 애플리케이션 설치인 상대적으로 정적인 이미지의 경우 동적 데이터가 많지 않습니다.

파일 시스템이 가득 차는 것을 방지하는 것은 여전히 ​​유용합니다. 여러 물리적 디스크 이외의 솔루션도 가능합니다. LVM으로 논리 볼륨을 분리합니다. 또는 일부 인스턴스의 데이터 파일이 증가하지 않도록 중앙 집중식 로깅 또는 메시징을 수행할 수도 있습니다.

IOPS 및 크기에 대한 할당량을 초과하면 여러 디스크를 논리 볼륨으로 결합해야 할 수도 있습니다. (물리적 배열이 여전히 수수께끼로 남아 있더라도 적어도 할당량은 클라우드에서 잘 정의되는 경향이 있습니다.) 스케일 업 데이터베이스가 존재합니다.

별도의 데이터 볼륨을 사용하면 일부 블록 수준 트릭을 사용할 수 있습니다. 데이터베이스 인스턴스에 대한 주요 OS 업그레이드가 있지만 복제할 보조 스토리지가 없다고 가정해 보세요. 업그레이드된 인스턴스를 준비하지만 데이터는 없습니다. 가동 중지 시간 동안 데이터 볼륨을 분리 및 분리하고 이를 새 인스턴스에 제공한 후 마운트합니다. 빠른 업그레이드, 데이터 복사 없음, 볼륨의 두 번째 복사본 없음.