Treo Blog

En este espacio puedes explorar las últimas tendencias y noticias en tecnología, seguridad informática e infraestructura TI.

  • Jonathan Rodriguez Paipa

Recuperación ante desastres rentable en entornos de nube híbrida

Por: Anil Yeluguri



Crédito: Pexels

A medida que más y más organizaciones pasan de los centros de datos locales a las nubes privadas, públicas e híbridas, es importante comprender que la alta disponibilidad no es lo mismo que la recuperación ante desastres (DR).


La planificación de la recuperación ante desastres es necesaria para recuperar sistemas cuando los desastres naturales o provocados por el hombre golpean la región o el centro de datos principal. Las recientes interrupciones en la nube pública sugieren que debemos tener un plan de recuperación ante desastres, incluso con la alta disponibilidad proporcionada por los proveedores de la nube pública. La planificación de la recuperación ante desastres debe ser parte de las discusiones iniciales sobre el diseño de la aplicación, lo que permite que la arquitectura de implementación se adapte a eventos imprevistos.

Dejarlo como una ocurrencia tardía podría conducir a desafíos de mantenimiento y al incumplimiento de los estándares regulatorios, de seguridad y de la industria.


Desafíos


Algunos desafíos comunes que la organización puede enfrentar al implementar planes de recuperación de desastres de un extremo a otro incluyen:

  • No asignar presupuestos de TI adecuados para cumplir con las expectativas de DR, lo que limita las velocidades de recuperación que los equipos de aplicaciones pueden diseñar dentro de las restricciones de costos.

  • Los equipos de desarrollo de aplicaciones dan prioridad a la construcción, las pruebas y la implementación de funciones en la producción y no consideran la recuperación ante desastres hasta que una auditoría interna o una escalada identifique esta brecha crítica para el negocio.

  • Mantenimiento de entornos de recuperación ante desastres con la complejidad de varios proveedores de nube pública, ya que no existe un único plano de control para administrar en todos los entornos.

Terminología clave y consideraciones iniciales de la planificación de la recuperación ante desastres


Comprender la terminología clave de DR y su contexto puede ayudar a conceptualizar la definición y planificación de un enfoque válido de DR.

  • Objetivo de tiempo de recuperación (RTO) : el tiempo máximo para restaurar la infraestructura y los servicios de aplicaciones después de un evento imprevisto, alineado con los requisitos de continuidad del negocio de una empresa.

  • Objetivo de punto de recuperación (RPO) : la cantidad de pérdida de datos que una empresa puede soportar sin un impacto comercial. RPO impulsa las estrategias de copia de seguridad y replicación de datos, fundamentales para mantener el negocio y cumplir con los requisitos de cumplimiento internos y externos.

  • Acuerdo de nivel de servicio (SLA): un compromiso entre un proveedor de servicios y un cliente. Generalmente, los SLA son aplicados por el equipo de cumplimiento en el departamento de TI y comunicaciones para alinearse con la misión comercial. Los SLA están estrechamente relacionados con la recuperación ante desastres y la continuidad del negocio, ya que definen la necesidad de resistencia del servicio.


Con la terminología clave de la recuperación ante desastres descrita, ¿cuáles podrían ser las consideraciones iniciales para definir un plan eficaz de recuperación ante desastres?

  • Identifique el RPO y el RTO de su aplicación según los requisitos comerciales, los requisitos de cumplimiento y el costo (pérdida de ingresos) del tiempo de inactividad. Esto puede ayudar a identificar el nivel de recuperación ante desastres adecuado para su aplicación. De acuerdo con los estándares de la industria probados en el tiempo, los niveles de DR van de 0 a 7. El nivel 7 se asigna a la mayoría de las aplicaciones críticas con tolerancia de pérdida de datos de cero a casi cero y un tiempo de recuperación del servicio de solo minutos. El nivel 0 se asigna a aplicaciones en las que la recuperación puede ser impredecible y, a veces, imposible. Un nivel de DR más alto generalmente significa un entorno de DR más costoso.

  • Identificar las dependencias de aplicaciones ascendentes y descendentes. Es especialmente importante saber cuándo una interrupción de una aplicación provocará una interrupción total o parcial del servicio en otras. Un plan de recuperación ante desastres de nivel empresarial ayudará a identificar estas dependencias y a asignar los niveles de recuperación ante desastres correctos a las aplicaciones.

Patrones DR estándar


