Implementando DAG en Exchange 2010 (Parte I)

LatamBlog
29 Mar 2010 7:59 PM

por Daniel Seveso

Database Availability Group (DAG) es el nico mtodo de proveer alta disponibilidad a

una base de datos en Exchange 2010. En un artculo previo, describo qu es un DAG y sus
principales caractersticas.
Este artculo es una referencia de cmo implementar un "Database Availability Group" en
Exchange 2010.
Para esta configuracin utilizar dos servidores de Exchange para formar una solucin de
dos DAG, aunque podramos utilizar hasta 16. Todos los roles estarn instalados en cada
mquina. Utilizar un controlador de dominio separado, respetando la tan importante
recomendacin de Microsoft "Nunca instalar Exchange en un controlador de dominio", ya
que no hace ms que traer dolores de cabeza.
Montar todo el laboratorio en Hyper-V server, as que Uds. tambin pueden tratar de hacer
esto en casa :). Usar Windows 2008 SP2 para la instalacin de cada servidor de Exchange.
Asumimos que los prerequisitos para instalar Exchange 2010 ya estn configurados.
Windows 2008 debe ser "Enterprise Edition" para poder participar en un DAG ya que
requiere el servicio de "Microsoft Failover Cluster"

Pausa...
OK, me escucharon decir DAG, Cluster y "todos los roles" (en un cluster??). Si estn
sorprendidos, deberan leer el captulo "Understanding High Availability and Site
Resiliance", o confiar ciegamente.

Sigo...
Contamos con dos tarjetas de red en cada servidor, LAN: conectada a nuestra red de
produccin y Repl: conectada a la red de heartbeat.

La tarjeta de heartbeat (Repl) no debe tener "Default Gateway" configurado.

Tampoco marcada la opcin "Register this connection's addresses in DNS" en las

propiedades avanzadas de TCP/IP.

Asegurate que la tarjeta en la red de produccin est primera en el orden de bindings en la

configuracin avanzada de conecciones de red.

Cada nodo cuenta con cuatro LUNs. Dos para bases de datos y dos para logs de
transacciones (nota que a efectos de este lab, las bases de datos y logs de transacciones
estarn en dos particiones del mismo disco fsico, lo cual *no* es recomendable para un
ambiente de produccin).
Ambos nodos debern tener una definicin de LUNs y asignacin de letras homognea

Instalacin de Exchange 2010

Una vez que los servidores estn configurados, lanzamos la instalacin de Exchange desde
el DVD
Con los prerequisitos ya instalados, la primera opcin disponible ser "Step 3" donde
tenemos que seleccionar el soporte de lenguaje que querramos.

En caso que seleccionemos "Install all languages from the language bundle", el instalador
intentar conectarse a internet y bajar el soporte de lenguaje ms actualizado. De no tener
conexin a internet, puedes bajarlo manualmente e indicarle al instalador la ruta donde
ubicar el paquete.

Las siguientes pantallas no necesitan aclaracin...

Instalaremos todos los roles en cada servidor, eligiendo la instalacin tpica.

Los CAS servers brindarn servicio a internet, por lo tanto configurar esta opcin con la
direccin de mis servicios pblicos mail.lab10.net. Nota: para que estos servicios funcionen
correctamente, debemos instalar un certificado con los Service Alternative Names acordes a
nuestro ambiente.

En ambiente de laboratorio mantendr deshabilitada la opcin de CEIP.

Aqui comienza la verificacin de prerequisitos para la organizacin y diferentes roles:

Una vez completada la verificacin iniciamos la instalacin ("Install")

Aparecer un detalle de cada componente instalado en el servidor:

Una vez que finaliza la instalacin puedes ver el log de instalacin en la opcin "View
Setup Log":

Luego de finalizar la instalacin, se ejecutar Exchange Management Console

automticamente y presentar la opcin de buscar actualizaciones del producto a travs de
Windows Update:

Nos olvidamos del cluster?

No. Exchange 2010 permite una implementacin incremental. Esto quiere decir, que a
diferencia con Exchange 2007 donde el servicio de Cluster tena que estar configurado de

antemano, podemos instalar un servidor normal, incluso usarlo de esa forma, y luego
agregarle alta disponibilidad haciendolo formar parte de un DAG.
Entonces, en este momento tenemos dos Mailbox Servers LabE2K10-1 y LabE2K10-2
como servidores independientes, cada uno con los roles de Hub, CAS y Mailbox.

Implementando DAG en Exchange 2010 (Parte II)

LatamBlog
29 Mar 2010 8:33 PM

por Daniel Seveso

