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
Los grupos de recursos de replicación sitúan al grupo de dispositivos bajo el control del software de 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 cluster 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.
-
Tener un recurso 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 siguientes propiedades de extensión se deben definir en el recurso 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 cluster primario y en el secundario
Configuración de grupos de recursos de aplicaciones
Para que esté totalmente disponible, una aplicación se debe gestionar 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 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 5 ilustra la configuración de un grupo de recursos de aplicación y de un grupo de recursos de replicación en una aplicación de conmutación por error.
Figura 5 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.
-
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.
Un grupo de recursos de una aplicación escalable debe tener las características siguientes:
La Figura 6 ilustra la configuración de grupos de recursos en una aplicación escalable.
Figura 6 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 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 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.
Figura 7 Asignación del DNS de un cliente a un cluster
Si desea actualizar el DNS, utilice el comando nsupdate. Para obtener 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:
-
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.
-
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.
-
Inicie el grupo de recursos en el cluster principal.
-
Actualice el DNS de modo que los clientes tengan acceso a la aplicación en el cluster primario.