En este documento veremos la instalación y configuración completa de VMware vCenter Site Recovery Manager 5 (SRM 5) con una de sus novedades vSphere Replication que nos permitirá replicar las máquinas virtuales entre un CPD principal y uno secundario, no a nivel de cabina si no gracias un virtual appliance desde la capa de virtualización. Esta replicación, más barata que una replicación a nivel de cabina, ya que además, no requiere unas cabinas compatibles con SRM (mediante los Storage Replication Adapter – SRA), esta replicación será a nivel de bloque gracias a CBT (Changed Block Tracking) y nos permitirá tener el CPD replicado con una pérdida máxima de 15min!

OK, en esta imagen observamos los 2 CPD’s que dispongo, uno principal (Bilbao) y uno secundario (Donostia), cada CPD dispone de su propio servidor vCenter 5, así como de una cabina de almacenamiento Openfiler que es donde se almacenan las máquinas virtuales de Bilbao y se replicarán a Donosti. En este escenario crearemos un servidor vRS (vSphere Replication Server) y un vSRM (vSphere Replication Management Server) que serán los encagados de replicar MV a MV entre las dos delegaciones. Una vez dispongamos de una replicación configurada entre ambos sites, la testearemos y finalmente moveré al CPD de respaldo las MV’s (ya que sufriré una catástrofe) 😛

Lo primero de todo en el CPD principal instalaremos VMware vCenter Site Recovery Manager, (posteriormente deberemos realizar los mismos pasos en el CPD secundario), podremos instalarlo en el propio vCenter o recomendable utilizaremos una MV para este fin.

Aceptamos las patentes de VMware,

Aceptamos el acuerdo,

Si vamos a utilizar replicación a nivel de cabina no hará falta la instalación de vSphere Replication (VR), en nuestro caso sí ya que será cómo gestionaremos las réplicas de nuestras máquinas virtuales, por lo que marcamos “Install vSphere Replication” & “Next”,

Indicamos la dirección IP o hostname del servidor vCenter 5 primario, su puerto (80tcp por defecto) y los credenciales de un usuario con privilegios administrativos, “Next”,

Indicamos el certificado que utilizará será generado automáticamente o importaremos nosotros uno, “Next”,

Incluimos la información de la organización, “Next”,

Ok, debemos indicar un nombre a este sitio físico, con objeto de recibir notificaciones agregaremos nuestro correo electrónico (para ello deberá estar configurado los parámetros SMTP en vCenter), indicaremos la IP con la que queremos que nos responda nuestro SRM, además de los puertos (por defecto): 8095tcp para SOAP, 9085tcp para HTTP & 9007tcp para las API Soap,

Ok, previo a esta instalación deberemos crear una BD en nuestro servidor de BBDD y crear un ODBC contra ella (x64), podremos hacerlo en este mismo paso introduciendo manualmente el nombre del conector, indicamos usuario & contraseña.

“Install” para comenzar la instalación de VMware vCenter Site Recovery Manager 5,

…

Tras unos minutos de instalación ya tenemos la instalación finalizada, lo dicho, deberemos repetir estos pasos en el CPD de respaldo.

Cuando nos conectemos al vCenter 5 de cualquiera de los sitios, veremos cómo está SRM perfectamente registrado, deberemos instalarnos como de costumbre el plugin necesario para su administración, sabemos que es una instalación sencilla estilo MyWife (sí cariño, si cariño)

Veremos en nuestro vCenter 5 que disponemos de un icono en el ‘Home’ de Site Recovery en Solutions and Applications.

Ok, lo primero será configurar básicamente SRM, para ello deberemos enlazar en ambos sentidos los dos CPDs (si nos interesase, como veremos en otro documento una vuelta atrás), pero para ello antes deberemos enlazar SRM del sitio principal con vCenter del sitio remoto; así que desde el sitio principal (recién creado) configuramos la conexión (Configure connection) -:)

Introducimos la dirección del vCenter de respaldo en cuestión, “Next”,

Nos dará una advertencia sobre el certificado ya que todos los que utilizo yo son auto firmatos y por lo tanto no confiamos en ellos, en este documento se han omitido todas las alertas en cuanto a advertencias de certificados.

Introducimos unos credenciales con privilegios administrativos en el vCenter remoto, “Next”,

Esperamos mientras dicha conexión se realiza & “Finish”!

Ok, ahora nos loguearemos contra él; de igual forma configuraremos el sitio de respaldo (en mi caso el principal será ‘Bilbao vc01’ & el de respaldo ‘Bilbao vc02’).

