Condividi tramite

Affidabilità in Gestione API di Azure

Gestione API di Azure. è un servizio completamente gestito che consente alle organizzazioni di pubblicare, proteggere, trasformare, gestire e monitorare le API. Come servizio di Azure, Gestione API offre una gamma di funzionalità per supportare i requisiti di affidabilità.

Quando si usa Azure, l'affidabilità è una responsabilità condivisa. Microsoft offre una gamma di funzionalità per supportare la resilienza e il ripristino. L'utente è responsabile della comprensione del funzionamento di tali funzionalità all'interno di tutti i servizi usati e della selezione delle funzionalità necessarie per soddisfare gli obiettivi aziendali e gli obiettivi di tempo di attività.

Questo articolo descrive come rendere resiliente la gestione delle API a un'ampia gamma di potenziali interruzioni e problemi, tra cui errori temporanei, interruzioni della zona di disponibilità, interruzioni della regione e manutenzione del servizio. Descrive anche come usare i backup per eseguire il ripristino da altri tipi di problemi ed evidenzia alcune informazioni chiave sul contratto di servizio di Gestione API.

Panoramica dell'architettura di affidabilità

Gestione API usa un'architettura basata su unità di scala per offrire ridondanza e scalabilità predefinite. Quando si distribuisce un'istanza di Gestione API, si configurano una o più unità di scala o unità. Ogni unità è una rappresentazione logica della capacità che contiene le risorse di calcolo necessarie per gestire le richieste API.

Quando si configura un'istanza con due o più unità, le unità disponibili interagiscono per elaborare le richieste e fornire il bilanciamento del carico automatico. Se una delle unità non è più disponibile, le unità rimanenti continuano a gestire il traffico, ma con capacità potenzialmente ridotta.

Per ottenere livelli più elevati di affidabilità, Gestione API supporta la distribuzione unità tra zone di disponibilità all'interno di un'area e in più aree.

I livelli di servizio Gestione API offrono livelli diversi di affidabilità:

  • Livello Premium (classico): Supporta più unità che possono essere distribuite tra zone di disponibilità e aree per ottenere la massima resilienza. Nel livello Premium ogni unità è costituita da due macchine virtuali (VM) che forniscono le risorse di calcolo per gestire le richieste API.

  • Livelli Basic v2, Standard, Standard v2 e Premium v2 (anteprima): Tutte supportano più unità all'interno di un singolo data center. Non supportano zone di disponibilità o distribuzioni in più aree.

  • Livello sviluppatore: Supporta solo una singola unità e non offre alcun supporto per la zona di disponibilità o per più aree. Questo livello è progettato per scenari di sviluppo e test. Non è adatto per i carichi di lavoro di produzione.

  • Livello di consumo: Offre funzionalità di resilienza predefinite ed è resiliente a una gamma di errori all'interno di un singolo data center di Azure. Tuttavia, il livello Consumo non fornisce supporto per le zone di disponibilità o le distribuzioni in più aree. Per comprendere il tempo di attività previsto di un'istanza di Gestione API del livello di consumo, esaminare il contratto di servizio.To understand the expected uptime of a Consumption tier API Management instance, review the service-level agreement (SLA).

Le unità all'interno di un'istanza interagiscono per elaborare le richieste e bilanciare automaticamente il carico tra le unità disponibili. Se un'unità non è più disponibile, le unità rimanenti continuano a gestire il traffico, ma con capacità potenzialmente ridotta.

Annotazioni

I livelli Developer e Premium di Gestione API supportano gateway self-hosted, che è possibile eseguire nella propria infrastruttura. Quando si usano gateway self-hosted, è necessario configurarli per soddisfare i requisiti di affidabilità. I gateway self-hosted non rientrano nell'ambito di questo articolo.

Raccomandazioni per la distribuzione di produzione

