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

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 Logs es un servicio regional de alta disponibilidad y multiusuario, y puede encontrar las regiones y ubicaciones de centros de datos disponibles en la documentación de Ubicaciones. IBM Cloud Logs, como servicio regional, cumple los objetivos de nivel de servicio(SLO ) definidos con el plan Standard. El SLO no es una garantía e IBM no concederá créditos por no cumplir un objetivo.

Los objetivos de nivel de servicio (SLO) describen los puntos de diseño que deben cumplir los servicios de IBM Cloud. IBM Cloud Logs está diseñado para alcanzar el siguiente objetivo de disponibilidad.

SLO para IBM Cloud Logs
Objetivo de disponibilidad	Valor objetivo
% de disponibilidad	99.99%

Arquitectura de alta disponibilidad

Una zona de disponibilidad es una ubicación aislada lógica y físicamente dentro de una región de IBM Cloud en la que se procesan y se alojan los datos.

Una zona de disponibilidad tiene infraestructuras de alimentación, de refrigeración y de red independientes que están aisladas de otras zonas para aumentar la tolerancia ante errores evitando Puntos únicos de anomalía entre las zonas.
Una zona de disponibilidad ofrece un ancho de banda alto y una baja latencia entre zonas dentro de una región.

Una región (ubicación) es un grupo geográfica y físicamente independiente de una o más zonas de disponibilidad con infraestructuras eléctricas y de red independientes aisladas de otras regiones.

Las regiones están diseñadas para eliminar Puntos únicos compartidos de anomalía con otras regiones y para garantizar una baja latencia entre zonas dentro de la región.
Cada región tiene 3 centros de datos (DC) diferentes por motivos de redundancia.

Funciones de alta disponibilidad

IBM Cloud Logs admite las siguientes funciones de alta disponibilidad:

Características de HA para IBM Cloud Logs
Característica	Descripción
Despliegue regional multizona	IBM Cloud Logs se despliega solo en regiones multizona (MZR) y, dentro de una MZR, el clúster del plano de datos abarca las tres zonas, lo que garantiza que la pérdida de una zona no afecte a la disponibilidad del servicio.
IBM Cloud Logs replicación de recursos entre zonas	Todos los recursos de IBM Cloud Logs, como alertas, métricas y registros, se replican en tres zonas dentro de los MZR. Esto garantiza que los datos se conservarán en caso de pérdida de zona.
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 Logs se basa en una arquitectura de clústeres virtuales ( Red Hat OpenShift on IBM Cloud, VPC) que utiliza regiones multizona y distribuye todos los nodos de trabajo en tres zonas. Los equilibradores de carga de VPC procesan el tráfico entrante y lo reenvían a la malla de servicios que se ejecuta en el clúster.

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

Funciones de recuperación ante desastres

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

Características de DR para IBM Cloud Logs
Característica	Descripción
Otra región	El servicio que se ejecuta en una región alternativa puede utilizarse, independientemente del servicio principal
Copia de seguridad de la base de datos	Se almacena una copia del conjunto de datos actual

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 Logs
Anomalía	Resolución
Fallo de hardware (punto único)	IBM proporciona una base de datos que es resistente a un único punto de fallo de hardware dentro de una zona, no se requiere ninguna configuración.
error de zona	IBM Cloud Logs utiliza un despliegue regional multizona que es resistente desde el punto de fallo de la zona.
Corrupción de datos	En caso de corrupción de datos, la base de datos se revertirá al último estado estable disponible en el sitio de respaldo. Utilizamos copias de seguridad de l IBM Cloud Object Storage, consulte Copias de seguridad
Fallo regional	Siga los pasos indicados en Sus responsabilidades en HA y DR

Sus responsabilidades en HA y DR

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.

En un desastre regional de gran magnitud, como sería un terremoto, una inundación o un tornado, puede que una región entera se viera afectada.

Para recuperar una instancia de IBM Cloud Logs, debe aprovisionar una nueva instancia de IBM Cloud Logs y volver a crear los recursos de IBM Cloud Logs. También debe tener una estrategia de DR para los buckets de IBM Cloud Object Storage que están asociados con la instancia, y la instancia de IBM Cloud Event Notifications que podría haber configurado para activar alertas de notificación.

Para garantizar que sus cargas de trabajo sean resistentes a tales eventos, complete los siguientes pasos:

Defina la estrategia regional en la que puede restaurar la configuración que está inactiva.

Compruebe la ubicación de sus datos y los requisitos de cumplimiento al elegir la región de recuperación.

Para más información sobre las ubicaciones, consulte:
- IBM Cloud Logs regiones admitidas
- IBM Cloud Object Storage regiones admitidas
- IBM Cloud Event Notifications regiones admitidas. IBM Cloud Event Notifications no está disponible en todas las regiones en las que está disponible IBM Cloud Logs.
Si tiene configuraciones que no utilizan Terraform, haga una copia de seguridad de sus configuraciones actuales utilizando la API. Si utiliza Terraform, guarde sus scripts de Terraform para ayudarle a recrear la región que no funciona. Considere la posibilidad de utilizar un sistema de control de versiones para almacenar los archivos de copia de seguridad o los scripts de Terraform.

Puede utilizar Terraform para crear instancias d IBM Cloud Logs. Ver Gestión de recursos Recursos de Terraform.

Puede utilizar Terraform para crear los recursos de IBM Cloud Logs. Ver recursos de Terraform en IBM Cloud Logs.

Puede utilizar Terraform para crear su depósito de datos, su depósito de métricas o ambos, con resiliencia entre regiones para almacenar y acceder a datos en múltiples regiones geográficas y garantizar una alta disponibilidad, durabilidad y capacidades de recuperación ante desastres. Ver recursos de Terraform en IBM Cloud Object Storage.

Puede utilizar Terraform para crear sus recursos de IBM Cloud Event Notifications. Ver recursos de Terraform en IBM Cloud Event Notifications.

Puede utilizar Terraform para crear sus autorizaciones y permisos de IAM. Consulte los recursos de IAM Terraform.

Compruebe siempre que puede restaurar la configuración de la copia de seguridad en una región alternativa.

En caso de desastre regional, debe completar los siguientes pasos para recuperar su instancia en una nueva región:

Identifique una región alternativa donde restaurar la instancia de IBM Cloud Logs.
Cree la nueva instancia de IBM Cloud Logs. Para obtener más información, consulte Suministro de una instancia.
Si su instancia tiene configurados depósitos de datos o métricas, complete los siguientes pasos:
- Si su instancia de IBM Cloud Logs en la región del desastre utilizaba un cubo de Cross Region IBM Cloud Object Storage (COS), puede adjuntar el mismo cubo a la nueva instancia de IBM Cloud Logs, pero no puede consultar los datos creados en la instancia de IBM Cloud Logs en la región del desastre utilizando los paneles de control o la CLI de la nueva instancia de IBM Cloud Logs. Solo podrá consultar los datos que se incorporen en la nueva región. Puede descargar y ver los datos existentes de la región que está inactiva. Para obtener más información sobre la estructura de datos de archivo, consulte Consulta de datos directamente desde el archivo.
- Si necesita acceder a los registros desde la instancia IBM Cloud Logs en el área del desastre utilizando el panel de control o la CLI de la instancia IBM Cloud Logs recién creada, póngase en contacto con el servicio de asistencia de IBM. Para obtener más información sobre la estrategia de recuperación ante desastres para IBM Cloud Object Storage, consulte Terminales de varias regiones, Seguridad de los datos, Crear un Content Store e seguro y Uso de la replicación para la continuidad del negocio y la recuperación ante desastres.
- Si utilizaba cubos locales o regionales de la región afectada, cree nuevos cubos. Adjunte los depósitos a la nueva instancia de IBM Cloud Logs. Para obtener más información, consulte Configuración del depósito de datos y Configuración del depósito de métricas.
- Definir las autorizaciones de IAM entre la instancia de IAM ( IBM Cloud Logs ) y los buckets. Para obtener más información, consulte Creación de una autorización de acceso a recursos compartidos(S2S)para conceder acceso a un bucket.
Si su instancia en la región afectada por el desastre no estaba configurada con buckets de IBM Cloud Object Storage, se perderán los registros y los datos de métricas.
Si su instancia tiene configuradas alertas, complete los siguientes pasos:
- Cree una nueva instancia de IBM Cloud Event Notifications o utilice una existente que pueda tener disponible en una región diferente, asegurándose siempre de que cumple con sus requisitos de conformidad y localización de datos. Para obtener más información, consulte Suministro de una instancia. Para obtener más información sobre la estrategia de recuperación ante desastres de IBM Cloud Event Notifications, consulte Proteger sus datos en IBM Cloud Event Notifications y Recuperación ante desastres.
- Definir las autorizaciones de IAM entre la instancia de IBM Cloud Logs y la de IBM Cloud Event Notifications. Para obtener más información, consulte Creación de una autorización de acceso a recursos compartidos(S2S)para trabajar con el servicio de acceso a recursos compartidos(IBM Cloud Event Notifications ).
- Configure IBM Cloud Event Notifications como una integración saliente. Para obtener más información, consulte Configurar el enrutamiento de eventos a destinos en IBM Cloud Event Notifications.
Recree los recursos en la nueva instancia de IBM Cloud Logs.

Crear vistas.

Crear paneles de instrumentos.

Crear alertas.

Crear políticas de TCO.

Crear reglas de análisis.

Cree eventos para las métricas.

Habilitar el uso de datos.

Configurar reglas de datos.

Configurar políticas de enriquecimiento de datos.

Para facilitar la recuperación de una instancia de IBM Cloud Logs, utilice Terraform para gestionar sus instancias, configuraciones y acceso a IAM. El uso de Terraform eliminará la necesidad de pasos manuales al configurar instancias en otra región.

Después de recuperar la instancia, debe reconfigurar sus fuentes de datos para enviar registros a la nueva instancia:

