공유 스토리지 큐가 여러 홈 서버 VM의 속도를 느리게 하는 이유는 무엇인가요?

공유 저장소 큐는 여러 홈 서버 VM을 느리게 만듭니다. 독립적인 가상 디스크가 결국 동일한 호스트 어댑터, 컨트롤러, 네트워크 경로, 물리적 드라이브에 요청을 제출하기 때문입니다. 각 VM은 자체 가상 큐를 가질 수 있지만 여전히 하위 공유 계층에서 다른 VM이 생성한 작업 뒤에서 대기할 수 있습니다.

따라서 지연은 단지 한 VM의 IOPS만으로 결정되지 않습니다. 요청 크기, 읽기/쓰기 비율, 동기화 동작, 큐 깊이, 저장 매체, 그리고 모든 인접 VM의 버스트 타이밍이 하나의 물리적 서비스 순서와 유한한 지연 예산으로 결합됩니다.

별도의 VM 큐는 어디서 공유 큐가 되나요?

각 게스트는 가상 컨트롤러를 통해 I/O를 제출하지만 VM 요청은 게스트 경계 아래의 공유 물리 자원에 집중됩니다. 하이퍼바이저, 호스트 파일시스템, 저장소 어댑터, 백업 장치는 여러 가상 디스크의 작업을 병합합니다.

VM은 내부 큐가 짧다고 보고할 수 있지만, 요청은 게스트가 볼 수 없는 호스트 또는 장치 큐에서 대기 중일 수 있습니다. 이 때문에 게스트 디스크 사용률만으로는 긴 애플리케이션 지연 시간을 설명하지 못할 수 있습니다.

전체 경로가 중요합니다: 게스트 스케줄러, 가상 컨트롤러, 호스트 큐, 네트워크 저장소 프로토콜, RAID 컨트롤러, 물리적 미디어가 각각 대기를 추가할 수 있습니다. 가장 좁고 포화된 계층이 공유 한계가 됩니다.

어떻게 한 VM이 저장소 소음 이웃이 되나요?

공유 인프라에서는 하나의 워크로드가 저장소 큐를 독점하여 조용한 워크로드의 지연 시간을 증가시킬 수 있습니다. 백업, 데이터베이스 압축, 업데이트 또는 대용량 파일 스캔이 이러한 버스트를 생성할 수 있습니다.

소음이 심한 VM은 가상 디스크 크기나 CPU 할당량을 초과할 필요가 없습니다. 저장소가 요청을 완료하는 것보다 빠르게 공유 서비스 경로를 점유할 만큼 충분한 미결 I/O를 발행하기만 하면 됩니다.

인접한 VM들은 평균 처리량 요구가 적더라도 꼬리 지연 시간이 증가할 수 있습니다. 미디어 VM이 스캔하거나 대량으로 쓰기 작업을 수행할 때 DNS 서버, 홈 자동화 데이터베이스 또는 인증 서비스가 느리게 느껴질 수 있습니다.

큐 깊이가 대기 상태로 전환되는 시점은 언제인가요?

일부 대기 중인 I/O는 유용한 저장소를 바쁘게 유지하기 때문에 필요하지만, 깊은 큐는 저장소 병목 현상을 나타냅니다. 장치의 유용한 병렬성을 넘어서면, 추가 요청은 완료된 작업 비율을 증가시키는 대신 체류 시간을 늘립니다.

큐 깊이는 한 계층에서의 개수이며 VM의 보편적 속성이 아닙니다. 게스트 깊이 8, 호스트 어댑터 깊이 수백, NVMe 하드웨어 큐는 서로 다른 위치이며 서로 다른 한계를 가집니다.

큐 깊이는 포화 후 지연 시간을 증가시킵니다. 처리량은 높게 유지될 수 있지만, 대기 중인 VM 요청은 동일한 지속 스트림 뒤에서 더 오래 기다릴 수 있습니다.

왜 큐 아키텍처가 VM 확장에 영향을 줄까요?

기존 경로는 많은 작업을 적은 명령 라인으로 강제할 수 있지만, 단일 큐 저장소는 더 많은 작업을 직렬화합니다. 여러 VM은 요청이 동시에 도착하기 때문에 이러한 아키텍처 차이를 증폭시킵니다.

