Expandir o Apigee para várias regiões

Esta página aplica-se ao Apigee, mas não ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

Pode expandir uma organização do Apigee em várias regiões. A expansão em várias regiões permite melhorias nestas áreas:

  • Elevada disponibilidade: em caso de falha de uma região, o tráfego continua a ser servido pelas regiões restantes, o que aumenta a disponibilidade geral das suas APIs.
  • Capacidade elevada: as regiões adicionais oferecem capacidade adicional para publicar o tráfego da sua API e espaço para qualquer pico inesperado no tráfego sem adicionar muita pressão a um único ambiente, o que aumenta a capacidade geral das suas APIs.
  • Baixa latência: as regiões adicionais podem reduzir a latência geral das transações para os clientes, atendendo aos respetivos pedidos numa região geograficamente mais próxima.

Este documento explica como adicionar o Apigee a uma nova região e como remover o Apigee de uma região.

Adicionar o Apigee a uma nova região

Pode ter uma instância de tempo de execução por região. Por isso, para adicionar uma nova região, tem de criar uma instância totalmente nova nessa região.

O processo geral para adicionar uma nova região é o seguinte:

  1. Certifique-se de que tem um intervalo de endereços IP adequado disponível na sua rede de peering, conforme descrito em Pré-requisitos. Além disso, certifique-se de que a sua conta pode suportar uma nova região, conforme descrito em Limites.
  2. Defina variáveis de ambiente
  3. Crie um novo conjunto de chaves e uma chave
  4. Reserve um novo intervalo de endereços
  5. Crie uma nova instância
  6. Associe ambientes à nova instância
  7. Configure o encaminhamento

Cada um destes passos é descrito nas secções seguintes.

Pré-requisitos

Certifique-se de que a sua rede tem /22 e /28 como intervalos de endereços IP não sobrepostos disponíveis. Isto é além dos intervalos usados por outras regiões.

Limites

Por predefinição, a sua organização inicial é normalmente criada com uma única região. Ao decidir se deve criar uma segunda (ou subsequente) região, tenha em atenção que só pode adicionar uma região se as suas autorizações de licença o permitirem. Opcionalmente, pode comprar um pacote organizacional.

  • Se tiver um modelo de preços baseado em subscrição, pode ter de comprar unidades organizacionais adicionais para permitir a expansão para várias regiões. Consulte os direitos de subscrição.
  • Se tiver um modelo de preços de pagamento conforme o uso, a expansão para várias regiões vai incorrer em custos adicionais, conforme explicado no artigo Adicionar regiões para pagamento conforme o uso.
  • As contas de avaliação estão limitadas a uma região e não podem ser expandidas para uma segunda região.

Para mais informações, consulte o artigo Vista geral do pagamento conforme o uso.

Nenhuma organização pode ter mais de 10 (11 para híbrido) regiões.

Defina variáveis de ambiente

Recomendamos que defina as seguintes variáveis de ambiente para garantir a consistência nos comandos usados ao longo desta documentação.

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

Onde:

  • NEW_REGION_LOCATION é a localização física da sua nova instância. Os valores válidos são qualquer região do Compute Engine. Para mais informações, consulte o artigo Regiões e zonas. Por exemplo, us-west1.
  • NEW_INSTANCE_NAME é o nome da nova região. Tem de ser exclusivo da sua organização. Por exemplo, my-instance-2.
  • NETWORK_NAME é o nome da rede de peering da sua organização. Por exemplo, my-network. Consulte o artigo Configure a rede de serviços.
  • DISK_KEY_RING_NAME é um nome para o conjunto de chaves do disco.
  • DISK_KEY_NAME é um nome para o anel de disco.
  • AUTH define o cabeçalho Authentication com um token de portador. Vai usar este cabeçalho quando chamar as APIs Apigee. Tenha em atenção que o token expira após um período e, quando isso acontece, pode simplesmente regenerá-lo através do mesmo comando. Para mais informações, consulte a página de referência do comando print-access-token.
  • PROJECT_ID é o ID do seu projeto do Google Cloud.
  • PROJECT_NUMBER é o número do projeto na nuvem.

Crie um novo conjunto de chaves e uma chave

