Despliegue de Azure Site Recovery, replicando un entorno local VMware VSphere en Azure.

Crearemos un entorno de Azure Site Recovery, en el que vamos a replicar una máquina virtual alojada en VMware VSphere 6.7, en un entorno Azure.

Provocaremos una conmutación por error y nos conectaremos al entorno en la nube.

Requisitos del entorno OnPremises / Virtual

Tiene que ser al menos VSphere 5.5 y los sistemas invitados deben estar en esta lista.

Windows:

Windows Server 2016 de 64 bits (Server Core, Server con Experiencia de escritorio)

Windows Server 2012 R2

Windows Server 2012

Windows Server 2008 R2 con al menos SP1.

Linux:

Red Hat Enterprise Linux: 5.2 a 5.11**, 6.1 a 6.9**, 7.0 a 7.5

CentOS: 5.2 a 5.11**, 6.1 a 6.9**, 7.0 a 7.5

Servidor Ubuntu 14.04 LTS

Servidor Ubuntu 16.04 LTS

Debian 7/Debian 8

SUSE Linux Enterprise Server 12 SP1, SP2, SP3

SUSE Linux Enterprise Server 11 SP3**, SUSE Linux Enterprise Server 11 SP4 *

Oracle Enterprise Linux 6.4, 6.5 que ejecuten el kernel compatible de Red Hat o Unbreakable Enterprise Kernel Release 3 (UEK3)

También tenemos que tener en cuenta que este proceso no se puede llevar a cabo a través de una VPN, tiene que ser directamente con Endpoint Publico o a través de ExpressRoute.

Una vez el entorno haya sido instalado, en caso de conmutación por error, si podemos utilizar servicio VPN para conectarnos a él de forma más segura.

Creación del entorno OnPremises

Creamos una máquina virtual en nuestro entorno virtualizado, en nuestro caso es un ESXi, si no dispones de un ESXi pero si de un Workstation, en esta entrada te contamos cómo montar un ESXi 6.7 sobre Workstation 14.

La máquina virtual no necesita ninguna configuración especial. Sólo tenemos que tener en cuenta lo siguiente:

- Tener instalados y actualizados la VMware Tools.

- Sistema Operativo invitado actualizado.

- Acceso permitido desde otras máquinas con credenciales suficientes. Nos conectamos a través de una máquina en la misma red con credenciales suficientes para coger los datos.

Necesitamos un usuario en el sistema VMware que tenga permisos para poder coger información de la máquina, en nuestro caso, utilizamos el usuario root, pero si quieres crear un usuario específico para este proceso, necesitamos:

Más información en este enlace.

Preparación del entorno Azure

Una vez creada la máquina virtual procedemos a crear el Vault de Site Recovery, es la infraestructura donde crearemos todas las réplicas y administraremos los Failovers.

Entramos en el portal de Azure y buscamos en el Marketplace, Backup and Site Recovery (OMS).

Le damos un nombre al almacen de servicios de recuperación, en nuestro caso algo descriptivo. “SiteRecoveryVault”, seleccionamos la suscripción que queremos utilizar y creamos un nuevo grupo de recursos.

Este grupo de recursos es dónde se van a almacenar las réplicas, pero luego podemos montar el entorno de producción en otro grupo de recursos cuando hacemos la conmutación por error.

Una vez que le hemos dado nombre, y específicado los parámetros le damos a crear.

Preparación de infraestructura Azure

Nos vamos a Vault de Servicios de recuperación, y nos dirigimos a Getting Started\Site Recovery, Prepamos la infraestructura y especificamos el tipo de Site Recovery que vamos a utilizar.

En la siguiente imagen podemos ver que vamos a:

Replicar un entorno On-premises (Punto 4)

Lo vamos a replicar en Azure (Punto 5)

Siendo la infraestructura origen, virtualizada sobre VMware (Punto 6)

