Recuperação de desastres

Modos de recuperação após desastres

O Operador Kubernetes pode orquestrar uma correção automática ou manual dos recursos do MongoDBMultiCluster em um cenário de recuperação de desastres, utilizando um dos seguintes modos:

• O Modo de Failover Automático permite que o Operador do Kubernetes desloque os membros do conjunto de réplicas do MongoDB afetado de um cluster do Kubernetes não íntegro para clusters do Kubernetes íntegros. Quando o Operador Kubernetes executa essa correção automática, ele distribui uniformemente os membros do conjunto de réplicas entre os clusters Kubernetes íntegros.

  Para habilitar este modo, utilize --set multiCluster.performFailover=true nos MongoDB Helm Charts para Kubernetes. No values.yaml arquivo nos MongoDB Helm Charts para Kubernetes diretório, o valor padrão da variável do ambiente é true.

  Como alternativa, você pode configurar a variável do ambiente de implantação do Kubernetes multi-cluster PERFORM_FAILOVER true no exemplo abreviado a seguir:

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

• O modo de failover manual (baseado em plug-ins) permite que você use o plug- in MongoDB Kubectl para reconfigurar o Kubernetes Operator para usar novos clusters de Kubernetes íntegros. Neste modo, você distribui membros do conjunto de réplicas entre os novos clusters íntegros configurando o recurso MongoDBMultiCluster com base em sua configuração.

  Para habilitar este modo, use --set multiCluster.performFailover=true nos MongoDB Helm Charts para Kubernetes, ou defina a variável de ambiente de sistema de multi-Kubernetes-cluster PERFORM_FAILOVER como false, como no exemplo abreviado a seguir:

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

Recuperar manualmente de uma falha usando o plug-in MongoDB

Quando um cluster Kubernetes que hospeda uma ou mais instâncias do Kubernetes Operator fica inativo ou o membro do conjunto de réplicas reside no mesmo cluster Kubernetes com falha que o Kubernetes que o managed, você não pode confiar nos modos de failover automático ou manual e deve usar o seguinte procedimento para recuperar manualmente de um cluster Kubernetes com falha.

O procedimento a seguir usa o plug- in MongoDB Kubectl para:

• Configure novos clusters Kubernetes íntegros.

• Adicione estes clusters do Kubernetes como novos clusters de membros ao ConfigMap do mongodb-enterprise-operator-member-list para sua implantação de múltiplos clusters do Kubernetes.

• Reequilibre os nós que hospedam recursos do MongoDBMultiCluster nos nós nos clusters Kubernetes íntegros.

O tutorial a seguir sobre recuperação manual de desastres pressupõe que você:

• Implementou um cluster central e três clusters de membros, seguindo o Quick Start de Multi-Kubernetes-Cluster. Nesse caso, o Kubernetes Operator é instalado com o failover automatizado desabilitado com --set multiCluster.performFailover=false.

• Implantou um recurso MongoDBMultiCluster da seguinte forma:

  kubectl apply -n mongodb -f - <<EOF
  apiVersion: mongodb.com/v1
  kind: MongoDBMultiCluster
  metadata:
   name: multi-replica-set
  spec:
   version: 5.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

O Operador do Kubernetes verifica periodicamente a conectividade com os clusters na implantação de vários clusters do Kubernetes fazendo ping nos endpoints /healthz dos servidores correspondentes. Para saber mais sobre /healthz, consulte os endpoints de integridade da API Kubernetes.

Caso CLUSTER_3 em nosso exemplo fique indisponível, o Kubernetes Operator detecta as conexões com falha com o cluster e marca os recursos MongoDBMultiCluster com a anotação failedClusters para reconciliações subsequentes.

Os recursos com nós de dados distribuídos nesse cluster falham na reconciliação até que você execute as etapas manuais de recuperação, como no procedimento a seguir.

Para reequilibrar os nós de dados do MongoDB para que todos os volumes de trabalho sejam executados em CLUSTER_1 e 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-enterprise-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: 5.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: 4
   - clusterName: ${MDB_CLUSTER_2_FULL_NAME}
     members: 3
 EOF

Recuperar-se manualmente de uma falha usando fluxos de trabalho do GitOps

Para ver um exemplo de uso do plugin Kubectl do MongoDB em um fluxo de trabalho GitOps com o ARG CD, consulte o exemplo de plug-in multi-cluster para GitOps.

A recuperação do GitOps requer reconfiguração manual do Controle de Acesso Baseado em Função usando .yaml arquivos de recursos . Para saber mais, consulte Entender funções e vinculações de funções do Kubernetes.