Visión general de la alta disponibilidad y la recuperación tras desastre para Code Engine

La alta disponibilidadCapacidad de un servicio o carga de trabajo para soportar fallos y seguir proporcionando capacidad de procesamiento de acuerdo con algún nivel de servicio predefinido. (HA) es la capacidad de un servicio de permanecer operativo y accesible a pesar de fallos inesperados. La recuperación en caso de catástrofeCapacidad de un servicio o carga de trabajo para recuperarse de incidentes graves poco frecuentes y fallos a gran escala, como la interrupción del servicio. Esto incluye un desastre físico que afecte a toda una región, la corrupción de una base de datos o la pérdida de un servicio que contribuya a una carga de trabajo. El impacto supera la capacidad del diseño de alta disponibilidad para gestionarlo. es el proceso de restablecimiento de las operaciones de servicio tras una interrupción grave.

Code Engine es un servicio regional de alta disponibilidad diseñado para mantener la disponibilidad durante las interrupciones zonales. Code Engine cumple los Objetivos de Nivel de Servicio(SLO ) con el plan Estándar.

Para obtener más información sobre los estándares de alta disponibilidad y recuperación ante desastres en IBM Cloud, consulta el artículo « Cómo garantiza IBM Cloud la alta disponibilidad y la redundancia ». También puede encontrar información sobre Acuerdos de nivel de servicio.

Disponibilidad de las instancias de Code Engine

IBM Cloud® Code Engine se ofrece en varios lugares (regiones). Cada región contiene tres centros de datos (zonas) por redundancia.

Cuando se proporciona un proyecto de Code Engine, se selecciona la ubicación (MZR) en la que se crea la instancia. La región determina dónde se alojan tus cargas de trabajo, como aplicaciones, tareas, funciones y flotas.

De forma predeterminada, tu carga de trabajo se implementa en una sola zona. Si la zona de alojamiento falla, la carga de trabajo se vuelve a crear automáticamente en una de las zonas restantes.

El servicio realiza movimientos controlados de la carga de trabajo entre zonas durante las operaciones normales, como el mantenimiento del servicio y las actualizaciones de software. Estos reinicios de despliegue se realizan con elegancia para minimizar las interrupciones. Las conmutaciones por error no planificadas pueden producirse durante eventos inesperados en el entorno operativo.

Code Engine almacena metadatos (incluidas las definiciones de proyecto, aplicación, función, trabajo, flota y creación de imágenes) y los replica en todas las zonas de una región para garantizar su disponibilidad. Como servicio exclusivamente informático, Code Engine no es responsable de garantizar la alta disponibilidad de los datos de su carga de trabajo ni de las imágenes de contenedor. Consulte la documentación de los respectivos servicios en la nube para obtener orientación sobre cómo garantizar una alta disponibilidad. Para la disponibilidad de la imagen del contenedor, siga la guía en IBM Cloud Container Registry para garantizar que su carga de trabajo siga operativa durante una interrupción zonal. Si lee o almacena datos en IBM Cloud Object Storage o en cualquier otro servicio de almacenamiento o base de datos de IBM Cloud, consulte la documentación de cada servicio para conocer las funciones de alta disponibilidad.

Code Engine topología regional topología regional topología regional — Code Engine

Regiones de Code Engine

La siguiente tabla enumera las regiones en las que Code Engine está disponible y su estado de alta disponibilidad.

Regiones de alta disponibilidad Code Engine
Área geográfica	Región	Alta disponibilidad
Asia Pacífico	Australia, Sídney (`au-syd`)	MZR
Asia Pacífico	India, Chennai (`in-che`)	MZR
Asia Pacífico	Japón, Osaka (`jp-osa`)	MZR
Asia Pacífico	Japón, Tokio (`jp-tok`)	MZR
Europa	Alemania, Fráncfort (`eu-de`)	MZR
Europa	España, Madrid (`eu-es`)	MZR
Europa	Reino Unido, Londres (`eu-gb`)	MZR
América del Norte	Canadá, Toronto (`ca-tor`)	MZR
América del Norte	EE. UU., Dallas (`us-south`)	MZR
América del Norte	EE. UU., Washington (`us-east`)	MZR
América del Sur	Brasil, São Paulo (`br-sao`)	MZR

