Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

4.7. Bare Metal Operator を使用した設定

ベアメタルホストに OpenShift Container Platform をデプロイする場合、プロビジョニングの前後にホストに変更を加える必要がある場合があります。これには、ホストのハードウェア、ファームウェア、ファームウェアの詳細の検証が含まれます。また、ディスクのフォーマットや、変更可能なファームウェア設定の変更も含まれます。

Bare Metal Operator (BMO) を使用して、クラスター内のベアメタルホストをプロビジョニング、管理、検査できます。BMO は次の操作を完了できます。

  • 特定のイメージを使用したクラスターへのベアメタルホストのプロビジョニング
  • ホストをオンまたはオフにします。
  • ホストのハードウェアの詳細を検査し、ベアメタルホストへ報告する
  • ホストのファームウェアを特定のバージョンにアップグレードまたはダウングレードする
  • ファームウェアを検査し、BIOS を設定します。
  • ホストをプロビジョニングする前または後に、ホストのディスクの内容をクリーンアップします。

BMO はこれらのタスクを完了するために次のリソースを使用します。

  • BareMetalHost
  • HostFirmwareSettings
  • FirmwareSchema
  • HostFirmwareComponents
  • HostUpdatePolicy

BMO は、各ベアメタルホストを BareMetalHost カスタムリソース定義のインスタンスにマッピングすることにより、クラスター内の物理ホストのインベントリーを維持します。各 BareMetalHost リソースには、ハードウェア、ソフトウェア、およびファームウェアの詳細が含まれています。BMO は、クラスター内のベアメタルホストを継続的に検査して、各 BareMetalHost リソースが対応するホストのコンポーネントを正確に詳述していることを確認します。

BMO は、HostFirmwareSettings リソース、FirmwareSchema リソース、および HostFirmwareComponents リソースを使用して、ファームウェア仕様の詳細を指定し、ベアメタルホストのファームウェアをアップグレードまたはダウングレードします。

BMO は、Ironic API サービスを使用してクラスター内のベアメタルホストと接続します。Ironic サービスは、ホスト上のベースボード管理コントローラー (BMC) を使用して、マシンと接続します。

BMO の HostUpdatePolicy を使用すると、ホストのプロビジョニング後に、ベアメタルホストのファームウェア設定、BMC 設定、または BIOS 設定へのライブ更新を有効または無効にできます。デフォルトでは、BMO はライブ更新を無効にします。

4.7.1. Bare Metal Operator のアーキテクチャー
リンクのコピー

Bare Metal Operator (BMO) は、次のリソースを使用して、クラスター内のベアメタルホストをプロビジョニング、管理、検査します。次の図は、これらのリソースのアーキテクチャーを示しています。

BMO アーキテクチャーの概要
View larger image
BMO アーキテクチャーの概要

BareMetalHost

BareMetalHost リソースは、物理ホストとそのプロパティーを定義します。ベアメタルホストをクラスターにプロビジョニングするときは、そのホストの BareMetalHost リソースを定義する必要があります。ホストの継続的な管理のために、BareMetalHost リソースの情報を確認したり、この情報を更新したりできます。

BareMetalHost リソースには、次のようなプロビジョニング情報が含まれます。

  • オペレーティングシステムのブートイメージやカスタム RAM ディスクなどのデプロイメント仕様
  • プロビジョニング状態
  • ベースボード管理コントローラー (BMC) アドレス
  • 目的の電源状態

BareMetalHost リソースには、次のようなハードウェア情報が含まれます。

  • CPU 数
  • NIC の MAC アドレス
  • ホストのストレージデバイスのサイズ
  • 現在の電源状態

HostFirmwareSettings

HostFirmwareSettings リソースを使用して、ホストのファームウェア設定を取得および管理できます。ホストが Available 状態に移行すると、Ironic サービスはホストのファームウェア設定を読み取り、HostFirmwareSettings リソースを作成します。BareMetalHost リソースと HostFirmwareSettings リソースの間には 1 対 1 のマッピングがあります。

HostFirmwareSettings リソースを使用して、ホストのファームウェア仕様を調べたり、ホストのファームウェア仕様を更新したりできます。

注記

HostFirmwareSettings リソースの spec フィールドを編集するときは、ベンダーファームウェアに固有のスキーマに従う必要があります。このスキーマは、読み取り専用の FirmwareSchema リソースで定義されます。

FirmwareSchema

ファームウェア設定は、ハードウェアベンダーやホストモデルによって異なります。FirmwareSchema リソースは、各ホストモデル上の各ファームウェア設定のタイプおよび制限が含まれる読み取り専用リソースです。データは、Ironic サービスを使用して BMC から直接取得されます。FirmwareSchema リソースを使用すると、HostFirmwareSettings リソースの spec フィールドに指定できる有効な値を特定できます。

スキーマが同じであれば、FirmwareSchema リソースは多くの BareMetalHost リソースに適用できます。

HostFirmwareComponents

Metal3 は、BIOS およびベースボード管理コントローラー (BMC) ファームウェアのバージョンを記述する HostFirmwareComponents リソースを提供します。HostFirmwareComponents リソースの spec フィールドを編集することで、ホストのファームウェアを特定のバージョンにアップグレードまたはダウングレードできます。これは、特定のファームウェアバージョンに対してテストされた検証済みパターンを使用してデプロイする場合に便利です。

HostUpdatePolicy

HostUpdatePolicy リソースを使用すると、ベアメタルホストのファームウェア設定、BMC 設定、または BIOS 設定のライブ更新を有効または無効にできます。デフォルトでは、各ベアメタルホストの HostUpdatePolicy リソースにより、ホストへの更新がプロビジョニング中だけに制限されます。ホストをプロビジョニングした後、ファームウェア設定、BMC 設定、または BIOS 設定を更新する場合は、ホストの HostUpdatePolicy リソースを変更する必要があります。

4.7.2. BareMetalHost リソースについて
リンクのコピー

Metal3 で、物理ホストとそのプロパティーを定義する BareMetalHost リソースの概念が導入されました。BareMetalHost リソースには、2 つのセクションが含まれます。

  1. BareMetalHost spec
  2. BareMetalHost status

4.7.2.1. BareMetalHost spec
リンクのコピー

BareMetalHost リソースの spec セクションは、ホストの必要な状態を定義します。

Expand
表4.1 BareMetalHost spec
パラメーター説明

automatedCleaningMode

プロビジョニングおよびプロビジョニング解除時の自動クリーニングを有効または無効にするインターフェイス。disabled に設定すると、自動クリーニングはスキップされます。metadata に設定すると、自動消去が有効になります。デフォルト設定は metadata です。 

bmc:
  address:
  credentialsName:
  disableCertificateVerification:
Copy to Clipboard Toggle word wrap

bmc 設定には、ホスト上のベースボード管理コントローラー (BMC) の接続情報が含まれます。フィールドの詳細は以下のとおりです。

  • address: ホストの BMC コントローラーとの通信用の URL。
  • credentialsName: BMC のユーザー名およびパスワードが含まれるシークレットへの参照。
  • disableCertificateVerification: true に設定されている場合に証明書の検証を省略するブール値。

bootMACAddress

ホストのプロビジョニングに使用する NIC の MAC アドレス。

bootMode

ホストのブートモード。デフォルトは UEFI ですが、BIOS ブートの legacy または UEFISecureBoot に設定することもできます。

consumerRef

