En este documento vemos cómo configurar alta disponibilidad en el servidor con el rol de Acceso de Cliente en Exchange 2010, basado en un cluster NLB (Network Load Balancing), para evitar cualquier caida del servicio y poder aceptar peticiones en todo momento desde los equipos cliente.
Una de las novedades y ventajas que nos ofrece Exchange 2010 es la posibilidad de disponer de un sistema de alta disponibilidad de una forma sencilla, siendo fácil de implementar, en cualquier momento y sobre todo la sencillez de administración. Se basa mediante la implementación de DAG o Database Availability Group, montando una réplica de las bases de datos entre los diferentes servidores de Buzón (o en el mismo equipo si disponemos en el mismo servidor de todos los roles), así que con esto se sustituyen los antiguos clúster de Exchange 2007, SCR y LCR; y por lo tanto ahora necesitaremos simplemente dos servidores y no tres o más como se requerían en Exchange 2007!
En este documento se vera ciertas configuraciones genericas que permiten estas cabinas SAN de HP llamadas HP Lefthand, este caso está realizado mediante unas cabinas virtuales bajo un entorno VMware, ya que permiten trabajar perfectamente en un entorno de laboratiorio mucho más flexible. HP dispone de varios modelos de cabinas Lefthand físicas, todas con el mismo sistema, pero con diferentes capacidades, modelos de disco, bocas ethernet… serían la serie HP LeftHand P4500 y HP LeftHand P4300. Pero también para entornos de producción dispone de la cabina virtual HP LeftHand P4000 Virtual SAN Appliance o VSA.
En este documento veremos las principales características de las cabinas, como son el Storage clustering (da mayor rendimiento y capacidad), Network RAID (mayor disponibilidad de los datos), Thin provisioning (reduce costes y mejora la utilización de la capacidad de los discos), iSCSI (tecnología de red Ethernet) Snapshots y Replicación mediante Remote Copy (para replicación local o remota, para mejorar la protección y disponibilidad de los datos).
En este documento, veremos cómo montar un clúster de alta disponibilidad para nuestro servidor de correo Microsoft Exchange 2007 Server con el sistema operativo Microsoft Windows Server 2008, en este caso montaremos un sistema de clúster llamado SCC (Single Copy Cluster o Clúster de Copia Única). En este anterior documento se describen el resto de posibilidades que tendríamos, nos puede interesar más un sistema que otro (http://www.bujarra.com/?p=2362). Cómo se comentó anteriormente, SCC es el clúster que podemos conocer de ediciones anteriores de Microsoft Exchange, es un sistema de clúster de conmutación por error de almacenamiento compartido, esto es, tendremos varios nodos con la ‘Función de buzón’ uno de ellos estando activo y el resto pasivos. El almacenamiento debe ser compartido, las bases de datos deben estar en una cabina o un sistema de almacenamiento remoto, sea iSCSI, fibra… Cuando el nodo activo falle, uno de los nodos en estado pasivo pasará a estar como activo conectándosele el almacenamiento compartido e iniciando todos sus servicios en él.
Bueno, tras mucho tiempo out, con mucho trabajo, tuve tiempo para mirarme y pelear con los diferentes tipos de alta disponibilidad que nos da Microsoft Exchange 2007 a fecha de hoy. A diferencia de Microsoft Exchange 2003, esta versión, trae más posibilidades para tener una alta disponibilidad de nuestro servidor de correo, disponiendo de diferentes métodos, unos más económicos que otros y más o menos complejos. En principio disponemos de:
CCR (Cluster Continuous Replication o Replicación Continua en Clúster)
SCC (Single Copy Cluster o Clúster de Copia Única)
LCR (Local Continuous Replication o Replicación Continua Local)
SCR (Standby Continuous Replication o Replicación Continua en Espera)
Tras ver un documento de cómo crear el almacenamiento compartido para un clúster, por qué no crear uno? Bueno, el proceso es parecido a Windows 2003, ahora lo realizaremos para Windows 2008, un clúster nuevo, y será para un servidor de ficheros, de tipo failover clustering, el proceso para otro tipo de clúster es parecido. Con esto conseguiremos alta disponibilidad, que si se nos cae uno de los servidores (nodo) no pase nada, ya que existen otros nodos que pueden coger los recursos y levantar los servicios para que los usuarios puedan trabajar prácticamente sin notar la caida del nodo contra el que estaban trabajando. También comentar que el mantenimiento de un clúster es costoso, esto es, tendremos siempre en cuenta que ambos servidores tendrán las mismas aplicaciones instaladas, de la misma forma y con las mismas versiones, todo esto para evitar problemas futuros. Además es recomendable balancear el clúster para comprobar su correcto funcionamiento.
