{"id":39304,"date":"2019-10-31T22:29:40","date_gmt":"2019-10-31T19:29:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti\/"},"modified":"2019-10-31T22:29:40","modified_gmt":"2019-10-31T19:29:40","slug":"kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","title":{"rendered":"Comment AWS \u00ab pr\u00e9pare \u00bb ses services \u00e9lastiques. Mise \u00e0 l'\u00e9chelle du r\u00e9seau","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

L'\u00e9chelle du r\u00e9seau Amazon Web Services s'\u00e9tend sur 69 zones \u00e0 travers le monde dans 22 r\u00e9gions : \u00c9tats-Unis, Europe, Asie, Afrique et Australie. Chaque zone abrite jusqu'\u00e0 8 centres de donn\u00e9es. Dans chaque centre de donn\u00e9es, il y a des milliers ou des centaines de milliers de serveurs. Le r\u00e9seau est con\u00e7u pour prendre en compte tous les sc\u00e9narios d'interruption peu probables. Par exemple, toutes les r\u00e9gions sont isol\u00e9es les unes des autres, et les zones de disponibilit\u00e9 sont s\u00e9par\u00e9es par plusieurs kilom\u00e8tres. M\u00eame si un c\u00e2ble est coup\u00e9, le syst\u00e8me basculera vers des canaux de secours, et la perte d'informations sera de quelques paquets de donn\u00e9es. Les principes sur lesquels le r\u00e9seau est construit et son fonctionnement seront expliqu\u00e9s par Vasily Pantiukhin.<\/p>\n

\"Comment
\n
\nVassili Pantioukhine<\/b> a commenc\u00e9 en tant qu'administrateur Unix dans des entreprises .ru, a pass\u00e9 6 ans sur de grands \u00e9quipements Sun Microsystem, et 11 ans \u00e0 pr\u00f4ner la centralit\u00e9 des donn\u00e9es chez EMC. Il a \u00e9volu\u00e9 naturellement vers les clouds priv\u00e9s, puis vers les publics. Actuellement, en tant qu'architecte d'Amazon Web Services, il apporte des conseils techniques pour vivre et se d\u00e9velopper dans le cloud AWS.<\/p>\n

Dans la partie pr\u00e9c\u00e9dente de la trilogie sur l'architecture d'AWS, Vasily s'est plong\u00e9 dans la structure des serveurs physiques et l'escalade des bases de donn\u00e9es. Les cartes Nitro, l'hyperviseur personnalis\u00e9 bas\u00e9 sur KVM, la base de donn\u00e9es Amazon Aurora \u2014 tout cela est abord\u00e9 dans le mat\u00e9riel \"Comment AWS \u00ab pr\u00e9pare \u00bb ses services \u00e9lastiques. Mise \u00e0 l'\u00e9chelle des serveurs et des bases de donn\u00e9es<\/a><\/noindex>\". Lisez-le pour plonger dans le contexte, ou regardez enregistrement vid\u00e9o<\/a><\/noindex> des pr\u00e9sentations.<\/p>\n

Dans cette partie, nous allons parler de l'escalade du r\u00e9seau \u2014 l'un des syst\u00e8mes les plus complexes d'AWS. L'\u00e9volution d'un r\u00e9seau plat vers le Virtual Private Cloud et sa structure, les services internes Blackfoot et HyperPlane, le probl\u00e8me du voisin bruyant, et \u00e0 la fin \u2014 l'\u00e9chelle du r\u00e9seau, le backbone et les c\u00e2bles physiques. Tout cela est plus loin.<\/p>\n

Avertissement : tout ce qui suit est l'avis personnel de Vasily et peut ne pas correspondre \u00e0 la position d'Amazon Web Services.<\/i>
\n<\/a><\/noindex><\/p>\n

Mise \u00e0 l'\u00e9chelle du r\u00e9seau<\/h2>\n

\nLe cloud AWS a \u00e9t\u00e9 lanc\u00e9 en 2006. Son r\u00e9seau \u00e9tait assez primitif \u2014 avec une structure plate. La plage d'adresses priv\u00e9es \u00e9tait commune \u00e0 tous les locataires du cloud. Lors du lancement d'une nouvelle machine virtuelle, vous receviez accidentellement une adresse IP disponible de cette plage.<\/p>\n

\"Comment
\n
\nCette approche \u00e9tait simple \u00e0 mettre en \u0153uvre, mais limitait fondamentalement l'utilisation du cloud. En particulier, il \u00e9tait assez difficile de d\u00e9velopper des solutions hybrides combinant des r\u00e9seaux priv\u00e9s sur site et dans AWS. Le probl\u00e8me le plus courant \u00e9tait le chevauchement des plages d'adresses IP.<\/p>\n

\"Comment
\n<\/p>\n

Virtual Private Cloud<\/h3>\n

\nLe cloud s'est av\u00e9r\u00e9 tr\u00e8s demand\u00e9. Il est temps de r\u00e9fl\u00e9chir \u00e0 l'\u00e9volutivit\u00e9 et \u00e0 la possibilit\u00e9 de son utilisation par des dizaines de millions de locataires. Le r\u00e9seau plat est devenu le principal obstacle. C'est pourquoi nous avons r\u00e9fl\u00e9chi \u00e0 la mani\u00e8re d'isoler les utilisateurs les uns des autres au niveau r\u00e9seau afin qu'ils puissent choisir eux-m\u00eames leurs plages d'IP.<\/p>\n

\"Comment
\n
\nQue vous vient-il \u00e0 l'esprit lorsque vous pensez \u00e0 l'isolation r\u00e9seau ? Bien s\u00fbr VLAN<\/b> et VRF \u2014 Virtual Routing and Forwarding<\/b>.<\/p>\n

Malheureusement, cela n'a pas fonctionn\u00e9. L'ID VLAN est de seulement 12 bits, ce qui ne nous donne que 4096 segments isol\u00e9s. M\u00eame dans les plus grands commutateurs, on peut utiliser au maximum 1 \u00e0 2 milliers de VRF. Le partage de VRF et VLAN ne nous donne que quelques millions de sous-r\u00e9seaux. C'est d\u00e9finitivement insuffisant pour des dizaines de millions de locataires, chacun d'eux devant avoir la possibilit\u00e9 d'utiliser plusieurs sous-r\u00e9seaux.<\/p>\n

De plus, nous ne pouvons tout simplement pas nous permettre d'acheter le nombre n\u00e9cessaire de grosses unit\u00e9s, par exemple, chez Cisco ou Juniper. Il y a deux raisons : c'est horriblement cher, et nous ne voulons pas d\u00e9pendre de leur politique de d\u00e9veloppement et de mise \u00e0 jour.<\/p>\n

Une conclusion s'impose \u2013 il faut cr\u00e9er sa propre solution.<\/p><\/blockquote>\n

\nEn 2009, nous avons annonc\u00e9 VPC<\/b> \u2014 Virtual Private Cloud<\/b>. Le nom a pris racine et maintenant de nombreux fournisseurs de cloud l'utilisent \u00e9galement.<\/p>\n

VPC \u2013 c'est un r\u00e9seau virtuel SDN<\/b> (Software Defined Network). Nous avons d\u00e9cid\u00e9 de ne pas inventer de protocoles sp\u00e9ciaux aux niveaux L2 et L3. Le r\u00e9seau fonctionne sur Ethernet et IP standard. Pour le transfert de trafic sur le r\u00e9seau, le trafic des machines virtuelles est encapsul\u00e9 dans un wrapper de notre propre protocole. Il sp\u00e9cifie un ID, qui appartient au locataire VPC.<\/p>\n

\"Comment
\n
\nCela semble simple. Cependant, il faut r\u00e9soudre plusieurs probl\u00e8mes techniques s\u00e9rieux. Par exemple, o\u00f9 et comment stocker les donn\u00e9es sur le mappage des adresses MAC\/IP virtuelles, l'ID VPC et les MAC\/IP physiques correspondants. \u00c0 l'\u00e9chelle d'AWS, il s'agit d'une \u00e9norme table qui doit fonctionner avec un minimum de latence lors des requ\u00eates. Cela est g\u00e9r\u00e9 par le service de mappage<\/b>, qui est r\u00e9parti en couche fine sur tout le r\u00e9seau.<\/p>\n

Dans les machines de nouvelle g\u00e9n\u00e9ration, l'encapsulation est effectu\u00e9e par des cartes Nitro au niveau mat\u00e9riel. Dans les anciennes instances, l'encapsulation et la d\u00e9capsulation sont effectu\u00e9es par logiciel.\u00a0<\/p>\n

\"Comment
\n
\nVoyons comment cela fonctionne en termes g\u00e9n\u00e9raux. Commen\u00e7ons par le niveau L2. Supposons que nous avons une machine virtuelle avec l'IP 10.0.0.2 sur un serveur physique 192.168.0.3. Elle envoie des donn\u00e9es \u00e0 la machine virtuelle 10.0.0.3, qui se trouve \u00e0 l'adresse 192.168.1.4. Une requ\u00eate ARP est g\u00e9n\u00e9r\u00e9e, qui est envoy\u00e9e \u00e0 la carte r\u00e9seau Nitro. Pour simplifier, consid\u00e9rons que les deux machines virtuelles se trouvent dans le m\u00eame VPC \u00ab bleu \u00bb.<\/p>\n

\"Comment
\n
\nLa carte remplace l'adresse source par la sienne et transmet le cadre ARP au service de mappage.<\/p>\n

\"Comment
\n
\nLe service de mappage renvoie les informations n\u00e9cessaires pour la transmission sur le r\u00e9seau physique L2.<\/p>\n

\"Comment
\n
\nLa carte Nitro dans la r\u00e9ponse ARP remplace l'adresse MAC dans le r\u00e9seau physique par une adresse dans le VPC.<\/p>\n

\"Comment
\n
\nLors de la transmission de donn\u00e9es, nous enveloppons les MAC et les IP logiques dans un wrapper VPC. Nous transmettons tout cela sur le r\u00e9seau physique \u00e0 l'aide des adresses IP des cartes Nitro source et destination.<\/p>\n

\"Comment
\n
\nLa machine physique \u00e0 laquelle le paquet est destin\u00e9 effectue une v\u00e9rification. Cela est n\u00e9cessaire pour emp\u00eacher toute substitution d'adresses. La machine envoie une requ\u00eate sp\u00e9ciale au service de mappage et demande : \u00ab De la machine physique 192.168.0.3, j'ai re\u00e7u un paquet destin\u00e9 \u00e0 10.0.0.3 dans le VPC \u00ab bleu \u00bb. Est-il l\u00e9gitime ? \u00bb\u00a0<\/p>\n

\"Comment
\n
\nLe service de mappage v\u00e9rifie sa table d'emplacement des ressources et autorise ou intercepte la transmission du paquet. Dans tous les nouveaux instances, une validation suppl\u00e9mentaire est int\u00e9gr\u00e9e dans les cartes Nitro. Celle-ci ne peut pas \u00eatre contourn\u00e9e m\u00eame th\u00e9oriquement. Par cons\u00e9quent, le spoofing sur des ressources dans un autre VPC ne fonctionnera pas.<\/p>\n

\"Comment
\n
\nLes donn\u00e9es sont ensuite envoy\u00e9es \u00e0 la machine virtuelle pour laquelle elles sont destin\u00e9es.\u00a0<\/p>\n

\"Comment
\n
\nLe service de mappage agit \u00e9galement comme un routeur logique pour la transmission de donn\u00e9es entre les machines virtuelles dans diff\u00e9rents sous-r\u00e9seaux. Conceptuellement, c'est assez simple, je ne vais pas le d\u00e9tailler.<\/p>\n

\"Comment
\n
\nAinsi, \u00e0 chaque transmission de paquet, les serveurs se dirigent vers le service de mappage. Comment faire face aux d\u00e9lais in\u00e9vitables ? Par le cache.<\/b>Bien s\u00fbr.<\/p>\n

Tout le charme est que vous n'avez pas besoin de mettre en cache l'\u00e9norme table enti\u00e8re. Sur le serveur physique vivent des machines virtuelles provenant d'un nombre relativement restreint de VPC. Il n'est n\u00e9cessaire de mettre en cache que les informations concernant ces VPC. La transmission de donn\u00e9es vers d'autres VPC en configuration \u00ab par d\u00e9faut \u00bb n'est de toute fa\u00e7on pas l\u00e9gitime. Si une fonctionnalit\u00e9 telle que le VPC-peering est utilis\u00e9e, des informations sur les VPC correspondants sont ajout\u00e9es au cache.\u00a0<\/p>\n

\"Comment
\n
\nNous avons compris le transfert de donn\u00e9es dans le VPC.<\/p>\n

Blackfoot<\/h3>\n

\nQue faire dans les cas o\u00f9 le trafic doit \u00eatre envoy\u00e9 \u00e0 l'ext\u00e9rieur, par exemple sur Internet ou via un VPN vers la terre ? Ici, nous sommes sauv\u00e9s par Blackfoot<\/b> \u2014 un service interne AWS. Il a \u00e9t\u00e9 d\u00e9velopp\u00e9 par notre \u00e9quipe sud-africaine. C'est pourquoi le service porte le nom d'un pingouin vivant en Afrique du Sud.<\/p>\n

\"Comment
\n
\nBlackfoot d\u00e9compresse le trafic et en fait ce qu'il faut. Les donn\u00e9es sont envoy\u00e9es sur Internet telles quelles.<\/p>\n

\"Comment
\n
\nLes donn\u00e9es sont d\u00e9compress\u00e9es et re-encapsul\u00e9es dans un emballage IPsec lors de l'utilisation de VPN.<\/p>\n

\"Comment
\n
\nLors de l'utilisation de Direct Connect, le trafic est \u00e9tiquet\u00e9 et transmis dans le VLAN correspondant.<\/p>\n

\"Comment
\n<\/p>\n

HyperPlane<\/h3>\n

\nC'est un service interne de contr\u00f4le du flux. De nombreux services r\u00e9seau n\u00e9cessitent un contr\u00f4le de l'\u00e9tat du flux de donn\u00e9es<\/b>. Par exemple, lors de l'utilisation de NAT, le contr\u00f4le du flux doit garantir qu'\u00e0 chaque paire \u00ab IP: port de destination \u00bb, il correspond un port sortant unique. Dans le cas d'un \u00e9quilibreur de charge NLB<\/b> \u2014 Network Load Balancer<\/b>, le flux de donn\u00e9es doit toujours \u00eatre dirig\u00e9 vers la m\u00eame machine virtuelle cible. Les Groupes de S\u00e9curit\u00e9 sont un pare-feu avec \u00e9tat. Il surveille le trafic entrant et ouvre implicitement des ports pour le flux sortant de paquets.<\/p>\n

\"Comment
\n
\nDans le cloud AWS, les exigences en mati\u00e8re de latence de transmission sont extr\u00eamement \u00e9lev\u00e9es. C'est pourquoi HyperPlane<\/b> est critique pour le bon fonctionnement de l'ensemble du r\u00e9seau.<\/p>\n

\"Comment
\n
\nHyperplane est construit sur des machines virtuelles EC2. Il n'y a pas de magie ici, juste de l'astuce. L'astuce est que ce sont des VM avec une grande RAM. Les op\u00e9rations sont transactionnelles et se font uniquement en m\u00e9moire. Cela permet d'atteindre des latences de quelques dizaines de microsecondes. Travailler avec le disque ruinerait toute performance.\u00a0<\/p>\n

Hyperplane est un syst\u00e8me distribu\u00e9 compos\u00e9 d'un grand nombre de machines EC2. Chaque machine virtuelle a une bande passante de 5 Go\/s. \u00c0 l'\u00e9chelle de l'ensemble du r\u00e9seau r\u00e9gional, cela offre des t\u00e9ra-octets de bande passante incroyable et permet de traiter des millions de connexions par seconde<\/b>.<\/p>\n

HyperPlane ne fonctionne qu'avec des flux. L'encapsulation de paquets VPC est compl\u00e8tement transparente pour lui. Une \u00e9ventuelle vuln\u00e9rabilit\u00e9 dans ce service interne ne permettra pas de briser l'isolement VPC. La s\u00e9curit\u00e9 est assur\u00e9e par les niveaux inf\u00e9rieurs.<\/p>\n

Voisin bruyant<\/h3>\n

\nIl y a encore un probl\u00e8me de voisin bruyant<\/b> \u2014 voisin bruyant<\/b>. Supposons que nous ayons 8 n\u0153uds. Ces n\u0153uds traitent les flux de tous les utilisateurs du cloud. Tout semble en ordre et la charge devrait \u00eatre r\u00e9partie de mani\u00e8re homog\u00e8ne entre tous les n\u0153uds. Les n\u0153uds sont tr\u00e8s puissants et il est difficile de les surcharge.<\/p>\n

Mais nous construisons notre architecture en tenant m\u00eame compte des sc\u00e9narios peu probables.\u00a0<\/p>\n

Une faible probabilit\u00e9 ne signifie pas impossibilit\u00e9.<\/p><\/blockquote>\n

\nNous pouvons envisager une situation o\u00f9 un ou plusieurs utilisateurs g\u00e9n\u00e8rent une charge trop importante. Toutes les n\u0153uds HyperPlane sont impliqu\u00e9es dans le traitement de cette charge, et d'autres utilisateurs pourraient ressentir une certaine diminution de la performance. Cela d\u00e9truit le concept de cloud, o\u00f9 les tenants n'ont pas la possibilit\u00e9 d'influencer les autres.<\/p>\n

\"Comment
\n
\nComment r\u00e9soudre le probl\u00e8me du voisin bruyant ? La premi\u00e8re id\u00e9e qui vient \u00e0 l'esprit est le sharding. Nos 8 n\u0153uds sont logiquement divis\u00e9s en 4 shards de 2 n\u0153uds chacun. Maintenant, le voisin bruyant ne g\u00eanera qu\u2019un quart de tous les utilisateurs, mais cela peut \u00eatre significatif.<\/p>\n

\"Comment
\n
\nAdoptons une approche diff\u00e9rente. Allouons uniquement 3 n\u0153uds \u00e0 chaque utilisateur.\u00a0<\/p>\n

\"Comment
\n
\nL'astuce consiste \u00e0 attribuer des n\u0153uds \u00e0 diff\u00e9rents utilisateurs de mani\u00e8re al\u00e9atoire. Sur l'image ci-dessous, l'utilisateur bleu partage des n\u0153uds avec l'un des deux autres utilisateurs \u2014 le vert et l'orange.<\/p>\n

\"Comment
\n
\nAvec 8 n\u0153uds et 3 utilisateurs, la probabilit\u00e9 de chevauchement du voisin bruyant avec un des utilisateurs est de 54 %. C'est avec cette probabilit\u00e9 que l'utilisateur bleu impactera les autres tenants. Cependant, il ne le fera qu'avec une partie de sa charge. Dans notre exemple, cet impact ne sera pas perceptible pour tout le monde, mais seulement pour un tiers de tous les utilisateurs. C\u2019est d\u00e9j\u00e0 un bon r\u00e9sultat.<\/p>\n

Le nombre d'utilisateurs qui se chevauchent<\/p>\n

La probabilit\u00e9 en pourcentage<\/p>\n

0<\/p>\n

18%<\/p>\n

1<\/p>\n

54%<\/p>\n

2<\/p>\n

26%<\/p>\n

3<\/p>\n

2%<\/p>\n

Rapprochons la situation de la r\u00e9alit\u00e9 \u2014 prenons 100 n\u0153uds et 5 utilisateurs sur 5 n\u0153uds. Dans ce cas, aucune des n\u0153uds ne se chevauchera avec une probabilit\u00e9 de 77%.\u00a0<\/p>\n

Le nombre d'utilisateurs qui se chevauchent<\/p>\n

La probabilit\u00e9 en pourcentage<\/p>\n

0<\/p>\n

77%<\/p>\n

1<\/p>\n

21%<\/p>\n

2<\/p>\n

1,8%<\/p>\n

3<\/p>\n

0,06%<\/p>\n

4<\/p>\n

0,0006%<\/p>\n

5<\/p>\n

0,00000013%<\/p>\n

Dans une situation r\u00e9elle avec un grand nombre de n\u0153uds HyperPlane et d'utilisateurs, l'impact potentiel d'un voisin bruyant sur les autres utilisateurs est minimal. Cette m\u00e9thode s'appelle le sharding al\u00e9atoire<\/b> \u2014 shuffle sharding<\/b>. Elle minimise l'effet n\u00e9gatif du dysfonctionnement de n\u0153uds.<\/p>\n

De nombreux services sont construits sur HyperPlane : Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n

L'\u00e9chelle du r\u00e9seau<\/h3>\n

\nParlons maintenant de l'\u00e9chelle du r\u00e9seau lui-m\u00eame. En octobre 2019, AWS propose ses services dans 22 r\u00e9gions<\/b>, et 9 autres sont pr\u00e9vues.<\/p>\n