Dell XC モデルのFirmware更新（LTS 6.10）

 この記事は Nutanix Advent Calendar 2024 の12月4日分として執筆しました。

本記事の概要

Dell XCモデルにおけるFirmware（FW）更新の仕組みと特長について、調べたことをまとめています。

 

Dell XCモデルのFW更新の大まかな仕組み

FWの更新を実施するのはiDRAC と呼ばれるサーバ側の管理モジュール（いわゆるBMC）です。

NutanixのLCM FrameworkはiDRACに対してFWファイルのアップロード＆更新のインストールを実行することでFWを更新しています。

その際に、LCM FrameworkからiDRACへの接続性はTCP/IPを利用しています。

通常、iDRAC(BMC)に接続する際はサーバに設けられている専用ポートにネットワーク設定を施すことで外部から接続（Out of band）が可能になりますが、XCモデルの場合は専用ポートを利用していません。代わりにサーバ上のOS（AHV）に仮想NICを認識させることで外部ネットワークを経由せずにサーバ内部の通信で完結させています。

具体的にはiDRACの機能でAHVに対して仮想のUSBNICを認識させており、AHVはそのUSBNICを利用することでサーバ内部の通信のみでiDRACにTCP/IP接続をすることができるということです。この接続パスを経由して、Redfishと呼ばれるAPIにてiDRACに対してFWファイルのアップロードと更新のインストールを実行することができています。

 

 

仮想NICについて

仮想NIC自体はUSBNICという形でAHVが検出することができます。（iDRACのOSパススルーの仕組みを有効化している必要があります。アプライアンスなので工場出荷時点で設定済み）

このUSBNICを経由した通信はiDRACにのみ伝達され、サーバの外部に通信が漏れることはありません。

LTS 6.5 (el7)までは、AHVにiSM（iDRAC Service Module）と呼ばれるモジュールがインストールされており、このiSMが仮想NICの検出と設定を実施していました。一方で、LTS 6.10(el8)ではiSMを利用せず、cdc_etherというドライバーを利用することで仮想NICを認識させ、Ethernet通信が可能な状態にしています。

 具体的に実機で確認をしてみました。

Dell XCモデルのAHVにログインして、dmesg を見るとcdc_ether が idrac というイーサネットデバイスを登録していることがわかります。

AHV起動後は以下のようidrac という名前でデバイスが認識されていることがコマンドで確認できます。

ただしこの状態ではIPアドレスが振られていないため、iDRACに接続することができません。

この状態でPrism ElementのLCMからInventoryを実行するとlcm_ops.out から以下の処理を確認できました。

ざっくりと処理の流れを説明すると、ipmitoolコマンドを利用してiDRACからUSBNICに関する情報を取得しています。

ipmitoolコマンドによる確認の結果、このハードウェアではUSBNICが有効であり、かつiDRAC側のIPアドレスが169.254.0.1であることが判明します。 

その後ethtoolコマンドでidracインターフェースを特定し、そのインターフェースに対して169.254.0.6のIPを設定している。

最終的にidracインターフェース（169.254.0.6）からiDRAC（169.254.0.1）へのPing疎通を確認しています。

上記の出力は、その後Ping疎通確認までとなっていますが、この後はRedfish APIを利用することでiDRACからサーバハードウェアやFWの情報を取得したり、FWの更新を実行したりできます。

 

Redfish APIについて

Redfishはサーバ管理のために標準化されたAPIです。iDRACだけでなく様々なサーバベンダが提供するBMCで対応しているプロトコルです。

Redfish自体についての細かい説明は省きます（というかそんなに知りません）が、Redfish APIを利用することでiDRACからハードウェアに関する情報取得や各種設定や変更操作が行うことができます。 

 

Dell XCモデルのFW更新のメリット

Dell XCモデルのFW更新の仕組み（仮想NIC＋Redfish）を採用したことによるメリットを考えます。

１つのメリットとしては、Nutanix LCMを利用したFW更新時間が短くなる、という点だと思います。

通常のNutanix LCMによるFWのアップデートの場合、Phoenix OSという専用のOSが立ち上がる仕組みになっています。そのため、実際にFWの更新を実施する前の段階でPhoenix OSを起動するため再起動が発生し、さらにFWの更新のための再起動が発生し、最後にAHVを起動するための再起動が発生します。

