고성능 올플래시 스토리지 어레이 시장에 있는 사람들은 NetApp AFF A800과 잘 맞을 것입니다. 종단 간 NVMe 어레이는 엄청난 성능을 제공하며 NetApp의 강력한 AFF 어레이 라인에서 나옵니다. 우리는 이전에 Fibre Channel을 통해 A800을 검토한 결과 Editor's Choice 상을 수상한 뛰어난 성능을 발휘하는 것으로 나타났습니다. 이 검토를 위해 이번에는 NVMeOF(NVMe over Fabrics)를 활용하여 동일한 어레이를 테스트하고 있습니다.
이번 리뷰는 후속 리뷰이므로 디자인 및 제작, 사양, 관리와 같은 내용은 다루지 않겠습니다. 첫 번째 리뷰 에서 이러한 모든 영역을 자세히 다뤘습니다. 리뷰 설정은 기본적으로 동일하지만 성능 차이를 확인하기 위해 네트워크 인터페이스만 다르게 구성했습니다. 다만, 이번 리뷰는 완전히 동일한 조건으로 비교하는 것은 아닙니다. 해당 어레이는 다양한 사용자 요구에 맞춰 여러 연결 방식을 제공하며, 저희는 각 연결 방식별 성능을 사용자들이 참고할 수 있도록 다양한 연결 유형을 검토하고 있습니다.
2014년에 처음 소개된 NVMeOF는 네트워크를 통해 전송 프로토콜을 사용하는 것과 PCIe 버스를 통해 NVMe 장치를 활용하는 개념입니다. NVM Express, Inc.는 2016년에 NVMeOF에 대한 표준을 발표했습니다. NVMeOF를 사용하면 NVMe 호스트가 대기 시간을 낮게 유지하면서 NVMe 대상 스토리지에 연결할 수 있습니다. 일반적인 아이디어는 대기 시간을 크게 추가하지 않고 더 많은 성능을 얻는 것입니다. 지금까지 프로토콜이 지원되거나 동시에 여러 모드에서 실행될 수 있는 여러 공급업체의 많은 접근 방식이 있었습니다. ONTAP가 장착된 AFF A800은 거의 땀을 흘리지 않고 CIFS, NFS, iSCSI, FCP 및 FC NVMeOF를 동시에 실행할 수 있습니다. 모든 플랫폼이 이런 방식으로 만들어지는 것은 아니며 NetApp EF600(약간 다른 목표를 염두에 두고 설계됨)도 FCP 또는 FC NVMeOF에서 실행할 수 있지만 동시에 둘 다 실행할 수는 없습니다.
성능 구성
NetApp AFF A800의 구성에는 8개의 32TB NVMe SSD가 설치된 24개의 1.92Gb FC 포트가 포함되었습니다. A24에 배치된 1.92개의 800TB SSD 중에서 우리는 SSD를 23개의 RAID-DP Aggregate로 분할하여 효과적으로 32개의 SSD를 사용하고 620개의 하프 파티션을 핫 스페어로 유지했습니다. 각 SSD의 절반은 두 컨트롤러로 분할되어 각 컨트롤러가 설치된 모든 SSD의 성능을 활용할 수 있습니다. 어레이는 16개의 Brocade G32 스위치를 통해 12Gb를 통해 연결되었으며, SLES 740 SP12를 실행하는 4개의 Dell PowerEdge RXNUMXxd 서버에 XNUMX개의 XNUMXGb 링크가 있었습니다.
각 서버는 2개의 350GB LUN으로 프로비저닝되어 총 스토리지 공간은 8.4TB입니다.
성능
스토리지 어레이를 벤치마킹할 때는 애플리케이션 테스트가 가장 좋고 합성 테스트가 두 번째입니다. 실제 워크로드를 완벽하게 나타내지는 못하지만 합성 테스트는 경쟁 솔루션 간의 비교를 쉽게 수행할 수 있는 반복성 요소로 스토리지 장치의 기준선을 만드는 데 도움이 됩니다. 이러한 워크로드는 "포 코너" 테스트, 공통 데이터베이스 전송 크기 테스트, 다양한 VDI 환경의 트레이스 캡처에 이르는 다양한 테스트 프로필을 제공합니다. 이러한 모든 테스트는 스크립팅 엔진과 함께 공통 vdBench 워크로드 생성기를 활용하여 대규모 컴퓨팅 테스트 클러스터에서 결과를 자동화하고 캡처합니다. 이를 통해 플래시 어레이 및 개별 스토리지 장치를 포함한 광범위한 스토리지 장치에서 동일한 워크로드를 반복할 수 있습니다.
프로필 :
- 4K 임의 읽기: 100% 읽기, 128 스레드, 0-120% iorate
- 4K 임의 쓰기: 100% 쓰기, 64 스레드, 0-120% iorate
- 64K 순차 읽기: 100% 읽기, 16 스레드, 0-120% iorate
- 64K 순차 쓰기: 100% 쓰기, 8개 스레드, 0-120% 속도
- 합성 데이터베이스: SQL 및 Oracle
A800과 함께 NVMeOF의 주요 성능 이점은 읽기 성능 향상과 대기 시간 감소입니다. 이전 테스트는 FCP 프로토콜을 사용하는 VMware 내부의 성능에 초점을 맞추고 VMDK가 여러 VM에 연결된 상태에서 NVMeOF 테스트는 베어 메탈 성능에 초점을 맞춥니다. 따라서 기존 데이터와 직접 일대일 비교를 할 수 없습니다. 또한 모든 스토리지 어레이에서 일관된 테스트를 위해 각 스토리지 어레이에 대해 스레드 수를 동일하게 유지했습니다. A800에 대한 NVMeOF 테스트를 통해 대기 시간이 크게 증가하기 전에 테스트가 완료된 일부 영역을 발견했습니다. 무엇보다도 이것은 플랫폼이 탁월한 성능을 발휘하여 인상적인 성능 통계에서 낮은 대기 시간을 유도하고 있음을 보여줍니다. 그러나 단점은 일정량의 성능이 테이블에 남아 있다는 것입니다. NetApp은 특정 상황에서 A800이 우리가 측정한 것보다 더 높은 성능을 발휘할 수 있다고 밝혔습니다.
4K 읽기부터 시작하여 NVMeOF가 있는 A800은 대기 시간이 217,460µs에 불과한 196.8 IOPS에서 시작하여 대기 시간이 2,184,220ms인 1.22 IOPS에서 정점에 도달했습니다.
4K 쓰기의 경우 어레이는 대기 시간 48,987µs의 196 IOPS에서 시작하여 대기 시간 465,445ms의 2.44 IOPS에서 정점에 도달했습니다.
다음은 64K 순차 워크로드입니다. 64K 읽기의 경우 A800은 약 403K IOPS 또는 25GB/s의 최대 성능과 800µs의 대기 시간으로 약간의 감소 전에 밀리초 미만의 대기 시간을 유지할 수 있었습니다.
64K의 경우 NVMeOF가 있는 A800이 강하게 시작하여 약 1K IOPS 또는 약 110GB/s까지 7ms 미만을 유지하고 120,314ms의 대기 시간으로 7.52 IOPS 또는 1.48GB/s에서 정점에 도달했습니다.
다음 벤치마크 배치는 SQL 테스트입니다. SQL에서 A800은 1µs의 대기 시간에서 1,466,467 IOPS의 인상적인 피크를 통해 전체적으로 496.6ms 미만을 유지했습니다.
SQL 90-10의 경우 NVMeOF가 탑재된 A800은 139,989 IOPS에서 시작하여 1,389,645 IOPS에서 최대 539.6 IOPS에 불과한 대기 시간이 XNUMXµs에 불과한 밀리초 미만의 대기 시간 성능을 또 한 번 인상적으로 실행했습니다.
SQL 80-20은 1,108,068µs 대기 시간에서 최고 658 IOPS로 다시 한 번 XNUMX밀리초 미만의 대기 시간을 보였습니다.
Oracle 워크로드로 이동하면 NVMeOF가 포함된 A800은 1µs의 대기 시간에서 최고 점수 1,057,570 IOPS로 860.4ms 미만을 유지했습니다.
Oracle 90-10은 A800이 118,586 IOPS에서 시작하여 1,140,178µs의 대기 시간에서 397.6 IOPS로 정점을 찍는 것을 확인했습니다.
Oracle 80-20에서 우리는 A800이 다시 한 번 104,206 IOPS에서 시작하여 1,003,577µs 대기 시간에서 468.8 IOPS로 정점에 도달하는 동안 지연 시간이 밀리초 미만인 것을 확인했습니다.
맺음말
NetApp AFF A800은 블록 및 파일 액세스는 물론 엔드 투 엔드 NVMe를 지원하는 4U 올플래시 어레이입니다. A800은 최대 316.8PB의 유효 용량을 제공하여 고성능과 대용량 스토리지가 필요한 까다로운 워크로드를 처리하는 사용자를 위해 설계되었습니다. 이전에 기존 파이버 채널을 사용한 리뷰에서 이 어레이를 자세히 살펴보았고 수상 경력도 있는 이번 리뷰에서는 NVMe over Fabric을 활용하여 성능을 분석합니다.
VDBench 워크로드의 경우 NetApp AFF A800은 전반적으로 인상적인 수치를 제공했습니다. 기본 네 모서리 실행에서 우리는 4만 IOPS 읽기 및 2.2K IOPS 쓰기의 무작위 465K 최고 성능을 확인했습니다. 순차 64K 워크로드에서 25GB/s 읽기 및 7.52GB/s 쓰기를 확인했습니다. SQL 워크로드에서 최고 1.5만 IOPS, SQL 90-10은 1.4만 IOPS, SQL 80-20은 1.1만 IOPS를 보였습니다. Oracle 테스트에서는 인상적인 1.1만 IOPS, Oracle 90-10은 1.14만 IOPS, Oracle 80-20은 1만 IOPS를 보였습니다. 더 인상적인 것은 SQL 및 Oracle 워크로드가 전체적으로 1ms 미만의 대기 시간을 유지한다는 것입니다.
NVMeOF용으로 구성된 A800에서 특히 읽기 성능 측면에서 훌륭한 결과를 보았지만 시스템이 여전히 더 많은 것을 제공할 수 있다는 점은 주목할 가치가 있습니다. 테스트에서 부하 생성 서버는 모두 VMware 하이퍼바이저 기반이었으며, 이는 또 다른 복잡성 계층을 추가합니다. 또한 VMware는 현재 NVMeOF를 완전히 지원하지 않습니다. NetApp 시스템과 함께 NVMeOF를 최대한 활용하려는 주류 기업의 경우 베어 메탈이 최고의 성능을 제공할 것입니다. 즉, 많은 사람들이 패브릭과 표준 파이버 채널 연결을 모두 사용하는 하이브리드 구성에서 NVMeOF ONTAP 시스템을 사용하기를 원할 것입니다. 두 경우 모두 NetApp은 고객이 필요로 하는 모든 것을 고객이 필요로 할 때마다 어레이를 준비할 수 있도록 최신 세대 기술을 채택 및 배포하는 측면에서 계속 선두를 달리고 있습니다. A800은 여기에서 특히 잘 작동하므로 초기 검토에서 Editor's Choice를 수상했습니다. NVMeOF는 비즈니스 크리티컬 애플리케이션을 위해 최대 처리량과 마이크로초 대기 시간이 필요한 기업에 어필할 수 있는 엄청난 성능 향상을 추가합니다.
아마존