Recuperación ante desastres

Modos de recuperación ante desastres

El Operador de Kubernetes puede orquestar una remediación automática o manual de la 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, utiliza --set multiCluster.performFailover=true en los Helm Charts de MongoDB para Kubernetes. En el archivo values.yaml en el En el directorio MongoDB Helm Charts para Kubernetes, el valor predeterminado de la variable de entorno true es.

  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 complemento) le permite utilizar el Plugin kubectl de MongoDB para reconfigurar el Operador de Kubernetes y utilizar nuevos clústeres saludables de Kubernetes. En este modo, puedes distribuir los miembros del set de réplicas entre los nuevos clústeres seguros, configurando el recurso MongoDBMultiCluster según tu 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-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 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 MongoDB kubectl Plugin para:

• Configura nuevos clústeres saludables de Kubernetes.

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

• Rebalancear los nodos que alojan recursos de MongoDBMultiCluster en los nodos de los clústeres saludables de Kubernetes.

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

• 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 se vuelva inaccesible, el Operador de Kubernetes detecta las fallas de conexión al clúster y marca los recursos MongoDBMultiCluster con la anotación failedClusters para las reconciliaciones subsiguientes.

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.