Azure Well-Architected Framework offre raccomandazioni su affidabilità, prestazioni, sicurezza, costi e operazioni. Per comprendere in che modo queste aree influiscono tra loro e contribuiscono a una soluzione di Gestione API affidabile, vedere Procedure consigliate per l'architettura per Gestione API.

Resilienza a errori temporanei

Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Gli errori temporanei si correggono dopo un breve periodo di tempo. È importante che le applicazioni possano gestire gli errori temporanei, in genere ritentando le richieste interessate.

Tutte le applicazioni ospitate nel cloud devono seguire le indicazioni sulla gestione degli errori temporanei di Azure quando comunicano con qualsiasi API, database e altri componenti ospitati nel cloud. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

Quando si usa Gestione API davanti a un'API, potrebbe essere necessario ripetere le richieste che hanno esito negativo a causa di errori temporanei. Per proteggere l'API back-end da un numero eccessivo di richieste, Gestione API offre criteri di ripetizione, limite di velocità e quota. È anche possibile configurare le funzionalità di bilanciamento del carico e interruttore usando le risorse back-end.

Resilienza ai guasti delle zone di disponibilità

Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di un'area di Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.

Gestione API offre due tipi di supporto per la zona di disponibilità quando si distribuisce un'istanza di Gestione API Premium (classica) in un'area supportata:

  • Automatico: La gestione delle API offre il supporto automatico per le zone di disponibilità quando non si specificano quali zone usare.

  • Manuale: Gestione API offre supporto manuale per la zona di disponibilità quando si specificano in modo esplicito le zone di disponibilità da usare.

Con il supporto della zona di disponibilità, Gestione API replica i componenti del servizio tra zone per la disponibilità elevata. Nell'area primaria, questi componenti includono il gateway (unità di scala), il piano di gestione e il portale per sviluppatori. Nelle aree secondarie vengono replicate solo le unità gateway. Per altre informazioni sulle aree secondarie, vedere Resilienza agli errori a livello di area.

Supporto automatico della zona di disponibilità

È possibile utilizzare il supporto per la gestione automatica delle zone di disponibilità per scegliere una configurazione di istanza singola o multi-unità per raggiungere la ridondanza tra le zone.

  • Configurazione multiunit (scelta consigliata): se l'istanza ha due o più unità, Gestione API tenta di distribuire le unità dell'istanza tra le zone di disponibilità dell'area. Non è possibile determinare le zone di disponibilità in cui vengono inserite le unità. È consigliabile distribuire almeno due unità, che è possibile distribuire tra due zone.

    Il diagramma seguente illustra un'istanza di Gestione API con tre unità configurate per il supporto automatico della zona di disponibilità:

    Diagramma che mostra tre unità di Gestione API distribuite tra zone di disponibilità per il supporto automatico della zona di disponibilità.

  • Configurazione a unità singola: Se l'istanza ha una singola unità, le macchine virtuali sottostanti dell'unità vengono distribuite in due zone di disponibilità. Non è possibile determinare le zone di disponibilità in cui vengono inserite le macchine virtuali dell'unità.

    Diagramma che mostra una singola unità gestione API distribuita tra due zone di disponibilità per il supporto automatico della zona di disponibilità.

Supporto per zone di disponibilità gestite manualmente

