Das sollten Sie beim Vergleich der Storage-Leistung beachten
Auf die Daten der Produktblätter sollte man sich beim Leistungsvergleich zwischen Storage-Systemen nicht verlassen, denn es gibt bessere Methoden, Fehlinvestitionen zu vermeiden.
Storage-Hersteller lieben es, über ihre Leistungsspezifikationen zu reden: IOPS, Durchsatz und Latenz. Allerdings sind diese Spezifikationen nicht standardisiert, und es gibt kaum verlässliche Angaben darüber, wie Hersteller auf ihre jeweiligen Werte kommen oder wie die angegebenen Leistungen im Verhältnis zu bestimmten Workloads stehen. Zudem wenden die Hersteller unterschiedliche Messverfahren an. Die drei Storage-Typen (Block, File und Objekt) komplizieren die Situation weiter.
IT-Profis müssen aus der undurchsichtigen Masse von Angaben die Wahrheit herausfiltern. Dabei sind sie letztlich auf ihre eigenen Geräte angewiesen. Wie also die Leistung von Storage-Systemen vergleichen?
Missverständnisse hinsichtlich der Performance-Metriken
Die Metriken für die Leistungsmessung an Storage-Systemen messen grundsätzlich drei Parameter: Latenz oder Verzögerung beim Lesen und Schreiben, Ein-/Ausgaben pro Sekunde (IOPS) und Durchsatz, also die Zahl der Bytes, die pro Sekunde das System durchfließen.
Das Problem ist das Messverfahren. Nur schwer lässt sich genau feststellen, was der jeweilige Hersteller misst.
Wie in der folgenden Grafik dargestellt, sollten Organisationen diverse Faktoren berücksichtigen, wenn sie die Leistungsangaben der Hersteller standardisieren wollen. Wird die Latenz ab dem ersten Byte, nur in einer oder beiden Richtungen, vom Filesystem oder der Applikation aus gemessen?
Abbildung 1: Die wichtigsten Kriterien für den Vergleich der Performance von Speichersystemen.
Werden sequenzielle Lese-, Schreib- oder gemischte Vorgänge oder Zufallszugriff gemessen? Für welche Datenblockgröße? Wie groß ist das Datenpaket, auf die sich eine Ein-/Ausgabe bezieht? Und schließlich: welche Workloads werden gemessen, wie ausgelastet ist das System?
Auch die Art des Storage muss berücksichtigt werden. Block Storage zielt normalerweise auf optimale Ein-/Ausgabeleistung und Latenz, File und Object Storage stärker auf Durchsatz.
Storage-Anbieter messen im Allgemeinen so, dass möglichst gute Ergebnisse für sie dabei herauskommen. Die Messergebnisse beziehen sich nicht unbedingt auf spezifische Lasten oder die Umstände, die im täglichen Betrieb zu erwarten sind.
Daher empfehlen sich Benchmarks als potentiell genaue Leistungsmetrik für Storage-Systeme. Allerdings kann man sie durch die Konfiguration der Storage manipulieren. Oft werden bei Messungen Konfigurationen verwendet, die in der Praxis niemand einsetzt. Das heißt nicht, dass die Messungen falsch sind. Sie stimmen nur nicht, wenn man die für den praktischen Einsatz vom Hersteller empfohlene Konfiguration verwendet.
Parteiische Proof-of-Concepts
Die meisten Storage-Vertriebsspezialisten wollen ihr Storage-System beim Kunden in einem Proof-of-Concept (PoC) installieren und testen. Sie wissen, dass ein Produkt, einmal vor Ort installiert mit den nötigen Applikationen ausgerüstet, wahrscheinlich gekauft wird.
Es gibt nur wenige Anhaltspunkte dafür, wie Anbieter die Leistung von Speichersystemen messen oder ermitteln und wie sie mit einer bestimmten Arbeitslast oder Anwendung zusammenhängen.
Das Problem von PoCs aus Administrationsperspektive sind die vielen Ressourcen, die Arbeit und Zeit, die diese Vorgehensweise verschlingt.
Dazu gibt es zwei Alternativen – ganz ohne Arbeit geht es aber auch hier nicht.
Messung im Herstellerlabor mit vorgegebener Konfiguration
Als erstes müssen alle Workloads definiert werden, die auf dem zu testenden System laufen sollen. Dann misst man die Spitzenleistung des Systems, das ersetzt werden soll. Anschließend misst man die Kapazität und definiert ihre Wachstumsrate bei maximaler Leistung innerhalb der kommenden drei Jahre.
Jetzt wird es interessant. Man bittet den Anbieter, ihre Systeme im Labor mit der vorgeschlagenen Konfiguration unter Spitzenlast zu testen. Es ist sinnvoll, die Tests zu überwachen und sich die Testergebnisse schriftlich geben zu lassen. Dann trägt der Storage-Hersteller oder Reseller das Risiko, nicht der Kunde.
Sollte diese Methode im spezifischen Fall nicht anwendbar sein, gibt es eine weitere Möglichkeit.
Storage-Systemmetriken normalisieren
Diese Option ist arbeitsintensiver. Man sammelt alle für die geplanten Workloads relevanten Storage-Systemmetriken. Alle Hersteller oder Reseller müssen schriftlich darlegen, was sie messen und wie, einschließlich aller Konfigurationen. Das ist aus mehreren Gründen kritisch, zum Beispiel wegen der Kosten und der Leistung.
Behauptet der Hersteller etwa, der Systemdurchsatz liege bei 171 GB/s, braucht er dafür aber 352 Serverknoten mit je zwei Rack-Einheiten Platzverbrauch, bedeutet das hohe Kosten, die berücksichtigt werden müssen: Strom, Kühlung, UPS, Vernetzung, Kabel, Transceiver und Platz in Rack-Schränken. Diese Kosten kommen in der Regel im Vorschlag des Anbieters nicht vor. Er umfasst nur den Preis des Storage-Systems, Softwareabonnements, Implementierung und Wartung. Die gilt auch bei Cloud-On-Demand-Preismodellen.
Als nächstes vergleicht man die anwendbaren Metriken der jeweils zur Wahl stehenden Storage-Systeme und sucht nach einem gemeinsamen Nenner. Berichtet Hersteller A beispielsweise IOPS-Werte für sequentielles Lesen von 4-KB-Blöcken, während Hersteller B dasselbe für Lesen mit Zufallszugriff tut, bittet man die Anbieter, sich auf einen einheitlichen Parameter zu einigen und vergleicht danach. Die Chance steht gut, dass die Hersteller entsprechende Werte haben, auch wenn sie sie nicht unaufgefordert kommunizieren.
Sinnvollerweise sollte man Metriken vergleichen, die für die Applikationen und Workloads auf dem System relevant sind. Soll etwa eine Oracle-Datenbank gespeichert werden, empfehlen sich IOPS-Werte für gemischte Lese-/Schreib-Zufallszugriffe auf 8-KB-Blocks. Liefert ein Anbieter nur 4-KB-Werte, kann man die Werte für 8 KB ungefähr schätzen, indem man die 4-KB-Werte halbiert. Widerspricht der Hersteller dieser Annahme, sollte man nach den tatsächlichen Testergebnissen für 8 KB zu fragen. Dasselbe kann man auch bei anderen I/O-Größen praktizieren.
Der Durchsatz lässt sich schwieriger standardisieren, besonders dann, wenn die Anbieter hierzu keine Daten liefern. Man kann ihn grob kalkulieren, indem die IOPS für sequenzielles Lesen mit der Größe eines I/O-Blocks multipliziert werden.
Am schwierigsten ist die Standardisierung bei der Latenz, besonders, wenn Hersteller sie unterschiedlich messen. Es gibt sehr viele Faktoren, die sie beeinflussen, beispielsweise die Systemlast des Storage, die Kapazitätsauslastung, die verwendeten Medien, die Menge an verfügbarem DRAM-Cache, vorhandene Engpässe im Storage-Netz, die Last und Auslastung der Applikationsserver sowie dort vorhandene Engpässe.
Die wichtigste Frage ist, wie, unter welchen Lasten und zwischen welchen Punkten der Anbieter die Latenz gemessen hat: Von und zum Interconnect auf dem Storage-Controller zu messen, vereinfacht die Normalisierung, weil Faktoren, die nicht direkt zum Storage gehören, außer Betracht bleiben.
Ist die Leistung jedes potentiellen Storage-Systems auf einen gemeinsamen Nenner gebracht, kann man die Gesamtkosten (TCO, Total Cost of Ownership) über fünf Jahre für jedes System berechnen. Dann lässt sich die TCO ins Verhältnis zur Leistung setzen.
