L'échelle du réseau Amazon Web Services est de 69 zones à travers le monde dans 22 régions : États-Unis, Europe, Asie, Afrique et Australie. Chaque zone contient jusqu'à 8 centres de données - Centres de traitement des données. Chaque centre de données possède des milliers, voire des centaines de milliers de serveurs. Le réseau est conçu de manière à prendre en compte tous les scénarios de panne improbables. Par exemple, toutes les régions sont isolées les unes des autres et les zones d’accessibilité sont séparées sur des distances de plusieurs kilomètres. Même si vous coupez le câble, le système passera aux canaux de secours et la perte d'informations équivaudra à quelques paquets de données. Vasily Pantyukhin expliquera sur quels autres principes le réseau repose et comment il est structuré.
Vassili Pantioukhine a commencé comme administrateur Unix dans des entreprises .ru, a travaillé sur du matériel Sun Microsystem pendant 6 ans et a prêché un monde centré sur les données pendant 11 ans chez EMC. Il a naturellement évolué vers des cloud privés, puis vers des cloud publics. Aujourd'hui, en tant qu'architecte Amazon Web Services, il fournit des conseils techniques pour vous aider à vivre et à vous développer dans le cloud AWS.
Dans la partie précédente de la trilogie AWS, Vasily s'est penché sur la conception de serveurs physiques et la mise à l'échelle des bases de données. Cartes Nitro, hyperviseur personnalisé basé sur KVM, base de données Amazon Aurora - à propos de tout cela dans le matériel "" Lire pour le contexte ou regarder les performances.
Cette partie se concentrera 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 un Virtual Private Cloud et sa conception, les services internes de Blackfoot et HyperPlane, le problème d'un voisin bruyant, et à la fin - l'échelle du réseau, du backbone et des câbles physiques. A propos de tout ça sous la coupe.
Avertissement : tout ce qui suit est l'opinion personnelle de Vasily et peut ne pas coïncider avec la position d'Amazon Web Services.
Mise à l'échelle du réseau
Le cloud AWS 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. Lors du démarrage d'une nouvelle machine virtuelle, vous avez accidentellement reçu une adresse IP disponible dans 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 au sol et dans AWS. Le problème le plus courant était le chevauchement des plages d’adresses IP.
Cloud privé virtuel
Le cloud s'est avéré très demandé. Le moment est venu 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. Nous avons donc réfléchi à la manière d'isoler les utilisateurs les uns des autres au niveau du réseau afin qu'ils puissent choisir indépendamment les plages IP.
Quelle est la première chose qui vous vient à l’esprit lorsque vous pensez à l’isolation du réseau ? Certainement VLAN и VRF - Routage et 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 les commutateurs les plus grands peuvent utiliser un maximum de 1 à 2 XNUMX VRF. L'utilisation conjointe 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.
Nous ne pouvons tout simplement pas non plus 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 : c'est extrêmement cher et nous ne voulons pas être à la merci de leurs politiques de développement et de correctifs.
Il n’y a qu’une seule conclusion : faites votre propre solution.
En 2009, nous avons annoncé VPC - Cloud privé virtuel. Le nom est resté et désormais, de nombreux fournisseurs de cloud l'utilisent également.
VPC est un réseau virtuel SDN (Réseau défini par logiciel). Nous avons décidé de ne pas inventer de protocoles particuliers aux niveaux L2 et L3. Le réseau fonctionne sur Ethernet et IP standard. Pour la transmission sur le réseau, le trafic des machines virtuelles est encapsulé dans notre propre wrapper de protocole. Il indique l’ID qui appartient au VPC du locataire.
Cela semble simple. Il reste cependant plusieurs défis techniques sérieux à surmonter. Par exemple, où et comment stocker les données sur le mappage des adresses MAC/IP virtuelles, de l'ID VPC et du MAC/IP physique correspondant. À l'échelle AWS, il s'agit d'une énorme table qui devrait fonctionner avec des délais d'accès minimes. Responsable de cela service de cartographie, qui est réparti en une fine couche sur tout le réseau.
Dans les machines de nouvelle génération, l'encapsulation est réalisée par les cartes Nitro au niveau matériel. Dans les cas plus anciens, l'encapsulation et la décapsulation sont basées sur un logiciel.
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 à la machine virtuelle 10.0.0.3, qui réside sur 192.168.1.4. Une requête ARP est générée et envoyée à la carte réseau Nitro. Pour plus de simplicité, nous supposons que les deux machines virtuelles vivent dans le même VPC « bleu ».
La carte remplace l'adresse source par la sienne et transmet la trame ARP au service de cartographie.
Le service de cartographie renvoie les informations nécessaires à la transmission sur le réseau physique L2.
La carte Nitro dans la réponse ARP remplace le MAC sur le réseau physique par une adresse dans le VPC.
Lors du transfert de données, nous enveloppons le MAC et l'IP logiques dans un wrapper VPC. Nous transmettons tout cela sur le réseau physique en utilisant les cartes IP Nitro source et destination appropriées.
La machine physique à laquelle le package est destiné effectue la vérification. Cela est nécessaire pour éviter toute possibilité d’usurpation d’adresse. La machine envoie une requête spéciale au service de cartographie et demande : « De la machine physique 192.168.0.3, j'ai reçu un paquet destiné à 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 intégrée aux cartes Nitro. Il est impossible de le contourner, même théoriquement. Par conséquent, l’usurpation d’identité vers les ressources d’un autre VPC ne fonctionnera pas.
Ensuite, les données sont 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 dans différents sous-réseaux. Tout est conceptuellement simple, je n'entrerai pas dans les détails.
Il s'avère que lors de la transmission de chaque paquet, les serveurs se tournent vers le service de cartographie. Comment gérer les retards inévitables ? Mise en cachebien sur.
La beauté est que vous n’avez pas besoin de mettre en cache l’intégralité de l’immense table. Un serveur physique héberge des machines virtuelles à partir d'un nombre relativement restreint de VPC. Il vous suffit de mettre en cache les informations 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 une fonctionnalité telle que l'appairage de VPC est utilisée, les informations sur les VPC correspondants sont également chargées dans le cache.
Nous avons réglé le transfert des données vers le VPC.
Blackfoot
Que faire dans les cas où le trafic doit être transmis à l'extérieur, par exemple vers Internet ou via VPN vers le sol ? Cela nous aide ici Blackfoot — Service interne AWS. Il est développé par notre équipe sud-africaine. C'est pourquoi le service porte le nom d'un pingouin qui vit en Afrique du Sud.
Blackfoot décapsule le trafic et en fait ce qui est nécessaire. Les données sont envoyées telles quelles sur Internet.
Les données sont décapsulées et réencapsulées dans IPsec lors de l'utilisation d'un VPN.
Lors de l'utilisation de Direct Connect, le trafic est balisé et envoyé au VLAN approprié.
HyperPlan
Il s'agit d'un service de contrôle de flux interne. De nombreux services réseau nécessitent une surveillance états 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 d'un é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 avec état. Il surveille le trafic entrant et ouvre implicitement des ports pour le flux de paquets sortants.
Dans le cloud AWS, les exigences en matière de latence de transmission sont extrêmement élevées. C'est pourquoi HyperPlan critique pour la performance 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. Le truc, c’est qu’il s’agit de machines virtuelles dotées d’une grande RAM. Les opérations sont transactionnelles et effectuées exclusivement en mémoire. Cela vous permet d'obtenir des retards de seulement quelques dizaines de microsecondes. Travailler avec le disque tuerait toute productivité.
Hyperplane est un système distribué composé d'un grand nombre de machines EC2 de ce type. Chaque machine virtuelle dispose d'une bande passante de 5 Go/s. Sur l'ensemble du réseau régional, cela fournit des térabits de bande passante incroyables et permet de traiter millions de connexions par seconde.
HyperPlane ne fonctionne qu'avec les flux. L’encapsulation des paquets VPC est totalement transparente. Une vulnérabilité potentielle dans ce service interne empêcherait toujours la rupture de l’isolation du VPC. Les niveaux ci-dessous sont responsables de la sécurité.
Voisin bruyant
Il y a toujours un problème voisin bruyant - voisin bruyant. Supposons que nous ayons 8 nœuds. Ces nœuds traitent les flux de tous les utilisateurs du cloud. Tout semble bien se passer et la charge devrait être répartie uniformément sur tous les nœuds. Les nœuds sont très puissants et il est difficile de les surcharger.
Mais nous construisons notre architecture sur la base de scénarios même improbables.
Une faible probabilité ne signifie pas impossible.
On peut imaginer une situation dans laquelle un ou plusieurs utilisateurs généreraient trop de charge. Tous les nœuds HyperPlane sont impliqués dans le traitement de cette charge et les autres utilisateurs pourraient potentiellement subir une sorte de baisse de performances. Cela brise le concept du cloud, dans lequel les locataires n'ont aucune possibilité 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 de 2 nœuds chacun. Désormais, un voisin bruyant ne dérangera qu'un quart de tous les utilisateurs, mais il les dérangera grandement.
Faisons les choses différemment. Nous allouerons seulement 3 nœuds à chaque utilisateur.
L'astuce consiste à attribuer des nœuds de manière aléatoire à différents utilisateurs. Dans l'image ci-dessous, l'utilisateur bleu croise des nœuds avec l'un des deux autres utilisateurs – vert et orange.
Avec 8 nœuds et 3 utilisateurs, la probabilité qu'un voisin bruyant croise l'un des utilisateurs est de 54 %. C'est avec cette probabilité qu'un utilisateur bleu influencera les autres locataires. En même temps, seulement une partie de sa charge. Dans notre exemple, cette influence sera au moins d'une manière ou d'une autre perceptible non pas par tout le monde, mais seulement par un tiers de tous les utilisateurs. C'est déjà un bon résultat.
Nombre d'utilisateurs qui se croiseront
Probabilité en pourcentage
0
18%
1
54%
2
26%
3
2%
Rapprochons la situation de la réalité - prenons 100 nœuds et 5 utilisateurs sur 5 nœuds. Dans ce cas, aucun des nœuds ne se croisera avec une probabilité de 77 %.
Nombre d'utilisateurs qui se croiseront
Probabilité en pourcentage
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
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 mélange de partitionnement - partitionnement aléatoire. 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'ampleur du réseau lui-même. Pour octobre 2019, AWS propose ses services en 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 de données. Il n'y en a pas plus de 8 au total.
- Le centre de données héberge un grand nombre de serveurs, certains en comptant jusqu'à 300 000.
Maintenant, faisons la moyenne de tout cela, multiplions et obtenons un chiffre impressionnant qui reflète Échelle du cloud Amazon.
Il existe de nombreuses liaisons optiques entre les zones de disponibilité et le centre de données. Dans l'une de nos plus grandes régions, 388 canaux ont été posés uniquement pour la communication AZ entre eux et les centres de communication avec d'autres régions (centres de transit). Au total ça donne du fou 5000 XNUMX Tbits.
Backbone AWS est spécialement conçu et optimisé pour le cloud. Nous le construisons sur les chaînes 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 d'autres sociétés.
Bien entendu, nous ne sommes pas le seul fournisseur de cloud à disposer d’un réseau fédérateur privé. De plus en plus de grandes entreprises suivent cette voie. Ceci est confirmé par des chercheurs indépendants, par exemple de .
Le graphique montre que la part des fournisseurs de contenu et des fournisseurs de cloud augmente. De ce fait, la part du trafic Internet des fournisseurs de backbone est en constante diminution.
Je vais vous expliquer pourquoi cela se produit. Auparavant, la plupart des services Web étaient accessibles et consommés directement depuis Internet. De nos jours, de plus en plus de serveurs sont situés dans le cloud et sont accessibles via CAN - Réseau de distribution de contenu. Pour accéder à une ressource, l'utilisateur passe par Internet uniquement jusqu'au PoP CDN le plus proche - Point de présence. Le plus souvent, c'est quelque part à proximité. Il quitte ensuite l’Internet public et traverse par exemple l’Atlantique via un réseau fédérateur privé pour atteindre directement la ressource.
Je me demande comment Internet va évoluer 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 ils ont fait de grands progrès dans les méthodes de transmission par fibre optique. Nous utilisons actuellement 6912 câbles 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 chaînes sont endommagées. La photo de droite montre des câbles optiques déchirés par des ouvriers du bâtiment dans l'une des régions américaines. À la suite de l'accident, seuls 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 secours - la balance fonctionne.
Nous avons galopé à travers 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, je trouve cela très excitant.
Il s'agit de la dernière partie de la trilogie de Vasily Pantyukhin sur le périphérique AWS. DANS les parties décrivent l'optimisation du serveur et la mise à l'échelle de la base de données, et dans — fonctions sans serveur et Firecracker.
Sur en novembre, Vasily Pantyukhin partagera de nouveaux détails sur l'appareil Amazon. Il sur les causes des pannes et la conception des systèmes distribués chez Amazon. Le 24 octobre est encore possible billet à un bon prix et payez plus tard. Nous vous attendons chez HighLoad++, venez discuter !
Source: habr.com