So beheben Sie Performance-Probleme bei Flash-Storage

Im Rennen um die beste Geschwindigkeit bei Speichersystemen in verdichteter Bauweise erfreut sich Flash-Storage bester Nutzer-Akzeptanz. Besonders in Rechenzentren, die auf Server-Virtualisierung setzen, hat Flash wegen des überragenden Gewinns an Geschwindigkeit überzeugen können.

Es ist heute kaum mehr überraschend, dass Systemadministratoren in Rechenzentren auf Storage-Arrays setzen, die auf Solid-State-Drives (SSDs) und proprietären Flash-Lösungen basieren.

Dabei ist NAND-Flash seit mehr als zehn Jahren eine der Hauptkomponenten von Speichersystemen. Es erfreute sich von Anfang an einer breiten Akzeptanz beim Einsatz in schnellen USB-Speichern. Diese Schnelligkeit ist auch ein wichtiger Faktor bei modernen Datenreduktionstechniken wie etwa der Inline-Deduplikation, Inline-Kompression und einigen Server-Virtualisierungstechniken beispielsweise VAAI. Diese Technologien, in Kombination mit der Geschwindigkeit, trugen dazu bei, dass Flash-basierter Speicher schnellere, zuverlässigere und vielseitigere Storage-Systeme auf handelsüblichen Komponenten ermöglicht.

In diesem Beitrag lesen Sie, welche Fragen wichtig für die Behandlung von Performance-Problemen bei Flash-Speichern sind:

• Was bedeutet Performance bei Flash-Speichern?

• Wie wird die Leistung gemessen und welches sind die wichtigsten Eckpunkte?

• Wie werden Performance-Probleme gelöst? Wie ermittelt man, ob die Gründe für die Leistungseinbußen beim Speicher liegen oder etwa eher bei der Netzwerkanbindung des Storage Area Networks (SAN) beziehungsweise Network Attached Storage (NAS) oder einem Problem beim Server oder Hypervisor?

Was bedeutet Storage-Performance?

In einfachen Worten bedeutet schnellere Performance, dass im Vergleich zum vorher genutzten System mehr Daten zwischen Server und Speicher in immer weniger Zeit transportiert werden. In Zeiten, als hauptsächlich rotierende Festplatten genutzt wurden, war die Zugriffszeit auf gespeicherte Daten durch die Anzahl der verwendeten Festplatten begrenzt. Um eine höhere Rate an IOPS (Input/Output Operations per Second) zu erzielen, mussten zusätzliche Festplatten angeschafft werden, was meist ungenutzte Kapazität zur Folge hatte.

Flash-Speicher hat diese Situation komplett verändert. Nun können Administratoren auch kompaktere Einheiten mit kleinerer Kapazität verwenden und erzielen gleichzeitig eine stattliche Rate an IOPS. Außerdem bieten Flash-Speicher Funktionen zur Datenreduzierung wie etwa der Inline-Deduplizierung und -Kompression bei einer Lebensdauer von mehr als fünf Jahren für jedes Storage Array. Folgende Parameter kommen beim Flash-Speicher zum Tragen:

Leistungsparameter von Flash-Storage

Datenblätter für Flash-Speicher-Arrays enthalten üblicherweise diese Angaben für jeden Controller:

1. Anzahl der CPU-Kerne und -Sockel sowie deren Taktung

2. Anzahl der dynamischen RAMSs (DRAMs) auf dem Controller

3. Anzahl und Beschaffenheit der IO-Anschlüsse (zum Beispiel 16 Gbps FC, 10GbE Ethernet)

4. Anzahl der SSDs im Gehäuse sowie die Kapazität der SSDs (so genannte RAW Terabytes, entspricht der unformatierten Kapazität)

5. Anzahl der SSD Shelves, die der Controller verwalten kann (RAW Terabytes insgesamt)

6. IO-Operationen pro Sekunde für eine Blockgröße von 32K bei einem 70/30- oder 80/20-Schreib-/Lese-Verhältnis (üblicherweise mit einer Latenz von unter einer Millisekunde)

