Wie AWS seine belastbaren Services zusammenstellt. Netzwerkskalierung

Das Amazon Web Services-Netzwerk verfügt über 69 Standorte weltweit in 22 Regionen: USA, Europa, Asien, Afrika und Australien. In jeder Zone gibt es bis zu 8 Rechenzentren - Datenverarbeitungszentren. Jedes Rechenzentrum verfügt über Tausende oder Hunderttausende von Servern. Das Netzwerk ist so aufgebaut, dass alle unwahrscheinlichen Ausfallszenarien berücksichtigt werden. Beispielsweise sind alle Regionen voneinander isoliert und die Zugangszonen sind mehrere Kilometer voneinander entfernt. Selbst wenn Sie das Kabel abschneiden, wechselt das System zu Sicherungskanälen, und der Informationsverlust beträgt Einheiten von Datenpaketen. Über welche anderen Prinzipien das Netzwerk aufgebaut ist und wie es aufgebaut ist, wird Vasily Pantyukhin sagen.



Vasily Pantyukhin begann als Unix-Administrator in .ru-Unternehmen, verbrachte 6 Jahre in den großen Drüsen des Sun Microsystems und predigte 11 Jahre lang bei EMC die Datenzentriertheit der Welt. Natürlich zu privaten Clouds entwickelt, dann an die Öffentlichkeit gegangen. Als Architekt von Amazon Web Services können Sie mit technischen Ratschlägen in der AWS-Cloud leben und wachsen.

Im vorherigen Teil der AWS-Gerätetrilogie befasste sich Vasily mit dem Gerät der physischen Server und der Datenbankskalierung. Nitro-Karten, benutzerdefinierter Hypervisor basierend auf KVM, Amazon Aurora-Datenbank - all dies im Artikel " Wie AWS" seine elastischen Dienste kocht ". Server- und Datenbankskalierung . “ Lesen Sie, um in den Kontext einzutauchen, oder sehen Sie sich ein Video der Präsentation an.

In diesem Teil konzentrieren wir uns auf die Netzwerkskalierung - eines der komplexesten Systeme in AWS. Entwicklung von einem flachen Netzwerk zu Virtual Private Cloud und seinem Gerät, internen Blackfoot- und HyperPlane-Diensten, dem Problem eines lauten Nachbarn und letztendlich der Größe des Netzwerks, des Backbones und der physischen Kabel. Über all das unter dem Schnitt.

Haftungsausschluss: Alles unten ist Vasilys persönliche Meinung und stimmt möglicherweise nicht mit der Position von Amazon Web Services überein.

Netzwerkskalierung

AWS Cloud wurde 2006 gestartet. Sein Netzwerk war ziemlich primitiv - mit einer flachen Struktur. Der Bereich der privaten Adressen war allen Mandanten der Cloud gemeinsam. Wenn Sie eine neue virtuelle Maschine starten, haben Sie versehentlich eine verfügbare IP-Adresse aus diesem Bereich erhalten.



Dieser Ansatz war einfach zu implementieren, beschränkte jedoch die Nutzung der Cloud grundlegend. Insbesondere war es ziemlich schwierig, hybride Lösungen zu entwickeln, die private Netzwerke vor Ort und in AWS kombinierten. Das häufigste Problem war der Schnittpunkt von IP-Adressbereichen.

Virtuelle private Cloud

Die Cloud war gefragt. Es ist Zeit, über die Skalierbarkeit und die Möglichkeit der Nutzung durch zig Millionen Mieter nachzudenken. Flaches Netzwerk ist zu einem großen Hindernis geworden. Daher haben wir uns überlegt, wie Benutzer auf Netzwerkebene voneinander isoliert werden können, damit sie IP-Bereiche unabhängig auswählen können.



Was fällt Ihnen zuerst ein, wenn Sie an Netzwerkisolation denken? Natürlich sind VLAN und VRF Virtual Routing und Forwarding .

Dies hat leider nicht funktioniert. Die VLAN-ID beträgt nur 12 Bit, wodurch wir nur 4096 isolierte Segmente erhalten. Selbst in den größten Switches können Sie maximal 1-2 Tausend VRF verwenden. Die kombinierte Verwendung von VRF und VLAN gibt uns nur wenige Millionen Subnetze. Dies ist definitiv nicht genug für zig Millionen Mieter, von denen jeder mehrere Subnetze nutzen kann.

Trotzdem können wir es uns einfach nicht leisten, die erforderliche Anzahl großer Kartons zu kaufen, beispielsweise von Cisco oder Juniper. Es gibt zwei Gründe: Es ist unglaublich teuer und wir möchten nicht von deren Entwicklungs- und Patch-Richtlinien abhängig werden.

