© Ken Pilon / 123RF.com

Klassische Festplatten liefern zwar immer mehr Kapazität, jedoch kaum mehr Geschwindigkeit. Flash-Speicher bietetn dem Admin mehr Speed. Doch nicht jedes Gerät passt für jeden Einsatzzweck.

Ein Besucher aus der Vergangenheit würde sich wohl nur ungläubig die Augen reiben, sähe er, welche Storage-Möglichkeiten sich dem Admin heute eröffnen. Galt früher ein RAID 10 bereits als wieselflink, hat ein solcher Plattenverbund schon gegen ein ein einziges modernes NVMe-Laufwerk nicht mehr den Hauch einer Chance. Selbst das Standardargument gegen Flash-Speicher verliert zunehmend an Relevanz: Längst rufen die Hersteller auch für größere Laufwerke nicht mehr den Gegenwert gebrauchter Kleinwagen auf.

Noch allerdings kosten Flash-Speicher mehr als vergleichbare Festplatten, und aus Sicht des Admins gilt zudem, dass unterschiedliche Arten von Flash-Speicher sich für verschiedene Einsatzzwecke verschieden gut eignen. Und oft ist Flash eigentlich nicht notwendig. Dieser Artikel geht auf die grundlegende Frage ein, wo man idealerweise Festplatten durch Flash-Medien ersetzt, und erläutert anhand verschiedener Alltagsbeispiele, wann welche Speicherlösung aus Sicht des Admins Sinn ergibt.

Gretchenfrage

Grundsätzlich ist die Frage, ob Platten (Abbildung 1) oder Flash zum Einsatz kommen sollen, freilich so alt wie Flash-Speicher selbst. Der Preisverfall bei SSDs (Abbildung 2) und NVMes erscheint ja aus heutiger Sicht durchaus bemerkenswert. Noch vor wenigen Jahren war Flash-Speicher in Rechenzentren vorrangig in Form von Pufferspeichern bei Controllern zu finden, kaum als Ersatz für Massenspeicher. Das hat sich mittlerweile geändert, denn Flash-Speicher wird preislich zunehmend attraktiver.

Abbildung 1: Festplatten dienen bis heute als das Rückgrat der meisten Storage-Systeme im RZ, weil Flash-Speicher teurer ist. Das soll sich ab 2025 aber ändern. Quelle: Seagate

Abbildung 2: SSDs waren die ersten allgemein verfügbaren Flash-Laufwerke für Server und stellten im Vergleich zu Festplatten technischen einen enormen Fortschritt dar. Quelle: Samsung

Die Industrie sagt für das Jahr 2025 den magischen Break Even an [1], also den Punkt, an dem ein Terabyte auf einem SSD- oder NVMe-Laufwerk genauso viel kostet wie auf einer Festplatte. Hier greift Wright’s Law, das sich mit Abstrichen auf Computerhardware anwenden lässt. Der US-Ingenieur Theodore Wright stellte schon 1936 fest, dass die Herstellungskosten für ein Flugzeug bei jeder Verdoppelung der Produktion um rund 20 Prozent sanken. Je höher die Nachfrage nach einem Gut, desto billiger kommt also dessen Massenproduktion. Auch der Umkehrschluss trifft zu: Je seltener ein Gut produziert wird, desto teurer ist seine Herstellung.

Die Kombination aus beiden Faktoren soll laut Marktforschern das Blatt 2025 zugunsten von Flash-Speicher wenden: Der wird dann so stark gefragt sein, dass sein Preis stetig sinkt, während die geringere Nachfrage bei großen Platten eher deren Verteuerung bewirkt. Freilich spielen bei Flash auch andere Faktoren eine Rolle, wie etwa die Verfügbarkeit von Rohstoffen oder Chips, doch in Summe wirkt das skizzierte Szenario durchaus plausibel.

Drum prüfe …

Allerdings müssen Admins auch schon vor 2025 ihre Daten irgendwo speichern und sehen sich dabei regelmäßig mit der Frage “Platte oder Flash” konfrontiert. Und damit nicht genug: Es gibt ja längst nicht mehr den Flash-Speicher in Form von SSDs. Neue Techniken wie NVMe bahnen sich den Weg in das RZ der Gegenwart, und längst nicht jedes Gerät eignet sich für jeden Einsatzzweck.

