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

Este es una alternativa a la replicación 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.

El ejemplo de este apéndice muestra cómo configurar una replicación de datos basada en host entre clusters con el software de Sun StorageTek Availability Suite 4.0. El ejemplo muestra una configuración de cluster 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 nodo de votación de cluster global. El ejemplo no incluye todos los pasos necesarios para otras aplicaciones ni las configuraciones de otros clusters.

Si utiliza el control de acceso basado en funciones (RBAC) en lugar de ser superusuario para acceder a los nodos del cluster, asegúrese de poder asumir una función de RBAC que proporcione autorización para todos los comandos de Oracle Solaris Cluster. Esta serie de procedimientos de replicación de datos requiere las siguientes autorizaciones de RBAC de Oracle Solaris Cluster si el usuario no es un superusuario:

• solaris.cluster.modify

• solaris.cluster.admin

• solaris.cluster.read

Consulte la System Administration Guide: Security Services para obtener más información sobre el uso de 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.

Descripción del software de Availability Suite en un cluster

En esta sección, se presenta la tolerancia ante problemas graves y se describen los métodos de replicación de datos que utiliza el software de Availability Suite.

La tolerancia a desastres es la capacidad de restaurar una aplicación en un cluster alternativo cuando el cluster 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 cluster 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 cluster 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 cluster secundario antes del fallo del sitio principal y, por lo tanto, se pierdan.

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

En esta sección, se describen los métodos de replicación de reflejo remoto y de instantánea de un momento determinado utilizados por el software de Availability Suite. Este software utiliza los comandos sndradm(1RPC) e iiadm(1II) para replicar datos. Para obtener más información sobre estos comandos, consulte la Availability Suite documentation.

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 cluster 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 instantánea de un momento determinado. 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 clusters

Esta sección proporciona directrices para la configuración de replicación de datos entre clusters. 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 cluster.

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 replicación sitúan al grupo de dispositivos bajo el control del software de Availability Suite con el recurso de nombre de host lógico. 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.

  El nombre de host lógico debe estar alojado por el cluster principal. Después de una conmutación por error, el nombre de host lógico debe estar alojado por el cluster secundario. El sistema DNS se utiliza para asociar el nombre de host lógico con un cluster.

• 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.

  • ZPoolsSearchDir. Esta propiedad de extensión es necesaria para utilizar el sistema de archivos ZFS.

  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 cluster 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.

Los recursos de aplicaciones y los grupos de recursos de aplicaciones configurados en el cluster primario también se deben configurar en el cluster secundario. Asimismo, se deben replicar en el cluster 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 cluster. 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 cluster principal y sin conexión en el cluster secundario.

  El grupo de recursos de aplicaciones debe estar en línea en el cluster secundario cuando éste hace las funciones de cluster 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 cluster 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 cluster principal falla, la aplicación se debe conmutar al cluster secundario lo antes posible. Para que el cluster secundario pueda realizar las funciones del principal, se debe actualizar el DNS.

Los clientes utilizan 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 cluster 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. En la Figura A-6, se muestra cómo el DNS asigna un cliente a un cluster.

Figura A-6 Asignación del DNS de un cliente a un cluster

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 cluster principal se puede volver a colocar en línea. Para volver al cluster primario original, siga estos pasos:

1. Sincronice el cluster 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 cluster principal.

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

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

En la Tabla A-1, se enumeran las tareas de este ejemplo de configuración de replicación de datos para una aplicación NFS mediante el software de Availability Suite.

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

Conexión e instalación de clusters

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

Figura A-7 Ejemplo de configuración de cluster

La Tabla A-2 resume el hardware y el software necesarios para la configuración de ejemplo. El sistema operativo Oracle Solaris, el software de Oracle Solaris Cluster y el software de administrador de volúmenes deben instalarse en los nodos del cluster antes de instalar los parches y el software de 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 cluster primario

• Configuración de un grupo de dispositivos en el cluster secundario

• Configuración de sistemas de archivos en el cluster primario para la aplicación NFS

• Configuración del sistema de archivos en el cluster secundario para la aplicación NFS

• Creación de un grupo de recursos de replicaciones en el cluster primario

• Creación de un grupo de recursos de replicaciones en el cluster secundario

• Creación de un grupo de recursos de aplicaciones NFS en el cluster primario

• Creación de un grupo de recursos de aplicaciones NFS en el cluster 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.

En este ejemplo, la configuración utiliza el software de SVM. Para obtener más información sobre el software de 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.

En la siguiente figura, se muestran los volúmenes que se crean en el grupo de dispositivos.

Figura A-8 Volúmenes para el grupo de dispositivos