Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

1.4. Administración de servicios de alta disponibilidad

La administración de servicios de alta disponibilidad proporcionan la habilidad de crear y administrar servicios de cluster de alta disponibilidad en un cluster de Red Hat. El componente clave de la administración de servicios de alta disponibilidad en un cluster de Red Hat es rgmanager. Este componente implementa recuperación contra fallos para aplicaciones. En un cluster de Red Hat, una aplicación es configurada con otros recursos del cluster para formar un servicio de cluster de alta disponibilidad. Un servicio de cluster de alta disponibilidad puede pasar de un nodo a otro sin ninguna interrupción aparente a los clientes de cluster. La recuperación contra fallos puede ocurrir si un nodo de cluster falla o si el administrador de sistema de cluster traslada el servicio de un nodo a otro (por ejemplo si el nodo necesita recibir tareas de mantenimiento).
Para crear un servicio de alta disponibilidad se debe configurar éste en el archivo de configuración de cluster. Un servicio de cluster consta de recursos de cluster. Los recursos de cluster son bloques de construcción que se crean y administran en el archivo de configuración de cluster — por ejemplo, una dirección IP, el script de inicialización de una aplicación o una partición compartida Red Hat GFS.
You can associate a cluster service with a failover domain. A failover domain is a subset of cluster nodes that are eligible to run a particular cluster service (refer to Figura 1.9, “Dominios de recuperación contra fallos”).

Nota

Los dominios de recuperación contra fallos no son requeridos para el funcionamiento del cluster.
Un servicio de cluster puede ser ejecutado en sólo un nodo de cluster en un momento dado para mantener la integridad de los datos. Se puede especificar la prioridad en el dominio de recuperación contra fallos, asignando niveles de prioridad a cada nodo en el dominio. El nivel de prioridad determina el orden de recuperación contra fallos — en otras palabras determina el nodo que debe reemplazar al nodo fallido. Si no se especifica la prioridad de recuperación contra fallos, un servicio de cluster puede pasar a cualquier nodo dentro del dominio. Asimismo, se puede especificar si un servicio de cluster debe ser ejecutado únicamente en los nodos de su dominio de recuperación contra fallos asociado. Cuando el servicio está asociado a un dominio de recuperación contra fallos no restringido, un servicio de cluster puede ser iniciado en cualquier nodo si no hay ningún nodo del dominio disponible.
In Figura 1.9, “Dominios de recuperación contra fallos”, Failover Domain 1 is configured to restrict failover within that domain; therefore, Cluster Service X can only fail over between Node A and Node B. Failover Domain 2 is also configured to restrict failover with its domain; additionally, it is configured for failover priority. Failover Domain 2 priority is configured with Node C as priority 1, Node B as priority 2, and Node D as priority 3. If Node C fails, Cluster Service Y fails over to Node B next. If it cannot fail over to Node B, it tries failing over to Node D. Failover Domain 3 is configured with no priority and no restrictions. If the node that Cluster Service Z is running on fails, Cluster Service Z tries failing over to one of the nodes in Failover Domain 3. However, if none of those nodes is available, Cluster Service Z can fail over to any node in the cluster.
Dominios de recuperación contra fallos

Figura 1.9. Dominios de recuperación contra fallos

Figura 1.10, “Web Server Cluster Service Example” shows an example of a high-availability cluster service that is a web server named "content-webserver". It is running in cluster node B and is in a failover domain that consists of nodes A, B, and D. In addition, the failover domain is configured with a failover priority to fail over to node D before node A and to restrict failover to nodes only in that failover domain. The cluster service comprises these cluster resources:
  • recurso de dirección IP — dirección IP 10.10.10.201.
  • An application resource named "httpd-content" — a web server application init script /etc/init.d/httpd (specifying httpd).
  • A file system resource — Red Hat GFS named "gfs-content-webserver".
Web Server Cluster Service Example

Figura 1.10. Web Server Cluster Service Example

Los clientes acceden al servicio de cluster a través de la dirección IP 10.10.10.201, permitiendo la interacción con la aplicación de servidor web, httpd-content. La aplicación httpd-content utiliza el sistema de archivos gfs-content-webserver. Si el nodo B falla, el servicio de cluster content-webserver pasa al nodo D. Si el nodo D no está disponible o falla, el servicio pasa al nodo A. La recuperación contra fallos no será perceptible por los clientes. Se podrá acceder al servicio de cluster desde otro nodo del cluster a través de la misma dirección IP que se utilizaba antes de la falla.