Sigue leyéndonos si quieres entender el servicio de Disaster Recovery de Jotelulu.
El servicio de Disaster Recovery de Jotelulu pretende asegurar que tanto nuestros partners como sus clientes dispongan de una herramienta para garantizar la supervivencia de sus infraestructuras y servicios en caso de que se produzca una contingencia severa en el datacenter donde se encuentren hospedados los servicios.
Este servicio permite evacuar las suscripciones de Servidores o Escritorio Remoto minimizando el impacto en el servicio que estos proporcionan y llevándolos a otra región para asegurar que el servicio no se vea afectado.
Disaster Recovery de Jotelulu permite al partner seleccionar una suscripción de servidores existente dentro de Jotelulu y replicarla en otra zona de disponibilidad, garantizando que los datos estarán diligentemente replicados según la periodicidad que el administrador haya definido. Una de las garantías que nos ofrece este servicio es que, cuando la infraestructura se evacúe al lugar remoto, seguirá manteniendo el direccionamiento de red público y privado (IPv4), así como todos los servicios que el cliente tuviera publicados en el origen. Con esto, el cliente consigue que, aunque se produzca la evacuación de los recursos, todos los cambios sean transparentes y el servicio se encuentre evacuado en cuestión de muy poco tiempo.
NOTA: Debemos decir, antes de continuar, que este es un servicio “vivo”, como todos los servicios de Jotelulu, motivo por el que, con el tiempo, este servicio irá evolucionando y tomando nuevas funcionalidades.
NOTA: Una suscripción de DR puede tener uno o más planes de DR en su interior.
NOTA: Un plan de DR solo puede tener una suscripción de origen.
De entrada tenemos una primera suscripción: esta es la suscripción que proporciona servicio a nuestros clientes originalmente. Si sobre esta suscripción, que pongamos que es de servidores, activamos el servicio de Disaster Recovery (DR), lo que sucederá es que se activará una segunda suscripción en otra región, que se comportará como un espejo y sobre la que se hará una replicación de los contenidos de la primera suscripción, de la suscripción operativa.
Cuando establecemos la replicación, se deben configurar una serie de puntos como el número de copias que guardaremos, cuándo empezamos a hacer la copia o cada cuánto haremos la copia, pero esta configuración no es inamovible.
La suscripción espejo, que se ha creado para dar respaldo a nuestra suscripción funcional (la que realmente está operativa), no será visible para los usuarios mientras esté activa la suscripción principal.
Si en algún momento decidimos pausar o detener la replicación de DR, se dejarán de replicar los datos a la suscripción de respaldo, pero hay que establecer una pequeña diferencia entre las dos formas en que se puede pausar la replicación. Cuando hablamos de detener una suscripción de DR, por un lado tenemos la opción de pausarla y por otro lado tenemos la opción de detenerla:
- Pausa: Cuando pausamos la replicación, lo que sucede es que no se hacen más replicaciones hasta que se vuelva a activar.
- Detención: Cuando detenemos la replicación, lo que sucede es que no se hacen más replicaciones hasta que se vuelva a activar, pero además, podemos proceder a cambiar la configuración si así lo deseamos.
Si por lo que fuera en un momento dado se quiere activar el faliover y evacuar los recursos a la suscripción de respaldo, estos pasarán a tomar el control y a operar, pero no porque se haga una evacuación muy rápida sino porque se habrá estado haciendo la copia cada cierto tiempo y en función de la configuración deseada.
Esta operativa de failover lo que producirá, es que la suscripción secundaria, la que se creó al dar de alta el servicio de DR, pase a estar visible y accesible, proporcionando el servicio, mientras que la suscripción de origen pasa a estar no accesible y por tanto no visible.
Para que esto suceda, inicialmente habrá que haber elegido una serie de parámetros, entre los que hemos comentado previamente que se encuentran el número de replicaciones, cada cuánto se replica, cuándo empieza, etc., pero también se tiene que haber seleccionado cómo se hace la replicación: si se hace por IP o por DNS, condicionando de esta manera la forma en que se han evacuado los recursos, aunque teniendo claro que finalmente, para que todo sea transparente de cara a los servicios prestados al cliente, se tendrá la IP de origen.
Por otro lado, también debemos saber que, una vez evacuados los recursos, en la nueva suscripción no tendremos replicación ni DR hacia ningún lado, ya que se trata de una nueva suscripción.
Conclusiones:
Tal como has podido ver en este artículo, entender el servicio de Disaster Recovery de Jotelulu es bastante sencillo, y el funcionamiento se basa en conceptos realmente simples.
Si quieres aprender más sobre este servicio puedes ir a nuestro blog para aprender sobre la parte teórica, en artículos como:
- 10 principales preocupaciones al montar un Disaster Recovery
- Disaster Recovery: Qué son RPO, RTO, WRT o MTD
- Por qué el Disaster Recovery es tan doloroso
- Disaster Recovery: qué es y por qué lo necesitamos
- Cómo evaluar riesgos y amenazas en la pyme
- Las 5 principales causas de pérdida de datos en la pyme
- Cuál es el coste real de no invertir en seguridad
- Pasos para gestionar un incidente de seguridad en IT
O ir a la parte de tutoriales donde encontrarás entradas como estas:
- Cómo activar un entorno Disaster Recovery
- Cómo configurar frecuencia y número de copias para la réplica en DRaaS
Si tienes preguntas o inquietudes sobre el servicio ¡contáctanos!
¡Gracias por acompañarnos!