SambaRack Manager のファームウェア更新

本ガイドでは、snctl firmware コマンドグループを使用した、SambaRack ハードウェアコンポーネントのファームウェアの監査とアップグレードについて説明します。

主要な概念

まず本セクションに一度目を通してください。以降の内容はすべて、次の 6 つの前提に基づいています。

前提条件

ファームウェアコマンドは対象デバイスに対して認証を行うため、先にデバイス認証情報を登録しておく必要があります。デバイス認証情報をご参照ください。

snctl secret set --device-type bmc
snctl secret set --device-type host
snctl secret set --device-type xrdu

デバイスタイプごとの対応操作

監査できるコンポーネントのすべてが、SambaRack Manager からアップグレードできるわけではありません。

デバイスタイプ	`firmware version`	`firmware upgrade`
`bios`	はい	はい
`bmc`	はい	はい
`xrdu`	はい	はい
`card` (Thor NIC)	はい	はい
`pdu`	はい	いいえ
`serial_terminal`	はい	いいえ
`access_switch`	はい	いいえ
`data_switch`	はい	いいえ
`all`	はい	はい — アップグレード可能なタイプのみ

対象の選択

--rack-id または --group のいずれか一方の指定が必須です (同時には指定できません)。どちらのサブコマンドでも、いずれか一方を指定できます。

snctl firmware version --rack-id 001 --device-type all
snctl firmware version --group production --device-type all
snctl firmware upgrade --group production --device-type bmc

(任意) スロット型デバイスタイプと `--index`

xrdu と card はスロット型 (slotted) のデバイスタイプです。ノードごとに複数のインスタンスが存在するため、--index で操作対象を特定のスロットに絞り込めます。0,2,5 のように、カンマ区切りのリストで指定します。

動作	詳細
`--index` を省略した場合	対象ラック上のすべてのインスタンスが対象になります
有効なデバイスタイプ	`xrdu` と `card` のみ
拒否されるデバイスタイプ	`bios`、`bmc`、`all` — これらにはスロットがありません
`card` の番号付け	ラックタイプのインターフェースリスト内の位置によってネットワークインターフェースを選択します — `snctl firmware version --device-type card` の `Slot` 列に表示される番号と同じです
インデックスに一致するものがない場合	エラーになります。存在しないインデックスと利用可能なインデックスを報告し、何も書き込まずに非ゼロで終了します

XRDU では 2 つのコンポーネントを書き込む

各 XRDU には、それぞれ独立して書き込まれる 2 つのコンポーネント — OBMC と RDU-C — が含まれます。firmware version では両者は別々に報告され、イメージを手動で渡す場合は両方を個別に指定する必要があります。

XRDU のアップグレードでは、書き込みツールが電源オン状態のシャーシへの書き込みを拒否するため、書き込みの前にシャーシの電源がオフになります。この電源オフは、--index で指定したスロットだけでなく、そのエンドポイント配下のすべての XRDU に適用されます。対象とするスロット数にかかわらず、XRDU のアップグレードはノード全体のメンテナンスとして計画してください。

ファームウェアイメージの入手元

環境	動作
接続環境 (デフォルト)	`--image` を省略します。SambaRack Manager がプランオブレコード (Plan of Record; POR) のファームウェアをダウンロードし、チェックサムを検証してローカルにキャッシュします。同一バージョンを再度アップグレードする場合はキャッシュが再利用されます。
エアギャップ環境	`--image` でファイルを自分で指定します。エアギャップ環境をご参照ください。

キャッシュディレクトリは、snctl config show の Cache Location に表示されます。変更するには snctl config update --cache-location <dir> を使用します。初期セットアップをご参照ください。

ファームウェアバージョンの確認

インストール済みファームウェアを POR と照合して監査します。

snctl firmware version \
  (--rack-id <rack_id> | --group <group_name>) \
  [--device-type <device_type>] \
  [--index <indices>]