Una geografía es un área geográfica que comprende una o más regiones. Cada región cuenta con varias zonas de disponibilidad para satisfacer los requisitos locales de acceso, baja latencia y seguridad. Cada región multizona(MZR) se compone de 3 o más zonas independientes, lo que garantiza que los fallos sólo afecten a una zona.

Recuperación tras desastre para instancias de Code Engine

En caso de catástrofe regional de gran envergadura —como un terremoto, una inundación o un fenómeno meteorológico extremo—, toda una región puede verse afectada. Para garantizar que tus cargas de trabajo sean resistentes ante este tipo de incidentes, impleméntalas en varias MZR e implementa un mecanismo de conmutación automática por error mediante un servicio de proxy perimetral. Por ejemplo, puede utilizar IBM Cloud® Internet Services. Para obtener más información sobre el despliegue de una aplicación entre varias regiones, consulte Despliegue de una aplicación en varias regiones con un nombre de dominio personalizado.

Code Engine topología global topología global topología global — Code Engine

Cómo ayuda IBM a garantizar la recuperación en caso de catástrofe

Copia de seguridad de las instancias de Code Engine

IBM Cloud realiza copias de seguridad automáticas de los metadatos de los proyectos de Code Engine y los guarda en un almacenamiento interregional con fines de recuperación en caso de catástrofe.

Criterios de valoración interregionales
Región de Code Engine	Punto final entre regiones
`au-syd`	`AP`
`br-sao`	`BR`
`ca-tor`	`CA`
`eu-de`	`EU`
`eu-es`	`EU`
`eu-gb`	`EU`
`jp-osa`	`AP`
`jp-tok`	`AP`
`us-east`	`US`
`us-south`	`US`

Para evitar impactos no deseados en sus cargas de trabajo - como la duplicación de trabajos o el despliegue de instancias de aplicaciones no deseadas - Code Engine no restaura automáticamente sus cargas de trabajo. Restaurar sus cargas de trabajo es su responsabilidad. Para obtener más información, consulte Descripción de las responsabilidades del cliente al utilizar Code Engine.

Objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO)

El Objetivo de Tiempo de Recuperación (RTO) es el tiempo máximo aceptable que un sistema, aplicación o proceso de negocio puede estar fuera de línea antes de causar un impacto significativo en el negocio.
El objetivo de punto de recuperación (RPO) define la cantidad máxima aceptable de pérdida de datos (medida en tiempo) tras un evento de HA o DR.

IBM realiza pruebas periódicas de HA/DR que incluyen la conmutación por error de HA, escenarios aislados de DR (excluidas las definiciones de carga de trabajo y datos propiedad del cliente), restauración de datos y simulación de parámetros no técnicos.

Durante estas pruebas se miden y verifican los objetivos de RTO (tiempo de recuperación) y RPO (punto de recuperación).

Objetivos RTO/RPO
Objetivo	Destino
Conmutación automática en caso de interrupción de la zona	RTO = segundos, RPO = 0
Recuperación en caso de catástrofe, excluida la recuperación de artefactos propiedad del cliente	RTO = horas, RPO = 1 día

Planificación de la recuperación tras desastre

Además de las pruebas de HA/DR de IBM, debe poner en práctica sus procedimientos de recuperación en caso de catástrofe con regularidad. Cuando elabore su plan, tenga en cuenta los siguientes escenarios de fracaso y resoluciones.