Se si desidera selezionare in modo esplicito le zone di disponibilità da usare, è possibile scegliere tra configurazioni a ridondanza di zona e configurazioni zonali.

  • Ridondanza della zona: Configurare manualmente la ridondanza della zona per un'istanza di Gestione API in un'area supportata per fornire ridondanza per i componenti del servizio. Quando si selezionano due o più zone di disponibilità da usare, Azure replica automaticamente i componenti del servizio tra le zone selezionate.

    Diagramma che mostra tre unità di Gestione API distribuite tra le zone di disponibilità per la ridondanza manuale della zona.

  • Zonale: I componenti del servizio Gestione API vengono distribuiti in una singola zona selezionata all'interno di un'area di Azure. Tutte le unità vengono inserite nella stessa zona di disponibilità.

    Diagramma che mostra una distribuzione di Gestione API di zona con due unità, in una singola zona di disponibilità.

    Importante

    Aggiungere a una singola zona di disponibilità solo se la latenza tra zone è troppo elevata per le proprie esigenze e dopo aver verificato che non soddisfa i propri requisiti di latenza. Di per sé, un'istanza zonale non offre resilienza in caso di un'interruzione della zona di disponibilità. Per migliorare la resilienza di una distribuzione di Gestione API di zona, è necessario distribuire in modo esplicito istanze separate in più zone di disponibilità e configurare il routing e il failover del traffico.

Requisiti

  • Supporto per l'area: Gestione API supporta le zone di disponibilità per il livello Premium (classico) in tutte le aree di Azure che supportano le zone di disponibilità.

  • Requisito del livello: Per configurare il supporto della zona di disponibilità, è necessario usare il livello Premium (classico). La gestione API attualmente non supporta le zone di disponibilità nei livelli a consumo classico, Developer, Basic e Standard o nei livelli Basic v2, Standard v2 e Premium v2. Per aggiornare l'istanza al livello Premium (classico), vedere Eseguire l'aggiornamento al livello Premium.

Annotazioni

Il livello Premium v2 con funzionalità aziendali è disponibile in anteprima. Per determinare se la progettazione deve basarsi sulle funzionalità di accesso anticipato o sulle funzionalità disponibili a livello generale, valutare le sequenze temporali di progettazione e implementazione in relazione alle informazioni disponibili sui percorsi di rilascio e migrazione di Premium v2.

Considerazioni

  • Numero di unità per le istanze con ridondanza della zona: Se si configura manualmente la ridondanza della zona per un'istanza, è anche necessario configurare una serie di unità di Gestione API che possono essere distribuite uniformemente in tutte le zone di disponibilità selezionate. Ad esempio, se si selezionano due zone, è necessario configurare almeno due unità. È invece possibile configurare quattro unità o un altro multiplo di due unità. Se si selezionano tre zone di disponibilità, è necessario configurare tre unità, sei unità o un altro multiplo di tre unità.

    Se si usa il supporto della zona di disponibilità automatica, non è necessario usare un numero specifico di unità. Le unità che distribuite vengono dislocate tra le zone di disponibilità nel miglior modo possibile. Per la ridondanza massima della zona, è consigliabile usare almeno due unità per assicurarsi che un'interruzione della zona di disponibilità non influisca sull'istanza.

    Per determinare il numero di unità che forniscono le prestazioni del gateway necessarie, usare le metriche di capacità e i propri test. Per altre informazioni sul ridimensionamento e sull'aggiornamento dell'istanza del servizio, vedere Aggiornare e ridimensionare un'istanza di Gestione API.

  • Scalabilità automatica: Se si configurano manualmente le zone di disponibilità in un'istanza di Gestione API configurata con la scalabilità automatica, potrebbe essere necessario modificare le impostazioni di scalabilità automatica dopo la configurazione. In questo caso, il numero di unità di Gestione API nelle regole e nei limiti di scalabilità automatica deve essere un multiplo del numero di zone. Se si usa il supporto della zona di disponibilità automatica, non è necessario modificare le impostazioni di scalabilità automatica.

  • Requisiti per gli indirizzi IP: Quando si abilita il supporto della zona di disponibilità in un'istanza di Gestione API distribuita in una rete virtuale esterna o interna, è necessario specificare una risorsa indirizzo IP pubblico da usare per l'istanza. In una rete virtuale interna, l'IP pubblico viene usato solo per le operazioni di gestione, non per le richieste API. Per altre informazioni, vedere Indirizzi IP in Gestione API.

Costo

Indipendentemente dalla configurazione della zona di disponibilità, se si aggiungono altre unità, si comportano più costi. Per informazioni, vedere Prezzi di Gestione API.