ホストを使用している別のリソースへの参照。別のリソースが現在ホストを使用していない場合は、空になることがあります。たとえば、machine-api がホストを使用している場合に、Machine リソースがホストを使用する場合があります。

description

ホストの特定に役立つ、人間が提供した文字列。

externallyProvisioned

ホストのプロビジョニングとプロビジョニング解除が外部で管理されるかどうかを示すブール値。設定される場合:

  • 電源ステータスは、オンラインフィールドを使用して引き続き管理できます。
  • ハードウェアインベントリーは監視されますが、プロビジョニング操作やプロビジョニング解除操作はホストで実行されません。

firmware

ベアメタルホストの BIOS 設定に関する情報が含まれます。現在、firmware は、iRMC、iDRAC、iLO4、および iLO5 BMC でのみサポートされます。サブフィールドは以下のとおりです。

  • simultaneousMultithreadingEnabled: 単一の物理プロセッサーコアが複数の論理プロセッサーとして表示されるのを許可します。有効な設定は true または false です。
  • sriovEnabled: SR-IOV のサポートにより、ハイパーバイザーが PCI-express デバイスの仮想インスタンスを作成できるようになり、パフォーマンスが向上する可能性があります。有効な設定は true または false です。
  • virtualizationEnabled: プラットフォームハードウェアの仮想化をサポートします。有効な設定は true または false です。 
image:
  url:
  checksum:
  checksumType:
  format:
Copy to Clipboard Toggle word wrap

image 設定には、ホストにデプロイされるイメージの詳細が保持されます。Ironic にはイメージフィールドが必要です。ただし、externallyProvisioned 設定が true に設定されていて、外部管理に電源制御が不要な場合、フィールドは空のままでもかまいません。この設定では次のフィールドがサポートされています。

  • url: ホストにデプロイするイメージの URL。
  • checksum: 実際のチェックサム、または image.url のイメージのチェックサムが含まれるファイルへの URL。
  • checksumType: チェックサムアルゴリズムを指定できます。現時点で image.checksumType は md5、sha256、および sha512 のみをサポートしています。デフォルトのチェックサムタイプは md5 です。
  • format: これはイメージのディスク形式です。raw、qcow2、vdi、vmdk、live-iso のいずれか、未設定のままにすることができます。これを raw に設定すると、そのイメージの Ironic エージェントでの raw イメージのストリーミングが有効になります。これを live-iso に設定すると、iso イメージをディスクにデプロイせずにライブブートが可能になり、checksum フィールドは無視されます。

networkData

ネットワーク設定データおよびその namespace が含まれるシークレットへの参照。したがって、ホストが起動してネットワークをセットアップする前にホストに接続することができます。

online

ホストの電源を入れる (true) かオフにする (false) かを示すブール値。この値を変更すると、物理ホストの電源状態に変更が加えられます。 

raid:
  hardwareRAIDVolumes:
  softwareRAIDVolumes:
Copy to Clipboard Toggle word wrap

(オプション) ベアメタルホストの RAID 設定に関する情報が含まれます。指定しない場合は、現在の設定を保持します。

注記

OpenShift Container Platform 4.19 は、BMC のインストールドライブ上で以下のハードウェア RAID をサポートします。

  • RAID レベル 0、1、5、6、および 10 をサポートする Fujitsu iRMC
  • ファームウェアバージョン 6.10.30.20 以降および RAID レベル 0、1、および 5 に対応した Redfish API を使用する Dell iDRAC

OpenShift Container Platform 4.19 は、インストールドライブ上のソフトウェア RAID をサポートしていません。

次の構成設定を参照してください。

  • hardwareRAIDVolumes: ハードウェア RAID の論理ドライブの一覧が含まれ、ハードウェア RAID で必要なボリューム設定を定義します。rootDeviceHints を指定しない場合、最初のボリュームがルートボリュームになります。サブフィールドは以下のとおりです。

    • level: 論理ドライブの RAID レベル。0、1、2、5、6、1+0、5+0、6+0 のレベルがサポートされます。
    • name: 文字列としてのボリュームの名前。サーバー内で一意である必要があります。指定されていない場合、ボリューム名は自動生成されます。
    • numberOfPhysicalDisks: 論理ドライブに使用する物理ドライブの数 (整数)。デフォルトは、特定の RAID レベルに必要なディスクドライブの最小数です。
    • physicalDisks: 物理ディスクドライブの名前の一覧です (文字列)。これはオプションのフィールドです。指定した場合、controller フィールドも指定する必要があります。
    • controller: (オプション) ハードウェア RAID ボリュームで使用する RAID コントローラーの名前 (文字列)。
    • rotational: true に設定すると、回転ディスクを用いるドライブのみが選択されます。false に設定すると、ソリッドステートドライブと NVMe ドライブのみが選択されます。設定されていない場合は、任意のドライブの種類を選択します (デフォルト動作)。
    • sizeGibibytes: 作成する論理ドライブのサイズ (GiB 単位の整数)。指定がない場合や 0 に設定すると、論理ドライブ用に物理ドライブの最大容量が使用されます。

  • softwareRAIDVolumes: OpenShift Container Platform 4.19 は、インストールドライブ上のソフトウェア RAID をサポートしていません。この設定には、ソフトウェア RAID の論理ディスクのリストが含まれています。rootDeviceHints を指定しない場合、最初のボリュームがルートボリュームになります。HardwareRAIDVolumes を設定すると、この項目は無効になります。ソフトウェア RAID は常に削除されます。作成されるソフトウェア RAID デバイスの数は、1 または 2 である必要があります。ソフトウェア RAID デバイスが 1 つしかない場合は、RAID-1 にする必要があります。2 つの RAID デバイスがある場合は、1 番目のデバイスを RAID-1 にする必要があります。また、2 番目のデバイスの RAID レベルは 0、1、または 1+0 に設定できます。最初の RAID デバイスはデプロイメントデバイスになりますが、ソフトウェア RAID ボリュームにすることはできません。RAID-1 を強制すると、デバイス障害が発生した場合にノードが起動しなくなるリスクが軽減されます。softwareRAIDVolume フィールドは、ソフトウェア RAID のボリュームの必要な設定を定義します。サブフィールドは以下のとおりです。

    • level: 論理ドライブの RAID レベル。0、1、1+0 のレベルがサポートされます。
    • physicalDisks: デバイスのヒントの一覧。アイテム数は、2 以上である必要があります。
    • sizeGibibytes: 作成される論理ディスクドライブのサイズ (GiB 単位の整数)。指定がない場合や 0 に設定すると、論理ドライブ用に物理ドライブの最大容量が使用されます。

hardwareRAIDVolume を空のスライスとして設定すると、ハードウェア RAID 設定を消去できます。以下に例を示します。 

spec:
   raid:
     hardwareRAIDVolume: []
Copy to Clipboard Toggle word wrap

ドライバーが RAID に対応していないことを示すエラーメッセージが表示された場合は、raid、hardwareRAIDVolumes または softwareRAIDVolumes を nil に設定します。ホストに RAID コントローラーがあることを確認する必要がある場合があります。 

rootDeviceHints:
  deviceName:
  hctl:
  model:
  vendor:
  serialNumber:
  minSizeGigabytes:
  wwn:
  wwnWithExtension:
  wwnVendorExtension:
  rotational:
Copy to Clipboard Toggle word wrap

