13.4. ベアメタルの電源ベースの修復について
ベアメタルクラスターでは、クラスター全体の正常性を確保するためにノードの修復は重要になります。クラスターの物理的な修復には難題が伴う場合があります。マシンを安全な状態または動作可能な状態にするまでの遅延が原因で、クラスターが動作が低下した状態のままに置かれる時間が長くなり、その後の障害の発生によりクラスターがオフラインになるリスクが生じます。電源ベースの修復は、このような課題への対応に役立ちます。
ノードの再プロビジョニングを行う代わりに、電源ベースの修復は電源コントローラーを使用して、動作不能なノードの電源をオフにします。この種の修復は、電源フェンシングとも呼ばれます。
OpenShift Container Platform は MachineHealthCheck コントローラーを使用して障害のあるベアメタルノードを検出します。電源ベースの修復は高速であり、障害のあるノードをクラスターから削除する代わりにこれを再起動します。
電源バースの修復は以下の機能を提供します。
- コントロールプレーンノードのリカバリーの許可
- ハイパーコンバージド環境でのデータ損失リスクの軽減
- 物理マシンのリカバリーに関連するダウンタイムの削減
13.4.1. ベアメタル上の MachineHealthCheck
ベアメタルクラスターでのマシンの削除により、ベアメタルホストの再プロビジョニングがトリガーされます。通常、ベアメタルの再プロビジョニングは長いプロセスで、クラスターにコンピュートリソースがなくなり、アプリケーションが中断される可能性があります。デフォルトの修復プロセスをマシンの削除からホストの電源サイクルに切り換えるには、MachineHealthCheck リソースに machine.openshift.io/remediation-strategy: external-baremetal アノテーションを付けます。
アノテーションの設定後に、BMC 認証情報を使用して正常でないマシンの電源が入れ直されます。
13.4.2. 修復プロセスについて
修復プロセスは以下のように機能します。
- MachineHealthCheck (MHC) コントローラーは、ノードが正常ではないことを検知します。
- MHC は、正常でないノードの電源オフを要求するベアメタルマシンコントローラーに通知します。
- 電源がオフになった後にノードが削除され、クラスターは影響を受けたワークロードを他のノードで再スケジューリングできます。
- ベアメタルマシンコントローラーはノードの電源をオンにするよう要求します。
- ノードの起動後、ノードはクラスターに自らを再登録し、これにより新規ノードが作成されます。
- ノードが再作成されると、ベアメタルマシンコントローラーは、削除前に正常でないノードに存在したアノテーションとラベルを復元します。
電源操作が完了していない場合、ベアメタルマシンコントローラーは、外部でプロビジョニングされたコントロールプレーンノードやノードでない場合に正常でないノードの再プロビジョニングをトリガーします。
13.4.3. ベアメタルの MachineHealthCheck リソースの作成
前提条件
- OpenShift Container Platform は、インストーラーでプロビジョニングされるインフラストラクチャー (IPI) を使用してインストールされます。
- ベースボード管理コントローラー (BMC) 認証情報へのアクセス (または 各ノードへの BMC アクセス)。
- 正常でないノードの BMC インターフェイスへのネットワークアクセス。
手順
-
マシンヘルスチェックの定義を含む
healthcheck.yamlファイルを作成します。 -
以下のコマンドを使用して、
healthcheck.yamlファイルをクラスターに適用します。
$ oc apply -f healthcheck.yaml
ベアメタルのサンプル MachineHealthCheck リソース
apiVersion: machine.openshift.io/v1beta1 kind: MachineHealthCheck metadata: name: example 1 namespace: openshift-machine-api annotations: machine.openshift.io/remediation-strategy: external-baremetal 2 spec: selector: matchLabels: machine.openshift.io/cluster-api-machine-role: <role> 3 machine.openshift.io/cluster-api-machine-type: <role> 4 machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone> 5 unhealthyConditions: - type: "Ready" timeout: "300s" 6 status: "False" - type: "Ready" timeout: "300s" 7 status: "Unknown" maxUnhealthy: "40%" 8 nodeStartupTimeout: "10m" 9
- 1
- デプロイするマシンヘルスチェックの名前を指定します。
- 2
- ベアメタルクラスターの場合、電源サイクルの修復を有効にするために
machine.openshift.io/remediation-strategy: external-baremetalアノテーションをannotationsセクションに含める必要があります。この修復ストラテジーにより、正常でないホストはクラスターから削除される代わりに、再起動されます。 - 3 4
- チェックする必要のあるマシンプールのラベルを指定します。
- 5
- 追跡するマシンセットを
<cluster_name>-<label>-<zone>形式で指定します。たとえば、prod-node-us-east-1aとします。 - 6 7
- ノード状態のタイムアウト期間を指定します。タイムアウト期間の条件が満たされると、マシンは修正されます。タイムアウトの時間が長くなると、正常でないマシンのワークロードのダウンタイムが長くなる可能性があります。
- 8
- ターゲットプールで同時に修復できるマシンの数を指定します。これはパーセンテージまたは整数として設定できます。正常でないマシンの数が
maxUnhealthyで設定された制限を超える場合、修復は実行されません。 - 9
- マシンが正常でないと判別される前に、ノードがクラスターに参加するまでマシンヘルスチェックが待機する必要のあるタイムアウト期間を指定します。
matchLabels はあくまでもサンプルであるため、特定のニーズに応じてマシングループをマッピングする必要があります。
電源ベースの修復についての問題のトラブルシューティングを行うには、以下を確認します。
- BMC にアクセスできる。
- BMC は修復タスクを実行するコントロールプレーンノードに接続されている。
