Spokes VPC
O Network Connectivity Center fornece conectividade de rede entre VPCs em grande escala com o suporte a spokes VPC. Os spokes VPC reduzem a complexidade operacional da gestão das conexões de peering de rede VPC entre pares usando spokes VPC e o modelo de gerenciamento de conectividade centralizado. Os spokes VPC podem exportar e importar todas as rotas de sub-rede de outras VPCs spoke em um hub do Network Connectivity Center. Isso garante conectividade completa entre todas as cargas de trabalho que residem em todas essas redes VPC. O tráfego de rede entre VPCs permanece dentro da rede do Google Cloud e não viaja pela Internet, o que ajuda a garantir privacidade e segurança.
Os spokes VPC podem estar no mesmo projeto e organização ou em um projeto e uma organização diferentes do hub do Network Connectivity Center. Um spoke de VPC pode ser conectado a um hub por vez.
Para informações sobre como criar um spoke VPC, consulte Criar um spoke VPC.
Comparação com o peering de rede VPC
Os spokes VPC atendem aos requisitos de empresas de médio a grande porte ao fornecer conectividade de rota de sub-rede IPv4 e IPv6 e conectividade de rota dinâmica IPv4 usando spokes híbridos.
Uma rede VPC pode ser simultaneamente um spoke VPC do Network Connectivity Center e estar conectada a outra rede VPC usando o peering de rede VPC, desde que a rede VPC em peering não seja um spoke VPC.
Considere o seguinte ao usar spokes de VPC do Network Connectivity Center e peering de rede VPC:
As rotas de sub-rede de peering em um spoke de VPC não são exportadas para o hub.
O Network Connectivity Center não oferece conectividade a recursos em uma rede VPC conectada a um spoke VPC usando o peering de rede VPC, com a seguinte exceção:
- Uma rede VPC de produtor de serviços com peering para acesso a serviços particulares pode ser adicionada como um spoke de VPC de produtor.
| Recurso | Peering de rede VPC | Spokes VPC |
|---|---|---|
| Redes VPC | ||
| Intervalos de sub-rede (rotas de sub-rede) |
Rotas por tabela de rotas de sub-rede |
|
| Rotas estáticas e dinâmicas |
Prefixos de rota dinâmica exclusivos por tabela de rota de hub por região. Não é possível realizar a troca de rota estática. |
|
| Exportar filtros |
Não há suporte para filtros específicos. Consulte Opções de troca de rota na documentação de Peering de redes VPC. |
Até 16 intervalos CIDR compatíveis por spoke VPC. |
| Inter-VPC NAT |
Sem suporte |
Com suporte |
| Propagação da conexão Private Service Connect |
Sem suporte |
Com suporte |
| Conectividade do spoke VPC do produtor de outras redes VPC |
Sem suporte |
Com suporte |
| Endereços IP |
Endereços IPv4 internos, incluindo endereços IPv4 particulares e endereços IPv4 públicos usados de modo privado. Consulte Intervalos IPv4 válidos. Endereços IPv6 internos e externos. |
Endereços IPv4 internos, incluindo endereços IPv4 particulares e endereços IPv4 públicos usados de modo privado. Consulte Intervalos IPv4 válidos. Endereços IPv6 internos e externos. |
| Famílias de endereços IP |
Configurações aceitas:
|
Configurações aceitas:
|
| Desempenho e capacidade (em comparação com outros mecanismos de conectividade de VPC) |
Latência mais baixa, maior capacidade (equivalente a VM-VM). |
Latência mais baixa, maior capacidade (equivalente a VM-VM). |
Os spokes da VPC em um projeto diferente de um hub
Ao usar o Network Connectivity Center, é possível anexar redes VPC, representadas por spokes de VPC, a um único hub em um projeto diferente, incluindo um projeto em uma organização diferente. Isso permite que você conecte suas redes VPC em vários projetos e organizações em escala.
Você pode ser um dos seguintes tipos de usuários:
- Um administrador de hub que é proprietário de um hub em um projeto
- Um administrador de rede spoke ou administrador de rede que quer adicionar a rede VPC em um projeto diferente como um spoke no hub
O administrador do hub controla quem pode criar uma VPC que falou em um projeto diferente associado ao hub usando permissões de gerenciamento de identidade e acesso (IAM). O administrador de spoke da rede VPC cria um spoke em um projeto diferente do hub. Esses spokes ficam inativos após a criação. O administrador do hub precisa analisá-los e aceitar ou rejeitar o spoke. Se o administrador do hub aceitar o spoke, ele ficará ativo.
O Network Connectivity Center sempre aceita automaticamente spokes criados no mesmo projeto que o hub.
Para informações detalhadas sobre como gerenciar hubs que têm spokes VPC em um projeto diferente do hub, consulte Visão geral da administração do hub. Para informações detalhadas sobre administradores spoke, consulte Visão geral da administração Spoke.
Interação do hub com o VPC Service Controls
O Network Connectivity Center é compatível com o VPC Service Controls para spokes entre projetos e organizações. Para um spoke em um projeto diferente do hub, quando um novo perímetro do VPC Service Controls é adicionado, não é possível adicionar novos spokes que violam o perímetro. No entanto, os spokes adicionados antes da adição do perímetro do VPC Service Controls continuam funcionando.
Conectividade VPC com filtros de exportação
O Network Connectivity Center permite que você limite a conectividade de todas as redes VPC spoke a apenas um subconjunto de sub-redes na VPC spoke. Você pode limitar a conectividade da seguinte forma:
- É possível configurar o spoke para anunciar todos os intervalos de sub-rede ou nenhum deles.
- É possível mudar os intervalos de endereços de sub-rede exportados.
- É possível especificar intervalos de endereços para impedir que sejam divulgados e estabelecer uma lista de intervalos CIDR que podem ser divulgados pela rede VPC. Ou você pode especificar apenas uma lista de intervalos CIDR permitidos, bloqueando todos os outros.
É possível usar filtros de exportação para configurar os hubs da VPC de modo que troquem apenas intervalos de sub-rede IPv4, apenas intervalos de sub-rede IPv6 ou ambos. Considere um spoke cuja rede VPC tenha uma combinação de tipos de pilha de sub-rede. Se você configurar o spoke para exportar apenas intervalos de sub-rede IPv6, os intervalos IPv6 de sub-redes de pilha dupla e somente IPv6 serão trocados, mas os intervalos de sub-rede IPv4 de sub-redes somente IPv4 e de pilha dupla não serão trocados.
Excluir intervalos de exportação
É possível impedir que um intervalo de endereços IP seja anunciado usando a sinalização --exclude-export-ranges na CLI do Google Cloud ou o campo excludeExportRanges na API. Os intervalos de endereços IP que correspondem ao intervalo especificado não são exportados para o hub. Essa filtragem é útil quando você tem sub-redes que precisam ser particulares dentro da rede VPC ou podem se sobrepor a outras sub-redes na tabela de rotas do hub.
Incluir intervalos de exportação
Você pode estabelecer quais intervalos de endereços IP podem ser anunciados
de um spoke VPC usando a propriedade --include-export-ranges
ou no campo includeExportRanges na API. É possível especificar o seguinte:
- Para anunciar todos os intervalos de sub-redes IPv4 privadas, especifique
ALL_PRIVATE_IPV4_RANGES. - Para anunciar apenas intervalos de sub-rede específicos, especifique uma lista de intervalos CIDR.
- Para anunciar todos os intervalos de sub-rede IPv6, especifique
ALL_IPV6_RANGES.
Estabeleça uma conectividade mais precisa usando um filtro de exportação de inclusão junto com o filtro de exportação de exclusão. Essa filtragem determina se um intervalo de sub-rede específico pode ser divulgado pela rede VPC.
Endereços IPv4 públicos usados de modo privado
Para permitir a troca de endereços IPv4 públicos usados de modo privado com spokes da VPC e spokes da VPC do produtor, faça uma das seguintes ações durante a criação do spoke usando o campo --include-export-ranges:
- Digite
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 modo privado que você precisa.
Considerações
Considere o seguinte ao usar os filtros de exclusão e inclusão de intervalos de exportação:
Os intervalos de inclusão precisam ser exclusivos entre si, o que significa que os intervalos incluídos não podem se sobrepor. Por exemplo, suponha que há 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 esses dois não se sobrepõem. No entanto, o intervalo 3 está contido no intervalo 1, então o intervalo 3 é inválido.
Se você usa IPv6, suponha que tenha 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 esses dois não se sobrepõem. No entanto, o intervalo 3 está contido no intervalo 1, então o intervalo 3 é inválido.
Como o Network Connectivity Center já tem filtros de exportação de exclusão disponíveis na política de configuração de rede, os filtros de exportação de inclusão e exclusão afetam os intervalos válidos de CIDR de configuração de rede. Quando ambos incluem e excluem filtros de exportação são usados, o intervalo de endereços IP de inclusão precisa ser um superconjunto da exclusão de intervalos de endereços IP.
Se você não especificar o filtro de inclusão ao criar o spoke da VPC, o Network Connectivity Center vai definir o intervalo de inclusão padrão como todos os endereços IPv4 particulares válidos, conforme definido em Intervalos IPv4 válidos.
Para refinar um intervalo de inclusão, você pode adicionar vários intervalos de exclusão. Por exemplo: se você 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 será uma conectividade refinada com a combinação dos filtros de inclusão e exclusão. Esse intervalo inclui tudo de 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 atuais continuam funcionando conforme o esperado. Sobrepõe-se a intervalos de inclusão e exclusão ao criar novos intervalos de sub-redes resultam em erro.
Exemplos de novo intervalo de sub-rede inválidos
Os exemplos a seguir mostram intervalos de sub-redes inválidos:
Sobreposição com intervalo de exclusão
Nesse caso, o intervalo de inclusão a seguir contém o intervalo de sub-rede 4, que é um superconjunto do intervalo de exclusão 4. Isso significa que o intervalo de sub-rede 4 é inválido.
Incluir intervalo: 10.0.0.0/8
Intervalo de exclusão 4: 10.1.1.0/24
Intervalo da sub-rede 4: 10.1.0.0/16
Sobreposição com o intervalo de inclusão
O intervalo de sub-rede 5 se sobrepõe ao intervalo de inclusão, portanto, é inválido.
Incluir intervalo: 10.1.1.0/24
Intervalo da sub-rede 5: 10.1.0.0/16
Quando você insere um intervalo de sub-rede inválido durante o processo de criação da sub-rede, você recebe um erro
Invalid IPCidrRange, semelhante ao seguinte:Invalid IPCidrRange: CIDR_RANGE conflicts with existing subnetwork SUBNET_RANGE in region REGION
Topologias predefinidas
O Network Connectivity Center permite especificar a configuração de conectividade em todos os spokes VPC. É possível escolher uma das duas topologias predefinidas a seguir:
Para informações detalhadas sobre topologias de conectividade, consulte Topologias de conectividade predefinidas.
Para informações detalhadas sobre como configurar a topologia de malha ou em estrela para seus spokes VPC, consulte Configurar um hub.
Limitações
Nesta seção, descrevemos as limitações dos spokes VPC em geral e quando eles estão anexados a um hub em um projeto diferente. Essas limitações também se aplicam aos spokes de VPC do produtor.
Limitações dos spokes VPC
- As redes VPC podem se conectar de maneira exclusiva pelo hub do Network Connectivity Center ou por peering de rede VPC.
- Não é possível usar o peering de rede VPC entre dois spokes VPC
conectados ao mesmo hub do Network Connectivity Center. No entanto, pense
no seguinte caso:
- Um spoke de VPC de produtor requer uma conexão de peering com um spoke de VPC no mesmo hub. A conectividade pelo Network Connectivity Center não é estabelecida entre o spoke de VPC produtor e o spoke de VPC pareado.
- No entanto, é possível ter um spoke VPC conectado ao Network Connectivity Center que faz peering com peering de rede VPC com uma VPC separada que não faz parte do Network Connectivity Center.
- As VPCs conectadas usando o Network Connectivity Center e o peering de rede VPC em qualquer combinação não são transitivas.
- Não é possível realizar a troca de rotas estáticas entre spokes VPC.
- As rotas que apontam para endereços IP virtuais do balanceador de carga de rede de passagem interna em outros spokes VPC não são compatíveis.
- Os balanceadores de carga de rede de passagem interna baseados em IPv6 não podem ser acessados entre os spokes da VPC.
- Não há suporte para troca de rota dinâmica IPv6.
- As redes VPC de modo automático não são compatíveis como spokes VPC. É possível mudar do modo automático para uma rede VPC personalizada que permite definir manualmente prefixos de sub-rede para cada região na sua rede VPC. Depois de atualizado, não é possível desfazer essa ação.
Limitações da troca de rotas dinâmicas
Somente IPv4: o Network Connectivity Center só aceita a troca de rotas dinâmicas IPv4. Não é possível trocar rotas dinâmicas IPv6.
Compatibilidade do spoke híbrido com a topologia em estrela: um hub configurado para usar a topologia em estrela impõe as seguintes limitações aos spokes híbridos:
- Os spokes híbridos com a transferência de dados site a site ativada só são compatíveis com o grupo de spokes centrais.
- Os spokes híbridos sem a transferência de dados site a site ativada podem estar no grupo de spokes centrais ou de borda.
Redes VPC de roteamento que também são spokes VPC: o Network Connectivity Center aceita duas ou mais redes VPC de roteamento no mesmo hub somente se todas as redes VPC de roteamento não forem também spokes VPC. Se um hub do Network Connectivity Center tiver uma única rede VPC de roteamento, ela também poderá ser um spoke de VPC:
Se você precisar disponibilizar conexões propagadas do Private Service Connect para redes locais pelos spokes híbridos do hub, a única rede VPC de roteamento do hub também precisará estar conectada como um spoke de VPC.
Se você não precisar disponibilizar conexões propagadas do Private Service Connect para redes locais usando os spokes híbridos do hub, recomendamos não configurar uma rede VPC de roteamento como um spoke da VPC para que o hub possa oferecer suporte a duas ou mais redes VPC de roteamento.
Regras de interação de rotas dinâmicas: em uma rede VPC de roteamento, para cada destino de rota dinâmica exclusivo com um próximo salto em um spoke híbrido, verifique se todas as outras rotas dinâmicas, independente da prioridade, cujos destinos correspondem exatamente ou se encaixam no destino de rota dinâmica exclusivo, têm túneis do Cloud VPN ou anexos da VLAN de próximo salto também em um spoke híbrido. Além disso, verifique se esses spokes híbridos usam a mesma configuração de transferência de dados site a site (ativada ou desativada).
Se apenas alguns próximos saltos para rotas dinâmicas com um destino comum estiverem em spokes híbridos, o Network Connectivity Center não poderá trocar de maneira confiável rotas dinâmicas que usam esse destino com spokes VPC no hub. Consequentemente, os spokes de VPC podem não receber essas rotas dinâmicas.
O Network Connectivity Center não realiza ECMP entre todos os próximos hops de rotas dinâmicas de spoke híbrido se alguns spokes híbridos tiverem a transferência de dados site a site ativada e outros, desativada. Se rotas dinâmicas com um destino comum estiverem em spokes híbridos sem configurações correspondentes de transferência de dados site a site, os próximos saltos para transferência de dados site a site ou para conectividade entre spokes de VPC e redes locais podem não ser o que você espera.
Regras de interação entre rotas dinâmicas e estáticas: em uma rede VPC de roteamento, para cada destino de rota dinâmica exclusiva que tenha um próximo salto em um spoke híbrido, verifique se não há rotas estáticas locais, independente da prioridade, cujos destinos correspondam exatamente ou se encaixem no destino da rota dinâmica.
Se uma rota estática local na rede VPC de roteamento tiver o mesmo destino de uma rota dinâmica de spoke híbrido, os spokes de VPC poderão perder a conectividade com o destino da rota dinâmica.
Se uma rota estática local em uma rede VPC de roteamento tiver um destino que se encaixe no destino de uma rota dinâmica de spoke híbrido, os spokes da VPC perderão a conectividade com o destino da rota estática.
Período de espera após a exclusão de um spoke VPC
Para um novo spoke para a mesma rede VPC anexado a um hub diferente, aguarde o período de espera de pelo menos 10 minutos. Se o período de espera adequado não for permitido, a nova configuração pode não entrar em vigor. Esse período de espera não será necessário se a rede VPC for adicionada como spoke ao mesmo hub.
Cotas e limites
Ao usar a troca de rotas dinâmicas, monitore com atenção o uso do número de rotas dinâmicas por hub. Essa cota conta o uso por destino (prefixo) apenas, sem considerar a prioridade ou o próximo salto de uma rota dinâmica. Quando o uso dessa cota excede o limite, o Network Connectivity Center descarta rotas por destino. Se um destino for descartado, todas as rotas dinâmicas com esse destino, independente da prioridade ou do próximo salto, não serão mais enviadas ao hub.
Para informações detalhadas sobre cotas, consulte Cotas e limites.
Faturamento
As seções a seguir descrevem detalhes do faturamento de horas de spoke e tráfego de saída.
Horário de funcionamento
As horas de spoke são cobradas no projeto em que o recurso spoke fica localizado e segue o preço padrão de horas de spoke. As horas do spoke só são cobradas quando o spoke está no estado ACTIVE.
Tráfego de saída
O tráfego de saída é cobrado no projeto do recurso spoke de origem do tráfego. O preço é o mesmo, independentemente de o tráfego ultrapassar os limites do projeto.
Contrato de nível de serviço
Para informações sobre o contrato de nível de serviço (SLA) do Network Connectivity Center, consulte este link.
Preços
Para mais informações, consulte Preços do Network Connectivity Center.
A seguir
- Para criar hubs e spokes, consulte Como trabalhar com hubs e spokes.
- Para uma lista de parceiros com soluções integradas à Network Connectivity Center, consulte Parceiros da Network Connectivity Center.
- Para encontrar soluções para problemas comuns, consulte Solução de problemas.
- Para ver detalhes sobre os comandos da API e do
gcloud, consulte APIs e referência.