Uso de replicación de datos basada en almacenamiento dentro de un clúster

La replicación de datos basada en almacenamiento usa un software instalado en el dispositivo de almacenamiento para administrar la replicación dentro de un clúster o un clúster de campus. Dicho software es específico del dispositivo de almacenamiento particular y no se utiliza para recuperación en caso de un problema grave. Consulte la documentación suministrada con el dispositivo de almacenamiento al configurar la replicación de datos basada en almacenamiento.

En función del software que use, puede utilizar la migración tras error automática o manual con la replicación de datos basada en almacenamiento. Oracle Solaris Cluster admite la migración tras error automática o manual de los replicadores con Hitachi TrueCopy, Hitachi Universal Replicator y EMC SRDF.

Esta sección describe la replicación de datos basada en almacenamiento que se usa en un clúster de campus. La Figura 4-1 muestra un ejemplo de configuración de dos salas donde los datos se replican entre dos matrices de almacenamiento. En esta configuración, la matriz de almacenamiento principal se encuentra en la primera sala, donde proporciona datos a los nodos de ambas salas. Esta matriz de almacenamiento principal también proporciona la matriz secundaria con datos para replicar.

Figura 4-1 Configuración de dos salas con replicación de datos basada en almacenamiento

Se puede llevar a cabo una replicación de datos basada en almacenamiento con Hitachi TrueCopy o Hitachi Universal Replicator de forma sincrónica o asincrónica en el entorno de Oracle Solaris Cluster, según el tipo de aplicación que utilice. Si desea efectuar una migración tras error automática en un clúster de campus, use TrueCopy de forma sincrónica. La repetición síncrona basada en almacenamiento con SRDF de EMC es compatible con Oracle Solaris Cluster; la repetición asíncrona no se admite para SRDF de EMC.

No use los modos Domino ni Adaptive Copy de EMC SRDF. El modo Domino hace que los volúmenes de SRDF locales y de destino no estén disponibles para el sistema cuando el destino no esté disponible. El modo Adaptive Copy se suele usar para migrar datos y desplazar centros de datos, pero no se recomienda para la recuperación de datos en caso de problema grave.

Si se pierde el contacto con el dispositivo de almacenamiento remoto, asegúrese de que una aplicación que se está ejecutando en el clúster principal no esté bloqueada especificando un fence_level de never o async. Si especifica un Fence_level de data o status, el dispositivo de almacenamiento principal rechaza las actualizaciones si éstas no pueden copiarse en el dispositivo de almacenamiento remoto.

Requisitos y restricciones al usar replicación de datos basada en almacenamiento dentro de un clúster

Para asegurar la integridad de los datos, use múltiples rutas y el paquete adecuado de RAID. La lista siguiente incluye consideraciones sobre cómo implementar una configuración de clúster que utilice replicación de datos basada en almacenamiento.

• La distancia entre nodo y nodo está limitada por el canal de fibra de Oracle Solaris Cluster y la infraestructura de interconexión. Póngase en contacto con el proveedor de servicios de Oracle para obtener más información sobre las limitaciones actuales y las tecnologías admitidas.

• No configure un volumen replicado como dispositivo de quórum. Localice los dispositivos de quórum en un volumen compartido con replicación anulada o utilice un servidor de quórum.

• Compruebe que sólo la copia primaria de los datos esté visible para los nodos del clúster. De lo contrario, el administrador de volúmenes podría intentar acceder simultáneamente a las copias primaria y secundaria de los datos. Consulte la documentación suministrada con la matriz de almacenamiento para obtener información sobre el control de la visibilidad de las copias de datos.

• EMC SRDF, Hitachi TrueCopy e Hitachi Universal Replicator permiten que el usuario defina los grupos de dispositivos replicados. Todos los grupos de dispositivos de replicación requieren un grupo de dispositivos de Oracle Solaris Cluster con el mismo nombre.

• Los datos particulares específicos de una aplicación podrían no ser adecuados para una replicación de datos asincrónica. Según sus conocimientos sobre el comportamiento de la aplicación, determine la mejor forma de replicar los datos específicos de la aplicación en los dispositivos de almacenamiento.

