Recuperación ante desastres

Modos de recuperación ante desastres

El operador de Kubernetes puede orquestar una remediación automática o manual del MongoDBMultiCluster recursos 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 habilitar este modo, utilice --set multiCluster.performFailover=true en los gráficos de MongoDB Helm para Kubernetes. En values.yaml el archivo de los gráficos de MongoDB Helm para Kubernetesdirectorio, el valor predeterminado de la variable de entorno true es.

  Como alternativa, puede establecer la variable de entorno de implementación de MongoDB del clúster multi-Kubernetes PERFORM_FAILOVER en true, como en el siguiente ejemplo abreviado:

  spec:
    template:
      ...
      spec:
        containers:
        - name: mongodb-enterprise-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 usar los 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 MongoDBMultiCluster recurso según la configuración.

  Para habilitar este modo, utilice --set multiCluster.performFailover=true en los gráficos Helm de MongoDB para Kubernetes o configure la variable de entorno de implementación de MongoDB del clúster de Kubernetes múltiple PERFORM_FAILOVER falseen, como en el siguiente ejemplo abreviado:

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

Recuperarse manualmente de un fallo mediante el complemento MongoDB

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

El siguiente procedimiento utiliza el complemento kubectl de MongoDB para:

• Configurar nuevos clústeres de Kubernetes en buen estado.

• Agregue estos clústeres de Kubernetes como nuevos clústeres miembros al ConfigMap mongodb-enterprise-operator-member-list para su implementación de MongoDB de múltiples clústeres de Kubernetes.

• Reequilibre los nodos que alojan MongoDBMultiCluster recursos en los nodos de los clústeres de Kubernetes en buen estado.

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

• Se implementó un clúster de operador y tres clústeres miembros, siguiendo el inicio rápido de clústeres múltiples de Kubernetes. En este caso, el operador de Kubernetes se instaló con la conmutación por error automática deshabilitada --set multiCluster.performFailover=false con.

• 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: 6.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

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 no esté disponible, el operador de Kubernetes detecta las conexiones fallidas al clúster y marca los recursos MongoDBMultiCluster con la anotación failedClusters para conciliaciones posteriores.

Los recursos con nodos de datos implementados en este clúster no se pueden conciliar hasta que ejecute los pasos de recuperación manual como en el siguiente procedimiento.

Para reequilibrar 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-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: 6.0.0-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

Recuperarse manualmente de un fallo mediante flujos de trabajo de GitOps

Para ver un ejemplo de uso del complemento kubectl de MongoDB en un flujo de trabajo de GitOps con Argo CD, consulte el ejemplo de complemento de múltiples clústeres para GitOps.

La recuperación de GitOps requiere la reconfiguración manual del control de acceso basado en roles mediante los .yaml archivos de recursos. Para obtener más información, consulte Descripción de los roles y las vinculaciones de roles de Kubernetes.