Expansión de Apigee a varias regiones

Esta página se aplica a Apigee, pero no a Apigee Hybrid.

Consulta la documentación de Apigee Edge.

Puedes expandir una organización de Apigee en varias regiones. La expansión multirregional permite realizar mejoras en estas áreas:

  • Alta disponibilidad: En caso de una falla de la región, las regiones restantes pueden entregar tráfico, lo que aumenta la disponibilidad general de las APIs.
  • Alta capacidad: Las regiones adicionales proporcionan capacidad adicional para entregar el tráfico de la API y dejar espacio para cualquier aumento inesperado en el tráfico sin agregar mucha presión en un solo entorno, para aumentar la capacidad general de tus API
  • Latencia baja: Las regiones adicionales pueden reducir la latencia general de la transacción para los clientes mediante la entrega de sus solicitudes en una región geográfica más cercana.

En este documento, se explica cómo agregar Apigee a una región nueva y cómo quitar Apigee de una región.

Agrega Apigee a una región nueva

Puedes tener una instancia del entorno de ejecución por región, por lo que para agregar una región nueva debes crear una instancia completamente nueva en esa región.

El proceso general para agregar una región nueva es el siguiente:

  1. Asegúrate de tener un rango de direcciones IP apropiado en tu red de intercambio de tráfico disponible, como se describe en Requisitos. Además, asegúrate de que tu cuenta admita una región nueva, como se describe en Límites.
  2. Define las variables de entorno.
  3. Crea un llavero de claves y una clave nuevos
  4. Reserva un nuevo rango de direcciones
  5. Cree una instancia nueva
  6. Conecta entornos a la instancia nueva
  7. Configura el enrutamiento

Cada uno de estos pasos se describe en las siguientes secciones.

Requisitos previos

Asegúrese de que su red tenga /22 y /28 como rangos de direcciones IP no superpuestos. Esto se suma a los rangos que usan otras regiones.

Límites

De forma predeterminada, tu organización inicial se crea generalmente con una sola región. Cuando decidas si deseas crear una segunda región (o una región posterior), ten en cuenta que solo puedes agregar una región si tus derechos de licencia lo permiten. De manera opcional, puedes comprar un paquete de organización.

  • Si tienes un modelo de precios basados en suscripciones, es posible que debas comprar unidades organizativas adicionales para permitir la expansión a varias regiones. Consulta Derechos de suscripción.
  • Si tienes un modelo de precios de pago por uso, expandirte a varias regiones generará costos adicionales, como se explica en Agrega regiones para pago por uso.
  • Las cuentas de evaluación se limitan a una región y no se pueden expandir a otra región.

Para obtener más información, consulta Descripción general del pago por uso.

Ninguna organización puede tener más de 10 regiones (11 para híbridos).

Define las variables de entorno.

Te recomendamos que definas las siguientes variables de entorno para garantizar la coherencia entre los comandos que se usan en esta documentación.

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

