{"id":39302,"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-serverov-i-bazy-dannyh\/"},"modified":"2019-10-31T22:29:40","modified_gmt":"2019-10-31T19:29:40","slug":"kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh","title":{"rendered":"Wie AWS seine flexiblen Dienste \u201ebraut\u201c. Skalierung von Servern und Datenbanken","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Cloud \u00e4hnelt einer magischen Schatzkiste \u2013 du gibst an, was du brauchst, und die Ressourcen erscheinen einfach aus dem Nichts. Virtuelle Maschinen, Datenbanken, Netzwerke \u2013 all das geh\u00f6rt nur dir. Es gibt auch andere Cloud-Tenants, aber in deinem Universum bist du der alleinige Herrscher. Du bist dir sicher, dass du immer die ben\u00f6tigten Ressourcen bekommst, ohne R\u00fccksicht auf andere und bestimmst selbst, wie das Netzwerk aussehen wird. Wie funktioniert diese Magie, die die Cloud dazu bringt, Ressourcen flexibel zuzuteilen und die Tenants vollst\u00e4ndig voneinander zu isolieren?<\/p>\n

\"Wie
\n
\nDie AWS-Cloud ist ein mega-super-komplexes System, das sich seit 2006 evolution\u00e4r entwickelt. Ein Teil dieser Entwicklung wurde Wassili Pantuchin<\/strong> \u2013 Architekt von Amazon Web Services. Als Architekt sieht er nicht nur das Endergebnis, sondern auch die Herausforderungen, die AWS bew\u00e4ltigt. Je mehr Verst\u00e4ndnis f\u00fcr die Funktionsweise des Systems, desto mehr Vertrauen. Daher wird Wassili die Geheimnisse der AWS-Cloud-Services teilen. Im Folgenden wird die Struktur der physischen AWS-Server, die elastische Skalierbarkeit von Datenbanken, die benutzerdefinierte Amazon-Datenbank und Methoden zur Leistungssteigerung virtueller Maschinen bei gleichzeitiger Senkung der Kosten behandelt. Das Wissen \u00fcber die Architekturans\u00e4tze von Amazon hilft, die AWS-Services effizienter zu nutzen und m\u00f6glicherweise neue Ideen zur Entwicklung eigener L\u00f6sungen zu finden.
\n<\/a><\/noindex>
\n\u00dcber den Sprecher: Wassili Pantuchin (Hen<\/a><\/noindex>) begann als Unix-Admin in .ru-Unternehmen, arbeitete 6 Jahre mit gro\u00dfen Systemen von Sun Microsystem und lehrte 11 Jahre lang die Datenzentrum-Orientierung der Welt bei EMC. Naturgem\u00e4\u00df entwickelte er sich zu privaten Clouds, und 2017 wechselte er zu \u00f6ffentlichen. Heute gibt er technische Ratschl\u00e4ge, um das Leben in der AWS-Cloud zu unterst\u00fctzen und zu f\u00f6rdern.<\/p>\n

Haftungsausschluss: Alles, was im Folgenden steht, ist die pers\u00f6nliche Meinung von Wassili und k\u00f6nnte von der Position von Amazon Web Services abweichen. Die Videoaufnahme<\/a><\/noindex> des Vortrags, auf dessen Basis der Artikel erstellt wurde, ist auf unserem YouTube-Kanal verf\u00fcgbar.<\/i><\/p>\n

Warum ich \u00fcber die Struktur von Amazon spreche<\/h2>\n

\nMein erstes Auto hatte einen \u201eSchalthebel\u201c \u2013 mit einem manuellen Getriebe. Das war gro\u00dfartig, weil ich das Gef\u00fchl hatte, dass ich das Auto steuern und vollst\u00e4ndig kontrollieren kann. Au\u00dferdem gefiel mir, dass ich zumindest ungef\u00e4hr das Prinzip seiner Funktionsweise verstand. Nat\u00fcrlich stellte ich mir den Aufbau des Getriebes eher primitiv vor \u2013 etwa wie ein Fahrradgetriebe.<\/p>\n

\"Wie
\n
\nAlles war gro\u00dfartig, bis auf eines \u2013 das Stehen im Stau. Man sitzt scheinbar und macht nichts, aber man schaltet st\u00e4ndig die G\u00e4nge, dr\u00fcckt die Kupplung, das Gas, die Bremse \u2013 das macht wirklich m\u00fcde. Das Stauproblem hat sich teilweise gel\u00f6st, als in der Familie ein Automatikauto hinzukam. Am Steuer hatte ich Zeit, \u00fcber etwas nachzudenken und ein H\u00f6rbuch zu h\u00f6ren.<\/p>\n

In meinem Leben gab es noch ein R\u00e4tsel, denn ich verstand \u00fcberhaupt nicht mehr, wie mein Auto funktioniert. Ein modernes Auto ist ein komplexes Ger\u00e4t. Es passt sich gleichzeitig an Dutzende verschiedener Parameter an: Gaspedal, Bremse, Fahrstil, Stra\u00dfenzustand. Ich verstehe nicht mehr, wie das funktioniert.<\/p>\n

Als ich anfing, mich mit der Amazon Cloud zu besch\u00e4ftigen, war das f\u00fcr mich ebenfalls ein R\u00e4tsel. Nur war dieses R\u00e4tsel um ein Vielfaches gr\u00f6\u00dfer, denn im Auto gibt es einen Fahrer, und in AWS gibt es Millionen. Alle Nutzer steuern gleichzeitig, dr\u00fccken das Gas und die Bremse. Es ist erstaunlich, dass sie dorthin fahren, wo sie wollen \u2013 f\u00fcr mich ist das ein Wunder! Das System passt sich automatisch an, skaliert und passt sich flexibel an jeden Benutzer an, sodass es ihm so vorkommt, als w\u00e4re er der einzige in diesem Universum.<\/p>\n

Die Magie schwand etwas, als ich sp\u00e4ter begann, als Architekt bei Amazon zu arbeiten. Ich sah, mit welchen Problemen wir konfrontiert sind, wie wir sie l\u00f6sen, wie wir die Dienste entwickeln. Mit wachsendem Verst\u00e4ndnis f\u00fcr die Funktionsweise des Systems w\u00e4chst das Vertrauen in den Dienst. Deshalb m\u00f6chte ich die Mechanismen hinter der AWS Cloud teilen.<\/p>\n

Wor\u00fcber werden wir sprechen<\/h2>\n

\nIch habe einen diversifizierten Ansatz gew\u00e4hlt \u2013 ich habe vier interessante Dienste ausgew\u00e4hlt, \u00fcber die es sich lohnt zu sprechen.<\/p>\n

Serveroptimierung<\/strong>. Ephemeral Clouds mit physischer Manifestation: Physische Rechenzentren, in denen physische Server stehen, die summen, W\u00e4rme erzeugen und mit Lichtern blitzen.<\/p>\n

Serverless-Funktionen <\/strong>(Lambda) \u2013 wahrscheinlich der skalierbarste Dienst in der Cloud.<\/p>\n

Datenbank-Skalierung<\/strong>. Ich werde erz\u00e4hlen, wie wir unsere eigenen skalierbaren DBs aufbauen.<\/p>\n

Netzwerkskalierung<\/strong>. Der letzte Teil, in dem ich die Struktur unseres Netzwerks enth\u00fclle. Es ist eine wunderbare Sache \u2013 jeder Cloud-Nutzer glaubt, dass er alleine in der Cloud ist und \u00fcberhaupt keine anderen Tenants sieht.<\/p>\n

Hinweis. In diesem Artikel geht es um die Optimierung von Servern und das Skalieren von Datenbanken. Die Skalierung von Netzwerken wird im n\u00e4chsten Artikel behandelt. Wo bleiben die serverlosen Funktionen? Dar\u00fcber gibt es eine separate Aufschl\u00fcsselung.Klein, aber oho. Unboxing der Mikrovirtualisierung Firecracker<\/a><\/noindex>Dar\u00fcber wird \u00fcber verschiedene Ans\u00e4tze zur Skalierung berichtet und die L\u00f6sung Firecracker im Detail besprochen \u2013 eine Symbiose der besten Eigenschaften von virtuellen Maschinen und Containern.<\/i><\/p><\/blockquote>\n

<\/p>\n

Die Server<\/h2>\n

\nDie Cloud ist verg\u00e4nglich. Aber diese Verg\u00e4nglichkeit hat dennoch eine physische Verk\u00f6rperung \u2013 die Server. Urspr\u00fcnglich war ihre Architektur klassisch. Standard-x86-Chipsatz, Netzwerkkarten, Linux, Hypervisor Xen, auf dem die virtuellen Maschinen liefen.<\/p>\n

\"Wie
\n
\nIm Jahr 2012 kam diese Architektur ihren Aufgaben durchaus nach. Xen ist ein ausgezeichneter Hypervisor, hat jedoch einen gravierenden Nachteil. Es gibt erhebliche Overheadkosten bei der Ger\u00e4teemulation.<\/strong>Mit dem Aufkommen neuer, schnellerer Netzwerkkarten oder SSDs werden diese Kosten jedoch zu hoch. Wie l\u00e4sst sich dieses Problem l\u00f6sen? Wir entschieden uns, an zwei Fronten gleichzeitig zu arbeiten \u2013 Sowohl die Hardware als auch den Hypervisor zu optimieren.<\/strong>Die Herausforderung ist sehr ernst.<\/p>\n

Optimierung von Hardware und Hypervisor<\/h3>\n

\nAlles gleichzeitig und gut zu machen, ist nicht m\u00f6glich. Was \u201egut\u201c bedeutet, war anf\u00e4nglich auch unklar.<\/p>\n

Wir entschieden uns f\u00fcr einen evolution\u00e4ren Ansatz \u2013 wir \u00e4ndern ein wichtiges Element der Architektur und bringen es in die Produktion.<\/p><\/blockquote>\n

Wir treten auf alle Rechen weiter, h\u00f6ren Beschwerden und Vorschl\u00e4ge. Dann \u00e4ndern wir eine andere Komponente. So \u00e4ndern wir schrittweise die gesamte Architektur basierend auf dem Feedback von Benutzern und Support.<\/p>\n

Die Transformation begann 2013 mit dem schwierigsten \u2013 dem Netzwerk. In den C3<\/strong> Instanzen wurde zur Standard-Netzwerkkarte eine spezielle Network Accelerator-Karte hinzugef\u00fcgt. Sie wurde buchst\u00e4blich mit einem kurzen Loopback-Kabel an der Vorderseite verbunden. Nicht sch\u00f6n, aber in der Cloud sieht man es nicht. Daf\u00fcr hat die direkte Interaktion mit der Hardware das Jitter und die Bandbreite des Netzwerks grundlegend verbessert.<\/p>\n

Anschlie\u00dfend beschlossen wir, den Zugriff auf den Elastic Block Storage (EBS) zu verbessern \u2013 eine Kombination aus Netzwerk und Speicher. Die Herausforderung bestand darin, dass es zwar Network Accelerator-Karten auf dem Markt gab, aber keine M\u00f6glichkeit, Hardware f\u00fcr Storage Accelerator zu kaufen. Daher wandten wir uns an das Start-up Annapurna Labs.<\/strong>, der spezielle ASIC-Chips f\u00fcr uns entwickelt hat. Diese erm\u00f6glichten es, entfernte EBS-Volumes als NVMe-Ger\u00e4te anzuschlie\u00dfen.<\/p>\n

In den Instanzen C4<\/strong> haben wir zwei Aufgaben gel\u00f6st. Erstens haben wir die Grundlage f\u00fcr zuk\u00fcnftige, vielversprechende, aber zu diesem Zeitpunkt neue NVMe-Technologie geschaffen. Zweitens haben wir die zentrale Verarbeitungseinheit erheblich entlastet, indem wir die Verarbeitung von Anfragen an EBS auf die neue Karte verlagert haben. Es hat gut funktioniert, deshalb ist Annapurna Labs jetzt Teil von Amazon.<\/p>\n

Bis November 2017 hatten wir das Gef\u00fchl, dass es an der Zeit war, auch den Hypervisor zu \u00e4ndern.<\/p>\n

Der neue Hypervisor wurde auf der Grundlage \u00fcberarbeiteter KVM-Kernmodule entwickelt.<\/p><\/blockquote>\n

Er erm\u00f6glichte es, die Overheads der Ger\u00e4tesimulation erheblich zu reduzieren und direkt mit den neuen ASICs zu arbeiten. Die Instanzen C5<\/strong> waren die ersten virtuellen Maschinen, unter deren Haube der neue Hypervisor lief. Wir haben ihn genannt Nitro<\/strong>.<\/p>\n

\"WieDie Evolution der Instanzen auf der Zeitachse.<\/em><\/p>\n

Alle neuen Typen virtueller Maschinen, die seit November 2017 erschienen sind, funktionieren auf diesem Hypervisor. Physische Bare Metal-Instanzen haben keinen Hypervisor<\/strong>, werden aber ebenfalls Nitro genannt, da sie spezialisierte Nitro-Karten verwenden.<\/p>\n

In den folgenden zwei Jahren hat sich die Anzahl der Nitro-Instanztypen auf mehrere Dutzend erh\u00f6ht: A1, C5, M5, T3 und andere.<\/p>\n

\"Wie
\nInstanztypen.<\/em><\/p>\n

Wie moderne Nitro-Maschinen aufgebaut sind<\/h3>\n

\nSie bestehen aus drei Hauptkomponenten: dem Nitro-Hypervisor (dar\u00fcber wurde bereits gesprochen), dem Sicherheitsschip und den Nitro-Karten.<\/p>\n

Das Sicherheitsschip<\/strong> ist direkt in das Motherboard integriert. Es kontrolliert viele wichtige Funktionen, beispielsweise die Kontrolle des Bootens des Host-Betriebssystems.<\/p>\n

Die Nitro-Karten<\/strong> \u2014 es gibt vier Typen. Alle wurden von Annapurna Labs entwickelt und basieren auf gemeinsamen ASICs. Ein Teil ihrer Firmware ist ebenfalls gemeinsam.<\/p>\n

\"Wie
\nVier Typen von Nitro-Karten.<\/em><\/p>\n

Eine der Karten ist f\u00fcr die Arbeit mit dem Netzwerk<\/strong>VPC<\/strong>. Diese erscheint in virtuellen Maschinen als Netzwerkadapter ENA \u2014 Elastic Network Adaptor<\/strong>. Sie kapselt auch den Datenverkehr beim \u00dcbertragen \u00fcber das physische Netzwerk (dar\u00fcber sprechen wir im zweiten Teil des Artikels), kontrolliert die Firewall der Sicherheitsgruppen, ist verantwortlich f\u00fcr das Routing und andere Netzwerkaufgaben.<\/p>\n

Einzelne Karten arbeiten mit blockbasierter Speicherung EBS<\/strong> und mit in den Server integrierten Festplatten. Sie werden der Gast-VM als NVMe-Adapter<\/strong>pr\u00e4sentiert. Sie sind auch f\u00fcr die Verschl\u00fcsselung der Daten und die \u00dcberwachung der Festplatten verantwortlich.<\/p>\n

Das System aus Nitro-Karten, Hypervisor und Sicherheitsschip ist in einem SDN-Netzwerk oder Software Defined Network<\/strong>. Die Verwaltung dieses Netzwerks (Control Plane) obliegt der Kartenkontroller<\/strong>.<\/p>\n

Nat\u00fcrlich arbeiten wir weiterhin an der Entwicklung neuer ASICs. Beispielsweise haben wir Ende 2018 den Inferentia-Chip ver\u00f6ffentlicht, der eine effizientere Bearbeitung von Aufgaben im Bereich des maschinellen Lernens erm\u00f6glicht.<\/p>\n

\"Wie
\nInferentia Machine Learning Prozessor.<\/em><\/p>\n

Skalierbare Datenbank<\/h2>\n

\nEine traditionelle Datenbank hat eine schichtartige Struktur. Wenn man es stark vereinfacht, ergeben sich folgende Ebenen.<\/p>\n