Andererseits ergibt auch längst nicht jede Kombination aus Flash und Software Sinn. Wer etwa eine skalierende Umgebung mit Ceph oder einem Objektspeicher für den S3-Betrieb braucht, der profitiert nur in einzelnen Teilen des Setups wirklich von schnellen Platten. Nach heutigem Sachstand würde der Admin hier also viel Geld in die Hand nehmen, ohne dass es sich wirklich auszahlt.

Geht es also darum, ein Storage-Profil für das eigene Rechenzentrum oder auch nur das eigene Setup zu bauen, steht die Erhebung des Storage-Bedarfs an erster Stelle. Nur ein kluge Auswahl verhindert ein technisches Desaster und den finanziellen Schuss in den Ofen. Die Komplexität moderner Setups bringt es allerdings mit sich, dass die Bedarfsermittlung gar nicht so leicht fällt: In zentralen Setups stehen heute diverse Dienste zur Verfügung, die jeweils ihre eigenen Anforderungen an Massenspeicher stellen. Es hilft, die üblichen Dienste genauer zu betrachten.

Gut für Flash

Die erste Stelle im Rechenzentrum, an der dem Admin das Thema Storage begegnet, ist üblicherweise das Laufwerk mit der Systempartition seiner Server. In den meisten Fällen liegt hier heute tatsächlich nur die Systeminstallation, die sich in gut gewarteten Setups notfalls auch aus der Dose automatisch wiederherstellen lässt. Theoretisch wäre eine langsame Festplatte also völlig ausreichend – und sehr günstig. Obendrein müsste der Admin sich in diesem Szenario nicht vor ausufernden Logs fürchten, die die Root-Partition zumüllen und so das System in die Knie zwingen.

Praktisch hat sich hier allerdings längst Flash etabliert. Einerseits genügen ein paar Hundert Gigabyte für die Systempartition heute völlig, insbesondere dann, wenn man die Logdateien in ein zentrales Logging sichert. Andererseits sind kleine Flash-Laufwerke für die Systempartition bei den Herstellern längst Standard. Oft genug verbauen die Hersteller sie ab Werk außerdem intern, sodass kein Schacht für ein Laufwerk mit Nutzdaten verloren geht. Ob man zudem eine 4 TByte große Festplatte oder eine SSD mit ein paar Hundert Gigabyte für seine Systempartition nutzt, macht unterm Strich praktisch keinen Unterschied mehr.

RAID und Co.

Etwas anders gestaltet sich die Sache bei zentralen Diensten. In beinahe jedem Setup gibt es heute eine Datenbank, oft handelt es sich um MySQL oder PostgreSQL. Es liegt in der Natur solcher Datenbanken, dass sie umso flinker ans Werk gehen, je schneller der sich unter ihnen befindliche Speicher ausfällt.

In der Vergangenheit machten sich hier aus Redundanzgründen Plattenverbünde breit, aber RAID 5 oder 10 bündelt eben auch die verfügbare Bandbreite und gewährleistet so eine hohe Geschwindigkeit der Datenbankanbindung. Verschiedene Caching-Mechanismen erlauben zudem den schnelleren Zugriff auf Daten, selbst wenn altmodische Festplatten zum Einsatz kommen.

Praktisch ist davon allerdings abzuraten und die dringende Empfehlung lautet, Datenbanken heute auf Flash-basierte Laufwerke zu packen und von RAID abzusehen. Mit Flash-basiertem Speicher entfällt von vornherein ein Teil der Probleme, die der Admin mit konventionellen Festplatten hat. Die Bandbreite einer NVMe oder SSD fällt ab Werk bereits viel höher aus als die selbst vieler Festplattenverbünde, bei denen es zudem in den vergangenen Jahren kaum Fortschritte in diese Richtung gab. RAID würde die SSDs an dieser Stelle eher noch ausbremsen.

Das gilt auch und besonders für die zweite Dimension von Performance, nämlich die Latenz. Weil Flash-Laufwerke keine rotierenden Teile mehr ausweisen, bieten sie drastisch kürzere Zugriffszeiten als Festplatten. Dieser Vorteil ginge im RAID-Verbund ebenso verloren. Dass der Admin möglicherweise auch noch Probleme bekommt, weil der TRIM-Befehl für viele RAID-Controller nicht zur Verfügung steht, SSDs ihn aber dringend brauchen, fällt da schon kaum mehr ins Gewicht.

