NetApp AFF A800 검토

AFF A800은 NetApp의 최고급 ONTAP 올플래시 스토리지 어레이로 출시 당시 업계 최초로 32Gb FC를 통한 종단간 NVMe/FC와 100GbE 연결을 제공했습니다. 지금까지 강력한 AFF부터 시작하여 올플래시 AFF 라인업을 통해 작업해 왔습니다. A200 (이후 A220으로 대체됨) 뿐만 아니라 A300. 이전에 검토한 두 단위 모두 Editor's Choice 상을 받았습니다. 오늘 우리는 이전에 검토한 모델과 동일한 ONTAP 이점을 제공할 뿐만 아니라 기하급수적으로 더 빠른 성능과 더 낮은 대기 시간을 제공하는 NVMe 기반 A800 강국을 살펴볼 것입니다. 이 초기 리뷰는 파이버 채널을 통한 시스템 성능에 초점을 맞추고 있지만 후속 기사에서는 A800의 종단 간 NVMe over Fabrics(NVMeoF) 지원에 대해 자세히 설명합니다.

AFF A800은 NetApp의 최고급 ONTAP 올플래시 스토리지 어레이로 출시 당시 업계 최초로 32Gb FC를 통한 종단간 NVMe/FC와 100GbE 연결을 제공했습니다. 지금까지 강력한 AFF부터 시작하여 올플래시 AFF 라인업을 통해 작업해 왔습니다. A200 (이후 A220으로 대체됨) 뿐만 아니라 A300. 이전에 검토한 두 단위 모두 Editor's Choice 상을 받았습니다. 오늘 우리는 이전에 검토한 모델과 동일한 ONTAP 이점을 제공할 뿐만 아니라 기하급수적으로 더 빠른 성능과 더 낮은 대기 시간을 제공하는 NVMe 기반 A800 강국을 살펴볼 것입니다. 이 초기 리뷰는 파이버 채널을 통한 시스템 성능에 초점을 맞추고 있지만 후속 기사에서는 A800의 종단 간 NVMe over Fabrics(NVMeoF) 지원에 대해 자세히 설명합니다.

A200 및 A300은 미드레인지 시장의 서로 다른 부문을 위해 제작된 것과 달리 A800은 가장 높은 성능을 요구하는 워크로드(예: AI 및 Deep Leaning)를 위해 설계되었으며 ONTAP이 제공하는 강력한 엔터프라이즈 데이터 서비스 집합도 포함합니다. 알려진. 명확하게 말하자면 NetApp은 미드레인지와 같은 EF 올플래시 제품군에 진정으로 빠른 스토리지 시리즈를 보유하고 있습니다. EF570 우리는 이전에 검토했습니다. A800으로 돌아가서 NetApp은 시스템이 1.3μs 미만의 대기 시간과 HA 쌍으로 최대 500GB/s의 처리량으로 34만 IOPS를 달성할 수 있다고 주장합니다. 대규모로 이는 NAS 클러스터가 11.4ms 대기 시간과 1GB/s의 처리량에서 최대 300M IOPS를 제공할 수 있음을 의미합니다. SAN 클러스터는 7.8µs의 대기 시간과 500GB/s의 처리량에서 최대 204만 IOPS를 제공할 수 있습니다.

나머지 AFF A 시리즈 시스템과 마찬가지로 NVMe A800은 NAS 구성의 클러스터에서 24개(HA 쌍 12개) 4U 듀얼 컨트롤러 노드로 확장할 수 있습니다. 이것은 NVMe 기반 시스템이기 때문에 드라이브 스케일링과 관련하여 약간의 뉘앙스가 있습니다. 예를 들어 미드레인지 A300은 4608개의 드라이브를 지원하며 A800은 2880개를 지원합니다. 배포 시 기능 문제가 아닐 가능성이 높지만 JBOD 확장 선반을 고려할 때 NVMe 기반 시스템이 다른 엔지니어링 문제가 있음을 나타내기 위해 이 점을 강조합니다. SAS 기반 시스템이므로 제품 라인이 올라갈수록 모든 것이 커진다고 가정할 수는 없습니다. SAN 구성에서 NVMe A800은 12개의 드라이브를 지원하여 6개 노드(HA 쌍 1,440개)로 확장됩니다. 즉, 사용자가 15.3TB NVMe SSD를 활용하는 경우 2.5U 공간에서 최대 4PB까지 확장할 수 있습니다. 데이터 효율성이 활성화되면(5:1로 가정) A800은 315노드 NAS 클러스터에서 24PB 이상, SAN 클러스터에서 160TB 이상을 지원합니다.

