Professionelle SAN-Konfiguration
Das Tuning entscheidet
Storage Area Networks offerieren Administratoren ein breites Spektrum von Optionen und Parametern zur Optimierung. Beispiele dafür sind das Design logischer Speichereinheiten und die Stellschrauben für Lese- und Schreib-Caches. Durch das richtige Tuning sind spürbare Performance-Steigerungen zu erzielen.
Die Leistungsfähigkeit von Storage Area Networks wird durch eine Reihe von Faktoren beeinflusst:
das zu bewältigende Datenaufkommen im Lese- beziehungsweise Schreibzugriff, das Design der
RAID-Gruppen, die Abbildung von RAID-Gruppen auf LUNs (Logical Units), die Cache-Einstellungen der
Speicherprozessoren und Tuning-Maßnahmen für Host-Bus-Adapter. RAID-Gruppen repräsentieren die
physikalische Sicht der Kommunikation mit SAN-Hardware, während LUNs die logische Sicht der
Kommunikation mit dem Betriebssystem darstellen.
Design von Logical Units
Wie auch immer das Speichernetzwerk realisiert ist, welches RAID-Level eingesetzt wird, ob es
zusätzliche "Mirrors" gibt: Vermittelt über die Applikation auf einem Server zeigt sich das
Storage-System immer als "Volume". Im SCSI-Sprachgebrauch heißt ein Volume auch "LUN". Diese
Abstraktion ist ein erster Schritt zur Speichervirtualisierung.
Wo mehr Performance auf der Wunschliste steht, sind dedizierte RAID-Gruppen bereits ein probates
Mittel. Dabei besteht ein unmittelbarer Zusammenhang zwischen RAID-Gruppe und LUN. Der Grund dafür
ist einfach: Jede Lese- oder Schreiboperation auf einer LUN muss letztlich auf der physikalischen
(RAID-)Ebene ausgeführt werden. Verdeutlichen lässt sich dieses Konzept an Applikationen wie dem
Microsoft Exchange Server 2003, da hier jede Lese- oder Schreibaktion auf einem Client mit einer
Rückbestätigung durch den Server korrespondiert.
Die Verknüpfung mehrerer LUNs mit einer einzigen RAID-Gruppe ist insbesondere in
Filesharing-Umgebungen ein gängiges Verfahren. Sind beispielsweise drei LUNs (0, 1 und 2) mit einer
RAID-Gruppe verbunden, konkurrieren abhängig von der Belastung alle drei um die physikalischen
Ressourcen der RAID-Gruppe. Damit solche Situationen nicht vorkommen, sollten Storage-Designer in
Datenbankumgebungen darauf achten, für jede RAID-Gruppe nur eine LUN zu konfigurieren.
Die Implementierung der optimalen Abbildung von RAID-Gruppen auf LUNs ist entscheidend dafür, ob
es zu LUN-Konflikten kommt. Gleiches gilt für die Herstellung eines ausgewogenen Verhältnisses
zwischen LUNs und Storage-Prozessoren. Auch hier lässt sich durch Drehen an den Stellschrauben die
Leistungsfähigkeit eines SANs beeinflussen.
Administratoren haben eine Reihe von Optionen, um LUNs Storage-Prozessoren zuzuweisen. Die
Verknüpfung kann automatisch erfolgen oder auch, indem LUNs dediziert einem Storage-Prozessor
zugeordnet werden. Richtschnur dafür ist die anfallende Arbeitslast, die möglichst gleichmäßig auf
die Storage-Prozessoren verteilt werden sollte, damit keine unnötigen Latenzzeiten entstehen. So
verfügt beispielsweise das Storage Array Dell/EMC CX700 über zwei Speicherprozessoren. Vier
Backend-Fibre-Channel-Loops pro Speicherprozessor mit je 2 GBit Bandbreite sorgen für insgesamt
acht Backend-Loops pro Array.
Eine weitere Tuning-Maßnahme bietet sich in Form von Vorgaben für die Größe der Pages im Cache,
Cache Flush Watermarks (Niedrig- und Höchstmarke, bei deren erreichen der Inhalt des Cache auf die
physikalische Platte geschrieben wird) und Cache Allocation. Grundsätzlich ist zwischen einem Lese-
und einem Schreib-Cache zu unterscheiden, wobei sich diese pro Storage-Prozessor aktivieren oder
deaktivieren lassen. Beim Design von LUNs im Hinblick auf möglichst schnelle Antwortzeiten – und
damit eine niedrige Latenz – können Administratoren den Cache bestimmter LUNs ein- oder
ausschalten, um so anderen LUNs mehr Cache zur Verfügung zu stellen. Ist der Cache größer, bleiben
diese LUNs dann darüber hinaus häufiger vom Cache Thrashing (ständiges Nachladen von Daten in den
Cache) verschont.
Eine wichtige Kennziffer ist die Größe der Pages im Cache. Im Unterschied zu
Festplatten-Controllern verwenden die Storage-Prozessoren Pages statt Sektoren. Je größer eine
Page, umso mehr zusammenhängende Sektoren lassen sich im Cache vorhalten. Als Faustregel gilt: 8
KByte oder 16 KByte für Fileserver-Applikationen und 2 oder 4 KByte für Datenbankanwendungen.
Auch der Umfang des Lese-Caches ist abhängig von der Arbeitslast, der LUNs ausgesetzt sind. Beim
sequenziellen Lesen kontinuierlicher Datenströme wie sie für Fileserver-Umgebungen typisch sind,
werden Lese-Caches stark beansprucht. Daher sollte der Lese-Cache recht großzügig bemessen werden,
um Anfragen aus dem Cache statt von LUNs beantworten zu können.
Beschleunigung von Lesezugriffen
Ebenfalls recht wirksam zur Beschleunigung der Lesezugriffe ist Read-ahead-Caching, auch als
Prefetching bezeichnet. Dabei ist der Storage-Prozessor befugt, nach zwei erfolgreichen
sequentiellen Lesevorgängen die Daten "im Voraus" zu lesen während er auf das Netzwerk wartet. Mit
diesem Algorithmus lässt sich die SAN-zu-LUN-Latenz senken, denn die benötigten Daten stehen schon
im Cache bereit. Drei Arten des Prefetchings können unterschieden werden:
Konstant: Diese Art des Prefetchings empfiehlt sich, wenn die Daten eine
konstante Länge besitzen. Als weitere Stellgrößen sind die Prefetch- (Anzahl der Datenblöcke, die
bei einem einzelnen physikalischen Zugriff erreichbar sind) und die Segmentgröße (Anzahl der
Datenblöcke einer Leseoperation von der LUN) verwendbar. Typische Einsatzgebiete sind Media- oder
Backup-Server.
Variabel: Hier geht es, wie der Name bereits sagt, um Daten variabler Länge.
Die zentralen Kennziffern hier sind Prefetch Multiplier, Segment Multiplier und Maximum Prefetch.
Wird der Prefetch Multiplier mit dem Wert vier gewählt und die benötigte Datenmenge beträgt 2
KByte, beläuft sich die variable Prefetch-Größe auf 8 KByte (vier mal zwei). Variables Prefetching
eignet sich für Umgebungen, bei denen Lesezugriffe eher selten und Schreibzugriffe eher häufig
sind.
Nicht zugelassen: deaktivierte Prefetching-Funktionen.
Das Pendant zu den Lesezugriffen sind die Schreibvorgänge insbesondere bei Datenbankanwendungen.
Kommen neue Daten hinzu oder werden vorhandene Massendaten geändert, sieht das Storage Array
Dell/EMC CX700 vor, dass die Informationen zunächst im Schreib-Cache der Storage-Prozessoren
eingehen und erst dann an vorgesehene LUN weitergeleitet werden. Zusätzlich – dies erhöht die
Datensicherheit und Verfügbarkeit – werden die Daten im Cache des einen Storage-Prozessors im Cache
des zweiten Storage-Prozessors gespiegelt.
Der Schreib-Cache jedes Prozessors enthält daher sowohl seine eigenen zwischengespeicherten
Daten als auch eine Cache-Kopie des zweiten Prozessors. Fällt einer der beiden Prozessoren aus,
werden die zwischengespeicherten Daten im funktionierenden Prozessor sofort auf die Platte
geschrieben, damit sie nicht verloren gehen können. Für Stromausfälle gibt es einen Notfallakku,
der ein vollständiges Backup erstellt und das System ordnungsgemäß herunterfährt. Dabei werden die
Daten im Cache auf Festplatten gespeichert, um Datenverlust zu verhindern.
Fazit
Performance, Kapazitäten und Latenz sind für den Systemadministrator wichtige Kennziffern beim
Design eines Storage Area Networks. Einen guten Ausgangspunkt für das Feintuning bieten die
Voreinstellungen der Hersteller. Die Top-Leistung lässt sich jedoch erst im Anschluss an eine
genaue Analyse der tatsächlichen Auslastung und der Auswirkungen einzelner Design- und
Tuningmaßnahmen erzielen.
Lesen Sie mehr zum Thema
