Cluster Alta disponibilidad en LINUX En este articulo aprenderemos a implementar un Cluster de Alta disponibilidad (AD).

Material necesario:

2 maquinas con Linux El paquete Heardbeat un Sistema de ficheros con Journaling Una Red Puerto serie Qu es un Cluster y para que me sirve? Un cluster , consiste en un grupo de nodos conectados entre si que interactuan como una sola maquina (En caso que un nodo dejase de funcionar tomara el control el segundo nodo) , reduciendo as considerablemente la tolerancia a fallos y cadas de servicio. Un cluster podra servir perfectamente en el caso de un problema de Hardware nuestros clientes tendran igualmente servicio ya que uno de los nodos tomara el control como maquina primaria. Qu es Heartbeat? Heartbeat es un paquete de software creado por LINUX-HA, funciona de forma similar al System V o init pero en vez de una sola mquina pasara a ejecutar los servicios en los nodos, basndose en que no le llegan respuestas estas se hacen por medio de ping y por pulsaciones del cable serie. Que es STONITH? STONITH son la Siglas de Shoot The Other Node In The Head ( Pgale un Tiro en la Cabeza al otro Nodo). Es una tcnica usada por Heartbeat que se asegura de que un servidor supuestamente muerto no interfiera con el funcionamiento del cluster, en caso de no implementarse bien esta tcnica, podra dar lugar a que el cluster no funcione. A grosso modo STONITH consiste en que el servidor secundario nota que el primario no funciona, y este le hara un DDOS al primario para asegurarse de que ha sido un falso positivo y tomara el nodo secundario el control. Preparando el Hardware Existen 3 cosas especificas del cluster que hay que conectar, los discos, las NICs de interconexin, el cable serial de interconexin y los cables de control de los UPS

Primero instalaremos los discos, pero no crearemos aun ningn sistema de ficheros. Instalaremos las NICs y las configuraremos con IPs privadas de la misma subred en los rangos 192.168.0.0/16 o el rango 10.0.0/8

A continuacin nos haremos con un cable Serial para la comunicacin PC a PC . Nos aseguraremos de que el cable incluya modems null y que incluya cables CTS Y RTS Conectamos cada ordenador a su UPS Instalacin del Software Para nuestro cluster necesitaremos varios paquetes de software. Heartbeat-1.0.3, Heartbeat-pils-1.0.3, Heartbeat-stonith-1.0.3 cada uno de ellos se encuentra en los repositorios de las distribuciones o se incluye como paquete en los CDs de instalacin de esta ( Cuando instale SUSE 9.3 me pareci verlos en la instalacin) si no los encontris podis mirar en http://linux-ha.org los paquetes los instalaremos usando nuestro administrador de paquetes favoritos ya sea apt-get, yast,urpmi, emerge, etc. Por ultimo nos queda instalar el servicio que queramos dar ya sea samba,apache postfix, etc. Configurando DRBD. DRBD se configura en el fichero /etc/drbd.conf Cdigo: resource drbd0 { protocol=C fsckcmd=/bin/true disk { disk-size=80418208 do-panic } net { sync-rate=8M # bytes/sec timeout=60 connect-int=10 ping-int=10 } on Zeus { # Zeus es el nombre del servidor principal device=/dev/nb0 disk=/dev/hda1 address=192.168.1.1 port=7789 } on SolarUX { #SolarUX es el nombre del servidor secundario device=/dev/nb0 disk=/dev/hda1 address=192.168.1.2 port=7789 } } Nota: Para calcular el tamao del disco usaremos blockdev-getsize y dividiremos el resultado por dos si ambas partes dan resultado diferente elegiremos el mas grande Creando el Sistema de Ficheros A continuacin crearemos el sistema de ficheros para Zeus ( Servidor Primario) es importante usar un sistema de ficheros con Journaling como Reiserfs, ext3, jfs, xfs. Crearemos dos particiones del mismo tamao en el dispositivo /dev/nb0 los dos servidores y con Reiserfs ya que se considera mas seguro. Instrucciones a ejecutar en Zeus Cdigo: Root@Zeus:~# /etc/init.d/drbd startLe respondemos yes para que nos ponga a