NetApp은 다른 AFF 시스템에서 프런트 엔드 NVMe 지원을 활성화했지만 A800은 종단간 NVMe 지원을 제공합니다. 언급한 바와 같이, 이 리뷰에서는 이것이 무엇을 의미하는지 자세히 다루지 않을 것입니다. A800은 이를 달성한 최초의 올플래시 NVMe 어레이라고 해도 과언이 아닙니다. 사실상 이것이 의미하는 바는 조직이 오늘날 NVMeoF 기능의 새로운 물결을 활용하면서 FC를 통해 보다 전통적인 워크로드를 계속 서비스할 수 있다는 것입니다. 이전에는 NVMeoF를 활용하고자 하는 조직은 일반적으로 "과학 프로젝트" 유형의 배포로 분류되었으며, 빠르기는 하지만 규모와 데이터 서비스 측면에서 제한이 있었습니다. 여기에서 NetApp의 구현은 이러한 단점을 해결하는 동시에 FC와 이더넷 모두에서 표준 연결 옵션을 지원합니다.

물론 클라우드 연결성을 강조하지 않고는 A800을 말할 수 없습니다. NetApp 데이터 패브릭. ONTAP에 내재된 것은 선도적인 클라우드 제공업체에 대한 심층적인 연결성으로, 고객이 데이터를 A800의 로컬이든 다른 위치든 상관없이 가장 적합한 위치에 배치할 수 있도록 합니다. NetApp은 Amazon Web Services, Microsoft Azure, Google Cloud Platform 등과의 클라우드 및 다중 클라우드 연결을 지원합니다. 광범위한 클라우드 지원을 통해 NetApp 고객은 데이터 풋프린트를 관리할 때 필요한 유연성과 클라우드 경제성, 새로운 기능 또는 모양 유형 등을 활용하기 위해 필요에 따라 데이터를 이동할 수 있는 민첩성을 가질 수 있습니다.

우리의 특정 빌드는 ONTAP 800RC24이 설치된 컨트롤러당 연결된 1.92개의 32포트 8Gb FC 포트(총 9.5개 포트)가 있는 1개의 XNUMXTB NVMe SSD가 있는 AXNUMX으로 구성됩니다.

NetApp A800 사양

설계 및 구축

NetApp AFF A800은 AFF 시리즈의 나머지 제품과 모양이 매우 유사한 4U 어레이입니다. 환기 및 NetApp 브랜딩이 포함된 스타일리시한 베젤 아래에는 SSD용 파란색 2.5인치 드라이브 베이 XNUMX줄이 있습니다.

NVMe 드라이브 자체를 살펴보면 NetApp은 1.9TB, 3.8TB, 7.6TB 및 15.3TB SSD를 포함한 다양한 용량 옵션을 지원합니다. 이 글을 쓰는 시점에서 NetApp은 이러한 모든 드라이브를 AES-256 암호화가 적용된 자체 암호화(SED)로 제공하고 있습니다. 또한 ONTAP 9.4로 초기화된 시스템의 경우 빠른 드라이브 영점 조정이 활성화됩니다.

