Configura
Per distribuire questa soluzione di failover automatizzato, devi configurare il load balancer, impostare allarmi e notifiche, creare una funzione e configurare il gateway API OCI.
Di seguito sono riportati i passaggi seguenti:
- Il processo inizia con la preparazione del load balancer, che richiede l'impostazione di listener secondari e di un set di regole specifico per controllare il funzionamento del reindirizzamento.
- Di seguito, configurare un allarme e una notifica per attivare l'azione quando gli application server sono tutti in cattivo stato e quando i server in buono stato diventano disponibili.
- È quindi possibile abilitare l'automazione di base distribuendo una fuction utilizzando le funzioni OCI, che controllano a livello di programmazione il collegamento o lo scollegamento del set di regole del load balancer in base allo stato di allarme corrente.
- Infine, configurare OCI API Gateway per ospitare la pagina di manutenzione statica personalizzata.
Ognuna di queste configurazioni svolge un ruolo specifico e integrato nel consentire il failover senza interruzioni e automatizzato a una pagina di manutenzione intuitiva.
Configurare il Load Balancer
La base di questa soluzione risiede nel load balancer, che si trova già di fronte all'applicazione e distribuisce il traffico tra i suoi server backend. Questi passi presuppongono che la maggior parte dei prerequisiti di distribuzione siano già presenti, tra cui un listener delle applicazioni (HTTP o HTTPS), un set backend con controlli dello stato configurati e l'instradamento tramite un gateway Internet in modo che gli utenti possano raggiungere il servizio.
Iniziare con un listener primario nel load balancer, configurato per gestire il traffico regolare verso l'applicazione. Quando tutto funziona normalmente, questo listener instrada le richieste in entrata al set backend delle istanze VM. Ascolta le porte standard (HTTP/80 o HTTPS/443) e i controlli dello stato garantiscono che solo le VM in buono stato ricevano traffico.
Per servire la pagina di manutenzione, aggiungere un secondo listener nel load balancer. A differenza del listener dell'applicazione, questo non inoltra le richieste agli Application Server. Invece, il suo set backend punta a un'istanza di OCI API Gateway, responsabile dell'hosting della pagina di errore statico. Questa separazione garantisce che, anche se tutti gli application server sono inattivi, il load balancer possa comunque presentare una pagina di manutenzione brandizzata e informativa tramite il gateway API ad alta disponibilità. La creazione dei passi del listener secondario e del gateway API è facoltativa: la pagina di manutenzione può essere ospitata ovunque su Internet.
Il passaggio di consegne tra questi due listener viene gestito tramite un set di regole. Il set di regole è collegato al listener dell'applicazione e definisce le condizioni in base alle quali il traffico deve essere reindirizzato. In circostanze normali, il listener invia il traffico direttamente agli Application Server. Tuttavia, quando gli Application Server non superano i controlli dello stato, il set di regole entra in gioco. Dice al load balancer di reindirizzare il traffico al listener di manutenzione, che a sua volta serve la pagina personalizzata ospitata nel gateway API.
I passi riportati di seguito descrivono come creare il set di regole utilizzato per reindirizzare gli utenti alla pagina di manutenzione.
Informazioni sugli allarmi
Un allarme funge da ponte tra rilevamento e azione.
OCI Monitoring ascolta le metriche di stato dei componenti della distribuzione, incluso il load balancer, incluso lo stato del set backend delle VM. Quando viene soddisfatta una condizione di allarme configurata negli allarmi OCI (ad esempio, tutte le VM monitorate non sono in buono stato per più di un minuto), viene immediatamente attivata una notifica. Questa notifica non è solo per gli amministratori umani. È possibile instradarlo tramite Notifiche OCI per richiamare una funzione personalizzata distribuita con Funzioni OCI. Tale funzione agisce per modificare la configurazione del load balancer e visualizzare la pagina di errore personalizzata.
Il messaggio di notifica inviato alla funzione contiene dimensioni, ovvero coppie chiave-valore che descrivono a quale risorsa e a quale set backend di VM appartiene l'evento di metrica.
Nel corpo della configurazione dell'allarme, includerai il seguente codice:
{{dimensions.resourceId}},{{dimensions.backendSetName}},<name of the ruleset>
Questa tabella descrive i componenti del corpo dell'allarme:
| Elemento | Descrizione | Scopo |
|---|---|---|
{{dimensions.resourceId}} |
OCID della risorsa load balancer che ha generato l'evento metrica | La funzione utilizza questo OCID per identificare il load balancer che richiede l'aggiornamento del set di regole |
{{dimensions.backendSetName}} |
Nome del set backend non in buono stato | La funzione può convalidare o registrare il set backend non riuscito; utile per gli ambienti dinamici con più set backend |
<name of the ruleset> |
Un valore statico (stringa): il nome del set di regole da collegare quando tutti i backend sono in cattivo stato | Indica alla funzione il set di regole da applicare all'attivazione |
Questa progettazione consente di riutilizzare la stessa funzione per gestire task quali la configurazione di un load balancer per visualizzare la pagina di manutenzione del server e l'instradamento del traffico all'applicazione reale una volta ripristinati i servizi. Questo approccio può essere applicato anche per gestire tutti i load balancer o le applicazioni sui load balancer in tutta la distribuzione OCI.
Il servizio OCI Load Balancer pubblica automaticamente una metrica denominata Unhealthybackendserver nello spazio di nomi oci_lbaas. Tiene traccia del numero di backend in cattivo stato in ogni set backend.
Ai fini di questa soluzione, gli elementi importanti di questo parametro sono:
- Descrizione
- Dimensioni
- Regola del triger
- Raggruppamento messaggi
In questa soluzione, l'allarme dovrebbe attivarsi quando tutti i server backend (VM) diventano in cattivo stato. Ciò significa che il conteggio dei server non in buono stato deve essere maggiore o uguale al numero totale di server backend nel set.
Di seguito è riportata una query di esempio della regola di attivazione allarme.
UnHealthyBackendServers[1m]{lbName = <name of lb>, backendSetName = <name of the backend set>}.max() >= 1La query si traduce nei seguenti elementi:
- Se il numero massimo di backend in cattivo stato è maggiore o uguale a un valore specifico (in questo esempio, 1)
- Per un periodo definito di 1 minuto.
- Quindi l'allarme passa allo stato
FIRING.
Tuttavia, questa popolazione dinamica di valori funziona solo quando l'opzione Notifica di divisione è abilitata nel raggruppamento dei messaggi. La notifica di divisione obbliga OCI a inviare una notifica per valore di dimensione, invece di raggruppare tutto insieme. Per questo motivo, la notifica di allarme che raggiunge la funzione personalizzata contiene l'OCID esatto del load balancer e il nome esatto del set backend in cui si è verificato l'errore. Di conseguenza, la stessa funzione diventa completamente riutilizzabile tra più load balancer, set backend o ambienti, senza dettagli del load balancer di codifica.
Questa configurazione consente all'intera catena di automazione di funzionare: l'allarme pubblica il contesto dinamico, la funzione lo legge ed esegue il collegamento corretto del set di regole sul listener esatto che serve l'applicazione all'utente finale.
Configurare allarmi e notifiche
Eseguire il passo riportato di seguito per configurare l'allarme e la notifica per questa soluzione.
Creare una funzione
Al centro dell'automazione si trova una funzione, che viene attivata ogni volta che l'allarme rileva che tutti i backend delle applicazioni sono malsani.
Il ruolo della funzione è semplice ma potente: aggiorna dinamicamente la configurazione del load balancer collegando o scollegando il set di regole che gestisce il reindirizzamento del traffico.
Il codice Python all'interno della funzione segue tre passaggi logici:
- Autenticazione con OCI: la funzione inizia stabilendo una sessione sicura con OCI utilizzando il principal risorsa (questo è il modo in cui alle funzioni in OCI è consentito chiamare altri servizi OCI senza gestire manualmente le chiavi). Ciò garantisce che il codice possa interagire in tutta sicurezza con il servizio Load Balancer. Per ulteriori informazioni sull'autenticazione, fare riferimento ai collegamenti disponibili in Esplora altri argomenti.
- Chiamata API per modificare il listener del load balancer: una volta autenticato, il codice effettua una chiamata all'API del load balancer.
- Se i backend non riescono, la funzione allega il set di regole di reindirizzamento al listener dell'applicazione, reindirizzando gli utenti alla pagina di errore personalizzata.
- Se i backend vengono recuperati, la funzione scollega il set di regole, ripristinando il normale flusso di traffico agli Application Server.
- Log e convalida: il codice include anche il log semplice in modo che gli amministratori possano tenere traccia dell'azione intrapresa, ad esempio "Set di regole della pagina di manutenzione collegata a listener-1". Ciò diventa estremamente utile durante la risoluzione dei problemi o gli audit.
Utilizzare il codice Python di esempio riportato di seguito per creare la funzione in Oracle Functions, modificandola in base alle esigenze.
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
Configura OCI API Gateway
In questa soluzione, OCI API Gateway è configurato per servire direttamente una pagina Web statica.
Nota
L'uso di OCI API Gateway è facoltativo: potresti anche ospitare la pagina di manutenzione/errore all'esterno di OCI.A differenza dell'uso tipico di OCI API Gateway in cui le richieste vengono instradate a backend dinamici come funzioni o istanze di computazione, questo approccio sfrutta la capacità di OCI API Gateway di ospitare una risposta statica. Questa pagina statica funge da messaggio di manutenzione descrittivo, informando gli utenti che il servizio è temporaneamente non disponibile a causa della manutenzione pianificata o di altri problemi. La pagina statica è completamente gestita da OCI API Gateway, eliminando la necessità di un'infrastruttura aggiuntiva come i server Web o lo storage degli oggetti.
Quando il sistema rileva che tutti i server backend non sono integri, la funzione attivata dall'allarme risponderà configurando il load balancer per reindirizzare il traffico al listener secondario che esegue il front-end dell'istanza del gateway API OCI, garantendo un'esperienza fluida e intuitiva senza esporre le pagine di errore predefinite.
In questo esempio si è concentrati solo sui passi necessari per configurare una risposta statica utilizzando OCI API Gateway. Per ulteriori informazioni, esaminare le risorse disponibili in Esplora altri argomenti.