Zeus como primario. ahora creamos el sistema de ficheros y lo montamos Cdigo: Root@Zeus:~# mkfs -t reiserfs /dev/nb0 datadisk /dev/nb0 startpor ltimo si usamos una conexin Ethernet de 1Gb para la sincronizacin, cambiaremos los parmetros los parmetros de esta para que nos funcione en modo fullduplex ver Activando Fullduplex en tarjetas ethernet en este mismo foro Configurando Heartbeat Heartbeat tiene tres ficheros de configuracin. 1. ha.cf Configura informacin bsica del cluster 2. haresources.cf Configura los grupos de recursos tipo init 3. authkeys Configura la Autenticacin de red Se pueden encontrar ejemplos de estos ficheros en /usr/share/doc/pakages/Heartbeat y se documentan en el fichero Getting Started de Heartbeat ha.cf le aporta a Heartbeat la informacin de la configuracin bsica. Configura los nodos, pulsaciones serial, la manera de registrar los logs intervalo de tiempo muerto y pulsaciones ejemplo de nuestro ha.cf Cdigo: logfacility local7 # servicio de syslog keepalive 1 #Intervalo pulsacin warntime 2 #Pulsacin Tarda deadtime 10 # Tiempo control Fallos nice_failback on node Zeus SolarUX ping 10.10.10.254 # Direccin del Router bcast eth0 eth1 #Broadcast Interfaces Heartbeat serial /dev/ttyS0 #Enlace Serial Heartbeat respawn /usr/lib/Heartbeat/ipfail stonith_host Zeus apcsmart SolarUX /dev/ttyS1 stonith_host SolarUX apcsmart Zeus /dev/ttyS1las pulsaciones se envan por eth0, eth1 y serial /dev/ttyS0 este fichero es idntico para todos los nodos Fichero /etc/ha.d/haresources Este fichero crea un grupo de recursos que en teora pertenecen a Zeus, asociados a una IP virtual 10.10.10.20 y los recursos a servir: NFS (Network File System) Samba (compartir archivos Windows) Dhcp (asignacin dinmica de IPs) Postfix (Servidor de Correo electrnico)

Cdigo: Zeus 10.10.10.20 datadisk::drbd0 nfslock nfsserver smb dhcpd postfixPara clarificar donde estn colocados los scripts dir que Ipaddr y datadisk estn en /etc/ha.d/resource.d y el resto de servicios tpicos en /etc/init.d/ Heartbeat se las apaa de maravilla administrando la mayora de servicios que vienen en los V System init comnmente llamados los scripts de arranque, sin embargo una de las condiciones para que Heartbeat administre correctamente los Scripts es que tienen de tener el mismo nombre en todos

los Nodos, por lo tanto recomiendo usar una distribucin idntica en las dos maquinas as simplificaremos la configuracin y el mantenimiento. Fichero /etc/ha.d/authkeys authkeys es el fichero de configuracin mas sencillo de todos. Contiene el mtodo de autenticacin basado en (sha1) con la clave que se usara para firmar los paquetes . este fichero tiene que ser idntico en todos los servidores y no debe tener ningn usuario acceso de lectura a excepcin de root: Cdigo: auth 1 1 sha1 RandomPasswordfc970c94efbConfiguracin de los Servicios Tenemos de deshabilitar los servicios para que no sean controlados por init si no por Heartbeat esto lo conseguiremos con el siguiente comando: Cdigo: Root@Zeus:~# chkconfig -del nfslock nfsserver smb dhcpd postfixNtese que deberamos cambiar los servicios marcados en azul por los que tenemos configurados en /etc/ha.d/haresources para servir. Configurando /etc/fstab Tenemos de tener especial cuidado en que la particin /home no se monte automticamente desde /etc/fstab si existe ya una entrada para /home en dicho fichero la eliminamos y creamos esta: Cdigo: /dev/nb0 /home reiserfs noauto 0 0Nota: si home ya esta montado lo desmontamos con umount /home Configuracin del Fichero /etc/hosts Si no tenemos un servidor DNS corriendo en nuestra red tendremos de usar nuestro archivo /etc/hosts quedando de esta manera: Cdigo: 10.10.10.20 Cluster # IP virtual cluster 192.168.1.1 Zeus #Servidor Primario 192.168.1.2 SolarUX # Servidor Segundario (Nodo)Montando todo el Cotarro Ahora es el momento de configurar el servidor segundario para que monte /home desde NFS aadiendo lo siguiente en /etc/fstab Cdigo: Cluster:/home /home nfs defaults 0 0Una vez la particin NFS montada creamos el directorio /home/HA.config y creamos la siguiente estructura de directorios: Cdigo: /etc postfix/ samba/ exports dhcpd.conf /var lib/ dhcpd samba nfs spool/ postfix/ mail/Despus de montar la estructura de directorios tendramos que crear enlaces simblicos por ejemplo Cdigo: ln -s /home/HA.config/etc/samba/smb.cf /etc/samba/smb.cfAhora desmontamos

/home de la siguiente forma: Cdigo: Root@Zeus:~# datadisk /dev/nb0 stop Root@Zeus:~# /etc/init.d/drbd stopTambin podemos configurar samba para que escuche en la interface del cluster modificando dentro de la directiva [ global ] de /etc/samba/smb.cf Cdigo:

Opciones de alta disponibilidad para Exchange 2007 - parte 1 Es, quizs, uno de los requerimientos ms solicitados por todos. Tener una alta disponibilidad de servicio de correo y con menor costo. No todas las organizaciones estn preparadas para afrontar los costos asociados con las opciones de alta disponibilidad que ofrecen las versiones anteriores de Exchange, por lo tanto en esta nueva versin se establecen nuevas.

La primer opcin se llama Local Continuous Replication (o LCR). Esta solucin implica un slo servidor que usa tecnologa de Log Shipping para crear y mantener una copia de un Storage Group en un segundo set de discos, que estn conectados al mismo servidor que el Storage Group. LCR provee log shipping, log replay y la posibilidad de switchear rpidamente a la copia de la base. La segunda opcin es Cluster Continuous Replication (CCR). Es una solucin de cluster que utiliza la misma tecnologa de log shipping que LCR, pero el Storage Group se mantiene en un servidor separado. CCR fue diseado para estar en el mismo datacenter o en uno remoto, brindando no slo alta disponibilidad de hardware sino tambin de sitios. Por ltimo tenemos Single Copy Cluster (SCC). Es una solucin de cluster que usa una sla copia del Storage Group en un storage compartido entre los nodos del cluster. SCC es muy similar a las opciones de cluster de las versiones anteriores de Exchange, con algunos cambios y mejoras. Tanto CCR como SCC son soluciones que se aplican a cluster con failover. Slo el rol de Mailbox Server puede ser instalado en esos servidores. Todas las opciones de alta disponibilidad de los roles restantes se pueden obtener con una combinacin de redundancia de servidores, Network Load Balancing o DNS Round Robin. Opciones de alta disponibilidad para Exchange 2007 - parte 2 Siendo la primer opcin en la parte 1 de esta serie de notas, nos centraremos en LCR (Local Continuous Replication). LCR es una solucin que involucra un slo servidor y hace uso de la tecnologa de Log Shipping y Log Replay built in en Exchange 2007 para crear y mantener actualizada una copia de un Storage Group determinado en un segundo set de discos, conectados al mismo servidor. Esta tecnologa podra graficarse de la siguiente manera:

LCR nos da la posibilidad de, manualmente, switchear a la copia pasiva de las bases de un Storage Group determinado ante una fatalidad. Esta tecnologa fue bsicamente diseada para:

Reducir considerablemente el tiempo de recuperacin por un error a nivel datos. Reducir el nmero de full backups requeridos para una ptima proteccin de la informacin. Reducir el impacto de backups en el rendimiento del servidor. Todos los tipos de backups (full, incremental, diferencial y copia) pueden ser tomados de la copia pasiva del Storage Group. Cuando sea necesario la copia local del Storage Group pasivo puede convertirse en la productiva. LCR no tiene requerimientos especficos de Storage, todos los medios soportados sirven. LCR es la opcin ideal para aquellas empresas o redes que necesitan soluciones de Disaster Recovery rpidas ante fallas o corrupcin en los buzones. Aunque LCR provea ciertas ventajas ante un backup tradicional, no provee una disponibilidad completa. Bsicamente porque reside en un mismo servidor, y lo nico que lo separa de la base productiva es subsistema de discos distintos. LCR ser la primer barrera ante una falla en la base de datos productiva y un recovery generalmente toma unos 10 minutos nicamente. Teniendo este tiempo de restore tan bajo, podemos empezar a pensar en cuotas de buzones mucho mayores. Requerimientos LCR tiene algunos requerimientos de storage y recomendaciones. Justamente una de las recomendaciones es que el storage que almacenar la copia pasiva sea de la misma capacidad y mismo rendimiento que el de la copia activa. Alguna de las mejores prcticas incluyen:

Utilizar una sola base de datos por Storage Group. Cuando se habilita LCR en un Storage Group, ste slo puede contener una sla base de datos. No se podr utilizar LCR en Public Folders si existe ms de una base de datos de Public Folders en la organizacin, debido a la replicacin. Particiones para rendimiento y recuperacin. Generalmente particionando los discos se obtiene un rendimiento mayor y menor volmen de datos a restaurar. Debera usarse discos y particiones diferentes para: Archivos del sistema operativo Archivos de aplicacin de Exchange

Bases de datos activas de Exchange Transaction logs activos de Exchange Bases de datos pasivas de Exchange Transaction logs pasivos de Exchange Adicionalmente, los discos de las copias activas y pasivas deberan estar aislados unos de otros. Asegurar espacio libre adecuado. Asegurar memoria RAM y CPU adecuados para LCR.

Opciones de alta disponibilidad para Exchange 2007 - parte 3 Como tercera parte, cubriremos Cluster Continuous Replication (CCR). Para simplificar el trmino, CCR es un LCR pero en otro nodo pasivo que, cuando el activo falla traspasa los recursos al nodo pasivo, atravs de los servicios de Cluster de Windows. CCR combina la tecnologa de Log Shipping y Log Replay con el servicio de Windows Cluster para brindar una solucin que:

