Solaris Cluster se diseñó para lograr la recuperación automática del sistema en diversos escenarios de error mediante la transferencia del control operativo de un nodo de servidor al nodo siguiente. Sin embargo, la mayoría de los errores en un sistema Solaris no requieren una acción de switchover de todo el sistema para recuperarse.
Solaris IPMP maneja los errores relacionados con comunicaciones de redes de manera rápida y discreta.
Solaris ZFS maneja los errores de discos del sistema de manera automática y discreta.
Los errores con una única unidad de disco en la matriz de almacenamiento conectado son recuperados automáticamente por el firmware de matriz de almacenamiento. Y en aquellos casos donde la matriz de almacenamiento no tuviera la posibilidad de recuperarse de un error de disco, Solaris ZFS tiene el control para proporcionar E/S de disco ininterrumpida a la unidad alternativa en la configuración reflejada.
Si se produce un error de un puerto HBA a la matriz compartida, Solaris conmuta automáticamente al puerto alternativo. Del mismo modo, si se produce un error en el módulo del controlador de la matriz compartida o si se desconecta un cable de interconexión, Solaris lo revierte instantáneamente a la ruta alternativa que se conecta al recurso del disco.
El error de la ruta de comunicación de la biblioteca se recupera automáticamente mediante lógica TCP/IP dual en ACSLS. Además, las operaciones de una tarjeta de controlador de biblioteca con errores se recuperan automáticamente mediante la lógica ACSLS HA asociada con Redundant Electronics (RE) de la biblioteca.
Si se produce un error en alguno de los procesos múltiples en ejecución en ACSLS, el daemon de ACSLS reinicia instantáneamente el proceso con errores.
Si se produce un error en el daemon de ACSLS en sí mismo o si algunos de los servicios ACSLS restantes se dejan de ejecutar, la utilidad de gestión de servicios (SMF) de Solaris reiniciará de inmediato el servicio con errores.
Todos estos escenarios se manejan de manera rápida y automática sin participación de Solaris Cluster. Pero si cualquier otro fallo grave afecta la operación de ACSLS en el nodo de servidor activo, ACSLS HA indica a Solaris Cluster que conmute el control al nodo alternativo.
Una vez comenzado, ACSLS HA realiza sondeos del sistema una vez por minuto a fin de observar si se produce alguno de los siguientes eventos:
Pérdida de comunicación con una biblioteca conectada+.
Pérdida de contacto de red con el host lógico ACSLS.
Pérdida de contacto con el puerto listener RPC para llamadas de clientes.
Pérdida de acceso al sistema de archivos ACSLS.
Estado de mantenimiento irrecuperable del servicio SMF acsls.
Cualquiera de estos eventos activa un failover del cluster. Solaris Cluster también sabe cómo realizar un failover si se producen condiciones fatales del sistema en el nodo de servidor activo.
Para activar el control de failover del cluster:
# cd /opt/ACSLSHA/util # ./acsAgt configure
La utilidad solicita el nombre del host lógico. Asegúrese de que el host lógico esté definido en el archivo /etc/hosts y que las direcciones IP correspondientes estén asignadas en el grupo ipmp definido en el capítulo Configuración del sistema Solaris para ACSLS HA. Antes de ejecutar acsAgt configure, use zpool list para confirmar que acslspool esté montado en el nodo de servidor actual.
Mediante esta acción, se inicia el control del cluster de ACSLS. Solaris Cluster supervisa el sistema realizando sondeos a cada minuto para verificar el estado de ACSLS específicamente y el sistema Solaris en general. Cualquier condición considerada fatal inicia una acción en el nodo alternativo.
Para controlar el estado de cluster del grupo de recursos ACSLS:
# clrg status
La pantalla:
muestra el estado de cada nodo,
identifica el nodo que es el nodo activo,
y muestra si se debe suspender la acción de failover.
Se recomienda configurar una política en el recurso acsls-storage para reiniciar el nodo activo siempre que se pierda la comunicación entre ese nodo y el dispositivo de disco RAID compartido. Esta acción provoca que el nodo activo ceda el control cuando no puede conectarse al disco y, de esa manera, permite a Solaris Cluster transferir el control al nodo alternativo. La configuración de Failover_mode de SOFT a HARD garantiza un reinicio del nodo activo siempre que se pierda la comunicación con el dispositivo de almacenamiento compartido.
Para ver el modo existente Failover_mode, ejecute el siguiente comando:
# clrs show -v acsls-storage | grep Failover
Se debe configurar Failover_mode en HARD de la siguiente manera:
# clrs set -p Failover_mode=HARD acsls-storage
Una vez que se ha activado el control del cluster, puede operar ACSLS de manera normal. Inicie y detenga ACSLS mediante la utilidad de control acsss estándar. Bajo el control del cluster, los usuarios inician y detienen los servicios ACSLS de la misma manera que iniciarían y detendrían la aplicación en un servidor ACSLS independiente. La operación se administra con los siguientes comandos acsss estándar:
acsss enable acsss disable acsss db
El inicio o la detención manual de los servicios acsss con estos comandos no hacen de ninguna manera que Solaris Cluster intervenga con la acción de failover. El uso de los comandos Solaris SMF (como svcadm) tampoco genera la intervención del cluster. Cada vez que los servicios acsss se cancelen o se interrumpan, SMF, no el cluster, será el principal responsable de reiniciar estos servicios.
Solaris Cluster solo interviene para restaurar el control en el nodo adyacente en las siguientes circunstancias:
Pérdida de comunicación con el sistema de archivos ACSLS.
Pérdida de comunicación con todos los puertos Ethernet públicos redundantes.
Comunicación perdida e irrecuperable con la biblioteca especificada.
Si se sospecha que la actividad de mantenimiento puede activar un evento de failover del cluster no deseado, suspenda el control del cluster del grupo de recursos acsls.
Para suspender el control del cluster:
# clrg suspend acsls-rg
Mientras el grupo de recursos está suspendido, Solaris Cluster no intenta conmutar el control al nodo adyacente, independientemente de las condiciones que pudieran disparar dicha acción.
Esta suspensión permite realizar reparaciones más invasivas en el sistema, incluso cuando la producción de la biblioteca pudiera estar en plena operación.
Si el nodo activo se reinicia mientras está en modo suspendido, no monta acslspool después del reinicio, y la operación de ACSLS se detiene. Para eliminar esta condición, reanude el control del cluster.
Para reanudar el control del cluster:
# clrg resume acsls-rg
Si el recurso de disco compartido está montado en el nodo actual, la operación normal se reanuda. Pero si Solaris Cluster descubre en el momento de la activación que zpool no está montado, conmuta el control de inmediato al nodo adyacente. Si no se puede acceder al nodo adyacente, el control se conmuta nuevamente al nodo actual. El cluster intenta montar acslspool e iniciar los servicios ACSLS en este nodo.
El siguiente procedimiento indica la secuencia segura de apagado en caso de ser necesario apagar el sistema ACSLS HA.
Determine el nodo activo en el cluster.
# clrg status
Busque el nodo en línea.
Inicie sesión como root en el nodo activo y detenga el control de Solaris Cluster del grupo de recursos ACSLS.
# clrg suspend acsls-rg
Conmute al usuario acsss y cierre los servicios acsss:
# su - acsss $ acsss shutdown
Cierre sesión como acsss y apague el nodo gradualmente.
$ exit # init 5
Inicie sesión en el nodo alternativo y apáguelo con init 5.
Apague la matriz de discos compartidos mediante el interruptor de energía físico.
Para restaurar la operación de ACSLS en el nodo que estaba activo antes de un cierre controlado:
Encienda ambos nodos localmente mediante el interruptor de energía físico o remotamente mediante Sun Integrated Lights Out Manager.
Encienda la matriz de discos compartidos.
Inicie sesión en cualquier nodo como root.
Si intenta iniciar sesión como acsss o incluir el directorio $ACS_HOME, puede notar que el recurso de discos compartidos no está montado en ningún nodo. Para reanudar la supervisión del cluster, ejecute el siguiente comando:
# clrg resume acsls-rg
Con esta acción, Solaris Cluster monta el disco compartido en el nodo que estaba activo cuando se cerró el sistema. Esta acción, además, debería reiniciar automáticamente los servicios acsss, y la operación normal debería reanudarse.
En ocasiones, ACSLS debe continuar con la operación desde un entorno de servidor independiente en un nodo mientras se repara el otro nodo. Esto se aplicaría en situaciones de mantenimiento del hardware, actualización del sistema operativo o actualización a Solaris Cluster.
Utilice los siguientes procedimientos para crear un servidor ACSLS independiente.
Reinicie el nodo deseado en un modo sin cluster.
# reboot -- -x
Para iniciar en un modo sin cluster desde Open Boot Prom (OBP) en servidores SPARC:
ok: boot -x
En servidores X86, es necesario editar el menú de inicio de GRUB.
Encienda el sistema.
Cuando aparezca el menú de inicio de GRUB, pulse e (editar).
Desde el submenú, utilizando las teclas de flecha, seleccione kernel /platform/i86pc/multiboot. Cuando lo haya seleccionado, pulse e.
En el modo de edición, agregue -x a la opción de inicio múltiple kernel /platform/i86pc/multiboot -x y haga clic en Intro.
Con la opción de inicio múltiple -x seleccionada, pulse b para realizar el inicio con esa opción.
Una vez que ha finalizado el ciclo de inicio, inicie sesión como root e importe la agrupación ACSLS Z.
# zpool import acslspool
Si fuera necesario, utilice la opción -f (forzar) cuando el recurso de disco se mantiene vinculado a otro nodo.
# zpool import -f acslspool
Abra los servicios acsss.
# su - acsss $ acsss enable