Microsoft Exchange Server 2010: Estrategias de alta disponibilidad
Las estrategias de que Microsoft ofrece para la creación de buzones de Microsoft Exchange altamente disponibles han evolucionado con los años.
Extraído de "Exchange 2010 – A Practical Approach," publicado por libros de puerta roja (2009).
Jaap Wesselius
Desde Exchange Server 5.5, Microsoft ha ofrecido clústeres de Windows como una opción para la creación de un entorno altamente disponible de buzón de Exchange. Hay dos nodos de servidor disponibles en un entorno típico de almacenamiento compartido. Ambos ejecutan Exchange Server y ambos servidores están conectados a una solución de almacenamiento compartido.
En los primeros días, este almacenamiento compartido fue construido en un bus SCSI compartido. Posteriormente emplean redes de área de almacenamiento (San) con una conexión de red de Fibre Channel o iSCSI. La parte importante fue el almacenamiento compartido donde se encontraban las bases de datos de Exchange Server.
Sólo un servidor nodo es el "dueño" de este datos compartidos. Este nodo proporciona los servicios de cliente. Es también conocido como el nodo activo. El otro nodo no es capaz de acceder a estos datos y por lo tanto el nodo pasivo. Una red privada entre los nodos del dos servidor se utiliza para la comunicación interna del clúster, como una señal del latido del corazón. Esto permite ambos nodos determinar el estado del clúster y asegúrese de que los otros nodos están todavía vivos.
Además de los dos nodos, crea un "servidor Virtual de Exchange" como un recurso de clúster. Esto no tiene nada que ver con las máquinas virtuales. Este es el recurso a los que los clientes Outlook conectan para poder acceder a sus buzones. Cuando se produce un error en el nodo activo, el nodo pasivo se apodera del servidor Virtual de Exchange, que luego continúa funcionando. Aunque los usuarios notarán un corto tiempo de inactividad durante la conmutación por error, es una experiencia de lo contrario. No se requiere acción del usuario.
Aunque esta solución ofrece redundancia, aún hay un punto único de falla — la base de datos compartida del servidor Exchange. En un entorno típico, esta base de datos se almacena en un SAN. Por su propia naturaleza, una SAN es un entorno de alta disponibilidad. Cuando algo sucede a la base de datos, sin embargo, como un error lógico, la base de datos está disponible para ambos nodos. Esto resulta en indisponibilidad total.
Replicación de base de datos de Exchange
Con Exchange Server 2007, Microsoft ofrece una nueva solución para la creación de entornos de Exchange altamente disponibles: replicación de base de datos. Replicación de base de datos crea una copia de una base de datos, resultando en la redundancia de la base de datos. Esta tecnología estaba disponible en tres sabores:
- **Replicación continua local (LCR):**Este enfoque crea una copia de la base de datos en el mismo servidor.
- **Cluster Continuous Replication (CCR):**Esto crea una copia de la base de datos en otro nodo en un clúster de conmutación por error de Windows (sólo puede haber dos nodos de un clúster CCR).
- **STANDBY Continuous Replication (SCR):**Esto sucedió con Exchange Server 2007 SP1. Crea una copia de una base de datos en cualquier otro servidor de Exchange (no necesariamente en el clúster). Esto no significó para alta disponibilidad (HA); es más para recuperación ante desastres.
Se trata de cómo funciona la replicación de base de datos en un entorno de clúster CCR. Exchange Server 2007 está instalado en un Windows Server 2003 o Windows Server 2008 failover cluster. No hay ningún almacenamiento compartido en uso dentro del cluster. Cada nodo tiene su propio almacenamiento de información. Esto puede resultar en una SAN (Fibre Channel o iSCSI) o almacenamiento de conexión directa (DAS) — locales discos físicos.
El nodo activo en las solicitudes de cliente de servicios de Cluster Server y Exchange Server utiliza la tecnología de base de datos estándar con una base de datos, archivos de registro y un archivo de control. Cuando Exchange Server está terminado con un archivo de registro, se envía inmediatamente al nodo pasivo del clúster. Esto puede ser a través de una conexión de red normal o a través de una red dedicada de replicación.
El nodo pasivo recibe el archivo de registro y comprueba los errores. Si encuentra ninguno, se retransmiten los datos en el archivo de registro a la copia pasiva de la base de datos. Se trata de un proceso asincrónico, es decir que la copia pasiva es siempre un par de archivos de registro de la copia activa, por lo que "falta" en la copia pasiva.
En este entorno, todos los mensajes — incluso mensajes internos — son enviados a través de un servidor Transporte de concentradores. El servidor Transporte de concentradores realiza un seguimiento de estos mensajes en un entorno de CCR. Por lo tanto puede enviar falta información (que en realidad pide el nodo pasivo) a la copia pasiva del clúster en el caso de un clúster de conmutación por error. Esto se llama el "contenedor de transporte" en un servidor Transporte de concentradores.
Este tipo de replicación funciona muy bien. Replicación de CCR es muy fiable, pero hay un par de potenciales inconvenientes:
- Un entorno de Exchange Server 2007 CCR se ejecuta en Windows Server 2003 o Windows Server 2008 de clustering. Para muchos, esto agrega complejidad excesiva para el medio ambiente.
- Windows Server 2003 en un entorno de varias subredes de clustering es casi imposible, aunque esto ha mejorado (pero aún no es perfecto) en Windows Server 2008 failover clustering.
- Resistencia de sitios no es transparente.
- Clúster CCR sólo es posible en un entorno de dos nodos.
- Todos los tres tipos de replicación (LCR, CCR y SCR) se administran de forma diferente.
Para superar estos problemas, Microsoft ha mejorado radicalmente la tecnología de replicación. También reduce la sobrecarga administrativa. Esto logra ocultando completamente los componentes del clúster detrás de la implementación de Exchange Server 2010. Los componentes del clúster están todavía allí, pero la administración se hace enteramente con la consola de administración de Exchange (EMC) o el Shell de administración de Exchange (EMS).
Replicación continua de DAG
En Exchange Server 2010, Microsoft introdujo el concepto de un grupo de disponibilidad de la base de datos (DAG). Se trata de una unidad lógica de servidores de buzones de Exchange Server 2010. Todos los servidores de buzón de correo dentro de un DAG puede replicar bases de datos entre sí. Un DAG solo puede almacenar hasta 16 servidores de buzones y hasta 16 copias de una base de datos.
La idea de múltiples copias de la base de datos en una organización de Exchange se llama movilidad de Exchange. Hay una base de datos en varios servidores, cada instancia de que es 100 por ciento idénticos y por lo tanto tiene el mismo GUID.
Con un DAG en el lugar, los clientes conectarse a una base de datos activa. Esta es la base de datos donde todos los datos se almacenan inicialmente. Nuevos mensajes de SMTP, ya sea desde fuera o dentro de la organización, se almacenan en esta base de datos primero.
Cuando el servidor de Exchange ha terminado de procesar la información en el archivo de registro de la base de datos, replica el archivo en otros servidores. Puede asignar a los servidores que reciben una copia de la base de datos. El archivo de registro es inspeccionado sobre el recibo y si todo está bien, la información contenida en el archivo de registro se cae en la copia local de la base de datos.
En Exchange Server 2010, todos los clientes conectan al servidor de acceso de cliente, incluyendo a todos los clientes de Messaging Application Programming Interface, o interfaz MAPI, como Microsoft Outlook. Clientes soportados de Outlook en Exchange Server 2010 incluyen Outlook 2003, Outlook 2007 y Outlook 2010.
Por lo que el cliente de Outlook se conecta al servidor de acceso de cliente, que luego se conecta al buzón en la copia activa de la base de datos. Lamentablemente, esto sólo es cierto para bases de datos de buzones. Cuando un cliente de Outlook debe tener acceso a una base de datos de carpetas públicas, el cliente tiene acceso aún al servidor de correo directamente.
Cuando la copia activa de una base de datos o su servidor falla, una de las copias pasivas de la base de datos se convierte en activa. Puede configurar el orden de conmutación por error durante el proceso de configuración de la copia de base de datos. El servidor de acceso de cliente automáticamente avisos de la conmutación por error y comienza a usar la nueva base de datos activa. Porque el cliente de Outlook está conectado al servidor de acceso de cliente y no directamente a la base de datos, una base de datos de conmutación por error es completamente transparente. Mensajes como, "se perdió la conexión con el servidor", y "se restaura la conexión al servidor," simplemente no aparecen ya.
Al crear un entorno de servidor de buzón de correo de alta disponibilidad en un DAG, no hay ninguna necesidad de crear un clúster de conmutación por error de antemano. Puede agregar servidores de buzones adicionales al DAG sobre la marcha. Sin embargo, para que el DAG funcione correctamente, todavía está utilizando algunos failover clustering componentes. Se instalan durante la configuración de DAG. Haces toda gestión de copia de DAG y base de datos a través de EMC o el EMS. Ya no tienes que usar el administrador de clúster de Windows.
El DAG con copias de la base de datos es la única tecnología de alta disponibilidad que utiliza Exchange Server 2010. Las viejas tecnologías como SCR, CCR y SCR ya no están disponibles. El clúster de copia única tradicional con almacenamiento compartido ya no es compatible, tampoco.
Configurar un DAG ya no se limita a un servidor que sólo la función del servidor Buzón de correo. Es posible crear una situación de dos servidores concentrador de transporte, acceso de cliente y funciones de servidor de buzón en ambos servidores y luego crear un DAG y configurar copias de la base de datos.
Sin embargo, no es una configuración de alta disponibilidad para los servidores de acceso de cliente o concentrador de transporte a menos que lo hayas puesto equilibradores de carga frente a ellos. Se puede utilizar el equilibrio de carga de red de Windows por defecto en combinación con los componentes clústeres de conmutación por error. Sin embargo, esto es una gran mejora para pequeñas implementaciones de Exchange Server 2010 donde HA es todavía necesario.
.jpg)
Jaap Wesselius es el fundador de DM consultores, una empresa con un fuerte foco en soluciones de mensajería y colaboración. Después de ocho años trabajando en Microsoft, Wesselius decidió cometer más de su tiempo a la comunidad de Exchange en los países Bajos, resultando en un premio de MVP de Exchange Server 2007. También es colaborador habitual en el grupo de usuarios de comunicaciones unificadas holandesa y un autor regular Simple-Talk.
Conozca más acerca de "Exchange 2010 – A Practical Approach" en red-gate.com/our-company/about/book-store.