rootDeviceHints パラメーターを使用すると、特定のデバイスへの RHCOS イメージのプロビジョニングが可能になります。これは、検出順にデバイスを検査し、検出された値をヒントの値と比較します。ヒントの値と一致する最初に検出されたデバイスが使用されます。設定では複数のヒントを組み合わせることができますが、デバイスが選択されるには、デバイスがすべてのヒントと一致する必要があります。フィールドの詳細は以下のとおりです。

  • deviceName: /dev/vda などの Linux デバイス名が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。
  • hctl: 0:0:0:0 などの SCSI バスアドレスが含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。
  • model: ベンダー固有のデバイス識別子が含まれる文字列。ヒントは、実際の値のサブ文字列になります。
  • vendor: デバイスのベンダーまたは製造元の名前が含まれる文字列。ヒントは、実際の値のサブ文字列になります。
  • serialNumber: デバイスのシリアル番号が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。
  • minSizeGigabytes: デバイスの最小サイズを表す整数 (ギガバイト単位)。
  • wwn: 一意のストレージ ID が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。
  • wwnWithExtension: ベンダー拡張が追加された一意のストレージ ID が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。
  • wwnVendorExtension: 一意のベンダーストレージ ID が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。
  • rotational: デバイスが回転ディスクを用いる (true) か、そうでないか (false) を示すブール値。

4.7.2.2. BareMetalHost status
リンクのコピー

BareMetalHost status は、ホストの現在の状態を表し、テスト済みの認証情報、現在のハードウェアの詳細などの情報が含まれます。

Expand
表4.2 BareMetalHost status
パラメーター説明

goodCredentials

シークレットおよびその namespace の参照で、システムが動作中と検証できるベースボード管理コントローラー (BMC) 認証情報のセットが保持されています。

errorMessage

プロビジョニングバックエンドが報告する最後のエラーの詳細 (ある場合)。

errorType

ホストがエラー状態になった原因となった問題のクラスを示します。エラータイプは以下のとおりです。

  • provisioned registration error: コントローラーがプロビジョニング済みのホストを再登録できない場合に発生します。
  • registration error: コントローラーがホストのベースボード管理コントローラーに接続できない場合に発生します。
  • inspection error: ホストからハードウェア詳細の取得を試みて失敗した場合に発生します。
  • preparation error: クリーニングに失敗した場合に発生します。
  • provisioning error: コントローラーがホストのプロビジョニングまたはプロビジョニング解除に失敗した場合に発生します。
  • power management error: コントローラーがホストの電源状態を変更できない場合に発生します。
  • detach error: コントローラーがホストをプロビジョナーからデタッチできない場合に発生します。 
hardware:
  cpu
    arch:
    model:
    clockMegahertz:
    flags:
    count:
Copy to Clipboard Toggle word wrap

hardware.cpu フィールドは、システム内の CPU の詳細を示します。フィールドには以下が含まれます。

  • arch: CPU のアーキテクチャー。
  • model: CPU モデル (文字列)。
  • clockMegahertz: CPU の速度 (MHz 単位)。
  • flags: CPU フラグのリスト。たとえば、'mmx','sse','sse2','vmx' などです。
  • count: システムで利用可能な CPU の数。 
hardware:
  firmware:
Copy to Clipboard Toggle word wrap

BIOS ファームウェア情報が含まれます。たとえば、ハードウェアベンダーおよびバージョンなどです。 

hardware:
  nics:
  - ip:
    name:
    mac:
    speedGbps:
    vlans:
    vlanId:
    pxe:
Copy to Clipboard Toggle word wrap

hardware.nics フィールドには、ホストのネットワークインターフェイスの一覧が含まれます。フィールドには以下が含まれます。

  • ip: NIC の IP アドレス (検出エージェントの実行時に IP アドレスが割り当てられている場合)。
  • name: ネットワークデバイスを識別する文字列。例:nic-1
  • mac: NIC の MAC アドレス。
  • speedGbps: デバイスの速度 (Gbps 単位)。
  • vlans: この NIC で利用可能な VLAN をすべて保持するリスト。
  • vlanId: タグ付けされていない VLAN ID。
  • pxe: NIC が PXE を使用して起動できるかどうか。 
hardware:
  ramMebibytes:
Copy to Clipboard Toggle word wrap

ホストのメモリー容量 (MiB 単位)。 

hardware:
  storage:
  - name:
    rotational:
    sizeBytes:
    serialNumber:
Copy to Clipboard Toggle word wrap

hardware.storage フィールドには、ホストで利用可能なストレージデバイスの一覧が含まれます。フィールドには以下が含まれます。

  • name: ストレージデバイスを識別する文字列。たとえば、disk 1 (boot) などです。
  • rotational: ディスクが回転ディスクを用いるかどうかを示します。true または false のいずれかを返します。
  • sizeBytes: ストレージデバイスのサイズ。
  • serialNumber: デバイスのシリアル番号。 
hardware:
  systemVendor:
    manufacturer:
    productName:
    serialNumber:
Copy to Clipboard Toggle word wrap

ホストの manufacturer、productName、および serialNumber に関する情報が含まれます。

lastUpdated

ホストのステータスの最終更新時のタイムスタンプ。

operationalStatus

サーバーのステータス。ステータスは以下のいずれかになります。

  • OK: ホストの詳細がすべて認識され、正しく設定され、機能し、管理可能であることを示します。
  • discovered: ホストの詳細の一部が正常に動作していないか、欠落しているかのいずれかを意味します。たとえば、BMC アドレスは認識されているが、ログイン認証情報が認識されていない。
  • error: システムで回復不能なエラーが検出されたことを示します。詳細は、status セクションの errorMessage フィールドを参照してください。
  • delayed: 複数ホストの同時プロビジョニングを制限するために、プロビジョニングが遅延していることを示します。
  • detached: ホストが unmanaged として識別されていることを示します。

poweredOn

ホストの電源が入っているかどうかを示すブール値。 

provisioning:
  state:
  id:
  image:
  raid:
  firmware:
  rootDeviceHints:
Copy to Clipboard Toggle word wrap

provisioning フィールドには、ホストへのイメージのデプロイに関連する値が含まれます。サブフィールドには以下が含まれます。

  • state: 進行中のプロビジョニング操作の現在の状態。状態には、以下が含まれます。

    • <empty string>: 現在、プロビジョニングは行われていません。
    • unmanaged: ホストを登録するのに十分な情報が利用できません。
    • registering: エージェントはホストの BMC の詳細を確認しています。
    • match profile: エージェントは、ホストで検出されたハードウェア詳細と既知のプロファイルを比較しています。
    • available: ホストはプロビジョニングに使用できます。この状態は、以前は ready として知られていました。
    • preparing: 既存の設定は削除され、新しい設定がホストに設定されます。
    • provisioning: プロビジョナーはイメージをホストのストレージに書き込んでいます。
    • provisioned: プロビジョナーはイメージをホストのストレージに書き込みました。
    • externally provisioned: Metal3 は、ホスト上のイメージを管理しません。
    • deprovisioning: プロビジョナーは、ホストのストレージからイメージを消去しています。
    • inspecting: エージェントはホストのハードウェア情報を収集しています。
    • deleting: エージェントはクラスターから削除しています。
  • id: 基礎となるプロビジョニングツールのサービスの一意識別子。
  • image: 直近ホストにプロビジョニングされたイメージ。
  • raid: 最近設定したハードウェアまたはソフトウェア RAID ボリュームの一覧。
  • firmware: ベアメタルサーバーの BIOS 設定。
  • rootDeviceHints: 直近のプロビジョニング操作に使用されたルートデバイス選択の手順。

triedCredentials

