Get best of the week

Como o Yandex.Cloud é hospedado pela Virtual Private Cloud e como nossos usuários nos ajudam a implementar recursos úteis

Olá, meu nome é Kostya Kramlikh, sou um desenvolvedor líder da divisão Virtual Private Cloud no Yandex.Cloud. Estou envolvido em uma rede virtual e, como você deve imaginar, neste artigo, falarei sobre o dispositivo de nuvem privada virtual (VPC) em geral e a rede virtual em particular. Você também aprenderá por que nós, desenvolvedores do serviço, apreciamos o feedback de nossos usuários. Mas as primeiras coisas primeiro.



O que é uma VPC?


Atualmente, para a implantação de serviços, existem diversas oportunidades. Tenho certeza de que alguém ainda mantém o servidor sob a mesa do administrador, embora, espero, haja cada vez menos histórias desse tipo.

Agora, os serviços estão tentando entrar em nuvens públicas e, aqui, eles enfrentam a VPC. A VPC é uma parte da nuvem pública que conecta usuário, infraestrutura, plataforma e outras capacidades, onde quer que estejam, em nossa nuvem ou além. Ao mesmo tempo, o VPC permite não colocar desnecessariamente essas capacidades na Internet, elas permanecem na sua rede isolada.

Como uma rede virtual se parece de fora




Por VPC, entendemos principalmente a rede de sobreposição e os serviços de rede, como VPNaaS, NATaas, LBaas, etc. E tudo isso funciona em cima da infraestrutura de rede à prova de falhas, sobre a qual já havia um excelente artigo aqui em Habré.

Vejamos a rede virtual e seu dispositivo mais de perto.



Considere duas zonas de acessibilidade. Nós fornecemos uma rede virtual - o que chamamos de VPC. De fato, ele define o espaço exclusivo dos seus endereços "cinza". Dentro de cada rede virtual, você controla completamente o espaço de endereço que pode ser atribuído aos recursos de computação.

A rede é global. Ao mesmo tempo, ele é projetado em cada uma das zonas de acesso na forma de uma entidade chamada Sub-rede. Para cada sub-rede, você atribui um certo CIDR de tamanho 16 ou menos. Pode haver mais de uma entidade em cada zona de disponibilidade, enquanto sempre há roteamento transparente entre elas. Isso significa que todos os seus recursos na mesma VPC podem "se comunicar" entre si, mesmo que estejam em zonas de acesso diferentes. "Comunicar" sem acesso à Internet, através de nossos canais internos, "pensando" que eles estão dentro da mesma rede privada.

O diagrama acima mostra uma situação típica: duas VPCs que se cruzam em algum lugar nos endereços. Ambos podem pertencer a você. Por exemplo, um para desenvolvimento, outro para teste. Pode haver simplesmente usuários diferentes - nesse caso, isso não importa. E uma máquina virtual está presa em cada VPC.



Composto o esquema. Você pode transformar uma máquina virtual em várias sub-redes ao mesmo tempo. E não apenas assim, mas em diferentes redes virtuais.



Ao mesmo tempo, se você precisar colocar carros na Internet, isso pode ser feito através da API ou da interface do usuário. Para fazer isso, você precisa configurar a tradução NAT do seu "cinza", endereço interno, para "branco" - público. Você não pode selecionar um endereço "branco"; ele é atribuído aleatoriamente em nosso pool de endereços. Assim que você parar de usar o IP externo, ele retornará ao pool. Você paga apenas pelo tempo em que usa o endereço "branco".



Também é possível conceder à máquina acesso à Internet usando uma instância NAT. Em uma instância, você pode obter tráfego através de uma tabela de roteamento estática. Fornecemos esse caso, porque os usuários precisam e sabemos disso. Assim, em nosso catálogo de imagens, encontra-se uma imagem NAT especialmente configurada.



Mas mesmo quando há uma imagem NAT pronta, a configuração pode ser complicada. Percebemos que para alguns usuários essa não é a opção mais conveniente; portanto, no final, tornamos possível incluir o NAT da sub-rede desejada em um clique. Esse recurso ainda está em acesso de visualização privado, onde é agregado com a ajuda de membros da comunidade.

