Configurar
Para desplegar esta solución de failover automatizada, debe configurar el equilibrador de carga, configurar alarmas y notificaciones, crear una función y configurar OCI API Gateway.
Los siguientes pasos se detallan a continuación:
- El proceso comienza con la preparación del equilibrador de carga, que requiere definir listeners secundarios y un juego de reglas específico para controlar el comportamiento de redirección.
- A continuación, configure una alarma y una notificación para disparar una acción cuando todos los servidores de aplicaciones se encuentren en un estado en mal estado y cuando haya servidores en buen estado disponibles.
- A continuación, puede activar la automatización del núcleo desplegando una función mediante OCI Functions, que controla mediante programación la asociación o desasociación del juego de reglas del equilibrador de carga en función del estado de alarma actual.
- Por último, configure OCI API Gateway para alojar la página de mantenimiento estático personalizada.
Cada una de estas configuraciones desempeña un papel específico e integrado al permitir la conmutación por error automatizada y sin problemas en una página de mantenimiento sencilla.
Configurar el equilibrador de carga
La base de esta solución reside en el equilibrador de carga, que ya utiliza la aplicación y distribuye el tráfico entre los servidores backend. En estos pasos se supone que la mayoría de los requisitos de despliegue ya están en vigor, incluido un listener de aplicación (HTTP o HTTPS), un juego de backends con comprobaciones del sistema configuradas y el enrutamiento a través de un gateway de Internet para que los usuarios puedan acceder al servicio.
Comience con un listener principal en el equilibrador de carga, configurado para manejar el tráfico normal a la aplicación. Cuando todo funciona normalmente, este listener direcciona las solicitudes entrantes al juego de backends de instancias de VM. Escucha en puertos estándar (HTTP/80 o HTTPS/443) y las comprobaciones de estado garantizan que solo las máquinas virtuales en buen estado reciban tráfico.
Para servir la página de mantenimiento, agregue un segundo listener en el equilibrador de carga. A diferencia del listener de aplicación, este no reenvía solicitudes a los servidores de aplicaciones. En su lugar, su juego de backends apunta a una instancia de OCI API Gateway, que es responsable de alojar la página de error estática. Esta separación garantiza que, incluso si todos los servidores de aplicaciones están caídos, el equilibrador de carga pueda seguir presentando una página de mantenimiento con marca e informativa a través del gateway de API de alta disponibilidad. La creación del listener secundario y los pasos del gateway de API son opcionales: la página de mantenimiento se puede alojar en cualquier lugar de Internet.
La transferencia entre estos dos listeners se gestiona mediante un juego de reglas. El juego de reglas está asociado al listener de la aplicación y define las condiciones en las que se debe redirigir el tráfico. En circunstancias normales, el listener envía tráfico directamente a los servidores de aplicaciones. Sin embargo, cuando los servidores de aplicaciones no realizan las comprobaciones del sistema, el juego de reglas entra en juego. Indica al equilibrador de carga que redirija el tráfico al listener de mantenimiento, que a su vez sirve la página personalizada alojada en el gateway de API.
En los siguientes pasos se describe cómo crear el juego de reglas utilizado para redirigir a los usuarios a la página de mantenimiento.
Acerca de las alarmas
Una alarma actúa como un puente entre la detección y la acción.
OCI Monitoring escucha las métricas de estado de los componentes del despliegue, incluido el equilibrador de carga, incluido el estado del juego de backends de máquinas virtuales. Cuando se cumple una condición de alarma configurada en las alarmas de OCI (por ejemplo, todas las máquinas virtuales supervisadas no están en buen estado durante más de un minuto), se dispara inmediatamente una notificación. Esta notificación no es solo para administradores humanos. Puede enrutarlo a través de OCI Notifications para llamar a una función personalizada desplegada con OCI Functions. Esa función actúa para cambiar la configuración del equilibrador de carga para mostrar la página de error personalizada.
El mensaje de notificación enviado a la función contiene dimensiones: pares clave-valor que describen a qué recurso y a qué juego de backends de máquinas virtuales pertenece el evento de métrica.
En el cuerpo de la configuración de la alarma, incluirá el siguiente código:
{{dimensions.resourceId}},{{dimensions.backendSetName}},<name of the ruleset>
En esta tabla, se describen los componentes de este cuerpo de alarma:
| Concepto | Descripción | Finalidad |
|---|---|---|
{{dimensions.resourceId}} |
OCID del recurso del equilibrador de carga que ha generado el evento de métrica | La función utiliza este OCID para identificar qué equilibrador de carga necesita la actualización del juego de reglas |
{{dimensions.backendSetName}} |
El nombre del juego de backends que no está en buen estado | La función puede validar o registrar qué juego de backends ha fallado; útil para entornos dinámicos con varios juegos de backends |
<name of the ruleset> |
Un valor estático (cadena): el nombre del juego de reglas que se va a asociar cuando todos los backends no estén en buen estado | Permite a la función saber qué juego de reglas se aplicará cuando se dispare |
Este diseño permite reutilizar la misma función para manejar tareas como la configuración de un equilibrador de carga para mostrar la página de mantenimiento del servidor y enrutar el tráfico de vuelta a la aplicación real una vez que se restauran los servicios. Este enfoque también se puede aplicar para gestionar todos los equilibradores de carga o aplicaciones en equilibradores de carga en su despliegue de OCI.
El servicio OCI Load Balancer publica automáticamente una métrica denominada Unhealthybackendserver en el espacio de nombres oci_lbaas. Realiza un seguimiento del número de backends en mal estado en cada juego de backends.
Para esta solución, los elementos importantes de esta métrica son:
- Descripción
- Dimensiones
- Regla de Triger
- Agrupamiento de mensajes
En esta solución, la alarma se debe disparar cuando todos los servidores backend (VM) dejen de estar en buen estado. Esto significa que el recuento de servidores en mal estado debe ser mayor o igual que el número total de servidores backend del juego.
A continuación se muestra un ejemplo de consulta de regla de disparador de alarma:
UnHealthyBackendServers[1m]{lbName = <name of lb>, backendSetName = <name of the backend set>}.max() >= 1La consulta se traduce en lo siguiente:
- Si el número máximo de backends en mal estado es mayor o igual que un valor específico (en este ejemplo, 1)
- Durante un período definido de 1 minuto.
- Luego, la alarma pasa al estado
FIRING.
Sin embargo, este grupo dinámico de valores solo funciona cuando la opción Notificación de división está activada en la agrupación de mensajes. La notificación dividida obliga a OCI a enviar una notificación por valor de dimensión, en lugar de agrupar todo. Por este motivo, la notificación de alarma que llega a la función personalizada contiene el OCID exacto del equilibrador de carga y el nombre exacto del juego de backends en el que se ha producido el fallo. Como resultado, la misma función se puede reutilizar por completo en varios equilibradores de carga, juegos de backends o entornos, sin tener que codificar los detalles del equilibrador de carga.
Esta configuración permite que funcione toda la cadena de automatización: la alarma publica el contexto dinámico, la función lo lee y realiza la asociación correcta del juego de reglas en el listener exacto que está sirviendo a la aplicación al usuario final.
Configuración de alarmas y notificaciones
Realice el siguiente paso para configurar la alarma y la notificación para esta solución.
Crear una función
En el corazón de la automatización se encuentra una función, que se activa cada vez que la alarma detecta que todos los backends de aplicaciones no son saludables.
El rol de la función es sencillo pero potente: actualiza dinámicamente la configuración del equilibrador de carga asociando o desasociando el juego de reglas que gestiona la redirección de tráfico.
El código Python dentro de la función sigue tres pasos lógicos:
- Autenticación con OCI: la función comienza estableciendo una sesión segura con OCI mediante la entidad de recurso (así se permite que las funciones de OCI llamen a otros servicios de OCI sin gestionar manualmente las claves). Esto garantiza que el código pueda interactuar de forma segura con el servicio Load Balancer. Para obtener más información sobre la autenticación, consulte los enlaces en Explorar más.
- Llamada de API para modificar el listener del equilibrador de carga: una vez autenticado, el código realiza una llamada a la API del equilibrador de carga.
- Si los backends fallan, la función asocia el juego de reglas de redirección al listener de aplicación y redirige a los usuarios a la página de error personalizada.
- Si los backends se recuperan, la función desasocia el juego de reglas y restaura el flujo de tráfico normal en los servidores de aplicaciones.
- Registro y Validación: el código también incluye un registro simple para que los administradores puedan realizar un seguimiento de la acción realizada: por ejemplo, "Juego de Reglas de Página de Mantenimiento Asociado al Listener-1". Esto resulta extremadamente útil durante la resolución de problemas o las auditorías.
Utilice el siguiente código Python de ejemplo para crear la función en Oracle Functions y modificarla según sea necesario.
Function.py
import io
import json
import os
import oci
from fdk import response
import logging
def handler(ctx, data: io.BytesIO=None):
message = "start of function"
logging.getLogger().info("HTTP function start")
try:
payload_bytes = data.getvalue()
if payload_bytes == b'':
raise KeyError('No keys in payload')
body1 = json.loads(payload_bytes)
type1 = body1["type"]
query = body1["body"]
load_balancer_ocid = query.split(",")[0]
maintenance = query.split(",")[2]
signer = oci.auth.signers.get_resource_principals_signer()
load_balancer_client = oci.load_balancer.LoadBalancerClient(config={}, signer=signer)
load_balancer_client_composite_ops = oci.load_balancer.LoadBalancerClientCompositeOperations(load_balancer_client)
load_balancer_data = json.loads(str(load_balancer_client.get_load_balancer(load_balancer_ocid).data))
lb_config = load_balancer_data['listeners']
list1 = json.dumps(lb_config)
for key,value in json.loads(list1).items():
if value['default_backend_set_name'] == query.split(",")[1]:
f_list = key
rulesets = value['rule_set_names']
if type1=="OK_TO_FIRING":
message = "FIRE"
if maintenance in rulesets:
message = "Already in Maintenance Mode"
logging.getLogger().info("Already in Manintenance mode")
else:
rulesets.insert(0, maintenance)
message = "Entering Maintenance Mode"
logging.getLogger().info("Entering Main mode")
load_balancer_client_composite_ops.update_listener_and_wait_for_state(
oci.load_balancer.models.UpdateListenerDetails(
default_backend_set_name=value["default_backend_set_name"],
rule_set_names=rulesets,
port=value["port"],
protocol=value["protocol"],
ssl_configuration=value["ssl_configuration"]
),
load_balancer_ocid,
key,
wait_for_states=[oci.load_balancer.models.WorkRequest.LIFECYCLE_STATE_SUCCEEDED]
)
elif type1=="FIRING_TO_OK":
message = "OK"
if maintenance in rulesets:
message = "Entering Operation Mode"
logging.getLogger().info("Entering Operation Mode")
rulesets.remove(maintenance)
load_balancer_client_composite_ops.update_listener_and_wait_for_state(
oci.load_balancer.models.UpdateListenerDetails(
default_backend_set_name=value["default_backend_set_name"],
rule_set_names=rulesets,
port=value["port"],
protocol=value["protocol"],
ssl_configuration=value["ssl_configuration"]
),
load_balancer_ocid,
key,
wait_for_states=[oci.load_balancer.models.WorkRequest.LIFECYCLE_STATE_SUCCEEDED]
)
else:
message = "Already in operation Mode"
logging.getLogger().info("Already in Operation mode")
except (Exception) as ex:
message = "Error:" + str(ex)
return message
Configurar gateway de API de OCI
En esta solución, el gateway de API de OCI está configurado para servir directamente una página web estática.
Note:
El uso de OCI API Gateway es opcional: también puede alojar la página de mantenimiento/error fuera de OCI.A diferencia del uso típico de OCI API Gateway, donde las solicitudes se direccionan a backends dinámicos, como funciones o instancias informáticas, este enfoque aprovecha la capacidad de OCI API Gateway para alojar una respuesta estática. Esta página estática actúa como un mensaje de mantenimiento fácil de recordar, informando a los usuarios de que el servicio no está disponible temporalmente debido al mantenimiento programado u otros problemas. La página estática está totalmente gestionada por OCI API Gateway, lo que elimina la necesidad de infraestructura adicional, como servidores web o almacenamiento de objetos.
Cuando el sistema detecta que todos los servidores backend no están en buen estado, la función disparada por la alarma responderá configurando el equilibrador de carga para redirigir el tráfico al listener secundario front-end de la instancia de Gateway de API de OCI, lo que garantiza una experiencia perfecta y fácil de usar sin exponer las páginas de error por defecto.
En este ejemplo, solo se centra en los pasos necesarios para configurar una respuesta estática mediante OCI API Gateway. Para obtener más información, revise los recursos en Explorar más.