Visión general de la alta disponibilidad y la recuperación tras desastre para IBM Cloud Metrics Routing

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. En el caso de los servicios, la disponibilidad se define en el Acuerdo de Nivel de Servicio. La disponibilidad incluye tanto los eventos planificados como los no planificados, como el mantenimiento, los fallos y las catástrofes. (HA) es la capacidad de un servicio para seguir operativo y accesible en presencia de fallos inesperados. La recuperación ante desastresCapacidad 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 recuperar la instancia de servicio a un estado de funcionamiento.

IBM Cloud® Metrics Routing es un servicio de plataforma multiarrendatario de alta disponibilidad.

Puede encontrar las ubicaciones de las regiones y los centros de datos compatibles en la documentación de Ubicaciones. IBM Cloud Metrics Routing, como servicio regional, cumple los objetivos de nivel de servicio(SLO ) definidos. El SLO no es una garantía e IBM no concederá créditos por no cumplir un objetivo.

Arquitectura de alta disponibilidad

IBM Cloud® Databases for PostgreSQL controla la distribución de solicitudes entre los miembros de Postgres, lo cual se describe en Alta disponibilidad para PostgreSQL

IBM Cloud Metrics Routing está disponible en varias regiones. Para obtener más información sobre las regiones donde IBM Cloud Metrics Routing está disponible, consulte Regiones.

Cada región tiene tres centros de datos diferentes para la redundancia configurada en modalidad active/active.
Si fallan todos los centros de datos de una ubicación, IBM Cloud Metrics Routing deja de estar disponible en dicha ubicación.
En cada región soportada, la carga de tráfico se equilibra a través de la infraestructura en múltiples zonas de disponibilidad, sin un único punto de fallo.

Para obtener más información sobre la disponibilidad del servicio, consulte Acuerdos de nivel de servicio (SLA).

En la tabla siguiente se muestra el estado de alta disponibilidad (HA) de las regiones (ubicaciones) en las que el servicio IBM Cloud Metrics Routing está disponible:

Lista de lugares donde el servicio está disponible.
Área geográfica	Región	Soporte en la UE	Estado de HA
Asia Pacífico	Osaka (`jp-osa`)	No aplicable	`MZR`
Asia Pacífico	Sídney (`au-syd`)	No aplicable	`MZR`
Asia Pacífico	Tokio (`jp-tok`)	No aplicable	`MZR`
Europa	Frankfurt (`eu-de`)	Sí	`MZR`
Europa	Londres (`eu-gb`)	No aplicable	`MZR`
Europa	Madrid ( `eu-es` )	Sí	`MZR`
América del Norte	Dallas (`us-south`)	No aplicable	`MZR`
América del Norte	Toronto (`ca-tor`)	No aplicable	`MZR`
América del Norte	Washington DC (`us-east`)	No aplicable	`MZR`
América del Sur	Sao Paulo (`br-sao`)	No aplicable	`MZR`

Donde

Un zona geográfica es una área geográfica o una organización política más amplia que contiene una o más regiones.
Una región es un territorio geográfico definido.

Una región puede ser un área de código postal específica, un pueblo, una ciudad, un estado o grupo de estados o incluso un grupo de países.

Una región contiene varias zonas de disponibilidad para cumplir los requisitos de acceso local, baja latencia y seguridad de la región.
N/A significa que la característica no se aplica a esta geografía.
MZR significa región multizona. Más información.

Funciones de alta disponibilidad

IBM Cloud Metrics Routing admite las siguientes funciones de alta disponibilidad:

Características de HA para IBM Cloud Metrics Routing
Característica	Descripción
Despliegue regional multizona	IBM Cloud Metrics Routing se despliega en regiones multizona (MZR) y, dentro de una MZR, el plano de datos abarca las tres zonas, lo que garantiza que la pérdida de una zona no afecte a la disponibilidad del servicio.
Réplica métrica de plataforma en todas las zonas	Las métricas introducidas en IBM Cloud Metrics Routing se replican en tres zonas dentro de los MZR
Supervisión de la vida / disponibilidad	Todos los microservicios se supervisan mediante sondas de actividad y disponibilidad de l Kubernetes.

