Configuración de replicación de datos basada en host con el software Availability Suite

En este apéndice, se proporciona una replicación alternativa basada en host que no utiliza Oracle Solaris Cluster Cluster Geographic Edition. Oracle recomienda el uso de Oracle Solaris Cluster Geographic Edition para la replicación basada en host con el fin de simplificar la configuración y el funcionamiento de la replicación basada en host entre clusters. Consulte Comprensión de la replicación de datos.

En el ejemplo de este apéndice, se muestra cómo configurar la replicación de datos basada en host entre clusters con el software Función Availability Suite de Oracle Solaris. El ejemplo muestra una configuración de clúster completa para una aplicación NFS que proporciona información detallada sobre cómo realizar tareas individuales. Todas las tareas deben llevarse a cabo en el cluster global. El ejemplo no incluye todos los pasos necesarios para otras aplicaciones ni las configuraciones de otros clústeres.

Si utiliza el control de acceso basado en roles (RBAC) para acceder a los nodos del cluster, asegúrese de poder asumir un rol de RBAC que proporcione autorización para todos los comandos de Oracle Solaris Cluster. Esta serie de replicación de datos necesita las siguientes autorizaciones RBAC de Oracle Solaris Cluster:

• solaris.cluster.modify

• solaris.cluster.admin

• solaris.cluster.read

Consulte Administración de Oracle Solaris 11.1: servicios de seguridad para obtener más información sobre cómo usar roles de RBAC. Consulte las páginas del comando man de Oracle Solaris Cluster para saber la autorización RBAC que requiere cada subcomando de Oracle Solaris Cluster.

Comprensión del software Availability Suite en un clúster

Esta sección presenta la tolerancia ante problemas graves y describe los métodos de replicación de datos que utiliza el software Availability Suite.

La tolerancia a desastres es la capacidad de restaurar una aplicación en un clúster alternativo cuando el clúster principal falla. La tolerancia a desastres se basa en la replicación de datos y la recuperación. Una recuperación reubica un servicio de aplicaciones en un clúster secundario estableciendo en línea uno o más grupos de recursos y grupos de dispositivos.

Si los datos se replican de manera síncrona entre el clúster principal y el secundario, no se pierde ningún dato comprometido cuando el sitio principal falla. Sin embargo, si los datos se replican de manera asíncrona, es posible que algunos datos no se repliquen en el clúster secundario antes del fallo del sitio principal y, por lo tanto, se pierdan.

Métodos de replicación de datos utilizados por Availability Suite

Esta sección describe los métodos de replicación por duplicación remota y de instantánea de un momento determinado utilizados por Availability Suite. Este software utiliza los comandos sndradm e iiadm para replicar datos. Para obtener más información, consulte las páginas del comando man sndradm(1M) and iiadm(1M).

Replicación de reflejo remoto

La replicación por duplicación remota se ilustra en la Figura A-1. Los datos del volumen maestro del disco primario se duplican en el volumen maestro del disco secundario mediante una conexión TCP/IP. Un mapa de bits de duplicación remota controla las diferencias entre el volumen maestro del disco primario y el del secundario.

Figura A-1 Replicación de reflejo remoto

La replicación por duplicación remota se puede efectuar de manera sincrónica en tiempo real o de manera asincrónica. Cada volumen definido en cada clúster se puede configurar de manera individual, para replicación sincrónica o asincrónica.

• En la replicación sincrónica de datos, no se confirma la finalización de la operación de escritura hasta que el volumen remoto se haya actualizado.

• En la replicación asincrónica de datos, se confirma la finalización de la operación de escritura antes de que se actualice el volumen remoto. La replicación asincrónica de datos proporciona una mayor flexibilidad en largas distancias y poco ancho de banda.

Instantánea puntual

La Figura A-2 muestra una instantánea puntual. Los datos del volumen primario de cada disco se copian en el volumen sombra del mismo disco. El mapa de bits instantáneo controla y detecta las diferencias entre el volumen primario y el volumen sombra. Cuando los datos se copian en el volumen sombra, el mapa de bits de un momento determinado se vuelve a configurar.

Figura A-2 Instantánea puntual

Replicación en la configuración de ejemplo

La Figura A-3 ilustra la forma en que se usan la replicación por duplicación remota y la instantánea de un momento determinado en este ejemplo de configuración.

Figura A-3 Replicación en la configuración de ejemplo

Directrices para la configuración de replicación de datos basada en host entre clústeres

Esta sección proporciona directrices para la configuración de replicación de datos entre clústeres. Asimismo, se proporcionan consejos para configurar los grupos de recursos de replicaciones y los de recursos de aplicaciones. Use estas directrices cuando esté configurando la replicación de datos en el clúster.

En esta sección se analizan los aspectos siguientes:

• Configuración de grupos de recursos de replicaciones

• Configuración de grupos de recursos de aplicaciones

  • Configuración de grupos de recursos en una aplicación de migración tras error

  • Configuración de grupos de recursos en una aplicación escalable

• Directrices para la gestión de una recuperación