Cada região requer a sua própria chave de encriptação de disco para a rede. A Google recomenda que também crie um conjunto de chaves separado para a nova região. Não precisa de criar uma nova chave de encriptação da base de dados, uma vez que todas as instâncias numa organização partilham a mesma chave de encriptação da base de dados.

Para mais detalhes, consulte o artigo Acerca das chaves de encriptação do Apigee.

Para criar um novo conjunto de chaves e uma nova chave de encriptação de disco:

  1. Crie um novo conjunto de chaves do disco com o comando gcloud: 
    gcloud kms keyrings create $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

    Verifique se o conjunto de chaves do disco está definido para a mesma localização que a instância. Cada instância e anel de chaves deve ter a sua própria localização.

    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. Crie uma nova chave de disco com o comando kms keys create; por exemplo: 
    gcloud kms keys create $DISK_KEY_NAME --keyring $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION --purpose "encryption" --project $PROJECT_ID

    A chave pode ser referenciada pelo respetivo caminho da chave. Pode obter o caminho da chave com o seguinte comando:

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

    O caminho principal tem o seguinte aspeto:

    projects/PROJECT_ID/locations/NEW_REGION_LOCATION/keyRings/my-disk-key-ring/cryptoKeys/my-disk-key
  3. Conceda acesso ao agente do serviço Apigee para usar a nova chave executando o comando gcloud kms keys add-iam-policy-binding; por exemplo: 
    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

    Verifique se a chave está associada ao agente do serviço 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

Reserve um novo intervalo de endereços

Reserve endereços IP para o intervalo de endereços da sua rede de peering. Para mais informações e considerações importantes, consulte também o artigo Compreender os intervalos de peering.

  1. Crie estas variáveis de ambiente: 
    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

    Onde:

    • NEW_RANGE_NAME_22 é o nome do intervalo de endereços IP de comprimento CIDR /22 que vai criar. Pode atribuir qualquer nome ao intervalo. Por exemplo: google-svcs-new_22
    • NEW_RANGE_NAME_28 é o nome do intervalo de endereços IP de comprimento CIDR /28 que vai criar. Pode atribuir qualquer nome ao intervalo. Por exemplo: google-svcs-new_28
    • NETWORK_NAME é o nome do recurso de rede no qual os endereços devem ser reservados.

      A Google cria uma rede predefinida (denominada default) para cada novo projeto, para que a possa usar. No entanto, a Google não recomenda a utilização da rede predefinida para fins que não sejam testes.

  2. Crie um intervalo de IP de rede com um comprimento 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

    Em caso de êxito, o gcloud responde com o seguinte:

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

    Valide a morada de cálculo criada:

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

    Depois de criar um intervalo de endereços IP, os endereços são associados ao projeto até os libertar.

  3. Crie um intervalo de IP de rede com um comprimento CIDR de /28. Este intervalo é obrigatório e é usado pelo Apigee para fins de resolução de problemas, não podendo ser personalizado nem alterado. 
    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. Valide a morada de cálculo criada:

    gcloud compute addresses list \
  --global \
  --project=$PROJECT_ID
     
     gcloud compute addresses describe $NEW_RANGE_NAME_28 \
  --global \
  --project=$PROJECT_ID
  4. Obtenha os nomes dos intervalos de peering: 
    gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID
  5. Adicione os intervalos recentemente reservados à sua rede com peering com o seguinte comando, em que $NEW_RANGE_NAME_22 e $NEW_RANGE_NAME_28 são os nomes dos novos intervalos e ORIGINAL_RANGE_NAME_1 e ORIGINAL_RANGE_NAME_n são os nomes dos intervalos de peering reservados devolvidos no 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. Valide as alterações de vpc-peering que foram atualizadas:

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

Crie uma nova instância

Crie uma nova instância para a região através da API Instances.

Com o intercâmbio da VPC

Se o Apigee foi configurado para usar o peering de VPC, use esta chamada de API para criar a instância: 

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