そのため、仮に該当のFWがサーバの再起動を必要としないもの（BMCなど）であったとしても、Phoenix OSの起動～AHVの起動で最低2回の再起動が発生しますし、再起動を必要とするFW更新があると、その分再起動が増えていきます。

サーバーの起動プロセスにおいてはPOSTや、各種デバイスやFWの初期化など、さまざまなステップを経由する必要があり、さらにブートローダーとOSの起動にも時間がかかるため、単純な再起動の場合でも5分以上かかることもあります。

仮に１つのFWの更新のために3回の再起動が走るとなるとそれだけでも15分かかる計算です。

一方で今回調べたDell XCモデルの仕組みであれば、FWが複数ある場合でも最大1回の再起動に抑えることができる（iDRACの機能で複数のFWを一度に更新できる）ため、再起動回数を大きく削減できます。

 仮に、Phoenix OSを利用した仕組みの場合はAHVとFWの更新で合計5回（※１）の再起動が発生すると仮定すると、Dell XCモデルの仕組みと比べたとき、1ノード当たり15分程度多くの時間がかかることになります。

※１） 個別の再起動が必要なFWが2つ以上あると仮定。AHV,Phoenix,FW#1,FW#2,AHV の合計5回

10ノードクラスタの場合、最終的に150分（2.5時間）の違いになります。

2.5時間を大きいとみるか小さいとみるかは運用における考え方次第と思いますが、この時間は常に冗長性が低下（※２）していますし、またアップグレード作業時間がメンテナンスウインドウに収まるか否かによってクラスタサイズの設計に影響を与えるため、運用観点においては短くて悪いということはありません。

※２） AOS 6.8以降はデフォルトでスマートリビルドが有効なため。

そのほか時短以外のメリットとしては、FWのアップデートに関してiDRACの標準機能とRedfish APIのみを利用しているため、FW更新自体の品質向上とトラブルシューティング時の切り分けやワークアラウンドが容易になるというメリットも考えられます。

 

Nutanix LCMのFW更新機能についての留意事項

いわゆるコンプライアンスチェックの機能は存在しないようです。もちろんInventoryを実行した際に、最新のLCMバンドルと比較して実機のFWバージョンが低いものがあればUpdate Neededという形で知らせてはくれるものの、逆にLCMバンドルのFWよりも新しいバージョンが当たっている場合においては、手動で確認しない限りバージョンドリフト（バンドルとのずれ）をNutanix LCMの機能内で知ることはできないようです。

運用においてはパーツ交換などの際に想定よりも高いバージョンのFWが当たってしまう可能性があり、一貫性のないFWバージョン利用となってしまうリスクがある点は留意が必要です。

一般的にはFWは新しければ問題はないことが多いですが、新しいことで逆に不具合を引くケースもなくはないので、パーツ交換などをした場合はFWを確認しておく方が推奨です（Nutanix環境に限った話ではないですが）。
FWのバージョン管理機能が必要な場合は、別途サーバベンダーが提供するサーバ管理ツールなどを検討するのが良いです。

パーツ交換などの後で、もし想定よりも高いFWバージョンになっていることを確認した場合、ユーザ判断でダウングレードを実施せずに必ずベンダーに問い合わせた方が良いです。場合によってはダウングレード不可（明示的にOKとしている方が少ないかも？）としているケースがあり、最悪のケースではダウングレードによってはパーツが使えなくなったり、サーバ起動しなくなることもあります。

おわりに

本記事ではDell XCモデルのFW更新機能について調べたことを紹介させていただきました。

HCIの機能としてサーバのFW更新まで実行（複数ベンダー対応）ができ、必要なバージョン選定が事前定義済みであり、かつFWファイルのNutanixのサイトからダウンロードできる（インターネット接続があればワンクリック）点は非常に便利だと思います。

Nutanixはソフトウェアソリューションであり、基盤（ハードウェア）への依存度が低い点も魅力の一つですが、FW管理を疎かにしてよいということはなく、きちんとNutanix LCMの機能で更新していくことが推奨されます。

せっかくの便利な機能ですのでぜひともご活用ください。