PowerStore: Effektive Techniken zur Bewertung der Storage-Array-Performance

Hinweis: Das Benchmarking ist nur gültig, wenn die gesamte Testumgebung gemäß den PowerStore Best Practices eingerichtet wurde und keine Verbindungs- oder Konfigurationsprobleme vorliegen. Andernfalls liefert der Test wahrscheinlich irrelevante Daten.

• Testen Sie mit Variablen, die der tatsächlichen Workload/Umgebung ähneln. Denken Sie daran, dass die meisten Tools Simulatoren sind und niemals 100 % einer tatsächlich simulierten Produktionsworkload erreichen.
• Wenn die Workload stark variiert, sollten Sie mehrere Iterationen von Lese-/Schreibtests mit unterschiedlichen Blockgrößen und Zugriffsmustern durchführen.
• Verwenden Sie Multithread- und asynchrone Vorgänge oder Tests, um parallele oder gleichzeitige Leistungsfunktionen sicherzustellen und sicherzustellen, dass das gesamte kumulierte Durchsatzpotenzial genutzt wird. 
• Berücksichtigen und überprüfen Sie Branchenstandard-Benchmarks für die zu evaluierenden Geräte in Bezug auf die Produktions-Workload Ihres Unternehmens.
• Führen Sie keine Tests mit Dateisystemen und/oder Volumes durch, die leer sind oder nur wenig Speicherplatz belegen. Wenn Sie keinen Speicherplatz für Schreib-Workloads vorab zuweisen, kommt es zu Latenzen aufgrund der On-the-fly-Zuweisung von Speicherplatz während des Tests.
• Vergessen Sie auch nicht, die Lese-I/O zu testen, da dies in den meisten Umgebungen in der Regel die häufigere Workload ist. Achten Sie während des Tests auf Paket/Frame-Verluste in der Netzwerkinfrastruktur.
• Stellen Sie sicher, dass Sie auf mehreren Geräten testen, um eine typische Umgebung mit vielen Hosts oder Clients zu simulieren. Auf PowerStore sind beispielsweise 16 Volumes eine gute Anzahl. Die Volume-Anzahl entspricht in der Regel der Anzahl der verwendeten Hosts oder Clients (physisch oder virtuell). Hier wird Parallelität erreicht.

 

Benchmarking-Tools und -Simulatoren
Denken Sie daran, dass die meisten Tools Simulatoren sind und wahrscheinlich nie 100 % einer echten Produktionsworkload simuliert werden. Diese Benchmarking-Tools werden verwendet, um eine Vorstellung davon zu erhalten, wie die Performance in bestimmten Situationen sein könnte, sein sollte oder sein wird. Dell besitzt diese Tools nicht und ist nicht verantwortlich für Probleme oder Probleme, die damit zusammenhängen können.

Stellen Sie bei jedem Leistungstest sicher, dass Tools mit asynchronen und Multithreading-Funktionen verwendet werden. Beispiele für diese Tools:

• Flexible I/O Tester (FIO)
• IOmeter
• Vdbench (erfordert ein Oracle-Konto)
• NFSometer (nur Fedora/NFS)
• Prüfliste für NAS-Performance von Intel

 

Vermeiden Sie die folgenden Testarten:

• Kopieren und Einfügen
• Ziehen und Ablegen
• Backup eines einzelnen Dateisystems auf Festplatte
• DD-Tests
• Rlarge
• Wlarge
• Mkfile
• Entpacken, Extrahieren und Komprimieren

Bei den meisten Benchmarking-Szenarien gibt es bestimmte Dinge zu beachten. Dieser Abschnitt dient nicht dazu, Workload-Größen und -Merkmale zu erläutern. Wenn Ihnen jedoch vergangene Daten fehlen und Sie eine grobe Schätzung des Anwendungsverhaltens benötigen, um die Funktionen von PowerStore (nicht die spezifische Workload-Performance) zu vergleichen, berücksichtigen Sie die folgenden Faktoren:

 

 

IODepth (Warteschlangentiefe)
Eine niedrige IOdepth (oder nicht hoch genug) kann den potenziellen Durchsatz je nach Situation einschränken. Stellen Sie daher immer sicher, dass die I/O-Tiefe hoch genug ist, um die Parallelitätsanforderungen einer Workload widerzuspiegeln oder zu emulieren. Eine zu niedrige I/O-Tiefe schöpft möglicherweise nicht das volle Potenzial des Geräts aus. Seien Sie aber auch bei einer zu hohen I/O-Tiefe vorsichtig, da dies zu erheblichen Warteschlangen auf dem Gerät und je nach Servicezeit des Geräts zu längeren Antwortzeiten führen kann. Dies kann widerspiegeln, wie ein überlastetes System aussehen könnte.

