Simplicidad

Las fallas ocurren. No hay tecnología que pueda cambiar eso. Discos, servidores, racks, redes, generadores, sistemas operáticos, aplicaciones (como Exchange), drivers, y otros servicios, simplemente no existe un servicio entregado por IT que no esté sujeto a fallos.

Una manera de mitigar las fallas es con una infraestructura redundante. Donde una entidad que falla, siempre tendrá una o más entidades para utilizar en su lugar. Esto se puede observar en los Web Server Array, disk array, y similares. Pero la redundancia puede ser costosa, por ejemplo, el costo y la complejidad del sistema de almacenamiento basado en SAN que estaba en el corazón de Exchange hasta la versión 2007, condujeron al equipo de Exchange en aumentar la inversión en almacenamiento para su arquitectura. Nos dimos cuenta de que cada sistema de SAN en última instancia, falla, y que la implementación de un sistema altamente redundante utilizando la tecnología SAN sería un costo muy alto. En respuesta a esto, Exchange a evolucionado de una exigencia costosa de alto rendimiento en almacenamiento SAN y periféricos relacionados, para ahora ser capaz de correr en servidores más baratos con los productos básicos SAS/SATA. Esta arquitectura permite a Exchange ser resistente a fallos relacionados con el almacenamiento permitiendo almacenar buzones de gran tamaño a un costo razonable. Con la construcción de la arquitectura de replicación y optimización de Exchange en almacenamiento, los fallos en temas de almacenamiento son prescindibles. Esta arquitectura no se detiene en la capa de almacenamiento, NIC redundantes, fuentes de poder, etc. Si se trata de un disco, controlador o placa base que falla, el resultado final debe ser el mismo, otra copia de base de datos se activa y se hace cargo. Cuanto más complejo sea el hardware o software de la arquitectura, los errores de hardware ya no se vuelven una prioridad. Ejemplos de redundancia complejos son pares activos/pasivos de red, puntos de agregación de la red con configuraciones complejas de enrutamiento, la colaboración de red, RAID, múltiples vías de fibra, etc. La eliminación de redundancia compleja no parece algo creíble, pero puede lograrse a través de una redundancia basada en Software. La Arquitectura preferida (PA) elimina la complejidad y redundancia cuando sea necesario para impulsar la arquitectura a un modelo de recuperación predecible: cuando se produce un fallo, se activa otra copia de la base de datos afectada.El PA se divide en cuatro áreas de interés:

• Diseño de espacios de nombres
• Diseño de datacenter
• Diseño del servidor
• Diseño del DAG

Namespace

Desde una perspectiva de espacio de nombres las opciones son, o bien implementar un espacio de nombres con destino preferido (que tiene una preferencia por los usuarios para operar fuera de un centro de datos específico) o un espacio de nombres no unida (que tienen los usuarios se conectan a cualquier centro de datos sin preferencia). El método recomendado es utilizar el modelo no unido, el despliegue de un único espacio de nombres según el protocolo de cliente para el par de estaciones tolerantes del datacenter (donde se supone que cada datacenter  para representar su propio sitio de Active Directory). Por ejemplo:

• Autodiscover.dominio.com
• Para clientes http: mail.dominio.com
• Para clientes IMAP: imap.dominio.com
• Para clientes SMTP: smtp.dominio.com

Cada espacio de nombre debe estar balanceado entre todos los datacenter en una configuración que no aprovecha la afinidad de sesión, lo que resulta en un cincuenta por ciento del tráfico se distribuye entre los datacenter. El tráfico se distribuye por igual entre los datacenter via DN round-robin, geo-DNS, o soluciones similares. Aunque desde nuestro punto de vista, la solución más simple es la menos complejo y más fácil de manejar, por lo que nuestra recomendación es aprovechar el DNS round-robin. En el caso de que usted tiene sitios múltiples de datacenter flexibles en su entorno, tendrá que decidir si quiere tener un único espacio de nombres en todo el mundo, o si desea controlar el tráfico a cada datacenter específico mediante el uso de espacios de nombres regionales. En última instancia su decisión depende de la topología de red y el costo asociado con el uso de un modelo no unido; por ejemplo, si usted tiene un datacenter ubicados en América del Sur y Europa, el enlace de red entre estas regiones podría no sólo ser costoso, si no también podría tener una alta latencia, que puede presentar dolor de cabeza para el usuario y las cuestiones operativas. En ese caso, tiene sentido para implementar un modelo enlazado con un espacio de nombres separado para cada región.

