Al día de hoy ningun server deployado en funciones de misión crítica debería correr fuera de un esquema de - al menos - alta disponibilidad, es decir, hablemos de clusters.
Primero el contexto, hablamos aquí de - tres - servers físicos en configuración de failover cluster, activo / pasivo.
El más famoso tipo de cluster a nivel empresarial/organizacional es el failover cluster. Básicamente tendremos dos servers idénticos (bah, iguales), cargados con el mismo software y configuraciones, compartiendo - de algun modo - el espacio de almacenamiento; típicamente y desde lo más recomendable, algun tipo de storage SAN, hardware o "amañado" - ya vamos a hablar de eso - aunque se puede recurrir a replicación (no hay un storage externo a los servers, pero hay en pie un soft que replica el contenido de los discos entre ambos servidores físicos).
Hay otros tipos de clusters muy interesantes - loadbalancers, la especialidad del devop típico por ejemplo - y pueden cultivarse por demás en los links de abajo, sigo con los failover clusters aquí.
El objetivo primario del failover cluster es que si un server físico se "cae" (el OS deja de responder, quema, explota, apaga por razones desconocidas, etc. etc.), el otro server físico automáticamente va a tomar el lugar del primero y el servicio que brinde el cluster seguirá proporcionandose a los clientes del mismo (que permanecerán gloriosamente ajenos al drama de recuperar el nodo primario caído).
El caso de uso por excelencia de un failover cluster es para servidores de base de datos, más o menos el corazón operativo de la mayoría de las aplicaciones de una organización.
Imagínense un servidor de base de datos de misión crítica, deployado fuera de un cluster...
Tenemos un array de 10 discos en RAID 6, que se banca perder hasta 2 discos del array sin fallar, doble procesador, triple procesador (ironía), 64 GB de memoria en 16 bancos de 2 gigas (ironía), podemos tener cierta redundancia para conectividad al agrupar placas de red en bonding (X tipo, a piacere del administrador o por disposición de policies, según el "shop" donde esté el server), etc. ...pero, tenemos una sola placa madre, forzosamente los 10 discos del RAID6 dependen de una sola placa controladora;
[¿se puede armar un RAID6 por hardware con redundancia de placas controladoras? Si se puede, los aportes de información son bienvenidos]
Solamente por tener una sola placa madre en el server, sosteniendo la función de misión crítica de la que depende una organización, es mandatorio configurar ese server de base de datos en un failover cluster.
Para clustering hay muchas y diversas tecnologías. La arquitectura del failover cluster típico consiste en un par de servers de "procesamiento" (nodo primario y nodo secundario), uno - el nodo primario - de los cuales va a estar trabajando efectivamente hasta que se produzca el evento que ponga en acción el otro - el nodo secundario. Ambos van a compartir espacio de storage, es decir, van a "ver" las mismas "particiones".
¿Cómo es que van a ver las mismas "particiones"? Muy simple, la arquitectura incluye - en gral. - un tercer server, que brinda el espacio de almacenamiento o storage compartido que el cluster va a utilizar.
En realidad el storage compartido podría ser un dispositivo de storage real, una SAN, pero, son bastante caras en vista a configurar el failover cluster básico del que estamos hablando (que ya se ocupa 2 servers físicos para una sola función), por lo que típicamente se busca utilizar algun buen server con mucha redundancia en RAID.
[ Vamos a buscarle el pero a esto: este tercer server también tiene una placa madre verdad? bien, es cierto. En este punto ya podríamos hablar de elevar la redundancia del storage compartido, ahora sí, configurando filesystems replicados entre ambos servidores de un cluster que brinde storage compartido al failover cluster original.]
Es bastante fácil configurar esta arquitectura tanto en Windows Server como en Linux y es muy recomendable hacerlo. Redundo, pocos aventureros - involuntarios en los peores casos - corren conscientemente servers de misión crítica fuera de un esquema de alta disponibilidad.
Si en este punto surgiera hablar de virtualización, ¿qué hacemos si los servers no son físicos y corren sobre hipervisores? Aquí la redundancia se puede arreglar de formas más "variadas" que en el mundo físico, por ejemplo, a nivel de la virtualización, teniendo los servers del cluster en diferentes hipervisores (distintos servers físicos), con el obvio cálculo obligado de overheads sumados que pueda encontrar, o si estamos ya en una infraestructura virtual completa, tal vez no sea necesario configurar el cluster en más de un hipervisor (corriendo ambos servers sobre el mismo hardware), pero de vuelta volcando la función de redundancia en la infraestructura virtual mediante funciones de replicación en background (copiando en background ambas máquinas virtuales de un hipervisor a otro), y hot-standby de máquinas virtuales (permitiendo que el hipervisor secundario, de respaldo corra las máquinas virtuales del cluster en caso de un fallo del hardware físico que sostiene al hipervisor primario).
..en fin,
¿Alguien puede aportar links de howtos simples de failover clusters (active / pasive) para RHEL, Ubuntu, etc.?
Porque encontré un par, pero me parece que sería lectura obligada el pdf de la documentación oficial de RHEL.
En los links de abajo pueden ver diversos tutoriales que recopilé, para Win 2008 Server y Linux (Ubuntu y RHEL).
Windows Server
Windows Server 2008 Clustering Whitepapershttp://www.microsoft.com/en-us/download/details.aspx?id=13153
Para leer:
Overview of Failover Clustering with Windows Server 2008.doc
Windows Server 2008 Failover Clustering Architecture Overview.doc
WS2008 Failover Clustering Datasheet.doc
Failover Clusters in Windows Server 2008 R2
http://technet.microsoft.com/en-us/library/ff182338(v=ws.10).aspx
Creando un Cluster de Windows Server 2008 (Parte 1)
http://blogs.technet.com/b/ponicke/archive/2007/10/08/creando-un-cluster-de-windows-server-2008-parte-1.aspx
Creando un Cluster de Windows Server 2008 (Parte 2)
http://blogs.technet.com/b/ponicke/archive/2007/10/09/creando-un-cluster-de-windows-server-2008-parte-2.aspx
Creando un clúster de alta disponibilidad en Microsoft Windows Server 2008
http://www.bujarra.com/?p=2290
(este otro es un requisito para el tutorial anterior)
Creando un iSCSI Target en Windows Unified Data Storage Server
http://www.bujarra.com/?p=2234
Linux (Ubuntu)
(este es nuevito, del 12 de abril 2012)Simple Apache failover cluster on Ubuntu with config synchronization
http://laurentbel.com/2012/04/12/simple-apache-failover-cluster-on-ubuntu-with-config-synchronization/
Linux (RHEL)
Red Hat Enterprise Linux Cluster, High Availability, and GFS Deployment Best Practiceshttps://access.redhat.com/knowledge/articles/40051
[Nunca está de más leer primero el título "Unsupported Items", antes de empezar a investigar diferentes enfoques posibles en el montaje de un cluster RHEL, así evitaremos montar configuraciones no soportadas oficialmente.]
Red Hat Enterprise Linux 6 - Cluster Administration
Configuring and Managing the High Availability Add-On
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Cluster_Administration/index.html
(este bien se puede implementar en RHEL)
How To Set Up An Active/Passive PostgreSQL Cluster With Pacemaker, Corosync, And DRBD (CentOS 5.5)
http://www.howtoforge.com/how-to-set-up-an-active-passive-postgresql-cluster-with-pacemaker-corosync-and-drbd-centos-5.5
(este viejito me gustó por el detalle que tiene la narración, obviamente está outdated respecto de nuevas versiones de RHEL, y ni hablar de que hay que darle una revisión detallada para no utilizar algun esquema no soportado oficialmente)
Redhat Cluster 4 how-to
http://unixnotebook.blogspot.com.ar/2005/07/redhat-cluster-4-how-to.html
(este no me pareció muy completo en realidad)
RedHat Cluster Suite And Conga - Linux Clustering
http://www.howtoforge.com/redhat-cluster-suite-and-conga-linux-clustering
No hay comentarios:
Publicar un comentario