Este documento es la última parte de una serie en la que se trata la recuperación ante desastres (DR) en Google Cloud. En esta parte, se ofrece una descripción general del proceso de planificación de DR: Qué necesitas saber para diseñar y, luego, implementar un plan de DR. En las siguientes partes, se analizan casos prácticos específicos de DR con ejemplos de implementaciones en Google Cloud.
La serie consta de las siguientes partes:
- Guía de planificación para la recuperación ante desastres (este documento)
- Componentes básicos de la recuperación ante desastres
- Situaciones de recuperación ante desastres para datos
- Situaciones de recuperación ante desastres para aplicaciones
- Arquitectura de recuperación ante desastres para cargas de trabajo con restricciones de localidad
- Casos de uso de recuperación ante desastres: aplicaciones de análisis de datos con restricciones de localidad
- Arquitectura de recuperación ante desastres para interrupciones de infraestructura de nube
Introducción
En cualquier momento, pueden producirse eventos que interrumpan el servicio. Tu red puede sufrir una interrupción, la última actualización de tu aplicación puede producir un error crítico o tal vez debas lidiar con un desastre natural. Cuando no todo sale como esperas, es importante contar con un plan de recuperación ante desastres sólido, orientado y probado.
Cuando tienes un plan de DR de estas características, puedes estar seguro de que, si sucede una catástrofe, el impacto en las ganancias de tu negocio será mínimo. No importa cuáles sean tus necesidades de DR, Google Cloud cuenta con una selección sólida, flexible y rentable de productos y funciones que puedes usar para crear o mejorar la solución más adecuada.
Conceptos básicos de la planificación de DR
La recuperación ante desastres es un subconjunto de la planificación de la continuidad empresarial. La planificación de recuperación ante desastres comienza con un análisis del impacto en el negocio que define dos métricas clave:
- Un objetivo de tiempo de recuperación (RTO), que es el período máximo aceptable en que la aplicación puede estar sin conexión. Por lo general, este valor se define como parte de un Acuerdo de Nivel de Servicio (ANS) más amplio.
- Un objetivo de punto de recuperación (RPO), que es el período máximo aceptable en el que se pueden perder datos de la aplicación debido a un incidente importante. Esta métrica varía según las formas en las que se utilizan los datos. Por ejemplo, los datos del usuario que se modifican con frecuencia podrían tener un RPO de solo algunos minutos. Por el contrario, los datos modificados con menos frecuencia y menos críticos podrían tener un RPO de varias horas. (Esta métrica solo describe el período, no indica la cantidad o la calidad de los datos que se pierden).
Por lo general, cuanto menores sean tus valores de RTO y RPO (es decir, cuanto más rápido tu aplicación deba recuperarse de una interrupción), mayor será el costo de ejecución de tu aplicación. En el siguiente gráfico, se muestra la relación del costo y el RTO/RPO.
Debido a que los valores de RTO y RPO menores implican una mayor complejidad, la sobrecarga administrativa asociada sigue una curva similar. Puede que una aplicación de alta disponibilidad requiera que administres la distribución entre dos centros de datos separados físicamente, que administres la replicación, etcétera.
En general, los valores de RTO y RPO se acumulan en otra métrica: el objetivo de nivel de servicio (SLO), que es un elemento medible clave de un ANS. Los ANS y SLO suelen combinarse. Un ANS es el acuerdo completo en el que se especifica qué servicio se proporcionará, cómo se brindará asistencia, así como los tiempos, las ubicaciones, los costos, el rendimiento, las penalizaciones y las responsabilidades de las partes involucradas. Los SLO son características medibles y específicas del ANS, como la disponibilidad, la capacidad de procesamiento, la frecuencia, el tiempo de respuesta o la calidad. Un ANS puede tener varios SLO. Los RTO y RPO son medibles y se deben considerar SLO.
Puedes leer más sobre los SLO y los ANS en el libro de ingeniería de confiabilidad de sitios de Google.
También puedes estar planificando una arquitectura para alta disponibilidad (HA). La HA no se superpone por completo con la recuperación ante desastres, pero suele ser necesario tener en cuenta la HA cuando piensas en los valores de RTO y RPO. La HA ayuda a asegurar un nivel de rendimiento operativo acordado, que suele ser el tiempo de actividad para un período mayor que el normal. Cuando ejecutas cargas de trabajo de producción en Google Cloud, puedes usar un sistema distribuido a nivel global para que, si ocurre algún error en una región, la aplicación continúe prestando servicio, incluso si se reduce su disponibilidad. En definitiva, la aplicación invoca su plan de DR.
¿Por qué elegir Google Cloud?
Google Cloud puede reducir de forma considerable los costos asociados con el RTO y RPO en comparación con el cumplimiento de los requisitos de ambos a nivel local. Por ejemplo, la planificación de DR tradicional requiere que consideres un número de requisitos, entre los que se incluyen los siguientes:
- Capacidad: Asegurar los recursos suficientes para escalar según sea necesario
- Seguridad: proporcionar seguridad física para proteger los activos.
- Infraestructura de red: incluir componentes de software, como firewalls y balanceadores de cargas.
- Asistencia: poner a disposición técnicos capacitados para que realicen mantenimiento y solucionen problemas.
- Ancho de banda: planificar un ancho de banda adecuado para la carga máxima.
- Instalaciones: Asegurar una infraestructura física, que incluya equipos y energía
Cuando proporcionas una solución altamente administrada en una plataforma de producción de primer nivel, Google Cloud te ayuda a evitar la mayoría de estos factores complicados, o todos, lo que reduce muchos costos empresariales. Además, el enfoque de Google Cloud en la simplicidad administrativa también permite reducir los costos de administrar una aplicación compleja.
Google Cloud ofrece varias funciones que son relevantes para la DR, incluidas las siguientes opciones:
- Una red global. Google tiene una de las redes informáticas más grandes y avanzadas del mundo. En la red troncal de Google, se usan herramientas de redes avanzadas definidas por software y servicios de almacenamiento en caché perimetral para brindar un rendimiento rápido, coherente y escalable.
- Redundancia. Los varios puntos de presencia (POP) en todo el mundo permiten una gran redundancia. Tus datos se duplican de forma automática en dispositivos de almacenamiento en varias ubicaciones.
- Escalabilidad. Google Cloud está diseñada para escalar como otros productos de Google (por ejemplo, el motor de búsqueda y Gmail), incluso cuando experimentas un gran aumento en el tráfico. Los servicios administrados, como App Engine, los escaladores automáticos de Compute Engine y Datastore ofrecen ajuste de escala automático que permite a la aplicación aumentar o reducir la escala según sea necesario.
- Seguridad. El modelo de seguridad de Google se creó a partir de más de 15 años de experiencia con el propósito de mantener a los clientes protegidos cuando usan las aplicaciones de Google, como Gmail y Google Workspace. Además, los equipos de ingeniería de confiabilidad de sitios de Google ayudan a asegurar una alta disponibilidad y evitar el abuso de los recursos de la plataforma.
- Cumplimiento. Google se somete a auditorías de terceros independientes periódicas para verificar que Google Cloud cumpla las normas y prácticas recomendadas de seguridad, privacidad y cumplimiento. Google Cloud cumple con certificaciones como ISO 27001, SOC 2/3 y PCI DSS 3.0.
Patrones de DR
Los patrones de recuperación ante desastres son fríos, tibios o calientes. Estos patrones indican qué tan fácilmente se puede recuperar el sistema cuando hay una falla. Esto puede compararse con lo que harías si estuvieras conduciendo y se pinchara un neumático de tu vehículo.
La forma en la que lidias con un neumático pinchado depende de qué tan preparado estés:
- Frío: no tienes tiempo libre, así que debes llamar a alguien para que te traiga un neumático nuevo y lo reemplace. Tu viaje se detendrá hasta que una persona llegue a hacer la reparación.
- Tibio: tienes un neumático de repuesto y un kit de reemplazo, por lo que puedes volver al camino gracias a lo que llevas en tu vehículo. Sin embargo, debes detenerte para reparar el problema.
- Caliente: tienes los neumáticos desinflados. Tal vez debas disminuir la velocidad, pero no hay un impacto inmediato en tu recorrido. Tus neumáticos funcionan lo suficientemente bien como para poder continuar (aunque puede que en algún momento debas solucionar el problema).
Crear un plan de recuperación ante desastres detallado
En esta sección, se ofrecen recomendaciones sobre cómo crear tu plan de recuperación ante desastres.
Diseña según tus objetivos de recuperación
Cuando diseñas tu plan de recuperación ante desastres, necesitas combinar las técnicas de recuperación de tus datos y tu aplicación, y observar el panorama más general. La manera más común de hacerlo es ver tus valores de RTO y RPO, y pensar en el patrón de recuperación ante desastres que puedes adoptar para llegar a esos valores. Por ejemplo, en el caso de datos históricos orientados al cumplimiento, es probable que no necesites un acceso rápido a ellos, por lo que un gran valor de RTO y un patrón de recuperación ante desastres frío son apropiados. Sin embargo, si tu servicio en línea sufre una interrupción, desearás recuperar tanto los datos como la parte de la aplicación orientada a los clientes tan rápido como sea posible. En ese caso, un patrón caliente sería más apropiado. El sistema de notificación por correo electrónico que, por lo general, no es crítico para el negocio, tal vez sea un candidato a un patrón tibio.
Si deseas obtener orientación sobre cómo usar Google Cloud para abordar situaciones comunes de DR, revisa las situaciones de recuperación de la aplicación. En estas situaciones, se proporcionan estrategias de DR orientadas a una variedad de casos prácticos y se ofrecen implementaciones de ejemplo en Google Cloud para cada una.
Diseña para la recuperación de extremo a extremo
Tener un plan para crear una copia de seguridad o archivar tus datos no es suficiente. Asegúrate de que tu plan de recuperación ante desastres aborde el proceso de recuperación completo, desde la creación de copias de seguridad hasta el restablecimiento y la limpieza. Esto se analiza en los documentos relacionados sobre los datos y la recuperación ante desastres.
Haz que tus tareas sean específicas
Cuando llegue el momento de ejecutar tu plan de recuperación ante desastres, no querrás detenerte a adivinar qué significa cada paso. Haz que cada tarea en tu plan de recuperación ante desastres consista de uno o más comandos o acciones concretos y claros. Por ejemplo, “Ejecutar la secuencia de comandos de restablecimiento” es muy general. En cambio, “Abrir Bash y ejecutar /home/example/restore.sh
” es preciso y concreto.
Implementa medidas de control
Agrega controles para prevenir desastres y detectar problemas antes de que ocurran. Por ejemplo, agrega un monitor que envíe una alerta cuando un flujo destructivo de datos, como una canalización de eliminación, presenta picos inesperados, o bien otra actividad inusual. Este monitor también podría cancelar los procesos de la canalización si se alcanza un cierto límite de eliminación, y así prevenir una situación catastrófica.
Preparar tu software
Como parte de la planificación de recuperación ante desastres, debes asegurarte de que el software que utilizas esté preparado para un evento de recuperación.
Verifica que puedes instalar tu software
Asegúrate de que el software de la aplicación se pueda instalar desde el origen o desde una imagen preconfigurada. Asegúrate de contar con la licencia adecuada para cualquier software que implementes en Google Cloud. Consulta con el proveedor del software si deseas obtener orientación.
Asegúrate de que los recursos necesarios de Compute Engine estén disponibles en el entorno de recuperación. Esto puede requerir la asignación previa de instancias o su reserva.
Diseña una implementación continua para la recuperación
Tu conjunto de herramientas de implementación continua (CD) es un componente fundamental para implementar tus aplicaciones. Como parte de tu plan de recuperación, debes considerar en qué lugar de tu entorno recuperado implementarás los artefactos. Planea dónde deseas alojar los artefactos y tu entorno de CD; deben estar disponibles y en funcionamiento en caso de que ocurra un desastre.
Implementar los controles de seguridad y cumplimiento
La seguridad es importante en el diseño de tu plan de recuperación ante desastres. Se deben aplicar los mismos controles que tienes en tu entorno de producción a tu entorno recuperado. También se aplicarán los reglamentos de cumplimiento.
Configura la seguridad para los entornos de producción y de recuperación ante desastres de igual manera
Asegúrate de que los controles de tu red proporcionen la misma separación y bloqueo que utiliza el entorno de producción de origen. Aprende a configurar la VPC compartida y los firewalls para establecer Herramientas de redes y control de seguridad centralizados de la implementación, configurar subredes, controlar el tráfico entrante y saliente, etcétera. Obtén información sobre cómo usar cuentas de servicio a fin de implementar privilegios mínimos para aplicaciones que acceden a las API de Google Cloud. Asegúrate de usar cuentas de servicio como parte de las reglas de firewall.
También, asegúrate de otorgar a los usuarios el mismo acceso al entorno de DR que tienen en el entorno de producción de origen. En la siguiente lista, se describen las maneras de sincronizar permisos entre entornos:
Si el entorno de producción es Google Cloud, replicar políticas de IAM en el entorno de DR es sencillo. Puedes usar herramientas de infraestructura como código (IaC), como Terraform para implementar tus políticas de IAM en la producción. Luego, usa las mismas herramientas para vincular las políticas a los recursos correspondientes en el entorno de DR como parte del proceso de preparación del entorno.
Si el entorno de producción es local, mapea las funciones de los roles, como el administrador de red y el auditor, a las políticas de IAM que tienen roles de IAM adecuados. La documentación de IAM tiene algunos ejemplos de configuración de funciones útiles. Consulta la documentación para crear funciones útiles de herramientas de redes y registros de auditoría.
Debes configurar las políticas de IAM para otorgar los permisos adecuados a los productos. Por ejemplo, tal vez quieras restringir el acceso a depósitos de Cloud Storage específicos.
Si el entorno de producción es otro proveedor de servicios en la nube, asigna los permisos de las políticas de IAM del otro proveedor a las políticas de Google Cloud IAM.
Verifica la seguridad de DR
Luego de configurar los permisos para el entorno de recuperación ante desastres, asegúrate de probar todo. Crea un entorno de prueba. Usa herramientas de IaC como Terraform para implementar las políticas de Google Cloud en el entorno de prueba. Verifica que los permisos que otorgas a los usuarios coincidan con los permisos que tienen los usuarios de forma local.
Asegúrate de que los usuarios puedan acceder al entorno de DR
No esperes a que ocurra un desastre antes de verificar que tus usuarios puedan acceder al entorno de recuperación ante desastres. Asegúrate de haberles otorgado los derechos de acceso adecuados a los usuarios, desarrolladores, operadores, científicos de datos, administradores de seguridad, administradores de red y cualquier otra función en tu organización. Si utilizas un sistema de identidades alternativo, asegúrate de que las cuentas se hayan sincronizado con tu cuenta de Cloud Identity. Debido a que el entorno de recuperación ante desastres será tu entorno de producción por un tiempo, haz que los usuarios que necesiten acceder al entorno de recuperación antes desastres puedan hacerlo y resuelve cualquier problema de autenticación. Incorpora a los usuarios que acceden al entorno de DR como parte de las pruebas de DR frecuentes que implementes.
Para administrar de forma centralizada quién tiene acceso SSH a las máquinas virtuales (VM) que se inician, habilita la función de Acceso al SO en los proyectos de Google Cloud que constituyen el entorno de DR.
Capacita a los usuarios
Los usuarios deben comprender cómo llevar a cabo las acciones en Google Cloud que están acostumbrados a desarrollar en el entorno de producción, como acceder, acceder a la VM, etcétera. Mediante el entorno de prueba, enseña a los usuarios a realizar estas tareas de modo tal que se proteja la seguridad del sistema.
Asegúrate de que el entorno de DR satisfaga los requisitos de cumplimiento
Verifica que el acceso a tu entorno de recuperación ante desastres esté restringido solo a aquellos que lo necesiten. Asegúrate de que los datos de PII estén ocultos y encriptados. Si realizas pruebas de penetración frecuentes en tu entorno de producción, debes incluir tu entorno de recuperación ante desastres como parte de ese alcance y realizar pruebas frecuentes mediante la preparación de un entorno de recuperación ante desastres.
Asegúrate de que mientras tu entorno de DR esté en servicio, cualquier registro que recopiles se reabastezca en el archivo de registros de tu entorno de producción. Del mismo modo, asegúrate de que, como parte del entorno de DR, puedas exportar los registros de auditoría que se recopilan mediante Cloud Logging al archivo receptor de registros principal. Usa los servicios del receptor de exportación. Para los registros de aplicaciones, duplica tu entorno de supervisión y registros locales. Si el entorno de producción es otro proveedor de servicios en la nube, asigna el registro y la supervisión de ese proveedor a los servicios de Google Cloud equivalentes. Usa un proceso para dar formato a los datos de entrada en tu entorno de producción.
Usa Cloud Storage como parte de tus rutinas de copias de seguridad diarias
Utiliza Cloud Storage para almacenar copias de seguridad. Asegúrate de que los depósitos que contienen tus copias de seguridad tengan aplicados los permisos adecuados.
Administra secretos de forma adecuada
Administra claves y secretos a nivel de la aplicación mediante Google Cloud para alojar el servicio de administración de claves y secretos (KMS). Puedes usar Cloud KMS o una solución de terceros, como HashiCorp Vault, con un backend de Google Cloud, como Spanner o Cloud Storage.
Trata los datos recuperados como si fueran datos de producción
Asegúrate de que los controles de seguridad que aplicas a tus datos de producción también se apliquen a tus datos recuperados: se deben aplicar los mismos permisos y requisitos de auditoría, y la misma encriptación.
Aprende dónde están ubicadas tus copias de seguridad y quién está autorizado a restablecer los datos. Comprueba que tu proceso de recuperación sea auditable: luego de una recuperación ante desastres, asegúrate de que puedes mostrar quién tenía acceso a los datos de las copias de seguridad y quién realizó la recuperación.
Asegúrate de que tu plan de DR funcione
Asegúrate de que, si ocurre un desastre, tu plan de DR funcione según lo previsto.
Mantén más de una ruta de acceso de recuperación de datos
En caso de un desastre, es posible que el método de conexión a Google Cloud deje de estar disponible. Implementa un método alternativo de acceso a Google Cloud para asegurarte de que puedas transferir datos a este. Prueba de forma periódica que la ruta de acceso a la copia de seguridad esté operativa.
Prueba tu plan con regularidad
Luego de crear un plan de recuperación ante desastres, pruébalo con frecuencia; ten en cuenta cualquier problema que surja y ajusta tu plan según sea necesario. Mediante Google Cloud, puedes probar situaciones de recuperación a un costo mínimo. Te recomendamos que implementes lo siguiente para ayudarte con las pruebas:
- Automatiza el aprovisionamiento de infraestructura. Puedes usar herramientas de IaC como Terraform para automatizar el aprovisionamiento de instancias de VM y otra infraestructura de Google Cloud. Si ejecutas el entorno de producción local, asegúrate de tener un proceso de supervisión que pueda iniciar el proceso de DR cuando detecte una falla y pueda activar las acciones de recuperación adecuadas.
- Supervisa y depura las pruebas mediante Cloud Logging y Cloud Monitoring. Google Cloud cuenta con excelentes herramientas de registro y supervisión a las que puedes acceder a través de llamadas a la API, lo que te permite automatizar la implementación de situaciones de recuperación mediante la reacción a métricas. Cuando diseñes pruebas, asegúrate de que cuentas con supervisión y alertas adecuadas que puedan activar las acciones de recuperación necesarias.
Realiza las pruebas que se mencionaron antes:
- Prueba que los permisos y el acceso del usuario funcionen en el entorno de DR como lo hacen en el entorno de producción.
- Realiza pruebas de penetración en tu entorno de DR.
- Realiza una prueba en la que la ruta de acceso habitual a Google Cloud no funcione.
Próximos pasos
- Consulta Geografía y regiones de Google Cloud.
- Lee otros artículos de esta serie sobre la DR:
- Componentes básicos de la recuperación ante desastres
- Situaciones de recuperación ante desastres para datos
- Situaciones de recuperación ante desastres para aplicaciones
- Arquitectura de recuperación ante desastres para cargas de trabajo con restricciones de localidad
- Casos de uso de recuperación ante desastres: aplicaciones de análisis de datos con restricciones de localidad
- Arquitectura de recuperación ante desastres para interrupciones de infraestructura de nube
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.