{"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\/de\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","title":{"rendered":"Wie AWS seine elastischen Services zubereitet. Netzwerkskalierung","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Infrastruktur von Amazon Web Services umfasst 69 Availability Zones in 22 Regionen weltweit: USA, Europa, Asien, Afrika und Australien. Jede Zone beherbergt bis zu 8 Rechenzentren. In jedem Rechenzentrum befinden sich Tausende oder Hunderttausende von Servern. Das Netzwerk ist so aufgebaut, dass selbst die unwahrscheinlichsten Szenarien von Ausf\u00e4llen ber\u00fccksichtigt werden. Zum Beispiel sind alle Regionen voneinander isoliert und die Availability Zones sind mehrere Kilometer voneinander entfernt. Selbst bei einem Kabelbruch wechselt das System auf Backup-Kan\u00e4le, wobei der Verlust an Informationen nur einzelne Datenpakete umfasst. Vasily Pantyukhin wird erl\u00e4utern, auf welchen weiteren Prinzipien das Netzwerk basiert und wie es funktioniert.<\/p>\n

\"Wie
\n
\nWassili Pantjuchin<\/b> Er begann als Unix-Admin in .ru-Unternehmen, arbeitete 6 Jahre lang mit gro\u00dfen Ger\u00e4ten von Sun Microsystems und predigte 11 Jahre lang die Datenzentriertheit der Welt bei EMC. Nat\u00fcrlich entwickelte er sich in private Clouds weiter und wandte sich dann \u00f6ffentlichen zu. Heute unterst\u00fctzt er als Architekt bei Amazon Web Services mit technischen Ratschl\u00e4gen, um im AWS-Cloud-Umfeld erfolgreich zu leben und zu wachsen.<\/p>\n

Im vorherigen Teil der Trilogie \u00fcber AWS hat Wasilij die Architektur physischer Server und das Skalieren von Datenbanken vertieft. Nitro-Karten, ein benutzerdefinierter Hypervisor auf KVM-Basis und die Amazon Aurora-Datenbank \u2013 all dies finden Sie im Artikel \u201eWie AWS seine elastischen Dienste \"zaubert\". Skalierung von Servern und Datenbanken<\/a><\/noindex>\u201c. Lesen Sie weiter, um in den Kontext einzutauchen, oder sehen Sie sich die Aufzeichnung<\/a><\/noindex> der Pr\u00e4sentation an.<\/p>\n

In diesem Teil geht es um das Skalieren des Netzwerks \u2013 eines der komplexesten Systeme in AWS. Die Entwicklung von einem flachen Netzwerk zu einem Virtual Private Cloud und dessen Struktur, die internen Dienste Blackfoot und HyperPlane, das Problem des lauten Nachbarn und schlie\u00dflich die Netzmasse, das Backbone und die physischen Kabel. All dies im Folgenden.<\/p>\n

Haftungsausschluss: Alles, was folgt, ist Wasilijs pers\u00f6nliche Meinung und k\u00f6nnte von der Position von Amazon Web Services abweichen.<\/i>
\n<\/a><\/noindex><\/p>\n

Netzwerkskalierung<\/h2>\n

\nDie AWS-Cloud wurde 2006 gestartet. Ihr Netzwerk war recht primitiv \u2013 mit einer flachen Struktur. Der Bereich der privaten Adressen war f\u00fcr alle Tenants der Cloud gemeinsam. Bei der Bereitstellung einer neuen virtuellen Maschine erhielten Sie zuf\u00e4llig eine verf\u00fcgbare IP-Adresse aus diesem Bereich.<\/p>\n

\"Wie
\n
\nDieser Ansatz lie\u00df sich einfach umsetzen, schr\u00e4nkte jedoch die Nutzung der Cloud grundlegend ein. Insbesondere war es recht schwierig, hybride L\u00f6sungen zu entwickeln, die private Netzwerke sowohl vor Ort als auch in AWS kombinierten. Das h\u00e4ufigste Problem war die \u00dcberlappung von IP-Adressbereichen.<\/p>\n

\"Wie
\n<\/p>\n

Virtual Private Cloud<\/h3>\n

\nDie Cloud erwies sich als sehr gefragt. Es wurde Zeit, \u00fcber die Skalierbarkeit und die M\u00f6glichkeit nachzudenken, sie von Millionen von Nutzern verwenden zu lassen. Das flache Netzwerk wurde zum Hauptgegenstand der Herausforderungen. Daher \u00fcberlegten wir, wie wir Nutzer auf Netzwerkebene voneinander isolieren k\u00f6nnen, sodass sie selbst IP-Bereiche ausw\u00e4hlen k\u00f6nnen.<\/p>\n

\"Wie
\n
\nWas f\u00e4llt Ihnen zuerst ein, wenn Sie an Netzisolierung denken? Nat\u00fcrlich VLAN<\/b> und VRF \u2014 Virtual Routing and Forwarding<\/b>.<\/p>\n

Leider hat es nicht funktioniert. VLAN-ID ist nur 12 Bit lang, was uns lediglich 4096 isolierte Segmente erm\u00f6glicht. Selbst in den gr\u00f6\u00dften Switches k\u00f6nnen maximal 1-2 Tausend VRF verwendet werden. Die Kombination aus VRF und VLAN ergibt nur wenige Millionen Subnetze. Das ist definitiv zu wenig f\u00fcr Zehntausende von Tenants, von denen jeder die M\u00f6glichkeit haben sollte, mehrere Subnetze zu nutzen.<\/p>\n

Au\u00dferdem k\u00f6nnen wir uns einfach nicht leisten, die erforderliche Anzahl gro\u00dfer Ger\u00e4te von Anbietern wie Cisco oder Juniper zu kaufen. Es gibt zwei Gr\u00fcnde daf\u00fcr: Es ist extrem teuer, und wir m\u00f6chten nicht von deren Entwicklungs- und Patch-Politik abh\u00e4ngig sein.<\/p>\n

Die einzige L\u00f6sung ist, eine eigene L\u00f6sung zu entwickeln.<\/p><\/blockquote>\n

\nIm Jahr 2009 haben wir angek\u00fcndigt VPC<\/b> \u2014 Virtual Private Cloud<\/b>. Der Name hat sich durchgesetzt und wird jetzt auch von vielen Cloud-Anbietern verwendet.<\/p>\n

VPC ist ein virtuelles Netzwerk SDN<\/b> (Software Defined Network). Wir haben uns entschieden, keine speziellen Protokolle auf den Ebenen L2 und L3 zu entwickeln. Das Netzwerk funktioniert auf Standard-Ethernet und IP. Um den Datenverkehr von virtuellen Maschinen \u00fcber das Netzwerk zu transportieren, wird er in das Format unseres eigenen Protokolls eingekapselt. Dabei wird eine ID angegeben, die zu dem VPC-tenant geh\u00f6rt.<\/p>\n

\"Wie
\n
\nDas klingt einfach. Allerdings m\u00fcssen mehrere ernsthafte technische Herausforderungen gemeistert werden. Zum Beispiel, wo und wie die Daten zur Zuordnung von virtuellen MAC-\/IP-Adressen, VPC-ID und den entsprechenden physischen MAC-\/IP-Adressen gespeichert werden. Im Ma\u00dfstab von AWS ist dies eine riesige Tabelle, die mit minimalen Verz\u00f6gerungen beim Zugriff arbeiten muss. Daf\u00fcr ist verantwortlich der Mapping-Service<\/b>, der d\u00fcnn \u00fcber das gesamte Netzwerk verteilt ist.<\/p>\n

In modernen Maschinen erfolgt die Kapselung durch Nitro-Karten auf hardwareseitiger Ebene. Bei \u00e4lteren Instanzen geschieht die Kapselung und Dekapselung softwareseitig.\u00a0<\/p>\n

\"Wie
\n
\nLassen Sie uns kl\u00e4ren, wie das im Gro\u00dfen und Ganzen funktioniert. Beginnen wir auf der L2-Ebene. Angenommen, wir haben eine virtuelle Maschine mit der IP 10.0.0.2 auf einem physischen Server mit der IP 192.168.0.3. Diese sendet Daten an eine virtuelle Maschine mit der IP 10.0.0.3, die auf der 192.168.1.4 lebt. Ein ARP-Anfrage wird generiert, die die Netzwerkkarte von Nitro erreicht. Der Einfachheit halber gehen wir davon aus, dass sich beide virtuellen Maschinen im selben \u201eblauen\u201c VPC befinden.<\/p>\n

\"Wie
\n
\nDie Karte ersetzt die Quelladresse durch ihre eigene und leitet das ARP-Frame an den Mapping-Service weiter.<\/p>\n

\"Wie
\n
\nDer Mapping-Service liefert die Informationen zur\u00fcck, die f\u00fcr die \u00dcbertragung \u00fcber das physische L2-Netzwerk erforderlich sind.<\/p>\n

\"Wie
\n
\nDie Nitro-Karte im ARP-Antwort ersetzt die MAC-Adresse im physischen Netzwerk durch die Adresse in der VPC.<\/p>\n

\"Wie
\n
\nBei der Daten\u00fcbertragung kapseln wir die logischen MAC- und IP-Adressen in eine VPC-H\u00fclle. All dies wird \u00fcber das physische Netzwerk mit den entsprechenden IP-Nitro-Karten von Quelle und Ziel \u00fcbertragen.<\/p>\n

\"Wie
\n
\nDer physische Server, der f\u00fcr das Paket bestimmt ist, f\u00fchrt eine \u00dcberpr\u00fcfung durch. Dies geschieht, um eine Adress\u00e4nderung zu verhindern. Der Server sendet eine spezielle Anfrage an den Mapping-Dienst und fragt: \"Von dem physischen Server 192.168.0.3 habe ich ein Paket erhalten, das f\u00fcr 10.0.0.3 im 'blauen' VPC bestimmt ist. Ist es legitim?\"\u00a0<\/p>\n

\"Wie
\n
\nDer Mapping-Dienst vergleicht und pr\u00fcft seine Ressourcen-Zuordnungstabelle und erlaubt oder verbietet das Durchleiten des Pakets. In allen neuen Instanzen ist eine zus\u00e4tzliche Validierung in den Nitro-Karten integriert. Diese kann theoretisch nicht umgangen werden. Daher wird Spoofing auf Ressourcen in einer anderen VPC nicht funktionieren.<\/p>\n

\"Wie
\n
\nAnschlie\u00dfend werden die Daten an die virtuelle Maschine gesendet, f\u00fcr die sie bestimmt sind.\u00a0<\/p>\n

\"Wie
\n
\nDer Mapping-Dienst fungiert auch als logischer Router f\u00fcr die Daten\u00fcbertragung zwischen virtuellen Maschinen in unterschiedlichen Subnetzen. Grunds\u00e4tzlich ist alles einfach, ich werde nicht ins Detail gehen.<\/p>\n

\"Wie
\n
\nWenn jeder Datenpaket \u00fcbertragen wird, greifen die Server auf den Mappingsdienst zu. Wie geht man mit unvermeidlichen Verz\u00f6gerungen um? Durch Caching.<\/b>, nat\u00fcrlich.<\/p>\n

Das Sch\u00f6ne daran ist, dass man nicht die gesamte gro\u00dfe Tabelle cachen muss. Auf einem physischen Server leben virtuelle Maschinen aus einer relativ kleinen Anzahl von VPCs. Es ist nur notwendig, Informationen \u00fcber diese VPCs zu cachen. Der Datenverkehr zu anderen VPCs ist in der \"Standard\"-Konfiguration dennoch nicht legitim. Wenn Funktionen wie VPC-Peering genutzt werden, wird zus\u00e4tzlich Informationen \u00fcber die entsprechenden VPCs ins Cache geladen.\u00a0<\/p>\n

\"Wie
\n
\nWir haben den Datenaustausch mit VPCs gekl\u00e4rt.<\/p>\n

Blackfoot<\/h3>\n

\nWas ist in F\u00e4llen, wenn der Datenverkehr nach au\u00dfen, zum Beispiel ins Internet oder \u00fcber VPN ins Ausland, weitergegeben werden muss? Hier hilft uns Blackfoot<\/b> \u2014 ein interner AWS-Dienst. Er wurde von unserem s\u00fcdafrikanischen Team entwickelt. Daher tr\u00e4gt der Dienst den Namen eines Pinguins, der in S\u00fcdafrika lebt.<\/p>\n

\"Wie
\n
\nBlackfoot dekapselt den Datenverkehr und erledigt damit, was notwendig ist. Die Daten werden unver\u00e4ndert ins Internet gesendet.<\/p>\n

\"Wie
\n
\nDie Daten werden dekapselt und wieder in eine IPsec-H\u00fclle eingepackt, wenn VPN verwendet wird.<\/p>\n

\"Wie
\n
\nBei der Verwendung von Direct Connect wird der Datenverkehr getaggt und in das entsprechende VLAN \u00fcbertragen.<\/p>\n

\"Wie
\n<\/p>\n

HyperPlane<\/h3>\n

\nDies ist ein interner Dienst zur Flusskontrolle. Viele Netzwerkanwendungen ben\u00f6tigen ein Flussmanagement. der Datenflusszust\u00e4nde<\/b>. Zum Beispiel muss bei Verwendung von NAT sichergestellt werden, dass jeder Paarung \"IP: Zielport\" ein eindeutiger ausgehender Port zugeordnet ist. Im Fall eines Lastenausgleichers NLB<\/b> \u2014 Network Load Balancer<\/b>, muss der Datenfluss immer an die gleiche Ziel-VM geleitet werden. Sicherheitsgruppen sind eine zustandsbehaftete Firewall. Sie \u00fcberwacht den eingehenden Verkehr und \u00f6ffnet implizit Ports f\u00fcr den ausgehenden Datenverkehr.<\/p>\n

\"Wie
\n
\nIn der AWS-Cloud sind die Anforderungen an die \u00dcbertragungsverz\u00f6gerungen \u00e4u\u00dferst hoch. Daher HyperPlane<\/b> ist kritisch f\u00fcr die Funktionalit\u00e4t des gesamten Netzwerks.<\/p>\n

\"Wie
\n
\nHyperplane basiert auf EC2-Instanzen. Hier gibt es keinen Zauber, nur Raffinesse. Die Raffinesse besteht darin, dass es virtuelle Maschinen mit gro\u00dfem RAM sind. Die Transaktionen werden ausschlie\u00dflich im Arbeitsspeicher verarbeitet. Dies erm\u00f6glicht Latenzen von nur wenigen Mikrosekunden. Die Arbeit mit Festplatten w\u00fcrde die gesamte Leistung killen.\u00a0<\/p>\n

Hyperplane ist ein verteiltes System, bestehend aus einer Vielzahl von EC2-Instanzen. Jede virtuelle Maschine bietet eine Durchsatzrate von 5 GB\/s. Auf der Ebene des gesamten regionalen Netzwerks ergibt das enorme Terabits an Bandbreite und erm\u00f6glicht die Verarbeitung von Millionen von Verbindungen pro Sekunde.<\/b>.<\/p>\n

HyperPlane arbeitet ausschlie\u00dflich mit Streams. Die VPC-Paketkapselung ist f\u00fcr ihn vollst\u00e4ndig transparent. Eine potenzielle Schwachstelle in diesem internen Dienst wird dennoch nicht die Isolierung der VPC durchbrechen. F\u00fcr die Sicherheit sind die unteren Ebenen verantwortlich.<\/p>\n

Noisy Neighbor<\/h3>\n

\nEs gibt noch ein Problem mit dem schleichenden Nachbarn.<\/b> \u2014 Noisy Neighbor<\/b>. Angenommen, wir haben 8 Knoten. Diese Knoten verarbeiten die Streams aller Cloud-Nutzer. Es scheint alles gut zu sein, und die Last sollte gleichm\u00e4\u00dfig auf alle Knoten verteilt werden. Die Knoten sind sehr leistungsf\u00e4hig und schwer zu \u00fcberlasten.<\/p>\n

Doch wir bauen unsere Architektur auch auf der Grundlage selbst der unwahrscheinlichsten Szenarien.\u00a0<\/p>\n

Eine niedrige Wahrscheinlichkeit bedeutet nicht, dass es unm\u00f6glich ist.<\/p><\/blockquote>\n

\nStellen Sie sich vor, eine oder mehrere Benutzer erzeugen eine \u00fcberm\u00e4\u00dfige Last. Alle HyperPlane-Knoten sind an dieser Last beteiligt, und andere Benutzer k\u00f6nnten m\u00f6glicherweise eine Verringerung der Leistung erfahren. Dies untergr\u00e4bt das Konzept der Cloud, in dem die Mandanten keinen Einfluss aufeinander haben sollten.<\/p>\n

\"Wie
\n
\nWie l\u00f6st man das Problem eines st\u00f6renden Nachbarn? Das Erste, was einem in den Sinn kommt, ist Sharding. Unsere 8 Knoten werden logisch in 4 Shards mit jeweils 2 Knoten aufgeteilt. Nun wird der st\u00f6rende Nachbar nur ein Viertel aller Benutzer beeintr\u00e4chtigen, aber daf\u00fcr erheblich.<\/p>\n

\"Wie
\n
\nLassen Sie uns anders verfahren. Jeder Benutzer erh\u00e4lt lediglich 3 Knoten zugewiesen.\u00a0<\/p>\n

\"Wie
\n
\nDer Trick besteht darin, die Knoten zuf\u00e4llig verschiedenen Benutzern zuzuweisen. Im Bild unten hat der blaue Benutzer Knoten mit einem der beiden anderen Benutzer \u2013 dem gr\u00fcnen und dem orangefarbenen \u2013 gemeinsam.<\/p>\n

\"Wie
\n
\nBei 8 Knoten und 3 Benutzern betr\u00e4gt die Wahrscheinlichkeit, dass ein lauter Nachbar mit einem der Benutzer interferiert, 54 %. Mit dieser Wahrscheinlichkeit wird der blaue Benutzer andere Teilnehmer beeinflussen, und das auch nur teilweise durch seine Belastung. In unserem Beispiel wird dieser Einfluss jedoch nur f\u00fcr etwa ein Drittel aller Benutzer sp\u00fcrbar sein. Das ist schon ein gutes Ergebnis.<\/p>\n

Anzahl der Benutzer, die sich \u00fcberschneiden<\/p>\n

Wahrscheinlichkeit in Prozent<\/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

Lassen Sie uns die Situation realistisch gestalten \u2013 nehmen wir 100 Knoten und 5 Benutzer, die auf 5 Knoten verteilt sind. In diesem Fall wird keine der Knoten mit einer Wahrscheinlichkeit von 77 % \u00fcberschneiden.\u00a0<\/p>\n

Anzahl der Benutzer, die sich \u00fcberschneiden<\/p>\n

Wahrscheinlichkeit in Prozent<\/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

In der Realit\u00e4t, bei einer gro\u00dfen Anzahl von HyperPlane-Knoten und -Benutzern, ist der potenzielle Einfluss eines lauten Nachbarn auf andere Benutzer minimal. Diese Methode wird genannt shuffle sharding<\/b> \u2014 shuffle sharding<\/b>. Sie minimiert die negativen Auswirkungen von Knoten, die ausfallen.<\/p>\n

Auf HyperPlane basieren zahlreiche Dienste: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n

Netzwerkskalierung<\/h3>\n

\nKommen wir nun zur Skalierung des Netzwerks selbst. Im Oktober 2019 bietet AWS seine Dienste in 22 Regionen<\/b>, und es sind weitere 9 geplant.<\/p>\n