Como uma rede virtual funciona de dentro para fora





Como um usuário interage com uma rede virtual? A rede parece externa com sua API. O usuário acessa a API e trabalha com o estado de destino. Por meio da API, o usuário vê como tudo deve ser organizado e configurado, enquanto vê o status de quanto o estado real difere do desejado. Esta é uma imagem do usuário. O que está acontecendo lá dentro?

Registramos o estado desejado no Yandex Database e vamos configurar diferentes partes do nosso VPC. A rede de sobreposição no Yandex.Cloud é construída com base em componentes selecionados do OpenContrail, que recentemente foi chamado de tecido de tungstênio. Os serviços de rede são implementados em uma única plataforma CloudGate. No CloudGate, também usamos vários componentes de código aberto: GoBGP - para acessar informações de controle e VPP - para implementar um roteador de software que trabalha no DPDK para o caminho de dados.

O tecido de tungstênio se comunica com o CloudGate por meio do GoBGP. Diz o que acontece na rede de sobreposição. O CloudGate, por sua vez, conecta redes de sobreposição entre si e com a Internet.



Agora vamos ver como uma rede virtual lida com escalabilidade e disponibilidade. Considere um caso simples. Há uma zona de disponibilidade e duas VPCs são criadas nela. Implantamos uma instância do Tungsten Fabric, que gera dezenas de milhares de redes. As redes se comunicam com o CloudGate. O CloudGate, como dissemos, garante a conectividade entre si e com a Internet.



Suponha que uma segunda zona de acessibilidade seja adicionada. Ele deve falhar completamente independentemente do primeiro. Portanto, na segunda zona de acesso, precisamos entregar uma instância separada do Tungsten Fabric. Este será um sistema separado que lida com sobreposições e sabe pouco sobre o primeiro sistema. E a aparência de que nossa rede virtual é global, de fato, cria nossa API VPC. Essa é a tarefa dele.

A VPC1 é projetada na zona de acesso B se houver recursos na zona de acesso B que aderem à VPC1. Se não houver recursos do VPC2 na zona de acesso B, não iremos materializar o VPC2 nessa zona. Por sua vez, como os recursos do VPC3 existem apenas na zona B, o VPC3 não está na zona A. Tudo é simples e lógico.

Vamos um pouco mais fundo e ver como um host específico é organizado no Y. Cloud. O principal que quero observar é que todos os hosts são organizados da mesma maneira. Fazemos com que apenas o mínimo necessário de serviços gire no hardware, e todo o resto funcione em máquinas virtuais. Construímos serviços de ordem superior baseados em serviços básicos de infraestrutura e também usamos a nuvem para resolver alguns problemas de engenharia, por exemplo, como parte da integração contínua.



Se olharmos para um host específico, veremos que três componentes estão girando no sistema operacional host:
  • A computação é a parte responsável pela distribuição dos recursos de computação no host.
  • O VRouter faz parte do tecido de tungstênio que organiza a sobreposição, ou seja, encapsula pacotes através da subjacência.
  • VDisk são peças de virtualização de armazenamento.

Além disso, foram lançados serviços em máquinas virtuais: serviços de infraestrutura em nuvem, serviços de plataforma e recursos do cliente. Os recursos do cliente e os serviços de plataforma sempre se sobrepõem ao VRouter.

Os serviços de infraestrutura podem aderir à sobreposição, mas basicamente eles querem trabalhar na sobreposição. Eles estão presos em uma base por meio do SR-IOV. De fato, cortamos a placa em placas de rede virtuais (funções virtuais) e as colocamos em máquinas virtuais de infraestrutura para não perder desempenho. Por exemplo, o mesmo CloudGate é lançado como uma dessas máquinas virtuais de infraestrutura.

Agora que descrevemos as tarefas globais da rede virtual e a organização dos componentes básicos da nuvem, vamos ver como exatamente as diferentes partes da rede virtual interagem umas com as outras.

Distinguimos três camadas em nosso sistema:
  • Plano de configuração - define o estado de destino do sistema. É isso que o usuário configura por meio da API.
  • Plano de controle - fornece semântica definida pelo usuário, ou seja, leva o estado do plano de dados ao que foi descrito pelo usuário no plano de configuração.
  • Data Plane - processa diretamente os pacotes do usuário.