Una vez disponemos de ambos sitios conectados con los vCenter correspondientes, configuraremos el mapeo entre los distintos sitios, recursos (clúster, carpetas, redes…), empezamos desde el sitio principal, pestaña ‘Resource Mappings’ > clúster origen & ‘Configure Mapping’. Estos mapeos permitirán a las máquinas que dispongan de dichos recursos conocerlos en el otro CPD, a la hora de ubicarlos en una carpeta, darle conectividad  a nivel de red…

Indicamos el clúster destino en este caso, donde levantaremos las máquinas que repliquemos a dicho site. “OK”,

Listo, confirmamos que el mapeo es correcto, ahora debemos proceder de igual forma entre todas las pestañas de mappings.

Configuraremos los mappings de las carpetas,

Configuramos los mappeos entre las distintas redes,

Será necesario un datastore pequeño (Placeholder Datastore), en este almacén se guardarán las configuraciones de las MV, los archivos de definición (.vmx)… todos los hosts que necesiten proteger/recuperar las MV’s deberán tener acceso a dicha LUN, en principio con el tamaño mínimo de VMFS5 valdría (1,2Gb), presentamos dicha LUN a los hosts, la formateamos & la seleccionamos.

Una vez configurados los pasos en el sitio principal, deberemos realizar lo mismo en el otro CPD con la intención comentada anteriormente, una posible vuelta atrás (no soportada con la replicación a nivel de MV, si no mediante SRA con la replicación de las cabinas).

Así que configuramos los mapeos del sitio secundario al principal, a nivel de clúster,

Configuramos los mapeos de las carpetas,

Configuramos igualmente los mapeos de las redes virtuales,

En este sitio también tendremos que indicar cuál será el datastore donde guardará los archivos de configuración de las máquinas virtuales, ok, listo.

Bien, antes de continuar, deberemos comprobar tanto en el vCenter principal así como en el secundario la dirección IP que hemos indicado la dirección de administración de vCenter (desde el cliente de VMware vCenter > “vCenter Server Settings” > “Runtime Settings” > “Managed IP Address”).

Ok, continuamos, configuraremos “vSphere Replication” si nos insteresase realizar la réplica de nuestro CPD principal al secundario utilizando las réplicas basadas en VMware, pinchamos en “Deploy the VRM Server” en nuestro CPD principal y posteriormente lo haremos en el secundario; en el caso de disponer unas cabinas de almacenamiento, y querramos replicar las LUN con ellas omitiríamos este paso y lo configuraríamos desde “Array Managers”.

Desplegaremos por tanto un virtual appliance de VMware llamado vSphere Replication Manangement Server o VRMS desde un fichero OVF. “OK”,

“Siguiente”,

Confirmamos que estamos desplegando el vapp VRMS de VMware, “Next”,

Le proporcionamos un nombre y lo colocamos en nuestro inventario, “Next”,

Seleccionamos el clúster donde albergar dicha máquina, “Next”,

Seleccionamos el host donde se ejecutará VRMS,

Así como donde almacenaremos, podrá ser en un datastore local,

Seleccionamos el formato del disco, normalmente ‘thin’,

Bien, configuramos el password del usuario ‘root’, indicamos la puerta de enlace, dirección IP y máscara de red, “Next”,

Si previamente hemos comprobado que tenemos perfectamente registrado nuestra dirección de management del vCenter podremos continuar ya que VRMS necesitará registrarse contra la dirección IP correcta de nuestro vCenter.

Bien, finalizamos con el despliegue de la MV, confirmamos que todo es correcto & “Finish”,

… esperaremos mientras despliega & arranca…

Confirmamos que el appliance de VMware VRMS ha arrancado correctamente, confirmamos la URL para gestionarlo.

Abrimos un navegador contra https://DIRECCIÓN_IP_VRMS:8080, entramos como ‘root’ y la clave que indicamos durante el asistente.

Ok, antes de configurar y registrar dicha máquina contra nuestro vCenter, necesitaremos crear previamente una base de datos en nuestro servidor de BBDD. Además será requisito fundamental el disponer de la autenticación mixta en nuestro servidor SQL (si es que usamos uno de estos), crearemos un usuario de SQL & lo asociaremos a dicha BD.