장치 뒷면을 뒤집으면 두 개의 컨트롤러가 있습니다. 하나는 미러 이미지처럼 다른 하나 위에 쌓입니다. 구성에는 연결을 위한 네 가지 스타일의 인터페이스가 포함됩니다. 이 32개의 카드는 가장 오른쪽 및 중간 PCIe 슬롯에 있습니다. 여기에는 쿼드 포트 25Gb FC 카드(왼쪽 상단), 듀얼 포트 100GbE 네트워킹 카드(왼쪽 하단), 듀얼 포트 10GbE 네트워킹 카드(오른쪽 상단) 및 쿼드 포트 XNUMXGbE 네트워킹 카드(오른쪽 하단)가 포함됩니다.

컨트롤러 중 하나를 제거하면 나머지 장치에 대한 연결과 컨트롤러 전면에 있는 팬을 볼 수 있습니다.

후면 컨트롤러를 살펴보면 왼쪽에는 각 컨트롤러에 대한 이중 중복 PSU와 HA 상호 연결 포트 및 클러스터 상호 연결 포트가 있습니다. 각 컨트롤러의 오른쪽 하단에는 1HA 및 클러스터 상호 연결 포트도 있습니다. 나머지 대부분은 네트워킹 포트 100GbE, 10GbE 또는 32Gb 파이버 채널 또는 구성에서와 같이 위의 일부 조합으로 채울 수 있는 PCIe 슬롯(3.0개)으로 채워집니다. 중간 하단에는 관리 포트와 XNUMX개의 USB XNUMX 포트가 있습니다.

컨트롤러는 매우 쉽게 열 수 있어 서비스가 매우 용이합니다.

CPU 20개, DIMM 슬롯 20개(RAM의 32GB DIMM XNUMX개로 채워짐), NVDIMM 슬롯 XNUMX개를 볼 수 있습니다. PCIe 네트워크 AIC도 여기에서 쉽게 액세스할 수 있습니다.

ONTAP GUI는 8.2 이전의 Java 지원 GUI에서 현대적이고 잘 설계된 웹 기반 ONTAP 9.5에 이르기까지 수년에 걸쳐 많은 발전을 이루었습니다. NetApp은 GUI를 크게 개선하여 일상적인 관리 기능 이상으로 GUI를 점점 더 유용하게 만들었습니다.

대시 보드 :

로그인하면 시스템에서 일어나는 일에 대한 빠른 요약을 제공하는 대시보드가 ​​표시됩니다. 대시보드는 당신이 볼 수 있는 한 매우 간단합니다. 각 위젯을 사용하면 경고, 성능, 용량, 효율성 및 보호를 빠르게 한 눈에 볼 수 있습니다. 보다 자세한 보기 및 장기 추세를 보려면 NetApp의(무료) OnCommand Unified Manager for ONTAP 메트릭을 사용하는 것이 좋습니다.

클라우드 계층:

NetApp Cloud 옵션 Fabric Pool을 추가하면 GUI를 통해 로컬 StorageGRID는 물론 NDAS를 포함한 퍼블릭 클라우드에 간단하게 연결할 수 있습니다.

SVM:

이 탭에서 ONTAP 클러스터의 모든 데이터 프로토콜 SVM을 생성, 편집, 삭제 및 시작/중지하고 다양한 설정을 편집할 수 있습니다.

집계 및 스토리지 풀:

Aggregate 및 Storage Pool 탭을 사용하면 Aggregate 및 Storage Pool을 간단하게 만들고 관리할 수 있습니다.

볼륨 및 LUN:

볼륨 및 LUN 관리 페이지에서는 FlexVol, FlexGroup 및 LUN, 심지어 각 SVM에 대한 igroup 및 매핑까지 다양한 생성 및 관리를 제공합니다.

QoS :

QoS는 수년간 ONTAP에서 큰 발전을 이루었습니다. 이제 각 워크로드에 대한 천장과 바닥을 구성할 수 있을 뿐만 아니라 변화하는 워크로드에 적응하도록 구성할 수 있습니다. QoS는 볼륨, 파일 및 LUN과 같은 ONTAP 내부의 다양한 개체와 기타 몇 가지 개체에 적용할 수 있습니다.

