Nesta página, você encontra a terminologia principal que se aplica aos produtos de conectividade de rede. Analise esses termos para entender melhor como cada produto funciona.
Termos do Google Cloud
A terminologia a seguir se aplica ao Google Cloud e aos recursos dele.
Termos do Cloud VPN
Os termos a seguir se aplicam aos gateways e túneis do Cloud VPN e aos gateways na sua rede de peering.
- outro gateway do Cloud VPN;
- um gateway de VPN hospedado por outro provedor de nuvem, como AWS ou Microsoft Azure;
- Um dispositivo de VPN local ou serviço de VPN
Para uma interface de gateway de VPN de alta disponibilidade que se conecta a um gateway de VPN externo, o endereço IP de peering remoto é o endereço IP da interface no gateway de VPN externo usado para o túnel.
Para uma interface de gateway de VPN de alta disponibilidade que se conecta a outro gateway de VPN de alta disponibilidade, o endereço IP de peering remoto é o endereço IP da outra interface do gateway de VPN de alta disponibilidade usada para o túnel.
Para a VPN clássica, o endereço IP de peering remoto é o endereço IP externo do gateway da VPN de peering.
vpnGateway em uma extremidade e por um
externalVpnGateway ou outro recurso VpnGateway do Google Cloud no final do peering. Uma conexão
também inclui todos os recursos do vpnTunnel e sessões do BGP
entre os recursos do gateway.
Termos do Cloud Interconnect
A terminologia da chave a seguir descreve os conceitos relacionados à criação do Cloud Interconnect. Cada seção indica se um termo se aplica à Interconexão dedicada, Interconexão por parceiro, Cross-Cloud Interconnect ou uma combinação deles.
Elementos do Cloud Interconnect
Aplicável à Interconexão dedicada e ao Cloud Interconnect.
Para Interconexão dedicada
Uma conexão física específica entre o Google e sua rede local. Essa conexão existe em uma instalação de colocation em que sua rede local e a rede do Google se conectam.
Uma única conexão pode ser um link de 10 Gbps, um link de 100 Gbps ou um pacote de links. Se você tiver várias conexões com o Google em locais ou com dispositivos diferentes, será necessário criar conexões separadas do Interconnect.
Para Cross-Cloud Interconnect
Uma conexão física específica entre o Google e a rede de outro provedor de serviços de nuvem (o provedor de serviços de nuvem remoto). Essa conexão existe em uma única instalação de colocation ou em instalações adjacentes, nas quais as redes do Google e do provedor de serviços de nuvem remota se encontram.
Uma única conexão pode ser um link de 10 Gbps, um link de 100 Gbps ou, dependendo do que o provedor de nuvem remoto suporta, um pacote de links.
- Interconexão dedicada
- Interconexão por parceiro
- Interconexão entre nuvens
Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.
Um anexo da VLAN (rede de área virtual) é uma conexão lógica entre uma rede externa e uma única região na sua rede de nuvem privada virtual (VPC). Na API Compute Engine, o anexo da VLAN é conhecido como um recurso interconnectAttachment.
Ao criar um anexo da VLAN, você o associa a um projeto, uma região, um Cloud Router novo ou atual e a uma conexão existente do Cloud Interconnect. Em seguida, configure uma sessão do Border Gateway Protocol (BGP) entre o Cloud Router e seu roteador externo.
- Na Interconexão dedicada, o anexo da VLAN usa uma conexão dedicada que você cria para o roteador local.
- Na Interconexão por parceiro, o anexo usa uma conexão que o parceiro escolhido configura e gerencia.
- No Cross-Cloud Interconnect, o anexo usa uma conexão que o Google cria em seu nome entre as redes do Google Cloud e seu provedor de serviços de nuvem remoto.
Um anexo da VLAN não está diretamente associado a uma rede VPC. No entanto, ele está indiretamente vinculado a uma única rede VPC, porque um Cloud Router pode ser associado a apenas uma rede. Portanto, o anexo da VLAN está vinculado à rede em que o Cloud Router está localizado.
Para Interconexão dedicada
Um anexo da VLAN para a Interconexão dedicada aloca uma única VLAN 802.1Q na conexão da Interconexão dedicada e a conecta a uma rede VPC específica. Como cada conexão com a Interconexão dedicada é compatível com vários anexos da VLAN. Além disso, é possível acessar várias redes VPC sem criar várias conexões.
Cada anexo criado é associado a uma rede VPC e a uma região do Google Cloud:
- Ao associar um anexo para a Interconexão dedicada com uma rede VPC, essa rede precisa estar em um projeto na mesma organização do projeto que contém a conexão do Interconnect.
- O conjunto de regiões válidas para um anexo depende da instalação de colocation usada pela conexão do Cloud Interconnect.
É possível definir a capacidade de cada anexo. Para uma lista de capacidades, consulte a página Preços. A capacidade de anexos padrão é de 10 Gbps.
A configuração de capacidade limita a largura de banda máxima que um anexo pode usar. Se você tiver vários anexos em uma única conexão do Interconnect, o limite de capacidade será útil quando você quiser evitar o congestionamento de rede na conexão. A largura de banda máxima é aproximada, por isso, é possível que um anexo use um valor maior do que a capacidade selecionada.
Como a configuração de capacidade limita apenas a largura de banda de saída do Google Cloud para a instalação de colocation da conexão do Interconnect, recomendamos que você configure um limitador de taxa de saída no roteador para sua conexão. Ao configurar esse limitador, é possível restringir a largura de banda máxima de entrada do tráfego que usa essa conexão na sua rede VPC.
Para Partner Interconnect
Para solicitar a conectividade da Interconexão por parceiro de um provedor de serviços, crie um anexo da VLAN no seu projeto do Google Cloud. O anexo da VLAN gera uma chave de pareamento exclusiva que você compartilha com o provedor de serviços. O provedor usa a chave de pareamento, a capacidade e o local de conexão solicitados para concluir a configuração do anexo da VLAN.
Depois que o provedor de serviços configurar o anexo, ele alocará uma VLAN 802.1q específica na conexão local.
Para Cross-Cloud Interconnect
Um anexo da VLAN para o Cross-Cloud Interconnect aloca uma única VLAN 802.1Q na conexão do Cloud Interconnect. O anexo da VLAN e o Cloud Router associado vinculam sua conexão a uma rede VPC específica. Como cada conexão do Cloud Interconnect é compatível com vários anexos da VLAN, é possível acessar várias redes VPC sem criar várias conexões.
Os seguintes requisitos são aplicáveis:
- Ao associar um Cloud Router ao anexo da VLAN, você associa o anexo a uma rede VPC. Essa rede precisa estar no mesmo projeto que a conexão do Cloud Interconnect.
- O conjunto de regiões válidas para um anexo depende dos locais compatíveis com o Google Cloud e do seu provedor de serviços de nuvem remoto.
Você pode selecionar uma capacidade para cada anexo. Para uma lista de capacidades, consulte a página Preços. A capacidade padrão é de 10 Gbps. Essa configuração afeta a largura de banda máxima que o anexo pode usar. Se você tiver vários anexos da VLAN, recomendamos definir uma capacidade para cada um deles. Isso pode impedir que qualquer anexo tente usar toda a largura de banda da conexão, o que pode fazer com que os pacotes sejam descartados. A largura de banda máxima é aproximada, por isso, é possível que um anexo use um valor maior do que a capacidade selecionada.
A configuração de capacidade limita apenas a largura de banda de saída do Google Cloud para a instalação de colocation da conexão do Cloud Interconnect. Por esse motivo, recomendamos que você configure um limitador de taxa de saída no roteador virtual na nuvem remota. Ao configurar esse limitador, é possível restringir a largura de banda máxima de entrada do tráfego que usa essa conexão na sua rede VPC.
Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.
O Cloud Router usa o Border Gateway Protocol (BGP) para trocar rotas dinamicamente entre a rede VPC e a rede local. Antes de criar um anexo da VLAN, você precisa criar ou usar um Cloud Router atual na rede VPC à qual quer se conectar. Em seguida, use o Cloud Router para configurar uma sessão do BGP com seu roteador externo.
Se você quiser ver mais informações sobre o Cloud Router, consulte a este link.
A configuração do BGP do Cloud Router varia se você estiver usando a conectividade da camada 2 ou 3. A Interconexão dedicada e o Cloud Interconnect usam apenas a conectividade da camada 2. A interconexão por parceiro pode usar conectividade de camada 2 ou camada 3.
- Na camada 2, você estabelece uma sessão do BGP entre o Cloud Router e o roteador externo.
- Na camada 3, o provedor de serviços estabelece uma sessão do BGP entre o Cloud Router e o respectivo roteador de extremidade. Para saber mais, consulte Conectividade da camadas 2 comparada à camada 3.
O Cloud Router anuncia sub-redes na rede VPC e propaga as rotas aprendidas para elas. A menos que você configure uma divulgação de rota personalizada, o Cloud Router anunciará as seguintes rotas:
- Se a rede VPC usar o modo de roteamento dinâmico regional, o Cloud Router divulgará rotas de sub-rede na região em que estiver localizado.
- Caso sua rede VPC use o modo de roteamento dinâmico global, o Cloud Router divulgará rotas de sub-rede em todas as regiões.
O Cloud Router também cria rotas dinâmicas na sua rede VPC para destinos que ele aprende com o roteador externo. Se a rede VPC usar o modo de roteamento dinâmico regional, o Cloud Router disponibilizará essas rotas apenas para a região em que ele está localizado. Se a rede usa o modo de roteamento dinâmico global, o Cloud Router disponibiliza essas rotas para todas as regiões.
Aplicável à Interconexão dedicada e à Interconexão por parceiro.
O roteador local é um roteador externo que estabelece uma sessão do BGP com o Cloud Router. Essa conexão permite trocar dados entre a rede local e a rede VPC.
Na Interconexão dedicada, você gerencia o roteador local, que geralmente está localizado fisicamente na instalação de colocation em que a conexão da Interconexão é provisionada. No entanto, o dispositivo pode estar fisicamente localizado em outra instalação, como um escritório onde você gerencia equipamentos de rede. Você estabelece as sessões do BGP entre seu roteador local e o Cloud Router.
Na Interconexão por parceiro, um roteador local é um dispositivo que você ou o provedor de serviços usa para configurar sessões BGP com o Cloud Router.
- Com as conexões da Interconexão por parceiro da camada 2, você configura a sessão do BGP entre seu roteador local e o Cloud Router.
- Com as conexões da Interconexão por parceiro de camada 3, seu provedor de serviços gerencia a sessão do BGP entre o roteador local e o Cloud Router dele.
Para mais informações sobre diferentes conexões de parceiros, consulte Conectividade das camadas 2 e 3.
Para informações sobre a configuração de roteadores locais, consulte os seguintes documentos:
Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.
Um roteador externo é um dispositivo de rede que fornece acesso à rede com que você quer fazer peering. O roteador externo pode ser um dos seguintes:
- um roteador local
- um roteador virtual hospedado pelo seu provedor de serviços de nuvem remota;
Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.
A versão legada da infraestrutura do Cloud Interconnect. O Dataplane v1 está sendo substituído pelo Dataplane v2. No entanto, enquanto a migração ocorre, alguns anexos da VLAN ainda podem funcionar no Dataplane v1.
Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.
O Cloud Interconnect Dataplane v2 é uma nova implementação da infraestrutura do Cloud Interconnect. Ele foi projetado para fornecer maior confiabilidade, desempenho e funcionalidade.
Alguns recursos de rede do Google Cloud que funcionam com o Cloud Interconnect, como a Detecção de encaminhamento bidirecional (BFD, na sigla em inglês) para o Cloud Router, exigem que os anexos da VLAN usados com o recurso sejam executados no Dataplane v2.
O Google está migrando todos os anexos da VLAN atuais para usar o Dataplane v2, sem nenhuma ação necessária da sua parte. Se você quiser usar um recurso do produto que exija o Dataplane v2 e precise atualizar a versão de um anexo da VLAN atual, entre em contato com o suporte do Google Cloud.
Todos os novos anexos da VLAN que você cria nas regiões disponíveis para o Cloud Interconnect são provisionados automaticamente no Dataplane v2.
Para ver as regiões disponíveis para o Cloud Interconnect, consulte a tabela de locais da Interconexão dedicada ou veja a lista de provedores de serviços da Interconexão por parceiro.
Para verificar a versão do Dataplane de um anexo da VLAN atual, consulte um dos seguintes documentos:
Locais do Cloud Interconnect
Aplica-se ao Dedicated Interconnect, com observações para o Partner Interconnect e Cross-Cloud Interconnect.
A instalação de colocation em que uma conexão do Cloud Interconnect física é provisionada. Esse é o local em que os aparelhos locais de roteamento se conectam à extremidade de peering do Google.
Uma instalação de colocation é onde o Google tem um ponto de presença (PoP, na sigla em inglês) que permite conectar sua rede local à rede do Google. Na instalação de colocation, você precisa trabalhar com o provedor da instalação para provisionar os aparelhos de roteamento antes de usar a Interconexão dedicada.
Cada local de conexão é compatível com um subconjunto de regiões do Google Cloud.
Por exemplo, lga-zone1-16 é compatível com anexos da VLAN nas regiões
northamerica-northeast1, northamerica-northeast2, us-central1,
us-east1, us-east4, us-east5, us-south1, us-west1, us-west2, us-west3 e us-west4.
Para ver uma lista de todos os locais e as regiões compatíveis, consulte Todas as instalações de colocation.
Ao usar a Interconexão por parceiro, os parceiros já configuraram conexões com a rede do Google. O conjunto de locais varia de acordo com o parceiro que você escolher. Ao configurar seu anexo da VLAN, é possível selecionar com base nos locais disponíveis do parceiro. Para ver uma lista de locais compatíveis com cada provedor de serviços, consulte a página de provedores de serviços.
Ao usar o Cloud Interconnect, é preciso escolher um local compatível com seu provedor de serviços de nuvem remota:
- Locais do Amazon Web Services
- Locais do Microsoft Azure
- Locais da infraestrutura em nuvem do Oracle
- Locais do Alibaba Cloud
Cada local do parceiro é compatível com um subconjunto de regiões do Google Cloud. É nessas regiões compatíveis que você se conecta aos roteadores do Cloud Router e anexos da VLAN associados.
Por exemplo, se você escolher o local Ashburn, será possível se conectar a todas as
regiões da América do Norte, como us-east1 e us-west1.
Para ver uma lista de regiões do Google Cloud, consulte a página
Regiões e zonas.
Aplicável à Interconexão por parceiro.
Um provedor de serviços de rede para a Interconexão por parceiro. Para usar a Interconexão por parceiro, você precisa se conectar a um provedor de serviços autorizado. Ele fornece conectividade entre sua rede local e a rede VPC.
Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.
A cidade onde uma instalação de colocation está localizada.
A área metropolitana escolhida depende da localização da rede local e das instâncias de VM do Compute Engine (a região delas no Google Cloud). Normalmente, é melhor escolher uma área metropolitana geograficamente próxima à sua rede local para reduzir a latência. Ao configurar uma conexão redundante, é possível escolher outrqa área metropolitana mais distante.
Cada área metropolitana oferece suporte a um subconjunto de regiões do Google Cloud. Só
é possível criar anexos da VLAN nessas regiões. Por exemplo,
se você escolher uma instalação em Ashburn, só será possível criar anexos da VLAN
nas regiões da América do Norte. Supondo que suas instâncias de VM também estejam localizadas nessas
regiões, crie anexos de VLAN nas mesmas regiões que suas VMs para reduzir a latência e os
custos de saída. Caso contrário, o tráfego teria que viajar entre regiões para acessar as
instâncias de VM ou a rede local.
Para saber mais sobre a Interconexão dedicada, consulte Todas as instalações de colocation.
Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.
Termo mais antigo para domínio de disponibilidade de extremidade.
Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.
Cada área metropolitana tem dois domínios de falha independentes chamados
domínios de disponibilidade de borda. Os dois domínios de disponibilidade de borda são chamados zone1 e zone2. Eles oferecem isolamento durante a manutenção
programada, o que significa que dois domínios na mesma área metropolitana não estão desativados para
manutenção ao mesmo tempo. Esse isolamento é importante quando você quer aumentar a redundância.
Os domínios de disponibilidade de borda abrangem uma área metropolitana inteira e não cruzam áreas metropolitanas. Para manter
a disponibilidade e um SLA, é necessário criar conexões
duplicadas do Cloud Interconnect escolhendo dois locais de conexão na
mesma área metropolitana que estejam em diferentes domínios de disponibilidade de borda. Algumas áreas metropolitanas oferecem mais de dois locais, mas ainda há apenas dois domínios de disponibilidade de borda na área metropolitana. Por exemplo, a criação de conexões nos locais dfw-zone1-4 e dfw-zone1-505 não oferece redundância porque os dois locais estão no domínio de disponibilidade de borda zone1. Criá-los em dfw-zone1-4 e dfw-zone2-4
proporciona redundância porque os locais estão em domínios de disponibilidade de borda diferentes.
As janelas de manutenção não são coordenadas entre áreas metropolitanas. Por exemplo, os domínios
de disponibilidade de borda dfw-zone1-4 e ord-zone1-7
podem enfrentar eventos de manutenção sobrepostos. Ao se conectar a várias áreas metropolitanas por questões de
redundância, é importante se conectar a diferentes domínios de disponibilidade de extremidade
em cada uma dessas áreas, como descrito na
topologia de produção.
Provisionamento e configuração
Aplicável à Interconexão dedicada.
Uma LOA-CFA identifica as portas que o Google atribuiu à conexão de Interconexão dedicada e concede permissão para um fornecedor em uma instalação de colocation se conectar a ele. Os documentos LOA-CFA são necessários ao solicitar conexões de Interconexão dedicada em uma instalação de colocation.
Quando você solicita conexões de Interconexão dedicada, o Google aloca recursos
para suas conexões e, em seguida, gera um documento LOA-CFA para cada uma. A LOA-CFA
lista os pontos de demarcação que o Google alocou para suas conexões.
Envie esse formulário ao fornecedor da instalação para provisionar conexões entre seu equipamento
e o do Google. Depois que o status de uma conexão for alterado
para PROVISIONED, a LOA-CFA não será mais válida, necessária ou estará disponível
no Console do Google Cloud.
Para saber mais sobre o fluxo de provisionamento, consulte a Visão geral de provisionamento da Interconexão dedicada.
Aplicável à Interconexão por parceiro.
Um identificador exclusivo que permite aos provedores de serviços identificarem determinados anexos da VLAN sem que ninguém compartilhe informações potencialmente confidenciais sobre a rede VPC ou o projeto do Google Cloud. As chaves de pareamento são usadas apenas com o Partner Interconnect.
Trate a chave de pareamento como informação confidencial até que o anexo da VLAN esteja configurado. Se for descoberta, é possível que terceiros a usem para se conectar à sua rede. A chave é usada apenas uma vez e não pode ser modificada. Se você precisar de uma nova chave de pareamento, exclua o anexo da VLAN e crie um novo.
O pareamento de chaves usa o seguinte formato:
<random>/<vlan-attachment-region>/<edge-availability-domain>.
Por exemplo, 7e51371e-72a3-40b5-b844-2e3efefaee59/us-central1/2 é
uma chave de pareamento para um anexo da VLAN na região us-central1
e domínio de disponibilidade de borda 2.
Aplicável ao Cross-Cloud Interconnect.
Outro provedor de serviços em nuvem, além do Google Cloud, em que você pode ter recursos de rede.
Termos do Border Gateway Protocol (BGP)
A terminologia a seguir se aplica ao Border Gateway Protocol (BGP), que o Cloud VPN e o Cloud Interconnect usam para roteamento dinâmico.