Comunicaciones

Protección de datos y recuperación ante desastres para Exchange Server 2007

Lee Benjamin

Resumen:

• Copia de seguridad y restauración básicas
• Continuidad de datos
• Tecnologías de réplica
• Soluciones alternativas

Microsoft Exchange Server fue diseñado con la realización de copias de seguridad en mente. Las organizaciones necesitan realizar copias de seguridad de sus datos de mensajería, y deben también poder restaurar esa información. Para satisfacer estas necesidades, Microsoft construyó una variedad completa de opciones de protección de datos, desde las

tradicionales operaciones de copia de seguridad y restauración como soluciones básicas, a la continuidad operativa, pasando por verdaderas soluciones de continuidad de negocio que ofrecen los niveles más altos de disponibilidad y recuperación ante desastres. En este artículo, examino esas opciones y le ayudo a decidir cómo implementar la mejor solución de recuperación de Exchange para su organización.

NIVEL 1: COPIA DE SEGURIDAD Y RESTAURACIÓN BÁSICAS

Puede realizar copias de seguridad de archivos de Exchange si desconecta sus bases de datos, pero también puede realizar copias de seguridad mientras Exchange se ejecuta. De hecho, la manera recomendada de realizar copias de seguridad de Exchange, con frecuencia es la última. Pero Exchange es más que un conjunto de archivos. Es un almacén de información con archivos de base de datos y registros de transacciones de gran tamaño. Los mensajes enviados a Exchange se registran inmediatamente en los registros de transacciones y cuando el sistema tiene algunos ciclos de reserva (generalmente sólo unos pocos milisegundos más tarde), los mensajes se copian en la misma base de datos. Al obtener la información en el disco lo más rápido posible, Exchange ofrece un muy alto nivel de capacidad de recuperación. Lo fundamental para restaurar Exchange es la disponibilidad de ambos conjuntos de información. Si el sistema falla, la combinación de una copia de seguridad previa, junto con la totalidad de transacciones a partir de ese punto, le permite restaurar Exchange con la información más reciente. Observe que Exchange reproduce automáticamente las transacciones en una base de datos restaurada según sea necesario.

El modo en que los programas de copia de seguridad tienen acceso a información en la base de datos de Exchange es a través de la API de copia de seguridad del Motor extensible de almacenamiento (ESE) o de soluciones de VSS más nuevas que trataré más adelante. Siempre que se inicia una copia de seguridad de ESE, Exchange suspende temporalmente todas las escrituras a sus bases de datos. Al mismo tiempo, ESE establece temporalmente la base de datos en modo de sólo lectura para que se pueda copiar en una copia de seguridad completa, y también usa una base de datos temporal para guardar las nuevas transacciones que tienen lugar durante la copia de seguridad. Cuando se completa la copia de seguridad, ESE devuelve la base de datos a su modo normal de lectura/escritura y aplica las transacciones acumuladas en su base de datos temporal. La copia de seguridad también purga los antiguos registros de transacciones cuando el proceso finaliza de manera correcta.

Aunque este proceso de copia de seguridad es sencillo y transparente, incluso para los usuarios que inician sesión por la noche mientras el proceso se encuentra en ejecución, ESE puede tardar mucho tiempo en completarse, especialmente porque las bases de datos de Exchange pueden variar en cualquier tamaño, desde pocos gigabytes, a unos administrables 30 a 50, o incluso hasta 100 GB (cuya copia de seguridad se hace casi imposible en una noche con tecnologías estándar). Para hacerse una idea de las opciones disponibles al usar NTBackup.exe, observe la figura 1.

Figura 1** Uso de la utilidad NTBackup **

Prácticas recomendadas para Exchange

Si desea que se pueda realizar una recuperación rápida ante errores comunes de hardware y del sistema, debe ejecutar copias de seguridad completas de Exchange por la noche. Para mejorar el rendimiento y la capacidad de recuperación siempre que un servidor Microsoft Exchange use discos locales, es importante usar matrices RAID separadas para almacenar las bases de datos y los registros de transacciones de Exchange. De esta manera, si se producen errores en el controlador de matriz RAID, o en más de un disco en la matriz de manera que los discos restantes ya no puedan regenerar los datos seccionados, todavía le será posible recuperar. Si pierde los registros de transacciones, todavía tendrá en las otras unidades de disco las bases de datos actualizadas de Exchange, que le permitirán continuar las operaciones normales con nuevos registros de transacciones. Si pierde las unidades de disco con las bases de datos, su estrategia de recuperación será volver a su copia de seguridad completa de las bases de datos de Exchange de la noche anterior y, a continuación, aplicar los registros de transacciones del día para actualizarlas.

