4.3. 障害復旧


この障害復旧ドキュメントでは、OpenShift Container Platform クラスターで発生する可能性のある複数の障害のある状態からの復旧方法に関する管理者向けの情報を提供しています。管理者は、クラスターの状態を機能する状態に戻すために、以下の 1 つまたは複数の手順を実行する必要がある場合があります。

重要

障害復旧には、少なくとも 1 つの正常なコントロールプレーンホストが必要です。

4.3.1. クォーラムの復元

quorum-restore.sh スクリプトを使用すると、クォーラムの喪失によりオフラインになっているクラスターの etcd クォーラムを復元できます。クォーラムが失われると、OpenShift Container Platform API が読み取り専用になります。クォーラムが復元されると、OpenShift Container Platform API は読み取り/書き込みモードに戻ります。

4.3.1.1. 高可用性クラスターの etcd クォーラムの復元

quorum-restore.sh スクリプトを使用すると、クォーラムの喪失によりオフラインになっているクラスターの etcd クォーラムを復元できます。クォーラムが失われると、OpenShift Container Platform API が読み取り専用になります。クォーラムが復元されると、OpenShift Container Platform API は読み取り/書き込みモードに戻ります。

quorum-restore.sh スクリプトは、ローカルのデータディレクトリーに基づいてシングルメンバーの新しい etcd クラスターを即座に戻し、以前のクラスター識別子を廃止して他のすべてのメンバーを無効としてマークします。コントロールプレーンを復元するために事前のバックアップは必要ありません。

高可用性 (HA) クラスターの場合、3 ノードの HA クラスターでは、クラスターの分割を回避するために、2 つのホストで etcd をシャットダウンする必要があります。4 ノードおよび 5 ノードの HA クラスターでは、3 つのホストをシャットダウンする必要があります。クォーラムにはノードの単純過半数が必要です。3 ノードの HA クラスターのクォーラムに必要なノードの最小数は 2 です。4 ノードおよび 5 ノードの HA クラスターでは、クォーラムに必要なノードの最小数は 3 です。リカバリーホスト上のバックアップから新しいクラスターを起動すると、他の etcd メンバーがクォーラムを形成してサービスを継続できる可能性があります。

警告

復元を実行するホストにすべてのデータがレプリケートされていない場合、データが失われる可能性があります。

重要

クォーラムの復元は、復元プロセス外のノード数を減らすために使用しないでください。ノードの数を減らすと、サポート対象外のクラスター設定になります。

前提条件

  • クォーラムを復元するために使用するノードへの SSH アクセス権がある。

手順

  1. リカバリーホストとして使用するコントロールプレーンホストを選択します。このホストで復元操作を実行します。

    1. 次のコマンドを実行して、実行中の etcd Pod をリスト表示します。

      $ oc get pods -n openshift-etcd -l app=etcd --field-selector="status.phase==Running"
    2. Pod を 1 つ選択し、次のコマンドを実行してその IP アドレスを取得します。

      $ oc exec -n openshift-etcd <etcd-pod> -c etcdctl -- etcdctl endpoint status -w table

      Raft インデックスが最も大きく、Learner ではないメンバーの IP アドレスをメモします。

    3. 次のコマンドを実行し、選択した etcd メンバーの IP アドレスに対応するノード名をメモします。

      $ oc get nodes -o jsonpath='{range .items[*]}[{.metadata.name},{.status.addresses[?(@.type=="InternalIP")].address}]{end}'
  2. SSH を使用して、選択したリカバリーノードに接続し、次のコマンドを実行して etcd クォーラムを復元します。

    $ sudo -E /usr/local/bin/quorum-restore.sh

    数分後、ダウンしたノードが、リカバリースクリプトを実行したノードと自動的に同期されます。残りのオンラインのノードは、quorum-restore.sh スクリプトによって作成された新しい etcd クラスターに自動的に再参加します。このプロセスには数分かかります。

  3. SSH セッションを終了します。
  4. いずれかのノードがオフラインの場合は、3 ノード設定に戻ります。オフラインになっているノードごとに次の手順を繰り返して、ノードを削除し、再作成します。マシンが再作成された後、新しいリビジョンが強制され、etcd が自動的にスケールアップします。

    • ユーザーがプロビジョニングしたベアメタルインストールを使用する場合は、最初に作成したときと同じ方法を使用して、コントロールプレーンマシンを再作成できます。詳細は、「ユーザーによってプロビジョニングされるクラスターのベアメタルへのインストール」を参照してください。

      警告

      リカバリーホストのマシンを削除し、再作成しないでください。

    • installer-provisioned infrastructure を実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。

      警告

      リカバリーホストのマシンを削除し、再作成しないでください。

      installer-provisioned infrastructure でのベアメタルインストールの場合、コントロールプレーンマシンは再作成されません。詳細は、「ベアメタルコントロールプレーンノードの交換」を参照してください。

      1. いずれかのオフラインノードのマシンを取得します。

        クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

        $ oc get machines -n openshift-machine-api -o wide

        出力例

        NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
        clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 
        1
        
        clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
        clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
        clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
        clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
        clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

        1
        これは、オフラインノード ip-10-0-131-183.ec2.internal のコントロールプレーンマシンです。
      2. 次のコマンドを実行して、オフラインノードのマシンを削除します。

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 
        1
        1
        オフラインノードのコントロールプレーンマシンの名前を指定します。

        オフラインノードのマシンを削除すると、新しいマシンが自動的にプロビジョニングされます。

  5. 以下を実行して、新しいマシンが作成されたことを確認します。

    $ oc get machines -n openshift-machine-api -o wide

    出力例

    NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
    clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
    clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
    clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running 
    1
    
    clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
    clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
    clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

    1
    新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

    新規マシンが作成されるまでに数分の時間がかかる場合があります。マシンまたはノードが正常な状態に戻ると、etcd クラスター Operator が自動的に同期します。

    1. オフラインになっているノードごとに上記の手順を繰り返します。
  6. 次のコマンドを実行して、コントロールプレーンが回復するまで待ちます。

    $ oc adm wait-for-stable-cluster
    注記

    コントロールプレーンが回復するまでに最大 15 分かかります。

トラブルシューティング

  • etcd 静的 Pod のロールアウトが進行していない場合は、次のコマンドを実行して、etcd クラスター Operator から強制的に再デプロイを実行できます。

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$(date --rfc-3339=ns )"'"}}' --type=merge
注記

コントロールプレーンノードの大部分がまだ使用可能であり、etcd のクォーラムがある場合は、1 つの異常な etcd メンバーを置き換えます

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る