Como a AWS fabrica seus serviços resilientes. Escala de rede

A rede Amazon Web Services possui 69 locais em todo o mundo em 22 regiões: EUA, Europa, Ásia, África e Austrália. Em cada zona, existem até 8 data centers - Data Processing Centers. Cada data center possui milhares ou centenas de milhares de servidores. A rede é construída de forma que todos os cenários de interrupção improváveis ​​sejam levados em consideração. Por exemplo, todas as regiões são isoladas uma da outra e as zonas de acesso são espaçadas a vários quilômetros de distância. Mesmo se você cortar o cabo, o sistema alternará para os canais de backup e a perda de informações equivalerá a unidades de pacotes de dados. Sobre que outros princípios a rede é construída e como é construída, dirá a Vasily Pantyukhin.



Vasily Pantyukhin começou como administrador do Unix em empresas .ru, passou 6 anos nas grandes glândulas da Sun Microsystem e, por 11 anos, pregou a centralidade de dados do mundo na EMC. Evoluiu naturalmente para nuvens privadas e depois tornou-se público. Agora, como arquiteto do Amazon Web Services, o aconselhamento técnico ajuda você a viver e crescer na nuvem da AWS.

Na parte anterior da trilogia de dispositivos da AWS, Vasily examinou o dispositivo de servidores físicos e o dimensionamento do banco de dados. Nitro-cards, hypervisor personalizado baseado no banco de dados KVM, Amazon Aurora - tudo isso no artigo " Como a AWS" prepara "seus serviços elásticos. Escala de servidor e banco de dados . ” Leia para mergulhar no contexto ou assista a um vídeo da apresentação.

Nesta parte, focaremos no dimensionamento da rede - um dos sistemas mais complexos da AWS. Evolução de uma rede plana para a Virtual Private Cloud e seu dispositivo, serviços internos 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 é da opinião pessoal de Vasily e pode não coincidir com a posição da Amazon Web Services.

Escala de rede

AWS Cloud lançado em 2006. Sua rede era bastante primitiva - com uma estrutura plana. O intervalo de endereços privados era comum a todos os inquilinos da nuvem. Ao iniciar uma nova máquina virtual, você acidentalmente recebeu um endereço IP disponível desse intervalo.



Essa abordagem foi fácil de implementar, mas limitou fundamentalmente o uso da nuvem. Em particular, era bastante difícil desenvolver soluções híbridas que combinavam redes privadas no local e na AWS. O problema mais comum foi a interseção de intervalos de endereços IP.

Nuvem privada virtual

A nuvem estava em demanda. É hora de pensar na escalabilidade e na possibilidade de seu uso por dezenas de milhões de inquilinos. Rede plana tornou-se um grande obstáculo. Portanto, pensamos em como isolar os usuários um do outro no nível da rede, para que eles possam selecionar independentemente os intervalos de IP.



O que vem à mente primeiro quando você pensa em isolamento de rede? É claro que VLAN e VRF são roteamento e encaminhamento virtual .

Infelizmente, isso não funcionou. O ID da VLAN é de apenas 12 bits, o que fornece apenas 4096 segmentos isolados. Mesmo nos comutadores maiores, você pode usar no máximo 1-2 mil VRF. O uso combinado de VRF e VLAN nos dá apenas alguns milhões de sub-redes. Definitivamente, isso não é suficiente para dezenas de milhões de inquilinos, cada um dos quais deve poder usar várias sub-redes.

Ainda assim, simplesmente não podemos comprar o número necessário de caixas grandes, por exemplo, da Cisco ou Juniper. Há duas razões: é extremamente caro e não queremos nos tornar dependentes de suas políticas de desenvolvimento e correção.

Há apenas uma conclusão - preparar sua própria decisão.

Em 2009, anunciamos o VPC - Virtual Private Cloud . O nome criou raízes e agora muitos provedores de nuvem também o usam.

VPC é uma rede virtual de rede definida por software ( SDN ). Decidimos não inventar protocolos especiais nos níveis L2 e L3. A rede é executada em Ethernet e IP padrão. Para transmissão em uma rede, o tráfego da máquina virtual é encapsulado em um invólucro de nosso próprio protocolo. Indica o ID que pertence à VPC do inquilino.



Isso parece fácil. No entanto, é necessário resolver vários problemas técnicos sérios. Por exemplo, onde e como armazenar dados de mapeamento para endereços MAC / IP virtuais, IDs de VPC e endereços MAC / IP físicos correspondentes. Em uma escala da AWS, esta é uma tabela enorme que deve funcionar com latência mínima. O serviço de mapeamento , que é manchado com uma camada fina em toda a rede, é responsável por isso.

