IBM Flashstorage Performance

Blubmann1337

Ensign
Registriert
Dez. 2009
Beiträge
241
Hallo zusammen,

wir haben zwei IBM Flashstorage 5200 mit "Fast"-Livereplikation gekauft und sind nach anfänglicher Euphorie etwas bedrückt. Die Performance ist für ein Flashsystem schlecht. Zur Konfiguration die Hauptstorage hängt mit jeweils 4 FC-Kabeln an zwei ESXi-Servern. Die Server sind ebenfalls neue Lenovo SR665. Die Storage hat drei FCM2-Module mit jeweils 19,2 TB im DRAID1-Verbund. Die Backupstorage ist an einem SR665 angeschlossen und hat ebenfalls drei FCM2-Module im DRAID1. Die Replikation läuft über 10 GBit-Richtfunk. Wenn wir keine Replikation aktiv haben kopieren wir eine 260GB große Datei mit 600MB/s innerhalb einer VM (finde ich persönlich für Flashmodule tatsächlich etwas wenig). Machen wir eine Livesynchronisation zur Backupstorage, dann müssen wir Glück haben, dass wir innerhalb einer VM mit 200MB/s kopieren. Nach guten 200 Tagen mit dem Support sind wir nun auf eine Replikation mit Intervallen und Änderungsdatenträgern (die Replikation wird nicht direkt auf die Backupstorage geschrieben, sondern zwischengespeichert) umgestiegen. Damit bekommen wir dann zwischen 400 und 200 MB/s hin, wenn wir innerhalb einer VM kopieren. Finde die Performance jetzt nicht berauschend und irgendwie ist das nicht zufriedenstellend, wenn ich überlege, dass eine alte v3700 mit HDDs und RAID6 schon teilweise mehr als 300MB/s beim kopieren gebracht hat. Grundsätzlich würde mich einfach mal interessieren, ob jemand von euch so ein IBM Flashsystem im Einsatz hat, ganz unabhängig mit oder ohne Replikation. Und welche Erfahrungen diejenigen damit gemacht haben.
 
FC ist ein Protokoll. Kein Kabel. Fibrechannel wird mal via Kupfer, mal via Glasfaser gemacht, sagt aber in jedem Fall nix über die Anbindungsgeschwindigkeit aus.

Wenn es 8 Gbit/s FC ist, dann klingen 600mb/s nicht falsch.
Die ist wenn ich das richtig sehe auf niedrige Latenzen und verdammt hohe IOPS ausgelegt, sprich wieder einmal optimal für Datenbanken.
Sollen die standalone bleiben oder wird das noch mehr? Vom Featureset her zielen die stark darauf, dass man ein ganzes Rack damit voll macht und auf verteiltes RAID setzt.
 
Tach,

Anbindung ist über Glasfaser mit 16 GBit/s. Aber selbst die Latenzen sind nicht berauschend für Flash, da sind wir laut Oberfläche teilweise bei Schreiblatenzen von 15 ms. Soll eigentlich Standalone bleiben.
 
was habt ihr sonst an FC infrastruktur?
Welche FC Karten stecken in den servern?
Welche FC Switche werden verwendet?

15ms ist da zu langsam.

Hmmm. Wie ist denn die latenz über die 10g strecke. Die 3 FCM laufen nicht lokal im DRAID, weil nur eine kiste pro RZ verbaut ist, sondern spiegeln über die Funkstrecke? Kann gut sein, dass das euer Problem ist.
Ich verstehe draid eigentlich eher so, dass es lokal zwischen n Storage Appliances super skaliert, aber halt darauf waertet, dass alles in sync ist.
Ich nehme an, die FUnkstrecke ist Fibrechannel over Ethernet?
 
Zuletzt bearbeitet:
Ja, das ist alles schon seltsam. Man bekommt schnell ziemliche Probleme....

Live Replikation ist halt auch immer so ne Sache....

Ich habe mittels DRBD aber schon aus zwei Systemen mit 40GBit verbunden über 2 GB/s rausgeholt. Und da hatte ich jetzt nur je eine U2 NVMe in jedem System...

Ist halt immer die Frage was man genau machen will/muss
 
  • Gefällt mir
