Ampliar Apigee a varias regiones

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

Consulta la documentación de Apigee Edge.

Puedes ampliar una organización de Apigee a varias regiones. La expansión multirregional permite mejorar los siguientes aspectos:

  • Alta disponibilidad: en caso de que falle una región, el tráfico se puede seguir atendiendo desde las regiones restantes, lo que aumenta la disponibilidad general de tus APIs.
  • Alta capacidad: las regiones adicionales proporcionan capacidad extra para servir el tráfico de tu API y espacio para cualquier pico inesperado de tráfico sin ejercer mucha presión sobre un solo entorno, lo que aumenta la capacidad general de tus APIs.
  • Latencia baja: las regiones adicionales pueden reducir la latencia general de las transacciones de los clientes, ya que sus solicitudes se sirven en una región geográficamente más cercana.

En este documento se explica cómo añadir Apigee a una región y cómo quitarlo de una región.

Añadir Apigee a una nueva región

Puedes tener una instancia de tiempo de ejecución por región, por lo que, para añadir una nueva región, debes crear una instancia completamente nueva en esa región.

El proceso general para añadir una región es el siguiente:

  1. Asegúrate de que tienes disponible un intervalo de direcciones IP adecuado en tu red de interconexión, tal como se describe en Requisitos previos. Además, asegúrate de que tu cuenta pueda admitir una nueva región, tal como se describe en Límites.
  2. Definir variables de entorno
  3. Crear un conjunto de claves y una clave
  4. Reservar un nuevo intervalo de direcciones
  5. Crear una instancia
  6. Asociar entornos a la nueva instancia
  7. Configurar el enrutamiento

En las siguientes secciones se describe cada uno de estos pasos.

Requisitos previos

Asegúrate de que tu red tenga disponibles los intervalos de direcciones IP /22 y /28 sin solapamiento. Esto se suma a los intervalos utilizados por otras regiones.

Límites

De forma predeterminada, tu organización inicial se crea con una sola región. Cuando decida si va a crear una segunda región (o una posterior), tenga en cuenta que solo podrá añadir una región si sus derechos de licencia lo permiten. También puedes comprar un paquete de organización.

  • Si tienes un modelo de precios basado en suscripciones, es posible que tengas que comprar unidades organizativas adicionales para poder ampliar tu cobertura a varias regiones. Consulta Derechos de suscripción.
  • Si tienes un modelo de precios de pago por uso, ampliar tu cobertura a varias regiones supondrá costes adicionales, tal como se explica en el artículo Añadir regiones para el modelo de pago por uso.
  • Las cuentas de evaluación están limitadas a una región y no se pueden ampliar a una segunda región.

Para obtener más información, consulta el resumen de la modalidad de pago por uso.

Ninguna organización puede tener más de 10 regiones (11 en el caso de las organizaciones híbridas).

Definir variables de entorno

Te recomendamos que definas las siguientes variables de entorno para asegurar la coherencia en 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)")

Donde:

  • NEW_REGION_LOCATION es la ubicación física de tu nueva instancia. Los valores válidos son cualquier región de Compute Engine. Para obtener más información, consulta Regiones y zonas. Por ejemplo, us-west1.
  • NEW_INSTANCE_NAME es el nombre de la nueva región. Debe ser único en tu organización. Por ejemplo, my-instance-2.
  • NETWORK_NAME es el nombre de la red de peering de tu organización. Por ejemplo, my-network. Consulta Configurar las redes de servicios.
  • DISK_KEY_RING_NAME es el nombre del conjunto de claves de disco.
  • DISK_KEY_NAME es el nombre del anillo de disco.
  • AUTH define el encabezado Authentication con un token de portador. Usarás este encabezado al llamar a las APIs de Apigee. Ten en cuenta que el token caduca al cabo de un tiempo. Cuando esto ocurra, 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 el ID de tu proyecto de Cloud.
  • PROJECT_NUMBER es el número de proyecto de Cloud de tu proyecto de Cloud.

Crear un conjunto de claves y una clave

Cada región requiere su propia clave de cifrado de disco para la red. Google recomienda que también crees un llavero independiente para la nueva región. No es necesario que crees una nueva clave de cifrado de base de datos, ya que todas las instancias de una organización comparten la misma clave de cifrado de base de datos.

Para obtener más información, consulta Acerca de las claves de cifrado de Apigee.