Y configuraremos VRMS contra ella, en principio no haría falta crear la BD antes ya que si se supone que realizas la configuración manual la debería crear el propio asistente, tras bastante tiempo de búsqueda y a día de hoy, habría que indicar configuración manual, crear la BD antes & autenticación mixta. Configuramos el resto de parámetros, el tipo de servidor de BD, los puertos necesarios 1433tcp (en el caso de SQL Server), usuario SQL, BD SQL, dirección IP del servidor vCenter al que pertenece y donde se registrará el VRMS, mail para las alertas, si queremos otro certificado… una vez completada toda la información, iremos a “Save and Restart Service”, comprobaremos que el servicio VRM está ‘running’.

Adicionalmente podremos desde este interfaz: Modificar parámetros de red, nombre equipo, aplicar actualizaciones en el appliance, y tareas de mantenimiento (apagado, reinicio…).

Una vez tenemos nuestro primer VRMS desplegado deberemos configurar una conexión con el VRMS de la delegación de respaldo, para ello primero debemos confirmar que hemos realizado los dos primeros pasos,

Si cambiamos al site remoto deberemos repetir los pasos del despliegue del appliance virtual, así como crear una BD en aquel sitio & finalizar los mismos pasos que seguimos con el VRM Server del site principal, así como registrar la dirección IP correcta de management en dicho vCenter.

Lo dicho, desplegamos el OVF en Donosti…

… continuamos el despliegue…

Ok, una vez tenemos los dos vSphere Replication Manangement Server’s desplegadosdeberemos configurar la conexión entre ellos, desde “Configure VRMS Connection”,

“Sí”,

Introducimos los credenciales con rol administrador del vCenter Server remoto & “OK”,

Damos por buena la conexión, “OK”,

Ahora debemos desplegar el vSphere Replication Server o VR Server,

“OK” para desplegar desde imagen portable,

Confirmamos que vamos a desplegar VMware vSphere Replication Server, “Next”,

Indicamos un nombre para el appliance y un nombre, “Next”,

Identificamos el clúster donde residirá,

Así como al host al que irá asociada y donde se ejecutará, “Next”,

Seleccionamos el datastore donde la guardaremos,

Seleccionamos también el formato de disco, ‘thin’ normalmente,

Además configuramos los parámetros de red necesarios (IP, DNS, Máscara & gateway),

Confirmamos que todo es correcto & “Finish”,

… esperamos mientras despliega & arranca…

Esperamos a que arranque bien la máquina & nos indica la URL para gestionar este vSphere Replication Server,

Entramos en la URL: https://DIRECCIÓN_IP_VRS:5480 con ‘root’ y contraseña predeterminada ‘vmware’,

Deberíamos modificar el hostname del appliance, vemos que es una SUSE 11, al igual que VRMS; en principio no necesitaremos más desde este interfaz.

OK, debemos registrar en el vCenter dicho servidor VR, para ello “Register a VR Server”

Lo buscamos por el árbol & “OK”,

Confirmamos que deseamos registrar este vSphere Replication Server, “Sí”,

“OK”,

Y repetimos los pasos en el CPD remoto, deberemos desplegar al menos un appliance VR Server, repetiremos los pasos similares al CPD principal,

Desplegando el vSphere Replication Server igualmente desde un OVF…

… seguimos & finalizamos el asistente…

Y de igual forma que lo registramos anteriormente, este VR Server deberemos registrarlo en el vCenter de respaldo.

Lo seleccionamos & “OK”,

A partir de ahora ya podremos configurar de forma independiente la replicación de las máquinas virtuales que nos interesen del CPD princpal al de respaldo; como hemos comentado esta replicación es a nivel de máquina virtual (no de datastore) y será por bloque modificado! para habilitar dicha replicación, en cada máquina a proteger, con botón derecho “vSphere Replication…”

Indicaremos el margen de replicación que varía desde cada 15 minutos a 24h, indicaremos además si queremos que se apoye en las VSS de Microsoft a la hora de realizar la copia (lo utilizaremos en los servidores de bases de datos), así como indicaremos la LUN destino donde se replicará esta MV, “Siguiente”,

Seleccionamos el formato del disco que generará (thin o thick) en el destino, “Next”,

Seleccionamos el servidor VR Server que replicará esta máquina,

Confirmamos que todos los parámetros son correctos & “Finish”,

Configuración realizada en esta máquina, “OK”,

Si nos colocamos en la pestaña “Virtual Machines” veremos el estatus actual de las máquinas que se están replicando, así como las que ya se replicaron o el tamaño de su última réplica o el tiémpo de réplica.

Ok, una vez seleccionado el sistema de replicación, ahora deberemos configurar su protección, donde crearemos un grupo de protección de las máquinas que seleccionemos (nuestras máquinas críticas), picamos en “Create a Protection Group”,