네트워크 구성:

IP 공간, 브로드캐스트 도메인, 포트, LIF, FC 및 이제 NVMe와 같은 모든 기본 네트워크 구성 및 관리가 GUI에 있습니다.

피어링:

ONTAP의 마지막 몇 가지 버전까지는 CLI를 통해서만 피어링 관계를 만들어야 했습니다. 그러나 이제 GUI에서도 클러스터 피어와 SVM 피어를 생성할 수 있습니다. 피어링을 구성하면 볼륨 생성 마법사에서 직접 SnapMirror 관계를 생성할 수도 있습니다.

클러스터 업데이트:

ONTAP 업그레이드는 점점 더 쉬워지고 있습니다. 작지만 매우 유용한 기능이 9.4에 추가되어 ONTAP 업데이트를 더욱 쉽게 수행할 수 있습니다. 우리 모두는 확실히 명령줄을 좋아하지만 이렇게 하면 고객과 파일을 업그레이드하기 위해 정말 쉽게 작업할 수 있습니다. 더 이상 http/ftp 서버를 망칠 필요가 없습니다. .tgz 파일을 직접 업로드하고 자동 클러스터 업데이트를 실행하기만 하면 됩니다.

퍼포먼스

성능을 위해 A800과 A300을 비교할 것입니다. 이것은 제품군 내에서 위로 올라갈수록 NetApp AFF 모델의 성능이 얼마나 잘 확장되는지를 보여주는 데 사용됩니다. 모든 테스트에서 데이터 축소 서비스를 활성화했습니다. 즉, 인라인 중복 제거 및 압축이 활성화되었습니다. 이전 리뷰에서 언급했듯이 NetApp ONTAP은 최소한의 오버헤드 또는 성능 영향으로 뛰어난 DR 기능을 제공합니다.

NetApp AFF A800의 구성에는 8개의 32TB NVMe SSD가 설치된 24개의 1.92Gb FC 포트가 포함되었습니다. A24에 배치된 1.92개의 800TB SSD 중에서 11개의 SSD를 사용하고 32개는 핫 스페어로 사용하는 두 개의 RAID-DP 집계로 분할했습니다. 어레이는 620개의 Brocade G16 스위치를 통해 16Gb를 통해 연결되었으며 Dell PowerEdge R740xd 서버에 대한 XNUMX개의 XNUMXGb 링크가 있었습니다.

VDbench와 Sysbench를 사용하는 합성 벤치마크의 경우 컨트롤러와 디스크 그룹 모두에 고르게 분산된 32개의 600GB 볼륨을 프로비저닝했습니다. SQL Server의 경우 벤치마킹에 사용되는 VM을 보관하기 위해 컨트롤러당 1.1개씩 총 50개의 XNUMXTB 볼륨을 추가로 사용했습니다. 데이터 감소가 고려된 후 테스트 중에 사용된 총 공간은 각 집계에 대해 XNUMX% 미만의 사용률에 달했습니다.

SQL 서버 성능

StorageReview의 Microsoft SQL Server OLTP 테스트 프로토콜은 복잡한 애플리케이션 환경에서 발견되는 활동을 시뮬레이션하는 온라인 트랜잭션 처리 벤치마크인 TPC-C(Transaction Processing Performance Council의 Benchmark C)의 최신 초안을 사용합니다. TPC-C 벤치마크는 합성 성능 벤치마크보다 데이터베이스 환경에서 스토리지 인프라의 성능 강점과 병목 현상을 측정하는 데 더 가깝습니다.

각 SQL Server VM은 100개의 vDisk(부팅용 500GB 볼륨, 데이터베이스 및 로그 파일용 16GB 볼륨)로 구성됩니다. 시스템 리소스 관점에서 각 VM을 vCPU 64개, DRAM XNUMXGB로 구성하고 LSI Logic SAS SCSI 컨트롤러를 활용했습니다. Sysbench 워크로드가 이전에 스토리지 I/O 및 용량 모두에서 플랫폼을 포화 상태로 테스트한 반면 SQL 테스트는 대기 시간 성능을 찾습니다.