Configuración de grupos de recursos de replicaciones

Los grupos de recursos de replicaciones sitúan el grupo de dispositivos bajo el control del software Availability Suite con un recurso de nombre de host lógico. Debe existir un nombre de host lógico en cada extremo del flujo de replicación de datos y debe encontrarse en el mismo nodo del clúster que actúa como la ruta de E/S principal para el dispositivo. Un grupo de recursos de replicaciones debe tener las características siguientes:

• Ser un grupo de recursos de migración tras error.

  Un recurso de migración tras error sólo puede ejecutarse en un nodo a la vez. Cuando se produce la migración tras error, los recursos de recuperación participan en ella.

• Debe tener un recurso de nombre de host lógico.

  Un nombre de host lógico se aloja en un nodo de cada cluster (principal y secundario) y se utiliza para proporcionar direcciones de origen y destino para el flujo de replicación de datos del software Availability Suite.

• Debe tener un recurso de HAStoragePlus.

  El recurso de HAStoragePlus fuerza la migración tras error del grupo de dispositivos si el grupo de recursos de replicaciones se conmuta o migra tras error. Oracle Solaris Cluster también fuerza la migración tras error del grupo de recursos de replicaciones si el grupo de dispositivos se conmuta. De este modo, es siempre el mismo nodo el que sitúa o controla el grupo de recursos de replicaciones y el de dispositivos.

  Las propiedades de extensión siguientes se deben definir en el recurso de HAStoragePlus:

  • GlobalDevicePaths. La propiedad de esta extensión define el grupo de dispositivos al que pertenece un volumen.

  • AffinityOn property = True. La propiedad de esta extensión provoca que el grupo de dispositivos se conmute o migre tras error si el grupo de recursos de replicaciones también lo hace. Esta función se denomina conmutación de afinidad.

  Para obtener más información sobre HAStoragePlus, consulte la página del comando man SUNW.HAStoragePlus(5).

• Recibir el nombre del grupo de dispositivos con el que se coloca, seguido de -stor-rg

  Por ejemplo, devgrp-stor-rg.

• Estar en línea en el clúster primario y en el secundario

Configuración de grupos de recursos de aplicaciones

Para que esté totalmente disponible, una aplicación se debe administrar como un recurso en un grupo de recursos de aplicaciones. Un grupo de recursos de aplicaciones se puede configurar en una aplicación de migración tras error o en una aplicación escalable.

La propiedad de extensión ZPoolsSearchDir se debe definir en el recurso HAStoragePlus. Esta propiedad de extensión es necesaria para utilizar el sistema de archivos ZFS.

Los recursos de aplicaciones y los grupos de recursos de aplicaciones configurados en el clúster primario también se deben configurar en el clúster secundario. Asimismo, se deben replicar en el clúster secundario los datos a los que tiene acceso el recurso de aplicaciones.

Esta sección proporciona directrices para la configuración de grupos de recursos de aplicaciones siguientes:

• Configuración de grupos de recursos en una aplicación de migración tras error

• Configuración de grupos de recursos en una aplicación escalable

Configuración de grupos de recursos en una aplicación de migración tras error

En una aplicación de migración tras error, una aplicación se ejecuta en un solo nodo a la vez. Si éste falla, la aplicación migra a otro nodo del mismo clúster. Un grupo de recursos de una aplicación de migración tras error debe tener las características siguientes:

• Debe tener un recurso de HAStoragePlus para aplicar la conmutación por error del sistema de archivos o zpool cuando el grupo de recursos de aplicaciones se conmuta.

  El grupo de dispositivos se coloca con el grupo de recursos de replicaciones y el grupo de recursos de aplicaciones. Por este motivo, la migración tras error del grupo de recursos de aplicaciones fuerza la migración de los grupos de dispositivos y de recursos de replicaciones. El mismo nodo controla los grupos de recursos de aplicaciones y de recursos de replicaciones, y el grupo de dispositivos.

  Sin embargo, que una migración tras error del grupo de dispositivos o del grupo de recursos de replicaciones no desencadena una migración tras error en el grupo de recursos de aplicaciones.

  • Si los datos de la aplicación están montados de manera global, la presencia de un recurso de HAStoragePlus en el grupo de recursos de aplicaciones no es obligatoria, aunque sí aconsejable.

  • Si los datos de la aplicación se montan de manera local, la presencia de un recurso de HAStoragePlus en el grupo de recursos de aplicaciones es obligatoria.

  Para obtener más información sobre HAStoragePlus, consulte la página del comando man SUNW.HAStoragePlus(5).

• Debe estar en línea en el clúster principal y sin conexión en el clúster secundario.

  El grupo de recursos de aplicaciones debe estar en línea en el clúster secundario cuando éste hace las funciones de clúster primario.

La Figura A-4 ilustra la configuración de grupos de recursos de aplicaciones y de recursos de replicaciones en una aplicación de migración tras error.

Figura A-4 Configuración de grupos de recursos en una aplicación de migración tras error

Configuración de grupos de recursos en una aplicación escalable