Reaktionen: PHuV und madmax2010
madmax2010 schrieb:
was habt ihr sonst an FC infrastruktur?
Welche FC Karten stecken in den servern?
Welche FC Switche werden verwendet?
Ich habe das Ganze mal bisher ungefähr dokumentiert, bin aber noch dran, so sieht es aber jetzt aus. Die ein oder andere Frage wird damit vielleicht beantwortet. Welche Karten genau verbaut sind würde ich morgen schauen. Die beiden Switche sind jeweils ein HPE FlexFabric 5945. Storage und Server sind direkt verbunden.
Netzwerk.png


madmax2010 schrieb:
Die 3 FCM laufen nicht lokal im DRAID, weil nur eine kiste pro RZ verbaut ist, sondern spiegeln über die Funkstrecke?
Ne also die drei FCMs sind schon lokal, nur wird die Produktivumgebung in das Backup-RZ gespiegelt. Die DRAIDs sind aber sonst völlig unabhängig voneinander.
madmax2010 schrieb:
Ich nehme an, die FUnkstrecke ist Fibrechannel over Ethernet?
Muss ich schauen
redjack1000 schrieb:
Ok das ist Brutto, was geht Netto über die Richtfunkstrecke?
Muss ich ebenfalls schauen
 
Noch ne Sache Allgemein zu eurer Erfahrung mit Flash. Flash bringt hauptsächlich etwas für IOPs, aber nicht für Bandbreite im Vergleich zu HDDs. Wenn ihr dann auch noch nen HWRaid Controller hattet mit Write Cache, dann wird der Unterschied noch kleiner so lange man im Cache bleibt.

Ich kenne es selbst, das Leute von nem HWRaid auf ZFS umgestiegen sind, weil die Bandbreite ja viel höher ist die man mit ZFS bekommt, sich dann aber gewundert haben warum die Produktion so langsam ist. Die hatte halt viele synchrone writes, was die Benchmarks halt nicht gezeigt haben.

Wenn du von eurem Problem mit großen Dateien sprichst, dann ist die sequenzielle Performance relevant und da solltest du keinen Unterschied zwischen HDD und Flash sehen.

Euer Problem ist die Richtfunkstrecke. Ich weiß blöd die Replikation zu stoppen. Aber ihr solltet das Ding mit Perf mal durchmessen, was da wirklich drüber geht über nen Zeitraum von 24h.

Keine Ahnung ob Kabel unmöglich ist, aber ich würde es wirklich mal ins Auge fassen. Die Kosten sind hoch, aber die Büchsen die ihr euch da hinstellt sind ja auch nicht billig.

Was mich nur wundert sind die 600MB/s ohne Geo Replikation. Das sollte eigentlich schon allein mit active-passive mehr sein. Soweit ich das gesehen habe sollte das ja 16GBit/s FC sein oder sogar 32GBit/s FC

Ist da noch massiv anderes Zeug parallel gelaufen oder wie muss man sich das vorstellen?

Ich fürchte bei 200Tagen Betrieb seid ihr schon in Produktion, oder läuft noch Parallelbetrieb? Wenn ja, kann ich nur sagen macht das Paket nochmal komplett auf und macht saubere Low Level Benchmarks und schaut, dass die das liefern was ihr erwartet/vereinbart habt. Ansonsten werdet Ihr da nicht mehr glücklich mit.

Wenn Produktion schon läuft, dann mein Beileid. Das werdet ihr kaum noch aufgedröselt bekommen, sofern es nicht einfach am Richtfunk liegt, was ich aber an sich ausschließen würde.

Btw IOR ist dein Freund. ;)
 
Live Replikation also synchrones Spiegeln über Richtfunk? Wie sind die Latenzen und allgemeinen Leitungswerte? Wird hier nur Storage drüber gespiegelt oder noch andere Redundanzen mit abgedeckt?

Das ganze Konstrukt synchron zu spiegeln mit aktiven Storage über Richtfunk, der hier zwei mal pro IO ins Spiel kommt, finde ich komisch und habe ich so noch nie gesehen. Ich kenne Richtfunk als sehr wackelige Technik, einige unserer Aussenstandorte verlieren da schnell die IP Verbindung.

Kann mir aber auch nicht vorstellen, dass das nach 200 Tagen Support nicht ausgiebig geprüft wurde.

Ist das gängig? Ich könnte mir über Richtfunk eine Replikation von Archivsystemen etc vorstellen aber nicht mit aktivem Storage.
 
Zuletzt bearbeitet:
@Skysnake Massiver Parallelbetrieb kann ich ausschließen, das Kopieren haben wir früh morgens durchgeführt, als das Backup bereits durch war und keine Mitarbeiter vor Ort. Und genau das Ding steht auch schon Produktiv. Ein Kabel ist aktuell unmöglich, da die Standorte gute 10km auseinander liegen. Und genau diese 600MB/s wundern mich halt auch, vielleicht ist die Erwartung auch zu hoch, aber irgendwie finde ich das zu wenig, aber vermutlich ist genau hier das eigentliche Problem. Vielleicht liegt das auch an diesem DRAID1 und es müssen mehr Platten rein, damit man ein DRAID6 machen kann.

@DEADBEEF Genau, synochron, wobei wir das bereits nicht mehr nutzen, da laut Support bereits eine geringe Latenz oder ein kleiner Paketverlust von 0,05% zu unerwünschten Effekten führt. Deshalb haben wir das nun asynchron eingerichtet und die Änderungen werden auf ein Volume per Flashcopy "gecached". Die Richtfunkstrecke ist in einem VLAN und wird exklusiv für die Replikation verwendet, da läuft definitiv nix anderes drüber.

Das interessante an der ganzen Sache ist aber, das habe ich vergessen zu erwähnen, wir haben die beiden Storages bereits direkt miteinander verbunden gehabt über 100GBit Ethernet und die Live-Replikation dort drüber laufen lassen. Da hatte lustiger bzw. traurigerweise die gleichen Effekt mit der Replikation. Auch ist die Firmware teilweise echt buggy, wodurch wir bereits 4 oder 5 Firmwareupdates gemacht haben.
Es wäre einfach interessant, ob es jemanden gibt der ebenfalls so ein Produkt von IBM nutzt oder eine FS7200 bzw. FS9200 und Erfahrungen damit hat, weil entweder wir machen irgendwas grundlegend falsch, die Erwartungen sind zu hoch oder IBM hat ihr Produkt nicht unter Kontrolle. Ich mache nun aber nochmal ein paar Messungen über den Richtfunk, vielleicht werde ich dann draus schlau. Aber vielleicht springt auch einfach mal eine Exkursion zu IBM nach Böblingen raus, um dort so ein Teil nochmal im Testaufbau zu sehen und die Performance zu testen
 
Hmm... auch mit direkter 100G Verbindung?

Autsch, das hört sich überhaupt nicht gut an. Ich befürchte auch aufgrund des Produktionsbetriebs, das IBM schon ne acceptance hat und damit auch ihr Geld. Damit habt ihr ein wichtiges Druckmittel weniger.

Das IBM das Ding nicht unter Kontrolle hat würde ich nicht sagen, aber die Servicemitarbeitet die aktuell daran arbeiten definitiv nicht würde ich mal sagen. Wie weit ist das denn schon eskaliert worden? Hängt ihr noch im normalen L1 Support, oder ist das in Richtung L2 bzw L3 eskaliert worden? Und habt ihr mal euren Sales angehauen und euren Unmut über die Situation ausgedrückt?

Wenn ihr jetzt schon zick Firmware Updates habt laufen lassen sieht das auch nicht gut aus. Leider ist qualifiziertes Personal zur Zeit schwer zu bekommen...

Die Frage ist halt auch, wie euer Vertrag aussieht. Was habt ihr an Anforderungen und SLAs reingeschrieben.? Ich befürchte halt keine IOR Werte etc die zu erreichen sind. Ihr solltet da also auch definitiv auf die ausschreibende/beschaffende Stelle zugehen und die mit ins Boot holen. Damit kann man zumindest für die Zukunft die Probleme reduzieren.

An sich hilft nur eins. Die Büchsen aus der Produktion nehmen und low level Performancetests machen. Alles andere wird euch nicht sicher zu einem Ergebnis führen.

Klingt hart, aber da spreche ich aus leidiger Erfahrung. Debuggen unter Produktion ist ein Krampf und hat nur eine sehr bedingte Aussagekraft.