Para crear un conjunto de claves y una clave de cifrado de disco:

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

    Verifica que el conjunto de claves de disco esté configurado en la misma ubicación que la instancia. Cada instancia y llavero debe 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 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 mediante su ruta de clave. Puedes obtener la ruta 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 la clave tiene el siguiente aspecto:

    projects/PROJECT_ID/locations/NEW_REGION_LOCATION/keyRings/my-disk-key-ring/cryptoKeys/my-disk-key
  3. Concede acceso al agente de servicio de Apigee para que use la nueva clave ejecutando el 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

    Comprueba 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

Reservar un nuevo intervalo de direcciones

Reserva direcciones IP para el intervalo de direcciones de tu red de emparejamiento. Para obtener más información y conocer las consideraciones importantes, consulta también el artículo Información sobre los intervalos de emparejamiento.

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

    Donde:

    • NEW_RANGE_NAME_22 es el nombre del intervalo de direcciones IP de longitud CIDR /22 que vas a crear. Puedes asignar el nombre que quieras al intervalo. Por ejemplo: google-svcs-new_22
    • NEW_RANGE_NAME_28 es el nombre del intervalo de direcciones IP de longitud CIDR /28 que vas a crear. Puedes asignar el nombre que quieras al intervalo. 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, Google no recomienda usar la red predeterminada para nada que no sean pruebas.

  2. Crea un intervalo de IP de red con una longitud 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 la solicitud se realiza correctamente, 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 cálculo creada:

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

    Una vez que creas un intervalo de direcciones IP, estas se asocian al proyecto hasta que las liberas.

  3. Crea un intervalo de IP de red con una longitud CIDR de /28. Este intervalo es obligatorio y Apigee lo usa para solucionar problemas. 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 cálculo 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 intervalos de emparejamiento: 
    gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID
  5. Añade los intervalos recién reservados a tu red emparejada con el siguiente comando, donde $NEW_RANGE_NAME_22 y $NEW_RANGE_NAME_28 son los nombres de los nuevos intervalos y ORIGINAL_RANGE_NAME_1 y ORIGINAL_RANGE_NAME_n son los nombres de los intervalos de emparejamiento reservados que se han devuelto 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 de vpc-peering que se han actualizado:

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

Crear una instancia

Crea una instancia para la región con la API Instances.

Con el emparejamiento de VPCs

Si Apigee se ha configurado para usar el emparejamiento entre VPCs, 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
  }'

Donde:

  • KEY_PATH es la ruta de la clave de cifrado de disco que has creado en Crear un conjunto de claves y una clave.
  • IP_ADDRESS_* son direcciones IP CIDR de los intervalos CIDR /22 y /28 que se usan para crear la instancia de Apigee. Ten en cuenta que ipRange es opcional. Si no proporcionas este campo, Apigee solicitará automáticamente un bloque CIDR /22 y /28 disponible de Service Networking. Consulta también la API de instancias de Apigee.

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

Sin emparejamiento de VPCs

Si Apigee no se ha configurado para usar el emparejamiento de VPCs, 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":"'"$INSTANCE_NAME"'",
    "location":"'"$RUNTIME_LOCATION"'",
    "diskEncryptionKeyName":"'"KEY_PATH"'",
    "consumerAcceptList":[ARRAY_OF_PROJECT_IDS]      
  }'

Donde:

  • KEY_PATH es la ruta de la clave de cifrado de disco que has creado en Crear un conjunto de claves y una clave. Consulta también la API de instancias de Apigee.
  • consumerAcceptList(Opcional) Especifica una lista de IDs de proyectos de Google Cloud que pueden conectarse de forma privada al adjunto de servicio de la VPC de Apigee. Una vinculación de servicio es una entidad que se usa con Private Service Connect de Google Cloud para permitir que los productores de servicios (en este caso, Apigee) expongan servicios a los consumidores (en este caso, uno o varios proyectos de Cloud de tu propiedad). De forma predeterminada, usamos el proyecto de Cloud 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, ya que Apigee debe crear e iniciar un nuevo clúster de Kubernetes, instalar los recursos de Apigee en ese clúster y configurar el balanceo de carga.

Temporizador: la operación de creación de la instancia tarda unos 30 minutos en completarse.

Para comprobar el estado de tu solicitud de creación de instancias de tiempo 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 información sobre cómo crear una instancia de tiempo de ejecución, incluido contexto adicional e información para solucionar problemas, consulta el paso 5: Crear una instancia de tiempo de ejecución de Apigee.

Asigna entornos a la nueva instancia

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