Es importante que limite el tamaño de sus bases de datos de Exchange para que en cada una sea posible realizar la copia de seguridad y restaurar (lo que es más importante) en una cantidad de tiempo razonable. En la mayoría de las organizaciones, esto significa mantener el tamaño de las bases de datos entre 30 y 50 GB. Cuando una base de datos crece más allá de ese tamaño, es conveniente dividirla en múltiples bases de datos para que la restauración sea más fácil de administrar.

Copia de seguridad y restauración continuas

La ubicación de las bases de datos y los registros de transacciones es muy importante; no sólo para el rendimiento de la copia de seguridad sino también para la velocidad de recuperación. Hoy en día, todos los servidores admiten distintos niveles de redundancia de unidad de disco, lo que se conoce como RAID. Básicamente, RAID permite que los errores en una unidad no bloqueen el sistema, aunque el rendimiento del sistema será menor hasta que el disco se reemplace y reconstruya. Hasta ese momento, el controlador de matriz debe regenerar los datos de los discos restantes sobre la marcha en respuesta a cada solicitud de acceso al disco. Para obtener más información sobre el diseño de almacenamiento para servidores de correo, consulte la nota técnica de Microsoft IT Showcase "Pasar a 64 bits con Exchange Server 2007".

Una característica principal de Exchange es su diseño de base de datos de instancia única. Esto significa que en el interior de una base de datos de Exchange se almacena una única copia de un mensaje específico junto con un único dato adjunto (si existe). Si el mensaje fue enviado a múltiples recipientes en el mismo almacén de información, se crean punteros adicionales a los objetos (mensaje, datos adjuntos), pero no se duplican los objetos. Esto no sólo significa un enorme beneficio de eficiencia de entrega, sino que además economiza espacio para Exchange, tanto en disco como en cinta.

Aunque Exchange es bueno en recuperar la base de datos completa, cuando es necesario restaurar buzones, carpetas o mensajes individuales, se debe recuperar primero la cinta completa. No es sorprendente que los usuarios desearan capacidades de restauración más específicas. La instancia única en cinta hace que sea muy complicado. Los proveedores de copia de seguridad responden a esta necesidad con la "copia de seguridad de nivel de bloque" (que no recomiendo). Una vez que finaliza una copia de seguridad completa de la base de datos de Exchange mediante la API aprobada de copia de seguridad de ESE, los productos de copia de seguridad agregan a continuación cada buzón a la cinta de copia de seguridad. Debido a que la API de copia de seguridad no ofrece una manera de extraer los datos de buzones individuales, se usa MAPI. Como resultado, la cinta de copia de seguridad es bastante más extensa porque duplica todos esos mensajes y datos adjuntos.

Microsoft ha realizado algunas mejoras que solucionan parcialmente el problema. Por ejemplo, la papelera administrativa (o contenedor) mantiene los elementos del entorno un cierto tiempo después de ser eliminados por los usuarios por si acaso se necesitan. Además, ya no es necesario mantener un servidor de reserva como entorno en un bosque de recuperación de Exchange; los grupos de almacenamiento de recuperación permiten a un administrador montar parcialmente las bases de datos restauradas que se recuperan de la cinta, y copiar o combinar los datos hasta el nivel inferior del buzón.

La práctica hace al maestro

Muchas organizaciones aprenden del modo más difícil que independientemente del nivel de copia de seguridad y recuperación que decidan, los procedimientos para medios de copia de seguridad y recuperación se deben probar con frecuencia. Demasiados administradores conocen si sus procedimientos de copia de seguridad y restauración realmente funcionan sólo después de un desastre. El mejor momento para probar es el día después de generar y configurar el nuevo servidor, cuando está operativo como parte de su organización Exchange, pero sólo tiene algunos usuarios. En ese momento debe realizar una copia de seguridad completa de Exchange y copias de seguridad regulares de sus unidades de disco. También debe capturar el estado de sistema, lo que incluye los archivos críticos en el disco de sistema así como la metabase IIS (donde se mantiene la configuración de enrutamiento de Exchange). A continuación, vuelva a formatear con calma el servidor y comience de nuevo, actualizando las notas que tomó al crear inicialmente el servidor. Debería poder restaurar la configuración a partir del estado de sistema, pero también contar con la documentación adecuada para volver a implementar manualmente los valores de configuración del sistema.