Si la nueva región tiene configurado un inquilino de IBM Cloud Logs Routing, debe utilizar el objetivo actual asociado a esa región para ver y supervisar los registros de la plataforma. Si la nueva región no tiene configurado un inquilino IBM Cloud Logs Routing, cree un inquilino IBM Cloud Logs Routing que haga referencia a su nueva instancia IBM Cloud Logs. Consulte Creación de un inquilino de IBM Cloud Logs Routing y Comprensión de la alta disponibilidad y la recuperación ante desastres para IBM Cloud Logs Routing.
Si la nueva región tiene una configuración de IBM Cloud Activity Tracker Event Routing que recopila eventos de seguimiento de actividad de la región que está inactiva, puede utilizar la configuración existente para ver y gestionar eventos. Si la nueva región no tiene una configuración de IBM Cloud Activity Tracker Event Routing que recopile eventos de seguimiento de actividad de la región que está inactiva, debe agregar una regla para indicar dónde y cómo desea recopilar eventos. Para obtener más información, consulte Creación de una configuración de enrutamiento resistente a un desastre regional.
Vuelva a configurar su Agente de registro para que apunte al punto final de ingestión de la región de recuperación de IBM Cloud Logs.

Para obtener más información sobre la responsabilidad de propiedad entre usted y IBM Cloud por el uso de IBM Cloud Logs, consulte Comprender sus responsabilidades al usar IBM Cloud Logs.

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

IBM Cloud Logs ofrece formas de 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 Logs.

RPO y RTO para IBM Cloud Logs
Objetivo de recuperación tras desastre	Valor objetivo
RPO	En un plazo de 4 horas
RTO	En 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?

Considere la posibilidad de crear una copia de seguridad utilizando la API antes de actualizar a una nueva versión de IBM Cloud Logs si tiene configuraciones que no utilizan Terraform.

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.

IBM Cloud Logs es un servicio altamente disponible y regional.

Para obtener más información sobre las regiones en las que está disponible IBM Cloud Logs, consulte Ubicaciones.
Cada región dispone de tres centros de datos diferentes para la redundancia que están configurados en modo active/active.
Si fallan todos los centros de datos de una ubicación, IBM Cloud Logs deja de estar disponible en dicha ubicación.
En cada región soportada, el tráfico se equilibra a través de la infraestructura en varias zonas de disponibilidad, sin ningún punto de anomalía.

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

Lista de ubicaciones 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`)	NEE	`MZR`
Europa	Madrid (`eu-es`)	SÍ	`MZR`
América del Norte	Toronto (`ca-tor`)	No aplicable	`MZR`
América del Norte	Montreal (`ca-mon`)	No aplicable	`MZR`
América del Norte	Dallas (`us-south`)	No aplicable	`MZR`
América del Norte	Washington (`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 código postal específico, un pueblo, una ciudad, un estado, un 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.
MZR significa región multizona. Más información.

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.

Los datos gestionados por IBM Cloud Logs en una región se mantienen en los centros de datos cercanos a esa región.

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

De forma predeterminada, IBM Cloud Logs 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.
Los datos de cada zona se replican automáticamente a las demás zonas con baja latencia. No es necesario hacer nada para activar la replicación.
El servicio está diseñado para soportar el fallo de una sola zona interrumpirse.

La arquitectura MZR ofrece conmutación automática por error entre zonas dentro de la región, y alta disponibilidad para el despliegue de IBM Cloud Logs dentro de una región.

Los metadatos gestionados por IBM Cloud Logs incluyen metadatos de clientes, como información sobre configuraciones críticas (claves, definiciones de alertas, definiciones de e e2m, datos de métricas, etc.).

IBM Cloud Logs realiza copias de seguridad periódicas de los datos en cada región:

Se realizan copias de seguridad periódicas a diario, que se conservan durante 30 días y se almacenan en depósitos de almacenamiento de datos ( IBM Cloud Object Storage ) entre regiones
Las copias de seguridad incrementales continuas se conservan los últimos 7 días.

Si se produce un fallo completo en la región, los datos de copia de seguridad permanecen disponibles, y se restauran como parte de la restauración del servicio de IBM Cloud Logs.

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 plano de datos abarca las tres zonas de una región, no habrá ningún impacto en la disponibilidad del servicio, y el equilibrador de carga global reanudará el envío de datos 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 restaura una región después de un fallo, IBM intentará restaurar la instancia de servicio desde el estado regional. Si el estado regional se corrompe, el servicio se restaura al estado de la última copia de seguridad interna, que se transmite continuamente a un sitio de datos alternativo en un bucket de almacenamiento interregional ( IBM Cloud Object Storage ) gestionado por el servicio. Si los datos de copia de seguridad se han dañado, existe la posibilidad de perder datos durante 24 horas. Estas copias de seguridad no están disponibles para la recuperación ante desastres gestionada por el cliente.

Si IBM no puede restaurar la instancia del servicio, el cliente debe restaurarla como se describe en Arquitectura de recuperación ante desastres.

Cómo Tiffany & Co. mantiene los servicios ( IBM )

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 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.