Hubs da VPC
O Network Connectivity Center oferece conetividade de rede entre VPCs em grande escala com o suporte para raios da VPC. Os raios da VPC reduzem a complexidade operacional da gestão das ligações de interligação de redes VPC individuais através da utilização de raios da VPC e de um modelo de gestão de conetividade centralizado. Os raios da VPC podem exportar e importar todas as rotas de sub-redes de outras VPCs de raios num hub do Network Connectivity Center. Isto garante a conetividade total entre todas as cargas de trabalho que residem em todas estas redes VPC. O tráfego de rede entre VPCs permanece na rede Google Cloud e não viaja através da Internet, o que ajuda a garantir a privacidade e a segurança.
Os raios da VPC podem estar no mesmo projeto e organização ou num projeto e organização diferentes do hub do Network Connectivity Center. Um raio da VPC pode ser ligado a um hub de cada vez.
Para obter informações sobre como criar um spoke de VPC, consulte o artigo Crie um spoke de VPC.
Comparação com o intercâmbio da rede da VPC
Os raios da VPC suportam os requisitos de empresas de média a grande dimensão através do seguinte: fornecimento de conetividade de rotas de sub-rede IPv4 e IPv6 e conetividade de rotas dinâmicas IPv4 com raios híbridos.
Uma rede da VPC pode ser simultaneamente um raio da VPC do Network Connectivity Center e estar ligada a outra rede da VPC através do intercâmbio das redes da VPC, desde que a rede da VPC com intercâmbio não seja um raio da VPC.
Tenha em atenção o seguinte quando usar os raios da VPC do Network Connectivity Center e o intercâmbio da rede da VPC:
Os encaminhamentos de sub-rede de peering num spoke de VPC não são exportados para o hub.
O Network Connectivity Center não fornece conetividade a recursos numa rede de VPC que esteja ligada a um raio de VPC através do intercâmbio das redes da VPC, com a seguinte exceção:
- Pode adicionar uma rede VPC de produtor de serviços com intercâmbio para acesso a serviços privados como um ponto de acesso VPC produtor.
| Funcionalidade | Intercâmbio de redes da VPC | Hubs da VPC |
|---|---|---|
| Redes da VPC | ||
| Intervalos de sub-redes (encaminhamentos de sub-redes) | ||
| Rotas estáticas e dinâmicas |
Prefixos de rotas dinâmicas exclusivos por tabela de rotas do hub por região. A troca de rotas estáticas não é suportada. |
|
| Exporte filtros |
Os filtros específicos não são suportados. Consulte as opções de troca de rotas na documentação do peering de redes VPC. |
Até 16 intervalos CIDR suportados por VPC spoke. |
| NAT entre VPCs |
Não suportado |
Suportado |
| Propagação da ligação do Private Service Connect |
Não suportado |
Suportado |
| Conetividade do spoke da VPC do produtor a partir de outras redes VPC |
Não suportado |
Suportado |
| Endereçamento IP |
Endereços IPv4 internos, incluindo endereços IPv4 privados e endereços IPv4 públicos usados de forma privada. Consulte os intervalos de IPv4 válidos. Endereços IPv6 internos e externos. |
Endereços IPv4 internos, incluindo endereços IPv4 privados e endereços IPv4 públicos usados de forma privada. Consulte os intervalos de IPv4 válidos. Endereços IPv6 internos e externos. |
| Famílias de endereços IP |
Configurações suportadas:
|
Configurações suportadas:
|
| Desempenho e débito (quando comparados com outros mecanismos de conetividade da VPC) |
Latência mais baixa, débito mais elevado (equivalente a VM-VM). |
Latência mais baixa, débito mais elevado (equivalente a VM-VM). |
Nós da VPC num projeto diferente de um centro
Ao usar o Network Connectivity Center, pode anexar redes VPC, representadas como raios VPC, a um único hub num projeto diferente, incluindo um projeto numa organização diferente. Isto permite-lhe ligar as suas redes VPC em vários projetos e organizações em grande escala.
Pode ser um dos seguintes tipos de utilizadores:
- Um administrador do hub que é proprietário de um hub num projeto
- Um administrador de spoke de rede VPC ou um administrador de rede que queira adicionar a respetiva rede VPC num projeto diferente como spoke ao hub
O administrador do hub controla quem pode criar um spoke da VPC num projeto diferente associado ao respetivo hub através de autorizações da gestão de identidade e de acesso (IAM). O administrador do spoke da rede VPC cria um spoke num projeto diferente do hub. Estes raios estão inativos após a criação. O administrador do hub tem de revê-las e pode aceitar ou rejeitar o spoke. Se o administrador do hub aceitar o spoke, este fica ativo.
O Network Connectivity Center aceita sempre automaticamente raios criados no mesmo projeto que o hub.
Para obter informações detalhadas sobre como gerir hubs que têm raios de VPC num projeto diferente do hub, consulte o artigo Vista geral da administração do hub. Para ver informações detalhadas para administradores de ramificações, consulte a Vista geral da administração de ramificações.
Interação do spoke com os VPC Service Controls
O Network Connectivity Center suporta VPC Service Controls para raios de projetos e organizações. Para um spoke num projeto diferente do hub, quando é adicionado um novo perímetro do VPC Service Controls, não pode adicionar novos spokes que violem o perímetro. No entanto, os raios existentes que adicionou antes de adicionar o perímetro do VPC Service Controls continuam a funcionar.
Conetividade da VPC com filtros de exportação
O Network Connectivity Center permite-lhe limitar a conetividade de todas as redes VPC spoke apenas a um subconjunto de sub-redes na VPC spoke. Pode limitar a conetividade da seguinte forma:
- Pode configurar o spoke para anunciar todos os respetivos intervalos de sub-redes ou nenhum dos respetivos intervalos de sub-redes.
- Pode alterar os intervalos de endereços de sub-rede exportados.
- Pode especificar intervalos de endereços para impedir que sejam anunciados e estabelecer uma lista de intervalos CIDR que podem ser anunciados a partir da rede VPC. Em alternativa, pode especificar apenas uma lista de intervalos CIDR permitidos, bloqueando assim todos os intervalos, exceto os permitidos.
Pode usar filtros de exportação para configurar os raios da VPC para trocar apenas intervalos de sub-redes IPv4, apenas intervalos de sub-redes IPv6 ou ambos os intervalos de sub-redes IPv4 e IPv6. Considere um spoke cuja rede VPC tenha uma combinação de tipos de pilha de sub-redes. Se configurar o spoke para exportar apenas intervalos de sub-redes IPv6, os intervalos IPv6 de sub-redes de pilha dupla e apenas IPv6 são trocados, mas os intervalos de sub-redes IPv4 de sub-redes apenas IPv4 e de pilha dupla não são trocados.
Exclua intervalos de exportação
Pode impedir que um intervalo de endereços IP seja anunciado através da flag --exclude-export-ranges na CLI Google Cloud ou do campo excludeExportRanges na API. Todos os intervalos de endereços IP que correspondam ao intervalo especificado são excluídos da exportação para o hub. Esta filtragem
é útil quando tem sub-redes que precisam de ser privadas na
rede VPC ou que podem sobrepor-se a outras sub-redes na
tabela de rotas do hub.
Inclua intervalos de exportação
Pode estabelecer que intervalos de endereços IP têm autorização para serem anunciados a partir de um spoke da VPC através da flag --include-export-ranges ou do campo includeExportRanges na API. Pode especificar o seguinte:
- Para anunciar todos os intervalos de sub-redes IPv4 privadas, pode especificar
ALL_PRIVATE_IPV4_RANGES. - Para anunciar apenas intervalos de sub-redes específicos, pode especificar uma lista de intervalos CIDR.
- Para anunciar todos os intervalos de sub-redes IPv6, pode especificar
ALL_IPV6_RANGES.
Estabeleça uma conetividade mais precisa usando um filtro de exportação de inclusão juntamente com o filtro de exportação de exclusão. Esta filtragem determina se um intervalo de sub-rede específico pode ser anunciado a partir da rede VPC.
Endereços IPv4 públicos usados de forma privada
Para permitir a troca de
endereços IPv4 públicos usados de forma privada com
raios da VPC e raios da VPC do produtor, pode fazer
uma das seguintes ações durante a criação do raio através do campo
--include-export-ranges:
- Introduza
ALL_IPV4_RANGES. - Adicione
ALL_PRIVATE_IPV4_RANGESe inclua uma lista separada por vírgulas dos intervalos de endereços IPv4 públicos usados de forma privada de que precisa.
Considerações
Considere o seguinte quando usar os filtros de intervalos de exportação de exclusão e inclusão:
Os intervalos de inclusão têm de ser exclusivos, o que significa que não se podem sobrepor. Por exemplo, suponhamos que existem três intervalos de endereços IPv4:
Intervalo 1: 10.100.64.0/18
Intervalo 2: 10.100.250.0/21
Intervalo 3: 10.100.100.0/22
O intervalo 1 e o intervalo 2 são intervalos de inclusão válidos porque não se sobrepõem. No entanto, o intervalo 3 está contido no intervalo 1, pelo que o intervalo 3 é inválido.
Se usar IPv6, suponha que tem estes três intervalos de endereços IPv6:
Intervalo 1: 2001:db8::/32
Intervalo 2: 2001:db9::/32
Intervalo 3: 2001:db8:1000::/48
O intervalo 1 e o intervalo 2 são intervalos de inclusão válidos porque não se sobrepõem. No entanto, o intervalo 3 está contido no intervalo 1, pelo que o intervalo 3 é inválido.
Uma vez que o Network Connectivity Center já tem filtros de exclusão de exportação disponíveis na política de configuração de rede, os filtros de inclusão e exclusão de exportação afetam os intervalos CIDR de configuração de rede válidos. Quando são usados filtros de exportação de inclusão e exclusão, os intervalos de endereços IP de inclusão têm de ser um superconjunto dos intervalos de endereços IP de exclusão.
Se não especificar o filtro de inclusão ao criar o spoke da VPC, o Network Connectivity Center define o intervalo de inclusão predefinido para todos os endereços IPv4 privados válidos, conforme definido em Intervalos IPv4 válidos.
Para refinar um intervalo de inclusão, pode adicionar vários intervalos de exclusão. Por exemplo, se especificar 10.1.0.0/16 como um intervalo de inclusão e 10.1.100.0/24 e 10.1.200.0/24 como os intervalos de exclusão, o resultado é uma conetividade refinada com a combinação de filtros de inclusão e exclusão. Este intervalo inclui tudo, desde 10.1.0.0/24 a 10.1.99.0/24, 10.1.101.0/24 a 10.1.199.0/24 e 10.1.201.0/24 a 10.1.255.0/24.
Os intervalos de sub-redes existentes continuam a funcionar conforme esperado. As sobreposições com intervalos de inclusão e exclusão quando cria novos intervalos de sub-redes resultam num erro.
Exemplos de intervalo de sub-rede novo inválido
Os exemplos seguintes mostram intervalos de sub-redes inválidos:
Sobreposição com o intervalo de exclusão
Neste caso, o intervalo de inclusão seguinte contém o intervalo de sub-rede 4, que é um superconjunto do intervalo de exclusão 4. Isto significa que o intervalo de sub-rede 4 é inválido.
Incluir intervalo: 10.0.0.0/8
Excluir intervalo 4: 10.1.1.0/24
Intervalo de sub-rede 4: 10.1.0.0/16
Sobreposição com o intervalo de inclusão
O intervalo de sub-rede 5 sobrepõe-se ao intervalo de inclusão, pelo que é inválido.
Incluir intervalo: 10.1.1.0/24
Intervalo de sub-rede 5: 10.1.0.0/16
Quando introduz um intervalo de sub-rede inválido durante o processo de criação de sub-rede, recebe um erro
Invalid IPCidrRangesemelhante ao seguinte:Invalid IPCidrRange: CIDR_RANGE conflicts with existing subnetwork SUBNET_RANGE in region REGION
Topologias predefinidas
O Network Connectivity Center permite-lhe especificar a configuração de conetividade em todos os raios da VPC. Pode escolher uma das seguintes duas topologias predefinidas:
Para obter informações detalhadas sobre as topologias de conetividade, consulte o artigo Topologias de conetividade predefinidas.
Para informações detalhadas sobre como configurar a topologia de malha ou estrela para os raios da VPC, consulte o artigo Configure um hub.
Limitações
Esta secção descreve as limitações dos spokes da VPC em geral e quando estão anexados a um hub num projeto diferente. Estas limitações também se aplicam aos raios da VPC do produtor.
Limitações dos raios da VPC
- As redes VPC podem ligar-se entre si de forma exclusiva através do hub do Network Connectivity Center ou do intercâmbio das redes da VPC.
- Não pode usar o intercâmbio da rede da VPC entre dois spokes da VPC que estejam ligados ao mesmo hub do Network Connectivity Center. No entanto, considere
o seguinte:
- Um VPC spoke de produtor requer uma ligação de peering a um VPC spoke no mesmo hub. A conetividade através do Network Connectivity Center não é estabelecida entre o spoke da VPC do produtor e o respetivo spoke da VPC com intercâmbio.
- Pode ter um spoke de VPC ligado ao Network Connectivity Center que esteja interligado através do intercâmbio das redes da VPC com uma VPC separada que não faça parte do Network Connectivity Center.
- As VPCs ligadas entre si através do Network Connectivity Center e do intercâmbio da rede da VPC em qualquer combinação não são transitivas.
- A troca de rotas estáticas entre raios de VPC não é suportada.
- As rotas que apontam para endereços IP virtuais do balanceador de carga de rede de passagem interna em raios de VPC diferentes não são suportadas.
- Os balanceadores de carga de rede de encaminhamento interno baseados em IPv6 não são acessíveis entre os raios da VPC.
- A troca de rotas dinâmicas IPv6 não é suportada.
- As redes VPC de modo automático não são suportadas como VPC spokes. Pode mudar do modo automático para uma rede VPC personalizada que lhe permite definir manualmente prefixos de sub-redes para cada região na sua rede VPC. Depois de atualizada, não pode anular esta ação.
Limitações da troca de rotas dinâmicas
Apenas IPv4: o Network Connectivity Center só suporta a troca de rotas dinâmicas IPv4. A troca de rotas dinâmicas IPv6 não é suportada.
Compatibilidade de raios híbridos com a topologia em estrela: um hub configurado para usar a topologia em estrela aplica as seguintes limitações aos respetivos raios híbridos:
- Os raios híbridos com a transferência de dados de site a site ativada só são suportados no grupo de raios central.
- Os raios híbridos sem a transferência de dados de site a site ativada podem estar no grupo de raios central ou no grupo de raios periférico.
Encaminhamento de redes da VPC que também são raios da VPC: o Network Connectivity Center suporta duas ou mais redes da VPC de encaminhamento no mesmo hub apenas se todas as redes da VPC de encaminhamento não forem também raios da VPC. Se um hub do Network Connectivity Center tiver uma rede de VPC de encaminhamento única, essa rede de VPC de encaminhamento também pode ser opcionalmente um spoke de VPC:
Se precisar de disponibilizar ligações do Private Service Connect propagadas às redes no local através dos raios híbridos do hub, a rede VPC de encaminhamento único do hub também tem de estar ligada como um raio da VPC.
Se não precisar de disponibilizar ligações do Private Service Connect propagadas a redes no local através dos raios híbridos do hub, recomendamos que não configure uma rede VPC de encaminhamento como um raio da VPC para que o hub possa suportar duas ou mais redes VPC de encaminhamento.
Regras de interação de trajetos dinâmicos: numa rede VPC de encaminhamento, para cada destino de trajeto dinâmico exclusivo com um próximo salto num raio híbrido, tem de garantir que todos os outros trajetos dinâmicos, independentemente da prioridade, cujos destinos correspondam exatamente ou se enquadrem no destino de trajeto dinâmico exclusivo, também têm túneis da Cloud VPN ou anexos de VLAN num raio híbrido. Além disso, tem de garantir que esses raios híbridos usam a mesma definição de transferência de dados de site a site (ativada ou desativada).
Se apenas alguns saltos seguintes para rotas dinâmicas com um destino comum estiverem em raios híbridos, o Network Connectivity Center não pode trocar de forma fiável rotas dinâmicas que usem esse destino com raios da VPC no hub. Consequentemente, os spokes da VPC podem não receber essas rotas dinâmicas.
O Network Connectivity Center não executa ECMP entre todos os próximos saltos de rotas dinâmicas de raios híbridos se alguns raios híbridos tiverem a transferência de dados de site a site ativada, mas outros raios híbridos tiverem a transferência de dados de site a site desativada. Se os trajetos dinâmicos com um destino comum estiverem em raios híbridos sem definições de transferência de dados entre sites correspondentes, os saltos seguintes para a transferência de dados entre sites ou para a conetividade entre raios de VPC e redes no local podem não ser o que espera.
Regras de interação de rotas dinâmicas e estáticas: numa rede VPC de encaminhamento, para cada destino de rota dinâmica exclusivo que tenha um próximo salto num raio híbrido, tem de garantir que não existem rotas estáticas locais, independentemente da prioridade, cujos destinos correspondam exatamente ou se enquadrem no destino da rota dinâmica.
Se um trajeto estático local na rede VPC de encaminhamento tiver o mesmo destino que um trajeto dinâmico de um spoke híbrido, os spokes da VPC podem perder a conetividade com o destino do trajeto dinâmico.
Se um trajeto estático local numa rede da VPC de encaminhamento tiver um destino que se enquadre no destino de um trajeto dinâmico híbrido, os raios da VPC perdem a conetividade com o destino do trajeto estático.
Período de repouso após a eliminação de um spoke de VPC
Para um novo spoke para a mesma rede VPC anexada a um hub diferente, tem de aguardar o período de repouso de, pelo menos, 10 minutos. Se o período de repouso adequado não for permitido, a nova configuração pode não entrar em vigor. Este período de repouso não é necessário se a rede VPC for adicionada como um spoke ao mesmo hub.
Quotas e limites
Quando usar a troca de rotas dinâmicas, monitorize cuidadosamente a sua utilização do número de rotas dinâmicas por hub. Esta quota contabiliza a utilização por destino (prefixo) apenas, independentemente da prioridade ou do próximo salto de uma rota dinâmica. Quando a utilização desta quota excede o respetivo limite, o Network Connectivity Center elimina as rotas por destino. Se um destino for eliminado, todas as rotas dinâmicas com esse destino, independentemente da prioridade ou do próximo salto, deixam de ser enviadas para o hub.
Para ver informações detalhadas sobre quotas, consulte o artigo Quotas e limites.
Faturação
As secções seguintes descrevem os detalhes da faturação das horas de spoke e do tráfego de saída.
Horário de funcionamento
As horas de spoke são cobradas ao projeto onde o recurso de spoke reside e seguem os preços padrão das horas de spoke. As horas de conversação só são cobradas quando
o raio está no estado ACTIVE.
Tráfego de saída
O tráfego de saída é cobrado ao projeto do recurso spoke a partir do qual o tráfego tem origem. O preço é o mesmo, independentemente de o tráfego atravessar ou não os limites do projeto.
Contrato de nível de serviço
Para obter informações sobre o contrato de nível de serviço do Network Connectivity Center, consulte o contrato de nível de serviço (SLA) do Network Connectivity Center.
Preços
Para ver informações sobre preços, consulte a secção Preços do Centro de conectividade de rede.
O que se segue?
- Para criar centros e nós, consulte o artigo Trabalhe com centros e nós.
- Para ver uma lista de parceiros cujas soluções estão integradas com o Network Connectivity Center, consulte Parceiros do Network Connectivity Center.
- Para encontrar soluções para problemas comuns, consulte a secção Resolução de problemas.
- Para obter detalhes sobre a API e os comandos
gcloud, consulte APIs e referência.