El tiempo que emplea en este simulacro de incendio reducirá apreciablemente su tiempo de recuperación en el futuro. Repita el proceso de manera periódica. Y al mismo tiempo, mida el tiempo que emplea para recuperar datos de las cintas fuera de sitio. Aquellos que se han visto afectados por ese intervalo aparentemente interminable con frecuencia comienzan a pensar seriamente acerca de cómo las copias de seguridad de disco a disco pueden ser una parte importante en su estrategia de copia de seguridad y restauración; incluso si el almacenamiento en cintas fuera de sitio sigue ofreciendo su último respaldo para recuperación ante desastres (DR).

Desafíos de la copia de seguridad en cinta

Restaurar de cinta requiere demasiado tiempo. Exchange es ahora tan crítico para las organizaciones que los usuarios y la administración esperan que siempre esté disponible. Cuando ocurre un problema grave, la mayoría de las organizaciones se encuentran desprevenidas. Nadie está preparado para escuchar que se necesitarán ocho horas para restaurar esa base de datos de 75 GB de cinta; y ello no incluye el tiempo que se dedica para obtener las cintas de la instalación de almacenamiento fuera de sitio o en volver a instalar el sistema operativo.

Además, también existe el desafío de recuperar de cinta la base de datos correcta. En los 10 años desde que Exchange se lanzó por primera vez al mercado, el costo de almacenamiento en discos y redes de área extensa ha caído considerablemente. Como resultado, muchas organizaciones pueden afrontar métodos más rápidos de copia de seguridad y restauración. Es posible que estas organizaciones aprovechen las tecnologías que les permitan obtener continuidad operativa y recuperación ante desastres para su infraestructura de Exchange.

NIVEL 2: CONTINUIDAD OPERATIVA

La continuidad operativa es un conjunto de procesos y tecnologías que pretende hacer que la recuperación sea lo más rápida posible, minimizando tiempos de inactividad inesperados. La continuidad operativa ofrece objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO) sobre cinta para la recuperación local. Se esfuerza por eliminar, donde sea posible, el tiempo que se necesita para recuperar los datos de cinta en el sitio. Observe la figura 2 para comparar la continuidad operativa con copia de seguridad, restauración y la recuperación ante desastres.

Figura 2** Recuperación continua **(Hacer clic en la imagen para ampliarla)

Este diagrama muestra la recuperación y disponibilidad continuas desde lo más lento y económico en la parte inferior izquierda hasta lo más rápido y costoso en la parte superior derecha, con una transición deliberadamente borrosa entre soluciones de continuidad operativa y recuperación ante desastres.

El gráfico le ofrece una idea de los equilibrios entre costos, tiempos de recuperación y disponibilidad entre estos enfoques. En este artículo, distingo claramente de manera intencional entre procesos de continuidad locales y recuperación ante desastres. La recuperación ante desastres siempre se ve como remota, con la obtención de datos fuera de sitio como un objetivo principal. La distancia presenta desafíos adicionales y es típicamente mucho más costosa, pero la recuperación ante desastres se centra en la continuidad del negocio después de eventos catastróficos. Trataré esto con detenimiento más adelante.

Un poco de historia

Cuando Exchange se convirtió en una parte más esencial de la infraestructura y en sus bases de datos comenzó a almacenarse más información, era claro que se debían reducir los tiempos de la copia de seguridad y restauración. Trabajando con Microsoft, algunas organizaciones grandes propusieron un enfoque que ofrecía un resultado con muchas mejoras en las operaciones parciales. Si una organización podía recibir y enviar nuevo correo electrónico al mundo exterior, parecería como si nada hubiera sucedido. Después de todo, las apariencias importan.

