博士

やあ、ロボ子。今日のITニュースは、物理ハードウェアとOSのデバイス名の対応付けをRedfish APIで解決する話じゃ。

ロボ子

Redfish APIですか。サーバーのマザーボードに接続されたBMCのためのHTTP APIですね。それがどのように役立つのでしょうか？

博士

Redfish APIを使うと、PCIeカードやNVMeドライブ、シリアル番号、MACアドレスといったハードウェア情報を詳しく取得できるのじゃ。これを使って、ハードウェアの物理的な位置とOSが認識するデバイス名を正確に対応付けることができるぞ。

ロボ子

なるほど。具体的には、どのような手順で導入するのですか？

博士

まず、ラックにサーバーを設置した後、ホスト名やBMCのMACアドレス、パスワードなどの情報をCSV形式で収集して、MetalCPに送るのじゃ。MetalCPはTemporal workerを使ってHost Import workflowを実行するぞ。

ロボ子

そのワークフローでは、どのような処理が行われるのですか？

博士

ワークフローは、デバイスを内部DCIMツールと照合したり、Tailscale経由でデータセンターの管理ネットワークに接続したり、BMCのDHCPリースを特定してデータを収集したりするのじゃ。そして、ハードウェアレイアウトの内部Protobuf表現を作成し、収集したMACアドレスを使ってBMCとホストの管理NICに静的なDHCPリースを作成、最後にサーバーの詳細をDBに更新するぞ。

ロボ子

ずいぶんと細かい作業をするのですね。他にどのような情報を特定できるのですか？

博士

ネットワークインターフェースカードのリストや物理的な場所、各ポートのMACアドレス、NVMeドライブのリスト、シリアル番号、モデル番号、物理スロットID、CPUコア数、RAMサイズ、ハードウェアIDなどのシステム統計も取得できるぞ。

ロボ子

OSのインストールはどのように行うのですか？

博士

Debian InstallerをPXEブートして、Pixiecoreを使ってPXEの複雑さをHTTP呼び出しでラップするのじゃ。Redfishから収集したシステム情報とPXEブートサーバーのMACアドレスを使って、カーネルコマンドラインとpreseedファイルを作成するぞ。

ロボ子

SupermicroのCaptureScreen OEM APIとClaude (AI) を使用して、サーバー画面のリアルタイムイメージを取得し、サーバーの状態を監視するというのは面白いですね。

博士

じゃろ？ネットワーク構成はどうじゃ？BGP unnumberedを使って、スイッチとサーバー間のルーティング設定を均一化するのじゃ。FRRを使ってIPv6リンクローカルアドレスをネクストホップとして使用するぞ。

ロボ子

各デバイスタイプに対して1つのBGP構成テンプレートを使用し、Ansibleでスイッチに適用するのですね。L3ネットワークを構築し、冗長リンク間でECMPを実現するとのことですが、ネットワークに新しいIPを追加する際はどうなるのですか？

博士

エージェントがLinuxカーネルルーティングテーブルにルートを挿入し、FRRデーモンがそれをネットワーク全体に伝播させるのじゃ。

ロボ子

BGP unnumberedに加えて、L3ファブリックには`bgp bestpath as-path multipath-relax`と特定のAS番号が必要なのですね。FRRは、高速なeBGPコンバージェンスのためにタイミングを調整する「データセンター」のデフォルト設定を提供しているとのことですが。

博士

その通りじゃ！これで物理ハードウェアとOSのデバイス名の対応付けもバッチリじゃな！

ロボ子

勉強になりました！

博士

ところでロボ子、ハードウェアとOSの対応付けで一番重要なのは何だと思う？

ロボ子

なんでしょう？

博士

それはもちろん、ハードウェアがちゃんと動くかどうかじゃ！動かなければ、OSも何もあったもんじゃないからの！

ロボ子

確かにそうですね！

博士

…というわけで、今日の教訓！ハードウェアは大切に！以上！