Configuración de replicación de datos basada en host con el software Sun StorageTek 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 en un clúster. Consulte Comprensión de la replicación de datos.

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

Si utiliza el control de acceso basado en funciones (RBAC) en lugar de ser superusuario para acceder a los nodos del clúster, 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 System Administration Guide: Security Services para obtener más información sobre el uso de las funciones de RBAC. Consulte las páginas de comando man de Oracle Solaris Cluster para saber la autorización de RBAC que requiere cada subcomando de Oracle Solaris Cluster.

Comprensión del software Sun StorageTek 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 &AvailSuite.

La tolerancia ante problemas graves es la capacidad de un sistema para recuperar una aplicación en un clúster alternativo cuando falla el clúster primario. La tolerancia ante problemas graves se basa en la replicación de datos y la migración tras error. La migración tras error es la reubicación automática de un grupo de recursos o de dispositivos de un clúster primario en un clúster secundario. Si falla el clúster primario, la aplicación y los datos quedan inmediatamente disponibles en el clúster secundario.

Métodos de replicación de datos utilizados por Sun StorageTek 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 Sun StorageTek Availability Suite. Este software utiliza los comandos sndradm(1RPC) e iiadm(1II) para replicar datos.

Replicación por duplicación remota

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 por duplicación remota

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 de un momento determinado

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 de un momento determinado

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ústers

Esta sección proporciona directrices para la configuración de replicación de datos entre clústers. 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 administrar migraciones tras error

Configuración de grupos de recursos de replicaciones

Los grupos de recursos de replicaciones sitúan al grupo de dispositivos bajo el control del software &AvailSuite 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 haber un recurso de nombres de host lógico.

  El clúster primario debe alojar el nombre de host lógico. Después de una migración tras error, el clúster secundario debe alojar el nombre de host lógico. El sistema DNS se utiliza para asociar el nombre de host lógico a un clúster.

• Debe haber 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. La propiedad de esta extensión es necesaria para utilizar el sistema de archivos ZFS.

  Para obtener más información sobre HAStoragePlus, consulte la página de 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.

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:

• Tener un recurso de HAStoragePlus para forzar la migración tras error del grupo de dispositivos cuando el grupo de recursos de aplicaciones se conmute o migre tras error.

  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.

    Sin un recurso de HAStoragePlus, la migración tras error del grupo de recursos de aplicaciones no activaría la migración del grupo de recursos de replicaciones y del grupo de dispositivos. Después de una migración tras error, el mismo nodo no controlaría el grupo de recursos de aplicaciones, el grupo de recursos de replicaciones y el grupo de dispositivos.

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

• Debe estar en línea en el clúster primario y fuera de línea en el 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 administrar migraciones tras error

Si se produce un error en el clúster primario, la aplicación se debe conmutar con el clúster secundario en cuanto sea posible. Para que el clúster secundario pueda realizar las funciones del principal, se debe actualizar el DNS.

El DNS asocia un cliente con el nombre de host lógico de una aplicación. Después de una migración tras error, se debe suprimir la asignación del DNS al clúster primario y se debe crear una asignación del DNS al clúster secundario. La Figura A-6 muestra cómo se asigna el DNS a un cliente en un clúster.

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 de comando man nsupdate(1M). Si desea ver un ejemplo de ocuparse de una migración tras error, consulte Ejemplo de cómo controlar una migración tras error.

Después de la reparación, el clúster primario puede volver a estar 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.

2. 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 Sun StorageTek 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ústers

La Figura A-7 ilustra la configuración de clústers 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ústers

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 administrador de volúmenes se deben instalar en los nodos del clúster antes de instalar los parches y el software Sun StorageTek 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.

Este ejemplo de configuración utiliza el software VxVM. Si desea más información sobre el software &SDSSVM, consulte el Capítulo 4, Configuración del software Solaris Volume Manager de Oracle Solaris Cluster Software Installation Guide.

La figura siguiente ilustra los volúmenes creados en el grupo de dispositivos.

Figura A-8 Volúmenes del grupo de dispositivos