Configurer
Pour déployer cette solution de basculement automatisé, vous devez configurer l'équilibreur de charge, configurer des alarmes et des avis, créer une fonction et configurer le service de passerelle d'API OCI.
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 modules d'écoute secondaires et d'un jeu 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 le statut des serveurs d'applications n'est pas sain et lorsque des serveurs sains deviennent disponibles.
- Vous activez ensuite l'automatisation de base en déployant une extraction à l'aide du service de fonctions pour OCI, qui contrôle par programmation l'attachement ou le détachement du jeu de règles de l'équilibreur de charge en fonction de l'état courant de l'alarme.
- Enfin, configurez le service de passerelle d'API OCI 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
La base de cette solution réside dans l'équilibreur de charge qui gère déjà l'application et répartit le trafic entre ses serveurs dorsaux. Ces étapes supposent que la plupart des préalables au déploiement sont déjà en place, notamment un module d'écoute d'application (HTTP ou HTTPS), un jeu dorsal avec des vérifications d'état configurées et un acheminement au moyen d'une passerelle Internet afin que les utilisateurs puissent accéder au service.
Commencez par un module d'écoute principal sur l'équilibreur de charge, configuré pour gérer le trafic régulier vers l'application. Lorsque tout fonctionne normalement, ce module d'écoute achemine les demandes entrantes vers le jeu dorsal des instances de machine virtuelle. Il écoute sur les ports standard (HTTP/80 ou HTTPS/443) et les vérifications d'état garantissent que seules les machines virtuelles saines reçoivent le trafic.
Pour accéder à la page de maintenance, ajoutez un deuxième module 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. Son jeu dorsal pointe plutôt vers une instance du service Passerelle d'API OCI, 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 en panne, l'équilibreur de charge peut toujours présenter une page de maintenance de marque et informative au moyen de la passerelle d'API hautement disponible. La création du module d'écoute secondaire et des étapes 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 modules d'écoute est géré au moyen d'un jeu de règles. Le jeu de règles est associé au module d'écoute de l'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 d'état, le jeu de règles entre en jeu. Il indique à l'équilibreur de charge de rediriger le trafic vers le module d'écoute de maintenance, qui à son tour sert la page personnalisée hébergée dans la passerelle d'API.
Les étapes suivantes décrivent comment créer le jeu de règles utilisé pour rediriger les utilisateurs vers la page de maintenance.
À propos des alarmes
Une alarme agit comme un pont entre la détection et l'action.
Le service Surveillance pour OCI écoute les mesures d'état des composants de votre déploiement, y compris l'équilibreur de charge, y compris le statut du jeu dorsal des machines virtuelles. Lorsqu'une condition d'alarme que vous avez configurée dans les alarmes OCI est satisfaite (par exemple, toutes les machines virtuelles surveillées ne fonctionnent pas pendant plus d'une minute), elle déclenche immédiatement un avis. Cette notification n'est pas uniquement destinée aux administrateurs humains. Vous pouvez l'acheminer au moyen du service Avis OCI pour appeler une fonction personnalisée déployée avec le service Fonctions OCI. Cette fonction agit pour modifier la configuration de l'équilibreur de charge afin d'afficher la page d'erreur personnalisée.
Le message d'avis envoyé à la fonction contient des dimensions, c'est-à-dire des paires clé-valeur qui décrivent quelle ressource et à quel jeu dorsal de machines virtuelles appartient l'événement de mesure.
Dans le corps de votre configuration d'alarme, vous inclurez le code suivant :
{{dimensions.resourceId}},{{dimensions.backendSetName}},<name of the ruleset>
Le tableau suivant décrit les composants de ce corps d'alarme :
| Élément | Description | Objet |
|---|---|---|
{{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 d'une mise à jour du jeu de règles |
{{dimensions.backendSetName}} |
Nom du jeu dorsal dont l'état est incorrect | La fonction peut valider ou consigner quel jeu dorsal a échoué; utile pour les environnements dynamiques comportant plusieurs jeux dorsaux |
<name of the ruleset> |
Une valeur statique (chaîne) — nom du jeu de règles à attacher lorsque tous les serveurs dorsaux ne sont pas sains | Indiquer à 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 applications sur les équilibreurs de charge dans l'ensemble de votre déploiement OCI.
Le service Équilibreur de charge OCI publie automatiquement une mesure nommée Unhealthybackendserver dans l'espace de noms oci_lbaas. Il assure le suivi du nombre de serveurs dorsaux peu sains dans chaque jeu dorsal.
Pour les besoins de cette solution, les éléments importants de cette mesure sont les suivants :
- Description
- Dimensions
- Règle de déclencheur
- Regroupement de messages
Dans cette solution, l'alarme doit se déclencher lorsque tous les serveurs dorsaux deviennent malsains. Cela signifie que le nombre de serveurs peu sains doit être supérieur ou égal au nombre total de serveurs dorsaux dans le jeu.
Voici un exemple d'interrogation de règle de déclenchement d'alarme :
UnHealthyBackendServers[1m]{lbName = <name of lb>, backendSetName = <name of the backend set>}.max() >= 1L'interrogation se traduit par ce qui suit :
- Si le nombre maximal de serveurs dorsaux peu sains est supérieur ou égal à une valeur spécifique (dans cet exemple, 1)
- Pour une période définie de 1 minute.
- Ensuite, l'alarme passe à l'état
FIRING.
Toutefois, cette population dynamique de valeurs ne fonctionne que lorsque l'avis de fractionnement est activé sous le regroupement de messages. La notification de fractionnement force OCI à envoyer un avis par valeur de dimension, au lieu de tout regrouper. Pour cette raison, l'avis d'alarme qui atteint votre fonction personnalisée contient l'OCID exact de l'équilibreur de charge et le nom exact du jeu dorsal où l'échec s'est produit. Par conséquent, la même fonction devient entièrement réutilisable dans plusieurs équilibreurs de charge, jeux dorsaux ou environnements, sans codage en dur des détails d'équilibreur de charge.
Cette configuration permet à toute la chaîne d'automatisation de fonctionner : l'alarme publie un contexte dynamique, la fonction le lit et exécute l'attachement de jeu de règles correct sur le module d'écoute exact qui dessert l'application à l'utilisateur final.
Configurer les alarmes et les avis
Effectuez l'étape suivante pour configurer l'alarme et l'avis pour cette solution.
Créer 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 serveurs dorsaux d'application ne sont pas sains.
Le rôle de la fonction est simple mais puissant : elle met à jour dynamiquement la configuration de l'équilibreur de charge en attachant ou en détachant le jeu de règles qui gère la redirection du trafic.
Le code Python à l'intérieur de la fonction suit trois étapes logiques :
- Authentification auprès d'OCI : La fonction commence par établir une session sécurisée avec OCI à l'aide du principal de ressource (c'est ainsi que les fonctions d'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 d'équilibreur de charge. Pour plus d'informations sur l'authentification, reportez-vous aux liens dans Explorer Plus.
- Appel d'API pour modifier le module d'écoute de l'équilibreur de charge : Une fois authentifié, le code effectue un appel à l'API de l'équilibreur de charge.
- Si les serveurs dorsaux échouent, la fonction associe le jeu de règles de redirection au module d'écoute de l'application, redirigeant les utilisateurs vers la page d'erreur personnalisée.
- Si les serveurs dorsaux se rétablissent, la fonction détache le jeu de règles, ce qui 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 Maintenance-Page attachée réglée à listener-1". Cela devient extrêmement utile lors du dépannage ou des audits.
Utilisez l'exemple de code Python suivant pour créer votre fonction dans Oracle Functions, en la modifiant selon les besoins.
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
Configurer le service de passerelle d'API pour OCI
Dans cette solution, le service de passerelle d'API OCI est configuré pour servir directement une page Web statique.
Note :
L'utilisation du service Passerelle d'API OCI est facultative : vous pouvez également héberger votre page de maintenance/erreur en dehors d'OCI.Contrairement à l'utilisation standard du service Passerelle d'API OCI où les demandes sont acheminées vers des serveurs dorsaux dynamiques tels que des fonctions ou des instances de calcul, cette approche tire parti de la capacité du service Passerelle d'API OCI à héberger une réponse statique. Cette page statique agit comme un message convivial de maintenance, 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 le service Passerelle d'API OCI, ce qui élimine le besoin d'infrastructure supplémentaire, comme les serveurs Web ou le stockage d'objets.
Lorsque le système détecte que tous les serveurs dorsaux ne sont pas sains, la fonction déclenchée par l'alarme répondra en configurant l'équilibreur de charge pour rediriger le trafic vers le module d'écoute secondaire frontal de l'instance du service de passerelle d'API OCI, ce qui garantit une expérience transparente et conviviale sans exposer les pages d'erreur par défaut.
Dans cet exemple, vous n'êtes concentré que sur les étapes requises pour configurer une réponse statique à l'aide du service de passerelle d'API OCI. Pour plus d'informations, consultez les ressources dans Explorer davantage.