NetApp AFF A800 レビュー

AFF A800 は、NetApp の最上位の ONTAP オールフラッシュ ストレージ アレイで、発売時には業界初の 32Gb FC を介したエンドツーエンドの NVMe/FC と 100GbE 接続を提供しました。これまで、私たちはオールフラッシュ 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 ラインナップの開発に取り組んできました。 A200 (その後 A220 に置き換えられました) A300。以前レビューしたユニットはどちらも Editor’s Choice 賞を受賞しました。今日は、以前にレビューしたモデルと同じ ONTAP の利点に加え、飛躍的に高速なパフォーマンスと低遅延を提供する NVMe ベースの A800 の強力な製品について説明します。この最初のレビューではファイバー チャネル経由のシステム パフォーマンスに焦点を当てていますが、その後の記事では A800 のエンドツーエンドの NVMe over Fabrics (NVMeoF) サポートについて詳しく説明します。

ミッドレンジ市場のさまざまなセグメント向けに構築された A200 および A300 とは異なり、A800 は、最もパフォーマンスを必要とするワークロード (AI やディープ ラーニングなど) 向けに設計されていると同時に、ONTAP の堅牢なエンタープライズ データ サービス セットも含まれています。で知られている。明確にしておきますが、NetApp にはミッドレンジなど、EF オールフラッシュ ファミリの一連の真の高速ストレージがあります。 EF570 以前レビューしました。 A800 の話に戻りますが、NetApp は、このシステムは 1.3 μs 未満のレイテンシで 500 万 IOPS に達し、HA ペアを使用すると最大 34 GB/s のスループットを達成できると主張しています。これは、NAS クラスタが 11.4 ミリ秒のレイテンシで最大 1 万 IOPS、300 GB/秒のスループットを実現できることを意味します。 SAN クラスタは、7.8 マイクロ秒のレイテンシと 500 GB/秒のスループットで最大 204 万 IOPS を実現できます。

他の AFF A シリーズ システムと同様に、NVMe A800 は、NAS 構成のクラスター内で 24 (12 HA ペア) の 4U デュアル コントローラー ノードまで拡張できます。これは NVMe ベースのシステムであるため、ドライブのスケーリングに関しては若干のニュアンスが異なります。たとえば、ミッドレンジ A300 は 4608 ドライブをサポートしており、A800 は最高で 2880 ドライブです。展開時に機能上の問題になる可能性は高くありませんが、JBOD 拡張シェルフを検討する場合、NVMe ベースのシステムには異なるエンジニアリング上の課題があることを示すためにこれを強調しています。 SAS ベースのシステムなので、製品ラインが上がるにつれてすべてが大きくなると単純に想定することはできません。 SAN 構成では、NVMe A800 は 12 台のドライブをサポートし、6 ノード (1,440 HA ペア) まで拡張できます。つまり、ユーザーが 15.3TB NVMe SSD を利用する場合、2.5U の設置面積で最大 4PB まで拡張できます。データ効率が有効になっている場合 (5:1 を想定)、A800 は 315 ノードの NAS クラスターで 24PB 以上、SAN クラスターで 160TB 以上をサポートします。

NetApp は他の AFF システムでフロントエンド NVMe サポートを有効にしていますが、A800 はいわゆるエンドツーエンド NVMe サポートを提供します。前述したように、このレビューではこれが何を意味するかについて深く掘り下げるつもりはありません。 A800 はこれを実現した最初のオールフラッシュ NVMe アレイであると言えば十分でしょう。これは事実上、組織が FC 経由で従来のワークロードを処理しながら、今日の NVMeoF 機能の新たな波を活用できることを意味します。以前は、NVMeoF を活用したい組織は、一般的に「サイエンス プロジェクト」タイプの導入に追いやられていました。この導入は高速ではあるものの、規模やデータ サービスに関しては制限がありました。ここでの NetApp の実装は、これらの欠点に対処すると同時に、FC とイーサネットの両方の標準接続オプションのサポートも提供します。