이 테스트는 Windows Server 2014 R2012 게스트 VM에서 실행되는 SQL Server 2를 사용하며 Dell의 Benchmark Factory for Databases에서 강조합니다. 이 벤치마크의 기존 사용은 로컬 또는 공유 스토리지에서 대규모 3,000개 규모의 데이터베이스를 테스트하는 것이었지만, 이 반복에서는 1,500개 규모의 데이터베이스 XNUMX개를 서버 전체에 고르게 분산시키는 데 중점을 둡니다.

SQL Server 테스트 구성(VM당)

• 윈도우 서버 2012 R2
• 스토리지 공간: 600GB 할당, 500GB 사용
• SQL 서버 2014
  • 데이터베이스 크기: 1,500 규모
  • 가상 클라이언트 로드: 15,000
  • RAM 버퍼: 48GB
• 시험 시간: 3시간
  • 2.5시간 전처리
  • 30분 샘플 기간

SQL Server 트랜잭션 성능의 경우 A800은 개별 VM이 12,635.5 TPS에서 3,158.6 TPS로 실행되는 총 점수가 3,159.3 TPS였습니다(A300의 12,628.7 TPS 및 A200의 12,583.8 TPS에 비해 약간 증가).

SQL Server 평균 대기 시간을 살펴보면 A800에서 총 5ms, 모든 VM에서 5ms로 떨어졌기 때문에 더 크게 향상되었습니다(A300의 8ms 및 A200의 25ms보다 훨씬 좋음).

시스벤치 MySQL 성능

첫 번째 로컬 스토리지 애플리케이션 벤치마크는 SysBench를 통해 측정된 Percona MySQL OLTP 데이터베이스로 구성됩니다. 이 테스트는 평균 TPS(Transactions Per Second), 평균 대기 시간 및 평균 99번째 백분위수 대기 시간도 측정합니다.

각 Sysbench VM은 92개의 vDisk로 구성됩니다. 하나는 부팅용(~447GB), 하나는 사전 구축된 데이터베이스(~270GB), 세 번째는 테스트 중인 데이터베이스용(16GB)입니다. 시스템 리소스 관점에서 각 VM을 vCPU 60개, DRAM XNUMXGB로 구성하고 LSI Logic SAS SCSI 컨트롤러를 활용했습니다.

Sysbench 테스트 구성(VM당)

• 센트OS 6.3 64비트
• 페르코나 XtraDB 5.5.30-rel30.1
  • 데이터베이스 테이블: 100
  • 데이터베이스 크기: 10,000,000
  • 데이터베이스 스레드: 32
  • RAM 버퍼: 24GB
• 시험 시간: 3시간
  • 2시간 동안 32개 스레드 사전 조정
  • 1시간 32 스레드

Sysbench의 경우 8, 16, 32를 포함한 여러 세트의 VM을 테스트했으며 두 데이터 축소를 "켜기" 상태로 Sysbench를 실행했습니다. A800은 15,750.8VM에서 8TPS, 22,170.9VM에서 16 TPS, 44,149.8VM에서 32 TPS를 기록할 수 있었습니다. 이는 A300이 32VM, 22,313 TPS로 한 것보다 거의 두 배에 가까운 이전보다 훨씬 높습니다.

Sysbench 평균 대기 시간에서 A800은 16.3VM에서 8ms, 23.1VM에서 16ms, 23.2VM에서 32ms를 기록했습니다. 이것은 작은 AFF 모델보다 훨씬 낫습니다.

최악의 시나리오(99번째 백분위수)에서 A800은 31.3VM의 경우 8ms, 48.5VM의 경우 16ms, 48.1VM의 경우 32ms를 기록했습니다.

VDBench 워크로드 분석

