NetApp Disaster Recovery es un servicio de recuperación ante desastres basado en cloud, al que se accede a través de la NetApp Console, que automatiza los flujos de trabajo de recuperación ante desastres para entornos VMware y Kubernetes. Replica las cargas de trabajo de VMware locales que se ejecutan en almacenamiento ONTAP, o las cargas de trabajo de Kubernetes que se ejecutan en almacenamiento ONTAP gestionado por Trident, a otra ubicación como destino de recuperación ante desastres. El servicio utiliza la tecnología ONTAP SnapMirror, con orquestación nativa de VMware o de Trident Protect, para proteger las cargas de trabajo mientras conserva las eficiencias del almacenamiento ONTAP, como la compresión y la deduplicación.

La recuperación ante desastres no requiere ninguna configuración adicional. Aparece automáticamente en la navegación izquierda de la NetApp Console, en Protection > Disaster recovery. Para acceder a la NetApp Console, en un navegador, introduce: "https://console.netapp.com/".

Se requiere una licencia de recuperación ante desastres para disponer de acceso completo y continuo. Puedes probar el servicio con una prueba gratuita de 30 días antes de adquirir una licencia o suscripción. Para obtener más información, consulta "Configura las licencias de recuperación ante desastres".

La recuperación ante desastres admite los siguientes objetivos de protección:

Para las cargas de trabajo de VMware, la recuperación ante desastres admite los siguientes tipos de almacenes de datos:

En el caso de las cargas de trabajo de Kubernetes, la función de recuperación ante desastres protege los volúmenes persistentes aprovisionados a través de NetApp Trident en el almacenamiento ONTAP.

Disaster Recovery ofrece las siguientes opciones de licencia:

Los cargos por recuperación ante desastres se calculan en función de la capacidad utilizada de los almacenes de datos en el sitio de origen cuando hay al menos una máquina virtual o un recurso de Kubernetes que cuenta con un plan de replicación.

En el caso de un BYOL, si los datos superan la capacidad permitida, las operaciones en el servicio están limitadas hasta que obtengas una licencia de capacidad adicional o actualices la licencia en la NetApp Console.

Una vez finalizado el periodo de prueba gratuito, podrás seguir viendo y eliminando recursos como cargas de trabajo y planes de replicación, y ejecutar todas las operaciones programadas que se crearon durante el periodo de prueba. Para seguir utilizando el servicio con todas sus funciones, necesitas obtener una suscripción PAYGO de tu proveedor de cloud o comprar una licencia BYOL de NetApp.

Puedes comprar una licencia o suscribirte en cualquier momento y no se te cobrará hasta que termine el periodo de prueba de 30 días.

La recuperación ante desastres admite las siguientes topologías:

Para consultar la lista completa, visita "Requisitos previos para la recuperación ante desastres".

Un agente de Console es un componente de software que permite que la NetApp Console se comunique con tu almacenamiento ONTAP y tus clústeres de VMware vCenter. Es necesario para que NetApp Disaster Recovery funcione correctamente. El agente reside en tu red privada (ya sea un centro de datos local o una VPC en la nube) y se comunica con tus instancias de almacenamiento ONTAP y tus clústeres de vCenter.

Para la recuperación ante desastres de entorno local a entorno local, instala el agente de la Console para entorno local en el sitio de recuperación ante desastres. Para la recuperación ante desastres de entorno local a AWS, instala el agente de la Console para AWS en tu VPC de AWS. Tanto el clúster de origen como el de destino de vCenter deben usar el mismo agente de la Console. La recuperación ante desastres solo funciona con la implementación del agente en modo estándar.

Cada clúster de Kubernetes debe tener instalado Trident de NetApp, un backend ONTAP y una clase de almacenamiento configurados, así como los CRD de instantáneas de volumen y el controlador instalados. Las aplicaciones deben usar volúmenes persistentes aprovisionados a través de la clase de almacenamiento de Trident. Cuando añades un clúster de Kubernetes como sitio, Disaster Recovery te guía para instalar y registrar Trident Protect en ese clúster. Consulta "Requisitos del clúster de Kubernetes para la recuperación ante desastres" para ver los comandos paso a paso y las comprobaciones de verificación.

Un sitio es un contenedor lógico, normalmente asociado a un centro de datos físico o a una ubicación en la nube, que aloja uno o varios clústeres de vCenter o de Kubernetes. Debes añadir tanto un sitio de origen (producción) como un sitio de destino (recuperación ante desastres) antes de crear un plan de replicación.

Un grupo de recursos es un contenedor lógico que te permite gestionar varias máquinas virtuales, almacenes de datos o espacios de nombres y recursos de Kubernetes como una sola unidad, para que puedan protegerse con una instantánea común. Una máquina virtual solo puede pertenecer a un grupo de recursos a la vez. Puedes crear un grupo de recursos para cada aplicación o carga de trabajo que quieras proteger, y las máquinas virtuales se encienden según el orden de arranque que configures dentro del grupo.

Un plan de replicación es un conjunto de reglas que establecen la frecuencia con la que se realizan las copias de seguridad y cómo gestionar los eventos de conmutación por error. Selecciona los sitios de origen y destino, asigna grupos de recursos, define las asignaciones de recuperación y configura el comportamiento al encender el sistema. Los planes definen el punto de recuperación (RPO) a través de la frecuencia de la replicación de datos.

El objetivo de punto de recuperación (RPO) es la cantidad máxima de pérdida de datos que se considera aceptable en caso de desastre; está definido por la frecuencia o el calendario de replicación del plan de replicación. El objetivo de tiempo de recuperación (RTO) es el tiempo máximo aceptable para recuperarse de un desastre; depende de cuánto tiempo se tarda en conmutar al sitio de recuperación ante desastres y reiniciar todas las máquinas virtuales o aplicaciones.

