Opciones de alta disponibilidad para Exchange 2007 – parte 3

Como tercera parte, cubriremos Cluster Continuous Replication (CCR). Para simplificar el término, CCR es un LCR pero en otro nodo pasivo que, cuando el activo falla traspasa los recursos al nodo pasivo, através de los servicios de Cluster de Windows.

CCR combina la tecnología de Log Shipping y Log Replay con el servicio de Windows Cluster para brindar una solución que:

  • No tiene un punto de fallas único
  • No tiene requerimientos especiales de Hardware
  • Puede ser configurado en uno o dos datacenters distintos
  • Al igual que LCR, reduce la frecuencia de backups.

Al configurar CCR, la primer operación que ocurre se denomina seeding que, básicamente, copia la base de datos del Storage Group al nodo pasivo. Luego que esta operación finaliza, se comienzan las de Log Replay. El comando de PowerShell involucrado en el falivoer es Move-ClusteredMailboxServer. Este cmdlet hace verificaciones para asegurar que el nodo pasivo está listo para recibir los recursos.

CCR combina las siguientes tecnologías para hacer este servicio posible:

  • Failover y virtualización provista por el servicio de Windows Cluster.
  • Transaction Log Replay y Log Shipping de Exchange Server 2007.
  • Una cola de mensajes del Hub Transport llamada Transport Dumpster.

Como la siguiente figura grafica, CCR requiere dos equipos o nodos unidos a un mismo cluster. Estos nodos alojan las bases de datos de buzones, clusterizadas.

 

El cluster utiliza la tecnología ya conocida del servicio de Cluster de Windows, pero agrega una novedad a nivel Quorum. En vez de usar un recurso de cluster, utiliza una nueva tecnología denominada Majority Node Set (MNS) quorum with file share witness.

CCR usa un “testigo” o file share witness en un tercer equipo fuera del cluster, utilizado por los nodos para hacer un seguimiento de cuál nodo tiene el control de los recursos del Cluster. Este recurso es sólo utilizado cuando los nodos pierden comunicación entre ellos, siendo innecesario cuando éstos pueden interactuar entre ellos e intercambiar esta información. El testigo es utilizado cuando:

  • Un nodo del cluster se inicia y sólo un nodo es el activo.
  • Existe un problema en la red que evita que los nodos se intercomuniquen.
  • Un nodo del cluster es quitado.
  • Periodicamente para validación. La frecuencia es configurable.

La carga en el File Server que aloja el “testigo” es muy poca.

Requerimientos

Existen ciertas consideraciones a tener en cuenta antes de implementar este tipo de soluciones:

  • Se debe utilizar una sóla base de datos por Storage Group.
  • Si se cuenta con un sólo servidor de Maiblox en la organización y está en un ambiente de CCR, el servidor puede contener un almacén de Carpetas Públicas. En esta configuración, existe una única base de datos de Public Folders, por lo tanto la replicación está deshabilitada.
  • Si se tienen varios Mailbox Servers, y sólo uno tiene una base de Public Folders, esta base puede estar alojada en un CCR. En esta configuración, existe una única base de datos de Public Folders, por lo tanto la replicación está deshabilitada.
  • Si más de un Mailbox Server tiene bases de datos de Public Folders, y la replicación está habilitada, las Public Folders no pueden estar alojadas en un CCR.
  • Todos los nodos del cluster deben pertenecer al mismo dominio de Active Directory.
  • Exchange Server 2007, en CCR, no está soportado si el servidor es también Domain Controller.
  • Asegurarse que el cluster sea configurado antes de instalar Exchange Server 2007.
  • No pueden existir otras aplicaciones instaladas en los nodos que utilicen el cluster (cluster-aware), como SQL Server o Exchange Server 2000 / 2003. Sí está soportado, por ejemplo, que el nodo corra SQL Server 2005 Express, sin clusterizar.
  • Se debe instalar la misma versión de Exchange Server 2007 en todos los nodos pertenecientes al cluster. Adicionalmente, el Sistema Operativo y los binarios de Exchange deben estar instalado en los mismos path y unidades en ambos nodos.
  • La cuenta de servicio de Cluster debe ser miembro del grupo Administradores local de cada nodo.

Requerimientos de Software

  • Todos los nodos en el cluster deben correr Windows Server 2003 Enterprise, utilizando las mismas unidades para el sistema y booteo.
  • El cluster debe tener instalado el fix 921181 
  • La carpeta compartida para el quorum de MNS no necesariamente tiene que ser un equipo dedicado. En un ambiente con delegaciones de administración, la recomendación es que el quorum resida en un Hub Transport u otro servidor de Exchange, para que pueda ser controlada por un Administrador de Exchange.
  • En CCR sólo se puede instalar el rol de Mailbox Server. No se puede compartir ningún otro rol.

Requerimientos de Red

  • Cada nodo debe contar con, al menos, dos interfaces de red disponibles para el servicio de Windows Cluster. Una interfaz será pública, y la otra para las comunicaciones intra-cluster.
  • Cada nodo requiere una dirección ip estática para cada uno de los adaptadores que serán utilizados por el servicio de cluster. Las direcciones de los adaptadores no pueden estar en la misma subnet.
  • Las interfaces privadas (comunicación intra-cluster) deben estar en la misma subnet.
  • Las interfaces públicas deben estar en la misma subnet.

 

Links recomendados:

Opciones de alta disponibilidad para Exchange 2007 – parte 1
Opciones de alta disponibilidad para Exchange 2007 – parte 2

Saludos,
Vernocchi Pablo

Opciones de alta disponibilidad para Exchange 2007 – parte 2

Siendo la primer opción en la parte 1 de esta serie de notas, nos centraremos en LCR (Local Continuous Replication).

LCR es una solución que involucra un sólo servidor y hace uso de la tecnología de Log Shipping y Log Replay built in en Exchange 2007 para crear y mantener actualizada una copia de un Storage Group determinado en un segundo set de discos, conectados al mismo servidor.

Esta tecnología podría graficarse de la siguiente manera:

 

LCR nos da la posibilidad de, manualmente, switchear a la copia pasiva de las bases de un Storage Group determinado ante una fatalidad. Esta tecnología fue básicamente diseñada para:

  • Reducir considerablemente el tiempo de recuperación por un error a nivel datos.
  • Reducir el número de full backups requeridos para una óptima protección de la información.
  • Reducir el impacto de backups en el rendimiento del servidor. Todos los tipos de backups (full, incremental, diferencial y copia) pueden ser tomados de la copia pasiva del Storage Group.

Cuando sea necesario la copia local del Storage Group pasivo puede convertirse en la productiva. LCR no tiene requerimientos específicos de Storage, todos los medios soportados sirven.

LCR es la opción ideal para aquellas empresas o redes que necesitan soluciones de Disaster Recovery rápidas ante fallas o corrupción en los buzones.

Aunque LCR provea ciertas ventajas ante un backup tradicional, no provee una disponibilidad completa. Básicamente porque reside en un mismo servidor, y lo único que lo separa de la base productiva es subsistema de discos distintos.

LCR será la primer barrera ante una falla en la base de datos productiva y un recovery generalmente toma unos 10 minutos únicamente. Teniendo este tiempo de restore tan bajo, podemos empezar a pensar en cuotas de buzones mucho mayores.

Requerimientos

LCR tiene algunos requerimientos de storage y recomendaciones. Justamente una de las recomendaciones es que el storage que almacenará la copia pasiva sea de la misma capacidad y mismo rendimiento que el de la copia activa. Alguna de las mejores prácticas incluyen:

  • Utilizar una sola base de datos por Storage Group. Cuando se habilita LCR en un Storage Group, éste sólo puede contener una sóla base de datos.
  • No se podrá utilizar LCR en Public Folders si existe más de una base de datos de Public Folders en la organización, debido a la replicación.
  • Particiones para rendimiento y recuperación. Generalmente particionando los discos se obtiene un rendimiento mayor y menor volúmen de datos a restaurar. Debería usarse discos y particiones diferentes para:
    • Archivos del sistema operativo
    • Archivos de aplicación de Exchange
    • Bases de datos activas de Exchange
    • Transaction logs activos de Exchange
    • Bases de datos pasivas de Exchange
    • Transaction logs pasivos de Exchange
    • Adicionalmente, los discos de las copias activas y pasivas deberían estar aislados unos de otros.
  • Asegurar espacio libre adecuado.
  • Asegurar memoria RAM y CPU adecuados para LCR.