Sinnvoller aus Sicht des Administrators ist es, die Redundanz der Datenbanken auf der Systemebene zu erreichen. Dazu lässt sich ein Failover-Cluster nutzen, aber heute kommen daneben auch Lösungen wie Galera infrage, die Redundanz auf der Host-Ebene schaffen. Obendrein eröffnet sich dem Administrator so die Möglichkeit, hochperformanten Flash-Speicher für die eigenen Datenbanken zu nutzen. Das könnten etwa auf 5 Gbit/s ausgelegte Module sein, die Hunderttausende Schreibzugriffe pro Sekunde ermöglichen.

Aber Vorsicht: Wer zu einer skalierten Datenbanklösung wie Galera greift, dürfte die Vorteile solcher Hardware nicht bis ins letzte Detail ausnutzen können – schon gar nicht, wenn er die Knoten mit Ethernet verbindet. Ethernet kommt ab Werk mit einer impliziten Latenz, an der Tuning kaum etwas ändern kann. Wer in Sachen Hardware ins Volle geht und teuren Flash kauft, greift mithin wirklich tief in die Tasche. Zuvor sei dringend empfohlen, den tatsächlichen Bedarf durch Trending zu erheben, um sich finanziell nicht in ein nutzloses Rennen zu versteigen.

Verteilter Speicher

Viele Setups sind heute so konzipiert, dass auf den jeweiligen Systemen nur noch so wenige Daten wie möglich lokal liegen. Gerade für Virtualisierung hat sich dieses Prinzip etabliert, weil es mit hohem Aufwand verbunden wäre, Datenträgerredundanz auf jedem System herzustellen. Stattdessen steht ein zentraler Zugriffspunkt für den Admin (Single Point of Administration) hoch im Kurs, der sich auf diversen Wegen erreichen lässt.

Eine Möglichkeit bieten klassische SANs, die allerdings oft eine eigenen Netzwerkinfrastruktur voraussetzen. Hier bieten die Hersteller eine breite Palette an, und SANs, die ausschließlich Flash verwenden, stehen massenhaft zur Verfügung. Das Preisschild solcher Lösungen hat allerdings das Potenzial, dem Admin Tränen in die Augen zu treiben. Obendrein erweist sich die Skalierbarkeit der Geräte in aller Regel als eingeschränkt. Braucht man also mehr Platz, als das jeweilige Gerät bietet, benötigt man ein zweites, und der Vorteil des Single Point of Administration ist wieder dahin.

Als Alternative zu blockbasiertem Speicher hat sich in den vergangenen Jahren Ceph etabliert. Es besteht im Kern aus einem Objektspeicher, bietet allerdings über verschiedene Protokolle mehrere Schnittstellen zur Außenwelt. Über das RBD-Protokoll lässt sich eine virtuelle Festplatte in Ceph via Netzwerk anbinden, und dank der Librbd klappt das mittlerweile auch aus Emulatoren wie Qemu nativ. Die Daten nehmen also keinen Umweg durch ein Kernel-Modul.

Grundsätzlich beherrscht Ceph den Umgang mit SSDs (Abbildung 3) und HDDs gleichermaßen, wobei es zwischen ihnen zu unterscheiden vermag. Die Werkzeuge zum Einrichten von Ceph erkennen die unterschiedlichen Laufwerkstypen und hinterlegen die passenden Details in der sogenannten Crush Map, die über die Platzierung von Daten im Cluster entscheidet.

Abbildung 3: Die NVMe-Schnittstelle macht Laufwerke direkt über PCI-Express nutzbar und räumt so SATA aus dem Weg. Im Rechenzentrum befinden sich NVMe-Speicher auf dem Vormarsch. Quelle: Samsung

Wissen, was nötig ist

Die Erfahrung zeigt zudem, dass es tatsächlich eine gute Idee ist, in Ceph die verschiedenen Gerätearten zu kombinieren. Einmal mehr gilt: Der Admin sollte seine Workloads kennen und abschätzen können, welche Funktionen er wirklich braucht.

Sollen im Virtualisierungscluster etwa Anwendungen laufen, bei denen es auf die verfügbare Bandbreite ankommt, wirken ein paar SSDs oder NVMes (Abbildung 4) im Ceph-Pool Wunder. Auch auf die Latenz beim Zugriff auf die Daten wirkt Flash sich spektakulär aus. Längst nicht jeder Einsatzzweck rechtfertigt jedoch den Kauf von (momentan noch) teurer Flash-Hardware, und gerade Einsatzszenarien in großen Skalierbarkeitsstufen machen das schnell deutlich.

Abbildung 4: Extrem schnell arbeiten NVMe-Geräte wie Intels “Optane”-Serie, für den massenhaften Einsatz sind sie allerdings zu teuer. Quelle: Intel

