Espansione di Apigee in più regioni

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

Visualizza documentazione di Apigee Edge.

Puoi espandere una piattaforma Apigee organizzazione in più regioni. L'espansione multiregionale consente miglioramenti in queste aree:

  • Disponibilità elevata: in caso di errore di una regione, il traffico può comunque essere gestito tramite le regioni rimanenti, aumentando la disponibilità complessiva delle tue API.
  • Capacità elevata: le regioni aggiuntive forniscono ulteriore capacità per gestire il traffico API. e lasciare spazio a picchi imprevisti di traffico senza aumentare la pressione su un singolo ambiente, aumentando la capacità complessiva delle tue API.
  • Bassa latenza: regioni aggiuntive possono ridurre la latenza complessiva delle transazioni per i client rispondendo alle 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 regione, quindi per aggiungere una nuova regione devi creare una 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 descritti 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. Crea 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. Questo è oltre a quelli utilizzati da altre regioni.

Limiti

Per impostazione predefinita, l'organizzazione iniziale viene in genere creata con un'unica regione. Quando decidi se creare una seconda regione (o successiva), tieni presente che puoi aggiungere una regione soltanto se i tuoi diritti di licenza sono disponibili consentirlo. Se vuoi, puoi acquistare un pacchetto organizzazioni.

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

Per saperne di più, consulta Panoramica del pagamento a consumo.

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

Definisci le variabili di ambiente

Ti consigliamo di definire le seguenti variabili di ambiente per garantire la coerenza tra usati 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 località fisica della nuova istanza. I valori validi sono qualsiasi regione di Compute Engine. Per ulteriori informazioni, vedi Regioni e zone. Ad esempio: us-west1.
  • NEW_INSTANCE_NAME è il nome della nuova regione. Deve essere univoco dell'organizzazione. Ad esempio: my-instance-2.
  • NETWORK_NAME è il nome del peering della tua organizzazione in ogni rete. Ad esempio: my-network. Vedi Configurare il networking di servizi.
  • DISK_KEY_RING_NAME è un nome per il keyring del disco.
  • DISK_KEY_NAME è un nome per l'anello del disco.
  • AUTH definisce l'intestazione Authentication con un token di connessione. Tu userà questa intestazione durante la chiamata alle API Apigee. Tieni presente che il token scade dopo il giorno un periodo di tempo e quando succede, puoi semplicemente rigenerarlo utilizzando lo stesso comando. Per Per ulteriori informazioni, consulta la pagina di riferimento per il comando Print-access-token.
  • PROJECT_ID è l'ID del tuo progetto Cloud.
  • PROJECT_NUMBER è il numero del progetto Cloud.

Crea un nuovo keyring e una nuova chiave

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

Per ulteriori dettagli, vedi Informazioni le 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 il keyring deve 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 percorso della chiave. Puoi ottenere il percorso della chiave il seguente comando:

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

    Il percorso della chiave è 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 per utilizzare la nuova chiave eseguendo il comando 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 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 di lunghezza CIDR /22 che creerai. Puoi assegnare un nome l'intervallo come preferisci. Ad esempio: google-svcs-new_22
    • NEW_RANGE_NAME_28 è il nome dell'intervallo di indirizzi IP di lunghezza CIDR /28 che creerai. Puoi assegnare un nome l'intervallo come preferisci. Ad esempio: google-svcs-new_28
    • NETWORK_NAME è il nome della risorsa di rete in cui gli indirizzi deve essere prenotato.

      Google crea un valore predefinito network (denominata default) per per ogni nuovo progetto, quindi puoi usarlo. Tuttavia, Google sconsiglia di utilizzare rete predefinita per qualsiasi attività diversa dai test.

  2. Crea un intervallo IP di rete con 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, questi vengono associati a il progetto finché non li rilasci.

  3. Crea un intervallo IP di rete con 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. Ottieni i nomi degli intervalli di peering: 
    gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID
  5. Aggiungi gli intervalli appena riservati alla rete in peering con il comando seguente, $NEW_RANGE_NAME_22 e $NEW_RANGE_NAME_28 sono il nuovo intervallo e ORIGINAL_RANGE_NAME_1 e ORIGINAL_RANGE_NAME_n sono l'intervallo di peering riservato nomi restituiti dal 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 vpc-peering che sono state aggiornate:

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

Crea 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 Crea un nuovo keyring e una nuova chiave.
  • IP_ADDRESS_* sono indirizzi IP CIDR per gli intervalli CIDR /22 e /28 utilizzati per per creare l'istanza Apigee. Tieni presente che il campo ipRange è facoltativo. Se non fornisci su questo campo, Apigee richiede automaticamente un blocco CIDR /22 e /28 disponibile a Service Networking. 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 è 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 Crea un nuovo keyring e una nuova chiave. Vedi anche API delle istanze Apigee.
  • consumerAcceptList(Facoltativo) Specifica un elenco di account Google Cloud ID progetto che possono connettersi privatamente al collegamento di servizio del VPC di Apigee. Servizio il collegamento è un'entità utilizzata con Google Cloud Private Service Connect per consentire producer di servizi (in questo caso Apigee) per esporre i servizi ai consumatori uno o più progetti Cloud di tua proprietà). Per impostazione predefinita, utilizziamo al progetto Cloud già associato alla tua organizzazione Apigee. Ad esempio: "consumerAccettaList": ["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 il completamento dell'operazione richiede circa 30 minuti.