Una vez que se han identificado los niveles de DR, un plan de DR específico para cada aplicación y sus requisitos de recuperación de datos ayuda a garantizar que solo ocurra una pérdida de datos aceptable y que el tiempo de recuperación esté dentro del SLA para su nivel de DR. A continuación se presentan los patrones e implementaciones de DR estándar, en orden de aumentar la resiliencia y el costo, y disminuir la pérdida de datos y el tiempo de recuperación.

  • Copia de seguridad y restauración : el DR más lento y menos costoso, este patrón se puede utilizar para aplicaciones capaces de soportar interrupciones del servicio de hasta 24 horas. Por lo general, las copias de seguridad programadas se almacenan en una región de recuperación ante desastres y se utilizan para restaurar una interrupción, o se almacenan en las instalaciones y se implementan en la infraestructura de una región de recuperación ante desastres para restaurar el servicio completo de la aplicación cuando sea necesario.

  • Pilot Light : los servicios centrales de la aplicación se ejecutan en la región de recuperación ante desastres en todo momento, ofreciendo inicialmente una funcionalidad reducida cuando ocurre un desastre, pero convirtiéndose en una recuperación completa a medida que se aprovisionan los servicios restantes. Este tipo de DR es el más adecuado para aplicaciones que pueden soportar la degradación del servicio durante varias horas.

  • Warm Standby (multirregión activa-pasiva): esta configuración permite una versión reducida de un entorno completamente funcional que está en funcionamiento en todo momento en la región de recuperación ante desastres, lo que puede significar un tiempo de recuperación más rápido, pero un costo más alto en comparación con Pilot Luz. Esta implementación debe usarse para aplicaciones críticas para el negocio que deben restaurarse por completo en unos pocos minutos.

  • Hot Standby (multirregión activo-activo con replicación completa) : en esta configuración, los entornos completamente escalados y funcionales (infraestructura y aplicación) se ejecutan en dos regiones geográficamente diferentes (primaria y secundaria) con sincronización asincrónica de datos en la región secundaria. Debido a que el tráfico se enruta a ambas regiones, tiene la tolerancia a fallas y la resistencia para resistir una interrupción que elimina una región completa, lo que lo convierte en la opción para sistemas de misión crítica, aunque a un costo mayor.


Tenga en cuenta que esta no es una lista exhaustiva de configuraciones de DR, y una organización puede combinar creativamente estas técnicas para adaptarse mejor a las necesidades de DR de un sistema específico y optimizar los costos.


Minimizar los costos de DR


Si bien las nubes públicas brindan flexibilidad inherente para escalar hacia arriba o hacia abajo según la demanda, lo que reduce el gasto de capital, es importante comprender que la recuperación ante desastres no está integrada y los equipos de aplicaciones deben implementar explícitamente un plan de recuperación ante desastres. En esta sección veremos cosas a considerar.


Cumpla con los SLA de nivel DR


Cumpla, sin exceder, las expectativas de SLA del nivel de DR asignado. Controle los costos de almacenamiento eligiendo cuidadosamente la clase de almacenamiento adecuada, de acuerdo con las reglas del ciclo de vida del proveedor de la nube, y eliminando los datos y las copias de seguridad que excedan sus SLA.


Automatice su infraestructura y procesos


La automatización juega un papel clave en el éxito de una implementación de DR porque, cuando ocurre un desastre, el tiempo de recuperación más corto es crítico. El tiempo para recuperar el servicio es directamente proporcional a la posible pérdida de ingresos y puede resultar en sanciones por no cumplir con los requisitos de cumplimiento. La recuperación ante desastres implica la integración precisa de varios componentes como la infraestructura, la sincronización de aplicaciones y datos, el enrutamiento, la seguridad y el cumplimiento y, a menudo, puede acelerarse con la automatización.


La automatización puede habilitar múltiples componentes bajo demanda de un sistema para el entorno de recuperación ante desastres en un centro de datos diferente o región de la nube utilizando marcos de infraestructura como código (IaC). Esto puede ayudar a minimizar los costos y cumplir con los SLA de recuperación requeridos. La automatización puede poner en funcionamiento más rápidamente el entorno de recuperación ante desastres según sea necesario y reducirlo cuando la región principal esté disponible, controlando estrictamente los costos. La automatización también brinda confianza al eliminar los pasos manuales involucrados con la capacidad probada durante la fase de prueba de DR.


Dependiendo del nivel de DR asignado a su aplicación, el tiempo que lleva iniciar todo el entorno de DR bajo demanda usando IaC puede no ser lo suficientemente rápido. En tales casos, se debe considerar qué componentes de la infraestructura de recuperación ante desastres deben activarse a pedido.


Independientemente de la configuración de DR seleccionada, es fundamental realizar pruebas de DR con regularidad para asegurarse de que se cumplan los SLA antes de que ocurra un escenario de DR real o cuando ocurra.


Red Hat Ansible Automation Platform es una plataforma de automatización empresarial que puede ayudar a reducir los costos y los riesgos en la infraestructura, la red y la ingeniería. Es independiente de la infraestructura con un marco y un lenguaje que se pueden aplicar en aplicaciones, computación, red, nube, contenedores y máquinas virtuales. Puede ayudar a mejorar las operaciones y puede funcionar bien con tecnologías que ya están en uso.