Bei diesem Test sind die Zahlen deutlich niedriger, wenn es eine IOdepth von eins im Vergleich zu einer IOdepth von etwas Realerem gibt, z. B. 64. Denken Sie daran, dass es sich um ein All-Flash-Array handelt und dieses Konzept daher in seiner extremen, aber immer häufiger vorkommenden Form zu sehen ist."

IOdepth=1" entspricht dies etwa ~30.000 Eingabe- und Ausgabeoperationen pro Sekunde (IOPS) für den Test.

 

„IOdepth=64“ entspricht durchschnittlich etwa ~107.000 IOPS für den Test.

 

 

„IOdepth=256“ entspricht durchschnittlich etwa ~142.000 IOPS für den Test.

 

 

Wie bereits erwähnt, pendelt sich die Performance bei den meisten Konfigurationen ab einer bestimmten I/O-Tiefe ein. Hier liegt eine Warteschlangentiefe von 512 vor und es gibt nur einen geringen Anstieg der IOPS gegenüber einer I/O-Tiefe von 64.

„IOdepth=512“ entspricht durchschnittlich etwa ~146.000 IOPS für den Test.

 

 


Asynchron vs. Synchron
Es gibt zwei verschiedene Hauptmotoren, die verwendet werden. Die beliebtesten und bei weitem effizientesten in Bezug auf die Performance sind „asynchrone I/O“. Der weniger effiziente und weniger leistungsfähige Engine-Typ sind synchrone I/O, die normalerweise mit Anwendungen verwendet werden, die strenge Anforderungen an die Datenintegrität und -sicherheit haben. Synchrone I/O werden auch in RPO-Replikationstechnologien (Recovery Point Objective) nahe Null verwendet. Bei Performancetests und Benchmarks bedeutet asynchron aus Hostperspektive, dass für eine I/O keine Bestätigung erforderlich ist, um die nächste I/O anzufordern. Bei synchronen Workloads ist für eine I/O eine Bestätigung erforderlich, bevor die nächste ausgegeben wird, sowie eine Bestätigung (ACK) für jede nachfolgend angeforderte I/O. Aus diesem Grund haben synchrone I/O in der Regel eine Warteschlange von 1 oder weniger und nutzen die Ressource nie vollständig aus. Das Koppeln synchroner Vorgänge mit einer niedrigen oder einzelnen Threadanzahl kann das Leistungspotenzial stark einschränken. Stellen Sie daher immer sicher, dass Sie asynchrone Tests durchführen, und wenn Sie synchrone Tests verwenden, stellen Sie sicher, dass Sie mehrere Threads verwenden, es sei denn, die Anwendungsumgebung weist ausdrücklich darauf hin.

Asynchron (Libaio – Linux native asynchron) = 1 Thread



Sync (synchrone I/O):  

 

 

Anzahl
der ThreadsFäden sind wichtig. Tests sollten immer mit mehreren Threads durchgeführt werden, insbesondere bei synchronen Tests/Workloads. Dies ist der Versuch, mehrere Iterationen eines Auftrags/Tests basierend auf dem Verhalten des Prozesses einer Unternehmensanwendung zu simulieren. Der aggregierte Durchsatz eines Systems wird durch mehrere Threads in Verbindung mit parallelen Aktivitäten erreicht. Die meisten asynchronen Module verwenden mehrere Threads, sodass Sie sich nicht so viele Gedanken über die Threadanzahl machen müssen. Wenn bei synchronen Workloads nicht genügend Threads vorhanden sind, kann der potenzielle Gesamtdurchsatz eines Auslastungstests für ein System stark eingeschränkt werden."

"Multithreaded" bedeutet, dass mehrere Threads parallel arbeiten. Wenn Sie beispielsweise über ein einzelnes Gerät verfügen, das 1.000 IOPS in einer synchronen Workload verarbeiten kann, bedeutet dies, dass das Gerät eine Antwortzeit von 1 ms ohne Warteschlange hat (ohne Warteschlange sollten also Servicezeit und Antwortzeit synonym sein). Es liegt auf der Hand, dass Geräte mit Antwortzeiten von 1 ms viel mehr Arbeit als 1.000 IOPS erledigen können, und dies wird durch das Stapeln mehrerer Threads oder paralleler Streams derselben Workload erreicht. Wenn Sie also die Threads (oder "Dinge, die diese bestimmte Aufgabe ausführen") auf 10 erhöhen, haben Sie jetzt 10 einzelne Threads, die I/O-Vorgänge zu einem Gerät mit 1 ms durchführen. Jeder einzelne Workload-Thread erhält immer noch 1 ms, was bedeutet, dass jeder Thread immer noch nur 1.000 IOPS erreicht, aber jetzt erhält der gesamte "Prozess" oder "Job", der von diesen mehreren Threads ausgeführt wird, 10.000 IOPS.

