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 Charts MongoDB Helm para Kubernetes. No arquivo values.yaml no diretório MongoDB Helm Charts for Kubernetes, o valor padrão da variável do ambiente é true.

  Como alternativa, você pode definir a variável de ambiente de sistema do MongoDB do cluster multi-Kubernetes PERFORM_FAILOVER como true, como no exemplo abreviado a seguir:

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

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

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

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

Quando o failover automático está desabilitado, o operador remove a anotação failedClusters depois que um cluster passa nas verificações de integridade um número configurado de vezes consecutivas. Você pode configurar esse limite usando uma variável de ambiente ou um valor Helm.

Recuperar manualmente de uma falha usando o plug-in MongoDB

Quando um cluster Kubernetes que hospeda uma ou mais instâncias do Kubernetes Operator é desativado ou o membro do conjunto de réplicas reside no mesmo cluster Kubernetes com falha que o Kubernetes que o gerencia, 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 Kubernetes como novos clusters membros ao mongodb-kubernetes-operator-member-list ConfigMap para seu sistema MongoDB de clusters Kubernetes múltiplos.

• 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ê:

• Distribuiu um cluster de operadores e três clusters de membros, seguindo o Início Rápido 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: 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

O Operador Kubernetes verifica periodicamente a conectividade com os clusters no sistema MongoDB de clusters multi-Kubernetes fazendo ping nos endpoints /readyz dos servidores correspondentes. Para saber mais sobre /readyz, 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. O operador remove essa anotação depois que o cluster passa nas verificações de integridade um número configurado de vezes consecutivas.

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-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

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

Para obter um exemplo de uso do plugin-in kubectl do MongoDB em um fluxo de trabalho GitOps com o Agos CD, consulte exemplo de plugin-in de vários clusters para GitOps.

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