Diferencia entre revisiones de «Clúster de Alta Disponibilidad»
m (Texto reemplazado: «<div align="justify">» por «»)
 
(No se muestran 12 ediciones intermedias de 3 usuarios)
Línea 1: Línea 1:
−
<div align="justify">
+
 
 
{{Ficha Software
 
{{Ficha Software
−
|nombre=Clúster de Alta Disponibilidad
+
|nombre=Cluster de Alta Disponibilidad
−
|imagen=Nginx.png
+
|imagen=ClústerHA.png
 
}}
 
}}
−
'''Clúster de Alta Disponibilidad'''. Para conseguir redundancia y protección contra fallos de un sistema, la primera de las medidas que se suelen tomar es replicar sus componentes hardware más críticos. Por ejemplo en el caso de un servidor se emplean configuraciones de discos en RAID, fuentes de alimentación redundantes, varias interfaces de red en bonding, etc. Y el mismo concepto de redundancia se aplica también para el resto de componentes como la electrónica de red o el sistema eléctrico.
+
 
 +
'''Cluster de Alta Disponibilidad'''. Para conseguir redundancia y protección contra fallos de un sistema, la primera de las medidas que se suelen tomar es replicar sus componentes hardware más críticos. Por ejemplo en el caso de un servidor se emplean configuraciones de discos en RAID, fuentes de alimentación redundantes, varias interfaces de red en [[bonding]], etc. Y el mismo concepto de redundancia se aplica también para el resto de componentes como la electrónica de red o el sistema eléctrico.
 +
 
 
Estas medidas indudablemente aumentan el nivel de disponibilidad de un sistema, pero para conseguir un nivel aun mas alto, se suelen utilizar configuraciones avanzadas de hardware y software como son los clusters de Alta Disponibilidad.
 
Estas medidas indudablemente aumentan el nivel de disponibilidad de un sistema, pero para conseguir un nivel aun mas alto, se suelen utilizar configuraciones avanzadas de hardware y software como son los clusters de Alta Disponibilidad.
−
Un Cluster de Alta Disponibilidad es un conjunto de dos o mas servidores, que se caracteriza por compartir el sistema de almacenamiento, y por que están constantemente monitorizándose entre sí. Si se produce un fallo del hardware o de los servicios de alguno de las maquinas que forman el cluster, el software de alta disponibilidad es capaz de rearrancar automáticamente los servicios que han fallado en cualquiera de los otros equipos del cluster. Y cuando el servidor que ha fallado se recupera, los servicios se migran de nuevo a la máquina original.
+
 
 +
'''Un Cluster de Alta Disponibilidad''' es un conjunto de dos o mas servidores, que se caracteriza por compartir el sistema de almacenamiento, y por que están constantemente monitorizándose entre sí. Si se produce un fallo del hardware o de los servicios de alguno de las maquinas que forman el cluster, el software de alta disponibilidad es capaz de rearrancar automáticamente los servicios que han fallado en cualquiera de los otros equipos del cluster. Y cuando el servidor que ha fallado se recupera, los servicios se migran de nuevo a la máquina original.
 +
 
 
Esta capacidad de los clusters de restablecer en pocos segundos un servicio, manteniendo la integridad de los datos, permite que en muchos casos los usuarios no tengan por que notar que se ha producido un problema. Cuando una avería de este tipo, en un sistema sin cluster, podría dejarles sin servicio durante horas.
 
Esta capacidad de los clusters de restablecer en pocos segundos un servicio, manteniendo la integridad de los datos, permite que en muchos casos los usuarios no tengan por que notar que se ha producido un problema. Cuando una avería de este tipo, en un sistema sin cluster, podría dejarles sin servicio durante horas.
 
La utilización de clusters no solo es beneficiosa para caídas de servicio no programadas, si no que también es útil en paradas de sistema programadas como puede ser un mantenimiento hardware o una actualización software.
 
La utilización de clusters no solo es beneficiosa para caídas de servicio no programadas, si no que también es útil en paradas de sistema programadas como puede ser un mantenimiento hardware o una actualización software.
Línea 26: Línea 30:
 
Un recurso es una interpretación de un servicio (a veces, incluso un conjunto de servicios o demonios) que será puesto en alta disponibilidad. Para cada recurso hay un script que sabe cómo manejar los servicios que corresponden, controlar los estados, parar, arrancar, etc...
 
Un recurso es una interpretación de un servicio (a veces, incluso un conjunto de servicios o demonios) que será puesto en alta disponibilidad. Para cada recurso hay un script que sabe cómo manejar los servicios que corresponden, controlar los estados, parar, arrancar, etc...
 
