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ücksichtigt werden. So sind beispielsweise alle Regionen voneinander isoliert, und die Verfügbarkeitszonen sind mehrere Kilometer voneinander entfernt. Selbst wenn ein Kabel durchtrennt wird, wechselt das System auf Backup-Kanäle, und der Informationsverlust beträgt nur wenige Datenpakete. Über die weiteren Prinzipien, auf denen das Netzwerk basiert, und wie es funktioniert, wird Vasily Pantiukhin berichten.
Wassili Pantuchin begann als Unix-Administrator in .ru-Unternehmen, beschäftigte sich 6 Jahre lang mit großen Servern von Sun Microsystems und predigte 11 Jahre lang die Datenzentrum-Zentriertheit der Welt bei EMC. Auf natürlichem Weg entwickelte er sich zu privaten Clouds weiter, bevor er zu öffentlichen wechselte. Jetzt, als Architekt von Amazon Web Services, hilft er mit technischen Ratschlägen, im AWS-Cloud-Umfeld zu leben und zu wachsen.
Im vorherigen Teil der Trilogie über die Architektur von AWS vertiefte sich Vasily in die Struktur physischer Server und die Skalierung von Datenbanken. Nitro-Karten, ein maßgeschneiderter Hypervisor auf Basis von KVM, die Amazon Aurora-Datenbank – all dies wird im Material „“ behandelt. Lesen Sie weiter, um in den Kontext einzutauchen, oder schauen Sie sich der Präsentation an.
In diesem Teil geht es um die Skalierung des Netzwerks – 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ßlich – die Dimensionen des Netzwerks, Backbone und physische Kabel. All dies erfahren Sie im weiteren Verlauf.
Haftungsausschluss: Alles, was folgt, ist die persönliche Meinung von Vasily und kann von der Position von Amazon Web Services abweichen.
Netzwerkskalierung
Die AWS-Cloud wurde 2006 gestartet. Ihr Netzwerk war damals recht primitiv – mit einer flachen Struktur. Der Bereich privater Adressen war für alle Tenants der Cloud gemeinsam. Beim Starten einer neuen virtuellen Maschine erhielten Sie zufällig eine verfügbare IP-Adresse aus diesem Bereich.
Dieser Ansatz war einfach umzusetzen, begrenzte jedoch grundsätzlich die Nutzung der Cloud. Insbesondere war es ziemlich schwierig, hybride Lösungen zu entwickeln, die private Netzwerke vor Ort und in AWS vereinten. Das häufigste Problem war die Überlappung von IP-Adressbereichen.
Virtual Private Cloud
Die Cloud hat sich als gefragt erwiesen. Es ist an der Zeit, über Skalierbarkeit und die Möglichkeit nachzudenken, sie von Dutzenden von Millionen von Tenants nutzen zu lassen. Ein flaches Netzwerk wurde zur Hauptschwierigkeit. Daher haben wir überlegt, wie wir Nutzer auf Netzwerkebene voneinander isolieren können, sodass sie selbst IP-Bereiche auswählen können.
Was kommt Ihnen zuerst in den Sinn, wenn Sie an Netzwerkisolierung denken? Natürlich VLAN und VRF – Virtuelles Routing und Weiterleitung.
Leider hat das nicht funktioniert. VLAN-ID sind nur 12 Bit, was uns lediglich 4096 isolierte Segmente gibt. Selbst in den größten Switches können 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ür Dutzende von Millionen von Tenants, von denen jeder die Möglichkeit haben sollte, mehrere Subnetze zu nutzen.
Außerdem können wir uns einfach nicht die erforderliche Anzahl großer Boxen, z.B. von Cisco oder Juniper, leisten. Es gibt zwei Gründe: es ist wahnsinnig teuer, und wir wollen nicht von ihrer Entwicklungs- und Patchpolitik abhängig sein.
Die Schlussfolgerung ist klar – eine eigene Lösung entwickeln.
Im Jahr 2009 haben wir angekündigt VPC — Virtual Private Cloud. Der Name hat sich etabliert, und mittlerweile verwenden ihn auch viele Cloud-Anbieter.
VPC – это виртуальная сеть SDN (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ür die Übertragung im Netzwerk wird der Traffic virtueller Maschinen in unsere eigene Protokollhülle eingekapselt. Darin wird die ID angegeben, die dem VPC des Tenants gehört.
Das klingt einfach. Allerdings müssen mehrere ernsthafte technische Aufgaben gelöst 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 das eine riesige Tabelle, die mit minimalen Verzögerungen beim Zugriff arbeiten muss. Dafür ist verantwortlich der Zuordnungsdienst, der dünn über das gesamte Netzwerk verteilt ist.
In Maschinen neuer Generationen erfolgt die Kapselung durch Nitro-Karten auf Hardware-Ebene. In älteren Instanzen erfolgt die Kapselung und Dekapselung softwareseitig.
Lass uns klären, wie das im Großen 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.
Die Karte ersetzt die Quelladresse durch ihre eigene und leitet das ARP-Frame an den Mapping-Dienst weiter.
Der Mapping-Dienst gibt die Informationen zurück, die für die Übertragung über das physische L2-Netzwerk benötigt werden.
Die Nitro-Karte ersetzt in der ARP-Antwort die MAC-Adresse im physischen Netzwerk durch die Adresse im VPC.
Bei der Datenübertragung verpacken wir die logischen MAC und IP in eine VPC-Hülle. All dies wird mithilfe der entsprechenden IP Nitro-Karten des Quell- und Zielservers über das physische Netzwerk übertragen.
Die physische Maschine, für die das Paket bestimmt ist, führt eine Überprüfung durch. Dies ist notwendig, um eine Adressfälschung zu verhindern. Die Maschine sendet eine spezielle Anfrage an den Mapping-Dienst und fragt: „Ich habe von der physischen Maschine 192.168.0.3 ein Paket erhalten, das für 10.0.0.3 im 'blauen' VPC bestimmt ist. Ist es legitim?“
Der Mapping-Dienst vergleicht mit seiner Ressourcenzuordnungstabelle und erlaubt oder verweigert die Paketweiterleitung. In allen neuen Instanzen ist eine zusätzliche Validierung in die Nitro-Karten eingebaut. Diese kann selbst theoretisch nicht umgangen werden. Daher wird Spoofing auf Ressourcen in einem anderen VPC nicht funktionieren.
Danach 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 verschiedenen Subnetzen. Grundsätzlich ist das einfach; ich werde nicht ins Detail gehen.
Daraus ergibt sich, dass die Server bei der Übertragung jedes Pakets den Mapping-Dienst ansprechen. Wie kann man mit den unvermeidlichen Verzögerungen umgehen? Durch Caching, natürlich.
Die ganze Schönheit 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üssen nur über diese VPCs gecacht werden. Die Datenübertragung in andere VPCs ist in der Standardkonfiguration trotzdem nicht legitim. Wenn solche Funktionen wie VPC-Peering genutzt werden, wird zusätzlich Informationen über die entsprechenden VPCs in den Cache geladen.
Wir haben die Datenübertragung in ein VPC geklärt.
Blackfoot
Wie geht man in Fällen damit um, wenn der Verkehr nach außen geleitet werden muss, beispielsweise ins Internet oder über VPN ins Inland? Hier hilft uns Blackfoot — der interne AWS-Service. Er wurde von unserem südafrikanischen Team entwickelt. Deshalb trägt der Service den Namen eines Pinguins, der in Südafrika lebt.
Blackfoot dekapsuliert den Verkehr und macht damit, was nötig ist. Daten werden genau so ins Internet gesendet.
Die Daten werden dekapsuliert und bei der Verwendung von VPN erneut in IPsec eingehüllt.
Bei Verwendung von Direct Connect wird der Verkehr gekennzeichnet und in das entsprechende VLAN übertragen.
HyperPlane
Das ist ein interner Service zur Steuerung des Verkehrs. Viele Netzwerkdienste erfordern eine Kontrolle des Datenstroms. Beispielsweise muss bei Verwendung von NAT die Verkehrssteuerung sicherstellen, dass jeder Paarung „IP: Zielport“ ein einzigartiger ausgehender Port zugeordnet ist. Im Fall des Lastenausgleichs NLB — Network Load Balancer, muss der Datenstrom immer an dieselbe Ziel-VM geleitet werden. Security Groups sind eine zustandsbehaftete Firewall. Sie überwacht den eingehenden Verkehr und öffnet implizit Ports für den ausgehenden Datenstrom.
In der AWS-Cloud sind die Anforderungen an die Übertragungsverzögerungen äußerst hoch. Daher HyperPlane ist kritisch für die Funktionsfähigkeit des gesamten Netzwerks.
Hyperplane basiert auf EC2-VMs. Hier gibt es keinen Zauber, nur eine List. Der Trick besteht darin, dass es sich um VMs mit großer RAM handelt. Die Transaktionen werden ausschließlich im Speicher durchgeführt. Das ermöglicht Verzögerungen von nur wenigen Mikrosekunden. Arbeiten mit der Festplatte würden die gesamte Leistung ruinieren.
Hyperplane ist ein verteiltes System aus einer riesigen Anzahl solcher EC2-Maschinen. Jede VM hat eine Bandbreite von 5 GB/s. Im Maßstab des gesamten regionalen Netzwerks bedeutet dies immense Terabits an Bandbreite und ermöglicht die Verarbeitung von Millionen von Verbindungen pro Sekunde..
HyperPlane arbeitet nur mit Streams. VPC-Paketinkapselung ist für ihn völlig transparent. Eine potenzielle Schwachstelle in diesem internen Service würde dennoch nicht zulassen, dass die VPC-Isolierung durchbrochen wird. Für die Sicherheit sind die unteren Ebenen verantwortlich.
Noisy neighbor
Es gibt noch ein Problem des lauten Nachbarn — noisy neighbor. Nehmen wir an, wir haben 8 Knoten. Diese Knoten verarbeiten die Ströme aller Nutzer der Cloud. Soweit ist alles gut, und die Last sollte gleichmäßig auf alle Knoten verteilt werden. Die Knoten sind sehr leistungsstark und es ist schwierig, sie zu überlasten.
Aber wir bauen unsere Architektur selbst auf der Grundlage von sogar unwahrscheinlichen Szenarien.
Eine niedrige Wahrscheinlichkeit bedeutet nicht Unmöglichkeit.
Wir können 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önnten ein gewisses Leistungsdefizit spüren. Das zerstört das Konzept der Cloud, in dem Mieter nicht gegenseitig Einfluss aufeinander nehmen können.
Wie löst man das Problem des störenden 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örende Nachbar nur ein Viertel aller Nutzer, aber dafür erheblich.
Lass uns anders verfahren. Wir weisen jedem Nutzer nur 3 Knoten zu.
Der Trick besteht darin, Knoten zufällig verschiedenen Nutzern zuzuordnen. Im Bild unten hat der blaue Nutzer Knoten mit einem der beiden anderen Nutzer — dem grünen und dem orangenen — gemeinsam.
Bei 8 Knoten und 3 Nutzern beträgt die Wahrscheinlichkeit, dass der störende Nachbar einen der Nutzer beeinträchtigt, 54%. Mit dieser Wahrscheinlichkeit wird der blaue Nutzer Einfluss auf andere Mieter ausüben. Dabei geschieht dies nur mit einem Teil seiner Last. In unserem Beispiel wird dieser Einfluss nicht für alle, sondern nur für ein Drittel aller Nutzer spürbar sein. Das ist bereits ein beachtliches Ergebnis.
Anzahl der Nutzer, die sich überschneiden werden
Wahrscheinlichkeit in Prozent
0
18%
1
54%
2
26%
3
2%
Lassen Sie uns die Situation in die Realität umsetzen – nehmen wir 100 Knoten und 5 Nutzer auf 5 Knoten. In diesem Fall überschneidet sich keiner der Knoten mit einer Wahrscheinlichkeit von 77%.
Anzahl der Nutzer, die sich überschneiden werden
Wahrscheinlichkeit in Prozent
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
In der realen Situation, bei einer großen Anzahl von HyperPlane-Knoten und Nutzern, ist der potenzielle Einfluss des störenden Nachbarn auf andere Nutzer minimal. Diese Methode wird genannt Shuffle Sharding — . Sie minimiert den negativen Effekt durch Ausfälle von Knoten.Auf der Grundlage von HyperPlane wurden zahlreiche Dienste aufgebaut: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Größe des Netzwerks
Netzwerkausmaße
Jetzt sprechen wir über das Ausmaß des Netzwerks. Im Oktober 2019 bietet AWS seine Dienste in 22 Regionen, und es sind weitere 9 geplant.
- Jede Region umfasst mehrere Availability Zones. Weltweit gibt es insgesamt 69.
- Jede AZ besteht aus Rechenzentren. Insgesamt sind es nicht mehr als 8.
- In den Rechenzentren befinden sich eine enorme Anzahl von Servern, in einigen bis zu 300.000.
Jetzt mitteln wir all das, multiplizieren es und erhalten eine beeindruckende Zahl, die das Ausmaß der Amazon-Cloud.
zwischen den Availability Zones und den Rechenzentren liegen viele optische Kanäle. In einer unserer größten Regionen wurden für die Verbindung der AZ untereinander und mit den Transitzentren in anderen Regionen 388 Kanäle verlegt. Insgesamt ergibt das verrückte 5000 Tbit.
Das AWS-Backbone wurde speziell für die Cloud entwickelt und optimiert, um mit ihr zu arbeiten. Wir bauen es auf Kanälen 100 Gbit/s. Wir kontrollieren sie vollständig, mit Ausnahme der Regionen in China. Der Datenverkehr wird nicht mit anderen 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, beispielsweise von .
, bestätigt. Im Diagramm ist zu sehen, dass der Anteil der Content- und Cloud-Anbieter wächst. Daher sinkt der Anteil des Internetverkehrs der Backbone-Anbieter ständig.
Ich erkläre, warum das so ist. Früher waren die meisten Webdienste direkt aus dem Internet erreichbar und wurden dort konsumiert. Jetzt befinden sich immer mehr Server in der Cloud und sind über CDN — Content Delivery Networkserreichbar. Um auf eine Ressource zuzugreifen, geht der Benutzer über das Internet bis zum nächstgelegenen CDN PoP — Point of Presence. Meistens ist das irgendwo in der Nähe. Danach verlässt er das öffentliche Internet und reist über ein privates Backbone, zum Beispiel über den Atlantik, direkt zur Ressource.
Es ist interessant, wie sich das Internet in 10 Jahren ändern wird, wenn dieser Trend anhält.
Physische Kanäle
Wissenschaftler haben bisher nicht herausgefunden, wie man die Lichtgeschwindigkeit im Universum erhöhen kann, aber sie haben in den Methoden zur Übertragung von Licht durch Glasfaser große Fortschritte gemacht. Derzeit verwenden wir Kabel mit 6912 Fasern. Das hilft, die Kosten ihrer Verlegung deutlich zu optimieren.
In einigen Regionen müssen wir spezielle Kabel verwenden. Zum Beispiel verwenden wir in der Region Sydney Kabel mit einer speziellen Beschichtung gegen Termiten.
Niemand ist vor Schwierigkeiten sicher, und manchmal werden unsere Kanäle beschädigt. Auf dem Foto rechts sind die optischen Kabel in einer der amerikanischen Regionen zu sehen, die von Bauarbeitern durchtrennt wurden. Durch den Vorfall gingen lediglich 13 Datenpakete verloren, was erstaunlich ist. Nochmals – nur 13! Das System schaltete buchstäblich sofort auf die Sicherungskanäle um – der Maßstab funktioniert.
Wir haben einige Dienste und Technologien von Amazon Cloud im Schnelldurchlauf betrachtet. Ich hoffe, dass Sie nun zumindest einen gewissen Eindruck vom Umfang der Aufgaben haben, die unsere Ingenieure zu bewältigen haben. Persönlich finde ich das sehr spannend.
Dies ist der finale Teil der Trilogie von Wassili Pantjuchin über die Funktionsweise von AWS. In diesem Teil werden die Optimierung von Servern und das Scaling von Datenbanken beschrieben, und in — serverless Funktionen und Firecracker.
Auf Im November wird Wassili Pantjuchin neue Details zur Funktionsweise von Amazon teilen. Er geht auf die Ursachen von Ausfällen und das Design verteilter Systeme bei Amazon ein. Am 24. Oktober kann man noch eine Karte zu einem guten Preis kaufen und später bezahlen. Wir freuen uns auf Ihren Besuch bei HighLoad++, kommen Sie vorbei – wir unterhalten uns!
Quelle: habr.com
