Bewertung der Auswirkung von Cache-Ebenen auf die E / A-Leistung in EMC VNX5400

    Einleitung


    Nach dem Testen und Schreiben eines Artikels über die Auswirkungen von Caching-Mechanismen auf die Leistung im Junior-Modell (Einstiegsmodell) von EMC VNXe3200- Speichersystemen begannen die Hände in regelmäßigen Abständen zu jucken, um dasselbe mit den älteren VNX2-Arrays der Brüder zu tun. Kürzlich bot sich eine solche Gelegenheit. Ich habe es geschafft, Tests auf dem VNX5400 durchzuführen. Es stellte sich heraus, dass der VNX5400 nicht nur direkt getestet wurde, sondern auch die EMC ExtremCache-Lösung (PCI-E-SSD-Karte EMC XtremSF700 auf eMLC-Chips + Software EMC XtremSW). Zu EMC ExtremCache wird es jedoch folgenden Artikel geben. Sprechen wir in der Zwischenzeit über VNX2-Arrays.

    EMC 2-Reihe von Speichersystemen der Mittelklasseaktualisiert im Herbst 2013. Die VNX-Arrays der zweiten Generation (VNX2) sahen meiner Meinung nach gut aus, was die Fehler der ersten Generation (VNX1) angeht. Der Hersteller präsentierte sie als ein grundlegendes und innovatives Update für die Midrenge-Linie. Jetzt, mehr als ein Jahr nach dem Erscheinen auf dem Markt, hat VNX2 immer noch nicht an Relevanz verloren. Ich werde mich nicht mit den Eigenschaften und Fähigkeiten der Arrays selbst befassen, sondern nur Links zu den offiziellen Dokumenten Data Sheet und Spec Sheet geben .

    Standbeschreibung und Tests


    Unter dem Spoiler
    Der Test wurde mit IOMETER durchgeführt. Das Lastprofil ist dasselbe wie beim Testen des VNXe3200 . Standard-Datenbankmuster (Intel / StorageReview.com).



    Es gab einen HP DL360 G5 Server mit 1 CPU (4-Core) und 4 GB RAM. Der Server verfügt über 2 PCI-E-Steckplätze. In einem der Steckplätze wurde ein Dual-Port-HBA Qlogic 4 Gbit / s installiert, der direkt mit dem VNX5400 verbunden ist. Da die physischen Kerne in der CPU viel kleiner sind als beim Testen des VNXe3200, mussten wir zunächst die Anzahl der Eingabe- / Ausgabeflüsse für jedes Worker-IOMETER erhöhen. Das Verhältnis von 1 Worker zu 1 CPU-Kern. Für jeden Worker wurden anfänglich 3 I / O-Streams mit einem "Multiplikator" von 2 festgelegt. Mit jedem weiteren Durchlauf (15 Minuten) des Tests im Zyklus wurde die Anzahl der Durchläufe um das Zweifache erhöht. Es fließen nur 5 aufeinanderfolgende Läufe und dementsprechend auf Worker am 3/6/12/24/48 IO. Im Allgemeinen hat die Testdatei Streams vom 24.12.48.96.192 empfangen. Das heißt Das Maximum ist das gleiche wie beim VNXe3200. Die Zeit für jeden Test beträgt 15x5 = 75 Minuten, wobei die „Rump-up-Zeit“ nicht berücksichtigt wird.



    Der VNX5400 hatte bereits einen Festplatten-FastVP-Pool mit den Monden, auf denen die Betriebssysteme installiert waren, sodass ich nicht damit begann, alles zu erfinden und neu zu erstellen. Der Pool umfasste 3 100-Gbit-SSD-Festplatten (Extreme Perfomance Tier) und 15 900-Gbit-SAS-Festplatten mit 10.000 U / min in Raid5 4 + 1 (Perfomance Tier), d. H. 3 private (für den Benutzer nicht sichtbare) Schlachtzugsgruppen in 4 + 1-Konfiguration. Für den Pool wurden Testmonde mit der Richtlinie "Niedrigstes verfügbares Tier" erstellt, sodass sich diese Monde vollständig auf SAS-Datenträgern befanden und SSD-Datenträger von Extreme Perfomance Tier die Ergebnisse nicht beeinträchtigten.





    Der Server verwendete das Betriebssystem Win2012R2 SP1 und die Software, um PowerPath Moon-Pfade von EMC 2 aus zu verwalten .

    Einige Berechnungen.


    EMV 2Bei der Berechnung der Leistung wird empfohlen, dass SAS-Festplatten mit 10.000 U / min einen Wert von 150 IOPS verwenden (FC / SAS mit 15.000 U / min - 180 IOPS, SATA / NL_SAS - 90 IOPS, SSD eMLS - 3500 IOPS, SSD SLC - 5000 IOPS). Das heißt, so viel wie theoretisch möglich können unsere 15 Festplatten 150 x 15 = 2250 IOPS liefern. Wir müssen berechnen, wie viele IOPS von diesen Serverfestplatten abgerufen werden, und dabei unser Lese- / Schreiblastprofil in Prozent von 67/33 und den Schreibaufwand für RAID5 berücksichtigen. Wir erhalten die folgende Gleichung mit einem unbekannten 2250 = X * 0,33 * 4 + X * 0,67. Wobei X unser IOPS ist, das den Server von unseren Festplatten empfängt, und 4 die Größe der "Strafe" im Datensatz für Raid5 ist. Als Ergebnis erhalten wir X = 2250 / 1,99 = ~ 1130 IOPS. Ich möchte Sie daran erinnern, dass wir in der Praxis bei Spitzenlasten in der Regel IOPS-Werte erhalten, die 1,5 bis 2 Mal höher sind.

    Tests und Ergebnisse


    1. Test des Betriebs von Cache-Controllern (SP - Speicherprozessor) VNX5400-Datei 2 GB


    Dieser Test wurde mit einer 2-GB-Datei durchgeführt (die Größe der Test-LUN mit NTFS beträgt 10 GB), sodass sie vollständig in den SP-Cache passt und alle Ein- / Ausgaben vom RAM der Speichercontroller verarbeitet werden. Das heißt, bedingt erschien ein kleiner "heißer" Datenbereich auf dem Array. Gleichzeitig wurde FastCache auf dem Array deaktiviert.
    Infolgedessen wurde im in das Array integrierten Unisphere Analyzer das folgende Diagramm angezeigt.



    In diesem Fall wurde der SP-Cache wie folgt gefüllt (der Cache funktioniert sowohl zum Lesen als auch zum Schreiben):



    Das heißt, innerhalb weniger Minuten nach Beginn des Tests wurden alle 2 GB der Testdatei in den Cache geladen.

    Das Diagramm der Abhängigkeit des durchschnittlichen IOPS von der Anzahl der Eingabe- / Ausgabeströme gemäß den Ergebnissen in IOMETER:



    Diagramm der Abhängigkeit der Durchschnittswerte der E / A-Antwortzeit von der Anzahl der E / A-Ströme gemäß den Ergebnissen in IOMETER: Ich



    erinnere mich, dass allgemein anerkannt ist, dass die durchschnittliche Antwortzeit für Datenbanken von bis zu 10 ms als angenehm angesehen wird. Laut Grafik haben wir mit 192 IO-Streams, was ein ziemlich großer Wert ist, eine etwas geringere durchschnittliche Antwortzeit als im ähnlichen Test auf dem VNXe3200 (es waren 8 ms). In absoluten Zahlen ist der Unterschied nicht signifikant, aber dennoch einer der Gründe für die große Lücke in der Anzahl der IOPS. VNXe3200 hatte in einem ähnlichen Test einen Durchschnitt von 23800 IOPS auf 192 IO-Threads. Wenn wir die prozentuale Differenz für die Antwortzeit und für IOPS berechnen, erhalten wir dort und dort ungefähr die gleichen 20-25%.

    2. Test des Betriebs von Cache-Controllern (SP - Speicherprozessor) VNX5400-Datei 15 GB


    Der Test wurde mit einer 15 GB großen Datei (LUN mit NTFS - 20 GB) durchgeführt. FastCache ist noch ausgeschaltet. Die Größe des Arbeitsspeichers im SP des VNX5400 beträgt 16 GB. Wenn Sie sich jedoch auf die Protokolle des Arrays verlassen, beträgt der für das Caching verwendete Arbeitsspeicher beim VNX5400 ungefähr 4 GB. Alles andere wird anscheinend verwendet, um den Betrieb der grundlegendsten Betriebssystem-Controller und anderer, recht umfangreicher Speicherfunktionen (Tiering, Thin Provisioning, Snapshots, Klonen, Replikation, schneller Cache usw.) sicherzustellen.



    Daher passen unsere 15 GB hoch geladenen (heißen) Daten nicht in den SP-Cache. Im Allgemeinen ist genau dies in der Grafik von Unisphere Analizer sichtbar. Vollständig zufällige Eingabe / Ausgabe für alle 15 GB kann von Controllern nicht vollständig zwischengespeichert werden. Aus diesem Grund liefern physische Spindeln in diesem Test den Hauptteil der Leistung, d.h. fährt direkt.



    Gleichzeitig arbeitet SP Cache weiter, wenn auch nicht so effizient.



    Diagramm der Abhängigkeit des durchschnittlichen IOPS von der Anzahl der Eingabe- / Ausgabeströme gemäß den Ergebnissen in IOMETER:



    Diagramm des Durchschnittswerts der E / A-Antwortzeit von der Anzahl der Eingabe- / Ausgabeströme gemäß den Ergebnissen in IOMETER:



    Gemäß dem Diagramm beträgt die Antwortzeit bereits bei 24 Strömen ungefähr 14 ms, d. H. ging über die Komfortzone hinaus. Ich war auch überrascht, dass ich bei der Schätzung der Spitzenleistung des Datenträgers so viel versäumt habe, und ging, um das Problem zu lösen. Als Ergebnis stellte ich fest, dass während des Tests nicht alle privaten RGs in der Leistungsstufe gleich belastet wurden. Das heißt Aus Leistungsgründen ist unsere Testdatei nicht gleichmäßig auf alle drei RGs in der Leistungsstufe verteilt. In der Grafik sieht es so aus (Laufwerke 5, 6 und 7 sind SSDs von Extreme Perfomance Tier).



    Das heißt, nicht alle 15 Spindeln waren am „vollständigen“ Test beteiligt. Um einen ähnlichen Effekt in FastVP-Pools auf VNX2-Arrays auszugleichen, gibt es eine Technologie, mit der Sie "heiße" und "kalte" Daten nicht nur zwischen Festplatten mit unterschiedlichen Kapazitäten (SSD, SAS, NL_SAS), sondern auch zwischen privaten RGs innerhalb derselben Ebene umverteilen können. Die Umverteilung von Daten zwischen privaten RGs erfolgt planmäßig zur gleichen Zeit wie die Migration von Daten zwischen Tiers. In der Array-Oberfläche ist dies in den Pool-Eigenschaften auf der Registerkarte Tiering zu sehen. Insbesondere sah es in meinem Fall direkt nach dem Test wie folgt aus.



    Ich möchte Sie daran erinnern, dass das Fenster so aussah, als das Array inaktiv war.



    Ein weiteres interessantes Bild ergibt sich aus der Überlagerung der Diagramme zum Füllen des SP-Cache und der Gesamtleistung der getesteten LUN.



    Die Grafik zeigt, dass Sie mit SP Cache auch in einer eher unangenehmen Situation "zusätzliche" IOPS gewinnen können.

    3. Testen Sie FastCache in der VNX5400-Datei 15 GB


    Nach dem Aktivieren von FastCache auf dem Array (zwei 100-Gbit-SSDs in Raid1) wurde ein Test für dieselbe Datei in 15 Gbit (LUN mit NTFS-20 Gbit) durchgeführt. FastCache in EMC 2- Arrays ist eine zusätzliche Cache-Ebene, die auf SSD-Datenträgern basiert und zwischen SP Cache und den Array-Datenträgern selbst integriert ist. Eine Datei mit 15 GB (oder dem bedingt "heißen" Datenbereich) sollte vollständig in 100 GB FastCache passen, was die Ergebnisse des vorherigen Tests verbessern sollte.
    Erhalten Sie die folgende Grafik von Unisphere Analizer (in IOPS).



    FastCache wurde wie folgt ausgefüllt (in%).



    Read Hits / s - Leseoperationen, die mit FastCache ausgeführt wurden.
    Read Misses / s - Operationen, für die keine Daten in FastCache gefunden und von Array-Festplatten angefordert wurden.



    Schreibzugriffe / s - Schreibvorgänge in FastCache, bei denen keine vorläufigen Sicherungskopien "veralteter" Daten auf Datenträgern (vorläufiges Löschen des Cachespeichers) erstellt wurden, oder Vorgänge, bei denen Daten angefordert wurden, die in den Cache geschrieben, aber noch nicht auf Datenträger übertragen wurden.
    Write Misses / s - Schreibvorgänge, die nicht über FastCache ausgeführt wurden oder eine erzwungene (Notfall-) Freigabe des Cache-Speichers erfordern.



    SP Cache stand auch nicht im Leerlauf und arbeitete einen Teil der Eingabe / Ausgabe aus.



    Auf der Serverseite sah IOMETR folgendermaßen aus.
    Diagramm der Abhängigkeit des durchschnittlichen IOPS von der Anzahl der Eingabe- / Ausgabeströme gemäß den Ergebnissen in IOMETER:



    Diagramm des Durchschnittswerts der E / A-Antwortzeit von der Anzahl der Eingabe- / Ausgabeströme gemäß den Ergebnissen in IOMETER:



    Das neueste Diagramm zeigt, dass nach dem Laden des "heißen" Bereichs in FastCache die Antwortzeit sogar abnimmt und erst mit zunehmenden Eingabe- / Ausgabeströmen zu wachsen beginnt. Gleichzeitig "durchbricht" der Graph die Obergrenze von 10 ms weit über dem Wert von 100 IO-Streams.

    4. Testen Sie FastCache in der VNX5400-Datei 150 GB


    Der nächste Test wurde mit einer 150-GB-Datei durchgeführt (Test-LUN mit NTFS 200 GB). Das heißt Unser "heißer" Datenbereich in diesem Test hat die FastCache-Größe des Arrays um das 1,5-fache überschritten. Die folgenden Ergebnisse wurden erhalten.
    Grafik von Unisphere Analizer (in IOPS).



    Das Füllen von FastCache mit Daten ging voran, aber ziemlich langsam. Am Ende des 75-minütigen Tests waren ungefähr 20% gefüllt (ungefähr 20 GB aus der 150-GB-Testdatei).



    Diagramme von Treffern und nicht Treffern von Lesevorgängen in FastCache.



    Diagramme Treffer / s und Fehler / s für Schreibvorgänge in FastCache.



    SP Cache war auch nicht inaktiv.



    Wie es von der Serverseite und IOMETR aussah.
    Das Diagramm der Abhängigkeit des durchschnittlichen IOPS von der Anzahl der Eingabe- / Ausgabeströme gemäß den Ergebnissen in IOMETER:



    Diagramm der Abhängigkeit der durchschnittlichen E / A-Antwortzeiten von der Anzahl der E / A-Streams gemäß den Ergebnissen in IOMETER:



    Die Diagramme zeigen, dass die IOPS geringfügig höher sind als beim Testen einer Datei mit 15 Gb ohne FastCache. Wir können also den Schluss ziehen, dass FastCache in dieser unangenehmen Situation dazu beiträgt, zusätzliche IOPS aus der Konfiguration zu entfernen. In der Praxis stellte sich jedoch heraus, dass dies nicht der Fall war.

    Zunächst wurden in diesem Test alle privaten Raid-Gruppen (Raid5 4 + 1) im "Perfomance Tier" gleichmäßiger geladen.



    Zweitens habe ich beschlossen, einen zusätzlichen Test mit einer 150-GB-Datei durchzuführen, aber FastCache wurde deaktiviert. Ich werde es nicht im Detail malen, hier sind die Grafiken von IOMETR (ich habe es zuerst nicht geglaubt und den Test zweimal durchgeführt).

    Diagramm der Abhängigkeit des durchschnittlichen IOPS von der Anzahl der Eingabe- / Ausgabeströme gemäß den Ergebnissen in IOMETER:



    Diagramm des Durchschnittswerts der E / A-Antwortzeit von der Anzahl der Eingabe- / Ausgabeströme gemäß den Ergebnissen in IOMETER:



    Das heißt, in einer Situation, in der die Menge der aktuellen Daten die Größe von FastCache überschreitet und ein hoher Prozentsatz zufälliger Anforderungen vorliegt, dauert das Befüllen von FastCache einige Zeit. In solchen Situationen führt FastCache eine kleine, aber dennoch zusätzliche Verzögerung der Reaktionszeit ein. In dieser Situation können Sie die Verwendung eines zusätzlichen Extreme Performance Tier für SSD-Festplatten im Pool vorschlagen. In diesem Fall „siedelt“ sich ein Teil der aktuellen Daten an und wird nicht über FastCache verarbeitet. Dementsprechend sinkt das über FastCache verarbeitete Datenvolumen und liegt in einem angenehmeren Bereich. Um nicht unbegründet zu sein, habe ich einen weiteren Test durchgeführt.

    5. Testen Sie FastCache in der VNX5400-Datei 80 GB


    Dieser Test wurde an einer Datei mit einer Größe von 80 GB (Test LUN mit NTFS 100 GB) durchgeführt, die nahe genug am FastCache-Volume im getesteten Array liegt. Das heißt, der "heiße" Datenbereich war ziemlich groß, passte aber trotzdem vollständig in FastCache.
    Grafik von Unisphere Analizer (in IOPS).



    FastCache füllte sich aktiver als bei einer 150-GB-Datei.



    SP Cache hat auch einen Teil der Ein- / Ausgabe erledigt.



    Von der Serverseite und IOMETR sah alles viel rosiger aus als bei einer 150-GB-Datei.
    Diagramm der Abhängigkeit des durchschnittlichen IOPS von der Anzahl der Eingabe- / Ausgabeströme gemäß den Ergebnissen in IOMETER:



    Diagramm des Durchschnittswerts der E / A-Antwortzeit von der Anzahl der Eingabe- / Ausgabeströme gemäß den Ergebnissen in IOMETER:



    Beginnend mit ungefähr 24 E / A-Streams (ungefähr 15 Minuten nach Beginn des Tests) kamen zunehmend Daten in FastCache an. Dementsprechend begann auch die Gesamtleistung im Test zu wachsen, während die Antwortzeit mit zunehmenden IO-Streams nicht so stark anstieg wie im Test mit einer 150-Gb-Datei.

    Ein kleiner Exkurs über Plattenpools


    Unter dem Spoiler
    Wenn Sie beim Entwerfen eines Festplattenpools die tatsächliche Größe des Hot-and-Warm-Datenbereichs nicht kennen, empfiehlt EMC, die folgenden Proportionen für den Pool mit drei Ebenen beizubehalten:
    10% - SSD-Laufwerke
    20% - SAS-Laufwerke
    70% - NL-SAS-Laufwerke
    Zusätzlich Bitte beachten Sie, dass beim automatischen Hinzufügen einer Flash-Ebene zum Pool alle Metadaten der im Pool erstellten dünnen Monde auf der SSD abgelegt werden. Wenn genug Platz für sie ist. Auf diese Weise können Sie die Gesamtleistung von dünnen Monden und Pools steigern. Unter diesen Metadaten müssen Sie zusätzlichen Speicherplatz auf der SSD basierend auf dem 3Gb-Volumen für jede 1 TB einplanen, die wirklich von dünnen Monden im Pool belegt wird. Bei alledem haben Monde mit einer Kachelrichtlinie der "höchsten verfügbaren Stufe" Vorrang, wenn sie auf einem SSD-Dash gegenüber anderen Daten platziert werden.

    Die Verwendung der Richtlinie "Niedrigster verfügbarer Status" für dünne, deduplizierte oder komprimierte Monde führt dazu, dass deren Metadaten auf den langsamsten Datenträgern abgelegt werden. Was sich negativ auf die Leistung dieser Monde auswirkt.

    Damit das Zerreißen richtig funktioniert, benötigen Sie freien Platz im Pool. Es werden mindestens 10% des freien Speicherplatzes auf jedem Strich empfohlen. Andernfalls kann das System keine Datenblöcke zwischen verschiedenen Festplattentypen im Pool übertragen.


    Schlussfolgerungen


    Basierend auf den Tests können wir folgendes sagen. So seltsam es auch klingen mag, FastCache ist nicht immer gut. In einem nicht ordnungsgemäß ausgelegten System kann dies die Leistung beeinträchtigen, auch in Richtung einer Verschlechterung. Um dies in der Entwurfsphase nicht zu verpassen, ist es besser, eine Kopie oder einen Teil Ihrer tatsächlichen Lasten auf das Demo-Array zu übertragen. Ein Demo-Array kann vom Anbieter angefordert werden. Wenn dies nicht möglich ist, müssen Sie von den Verhältnissen für heiße / warme / kalte Daten ausgehen, die derselbe Anbieter für die Berechnungen vorschlägt (basierend auf statistischen Daten und einigen anderen Überlegungen). Die erste Option mit einem Demo-Array ist meiner Meinung nach vorzuziehen. Im Allgemeinen sorgt eine zusätzliche Cache-Ebene (FastCache) auf VNX2 bei einem ordnungsgemäß gestalteten Array für eine angemessene Leistungssteigerung.

    Die Leistung des VNX5400 übertrifft die Leistung des VNXe3200 zumindest in kleinen und vergleichbaren Konfigurationen (Anzahl der Festplatten, FastCache-Größe) nicht wesentlich. Vielleicht liegt das daran, dass das jüngere Array erst in diesem Jahr 2014 veröffentlicht wurde. Dieselben Schlussfolgerungen können für den VNX5200 gezogen werden, bei dem sich die SP (Controller) nicht vom VNX5400 unterscheiden (die Service-Teilenummer für den Austausch ist dieselbe). Der VNX5200 hat nur eine Beschränkung der maximalen Anzahl von Festplatten (125 Stk. Gegenüber 250 Stk. Beim VNX5400), eine Beschränkung der maximalen FastCache-Größe (600 Gb gegenüber 1000 Gb beim VNX5400) und einen Steckplatz weniger für eine zusätzliche Erweiterungskarte mit Anschlüssen für den Anschluss von Servern.

    Alle durchgeführten Tests sind „Kunststoffe“, die nichts mit Ihrer tatsächlichen Arbeitsbelastung zu tun haben. Meiner Meinung nach hilft eine solche Modellierung jedoch dabei, die allgemeinen Trends im Verhalten von Speichersystemen in bestimmten Situationen zu verstehen.

    Wie PS


    Wenn Sie Speicherplatz für das Laden von Streams benötigen (Nr: Aufzeichnen und Verarbeiten großer Videostreams), hilft Ihnen hier kein Cache. Es wird eine Zeit kommen, in der es überläuft und die Anzahl der Spindeln (Festplatten) in Ihrem Datenspeichersystem in dieser Situation entscheidet.
    Wenn Sie eine sehr hohe Transaktionslast haben. Bei einer großen OLTP-Datenbank oder VDI für Tausende oder Zehntausende von Benutzern benötigen Sie höchstwahrscheinlich ein All-Flash-Array anstelle eines klassischen Speichers und Tierings.

    Jetzt auch beliebt: