Exchange Server 2010
Garantía de alta disponibilidad en Microsoft Exchange Server 2010
William R. Stanek
- Características de alta disponibilidad en Exchange Server 2010
- Descripción detallada de grupos de disponibilidad de base de datos
Las bases de datos de buzones y los datos que contiene son críticos para cualquier organización de Exchange. Para garantizar una alta disponibilidad para bases de datos de buzones, Exchange 2007 proporcionó una variedad de opciones de replicación y clústeres, en que se incluía replicación continua local, clústeres de copia única y servidores de Buzón agrupados. Aunque estas características representaban mejoras respecto de ofertas anteriores, seguían representando muchos desafíos de implementación. En el caso de principiantes, cada aproximación a una alta disponibilidad se administraba de manera diferente. Con clústeres de copia única, todos los servidores de buzón en un clúster usaban almacenamiento compartido. La implementación de clústeres significaba que los administradores de Exchange tenían que configurar clústeres de conmutación por error de Windows, lo cual es bastante complejo y puede requerir mucho tiempo lograr un alto nivel de tiempo activo. Con la replicación continua, Exchange 2007 utilizaba replicación asincrónica integrada para crear copias de datos y luego mantenía estas copias a través de un trasvase de registros de transacciones y reproducción. Aunque usaba replicación continua local para crear copias locales en un entorno no agrupado, utilizaba replicación continua de clústeres o replicación continua en espera en un entono agrupado, y cada tipo de replicación continua de administraba de manera diferente.
Exchange Server 2010 tiene un enfoque radicalmente distinto respecto de la alta disponibilidad, puesto que ésta se integra en su arquitectura central, con lo cual se crea una solución de extremo a extremo que proporciona disponibilidad de servicio, disponibilidad de datos y recuperación automática. El resultado es que una solución clave de alta disponibilidad reemplaza a muchas soluciones distintas que se usaban anteriormente. Esta solución es el grupo de disponibilidad de base de datos (DAG).
Los DAG proporcionan conmutación por error y recuperación automáticas a nivel de la base de datos (en vez de a nivel del servidor) sin necesitar clústeres cuando implementa varios servidores de buzón con varias copias de bases de datos de buzón. Debido a estos cambios, crear un servidor de buzón de alta disponibilidad ya no requiere hardware de clústeres ni configuración de clústeres avanzada. En su lugar, los DAG proporcionan el componente base para la alta disponibilidad y la conmutación por error es automática para bases de datos de buzón que son parte del mismo DAG. Los DAG se pueden ampliar a varios sitios de Active Directory y los cambios arquitectónicos relacionados con servidores de buzón permiten que una base de datos de buzón única se mueva entre sitios de Active Directory. Como resultado, una base de datos de buzón única en un sitio de Active Directory puede conmutar por error en otro sitio de Active Directory.
Tiene que recordar que las copias de bases de datos son únicamente para bases de datos de buzón. Para redundancia y alta disponibilidad de bases de datos de carpetas públicas, utilizará replicación de carpetas públicas. A diferencia de la replicación continua de clústeres, en la cual varias copias de una base de datos de carpeta pública no pueden existir en el mismo clúster, puede replicar bases de datos de carpeta pública entre servidores en un DAG.
Antes de adentrarme en los detalles de los DAG, veamos las otras maneras en que las opciones de alta disponibilidad cambiaron para Exchange 2010.
Paseo rápido por las características de alta disponibilidad de Exchange Server 2010
En versiones previas, Exchange operaba como una aplicación de clústeres que utilizaba el modelo de administración de recursos de clústeres. En este enfoque, implementó alta disponibilidad para servidores de Buzón al crear primero un clúster de conmutación por error de Windows y luego ejecutar la instalación de Exchange en modo agrupado. Como parte del proceso de instalación, se registró la DLL de recurso de clúster de Exchange (exres.dll), lo cual permite la creación de un servidor de buzón agrupado. En contraste, Exchange 2010 no opera como una aplicación agrupada y el modo de administración de recursos de clústeres ya no se utiliza para alta disponibilidad. La DLL de recurso de clúster de Exchange y todos los recursos de clúster que proporcionaba ya no existen. En su lugar, Exchange 2010 utiliza su propio modelo de alta disponibilidad interno. Aunque algunos componentes de clústeres de conmutación por error de Windows todavía se utilizan en este modelo, ahora los administra en exclusiva Exchange 2010.
Es bastante interesante notar que muchas de las tecnologías de replicación subyacentes permanecen, sólo que evolucionaron y ahora trabajan de maneras significativamente diferentes. Como los grupos de almacenamiento se eliminaron de Exchange 2010, la replicación continua se ejecuta a nivel de la base de datos. En lugar de usar el bloque de mensajes de servidor (SMB) para el trasvase de registros y la propagación, Exchange 2010 utiliza un puerto TCP único definido por el administrador para la transferencia de datos. En vez de que copias pasivas extraigan un archivo de registro cerrado de la copia activa, la copia activa inserta archivos de registro en las copias pasivas y el flujo de datos se asegura a través del cifrado o compresión para reducir el tamaño de los datos replicados. Aunque la copia activa de una base de datos en versiones anteriores de Exchange se podría utilizar para inicialización y reinicialización, en Exchange Server 2010 tanto las copias activas como pasivas de bases de datos de buzón se pueden especificar como fuentes de inicialización y reinicialización, lo cual le permite agregar más fácilmente una copia de una base de datos a otro servidor de buzón.
Otro cambio importante tiene que ver con la manera en que replican los datos. En Exchange 2007, el servicio de replicación de Microsoft Exchange reproducía registros en copias de bases de datos pasivas y creaba una caché de operaciones de lectura/escritura que se utilizaba para reducir las operaciones de E/S de lectura. Cuando la copia pasiva de la base de datos se activaba, la caché de la base de datos se perdía, sin embargo, debido a que el servicio de Almacén de información de Microsoft Exchange que montaba la base de datos no tenía esta caché disponible. Esto significaba que la copia pasiva se activaba y se volvía disponible en estado frío sin una caché lista. Estado frío es el mismo estado en que habría estado la caché de la base de datos después de un reinicio del servidor o un reinicio de los servicios que realizan el almacenamiento de caché. Estar en estado frío significaba que el servidor no contaba con operaciones de lectura/escritura en caché, una condición que normalmente aumentaba el número de operaciones de E/S de lectura requerido hasta que el tamaño de la caché aumentaba lo suficiente para reducir la E/S del disco en el servidor. En Exchange 2010, el servicio de Almacén de información de Microsoft Exchange reproduce registros y controla las operaciones de montaje, lo cual asegura que la caché esté disponible cuando una copia pasiva se activa y vuelve disponible. Como resultado, es más probable que el servidor pueda utilizar la caché para reducir las operaciones de E/S de lectura después de un cambio o error.
Con servidores de buzón altamente disponibles, los mensajes de correo electrónico están a salvo una vez que llegan a un buzón; proteger mensajes de este tipo en tránsito, sin embargo, es otra cosa. Si un servidor de transporte de concentradores arroja error mientras procesa mensajes y no se puede recuperar, los mensajes se podrían perder. Como protección contra la pérdida de datos, Exchange 2007 introdujo la característica de recuperación del elemento eliminado de transporte, la cual aseguraba que los servidores de transporte de concentradores mantuvieran una cola de mensajes entregados recientemente a destinatarios cuyos buzones estaban protegidos mediante de replicación continua local o la replicación continua de clústeres. Los mensajes se retenían en la recuperación del elemento eliminado de transporte hasta que se alcanzaba un límite de tiempo o límite de tamaño definido por el administrador. En el caso de una conmutación por error, un servidor de buzón agrupado solicitaba automáticamente que cada servidor de transporte de concentradores en el sitio de Active Directory volviera a enviar correo desde la cola de la recuperación del elemento eliminado de transporte. Este enfoque evitaba que el correo se perdiera durante el tiempo necesario para que el clúster conmutara por error. Aunque este enfoque funciona, sólo está disponible para entrega de mensajes en un entorno de replicación continuo y no aborda una posible pérdida de mensajes cuando están en tránsito entre el Transporte de concentradores y los servidores de Transporte perimetral.
Exchange 2010 aborda estas desventajas de varias maneras. La recuperación del elemento eliminado de transporte ahora recibe comentarios para determinar qué mensajes se han entregado y replicado. Los servidores de transporte de concentradores mantienen una copia de mensajes que se envían a una base de datos de buzón replicado en un DAG. La copia se guarda en la cola de transporte (mail.que) hasta que se notifica al servidor de transporte de concentradores que los registros de transacción que representan el mensaje se han replicado e inspeccionado correctamente por todas las copias de la base de datos de buzón. Luego los registros se truncan desde la recuperación del elemento eliminado de transporte, con lo cual se asegura que la cola de esta recuperación se utilice sólo para mantener copias de mensajes cuyos registros de transacciones aún no se han replicado. Además, cuando una base de datos de buzón en un sitio de Active Directory conmuta por error en otro sitio de Active Directory, se envían solicitudes de nueva entrega de recuperación del elemento enviado de transporte al sitio original y al sitio nuevo.
Para proporcionar redundancia para los mensajes durante todo el tiempo que están en tránsito, Exchange 2010 agrega la característica de redundancia de sombras. La redundancia de sombras utiliza un enfoque similar a la recuperación del elemento enviado de transporte, salvo que la eliminación de mensajes de la base de datos de transporte se retrasa hasta que el servidor de transporte verifica que todos los saltos siguientes para ese mensaje se entregaron completamente. Si el servidor de transporte no puede verificar la entrega del siguiente salto, los mensajes se reenvían para entrega al siguiente salto. Este enfoque utiliza menos ancho de banda de red que crear copias duplicadas de mensajes en varios servidores. Aquí, el único tráfico de red adicional generado es el intercambio de mensajes con estado descartar entre los servidores de transporte. Los mensajes con estado de descarte los genera Shadow Redundancy Manager e indican cuando un mensaje de correo electrónico está listo para descartarse de la base de datos de transporte.
La redundancia de sombras es una extensión del servicio de protocolo simple de transferencia de correo (SMTP) y se usa siempre que ambos servidores en una conexión SMTP admitan la característica. Cuando tiene rutas de mensajes redundantes en su topología de enrutamiento, la redundancia de sombras hace que cualquier servidor de transporte sea desechable al eliminar la dependencia del estado de cualquier servidor específico de transporte de concentradores o perimetral. En este caso, si un servidor de transporte arroja error o desea desconectarlo para mantención, puede hacerlo en cualquier momento al extraerlo, reemplazarlo o actualizarlo sin tener que vaciar sus colas o preocuparse de que los mensajes se pierdan.
Shadow Redundancy Manager usa un enfoque de frecuencia para determinar la disponibilidad de servidores para los cuales los mensaje de sombra están en cola. El servidor de inicialización emite un mensaje XQUERYDISCARD y en respuesta el servidor objetivo devuelve notificaciones de descarte. Estos intercambios de notificaciones son la frecuencia.
Si un servidor no puede establecer una conexión con un servidor principal dentro del intervalo de tiempo de expiración de frecuencia, el cual corresponde a 300 segundos de manera predeterminada, el servidor reinicia el temporizador e intenta nuevamente, hasta tres veces (el valor predeterminado del conteo de reintentos de frecuencia). Si un servidor principal no puede responder en el momento en que se alcanza el conteo de reintentos, el servidor determina que el servidor principal arrojó error, se apropia de los mensajes de sombra y los vuelve a enviar. Los mensajes luego se entregan a sus destinos según corresponda. En algunos escenarios, como cuando el servidor original vuelve a conectarse con su base de datos original, se puede producir una entrega duplicada de mensajes. Debido a las características de detección de mensajes duplicados en Exchange, los usuarios de buzón de Exchange no ven los mensajes duplicados. Sin embargo, los destinatarios en servidores de buzón sin Exchange podrían recibir copias duplicadas.
Explicación detallada de los DAG
Aunque muchas de las mejoras de alta disponibilidad que he descrito hasta ahora son importantes, ninguna característica única tiene tanto impacto en la manera en que administra Exchange 2010 como los grupos de disponibilidad de bases de datos. Los DAG son el componente base de la alta disponibilidad en Exchange 2010. Las reglas de los DAG son simples. Cada DAG puede tener hasta 16 servidores de buzón como miembros. Cada servidor de buzón puede ser miembro de un solo DAG y sólo puede hospedar una copia de una base de datos. La copia hospedada puede ser una copia activa o una copia pasiva. Una copia activa se diferencia de una pasiva en que está en uso y los usuarios pueden obtener acceso a ella en vez de estar desconectada. No puede crear dos copias de la misma base de datos en el mismo servidor. Después de esto, cualquier servidor en un DAG puede hospedar una copia de cualquier base de datos de buzón desde cualquier otro servidor en el DAG. Aunque puede haber varias bases de datos activas al mismo tiempo, sólo una copia de alguna base de datos en particular se puede activar en cualquier momento y hasta 15 copias pasivas de esta base de datos pueden estar en otros servidores en un DAG.
Cuando crea su primer DAG en una organización de Exchange, Exchange crea un clúster de conmutación por error de Windows, pero no hay grupos de clústeres para Exchange ni recursos de almacenamiento en el clúster. El DAG usa sólo las características de frecuencia de clúster, redes de clúster y base de datos de clúster de los clústeres de conmutación por error de Windows. La frecuencia del clúster se usa para detectar errores. Cada DAG requiere al menos una red de tráfico de replicaciones y al menos una red para MAPI y otro tráfico. La base de datos de clúster almacena cambios en su estado y otra información importante. Cuando agrega otros servidores al DAG, éstos se unen al clúster subyacente y el modelo de quórum del clúster se modifica automáticamente según sea necesario basado en el número de servidores miembro.
Active Manager es el componente de Exchange 2010 que proporciona el modelo de recursos y las características de administración de conmutación por error. Active Manager se ejecuta en todos los servidores de buzón que sean miembros de un DAG y opera como titular de la función principal (Primary Active Manager) o titular de la función secundaria (Standby Active Manager) de una base de datos en particular. El principal decide qué copias de la base de datos quedarán activas y qué copias se activarán. El principal recibe las notificaciones de cambios de topología y reacciona ante errores del servidor. El principal también es dueño del recurso de quórum de clústeres. Si el servidor que actúa como principal arroja error, la función principal pasa automáticamente a otro servidor en el DAG y ese servidor se apropia del recurso de quórum de clústeres.
El secundario detecta errores de bases de datos locales replicadas y la tienda de información local, y emite notificaciones de error al principal, pidiéndole que inicie una conmutación por error. El secundario no determina qué servidor asume el control ni tampoco actualiza el estado de la ubicación de la base de datos. El principal realiza estas tareas. Cuando una base de datos activa arroja error, Active Manager utiliza un algoritmo de selección de mejor copia para seleccionar una copia de base de datos por activar. Este algoritmo identifica la mejor copia de base de datos por activar basado en el estado de la base de datos, el estado del índice de contenido, la longitud de cola de copia y la longitud de cola de reproducción de la copia de base de datos. Si más de una copia de base de datos cumple los criterios de selección, se usa el valor de preferencia de activación, y se activa y monta la base de datos con menor preferencia.
Después de agregar servidores a un DAG, las bases de datos activas en cada servidor se pueden replicar en otros servidores en el DAG y puede configurar otras propiedades del DAG, como cifrado de red o compresión de red para replicación de bases de datos. Dentro de un DAG, los registros de transacciones se replican en cada servidor miembro que tiene una copia de una base de datos de buzón y se reproducen en la misma copia. Después de crear varias copias de bases de datos, puede usar la Consola de administración de Exchange y el Shell de administración de Exchange para monitorizar la replicación y el estado de sus DAG. La conmutación por error de base de datos puede ocurrir automáticamente en caso de una interrupción o bien puede iniciar el cambio manualmente. En un cambio, la copia activa se desmonta y una copia pasiva en otro servidor en el DAG se monta y se vuelve la copia activa.
Simplificación de verdad
Como he explicado en este artículo, Exchange 2010 tiene muchas ventajas importantes que mejoran la disponibilidad, incluida la integración de características de alta disponibilidad en los cambios de arquitectura centrales que mejoran la disponibilidad y más. De todas las características nuevas y cambiadas, los DAG son mis favoritos. Los DAG verdaderamente simplifican las implementaciones de clústeres y le permiten centrarse en lo más importante: los datos. Espero que encuentre útil este artículo y busque mis nuevos libros, “Exchange Server 2010 Administrator’s Pocket Consultant”, “Windows 7 Administrator’s Pocket Consultant” y “Windows Server 2008 Administrator’s Pocket Consultant, 2nd Edition.”
William R. Stanek (williamstanek.com) es experto líder en tecnología, un excelente instructor y el galardonado autor de más de 100 libros. Entre sus libros actuales o próximos se incluyen “Active Directory Administrator’s Pocket Consultant”, “Group Policy Administrator’s Pocket Consultant”, “Windows 7 Administrator’s Pocket Consultant”, “Exchange Server 2010 Administrator’s Pocket Consultant” y “Windows Server 2008 Inside Out”. Siga a Stanek en Twitter en https://twitter.com/WilliamStanek.