Azure Stack HCIのノード拡張とCSVの回復性変更で、仮想マシンのDisk I/Oはどれくらいダウンするのか

注）Nested Hyper-Vかつ、CSVあたりの仮想マシンは一つだけということで、本番環境と比較しうるにはまったくもって不十分です。これをもって、なにかを可否を判断するのは早計と考えております。そこのところを踏まて、あくまでも参考としてとらえていただけると大変助かります。

以前、下記の記事を書きました。

Azure Stack HCI Single Serverから2ノードクラスターにしましたが、更に3ノードクラスターにしてみます。

本稿は、パフォーマンス面を把握してみることにしました。しかしながら、冒頭にも書いた通りで、極めて限定的な確認です。

前提

• Nested Hyper-VのAzure Stack HCI 22H2 クラスター
• 400GBのCluster Shared Volume(以降、CSV)を二つ作成
• 上記CSVにWindows Server 2022仮想マシンを一つずつ作成
  クラスター内の仮想マシン数としては、合計2個
• 上記クラスターを2ノードから3ノードへ拡張
• ノードの拡張は、Windows Admin Centerより実行
• 下記ドキュメントに基づき、2個のCSVに対して、2 way Mirrorから3 way MirrorへResiliencyを変換（回復性を変更）
  2 ノードから 3 ノード以上のクラスター
  ※クラスターパフォーマンス履歴も2 way Mirrorから3 way Mirrorへ変換
• 各パターンにてパフォーマンス計測を最低3回実施
  
• 2 way Mirrorから3 way Mirrorへ変換時に、Windows Server 2022仮想マシン内部にてDiskspdを使用したパフォーマンスを計測
  
• 3 way Mirrorへ変換時後、Windows Server 2022仮想マシン内部にてDiskspdを使用したパフォーマンスを計測
• 上記のパフォーマンス計測は、下記ドキュメントに記載されているサンプルから変更
  DISKSPD を使用してワークロード ストレージのパフォーマンスをテストする
• 仮想マシンのvCPU 4へ負荷をかけるため-tオプションを4（すなわち-t4）を指定
• 読み取り要求50%と書き込み要求50%にするため、-w50を指定

2 way Mirrorから3 way Mirrorへ変換時に、Windows Server 2022仮想マシン内部にてDiskspdを使用したパフォーマンスを計測

2 way Mirrorから3 way Mirrorへ変換は、CSVのオーナー変更を行うと開始されます。下記画像のとおり、変換にともなうRepairのストレージジョブが実行中さなか、仮想マシンでパフォーマンス計測がおこわなれるという具合です。
※Hyper-Vノード側でCSVへRepairジョブを実行、仮想マシンではパフォーマンス計測されています。

ですので、パフォーマンス計測もそのタイミングから実施しました。

各々のIOPSは下記の通り。

• 仮想マシン1台目のIOPS平均は、258.25（小数点第3位以下は切り捨て）

• 238.93
• 250.265
• 285.56

• 仮想マシン2台目のIOPS平均は、351.67（小数点第3位以下は切り捨て）
• 336.331
• 292.30
• 426.38

3 way Mirrorへ変換時後、Windows Server 2022仮想マシン内部にてDiskspdを使用したパフォーマンスを計測

各々のIOPSは下記の通り。

• 仮想マシン1台目のIOPS平均は、1263.66（小数点第3位以下は切り捨て）

• 1062.59
• 1221.91
• 1506.50

• 仮想マシン2台目のIOPS平均は、1136.81（小数点第3位以下は切り捨て）
• 981.89
• 1155.72
• 1272.82

まとめ

仮想マシン内でのパフォーマンスは、平常時より低下することが確認できました。

• 仮想マシン1台目のIOPSは、平常時の20%ほど
• 仮想マシン2台目のIOPSは、平常時の30%ほど

※Hyper-Vノードの再起動後に、CSVのRepairが実行されます。そういった場合にも、上記のようなパフォーマンス低下が起こりえますね。。。