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 - <<EOFapiVersion: mongodb.com/v1kind: MongoDBMultiClustermetadata: name: multi-replica-setspec: 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: 3EOF

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 - <<EOFapiVersion: mongodb.com/v1kind: MongoDBMultiClustermetadata:  name: multi-replica-setspec:  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.