Implementaciones de alta disponibilidad

Se aplica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Última modificación del tema: 2008-01-17

Uno de los principales temas de desarrollo relacionados con la alta disponibilidad en Microsoft Exchange Server 2007 era cómo hacer frente al desafío que suponen las opciones de configuración y prácticas de alta disponibilidad presentes en versiones anteriores de Exchange Server. Si se sigue un proceso de planeamiento estructurado con Exchange 2007, se pueden reducir los costos operacionales y de implementación, al tiempo que se proporcionan más servicios a los usuarios finales.

Se han conseguido implementar soluciones de alta disponibilidad de Exchange Server 2003 en producción gracias a Microsoft y a muchos clientes para proporcionar un entorno de mensajería de alta disponibilidad. Además, muchos clientes han implementado correctamente tecnología de replicación en asociado y han creado soluciones que realizan automáticamente la conmutación por error a una segunda copia de los datos cuando se produce un error. Exchange 2007 incorpora mejoras a las soluciones de alta disponibilidad de Exchange 2003, así como nuevas características de alta disponibilidad que eliminan la necesidad de tecnologías de replicación de terceros y reducen los costos y la complejidad de toda la solución. Algunas de las razones clave que están detrás de estas mejoras son consecuencia directa de los comentarios aportados por los clientes:

• El requisito de almacenamiento compartido incrementaba los costos y la complejidad de la solución. Por ejemplo, el hardware de toda la solución debía elegirse en la categoría Solución de clúster del Catálogo de productos comprobados de Windows Server. En Exchange 2007, los clústeres de copia única (SCC) mantienen este requisito, pero no los servidores de buzones de correo en clúster configurados en un entorno de replicación continua en clúster (CCR).

• El uso de una copia única de los datos del buzón implicaba que los errores de dicha copia y su almacenamiento generaban un gran trastorno, se prolongaban las interrupciones o, incluso, se producía una pérdida de datos.

• La ausencia de integración de la instalación y la administración entre el Servicio de clúster y Exchange Server obligaba al administrador de Exchange a entender los conceptos y funcionalidad de los clústeres. Esto representaba una curva de aprendizaje significativa para algunos administradores de Exchange.

• Con los valores de configuración predeterminados de fábrica no se lograban comportamientos de recuperación óptimos. Los administradores debían volver a configurar manualmente los valores y recursos de clúster predeterminados para cumplir con las prácticas recomendadas.

• Todos los servicios de Exchange (acceso de cliente, transporte y almacenamiento) se controlaban usando la misma estrategia de disponibilidad, aunque entre ellos hubiera grandes diferencias de arquitectura como, por ejemplo, la disparidad de estrategias de alta disponibilidad.

• Algunos clientes necesitaban tecnología en asociado para lograr una solución con la que conservar dos copias de sus datos de buzón. Estas soluciones incrementaban los costos y la complejidad de la implementación.

Las soluciones de alta disponibilidad de Exchange 2007 están diseñadas para corregir todas las deficiencias que presentaba el enfoque de la alta disponibilidad en Exchange 2003. Exchange 2007 soluciona dichas deficiencias a través de cambios en la arquitectura, compatibilidad con nuevas configuraciones, cambio de los modelos de administración e incorporación de nuevos enfoques de la alta disponibilidad. El resultado es una solución flexible que aporta a cada organización la libertad para elegir una opción que se adapte a sus necesidades.

Opciones de implementación de alta disponibilidad

La alta disponibilidad debería diseñarse siempre tanto a nivel de componente individual como en el contexto de la totalidad del sistema o solución. Generalmente, existen dos tipos de opción a la hora de implementar la alta disponibilidad para Exchange 2007:

• Implementaciones de centro de datos único con redundancia, que permiten la recuperación automática de algunos errores después de una interrupción breve. En caso de producirse un error en un sitio, una solución de centro de datos único recurre a procedimientos de recuperación de desastres para volver al estado de funcionamiento.

