{"id":39304,"date":"2019-10-31T22:29:40","date_gmt":"2019-10-31T19:29:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti\/"},"modified":"2019-10-31T22:29:40","modified_gmt":"2019-10-31T19:29:40","slug":"kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","title":{"rendered":"Como a AWS \"cozinha\" seus servi\u00e7os el\u00e1sticos. Escalonamento de rede","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A escala da Amazon Web Services \u00e9 de 69 zonas ao redor do mundo em 22 regi\u00f5es: EUA, Europa, \u00c1sia, \u00c1frica e Austr\u00e1lia. Cada zona tem at\u00e9 8 CDPs \u2014 Centros de Processamento de Dados. Em cada CDP, h\u00e1 milhares ou centenas de milhares de servidores. A rede \u00e9 constru\u00edda de forma que todos os cen\u00e1rios improv\u00e1veis de falhas sejam considerados. Por exemplo, todas as regi\u00f5es s\u00e3o isoladas umas das outras, e as zonas de disponibilidade est\u00e3o a v\u00e1rias quil\u00f4metros de dist\u00e2ncia. Mesmo que um cabo seja cortado, o sistema alternar\u00e1 para canais de backup, e as perdas de informa\u00e7\u00e3o ser\u00e3o de apenas algumas unidades de pacotes de dados. Sobre quais outros princ\u00edpios a rede \u00e9 constru\u00edda e como ela funciona, contar\u00e1 Vasily Pantyukhin.<\/p>\n

\"Como
\n
\nVasily Pantyukhin<\/b> come\u00e7ou como administrador Unix em empresas .ru, trabalhou 6 anos com grandes equipamentos da Sun Microsystem, e 11 anos pregou a centralidade de dados no mundo na EMC. Evoluiu naturalmente para nuvens privadas e depois migrou para as p\u00fablicas. Agora, como arquiteto da Amazon Web Services, oferece conselhos t\u00e9cnicos para viver e se desenvolver na nuvem da AWS.<\/p>\n

Na parte anterior da trilogia sobre a estrutura da AWS, Vasily se aprofundou na constru\u00e7\u00e3o de servidores f\u00edsicos e no escalonamento de bancos de dados. As placas Nitro, o hipervisor personalizado baseado em KVM, o banco de dados Amazon Aurora \u2014 tudo isso no material \"Como a AWS 'prepara' seus servi\u00e7os el\u00e1sticos. Escalabilidade de servidores e bancos de dados<\/a><\/noindex>\". Leia para mergulhar no contexto, ou assista a grava\u00e7\u00e3o em v\u00eddeo<\/a><\/noindex> palestras.<\/p>\n

Nesta parte, falaremos sobre o escalonamento da rede \u2014 um dos sistemas mais complexos da AWS. A evolu\u00e7\u00e3o de uma rede plana para uma Virtual Private Cloud e sua estrutura, os servi\u00e7os internos Blackfoot e HyperPlane, o problema do vizinho barulhento, e, no final, as dimens\u00f5es da rede, backbone e cabos f\u00edsicos. Tudo isso abaixo.<\/p>\n

Aviso: tudo que est\u00e1 abaixo \u00e9 opini\u00e3o pessoal de Vasily e pode n\u00e3o coincidir com a posi\u00e7\u00e3o da Amazon Web Services.<\/i>
\n<\/a><\/noindex><\/p>\n

Escalonamento de rede<\/h2>\n

\nA nuvem da AWS foi lan\u00e7ada em 2006. Sua rede era bastante primitiva \u2014 com uma estrutura plana. O intervalo de endere\u00e7os privados era comum para todos os inquilinos da nuvem. Ao iniciar uma nova m\u00e1quina virtual, voc\u00ea recebia, por acaso, um endere\u00e7o IP dispon\u00edvel desse intervalo.<\/p>\n

\"Como
\n
\nEssa abordagem foi f\u00e1cil de implementar, mas limitava fundamentalmente o uso da nuvem. Em particular, era bastante dif\u00edcil desenvolver solu\u00e7\u00f5es h\u00edbridas que combinassem redes privadas locais com a AWS. O problema mais comum era a sobreposi\u00e7\u00e3o dos intervalos de endere\u00e7os IP.<\/p>\n

\"Como
\n<\/p>\n

Nuvem Privada Virtual<\/h3>\n

\nA nuvem se tornou popular. Chegou a hora de considerar a escalabilidade e a possibilidade de uso por dezenas de milh\u00f5es de inquilinos. A rede plana tornou-se o principal obst\u00e1culo. Por isso, pensamos em como isolar usu\u00e1rios uns dos outros em n\u00edvel de rede, garantindo que pudessem escolher seus pr\u00f3prios intervalos de IP.<\/p>\n

\"Como
\n
\nO que vem \u00e0 mente quando voc\u00ea pensa em isolamento de rede? Claro VLAN<\/b> e VRF \u2014 Encaminhamento e Comuta\u00e7\u00e3o Virtual<\/b>.<\/p>\n

Infelizmente, isso n\u00e3o funcionou. O ID do VLAN \u00e9 composto por apenas 12 bits, o que nos proporciona apenas 4096 segmentos isolados. Mesmo nos maiores switches, podemos utilizar no m\u00e1ximo 1-2 mil VRFs. O compartilhamento de VRF e VLAN nos fornece apenas alguns milh\u00f5es de sub-redes. Isso \u00e9 definitivamente insuficiente para dezenas de milh\u00f5es de inquilinos, cada um dos quais deve ter a possibilidade de usar v\u00e1rias sub-redes.<\/p>\n

Al\u00e9m disso, simplesmente n\u00e3o podemos nos dar ao luxo de comprar a quantidade necess\u00e1ria de grandes dispositivos, por exemplo, da Cisco ou da Juniper. Existem duas raz\u00f5es: \u00e9 extremamente caro, e n\u00e3o queremos depender da pol\u00edtica de desenvolvimento e atualiza\u00e7\u00e3o deles.<\/p>\n

A conclus\u00e3o \u00e9 clara \u2013 precisamos criar nossa pr\u00f3pria solu\u00e7\u00e3o.<\/p><\/blockquote>\n

\nEm 2009, anunciamos VPC<\/b> \u2014 Nuvem Privada Virtual<\/b>. O nome pegou e agora muitos provedores de nuvem tamb\u00e9m o utilizam.<\/p>\n

VPC \u2013 \u00e9 uma rede virtual SDN<\/b> (Rede Definida por Software). Decidimos n\u00e3o inventar protocolos especiais nos n\u00edveis L2 e L3. A rede opera em Ethernet e IP padr\u00e3o. Para a transmiss\u00e3o na rede, o tr\u00e1fego das m\u00e1quinas virtuais \u00e9 encapsulado em uma estrutura do nosso pr\u00f3prio protocolo. Nela \u00e9 especificado um ID que pertence ao inquilino do VPC.<\/p>\n

\"Como
\n
\nParece simples. No entanto, \u00e9 preciso resolver v\u00e1rias quest\u00f5es t\u00e9cnicas s\u00e9rias. Por exemplo, onde e como armazenar os dados de mapeamento de endere\u00e7os MAC\/IP virtuais, ID do VPC e os respectivos endere\u00e7os MAC\/IP f\u00edsicos. Em escala da AWS, temos uma enorme tabela que deve operar com lat\u00eancias m\u00ednimas de acesso. Isso \u00e9 responsabilidade do servi\u00e7o de mapeamento<\/b>, que \u00e9 distribu\u00eddo por toda a rede.<\/p>\n

Nos carros da nova gera\u00e7\u00e3o, a encapsula\u00e7\u00e3o \u00e9 realizada por meio de placas Nitro a n\u00edvel de hardware. Em inst\u00e2ncias mais antigas, a encapsula\u00e7\u00e3o e desencapsula\u00e7\u00e3o s\u00e3o feitas de forma program\u00e1tica.\u00a0<\/p>\n

\"Como
\n
\nVamos entender como isso funciona de forma geral. Come\u00e7aremos pelo n\u00edvel L2. Suponha que temos uma m\u00e1quina virtual com o IP 10.0.0.2 em um servidor f\u00edsico 192.168.0.3. Ela envia dados para uma m\u00e1quina virtual 10.0.0.3, que reside em 192.168.1.4. Um pedido ARP \u00e9 gerado, que chega \u00e0 placa de rede Nitro. Para simplificar, vamos considerar que ambas as m\u00e1quinas virtuais est\u00e3o na mesma VPC \"azul\".<\/p>\n

\"Como
\n
\nA placa substitui o endere\u00e7o de origem pelo seu pr\u00f3prio e reencaminha o quadro ARP para o servi\u00e7o de mapeamento.<\/p>\n

\"Como
\n
\nO servi\u00e7o de mapeamento retorna as informa\u00e7\u00f5es necess\u00e1rias para a transmiss\u00e3o pela rede f\u00edsica L2.<\/p>\n

\"Como
\n
\nA placa Nitro, na resposta ARP, substitui o MAC na rede f\u00edsica pelo endere\u00e7o na VPC.<\/p>\n

\"Como
\n
\nAo transmitir dados, envolvemos os MAC e IP l\u00f3gicos em um inv\u00f3lucro da VPC. Tudo isso \u00e9 enviado pela rede f\u00edsica com o uso dos IPs apropriados das placas Nitro de origem e destino.<\/p>\n

\"Como
\n
\nA m\u00e1quina f\u00edsica para a qual o pacote \u00e9 destinado faz uma verifica\u00e7\u00e3o. Isso \u00e9 necess\u00e1rio para evitar a possibilidade de falsifica\u00e7\u00e3o de endere\u00e7os. A m\u00e1quina envia um pedido especial ao servi\u00e7o de mapeamento e pergunta: \"Da m\u00e1quina f\u00edsica 192.168.0.3, eu recebi um pacote destinado a 10.0.0.3 na VPC 'azul'. Ele \u00e9 leg\u00edtimo?\"\u00a0<\/p>\n

\"Como
\n
\nO servi\u00e7o de mapeamento confere sua tabela de aloca\u00e7\u00e3o de recursos e permite ou nega a passagem do pacote. Em todas as novas inst\u00e2ncias, uma valida\u00e7\u00e3o adicional \u00e9 incorporada nas placas Nitro. N\u00e3o \u00e9 poss\u00edvel contorn\u00e1-la, nem mesmo teoricamente. Portanto, a falsifica\u00e7\u00e3o de recursos em outra VPC n\u00e3o funcionar\u00e1.<\/p>\n

\"Como
\n
\nEm seguida, os dados s\u00e3o enviados para a m\u00e1quina virtual para a qual foram destinados.\u00a0<\/p>\n

\"Como
\n
\nO servi\u00e7o de mapeamento tamb\u00e9m atua como um roteador l\u00f3gico para a transmiss\u00e3o de dados entre m\u00e1quinas virtuais em diferentes sub-redes. Conceitualmente, tudo \u00e9 simples, n\u00e3o entrarei em detalhes.<\/p>\n

\"Como
\n
\nAssim, ao transmitir cada pacote, os servidores consultam o servi\u00e7o de mapeamento. Como lidar com as inevit\u00e1veis lat\u00eancias? Com cache.<\/b>, claro.<\/p>\n

Toda a beleza est\u00e1 no fato de que n\u00e3o \u00e9 necess\u00e1rio armazenar em cache toda a tabela enorme. Em um servidor f\u00edsico vivem m\u00e1quinas virtuais a partir de uma quantidade relativamente pequena de VPCs. \u00c9 preciso armazenar em cache apenas as informa\u00e7\u00f5es sobre esses VPCs. A transmiss\u00e3o de dados para outros VPCs na configura\u00e7\u00e3o \"padr\u00e3o\" ainda n\u00e3o \u00e9 leg\u00edtima. Se se utiliza funcionalidade como VPC-peering, ent\u00e3o as informa\u00e7\u00f5es sobre os VPCs correspondentes s\u00e3o carregadas adicionalmente no cache.\u00a0<\/p>\n

\"Como
\n
\nResolvemos a transmiss\u00e3o de dados em VPC.<\/p>\n

Blackfoot<\/h3>\n

\nComo agir em situa\u00e7\u00f5es em que o tr\u00e1fego precisa ser transmitido para fora, por exemplo, para a Internet ou atrav\u00e9s de VPN para a terra? Aqui somos salvos pelo Blackfoot<\/b> \u2014 servi\u00e7o interno da AWS. Ele foi desenvolvido pela nossa equipe da \u00c1frica do Sul. Por isso, o servi\u00e7o \u00e9 nomeado em homenagem a um pinguim que vive na \u00c1frica do Sul.<\/p>\n

\"Como
\n
\nBlackfoot descapsula o tr\u00e1fego e faz com ele o que \u00e9 necess\u00e1rio. Os dados s\u00e3o enviados para a Internet como est\u00e3o.<\/p>\n

\"Como
\n
\nOs dados s\u00e3o descapsulados e recobertos com a prote\u00e7\u00e3o IPsec ao usar VPN.<\/p>\n

\"Como
\n
\nAo usar Direct Connect, o tr\u00e1fego \u00e9 etiquetado e transmitido para o VLAN correspondente.<\/p>\n

\"Como
\n<\/p>\n

HyperPlane<\/h3>\n

\nEste \u00e9 um servi\u00e7o interno de controle de fluxo. Muitos servi\u00e7os de rede exigem controle do estado do fluxo de dados<\/b>. Por exemplo, ao usar NAT, o controle de fluxo deve garantir que cada par \"IP: porta de destino\" corresponda a uma porta de sa\u00edda \u00fanica. No caso do balanceador NLB<\/b> \u2014 Network Load Balancer<\/b>, o fluxo de dados deve sempre ser direcionado para a mesma m\u00e1quina virtual de destino. Os Grupos de Seguran\u00e7a s\u00e3o um firewall com estado. Ele monitora o tr\u00e1fego de entrada e abre implicitamente as portas para o fluxo de pacotes de sa\u00edda.<\/p>\n

\"Como
\n
\nNa nuvem AWS, as exig\u00eancias de lat\u00eancia de transmiss\u00e3o s\u00e3o extremamente altas. Portanto, HyperPlane<\/b> \u00e9 cr\u00edtico para a opera\u00e7\u00e3o de toda a rede.<\/p>\n

\"Como
\n
\nHyperplane \u00e9 constru\u00eddo em m\u00e1quinas virtuais EC2. N\u00e3o h\u00e1 m\u00e1gica aqui, apenas ast\u00facia. A ast\u00facia est\u00e1 no fato de que s\u00e3o m\u00e1quinas virtuais com grande RAM. As opera\u00e7\u00f5es s\u00e3o transacionais e realizadas exclusivamente na mem\u00f3ria. Isso permite alcan\u00e7ar lat\u00eancias de apenas dezenas de microssegundos. Trabalhar com disco arruinaria toda a performance.\u00a0<\/p>\n

Hyperplane \u00e9 um sistema distribu\u00eddo de um enorme n\u00famero dessas m\u00e1quinas EC2. Cada m\u00e1quina virtual tem uma largura de banda de 5 GB\/s. Em toda a rede regional, isso proporciona uma largura de banda esmagadora de terabits e permite processar milh\u00f5es de conex\u00f5es por segundo.<\/b>.<\/p>\n

HyperPlane funciona apenas com fluxos. A encapsula\u00e7\u00e3o de pacotes pelo VPC \u00e9 completamente transparente para ele. Uma vulnerabilidade potencial neste servi\u00e7o interno ainda assim n\u00e3o permitir\u00e1 romper a isola\u00e7\u00e3o do VPC. A seguran\u00e7a \u00e9 responsabilidade dos n\u00edveis inferiores.<\/p>\n

vizinho barulhento<\/h3>\n

\nH\u00e1 mais um problema vizinho barulhento<\/b> \u2014 vizinho barulhento<\/b>. Vamos supor que temos 8 n\u00f3s. Esses n\u00f3s processam os fluxos de todos os usu\u00e1rios da nuvem. Parece que tudo est\u00e1 bem e a carga deve ser distribu\u00edda uniformemente entre todos os n\u00f3s. Os n\u00f3s s\u00e3o muito potentes e \u00e9 dif\u00edcil sobrecarreg\u00e1-los.<\/p>\n

Mas estamos construindo nossa arquitetura levando em conta at\u00e9 mesmo os cen\u00e1rios menos prov\u00e1veis.\u00a0<\/p>\n

Uma baixa probabilidade n\u00e3o significa impossibilidade.<\/p><\/blockquote>\n

\nPodemos imaginar uma situa\u00e7\u00e3o em que um ou v\u00e1rios usu\u00e1rios geram uma carga muito alta. Todos os n\u00f3s HyperPlane est\u00e3o envolvidos no processamento dessa carga, e outros usu\u00e1rios podem potencialmente sentir alguma diminui\u00e7\u00e3o no desempenho. Isso destr\u00f3i o conceito de nuvem, onde os locat\u00e1rios n\u00e3o t\u00eam como influenciar uns aos outros.<\/p>\n

\"Como
\n
\nComo resolver o problema do vizinho barulhento? A primeira coisa que vem \u00e0 mente \u00e9 o sharding. Nossos 8 n\u00f3s s\u00e3o logicamente divididos em 4 shards com 2 n\u00f3s cada. Agora, o vizinho barulhento afetar\u00e1 apenas um quarto de todos os usu\u00e1rios, mas de forma significativa.<\/p>\n

\"Como
\n
\nVamos agir de forma diferente. Atribuiremos apenas 3 n\u00f3s para cada usu\u00e1rio.\u00a0<\/p>\n

\"Como
\n
\nA sacada \u00e9 designar n\u00f3s para diferentes usu\u00e1rios aleatoriamente. Na imagem abaixo, o usu\u00e1rio azul se sobrep\u00f5e a um dos outros dois usu\u00e1rios \u2014 o verde e o laranja.<\/p>\n

\"Como
\n
\nCom 8 n\u00f3s e 3 usu\u00e1rios, a probabilidade de sobreposi\u00e7\u00e3o de um vizinho barulhento com um dos usu\u00e1rios \u00e9 de 54%. \u00c9 com essa probabilidade que o usu\u00e1rio azul influenciar\u00e1 outros locat\u00e1rios. E isso s\u00f3 com parte da sua carga. No nosso exemplo, essa influ\u00eancia ser\u00e1 notada apenas por um ter\u00e7o de todos os usu\u00e1rios. Esse j\u00e1 \u00e9 um bom resultado.<\/p>\n

O n\u00famero de usu\u00e1rios que se sobrepor\u00e3o<\/p>\n

Probabilidade em porcentagem<\/p>\n

0<\/p>\n

18%<\/p>\n

1<\/p>\n

54%<\/p>\n

2<\/p>\n

26%<\/p>\n

3<\/p>\n

2%<\/p>\n

Aproximando a situa\u00e7\u00e3o da realidade \u2014 vamos considerar 100 n\u00f3s e 5 usu\u00e1rios em 5 n\u00f3s. Nesse caso, nenhuma das n\u00f3s se sobrepor\u00e1 com uma probabilidade de 77%.\u00a0<\/p>\n

O n\u00famero de usu\u00e1rios que se sobrepor\u00e3o<\/p>\n

Probabilidade em porcentagem<\/p>\n

0<\/p>\n

77%<\/p>\n

1<\/p>\n

21%<\/p>\n

2<\/p>\n

1,8%<\/p>\n

3<\/p>\n

0,06%<\/p>\n

4<\/p>\n

0,0006%<\/p>\n

5<\/p>\n

0,00000013%<\/p>\n

Na situa\u00e7\u00e3o real, com um grande n\u00famero de n\u00f3s HyperPlane e usu\u00e1rios, o impacto potencial do vizinho barulhento sobre outros usu\u00e1rios \u00e9 m\u00ednimo. Esse m\u00e9todo \u00e9 chamado de sharding com mistura<\/b> \u2014 shuffle sharding<\/b>. Isso minimiza o efeito negativo da falha de n\u00f3s.<\/p>\n

Muitos servi\u00e7os s\u00e3o constru\u00eddos sobre a base do HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n

Escala da rede<\/h3>\n

\nAgora vamos falar sobre a escala da pr\u00f3pria rede. Em outubro de 2019, a AWS oferece seus servi\u00e7os em 22 regi\u00f5es<\/b>, e mais 9 est\u00e3o planejadas.<\/p>\n