検索

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

download PDF

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

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

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

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

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

14.4.1. ベアメタル上の MachineHealthCheck

ベアメタルクラスターでのマシンの削除により、ベアメタルホストの再プロビジョニングがトリガーされます。通常、ベアメタルの再プロビジョニングは長いプロセスで、クラスターにコンピュートリソースがなくなり、アプリケーションが中断される可能性があります。デフォルトの修復プロセスをマシンの削除からホストの電源サイクルに切り換えるには、MachineHealthCheck リソースに machine.openshift.io/remediation-strategy: external-baremetal アノテーションを付けます。

アノテーションの設定後に、BMC 認証情報を使用して正常でないマシンの電源が入れ直されます。

14.4.2. 修復プロセスについて

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

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

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

14.4.3. ベアメタルの 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 はあくまでもサンプルであるため、特定のニーズに応じてマシングループをマッピングする必要があります。

<mgmt-troubleshooting-issue-power-remediation_deploying-machine-health-checks><title>電源ベースの修復に関する問題のトラブルシューティング</title>

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

  • BMC にアクセスできる。
  • BMC は修復タスクを実行するコントロールプレーンノードに接続されている。
</mgmt-troubleshooting-issue-power-remediation_deploying-machine-health-checks>
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.