Es gibt nur eine Schlussfolgerung - Ihre eigene Entscheidung zu treffen.

2009 haben wir VPC - Virtual Private Cloud angekündigt. Der Name hat Wurzeln geschlagen und wird jetzt auch von vielen Cloud-Anbietern verwendet.

VPC ist ein virtuelles SDN- Netzwerk (Software Defined Network). Wir haben beschlossen, 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 ein Netzwerk wird der Datenverkehr der virtuellen Maschine in einem Wrapper unseres eigenen Protokolls gekapselt. Es gibt die ID an, die zur Mandanten-VPC gehört.



Das klingt einfach. Es ist jedoch notwendig, mehrere schwerwiegende technische Probleme zu lösen. Beispiel: Wo und wie werden Zuordnungsdaten für virtuelle MAC / IP-Adressen, VPC-IDs und entsprechende physische MAC / IP-Adressen gespeichert? Auf einer AWS-Skala ist dies eine riesige Tabelle, die mit minimaler Latenz arbeiten sollte. Verantwortlich dafür ist der Mapping-Service , der im gesamten Netzwerk mit einer dünnen Schicht verschmiert ist.

In Maschinen neuer Generationen erfolgt die Einkapselung durch Nitro-Karten auf Eisenebene. In älteren Fällen Software-Kapselung und -Entkapselung.



Mal sehen, wie das allgemein funktioniert. Beginnen wir mit Level L2. Angenommen, wir haben eine virtuelle Maschine mit IP 10.0.0.2 auf einem physischen Server 192.168.0.3. Es sendet Daten an eine virtuelle Maschine 10.0.0.3, die unter 192.168.1.4 ausgeführt wird. Es wird eine ARP-Anfrage generiert, die auf die Nitro-Netzwerkkarte fällt. Der Einfachheit halber glauben wir, dass beide virtuellen Maschinen in derselben „blauen“ VPC leben.



Die Karte ersetzt die Quelladresse durch eine eigene und sendet den ARP-Frame an den Zuordnungsdienst.



Der Zuordnungsdienst gibt die Informationen zurück, die für die Übertragung über das physische L2-Netzwerk erforderlich sind.



Die Nitrokarte in der ARP-Antwort ersetzt den MAC im physischen Netzwerk durch die Adresse in der VPC.



Bei der Datenübertragung verpacken wir den logischen MAC und die IP in einen VPC-Wrapper. All dies wird über das physische Netzwerk mit den entsprechenden IP-Nitro-Karten der Quelle und des Ziels übertragen.



Die physische Maschine, auf der das Paket Überprüfungen durchführen soll. Dies soll die Möglichkeit von Spoofing verhindern. Der Computer sendet eine spezielle Anforderung an den Zuordnungsdienst und fragt: „Vom physischen Computer 192.168.0.3 habe ich ein Paket erhalten, das für 10.0.0.3 in der blauen VPC ausgelegt ist. Ist er legitim? "



Der Zuordnungsdienst überprüft seine Ressourcenzuordnungstabelle und erlaubt oder verweigert den Durchgang des Pakets. In allen neuen Fällen wird eine zusätzliche Validierung in Nitro-Karten eingefügt. Es ist unmöglich, sich auch theoretisch fortzubewegen. Daher funktioniert das Spoofing von Ressourcen in einer anderen VPC nicht.



Anschließend werden die Daten an die virtuelle Maschine gesendet, für die sie bestimmt sind.



Der Zuordnungsdienst fungiert auch als logischer Router zum Übertragen von Daten zwischen virtuellen Maschinen in verschiedenen Subnetzen. Dort ist konzeptionell alles einfach, ich werde es nicht im Detail analysieren.



Es stellt sich heraus, dass die Server während der Übertragung jedes Pakets auf den Zuordnungsdienst zugreifen. Wie gehe ich mit unvermeidlichen Verzögerungen um? Caching natürlich.

Der ganze Reiz ist, dass Sie nicht den gesamten riesigen Tisch zwischenspeichern müssen. Virtuelle Maschinen von einer relativ kleinen Anzahl von VPCs leben auf einem physischen Server. Informationen müssen nur über diese VPCs zwischengespeichert werden. Das Übertragen von Daten auf andere VPCs in der "Standard" -Konfiguration ist immer noch nicht legitim. Wenn Funktionen wie VPC-Peering verwendet werden, werden zusätzlich Informationen zu den entsprechenden VPCs in den Cache geladen.



Mit der Übertragung der Daten an die VPC herausgefunden.

Blackfoot

Was tun, wenn der Datenverkehr außerhalb des Unternehmens übertragen werden muss, z. B. im Internet oder über ein VPN zum Boden? Hier hilft uns Blackfoot , der interne AWS-Service. Es wurde von unserem südafrikanischen Team entworfen. Daher ist der Dienst nach dem in Südafrika lebenden Pinguin benannt.