En el entorno que vamos a crear y configurar solo va a ser de una máquina virtual, no es necesario que realicemos un estudio de lo que vamos a tardar en prepararlo, ni el consumo que vamos a tener. Si fueran muchas máquinas en un entorno de producción, sería aconsejable descargar una herramienta de análisis y estimación de tiempos. Microsoft dispone de una herramienta que nos ofrece en este paso:

En nuestro caso le decimos que ya lo hemos hecho y seguimos.

Para que la réplica en Azure se lleve a cabo de forma correcta, es necesario el despliegue de una maquina virtual “intermedia”, que si bien la podemos preparar nosotros, tiene unas singularidades especiales que hay que tener en cuenta.

Para ello necesitamos los siguientes requerimientos:

- 8 CPU cores

- 16 GB de RAM

- 3 discos duros, dos de 600 Gb y uno de 80 Gb

- IP estática

Aunque en el despliegue del servidor de configuración, hay un paso en el que tenemos que instalar software de terceros como MySQL, en ningún caso nos indica que tengamos que instalar PowerCLI 6.0, pero es necesario hacerlo antes de replicar nuestras máquinas.

Aprovisionamiento de Servidor de configuración de forma manual.

Si aún así queremos contruir nuestro propio Servidor de Configuración sin utilizar la plantilla, tenemos que descargar la aplicación Unified Setup file, podemos hacerlo desde este enlace: https://docs.microsoft.com/en-us/azure/site-recovery/physical-azure-set-up-source.

Además de los requisitos que debemos cumplir con la plantilla, tenemos que saber que no se pueden instalar en esta maquina los siguientes roles:

- Active Directory Domain Services

- IIS

- Hyper-V

Tampoco podemos habilitar una serie de GPO´s:

- Impedir el acceso al símbolo del sistema.

- Impedir el acceso a herramientas de edición del Registro.

- Confiar en la lógica de datos adjuntos de archivos.

- Activar la ejecución de scripts.

Y uno de los puntos más importantes, es que tiene que tener un adaptador de red VMXNET3.

Despliegue de plantilla de máquina virtual Servidor de Configuración.

Nosotros lo vamos a importar de la plantilla. Si no la hemos descargado en el asistente de preparación de infraestructura, podemos descargarla de este enlace.

Una vez descargada la plantilla, nos vamos a VMware. Le damos a crear máquina virtual, y en vez de crear una desde cero, vamos a desplegar una plantilla.

Le damos un nombre a la máquina, en este caso VMConfServer, y le decimos donde tenemos la plantilla, en este caso la hemos puesto en c:\.

Una vez seleccionada, nos dice que elijamos el DataStore donde lo vamos a aprovisionar, seleccionamos el Premium para que vaya más rápido.

Una vez seleccionado el DataStore, aceptamos el acuerdo de licencia y nos dice que tipo de disco queremos usar si fijo o de expansión dinámica, si es en producción y tenemos el espacio necesario poner fijo, como nosotros no contamos con tanto espacio porque hacen falta 1280 Gb, le vamos a poner de expansión dinámica.

Una vez lanzado, tenemos que comprobar en las tareas recientes que la tarea se ejecuta de forma correcta hasta que termine.

Si se producen errores, los más habituales son, por falta de espacio en el DataStore, o porque no hayamos asignado suficientes cores a la máquina, recordar que necesita 8. Puedes configurar que utilice 2 CPUs de 2 procesadores virtuales cada uno, si andas justo de recursos.

Una vez que todo ha finalizado, es como si fuera un Windows Server 2016 normal.

Aceptamos el acuerdo de licencia, y nos solicita una contraseña, recuerda que esta máquina no puede tener servicios de directorio activo.

Nos dice que le demos un nombre y si queremos descubrir la red, le diremos que si para que tenga acceso a toda la red de servidores.

Una vez le damos el nombre comprueba que tiene internet, y es necesario que lo metamos en un directorio activo Azure, lo vamos a hacer en el AZ donde tenemos el Site Recovery. Le damos a Sign in

Una vez está todo correcto, tenemos que reiniciar la máquina.

