Comment AWS fabrique ses services résilients. Mise à l'échelle du réseau

Le réseau Amazon Web Services compte 69 sites dans le monde dans 22 régions: États-Unis, Europe, Asie, Afrique et Australie. Dans chaque zone, il y a jusqu'à 8 centres de données - centres de traitement des données. Chaque centre de données possède des milliers ou des centaines de milliers de serveurs. Le réseau est construit de telle manière que tous les scénarios d'interruption improbables soient pris en compte. Par exemple, toutes les régions sont isolées les unes des autres et les zones d'accès sont espacées de plusieurs kilomètres. Même si vous coupez le câble, le système passera aux canaux de sauvegarde et la perte d'informations équivaudra à des unités de paquets de données. A propos de quels autres principes le réseau est construit et comment il est construit, dira Vasily Pantyukhin.



Vasily Pantyukhin a commencé en tant qu’administrateur Unix dans des sociétés .ru, a passé 6 ans dans les grandes glandes de Sun Microsystem et pendant 11 ans, il a prêché la concentration sur les données du monde chez EMC. Naturellement, il est devenu un cloud privé, puis est devenu public. Désormais, en tant qu'architecte d'Amazon Web Services, les conseils techniques vous aident à vivre et à grandir dans le cloud AWS.

Dans la partie précédente de la trilogie des appareils AWS, Vasily s'est plongé dans l'appareil des serveurs physiques et de la mise à l'échelle de la base de données. Nitro-cards, hyperviseur personnalisé basé sur KVM, base de données Amazon Aurora - tout cela dans l'article " Comment AWS" cuisine "ses services élastiques. Mise à l'échelle du serveur et de la base de données . ” Lisez pour plonger dans le contexte ou regardez une vidéo de la présentation.

Dans cette partie, nous nous concentrerons sur la mise à l'échelle du réseau - l'un des systèmes les plus complexes d'AWS. L'évolution d'un réseau plat vers le cloud privé virtuel et son appareil, les services internes Blackfoot et HyperPlane, le problème d'un voisin bruyant, et à la fin - l'échelle du réseau, de la dorsale et des câbles physiques. À propos de tout cela sous la coupe.

Avis de non-responsabilité: tout ce qui suit est l'opinion personnelle de Vasily, et cela peut ne pas coïncider avec la position d'Amazon Web Services.

Mise à l'échelle du réseau

AWS Cloud a été lancé en 2006. Son réseau était assez primitif - avec une structure plate. La plage d'adresses privées était commune à tous les locataires du cloud. Lorsque vous démarrez une nouvelle machine virtuelle, vous avez accidentellement reçu une adresse IP disponible de cette plage.



Cette approche était facile à mettre en œuvre, mais limitait fondamentalement l'utilisation du cloud. En particulier, il était assez difficile de développer des solutions hybrides combinant des réseaux privés sur le terrain et dans AWS. Le problème le plus courant était l'intersection de plages d'adresses IP.

Cloud privé virtuel

Le cloud était en demande. Il est temps de réfléchir à l'évolutivité et à la possibilité de son utilisation par des dizaines de millions de locataires. Le réseau plat est devenu un obstacle majeur. Par conséquent, nous avons réfléchi à la façon d'isoler les utilisateurs les uns des autres au niveau du réseau afin qu'ils puissent sélectionner indépendamment les plages IP.



Qu'est-ce qui vous vient à l'esprit en premier lorsque vous pensez à l'isolement du réseau? Bien sûr, le VLAN et le VRF sont le routage et le transfert virtuels .

Malheureusement, cela n'a pas fonctionné. L'ID VLAN n'est que de 12 bits, ce qui nous donne seulement 4096 segments isolés. Même dans les plus grands commutateurs, vous pouvez utiliser un maximum de 1 à 2 000 VRF. L'utilisation combinée de VRF et de VLAN ne nous donne que quelques millions de sous-réseaux. Ce n'est certainement pas suffisant pour des dizaines de millions de locataires, chacun devant pouvoir utiliser plusieurs sous-réseaux.

Pourtant, nous ne pouvons tout simplement pas nous permettre d'acheter le nombre requis de grandes boîtes, par exemple, auprès de Cisco ou de Juniper. Il y a deux raisons: cela coûte furieusement cher, et nous ne voulons pas devenir dépendants de leurs politiques de développement et de correctifs.

