本記事は Nutanix Advent Calendar 2018 #1 12月19日分の記事です。
今回はHCI、殊Nutanixには定番なVDIなお話です。
設計に関するちょっとした小ネタを紹介します。
１．VDIとHCIの相性の良さについてのおさらい
様々なところでVDIとHCIの相性の良さは語られているので、
ここでは簡単に紹介、となりますが、
次の理由でHCIが採用されています。
①段階的な拡張に対応できる
VDIは特定部門から徐々に全社展開となるケースが多い。
また、展開するうちに新たな要求事項が発生し、
当初の計画通りでなければならない基盤では、
余計な投資を招くリスクがある。
②IOPS性能の余力と拡張
ユーザがどのような利用をするのかは予測ができない為、
基本的にVDIをサイジングする場合は一般論からの
推測でサイジングを行うケースが多い。
集中型のストレージ装置を用意したケースでは、
費用圧縮の観点から、推測値ギリギリでサイジングが行われ、
致命的な性能不足に陥るリスクを、
ユーザがその性能リスクを負う提案になりがちである。
もしくは、余力はあるが、過剰コストの提案になる可能性がある。
HCIではノードごとでI/O処理が行われ、
その処理はノード内の仮想マシンだけに基本的に注力できる。
その為、性能余力が十分に確保された状況を、
余計な費用なしに実現できるメリットがある。
といったところで、よほど規模や計画が確定的でない限りは、
HCIにしておくことがベストな選択と言えるでしょう。
２．大規模VDI向けのNutanix設計
今回の本題です。
まずは基本的事項から。
VDIにおいてのNutanixの設計は
それほど特別に気を付けなければいけない
設計事項はありません。
そのままでも十分使ってもらえます。
ただ、ここでご紹介したいことは、
環境が大規模（数十ノードレベルの環境）になった時の話です。
基本的に、Nutanixには他の製品と違って、
クラスタ内の拡張レベルに制限はありません。
何十ノードを一つのクラスターとして、
大きなクラスターを構成してもらっても構いません。
ただし、少し考慮した設計をすることで、
運用のしやすさを向上することができます。
例えば、AOSのバージョンアップを考えると、
日本のお客様はエンドユーザさんに
「システム停止するので、使わないで」
と停止調整をするケース、多いのではないでしょうか。
AOSのバージョンアップも比較的高速なので、
休日の時間を使えば何とかなるのでは、
ということありますが、
もし「停止可能な時間がまちまち」だった場合は
どうしますか？
このようなケースでは、
年末年始やゴールデンウイーク、お盆など、
全社的な休みを狙って実施することになりますが、
情報システム部門の方は、貴重なお休みを
費やす結果となってしまいます。
これを回避する簡単な設計方法が、
サービス提供日程の違うNutanixクラスターを複数用意して、
それぞれのデスクトッププールも、
そのクラスタに合わせて所属させる、という設計です。
つまり利用傾向を揃える、ということですね。
分割の仕方は以下のイメージです。
このやり方をすると、
メンテナンス単位が各Nutanixクラスターに限定されるため、
実運用する上では停止調整をする範囲が、
かなり限定されます。
事業部ごとで同じような利用傾向を
予めまとめていますので、
停止調整の計画が非常に立てやすくなります。
＃ここれは例で事業部にまとめていますが、
＃職種などで傾向が付けばそれでもOKです。
また、サイズが小さくなるために、
１メンテナンスあたりの所要時間が短くなったり、
万が一の障害時も、影響範囲を限定することで、
全社的な業務が止まるリスクを回避できる、
といったメリットもあります。
これらのメリットから、
通常の休日や平日夜間を利用した
メンテナンスを実行しやすくなり、
かなり運用しやすい基盤となります。
ちなみにNutanixではノードの切り離しや
再参加がしやすいという特徴があります。
業務特性に変化があった場合は、
クラスター間でノードを融通することで、
調達したノードを無駄なく利用可能です。
今回は、VDIの設計について、
TIPS的な話を取り上げてみました。
VDIは止まると即業務影響という点では、
かなりミッションクリティカル度の高いインフラです。
こういった工夫も欠かさないことを、
ぜひおすすめしたいです。
今回は以上です。
明日は、沢山のNutanix関連記事を供給し続けている、
レノボ小宮さんの記事です！