フラグ	説明
`-r, --rack-id <id>`	対象のラック (`--group` を使用しない場合は必須)
`--group <name>`	指定した名前のグループ内のすべてのラックを対象にする
`--device-type <type>`	`all` (デフォルト)、または対応表にある任意のタイプ
`--index <indices>`	`xrdu` と `card` のスロットインデックス — スロット型デバイスタイプをご参照ください
`--protocol <protocol>`	デフォルトのプロトコルを上書きする: `ssh`、`rest`、または `redfish` (エンドポイントに依存)
`-o, --output <format>`	`text` (デフォルト)、`wide`、または `json`

snctl firmware version --rack-id 001 --device-type all

Rack  Node             Component  Status  CURR   POR
----  ---------------  ---------  ------  -----  -----
001   sn40l-16-001-n1  BIOS       PASS    2.4.1  2.4.1
001   sn40l-16-001-n1  BMC        FAIL    1.07   1.08

  1 racks: 1 ok, 0 failed  (12.4s)

出力の読み方

列	意味
`CURR`	現在インストールされているバージョン
`POR`	POR の目標バージョン
`Status`	両者が一致していれば `PASS`、異なれば `FAIL`、コンポーネントを読み取れなかった場合は `ERROR`

FAIL はファームウェアが最新でないことを意味します。コマンドが失敗したわけではありません。チェック自体は正常に実行され、バージョンの不一致を正しく報告しています。

XRDU の 2 つのコンポーネントは、別々の行で報告されます。

Rack  Node             Component    Status  CURR   POR
----  ---------------  -----------  ------  -----  -----
001   sn40l-16-001-n1  XRDU/0/OBMC  PASS    5.1.4  5.1.4
001   sn40l-16-001-n1  XRDU/0/RDUC  FAIL    5.1.2  5.1.4

wide 出力

-o wide を指定すると、Protocol、Model、Source の各列が追加されます。Source は POR ファームウェアのアーティファクト URL で、エアギャップ環境でのアップグレードに必要です。

snctl firmware version --rack-id 001 --device-type bios -o wide

Rack  Node             Component  Status  CURR   POR    Protocol  Model     Source
----  ---------------  ---------  ------  -----  -----  --------  --------  ------------------------------------------
001   sn40l-16-001-n1  BIOS       PASS    2.4.1  2.4.1  redfish   SN40L-16  gs://<bucket>/firmware/bios/2.4.1/bios.bin

ファームウェアのアップグレード

ラックのコンポーネントにファームウェアを適用します。

snctl firmware upgrade \
  (--rack-id <rack_id> | --group <group_name>) \
  --device-type <device_type> \
  [--image <path>] \
  [--index <indices>]

フラグ	説明
`-r, --rack-id <id>`	対象のラック (`--group` を使用しない場合は必須)
`--group <name>`	指定した名前のグループ内のすべてのラックを対象にする
`--device-type <type>`	`all`、`bios`、`bmc`、`xrdu`、または `card` — 必須
`--image <path>`	ローカルのファームウェアイメージ。任意 — 省略時は自動的にダウンロードされます
`--index <indices>`	`xrdu` と `card` のスロットインデックス — スロット型デバイスタイプをご参照ください
`-p, --parallelism-racks <n>`	同時に処理するラック数の上限 (デフォルト `1`)
`--parallelism-devices <n>`	全ラック合計で同時処理するノード数のグローバル上限 (`0` = 上限なし)
`--protocol <protocol>`	デフォルトのプロトコルを上書きする (エンドポイントに依存)

推奨される順序と事前条件

対応コンポーネント間に厳密な依存関係はありません。ただし、複数のコンポーネントをアップグレードする場合は、次の順序で実行してください。 CARD → BIOS → BMC → XRDU

デバイス	事前条件	アップグレード後の操作	想定所要時間
CARD	ホスト上で `snd` ドライバデーモンがアクティブであること (自動的に待機します)	パワーサイクル不要。ファームウェアバージョンの確認	約 10 分 — アップグレード約 5 分、検証約 5 分
BIOS	ホストの電源がオン	ホストの電源オフ/オン、SR-IOV の確認、ノードのパワーサイクル、バージョン確認	約 1 時間 — アップグレード約 5 分、SR-IOV の無効化と確認に約 30 分、パワーサイクル約 20 分
BMC	なし	パワーサイクル、バージョン確認	約 25 分 — アップグレード約 5 分、パワーサイクル約 20 分
XRDU	ホストの電源がオフ	電源オン、バージョン確認	約 30 分 — アップグレード約 20 分、電源オン約 10 分

