Sobre as conexões de peering

Esta página oferece uma visão geral da administração de conexões de peering de rede VPC.

Conexão de peering

Uma conexão de peering conecta duas redes de nuvem privada virtual (VPC). Para estabelecer uma conexão de peering, cada lado cria separadamente uma configuração de peering que faz referência à outra rede.

Você inicia a solicitação de conexão a outra rede VPC criando uma configuração de peering. Quando a outra rede tiver uma configuração correspondente para fazer peering com a sua, a conexão de peering será estabelecida e o estado de peering será alterado para ACTIVE nas duas redes. O estado de peering permanecerá INACTIVE se a outra rede não tiver uma configuração de peering correspondente, indicando que sua rede não está conectada à outra.

A criação de uma conexão de peering não concede papéis do Identity and Access Management na outra rede VPC. Por exemplo, se tiver o papel de Administrador de rede do Compute (roles/compute.networkAdmin) ou de Administrador de segurança do Compute (roles/compute.securityAdmin) em uma rede, você não se tornará Administrador da rede ou Administrador de segurança na outra rede.

Depois que a conexão de peering for estabelecida, as duas redes VPC sempre trocarão rotas de sub-rede IPv4 que usam intervalos de endereços IPv4 particulares. Para mais informações sobre as opções de troca de rota, consulte o seguinte:

Modo de conexão

O modo de conexão determina como uma conexão de peering é administrada. O peering de rede VPC oferece suporte a dois modos de conexão:

Para implantações padrão, o modo independente geralmente é preferível. No entanto, para implantações que oferecem suporte a um serviço crítico em que a exclusão acidental da conexão de peering causaria uma interrupção do serviço, recomendamos o uso do modo de consenso. Esse modo exige o consentimento de ambas as redes e impede mudanças unilaterais no status efetivo da conexão de peering.

Ao criar uma conexão de peering, as duas configurações de peering precisam especificar o mesmo modo de conexão: independente ou de consenso.

Para mudar o modo de peering de uma conexão atual de independente para de consenso, as duas configurações de peering precisam ser atualizadas. Não é possível mudar o modo de conexão de consenso para independente.

Modo independente

Quando uma conexão de peering está no modo independente (padrão), qualquer rede pode atualizar ou excluir a conexão a qualquer momento. Você pode restringir esse comportamento atualizando o modo de conexão para de consenso.

Modo de consenso

O modo de consenso impede mudanças unilaterais acidentais no comportamento da rede. Quando uma conexão de peering está no modo de consenso, cada solicitação para atualizar ou excluir a conexão de peering exige o consentimento de ambas as redes.

Configurar o modo de consenso para uma conexão

É possível configurar uma conexão de peering nova ou atual para usar o modo de consenso definindo o parâmetro update_strategy:

  • Nova conexão. As duas redes precisam definir a estratégia de atualização como CONSENSUS. Se a estratégia de atualização não for especificada, a conexão será criada no modo independente.

  • Conexão atual. As duas redes precisam mudar a estratégia de atualização para CONSENSUS. Até que os dois valores correspondam, a estratégia de atualização efetiva permanece INDEPENDENT, e as solicitações unilaterais de atualização e exclusão são permitidas.

    As solicitações pendentes para atualizar o modo de conexão não causam inatividade, e a conexão permanece ativa enquanto a solicitação está em andamento.

Além disso, para configurar o modo de consenso para uma conexão, cada opção de troca de rota na configuração precisa ter o mesmo valor que a flag complementar na configuração do peer. Se os valores das flags a seguir não corresponderem, a solicitação para criar ou atualizar a conexão será rejeitada.

Flag local Flag complementar do peer
import_custom_route export_custom_route
export_custom_route import_custom_route
import_subnet_routes_with_public_ip export_subnet_routes_with_public_ip
export_subnet_routes_with_public_ip import_subnet_routes_with_public_ip
stack_type stack_type

Por exemplo, se a rede importar rotas personalizadas, a rede do peer precisará exportar rotas personalizadas. Se algum desses valores não corresponder a uma conexão atual, qualquer rede poderá atualizá-los antes ou ao mudar o modo de conexão.

Para cancelar uma solicitação pendente para configurar o modo de consenso para uma conexão atual, a rede solicitante precisa redefinir a estratégia de atualização para INDEPENDENT.

Para mais informações, consulte Criar uma conexão de peering no modo de consenso e Atualizar uma conexão para o modo de consenso
.

Atualizar uma conexão no modo de consenso

Qualquer lado de uma conexão de peering pode enviar uma solicitação de atualização. Uma solicitação de atualização pendente não causa inatividade, e a conexão permanece ativa. Se uma solicitação de exclusão estiver em andamento, todas as solicitações de atualização (incluindo aceitar ou cancelar uma solicitação de atualização pendente) serão rejeitadas.

