Configurar Cloud Witness en Failover Cluster

Si tenemos una implementación de Failover Cluster en Windows Server 2016, y cada uno de los nodos tiene salida a Internet, tal vez resulte de utilidad configurar un téstigo de nube (Cloud Witness) en Microsoft Azure. Esto nos habilita distintos escenarios, por ejemplo si tenemos dos centros de datos,  anteriormente utilizábamos un testigo de file share en un tercer sitio, el cual nos servía de testigo y contaba como voto,  en caso de que alguno de los sitios perdiera comunicación aún teníamos quorum al contar con el voto del file share en el tercer sitio, con cloud witness no hay necesidad de contar con un tercer centro de datos, simplemente podemos utilizar almacenamiento blob de Azure como testigo de nube para lograr lo mismo.

Su implementación es bastante sencilla, lo primero que debemos hacer es crear la cuenta de almacenamiento en Azure, para ello vamos al portal, y en el Marketplace seleccionamos  Storage  y luego Storage Account - blob, file, table, queue

Luego, diligenciamos la información para crear la cuenta. A continuación solamente describiré los detalles más importantes a modificar, entre ellos vale la pena resaltar que el tipo de cuenta debe ser de propósito general, y la replicación es suficiente con que tenga redundancia local.

Name: Ponemos el nombre que deseamos para la cuenta, en mi caso la llamé witnesslab

Account kind: Storage (general purpose v1)

Replication: Locally-redundant storage (LRS)

A continuación la imagen de la configuración que realicé para mi cuenta de almacenamiento:

De esta cuenta recién creada vamos a necesitar las llaves de acceso (Access Keys) y solo en caso de requerirse el endpoint. Veamos cómo obtener la llave.

En la cuemta de almacenamiento tenemos la opción Access Keys allí observaremos 2 llaves, en este caso usaremos la primera de ellas.

Esta llave de acceso debemos tenerla lista ya que más adelante la vamos a necesitar, ahora vamos a la consola de Failover Cluster para agregar nuestro nuevo testigo de nube.

Hacemos clic derecho sobre el nombre del cluster, seleccionamos More Actions y luego Configure Cluster Quorum Settings

En el asistente hacemos clic en Next para empezar

En Select Quorum Configuration Options hacemos clic en la tercer opción Advanced quorum configuration y hacemos clic en Next

Seleccionamos los nodos que tendrán votos en el quorum, en esta caso todos los nodos y hacemos clic en Next

En la siguiente ventana seleccionamos Configure a cloud witness y hacemos clic en Next

A continuación, debemos poner el nombre de la cuenta de almacenamiento que previamente creamos en Azure, así como la llave de acceso que podemos copiar desde el portal, el Azure service point no lo necesitaremos en este caso, esto solo se debe cambiar bajo circunstancias específicas, como por ejemplo si estamos usando un datacenter en China, el cual tendrá un endpoint diferente, de lo contrario debe quedar algo similar a lo que se muestra en la siguiente imagen.

Revisamos la configuración y hacemos clic en Next

Para finalizar nos mostrará un mensaje indicando que todo salió bien, tal como se muestra a continuación.

Ahora, si revisamos los recursos del cluster, podemos observar que ya tenemos nuestro Cloud Witness en línea.

Y esto es todo. Espero esta información les sea de utilidad.

