障害復旧

障害復旧モード

Kubernetes Operator は、次のいずれかのモードを使用して、障害復旧シナリオにおいてMongoDBMultiClusterリソースの自動または手動修復のいずれかをオーケストレーションできます。

• 自動フェイルオーバー モードを使用すると、Kubernetes Operator は、影響を受ける MongoDB レプリカセット メンバーを、正常でない Kubernetes クラスターから正常な Kubernetes クラスターに移行できます。 Kubernetes Operator がこの自動修正を実行すると、レプリカセット メンバーが正常な Kubernetes クラスター全体に均等に分散されます。

  このモードを有効にするには、 Kubernetes用のMongoDB Helm Charts で --set multiCluster.performFailover=true を使用します。values.yamlKubernetesディレクトリ用のMongoDB Helm Charts ディレクトリ内の ファイルでは、環境の変数のデフォルト値はtrue です。

  あるいは、次の省略された例のように、マルチ Kubernetes クラスター MongoDB 配置環境変数PERFORM_FAILOVERをtrueに設定することもできます。

  spec:
    template:
      ...
      spec:
        containers:
        - name: mongodb-kubernetes-operator
          ...
          env:
          ...
          - name: PERFORM_FAILOVER
            value: "true"
          ...

• 手動（プラグインベース）フェイルオーバー モードでは、 MongoDB kubernetes プラグインを使用して、新しい正常な Kubernetes クラスターを使用するように Kubernetes Operator を再構成 できます 。 このモードでは、 構成に基づいてMongoDBMultiClusterリソースを構成し、新しい正常なクラスター全体にレプリカセット ノードを分散します。

  このモードを有効にするには、Kubernetes用のMongoDB Helm Charts で --set multiCluster.performFailover=true を使用するか、次の省略された例のように、マルチ Kubernetes クラスターのMongoDBデプロイ環境変数 PERFORM_FAILOVER を false に設定します。

  spec:
    template:
      ...
      spec:
        containers:
        - name: mongodb-kubernetes-operator
          ...
          env:
          ...
          - name: PERFORM_FAILOVER
            value: "false"
          ...

MongoDB プラグインを使用した障害からの手動回復

1 つ以上の Kubernetes Operator インスタンスをホストしている Kubernetes クラスターがダウンした場合、またはレプリカセット ノードが、それを管理する Kubernetes と同じ失敗した Kubernetes クラスターに存在する場合、自動または手動フェイルオーバー モードに依存することはできず、次のコマンドを使用する必要があります障害が発生した Kubernetes クラスターから手動で回復する手順。

次の手順では、 MongoDB kubernetes プラグインを使用して次のようにします。

• 新しい正常な Kubernetes クラスターを構成します。

• これらのKubernetesクラスターを、マルチKubernetesクラスターMongoDB配置のmongodb-kubernetes-operator-member-list ConfigMapに新しいノードクラスターとして追加します。

• 正常な Kubernetes クラスター内のノードでMongoDBMultiClusterリソースをホストしているノードを再バランス化します。

手動障害復旧に関する次のチュートリアルでは、次のことを前提としています。

• 中央クラスター1つとノードクラスター3つを配置しました。Multi-Kubernetes-Cluster Quick Startに従います。この場合、Kubernetes 演算子は自動フェイルオーバーを無効にして--set multiCluster.performFailover=falseでインストールされます。

• MongoDBMultiClusterリソースを次のように配置しました。

  kubectl apply -n mongodb -f - <<EOF
  apiVersion: mongodb.com/v1
  kind: MongoDBMultiCluster
  metadata:
   name: multi-replica-set
  spec:
   version: 8.0.0
   type: ReplicaSet
   persistent: false
   duplicateServiceObjects: true
   credentials: my-credentials
   opsManager:
     configMapRef:
       name: my-project
   security:
     tls:
       ca: custom-ca
   clusterSpecList:
     - clusterName: ${MDB_CLUSTER_1_FULL_NAME}
       members: 3
     - clusterName: ${MDB_CLUSTER_2_FULL_NAME}
       members: 2
     - clusterName: ${MDB_CLUSTER_3_FULL_NAME}
       members: 3
  EOF

Kubernetes Operator は、対応するサーバーの /readyz エンドポイントを ping して、マルチ Kubernetes クラスターMongoDBデプロイ内のクラスターへの接続を定期的にチェックします。/readyz の詳細については、Kubernetes APIヘルス エンドポイント を参照してください。

この例のCLUSTER_3が使用できなくなった場合、Kubernetes Operator はクラスターへの接続の失敗を検出し、次回の調整のためにMongoDBMultiClusterリソースをfailedClustersアノテーションでマークします。

このクラスターに配置されたデータ ノードを含むリソースは、次の手順のように手動で回復手順を実行するまで、調整に失敗します。

MongoDB データ ノードを再バランスして、すべてのワークロードがCLUSTER_1とCLUSTER_2で実行されるようにするには、次の手順に従います。

kubectl mongodb multicluster recover \
  --central-cluster="MDB_CENTRAL_CLUSTER_FULL_NAME" \
  --member-clusters="${MDB_CLUSTER_1_FULL_NAME},${MDB_CLUSTER_2_FULL_NAME}" \
  --member-cluster-namespace="mongodb" \
  --central-cluster-namespace="mongodb" \
  --operator-name=mongodb-kubernetes-operator-multi-cluster \
  --source-cluster="${MDB_CLUSTER_1_FULL_NAME}"

kubectl apply -n mongodb -f - <<EOF
apiVersion: mongodb.com/v1
kind: MongoDBMultiCluster
metadata:
  name: multi-replica-set
spec:
  version: 8.0.0
  type: ReplicaSet
  persistent: false
  duplicateServiceObjects: true
  credentials: my-credentials
  opsManager:
    configMapRef:
      name: my-project
 security:
   tls:
     ca: custom-ca
 clusterSpecList:
   - clusterName: ${MDB_CLUSTER_1_FULL_NAME}
     members: 4
   - clusterName: ${MDB_CLUSTER_2_FULL_NAME}
     members: 3
 EOF

GitOps Workflows を使用した障害からの手動回復

Argo CD を使用した GitOps ワークフローでのMongoDB kubertl プラグインの使用例については、 GitOps 用のマルチクラスター プラグインの例を参照してください。

GitOps の復元には、 リソースファイルを使用した ロールベースのアクセス制御 .yamlの手動再構成が必要です。詳しくは、「 Kubernetes のロールとロール バインディングの理解 」を参照してください。