BIOS と XRDU では、電源に関する事前条件が正反対です。BIOS はホストの電源オンが、XRDU は電源オフが必要です。

アップグレードの検証。実行が成功してから約 5 分後に snctl firmware version --rack-id <rack_id> --device-type all を実行し、新しいバージョンが反映されたことを確認してください。

使用例

# Upgrade BMC firmware, image downloaded automatically
snctl firmware upgrade --rack-id 001 --device-type bmc

# Upgrade one XRDU
snctl firmware upgrade --rack-id 001 --device-type xrdu --index 3

# Upgrade several XRDUs
snctl firmware upgrade --rack-id 001 --device-type xrdu --index 3,4,5,6

# Upgrade only network interfaces 0 and 3 on every node
snctl firmware upgrade --rack-id 001 --device-type card --index 0,3

進捗の出力

各コンポーネントは書き込み中に段階ごとの進捗を報告し、その後にコンポーネント別の結果一覧とサマリーが表示されます。すでに目標バージョンになっているコンポーネントはスキップされます。

#Example output : THOR Card Upgrade

snctl firmware upgrade --rack-id 001 --device-type card

firmware upgrade  rack=001
[card slot=1] 30% flashing
[card slot=2] 30% flashing
[card slot=6] 100% already at target version — skipping
[card slot=8] 100% already at target version — skipping
[card slot=1] 80% verifying
[card slot=2] 80% verifying
[card slot=1] 100% done
[card slot=2] 100% done
...
OK    card node=node1 slot=1
OK    card node=node1 slot=2
OK    card node=node1 slot=6
OK    card node=node1 slot=8
...

  9 components: 9 ok, 0 failed  (328.7s)

エアギャップ環境

環境から GCS にアクセスできない場合は、--image でファームウェアファイルを自分で指定します。

ダウンロード URL の確認

firmware version -o wide を実行し、アップグレード対象コンポーネントの Source 列を確認します。

snctl firmware version --rack-id 001 --device-type bios -o wide

アウトオブバンドでのファイルのダウンロード

GCS にアクセスできるホストからファイルをダウンロードし、エアギャップ環境に転送します。

gsutil cp gs://<bucket>/<path-from-source-column> ./bios.bin

ローカルパスの指定

snctl firmware upgrade --rack-id 001 --device-type bios --image /path/to/bios.bin

イメージパスの形式

デバイスタイプ	`--image` の形式
`bios`, `bmc`, `card`	プレフィックスなしのパスのみ
`xrdu`	2 回指定し、それぞれに明示的なコンポーネントプレフィックスを付ける

snctl firmware upgrade --rack-id 001 --device-type xrdu \
  --image obmc=/path/to/obmc-5.1.4.tgz \
  --image rduc=/path/to/rduc-5.1.4.tgz

XRDU のアップグレードでは、スロットごとに両方のコンポーネントが報告され、ステージング、シャーシの電源オフ、各コンポーネントのプライマリパーティションとリカバリパーティションへの書き込み、再起動、検証の順に進行します。

[xrdu_obmc slot=2] 3% checking staging space
[xrdu_obmc slot=2] 5% powering off chassis
[xrdu_obmc slot=2] 15% staging image
[xrdu_obmc slot=2] 30% flashing bmc primary
[xrdu_obmc slot=2] 45% rebooting
[xrdu_obmc slot=2] 60% staging bmc
[xrdu_obmc slot=2] 64% flashing bmc recovery
[xrdu_obmc slot=2] 68% staging rduc
[xrdu_obmc slot=2] 72% flashing rduc primary
[xrdu_obmc slot=2] 76% staging rduc
[xrdu_obmc slot=2] 80% flashing rduc recovery
[xrdu_obmc slot=2] 92% verifying
[xrdu_obmc slot=2] 100% done
...
OK    xrdu_obmc node=node1 slot=2
OK    xrdu_rduc node=node1 slot=2
...

  16 components: 16 ok, 0 failed  (1451.5s)

