Skip to main content
Hay disponible una nueva versión de este producto.
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Protección de datos

Colaboradores
PDF

Conozca las opciones de protección de datos y capacidad de recuperación que ofrecen las plataformas de almacenamiento de NetApp. Astra Trident puede aprovisionar volúmenes que puedan aprovechar algunas de estas funciones. Debería tener una estrategia de protección y recuperación de datos para cada aplicación con un requisito de persistencia.

Realice una copia de seguridad del etcd datos del clúster

Astra Trident almacena sus metadatos en el clúster de Kubernetes etcd base de datos. Realizar una copia de seguridad periódica del etcd Los datos del clúster son importantes para recuperar los clústeres de Kubernetes en situaciones de desastre.

Pasos

  1. La etcdctl snapshot save comando permite realizar una copia snapshot de un momento específico de etcd clúster:

    sudo docker run --rm -v /backup:/backup \
  --network host \
  -v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
  --env ETCDCTL_API=3 \
  registry.k8s.io/etcd-amd64:3.2.18 \
  etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
  --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
  snapshot save /backup/etcd-snapshot.db

    Este comando crea una instantánea etcd girando un contenedor etcd y lo guarda en /backup directorio.

  2. En caso de desastre, puede iniciar un clúster de Kubernetes usando las snapshots de etcd. Utilice la etcdctl snapshot restore comando para restaurar una instantánea específica realizada en la /var/lib/etcd carpeta. Después de la restauración, confirme si /var/lib/etcd se ha completado la carpeta con member carpeta. A continuación se muestra un ejemplo de etcdctl snapshot restore comando:

    etcdctl snapshot restore '/backup/etcd-snapshot-latest.db' ; mv /default.etcd/member/ /var/lib/etcd/

  3. Antes de inicializar el clúster de Kubernetes, copie todos los certificados necesarios.

  4. Cree el clúster con el --ignore-preflight-errors=DirAvailable—​var-lib-etcd bandera.

  5. Una vez que el clúster haya terminado, asegúrese de que los pods de kube-system hayan comenzado.

  6. Utilice la kubectl get crd Comando para comprobar si existen los recursos personalizados que ha creado Trident y recuperar los objetos de Trident para garantizar que todos los datos estén disponibles.

Recuperar la fecha utilizando snapshots de ONTAP

Las copias Snapshot tienen un papel importante al proporcionar opciones de recuperación a un momento específico para los datos de aplicaciones. Sin embargo, las copias Snapshot no son backups por sí mismas, no protegen contra fallos del sistema de almacenamiento u otras catástrofes. No obstante, son un método cómodo, rápido y sencillo para recuperar datos en la mayoría de escenarios. Obtenga más información sobre cómo usar la tecnología Snapshot de ONTAP para realizar backups del volumen y cómo restaurarlos.

  • Si la política de snapshot no se ha definido en el back-end, de forma predeterminada utiliza el none política. Esto da como resultado que ONTAP no realice instantáneas automáticas. No obstante, el administrador de almacenamiento puede realizar copias Snapshot manuales o cambiar la política de Snapshot a través de la interfaz de gestión de ONTAP. Esto no afecta al funcionamiento de Trident.

  • El directorio de instantáneas está oculto de forma predeterminada. De este modo se facilita la máxima compatibilidad de volúmenes aprovisionados mediante el ontap-nas y.. ontap-nas-economy de windows Habilite el .snapshot cuando utilice ontap-nas y.. ontap-nas-economy controladores para permitir que las aplicaciones recuperen datos de instantáneas directamente.

  • Restaure un volumen a un estado registrado en una instantánea anterior mediante el volume snapshot restore Comando de la CLI de ONTAP. Al restaurar una copia Snapshot, la operación de restauración sobrescribe la configuración de volúmenes existente. Se perderán todos los cambios que se realicen en los datos del volumen después de crear la copia Snapshot.

cluster1::*> volume snapshot restore -vserver vs0 -volume vol3 -snapshot vol3_snap_archive

Replicación de datos mediante ONTAP

El replicación de datos puede tener un rol importante en la protección contra la pérdida de datos debido al fallo de la cabina de almacenamiento.

Nota Para obtener más información sobre las tecnologías de replicación de ONTAP, consulte "Documentación de ONTAP".

Replicación de SnapMirror Storage Virtual Machines (SVM)

Puede utilizar "SnapMirror" Para replicar una SVM completa, que incluye su configuración y sus volúmenes. En caso de desastre, puede activar la SVM de destino de SnapMirror para empezar a servir datos. Puede volver al primario cuando se restauren los sistemas.

