Apigee auf mehrere Regionen erweitern

Diese Seite gilt für Apigee, aber nicht für Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Sie können eine Apigee-Organisation über mehrere Regionen hinweg erweitern. Die multiregionale Erweiterung ermöglicht Verbesserungen in diesen Bereichen:

  • Hochverfügbarkeit: Bei einem Regionsausfall kann der Traffic von den verbleibenden Regionen bereitgestellt werden, wodurch sich die Gesamtverfügbarkeit Ihrer APIs erhöht.
  • Hohe Kapazität: Zusätzliche Regionen bieten zusätzliche Kapazität für die Bereitstellung Ihres API-Traffics und Platz für unerwartete Trafficspitzen, ohne eine einzelne Umgebung zu sehr zu belasten, und erhöhen die Gesamtkapazität Ihrer APIs.
  • Niedrige Latenz: Durch zusätzliche Regionen kann die Gesamttransaktionslatenz für Clients verringert werden, wenn ihre Anfragen in einer geografisch näher gelegenen Region verarbeitet werden.

In diesem Dokument wird erläutert, wie Sie Apigee einer neuen Region hinzufügen und Apigee aus einer Region entfernen.

Apigee einer neuen Region hinzufügen

Sie können eine Laufzeitinstanz pro Region haben. Wenn Sie eine neue Region hinzufügen möchten, müssen Sie eine vollständig neue Instanz in dieser Region erstellen.

So fügen Sie eine neue Region hinzu:

  1. Achten Sie darauf, dass in Ihrem Peering-Netzwerk ein geeigneter IP-Adressbereich verfügbar ist, wie unter Voraussetzungen beschrieben. Prüfen Sie außerdem, ob Ihr Konto eine neue Region unterstützt, wie unter Limits beschrieben.
  2. Umgebungsvariablen definieren
  3. Neuen Schlüsselbund und Schlüssel erstellen
  4. Neuen Adressbereich reservieren
  5. Neue Instanz erstellen
  6. Umgebungen an die neue Instanz anhängen
  7. Routing konfigurieren

Jeder dieser Schritte wird in den folgenden Abschnitten beschrieben.

Vorbereitung

Achten Sie darauf, dass in Ihrem Netzwerk /22 und /28 als nicht überlappende IP-Adressbereiche verfügbar sind. Dies gilt zusätzlich zu den von anderen Regionen verwendeten Bereichen.

Limits

Standardmäßig wird Ihre anfängliche Organisation mit einer einzelnen Region erstellt. Wenn Sie entscheiden, ob Sie eine zweite (oder nachfolgende) Region erstellen möchten, können Sie nur dann eine Region hinzufügen, wenn Ihre Lizenzberechtigungen dies zulassen. Optional können Sie ein Organisationspaket erwerben.

  • Wenn Sie ein abobasiertes Preismodell haben, müssen Sie möglicherweise zusätzliche Organisationseinheiten erwerben, um die Erweiterung auf mehrere Regionen zu ermöglichen. Weitere Informationen zu Aboberechtigungen.
  • Wenn Sie ein „Pay-as-you-go“-Preismodell haben, entstehen durch die Erweiterung in mehrere Regionen zusätzliche Kosten, wie unter Regionen für „Pay-as-you-go“ hinzufügen erläutert.
  • Eval-Konten sind auf eine einzelne Region beschränkt und können nicht auf eine zweite Region erweitert werden.

Weitere Informationen zu Pay as you go – Übersicht.

Keine Organisation darf mehr als 10 (11 bei hybriden) Regionen haben.

Umgebungsvariablen definieren

Wir empfehlen, die folgenden Umgebungsvariablen zu definieren, um die Konsistenz der in dieser Dokumentation verwendeten Befehle zu gewährleisten.

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)")