もちろん、クラウド接続と ネットアップ データ ファブリック。 ONTAP には主要なクラウド プロバイダーへの強力な接続が備わっており、これにより、顧客はローカルの A800 上でも、他の場所でも、最も意味のある場所にデータを配置できます。 NetApp は、アマゾン ウェブ サービス、Microsoft Azure、Google Cloud Platform などとのクラウドおよびマルチクラウド接続をサポートしています。広範なクラウド サポートにより、ネットアップのお客様は、データ フットプリントを管理する際に必要な柔軟性と、クラウドの経済性、新機能や形状タイプなどを活用するために必要に応じてデータを移動する機敏性を得ることができます。

当社の特定のビルドは、ONTAP 800RC24 がインストールされたコントローラーごとに接続された 1.92 つの 32 ポート 8Gb FC ポート (合計 9.5​​ ポート) を備えた 1 x XNUMXTB NVMe SSD を備えた AXNUMX で構成されています。

NetApp A800の仕様

設計と構築

NetApp AFF A800 は、AFF シリーズの他のアレイと非常に似た外観を持つ 4U アレイです。通気口と NetApp ブランドを備えたスタイリッシュなベゼルの下には、SSD 用の青い 2.5 インチ ドライブ ベイが XNUMX 列あります。

NVMe ドライブ自体を見ると、ネットアップは 1.9 TB、3.8 TB、7.6 TB、15.3 TB SSD などの幅広い容量オプションをサポートしています。この記事の執筆時点では、ネットアップはこれらすべてのドライブを AES-256 暗号化による自己暗号化 (SED) として出荷しています。さらに、ONTAP 9.4 で初期化されたシステムでは、高速ドライブ ゼロ調整が有効になります。

デバイスの背面にひっくり返すと、32 つのコントローラーがあり、25 つは鏡像のようにもう 100 つのコントローラーの上に積み重ねられています。私たちの構成には、接続用の 10 つの異なるスタイルのインターフェイスが含まれています。これら XNUMX つのカードは、右端と中央の PCIe スロットにあります。これらには、クアッド ポート XNUMXGb FC カード (左上)、デュアル ポート XNUMXGbE ネットワーク カード (左下)、デュアル ポート XNUMXGbE ネットワーク カード (右上)、およびクアッド ポート XNUMXGbE ネットワーク カード (右下) が含まれます。

コントローラーの 1 つを取り外すと、残りのユニットへの接続と、コントローラーの前面に並んでいるファンが見えます。

背面コントローラーに目を向けると、左側には各コントローラーにデュアル冗長 PSU、HA インターコネクト ポート、クラスター インターコネクト ポートがあります。各コントローラーの右下には、1HA およびクラスター相互接続ポートもあります。残りの大部分は、ネットワーク ポート 100GbE、10GbE、または 32Gb ファイバー チャネル、またはこの構成のように上記の組み合わせを装着できる PCIe スロット (3.0 つ) で占められています。中央下部には管理ポートと XNUMX つの USB XNUMX ポートがあります。

コントローラーは驚くほど簡単に開けられるので、非常に使いやすいです。

20 つの CPU、20 個の DIMM スロット (32 x XNUMXGB DIMM の RAM が装着されている)、および XNUMX つの NVDIMM スロットが表示されます。 PCIe ネットワーク AIC にもここから簡単にアクセスできます。

マネジメント

ONTAP GUI は、8.2 以前の Java 対応 GUI から、最新の適切に設計された Web ベースの ONTAP 9.5 まで、長年にわたって大きな進歩を遂げてきました。 NetApp は GUI を大幅に強化し、日常的な管理機能以外にも使いやすくなりました。

ダッシュボード：

ログインすると、システムで何が起こっているかの概要を示すダッシュボードが表示されます。ダッシュボードは、目に見える範囲では非常に簡単です。各ウィジェットを使用すると、アラート、パフォーマンス、容量、効率、保護を一目で確認できます。さらに詳細な表示と長期的な傾向を確認するには、NetApp の (無料) OnCommand Unified Manager for ONTAP メトリクスを使用することをお勧めします。

クラウド層:

NetApp Cloud オプションの Fabric Pool の追加により、GUI により、NDAS やローカル StorageGRID などのパブリック クラウドへの接続が簡単になります。

SVM:

このタブからは、ONTAP クラスタ上のすべてのデータ プロトコル SVM の作成、編集、削除、開始/停止や、さまざまな設定の編集ができます。

アグリゲート プールとストレージ プール:

[アグリゲート] タブと [ストレージ プール] タブを使用すると、アグリゲートとストレージ プールの作成と管理を簡単に行うことができます。

ボリュームとLUN:

ボリュームと LUN の管理ページでは、FlexVol、FlexGroups、LUN、さらには各 SVM の igroup やマッピングなど、さまざまな作成と管理を行うことができます。

QoS：

ONTAP では長年にわたって QoS が大幅に進歩しており、ワークロードごとに上限と下限を設定できるだけでなく、変化するワークロードに適応するように設定できるようになりました。 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 台がホット スペアとして、620 つの RAID-DP アグリゲートに分割されました。アレイは 16 台の Brocade G16 スイッチを介して 740Gb で接続され、その後、Dell PowerEdge RXNUMXxd サーバーへの XNUMX 個の XNUMXGb リンクがありました。

VDbench と Sysbench を使用した合成ベンチマークでは、コントローラーとディスク グループの両方に均等に分散された 32 の 600 GB ボリュームをプロビジョニングしました。 SQL Server の場合、ベンチマークに使用する VM を保持するために、コントローラーごとに 1.1 つずつ、さらに 50 つの XNUMXTB ボリュームを使用しました。データ削減を考慮すると、テスト中に使用された合計フットプリントは、各集計の使用率が XNUMX% 弱に達しました。

SQLサーバーのパフォーマンス

StorageReview の Microsoft SQL Server OLTP テスト プロトコルは、複雑なアプリケーション環境で見られるアクティビティをシミュレートするオンライン トランザクション処理ベンチマークである、トランザクション処理パフォーマンス評議会のベンチマーク C (TPC-C) の現在のドラフトを採用しています。 TPC-C ベンチマークは、データベース環境におけるストレージ インフラストラクチャのパフォーマンスの強みとボトルネックを測定するのに、合成パフォーマンス ベンチマークよりも近くなります。

各 SQL Server VM は 100 つの vDisk で構成されています。ブート用の 500 GB ボリュームと、データベースとログ ファイル用の 16 GB のボリュームです。システム リソースの観点から、各 VM に 64 個の vCPU、XNUMX GB の DRAM を構成し、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 ごと)

• Windows Serverの2012 R2
• ストレージ フットプリント: 600GB 割り当て、500GB 使用
• SQL Serverの2014
  • データベースのサイズ: 1,500 スケール
  • 仮想クライアント負荷: 15,000
  • RAMバッファ: 48GB
• テスト時間: 3 時間
  • 2.5時間のプレコンディショニング
  • 30 分のサンプル期間

SQL Server のトランザクション パフォーマンスについては、A800 の合計スコアは 12,635.5 TPS で、個々の VM は 3,158.6 TPS から 3,159.3 TPS で実行されました（A300 の 12,628.7 TPS や A200 の 12,583.8 TPS をわずかに上回っています）。

SQL Server の平均レイテンシを見ると、A800 では合計 5 ミリ秒、すべての VM で 5 ミリ秒まで低下し、大幅な改善が見られます (A300 の 8 ミリ秒や A200 の 25 ミリ秒よりもはるかに優れています)。

Sysbench MySQL のパフォーマンス

最初のローカル ストレージ アプリケーション ベンチマークは、SysBench 経由で測定された Percona MySQL OLTP データベースで構成されています。このテストでは、平均 TPS (99 秒あたりのトランザクション数)、平均レイテンシ、平均 XNUMX パーセンタイル レイテンシも測定します。

各 Sysbench VM は 92 つの vDisk で構成されています。447 つはブート用 (~270 GB)、16 つは事前構築済みデータベース (~60 GB)、XNUMX 番目はテスト対象データベース用 (XNUMX GB) です。システム リソースの観点から、各 VM に XNUMX 個の vCPU、XNUMX GB の DRAM を構成し、LSI Logic SAS SCSI コントローラーを活用しました。