Wer ein Terabyte Flash-Speicher für 0,2 Cent herstellt, ein Terabyte Plattenplatz aber für nur 0,05 Cent produziert, der kann beim Einsatz von Platten ein Produkt zum günstigeren Preis anbieten. Bei Massenprodukten wie Webhosting ist das relevant. Das gilt umso mehr, da es bei den meisten Anwendungen von Webhosting-Kunden in Sachen nicht auf extreme Performance ankommt. Der Kunde, dessen Datenbank am Tag ein paar Tausend Zugriffe abwickelt, bemerkt im Normalfall höchstens an der Latenz, ob seine Daten auf Flash oder Festplatten lagern – und selbst das ist wegen der impliziten Latenz von HTTPS schwierig.

Die Mischstrategie ist daher der perfekte Ansatz. Ceph eröffnet die Möglichkeit, Festplatten und Flash-Laufwerke logisch in unterschiedliche Kategorien zu sortieren, die sogenannten Pools. Auf der Anwendungsebene bindet der Admin diese Pools im Normalfall in Form unterschiedlicher Storage-Ziele an. Legt der Anwender dann ein Volume an, bestimmt er über die Auswahl des Pools, welche Speichertechnik er nutzt. Verknüpft der Admin den Flash-Speicher und den eher langsamen HDD-Speicher dann noch mit unterschiedlichen Preisschildern, ist die Sache geritzt.

Bei verteilten Speicherlösungen wie Ceph oder OpenStack Swift sollte der Admin allerdings über das Layout seiner Installation nachdenken. Sündhaft teure, weil besonders schnelle oder besonders haltbare Flash-Laufwerke müssen es nicht sein. Das verführt manchen Admin dazu, wenige Systeme mit vielen relativ großen Flash-Laufwerken zu bauen. Ein Ceph-Knoten mit 16 NVMes zu je 7,6 TByte Kapazität etwa stellt aus Sicht des Hosts kein Problem dar.

Wenn es kracht

Aus Ceph-Sicht kann ein solches Layout allerdings schnell zum Problem werden, wie ein simples Gedankenexperiment zeigt. Verliert ein aus fünf Knoten mit Speicherlaufwerken für Ceph bestehender Cluster mit sechzehn 7,6-TByte-NVMes pro Host einen Knoten durch Ausfall, betrifft das 20 Prozent der Brutto-Kapazität oder 122,88 TByte.

Planmäßig führt der Ausfall eines Knotens in Ceph dazu, dass sofort eine Recovery-Operation startet. Dabei legt der Cluster Kopien jener Objekte an, deren Replikationsvorgaben nach dem Ausfall des fünften Knotens nicht mehr erfüllt sind. Gleichzeitig stößt Ceph allerdings auch sein eigenes Backfilling an. Weil der Crush-Algorithmus Hash-basiert arbeitet, ändert sich durch die Veränderung des Cluster-Layouts (ein Knoten weniger) für viele binäre Objekte im System auch die Zuordnung zu den einzelnen Laufwerken.

Je nach genutzter Netzwerklatenz dauert es eine ganze Weile, bis der Backfill in einem solchen Szenario abgeschlossen ist. Der Vorgang beeinflusst allerdings die Performance für normale Schreibvorgänge im System erheblich. Solange also Wiederherstellung und Backfill aktiv sind, zieht das alle Cluster-Operationen in Mitleidenschaft und bremst die Clients aus.

Weil hier oft das Netz und weniger die Laufwerke ein Problem sind, helfen schnellere Flash-Laufwerke nicht, zumal diese in 7.6 TByte Größe auch kaum erschwinglich wären. Der Admin fährt also mit soliden SSDs oder NVMes gut, teilt diese allerdings idealerweise auf viele Systeme auf. Für Massenprodukte auf HDD-Basis gilt exakt dasselbe.

Objektspeicher für Objektzugriff

In unmittelbarem Zusammenhang mit dieser Diskussion steht jene über klassisch als solche genutzte Objektspeicher. Amazon hat mit S3 einen Weg gefunden, Daten per HTTP/HTTPS in nahezu beliebiger Art und Weise verfügbar zu machen. Kein Wunder, dass diesen Erfolg einige gern nachahmen möchten; S3-Reimplementierungen für das eigene Rechenzentrum gibt es heute zuhauf. Bei der Frage, ob Platte oder Flash, nehmen diese in gewisser Weise eine Sonderrolle ein, und zwar wegen der Art, in der Benutzer auf sie zugreifen.

HTTP und HTTPS stehen ja von vornherein nicht unter dem Verdacht, sonderlich flott zu arbeiten. Vor allem die durch das Transportmedium Ethernet induzierte Latenz stellt hier eine echte Herausforderung dar. Ein Übriges trägt die schiere Distanz zwischen Client und Server bei. Beim Aufruf einer Website die Wegstrecke von München nach Hamburg zurückzulegen dauert eine (kurze) Weile, wie man es auch dreht und wendet. Der Knackpunkt dabei: Selbst wenn der Admin den Speicher für sein S3 mit fetten Flash-Laufwerken vollstopfte, bliebe der Effekt für die Endanwender überschaubar. Hohe Investitionen nützen hier also nicht, und der Admin investiert sein Spielgeld sinnvollerweise in etwas anderes.

Nicht ohne Trending

Mehrmals kam in diesem Artikel bereits der Aspekt der Erhebung des eigenen Bedarfs zur Sprache. Nur wenn der Admin seine Anforderungen genau kennt, kann er mit der passenden Hardware an den richtigen Stellen reagieren. Mancher missversteht die Aufforderung zur Bedarfserhebung als Arbeit, die nur ein einziges Mal bei der Planung einer Umgebung anfällt. Baut man ein Setup mit klar eingegrenzten Aufgaben, das über seine Lebensdauer nicht wächst, ist das auch der richtige Ansatz.

Allerdings existieren heute solche Setups immer seltener. Stattdessen finden sich heute in der Praxis meist die bereits erwähnten Virtualisierungsplattformen, die ihren Umfang gern auch mal verdoppeln. Bereits nach zwei Jahren kann sich die Anforderung an das, was der verfügbare Speicher leisten muss, fundamental geändert haben, was eine Neubewertung der Situation erfordert.

Admins kommen in solchen Umgebungen daher auch nicht sinnvoll dazu, allgemeine Annahmen zu machen. Stattdessen müssen sie proaktiv und ständig den Umfang und die Art der Ressourcennutzung im Cluster überwachen. Werkzeuge wie Prometheus in Kombination mit Grafana (Abbildung 5) liefern eine schnelle Übersicht über die Last der vorhandenen Hardware. Wer in einem Ceph-Cluster unterschiedliche Pools mit HDDs und SSDs betreibt, kann sich pro Pool die durchschnittliche Lese- und Schreibrate ebenso anzeigen lassen wie aktuelle IOPS oder deren 50. Perzentil.

Abbildung 5: Permanente Überwachung mit Werkzeugen wie Prometheus erleichtert es dem Admin, den eigenen Bedarf zu tracken und proaktiv zu reagieren. Quelle: Antoine Solnichkin

Kommt der Admin anhand dieser Daten zu dem Schluss, dass seine Hardware nicht mehr zu seinen Anforderungen passt, kann er mit genügend zeitlichem Puffer nachjustieren. Einmal mehr zeigt sich, dass Trending zu den zwingenden Voraussetzungen moderner Virtualisierungscluster zählt und es ohne schlicht nicht geht.

Haltbarkeit

Am Ende dieses Artikels darf eine Warnung nicht fehlen, die manch geschockter Admin vermutlich gern rechtzeitig gehabt hätte. Flash gilt aus Sicht vieler Admins als die deutlich zuverlässigere Storage-Option als Festplatten.

Das scheint zunächst auf der Hand zu liegen, denn in modernen HDDs drehen sich etliche Metallscheiben in einem Gemisch aus speziellen Gasen zum Teil 15 000 Mal pro Minute um die eigene Achse. Dass das an die Substanz des Materials geht, leuchtet sofort ein. Bei SSDs und NVMes hingegen bewegt sich gar nichts.

Dass das zwangsläufig mit einer geringeren Anfälligkeit für Fehler einhergeht, ist jedoch ein (verbreiteter) Trugschluss. Allerdings gibt keine einzige der zahlreichen Untersuchungen zum Thema diese Aussage her. Zwar ermöglichen es SSDs durch ihr Fehlerkorrekturverhalten, einen Ausfall vorhersagbarer als bei Platten zu machen, deren gefürchteter Headcrash sich selten ankündigt. Daraus lässt sich aber nicht generell eine höhere Zuverlässigkeit von Flash-Speichern herleiten.

Zudem verschleißen Flash-Speicher durchaus. Grob vereinfacht dargestellt, funktionieren sie nach dem Prinzip von Kondensatoren, die eine gewisse Spannung halten. Dabei kommt in den allermeisten Flash-Speichern der Gegenwart Silizium zum Einsatz, das hier eine Trennfunktion erfüllt: Es unterbricht den Stromfluss innerhalb der einzelnen Speicherzellen. So lassen sich die Zellen problemlos auslesen, aber nicht beschreiben.

Schreibvorgänge innerhalb von Flash-Speichern erfordern kurzzeitig eine deutlich höhere Spannung – so hoch, dass sie die hemmende Wirkung des Siliziums überwindet. Das ist etwa das Funktionsprinzip modernen Speichers nach der 3D-NAND-Technologie. Das Problem: Bei jedem Schreibvorgang, also jedes Mal, wenn die Spannung in der Zelle so ansteigt, dass sie die Siliziumschicht überwindet, beschädigt sie diese. Das Spiel geht so lange gut, bis nicht mehr genug Silizium übrig bleibt, um die Speicherzelle im Normalzustand frei von fließendem Strom zu halten. Spätestens dann ist die Zelle kaputt.

DWPD ist wichtig

Im Alltag dürfte dieser Verschleiß üblicherweise eine untergeordnete Rolle spielen. Wer etwa Flash-Speicher für seine Systemlaufwerke nutzt, schreibt hier nur selten so viel, dass die Geräte wirklich kaputtgehen.

Der Administrator kann die Lebensdauer übrigens auch berechnen: Für jedes Flash-Laufwerk geben Hersteller die DWPD-Zahl an. Das Kürzel steht für Drive Writes Per Day und gibt an, wie oft sich das gesamte Laufwerk pro Tag innerhalb der Garantie des Herstellers überschreiben lässt, ohne kaputtzugehen. Die Spezifikation basiert auf dem TBW-Test (Terabyte Written) des JEDEC-Verfahrens und macht die Lebensdauer von SSDs vergleichbar.

Die meisten Geräte kommen mit DWPD-Werten zwischen 3 und 5 daher; auf eine 200-GByte-SSD ließen sich pro Tag also 600 bis 1200 GByte schreiben. Das wird freilich kaum eintreten, wenn das Laufwerk nur für die Systemfestplatte zum Einsatz kommt.

Achtsam sein

Anders sieht die Sache eventuell bei Flash-Speicher aus, den der Admin in einen Ceph-Cluster für Hochgeschwindigkeitszwecke integriert. Es gibt durchaus extrem schreiblastige Einsatzszenarien, etwa bei Analyse- oder Simulationssoftware, die große Mengen an Daten lesen, aber auch schreiben. Baut der Admin nun also viele Festplatten mit 3 DWPD in seinen Ceph-Cluster ein, packt sie dort in einen eigenen Pool und lässt seine Applikation darauf mit ein paar Gigabit pro Sekunde los, hat er an seinem Ceph-Cluster nicht allzu lange Freude.

Freilich gibt es auch Flash-Laufwerke, die deutlich höhere DWPD-Werte erreichen. Die kosten dann allerdings auch den einen oder anderen Euro mehr. Eine Intel “Optane” mit 1,5 TByte Kapazität und 20 DWPD kostet entspannte 4300 Euro brutto und dürfte dadurch das ein oder andere Loch in manches Budget reißen. Das Perfide ist dabei allerdings auch, dass sich entsprechende hohe Schreibraten mit Festplatten realistisch nicht mehr erreichen lassen – um Flash kommt der Admin also nicht herum.

Fernab aller anderen Tipps in diesem Artikel gilt deshalb, dass der Admin beim Kauf von Flash-Speichern die erwartete Schreiblast im Hinterkopf haben und entsprechend beachten muss.

Fazit

Der Siegeszug von Flash-Laufwerken ist nicht mehr aufzuhalten, und es scheint nur eine Frage der Zeit, bis klassische Festplatten ein Fall für den Elektromüll werden. “Mal eben” auf Flash-Speicher umbauen ist so simpel allerdings nicht: Je nach geplantem Einsatzzweck eignen sich manche Flash-Spielarten besser oder schlechter. Hier hilft nur eine gründliche Bestandsaufnahme vor der Anschaffung von Hardware weiter. Zumindest aus heutiger Sicht ist obendrein die Anschaffung von (noch) teurem Flash faktisch gar nicht zwingend erforderlich: Ein reiner Objektspeicher für S3 lässt sich ebenso gut mit normalen Platten betreiben. (jcb)