Nutanixの構成を考える時に知っておくといいかもしれないこと

普段Nutanixの構成を組むうえで普段考えてることを軽く説明としてまとめました。
ある程度要件をベンダーに伝えれば構成を組んでくれますが、自分のようにお客さんに直接セールスする場合は、聞き取りからNutanixを組み合わせるための知識が必要ですので。
間違いがあったら指摘お願いします。

このエントリーを書いている時点でざっくりと思いつくかぎり以下のとおりです。

– CPUリソース
– メモリリソース
– ストレージキャパシティ
– フラッシュ領域
– 筐体冗長性(Blockawareness)
– ハードウェアの冗長性

CPUリソース

ハイパーバイザにもよりますが、事前にリソースのサンプリングができる場合はVMwareのクロック足し算方式を使います。
この場合問題となるのはNutanixのCVMのオーバーヘッドの見積りです。
NutanixのCVMは設定上8コアをアサインする為(実際は8コアリソースをフルに使うわけではない)、従来のコア数分割方式を使うと相当のリソースに余りが発生してしまいます。
CVMが実際に消費するリソースはシステム全体の数パーセントと言われています。
またハイパーバイザのタスクスケジューラがすべてのCPUタスクを一度ばらすため、コア数固定のvCPU割り当ての考え方はナンセンスとしか言いようがありません。

脱線しましたが、多めに見積もってもCVMのオーバーヘッドはシステム全体の10%も見ておけば十分です。
実際に検証したところ、VDI100クライアントをNX3460の1ノードにフルのワークロードをかけた場合のCVMのリソース消費量は2GHz前後でした。
24コア2プロセッサーモデルT/Bなしで見積もり、2.4GHz * 24 = 総量57.6GHzなので大体10%前後という考えはあっていました、
あとはHV自体のオーバーヘッドを引けば実際にユーザVMが使えるCPUリソースが算出できます。
また極端に特定のCVMにワークロードがかかる場合は別ノードのCVMにバイパスして負荷分散することも可能です。

メモリリソース

これもまずCVMのオーバーヘッドを考慮します。
実際にCVMにアサインされたメモリをオーバーヘッドとします。
メモリは全体から見るとそんなに高いものではないので、最低でも全スロット16Gモジュールにしています。
もしメモリ不足が発生した場合、ハイパーバイザのメモリ圧縮やスワップアウトが発生して、CVMのインライン処理のパフォーマンスに影響が出てしまいます。

ストレージキャパシティ

Nutanixは内部的にキャシュ領域やCVMのオーバーヘッドがあるため容量の計算方法が複雑です。
一般的には公式のサイジングツールを利用します。
またBOMといって構成情報をそのままエクスポートできるので、ベンダーに構成の相談をする場合などに重宝します。
https://services.nutanix.com/

ストレージ容量の構成は単純に必要なキャパシティ容量のHDD/SSDを搭載していくだけです。
ファイルサーバなどストレージ用途等で極端に大きなキャパシティ容量が必要な場合は、HDDを大量に搭載できる(ただしユーザVMが動かせない)NX-6035Cなどヘビーストレージモデルも検討してください。

フラッシュ領域

DB用途などフラッシュのI/Oになるべく乗せたいという要望があると思います。(オールフラッシュモデルもありますが)
NutanixはエクステントストアというSSDとHDDのハイブリットで構成された、永続的にデータを保存する領域があります。
CVMは以下の階層で書き込み処理を実行します。

ローカルのSSD->ローカルのSSD2個目->クラスタ内ノードのSSD->HDD

SSDのエクステントストアがフルになると、設定された容量分だけHDDエクステントストアにデータをマイグレーションしSSDエクステントストアの空き容量を確保します。
またマイグレーションされたデータは常にモニタリングされ、必要に応じて移動されます。

SSDエクステントストアのサイズはの先程のNutanix Sizerで確認することができます。

リードについてはユニファイドキャッシュという透過的に動作するメモリとSSDからなるキャッシュ層があります。
ただ永続的ではないので、エクステントストアの容量で単純に計算したほうがトラブルがないでしょう。

ちなみにエクステントストアのSSDはパフォーマンス層やホットティア、HDDはキャパシティ層やコールドティアと呼ばれています。

筐体冗長性(Blockawareness)

Nutanixには筐体故障からデータを保護するBlockawarenessという機能があります。
RF2では1ブロック、RF3では2ブロックの故障まで保証されます。
ただし、故障発生時にデータの再配置が自動で実行されるため、再構成が完了後であればストレージの容量に余裕があれば、さらに追加で故障してもデータは保護されます。(CPUリソースは減っていきますが…)

Blockawareness構成の組み方ですが、クラスタ内の1ブロックに搭載されているノードの最大数の2倍の数が他ブロックにあることが必要です。(RF2の場合)
必要な条件がそろった時点で自動でBlockawarenessとなります。

少ないノード数でクラスタを構成する場合は、1ブロック1ノードや2ノードモデルを採用するとBlockawareness構成を組みやすくなります。
どのみち日本は100Vが主流なので、1ブロック2ノードモデルが最適かと思います。
参考ですが、必要となる電圧は「Hardware Administration and Reference」に書いてあります。

ハードウェアの冗長性

従来のインフラ基盤を運用してきたエンジニアはまずこの概念を変えないといけません。
なぜならNutanixで冗長化されているハードウェアコンポーネントは電源ユニットのみです。
ディスクはRAIDではありませんし、メモリミラーリングも使用しません。

Nutanixはソフトウェアによるミラーリングや、ノードのクラスタリングでデータを保護しています。
クラスタノード間でデータを複製するため、仮にノードが1台故障(たとえばハイパーバイザがインストールされたSATA DOMの死亡とか)したところでデータは消失しません。
これがNutanixは最低3ノード必要といわれる理由です。

RAIDなどノード単体に頼った冗長化を個別に実施してしまうと利用効率が低下します。
逆にNutanixはクラスタを構成するノード数が増えれば増えるほど、RAID構成と比較して利用効率が向上していきます。
セールスエンジニアは顧客から聞かれることが多い質問なので、概念を理解し説明できるようになっておいた方が有利です。

いろいろ書きましたが実際触って考えて悩んでみるのが一番早いと思いました。
Nutanixはいいぞ

コメントを残す

メールアドレスが公開されることはありません。


*