• Implementaciones de centro de datos múltiple con redundancia, que permiten la recuperación automática de la mayoría de errores individuales. Una solución de centro de datos múltiple permite a la organización sobrevivir a un error del centro de datos sin tener que recurrir a procedimientos de recuperación de desastres. Los errores de los que no es posible recuperarse, como un error de la totalidad del sitio, requieren de la intervención manual para la recuperación.

Ambas opciones de implementación se abordan con más detalle más adelante en este tema.

Configuraciones de centro de datos único

En las configuraciones de centro de datos único para las funciones del servidor Mensajería unificada, Transporte de concentradores, Acceso de cliente y Transporte perimetral se ven implicados todos servidores configurados del mismo modo y redundantes. En cuanto a los servidores de buzones, existen tres configuraciones de alta disponibilidad que proporcionan disponibilidad de datos y servicios en un único centro de datos: clústeres de copia única (SCC), replicación continua en clúster (CCR) y replicación continua local (LCR). En la siguiente ilustración se muestra una implementación general de una configuración de centro de datos único totalmente redundante.

Configuración de centro de datos único con redundancia total

En la figura anterior, se abstrae la configuración de redundancia de la función del servidor Buzón de correo. Ello se debe a que existen varias opciones disponibles para una organización, entre las cuales se incluyen diversas configuraciones que usan clúster de copia única (SCC) y replicación continua en clúster (CCR).

Clústeres de copia única

La configuración en clústeres de almacenamiento compartido de Exchange 2007 se denomina clúster de copia única (SCC). Un SCC usa el Servicio de clúster y almacenamiento compartido para hospedar un servidor de buzones de correo en clúster. Un servidor de buzones de correo en clúster es un equipo lógico que se mueve entre nodos físicos mientras esté vigente. Ello es posible gracias a la capacidad del Servicio de clúster para crear y administrar una identidad de red flotante. La identidad de red flotante se usa como identidad de red del servidor de buzones de correo en clúster. El programa de instalación de Exchange crea esta identidad de red automáticamente con el nombre de host y la dirección IP que proporciona el administrador. Esta identidad de red flotante se mueve entre los nodos del clúster, según la disponibilidad del nodo y las necesidades de mantenimiento. Estos mecanismos permiten a los usuarios tener acceso a sus datos de buzón si el almacenamiento está disponible y al menos uno de los dos nodos está operativo. Para que funcione la recuperación de errores, Exchange y el Servicio de clúster funcionan conjuntamente y ponen en conexión el servidor de buzones de correo en clúster en un nodo disponible después de un error.

Las que siguen son algunas mejoras clave de Exchange 2007 respecto a los clústeres de almacenamiento compartido de versiones anteriores de Exchange Server:

• Únicamente la función del servidor Buzón de correo es compatible con clústeres. Es la única función que se puede instalar en un clúster de conmutación por error.

• Los comportamientos de conmutación por error de fábrica se han optimizado para realizar la conmutación por error únicamente cuando existan altas probabilidades de que mejore la disponibilidad. Solamente un error total del nodo o la incapacidad del nodo para comunicar con clientes origina una conmutación por error.

• La mayor parte de la administración se ha movido del Administrador de clústeres a herramientas de Exchange, como es el caso del Shell de administración Exchange. Con ello se reduce la curva de aprendizaje para los administradores de SCC.

• La instalación del servidor de buzones de correo en clúster se ha integrado en el programa de instalación, proporcionando la misma experiencia que una instalación independiente.

La figura siguiente describe una configuración típica de SCC. Una SCC admite hasta ocho clústeres de nodo que tienen al menos un nodo pasivo.

Figura 2   Arquitectura básica de un clúster de copia única

En la figura anterior, los dos nodos están unidos en un clúster de conmutación por error. El clúster usa un disco compartido para administrar el recurso de quórum de clúster, que está representado por el disco Quórum El nodo activo es actualmente propietario de los recursos de disco que guardan los registros y archivos de la base de datos del servidor de buzones de correo en clúster. Las líneas azules del nodo activo a los discos ilustran dicha propiedad. En esta configuración, se obtiene acceso a los discos a través del nodo activo, pero no simultáneamente a través del nodo pasivo.