Es gibt Tools und Workloads, die mit einem einzigen Thread an die Grenzen eines Geräts stoßen können, andere erfordern mehr. Zusammenfassend lässt sich sagen, dass Sie beim Simulieren einer synchronen Auslastung so viele Threads/Worker/Streams wie möglich haben sollten, ohne die Gesamtantwortzeit zu beeinträchtigen. Es gibt einen Punkt, an dem eine Erhöhung der Thread-Anzahl keinen positiven Effekt mehr hat (wenn das Gerät zu 100 % ausgelastet ist). Im Allgemeinen spielt bei asynchronen Workloads die Thread-Anzahl standardmäßig keine große Rolle. Unten sehen Sie z. B. immer noch einen Unterschied zwischen 1 Thread und 10 für eine asynchrone Workload, wenn auch nicht signifikant. Sie müssen sich bei asynchronen Workloads also keine großen Gedanken über die Threads machen. 

Ein einzelner Thread kann hier 68.000 IOPS mit der (asynchronen) „libaio“-Engine erreichen. 

 

Wenn Sie die Anzahl der Threads (Numjobs) auf 10 erhöhen, können Sie immer noch einen Anstieg der IOPS feststellen.

 

Auch wenn es sich um einen Extremfall handelt, kann es bei synchronen Workloads zwei Hauptfaktoren geben, die bei diesem Test aufgrund der synchronen Natur zu einer schlechten Performance führen. 

I/O-1 senden, auf ACK warten, I/O-2 senden, auf ACK warten usw.

 Und ohne die Möglichkeit, mehrere Threads für denselben Zweck zu stapeln. 

job1=I/O-1 senden - Job2=I/O-1 senden - Job3=I/O-1 senden..... job1=Ack abrufen, I/O-2 senden - job2=Ack erhalten, I/O-2 senden - job3= Ack abrufen, I/O-2 senden usw.

Direkt-Flag

Bei einigen Tools, insbesondere *nix-basierten Tools/Betriebssystemen, wird möglicherweise die Option „Direkte I/O“ angezeigt. Diese kann mit „asynchronen“ Engines verwendet werden und sollte nicht mit „synchronen“ I/O verwechselt werden. Bei einigen Tools kann es ohne diese Markierung dazu kommen, dass in den Servercache und nicht direkt auf die Festplatte geschrieben wird. Der Host möchte seinen eigenen Cache umgehen und direkt auf die Festplatte schreiben. Dies ist ein wesentlicher Faktor beim Testen von Storage. Wenn Sie die „Direkte I/O“-Markierung gesetzt haben, schreiben Sie technisch gesehen auf die Festplatte, obwohl „Festplatte“ in diesem Fall in Wirklichkeit der Storage-Cache ist. Dies ist für Testzwecke immer noch akzeptabel, da Sie selbst mit der richtigen Workload immer noch simulieren und genau nachahmen, wie sich diese Workload in einer realen Umgebung verhält, da auch die Produktionslast auf den Cache trifft, bevor die Bestätigung zurückgesendet wird. (Fühlen Sie sich nicht betrogen, nur weil Sie Leistungszahlen des beteiligten Caches und nicht nur der Back-End-Spindeln erhalten.)

 

Bandbreite (MB/s) vs. Durchsatz (IOPS)

Es gibt zwei Hauptperspektiven, auf die Sie testen können. Der Begriff Durchsatz bezieht sich in der Netzwerk- und Performancewelt in der Regel auf die Datenübertragung. In SAN/Block-Umgebungen ist es jedoch üblich, „Durchsatz“ zur Darstellung der IOPS zu verwenden. Daher müssen Sie zunächst die Workload-Merkmale verstehen, auf die Sie testen.