Arquitectura de recuperación ante desastres

IBM Cloud® Databases for PostgreSQL controla la distribución de solicitudes entre los miembros de Postgres, lo cual se describe en Alta disponibilidad para PostgreSQL

IBM Cloud Object Storage gestiona los geo buckets utilizados para almacenar las copias de seguridad de Postgres para IBM Cloud Metrics Routing. La gestión de los depósitos de geolocalización se describe en Alta disponibilidad para IBM Cloud Object Storage

Fallo de zona única

IBM Cloud Metrics Routing es HA y puede seguir funcionando a través de cualquier fallo de zona o máquina.

Fallo regional

IBM Cloud Metrics Routing es un servicio de plataforma. No existe una conmutación por error interregional automática ni una recuperación ante desastres interregional. Si fallan todas las zonas de disponibilidad de una región, IBM Cloud Metrics Routing deja de estar disponible en esa región.

Funciones de recuperación ante desastres

IBM Cloud Metrics Routing admite las siguientes funciones de recuperación ante desastres:

Características de DR para IBM Cloud Metrics Routing
Característica	Descripción	Consideración
Múltiples destinos configurables	Aquí se pueden encontrar detalles para que los clientes creen configuraciones resistentes a desastres utilizando IBM Cloud Metrics Routing	La configuración debe ser implementada por el cliente.
Réplica de solo lectura entre sitios para los metadatos del cliente	Las configuraciones de rutas y objetivos de clientes dentro de IBM Cloud Metrics Routing se mantienen en una instancia de base de datos regional, así como en una réplica de solo lectura en la región de recuperación. La réplica puede utilizarse en caso de desastre regional para restaurar los metadatos de la región	Para obtener más información, consulte Alta disponibilidad para PostgreSQL
Copia de seguridad de la base de datos entre sitios para los metadatos del cliente	Las configuraciones de rutas y objetivos de clientes dentro de IBM Cloud Metrics Routing se mantienen en un bucket de recuperación geográfica ( IBM Cloud Object Storage ) interregional. Esta copia de seguridad puede utilizarse en caso de desastre regional para restaurar los metadatos de la región	Para más información, consulte IBM Cloud Object Storage puntos de conexión entre regiones

Planificación para RD

Los pasos de la DR deben practicarse con regularidad. A medida que construye su plan, tenga en cuenta los siguientes escenarios de fallos y resoluciones.

Escenarios de RD para IBM Cloud Metrics Routing
Anomalía	Resolución
Fallo de hardware (punto único)	No se requiere configuración.
error de zona	No se requiere configuración.
Corrupción de metadatos	En caso de corrupción de metadatos, el servicio IBM Cloud Metrics Routing intentará primero restaurarlos utilizando una copia de seguridad puntual de la base de datos regional. Si la base de datos ya no está disponible en la región, la réplica interregional se promocionará como la principal. Si la réplica interregional no está disponible, la base de datos se restaurará desde la copia de seguridad interregional de IBM Cloud Object Storage
Fallo regional	Siga los pasos indicados en Sus responsabilidades en HA y DR.

Sus responsabilidades en HA y DR

La recuperación ante desastres consiste en sobrevivir a un fallo catastrófico o a la pérdida de disponibilidad en una ubicación.

IBM Cloud Metrics Routing es un servicio de plataforma, no hay conmutación por error automática entre regiones ni recuperación de desastres entre regiones. Si fallan todas las zonas de disponibilidad de una región, IBM Cloud Metrics Routing deja de estar disponible en esa región.

Puede crear una configuración para enrutar a un destino de copia de seguridad en una región diferente.

En el caso de un desastre regional, debe completar los pasos siguientes para establecer la alta disponibilidad entre regiones:

Decida qué ubicación va a ser su región de recuperación. Elija 1 de las opciones siguientes:
- Compruebe la región de recuperación de DR sugerida y utilice esa región como su región de recuperación.
- Si ha configurado los ajustes de la cuenta IBM Cloud Metrics Routing con una ubicación principal y una ubicación secundaria de respaldo, compruebe si alguna de las dos sigue operativa y utilice la que siga operativa como región de recuperación.
- Si ha configurado los ajustes de la cuenta IBM Cloud Metrics Routing con una ubicación principal solamente, y esta ubicación no está disponible, compruebe las regiones admitidas por IBM Cloud Metrics Routing y elija una región activa como su región de recuperación.
Solo puede definir objetivos en regiones admitidas por IBM Cloud Metrics Routing. Sin embargo, el objetivo real puede estar disponible en una región diferente y seguir operativo. En primer lugar, debe comprobar la disponibilidad del destinatario. A continuación, elija una de las siguientes opciones:
- Si un destino está disponible en una región diferente a la que está inactiva, y la región de recuperación que eliges está configurada en los ajustes de la cuenta IBM Cloud Metrics Routing, la ubicación principal y la ubicación secundaria de respaldo incluyen detalles de tu destino. Puede seguir comprobando las rutas que están definidas en la cuenta para asegurarse de que las métricas de la plataforma se dirigen al objetivo.
- Si un destino está disponible en una región diferente a la que está inactiva, y la región de recuperación que eliges no es una región configurada en los ajustes de la cuenta de IBM Cloud Metrics Routing, debes configurar el destino en cualquier región compatible con IBM Cloud Metrics Routing que esté disponible, preferiblemente, la región que elijas como tu región de recuperación. A continuación, debe comprobar las rutas que están definidas en la cuenta para que las métricas de la plataforma se dirijan al nuevo destino que ha configurado.
- Si el destino no está disponible, debe pasar por el proceso de recuperación de DR de ese tipo de destino y proporcionar uno nuevo en la región de recuperación que elija. Debe configurar el destino en cualquier región compatible con IBM Cloud Metrics Routing que esté disponible, preferiblemente, la región que elija como su región de recuperación. A continuación, debe comprobar las rutas que están definidas en la cuenta para que las métricas de la plataforma se dirijan al nuevo destino que ha configurado.
Usted define las rutas para indicar cómo se dirigen las métricas de la plataforma a los objetivos que ha configurado en la cuenta. Estas rutas son globales y no están vinculadas a una región específica. Por lo tanto, en el caso de un escenario de DR, debe comprobar que todos los objetivos que están configurados son operativos y que las reglas se aplican a objetivos y ubicaciones operativos.

Cuando se recupera IBM Cloud Metrics Routing en la región que está inactiva, se restaura la configuración. Complete los siguientes pasos para continuar operando en la región que se cayó:

Debe comprobar que todos los objetivos existentes en esa región también se han recuperado y están operativos.
Si ha configurado nuevos objetivos, puede actualizar su configuración para volver a utilizar los objetivos que se han caído. También puede decidir seguir utilizando los destinos que habilitó en la región de recuperación.

Para obtener más información sobre la responsabilidad compartida entre usted y IBM Cloud por el uso de IBM Cloud Metrics Routing, consulte Responsabilidades compartidas para IBM Cloud Metrics Routing.

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

IBM Cloud dispone de planes de continuidad de la actividadCapacidad de una empresa para soportar paradas y para operar con servicios críticos de forma normal y sin interrupciones de acuerdo con los acuerdos de nivel de servicio predefinidos. que permiten recuperar los servicios en cuestión de horas en caso de catástrofe. El cliente es el responsable de la copia de seguridad de datos y de la recuperación asociada de su contenido.

