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はいいぞ

ハイパーコンバージド製品(Nutanix)をエンタープライズで使って思ったこと

だいぶご無沙汰しています。

とある案件をきっかけに、社内ではNutanix & Azure屋が定着してしまいました。
オンプレ自作の魂の結晶のような働き方をしていましたが、環境が変われば人間変わるもんだなと思いました。

さて、昨今Nutanixを皮切りに各社からリリースされブームが巻き起こっている「ハイパーコンバージド」と称されるアプライアンス類ですが、ブームに半して個人的に心配していることがあります。

それはハイパーコンバージドと呼ばれているコンセプトを理解せず、「コストが安い」「拡張性がある」「ハイブリット構成が作りやすい」など、メリットや機能面ばかり押し出していて、本来目指すべきであるゴールを考えている人(考えられる人)がまだまだ少ない点です。
ついでにNutanixに限って言えば、アーキテクチャを理解してる(できる)人も少ないです。まあこれはエンタープライズな現場にいるせいかも。

でまあ、例えば以下のような矛盾を指摘します。

・コストが安い
別に安くないし、同じ容量で安いストレージならソフトウェア + IAサーバとかでよければいっぱいある。
有名なところだと例えばRAIDIXとか。
そうじゃないねん。

・拡張性がある
スケールアウト型のストレージなんていっぱるあるがな。

・ハイブリットなクラウド構成が作りやすい
これは同意。でパブリッククラウド使えるの?

あと勘違いで多いのが、クラスタで「CPUとメモリを共有できる」というのも多いです。
Nutanixに限って言えばあくまでストレージです。
CPU、メモリは物理ホスト上のみでしか展開できません。

ものすごーーーい複雑にできてるものを簡単に見せてるので、アーキテクチャや概念を理解しないままではミスマッチしか起こしません。
自分は日本のIT業界の歴史からこの懸念をすごい持っています。
とりあえず仮想化だけしておけばええやろ、みたいな。

では現場レベル、設計や運用者からみたハイパーコンバージドとはなんなのか。

自分は、「ソフトウェアの実装によるハードウェアレイヤーを抽象化すること」と説明しています。
自前で持つパブリッククラウドに近い感じですね。
実際ものの値段みた感じNutanixの大半ってソフトウェアと保守費用だと思います。

ハードウェアの抽象化って、うちのグループの某部隊もそうですが、物理コアとvCPUの数合わせるとか、ストレージの容量をLUNのパーティショニングで決めるとかやってる人々には、異次元の世界なんですね。
自分は仮想化を日本型と欧米型の二種類に勝手に分類しています。

日本型は仮想化するにも関わらず、大事なことだから2回と補足をつけて言いますが、VMwareのサイジングガイドなんぞ無視して、物理コア = vCPUという分けのわからないサイジング方式が根付いてるため、仮想化するコスト的なメリットが薄いです。
実際リソースはだだあまりしています。
(ライフサイクル運用が楽になるだろとかは後述)

上記日本型に対して欧米型は「リソースのプール化」が目的です。

欧米型はだだあまりしているリソースをプール化して有効活用してしゃぶりつくそう、というのが目的です。
これがハードウェアを物理の制限から解放する物理リソースのプール化です。
自分はこれを真の仮想化のメリットととらえています。

なので、日本のエンタープライズSEが好んで実行しているリソース分割型の手法では、そもそもハイパーコンバージドという考え方はマッチしません。

随時必要な時に必要な、CPU、メモリ、ストレージを足していって無限に拡張できる、これがハイパーコンバージドの目的と自分は考えます。

実際現場でみていると、ハイパーコンバージドとリソースプール化の概念をもっているSEは出会ったことがありません。

予算が組めないよーっておっしゃる人もいると思いますが、以下の2パターンどちらがいいと思いますか?社風もあわせて考えてみてください。

・一括で予算を決めて5年間はなにがあっても走り切る、そしてその後また同じ大規模リプレース後基盤移行作業
・1年ごとに予算を決めて小さい規模で拡張とリプレースをし続ける、基盤自体の移行作業は不要

という残業して帰ってきて疲れてかいた駄文でした。
Nutanixはいいぞ。(すくなくとも自分にはあってる)

あと仮想化にまかせた冗長化は微妙だからアプリレベルでも確保したほうがいいよ!