El servicio de recuperación ante desastres basado en la nube acapara la atención

Puntos fuertes de recuperación ante desastres en la nube

Hoy en día, es probable que las aplicaciones estén mucho más distribuidas, ejecutándose en entornos virtualizados o (en el futuro) en contenedores. Esto ha cambiado el paradigma de la copia de seguridad y las tiendas tienen más flexibilidad para recuperar la totalidad o parte de los servicios de TI cuando sea necesario. Con un servicio de recuperación ante desastres basado en la nube, las empresas pueden:

• Brindar continuidad a sus servicios operativos, independientemente de dónde se entreguen.
• Realizar una conmutación por error táctica a los servicios secundarios en caso de una falla de hardware o software en algunos (o todos) de sus sistemas de TI
• Realice una conmutación por error controlada de las cargas de trabajo para permitir el mantenimiento de otros componentes, como la red o la infraestructura ambiental.
• Migrar cargas de trabajo para hacer frente a la demanda o el crecimiento no planificados
• Pruebe las capacidades de recuperación ante desastres a pedido sin impacto en los sistemas primarios

Por supuesto, el enfoque principal de BC/DR es cumplir con los acuerdos y objetivos de nivel de servicio proporcionados al negocio. Esto significa cumplir con las métricas de RTO (objetivos de tiempo de recuperación) y RPO (objetivos de punto de recuperación) de una aplicación a otra. Según los requisitos de RTO/RPO específicos de una organización, existen tres modelos principales de recuperación ante desastres en la nube:

Solo datos. El proceso de DR se enfoca en garantizar que una copia de seguridad de los datos esté disponible en la plataforma en la nube y represente el nivel más bajo de recuperación. Esto significa proteger datos como los que se encuentran en los servidores de archivos, incluidos los directorios de inicio y las carpetas compartidas. En caso de desastre, se puede acceder a los datos desde la ubicación DR en la nube. Dependiendo de la cantidad de datos que se deban restaurar, el tiempo de inactividad puede ser significativo e incluso requerir el envío físico de datos al sitio principal en un dispositivo para restaurar.

Basado en aplicaciones. El proceso de DR se enfoca en replicar los datos de la aplicación en la nube para una implementación secundaria de la aplicación. Los datos se mueven utilizando capacidades de aplicaciones nativas o un producto de terceros. La conmutación por error consiste en redirigir el acceso a la aplicación que se ejecuta en la nube (normalmente a través de cambios de DNS). La instancia de la aplicación secundaria se ejecuta permanentemente en la nube y recibe datos periódicamente.

Por supuesto, pasar a un servicio de recuperación de desastres basado en la nube tiene problemas.

Imagen de la máquina virtual. El proceso DR replica una imagen de máquina virtual completa, incluidos los datos, en la nube. La imagen de la máquina virtual en sí está inactiva (no se ejecuta) hasta que se necesita, momento en el cual se puede encender y acceder, generalmente a través de cambios de DNS. La copia de seguridad de imágenes de máquinas virtuales también se puede utilizar como un método para proteger las implementaciones de aplicaciones físicas (bare metal) a través de la replicación P2V.

Problemas de recuperación ante desastres en la nube

Por supuesto, pasar a un servicio de recuperación de desastres basado en la nube tiene problemas. Muchos de los siguientes ejemplos podrían experimentarse al implementar cualquier sistema DR; sin embargo, algunos son más específicos para las implementaciones en la nube.

Ancho de banda de la red. El ancho de banda es un problema desde varios ángulos. Primero, debe tener suficiente capacidad de rendimiento entre el sitio principal y la nube para garantizar que los datos se puedan replicar de manera oportuna sin demasiado retraso en la simultaneidad (lo que afecta el RPO). En segundo lugar, necesita suficiente ancho de banda disponible para recuperar los datos modificados en el sitio principal una vez que finalice el problema de DR. En tercer lugar, debe poder acceder a los servicios desde la nube, ya sea desde la red comercial interna o desde Internet con aplicaciones orientadas al cliente.

Seguridad de la red. Los datos que se mueven a la nube estarán fuera de la protección de la red privada en el centro de datos, por lo que deben cifrarse en tránsito como mínimo. El cumplimiento u otras restricciones reglamentarias pueden requerir que los datos se cifren en reposo cuando están fuera del sitio. Esto puede tener implicaciones sobre cómo se implementan las aplicaciones en el sitio, para garantizar que el proceso de encriptación no interfiera con las operaciones normales.