Einige Hersteller veröffentlichen diese Leistungsdaten in ihren Datenblättern nicht.

7. Datenreduktion, die durch Deduplizierung und Kompression erzielt wird. Sie liegt meist zwischen 3:1 to 5:1 (jeweils bezogen auf ein Dataset).

Ein weiterer wichtiger Faktor, um die Performance sichtbar zu steigern, liegt in den einzelnen Anwendungen: Sie benötigen weniger CPU-Zyklen um auf Flash-Speicher zuzugreifen. Dies kommt dort zugute, wo die Lizensierung von Software aufgrund CPU-Kernen oder -Sockeln erfolgt. Damit können Nutzer ihre Anwendungen auf weniger Prozessorkernen laufen lassen und schonen so ihr Budget. Die Summe, die durch die Verwendung weniger Kerne eingespart wird, kann man nun in schnelleren Flash-Speicher investieren.

Von diesen Parametern, die die Leistung ausdrücken, sieht man folgende auf den Dashboards sämtlicher Flash Arrays:

1. Block-Größe (zum Beispiel 32k):

Dieser Parameter variiert je nach Anwendung

2. IOPS:

(Input/Output Operations per second)

3. Latenz:

Dieser Wert wird üblicherweise in Mikro- oder Millisekunden gemessen (die durchschnittliche Übertragungszeit, um einen IO-Block zu lesen oder zu schreiben)

4. Bandbreite / Durchsatz (errechnet aus Blockgröße und IOPS):

IOPS x IO-Größe = Bandbreite

Die Bandbreite wird in Megabytes oder Megabits pro Sekunde gemessen.

Aus welchen Gründen überbietet Flash Storage traditionelle Speichersysteme?

Die Lebensdauer von NAND ist wesentlich geringer als die des Vorgängers, der beweglichen Disk. Üblicherweise wenden SSD-Hersteller bei ihren Laufwerken verschiedene Grade von Überprovisionierung an - bestimmte Bereiche werden dabei nicht dem Nutzer zur Verfügung gestellt, sondern bleiben als stille Reserve, falls ein genutzter Bereich ausfallen sollte. Dies unterscheidet Business- von Consumer-Produkten.

Je nach Hersteller kommen entweder E-MLCs (Enterprise Multi-Level Cell) oder C-MLCs (Consumer Multi-Level Cell) zum Zuge. Mehr reservierte Zellen pro SSD (E-MLC) ist aber gleichbedeutend mit längerer Lebensdauer pro SSD - und damit weniger Ausfällen und Aufwänden im Rechenzentrum. C-MLC-SSD’s hingegen sind günstiger in der Beschaffung. Jedoch ist auch hier der technische Fortschritt wichtig, denn die Entwicklung der SSD-Technologie schreitet voran: Jedes Jahr werden SSDs schneller, dichter und preisgünstiger. Gleichzeitig wird die Software, die im Controller für Performance und der effizienten Nutzung des Speichers verantwortlich ist, "smarter". So stellt diese intelligentere Software sicher, dass neuere SSDs mit kürzerer Lebensdauer mindestens fünf Jahre halten.

Diese Software ist auch dafür verantwortlich, nicht nur die Lebensdauer zu verlängern, sondern die Performance zu steigern. Einzelne Schreibzugriffe auf MLC Flash sind eher langsam, da eine ganze Speicherseite neu geschrieben werden muss, wenn lediglich ein Block auf diese Seite geschrieben wird. Ein blockweises Überschreiben ist so nicht möglich. Die Storage Software vermeidet diesen Nachteil, indem sie die Schreibzugriffe auf einer Seite sammelt und sie in einem einzigen Vorgang schreibt. Software-Features wie Inline-Deduplikation und Kompression verhindern dabei überflüssige Schreibzugriffe für redundante und unkomprimierte Daten, denn der schnellste und effizienteste Schreibvorgang ist jener, der nicht erfolgen muss.

Segment-Cleaning/Garbage Collection