Diseño de Servidores

En la PA, todos los servidores son multi-rol y físicos. Se prefiere hardware físico por dos razones:

• Los servidores se escalan para utilizar el 80% de los recursos en el peor de los casos.
• La virtualización añade una capa adicional de administración y recuperación que no añaden valor a Exchange.

Mediante el despliegue de servidores multi-rol, la arquitectura se simplifica ya que todos los servidores tienen el mismo hardware, proceso de instalación y las opciones de configuración. Consistencia a través de servidores también simplifica la administración. servidores multi-rol proporcionan un uso más eficiente de los recursos del servidor mediante la distribución del CAS y los recursos del Mailbox a través de un mayor número de servidores. CAS y DAG son más resistente a fallas, ya que hay más servidores disponibles para el equilibrio de carga del CAS y para el DAG.

Figura 1: Diseño de servidores

Diseño DAG

Para cada sitio será necesario tener como mínimo un DAG.

Configuración del DAG

Al igual que con el namespace design, cada DAG dentro del sitio del datacenter opera en un modelo no unido con copias activas distribuidas por igual entre todos los servidores en el DAG. Este modelo ofrece dos ventajas:

• Se asegura de que cada servicio de la base de datos se encuentre valida (conectividad con cliente, replicación, transporte, etc).
• distribuye la carga a través de tantos servidores como sea posible durante un escenario de error, lo que aumenta de forma incremental solamente la utilización de recursos a través de los miembros restantes dentro del DAG.

Cada datacenter es simétrico, con igual número de servidores miembro dentro de un DAG que reside en cada datacenter. Esto significa que cada DAG contiene un número par de servidores y utiliza un servidor testigo de arbitraje quórum.

El DAG es el bloque de construcción fundamental en Exchange 2013. Con respecto al tamaño de DAG, un DAG más grande proporciona más redundancia y recursos. Dentro de la PA, el objetivo es el despliegue de los DAG con alta capacidad.

DAG Network

Desde la introducción de la replicación continua en Exchange 2007, Exchange ha recomendado tener múltiples redes de replicación, para separar el tráfico del cliente de tráfico de replicación. La implementación de dos redes le permite aislar ciertos niveles de tráfico a lo largo de las diferentes vías de la red y asegurarse de que, en determinados eventos la interfaz de red no este saturada. Sin embargo, para la mayoría de los clientes, que tiene dos redes que funcionan de esta manera era sólo una separación lógica, ya que el mismo tejido de cobre fue utilizado por ambas redes en la arquitectura de red subyacente.

Witness Server (Servidor de Testigo)

La utilización de un servidor de testigo determina si la arquitectura puede proporcionar capacidades de activación automática por datacenter en caso de fallas, o si se requerirá activación manual para subir el servicio. Si su organización tiene una tercera ubicación con una infraestructura de red que está aislado de los fallos de red que afectan el sitio del centro de datos par resistente en el que se despliega el DAG, entonces la recomendación es implementar servidor testigo del DAG en ese tercer lugar. Esta configuración ofrece la DAG la capacidad de resistencia a fallas y activación de copia pasiva en otro datacenter.

Figura 2: DAG (Esquema de 3 datacenter)

El PA se aprovecha de los cambios realizados en Exchange 2013 para simplificar la implementación de Exchange, sin disminuir la disponibilidad o la elasticidad del despliegue. Y en algunos casos, en comparación con las generaciones anteriores, la PA aumenta la disponibilidad y capacidad de recuperación de su implementación.

Ernesto León, Consultor Infraestructura, Blue Latam.