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.

  To enable this mode, use --set multiCluster.performFailover=true in the MongoDB Helm Charts for Kubernetes. In the values.yaml file in the MongoDB Helm Charts for Kubernetes directory, the environment's variable default value is 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"
          ...

• Modo de conmutación por error manual (basado en plugins) le permite utilizar el plugin kubectl de MongoDB para reconfigurar el Operador de Kubernetes para usar nuevos clústeres saludables de Kubernetes. En este modo, distribuyes los miembros del conjunto de réplicas en los nuevos clústeres saludables al configurar el recurso MongoDBMultiCluster según tu configuración.

  To enable this mode, use --set multiCluster.performFailover=true in the MongoDB Helm Charts for Kubernetes, or set the multi-Kubernetes cluster MongoDB deployment environment variable PERFORM_FAILOVER to false, as in the following abbreviated example:

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

Cuando la conmutación por error automática está deshabilitada, el operador elimina la anotación failedClusters después de que un clúster pasa las verificación de estado un número configurado de veces consecutivas. Puede configurar este umbral utilizando una variable de entorno o un valor de Helm.

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

  MongoDBMultiCluster Recursos

  en los nodos de los clústeres de Kubernetes sanos.

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 ha implementado el 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 el

MongoDBMultiCluster Recursos

con la anotación failedClusters para reconciliaciones posteriores. El operador elimina esta anotación después de que el clúster pasa las verificaciones de estado un número configurado de veces consecutivas.

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 obtener un ejemplo del uso del plugin MongoDB kubectl en un flujo de trabajo GitOps con Argo CD, consulta ejemplo del plugin de múltiples clústeres para GitOps.

GitOps recovery requires manual reconfiguration of Role Based Access Control using .yaml resource files. To learn more, see Understand Kubernetes Roles and Role Bindings.