Em máquinas de novas gerações, o encapsulamento é realizado pelos cartões Nitro no nível do ferro. Em casos mais antigos, encapsulamento e decapsulação de software.



Vamos ver como isso funciona em termos gerais. Vamos começar com o nível L2. Suponha que tenhamos uma máquina virtual com IP 10.0.0.2 em um servidor físico 192.168.0.3. Ele envia dados para uma máquina virtual 10.0.0.3 que vive em 192.168.1.4. Uma solicitação ARP é gerada, que fica na placa de rede Nitro. Para simplificar, acreditamos que as duas máquinas virtuais vivem na mesma VPC "azul".



O cartão substitui o endereço de origem pelo seu e envia 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 transferir dados, agrupamos o MAC e o IP lógicos em um wrapper VPC. Tudo isso é transmitido pela rede física usando as placas IP Nitro apropriadas da origem e do destino.



A máquina física em que o pacote se destina a executar verificações. Isso é para evitar a possibilidade de falsificaçã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 projetado para 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, a validação adicional é agregada nos cartões Nitro. É impossível se locomover 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 à qual se destinam.



O serviço de mapeamento também funciona como um roteador lógico para transferir dados entre máquinas virtuais em diferentes sub-redes. Tudo é conceitualmente simples lá, não vou analisá-lo em detalhes.



Acontece que durante a transmissão de cada pacote, os servidores acessam o serviço de mapeamento. Como lidar com atrasos inevitáveis? Armazenamento em cache , é claro.

Todo o charme é que você não precisa armazenar em cache a tabela enorme inteira. Máquinas virtuais de um número relativamente pequeno de VPCs vivem em um servidor físico. As informações precisam ser armazenadas em cache apenas 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, informações sobre os VPCs correspondentes serão carregadas adicionalmente no cache.



Com a transferência de dados para o VPC descoberto.

Pé-preto

O que fazer nos casos em que o tráfego precisa ser transmitido para fora, por exemplo, na Internet ou através de uma VPN no solo? É aqui que o Blackfoot , o serviço interno da AWS, nos ajuda. Ele foi projetado por nossa equipe sul-africana. Portanto, o serviço recebeu o nome do pinguim que vive na África do Sul.



Blackfoot decapsula o tráfego e faz o que precisa com ele. Os dados da Internet são enviados como estão.



Os dados são decapsulados e agrupados novamente em um invólucro IPsec ao usar uma VPN.



Ao usar o Direct Connect, o tráfego é marcado e transmitido para a VLAN correspondente.

HyperPlane

Este é um serviço de controle de fluxo interno. Muitos serviços de rede exigem o monitoramento do status do fluxo de dados . Por exemplo, ao usar o NAT, o controle de fluxo deve garantir que cada par "IP: porta de destino" tenha uma porta de saída exclusiva. No caso do balanceador NLB - Network Load Balancer , o fluxo de dados sempre deve ser direcionado para a mesma máquina virtual de destino. Grupos de segurança é um firewall com estado. Ele monitora o tráfego recebido e abre implicitamente as portas para o fluxo de pacotes de saída.



Na nuvem da AWS, os requisitos de latência de transmissão são extremamente altos. Portanto, o HyperPlane é fundamental para a saúde de toda a rede.



O Hyperplane é construído em máquinas virtuais EC2. Não há mágica aqui, apenas astúcia. O truque é que elas são máquinas virtuais com grande RAM. As transações são transacionais e executadas exclusivamente na memória. Isso permite atrasos de apenas dezenas de microssegundos. Trabalhar com um disco mataria todo o desempenho.

O Hyperplane é um sistema distribuído de um grande número de máquinas EC2. Cada máquina virtual possui uma largura de banda de 5 GB / s. Em toda a rede regional, isso gera terabits selvagens de largura de banda e permite processar milhões de conexões por segundo .

O HyperPlane funciona apenas com threads. O encapsulamento de pacotes VPC é completamente transparente para ele. A vulnerabilidade em potencial nesse serviço interno ainda não permitirá romper o isolamento da VPC. Por segurança, os níveis abaixo são responsáveis.

Vizinho barulhento

Há também o problema do vizinho barulhento . Suponha que tenhamos 8 nós. Esses nós processam os encadeamentos de todos os usuários da nuvem. Tudo parece estar bem e a carga deve ser distribuída igualmente em todos os nós. Os nós são muito poderosos e difíceis de sobrecarregar.

Mas estamos construindo nossa arquitetura com base em cenários improváveis.

Baixa probabilidade não significa impossibilidade.

