Visión general de la alta disponibilidad y la recuperación tras desastre para Red Hat OpenShift on IBM Cloud
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 ante fallos inesperados. La recuperación de 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 recuperación de la instancia de servicio a un estado de funcionamiento.
Red Hat OpenShift on IBM Cloud es un servicio regional o zonal de alta disponibilidad diseñado para estar disponible durante una interrupción regional o zonal. Red Hat OpenShift on IBM Cloud está diseñado para cumplir los Objetivos de Nivel de Servicio (SLO) con el plan Estándar.
Para obtener más información sobre la región disponible y las ubicaciones de los centros de datos, consulte Disponibilidad de servicios e infraestructura por ubicación.
Arquitectura de alta disponibilidad
Red Hat OpenShift on IBM Cloud la arquitectura crea una alta disponibilidad a nivel regional, de zona y de clúster.
- Disponibilidad de regiones
- Cada región está configurada con un equilibrador de carga de alta disponibilidad al que se puede acceder desde el punto final de la API específico de la región. El equilibrador de carga direcciona solicitudes de entrada y salida a los clústeres en las zonas regionales. La probabilidad de que se produzca un error global de región es baja. Sin embargo, para estar preparado ante este error, puede configurar varios clústeres en diferentes regiones y conectarlos mediante un equilibrador de carga externo. Si falla una región entera, el cluster de la otra región puede hacerse cargo de la carga de trabajo.
- Disponibilidad de grupos y zonas
- Los errores de zona afectan a todos los hosts de cálculo físico y al almacenamiento NFS. Los errores pueden ser interrupciones de alimentación, refrigeración, red o almacenamiento, y desastres naturales, como inundaciones, terremotos y huracanes. Para estar protegido ante un error de zona, debe tener clústeres en dos zonas diferentes en las que equilibre la carga un equilibrador de carga externo. Crear un clúster en una ubicación multizona, que distribuye el maestro por las zonas. O bien, considere la posibilidad de configurar un segundo clúster en otra zona.
- Disponibilidad en varias zonas
- Los clústeres multizona distribuyen las cargas de trabajo entre múltiples nodos y zonas de trabajo, creando una protección adicional contra los fallos de zona. Los nodos de trabajo se despliegan automáticamente con tres réplicas repartidas en varias zonas. Si una zona entera experimenta una interrupción, su carga de trabajo se programa en nodos de trabajo en las otras zonas, protegiendo su aplicación de la interrupción.
- Equilibrio de carga global
- Para proteger su aplicación de un fallo maestro o para clústeres clásicos que deben residir en una de las regiones multizona compatibles, puede crear varios clústeres en diferentes zonas dentro de una región y conectarlos con un equilibrador de carga global.
Distribución de recursos para alta disponibilidad.
Si distribuye sus apps entre varios nodos trabajadores, zonas y clústeres, es menos probable que los usuarios experimenten un tiempo de inactividad del sistema. Características incorporadas como, por ejemplo, el aislamiento y el equilibrio de carga, incrementan la resiliencia con relación a posibles anomalías con hosts, redes o apps. Revise estas configuraciones potenciales de clústeres que están ordenadas por grados de disponibilidad en orden ascendente. Para obtener más información sobre cómo se distribuyen los recursos de IBM Cloud en las zonas geográficas y regiones, consulte la documentación de Ubicaciones.
- Clústeres de una sola zona
- Sólo clásico
- Los clústeres de zona única tienen nodos de trabajo que se distribuyen en hosts físicos separados dentro de la misma zona. Esta opción protege contra ciertas interrupciones, como durante una actualización maestra, y es más sencilla de gestionar. Sin embargo, no protege sus aplicaciones si toda una zona sufre una interrupción.
- Clústeres multizona
- Clásico VPC
- Los clústeres multizona tienen nodos de trabajo implementados automáticamente con tres réplicas repartidas en varias zonas. Si una zona entera experimenta una interrupción, su carga de trabajo se programa en nodos de trabajo en las otras zonas, protegiendo su aplicación de la interrupción.
- Múltiples clústeres vinculados con equilibradores de carga
- Clásico VPC
- Se pueden configurar múltiples clústeres en la misma zona o en zonas diferentes y conectarlos a través de un equilibrador de carga global. Esta opción es útil si debe aprovisionar un clúster en una región de zona única, pero aún desea los beneficios de la disponibilidad multizona.
Funciones de alta disponibilidad
Revise las funciones disponibles para proporcionar una alta disponibilidad a sus aplicaciones y servicios.
| Característica | Descripción |
|---|---|
| Opciones anti-afinidad | Utilice reglas anti-afinidad para distribuir la implementación de pods entre los nodos de trabajo en lugar de restringir la implementación a nodos específicos. Esto proporciona flexibilidad adicional para su carga de trabajo. |
| Conjuntos de réplicas | Para aumentar la disponibilidad de la app, puede añadir un conjunto de réplicas en el despliegue. Si una instancia de la app deja de estar activa, Kubernetes automáticamente activa una nueva instancia de la app para mantener el número especificado de instancias de la app. |
| Equilibrio de carga multizona (Clásico) | Cuando se crea un clúster clásico multizona, se crea automáticamente un equilibrador de carga multizona en cada zona en la que reside el clúster para gestionar todas las solicitudes entrantes a las aplicaciones y equilibrar la carga de las solicitudes entre los equilibradores de carga de aplicaciones (ALB) de las zonas del clúster. También habilita las comprobaciones de estado para las direcciones IP públicas de Ingress. |
| Equilibrio de carga de VPC (VPC) | Cuando creas un clúster de VPC, se crea automáticamente un equilibrador de carga de VPC para que gestiones todas las solicitudes entrantes a tus aplicaciones y equilibres la carga de las solicitudes entre los equilibradores de carga de aplicaciones (ALB) en las zonas de tu clúster. También habilita las comprobaciones de estado para las direcciones IP públicas de Ingress. |
| Programa de escalado automático de clústeres | El complemento de autoescalado de clústeres escala automáticamente los grupos de trabajadores de su clúster para aumentar o reducir el número de nodos de trabajadores en el grupo de trabajadores en función de las necesidades de tamaño de sus cargas de trabajo programadas. |
Funciones de recuperación ante desastres
La estrategia general para la recuperación ante desastres es configurar el almacenamiento y las copias de seguridad de sus datos con soluciones como Portworx.
Red Hat OpenShift on IBM Cloud admite las siguientes funciones de recuperación ante desastres:
| Característica | Descripción |
|---|---|
| Portworx | Una solución de almacenamiento definida por software de terceros y de alta disponibilidad que puede utilizar para gestionar el almacenamiento persistente local para sus bases de datos en contenedores y otras aplicaciones con estado, o para compartir datos entre pods en varias zonas. Revisar los requisitos previos |
| OpenShift Recuperación ante desastres regionales de la Fundación de Datos Abiertos(ODF) | Una solución de recuperación en caso de catástrofe que proporciona una recuperación automatizada con un solo clic si se produce una catástrofe regional. Las solicitudes se reasignan automáticamente a un centro de datos designado ( OpenShift Container Platform ) con un clúster ODF que esté disponible en otra región. |
| Cloud Object Storage (COS) | Una opción de almacenamiento persistente y de alta disponibilidad que se integra en sus aplicaciones, disponible como complemento. Revise las limitaciones. |
| Recuperación automática | El sistema de recuperación automática utiliza varias comprobaciones para consultar el estado de salud del nodo trabajador de la consulta. Si la recuperación automática detecta un nodo trabajador en mal estado basándose en las comprobaciones configuradas, la recuperación automática activa una acción correctiva como el rearranque de un nodo trabajador de VPC o la recarga del sistema operativo en un nodo trabajador clásico. |
| Portabilidad de datos con Velero | Una opción de terceros para exportar datos desde su clúster a una instancia de Oracle Cloud Service ( IBM ) u otro proveedor de servicios de nube ( s3 ). |
Portabilidad de datos utilizando la CLI(kubectl) |
Exportar datos mediante la CLI (interfaz de línea de comandos) de kubectl. |
Revise las opciones adicionales para exportar datos, como rclone o OADP.
Objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO)
| Característica | RTO y RPO | Consideraciones |
|---|---|---|
| Portworx | RTO = Recuperación total de operaciones ( <60s ), RPO = Pérdida total de operaciones ( <60s )- 15m | Los valores difieren entre las configuraciones asíncronas o síncronas (también conocidas como Metro DR). Para obtener más información, consulte Configuración de la recuperación tras desastre con Portworx. |
| ODF Recuperación regional ante desastres | RTO = 0, RPO = 0 | Estos valores se aplican únicamente al nivel de clúster. La recuperación regional y metropolitana no está disponible actualmente. |
| Cloud Object Storage | Consulte los documentos de almacenamiento de objetos. |
Cómo ayuda a garantizar la recuperación ante desastres IBM®
IBM® toma medidas de recuperación específicas para Red Hat OpenShift on IBM Cloud si se produce un desastre.
Cómo se recupera IBM de los fallos
Si se produce un fallo zonal o regional, IBM es responsable de la recuperación de los componentes. IBM intentará restaurar el clúster en la misma región basándose en el último estado del almacenamiento persistente interno. IBM actualiza y recupera los componentes operativos del clúster, como el equilibrador de carga de aplicaciones Ingress y el complemento de almacenamiento de archivos.
IBM también ofrece la posibilidad de integrarse con otros servicios de IBM Cloud, como proveedores de almacenamiento, para poder realizar copias de seguridad y restaurar los datos. Es su responsabilidad implementar estas integraciones.
Cómo Tiffany & Co. mantiene los servicios ( IBM )
Todas las actualizaciones siguen las mejores prácticas de servicio de IBM, incluidos los planes de recuperación y los procesos de reversión. El mantenimiento periódico puede provocar breves interrupciones, mitigadas por 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. IBM revierte las actualizaciones ante el primer signo 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 notificaciones de IBM Cloud. Para obtener más información sobre el mantenimiento planificado, los anuncios y las notas de la versión que afectan a este servicio, consulte Notificaciones y estado de supervisión.
Sus responsabilidades en materia de alta disponibilidad y recuperación en caso de catástrofe
Es su responsabilidad probar continuamente su plan para HA y DR.
Pueden producirse interrupciones en la conectividad de la red y breves periodos de indisponibilidad de un servicio. Es su responsabilidad asegurarse de que el código fuente de la aplicación incluya la lógica de reintento de disponibilidad del cliente para mantener una alta disponibilidad de la aplicación.
Usted es responsable de configurar su clúster para lograr el nivel adecuado de disponibilidad para sus aplicaciones y servicios. El nivel de disponibilidad que configure para el clúster afecta a la cobertura bajo los términos del acuerdo de nivel de servicio de alta disponibilidad de IBM Cloud. Por ejemplo, para recibir una cobertura completa de alta disponibilidad según los términos del SLA, debe configurar un clúster multizona con un total de 6 nodos de trabajador como mínimo, dos nodos de trabajador por zona que se distribuyen uniformemente en tres zonas.
Usted es el responsable de la recuperación de las cargas de trabajo que se ejecutan en el clúster y en los datos de la aplicación. Para más información sobre sus responsabilidades en la recuperación de desastres, consulte Sus responsabilidades con el uso de Red Hat OpenShift on IBM Cloud.
Gestión de cambios
La gestión de cambios incluye tareas como actualizaciones, cambios de configuración y eliminaciones. Tenga en cuenta los siguientes puntos para reducir el tiempo de inactividad o la pérdida de datos de su carga de trabajo.
-
Se recomienda que conceda a los usuarios y procesos los roles y acciones de IAM con el mínimo privilegio requerido para su trabajo. Por ejemplo, limitar la capacidad de eliminar recursos de producción.
-
Utilice las herramientas de la API, la CLI o la consola para aplicar las actualizaciones de los nodos trabajadores proporcionadas que incluyen parches del sistema operativo, o para solicitar que se reinicien, recarguen o sustituyan los nodos trabajadores.
-
Utilice las herramientas de la API, la CLI o la consola para aplicar los valores mayor y menor proporcionados Kubernetes actualizaciones maestras y mayor, menor y actualizaciones del nodo patch worker. Asegúrese de revisar la información y los requisitos de cada actualización de versión para evitar problemas o tiempos de inactividad.
-
Asegúrese de que los nodos trabajadores del clúster ejecutan la última versión de Ubuntu más reciente.
-
Asegúrese de comprender los horarios de publicación de cualquier complemento que ejecute en su clúster.
Consideraciones para la implementación de aplicaciones y servicios
La forma en que configura su clúster afecta al nivel de disponibilidad que consigue para sus aplicaciones y servicios. Cuanto más ampliamente distribuya la configuración entre varios nodos trabajadores y clústeres, menor será la probabilidad de que los usuarios experimenten tiempo de inactividad con la app.
Revise las siguientes configuraciones potenciales de apps que están ordenadas por grados de disponibilidad en orden ascendente.
- Un despliegue con pods n+2 gestionados por un conjunto de réplicas en un único nodo.
- Un despliegue con n+2 pods gestionados por un conjunto de réplicas y distribuidos en varios nodos (antiafinidad) en un clúster de una sola zona.
- Un despliegue con n+2 pods gestionados por un conjunto de réplicas y distribuidos en varios nodos (antiafinidad) en varias zonas de un clúster multizona.
Revise la siguiente documentación para obtener información sobre la creación de una carga de trabajo de alta disponibilidad.