{"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 flexiblen Dienste \u201ebraut\u201c. Skalierung des Netzwerks","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Der Umfang des Amazon Web Services-Netzwerks umfasst 69 Zonen weltweit in 22 Regionen: USA, Europa, Asien, Afrika und Australien. In jeder Zone gibt es bis zu 8 Rechenzentren. In jedem Rechenzentrum befinden sich Tausende oder Hunderttausende von Servern. Das Netzwerk ist so konzipiert, dass alle unwahrscheinlichen Ausfall-Szenarien ber\u00fccksichtigt werden. So sind beispielsweise alle Regionen voneinander isoliert, und die Verf\u00fcgbarkeitszonen sind mehrere Kilometer voneinander entfernt. Selbst wenn ein Kabel durchtrennt wird, wechselt das System auf Backup-Kan\u00e4le, und der Informationsverlust betr\u00e4gt nur wenige Datenpakete. \u00dcber die weiteren Prinzipien, auf denen das Netzwerk basiert, und wie es funktioniert, wird Vasily Pantiukhin berichten.<\/p>\n

\"Wie
\n
\nWassili Pantuchin<\/b> begann als Unix-Administrator in .ru-Unternehmen, besch\u00e4ftigte sich 6 Jahre lang mit gro\u00dfen Servern von Sun Microsystems und predigte 11 Jahre lang die Datenzentrum-Zentriertheit der Welt bei EMC. Auf nat\u00fcrlichem Weg entwickelte er sich zu privaten Clouds weiter, bevor er zu \u00f6ffentlichen wechselte. Jetzt, als Architekt von Amazon Web Services, hilft er mit technischen Ratschl\u00e4gen, im AWS-Cloud-Umfeld zu leben und zu wachsen.<\/p>\n

Im vorherigen Teil der Trilogie \u00fcber die Architektur von AWS vertiefte sich Vasily in die Struktur physischer Server und die Skalierung von Datenbanken. Nitro-Karten, ein ma\u00dfgeschneiderter Hypervisor auf Basis von KVM, die Amazon Aurora-Datenbank \u2013 all dies wird im Material \u201eWie AWS seine flexiblen Dienste \u201ebraut\u201c. Skalierung von Servern und Datenbanken<\/a><\/noindex>\u201c behandelt. Lesen Sie weiter, um in den Kontext einzutauchen, oder schauen Sie sich die Videoaufzeichnung<\/a><\/noindex> der Pr\u00e4sentation an.<\/p>\n

In diesem Teil geht es um die Skalierung des Netzwerks \u2013 eines der komplexesten Systeme in AWS. Die Evolution vom flachen Netzwerk zur Virtual Private Cloud und deren Aufbau, die internen Dienste Blackfoot und HyperPlane, das Nachbarproblem, und schlie\u00dflich \u2013 die Dimensionen des Netzwerks, Backbone und physische Kabel. All dies erfahren Sie im weiteren Verlauf.<\/p>\n

Haftungsausschluss: Alles, was folgt, ist die pers\u00f6nliche Meinung von Vasily und kann 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 damals recht primitiv \u2013 mit einer flachen Struktur. Der Bereich privater Adressen war f\u00fcr alle Tenants der Cloud gemeinsam. Beim Starten einer neuen virtuellen Maschine erhielten Sie zuf\u00e4llig eine verf\u00fcgbare IP-Adresse aus diesem Bereich.<\/p>\n

\"Wie
\n
\nDieser Ansatz war einfach umzusetzen, begrenzte jedoch grunds\u00e4tzlich die Nutzung der Cloud. Insbesondere war es ziemlich schwierig, hybride L\u00f6sungen zu entwickeln, die private Netzwerke vor Ort und in AWS vereinten. Das h\u00e4ufigste Problem war die \u00dcberlappung von IP-Adressbereichen.<\/p>\n

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

Virtual Private Cloud<\/h3>\n

\nDie Cloud hat sich als gefragt erwiesen. Es ist an der Zeit, \u00fcber Skalierbarkeit und die M\u00f6glichkeit nachzudenken, sie von Dutzenden von Millionen von Tenants nutzen zu lassen. Ein flaches Netzwerk wurde zur Hauptschwierigkeit. Daher haben wir \u00fcberlegt, wie wir Nutzer auf Netzwerkebene voneinander isolieren k\u00f6nnen, sodass sie selbst IP-Bereiche ausw\u00e4hlen k\u00f6nnen.<\/p>\n

\"Wie
\n
\nWas kommt Ihnen zuerst in den Sinn, wenn Sie an Netzwerkisolierung denken? Nat\u00fcrlich VLAN<\/b> und VRF \u2013 Virtuelles Routing und Weiterleitung<\/b>.<\/p>\n

Leider hat das nicht funktioniert. VLAN-ID sind nur 12 Bit, was uns lediglich 4096 isolierte Segmente gibt. Selbst in den gr\u00f6\u00dften Switches k\u00f6nnen maximal 1-2.000 VRF verwendet werden. Die gemeinsame Nutzung von VRF und VLAN bietet uns nur einige Millionen Subnetze. Das reicht definitiv nicht f\u00fcr Dutzende von Millionen von Tenants, von denen jeder die M\u00f6glichkeit haben sollte, mehrere Subnetze zu nutzen.<\/p>\n

Au\u00dferdem k\u00f6nnen wir uns einfach nicht die erforderliche Anzahl gro\u00dfer Boxen, z.B. von Cisco oder Juniper, leisten. Es gibt zwei Gr\u00fcnde: es ist wahnsinnig teuer, und wir wollen nicht von ihrer Entwicklungs- und Patchpolitik abh\u00e4ngig sein.<\/p>\n

Die Schlussfolgerung ist klar \u2013 eine eigene L\u00f6sung entwickeln.<\/p><\/blockquote>\n

\nIm Jahr 2009 haben wir angek\u00fcndigt VPC<\/b> \u2014 Virtual Private Cloud<\/b>. Der Name hat sich etabliert, und mittlerweile verwenden ihn auch viele Cloud-Anbieter.<\/p>\n

VPC \u2013 \u044d\u0442\u043e \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u0430\u044f \u0441\u0435\u0442\u044c SDN<\/b> (Software Defined Network). Wir haben beschlossen, keine speziellen Protokolle auf den Ebenen L2 und L3 zu erfinden. Das Netzwerk arbeitet mit Standard-Ethernet und IP. F\u00fcr die \u00dcbertragung im Netzwerk wird der Traffic virtueller Maschinen in unsere eigene Protokollh\u00fclle eingekapselt. Darin wird die ID angegeben, die dem VPC des Tenants geh\u00f6rt.<\/p>\n

\"Wie
\n
\nDas klingt einfach. Allerdings m\u00fcssen mehrere ernsthafte technische Aufgaben gel\u00f6st 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 das eine riesige Tabelle, die mit minimalen Verz\u00f6gerungen beim Zugriff arbeiten muss. Daf\u00fcr ist verantwortlich der Zuordnungsdienst<\/b>, der d\u00fcnn \u00fcber das gesamte Netzwerk verteilt ist.<\/p>\n

In Maschinen neuer Generationen erfolgt die Kapselung durch Nitro-Karten auf Hardware-Ebene. In \u00e4lteren Instanzen erfolgt die Kapselung und Dekapselung softwareseitig.\u00a0<\/p>\n

\"Wie
\n
\nLass uns kl\u00e4ren, wie das im Gro\u00dfen und Ganzen funktioniert. Beginnen wir mit der Ebene L2. Angenommen, wir haben eine virtuelle Maschine mit der IP 10.0.0.2 auf einem physischen Server 192.168.0.3. Sie sendet Daten an die virtuelle Maschine 10.0.0.3, die auf 192.168.1.4 lebt. Es wird eine ARP-Anfrage generiert, die auf die Netzwerk-Nitro-Karte gelangt. Zum Zweck der Vereinfachung nehmen wir an, dass beide virtuellen Maschinen im selben \"blauen\" VPC leben.<\/p>\n

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

\"Wie
\n
\nDer Mapping-Dienst gibt die Informationen zur\u00fcck, die f\u00fcr die \u00dcbertragung \u00fcber das physische L2-Netzwerk ben\u00f6tigt werden.<\/p>\n

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

\"Wie
\n
\nBei der Daten\u00fcbertragung verpacken wir die logischen MAC und IP in eine VPC-H\u00fclle. All dies wird mithilfe der entsprechenden IP Nitro-Karten des Quell- und Zielservers \u00fcber das physische Netzwerk \u00fcbertragen.<\/p>\n

\"Wie
\n
\nDie physische Maschine, f\u00fcr die das Paket bestimmt ist, f\u00fchrt eine \u00dcberpr\u00fcfung durch. Dies ist notwendig, um eine Adressf\u00e4lschung zu verhindern. Die Maschine sendet eine spezielle Anfrage an den Mapping-Dienst und fragt: \u201eIch habe von der physischen Maschine 192.168.0.3 ein Paket erhalten, das f\u00fcr 10.0.0.3 im 'blauen' VPC bestimmt ist. Ist es legitim?\u201c\u00a0<\/p>\n

\"Wie
\n
\nDer Mapping-Dienst vergleicht mit seiner Ressourcenzuordnungstabelle und erlaubt oder verweigert die Paketweiterleitung. In allen neuen Instanzen ist eine zus\u00e4tzliche Validierung in die Nitro-Karten eingebaut. Diese kann selbst theoretisch nicht umgangen werden. Daher wird Spoofing auf Ressourcen in einem anderen VPC nicht funktionieren.<\/p>\n

\"Wie
\n
\nDanach 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 verschiedenen Subnetzen. Grunds\u00e4tzlich ist das einfach; ich werde nicht ins Detail gehen.<\/p>\n

\"Wie
\n
\nDaraus ergibt sich, dass die Server bei der \u00dcbertragung jedes Pakets den Mapping-Dienst ansprechen. Wie kann man mit den unvermeidlichen Verz\u00f6gerungen umgehen? Durch Caching<\/b>, nat\u00fcrlich.<\/p>\n

Die ganze Sch\u00f6nheit besteht darin, dass man nicht die gesamte riesige Tabelle cachen muss. Auf dem physischen Server leben virtuelle Maschinen aus einer relativ kleinen Anzahl von VPCs. Die Informationen m\u00fcssen nur \u00fcber diese VPCs gecacht werden. Die Daten\u00fcbertragung in andere VPCs ist in der Standardkonfiguration trotzdem nicht legitim. Wenn solche Funktionen wie VPC-Peering genutzt werden, wird zus\u00e4tzlich Informationen \u00fcber die entsprechenden VPCs in den Cache geladen.\u00a0<\/p>\n

\"Wie
\n
\nWir haben die Daten\u00fcbertragung in ein VPC gekl\u00e4rt.<\/p>\n

Blackfoot<\/h3>\n

\nWie geht man in F\u00e4llen damit um, wenn der Verkehr nach au\u00dfen geleitet werden muss, beispielsweise ins Internet oder \u00fcber VPN ins Inland? Hier hilft uns Blackfoot<\/b> \u2014 der interne AWS-Service. Er wurde von unserem s\u00fcdafrikanischen Team entwickelt. Deshalb tr\u00e4gt der Service den Namen eines Pinguins, der in S\u00fcdafrika lebt.<\/p>\n

\"Wie
\n
\nBlackfoot dekapsuliert den Verkehr und macht damit, was n\u00f6tig ist. Daten werden genau so ins Internet gesendet.<\/p>\n

\"Wie
\n
\nDie Daten werden dekapsuliert und bei der Verwendung von VPN erneut in IPsec eingeh\u00fcllt.<\/p>\n

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

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

HyperPlane<\/h3>\n

\nDas ist ein interner Service zur Steuerung des Verkehrs. Viele Netzwerkdienste erfordern eine Kontrolle des Datenstroms<\/b>. Beispielsweise muss bei Verwendung von NAT die Verkehrssteuerung sicherstellen, dass jeder Paarung \u201eIP: Zielport\u201c ein einzigartiger ausgehender Port zugeordnet ist. Im Fall des Lastenausgleichs NLB<\/b> \u2014 Network Load Balancer<\/b>, muss der Datenstrom immer an dieselbe Ziel-VM geleitet werden. Security Groups sind eine zustandsbehaftete Firewall. Sie \u00fcberwacht den eingehenden Verkehr und \u00f6ffnet implizit Ports f\u00fcr den ausgehenden Datenstrom.<\/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 Funktionsf\u00e4higkeit des gesamten Netzwerks.<\/p>\n

\"Wie
\n
\nHyperplane basiert auf EC2-VMs. Hier gibt es keinen Zauber, nur eine List. Der Trick besteht darin, dass es sich um VMs mit gro\u00dfer RAM handelt. Die Transaktionen werden ausschlie\u00dflich im Speicher durchgef\u00fchrt. Das erm\u00f6glicht Verz\u00f6gerungen von nur wenigen Mikrosekunden. Arbeiten mit der Festplatte w\u00fcrden die gesamte Leistung ruinieren.\u00a0<\/p>\n

Hyperplane ist ein verteiltes System aus einer riesigen Anzahl solcher EC2-Maschinen. Jede VM hat eine Bandbreite von 5 GB\/s. Im Ma\u00dfstab des gesamten regionalen Netzwerks bedeutet dies immense Terabits an Bandbreite und erm\u00f6glicht die Verarbeitung von Millionen von Verbindungen pro Sekunde.<\/b>.<\/p>\n

HyperPlane arbeitet nur mit Streams. VPC-Paketinkapselung ist f\u00fcr ihn v\u00f6llig transparent. Eine potenzielle Schwachstelle in diesem internen Service w\u00fcrde dennoch nicht zulassen, dass die VPC-Isolierung durchbrochen wird. F\u00fcr die Sicherheit sind die unteren Ebenen verantwortlich.<\/p>\n

Noisy neighbor<\/h3>\n

\nEs gibt noch ein Problem des lauten Nachbarn<\/b> \u2014 noisy neighbor<\/b>. Nehmen wir an, wir haben 8 Knoten. Diese Knoten verarbeiten die Str\u00f6me aller Nutzer der Cloud. Soweit ist alles gut, und die Last sollte gleichm\u00e4\u00dfig auf alle Knoten verteilt werden. Die Knoten sind sehr leistungsstark und es ist schwierig, sie zu \u00fcberlasten.<\/p>\n

Aber wir bauen unsere Architektur selbst auf der Grundlage von sogar unwahrscheinlichen Szenarien.\u00a0<\/p>\n

Eine niedrige Wahrscheinlichkeit bedeutet nicht Unm\u00f6glichkeit.<\/p><\/blockquote>\n

\nWir k\u00f6nnen uns eine Situation vorstellen, in der ein oder mehrere Nutzer eine zu hohe Last erzeugen. Alle Knoten von HyperPlane sind in die Verarbeitung dieser Last involviert, und andere Nutzer k\u00f6nnten ein gewisses Leistungsdefizit sp\u00fcren. Das zerst\u00f6rt das Konzept der Cloud, in dem Mieter nicht gegenseitig Einfluss aufeinander nehmen k\u00f6nnen.<\/p>\n

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

\"Wie
\n
\nLass uns anders verfahren. Wir weisen jedem Nutzer nur 3 Knoten zu.\u00a0<\/p>\n

\"Wie
\n
\nDer Trick besteht darin, Knoten zuf\u00e4llig verschiedenen Nutzern zuzuordnen. Im Bild unten hat der blaue Nutzer Knoten mit einem der beiden anderen Nutzer \u2014 dem gr\u00fcnen und dem orangenen \u2014 gemeinsam.<\/p>\n

\"Wie
\n
\nBei 8 Knoten und 3 Nutzern betr\u00e4gt die Wahrscheinlichkeit, dass der st\u00f6rende Nachbar einen der Nutzer beeintr\u00e4chtigt, 54%. Mit dieser Wahrscheinlichkeit wird der blaue Nutzer Einfluss auf andere Mieter aus\u00fcben. Dabei geschieht dies nur mit einem Teil seiner Last. In unserem Beispiel wird dieser Einfluss nicht f\u00fcr alle, sondern nur f\u00fcr ein Drittel aller Nutzer sp\u00fcrbar sein. Das ist bereits ein beachtliches Ergebnis.<\/p>\n

Anzahl der Nutzer, die sich \u00fcberschneiden werden<\/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 in die Realit\u00e4t umsetzen \u2013 nehmen wir 100 Knoten und 5 Nutzer auf 5 Knoten. In diesem Fall \u00fcberschneidet sich keiner der Knoten mit einer Wahrscheinlichkeit von 77%.\u00a0<\/p>\n

Anzahl der Nutzer, die sich \u00fcberschneiden werden<\/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 realen Situation, bei einer gro\u00dfen Anzahl von HyperPlane-Knoten und Nutzern, ist der potenzielle Einfluss des st\u00f6renden Nachbarn auf andere Nutzer minimal. Diese Methode wird genannt Shuffle Sharding<\/b> \u2014 . Sie minimiert den negativen Effekt durch Ausf\u00e4lle von Knoten.<\/b>Auf der Grundlage von HyperPlane wurden zahlreiche Dienste aufgebaut: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n

Gr\u00f6\u00dfe des Netzwerks<\/p>\n

Netzwerkausma\u00dfe<\/h3>\n

\nJetzt sprechen wir \u00fcber das Ausma\u00df des Netzwerks. Im Oktober 2019 bietet AWS seine Dienste in 22 Regionen<\/b>, und es sind weitere 9 geplant.<\/p>\n