Visão geral dos spokes VPC

Nesta página, você encontra uma visão geral do suporte a spokes da nuvem privada virtual (VPC) no Network Connectivity Center.

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 exportam e importam toda a sub-rede IPv4 e rotas de outros spokes VPC em um hub do Network Connectivity Center. Isso garante conectividade IPv4 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. Os spokes VPC podem ser conectados 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 foram projetados para atender aos requisitos de carga de trabalho de empresas de médio a grande porte para conectividade roteada entre intervalos de sub-redes IPv4 localizados em muitas redes VPC distintas.

Uma rede VPC pode ser um spoke VPC do Network Connectivity Center e estar conectada a outras redes VPC usando o peering de rede VPC. No entanto, as rotas de sub-rede de peering que a rede VPC spoke importa usando o peering de rede VPC não são compartilhadas com outros spokes VPC conectados ao hub do Network Connectivity Center. Consequentemente, os serviços gerenciados que usam Acesso a serviços particulares não são acessíveis transitivamente por padrão usando outros spokes VPC de um hub do Network Connectivity Center. Nesse caso, é possível tornar o serviço gerenciado acessível usando um spoke de VPC do produtor (pré-lançamento).

Recurso Peering de rede VPC Spokes VPC
Redes VPC

Até 25 (exige a redução de outras cotas da VPC)

Até 250 spokes VPC ativos por hub.

Instâncias de VM

Instâncias por grupo de peering.

O Network Connectivity Center oferece suporte ao máximo por rede VPC. Não é necessário ter cotas de grupos de peering separados.

Intervalos de sub-rede (rotas de sub-rede)

Intervalos de sub-rede por grupo de peering.

Rotas por tabela de rotas de sub-rede.

Rotas estáticas e dinâmicas

Rotas estáticas por grupo de peering.

Rotas dinâmicas por região por grupo de peering.

500 rotas dinâmicas por hub.

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.

Endereços IP

Endereços IP internos, inclusive endereços IP privados e endereços IPv4 públicos usados de modo privado. Consulte Intervalos IPv4 válidos.

Endereços IPv4 internos, incluindo endereços IP privados e excluindo endereços IPv4 públicos usados de modo privado. Consulte Intervalos IPv4 válidos.

Famílias de endereços IP

Endereços de pilha dupla IPv4 e IPv6/IPv4.

Somente endereços IPv4.

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.

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. Para limitar a conectividade, especifique intervalos de endereços IP da divulgação e estabeleça uma lista de intervalos CIDR que podem ser divulgados pela rede VPC. Você também pode limitar a conectividade especificando uma lista de intervalos CIDR permitidos, bloqueando, assim, mas apenas nos intervalos permitidos.

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. As sub-redes que correspondem ao intervalo especificado não são exportadas 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 uma lista de intervalos CIDR que podem ser anunciados de um spoke VPC usando a propriedade include-export-ranges ou no campo includeExportRanges na API. Uma conectividade mais precisa é estabelecida quando você a usa junto com o endereço IP do filtro de exportação de exclusão de destino da rota. Essa filtragem determina se um intervalo de sub-rede específico pode ser divulgado pela rede VPC.

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 devem 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 IP:

    Range 1: 10.100.64.0/18

    Range 2: 10.100.250.0/21

    Range 3: 10.100.100.0/22

    Range 1 e range 2 são intervalos de inclusão válidos porque esses dois não se sobrepõem. No entanto, range 3 está em range 1, o que pode causar sobreposição, então range 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.

  • Por padrão, todas as políticas de conectividade de VPC têm um intervalo CIDR de 0.0.0.0/0 incluído. Se você não especificar o filtro de inclusão ao criar o spoke da VPC, o Network Connectivity Center define o intervalo de inclusão padrão como todos os Endereços IPv4, 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: suponha que haja o seguinte intervalo de endereços IP.

    Incluir intervalo: 10.0.0.0/8

    Exclude range 4: 10.1.1.0/24

    Subnet range 4: 10.1.0.0/16

    Nesse caso, o intervalo de inclusão contém subnet range 4. No entanto, é superconjunto de exclude range 4. Portanto, subnet range 4 é inválido.

  • Sobreposição com intervalo de inclusão: suponha que haja os seguintes intervalos de endereços IP.

    Incluir intervalo: 10.1.1.0/24

    Subnet range 5: 10.1.0.0/16

    Subnet range 5 se sobrepõe ao intervalo de inclusão, portanto, é inválido.

Quando você insere um intervalo de sub-rede inválido durante o processo de criação da sub-rede, você recebe um erro Invalid IPCiderRange, 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 desejada em todos os spokes VPC. É possível escolher uma das duas topologias predefinidas a seguir:

  • Topologia de malha
  • Topologia de estrela

Ao criar um hub usando o comando gcloud network-connectivity hubs create, escolha a malha predefinida ou a topologia em estrela. Se a topologia não for especificada, o padrão será usar malha. Depois de definido durante a criação do hub, não é possível mudar a topologia de um determinado hub.

