これまでの記事で紹介してきたとおりAzure Stack HCIは、Windows Serverをベースとしたシステムから、Azureとのハイブリッドサービスを意識し、専用OSを搭載したものへと生まれ変わりました。
Azure Stack HCI Bootcampの第3回、「Azure Stack HCI導入オプションとサイジング パフォーマンスの考慮事項」では、日本マイクロソフト マーケティング＆オペレーションズ部門 Azure ビジネス本部 プロダクトマーケティング部 プロダクトマネージャーを務める佐藤壮一氏が、要件や用途に応じてAzure Stack HCIを最適な形にチューニングする際の留意事項と、既存のシステムからの移行時のポイントを紹介しました。
▼Azure Stack HCI Bootcampに関する記事一覧
https://zine.qiita.com/tag/azure-stack-hci-bootcamp/
「認定ノード」と「統合システム」の2つに分かれた認定プログラム
これまでのWindows ServerをベースとしたAzure Stack HCIは、いくつかのテクニカルな要件を満たした環境に「DIYインストール」することができました。専用OSをベースとした新生Azure Stack HCIもその点に変わりはありません。ただしプログラムが階層化され、「バリデーテッドノード」（認定ノード）と「インテグレーテッドシステム」（統合システム）という2つのプログラムに分かれたことが特徴です。
バリデーテッドノードは、従来の認定プログラムに近い仕組みです。一方インテグレーテッドシステムは、よりアプライアンスに近い形で、なおかつ認定を受けたものとなります。
「インテグレーテッドシステムは、複数ノードを前提としたアプライアンスの形でパッケージされています。このため調達の容易さや展開のシンプルさ、メンテナンス性の向上といったメリットに加え、複数のOEMパートナーとマイクロソフトとでよりしっかりテストをしていくため、信頼性がより高くなるメリットがあります」。さらに、Secure-Coreテクノロジをベースとした強固なセキュリティの提供やより上位のサポート提供も予定されています。
「Azure Stack HCIカタログ」には、Azure Stack HCIの認定を受けたハードウェアが一覧形式で掲載されていますが、こちらも新生Azure Stack HCIのリリースに合わせて刷新されています。ぜひ確認の上、自社にはどちらが適合しているかを検討する材料にしてください。
2ノードの小規模構成から超大規模まで、柔軟に構成可能なAzure Stack HCI
2つのプログラムの違いを踏まえた上で、いよいよAzure Stack HCIのサイジングを検討することになります。
Azure Stack HCIは最小で2ノード構成から利用できる点は以前と変わりはありません。また、ドライブはSSD×4もしくはSSD×2とHDD×4の組み合わせが最小要件となり、プロセッサはハイパーバイザーのHyper-Vが動作するスペックならば大丈夫です。そして2つのノード間を結ぶネットワークは、10Gbpsが最小要件となります。
「2ノードからでも使える上、価格体系も使いやすくなっているため、小さなオフィスなど中小規模の環境でも導入を検討できるのではないかと思います」（佐藤氏）
逆に、最大でどこまで拡張できるかというと、ノード数は1クラスターあたり最大16ノードまでで、これも以前のAzure Stack HCIと変わりありません。また、1クラスターあたりのストレージ容量は最大4000TBまでとなっています。
ただし「複数のクラスターをクラスターセットとしてまとめることも可能なため、1000台規模のサーバーをひとまとめにして大きな仮想マシンやコンテナーを動かしたり、エッジのインフラとして活用することも従来通りにできます」と佐藤氏は述べました。
Azure Stack HCIの特徴の1つですが、ノードの追加はダウンタイムなしで可能な上、ストレージやドライブの割り当ても自動的にリバランシングされます。ノードを減らすときも同様にオートマティックな仕組みが働きますが、ボリュームの利用状況によっては削るに削れないところが出てくるため注意が必要です。
なお参考情報ですが、マイクロソフトでは、よりよい運用に役立てていただくためにWindows ServerベースのAzure Stack HCIのテレメトリデータを収集してきました。この実績ベースで見ると、グローバルのユーザーで最も多いのは「2ノード構成」と「4ノード構成」で、その次に3ノード構成という順番になっています。
ドライブの種類と冗長構成オプションがポイントとなるストレージ
次の検討ポイントはストレージです。
ストレージを構成する物理的なドライブには、HDD、SSD、NVMe、そしてパーシステントメモリといった種類があり、それぞれ特性が異なります。Azure Stack HCIでは、「1種類のみ」「2種類の混合」「3種類の混合」といったパターンをサポートし、用途や要件に応じて選べるようになっています。
ドライブを1種類のみで使う場合には、パフォーマンスのボトルネックを発生させないよう、サポートするのはSSDのみとなっています。またキャッシュは使わず、単なる記憶領域として利用します。
これに対し2種類の混合構成では、高速なディスクは自動的にキャッシュ領域に、遅いディスクをキャパシティ領域に利用することで、容量とパフォーマンスのバランスを取る仕組みです。この場合の最小構成は、「SSD×2本で構成するキャッシュ＋その倍数で用意するキャパシティディスク」となります。3種類の混合構成も基本は同じですが、キャッシュ＋キャパシティ＋キャパシティという使い分けになります。
このとき、「キャッシュ用のドライブは、Azure Stack HCIの記憶域容量としてはカウントされないこと」、そして「キャッシュとキャパシティの使い分けの判断は、実測ベースではなく、ドライブやメディアタイプ、バスの種類をベースにしていること」に注意してほしいと佐藤氏は述べました。状況によっては、たとえば「キャッシュにSSDを使うつもりだったのにHDDが使われている」といったパターンが生じる可能性があります。ただしその場合はPowerShellなどを使って手動で設定を上書きすることで、キャッシュに使うドライブを指定できます。
物理的なドライブ構成を決めたら、次は仮想ボリュームを作成しますが、ここで重要なのが冗長構成のオプションです。
まずはいわゆる「ミラー構成」で、RAID 1に相当します。「アルゴリズム的に極めてシンプルで、動きにも複雑なところがないため、パフォーマンスの観点ではベストなオプションになっています」（佐藤氏）。ただし、ストレージの利用効率は2ウェイミラーならば50％、3ウェイミラーならば33.3％といった具合に下がっていきます。
ミラーの反対が、RAID 6に相当する「パリティ」です。4ノード以上の構成で利用可能で、ミラーと同様に二重障害まで担保します。ノード数とドライブ数が増えれば増えるほど容量効率が上がり、最大で80％まで向上しますが、分散ストレージの煩雑な処理が必要になるため、I/Oのパフォーマンスはどうしても低下します。ですので、高いI/Oを要求する用途にはお勧めできません。
さらに、ミラーとパリティをいい具合に組み合わせた「Mirror-accelerated parity」というオプションもあります。
いわゆるホットデータと呼ばれる頻繁に読み書きが行われるデータはミラー構成の領域に配置する一方で、コールドデータの扱いになったものをパリティ構成の領域に配置することで、I/Oパフォーマンスを最大限に高めながら容量効率も犠牲にしない方式です。「OSのバージョンアップに追随してこの部分のチューニングをしっかりかけていますので、Mirror-accelerated parityを検討いただく余地はあるのではないでしょうか」と佐藤氏は説明しました。
また、2ノード構成時に知っておきたい仮想ボリュームのオプションが「Nested Resiliency」です。
ノードが2台しかない場合にミラー構成を採用すると、当然ながら2ウェイミラーにしかなりません。つまり、故障中にさらに別の障害が発生するなど、二重に障害が発生した際の備えがなくなってしまいます。しかし「Nested Resiliencyを利用すると、各ノード内でコピーを多重で持つ形になります。ディスクの利用効率は落ちますが、2ノード構成において二重に障害が発生した場合でも再起動できる状態を実現できるため、環境や要件によっては必要なオプションになるかもしれません」（佐藤氏）
なお、具体的なストレージ容量の計算には「Storage Spaces Direct Calculator 」が活用できます。どのようなノード構成で、どのようなオプションを用いたら仮想ストレージのボリュームサイズはどのくらいになるか、といったことをオンラインで試算できるため、ぜひ活用してみてはいかがでしょうか。
ネットワークでは要件に応じて増強や新プロトコルへの対応の検討を
次に、ノードとノードを結ぶネットワークについて見てみましょう。ここでポイントとなるのは、いわゆる「East-West」通信、ノード間通信です。
前述の通りネットワークの最小スペックは10Gbpsとなりますが、「大規模環境やパフォーマンスが要求される環境、非常に高いレベルの冗長性が要求される環境ならば、当然ながらネットワークも増強してください」と佐藤氏は述べました。
より大規模・高速性が求められる環境ならばNICはシングルよりもデュアルの方が望ましいですし、冗長性を担保する「SMBマルチチャネル」、リモートのノードに対してより高速にアクセスできる「RDMA」といった新たなプロトコルに対応したNICを使うことが推奨されます。
なお、各ノードが搭載するNICが高速化すればするほど、それらをつなぐスイッチがボトルネックになる可能性も出てきます。ご存じの通り、スイッチの増強には相応のコストがかかりますから、2ノードや3ノードといった小規模環境で使う場合には、Azure Stack HCIをスイッチレスで直接接続する構成も選択肢の1つに挙げるといいでしょう。
新たな要件や考慮事項はほとんどないプロセッサとメモリのサイジング
次に、プロセッサとメモリについてですが、「プロセッサとメモリに関するサイジングでは、従来からのHyper-V環境に比べ、Azure Stack HCI特有の新しい要件や考慮事項はないと考えて問題ありません」と佐藤氏は述べました。
プロセッサに関しては、Hyper-Vの要件である1ソケット、2コアが最小要件で、実質的な上限はありません。
ハイパーバイザーの処理に関わるオーバーヘッドを懸念する方がいらっしゃるかもしれませんが、「最近はハードウェアが進化し、プロセッサのパフォーマンスがより向上している背景もあるため、コアに関してオーバーヘッドを加味してサイジングする必要はありません」（佐藤氏）。仮想化と物理コアの比率についても、Azure Stack HCIとして特に汎用的な推奨比はなく、「ワークロードが推奨値を持つのであれば、それを加味して設計してください」としました。
またメモリの最小要件はノードごとに64GBで、上限は特にありません。これもプロセッサ同様に、どういったワークロードを動かすかによって検討するのがいいでしょう。ただし、仮想ストレージにおいてNVMe SSDをキャッシュに使う場合、メタデータの格納にRAM側のメモリを使うことになるため、そのバッファを見込んでおく必要がある点に注意が必要です。
ここまで新生Azure Stack HCIの各リソースについて、サイジングのポイントを説明してきましたが、Azureとの統合を意識した新たな機能も追加されています。その1つが「ストレッチクラスタリング」です。
「ストレッチクラスタリングにより、サイトを指定することによって、1つのクラスターの中で地理的に冗長なクラスターを組むことができるようになりました」（佐藤氏）。たとえば東京と大阪、あるいは異なる二つのビルにまたがるシングルクラスターを組み、自動フェイルオーバーを実現できます。ただしこの場合は最小で4ノード、サイトごとに2ノードが最小構成となります。
Azure Stack HCIは以前から、ブランチオフィスやVDI、高いパフォーマンスが要求されるデータベースの基盤やKubernetesなどコンテナーの基盤、そして高いセキュリティが求められる仮想基盤といったユースケースが推奨されてきました。マイクロソフトではこれら主なユースケースごとにサンプル構成やガイダンス情報をとりまとめ、英文ですが公開しています。こうした情報も参考になるでしょう。
Windows Admin Centerを活用してスムーズに行えるAzure Stack HCIの構築・設定
次に、Azure Stack HCIへの移行方法を見てみましょう。
Azure Stack HCIはAzureとの統合を強く意識し、Azureのサービスの1つとして管理できますが、それと同時にこれまで通り、Windows Admin Center（WAC）との統合も強くケアされています。実はWACにはAzure Stack HCIクラスターセットアップ用のウィザードが追加されており、これを利用すればAzure Stack HCIの構築・設定作業をかなりスムーズに進めることができます。
詳細な情報はWebサイト上のドキュメントに記されていますが、
- OSのセットアップ
- 各サーバー環境の初期セットアップ
- WACからのクラスター作成
という流れで進みます。この手順の中で戸惑うとすれば、各サーバー環境の初期セットアップの部分でしょう。GUIではなくコマンドラインベースで進みますが、「基本的にネットワークインターフェイスを確認してIPアドレスさえ振ってしまえば、あとはWACを用いて、リモートからリッチなウィザードベースでセットアップしていくことができます」（佐藤氏）
ただ、既存のさまざまなシステムからAzure Stack HCIへ移行する方法ですが、残念ながら今の時点では、Hyper-Vレプリカはサポートされていません。現時点ではいったん仮想マシンをオフラインにし、ファイルコピーによって構成も含めたデータ一式をAzure Stack HCIに持っていってインポートするという手順が必要です。
マイクロソフトでは今後、System Center Virtual Machine ManagerでHyper-Vからの移行、そしてVMware vSphere環境からの移行をサポートしていく予定です。今後の続報にぜひご期待ください。
詳しい動画解説を見る
（Azure Stack HCI Bootcamp Japan 第3回）
文：高橋睦美