Para implementar esta restauración con "señal de marcado" para Exchange, se ponía una nueva base de datos vacía en el lugar de la dañada. Exchange y Active Directory® creaban a continuación nuevos buzones con los permisos apropiados, y los usuarios podrían enviar y recibir correo. Una vez que la cinta de copia de seguridad y los datos se recuperaban, se podrían montar administrativamente. El administrador de Exchange combinaría entonces los buzones restaurados con los buzones con señal de marcado. Se podría establecer la prioridad de los buzones según sea necesario. Aunque representa una mejora, era un proceso complejo que demandaba tiempo, y que originalmente usó EXMERGE. Luego se adaptó a grupos de almacenamiento de recuperación. No obstante, se debe considerar que esa restauración completa de datos después de un escenario de recuperación con señal de marcado puede ser una tarea ardua y complicada (especialmente cuando en Exchange 2007 son posibles hasta 50 grupos de almacenamiento). Si considera implementar un escenario de recuperación con señal de marcado, tenga cuidado en asegurar que las ventajas compensarán el esfuerzo.

Servicio de instantáneas de volumen

Para aprovechar los discos más económicos y quitar la sobrecarga de procesador de los servidores Exchange en producción, se desarrolló una API de copia de seguridad para Microsoft® Windows Server® 2003 y Exchange. Se creó el servicio de instantáneas de volumen (VSS) para hacer copias de datos coherentes a un momento dado. Estas instantáneas son copias rápidas de sólo lectura de los datos de Exchange que incluyen sucesivamente sólo los datos que han cambiado. Las copias señalan generalmente a otro servidor con espacio en disco disponible o a una red de área de almacenamiento (SAN). Se pueden conservar múltiples instantáneas, con copias de seguridad realizadas en cinta. Como resultado, el servidor Exchange en producción ya no tiene que sufrir el impacto de rendimiento del software de copia de seguridad y el gasto de la copia en cinta.

Existen ventajas al usar VSS para la protección de datos de Exchange. En primer lugar, se puede quitar la carga de rendimiento de las operaciones de copia de seguridad en cinta del servidor Exchange. Aunque todavía es necesario realizar la copia de seguridad en cinta, puede usar la copia de los datos de Exchange y no afectar al rendimiento de usuario. En segundo lugar, es posible tomar instantáneas con más frecuencia que una vez por noche. Y, como ventaja adicional, puede mantener múltiples instantáneas en el servidor secundario o en otro almacenamiento local.

Existen en el mercado varios productos de terceros que aprovechan las capacidades de las instantáneas VSS. Algunos simplemente reducen el tiempo necesario para realizar copias de seguridad y restaurar bases de datos de Exchange, mientras que otros agregan capacidades tales como una recuperación más específica que la incluida en Exchange de manera nativa por lo que puede restaurar hasta el nivel de buzón. Mientras nadie quiere tales copias de seguridad en bloque, las personas desean que se pueda restaurar carpetas específicas o bien mensajes individuales.

Tecnologías de réplica

La conmutación por error de Exchange mediante software es una opción que ofrecen algunos proveedores de réplica. Hace que un servidor Microsoft Exchange en modo de espera se active y que a continuación le diga a Active Directory que todos los buzones de usuarios se han movido. Hay dos maneras de realizar esto, y ambas requieren algunas personalizaciones en Exchange y entornos de Windows. Una implica engañar a su DNS para que el servidor en modo de espera tome el nombre y la dirección IP del servidor con errores. Este enfoque tiene la ventaja de ser sencillo en las estaciones de trabajo cliente porque Outlook® aún piensa que usa el mismo servidor.

El segundo enfoque usa un servidor en modo de espera que ejecuta Exchange y que mantiene copias de la base de datos pero ninguna está montada. Ante un error, el servidor en modo de espera notifica a Active Directory que todos los buzones de usuario se han movido al mismo. Entonces se ejecuta un script, o se distribuye una directiva de grupo, que le dice a los clientes que están en un servidor de correo diferente. Outlook 2007 reconoce Active Directory, lo que hace que el proceso sea más fácil porque resolverá automáticamente estas asignaciones por su cuenta.

Clúster local con MSCS

En un nivel superior en la disponibilidad continua se encuentran los Servicios de Cluster Server de Microsoft (MSCS); Exchange es una aplicación compatible con clúster. El clúster comparte información entre dos o más equipos para que si uno presenta errores, los otros puedan hacerse cargo. Hoy en día, la mayoría de los clústeres de Exchange están compuestos por dos o cuatro nodos, aunque se pueden usar hasta ocho nodos. Un nodo siempre se designa como pasivo, operativo, con Windows Server en ejecución y Exchange Server instalado, pero sin buzones activos. En Exchange 2003 era posible tener un clúster activo/activo de dos nodos, pero debido a las cargas de rendimiento, ahora no es recomendable y no será compatible con Exchange 2007.

Al igual que la disposición de clúster de Exchange 2003, los clústeres de Exchange 2007 que incluyen un nodo pasivo todavía pueden usar una única matriz compartida de almacenamiento. Aunque las matrices de almacenamiento con calidad para clúster típicamente incluyen varias características de redundancia para resistir a muchos tipos de errores, todavía ofrecen una única copia de los datos, lo que deja abierta una ventana de vulnerabilidad. Por eso estos clústeres se denominan clústeres de copia única (SCC), para distinguirlos de la próxima frontera en protección de datos que llega con los clústeres de copias múltiples (MCC) en Exchange 2007. Trataremos los MCC más adelante cuando veamos la recuperación ante desastres.

Replicación continua local

La Réplica continua local (LCR) es una nueva característica de Exchange 2007 que ofrece mejoras en la manera de mantener una segunda copia de las bases de datos y los registros de transacciones de Exchange dentro del mismo servidor. Esto agrega un nivel de redundancia a la recomendación de tener la base de datos de Exchange en una matriz RAID y los registros de transacciones en otra: LCR permite almacenar una copia secundaria de los registros en la matriz que almacena la copia principal de la base de datos y, a continuación, almacenar una copia secundaria de la base de datos en la matriz que almacena la copia principal de los registros (consulte la figura 3). Si se produce un error en el controlador RAID o la matriz, todavía dispondrá de la base de datos y los registros de transacciones en la otra matriz. De este modo, puede seguir operando (aunque un poco nervioso y con alguna degradación del rendimiento) hasta que pueda regenerar la matriz con errores.

Figura 3** Configuración de LCR **

LCR es una solución de continuidad operativa local, no una solución de copia de seguridad, así que todavía necesitará una estrategia de copia de seguridad completa. Con LCR, hay también un impacto en el rendimiento porque ahora el servidor realiza dos copias de la base de datos y los registros de transacciones. Además, en la implementación de Exchange 2007, existen algunas limitaciones que harán que LCR sólo sea conveniente para organizaciones más pequeñas, porque sólo admite una única base de datos en un grupo de almacenamiento y una única base de datos de carpetas públicas en una organización.

La conmutación por error mediante una recuperación de LCR no es instantánea; un profesional de TI con experiencia tendrá que ejecutar scripts para recuperar Exchange. El proceso requiere la ejecución de comandos del shell de administración de Exchange que se ejecutan fuera de la consola de administración de Exchange.

Donde Exchange Server 2003 Enterprise Edition permitía que una organización ejecutara hasta 20 bases de datos de Exchange (cuatro grupos de almacenamiento de hasta cinco bases de datos cada uno), Exchange 2007 Enterprise Edition permite hasta 50 grupos de almacenamiento, cada uno con su propia base de datos. Los registros de transacciones también se han reducido de archivos de 5 MB en Exchange 2003 a archivos de 1 MB en Exchange 2007. Ambos cambios están diseñados para admitir LCR más réplica continua en clúster (CCR), que abordaré en un instante.

Las organizaciones pequeñas y medianas usarán LCR para ofrecer una protección mejorada de datos para sus operaciones de Exchange. LCR es fácil de implementar pero todavía supone la intervención manual. Como solución en disco local y en el mismo servidor, LCR sólo es un primer paso hacia una continuidad operativa mejorada. Si bien protege contra errores de una matriz y controladores RAID, los bloqueos de múltiples discos simultáneos o errores de controlador RAID son relativamente raros. La mayoría de las veces, los escenarios de error implican el colapso del servidor entero, lo que nos conduce al paso siguiente en la protección de Exchange.

Réplica fuera de host local de terceros