Implementacin del DAG

Continuando mi artculo anterior Implementando DAG en Exchange 2010 (Parte I),
tenemos dos servidores de Exchange 2010 instalados, cada uno con los roles de HUB, CAS
y Mailbox Server.
En este punto es conveniente crear un usuario en cada base de datos y comprobar que los
mensajes fluyen correctamente entre los servidores.
Tambin confirmar que los servidores se comuniquen por ambas tarjetas de red LAN
y REPL.

Como ven no hay DAG definidos an:

Las bases de datos estn en su ubicacin y nombres por default:

C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox
Database nnnnnnnnnn
Comenzar moviendo la base de datos de cada servidor a una de las unidades creadas a
tales efectos. Mover la base de datos del servidor 1 a E:\DB1 y los logs a F:\DB1, lo que
puedo hace va lnea de comandos (PS) desde Exchange Management Console:
[PS] C:\>move-DatabasePath -Identity 'Mailbox Database 1296140075'
-EdbFilePath 'E:\DB1\DB1.edb'
-LogFolderPath 'F:\DB1'

De igual forma muevo la base de datos y logs del servidor 2. Por claridad, tambin voy a
renombrar las bases de datos a DB1 y DB2 respectivamente, con lo que la configuracin
queda de esta forma:

Creando el DAG
Como estamos instalando slo dos nodos en el Cluster sin tener un disco compartido,
necesitamos un File Share Witness (FSW) para tener el segundo voto en caso que un
nodo del cluster falle. Puedes leer sobre Clusters y FSW aqu. Un requerimiento para el
FSW es que Exchange pueda accederlo y para ello, debemos otorgar permisos de
administrador via el grupo Exchange Trusted Subsystem haciendo este grupo miembro
del grupo Administratorsdel servidor donde vamos a ubicar el FSW.
Nota: Este paso solo es necesario cuando el FSW est ubicado en un servidor NOExchange, dado que este permiso ya est otorgado en los servidores de Exchange desde el
momento de su instalacin. Lo recomendado es que el FSW se ubique en un Hub Transport
server que no forme parte del cluster.
Estamos listos para crear el DAG, y vamos a hacerlo desde Exchange Management
Console:

Especificamos el nombre del DAG, el servidor que va a oficiar de FSW (en nuestro caso
ser el controlador de dominio) y el directorio donde se configurar localmente el FSW en
LABDC1

Al finalizar el asistente nos aparece una alerta avisandonos que LABDC1 no es un servidor
de Exchange y por lo tanto necesita el permiso anteriormente mencionado.

Esta accin crea el objeto del DAG de clase msExchMDBAvailabilityGroup en el

directorio activo. Nota que el contenedor de Database Availability Groups est al mismo
nivel que los Servers en la configuracin de Exchange 2010.

En el Exchange Management Console ya vemos el DAG:

Configurando el DAG
Una vez que el objeto est creado, definimos los servidores miembros del DAG mediante la
opcin Manage Database Availability Group Membership:

Agregamos ambos servidores con la opcin Add y continuamos con Manage.

Los comandos PS correspondientes para esta operacin seran:

[PS] C:\>Add-DatabaseAvailabilityGroupServer Identity DAG1
MailboxServer LABE2K10-1
[PS] C:\>Add-DatabaseAvailabilityGroupServer Identity DAG1
MailboxServer LABE2K10-1
Este paso proceder a la instalacin de los servicios de Cluster en cada uno de los nodos en
forma automtica

En el proceso, se crear automticamente el FSW y su correspontiente carpeta compartida

en LABDC1 como fue indicado en el asistente:

Como parte de la configuracin, se crear un recurso de cluster IP Address para ser

utilizado por el DAG. Si ests utilizando DHCP en tu red, este recurso de cluster ser
configurado con una IP dinmica del DHCP y no necesitar mayor intervencin. En caso
contrario tendremos un aviso notificando que el DAG no tiene direccin IP vlida y
tendremos que configurarla manualmente. Voy a seguir el segundo caso:

El Failover Cluster Manager indica el problema con la IP:

Ejecutamos entonces el siguiente comando para agregar la direccin IP fija a la

configuracin del DAG:
[PS] C:\>Set-DatabaseAvailabilityGroup DAG1
DatabaseAvailabilityGroupIpAddresses 192.168.31.175

Consultamos como quedan las principales propiedades del DAG

