Protección del plano de datos de servicio frente a fallos del plano de control

La arquitectura del servicio IBM Cloud separa componentes para el plano de datos y el plano de control.

Los componentes del plano de datos son responsables de proporcionar las funciones primarias del servicio. Los componentes del plano de datos procesan las peticiones de los usuarios y las aplicaciones cliente, como la implementación del procesamiento de datos, la persistencia, el equilibrio de carga, etc.

Por ejemplo, las siguientes son responsabilidades del plano de datos:

• Ejecución y alojamiento de la Instancia de Servidor Virtual (VSI)
• Lectura y escritura en volúmenes de almacenamiento en bloque
• Obtención y fijación de objetos en cubos Object Storage
• Ejecución, procesamiento de consultas y actualizaciones de IBM Cloud Databases for PostgreSQL

Los componentes del plano de control se encargan de administrar y configurar el funcionamiento de los componentes del plano de datos. Los componentes del plano de control procesan las solicitudes de los administradores para gestionar el ciclo de vida del plano de datos a través de las fases de creación, configuración, actualización y retirada de recursos de las instancias de servicio.

Por ejemplo, las siguientes son responsabilidades del plano de control:

• Listado de la VSI en la cuenta y aprovisionamiento de una nueva VSI, orquestación de la creación de máquinas virtuales a partir de una imagen de SO, creación de almacenamiento en bloque, acoplamiento y configuración de los puntos finales de red
• Configuración, redimensionamiento y montaje de volúmenes de almacenamiento en bloque
• Creación de nuevos cubos Object Storage

Para mejorar la resistencia y la continuidad de la actividad, los planos de datos de servicio están diseñados para seguir desempeñando su función principal incluso en caso de fallo del plano de control. Por ejemplo, el acceso del plano de datos a los recursos de infraestructura, cuando se aprovisiona, no depende del plano de control y, por tanto, no se ve afectado por ningún problema del plano de control.

Los fallos en el plano de control pueden afectar a la capacidad de crear, modificar o eliminar recursos, pero no a los recursos existentes que siguen estando disponibles.

Independencia zonal del servicio

Los servicios zonales permiten solicitar el despliegue de instancias de servicio en una zona específica de una región multizonal o en un centro de datos concreto.

Estas instancias de servicio que se despliegan en una zona específica o centro de datos específico se implementan y operan de forma independiente dentro de su región, sin dependencias de componentes de los servicios en otras zonas o centros de datos. Por lo tanto, los fallos en una zona pueden afectar a la instancia alojada en esa zona, pero no afectarán a ninguna instancia de otras zonas de la misma región o de otras regiones.

Las arquitecturas de servicios zonales utilizan un plano de datos zonal que se despliega en cada zona de una región y se gestiona desde el componente del plano de control local en la región.

El usuario o la aplicación interactúa con la función de instancia de servicio utilizando un punto final de API zonal que se encuentra en cada zona de destino.

El plano de control del servicio, con algunas excepciones que se describen en Redundancia global del servicio, está situado en la misma región del plano de datos y desplegado en 3 zonas de las regiones. Es independiente de los planos de control de otras regiones. Por lo tanto, un fallo del plano de control en una región podría afectar sólo a las funciones de servicio de esa región, pero no a las funciones de servicio de otras regiones.

Si se produce un fallo del plano de control en una zona, o si una zona no está disponible, las solicitudes del administrador para gestionar las fases del ciclo de vida del plano de datos, como la creación de recursos, la configuración, la actualización y el desmantelamiento, son realizadas por el plano de control en las dos zonas restantes.

En casos excepcionales en los que el plano de control se despliega globalmente, sigue desplegándose en varias regiones para ayudar a garantizar una alta disponibilidad. Por lo tanto, los fallos en una región no afectarían a las funciones de servicio en las otras regiones.

Para obtener más información sobre las opciones específicas para desplegar las cargas de trabajo que utilizan un servicio zonal, consulte Ubicaciones para el despliegue de recursos y Consideraciones para la alta disponibilidad.

Redundancia de servicios regionales

Los servicios regionales permiten solicitar instancias de servicio que se desplieguen en una región específica en su conjunto sin especificar una única zona o centro de datos de destino.

Estas instancias de servicio que se despliegan en una región se implementan y operan con componentes redundantes que se despliegan en múltiples zonas dentro de la misma región. De este modo, no hay un único punto de fallo en ninguna zona específica dentro de una región.

La arquitectura de servicio regional utiliza un plano de datos regional desplegado en 3 zonas de cada región que se gestiona desde el plano de control local de la región. Si se produce un fallo en el plano de datos de una zona, o si una zona no está disponible, las peticiones de los usuarios y las aplicaciones cliente se redirigen automáticamente al plano de datos de las dos zonas restantes.

El usuario o la aplicación interactúa con la función de instancia de servicio utilizando un punto final de API regional que se encuentra en cada región de destino.

El plano de control de servicios, con algunas excepciones que se describen en Redundancia global de servicios, se encuentra en la misma región del plano de datos y se despliega en 3 zonas de las regiones, independientemente de los planos de control de otras regiones. De este modo, los fallos del plano de control en una región podrían afectar sólo a las funciones de servicio de esa región y no a las funciones de servicio de otras regiones.

Si se produce un fallo del plano de control en una zona, o incluso su pérdida completa, la solicitud de los administradores para gestionar el ciclo de vida del plano de datos a través de las fases de creación de recursos, configuración, actualización, desmantelamiento de instancias de servicio son realizadas por el plano de control en las zonas restantes.

Incluso en los casos excepcionales en los que el plano de control se despliega globalmente, sigue desplegándose en múltiples regiones para ayudar a asegurar una alta disponibilidad y garantizar que los fallos en una región no afecten a las funciones de servicio en otras regiones.

Para obtener más información sobre las opciones específicas para desplegar las cargas de trabajo que utilizan un servicio regional, consulte Ubicaciones para el despliegue de recursos y Consideraciones para la alta disponibilidad.

Redundancia global de servicios

Un subconjunto de servicios IBM Cloud utiliza un modelo de despliegue global con componentes que se despliegan en varias regiones de diferentes ubicaciones y geografías. Estos servicios proporcionan funciones comunes de las que dependen otros servicios zonales o regionales. También hay componentes específicos del plano de control dentro de un servicio que proporcionan funciones globales.

Los servicios que utilizan un modelo de despliegue global implementan una arquitectura distribuida con componentes que se replican en varias regiones. Los componentes están equilibrados en carga en estas regiones con un diseño de conmutación por error automática para mantener los servicios en funcionamiento sin necesidad de la actuación de un operador.

En las siguientes secciones se detallan los servicios que utilizan un modelo de despliegue global y su impacto interregional en las dependencias de otros servicios zonales o regionales.

Este enfoque ayuda a eliminar puntos únicos de fallo en su arquitectura, pero podría representar impactos potenciales entre regiones, incluso cuando esté operando en una región que es diferente de donde se aloja el plano de control de servicio global.

Red troncal redundante

La red IBM Cloud está diseñada para que nunca se produzca un único punto de fallo. Existe una conectividad diversa y redundante en cada punto de la red mediante el uso de diversos proveedores de telecomunicaciones para la conectividad del mismo servicio siempre que sea posible dentro de cada región.

IBM Cloud utiliza diversos proveedores de fibra oscura para conectar los sitios periféricos a todas las instalaciones de computación regionales. Además, cada sitio de borde tiene una red troncal redundante de conectividad con otras regiones, y pares con múltiples proveedores, directa e indirectamente a través de una central local.

Aislamiento de los servicios zonales y regionales de las dependencias interregionales

En general, si se produce un suceso que afecta a la disponibilidad en una región, sólo se ven afectados los servicios zonales y regionales de esa región. Los servicios de otras regiones no se verán afectados.

Los planos de datos de los servicios zonales y regionales dependen de recursos dentro de la misma región, incluidas dependencias esenciales como infraestructura, orquestación de contenedores, bases de datos, seguridad, etc.

El plano de datos de un servicio que se encuentra en una región también depende de instancias de servicio que son proporcionadas por el usuario para soportar las siguientes funciones de servicio a servicio:

• Key Protect instancia para soporte de encriptación BYOK (bring-your-own-key).
• Hyper Protect Crypto Services instancia para soporte de encriptación "keep-your-own-key" (KYOK).
• Object Storage buckets para almacenar copias de seguridad, pruebas y resultados de Security Control Center, registros archivados, etc., y en general para cualquier función que soporte almacenar o procesar gran cantidad de datos en o desde Object Storage buckets.

Seleccione cuidadosamente la región para la asignación de servicios con el fin de garantizar la disponibilidad. Se recomienda situar los servicios en la misma región que los servicios dependientes para evitar el impacto de un fallo entre regiones.

La documentación de cada servicio ofrece indicaciones claras sobre cómo utilizarlos, la ubicación y las opciones de configuración, hasta la arquitectura de sus aplicaciones para el nivel de resistencia deseado.