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

14.4. ベアメタルの電源ベースの修復について

ベアメタルクラスターでは、クラスター全体の正常性を確保するためにノードの修復は重要になります。クラスターの物理的な修復には難題が伴う場合があります。マシンを安全な状態または動作可能な状態にするまでの遅延が原因で、クラスターが動作が低下した状態のままに置かれる時間が長くなり、その後の障害の発生によりクラスターがオフラインになるリスクが生じます。電源ベースの修復は、このような課題への対応に役立ちます。

ノードの再プロビジョニングを行う代わりに、電源ベースの修復は電源コントローラーを使用して、動作不能なノードの電源をオフにします。この種の修復は、電源フェンシングとも呼ばれます。

OpenShift Container Platform は MachineHealthCheck コントローラーを使用して障害のあるベアメタルノードを検出します。電源ベースの修復は高速であり、障害のあるノードをクラスターから削除する代わりにこれを再起動します。

電源バースの修復は以下の機能を提供します。

  • コントロールプレーンノードのリカバリーの許可
  • ハイパーコンバージド環境でのデータ損失リスクの軽減
  • 物理マシンのリカバリーに関連するダウンタイムの削減

14.4.1. ベアメタル上の MachineHealthCheck

ベアメタルクラスターでのマシンの削除により、ベアメタルホストの再プロビジョニングがトリガーされます。通常、ベアメタルの再プロビジョニングは長いプロセスで、クラスターにコンピュートリソースがなくなり、アプリケーションが中断される可能性があります。

デフォルトの修復プロセスを、マシンの削除からホストのパワーサイクルに変更する方法は 2 つあります。

  1. MachineHealthCheck リソースに machine.openshift.io/remediation-strategy: external-baremetal アノテーションを付けます。
  2. Metal3RemediationTemplate リソースを作成し、これを MachineHealthCheck の spec.remediationTemplate で参照します。

いずれかの方法を実行すると、ベースボード管理コントローラー (BMC) 認証情報を使用して、正常でないマシンでパワーサイクルが適用されます。

14.4.2. アノテーションベースの修復プロセスについて

修復プロセスは以下のように機能します。

  1. MachineHealthCheck (MHC) コントローラーは、ノードが正常ではないことを検知します。
  2. MHC は、正常でないノードの電源オフを要求するベアメタルマシンコントローラーに通知します。
  3. 電源がオフになった後にノードが削除され、クラスターは影響を受けたワークロードを他のノードで再スケジューリングできます。
  4. ベアメタルマシンコントローラーはノードの電源をオンにするよう要求します。
  5. ノードの起動後、ノードはクラスターに自らを再登録し、これにより新規ノードが作成されます。
  6. ノードが再作成されると、ベアメタルマシンコントローラーは、削除前に正常でないノードに存在したアノテーションとラベルを復元します。
注記

電源操作が完了していない場合、ベアメタルマシンコントローラーは、外部でプロビジョニングされたコントロールプレーンノードやノードでない場合に正常でないノードの再プロビジョニングをトリガーします。

14.4.3. metal3 ベースの修復プロセスについて

修復プロセスは以下のように機能します。

  1. MachineHealthCheck (MHC) コントローラーは、ノードが正常ではないことを検知します。
  2. MHC は、metal3 修復コントローラーの metal3 修復カスタムリソースを作成します。これは、正常でないノードの電源をオフにするように要求します。
  3. 電源がオフになった後にノードが削除され、クラスターは影響を受けたワークロードを他のノードで再スケジューリングできます。
  4. metal3 修復コントローラーが、ノードの電源を入れるよう要求します。
  5. ノードの起動後、ノードはクラスターに自らを再登録し、これにより新規ノードが作成されます。
  6. ノードが再作成されると、metal3 修復コントローラーは、削除する前に存在していた正常でないノードのアノテーションとラベルを復元します。
注記

電源操作が完了しなかった場合、外部でプロビジョニングされたコントロールプレーンノードやノードでなければ、metal3 修復コントローラーがノードの再プロビジョニングをトリガーします。

14.4.4. ベアメタルの MachineHealthCheck リソースの作成

前提条件

  • OpenShift Container Platform は、インストーラーでプロビジョニングされるインフラストラクチャー (IPI) を使用してインストールされます。
  • BMC 認証情報へのアクセス (または各ノードへの BMC アクセス)。
  • 正常でないノードの BMC インターフェイスへのネットワークアクセス。

手順

  1. マシンヘルスチェックの定義を含む healthcheck.yaml ファイルを作成します。

  2. 以下のコマンドを使用して、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 はあくまでもサンプルであるため、特定のニーズに応じてマシングループをマッピングする必要があります。

ベアメタルのサンプル MachineHealthCheck リソース (metal3 ベースの修復)

apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example
  namespace: openshift-machine-api
spec:
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-machine-role: <role>
      machine.openshift.io/cluster-api-machine-type: <role>
      machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone>
  remediationTemplate:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3RemediationTemplate
    name: metal3-remediation-template
    namespace: openshift-machine-api
  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s"

ベアメタルのサンプル Metal3RemediationTemplate リソース (metal3 ベースの修復)

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3RemediationTemplate
metadata:
  name: metal3-remediation-template
  namespace: openshift-machine-api
spec:
  template:
    spec:
      strategy:
        type: Reboot
        retryLimit: 1
        timeout: 5m0s

注記

matchLabels はあくまでもサンプルであるため、特定のニーズに応じてマシングループをマッピングする必要があります。annotations セクションは metal3 ベースの修復には適用されません。アノテーションベースの修復と metal3 ベースの修復は相互に排他的です。

14.4.5. 電源ベースの修復に関する問題のトラブルシューティング

電源ベースの修復に関する問題のトラブルシューティングを行うには、以下を確認します。

  • BMC にアクセスできる。
  • BMC は修復タスクを実行するコントロールプレーンノードに接続されている。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.