プロビジョニングバックエンドに送信された BMC 認証情報の最後のセットを保持するシークレットおよびその namespace への参照。

4.7.3. BareMetalHost リソースの取得
リンクのコピー

BareMetalHost リソースには、物理ホストのプロパティーが含まれます。物理ホストのプロパティーをチェックするには、その BareMetalHost リソースを取得する必要があります。

手順

  1. BareMetalHost リソースの一覧を取得します。 

    $ oc get bmh -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap
    注記

    oc get コマンドで、bmh の長い形式として、baremetalhost を使用できます。

  2. ホストのリストを取得します。 

    $ oc get bmh -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  3. 特定のホストの BareMetalHost リソースを取得します。 

    $ oc get bmh <host_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    ここで、<host_name> はホストの名前です。

    出力例

    apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  creationTimestamp: "2022-06-16T10:48:33Z"
  finalizers:
  - baremetalhost.metal3.io
  generation: 2
  name: openshift-worker-0
  namespace: openshift-machine-api
  resourceVersion: "30099"
  uid: 1513ae9b-e092-409d-be1b-ad08edeb1271
spec:
  automatedCleaningMode: metadata
  bmc:
    address: redfish://10.46.61.19:443/redfish/v1/Systems/1
    credentialsName: openshift-worker-0-bmc-secret
    disableCertificateVerification: true
  bootMACAddress: 48:df:37:c7:f7:b0
  bootMode: UEFI
  consumerRef:
    apiVersion: machine.openshift.io/v1beta1
    kind: Machine
    name: ocp-edge-958fk-worker-0-nrfcg
    namespace: openshift-machine-api
  customDeploy:
    method: install_coreos
  online: true
  rootDeviceHints:
    deviceName: /dev/disk/by-id/scsi-<serial_number>
  userData:
    name: worker-user-data-managed
    namespace: openshift-machine-api
status:
  errorCount: 0
  errorMessage: ""
  goodCredentials:
    credentials:
      name: openshift-worker-0-bmc-secret
      namespace: openshift-machine-api
    credentialsVersion: "16120"
  hardware:
    cpu:
      arch: x86_64
      clockMegahertz: 2300
      count: 64
      flags:
      - 3dnowprefetch
      - abm
      - acpi
      - adx
      - aes
      model: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz
    firmware:
      bios:
        date: 10/26/2020
        vendor: HPE
        version: U30
    hostname: openshift-worker-0
    nics:
    - mac: 48:df:37:c7:f7:b3
      model: 0x8086 0x1572
      name: ens1f3
    ramMebibytes: 262144
    storage:
    - hctl: "0:0:0:0"
      model: VK000960GWTTB
      name: /dev/disk/by-id/scsi-<serial_number>
      sizeBytes: 960197124096
      type: SSD
      vendor: ATA
    systemVendor:
      manufacturer: HPE
      productName: ProLiant DL380 Gen10 (868703-B21)
      serialNumber: CZ200606M3
  lastUpdated: "2022-06-16T11:41:42Z"
  operationalStatus: OK
  poweredOn: true
  provisioning:
    ID: 217baa14-cfcf-4196-b764-744e184a3413
    bootMode: UEFI
    customDeploy:
      method: install_coreos
    image:
      url: ""
    raid:
      hardwareRAIDVolumes: null
      softwareRAIDVolumes: []
    rootDeviceHints:
      deviceName: /dev/disk/by-id/scsi-<serial_number>
    state: provisioned
  triedCredentials:
    credentials:
      name: openshift-worker-0-bmc-secret
      namespace: openshift-machine-api
    credentialsVersion: "16120"
    Copy to Clipboard Toggle word wrap

4.7.4. BareMetalHost リソースの編集
リンクのコピー

OpenShift Container Platform クラスターをベアメタルにデプロイした後、ノードの BareMetalHost リソースを編集する必要がある場合があります。たとえば、次のような例が考えられます。

  • Assisted Installer を使用してクラスターをデプロイし、ベースボード管理コントローラー (BMC) のホスト名または IP アドレスを追加または編集する必要がある。
  • ノードをプロビジョニング解除せずに、あるクラスターから別のクラスターに移動する必要がある。

前提条件

  • ノードが Provisioned、ExternallyProvisioned、または Available 状態であることを確認する。

手順

  1. ノードのリストを取得します。 

    $ oc get bmh -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  2. ノードの BareMetalHost リソースを編集する前に、次のコマンドを実行してノードを Ironic からデタッチします。 

    $ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached=true'
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_name> はノード名に置き換えてください。

  3. 次のコマンドを実行して、BareMetalHost リソースを編集します。 

    $ oc edit bmh <node_name> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、ノードを Ironic に再アタッチします。 

    $ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached'-
    Copy to Clipboard Toggle word wrap

4.7.5. BareMetalHost リソースを削除する際の遅延のトラブルシューティング
リンクのコピー

Bare Metal Operator (BMO) が BareMetalHost リソースを削除すると、Ironic はクリーニングと呼ばれるプロセスでベアメタルホストのプロビジョニングを解除します。クリーニングが失敗すると、Ironic はクリーニングプロセスを 3 回再試行します。これが遅延の原因となります。クリーニングプロセスが成功せず、ベアメタルホストのプロビジョニングステータスが deleting 状態のまま無期限に残る原因となります。このような場合は、次の手順に従ってクリーニングプロセスを無効にしてください。

警告

BareMetalHost リソースからファイナライザーを削除しないでください。

手順

  1. クリーニングプロセスが失敗して再開された場合は、完了するまで待機します。これには約 5 分かかる場合があります。
  2. プロビジョニングステータスが deleting 状態のままの場合は、BareMetalHost リソースを変更し、automatedCleaningMode フィールドを disabled に設定して、クリーニングプロセスを無効にします。

詳細は、「BareMetalHost リソースの編集」を参照してください。

4.7.6. ブータブルでない ISO をベアメタルノードにアタッチする
リンクのコピー

DataImage リソースを使用すると、ブータブルでない汎用の ISO 仮想メディアイメージを、プロビジョニングされたノードにアタッチできます。リソースを適用すると、起動後にオペレーティングシステムから ISO イメージにアクセスできるようになります。これは、オペレーティングシステムをプロビジョニングした後、ノードが初めて起動する前にノードを設定する場合に便利です。

前提条件

  • この機能をサポートするために、ノードが Redfish またはそれから派生したドライバーを使用している。
  • ノードが Provisioned または ExternallyProvisioned 状態である。
  • name が、BareMetalHost リソースで定義されているノードの名前と同じである。
  • ISO イメージへの有効な url がある。

手順

  1. DataImage リソースを作成します。 

    apiVersion: metal3.io/v1alpha1
kind: DataImage
metadata:
  name: <node_name>
    1 
    
spec:
  url: "http://dataimage.example.com/non-bootable.iso"
    2
    Copy to Clipboard Toggle word wrap
    1
    BareMetalHost リソースで定義されているノードの名前を指定します。
    2
    ISO イメージへの URL とパスを指定します。

  2. 次のコマンドを実行して、DataImage リソースをファイルに保存します。 

    $ vim <node_name>-dataimage.yaml
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、DataImage リソースを適用します。 

    $ oc apply -f <node_name>-dataimage.yaml -n <node_namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    namespace が BareMetalHost リソースの namespace と一致するように <node_namespace> を置き換えます。たとえば、openshift-machine-api です。

  4. ノードを再起動します。

    注記

    ノードを再起動するには、reboot.metal3.io アノテーションを割り当てるか、BareMetalHost リソースで online ステータスをリセットします。ベアメタルノードを強制的に再起動すると、ノードの状態がしばらくの間 NotReady に変わります。具体的には、5 分以上変わります。

  5. 次のコマンドを実行して、DataImage リソースを表示します。 

    $ oc get dataimage <node_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: v1