Para fomentar las capacidades de recuperación de Exchange, otros proveedores han desarrollado productos que aprovechan la réplica "fuera de host" usando archivos de registro de Exchange para mantener una copia en modo de espera de la base de datos de Exchange en otro equipo. En este caso, la protección de datos o solución de archivado realiza una copia de seguridad completa de ESE de Exchange en un equipo diferente y extrae los registros de transacciones en cuanto Exchange los cierra. A continuación, inserta esas transacciones en su copia de la base de datos de Exchange para que se mantenga siempre actualizada. Como he indicado, estos registros son relativamente pequeños (5 MB en Exchange 2003 y 1 MB en Exchange 2007), por lo que una vez que se completa la copia de seguridad, casi no existe sobrecarga en el servidor Exchange al copiar estos archivos de registro al servidor fuera de host.

NIVEL 3: RECUPERACIÓN ANTE DESASTRES Y ALTA DISPONIBILIDAD

La recuperación ante desastres es la capacidad de recuperar y poner en funcionamiento el sistema cuando el principal centro de datos deja de estar disponible. Exchange merece una recuperación ante desastres eficaz porque el correo electrónico y el calendario son el elemento vital de muchas organizaciones actuales.

Algunas compañías se imaginan que sus copias de seguridad en cinta tradicionales almacenadas fuera de sitio son una forma de recuperación ante desastres, pero si el único centro de datos se destruye a causa de un incendio o una inundación, un camión que regrese con los carretes de cintas tiene escaso valor. La recuperación ante desastres implica necesariamente mover no sólo los datos a una ubicación alternativa, sino también la tecnología y los procesos necesarios para recuperar y poner en funcionamiento la aplicación. Para que sea eficaz, la recuperación ante desastres depende de sistemas principales y secundarios separados por alguna distancia. Cuán lejos se encuentren los sitios debe depender de la magnitud del desastre del que se preocupa por superar. Si está preocupado por el riesgo de incendios, quizás otro edificio en su campus esté suficientemente apartado. Sin embargo, los desastres de infraestructura que implican trenes o aviones podrían tener un impacto en un radio de un kilómetro o más. Muchos desastres son regionales: inundaciones, tormentas de hielo, terremotos e incluso cortes del suministro de energía. Las comunicaciones pueden sufrir sus propias calamidades; desde una excavadora que corta el vínculo a su ISP, hasta ataques de denegación de servicio, pasando por ataques DoS de Internet destinados al comercio en general.

Como cuestión práctica, si la organización ya cuenta con más de un sitio con personal de TI, quizás una de esas ubicaciones cumpla sus criterios para continuidad operativa remota, dados los tipos de desastres contra los que se defiende. El uso de instalaciones y personal propias representará costos mucho menores que la contratación de un proveedor de recuperación ante desastres o el alquiler de espacio en una nueva ubicación.

En última instancia, la recuperación ante desastres es también una cuestión de percepción: dar a sus clientes la confianza que todavía realiza su actividad comercial. Las personas entienden cuando un desastre afecta a una ciudad o área, pero si la compañía no vuelve a estar operativa en un par de días o una semana, es probable que los clientes y proveedores crean lo peor; muchas compañías cometen errores por ese motivo. A los clientes les debe parecer que las operaciones se recuperan, para garantizarles que el negocio continúa. Los clientes tendrán diferentes ideas respecto de la recuperación oportuna: son, con razón, menos pacientes con interrupciones de las compañías de servicios financieros que con, por ejemplo, interrupciones en las actividades de los proveedores de muebles de oficina.

Demandas de la recuperación ante desastres

Para poder poner Exchange de nuevo en línea después de un desastre se requiere replicar sus datos al sitio secundario y usar tecnología de réplica que esté preparada para presentar los datos a un servidor Exchange secundario que esté listo para ejecutarlos, y a continuación, notificar a los clientes de Outlook que se han movido sus buzones.

Exchange es una aplicación exigente para la réplica, especialmente sobre grandes distancias. Como verdadera base de datos transaccional, el orden de cada escritura es sumamente importante. Para complicar el desafío, el protocolo de transporte que Exchange usa para comunicar todas las transacciones e información de sistema entre servidores es SMTP, un protocolo conocido que hace un uso intensivo del ancho de banda. Además, con clústeres de Exchange se debe mantener un latido entre sistemas cada 500 milisegundos. Si un nodo secundario no recibe ese latido, puede activar el comienzo de una conmutación por error.

