障害復旧
項目一覧
Kubernetes Operator は、Kubernetes Operator が元の Kubernetes クラスターがダウンしていることを識別する場合に、MongoDB レプリカセット メンバーを正常な Kubernetes クラスターに回復するように調整できます。
障害復旧モード
Kubernetes Operator は、次のいずれかのモードを使用して、障害復旧シナリオで MongoDBMultiCluster
リソースの自動または手動修復のいずれかをオーケストレーションできます。
自動フェイルオーバー モードを使用すると、Kubernetes Operator は、影響を受ける MongoDB レプリカセット メンバーを、正常でない Kubernetes クラスターから正常な Kubernetes クラスターに移行できます。 Kubernetes Operator がこの自動修正を実行すると、レプリカセット メンバーが正常な Kubernetes クラスター全体に均等に分散されます。
このモードを有効にするには、
--set multiCluster.performFailover=true
Kubernetes用のMongoDB Helm Charts で を使用します。 Kubernetesvalues.yaml
{ 用の MongoDB Helm Charts の ファイル内 ディレクトリ)、環境の変数のデフォルト値はtrue
です。あるいは、次の省略された例のように、マルチ Kubernetes クラスター MongoDB 配置環境変数
PERFORM_FAILOVER
をtrue
に設定することもできます。spec: template: ... spec: containers: - name: mongodb-enterprise-operator ... env: ... - name: PERFORM_FAILOVER value: "true" ... 手動(プラグインベース)フェイルオーバー モードでは、 MongoDB kubernetes プラグインを使用して、新しい正常な Kubernetes クラスターを使用するように Kubernetes Operator を再構成 します。 このモードでは、構成に基づいて
MongoDBMultiCluster
リソースを構成し、新しい正常なクラスター全体にレプリカセット ノードを分散します。このモードを有効にするには 、Kubernetes
--set multiCluster.performFailover=true
用の MongoDB Helm Charts でPERFORM_FAILOVER
を使用します。false
または、次の省略された例のように、マルチ Kubernetes クラスター MongoDB 配置環境変数 を に設定します。spec: template: ... spec: containers: - name: mongodb-enterprise-operator ... env: ... - name: PERFORM_FAILOVER value: "false" ...
注意
1 つ以上の Kubernetes Operator インスタンスをホストしている Kubernetes クラスターがダウンした場合、またはレプリカセット ノードが、それを管理する Kubernetes と同じ失敗した Kubernetes クラスター上に存在する場合、自動または手動フェイルオーバー モードに依存することはできません。
このような場合、失われた Kubernetes クラスターから残りの正常な Kubernetes クラスターにレプリカセット ノードを復元するには、まず複数の Kubernetes クラスター MongoDB 配置を管理する Kubernetes Operator インスタンスを復元するか、Kubernetes Operator を残りの Kubernetes クラスターの 1 つに再デプロイする必要があります。をクリックし、 kubectl mongodb
プラグインを再実行します。 詳細については、「 MongoDB プラグインを使用した障害からの手動回復 」を参照してください。
MongoDB プラグインを使用した障害からの手動回復
1 つ以上の Kubernetes Operator インスタンスをホストしている Kubernetes クラスターがダウンした場合、またはレプリカセット ノードが、それを管理する Kubernetes と同じ失敗した Kubernetes クラスターに存在する場合、自動または手動フェイルオーバー モードに依存することはできず、次のコマンドを使用する必要があります障害が発生した Kubernetes クラスターから手動で回復する手順。
次の手順では、 MongoDB kubernetes プラグインを使用して次のようにします。
新しい正常な Kubernetes クラスターを構成します。
これらの Kubernetes クラスターを新しいノード クラスターとして、マルチ Kubernetes クラスター MongoDB 配置の
mongodb-enterprise-operator-member-list
ConfigMap に追加します。正常な Kubernetes クラスター内のノードで
MongoDBMultiCluster
リソースをホストしているノードを再バランス化します。
手動障害復旧に関する次のチュートリアルでは、次のことを前提としています。
マルチKubernetes-クラスター クイック スタートに従って、1 つの中央クラスターと 3 つのノード クラスターを配置します。 この場合、Kubernetes Operator は、
--set multiCluster.performFailover=false
で無効になっている自動フェイルオーバーを使用してインストールされます。MongoDBMultiCluster
リソースを次のように配置しました。kubectl apply -n mongodb -f - <<EOF apiVersion: mongodb.com/v1 kind: MongoDBMultiCluster metadata: name: multi-replica-set spec: version: 6.0.5-ent 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 は、対応するサーバーの/healthz
エンドポイントを ping して、マルチ Kubernetes クラスター MongoDB 配置内のクラスターへの接続を定期的にチェックします。 /healthz
の詳細については、「 Kubernetes API ヘルスエンドポイント 」を参照してください。 。
この例のCLUSTER_3
が使用できなくなった場合、Kubernetes Operator はクラスターへの接続の失敗を検出し、次回の調整のためにMongoDBMultiCluster
リソースをfailedClusters
アノテーションでマークします。
このクラスターに配置されたデータ ノードを含むリソースは、次の手順のように手動で回復手順を実行するまで、調整に失敗します。
MongoDB データ ノードを再バランスして、すべてのワークロードがCLUSTER_1
とCLUSTER_2
で実行されるようにするには、次の手順に従います。
MongoDB kubernetes クラスターのMongoDBデプロイを回復するには、 MongoDB kubernetesプラグイン を使用します。
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-enterprise-operator-multi-cluster \ --source-cluster="${MDB_CLUSTER_1_FULL_NAME}"
このコマンド:
2 つの正常な Kubernetes クラスターのワークロードを管理するように Kubernetes Operator を再構成します。 (このリストには新しい Kubernetes クラスターも含まれる場合があります)。
新しい Kubernetes クラスターのノード ノード構成の構成ソースとして
CLUSTER_1
をマークします。CLUSTER_1
の構成と一致するようにロールとサービス アカウントの構成を複製します。
正常な Kubernetes クラスター上のデータ ノードを再バランスをとります。
MongoDBMultiCluster
リソースを再構成し、変更の影響を受けるリソースを編集して、正常な Kubernetes クラスター上のデータ ノードを再バランスします。
kubectl apply -n mongodb -f - <<EOF apiVersion: mongodb.com/v1 kind: MongoDBMultiCluster metadata: name: multi-replica-set spec: version: 6.0.0-ent 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 のロールとロール バインディングの理解 」を参照してください。