items:
- apiVersion: metal3.io/v1alpha1
  kind: DataImage
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"metal3.io/v1alpha1","kind":"DataImage","metadata":{"annotations":{},"name":"bmh-node-1","namespace":"openshift-machine-api"},"spec":{"url":"http://dataimage.example.com/non-bootable.iso"}}
    creationTimestamp: "2024-06-10T12:00:00Z"
    finalizers:
    - dataimage.metal3.io
    generation: 1
    name: bmh-node-1
    namespace: openshift-machine-api
    ownerReferences:
    - apiVersion: metal3.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: BareMetalHost
      name: bmh-node-1
      uid: 046cdf8e-0e97-485a-8866-e62d20e0f0b3
    resourceVersion: "21695581"
    uid: c5718f50-44b6-4a22-a6b7-71197e4b7b69
  spec:
    url: http://dataimage.example.com/non-bootable.iso
  status:
    attachedImage:
      url: http://dataimage.example.com/non-bootable.iso
    error:
      count: 0
      message: ""
    lastReconciled: "2024-06-10T12:05:00Z"
    Copy to Clipboard Toggle word wrap

4.7.7. 共有 NIC の NC-SI と DisablePowerOff の設定
リンクのコピー

Network Controller Sideband Interface (NC-SI) により、ベースボード管理コントローラー (BMC) は、Redfish、IPMI、ベンダー固有のインターフェイスなどのプロトコルを使用して、管理トラフィック用のシステムネットワークインターフェイスカード (NIC) をホストと共有できるようになります。DisablePowerOff 機能は、ハードな電源オフを防ぎ、ソフトリブートを行うことで BMC との接続を維持します。

前提条件

  • NC-SI 対応のハードウェアと NIC。
  • IP アドレスとネットワーク接続が設定された BMC。
  • BMC への管理アクセス。
  • cluster-admin 特権で OpenShift クラスターにアクセスする。

手順

  1. 共有 NIC に対して NC-SI を有効にするように BMC を設定します。

  2. 次のいずれかのコマンドを実行し、Redfish または IPMI を使用して BMC の接続を確認します。 

    $ curl -k https://<bmc_ip>/redfish/v1/Systems/1
    Copy to Clipboard Toggle word wrap 
    $ ipmitool -I lanplus -H <bmc_ip> -U <user> -P <pass> power status
    Copy to Clipboard Toggle word wrap

  3. openshift-machine-api namespace の BareMetalHost リソースを編集して、DisablePowerOff 機能を有効にします。 

    apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: example-host
  namespace: openshift-machine-api
spec:
  online: true
  bmc:
    address: <protocol>://<bmc_ip>/<bmc_address_format>
    credentialsName: bmc-secret
  disablePowerOff: true
    Copy to Clipboard Toggle word wrap

    サポートされているプロトコルと BMC アドレス形式の詳細は、「BMC アドレス指定」セクションを参照してください。

  4. 次のコマンドを実行して変更を適用します。 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、BareMetalHost のステータスを確認します。 

    $ oc get baremetalhost example-host -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    spec セクションに disablePowerOff: true があることを確認します。

  • ノード Pod を再起動してリブートをテストし、BMC 接続がアクティブなままであることを確認します。
  • BareMetalHost.spec.online=false の設定を試みます。電源オフが無効であることを示すエラーが表示されて失敗するはずです。

4.7.8. HostFirmwareSettings リソースについて
リンクのコピー

HostFirmwareSettings リソースを使用して、ホストの BIOS 設定を取得および管理できます。ホストが Available 状態に移行すると、Ironic はホストの BIOS 設定を読み取り、HostFirmwareSettings リソースを作成します。リソースには、ベースボード管理コントローラー (BMC) から返される完全な BIOS 設定が含まれます。BareMetalHost リソースの firmware フィールドは、ベンダーに依存しない 3 つのフィールドを返しますが、HostFirmwareSettings リソースは、通常ホストごとにベンダー固有のフィールドの多数の BIOS 設定で構成されます。

HostFirmwareSettings リソースには、以下の 2 つのセクションが含まれます。

  1. HostFirmwareSettings spec
  2. HostFirmwareSettings status
注記

ファームウェア設定の読み取りと変更は、ベンダーに依存しない Redfish プロトコル、Fujitsu iRMC、または HP iLO ベースのドライバーでのみサポートされます。

4.7.8.1. HostFirmwareSettings spec
リンクのコピー

HostFirmwareSettings リソースの spec セクションは、ホストの BIOS の必要な状態を定義し、デフォルトでは空です。Ironic は spec.settings セクションの設定を使用して、ホストが Preparing 状態の場合、ベースボード管理コントローラー (BMC) を更新します。FirmwareSchema リソースを使用して、無効な名前と値のペアをホストに送信しないようにします。詳細は、「FirmwareSchema リソースについて」を参照してください。

例

spec:
  settings:
    ProcTurboMode: Disabled
1
Copy to Clipboard Toggle word wrap

1
前述の例では、spec.settings セクションには、ProcTurboMode BIOS 設定を Disabled に設定する名前/値のペアが含まれます。
注記

status セクションに一覧表示される整数パラメーターは文字列として表示されます。たとえば、"1" と表示されます。spec.settings セクションで整数を設定する場合、値は引用符なしの整数として設定する必要があります。たとえば、1 と設定します。

4.7.8.2. HostFirmwareSettings status
リンクのコピー

status は、ホストの BIOS の現在の状態を表します。

Expand
表4.3 HostFirmwareSettings
パラメーター説明
status:
  conditions:
  - lastTransitionTime:
    message:
    observedGeneration:
    reason:
    status:
    type:
Copy to Clipboard Toggle word wrap

conditions フィールドには、状態変更の一覧が含まれます。サブフィールドには以下が含まれます。

  • lastTransitionTime: 状態が最後に変更した時刻。
  • message: 状態変更の説明。
  • observedGeneration: status の現在の生成。metadata.generation とこのフィールドが同じでない場合には、status.conditions が古い可能性があります。
  • reason: 状態変更の理由。
  • status: 状態の変更のステータス。ステータスは True、False、または Unknown です。
  • type: 状態変更のタイプ。タイプは Valid および ChangeDetected です。 
status:
  schema:
    name:
    namespace:
    lastUpdated:
Copy to Clipboard Toggle word wrap

ファームウェア設定の FirmwareSchema。フィールドには以下が含まれます。

  • name: スキーマを参照する名前または一意の識別子。
  • namespace: スキーマが保存される namespace。
  • lastUpdated: リソースが最後に更新された時刻。 
status:
  settings:
Copy to Clipboard Toggle word wrap

settings フィールドには、ホストの現在の BIOS 設定の名前と値のペアのリストが含まれます。

4.7.9. HostFirmwareSettings リソースの取得
リンクのコピー

HostFirmwareSettings リソースには、物理ホストのベンダー固有の BIOS プロパティーが含まれます。物理ホストの BIOS プロパティーをチェックするには、その HostFirmwareSettings リソースを取得する必要があります。

