Condividi tramite

Distribuire un'istanza del servizio Gestione API di Azure in più aree di Azure

  • Articolo

SI APPLICA A: Premium

Azure Gestione API supporta la distribuzione in più aree, che consente agli editori API di aggiungere gateway API 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.

Quando si aggiunge un'area, si configura:

  • Numero di unità di scalabilità che ospiteranno l'area.

  • Zone di disponibilità facoltative, se l'area la supporta.

  • Impostazioni di rete virtuale nell'area aggiunta, se la rete è configurata nell'area o nelle aree esistenti.

Importante

In Azure la funzionalità per abilitare l'archiviazione dei dati dei clienti in una singola area è attualmente disponibile solo nell'area Asia sud-orientale (Singapore) dell'area geografica Asia Pacifico. Per tutte le altre aree i dati dei clienti vengono archiviati in Geo.

Informazioni sulla distribuzione in più aree

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

Prerequisiti

  • Se non è stata creata un'istanza del servizio Gestione API, vedere Creare un'istanza del servizio Gestione API. Selezionare il livello di servizio Premium.
  • Se l'istanza di Gestione API viene distribuita in una rete virtuale, assicurarsi di configurare una rete virtuale e una subnet nel percorso da aggiungere e all'interno della stessa sottoscrizione. Vedere i prerequisiti della rete virtuale.

Distribuire il servizio Gestione API in un'area aggiuntiva

  1. Nel portale di Azure passare al servizio Gestione API e selezionare Percorsi dal menu a sinistra.
  2. Selezionare + Aggiungi nella barra superiore.
  3. Selezionare il percorso aggiunto dall'elenco a discesa.
  4. Selezionare il numero di unità di scala nella posizione.
  5. Facoltativamente, selezionare una o più zone di disponibilità.
  6. Se l'istanza di Gestione API viene distribuita in una rete virtuale, configurare le impostazioni della rete virtuale nel percorso, tra cui rete virtuale, subnet e indirizzo IP pubblico (se si abilitano le zone di disponibilità).
  7. Selezionare Aggiungi per confermare.
  8. Ripetere questo processo fino a quando non si configurano tutte le posizioni.
  9. Selezionare Salva nella barra superiore per avviare il processo di distribuzione.

Rimuovere un'area del servizio Gestione API

  1. Nel portale di Azure passare al servizio Gestione API e selezionare Percorsi dal menu a sinistra.
  2. Per la posizione che si vuole rimuovere, selezionare il menu di scelta rapida usando il pulsante ... alla fine destra della tabella. Selezionare Elimina.
  3. Confermare l'eliminazione e selezionare Salva per applicare le modifiche.

Chiamate di route API per servizi back-end a livello di area

Per impostazione predefinita, ogni API instrada le richieste a un singolo URL del servizio back-end. Anche se sono stati configurati gateway di Gestione API di Azure in varie aree, il gateway API inoltra comunque le richieste allo stesso servizio back-end, che viene distribuito in una sola area. In questo caso, il miglioramento delle prestazioni proverrà solo dalle risposte memorizzate nella cache in Gestione API di Azure in un'area specifica per la richiesta; il tentativo di contattare il back-end in tutto il mondo potrebbe comunque causare una latenza elevata.

Per sfruttare i vantaggi della distribuzione geografica del sistema, è necessario che i servizi back-end siano distribuiti nelle stesse aree delle istanze di Gestione API di Azure. Quindi, usando i criteri e la proprietà @(context.Deployment.Region), è possibile instradare il traffico alle istanze locali di back-end.

  1. Passare all'istanza di Gestione API di Azure e selezionare le API dal menu a sinistra.

  2. Selezionare l'API desiderata.

  3. Selezionare editor di codice dall'elenco a discesa freccia nell'elaborazione in ingresso.

    Editor di codice API

  4. Usare i criteri set-backend combinati con condizionalechoose per creare un criterio di routing appropriato nella <inbound> </inbound> sezione del file.

    Ad esempio, il file XML seguente funziona per le aree Stati Uniti occidentali e Asia orientale:

    <policies>
    <inbound>
        <base />
        <choose>
            <when condition="@("West US".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
                <set-backend-service base-url="http://contoso-backend-us.com/" />
            </when>
            <when condition="@("East Asia".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
                <set-backend-service base-url="http://contoso-backend-asia.com/" />
            </when>
            <otherwise>
                <set-backend-service base-url="http://contoso-backend-other.com/" />
            </otherwise>
        </choose>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

Usare Gestione traffico per il routing ai back-end a livello di area

È anche possibile far fronte ai servizi back-end con Gestione traffico di Azure, indirizzare le chiamate API a Gestione traffico e consentire la risoluzione automatica del routing.

  • Per la distribuzione e il failover del traffico, è consigliabile usare Gestione traffico con il metodo di routing geografico. Non è consigliabile usare Gestione traffico con il metodo di routing ponderato con back-end di Gestione API.

  • Per il controllo del traffico durante le operazioni di manutenzione, è consigliabile usare il metodo di routing Priority.

Usare il routing personalizzato per i gateway a livello di area di Gestione API

