X-IO Technologies ISE 1 G860 レビューのパート 3 では、ISE 860 G3 の概要を説明し、アプリケーションと合成ベンチマークを検討しました。簡単にまとめると、このプラットフォームは、MySQL、SQL Server、合成ワークロードなど、私たちが取り組んだすべての機能において非常に優れたパフォーマンスを発揮しました。レビューの 860 番目の部分では、VMmark テストを使用して ISE 3 G860 の VMware 仮想化テストを拡張し、負荷がかかった状態でコントローラに障害が発生し、MySQL ワークロードの下で ISE 3 GXNUMX の QoS エンジンに負荷をかけます。
VMmark パフォーマンス分析
当社のアプリケーションパフォーマンス分析はすべて、実際の運用環境における製品のパフォーマンスを、メーカーの公称性能と比較して示すことを目的としています。当社は、ストレージを大規模システムの構成要素として評価することの重要性を理解しており、特に主要なエンタープライズアプリケーションとの連携におけるストレージの応答性を重視しています。このテストでは、VMwareのVMmark仮想化ベンチマークをマルチサーバー環境で使用します。
VMmark はその設計上、リソースを大量に消費するベンチマークであり、ストレージ、ネットワーク、コンピューティング アクティビティに重点を置く VM ベースのアプリケーション ワークロードが幅広く混在しています。仮想化パフォーマンスのテストに関しては、これより優れたベンチマークはほとんどありません。VMmark はストレージ I/O、CPU、さらには VMware 環境のネットワーク パフォーマンスに至るまで、非常に多くの側面を調査しているからです。
Dell PowerEdge R730 VMware VMmark 4 ノード クラスタの仕様
- Dell PowerEdge R730 サーバー (x4)
- CPU: 5 基の Intel Xeon E2690-3 v2.6 12GHz (24C/XNUMXT)
- メモリ: 64 x 16GB DDR4 RDIMM
- Emulex LightPulse LPe16002B 16Gb FC デュアルポート HBA
- Emulex OneConnect OCe14102-NX 10Gb イーサネット デュアルポート NIC
- VMwareのESXiの6.0
ISE 860 G3（DataPac あたり 20×1.6TB SSD）
- RAID前: 51.2TB
- RAID 10 容量: 22.9TB
- RAID 5 容量: 36.6TB
- 定価：575,000ドル
VMware VMmark のパフォーマンスを XIO ISE 860 で最初に検証した際には、ワークロードの駆動源としてDell PowerEdge R730 13G 4 ノード クラスタを使用しました。このクラスタは、8 基の Intel E5-2690 v3 Haswell CPU を搭載しており、各 VMmark タイルの一部として実行されるアプリケーションに 249.6GHz の CPU リソースを提供します。一般的に、タイルあたり約 10GHz の要件が見られるため、このクラスタは最適な条件下で 24～26 タイルを実行できるはずです。それ以上の負荷をかけるには、クラスタにサーバーを追加するか、E5-2697 v3 や E5-2699 v3 などの上位プロセッサに切り替える必要があります。つまり、このクラスタが限界に達した場合でも、ストレージにはまだ余裕があり、さらに負荷を上げることができる可能性が高いということです。
XIO ISE 860 で VMmark ワークロードをスケーリングすると、1 タイルから 22 タイルまで強力な線形改善が見られました。 22 タイルを超えると、コンピューティング クラスターの CPU 使用率が固定されるため、パフォーマンスがわずかに低下し始めました。より大規模なクラスタを使用すると、XIO ISE 860 は追加の負荷を簡単に処理できます。舞台裏でのパフォーマンス監視を詳しく調べてみると、1 タイルの実行中に遅延が 26 ミリ秒未満に測定され、svmotion/デプロイ アクション中に数回 860 桁のスパイクが発生したことがそれを裏付けています。オールフラッシュ アレイには低遅延パフォーマンスが絶対条件であるため、X-IO ISE XNUMX はまったく期待を裏切りません。
コントローラーの故障テスト
市場にはさまざまな SAN 設計があり、アクティブ/パッシブ、アクティブ/アクティブなどの構成の違いもあります。障害への対処に関しては、どちらの設計でも、プライマリ コントローラーがオフラインになった場合に、スペアまたはセカンダリ コントローラーがストレージの役割を引き継ぐことができます。すべてのプラットフォームが同じではないため、さまざまなプラットフォームがコントローラーの障害にどのように対処するかを示すことへの関心が高まっています。私たちが設計したシナリオは、本質的にかなり基本的なものです。ストレージ アレイに大量のワークロードをデプロイし、ワークロードが定常状態に達するまで待ってから、コントローラーをプルします。このプロセスでは、パフォーマンス特性がどのように変化するかを確認し、ドロップされた I/O アクティビティを監視します。そして最も重要なのは、プラットフォームがテスト対象のワークロードを再開する速度を確認します。 X-IO ISE 860 の場合、4 つのボリュームに分散された XNUMX つのインスタンスを持つ Sysbench ワークロードを使用しました。
ISE 4 上で 860 つの Sysbench VM を実行し、ストレージ アレイ上のワークロードが均等になるまで約 15 分間待ちました。この時点でのワークロードは VM あたり約 1,100TPS と測定されました。 3 つのコントローラーを取り外すと、すべての VM でパフォーマンスが 4 ～ 10 秒間低下し、約 6.0 秒間一時停止し、その後すぐに障害発生前に測定されたパフォーマンス レベルに戻りました。当社の VMware ESXi XNUMX ホストは、このストレージ I/O の中断に簡単に対処し、何事もなかったかのように動作を継続しました。
X-IO ISE Manager Suite からは、約 5 分後に障害を確認することができました (手動で更新すると、もっと早く障害が表示された可能性があります)。コントローラーを取り外してから 10 ～ 15 分後に、X-IO サポートからコントローラーの障害を警告する自動メール アラートも受け取りました。
古いコントローラーをフォールドに戻す (または交換用コントローラーをアレイに追加する) には、単にコントローラーをアレイの背面に挿入し、アレイにコントローラーを検出/分析させ、アレイとマージできることを示します。 。このプロセスには数分かかり、ISE Manager コントローラ ビューに [追加] ボタンが表示されます。クリックすると同様のパフォーマンスの低下が見られ、その後、アレイが通常の状態に戻る前に数秒間の I/O 一時停止が続きました。最初の障害と同様に、VMware ESXi 6.0 はこの中断を問題なく処理でき、ゲスト OS レベルでのエラーは見られませんでした。この点では、すべてのストレージ アレイが同じように作成されているわけではありません。ISE 860 が壊滅的な障害に簡単に対処できることは素晴らしいことです。
X-IO テクノロジー ISE 860 G3 QoS
レビューの最初の部分で QoS について簡単に触れましたが、ここではさらに詳しく見ていきます。 X-IO は、ISE ストレージ アレイで QoS 機能を提供します。 QoS 設定はボリューム レベルで適用され、ユーザーは IOPS Max、IOPS Min、および IOPS Burst を指定できます。合成結果は、特定のデバイス上で QoS プロファイルがどのように機能するかを示すのに役立つ場合がありますが、アプリケーションがそれらにどのように応答するかを確認することの方がはるかに価値があります。このセクションでも Sysbench MySQL TPC-C ワークロードを使用しました。これは、優れたリアルタイム パフォーマンス監視機能を提供するためです。このシナリオでは、4 つの VM を XNUMX つのボリューム上に配置し、他の XNUMX つの VM を別のボリューム上に配置する XNUMX VM デプロイメントを利用しました。 XNUMX つのボリュームは、規制されていないベンチマークと比較してパフォーマンスに制限を設けない「本番」ユースケースとして設計され、もう XNUMX つのボリュームは「開発」ユースケースになります。これは、プライマリ ストレージ上で複数のデータベース インスタンスを実行する必要があるが、開発インスタンスが運用 VM に影響を与えることは許可されないというエンタープライズ設定を反映しています。
X-IO ISE 860 では、QoS を有効にしてボリューム レベルで構成するのが非常に簡単です。ボリュームをプロビジョニングするときと同じメニューから設定にアクセスできます。デフォルトは「ストレージ規制」またはフル パフォーマンスです。 QoS を有効にするには、IOPS 値を入力するだけで、それがワークロードにどのような影響を与えるかを試行錯誤して確認します。まずベースラインを取得するために、ISE マネージャーのパフォーマンス ビューを通じてワークロードの IOPS レベルを制限なしで監視することは価値があります。この場合、2 つの Sysbench VM が 20,000 IOPS を超えて消費したため、本番ワークロードを実行するボリュームに最大 30 IOPS、バースト 40 IOPS、最小 20 IOPS を設定しました。開発ボリュームについては、I/O プロファイルの制限がライブ Sysbench の実行にどのような影響を与えるかを確認するために、数回の反復を実行しました。
最初の例は、QoS が有効になっている、本番ボリュームで実行されている Sysbench を示しています。ストレージが規制されているか、まったく制限されていない場合と比較して、パフォーマンスの変化は見られませんでした。
私たちの開発 Sysbench ワークロードでは、パフォーマンス レベルは低いものの、安定したパフォーマンス プロファイルを簡単に制御できました。以下の例では、実稼働ボリュームの半分のパフォーマンスに設定されたプロファイルから、IOPS レベルを元の 25% に下げるプロファイルに変更しました。ご覧のとおり、パフォーマンスの変化はすぐに発生し、I/O の中断や I/O の不安定性はありませんでした。優先度の高いワークロードに影響を与える可能性のある近隣の騒音を懸念する購入者向けに、X-IO は、実際の条件下で非常に優れたパフォーマンスを発揮する、高機能な QoS 機能セットを提供します。
パート 2 最終的な考察
このレビュー シリーズの 860 番目のセグメントでは、パフォーマンスとサービスの問題の両方を幅広く取り上げます。パフォーマンスの面では、ISE 26 は VMmark の 4 タイルを削減し、26 ノード クラスタの能力を最大限に引き出しました。さらに、1 タイルのロードでは書き込みレイテンシが信じられないほど低く、10ms 未満であり、スパイクは XNUMXms 未満でした。ここでは ISE の方が明らかに余裕がありますが、これについてはさらに詳しく調べていきます。 XNUMX 台のサーバーが可能なすべてを実行するのは簡単な作業ではありませんが、それでも、ISE はさまざまなワークロードにわたって素晴らしいパフォーマンスを実証し続けているため、予想通りのことでした。
パフォーマンス以外にも目を向けると、X-IO が ISE シリーズで名声を博していることの 1 つは、メンテナンスの必要がないことです。この場合、ドライブに障害が発生しても機能しません。たとえ動作中に物理的にアクセスできたとしても、X-IO はストレージを集約して個々のドライブ自体を意図的に難読化します。この場合、アクティブなワークロードに何が起こるかを確認するためにコントローラーを正常にプルしたわけではありません。 2 番目のコントローラーが負荷を吸収するときに少し音を立てましたが、vCenter やゲスト OS では問題なくすべてが続行されました。また、ボリュームごとの厳密な制御を可能にする ISE の QoS 機能についても詳しく説明します。成熟した QoS 機能はプライマリ ストレージ アレイではあまり見られないため、このレベルのきめ細かなアクセスがあれば、特にプライマリ ストレージで非クリティカルな開発ワークロードを実行している場合や、頻繁に消耗する可能性のあるノイズの多いネイバーがある場合には便利です。リソースの公平な配分を超えています。
私たちは、この新しい種類の高性能ストレージのテスト戦略をさらに開発する際に、引き続き ISE 860 と協力していきます。次のステップには、XNUMX つのブレードを備えた Cisco UCS Mini と、フラッシュ アレイが優れた処理を実行できるいくつかの追加のワークロードに対するテストが含まれます。
Amazon