Los entornos se comparten entre instancias, por lo que debes asociar los entornos existentes a la nueva región. No definas nuevos entornos para la nueva región. Si defines un nuevo entorno para la nueva región que sirve las mismas rutas base para los mismos hosts que tu entorno original, es posible que tus llamadas de tiempo de ejecución devuelvan errores HTTP 503.

Cuando rellenas una región nueva con entornos, no es necesario que asocies los entornos a grupos de entornos, ya que están asociados a sus grupos. Solo tienes que adjuntar los entornos a la nueva instancia.

Para asociar tus entornos a la nueva región, usa la API de asociación 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, sigue estos pasos:

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

Debes asociar cada entorno con una llamada independiente a la API Instances Attachment. No puedes adjuntar más de un entorno en una sola llamada.

Configurar el enrutamiento

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

Configurar el enrutamiento de PSC

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

Información general

En la siguiente figura se muestra la arquitectura de alto nivel orientada al norte de PSC multirregional:

Diagrama del enrutamiento de PSC multirregional.

Figura 1: Arquitectura multirregional de dirección norte con PSC

Como se muestra en la figura 1, crearás un grupo de puntos finales de red (NEG) en tu proyecto que se comunique con un adjunto de servicio en la región en la que se encuentre la nueva instancia de Apigee. Los NEGs de Apigee de todas las regiones están conectados al servicio de backend de tu balanceador de carga externo global de producción de Apigee.

Crea un grupo de endpoints de red para la nueva región.

Sigue estos pasos para crear y configurar un balanceador de carga con un grupo de puntos finales de red (NEG) para la nueva región:

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

      En el siguiente ejemplo de salida, el valor serviceAttachment se muestra en 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 has obtenido del cuerpo de la 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

      Haz los cambios siguientes:

      • NEG_NAME: nombre del grupo de endpoints de red.
      • TARGET_SERVICE: el archivo adjunto de servicio al que quieras conectarte. Por ejemplo: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
      • NETWORK_NAME: (Opcional) Nombre de la red en la que se crea el NEG. Si omite este parámetro, se usará la red del proyecto default.
      • SUBNET_NAME: nombre de la subred usada para la conectividad privada con el productor. El tamaño de la subred puede ser pequeño: el NEG de PSC solo necesita una IP de la subred. En Apigee, solo se necesita un NEG de PSC por región. Las subredes se pueden compartir y usar en VMs u otras entidades. Si no se especifica ninguna subred, los endpoints de red pueden pertenecer a cualquier subred de la región en la que se cree el grupo de endpoints 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 el consumerAcceptlist cuando se creó la instancia de tiempo de ejecución de Apigee.
  2. Obtén el nombre del servicio de backend de tu balanceador de carga de producción de Apigee: 
    gcloud compute backend-services list --project=$PROJECT_ID
  3. Añade el NEG como 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

    Haz los cambios siguientes:

    • BACKEND_SERVICE_NAME: el nombre del servicio de backend.
    • NEG_NAME: el nombre del grupo de endpoints de red.
  4. (Opcional) Puedes definir una política de tráfico de detección de valores atípicos en el servicio de backend para gestionar automáticamente los escenarios de conmutación por error. Para obtener más información, consulta los siguientes recursos:

Probar la configuración final

Llama a un proxy de API. Consulta Desplegar un proxy de ejemplo.

Configurar el enrutamiento de MIGs

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

Información general

En la siguiente figura se muestra la arquitectura de alto nivel y de salida para la configuración multirregional con grupos de instancias gestionados (MIGs):

Diagrama de la arquitectura de salida de PSC multirregional.

Imagen 2: Arquitectura multirregión de entrada con MIG

Como se muestra en la figura 2, crearás un MIG en tu proyecto para comunicarte con un balanceador de carga implementado en la región en la que se encuentra la nueva instancia de Apigee. Los proxies de MIG de todas las regiones están conectados al backend del balanceador de carga externo global de producción de Apigee.

Crea un grupo de instancias gestionado para la nueva región

