Espansione di Apigee in più regioni

Questa pagina si applica ad Apigee, ma non ad Apigee ibrido.

Visualizza la documentazione di Apigee Edge.

Puoi espandere un'organizzazione Apigee in più regioni. L'espansione a più regioni consente miglioramenti in queste aree:

  • Alta disponibilità: in caso di errore a livello di regione, il traffico può comunque essere gestito dalle regioni rimanenti, aumentando la disponibilità complessiva delle API.
  • Capacità elevata: le regioni aggiuntive forniscono capacità aggiuntiva per gestire il traffico delle API e spazio per eventuali picchi imprevisti di traffico senza esercitare molta pressione su un singolo ambiente, aumentando la capacità complessiva delle API.
  • Bassa latenza: altre regioni possono ridurre la latenza complessiva delle transazioni per i client gestendo le loro richieste in una regione geograficamente più vicina.

Questo documento spiega come aggiungere Apigee a una nuova regione e come rimuovere Apigee da una regione.

Aggiunta di Apigee a una nuova regione

Puoi avere un'istanza di runtime per ogni regione, quindi per aggiungere una nuova regione devi creare un'istanza completamente nuova in quella regione.

La procedura generale per aggiungere una nuova regione è la seguente:

  1. Assicurati di disporre di un intervallo di indirizzi IP appropriato nella rete di peering, come descritto nella sezione Prerequisiti. Inoltre, assicurati che il tuo account possa supportare una nuova regione, come descritto in Limiti.
  2. Definire le variabili di ambiente
  3. Creare un nuovo keyring e una nuova chiave
  4. Prenotare un nuovo intervallo di indirizzi
  5. Crea una nuova istanza
  6. Collega ambienti alla nuova istanza
  7. Configurare il routing

Ciascuno di questi passaggi è descritto nelle sezioni seguenti.

Prerequisiti

Assicurati che sulla rete siano disponibili intervalli di indirizzi IP non sovrapposti /22 e /28. Si aggiungono agli intervalli utilizzati da altre regioni.

Limiti

Per impostazione predefinita, l'organizzazione iniziale in genere viene creata con una singola regione. Quando decidi se creare una seconda regione (o successive), tieni presente che puoi aggiungere una regione solo se i diritti di licenza lo consentono. Se vuoi, puoi acquistare un pacchetto dell'organizzazione.

  • Se hai un modello di prezzi basato su abbonamento, potresti dover acquistare unità organizzative aggiuntive per consentire l'espansione a più regioni. Consulta la sezione Diritti di abbonamento.
  • Se utilizzi un modello di pagamento a consumo, l'espansione in più regioni comporterà costi aggiuntivi, come spiegato in Aggiungere regioni per il pagamento a consumo.
  • Gli account di valutazione sono limitati a una regione e non possono essere espansi a una seconda regione.

Per ulteriori informazioni, consulta la Panoramica del pagamento a consumo.

Nessuna organizzazione può avere più di 10 regioni (11 per i modelli ibride).

Definisci le variabili di ambiente

Ti consigliamo di definire le variabili di ambiente riportate di seguito per garantire la coerenza tra i comandi utilizzati in questa documentazione.

export NEW_REGION_LOCATION="NEW_REGION_LOCATION"
export NEW_INSTANCE_NAME="NEW_INSTANCE_NAME"
export NETWORK_NAME"=NETWORK_NAME"
export DISK_KEY_RING_NAME="YOUR_DISK_KEY_RING_NAME"
export DISK_KEY_NAME="YOUR_DISK_KEY_NAME"
export PROJECT_ID=YOUR_PROJECT_ID
export AUTH="Authorization: Bearer $(gcloud auth print-access-token)"
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")

