Olá, meu nome é Kostya Kramlih, sou o principal desenvolvedor da divisão de Virtual Private Cloud no Yandex.Cloud. Eu trabalho com redes virtuais e, como você pode imaginar, neste artigo vou falar sobre a estrutura do Virtual Private Cloud (VPC) em geral e da rede virtual em particular. Além disso, você descobrirá por que nós, desenvolvedores do serviço, valorizamos o feedback de nossos usuários. Mas, vamos por partes.
O que é VPC?
Hoje em dia, existem várias opções para implantar serviços. Tenho certeza de que alguns ainda mantêm um servidor embaixo da mesa do administrador, embora, espero, que essas histórias estejam se tornando cada vez mais raras.
Atualmente, os serviços estão migrando para nuvens públicas, e é aqui que eles se deparam com o VPC. O VPC é uma parte da nuvem pública que conecta recursos de usuários, infraestrutura, plataformas e outros de forma integrada, independentemente de onde estejam, em nossa nuvem ou fora dela. O VPC permite que esses recursos não sejam expostos à Internet sem necessidade, permanecendo dentro da sua rede isolada.
Como a rede virtual parece do exterior
Por VPC, entendemos, primeiro de tudo, uma rede overlay e serviços de rede, como VPNaaS, NATaas, LBaas, etc. E tudo isso opera sobre uma infraestrutura de rede robusta, da qual já falamos em uma ótima matéria aqui mesmo, no Habr.
Vamos dar uma olhada mais de perto na rede virtual e sua estrutura.
Vamos considerar duas zonas de disponibilidade. Nós fornecemos uma rede virtual – o que chamamos de VPC. De fato, ela define o espaço de exclusividade dos seus endereços "cinzas". Dentro de cada rede virtual, você tem controle total sobre o espaço de endereços que pode atribuir aos recursos computacionais.
A rede é global. Ela se projeta em cada uma das zonas de disponibilidade na forma de uma entidade chamada Subnet. Para cada Subnet, você atribui um CIDR de tamanho 16 ou menor. Em cada zona de disponibilidade, pode haver mais de uma dessas entidades, e entre elas sempre existe um roteamento transparente. Isso significa que todos os seus recursos dentro de uma VPC podem "comunicar-se" entre si, mesmo que estejam em diferentes zonas de disponibilidade. "Comunicar-se" sem ir para a internet, através de nossos canais internos, "pensando" que estão dentro de uma única rede privada.
No esquema acima, é mostrada uma situação típica: duas VPCs que se cruzam em algum lugar nos endereços. Ambas podem pertencer a você. Por exemplo, uma para desenvolvimento e outra para teste. Podem ser apenas usuários diferentes – nesse caso, não importa. E em cada VPC, está conectada uma máquina virtual.
Vamos complicar o esquema. É possível fazer com que uma máquina virtual se conecte a várias Subnets de uma vez. E não apenas isso, mas em diferentes redes virtuais.
Se você precisar expor as máquinas para a internet, isso pode ser feito através da API ou da interface do usuário. Para isso, é necessário configurar a tradução NAT do seu endereço "cinza", interno, para um "branco" – público. Você não pode escolher o endereço "branco", ele é atribuído aleatoriamente do nosso pool de endereços. Assim que você para de usar o IP externo, ele retorna ao pool. Você paga apenas pelo tempo de uso do endereço "branco".
Também existe a possibilidade de fornecer acesso à internet para uma máquina através de uma instância NAT. O tráfego pode ser roteado para a instância através de uma tabela de roteamento estática. Nós previmos esse caso, porque sabemos que pode ser necessário para alguns usuários. Assim, em nosso catálogo de imagens, temos uma imagem NAT especialmente configurada.
Mas mesmo quando há uma imagem NAT pronta, a configuração pode ser complicada. Nós entendemos que para alguns usuários essa não é a opção mais conveniente, portanto, acabamos implementando a possibilidade de ativar o NAT para a Subnet desejada em um clique. Este recurso ainda está em acesso preview fechado, sendo testado com a ajuda dos participantes da comunidade.
Como a rede virtual é estruturada internamente
Como o usuário interage com a rede virtual? A rede se comunica externamente por meio da sua API. O usuário acessa a API e trabalha com o estado desejado. Através da API, o usuário vê como tudo deve ser configurado e ajustado, enquanto observa o status, em que medida o estado real difere do desejado. Essa é a perspectiva do usuário. E o que acontece internamente?
Registramos o estado desejado no Yandex Database e começamos a configurar diferentes partes da nossa VPC. A rede overlay na Yandex.Cloud é construída com base em componentes selecionados do OpenContrail, que recentemente passou a se chamar Tungsten Fabric. Os serviços de rede são implementados em uma plataforma única chamada CloudGate. No CloudGate, também utilizamos alguns componentes de código aberto: GoBGP – para a consulta de informações de controle, e VPP – para a implementação de um roteador programático operando sobre DPDK para o caminho de dados.
Tungsten Fabric se comunica com o CloudGate através do GoBGP. Ele informa o que acontece na rede overlay. O CloudGate, por sua vez, conecta as redes overlays entre si e à internet.
Agora, vamos ver como a rede virtual resolve problemas de escalabilidade e disponibilidade. Consideremos um caso simples. Temos uma zona de disponibilidade e nela foram criadas duas VPCs. Implantamos uma instância do Tungsten Fabric, que abrange várias dezenas de milhares de redes. As redes se conectam ao CloudGate. O CloudGate, como já mencionamos, garante a conectividade entre elas e com a internet.
Vamos supor que uma segunda zona de disponibilidade seja adicionada. Ela deve falhar completamente de forma independente da primeira. Portanto, na segunda zona de disponibilidade, precisamos instalar uma instância separada do Tungsten Fabric. Esta será uma sistema distinta, encarregada do overlay e que pouco sabe sobre o primeiro sistema. E a visibilidade de que nossa rede virtual é global é, na verdade, criada pela nossa API da VPC. Essa é sua função.
A VPC1 é projetada na zona de disponibilidade B, se na zona de disponibilidade B existem recursos que se conectam à VPC1. Se não há recursos da VPC2 na zona de disponibilidade B, não materializamos a VPC2 nessa zona. Por sua vez, como os recursos da VPC3 existem apenas na zona B, a VPC3 não está na zona A. É tudo simples e lógico.
Vamos nos aprofundar um pouco mais e ver como um host específico no Y.Cloud é configurado. O principal a destacar é que todos os hosts são construídos da mesma forma. Fazemos com que o mínimo necessário de serviços opere no hardware, enquanto todos os outros funcionam em máquinas virtuais. Construímos serviços de nível superior com base em serviços de infraestrutura básicos e também usamos a Nuvem para resolver algumas tarefas de engenharia, como parte da Integração Contínua.
Se olharmos para um host específico, veremos que três componentes estão operando no sistema operacional do host:
- Compute – a parte responsável pela distribuição de recursos computacionais no host.
- VRouter – parte do Tungsten Fabric que organiza o overlay, ou seja, tuneliza pacotes através do underlay.
- VDisk – são pedaços de virtualização de armazenamento.
Além disso, em máquinas virtuais estão em execução serviços: serviços de infraestrutura da Nuvem, serviços de plataforma e recursos de clientes. Os recursos dos clientes e os serviços de plataforma sempre operam no overlay através do VRouter.
Os serviços de infraestrutura podem estar conectados ao overlay, mas geralmente preferem operar no underlay. No underlay, eles se conectam por meio do SR-IOV. Na prática, cortamos o cartão em cartões de rede virtuais (funções virtuais) e os inserimos em máquinas virtuais de infraestrutura para não perder desempenho. Por exemplo, aquele CloudGate está em execução como uma dessas máquinas virtuais de infraestrutura.
Agora que descrevemos as funções globais da rede virtual e a estrutura dos componentes básicos da nuvem, vamos ver como diferentes partes da rede virtual interagem entre si.
Identificamos em nosso sistema três camadas:
- Config Plane – define o estado-alvo do sistema. É o que o usuário configura através da API.
- Control Plane – garante a semântica definida pelo usuário, ou seja, torna o estado do Data Plane o que foi descrito pelo usuário no Config Plane.
- Data Plane – processa diretamente os pacotes do usuário.
Como mencionei anteriormente, tudo começa quando o usuário ou um serviço de plataforma interno acessa a API e descreve um determinado estado-alvo.
Esse estado é imediatamente registrado no Yandex Database, retorna através da API o ID da operação assíncrona e aciona nossa maquinaria interna para fornecer o estado que o usuário desejava. As tarefas de configuração vão para o controlador SDN e informam ao Tungsten Fabric o que precisa ser feito no overlay. Por exemplo, elas reservam portas, redes virtuais e assim por diante.
O Config Plane no Tungsten Fabric entrega ao Control Plane o estado necessário. Através dele, o Config Plane se comunica com os hosts, informando o que exatamente será executado em breve.
Agora vamos ver como o sistema aparece nos hosts. Em máquina virtual há um adaptador de rede conectado ao VRouter. O VRouter é um módulo central do Tungsten Fabric que observa os pacotes. Se para um determinado pacote já existe um fluxo, o módulo o processa. Se não existe fluxo, o módulo realiza o chamado punting, ou seja, envia o pacote para o processo em modo usuário. O processo analisa o pacote e responde a ele diretamente, como, por exemplo, no caso de 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 dentro de uma mesma rede virtual flui de forma transparente, não sendo direcionado para o CloudGate. Os hosts onde as máquinas virtuais estão implantadas comunicam-se entre si diretamente. Eles encapsulam o tráfego e o encaminham uns para os outros através do underlay.
O Control Plane se comunica entre si entre zonas de disponibilidade através do BGP, como se fosse outro roteador. Eles informam quais máquinas estão onde 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 estão disponíveis e quais são seus endereços. Isso permite direcionar o tráfego externo e o tráfego dos balanceadores para elas.
O tráfego que sai do VPC chega ao CloudGate, no data path, onde é rapidamente processado pelo VPP com nossos plugins. Em seguida, o tráfego é enviado para outros VPCs ou para fora, para os roteadores de borda que são configurados através do Control Plane do próprio CloudGate.
Planos para o futuro próximo
Se resumirmos tudo o que foi dito acima em algumas frases, podemos afirmar que o VPC no Yandex.Cloud resolve duas tarefas importantes:
- Fornece isolamento entre diferentes clientes.
- Integra recursos, infraestrutura, serviços em plataforma, outras nuvens e on-premise em uma única rede.
E para resolver essas questões de forma eficaz, é necessário garantir escalabilidade e resiliência no nível da arquitetura interna, o que o VPC faz.
Gradualmente, o VPC está sendo aprimorado com novas funcionalidades, estamos implementando novas oportunidades e nos esforçando para melhorar a experiência do usuário. Algumas ideias são mencionadas e entram em nossa lista de prioridades graças aos participantes de nossa comunidade.
Atualmente, temos aproximadamente a seguinte lista de planos para o futuro próximo:
- VPN como um serviço.
- Instâncias de DNS privado – imagens para configuração rápida de máquinas virtuais com servidor DNS pré-configurado.
- DNS como um serviço.
- Balanceador de carga interno.
- Adicionar um endereço IP 'branco' sem recriar a máquina virtual.
O balanceador e a possibilidade de alternar o endereço IP para uma máquina virtual já criada estavam nessa lista a pedido dos usuários. Para ser honesto, sem feedback claro, levaríamos algum tempo para trabalhar nessas funcionalidades. Assim, já estamos trabalhando na questão dos endereços.
Inicialmente, o endereço IP 'branco' só poderia ser adicionado ao criar a máquina. Se o usuário esquecesse de fazer isso, a máquina virtual tinha que ser recriada. O mesmo se aplicava quando era necessário remover o IP externo. Em breve, será possível ligar e desligar o IP público sem recriar a máquina.
Não hesite em expressar suas ideias e apoiar as sugestões de outros usuários. Você nos ajuda a tornar a Nuvem melhor e a obter funcionalidades importantes e úteis mais rapidamente!
Fonte: habr.com