Astra Trident no puede configurar las relaciones de replicación por sí mismo, de modo que el administrador de almacenamiento pueda usar la función de replicación de SVM de SnapMirror de ONTAP para replicar automáticamente volúmenes en un destino de recuperación ante desastres (DR).

Tenga en cuenta lo siguiente si tiene pensado utilizar la función de replicación de SVM de SnapMirror o si actualmente utiliza la función:

  • Debe crear un back-end distinto para cada SVM, la cual tiene habilitada la SVM-DR.

  • Debe configurar las clases de almacenamiento para no seleccionar los back-ends replicados, excepto cuando se desee. Esto es importante para evitar que se aprovisionen volúmenes que no necesiten la protección de una relación de replicación en los back-end que sean compatibles con SVM-DR.

  • Los administradores de aplicaciones deben comprender el coste y la complejidad adicionales que supone la replicación de datos, así como tener en cuenta un plan de recuperación antes de aprovechar esta replicación.

  • Antes de activar la SVM de destino de SnapMirror, detenga todas las transferencias programadas de SnapMirror, aborte todas las transferencias continuas de SnapMirror, rompa la relación de replicación, detenga la SVM de origen e inicie la SVM de destino de SnapMirror.

  • Astra Trident no detecta automáticamente fallos de SVM. Por lo tanto, en caso de que se produzca un error, el administrador debe ejecutar el tridentctl backend update Comando para activar la conmutación por error de Trident al nuevo back-end.

A continuación se ofrece información general de los pasos de configuración de SVM:

  • Configure una relación entre iguales entre los clústeres de origen y destino y SVM.

  • Cree la SVM de destino mediante el -subtype dp-destination opción.

  • Cree un programa de trabajo de replicación para asegurarse de que la replicación se produce en los intervalos necesarios.

  • Cree una replicación de SnapMirror a partir de la SVM de destino con la SVM de origen mediante el -identity-preserve true Opción para garantizar que las configuraciones de SVM de origen y las interfaces de SVM de origen se copian en el destino. En la SVM de destino, inicialice la relación de replicación de SVM de SnapMirror.

Muestra los pasos involucrados en la configuración de SVM.

Flujo de trabajo de recuperación ante desastres para Trident

Astra Trident 19.07 y versiones posteriores utilizan los CRD de Kubernetes para almacenar y gestionar su propio estado. Usa los clústeres de Kubernetes etcd para almacenar sus metadatos. En este caso asumimos que el Kubernetes etcd Los archivos de datos y los certificados se almacenan en NetApp FlexVolume. Este volumen FlexVolume reside en una SVM, que tiene una relación de SVM-recuperación ante desastres de SnapMirror con una SVM de destino en el sitio secundario.

Los siguientes pasos describen cómo recuperar un único clúster Kubernetes maestro con Astra Trident en caso de desastre:

  1. Si la SVM de origen falla, active la SVM de destino de SnapMirror. Para ello, debe detener las transferencias de SnapMirror programadas, anular las transferencias continuas de SnapMirror, romper la relación de replicación, detener la SVM de origen e iniciar la SVM de destino.

  2. Desde la SVM de destino, monte el volumen que contiene Kubernetes etcd archivos de datos y certificados en el host que se configurarán como un nodo maestro.

  3. Copie todos los certificados necesarios relacionados con el clúster de Kubernetes en /etc/kubernetes/pki y el etcd member archivos en /var/lib/etcd.

  4. Cree un clúster de Kubernetes mediante el kubeadm init con el --ignore-preflight-errors=DirAvailable—​var-lib-etcd bandera. Los nombres de host utilizados para los nodos de Kubernetes deben ser los mismos que el clúster de Kubernetes de origen.

  5. Ejecute el kubectl get crd Comando para verificar si todos los recursos personalizados de Trident han aparecido y recuperar los objetos de Trident para verificar que todos los datos estén disponibles.

  6. Actualice todos los back-ends necesarios para reflejar el nuevo nombre de SVM de destino. Para ello, ejecute el ./tridentctl update backend <backend-name> -f <backend-json-file> -n <namespace> comando.

Nota En el caso de los volúmenes persistentes de la aplicación, cuando se activa la SVM de destino, todos los volúmenes aprovisionados mediante Trident empiezan a servir datos. Una vez que el clúster de Kubernetes se configura en el lado de destino mediante los pasos descritos anteriormente, se inician todas las puestas en marcha y pods y las aplicaciones en contenedores deben ejecutarse sin ningún problema.