[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 5

Post en esta serie:

[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 1
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 2
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 3
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 4


En las entregas anteriores vimos cómo preparar toda la infraestructura de Azure Site Recovery, en esta última entrega dela serie vamos a realizar un failover de prueba (Test Failover).

Para ello basta con seleccionar cualquiera de las máquinas ya replicadas, y en las opciones de la parte superior podemos ver que contamos con 3:

1. Planned Failover
2. Failover
3. Test Failover 

En este caso vamos a utilizar Test Failover

Como se puede apreciar en la imagen anterior, contamos con un RPO bastante bajo,de tan solo 3 segundos en este caso.

A continuación podemos seleccionar un punto de restauración, y la red virtual sobre la cual haremos el failover.

Nótese la recomendación, al identificar que se trata de un test, me sugiere utilizar una red diferente a la de producción, ya que en mi caso estoy usando el mismo segmento, lo ideal es que la red para pruebas se mantenga en un segmento aislado, pero para efectos de esta demostración no tengo lío en utilizar la misma red, ya que no tengo comunicación alguna entre estas dos redes.

Luego, solamente debemos esperar hasta que se complete el proceso de Failover.

Algo interesante durante este proceso es que podemos ver cuánto tarda, con lo cual podemos tener valores de RTO para nuestro DRP

Al finalizar, ya tenemos las máquinas encendidas y listas para hacer pruebas, observen que se agrega la palabra test al final del nombre de la máquina.

Los pasos siguientes pueden ser agregar direcciones IP públicas a las interfaces en caso de que no tengamos conectividad entre los sitios para alcanzar las máquinas, ASR también incluye planes de ejecución en los cuales se puede determinar el orden de encendido de las máquinas en el caso de existan dependencias, como por ejemplo un servidor de SQL o Sharepoint que requieren de un controlador de dominio, etc. También es posible en medio del proceso la solicitud de acciones manuales, como actualizar algún registro DNS, o modificación de archivos de configuración. Estos temas no los veremos en esta serie de entregas,ya se sería más extenso de los que ya está, sin embargo para una futura ocasión crearé un post hablando sobre ello.

Por ahora, y para finalizar, veamos cómo se verifica el estado dela replicación desdeVMM

Si hacemos clic derecho sobre una de las máquinas protegidas, veremos la opción Manage Protection

Y desde allí podemos configurar la frecuencia de replicación.

En la parte de estado de la máquina, además de ver el estado de la protección, tenemos información acerca  de los errores, y cuando se realizó la última sincronización.

Bien, y esto es todo! Hasta aquí hemos llegado con esta serie de 5 artículos, un poco larga, pero seguro les será de utilidad si desean proteger máquinas administradas por VMM.

Un saludo para todos!

[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 4

Post en esta serie:

[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 1
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 2
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 3
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 5

Bien, en esta parte ya estamos cerca de terminar la implementación, Lo que vamos hacer ahora es mapear nuestra red de VMM en Azure Site Recovery, para ello en la parte de administración seleccionamos Site Recovery Infrastructure - Network Mapping

En la parte superior hacemos clic en + Network Mapping

Ahora seleccionamos las redes de origen y destino como se muestra a continuación:

1.  Seleccionamos el servidor VMM de origen SCVMM01A.cloud
2.  El destino que será Azure
3.  Seleccionamos la suscripción
4.  El método de implementación después del failover será Resource Manager
5.  Seleccionamos la red de origen, en este caso en VMM mi red se llama LABNET
6.  Por último la red de destino en Azure será VNet4. Como se puede apreciar en Azure conservaré         el mismo segmento de red que utilizo en mi ambiente on-premise con VMM.


Con lo anterior, hemos terminado la preparación de toda la infraestructura a nivel de Azure. Lo cual significa que ya tenemos el entorno local con VMM conectado con Azure Site Recovery, con ello ya podemos empezar el proceso de replicación de las máquinas virtuales hacia Azure.

En la parte de Site Recovery, ahora vamos a continuar con el paso 1 (Replicate Application) para máquinas on-premises y en Azure, como se muestra en la siguiente imagen:

Para habilitar la replicación, necesitamos completar las siguientes acciones, primero debemos configurar nuestro origen de replicación:

1. Source: Seleccionamos el origen On-premises
2. Source location: Seleccionamos el servidorVMM On-premises de origen.
3. Cloud: Seleccionamos la nube de VMM en la cual se encuentran las máquinas a replicar.


Ahora que ya tenemos el origen listo, debemos configurar el destino (Azure), con los datos necesarios como la suscripción, el grupo de recursos, entre otros que se muestran a continuación:

1. Target: Ya nos aparecerá el destino marcado con Azure
2. Subscription: Seleccionamos la suscripción
3. Post-failover resource group: Seleccionamos el grupo de recursos que usaremos para desplegar        las máquinas cuando se realice la conmutación por error.
4. Post-failover deployment model: Seleccionamos el modelo de implementación que usaremos            cuando se realice la conmutación por error, simplemente Resource Manager.
5. Storage account: Seleccionamos la cuenta de almacenamiento para nuestra infraestructura.


En la parte 3 Virtual Machines nos mostrará todas las máquinas existentes en la nube de VMM que elegimos, en este caso solamente replicaré dos VMs LAB-SRVSQL y LAB-SRV5 las cuales contienen la base de datos y la aplicación que deseo proteger con Azure Site Recovery.

En el paso 4 vamos a configurar las propiedades de ñas máquinas que vamos a replicar.

Básicamente aquí seleccionamos el sistema operativo de las máquinas y los discos a replicar.

En el quinto y último paso, vamos a configurar la replicación, donde lo único que debemos hacer es seleccionar la directiva de relplicación que creamos en el post anterior.

Una vez finalizado este último paso, solo nos resta hacer clic en el botón Enable Replication

Si todo sale bien veremos algo similar a lo que se muestra en la siguiente imagen:

Ahora solo resta esperar, depende del canal, cantidad y tamaño delas máquinas. Cabe aclarar que esto se trata de la sincronización inicial, una vez replicadas las máquinas solamente se replicarán los cambios.

Una vez finalice la replicación veremos las máquinas en estado protegido, como muestra la siguiente imagen:

Esto es todo, solo nos falta hacer una prueba (test) simulando una situación de recuperación de desastres, Azure Site Recovery permite hacer este tipo de pruebas sin afectar el entorno de producción on-premise, pero eso lo haremos en la siguiente y última parte de la serie. Por ahora para finalizar este post, veamos el diagrama que construye Azure de la solución.

Continúa en:
[ASR] Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager - Parte 5