Diseño de alta disponibilidad para sus cargas de trabajo
IBM Cloud admite despliegues de aplicaciones de alta disponibilidad dentro de una única zona, en varias zonas de una región multizona y en varias regiones.
Los dominios de fallo determinan el grado de protección frente a fallos de la infraestructura para cada opción de despliegue. Una instancia de aplicación desplegada en una sola zona no está protegida contra un fallo de esa zona. Las instancias de aplicación desplegadas en varias zonas de disponibilidad están protegidas contra el fallo de una sola zona. Las múltiples zonas de disponibilidad se encuentran dentro de la misma área metropolitana y están conectadas por enlaces de red de baja latencia que permiten replicar los datos de forma sincrónica entre las zonas. Las instancias de aplicación desplegadas en varias regiones están protegidas contra el fallo de toda una región. Las distintas regiones están situadas en diferentes países o en diferentes partes de un mismo país. Por lo general, la distancia entre regiones sólo permite replicar los datos de forma asíncrona.
La siguiente tabla muestra las opciones de despliegue de aplicaciones basadas en dominios de fallo disponibles en una nube pública.
| virtual | Disponibilidad | Dominio del fracaso | Coste y complejidad |
|---|---|---|---|
| Zona única, región única |
Bajo/Medio | Servidor virtual / host físico | Bajo |
| Multizona, una sola región |
Alto | Zona | Medio |
| Multizona, multirregión | Muy alta | Región | Alto |
Despliegue en una sola zona
En los despliegues de zona única, se despliegan varias instancias de aplicación en una zona. Si una instancia de aplicación se ejecuta en un único servidor virtual, los Grupos de Ubicación permiten aprovisionar estos servidores virtuales en hosts físicos separados. VPC Autoscale puede utilizarse para permitir el ajuste dinámico de la capacidad en función de los cambios en la carga de trabajo. Las implantaciones en una sola zona ofrecen soluciones rentables con una disponibilidad de la infraestructura 99.9. Este despliegue podría ser apropiado para entornos no productivos o aplicaciones no críticas para el negocio. Sin embargo, los despliegues de una sola zona no ofrecen protección frente a las interrupciones de las zonas.
Al utilizar este modelo de implementación, se recomienda evitar los desequilibrios entre zonas. Se produce un desequilibrio zonal cuando la capacidad —por ejemplo, las instancias de servidor virtual (VSI) de VPC— no se distribuye de manera uniforme entre las zonas. Consideremos un ejemplo en el que una carga de trabajo se implementa con el 70 % de su capacidad VSI en la zona 1, el 20 % en la zona 2 y el 10 % en la zona 3. Si la zona 1 fallara, la carga de trabajo podría seguir estando disponible, pero solo con el 30 % de su capacidad. Una solución consiste en asignar más recursos si se produce una interrupción en la zona 1, pero dicha interrupción puede provocar un pico anómalo en la demanda de capacidad en las zonas restantes. Una solución más adecuada consiste en eliminar el desequilibrio y garantizar que la capacidad necesaria se distribuya entre las distintas zonas, con un margen adicional de alrededor del 17 % en cada zona para compensar la pérdida de cualquiera de ellas. Esto garantiza que la carga de trabajo siga estando disponible y pueda funcionar a plena capacidad, en caso de que se produzca la pérdida de una zona.
Implantación multizona y en una sola región
En un despliegue multizona de región única, se despliegan varias instancias de aplicación en dos o más zonas de disponibilidad dentro de la región. Las implementaciones multizona en una sola región pueden ofrecer una disponibilidad de la infraestructura de hasta el 99.99 %, cuando la aplicación se implementa en tres zonas de disponibilidad. Esta implementación protege la aplicación frente a fallos de zona y es adecuada para cargas de trabajo empresariales en entorno de producción con requisitos de disponibilidad superiores al 99.9 %. La disponibilidad real de la aplicación depende del diseño de alta disponibilidad de la aplicación.
Cuando utilices este modelo de implementación, evita los desequilibrios entre zonas. Se produce un desequilibrio zonal cuando la capacidad —por ejemplo, los IBM Cloud® Virtual Servers for Virtual Private Cloud (VSI)— no se distribuye de manera uniforme entre las zonas. Consideremos un ejemplo en el que una carga de trabajo se implementa con el 70 % de su capacidad VSI en la zona 1, el 20 % en la zona 2 y el 10 % en la zona 3. Si la zona 1 falla, la carga de trabajo podría seguir estando disponible, pero solo con el 30 % de su capacidad. Se podrían aprovisionar más recursos cuando se produzca una interrupción del servicio, pero esta puede provocar un pico anómalo en la demanda de capacidad en el resto de zonas. En su lugar, elimine el desequilibrio distribuyendo la capacidad necesaria de manera uniforme entre las zonas, con un margen adicional de aproximadamente el 17 % por zona para compensar la pérdida de cualquier zona concreta. Esto garantiza que la carga de trabajo siga estando disponible y pueda funcionar a plena capacidad si falla una zona.
Despliegue multizona y multirregión
Un despliegue multizona y multirregión ofrece protección frente a los cortes de suministro en una región. Este despliegue se recomienda para aplicaciones de misión crítica con requisitos de disponibilidad continua o casi continua. Este despliegue también admite la recuperación ante desastres fuera de la región y la continuidad del negocio para aplicaciones con requisitos geográficos o de distancia de separación específicos.
Los despliegues multizona se basan en la replicación de datos en función de la aplicación en todas las zonas de disponibilidad y admiten patrones de arquitectura activo-activo y activo-standby. Las implantaciones multizona y multirregión admiten patrones de arquitectura para aplicaciones empresariales con disponibilidad continua y requisitos de funcionamiento permanente. Las tablas siguientes muestran una comparación de las distintas opciones de despliegue y el uso recomendado.
| virtual | Disponibilidad | Descripción | Uso recomendado |
|---|---|---|---|
| Zona única | 99.9% |
|
|
| Multizona, región única | 99.99% |
|
|
| Multizona, multirregión |
|
|
|
El siguiente marco de arquitectura proporciona consideraciones de diseño y decisiones de arquitectura para desplegar aplicaciones resistentes en la infraestructura de IBM Cloud Virtual Private Cloud (VPC). Abarca los siguientes aspectos y ámbitos de la solución:
- Redes: Equilibrio de carga, Sistema de nombres de dominio
- Seguridad de los datos Seguridad de los datos
- Resiliencia: alta disponibilidad, copias de seguridad y restauración, recuperación ante desastres
- Gestión de servicios: Supervisión, registro, auditoría y alerta
El Marco de Diseño de Arquitectura proporciona un enfoque coherente para diseñar soluciones en la nube abordando los requisitos a través de un conjunto de aspectos y dominios. Los dominios son áreas arquitectónicas que deben tenerse en cuenta para cualquier solución empresarial, independientemente de la tecnología.
Lógica de reintento del cliente para aplicaciones de alta disponibilidad
Usted es responsable de crear aplicaciones cliente que puedan gestionar errores temporales de forma eficaz. Los errores temporales incluyen errores de red y fallos temporales introducidos por la implementación de alta disponibilidad de un servicio, como cuando un servicio regional se recupera de un fallo zonal. Para obtener más información sobre servicios específicos IBM Cloud, consulte la documentación del servicio de alta disponibilidad y recuperación ante desastres.
Muchos de los IBM Cloud SDK se basan en el IBM Cloud SDK Common que admite reintentos automáticos diseñados para gestionar errores HTTP específicos, como los errores 429 y 503. El SDK no gestiona todos los errores automáticamente. Para aprovechar la lógica de reintento, debe configurar el SDK correctamente.
Algunos servicios IBM Cloud soportan protocolos de código abierto, y puede ser apropiado utilizar SDKs de código abierto. Examine estos SDK para determinar si son útiles para su aplicación y ofrecen funciones de reintento adecuadas.
La lógica de reintento varía en función del tipo de servicio IBM Cloud y del tipo de operación. Algunas operaciones fallidas producen códigos de estado aptos para el reintento, y otras producen códigos de estado no aptos para el reintento. Las operaciones de lectura y HTTP GET fallidas pueden reintentarse generalmente utilizando un backoff exponencial con un periodo de tiempo fijo. El backoff exponencial es una estrategia de reintentos para gestionar los reintentos tras una operación fallida, como una solicitud de red o una llamada a la API. Aumenta gradualmente el retardo entre reintentos siguiendo un patrón exponencial, lo que reduce el riesgo de sobrecarga del sistema. Los fallos que deben reintentarse dependen del tipo de fallo y del servicio específico IBM Cloud. Para obtener más información, consulte el SDK y la documentación de cada servicio IBM Cloud.
Las operaciones fallidas de escritura, HTTP PUT, POST, DELETE y otras probablemente no puedan recuperarse utilizando un simple mecanismo de reintento, a menos que esté claro que la operación no se completó y la lógica documentada del cliente indique que un reintento es apropiado. Cuando una operación que cambia el estado de un sistema, como la creación de un recurso, falla, a menudo no está claro qué causó el fallo. Debido a esta incertidumbre, no se puede confiar en una simple lógica de reintento para solucionar el problema. En su lugar, utilice métodos más avanzados diseñados específicamente para el servicio IBM Cloud.
El reintento de cliente mejora la disponibilidad de un solo cliente, y las cargas de trabajo pueden estar compuestas por muchos clientes. Registrar los fallos de los clientes en un servicio de registro centralizado como IBM Cloud Logs permite realizar análisis de fallos y disponibilidad de toda la carga de trabajo.