Para atualizar uma conexão de peering configurada com o modo de consenso, o administrador da rede local primeiro atualiza a configuração local. Em seguida, o administrador da rede do peer precisa fazer uma atualização complementar na configuração do peer. Por exemplo, se você atualizar a flag --export-custom-routes para true, a rede do peer precisará definir a flag --import-custom-routes como true. O status efetivo da conexão de peering não será alterado até que a rede do peer atualize a configuração correspondente.

Depois que a configuração de peering local for atualizada, nenhum dos lados da conexão poderá enviar outras solicitações de atualização até que a atualização inicial seja aceita ou cancelada. Atualizações parciais não são aceitas. Se uma solicitação atualizar vários parâmetros, todos eles precisarão ser aceitos ou cancelados. Para cancelar uma atualização, a rede solicitante redefine cada parâmetro modificado para o valor anterior.

O diagrama a seguir mostra como o status de uma conexão de peering muda quando uma solicitação de atualização é enviada.

Como atualizar uma conexão de peering no modo de consenso
Atualização de uma conexão de peering no modo de consenso (clique para ampliar).

No diagrama anterior, depois que a rede A envia a solicitação de atualização, o status de atualização da conexão muda de IN_SYNC para PENDING_PEER_ACKNOWLEDGMENT na configuração local e para PENDING_LOCAL_ACKNOWLEDGMENT na configuração do peer.

Para retornar ao status IN_SYNC, a rede B precisa fazer a mudança complementar ou a rede A precisa cancelar a solicitação. Para mais informações sobre esses status de conexão, consulte Status da conexão.

Para atualizar uma conexão de peering, consulte Atualizar uma conexão (modo de consenso).

Excluir uma conexão no modo de consenso

Para excluir uma conexão de peering no modo de consenso, os dois lados da conexão precisam enviar uma solicitação de exclusão. É possível cancelar uma solicitação de exclusão antes ou depois que ela for aceita pela rede do peer.

As condições a seguir se aplicam a solicitações de exclusão:

  • Se uma solicitação de atualização estiver pendente, ainda será possível excluir a conexão de peering.
  • Se uma solicitação de exclusão estiver pendente, todas as solicitações de atualização, incluindo aceitar ou cancelar uma atualização pendente, serão rejeitadas. Para concluir uma atualização pendente, primeiro cancele a solicitação de exclusão.

Para mais informações, consulte Excluir uma conexão (modo de consenso).

Status da conexão

O gcloud compute networks describe comando mostra o status efetivo de uma conexão de peering e a configuração de peering local.

É possível conferir o status de conexão efetivo examinando o campo peerings.connectionStatus. A tabela a seguir descreve os status de configuração disponíveis. A marca de seleção indica que o campo está disponível.

Campo Modo independente Modo de consenso Descrição
trafficConfiguration Mostra as opções de troca de rota efetivas da conexão de peering.
updateStrategy Mostra o modo de conexão efetivo: INDEPENDENT ou CONSENSUS.
consensusState.deleteStatus
  • UNSPECIFIED: nenhuma solicitação requestRemovePeering está pendente para essa conexão de peering. O campo deleteStatus não aparece na saída quando o status é UNSPECIFIED.
  • LOCAL_DELETE_REQUESTED: o proprietário desse peering solicitou a exclusão da conexão de peering.
  • PEER_DELETE_REQUESTED: o proprietário do peering correspondente solicitou a exclusão da conexão de peering.
  • DELETE_ACKNOWLEDGED: os dois proprietários de peering dessa conexão solicitaram a exclusão da conexão de peering. As solicitações removePeering subsequentes serão bem-sucedidas para qualquer peering.
  • LOCAL_CANCEL_REQUESTED: a conexão de peering estava no estado DELETE_ACKNOWLEDGED mas a rede local cancelou a exclusão.
  • PEER_CANCEL_REQUESTED: a conexão de peering estava no estado DELETE_ACKNOWLEDGED mas a rede do peer cancelou a exclusão.
consensusState.updateStatus
  • IN_SYNC: nenhum proprietário de peering tem atualizações pendentes.
  • PENDING_PEER_ACKNOWLEDGMENT: o proprietário do peering local fez uma mudança, mas o proprietário do peering correspondente não aplicou as mudanças correspondentes ao peering.
  • PENDING_LOCAL_ACKNOWLEDGMENT: o proprietário do peering correspondente fez uma mudança, mas o proprietário do peering local não aplicou as mudanças correspondentes a esse peering.

Para listar todas as configurações de peering em um Google Cloud projeto, consulte Listar conexões de peering.

A seguir