Blackfoot entkapselt den Verkehr und macht damit, was es braucht. Internetdaten werden unverändert gesendet.



Bei Verwendung eines VPN werden die Daten entkapselt und erneut in einen IPSec-Wrapper eingeschlossen.



Bei Verwendung von Direct Connect wird der Datenverkehr markiert und an das entsprechende VLAN übertragen.

HyperPlane

Dies ist ein interner Flusskontrolldienst. Viele Netzwerkdienste erfordern die Überwachung des Status des Datenstroms . Wenn Sie beispielsweise NAT verwenden, sollte die Flusskontrolle sicherstellen, dass jedes Paar „IP: Zielport“ einen eindeutigen ausgehenden Port hat. Beim NLB- Balancer - Network Load Balancer sollte der Datenstrom immer an dieselbe virtuelle Zielmaschine geleitet werden. Sicherheitsgruppen ist eine Stateful Firewall. Es überwacht den eingehenden Verkehr und öffnet implizit Ports für den ausgehenden Paketstrom.



In der AWS-Cloud sind die Anforderungen an die Übertragungslatenz extrem hoch. Daher ist HyperPlane für den Zustand des gesamten Netzwerks von entscheidender Bedeutung.



Hyperplane basiert auf virtuellen EC2-Maschinen. Hier gibt es keine Magie, nur List. Der Trick ist, dass es sich um virtuelle Maschinen mit großem RAM handelt. Transaktionen sind Transaktionen und werden ausschließlich im Speicher ausgeführt. Dies ermöglicht Verzögerungen von nur einigen zehn Mikrosekunden. Das Arbeiten mit einer Festplatte würde die gesamte Leistung beeinträchtigen.

Hyperplane ist ein verteiltes System aus einer großen Anzahl solcher EC2-Maschinen. Jede virtuelle Maschine hat eine Bandbreite von 5 GB / s. Dies ergibt im gesamten regionalen Netzwerk wilde Terabit-Bandbreite und ermöglicht es Ihnen, Millionen von Verbindungen pro Sekunde zu verarbeiten .

HyperPlane funktioniert nur mit Threads. Die VPC-Paketkapselung ist für ihn völlig transparent. Die potenzielle Sicherheitsanfälligkeit in diesem internen Dienst lässt die VPC-Isolation weiterhin nicht zu. Für die Sicherheit sind die folgenden Ebenen verantwortlich.

Lauter Nachbar

Es gibt auch das Problem mit lauten Nachbarn . Angenommen, wir haben 8 Knoten. Diese Knoten verarbeiten die Threads aller Cloud-Benutzer. Alles scheint in Ordnung zu sein und die Last sollte gleichmäßig auf alle Knoten verteilt sein. Die Knoten sind sehr leistungsfähig und schwer zu überlasten.

Aber wir bauen unsere Architektur auf selbst unwahrscheinlichen Szenarien auf.

Geringe Wahrscheinlichkeit bedeutet nicht Unmöglichkeit.

Wir können uns eine Situation vorstellen, in der ein oder mehrere Benutzer zu viel Last erzeugen. Alle HyperPlane-Knoten sind an der Verarbeitung dieser Last beteiligt, und andere Benutzer können möglicherweise eine Leistungsverschlechterung spüren. Dies zerstört das Konzept der Cloud, in der sich die Mieter nicht gegenseitig beeinflussen können.



Wie kann man das Problem eines lauten Nachbarn lösen? Das erste, was mir in den Sinn kommt, ist Scherben. Unsere 8 Knoten sind logisch in 4 Shards mit jeweils 2 Knoten unterteilt. Jetzt wird ein lauter Nachbar nur von einem Viertel aller Benutzer behindert, aber viel mehr.



Lass es uns anders machen. Jedem Benutzer sind nur 3 Knoten zugeordnet.



Der Trick besteht darin, Knoten zufällig verschiedenen Benutzern zuzuweisen. In der Abbildung unten schneidet der blaue Benutzer die 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 mit einem der Benutzer überquert, 54%. Mit dieser Wahrscheinlichkeit wirkt sich der blaue Benutzer auf andere Mieter aus. Darüber hinaus nur ein Teil seiner Last. In unserem Beispiel wird dieser Einfluss zumindest nicht für alle spürbar sein, sondern nur für ein Drittel aller Benutzer. Das ist schon ein gutes Ergebnis.

Lassen Sie uns die Situation näher an die reale bringen - nehmen Sie 100 Knoten und 5 Benutzer auf 5 Knoten. In diesem Fall schneidet sich keiner der Knoten mit einer Wahrscheinlichkeit von 77%.

