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