Wegen dem DRAID1. Das wird am Ende auch nur Replikation sein. Das heißt ihr fällt je nachdem auf die Performance einer Platte zurück. Kannst du mal noch sagen was das für Platten sind, wie sie angeschlossen sind und wie viele das sind?
Ergänzung ()

Adding DRAID 1 support provides the ability to establish DRAID mirroring to smaller numbers of drives than with other levels of DRAID, reducing the minimum cost requirements to implement DRAID in a system. Traditional RAID 1 writes to one drive from the host but can read from both. Distributing the primary data between the drives in DRAID allows both reading and writing to both drives, improving overall performance in both I/O operations and during rebuilds. DRAID 1 supports a minimum of two drives, with no requirement to establish a rebuild area in two-drive configurations. Two-drive configurations are limited to SCM devices and flash drives, where the cost of additional devices can make DRAID 6 impractical in some instances.
Im Prinzip sollte ich recht haben.

Und wenn ihr jetzt SAS12 SSDs da drin habt, die ja wegen ha im Multiport laufen, dann ist das eben die Performance von nem halben SAS12 Port.....

Mir schwant da irgendwie übles....
 
Wie sind denn die Hosts und VMs genau angebunden? NPIV oder Host mapping? Ich kenne mich leider nur mit Brocade/Broadcom SAN-Switches aus, habt ihr schon das gesamte Zoning analysiert? Da passieren eigentlich oft Fehler, vor allem wenn einmal der Wurm drin ist. SFPs brennen auch gerne durch und verursachen alle möglichen Fehler. Jeden verwendeten Port auf CRC Fehler prüfen und ggfs die Module tauschen.
 
Ich stell ne ganz dumme Frage:
Kann es sein dass der Copy Job in der VM an einem CPU oder IO Limit hängt, der Storage aber noch Luft nach oben hat? Sprich ob der Hypervisor da irgendwie nicht mehr zulässt.
 
@Skysnake Liegt bereits bei L3. Aber die sind sich auch nicht so sicher, aktuell vermuten Sie ein Problem mit der Richtfunkstrecke, wobei das nicht das recht langsame ohne Replikationsbetrieb erklärt. Aber bin da voll hinten dran, also ich lass mich da nicht abschüttelt, bis es eine passende Lösung gibt.
Platten sind IMB FCMs verbaut, das ist Flashspeichermodule mit PCI-Express-Anbindung. Davon sind drei Stück jeweils in den Storages verbaut im DRAID1. Sprich eine als Ausfallsicherheit und eine zusätzlich als Hot-Spare.

@DEADBEEF Sind per Hostmapping angebunden und Direct Attached. Gibt also keine SAN-Switches dazwischen. Ports sind geprüft, die passen.

@Sannyboy111985 Der Gedanke kam mir auch mal zwischendurch. Installiert ist ein ESXi 7 mit aktuellstem Update. Sowohl auf den Servern als auch die Appliance. Wie könnte ich das sinnvoll testen, ob es daran hängt?
 
Das müssten dann wohl U2 SSDs sein. Mit active passive wären das also maximal 2GB/s Write und 4 GB/s read. Mehr könnt ihr nicht sehen, wenn ihr tatsächlich nur 3 Platten im System habt und davon eine als Hotspare und den Rest als DRAID1.

Also bei so nem kleinen System frage ich mich schon ernsthaft nach dem Warum. Da wäre ne DRBD meiner Meinung nach echt nen Blick wert gewesen.

Die 600MB/s sind also etwas mehr als 25% von Peak. Für ne VM finde ich das gar nicht so schlecht. Klar bei nem simplen CP würde ich mir schon 1.5GB/s erhoffen, aber wer weiß wie das skaliert.

Was ich glaub ich schon mal gesagt habe wäre halt nen Test mit Fio oder IOR. Also sowohl kleine writes als auch große. Single als auch multistream.

Ich habe so ein bißchen den Verdacht, das ein Stream hakt nicht mehr als 600MB/s packt. Das könnte durchaus sein von Gefühl her.

Das Ding sollte ja ähnlich zu den FAS Systemen von NetApp sein.

Also ich will dir jetzt keine Angst machen, aber ich befürchte mehr wird es wohl nicht werden.

was wurde euch h den Versprochen/verkauft?