• Si quiere configurar el clúster para que realice automáticamente migraciones tras error, use la replicación sincrónica.

  Para obtener instrucciones sobre cómo configurar el clúster para que realice migraciones tras error automáticas de los volúmenes replicados, consulte Administración de dispositivos replicados basados en almacenamiento.

• Oracle Real Application Clusters (RAC) no es compatible con SRDF, Hitachi TrueCopy ni Hitachi Universal Replicator cuando se replica dentro de un clúster. Los nodos conectados a réplicas que no sean la réplica primaria no tendrán acceso de escritura. Cualquier aplicación escalable que requiera acceso de escritura directo desde todos los nodos del clúster no puede ser compatible con dispositivos replicados.

• Veritas Cluster Volume Manager (CVM) y Solaris Volume Manager multipropietario no son compatibles con Oracle Solaris Cluster.

• No use los modos Domino o Adaptive Copy de EMC SRDF. Consulte Uso de replicación de datos basada en almacenamiento dentro de un clúster para obtener más información.

• No use los modos Data ni Status en Hitachi TrueCopy ni Hitachi Universal Replicator. Consulte Uso de replicación de datos basada en almacenamiento dentro de un clúster para obtener más información.

Problemas de recuperación manual al usar una replicación de datos basada en almacenamiento dentro de un clúster

Como sucede en todos los clústers de campus, los que utilizan replicación de datos basada en almacenamiento no suelen necesitar intervención cuando tienen un solo error. Sin embargo, si se usa migración tras error manual y se pierde el espacio que aloja el dispositivo de almacenamiento principal (como se muestra en la Figura 4-1), los problemas surgen en un nodo de dos clústers. El nodo que queda no puede reservar el dispositivo de quórum y no se puede arrancar como miembro del clúster. En este caso, el clúster requiere la intervención manual siguiente:

1. El proveedor de servicios de Oracle debe volver a configurar el nodo restante para que inicie como miembro del clúster.

2. El proveedor de servicios de Oracle debe configurar un volumen con replicación anulada del dispositivo de almacenamiento secundario como dispositivo de quórum.

3. El proveedor de servicios de Oracle debe configurar el nodo restante para que use el dispositivo de almacenamiento secundario como almacenamiento principal. Esta reconfiguración podría suponer la reconstrucción de volúmenes del administrador de volúmenes, la restauración de datos o el cambio de las asociaciones de aplicación con volúmenes de almacenamiento.

Prácticas recomendadas al usar la replicación de datos basada en almacenamiento

Cuando configure los grupos de dispositivos que usan Hitachi TrueCopy o Hitachi Universal Replicator para la replicación de datos basada en almacenamiento, siga estas prácticas:

• Utilice una replicación sincrónica para evitar la posibilidad de perder datos si falla la ubicación principal.

• Debe haber una relación unívoca entre el grupo de dispositivos globales de Oracle Solaris Cluster y el grupo de replicaciones de TrueCopy definidos en el archivo de configuración horcm. De este modo, los dos grupos se mueven de un nodo a otro como una sola unidad.

• Los volúmenes de sistema de archivos globales y los del sistema de archivos de migración tras error no se pueden mezclar en el mismo grupo de dispositivos replicados porque se controlan de forma distinta. Los sistemas de archivos globales están controlados por un sistema de configuración de dispositivos , mientras que los volúmenes de sistemas de archivos de migración tras error lo están por HAS+. El primario de cada uno podría ser un nodo diferente, lo que podría provocar conflictos sobre el nodo en el que debería estar la replicación primaria.

• Todas las instancias de RAID Manager deben estar siempre activadas y en funcionamiento.

Cuando utilice el software EMC SRDF para replicación de datos basada en almacenamiento, use dispositivos dinámicos en lugar de estáticos. Los dispositivos estáticos necesitan varios minutos para cambiar el nodo primario de replicación y pueden afectar al tiempo de migración tras error.