In einer realen Situation mit einer großen Anzahl von HyperPlane-Knoten und -Benutzern ist die potenzielle Auswirkung eines lauten Nachbarn auf andere Benutzer minimal. Diese Methode wird als Shuffle-Sharding bezeichnet . Es minimiert die negativen Auswirkungen eines Knotenausfalls.

Viele Dienste basieren auf HyperPlane: Netzwerklastenausgleich, NAT-Gateway, Amazon EFS, AWS PrivateLink und 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 22 Regionen an , 9 weitere sind geplant.

• Jede Region enthält mehrere Verfügbarkeitszonen. Es gibt 69 von ihnen auf der Welt.
  
• Jede AZ besteht aus Datenverarbeitungszentren. Es gibt nicht mehr als 8 von ihnen.
  
• Im Rechenzentrum gibt es eine große Anzahl von Servern, einige bis zu 300.000.
  

Jetzt wird alles gemittelt, multipliziert und erhält eine beeindruckende Zahl, die die Größe der Amazon-Cloud anzeigt.

Zwischen den Zugangszonen und dem Rechenzentrum sind viele optische Kanäle verlegt. In einer unserer größten Regionen wurden nur 388 Kanäle für die Verbindung zwischen AZ und Kommunikationszentren mit anderen Regionen (Transitzentren) eingerichtet. Insgesamt ergibt dies verrückte 5000 Tbit .



Backbone AWS wurde speziell für die Cloud entwickelt und für die Arbeit mit dieser optimiert. Wir bauen es auf 100 GB / s- Kanälen. Wir kontrollieren sie vollständig, mit Ausnahme der Regionen in China. Der Datenverkehr wird nicht mit den 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 wird beispielsweise von unabhängigen Forschern aus der Telegeographie bestätigt .



Die Grafik zeigt, dass der Anteil von Inhaltsanbietern und Cloud-Anbietern wächst. Aus diesem Grund nimmt der Anteil des Internetverkehrs von Backbone-Anbietern ständig ab.

Ich werde erklären, warum dies passiert. Bisher waren die meisten Webdienste verfügbar und wurden direkt aus dem Internet genutzt. Jetzt befinden sich immer mehr Server in der Cloud und sind über das CDN - Content Distribution Network verfügbar. Um auf die Ressource zuzugreifen, geht der Benutzer über das Internet nur zum nächsten CDN PoP - Point of Presence . Meistens ist es irgendwo in der Nähe. Dann verlässt er das öffentliche Internet und fliegt beispielsweise über ein privates Backbone durch den Atlantik und gelangt direkt zur Ressource.

Ich frage mich, wie sich das Internet in 10 Jahren ändern wird, wenn sich dieser Trend fortsetzt.

Physische Kanäle

Wissenschaftler haben noch nicht herausgefunden, wie die Lichtgeschwindigkeit im Universum erhöht werden kann, haben jedoch große Fortschritte bei den Methoden zur Übertragung durch Lichtwellenleiter erzielt. Wir verwenden derzeit 6912 Glasfaserkabel. Dies hilft, die Kosten ihrer Installation erheblich zu optimieren.

In einigen Regionen müssen spezielle Kabel verwendet werden. In der Region Sydney verwenden wir beispielsweise Kabel mit einer speziellen Beschichtung gegen Termiten.



Niemand ist vor Problemen sicher und manchmal sind unsere Kanäle beschädigt. Das Foto rechts zeigt optische Kabel in einer der amerikanischen Regionen, die von Bauherren zerrissen wurden. Infolge des Unfalls gingen nur 13 Datenpakete verloren, was überraschend ist. Noch einmal - nur 13! Das System wechselte buchstäblich sofort zu Backup-Kanälen - die Waage funktioniert.

Wir galoppierten über einige Amazon Cloud-Dienste und -Technologien. Ich hoffe, Sie haben zumindest eine Vorstellung von der Größe der Aufgaben, die unsere Ingenieure lösen müssen. Ich persönlich interessiere mich sehr dafür.

Dies ist der letzte Teil der Trilogie von Vasily Pantyukhin über das AWS-Gerät. Der erste Teil beschreibt die Serveroptimierung und Datenbankskalierung, und der zweite Teil beschreibt serverlose Funktionen und Firecracker.

Bei HighLoad ++ im November wird Vasily Pantyukhin neue Amazon-Gerätedetails veröffentlichen. Er wird über die Fehlerursachen und das Design verteilter Systeme bei Amazon sprechen . Am 24. Oktober können Sie noch ein Ticket zu einem guten Preis buchen und später bezahlen. Wir warten bei HighLoad ++ auf Sie, kommen Sie und reden Sie!