Konfigurieren
Um diese automatisierte Failover-Lösung bereitzustellen, müssen Sie den Load Balancer konfigurieren, Alarme und Benachrichtigungen einrichten, eine Funktion erstellen und OCI API Gateway konfigurieren.
Im Folgenden werden die folgenden Schritte beschrieben:
- Der Prozess beginnt mit der Vorbereitung des Load Balancers. Dazu müssen sekundäre Listener und ein bestimmtes Regelset festgelegt werden, um das Umleitungsverhalten zu steuern.
- Konfigurieren Sie anschließend einen Alarm und eine Benachrichtigung, um eine Aktion auszulösen, wenn sich alle Anwendungsserver in einem fehlerhaften Status befinden und fehlerfreie Server verfügbar werden.
- Anschließend aktivieren Sie die Core-Automatisierung, indem Sie eine Fuction mit OCI Functions bereitstellen, die das Anhängen oder Trennen des Regelsets des Load Balancers basierend auf dem aktuellen Alarmstatus programmgesteuert steuert.
- Konfigurieren Sie OCI API Gateway schließlich so, dass Ihre benutzerdefinierte statische Wartungsseite gehostet wird.
Jede dieser Konfigurationen spielt eine spezifische und integrierte Rolle bei der Ermöglichung eines nahtlosen, automatisierten Failovers auf eine benutzerfreundliche Wartungsseite.
Load-Balancer konfigurieren
Die Grundlage dieser Lösung liegt im Load Balancer, der die Anwendung bereits vorstellt und den Datenverkehr auf die Backend-Server verteilt. Bei diesen Schritten wird davon ausgegangen, dass die meisten Deployment-Voraussetzungen bereits vorhanden sind, darunter ein Anwendungs-Listener (HTTP oder HTTPS), ein Backend-Set mit konfigurierten Health Checks und das Routing über ein Internetgateway, damit Benutzer den Service erreichen können.
Beginnen Sie mit einem primären Listener auf dem Load Balancer, der für die Verarbeitung von regulärem Traffic zur Anwendung konfiguriert ist. Wenn alles normal funktioniert, leitet dieser Listener eingehende Anforderungen an das Backend-Set der VM-Instanzen weiter. Es überwacht Standardports (HTTP/80 oder HTTPS/443), und Health Checks stellen sicher, dass nur fehlerfreie VMs Traffic empfangen.
Um die Wartungsseite zu bedienen, fügen Sie dem Load Balancer einen zweiten Listener hinzu. Im Gegensatz zum Anwendungs-Listener leitet dieser keine Anforderungen an die Anwendungsserver weiter. Stattdessen verweist das Backend-Set auf eine OCI API Gateway-Instanz, die für das Hosting der statischen Fehlerseite verantwortlich ist. Durch diese Trennung wird sichergestellt, dass der Load Balancer auch dann eine Branding- und informative Wartungsseite über das hochverfügbare API-Gateway anzeigen kann, wenn alle Anwendungsserver heruntergefahren sind. Die Erstellung der sekundären Listener- und API-Gateway-Schritte ist optional: Die Wartungsseite kann überall im Internet gehostet werden.
Die Übergabe zwischen diesen beiden Listenern wird über eine Regelgruppe verwaltet. Das Regelset ist dem Anwendungs-Listener zugeordnet und definiert die Bedingungen, unter denen Traffic umgeleitet werden soll. Unter normalen Umständen sendet der Listener Traffic direkt an die Anwendungsserver. Wenn die Anwendungsserver jedoch ihre Health Checks nicht erfolgreich ausführen, wird die Regelgruppe verwendet. Er weist den Load Balancer an, Traffic an den Wartungs-Listener umzuleiten, der wiederum die benutzerdefinierte Seite bedient, die im API-Gateway gehostet wird.
In den folgenden Schritten wird beschrieben, wie Sie das Regelset erstellen, das zum Umleiten von Benutzern zur Verwaltungsseite verwendet wird.
Info über Alarme
Ein Alarm fungiert als Brücke zwischen Erkennung und Aktion.
OCI Monitoring überwacht die Zustandsmetriken der Komponenten Ihres Deployments, einschließlich des Load Balancers, einschließlich des Status des Backend-Sets von VMs. Wenn eine Alarmbedingung, die Sie in OCI-Alarmen konfiguriert haben, erfüllt ist (z.B. alle überwachten VMs, die länger als eine Minute fehlerhaft sind), wird sofort eine Benachrichtigung ausgelöst. Diese Benachrichtigung gilt nicht nur für menschliche Administratoren. Sie können sie über OCI-Benachrichtigungen weiterleiten, um eine benutzerdefinierte Funktion aufzurufen, die mit OCI Functions bereitgestellt ist. Mit dieser Funktion wird die Load-Balancer-Konfiguration so geändert, dass die benutzerdefinierte Fehlerseite angezeigt wird.
Die Benachrichtigungsnachricht, die an die Funktion gesendet wird, enthält Dimensionen – Schlüssel/Wert-Paare, die beschreiben, zu welcher Ressource und welchem Backend-Set von VMs das Metrikereignis gehört.
Im Hauptteil Ihrer Alarmkonfiguration wird der folgende Code eingefügt:
{{dimensions.resourceId}},{{dimensions.backendSetName}},<name of the ruleset>
In dieser Tabelle werden die Komponenten dieses Alarmbodys beschrieben:
| Element | Beschreibung | Zweck |
|---|---|---|
{{dimensions.resourceId}} |
Die OCID der Load-Balancer-Ressource, die das Metrikereignis generiert hat | Die Funktion verwendet diese OCID, um zu identifizieren, welcher Load Balancer das Regelsetupdate benötigt |
{{dimensions.backendSetName}} |
Der Name des Backend-Sets, das fehlerhaft war | Die Funktion kann validieren oder protokollieren, welches Backend-Set nicht erfolgreich war. Nützlich für dynamische Umgebungen mit mehreren Backend-Sets |
<name of the ruleset> |
Ein statischer Wert (Zeichenfolge) – der Name des Regelsets, das angehängt werden soll, wenn alle Backends fehlerhaft sind | Lassen Sie die Funktion wissen, welche Regelgruppe beim Auslösen angewendet werden soll |
Mit diesem Design können Sie dieselbe Funktion wiederverwenden, um Aufgaben wie die Konfiguration eines Load Balancers zur Anzeige der Serverwartungsseite und das Zurückleiten von Traffic an die echte Anwendung zu bewältigen, sobald Services wiederhergestellt wurden. Dieser Ansatz kann auch angewendet werden, um alle Load Balancer oder Anwendungen auf Load Balancern in Ihrem OCI-Deployment zu verwalten.
Der OCI Load Balancer-Service veröffentlicht automatisch eine Metrik namens Unhealthybackendserver im Namespace oci_lbaas. Es verfolgt die Anzahl der fehlerhaften Backends in jedem Backend-Set.
Für die Zwecke dieser Lösung sind folgende wichtige Elemente in dieser Metrik:
- Beschreibung
- Dimensionen
- Triger-Regel
- Nachrichtengruppierung
In dieser Lösung sollte der Alarm ausgelöst werden, wenn alle Backend-Server (VMs) fehlerhaft werden. Das bedeutet, dass die Anzahl fehlerhafter Server größer oder gleich der Gesamtanzahl der Backend-Server im Set sein muss.
Beispiel für eine Abfrage der Alarm-Trigger-Regel:
UnHealthyBackendServers[1m]{lbName = <name of lb>, backendSetName = <name of the backend set>}.max() >= 1Die Abfrage wird wie folgt übersetzt:
- Wenn die maximale Anzahl fehlerhafter Backends größer oder gleich einem bestimmten Wert ist (in diesem Beispiel 1)
- Für einen definierten Zeitraum von 1 Minute.
- Dann geht der Alarm in den Status
FIRINGüber.
Diese dynamische Auffüllung von Werten funktioniert jedoch nur, wenn unter der Nachrichtengruppierung die Option Benachrichtigung teilen aktiviert ist. Die Split-Benachrichtigung zwingt OCI, eine Benachrichtigung pro Dimensionswert zu senden, anstatt alles zusammen zu gruppieren. Aus diesem Grund enthält die Alarmbenachrichtigung, die Ihre benutzerdefinierte Funktion erreicht, die genaue Load-Balancer-OCID und den genauen Namen des Backend-Sets, in dem der Fehler aufgetreten ist. Infolgedessen kann dieselbe Funktion vollständig für mehrere Load Balancer, Backend-Sets oder Umgebungen wiederverwendet werden, ohne Hardcoding-Load-Balancer-Details.
Mit dieser Konfiguration kann die gesamte Automatisierungskette funktionieren – der Alarm veröffentlicht dynamischen Kontext, die Funktion liest ihn und führt den richtigen regelbasierten Anhang auf dem exakten Listener aus, der die Anwendung dem Endbenutzer bereitstellt.
Alarme und Benachrichtigungen konfigurieren
Führen Sie den folgenden Schritt aus, um den Alarm und die Benachrichtigung für diese Lösung zu konfigurieren.
Funktion erstellen
Im Mittelpunkt der Automatisierung steht eine Funktion, die ausgelöst wird, wenn der Alarm erkennt, dass alle Anwendungs-Backends fehlerhaft sind.
Die Rolle der Funktion ist einfach und dennoch leistungsstark: Sie aktualisiert die Load-Balancer-Konfiguration dynamisch, indem sie das Regelset anhängt oder trennt, das die Trafficumleitung verarbeitet.
Der Python-Code innerhalb der Funktion folgt drei logischen Schritten:
- Authentifizierung mit OCI: Die Funktion beginnt mit der Einrichtung einer sicheren Session mit OCI mit dem Resource Principal (auf diese Weise können Funktionen in OCI andere OCI-Services aufrufen, ohne Schlüssel manuell zu verwalten). Dadurch wird sichergestellt, dass der Code sicher mit dem Load Balancer-Service interagieren kann. Weitere Informationen zur Authentifizierung finden Sie über die Links unter "Weitere Informationen".
- API-Aufruf zum Ändern des Load Balancer Listeners: Nach der Authentifizierung ruft der Code die Load-Balancer-API auf.
- Wenn die Backends nicht erfolgreich sind, hängt die Funktion das Umleitungsregelset an den Anwendungs-Listener an und leitet Benutzer zur benutzerdefinierten Fehlerseite um.
- Wenn die Backends wiederhergestellt werden, trennt die Funktion die Regelliste und stellt den normalen Verkehrsfluss zu den Anwendungsservern wieder her.
- Logging und Validierung: Der Code umfasst auch einfaches Logging, damit Administratoren verfolgen können, welche Aktion ausgeführt wurde. Beispiel: "Angehängtes Maintenance-Page-Regelset an listener-1". Dies wird bei der Fehlerbehebung oder bei Audits äußerst nützlich.
Verwenden Sie den folgenden Python-Beispielcode, um Ihre Funktion in Oracle Functions zu erstellen und sie nach Bedarf zu ändern.
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
OCI-API-Gateway konfigurieren
In dieser Lösung ist das OCI-API-Gateway so konfiguriert, dass eine statische Webseite direkt bereitgestellt wird.
Hinweis:
Die Verwendung von OCI API Gateway ist optional: Sie können auch Ihre Wartungs-/Fehlerseite außerhalb von OCI hosten.Im Gegensatz zur typischen Verwendung von OCI-API-Gateway, bei der Anforderungen an dynamische Backends wie Funktionen oder Compute-Instanzen weitergeleitet werden, nutzt dieser Ansatz die Fähigkeit von OCI-API-Gateway, eine statische Antwort zu hosten. Diese statische Seite dient als benutzerfreundliche Wartungsmeldung und informiert Benutzer darüber, dass der Service aufgrund geplanter Wartungsarbeiten oder anderer Probleme vorübergehend nicht verfügbar ist. Die statische Seite wird vollständig von OCI API Gateway verwaltet, sodass keine zusätzliche Infrastruktur wie Webserver oder Objektspeicher erforderlich ist.
Wenn das System erkennt, dass alle Backend-Server fehlerhaft sind, reagiert die vom Alarm ausgelöste Funktion, indem der Load Balancer so konfiguriert wird, dass der Traffic an den sekundären Listener umgeleitet wird, der die OCI API Gateway-Instanz abschließt. So wird eine nahtlose und benutzerfreundliche Erfahrung gewährleistet, ohne Standardseiten für Fehlerseiten verfügbar zu machen.
In diesem Beispiel konzentrieren Sie sich nur auf die Schritte, die zum Konfigurieren einer statischen Antwort mit OCI-API-Gateway erforderlich sind. Weitere Informationen finden Sie in den Ressourcen unter "Mehr erfahren".