Configurare il supporto delle zone di disponibilità

Questa sezione illustra come configurare il supporto della zona di disponibilità per l'istanza di Gestione API.

Annotazioni

Quando si selezionano le zone di disponibilità da usare, si seleziona effettivamente la zona di disponibilità logica. Se si distribuiscono altri componenti del carico di lavoro in una sottoscrizione di Azure diversa, è possibile usare un numero di zona di disponibilità logico diverso per accedere alla stessa zona di disponibilità fisica. Per altre informazioni, vedere Zone di disponibilità fisiche e logiche.

  • Creare un'istanza di Gestione API che supporti le zone di disponibilità: Quando si crea un'istanza di Gestione API Premium (classica) in un'area che supporta le zone di disponibilità, l'istanza supporta le zone di disponibilità per impostazione predefinita. È possibile selezionare la zona di disponibilità automatica o configurare manualmente il supporto zonale o zona ridondante.

  • Abilitare o riconfigurare il supporto della zona di disponibilità: È possibile modificare la configurazione della zona di disponibilità per un'istanza di Gestione API, inclusa l'aggiunta di zone di disponibilità e lo spostamento di un'istanza di zona tra le zone di disponibilità. Per informazioni su come configurare il supporto della zona di disponibilità in un'istanza di Gestione API, vedere Abilitare il supporto della zona di disponibilità nelle istanze di Gestione API. Non sono previsti requisiti di tempo di inattività per una delle opzioni di configurazione.

    Quando si modifica la configurazione della zona di disponibilità, le modifiche possono richiedere da 15 a 45 minuti o più da applicare. Il gateway di Gestione API può continuare a gestire le richieste API durante questo periodo.

    La modifica della configurazione della zona di disponibilità attiva una modifica dell'indirizzo IP pubblico e privato.

Pianificazione e gestione della capacità

In uno scenario di indisponibilità di zona, non c'è garanzia che le richieste di maggiore capacità in un'altra zona di disponibilità abbiano successo. Il recupero delle informazioni delle unità perse si verifica in base al massimo impegno. Se è necessaria una capacità garantita quando una zona di disponibilità ha esito negativo, è necessario creare e configurare l'istanza di Gestione API per tenere conto della perdita di una zona eseguendo tutte le azioni seguenti:

  • Effettuare il provisioning eccessivo delle unità dell'istanza di Gestione API.

  • Usare la configurazione della zona di disponibilità automatica o con ridondanza della zona.

Per altre informazioni, vedere Gestire la capacità con il provisioning eccessivo.

Usare le metriche di capacità e i test personalizzati per determinare il numero di unità che forniscono le prestazioni del gateway necessarie. Per altre informazioni su come ridimensionare e aggiornare l'istanza del servizio, vedere Aggiornare e ridimensionare un'istanza di Gestione API.

Comportamento quando tutte le zone sono integre

Questa sezione descrive cosa aspettarsi quando le istanze di Gestione API sono configurate con il supporto della zona di disponibilità e tutte le zone di disponibilità sono operative.

  • Routing del traffico tra zone: Durante le normali operazioni, il traffico viene instradato tra tutte le unità di Gestione API disponibili in tutte le zone di disponibilità selezionate.

  • Replica dei dati tra zone: Gestione API archivia e replica i dati seguenti.

    • La configurazione del gateway, ad esempio le API e le definizioni dei criteri, viene sincronizzata regolarmente tra le zone di disponibilità selezionate per l'istanza. La propagazione degli aggiornamenti tra le zone di disponibilità richiede in genere meno di 10 secondi.

    • Dati nella cache interna, se si usa la cache interna fornita da Gestione API. Le voci della cache vengono distribuite tra le zone di disponibilità. La cache interna è volatile e non è garantito che i dati siano persistenti. È consigliabile usare una cache esterna se è necessario rendere persistenti i dati memorizzati nella cache.

    • Contatori dei limiti di frequenza, se si usano le funzionalità di limitazione della frequenza fornite da Gestione API. I contatori dei limiti di frequenza vengono replicati in modo asincrono tra le zone di disponibilità selezionate per l'istanza.

