Exchange desde su versión 2007 basa su funcionamiento en roles. Cuando pensamos en dar alta disponibilidad lo primero que nos viene a la mente son las bases de datos de buzones, pero ¿Qué pasa con los otros roles? ¿De qué sirve tener los buzones Online si los servidores de acceso cliente no están disponibles? Y aunque lo estén, si no tenemos servidores HUB o EDGE que mantengan el flujo de correo tendremos parada toda nuestra organización lo cual es inadmisible para cualquier empresa.
Vamos a realizar un repaso por las diferentes tecnologías implicadas en la alta disponibilidad de Exchange analizando rol por rol y viendo qué alternativas tenemos.
Comenzaremos por los servidores perimetrales:
Rol de servidor de transporte perimetral o Edge Transport
Estos servidores se encuentran en nuestra DMZ y son los encargados de recibir el correo de nuestra organización. Normalmente el registro MX de nuestra zona pública apuntará a ellos y una vez recibidos los correos lo pasarán al siguiente rol en la cadena: el concentrador de transporte o Hub Transport.
Para seguir teniendo servicio ante la caída de Edge Transport necesitamos dos registros MX en nuestra zona DNS pública.
Por una lado podríamos tener un servidor Edge (con su MX asociado con un valor 10 por ejemplo) y en caso de caída tener contratado un servicio online de recepción de correos con su registro MX asociado con un valor mayor (por ejemplo 20). De esta forma si nuestro Edge cae, el correo será entregado al servidor en la nube que intentará entregar en correo a nuestra organización en cuanto esté disponible.
Por otro lado podemos tener un segundo servidor Edge de forma que el segundo registro MX apunte al él con un valor 20 de forma que sirva de failover o incluso mejor: darle a los dos la misma prioridad MX (10) de forma que a través del round robin del DNS obtenemos un balanceo de carga. De esta forma ante la caída de uno de los dos servidores el servicio de correo no se vería afectado.
Incluso se podría proteger más teniendo cada Edge en un CPD distinto o incluso varios edges en varios CPDs.
De cualquiera de estas forma aseguramos la continuidad del negocio.
Ya hemos recibido el correo en nuestros servidores perimetrales, ahora entramos en la LAN de la empresa.
Rol de servidor de transporte de concentradores o Hub Transport Server
Sin necesidad de realizar configuraciones adicionales los servidores de transporte de concentradores se coordinan de forma que si un servidor falla y no está disponible otro se encarga del transporte del correo, pero ¿qué pasa con los mensajes que estuvieran en tránsito o en cola durante la caída? La respuesta es clara: se perderían.
Esto es inadmisible. Microsoft nos proporciona una forma de tener redundancia extremo a extremo de la comunicación. Es la llamada shadow redundancy:
De esta forma no se interrumpe el fujo de correo ante la caída de un servidor HUB o EDGE.
Rol de servidor de acceso cliente o Client Access Server
Este rol es el encargado de recibir las peticiones de los usuarios, incluso las conexiones MAPI (a diferencia de 2007 en dónde las conexiones MAPI eran contra el servidor de buzones). La única excepción son las conexiones MAPI a las carpetas públicas que siguen necesitando acceder al servidor de buzones.
De ahí lo crítico del rol ya que es el encargado de que podamos acceder a nuestros buzones ya sea por MAPI, POP, IMAP, Active-Sync, OWA etc.
Microsoft nos proporciona el Array de CAS para tener alta disponibilidad en estos servidores. Se trata de un cluster NLB (no failover) que podemos montar ya sea con balanceadores hardware o mediante NLB de Windows. La ventaja de montarlo sobre balanceadores hardware es que al no usar NLB podemos montar el CAS Array sobre equipos de buzones que sean miembros de un DAG como podemos apreciar en la imagen.
De esta forma ante la caída de un miembro del array los usuarios siguen podiendo acceder de forma transparente a sus buzones.
Rol de servidor de buzones o Mailbox Server
Este rol es que que más claramente necesita la alta disponibilidad: si se cae el servidor que contiene los buzones los usuarios dejan de trabajar. Es el primer rol en el que pensamos a la hora de la alta disponibilidad pero lo hemos dejado para el final ya que es el que más tela tiene para cortar.
Microsoft nos proporciona el DAG para tener alta disponibilidad en los buzones. Básicamente se trata de un cluster de replicación en el que no existe un almacenamiento único y en dónde todos los miembros tienen replicadas todas las bases de datos. En caso de caída se activaría una copia en otro servidor y no se interrumpiría el servicio.
Esa es la explicación rápida pero hay que tener más consideraciones.
Si sólo disponemos de un sólo CPD la explicación anterior nos sirve al 100%, configuramos un DAG, asignamos cada copia viva de una base de datos a un servidor y en caso de caída se activa otra. El acceso de los usuarios es mediante el CAS con lo que no hay que cambiar nada en los clientes.
¿Qué pasa si tenemos 2 CPDs en ubicaciones distintas?
Ejemplo: 2 CPDs con usuarios
En este caso disponemos de 2 CPDs que dan acceso por ejemplo a 1000 usuarios cada uno.
Esta claro que usaríamos DAG, pero ¿Cómo?
Tenemos dos opciones claras: usar 1 DAG o usar 2 DAG.
1 DAG: Esta claro que en cada ubicación tendríamos 2 servidores con lo que tendríamos un DAG de cómo mínimo 4 servidores con 1 witness para convertir uno de ellos en primario.
¿Qué pasaría ante la caída del CPD secundario? Dado que tiene menor número de nodos, las replicas de las bases de datos que no estaban activas en el sitio primario pasarían a ser activas y no se interrumpiría el servicio. Los usuarios del sitio secundario podrían acceder remotamente a sus buzones vía el CPD primario.
¿y si el que cae es el CPD primario? Al caer el CPD primario que posee el mayor número de nodos, el DAG se caería. Un administrador podría activar un witness alternativo en el CPD secundario y dejar a los usuarios trabajando contra el CPD secundario.
Ok, se soluciona la avería en el CPD primario y se encienden los equipos antes de que se restaure la conectividad WAN. En este caso el DAG ve que tiene el witness y activa las bases de datos: se ha producido el síndrome del cerebro dividido. Los dos CPDs tienen activas las mismas bases de datos.
Esto lo solucionaríamos activando el DAC (Datacenter Activation Coordination mode). Gracias a esta funcionalidad se crea un token que sólo puede tener a la vez uno de los CPDs. Hasta que no hablan los dos CPDs el que acaba de arrancar no intentaría levantar sus bases de datos.
¿Y si cae la línea entre los dos CPDs? Imaginemos 2 sedes muy grandes con acceso a internet cada una y con una línea WAN dedicada para comunicarse. En este caso al perderse la comunicación el CPD1 seguiría trabajando por tener el mayor número de nodos pero el CPD2 desmontaría las bases de datos al no disponer de la mayoría. Dejaríamos una sede de 1000 usuarios sin trabajar con el correo.
Segunda opción: dos DAGs.
Para solucionar el problema comentado montaríamos dos DAG a lo largo de todos los servidores (como se muestra en la imagen) . En el CPD1 los servidores 1 y 2 tendría las bases de datos del CPD1 y los servidores 3 y 4 las copias durmientes del CPD2. En el CPD2 al contrario. El DAG1 tendría el witness en el CPD1 y el DAG2 en el CPD2.
De esta forma al perder la comunicación entre CPDs quedaría activo el DAG1 en el CPD1 (con lo que no montaría las bases de datos del CPD2 que están en el DAG2) y el DAG2 quedaría activo en el CPD2 (dado que allí tiene mayoría).
De esta forma las dos oficinas podrían seguir trabajando sin problemas.
Con esto finalizamos el repaso sobre las opciones de alta disponibilidad de Exhcnage 2010 según los roles.
Adjunto documentación del Technet de Microsoft para ampliar información.
Exchange Hosted Services: http://www.microsoft.com/exchange/en-us/exchange-online-hosted-email.aspx
Shadow Redundancy: http://technet.microsoft.com/en-us/library/dd351027.aspx
CAS Array: http://technet.microsoft.com/en-us/library/dd979781.aspx
DAG: http://technet.microsoft.com/en-us/library/dd979781.aspx
No hay comentarios:
Publicar un comentario