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はいいぞ。(すくなくとも自分にはあってる)

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

IaaS Casual Talks #1 に参加しました

ご無沙汰しています。
BtoBになるとどこまで話していいものか判断が難しくてなかなか気軽に書けないんですよね。

さてしばらく停滞していましたが、@higebu さんが勉強会を開催されるということで、ちょうどネタもたまっていたので軽く話をさせていただきました。

ちなみに速足だったのであまり話せませんでしたが、Kauli買収直後の状況はこんな感じでした。
Capture2Captureぜんぜんめでたくないし、空中分解した現状をみて改めて↑の方々にコメントをいただきたいところですねw。
VOYAGEとか以前から恨みあったし相当嫌でしたよ。

さて、ESXiなんて貴族のハイパーバイザなんてろくに触ったことなかったんですが、半年もするとだいぶ慣れるものですね。
なにより、サポートが(ryというのもありますが、納得いくまで調べて確実にナレッジにするという基本的な行動方針おかげです。
ちょっとした内容ですが、なにかの参考になると忙しい中作った身としては幸いです。

今回は事前も当日も時間がなくて簡単な内容になってしまいましたが、期末を乗り切った次回はもうちょっとしっかり話をできたらと思います?

あと別件になってしまいますが、今扱っているNutanixについて来月の Nutanix Community Meetup #10 で実際に使った使用感を話そうと思っています。
興味がある方はぜひ参加してみてください。

 

VyOS向け低レイテンシーチューニングTips

すっかり冬模様になりましたね。
雪遊びの準備が全然できてないので、早く仕事を落ち着かせたい今日この頃です。

2015年はKauliが買収されたり、ご自慢のVOYAGEオフィスから締め出されたり、その後転職といろいろありました。
来年は落ち着いた一年になることを心から願っています。

さて久々に糞エントリーを書くのとadvent calendarということもあり、ふわっとゆるい内容でいきたいと思います。

VyOS向けとありますが、VyOS自体DebianなのでLinux全般で使えるTipsです。
低遅延になって何がうれしいかというと、VoIPで音声通話がよりリアルタイムになったり、ネットゲームで有利になったり、VyOSで超高速取引をしてる個人投資家が有利になるとかいい事尽くめです(?)

本来の目的は10Gbps 64byteのショートパケットで、ワイヤレートをだすLVSを作る予定だったんですが、VOYAGEの経営陣に取り潰されたネタです。

チューニングすべき箇所はキューやバッファですが、それぞれネットワークスタックやデバイスコンポーネントの一部として構成されています。
それらのデフォルトの設定はスループット向上や、CPU負荷低減などシステムや回線の利用効率向上に一役かっています。
しかし逆に何をしてもいいから1ナノセックでも早くパケットを処理し送り出したい、そんな要求も世の中にはあります。
今回はそんな人むけです。
なおソケットなどユーザランドは考慮しません。
あくまでルータとしてNICとカーネルまでです。

リングバッファを少なくする

リングバッファはCPUがオンデマンドで処理できない時のために、バッファ領域としてごく小さいメモリ空間として存在しています。
理想はないほうがいいし、あったとしてもメモリ空間なのでレイテンシを気にする場合は効率的に使う必要があります。
リングバッファサイズを小さくすることでヘッドポインタとテールポインタを追跡する処理やガベージコレクトのロスを減らすことができます。
レイテンシを目的とするなら最小値に設定しましょう。

RSSのキューイング先(CPUコア)を固定する

CPUのキャッシュが効率的に使えます。
ntupleとFlow Directorによって、通信条件を指定してRSSのキューイング先を指定できます。

NICのInterrupt Coalescingを無効にする

過大なCPU割り込みを軽減するために、NICはパケットを受信してもすぐ割り込みを発生させません。
特定のパケット数がたまるまで待つ設定がデフォルトでされています。
オフにすればオンデマンドで割り込みが発生し遅延しません。
ただしバーストトラフィックには注意してください。
バースト分がCPUに直撃します。

EISTとC-STATEをオフにする

CPUクロックの変化がレイテンシに悪影響を与えるため、EISTと各C-STATEをすべて無効にします。

・PCIe Link State Power Managementをオフにする

CPU同様にPCI Expressも全力で稼動させます。

NICオフロードについては未調査のため今回はスルーします。
では皆様よいお年を!
(このやっつけ感)

近状とか

ご無沙汰しています。
やっと新しい職場に入ってから3ヶ月がたって、試用期間も終わったところですが、社内のみんなそんなこと信じてくれないか忘れるくらいなじんでます。

普段あまり話さない人から、最近ブログ更新ないし何してるの?って言われたので、いい機会だから近状とかざっくり。

買収直後の辞める面談の時にVGの新経営陣から話だけはされましたが、職歴が汚れるのでVGには転籍せずにKauli所属のまま8月いっぱい有給を消化して辞めました。
引継ぎもあるし年内くらいは居た方がいいかなと思っていたんですが、新経営陣が早く追い出したがってたのでさくっとほっぽりなげて辞めました。
年内でKauliがなくなるから失業したくなければVGに移れ拾ってやる、みたいな物言いだったけど、次の行き先決まってたし。

9月からうってかわって、某ITソリューションプロバイダー()のアカウントSEに転生しました。
生まれてはじめてスーツきて仕事してます。
仕事が集まってきて大変だけど、職場の雰囲気もいいし、無理難題だらけで課題も尽きないので毎日楽しく(?)仕事してます。
むしろVGの騒いでるだけの連中みたいに仕事に派手さを求めない自分にとっては、タダ酒とかゲームできるとかどうてもよくて、落ち着いてて馬鹿が視界に入らない環境のほうが重要ですね。
一度挫折を経験するまでは、とにかく今の職場でがんばろうと思います。

そんなわけで、なにかお困り事ありましたら、こんな最低な自分が直接ご提案にいくことができるようになりました。
ちょっととがったご提案を欲してるときは、自分に声かけてください。
野良不良SEがなんか考えてもっていきます。(ひやかしはやめてね!)

というわけで復帰ついでにSE●LとGI●チームに喧嘩を売るような内容になっちゃうけどVyOSのadvent calendarネタ書かせてもらおうと思います。