스토리지 어레이를 벤치마킹할 때는 애플리케이션 테스트가 가장 좋고 합성 테스트가 두 번째입니다. 실제 워크로드를 완벽하게 나타내지는 못하지만 합성 테스트는 경쟁 솔루션 간의 비교를 쉽게 수행할 수 있는 반복성 요소로 스토리지 장치의 기준선을 만드는 데 도움이 됩니다. 이러한 워크로드는 "포 코너" 테스트, 공통 데이터베이스 전송 크기 테스트, 다양한 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
• VDI 전체 클론 및 연결된 클론 추적

피크 임의 4K 읽기 성능으로 시작하여 A800은 118,511μs의 대기 시간으로 217.5 IOPS에서 시작했습니다. A800은 약 1만 IOPS에 도달할 때까지 1.07ms 미만을 유지했으며 1,219.829ms의 대기 시간에서 3.3 IOPS로 정점에 도달했습니다. 이는 대기 시간이 300ms인 A635,342의 최고 성능인 6.4 IOPS와 비교할 때 현저한 차이입니다.

4K 쓰기 성능을 살펴보면 A800은 45,676μs의 대기 시간으로 213.1 IOPS에서 시작했습니다. A800은 약 410K IOPS까지 439밀리초 미만의 대기 시간 성능을 보였고 약 4.4K IOPS에서 300ms 대기 시간으로 정점에 도달한 후 일부 감소했습니다. 대조적으로 A208,820은 9.72ms의 대기 시간으로 XNUMX IOPS의 최고 성능을 보였습니다.

순차 워크로드로 전환하여 최대 64K 읽기 성능을 살펴보고 여기서 A800은 29,589μs의 대기 시간으로 1.85 IOPS 또는 166.1GB/s에서 시작했습니다. A300은 약 300K IOPS 또는 18.5GB/s까지 302,668밀리초 미만의 지연 시간을 가졌고, 18.9ms 지연 시간에서 1.7 IOPS 또는 300GB/s로 정점에 도달했습니다. A84,766은 약 5.71K IOPS 또는 3.64GB/s에서 정점을 찍고 XNUMXms 대기 시간이 조금 떨어졌습니다.

64K 순차 쓰기 성능의 경우 A800은 대기 시간이 8,103μs인 506.4 IOPS 또는 304.8MB/s에서 시작했습니다. 어레이는 실행이 끝날 때까지 1ms 미만 또는 약 80K IOPS 또는 5GB/s를 유지했으며 80,536ms의 대기 시간과 함께 5.03 IOPS 또는 3.1GB/s에서 정점에 도달했습니다. 최고의 성능을 위해 A300은 48,883ms의 대기 시간에서 3.1 IOPS 또는 4.8GB/s를 기록했습니다.

다음 벤치마크 배치는 SQL 테스트입니다. SQL에서 A800은 대기 시간이 138,007μs인 255.2 IOPS에서 시작하여 약 650K IOPS까지 밀리초 미만의 대기 시간을 가지며, 697,603ms의 대기 시간에서 1.5 IOPS로 정점에 도달했습니다. 이는 대기 시간이 300ms인 A488,488의 최대 2.1 IOPS와 비교됩니다.

SQL 90-10에서 A800은 70,867μs의 대기 시간에서 277.3 IOPS로 시작하여 약 1K IOPS까지 640ms 미만을 유지했으며, 730,567ms의 대기 시간으로 1.4 IOPS에서 정점에 도달했습니다. 반면 A300은 416,370ms의 대기 시간으로 2.46 IOPS의 최고 성능을 보였습니다.

SQL 80-20의 경우 A800은 대기 시간 56,391μs에서 256.6 IOPS에서 시작했으며 대기 시간은 약 480K IOPS까지 밀리초 미만이었습니다. A800은 623,557ms의 대기 시간으로 1.6 IOPS에서 정점을 찍었습니다. 이는 대기 시간이 300ms인 A360,642의 2.82 IOPS의 약 두 배입니다.