Bandbreite (MB/s): Die Bandbreite ist das Maß für die Daten, die Sie gleichzeitig (oder innerhalb eines X-Intervalls, in der Regel "pro Sekunde") in einer Pipe oder einem System unterbringen können. Es wird also gemessen, wie viele Daten Sie über einen bestimmten Zeitraum übertragen haben. Obwohl Bandbreite und IOPS sich nicht gegenseitig ausschließen, können Sie mit der gleichen Menge an IOPS eine höhere oder niedrigere Bandbreite erzielen. Es hängt alles von der Blockgröße ab. Denken Sie daran, dass Sie mit der Bandbreite keine Geschwindigkeit messen. Die Geschwindigkeit ist etwas völlig anderes und auch wenn sie sich auf die Bandbreite auswirkt, kann sie in der Regel bei Workloads mit hoher Bandbreite nicht gesteuert werden. Verwenden Sie daher beim Testen der Bandbreite immer größere Blöcke (im Rahmen des zumutbaren Maßes), damit Ihre Daten pro I/O größer sind, als wenn Sie auf IOPS testen würden, da die Wartung größerer Blöcke natürlich länger dauert. Wenn Sie beispielsweise 1 MB/s erzielen möchten, aber 8-KB-Blockgrößen verwenden, müssen Sie etwa 125 IOPS übertragen. Wenn Sie jedoch 512-KB-Blöcke verwenden, sind nur zwei (2) IOPS erforderlich.
(Wenn Sie die 125 IOPS beibehalten und trotzdem die Blockgröße von 8 KB auf 512 KB erhöhen würden, erreichen Sie jetzt 64 MB/s!)

Da sich jedoch mehr Daten in einer einzigen I/O befinden, dauert es in der Regel länger, diese I/O zu "packen" (Suchen, Aneinanderreihen usw.). Daher können die Servicezeiten natürlich höher sein. Manchmal ist eine kürzere Warteschlange vorhanden, sodass Ihre Antwortzeiten, obwohl sie natürlich länger sind, ziemlich nahe beieinander liegen sollten. Denken Sie daran, dass die Antwortzeit zwar eine Rolle dabei spielt, wie viel Bandbreite Sie erreichen können, die Erhöhung der Menge an Daten pro I/O jedoch in der Regel jede geringfügige Erhöhung der Antwortzeit (RT) bei dieser Art von I/O überwiegt. Da die Antwortzeiten höher sind, sollten Sie nicht verhindern, dass Workloads mit großen Blöcken zufällig sein müssen. Bandbreiten-Workloads sind also in der Regel sequenziell. Wenn Sie eine Workload mit großen Blöcken als Zufall einsetzen, wird Ihre stetige Datenübertragungsrate konsistent unterbrochen und Sie machen sich durch die etwas höheren Antwortzeiten pro I/O bemerkbar.

Durchsatz (IOPS): Durchsatz/IOPS ist die häufigste Perspektive bei Workloads mit kleinen Blöcken, insbesondere wenn sie zufälliger werden. Alles, was größer als 32 bis 64 KB ist, kann als großer Block betrachtet werden. Beim Durchsatz sind die oben genannten Faktoren am wichtigsten (Dinge wie Thread-Anzahl, synchron oder asynchron, Warteschlangentiefe usw.). Sie versuchen hier nicht zu messen, wie viele Gesamtdaten Sie während des Intervalls x übertragen können, sondern wie viele einzelne Pakete (I/O-Anforderungen), die diese Daten enthalten, Sie zu verarbeiten versuchen (in jedem Intervall x). In Umgebungen wie OLTP (Bankwesen) spielt es keine Rolle, wie viele Daten übertragen werden können, da ihr Datenbedarf in der Regel gering ist. Diese kleinen Datensets können jedoch stark ausgelastet sein und sind es normalerweise auch. Diese Datensätze weisen einen hohen Skew auf (es wird auf eine kleine Menge an Speicherplatz zugegriffen, dies jedoch aggressiv und konsistent). Die kleinen Datenpakete enthalten in der Regel nur Anforderungen zum Ändern/Aktualisieren von Blöcken mit numerischen oder kleineren Zeichenfolgenwerten und daher sind keine großen I/O-Pakete erforderlich. Aufgrund der Art der Transaktionen und der Tatsache, dass es so viele davon gibt, möchten wir jedoch überprüfen, ob wir mit jeder einzelnen Nachfrage Schritt halten können. In der Regel gilt: Je kleiner die Blockgröße, desto mehr IOPS können in einem bestimmten Szenario erreicht werden und obwohl Workloads mit kleinen Blöcken hauptsächlich wahlfreien Direktzugriff verwenden, können Sie mit sequenziellen Workloads mit kleinen Blöcken noch mehr Durchsatz erzielen. Sequenzielle Workloads mit kleinen Blöcken sind jedoch spezifisch und nicht so verbreitet. Testen Sie diese Szenarien daher nur, wenn dies in Ihrer Umgebung erforderlich ist.