Queridos amigos del blog de Encora y del Encora TV, os queremos presentar un nuevo capítulo de Encora Webinars, realizado en noviembre de 2021 por nuestro TAM & Presales Manager, Nacho Bellido.
Nos explicará cómo utilizarlo para disponer de toda nuestra infraestructura replicada en Azure.
También repasaremos los principales puntos de un proyecto de Azure Site Recovery.
CÓMO PROTEGER TU ENTORNO CON AZURE SITE RECOVERY
Azure Site Recovery Manager es una forma de tener nuestro entorno replicado en Azure.
En el Cloud de Microsoft puedes tener un Recovery Site de tu empresa ubicado en cualquier parte del mundo.
Lo podrás conectar con tu entorno en producción, ya sea on premise o Cloud.
¿Cuál es el proceso?
No es un activo – activo, no es una réplica, como si tuviéramos otro CPD que está completamente levantado en nuestro entorno.
Con Azure Site Recovery lo que estamos haciendo es replicar nuestro entorno on premise o nube hacia Azure y almacenándolo en un disco.
¿Porqué lo almacenamos en un disco?
Ya sabéis que en todas las nubes el formato es pago por uso, entonces, la factura que tenemos que pagar a final de mes depende del uso que le estamos dando al equipamiento. Al tratarse de un disco, el coste es más ligero que si tuviéramos completamente el entorno levantado en tiempo real para poder hacer un cambio o conmutar en caso de necesidad.
¿Qué es lo que podemos replicar en Azure Site Recovery?
Podemos replicar entornos físicos, entornos virtuales, VMware, HyperV, Linux, Windows, etc.
Como todo, tiene siempre algún matiz. La parte de Linux tiene que ser dentro de Linux. Hay unas distribuciones que son las que están soportadas y que se pueden implantar en Azure sin ningún problema y hay otras que puede ser que tengamos que hacer algunas modificaciones.
Azure Site Recovery una solución muy sencilla.
Dentro de un solo panel tenemos absolutamente todo, podemos hacer una recuperación completa, podemos gestionar, configurar y administrar las réplicas, y podemos hacer eso mismo, pero con un entorno de test.
El entorno cerrado es como un sandbox en el que podemos probar todo nuestro entorno de réplica sin afectar a la producción.
Los planes de recuperación personalizados nos permiten hacer infinidad de tareas.
Normalmente, cuando vamos a arrancar un entorno en Disaster Recovery, siempre tiene que haber un orden establecido para levantar los servicios.
Debemos contar con que no hay nada, o sea, todo ha caído, entonces lo primero que deberíamos levantar es nuestros controladores de dominio. Porque es lo básico, sin eso no vamos a poder ingresar en ningún servicio. Luego seguimos con bases de datos de servidores de ficheros, vamos a ir levantando todo en orden.
Podemos agregar en algunas máquinas, si necesitamos hacer algún post-proceso, un script de post proceso y luego aprovechar todos los Run Box que tenemos en Azure.
Podemos automatizar muchas tareas si queremos personalizar aún más nuestro entorno.
RPO y RTO, obviamente alineados con las necesidades de negocio. Máximo 30 segundos, que sería el tiempo desde que se nos cae el entorno hasta que tenemos una réplica completa.
¿Qué es el DRP?
El DRP (Disaster Recovery Plan) al final es un plan en el que tenemos que recoger todos los pasos que debemos dar para cuando llegue este momento.
Lo que suele ocurrir es que este plan, o no está bien desarrollado, o no se han cubierto algunos aspectos importantes.
Por ejemplo, ¿por qué pasamos a DR? ¿Qué puede ocurrir para que pasemos a DR? ¿Tiene que ser una caída total de nuestro sistema? Sí.
¿Cuánto tiempo se tarda en levantar el DR? Eso es importantísimo. Si no sabemos cuánto tiempo tardamos en levantarlo. ¿Cuánto tiempo tardamos en devolver el servicio? No tendremos nunca claro si podremos pasar a DR o no.
Azure Site Recovery no es un backup.
En ningún momento, debemos tomarlo como copia de seguridad. La copia de seguridad es una copia, es una copia de un punto exacto.
Sí pretendemos trabajar con DR como copia de seguridad, será un error.
Si nos infectan con un ransomware, nos atacan a las máquinas, nos cifran en el OnPremise y también nos cifran en el DR, porque estamos replicando, cogemos el dato y nos lo llevamos. Entonces, si lo cifran abajo estará cifrado arriba.
Hay planes de Azure Site Recovery para protegernos de eso. Para eso tenemos las distintas instantáneas. Podemos decidir cuántas veces queremos almacenar dentro de un mismo día si queremos almacenar una cada hora, o sacar una instantánea cada 3 horas y esas guardarlas durante 3 días. Todos esos esos mecanismos son los que nos permiten estar protegidos ante este tipo de caídas.
Detalles importantes de Azure Site Recovery
Tenemos que saber qué es lo que vamos a levantar y en qué situaciones lo vamos a levantar.
Si es una pérdida eléctrica, ¿bajamos a DR? Bueno, pues habría que analizar como de crítica es esa esa pérdida de energía. ¿Cuánto tiempo vamos a estar sin energía? Y en el caso de arrancar de DR y todos nuestros trabajadores están en la oficina, quizás no solucionamos nada porque no tenemos métodos de conexión desde nuestra oficina porque no hay electricidad y no podemos conectar al DR.
Son detalles que parecen que son ligeros, pero hay que tenerlos siempre por escrito.
Otra de las ventajas de tenerlo por escrito es ensayarlo una y otra vez.
Cuando ponemos una puesta en producción de este tipo de planes siempre incluimos tests de DR cada dos meses.
Cuantas más veces ensayamos, más fácil es. Sabemos cuánto tarda en levantarse, el orden en que tienen que levantarse las máquinas. Sabemos la forma en la que se van a conectar nuestros usuarios.
Hitos de un proyecto de Azure Site Recovery
Planificación
Tenemos una herramienta que se llama Capacity Planner. Nos vale para instalarlo dentro de vuestro entorno y monitorizar la tasa de cambio de vuestras máquinas. Con eso obtendremos información y gráficas de consumo de iops, de consumo de ancho de banda, de las modificaciones que se van creando en las máquinas y el uso que le dais a esas máquinas. También sacamos las horas punta y las horas valle.
Dimensionamiento
Con toda esta información podemos dimensionar:
- Porque en el DR, no tenemos por qué llevar exactamente tal y como tenemos las máquinas.
- Porque en un entorno on premise, siempre tendemos a sobre-dimensionar las máquinas, como al hardware ya lo tenemos, ya no nos cuesta más. Cuanto más anchas vayan las máquinas, más espacio tengan y más memoria disco, pues mejor pueden trabajar.
Pero en un entorno de DR no tiene por qué ser así necesariamente.
En Azure Site Recovery tenemos pago por uso y tenemos el crecimiento prácticamente ilimitado.
Entonces las máquinas hay que dimencionarlas para tener la capacidad que necesitan y si necesitan las hacemos crecer o decrecer en cualquier momento, pero no tenemos que sobredimensionar.
Arquitectura
Muchas veces no somos conscientes de cómo se van a ir conectando nuestros usuarios tras un desastre. Porque en un DR se levantan los servidores, pero luego según el tipo de caída que sea, no puedes contar con tu oficina.
En este proceso arquitectura tenemos que dar alternativas. ¿Qué podemos hacer para que nuestros usuarios se conecten si en la oficina no tenemos conexión a Internet?
Bueno, que puedan conectarse desde otros dispositivos, que puedan conectarse desde casa, pueden usar líneas de dispositivos móviles, etc.
Todo esto lo tenemos que dejar por escrito en detalle en la arquitectura del plan.
Transformación de servicios
Podemos tener un entorno de directorio activo, conectado por la VPN y en lugar de tener solo nuestro Directorio activo on premise, tener una máquina más que se replica en tiempo real con las nuestras y tenerla en nube. Esto nos vale para no tener que replicar el directorio, así tendríamos todas las máquinas.
Podríamos correr el riesgo de ataques de ransomware, pero en Azure podríamos tener copias de seguridad que se restauran en segundos. En escasos minutos podríamos restaurar un control de dominio con una copia nativa dentro de Azure.
Buenas Prácticas
Pilar fundamental: todo va a pasar por el DRP.
Todo lo que esté incluido en el Plan de Disaster Recovery será mucho más sencillo de mantener y de interiorizar.
Teniendo un plan bien detallado es muy sencillo de operar con él. No tiene por qué ser extenso, no tiene por qué ser aburrido, no tiene por qué tener una duración determinada en páginas.
RTO y RPO
Debemos tener en cuenta cuál es el tiempo máximo que podemos asumir desde que se nos cae el entorno hasta tener la copia en un segundo punto.
Y luego, saber el tiempo que tardamos en reanudar ese servicio desde que se ha caído, hasta que lo tengo levantado y los usuarios vuelven a acceder y estoy en un porcentaje razonable en el que puedo trabajar y retomar mi actividad.
Las alertas
En Azure Site Recovery las alertas son importantes porque hay que monitorizar el entorno. Un DR no lo monto y funciona solo, siempre va a dar problemas, cuando agregamos nuevas máquinas van saliendo parches, hay que incorporar nuevos agentes, agregar funcionalidades nuevas. Todo esto hay que irlo depurando mes tras mes y hay que seguirlo trabajando.
Puntos de restauración
Hay que tenerlo muy en cuenta de cara a una infección de ransomware.
Si cerramos la empresa desde el viernes y hasta el lunes, normalmente si no hay nada grave, pues no se suele trabajar.
Es importante que este DR supere esos dos días, porque si nos infectan el viernes a última hora y nos enteramos el lunes a primera, lo que puede ocurrir es que todo lo que tengamos en el punto de restauración, también cifrado, porque ya hemos replicado toda esa información.
Entonces es importante tenerlo más de 3 días guardarlo.
Las conmutaciones de test
Os lo he repetido muchas veces, pero insisto, es importantísimo. Hay que seguir probando, hay que levantar los entornos y aunque parezca que es aburrido y que al final se hace pesado, hay que hacerlo porque es la única forma de estar más preparados para cuando llega el momento en que lo tenemos que usar.
Servicio gestionado
En todos los proyectos de Azure Site Recovery que hacemos, siempre incluimos un servicio gestionado. Para fijar los RTO y RPO con el cliente, para definir las alertas, monitorizar las recibidas. Diariamente se reciben alertas diciendo: Oye, pues esta máquina ha superado la tasa de cambio permitida para este tipo de máquina. Bueno, pues, quizás es una base de datos muy potente y hay que modificar esos discos para que soporten mayor tasa de cambio.
Son cosas que hay que ir haciendo día a día porque el proyecto del DR en Azure Site Recovery no se hace una única vez y se acabó. El proyecto tiene que mantenerse vivo y tiene que ir creciendo. Hay que actualizar el entorno, hay que parchear sistemas operativos.
Las bases de datos de SQL cuando están en modalidad «always on», están soportadas ya en Azure Site Recovery. ¿Qué ocurre? Pues que hay que actualizar la base de datos, el motor y tenerlo actualizado a las últimas versiones para que esté soportado dentro de los agentes.
¡Esperamos que os haya gustado este Encora webinar sobre Azure Site Recovery!
Más información
Os dejamos más información sobre Azure Site Recovery de la web de Microsoft.
¿Qué ofrece Azure Site Recovery?
| Característica | Detalles |
|---|---|
| Solución de BCDR simple | Mediante Azure Site Recovery se pueden configurar y administrar la replicación, la conmutación por error y la conmutación por recuperación desde una sola ubicación en Azure Portal. |
| Replicación de máquinas virtuales de Azure | Puede configurar la recuperación ante desastres de máquinas virtuales de Azure de una región primaria a una secundaria. |
| Replicación de máquinas virtuales de VMware | Puede replicar máquinas virtuales de VMware en Azure mediante el dispositivo de replicación de Azure Site Recovery mejorado que ofrece una mayor seguridad y resistencia que el servidor de configuración. Para más información, consulte Recuperación ante desastres de máquinas virtuales de VMware. |
| Replicación de máquinas virtuales local | Las máquinas virtuales y los servidores físicos se pueden replicar en Azure o en un centro de datos local secundario. Si se replican en Azure Site Recovery, se elimina el costo y la complejidad de mantener un centro de datos secundario. |
| Replicación de la carga de trabajo | La replicación de cualquier carga de trabajo que se ejecuta en máquinas virtuales de Azure compatibles, máquinas virtuales de Hyper-V y VMware locales y servidores físicos Windows o Linux. |
| Resistencia de datos | Azure Site Recovery coordina la replicación sin interceptar los datos de las aplicaciones. Cuando se realiza la replicación en Azure, los datos se almacenan en Azure Storage con toda la resistencia que proporciona. Cuando se produce la conmutación por error, las máquinas virtuales de Azure en función de los datos replicados. |
| Destinos RTO y el RPO | Mantenga los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO) dentro de los límites de la organización. Site Recovery proporciona una replicación continua tanto a las máquinas virtuales de Azure como a las máquinas virtuales VMware con una frecuencia de tan solo 30 segundos para Hyper-V. Para reducir aún más el RTO, realice la integración con Azure Traffic Manager. |
| Mantener la coherencia de aplicaciones a través de la conmutación por error | Puede realizar la replicación mediante puntos de configuración con instantáneas coherentes con la aplicación. Estas instantáneas capturan los datos del disco, todos los datos en que hay en la memoria y todas las transacciones en curso. |
| Pruebas sin interrupciones | Puede ejecutar fácilmente maniobras de recuperación ante desastres, sin que ello afecte a la replicación en curso. |
| Conmutaciones por error flexibles | Puede ejecutar conmutaciones por error planeadas para las interrupciones previstas sin pérdida de datos. O conmutaciones por error no planeadas con la mínima pérdida de datos, dependiendo de la frecuencia de replicación, para desastres inesperados. Puede conmutar por recuperación a su sitio principal fácilmente cuando vuelva a estar disponible. |
| Planes de recuperación personalizados | Con los planes de recuperación, puede personalizar y secuenciar la conmutación por error y la recuperación de aplicaciones de niveles múltiples en varias máquinas virtuales. Puede agrupar las máquinas en un plan de recuperación y, opcionalmente, agregar scripts y acciones manuales. Los planes de recuperación se pueden integrar con runbooks de Azure Automation. |
| Integración de BCDR | Azure Site Recovery se integra con otras tecnologías de BCDR. Por ejemplo, puede utilizar Site Recovery para proteger el back-end de SQL Server de cargas de trabajo corporativas, con compatibilidad nativa para SQL Server AlwaysOn, a fin de administrar la conmutación por error de grupos de disponibilidad. |
| Integración de Azure Automation | Una ingente biblioteca de Azure Automation proporciona scripts específicos de la aplicación y preparados para la producción que se pueden descargar e integrarse con Site Recovery. |
| Integración de red | Azure Site Recovery se integra con Azure para la administración de la red de aplicaciones. Por ejemplo, para reservar direcciones IP, configurar equilibradores de carga y usar Azure Traffic Manager para los cambios de red eficientes. |
¿Qué puedo replicar en Azure Site Recovery?
| Compatible | Detalles |
|---|---|
| Escenarios de replicación | Replique las máquinas virtuales de Azure de una región de Azure a otra. Replique las máquinas virtuales de VMware locales, las máquinas virtuales de Hyper-V, los servidores físicos (Windows y Linux) y las máquinas de virtuales Azure Stack en Azure. Replique las instancias de Windows de AWS a Azure. Replique las máquinas virtuales locales de VMware, de Hyper-V administradas por System Center VMM y los servidores físicos en un sitio secundario. |
| Regiones | Revise las regiones admitidas para Azure Site Recovery. |
| Máquinas replicadas | Revise los requisitos de la replicación de máquinas virtuales de Azure, máquinas virtuales y servidores físicos de VMware locales y los máquinas virtuales de Hyper-V locales. |
| Cargas de trabajo | Puede replicar cualquier carga de trabajo que se ejecute en una máquina que se admita para la replicación. Y que el equipo de Azure Site Recovery haya hecho pruebas específicas de la aplicación para un número de aplicaciones. |
Gracias por compartirlo en redes sociales. Esperamos vuestros comentarios.
¡Hasta pronto!
