Omitir Vínculos de navegación | |
Salir de la Vista de impresión | |
Guía de administración del sistema de Oracle Solaris Cluster Oracle Solaris Cluster 3.3 3/13 (Español) |
1. Introducción a la administración de Oracle Solaris Cluster
2. Oracle Solaris Cluster y RBAC
3. Cierre y arranque de un cluster
4. Métodos de replicación de datos
Comprensión de la replicación de datos
Métodos admitidos de replicación de datos
Uso de la replicación de datos basada en almacenamiento en un cluster
Requisitos y restricciones del uso de la replicación de datos basada en almacenamiento en un cluster
Mejores prácticas para utilizar la replicación de datos basada en almacenamiento
7. Administración de interconexiones de clusters y redes públicas
8. Adición y eliminación de un nodo
10. Configuración del control del uso de la CPU
11. Aplicación de parches de software y firmware de Oracle Solaris Cluster
12. Copias de seguridad y restauraciones de clusters
13. Administración de Oracle Solaris Cluster con las interfaces gráficas de usuario
La replicación de datos basada en almacenamiento utiliza software instalado en el dispositivo de almacenamiento para gestionar la replicación dentro de un cluster o un cluster de campus. Dicho software es específico de su dispositivo de almacenamiento particular y si no se utiliza para la recuperación después de un desastre. Consulte la documentación incluida con el dispositivo de almacenamiento cuando vaya a configurar la replicación de datos basada en almacenamiento.
Según el software que utiliza, puede usar la conmutación por error manual o automática con la replicación de datos basada en almacenamiento. Oracle Solaris Cluster admite la conmutación por error manual y automática de los replicadores con el software de EMC SRDF, Hitachi Universal Replicator y Hitachi TrueCopy.
En esta sección, se describe la replicación de datos basada en almacenamiento como se la utiliza en un cluster de campus. En la Figura 4-1, aparece un ejemplo de configuración de dos salas en donde los datos se replican entre dos matrices de almacenamiento. En esta configuración, la matriz de almacenamiento principal se incluye en la sala primaria, donde proporciona datos a los nodos de ambas salas. La matriz de almacenamiento principal también proporciona a la matriz de almacenamiento secundaria datos que se van a replicar.
Nota - En la Figura 4-1, se muestra que el dispositivo del quórum está en un volumen sin replicar. Un volumen replicado no se puede utilizar como dispositivo del quórum.
Figura 4-1 Configuración de dos salas con replicación de datos basada en almacenamiento
La replicación de datos basada en almacenamiento con Hitachi TrueCopy o Hitachi Universal Replicator se puede realizar de manera síncrona y asíncrona en el entorno de Oracle Solaris Cluster según el tipo de aplicación que se usa. Si desea realizar una conmutación por error automática en un cluster de campus, utilice TrueCopy de forma síncrona. La replicación síncrona basada en almacenamiento con EMC SRDF es compatible con Oracle Solaris Cluster; la replicación asíncrona no es compatible con EMC SRDF.
No use el modo Domino (Dominó) ni el modo Adaptive Copy (Copia adaptable) de EMC SRDF. El modo Domino (Dominó) hace que los volúmenes SRDF locales y de destino no estén disponibles para el host si el destino no está disponible. El modo Adaptive Copy (Copia adaptable) se usa normalmente para migraciones de datos y movimientos del centro de datos, y no se recomienda para la recuperación después de un desastre.
Si se pierde el contacto con el dispositivo de almacenamiento remoto, asegúrese de que una aplicación que se ejecute en el cluster principal no se bloquee mediante la especificación de 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 las actualizaciones no se pueden copiar en el dispositivo de almacenamiento remoto.
Para garantizar la integridad de los datos, utilice múltiples rutas y el paquete RAID adecuado. En la lista siguiente, se incluyen consideraciones para la implementación de una configuración de cluster que usa replicación de datos basada en almacenamiento.
La distancia de nodo a nodo está limitada por la infraestructura de interconexión y el canal de fibra de Oracle Solaris Cluster. Póngase en contacto con el proveedor de servicios de Oracle para obtener más información acerca de las limitaciones actuales y las tecnologías admitidas.
No configure un volumen replicado como dispositivo del quórum. Localice los dispositivos del quórum en un volumen compartido sin replicar o utilice el servidor del quórum.
Asegúrese de que sólo la copia principal de los datos permanece visible para los nodos del cluster. De lo contrario, el administrador de volúmenes puede intentar acceder simultáneamente a las copias principales y secundarias de los datos. Consulte la documentación que recibió con la matriz de almacenamiento para obtener más información sobre el control de la visibilidad de las copias de datos.
EMC SRDF, Hitachi TrueCopy y Hitachi Universal Replicator permiten definir grupos de dispositivos replicados. Cada grupo de dispositivo de replicación requiere grupo de dispositivo de Oracle Solaris Cluster con el mismo nombre.
Para una configuración de tres sitios o de tres centros de datos que usan EMC SRDF con dispositivos RDF simultáneos o en cascada, debe agregar la siguiente entrada en el archivo de opciones de Solutions Enabler (SYMCLI) en todos los nodos participantes del cluster:
SYMAPI_2SITE_CLUSTER_DG=device-group:rdf-group-number
Esta entrada permite que el software del cluster automatice el movimiento de la aplicación entre los dos sitios SRDF síncronos. El rdf-group-number de la entrada representa el grupo RDF que conecta el symmetrix local del host al symmetrix del segundo sitio.
Para obtener más información sobre las configuraciones de tres centros de datos, consulte Three-Data-Center (3DC) Topologies de Oracle Solaris Cluster Geographic Edition Overview.
Es posible que ciertos datos específicos de la aplicación no sean adecuados para la replicación de datos asincrónica. Emplee sus conocimientos acerca del comportamiento de la aplicación para determinar la mejor manera de replicar datos específicos de la aplicación en los dispositivos de almacenamiento.
Si va a configurar el cluster para la conmutación por error automática, utilice la replicación sincrónica.
Para obtener instrucciones de configuración del cluster para la conmutación por error automática de volúmenes replicados, consulte Administración de dispositivos replicados basados en el almacenamiento.
Oracle Real Application Clusters (RAC) no es compatible con SRDF, Hitachi TrueCopy y Hitachi Universal Replicator al replicar dentro de un cluster. Los nodos conectados a las réplicas que no son actualmente la réplica principal no tienen acceso de lectura. Cualquier aplicación escalable que requiere acceso directo de escritura desde todos los nodos del cluster no es compatible con dispositivos replicados.
No se admite Solaris Volume Manager de múltiples propietarios para el software de Oracle Solaris Cluster.
No use el modo Domino (Dominó) ni el modo Adaptive Copy (Copia adaptable) de EMC SRDF. Consulte Uso de la replicación de datos basada en almacenamiento en un cluster para obtener más información.
No utilice el modo Data (Datos) o el modo Status (Estado) en Hitachi TrueCopy o Hitachi Universal Replicator. Consulte Uso de la replicación de datos basada en almacenamiento en un cluster para obtener más información.
Al igual que ocurre con los clusters de campus, los clusters que utilizan la replicación de datos basada en almacenamiento generalmente no necesitan intervención cuando se produce un solo fallo. Sin embargo, si utiliza la conmutación por error manual y se pierde la sala que contiene el dispositivo de almacenamiento principal (como se muestra en la Figura 4-1), se ocasionan problemas en un cluster de dos nodos. El nodo restante no puede reservar el dispositivo de quórum y no puede iniciar como miembro del cluster. En esta situación, el cluster requiere la siguiente intervención manual:
El proveedor de servicios de Oracle debe volver a configurar el nodo restante para iniciar como miembro del cluster.
O usted o el proveedor de servicios de Oracle deben configurar un volumen sin replicar del dispositivo de almacenamiento secundario como dispositivo del quórum.
O usted o el proveedor de servicios de Oracle deben configurar el nodo restante para utilizar el dispositivo de almacenamiento secundario como almacenamiento principal. Esta reconfiguración puede suponer la reconstrucción de los volúmenes del administrador de volúmenes, la restauración de datos o el cambio de asociaciones de aplicaciones con volúmenes de almacenamiento.
Al configurar grupos de dispositivos que utilizan el software de Hitachi TrueCopy o Hitachi Universal Replicator para la replicación de datos basada en almacenamiento, tenga en cuenta las siguientes prácticas:
Utilice la replicación síncrona para evitar la posibilidad de perder datos si falla el sitio principal.
Debe existir una relación de uno a uno entre el grupo de dispositivos global de Oracle Solaris Cluster y el grupo de replicación de TrueCopy definido en el archivo de configuración horcm. Esto permite que ambos grupos se muevan de un nodo a otro como una sola unidad.
Los volúmenes del sistema de archivos global y los volúmenes del sistema de archivos de conmutación por error no pueden mezclarse en el mismo grupo de dispositivos replicado porque se controlan de forma distinta. Los sistemas de archivos globales se controlan mediante el sistema de configuración de dispositivos (DCS), mientras que los volúmenes del sistema de archivos de conmutación por error se controlan mediante HAS+. El nodo principal para cada uno podría ser diferente, lo que provocaría conflictos para determinar qué nodo debería ser el nodo principal de replicación.
Todas las instancias del gestor de RAID deben estar activas en todo momento.
Al utilizar el software de EMC SRDF para la replicación de datos basada en almacenamiento, use dispositivos dinámicos en lugar de dispositivos estáticos. Los dispositivos estáticos requieren varios minutos para cambiar la replicación principal y pueden afectar el tiempo de conmutación por error.