Arrays, die über Inline-Deduplikation und -Kompression verfügen, laufen gewöhnlich mit einem Log-basierten Dateisystem. Das verwendete RAID-Subsystem überprüft dabei das Dateisystem ständig, ob sich ungenutzte oder veraltete Blöcke befinden, die bereinigt werden können, um diesen Platz für neue Daten freizumachen.

Performance-Probleme innerhalb eines Storage-Arrays

Die CPU läuft einwandfrei innerhalb des Array-Controllers. Darüber hinaus sind die Prozessorkerne der Storage-Array-CPU multiplen Tasks zugeordnet. Trotzdem kommt es zu Leistungseinbußen. Das könnten die Ursachen sein:

Protocol-IO-Task: Üblicherweise benötigt jeder gelesene und geschriebene Block bei IO-Operationen in kleinen Blöcken (4k, 8k) Prozessorzyklen auf Protokollebene.

Wenn die zugewiesenen Prozessorkerne mit hundert Prozent ihrer Kapazität laufen, kann das Array nicht rasch mehr Eingabe-/Ausgabe-Operationen aufnehmen. Daraus ergibt sich eine Erhöhung der Latenz und somit eine geringere Performance bei Schreib-/Lese-Operationen. Dies bedeutet, dass mehr Prozessorleistung erforderlich ist und dass die Array-Controller oberhalb ihrer Kapazitätsgrenze arbeiten, um eine Latenz im Sub-Millisekunden-Bereich zu bieten.

Berechnung von Deduplikation und Kompression: Dieser Bereich ist normalerweise unkritisch da die meisten Arrays auch dann zuverlässig arbeiten. Es gibt aber Arrays die bei hoher Last in einen Post Prozess Modus verfallen und damit an Effizienz verlieren. Die Größe des Datasets kann reduziert werden um die Anzahl benötigter Arbeitsschritte beim Schreibvorgang auf den Flash-Speicher zu reduzieren.

Segment Cleaning/GC: Segment Cleaning (SC) dient dazu, mit ungenutzten Daten belegte Blöcke in Segmente zu unterteilen und zu ermitteln, welche Segmente gesäubert und dem freien Pool zurückgeführt werden müssen. Diese Datenbereinigung wirkt sich positiv auf die Schreibgeschwindigkeit und die Prozessorauslastung des Controllers aus. Der Prozess selbst sollte auf SSD-Ebene stattfinden, denn dann wird die Last für den Arraycontroller verringert.

Eingeschränkter RAID-Betrieb: Bei SSD-Fehlern im Array könnte es zu Leistungseinbußen kommen solange die betroffene SSD nicht ausgetauscht und die Wiederherstellung abgeschlossen wurde. Während im Gegensatz zur Festplatte mechanische Fehler nahezu ausgeschlossen sind, ist wie oben erwähnt die Art der SSDs (Consumer- oder eben Enterprise SSD) und deren Nutzung maßgeblich für die Lebensdauer der SSD.

Unaligned write IO seitens der Anwendung: Einige SSD-basierten Arrays besitzen Dateisysteme, die auf Block-variablen Log-Strukturen basieren. Diese können die Größe ihres IO Vorganges auf die jeweilige Anwendung anpassen.

Arrays ohne diese Fähigkeit verfügen über fix vorgegebenen Blockgrößen. In diesem Fall vervielfacht sich die Menge der Daten, die der Controller verwalten muss, da die Daten anteilig in mehrere Blöcke geschrieben werden müssen. Als Konsequenz muss die CPU vermehrt das IO-Protokoll abarbeiten, was wiederum zu einer höheren Latenz führt. Dabei kann sich die Lebensdauer der SSDs verringern und Kapazität durch Überprovisionierung kosten.

Moderne Betriebssysteme wie etwa Windows Server 2012 R2 und VMware vSphere übernehmen die Rolle der Partitionenverwaltung, wenn seitens des Arrays Blockprotokolle verwendet werden. Ältere hingegen, beispielsweise Windows Server 2003 und einige Versionen von Linux beziehungsweise von Linux-Dateisystemen übernehmen diese Funktionen nicht, solange die Erstellung nicht mit entsprechenden Attributen geschehen ist.

