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

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 esses cluster Kubernetes como novos nó cluster ao ConfigMap mongodb-kubernetes-operator-member-list para sua implantação do MongoDB em vários cluster 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ê:

• Implantar um cluster central e três clusters de nós, seguindo o Guia de Início Rápido de Multi-Kubernetes-Cluster. Nesse caso, o Kubernetes operador é instalado com o failover automatizado desativado 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.

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.