![\"Como](\"\/wp-content\/uploads\/2020\/02\/62b3d222c1911fb28a345defdd81135c.jpeg\")
<\/p>\nOl\u00e1, meu nome \u00e9 Kostya Kramlih, sou o principal desenvolvedor da divis\u00e3o de Virtual Private Cloud no Yandex.Cloud. Eu trabalho com redes virtuais e, como voc\u00ea pode imaginar, neste artigo vou falar sobre a estrutura do Virtual Private Cloud (VPC) em geral e da rede virtual em particular. Al\u00e9m disso, voc\u00ea descobrir\u00e1 por que n\u00f3s, desenvolvedores do servi\u00e7o, valorizamos o feedback de nossos usu\u00e1rios. Mas, vamos por partes.<\/p>\n
<\/p>\n
<\/a><\/p>\n Hoje em dia, existem v\u00e1rias op\u00e7\u00f5es para implantar servi\u00e7os. Tenho certeza de que alguns ainda mant\u00eam um servidor embaixo da mesa do administrador, embora, espero, que essas hist\u00f3rias estejam se tornando cada vez mais raras.<\/p>\n Atualmente, os servi\u00e7os est\u00e3o migrando para nuvens p\u00fablicas, e \u00e9 aqui que eles se deparam com o VPC. O VPC \u00e9 uma parte da nuvem p\u00fablica que conecta recursos de usu\u00e1rios, infraestrutura, plataformas e outros de forma integrada, independentemente de onde estejam, em nossa nuvem ou fora dela. O VPC permite que esses recursos n\u00e3o sejam expostos \u00e0 Internet sem necessidade, permanecendo dentro da sua rede isolada.<\/p>\n Por VPC, entendemos, primeiro de tudo, uma rede overlay e servi\u00e7os de rede, como VPNaaS, NATaas, LBaas, etc. E tudo isso opera sobre uma infraestrutura de rede robusta, da qual j\u00e1 falamos em uma \u00f3tima mat\u00e9ria<\/a> aqui mesmo, no Habr.<\/p>\n Vamos dar uma olhada mais de perto na rede virtual e sua estrutura.<\/p>\n Vamos considerar duas zonas de disponibilidade. N\u00f3s fornecemos uma rede virtual \u2013 o que chamamos de VPC. De fato, ela define o espa\u00e7o de exclusividade dos seus endere\u00e7os \"cinzas\". Dentro de cada rede virtual, voc\u00ea tem controle total sobre o espa\u00e7o de endere\u00e7os que pode atribuir aos recursos computacionais.<\/p>\n A rede \u00e9 global. Ela se projeta em cada uma das zonas de disponibilidade na forma de uma entidade chamada Subnet. Para cada Subnet, voc\u00ea 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\u00e9s de nossos canais internos, \"pensando\" que est\u00e3o dentro de uma \u00fanica rede privada.<\/p>\n No esquema acima, \u00e9 mostrada uma situa\u00e7\u00e3o t\u00edpica: duas VPCs que se cruzam em algum lugar nos endere\u00e7os. Ambas podem pertencer a voc\u00ea. Por exemplo, uma para desenvolvimento e outra para teste. Podem ser apenas usu\u00e1rios diferentes \u2013 nesse caso, n\u00e3o importa. E em cada VPC, est\u00e1 conectada uma m\u00e1quina virtual.<\/p>\n Vamos complicar o esquema. \u00c9 poss\u00edvel fazer com que uma m\u00e1quina virtual se conecte a v\u00e1rias Subnets de uma vez. E n\u00e3o apenas isso, mas em diferentes redes virtuais.<\/p>\n Se voc\u00ea precisar expor as m\u00e1quinas para a internet, isso pode ser feito atrav\u00e9s da API ou da interface do usu\u00e1rio. Para isso, \u00e9 necess\u00e1rio configurar a tradu\u00e7\u00e3o NAT do seu endere\u00e7o \"cinza\", interno, para um \"branco\" \u2013 p\u00fablico. Voc\u00ea n\u00e3o pode escolher o endere\u00e7o \"branco\", ele \u00e9 atribu\u00eddo aleatoriamente do nosso pool de endere\u00e7os. Assim que voc\u00ea para de usar o IP externo, ele retorna ao pool. Voc\u00ea paga apenas pelo tempo de uso do endere\u00e7o \"branco\".<\/p>\n Tamb\u00e9m existe a possibilidade de fornecer acesso \u00e0 internet para uma m\u00e1quina atrav\u00e9s de uma inst\u00e2ncia NAT. O tr\u00e1fego pode ser roteado para a inst\u00e2ncia atrav\u00e9s de uma tabela de roteamento est\u00e1tica. N\u00f3s previmos esse caso, porque sabemos que pode ser necess\u00e1rio para alguns usu\u00e1rios. Assim, em nosso cat\u00e1logo de imagens, temos uma imagem NAT especialmente configurada.<\/p>\n Mas mesmo quando h\u00e1 uma imagem NAT pronta, a configura\u00e7\u00e3o pode ser complicada. N\u00f3s entendemos que para alguns usu\u00e1rios essa n\u00e3o \u00e9 a op\u00e7\u00e3o mais conveniente, portanto, acabamos implementando a possibilidade de ativar o NAT para a Subnet desejada em um clique. Este recurso ainda est\u00e1 em acesso preview fechado, sendo testado com a ajuda dos participantes da comunidade.<\/p>\n Como o usu\u00e1rio interage com a rede virtual? A rede se comunica externamente por meio da sua API. O usu\u00e1rio acessa a API e trabalha com o estado desejado. Atrav\u00e9s da API, o usu\u00e1rio v\u00ea como tudo deve ser configurado e ajustado, enquanto observa o status, em que medida o estado real difere do desejado. Essa \u00e9 a perspectiva do usu\u00e1rio. E o que acontece internamente?<\/p>\n Registramos o estado desejado no Yandex Database e come\u00e7amos a configurar diferentes partes da nossa VPC. A rede overlay na Yandex.Cloud \u00e9 constru\u00edda com base em componentes selecionados do OpenContrail, que recentemente passou a se chamar Tungsten Fabric. Os servi\u00e7os de rede s\u00e3o implementados em uma plataforma \u00fanica chamada CloudGate. No CloudGate, tamb\u00e9m utilizamos alguns componentes de c\u00f3digo aberto: GoBGP \u2013 para a consulta de informa\u00e7\u00f5es de controle, e VPP \u2013 para a implementa\u00e7\u00e3o de um roteador program\u00e1tico operando sobre DPDK para o caminho de dados.<\/p>\n Tungsten Fabric se comunica com o CloudGate atrav\u00e9s do GoBGP. Ele informa o que acontece na rede overlay. O CloudGate, por sua vez, conecta as redes overlays entre si e \u00e0 internet.<\/p>\n 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\u00e2ncia do Tungsten Fabric, que abrange v\u00e1rias dezenas de milhares de redes. As redes se conectam ao CloudGate. O CloudGate, como j\u00e1 mencionamos, garante a conectividade entre elas e com a internet.<\/p>\n 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\u00e2ncia separada do Tungsten Fabric. Esta ser\u00e1 uma sistema distinta, encarregada do overlay e que pouco sabe sobre o primeiro sistema. E a visibilidade de que nossa rede virtual \u00e9 global \u00e9, na verdade, criada pela nossa API da VPC. Essa \u00e9 sua fun\u00e7\u00e3o.<\/p>\n A VPC1 \u00e9 projetada na zona de disponibilidade B, se na zona de disponibilidade B existem recursos que se conectam \u00e0 VPC1. Se n\u00e3o h\u00e1 recursos da VPC2 na zona de disponibilidade B, n\u00e3o materializamos a VPC2 nessa zona. Por sua vez, como os recursos da VPC3 existem apenas na zona B, a VPC3 n\u00e3o est\u00e1 na zona A. \u00c9 tudo simples e l\u00f3gico.<\/p>\n Vamos nos aprofundar um pouco mais e ver como um host espec\u00edfico no Y.Cloud \u00e9 configurado. O principal a destacar \u00e9 que todos os hosts s\u00e3o constru\u00eddos da mesma forma. Fazemos com que o m\u00ednimo necess\u00e1rio de servi\u00e7os opere no hardware, enquanto todos os outros funcionam em m\u00e1quinas virtuais<\/a>. Constru\u00edmos servi\u00e7os de n\u00edvel superior com base em servi\u00e7os de infraestrutura b\u00e1sicos e tamb\u00e9m usamos a Nuvem para resolver algumas tarefas de engenharia, como parte da Integra\u00e7\u00e3o Cont\u00ednua.<\/p>\n Se olharmos para um host espec\u00edfico, veremos que tr\u00eas componentes est\u00e3o operando no sistema operacional do host:<\/p>\n Al\u00e9m disso, em m\u00e1quinas virtuais<\/a> est\u00e3o em execu\u00e7\u00e3o servi\u00e7os: servi\u00e7os de infraestrutura da Nuvem, servi\u00e7os de plataforma e recursos de clientes. Os recursos dos clientes e os servi\u00e7os de plataforma sempre operam no overlay atrav\u00e9s do VRouter.<\/p>\n Os servi\u00e7os 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\u00e1tica, cortamos o cart\u00e3o em cart\u00f5es de rede virtuais (fun\u00e7\u00f5es virtuais) e os inserimos em m\u00e1quinas virtuais de infraestrutura para n\u00e3o perder desempenho. Por exemplo, aquele CloudGate est\u00e1 em execu\u00e7\u00e3o como uma dessas m\u00e1quinas virtuais de infraestrutura.<\/p>\n Agora que descrevemos as fun\u00e7\u00f5es globais da rede virtual e a estrutura dos componentes b\u00e1sicos da nuvem, vamos ver como diferentes partes da rede virtual interagem entre si.<\/p>\n Identificamos em nosso sistema tr\u00eas camadas:<\/p>\n Como mencionei anteriormente, tudo come\u00e7a quando o usu\u00e1rio ou um servi\u00e7o de plataforma interno acessa a API e descreve um determinado estado-alvo.<\/p>\n Esse estado \u00e9 imediatamente registrado no Yandex Database, retorna atrav\u00e9s da API o ID da opera\u00e7\u00e3o ass\u00edncrona e aciona nossa maquinaria interna para fornecer o estado que o usu\u00e1rio desejava. As tarefas de configura\u00e7\u00e3o v\u00e3o 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.<\/p>\n O Config Plane no Tungsten Fabric entrega ao Control Plane o estado necess\u00e1rio. Atrav\u00e9s dele, o Config Plane se comunica com os hosts, informando o que exatamente ser\u00e1 executado em breve.<\/p>\n Agora vamos ver como o sistema aparece nos hosts. Em m\u00e1quina virtual<\/a> h\u00e1 um adaptador de rede conectado ao VRouter. O VRouter \u00e9 um m\u00f3dulo central do Tungsten Fabric que observa os pacotes. Se para um determinado pacote j\u00e1 existe um fluxo, o m\u00f3dulo o processa. Se n\u00e3o existe fluxo, o m\u00f3dulo realiza o chamado punting, ou seja, envia o pacote para o processo em modo usu\u00e1rio. 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.<\/p>\n Al\u00e9m disso, o tr\u00e1fego entre m\u00e1quinas virtuais dentro de uma mesma rede virtual flui de forma transparente, n\u00e3o sendo direcionado para o CloudGate. Os hosts onde as m\u00e1quinas virtuais est\u00e3o implantadas comunicam-se entre si diretamente. Eles encapsulam o tr\u00e1fego e o encaminham uns para os outros atrav\u00e9s do underlay.<\/p>\n O Control Plane se comunica entre si entre zonas de disponibilidade atrav\u00e9s do BGP, como se fosse outro roteador. Eles informam quais m\u00e1quinas est\u00e3o onde para que as m\u00e1quinas virtuais em uma zona possam interagir diretamente com outras m\u00e1quinas virtuais.<\/p>\n Al\u00e9m disso, o Control Plane se comunica com o CloudGate. Da mesma forma, informa onde e quais m\u00e1quinas virtuais est\u00e3o dispon\u00edveis e quais s\u00e3o seus endere\u00e7os. Isso permite direcionar o tr\u00e1fego externo e o tr\u00e1fego dos balanceadores para elas.<\/p>\n O tr\u00e1fego que sai do VPC chega ao CloudGate, no data path, onde \u00e9 rapidamente processado pelo VPP com nossos plugins. Em seguida, o tr\u00e1fego \u00e9 enviado para outros VPCs ou para fora, para os roteadores de borda que s\u00e3o configurados atrav\u00e9s do Control Plane do pr\u00f3prio CloudGate.<\/p>\n Se resumirmos tudo o que foi dito acima em algumas frases, podemos afirmar que o VPC no Yandex.Cloud resolve duas tarefas importantes:<\/p>\n E para resolver essas quest\u00f5es de forma eficaz, \u00e9 necess\u00e1rio garantir escalabilidade e resili\u00eancia no n\u00edvel da arquitetura interna, o que o VPC faz.<\/p>\n Gradualmente, o VPC est\u00e1 sendo aprimorado com novas funcionalidades, estamos implementando novas oportunidades e nos esfor\u00e7ando para melhorar a experi\u00eancia do usu\u00e1rio. Algumas ideias s\u00e3o mencionadas e entram em nossa lista de prioridades gra\u00e7as aos participantes de nossa comunidade.<\/p>\n Atualmente, temos aproximadamente a seguinte lista de planos para o futuro pr\u00f3ximo:<\/p>\n O balanceador e a possibilidade de alternar o endere\u00e7o IP para uma m\u00e1quina virtual j\u00e1 criada estavam nessa lista a pedido dos usu\u00e1rios. Para ser honesto, sem feedback claro, levar\u00edamos algum tempo para trabalhar nessas funcionalidades. Assim, j\u00e1 estamos trabalhando na quest\u00e3o dos endere\u00e7os.<\/p>\n Inicialmente, o endere\u00e7o IP 'branco' s\u00f3 poderia ser adicionado ao criar a m\u00e1quina. Se o usu\u00e1rio esquecesse de fazer isso, a m\u00e1quina virtual tinha que ser recriada. O mesmo se aplicava quando era necess\u00e1rio remover o IP externo. Em breve, ser\u00e1 poss\u00edvel ligar e desligar o IP p\u00fablico sem recriar a m\u00e1quina.<\/p>\n N\u00e3o hesite em expressar suas ideias e apoiar as sugest\u00f5es<\/a> de outros usu\u00e1rios. Voc\u00ea nos ajuda a tornar a Nuvem melhor e a obter funcionalidades importantes e \u00fateis mais rapidamente!<\/p>\nO que \u00e9 VPC?<\/h2>\n
Como a rede virtual parece do exterior<\/h2>\n
![\"Como](\"\/wp-content\/uploads\/2020\/02\/073a0cbac0e733decd8a4e6ffd9570ff.jpeg\")
<\/p>\n![\"Como](\"\/wp-content\/uploads\/2020\/02\/b1b7a15912f9c7995663ab9943d473f1.jpeg\")
<\/p>\n![\"Como](\"\/wp-content\/uploads\/2020\/02\/73e872a4f6c3e19576db4e4980d62a45.jpeg\")
<\/p>\n![\"Como](\"\/wp-content\/uploads\/2020\/02\/cc4ab2c7553d63ef2636924df1575479.jpeg\")
<\/p>\n![\"Como](\"\/wp-content\/uploads\/2020\/02\/c2375fd6d0fb7b55ca55787adf505229.jpeg\")
<\/p>\n![\"Como](\"\/wp-content\/uploads\/2020\/02\/744ac3bdd2f388bab2597d6fe1519d76.jpeg\")
<\/p>\nComo a rede virtual \u00e9 estruturada internamente<\/h2>\n
![\"Como](\"\/wp-content\/uploads\/2020\/02\/71cab3ae7f067f165a87e30c60559794.jpeg\")
<\/p>\n![\"Como](\"\/wp-content\/uploads\/2020\/02\/222d68fff4b9577f316c8642e846172e.jpeg\")
<\/p>\n![\"Como](\"\/wp-content\/uploads\/2020\/02\/4da02ba041dcd886eee212dd8998718c.jpeg\")
<\/p>\n![\"Como](\"\/wp-content\/uploads\/2020\/02\/4664bd03793ba394ceda1f8214fa2c16.jpeg\")
<\/p>\n\n
\n
![\"Como](\"\/wp-content\/uploads\/2020\/02\/644cddfa8bce83a501bf4788a21f9588.jpeg\")
<\/p>\n![\"Como](\"\/wp-content\/uploads\/2020\/02\/c2c6e443c93f8dedc6a63e4bd3fd7042.jpeg\")
<\/p>\n![\"Como](\"\/wp-content\/uploads\/2020\/02\/2139361a9e1837c7bc7f156e8bc36d38.jpeg\")
<\/p>\n![\"Como](\"\/wp-content\/uploads\/2020\/02\/1247f20fa2a12f093d7f1d2361d48a02.jpeg\")
<\/p>\n![\"Como](\"\/wp-content\/uploads\/2020\/02\/f70cd562220c7367e29597d8e8b62f81.jpeg\")
<\/p>\nPlanos para o futuro pr\u00f3ximo<\/h2>\n
\n
\n