Direccionamiento de red. A medida que las cargas de trabajo de las aplicaciones se trasladan a la nube, las direcciones IP cambiarán. Cuando los servidores de aplicaciones principal y secundario se mantienen en el sitio, el direccionamiento IP se puede administrar con relativa facilidad, ya sea mediante la implementación de una red de nivel 3 entre sitios o mediante el enrutamiento. Mover una aplicación a la nube requerirá cambios en el DNS (para apuntar a la nueva ubicación del servidor/datos) y la modificación de la propia aplicación en algunos casos.

Latencia de conexion. La ejecución de aplicaciones desde la nube en lugar de en el sitio puede causar problemas de rendimiento debido al aumento de la latencia. Esto puede ocurrir si solo una parte de un servicio se migra a DR con problemas experimentados en la intercomunicación entre los servicios internos y externos.

¿Debe crear la capacidad DR usted mismo o comprar un servicio o producto de recuperación ante desastres basado en la nube?

Licencia. Las instancias de DR de las aplicaciones requieren la compra de licencias, según los términos del proveedor de la aplicación. Estas opciones de licencia pueden ser diferentes para las implementaciones en la nube o, en el peor de los casos, no ser compatibles.

Costo. El costo de implementar DR incluirá proporcionar servicios en la nube, capacidad de red adicional, licencias de software de respaldo dedicado y licencias de aplicaciones adicionales. Todo esto puede variar según la forma en que se entrega DR en la nube.

Opciones: ¿bricolaje o comprar?

¿Debe crear la capacidad DR usted mismo o comprar un servicio o producto de recuperación ante desastres basado en la nube? La recuperación ante desastres basada únicamente en datos se puede implementar de forma relativamente sencilla, copiando datos en un servicio de archivos basado en la nube o utilizando productos como Acronis Cloud Backup o Zetta’s DataProtect.

La recuperación ante desastres basada en aplicaciones se puede lograr creando una máquina virtual de destino con un proveedor de servicios en la nube e implementando la replicación en el nivel de la aplicación. Por supuesto, la organización de TI será responsable de garantizar que la imagen de DR VM se mantenga adecuadamente (revisada, actualizada) para mantenerse al día con la implementación de producción. Además, si se invoca la conmutación por error, los equipos de aplicaciones deberán participar para volver a mover los datos después de una conmutación por error. Ciertos productos de replicación basados ​​en bases de datos no admiten la replicación incremental de datos a la instancia de la base de datos principal (incluso si funcionan técnicamente), lo que puede presentar un problema.

Un servicio de recuperación ante desastres basado en la nube ofrece flexibilidad para brindar protección de datos a entornos locales.

La replicación de VM brinda la capacidad de mover una aplicación completa a la nube como una máquina virtual. Esta es una buena idea cuando existen dependencias complejas de aplicaciones/servidores, como Microsoft SharePoint, ya que no es necesario crear y mantener una imagen de máquina virtual separada. Hay productos disponibles de proveedores como Zerto, que se integran en el hipervisor y replican todas las E/S en la instancia de la nube. En una situación de recuperación, la imagen basada en la nube se usa para ejecutar el servicio de producción, siguiendo cualquier modificación de configuración, como establecer direcciones IP y hacer coincidir la especificación de hardware DR.

Con la mayoría de los productos de replicación basados ​​en bloques, la imagen de la nube puede parecer una copia coherente de la aplicación que, posteriormente, puede requerir una recuperación prolongada al iniciarse. Aquí es donde la capacidad de probar la imagen de recuperación se vuelve crítica. Probar significa abrir la aplicación de manera aislada en modo de recuperación ante desastres que permite realizar verificaciones de integridad sin afectar la aplicación de producción.

Comparación de servicios DR en la nube

¿Qué deben buscar los compradores al revisar un servicio de recuperación de desastres basado en la nube? Aquí hay algunos consejos adicionales:

• Base de costo. Cómo se cobra el servicio; por TB de almacenamiento o por VM? ¿Hay cargos adicionales por ejecutar en modo DR?
• Limitaciones de tiempo. ¿Cuánto tiempo puedo ejecutar el servicio en modo DR? ¿Hay alguna restricción sobre cuántos sistemas puedo conmutar por error?
• ¿Cómo funciona la conmutación por recuperación? ¿Puedo recuperar gradualmente la producción (recuperar solo los cambios) o necesito restaurar todos mis datos?
• ¿El servicio ofrece protección extendida? Si estoy en modo DR, ¿puedo también replicar mis datos en una tercera copia hasta que regrese a producción?

Un servicio de recuperación ante desastres basado en la nube ofrece flexibilidad para brindar protección de datos a entornos locales. A medida que las aplicaciones evolucionen, tal vez veamos que la distinción entre DR y las aplicaciones dispersas comienza a desdibujarse, y DR brinda protección y escalabilidad a las aplicaciones. Pase lo que pase, la necesidad de proporcionar resistencia a las aplicaciones y protección de datos siempre permanecerá.