[PS] C:\Windows\system32>Get-DatabaseAvailabilityGroup | fl
RunspaceId
: 2c63732a-5bd2-478b-94adb8dc8b9f3422
Name
: DAG1
Servers
: {LABE2K10-2, LABE2K10-1}
WitnessServer
: LABDC1.LAB10.NET
WitnessDirectory
: C:\FSWDAG1
AlternateWitnessServer
:
AlternateWitnessDirectory
:
NetworkCompression
: InterSubnetOnly
NetworkEncryption
: InterSubnetOnly
DatacenterActivationMode
: Off
StoppedMailboxServers
: {}
StartedMailboxServers
: {}
DatabaseAvailabilityGroupIpv4Addresses : {192.168.131.175}
OperationalServers
:
PrimaryActiveManager
:
ThirdPartyReplication
: Disabled
ReplicationPort
: 0
NetworkNames
: {}
AdminDisplayName
:
ExchangeVersion
: 0.10 (14.0.100.0)
DistinguishedName
: CN=DAG1,CN=Database
Availability Groups,CN=Exchange Administrative Group (FYDI
BOHF23SPDLT),CN=Administr
ative Groups,CN=Lab10,CN=Microsoft Exchange,CN=Servic
es,CN=Configuration,DC=la
b10,DC=net
Identity
: DAG1
Guid
: 04d033ab-fc82-4124-91dad714f661c166
ObjectCategory
:
lab10.net/Configuration/Schema/ms-Exch-MDB-Availability-Group
ObjectClass
: {top,
msExchMDBAvailabilityGroup}
WhenChanged
: 3/26/2010 9:08:49 PM
WhenCreated
: 3/26/2010 8:24:45 PM
WhenChangedUTC
: 3/27/2010 2:08:49 AM
WhenCreatedUTC
: 3/27/2010 1:24:45 AM
OrganizationId
:

OriginatingServer
IsValid

: LabDC1.lab10.net
: True

Luego de asignar la direccin IP al DAG veremos recurso Cluster Name en el Failover

Cluster Manager: online.
En este punto ya podemos considerar que nuestro DAG est formado. Usando el
commando Add-DatabaseAvailabilityGroupServer, o la opcin equivalente Manage
Database Availability Group Membership en el Exchange Management Console, pudes
agregar ms servidores al DAG. Si el Windows Failover Cluster no est instalado en el
servidor que agregamos, el asistente de instalacin lo instalar automticamente.
De la misma forma puedes usar el comando Remove-DatabaseAvailabilityGroupServer
para quitr servidores del DAG. Para quitar servidores del DAG debes primero remover las
copias de base de datos que existan en el servidor.
Las redes NET y REPL se han configurado automticamente de la siguiente forma:

Si listamos las redes en PS, tendremos mayor detalle de su configuracin. Nota que la red
REPL (DAGNetwork02) se usar para replicacin pero no para trfico de clientes MAPI,
mientras que NET (DAGNetwork01) se sar para ambos tipos de trfico. Esto obviamente
se puede cambiar via el comando
Set-DatabaseAvailabilityGroupNetwork
[PS] C:\Windows\system32>Get-DatabaseAvailabilityGroupNetwork
Identity

ReplicationEnabled
Subnets

--------

------------------------

DAG1\DAGNetwork01
{{192.168.131.0/24,Up}}
DAG1\DAGNetwork02
{{10.0.0.0/8,Up}}

True
True

[PS] C:\Windows\system32>Get-DatabaseAvailabilityGroupNetwork |fl

RunspaceId
: 2c63732a-5bd2-478b-94ad-b8dc8b9f3422
Name
: DAGNetwork01
Description
:
Subnets
: {{192.168.131.0/24,Up}}
Interfaces
: {{LabE2K10-1,Up,192.168.131.71}, {LabE2K102,Up,192.168.131.72}}
MapiAccessEnabled : True
ReplicationEnabled : True
IgnoreNetwork
: False
Identity
: DAG1\DAGNetwork01
IsValid
: True
RunspaceId
Name
Description
Subnets
Interfaces
2,Up,10.10.10.2}}
MapiAccessEnabled
ReplicationEnabled
IgnoreNetwork
Identity
IsValid

:
:
:
:
:

2c63732a-5bd2-478b-94ad-b8dc8b9f3422
DAGNetwork02

:
:
:
:
:

False
True
False
DAG1\DAGNetwork02
True

{{10.0.0.0/8,Up}}
{{LabE2K10-1,Up,10.10.10.1}, {LabE2K10-

Otro detalle que quera mostrarles es el Cluster Network Object que se crea
automticamente con la configuracin del DAG. Es la cuenta de mquina que se crea

representando al nombre de red del cluster y est habiliatada para uso de Kerberos como
forma de autenticacin.

Agregando replicas de bases de datos al

DAG