Comportamento durante un errore di zona

Questa sezione descrive cosa aspettarsi quando le istanze di Gestione API sono configurate con il supporto della zona di disponibilità e si verifica un'interruzione della zona di disponibilità.

  • Rilevamento e risposta: La responsabilità del rilevamento e della risposta dipende dalla configurazione della zona di disponibilità usata dall'istanza.

    • Automatico e con ridondanza di zona: Per le istanze configurate per l'uso del supporto automatico della zona di disponibilità o configurate manualmente per l'uso della ridondanza della zona, la piattaforma di Gestione API è responsabile del rilevamento di un errore in una zona di disponibilità e della relativa risposta. Non è necessario eseguire alcuna operazione per avviare un failover di zona.

    • Zonale: Per le istanze configurate per la zona, è necessario rilevare la perdita di una zona di disponibilità e avviare un failover in un'istanza secondaria creata in un'altra zona di disponibilità.

  • Richieste attive: Quando una zona di disponibilità non è disponibile, tutte le richieste in corso connesse a un'unità gestione API nella zona di disponibilità difettosa vengono terminate e devono essere ritentate.

  • Perdita di dati prevista: Gestione API archivia i dati seguenti.

    • Modifiche alla configurazione del gateway, replicate in ogni zona di disponibilità selezionata entro circa 10 secondi. Se si verifica un'interruzione di una zona di disponibilità, è possibile che le modifiche alla configurazione non vengano replicate.

    • Dati nella cache interna, se si usa la funzionalità cache interna. La cache interna è volatile e non è garantito che i dati siano persistenti. Durante un'interruzione della zona di disponibilità, si potrebbero perdere alcuni o tutti i dati memorizzati nella cache. È consigliabile usare una cache esterna se è necessario rendere persistenti i dati memorizzati nella cache.

    • Contatori dei limiti di frequenza, se si usa la funzionalità limite di velocità. Durante un'interruzione della zona di disponibilità, i contatori dei limiti di frequenza potrebbero non essere aggiornati nelle zone sopravvissute.

  • Tempo di inattività previsto: Il tempo di inattività previsto dipende dalla configurazione della zona di disponibilità usata dall'istanza.

    • Automatico: È possibile prevedere che le istanze che usano il supporto della zona di disponibilità automatica non abbiano tempi di inattività durante un'interruzione della zona di disponibilità. Le unità nella zona o nelle zone non interessate continuano a funzionare.

      È anche possibile prevedere che le istanze che usano il supporto della zona di disponibilità automatica, ma che abbiano una singola unità, non abbiano tempi di inattività. In questo caso, Gestione API distribuisce le macchine virtuali sottostanti dell'unità in due zone. La macchina virtuale nella zona non interessata continua a funzionare.

    • Zone a ridondanza: È possibile prevedere che le istanze con zone a ridondanza non abbiano interruzioni durante un'interruzione della zona di disponibilità.

    • Zonale: Per le istanze di zona, quando una zona non è disponibile, l'istanza non è disponibile fino al ripristino della zona di disponibilità.

  • Reindirizzamento del traffico: Il comportamento di reindirizzamento del traffico dipende dalla configurazione della zona di disponibilità usata dall'istanza.

    • Automatica e con ridondanza di zona: Per le istanze configurate per l'uso del supporto automatico di disponibilità della zona o configurate manualmente per l'uso della ridondanza di zona, quando una zona non è disponibile, anche le unità nella zona interessata non sono disponibili. È possibile scegliere di ridimensionare l'istanza per aggiungere altre unità.

    • Zonale: Per le istanze di zona, quando una zona non è disponibile, l'istanza non è disponibile. Se si dispone di un'istanza secondaria in un'altra zona di disponibilità, spetta a te reindirizzare il traffico a tale istanza secondaria.