Onde:

  • KEY_PATH é o caminho da chave de encriptação de disco que criou em Crie um novo conjunto de chaves e uma chave.
  • IP_ADDRESS_* são endereços IP CIDR para os intervalos CIDR /22 e /28 usados para criar a instância do Apigee. Tenha em atenção que ipRange é opcional. Se não fornecer este campo, o Apigee pede automaticamente um bloco CIDR /22 e /28 disponível ao serviço de rede. Consulte também a API de instâncias do Apigee.

    • Este pedido pode demorar até 20 minutos a ser concluído porque o Apigee tem de criar e iniciar um novo cluster do Kubernetes, instalar os recursos do Apigee nesse cluster e configurar o equilíbrio de carga.

Sem intercâmbio da VPC

Se o Apigee não estiver configurado para usar o peering de VPC, use esta chamada API para criar a instância: 

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

Onde:

  • KEY_PATH é o caminho da chave de encriptação de disco que criou em Crie um novo conjunto de chaves e uma chave. Consulte também a API de instâncias do Apigee.
  • consumerAcceptList(Opcional) Especifica uma lista de IDs de projetos do Google Cloud que podem estabelecer ligação privada ao anexo de serviço da VPC do Apigee. A associação de serviços é uma entidade usada com o Private Service Connect do Google Cloud para permitir que os produtores de serviços (neste caso, o Apigee) exponham serviços aos consumidores (neste caso, um ou mais projetos do Google Cloud que lhe pertencem). Por predefinição, usamos o projeto na nuvem que já está associado à sua organização do Apigee. Por exemplo: "consumerAcceptList": ["project1", "project2", "project3"]

Este pedido pode demorar até 20 minutos a ser concluído porque o Apigee tem de criar e iniciar um novo cluster do Kubernetes, instalar os recursos do Apigee nesse cluster e configurar o equilíbrio de carga.

timer A operação de criação de instâncias demora aproximadamente 30 minutos a concluir.

Para verificar o estado do seu pedido de criação de instância de tempo de execução, execute o seguinte comando. Quando o estado for ATIVO, pode avançar para o passo seguinte.

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

Para mais detalhes sobre a criação de uma instância de tempo de execução, incluindo contexto adicional e informações de resolução de problemas, consulte o Passo 5: crie uma instância de tempo de execução do Apigee.

Associe ambientes à nova instância

Depois de criar a instância, tem de anexar-lhe ambientes. Caso contrário, não pode responder a pedidos de API.

Os ambientes são partilhados entre instâncias. Por isso, deve anexar ambientes existentes à nova região. Não definir novos ambientes para a nova região. Se definir um novo ambiente para a nova região que está a publicar os mesmos caminhos base para os mesmos anfitriões que o seu ambiente original, as chamadas de tempo de execução podem devolver erros HTTP 503.

Quando preenche uma nova região com ambientes, não tem de anexar os ambientes a grupos de ambientes: já estão anexados aos respetivos grupos. Só tem de anexar os ambientes à nova instância.

Para anexar os seus ambientes à nova região, use a API Instances attachment, conforme mostrado no exemplo seguinte:

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 obter uma lista dos seus ambientes:

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

Tem de anexar cada ambiente com uma chamada separada à API Instances Attachment. Não pode anexar mais do que um ambiente numa única chamada.

Configure o encaminhamento

Pode configurar o encaminhamento de rede na nova região através de um grupo de instâncias gerido (GIG) ou de uma configuração baseada no Private Service Connect (PSC).

Configure o encaminhamento de PSC

Os passos seguintes explicam como configurar o encaminhamento na nova região através do PSC.

Vista geral

A figura seguinte mostra a arquitetura de alto nível no sentido ascendente para o PSC multirregional:

Diagrama do encaminhamento de PSC multirregional.

Figura 1: arquitetura de várias regiões de saída com PSC

Conforme ilustrado na Figura 1, vai criar um grupo de pontos finais de rede (NEG) no seu projeto que comunica com uma associação de serviço na região onde reside a nova instância do Apigee. Os NEGs do Apigee para todas as regiões estão ligados ao serviço de back-end do balanceador de carga externo global de produção do Apigee.

Crie um grupo de pontos finais de rede para a nova região