手順

  1. 次のコマンドを実行して、HostFirmwareSettings リソースの詳細なリストを取得します。 

    $ oc get hfs -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap
    注記

    oc get コマンドで、hfs の長い形式として hostfirmwaresettings を使用できます。

  2. 次のコマンドを実行して、HostFirmwareSettings リソースのリストを取得します。 

    $ oc get hfs -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、特定のホストの HostFirmwareSettings リソースを取得します。 

    $ oc get hfs <host_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    ここで、<host_name> はホストの名前です。

4.7.10. プロビジョニング済みホストの HostFirmwareSettings リソースの編集
リンクのコピー

プロビジョニング済みホストの HostFirmwareSettings 仕様を変更するには、次の操作を実行します。

  • ホストの HostFirmwareSettings リソースを編集します。
  • マシンセットからホストを削除します。
  • マシンセットをスケールダウンします。
  • マシンセットをスケールアップして変更を反映させます。
重要

ホストが provisioned 状態にある場合にのみ、ホストを編集できます (読み取り専用の値を除く)。externally provisioned 状態のホストは編集できません。

手順

  1. 次のコマンドを実行して、HostFirmwareSettings リソースのリストを取得します。 

    $ oc get hfs -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、ホストの HostFirmwareSettings リソースを編集します。 

    $ oc edit hfs <hostname> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    <hostname> はプロビジョニングされたホストの名前です。HostFirmwareSettings リソースは、ターミナルのデフォルトエディターで開きます。

  3. 次のコマンドを実行して、spec.settings セクションに名前と値のペアを追加します。

    例

    spec:
  settings:
    name: value
    1
    Copy to Clipboard Toggle word wrap

    1
    FirmwareSchema リソースを使用して、ホストで利用可能な設定を特定します。読み取り専用の値は設定できません。
  4. 変更を保存し、エディターを終了します。

  5. 次のコマンドを実行して、ホストのマシン名を取得します。 

     $ oc get bmh <hostname> -n openshift-machine name
    Copy to Clipboard Toggle word wrap

    <hostname> はホストの名前です。ターミナルの CONSUMER フィールドの下にマシン名が表示されます。

  6. 次のコマンドを実行して、マシンにアノテーションを付けてマシンセットから削除します。 

    $ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    ここで、<machine_name> は削除するマシンの名前です。

  7. 次のコマンドを実行して、ノードのリストを取得し、ワーカーノードの数をカウントします。 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

  8. 次のコマンドを実行してマシンセットを取得します。 

    $ oc get machinesets -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  9. 次のコマンドを実行して、マシンセットをスケールします。 

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
    Copy to Clipboard Toggle word wrap

    <machineset_name> はマシンセットの名前です。<n-1> は減少させたワーカーノードの数です。

  10. ホストが Available 状態になったら、次のコマンドを実行してマシンセットをスケールアップし、HostFirmwareSettings リソースの変更を反映します。 

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
    Copy to Clipboard Toggle word wrap

    <machineset_name> はマシンセットの名前です。<n> はワーカーノードの数です。

4.7.11. HostFirmwareSettings リソースへのライブ更新の実行
リンクのコピー

ワークロードの実行を開始した後、HostFirmareSettings リソースに対してライブ更新を実行できます。ライブ更新では、ホストのプロビジョニング解除と再プロビジョニングはトリガーされません。

重要

ホストのライブ更新はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

前提条件

  • HostUpdatePolicy リソースの firmwareSettings パラメーターが onReboot に設定されている。

手順

  1. 次のコマンドを実行して、HostFirmwareSettings リソースを更新します。 

    $ oc patch hostfirmwaresettings <hostname> --type merge -p \
    1 
    
    '{"spec": {"settings": {"<name>": "<value>"}}}'
    2
    Copy to Clipboard Toggle word wrap
    1
    <hostname> はホスト名に置き換えます。
    2
    <name> は設定の名前に置き換えます。<value> は設定の値に置き換えます。複数の名前と値のペアを設定できます。
    注記

    ハードウェアがサポートする設定と、更新できる設定および値を確認するには、FirmwareSchema リソースを取得します。読み取り専用の値を更新することはできません。また、FirmwareSchema リソースを更新することもできません。oc edit <hostname> hostfirmwaresettings -n openshift-machine-api コマンドを使用して HostFirmwareSettings リソースを更新することもできます。

  2. 次のコマンドを実行して、ノードをスケジューリング対象から外してドレインします。 

    $ oc drain <node_name> --force
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_name> はノード名に置き換えてください。

  3. 次のコマンドを実行して、ホストの電源を 5 分間オフにします。 

    $ oc patch bmh <hostname> --type merge -p '{"spec": {"online": false}}'
    Copy to Clipboard Toggle word wrap

    このステップにより、デーモンセットまたはコントローラーが、ホスト上で実行されている可能性のあるインフラストラクチャー Pod をオフラインとしてマークし、残りのホストが受信リクエストを処理するようになります。

  4. 5 分後、次のコマンドを実行してホストの電源をオンにします。 

    $ oc patch bmh <hostname> --type merge -p '{"spec": {"online": true}}'
    Copy to Clipboard Toggle word wrap

    サービス操作が開始し、Bare Metal Operator (BMO) が BareMetalHost の operationalStatus パラメーターを servicing に設定します。BMO は、リソースを更新した後、operationalStatus パラメーターを OK に更新します。エラーが発生した場合、BMO は operationalStatus パラメーターを error に更新し、操作を再試行します。

  5. Ironic が更新を完了し、ホストが起動したら、次のコマンドを実行してノードをスケジューリング対象に戻します。 

    $ oc uncordon <node_name>
    Copy to Clipboard Toggle word wrap

4.7.12. HostFirmware Settings リソースが有効であることの確認
リンクのコピー

ユーザーが spec.settings セクションを編集して HostFirmwareSetting (HFS) リソースに変更を加えると、Bare Metal Operator (BMO) は読み取り専用リソースである FimwareSchema リソースに対して変更を検証します。この設定が無効な場合、BMO は status.Condition 設定の Type の値を False に設定し、イベントを生成して HFS リソースに保存します。以下の手順を使用して、リソースが有効であることを確認します。

手順

  1. HostFirmwareSetting リソースの一覧を取得します。 

    $ oc get hfs -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  2. 特定のホストの HostFirmwareSettings リソースが有効であることを確認します。 

    $ oc describe hfs <host_name> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    ここで、<host_name> はホストの名前です。

    出力例

    Events:
  Type    Reason            Age    From                                    Message
  ----    ------            ----   ----                                    -------
  Normal  ValidationFailed  2m49s  metal3-hostfirmwaresettings-controller  Invalid BIOS setting: Setting ProcTurboMode is invalid, unknown enumeration value - Foo
    Copy to Clipboard Toggle word wrap

    重要

    応答が ValidationFailed を返す場合、リソース設定にエラーがあり、FirmwareSchema リソースに準拠するよう値を更新する必要があります。

4.7.13. FirmwareSchema リソースについて
リンクのコピー

BIOS 設定は、ハードウェアベンダーやホストモデルによって異なります。FirmwareSchema リソースは、各ホストモデル上の各 BIOS 設定のタイプおよび制限が含まれる読み取り専用リソースです。データは BMC から Ironic に直接取得されます。FirmwareSchema を使用すると、HostFirmwareSettings リソースの spec フィールドに指定できる有効な値を特定できます。FirmwareSchema リソースには、その設定および制限から派生する一意の識別子があります。同じホストモデルは同じ FirmwareSchema 識別子を使用します。HostFirmwareSettings の複数のインスタンスが同じ FirmwareSchema を使用する可能性が高いです。

