Condividi tramite

Garantire la disponibilità e l'affidabilità di Gestione API

  • Articolo

SI APPLICA A: Premium

Questo articolo offre una panoramica delle funzionalità del servizio per assicurarsi che l'istanza di Gestione API continui a gestire le richieste API in caso di interruzioni di Azure.

Gestione API offre le funzionalità seguenti per soluzioni di Azure affidabili e resilienti. Usarli singolarmente o insieme per migliorare la disponibilità:

  • Zone di disponibilità: resilienza alle interruzioni a livello di data center

  • Distribuzione in più aree: resilienza alle interruzioni a livello di area

Nota

Zone di disponibilità

Le zone di disponibilità di Azure sono posizioni fisicamente separate all'interno di un'area di Azure con tolleranza agli errori a livello di data center. Ogni zona è costituita da uno o più data center dotati di impianti indipendenti per l'alimentazione, il raffreddamento e la connettività di rete. Per garantire la resilienza, sono presenti almeno 3 zone di disponibilità separate in tutte le aree abilitate per la zona di disponibilità. Ulteriori informazioni

L'abilitazione della ridondanza della zona per un'istanza di Gestione API in un'area supportata offre ridondanza per tutti i componenti del servizio: gateway, piano di gestione e portale per sviluppatori. Azure replica automaticamente tutti i componenti del servizio nelle zone selezionate.

Quando si abilita la ridondanza della zona in un'area, prendere in considerazione il numero di unità di scala di Gestione API da distribuire. Configurare almeno un numero di unità corrispondente al numero di zone di disponibilità o un multiplo di tale valore, in modo che le unità vengano distribuite uniformemente tra le zone. Ad esempio, se si selezionano 3 zone di disponibilità in un'area, è possibile avere 3 unità in modo che ogni zona ospiti un'unità.

Nota

Usare le metriche di capacità e i propri test per decidere il numero di unità di scala che forniranno le prestazioni del gateway per le proprie esigenze. Altre informazioni su ridimensionamento e aggiornamento dell'istanza del servizio.

Distribuzione in più aree

Con la 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. Ciò consente di ridurre la latenza delle richieste percepita dagli utenti dell'API distribuiti geograficamente, oltre a migliorare la disponibilità del servizio se un'area viene portata offline.

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

  • Se si vuole configurare un percorso secondario per l'istanza di Gestione API quando viene distribuita (inserita) in una rete virtuale, la rete virtuale e l'area della subnet devono corrispondere alla posizione secondaria che si sta configurando. Se si sta aggiungendo, rimuovendo o abilitando la zona di disponibilità nell'area primaria o se si modifica la subnet dell'area primaria, l'indirizzo VIP dell'istanza di Gestione API cambierà. Per altre informazioni, vedere Indirizzi IP del servizio Gestione API di Azure. Se tuttavia si aggiunge un'area secondaria, l'indirizzo VIP dell'area primaria non cambierà perché ogni area ha un proprio indirizzo VIP privato.

  • Le configurazioni del gateway, ad esempio API e definizioni di criteri, vengono sincronizzate 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. La distribuzione in più aree offre la disponibilità del gateway API in più aree e fornisce la disponibilità del servizio se un'area è offline.

  • Quando Gestione API riceve richieste HTTP pubbliche all'endpoint di gestione traffico (si applica per la rete virtuale esterna e le modalità non di rete di Gestione API), il traffico viene instradato a un gateway a livello di area in base alla latenza più bassa. Ciò può ridurre la latenza riscontrata dai consumer di API distribuite geograficamente. In modalità VNet interna, i clienti devono configurare la propria soluzione per instradare e bilanciare il carico del traffico tra i gateway regionali. Per informazioni dettagliate, vedere Considerazioni sulla rete.

  • 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.

  • Se un'area viene disattivata, le richieste API vengono indirizzate automaticamente all'area non riuscita al gateway più vicino.

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

Combinare le zone di disponibilità e la distribuzione in più aree

La combinazione di zone di disponibilità per la ridondanza all'interno di un'area e distribuzioni in più aree per migliorare la disponibilità del gateway in caso di interruzione a livello di area consente di migliorare sia l'affidabilità che le prestazioni dell'istanza di Gestione API.

Esempi:

  • Usare le zone di disponibilità per migliorare la resilienza dell'area primaria in una distribuzione in più aree

  • Distribuire le unità di scala tra zone di disponibilità e aree per migliorare le prestazioni del gateway a livello di area

Considerazioni sul contratto di servizio

Gestione API offre un contratto di servizio del 99,99% quando si distribuisce almeno un'unità in due o più zone di disponibilità o aree. Per altre informazioni, vedere Prezzi.

Nota

Benché Azure si impegni continuamente per ottenere la massima resilienza possibile nel contratto di servizio per la piattaforma cloud, è necessario definire contratti di servizio di destinazione personalizzati per altri componenti della soluzione.

Disponibilità back-end

A seconda della posizione e della modalità di hosting dei servizi back-end, potrebbe essere necessario configurare back-end ridondanti in aree diverse per soddisfare i requisiti di disponibilità del servizio. È anche possibile configurare le proprietà back-end per migliorare la resilienza e la disponibilità dei servizi back-end.

Back-end a livello di area

È possibile gestire back-end a livello di area e gestire il failover tramite Gestione API per mantenere la disponibilità. Ad esempio:

  • Nelle distribuzioni in più aree usare i criteri per instradare le richieste tramite gateway regionali a back-end a livello di area.

  • Configurare i criteri per instradare le richieste in modo condizionale a back-end diversi in caso di errore dei back-end in una determinata area.

  • Usare la memorizzazione nella cache per ridurre le chiamate con errori.

Per informazioni dettagliate, vedere il post di blog Ridondanza dell'API back-end con Gestione API di Azure.

Configurare le proprietà back-end per la disponibilità

Le entità back-end di Gestione API consentono di gestire e applicare proprietà back-end per migliorare la disponibilità dei back-end. Ad esempio:

Passaggi successivi