Olá, meu nome é Kostya Kramlich, sou o desenvolvedor líder da divisão Virtual Private Cloud da Yandex.Cloud. Estou trabalhando em uma rede virtual e, como você pode imaginar, neste artigo falarei sobre o dispositivo Virtual Private Cloud (VPC) em geral e a rede virtual em particular. E você também descobrirá por que nós, desenvolvedores de serviços, valorizamos o feedback de nossos usuários. Mas primeiro as primeiras coisas.
O que é VPC?
Hoje em dia, existem diversas opções para implantação de serviços. Tenho certeza de que alguém ainda mantém um servidor sob a mesa do administrador, embora eu espere que essas histórias estejam se tornando cada vez menos comuns.
Agora os serviços estão tentando migrar para nuvens públicas e é aqui que encontram VPCs. VPC é uma parte da nuvem pública que une usuário, infraestrutura, plataforma e outras capacidades, onde quer que estejam, em nossa nuvem ou fora dela. Ao mesmo tempo, o VPC permite que você não exponha desnecessariamente essas capacidades à Internet; elas permanecem dentro da sua rede isolada.
Qual é a aparência de uma rede virtual vista de fora
Por VPC queremos dizer, em primeiro lugar, uma rede sobreposta e serviços de rede, como VPNaaS, NATaas, LBaas, etc. E tudo isso funciona em cima de uma infraestrutura de rede tolerante a falhas, que já foi discutida aqui em Habré.
Vamos dar uma olhada mais de perto na rede virtual e em sua estrutura.
Vejamos duas zonas de disponibilidade. Fornecemos uma rede virtual – o que chamamos de VPC. Na verdade, ele define o espaço de exclusividade dos seus endereços “cinza”. Dentro de cada rede virtual, você tem controle total sobre o espaço de endereços que pode atribuir aos recursos de computação.
A rede é global. Ao mesmo tempo, é projetado em cada uma das zonas de disponibilidade na forma de uma entidade denominada Sub-rede. Para cada sub-rede você atribui um CIDR de tamanho 16 ou menos. Cada zona de disponibilidade pode ter mais de uma dessas entidades e sempre há roteamento transparente entre elas. Isso significa que todos os seus recursos dentro da mesma VPC podem “conversar” entre si, mesmo que estejam em zonas de disponibilidade diferentes. “Comunicar-se” sem acesso à Internet, através dos nossos canais internos, “pensando” que estão dentro da mesma rede privada.
O diagrama acima mostra uma situação típica: duas VPCs que se cruzam em algum lugar de seus endereços. Ambos podem ser seus. Por exemplo, um para desenvolvimento e outro para teste. Pode haver simplesmente usuários diferentes - neste caso, não importa. E cada VPC possui uma máquina virtual.
Vamos piorar o esquema. Você pode fazer com que uma máquina virtual se conecte a várias sub-redes ao mesmo tempo. E não só assim, mas em diferentes redes virtuais.
Ao mesmo tempo, se você precisar expor máquinas na Internet, isso pode ser feito através da API ou UI. Para fazer isso, você precisa configurar a tradução NAT do seu endereço interno “cinza” para um endereço público “branco”. Você não pode escolher um endereço “branco”; ele é atribuído aleatoriamente em nosso conjunto de endereços. Assim que você parar de usar o IP externo, ele retornará ao pool. Você paga apenas pelo tempo de uso do endereço “branco”.
Também é possível dar acesso à Internet à máquina usando uma instância NAT. Você pode rotear o tráfego para sua instância por meio de uma tabela de roteamento estático. Fornecemos esse caso porque os usuários às vezes precisam dele e sabemos disso. Assim, em nosso diretório de imagens existe uma imagem NAT especialmente configurada.
Mas mesmo quando existe uma imagem NAT pronta, a configuração pode ser complexa. Entendemos que para alguns usuários esta não é a opção mais conveniente, então no final tornamos possível habilitar o NAT para a sub-rede desejada com um clique. Este recurso ainda está em acesso de visualização fechado, onde está sendo testado com a ajuda de membros da comunidade.
Como funciona uma rede virtual por dentro
Como um usuário interage com uma rede virtual? A rede olha para fora com sua API. O usuário acessa a API e trabalha com o estado de destino. Através da API, o usuário vê como tudo deve ser organizado e configurado, enquanto vê o status, como o estado real difere do desejado. Esta é a foto do usuário. O que está acontecendo lá dentro?
Registramos o estado desejado no banco de dados Yandex 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 Tungsten Fabric. 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 lidar com informações de controle, bem como VPP para implementar um roteador de software rodando sobre DPDK para o caminho de dados.
O Tungsten Fabric se comunica com o CloudGate via GoBGP. Informa o que está acontecendo na rede de sobreposição. O CloudGate, por sua vez, conecta redes sobrepostas entre si e à Internet.
Agora vamos ver como uma rede virtual resolve problemas de escalabilidade e disponibilidade. Vamos considerar um caso simples. Há uma zona de disponibilidade e duas VPCs foram criadas nela. Implantamos uma instância do Tungsten Fabric e ela contém dezenas de milhares de redes. As redes se comunicam com o CloudGate. CloudGate, como já dissemos, garante a conectividade entre si e com a Internet.
Digamos que uma segunda zona de disponibilidade seja adicionada. Deve falhar de forma completamente independente do primeiro. Portanto, devemos instalar uma instância separada do Tungsten Fabric na segunda zona de disponibilidade. Este será um sistema separado que lidará com a sobreposição e saberá pouco sobre o primeiro sistema. E a aparência de que nossa rede virtual é global, na verdade, cria nossa API VPC. Esta é a sua tarefa.
A VPC1 será mapeada para a zona de disponibilidade B se a zona de disponibilidade B tiver recursos que permanecem na VPC1. Se não houver recursos da VPC2 na zona de disponibilidade B, não materializamos a VPC2 nesta zona. Por sua vez, como os recursos do VPC3 existem apenas na zona B, o VPC3 não existe na zona A. Tudo é simples e lógico.
Vamos nos aprofundar um pouco mais e ver como funciona um host específico no Y.Cloud. A principal coisa que gostaria de observar é que todos os hosts são projetados da mesma forma. Garantimos que apenas o mínimo necessário de serviços seja executado em hardware; todo o restante seja executado em máquinas virtuais. Construímos serviços de alto nível 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, podemos ver que existem três componentes em execução no sistema operacional host:
- Compute é a parte responsável pela distribuição dos recursos computacionais no host.
- O VRouter faz parte do Tungsten Fabric, que organiza o overlay, ou seja, encapsula pacotes através do underlay.
- VDisks são peças de virtualização de armazenamento.
Além disso, as máquinas virtuais executam serviços: serviços de infraestrutura em nuvem, serviços de plataforma e capacidade do cliente. As capacidades e serviços da plataforma dos clientes vão sempre para a sobreposição via VRouter.
Os serviços de infraestrutura podem ser conectados à sobreposição, mas principalmente desejam trabalhar na base. Eles são presos na base usando SR-IOV. Na verdade, cortamos o cartão 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 de uma rede virtual e o design dos componentes básicos da nuvem, vamos ver como exatamente as diferentes partes da rede virtual interagem entre si.
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 especificada pelo usuário, ou seja, traz o estado do Plano de Dados para o que foi descrito pelo usuário no Plano de Configuração.
- Plano de dados – processa diretamente os pacotes do usuário.
Como eu disse acima, tudo começa com o usuário ou serviço interno da plataforma acessando a API e descrevendo um determinado estado de destino.
Esse estado é imediatamente gravado no banco de dados Yandex, retorna o ID da operação assíncrona por meio da API e inicia nosso mecanismo interno para produzir o estado desejado pelo usuário. As tarefas de configuração vão para o controlador SDN e informam ao Tungsten Fabric o que precisa ser feito na sobreposição. Por exemplo, eles reservam portas, redes virtuais e assim por diante.
O Config Plane no Tungsten Fabric carrega o estado necessário para o Control Plane. Através dele, o Config Plane se comunica com os hosts, informando-lhes o que exatamente estará rodando neles em um futuro próximo.
Agora vamos ver como fica o sistema nos hosts. A máquina virtual possui um determinado adaptador de rede conectado ao VRouter. VRouter é um módulo principal do Tungsten Fabric que analisa pacotes. Se já existe um fluxo para algum pacote, o módulo o processa. Se não houver fluxo, o módulo faz o chamado punting, ou seja, envia o pacote para o processo usermod. O processo analisa o pacote e responde a ele sozinho, como DHCP e DNS, ou informa ao VRouter o que fazer com ele. O VRouter pode então processar o pacote.
Além disso, o tráfego entre máquinas virtuais dentro da mesma rede virtual flui de forma transparente e não é enviado ao CloudGate. Os hosts nos quais as máquinas virtuais são implementadas comunicam-se diretamente entre si. Eles encapsulam o tráfego e o encaminham entre si por meio da base.
Os planos de controle se comunicam entre si através das zonas de disponibilidade via BGP, assim como acontece com outro roteador. Eles informam quais máquinas estão instaladas e onde, para que as máquinas virtuais em uma zona possam se comunicar diretamente com outras máquinas virtuais.
O Control Plane também se comunica com o CloudGate. Da mesma forma, informa onde e quais máquinas virtuais estão instaladas, 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 do VPC chega ao CloudGate, no caminho de dados, onde o VPP com nossos plugins é rapidamente mastigado. Em seguida, o tráfego é direcionado para outras VPCs ou para fora, para roteadores de borda, que são configurados através do Plano de Controle do próprio CloudGate.
Planos para o futuro próximo
Se resumirmos tudo o que foi dito acima em algumas frases, podemos dizer que o VPC no Yandex.Cloud resolve dois problemas importantes:
- Fornece isolamento entre diferentes clientes.
- Une recursos, infraestrutura, serviços de plataforma, outras nuvens e locais em uma única rede.
E para resolver bem esses problemas, é preciso garantir escalabilidade e tolerância a falhas no nível da arquitetura interna, que é o que o VPC faz.
Aos poucos o VPC vai adquirindo funções, estamos implementando novas funcionalidades e tentando melhorar algo em termos de comodidade para os usuários. Algumas ideias são expressas e incluídas 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 serviço.
- Instâncias DNS privadas – imagens para configurar rapidamente máquinas virtuais com um servidor DNS pré-configurado.
- DNS como serviço.
- Balanceador de carga interno.
- Adicionar um endereço IP “branco” sem recriar a máquina virtual.
Um balanceador e a capacidade de alternar o endereço IP para uma máquina virtual já criada foram incluídos nesta lista a pedido dos usuários. Para ser honesto, sem feedback explícito teríamos assumido essas funções um pouco mais tarde. E então já estamos trabalhando no problema dos endereços.
Inicialmente, um endereço IP “branco” só poderia ser adicionado ao criar uma máquina. Caso o usuário se esquecesse de fazer isso, a máquina virtual teria que ser recriada. O mesmo vale para remover o IP externo, se necessário. Em breve será possível ligar e desligar um IP público sem precisar recriar a máquina.
Sinta-se à vontade para expressar o seu outros usuários. Você nos ajuda a melhorar a nuvem e a obter recursos importantes e úteis com mais rapidez!
Fonte: habr.com