Sysbench テスト構成 (VM ごと)

• CentOS 6.3 64 ビット
• Percona 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 のほぼ XNUMX 倍です。

Sysbench の平均レイテンシでは、A800 は 16.3VM で 8 ミリ秒、23.1VM で 16 ミリ秒、23.2VM で 32 ミリ秒に達しました。これは、小型の AFF モデルよりもはるかに優れています。

最悪のシナリオ (99 パーセンタイル) の遅延では、A800 は 31.3VM で 8 ミリ秒、48.5VM で 16 ミリ秒、48.1VM で 32 ミリ秒に達しました。

VDBench ワークロード分析

ストレージ アレイのベンチマークに関しては、アプリケーション テストが最適であり、合成テストは 2 番目になります。実際のワークロードを完全に表現しているわけではありませんが、合成テストは、競合ソリューション間での完全な比較を容易にする再現性係数を備えたストレージ デバイスのベースラインを確立するのに役立ちます。これらのワークロードは、「4 コーナー」テスト、一般的なデータベース転送サイズ テスト、さまざまな VDI 環境からのトレース キャプチャに至るまで、さまざまなテスト プロファイルを提供します。これらのテストはすべて、スクリプト エンジンを備えた共通の vdBench ワークロード ジェネレーターを利用して、大規模なコンピューティング テスト クラスターの結果を自動化して取得します。これにより、フラッシュ アレイや個々のストレージ デバイスを含む幅広いストレージ デバイスにわたって同じワークロードを繰り返すことができます。

プロフィール：

• 4K ランダム読み取り: 100% 読み取り、128 スレッド、0 ～ 120% の読み取り
• 4K ランダム書き込み: 100% 書き込み、64 スレッド、0 ～ 120% の書き込み
• 64K シーケンシャル読み取り: 100% 読み取り、16 スレッド、0 ～ 120% の iorate
• 64K シーケンシャル書き込み: 100% 書き込み、8 スレッド、0 ～ 120% iorate
• 合成データベース: SQL および Oracle
• VDI フル クローンおよびリンク クローン トレース

A4 は、ランダム 800K 読み取りのピーク パフォーマンスから始まり、レイテンシー 118,511 μs で 217.5 IOPS でスタートしました。 A800 は、約 1 万 IOPS に達するまで 1.07 ミリ秒未満に留まり、その後 1,219.829 ミリ秒の遅延で 3.3 IOPS のピークに達しました。これは、A300 のピーク パフォーマンスである 635,342 IOPS、レイテンシ 6.4 ミリ秒と比較すると、顕著な違いでした。

4K 書き込みパフォーマンスを見ると、A800 は 45,676 IOPS で開始し、レイテンシーは 213.1μs でした。 A800 は、約 410 IOPS まではミリ秒未満の遅延パフォーマンスを示し、その後、遅延が 439 ミリ秒で約 4.4 IOPS でピークに達し、その後若干低下しました。対照的に、A300 のピーク パフォーマンスは 208,820 IOPS、遅延は 9.72 ミリ秒でした。

シーケンシャル ワークロードに切り替えて、ピーク 64K 読み取りパフォーマンスを調べます。ここでは、A800 は 29,589 IOPS または 1.85GB/s で開始し、レイテンシは 166.1μs でした。 A300 の遅延は約 300K IOPS または 18.5GB/s まではミリ秒未満でしたが、その後 302,668ms の遅延で 18.9 IOPS または 1.7GB/s でピークに達しました。 A300 は、ピーク時に約 84,766K IOPS、つまり 5.71GB/秒、レイテンシ 3.64ms に達し、その後少し低下しました。

64K シーケンシャル書き込みパフォーマンスの場合、A800 は 8,103 IOPS または 506.4MB/s で開始し、遅延は 304.8μs でした。アレイは実行が終了するまで 1 ミリ秒未満、つまり約 80 IOPS または 5GB/秒に留まり、その後 80,536 ミリ秒の遅延で 5.03 IOPS または 3.1GB/秒のピークに達しました。ピークパフォーマンスでは、A300 は 48,883ms の遅延で 3.1 IOPS または 4.8GB/s に達しました。

