Archivo

Entradas Etiquetadas ‘DAG’

Exchange 2013: Cómo configurar un DAG Multi-Site sin despeinarse

viernes, 6 de febrero de 2015 Sin comentarios

Hola a todos,

Vuelvo a mi tema favorito (y que a veces me produce úlceras de estómago): Exchange 2013.

Después de la – para mi – desastrosa CU6 en temas de clúster DAG, hoy os escribo para explicaros cómo crear un DAG en un entorno de servidores MBX multisite (o en CPDs separados)

¿Qué tenemos?

  • Dos servidores Windows Server 2012 R2 Update 1 (Standard o Enterprise, da igual)
  • Dos servodores Exchange Server 2013 CU7 con el rol de MBX
  • Dos CPDs con vLANs diferentes (172.20.0.0/16 y 172.21.0.0/16)
  • El rol de Failover clúster instalado en los Windows (aunque si no lo tienes, Exchange lo instalará cuando lo necesite)

¿Qué queremos?

Montar un clúster DAG con estos dos servidores para dotar a las DBs de alta disponibilidad (HA)

¿Cómo lo hacemos?

Lo primero de todo, leyendo un poco.

  • ¿Leer? Pero si hace años que monto DAGs de Exchange!!!!
  • Tú lee. Hazme caso Winking smile

Una de las diferencias que os vais a encontrar, si no lo habéis hecho ya (que si ya os ha pasado, podéis saltar al siguiente punto…), es que el Asistente de creació de clústers DAG no funciona “como siempre” sobre Windows Server 2012 o superior. WTF??!!

Lo dicho: hay que crear a mano la cuenta de equipo que representará al clúster en nuestro entorno, tal como se describe en

    Si el proceso anterior se sigue a rajatabla, no tendréis problemas, no más de los habituales. Así que la creamos

image

La dejamos deshabilitada y le establecemos los permisos adecuados.

image

image

Con estos cambios, ya podemos ir a la consola ECP de Exchange (o usar directamente PowerShell)

image

Yo lo haré por PowerShell, por variar un poco  Smile

  • NOTA: fijaros que añado DOS IPs como IPs de clúster!!!! Cada IP corresponde a un segmento de red, uno por CPD

New-DatabaseAvailabilityGroup -Name ClusterDAG -WitnessServer FileServer01 -WitnessDirectory C:\WitnessExchange -DatabaseAvailabilityGroupIPAddresses 172.20.0.86,172.20.1.86

Si la ejecución es correcta, habremos creado nuestro clúster DAG sin despeinarnos. Lo podemos revisar desde la propia herramienta de Failover cluster de Windows donde veremos que hay una IP caída que no lo es tal (es por diseño). Si balanceamos el clúster, veréis cómo se activa sin problemas y se cae la actual.

image

Desde la consola de gestión del DAG de Exchange también podemos ver “algo” pero no queda tan claro

image

Lo siguiente, añadir nuestros Nodos de Exchange al recién creado clúster. De nuevo desde PowerShell:

Add-DatabaseAvailabilityGroupServer -Identity ClusterDAG -MailboxServer ClusterNode1

Repetimos el comando para nuestro ClusterNode2 para tener un clúster de dos miembros.

Finalmente, queda añadir las réplicas de las DBs que queramos que participen del mismo. Que con PowerShell es así de sencillo (y por cada DB que quieras replicar):

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer ClusterNode2 -ActivationPreference 2 -SeedingPostponed

NOTA: Importante, muy importante el último parámetro –SeedingPostponed. Ponedlo siempre y os evitaréis que os falle la primera copia de la DB (que falla siempre, por cierto) y os tocará jugar – más – con PowerShell Smile with tongue out

 

Y esto es todo. Fácil, no?

 

Saludos,

Marc

Migración de bosques AD: configuración de un DAG en los MBX en Exchange 2010 SP1

sábado, 10 de septiembre de 2011 Sin comentarios

Tenemos los CAS y los HT configurados. Queda el rol de MBX en el que montaremos un DAG para tener un mínimo entorno funcional en el nuevo bosque.

Vamos a ello.

Para poder implementar un clúser DAG en Exchange hemos de instalar las herramientas de Failover cluster para W2K8R2 desde el Server Manager, Add Features.

Después de la instalación y reinicio del equipo, procedemos a generar un clúster DAG desde la propia interfaz de administración de Exchange 2010 SP1

Además, para crear un clúster DAG es necesario que todos los servidores con el rol de MBX que formarán parte de este clúster (hasta 16 miembros) tengan publicados el mismo número de discos, con las mismas letras y con espacios idénticos.

Si se cumplen esas premisas, podremos generar correctamente un DAG.

1.1 Implementación del DAG

Para crear un clúster DAG es necesario abrir o bien la Exchange Management Console (EMC) o la Exchange Management Shell (EMS).

En nuestro caso optaremos por la primera opción.

Nos dirigimos a la parte de Organización, y en el Task Panel de la derecha, seleccionamos la opción de “New Database Availability Group” que nos lanzará el asistente de creación del DAG.

Vamos completando los distintos campos como se aprecia en la siguiente captura de pantalla

El nombre del clúster será “DAG”

image

No es necesario indicar un “Witness server” ya que por defecto escogerá el primer HT de la organización que no tenga el rol de MBX

Añadimos todos los servidores con el rol de MBX que queramos participen del DAG, en este caso los 2 nuevos servidores montados, y continuamos con el asistente.

image

Una vez finalizada la configuración del asistente, tenemos un clúster DAG pero sin bases de datos de buzones y sin una configuración de red para el mismo.

