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 ou ambos.
Elementos do Cloud Interconnect
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.
Também conhecido como um anexo de interconexão ou recurso interconnectAttachment
na API Compute Engine, um anexo da VLAN (rede de área virtual)
é uma conexão lógica entre sua rede local e uma única região na
sua rede de nuvem privada virtual (VPC).
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 Interconnect. Em seguida o Cloud Router estabelece uma sessão do protocolo de gateway de borda (BGP, na sigla em inglês) pelo anexo no seu roteador local.
- 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.
Um anexo da VLAN usado com a Interconexão dedicada ou a Interconexão por parceiro não está diretamente associado a uma rede VPC, mas está indiretamente vinculado a uma única rede, porque um Cloud Router só pode ser associado a uma única rede VPC. 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.
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, associe o anexo a esse Cloud Router. O Cloud Router cria uma sessão do BGP que se conecta ao roteador local (de peering) de mesmo nível.
Para informações detalhadas sobre o Cloud Router, consulte a visão geral.
A configuração do BGP do Cloud Router varia se você estiver usando a conectividade da camada 2 ou 3. A interconexão dedicada usa 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 local.
- 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 personalizadas na sua rede VPC para destinos que ele aprende com o roteador local de mesmo nível. Dependendo do modo de roteamento dinâmico da rede VPC (regional ou global), o Cloud Router disponibiliza essas rotas apenas para a região do Cloud Router ou para todas as regiões.
O roteador local é o dispositivo de rede que estabelece uma sessão do BGP com o Cloud Router. Essa conexão permite a troca de 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 com que você ou o provedor de serviços configura sessões do 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:
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.
Muitas regiões já aceitam a criação de alguns anexos da VLAN no Dataplane v2. No entanto, você pode ver quais regiões aceitam a criação detodos os novos anexos da VLAN no Dataplane v2 visualizando a tabela de locais ou a lista de provedores de serviços. Para garantir que os novos anexos da VLAN usem o Dataplane v2, crie os anexos em uma região ativada pelo Dataplane v2 atendida pelo seu local ou provedor de serviços.
Para verificar a versão do plano de dados de um anexo da VLAN atual, consulte Visualizar anexos da VLAN (dedicada) ou Visualizar anexos da VLAN (parceiro).
Locais do Cloud Interconnect
A instalação de colocation em que uma conexão do 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 interconexã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 Como escolher locais de instalação 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 Provedores de serviços.
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.
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.
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 mais informações, consulte Como escolher locais de instalação de colocation.
Termo mais antigo para domínio de disponibilidade de extremidade.
Cada área metropolitana tem pelo menos duas zonas chamadas de domínios de disponibilidade da extremidade. 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 única zona metropolitana. Para manter a
disponibilidade e um SLA,
é preciso criar conexões do Interconnect duplicadas em diferentes domínios de disponibilidade de
extremidade na mesma área metropolitana. Por exemplo, criar conexões em dfw-zone1-4 e
dfw-zone2-4 fornece redundância em domínios de disponibilidade de extremidade diferentes, ao
criá-las em dfw-zone1-4 e dfw-zone1-505
não no mesmo domínio de disponibilidade de extremidade.
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
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.
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.
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.