A escala da Amazon Web Services é de 69 zonas ao redor do mundo em 22 regiões: EUA, Europa, Ásia, África e Austrália. Cada zona tem até 8 CDPs — Centros de Processamento de Dados. Em cada CDP, há milhares ou centenas de milhares de servidores. A rede é construída de forma que todos os cenários improváveis de falhas sejam considerados. Por exemplo, todas as regiões são isoladas umas das outras, e as zonas de disponibilidade estão a várias quilômetros de distância. Mesmo que um cabo seja cortado, o sistema alternará para canais de backup, e as perdas de informação serão de apenas algumas unidades de pacotes de dados. Sobre quais outros princípios a rede é construída e como ela funciona, contará Vasily Pantyukhin.
Vasily Pantyukhin começou 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úblicas. Agora, como arquiteto da Amazon Web Services, oferece conselhos técnicos para viver e se desenvolver na nuvem da AWS.
Na parte anterior da trilogia sobre a estrutura da AWS, Vasily se aprofundou na construção de servidores físicos e no escalonamento de bancos de dados. As placas Nitro, o hipervisor personalizado baseado em KVM, o banco de dados Amazon Aurora — tudo isso no material "". Leia para mergulhar no contexto, ou assista a palestras.
Nesta parte, falaremos sobre o escalonamento da rede — um dos sistemas mais complexos da AWS. A evolução de uma rede plana para uma Virtual Private Cloud e sua estrutura, os serviços internos Blackfoot e HyperPlane, o problema do vizinho barulhento, e, no final, as dimensões da rede, backbone e cabos físicos. Tudo isso abaixo.
Aviso: tudo que está abaixo é opinião pessoal de Vasily e pode não coincidir com a posição da Amazon Web Services.
Escalonamento de rede
A nuvem da AWS foi lançada em 2006. Sua rede era bastante primitiva — com uma estrutura plana. O intervalo de endereços privados era comum para todos os inquilinos da nuvem. Ao iniciar uma nova máquina virtual, você recebia, por acaso, um endereço IP disponível desse intervalo.
Essa abordagem foi fácil de implementar, mas limitava fundamentalmente o uso da nuvem. Em particular, era bastante difícil desenvolver soluções híbridas que combinassem redes privadas locais com a AWS. O problema mais comum era a sobreposição dos intervalos de endereços IP.
Nuvem Privada Virtual
A nuvem se tornou popular. Chegou a hora de considerar a escalabilidade e a possibilidade de uso por dezenas de milhões de inquilinos. A rede plana tornou-se o principal obstáculo. Por isso, pensamos em como isolar usuários uns dos outros em nível de rede, garantindo que pudessem escolher seus próprios intervalos de IP.
O que vem à mente quando você pensa em isolamento de rede? Claro VLAN e VRF — Encaminhamento e Comutação Virtual.
Infelizmente, isso não funcionou. O ID do VLAN é composto por apenas 12 bits, o que nos proporciona apenas 4096 segmentos isolados. Mesmo nos maiores switches, podemos utilizar no máximo 1-2 mil VRFs. O compartilhamento de VRF e VLAN nos fornece apenas alguns milhões de sub-redes. Isso é definitivamente insuficiente para dezenas de milhões de inquilinos, cada um dos quais deve ter a possibilidade de usar várias sub-redes.
Além disso, simplesmente não podemos nos dar ao luxo de comprar a quantidade necessária de grandes dispositivos, por exemplo, da Cisco ou da Juniper. Existem duas razões: é extremamente caro, e não queremos depender da política de desenvolvimento e atualização deles.
A conclusão é clara – precisamos criar nossa 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 opera em Ethernet e IP padrão. Para a transmissão na rede, o tráfego das máquinas virtuais é encapsulado em uma estrutura do nosso próprio protocolo. Nela é especificado um ID que pertence ao inquilino do VPC.
Parece simples. No entanto, é preciso resolver várias questões técnicas sérias. Por exemplo, onde e como armazenar os dados de mapeamento de endereços MAC/IP virtuais, ID do VPC e os respectivos endereços MAC/IP físicos. Em escala da AWS, temos uma enorme tabela que deve operar com latências mínimas de acesso. Isso é responsabilidade do serviço de mapeamento, que é distribuído por toda a rede.
Nos carros da nova geração, a encapsulação é realizada por meio de placas Nitro a nível de hardware. Em instâncias mais antigas, a encapsulação e desencapsulação são feitas de forma programática.
Vamos entender como isso funciona de forma geral. Começaremos pelo nível L2. Suponha que temos uma máquina virtual com o IP 10.0.0.2 em um servidor físico 192.168.0.3. Ela envia dados para uma máquina virtual 10.0.0.3, que reside em 192.168.1.4. Um pedido ARP é gerado, que chega à placa de rede Nitro. Para simplificar, vamos considerar que ambas as máquinas virtuais estão na mesma VPC "azul".
A placa substitui o endereço de origem pelo seu próprio e reencaminha o quadro ARP para o serviço de mapeamento.
O serviço de mapeamento retorna as informações necessárias para a transmissão pela rede física L2.
A placa Nitro, na resposta ARP, substitui o MAC na rede física pelo endereço na VPC.
Ao transmitir dados, envolvemos os MAC e IP lógicos em um invólucro da VPC. Tudo isso é enviado pela rede física com o uso dos IPs apropriados das placas Nitro de origem e destino.
A máquina física para a qual o pacote é destinado faz uma verificação. Isso é necessário para evitar a possibilidade de falsificação de endereços. A máquina envia um pedido especial ao serviço de mapeamento e pergunta: "Da máquina física 192.168.0.3, eu recebi um pacote destinado a 10.0.0.3 na VPC 'azul'. Ele é legítimo?"
O serviço de mapeamento confere sua tabela de alocação de recursos e permite ou nega a passagem do pacote. Em todas as novas instâncias, uma validação adicional é incorporada nas placas Nitro. Não é possível contorná-la, nem 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 para a qual foram destinados.
O serviço de mapeamento também atua como um roteador lógico para a transmissão de dados entre máquinas virtuais em diferentes sub-redes. Conceitualmente, tudo é simples, não entrarei em detalhes.
Assim, ao transmitir cada pacote, os servidores consultam o serviço de mapeamento. Como lidar com as inevitáveis latências? Com cache., claro.
Toda a beleza está no fato de que não é necessário armazenar em cache toda a tabela enorme. Em um servidor físico vivem máquinas virtuais a partir de uma quantidade relativamente pequena de VPCs. É preciso armazenar em cache apenas as informações sobre esses VPCs. A transmissão de dados para outros VPCs na configuração "padrão" ainda não é legítima. Se se utiliza funcionalidade como VPC-peering, então as informações sobre os VPCs correspondentes são carregadas adicionalmente no cache.
Resolvemos a transmissão de dados em VPC.
Blackfoot
Como agir em situações em que o tráfego precisa ser transmitido para fora, por exemplo, para a Internet ou através de VPN para a terra? Aqui somos salvos pelo Blackfoot — serviço interno da AWS. Ele foi desenvolvido pela nossa equipe da África do Sul. Por isso, o serviço é nomeado em homenagem a um pinguim que vive na África do Sul.
Blackfoot descapsula o tráfego e faz com ele o que é necessário. Os dados são enviados para a Internet como estão.
Os dados são descapsulados e recobertos com a proteção IPsec ao usar VPN.
Ao usar Direct Connect, o tráfego é etiquetado e transmitido para o VLAN correspondente.
HyperPlane
Este é um serviço interno de controle de fluxo. Muitos serviços de rede exigem controle do estado do fluxo de dados. Por exemplo, ao usar NAT, o controle de fluxo deve garantir que cada par "IP: porta de destino" corresponda a uma porta de saída única. No caso do balanceador NLB — Network Load Balancer, o fluxo de dados deve sempre ser direcionado para a mesma máquina virtual de destino. Os Grupos de Segurança são um firewall com estado. Ele monitora o tráfego de entrada e abre implicitamente as portas para o fluxo de pacotes de saída.
Na nuvem AWS, as exigências de latência de transmissão são extremamente altas. Portanto, HyperPlane é crítico para a operação de toda a rede.
Hyperplane é construído em máquinas virtuais EC2. Não há mágica aqui, apenas astúcia. A astúcia está no fato de que são máquinas virtuais com grande RAM. As operações são transacionais e realizadas exclusivamente na memória. Isso permite alcançar latências de apenas dezenas de microssegundos. Trabalhar com disco arruinaria toda a performance.
Hyperplane é um sistema distribuído de um enorme 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 uma largura de banda esmagadora de terabits e permite processar milhões de conexões por segundo..
HyperPlane funciona apenas com fluxos. A encapsulação de pacotes pelo VPC é completamente transparente para ele. Uma vulnerabilidade potencial neste serviço interno ainda assim não permitirá romper a isolação do VPC. A segurança é responsabilidade dos níveis inferiores.
vizinho barulhento
Há mais 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. Parece que tudo está bem e a carga deve ser distribuída uniformemente entre todos os nós. Os nós são muito potentes e é difícil sobrecarregá-los.
Mas estamos construindo nossa arquitetura levando em conta até mesmo os cenários menos prováveis.
Uma baixa probabilidade não significa impossibilidade.
Podemos imaginar uma situação em que um ou vários usuários geram uma carga muito alta. Todos os nós HyperPlane estão envolvidos no processamento dessa carga, e outros usuários podem potencialmente sentir alguma diminuição no desempenho. Isso destrói o conceito de nuvem, onde os locatários não têm como influenciar uns aos outros.
Como resolver o problema do vizinho barulhento? A primeira coisa que vem à mente é o sharding. Nossos 8 nós são logicamente divididos em 4 shards com 2 nós cada. Agora, o vizinho barulhento afetará apenas um quarto de todos os usuários, mas de forma significativa.
Vamos agir de forma diferente. Atribuiremos apenas 3 nós para cada usuário.
A sacada é designar nós para diferentes usuários aleatoriamente. Na imagem abaixo, o usuário azul se sobrepõe a um dos outros dois usuários — o verde e o laranja.
Com 8 nós e 3 usuários, a probabilidade de sobreposição de um vizinho barulhento com um dos usuários é de 54%. É com essa probabilidade que o usuário azul influenciará outros locatários. E isso só com parte da sua carga. No nosso exemplo, essa influência será notada apenas por um terço de todos os usuários. Esse já é um bom resultado.
O número de usuários que se sobreporão
Probabilidade em porcentagem
0
18%
1
54%
2
26%
3
2%
Aproximando a situação da realidade — vamos considerar 100 nós e 5 usuários em 5 nós. Nesse caso, nenhuma das nós se sobreporá com uma probabilidade de 77%.
O número de usuários que se sobreporão
Probabilidade em porcentagem
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Na situação real, com um grande número de nós HyperPlane e usuários, o impacto potencial do vizinho barulhento sobre outros usuários é mínimo. Esse método é chamado de sharding com mistura — shuffle sharding. Isso minimiza o efeito negativo da falha de nós.
Muitos serviços são construídos sobre a base do HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Escala da rede
Agora vamos falar sobre a escala da própria rede. Em outubro de 2019, a AWS oferece seus serviços em 22 regiões, e mais 9 estão planejadas.
- Cada região contém várias zonas de disponibilidade — Availability Zone. No total, existem 69 no mundo.
- Cada AZ é composta por Data Centers. No total, há no máximo 8.
- No Data Center, há uma enorme quantidade de servidores, alguns chegando a 300.000.
Agora vamos calcular a média, multiplicar e obter um número impressionante que reflete a escala da nuvem da Amazon.
Muitos canais ópticos estão conectados entre as zonas de disponibilidade e os Data Centers. Em uma das maiores regiões, apenas para a comunicação entre AZs e centros de comunicação com outras regiões (Transit Centers), há 388 canais. Isso resulta em impressionantes 5000 Tbps.
A Backbone AWS foi especificamente construída para a nuvem e otimizada para trabalhar com ela. Nós a construímos em canais 100 Gbps. Controlamos completamente, exceto nas regiões da China. O tráfego não é compartilhado com as cargas de outras empresas.
Claro, não somos o único provedor de nuvem com uma rede backbone privada. Cada vez mais grandes empresas estão seguindo esse caminho. Isso é confirmado por pesquisadores independentes, como os da .
No gráfico, é visível que a participação de provedores de conteúdo e provedores de nuvem está aumentando. Devido a isso, a participação do tráfego de Internet dos provedores de backbone está constantemente diminuindo.
Vou explicar por que isso está acontecendo. Anteriormente, a maioria dos serviços web era acessada e consumida diretamente da Internet. Agora, mais servidores estão localizados na nuvem e acessíveis através da provedor de CDN). Eles monitoram seu — Content Distribution Network. Para acessar o recurso, o usuário vai pela Internet apenas até o PoP CDN mais próximo — Point of Presence. A maioria das vezes, isso fica próximo. Depois, ele sai da Internet pública e viaja pelo backbone privado através do Atlântico, por exemplo, e chega diretamente ao recurso.
É interessante pensar em 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 avançaram significativamente nos métodos de transmissão através da fibra óptica. Atualmente, usamos cabos com 6912 fibras. Isso ajuda a otimizar bastante o custo de sua instalação.
Em algumas regiões, precisamos usar cabos especiais. Por exemplo, na região de Sydney, aplicamos cabos com revestimento especial contra cupins.
Ninguém está isento de problemas e, às vezes, nossos canais são danificados. Na foto à direita, cabos ópticos em uma das regiões da América que foram rompidos por construtores. Como resultado do acidente, perdemos apenas 13 pacotes de dados, o que é surpreendente. Apenas 13! O sistema rapidamente alternou para canais de reserva — a escala funciona.
Demos uma rápida passada por alguns serviços e tecnologias da nuvem da Amazon. Espero que você tenha pelo menos uma ideia da magnitude das tarefas que nossos engenheiros precisam resolver. Pessoalmente, isso me fascina muito.
Esta é a parte final da trilogia de Vasily Pantyukhin sobre a estrutura da AWS. Na parte, são descritas a otimização de servidores e o dimensionamento de banco de dados, e na — funções serverless e Firecracker.
Sobre Em novembro, Vasily Pantyukhin compartilhará novos detalhes sobre a estrutura da Amazon. Ele discutirá as causas de falhas e o design de sistemas distribuídos na Amazon. Até 24 de outubro, você ainda pode comprar um bilhete a um bom preço e pagar depois. Esperamos você no HighLoad++, venha — vamos conversar!
Fonte: habr.com