Las complejidades para administrar tales desafíos pueden ser el motivo por el cual Microsoft recién ingresa en este espacio con Exchange 2007. En ausencia de una participación de Microsoft, se han desarrollado varias soluciones de terceros para replicar los datos de Exchange mediante réplica basada en host o réplica basada en matriz.

Los proveedores se dieron cuenta de que podían extender un clúster al dispersar los nodos en diferentes ubicaciones; esto se denomina clúster extendido. Hoy en día, la manera más común de implementar clústeres extendidos es a través de productos de réplica de datos de terceros de uso general o específicamente dirigidos a extender un nodo de Exchange. Esto se puede realizar con MSCS, pero los requisitos de subred son un desafío sobre una WAN. El clúster y las complejidades del aprovisionamiento confiable de conectividad con alto ancho de banda a centros de datos remotos aumenta de manera comprensible los costos y requisitos de personal para crear, mantener y probar periódicamente sistemas de recuperación ante desastres.

Replicación continua en clúster

Microsoft extiende su compatibilidad con clúster mediante la réplica continua en clúster de Exchange 2007. CCR extiende la capacidad de LCR para mantener dos copias de una base de datos y los registros de transacciones de Exchange al implementar la misma idea en dos nodos de clúster. La recuperación ante desastres implica la separación geográfica de sistemas principales y secundarios, y los clústeres de copias múltiples de Microsoft (MCC) no podrán abarcar distancias considerables hasta Windows Server 2008, anteriormente designado con el nombre en código "Longhorn", que hace posible los clústeres extendidos.

La tecnología que permite que los nodos MCC mantengan copias separadas de los datos se denomina conjunto de nodos mayoritarios (MNS), que se refiere al proceso de elección que dos o más nodos realizan para determinar cuál de ellos mantiene la copia activa de los datos. Cuando hay errores, los nodos restantes mantienen una nueva elección para determinar cuál asumirá el trabajo de nuevo servidor de procesamiento principal o de datos. Esta democracia técnica recibe el soporte de CCR, que se asegura que cada nodo tenga una base de datos actualizada. Los clústeres de Exchange 2007 que usan CCR están limitados sólo a dos nodos.

En compañías de mayor tamaño, los servidores Exchange configuran típicamente el disco local de sistema en el mismo servidor y se conectan a la base de datos de Exchange sobre una SAN mediante SCSI, fibra o matrices de disco iSCSI. Con un clúster MCC/MNS, una pregunta interesante es si el almacenamiento avanzado de Exchange evolucionará volviendo a usar matrices locales RAID en cada nodo. Si el propósito de un clúster de MNS es habilitar cada nodo para que tenga su propio almacenamiento separado, ¿tendrá todavía sentido que cada nodo señale a una SAN cuyo propósito principal es ofrecer almacenamiento común?

Un probable escenario intermedio de clúster MCC/MNS tendría el nodo principal con almacenamiento en la SAN y un nodo de clúster secundario con almacenamiento en discos locales o bien en una SAN con iSCSI de bajo costo. Este nodo secundario podría estar alejado del centro de datos principal, en una ubicación que no disponga de una infraestructura SAN.

Independientemente de cómo se presente, MCC mediante MNS y CCR son otro avance en la jerarquía de redundancia y mejora de disponibilidad porque la capacidad de conmutación por error reside en múltiples equipos y los datos se replican en elementos de almacenamiento separados. No obstante, se encuentra completamente reducido a un solo centro de datos hasta la llegada de Windows Server 2008. Windows Server 2008 será compatible de forma nativa con clústeres extendidos y permitirá que los nodos en un clúster MNS se encuentren geográficamente tan separados como se desee, siempre y cuando la latencia de red entre nodos sea menor que 500 ms, de manera confiable. Hasta entonces (y más allá), la tecnología de clúster de terceros puede posicionarse por encima de MNS y CCR de Microsoft para ofrecer la separación geográfica necesaria para que los clústeres extendidos sean una solución eficaz de recuperación ante desastres.

El clúster se encuentra entre las tecnologías avanzadas de recuperación continua ante desastres y CCR está posicionado apropiadamente como una capacidad avanzada de Exchange. Y aunque su combinación implicará gastos en costo y personal, promete ser una emocionante solución del más alto nivel para clientes que deseen ejecutar un entorno de Microsoft homogéneo.

Continuidad operativa remota y de terceros

No cabe duda que la solución de Microsoft y las extensiones de terceros ocuparán el mayor nivel de la recuperación continua cuando estén disponibles. La conmutación por error automática realizada en pocos segundos; es un concepto inmejorable. Aunque no todas las compañías necesitan ese nivel de disponibilidad y continuidad de negocio, ni pueden afrontar la inversión de cientos de miles de dólares necesarios para entregarla. Para muchas compañías, una solución segura que restaure completamente Exchange en minutos proporcionará toda la continuidad operativa que necesitan.

Por ejemplo, Mimosa Systems, Inc. extiende hacia una continuidad remota la continuidad operativa dentro de un único centro de datos. En una ubicación remota, Mimosa DR conserva una copia de Exchange, la mantiene actualizada con los registros de transacciones suministrados por el servidor Exchange principal y está siempre listo para poner esta copia activa a disposición del servidor Exchange en modo de espera. El servidor Exchange remoto usa hardware estándar de servidor y, como en la implementación de un único centro de datos, se mantiene preparado y siempre listo para ser activado en caso de un desastre. Si ocurre el desastre, un operador en el sitio remoto inicia la conmutación por error y la lleva a cabo, incluido el montaje de los archivos de la base de datos en modo de espera y la reasignación de buzones y perfiles de Outlook. No obstante, se debe tener en cuenta que estas soluciones de terceros están sujetas a los límites de compatibilidad definidos en el artículo de Microsoft Knowledge Base "Directiva de compatibilidad de Microsoft para productos de terceros que modifican o extraen contenido de la base de datos de Exchange".

Conclusión

La protección de datos de Exchange está disponible como una continuidad de tecnologías y procedimientos que se pueden agrupar en tres niveles según el costo y las capacidades. Cuando comienza a pensar en los requisitos para la protección de datos de Exchange, debe considerar cuánto tiempo de inactividad pueden tolerar los interesados. Mayor rendimiento y recuperación más rápida cuestan más, con opciones avanzadas cuyo costo puede alcanzar importes de seis cifras. Existen soluciones más económicas que se acercan, pero que no alcanzan exactamente, los niveles más altos de disponibilidad. Las decisiones que tome deben reflejar las verdaderas necesidades de la organización.

Service Pack 1 para Exchange 2007

Actualmente como versión beta en fase de prueba, se espera que el Service Pack 1 (SP1) para Exchange 2007 incluirá varias características que les faltaba a los administradores, incluidas mejoras en OWA, capacidades adicionales de GUI en la consola y mucho más.

De particular interés para administradores que planean soluciones de recuperación, Exchange 2007 SP1 también incluye una tercera solución de disponibilidad para complementar LCR y CCR: la Réplica continua secundaria (SCR). Se trata de un enfoque de término medio y Microsoft mira a ese lugar propicio de mayor capacidad de recuperación, que no tiene la complejidad de la "alta disponibilidad" completa.

SCR permitirá la réplica de la base de datos y los registros de transacciones de Exchange a un servidor Exchange diferente del servidor en que típicamente residen los buzones. El objetivo de SCR puede ser local o remoto y puede ser un clúster o un servidor Exchange en modo de espera. Sin embargo, SCR no requiere un clúster en ninguna de las ubicaciones y difiere de CCR en que el objetivo es un entorno en modo de espera y la conmutación por error es un proceso manual. Tenga en cuenta que todavía necesita obtener esa primera gran copia a través del cable; esencialmente una copia de seguridad completa. Es posible que necesite realizar periódicamente esta gran réplica y debe conocer las implicaciones para la red, al igual que con CCR y las soluciones de terceros. Espero ver una adopción significativa tanto de SCR como de CCR, y de productos adicionales que ofrecen capacidades similares y a veces mayores.

Lee Benjamindirige ExchangeGuy Consulting Services donde trabaja directamente con clientes y aconseja a asociados de Microsoft. Lee es presidente del mayor grupo de usuarios de Exchange en el mundo, ExchangeServerBoston, y director de BostonUserGroups. Lee también es MVP de Exchange, Microsoft Certified Trainer y un orador frecuente en conferencias del sector.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.