Per controllare lo stato della richiesta di creazione dell'istanza di runtime, esegui questo comando . Se 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 per informazioni sulla risoluzione dei problemi, consulta il Passaggio 5: crea un'istanza di runtime Apigee.

Collega ambienti alla nuova istanza

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

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

Quando popoli una nuova regione con ambienti, non è necessario collegare gli ambienti a gruppi di ambienti: sono già associati ai propri gruppi. Devi collegare solo gli ambienti alla nuova istanza.

Per collegare i tuoi ambienti alla nuova regione, utilizza l'API InstancesAttachment (API di collegamento istanze) come 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 degli 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. Tu non può 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).

Configura 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 verso nord per la PSC multiregionale:

Diagramma del rouiting PSC multiregionale.

Figura 1: architettura multiregionale legata a nord con PSC

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

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 creata 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 è 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 punti al collegamento al servizio ottenuto dalla 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 che vuoi connettersi. 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 parametro viene usata 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 dalle VM altre entità. Se non viene specificata una subnet, gli endpoint di rete possono appartenere a qualsiasi subnet nella regione in cui è stato creato il gruppo di endpoint di rete.
      • PROJECT_ID Il progetto Cloud già associato alla tua organizzazione Apigee o un progetto Cloud incluso nel consumerAcceptlist, quando è stata creata l'istanza di runtime Apigee.
  2. Ottieni 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 del traffico per il rilevamento di outlier nel servizio di backend per la gestione scenari di failover automaticamente. Per ulteriori informazioni, vedi quanto segue:

Testa la configurazione finale

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

Configura il routing MIG

I passaggi seguenti spiegano come configurare il routing nella nuova regione utilizzando un'istanza gestita (MIG).

Panoramica

La figura seguente mostra l'architettura di alto livello in direzione nord per più regioni utilizzando gruppi di istanze gestite:

Diagramma dell'architettura verso nord per la PSC a più regioni.

Figura 2: architettura multiregionale legata a nord con gruppo di istanze gestite

Come illustrato nella Figura 2, creerai un gruppo di istanze gestite nel tuo progetto per comunicare di un bilanciatore del carico di cui è stato eseguito il deployment nella regione in cui si trova la nuova istanza Apigee. La I proxy MIG per tutte le regioni sono connessi all'esterno globale di produzione Apigee il backend del bilanciatore del carico.

Crea un gruppo di istanze gestite per la nuova regione

Segui questi passaggi 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 Attivazione della versione privata di Google Accesso.

  2. Configura le variabili di ambiente:

    Le istruzioni in questa sezione usano le variabili di ambiente per fare riferimento all'uso ripetuto stringhe. Ti consigliamo di impostarli 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-12 \
  --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. Corrono Debian 12 e avere 20 GB di disco. Lo script startup-script.sh configura il gruppo di istanze gestite per instradare il traffico in entrata dal carico di fatturazione 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. Ottieni 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 tuo 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 un proxy di esempio.

Aggiunta di regioni

L'aggiunta di più regioni a un ambiente Apigee può fornire disponibilità elevata, maggiore capacità, e latenza più bassa per le tue API. Un deployment multiregionale supporta l'alta disponibilità perché il failover manuale non è necessaria poiché la XLB eseguirà il controllo di integrità su ogni regione. Viene fornita una capacità maggiore quando più regioni gestiscono la stessa offerta contemporaneamente. Inoltre, se i tuoi client API si trovano in più regioni, la tua API verrà gestita provenienti da una regione più vicina ai tuoi clienti contribuirà a ridurre la latenza e a migliorare le prestazioni.

Esempio: un deployment multiregionale migliora disponibilità, capacità e latenza

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

Per ogni richiesta, il XLB sceglierà la regione più vicina al client, a meno che il numero di richieste supera il limite impostato per un determinato backend. Vedi ottimizzazioni della capacità delle applicazioni con il bilanciamento del carico globale per saperne di più su come i bilanciatori del carico instradano il traffico.

Aggiunta di regioni per il pagamento a consumo

Con il modello di determinazione del prezzo con 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, ciascuna regione deve avere almeno 8 nodi. per supportare immediatamente la perdita di una regione. Vedi 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 viene impostato per ambiente, ma applicato in base alla regione. Ad esempio, se Se imposti il minimo su 8, ogni regione avrà un minimo di 8 nodi.

Costo

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

Rimozione di Apigee da una regione

Per rimuovere un'istanza Apigee dalla gestione del traffico API, segui questi passaggi per assicurarti servizio ininterrotto (senza tempi di inattività per le API):

  1. Attiva lo svuotamento della connessione sul servizio di backend. Lo svuotamento della connessione è un processo che garantisce che i dati in corso il completamento delle richieste viene concesso quando un backend viene rimosso dal servizio di backend.
  2. Se Cloud DNS è stato configurato per instradare il traffico a questa regione Apigee tramite criterio di routing Round Robin ponderato, rimuovere la configurazione DNS, come descritto in Gestire i criteri di routing del DNS e i controlli di integrità.
  3. Scollega il backend del gruppo di istanze gestite dal servizio backend. Questo, insieme allo svuotamento della connessione, assicura che l'istanza Apigee non riceva nuovo traffico, ma consente qualsiasi traffico in-flight richieste da completare.
  4. Eliminare l'istanza Apigee e il gruppo di istanze gestite corrispondente. Consulta Eliminare un'istanza.