병렬 큐는 잠금 경쟁을 줄이고 서로 다른 CPU 코어가 작업을 덜 직렬화하여 제출하고 완료할 수 있게 합니다. 하지만 무제한 저장소 성능을 만들지는 않으며, 컨트롤러, 네트워크, NAND 또는 디스크가 여전히 물리적 한계를 부과합니다.

따라서 프로토콜과 드라이버 경로가 시스템이 포화 상태에 도달하는 방식을 좌우합니다. 더 병렬적인 경로는 처리량을 유지하고 CPU 오버헤드를 줄일 수 있지만, 오래된 경로는 더 빨리 하나의 지배적인 큐를 형성할 수 있습니다.

왜 HDD와 NVMe는 다르게 반응할까요?

플래시와 NVMe는 NVMe가 더 많은 병렬 명령을 지원할 수 있는 반면, HDD 액추에이터는 여전히 주로 기계적 움직임을 통해 물리적 위치를 서비스합니다.

여러 개의 VM이 개별적으로 순차적인 작업 부하를 무작위 물리적 패턴으로 바꿀 수 있습니다. HDD에서는 교차된 요청이 탐색 및 회전 지연을 증가시키고, SSD에서는 동일한 동시성이 내부 컨트롤러나 NAND가 포화될 때까지 활용도를 향상시킬 수 있습니다.

더 빠른 매체는 서비스 시간을 줄이지만 큐잉을 없애지 못합니다. 동기 쓰기, 가비지 컬렉션, RAID 작업, 네트워크 지연, 몇몇 큰 요청은 여전히 작은 지연 민감 작업을 지연시킬 수 있습니다.

QoS와 작업 부하 분리가 간섭을 줄이는 방법은 무엇인가요?

가장 강력한 제어는 한 VM이 생성할 수 있는 공유 작업량을 제한하는 것입니다. 작업 부하 격리는 지연에 민감한 서비스에 별도의 자원 경계를 제공하여 테넌트 간 경쟁을 방지합니다.

홈 서버에서는 VM별 IOPS 제한, 우선순위, 별도의 가상 디스크, 데이터베이스 전용 SSD 풀, 또는 대화형 시간이 아닌 시간에 백업 및 스캔 스케줄링을 의미할 수 있습니다.

호스트 수준 지연과 큐 점유율을 VM별 지표와 함께 측정하세요. 공정성 제어는 바쁜 VM의 최대 처리량을 줄일 수 있지만, 한 배치 작업이 모든 서비스의 응답 시간 예산을 소비하는 것을 막습니다.

자주 묻는 질문

각 VM마다 자체 저장소 큐가 있나요?

가상 큐를 가질 수 있지만, 결국 그 큐들은 공유 호스트, 어댑터, 컨트롤러, 물리 장치 큐로 합쳐집니다.

한 백업 VM이 관련 없는 데이터베이스 VM을 느리게 할 수 있나요?

네. 지속적인 백업은 공유 큐를 채우고 디스크 대역폭을 소비하여 CPU와 메모리가 사용 가능해도 데이터베이스 VM의 지연을 증가시킬 수 있습니다.

더 높은 큐 깊이가 항상 나쁜가요?

아니요. 어느 정도 깊이는 병렬성을 드러내고 처리량을 높이지만, 미처리 작업이 유용한 병렬 용량을 초과하고 요청이 주로 대기 시간에 소비될 때 해로워집니다.

NVMe가 이웃 간 저장소 문제를 없애나요?

아니요. NVMe는 더 많은 병렬 큐와 낮은 서비스 시간을 제공하지만, 유한한 NAND, 컨트롤러, CPU, RAID, 네트워크 자원은 여전히 포화될 수 있습니다.

최종 요약

여러 홈 서버 VM이 독립적인 가상 디스크를 보인다고 해서 독립적인 물리 디스크를 소유하는 것은 아닙니다. 이들의 요청은 공유 큐로 합쳐지며, 이로 인해 버스트, 혼합 액세스 패턴, 제한된 장치 병렬성 때문에 이웃 간 지연이 발생합니다. 큐 인식 모니터링, VM별 제한, 스케줄링, 별도의 저장소 계층을 통해 공유 용량을 유용하게 만들면서도 한 VM이 모든 애플리케이션의 응답 시간을 제어하지 못하게 합니다.