Quando você usa o Cloud Interconnect, o Google provisiona conexões físicas em seu nome entre a rede do Google Cloud e a rede do Microsoft Azure.
Antes que o Google possa estabelecer essas conexões, é preciso solicitar portas do Google e do Azure. Como preparação para esse processo, identifique os locais do Google Cloud e os locais correspondentes do Azure que você quer usar nas suas conexões.
Práticas recomendadas para selecionar um local
Ao decidir onde colocar as conexões, considere questões como as seguintes:- Onde estão a maioria dos seus recursos do Google Cloud?
- Onde estão a maioria dos seus recursos do Azure?
Se os recursos de ambas as nuvens estiverem no mesmo lugar, a escolha é simples. No entanto, se não estiverem, considere se quer que suas conexões estejam mais próximas dos recursos do Google Cloud ou dos recursos do Azure. Se as conexões estiverem mais próximas dos seus recursos do Azure, o tráfego passa mais tempo viajando pela rede do Google, o que em geral é desejável. No entanto, considere também os custos de transferência de dados de saída que você provavelmente terá em ambas as nuvens.
Fatores afetados pela localização
Esta seção descreve os fatores que são afetados por sua escolha de local.
Anexos da VLAN e circuitos ExpressRoute
Depois que a conexão do Cloud Interconnect é estabelecida, configure vários recursos no Google Cloud e no Azure. No Google Cloud, esses recursos incluem anexos da VLAN. Um anexo da VLAN é uma conexão lógica entre sua rede de nuvem remota e uma única região na sua rede de nuvem privada virtual.
No Azure, você precisa criar um recurso semelhante. O recurso Azure é chamado de circuito ExpressRoute.
Ao escolher um local para suas portas, você limita o conjunto de regiões em que pode colocar anexos da VLAN e interfaces virtuais. Por esse motivo, a tabela de locais compatíveis inclui colunas para as regiões do Google Cloud e do Azure que são exibidas por cada local da porta.
Domínios de disponibilidade de borda
Cada área metropolitana tem dois domínios de disponibilidade de borda do Google Cloud. A manutenção de dois domínios na mesma área metropolitana não está programada para ser executada ao mesmo tempo. Por esse motivo, quando você seleciona um local para uma porta principal e redundante, cada porta precisa usar um domínio de disponibilidade de borda diferente dentro da mesma área metropolitana. Isso ocorre independentemente de como você ordena as portas. No entanto, ao usar a Google Cloud CLI, você precisa especificar cada domínio de disponibilidade de borda explicitamente. Quando você usa o console do Google Cloud, basta selecionar um local, e o Google Cloud reserva uma porta para você em cada domínio.
Na versão da CLI gcloud do nome do local, o domínio de disponibilidade de borda é a segunda informação. Por exemplo, se o nome do local for iad-zone1-1, o domínio de disponibilidade de borda será zone1. Se o nome do local for iad-zone2-1, a zona de disponibilidade de borda será zone2.
Instalações de colocation
O Azure exige que as conexões sejam provisionadas na mesma instalação. Por esse motivo, cada par de locais na tabela de locais compatíveis representa uma única instalação.
Lista de locais compatíveis
A tabela a seguir lista os locais compatíveis com o Azure e os locais correspondentes do Google Cloud.
Você precisa especificar a localização do Google Cloud da porta do Cross-Cloud Interconnect, além de especificar em que local do outro provedor de nuvem a conexão será feita. Esse último local do Azure é chamado de local remoto neste conjunto de documentação e no Google Cloud. Use o nome do local remoto quando fizer o pedido do Cross-Cloud Interconnect. O provedor de nuvem remoto tem um nome diferente, embora semelhante, para o local, que você usa ao solicitar a porta com esse provedor de nuvem.
Há variações de sintaxe para cada nome de local. Exemplo:
- O nome do local remoto varia de acordo com sua interação com o Azure ou o Google Cloud.
- Ao interagir com o Google Cloud, o Console do Google Cloud exibe a descrição ao lado do nome do local para ajudar você a escolher o local correto.
- No Google Cloud, o local do Cloud Interconnect do Console do Google Cloud (não o local remoto) mostra informações da instalação em vez do nome real do local do Cloud Interconnect.
| Regiões do Google Cloud | Regiões do Microsoft Azure | Área metropolitana | Local remoto | Locais do Google Cloud | |
|---|---|---|---|---|---|
| Google Cloud | Microsoft Azure | ||||
|
|
Hong Kong | azure-equinix-hong-kong-hk1 | Equinix-Hong-Kong-HK1 |
|
|
|
Osaka | azure-equinix-osaka-os1 | Equinix-Osaka-OS1 |
|
|
|
Seul | azure-kinx-seoul-gasan | KINX-Seoul-Gasan |
|
|
|
Singapura | azure-equinix-singapore-sg1 | Equinix-Singapore-SG1 |
|
| azure-global-switch-singapore | Global-Switch-Singapore |
| |||
|
|
Tóquio | azure-equinix-tokyo-ty4 | Equinix-Tokyo-TY4 |
|
|
|
Sydney | azure-equinix-sydney-sy2 | Equinix-Sydney-SY2 |
|
| azure-nextdc-sydney-s1 | NextDC-Sydney-S1 |
| |||
|
|
Amsterdã | azure-equinix-amsterdam-am5 | Equinix-Amsterdam-AM5 |
|
|
|
Frankfurt | azure-interxion-frankfurt-fra11 | Interxion-Frankfurt-FRA11 |
|
| azure-equinix-frankfurt-fr7 | Equinix-Frankfurt-FR7 |
| |||
|
|
Londres | azure-equinix-london-ld5 | Equinix-London-LD5 |
|
|
|
Paris | azure-interxion-paris-par5 | Interxion-Paris-PAR5 |
|
|
|
Zurique | azure-interxion-zurich-zur2 | Interxion-Zurich-ZUR2 |
|
|
|
Mumbai | azure-tata-mumbai-lvsb | Tata-Mumbai-LVSB |
|
|
|
Washington D.C. | azure-equinix-ashburn-dc2 | Equinix-Ashburn-DC2 |
|
| azure-equinix-ashburn-dc6 | Equinix-Ashburn-DC6 |
| |||
| azure-coresite-reston-va2 | CoreSite-Reston-VA2 |
| |||
|
|
Chicago | azure-equinix-chicago-ch1 | Equinix-Chicago-CH1 |
|
|
|
Dallas | azure-equinix-dallas-da3 | Equinix-Dallas-DA3 |
|
|
|
Portland | azure-edgeconnex-portland-por01 | EdgeConneX-Portland-POR01 |
|
|
|
San Antonio, Texas | azure-cyrusone-san-antonio-1 | CyrusOne-San-Antonio-1 |
|
|
|
São Francisco | azure-coresite-santa-clara-sv7 | CoreSite-Santa-Clara-SV7 |
|
|
|
Seattle | azure-equinix-seattle-se2 | Equinix-Seattle-SE2 |
|
|
|
Toronto | azure-cologix-toronto-tor1 | Cologix-Toronto-TOR1 |
|
Verificar disponibilidade
Depois de identificar um local que você quer usar, verifique se ele tem uma porta direta de 10 Gbps ou 100 Gbps. Essa etapa é útil porque a disponibilidade de portas pode mudar sem aviso prévio.
Se você estiver trabalhando no portal do Azure, poderá verificar a disponibilidade durante o pedido das conexões. Para verificar a disponibilidade com antecedência, use o Azure PowerShell.
Azure PowerShell
Use o comando Get-AzExpressRoutePortsLocation:
Get-AzExpressRoutePortsLocation -LocationName LOCATION
Substitua LOCATION pelo nome do local como é representado no Azure, por exemplo, Interxion-Frankfurt-FRA11.
Na saída do comando, observe o bloco AvailableBandwidths: Verifique se ela lista a velocidade de porta necessária.
Por exemplo, a saída a seguir mostra que Interxion-Frankfurt-FRA11 tem as portas 10 Gbps e 100 Gbps disponíveis:
Name : Interxion-Frankfurt-FRA11
Id : [ID information]
ProvisioningState : Succeeded
Address : Interxion Deutschland GmbHHanauer Landstraße 298 60314 Frankfurt am Main
Deutschland
Contact : de.info@interxion.com
AvailableBandwidths : [
{
"OfferName": "100 Gbps",
"ValueInGbps": 100
},
{
"OfferName": "10 Gbps",
"ValueInGbps": 10
}
]
Locais e regiões
Depois de revisar as seções anteriores, anote os seguintes valores:
- O local remoto, como é conhecido no Google Cloud, e o local do Google Cloud. Você precisa desses valores ao solicitar suas conexões do Cross-Cloud Interconnect.
- O local remoto, como é conhecido no Azure, e a região em que você quer colocar os recursos do ExpressRoute Direct e os circuitos ExpressRoute. Você precisa desses valores ao ordenar as portas do Azure e criar os circuitos ExpressRoute.
- A região do Google Cloud em que você quer colocar os anexos da VLAN. Você precisará desse valor ao criar o anexo, conforme descrito em Configurar seus recursos do Google Cloud.