Replicación de volúmenes de SnapMirror

La replicación de volúmenes de SnapMirror de ONTAP es una función de recuperación ante desastres que permite llevar a cabo la conmutación al nodo de respaldo en el almacenamiento de destino desde el almacenamiento principal a nivel de volumen. SnapMirror crea una réplica o un reflejo de volumen del almacenamiento principal en el almacenamiento secundario mediante la sincronización de las copias Snapshot.

A continuación se ofrece información general de los pasos de configuración de la replicación de volúmenes de SnapMirror de ONTAP:

  • Configure una relación entre los clústeres en los que residen los volúmenes y las SVM que sirven datos de los volúmenes.

  • Cree una política de SnapMirror, que controla el comportamiento de la relación y especifica los atributos de configuración de esa relación.

  • Cree una relación de SnapMirror entre el volumen de destino y el de origen mediante la[snapmirror create Command] y asigne la política de SnapMirror correspondiente.

  • Una vez creada la relación de SnapMirror, inicialice la relación de forma que haya completado una transferencia inicial desde el volumen de origen al volumen de destino.

Muestra la configuración de replicación de volúmenes de SnapMirror.

Flujo de trabajo de recuperación ante desastres de volúmenes de SnapMirror para Trident

En los siguientes pasos se describe cómo recuperar un único clúster Kubernetes maestro con Astra Trident.

  1. En caso de desastre, detenga todas las transferencias programadas de SnapMirror y cancele todas las transferencias continuas de SnapMirror. Rompa la relación de replicación entre los volúmenes de destino y de origen para que el volumen de destino se convierta en de lectura/escritura.

  2. Desde la SVM de destino, monte el volumen que contiene Kubernetes etcd archivos de datos y certificados en el host, que se configurarán como un nodo maestro.

  3. Copie todos los certificados necesarios relacionados con el clúster de Kubernetes en /etc/kubernetes/pki y el etcd member archivos en /var/lib/etcd.

  4. Ejecute el para crear un clúster de Kubernetes kubeadm init con el --ignore-preflight-errors=DirAvailable—​var-lib-etcd bandera. Los nombres de host deben ser los mismos que el clúster de Kubernetes de origen.

  5. Ejecute el kubectl get crd Comando para comprobar si todos los recursos personalizados de Trident han aparecido y recuperan objetos de Trident para garantizar que todos los datos estén disponibles.

  6. Limpiar los back-ends anteriores y crear nuevos back-ends en Trident. Especifique el nuevo LIF de gestión, el nuevo nombre de la SVM y la contraseña de la SVM de destino.

Flujo de trabajo de recuperación ante desastres para volúmenes persistentes de aplicaciones

Los pasos siguientes describen cómo pueden ponerse volúmenes de destino de SnapMirror disponibles para cargas de trabajo en contenedores en caso de desastre:

  1. Detenga todas las transferencias programadas de SnapMirror y cancele todas las transferencias continuas de SnapMirror. Rompa la relación de replicación entre el volumen de destino y el de origen para que el volumen de destino se convierta en de lectura/escritura. Borre las puestas en marcha que consumían PVC vinculado a volúmenes en la SVM de origen.

  2. Una vez que el clúster de Kubernetes se ha configurado en el lado de destino mediante los pasos descritos anteriormente, limpie las puestas en marcha, las RVP y el VP, del clúster de Kubernetes.

  3. Cree nuevos back-ends en Trident especificando las nuevas LIF de gestión y datos, el nuevo nombre de SVM y la contraseña de la SVM de destino.

  4. Importe los volúmenes necesarios como un VP vinculado a una nueva RVP mediante la función de importación Trident.

  5. Vuelva a poner en marcha las implementaciones de aplicaciones con las RVP recién creadas.

Recuperar datos mediante copias de Snapshot de Element

Realizar un backup de los datos de un volumen de Element mediante la configuración de una programación de Snapshot para el volumen y la garantía de que las copias de Snapshot se tomen en los intervalos requeridos. Debe establecer la programación de Snapshot mediante las API o la interfaz de usuario de Element. Actualmente, no es posible establecer una programación de snapshots en un volumen a través del solidfire-san controlador.

En caso de que los datos se dañen, es posible seleccionar una snapshot determinada y revertir el volumen a la snapshot manualmente mediante las API o la interfaz de usuario de Element. De este modo se revierten los cambios que se hayan hecho al volumen desde el momento de la creación de la snapshot.