Eventos de HA/DR y resolución
Suceso	Resolución
Fallo de hardware (infraestructura informática)	IBM proporciona una infraestructura resistente a fallos de hardware puntuales dentro de una zona, sin necesidad de configuración.
error de zona	Conmutación automática por error (véase Disponibilidad de las instancias Code Engine ). La carga de trabajo se desplaza automáticamente a una zona disponible.
Corrupción de datos	Usted es responsable de crear copias de seguridad de sus datos.
Fracaso regional	No hay conmutación automática. Como se describe en Recuperación ante desastres para instancias de Code Engine, debe desplegar su carga de trabajo en una segunda región multizona.
Disponibilidad de la carga de trabajo	Usted es responsable de implementar sus aplicaciones de negocio para recuperar el estado de almacenamiento externo o bases de datos.
Resistencia HA/DR	Usted es responsable de garantizar la disponibilidad de personal formado para gestionar sus componentes y restaurar sus cargas de trabajo y los datos propiedad del cliente durante una interrupción.

Sus responsabilidades en HA y DR

Utilice las siguientes listas de comprobación asociadas a cada característica para ayudarle a crear y poner en práctica su plan.

Imágenes de contenedores utilizadas para aplicaciones, trabajos y flotas de IBM Cloud® Code Engine

Compruebe que las imágenes de su contenedor están disponibles en su región de copia de seguridad IBM Cloud Container Registry.
Paquetes de códigos utilizados para las funciones de IBM Cloud® Code Engine

Compruebe que sus paquetes de códigos están disponibles en su región de copia de seguridad IBM Cloud Container Registry.

Un plan completo de pruebas de alta disponibilidad (HA) y recuperación ante desastres (DR) incluye la definición de los objetivos de RTO y RPO, la identificación de los sistemas críticos y la validación de la integridad de las copias de seguridad, la conmutación por error de la red y la sincronización de datos. Los pasos clave consisten en simular fallos (como el fallo de un nodo o la interrupción de un sitio), ejecutar procedimientos de conmutación por error, verificar la funcionalidad del sistema y documentar el proceso de conmutación por error.

Preparación de exámenes
- Defina los objetivos: Confirme su objetivo de tiempo de recuperación (RTO) y su objetivo de punto de recuperación (RPO).
- Identifique los sistemas críticos: Enumere todos los sistemas, datos y aplicaciones que requieren conmutación por error.
- Establezca las funciones del equipo: Defina las responsabilidades del equipo de RD y asigne una persona de contacto clave.
- Verificación de copias de seguridad: Confirme que las copias de seguridad son válidas y accesibles.
- Aislamiento del entorno: Aislar los sistemas de prueba para evitar un impacto accidental en los entornos de producción.
Ejecución de pruebas
- Simular escenario de fallo: Inicie un fallo planificado, como cortar la conectividad de red, detener un servicio o apagar un servidor primario.
- Ejecución de la conmutación por error: Ejecute el procedimiento documentado de conmutación por error al sitio secundario/DR.
- Verificar la integridad de los datos: Utiliza sumas de comprobación o valores hash para asegurarte de que los datos no están corruptos.
- Validación de aplicaciones: Pruebe la funcionalidad de las aplicaciones en el sitio DR.
- Redireccionamiento de DNS/tráfico: Validar que el tráfico de usuario se redirige al nuevo nodo activo.
Prueba posterior y documentación
- Realizar failback: Ponga de nuevo en línea el sitio primario y vuelva a sincronizar los datos.
- Documente los resultados: Registre los tiempos, los éxitos y cualquier desviación del plan.
- Identificar lagunas: Identifique las deficiencias del plan y actualice los procedimientos en consecuencia.
- Auditoría de comunicación: Verificar que se enviaron notificaciones a todas las partes interesadas.
Escenarios de prueba habituales
- Prueba de HA: Conmutación local por error a un nodo en espera (por ejemplo, dentro del mismo centro de datos).
- Prueba DR: Conmutación por error completa a una ubicación geográficamente separada.
- Restauración de datos: Restauración completa de datos propiedad del cliente y artefactos de carga de trabajo desde un almacén de datos de copia de seguridad a la ubicación de copia de seguridad primaria o seleccionada.
- Disponibilidad del personal: Compruebe el impacto operativo si el personal clave no está disponible o no puede conectarse a sus sistemas.