Podemos imaginar uma situação em que um ou mais usuários gerem muita carga. Todos os nós do HyperPlane estão envolvidos no processamento dessa carga e outros usuários podem sentir algum tipo de degradação do desempenho. Isso destrói o conceito de nuvem, no qual os inquilinos não têm como se influenciar.



Como resolver o problema de um 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 em cada um. Agora, um vizinho barulhento será prejudicado por apenas um quarto de todos os usuários, mas muito mais.



Vamos fazer diferente. Cada usuário possui apenas três nós.



O truque é atribuir nós a diferentes usuários aleatoriamente. Na imagem abaixo, o usuário azul intercepta os 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 essa probabilidade que o usuário azul afetará outros inquilinos. Além disso, apenas uma parte de sua carga. No nosso exemplo, essa influência será pelo menos de alguma forma imperceptível para todos, mas apenas para um terço de todos os usuários. Este já é um bom resultado.

Vamos aproximar a situação da real - pegue 100 nós e 5 usuários em 5 nós. Nesse caso, nenhum dos nós se cruza com uma probabilidade de 77%.

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 em outros usuários é mínimo. Esse método é chamado de fragmentação aleatória . Minimiza o efeito negativo da falha do nó.

Com base no HyperPlane, muitos serviços são criados: 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 planejadas.

• Cada região contém várias zonas de disponibilidade. Existem 69 deles no mundo.
  
• Cada AZ consiste em centros de processamento de dados. Não há mais de 8 deles.
  
• No data center, há um grande número de servidores, alguns até 300.000.
  

Agora, tudo isso é calculado em média, multiplicado e obtém uma figura impressionante que mostra a escala da nuvem da Amazon .

Entre as zonas de acesso e o data center, muitos canais ópticos são instalados. Em uma de nossas maiores regiões, apenas 388 canais foram estabelecidos para a comunicação do AZ entre si e os centros de comunicação com outras regiões (Centros de Trânsito). No total, isso dá um louco 5000 Tbit .



Backbone A AWS foi criada especificamente para a nuvem e otimizada para trabalhar com ela. Nós o construímos em canais de 100 GB / s . Nós os controlamos totalmente, com exceção das regiões da China. O tráfego não é compartilhado com as cargas de outras empresas.



Obviamente, não somos o único provedor de nuvem com uma rede de backbone privada. Cada vez mais empresas grandes estão seguindo esse caminho. Isso é confirmado por pesquisadores independentes, por exemplo, da Telegeography .



O gráfico mostra que a participação de provedores de conteúdo e de nuvem está aumentando. Por esse motivo, a proporção de tráfego da Internet de provedores de backbone está diminuindo constantemente.

Vou explicar por que isso acontece. Anteriormente, a maioria dos serviços da Web estava disponível e consumida diretamente da Internet. Agora, mais e mais servidores estão localizados na nuvem e estão disponíveis na CDN - Content Distribution Network . Para acessar o recurso, o usuário passa pela Internet apenas até o CDN PoP - Ponto de Presença mais próximo. Na maioria das vezes, está em algum lugar próximo. Em seguida, ele sai da Internet pública e voa pelo Atlântico através de uma espinha dorsal privada, por exemplo, e chega diretamente ao recurso.

Gostaria de saber 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 avanços nos métodos de transmissão através da fibra óptica. Atualmente, estamos usando 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, usamos cabos com um revestimento especial contra cupins.



Ninguém está a salvo de problemas e, às vezes, nossos canais são danificados. A foto à direita mostra cabos ópticos em uma das regiões americanas que foram arrancadas pelos construtores. Como resultado do acidente, apenas 13 pacotes de dados foram perdidos, o que é surpreendente. Mais uma vez - apenas 13! O sistema literalmente mudou instantaneamente para os canais de backup - a balança funciona.

Galopamos sobre alguns serviços e tecnologias em nuvem da Amazon. Espero que você tenha pelo menos uma idéia da escala das tarefas que nossos engenheiros precisam resolver. Pessoalmente, estou muito interessado nisso.

Esta é a parte final da trilogia de Vasily Pantyukhin sobre o dispositivo da AWS. A primeira parte descreve a otimização do servidor e a escala do banco de dados, e a segunda descreve as funções sem servidor e o Firecracker.

No HighLoad ++ em novembro, Vasily Pantyukhin compartilhará novos detalhes do dispositivo Amazon. Ele falará sobre as causas das falhas e o design dos sistemas distribuídos na Amazon. Em 24 de outubro, você ainda pode reservar um bilhete por um bom preço e pagar mais tarde. Estamos esperando por você no HighLoad ++, venha conversar!