Clúster de Alta Disponibilidad

Clúster de Alta Disponibilidad

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. 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.

/etc/nginx/nginx.conf

user www-data;
worker_processes  1;
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
events {
worker_connections  1024;
# multi_accept on;
}
http {
include       /etc/nginx/mime.types;
access_log        /var/log/nginx/access.log;
sendfile        on;
#tcp_nopush     on;
#keepalive_timeout  0;
keepalive_timeout  65;
tcp_nodelay        on;
gzip  on;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}

/etc/nginx/sites-enabled/default

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;
 }
}

/etc/nginx/conf.d/proxy.conf

# configuraciones globales para proxy inverso
proxy_redirect             off;
proxy_set_header           X-Real-IP        $remote_addr;
proxy_set_header           X-Forwarded-For  $proxy_add_x_forwarded_for;
proxy_intercept_errors     on;
proxy_connect_timeout      12s;
proxy_send_timeout         90s;
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;

/etc/nginx/sites-enabled/correo

# 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;
 }
}

Fuentes

• http://nginx.org
• Artículo Configuración de proxy inverso. Disponible en: "https://www.dhis2.org" Consultado el 30 de noviembre de 2014
• Artículo Nginx como Proxy Reverso en servidor Directadmin. Disponible en: "http://www.tail-f.com.ar" Consultado el 30 de noviembre de 2014
• Artículo 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 Definición de un servidor proxy inverso. Disponible en: "http://ordenador.wingwit.com" Consultado el 30 de noviembre de 2014