Los nodos activo y pasivo están conectados al menos por dos redes (privada y mixta). Solamente una de las dos redes se usa para comunicación de cliente (la red mixta). El Servicio de clúster comprueba de forma periódica el estado de comunicación de ambas redes.

Para obtener más información acerca de SCC, consulte Clústeres de copia única.

Replicación continua en clúster

Como su mismo nombre indica, un clúster de copia única contiene una única copia de los datos del buzón. Un error de almacenamiento al hospedar los datos del buzón no da lugar a una recuperación automática. De hecho, dicho error normalmente ocasiona una interrupción extendida y pérdida de datos. Con las mejoras en SCC respecto a soluciones de clúster anteriores se corrigen los problemas que los clientes planteaban en sus comentarios de las anteriores soluciones de alta disponibilidad. No obstante, SCC todavía presenta la dificultad propia del uso de almacenamiento compartido. Tiene al menos dos errores puntuales de fábrica: el disco de quórum único y la copia única de los datos de Exchange. En Exchange 2007, existe un segundo tipo de configuración de alta disponibilidad que proporciona redundancia completa sin necesidad de hardware de la categoría Solución de clúster del Catálogo de productos comprobados de Windows Server. Esta solución se denomina replicación continua en clúster (CCR).

CCR usa transporte de registros asincrónico integrado para replicar datos del buzón entre dos servidores en un clúster de conmutación por error. La integración de la replicación y clústeres permite una solución sin un solo punto de error y proporciona recuperación automática de errores del servidor. Además, elimina la necesidad de almacenamiento compartido, con lo que se reducen los costos de implementación y la complejidad. CCR sólo admite clústeres de dos nodos y dos copias de los datos (la copia activa y la copia pasiva). En la siguiente figura se describe un entorno típico de CCR.

Implementación básica de CCR

Dos cambios significativos que se ilustran en la figura anterior son la ausencia de un disco de quórum compartido y la presencia de un recurso compartido de archivos en un tercer equipo fuera del clúster. El recurso compartido de archivos forma parte de las nuevas capacidades de quórum de clúster incluidas en la actualización descrita en el artículo 921181 de Microsoft Knowledge Base, Existe una actualización disponible que agrega una característica de testigo de uso compartido de archivos y una característica de latidos de clúster configurables para clústeres de servidores basados en Service Pack 1 de Microsoft Windows Server 2003. La actualización permite al Servicio de clúster usar un recurso de quórum que use un recurso compartido de archivos en lugar de un nodo de votante del clúster. Sin la actualización, las únicas opciones de quórum son usar un disco compartido o una configuración tradicional de conjunto de nodos de mayoría, ambas con inconvenientes e incremento de los costos:

• El uso de un disco compartido vuelve a introducir la complejidad del almacenamiento compartido en la solución.

• Los quórum de conjunto de nodos de mayoría requieren tres o más nodos. En esta configuración, se requiere un nodo adicional, conocido como nodo votante, para actuar como nodo votante del clúster.

Para obtener más información acerca de la replicación continua en clúster, consulte replicación continua de clústeres.

Replicación continua local

CCR proporciona redundancia total de los datos y servicios, y SCC proporciona redundancia de servicio. Para las organizaciones que requieran redundancia de datos sin redundancia de servicio, existe la replicación continua local (LCR). LCR no es una solución en clúster y, por lo tanto, no proporciona disponibilidad de servicios. En la siguiente figura se describe un entorno típico de LCR.

Implementación típica de replicación continua local

LCR usa la tecnología de replicación continua integrada descrita en la sección anterior sobre CCR para crear una segunda copia (a la que se denomina copia pasiva) de un grupo de almacenamiento en el equipo local. El equipo debe ser un servidor de buzones independiente (no en clúster). En un entorno de replicación continua local (LCR), el administrador decide qué grupos de almacenamiento tienen una copia pasiva y configura una segunda ubicación para la copia pasiva en el mismo servidor.

