A escala da rede Amazon Web Services é de 69 zonas ao redor do mundo em 22 regiões: EUA, Europa, Ásia, África e Austrália. Cada zona contém até 8 data centers - Centros de Processamento de Dados. Cada data center possui milhares ou centenas de milhares de servidores. A rede é projetada de forma que todos os cenários improváveis de interrupção sejam levados em consideração. Por exemplo, todas as regiões estão isoladas umas das outras e as zonas de acessibilidade estão separadas por distâncias de vários quilómetros. Mesmo se você cortar o cabo, o sistema mudará para canais de backup e a perda de informações equivalerá a alguns pacotes de dados. Vasily Pantyukhin falará sobre quais outros princípios a rede é construída e como ela está estruturada.
Vasily Pantyukhin começou como administrador Unix em empresas .ru, trabalhou em grandes hardwares da Sun Microsystem por 6 anos e pregou um mundo centrado em dados por 11 anos na EMC. Naturalmente evoluiu para nuvens privadas e depois mudou para nuvens públicas. Agora, como arquiteto da Amazon Web Services, ele fornece consultoria técnica para ajudar a viver e desenvolver na nuvem AWS.
Na parte anterior da trilogia AWS, Vasily se aprofundou no design de servidores físicos e no dimensionamento de banco de dados. Cartões Nitro, hipervisor personalizado baseado em KVM, banco de dados Amazon Aurora - sobre tudo isso no material "" Leia para contextualizar ou assista discursos.
Esta parte se concentrará no dimensionamento de rede, um dos sistemas mais complexos da AWS. A evolução de uma rede plana para uma Nuvem Privada Virtual e seu design, serviços internos do Blackfoot e HyperPlane, o problema de um vizinho barulhento e, no final - a escala da rede, backbone e cabos físicos. Sobre tudo isso sob o corte.
Isenção de responsabilidade: tudo abaixo é a opinião pessoal de Vasily e pode não coincidir com a posição da Amazon Web Services.
Dimensionamento de rede
A nuvem AWS foi lançada em 2006. Sua rede era bastante primitiva – com uma estrutura plana. A gama de endereços privados era comum a todos os inquilinos da nuvem. Ao iniciar uma nova máquina virtual, você recebeu acidentalmente um endereço IP disponível nesse intervalo.
Esta abordagem foi fácil de implementar, mas limitou fundamentalmente o uso da nuvem. Em particular, foi bastante difícil desenvolver soluções híbridas que combinassem redes privadas no terreno e na AWS. O problema mais comum era a sobreposição de intervalos de endereços IP.
Nuvem privada virtual
A nuvem acabou sendo muito procurada. Chegou a hora de pensar na escalabilidade e na possibilidade de sua utilização por dezenas de milhões de inquilinos. A rede plana tornou-se um grande obstáculo. Portanto, pensamos em como isolar os usuários uns dos outros no nível da rede para que eles pudessem escolher independentemente os intervalos de IP.
Qual é a primeira coisa que vem à mente quando você pensa em isolamento de rede? Certamente VLAN и VRF - Roteamento e encaminhamento virtual.
Infelizmente, não funcionou. O ID da VLAN tem apenas 12 bits, o que nos dá apenas 4096 segmentos isolados. Mesmo os maiores switches podem usar no máximo 1 a 2 mil VRFs. Usar VRF e VLAN juntos nos dá apenas alguns milhões de sub-redes. Definitivamente, isso não é suficiente para dezenas de milhões de locatários, cada um dos quais deve ser capaz de usar múltiplas sub-redes.
Também não podemos simplesmente comprar o número necessário de caixas grandes, por exemplo, da Cisco ou da Juniper. Há duas razões: é absurdamente caro e não queremos ficar à mercê de suas políticas de desenvolvimento e correção.
Há apenas uma conclusão: faça sua própria solução.
Em 2009 anunciamos VPC - Nuvem privada virtual. O nome pegou e agora muitos provedores de nuvem também o utilizam.
VPC é uma rede virtual SDN (Rede definida por software). Decidimos não inventar protocolos especiais nos níveis L2 e L3. A rede funciona em Ethernet e IP padrão. Para transmissão pela rede, o tráfego da máquina virtual é encapsulado em nosso próprio wrapper de protocolo. Indica o ID que pertence à VPC do locatário.
Parece simples. No entanto, existem vários desafios técnicos sérios que precisam ser superados. Por exemplo, onde e como armazenar dados sobre mapeamento de endereços MAC/IP virtuais, ID de VPC e MAC/IP físico correspondente. Na escala AWS, esta é uma tabela enorme que deve funcionar com atrasos mínimos de acesso. Responsável por isso serviço de mapeamento, que se espalha em uma camada fina por toda a rede.
Nas máquinas de nova geração, o encapsulamento é realizado por placas Nitro no nível do hardware. Em casos mais antigos, o encapsulamento e o desencapsulamento são baseados em software.
Vamos descobrir como isso funciona em termos gerais. Vamos começar com o nível L2. Vamos supor que temos uma máquina virtual com IP 10.0.0.2 em um servidor físico 192.168.0.3. Ele envia dados para a máquina virtual 10.0.0.3, que reside em 192.168.1.4. Uma solicitação ARP é gerada e enviada para a placa Nitro da rede. Para simplificar, presumimos que ambas as máquinas virtuais residam na mesma VPC “azul”.
O mapa substitui o endereço de origem pelo seu próprio e encaminha o quadro ARP para o serviço de mapeamento.
O serviço de mapeamento retorna informações necessárias para transmissão pela rede física L2.
A placa Nitro na resposta ARP substitui o MAC na rede física por um endereço no VPC.
Ao transferir dados, envolvemos MAC e IP lógicos em um wrapper VPC. Transmitimos tudo isso pela rede física usando as placas IP Nitro de origem e destino apropriadas.
A máquina física à qual o pacote se destina realiza a verificação. Isto é necessário para evitar a possibilidade de falsificação de endereço. A máquina envia uma solicitação especial ao serviço de mapeamento e pergunta: “Da máquina física 192.168.0.3 recebi um pacote destinado a 10.0.0.3 na VPC azul. Ele é legítimo?
O serviço de mapeamento verifica sua tabela de alocação de recursos e permite ou nega a passagem do pacote. Em todas as novas instâncias, validação adicional está incorporada nos cartões Nitro. É impossível contorná-lo, mesmo teoricamente. Portanto, a falsificação de recursos em outra VPC não funcionará.
Em seguida, os dados são enviados para a máquina virtual a que se destinam.
O serviço de mapeamento também funciona como um roteador lógico para transferência de dados entre máquinas virtuais em diferentes sub-redes. Tudo é conceitualmente simples, não vou entrar em detalhes.
Acontece que ao transmitir cada pacote, os servidores recorrem ao serviço de mapeamento. Como lidar com atrasos inevitáveis? Cache, claro.
A beleza é que você não precisa armazenar em cache toda a enorme mesa. Um servidor físico hospeda máquinas virtuais de um número relativamente pequeno de VPCs. Você só precisa armazenar em cache informações sobre essas VPCs. A transferência de dados para outras VPCs na configuração “padrão” ainda não é legítima. Se funcionalidades como peering de VPC forem usadas, as informações sobre as VPCs correspondentes serão carregadas adicionalmente no cache.
Resolvemos a transferência de dados para o VPC.
Blackfoot
O que fazer nos casos em que o tráfego precisa ser transmitido para fora, por exemplo para a Internet ou via VPN para o solo? Nos ajuda aqui Blackfoot — Serviço interno da AWS. É desenvolvido pela nossa equipe sul-africana. É por isso que o serviço leva o nome de um pinguim que vive na África do Sul.
Blackfoot desencapsula o tráfego e faz o que for necessário com ele. Os dados são enviados para a Internet como estão.
Os dados são desencapsulados e reagrupados em IPsec ao usar uma VPN.
Ao usar o Direct Connect, o tráfego é marcado e enviado para a VLAN apropriada.
Hiperplano
Este é um serviço de controle de fluxo interno. Muitos serviços de rede requerem monitoramento estados de fluxo de dados. Por exemplo, ao usar NAT, o controle de fluxo deve garantir que cada par IP:porta de destino tenha uma porta de saída exclusiva. No caso de um balanceador NLB - Balanceador de carga de rede, o fluxo de dados deverá sempre ser direcionado para a mesma máquina virtual de destino. Grupos de segurança são um firewall com estado. Ele monitora o tráfego de entrada e abre portas implicitamente para o fluxo de pacotes de saída.
Na nuvem AWS, os requisitos de latência de transmissão são extremamente altos. É por isso Hiperplano fundamental para o desempenho de toda a rede.
O Hyperplane é construído em máquinas virtuais EC2. Não há magia aqui, apenas astúcia. O truque é que se trata de máquinas virtuais com grande quantidade de RAM. As operações são transacionais e executadas exclusivamente na memória. Isso permite atingir atrasos de apenas dezenas de microssegundos. Trabalhar com o disco mataria toda a produtividade.
Hyperplane é um sistema distribuído de um grande número dessas máquinas EC2. Cada máquina virtual tem uma largura de banda de 5 GB/s. Em toda a rede regional, isso proporciona incríveis terabits de largura de banda e permite o processamento milhões de conexões por segundo.
O HyperPlane funciona apenas com fluxos. O encapsulamento de pacotes VPC é completamente transparente para isso. Uma vulnerabilidade potencial neste serviço interno ainda impediria a quebra do isolamento da VPC. Os níveis abaixo são responsáveis pela segurança.
Vizinho barulhento
Ainda há um problema vizinho barulhento - vizinho barulhento. Vamos supor que temos 8 nós. Esses nós processam os fluxos de todos os usuários da nuvem. Tudo parece estar bem e a carga deve ser distribuída uniformemente por todos os nós. Os nós são muito poderosos e é difícil sobrecarregá-los.
Mas construímos nossa arquitetura com base em cenários até improváveis.
Baixa probabilidade não significa impossível.
Podemos imaginar uma situação em que um ou mais usuários gerariam muita carga. Todos os nós do HyperPlane estão envolvidos no processamento dessa carga e outros usuários podem experimentar algum tipo de impacto no desempenho. Isto quebra o conceito de nuvem, em que os inquilinos não têm capacidade de influenciar uns aos outros.
Como resolver o problema de um vizinho barulhento? A primeira coisa que vem à mente é a fragmentação. Nossos 8 nós são logicamente divididos em 4 fragmentos de 2 nós cada. Agora, um vizinho barulhento perturbará apenas um quarto de todos os usuários, mas os perturbará bastante.
Vamos fazer as coisas de maneira diferente. Alocaremos apenas 3 nós para cada usuário.
O truque é atribuir nós aleatoriamente a usuários diferentes. Na imagem abaixo, o usuário azul cruza nós com um dos outros dois usuários – verde e laranja.
Com 8 nós e 3 usuários, a probabilidade de um vizinho barulhento cruzar com um dos usuários é de 54%. É com esta probabilidade que um usuário azul influenciará outros inquilinos. Ao mesmo tempo, apenas uma parte de sua carga. Em nosso exemplo, essa influência será pelo menos perceptível não para todos, mas apenas para um terço de todos os usuários. Este já é um bom resultado.
Número de usuários que se cruzarão
Probabilidade em porcentagem
0
18%
1
54%
2
26%
3
2%
Vamos aproximar a situação da realidade - vamos pegar 100 nós e 5 usuários em 5 nós. Neste caso, nenhum dos nós se cruzará com uma probabilidade de 77%.
Número de usuários que se cruzarão
Probabilidade em porcentagem
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Em uma situação real, com um grande número de nós e usuários do HyperPlane, o impacto potencial de um vizinho barulhento sobre outros usuários é mínimo. Este método é chamado misturando fragmentação - fragmentação de embaralhamento. Minimiza o efeito negativo da falha do nó.
Muitos serviços são construídos com base no HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Escala de rede
Agora vamos falar sobre a escala da própria rede. Para outubro de 2019 a AWS oferece seus serviços em 22 regiões, e mais 9 estão planejados.
- Cada região contém diversas zonas de disponibilidade. Existem 69 deles em todo o mundo.
- Cada AZ consiste em Centros de Processamento de Dados. Não há mais de 8 deles no total.
- O data center abriga um grande número de servidores, alguns com até 300.
Agora vamos calcular a média de tudo isso, multiplicar e obter um número impressionante que reflita Escala de nuvem Amazon.
Existem muitos links ópticos entre as zonas de disponibilidade e o data center. Numa das nossas maiores regiões, foram criados 388 canais apenas para comunicação AZ entre si e centros de comunicação com outras regiões (Centros de Trânsito). No total isso dá uma loucura 5000 TB.
O Backbone AWS foi desenvolvido especificamente e otimizado para a nuvem. Nós construímos isso nos canais 100 GB / s. Nós os controlamos completamente, com exceção das regiões da China. O tráfego não é compartilhado com cargas de outras empresas.
É claro que não somos o único fornecedor de nuvem com uma rede backbone privada. Cada vez mais grandes empresas estão seguindo esse caminho. Isto é confirmado por investigadores independentes, por exemplo, do .
O gráfico mostra que a participação de provedores de conteúdo e de provedores de nuvem está crescendo. Por causa disso, a parcela do tráfego de Internet dos provedores de backbone está diminuindo constantemente.
Vou explicar por que isso acontece. Anteriormente, a maioria dos serviços web eram acessíveis e consumidos diretamente da Internet. Hoje em dia, cada vez mais servidores estão localizados na nuvem e podem ser acessados via CDN - Rede de distribuição de conteúdo. Para acessar um recurso, o usuário acessa a Internet apenas até o CDN PoP mais próximo - Ponto de presença. Na maioria das vezes, está em algum lugar próximo. Depois sai da Internet pública e voa através de uma espinha dorsal privada através do Atlântico, por exemplo, e chega directamente ao recurso.
Eu me pergunto como a Internet mudará em 10 anos se essa tendência continuar?
Canais físicos
Os cientistas ainda não descobriram como aumentar a velocidade da luz no Universo, mas fizeram grandes progressos nos métodos de transmissão através de fibra óptica. Atualmente usamos cabos de fibra 6912. Isso ajuda a otimizar significativamente o custo de sua instalação.
Em algumas regiões temos que usar cabos especiais. Por exemplo, na região de Sydney utilizamos cabos com revestimento especial contra cupins.
Ninguém está imune a problemas e às vezes nossos canais ficam danificados. A foto à direita mostra cabos ópticos em uma das regiões americanas que foram rasgados por trabalhadores da construção civil. Como resultado do acidente, apenas 13 pacotes de dados foram perdidos, o que é surpreendente. Mais uma vez - apenas 13! O sistema mudou literalmente instantaneamente para canais de backup - a balança está funcionando.
Galopamos por alguns dos serviços e tecnologias em nuvem da Amazon. Espero que você tenha pelo menos alguma ideia da escala das tarefas que nossos engenheiros devem resolver. Pessoalmente, acho isso muito emocionante.
Esta é a parte final da trilogia de Vasily Pantyukhin sobre o dispositivo AWS. EM partes descrevem a otimização do servidor e o dimensionamento do banco de dados, e em — funções sem servidor e Firecracker.
На em novembro, Vasily Pantyukhin compartilhará novos detalhes do dispositivo Amazon. Ele sobre as causas das falhas e o design de sistemas distribuídos na Amazon. 24 de outubro ainda é possível bilhete a um bom preço e pague depois. Esperamos você no HighLoad++, venha bater um papo!
Fonte: habr.com