Il n'y a qu'une seule conclusion - pour préparer votre propre décision.

En 2009, nous avons annoncé VPC - Virtual Private Cloud . Le nom a pris racine et maintenant de nombreux fournisseurs de cloud l'utilisent également.

VPC est un réseau virtuel SDN (Software Defined Network). Nous avons décidé de ne pas inventer de protocoles spéciaux aux niveaux L2 et L3. Le réseau fonctionne sur Ethernet et IP standard. Pour la transmission sur un réseau, le trafic des machines virtuelles est encapsulé dans un wrapper de notre propre protocole. Il indique l'ID qui appartient au VPC du locataire.



Cela semble facile. Cependant, il est nécessaire de résoudre plusieurs problèmes techniques graves. Par exemple, où et comment stocker les données de mappage pour les adresses MAC / IP virtuelles, les ID VPC et les adresses MAC / IP physiques correspondantes. À l'échelle AWS, il s'agit d'une énorme table qui devrait fonctionner avec une latence minimale. Le service de cartographie , qui est recouvert d'une couche mince sur tout le réseau, en est responsable.

Dans les machines des nouvelles générations, l'encapsulation est réalisée par des cartes Nitro au niveau du fer. Dans les cas plus anciens, encapsulation et décapsulation de logiciels.



Voyons comment cela fonctionne en termes généraux. Commençons par le niveau L2. Supposons que nous ayons une machine virtuelle avec IP 10.0.0.2 sur un serveur physique 192.168.0.3. Il envoie des données à une machine virtuelle 10.0.0.3 qui vit sur 192.168.1.4. Une requête ARP est générée, qui tombe sur la carte réseau Nitro. Pour simplifier, nous pensons que les deux machines virtuelles vivent dans le même VPC «bleu».



La carte remplace l'adresse source par la sienne et envoie la trame ARP au service de mappage.



Le service de mappage renvoie les informations nécessaires à la transmission sur le réseau physique L2.



La carte nitro dans la réponse ARP remplace le MAC dans le réseau physique par l'adresse dans le VPC.



Lors du transfert de données, nous enveloppons le MAC et l'IP logiques dans un wrapper VPC. Tout cela est transmis sur le réseau physique à l'aide des cartes IP Nitro appropriées de la source et de la destination.



La machine physique sur laquelle le package est destiné à effectuer des vérifications. C'est pour éviter la possibilité d'usurpation. La machine envoie une demande spéciale au service de mappage et demande: «De la machine physique 192.168.0.3, j'ai reçu un paquet conçu pour 10.0.0.3 dans le VPC bleu. Est-il légitime? "



Le service de mappage vérifie sa table d'allocation de ressources et autorise ou refuse le passage du paquet. Dans toutes les nouvelles instances, une validation supplémentaire est cousue sur des cartes Nitro. Il est impossible de se déplacer même théoriquement. Par conséquent, l'usurpation d'identité vers des ressources dans un autre VPC ne fonctionnera pas.



Les données sont ensuite envoyées à la machine virtuelle à laquelle elles sont destinées.



Le service de mappage fonctionne également comme un routeur logique pour transférer des données entre des machines virtuelles sur différents sous-réseaux. Tout y est conceptuellement simple, je ne vais pas l'analyser en détail.



Il s'avère que lors de la transmission de chaque paquet, les serveurs accèdent au service de mappage. Comment faire face aux retards inévitables? La mise en cache , bien sûr.

Tout le charme est que vous n'avez pas besoin de mettre en cache toute la grande table. Les machines virtuelles d'un nombre relativement faible de VPC vivent sur un serveur physique. Les informations doivent être mises en cache uniquement sur ces VPC. Le transfert de données vers d'autres VPC dans la configuration "par défaut" n'est toujours pas légitime. Si des fonctionnalités telles que l'appairage de VPC sont utilisées, des informations sur les VPC correspondants sont en outre chargées dans le cache.



Avec le transfert de données vers le VPC compris.

Pieds-noirs

Que faire dans les cas où le trafic doit être transmis à l'extérieur, par exemple sur Internet ou via un VPN au sol? C'est là que Blackfoot , le service interne AWS, nous aide. Il est conçu par notre équipe sud-africaine. Par conséquent, le service porte le nom du pingouin qui vit en Afrique du Sud.