Asignamos un Secondary Witnes Server en el otro HT por si el primero de ellos no está disponible o falla por cualquier motivo.

image

Procedemos a la configuración de las redes.

Red de Heartbeat

La red de Heartbeat sólo la configuramos para que el clúster se comunique internamente pero no para que los clientes se conecten a ella por lo que dejamos habilitada la sincronización y le cambiamos el nombre de “DAGNetwork01” a un nombre más descriptivo como “DAG-Heartbeat”.

image

Red iSCSI

La red de iSCSI sólo la configuramos para que el clúster se comunique con la cabina de discos que publica las LUNs de las DB pero no para que los clientes se conecten a ella por lo que dejamos deshabilitada la sincronización y le cambiamos el nombre de “DAGNetwork02” a un nombre más descriptivo como “DAG-iSCSI”.

image

Red del clúster

Finalmente, la red de Producción la configuramos para que el clúster se comunique los clientes y también para que replique la configuración del DAG de modo interno en caso de que fallase la DAG-Heartbeat. Le cambiamos el nombre de “DAGNetwork03” a un nombre más descriptivo como “DAG-NetworkPro”.

image

Finalmente hemos de poner una IP fija al clúster DAG de modo que no se dependa de un servicio DHCP para acceder a las DB del DAG.

La IP del clúster DAG es la 192.168.130.157

image

1.2 Creación de los Mailboxes en el clúster DAG

Después de crear el clúster DAG, es necesario crear las bases de datos de buzones para dar soporte a las necesidades de la MIDOMINIO.

Hay definidos dos tipos de usuarios, en función de la jerarquía de la casa y son los usuarios VIPS y los usuarios No-Vips. Para cada tipo de usuario se generará un nuevo almacén con características de cuotas diferentes.

El proceso de generación del nuevo almacén de buzones es independiente a añadirlo al clúster DAG para obtener alta disponibilidad.

1.2.1 Almacén de buzones para los usuarios No-VIP

Para generar un nuevo almacén para los usuarios no-VIP iremos al Task Panel de la parte derecha de la consola de administración de Exchange (EMC) y seleccionaremos la opción “New Mailbox Database”.

Una vez lanzado el asistente, le daremos un nombre descriptivo, seleccionaremos el servidor de MBX que almacenará ese nuevo almacén y pulsaremos en “Siguiente”

image

En el siguiente punto, hemos de indicar la ruta local del servidor donde almacenaremos ese nuevo almacén. Se ha definido la unidad F: para los datos de los usuarios No-VIP y la letra G:\ para guardar los logs de transacción que genere el citado almacén.

Validamos que los datos sean correctos y proseguimos con el asistente.

image

Si todos los datos introducidos son correctos el asistente creará la estructura de directorios y ficheros adecuada y montará el nuevo almacén si no le decimos lo contrario.

image

En este punto ya tenemos el almacén de buzones para los usuarios No-VIP creado. El siguiente paso es añadir una copia al DAG para ofrecer Alta Disponibilidad (HA) en caso de fallo de alguno de los servidores de MBX.

Para proveer de esa HA, seleccionamos el nuevo almacén, botón derecho sobre él y “Add Copy”. Se nos lanzará un asistente para configurar esa HA donde básicamente nos pedirá en qué otro servidor MBX del DAG queremos generar la réplica del almacén seleccionado.

image

En este caso, seleccionamos el MBX contrario de donde hayamos generado el almacén y seguimos avanzando con el asistente.

Una vez finalizado el asistente, revisamos que se ha generado la copia para HA y damos por concluida la tarea.

image

1.2.2 Almacén de buzones para los usuarios VIP

El proceso para la generación del almacén de buzones para los usuarios VIP es análogo al anterior, exceptuando las rutas físicas donde se almacenarán los buzones.

En este caso, la letra de la unidad es la E:\ mientras que los logs siguen yendo a la unidad G:\ pero en otra carpeta.

Una vez finalizado el asistente, tendremos el almacén de buzones de los usuarios VIP y sólo quedará añadir una réplica dentro del clúster DAG.

Para proveer de esa HA, seleccionamos el nuevo almacén, botón derecho sobre él y “Add Copy”. Se nos lanzará un asistente para configurar esa HA donde básicamente nos pedirá en qué otro servidor MBX del DAG queremos generar la réplica del almacén seleccionado.

En este caso, seleccionamos el MBX contrario de donde hayamos generado el almacén y seguimos avanzando con el asistente.

Después de completar el asistente, vemos que se ha generado una copia en el otro servidor de MBX y que se han replicado correctamente los datos.

1.3 Configuración de la organización

Después de generar los buzones para cada tipo de usuario, se procederá a establecer cuotas de uso de los buzones en función del tipo de usuario.

Para los usuarios No-VIP, los límites establecidos son

– 60 MB para aviso del límite de la cuota

– 72 MB para enviar

– 80 MB para enviar y recibir.

image

Para los usuarios VIP, los límites establecidos son

– 3,30 GB para aviso del límite de la cuota

– 3,95 GB para enviar

– 4,50 GB para enviar y recibir.

image

Para cada almacén de buzones se ha definido el uso de la misma Offline Address Book (OAB) que es distribuida por los CAS Servers

imageimage

De momento, no hay definas Carpetas Públicas (PF) en la organización de la CMT dado que no son requeridas por las aplicaciones.

1.4 Configuración del servidor

No se realiza ninguna configuración a nivel de servidor dejando los valores por defecto.


Próxima acción, publicar el servicio de correo en Internet a través de Forefront TMG que hará de Reverse Proxy para OWA, ActiveSync y Outlook Anywhere el cual ya hemos configurado.

Marc