Performance-Probleme zwischen Array und Server

Die Verbindung zwischen Server und Array erfolgt im Allgemeinen mittels 10 GbE Ethernet oder 8/16-Gbps-Glasfaser. Denn ausreichend Bandbreite und Durchsatz zwischen dem Host Bus Adapter oder dem Converged Network Adapter des Servers und den Zieladaptern des Arrays ist für eine gute Leistung geradezu essenziell.

Ein SAN zu beschleunigen bedeutet, genug Kapazitäten von Buffer zu Buffer für Fibre-Channel-Ports vorzuhalten, die Datenübertragung in weniger als drei bis vier Hops auszuführen sowie Single Initiator-Multi-Target Zoning anzuwenden. Bei Ethernet-Netzwerken empfiehlt es sich, die richtigen MTU-Einstellungen, statisches Routing und Jumbo-Frames zu verwenden oder Port Fast zu deaktivieren. Damit kann man ein möglichst verlustarmes Ethernet-Netzwerk für iSCSI- oder NFS-Traffic erreichen. Die Fehlersuche ist und bleibt ein wichtiger Teil bei der Leistungsmessung und -verbesserung.

Die folgende Tabelle zeigt die Bandbreite, die mit zwei HBAs oder zwei NICs pro Controller erzielbar sind.

Performance-Probleme innerhalb des Servers

Server: Server verfügen über mehrere CPU-Sockel sowie Hauptspeicher und PCIe-Busse, die in enger Beziehung miteinander stehen. Es wird nicht empfohlen, die Daten über verschiedene PCIe-Ports, die verschiedene Seiten des NUMA-Busses (Non-Uniform Memory Access) ansprechen, zu verteilen. Dies löst oft IO-Konflikte aus und veranlasst den PCI- Adapter die Datenflut in der CPU-Queue zu unterbrechen. Man sollte deshalb sämtliche PCIe-Adapter so platzieren, dass sie einen Bezug auf dieselbe Seite des NUMA-Busses besitzen. Zudem sollte bei Linux die IRQ-Balance die Interrupts verwalten. Hyper-V und vSphere administrieren dies nach Erstellung einer virtuellen Maschine automatisch.

Bei OS Multi-Pathing sollten die Best Practices der Array-Hersteller bezüglich Multi-Pathing oder anderen Verteilungsmethoden befolgt werden. Für die Leistungsanalyse bietet Windows perfmon. In Linux kommen dafür verschiedene Tools in Frage, beispielsweise iostat, vmstat oder sar, um die Performance zu messen.

Hypervisor Tuning: Zum optimalen Einstellung der Host-PCI-Geräte (HBA) sind mehrere Infodocs von VMware erhältlich. Zusätzlich gibt es Hersteller-Plugins, die das Array selbständig einstellen.

Zusätzlich hilft das ESXtop-Tool, vSphere Latenzen auf Hypervisor-Ebene zu analysieren und überprüft die VAAI-Statistiken auf die korrekte Funktion von VAAI.

InGuest Tuning: Auch für Maßnahmen, die beispielsweise dazu dienen, das Gastbetriebssystem so einzustellen, dass es weniger CPU-Ressourcen verwendet, gibt es verschiedene Ratgeber im Netz. So könnte man anstelle eines LSI Logic Controllers auch PVSCSI-Controller in einer virtuellen Maschine auf VMware-basis nutzen.

Unter Linux erstellt und steuert udev (userspace /dev) Dateisysteme mit spezifischen Offsets um ein ausgeglichenes IO-Verhalten herbeizuführen.

Dieselben Tools, die auf dem Betriebssystem des physischen Servers laufen, sind auch auf der virtuellen Maschine verfügbar beziehungsweise nutzbar. Für die Leistungsmessung des Gastbetriebssystems wäre das in Windows perfmon, bei Linux iostat, vmstat und sar.

(hal)