A priori, un recurso se corresponde con un servicio. Esto quiere decir lo siguiente:
 
A priori, un recurso se corresponde con un servicio. Esto quiere decir lo siguiente:
−
-> Servicio http (apache) -> Recurso http (apache)
+
-> Servicio http (apache) -> Recurso http (apache)
−
-> Servicio sgbd (mysql) -> Recurso sgbd (mysql)
+
-> Servicio sgbd (mysql) -> Recurso sgbd (mysql)
−
[etc...]
+
[etc...]
 +
 
 
Una vez comprendida e interiorizada esta correspondencia podemos decir que un recurso puede ser algo mucho más completo que un servicio y que tiene características añadidas:
 
Una vez comprendida e interiorizada esta correspondencia podemos decir que un recurso puede ser algo mucho más completo que un servicio y que tiene características añadidas:
−
• Movilidad : Un servicio pertenece a una máquina. Un recurso no pertenece a una máquina concreta.
+
*Movilidad : Un servicio pertenece a una máquina. Un recurso no pertenece a una máquina concreta.
−
• Integración : Podemos conseguir un grado muy alto de integración entre distintos recursos; relaciones de localización, relaciones de orden de arranque y parada, etc...
+
*Integración : Podemos conseguir un grado muy alto de integración entre distintos recursos; relaciones de localización, relaciones de orden de arranque y parada, etc...
−
• Agrupación : Podríamos decir que un recurso en algunos casos está compuesto de varios servicios, e incluso de otros recursos.
+
*Agrupación : Podríamos decir que un recurso en algunos casos está compuesto de varios servicios, e incluso de otros recursos.
 
Así que podemos resumir que cuando hablamos de un cluster de alta disponibilidad, nos referimos que se ofrecen recursos y servicios.
 
Así que podemos resumir que cuando hablamos de un cluster de alta disponibilidad, nos referimos que se ofrecen recursos y servicios.
  
 
== Hardware necesario ==
 
== Hardware necesario ==
−
 
 
La cantidad, calidad y capacidad del hardware estará íntegramente relacionada con la dimensión del cluster a construir.
 
La cantidad, calidad y capacidad del hardware estará íntegramente relacionada con la dimensión del cluster a construir.
 
Para un firewall, es de suponer que los elementos principales de cada máquina será la RAM y las interfaces de red. Otras características como el disco duro no toman tanta importancia.
 
Para un firewall, es de suponer que los elementos principales de cada máquina será la RAM y las interfaces de red. Otras características como el disco duro no toman tanta importancia.
 
De manera genérica, para un firewall montado en un cluster necesitaremos las siguientes interfaces de red:
 
De manera genérica, para un firewall montado en un cluster necesitaremos las siguientes interfaces de red:
−
• Interfaz dedicada para la comunicación entre nodos. Recomendable usar más de una; el sistema será más completo mientras más redundancia haya.
 
−
• Interfaz dedicada a cada zona. Si estamos construyendo un firewall de tres patas, necesitaremos 3 interfaces dedicadas en cada nodo.
 
−
• En caso de bonding entre interfaces, el número se incrementa considerablemente, dado que también habrá que hacer el bonding en cada uno de los nodos del cluster.
 
  
−
'''/etc/nginx/nginx.conf'''
+
*Interfaz dedicada para la comunicación entre nodos. Recomendable usar más de una; el sistema será más completo mientras más redundancia haya.
−
+
*Interfaz dedicada a cada zona. Si estamos construyendo un firewall de tres patas, necesitaremos 3 interfaces dedicadas en cada nodo.
−
<div >
+
*En caso de [[bonding]] entre interfaces, el número se incrementa considerablemente, dado que también habrá que hacer el bonding en cada uno de los nodos del cluster.
−
user www-data;
+
 
−
worker_processes  1;
+
== Software a utilizar: Pacemaker + Corosync ==
−
error_log  /var/log/nginx/error.log;
+
 