Sigue estos pasos para crear y configurar un MIG en la nueva región:

  1. Habilita la función Acceso privado de Google en una subred de tu red de VPC.

    Para habilitar la función Acceso privado de Google en una subred de tu red de VPC, sigue los pasos que se indican en el artículo sobre cómo habilitar Acceso privado de Google.

  2. Configura las variables de entorno:

    En las instrucciones de esta sección se usan variables de entorno para hacer referencia a cadenas que se usan repetidamente. Te recomendamos que los definas 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. Crea un grupo de instancias gestionado. En este paso, creará y configurará un grupo de instancias gestionado (MIG).
    1. Crea una plantilla de instancia ejecutando el 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-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

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

    2. Crea un grupo de instancias gestionado ejecutando 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 autoescalado del grupo ejecutando el 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 ejecutando el 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 de tu balanceador de carga de producción de Apigee: 
    gcloud compute backend-services list --project=$PROJECT_ID
  5. Añade el MIG a tu servicio 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

    Sustituye BACKEND_SERVICE_NAME por el nombre del servicio de backend.

Probar la configuración final

Llama a un proxy de API. Consulta Desplegar un proxy de ejemplo.

Añadir regiones

Si añades varias regiones a un entorno de Apigee, tus APIs pueden disfrutar de alta disponibilidad, mayor capacidad y menor latencia. Una implementación multirregional admite la alta disponibilidad porque no es necesaria la conmutación por error manual, ya que el XLB comprobará el estado de cada región. Se proporciona una mayor capacidad cuando varias regiones sirven las mismas APIs al mismo tiempo. Además, si tus clientes de la API se encuentran en varias regiones, servir la API desde una región más cercana a tus clientes ayudará a reducir la latencia y mejorar el rendimiento.

Ejemplo: Una implementación multirregional mejora la disponibilidad, la capacidad y la latencia

En un despliegue multirregional activo-activo, el tráfico se sirve desde dos regiones al mismo tiempo. Añade un servicio de backend para el MIG de cada región al mismo balanceador de carga HTTPS externo (XLB), tal como se explica en el paso 8e(3) de la pestaña Enrutamiento externo (MIG) de la sección Paso 8: Configurar el enrutamiento. Para obtener más información, consulta también Crear un grupo de instancias gestionadas (MIG) para la nueva región.

En cada solicitud, el XLB elegirá la región más cercana al cliente, a menos que el número de solicitudes supere el límite establecido para un backend concreto. Consulta Optimizaciones de capacidad de aplicaciones con el balanceo de carga global para obtener más información sobre cómo enrutan el tráfico los balanceadores de carga externos.

Añadir regiones para la modalidad de pago por uso

Con el modelo de precios Pay-as-you-go, puedes definir el número mínimo de nodos de la pasarela de Apigee para un entorno. De esta forma, las regiones siempre tienen capacidad adicional para admitir inmediatamente el tráfico de conmutación por error en caso de que se produzca un fallo en una región.

Definir el número mínimo de nodos de pasarela de Apigee

Si puedes atender todo el tráfico normal de tu API desde dos regiones activas, cada una con cuatro nodos de pasarela de Apigee, cada región debe tener un mínimo de ocho nodos. Esto se hace para que se pueda seguir trabajando inmediatamente si se pierde una región. Consulta Información sobre los nodos de Apigee para obtener más información sobre cómo determinar el número de nodos que necesitas para gestionar el tráfico de tus APIs. Ten en cuenta que el número mínimo de nodos se define por entorno, pero se aplica por región. Por ejemplo, si defines el mínimo en 8, cada región tendrá un mínimo de 8 nodos.

Coste

En el ejemplo anterior, incurrirías en el coste de ejecutar al menos 16 nodos de la pasarela de Apigee (8 nodos x 2 regiones). El coste puede aumentar a medida que el número de nodos aumente automáticamente para gestionar el tráfico adicional, hasta el máximo.

Quitar Apigee de una región

Para retirar una instancia de Apigee del servicio de tráfico de APIs, siga estos pasos para asegurarse de que el servicio no se interrumpa (es decir, que las APIs no sufran tiempos de inactividad):

  1. Habilita la purgado de conexiones en el servicio de backend. El drenaje de conexiones es un proceso que asegura que las solicitudes en curso tengan tiempo para completarse cuando se elimina un backend del servicio de backend.
  2. Si Cloud DNS se ha configurado para enrutar el tráfico a esta región de Apigee mediante la política de enrutamiento round-robin ponderado, elimina esa configuración de DNS, tal como se describe en Gestionar políticas de enrutamiento de DNS y comprobaciones de estado.
  3. Desasocia el backend de MIG del servicio de backend. De esta forma, junto con la purga de conexiones, se asegura de que la instancia de Apigee no reciba tráfico nuevo, pero permite que se completen las solicitudes en curso.
  4. Elimina la instancia de Apigee y su MIG correspondiente. Consulta Eliminar una instancia.