Aquí:

  • NEW_REGION_LOCATION es la ubicación física de tu instancia nueva. Los valores válidos son cualquier región de Compute Engine. Para obtener más información, consulta la página sobre regiones y zonas. Por ejemplo, us-west1.
  • NEW_INSTANCE_NAME es el nombre de la región nueva. Debe ser único para tu organización. Por ejemplo, my-instance-2.
  • NETWORK_NAME es el nombre de la red de intercambio de tráfico de tu organización. Por ejemplo, my-network. Consulta Configura herramientas de redes de servicio.
  • DISK_KEY_RING_NAME es un nombre para el llavero de claves del disco.
  • DISK_KEY_NAME es un nombre para el anillo del disco.
  • AUTH define el encabezado Authentication con un token del portador. Usarás este encabezado cuando llames a las API de Apigee. Ten en cuenta que el token vence después de un período y, cuando lo hace, puedes volver a generarlo con el mismo comando. Para obtener más información, consulta la página de referencia del comando print-access-token.
  • PROJECT_ID es tu ID del proyecto de Cloud.
  • PROJECT_NUMBER es el número de tu proyecto de Cloud.

    • Crea un llavero de claves y una clave nuevos

    Cada región requiere su propia clave de encriptación de disco para la red. Google recomienda que también crees un llavero de claves por separado para la región nueva. No es necesario crear una clave de encriptación nueva de base de datos porque todas las instancias de una organización comparten la misma clave.

    Para obtener detalles adicionales, consulta la Acerca de las claves de encriptación de Apigee.

    Para crear un llavero de claves de encriptación de disco nuevo y una clave, sigue estos pasos:

    1. Crea un llavero de claves de disco nuevo con el comando de gcloud: 
      gcloud kms keyrings create $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

      Verifica que el llavero de claves del disco esté configurado en la misma ubicación que la instancia. Cada instancia y llavero de claves deben tener su propia ubicación.

      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 clave de disco nueva con el comando kms keys create; por ejemplo: 
      gcloud kms keys create $DISK_KEY_NAME --keyring $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION --purpose "encryption" --project $PROJECT_ID

      Se puede hacer referencia a la clave por la ruta de acceso de la clave. Puedes obtener la ruta de acceso de la clave con el siguiente comando:

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

      La ruta de acceso de la clave se ve de la siguiente manera:

      projects/PROJECT_ID/locations/NEW_REGION_LOCATION/keyRings/my-disk-key-ring/cryptoKeys/my-disk-key
    3. Otorga acceso para que el agente de servicio de Apigee use la clave nueva mediante la ejecución del comando gcloud kms keys add-iam-policy-binding; por ejemplo: 
      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 que la clave esté vinculada al agente de servicio de 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

    Reserva un nuevo rango de direcciones

    Reserva direcciones IP para el rango de direcciones de tu red de intercambio de tráfico: Para obtener más información y consideraciones importantes, consulta también Información sobre los rangos de intercambio de tráfico.

    1. Crea estas variables de entorno: 
      NEW_RANGE_NAME_22=YOUR_CIDR_22_RANGE_NAME
