Plan empresarial predeterminado y personalizado
En esta sección se describe la alta disponibilidad (HA) que proporciona el servicio IBM MQ on Cloud, cómo crear una arquitectura de solución HA de gestor de colas y detalles de la recuperación tras desastre. La información aquí es una especificación de los planes Empresa predeterminada y Personalizada.
Alta disponibilidad
Internamente, IBM MQ on Cloud se despliega utilizando una serie de componentes que se crean y despliegan como contenedores en un clúster de Kubernetes que se ejecuta en la región geográfica determinada que ha seleccionado. Cada gestor de colas de pago que despliega existe en su propio contenedor aislado y tiene asignado CPU, RAM y disco para su uso.
Un clúster de Kubernetes consta de varios nodos trabajadores (por ejemplo, máquinas virtuales) en los cuales se distribuyen los contenedores desplegados, y cada contenedor tiene una comprobación de estado y de actividad definidas, de forma que Kubernetes hará que el contenedor se mueva automáticamente de un nodo trabajador a otro en caso de que se produzcan determinados tipos de anomalía.
Actualmente, la infraestructura de MQ on Cloud se despliega en un único centro de datos (también denominado "Zona de disponibilidad única") dentro de cada región, por lo que cada uno de los nodos trabajadores del clúster de Kubernetes está dentro de un único centro de datos.
El estado persistente de un gestor de colas como, por ejemplo, las colas definidas, los mensajes persistentes contenidos en dichas colas y el estado de la secuencia de los canales del gestor de colas se almacenan en un volumen persistente que existe fuera de la imagen del contenedor, de forma que cuando se reinicia un contenedor de gestor de colas en un nodo trabajador distinto, tiene exactamente el mismo estado persistente que cuando se estaba ejecutando en el nodo trabajador original.
El enfoque descrito anteriormente forma la base de la alta disponibilidad en IBM MQ on Cloud y garantiza que los gestores de colas puedan continuar ejecutándose incluso en caso de que un trabajador individual del clúster falle.
Arquitectura de solución necesaria para la configuración del gestor de colas HA
La arquitectura de MQ on Cloud descrita anteriormente proporciona muy buenos niveles de disponibilidad para los gestores de colas individuales, ya que garantiza que pueden continuar ejecutándose aunque fallen partes de la infraestructura subyacente, sin embargo, un gestor de colas individual sigue siendo un punto único de anomalía en tanto en cuanto se va a poner fuera de línea durante breves periodos de tiempo en casos como, por ejemplo, cuando un gestor de colas realice una migración tras error a un nuevo nodo trabajador para evitar una interrupción de servicio, cuando se reinicia el gestor de colas para aplicar arreglos de seguridad o actualizaciones de características, o si hay una anomalía a nivel de toda la región.
Los siguientes puntos describen cómo utilizar IBM MQ on Cloud para desplegar una arquitectura de solución altamente disponible que proporciona disponibilidad ininterrumpida de servicio incluso en el caso de que un gestor de colas individual esté fuera de línea durante un periodo de tiempo. Esta arquitectura de solución también define la "Configuración identificada de HA" para IBM MQ on Cloud según lo prescrito por el acuerdo de nivel de servicio contractual (SLA) de IBM Cloud para la configuración de alta disponibilidad, tal como se hace referencia en la Sección 3.2 de la Descripción del servicio de IBM Cloud.
- Los usuarios deben desplegar dos o más gestores de colas en distintas ubicaciones de despliegue para garantizar la disponibilidad continuada en caso de una interrupción de servicio a nivel (por ejemplo, las regiones de Londres y Frankfurt, o IBM Cloud Dallas y AWS US East 1, pero no desplegar los dos gestores de colas en IBM Cloud Dallas)
- Cada gestor de colas debe estar configurado con la misma conectividad y el mismo conjunto de objetos (como por ejemplo colas/temas/canales) para que las aplicaciones se puedan conectar a cualquiera de los dos gestores de colas para llevar a cabo su trabajo
- Las aplicaciones se deben configurar para que se puedan conectar a cualquier gestor de colas disponible
- Las aplicaciones de productor se deben configurar de modo que pueden conectarse a cualquiera de los gestores de colas (por ejemplo, el equilibrio de la carga de trabajo - activo/activo, o pasar al segundo gestor de colas si el primero no está disponible - activo/pasivo)
- Se deben desplegar y distribuir varias instancias de aplicaciones consumidoras en los gestores de colas disponibles para que los mensajes no se dejen sin consumir en las instancias disponibles de colas/temas
- Las aplicaciones se deben configurar con reconexión automática para asegurarse de que restablecerán automáticamente la conexión a un gestor de colas en caso de que se produzca un error
Técnicas de IBM MQ para implementar la arquitectura de la solución de HA
El producto IBM MQ incluye diversas funciones tanto del lado del cliente como del lado del servidor (gestor de colas) para dar soporte a la configuración de la arquitectura de la solución de alta disponibilidad descrita anteriormente;
- ConnectionNameList es una lista separada por comas de puntos finales de gestor de colas con el formato "host1(port1),host2(port2)" que se probarán en orden secuencial cuando la aplicación cree una conexión, por lo que es ideal para escenarios de tipo activo/pasivo donde las aplicaciones preferirían conectarse al host1 si está disponible
- CCDT (Client Channel Definition Table - Tabla de definición de canales de cliente) es un formato de archivo que define el conjunto de gestores de colas disponibles y permite al usuario definir grupos de gestores de colas equivalentes y políticas para distribuir las solicitudes de conexión entre esos gestores de colas. De forma predeterminada, las conexiones a los conjuntos de gestores de colas serán aleatorias dentro del grupo (lo que es ideal para escenarios de tipo activo/activo), pero también se puede configurar para definir una preferencia (p. ej. escenarios de tipo activo/pasivo)
- Las aplicaciones que utilizan la API de mensajería REST de IBM MQ se conectan a un punto final de URL REST distinto para cada gestor de colas, y pueden utilizar las capacidades de su entorno de programación para seleccionar el punto final a utilizar y cómo realizar la migración tras error en caso de que uno de los puntos finales no esté disponible
Recuperación tras desastre en frío
Las secciones anteriores describen cómo IBM MQ on Cloud proporciona una alta disponibilidad para manejar las interrupciones o las anomalías que pueden producirse en los trabajadores individuales en los que se ejecutan los gestores de colas, sin embargo, hay un caso de error más extremo en el que una anomalía catastrófica hace que toda la infraestructura y los datos existentes dejen de estar disponibles o queden dañados. El proceso de restaurar el servicio después de este tipo de error se denomina "Recuperación tras desastre en frío", abreviado "DR en frío".
Como ejemplo, se produciría un escenario de DR en frío si todo el centro de datos donde se ha desplegado la infraestructura de MQ on Cloud para una región determinada quedara fuera de línea, por ejemplo debido a un desastre natural importante. En este caso, el volumen persistente donde se almacena el estado de ejecución del gestor de colas deja de estar disponible (porque se almacena dentro del centro de datos único), por lo que no se podrá restaurar el gestor de colas exactamente al estado que tenía antes del error catastrófico.
Responsabilidades de IBM
Para que IBM pueda restaurar el servicio después de un error catastrófico de este tipo, se realiza una copia de seguridad de la configuración de cada uno de los gestores de colas de pago cada 24 horas y se guarda en formato cifrado en una ubicación de almacenamiento fuera del centro de datos activo. La copia de seguridad de la configuración incluye las definiciones de administración de las colas, los temas y los canales que existen dentro del gestor de colas, así como los certificados TLS que se han aplicado, pero no incluye el estado de ejecución, como por ejemplo los mensajes persistentes o el estado de la secuencia de canales, porque en un gestor de colas el estado de ejecución cambia con tanta frecuencia que restaurar una copia de esos datos de hasta 24 horas es normalmente menos deseable para una empresa que partir de un estado limpio.
Puesto que al restaurar un gestor de colas a partir de esta copia de seguridad de configuración se pierde el estado de ejecución, como por ejemplo los mensajes persistentes, no es una acción que IBM realice a la ligera y, por lo tanto, el equipo de IBM Operations trabajará primero con el proveedor de la infraestructura (por ejemplo, IBM o Amazon Web Services) para recuperar la infraestructura existente. Solo una vez que se haya determinado que no se puede recuperar la infraestructura original en un plazo de tiempo aceptable, se activará el proceso de DR en frío.
Una vez que se haya tomado la decisión de activar el proceso de DR en frío, IBM iniciará la nueva infraestructura en un centro de datos distinto para alojar los gestores de colas de pago, y utilizar la copia de seguridad de configuración de cada gestor de colas de pago para volver a crear una copia del gestor de colas desplegado en la nueva infraestructura. Finalmente, se actualiza el nombre de host de DNS que utilizan las aplicaciones para acceder al gestor de colas para que apunte al nuevo despliegue de la infraestructura.
RTO y RPO (objetivo de tiempo de recuperación y objetivo de punto de recuperación)
- RTO es de 24 horas
- RPO es de 24 horas
| Región del gestor de colas | Zona de disponibilidad de proceso | Zona de disponibilidad alternativa | Región multi-az de copia de seguridad |
|---|---|---|---|
| us-south | dal12 | dal14 | us-south |
| us-east | wdc04 | wdc06 | us-east |
| eu-de | fra02 | fra05 | eu-de |
| eu-gb | lon04 | lon02 | eu-gb |
| AWS us-east-1 | us-east-1d | us-east-1b | us-east |
| AWS eu-west-1 | eu-west-1c | eu-west-1b | eu-west |
Responsabilidades del cliente
Puesto que la restauración en frío del gestor de colas no conserva el estado de ejecución, como por ejemplo el estado de la secuencia de canales, es posible que tenga que llevar a cabo alguna acción administrativa para volver a integrar el gestor de colas restaurado en la otra infraestructura, por ejemplo restableciendo números de secuencia de canales para que los canales se comuniquen correctamente. Como ayuda en este paso final de recuperación, se recomienda que configure un manejador de notificaciones de recuperación tras desastre como se describe aquí cuando despliegue los gestores de colas para recibir una notificación del equipo de IBM Operations cuando se haya completado el proceso de recuperación tras desastre.