Ripristino della zona

Il comportamento di ripristino della zona dipende dalla configurazione della zona di disponibilità usata dall'istanza.

  • Automatico e ridondante di zona: Per le istanze che sono configurate per utilizzare il supporto automatico della zona di disponibilità o che sono configurate manualmente per l'uso della ridondanza di zona, quando la zona di disponibilità viene recuperata, Gestione delle API ripristina automaticamente le unità nella zona di disponibilità e reindirizza il traffico tra le unità come di consueto.

  • Zonal: per le istanze di zona, si è responsabili del reindirizzamento del traffico all'istanza nella zona di disponibilità originale dopo il ripristino della zona di disponibilità.

Verifica dei guasti di zona

Le opzioni per il test per gli errori di zona dipendono dalla configurazione della zona di disponibilità usata dall'istanza.

  • Automatico e ridondante per zona: Per le istanze configurate per l'uso del supporto automatico per le zone di disponibilità o configurate manualmente per l'uso della ridondanza zonale, la piattaforma di gestione delle API gestisce il routing del traffico, il failover e il ripristino. Questa funzionalità è completamente gestita, quindi non è necessario avviare o convalidare i processi di errore della zona di disponibilità.

  • Zonale: Per le istanze di zona, non è possibile simulare un'interruzione della zona di disponibilità che contiene l'istanza di Gestione API. Tuttavia, è possibile configurare manualmente gateway upstream o servizi di bilanciamento del carico per reindirizzare il traffico a un'istanza diversa in una zona di disponibilità diversa.

Resilienza agli errori a livello di area

Con una distribuzione in più aree, è possibile aggiungere gateway API a livello di area a un'istanza di Gestione API esistente in una o più aree di Azure supportate. La distribuzione in più aree consente di ridurre qualsiasi latenza delle richieste percepita dai consumer di API distribuite geograficamente. Una distribuzione in più aree migliora anche la disponibilità del servizio se un'area diventa offline.

Distribuzione multi-area gestita da Microsoft

Gestione API supporta solo distribuzioni in più aree nel livello Premium (classico). Non supporta distribuzioni in più aree nei livelli Consumption, Developer, Basic, Basic v2, Standard, Standard v2 e Premium v2 (anteprima). Per altre informazioni, vedere Requisiti.

Quando si aggiunge un'area, si configura:

Requisiti

  • Supporto per l'area: È possibile creare distribuzioni in più aree nel livello Premium (classico) con qualsiasi area di Azure che supporta Gestione API. Per vedere quali aree supportano distribuzioni in più aree, vedere Disponibilità del prodotto in base all'area.

  • Requisito del livello: È necessario usare il livello Premium (classico) per configurare il supporto per più aree. Per aggiornare l'istanza al livello Premium (classico), vedere Eseguire l'aggiornamento al livello Premium.

Annotazioni

Il livello Premium v2 con funzionalità aziendali è disponibile in anteprima. Per determinare se la progettazione deve basarsi sulle funzionalità di accesso anticipato o sulle funzionalità disponibili a livello generale, valutare le sequenze temporali di progettazione e implementazione in relazione alle informazioni disponibili sui percorsi di rilascio e migrazione di Premium v2.

