%

Date: 5월 16, 2022

ZRS(영역 중복 저장소)가 있는 Azure 공유 디스크의 성능

2021년 9월 9일 마이크로소프트 발표 일반 가용성 Azure Disk Storage용 ZRS(영역 중복 저장소) , Azure 공유 디스크 포함.

흥미로운 점은 이제 가용 영역(AZ)에 걸쳐 공유 스토리지 기반 장애 조치 클러스터 인스턴스를 구축할 수 있다는 것입니다.클러스터 노드가 서로 다른 AZ에 있으므로 사용자는 이제 99.99% 가용성 SLA에 대한 자격을 얻을 수 있습니다. 영역 중복 저장소를 지원하기 전에 Azure 공유 디스크는 LRS(로컬 중복 저장소)만 지원하여 클러스터 배포를 단일 AZ로 제한하여 사용자가 AZ가 오프라인이 될 경우 중단될 수 있었습니다.

그러나 ZRS를 사용하여 Azure 공유 디스크를 배포할 때 알아야 할 몇 가지 제한 사항이 있습니다.

프리미엄 SSD(반도체 드라이브) 및 표준 SSD에서만 지원됩니다. Azure 울트라 디스크는 지원되지 않습니다.
ZRS가 포함된 Azure 공유 디스크는 현재 미국 서부 2, 서부 유럽, 북유럽 및 프랑스 중부 지역에서만 사용할 수 있습니다.
읽기 및 쓰기의 디스크 캐싱은 프리미엄 SSD Azure 공유 디스크에서 지원되지 않습니다.
프리미엄 SSD에는 디스크 버스팅을 사용할 수 없습니다.
Azure Site Recovery 지원은 아직 사용할 수 없습니다.
Azure Backup은 Azure Disk Backup을 통해서만 사용할 수 있습니다.
서버 쪽 암호화만 지원되며 Azure 디스크 암호화는 현재 지원되지 않습니다.

나는 또한 흥미로운 메모를 발견했습니다. 선적 서류 비치 .

"더 많은 쓰기 지연 시간을 제외하고 ZRS를 사용하는 디스크는 LRS를 사용하는 디스크와 동일하며 확장 목표가 동일합니다. 디스크를 벤치마킹하여 애플리케이션의 워크로드를 시뮬레이션하고 LRS와 ZRS 디스크 간의 대기 시간을 비교하십시오.” 문서에 ZRS가 추가 쓰기 대기 시간을 발생시키는 것으로 나와 있지만 예상할 수 있는 추가 대기 시간을 결정하는 것은 사용자의 몫입니다. 에 대한 링크 디스크 벤치마크 성능 테스트에 도움이 되도록 문서가 제공됩니다.

문서의 지침에 따라 DiskSpd를 사용하여 발생할 수 있는 추가 쓰기 대기 시간을 측정했습니다. 물론 결과는 작업 부하, 디스크 유형, 인스턴스 크기 등에 따라 다르지만 여기 내 결과가 있습니다.

	LRS(로컬 중복 스토리지)	영역 중복 저장소(ZRS)
쓰기 IOPS	5099.82	4994.63
평균 지연 시간	7.830	7.998

내가 실행한 DiskSpd 테스트는 다음 매개변수를 사용했습니다.

diskspd -c200G -w100 -b8K -F8 -r -o5 -W30 -d10 -Sh -L testfile.dat ZRS가 있는 P30 디스크와 표준 DS3 v2(4개의 vcpus, 14GiB 메모리)에 연결된 LRS가 있는 P30에 썼습니다. ) 인스턴스 유형. 공유 ZRS P30도 다른 AZ의 동일한 인스턴스에 연결되었고 빈 클러스터 애플리케이션에 공유 스토리지로 추가되었습니다.

2%의 오버헤드는 데이터를 2개의 AZ에 동기적으로 배포하기 위해 지불해야 하는 합리적인 가격처럼 보입니다. 하지만 클러스터링된 애플리케이션을 원격 노드로 이동하여 디스크를 하나의 AZ에, 인스턴스를 다른 AZ에 배치하면 어떻게 될지 궁금했습니다.

결과는 다음과 같습니다.

	LRS(로컬 중복 스토리지)	영역 중복 저장소(ZRS)	원격 AZ에서 쓸 때 ZRS
쓰기 IOPS	5099.82	4994.63	4079.72
평균 지연 시간	7.830	7.998	9.800

이 시나리오에서 나는 25%의 쓰기 지연 증가를 측정했습니다. AZ에 완전한 장애가 발생하면 스토리지와 인스턴스가 모두 보조 AZ로 장애 조치되며 이러한 지연 시간 증가는 전혀 발생하지 않습니다. 그러나 AZ 전체가 아닌 다른 오류 시나리오에서는 클러스터된 애플리케이션이 한 AZ에서 실행되고 Azure 공유 디스크가 다른 AZ에서 실행될 수 있습니다. 이러한 시나리오에서는 추가 오버헤드를 피하기 위해 가능한 한 빨리 클러스터링된 워크로드를 스토리지와 동일한 AZ에 있는 노드로 다시 이동하려고 할 것입니다.

Microsoft는 방법을 문서화합니다. 스토리지 계정 장애 조치 시작 GRS를 사용할 때 다른 지역으로 이동하지만 영역 중복 저장소를 사용할 때 다른 AZ로 저장소 계정의 장애 조치를 수동으로 시작할 수 있는 방법이 없습니다. 장애 조치(failover) 클러스터 인스턴스를 모니터링하여 클러스터 워크로드가 다른 서버로 이동할 때마다 경고를 받고 안전하게 이동하는 즉시 다시 이동할 계획을 세워야 합니다.

예기치 않게 이러한 상황에 처할 수 있지만 롤링 업데이트를 수행할 때 클러스터된 응용 프로그램 서버의 계획된 유지 관리 중에도 확실히 발생합니다. 인식은 스토리지가 저하된 상태에서 수행되는 시간을 최소화하는 데 도움이 되는 핵심입니다.

앞으로 Microsoft에서 사용자가 GRS와 마찬가지로 ZRS 디스크의 수동 장애 조치를 시작할 수 있기를 바랍니다. GRS에 기능을 추가한 이유는 자동 장애 조치가 예상대로 발생하지 않을 경우에 대비하여 사용자의 손에 권한을 주기 위함이었습니다. Zone Redundant Storage의 경우 SIOS DataKeeper와 같은 호스트 기반 복제 솔루션이 수행하는 방식과 유사하게 스토리지와 애플리케이션을 함께 연결하여 항상 동일한 AZ에서 실행되도록 하려는 사람들을 볼 수 있었습니다.