Omitir Vínculos de navegación | |
Salir de la Vista de impresión | |
![]() |
Guía de administración de Oracle® ZFS Storage Appliance |
Capítulo 1 Descripción general de Oracle ZFS Storage Appliance
Capítulo 3 Configuración inicial
Capítulo 4 Configuración de red
Capítulo 5 Configuración del almacenamiento
Capítulo 6 Configuración de red de área de almacenamiento
Capítulo 7 Configuración de usuario
Capítulo 8 Configuración de preferencias de dispositivos ZFSSA
Capítulo 9 Configuración de alertas
Capítulo 10 Configuración de cluster
Capítulo 11 Servicios del dispositivo ZFSSA
Capítulo 12 Recursos compartidos, proyectos y esquemas
Descripción general de la replicación
Destinos de replicación de proyecto
Acciones y paquetes de replicación de proyectos
Agrupaciones de almacenamiento de replicación de proyectos
Replicación de nivel de proyecto frente a replicación de nivel de recurso compartido
Configuración de replicación de proyectos
Creación y edición de destinos
Creación y edición de destinos en la BUI
Creación y edición de destinos en la CLI
Creación y edición de acciones
Creación y edición de acciones en la BUI
Creación y edición de acciones en la CLI
Modos de replicación: programados o continuos
Replicación: inclusión de las instantáneas intermedias
Replicación: envío y cancelación de actualizaciones
Gestión de paquetes de replicación
Gestión de paquetes de replicación en la BUI
Gestión de paquetes de replicación en la CLI
Cancelación de actualizaciones de replicación
Clonación de un paquete o recursos compartidos individuales
Exportación de sistemas de archivos replicados
Destrucción de un paquete de replicación
Reversión de la replicación: establecimiento de la replicación
Reversión de la replicación: simulación de la recuperación ante desastres
Reversión de la replicación: reanudación de la replicación desde el sistema de producción
Uso forzoso de una ruta estática al replicar
Uso forzoso de una ruta estática al replicar
Clonación de un proyecto de replicación recibido
Detalles de la replicación remota
Eventos de auditoría de replicación
Replicación y agrupación en clusters
Instantáneas y coherencia de datos
Replicación de la configuración de iSCSI
Actualización de la versión 2009.Q3 y versiones anteriores
Capítulo 15 Secuencias de comandos de la CLI
Se puede invertir la dirección de la replicación para admitir los planes típicos de recuperación ante desastres de dos sistemas. Esta operación es similar a la operación de corte descrita anteriormente, pero, además, configura una acción de replicación en el nuevo proyecto local para realizar una replicación incremental en el sistema de origen. No se efectúan cambios en el sistema de origen cuando se completa esta operación, sino que el primer intento de actualización con esta acción convertirá el proyecto original del sistema de origen en un paquete de replicación y revertirá los cambios efectuados desde la última actualización de replicación exitosa de ese sistema.
Esta función no redirige automáticamente cargas de trabajo de producción ni direcciones IP de failover, ni realiza otras actividades relacionadas con el failover de la recuperación ante desastres, aparte de modificar el estado de lectura y escritura de las copias de datos principales y secundarios.
Como parte de la conversión del proyecto de origen original en un paquete de replicación en el sistema de origen original (que ahora funciona como destino), los recursos compartidos que se replicaron como parte de la acción o el paquete que actualmente se está revirtiendo se trasladan a un nuevo paquete de replicación y no se exportan. El proyecto original permanece en la recopilación local, pero podría terminar vacío si la acción o el paquete incluyeran todos los recursos compartidos. Cuando se revierte la replicación de nivel de recurso compartido, todos los demás recursos compartidos del proyecto original no se modifican.
Después de establecer la replicación de nivel de recurso compartido de un dispositivo ZFSSA a otro, la reversión de esa replicación en el dispositivo ZFSSA de destino destruye el cronograma de replicación. Luego, se crea una acción de replicación en el nivel de proyecto, que contiene el dispositivo ZFSSA de destino correcto sin un cronograma.
Como mencionamos anteriormente, esta característica generalmente se utiliza para implementar una configuración de recuperación ante desastres de dos sistemas, en la cual un sistema principal proporciona datos de producción y los replica a un sistema secundario o DR (por lo general, en otro centro de datos) en espera para tomar el control del tráfico de producción en caso de que se produzca un desastre en el sitio principal. Si se produce un desastre en el sitio principal, la copia del sitio secundario se debe convertir en "principal" y, para ello, se debe convertir en modificable y el tráfico de producción se debe redirigir al sitio secundario. Cuando se repara el sitio principal, los cambios acumulados en el sitio secundario se pueden replicar nuevamente en el sitio principal y ese sitio puede reanudar el mantenimiento de la carga de trabajo de producción.
A continuación, se describe una secuencia típica de eventos con ese plan:
El sistema principal abastece la carga de trabajo de producción y se ocupa de la replicación al sistema secundario.
Se produce un desastre, que posiblemente representa una falla total del sistema en el sitio principal. Los administradores revierten la dirección de la replicación en el sitio secundario; para ello, exportan los recursos compartidos replicados de un nuevo proyecto configurado para realizar la replicación nuevamente en el sitio principal cuando se restaure dicho servicio principal. Mientras tanto, la carga de trabajo de producción se redirige al sitio secundario.
Cuando el sitio principal vuelve a estar en línea, el administrador inicia una actualización de replicación desde el sitio secundario hacia el sitio principal. Esto permite convertir la copia del sitio principal en un paquete de replicación, lo cual revierte los cambios realizados desde la última actualización exitosa del destino (antes de la falla). Cuando la copia del sitio principal está actualizada, la dirección de la replicación se revierte nuevamente, lo que convierte la copia del sitio principal en modificable. El tráfico de producción se redirige nuevamente al sitio principal. Se reanuda la replicación del sitio principal al secundario, lo cual restaura la relación inicial entre las copias principal y secundaria.
Para revertir la dirección de la replicación de un paquete, se recomienda a los administradores que, antes de hacerlo, detengan la replicación de ese proyecto desde el origen. Si hay una actualización de replicación en curso cuando el administrador revierte la dirección de la replicación de un proyecto, los administradores no podrán saber qué instantánea de replicación coherente se utilizó para crear el proyecto resultante en el dispositivo ZFSSA de destino anterior (que ahora es el dispositivo ZFSSA de origen).
Para revertir la replicación desde la BUI, se debe navegar hasta el paquete de replicación (ver más arriba) y, a continuación, hacer clic en la ficha Replication (Replicación) y en el botón
. El cuadro de diálogo que aparece permite que el administrador especifique el nombre del nuevo proyecto local.
Para revertir la replicación desde la CLI, se debe navegar hasta el paquete de replicación (ver más arriba) y, a continuación, utilizar el comando reverse. Este comando toma un argumento opcional que especifica el nombre del nuevo proyecto local. Si no se especifica ningún argumento, se utiliza el nombre original.
Dado que se exportan todos los recursos compartidos locales, todos los recursos compartidos del paquete se exportan cuando se revierte el paquete, independientemente de que se hayan exportado previamente (ver más arriba). Si existen conflictos de punto de montaje entre los sistemas de archivos replicados y otros sistemas de archivos del sistema, se producirá un error en la operación de reversión. Estos conflictos se deben resolver antes de realizar el corte mediante la reconfiguración los puntos de montaje de los recursos compartidos correspondientes. Dado que esta operación, generalmente, forma parte de la ruta crítica de restauración del servicio de producción, se recomienda resolver estos conflictos de punto de montaje cuando los sistemas se configuran por primera vez, en lugar de hacerlo en el momento en que se produce el failover de la recuperación ante desastres.