Configurer
Pour déployer cette solution de basculement automatisé, vous devez configurer l'équilibreur de charge, configurer des alarmes et des notifications, créer une fonction et configurer OCI API Gateway.
Les étapes suivantes sont détaillées ci-dessous :
- Le processus commence par la préparation de l'équilibreur de charge, qui nécessite la définition de processus d'écoute secondaires et d'un ensemble de règles spécifique pour contrôler le comportement de redirection.
- Ensuite, configurez une alarme et une notification pour déclencher une action lorsque les serveurs d'applications sont tous en mauvais état et lorsque des serveurs en bon état sont disponibles.
- Vous activez ensuite l'automatisation de base en déployant une application fuction à l'aide d'OCI Functions, qui contrôle par programmation l'attachement ou le détachement de l'ensemble de règles de l'équilibreur de charge en fonction de l'état d'alarme en cours.
- Enfin, configurez OCI API Gateway pour héberger votre page de maintenance statique personnalisée.
Chacune de ces configurations joue un rôle spécifique et intégré pour permettre le basculement transparent et automatisé vers une page de maintenance conviviale.
Configurer l'équilibreur de charge
Cette solution repose sur l'équilibreur de charge, qui fait déjà face à l'application et distribue le trafic sur ses serveurs back-end. Ces étapes supposent que la plupart des prérequis de déploiement sont déjà en place, y compris un processus d'écoute d'application (HTTP ou HTTPS), un ensemble de back-ends avec des vérifications de l'état configurées et un routage via une passerelle Internet afin que les utilisateurs puissent atteindre le service.
Démarrez avec un processus d'écoute principal sur l'équilibreur de charge, configuré pour gérer le trafic régulier vers l'application. Lorsque tout fonctionne normalement, ce processus d'écoute achemine les demandes entrantes vers l'ensemble de back-ends des instances de machine virtuelle. Il écoute les ports standard (HTTP/80 ou HTTPS/443) et les vérifications de l'état garantissent que seules les machines virtuelles en bon état reçoivent le trafic.
Pour servir la page de maintenance, ajoutez un deuxième processus d'écoute sur l'équilibreur de charge. Contrairement au processus d'écoute d'application, celui-ci ne transmet pas les demandes aux serveurs d'applications. Au lieu de cela, son ensemble de back-ends pointe vers une instance OCI API Gateway, qui est responsable de l'hébergement de la page d'erreur statique. Cette séparation garantit que même si tous les serveurs d'applications sont arrêtés, l'équilibreur de charge peut toujours présenter une page de maintenance de marque et informative via la passerelle d'API hautement disponible. La création des étapes de processus d'écoute secondaire et de passerelle d'API est facultative : la page de maintenance peut être hébergée n'importe où sur Internet.
Le transfert entre ces deux processus d'écoute est géré via un ensemble de règles. L'ensemble de règles est attaché au processus d'écoute d'application et définit les conditions dans lesquelles le trafic doit être redirigé. Dans des circonstances normales, le processus d'écoute envoie le trafic directement aux serveurs d'applications. Toutefois, lorsque les serveurs d'applications échouent à leurs vérifications de l'état, l'ensemble de règles entre en jeu. Elle indique à l'équilibreur de charge de rediriger le trafic vers le processus d'écoute de maintenance, qui sert à son tour la page personnalisée hébergée dans la passerelle d'API.
Les étapes suivantes expliquent comment créer le jeu de règles utilisé pour rediriger les utilisateurs vers la page de maintenance.
A propos des alarmes
Une alarme sert de pont entre la détection et l'action.
OCI Monitoring écoute les mesures d'état des composants de votre déploiement, y compris l'équilibreur de charge, y compris le statut de l'ensemble de back-ends de machines virtuelles. Lorsqu'une condition d'alarme configurée dans les alarmes OCI est remplie (par exemple, toutes les machines virtuelles surveillées sont en mauvais état pendant plus d'une minute), une notification est immédiatement déclenchée. Cette notification n'est pas uniquement destinée aux administrateurs humains. Vous pouvez l'acheminer via OCI Notifications pour appeler une fonction personnalisée déployée avec OCI Functions. Cette fonction agit pour modifier la configuration de l'équilibreur de charge afin d'afficher la page d'erreur personnalisée.
Le message de notification envoyé à la fonction contient les dimensions (paires clé-valeur) qui décrivent la ressource et l'ensemble de back-ends de machines virtuelles auquel appartient l'événement de mesure.
Dans le corps de votre configuration d'alarme, vous incluez le code suivant :
{{dimensions.resourceId}},{{dimensions.backendSetName}},<name of the ruleset>
Ce tableau décrit les composants de ce corps d'alarme :
| Elément | Description | Description |
|---|---|---|
{{dimensions.resourceId}} |
OCID de la ressource d'équilibreur de charge qui a généré l'événement de mesure | La fonction utilise cet OCID pour identifier l'équilibreur de charge qui a besoin de la mise à jour du jeu de règles |
{{dimensions.backendSetName}} |
Nom de l'ensemble de back-ends en mauvais état | La fonction peut valider ou consigner l'ensemble de back-ends qui a échoué ; utile pour les environnements dynamiques avec plusieurs ensembles de back-ends |
<name of the ruleset> |
Valeur statique (chaîne) : nom de l'ensemble de règles à attacher lorsque tous les back-ends sont en mauvais état | Indiquez à la fonction le jeu de règles à appliquer lorsqu'il est déclenché |
Cette conception vous permet de réutiliser la même fonction pour gérer des tâches telles que la configuration d'un équilibreur de charge pour afficher la page de maintenance du serveur et le routage du trafic vers l'application réelle une fois les services restaurés. Cette approche peut également être appliquée pour gérer tous les équilibreurs de charge ou toutes les applications sur les équilibreurs de charge dans votre déploiement OCI.
Le service OCI Load Balancer publie automatiquement une mesure appelée Unhealthybackendserver dans l'espace de noms oci_lbaas. Il suit le nombre de back-ends en mauvais état dans chaque ensemble de back-ends.
Aux fins de cette solution, les éléments importants de cette métrique sont les suivants :
- Description
- Dimensions
- Règle de réfrigération
- Regroupement de messages
Dans cette solution, l'alarme doit se déclencher lorsque tous les serveurs back-end (VM) sont en mauvais état. Cela signifie que le nombre de serveurs en mauvais état doit être supérieur ou égal au nombre total de serveurs back-end dans l'ensemble.
Voici un exemple de requête de règle de déclencheur d'alarme :
UnHealthyBackendServers[1m]{lbName = <name of lb>, backendSetName = <name of the backend set>}.max() >= 1La requête se traduit par ce qui suit :
- Si le nombre maximum de back-ends en mauvais état est supérieur ou égal à une valeur spécifique (dans cet exemple, 1)
- Pour une période définie de 1 minute.
- L'alarme passe ensuite à l'état
FIRING.
Toutefois, cette population dynamique de valeurs ne fonctionne que lorsque l'option Fractionner la notification est activée dans le cadre du regroupement de messages. La notification de fractionnement force OCI à envoyer une notification par valeur de dimension, au lieu de tout regrouper. Par conséquent, la notification d'alarme qui atteint votre fonction personnalisée contient l'OCID exact de l'équilibreur de charge et le nom exact de l'ensemble de back-ends où l'échec s'est produit. Par conséquent, la même fonction devient entièrement réutilisable sur plusieurs équilibreurs de charge, ensembles de back-ends ou environnements, sans les détails de l'équilibreur de charge de codage en dur.
Cette configuration permet à l'ensemble de la chaîne d'automatisation de fonctionner : l'alarme publie le contexte dynamique, la fonction le lit et effectue l'attachement d'ensemble de règles correct sur le processus d'écoute exact qui sert l'application à l'utilisateur final.
Configurer des alarmes et des notifications
Effectuez l'étape suivante pour configurer l'alarme et la notification pour cette solution.
Créez une fonction
Au cœur de l'automatisation se trouve une fonction, qui est déclenchée chaque fois que l'alarme détecte que tous les back-ends d'application sont en mauvais état.
Le rôle de la fonction est simple mais puissant : il met à jour dynamiquement la configuration de l'équilibreur de charge en associant ou en détachant l'ensemble de règles qui gère la redirection du trafic.
Le code Python dans la fonction suit trois étapes logiques :
- Authentification avec OCI : la fonction commence par établir une session sécurisée avec OCI à l'aide du principal de ressource (les fonctions dans OCI sont autorisées à appeler d'autres services OCI sans gérer manuellement les clés). Ainsi, le code peut interagir en toute sécurité avec le service Load Balancer. Pour plus d'informations sur l'authentification, reportez-vous aux liens dans Explorer plus.
- Appel d'API permettant de modifier le processus d'écoute d'équilibreur de charge : une fois authentifié, le code effectue un appel vers l'API de l'équilibreur de charge.
- Si les back-ends échouent, la fonction associe l'ensemble de règles de redirection au processus d'écoute d'application, redirigeant les utilisateurs vers la page d'erreur personnalisée.
- Si les back-ends sont récupérés, la fonction dissocie l'ensemble de règles et restaure le flux de trafic normal vers les serveurs d'applications.
- Journalisation et validation : le code inclut également une journalisation simple afin que les administrateurs puissent suivre l'action effectuée : par exemple, "Règle de page de maintenance attachée définie sur listener-1". Cela devient extrêmement utile lors de la résolution des incidents ou des audits.
Utilisez l'exemple de code Python suivant pour créer votre fonction dans Oracle Functions, en la modifiant si nécessaire.
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
Configuration d'OCI API Gateway
Dans cette solution, la passerelle d'API OCI est configurée pour servir directement une page Web statique.
Remarques :
L'utilisation d'OCI API Gateway est facultative : vous pouvez également héberger votre page de maintenance/d'erreur en dehors d'OCI.Contrairement à l'utilisation standard d'OCI API Gateway où les demandes sont acheminées vers des back-ends dynamiques tels que des fonctions ou des instances de calcul, cette approche exploite la capacité d'OCI API Gateway à héberger une réponse statique. Cette page statique agit comme un message de maintenance convivial, informant les utilisateurs que le service est temporairement indisponible en raison d'une maintenance programmée ou d'autres problèmes. La page statique est entièrement gérée par OCI API Gateway, ce qui élimine la nécessité d'une infrastructure supplémentaire telle que des serveurs Web ou le stockage d'objets.
Lorsque le système détecte que tous les serveurs back-end sont en mauvais état, la fonction déclenchée par l'alarme répond en configurant l'équilibreur de charge pour rediriger le trafic vers le processus d'écoute secondaire en front-end de l'instance OCI API Gateway, ce qui garantit une expérience transparente et conviviale sans exposer les pages d'erreur par défaut.
Dans cet exemple, vous êtes uniquement axé sur les étapes requises pour configurer une réponse statique à l'aide d'OCI API Gateway. Pour plus d'informations, consultez les ressources dans Explorer plus.