Considerazioni

  • Solo gateway: Solo il componente gateway dell'istanza di Gestione API viene replicato in più aree. Il piano di gestione e il portale per sviluppatori dell'istanza rimangono ospitati solo nell'area primaria in cui è stato originariamente distribuito il servizio.

  • Requisiti di rete: Se si vuole configurare un percorso secondario per l'istanza di Gestione API quando viene distribuito (inserito) in una rete virtuale, la rete virtuale e l'area della subnet devono corrispondere alla posizione secondaria configurata. Se si aggiunge, rimuove o abilita la zona di disponibilità nell'area primaria o si modifica la subnet dell'area primaria, l'indirizzo IP virtuale (VIP) dell'istanza di Gestione API cambia. Per altre informazioni, vedere Modifiche agli indirizzi IP. Tuttavia, se si aggiunge un'area secondaria, l'indirizzo VIP dell'area primaria non cambia perché ogni area ha un indirizzo VIP privato.

  • Nomi DNS (Domain Name System): Il gateway in ogni area, inclusa l'area primaria, ha un nome DNS a livello di area che segue il modello URL di https://<service-name>-<region>-01.regional.azure-api.net, ad esempio https://contoso-westus2-01.regional.azure-api.net.

Costo

L'aggiunta di aree comporta costi. Per informazioni, vedere Prezzi di Gestione API.

Configurare il supporto per più aree

Per configurare il supporto in più aree in un'istanza di Gestione API, vedere Distribuire un'istanza di Gestione API in più aree di Azure.

Per rimuovere un'area da un'istanza di Gestione API, vedere Rimuovere un'area del servizio Gestione API.

Pianificazione e gestione della capacità

In uno scenario di malfunzionamento della regione non è garantito che le richieste di maggiore capacità in un'altra regione abbiano esito positivo. Se è necessaria una capacità garantita quando un'area ha esito negativo, è necessario creare e configurare l'istanza di Gestione API per tenere conto della perdita di un'area. A tale scopo, è possibile effettuare il over-provisioning della capacità dell'istanza di Gestione API. Per altre informazioni sui principi del provisioning eccessivo, vedere Gestire la capacità con provisioning eccessivo.

Nelle distribuzioni in più aree, la scalabilità automatica si applica solo all'area primaria. Le aree secondarie richiedono regolazioni manuali del ridimensionamento o strumenti personalizzati che controlli tu stesso.

Comportamento quando tutte le aree sono integre

Questa sezione descrive cosa aspettarsi quando le istanze di Gestione API sono configurate con supporto per più aree e tutte le aree sono operative.

  • Routing del traffico tra aree: Gestione API instrada automaticamente le richieste in ingresso a un gateway a livello di area. Una richiesta viene instradata al gateway a livello di area con la latenza più bassa dal client. Se è necessario usare un approccio di routing diverso, è possibile configurare Gestione traffico personalizzato con regole di routing personalizzate. Per altre informazioni, vedere Usare il routing personalizzato per i gateway a livello di area di Gestione API.

    Quando una richiesta raggiunge un gateway a livello di area di Gestione API, viene instradata all'API back-end, a meno che un criterio non restituisca una risposta direttamente dal gateway, ad esempio una risposta memorizzata nella cache o un codice di errore. In una soluzione in più aree è necessario eseguire il routing a un'istanza dell'API back-end che soddisfi i requisiti di prestazioni. Per altre informazioni, vedere Instradare le chiamate API ai servizi back-end a livello di area.

  • Replica dei dati tra aree: La configurazione del gateway, ad esempio le API e le definizioni dei criteri, viene sincronizzata regolarmente tra le aree primarie e secondarie aggiunte. La propagazione degli aggiornamenti ai gateway a livello di area richiede in genere meno di 10 secondi.

    I contatori dei limiti di frequenza e i dati nella cache interna sono specifici dell'area, quindi non vengono replicati tra aree.

Comportamento durante un errore di area

