지금까지 우리는 Microsoft Azure Stack HCI에 대해 자세히 알아보기, Microsoft Azure 클라우드 서비스의 온프레미스 구현입니다. Azure Stack HCI는 두 가지 모두에서 최고의 플랫폼 유형으로 볼 수 있습니다. Azure Monitor, Azure Security Center, Azure 업데이트 관리, Azure 네트워크 어댑터 및 Azure Site Recovery와 같은 Azure의 모든 관리 도구가 있으며 데이터를 온프레미스에 저장하고 특정 규정을 충족합니다. Azure Stack HCI는 소프트웨어 정의 아키텍처, Azure 서비스 및 하드웨어의 세 부분으로 나뉩니다.
지금까지 우리는 Microsoft Azure Stack HCI에 대해 자세히 알아보기, Microsoft Azure 클라우드 서비스의 온프레미스 구현입니다. Azure Stack HCI는 두 가지 모두에서 최고의 플랫폼 유형으로 볼 수 있습니다. Azure Monitor, Azure Security Center, Azure 업데이트 관리, Azure 네트워크 어댑터 및 Azure Site Recovery와 같은 Azure의 모든 관리 도구가 있으며 데이터를 온프레미스에 저장하고 특정 규정을 충족합니다. Azure Stack HCI는 소프트웨어 정의 아키텍처, Azure 서비스 및 하드웨어의 세 부분으로 나뉩니다.
기사 "에서 자세히 설명했듯이 올바른 하드웨어를 선택하는 것이 중요합니다.Microsoft Azure Stack HCI에서 하드웨어의 중요성.” Azure Stack HCI를 배포하는 첫 번째 단계는 인증된 하드웨어 공급업체(이 경우 DataON)를 찾는 것입니다. DataON은 몇 년 동안 Microsoft 및 Intel과 강력한 파트너십을 유지해 왔으며 Intel Select 구성의 Azure Stack HCI에 대한 하드웨어 레이아웃에서 이 파트너십을 완전히 실현했습니다. Intel과의 파트너십의 흥미로운 측면은 Azure Stack HCI와 함께 회사의 PMEM(및 최신 프로세서)을 활용할 수 있는 능력입니다.
대부분의 경우 DataON HCI Intel Select 솔루션은 자체 랙에 구성 및 배송되어 즉시 배포할 수 있습니다. 이 제공 방법은 기존 IT 인프라가 제한적이거나 존재하지 않는 엣지에서 특히 유용합니다. StorageReview 랩에서는 아래 다이어그램과 같이 XNUMX개의 스토리지 및 컴퓨팅 노드, 도메인 컨트롤러 및 스위치를 배포했습니다.
빌드 및 디자인
우리가 검토한 Microsoft Azure Stack HCI 클러스터는 DataON HCI-224 All Flash NVMe 플랫폼에 구축되었습니다. 이 서버는 전면에 2-NVMe 베이가 있는 24U 크기로 PCIe 기반 구성 요소를 위해 후면에 충분한 확장을 제공합니다. 무광 블랙 드라이브 캐디와 달리 레이블이 높아서 교체할 때가 되면 특정 드라이브를 쉽게 찾을 수 있습니다. 모든 것이 레이블이 지정되어 있으며 이는 드문 일이 아니지만 레이블 지정 범위는 입니다. 배포에는 레이블이 지정된 각 노드(1~4)와 데이터 센터에서 쉽게 배포하고 관리할 수 있는 기타 여러 항목이 있습니다.
구성에는 48개의 NVMe SSD 또는 노드당 12개가 장착되었습니다. 여기에는 375개의 4800GB Intel Optane P4510X SSD와 2개의 Intel PXNUMX XNUMXTB SSD가 포함되었습니다.
후면에는 클러스터 네트워크 트래픽을 위한 100개의 Mellanox 5G 스위치(SN100)를 통해 완전한 중복 연결을 제공하는 2100개의 듀얼 포트 XNUMXG Mellanox Connect-X XNUMX NIC가 있습니다. 스튜디오 사진에는 표시되지 않았지만 배포 단계에서 오류 없는 케이블 연결을 허용하기 위해 적절한 네트워크 케이블의 각 끝에 완전한 레이블이 지정된 모든 연결이 있습니다.
이전에는 레이블에 이 정도 수준의 문서가 포함된 솔루션이 없었습니다. Microsoft와 DataON은 고객이 즉시 운영할 수 있도록 Azure Stack을 배포하는 과정을 수월하게 만듭니다. 각 케이블은 특정 용도에 맞게 색상으로 구분되어 있으며 각 끝이 어디로 가는지 레이블이 지정되어 있습니다. DataON이 고객에게 제공하는 맞춤형 시트와 결합하여 거의 오류 없는 배포를 보장합니다. 우리 배포에서 시스템은 선적 전에 IP 주소로 사전 구성되었으며 관리용 IP 주소와 IPMI 레이블이 지정되었습니다.
관리 및 유용성
Windows Server에서 운영되는 Hyper-V 매장을 운영하는 구매자의 경우 Microsoft Azure Stack HCI로 쉽게 전환할 수 있습니다. 동일한 관리 도구가 많이 있으며 더 통합되고 단순한 워크플로를 제공하는 도구가 많습니다. 검토 프로세스에서 우리는 Windows Failover Cluster Manager를 모두 활용하여 DataOn HCI 클러스터를 관리하고 Windows Admin Center를 사용하여 워크로드를 모니터링하고 성능을 확인했습니다.
먼저 노드 중 하나에 로그인한 Microsoft 원격 데스크톱(RDP) 세션을 통해 노드 수준을 더 많이 살펴보고 Windows 장애 조치 클러스터 관리자를 살펴봤습니다. 이는 노드 수준 관리 기능과 클러스터 수준 가시성을 모두 제공합니다. 이러한 유형의 액세스는 Windows Admin Center에서 일상적인 모니터링이 수행되는 초기 배포에 더 적합합니다.
먼저 특정 클러스터를 클릭하고 이에 대한 일반 정보, 구성 기능 및 리소스를 살펴봅니다. 그러면 선택한 클러스터의 요약 보기가 제공되어 문제가 있는 위치를 확인하고 특정 영역으로 드릴을 시작할 수 있습니다.
다음은 장애 조치 역할입니다. 여기에서 클러스터에서 실행 중인 모든 Hyper-V VM을 볼 수 있습니다. 클러스터의 스트레스 테스트에 사용한 많은 vmfleet VM이 표시됩니다.
네트워크를 통해 사용 가능한 클러스터 네트워크와 각각의 상태를 확인할 수 있습니다. 클러스터 네트워크를 선택하면 연결된 기본 네트워크 카드와 IP 주소를 볼 수 있습니다.
스토리지 옵션 아래에는 디스크, 풀 및 인클로저가 있습니다. 디스크의 경우 가상 디스크를 클릭하고 할당된 상태, 소유자 노드, 디스크 번호, 파티션 스타일 및 용량과 같은 정보를 얻을 수 있습니다. 사용자는 풀 ID, 이름, 설명, 가상 디스크 ID, 이름, 설명, 상태 및 작동 상태, 복원력과 같은 더 많은 정보를 통해 조금 더 자세히 드릴다운할 수 있습니다.
풀은 상태, 상태, 소유자 노드, 작동 상태, 전체 용량, 여유 공간 및 사용 공간과 같은 특정 스토리지 풀의 정보와 유사합니다.
노드에서 클러스터의 모든 노드와 해당 상태를 쉽게 볼 수 있습니다.
오른쪽에서 장애 조치 디스크로 전환하고 하단에서 주어진 노드에 대한 개별 디스크를 볼 수 있습니다.
동일한 사이드바에서 주어진 노드에 대한 네트워크를 볼 수도 있습니다.
Windows 장애 조치 클러스터 관리자는 보다 "세부적인" 관리 장치이지만 이를 사용하려면 사용자가 Windows 원격 데스크톱을 통해 서버 자체(또는 해당 클러스터에 연결된 다른 서버)에 연결해야 합니다. 이 관리 스타일은 많은 용도에 적합하지만 Microsoft는 Windows Admin Center라는 새로운 플랫폼으로 작업을 더 쉽게 만들었습니다. 장애 조치(failover) 클러스터 관리자와 달리 Windows Admin Center는 완전히 웹 브라우저 기반이므로 직장의 모든 컴퓨터나 태블릿에서 쉽게 연결할 수 있습니다. 또한 현대적이고 심미적으로 만족스러운 모양과 느낌을 제공하여 일상적인 모니터링을 더욱 즐겁게 만듭니다. 장애 조치(failover) 클러스터 관리자가 동일한 범위로 제공하지 않는 활동 모니터링에 더 중점을 두고 동일한 정보를 많이 살펴봅니다.
Windows Admin Center가 클러스터와 연결되면 특정 영역으로 드릴다운하여 작업을 보고 관리할 수 있습니다. 여기에서 VM이 활용하는 전체 리소스를 추적하는 전체 클러스터 컴퓨팅 성능 정보를 볼 수 있습니다.
Windows Admin Center는 활동 보기에 적합하지만 클러스터의 VM과 계속 상호 작용할 수 있습니다. 아래에서는 여러 vmfleet VM의 전원을 켭니다.
사용자는 특정 VM에 대한 정보를 자세히 살펴볼 수도 있습니다.
역할에 따라 역할에 대해 약간 다른 역할을 수행하지만 대부분 동일한 주요 정보를 얻습니다.
설정에서 사용자는 Azure용 확장을 다운로드, 설치 및 업데이트할 수 있습니다.
Windows Admin Center를 통해 Hyper-Converged Cluster Manager로 이동하여 컴퓨팅 및 스토리지를 보다 자세히 살펴볼 수도 있습니다. 서버, 드라이브, VM, 볼륨의 수와 CPU, 메모리 및 스토리지 사용량과 같은 일반 정보가 있는 대시보드를 엽니다. 대시보드 하단에는 특정 시간 프레임과 IOPS 및 대기 시간으로 분류되는 클러스터 성능이 있습니다.
컴퓨팅에서 관리자는 클러스터에서 서버 제거를 포함하여 관리를 위해 서버 자체를 드릴할 수 있습니다. 여기에는 가동 시간, 위치, 도메인, 제조업체, 모델, 일련 번호, OS 이름, 버전 및 빌드 번호와 같은 사용된 서버에 대한 일반 정보가 있습니다. 또한 사용자는 서버에 특정한 성능을 볼 수 있습니다.
볼륨 탭을 클릭하면 사용자가 클러스터의 모든 볼륨에 대한 요약을 볼 수 있습니다. 볼륨의 상태는 색상으로 구분됩니다. 정상은 녹색, 위험은 빨간색, 경고는 노란색입니다. 모든 볼륨에 대한 성능도 추적되며 시간 프레임별로 IOPS, 대기 시간 및 처리량으로 분류됩니다.
단일 볼륨으로 드릴다운하면 상태, 파일 시스템, 경로, 장애 도메인 인식, 총 크기, 사용된 크기, 복원력 및 공간을 포함하여 볼륨의 특정 속성이 제공됩니다. 여기에서 끄거나 켤 수 있는 선택적 기능(중복 제거 및 압축, 무결성 체크섬)이 있습니다. 용량은 그래픽으로 표시되어 사용 대 사용 가능 여부를 보여줍니다. 그리고 다시 성능을 확인합니다.
드라이브 탭에서 시스템의 모든 드라이브에 대한 요약을 얻습니다. 여기에서 총 드라이브 수와 볼륨과 동일한 색상 코딩을 가진 경고가 있는지 여부를 볼 수 있습니다. 용량(사용됨, 사용 가능 및 예약)도 볼 수 있습니다.
Inventory를 클릭하면 모든 드라이브 목록과 몇 가지 세부 정보가 표시됩니다. 세부 정보에는 드라이브의 상태, 모델, 용량 크기, 유형, 용도 및 사용된 스토리지 양이 포함됩니다.
단일 드라이브로 드릴다운하여 상태, 위치, 크기, 유형, 용도, 제조업체, 모델, 일련 번호, 펌웨어 버전 및 스토리지 풀과 같은 속성을 볼 수 있습니다. 사용된 용량을 볼 수 있습니다. IOPS, 대기 시간 및 처리량의 개별 드라이브 및 성능에 대해 사용 가능한 것과 비교합니다.
성능 아래에서 드라이브 대기 시간 및 오류 통계도 볼 수 있습니다.
퍼포먼스
Microsoft Azure Stack 에코시스템 내부의 성능은 항상 훌륭했으며 Storage Spaces 시절부터 강력한 성능을 발휘했습니다. 이를 염두에 두고 이 리뷰에서 사용자가 이 플랫폼이 시장의 다른 HCI 솔루션과 얼마나 잘 비교되는지 확인할 수 있도록 몇 가지 일반적인 벤치마킹 워크로드를 살펴보았습니다. 이를 염두에 두고 워크로드를 사용하여 임의의 작은 블록 크기와 큰 블록 전송을 강조하여 이 Microsoft 솔루션이 제공할 수 있는 잠재력을 보여주었습니다. Azure Stack HCI 검토에서는 성능 벤치마크에 vmfleet을 활용했고 VMware 또는 베어메탈 Linux에서는 vdbench를 사용했습니다.
여기서 성능을 위해 2-way 미러와 3-way 미러로 시스템을 테스트했습니다. 미러는 데이터 보호 방법(3개 또는 2개)을 나타냅니다. 분명히 더 많은 사본을 사용하면 사용자는 일부 용량을 잃게 됩니다. 성능 관점에서 XNUMX-way는 병렬 처리의 증가를 통해 더 나은 읽기로 이어져야 하며 XNUMX-way는 네트워크 트래픽이 XNUMX분의 XNUMX로 적어 쓰기 성능이 더 좋습니다.
4K 랜덤 테스트에서 양방향 미러는 2µs의 평균 대기 시간에서 2,204,296 IOPS의 읽기 처리량과 247ms의 평균 대기 시간에서 564,601 IOPS의 쓰기 처리량을 확인했습니다. 3.69-way는 3µs의 평균 대기 시간에서 읽기 2,302,610 IOPS의 읽기 처리량을 보였고 쓰기의 경우 평균 대기 시간 170ms에서 338,538 IOPS의 처리량이었습니다. 이 중 일부를 살펴보기 위해 노드당 9.12개의 Optane SSD와 521개의 NVMe 용량 SSD를 사용하는 VMware의 vSAN 제품은 최대 읽기에서 4K IOPS 202K, 쓰기에서 XNUMXK IOPS를 측정했습니다.
다음으로 32K 순차 벤치마크를 살펴봅니다. 읽기의 경우 양방향은 2GB/s, 42.59방향은 3GB/s를 기록했습니다. 쓰기의 경우 HCI는 39.48방향에 13.8GB/s, 2방향에 7.19GB/s를 제공했습니다.
순차적 작업을 계속하면서 64K 테스트로 이동합니다. 여기서 2방향 조회수는 39.5GB/s 읽기 및 15.24GB/s 쓰기이고 3방향 조회수는 46.47GB/s 읽기 및 7.72GB/s 쓰기입니다. vSAN과 비교할 때 읽기 대역폭 차이는 근접하지도 않습니다. 테스트에서 대역폭은 5.3K 블록 크기로 64GB/s를 약간 상회했습니다. 쓰기 대역폭도 비슷한 차이를 보였고 vSAN은 2.55GB/s로 최고를 기록했습니다.
다음 벤치마크는 읽기/쓰기 성능이 혼합된 SQL입니다. 여기에서 양방향은 2µs의 평균 대기 시간에서 1,959,921 IOPS의 처리량을 가졌습니다. 324방향은 3 IOPS를 기록했고 평균 지연 시간은 1,929,030µs입니다. SQL 워크로드는 Azure Stack HCI가 185만 IOPS에 조금 못미치는 것으로 측정할 수 있는 또 다른 영역이며, 동일한 워크로드 프로필의 VMware vSAN은 2k IOPS를 측정했습니다.
SQL 90-10에서 2방향은 평균 대기 시간이 1,745,560µs인 411 IOPS를 기록했고 3방향은 대기 시간이 1,547,388 IOPS 및 285µs였습니다.
SQL 80-20의 경우 2-way는 대기 시간에 대해 1,530,319µs에서 581 IOPS의 처리량을 가졌습니다. 3방향은 1,175,469 IOPS와 681µs의 대기 시간을 기록했습니다.
사양
다음은 여기에서 우리를 위한 새로운 테스트인 SPECsfs 2014 SP2 벤치마크입니다. SPECsfs는 파일 서버 처리량과 응답 시간을 측정하는 벤치마크 제품군입니다. 벤치마크는 서로 다른 공급업체 플랫폼 간의 성능을 비교하기 위한 표준화된 방법을 제공합니다. 벤치마크는 기준 대기 시간이 벤치마크 사양에 비해 너무 클 때까지 척도를 설정하고 증분하는 방식으로 작동합니다. 여기서 우리는 11ms가 위반될 때까지 수행할 수 있는 규모와 서버가 대기 시간 수에 실패할 때 도달하는 대역폭을 살펴봅니다.
두 번째 부분에서 대역폭이 중단된 이유에 대해 더 많은 정보를 제공하므로 여기에서 대기 시간을 먼저 살펴보겠습니다. 2방향 및 3방향 모두에 대한 규모와 대기 시간은 아래 표에 나와 있습니다.
| SPECsfs 대기 시간(밀리초) | ||
|---|---|---|
| 규모 | DataON HCI-224 양방향 미러 | DataON HCI-224 양방향 미러 |
| 100 | 0.243 | 0.262 |
| 200 | 0.329 | 0.371 |
| 300 | 0.466 | 0.499 |
| 400 | 0.636 | 0.699 |
| 500 | 0.753 | 0.896 |
| 600 | 0.953 | 1.083 |
| 700 | 1.113 | 1.314 |
| 800 | 1.326 | 1.557 |
| 900 | 1.501 | 1.826 |
| 1000 | 1.88 | 2.167 |
| 1100 | 2.061 | 2.807 |
| 1200 | 2.323 | 4.64 |
| 1300 | 2.749 | 8.557 |
| 1400 | 5.47 | 10.449 |
| 1500 | 8.616 | 11.285(실패) |
| 1600 | 10.485 | 11.414(실패) |
| 1700 | 11.069 | |
| 1800 | 11.697(실패) | |
| 1900 | 12.51(실패) | |
보시다시피, 두 가지 구성 모두 250µs 근처에서 시작했고, 2웨이는 약간 아래에서 전체적으로 그 상태를 유지했습니다. 1500의 척도에서 3-way는 11.285ms까지 실패하여 262µs에서 10.45ms의 범위를 제공합니다. 2-way는 1800ms에 도달하는 11.7의 규모에서 실패하여 243µs에서 11.07ms의 범위를 제공합니다.
다음 표는 각 빌드의 각 구성에 대한 대역폭을 보여주며 위에 나열된 오류는 대기 시간으로 표시됩니다.
| SPECsfs 대역폭(KB/s) | ||
| 규모 | DataON HCI-224 양방향 미러 | DataON HCI-224 양방향 미러 |
| 100 | 300897 | 300880 |
| 200 | 600372 | 600857 |
| 300 | 901672 | 902964 |
| 400 | 1202779 | 1203106 |
| 500 | 1504492 | 1503394 |
| 600 | 1805952 | 1806455 |
| 700 | 2105973 | 2108432 |
| 800 | 2408183 | 2406171 |
| 900 | 2710895 | 2707106 |
| 1000 | 3007499 | 3009280 |
| 1100 | 3308648 | 3308168 |
| 1200 | 3608244 | 3610219 |
| 1300 | 3910414 | 3888303 |
| 1400 | 4212976 | 4026720 |
| 1500 | 4513454 | 4000079(실패) |
| 1600 | 4587183 | 4229678(실패) |
| 1700 | 4621067 | |
| 1800 | 4630352(실패) | |
| 1900 | 4569824(실패) | |
대역폭의 경우, 두 구성 모두 300MB/s 간격으로 3방향이 최종 통과 대역폭이 4.02GB/s이고 2방향이 4.62GB/s의 최종 통과 대역폭을 갖는 대기 시간에 실패할 때까지 연속적으로 실행되었습니다. 에스.
결론
Microsoft 스토리지 중심 스택에 대해 이렇게 깊이 파고든 지 꽤 되었습니다. 그리고 소년, 우리는 돌아와서 기쁘다. 리브랜딩된 Microsoft Azure Stack HCI 솔루션을 통해 Microsoft는 매우 기본적이고 기본적인 작업을 수행했으며 감사하기 쉽습니다. Microsoft는 HCI 솔루션을 성능 저하를 위해 오버레이하지 않고 매우 간단하게 작동하도록 만들었습니다. 숫자에서 알 수 있듯이 우리가 테스트한 DataON 클러스터는 미드 마켓 4노드 HCI 클러스터에서 가장 빠른 엄청난 숫자를 기록했습니다. 공정하게 말하면 우리는 DataON의 최신 하드웨어를 테스트하지도 않습니다. 이 구성은 Intel Optane DC SSD로 완성된 완벽한 구성이지만 Intel Xeon 2세대 CPU, 영구 메모리 및 더 빠른 네트워킹을 활용하는 더 빠른 솔루션을 제공합니다. Azure Stack HCI 솔루션에서 훨씬 더 많은 성능을 사용할 수 있다는 사실은 흥미롭지만 솔루션이 다음과 같은 소규모 배포로 축소될 수 있음을 기억하는 것도 중요합니다. XNUMX노드 HCI 저비용 에지 또는 SMB 솔루션을 위해 스위치 없이 구성할 수 있습니다.
성능 수치를 살펴보면 Microsoft Azure Stack HCI 클러스터는 엄청난 양의 I/O 및 대역폭을 제공할 수 있었습니다. 2.3코너 영역에서 4방향 미러 구성으로 3k IOPS 338K 임의 읽기와 4k IOPS 2K 임의 쓰기를 초과하여 측정했습니다. 더 높은 쓰기 성능이 필요한 경우 양방향 미러 구성을 통해 4K 임의 쓰기 속도를 564k IOP로 높일 수 있습니다. 하지만 대역폭을 살펴보면 Microsoft Azure Stack이 정말 빛을 발합니다. 64K 블록 순차 전송 워크로드에서 양방향 미러는 2GB/s 읽기 및 39.5GB/s 쓰기를 측정한 반면 15.24방향 미러는 3GB/s 읽기 및 46.47GB/s 쓰기를 측정했습니다. 이는 과거 HCI 클러스터에서 측정한 값을 훨씬 능가합니다.
전반적으로 Microsoft의 Azure Stack HCI 솔루션은 배포가 간단하고 관리가 쉬우며 탁월한 성능을 제공하는 것으로 입증되었습니다. 솔루션의 파트너인 DataON은 턴키 빌드를 제공하는 데 탁월했으며, 명확한 지침이 포함된 사양에 맞게 제작된 하드웨어를 제공하여 궁극적으로 즉시 가동할 수 있는 구성으로 판매되었습니다. 고객은 많은 경우 배선을 건너뛸 수도 있으므로 특정 요구 사항에 따라 결정됩니다. 그러나 어느 쪽이든 Intel Optane, Intel NVMe SSD 및 Mellanox 100G 네트워킹과 결합된 Azure Stack HCI는 그 자체로 무시할 수 없는 힘을 입증했습니다.
