Omitir Vínculos de navegación | |
Salir de la Vista de impresión | |
![]() |
Guía de administración de Oracle® ZFS Storage Appliance |
Capítulo 1 Descripción general de Oracle ZFS Storage Appliance
Capítulo 3 Configuración inicial
Capítulo 4 Configuración de red
Capítulo 5 Configuración del almacenamiento
Capítulo 6 Configuración de red de área de almacenamiento
Capítulo 7 Configuración de usuario
Capítulo 8 Configuración de preferencias de dispositivos ZFSSA
Capítulo 9 Configuración de alertas
Capítulo 10 Configuración de cluster
Características y ventajas de los clusters
Descripción de la agrupación en clusters
E/S de interconexión del cluster
Descripción de gestión de recursos del cluster
Cambios de configuración en un entorno en cluster
Consideraciones de la agrupación en clusters para almacenamiento
Consideraciones de la agrupación en clusters para redes
Interfaces IP locales privadas
Consideraciones de la agrupación en clusters para InfiniBand
Situaciones de ruta redundante de agrupación en clusters
Estimación y reducción del impacto de la toma de control
Configuración de clusters con la BUI
Configuración de agrupaciones en clusters
Desconfiguración de una agrupación en clusters
Configuración de agrupaciones en clusters con la CLI
Cierre de una configuración en clusters
Cierre del nodo principal en espera
Desconfiguración de una agrupación en clusters
Cableado de clusters ZS3-4 y 7x20
Cableado de estantes de almacenamiento
Página de configuración de clusters de la BUI
Capítulo 11 Servicios del dispositivo ZFSSA
Capítulo 12 Recursos compartidos, proyectos y esquemas
Capítulo 15 Secuencias de comandos de la CLI
Los nodos principales en clusters pueden estar en uno de una pequeña cantidad de estados posibles en cualquier momento dado:
|
Las transiciones entre estos estados tienen lugar como parte de dos operaciones: toma de control y failback.
La toma de control puede ocurrir en cualquier momento. Como ya se explicó, la toma de control se intenta cuando se detecta un fallo en el par. También se puede iniciar manualmente desde la CLI o la BUI de configuración del cluster. Esto resulta útil para hacer pruebas y realizar actualizaciones de software graduales (actualizaciones en las que se actualiza uno de los nodos principales mientras el otro proporciona los servicios con el software anterior, y a continuación se actualiza el segundo nodo principal una vez que se haya validado el nuevo software). Finalmente, la toma de control se realiza cuando uno de los nodos principales se inicia y detecta que su par está ausente. Esto permite que se reanude el servicio con normalidad cuando uno de los nodos principales falla de manera permanente o cuando ambos nodos principales pierden temporalmente la fuente de alimentación.
El failback nunca se realiza de manera automática. Cuando se repara e inicia un nodo principal que ha fallado, se vuelve a unir al cluster (resincroniza su vista de todos los recursos, sus propiedades y su propietario) y espera a que un administrador realice la operación de failback. Hasta ese momento, el nodo principal original superviviente continúa proporcionando todos los servicios. Esto permite llevar a cabo una investigación completa del problema que ocasionó la toma de control, validar alguna nueva revisión del software o realizar otras tareas administrativas antes de que el nodo principal regrese al servicio de producción. Como el failback interrumpe la actividad de los clientes, se debe programar en función de las necesidades y los procesos específicos de la empresa. Hay una excepción: Supongamos que el nodo principal A falla y que el nodo principal B toma el control. Cuando el nodo principal A se vuelve a unir al cluster, puede tomar el control si detecta que el nodo principal B está ausente o ha fallado. El principio es que siempre es mejor proporcionar servicio que no hacerlo, aun cuando todavía no se haya podido investigar el problema original. De manera que si nunca se realizará automáticamente un failback a un nodo principal que haya fallado, sí es posible que se realice una toma de control en cualquier momento.
Cuando configura un cluster, el estado inicial tiene el nodo que inició la configuración en el estado Propietario y el otro nodo en el estado Segmentado. Después de realizar una operación inicial de failback para entregar al nodo Segmentado su porción de los recursos compartidos, ambos nodos pasan al estado En cluster. Si se apagan ambos nodos del cluster o se produce un fallo en ellos, cuando vuelvan a iniciar simultáneamente se llevará a cabo un arbitraje y uno de ellos tomará el estado Propietario y el otro el estado Segmentado.
Durante el failback, se exportan todos los recursos externos (los asignados al par) y, a continuación, son importados por el par. Una agrupación no se puede importar porque el estado de fallo haría que el nodo Segmentado se reinicie. Si se intenta realizar failback con una agrupación que tiene un fallo, el nodo Segmentado puede reiniciarse a causa del fallo de importación.