Wobei:

  • NEW_REGION_LOCATION ist der physische Standort der neuen Instanz. Dafür kann eine beliebige Compute Engine-Region verwendet werden. Weitere Informationen zu Regionen und Zonen. Beispiel: us-west1
  • NEW_INSTANCE_NAME ist der Name der neuen Instanz. Er muss für Ihre Organisation eindeutig sein. Beispiel: my-instance-2
  • NETWORK_NAME ist der Name des Peering-Netzwerks Ihrer Organisation. Beispiel: my-network Siehe Dienstnetzwerke konfigurieren.
  • DISK_KEY_RING_NAME ist ein Name für den Laufwerkschlüsselring.
  • DISK_KEY_NAME ist der Name des Laufwerkrings.
  • AUTH definiert den Authentication-Header mit einem Inhabertoken. Dieser Header wird beim Aufrufen von Apigee APIs verwendet. Beachten Sie, dass das Token nach einer gewissen Zeit abläuft. Wenn dies der Fall ist, können Sie es einfach mit demselben Befehl neu generieren. Weitere Informationen finden Sie auf der Referenzseite für den Befehl print-access-token.
  • PROJECT_ID ist die ID Ihres Cloud-Projekts.
  • PROJECT_NUMBER ist die Cloud-Projektnummer für Ihr Cloud-Projekt.

    • Neuen Schlüsselbund und Schlüssel erstellen

    Jede Region benötigt einen eigenen Schlüssel zur Laufwerksverschlüsselung für das Netzwerk. Google empfiehlt, auch einen separaten Schlüsselbund für die neue Region erstellen. Sie müssen keinen neuen Verschlüsselungsschlüssel für die Datenbank-Verschlüsselungsschlüssel erstellen, da alle Instanzen in einer Organisation denselben Datenbank-Verschlüsselungsschlüssel haben.

    Weitere Informationen zu Apigee-Verschlüsselungsschlüssel.

    So erstellen Sie einen neuen Schlüsselbund und Schlüssel zur Laufwerksverschlüsselung:

    1. Erstellen Sie mit dem Befehl gcloud einen neuen Laufwerkschlüsselbund: 
      gcloud kms keyrings create $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

      Prüfen Sie, ob der Schlüsselbund des Laufwerks auf den gleichen Standort wie die Instanz eingestellt wurde. Jede Instanz und jeder Schlüsselbund müssen einen eigenen Standort haben.

      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. Erstellen Sie mit dem Befehl kms keys create einen neuen Laufwerkschlüsselbund, zum Beispiel: 
      gcloud kms keys create $DISK_KEY_NAME --keyring $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION --purpose "encryption" --project $PROJECT_ID

      Auf den Schlüssel kann über seinen Schlüsselpfad verwiesen werden. Der Schlüsselpfad lässt sich mit folgendem Befehl abrufen:

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

      Der Schlüsselpfad sieht in etwa so aus:

      projects/PROJECT_ID/locations/NEW_REGION_LOCATION/keyRings/my-disk-key-ring/cryptoKeys/my-disk-key
    3. Gewähren Sie dem Apigee Service Agent Zugriff auf den neuen Schlüssel, indem Sie den Befehl gcloud kms keys add-iam-policy-binding ausführen. Beispiel: 
      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

      Prüfen Sie, ob der Schlüssel an den Apigee-Dienst-Agent gebunden ist.

      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

    Neuen Adressbereich reservieren

    IP-Adressen für den Adressbereich Ihres Peering-Netzwerks reservieren: Weitere Informationen und wichtige Überlegungen finden Sie unter Informationen zu Peering-Bereichen.

    1. Erstellen Sie folgende Umgebungsvariablen: 
      NEW_RANGE_NAME_22=YOUR_CIDR_22_RANGE_NAME