次のベンチマークは SQL テストです。 SQL では、A800 は 138,007 μs のレイテンシで 255.2 IOPS で開始し、約 650 IOPS まではミリ秒未満のレイテンシを持ち、その後 697,603 ミリ秒のレイテンシで 1.5 IOPS でピークに達しました。これは、A300 のピーク 488,488 IOPS、遅延 2.1 ミリ秒と比較されます。

SQL 90-10 では、A800 は 70,867μs のレイテンシで 277.3 IOPS で開始し、約 1K IOPS まで 640ms 未満に留まり、その後 730,567ms のレイテンシで 1.4 IOPS でピークに達しました。一方、A300 のピーク パフォーマンスは 416,370 IOPS、遅延は 2.46 ミリ秒でした。

SQL 80-20 の場合、A800 は 56,391μs のレイテンシで 256.6 IOPS で開始し、約 480K IOPS まではミリ秒未満のレイテンシでした。 A800 は、レイテンシー 623,557 ミリ秒で 1.6 IOPS に達し、ピークに達しました。これは、A300 の 360,642 ミリ秒のレイテンシでの 2.82 IOPS の約 XNUMX 倍です。

Oracle ワークロードに移ると、A800 は 64,020 IOPS で 254.7 μs のレイテンシで開始し、約 1 IOPS まで 470 ミリ秒未満に留まりました。 A800 は、656,438 ミリ秒の遅延で 1.9 IOPS に達しました。繰り返しますが、A800 は、300 ミリ秒の遅延で 340,391 IOPS という A3.6 のスコアのほぼ XNUMX 倍のパフォーマンスを実現しました。

Oracle 90-10 では、A800 は 75,710 IOPS および 242.5μs のレイテンシで起動しました。このアレイは全体を通してミリ秒未満のレイテンシ パフォーマンスを管理し、レイテンシ 759,117 μs でピーク 839.2 IOPS に達しました。これは、レイテンシ 300 ミリ秒での A417,869 のピーク 1.53 IOPS から大幅に向上しました。

Oracle 80-20 では、A800 はミリ秒未満のレイテンシ パフォーマンスを維持し、レイテンシ 65,505 μs で 254.5 IOPS から始まり、666,556 μs でピークの 943.1 IOPS に達しました。 A300 のピーク時は 362,499 IOPS、遅延は 1.62 ミリ秒でした。

次に、完全およびリンクされた VDI クローン テストに切り替えました。 VDI フル クローン ブートの場合、A800 の遅延は約 535 IOPS まではミリ秒未満でしたが、その後 579,786 ミリ秒の遅延で 1.8 IOPS でピークに達しました。 A300 のピークは 300,128 IOPS、遅延は 3.46 ミリ秒でした。

VDI フル クローンの初期ログインでは、A800 は約 1 IOPS まで 200 ミリ秒未満に留まり、254,888 ミリ秒の遅延で 3.5 IOPS に達しました。これは、レイテンシ 300 ミリ秒でピーク 123,984 IOPS に達した A7.26 とは対照的です。

VDI FC Monday Login では、A800 のレイテンシが 180 ミリ秒で約 228,346 IOPS、ピークの 2.2 IOPS まではミリ秒未満のレイテンシ パフォーマンスを示しました。これは、A300 の 131,628 IOPS (レイテンシ 3.89 ミリ秒) を大幅に上回りました。

VDI リンク クローン (LC) に切り替えると、ブート テストでは、A800 のレイテンシーはほぼ全体で 1 ミリ秒未満で、約 1 IOPS で 440 ミリ秒の壁を突破し、レイテンシー 460,366 ミリ秒で最大 1.1 IOPS に達しました。 A300 のピークは 215,621 IOPS、遅延は 2.28 ミリ秒でした。

