2021年7月23日金曜日

Nutanix LCMのおさえておきたいポイント

今まで数回にわたってLCMについて記載をしてきました。LCMは頻繁にバージョンアップが行われており、機能が常に増えております。

今日は2021年7月現在のLCMの事情とLCMの動作ポイントについてご紹介していきます。


Q.LCMとSoftware Updateはどう使い分ければ良いのですか?

最近大変多く聞かれるご質問の一つです。従来Nutanixは、ソフトウェアのアップデートを簡潔化するためOne Click Updateという名のもと、AOSやハイパーバイザーのローリングアップデート機能を提供しました。さらに、NXモデルのファームウェアアップデートなども出来るようになりました。しかし、ファームウェアーのアップデートは、自らは必要なファームウェアを外部サイトから取得し手動でアップロードすることと、対応ハードウェアがNXのみのサポートであったことから、どのハードウェアでも快適に動作するHCIソフトウェアを提供するNutanixとしては、特定のハードウェアでしか利便性を享受できないのは、ユーザーにとって選択の自由を満たしていないことから、ソフトウェア・ハードウェアを含めバージョン管理を行う仕組みとしてLCMが誕生しました。
現在Software Updateの機能は順次LCMに移動しており、現在はAHVやAOSは、LCMからのアップデートとなりました。HPE ProLiant DXは、DELL XC Coreなどのハードウェアプラットフォームのファームウェアのアップデートも対応しています。
現行Software Updateをご利用頂くケースは、vSphere ESXiのアップデートとなります。(こちらも近々にリリースされるバージョンでLCMで対応予定です)それ以外のアップデート(FilesやFoundationなど)は、LCMを最新版にすることでLCM経由でアップデート可能となりますので、まずはLCMを最新版にすることから始めて下さい。



Q.Nutanixクラスターが直接インターネットに接続していない環境では、LCMを利用するためにWebサーバーを用意しないといけないのですか?

この回答は基本的にYESなのですが、LCM2.4のバージョンアップにて一部ですがWebサーバー不要でアップデートが可能になっております。具体的には、Nutanix Support Portal経由で取得したLCM専用バイナリをLCMの画面でアップロードする形となります。
LCM2.4時点でバイナリのダイレクトアップロードに対応しているのは、以下の通りです。

  • AOS
  • AHV
  • Nutanix Files
  • File Analytics
  • Foundation
  • NCC
また、LCMにアップデートするファイルは「lcm_softwarename_version.tar.gz」の命名規約に従ったファイル名のLCMアップデート専用のバイナリが必要になります。

▼LCM2.4から搭載されたダイレクトアップロード機能




Q.1ノードクラスターはLCMは利用できないのですか?

こちらは、従来のAOSでは明確にLCMは利用できませんでしたが、AOS5.15以降で順次実装が変わっております。LCM2.4時点でのご案内としては、シングルノードにおいては、「ファームウェアのアップロードが不可」というだけで、AOSやハイパーバイザーなどのアップデートはLCMを利用したアップデートが可能となっております。なお2ノードクラスターの場合は、LCMによるファームウェアのアップデートに対応しています。
この理由ですが、LCMにてファームウェアをアップデートする際、アップデート対象ノードのブート領域にあるPhoenix領域からLinuxが起動し、その後稼働中のクラスターメンバーのCVMと疎通してバイナリファイルを取得・アップデートを行う動作をしています。1ノードのクラスターの場合、自信がPhoenixモードになると、他のCVMがクラスター内に存在していないためファームウェアを取得するCVMが存在しないため、1ノードにおけるファームウェアアップデートは未対応となります。



Q.ファームウェアのアップデートを行ったら、途中でFailし該当のノードがLinuxシェルの画面のままになっていて再起動してもハイパーバイザーは起動せずLinux(Phoenix)が起動する

基本あまりあってほしくないのですが、何らかの理由でLCMを経由したファームウェアのアップデートに失敗した事象になります。ファームウェアのアップデートに失敗する事象は様々な原因があります。たとえば、Phoenixモードになった際、他のCVMとうまく疎通が出来ずにファームウェアバイナリが取得できなかったなども要因としてあり得ます。
こういった、Phoenix(簡易Linux)で起動したものの処理が継続できない場合、このPhoenixが起動したままで、ハイパーバイザーが自動で再起動しない仕様に現在なっています。この場合、ハードウェアで強制リセットをかけてもまたPhoenixが起動し、ハイパーバイザーは起動しません。

万が一このような事態に陥った場合、Phoenixの画面から以下のコマンドを入力することで、ハイパーバイザーの起動モードに戻すことが出来ます。

python /phoenix/reboot_to_host.py

アップデートに失敗した場合、ログ取得などを行う必要もありますので、別途以下のKBも参考にしてください。

KB9437:How to restore a node from LCM firmware upgrade failure using lcm_node_recovery

KB4520:Host stuck in Phoenix after LCM firmware upgrade failure


ファームウェアアップデートにおいては特定モデルと特定のファームウェアバージョンにおいて失敗するケースが見受けられます。アップデートの際は、LCMのリリースノードを一度確認した上でのアップデートをおすすめいたします。

LCMのリリースノート
https://portal.nutanix.com/page/documents/details?targetId=Release-Notes-LCM:Release-Notes-LCM


アップデートに失敗した場合LCM側でFailと認識されますので、失敗の原因調査の上(リリースノートの確認やサポートへのCaseOpen)再度ファームウェアアップデートを実行していただくこととなります。