Utilice aplicaciones en contenedores


Los contenedores son componentes de software livianos que a menudo se utilizan con arquitecturas de microservicios para crear aplicaciones nativas de la nube en las que los servicios están débilmente acoplados y se pueden escalar de forma independiente.


Kubernetes es el estándar de la industria para administrar y organizar contenedores. Red Hat OpenShift Platform, la plataforma empresarial líder de Kubernetes, puede ayudar a construir, implementar, ejecutar y administrar aplicaciones inteligentes de manera más segura a escala en los principales proveedores de nube.


OpenShift también puede ofrecer ajuste de escala automático de clúster para cambiar el tamaño de su clúster en función de las demandas de su carga de trabajo. Ideal para escenarios Pilot Light y Warm Standby DR, el autoescalado contiene el costo de su entorno primario y DR y proporciona escalabilidad bajo demanda cuando el tráfico se enruta al entorno DR en un escenario de desastre.


Haga coincidir la elección entre clústeres zonales y clústeres regionales en nubes públicas con la importancia de su aplicación para reducir aún más los costos


Los clústeres zonales tienen un solo plano de control en una sola zona para los nodos en su zona o múltiples zonas. Los clústeres regionales en una región determinada tienen réplicas del plano de control que se ejecutan en varias zonas, cada una para los nodos de esa zona, lo que genera un costo adicional pero los hace más tolerantes a las interrupciones zonales.


Red Hat OpenShift se destaca como líder con una plataforma Kubernetes compatible y centrada en la seguridad. Red Hat OpenShift Dedicated es un servicio de nube totalmente administrado para Red Hat OpenShift en proveedores de nube como AWS y Google Cloud. También puede elegir entre ofertas totalmente administradas que ayudan a reducir la complejidad, como Microsoft Azure Red Hat OpenShift , Red Hat OpenShift en IBM Cloud , el servicio Red Hat OpenShift en AWS . Los servicios de nube administrados que utilizan Red Hat OpenShift le permiten concentrarse en crear y escalar aplicaciones que agregan valor a su negocio con la flexibilidad de elegir su proveedor de nube.


Red Hat Advanced Cluster Management para Kubernetes ayuda a reducir los costos operativos con una interfaz de administración unificada para administrar clústeres de Kubernetes en implementaciones locales, completas, vSphere y en la nube pública. Las características como el monitoreo de estado de múltiples clústeres pueden ayudar a escanear clústeres en todos los entornos para identificar y resolver problemas que afectan las cargas de trabajo y corregir más rápidamente las interrupciones del servicio.


Considere implementar una configuración sin servidor


Serverless es un modelo informático relativamente nuevo que se utiliza para crear y ejecutar aplicaciones sin tener que administrar los servidores en los que se ejecuta la aplicación. Las aplicaciones en un entorno sin servidor son conjuntos de una o más funciones ejecutadas bajo demanda y escaladas dinámicamente para satisfacer la demanda sin necesidad de planificación de capacidad.


Un modelo de computación sin servidor puede ser el modelo de elección para cargas de trabajo sin estado, altamente dinámicas, asíncronas o concurrentes. Además, la tecnología sin servidor se adapta bien a las cargas de trabajo esporádicas y poco frecuentes en las que el tráfico de solicitudes es impredecible y necesita una capacidad informática dinámica. Elimina la sobrecarga de mantenimiento del servidor y las empresas pagan solo por el tiempo de cómputo consumido. Cuando se utiliza para entornos de recuperación ante desastres, los costos de instalación son mínimos y se incurre en cargos solo cuando los eventos se enrutan a él.


Para obtener más información sobre la tecnología sin servidor, sus beneficios y casos de uso comunes, puede consultar el documento técnico publicado por CNCF Serverless Working Group.


Conclusión


Incluir DR y automatización como parte del diseño y desarrollo de la aplicación inicial ayudará a inyectar los patrones de diseño requeridos y las prácticas de DevOps para construir una aplicación nativa de la nube resistente, reduciendo el costo de las operaciones y brindando disponibilidad constante a la aplicación.


La ausencia de un plan de recuperación ante desastres puede generar pérdidas inesperadas de ingresos y problemas de cumplimiento, y también podría generar una pérdida de confianza en la base de clientes. Identificar el nivel de recuperación ante desastres adecuado, tomar buenas decisiones de arquitectura y utilizar herramientas de automatización independientes de la infraestructura pueden reducir el costo de mantener un entorno de recuperación ante desastres y, al mismo tiempo, brindar la capacidad de recuperación para recuperarse rápidamente en caso de un desastre.


Explore cómo las tecnologías de código abierto de Red Hat pueden ayudar en estas funciones críticas con una variedad de soluciones de automatización , administración de clústeres y aplicaciones en contenedores.


Fuente: Blog de Red Hat