No tiene un punto de fallas nico No tiene requerimientos especiales de Hardware Puede ser configurado en uno o dos datacenters distintos Al igual que LCR, reduce la frecuencia de backups. Al configurar CCR, la primer operacin que ocurre se denomina seeding que, bsicamente, copia la base de datos del Storage Group al nodo pasivo. Luego que esta operacin finaliza, se comienzan las de Log Replay. El comando de PowerShell involucrado en el falivoer es Move-ClusteredMailboxServer. Este cmdlet hace verificaciones para asegurar que el nodo pasivo est listo para recibir los recursos. CCR combina las siguientes tecnologas para hacer este servicio posible:

Failover y virtualizacin provista por el servicio de Windows Cluster. Transaction Log Replay y Log Shipping de Exchange Server 2007. Una cola de mensajes del Hub Transport llamada Transport Dumpster. Como la siguiente figura grafica, CCR requiere dos equipos o nodos unidos a un mismo cluster. Estos nodos alojan las bases de datos de buzones, clusterizadas.

El cluster utiliza la tecnologa ya conocida del servicio de Cluster de Windows, pero agrega una novedad a nivel Quorum. En vez de usar un recurso de cluster, utiliza una nueva tecnologa denominada Majority Node Set (MNS) quorum with file share witness. CCR usa un "testigo" o file share witness en un tercer equipo fuera del cluster, utilizado por los nodos para hacer un seguimiento de cul nodo tiene el control de los recursos del Cluster. Este recurso es slo utilizado cuando los nodos pierden comunicacin entre ellos, siendo innecesario cuando stos pueden interactuar entre ellos e intercambiar esta informacin. El testigo es utilizado cuando:

Un nodo del cluster se inicia y slo un nodo es el activo. Existe un problema en la red que evita que los nodos se intercomuniquen. Un nodo del cluster es quitado. Periodicamente para validacin. La frecuencia es configurable. La carga en el File Server que aloja el "testigo" es muy poca. Requerimientos Existen ciertas consideraciones a tener en cuenta antes de implementar este tipo de soluciones:

Se debe utilizar una sla base de datos por Storage Group. Si se cuenta con un slo servidor de Maiblox en la organizacin y est en un ambiente de CCR, el servidor puede contener un almacn de Carpetas Pblicas. En esta configuracin, existe una nica base de datos de Public Folders, por lo tanto la replicacin est deshabilitada. Si se tienen varios Mailbox Servers, y slo uno tiene una base de Public Folders, esta base puede estar alojada en un CCR. En esta configuracin, existe una nica base de datos de Public Folders, por lo tanto la replicacin est deshabilitada.

Si ms de un Mailbox Server tiene bases de datos de Public Folders, y la replicacin est habilitada, las Public Folders no pueden estar alojadas en un CCR. Todos los nodos del cluster deben pertenecer al mismo dominio de Active Directory. Exchange Server 2007, en CCR, no est soportado si el servidor es tambin Domain Controller. Asegurarse que el cluster sea configurado antes de instalar Exchange Server 2007. No pueden existir otras aplicaciones instaladas en los nodos que utilicen el cluster (cluster-aware), como SQL Server o Exchange Server 2000 / 2003. S est soportado, por ejemplo, que el nodo corra SQL Server 2005 Express, sin clusterizar. Se debe instalar la misma versin de Exchange Server 2007 en todos los nodos pertenecientes al cluster. Adicionalmente, el Sistema Operativo y los binarios de Exchange deben estar instalado en los mismos path y unidades en ambos nodos. La cuenta de servicio de Cluster debe ser miembro del grupo Administradores local de cada nodo. Requerimientos de Software

Todos los nodos en el cluster deben correr Windows Server 2003 Enterprise, utilizando las mismas unidades para el sistema y booteo. El cluster debe tener instalado el fix 921181 La carpeta compartida para el quorum de MNS no necesariamente tiene que ser un equipo dedicado. En un ambiente con delegaciones de administracin, la recomendacin es que el quorum resida en un Hub Transport u otro servidor de Exchange, para que pueda ser controlada por un Administrador de Exchange. En CCR slo se puede instalar el rol de Mailbox Server. No se puede compartir ningn otro rol. Requerimientos de Red

Cada nodo debe contar con, al menos, dos interfaces de red disponibles para el servicio de Windows Cluster. Una interfaz ser pblica, y la otra para las comunicaciones intra-cluster. Cada nodo requiere una direccin ip esttica para cada uno de los adaptadores que sern utilizados por el servicio de cluster. Las direcciones de los adaptadores no pueden estar en la misma subnet. Las interfaces privadas (comunicacin intra-cluster) deben estar en la misma subnet. Las interfaces pblicas deben estar en la misma subnet.