En una aplicación escalable, una aplicación se ejecuta en varios nodos con el fin de crear un único servicio lógico. Si se produce un error en un nodo que ejecuta una aplicación escalable, no habrá migración tras error. La aplicación continúa ejecutándose en los otros nodos.

Cuando una aplicación escalable se administra como recurso en un grupo de recursos de aplicaciones, no es necesario acoplar el grupo de recursos de aplicaciones con el grupo de dispositivos. Por este motivo, no es necesario crear un recurso de HAStoragePlus para el grupo de recursos de aplicaciones.

Un grupo de recursos de una aplicación escalable debe tener las características siguientes:

• Tener una dependencia en el grupo de recursos de direcciones compartidas.

  Los nodos que ejecutan la aplicación escalable utilizan la dirección compartida para distribuir datos entrantes.

• Estar en línea en el clúster primario y fuera de línea en el secundario.

La Figura A-5 ilustra la configuración de grupos de recursos en una aplicación escalable.

Figura A-5 Configuración de grupos de recursos en una aplicación escalable

Directrices para la gestión de una recuperación

Si el clúster principal falla, la aplicación se debe conmutar al clúster secundario lo antes posible. Para que el clúster secundario pueda realizar las funciones del principal, se debe actualizar el DNS.

Los clientes usan el DNS para asignar el nombre de host lógico de una aplicación a una dirección IP. Después de una recuperación, donde la aplicación se mueve a un clúster secundario, la información del DNS debe actualizarse para reflejar la asignación entre el nombre de host lógico de la aplicación y la dirección IP nueva.

Figura A-6 Asignación del DNS de un cliente a un clúster

Si desea actualizar el DNS, utilice el comando nsupdate. Para obtener más información, consulte la página del comando man nsupdate(1M). Por ver un ejemplo de cómo gestionar una recuperación, consulte Ejemplo de cómo gestionar una recuperación.

Después de la reparación, el clúster principal se puede volver a colocar en línea. Para volver al clúster primario original, siga estos pasos:

1. Sincronice el clúster primario con el secundario para asegurarse de que el volumen principal esté actualizado. Puede hacerlo deteniendo el grupo de recursos en el nodo secundario, de modo que el flujo de datos de replicación pueda drenar.

2. Revierta la dirección de la replicación de datos, de modo que el nodo principal original esté ahora, otra vez, replicando los datos en el nodo secundario original.

3. Inicie el grupo de recursos en el clúster principal.

4. Actualice el DNS de modo que los clientes tengan acceso a la aplicación en el clúster primario.

Mapa de tareas: ejemplo de configuración de una replicación de datos

La Tabla A-1 enumera las tareas de este ejemplo de configuración de replicación de datos para una aplicación de NFS mediante el software Availability Suite.

Tabla A-1 Mapa de tareas: ejemplo de configuración de una replicación de datos

Conexión e instalación de clústeres

La Figura A-7 ilustra la configuración de clústeres utilizada en la configuración de ejemplo. El clúster secundario de la configuración de ejemplo contiene un nodo, pero se pueden usar otras configuraciones de clúster.

Figura A-7 Ejemplo de configuración de clúster

La Tabla A-2 resume el hardware y el software necesarios para la configuración de ejemplo. El sistema operativo Oracle Solaris, el software Oracle Solaris Cluster y el software Volume Manager deben instalarse en los nodos del clúster antes de instalar las actualizaciones del software y el software Availability Suite.

Tabla A-2 Hardware y software necesarios

Ejemplo de configuración de grupos de dispositivos y de recursos

Esta sección describe cómo se configuran los grupos de dispositivos y los de recursos en una aplicación NFS. Para obtener más información, consulte Configuración de grupos de recursos de replicaciones y Configuración de grupos de recursos de aplicaciones.

Esta sección incluye los procedimientos siguientes:

• Configuración de un grupo de dispositivos en el clúster primario

• Configuración de un grupo de dispositivos en el clúster secundario

• Configuración de sistemas de archivos en el clúster primario para la aplicación NFS

• Configuración del sistema de archivos en el clúster secundario para la aplicación NFS

• Creación de un grupo de recursos de replicaciones en el clúster primario

• Creación de un grupo de recursos de replicaciones en el clúster secundario

• Creación de un grupo de recursos de aplicaciones NFS en el clúster primario

• Creación de un grupo de recursos de aplicaciones NFS en el clúster secundario

• Procedimiento para comprobar la configuración de la replicación

La tabla siguiente enumera los nombres de los grupos y recursos creados para la configuración de ejemplo.

Tabla A-3 Resumen de los grupos y de los recursos en la configuración de ejemplo

Con la excepción de devgrp-stor-rg, los nombres de los grupos y recursos son nombres de ejemplos que se pueden cambiar cuando sea necesario. El grupo de recursos de replicaciones debe tener un nombre con el formato nombre_grupo_dispositivos -stor-rg.

Para obtener información sobre el software Solaris Volume Manager, consulte el Capítulo 4, Configuración del software de Solaris Volume Manager de Guía de instalación del software de Oracle Solaris Cluster.