Dove:

  • NEW_REGION_LOCATION è la posizione fisica della nuova istanza. I valori validi sono qualsiasi regione di Compute Engine. Per maggiori informazioni, consulta Regioni e zone. Ad esempio: us-west1.
  • NEW_INSTANCE_NAME è il nome della nuova regione. Deve essere univoco per la tua organizzazione. Ad esempio: my-instance-2.
  • NETWORK_NAME è il nome della rete di peering della tua organizzazione. Ad esempio: my-network. Vedi Configurare il networking di servizi.
  • DISK_KEY_RING_NAME è il nome del keyring del disco.
  • DISK_KEY_NAME è il nome dell'anello del disco.
  • AUTH definisce l'intestazione Authentication con un token di connessione. Utilizzerai questa intestazione quando chiami le API Apigee. Tieni presente che il token scade dopo un determinato periodo di tempo e quando succede, puoi semplicemente rigenerarlo utilizzando lo stesso comando. Per ulteriori informazioni, consulta la pagina di riferimento del comando print-access-token.
  • PROJECT_ID è l'ID progetto Cloud.
  • PROJECT_NUMBER è il numero del tuo progetto Cloud.

    • Crea un nuovo keyring e una nuova chiave

    Ogni regione richiede la propria chiave di crittografia del disco per la rete. Google consiglia di creare anche un keyring separato per la nuova regione. Non è necessario creare una nuova chiave di crittografia del database perché tutte le istanze di un'organizzazione condividono la stessa chiave di crittografia del database.

    Per ulteriori dettagli, consulta Informazioni sulle chiavi di crittografia Apigee.

    Per creare un nuovo keyring e una nuova chiave di crittografia del disco:

    1. Crea un nuovo keyring del disco utilizzando il comando gcloud: 
      gcloud kms keyrings create $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

      Verifica che il keyring del disco sia impostato sulla stessa località dell'istanza. Ogni istanza e keyring devono avere una propria posizione.

      gcloud kms keyrings list \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID
      gcloud kms keyrings describe $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID
    2. Crea una nuova chiave del disco utilizzando il comando kms keys create, ad esempio: 
      gcloud kms keys create $DISK_KEY_NAME --keyring $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION --purpose "encryption" --project $PROJECT_ID

      È possibile fare riferimento alla chiave tramite il relativo percorso della chiave. Puoi ottenere il percorso della chiave con il seguente comando:

      gcloud kms keys list \
  --location=$NEW_REGION_LOCATION \
  --keyring=$DISK_KEY_RING_NAME \
  --project=$PROJECT_ID

      Il percorso della chiave sarà simile al seguente:

      projects/PROJECT_ID/locations/NEW_REGION_LOCATION/keyRings/my-disk-key-ring/cryptoKeys/my-disk-key
    3. Concedi all'agente di servizio Apigee l'accesso in modo da utilizzare la nuova chiave eseguendo il comando gcloud kms keys add-iam-policy-binding; ad esempio: 
      gcloud kms keys add-iam-policy-binding $DISK_KEY_NAME \
  --location $NEW_REGION_LOCATION \
  --keyring $DISK_KEY_RING_NAME \
  --member serviceAccount:service-$PROJECT_NUMBER@gcp-sa-apigee.iam.gserviceaccount.com \
  --role roles/cloudkms.cryptoKeyEncrypterDecrypter \
  --project $PROJECT_ID

      Verifica che la chiave sia associata all'agente di servizio Apigee.

      gcloud kms keys get-iam-policy $DISK_KEY_NAME \
  --keyring $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID
      gcloud kms keys describe $DISK_KEY_NAME \
  --keyring $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

    Prenota un nuovo intervallo di indirizzi

    Prenota gli indirizzi IP per l'intervallo di indirizzi della tua rete di peering. Per ulteriori informazioni e considerazioni importanti, consulta anche Informazioni sugli intervalli di peering.

    1. Crea queste variabili di ambiente: 
      NEW_RANGE_NAME_22=YOUR_CIDR_22_RANGE_NAME
