시스템이 디스크 정렬 불량으로 인해 부정적인 영향을 받는지 알 수 있는 방법이 있는지 알아내려고 노력 중입니다. 즉, 디스크 I/O 작업을 수행할 때 실제로 백엔드 스토리지에서 추가 블록을 요청해야 합니다(우리는 SAN을 사용하고 있습니다). ) 요청된 데이터 블록이 실제로 실제 디스크의 여러 블록에 상주하기 때문입니다.
이 문제는 디스크가 추상화되어 잘못된 섹터 오프셋으로 인해 블록이 정렬되지 않아 가상 머신에서 백엔드 스토리지에 액세스할 때 추가 IOPS가 사용되기 때문에 가상 머신에 더 큰 영향을 미치는 것으로 알려져 있습니다.
어쨌든 iostat 출력을 살펴보니 거기에 있는 데이터가 나에게 단서를 줄 수도 있을 것 같지만 추론이 느린 것 같습니다. iostat(또는 다른 것)에서 머신이 더 최적의 디스크 I/O를 수행할 수 있다는 단서가 있습니까?
(디스크 정렬이 조사/걱정할 가치가 있다고 확신하지는 않지만, 이 문제에 대한 의견을 듣고 싶습니다!)
답변1
과거에는 디스크 정렬이 상당히 간단한 문제였습니다. 모든 트랙에는 동일한 크기의 동일한 수의 섹터가 있습니다. 최신 고밀도 드라이브는 트랙당 서로 다른 수의 섹터를 사용하여 플래터에서 거의 동일한 비트 밀도를 유지합니다. 여전히 이전 실린더, 트랙 및 섹터 크기 정보를 보고합니다. 실제 섹터 구조는 디스크의 쓰기 위치에 따라 다릅니다.
실제 주소 지정은 일반적으로 LBA(Logical Block Addressing) 형식으로 수행됩니다. 그리고 실제로 디스크 기하학에 관심이 없습니다. 분할 I/O는 디스크 제어 소프트웨어로 수행될 수 있습니다. 예상하지 못한 위치와 예상하지 못한 위치에서 분리된 I/O가 발생할 수 있습니다.
이러한 디스크를 SAN에 넣고 공유하면 기하학은 다른 기하학 레이어 뒤에 숨겨집니다. 그 시점에서는 어떤 I/O가 언제 분할되었는지 추측하려고 시도하지도 않았습니다. 저는 데이터를 4Kb에서 4Mb 사이의 2제곱으로 스트라이프할 수 있는 SAN 보기에 더 관심이 있습니다. 이러한 경계의 I/O는 디스크 전체에 걸쳐 분할됩니다. SAN 관리자가 SAN 할당 크기를 알려줄 수 있어야 합니다. 할당 크기가 더 작은 경우 파티션 및 블록 크기를 SAN의 크기와 일치하게 유지하는 것이 더 유리할 수 있습니다.
sar나는 보통 디스크 I/O에 문제가 있는지 확인하기 위해 출력을 살펴봅니다 . I/O 문제가 발생하면 평균 대기열 크기와 서비스 시간이 증가하는 것을 볼 수 있습니다. 이 시점에서 I/O가 왜 문제인지 조사해야 합니다. SAN을 사용하면 이러한 일이 여러 곳에서 발생할 수 있습니다. 여러 가지 솔루션이 있습니다. 가상 머신의 경우 각 머신마다 별도의 SAN 디스크를 사용하는 경향이 있습니다. 이는 VMDK와 같은 파일 형식의 가상 디스크 중 하나가 아닌 원시 디스크로 가상 머신에 할당될 수 있습니다.