Arquitecturas recomendadas II: Exchange

Este post es el segundo de una serie de artículos sobre cómo diseñar arquitecturas para plataformas cloud según la aplicación y el fin para los cuales son requeridas. Tras el post dedicado a plataformas de e-commerce, próximamente aparecerán los dedicados a Desktop as a Service y Disaster Recovery

En esta entrega vamos a abordar el diseño de plataformas para alojar una de las aplicaciones corporativas estrella, Microsoft Exchange, específicamente en su última versión, la 2013. Exchange es el estándar de facto en cuanto a aplicaciones de correo electrónico, calendarios y colaboración empresarial. Todas las compañías usan el correo electrónico a diario, es una necesidad ineludible de cualquier negocio, y por ello las plataforma que lo sustenta debe ser capaz de soportar desastres, incidencias y ataques. Ciñéndonos al propósito de esta serie de artículos –cómo construir correctamente plataformas en la nube–, todas las arquitecturas aquí presentadas hacen uso de la virtualización, tanto en entornos de cloud público como de cloud privado.

ARQUITECTURAS RECOMENDADAS

La primera y más típica arquitectura para alojar una solución de Exchange está compuesta por un único servidor multi-rol (Mailbox y CAS [En Exchange 2010 y anteriores CAS/HUB]), como la siguiente:

Arquitectura plataforma para ecommerce modelo 1

Para empresas donde el correo no es un elemento crítico, es una solución contenida en costes, pero que desde un punto de vista operativo deja un gran punto único de fallo. Aquí, una corrupción de datos o una rotura del servidor dejará durante varias horas a la empresa sin correo.

Arquitectura plataforma para ecommerce modelo 2

En este segundo diseño de infraestructura ya hemos dotado a la plataforma de HA (Alta Disponibilidad) mediante un balanceo de carga y los Database Availability Groups (DAGs), lo cuál permitirá soportar el posible fallo de uno de los servidores. El protocolo de clustering DAG de Exchange nos permite tener varias bases de datos replicadas entre los servidores, en un esquema de shared nothing clustering, lo que mitiga posibles puntos únicos de fallo en cuanto al almacenamiento.

Sin embargo, desde un punto de vista operativo esta arquitectura sigue sin ser óptima, ya que cualquier actuación sobre cualquiera de los roles instalados (Mailbox o CAS) necesitará activar el proceso de Failover del DAG, provocando una degradación del servicio de cara al usuario.

Arquitectura plataforma para ecommerce modelo 3

Por último, esta es la arquitectura que más podemos recomendar, y es la que Claranet ofrece a sus clientes con máxima exigencia. Aquí, además de disponer de alta disponibilidad, los servidores están especializados en cada rol, redundados entre ellos, para ser capaces de soportar incidencias. Si, por ejemplo, el equipo técnico necesita actuar sobre un servidor CAS, en ningún momento será necesario invocar el procedimiento de Failover, otorgando al usuario una experiencia fluida y sin cortes.

¿QUÉ VENTAJAS APORTA?

Esta arquitectura es óptima para empresas que buscan un servicio de Exchange por usuario. Es una gran alternativa a Office 365, ya que plantea una infraestructura exclusiva para el cliente que garantiza disponibilidad de recursos y seguridad; ofrece una facturación predecible por usuario y mes; y permite olvidarse de la infraestructura subyacente.

Más sobre Servicios de Correo Electrónico

Contenidos relacionados: