recuperación ante desastres

Modos de recuperación ante desastres

El operador de Kubernetes puede orquestar una corrección automática o manual de los recursos de MongoDBMultiCluster en un escenario de recuperación ante desastres, utilizando uno de los siguientes modos:

• El Modo de failover automático permite que el operador de Kubernetes traslade los miembros afectados del set de réplicas de MongoDB de un clúster de Kubernetes no saludable a clústeres saludables de Kubernetes. Cuando el operador de Kubernetes realiza esta autorremediación, distribuye uniformemente los miembros del set de réplicas en los clústeres saludables de Kubernetes.

  Para activar este modo, utiliza --set multiCluster.performFailover=true en los Helm Charts de MongoDB para Kubernetes. En el archivo values.yaml en el Charts Helm de MongoDB para Kubernetes directorio, el valor por defecto de la variable del entorno es true.

  Como alternativa, puedes configurar la variable de entorno de la implementación de MongoDB en clústeres múltiples de Kubernetes PERFORM_FAILOVER en true, como se muestra en el siguiente ejemplo abreviado:

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

• El modo de conmutación por error manual (basado en complementos) permite usar el complemento kubectl de MongoDB para reconfigurar el operador de Kubernetes y utilizar nuevos clústeres de Kubernetes en buen estado. En este modo, se distribuyen los miembros del conjunto de réplicas entre los nuevos clústeres en buen estado configurando el recurso MongoDBMultiCluster según la configuración.

  Para habilitar este modo, utiliza --set multiCluster.performFailover=true en los Helm Charts de MongoDB para Kubernetes, o establece la variable de entorno de la implementación de MongoDB en múltiples clústeres de Kubernetes PERFORM_FAILOVER a false, como en el siguiente ejemplo abreviado:

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

Recuperación manual de una falla mediante el plugin de MongoDB

Cuando un clúster de Kubernetes que aloja una o más instancias de Kubernetes Operator deja de funcionar, o cuando el miembro del set de réplicas reside en el mismo clúster de Kubernetes fallido que lo administra, no se puede confiar en los modos de conmutación por error automáticos o manuales, y se debe utilizar el siguiente procedimiento para recuperarse manualmente de un clúster de Kubernetes fallido.

El siguiente procedimiento utiliza el MongoDB kubectl Plugin para:

• Configura nuevos clústeres saludables de Kubernetes.

• Agrega estos clústeres Kubernetes como nuevos clústeres nodos al ConfigMap mongodb-kubernetes-operator-member-list para la implementación de MongoDB en múltiples clústeres de Kubernetes.

• Reequilibrar los nodos que alojan recursos de MongoDBMultiCluster en los nodos de los clústeres de Kubernetes que funcionan correctamente.

El siguiente tutorial para la recuperación manual ante desastres asume que:

• Desplegó un clúster de operador y tres clústeres nodos, siguiendo la Guía rápida de Multi-Kubernetes-Cluster. En este caso, el Operador de Kubernetes se instala con el traspaso automático desactivado usando --set multiCluster.performFailover=false.

• Se implementó un recurso MongoDBMultiCluster de la siguiente manera:

  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

El Operador de Kubernetes verifica periódicamente la conectividad con los clústeres en la implementación de MongoDB multi-Kubernetes, haciendo ping a los endpoints de /readyz de los servidores correspondientes. Para obtener más información sobre /readyz, consulta los Endpoints de salud de la API de Kubernetes.

En el caso de que CLUSTER_3 en nuestro ejemplo deje de estar disponible, el operador de Kubernetes detecta las conexiones fallidas al clúster y marca los recursos MongoDBMultiCluster con la anotación failedClusters para las reconciliaciones posteriores.

Los recursos con nodos de datos implementados en este clúster fallan la reconciliación hasta que se ejecuten los pasos de recuperación manual según el siguiente procedimiento.

Para equilibrar los nodos de datos de MongoDB, de modo que todas las cargas de trabajo se ejecuten en CLUSTER_1 y 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

Recupera manualmente de un fallo utilizando flujos de trabajo GitOps

Para un ejemplo de uso del plugin MongoDB kubectl en un flujo de trabajo GitOps con Argo CD, consute plugin multiclúster para GitOps.

La recuperación de GitOps requiere reconfiguración manual del Control de Acceso Basado en Roles utilizando .yaml archivos de recursos. Para obtener más información, consulta Comprender los roles y vinculaciones de roles de Kubernetes.