Hace tiempo ya os hablé sobre cómo configurar clusters de servicio con ServiceGuard. Veritas Cluster es un producto similar que también podemos utilizar para configurar servicios de alta disponibilidad.
¿Qué es Veritas Cluster (VCS)?
Veritas Cluster es una solución de alta disponibilidad que permite mantener aplicaciones críticas en funcionamiento continuo en caso de fallos de hardware o software. El funcionamiento de Veritas Cluster se basa en la implementación de un clúster de servidores que trabajan en conjunto para proporcionar un servicio confiable y continuo.
En un clúster de Veritas Cluster, cada servidor (también llamado nodo) tiene acceso a un conjunto de discos compartidos y a una red de comunicaciones. Veritas Cluster utiliza técnicas de detección de fallos para identificar cuándo un nodo ha dejado de responder y toma medidas para asegurarse de que las aplicaciones que se ejecutan en ese nodo se reinicien en otro nodo del clúster.
Cuando una aplicación se ejecuta en Veritas Cluster, se asigna a un grupo de recursos. Cada grupo de recursos incluye la aplicación, los discos compartidos y cualquier otro recurso necesario para que la aplicación funcione correctamente, como direcciones IP virtuales, servicios de red y archivos de configuración. Cuando un nodo del clúster detecta que ha fallado un nodo, Veritas Cluster automáticamente toma medidas para transferir los grupos de recursos de la aplicación a otro nodo del clúster.
Además, Veritas Cluster también incluye herramientas de administración y monitorización que permiten a los administradores del sistema controlar y supervisar la configuración del clúster y la disponibilidad de los servicios. Estas herramientas pueden utilizarse para realizar tareas como la creación de grupos de recursos, la definición de políticas de failover y la realización de tareas de mantenimiento.
Arquitectura de Veritas Cluster
La arquitectura de Veritas Cluster se basa en un clúster de servidores que trabajan en conjunto para proporcionar servicios de alta disponibilidad. En un clúster de Veritas Cluster, se pueden tener múltiples nodos (servidores) que comparten un conjunto de discos y una red de comunicaciones. Cada nodo en el clúster tiene instalado Veritas Cluster Server (VCS), que es el software que permite la administración del clúster y la gestión de los recursos.
A continuación se describen los componentes principales de la arquitectura de Veritas Cluster:
Nodos (servidores): Son los componentes físicos del clúster. Cada nodo en el clúster ejecuta una instancia de VCS que se comunica con los otros nodos del clúster para coordinar la gestión de los recursos. Los nodos están conectados a una red privada de comunicaciones para intercambiar información sobre el estado del clúster y los recursos.
Discos compartidos: Todos los nodos del clúster tienen acceso a un conjunto de discos compartidos que se utilizan para almacenar los datos y configuraciones de las aplicaciones que se ejecutan en el clúster. Los discos compartidos pueden ser almacenamiento directamente conectado (DAS), almacenamiento conectado en red (SAN) o almacenamiento en la nube.
Red de comunicaciones: Es la red privada que conecta los nodos del clúster y permite la comunicación y coordinación entre ellos. Esta red se utiliza para enviar mensajes y datos de estado entre los nodos, y para sincronizar los discos compartidos.
Veritas Cluster Server (VCS): Es el software que permite la administración del clúster y la gestión de los recursos. VCS se ejecuta en cada nodo del clúster y se encarga de coordinar la detección de fallos, la transferencia de recursos y la gestión de políticas de failover.
Grupos de recursos: Los recursos se agrupan en conjuntos lógicos llamados grupos de recursos. Cada grupo de recursos incluye los recursos necesarios para que una aplicación funcione correctamente, como la aplicación en sí, los discos compartidos, las direcciones IP virtuales, las interfaces de red y los servicios de red. Los grupos de recursos se asignan a un nodo principal y a un nodo de respaldo, para garantizar que la aplicación se pueda recuperar rápidamente en caso de un fallo.
Componentes de Veritas Cluster
Los componentes principales de Veritas Cluster incluyen:
Veritas Cluster Server (VCS): es el software que permite la administración del clúster y la gestión de los recursos. VCS se ejecuta en cada nodo del clúster y se encarga de coordinar la detección de fallos, la transferencia de recursos y la gestión de políticas de failover.
Agentes: son programas que se ejecutan en cada nodo del clúster y que proporcionan la capacidad de monitorizar y gestionar recursos específicos. Los agentes son específicos para cada aplicación o servicio que se desea monitorizar. VCS incluye un conjunto de agentes predefinidos para diferentes tipos de recursos, como bases de datos, servidores web, servidores de correo, entre otros.
Grupos de recursos: los recursos se agrupan en conjuntos lógicos llamados grupos de recursos. Cada grupo de recursos incluye los recursos necesarios para que una aplicación funcione correctamente, como la aplicación en sí, los discos compartidos, las direcciones IP virtuales, las interfaces de red y los servicios de red.
Políticas de failover: son las reglas que determinan cómo se gestionan los recursos en caso de un fallo. Las políticas de failover especifican cuándo se debe transferir un grupo de recursos de un nodo a otro y cómo se debe realizar la transferencia.
Comunicaciones: los nodos del clúster se comunican entre sí a través de una red privada para intercambiar información sobre el estado del clúster y los recursos. También se utilizan protocolos de comunicación para sincronizar los discos compartidos.
Herramientas de administración: VCS incluye una serie de herramientas de administración que permiten la monitorización del clúster, la gestión de grupos de recursos y la configuración de políticas de failover. Estas herramientas se pueden utilizar para realizar tareas como la creación de grupos de recursos, la configuración de agentes, la definición de políticas de failover y la monitorización del estado del clúster y los recursos.
Discos compartidos: todos los nodos del clúster tienen acceso a un conjunto de discos compartidos que se utilizan para almacenar los datos y configuraciones de las aplicaciones que se ejecutan en el clúster. Los discos compartidos pueden ser almacenamiento directamente conectado (DAS), almacenamiento conectado en red (SAN) o almacenamiento en la nube.
Nodo principal y nodo de respaldo: cada grupo de recursos se asigna a un nodo principal y a un nodo de respaldo, para garantizar que la aplicación se pueda recuperar rápidamente en caso de un fallo. El nodo principal es responsable de ejecutar el grupo de recursos, mientras que el nodo de respaldo está en espera en caso de que el nodo principal falle.
Funcionamiento de Veritas Cluster
El funcionamiento de Veritas Cluster se basa en el concepto de alta disponibilidad y se centra en garantizar la continuidad de los servicios y aplicaciones en caso de fallos. Esto se logra a través de una combinación de tecnologías de hardware y software.
Cuando se configura Veritas Cluster, se crea un conjunto de nodos (servidores) que comparten discos y recursos, como direcciones IP y servicios de red. Estos nodos se comunican entre sí a través de una red privada y comparten información sobre el estado del clúster y los recursos.
Cada recurso se agrupa en un grupo de recursos y se asigna a un nodo principal y a un nodo de respaldo. El nodo principal es responsable de ejecutar el recurso, mientras que el nodo de respaldo permanece en espera en caso de que el nodo principal falle.
Veritas Cluster también incluye agentes específicos para cada tipo de recurso, que se ejecutan en cada nodo y proporcionan la capacidad de monitorizar y gestionar recursos específicos, como bases de datos, servidores web, servidores de correo, entre otros.
Cuando se produce un fallo en el nodo principal, Veritas Cluster detecta el fallo y realiza automáticamente la transferencia del grupo de recursos al nodo de respaldo. Esto se conoce como failover y se produce de forma transparente para los usuarios, lo que garantiza la continuidad del servicio o la aplicación.
Además, Veritas Cluster también proporciona herramientas de administración para la configuración y gestión del clúster, incluyendo la creación y configuración de grupos de recursos, la definición de políticas de failover y la monitorización del estado del clúster y los recursos.
En resumen, el funcionamiento de Veritas Cluster se basa en la alta disponibilidad y se centra en garantizar la continuidad de los servicios y aplicaciones críticas en caso de fallos. Esto se logra a través de una combinación de tecnologías de hardware y software, incluyendo la detección de fallos, la transferencia automática de recursos y las herramientas de administración.
Creación y configuración de grupos de recursos
La creación y configuración de grupos de recursos de Veritas Cluster es un proceso importante que permite definir los recursos que se van a monitorizar y administrar en el clúster. A continuación, se detallan los pasos para crear y configurar un grupo de recursos en Veritas Cluster:
Identificación de los recursos: lo primero que debe hacerse es identificar los recursos que se van a incluir en el grupo. Estos pueden ser aplicaciones, bases de datos, servicios de red, sistemas de almacenamiento, entre otros.
Configuración de los recursos: una vez identificados los recursos, se debe configurar cada uno de ellos en el nodo en el que se van a ejecutar. Para ello, se utilizan los agentes específicos de Veritas Cluster que permiten monitorizar y administrar cada recurso.
Creación del grupo de recursos: después de configurar los recursos, se crea un grupo de recursos en el que se agrupan todos los recursos relacionados. El grupo de recursos se configura con un nombre y se asigna a un nodo principal y a un nodo de respaldo.
Configuración de las políticas de failover: se definen las políticas de failover, que determinan las acciones que se deben llevar a cabo en caso de que se produzca un fallo en el nodo principal. Estas políticas pueden incluir la transferencia automática del recurso al nodo de respaldo, la notificación por correo electrónico o la ejecución de un script personalizado.
Prueba del grupo de recursos: una vez configurado el grupo de recursos y las políticas de failover, se recomienda realizar pruebas para comprobar que el grupo se comporta de forma adecuada en caso de fallos. Durante estas pruebas, se pueden simular fallos en el nodo principal para comprobar que el recurso se transfiere correctamente al nodo de respaldo.
Monitorización y gestión del grupo de recursos: una vez que se ha configurado el grupo de recursos y se ha probado su funcionamiento, es importante monitorizar y gestionar el grupo de recursos de forma regular para garantizar la continuidad del servicio y la aplicación.
Políticas de failover en Veritas Cluster
Las políticas de failover en Veritas Cluster definen las acciones que se deben llevar a cabo en caso de que se produzca un fallo en el nodo principal de un recurso. Estas políticas se configuran en el grupo de recursos y determinan el comportamiento del clúster en caso de fallos. Algunas de las políticas de failover más comunes en Veritas Cluster son las siguientes:
Automático: esta política es la más utilizada y consiste en la transferencia automática del recurso al nodo de respaldo en caso de que se produzca un fallo en el nodo principal. El failover se realiza de forma automática y transparente para el usuario, y se restablece el servicio o aplicación en el nodo de respaldo.
Manual: esta política implica que la transferencia del recurso al nodo de respaldo se realiza de forma manual por el administrador del clúster. En este caso, el administrador del clúster recibe una notificación del fallo en el nodo principal y debe realizar la transferencia del recurso al nodo de respaldo manualmente.
Preferencia de nodo: esta política permite especificar el nodo de destino preferido para el failover. En caso de que se produzca un fallo en el nodo principal, el recurso se trasladará al nodo preferido en lugar del nodo de respaldo predeterminado.
Preferencia de sitio: esta política se utiliza en entornos de clústeres geográficamente distribuidos. Permite especificar el sitio preferido para la ejecución del recurso y, en caso de que se produzca un fallo en el sitio principal, se traslada el recurso al sitio preferido.
No fallar: esta política se utiliza para recursos que no deben fallar bajo ninguna circunstancia. Si se produce un fallo en el nodo principal, se realiza la transferencia del recurso al nodo de respaldo, pero si el nodo de respaldo falla también, no se produce el failover y el recurso permanece inactivo.
Herramientas de administración y monitorización
Veritas Cluster ofrece varias herramientas para la administración y monitorización del clúster. Algunas de las herramientas más comunes son las siguientes:
Veritas Cluster Manager: es una herramienta gráfica que permite la gestión y monitorización del clúster de forma intuitiva y visual. Ofrece una vista en tiempo real del estado del clúster, incluyendo la configuración de los grupos de recursos, los nodos del clúster y los recursos individuales. Además, permite realizar tareas de administración, como la creación y eliminación de grupos de recursos, la configuración de políticas de failover y la realización de pruebas de conmutación por error.
Command line interface (CLI): Veritas Cluster también ofrece una interfaz de línea de comandos para la administración del clúster. La CLI proporciona una gran cantidad de opciones para configurar y monitorizar el clúster, y es especialmente útil para la automatización de tareas y scripts.
Veritas Cluster Server Management Console (VCSMC): esta herramienta proporciona una vista centralizada de la configuración del clúster, lo que permite a los administradores ver y gestionar todos los recursos del clúster desde una sola consola. La VCSMC también proporciona acceso a funciones avanzadas, como la monitorización de recursos y nodos individuales, la creación y eliminación de grupos de recursos y la configuración de políticas de failover.
Veritas Cluster Manager Simulator: es una herramienta que permite a los administradores probar y validar la configuración del clúster sin afectar al entorno de producción. Con el simulador, se pueden probar diferentes configuraciones de clúster, grupos de recursos y políticas de failover, lo que ayuda a minimizar el riesgo de fallos y a reducir el tiempo de inactividad en el entorno de producción.
Ejemplos de casos de uso de Veritas Cluster
Veritas Cluster se utiliza en una amplia gama de entornos empresariales para garantizar la alta disponibilidad de los recursos críticos. Algunos de los casos de uso más comunes incluyen los siguientes:
Servidores de bases de datos: Veritas Cluster se utiliza con frecuencia en entornos de bases de datos para garantizar la alta disponibilidad y el rendimiento de las aplicaciones críticas. En estos casos, el clúster se utiliza para garantizar que la base de datos se ejecute continuamente en caso de fallo en el nodo principal, lo que minimiza el tiempo de inactividad y reduce el riesgo de pérdida de datos.
Servidores de aplicaciones: Veritas Cluster también se utiliza en entornos de servidores de aplicaciones para garantizar la alta disponibilidad y el rendimiento de las aplicaciones empresariales. En estos casos, el clúster se utiliza para garantizar que la aplicación se ejecute continuamente en caso de fallo en el nodo principal, lo que minimiza el tiempo de inactividad y reduce el riesgo de pérdida de datos.
Entornos de virtualización: Veritas Cluster también se utiliza en entornos de virtualización para garantizar la alta disponibilidad y el rendimiento de las máquinas virtuales. En estos casos, el clúster se utiliza para garantizar que las máquinas virtuales se ejecuten continuamente en caso de fallo en el nodo principal, lo que minimiza el tiempo de inactividad y reduce el riesgo de pérdida de datos.
Servidores de correo electrónico: Veritas Cluster se utiliza con frecuencia en entornos de correo electrónico para garantizar la alta disponibilidad y el rendimiento de los servidores de correo electrónico. En estos casos, el clúster se utiliza para garantizar que el servidor de correo electrónico se ejecute continuamente en caso de fallo en el nodo principal, lo que minimiza el tiempo de inactividad y reduce el riesgo de pérdida de datos.
Caso práctico: Configuración de un cluster de base de datos que pueda balancear entre dos nodos
Para configurar una base de datos que pueda balancear entre dos nodos en Veritas Cluster, se pueden utilizar los siguientes comandos:
- Crear el grupo de recursos:
hagrp -add <nombre_del_grupo>
- Agregar el recurso de IP:
hagrp -modify <nombre_del_grupo> AutoStartList IP <nombre_de_la_IP>
hagrp -add <nombre_del_grupo> IP <nombre_de_la_IP>
- Agregar el recurso de sistema de archivos:
hagrp -modify <nombre_del_grupo> AutoStartList Mount <nombre_del_FS>
hagrp -add <nombre_del_grupo> Mount <nombre_del_FS>
- Agregar el recurso de la base de datos:
hagrp -add <nombre_del_grupo> Oracle <nombre_de_la_base_de_datos>
hagrp -modify <nombre_del_grupo> Oracle <nombre_de_la_base_de_datos> UAgentStartTimeout 1800
- Configurar el recurso de la base de datos para balancear entre los nodos:
hares -modify <nombre_de_la_base_de_datos> PreferredServer <nombre_del_nodo_preferido>
hares -modify <nombre_de_la_base_de_datos> AlternateServer <nombre_del_nodo_alternativo>
- Verificar el estado del grupo:
hagrp -state <nombre_del_grupo>
Con estos comandos básicos, se puede configurar una base de datos que puede balancear entre dos nodos en Veritas Cluster. Cabe destacar que es importante seguir las guías de instalación y configuración de Veritas Cluster, y que estos comandos son solo un ejemplo básico de cómo configurar un grupo de recursos.
En los comandos anteriores, no se especifica el script de arranque de la base de datos. Sin embargo, en la configuración de un recurso Oracle en Veritas Cluster, es necesario especificar el script de arranque de la base de datos.
Para hacerlo, se debe agregar la opción «StartList» al comando «hagrp -add», con el nombre del script de arranque de la base de datos:
hagrp -add <nombre_del_grupo> Oracle <nombre_de_la_base_de_datos> StartList "<ruta_del_script_de_arranque>"
El script de arranque especificado debe ser capaz de iniciar la base de datos en el nodo en el que se está ejecutando y configurar el entorno para el inicio de la base de datos.
Cabe destacar que la configuración exacta de los scripts de arranque de la base de datos dependerá de la configuración específica de la base de datos y puede variar de un entorno a otro. Por lo tanto, es importante seguir las guías de instalación y configuración de Veritas Cluster y la documentación de la base de datos para configurar correctamente el script de arranque.
Configurar un flesystem LVM en un cluster de Veritas
LVM es un tipo de arquitectura de filesystem ampliamente extendida en los sistemas Linux. Si queremos que el cluster de Veritas monte un filesystem de tipo LVM, deberemos lo haremos de la siguiente manera:
- Creamos un VG. lvol y filesystem LVM utilizando discos de la SAN visibles en todos los nodos del cluster para que el FS se pueda montar en cualquiera de ellos.
- Abrimos la base de datos de Veritas Cluster en modo escritura:
haconf-makerw- Creamos un grupo de servicio llamado «lvm_vg»:
hagrp-add lvm_vg
hagrp-modify lvm_vg SystemList system1 0 system21
hagrp -modifylvm_vg AutoStartList system1- Creamos el recurso del VG dentro del cluster de Veritas:
hares -addvg_vg01 LVMVolumeGrouplvm_vg
hares -modifyvg_vg01 VolumeGroup vg01- También añadimos los lvols:
hares -addlvol_lvol1 LVMLogicalVolumelvm_vg
hares -modifylvol_lvol1 LogicalVolumelvol1
hares -modifylvol_lvol1 VolumeGroupvg01
hares -addlvol_lvol2 LVMLogicalVolumelvm_vg
hares -modifylvol_lvol2 LogicalVolumelvol2
hares -modifylvol_lvol2 VolumeGroup vg01- Enlazamos los recursos de lvol con los recursos de VG:
hares -linklvol_lvol1 vg_vg01
hares -link lvol_lvol2 vg_vg01En Veritas cluster un enlace significa que un recurso depende de otro con el fin de establecer un orden de arranque y parada del mismo.
- Creamos el recurso de los puntos de montaje:
hares -addmnt_lvol1 Mountlvm_vg
hares -modifymnt_lvol1 MountPoint/my_lvol1
hares-modify mnt_lvol1 BlockDevice/dev/vg01/lvol1
hares-modify mnt_lvol1 FSTypevxfs
hares -modifymnt_lvol1 FsckOpt%-y
hares -addmnt_lvol2 Mountlvm_vg
hares -modifymnt_lvol2 MountPoint/my_lvol2
hares-modify mnt_lvol2 BlockDevice/dev/vg01/lvol2
hares-modify mnt_lvol2 FSTypevxfs
hares -modifymnt_lvol2 FsckOpt %-y
hares -modify mnt_lvol2 MountOptlargefiles- Enlazamos los recursos de montaje de filesystem con el recurso de lvol:
hares -link mnt_lvol1lvol_lvol1
hares-link mnt_lvol2 lvol_lvol2- Habilitamos los nuevos recursos que acabamos de crear:
hares-modify vg_vg01 Enabled1
hares -modifylvol_lvol1 Enabled 1
hares -modify lvol_lvol2 Enabled1
hares -modifymnt_lvol2 Enabled 1
hares -modify mnt_lvol1 Enabled 1- Cerramos la base de datos del cluster de Veritas:
haconf -dump -makeroComandos útiles de Veritas Cluster
Fuente oficial: https://www.veritas.com/support/en_US/article.100006818#Cluster_Status
LLT & GAB
VCS utiliza dos componentes, LLT y GAB, para compartir datos a través de redes privadas entre sistemas.
Estos componentes brindan el rendimiento y la confiabilidad requeridos por VCS.
| LLT | LLT (Low Latency Transport o Transporte de baja latencia) proporciona comunicaciones rápidas de kernel a kernel y monitoriza las conexiones de red. El administrador del sistema configura el LLT mediante la creación de un archivo de configuración (llttab) que describe los sistemas en el clúster y los enlaces de red privada entre ellos. |
| GAB | GAB (Group membership and Atomic Broadcast) proporciona el orden de mensajes global necesario para mantener un estado sincronizado entre los sistemas y supervisa las comunicaciones de disco, como las que requiere la utilidad VCS heartbeat. El administrador del sistema configura el controlador GAB creando un archivo de configuración (gabtab). |
| /etc/llthosts | El archivo es una base de datos, que contiene una entrada por sistema, que vincula el ID del sistema LLT con el nombre del host. El archivo es idéntico en cada servidor del clúster. |
| /etc/llttab | El archivo contiene información que se obtiene durante la instalación y que utiliza la utilidad lltconfig. |
| /etc/gabtab | El archivo contiene la información necesaria para configurar el controlador GAB. Este archivo es utilizado por la utilidad gabconfig. |
| /etc/VRTSvcs/conf/config/main.cf | El archivo de configuración de VCS. El archivo contiene la información que define el clúster y sus sistemas. |
| gabconfig | -c Configurar un controlador para su uso -n Numero de sistemas que foman el cluster -a Puertos en uso actualmente -x «Sembrar» manualmente el nodo (cuidado con esta opción, ya que puede crear 2 clústers separados) |
LLT and GAB Commands
| Verificación de que los enlaces están activos para LLT | lltstat -n |
| verbose (más información sobre el resultado del comando) | lltstat -nvv | more |
| puertos abiertos para LLT | lltstat -p |
| mostrar los valores de las directivas de configuración LLT | lltstat -c |
| muestra información sobre cada enlace LLT configurado | lltstat -l |
| Listar todas las direcciones MAC en el clúster | lltconfig -a list |
| Parar LLT | lltconfig -U |
| Arrancar LLT | lltconfig -c |
| verificar que GAB esté funcionando | gabconfig -aNote: port a indicates that GAB is communicating, port h indicates that VCS is started. |
| Parar GAB | gabconfig -U |
| Arrancar GAB | gabconfig -c |
| Arrancar GAB en un conjunto de nodos | gabconfig -c -n <number of nodes> |
| anular los valores semilla en el archivo gabtab | gabconfig -c -x |
GAB Port Memberbership
| Lisado de miembros | gabconfig -a |
| Eliminar puerto | /opt/VRTS/bin/fsclustadm cfsdeinit |
| Funciones del puerto | a gab driver b I/O fencing (designed to guarantee data integrity) d ODM (Oracle Disk Manager) f CFS (Cluster File System) h VCS (VERITAS Cluster Server: high availability daemon) o VCSMM driver (kernel module needed for Oracle and VCS interface) q QuickLog daemon v CVM (Cluster Volume Manager) w vxconfigd (module for cvm) y kernel-tokernel communication used for I/O shipping. |
Cluster daemons
| Demonio de alta disponibilidad | had |
| Demonio compañero | hashadow |
| Demonio del agente de recursos | <resource>Agent |
| Consola WEB de administración del cluster | CmdServer |
Cluster Log Files
| Directorio de logs | /var/VRTSvcs/log |
| Log primario | /var/VRTSvcs/log/engine_A.log |
| Logs de los agentes | /var/VRTSvcs/log/<Agent type>_A.log |
Starting and Stopping the cluster
| «-stale» indica al cluster que considere la configuración local como obsoleta «-force» | hastart [-stale|-force] |
| Arranca el cluster desde un estado obsoleto utilizando el archivo de configuración de un servidor en particular. | hasys -force <server_name> |
Para el cluster y sus recursos en el servidor local. | hastop -local |
Para el cluster en el servidor local pero arranca las aplicaciones en otro nodo. | hastop -local -evacuate |
| Paa el clúster en todos los nodos pero deja los recursos en línea. | hastop -all -force |
Cluster Status
| Muestra información sobre el cluster | hastatus -summary |
| hastatus | |
| Verifica que el cluster está corriendo | hasys -display |
Cluster Details
| Muestra información sobre el cluster | haclus -display |
| Muestra información sobre un atributo específico del cluster | haclus -value <attribute> |
| Modifica un atributo del cluster | haclus -modify <attribute name> <new> |
| Habilita la monitorización del enlazado | haclus -enable LinkMonitoring |
| Deshabilita la monitorización del enlazado | haclus -disable LinkMonitoring |
Users
| Añade un usuario al cluster | hauser -add <username> |
| Modifica un usuario | hauser -update <username> |
| Elimina un usuario user | hauser -delete <username> |
| Muestra los usuarios existentes | hauser -display |
System Operations
| Añade un sistema al cluster | hasys -add <sys> |
| Elimina un sistema del cluster | hasys -delete <sys> |
| Modifica atributos del sistema | hasys -modify <sys> <modify options> |
| Muestra el estado del sistema | hasys -state |
| Fuerza el arranque de un sistema | hasys -force |
| Muestra los atributos del sistema | hasys -display [-sys] |
| Muestra todos los sistemas que forman el cluster | hasys -list |
| Modifica el atributo «load» del sistema | hasys -load <system> <value> |
| Muestra el valor del sistema «nodeid» (/etc/llthosts) | hasys -nodeid |
| Congela un sistema (Sin sistema fuera de línea, sin grupos en línea) | hasys -freeze [-persistent][-evacuate]Note: main.cf must be in write mode |
| Unfreeze a system Descongela un sistema (volver a habilitar grupos y recursos en línea) | hasys -unfreeze [-persistent]Note: main.cf must be in write mode |
Dynamic Configuration
La configuración de Veritas Cluster debe estar en modo lectura o escritura para poder realizar cambio o aplicarlos. Cuando está en modo escritura se crea un fichero temporal .stale en $VCS_CONF/conf/config. Cuando la configuración vuelve a ponerse en modo sólo lectura, el fichero .stale se elimina.
| Cambiar la configuración a modo lectura y escritura | haconf -makerw |
| Cambiar la configuración a modo sólo lectura | haconf -dump -makero |
| Chequear en que modo está corriendo el cluster | haclus -display |grep -i ‘readonly’0 = write mode 1 = read only mode |
| Chequear el fichero de configuración | hacf -verify /etc/VRTS/conf/configNote: you can point to any directory as long as it has main.cf and types.cf |
| Convierte el fichero main.cf en comandos del cluster | hacf -cftocmd /etc/VRTS/conf/config -dest /tmp |
| Convierte un fichero de comandos an el archivo main.cf | hacf -cmdtocf /tmp -dest /etc/VRTS/conf/config |
Service Groups
| Añade un grupo de servicios | haconf -makerw hagrp -add groupw hagrp -modify groupw SystemList sun1 1 sun2 2 hagrp -autoenable groupw -sys sun1 haconf -dump -makero |
| Elimina un grupo de servicios | haconf -makerw hagrp -delete groupw haconf -dump -makero |
| Cambia un grupo de servicios | haconf -makerw hagrp -modify groupw SystemList sun1 1 sun2 2 sun3 3 haconf -dump -makeroNote: use the «hagrp -display <group>» to list attributes |
| Muestra los grupos de servicios | hagrp -list |
| Muestra las dependencias de grupos de servicios | hagrp -dep <group> |
| Muestra los parámetros de un grupo | hagrp -display <group> |
| Muestra los recursos de un grupo de servicios | hagrp -resources <group> |
| Muestra el estado actual de grupo de servicios | hagrp -state <group> |
| Elimina un recurso no persistente defectuoso en un grp específico | hagrp -clear <group> [-sys] <host> <sys> |
| Cambia la lista de sistemas en un clúster | # remove the host hagrp -modify grp_zlnrssd SystemList -delete <hostname># add the new host (don’t forget to state its position) hagrp -modify grp_zlnrssd SystemList -add <hostname> 1# update the autostart list hagrp -modify grp_zlnrssd AutoStartList <host> <host> |
Service Group Operations
| Inicia un grupo de servicio y pone sus recursos en línea | hagrp -online <group> -sys <sys> |
| Para un grupo de servicios y sus recursos | hagrp -offline <group> -sys <sys> |
| Balancea un grupo de servicios a otro nodo del cluster | hagrp -switch <group> -to <sys> |
| Habilita todos los recursos de un grupo | hagrp -enableresources <group> |
| Deshabilita todos los recursos de un grupo | hagrp -disableresources <group> |
| Freeze a service group (deshabilitar en línea y fuera de línea) | hagrp -freeze <group> [-persistent]note: use the following to check «hagrp -display <group> | grep TFrozen» |
| Descongela un grupo de sevicios (habilitar en línea y fuera de línea) | hagrp -unfreeze <group> [-persistent]note: use the following to check «hagrp -display <group> | grep TFrozen» |
| Habilita un grupo de servicios pero sólo los grupos habilitados estarán online. | haconf -makerw hagrp -enable <group> [-sys] haconf -dump -makeroNote to check run the following command «hagrp -display | grep Enabled» |
| Deshabilita un grupo de servicios (deja de poner en línea). | haconf -makerw hagrp -disable <group> [-sys] haconf -dump -makeroNote to check run the following command «hagrp -display | grep Enabled» |
| Vacía un grupo de servicios y habilita la acción correctiva (flush). | hagrp -flush <group> -sys <system> |
Resources
| Añade un recurso | haconf -makerw hares -add appDG DiskGroup groupw hares -modify appDG Enabled 1 hares -modify appDG DiskGroup appdg hares -modify appDG StartVolumes 0 haconf -dump -makero |
| Elimina un recurso | haconf -makerw hares -delete <resource> haconf -dump -makero |
| Modifica un recurso | haconf -makerw hares -modify appDG Enabled 1 haconf -dump -makeroNote: list parameters «hares -display <resource>» |
| Cambia el atributo de un recurso a nivel global | hares -global <resource> <attribute> <value> |
| Modifica el atributo de un recurso a nivel local | hares -local <resource> <attribute> <value> |
| Muestra los parámetros de un recurso | hares -display <resource> |
| Listado de recursos | hares -list |
| Listado de dependencias de un recurso | hares -dep |
Resource Operations
| Pone online un recurso | hares -online <resource> [-sys] |
| Pone offline un recurso | hares -offline <resource> [-sys] |
| Muestra el estado de un recurso | hares -state |
| Muestra los parámetros de un recurso | hares -display <resource> |
| Desconecta un recurso y propagar el comando a sus hijos | hares -offprop <resource> -sys <sys> |
| Hace que un agente de recursos supervise inmediatamente el recurso | hares -probe <resource> -sys <sys> |
| Borrar un recurso (inicia automáticamente la conexión) | hares -clear <resource> [-sys] |
Resource Types
| Añade un tipo de recurso | hatype -add <type> |
| Elimina un tipo de recurso | hatype -delete <type> |
| Muestra los tipos de recursos | hatype -list |
| Muestra un tipo de recurso | hatype -display <type> |
| Lista un tipo de recurso específico | hatype -resources <type> |
| Modifica los atributos de un tipo de recurso específico | hatype -value <type> <attr> |
Resource Agents
| Añade un agente | pkgadd -d . <agent package> |
| Elimina un agente | pkgrm <agent package> |
| Modifica un agente | n/a |
| Lista todos los agentes de alta dispinibilidad | haagent -list |
| Muestra el tiempo que llevan ejecutándose los agentes | haagent -display <agent_name> |
| Muestra errores de los agentes | haagent -display |grep Faults |
Resource Agent Operations
| Arranca un agente | haagent -start <agent_name>[-sys] |
| Para un agente | haagent -stop <agent_name>[-sys] |
¿Cómo configurar un cluster de Veritas Cluster?
Ahora que ya hemos visto la estructura básica y los comandos más importantes de Veritas Cluster, podremos proceder a configurar un cluster básico de Veritas Cluster a través de la línea de comandos.
- Configuración inicial:
- Instalar y configura Veritas Cluster Server en todos los nodos del cluster.
- Asegúrse de que todos los nodos tengan la conectividad de red adecuada y compartan el mismo almacenamiento compartido (por ejemplo, SAN).
- Crear un archivo de configuración del cluster:
- En cada nodo, se crea un archivo de configuración del cluster utilizando el comando
haclus -addnode <nodename>. Esto agregará el nodo al archivo de configuración del cluster.
- En cada nodo, se crea un archivo de configuración del cluster utilizando el comando
- Configurar los servicios y recursos:
- Utilizar el comando
haconf -makerwpara hacer el archivo de configuración del cluster editable. - Utilizar los comandos
haresyhagrppara crear recursos y grupos de recursos respectivamente. - Utilizar el comando
hares -modify <resource> AutoStartList <nodelist>para especificar en qué nodos deben iniciarse los recursos automáticamente. - Configurar los atributos y propiedades de los recursos utilizando el comando
hares -modify <resource> <attribute> <value>.
- Utilizar el comando
- Configurar la comunicación del cluster:
- Utilizar el comando
haclus -join <nodename>en cada nodo para unirlos al cluster. - Configurar las interfaces de comunicación del cluster utilizando el comando
haif -add <interface_name> <ip_address>.
- Utilizar el comando
- Iniciar el cluster:
- Utiliza el comando
haclus -startpara iniciar el cluster en todos los nodos.
- Utiliza el comando
Estos son solo pasos básicos para configurar un cluster de Veritas Cluster Server a través de la línea de comandos. A partir de aquím podemos complementar la configuración añadiendo nuevos recursos y servicios al cluster, como el montaje de filesystems, arranque de bases de datos, etc.
Realizar una copia de seguridad de Veritas Cluster
Para hacer una copia de seguridad de un cluster de Veritas Cluster Server (VCS), debemos realizar una copia de seguridad de los archivos de configuración del cluster, así como de cualquier otro archivo relevante para la configuración y el estado del cluster:
- Realizar una copia de seguridad de los archivos de configuración del cluster:
- Los archivos principales que debes respaldar son
gabtab,llttab,hastabymain.cf. - Estos archivos generalmente se encuentran en el directorio
/etc/VRTSvcs/conf/en cada nodo del cluster. - Copia estos archivos en un lugar seguro para su posterior restauración.
- Los archivos principales que debes respaldar son
- Realizar una copia de seguridad de los archivos de recursos y grupos:
- Los archivos de configuración de recursos y grupos se encuentran en el directorio
/etc/VRTSvcs/conf/config/en cada nodo del cluster. - Copiar todo el contenido de este directorio en un lugar seguro.
- Los archivos de configuración de recursos y grupos se encuentran en el directorio
- Realizar una copia de seguridad de otros archivos relevantes:
- Dependiendo de tu configuración específica, es posible que debas hacer una copia de seguridad de otros archivos, como scripts de inicio personalizados, archivos de configuración de aplicaciones específicas, archivos de registro, etc.
- Identifica estos archivos y copialos también en un lugar seguro.
Migración de filesystems que no están en arquitectura LVM a LVM en un cluster de Veritas que ya está dando servicio
Me encontré con un caso en el que un antiguo equipo de administración de sistemas había montado un cluster de Veritas filesystem de manera que, para poder crecer una base de datos, asignaban un disco y un filesystem asociado a ese disco para poder darle más espacio a la base de datos. El resultado es que, al cabo de los años, tenían cerca de 400 discos asignados y el cluster tardaba un buen rato en desmontarlos todos.
La manera elegante de hacer esto, es utilizando LVM y aumentando el tamaño del disco cada vez que se necesite. De esta manera, ahorras en el número de dispositivos que tiene que gestionar el sistema y el propio cluster.
Ahora que ya conocemos el escenario en que nos encontramos y a dónde queremos llegar, hay que trazar un plan para poder transformar la arquitectura de discos del cluster de NO LVM a LVM.
Planificación
- Revisión Actual: Documentaremos la configuración actual del cluster, incluyendo la asignación de discos, volumen de datos, aplicaciones en ejecución y cualquier otro recurso crítico.
- Análisis de Requisitos: Determinaremos el tamaño y la cantidad de los nuevos discos LVM que necesitaremos.
- Plan de Migración: Desarrollaremos un plan detallado que incluya:
- Un cronograma que defina cuándo se realizará la migración.
- Procedimientos de backup y estrategias de rollback en caso de que algo no vaya según lo planeado.
Preparación
- Backups: Nos aseguraremos de que todos los datos estén respaldados adecuadamente antes de realizar cualquier cambio. También haremos un backup bootable del sistema operativo con REAR.
- Adquisición de Discos: Solicitaremos los nuevos discos al equipo de Storage y nos aseguraremos de que estén correctamente configurados y visibles para el sistema (multipath).
- Comunicación: Informaremos a los usuarios y partes interesadas sobre la ventana de mantenimiento planificada y el posible tiempo de inactividad.
- Preparar el LVM: Configuraremos los VGs y filesystems con LVM. Les daremos un nombre temporal y el día de la intervención los renombraremos a su nombre actual de producción una vez copiados los datos.
Ejecución
- Parar las aplicaciones: Paramos las aplicaciones o bases de datos que estén utilizando los filesystems actuales de producción.
- Copia de datos: Copiaremos los datos de los filesystems actuales a los que tienen arquitectura LVM.
- Desmontamos los filesystems actuales
- Renombrar filesystems: Los filesystems nuevos con arquitectura LVM deben tener el nombre de producción, ya que es el que utiliza las aplicaciones (desmontaje, renombrar, montaje).
- Deshabilitaremos el Cluster: Para realizar los cambios necesarios en la configuración de almacenamiento de cluster, tendremos que pararlo.
hastop -all -force
- Actualización de Configuración del Cluster: Modificaremos la configuración de Veritas Cluster Server para que apunte a los nuevos dispositivos LVM.
Para modificar la configuración del servicio, como cambiar la configuración de los discos o filesystems, editaremos el archivo de configuración principal de VCS /etc/VRTSvcs/conf/config/main.cf. Ejemplo:
# Definir el disco (ahora será un Logical Volume)
disk disk01 (
DeviceName = "/dev/vg01/lvol1"
DiskType = LVM
)
# Definir el recurso del sistema de archivos
fs fs01 (
MountPoint = "/mnt/data"
BlockDevice = "/dev/vg01/lvol1"
FsType = vxfs
MountOpt = rw
FsckOpt = "-y"
)
# Definir el grupo de servicio y asociar los recursos
servicegroup my_data_sg (
SystemList = { sys1 = 1, sys2 = 1 }
AutoStartList = { sys1, sys2 }
)
# Asociar los recursos con el grupo de servicio
my_data_sg (
disk01
fs01
)
# Dependencias de los recursos (si es necesario)
fs01 requires disk01Verificamos el fichero de configuración con hacf -verify. Si está todo correcto, aplicamos (propagamos) los cambios con hacf -propagate.
- Pruebas: Realizaremos pruebas exhaustivas para asegurarnos de que todos los filesystems están accesibles desde todos los nodos del cluster y funcionan según lo esperado.
- Verificación Post-Migración: Verificaremos que todas las aplicaciones y servicios del cluster estén funcionando normalmente con los nuevos filesystems LVM.
En resumen, Veritas Cluster se utiliza en una amplia gama de entornos empresariales para garantizar la alta disponibilidad y el rendimiento de los recursos críticos. Su uso puede reducir el riesgo de tiempo de inactividad y pérdida de datos, lo que a su vez mejora la continuidad del negocio y la satisfacción del cliente.
Mi pasión por la tecnología me lleva constantemente a explorar las últimas tendencias y aplicaciones, buscando siempre formas de implementar soluciones innovadoras que mejoren la eficiencia. En puerto53.com comparto contenido valioso para ayudar a otros profesionales y entusiastas de la informática a navegar y dominar el complejo mundo de la tecnología. Mi especialidad en Linux RedHat.
Más sobre mí en el este enlace,
