Testen von NetApp E2700

    Testen von NetApp E2700

    Lange Zeit bin ich nicht auf Tests eines Einsteiger-Arrays gestoßen, das bis zu 1,5 Gbit / s über einen einzelnen Controller mit Streaming-Last übertragen kann. NetApp E2700 hat diese Aufgabe gerade gemeistert. Im Juni habe ich das Unboxing NetApp E2700 gehostet . Und jetzt bin ich bereit, Ihnen die Ergebnisse des Tests dieses Speichersystems mitzuteilen. Im Folgenden stelle ich die Ergebnisse von Auslastungstests und die daraus resultierenden quantitativen Leistungsindikatoren des NetApp E-Series 2700 Arrays (IOps, Durchsatz, Latenz) vor.

    Die Konfiguration des Festplatten-Arrays sieht wie folgt aus:

    NetApp E2700 Festplatten-Array-Konfiguration

    Das Schema zum Verbinden des Arrays mit dem Server:

    NetApp E2700 Array-Verbindungsdiagramm zum Server

    Und die Konfiguration des Testservers:

    Testen Sie die Serverkonfiguration

    Testmethodik


    Als Lastgenerator verwende ich den FIO-Benchmark, den "echtesten" Benchmark unter Linux. Ich möchte Daten zur Durchschnittsgeschwindigkeit (Bandbreite, Mb / s) und zu durchschnittlichen Verzögerungen (Latenz, ms) unter den folgenden Lasttypen erhalten:
    1. 100% sequentielles Lesen in Blöcken von 256 kb, 512 kb und 1024 kb;
    2. 100% sequentielle Aufzeichnung in Blöcken von 256 kb, 512 kb und 1024 kb;
    3. Gemischtes sequentielles Lesen / Schreiben (50/50) in Blöcken von 256 kb, 512 kb und 1024 kb;
    4. 100% zufällige Ablesung in Blöcken von 4 kb, 8 kb und 16 kb;
    5. 100% zufällige Aufzeichnung in Blöcken von 4 kb, 8 kb und 16 kb;
    6. Gemischtes zufälliges Lesen / Schreiben (50/50) in Blöcken von 256 kb, 512 kb und 1024 kb;

    In diesem Fall verwende ich zwei LUNs aus dem Array mit einer Größe von jeweils 1 TB, die auf Serverebene als RAW-Geräte verfügbar sind: sdb und sdc.

    Ein wichtiger Punkt meiner Tests ist der Vergleich der Leistung der verschiedenen RAID-Level, die das Array unterstützt. Aus diesem Grund werde ich die Last abwechselnd auf die LUNs anwenden, die unter DDP, RAID6 und RAID10 erstellt wurden. Und ich werde Dynamic Disk Pool und Volume Groups auf der Basis aller 24 Festplatten erstellen.

    Um die Ergebnisse nicht vom Betriebsalgorithmus des berüchtigten „Linux-Speichercaches“ abhängig zu machen, verwende ich Blockgeräte, ohne ein Dateisystem darüber zu organisieren. Dies ist natürlich nicht die Standardkonfiguration für Streaming-Anwendungen, aber es ist wichtig zu verstehen, wozu ein Array in der Lage ist. Mit Blick auf die Zukunft sage ich jedoch, dass bei Verwendung der Parameter direct = 1 und buffered = 0 im FIO-Lademuster das Arbeiten (Schreiben) mit Dateien auf EXT4-Ebene mit Geräten mit Bandbreite-Block nahezu dieselben Ergebnisse erzielt. Gleichzeitig sind die
    Latenzindikatoren bei der Arbeit mit dem Dateisystem um 15 bis 20 Prozent höher als bei der Arbeit mit Raw- Geräten.Das Lademuster für FIO ist wie folgt konfiguriert:

    [global]
    description = seq-reads
    ioengine = libaio
    bs = so
    direct = 1
    buffered = 0
    rw = [schreiben, lesen, rw, randwrite, randread, randrw]
    Laufzeit = 900
    Thread

    [sdb]
    Dateiname = / dev / sdc
    Iodepth = sehen unter

    [sdc] filename =
    / dev / sdb
    iodepth = see unten


    Wenn ich richtig verstanden habe, bestimmt man by fio, der Parameter iodepth, die Anzahl der unabhängigen Threads, die gleichzeitig mit der Festplatte arbeiten. Dementsprechend erhalte ich in der Konfiguration die Anzahl der Threads gleich X * 2 (4, 8, 16).

    Als Ergebnis erhielt ich folgende Testsuite: Wir

    Testsuite für NetApp E2700

    haben die Methoden herausgefunden, die Muster bestimmt und die Last angegeben. Um dem Administrator die Arbeit zu erleichtern, können Sie eine Reihe von FIO-Mustern in Form separater Dateien ausschneiden, in denen sich die Werte der beiden Parameter - bs und iodepth - ändern. Dann können Sie ein Skript schreiben, das in einem Doppelzyklus (Ändern der Werte von zwei Parametern) alle unsere Muster ausführt und die erforderlichen Indikatoren in separaten Dateien speichert.

    Ja, ich hätte fast ein paar Punkte vergessen. Auf der Array-Ebene habe ich die Cache-Einstellungen wie folgt konfiguriert:
    • Für Streaming-Aufnahmen habe ich den Lese-Cache deaktiviert.
    • für das Streaming-Lesen wurde der Schreib-Cache ausgeschaltet und der dynamische Lese-Prefetch-Algorithmus nicht verwendet;
    • Für gemischte Lese- und Schreibvorgänge ist der Cache vollständig aktiviert.

    Auf Linux-Ebene habe ich den regulären I / O-Scheduler auf noop für Streaming-Vorgänge und auf deadline für Random-Vorgänge geändert. Außerdem habe ich den Multipath-Treiber von NetApp, MPP / RDAC, installiert, um den Datenverkehr auf HBA-Ebene richtig auszugleichen. Die Ergebnisse seiner Arbeit haben mich positiv überrascht, der Datenfluss zwischen den HBA-Ports war fast 50-mal-50 ausgeglichen, was ich mit Qlogic oder dem regulären Linux Multipathd noch nie gesehen habe.

    SANTricity hat eine Reihe von Optimierungsparametern (ich habe oben zum Beispiel über die Verwaltung des Daten-Caches auf Volume-Ebene geschrieben). Ein weiterer potenziell interessanter Parameter ist die Segmentgröße, die auf Lautstärkeebene eingestellt und geändert werden kann. Die Segmentgröße ist ein Block, den der Controller auf eine Festplatte schreibt (Daten in einem Segment werden in Blöcken von 512 Byte geschrieben). Wenn ich DDP verwende, ist die Größe dieses Parameters für alle im Pool erstellten Volumes gleich (128 KB) und kann nicht geändert werden.

    Für Volumes, die auf der Basis von VolumeGroup erstellt wurden, kann ich vorkonfigurierte Ladevorlagen für das Volume auswählen (Dateisystem, Datenbank, Multimedia). Außerdem kann ich die Größe von SegmentSize selbst im Bereich von 32 KB bis 512 KB auswählen.

    Auswählen vordefinierter Lademuster für ein aus VolumeGroup erstelltes Volume

    Im Allgemeinen ist die Größe der Segmentgröße für den integrierten Volume-E / A-Merkmalstyp nicht sehr unterschiedlich:
    • Für das Muster Dateisystem = 128 Kb;
    • Für das Muster Database = 128 Kb;
    • Für das Muster Multimedia = 256 Kb.

    Ich habe das Standardmuster (Dateisystem) beim Erstellen des Volumes nicht geändert, sodass die Segmentgröße für die auf dem DDP und der regulären VolumeGroup erstellten Volumes identisch ist.

    Natürlich habe ich mit der Größe der Segmentgröße herumgespielt, um zu verstehen, wie sich dies auf die Leistung von Schreibvorgängen auswirkt (zum Beispiel). Die Ergebnisse sind ganz normal:
    • Mit der kleinsten Größe (SS = 32 KB) erhalte ich bei Operationen mit kleinen Blockgrößen eine höhere Leistung.
    • Mit der größten Größe (SS = 1024 KB) erziele ich bei Operationen mit großen Blockgrößen eine höhere Leistung.
    • Wenn ich die SS-Größe und die Blockgröße ausrichte, mit der FIO arbeitet, sind die Ergebnisse sogar noch besser.
    • Es gibt ein "aber". Ich habe festgestellt, dass beim Streaming von Aufzeichnungen in großen Blöcken und bei SS = 1024 KB die Latenz höher ist als bei SS = 128 KB oder 256 KB.

    Insgesamt ist die Nützlichkeit dieses Parameters offensichtlich, und wenn wir davon ausgehen, dass wir viele zufällige Operationen haben werden, ist es sinnvoll, ihn auf 32 KB festzulegen (es sei denn, wir verwenden natürlich DDP). Für Streaming-Vorgänge sehe ich keinen Grund, den SS-Wert auf das Maximum zu setzen, weil Ich habe keine wesentliche Erhöhung der Datenübertragungsrate festgestellt, und Latenzindikatoren können für die Anwendung von entscheidender Bedeutung sein.

    Ergebnisse (Auswertung und Vergleich der Ergebnisse)


    DDP-

    DDP-Testergebnisse für NetApp E2700

    Testergebnisse RAID6-Testergebnisse

    RAID6-Testergebnisse für NetApp E2700

    RAID10-Testergebnisse

    RAID10-Testergebnisse für NetApp E2700

    Auswertung der Ergebnisse


    1. Der erste Punkt, den ich sofort bemerkte, war die 0% ige Auslastung des Lese-Cache für ein beliebiges Muster (und selbst wenn der Schreib-Cache vollständig ausgeschaltet ist). Es war nicht möglich zu verstehen, womit es verbunden war, aber die Ergebnisse von Leseoperationen sanken im Vergleich zu Schreiboperationen erheblich. Möglicherweise liegt dies an der Konfiguration des Test-Arrays mit einem Controller, da der Lesecache zwischen den beiden Controllern gespiegelt werden sollte.
    2. Der zweite Punkt sind die eher niedrigen Raten für Zufallsoperationen. Dies wird durch die Tatsache erklärt, dass die Größe der Segmentgröße (wie oben geschrieben) standardmäßig 128 KB entspricht. Für kleine Blockgrößen ist diese SS-Größe nicht geeignet. Zur Verifizierung habe ich eine zufällige Last auf Volumes in RAID6 und RAID10 mit SS = 32 KB ausgeführt. Die Ergebnisse waren viel interessanter. Im Fall von DDP können wir die Größe der SS jedoch nicht ändern, sodass die zufällige Belastung der DDP kontraindiziert ist.
    3. Wenn wir die Leistung von DDP, RAID6 und RAID10 mit der Größe von SS = 128 KB vergleichen, können wir die folgenden Muster verfolgen:

    • Im Allgemeinen gibt es keinen signifikanten Unterschied zwischen den drei verschiedenen logischen Darstellungen der Blöcke.
    • RAID10 stabiler hält die Last, auch gemischt, und bietet gleichzeitig die beste Latenz, verliert jedoch an Schreib- und Lesegeschwindigkeit von RAID6 und DDP;
    • RAID6 und DDP in zufälligen Operationen mit zunehmender Blockgröße weisen die beste Latenz und IOps auf. Dies liegt höchstwahrscheinlich an der Größe der SS (siehe oben). RAID10 zeigte jedoch keinen solchen Effekt.
    • Wie ich oben geschrieben habe, ist eine zufällige Auslastung für DDP bei Blockgrößen von weniger als 32 KB in jedem Fall kontraindiziert.


    Schlussfolgerungen


    Lange Zeit bin ich nicht auf Tests eines Einsteiger-Arrays gestoßen, das bis zu 1,5 Gbit / s über einen einzelnen Controller mit Streaming-Last übertragen kann. Es ist davon auszugehen, dass die Dual-Controller-Konfiguration bis zu 3 Gbit / s verarbeiten kann. Und das ist ein Datenstrom bis zu 24 Gb / s.

    Selbstverständlich sind die von uns verwendeten Tests synthetisch. Die gezeigten Ergebnisse sind jedoch sehr gut. Wie erwartet hält das Array die gemischte Last während zufälliger Operationen schwach, aber es gibt keine Wunder :-).

    In Bezug auf die Benutzerfreundlichkeit und die Möglichkeit, die Einstellungen für ein bestimmtes Lastmuster für ein Array der Einstiegsklasse zu optimieren, hat sich das E2700 als führend erwiesen. SANTricity hat eine klare und recht einfache Benutzeroberfläche mit einem Minimum an Störungen und Bremsen. Es gibt keine unnötigen Einstellungen von Werten, die oft nicht klar sind (ich erinnere mich an die Steuerschnittstelle der IBM DS 4500 - es war etwas). Im Allgemeinen ist alles solide "4".

    Jetzt auch beliebt: