¿Qué, cómo y cuándo aplicar Alta Disponibilidad en GCP?
¿Qué es Alta Disponibilidad?
Probablemente más de alguna vez han escuchado el concepto de Alta Disponibilidad o simplemente la sigla HA.
La Alta Disponibilidad (https://es.wikipedia.org/wiki/Alta_disponibilidad)
Es un protocolo de diseño del sistema y su implementación asociada que asegura un cierto grado absoluto de continuidad operacional durante un período de medición dado.
Felicitaciones, ya sabes qué es la alta disponibilidad, no era tan difícil no? Ahora vamos a entender los conceptos básicos para saber como aplicar alta disponibilidad en nuestras soluciones.
¿Cómo aplicar Alta Disponibilidad en GCP?
En GCP en particular existen 3 conceptos importantes para poder entender cual es o será disponibilidad de nuestras soluciones
- Regiones.
- Zonas.
- SLA.
Una región es una ubicación geográfica específica donde puedes alojar recursos.
Una zona es una ubicación aislada dentro de la región.
Ref Regiones y Zonas: https://cloud.google.com/compute/docs/regions-zones
SLA es la sigla de Service-Level Agreement es un acuerdo entre un proveedor de servicio y su cliente con el objetivo de fijar el nivel acordado para la calidad de dicho servicio.
Ref GCP SLA: https://cloud.google.com/terms/sla y https://es.wikipedia.org/wiki/Acuerdo_de_nivel_de_servicio
Una Región en GCP tiene una o más zonas.
Solución A: Si tu solución está solamente en una zona, si falla esa zona tu solución perderá su disponibilidad.
Solución B: Si tu solución se encuentra en 2 zonas de una misma región, la solución será más resiliente que la Solución A, ya que para perder su disponibilidad es necesario que no una, sino 2 zonas al mismo tiempo de una misma región esten abajo, pero si se cae la región, la solución perderá su disponibilidad.
Solución C: Si tu solución se encuentra en 4 zonas de 2 regiones diferentes, la solución será más resiliente que la Solución B, ya que además de tener la disponibilidad de la Solución B, en caso de que una región completa quede no disponible, hay otra región para poder seguir entregando disponibilidad a la solución.
Para hacer este ejemplo aún más practico, les dejo un ejemplo de Compute Engine, que es el servicio de Máquinas Virtuales en Google .
Ref Compute Engine SLA: https://cloud.google.com/compute/sla
Ejemplo 1: Si tienes una instancia en una sola zona, Google Cloud te promete un SLA de >= 99.5% lo cual se traduce aprox en 44 horas al año que podría en el peor de los casos estar abajo.
Horas en un año = 365 días x 24 horas = 8760 horas.
SLA en horas anuales = 365 días x 24 horas x 0.995 SLA= 8716 horas.
Horas de indisponibilidad anual= 44 horas anuales.
Ejemplo 2: Si tienes 2 instancias en multiples zonas de una misma región google te promete un SLA de >= 99.99% lo cual se traduce en aprox 1 hora al año que podría en el peor de los casos estar abajo.
Horas en un año = 365 días x 24 horas = 8760 horas.
SLA en horas anuales = 365 días x 24 horas x 0.9999 SLA = 8759 horas. anuales.
Horas de indisponibilidad anual =1 hora de indisponibilidad anual.
Ejemplo 3: Ahora si tu aplicación necesita un SLA más elevado, en vez de tener tu solución en 2 zonas de una misma región, tendrías que poner tus instancias en multiples zonas de multiples regiones con el fin de poder reducir la indisponibilidad de servicio a algo menor que 1hora considerando el Ejemplo 2.
Hay mas casos, como por ejemplo tener 4 instancias en 4 zonas de una misma región o 2 instancias en 2 regiones distintas.
Lo más importante al final de este ejercicio es entender lo siguiente.
Sin Alta Disponibilidad (Disponibilidad:Baja / Costo:Bajo): Que falle una zona es probable, pero también requiere de un menor costo.
Alta Disponbilidad Zonal (Disponibilidad:Media / Costo:Medio): Que fallen 2 zonas dentro de una misma región es menos probable, pero es más costoso que tener tu solución en solamente una zona.
Alta Disponibilidad Regional (Disponibilidad:Alta / Costo:Alto): Que fallen 4 zonas, dentro de las cual, 2 zonas se encuentran en la región A y 2 zonas se encuentran en la región B es muy poco probable, pero es más costoso que tener solamente tu solución en 2 zonas en una sola región y mucho más costoso que tener tu solución solamente en una zona.
También es muy importante entender lo siguiente:
Caso 1: Si tu servicio NO es un servicio autoadministrado (EJ: Una instancia de Compute Engine) debes implementar una capa superior (Como un Balanceador de Carga) para poder lograr que tu solución tenga alta disponibilidad en caso de que una zona tenga una caida. Esto considera una complejidad tanto técnica como un aumento de costo de la solución.
Caso 2: Si tu servicio SÍ es autoadministrado, en caso de que ocurra una falla en alguna zona, de forma automática el servicio utilizará otra zona y tu no tienes que preocuparte. Esto solamente considera un aumento en el costo de la solución.
Felicitaciones, ya no sabes solamente qué es la alta disponibilidad, sino que cómo se puede aplicar en GCP. Ahora vamos por el último de los pasos, cuando deberíamos o no realmente aplicar la alta disponibilidad, entendiendo que existe además un factor de costos asociados dependiendo de cada una de las opciones que queramos elegir.
¿Cuándo aplicar Alta Disponibilidad en tus Soluciones?
Como ya pudimos darnos cuenta en la sección anterior, el aplicar Alta Disponibilidad a tu soluciones no solamente representa un esfuerzo técnico (en algunos casos), sino que también un costo monetario, por lo que para tomar la decisión de que solución de alta disponibilidad es la que deberías aplicar en tu solución, deberías revisar el SLA de cada una de los componentes y servicios que componen tu solución y dependiendo de los costos que una baja pudieran tener tanto en perdidas de utilidades como en multas por conceptos legales tomar una decisión.
Ref SLA: https://cloud.google.com/terms/sla
Felicitaciones, ya sabes, qué es, cómo y cuándo implementar Alta Disponibilidad en Google Cloud :)
Conclusiones Finales
- La Alta Disponibilidad permite asegurar la continuidad operacional durante un periodo de tiempo.
- Existen las soluciones sin alta disponibilidad, con alta disponibilidad zonal y alta disponibilidad regional.
- Cada una de estas soluciones requieren de un menor o mayor esfuerzo técnico y costo de la solución.
- Para soluciones no autoadministradas, es necesario tanto implementar la solución técnica como considerar el costo monetario.
- Para soluciones autoadministrados, solamente es necesario considerar el costo monetario.
- En base a estos factores y al costo que puede significar tanto en perdidas de utilidades o multas asociadas, es que deberías considerar que nivel de SLA necesitas para tu solución.
Espero que esta información les sea de utilidad para poder desarrollar soluciones resilientes en Google Cloud Platform.