これまで、 Microsoft Azure クラウド サービスのオンプレミス実装であるMicrosoft Azure Stack HCI について詳しく見てきました。Azure Stack HCI は、両方の利点を兼ね備えたプラットフォームと言えます。Azure Monitor、Azure Security Center、Azure Update Management、Azure Network Adapter、Azure Site Recovery など、Azure のすべての管理ツールを備えながら、データをオンプレミスで管理し、特定の規制にも対応しています。Azure Stack HCI は、ソフトウェア定義アーキテクチャ、Azure サービス、ハードウェアの 3 つの部分で構成されています。
適切なハードウェアを選択することは重要です。これについては、弊社の記事「Microsoft Azure Stack HCIにおけるハードウェアの重要性」で詳しく説明しています。Azure Stack HCIを導入する最初のステップは、認定ハードウェアベンダーを見つけることです。この場合、DataONがそのベンダーとなります。DataONは、MicrosoftおよびIntelと長年にわたり強力なパートナーシップを築いており、Azure Stack HCIのハードウェア構成において、Intel Select構成でこのパートナーシップを最大限に活かしています。Intelとのパートナーシップの興味深い点は、Azure Stack HCIでIntelのPMEM（および最新のプロセッサ）を活用できることです。
多くの場合、DataON HCI Intel Select ソリューションは独自のラックに構成されて出荷され、すぐに導入できる状態になっています。この配信方法は、既存の IT インフラストラクチャが制限されているか存在しないエッジで特に役立ちます。 StorageReview ラボでは、以下の図に示すように、4 つのストレージ ノード、コンピューティング ノード、ドメイン コントローラー、スイッチを展開しました。
ビルドとデザイン
私たちがレビューした Microsoft Azure Stack HCI クラスターは、DataON HCI-224 オール フラッシュ NVMe プラットフォーム上に構築されています。これらのサーバーはサイズが 2U で、前面に 24 NVMe ベイを備え、背面に PCIe ベースのコンポーネント用の十分な拡張機能を備えています。ラベルはマットブラックのドライブ キャディとは対照的に目立つ位置にあるため、交換時期が来た場合に特定のドライブを簡単に見つけることができます。すべてにラベルが付けられているのは、それほど珍しいことではありませんが、ラベルの範囲は異なります。私たちの展開には、各ノードに (1 ～ 4) のラベルが付けられています。また、データセンターでの展開と管理を容易にするその他の項目も多数あります。
私たちの構成には 48 台の NVMe SSD、つまりノードごとに 12 台が装備されていました。これらには、375 つの 4800GB Intel Optane P4510X SSD と 2 つの Intel PXNUMX XNUMXTB SSD が含まれます。
背面には 100 つのデュアルポート 5G Mellanox Connect-X 100 NIC があり、クラスター ネットワーク トラフィックに対して 2100 つの Mellanox XNUMXG スイッチ (SNXNUMX) を介した完全な冗長接続を提供します。スタジオ写真には示されていませんが、展開段階でエラーのないケーブル接続を可能にするために、適切なネットワーク ケーブルの両端に完全なラベルが貼られたすべての接続が示されています。
これまでは、このレベルのドキュメントをラベルに含めたソリューションが提供されたことはありませんでした。 Microsoft と DataON は、Azure Stack の展開を簡単なプロセスにして、顧客がすぐに運用を開始できるようにします。各ケーブルは特定の用途に合わせて色分けされており、各端の接続場所にラベルが付けられています。 DataON が顧客に提供するカスタマイズされたシートと組み合わせることで、エラーのない展開がほぼ保証されます。当社の導入環境では、システムは出荷前に IP アドレスで事前構成されており、管理用の IP アドレスと IPMI のラベルが付けられていました。
管理と使いやすさ
Windows Server 上で Hyper-V ショップを運営している購入者にとって、Microsoft Azure Stack HCI は簡単に移行できます。同じ管理ツールの多くが導入されており、その多くはより統合されたシンプルなワークフローを提供しています。レビュー プロセスでは、Windows フェールオーバー クラスター マネージャーを利用して DataOn HCI クラスターを管理し、Windows 管理センターを利用してワークロードを監視し、そのパフォーマンスを確認しました。
まず、ノードの 1 つにログインした Microsoft リモート デスクトップ (RDP) セッションを通じてノード レベルを詳しく調べ、Windows フェールオーバー クラスター マネージャーを調べました。これにより、ノードレベルの管理機能とクラスターレベルの可視性の両方が得られます。このタイプのアクセスは、Windows Admin Center から日常の監視が行われる初期展開に適しています。
まず、特定のクラスターをクリックして、そのクラスターに関する一般情報、クラスターを構成する機能、およびリソースを調べます。これにより、選択したクラスターの概要ビューが表示され、問題がどこにあるのかを確認し、特定の領域へのドリルダウンを開始できるようになります。
次はフェイルオーバーの役割です。ここでは、クラスター上で実行されているすべての Hyper-V VM を確認できます。クラスターのストレス テストに使用した多数の vmfleet VM が示されています。
ネットワークを使用すると、利用可能なクラスタ ネットワークとそれぞれのステータスを確認できます。クラスタ ネットワークを選択すると、それに関連付けられている基盤となるネットワーク カードとその IP アドレスが表示されます。
ストレージ オプションの下には、ディスク、プール、エンクロージャがあります。ディスクの場合、仮想ディスクをクリックすると、ステータス、割り当て先、所有者ノード、ディスク番号、パーティション スタイル、容量などの情報を取得できます。ユーザーは、プール ID、名前、説明のほか、仮想ディスク ID、名前、説明、正常性と動作ステータス、回復力などのさらに多くの情報を表示して、さらに深くドリルダウンすることもできます。
プールも同様で、ステータス、健全性、所有者ノード、動作状態、全体の容量、空き領域と使用済み領域などの特定のストレージ プールの情報が含まれます。
「ノード」では、クラスター内のすべてのノードとそのステータスを簡単に確認できます。
右側では、フェイルオーバー ディスクに切り替えると、下部に特定のノードの個々のディスクが表示されます。
同じサイドバーから、特定のノードのネットワークを確認することもできます。
Windows フェールオーバー クラスター マネージャーは、より「細部に至るまで」の管理装置ですが、ユーザーが操作するには、Windows リモート デスクトップを介してサーバー自体 (またはそのクラスターに接続されている別のサーバー) に接続する必要があります。この管理スタイルは多くの用途に適していますが、Microsoft は Windows Admin Center と呼ばれる新しいプラットフォームを使用して作業を容易にしました。フェールオーバー クラスター マネージャーとは異なり、Windows Admin Center は完全に Web ブラウザー ベースであるため、職場のコンピューターやタブレットから簡単に接続できます。また、最新化され、見た目も美しく、日々のモニタリングがより楽しい作業になります。これは、フェールオーバー クラスター マネージャーでは同じ程度には提供されないアクティビティの監視に重点を置きながら、ほぼ同じ情報の調査を提供します。
Windows Admin Center をクラスターに関連付けると、特定の領域にドリルダウンして操作を表示および管理できます。ここでは、クラスタ全体のコンピューティング パフォーマンス情報が表示され、VM が使用している全体的なリソースが追跡されます。
Windows Admin Center はアクティビティを表示するのに最適ですが、クラスター内の VM を操作することもできます。以下では、いくつかの vmfleet VM をパワーオンしています。
ユーザーは、特定の VM に関する情報をドリルダウンすることもできます。
役割の下では、役割について若干異なる見方が得られますが、重要な情報はほとんど同じです。
ユーザーは設定で、Azure の拡張機能をダウンロード、インストール、更新できます。
Windows Admin Center を通じて、ハイパーコンバージド クラスター マネージャーにアクセスして、コンピューティングとストレージをさらに詳しく調べることもできます。ダッシュボードを開くと、サーバー、ドライブ、VM、ボリュームの数、CPU、メモリ、ストレージの使用状況などの一般的な情報が表示されます。ダッシュボードの下部には、特定の時間枠、IOPS、レイテンシに分類されたクラスタのパフォーマンスが表示されます。
コンピューティングでは、管理者はサーバー自体にドリルダウンして、クラスタからのサーバーの削除などの管理を行うことができます。ここには、稼働時間、場所、ドメイン、メーカー、モデル、シリアル番号、OS 名、バージョン、ビルド番号など、使用されているサーバーに関する一般的な情報が含まれます。また、ユーザーはサーバー固有のパフォーマンスを確認できます。
「ボリューム」タブをクリックすると、クラスター上のすべてのボリュームの概要が表示されます。ボリュームの健全性は色分けされています。健全な場合は緑、重大な場合は赤、警告は黄色です。すべてのボリュームのパフォーマンスも追跡され、時間枠ごとに IOPS、レイテンシー、スループットに分類されます。
単一ボリュームをドリルダウンすると、ステータス、ファイル システム、パス、障害ドメインの認識、合計サイズ、使用済みサイズ、復元力、フットプリントなどのボリュームの特定のプロパティが得られます。ここでオンまたはオフにできるオプション機能 (重複排除と圧縮、整合性チェックサム) があります。容量はグラフで表示され、使用済みと使用可能が示されます。そして再びパフォーマンスが見られます。
[ドライブ] タブでは、システム内のすべてのドライブの概要が表示されます。ここでは、ドライブの総数と、ボリュームと同じ色分けのアラートがあるかどうかが表示されます。また、使用済み、使用可能、予約済みの容量も確認できます。
「インベントリー」をクリックすると、すべてのドライブのリストといくつかの詳細が表示されます。詳細には、ドライブのステータス、モデル、容量サイズ、タイプ、用途、使用されるストレージの量が含まれます。
単一のドライブをドリルダウンして、ステータス、場所、サイズ、タイプ、使用目的、製造元、モデル、シリアル番号、ファームウェアのバージョン、ドライブ内のストレージ プールなどのプロパティを確認できます。使用されている容量の量を確認できます。個々のドライブで利用可能なものと、その IOPS、レイテンシ、スループットのパフォーマンスを比較します。
パフォーマンスの下には、ドライブの遅延とエラーの統計も表示されます。
パフォーマンス
Microsoft Azure Stack エコシステム内のパフォーマンスは常に素晴らしく、これは記憶域スペースの時代から受け継がれている強力な性能です。それを念頭に置いて、このレビューでは、ユーザーがこのプラットフォームが市場の他の HCI ソリューションとどの程度優れているかを確認できるように、いくつかの一般的なベンチマーク ワークロードに注目しました。これを念頭に置いて、この Microsoft ソリューションがどのような可能性を提供できるかを示すために、ワークロードを使用してランダムな小さなブロック サイズと大きなブロックの転送に重点を置きました。 Azure Stack HCI のレビューでは、パフォーマンス ベンチマークに vmfleet を利用しましたが、VMware またはベアメタル Linux では vdbench を使用しました。
ここでのパフォーマンスについては、2 方向ミラーと 3 方向ミラーの両方を使用してシステムをテストしました。ミラーとは、データ保護の方法 (3 つのコピーまたは 2 つのコピー) を指します。明らかに、コピー数が増えると、ユーザーの容量がいくらか失われます。パフォーマンスの観点から見ると、XNUMX ウェイは並列処理の向上により読み取りが向上し、XNUMX ウェイはネットワーク トラフィックが XNUMX 分の XNUMX 減り、書き込みパフォーマンスが向上します。
4K ランダム テストでは、2 方向ミラーの平均遅延 2,204,296 μs で読み取り 247 IOPS のスループットと、平均遅延 564,601 ms で書き込みスループット 3.69 IOPS が確認されました。 3 ウェイでは、平均レイテンシ 2,302,610 μs で読み取り 170 IOPS の読み取りスループットが確認され、書き込みの場合、平均レイテンシ 338,538 ミリ秒で 9.12 IOPS のスループットが得られました。これを大局的に考えると、ノードごとに 521 台の Optane SSD と 4 台の NVMe キャパシティ SSD を使用した VMware の vSAN サービスでは、ピーク時に 202K IOPS XNUMXK 読み取り、XNUMXK IOPS 書き込みが測定されました。
次に、32K シーケンシャル ベンチマークを見ていきます。読み取りについては、2 ウェイで 42.59 GB/s に達し、3 ウェイで 39.48 GB/s に達しました。書き込みについては、HCI は 13.8 ウェイで 2 GB/秒、7.19 ウェイで 3 GB/秒を示しました。
一連の作業を続けて、64K テストに進みます。ここでは、2 ウェイのヒットは読み取り 39.5 GB/s、書き込み 15.24 GB/s、3 ウェイのヒットは読み取り 46.47 GB/s、書き込み 7.72 GB/s でした。 vSAN と比較すると、読み取り帯域幅の差はほとんどなく、テストでの帯域幅は 5.3K ブロックサイズで 64GB/s 強に達しました。書き込み帯域幅にも同様の差があり、vSAN の最高値は 2.55 GB/秒でした。
次のベンチマークは、読み取り/書き込みパフォーマンスが混在する SQL です。ここでは、2 ウェイのスループットは 1,959,921μs の平均レイテンシーで 324 IOPS でした。 3 ウェイは 1,929,030 IOPS に達し、平均遅延は 185μs でした。 SQL ワークロードは、Azure Stack HCI が強みを発揮できるもう 2 つの領域であり、同じワークロード プロファイルの VMware の vSAN が 321 IOPS を測定したのに対し、XNUMX 万 IOPS をわずかに下回りました。
SQL 90-10 では、2 ウェイでは 1,745,560 IOPS に達し、平均レイテンシは 411 μs で、3 ウェイでは 1,547,388 IOPS でレイテンシは 285 μs でした。
SQL 80-20 の場合、2 ウェイのスループットは 1,530,319µs のレイテンシで 581 IOPS でした。 3 ウェイでは 1,175,469 IOPS と 681µs のレイテンシーを達成しました。
スペック
次は、SPECsfs 2014 SP2 ベンチマークです。これは、ここでの新しいテストです。 SPECsfs は、ファイル サーバーのスループットと応答時間を測定するベンチマーク スイートです。このベンチマークにより、さまざまなベンダー プラットフォーム間でパフォーマンスを比較するための標準化された方法が得られます。ベンチマークは、スケールを設定し、ポイント レイテンシがベンチマークの仕様に対して大きすぎるまで増加することによって動作します。ここでは、11 ミリ秒を突破するまでに実行できるスケールと、サーバーがレイテンシの数値を超えたときに到達する帯域幅を見ていきます。
ここでは、帯域幅が 2 番目の部分で停止した理由をさらに明らかにするため、最初にレイテンシーを見ていきます。 3 ウェイと XNUMX ウェイの両方のスケールとそのレイテンシを以下の表に示します。
| SPECsfs 遅延 (ミリ秒) | ||
|---|---|---|
| 規模 | DataON 224ウェイミラー HCI-2 | DataON 224ウェイミラー HCI-3 |
| 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 ウェイ障害は 11.285ms に達し、範囲は 262µs ～ 10.45ms となりました。 2 ウェイは 1800 のスケールで 11.7 ミリ秒に達し、243 マイクロ秒から 11.07 ミリ秒の範囲で失敗しました。
次の表は、各ビルドでの各構成の帯域幅と、上記の遅延を示した障害を示しています。
| SPECsfs 帯域幅 (KB/秒) | ||
| 規模 | DataON 224ウェイミラー HCI-2 | DataON 224ウェイミラー HCI-3 |
| 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 (失敗) | |
帯域幅に関しては、300 ウェイが最終通過帯域幅 3GB/秒で遅延に失敗するまで、両方の構成が 4.02MB/秒の間隔でネックインネックで動作し、2 ウェイの最終通過帯域幅が 4.62GB/秒でした。 s.
結論
Microsoftのストレージ中心のスタックについて、これほど深く掘り下げたのは久しぶりです。そして、こうして戻ってこられて本当に嬉しいです。Microsoft Azure Stack HCIソリューションは、Microsoftが基本的かつ根本的なことを成し遂げたため、その重要性が見過ごされがちです。Microsoftは、パフォーマンスを低下させるようなオーバーレイを一切使用せず、HCIソリューションを極めてシンプルに操作できるようにしました。テストしたDataONクラスターは、数値からもわかるように、驚異的な数値を記録し、中規模市場の4ノードHCIクラスターとしてはこれまでで最速でした。公平を期すために付け加えると、DataONの最新かつ最高のハードウェアをテストしているわけでもありません。この構成はIntel Optane DC SSDを搭載しており、明らかに性能は劣りませんが、DataONはIntel Xeon第2世代CPU、永続メモリ、高速ネットワークを活用した、より高速なソリューションを提供しています。 Azure Stack HCIソリューションでさらに高いパフォーマンスが利用できるようになったことは素晴らしいことですが、低コストのエッジ環境や中小企業向けソリューションとして、スイッチレス構成が可能な2ノードHCIといった小規模なデプロイメントにも対応できることも覚えておくことが重要です。
パフォーマンス数値を詳しく調べると、Microsoft Azure Stack HCI クラスターは信じられないほどの量の I/O と帯域幅を提供できました。 2.3 隅の領域では、4 方向ミラー構成で 3 万 IOPS 338K ランダム読み取り、および 4k IOPS 2K ランダム書き込みを超えることが測定されました。より高い書き込みパフォーマンスが必要な場合は、4 方向ミラー構成により、564K ランダム書き込み速度を 64k IOP まで高めることができます。ただし、帯域幅に注目すると、Microsoft Azure Stack が真価を発揮します。 2K ブロックのシーケンシャル転送ワークロードでは、39.5 方向ミラーでは読み取り 15.24 GB/秒、書き込み 3 GB/秒が測定されましたが、46.47 方向ミラーでは読み取り 7.72 GB/秒、書き込み XNUMX GB/秒が測定されました。これは、過去の HCI クラスターから測定したものをはるかに上回っています。
全体として、Microsoft の Azure Stack HCI ソリューションは、展開が簡単で、管理が簡単で、非常にパフォーマンスが高く、必要なものをすべて備えていることが証明されました。 DataON は、ソリューションのパートナーとして、ターンキー ビルドの提供に優れ、仕様に合わせて構築されたハードウェアを明確な説明書とともに提供し、最終的にはすぐに稼働できる構成で販売されます。多くの場合、お客様は配線を省略することもできるため、最終的には特定のニーズに応じて対応できます。ただし、どちらの方法でも、Azure Stack HCI と Intel Optane、Intel NVMe SSD、Mellanox 100G ネットワーキングを組み合わせることで、それ自体が無視できない力であることが証明されました。
Amazon