Hola amigos,
Mañana estaré charlando online con ustedes sobre tecnologías de Load Balancing para Exchange 2010.
Podrán unirse a la mesa redonda en formato de webcast desde https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032466978&Culture=es-AR
Los espero!
>> Pablo Vernocchi
Circular Logging, o registro circular es una configuración para truncar Transaction Logs que ya fueron comiteados a la base de datos, replicados, inspeccionados y aplicados a bases de datos pasivas y lagueadas.
Continuous Replication Circular Logging está recomendado únicamente si el despliegue de Exchange 2010 cuenta con múltiples copias de las bases de datos de Mailbox, incluyendo copias lagueadas y no se está realizando copia de seguridad de las mismas. De esa manera es como se logra una Organización de Exchange Backup-less.
En cambio, si ya se están tomando resguardos (backups) de las bases de datos, el mismo proceso de backup se encarga de truncar (purgar) los logs que ya fueron resguardados, en ese escenario no se debe habilitar Circular Logging.
Para mayor información sobre Circular Logging y Organizaciones de Exchange sin backup, les recomiendo chequear el siguiente link:
http://technet.microsoft.com/en-us/library/dd876874.aspx (inglés)
http://technet.microsoft.com/es-ar/library/dd876874.aspx (español)
Además, el grupo de producto publicó un artículo con mayor información sobre Circular Logging y backups VSS en: Exchange Circular Logging and VSS Backups
>> Pablo Vernocchi
Muchas veces, tanto en Workshops como en proyectos, los clientes se acercan para consultarme cuál es el comportamiento que tienen los clientes Outlook soportados en Exchange 2010 ante un failover/switch-over y activación de Datacenters de contingencia.
Este es el escenario más simple. Desplegamos nuestra topología de Exchange 2010 compuesta por un CAS Array y un DAG de Exchange 2010 con las bases replicadas en X cantidad de Mailbox Servers. Los perfiles apuntan al Cas Array.
Todos los clientes de Outlook (2003, 2007 y 2010) se comportan de la misma manera en un escenario de alta disponibilidad en un único Datacenter: No hay modificaciones en el perfil de Outlook, ni requiere internvención manual.
Supongamos el hipotético caso de un escenario donde se requiera alta disponibilidad local y, además, un sitio de contingencia remoto. Este escenario se podría diagramar de la siguiente manera (el que me roba el gráfico, le corto los dedos):
En este escenario tendríamos un DAG distribuído en dos datacenters, con un CAS Array para cada Datacenter, Hub Transport y Global Catalogs (que no los dibujé). Para reducir los backups, en el datacenter de contingencia, el servidor MBX-D aloja una base de datos lagueada.
En el caso que la base hosteada en MBX-B hiciese switch over al servidor MBX-A, estaríamos en el caso anterior, donde la conectividad se mantiene dentro del mismo Datacenter y del mismo Cas Array.
¿Qué pasaría si la base se activara en MBX-C?
En este escenario, tanto el Outlook 2003, el 2007 y el 2010 se conectarían a la base de datos del servidor MBX-C a través del servidor CAS-Pri. No habría cambio alguno en los perfiles de los usuarios, ni tampoco impactaría a los mismos.
Los clientes Outlook sólo usarían CAS-Sec si no pudieran conectarse al CAS-Pri, haciendo failover de Cas Array, y ahí él problema estaría en los clientes Outlook 2003, ya que tanto Outlook 2007 como 2010 descubrirían el otro CAS por Autodiscover. Una reparación del perfil de Outlook 2003 cambia el servidor de conexión y resuelve el problema.
Dentro de las propiedades de las bases de datos, podemos asignar cuál es el CAS Array que va a dar conexión a esa base de datos. Suponiendo una activación de la base del MBX-B al MBX-C, podríamos cambiar esa propiedad de la base de datos, y esperaríamos que los clientes de Outlok 2007 y 2010 se conecten a esa base a través del CAS-Sec. Esto no va a suceder, lamento informarles, al menos no hoy con las versiones de Outlook que hay disponbiles. Este cambio de CAS Array podría ser corregido en Outlook 2010 SP1, pero no hay nada confirmado aún.
Si durante la fase de diseño hicimos las cosas bien, en cuanto a diseño de espacio de direcciones y certificados SSL respecta, entonces pasar al Datacenter de contingencia se simplifica a un cambio de registros DNS, cambiando el registro DNS del CAS Array del Datacenter primario al secundario.
Si bien a partir del Service Pack 1 de Exchange Server tenemos la posibilidad de contingencia de Datacenter con SCR, muchas veces no se cuenta con la infraestructura necesaria para poder instalar el servicio de esa manera.
Para esos escenarios, podemos optar por una configuración de cluster CCR distribuído, o geográficamente disperso. Esto quiere decir, instalar un cluster CCR con el nodo activo en un datacenter, y el pasivo en otro (recordemos que CCR sólo permite clusters de dos nodos Activo / Pasivo).
Como pre requisitos:
Antes de comenzar el tema en profundidad, cabe destacar que CCR es un cluster del tipo ‘Majority Node Set’ (MNS), esto quiere decir que al momento de hacer failover al otro nodo, requiere de una mayoría para tomar esa decisión. Es decir, requiere que esté vivo un nodo del clúster y el File Share Witness (FSW).
Dentro del CCR disperso, existen varios escenarios. A continuación, examinaremos cuáles son las posibilidades y las contras de cada uno de ellos.
Figura 1: Escenario de CCR con el Nodo Activo en el mismo Datacenter que el FSW
Este escenario es la instalación que, quizás, se viene a la mente al momento de configurar una solución de alta disponibilidad de CCR.
Figura 2: Escenario de CCR con el Nodo Activo en el Datacenter distinto al FSW
Este escenario habilita algunos casos de failover automático, pero caer en el split brain syndrome es aún más fácil.
Figura 2: Escenario de CCR con el FSW en un tercer Datacenter
Este es el escenario ideal. En este escenario tenemos:
Pablo D. Vernocchi
Microsoft Exchange MVP
MCSE + M / MCSE + Sec
https://mvp.support.microsoft.com/profile/Pablo