VDI LC の初期ログインでは、A800 は再びミリ秒未満のレイテンシを約 158 IOPS まで長時間続け、レイテンシ 166,224 ミリ秒で 1.5 IOPS に達しました。これは、A300 のピーク時の 95,296 IOPS、遅延 2.68 ミリ秒と比較されます。

最後に、VDI LC Monday Login を見てみましょう。A800 は 15,287μs のレイテンシーで 299.3 IOPS で開始しました。アレイは約 1 IOPS まで 130 ミリ秒未満に留まり、レイテンシー 164,684 ミリ秒で 3.1 IOPS でピークに達しました。 A300 のピーク時は 94,722 IOPS、遅延は 5.4 ミリ秒でした

まとめ 

NetApp AFF A800 は、最高のパフォーマンスを実現する 4U オールフラッシュ ストレージ アレイです。 A800 にはすべて NVMe フラッシュが搭載されており、最も要求の厳しいワークロードを対象としています。 AFF A15.3 は、すべての NVMe (およびそれぞれ最大 800 TB の容量の NVMe SSD) をサポートするだけでなく、パフォーマンスが絶対に必要な場合に備えて、オプションの 100GbE 接続も備えています。 NetApp によると、AFF A800 は 1.4 μs 未満の遅延で 500 万 IOPS に達することができるはずです。 A シリーズの他の NetApp アレイと同様、A800 は ONTAP を搭載しています。

パフォーマンスのために、SQL Server と Sysbench で構成されるアプリケーション分析ワークロードと VDBench ワークロードの両方を実行しました。アプリケーション ワークロード分析では、A800 のトランザクション SQL Server スコアは合計 12,835.5 TPS、平均遅延は 5 ミリ秒でした。これは、A300 の 12,628.7 TPS と平均レイテンシ 8 ミリ秒からパフォーマンスが大幅に向上しました。 Sysbench を使用した場合、A800 では 15,750.8VM で 8TPS、22,170.9VM で 16 TPS、44,149.8VM で 32 TPS が得られ、平均レイテンシは 16.3VM で 8 ミリ秒、23.1VM で 16 ミリ秒、23.2VM で 32 ミリ秒、最悪のシナリオのレイテンシは31.3VM の場合は 8 ミリ秒、48.5VM の場合は 16 ミリ秒、48.1VM の場合は 32 ミリ秒です。場合によっては、A800 は遅延を約半分に短縮しながら TPS を XNUMX 倍にすることができました。

VDBench ワークロードでは、NetApp AFF A800 が引き続き優れた性能を発揮しました。ハイライトには、1.2K 読み取りで 4 万 IOPS、439K 書き込みで 4K IOPS、シーケンシャル 18.9K 読み取りで 64GB/秒、5.03K 書き込みで 64GB/秒が含まれます。これらの数値はすべて、5 ミリ秒未満の遅延で達成されました。 SQL テストでは、アレイは 698K IOPS、SQL 731-90 で 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.4 ミリ秒でした。

以前にレビューしたミッドマーケットの ONTAP システムと同様に、NetApp はエンタープライズ向けの A800 で再び限界を打ち出しました。パフォーマンス プロファイルは非常に優れており、ONTAP ファミリのトップの地位を占めています。前述したように、このテストは非常に複雑なファイバー チャネルの作業です。私たちはまだ皮をむいていません NVMeoF 構成で利用できるものとても楽しいはずです。レビューのためにハードウェアを検討しているとき、古いストレージ ベンダーは新興企業ほど高速かつ柔軟ではなく、「レガシー コード」が追いついていないのではないかという、ちょっとした懸念が生じることがあります。 NetApp ポートフォリオのどこにもこうした問題の兆候は見られません。さらに、A800 は、ONTAP に長年備わっているデータ保護と可用性の機能を犠牲にすることなく、企業にとって実用的な方法で NVMe と NVMeoF を採用しています。 NetApp は A800 の NVMe をうまく活用しています。私たちは、これらの学習が他のアレイ全体にどのように生かされるのかを楽しみにしています。

ネットアップ AFF シリーズ

このレビューについて話し合う

StorageReview ニュースレターにサインアップする