Links recomendados:

Opciones de alta disponibilidad para Exchange 2007 – parte 1
Opciones de alta disponibilidad para Exchange 2007 – parte 3

Saludos,
Vernocchi Pablo

Opciones de alta disponibilidad para Exchange 2007 – parte 1

Es, quizás, uno de los requerimientos más solicitados por todos. Tener una alta disponibilidad de servicio de correo y con menor costo. No todas las organizaciones están preparadas para afrontar los costos asociados con las opciones de alta disponibilidad que ofrecen las versiones anteriores de Exchange, por lo tanto en esta nueva versión se establecen nuevas.

  • La primer opción se llama Local Continuous Replication (o LCR). Esta solución implica un sólo servidor que usa tecnología de Log Shipping para crear y mantener una copia de un Storage Group en un segundo set de discos, que están conectados al mismo servidor que el Storage Group. LCR provee log shipping, log replay y la posibilidad de switchear rápidamente a la copia de la base.
  • La segunda opción es Cluster Continuous Replication (CCR). Es una solución de cluster que utiliza la misma tecnología de log shipping que LCR, pero el Storage Group se mantiene en un servidor separado. CCR fue diseñado para estar en el mismo datacenter o en uno remoto, brindando no sólo alta disponibilidad de hardware sino también de sitios.
  • Por último tenemos Single Copy Cluster (SCC). Es una solución de cluster que usa una sóla copia del Storage Group en un storage compartido entre los nodos del cluster. SCC es muy similar a las opciones de cluster de las versiones anteriores de Exchange, con algunos cambios y mejoras.

Tanto CCR como SCC son soluciones que se aplican a cluster con failover. Sólo el rol de Mailbox Server puede ser instalado en esos servidores. Todas las opciones de alta disponibilidad de los roles restantes se pueden obtener con una combinación de redundancia de servidores, Network Load Balancing o DNS Round Robin.

Próximamente estaremos viendo en detalle cada uno de las opciones.

Links recomendados:

Opciones de alta disponibilidad para Exchange 2007 – parte 2
Opciones de alta disponibilidad para Exchange 2007 – parte 3

Vernocchi Pablo.

Nuevos documentos de Exchange Server 2007 – Junio

El team de documentación de Exchange Server anunció nuevo contenido para este mes:

How to Build a Scalable and Available Unified Messaging System

Planear y configurar los servidores de Exchange y los componentes de telefonía para apoyar a los usuarios en la organización.

 

Getting Started with Messaging Records Management

Introducción a MRM conforme a las políticas de la compañía, regulaciones del gobierno o necesidades legales.

 

White Paper: Unified Messaging Concepts and Planning

Consolida la información necesaria para enterder los conceptos de mensajería unificada.

 

Planning for Exchange Server 2007 Client Access Servers

Características y descripción de los protocolos para la configuración del acceso del cliente.

 

Managing Client Access in Exchange Server 2007

Documento de ayuda para la administración y configuración de los servidores para acceso del cliente.

 

Getting Started with Exchange Server 2007

Documento que describe las características y funcionalidad ofrecida por Exchange 2007, los conceptos básicos de la mensajería unificada y los pasos para instalarla.

 

Educating Information Workers About Exchange Server 2007

Información y procedimientos.

 

Saludos

Carlos Salina  | Microsoft MVP Exchange  | Tucumán  | Argentina

GLUE en TechEd 2007

Desde el Domingo 3 de Junio estoy en el Teched 2007 (Orlando, USA) invitado por el equipos de Producto de Exchange en la seccion llamada TLC (Technical Learning Center) http://www.microsoft.com/events/teched2007/default.mspx.


En este evento estan participando 10.000 personas como asistentes de las cuales hay IT Pros de todo el mundo, he tenido la oportunidad de hablar con gente de Brasil, Japon, China, Dinamarca, Noruega, Inglaterra, Puerto Rico. etc.


Realmente este evento es impresionante ya que todos los que asisten tienen la oportunidad de hablar cara a cara con la gente de MS de Redmond.


 


 Carlos Dinapoli – Microsoft Exchange MVP – MCSE 2003 Messaging