Blackfoot décapsule le trafic et en fait ce dont il a besoin. Les données Internet sont envoyées telles quelles.



Les données sont décapsulées et enveloppées à nouveau dans un wrapper IPsec lors de l'utilisation d'un VPN.



Lorsque vous utilisez Direct Connect, le trafic est étiqueté et transmis au VLAN correspondant.

HyperPlane

Il s'agit d'un service de contrôle de flux interne. De nombreux services réseau nécessitent de surveiller l' état du flux de données . Par exemple, lors de l'utilisation de NAT, le contrôle de flux doit garantir que chaque paire «IP: port de destination» possède un port sortant unique. Dans le cas de l'équilibreur NLB - équilibreur de charge réseau , le flux de données doit toujours être dirigé vers la même machine virtuelle cible. Les groupes de sécurité sont un pare-feu dynamique. Il surveille le trafic entrant et ouvre implicitement les ports pour le flux de paquets sortant.



Dans le cloud AWS, les exigences de latence de transmission sont extrêmement élevées. Par conséquent, HyperPlane est essentiel à l' intégrité de l'ensemble du réseau.



Hyperplane est construit sur des machines virtuelles EC2. Il n'y a pas de magie ici, seulement de la ruse. L'astuce est que ce sont des machines virtuelles avec une grande RAM. Les transactions sont transactionnelles et effectuées exclusivement en mémoire. Cela permet des retards de seulement quelques dizaines de microsecondes. Travailler avec un disque tuerait toutes les performances.

Hyperplane est un système distribué à partir d'un grand nombre de ces machines EC2. Chaque machine virtuelle a une bande passante de 5 Go / s. Sur l'ensemble du réseau régional, cela donne des térabits de bande passante sauvages et vous permet de traiter des millions de connexions par seconde .

HyperPlane ne fonctionne qu'avec des threads. L'encapsulation des paquets VPC lui est totalement transparente. La vulnérabilité potentielle de ce service interne ne permettra toujours pas de rompre l'isolement du VPC. Pour la sécurité, les niveaux ci-dessous sont responsables.

Voisin bruyant

Il y a aussi le problème du voisin bruyant . Supposons que nous ayons 8 nœuds. Ces nœuds traitent les threads de tous les utilisateurs du cloud. Tout semble aller bien et la charge devrait être répartie uniformément sur tous les nœuds. Les nœuds sont très puissants et difficiles à surcharger.

Mais nous construisons notre architecture sur la base de scénarios même improbables.

Une faible probabilité ne signifie pas une impossibilité.

Nous pouvons imaginer une situation dans laquelle un ou plusieurs utilisateurs généreront trop de charge. Tous les nœuds HyperPlane sont impliqués dans le traitement de cette charge, et d'autres utilisateurs peuvent potentiellement ressentir une sorte de dégradation des performances. Cela détruit le concept du cloud, dans lequel les locataires n'ont aucun moyen de s'influencer mutuellement.



Comment résoudre le problème d'un voisin bruyant? La première chose qui me vient à l'esprit est le partage. Nos 8 nœuds sont logiquement divisés en 4 fragments avec 2 nœuds chacun. Maintenant, un voisin bruyant ne sera gêné que par un quart de tous les utilisateurs, mais beaucoup plus.



Faisons-le différemment. Chaque utilisateur ne dispose que de 3 nœuds.



L'astuce consiste à affecter des nœuds à différents utilisateurs de manière aléatoire. Dans l'image ci-dessous, l'utilisateur bleu coupe les nœuds avec l'un des deux autres utilisateurs - vert et orange.



Avec 8 nœuds et 3 utilisateurs, la probabilité de passage d'un voisin bruyant avec l'un des utilisateurs est de 54%. C'est avec cette probabilité que l'utilisateur bleu affectera les autres locataires. De plus, seule une partie de sa charge. Dans notre exemple, cette influence sera au moins en quelque sorte perceptible par tout le monde, mais seulement un tiers de tous les utilisateurs. C'est déjà un bon résultat.

Ramenons la situation plus proche de la réalité - prenez 100 nœuds et 5 utilisateurs sur 5 nœuds. Dans ce cas, aucun des nœuds ne se croise avec une probabilité de 77%.

