Kontinuierliche Neuerfindung: Eine kurze Geschichte von AWS Block Storage
(allthingsdistributed.com)- AWS EBS begann als netzwerkgebundener Block Storage für EC2 und entwickelte sich von einem Dienst auf Basis gemeinsam genutzter HDDs zu einer verteilten SSD-Flotte, die mehr als 140 Billionen Operationen pro Tag verarbeitet
- Die anfänglichen Performance-Grenzen ergaben sich nicht nur aus 120–150 IOPS und durchschnittlich 6–8 ms Latenz von HDDs, sondern auch aus dem Noisy-Neighbor-Problem, das entstand, weil mehrere Kunden-Workloads dieselben Festplatten gemeinsam nutzten
- Mit der Einführung von SSDs boten Provisioned-IOPS-Volumes 2012 bis zu 1.000 IOPS und im Mittel etwa 2–3 ms Latenz, doch die Engpässe verlagerten sich auf Netzwerk, Hypervisor und Software-Queues
- Das EBS-Team instrumentierte den gesamten IO-Pfad und verbesserte Schicht für Schicht Xen-Queues, Nitro-Offloading, hardwaregestützte Verschlüsselung, TCP-Tuning bis hin zum SRD-Transportprotokoll
- Die Performance-Steigerungen erfolgten weniger durch große Neuschreibungen als durch unterbrechungsfreie Migrationen, unabhängige Änderungen kleiner Teams, kontinuierliche Messung und zurückrollbare inkrementelle Verbesserungen
Vom Block Storage für EC2 zur großen SSD-Flotte
- EBS startete am 20. August 2008, etwa zwei Jahre nach dem Start der EC2-Beta, mit der Idee, netzwerkgebundenen Block Storage für EC2-Instanzen bereitzustellen
- Damals gab es im Team ein oder zwei Storage-Experten und einige Distributed-Systems-Engineers, die den Dienst auf Basis ihres Wissens über Computersysteme und Netzwerke aufbauten
- Seitdem hat sich EBS von einem gemeinsam genutzten HDD-Produkt zu einem Dienst entwickelt, der einer einzelnen EC2-Instanz Hunderttausende IOPS bereitstellen kann
- Die heute einer einzelnen Instanz bereitstellbaren IOPS übersteigen das Niveau, das in der frühen HDD-basierten Zeit für eine gesamte Availability Zone bereitgestellt wurde
- Insgesamt verarbeitet EBS in einer verteilten SSD-Flotte pro Tag mehr als 140 Billionen Operationen
- Die wichtigste Workload ist die Systemplatte von EC2-Instanzen; funktional ähnelt das der Bereitstellung der Festplatte in einem physischen Server als Network Storage
- Kunden legen großen Wert auf Haltbarkeit, betrachten aber Performance und Verfügbarkeit, die direkt mit der EC2-Erfahrung verbunden sind, als ebenso wichtig
- io2 Block Express Volumes und Volume-Snapshots werden als grundlegende Bausteine bereitgestellt, um hohe Haltbarkeit zu erreichen
- Performance und Verfügbarkeit von EBS-Volumes schlagen sich nahezu direkt in der Erfahrung von EC2-basierten Anwendungen nieder
Frühe Grenzen durch Queuing und HDDs
- In Computersystemen werden Storage-Anfragen über mehrere Queues zwischen CPU, Bus und Gerät verarbeitet
- Bei Network Storage entstehen mehrere Queues zwischen Betriebssystem-Kernel, Storage-Adapter, Storage-Fabric, Ziel-Storage-Adapter und Speichermedium
- Als EBS 2008 erstmals entwickelt wurde, war der Storage-Markt vor allem von HDDs geprägt, und die Latenz wurde vom Speichermedium selbst dominiert
- Festplatten sind mechanische Geräte und unterliegen daher physikalischen Grenzen
- Über Jahrzehnte hinweg blieb die HDD-Performance grob bei 120–150 Operationen pro Sekunde und einer durchschnittlichen IO-Latenz von 6–8 ms
- Durch Queuing und interne Befehlsumordnung im Laufwerk konnte die Tail-Latenz bis auf Hunderte Millisekunden ansteigen
- Da die Ende-zu-Ende-Latenz von EBS damals im Bereich von Dutzenden Millisekunden lag, machten die im Netzwerk hinzukommenden Dutzenden Mikrosekunden nur einen kleinen Anteil an der Gesamtlatenz aus
- Die HDD-Performance wurde stark von anderen in der Queue wartenden Operationen beeinflusst
- Kleine, zufällige Anfragen, die über das Medium verteilt sind, benötigen zum Suchen und Zugreifen länger als mehrere große, nahe beieinanderliegende Anfragen
- Verteilte man Kunden auf mehrere Festplatten, reduzierte das zwar Latenzen oberhalb der Peaks der heißesten Workloads, verteilte aber unregelmäßiges Verhalten auf mehr Kunden
- Dass eine Workload eine andere beeinflusst, wurde als Noisy Neighbor zu einem wichtigen Geschäftsproblem
- AWS sah starke Performance-Isolation als notwendig an, um die Qualität der Kundenerfahrung zu erhöhen
- Änderungen an Disk-Scheduling-Algorithmen und die Verteilung von Workloads auf mehr Spindles brachten nur kleine inkrementelle Verbesserungen
Die nach der SSD-Einführung sichtbar gewordene Bedeutung von Instrumentierung
- Um 2011 wurden SSDs verbreiteter und in Kapazitäten verfügbar, die AWS prüfen konnte
- SSDs haben keine physische Armbewegung zum Auffinden von Daten, zufällige Anfragen sind nahezu so schnell wie sequenzielle Anfragen, und zwischen Controller und NAND-Chips gibt es mehrere Kanäle
- EBS entwickelte zunächst einen neuen SSD-basierten Storage-Server-Typ und einen neuen Volume-Typ namens Provisioned IOPS
- Die Einführung des neuen Volume-Typs war keine kleine Aufgabe, und die Workloads, die ihn nutzen konnten, waren begrenzt
- Entgegen der Erwartung, dass der Austausch von HDDs durch SSDs fast alle Probleme lösen würde, verschwand das Noisy-Neighbor-Problem nicht automatisch
- Provisioned IOPS, im August 2012 gestartet, bot bis zu 1.000 IOPS
- Das war zehnmal so viel wie bei den bisherigen EBS-Standard-Volumes
- Die durchschnittliche Latenz lag bei etwa 2–3 ms, eine Verbesserung um den Faktor 5 bis 10
- Auch die Kontrolle von Ausreißern verbesserte sich deutlich
- Zu diesem Zeitpunkt verfügte EBS nur über grundlegende Telemetrie; um zu entscheiden, was behoben werden sollte, war feinere Instrumentierung erforderlich
- Das Team baute eine Methode auf, jeden IO an mehreren Punkten zu verfolgen
- EBS-Client-Initiator
- Netzwerk-Stack
- Storage-Durability-Engine
- Betriebssystem
- Zusätzlich zum Monitoring von Kunden-Workloads wurden Canary-Tests erstellt, die bei bekannten Workloads kontinuierlich positive und negative Auswirkungen von Änderungen überprüften
Verbesserungen durch gemeinsame Aufteilung von Hardware und Software
- Die neue Telemetrie zeigte klar die ersten Investitionsbereiche
- Die Zahl der Queues im Gesamtsystem musste reduziert werden
- Es gab Potenzial, die Komplexität des IO-Pfads im bei EC2 verwendeten Xen-Hypervisor zu senken
- Optimierungen der Netzwerksoftware waren nötig
- Die zentrale Durability-Engine benötigte On-Disk-Datenplatzierung, Cache-Line-Optimierungen und die Unterstützung eines asynchronen Programmiermodells
- Performance-Probleme in AWS-Systemen verlaufen häufig gleichzeitig über mehrere Schichten des Hardware- und Software-Stacks hinweg
- EBS ließ das Storage-Server-Team und das Client-Team parallel arbeiten; auch EC2-Hypervisor-Engineers und die interne Netzwerk-Performance-Gruppe von AWS waren beteiligt
- Auch die Entwicklungsorganisation wurde wie ein Softwaresystem nach dem Prinzip Divide and Conquer aufgeteilt
- Das monolithische Storage-Server-Entwicklungsteam wurde in kleine Teams für Bereiche wie Datenreplikation, Durability und Snapshot-Hydration umorganisiert
- Jedes Team konnte auf Basis strenger Tests unabhängig iterieren und Änderungen einbringen
- Der 2013 erstellte Blueprint entspricht zwar nicht exakt dem heutigen EBS, gab aber die Richtung vor
- Damals war nicht absehbar, dass Amazon eines Tages eigene SSDs entwickeln und einen auf die Anforderungen von EBS zugeschnittenen Technologie-Stack besitzen würde
Beseitigung von Engpässen von Xen über Nitro bis SRD
- Bis Ende 2017 liefen alle EC2-Instanzen auf dem Xen-Hypervisor
- Im Xen-Gerätepfad gab es eine Ring-Queue, über die Guest-Domain und die privilegierte Driver-Domain dom0 Informationen austauschten; der EBS-Client lief als Kernel-Blockgerät in dom0
- Bis eine IO-Anfrage von der Instanz den EC2-Host verließ, durchlief sie mehrere Queues
- Instanz-Blockgeräte-Queue
- Xen-Ring
- dom0-Kernel-Blockgeräte-Queue
- EBS-Client-Netzwerk-Queue
- Das EBS-Team schrieb mehrere Loopback-Geräte, um den Einfluss jeder Queue zu isolieren
- Selbst bei nahezu keiner Latenz im dom0-Gerätetreiber zeigte sich: Wenn mehrere Instanzen gleichzeitig IO erzeugten, verlangsamte sich der effektive Durchsatz des Gesamtsystems
- EC2 wurde mit den Standardwerten von Xen für die Zahl der Blockgeräte-Queues und Queue-Einträge gestartet
- Diese Standardwerte orientierten sich an der begrenzten Storage-Hardware früherer Xen-Entwicklungsumgebungen
- Die Zahl ausstehender IO-Anfragen war für den gesamten Host auf 64 begrenzt, nicht pro Gerät
- 2013 war die Entwicklung der ersten Nitro-Offload-Karte nur für Networking im Gange
- Die Verarbeitung des VPC Software-Defined Network wurde vom Xen-dom0-Kernel in eine dedizierte Hardware-Pipeline verlagert
- Durch die Trennung der Paketverarbeitungs-Data-Plane vom Hypervisor mussten keine CPU-Zyklen von Kundeninstanzen mehr für die Verarbeitung von Netzwerkverkehr aufgewendet werden
- Derselbe Ansatz wurde auch auf EBS-Storage angewendet
- Mehr Verarbeitung wurde in Hardware verlagert, um die Betriebssystem-Queues im Hypervisor zu reduzieren
- Interrupt-basierte Arbeit wurde ausgelagert, wodurch der Hypervisor weniger Zeit für die Verarbeitung von Anfragen aufwendete
- Die zweite Nitro-Karte verfügte zudem über Hardwarefunktionen, mit denen EBS-verschlüsselte Volumes ohne Performance-Einbußen verarbeitet werden konnten
- Schlüsselmaterial für die Verschlüsselung wurde vom Hypervisor getrennt, um Kundendaten zusätzlich zu schützen
- Nachdem EBS auf Nitro verlagert worden war, wanderte der Engpass ins Netzwerk selbst
- Aktuelle TCP-Tuning-Parameter und Congestion-Control-Algorithmen für Rechenzentren wurden überprüft
- In einigen Fällen reduzierte das Hinzufügen kleiner zufälliger Verzögerungen zu Storage-Server-Anfragen durch einen Netzwerk-Smoothing-Effekt die durchschnittliche Latenz und Ausreißer
- Solche Tunings hielten mit weiter steigender System-Performance und -Skalierung nicht dauerhaft, sodass Messungen und Monitoring zur Vermeidung von Regressionen weiterhin nötig waren
- 2014 begannen Arbeiten auf Basis von Scalable Reliable Datagram (SRD) mit dem Ziel eines besseren Ansatzes als TCP
- Das zugehörige Paper ist A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC
- Zu den Anforderungen gehörten verbesserte Wiederherstellung nach Ausfällen und Umgehungsfähigkeit sowie einfacheres Hardware-Offloading
- Für das SRD-Design waren zwei Beobachtungen wichtig
- Man konnte sich auf das Design des AWS-Rechenzentrumsnetzwerks konzentrieren, nicht auf das allgemeine Internet
- Im Storage können in-flight IO-Anfragen in ihrer Ausführungsreihenfolge neu geordnet werden
- So ließen sich die Kosten der strikten In-Order-Delivery von TCP vermeiden; verschiedene Anfragen konnten über mehrere Netzwerkpfade gesendet und bei Ankunft ausgeführt werden
- SRD wird nicht nur für Storage, sondern auch für Networking genutzt
- Bei Elastic Network Adapter (ENA) Express verbessert SRD die Performance des TCP-Stacks im Guest
- Durch die Nutzung mehrerer Netzwerkpfade sowie die Reduzierung von Overflows und Queues in zwischengeschalteten Netzwerkgeräten lässt sich eine höhere Netzwerkauslastung erreichen
SSD-Cache und unterbrechungsfreie Migration
- EBS wollte sich nicht damit zufriedengeben, dass nur einige Volumes und Kunden bessere Performance erhielten, sondern die Vorteile von SSDs breiter verfügbar machen
- Damals liefen Millionen von Kunden-Volumes ohne Provisioned IOPS auf Tausenden von Storage-Servern
- Einige dieser Volumes existieren heute noch
- Sämtliche Hardware wegzuwerfen und zu ersetzen, wäre teuer gewesen
- Im Server-Chassis gab es freien Platz, doch die einzige Stelle, die den Kühlluftstrom nicht störte, lag zwischen Motherboard und Lüftern
- SSDs waren klein und leicht, durften im Chassis aber nicht verrutschen; mit Hilfe von Materialwissenschaftlern und nach Versuch und Irrtum fand man hitzebeständiges industrielles Klettband
- Über mehrere Monate im Jahr 2013 setzte EBS manuell in jeden von Tausenden Servern eine SSD ein
- In der Software wurde eine kleine Änderung ergänzt: Neue Schreibvorgänge wurden auf der SSD gestaged und der Anwendung als abgeschlossen zurückgemeldet, bevor sie asynchron auf die langsamere HDD geflusht wurden
- Diese Arbeiten erfolgten ohne Unterbrechung für Kunden
- EBS war von Anfang an für unterbrechungsfreie Wartungsereignisse ausgelegt
- EBS-Volumes konnten auf neue Storage-Server retargetet werden, während leere Server aktualisiert oder neu aufgebaut wurden
- Die Fähigkeit, Kunden-Volumes auf neue Storage-Server zu verschieben, erwies sich später mehrfach als nützlich
- Sie wurde bei der Einführung effizienterer Datenstrukturen für das On-Disk-Format genutzt
- Sie wurde auch verwendet, um alte Hardware durch neue Hardware zu ersetzen
- Einige Volumes, die in den ersten Monaten nach dem EBS-Launch 2008 erstellt wurden, sind noch aktiv
- Solche Volumes sind wahrscheinlich über Hunderte verschiedene Server und mehrere Hardwaregenerationen gewandert
- Flotten-Updates und Neubauten erfolgten ohne Auswirkungen auf diese Workloads
Führungsansatz passend zur Performance-Skalierung
- Die Größenordnung von EBS unterschied sich nicht nur technisch, sondern auch organisatorisch von Umgebungen kleinerer Unternehmen oder Startups
- Wenn Systemexperten an jeder Eskalation, jedem Commit-Review und jeder Designänderungsprüfung beteiligt sind, können sie zum Performance-Engpass der Organisation werden
- Um das zu lösen, wurde nicht nur im Code, sondern auch in der Zusammenarbeit experimentiert
- Als repräsentatives Werkzeug wurde Peer Debugging eingesetzt
- Mehrere Engineers verfolgten gemeinsam Code und Terminal, um Probleme zu analysieren
- Dabei wurde ein Fall gefunden, in dem Ort und Art des Lockings bei Updates einer critical data structure problematisch waren
- Normalerweise zeigte sich das Problem nicht, doch gelegentlich wurden Anfrageantworten langsam; durch die Korrektur wurde eine Ursache von Jitter beseitigt
- Engineers die Befugnis zu geben, sicher zu experimentieren, Hindernisse zu reduzieren und zugleich Guardrails beizubehalten, konnte zu besseren Ergebnissen führen
Kontinuierliche Verbesserung statt großer Neuschreibung
- Die Verbesserungen von EBS erfolgten nicht als eine riesige Änderung, sondern als Reihe inkrementeller Verbesserungen über die Zeit
- Dieser Ansatz lieferte Kundennutzen schneller und ermöglichte es, auf Basis des Gelernten bei veränderten Kunden-Workloads die Richtung anzupassen
- Die EBS-Latenzerfahrung verbesserte sich von durchschnittlich über 10 ms pro IO-Operation auf konsistente Sub-Millisekunden-IOs bei den leistungsstärksten io2 Block Express Volumes
- Diese Veränderung gelang, ohne den Dienst offline zu nehmen, um eine neue Architektur bereitzustellen
- Kunden wollen weiterhin mehr Performance, und diese Nachfrage ist die treibende Kraft hinter der fortlaufenden Innovation und Iteration von EBS
1 Kommentare
Hacker-News-Kommentare
Es freut mich wirklich, diesen Artikel hier zu sehen. Wer sich auch nur ein wenig für großskalige Systeme interessiert, sollte ihn unbedingt lesen.
Bei sequenziellen Workloads können moderne Magnetfestplatten beim Lesen/Schreiben über 100 MB/s erreichen, bei vollständig zufälligen 4-kB-Workloads kann das jedoch auf 400 kB/s fallen. Queuing und Scheduling verhindern zwar das Schlimmste, aber die reale Performance kann je nach Workload um mehr als den Faktor 100 schwanken, was für ein mandantenfähiges System extrem schwer zu handhaben ist. Gerade beim Lesen gibt es keinen Ausweg wie „einfach woanders hinschreiben“.
Das Wichtigste, was ich von Marc gelernt habe: Um zu wissen, was kaputt ist, muss man zuerst richtig hinschauen. Er erstellte Visualisierungen der Latenz, etwa Histogramm-Zeitreihen wie im Artikel, und erzählte damit eine Geschichte, die dem Team eine völlig andere Sicht darauf gab, was zu tun war. Jeder Peak im Histogramm hatte seine eigene Ursache und eigene Optimierungsarbeit; wer in Performance-Daten nicht auf mehrere Arten tief hineinschaut, sieht Effizienzgewinne und Chancen nicht, die sich sonst auftun würden.
Das Retrofit-Projekt von 2013, bei dem Tausende Server jeweils mit einer SSD ausgestattet wurden, ist eines meiner liebsten Beispiele aus der AWS-Geschichte. Möglich war das, weil EBS von Anfang an auf unterbrechungsfreie Wartungsereignisse ausgelegt war: Volumes konnten neuen Storage-Servern zugewiesen und leere Server aktualisiert oder neu aufgebaut werden. Es ist ein gutes Beispiel dafür, dass verteilte Systeme nicht nur zum Skalieren da sind, sondern auch dafür, Serverausfälle selbstverständlich zu verkraften und Daten ohne Verlust verschieben zu können – und so Betrieb in großem Maßstab überhaupt möglich zu machen.
Dick Lyon von Google verfolgte bei Google-Storage-Servern denselben Ansatz und identifizierte ab Folie 62 von https://www.pdl.cmu.edu/SDI/2015/slides/DatacenterComputers.... mehrere Queues und Ressourcenkonkurrenz als zentrale Bottlenecks im Block Storage.
Das weckt alte Erinnerungen. Reddit war 2008 einer der frühen EBS-Nutzer, und wir hielten uns für clever, als wir herausfanden, dass man mit Software-RAID über fünf EBS-Volumes die IOPS steigern konnte.
Damals schwankte die Performance der einzelnen Volumes stark, also starteten wir sieben oder acht davon, ließen Lese-/Schreiblast darüber laufen und wählten die fünf mit der besten Performance aus, um sie per Linux-Software-RAID zu bündeln. Wenn es gut lief, brachte das den gewünschten Effekt und lieferte manchmal mehr als das Fünffache der IOPS eines einzelnen Nodes; wenn es schlecht lief, war es wirklich grauenhaft.
Uns war nicht klar, dass bei Software-RAID ein langsamer Node das gesamte RAID auf die Geschwindigkeit des langsamsten Volumes herunterzieht, und dadurch sah es so aus, als würde die Datenbank kaputtgehen. Es dauerte eine Weile, bis wir herausfanden, dass RAID die Ursache war, und es war auch schwierig, einen schlechten Node zu entfernen. Denn das Software-RAID wollte ihn nicht freigeben, bevor es die Schreibvorgänge auf dieses langsame Volume abgeschlossen hatte.
Wir mussten ein neues EBS-Volume hinzufügen und das Array neu aufbauen, was ebenfalls schlecht lief, weil es wiederum von den IOPS des neuen Volumes begrenzt wurde. Danach nutzten wir dieses Software-RAID nicht mehr, und bei Netflix verwendeten wir EBS fast gar nicht. Ich erzählte jedem, der es hören wollte, von den Fehlern, die wir bei Reddit gemacht hatten, und Netflix hatte schon vor meinem Einstieg standardmäßig auf ausschließlich lokale Disks gesetzt.
Als amüsante Randnotiz: Während des großen EBS-Ausfalls bei AWS arbeitete ich bei Reddit und schaute Netflix, während ich darauf wartete, dass EBS zurückkam, um die Datenbank zu reparieren. Beim Netflix-Interview fragte ich: „Wie habt ihr während des EBS-Ausfalls überlebt?“ Die Antwort war: „Ach, wir nutzen einfach kein EBS.“
Ich habe den Artikel gern gelesen.
Interessant ist, dass AWS in dem Zeitraum, den der Artikel behandelt, wegen EBS meines Wissens einen etwa viertägigen Ausfall hatte, von dem EC2, EBS und RDS betroffen waren. Dieser Ausfall erschütterte das Vertrauen in AWS erheblich.
In der Folge gab es eine Umorganisation, und EBS wurde als eigenständiger Service deutlich stärker ausgebaut. Diese Zeit fiel auch damit zusammen, dass Apple Kunde wurde, und mit der starken Verbreitung bei Startups wie Netflix, Zynga und Dropbox wuchs AWS insgesamt rasant.
Solche technischen und operativen Geschichten sind spannend, aber technische Innovation in der Produktion ist chaotisch und findet vor dem Hintergrund realer geschäftlicher Anforderungen statt. Von solchen Geschichten würde ich gern mehr hören.
Aber das Rad drehte sich weiter, und es ging wieder zurück zur Feature-Entwicklung. Ich werde dieses Jahr immer als das Jahr mit den wenigsten Eskalationen während meiner Zeit dort in Erinnerung behalten.
Mich interessiert die Stelle: „Das Hinzufügen kleiner zufälliger Verzögerungen zu Anfragen an Storage-Server reduzierte durch die Glättung des Netzwerks tatsächlich die durchschnittliche Latenz und die Ausreißer.“ Kann jemand erklären, warum das so ist?
Falls es interessiert: Es gibt einen Vortrag [0] von 2009 über die interne Architektur von Amazon S3. Er wurde auf Grundlage interner Unterlagen des S3-Teams erstellt, und vieles davon beeinflusste auch die Art, wie EBS entwickelt wurde.
[0]: https://vimeo.com/7330740
Mir gefiel die Stelle, dass 2013 bei allen EBS-Geräten manuell SSDs nachgerüstet wurden. Auf dem Foto sieht es ziemlich nach einer Samsung-SATA-SSD aus
https://www.allthingsdistributed.com/images/mo-manual-ssd.pn...
Meine Erinnerung kann mich täuschen, aber ich glaube, wir hatten schon deutlich früher SSDs in Dell-Blades im Einsatz. Um 2010–2012 herum war I/O-Performance wirklich ein großes Thema, und es war die Zeit des Übergangs von rotierenden Festplatten zu Flash-Speicher
Ich erinnere mich noch an Experimente mit rohen Flash-basierten Geräten, ganz ohne Fehlerbehandlung oder Wear Leveling. Das war verrückt, aber alle waren verzweifelt auf die enormen I/O-Performance-Gewinne aus, die der Wechsel von rotierenden Platten zu Silizium brachte
Die Laufwerke wurden so schnell schneller, dass das erste SKU nach sechs Monaten schon veraltet war. Ich war froh, dass ich dem Asset-Team nicht persönlich erklären musste, warum wir diese Racks Jahre früher als geplant ausmusterten. Es war deutlich wertvoller, neue, dichtere und schnellere Modelle in die Rack-Positionen zu setzen
Das erinnert mich an die Zeit, als wir Storage-Infrastruktur as a Service bauten, bevor es brauchbare Open-Source-Lösungen gab. Weg von Sun SAN, Fibre Channel und Solaris, hin zu GlusterFS auf Supermicro-Storage-Servern mit Linux und NFS; bevor ich 2007 ging, waren wir fast bei 2 PB
Und ich denke auch an die Zeit, als es schlicht sinnvoll war, im laufenden Serverbetrieb heimlich mdraid zu zerlegen und neu aufzubauen, indem man SSDs statt rotierender Festplatten einsetzte. SATA unterstützte Hot-Swapping von Laufwerken schließlich bis zu einem gewissen Grad. Der Wechsel von rotierenden Platten zu SSDs erhöhte die IOPS des wichtigsten Systems der Plattform um das 14-Fache
Früh in meiner Laufbahn arbeitete ich bei einem Internetunternehmen, das nicht nach Mitarbeiterzahl, sondern nach technischer und operativer Größenordnung groß war, und war dort für Systeme in der Breite zuständig. Die Zahl der Lektionen, die ich in kurzer Zeit lernte, war absurd hoch. Nachdem ich das Unternehmen verlassen hatte, wurde mir klar, dass die meisten Menschen im Laufe ihrer Karriere kaum je mit solchen Problemen konfrontiert werden und diese Lektionen daher auch nicht lernen
Deshalb denke ich, dass es ein professionelles Qualifikationssystem geben sollte. Wenn man eine Ausbildung unter erfahrenen Engineers verlangt, kann man in kurzer Zeit sehr wertvolles Wissen und Fähigkeiten erwerben, die sich nur durch Erfahrung lernen lassen, und danach deutlich effektiver arbeiten. Auch aus Sicht von Interviewern wären Erfahrungsnachweise und Empfehlungen von Mentoren äußerst wertvoll
Dieser Satz gefiel mir
„Auch das weithin gepriesene Ideal des Full-Stack-Engineers hat seinen Wert, aber in tiefen, komplexen Systemen ist es oft wertvoller, eine Gruppe von Spezialisten aufzubauen, die über den gesamten Stack und ihre jeweiligen tiefen Fachgebiete hinweg zusammenarbeiten und kreativ arbeiten können“
Das erste Diagramm im Artikel ist ungenau oder ziemlich veraltet. In modernen Computern sind die meisten PCIe-Lanes nicht mehr wie früher über einen separaten PCH angebunden, sondern direkt mit dem I/O-Hub oder dem Uncore-Bereich der CPU verbunden
Das ist eine wichtige Weiterentwicklung sowohl für den I/O-Durchsatz als auch für die Latenz. Abgesehen davon ist es ein hervorragender Artikel, der gut zeigt, dass am Ende überall Queues sind
Ich werde in der Bildunterschrift klarstellen, dass es sich um die Architektur jener Zeit handelt