Oracle 워크로드로 이동하면 A800이 64,020 IOPS에서 254.7μs 대기 시간으로 시작하여 약 1K IOPS까지 470ms 미만으로 유지되는 것을 확인했습니다. A800은 656,438ms의 대기 시간에서 1.9 IOPS로 정점을 찍었습니다. 다시 말하지만, A800은 A300의 340,391 IOPS 점수보다 거의 두 배의 성능과 3.6ms의 대기 시간을 가졌습니다.

Oracle 90-10에서 A800은 75,710 IOPS 및 242.5μs 대기 시간에서 시작했습니다. 어레이는 대기 시간이 759,117ms인 A839.2의 최대 300 IOPS에서 크게 향상된 417,869μs 대기 시간에서 1.53 IOPS로 정점을 찍는 XNUMX밀리초 미만의 대기 시간 성능을 전체적으로 관리했습니다.

Oracle 80-20과 함께 A800은 65,505μs 대기 시간에서 254.5 IOPS에서 시작하여 666,556μs에서 943.1 IOPS에서 최대 300밀리초 미만의 대기 시간 성능을 유지했습니다. A362,499은 최고 1.62 IOPS와 XNUMXms의 대기 시간을 기록했습니다.

다음으로 VDI 클론 테스트, 전체 및 연결로 전환했습니다. VDI 전체 복제 부팅의 경우 A800은 약 535K IOPS까지 밀리초 미만의 대기 시간을 가졌고 대기 시간이 579,786ms인 1.8 IOPS에서 정점에 도달했습니다. A300은 지연 시간이 300,128ms인 3.46 IOPS로 정점을 찍었습니다.

VDI 전체 복제 초기 로그인을 통해 A800은 약 1 IOPS까지 200ms 미만을 유지했고 254,888ms 대기 시간으로 최고 3.5 IOPS를 기록했습니다. 이것은 300ms의 대기 시간과 함께 123,984 IOPS에서 정점에 도달한 A7.26과 대조됩니다.

VDI FC 월요일 로그인은 A800이 약 180K IOPS까지 밀리초 미만의 대기 시간 성능과 228,346ms의 대기 시간으로 최대 2.2 IOPS를 보여주었습니다. 이것은 대기 시간이 300ms인 A131,628의 3.89 IOPS를 크게 뛰어넘은 것입니다.

부팅 테스트에서 VDI LC(Linked Clone)로 전환하면 A800은 거의 전체에 걸쳐 대기 시간이 1ms 미만이었으며 약 1K IOPS에서 440ms 장벽을 깨고 460,366ms의 대기 시간으로 1.1 IOPS에서 정점에 도달했습니다. A300은 215,621ms의 대기 시간과 함께 2.28 IOPS로 정점을 찍었습니다.

VDI LC 초기 로그인에서 A800은 다시 약 158K IOPS까지 166,224밀리초 미만의 긴 대기 시간을 가졌으며, 1.5ms의 대기 시간에서 300 IOPS로 정점에 도달했습니다. 이는 대기 시간이 95,296ms인 A2.68의 최대 XNUMX IOPS와 비교됩니다.

마지막으로, A800이 15,287μs의 지연 시간에 299.3 IOPS에서 시작한 VDI LC 월요일 로그인을 살펴봅니다. 어레이는 약 1K IOPS까지 130ms 미만으로 유지되었고 164,684ms의 대기 시간에서 3.1 IOPS로 정점에 도달했습니다. A300은 94,722ms의 대기 시간과 함께 5.4 IOPS로 정점을 찍었습니다.

결론 

NetApp AFF A800은 최고의 성능을 제공하는 4U 올플래시 스토리지 어레이입니다. A800은 모든 NVMe 플래시와 함께 제공되며 가장 까다로운 워크로드를 목표로 합니다. 모든 NVMe(및 각각 최대 15.3TB 용량의 NVMe SSD)를 지원하는 것 외에도 AFF A800에는 성능이 절대적으로 필요한 경우를 위한 100GbE 연결 옵션도 있습니다. NetApp에 ​​따르면 AFF A800은 1.4μs 미만의 대기 시간에서 500만 IOPS를 달성할 수 있어야 합니다. A 시리즈의 다른 NetApp 어레이와 마찬가지로 A800은 ONTAP에 의해 구동됩니다.

