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ällen berücksichtigt 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äle, wobei der Verlust an Informationen nur einzelne Datenpakete umfasst. Vasily Pantyukhin wird erläutern, auf welchen weiteren Prinzipien das Netzwerk basiert und wie es funktioniert.
Wassili Pantjuchin Er begann als Unix-Admin in .ru-Unternehmen, arbeitete 6 Jahre lang mit großen Geräten von Sun Microsystems und predigte 11 Jahre lang die Datenzentriertheit der Welt bei EMC. Natürlich entwickelte er sich in private Clouds weiter und wandte sich dann öffentlichen zu. Heute unterstützt er als Architekt bei Amazon Web Services mit technischen Ratschlägen, um im AWS-Cloud-Umfeld erfolgreich zu leben und zu wachsen.
Im vorherigen Teil der Trilogie über 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 – all dies finden Sie im Artikel „“. Lesen Sie weiter, um in den Kontext einzutauchen, oder sehen Sie sich der Präsentation an.
In diesem Teil geht es um das Skalieren des Netzwerks – 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ßlich die Netzmasse, das Backbone und die physischen Kabel. All dies im Folgenden.
Haftungsausschluss: Alles, was folgt, ist Wasilijs persönliche Meinung und könnte von der Position von Amazon Web Services abweichen.
Netzwerkskalierung
Die AWS-Cloud wurde 2006 gestartet. Ihr Netzwerk war recht primitiv – mit einer flachen Struktur. Der Bereich der privaten Adressen war für alle Tenants der Cloud gemeinsam. Bei der Bereitstellung einer neuen virtuellen Maschine erhielten Sie zufällig eine verfügbare IP-Adresse aus diesem Bereich.
Dieser Ansatz ließ sich einfach umsetzen, schränkte jedoch die Nutzung der Cloud grundlegend ein. Insbesondere war es recht schwierig, hybride Lösungen zu entwickeln, die private Netzwerke sowohl vor Ort als auch in AWS kombinierten. Das häufigste Problem war die Überlappung von IP-Adressbereichen.
Virtual Private Cloud
Die Cloud erwies sich als sehr gefragt. Es wurde Zeit, über die Skalierbarkeit und die Möglichkeit nachzudenken, sie von Millionen von Nutzern verwenden zu lassen. Das flache Netzwerk wurde zum Hauptgegenstand der Herausforderungen. Daher überlegten wir, wie wir Nutzer auf Netzwerkebene voneinander isolieren können, sodass sie selbst IP-Bereiche auswählen können.
Was fällt Ihnen zuerst ein, wenn Sie an Netzisolierung denken? Natürlich VLAN und VRF — Virtual Routing and Forwarding.
Leider hat es nicht funktioniert. VLAN-ID ist nur 12 Bit lang, was uns lediglich 4096 isolierte Segmente ermöglicht. Selbst in den größten Switches können maximal 1-2 Tausend VRF verwendet werden. Die Kombination aus VRF und VLAN ergibt nur wenige Millionen Subnetze. Das ist definitiv zu wenig für Zehntausende von Tenants, von denen jeder die Möglichkeit haben sollte, mehrere Subnetze zu nutzen.
Außerdem können wir uns einfach nicht leisten, die erforderliche Anzahl großer Geräte von Anbietern wie Cisco oder Juniper zu kaufen. Es gibt zwei Gründe dafür: Es ist extrem teuer, und wir möchten nicht von deren Entwicklungs- und Patch-Politik abhängig sein.
Die einzige Lösung ist, eine eigene Lösung zu entwickeln.
Im Jahr 2009 haben wir angekündigt VPC — Virtual Private Cloud. Der Name hat sich durchgesetzt und wird jetzt auch von vielen Cloud-Anbietern verwendet.
VPC ist ein virtuelles Netzwerk SDN (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 über das Netzwerk zu transportieren, wird er in das Format unseres eigenen Protokolls eingekapselt. Dabei wird eine ID angegeben, die zu dem VPC-tenant gehört.
Das klingt einfach. Allerdings müssen 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ßstab von AWS ist dies eine riesige Tabelle, die mit minimalen Verzögerungen beim Zugriff arbeiten muss. Dafür ist verantwortlich der Mapping-Service, der dünn über das gesamte Netzwerk verteilt ist.
In modernen Maschinen erfolgt die Kapselung durch Nitro-Karten auf hardwareseitiger Ebene. Bei älteren Instanzen geschieht die Kapselung und Dekapselung softwareseitig.
Lassen Sie uns klären, wie das im Großen 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 „blauen“ VPC befinden.
Die Karte ersetzt die Quelladresse durch ihre eigene und leitet das ARP-Frame an den Mapping-Service weiter.
Der Mapping-Service liefert die Informationen zurück, die für die Übertragung über das physische L2-Netzwerk erforderlich sind.
Die Nitro-Karte im ARP-Antwort ersetzt die MAC-Adresse im physischen Netzwerk durch die Adresse in der VPC.
Bei der Datenübertragung kapseln wir die logischen MAC- und IP-Adressen in eine VPC-Hülle. All dies wird über das physische Netzwerk mit den entsprechenden IP-Nitro-Karten von Quelle und Ziel übertragen.
Der physische Server, der für das Paket bestimmt ist, führt eine Überprüfung durch. Dies geschieht, um eine Adressänderung 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ür 10.0.0.3 im 'blauen' VPC bestimmt ist. Ist es legitim?"
Der Mapping-Dienst vergleicht und prüft seine Ressourcen-Zuordnungstabelle und erlaubt oder verbietet das Durchleiten des Pakets. In allen neuen Instanzen ist eine zusätzliche Validierung in den Nitro-Karten integriert. Diese kann theoretisch nicht umgangen werden. Daher wird Spoofing auf Ressourcen in einer anderen VPC nicht funktionieren.
Anschließend werden die Daten an die virtuelle Maschine gesendet, für die sie bestimmt sind.
Der Mapping-Dienst fungiert auch als logischer Router für die Datenübertragung zwischen virtuellen Maschinen in unterschiedlichen Subnetzen. Grundsätzlich ist alles einfach, ich werde nicht ins Detail gehen.
Wenn jeder Datenpaket übertragen wird, greifen die Server auf den Mappingsdienst zu. Wie geht man mit unvermeidlichen Verzögerungen um? Durch Caching., natürlich.
Das Schöne daran ist, dass man nicht die gesamte große Tabelle cachen muss. Auf einem physischen Server leben virtuelle Maschinen aus einer relativ kleinen Anzahl von VPCs. Es ist nur notwendig, Informationen über 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ätzlich Informationen über die entsprechenden VPCs ins Cache geladen.
Wir haben den Datenaustausch mit VPCs geklärt.
Blackfoot
Was ist in Fällen, wenn der Datenverkehr nach außen, zum Beispiel ins Internet oder über VPN ins Ausland, weitergegeben werden muss? Hier hilft uns Blackfoot — ein interner AWS-Dienst. Er wurde von unserem südafrikanischen Team entwickelt. Daher trägt der Dienst den Namen eines Pinguins, der in Südafrika lebt.
Blackfoot dekapselt den Datenverkehr und erledigt damit, was notwendig ist. Die Daten werden unverändert ins Internet gesendet.
Die Daten werden dekapselt und wieder in eine IPsec-Hülle eingepackt, wenn VPN verwendet wird.
Bei der Verwendung von Direct Connect wird der Datenverkehr getaggt und in das entsprechende VLAN übertragen.
HyperPlane
Dies ist ein interner Dienst zur Flusskontrolle. Viele Netzwerkanwendungen benötigen ein Flussmanagement. der Datenflusszustände. 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 — Network Load Balancer, muss der Datenfluss immer an die gleiche Ziel-VM geleitet werden. Sicherheitsgruppen sind eine zustandsbehaftete Firewall. Sie überwacht den eingehenden Verkehr und öffnet implizit Ports für den ausgehenden Datenverkehr.
In der AWS-Cloud sind die Anforderungen an die Übertragungsverzögerungen äußerst hoch. Daher HyperPlane ist kritisch für die Funktionalität des gesamten Netzwerks.
Hyperplane basiert auf EC2-Instanzen. Hier gibt es keinen Zauber, nur Raffinesse. Die Raffinesse besteht darin, dass es virtuelle Maschinen mit großem RAM sind. Die Transaktionen werden ausschließlich im Arbeitsspeicher verarbeitet. Dies ermöglicht Latenzen von nur wenigen Mikrosekunden. Die Arbeit mit Festplatten würde die gesamte Leistung killen.
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öglicht die Verarbeitung von Millionen von Verbindungen pro Sekunde..
HyperPlane arbeitet ausschließlich mit Streams. Die VPC-Paketkapselung ist für ihn vollständig transparent. Eine potenzielle Schwachstelle in diesem internen Dienst wird dennoch nicht die Isolierung der VPC durchbrechen. Für die Sicherheit sind die unteren Ebenen verantwortlich.
Noisy Neighbor
Es gibt noch ein Problem mit dem schleichenden Nachbarn. — Noisy Neighbor. Angenommen, wir haben 8 Knoten. Diese Knoten verarbeiten die Streams aller Cloud-Nutzer. Es scheint alles gut zu sein, und die Last sollte gleichmäßig auf alle Knoten verteilt werden. Die Knoten sind sehr leistungsfähig und schwer zu überlasten.
Doch wir bauen unsere Architektur auch auf der Grundlage selbst der unwahrscheinlichsten Szenarien.
Eine niedrige Wahrscheinlichkeit bedeutet nicht, dass es unmöglich ist.
Stellen Sie sich vor, eine oder mehrere Benutzer erzeugen eine übermäßige Last. Alle HyperPlane-Knoten sind an dieser Last beteiligt, und andere Benutzer könnten möglicherweise eine Verringerung der Leistung erfahren. Dies untergräbt das Konzept der Cloud, in dem die Mandanten keinen Einfluss aufeinander haben sollten.
Wie löst man das Problem eines störenden 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örende Nachbar nur ein Viertel aller Benutzer beeinträchtigen, aber dafür erheblich.
Lassen Sie uns anders verfahren. Jeder Benutzer erhält lediglich 3 Knoten zugewiesen.
Der Trick besteht darin, die Knoten zufällig verschiedenen Benutzern zuzuweisen. Im Bild unten hat der blaue Benutzer Knoten mit einem der beiden anderen Benutzer – dem grünen und dem orangefarbenen – gemeinsam.
Bei 8 Knoten und 3 Benutzern beträgt 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ür etwa ein Drittel aller Benutzer spürbar sein. Das ist schon ein gutes Ergebnis.
Anzahl der Benutzer, die sich überschneiden
Wahrscheinlichkeit in Prozent
0
18%
1
54%
2
26%
3
2%
Lassen Sie uns die Situation realistisch gestalten – 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 % überschneiden.
Anzahl der Benutzer, die sich überschneiden
Wahrscheinlichkeit in Prozent
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
In der Realität, bei einer großen Anzahl von HyperPlane-Knoten und -Benutzern, ist der potenzielle Einfluss eines lauten Nachbarn auf andere Benutzer minimal. Diese Methode wird genannt shuffle sharding — shuffle sharding. Sie minimiert die negativen Auswirkungen von Knoten, die ausfallen.
Auf HyperPlane basieren zahlreiche Dienste: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Netzwerkskalierung
Kommen wir nun zur Skalierung des Netzwerks selbst. Im Oktober 2019 bietet AWS seine Dienste in 22 Regionen, und es sind weitere 9 geplant.
- Jede Region umfasst mehrere Verfügbarkeitszonen – Availability Zones. Weltweit gibt es insgesamt 69 davon.
- Jede AZ besteht aus Rechenzentren. Maximal gibt es davon 8.
- In einem Rechenzentrum befinden sich unzählige Server, in einigen sogar bis zu 300.000.
Jetzt fassen wir all das zusammen, multiplizieren und erhalten eine beeindruckende Zahl, die das Ausmaß der Amazon-Cloud widerspiegelt..
Zwischen den Verfügbarkeitszonen und den Rechenzentren verlaufen zahlreiche Glasfaserkabel. In unserer größten Region sind allein 388 Verbindungen für die Kommunikation zwischen den AZ und den Transitzentren zu anderen Regionen verlegt. Insgesamt ergibt dies immense 5000 Tbit..
Das AWS-Backbone wurde speziell für die Cloud entwickelt und ist für deren Betrieb optimiert. Es basiert auf Verbindungen mit 100 GB/s.Wir kontrollieren diese vollständig, mit Ausnahme der Regionen in China. Der Datenverkehr wird nicht mit Lasten anderer Unternehmen geteilt.
Natürlich sind wir nicht der einzige Cloud-Anbieter mit einem privaten Backbone-Netzwerk. Immer mehr große Unternehmen folgen diesem Weg. Dies wird von unabhängigen Forschern, wie zum Beispiel von .
Die Grafik zeigt, dass der Anteil von Content-Providern und Cloud-Anbietern stetig wächst. Daher nimmt der Anteil des Internetverkehrs von Backbone-Providern kontinuierlich ab.
Ich erkläre, warum das so ist. Früher waren die meisten Web-Services direkt über das Internet erreichbar und wurden konsumiert. Heute sind immer mehr Server in der Cloud und über (CDN — Content Delivery Networkerreichbar. Um auf die Ressource zuzugreifen, gelangt der Nutzer über das Internet nur bis zum nächstgelegenen CDN-Standort — Point of Presence. Häufig ist dieser in der Nähe. Danach verlässt der Verkehr das öffentliche Internet und wird über private Backbone-Netze, zum Beispiel über den Atlantik, direkt zur Ressource geleitet.
Es bleibt spannend, wie sich das Internet in 10 Jahren entwickelt, wenn dieser Trend anhält.
Physikalische Kanäle
Wissenschaftler haben noch keinen Weg gefunden, die Lichtgeschwindigkeit im Universum zu erhöhen, aber sie haben bedeutende Fortschritte in den Methoden zur Übertragung über Glasfaser erzielt. Derzeit verwenden wir Kabel mit 6912 Fasern. Das hilft, die Kosten für den Ausbau erheblich zu optimieren.
In einigen Regionen sind wir gezwungen, spezielle Kabel zu verwenden. Zum Beispiel setzen wir in der Region Sydney Kabel mit einer speziellen Beschichtung gegen Termiten ein.
Unfälle sind nicht auszuschließen, und manchmal werden unsere Kanäle beschädigt. Auf dem Bild rechts sind Glasfaserkabel in einer der amerikanischen Regionen zu sehen, die von Bauarbeitern durchtrennt wurden. Infolge des Vorfalls gingen nur 13 Datenpakete verloren, was bemerkenswert ist. Nochmals – nur 13! Das System schaltete sofort auf die Backup-Kanäle um – der Maßstab funktioniert.
Wir haben einen schnellen Überblick über einige Services und Technologien der Amazon-Cloud gegeben. Ich hoffe, dass Sie zumindest einen Eindruck vom Umfang der Herausforderungen gewonnen haben, mit denen unsere Ingenieure konfrontiert sind. Persönlich finde ich das sehr spannend.
Dies ist der letzte Teil der Trilogie von Wasilij Pantjuchin über die AWS-Infrastruktur. In Teil werden die Serveroptimierung und das Datenbank-Scaling beschrieben, und im – serverless Funktionen und Firecracker.
Auf Im November wird Wasilij Pantjuchin neue Details zur Amazon-Infrastruktur teilen. Er wird über die Ursachen von Ausfällen und das Design verteilter Systeme bei Amazon sprechen. Am 24. Oktober kann man noch Ein Ticket zu einem attraktiven Preis, und die Bezahlung erfolgt später. Wir freuen uns auf Ihren Besuch bei HighLoad++, kommen Sie vorbei — wir freuen uns auf den Austausch!
Quelle: habr.com
