SQL Server 가상화와 관련하여 여기에서 수행 한 것과 유사한 방식으로 로그 장치에서 다른 반 가상화 SCSI (PVSCSI) 어댑터로 데이터 장치를 분리하는 데 긍정적 인 성능 영향이 있는지에 대한 정보를 찾으려고 노력했습니다 .
클라이언트에 추가 PVSCSI가 추가되고 로그 장치가 새로운 PVSCSI로 분리되어 상당한 성능 향상을 보여주는 시나리오가있었습니다. 그러나이 분리로 인한 것인지 아니면 단순히 추가 PVSCSI가 존재했기 때문에 의문이 남아 있습니다.
알려진 바와 같이, 로그 디스크는 일반적으로 순차적 인 방식으로 기록되는 반면, 데이터 디스크는 r / w에서 더 임의의 패턴을 따르며이 두 종류의 파일을 별도의 디스크에 배치하면 성능상의 이점이 있습니다.
그러나 컨트롤러는 어떻습니까? 이러한 다른 패턴을 별도의 PVSCSI 컨트롤러에 유지하면 이점이 있습니까?
누구든지 이것에 대한 통찰력이 있습니까?
미리 감사드립니다
답변:
두 부분으로 답하겠습니다. 먼저 "순차 및 랜덤 분리에 대한 기존의 대답이 종종 적용되지 않는 이유"
그런 다음 Windows 물리 디스크에서 파일을 분리하고 vHBA를 추가하고 그 사이에 물리 디스크를 배포 할 때 얻을 수있는 이점에 대해 설명합니다.
Windows 물리 디스크 수준에서 무작위 및 순차 디스크 IO를 분리하면 예상되는 이점은 일반적으로 데이터 스토리지 용 HDD 장치를 가정합니다. 또한 일반적으로 별도의 Windows 물리 디스크는 별도의 HDD 장치를 의미한다고 가정합니다. 일부 HDD 세트는 주로 순차 디스크 IO를 처리하고 디스크 헤드 이동은 매우 제한적이며 (예 : 단일 통화 중 txlog *를 호스팅하는 HDD) 별도의 HDD 세트는 임의 디스크 IO를 처리합니다.
이러한 가정은 오늘날 VM에서 거의 유지되지 않습니다. 우선, VM Windows 물리 디스크가 RDM이 아닌 경우 여러 개의 데이터 저장소가 단일 데이터 저장소에 있거나 여러 개의 데이터 저장소가 단일 ESXi 호스트 LUN에있을 수 있습니다. 따라서 게스트에서 분리 된 내용은 ESXi 호스트 수준에서 결합 될 수 있습니다.
그러나 RDM이 사용되거나 각 게스트 물리 디스크가 자체 데이터 저장소, 자체 ESXi LUN에 있다고 가정 해 봅시다. 그럼에도 불구하고 ESXi 호스트에 제공된 LUN이 동일한 단일 디스크 장치 풀에서 제공 될 수 있기 때문에 게스트에서 임의의 io와 별도의 순차적 인 io가 별도의 어레이에 결합되는 경우가 많습니다. 거의 모든 스토리지 어레이가 이제 독점적으로 또는 옵션으로 관리를 용이하게하고 어레이 효율성 / 자원 활용도를 높이기위한 옵션으로이 작업을 수행합니다.
마지막으로 오늘날 많은 스토리지는 모두 플래시 또는 하이브리드 플래시 + HDD입니다. 걱정할 필요가없는 헤드 움직임이없는 플래시는 임의의 순차적 인 분리를 신경 쓰지 않고 IO 직조를 신경 쓰지 않습니다.
따라서 ... 순차를 무작위에서 분리하는 것이 그다지 유리하지 않을 수도 있습니다. 다음으로 물리 디스크에 파일을 분산시키고 vHBA에 물리 디스크를 확산시키는 것이 여전히 성능을 향상시킬 수있는 이유는 무엇입니까?
*이 HDD 예제에서 의도적으로 단일 트랜잭션 로그를 언급했습니다. 동일한 HDD에서 여러 개의 개별 순차 디스크 IO 스트림 (예 : 8 개의 사용중인 트랜잭션 로그)이 발생하는 경우 (어떤 방식 으로든 거의 모든 활동이 SAN 캐시 내에 있지 않는 한) 순차 IO 트랙 간의 지속적인 헤드 이동으로 인해 IO 직조가 발생합니다. 이는 디스크 종류가 "무작위보다 나쁘다"는 디스크 대기 시간으로 이어지는 특정 종류의 디스크 헤드 스 래싱입니다. RAID5는 RAID5보다 RAID5보다 약간 더 많은 변형을 견딜 수 있지만 RAID5 및 RAID10에서 발생합니다.
이제 어떻게 순차적에서 무작위로 분리하는 것이 도움이되지 않을지에 대한 이야기가 주어 졌다면 물리 디스크에 파일을 분산시키는 것이 여전히 도움이 될까요? vHBA간에 물리 디스크를 확산시키는 데 어떻게 도움이됩니까?
디스크 IO 대기열에 관한 것입니다.
perfmon이 "Current Disk Queue"라고보고 한 모든 Windows 물리 디스크 또는 LogicalDisk는 한 번에 최대 255 개의 미해결 디스크 IO를 가질 수 있습니다. 물리 디스크 대기열의 미해결 디스크 IO에서 storport는 미니 드라이버에 최대 254 개를 전달할 수 있습니다. 그러나 미니 드라이버에는 서비스 대기열 (다음 하위 수준으로 전달)과 대기 대기열이 모두있을 수 있습니다. 그리고 storport는 254에서 전달하는 숫자를 낮추라고 할 수 있습니다.
VMware Windows 게스트에서 pvscsi 드라이버의 기본 "장치"큐 깊이는 64입니다. 여기서 장치는 물리 디스크입니다. 따라서 perfmon은 단일 물리 디스크에 대해 "현재 디스크 대기열 길이"에 최대 255 개의 디스크 IO를 표시 할 수 있지만 한 번에 최대 64 개의 디스크 IO 만 다음 수준으로 전달됩니다 (기본값이 변경되지 않은 경우).
하나에 대해 눈에 띄는 디스크 IO 수한 번에 바쁜 트랜잭션 로그? 트랜잭션 로그 쓰기의 크기는 최대 60kb입니다. 높은 규모의 ETL 중에는 종종 60kb로 txlog에 대한 모든 쓰기를 볼 수 있습니다. txlog 기록기는 한 번에 하나의 txlog에 최대 32 개의 60kb의 쓰기를 처리 할 수 있습니다. 따라서 기본 VMware 설정을 사용하여 동일한 물리 디스크에 바쁜 준비 txlog와 바쁜 dw txlog가있는 경우 어떻게해야합니까? 두 txlog가 각각 32 개의 미해결 60kb 쓰기에서 최대 값을 초과하는 경우 해당 물리 디스크의 큐 깊이는 64입니다. 이제 ... 물리 디스크에 플랫 파일이 ETL 소스로 있으면 어떻게됩니까? 플랫 파일에 대한 읽기와 txlog 쓰기 사이에는 대기 큐를 사용해야합니다. 한 번에 64 개만 나올 수 있기 때문입니다. 물리적 서버이든 가상이든 이와 같이 사용량이 많은 txlog가있는 데이터베이스의 경우 자체 물리적 디스크에서 txlog를 권장합니다. 물리 디스크에는 다른 것이 없습니다. 그러면 해당 수준에서 큐잉이 방지되고 여러 파일 인터리빙의 내용에 대한 우려가 없어집니다 (요즘에는 훨씬 덜 우려됩니다).
한 번에 한 행에 몇 개의 디스크 IO를 표시 할 수 있습니까 (SQL Server의 관점에서 볼 때 반드시 하위 수준으로 제출할 필요는 없음)? SQL Server 자체에는 실제로 제한이 없습니다 (어쨌든 내가 찾은 것). 그러나 파일을 가정하여 하나의 윈도우 실제 디스크 (나는 다른 시간에 대한 항목의 SQL 서버를위한 스트라이프 동적 디스크를 사용하지 않는 것이 좋습니다)에, 거기 이다 한계가. 이전에 언급 한 255입니다.
SQL Server readahead와 비동기 IO의 마법으로 직렬 드라이브에서 각각 4 개의 동시 쿼리가 총 1200 개의 "현재 디스크 큐 길이"를 보았습니다! 255 개의 한계로 인해 단일 물리 디스크의 모든 행 파일 내용으로는 불가능합니다. 각각 고유 한 물리 디스크에 8 개의 파일이있는 기본 파일 그룹에 대한 것입니다.
따라서 미리 읽기는 매우 공격적 일 수 있으며 IO 대기열에 부담을 줄 수 있습니다. 다른 행 파일 읽기 및 쓰기가 결국 대기하도록 너무 공격적 일 수 있습니다. 트랜잭션 로그가 행 파일과 동일한 물리적 디스크에있는 경우 동시 미리 읽기 및 txlog 쓰기 중에는 대기하기가 매우 쉽습니다. 대기가 "현재 디스크 큐 길이"레벨이 아니더라도 장치 큐에서 대기 중일 수 있습니다 (기본적으로 pvscsi에서는 64).
행 파일에 대한 백업 읽기는 특히 백업 처리량을 최대화하기 위해 버퍼 수가 조정 된 경우 공격적 일 수 있습니다.
txlog를 격리 할 때 고려해야 할 SQL Server IO 유형이 하나 더 있습니다. 쿼리 유출을 tempdb로. 쿼리 유출이 발생하면 각각의 유출 작업은 tempdb에 기록됩니다. 동시에 많은 병사들이 쏟아져 나왔습니까? 그것은 꽤 쓰기로드 일 수 있습니다. 바쁜 txlog와 중요한 행 파일을 멀리두면 정말 도움이 될 수 있습니다 :-)
이제 pvscsi 드라이버의 기본 장치 큐 깊이를 변경할 수 있습니다. 기본값은 64이며 storport가 가장 많이 전달할 수있는 최대 254까지 설정할 수 있습니다. 그러나 이것을 조심스럽게 변경하십시오. 게스트 장치 대기열 깊이를 기본 ESXi 호스트 LUN 대기열 깊이에 맞추는 것이 좋습니다. 그리고 어레이 모범 사례에 따라 ESXi 호스트 LUN 대기열 용량을 설정합니다. EMC VNX를 사용하십니까? 호스트 LUN 대기열 크기는 32 여야합니다. 게스트는 RDM을 사용합니까? 큰. 게스트 pvscsi 디바이스 큐 깊이를 32로 설정하여 ESXi 호스트 LUN 큐 깊이에 맞 춥니 다. EMC VMAX? ESXi 호스트 레벨에서 일반적으로 64, 게스트에서 64. Pure / Xtremio / IBM FlashSystem? 때때로 호스트 LUN 대기열 용량이 256으로 높게 설정됩니다! 계속해서 pvscsi 장치 큐 용량을 254 (최대 가능)로 설정하십시오.
지침이있는 링크는 다음과 같습니다. https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
링크는 또한 requestringpages에 대해 이야기합니다-WhatAreThose ?? pvscsi 어댑터 자체의 큐 용량을 결정합니다. 각 페이지는 32 개의 슬롯을 어댑터 대기열 깊이로 제공합니다. 기본적으로 requestringpages는 어댑터 큐 깊이 256의 경우 8입니다. 1024 개의 어댑터 큐 깊이 슬롯의 경우 최대 32까지 설정할 수 있습니다.
모든 것이 기본값이라고 가정 해 봅시다. 행 파일이있는 8 개의 물리 디스크가 있으며 SQL Server는 사용량이 적습니다. 8에 걸쳐 평균 32 개의 "현재 디스크 큐 길이"가 있으며 64보다 큰 것은 없습니다 (다양한 장치 서비스 큐에 모두 해당). 훌륭합니다-256 OIO를 제공합니다. 장치 서비스 대기열에 적합하고 어댑터 서비스 대기열에 적합하므로 256 개 모두 게스트에서 ESX 호스트 수준의 대기열로 연결합니다.
그러나… 상황이 조금 더 바 빠지면 실제 디스크 대기열이 128 개로 평균 64 개가됩니다. 64 개가 넘는 장치의 경우 초과분은 대기 대기열에 있습니다. 8 개 물리 디스크의 장치 서비스 대기열에 256 개가 넘는 경우 어댑터 서비스 대기열의 슬롯이 열릴 때까지 대기 대기열에 초과가 발생합니다.
이 경우 다른 pvscsi vHBA를 추가하고 이들 사이에 물리 디스크를 분산 시키면 총 어댑터 대기열 길이가 512로 두 배가됩니다. 동시에 더 많은 io를 게스트에서 호스트로 전달할 수 있습니다.
하나의 pvscsi 어댑터에 머무르고 요청 페이지를 늘리면 비슷한 결과를 얻을 수 있습니다. 16으로 가면 512 개의 슬롯이 생성되고 32가되면 1024 개의 슬롯이 생성됩니다.
가능하면 깊이 들어가기 전에 어댑터를 넓히는 것이 좋습니다 (어댑터 대기열 깊이 증가). 그러나 가장 바쁜 시스템의 경우 두 가지를 모두 수행해야합니다. 게스트에 vHBA 4 개를 배치하고 요청 페이지를 32 개로 늘리십시오.
다른 고려 사항도 많이 있습니다. vmdks를 사용하는 경우 sioc 및 적응 큐 깊이 조절, 다중 경로 구성, LUN 큐 깊이를 초과하는 ESXi 어댑터 구성 등
그러나 나는 내 환영을 남용하고 싶지 않습니다 :-)
Lonny Niederstadt @sqL_handLe