성능을 위해 SQL Server와 Sysbench로 구성된 애플리케이션 분석 워크로드와 VDBench 워크로드를 모두 실행했습니다. 애플리케이션 워크로드 분석에서 A800은 총 12,835.5 TPS의 트랜잭션 SQL Server 점수와 5ms의 평균 대기 시간을 가졌습니다. 이것은 A300의 12,628.7 TPS 및 평균 대기 시간 8ms에서 성능이 크게 향상되었습니다. Sysbench에서 A800은 15,750.8VM의 경우 8TPS, 22,170.9VM의 경우 16 TPS, 44,149.8VM의 경우 32 TPS를 제공했으며 평균 대기 시간은 16.3VM의 경우 8ms, 23.1VM의 경우 16ms, 23.2VM의 경우 32ms이고 최악의 시나리오 대기 시간은 31.3VM의 경우 8ms, 48.5VM의 경우 16ms, 48.1VM의 경우 32ms입니다. 경우에 따라 A800은 대기 시간을 대략 절반으로 줄이면서 TPS를 두 배로 늘릴 수 있었습니다.

VDBench 워크로드의 경우 NetApp AFF A800이 계속 빛을 발했습니다. 하이라이트는 1.2K 읽기에서 4만 IOPS, 439K 쓰기에서 4K IOPS, 순차 18.9K 읽기에서 64GB/s, 5.03K 쓰기에서 64GB/s입니다. 이 숫자는 모두 5ms 미만의 지연 시간에 적중되었습니다. SQL 테스트에서 어레이는 SQL 698-731에서 90K IOPS, 10K IOPS, SQL 624-80에서 20K IOPS를 기록했습니다. Oracle에서 A800은 656K IOPS를 기록했고 Oracle 90-10과 Oracle 80-20 모두에서 어레이는 각각 759K IOPS와 667K IOPS의 최대 점수로 밀리초 미만의 지연 시간을 가졌습니다. VDI 클론 테스트에서 A800은 전체 클론의 경우 580K IOPS, 연결된 클론의 경우 460K IOPS의 부팅 점수를 달성할 수 있었습니다. 모든 테스트에서 가장 높은 최대 대기 시간은 4.4ms에 불과했습니다.

우리가 이전에 검토한 미드마켓 ONTAP 시스템과 마찬가지로 NetApp은 엔터프라이즈 중심의 A800으로 다시 한 번 성공했습니다. 성능 프로필은 매우 강력하여 ONTAP 제품군의 최상위 위치를 차지합니다. 언급한 바와 같이 이 테스트는 다양한 파이버 채널 작업입니다. 우리는 아직 껍질을 벗기지 않았습니다 NVMeoF 구성에서 사용할 수 있는 것, 재미있을 것입니다. 검토를 위해 하드웨어를 검토할 때 오래된 스토리지 공급업체가 신생 기업만큼 빠르고 유연하지 않으며 "레거시 코드"가 보조를 맞출 수 없다는 사소한 우려가 때때로 있습니다. NetApp 포트폴리오 어디에서도 이러한 문제의 징후를 볼 수 없으며 A800은 수년 동안 ONTAP에 내재된 데이터 보호 및 가용성 기능을 희생하지 않고 기업에 실용적인 방식으로 NVMe 및 NVMeoF를 수용합니다. NetApp은 A800의 NVMe를 훌륭하게 처리하고 있습니다. 우리는 이러한 학습이 다른 어레이 전체에서 어떻게 적용되는지 보고 싶습니다.

NetApp AFF 시리즈

이 리뷰에 대해 토론하기

StorageReview 뉴스레터 신청