Expand
表4.4 FirmwareSchema 仕様
パラメーター説明
<BIOS_setting_name>
  attribute_type:
  allowable_values:
  lower_bound:
  upper_bound:
  min_length:
  max_length:
  read_only:
  unique:
Copy to Clipboard Toggle word wrap

spec は、BIOS 設定名と設定の制限で構成される単純なマップです。フィールドには以下が含まれます。

  • attribute_type: 設定のタイプ。サポートされるタイプは以下のとおりです。

    • Enumeration
    • Integer
    • String
    • Boolean
  • allowable_values: attribute_type が Enumeration の場合の、許可される値のリスト。
  • lower_bound: attribute_type が Integer の場合に許可される最小値。
  • upper_bound: attribute_type が Integer の場合に許可される最大値。
  • min_length: attribute_type が String の場合に、値が取ることのできる最も短い文字列の長さ。
  • max_length: attribute_type が String の場合に、値が取ることのできる最も長い文字列の長さ。
  • read_only: 設定は読み取り専用で、変更することはできません。
  • unique: 設定はこのホストに固有のものです。

4.7.14. FirmwareSchema リソースの取得
リンクのコピー

各ベンダーの各ホストモデルの BIOS 設定は、それぞれ異なります。HostFirmwareSettings リソースの spec セクションを編集する際に、設定する名前/値のペアはそのホストのファームウェアスキーマに準拠している必要があります。有効な名前と値のペアを設定するには、ホストの FirmwareSchema を取得して確認します。

手順

  1. 次のコマンドを実行して、FirmwareSchema リソースインスタンスのリストを取得します。 

    $ oc get firmwareschema -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、特定の FirmwareSchema インスタンスを取得します。 

    $ oc get firmwareschema <instance_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    ここで、<instance_name> は、HostFirmwareSettings リソース (表 3 を参照) に記載されているスキーマインスタンスの名前です。

4.7.15. HostFirmwareComponents リソースについて
リンクのコピー

Metal3 は、BIOS およびベースボード管理コントローラー (BMC) ファームウェアのバージョンを記述する HostFirmwareComponents リソースを提供します。HostFirmwareComponents リソースには 2 つのセクションが含まれています。

  1. HostFirmwareComponents spec
  2. HostFirmwareComponents status

4.7.15.1. HostFirmwareComponents spec
リンクのコピー

HostFirmwareComponents リソースの spec セクションでは、ホストの BIOS および BMC バージョンの目的の状態を定義します。

Expand
表4.5 HostFirmwareComponents spec
パラメーター説明
updates:
  component:
  url:
Copy to Clipboard Toggle word wrap

updates 設定には、更新するコンポーネントを含めます。フィールドの詳細は以下のとおりです。

  • component: コンポーネントの名前。有効な設定は bios または bmc です。
  • url: コンポーネントのファームウェア仕様とバージョンへの URL。

4.7.15.2. HostFirmwareComponents status
リンクのコピー

HostFirmwareComponents リソースの status セクションは、ホストの BIOS および BMC バージョンの現在のステータスを返します。

Expand
表4.6 HostFirmwareComponents status
パラメーター説明
components:
  component:
  initialVersion:
  currentVersion:
  lastVersionFlashed:
  updatedAt:
Copy to Clipboard Toggle word wrap

components セクションには、コンポーネントのステータスが含まれています。フィールドの詳細は以下のとおりです。

  • component: ファームウェアコンポーネントの名前。bios または bmc を返します。
  • initialVersion: コンポーネントの初期ファームウェアバージョン。Ironic は、BareMetalHost リソースを作成するときにこの情報を取得します。ユーザーが変更することはできません。
  • currentVersion: コンポーネントの現在のファームウェアバージョン。この値は、Ironic がベアメタルホストのファームウェアを更新するまで、initialVersion の値と同じです。
  • lastVersionFlashed: ベアメタルホストでフラッシュされたコンポーネントの最後のファームウェアバージョン。Ironic がファームウェアを更新するまで、このフィールドは null を返します。
  • updatedAt: Ironic がベアメタルホストのファームウェアを更新したときのタイムスタンプ。 
updates:
  component:
  url:
Copy to Clipboard Toggle word wrap

updates 設定には、更新されたコンポーネントが含まれています。フィールドの詳細は以下のとおりです。

  • component: コンポーネントの名前。
  • url: コンポーネントのファームウェア仕様とバージョンへの URL。

4.7.16. HostFirmwareComponents リソースの取得
リンクのコピー

HostFirmwareComponents リソースには、物理ホストの BIOS およびベースボード管理コントローラー (BMC) の特定のファームウェアバージョンが含まれています。ファームウェアのバージョンとステータスを確認するには、物理ホストの HostFirmwareComponents リソースを取得する必要があります。

手順

  1. 次のコマンドを実行して、HostFirmwareComponents リソースの詳細なリストを取得します。 

    $ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、HostFirmwareComponents リソースのリストを取得します。 

    $ oc get hostfirmwarecomponents -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、特定のホストの HostFirmwareComponents リソースを取得します。 

    $ oc get hostfirmwarecomponents <host_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    ここで、<host_name> はホストの名前です。

    出力例

    ---
apiVersion: metal3.io/v1alpha1
kind: HostFirmwareComponents
metadata:
  creationTimestamp: 2024-04-25T20:32:06Z"
  generation: 1
  name: ostest-master-2
  namespace: openshift-machine-api
  ownerReferences:
  - apiVersion: metal3.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: BareMetalHost
    name: ostest-master-2
    uid: 16022566-7850-4dc8-9e7d-f216211d4195
  resourceVersion: "2437"
  uid: 2038d63f-afc0-4413-8ffe-2f8e098d1f6c
spec:
  updates: []
status:
  components:
  - component: bios
    currentVersion: 1.0.0
    initialVersion: 1.0.0
  - component: bmc
    currentVersion: "1.00"
    initialVersion: "1.00"
  conditions:
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "True"
    type: Valid
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "False"
    type: ChangeDetected
  lastUpdated: "2024-04-25T20:32:06Z"
  updates: []
    Copy to Clipboard Toggle word wrap

4.7.17. プロビジョニング済みホストの HostFirmwareComponents リソースの編集
リンクのコピー

プロビジョニング済みホストの HostFirmwareComponents リソースを編集できます。

手順

  1. 次のコマンドを実行して、HostFirmwareComponents リソースの詳細なリストを取得します。 

    $ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、HostFirmwareComponents リソースを編集します。 

    $ oc edit <hostname> hostfirmwarecomponents -n openshift-machine-api
    1
    Copy to Clipboard Toggle word wrap
    1
    <hostname> はホストの名前です。HostFirmwareComponents リソースが、ターミナルのデフォルトのエディターで開きます。

  3. 適切な編集を行います。

    出力例

    ---
apiVersion: metal3.io/v1alpha1
kind: HostFirmwareComponents
metadata:
  creationTimestamp: 2024-04-25T20:32:06Z"
  generation: 1
  name: ostest-master-2
  namespace: openshift-machine-api
  ownerReferences:
  - apiVersion: metal3.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: BareMetalHost
    name: ostest-master-2
    uid: 16022566-7850-4dc8-9e7d-f216211d4195
  resourceVersion: "2437"
  uid: 2038d63f-afc0-4413-8ffe-2f8e098d1f6c
spec:
  updates:
    - name: bios
    1 
    
      url: https://myurl.with.firmware.for.bios
    2 
    
    - name: bmc
    3 
    
      url: https://myurl.with.firmware.for.bmc
    4 
    