Para alterar as configurações de topologia de um spoke, é possível excluí-lo e criar um novo spoke com um novo hub que usa uma topologia diferente.

Topologia de malha

A topologia de malha fornece conectividade de rede em alta escala entre spokes VPC. Essa topologia permite que todos os spokes se conectem e se comuniquem entres. As sub-redes nesses spokes VPC são totalmente acessíveis, a menos que você especifique exclude export filters. Por padrão, quando duas ou mais redes VPC de carga de trabalho são configuradas para ingressar em um hub do Network Connectivity Center como spokes, o Network Connectivity Center cria automaticamente uma malha completa de conectividade entre cada spoke.

Todos os spokes na topologia de malha pertencem a um único grupo padrão. A topologia de malha é compatível com VPC e tipos de spoke híbridos.

O diagrama a seguir mostra a conectividade da topologia de malha no Network Connectivity Center.

Conectividade da topologia de malha do Network Connectivity Center.
Conectividade da topologia de malha do Network Connectivity Center (clique para ampliar).

Topologia de estrela

A topologia em estrela só é compatível com spokes VPC. Quando você usa a topologia em estrela para conectividade, os spokes edge e as sub-redes associadas alcançam apenas os spokes center designados, enquanto os spokes center podem alcançar todos os outros spokes. Isso ajuda a garantir a segmentação e a separação de conectividade nas redes VPC de borda.

Como os spokes VPC podem ser anexados a um hub em um projeto diferente, eles podem vir de domínios administrativos diferentes. Esses spokes que estão em um projeto diferente do hub podem não precisar se comunicar com todos os outros spokes no hub do Network Connectivity Center.

É possível escolher a topologia em estrela para os seguintes casos de uso:

  • Cargas de trabalho em execução em diferentes redes VPC que não precisam de conectividade entre si, mas exigem acesso apenas às redes VPC usando a rede VPC central de serviços compartilhados.

  • Controle de segurança sobre a comunicação em várias redes VPC que exige que o tráfego passe por um conjunto de appliances virtuais de rede (NVAs) centralizados.

O diagrama a seguir mostra a conectividade da topologia em estrela no Network Connectivity Center. center-vpc-a e center-vpc-b estão associados ao grupo central, e edge-vpc-c e edge-vpc-d estão associados ao grupo de borda. Nesse caso, o uso da topologia em estrela permite que edge-vpc-c e edge-vpc-d sejam conectados a center-vpc-a e center-vpc-b e propaguem as sub-redes para o grupo central, mas não podem estar conectados entre si (sem acessibilidade direta entre edge-vpc-c e edge-vpc-d). Enquanto isso, center-vpc-a e center-vpc-b estão conectados entre si e a edge-vpc-c e edge-vpc-d, permitindo a acessibilidade total das VPCs do grupo central para o grupo de borda VPCs.

Conectividade da topologia em estrela do Network Connectivity Center.
Conectividade de topologia em estrela do Network Connectivity Center (clique para ampliar)

Grupos de spoke

Um grupo de spokes é um subconjunto de spokes anexados a um hub. Para configurar o Network Connectivity Center usando a topologia em estrela, é preciso separar todos os spokes da VPC em dois grupos diferentes, também chamados de domínios de roteamento:

  1. Um grupo center de spokes, que se comunicam com todos os outros spokes conectados ao hub.
  2. Um grupo de spokes de borda, que se comunicam apenas com os spokes que pertencem ao grupo central.

Um spoke VPC pode pertencer a apenas um grupo por vez. Os grupos são criados automaticamente quando você cria um hub.

Um administrador de hub pode atualizar um grupo de spokes usando o comando gcloud network-connectivity hubs groups update. O administrador do hub pode adicionar uma lista de IDs ou números de projeto para ativar a aceitação automática de spokes. Quando a aceitação automática estiver ativada, o spoke do projeto de aceitação automática será conectado automaticamente ao hub, sem a necessidade de uma revisão individual da proposta do spoke.

É possível listar os grupos center e edge como recursos aninhados para um hub específico usando o comando gcloud network-connectivity hubs groups list --hub. Para hubs criados com topologia de malha, a saída retorna o grupo padrão. Para hubs criados com topologia em estrela, a saída retorna os grupos center e edge.

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 (pré-lançamento).

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 IPv4 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.
  • As sub-redes sobrepostas precisam ser mascaradas por filtros de exportação de exclusão.
  • A atualização de export range filters após a criação do spoke VPC não é compatível.
  • 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, mas os spokes atuais continuam funcionando.
  • A conectividade da topologia em estrela não é compatível com spokes híbridos nem com troca de rota dinâmica.

Requisitos do 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 é necessário se a rede VPC for adicionada como um spoke ao mesmo hub.

Cotas e limites

Para informações detalhadas sobre cotas, consulte Cotas e limites.

Faturamento

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