Garantire Gestione API disponibilità e affidabilità

  • Articolo

SI APPLICA A: Premium

Questo articolo presenta le funzionalità e le considerazioni del servizio per assicurarsi che l'istanza di Gestione API continui a gestire le richieste API se si verificano interruzioni di Azure.

Gestione API supporta le funzionalità chiave del servizio seguenti consigliate per soluzioni di Azure affidabili e resilienti. Usarli singolarmente o insieme per migliorare la disponibilità della soluzione Gestione API:

  • Zone di disponibilità, per fornire resilienza alle interruzioni a livello di data center

  • Distribuzione in più aree, per offrire resilienza alle interruzioni a livello di area

Nota

Gestione API supporta le zone di disponibilità e la distribuzione in più aree nelLivello di servizio Premium.

Zone di disponibilità

Le zone di disponibilità di Azure sono posizioni fisicamente separate all'interno di un'area di Azure che sono tolleranti 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à.

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. La ridondanza della zona è disponibile solo nel livello di servizio Premium.

Quando si abilita la ridondanza della zona in un'area, prendere in considerazione il numero di unità di scala Gestione API da distribuire. Configurare in modo minimo lo stesso numero di unità del numero di zone di disponibilità o un multiplo 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 la metrica 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 sul ridimensionamento e sull'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. La distribuzione in più aree è disponibile solo nel livello di servizio Premium.

  • 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, l'area in cui è stato originariamente distribuito il servizio.

  • 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 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. Tuttavia, se 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, che può ridurre la latenza riscontrata dai consumer di API distribuite geograficamente.

  • 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 fornisce un contratto di servizio del 99,99% quando si distribuisce almeno un'unità in due o più zone o aree di disponibilità. Per altre informazioni, vedere Prezzi.

Nota

Mentre Azure si impegna 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 i 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 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 sulla ridondanza dell'API back-end con Gestione API di Azure.

Configurare le proprietà back-end per la disponibilità

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

  • Distribuire e bilanciare il carico del traffico a un pool di URL
  • Configurare le regole dell'interruttore per applicare il modello di interruttore per proteggere il back-end da troppe richieste

Passaggi successivi