status:
  components:
  - component: bios
    currentVersion: 1.0.0
    initialVersion: 1.0.0
  - component: bmc
    currentVersion: "1.00"
    initialVersion: "1.00"
  conditions:
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "True"
    type: Valid
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "False"
    type: ChangeDetected
  lastUpdated: "2024-04-25T20:32:06Z"
    Copy to Clipboard Toggle word wrap

    1
    BIOS のバージョンを設定するには、name 属性を bios に設定します。
    2
    BIOS のバージョンを設定するには、url 属性を BIOS のファームウェアバージョンの URL に設定します。
    3
    BMC のバージョンを設定するには、name 属性を bmc に設定します。
    4
    BMC のバージョンを設定するには、url 属性を BMC のファームウェアバージョンの URL に設定します。
  4. 変更を保存し、エディターを終了します。

  5. 次のコマンドを実行して、ホストのマシン名を取得します。 

    $ oc get bmh <host_name> -n openshift-machine name
    1
    Copy to Clipboard Toggle word wrap
    1
    ここで、<host_name> はホストの名前です。ターミナルの CONSUMER フィールドの下にマシン名が表示されます。

  6. 次のコマンドを実行して、マシンにアノテーションを付けてマシンセットから削除します。 

    $ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api
    1
    Copy to Clipboard Toggle word wrap
    1
    ここで、<machine_name> は削除するマシンの名前です。

  7. 次のコマンドを実行して、ノードのリストを取得し、ワーカーノードの数をカウントします。 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

  8. 次のコマンドを実行してマシンセットを取得します。 

    $ oc get machinesets -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  9. 次のコマンドを実行して、マシンセットをスケールダウンします。 

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
    1
    Copy to Clipboard Toggle word wrap
    1
    <machineset_name> はマシンセットの名前です。<n-1> は減少させたワーカーノードの数です。

  10. ホストが Available 状態になったら、次のコマンドを実行してマシンセットをスケールアップし、HostFirmwareComponents リソースの変更を反映します。 

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
    1
    Copy to Clipboard Toggle word wrap
    1
    <machineset_name> はマシンセットの名前です。<n> はワーカーノードの数です。

4.7.18. HostFirmwareComponents リソースへのライブ更新の実行
リンクのコピー

すでにプロビジョニングされているホスト上の HostFirmwareComponents リソースに対してライブ更新を実行できます。ライブ更新では、ホストのプロビジョニング解除と再プロビジョニングはトリガーされません。

重要

ホストのライブ更新はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

重要

実稼働ホストではライブ更新を実行しないでください。BIOS のライブ更新はテスト目的で実行できます。特に以前の世代のハードウェアでは、テスト目的で OpenShift Container Platform 4.19 上の BMC にライブ更新を実行することは推奨しません。

前提条件

  • HostUpdatePolicy リソースの firmwareUpdates パラメーターが onReboot に設定されている。

手順

  1. 次のコマンドを実行して、HostFirmwareComponents リソースを更新します。 

    $ oc patch hostfirmwarecomponents <hostname> --type merge -p \
    1 
    
    '{"spec": {"updates": [{"component": "<type>", \
    2 
    
                        "url": "<url>"}]}}'
    3
    Copy to Clipboard Toggle word wrap
    1
    <hostname> はホスト名に置き換えます。
    2
    <type> はコンポーネントのタイプに置き換えます。bios または bmc を指定します。
    3
    <url> はコンポーネントの URL に置き換えます。
    注記

    oc edit <hostname> hostfirmwarecomponents -n openshift-machine-api コマンドを使用してリソースを更新することもできます。

  2. 次のコマンドを実行して、ノードをスケジューリング対象から外してドレインします。 

    $ oc drain <node_name> --force
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_name> はノード名に置き換えてください。

  3. 次のコマンドを実行して、ホストの電源を 5 分間オフにします。 

    $ oc patch bmh <hostname> --type merge -p '{"spec": {"online": false}}'
    Copy to Clipboard Toggle word wrap

    このステップにより、デーモンセットまたはコントローラーが、ノード上で実行されている可能性のあるインフラストラクチャー Pod をオフラインとしてマークし、残りのノードが受信リクエストを処理するようになります。

  4. 5 分後、次のコマンドを実行してホストの電源をオンにします。 

    $ oc patch bmh <hostname> --type merge -p '{"spec": {"online": true}}'
    Copy to Clipboard Toggle word wrap

    サービス操作が開始し、Bare Metal Operator (BMO) が BareMetalHost の operationalStatus パラメーターを servicing に設定します。BMO は、リソースを更新した後、operationalStatus パラメーターを OK に更新します。エラーが発生した場合、BMO は operationalStatus パラメーターを error に更新し、操作を再試行します。

  5. 次のコマンドを実行してノードをスケジューリング対象に戻します。 

    $ oc uncordon <node_name>
    Copy to Clipboard Toggle word wrap

4.7.19. HostUpdatePolicy リソースについて
リンクのコピー

HostUpdatePolicy リソースを使用すると、各ベアメタルホストのファームウェア設定、BMC 設定、またはファームウェア設定へのライブ更新の適用を有効または無効にできます。デフォルトでは、すでにプロビジョニングされたベアメタルホストへのライブ更新は、Operator によって無効にされます。

HostUpdatePolicy 仕様

HostUpdatePolicy リソースの spec セクションには、次の 2 つの設定があります。

firmwareSettings
この設定は、HostFirmwareSettings リソースに対応するものです。
firmwareUpdates
この設定は、HostFirmwareComponents リソースに対応するものです。

値を onPreparing に設定すると、ホストを更新できるのがプロビジョニング中だけになります。これがデフォルト設定です。値を onReboot に設定すると、リソースを適用してベアメタルホストを再起動することで、プロビジョニング済みホストを更新できます。その後、HostFirmwareSettings または HostFirmwareComponents リソースを編集する手順に従います。

HostUpdatePolicy リソースの例

apiVersion: metal3.io/v1alpha1
kind: HostUpdatePolicy
metadata:
  name: <hostname>
1 

  namespace: openshift-machine-api
spec:
  firmwareSettings: <setting>
2 

  firmwareUpdates: <setting>
Copy to Clipboard Toggle word wrap

1
ベアメタルホストの名前。
2
更新ポリシーの設定。ライブ更新を無効にするには、onPreparing を指定します。ライブ更新を有効にするには、onReboot を指定します。

4.7.20. HostUpdatePolicy リソースの設定
リンクのコピー

デフォルトでは、HostUpdatePolicy はライブ更新を無効にします。ライブ更新を有効にするには、次の手順に従います。

重要

HostUpdatePolicy リソースの設定はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

手順

  1. 次のコマンドを実行して、HostUpdatePolicy リソースを作成します。 

    $ vim hup.yaml
    Copy to Clipboard Toggle word wrap

    任意のテキストエディターを使用できます。

    HostUpdatePolicy リソースの例

    apiVersion: metal3.io/v1alpha1
kind: HostUpdatePolicy
metadata:
  name: <hostname>
    1 
    
  namespace: openshift-machine-api
spec:
  firmwareSettings: onReboot
  firmwareUpdates: onReboot
    Copy to Clipboard Toggle word wrap

    1
    <hostname> はホスト名に置き換えます。
  2. hup.yaml ファイルへの変更を保存します。

  3. 以下のコマンドを実行してポリシーを適用します。 

    $ oc apply -f hup.yaml
    Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat