{"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 elastischen Dienste \"zaubert\". Skalierung von Servern und Datenbanken","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Clouds sind wie eine magische Box \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 Tenant im Cloud, aber in deinem Universum bist du der alleinige Herrscher. Du kannst dir sicher sein, dass du immer die ben\u00f6tigten Ressourcen erh\u00e4ltst, ohne R\u00fccksicht auf andere, und entscheidest selbst, wie das Netzwerk aussehen soll. Wie funktioniert diese Magie, die es der Cloud erm\u00f6glicht, Ressourcen elastisch bereitzustellen und die Tenants vollst\u00e4ndig voneinander zu isolieren?<\/p>\n

\"Wie
\n
\nDie AWS-Cloud ist ein megakomplexes System, das sich seit 2006 evolution\u00e4r weiterentwickelt. Ein Teil dieser Entwicklung hat Wassili Pantjuchin<\/strong> \u2014 Architekt von Amazon Web Services. Als Architekt sieht er nicht nur das Endergebnis, sondern auch die Herausforderungen, die AWS bew\u00e4ltigen muss. Je mehr Verst\u00e4ndnis f\u00fcr das System besteht, desto h\u00f6her ist das Vertrauen. Daher wird Wladimir die Geheimnisse der AWS-Cloud-Services mit Ihnen teilen. Im Detail erfahren Sie, wie die physikalischen Server von AWS aufgebaut sind, welche elastische Skalierbarkeit die Datenbanken bieten, welche ma\u00dfgeschneiderte Amazon-Datenbanken existieren und wie die Leistung virtueller Maschinen gesteigert und gleichzeitig die Kosten gesenkt werden k\u00f6nnen. Kenntnisse \u00fcber die Architekturans\u00e4tze von Amazon helfen dabei, die AWS-Services effizienter zu nutzen und m\u00f6glicherweise neue Ideen f\u00fcr eigene L\u00f6sungen zu entwickeln.
\n<\/a><\/noindex>
\n\u00dcber den Referenten: Wladimir Pantyuchin (Hen<\/a><\/noindex>) begann als Unix-Administrator in .ru-Unternehmen, arbeitete 6 Jahre mit gro\u00dfen Ger\u00e4ten von Sun Microsystems und setzte sich 11 Jahre lang f\u00fcr die Datenzentrierung bei EMC ein. Nat\u00fcrlich entwickelte er sich zu Private Clouds weiter und wandte sich 2017 den Public Clouds zu. Heute gibt er technische Ratschl\u00e4ge, um im AWS-Cloud-Umfeld zu leben und sich weiterzuentwickeln.<\/p>\n

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

Warum spreche ich \u00fcber das Amazon-Ger\u00e4t<\/h2>\n

\nMein erstes Auto hatte eine \"Schaltung\" \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 verstehe, wie es funktioniert. Nat\u00fcrlich stellte ich mir die Funktionsweise des Getriebes ziemlich primitiv vor \u2013 etwa wie das einer Fahrradschaltung.<\/p>\n

\"Wie
\n
\nAlles war wunderbar, bis auf eines \u2013 das Stehen in Staus. Man sitzt da und macht nichts, aber wechselt st\u00e4ndig die G\u00e4nge, dr\u00fcckt die Kupplung, das Gas, die Bremse \u2013 das strengt wirklich an. Das Problem mit den Staus wurde teilweise gel\u00f6st, als wir ein Auto mit Automatikgetriebe bekamen. Am Steuer hatte ich Zeit, \u00fcber etwas nachzudenken oder ein H\u00f6rbuch zu h\u00f6ren.<\/p>\n

Ein weiteres R\u00e4tsel trat in mein Leben, denn ich verstand \u00fcberhaupt nicht mehr, wie mein Auto funktioniert. Ein modernes Fahrzeug ist ein komplexes Ger\u00e4t. Es passt sich gleichzeitig an Dutzende von verschiedenen Parametern an: Gas- und Bremsbet\u00e4tigung, Fahrstil, Stra\u00dfenqualit\u00e4t. Ich verstehe nicht mehr, wie das funktioniert.<\/p>\n

Als ich begann, mich mit Amazon Cloud zu besch\u00e4ftigen, war es auch f\u00fcr mich ein R\u00e4tsel. Doch dieses R\u00e4tsel ist von viel gr\u00f6\u00dferem Umfang, denn im Fahrzeug sitzt ein Fahrer, w\u00e4hrend es in AWS Millionen gibt. Alle Nutzer steuern gleichzeitig, beschleunigen und bremsen. Es ist faszinierend, 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 elastisch jedem Nutzer an, sodass es ihm vorkommt, als w\u00e4re er der Einzige im Universum.<\/p>\n

Die Magie verblasste ein wenig, als ich sp\u00e4ter als Architekt bei Amazon anfing. Ich sah, mit welchen Herausforderungen wir konfrontiert sind, wie wir sie l\u00f6sen und wie wir die Dienste weiterentwickeln. Mit wachsendem Verst\u00e4ndnis f\u00fcr die Funktionsweise des Systems steigt auch das Vertrauen in den Dienst. Daher m\u00f6chte ich ein Bild davon zeichnen, was sich unter der Haube der AWS-Cloud verbirgt.<\/p>\n

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

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

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

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

Datenbank-Skalierung<\/strong>. Ich werde erl\u00e4utern, wie wir unsere eigenen skalierbaren Datenbanken aufbauen.<\/p>\n

Netzwerkskalierung<\/strong>. Im letzten Teil werde ich die Struktur unseres Netzwerks aufzeigen. Es ist eine gro\u00dfartige Sache \u2013 jeder Cloud-Nutzer hat das Gef\u00fchl, dass er alleine in der Cloud ist und keine anderen Mandanten sieht.<\/p>\n

Hinweis. In diesem Artikel geht es um die Optimierung von Servern und die Skalierung von Datenbanken. Die Netzwerkskalierung werden wir im n\u00e4chsten Artikel betrachten. Wo bleiben die serverlosen Funktionen? Dazu gibt es eine separate Ausarbeitung \u201eKlein, aber oho. Unboxing der Mikro-Virtualisierung Firecracker<\/a><\/noindex>\u201c. Darin werden verschiedene Ans\u00e4tze zur Skalierung vorgestellt, und die L\u00f6sung Firecracker wird detailliert behandelt \u2013 eine Symbiose aus den besten Eigenschaften von virtuellen Maschinen und Containern.<\/i><\/p><\/blockquote>\n

<\/p>\n

Server<\/h2>\n

\nDie Cloud ist fl\u00fcchtig. Doch dieser Fl\u00fcchtigkeit liegt eine physische Grundlage zugrunde \u2013 Server. Urspr\u00fcnglich war deren Architektur klassisch. Ein Standard-x86-Chipsatz, Netzwerkkarten, Linux, ein Hypervisor Xen, auf dem virtuelle Maschinen betrieben wurden.<\/p>\n

\"Wie
\n
\nIm Jahr 2012 erf\u00fcllte eine solche Architektur ihre Aufgaben durchaus. Xen ist ein hervorragender Hypervisor, hat aber einen gravierenden Nachteil. Er hat genug hohe Overheadkosten f\u00fcr die Emulation von Ger\u00e4ten<\/strong>. Wenn neue, schnellere Netzwerkkarten oder SSDs erscheinen, werden diese Overheadkosten zu hoch. Wie k\u00f6nnen wir dieses Problem l\u00f6sen? Wir haben beschlossen, gleich an zwei Fronten zu arbeiten \u2014 sowohl die Hardware als auch den Hypervisor zu optimieren<\/strong>. Das ist eine sehr ernste Herausforderung.<\/p>\n

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

\nEs wird nicht m\u00f6glich sein, alles sofort und gut zu machen. Was \u00abgut\u00bb ist, war urspr\u00fcnglich auch unklar.<\/p>\n

Wir haben uns entschieden, einen evolution\u00e4ren Ansatz zu verfolgen \u2014 wir \u00e4ndern ein wichtiges Architekturelement und setzen es sofort in Produktion.<\/p><\/blockquote>\n

Wir sto\u00dfen auf alle m\u00f6glichen Probleme, h\u00f6ren uns Beschwerden und Vorschl\u00e4ge an. Danach \u00e4ndern wir eine andere Komponente. So ver\u00e4ndern wir die gesamte Architektur schrittweise basierend auf dem Feedback der Benutzer und der Unterst\u00fctzung.<\/p>\n

Die Transformation begann 2013 mit dem Schwierigsten \u2014 dem Netzwerk. In den C3<\/strong> Instanzen haben wir der Standardnetzwerkkarte eine spezielle Network Accelerator-Karte hinzugef\u00fcgt. Sie wurde buchst\u00e4blich mit einem kurzen Loopback-Kabel an der Vorderseite verbunden. Unsichtbar in der Cloud, aber das direkte Zusammenspiel mit der Hardware hat das Jitter und die Netzwerkkapazit\u00e4t erheblich verbessert.<\/p>\n

Wir haben uns dann entschieden, den Zugriff auf EBS \u2014 Elastic Block Storage zu verbessern. Dies ist eine Kombination aus Netzwerk und Speicher. Die Schwierigkeit bestand darin, dass es zwar Netzwerkbeschleunigerkarten auf dem Markt gab, jedoch keine M\u00f6glichkeit bestand, Hardware f\u00fcr Speicherbeschleuniger zu erwerben. Daher wandten wir uns an ein Startup, Annapurna Labs<\/strong>, das f\u00fcr uns spezielle ASIC-Chips entwickelt hat. Diese erm\u00f6glichten es, entfernte EBS-Volumes wie NVMe-Ger\u00e4te anzuschlie\u00dfen.<\/p>\n

In den Instanzen C4<\/strong> haben wir zwei Ziele erreicht. Erstens haben wir eine Basis f\u00fcr die vielversprechende, damals jedoch noch neue NVMe-Technologie geschaffen. Zweitens haben wir die zentrale Verarbeitungseinheit entlastet, indem wir die Verarbeitung der Anfragen an EBS auf die neue Karte verlagert haben. Es war ein voller Erfolg, weshalb Annapurna Labs jetzt Teil von Amazon ist.<\/p>\n

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

Den neuen Hypervisor haben wir auf der Grundlage verbesserter KVM-Kernmodule entwickelt.<\/p><\/blockquote>\n

Er erm\u00f6glichte eine signifikante Reduzierung des Overheads bei der Emulation von Ger\u00e4ten und direkte Interaktion mit den neuen ASICs. Die Instanzen C5<\/strong> waren die ersten virtuellen Maschinen, die den neuen Hypervisor unter der Haube hatten. Wir haben ihn Nitro<\/strong>.<\/p>\n

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

Alle neuen Typen von virtuellen Maschinen, die seit November 2017 eingef\u00fchrt wurden, laufen auf diesem Hypervisor. Bare Metal Instanzen haben keinen Hypervisor,<\/strong>werden jedoch ebenfalls als Nitro bezeichnet, da sie spezialisierte Nitro-Karten nutzen.<\/p>\n

In den folgenden zwei Jahren hat die Anzahl der Nitro-Instanztypen mehrere Dutzend \u00fcberschritten: 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 (der bereits erw\u00e4hnt wurde), einem Sicherheitsschip und den Nitro-Karten.<\/p>\n

Das Sicherheitsschip<\/strong> ist direkt auf dem Motherboard integriert. Es \u00fcberwacht viele wichtige Funktionen, wie die Kontrolle \u00fcber das Booten des Host-OS.<\/p>\n

Nitro-Karten<\/strong> \u2013 es gibt vier Typen davon. 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 wird in den virtuellen Maschinen als Netzwerkkarte angezeigt ENA \u2013 Elastic Network Adaptor<\/strong>. Sie kapselt auch den Datenverkehr, wenn er \u00fcber das physische Netzwerk \u00fcbertragen wird (dar\u00fcber sprechen wir im zweiten Teil des Artikels), \u00fcberwacht die Firewall-Sicherheitsgruppen, ist f\u00fcr das Routing zust\u00e4ndig und k\u00fcmmert sich um weitere Netzwerkfragen.<\/p>\n

Einzelne Karten arbeiten mit Blockspeicher EBS<\/strong> und Festplatten, die in den Server integriert sind. In der virtuellen Umgebung erscheinen sie als NVMe-Adapter<\/strong>. Sie sind auch f\u00fcr die Verschl\u00fcsselung von Daten und die \u00dcberwachung der Festplatten verantwortlich.<\/p>\n

Das Nitro-Kartensystem, der Hypervisor und der Sicherheitschip sind in ein SDN oder Software Defined Network<\/strong>verbunden. Die Verwaltung dieses Netzwerks (Control Plane) erfolgt durch eine Controller-Karte<\/strong>.<\/p>\n

Nat\u00fcrlich arbeiten wir weiterhin an der Entwicklung neuer ASICs. Zum Beispiel haben wir Ende 2018 den Inferentia-Chip ver\u00f6ffentlicht, der die Verarbeitung von Aufgaben im Bereich maschinelles Lernen effizienter gestaltet.<\/p>\n

\"Wie
\nInferentia Machine Learning Processor-Chip.<\/em><\/p>\n

Skalierbare Datenbank<\/h2>\n

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