NEW_RANGE_NAME_28=YOUR_CIDR_28_RANGE_NAME
NETWORK_NAME=YOUR_NETWORK_NAME

      Wobei:

      • NEW_RANGE_NAME_22 ist der Name des IP-Adressbereichs der CIDR-Länge /22, den Sie erstellen. Sie können diesen Bereich beliebig benennen. Beispiel: google-svcs-new_22
      • NEW_RANGE_NAME_28 ist der Name des IP-Adressbereichs der CIDR-Länge /28, den Sie erstellen. Sie können diesen Bereich beliebig benennen. Beispiel: google-svcs-new_28
      • NETWORK_NAME ist der Name der Netzwerkressource, in der die Adressen reserviert werden sollen.

        Google erstellt für jedes neue Projekt ein Standardnetzwerk namens default, das Sie verwenden können. Google empfiehlt jedoch, das Standardnetzwerk ausschließlich für Tests zu verwenden.

    2. Erstellen Sie einen Netzwerk-IP-Bereich mit einer CIDR-Länge von /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

      Bei Erfolg gibt gcloud Folgendes zurück:

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

      Prüfen Sie die erstellte Compute-Adresse:

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

      Wenn Sie einen Bereich von IP-Adressen erstellt haben, sind die Adressen mit dem Projekt verknüpft, bis Sie sie wieder freigeben.

    3. Erstellen Sie einen Netzwerk-IP-Bereich mit einer CIDR-Länge von /28. Dieser Bereich ist erforderlich und wird von Apigee zur Fehlerbehebung verwendet. Er kann nicht angepasst oder geändert werden. 
      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. Prüfen Sie die erstellte Compute-Adresse:

      gcloud compute addresses list \
  --global \
  --project=$PROJECT_ID
       gcloud compute addresses describe $NEW_RANGE_NAME_28 \
  --global \
  --project=$PROJECT_ID
    4. Rufen Sie die Namen der Peering-Bereiche ab: 
      gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID
    5. Fügen Sie Ihrem Peering-Netzwerk die neu reservierten Bereiche mit dem folgenden Befehl hinzu, wobei:$NEW_RANGE_NAME_22 und $NEW_RANGE_NAME_28 die neuen Bereichsnamen und ORIGINAL_RANGE_NAME_1 und ORIGINAL_RANGE_NAME_n die reservierten Peering-Bereichsnamen sind, die vom vorherigen Befehl zurückgegeben wurden: 
      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. Validieren Sie die vpc-peering-Änderungen, die aktualisiert wurden:

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

    Neue Instanz erstellen

    Erstellen Sie mit der Instances API eine neue Instanz für die Region.

    Mit VPC-Peering

    Wenn Apigee für die Verwendung von VPC-Peering eingerichtet hat, erstellen Sie die Instanz mit diesem API-Aufruf: 

    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
  }'

    Wobei:

    • KEY_PATH ist der Schlüsselpfad des Schlüssels zur Laufwerksverschlüsselung, den Sie unter Neuen Schlüsselbund und Schlüssel erstellen erstellt haben.
    • IP_ADDRESS_* sind CIDR-IP-Adressen für die CIDR-Bereiche /22 und /28, die zum Erstellen der Apigee-Instanz verwendet werden. ipRange ist optional. Wenn Sie dieses Feld nicht angeben, fordert Apigee automatisch einen verfügbaren /22- und /28-CIDR-Block von Service Networking an. Siehe auch Apigee Instances API.

      • Diese Anfrage kann bis zu 20 Minuten dauern, da Apigee einen neuen Kubernetes-Cluster erstellen und starten, die Apigee-Ressourcen in diesem Cluster installieren und den Lastenausgleich einrichten muss.

    Ohne VPC-Peering

    Wenn Apigee nicht für die Verwendung von VPC-Peering eingerichtet wurde, verwenden Sie diesen API-Aufruf, um die Instanz zu erstellen: 

    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]
  }'

    Wobei:

    • KEY_PATH ist der Schlüsselpfad des Schlüssels zur Laufwerksverschlüsselung, den Sie unter Neuen Schlüsselbund und Schlüssel erstellen erstellt haben. Siehe auch Apigee Instances API.
    • consumerAcceptList(Optional) Gibt eine Liste von Google Cloud-Projekt-IDs an, die eine private Verbindung zum Dienstanhang der Apigee-VPC herstellen können. Der Dienstanhang ist eine Entität, die mit Google Private Service Connect verwendet wird, um es Diensterstellern (in diesem Fall Apigee) zu ermöglichen, Dienste für Nutzer verfügbar zu machen (in diesem Fall ein oder mehrere Cloud-Projekte, die Ihnen gehören). Standardmäßig verwenden wir das Cloud-Projekt, das bereits Ihrer Apigee-Organisation zugeordnet ist. Beispiel: "consumerAcceptList": ["project1", "project2", "project3"]

    Diese Anfrage kann bis zu 20 Minuten dauern, da Apigee einen neuen Kubernetes-Cluster erstellen und starten, die Apigee-Ressourcen in diesem Cluster installieren und den Lastenausgleich einrichten muss.

    timer Der Vorgang der Instanzerstellung dauert ungefähr 30 Minuten.

    Führen Sie den folgenden Befehl aus, um den Status Ihrer Anfrage zur Erstellung einer Laufzeitinstanz zu prüfen. Wenn der Status ACTIVE lautet, können Sie mit dem nächsten Schritt fortfahren.

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

    Weitere Informationen zum Erstellen einer Laufzeitinstanz, einschließlich zusätzlicher Kontext- und Fehlerbehebungsinformationen, finden Sie unter Schritt 5: Apigee-Laufzeitinstanz erstellen.

    Umgebungen an die neue Instanz anhängen

    Nachdem Sie die Instanz erstellt haben, müssen Sie ihr Umgebungen hinzufügen. Andernfalls kann sie nicht auf API-Anfragen antworten.

    Umgebungen werden von mehreren Instanzen gemeinsam genutzt. Daher hängen Sie vorhandene Umgebungen an die neue Region an. Definieren Sie keine neuen Umgebungen für die neue Region. Wenn Sie eine neue Umgebung für die neue Region definieren, die dieselben Basispfade für dieselben Hosts wie die ursprüngliche Umgebung bereitstellt, geben Ihre Laufzeitaufrufe möglicherweise HTTP 503-Fehler zurück.

    Wenn Sie eine neue Region mit Umgebungen füllen, müssen Sie die Umgebungen nicht an Umgebungsgruppen anhängen: Sie sind bereits mit ihren Gruppen verknüpft. Sie müssen nur die Umgebungen an die neue Instanz anhängen.

    Verwenden Sie die Instances Attachment API, um Ihre Umgebungen an die neue Region anzuhängen:

    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"
  }'

    So rufen Sie eine Liste Ihrer Umgebungen ab:

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

    Sie müssen jede Umgebung mit einem separaten Aufruf der Instances Attachment API anhängen. Pro Aufruf können Sie nur eine Umgebung anhängen.

    Routing konfigurieren

    Sie können das Netzwerkrouting in der neuen Region entweder mit einer verwalteten Instanzgruppe (Managed Instance Group, MIG) oder mit einer auf Private Service Connect (PSC) basierenden Konfiguration konfigurieren.

    PSC-Routing konfigurieren

    In den folgenden Schritten wird erläutert, wie Sie das Routing in der neuen Region mithilfe von PSC konfigurieren.

    Übersicht

    Die folgende Abbildung zeigt die allgemeine Northbound-Architektur für multiregionales PSC:

    Diagramm des multiregionalen PSC-Routing.

    Abbildung 1: Northbound-Architektur für multiregionales PSC

    Wie Abbildung 1 zeigt, erstellen Sie in Ihrem Projekt eine Netzwerk-Endpunktgruppe (NEG), die mit einem Dienstanhang in der Region kommuniziert, in der sich die neue Apigee-Instanz befindet. Die Apigee-NEGs für alle Regionen sind mit dem Backend-Dienst des globalen externen Load-Balancers von Apigee verbunden.

    Erstellen Sie eine Netzwerk-Endpunktgruppe für die neue Region

    Führen Sie die folgenden Schritte aus, um einen Load-Balancer mit einer Netzwerk-Endpunktgruppe (NEG) für die neue Region zu erstellen und zu konfigurieren:

    1. Erstellen Sie eine neue NEG:
      1. Rufen Sie den Dienstanhang aus der zuvor erstellten Instanz ab: 
        curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

        In der folgenden Beispielausgabe ist der Wert serviceAttachment fett dargestellt: 

        {
  "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. Erstellen Sie eine NEG, die auf den Serviceanhang verweist, den Sie im vorherigen Schritt aus dem Antworttext der Instanz erhalten haben. 

        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

        Dabei gilt:

        • NEG_NAME ist ein Name für die Netzwerk-Endpunktgruppe.
        • TARGET_SERVICE ist der Dienstanhang, mit dem Sie eine Verbindung herstellen möchten. Beispiel: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
        • NETWORK_NAME: (Optional) Name des Netzwerks, in dem die NEG erstellt wird. Wenn Sie diesen Parameter weglassen, wird das Projektnetzwerk default verwendet.
        • SUBNET_NAME: Name des Subnetzes, das für die private Verbindung zum Ersteller verwendet wird. Die Subnetzgröße kann klein sein: Die PSC NEG benötigt nur eine IP-Adresse aus dem Subnetz. Für Apigee ist nur eine PSC-NEG pro Region erforderlich. Das Subnetz kann von VMs oder anderen Entitäten gemeinsam genutzt und verwendet werden. Wenn kein Subnetz angegeben ist, können Netzwerkendpunkte zu einem Subnetzwerk in der Region gehören, in der die Netzwerk-Endpunktgruppe erstellt wird.
        • PROJECT_ID Das Cloud-Projekt, das bereits mit Ihrer Apigee-Organisation verknüpft ist, oder ein Cloud-Projekt, das in consumerAcceptlist enthalten war, als die Apigee-Laufzeitinstanz erstellt wurde.
    2. Rufen Sie den Namen des Backend-Dienstes für Ihren Produktions-Load-Balancer in Apigee ab: 
      gcloud compute backend-services list --project=$PROJECT_ID
    3. Fügen Sie dem Backend-Dienst die NEG als Backend hinzu: 
      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

      Dabei gilt:

      • BACKEND_SERVICE_NAME ist der Name des Backend-Dienstes.
      • NEG_NAME ist der Name der Netzwerk-Endpunktgruppe.
    4. (Optional) Sie können für den Backend-Dienst eine Traffic-Richtlinie für Ausreißererkennung festlegen, um Failover-Szenarien automatisch zu verarbeiten. Weitere Informationen finden Sie hier:

    Abschließende Einrichtung testen

    Einen API-Proxy aufrufen Siehe Beispielproxy bereitstellen.

    MIG-Routing konfigurieren

    In den folgenden Schritten wird erläutert, wie Sie das Routing in der neuen Region mithilfe einer verwalteten Instanzgruppe (Managed Instance Group, MIG) konfigurieren.

    Übersicht

    Die folgende Abbildung zeigt die allgemeine Northbound-Architektur für multiregionale verwaltete Instanzgruppen (MIGs):

    Diagramm der Northbound-Architektur für multiregionales PSC.

    Abbildung 2: Northbound-Architektur für multiregionale verwaltete Instanzgruppen (MIGs)

    Wie Abbildung 2 zeigt, erstellen Sie in Ihrem Projekt eine MIG zur Kommunikation mit einem Load-Balancer in der Region, in der sich die neue Apigee-Instanz befindet. Die MIG-Proxys für alle Regionen sind mit dem globalen externen Backend des Produktions-Load-Balancers von Apigee verbunden.

    Verwaltete Instanzgruppe (MIG) für die neue Region erstellen

    Führen Sie die folgenden Schritte aus, um eine MIG für die neue Region zu erstellen und zu konfigurieren:

    1. Aktivieren Sie den privaten Google-Zugriff für ein Subnetz Ihres VPC-Netzwerks.

      Führen Sie die Schritte unter Privaten Google-Zugriff aktivieren aus, um den privaten Google-Zugriff für ein Subnetz Ihres VPC-Netzwerks zu aktivieren.

    2. Richten Sie Umgebungsvariablen ein:

      In der Anleitung in diesem Abschnitt werden Umgebungsvariablen verwendet, um auf wiederholt verwendete Strings zu verweisen. Wir empfehlen, diese festzulegen, bevor Sie fortfahren:

      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. Erstellen Sie eine verwaltete Instanzgruppe. In diesem Schritt erstellen und konfigurieren Sie eine verwaltete Instanzgruppe (MIG).
      1. Erstellen Sie mit dem folgenden Befehl eine Instanzvorlage.
        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

        Wie Sie anhand dieses Befehls sehen können, sind Maschinen vom Typ e2-medium. Sie führen Debian 10 aus und haben 20 GB Speicherplatz. Das Skript startup-script.sh konfiguriert die MIG so, dass eingehender Traffic vom Load-Balancer an die Apigee-Instanz weitergeleitet wird.

      2. Erstellen Sie mit folgendem Befehl eine verwaltete Instanzgruppe:
        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. Konfigurieren Sie das Autoscaling für die Gruppe mit folgendem Befehl: 
        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. Definieren Sie mit folgendem Befehl einen benannten Port:
        gcloud compute instance-groups managed set-named-ports $MIG_NAME \
  --project $PROJECT_ID --region $NEW_REGION_LOCATION --named-ports https:443
    4. Rufen Sie den Namen des Backend-Dienstes für Ihren Produktions-Load-Balancer in Apigee ab: 
      gcloud compute backend-services list --project=$PROJECT_ID
    5. Fügen Sie Ihrem Backend-Dienst die MIG mit dem folgenden Befehl hinzu: 
      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

      Ersetzen Sie BACKEND_SERVICE_NAME durch den Namen des Backend-Dienstes.

    Abschließende Einrichtung testen

    Einen API-Proxy aufrufen Siehe Beispielproxy bereitstellen.

    Regionen hinzufügen

    Das Hinzufügen mehrerer Regionen zu einer Apigee-Umgebung kann Hochverfügbarkeit, eine höhere Kapazität und eine geringere Latenz für Ihre APIs bieten. Eine Bereitstellung in mehreren Regionen unterstützt Hochverfügbarkeit, da kein manueller Failover erforderlich ist, da der XLB eine Systemdiagnose für jede Region durchführt. Eine höhere Kapazität wird bereitgestellt, wenn mehrere Regionen gleichzeitig dieselben APIs bereitstellen. Wenn sich Ihre API-Clients außerdem in mehreren Regionen befinden, können Sie die Latenz verringern und die Leistung verbessern, wenn Sie die API aus einer Region bereitstellen, die näher an Ihren Clients liegt.

    Beispiel: Eine multiregionale Bereitstellung verbessert Verfügbarkeit, Kapazität und Latenz.

    In einer Aktiv/Aktiv-Konfiguration für mehrere Regionen wird der Traffic gleichzeitig aus zwei Regionen bereitgestellt. Sie fügen einen Backend-Dienst für die MIG jeder Region zum selben externen HTTPS-Load-Balancer (XLB) hinzu, wie in Schritt 8e(3) im Tab Externes Routing (MIG) im Abschnitt Schritt 8: Routing konfigurieren erläutert. Weitere Informationen zu Verwaltete Instanzgruppe (MIG) für die neue Region erstellen.

    Für jede Anfrage wählt der XLB die Region aus, die dem Client am nächsten ist, es sei denn, die Anzahl der Anfragen überschreitet das für ein bestimmtes Backend festgelegte Limit. Weitere Informationen zur Weiterleitung von Traffic über externe Load-Balancer finden Sie unter Optimierung der Anwendungskapazität mit globalem Load-Balancing.

    Regionen für „Pay as you go“-Regionen hinzufügen

    Mit dem Preismodell Pay-as-you-go können Sie die Mindestanzahl von Apigee-Gateway-Knoten für eine Umgebung festlegen. So können Regionen immer mit zusätzlicher Kapazität ausgeführt werden, damit bei einem Ausfall einer Region der Failover-Traffic sofort unterstützt wird.

    Mindestanzahl von Apigee-Gateway-Knoten festlegen

    Wenn der gesamte normale API-Traffic von zwei aktiven Regionen mit jeweils vier Apigee-Gateway-Knoten bereitgestellt werden kann, sollte jede Region mindestens acht Knoten haben. Auf diese Weise wird der Verlust einer Region sofort unterstützt. Weitere Informationen dazu, wie Sie die Anzahl der Knoten ermitteln, die Sie für den API-Traffic benötigen, finden Sie unter Apigee-Knoten. Beachten Sie, dass die Mindestanzahl an Knoten pro Umgebung festgelegt, aber pro Region erzwungen wird. Wenn Sie zum Beispiel das Minimum auf 8 festlegen, hat jede Region mindestens 8 Knoten.

    Kosten

    Im obigen Beispiel fallen die Kosten für die Ausführung von mindestens 16 Apigee-Gateway-Knoten (8 Knoten x 2 Regionen) an. Die Kosten können bis zum Maximum steigen, wenn sich die Anzahl der Knoten automatisch erhöht, um zusätzlichen Traffic zu verarbeiten.

    Apigee aus einer Region entfernen

    Wenn Sie eine Apigee-Instanz außer Betrieb nehmen möchten, um API-Traffic nicht bereitzustellen, führen Sie die folgenden Schritte aus, um einen unterbrechungsfreien Dienst ohne Ausfallzeiten für Ihre APIs zu gewährleisten:

    1. Aktivieren Sie den Verbindungsausgleich für den Backend-Dienst. Durch den Verbindungsausgleich wird sichergestellt, dass in Bearbeitung befindliche Anfragen zuerst vollständig abgeschlossen werden, bevor ein Backend aus dem BBackend-Dienst entfernt wird.
    2. Wenn Cloud DNS so konfiguriert wurde, dass der Traffic über die gewichtete Round Robin-Routingrichtlinie zu dieser Apigee-Region geleitet wird, entfernen Sie diese DNS-Konfiguration, wie unter DNS-Routingrichtlinie und Systemdiagnosen verwalten beschrieben.
    3. Trennen Sie das MIG-Backend vom Backend-Dienst. Dadurch wird zusammen mit dem Verbindungsausgleich sichergestellt, dass die Apigee-Instanz keinen neuen Traffic empfängt, aber alle laufenden Anfragen abgeschlossen werden können.
    4. Löschen Sie die Apigee-Instanz und die zugehörige MIG. Siehe Instanz löschen.