Condividi tramite

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

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à, se l'area la supporta. Per impostazione predefinita, Gestione API configura automaticamente le zone di disponibilità per l'area aggiunta, consigliata. È anche possibile configurare manualmente le zone di disponibilità per l'area aggiunta.

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

Importante

Il completamento delle modifiche apportate all'infrastruttura del servizio Gestione API, ad esempio la configurazione di domini personalizzati, l'aggiunta di certificati CA, la scalabilità, la configurazione della rete virtuale, le modifiche della zona di disponibilità e le aggiunte all'area, possono richiedere 15 minuti o più, a seconda del livello di servizio e delle dimensioni della distribuzione. Prevedere tempi più lunghi per un'istanza con un numero maggiore di unità di scala o configurazione in più aree. Modifiche progressive al servizio di gestione delle API vengono eseguite con attenzione per preservare la capacità e la disponibilità.

Durante l'aggiornamento del servizio, non è possibile apportare altre modifiche all'infrastruttura del servizio. Tuttavia, è possibile configurare API, prodotti, criteri e impostazioni utente. Il servizio non riscontra tempi di inattività del gateway e Gestione API continuerà a gestire le richieste API senza interruzioni (ad eccezione del livello Sviluppatore).

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.

  • Se configurati, i criteri rate-limit e rate-limit-by-key contano le chiamate separatamente in ogni gateway regionale della distribuzione. I criteri non aggregano tutti i dati delle chiamate per l'istanza. Analogamente, i criteri azure-openai-token-limit e llm-token-limit conteggiano separatamente l'utilizzo dei token in ogni gateway a livello di area nella distribuzione.

Prerequisiti

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. Se l'area supporta le zone di disponibilità, lasciare l'impostazione Automatica (scelta consigliata) o facoltativamente selezionare una o più zone. Se si selezionano zone specifiche, il numero di unità selezionate deve essere distribuito uniformemente tra le zone di disponibilità. Ad esempio, se si selezionano tre unità, è necessario selezionare tre zone in modo che ogni zona ospiti un'unità.
  6. Se l'istanza di Gestione API viene distribuita in una rete virtuale, configurare le impostazioni della rete virtuale nella località, comprese rete virtuale, subnet e indirizzo IP pubblico.
  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.

Instradare le chiamate API ai 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 si configurano gateway di Gestione API 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, le prestazioni migliorate provengono solo dalle risposte memorizzate nella cache in Gestione API in un'area specifica della richiesta. Il contatto con il back-end in tutto il mondo potrebbe comunque causare una latenza elevata.

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

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

  2. Selezionare l'API desiderata.

  3. Nella sezione Elaborazione in ingresso della scheda Progettazione selezionare Editor di codice.

    Screenshot che evidenzia l'editor di codice API nella scheda progettazione.

  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 regionali 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 gestione traffico personalizzata.
  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 del servizio di creazione o aggiornamento , il comando az apim update nell'interfaccia della riga di comando di Azure, il cmdlet di Azure PowerShell set-azapimanagement o altri strumenti di Azure.

Importante

  • È possibile impostare la proprietà per disabilitare il disableGateway routing a un gateway a livello di area solo quando si usa il routing predefinito in Gestione API, non una soluzione di routing personalizzata.
  • Non è possibile impostare la proprietà disableGateway per disabilitare il routing verso un gateway regionale quando l'istanza di API Management è distribuita in una rete virtuale in modalità interna. In questo caso, è necessario gestire personalmente il routing e il bilanciamento del carico tra più aree.

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 gli stessi requisiti per una rete nell'area primaria.
  • Le reti virtuali nelle diverse aree non devono essere sottoposte a peering.

Importante

Quando si configura l'istanza di Gestione API per l'uso della modalità di rete virtuale 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 . Assicurati di consentire la connettività al fully qualified domain name (FQDN) o all'indirizzo IP di questo database SQL di Azure in tutte le route o nelle regole del firewall configurate per le reti nelle regioni secondarie; in tale scenario non è possibile usare l'endpoint 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.

Routing.

  • Modalità rete virtuale esterna: Il routing del traffico HTTP pubblico ai gateway regionali viene gestito automaticamente, allo stesso modo per un'istanza di Gestione API non di rete.

  • Modalità rete virtuale interna: Il traffico HTTP privato non viene instradato né bilanciato ai gateway regionali 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.

Contenuti correlati

  • Last updated on