スロットは並列に実行されるため、実際には異なるスロットの行が交互に出力されます。

--device-type xrdu ではプレフィックスなしの --image パスが拒否され、単一コンポーネントのタイプではプレフィックス付きの値が拒否されます。

デバイスタイプ別のアップグレード手順

複数のコンポーネントをアップグレードする場合は、推奨される順序に従って実行してください。 CARD → BIOS → BMC → XRDU

CARD (Thor NIC)

事前条件: ホスト上で SambaNova ドライバデーモン (snd) がアクティブである必要があります。SambaRack Manager は書き込みの前にこれを自動的に待機するため、手動での確認は不要です。

# Auto-download the POR image
snctl firmware upgrade --rack-id <rack_id> --device-type card

# Or flash a specific local image
snctl firmware upgrade --rack-id <rack_id> --device-type card --image /path/to/thor-firmware.pkg

CARD のアップグレードにパワーサイクルは不要です。bnxtnvm による書き込みは再起動なしで有効になります。アップグレード対象の中で唯一、実行後の電源操作を必要としません。

すべての NIC インターフェースのファームウェアバージョンを確認します。

snctl firmware version --rack-id <rack_id> --device-type card

BIOS

事前条件: ホストの電源がオンである必要があります。

BIOS 更新を適用した直後にノード全体をパワーサイクルすると、ホストの電源は入っているのに POST (Power-On Self-Test) の前で停止し、OS に到達しない状態になることがあります。新しい BIOS を確実に適用するには、まずホスト単体をパワーサイクルし、SR-IOV 設定を確認してから、初めてノード全体のパワーサイクルを実行してください。以下のすべてのステップを順番どおりに実施してください。

ホストの電源オンの確認

snctl power state --node <node_id> --type host

# Power on if needed
snctl power on --node <node_id> --type host

アップグレードの実行

# Auto-download the POR image
snctl firmware upgrade --rack-id <rack_id> --device-type bios

# Or flash a specific local image
snctl firmware upgrade --rack-id <rack_id> --device-type bios --image /path/to/bios.bin

ノードの電源オフとホスト単体での起動

--type を省略して、ホストと XRDU の両方の電源をオフにします。

snctl power off --node <node_id>

次に、ホスト単体の電源を入れます。新しい BIOS は POST 中に適用されます。コンソールには BIOS 設定が適用される様子が表示され、OS の起動前にホストが自動的に 1 回再起動することがあります。

snctl power on --node <node_id> --type host

電源オン後、ホストが POST を完了して OS を起動するまで 10〜15 分待ってから、次に進んでください。

SR-IOV の無効化の確認

BIOS で SR-IOV が無効になっている必要があります。該当する属性は PCIS007 です。以下の確認は、BMC に対して直接 Redfish 経由で実行します。BMC の接続情報を収集します。BMC の IP アドレスとユーザー名はノードのインベントリから取得します。BMC 行を確認してください。

snctl node show <node_id>

BMC のパスワードはシークレットストアから取得します。

snctl secret get --device-type bmc --show-value

--show-value はパスワードを平文で出力します。安全な環境でのみ使用し、出力は決して共有しないでください。

取得した値を、以下の <bmc_ip>、<bmc_user>、<bmc_password> に使用します。現在の値を確認する:

curl -s -k -u <bmc_user>:<bmc_password> \
  https://<bmc_ip>/redfish/v1/Systems/Self/Bios | jq '.Attributes.PCIS007'

"Disabled" と表示された場合 — 次のステップに進みます。
それ以外が表示された場合 — 以下の手順で無効化します。

SR-IOV を無効化する (リクエストが成功した場合、出力はありません):

curl -s -k -u <bmc_user>:<bmc_password> \
  -X POST https://<bmc_ip>/redfish/v1/Systems/Self/Bios/SD \
  -H 'Content-Type: application/json' \
  -d '{"Attributes": {"PCIS007": "Disabled"}}'