Como eu disse acima, tudo começa com o fato de um usuário ou um serviço de plataforma interna chegar à API e descrever um estado de destino específico.

Esse estado é imediatamente registrado no banco de dados Yandex, retorna o ID da operação assíncrona por meio da API e inicia nossa maquinaria interna para retornar o estado desejado pelo usuário. As tarefas de configuração vão para o controlador SDN e informam ao Tungsten Fabric o que fazer na sobreposição. Por exemplo, eles reservam portas, redes virtuais e similares.



O plano de configuração no tecido de tungstênio envia o estado necessário para o plano de controle. Por meio dele, o Config Plane se comunica com os hosts, informando o que os tornará no futuro próximo.



Agora vamos ver como é o sistema nos hosts. Na máquina virtual, há um determinado adaptador de rede preso no VRouter. O VRouter é um módulo principal de tecido de tungstênio que analisa pacotes. Se já houver fluxo para algum pacote, o módulo o processará. Se não houver fluxo, o módulo executa o chamado punting, ou seja, envia o pacote para o processo no modo de usuário. O processo analisa o pacote e responde a ele próprio, como, por exemplo, ao DHCP e DNS, ou diz ao VRouter o que fazer com ele. Depois disso, o VRouter pode processar o pacote.

Além disso, o tráfego entre máquinas virtuais na mesma rede virtual é executado de forma transparente, não sendo direcionado ao CloudGate. Os hosts nos quais as máquinas virtuais são implantadas se comunicam diretamente entre si. Eles encapsulam o tráfego e o encaminham um ao outro através do underlay.



O plano de controle se comunica entre as zonas de acesso BGP, como com outro roteador. Eles informam quais máquinas são criadas, para que as máquinas virtuais em uma zona possam interagir diretamente com outras máquinas virtuais.



Além disso, o Control Plane se comunica com o CloudGate. Da mesma forma, informa onde e quais máquinas virtuais são criadas, quais são seus endereços. Isso permite direcionar o tráfego externo e o tráfego dos balanceadores para eles.

O tráfego que sai da VPC chega ao CloudGate, no caminho dos dados, onde o VPP é rapidamente mastigado com nossos plugins. Em seguida, o tráfego é disparado em outras VPCs ou nos roteadores de borda configurados pelo Control Plane do CloudGate.

Planos para o futuro próximo


Se resumirmos tudo isso em várias frases, podemos dizer que a VPC no Yandex.Cloud resolve duas tarefas importantes:

  • Fornece isolamento entre diferentes clientes.
  • Combina recursos, infraestrutura, serviços de plataforma, outras nuvens e no local em uma única rede.

E para resolver bem esses problemas, você precisa fornecer escalabilidade e tolerância a falhas no nível da arquitetura interna, o que a VPC faz.

A VPC está gradualmente adquirindo funções, estamos percebendo novas oportunidades, tentando melhorar algo em termos de conveniência do usuário. Algumas idéias são expressas e caem na lista de prioridades, graças aos membros da nossa comunidade.

Agora, temos aproximadamente a seguinte lista de planos para o futuro próximo:

  • VPN como um serviço.
  • Private DNS – DNS-.
  • DNS .
  • .
  • «» IP- .

O balanceador e a capacidade de alternar o endereço IP da máquina virtual já criada estavam nesta lista a pedido dos usuários. Francamente, sem feedback explícito, assumiríamos essas funções um pouco mais tarde. E, portanto, já estamos trabalhando em uma tarefa sobre endereços.

Inicialmente, um endereço IP “branco” só poderia ser adicionado ao criar a máquina. Se o usuário esqueceu de fazer isso, a máquina virtual precisou ser recriada. A mesma coisa e, se necessário, remova o IP externo. Em breve, será possível ativar e desativar o IP público sem recriar a máquina.

Sinta-se livre para expressar suas idéias e apoiar as sugestões de outros usuários. Você nos ajuda a melhorar a nuvem e obter recursos importantes e úteis mais rapidamente!

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles