A funcionalidade de transferência de dados de site a site permite-lhe ligar os seus sites externos através da rede Google. Neste contexto, um site externo é qualquer rede que mantém fora do Google Cloud. Por exemplo, um site externo pode ser a sua rede nas instalações ou a sua rede noutro fornecedor de serviços na nuvem.
A transferência de dados entre sites só é suportada em determinadas localizações. No entanto, pode ter de manter um recurso de conetividade numa região não suportada para a transferência de dados entre sites. Se tiver este tipo de topologia de rede e quiser fazer uma transferência de dados de site para site, use a configuração descrita nesta página. Caso contrário, a conetividade entre sites pode falhar.
A transferência de dados de site a site faz parte do Network Connectivity Center, que lhe permite gerir a sua rede através de uma arquitetura de hub e raios. Para usar a transferência de dados de site a site, estabelece conetividade a cada rede externa através de um recurso de conetividade suportado. Posteriormente, associa cada recurso de conetividade a um spoke do Network Connectivity Center, que está anexado a um hub do Network Connectivity Center. Em seguida, o Network Connectivity Center estabelece uma ligação de malha completa entre todos os sites externos associados aos seus raios.
Topologia de exemplo
Neste exemplo, uma organização usa a transferência de dados de site a site para ligar duas redes no local:
Rede A, na Índia
Network B, na Austrália
Estas redes estabelecem ligação a Google Cloud através de anexos de VLAN do Dedicated Interconnect e túneis do Cloud VPN (VPN de alta disponibilidade). Estes recursos estão localizados em duas regiões suportadas para a transferência de dados de site a site: asia-south1
e australia-southeast1
. Ambas as associações de VLAN estão associadas a raios do Network Connectivity Center que têm a funcionalidade de transferência de dados site a site ativada.
Esta topologia também coloca máquinas virtuais (VM) do Compute Engine em australia-southeast1
. Estas VMs executam serviços que são acedidos regularmente por sistemas no local localizados na rede A.
No entanto, esta topologia foi concebida para que os recursos do Dedicated Interconnect tenham uma disponibilidade de 99,99%. Para ter uma disponibilidade de 99,99%, tem de usar dois pares de ligações de interligação dedicada em duas regiões. Cada conexão tem de ter a sua própria associação de VLAN.
Para cumprir este requisito, a topologia de exemplo coloca um par redundante de anexos de VLAN numa região hipotética não suportada (region-unsupported1
). A rede A está equidistante entre asia-south1
e region-unsupported1
. No entanto, a região não suportada está mais perto de
australia-southeast1
do que de asia-south1
.
Esta configuração representa um problema potencial para a transferência de dados de site para site. Uma vez que region-unsupported1
está mais perto de australia-southeast1
, o Cloud Router em australia-southeast1
vê o recurso em region-unsupported1
como o caminho ideal para a rede A. No entanto, uma vez que este caminho não está associado ao Network Connectivity Center, o Cloud Router não volta a anunciar os prefixos da rede A à rede B.
Opções de configuração
No cenário de exemplo, pode controlar como o tráfego é encaminhado configurando o router externo para a rede A. Use uma das opções descritas nas secções seguintes.
Ambas as opções envolvem a utilização do MED. Para obter ajuda na compreensão de como o Cloud Router usa o MED, consulte as Orientações para prioridades base.
Opção 1: otimize para a transferência de dados de site para site
Se a transferência de dados de site para site for fundamental, force todo o tráfego a dar preferência aos recursos associados aos raios do Network Connectivity Center. Pode afetar este comportamento usando valores MED diferentes para asia-south1
e region-unsupported1
.
Por exemplo, configure o router para a rede no local A para anunciar
10.1/16
através do seguinte:
- Uma MED de
100
aasia-south1
- Uma MED de
20000
aregion-unsupported1
Neste caso, o router na nuvem em australia-southeast1
vê o
anúncio proveniente de asia-south1
como o melhor caminho. Também anuncia novamente
10.1/16
à rede no local B.
A vantagem desta abordagem é que lhe permite usar a transferência de dados de site para site de forma consistente. A desvantagem é que aumenta a latência para os sistemas da rede A que precisam de aceder às VMs em australia-southeast1
.
Opção 2: otimize para o tráfego do site para a nuvem
Se a transferência de dados de site para site não for fundamental, force todo o tráfego a dar
preferência a region-unsupported1
. Pode efetuar este comportamento usando os mesmos valores MED para asia-south1
e region-unsupported1
.
Por exemplo, configure o router para a rede no local A para anunciar
10.1/16
através do seguinte:
- Uma MED de
100
aasia-south1
- Uma MED de
100
aregion-unsupported1
Neste cenário, o Cloud Router em australia-southeast1
vê o anúncio proveniente de region-unsupported1
como o melhor caminho porque está geograficamente mais próximo do que asia-south1
.
Uma vez que este caminho não está associado ao Network Connectivity Center, o Cloud Router não volta a anunciar 10.1/16
à rede no local B.
A vantagem desta abordagem é que, para os sistemas na rede A que precisam de aceder a VMs em australia-southeast1
, é dada preferência à rota com menor latência. A desvantagem desta abordagem é que faz com que a transferência de dados entre sites falhe.
O que se segue?
- Para saber como o Network Connectivity Center permite a conetividade de malha completa entre sites externos, consulte o artigo Troca de rotas com transferência de dados site a site.
- Para ver uma topologia de exemplo, consulte o artigo Topologia de exemplo para a transferência de dados de site a site.
- Para saber mais acerca dos requisitos de elevada disponibilidade, consulte o artigo Requisitos de elevada disponibilidade para recursos spoke.
- Para criar centros e nós, consulte o artigo Trabalhe com centros e nós.