Auf meine Frage bezüglich acceptance Tests bist du ja leider nicht eingegangen. Ich befürchte aber nichts gutes. Daher sollte man wohl davon ausgehen, das es so nicht mehr s schneller wird.
 
Also zum Testen gibt es wohl von VMware HCIbench https://www.thomas-krenn.com/de/wiki/Datastore_Performancemessung_unter_VMware_vSphere

Oder alternativ mit einem Linux sowas wie bonnie++ oder fio
Unter Windows Ggf auch crystal disk mark.

Wichtig wäre, dass du weist wie man performance Daten und bottle necks beim jeweiligen OS erkennen kannst.

Sorry bin gerade etwas kurz angebunden.

Mit so wenig Platten, kann es sein dass der Storage selbst gar nicht mehr kann da der auf mehr Platten ausgelelgt ist.

Was sagen denn die Auslastung des Storage, disk busy, latency, cpu.
Und bitte für Front und Backend angeben.
 
Ich habe mir mal HCIBench angeschaut, aber bin nicht wirklich schlau draus geworden wie die Werte zu interpretieren sind.
Meine Konfig war wie folgt:

9 VMs, 4CPUs, 8GB RAM, 8 Data Disks mit jeweils 10 GiB.


Als Workloadparameter habe ich folgende Einstellungen:

8 Disk to test, 100% Working-Set, 8 Threads, 8k-Blöcke, 100%Read, 0% Random, 100 Test Time, quasi so wie im Link beschrieben


Ergebnisse sind wir folgt:

Datastore: Storage-A
=============================
Version: vdbench50407
Run Def: RD=run1;
I/O rate: Uncontrolled MAX;
elapsed=100;
For loops: None
Number of VMs: 3
I/O per Second: 1228706.4 IO/S
Throughput: 9599.27 MB/s
Latency: 0.17 ms
Read Latency: 0.17 ms
Write Latency: 0.0 ms
95th Percentile Latency: 0.56 ms
=============================

Datastore: Storage-B
=============================
Version: vdbench50407
Run Def: RD=run1;
I/O rate: Uncontrolled MAX;
elapsed=100;
For loops: None
Number of VMs: 3
I/O per Second: 1273246.6 IO/S
Throughput: 9947.24 MB/s
Latency: 0.17 ms
Read Latency: 0.17 ms
Write Latency: 0.0 ms
95th Percentile Latency: 0.57 ms
=============================

Datastore: Storage-C
=============================
Version: vdbench50407
Run Def: RD=run1;
I/O rate: Uncontrolled MAX;
elapsed=100; For loops: None
Number of VMs: 3
I/O per Second: 1246543.4 IO/S
Throughput: 9738.62 MB/s
Latency: 0.17 ms
Read Latency: 0.17 ms
Write Latency: 0.0 ms
95th Percentile Latency: 0.61 ms
=============================

1652792981507.png

1652793004473.png


Währenddessen war ich mal auf der Storage im Frontend (backend muss ich erstmal schauen wie ich da an Performancedaten komme). Hier hatte ich in der Spitze 28% CPU-Last. Bei den verwalteten Platten hatte ich eine maximale Latenz beim schreiben von 0,6ms und beim lesen von 0,4ms. Die Datenträger-Latenz war beim Schreiben maximal 1,4ms und lesen 0,7ms. Sieht für mich eigentlich gar nicht so schlecht aus.
 
Die Grafana Screens (Graphen) kommen direkt aus dem HCI?
Wenn es ne eigne Instanz ist bzw. du dich damit aukennst bzw. auseinander setzen magst, kannst du schauen ob du das Dashboard ans laufen bekommst.

Was da steht ist erstmal 3x 1,2 Mio IOPS und 3x 9,7GB/s.
Das wird sehr vermutlich im RAM gelaufen sein, wie @Skysnake sagte.
Versuch mal 50GB oder besser 100GB.
Was der Test gemacht war 9 VMs *8 Disks * 8 Threads zu nutzen was 576 paralle Operationen sind. Für Sowas ist FC Storage gebaut ;) Wenn du über Windwos kopierst hast womöglich nur 1 Thread.

Wenn du auf den Stroage Frontend schaust, wieviel Throughput war denn dort zu sehen während des Tests?
 
Zurück
Oben