ホストを再度電源オフ/オンして、変更を適用します。

snctl power off --node <node_id> --type host
snctl power on  --node <node_id> --type host

ホストが起動するまで 10〜15 分待ってから PCIS007 を再確認し、"Disabled" と表示されることを確認したうえで次に進んでください。

ノード全体のパワーサイクル

SR-IOV の無効化を確認できた場合にのみ実行します。snctl power cycle は常にノード全体を対象とするため、--type フラグはありません。

snctl power cycle --node <node_id>

ファームウェアバージョンの確認

snctl firmware version --rack-id <rack_id> --device-type bios

BMC

事前条件: ホストの電源がオンである必要があります。

アップグレードの実行

# Auto-download the POR image
snctl firmware upgrade --rack-id <rack_id> --device-type bmc

# Or flash a specific local image
snctl firmware upgrade --rack-id <rack_id> --device-type bmc --image /path/to/bmc.bin

ノードのパワーサイクルと確認

snctl power cycle --node <node_id>
snctl firmware version --rack-id <rack_id> --device-type bmc

XRDU

事前条件: ホストの電源がオフである必要があります — BIOS の事前条件とは正反対です。

ホストの電源オフの確認

snctl power state --node <node_id> --type host

# Power off if needed
snctl power off --node <node_id> --type host

アップグレードの実行

2 つのコンポーネント (OBMC と RDU-C) は一緒にアップグレードされます。

# Auto-download the POR images for both components
snctl firmware upgrade --rack-id <rack_id> --device-type xrdu

# Or flash specific local images — both components required
snctl firmware upgrade --rack-id <rack_id> --device-type xrdu \
  --image obmc=/path/to/obmc.tgz --image rduc=/path/to/rduc.tgz

この操作は、--index の指定にかかわらず、ノード上のすべての XRDU の電源をオフにすることに留意してください。

ノードの電源再投入と確認

snctl power on --node <node_id> --type node
snctl firmware version --rack-id <rack_id> --device-type xrdu

次のステップ

デバイスを 1 つずつ手動で追加する代わりに、1 コマンドで新規インストール環境にインベントリを取り込めます。インベントリファイルスキーマをご参照ください。

はじめに

サービス管理

ハードウェア管理

リファレンスアーキテクチャ

リソース

ファームウェア更新

主要な概念

前提条件

デバイスタイプごとの対応操作

対象の選択

(任意) スロット型デバイスタイプと `--index`

XRDU では 2 つのコンポーネントを書き込む

ファームウェアイメージの入手元

ファームウェアバージョンの確認

出力の読み方

wide 出力

ファームウェアのアップグレード

推奨される順序と事前条件

使用例

進捗の出力

エアギャップ環境

イメージパスの形式

デバイスタイプ別のアップグレード手順

CARD (Thor NIC)

BIOS

BMC

XRDU

次のステップ

​主要な概念

​前提条件

​デバイスタイプごとの対応操作

​対象の選択

​(任意) スロット型デバイスタイプと --index

​XRDU では 2 つのコンポーネントを書き込む

​ファームウェアイメージの入手元

​ファームウェアバージョンの確認

​出力の読み方

​wide 出力

​ファームウェアのアップグレード

​推奨される順序と事前条件

​使用例

​進捗の出力

​エアギャップ環境

​イメージパスの形式

​デバイスタイプ別のアップグレード手順

​CARD (Thor NIC)

​BIOS

​BMC

​XRDU

​次のステップ

主要な概念

前提条件

デバイスタイプごとの対応操作

対象の選択

(任意) スロット型デバイスタイプと `--index`

XRDU では 2 つのコンポーネントを書き込む

ファームウェアイメージの入手元

ファームウェアバージョンの確認

出力の読み方

wide 出力

ファームウェアのアップグレード

推奨される順序と事前条件

使用例

進捗の出力

エアギャップ環境

イメージパスの形式

デバイスタイプ別のアップグレード手順

CARD (Thor NIC)

BIOS

BMC

XRDU

次のステップ