Questa sezione descrive cosa aspettarsi quando le istanze di Gestione API sono configurate con il supporto per più aree ed è presente un'interruzione in una delle aree usate.

  • Rilevamento e risposta: Gestione API è responsabile del rilevamento di un errore in un'area e del failover automatico in un gateway in una delle altre aree configurate.

  • Richieste attive: Tutte le richieste attive elaborate nell'area difettosa potrebbero essere eliminate e devono essere ritentate dal client.

  • Perdita di dati prevista: Gestione API non archivia i dati, ad eccezione di configurazione, cache e contatori dei limiti di frequenza.

    Le modifiche alla configurazione vengono replicate in ogni area entro circa 10 secondi. Se si verifica un'interruzione dell'area primaria, potresti perdere le modifiche alla configurazione che non sono state replicate.

    I contatori dei limiti di frequenza e i dati nella cache interna sono specifici dell'area, quindi non vengono replicati tra aree.

  • Tempo di inattività previsto: Non è previsto alcun tempo di inattività del gateway.

    Se l'area primaria diventa offline, il piano di gestione API e il portale per sviluppatori non sono più disponibili, ma le aree secondarie continuano a gestire le richieste API usando la configurazione del gateway più recente.

  • Reinstradamento del traffico: Se un'area passa offline, le richieste API vengono automaticamente instradate intorno all'area non funzionante verso il gateway più vicino.

Ripristino della regione

Quando l'area primaria viene ripristinata, Gestione API ripristina automaticamente le unità nell'area e reindirizza il traffico tra le unità.

Test per guasti a livello di area

Per prepararsi a interruzioni impreviste dell'area geografica, è consigliabile testare regolarmente le risposte alle interruzioni regionali. È possibile simulare alcuni aspetti di un errore di area disabilitando il routing a un gateway a livello di area.

Backup e ripristino

Gestione API non archivia la maggior parte dei dati di runtime. Tuttavia, è possibile eseguire il backup della configurazione del servizio Gestione API. È anche possibile usare operazioni di backup e ripristino per replicare le configurazioni del servizio Gestione API tra ambienti operativi, ad esempio sviluppo e gestione temporanea.

Importante

In una procedura di backup vengono inclusi dati di runtime, ad esempio utenti e sottoscrizioni, che potrebbero non essere sempre auspicabili.

Il backup è supportato nei livelli Developer, Basic, Standard e Premium.

Per altre informazioni, vedere Come implementare il ripristino di emergenza usando il backup e il ripristino del servizio in Gestione API.

Per il backup o il ripristino di alcuni componenti o risorse del servizio, è anche possibile prendere in considerazione opzioni gestite dal cliente, ad esempio strumenti APIOps e soluzioni di infrastruttura come codice (IaC).

Resilienza alla manutenzione del servizio

Gestione API esegue aggiornamenti regolari del servizio e altre forme di manutenzione.

Nei livelli Basic, Standard e Premium (versione classica) è possibile personalizzare quando nel processo di aggiornamento l'istanza riceve un aggiornamento. Se è necessario convalidare l'effetto degli aggiornamenti nel carico di lavoro, valutare la possibilità di configurare un'istanza di test per ricevere gli aggiornamenti all'inizio di un ciclo di aggiornamento e impostare l'istanza di produzione per ricevere gli aggiornamenti in ritardo nel ciclo. È anche possibile specificare una finestra di manutenzione, ovvero l'ora del giorno in cui si desidera che l'istanza applichi gli aggiornamenti del servizio.

Per altre informazioni, vedere Configurare le impostazioni di aggiornamento del servizio per le istanze di Gestione API.

Contratto di servizio

Il contratto di servizio per i servizi di Azure descrive la disponibilità prevista di ogni servizio e le condizioni che la soluzione deve soddisfare per raggiungere tale aspettativa di disponibilità. Per altre informazioni, vedere Contratti di servizio per Servizi online.

Quando si distribuisce un'istanza di API Management in più zone o aree di disponibilità, aumenta la percentuale di uptime definita nell'SLA.

Il servizio fornisce il proprio contratto di servizio, ma è anche necessario tenere conto dell'affidabilità prevista di altri componenti del carico di lavoro, ad esempio i back-end dell'API.

Contenuti correlati

  • Last updated on