Esta página descreve como configurar uma implantação multirregional altamente disponível com balanceadores de carga de aplicativo externos regionais. Para ter alta disponibilidade, implante vários balanceadores de carga de aplicativo externos regionais individuais nas regiões que melhor oferecem suporte ao do tráfego do aplicativo. Isso funciona porque os balanceadores de carga de aplicativo externos regionais em diferentes regiões não são apenas isolados entre si, mas também são isolados de qualquer balanceador de carga de aplicativo externo global ou infraestrutura de balanceador de carga de aplicativo clássico em execução na mesma região.
Estratégias de alta disponibilidade
É possível implementar a resiliência entre regiões para balanceadores de carga de aplicativo externos regionais usando uma das seguintes estratégias:
Ativo-passivo (failover regional): implante um balanceador de carga de aplicativo externo regional principal na região principal e um ou mais balanceadores de carga de aplicativo externos regionais de backup em regiões secundárias. Em estado estável, o Cloud DNS encaminha todo o tráfego para o balanceador de carga principal. Se o balanceador de carga principal falhar nas verificações de integridade, o Cloud DNS usará uma política de roteamento de failover para encaminhar o tráfego aos balanceadores de carga regionais de backup.
Este é um exemplo de configuração ativo-passiva que mostra dois balanceadores de carga de aplicativo externos regionais em duas regiões diferentes.
Ativo-ativo (roteamento por proximidade): implante vários balanceadores de carga de aplicativo externos regionais em diferentes regiões que atendem ao tráfego simultaneamente. Use uma política de roteamento de geolocalização do Cloud DNS para direcionar os clientes à região íntegra mais próxima. Se um balanceador de carga em uma região sofrer uma interrupção, o Cloud DNS vai rotear automaticamente o tráfego da região não íntegra para balanceadores de carga íntegros em outras regiões.
Este é um exemplo de configuração ativo-ativo que mostra dois balanceadores de carga de aplicativo externos regionais em duas regiões diferentes.
Alta disponibilidade com dois balanceadores de carga de aplicativo externos regionais (clique para ampliar).
As seções a seguir descrevem como a verificação de integridade e o direcionamento de tráfego operam em várias regiões em um fluxo de trabalho típico:
Usar verificações de integridade para detectar falhas regionais
OGoogle Cloud usa verificações de integridade para detectar se os balanceadores de carga regionais estão íntegros. Configure essas verificações de integridade para enviar sondagens de três regiões de origem. Essas três regiões de origem precisam ser das regiões de onde seus clientes acessam a carga balanceadores de carga HTTP(S) externos. Por exemplo, se você tiver um balanceador de carga de aplicativo externo regional com a maioria do tráfego do cliente originário da América do Norte e da Europa, poderá ter sondas originárias de duas ou mais regiões na América do Norte e sondagens originárias de duas ou mais regiões na Europa.
Observações adicionais:
- É preciso especificar exatamente três regiões de origem ao criar a verificação de integridade. Somente as verificações de integridade globais podem especificar regiões de origem.
- As verificações de integridade HTTP, HTTPS e TCP são compatíveis.
- As sondagens de verificação de integridade têm origem em um ponto de presença (PoP) na Internet a uma pequena distância da região de origem configurada Google Cloud.
Encaminhar o tráfego com base em políticas de roteamento
- Ativo-passivo: o Cloud DNS usa uma política de roteamento de failover para direcionar 100% do tráfego de clientes ao balanceador de carga regional principal durante o estado estável. Quando o balanceador de carga regional principal falha nas verificações de integridade, o Cloud DNS direciona o tráfego para os balanceadores de carga regionais de backup.
- Ativo-ativo: o Cloud DNS usa uma política de roteamento de geolocalização para direcionar o tráfego aos balanceadores de carga. Quando todos os balanceadores de carga estão íntegros, o Cloud DNS encaminha o tráfego para o balanceador de carga geograficamente mais próximo do cliente. Quando um balanceador de carga em uma região começa a falhar nas verificações de integridade, o tráfego é automaticamente direcionado para balanceadores de carga íntegros disponíveis em outras regiões.
Failback para o balanceador de carga principal
O failback é automático quando as verificações de integridade começam a ser aprovadas novamente. O tráfego é restaurado sem tempo de inatividade porque os balanceadores de carga estão disponibilizando o tráfego.
Configurar o balanceamento de carga multirregional
Para configurar uma implantação multirregional que facilite a alta disponibilidade, siga estas etapas:
- Crie balanceadores de carga de aplicativo externos regionais nas regiões que você determinar como as melhores para o tráfego do seu aplicativo. Cada um desses balanceadores de carga precisa ter a mesma configuração de gerenciamento de tráfego e segurança.
- Crie verificações de integridade para monitorar os endereços IP da regra de encaminhamento dos balanceadores de carga regionais.
- Configure sua política de roteamento de DNS no Cloud DNS:
- Para implantações ativo-passivo, crie uma política de roteamento de failover.
- Para implantações ativas-ativas, crie uma política de roteamento de geolocalização.
Criar balanceadores de carga em várias regiões
Observe as seguintes considerações ao configurar seus balanceadores de carga redundantes adicionais:
Configure todos os balanceadores de carga de aplicativo externos regionais com recursos semelhantes para que o tráfego seja processado de forma consistente, independentemente de qual balanceador de carga atende à solicitação. Por exemplo, use o mesmo tipo de certificado SSL, as mesmas políticas de segurança regionais do Cloud Armor e as mesmas configurações de roteamento do mapa de URL para todos os balanceadores de carga de aplicativo externos regionais.
Recomendamos o uso de um framework de automação, como o Terraform, para ajudar a alcançar e manter a consistência nas configurações do balanceador de carga nas diferentes implantações regionais.
Recomendamos que você configure balanceadores de carga de aplicativo externos regionais em cada região que você determinar que suportará melhor o tráfego para seu aplicativo.
Os balanceadores de carga de aplicativo externos regionais dão suporte aos níveis de serviço de rede Premium e Standard. Recomendamos que você configure os balanceadores de carga de aplicativo externos regionais no nível Premium para garantir baixa latência.
Para saber como configurar um balanceador de carga de aplicativo externo regional, consulte Configurar um balanceador de carga de aplicativo externo regional com back-ends de grupos de instâncias de VM.
Criar a verificação de integridade
Crie uma verificação de integridade global para monitorar o endereço IP externo da regra de encaminhamento de cada balanceador de carga regional:
gcloud compute health-checks create http HEALTH_CHECK_NAME \
--global \
--source-regions=SOURCE_REGION_1,SOURCE_REGION_2,SOURCE_REGION_3 \
--use-serving-port \
--check-interval=HEALTH_CHECK_INTERVAL \
--healthy-threshold=HEALTHY_THRESHOLD \
--unhealthy-threshold=UNHEALTHY_THRESHOLD \
--request-path=REQUEST_PATH
Substitua:
HEALTH_CHECK_NAME: o nome da verificação de integridade.SOURCE_REGION_1,SOURCE_REGION_2eSOURCE_REGION_3: as três regiões do Google Cloudem que as sondagens de verificação de integridade são enviadas. Você deve especificar exatamente três regiões de origem.HEALTH_CHECK_INTERVAL: o tempo em segundos desde o início de uma sondagem emitida por uma sonda até o início da próxima sondagem emitida pela mesma sonda. O valor mínimo aceito é de 30 segundos. Para valores recomendados, consulte Práticas recomendadas.HEALTHY_THRESHOLDeUNHEALTHY_THRESHOLD: especificam o número de sondagens sequenciais que precisam ser bem-sucedidas ou falhar para que o balanceador de carga seja considerado íntegro ou não íntegro. Se omitidos, Google Cloud usará um limite padrão de 2.REQUEST_PATH: o caminho do URL para o qual o Google Cloud envia solicitações de sondagem de verificação de integridade. Se omitido, Google Cloud enviará solicitações de sondagem para o caminho raiz,/. Se os endpoints que estão sendo verificados forem particulares, o que não é comum para endereços IP regra de encaminhamento externas, defina esse caminho como/afhealthz.
Configurar o failover regional ativo-passivo
No Cloud DNS, crie um conjunto de registros e aplique uma política de roteamento FAILOVER para enviar tráfego de estado estável ao balanceador de carga regional principal e fazer failover para o balanceador de carga regional de backup durante uma interrupção:
gcloud dns record-sets create DNS_RECORD_SET_NAME \
--ttl=TIME_TO_LIVE \
--type=RECORD_TYPE \
--zone="MANAGED_ZONE_NAME" \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=PRIMARY_REGIONAL_FORWARDING_RULE \
--routing-policy-backup-data_type=GEO \
--routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP]" \
--health-check=HEALTH_CHECK_NAME \
--backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO
Substitua:
DNS_RECORD_SET_NAME: o DNS ou nome de domínio do conjunto de registros a ser adicionado. Por exemplo,test.example.com.TIME_TO_LIVE: o TTL em segundos do registro. Para valores recomendados, consulte Práticas recomendadas.RECORD_TYPE: o tipo de registro. Por exemplo,A.MANAGED_ZONE_NAME: o nome da sua zona gerenciada do Cloud DNS. Por exemplo,my-zone-name.PRIMARY_REGIONAL_FORWARDING_RULE: o nome da regra de encaminhamento do balanceador de carga de aplicativo externo regional principal.BACKUP_REGION_1eBACKUP_REGION_2: as regiões em que os balanceadores de carga de aplicativo externos regionais de backup são implantados.BACKUP_LOAD_BALANCER_1_IPeBACKUP_LOAD_BALANCER_2_IP: os endereços IP externo da regra de encaminhamento dos balanceadores de carga de aplicativo externos regionais de backupHEALTH_CHECK_NAME: o nome da verificação de integridade.BACKUP_DATA_TRICKLE_RATIO: a fração de tráfego (de 0 a 1, como0.1) a ser enviada ao balanceador de carga regional de backup durante o estado estável para garantir que o backup esteja preparado e pronto. O padrão é 0.
Configurar o roteamento de região ativo-ativo
No Cloud DNS, crie um conjunto de registros e aplique uma política de roteamento de geolocalização para direcionar o tráfego simultaneamente em balanceadores de carga regionais íntegros:
gcloud dns record-sets create DNS_RECORD_SET_NAME \
--ttl=TIME_TO_LIVE \
--type=RECORD_TYPE \
--zone="MANAGED_ZONE_NAME" \
--routing-policy-type="GEO" \
--routing-policy-data="FORWARDING_RULE_NAME_A@REGION_A;FORWARDING_RULE_NAME_B@REGION_B[,;FORWARDING_RULE_NAME_C@REGION_C]" \
--health-check=HEALTH_CHECK_NAME
Substitua:
DNS_RECORD_SET_NAME: o DNS ou nome de domínio do conjunto de registros a ser adicionado. Por exemplo,test.example.com.TIME_TO_LIVE: o time to live (TTL), em segundos, para fins de registro. Para valores recomendados, consulte Práticas recomendadas.RECORD_TYPE: o tipo de registro. Por exemplo,A.MANAGED_ZONE_NAME: o nome da zona gerenciada com os conjuntos de registros que você quer gerenciar. Por exemplo,my-zone-nameFORWARDING_RULE_NAME_A,FORWARDING_RULE_NAME_BeFORWARDING_RULE_NAME_C: os nomes das regras de encaminhamento para os balanceadores de carga em cada região correspondente.REGION_A,REGION_BeREGION_C: as regiões em que cada balanceador de carga é implantadoHEALTH_CHECK_NAME: o nome da verificação de integridade.
Práticas recomendadas
Confira algumas práticas recomendadas ao configurar registros do Cloud DNS e verificações de integridade:
Calcular a duração da interrupção: o tempo que leva para o tráfego ser roteado de balanceadores de carga não íntegros para íntegros (a duração da interrupção) depende do valor de TTL do DNS, do intervalo de verificação de integridade e do parâmetro limite não íntegro da verificação de integridade:
Duration of outage = DNS TTL + Health Check Interval * Unhealthy ThresholdRecomendamos configurar o TTL do DNS como 30 a 60 segundos. TTLs mais altos levam a tempos de inatividade mais longos porque os clientes na Internet continuam acessando os balanceadores de carga não saudáveis, mesmo depois que o DNS falhar para outras regiões.
Configure os limites de verificação de integridade: configure os parâmetros de limite íntegro e não íntegro para evitar o redirecionamento abrupto e desnecessário do tráfego devido a erros temporários. Limites mais altos aumentam o tempo necessário para o tráfego mudar para balanceadores de carga em outras regiões.
Use o tráfego do trickle para validação ativa-passiva: em configurações ativas-passivas, configure a flag
--backup-data-trickle-ratiopara enviar continuamente uma pequena porcentagem de tráfego (por exemplo,0.1) ao balanceador de carga regional de backup durante o estado estável. Isso verifica se a infraestrutura de backup está ativa e pronta para processar o tráfego durante um evento de failover.