Siga estes passos para criar e configurar um equilibrador de carga com um grupo de pontos finais de rede (NEG) para a nova região:

  1. Crie um novo NEG:
    1. Obtenha a associação de serviço da instância que criou anteriormente: 
      curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

      Na saída de exemplo seguinte, o valor serviceAttachment é apresentado a negrito: 

      {
  "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. Crie um NEG que aponte para a associação de serviço que obteve do corpo da resposta da instância no passo 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

      Substitua o seguinte:

      • NEG_NAME: um nome para o grupo de pontos finais da rede.
      • TARGET_SERVICE: o anexo de serviço ao qual quer estabelecer ligação. Por exemplo: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
      • NETWORK_NAME: (Opcional) Nome da rede na qual o NEG é criado. Se omitir este parâmetro, é usada a rede do projeto default.
      • SUBNET_NAME: nome da sub-rede usada para a conetividade privada ao produtor. O tamanho da sub-rede pode ser pequeno: o NEG do PSC só precisa de um IP da sub-rede. Para o Apigee, só é necessário um NEG do PSC por região. A sub-rede pode ser partilhada e usada por VMs ou outras entidades. Se não for especificada uma sub-rede, os pontos finais de rede podem pertencer a qualquer sub-rede na região onde o grupo de pontos finais de rede é criado.
      • PROJECT_ID O projeto do Cloud que já está associado à sua organização do Apigee ou um projeto do Cloud incluído no consumerAcceptlist quando a instância de runtime do Apigee foi criada.
  2. Obtenha o nome do serviço de back-end para o balanceador de carga do Apigee de produção: 
    gcloud compute backend-services list --project=$PROJECT_ID
  3. Adicione o NEG como back-end ao serviço de back-end: 
    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

    Substitua o seguinte:

    • BACKEND_SERVICE_NAME: o nome do serviço de back-end.
    • NEG_NAME: o nome do grupo de pontos finais da rede.
  4. (Opcional) Pode definir uma política de tráfego de deteção de valores atípicos no serviço de back-end para processar automaticamente cenários de comutação por falha. Consulte o seguinte para mais informações:

Teste a configuração final

Chamar um proxy de API. Consulte o artigo Implemente um proxy de exemplo.

Configure o encaminhamento de MIG

Os passos seguintes explicam como configurar o encaminhamento na nova região através de um grupo de instâncias gerido (MIG).

Vista geral

A figura seguinte mostra a arquitetura de nível elevado e de sentido ascendente para várias regiões que usam grupos de instâncias geridos (MIGs):

Diagrama da arquitetura de saída para o PSC multirregional.

Figura 2: arquitetura multirregião de saída com MIG

Conforme ilustrado na Figura 2, vai criar um MIG no seu projeto para comunicar com um equilibrador de carga implementado na região onde reside a nova instância do Apigee. Os proxies MIG para todas as regiões estão ligados ao back-end do equilibrador de carga externo global de produção do Apigee.

Crie um grupo de instâncias geridas (MIG) para a nova região

Siga estes passos para criar e configurar um MIG para a nova região:

  1. Ative o acesso privado à Google para uma sub-rede da sua rede VPC.

    Para ativar o acesso privado à Google para uma sub-rede da sua rede VPC, siga os passos indicados em Ativar o acesso privado à Google.

  2. Configure variáveis de ambiente:

    As instruções nesta secção usam variáveis de ambiente para fazer referência a strings usadas repetidamente. Recomendamos que defina estas opções 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. Crie um grupo de instâncias gerido. Neste passo, cria e configura um grupo de instâncias geridas (MIG).
    1. Crie um modelo de instância executando o seguinte 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 pode ver neste comando, as máquinas são do tipo e2-medium. Executam o Debian 12 e têm 20 GB de disco. O script startup-script.sh configura o MIG para encaminhar o tráfego de entrada do balanceador de carga para a instância do Apigee.

    2. Crie um grupo de instâncias gerido executando o seguinte 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. Configure o dimensionamento automático para o grupo executando o seguinte 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. Defina uma porta com nome executando o seguinte comando: 
      gcloud compute instance-groups managed set-named-ports $MIG_NAME \
  --project $PROJECT_ID --region $NEW_REGION_LOCATION --named-ports https:443
  4. Obtenha o nome do serviço de back-end para o balanceador de carga do Apigee de produção: 
    gcloud compute backend-services list --project=$PROJECT_ID
  5. Adicione o MIG ao serviço de back-end com o seguinte 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

    Substitua BACKEND_SERVICE_NAME pelo nome do serviço de back-end.

Teste a configuração final

Chamar um proxy de API. Consulte o artigo Implemente um proxy de exemplo.

Adicionar regiões

Adicionar várias regiões a um ambiente do Apigee pode oferecer alta disponibilidade, maior capacidade e menor latência para as suas APIs. Uma implementação em várias regiões suporta a elevada disponibilidade porque a comutação por falha manual não é necessária, uma vez que o XLB verifica o estado de funcionamento de cada região. É disponibilizada uma capacidade mais elevada quando várias regiões publicam as mesmas APIs em simultâneo. Além disso, se os seus clientes de API estiverem em várias regiões, o facto de a API ser fornecida a partir de uma região mais próxima dos seus clientes ajuda a reduzir a latência e a melhorar o desempenho.

Exemplo: uma implementação em várias regiões melhora a disponibilidade, a capacidade e a latência

Numa implementação multirregional ativa-ativa, o tráfego é processado em duas regiões em simultâneo. Adiciona um serviço de back-end para o MIG de cada região ao mesmo balanceador de carga HTTPS externo (XLB), conforme explicado no Passo 8e(3) no separador Encaminhamento externo (MIG) na secção Passo 8: configure o encaminhamento. Para mais informações, consulte também o artigo Crie um grupo de instâncias gerido (MIG) para a nova região.

Para cada pedido, o XLB escolhe a região mais próxima do cliente, a menos que o número de pedidos exceda o limite definido para um back-end específico. Consulte o artigo Otimizações da capacidade das aplicações com o balanceamento de carga global para mais informações sobre como os balanceadores de carga externos encaminham o tráfego.

Adicionar regiões para o modelo de pagamento pré-pago

Com o modelo de preços Pay-as-you-go, pode definir o número mínimo de nós do gateway do Apigee para um ambiente. Isto permite garantir que as regiões são sempre executadas com capacidade adicional para suportar imediatamente o tráfego de comutação por falha, em caso de falha de uma região.

Definir o número mínimo de nós do gateway do Apigee

Se conseguir publicar todo o seu tráfego normal da API a partir de 2 regiões ativas, cada uma com 4 nós de gateway do Apigee, cada região deve ter, no mínimo, 8 nós. Isto destina-se a suportar imediatamente a perda de uma região. Consulte o artigo Acerca dos nós do Apigee para mais informações sobre como determinar o número de nós de que precisa para processar o tráfego da API. Tenha em atenção que o número mínimo de nós é definido por ambiente, mas aplicado por região. Por exemplo, se definir o mínimo como 8, cada região tem um mínimo de 8 nós.

Custo

No exemplo acima, incorreria no custo de execução de, pelo menos, 16 nós de gateway do Apigee (8 nós x 2 regiões). O custo pode aumentar à medida que os números de nós aumentam automaticamente para processar tráfego adicional, até ao máximo.

Remover o Apigee de uma região

Para desativar uma instância do Apigee da publicação de tráfego de API, siga estes passos para garantir um serviço ininterrupto (tempo de inatividade zero para as suas APIs):

  1. Ative a drenagem de ligações no serviço de back-end. A drenagem de ligações é um processo que garante que os pedidos existentes em curso têm tempo para serem concluídos quando um back-end é removido do serviço de back-end.
  2. Se o Cloud DNS tiver sido configurado para encaminhar o tráfego para esta região do Apigee através da política de encaminhamento de round-robin ponderado, remova essa configuração de DNS, conforme descrito no artigo Gerir políticas de encaminhamento de DNS e verificações de estado.
  3. Desassocie o back-end do MIG do serviço de back-end. Isto, juntamente com a drenagem de ligações, garante que a instância do Apigee não recebe novo tráfego, mas permite que os pedidos em curso sejam concluídos.
  4. Elimine a instância do Apigee e o respetivo MIG correspondente. Consulte o artigo Elimine uma instância.