Gestione API instrada le richieste a un gateway a livello di area in base alla latenza più bassa. Anche se non è possibile eseguire l'override di questa impostazione in Gestione API, è possibile usare Gestione traffico personalizzato con regole di routing personalizzate.

  1. Creare una propria Gestione traffico di Azure.
  2. Se si usa un dominio personalizzato, usarlo con Gestione traffico anziché con il servizio Gestione API.
  3. Configurare gli endpoint a livello di area di Gestione API in Gestione traffico. Gli endpoint a livello di area seguono il modello URL di https://<service-name>-<region>-01.regional.azure-api.net, ad esempio https://contoso-westus2-01.regional.azure-api.net.
  4. Configurare gli endpoint di stato a livello di area di Gestione API in Gestione traffico. Gli endpoint di stato a livello di area seguono il modello URL di https://<service-name>-<region>-01.regional.azure-api.net/status-0123456789abcdef, ad esempio https://contoso-westus2-01.regional.azure-api.net/status-0123456789abcdef.
  5. Specificare il metodo di routing di Gestione traffico.

Disabilitare il routing a un gateway a livello di area

In alcune condizioni, potrebbe essere necessario disabilitare temporaneamente il routing a uno dei gateway regionali. Ad esempio:

  • Dopo aver aggiunto una nuova area, per mantenerla disabilitata durante la configurazione e il test del servizio back-end a livello di area
  • Durante la normale manutenzione back-end in un'area
  • Per reindirizzare il traffico ad altre aree durante un'esercitazione di ripristino di emergenza pianificata che simula un'area non disponibile o durante un errore a livello di area

Per disabilitare il routing a un gateway a livello di area nell'istanza di Gestione API, aggiornare il valore della proprietà disableGateway del gateway a true. È possibile impostare il valore usando l'API REST Creare o aggiornare il servizio , il comando az apim update nell'interfaccia della riga di comando di Azure, il cmdlet set-azapimanagement di Azure PowerShell o altri strumenti di Azure.

Nota

È possibile disabilitare il routing a un gateway a livello di area solo quando si usa il routing predefinito di Gestione API, non una soluzione di routing personalizzata.

Per disabilitare un gateway a livello di area usando l'interfaccia della riga di comando di Azure:

  1. Usare il comando az apim show per visualizzare i percorsi, lo stato del gateway e gli URL internazionali configurati per l'istanza di Gestione API.

    az apim show --name contoso --resource-group apim-hello-world-resource \
    --query "additionalLocations[].{Location:location,Disabled:disableGateway,Url:gatewayRegionalUrl}" \
    --output table

    Output di esempio:

    Location    Disabled    Url
----------  ----------  ------------------------------------------------------------
West US 2   True        https://contoso-westus2-01.regional.azure-api.net
West Europe True        https://contoso-westeurope-01.regional.azure-api.net

  2. Usare il comando az apim update per disabilitare il gateway in una posizione disponibile, ad esempio Stati Uniti occidentali 2.

    az apim update --name contoso --resource-group apim-hello-world-resource \
--set additionalLocations[location="West US 2"].disableGateway=true

    L'aggiornamento potrebbe richiedere alcuni minuti.

  3. Verificare che il traffico indirizzato all'URL del gateway a livello di area venga reindirizzato a un'altra area.

Per ripristinare il routing al gateway a livello di area, impostare il valore di disableGateway su false.

Reti virtuali

Questa sezione fornisce considerazioni sulle distribuzioni in più aree quando l'istanza di Gestione API viene inserita in una rete virtuale.

  • Configurare ogni rete a livello di area in modo indipendente. I requisiti di connettività, ad esempio le regole del gruppo di sicurezza di rete necessarie per una rete virtuale in un'area aggiunta, sono in genere uguali a quelli per una rete nell'area primaria.
  • Le reti virtuali nelle diverse aree non devono essere sottoposte a peering.

Importante

Se configurata in modalità VNet interna, ogni gateway a livello di area deve avere anche connettività in uscita sulla porta 1433 al database SQL di Azure configurato per l'istanza di Gestione API, che si trova solo nell'area primaria. Assicurarsi di consentire la connettività al nome di dominio completo o all'indirizzo IP di questo database SQL di Azure in qualsiasi route o regole del firewall configurate per le reti nelle aree secondarie; in questo scenario non è possibile usare il tag del servizio SQL di Azure. Per trovare il nome del database SQL di Azure nell'area primaria, passare alla pagina Rete>Stato rete dell'istanza di Gestione API nel portale.

Indirizzi IP

  • Un indirizzo IP virtuale pubblico viene creato in ogni area aggiunta con una rete virtuale. Per le reti virtuali in modalità esterna o interna, questo indirizzo IP pubblico viene usato per il traffico di gestione sulla porta 3443.

    • Modalità rete virtuale esterna: gli indirizzi IP pubblici sono necessari anche per instradare il traffico HTTP pubblico ai gateway API.

    • Modalità rete virtuale interna: viene creato anche un indirizzo IP privato in ogni area aggiunta con una rete virtuale. Usare questi indirizzi per connettersi all'interno della rete agli endpoint di Gestione API nelle aree primarie e secondarie.

Definizione dei percorsi di trasferimento

  • Modalità rete virtuale esterna: il routing del traffico HTTP pubblico ai gateway internazionali viene gestito automaticamente, nello stesso modo in cui si tratta di un'istanza di Gestione API non di rete.

  • Modalità rete virtuale interna: il traffico HTTP privato non viene instradato o con carico bilanciato ai gateway a livello di area per impostazione predefinita. Gli utenti possiedono il routing e sono responsabili del trasferimento della propria soluzione per gestire il routing e il bilanciamento del carico privato in più aree.

Passaggi successivi