Este documento ajuda os arquitetos de nuvem e os profissionais de operações a decidir como se ligar Google Cloud a outros fornecedores de serviços na nuvem (CSP), como os serviços Web da Amazon (AWS) e o Microsoft Azure. Num design de várias nuvens, as ligações entre os CSPs permitem transferências de dados entre as suas redes virtuais. Este documento também fornece informações sobre como implementar a opção que escolher.
Muitas organizações operam em várias plataformas de nuvem, quer como medida temporária durante uma migração ou porque a organização tem uma estratégia de várias nuvens a longo prazo.
Para a troca de dados entre o Google Cloud e outros PSCs, existem várias opções abordadas neste documento:
- Transferência de dados através de endereços IP públicos pela Internet.
- Usar um serviço de VPN gerido entre Google Cloud e o outro FSN.
- Usar o Partner Interconnect na Google Cloud para estabelecer ligação a um parceiro que possa estabelecer ligação diretamente com o outro PSC.
- Usar a Interligação dedicada na Google Cloud para transferir dados para o outro FSN através de um ponto de presença (PoP) comum.
- Usar o Cross-Cloud Interconnect no Google Cloud para uma ligação gerida a outro CSP.
Estas opções diferem em termos de velocidade de transferência, latência, fiabilidade, contratos de nível de serviço (SLAs), complexidade e custos. Este documento descreve detalhadamente cada opção, bem como as respetivas vantagens e desvantagens, e termina com uma comparação de todas as opções.
Este documento aborda as transferências de dados entre máquinas virtuais residentes no Google Cloud e noutras redes virtuais de CSPs. Para dados armazenados noutros Google Cloud produtos, como o Cloud Storage e o BigQuery, consulte a secção que aborda estes produtos.
Este documento pode servir de guia para avaliar as opções de transferência de dados entre Google Cloud e um ou mais outros PSCs, com base nos seus requisitos e capacidades.
Os conceitos neste documento aplicam-se em vários casos:
- Quando planeia transferir grandes quantidades de dados durante um curto período de tempo, por exemplo, para um projeto de migração de dados.
- Se executar transferências de dados contínuas entre vários fornecedores de nuvem, por exemplo, porque as suas cargas de trabalho de computação são executadas noutro CSP enquanto as suas cargas de trabalho de Big Data usam o Google Cloud.
Considerações iniciais
Antes de escolher como associar os seus ambientes na nuvem, é importante que veja as regiões que escolhe em cada ambiente e que tenha uma estratégia para transferir dados que não residam em ambientes de rede virtuais.
Escolha regiões da nuvem
Se os recursos do Google Cloud e de outros FSCs estiverem em regiões geograficamente próximas entre si, existe uma vantagem em termos de custos e latência para as transferências de dados entre fornecedores de nuvem.
O diagrama seguinte ilustra o fluxo de dados entre Google Cloud
e outros CSPs.
Independentemente do método de transferência, os dados fluem de Google Cloud para o outro PSC da seguinte forma:
- Da Google Cloud região onde os recursos estão alojados para o PoP de limite da Google.
- Através de uma instalação de terceiros entre Google Cloud e o outro CSP.
- Do PoP de limite do outro CSP para a região onde os recursos estão localizados na rede do outro CSP.
Os dados que fluem do outro PSC para Google Cloud percorrem o mesmo caminho, mas na direção oposta.
O caminho ponto a ponto determina a latência da transferência de dados. Para algumas soluções, os custos de rede também aumentam quando os PoPs de limite de ambos os fornecedores não estão numa área metropolitana. Os detalhes estão indicados na secção de preços seguinte de cada solução.
Certifique-se de que escolhe regiões adequadas em cada nuvem que possam alojar as cargas de trabalho pretendidas. Visite a página Localizações para Google Cloud e páginas semelhantes para outros FSCs, como a tabela de regiões da AWS ou produtos Azure por região. Para obter ajuda geral na seleção de uma ou várias localizações, Google Cloud, reveja as práticas recomendadas para a seleção de regiões do Compute Engine.
Transferência de dados no Cloud Storage e no BigQuery
Por predefinição, apenas os dados que residem num ambiente de VPC passam por um túnel do Cloud VPN ou uma ligação do Cloud Interconnect. Google Cloud
Se quiser transferir dados de e para outros serviços Google, pode usar o Private Service Connect e o acesso privado à Google para anfitriões no local a partir do ambiente do outro FSC.
Se quiser transferir o armazenamento de objetos, a base de dados, o data warehouse ou outros produtos de outro FSP, consulte a respetiva documentação para ver se os dados podem passar pelo produto de VPN gerido ou de interligação. Caso contrário, pode conseguir transmitir estes dados através de máquinas virtuais de proxy que configurar no ambiente do CSP respetivo para que sejam transmitidos através da ligação pretendida.
Para transferir dados para o Cloud Storage ou o BigQuery, também pode usar o Serviço de transferência de armazenamento ou o Serviço de transferência do BigQuery.
Transferência através de endereços IP externos pela Internet
A forma mais fácil de transferir dados entre Google Cloud e outro CSP é usar a Internet e transferir os dados através de endereços IP externos.
O diagrama seguinte ilustra os elementos desta solução.
Entre o limite da rede da Google e o limite da rede do outro FSP, os dados passam pela Internet ou usam uma interligação direta entre Google Cloud e o outro FSP. Os dados só podem passar entre recursos aos quais foram atribuídos endereços IP públicos.
Como a Google se liga a outras redes
Os PoPs de limite da Google são onde a rede da Google se liga a outras redes que, em conjunto, formam a Internet. A Google está presente em várias localizações em todo o mundo.
Na Internet, é atribuído a cada rede um número de sistema autónomo (ASN) que abrange a infraestrutura de rede interna e as rotas da rede. O ASN principal da Google é 15169.
Existem duas formas principais de uma rede enviar ou receber tráfego para ou do Google:
- Compre um serviço de Internet a um fornecedor de serviços de Internet (ISP) que já tenha conetividade com a Google (AS15169). Esta opção é geralmente designada por trânsito de IP e é semelhante ao que os consumidores e as empresas compram aos fornecedores de acesso nas suas casas e empresas.
- Associar diretamente ao Google (AS15169). Esta opção, denominada intercâmbio, permite que uma rede envie e receba diretamente tráfego para a Google (AS15169) sem usar uma rede de terceiros. Geralmente, a troca de tráfego é preferível ao trânsito porque os operadores de rede têm mais controlo sobre como e onde o tráfego é trocado, o que permite a otimização do desempenho e do custo. O peering é um sistema voluntário. Quando optam pelo peering, os operadores de rede decidem em conjunto a que instalações estabelecer ligação, a largura de banda a disponibilizar, como dividir os custos de infraestrutura e quaisquer outros detalhes necessários para configurar as ligações. O AS15169 tem uma política de peering aberta, o que significa que, desde que uma rede cumpra os requisitos técnicos, a Google estabelece peering com a mesma.
O peering é um contrato privado e mutuamente benéfico entre duas redes independentes e, como tal, as redes geralmente não divulgam publicamente com quem fazem peering em localizações específicas, a largura de banda disponível, etc. No entanto, devido à escala e a uma política aberta, a Google tem peering direto com quase todos os principais ISPs e fornecedores de serviços na nuvem em várias localizações e regiões. A equipa de rede da Google trabalha diretamente com os seus homólogos nestas redes para fornecer capacidade de intercâmbio suficiente para satisfazer a procura.
Pode ler mais sobre o funcionamento da interligação da Internet no artigo O manual de interligação da Internet.
Implementação
Nesta configuração, todas as máquinas virtuais que transferem dados entre oGoogle Cloud e outros fornecedores de serviços na nuvem têm de ter um endereço IP público. Por um lado, a firewall tem de ser aberta para permitir uma ligação a partir do endereço IP público do outro fornecedor de nuvem. Não são necessários passos adicionais porque a troca de dados ocorre através da conetividade à Internet existente.
Velocidade de transferência e latência
Embora não exista uma velocidade nem uma latência garantidas no caminho através da Internet, normalmente, os principais CSPs e a Google trocam dados diretamente em várias localizações em todo o mundo. A capacidade é partilhada com outros clientes e serviços, mas, muitas vezes devido à ligação direta entre ambos os fornecedores, a latência é semelhante ou inferior à de outras opções.
Recomendamos que teste a latência e a largura de banda entre Google Cloud e os outros PSCs nas regiões escolhidas. Pode fazer uma referência rápida usando ferramentas como iperf ou netperf, ou executar uma referência personalizada mais completa com base na sua app. Embora as condições possam mudar ao longo do tempo, a referência pode dar uma indicação do desempenho que pode esperar e se esta solução satisfaz as suas necessidades. Se precisar de uma largura de banda dedicada entre ambos os ambientes, deve escolher outra solução.
Tenha em atenção que os produtos de diferentes fornecedores podem ter características de desempenho que nem sempre se alinham. Por exemplo, a capacidade de VPN IPsec por túnel pode variar de fornecedor para fornecedor.
Segurança
O tráfego através da Internet não é encriptado e pode passar por fornecedores de serviços de Internet (ISPs), sistemas autónomos e instalações de terceiros. Por conseguinte, deve encriptar o tráfego sensível na camada de aplicação ou escolher outra solução.
Fiabilidade e SLA
Google Cloud tem geralmente vários caminhos diversificados para a conetividade à Internet a partir de regiões e existem ligações de peering diretas com outros CSPs importantes em várias localizações em todo o mundo.
No entanto, Google Cloud não fornece SLAs para a conetividade a outros CSPs através da Internet. Embora deva verificar os SLAs dos seus outros CSPs, estes normalmente referem-se apenas à conetividade à Internet como um todo e não a fornecedores específicos.
Os fornecedores podem ter políticas de encaminhamento diferentes que podem afetar a disponibilidade. Por exemplo, na respetiva página do peeringdb, a Amazon explica que muitas regiões da AWS anunciam apenas rotas locais, porque as VPCs da AWS são apenas regionais (Google Cloud as VPCs são globais). Isto significa que os clientes podem estar a confiar em links numa única localização de intercâmbio, uma vez que o tráfego que sai Google Cloud só pode usar esses links para alcançar o destino. Isto não é um problema no funcionamento normal, com o tráfego a ser trocado na região, mas é aconselhável que os clientes criem arquiteturas para implementações multirregionais de modo a tolerar falhas regionais. Isto pode incluir a configuração de gateways e túneis adicionais, interligação de redes virtuais ou outras topologias multirregionais na nuvem de terceiros.
As aplicações também devem ser criadas de forma a "falharem em aberto", conforme recomendado pela Google SRE no livro SRE. Por exemplo, se criar uma aplicação que dependa da capacidade de alcançar um serviço de terceiros através do encaminhamento da Internet, certifique-se de que a aplicação continua a funcionar ou, pelo menos, devolve mensagens de erro úteis ao utilizador em caso de problemas de conetividade.
Quando ocorrem problemas com o encaminhamento da Internet, a equipa de rede da Google tenta restaurar a conetividade com o terceiro. No entanto, nem todos os problemas estão sob o controlo da Google. Assim, em alguns casos, a reparação pode depender da tomada de medidas de recuperação por parte de terceiros (ISP ou fornecedor de nuvem). Os clientes têm a maior influência sobre a forma como os operadores respondem às interrupções, por isso, certifique-se de que tem cobertura de apoio técnico com todos os fornecedores e um plano para encaminhar problemas caso algo corra mal. Também deve realizar testes periódicos de BCP (processo de continuidade do negócio) para garantir a resiliência das aplicações arquitetadas em várias nuvens.
Preços
Para transferências de dados através da Internet, aplicam-se as tarifas de saída da Internet normais para o tráfego que sai Google Cloud. Nos casos em que a latência não é fundamental, a utilização do Nível de serviço de rede padrão oferece um nível de preços inferior.
Os outros PSCs têm os seus próprios encargos para transferências de dados. Em muitos casos, cobram apenas o tráfego que sai da respetiva rede. Consulte a lista de preços do seu PSC. Por exemplo, para a AWS, consulte os custos de transferência de dados do EC2 e, para o Azure, consulte os detalhes dos preços da largura de banda.
VPN gerida entre fornecedores de nuvem
Pode usar serviços de VPN geridos de ambos os fornecedores de nuvem, o que tem duas vantagens. Fornece um canal encriptado entre redes virtuais em ambos os ambientes de nuvem e permite-lhe transferir dados através de endereços IP privados. Esta é uma extensão da solução anterior de transferência através da Internet sem precisar de hardware ou parceiros.
O diagrama seguinte ilustra os elementos desta solução.
Com esta solução, os dados são encriptados Google Cloud através da VPN na nuvem e de uma solução de VPN para o outro PSC. A transferência de dados entre Google Cloud e o outro FSP usa a Internet, tal como na solução anterior.
Implementação
A Google oferece a VPN de alta disponibilidade como um serviço de VPN gerido para túneis IPsec encriptados, que podem ser usados no lado da Google. Outros CSPs oferecem os seus próprios produtos de VPN geridos, que pode usar para criar túneis de VPN IPsec entre ambos os ambientes. Por exemplo, a AWS oferece a VPN site a site da AWS e o Azure oferece o gateway de VPN do Azure. Pode ligar as suas redes virtuais entre os ambientes através de túneis VPN.
Pode ligar-se a outro CSP usando a VPN de alta disponibilidade por si só ou pode configurar a VPN de alta disponibilidade como um raio híbrido do Network Connectivity Center. O Network Connectivity Center permite-lhe ligar localizações nas instalações, redes VPC e outras nuvens através da gestão centralizada.
A VPN de alta disponibilidade não tem funcionalidade de tradução de endereços de rede (NAT) integrada. No entanto, pode ativar o NAT híbrido na ligação.
Com o Cloud Router no modo de encaminhamento dinâmico global, pode alcançar todas as regiões numa rede VPC global usando apenas túneis VPN para essa região. Para outros PSCs, pode precisar de túneis de VPN por região. Se tiver várias redes virtuais num ambiente de nuvem que não estejam em peering, tem de ligar todas as redes virtuais que precisam de comunicar entre si de forma independente através de uma VPN.
Google Cloud oferece guias de interoperabilidade, que têm instruções passo a passo para configurar túneis de VPN para outros principais fornecedores de nuvem:
Velocidade de transferência e latência
Quando usa canais VPN geridos, os dados seguem aproximadamente os mesmos caminhos da Internet que seguiriam sem os canais VPN. A latência observada deve ser semelhante à da opção anterior, com apenas uma pequena sobrecarga de latência para os túneis VPN. A largura de banda disponível é limitada pela largura de banda máxima por túnel de VPN na Google Cloud, pela largura de banda máxima dos túneis do outro FSP e pela largura de banda disponível no caminho da Internet.
Para uma largura de banda superior, pode implementar túneis adicionais. Para mais informações sobre como implementar uma solução deste tipo, consulte Topologias de VPN de HA para aumentar a largura de banda.
Pode testar a latência e a largura de banda conforme descrito na última secção, mas as condições podem variar ao longo do tempo, e não existem garantias sobre a latência ou a largura de banda.
Segurança
O tráfego através de túneis VPN IPsec é encriptado através de cifras aceites por ambos os CSPs. Para mais informações, consulte os seguintes artigos: Cifras IKE suportadas pela VPN na nuvem, Perguntas frequentes sobre a VPN da AWS e Parâmetros IPsec/IKE da VPN do Azure.
Fiabilidade e SLA
A VPN na nuvem oferece um SLA. Outros CSPs oferecem, por vezes, SLAs no respetivo produto de VPN gerido, por exemplo, o SLA de VPN site a site da AWS e o SLA da Azure para o gateway de VPN. No entanto, estes SLAs abrangem apenas a disponibilidade dos gateways de VPN e não incluem a conetividade a outros CSPs através da Internet, pelo que não existe um SLA na solução ponto a ponto.
Para aumentar a fiabilidade, considere usar gateways e túneis de VPN adicionais na Google Google Cloud e nos outros CSPs.
Preços
Para o serviço de VPN gerido, aplicam-se custos. Para Google Cloud, aplica-se uma taxa por hora. Consulte os preços da Cloud VPN. Para outros FSCs, consulte as respetivas listas de preços. Por exemplo, consulte os preços da ligação VPN site a site da AWS ou os preços do Azure VPN Gateway.
Além do preço por hora do serviço de VPN, tem de pagar pelos dados transferidos através dos gateways de VPN. Para Google Cloud e muitos CSPs, aplicam-se os custos de transferência de dados da Internet padrão, conforme detalhado em Transferência através de endereços IP externos pela Internet. Em muitos casos, os custos de transferência de dados excedem o custo fixo desta solução.
Interligação de parceiros com parceiros com várias nuvens ativadas
O Partner Interconnect permite-lhe ligar uma nuvem virtual privada às redes virtuais de outro FSN através da rede de parceiros selecionados que oferecem soluções multinuvem diretas. A ligação é feita através da implementação de uma ou mais instâncias de encaminhamento virtual que se encarregam da configuração do Border Gateway Protocol (BGP) necessária.
O diagrama seguinte mostra uma configuração redundante com duas ligações de interconexão de parceiros.
As rotas são trocadas entre o Cloud Router e o gateway do outro lado do CSP através de uma instância de encaminhamento virtual gerida pelo parceiro que fornece a interconexão. O tráfego flui através da rede de parceiros entreGoogle Cloud e o outro PSC.
Implementação
Esta solução requer a configuração de vários componentes:
- No lado Google Cloud , configura o Partner Interconnect com umfornecedor de serviços de interligação que serve as suas Google Cloud regiões e oferece conetividade multinuvem ao outro CSP.
- No outro PSC, tem de usar o respetivo produto de interconexão para se ligar ao mesmo parceiro. Por exemplo, na AWS, pode usar o Direct Connect e, no Azure, pode usar o ExpressRoute.
- Do lado do parceiro fornecedor de serviços, tem de configurar o equipamento de encaminhamento virtual que fornece as sessões BGP ao Google Cloud e ao outro CSP.
Pode estabelecer ligação através da Partner Interconnect por si só ou configurar a Partner Interconnect como um raio híbrido do Network Connectivity Center. O Network Connectivity Center permite-lhe ligar localizações nas instalações, redes VPC e outras nuvens através da gestão centralizada.
Se o espaço de endereços IP entre ambos os ambientes de CSP se sobrepuser, pode ativar o NAT híbrido na ligação.
Velocidade de transferência e latência
Esta solução oferece capacidade dedicada entre a Google Cloud e outros CSPs. Consoante o parceiro e o outro PSC, a capacidade de anexos disponível pode variar. Do Google Cloud lado do parceiro, o Partner Interconnect está disponível com uma capacidade de anexo entre 50 Mbps e 50 Gbps.
A latência desta solução é a soma do seguinte:
- Latência entre a região na qual os seus recursos estão alojados em Google Cloud e a localização da interligação onde o parceiro se liga a Google Cloud.
- Latência na rede de parceiros para, de e através da instância de encaminhamento virtual em direção ao outro CSP.
- Latência da localização periférica do outro CSP onde a interconexão com o parceiro ocorre na região onde os recursos estão alojados no CSP.
Para a latência mais baixa possível, as localizações periféricas da Google Cloud e do outro CSP devem estar na mesma área metropolitana, juntamente com a instância de encaminhamento virtual. Por exemplo, pode ter uma ligação de baixa latência se as regiões na nuvem do CSP, bem como o PoP de limite e a instância de encaminhamento virtual, estiverem localizados na área de Ashburn, Virginia.
Embora Google Cloud e muitos outros CSPs não ofereçam garantias de latência para o tráfego em direção ao limite da respetiva rede, uma vez que existe um caminho dedicado e capacidade através do parceiro, normalmente, a latência nesta solução é menos variável do que se usar endereços IP externos ou uma solução de VPN.
Segurança
Por predefinição, o tráfego através da Partner Interconnect não é encriptado. Para ajudar a proteger o seu tráfego, pode implementar a VPN de alta disponibilidade através do Cloud Interconnect no lado da ligação. Google Cloud Outros FSCs permitem-lhe usar o respetivo serviço VPN gerido através de uma interconexão. Por exemplo, a VPN site-to-site da AWS pode ser usada através da AWS Direct Interconnect. Em alternativa, também pode usar um dispositivo virtual que encripta o tráfego do lado do outro CSP.
Outra opção é encriptar o seu tráfego na camada de aplicação em vez de usar uma VPN.
Fiabilidade e SLA
Esta solução envolve três contratos de nível de serviço diferentes: um da Google, um do parceiro de interconexão e um do outro CSP.
Quando usa a Interligação de parceiro de forma redundante, a Google oferece SLAs mensais de 99,9% a 99,99% consoante a topologia escolhida. Não existe um SLA numa única ligação de interconexão de parceiros.
Consulte a documentação do outro CSP para ver o SLA do respetivo produto de interconexão, por exemplo, o SLA do AWS Direct Connect ou o SLA do ExpressRoute no Azure.
Consulte a documentação ou os termos do fornecedor de serviços parceiro para o Partner Interconnect relativamente ao respetivo SLA sobre a disponibilidade da conetividade e da instância de encaminhamento virtual. Por exemplo, consulte o contrato de serviços globais da Megaport.
Preços
No lado do Google Cloud , existe uma taxa mensal para cada anexo do Partner Interconnect, consoante a largura de banda. O tráfego que sai através da interconexão de parceiros é cobrado a uma taxa inferior à do tráfego da Internet. Para mais informações, consulte a página de preços do Partner Interconnect.
Consulte a página de preços do outro CSP para o respetivo produto de interconexão, por exemplo, os preços do AWS Direct Connect ou os preços do Azure ExpressRoute. Normalmente, os preços também têm uma cobrança mensal para a interconexão e cobranças de transferência de dados através da interconexão a uma taxa inferior à da Internet.
O parceiro fornece cobranças de serviços de interconexão de acordo com os seus próprios preços, que podem ser encontrados no respetivo Website ou consultando a equipa de vendas para obter um orçamento. Normalmente, se todas as transferências de dados ocorrerem na mesma área metropolitana, as cobranças são muito inferiores às que se aplicam se os dados tiverem de percorrer uma distância maior numa rede de parceiros.
Quando os dados são transferidos regularmente a volumes suficientemente elevados, consoante os preços do outro PSC, esta solução pode, por vezes, oferecer o custo total mais baixo devido às taxas de saída com desconto. Mesmo quando adiciona os custos mensais da interligação para a interligação de parceiros, o outro FSP e o parceiro fornecedor de serviços, a utilização desta solução pode gerar poupanças significativas. Como os preços dos parceiros e de outros PSCs podem mudar sem aviso prévio, faça a sua própria comparação com orçamentos atualizados de todas as partes envolvidas.
Interligação dedicada através de um PoP comum
Ao usar um ou mais dispositivos de encaminhamento físicos numa instalação de interconexão comum entre Google Cloud e o outro CSP, pode ligar ambos os fornecedores de serviços na nuvem usando o Dedicated Interconnect no ladoGoogle Cloud e um produto equivalente no outro CSP. A localização da interconexão não está necessariamente na mesma localização que a região na qual os seus recursos estão localizados.
O diagrama seguinte mostra uma configuração redundante com duas ligações Dedicated Interconnect:
As rotas são trocadas entre o Cloud Router e o gateway do outro lado do CSP através de um router físico que coloca numa instalação de interconexão comum. O tráfego flui através deste router entre Google Cloud e o outro CSP.
Implementação
Esta solução requer que aloje e mantenha dispositivos de encaminhamento físico numa instalação de colocation onde a Google e o CSP ao qual quer estabelecer ligação estão presentes. A partir deste dispositivo de encaminhamento, encomenda duas ligações físicas com a instalação: uma para Google Cloud usar Dedicated Interconnect, e outra para o outro fornecedor de serviços através de um produto equivalente, por exemplo, AWS Direct Connect ou Azure ExpressRoute. No dispositivo de encaminhamento, tem de configurar o BGP para permitir trocas de rotas entre os dois ambientes de nuvem.
Consulte a lista de localizações de instalações de colocation da Google Cloud e do seu outro CSP, por exemplo, as localizações do AWS Direct Connect ou as localizações de peering do Azure ExpressRoute, para identificar localizações adequadas para esta configuração.
Pode estabelecer ligação através da interligação dedicada por si só ou pode configurar a interligação dedicada como um raio híbrido do Network Connectivity Center. O Network Connectivity Center permite-lhe ligar localizações nas instalações, redes VPC e outras nuvens através da gestão centralizada.
Se o espaço de endereços IP entre ambos os ambientes de CSP se sobrepuser, pode ativar o NAT híbrido na ligação.
Esta solução é eficaz se usar a conetividade dedicada para estabelecer também uma ligação ao seu ambiente no local, além da ligação a outro CSP.
Noutros casos, esta solução é complexa porque requer que tenha e mantenha equipamento físico e que tenha um contrato com uma instalação de colocation. Só recomendamos esta solução se, pelo menos, uma das seguintes afirmações for verdadeira:
- Já tem equipamento num local adequado para outro fim e um contrato existente com o local.
- Transfere grandes quantidades de dados regularmente, pelo que esta é uma opção económica, ou tem requisitos de largura de banda que os parceiros não conseguem satisfazer.
Velocidade de transferência e latência
Esta solução oferece capacidade dedicada entre Google Cloud e outro CSP. No Google Cloud lado, a interligação dedicada está disponível através de uma ou várias ligações físicas de 10 ou 100 Gbps.
A latência desta solução é a soma do seguinte:
- Latência entre a região na qual os seus recursos estão alojados em Google Cloud e a localização de interligação onde se interliga com Google Cloud.
- Latência através da instalação e do seu equipamento físico, que é normalmente insignificante quando comparada com qualquer latência devido ao comprimento da fibra.
- Latência da localização da interconexão através da rede do outro CSP para a região onde os recursos estão alojados no CSP.
Embora não sejam oferecidas garantias de latência, esta solução permite normalmente a latência mais baixa e as velocidades de transferência mais elevadas entre o Google Cloud e outros ambientes de nuvem através de endereços IP privados. Google Cloud
Segurança
Por predefinição, o tráfego através da interligação dedicada não é encriptado. Para ajudar a proteger o seu tráfego, pode implementar a VPN de alta disponibilidade através do Cloud Interconnect no lado da ligação. Google Cloud Outros FSCs permitem-lhe usar o respetivo serviço VPN gerido através de uma interconexão. Por exemplo, a VPN site-to-site da AWS pode ser usada através da AWS Direct Interconnect. Em alternativa, também pode usar um dispositivo virtual que encripta o tráfego do lado do outro CSP.
Outra opção é encriptar o seu tráfego na camada de aplicação em vez de usar uma VPN.
Fiabilidade e SLA
Quando usa a Interligação dedicada de forma redundante, a Google oferece SLAs mensais de 99,9% a 99,99% consoante a topologia escolhida. Não existe SLA numa única ligação Dedicated Interconnect.
Para mais informações, consulte a documentação de outros PSCs para o SLA no respetivo produto de interconexão, por exemplo, o SLA do AWS Direct Connect ou o SLA do Azure para o ExpressRoute.
A instalação de colocação ou o fornecedor de hardware do equipamento de encaminhamento físico também podem oferecer SLAs nos respetivos serviços.
Preços
No Google Cloud lado, existe uma taxa mensal para cada porta Dedicated Interconnect, bem como para cada anexo de VLAN que se liga a um ambiente de VPC. O tráfego que sai através da interligação dedicada é cobrado a uma taxa inferior à do tráfego da Internet. Para mais informações, consulte a página de preços do Dedicated Interconnect.
Consulte a página de preços do outro CSP para o respetivo produto de interconexão, por exemplo, os preços do AWS Direct Connect ou os preços do Azure ExpressRoute. Normalmente, os preços também têm uma cobrança mensal para a interconexão e cobranças de transferência de dados através da interconexão a uma taxa inferior à da Internet.
Além disso, tem de ter em conta os encargos dos serviços de instalações de alojamento partilhado que fornecem espaço, energia elétrica e ligações físicas para os ambientes de nuvem, bem como quaisquer custos e contratos de serviços contínuos com o fornecedor para o equipamento de encaminhamento físico. Se a ligação entre ambos os FSCs não puder ocorrer na mesma instalação e precisar de adquirir conetividade entre instalações, os preços podem ser muito mais elevados para estes serviços.
Ligações geridas do Cross-Cloud Interconnect
Pode ligar as suas Google Cloud redes VPC às suas redes virtuais noutro CSP através da estrutura de rede da Google. Em certo sentido, esta configuração funciona como o Partner Interconnect, mas com o SLA da Google a abranger as redes Google e as interconexões propriamente ditas.
O diagrama seguinte mostra uma configuração do Cross-Cloud Interconnect com o número mínimo de ligações.
As rotas são trocadas entre o Cloud Router e o gateway do outro lado do CSP através da infraestrutura de rede da Google. O tráfego flui através desta estrutura entre Google Cloud e o outro PSC.
Implementação
Quando compra o Cross-Cloud Interconnect, a Google aprovisiona uma ligação física dedicada entre a rede Google e a de outro fornecedor de serviços na nuvem. Pode usar esta ligação para estabelecer intercâmbio entre a sua rede da nuvem virtual privada (VPC) e uma rede alojada por um fornecedor de serviços na nuvem suportado. Google Cloud
Depois de aprovisionar a ligação, a Google suporta a ligação até ao ponto em que atinge a rede do outro fornecedor de serviços na nuvem. A Google não garante o tempo de atividade do outro fornecedor de serviços na nuvem. No entanto, a Google continua a ser o principal ponto de contacto para o serviço completo e envia-lhe uma notificação se tiver de abrir um registo de apoio técnico com o outro PSC.
Esta solução requer que siga o processo de configuração para o outro PSC, incluindo a escolha do local onde as duas redes vão interligar-se. Apenas são suportados determinados CSPs.
Pode estabelecer ligação através do Cross-Cloud Interconnect por si só ou pode configurar o Cross-Cloud Interconnect como um raio híbrido do Network Connectivity Center. O Network Connectivity Center permite-lhe ligar localizações nas instalações, redes VPC e outras nuvens através da gestão centralizada.
Se o espaço de endereços IP entre ambos os ambientes de CSP se sobrepuser, pode ativar o NAT híbrido na ligação.
Velocidade de transferência e latência
Esta solução oferece capacidade dedicada entre Google Cloud e outro CSP. No lado Google Cloud , a interligação dedicada está disponível através da utilização de um ou vários pares de ligações físicas de 10 Gbps ou 100 Gbps.
A latência desta solução é a soma do seguinte:
- Latência entre a região em que os seus recursos estão alojados emGoogle Cloud e a localização entre nuvens.
- Latência entre a localização periférica da Google e a localização periférica do outro FSP (frequentemente na mesma instalação)
- Latência da localização de limite do outro CSP onde o Cross-Cloud Interconnect está implementado para a região onde os recursos estão alojados no CSP.
Embora não sejam oferecidas garantias de latência, esta solução permite normalmente a latência mais baixa possível e as velocidades de transferência mais elevadas possíveis entre oGoogle Cloud e outros ambientes de nuvem através de endereços IP privados.
Segurança
Uma vez que o tráfego através da Interligação entre nuvens não está encriptado, recomendamos que use a encriptação da camada de aplicação para o tráfego sensível.
Se todo o tráfego tiver de ser encriptado, os dispositivos virtuais disponíveis junto de parceiros no Cloud Marketplace podem fornecer soluções para encriptar o tráfego para o ambiente de outro CSP. Google Cloud
Fiabilidade e SLA
O Cross-Cloud Interconnect usa o SLA do Cloud Interconnect. Para ser elegível para o SLA, a configuração do Cross-Cloud Interconnect tem de usar um ou mais pares de ligações, conforme descrito na secção Contrato de nível de serviço da vista geral do Cross-Cloud Interconnect.
O SLA abrange tudo do lado da Google até ao limite da rede do outro fornecedor de nuvem. Não abrange a rede do outro CSP. Para mais informações, consulte a documentação de outros PSCs para o SLA no respetivo produto de interconexão; por exemplo, o SLA do AWS Direct Connect ou o SLA do Azure para o ExpressRoute.
Preços
Existe uma taxa horária para cada ligação do Cross-Cloud Interconnect, bem como para cada anexo de VLAN que se liga a um ambiente de VPC. O tráfego de saída através do Cross-Cloud Interconnect é cobrado a uma taxa inferior à do tráfego da Internet. Para mais informações, consulte os preços do Cross-Cloud Interconnect.
Consulte a página de preços do outro CSP para o respetivo produto de interconexão, por exemplo, os preços do AWS Direct Connect ou os preços do Azure ExpressRoute. Normalmente, existe uma cobrança mensal pela interconexão. Normalmente, os custos de transferência de dados através da interligação são inferiores aos custos de transferência de dados através da Internet.
Não existem custos separados para localizações de interconexão nem para equipamento.
Comparação de opções
As opções apresentadas variam em termos de velocidade, disponibilidade, complexidade, segurança e preço. Deve avaliar todas as opções cuidadosamente de acordo com as suas necessidades.
O diagrama seguinte explica o processo de escolha de uma das soluções mencionadas neste documento através de um fluxograma.
Normalmente, podemos recomendar as seguintes opções:
- Para muitos cenários em que os dados são trocados ocasionalmente ou em baixo volume e as transferências não são críticas, a transferência de dados através da Internet é a opção mais simples e continua a oferecer uma latência relativamente baixa e uma largura de banda elevada.
- Se for necessária a encriptação ou a transferência de quantidades mais pequenas de dados através de endereços IP privados, considere usar a Cloud VPN e um serviço VPN gerido do lado do outro CSP.
- Se transferir grandes quantidades de dados, a utilização da Interligação de parceiros com um parceiro com várias nuvens ativadas oferece várias vantagens: capacidade dedicada, custo mais baixo para transferências de dados e, consoante a topologia, um SLA para cada parte da solução. Normalmente, a capacidade da interligação de parceiros é inferior a 10 Gbps por ligação.
- Se ligar o seu equipamento nas instalações a várias nuvens, usar a Interligação dedicada através de um PoP comum é uma opção comum. Tem a complexidade adicional de gerir o seu próprio hardware e relações com uma instalação de alojamento conjunto. A menos que já tenha a infraestrutura implementada, esta solução está reservada para casos em que as taxas de transferência de dados típicas são de 10 Gbps ou mais.
- Se não quiser a sobrecarga da gestão de interconexões e equipamento de encaminhamento em PoPs remotos, o Cross-Cloud Interconnect oferece uma solução gerida em que a Google trata de tudo por si.
O que se segue?
- Reveja a série sobre padrões e práticas híbridas e multicloud.
- Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.