Implementando DAG en Exchange 2010 (Parte I)

LatamBlog

29 Mar 2010 7:59 PM

0

por Daniel Seveso

Database Availability Group (DAG) es el único método de proveer alta disponibilidad a

una base de datos en Exchange 2010. En un artículo previo, describo qué es un DAG y sus

principales características.

Este artículo es una referencia de cómo implementar un "Database Availability Group" en

Exchange 2010.

Para esta configuración utilizaré dos servidores de Exchange para formar una solución de

dos DAG, aunque podríamos utilizar hasta 16. Todos los roles estarán instalados en cada

máquina. Utilizaré un controlador de dominio separado, respetando la tan importante

recomendación de Microsoft "Nunca instalar Exchange en un controlador de dominio", ya

que no hace más que traer dolores de cabeza.

Montaré todo el laboratorio en Hyper-V server, así que Uds. también pueden tratar de hacer

esto en casa :). Usaré Windows 2008 SP2 para la instalación de cada servidor de Exchange.

Asumimos que los prerequisitos para instalar Exchange 2010 ya están 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 están

sorprendidos, deberían leer el capítulo "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

producción y Repl: conectada a la red de heartbeat.

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

Tampoco marcada la opción "Register this connection's addresses in DNS" en las

propiedades avanzadas de TCP/IP.

Asegurate que la tarjeta en la red de producción esté primera en el orden de bindings en la

configuración 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

estarán en dos particiones del mismo disco físico, lo cual *no* es recomendable para un

ambiente de producción).

Ambos nodos deberán tener una definición de LUNs y asignación de letras homogénea

Instalación de Exchange 2010

Una vez que los servidores están configurados, lanzamos la instalación de Exchange desde

el DVD

Con los prerequisitos ya instalados, la primera opción 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 más actualizado. De no tener

conexión a internet, puedes bajarlo manualmente e indicarle al instalador la ruta donde

ubicar el paquete.

Las siguientes pantallas no necesitan aclaración...

http://blogs.technet.com/blogfiles/latam/WindowsLiveWriter/ImplementandoDAGenExchange2010_B60B/image_24.png

http://blogs.technet.com/blogfiles/latam/WindowsLiveWriter/ImplementandoDAGenExchange2010_B60B/image_26.png

Instalaremos todos los roles en cada servidor, eligiendo la instalación típica.

Los CAS servers brindarán servicio a internet, por lo tanto configuraré esta opción con la

dirección de mis servicios públicos 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 opción de CEIP.

Aqui comienza la verificación de prerequisitos para la organización y diferentes roles:

Una vez completada la verificación iniciamos la instalación ("Install")

Aparecerá un detalle de cada componente instalado en el servidor:

Una vez que finaliza la instalación puedes ver el log de instalación en la opción "View

Setup Log":

Luego de finalizar la instalación, se ejecutará Exchange Management Console

automáticamente y presentará la opción de buscar actualizaciones del producto a través de

Windows Update:

¿Nos olvidamos del cluster?

No. Exchange 2010 permite una implementación incremental. Esto quiere decir, que a

diferencia con Exchange 2007 donde el servicio de Cluster tenía 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

1

por Daniel Seveso

Implementación del DAG

Continuando mi artículo 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.

También confirmar que los servidores se comuniquen por ambas tarjetas de red LAN

y REPL.

Como ven no hay DAG definidos aún:

Las bases de datos están en su ubicación 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 vía línea 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, también voy a

renombrar las bases de datos a DB1 y DB2 respectivamente, con lo que la configuración

queda de esta forma:

Creando el DAG

Como estamos instalando sólo 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 “Administrators”del servidor donde vamos a ubicar el FSW.

Nota: Este paso solo es necesario cuando el FSW está ubicado en un servidor NO-

Exchange, dado que este permiso ya está otorgado en los servidores de Exchange desde el

momento de su instalación. 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 acción 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 configuración 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

opción Manage Database Availability Group Membership:

Agregamos ambos servidores con la opción “Add” y continuamos con “Manage”.

Los comandos PS correspondientes para esta operación serían:

[PS] C:\>Add-DatabaseAvailabilityGroupServer –Identity “DAG1” –MailboxServer “LABE2K10-1”

[PS] C:\>Add-DatabaseAvailabilityGroupServer –Identity “DAG1” –MailboxServer “LABE2K10-1”

Este paso procederá a la instalación de los servicios de Cluster en cada uno de los nodos en

forma automática

En el proceso, se creará automáticamente el FSW y su correspontiente carpeta compartida

en LABDC1 como fue indicado en el asistente:

Como parte de la configuración, se creará un recurso de cluster “IP Address” para ser

utilizado por el DAG. Si estás utilizando DHCP en tu red, este recurso de cluster será

configurado con una IP dinámica del DHCP y no necesitará mayor intervención. En caso

contrario tendremos un aviso notificando que el DAG no tiene dirección IP válida 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 dirección IP fija a la

configuración 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-94ad-b8dc8b9f3422 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=Administrative Groups,CN=Lab10,CN=Microsoft Exchange,CN=Servic es,CN=Configuration,DC=lab10,DC=net Identity : DAG1 Guid : 04d033ab-fc82-4124-91da-d714f661c166 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 : LabDC1.lab10.net IsValid : True

Luego de asignar la dirección 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 opción equivalente “Manage

Database Availability Group Membership” en el Exchange Management Console, pudes

agregar más servidores al DAG. Si el Windows Failover Cluster no está instalado en el

servidor que agregamos, el asistente de instalación lo instalará automáticamente.

De la misma forma puedes usar el comando “Remove-DatabaseAvailabilityGroupServer”

para quitár 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 automáticamente de la siguiente forma:

Si listamos las redes en PS, tendremos mayor detalle de su configuración. Nota que la red

REPL (DAGNetwork02) se usará para replicación pero no para tráfico de clientes MAPI,

mientras que NET (DAGNetwork01) se sará para ambos tipos de tráfico. Esto obviamente

se puede cambiar via el comando

Set-DatabaseAvailabilityGroupNetwork

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

Identity ReplicationEnabled Subnets -------- ------------------ ------- DAG1\DAGNetwork01 True {{192.168.131.0/24,Up}} DAG1\DAGNetwork02 True {{10.0.0.0/8,Up}}

[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}, {LabE2K10-2,Up,192.168.131.72}} MapiAccessEnabled : True ReplicationEnabled : True IgnoreNetwork : False Identity : DAG1\DAGNetwork01 IsValid : True

RunspaceId : 2c63732a-5bd2-478b-94ad-b8dc8b9f3422 Name : DAGNetwork02 Description : Subnets : {{10.0.0.0/8,Up}} Interfaces : {{LabE2K10-1,Up,10.10.10.1}, {LabE2K10-2,Up,10.10.10.2}} MapiAccessEnabled : False ReplicationEnabled : True IgnoreNetwork : False Identity : DAG1\DAGNetwork02 IsValid : True

Otro detalle que quería mostrarles es el “Cluster Network Object” que se crea

automáticamente con la configuración del DAG. Es la cuenta de máquina que se crea

representando al nombre de red del cluster y está habiliatada para uso de Kerberos como

forma de autenticación.

Agregando replicas de bases de datos al

DAG