Funzioni di Azure ripristino di emergenza geografico

Quando interi data center o aree di Azure si verificano tempi di inattività, il codice cruciale deve continuare l'elaborazione in un'area diversa. Questo articolo illustra alcune delle strategie che è possibile usare per distribuire le funzioni per consentire il ripristino di emergenza.

Concetti fondamentali

Funzioni di Azure in un'app per le funzioni in un'area specifica. Non è disponibile alcuna ridondanza incorporata. Per evitare la perdita di esecuzione durante le interruzioni, è possibile distribuire in modo ridondante le stesse funzioni nelle app per le funzioni in più aree.

Quando si esegue lo stesso codice di funzione in più aree, è necessario prendere in considerazione due modelli:

Modello Descrizione
Attivo/attivo Le funzioni in entrambe le aree eseguono ed elaborano attivamente gli eventi, in modo duplicato o in rotazione. È consigliabile usare un modello attivo/attivo in combinazione con Frontdoor di Azure per le funzioni critiche attivate da HTTP.
Attivo/passivo Le funzioni vengono eseguite attivamente nell'area che riceve eventi, mentre le stesse funzioni in una seconda area rimangono inattive. Quando è necessario il failover, la seconda area viene attivata e assume la proprietà dell'elaborazione. È consigliabile usare questo modello per le funzioni attivate non HTTP e guidate da eventi, ad esempio bus di servizio e le funzioni attivate dall'hub eventi.

Per altre informazioni sulle distribuzioni in più aree, vedere le linee guida in Applicazione Web in più aree a disponibilità elevata.

Ridondanza per le funzioni trigger HTTP

Il modello attivo/attivo è il modello di distribuzione migliore per le funzioni trigger HTTP. In questo caso, è necessario usare Frontdoor di Azure per coordinare le richieste tra entrambe le aree. Frontdoor di Azure possibile instradare e round robin le richieste HTTP tra le funzioni in esecuzione in più aree. Controlla inoltre periodicamente l'integrità di ogni endpoint. Quando una funzione in un'area smette di rispondere ai controlli di integrità, Frontdoor di Azure esce dalla rotazione e inoltra il traffico solo alle funzioni integre rimanenti.

Architettura per Frontdoor di Azure e funzione

Ridondanza per le funzioni trigger non HTTP

La ridondanza per le funzioni che utilizzano eventi di altri servizi richiede un modello diverso, che funziona con il modello di failover dei servizi correlati.

Ridondanza attiva/passiva per funzioni trigger non HTTP

Attivo/passivo consente a una sola funzione di elaborare ogni messaggio, ma fornisce un meccanismo per eseguire il failover in un'area secondaria in caso di emergenza. Le app per le funzioni funzionano con i comportamenti di failover dei servizi partner, ad esempio Azure bus di servizio ripristino geografico e Hub eventi di Azure il ripristino geografico. L'app per le funzioni secondaria è considerata passiva perché il servizio di failover a cui è connessa non è attualmente attivo, quindi l'app per le funzioni è essenzialmente inattiva.

Si consideri una topologia di esempio che usa Hub eventi di Azure trigger. In questo caso, il modello attivo/passivo richiede l'utilizzo dei componenti seguenti:

  • Hub eventi di Azure distribuito sia in un'area primaria che in un'area secondaria.
  • Emergenza geografica abilitata per associare l'hub eventi primario e secondario. Viene anche creato un alias che è possibile usare per connettersi agli hub eventi e passare da primario a secondario senza modificare le informazioni di connessione.
  • Le app per le funzioni vengono distribuite nell'area primaria e secondaria (failover), con l'app nell'area secondaria essenzialmente inattiva perché i messaggi non vengono inviati in questa area.
  • L'app per le funzioni viene attivata nella stringa di connessione diretta (non alias) per il rispettivo hub eventi.
  • Gli autori nell'hub eventi devono pubblicare nella stringa di connessione alias.

Architettura di esempio attivo-passivo

Prima del failover, i server di pubblicazione che inviano alla route alias condivisa all'hub eventi primario. L'app per le funzioni primaria è in ascolto esclusivo dell'hub eventi primario. L'app per le funzioni secondaria è passiva e inattiva. Non appena viene avviato il failover, i server di pubblicazione che inviano all'alias condiviso vengono indirizzati all'hub eventi secondario. L'app per le funzioni secondaria diventa ora attiva e avvia automaticamente l'attivazione. Il failover effettivo in un'area secondaria può essere guidato interamente dall'hub eventi, con le funzioni che diventano attive solo quando il rispettivo hub eventi è attivo.

Altre informazioni e considerazioni sul failover con bus di servizio e Hub eventi.

Ridondanza attiva/attiva per funzioni trigger non HTTP

È comunque possibile ottenere distribuzioni attive/attive per le funzioni attivate non HTTP. Tuttavia, è necessario considerare il modo in cui le due aree attive interagiscono o si coordinano tra loro. Quando si distribuisce la stessa app per le funzioni in due aree, ognuna delle quali viene attivata nella stessa coda bus di servizio, queste fungerebbero da consumer concorrenti per il deaccodamento della coda. Anche se ciò significa che ogni messaggio viene elaborato solo da una delle istanze, significa anche che è ancora presente un singolo punto di errore nella singola bus di servizio istanza.

È invece possibile distribuire due code bus di servizio, una in un'area primaria e una in un'area secondaria. In questo caso, è possibile avere due app per le funzioni, ognuna delle quali punta alla coda bus di servizio attiva nella relativa area. Il problema di questa topologia è il modo in cui i messaggi della coda vengono distribuiti tra le due aree. Spesso, ciò significa che ogni autore tenta di pubblicare un messaggio in entrambe le aree e ogni messaggio viene elaborato da entrambe le app per le funzioni attive. Anche se crea il modello attivo/attivo desiderato, crea anche altre problematiche in relazione alla duplicazione delle risorse di calcolo e al momento o al modo in cui i dati vengono consolidati. A causa di questi problemi, è consigliabile usare il modello attivo/passivo per le funzioni trigger non HTTPS.

Passaggi successivi