Para conocer los pasos a seguir, consulta "Agrega sitios en NetApp Disaster Recovery".

Por defecto, el proceso de descubrimiento se ejecuta cada 24 horas; puedes personalizar la programación para adaptarla a tu entorno. El intervalo mínimo es de 30 minutos y el máximo es de 24 horas. NetApp recomienda realizar primero algunos descubrimientos manuales para obtener información actualizada y luego configurar la programación para que se ejecute automáticamente. Los recursos recién añadidos o eliminados se reconocen en el siguiente descubrimiento programado o manual.

No. Alojar máquinas virtuales protegidas y sin proteger en el mismo almacén de datos puede causar problemas. Concretamente, si se produce una conmutación por error del almacén de datos, las máquinas virtuales sin proteger que se encuentren en él dejarán de existir en el origen tras la conmutación, y NetApp Disaster Recovery no las iniciará en el sitio de conmutación.

Debes organizar los recursos antes de implementar NetApp Disaster Recovery, de modo que las cargas de trabajo protegidas y las no protegidas utilicen subconjuntos distintos de almacenes de datos, y asegurarte de que un mismo almacén de datos no esté protegido por más de un plan de replicación.

Si tienes previsto utilizar copias de seguridad gestionadas por la plataforma (gestionadas por ONTAP), utiliza la política MirrorAll. MirrorVault y Asynchronous son alternativas válidas, pero debes asegurarte de que la instantánea seleccionada durante la conmutación por error o la conmutación de retorno exista tanto en el volumen de origen como en el de destino, o la operación fallará con el error "no se ha encontrado ninguna instantánea común". MirrorLatest no se recomienda porque deja solo una instantánea común para la conmutación por error. Para las relaciones de SnapMirror que gestiona Disaster Recovery, no programes actualizaciones para ellas fuera del servicio, ya que Disaster Recovery gestiona la sincronización de la replicación.

Sí. Si ya existe una relación SnapMirror entre los volúmenes de origen y destino de un datastore protegido, Disaster Recovery usa esa relación para todas las operaciones de replicación en lugar de crear una nueva.

Sí. Puedes migrar aplicaciones de VMware desde un sitio de origen a otro utilizando un plan de replicación configurado para la migración. Después de iniciar la migración, el servicio verifica cada 30 minutos que la migración avanza según lo planeado; puedes supervisar el progreso en la supervisión de trabajos. Actualmente, la migración no es compatible con cargas de trabajo basadas en Kubernetes. Consulta "Migrar aplicaciones a otro sitio".

Sí. Durante una conmutación por error de prueba, NetApp Disaster Recovery crea máquinas virtuales temporales a partir de un nuevo volumen de FlexClone de la instantánea seleccionada y asigna un almacén de datos temporal respaldado por FlexClone a los hosts ESXi. Esto no consume capacidad física adicional, no modifica el volumen de origen original y no interrumpe la relación de SnapMirror ni las cargas de trabajo de producción, que siguen replicándose normalmente. Después de la prueba, limpia el entorno de prueba usando la acción Clean up failover test. Consulta "Conmutar por error las aplicaciones a un sitio remoto".

Sí. Por defecto, todas las máquinas virtuales se inician al mismo tiempo en paralelo, pero puedes asignar a cada máquina virtual un número secuencial (por ejemplo, 1, 2, 3) para controlar el orden de inicio, o asignar el mismo número a varias máquinas virtuales para que se inicien simultáneamente. También puedes establecer un retraso de arranque (0–10 minutos) por máquina virtual para escalonar el inicio, lo cual es útil para asegurarte de que las máquinas virtuales prioritarias estén en funcionamiento antes de que se inicien las de menor prioridad.

La recuperación automática (failback) devuelve las operaciones al sitio de origen original una vez que se ha resuelto un desastre. Partiendo de una relación que se ha desviado al destino, NetApp Disaster Recovery vuelve a sincronizar cualquier cambio en la máquina virtual (VM) o el clúster de Kubernetes de origen antes de invertir la dirección de la replicación. El proceso:

Consulta "Recupera las aplicaciones en el origen original".

Utiliza el panel de control de recuperación ante desastres para comprobar si los sitios y los planes están en buen estado, desconectados o con un rendimiento reducido; revisar las advertencias recientes y las tareas fallidas; identificar las cargas de trabajo protegidas y las que no lo están; y ver la capacidad de un vistazo. Consulta "Ver el estado del plan de recuperación ante desastres".

Utiliza Job monitoring para consultar las marcas de tiempo, el estado y el iniciador de una tarea (o "system" si Disaster Recovery la inició). Puedes cancelar una tarea que esté "In progress" o "Queued" desde su menú de acciones, lo cual es útil si una tarea se queda atascada o necesitas priorizar otra operación. Consulta "Supervisa los trabajos de recuperación ante desastres".

Puedes generar informes centrados en VMware, Kubernetes o todas las cargas de trabajo, que incluyen detalles del plan de replicación, el estado de cumplimiento y resúmenes de tareas. Los informes se pueden descargar como archivos PDF, HTML o JSON. Abarcan un periodo de tiempo de entre uno y siete días. Para obtener más información, consulta "Crear informes en Disaster Recovery".

Un AppVault es el destino de almacenamiento en la nube donde Trident Protect guarda los datos de protección de Kubernetes. Tú creas un AppVault mientras configuras un plan de replicación de Kubernetes.