Al usar LCR, el administrador debe decidir de manera explícita qué grupos de almacenamiento tienen copias pasivas. Los administradores pueden decidir crear una copia pasiva de un grupo de almacenamiento existente o habilitar LCR para un nuevo grupo de almacenamiento durante el proceso de creación. El administrador debe configurar una segunda ubicación para los archivos de base de datos y registro para aquellos grupos de almacenamiento con LCR habilitado.

En LCR, la activación de dicha segunda copia es manual. No hay conmutación por error en LCR ya que es una operación en clúster y LCR no es una solución en clúster. En lugar de ello, el administrador debe decidir cuándo deja de ser viable la copia activa y, a continuación, activar de manera manual la copia pasiva, lo que la hace la nueva copia activa. El proceso de activación de la copia pasiva es fácil y rápido.

En cualquier momento un administrador puede decidir habilitar LCR y crear una copia pasiva de una base de datos existente o habilitar inmediatamente LCR al crear una nueva base de datos. Una vez habilitada LCR, se crea una copia de línea de base mediante un proceso llamado inicialización y, a continuación, se inicializa la replicación (transporte de registros). Una práctica recomendada consiste en ubicar la copia pasiva en discos o en un contenedor de almacenamiento aislado de la copia activa. Esta práctica minimiza las posibilidades de que se produzcan errores simultáneos múltiples. LCR tiene un impacto de recurso en el servidor de buzones. El servidor de buzones realiza todo el procesamiento asociado a la replicación continua. El planeamiento de la capacidad del servidor debe tener en cuenta este hecho. La carga de entrada/salida (E/S) de la copia activa es limitada debido a que la mayor parte de la actividad de entrada/salida de la copia pasiva está asociada a los archivos de base de datos y registro de la misma.

LCR admite copia de seguridad de la copia pasiva mediante el servicio de instantánea de volumen (VSS) preparado para Exchange. Cuando los volúmenes de disco que contienen la copia activa están separados de manera adecuada de la copia pasiva, las copias de seguridad de VSS sin compatibilidad con VSS basado en hardware son una buena opción. Las copias de seguridad desde la copia pasiva descargan la E/S de copia de seguridad desde los volúmenes de disco de la copia activa. Como la copia pasiva no requiere una respuesta en tiempo real a los clientes, puede acomodar los costos asociados con un escritor de VSS basado en software. Además, en función del diseño de la capacidad, puede resultar práctico extender la ventana de copia de seguridad en el servidor con LCR. El factor clave es mantener la carga de la CPU del agente de copia de seguridad de la ventana de copia de seguridad.

La copia pasiva representa la primera línea de defensa contra daños y errores en los datos. Con LCR, la recuperación del primer error puede tener un contrato de nivel de servicio (SLA) relativamente corto. Un error doble requiere realizar una restauración desde copia de seguridad. Con este modelo, un SLA de un error doble puede ser más largo. Como resultado, una estrategia viable y recomendada es un régimen de copias de seguridad completas semanales, así como copias de seguridad incrementales diarias. Esta estrategia reduce también el contenido total trasladado a medios de copia de seguridad.

En resumen, LCR es una excelente opción para organizaciones que necesitan una rápida recuperación tras un error o daños en los datos, pero pueden permitir paradas de servidor por razones previstas o imprevistas. LCR ofrece las siguientes ventajas:

• Una recuperación rápida en dos pasos tras producirse daños o errores en una base de datos activa.

• Selectividad del administrador, que protege a los usuarios que más lo necesitan.

• Disponibilidad en cualquier tamaño de servidor de buzones y en todos los productos.

• Impacto mínimo en la base de datos activa y E/S de registro.

• Capacidad de descargar E/S de copia de seguridad desde la base de datos activa y volúmenes de registro.

• Capacidad para reducir la totalidad de datos movidos a medios de copia de seguridad, a la vez que extiende la ventana de copia de seguridad.

• Abstracción de administración en el nivel de Exchange mediante el uso de la Consola de administración de Exchange o el Shell de administración de Exchange.

Para obtener más información acerca la replicación continua local (LCR), consulte Replicación continua local.