IBM Cloud Metrics Routing proporciona mecanismos para proteger sus datos y restablecer las funciones del servicio. Existen planes de continuidad de la actividad para alcanzar el objetivo de punto de recuperaciónEn la planificación de la recuperación de desastres, el momento en el que se restauran los datos medido en tiempo (segundos, minutos, horas) empezando en la instancia recuperada y terminando en el punto del desastre. (RPO) y el objetivo de tiempo de recuperaciónEn la planificación de la recuperación en caso de catástrofe, el tiempo que tarda en restablecerse un proceso empresarial tras una catástrofe. (RTO) previstos para el servicio. El siguiente cuadro presenta los objetivos de IBM Cloud Metrics Routing.

RPO y RTO para IBM Cloud Metrics Routing
Objetivo de recuperación para DR	Tiempo estimado
Tiempo de inactividad máximo tolerable (MTD) / Objetivo de tiempo de recuperación (RTO)	Menos de 24 horas
Objetivo de punto de recuperación (RPO)	Menos de 24 horas

Gestión de cambios

La gestión de cambios incluye tareas como actualizaciones, cambios de configuración y eliminaciones.

Se recomienda que conceda a los usuarios y procesos los roles y acciones de IAM con el mínimo privilegio requerido para su trabajo. Véase ¿Cómo puedo evitar la eliminación accidental de servicios?

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

IBM® realiza pruebas anuales de varios escenarios de desastre y perfecciona continuamente nuestra documentación de recuperación en función de los hallazgos que se encuentran durante estas pruebas.
los clientes con un IBM®, cuentan con asistencia global las 24 horas del día, los 7 días de la semana, a través de expertos en la materia que están disponibles para ayudar en caso de desastre.

Todos los expertos en la materia de IBM® reciben formación anual sobre políticas y procedimientos de continuidad del negocio y recuperación ante desastres para garantizar la preparación en caso de desastre.

Los metadatos que gestiona IBM Cloud Metrics Routing en una región se guardan en los centros de datos cercanos a esa región.

Una región multizona (MZR) consta de 3 o más zonas de disponibilidad que son independientes entre sí para garantizar que las métricas de un único fallo sólo afecten a una única zona.

De forma predeterminada, IBM Cloud Metrics Routing se implementa en 3 zonas. Cada zona está configurada con un active/active/active :

Cada zona se encuentra en un centro de datos diferente en la región.
Las métricas de la plataforma en cada zona se replican automáticamente en las otras zonas con baja latencia. No es necesario que haga nada para habilitar la réplica.
El servicio está diseñado para soportar el fallo de una sola zona interrumpirse.

La arquitectura MZR ofrece conmutación por error automática entre zonas dentro de la región y alta disponibilidad para una instancia dentro de una región.

IBM Cloud Metrics Routing los metadatos incluyen información sobre dónde y cómo recopilar y almacenar métricas en su cuenta.

Un objetivo define un recurso en el que se pueden recopilar métricas.
Una ruta define las reglas que determinan hacia dónde se dirigen las métricas en su cuenta o cuenta cruzada.

IBM Cloud Metrics Routing realiza copias de seguridad periódicas de los metadatos por región:

Las ubicaciones de metadatos de configuración indican la región donde se realiza la copia de seguridad de los metadatos.
Se realizan copias de seguridad periódicas a diario.
IBM Cloud Metrics Routing los metadatos se replican en todas las regiones en función de la configuración de su cuenta para las ubicaciones de metadatos principales y de respaldo.

IBM Cloud Metrics Routing los metadatos se replican en varias regiones.

Las copias de seguridad frecuentes se almacenan en varias regiones y se pueden restaurar a otras regiones.

La tabla siguiente muestra las regiones en las que se replica y está disponible la copia de una copia de seguridad frecuente:

Lista de ubicaciones en las que está disponible una copia de seguridad
Área geográfica	Región	Otras regiones que conservan una copia de la copia de seguridad
Asia Pacífico	Osaka (`jp-osa`)	Tokio (`jp-tok`)
Asia Pacífico	Sídney (`au-syd`)	Londres (`eu-gb`)
Asia Pacífico	Tokio (`jp-tok`)	Osaka (`jp-osa`)
Europa	Frankfurt (`eu-de`)	Madrid ( `eu-es` )
Europa	Londres (`eu-gb`)	Sídney (`au-syd`)
Europa	Madrid ( `eu-es` )	Frankfurt (`eu-de`)
América del Norte	Dallas (`us-south`)	Washington (`us-east`)
América del Norte	Toronto (`ca-tor`)	Washington (`us-east`)
América del Norte	Washington (`us-east`)	Dallas (`us-south`)
América del Sur	Sao Paulo (`br-sao`)	Washington (`us-east`)

Para obtener más información sobre la disponibilidad de servicios en regiones y centros de datos, consulte Disponibilidad de servicio e infraestructura por ubicación.

La tabla siguiente indica la región de recuperación en el caso de una situación de DR:

Lista de ubicaciones donde se recupera una región
Área geográfica	Región de origen	Región de recuperación
Asia Pacífico	Osaka (`jp-osa`)	Tokio (`jp-tok`)
Asia Pacífico	Sídney (`au-syd`)	Frankfurt (`eu-de`)
Asia Pacífico	Tokio (`jp-tok`)	Osaka (`jp-osa`)
Europa	Frankfurt (`eu-de`)	Madrid ( `eu-es` )
Europa	Londres (`eu-gb`)	Frankfurt (`eu-de`)
Europa	Madrid ( `eu-es` )	Frankfurt (`eu-de`)
América del Norte	Dallas (`us-south`)	Washington (`us-east`)
América del Norte	Toronto (`ca-tor`)	Washington (`us-east`)
América del Norte	Washington DC (`us-east`)	Dallas (`us-south`)
América del Sur	Sao Paulo (`br-sao`)	Washington (`us-east`)

Cómo se recupera IBM de los fallos de zona

En caso de fallo de zona, IBM Cloud resolverá el corte de zona. Dado que el servicio abarca las tres zonas de una región, no habrá ningún impacto en la disponibilidad del servicio dentro de una MZR. Tras la recuperación de la zona, se reanudará el envío de eventos y solicitudes de API a la zona restaurada. No será necesario que el cliente realice ninguna acción en este momento.

Cómo se recupera IBM de los fallos regionales

Cuando se recupera IBM Cloud Metrics Routing en la región que está inactiva, se restaura la configuración. Complete los siguientes pasos para continuar operando en la región que se cayó:

Debe comprobar que todos los objetivos existentes en esa región también se recuperan y están operativos confirmando que las métricas de la plataforma se enrutan a los destinos objetivo configurados.
Si ha configurado nuevos objetivos, puede actualizar su configuración para volver a utilizar los objetivos que se han caído. También puede decidir seguir utilizando los destinos que habilitó en la región de recuperación.

Si el cliente sigue estos pasos y la configuración de recuperación ante desastres, las métricas de la plataforma deberían fluir al destino configurado originalmente para la región recuperada, una vez que los servicios que envían métricas de la plataforma se restauren y comiencen a enviar métricas de la plataforma a la instancia de IBM Cloud Metrics Routing recuperada.

Todas las actualizaciones siguen las mejores prácticas del servicio de recuperación ante desastres ( IBM ) y cuentan con un plan de recuperación y un proceso de reversión. Las actualizaciones periódicas para nuevas funciones y el mantenimiento se producen como parte de las operaciones normales. Dicho mantenimiento puede causar ocasionalmente breves intervalos de interrupción que se gestionan mediante la lógica de reintento de disponibilidad del cliente. Los cambios se implementan de forma secuencial, región por región y zona por zona dentro de una región. Las actualizaciones se desinstalan a la primera señal de un defecto.

Los cambios complejos se habilitan y deshabilitan con indicadores de características para controlar la exposición.

Los cambios que afectan a las cargas de trabajo de los clientes se detallan en las notificaciones. Para obtener más información, consulte las notificaciones de supervisión y el estado del mantenimiento planificado, los anuncios y las notas de la versión que afectan a este servicio.