Die Größe des Amazon Web Services-Netzwerks umfasst 69 Zonen auf der ganzen Welt in 22 Regionen: USA, Europa, Asien, Afrika und Australien. Jede Zone enthält bis zu 8 Rechenzentren – Datenverarbeitungszentren. Jedes Rechenzentrum verfügt über Tausende oder Hunderttausende Server. Das Netzwerk ist so konzipiert, dass alle unwahrscheinlichen Ausfallszenarien berücksichtigt werden. So sind beispielsweise alle Regionen voneinander isoliert und Erreichbarkeitszonen über Distanzen von mehreren Kilometern verteilt. Selbst wenn Sie das Kabel durchtrennen, schaltet das System auf Backup-Kanäle um und der Informationsverlust beläuft sich auf einige Datenpakete. Vasily Pantyukhin wird darüber sprechen, auf welchen weiteren Prinzipien das Netzwerk basiert und wie es strukturiert ist.
Wassili Pantjuchin begann als Unix-Administrator in .ru-Unternehmen, arbeitete 6 Jahre lang an großer Sun Microsystem-Hardware und predigte 11 Jahre lang bei EMC eine datenzentrierte Welt. Es entwickelte sich natürlich zu privaten Clouds und verlagerte sich dann auf öffentliche Clouds. Als Amazon Web Services-Architekt bietet er nun technische Beratung zum Leben und Entwickeln in der AWS-Cloud an.
Im vorherigen Teil der AWS-Trilogie befasste sich Vasily intensiv mit dem Design physischer Server und der Datenbankskalierung. Nitro-Karten, benutzerdefinierter KVM-basierter Hypervisor, Amazon Aurora-Datenbank – darüber alles im Material“" Für den Kontext lesen oder ansehen Reden.
Dieser Teil konzentriert sich auf die Netzwerkskalierung, eines der komplexesten Systeme in AWS. Die Entwicklung von einem flachen Netzwerk zu einer Virtual Private Cloud und deren Design, interne Dienste von Blackfoot und HyperPlane, das Problem eines lauten Nachbarn und am Ende – die Größe des Netzwerks, des Backbones und der physischen Kabel. Über all das unter dem Strich.
Haftungsausschluss: Alles Folgende ist Vasilys persönliche Meinung und stimmt möglicherweise nicht mit der Position von Amazon Web Services überein.
Netzwerkskalierung
Die AWS-Cloud wurde 2006 eingeführt. Sein Netzwerk war ziemlich primitiv – mit einer flachen Struktur. Der Bereich privater Adressen war allen Cloud-Mietern gemeinsam. Beim Starten einer neuen virtuellen Maschine haben Sie versehentlich eine verfügbare IP-Adresse aus diesem Bereich erhalten.
Dieser Ansatz war einfach umsetzbar, schränkte jedoch den Einsatz der Cloud grundsätzlich ein. Insbesondere war es ziemlich schwierig, Hybridlösungen zu entwickeln, die private Netzwerke vor Ort und in AWS kombinieren. Das häufigste Problem waren sich überschneidende IP-Adressbereiche.
Virtuelle Private Cloud
Es stellte sich heraus, dass die Cloud gefragt war. Es ist an der Zeit, über Skalierbarkeit und die Möglichkeit ihrer Nutzung durch zig Millionen Mieter nachzudenken. Das flache Netz ist zu einem großen Hindernis geworden. Deshalb haben wir darüber nachgedacht, wie wir Benutzer auf Netzwerkebene voneinander isolieren können, damit sie ihre IP-Bereiche unabhängig auswählen können.
Was fällt Ihnen als Erstes ein, wenn Sie an Netzwerkisolation denken? Sicherlich VLAN и VRF – Virtuelles Routing und Weiterleiten.
Leider hat es nicht funktioniert. Die VLAN-ID beträgt nur 12 Bit, was uns nur 4096 isolierte Segmente ergibt. Selbst die größten Switches können maximal 1-2 VRFs verwenden. Wenn wir VRF und VLAN zusammen verwenden, erhalten wir nur wenige Millionen Subnetze. Dies ist definitiv nicht genug für zig Millionen Mieter, von denen jeder mehrere Subnetze nutzen können muss.
Außerdem können wir es uns einfach nicht leisten, die erforderliche Anzahl großer Boxen beispielsweise von Cisco oder Juniper zu kaufen. Dafür gibt es zwei Gründe: Es ist wahnsinnig teuer und wir wollen nicht der Gnade ihrer Entwicklungs- und Patching-Richtlinien ausgeliefert sein.
Es gibt nur eine Schlussfolgerung: Finden Sie Ihre eigene Lösung.
Im Jahr 2009 gaben wir bekannt VPC - Virtuelle Private Cloud. Der Name blieb hängen und mittlerweile verwenden ihn auch viele Cloud-Anbieter.
VPC ist ein virtuelles Netzwerk SDN (Softwaredefiniertes Netzwerk). Wir haben uns entschieden, keine speziellen Protokolle auf den Ebenen L2 und L3 zu erfinden. Das Netzwerk läuft über Standard-Ethernet und IP. Für die Übertragung über das Netzwerk wird der Datenverkehr der virtuellen Maschine in unserem eigenen Protokoll-Wrapper gekapselt. Es gibt die ID an, die zur VPC des Mandanten gehört.
Klingt einfach. Es gibt jedoch einige gravierende technische Herausforderungen, die bewältigt werden müssen. Zum Beispiel, wo und wie Daten zur Zuordnung virtueller MAC/IP-Adressen, VPC-ID und entsprechender physischer MAC/IP gespeichert werden. Im AWS-Maßstab ist dies eine riesige Tabelle, die mit minimalen Zugriffsverzögerungen funktionieren sollte. Verantwortlich dafür Kartendienst, die in einer dünnen Schicht im gesamten Netzwerk verteilt ist.
Bei Maschinen der neuen Generation erfolgt die Kapselung durch Nitro-Karten auf Hardwareebene. In älteren Fällen erfolgen Kapselung und Entkapselung softwarebasiert.
Lassen Sie uns herausfinden, wie es im Allgemeinen funktioniert. Beginnen wir mit der L2-Ebene. Nehmen wir an, wir haben eine virtuelle Maschine mit der IP 10.0.0.2 auf einem physischen Server 192.168.0.3. Es sendet Daten an die virtuelle Maschine 10.0.0.3, die sich auf 192.168.1.4 befindet. Eine ARP-Anfrage wird generiert und an die Netzwerk-Nitro-Karte gesendet. Der Einfachheit halber gehen wir davon aus, dass beide virtuellen Maschinen in derselben „blauen“ VPC leben.
Die Karte ersetzt die Quelladresse durch ihre eigene und leitet den ARP-Frame an den Kartendienst weiter.
Der Zuordnungsdienst gibt Informationen zurück, die für die Übertragung über das physische L2-Netzwerk erforderlich sind.
Die Nitro-Karte in der ARP-Antwort ersetzt den MAC im physischen Netzwerk durch eine Adresse in der VPC.
Bei der Datenübertragung verpacken wir logische MAC- und IP-Adressen in einen VPC-Wrapper. All dies übertragen wir über das physische Netzwerk mit den entsprechenden Quell- und Ziel-IP-Nitro-Karten.
Die Prüfung erfolgt durch die physische Maschine, für die das Paket bestimmt ist. Dies ist notwendig, um die Möglichkeit eines Adressspoofings zu verhindern. Die Maschine sendet eine spezielle Anfrage an den Kartendienst und fragt: „Von der physischen Maschine 192.168.0.3 habe ich ein Paket erhalten, das für 10.0.0.3 in der blauen VPC bestimmt ist.“ Ist er legitim?
Der Zuordnungsdienst überprüft seine Ressourcenzuordnungstabelle und lässt die Durchleitung des Pakets zu oder verweigert es. In allen neuen Fällen ist eine zusätzliche Validierung in Nitro-Karten integriert. Es ist nicht einmal theoretisch möglich, es zu umgehen. Daher funktioniert Spoofing auf Ressourcen in einer anderen VPC nicht.
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 verschiedenen Subnetzen. Vom Konzept her ist alles einfach, ich werde nicht ins Detail gehen.
Es stellt sich heraus, dass sich die Server bei der Übertragung jedes Pakets an den Kartendienst wenden. Wie gehe ich mit unvermeidlichen Verzögerungen um? Caching, Natürlich.
Das Schöne ist, dass Sie nicht die gesamte große Tabelle zwischenspeichern müssen. Ein physischer Server hostet virtuelle Maschinen aus einer relativ kleinen Anzahl von VPCs. Sie müssen nur Informationen zu diesen VPCs zwischenspeichern. Die Übertragung von Daten auf andere VPCs in der „Standard“-Konfiguration ist weiterhin nicht legitim. Werden Funktionalitäten wie VPC-Peering genutzt, werden zusätzlich Informationen über die entsprechenden VPCs in den Cache geladen.
Wir haben die Datenübertragung an die VPC geklärt.
Schwarzfuß
Was tun, wenn der Datenverkehr nach außen übertragen werden muss, beispielsweise ins Internet oder per VPN zur Erde? Hilft uns hier weiter Schwarzfuß – AWS-interner Service. Es wurde von unserem südafrikanischen Team entwickelt. Deshalb ist der Dienst nach einem in Südafrika lebenden Pinguin benannt.
Blackfoot entkapselt den Datenverkehr und macht mit ihm das, was nötig ist. Die Daten werden unverändert an das Internet gesendet.
Bei Verwendung eines VPN werden die Daten entkapselt und erneut in IPsec verpackt.
Bei Verwendung von Direct Connect wird der Datenverkehr markiert und an das entsprechende VLAN gesendet.
HyperPlane
Dies ist ein interner Flusskontrolldienst. Viele Netzwerkdienste erfordern eine Überwachung Datenflusszustände. Wenn Sie beispielsweise NAT verwenden, muss die Flusskontrolle sicherstellen, dass jedes IP-Ziel-Port-Paar über einen eindeutigen ausgehenden Port verfügt. Im Falle eines Balancers NLB - Netzwerk-Load-Balancer, sollte der Datenfluss immer an dieselbe virtuelle Zielmaschine geleitet werden. Security Groups ist eine Stateful-Firewall. Es überwacht den eingehenden Datenverkehr und öffnet implizit Ports für den ausgehenden Paketfluss.
In der AWS-Cloud sind die Anforderungen an die Übertragungslatenz extrem hoch. Deshalb HyperPlane entscheidend für die Leistung des gesamten Netzwerks.
Hyperplane basiert auf virtuellen EC2-Maschinen. Hier gibt es keine Magie, nur List. Der Trick besteht darin, dass es sich um virtuelle Maschinen mit großem RAM handelt. Operationen sind transaktional und werden ausschließlich im Speicher ausgeführt. Dadurch können Sie Verzögerungen von nur einigen zehn Mikrosekunden erreichen. Die Arbeit mit der Festplatte würde jegliche Produktivität zerstören.
Hyperplane ist ein verteiltes System einer großen Anzahl solcher EC2-Maschinen. Jede virtuelle Maschine verfügt über eine Bandbreite von 5 GB/s. Im gesamten regionalen Netzwerk stehen dadurch unglaubliche Terabit Bandbreite zur Verfügung und ermöglichen die Verarbeitung Millionen Verbindungen pro Sekunde.
HyperPlane funktioniert nur mit Streams. Die VPC-Paketkapselung ist dafür völlig transparent. Eine potenzielle Schwachstelle in diesem internen Dienst würde dennoch verhindern, dass die VPC-Isolation durchbrochen wird. Die darunter liegenden Ebenen sind für die Sicherheit zuständig.
Lauter Nachbar
Es gibt immer noch ein Problem lauter Nachbar - lauter Nachbar. Nehmen wir an, wir haben 8 Knoten. Diese Knoten verarbeiten die Datenflüsse aller Cloud-Benutzer. Alles scheint in Ordnung zu sein und die Last sollte gleichmäßig auf alle Knoten verteilt sein. Knoten sind sehr leistungsfähig und es ist schwierig, sie zu überlasten.
Aber wir bauen unsere Architektur auch auf der Grundlage unwahrscheinlicher Szenarien auf.
Geringe Wahrscheinlichkeit bedeutet nicht unmöglich.
Wir können uns eine Situation vorstellen, in der ein oder mehrere Benutzer zu viel Last erzeugen würden. Alle HyperPlane-Knoten sind an der Verarbeitung dieser Last beteiligt, und bei anderen Benutzern kann es möglicherweise zu Leistungseinbußen kommen. Dies widerspricht dem Konzept der Cloud, in der Mieter keine Möglichkeit haben, sich gegenseitig zu beeinflussen.
Wie kann man das Problem eines lauten Nachbarn lösen? Das erste, was mir in den Sinn kommt, ist Sharding. Unsere 8 Knoten sind logisch in 4 Shards zu je 2 Knoten unterteilt. Nun wird ein lauter Nachbar zwar nur ein Viertel aller Nutzer stören, aber er wird sie stark stören.
Lasst uns die Dinge anders machen. Wir werden jedem Benutzer nur 3 Knoten zuweisen.
Der Trick besteht darin, Knoten zufällig verschiedenen Benutzern zuzuweisen. Im Bild unten schneidet der blaue Benutzer Knoten mit einem der beiden anderen Benutzer – grün und orange.
Bei 8 Knoten und 3 Benutzern beträgt die Wahrscheinlichkeit, dass ein lauter Nachbar einen der Benutzer kreuzt, 54 %. Mit dieser Wahrscheinlichkeit beeinflusst ein blauer Nutzer andere Mieter. Gleichzeitig nur ein Teil seiner Belastung. In unserem Beispiel wird dieser Einfluss nicht für jeden, sondern nur für ein Drittel aller Nutzer zumindest irgendwie spürbar sein. Das ist bereits 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 der Realität näher bringen – nehmen wir 100 Knoten und 5 Benutzer auf 5 Knoten. In diesem Fall wird sich keiner der Knoten mit einer Wahrscheinlichkeit von 77 % schneiden.
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 einer realen Situation mit einer großen Anzahl von HyperPlane-Knoten und Benutzern sind die potenziellen Auswirkungen eines lauten Nachbarn auf andere Benutzer minimal. Diese Methode heißt Sharding mischen - Shuffle-Sharding. Es minimiert die negativen Auswirkungen eines Knotenausfalls.
Viele Dienste basieren auf HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Netzwerkskala
Lassen Sie uns nun über die Größe des Netzwerks selbst sprechen. Für Oktober 2019 bietet AWS seine Dienste in an 22 Regionen, und 9 weitere sind geplant.
- Jede Region enthält mehrere Availability Zones. Weltweit gibt es davon 69.
- Jede AZ besteht aus Datenverarbeitungszentren. Insgesamt gibt es nicht mehr als 8 davon.
- Das Rechenzentrum beherbergt eine riesige Anzahl an Servern, teilweise mit bis zu 300.
Lassen Sie uns nun den Mittelwert aus all dem bilden, multiplizieren und eine beeindruckende Zahl erhalten, die dies widerspiegelt Amazon Cloud-Skala.
Es gibt viele optische Verbindungen zwischen Availability Zones und dem Rechenzentrum. In einer unserer größten Regionen wurden 388 Kanäle nur für die AZ-Kommunikation untereinander und für Kommunikationszentren mit anderen Regionen (Transitzentren) eingerichtet. Insgesamt gibt das Wahnsinn 5000 Tbit.
Backbone AWS wurde speziell für die Cloud entwickelt und optimiert. Wir bauen es auf den Kanälen auf 100 GB/s. Wir kontrollieren sie vollständig, mit Ausnahme der Regionen in China. Der Verkehr 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 gehen diesen Weg. Dies bestätigen beispielsweise unabhängige Forscher von .
Die Grafik zeigt, dass der Anteil der Content-Anbieter und Cloud-Anbieter wächst. Aus diesem Grund nimmt der Anteil des Internetverkehrs der Backbone-Anbieter stetig ab.
Ich werde erklären, warum das passiert. Bisher waren die meisten Webdienste direkt über das Internet zugänglich und wurden direkt genutzt. Heutzutage befinden sich immer mehr Server in der Cloud und sind über erreichbar CDN - Inhaltsverteilungsnetzwerk. Um auf eine Ressource zuzugreifen, geht der Benutzer über das Internet nur zum nächstgelegenen CDN-PoP – Präsenzpunkt. Meistens ist es irgendwo in der Nähe. Dann verlässt es das öffentliche Internet und fliegt beispielsweise über ein privates Backbone über den Atlantik und gelangt direkt zur Ressource.
Ich frage mich, wie sich das Internet in 10 Jahren verändern wird, wenn dieser Trend anhält?
Physische Kanäle
Wissenschaftler haben noch nicht herausgefunden, wie man die Lichtgeschwindigkeit im Universum erhöhen kann, aber sie haben große Fortschritte bei den Methoden zur Übertragung über Glasfaser gemacht. Wir verwenden derzeit 6912-Glasfaserkabel. Dies trägt dazu bei, die Kosten ihrer Installation deutlich zu optimieren.
In einigen Regionen müssen wir spezielle Kabel verwenden. Beispielsweise nutzen wir in der Region Sydney Kabel mit einer speziellen Beschichtung gegen Termiten.
Niemand ist vor Problemen gefeit und manchmal werden unsere Kanäle beschädigt. Das Foto rechts zeigt optische Kabel in einer der amerikanischen Regionen, die von Bauarbeitern gerissen wurden. Durch den Unfall gingen überraschenderweise nur 13 Datenpakete verloren. Wieder einmal - nur 13! Das System schaltete buchstäblich sofort auf Backup-Kanäle um – die Waage funktioniert.
Wir sind durch einige der Cloud-Dienste und -Technologien von Amazon galoppiert. Ich hoffe, dass Sie zumindest eine Vorstellung davon haben, wie groß die Aufgaben sind, die unsere Ingenieure lösen müssen. Ich persönlich finde das sehr spannend.
Dies ist der letzte Teil der Trilogie von Vasily Pantyukhin über das AWS-Gerät. IN Teile beschreiben Serveroptimierung und Datenbankskalierung, und in – serverlose Funktionen und Firecracker.
Auf Im November wird Vasily Pantyukhin neue Details des Amazon-Geräts mitteilen. Er über Fehlerursachen und die Gestaltung verteilter Systeme bei Amazon. Der 24. Oktober ist noch möglich Ticket zu einem guten Preis kaufen und später bezahlen. Wir erwarten Sie bei HighLoad++, kommen Sie vorbei und lassen Sie uns chatten!
Source: habr.com