Acerca das associações de peering

Esta página fornece uma vista geral da administração das associações de intercâmbio da rede da VPC.

Ligação de intercâmbio

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

Inicia o pedido de ligação a outra rede VPC criando uma configuração de peering. Depois de a outra rede ter uma configuração correspondente para estabelecer uma relação de peering com a sua rede, a ligação de peering é estabelecida e o estado de peering é alterado para ACTIVE em ambas as redes. O estado de peering permanece INACTIVE se a outra rede não tiver uma configuração de peering correspondente, o que indica que a sua rede não está ligada à outra.

A criação de uma ligação de peering não lhe concede funções de gestão de identidade e de acesso na rede VPC de outro utilizador. Por exemplo, se tiver a função de administrador da rede de computação (roles/compute.networkAdmin) ou a função de administrador de segurança de computação (roles/compute.securityAdmin) para uma rede, não se torna administrador de rede nem administrador de segurança para a outra rede.

Depois de estabelecer a ligação de peering, as duas redes VPC trocam sempre rotas de sub-rede IPv4 que usam intervalos de endereços IPv4 privados. Para mais informações sobre as opções de troca de rotas, consulte o seguinte:

Modo de ligação

O modo de associação determina como uma associação de peering é administrada. O intercâmbio da rede da VPC suporta dois modos de ligação:

Para implementações padrão, o modo independente é geralmente preferível. No entanto, para implementações que suportem um serviço crítico em que a eliminação acidental da ligação de peering causaria uma indisponibilidade do serviço, recomendamos a utilização do modo de consenso. Este modo requer o consentimento de ambas as redes e impede alterações unilaterais à ligação de peering.

Quando cria uma ligação de peering, ambas as configurações de peering têm de especificar o mesmo modo de ligação: independente ou de consenso.

Para alterar o modo de peering de uma ligação existente de independente para consenso, ambas as configurações de peering têm de ser atualizadas. A alteração do modo de associação de consenso para independente não é suportada.

Modo independente

Quando uma ligação de peering está no modo independente (predefinição), qualquer uma das redes pode atualizar ou eliminar a ligação em qualquer altura. Opcionalmente, pode restringir este comportamento atualizando o modo de ligação para consenso.

Modo de consenso

O modo de consenso impede alterações acidentais e unilaterais ao comportamento da rede. Quando uma ligação de peering está no modo de consenso, cada pedido para eliminar a ligação de peering requer o consentimento de ambas as redes.

Limitações

A atualização das associações de intercâmbio no modo de consenso não é suportada. Para atualizar as opções de troca de rotas ou quaisquer outros parâmetros de configuração de uma ligação de peering no modo de consenso, tem de eliminar a ligação e, em seguida, recriá-la com os parâmetros de configuração pretendidos.

Configurar o modo de consenso para uma associação

Pode configurar uma associação de peering nova ou existente para usar o modo de consenso. Antes de configurar uma ligação de peering para usar o modo de consenso, considere o seguinte:

  • O parâmetro update_strategy configura o modo de ligação. Para alterar o modo de associação, tem de atualizar a estratégia de atualização nas configurações locais e de pares de INDEPENDENT para CONSENSUS. Até que ambas as configurações sejam atualizadas, a estratégia de atualização eficaz permanece INDEPENDENT e os pedidos de eliminação unilateral da associação são permitidos.

    Depois de iniciar um pedido para alterar o modo de ligação, a rede par pode aceitar o pedido ou a rede local pode revertê-lo.

  • Para configurar o modo de consenso para uma ligação, cada opção de troca de rotas que pretenda usar tem de ter o mesmo valor que a flag complementar na configuração de peering correspondente. Por exemplo, se a sua rede importar encaminhamentos personalizados, a outra rede tem de exportar encaminhamentos personalizados.

    Se os valores das seguintes flags complementares não corresponderem entre as configurações, o pedido de atualização do modo de ligação é rejeitado. Ambas as partes da ligação podem atualizar estes valores antecipadamente ou quando atualizam o modo de ligação.

    A sua rede Rede ponto a ponto
    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
  • Os pedidos pendentes de atualização do modo de associação não causam tempo de inatividade e a associação permanece ativa enquanto o pedido está em curso.

Para mais informações, consulte os artigos Crie uma associação de pares no modo de consenso e Atualize uma associação para o modo de consenso
.

Eliminar uma associação no modo de consenso

Para eliminar uma associação de peering no modo de consenso, ambas as partes da associação têm de enviar um pedido de eliminação antes de a associação poder ser eliminada. Depois de iniciar um pedido de eliminação, não é possível cancelá-lo.

Para mais informações, consulte o artigo Elimine uma associação (modo de consenso).

Estado da ligação

O comando gcloud compute networks describe mostra o estado efetivo de uma associação de pares e a sua configuração de associação de pares local.

Pode ver o estado da associação efetiva examinando o campo peerings.connectionStatus. A tabela seguinte descreve os respetivos estados de configuração disponíveis. A marca de verificação indica que o campo está disponível.

Campo Modo independente Modo de consenso Descrição
trafficConfiguration Mostra as opções de troca de rotas eficazes da associação de peering.
updateStrategy Mostra o modo de ligação: INDEPENDENT ou CONSENSUS.
consensusState.deleteStatus
  • UNSPECIFIED: não existem pedidos requestRemovePeering pendentes para esta associação de pares.
  • LOCAL_DELETE_REQUESTED: o proprietário desta interligação pediu a eliminação da ligação de interligação.
  • PEER_DELETE_REQUESTED: o proprietário do intercâmbio correspondente solicitou a eliminação da ligação de intercâmbio.
  • DELETE_ACKNOWLEDGED: ambos os proprietários da interligação desta ligação pediram a eliminação da ligação de interligação. Os pedidos removePeering subsequentes vão ter êxito para qualquer uma das relações de intercâmbio.
consensusState.updateStatus
  • IN_SYNC: nenhum proprietário da interligação tem atualizações pendentes.
  • PENDING_PEER_ACK: o proprietário da interligação local fez uma alteração, mas o proprietário da interligação correspondente não aplicou as alterações correspondentes à respetiva interligação.
  • PENDING_LOCAL_ACK: o proprietário da interligação correspondente fez uma alteração, mas o proprietário da interligação local não aplicou as alterações correspondentes a esta interligação.

Para listar todas as configurações de peering num Google Cloud projeto, consulte o artigo Listar ligações de peering.

O que se segue?