はじめに
この記事はNutanix Advent Calendar 2019(4枚目)、12月24日分です。
気づけばNutanix Advent Calendarへの参加は3年連続3回目です。
Nutanix Advent Calendar 2019(1枚目)
Nutanix Advent Calendar 2019(2枚目)
Nutanix Advent Calendar 2019(3枚目)
お断り
この記事ではNutanixの運用をしていてハマったことの一例を記載します。
「Nutanixのココでハマった！」と少しセンシティブな表題ですが、これらはすべて
・アーキテクチャを理解した設計をする
・マニュアルをきちんと読む
・ベストプラクティスに準拠する
を守っていれば起き得ないことであり、この記事で私が言いたいのもコレに尽きます。
はまったこと。
なぜかLCMがらみが多いです。
オカルティックなお話しですが、私は10年ほど前からファームウェアと非常に相性が悪いからだと思います。
例えばProLiantサーバで、私がSystem ROMを上げると高確率でボード障害が起きますが、その他のメンバーではこういった事は起きません。
その変わり、同じ事をやると高確率でDVD-ROMが故障する人がいます。(これ、なんでだろ…)
LCMを使ってFirmwareを上げていたらホストの再起動後、Phoenix が起動した状態で止まってしまいました！①
原因は、IPMIポートにLANケーブルが挿されていなかったからです。(IPアドレスは設定していました)
hypervisor問わず、IPMIポートにLANケーブルを挿し、IPアドレスを設定することがリコメンドされていますね。
LCMはFirmwareをアップデートするとき、ざっくり以下のような動きをします。
・AHVホストを再起動
・Phoenix を起動
・IPMI経由でisoをマウント
・ファームウェアのバージョンアップ
・再起動、しAHVホストが起動したら次のノードへ
せっかくリコメンドされているのに、それをやらないと、こういう罠？にハマります。
なお、IPMIはAHVノードのeth0とShared Portだったはずであり、IPMIポートにLANケーブルが挿さっていない以外にも、何か原因があったかもしれません。
LCMを使ってFirmwareを上げていたらホストの再起動後、Phoenix (以下略 ②
LCMを利用して、Firmwareを上げていたところ、ホストの再起動後、Phenixが起動した状態で止まってしまいました。
ノードを本番クラスタに入れる前、Single Node Clusterを組んでFirmwareをあげておこうとしたところ、こうなりました。
原因はそのまんま、Single Node Clusterだからです。LCMはSingle Nodeクラスタはサポート外です。マニュアルに書いてあります。
https://portal.nutanix.com/#/page/docs/details?targetId=Web-Console-Guide-Prism-v510:upg-firmware-upgrades-c.html
きちんと読みましょう！(ごめんなさいたま！)
LCMを使ってFirmwareを上げていたらホストの再起動後、Phoenix (ry ③
この時、ちなみに①を経験していたため、IPMI周りは既に完璧にしています。
LCMの不具合を踏んでいました。この不具合は以下の条件で発生し、私がいる環境ではこれに該当していました。
・ブリッジが2つある
・対向スイッチでLACPまたはStatic LAGを有効にしている
この不具合は、LCM 2.3およびFoundation to 4.5.1で修正されています。
https://portal.nutanix.com/#/page/kbs/details?targetId=kA00e000000PVpbCAG
昔ながらの？仮想インフラの設計において、以下の用途に対して、それぞれ個別のvSwitchを作成し、明示的に通信を分けることはよくあることかと思います。
・Hypervisor(Migrationを含む)
・ストレージ
・仮想マシンのサービス
Nutanix AHVはHCIであるため、上記のHypervisorとストレージはほぼ同義であり、当然同一のブリッジである必要があります。(ブリッジ内では異なるVLANにセパレートすることは可能です)
したがって、AHVの場合、問題になるのがHypervisorと仮想マシンのサービス別のブリッジに分けるか否か？ですが。これを無理に分ける必要ってあるのでしょうか？Nutanixに関して、私はこれに合理的な答えを見つけられずにいます。(私がいる環境の場合、別の要因で分けざるを得なかったのです、、、)
AOS 5.10よりAHVノードに対するブリッジの追加は、クラスタに参加した後にしかできなくなりました。この変更は、「これって無理に分ける必要ってあるの？分けない方がシンプルじゃん」というメッセージのように感じます。Nutanixのアーキテクチャを考えるに、トラフィックごとにブリッジと線を分けるより、線そのものを増やして、LACPなどでロードバランスをした方がパフォーマンスがでるはずです。(間違ってたらごめんなさい)
現在、AHVは仮想マシンに対するネットワークのQoSの機能がありませんが、将来的に実装されるのでは？と個人的には期待しています。
ちなみに、vSANの場合、vSANトラフィックをその他のトラフィック、と同一のvSwitchで処理させる場合、分散仮想スイッチのNetwork I/O Controlでバンド幅を確保するのがベストプラクティスだった記憶があります。
vSANの話を出しましたが、どちらが優れている、という訳でなく、それぞれのアーキテクチャに合わせた設計をしましょう、ということですね。
おわりに
実名は伏せさせていただきますが、日頃よりお世話になっておりますNutanix社の担当営業およびSEの方々や丁寧に回答をいただけるサポートの方、さまざまな支援をくださる販社の皆さま、技術情報を発信されている方々に敬意を表するとともに、心より御礼申し上げます。ありがとうございます！今後ともよろしくお願いします。
おまけ
実はNutanix社の株主だったりします。1株。
Nutanix社に限らず、業務で関わった思い出深いプロダクトの株式を1株だけ買う「思い出株」という活動を、昨年から始めました。
円高と株価の下落、1株だけのため割高な手数料で目も当てられないことになっていますが、投資目的ではないので何も問題はないです。