Una vez iniciado, se abre el asistente del servidor de configuración de Site Recovery (Si no se abre de forma automática, en el escritorio tenemos un icono que nos lo abre).

Es necesario ponerle una IP estática a la máquina, antes de nada, modificamos la IP y le ponemos 192.168.0.120-

Es importante que todo lo relación con la tarjeta de red lo hagamos antes de hacer este paso, luego no se puede modificar, o al menos no fácilmente.

Ahora tenemos que seleccionar el Vault donde vamos a hacer las copias, por lo que nos pedirá credenciales de Azure, las introducimos, y nos pide permiso para acceder a la suscripción con un usuario sólo lectura para ver los recursos.

Aceptamos la solicitud, y le indicamos dónde queremos que se lleve a cabo la replicación.

El servidor necesita MySQL para su funcionamiento por lo que nos pide permiso, le damos a instalar.

En los siguientes apartados nos pide las credenciales por un lado del servidor/es, ESXi donde van a estar almacenadas las máquinas, podemos crear un usuario específico del que hablábamos a la hora de configurar la infraestructura local.

Como es un laboratorio nosotros vamos a utilizar el usuario root, lo correcto dependiendo del entorno, es crear un usuario específico para esta labor con los permisos limitados.

Una vez introducidas las credenciales y el nombre por el que identificaremos a cada uno de los ESXi nos solicita la misma información para las máquinas virtuales, si todos autentican con el mismo usuario con poner solo uno es suficiente.

Una vez que está todo correcto, y verificado le damos a finalizar la configuración.

Hay que instalar posteriormente PowerCli 6.0, lo podemos descargar en este enlace.

El servidor de configuración está listo, tenemos que seguir con la configuración en Azure.

 

Vincular entorno ESXi a Azure y asociar política de replicación.

Si recordáis estábamos “Preparando la infraestructura”, y nos pedía descargar la plantilla, para posteriormente desplegar el servidor de configuración.

Vemos que directamente, nos pone ya el nombre del servidor de configuración y simplemente tenemos que desplegar en el paso 2 y seleccionar nuestro servidor/es ESXi.

Ahora necesitamos crear una Storage Account y una VNet de administración para subir los datos de la red OnPremises a Azure.

Empezamos por la cuenta de almacenamiento.

Es importante que el tipo de replicación pongamos georedundante de solo lectura. Lo especifica Microsoft en sus requisitos. Ahora vamos a configurar la VNet, sólo se va a utilizar para subir los recursos locales a Azure.

Configurados los recursos para poder subir las réplicas a Azure hay que asociar una política de replicación. En mi caso voy a poner 15 minutos porque me interesa que si hago un cambio local se replique pronto, pero lo habitual es poner este tiempo más espacio, sobre todo por temas de coste.

Ya tenemos nuestro Servidor de Configuración desplegado, con su cuenta de almacenamiento creada, su red para subir las máquinas, y su política de replicación asociada.

 

Habilitar replica de objetos.

Vamos a seguir el asistente de inicio a la hora de crear la infraestrutuctura, pero estos pasos también los podemos hacer desde “Administrar infraestructura de Site Recovery”, y “Objetos replicados”.

Solo nos falta decirle que elementos queremos replicar y dónde lo queremos replicar.

Debemos tener claro, que vamos a hacer en caso de FailOver, en nuestro caso vamos a utilizar los mismos recursos de almacenamiento, pero diferente tarjeta de red. Por lo que seleccionamos la cuenta de almacenamiento anterior, el grupo de recurso anterior, pero creamos una nueva VNet, además la hemos creado con el mismo rango que OnPremises, esto es dependiendo de las necesidades. Podemos poner el rango que necesitemos.

Luego indicamos la subnet que queremos utilizar tras la conmutación.

Ahora seleccionamos que máquinas queremos replicar en Azure, en nuestro caso sólo una.

Por esa razón, el paso siguiente es un poco obvio, pero si tuvieramos muchas máquinas podemos poner que credencial usar para cada una de ellas, y cual por defecto si carecemos de una específica.

Estas credenciales son las que configuramos en el servidor de configuración, en el asistente, para poder acceder a cada una de las máquinas. Se utiliza principalmente para instalar el agente de Azure y el agente de ASR. (Se puede instalar también de forma manual).

Una vez finalizado este paso, comienza la replicación, comprueba que tenemos acceso y que todo está correcto. Si todo está bien, comenzará a subir la máquina a Azure.

Comienza a sincronizar, tenemos que esperar a que la replicación sea Healthy, y el estado de la máquina ponga Protected, es decir que todo esté correcto y 100% sincronizada.

Prueba de conmutación por error.

Vamos a provocar un test de fallo, y ver si nos podemos conectar a la máquina. Para ello hemos creado varias carpetas en el escritorio, así comprobaremos que es una copia exacta de la máquina local.

Seleccionamos la máquina.

Una vez dentro, podemos ver que aparecen diferentes acciones, hacer un failover, o una prueba, deshabilitar la replicación, y podemos ver información como la última vez que se ha ejecutado la prueba y la última vez de la copia.

Podemos ver también un esquema de la arquitectura que tenemos montada, y donde está fallando en caso de error.

Realizamos una conmutación por error.

Aparecen diferentes puntos de recuperación. Debemos elegir el último procesado, porque al estar ya “compilado”, es más rápida la prueba. Si no, podemos elegir el último, pero tiene que procesarlo y tardaría más.

También tenemos que elegir la VNet donde queremos montar el entorno, anteriormente ya creamos una para cuando el entorno estaba en “producción”. Elegimos este.

Una vez seleccionados el punto y la red, le damos a iniciar. No debería tardar demasiado.

Una vez ha finalizado, si nos vamos al grupo de recursos, vemos que nos ha creado diferentes objetos que terminan en -test. Eso es todo lo que ha creado, seleccionamos la máquina virtual.

Nos vamos a Boot diagnostics para ver si se ha encendido correctamente.

 

Conectar a la máquina virtual

Si intentamos conectar, vemos que no nos lo permite, esto es debido a que la tarjeta de red tiene conectividad local, pero no hemos asignado ninguna IP publica, si tuviéramos VPN podríamos entrar sin problemas.

Nos vamos a la tarjeta de red, y seleccionamos la interfaz que está asociada a la máquina y Vnet.

Le damos a IP configuration, y seleccionamos la única que tenemos.

Ahora nos sale un blade en que nos aparece la IP Publica como deshabilitada, le damos a habilitar, y creamos una IP publica nueva.

Como vemos en la información de la máquina, ya teneos una IP publica asociada, y podemos darle a conectar.

“Una cosa que me resultó curiosa al realizar este laboratorio, dudaba de, con unas credenciales que por defecto Azure no permite, (usuario “administrator” o contraseña sin la longitud mínima) iba a funcionar. Pero como podemos comprobar accedemos correctamente.”

Además, tenemos los datos que habíamos creado en nuestra máquina local.

Limpieza de objetos tras la conmutación por error

Si queremos eliminar el entorno de prueba, volvemos al Vault, Objetos Replicados, Seleccionamos la máquina, y le damos a limpiar prueba de conmutación.

Esto nos eliminaría todos los objetos que ha creado la prueba, pero tenemos que tener cuidado con los que hemos creado nosotros manualmente, recordar que hemos creado una IP publica, hay que eliminarla de forma manual, pues no ha sido creada automáticamente en el proceso de prueba.

Cualquier duda acerca del laboratorio, escríbenos por si podemos ayudarte.

Para más información sobre el tema:

https://docs.microsoft.com/es-es/azure/site-recovery/vmware-azure-tutorial-prepare-on-premises

Este Post ha sido también publicado en:

- ITCloud.es: https://itcloud.es/despliegue-de-azure-site-recovery-replicando-un-entorno-local-vmware-vsphere-en-azure/