NEW_RANGE_NAME_28=YOUR_CIDR_28_RANGE_NAME
NETWORK_NAME=YOUR_NETWORK_NAME

      Dove:

      • NEW_RANGE_NAME_22 è il nome dell'intervallo di indirizzi IP con lunghezza CIDR /22 che creerai. Puoi assegnare all'intervallo il nome che preferisci. Ad esempio: google-svcs-new_22
      • NEW_RANGE_NAME_28 è il nome dell'intervallo di indirizzi IP con lunghezza CIDR /28 che creerai. Puoi assegnare all'intervallo il nome che preferisci. Ad esempio: google-svcs-new_28
      • NETWORK_NAME è il nome della risorsa di rete in cui devono essere prenotati gli indirizzi.

        Google crea una rete predefinita (denominata default) per ogni nuovo progetto, che puoi utilizzare. Tuttavia, Google sconsiglia di utilizzare la rete predefinita per scopi diversi dai test.

    2. Crea un intervallo IP di rete con una lunghezza CIDR di /22: 
      gcloud compute addresses create $NEW_RANGE_NAME_22 \
  --global \
  --prefix-length=22 \
  --description="Peering range for Apigee services" \
  --network=$NETWORK_NAME \
  --purpose=VPC_PEERING \
  --project=$PROJECT_ID

      Se l'operazione riesce, gcloud risponde con quanto segue:

      Created [https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/addresses/google-svcs-new].

      Convalida l'indirizzo di computing creato:

      gcloud compute addresses list \
  --global \
  --project=$PROJECT_ID
      gcloud compute addresses describe $NEW_RANGE_NAME_22 \
  --global \
  --project=$PROJECT_ID

      Dopo aver creato un intervallo di indirizzi IP, gli indirizzi vengono associati al progetto finché non li rilasci.

    3. Crea un intervallo IP di rete con una lunghezza CIDR di /28. Questo intervallo è obbligatorio e viene utilizzato da Apigee per la risoluzione dei problemi e non può essere personalizzato o modificato. 
      gcloud compute addresses create $NEW_RANGE_NAME_28 \
  --global \
  --prefix-length=28 \
  --description="Peering range for supporting Apigee services" \
  --network=$NETWORK_NAME \
  --purpose=VPC_PEERING \
  --project=$PROJECT_ID

      4. Convalida l'indirizzo di computing creato:

      gcloud compute addresses list \
  --global \
  --project=$PROJECT_ID
       gcloud compute addresses describe $NEW_RANGE_NAME_28 \
  --global \
  --project=$PROJECT_ID
    4. Recupera i nomi degli intervalli di peering: 
      gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID
    5. Aggiungi i nuovi intervalli riservati alla rete in peering con il seguente comando, dove $NEW_RANGE_NAME_22 e $NEW_RANGE_NAME_28 sono i nomi dei nuovi intervalli, mentre ORIGINAL_RANGE_NAME_1 e ORIGINAL_RANGE_NAME_n sono i nomi degli intervalli di peering riservati restituiti nel comando precedente: 
      gcloud services vpc-peerings update --service=servicenetworking.googleapis.com \
  --network=$NETWORK_NAME \
  --ranges=$NEW_RANGE_NAME_22,$NEW_RANGE_NAME_28,ORIGINAL_RANGE_NAME_1,ORIGINAL_RANGE_NAME_n \
  --project=$PROJECT_ID

      6. Convalida le modifiche di peering VPC che sono state aggiornate:

      gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID

    Creazione di una nuova istanza

    Crea una nuova istanza per la regione utilizzando l'API Instances.

    Con peering VPC

    Se Apigee è stato configurato per utilizzare il peering VPC, utilizza questa chiamata API per creare l'istanza: 

    curl -X POST -H "$AUTH" \
  -H "Content-Type: application/json" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances" \
  -d '{
    "name":"'"$NEW_INSTANCE_NAME"'",
    "location":"'"$NEW_REGION_LOCATION"'",
    "diskEncryptionKeyName":"KEY_PATH",
    "ipRange":"IP_ADDRESS_1/28, IP_ADDRESS_2/22"  # OPTIONAL
  }'

    Dove:

    • KEY_PATH è il percorso della chiave della chiave di crittografia del disco che hai creato in Creare un nuovo keyring e una nuova chiave.
    • IP_ADDRESS_* sono indirizzi IP CIDR per gli intervalli CIDR /22 e /28 utilizzati per creare l'istanza Apigee. Tieni presente che ipRange è facoltativo. Se non fornisci questo campo, Apigee richiede automaticamente un blocco CIDR /22 e /28 disponibile dal networking dei servizi. Vedi anche API delle istanze Apigee.

      • Il completamento di questa richiesta può richiedere fino a 20 minuti perché Apigee deve creare e avviare un nuovo cluster Kubernetes, installare le risorse Apigee su quel cluster e configurare il bilanciamento del carico.

    Senza peering VPC

    Se Apigee non è stato configurato per utilizzare il peering VPC, utilizza questa chiamata API per creare l'istanza: 

    curl -X POST -H "$AUTH" \
  -H "Content-Type:application/json" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances" \
  -d '{
    "name":"'"$INSTANCE_NAME"'",
    "location":"'"$RUNTIME_LOCATION"'",
    "diskEncryptionKeyName":"'"KEY_PATH"'",
    "consumerAcceptList":[ARRAY_OF_PROJECT_IDS]
  }'

    Dove:

    • KEY_PATH è il percorso della chiave della chiave di crittografia del disco che hai creato in Creare un nuovo keyring e una nuova chiave. Vedi anche API delle istanze Apigee.
    • consumerAcceptList(Facoltativo) Specifica un elenco di ID progetto Google Cloud che possono connettersi in modo privato al collegamento del servizio VPC Apigee. Il collegamento al servizio è un'entità utilizzata con Google Cloud Private Service Connect per consentire ai producer di servizi (in questo caso, Apigee) di esporre i servizi ai consumer (in questo caso, uno o più progetti Cloud di tua proprietà). Per impostazione predefinita, viene utilizzato il progetto Cloud già associato alla tua organizzazione Apigee. Ad esempio: "consumerAccettoList": ["progetto1", "progetto2", "progetto3"]

    Il completamento di questa richiesta può richiedere fino a 20 minuti perché Apigee deve creare e avviare un nuovo cluster Kubernetes, installare le risorse Apigee su quel cluster e configurare il bilanciamento del carico.

    timer L'operazione di creazione dell'istanza richiede circa 30 minuti.

    Per controllare lo stato della richiesta di creazione dell'istanza di runtime, esegui questo comando. Quando lo stato è ATTIVO, puoi andare al passaggio successivo.

    curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances/$NEW_INSTANCE_NAME"

    Per maggiori dettagli sulla creazione di un'istanza di runtime, inclusi contesto aggiuntivo e informazioni sulla risoluzione dei problemi, consulta Passaggio 5: crea un'istanza di runtime Apigee.

    Collega gli ambienti alla nuova istanza

    Dopo aver creato l'istanza, devi collegarvi gli ambienti, altrimenti non potrà rispondere alle richieste API.

    Gli ambienti sono condivisi tra le istanze; di conseguenza, devi collegare gli ambienti esistenti alla nuova regione. Non definisci nuovi ambienti per la nuova regione. Se definisci un nuovo ambiente per la nuova regione che gestisce gli stessi percorsi base per gli stessi host del tuo ambiente originale, le chiamate di runtime potrebbero restituire HTTP 503 errori.

    Quando compili una nuova regione con ambienti, non è necessario collegare gli ambienti ai gruppi di ambienti perché sono già collegati ai rispettivi gruppi. Devi solo collegare gli ambienti alla nuova istanza.

    Per collegare i tuoi ambienti alla nuova regione, utilizza l'API di collegamento delle istanze come mostrato nell'esempio seguente:

    curl -X POST -H "$AUTH" \
  -H "Content-Type: application/json" \
  https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances/$NEW_INSTANCE_NAME/attachments \
  -d '{
    "environment":"ENVIRONMENT_NAME"
  }'

    Per ottenere un elenco dei tuoi ambienti:

    curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/environments"

    Devi collegare ogni ambiente con una chiamata separata all'API Instances Attachment. Non puoi collegare più di un ambiente in una singola chiamata.

    Configura il routing

    Puoi configurare il routing di rete nella nuova regione utilizzando un gruppo di istanze gestite (MIG) o una configurazione basata su Private Service Connect (PSC).

    Configurare il routing PSC

    I passaggi seguenti spiegano come configurare il routing nella nuova regione utilizzando PSC.

    Panoramica

    La figura seguente mostra l'architettura di alto livello con direzione nord per PSC multiregionale:

    Diagramma dell'indirizzamento PSC in più regioni.

    Figura 1: architettura multiregionale in direzione nord con PSC

    Come illustra la Figura 1, creerai un gruppo di endpoint di rete (NEG) nel progetto che comunica con un collegamento a un servizio nella regione in cui risiede la nuova istanza Apigee. I NEG Apigee per tutte le regioni sono connessi al servizio di backend del bilanciatore del carico esterno globale di produzione Apigee.

    Crea un gruppo di endpoint di rete per la nuova regione

    Segui questi passaggi per creare e configurare un bilanciatore del carico con un gruppo di endpoint di rete (NEG) per la nuova regione:

    1. Crea un nuovo NEG:
      1. Recupera il collegamento al servizio dall'istanza che hai creato in precedenza: 
        curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

        Nel seguente output di esempio, il valore serviceAttachment viene mostrato in grassetto: 

        {
  "instances": [
    {
      "name": "us-west1",
      "location": "us-west1",
      "host": "10.82.192.2",
      "port": "443",
      "createdAt": "1645731488019",
      "lastModifiedAt": "1646504754219",
      "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
      "state": "ACTIVE",
      "peeringCidrRange": "SLASH_22",
      "runtimeVersion": "1-7-0-20220228-190814",
      "ipRange": "10.82.192.0/22,10.82.196.0/28",
      "consumerAcceptList": [
        "875609189304"
      ],
      "serviceAttachment": "projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7"
    }
  ]
}

      2. Crea un NEG che punta al collegamento al servizio ottenuto dal corpo della risposta dell'istanza nel passaggio precedente. 

        gcloud compute network-endpoint-groups create NEG_NAME \
  --network-endpoint-type=private-service-connect \
  --psc-target-service=TARGET_SERVICE \
  --region=$NEW_REGION_LOCATION \
  --network=NETWORK_NAME \
  --subnet=SUBNET_NAME \
  --project=PROJECT_ID

        Sostituisci quanto segue:

        • NEG_NAME: un nome per il gruppo di endpoint di rete.
        • TARGET_SERVICE: il collegamento al servizio a cui vuoi connetterti. Ad esempio: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
        • NETWORK_NAME: (facoltativo) nome della rete in cui viene creato il NEG. Se ometti questo parametro, viene utilizzata la rete del progetto default.
        • SUBNET_NAME: nome della subnet utilizzata per la connettività privata al producer. Le dimensioni della subnet possono essere ridotte: il NEG PSC richiede solo un IP dalla subnet. Per Apigee, è necessario un solo NEG PSC per regione. La subnet può essere condivisa e utilizzata da VM o altre entità. Se non viene specificata una subnet, gli endpoint di rete possono appartenere a qualsiasi subnet nella regione in cui viene creato il gruppo di endpoint di rete.
        • PROJECT_ID Il progetto Cloud già associato alla tua organizzazione Apigee o un progetto Cloud incluso in consumerAcceptlist al momento della creazione dell'istanza di runtime Apigee.
    2. Recupera il nome del servizio di backend per il bilanciatore del carico Apigee di produzione: 
      gcloud compute backend-services list --project=$PROJECT_ID
    3. Aggiungi il NEG come backend del servizio di backend: 
      gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --network-endpoint-group=NEG_NAME \
  --network-endpoint-group-region=$NEW_REGION_LOCATION \
  --global --project=$PROJECT_ID

      Sostituisci quanto segue:

      • BACKEND_SERVICE_NAME: il nome del servizio di backend.
      • NEG_NAME: il nome del gruppo di endpoint di rete.
    4. (Facoltativo) Puoi impostare un criterio di traffico per il rilevamento di outlier sul servizio di backend per gestire automaticamente gli scenari di failover. Consulta quanto segue per saperne di più:

    Testa la configurazione finale

    Chiama un proxy API. Vedi Eseguire il deployment di un proxy di esempio.

    Configura il routing del gruppo di istanze gestite

    I passaggi seguenti spiegano come configurare il routing nella nuova regione utilizzando un gruppo di istanze gestite.

    Panoramica

    La figura seguente mostra l'architettura di alto livello in direzione nord per più regioni che utilizzano gruppi di istanze gestite (MIG):

    Diagramma dell'architettura in direzione nord per PSC multiregionale.

    Figura 2: architettura multiregionale in direzione nord con gruppo di istanze gestite

    Come illustra la Figura 2, creerai un gruppo di istanze gestite nel progetto per comunicare con un bilanciatore del carico di cui è stato eseguito il deployment nella regione in cui risiede la nuova istanza Apigee. I proxy MIG per tutte le regioni sono connessi al backend del bilanciatore del carico esterno globale di produzione Apigee.

    Crea un gruppo di istanze gestite per la nuova regione

    Per creare e configurare un gruppo di istanze gestite per la nuova regione:

    1. Abilita l'accesso privato Google per una subnet della tua rete VPC.

      Per abilitare l'accesso privato Google per una subnet della tua rete VPC, segui i passaggi elencati in Abilitare l'accesso privato Google.

    2. Configura le variabili di ambiente:

      Le istruzioni in questa sezione utilizzano le variabili di ambiente per fare riferimento alle stringhe utilizzate più volte. Ti consigliamo di impostare i seguenti valori prima di continuare:

      MIG_NAME=YOUR_MIG_NAME