Seleccionaremos el sitio protegido, así como el sistema de replicación que tenemos configurado, en el caso actual será replicación de VMware, marcamos vSphere Replication (VR), “Next”,

Marcamos las máquinas que queremos meter en este grupo de protección, “Next”,

Indicamos un nombre comprensivo para la protección de nuestras máquinas, “Next”,

Confirmamos que la config es correcta & “Finsih”,

Confirmamos que disponemos ya de un grupo de protección creado, que su status es ‘ok’ y que tenemos el nº correcto de MV’s protegidas,

Si nos fijamos, en el vCenter destino ya tendremos las réplicas de las máquinas que indicamos en el grupo de protección listas para ser arrancadas en caso de necesidad por SRM, comprobamos que están apagadas y tienen otro icono.

Bien, lo importante será crear un buen plan de recuperación, donde agregaremos todas las máquinas que protegeremos, estas máquinas se replicarán al CPD destino y deberemos configurar un orden de apagado/encendido así como distintas opciones. Una vez tengamos el plan de protección creado será indispensable probarlo y testearlo, para ello necesitaremos una red privada en nuestro CPD de respaldo que será donde encienda las MVs réplicas y las conecte a dicha red para no afectar a la producción duplicando IP’s. “Create Recovery Plan”,

Seleccionamos el sitio de recuperación como CPD respaldo, “Next”,

Seleccionamos los/el grupo de protección recién creado & “Next”,

Seleccionamos las redes para el test, que será una red aislada o por lo menos separada de la de producción para no duplicar las IP’s,

Indicamos un nombre al plan de protección, “Next,”

Confirmamos que todo es OK & “Finish”.

Lo dicho, una vez creado el plan de protección, vamos a la pestaña “Recovery Steps” que será donde configuremos el orden correcto de arranque de nuestras MVs, indicando más o menos prioridad… sobre una MV, botón derecho “Configure…”

Podríamos si nos interesase levantar esta máquina con otro direccionamiento IP,

Seleccionamos el grupo de prioridad a aplicar a dicha máquina,

Podríamos además configurar unas dependencias entre nuestras máquinas virtuales (que pertenezcan al mismo grupo de protección),

Como acción de apagado podremos indicar un timeout en caso que las VMware Tools no respondan a tiempo o directamente hacerle un Power off a la máquina origen,

Lo mismo en el caso del encendido, podremos indicar que arranque o no dicha MV en el destino, así como si nos interesa esperar a las VMware Tools o no además de indicar un tiempo de espera. Las dos últimas opciones serían unas tareas/comandos que podríamos ejecutar antes de encender la máquina o después de encenderla.

Bien, una vez configurados bien los pasos de recuperación deberemos testear el entorno para conocer si en caso de necesidad esto nos funcionaría! 🙂 Le damos al botón de “Test”,

Marcamos “Replicate recent changes to recovery site” si nos interesa que durante esta prueba de test replique los últimos cambios de las máquinas virtuales protegidas, “Next”,

Confirmamos que todo es correcto & “Start”!

Tras unos minutos, iremos comprobando el despliegue de las máquinas, sus réplicas, cómo enciende las MVs en destino… una vez que nuestro test de todo como correcto podremos darlo por finalizado! Además de ser una tarea periódica las revisiones de estos planes de recuperación.

Una vez finalizado procedemos a realizar una limpieza del entorno que deshaga todos los pasos anteriores, realizamos un cleanup.

“Next” para ejecutar el asistente de limpieza, si este asistente nos fallará nos saldría la opción de realizar un “Force Cleanup” que continuaría con la limpieza aún que exista cualquier error durante dicha ejecución.

Confirmamos que es correcto & “Start”,

Listo! perfecto! y bueno, ahora al ser un LAB haré la prueba de recuperación completa en el CPD de respaldo, pulso (y yo sólo -:) “Recovery”

Tenemos dos opciones a la hora de recuperar nuestro entorno, una primera ‘Planned Migration’ que moverá nuestro entorno virtual del CPD principal al secundario con las últimas modificaciones en nuestras máquinas virtuales, en caso de error al replicar estos últimos cambios el plan de recuperación se cancelará. Yo seleccionaré la segunda opción, quizá más nazi, en caso de que me falle la réplica, continuará levantando el entorno virtual en el CPD secundario, “Next”,

Confirmamos que todo es correcto & “Start”,

Y listo! tenemos todos los pasos de la recuperación de mi CPD desde Bilbao a Donosti sin ningún problema