NEW_RANGE_NAME_28=YOUR_CIDR_28_RANGE_NAME
NETWORK_NAME=YOUR_NETWORK_NAME

      Aquí:

      • NEW_RANGE_NAME_22 es el nombre del rango de direcciones IP de la longitud de CIDR /22 que crearás. Puedes nombrar el rango como desees. Por ejemplo: google-svcs-new_22
      • NEW_RANGE_NAME_28 es el nombre del rango de direcciones IP de la longitud de CIDR /28 que crearás. Puedes nombrar el rango como desees. Por ejemplo: google-svcs-new_28
      • NETWORK_NAME es el nombre del recurso de red en el que se deben reservar las direcciones.

        Google crea una red predeterminada (llamada default) para cada proyecto nuevo, por lo que puedes usarla. Sin embargo, no recomienda usar la red predeterminada para nada más que la prueba.

    2. Crea un rango de IP de red con una longitud de CIDR de /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

      Si se ejecuta de forma correcta, gcloud responde con lo siguiente:

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

      Valida la dirección de procesamiento creada:

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

      Después de crear un rango de direcciones IP, las direcciones se asocian al proyecto hasta que las liberes.

    3. Crea un rango de IP de red con una longitud de CIDR de /28. Este rango es obligatorio y Apigee lo usa para solucionar problemas y no se puede personalizar ni cambiar. 
      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. Valida la dirección de procesamiento creada:

      gcloud compute addresses list \
  --global \
  --project=$PROJECT_ID
       gcloud compute addresses describe $NEW_RANGE_NAME_28 \
  --global \
  --project=$PROJECT_ID
    4. Obtén los nombres de los rangos de intercambio de tráfico: 
      gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID
    5. Agrega los rangos reservados recientemente a tu red de intercambio de tráfico con el siguiente comando, en el que $NEW_RANGE_NAME_22 y $NEW_RANGE_NAME_28 son los nombres de los rangos nuevos y ORIGINAL_RANGE_NAME_1 y ORIGINAL_RANGE_NAME_n son los nombres de los rangos de intercambio de tráfico reservados que se muestran en el comando anterior: 
      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. Valida los cambios del intercambio de tráfico entre VPC que se actualizaron:

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

    Cree una instancia nueva

    Crea una instancia nueva para la región con la API de instancias.

    Intercambio de tráfico entre VPC

    Si Apigee fue Configura el intercambio de tráfico entre VPC y usa esta llamada a la API para crear la instancia: 

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

    Aquí:

    • KEY_PATH es la ruta de la clave de encriptación de disco que creaste en Crea un llavero de claves y una clave nuevos.
    • IP_ADDRESS_* son direcciones IP de CIDR para los rangos de CIDR /22 y /28 que se usan a fin de crear la instancia de Apigee. Ten en cuenta que ipRange es opcional. Si no proporcionas este campo, Apigee solicita de forma automática un bloque CIDR /22 y /28 disponible de las Herramientas de redes de servicios. Consulta también la API de instancias de Apigee.

      • Esta solicitud puede tardar hasta 20 minutos en completarse porque Apigee debe crear e iniciar un clúster nuevo de Kubernetes, instalar los recursos de Apigee en ese clúster y configurar el balanceo de cargas.

    Sin intercambio de tráfico entre VPC

    Si Apigee no se configuró para usar el intercambio de tráfico de VPC, usa esta llamada a la API a fin de crear la instancia: 

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

    Aquí:

    • KEY_PATH es la ruta de la clave de encriptación de disco que creaste en Crea un llavero de claves y una clave nuevos. Consulta también la API de instancias de Apigee.
    • consumerAcceptList Especifica una lista de ID de proyectos de Google Cloud que se pueden conectar de forma privada al adjunto de servicio de la VPC de Apigee. El adjunto de servicio es una entidad que se usa con Private Service Connect de Google Cloud a fin de permitir que los productores de servicios (en este caso, Apigee) expongan servicios a los consumidores (en este caso, uno o más proyectos de la nube que te pertenezcan). De forma predeterminada, usamos el proyecto de la nube que ya está asociado a tu organización de Apigee. Por ejemplo: "consumerAcceptList": ["project1", "project2", "project3"]

    Esta solicitud puede tardar hasta 20 minutos en completarse porque Apigee debe crear e iniciar un clúster nuevo de Kubernetes, instalar los recursos de Apigee en ese clúster y configurar el balanceo de cargas.

    timer La operación de creación de instancia toma alrededor de 30 minutos en completarse.

    Para verificar el estado de tu solicitud de creación de instancias del entorno de ejecución, ejecuta el siguiente comando. Cuando el estado sea ACTIVO, puedes continuar con el siguiente paso.

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

    Para obtener más detalles sobre cómo crear una instancia del entorno de ejecución, incluida información adicional de contexto y solución de problemas, consulta el Paso 5: Crea una instancia del entorno de ejecución de Apigee.

    Conecta entornos a la instancia nueva

    Después de crear la instancia, debes adjuntar entornos a ella; de lo contrario, no podrá responder a las solicitudes a la API.

    Los entornos se comparten entre las instancias. Por lo tanto, debes adjuntar entornos existentes a la región nueva. No se definen entornos nuevos para la región nueva. Si defines un entorno nuevo para la región nueva que entrega las mismas rutas base para los mismos hosts que tu entorno original, las llamadas al entorno de ejecución pueden mostrar errores HTTP 503.

    Cuando propagas una región nueva con entornos, no es necesario adjuntarlos a los grupos de entorno; ya están conectados a sus grupos. Solo debes conectar los entornos a la instancia nueva.

    Para conectar tus entornos a la región nueva, usa la API de adjuntos de instancias, como se muestra en el siguiente ejemplo:

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

    Para obtener una lista de tus entornos:

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

    Debes adjuntar cada entorno con una llamada por separado a la API de adjuntos de instancias. No se puede conectar más de un entorno en una sola llamada.

    Configura el enrutamiento

    Puedes configurar el enrutamiento de red en la región nueva mediante un MIG administrado o una configuración basada en Private Service Connect (PSC).

    Configura el enrutamiento de PSC

    En los siguientes pasos, se explica cómo configurar el enrutamiento en la región nueva mediante PSC.

    Descripción general

    En la siguiente figura, se muestra la arquitectura ascendente de alto nivel para PSC multirregional:

    Diagrama del recorrido de PSC multirregional.

    Figura 1: Arquitectura multirregional estándar con PSC

    Como se ilustra en la Figura 1, se creará un grupo de extremos de red (NEG) en el proyecto que se comunicará con un adjunto de servicio en la región en la que reside la instancia nueva de Apigee. Los NEG de Apigee para todas las regiones están conectados al servicio de backend del balanceador de cargas externo global de producción de Apigee.

    Crea un grupo de extremos de red para la región nueva

    Sigue estos pasos a fin de crear y configurar un balanceador de cargas con un grupo de extremos de red (NEG) para la región nueva:

    1. Crea un NEG nuevo:
      1. Obtén el adjunto de servicio de la instancia que creaste antes: 
        curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

        En el siguiente resultado de muestra, el valor serviceAttachment se muestra con letra negrita: 

        {
  "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 que apunte al adjunto de servicio que obtuviste del cuerpo de respuesta de la instancia en el paso anterior. 

        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

        Reemplaza lo siguiente:

        • NEG_NAME: un nombre para el grupo de extremos de red.
        • TARGET_SERVICE: el adjunto de servicio al que deseas conectarte. Por ejemplo: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7.
        • NETWORK_NAME: Nombre de la red en la que se crea el NEG (opcional). Si omites este parámetro, se usa la red del proyecto default.
        • SUBNET_NAME: Nombre de la subred que se usa para la conectividad privada al productor. El tamaño de subred puede ser pequeño: el NEG de PSC solo necesita una IP de la subred. Para Apigee, solo se necesita un NEG de PSC por región. Las VMs y otras entidades pueden compartir y usar la subred. Si no se especifica una subred, los extremos de red pueden pertenecer a cualquier subred en la región donde se crea el grupo de extremos de red.
        • PROJECT_ID El proyecto de Cloud que ya está asociado a tu organización de Apigee o un proyecto de Cloud incluido en consumerAcceptlist cuando se crea la instancia del entorno de ejecución de Apigee.
    2. Obtén el nombre del servicio de backend para tu balanceador de cargas de Apigee de producción: 
      gcloud compute backend-services list --project=$PROJECT_ID
    3. Agrega el NEG como el backend al servicio de 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

      Reemplaza lo siguiente:

      • BACKEND_SERVICE_NAME: el nombre del servicio de backend.
      • NEG_NAME: el nombre del grupo de extremos de red.
    4. Puedes configurar una política de tráfico de detección de valores atípicos en el servicio de backend para controlar situaciones de conmutación por error de forma automática (opcional). Consulta los siguientes artículos para obtener más información:

    Prueba la configuración final

    Llama a un proxy de API Consulta Implementa un proxy de muestra.

    Configura el enrutamiento de MIG

    En los siguientes pasos, se explica cómo configurar el enrutamiento en la nueva región mediante un grupo de instancias administrado (MIG).

    Descripción general

    En la siguiente figura, se muestra la arquitectura ascendente de alto nivel para la multirregión que usa grupos de instancias administrados (MIG):

    Diagrama de la arquitectura ascendente para PSC multirregional.

    Figura 2: Arquitectura multirregional ascendente con MIG

    Como se ilustra en la Figura 2, se creará un MIG en tu proyecto para comunicarse con un balanceador de cargas implementado en la región en la que reside la instancia nueva de Apigee. Los proxies de MIG de todas las regiones están conectados al backend del balanceador de cargas externo global de producción de Apigee.

    Crea un grupo de instancias administrado (MIG) para la región nueva

    Sigue estos pasos a fin de crear y configurar un MIG para la región nueva:

    1. Habilita el Acceso privado a Google para una subred de tu red de VPC.

      Si quieres habilitar el Acceso privado a Google para una subred de tu red de VPC, sigue los pasos que se indican en Habilita el Acceso privado a Google.

    2. Configure las variables de entorno:

      En las instrucciones de esta sección, se usan variables de entorno para hacer referencia a strings que se usan de forma repetida. Te recomendamos que configures lo siguiente antes de continuar:

      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. Cree un grupo de instancias administrado. En este paso, crearás y configurarás un grupo de instancias administrado (MIG).
      1. Crea una plantilla de instancias mediante la ejecución del siguiente 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

        Como se puede ver en este comando, las máquinas son del tipo e2-medium. Ejecutan Debian 10 y tienen 20 GB de disco. La secuencia de comandos startup-script.sh configura el MIG para enrutar el tráfico entrante desde el balanceador de cargas hasta la instancia de Apigee.

      2. Para crear un grupo de instancias administrado, ejecuta el siguiente 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 el ajuste de escala automático para el grupo mediante la ejecución del siguiente 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. Define un puerto con nombre mediante la ejecución del siguiente comando:
        gcloud compute instance-groups managed set-named-ports $MIG_NAME \
  --project $PROJECT_ID --region $NEW_REGION_LOCATION --named-ports https:443
    4. Obtén el nombre del servicio de backend para tu balanceador de cargas de Apigee de producción: 
      gcloud compute backend-services list --project=$PROJECT_ID
    5. Agrega el MIG al servicio de backend con el siguiente 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

      Reemplaza BACKEND_SERVICE_NAME por el nombre del servicio de backend.

    Prueba la configuración final

    Llama a un proxy de API Consulta Implementa un proxy de muestra.

    Agrega regiones

    Agregar varias regiones a un entorno de Apigee puede proporcionar alta disponibilidad, mayor capacidad y una menor latencia para tus APIs. Una implementación multirregión admite la alta disponibilidad, ya que no se necesita conmutación por error manual, pues el XLB verificará el estado de cada región. Se proporciona una capacidad más alta cuando varias regiones entregan las mismas APIs al mismo tiempo. Además, si tus clientes de API están en varias regiones, tener tu API entregada desde una región más cercana a tus clientes ayudará a reducir la latencia y mejorar el rendimiento.

    Ejemplo: una implementación multirregión mejora la disponibilidad, capacidad y latencia

    En una implementación multirregión de activo a activo, el tráfico se entrega en dos regiones al mismo tiempo. Agrega un servicio de backend para el MIG de cada región al mismo balanceador de cargas de HTTPS externo (XLB), como se explica en el paso 8e(3) en la pestaña Enrutamiento externo (MIG) de la sección Paso 8: Configura el enrutamiento. A fin de obtener más información, consulta también Crea un grupo de instancias administrado (MIG) para la región nueva.

    Para cada solicitud, el XLB elegirá la región más cercana al cliente, a menos que la cantidad de solicitudes supere el límite establecido para un backend en particular. Consulta Optimizaciones de la capacidad de la aplicación con balanceo de cargas global para obtener más información sobre cómo los balanceadores de cargas externos enrutan el tráfico.

    Agrega regiones de prepago

    Con el modelo de precios prepagados, puedes establecer la cantidad mínima de nodos de puerta de enlace de Apigee para un entorno. Esto permite garantizar que las regiones siempre se ejecuten con capacidad adicional para admitir de inmediato el tráfico de conmutación por error, en caso de que ocurra una falla en la región.

    Configura la cantidad mínima de nodos de puerta de enlace de Apigee

    Si puedes entregar todo el tráfico de API normal en 2 regiones activas, cada una con 4 nodos de puerta de enlace de Apigee, cada región debe tener un mínimo de 8 nodos cada una. Esto es para admitir de inmediato la pérdida de una región. Consulta Acerca de los nodos de Apigee para obtener más información sobre cómo determinar la cantidad de nodos que necesitas a fin de manejar el tráfico de la API. Ten en cuenta que la cantidad mínima de nodos se establece por entorno, pero se aplica por región. En este ejemplo, si estableces el mínimo en 8, cada región tendrá un mínimo de 8 nodos.

    Costo

    En el ejemplo anterior, generarías el costo de ejecutar al menos 16 nodos de puerta de enlace de Apigee (8 nodos x 2 regiones). El costo puede aumentar a medida que los números de nodos aumentan automáticamente para manejar el tráfico adicional, hasta el máximo.

    Quita Apigee de una región

    Para quitar una instancia de Apigee de entregar tráfico de APIs, sigue estos pasos a fin de garantizar un servicio sin interrupciones (sin tiempo de inactividad para tus APIs):

    1. Habilita el vaciado de conexiones en el servicio de backend. El vaciado de conexiones es un proceso que garantiza que las solicitudes existentes en curso tengan tiempo para completarse cuando se quita un backend del servicio de backend.
    2. Si Cloud DNS se configuró para enrutar el tráfico a esta región de Apigee a través de la política de enrutamiento round robin ponderado, quita esa configuración de DNS, como se describe en Administra políticas de enrutamiento de DNS y verificaciones de estado.
    3. Desconecta el backend de MIG del servicio de backend. Esto, junto con el vaciado de conexiones, garantizará que la instancia de Apigee no reciba tráfico nuevo, pero que se complete cualquier solicitud en tránsito.
    4. Borra la instancia de Apigee y su MIG correspondiente. Consulta Borra una instancia.