−
pid        /var/run/nginx.pid;
+
'''Pacemaker''' este proyecto surge en el año 2007, a raíz de la segunda generación de Linux-HA. Los programadores del componente CRM de Linux-HA, deciden extraer el desarrollo y mantenimiento de este en un proyecto separado. Para que el nuevo CRM pueda utilizar como capa de comunicación no solo Heartbeat si no también OpenAIS.
−
events {
+
 
−
worker_connections  1024;
+
Pacemaker es compatible totalmente con Heartbeat, así como con los scripts de recursos existentes para este, también se ha adaptado el administrador gráfico Linux-HA para que funcione con Pacemaker.
−
# multi_accept on;
+
 
−
}
+
Pacemaker esta disponible en la mayoría de las distribuciones Linux actuales, las cuales lo han adoptado como sucesor de Heartbeat. También es la opción elegida en Suse Linux Enterprise, una de las distribuciones comerciales mas importantes en el sector corporativo.
−
http {
+
 
−
include      /etc/nginx/mime.types;
+
'''Corosync Cluster Engine''' es un proyecto open source bajo la licencia BSD, derivado del proyecto Open-AIS. El objetivo principal del proyecto es desarrollar una solución de cluster completa, certificada por la OSI (Open Source Initiative), con soporte para Linux, Solaris, BSD y MacOSX.
−
access_log        /var/log/nginx/access.log;
+
 
−
sendfile        on;
+
El proyecto se inicia en Julio de 2008, y la primera versión estable Corosync 1.0.0 se lanzó en agosto de 2009. Hasta el momento solo la distribución Fedora lo soporta oficialmente incluyendo los binarios de Corosyn en sus repositorios de paquetes.
−
#tcp_nopush    on;
+
 
−
#keepalive_timeout  0;
+
== Configuraciones de Alta Disponibilidad ==
−
keepalive_timeout  65;
+
 
−
tcp_nodelay        on;
+
Las configuraciones mas comunes en entornos de clusters de alta disponibilidad son la configuración activo/activo y la configuración activo/pasivo.
−
gzip  on;
 
−
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
 
−
include /etc/nginx/conf.d/*.conf;
 
−
include /etc/nginx/sites-enabled/*;
 
−
}
 
−
</div>
 
−
''' /etc/nginx/sites-enabled/default '''
 
−
 
−
<div >
 
−
server {
 
−
listen 80;
 
−
location / {
 
−
root /var/www/nginx-default;
 
−
index index.html;
 
−
error_page 404 /index.html;
 
−
  }
 
−
}
 
−
server {
 
−
listen 443;
 
−
access_log /var/log/nginx/access.log;
 
−
keepalive_timeout 22;
 
−
ssl on;
 
−
ssl_certificate /etc/nginx/ssl/cert.pem;
 
−
ssl_certificate_key /etc/nginx/ssl/key.pem;
 
−
ssl_session_timeout 30m;
 
−
location / {
 
−
  root /var/www/nginx-default;
 
−
  index index.html;
 
−
  error_page 404 /index.html;
 
−
  }
 
−
}
 
−
</div>
 
  
−
''' /etc/nginx/conf.d/proxy.conf '''
+
==Configuración Activo/Activo ==
−
<div >
+
{| width="80" cellspacing="1" cellpadding="1" border="0"
 +
|-
 +
| [[Image:ClústerAA.png|left|200x200px|ClústerActivo/Activo]]<br>
 +
|}
 +
En una configuración activo/activo, todos los servidores del cluster pueden ejecutar los mismos recursos simultáneamente. Es decir, los servidores poseen los mismos recursos y pueden acceder a estos independientemente de los otros servidores del cluster. Si un nodo del sistema falla y deja de estar disponible, sus recursos siguen estando accesibles a través de los otros servidores del cluster.
 +
La ventaja principal de esta configuración es que los servidores en el cluster son mas eficientes ya que pueden trabajar todos a la vez. Sin embargo, cuando uno de los servidores deja de estar accesible, su carga de trabajo pasa a los nodos restantes, lo que produce una degradación del nivel global de servicio ofrecido a los usuarios.
 +
En la siguiente figura se muestra como ambos servidores están activos, proporcionando un mismo servicio a los diferentes usuarios. Los clientes acceden al servicio o recursos deforma transparente y no tienen conocimiento de la existencia de varios servidores formando un cluster.
  
−
# configuraciones globales para proxy inverso
+
== Configuración Activo/Pasivo ==
−
proxy_redirect            off;
+
{| width="80" cellspacing="1" cellpadding="1" border="0"
−
proxy_set_header          X-Real-IP        $remote_addr;
+
|-
−
proxy_set_header          X-Forwarded-For  $proxy_add_x_forwarded_for;
+
| [[Image:ClústerAP.png|left|200x200px|ClústerActivo/Pasivo]]<br>
−
proxy_intercept_errors    on;
+
|}
−
proxy_connect_timeout      12s;
+
Un cluster de alta disponibilidad, en una configuración activo/pasivo, consiste en un servidor que posee los recursos del cluster y otros servidores que son capaces de acceder a esos recursos, pero no los activan hasta que el el propietario de los recursos ya no este disponible.
−
proxy_send_timeout        90s;
+
Las ventajas de la configuración activo/pasivo son que no hay degradación de servicio y que los servicios solo se reinician cuando el servidor activo deja de responder. Sin embargo, una desventaja de esta configuración es que los servidores pasivos no proporcionan ningún tipo de recurso mientras están en espera, haciendo que la solución sea menos eficiente que el cluster de tipo activo/activo. Otra desventaja es que los sistemas tardan un tiempo en migrar los recursos ([[failover]]) al nodo en espera.
−
proxy_read_timeout        90s;
 
−
proxy_buffer_size          4k;
 
−
proxy_buffers              4 32k;
 
−
proxy_busy_buffers_size    64k;
 
−
proxy_temp_file_write_size 64k;
 
−
client_body_buffer_size    128k;
 
−
client_max_body_size      600M;
 
−
</div>
 
  
−
''' /etc/nginx/sites-enabled/correo '''
+
== Funcionamiento de un cluster de alta disponibilidad ==
−
<div >
+
En un cluster de alta disponibilidad, el software de cluster realiza dos funciones fundamentales. Por un lado intercomunica entre sí todos los nodos, monitorizando continuamente su estado y detectando fallos. Y por otro lado administra los servicios ofrecidos por el cluster, teniendo la capacidad de migrar dichos servicios entre diferentes servidores físicos como respuesta a un fallo.
−
# ejemplo de cluster [[roundrobind]]
 
−
server {
 
−
  listen 80;
 
−
  server_name correo.midominio;
 
−
  rewrite ^(.*) https://$host$1 permanent;
 
−
}
 
−
# aqui definimos el cluster de los nodos
 
−
upstream appclustercorreo {
 
−
  server 12.0.0.30 fail_timeout=20;
 
−
  server 12.0.0.31 fail_timeout=20;
 
−
}
 
−
server {
 
−
  listen 443;
 
−
  server_name correo.midominio;
 
−
  access_log /var/log/nginx/access.log;
 
−
  keepalive_timeout 22;
 
−
  ssl on;
 
−
  ssl_certificate /etc/nginx/ssl/cert.pem;
 
−
  ssl_certificate_key /etc/nginx/ssl/key.pem;
 
−
  ssl_client_certificate /etc/nginx/ssl/cacert.pem;
 
−
  ssl_session_timeout 30m;
 
−
  location / {
 
−
  proxy_pass http://appclustercorreo; # hacemos la llamada al nombre que definimos en el cluster de nodos
 
−
    proxy_set_header Host correo.midominio;;
 
−
    error_page 500 502 503 504 /50x.html;
 
−
  }
 
−
  location = /50x.html {
 
−
    root /var/www/nginx-default;
 
−
  }
 
−
}
 
  
 
</div>
 
</div>
 +
 
== Fuentes ==
 
== Fuentes ==
−
*http://nginx.org
+
*Artículo [[http://informatica.gonzalonazareno.org/proyectos 2010-11proyecto_integrado_arturo_borrero_pdf.pdf Proyecto Integrado:
−
*Artículo [https://www.dhis2.org/doc/snapshot/es/implementer/html/ch08s02.html Configuración de proxy inverso]. Disponible en: "https://www.dhis2.org" Consultado el 30 de noviembre de 2014
+
"Firewall en cluster de alta disponibilidad"]]. Disponible en: "http://informatica.gonzalonazareno.org" Consultado el 13 de enero de 2015
−
*Artículo [http://www.tail-f.com.ar/servicios/httpd/nginx/nginx-como-proxy-reverso-en-servidor-directadmin.html Nginx como Proxy Reverso en servidor Directadmin]. Disponible en: "http://www.tail-f.com.ar" Consultado el 30 de noviembre de 2014
+
*Artículo [[http://www.lintips.com/?q=node/119 Clusters de Alta Disponibilidad (HA)]] . Disponible en: "http://www.lintips.com" Consultado el 13 de enero de 2015
−
*Artículo  [http://only19.wordpress.com/2009/11/26/proxy-inverso-con-nginx-y-apache Integración de servidores web: Proxy inverso con nginx y apache]. Disponible en: "http://only19.wordpress.com" Consultado el 30 de noviembre de 2014
+
*Artículo  [[https://albertomolina.wordpress.com/2012/03/04/sencillo-cluster-de-alta-disponilidad-con-pacemaker-y-corosync/: Sencillo cluster de alta disponibilidad con Pacemaker y Corosync]]. Disponible en: "http://albertomolina.wordpress.com" Consultado el 30 de noviembre de 2014
−
*Artículo [http://ordenador.wingwit.com/Redes/internet-networking/70962.html#.VH35hPun8wo Definición de un servidor proxy inverso]. Disponible en: "http://ordenador.wingwit.com" Consultado el 30 de noviembre de 2014
 
  
  
−
[[Category:Informática]][[Category:Software]]
+
[[Category:Informática]]

última versión al 15:30 20 jun 2019

Cluster de Alta Disponibilidad
Información sobre la plantilla
ClústerHA.png

Cluster de Alta Disponibilidad. Para conseguir redundancia y protección contra fallos de un sistema, la primera de las medidas que se suelen tomar es replicar sus componentes hardware más críticos. Por ejemplo en el caso de un servidor se emplean configuraciones de discos en RAID, fuentes de alimentación redundantes, varias interfaces de red en bonding, etc. Y el mismo concepto de redundancia se aplica también para el resto de componentes como la electrónica de red o el sistema eléctrico.

Estas medidas indudablemente aumentan el nivel de disponibilidad de un sistema, pero para conseguir un nivel aun mas alto, se suelen utilizar configuraciones avanzadas de hardware y software como son los clusters de Alta Disponibilidad.

Un Cluster de Alta Disponibilidad es un conjunto de dos o mas servidores, que se caracteriza por compartir el sistema de almacenamiento, y por que están constantemente monitorizándose entre sí. Si se produce un fallo del hardware o de los servicios de alguno de las maquinas que forman el cluster, el software de alta disponibilidad es capaz de rearrancar automáticamente los servicios que han fallado en cualquiera de los otros equipos del cluster. Y cuando el servidor que ha fallado se recupera, los servicios se migran de nuevo a la máquina original.

Esta capacidad de los clusters de restablecer en pocos segundos un servicio, manteniendo la integridad de los datos, permite que en muchos casos los usuarios no tengan por que notar que se ha producido un problema. Cuando una avería de este tipo, en un sistema sin cluster, podría dejarles sin servicio durante horas. La utilización de clusters no solo es beneficiosa para caídas de servicio no programadas, si no que también es útil en paradas de sistema programadas como puede ser un mantenimiento hardware o una actualización software.

Razones para implementar un cluster HA

  • Aumentar la disponibilidad
  • Mejorar el rendimiento
  • Escalabilidad
  • Tolerancia a fallos
  • Recuperación ante fallos en tiempo aceptable
  • Reducir costes
  • Consolidar servidores
  • Consolidar el almacenamiento

Concepto importante: recurso

Lo primero que vamos a encontrar al trabajar con un cluster de alta disponibilidad es un recurso. Es fundamental comprender el concepto de recurso, porque nos abrirá la puerta a entendernos con lo que hay detrás y con las posibilidades de configuración Un recurso es una interpretación de un servicio (a veces, incluso un conjunto de servicios o demonios) que será puesto en alta disponibilidad. Para cada recurso hay un script que sabe cómo manejar los servicios que corresponden, controlar los estados, parar, arrancar, etc... A priori, un recurso se corresponde con un servicio. Esto quiere decir lo siguiente: 

-> Servicio http (apache) -> Recurso http (apache)
-> Servicio sgbd (mysql) -> Recurso sgbd (mysql)
[etc...]

Una vez comprendida e interiorizada esta correspondencia podemos decir que un recurso puede ser algo mucho más completo que un servicio y que tiene características añadidas:

  • Movilidad : Un servicio pertenece a una máquina. Un recurso no pertenece a una máquina concreta.
  • Integración : Podemos conseguir un grado muy alto de integración entre distintos recursos; relaciones de localización, relaciones de orden de arranque y parada, etc...
  • Agrupación : Podríamos decir que un recurso en algunos casos está compuesto de varios servicios, e incluso de otros recursos.

Así que podemos resumir que cuando hablamos de un cluster de alta disponibilidad, nos referimos que se ofrecen recursos y servicios.

Hardware necesario

La cantidad, calidad y capacidad del hardware estará íntegramente relacionada con la dimensión del cluster a construir. Para un firewall, es de suponer que los elementos principales de cada máquina será la RAM y las interfaces de red. Otras características como el disco duro no toman tanta importancia. De manera genérica, para un firewall montado en un cluster necesitaremos las siguientes interfaces de red:

  • Interfaz dedicada para la comunicación entre nodos. Recomendable usar más de una; el sistema será más completo mientras más redundancia haya.
  • Interfaz dedicada a cada zona. Si estamos construyendo un firewall de tres patas, necesitaremos 3 interfaces dedicadas en cada nodo.
  • En caso de bonding entre interfaces, el número se incrementa considerablemente, dado que también habrá que hacer el bonding en cada uno de los nodos del cluster.

Software a utilizar: Pacemaker + Corosync

Pacemaker este proyecto surge en el año 2007, a raíz de la segunda generación de Linux-HA. Los programadores del componente CRM de Linux-HA, deciden extraer el desarrollo y mantenimiento de este en un proyecto separado. Para que el nuevo CRM pueda utilizar como capa de comunicación no solo Heartbeat si no también OpenAIS.

Pacemaker es compatible totalmente con Heartbeat, así como con los scripts de recursos existentes para este, también se ha adaptado el administrador gráfico Linux-HA para que funcione con Pacemaker.

Pacemaker esta disponible en la mayoría de las distribuciones Linux actuales, las cuales lo han adoptado como sucesor de Heartbeat. También es la opción elegida en Suse Linux Enterprise, una de las distribuciones comerciales mas importantes en el sector corporativo.

Corosync Cluster Engine es un proyecto open source bajo la licencia BSD, derivado del proyecto Open-AIS. El objetivo principal del proyecto es desarrollar una solución de cluster completa, certificada por la OSI (Open Source Initiative), con soporte para Linux, Solaris, BSD y MacOSX.

El proyecto se inicia en Julio de 2008, y la primera versión estable Corosync 1.0.0 se lanzó en agosto de 2009. Hasta el momento solo la distribución Fedora lo soporta oficialmente incluyendo los binarios de Corosyn en sus repositorios de paquetes.

Configuraciones de Alta Disponibilidad

Las configuraciones mas comunes en entornos de clusters de alta disponibilidad son la configuración activo/activo y la configuración activo/pasivo.

Configuración Activo/Activo

ClústerActivo/Activo

En una configuración activo/activo, todos los servidores del cluster pueden ejecutar los mismos recursos simultáneamente. Es decir, los servidores poseen los mismos recursos y pueden acceder a estos independientemente de los otros servidores del cluster. Si un nodo del sistema falla y deja de estar disponible, sus recursos siguen estando accesibles a través de los otros servidores del cluster. La ventaja principal de esta configuración es que los servidores en el cluster son mas eficientes ya que pueden trabajar todos a la vez. Sin embargo, cuando uno de los servidores deja de estar accesible, su carga de trabajo pasa a los nodos restantes, lo que produce una degradación del nivel global de servicio ofrecido a los usuarios. En la siguiente figura se muestra como ambos servidores están activos, proporcionando un mismo servicio a los diferentes usuarios. Los clientes acceden al servicio o recursos deforma transparente y no tienen conocimiento de la existencia de varios servidores formando un cluster.

Configuración Activo/Pasivo

ClústerActivo/Pasivo

Un cluster de alta disponibilidad, en una configuración activo/pasivo, consiste en un servidor que posee los recursos del cluster y otros servidores que son capaces de acceder a esos recursos, pero no los activan hasta que el el propietario de los recursos ya no este disponible. Las ventajas de la configuración activo/pasivo son que no hay degradación de servicio y que los servicios solo se reinician cuando el servidor activo deja de responder. Sin embargo, una desventaja de esta configuración es que los servidores pasivos no proporcionan ningún tipo de recurso mientras están en espera, haciendo que la solución sea menos eficiente que el cluster de tipo activo/activo. Otra desventaja es que los sistemas tardan un tiempo en migrar los recursos (failover) al nodo en espera.

Funcionamiento de un cluster de alta disponibilidad

En un cluster de alta disponibilidad, el software de cluster realiza dos funciones fundamentales. Por un lado intercomunica entre sí todos los nodos, monitorizando continuamente su estado y detectando fallos. Y por otro lado administra los servicios ofrecidos por el cluster, teniendo la capacidad de migrar dichos servicios entre diferentes servidores físicos como respuesta a un fallo.

Fuentes

"Firewall en cluster de alta disponibilidad"]]. Disponible en: "http://informatica.gonzalonazareno.org" Consultado el 13 de enero de 2015

Obtenido de «https://www.ecured.cu/index.php?title=Clúster_de_Alta_Disponibilidad&oldid=3417620»