Dans une situation réelle avec un grand nombre de nœuds et d'utilisateurs HyperPlane, l'impact potentiel d'un voisin bruyant sur les autres utilisateurs est minime. Cette méthode est appelée shuffle sharding . Il minimise l'effet négatif de la défaillance du nœud.

De nombreux services sont construits sur la base d'HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.

Échelle du réseau

Parlons maintenant de l'échelle du réseau lui-même. Pour octobre 2019, AWS propose ses services dans 22 régions , et 9 autres sont prévus.

• Chaque région contient plusieurs zones de disponibilité. Il y en a 69 dans le monde.
  
• Chaque AZ se compose de centres de traitement des données. Il n'y en a pas plus de 8.
  
• Dans le centre de données, il y a un grand nombre de serveurs, certains jusqu'à 300 000.
  

Maintenant, tout cela en moyenne, multiplié et obtenir un chiffre impressionnant qui affiche l' échelle du cloud Amazon .

Entre les zones d'accès et le datacenter, de nombreux canaux optiques sont posés. Dans l'une de nos plus grandes régions, seuls 388 canaux ont été posés pour la communication d'AZ entre eux et les centres de communication avec les autres régions (Transit Centers). Au total, cela donne un 5000 Tbit fou.



Backbone AWS est conçu spécifiquement pour le cloud et optimisé pour fonctionner avec lui. Nous le construisons sur des canaux à 100 Go / s . Nous les contrôlons entièrement, à l'exception des régions de Chine. Le trafic n'est pas partagé avec les charges des autres sociétés.



Bien sûr, nous ne sommes pas le seul fournisseur de cloud avec un réseau fédérateur privé. De plus en plus de grandes entreprises vont dans ce sens. Cela est confirmé par des chercheurs indépendants, par exemple, de Telegeography .



Le graphique montre que la part des fournisseurs de contenu et des fournisseurs de cloud augmente. Pour cette raison, la proportion du trafic Internet provenant des fournisseurs de dorsale est en constante diminution.

Je vais expliquer pourquoi cela se produit. Auparavant, la plupart des services Web étaient disponibles et consommés directement depuis Internet. Désormais, de plus en plus de serveurs sont situés dans le cloud et sont disponibles via le CDN - Content Distribution Network . Pour accéder à la ressource, l'utilisateur ne passe par Internet qu'au point de présence CDN PoP le plus proche. Le plus souvent, c'est quelque part à proximité. Il quitte ensuite l'Internet public et vole à travers l'Atlantique via un réseau privé, par exemple, et se rend directement à la ressource.

Je me demande comment Internet va changer dans 10 ans si cette tendance se poursuit?

Canaux physiques

Les scientifiques n'ont pas encore compris comment augmenter la vitesse de la lumière dans l'univers, mais ont fait de grands progrès dans les méthodes de transmission à travers la fibre optique. Nous utilisons actuellement 6912 câbles en fibre. Cela permet d'optimiser considérablement le coût de leur installation.

Dans certaines régions, nous devons utiliser des câbles spéciaux. Par exemple, dans la région de Sydney, nous utilisons des câbles avec un revêtement spécial contre les termites.



Personne n'est à l'abri des problèmes et parfois nos canaux sont endommagés. La photo de droite montre des câbles optiques dans l'une des régions américaines déchirées par les constructeurs. À la suite de l'accident, seulement 13 paquets de données ont été perdus, ce qui est surprenant. Encore une fois - seulement 13! Le système est littéralement passé instantanément aux canaux de sauvegarde - la balance fonctionne.

Nous avons galopé sur certains services et technologies cloud d'Amazon. J'espère que vous avez au moins une idée de l'ampleur des tâches que nos ingénieurs doivent résoudre. Personnellement, cela m'intéresse beaucoup.

Ceci est la dernière partie de la trilogie de Vasily Pantyukhin sur l'appareil AWS. La première partie décrit l'optimisation du serveur et la mise à l'échelle de la base de données, et la seconde décrit les fonctions sans serveur et Firecracker.

À HighLoad ++ en novembre, Vasily Pantyukhin partagera les nouveaux détails des appareils Amazon. Il parlera des causes des pannes et de la conception des systèmes distribués chez Amazon. Le 24 octobre, vous pouvez toujours réserver un billet à un bon prix et payer plus tard. Nous vous attendons à HighLoad ++, venez parler!