VPC_NAME=YOUR_VPC_NAME       # If you are using a shared VPC, use the shared VPC name
VPC_SUBNET=YOUR_SUBNET_NAME     # Private Google Access must be enabled for this subnet
NEW_REGION_LOCATION=YOUR_NEW_REGION      # The same region as your new Apigee runtime instance
APIGEE_ENDPOINT=APIGEE_INSTANCE_IP        # See the tip below for details on getting this IP address value
    3. Creare un gruppo di istanze gestite. In questo passaggio, creerai e configurerai un gruppo di istanze gestite.
      1. Crea un modello di istanza eseguendo questo comando. 
        gcloud compute instance-templates create $MIG_NAME \
  --project $PROJECT_ID \
  --region $NEW_REGION_LOCATION \
  --network $VPC_NAME \
  --subnet $VPC_SUBNET \
  --tags=https-server,apigee-mig-proxy,gke-apigee-proxy \
  --machine-type e2-medium --image-family debian-10 \
  --image-project debian-cloud --boot-disk-size 20GB \
  --no-address \
  --metadata ENDPOINT=$APIGEE_ENDPOINT,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh

        Come puoi vedere da questo comando, le macchine sono di tipo e2-medium. Eseguono Debian 10 e hanno 20 GB di disco. Lo script startup-script.sh configura il gruppo di istanze gestite in modo da instradare il traffico in entrata dal bilanciatore del carico all'istanza Apigee.

      2. Crea un gruppo di istanze gestite eseguendo questo comando: 
        gcloud compute instance-groups managed create $MIG_NAME \
  --project $PROJECT_ID --base-instance-name apigee-mig \
  --size 2 --template $MIG_NAME --region $NEW_REGION_LOCATION
      3. Configura la scalabilità automatica per il gruppo eseguendo questo comando: 
        gcloud compute instance-groups managed set-autoscaling $MIG_NAME \
  --project $PROJECT_ID --region $NEW_REGION_LOCATION --max-num-replicas 3 \
  --target-cpu-utilization 0.75 --cool-down-period 90
      4. Definisci una porta denominata eseguendo questo comando: 
        gcloud compute instance-groups managed set-named-ports $MIG_NAME \
  --project $PROJECT_ID --region $NEW_REGION_LOCATION --named-ports https:443
    4. Recupera il nome del servizio di backend per il bilanciatore del carico Apigee di produzione: 
      gcloud compute backend-services list --project=$PROJECT_ID
    5. Aggiungi il gruppo di istanze gestite al servizio di backend con il seguente comando: 
      gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --project $PROJECT_ID --instance-group $MIG_NAME \
  --instance-group-region $NEW_REGION_LOCATION \
  --balancing-mode UTILIZATION --max-utilization 0.8 --global

      Sostituisci BACKEND_SERVICE_NAME con il nome del servizio di backend.

    Testa la configurazione finale

    Chiama un proxy API. Vedi Eseguire il deployment di un proxy di esempio.

    Aggiungere regioni

    L'aggiunta di più regioni a un ambiente Apigee può fornire alta disponibilità, maggiore capacità e minore latenza per le tue API. Un deployment su più regioni supporta l'alta disponibilità perché non è necessario il failover manuale perché XLB controllerà l'integrità di ogni regione. È disponibile una capacità maggiore quando più regioni gestiscono le stesse API contemporaneamente. Inoltre, se i client API si trovano in più regioni, la gestione dell'API da una regione più vicina ai client contribuirà a ridurre la latenza e a migliorare le prestazioni.

    Esempio: un deployment in più regioni migliora disponibilità, capacità e latenza

    In un deployment multiregione attivo e attivo, il traffico viene gestito contemporaneamente da due regioni. Aggiungi un servizio di backend per il gruppo di istanze gestite di ogni regione allo stesso bilanciatore del carico HTTPS esterno (XLB), come spiegato nel passaggio 8e(3) della scheda Routing esterno (MIG) nella sezione Passaggio 8: configura il routing. Per maggiori informazioni, vedi anche Creare un gruppo di istanze gestite per la nuova regione.

    Per ogni richiesta, lo XLB sceglierà la regione più vicina al client, a meno che il numero di richieste non superi il limite impostato per un determinato backend. Per ulteriori informazioni su come i bilanciatori del carico esterni instradano il traffico, consulta Ottimizzazioni della capacità delle applicazioni con il bilanciamento del carico globale.

    Aggiunta di regioni per il pagamento a consumo

    Con il modello di prezzi Pay-as-you-go, puoi impostare il numero minimo di nodi gateway Apigee per un ambiente. In questo modo è possibile garantire che le regioni vengano sempre eseguite con capacità aggiuntiva per supportare immediatamente il traffico di failover, in caso di errore della regione.

    Impostazione del numero minimo di nodi gateway Apigee

    Se sei in grado di gestire tutto il normale traffico API su 2 regioni attive, ciascuna con 4 nodi gateway Apigee, ogni regione dovrebbe avere un minimo di 8 nodi ciascuna. allo scopo di supportare immediatamente la perdita di una regione. Consulta la pagina Informazioni sui nodi Apigee per saperne di più su come determinare il numero di nodi necessari per gestire il traffico API. Tieni presente che il numero minimo di nodi è impostato per ambiente, ma applicato in base alla regione. Ad esempio, se imposti il minimo su 8, ogni regione avrà un minimo di 8 nodi.

    Costo

    Nell'esempio precedente, ti verrà addebitato il costo dell'esecuzione di almeno 16 nodi gateway Apigee (8 nodi x 2 regioni). Il costo può aumentare man mano che il numero di nodi aumenta automaticamente per gestire il traffico aggiuntivo, fino al massimo.

    Rimozione di Apigee da una regione in corso...

    Per disautorizzare un'istanza Apigee dalla gestione del traffico API, segui questi passaggi per garantire un servizio ininterrotto (nessun tempo di inattività per le tue API):

    1. Abilita lo svuotamento della connessione sul servizio di backend. Lo svuotamento della connessione è un processo che garantisce che alle richieste esistenti in corso venga concesso il tempo per il completamento quando un backend viene rimosso dal servizio di backend.
    2. Se Cloud DNS è stato configurato per instradare il traffico a questa regione Apigee tramite il criterio di routing round robin ponderato, rimuovi la configurazione DNS, come descritto in Gestire i criteri di routing e i controlli di integrità DNS.
    3. Scollega il backend del gruppo di istanze gestite dal servizio di backend. Questo, insieme allo svuotamento della connessione, garantisce che l'istanza Apigee non riceva nuovo traffico, ma consente il completamento di eventuali richieste in corso.
    4. Elimina l'istanza Apigee e il gruppo di istanze gestite corrispondente. Vedi Eliminare un'istanza.