Ob ERP, E-Mail oder Dokumenten-Management: Wichtige Applikationen müssen von den Benutzern ohne Unterbrechung und Verzögerung erreichbar sein. Dieser klaren Anforderung steht ein komplexes System gegenüber, das aus PCs, Servern, Netzwerk-, Storage-Networking- und WAN-Komponenten besteht. Um in diesem Geflecht den Zusammenhang der einzelnen, die Performance beeinflussenden Elemente zu veranschaulichen, genügt ein Blick auf die Abläufe: Ein Benutzer arbeitet auf einem Applikations-Server, der seine Daten von einem zentralen, an das SAN gekoppelten Primärspeicher erhält. In die Aktion sind folgende Elemente involviert: Client-PC mit Netzwerkadapter, LAN, Applikations-Server-Hardware, Netzwerkadapter, Betriebssystem, Datenbank, Host-Bus-Adapter, SAN und zentraler Speicher. In dieser Verkettung genügt ein Element mit zu schwacher Leistung, und die Zugriffszeit für den Benutzer auf die Applikation steigt an.

Schwachstellen in der Kette

Um potenzielle Problembereiche in der Gesamtleistung eines Systems identifizieren zu können, ist es wichtig, das schwächste Glied in der Kette zu kennen. Dann sind entscheidende Fragen zu diesem anfälligen Element zu klären, etwa wie dominant seine Funktion ist, ob es Ressourcen anteilig nutzt (LAN) oder ausschließlich für sich beansprucht (Backup-Server). Denn nur ein gutes Lösungsdesign sichert die Balance zwischen Aufwand und Nutzen. Mangelnde Kenntnis eines Lösungsanbieters kann nämlich zu einem starken Ungleichgewicht bei der Leistung der einzelnen Elemente führen. Solange die Performance einer Komponente überdimensioniert ist, wird das Budget des Kunden zwar belastet, ein Vorteil ergibt sich daraus aber nicht zwangsläufig. Der umgekehrte Fall kann jedoch erhebliche Folgen für das Unternehmen haben, schlimmstenfalls steht eine Funktion nicht mehr zur Verfügung.

Ein besonderes Augenmerk bei der Performance-Analyse gilt den mit einer Speicherlandschaft zusammenhängenden Komponenten. Hierzu zählen der zentrale Primärspeicher, die Connectivity-Elemente sowie die Backup- und Recovery-Lösungen. Bezüglich des Primärspeichers ist ein deutlicher Trend in Richtung konsolidierter zentraler Speichersysteme in Form von Network Attached Storage (NAS), Storage Area Networks (SANs) sowie Konvergenzlösungen zu erkennen. Die Vorteile eines zentralen Speichers gegenüber Server-bezogenen Speichersystemen bestehen aus einem verringerten Administrationsaufwand, geringeren Kosten sowie einer höheren Verfügbarkeit und Performance.

Der Primärspeicher

Betrachtet man den Primärspeicher, fällt der Blick zunächst auf die Art der Festplatte (FC, SCSI oder S-ATA). In den letzten Jahren ist die Nutzung von S-ATA-Platten sprunghaft gestiegen. Die Technik ersetzt die parallele IDE-Schnittstelle und ermöglicht höhere Datenraten und eine flexiblere Verkabelung. Sie rückt damit in einen Bereich vor, der bislang ausschließlich von SCSI- und FC-Platten besetzt war. Ein unbestrittener Vorteil für S-ATA ergibt sich aus den vergleichsweise geringen Kosten. Nachteile sind die höhere Ausfallrate und der wesentlich langsamere Random-Zugriff. Das ist auch der Grund dafür, dass S-ATA-Systeme gegenwärtig noch nicht ernsthaft für zentrale Primärspeicher verwendet werden. Anwendung finden diese Platten vielmehr für Aufgaben des Information-Lifecycle-Managements (ILM) im Rahmen von "tiered" Storage.

Festplatten werden mit Hilfe der Raid-Technik (Redundant Arrays of Inexpensive Disks) zu einem redundanten, leistungsfähigen System zusammengeschaltet. Das kann hard- oder softwareseitig erfolgen - für die Anwendung stellt sich das Raid-System wie eine einzelne Platte dar. Durch die Auswahl verschiedener Raid-Levels ist es möglich, zwischen minimalen Kosten, maximaler Verfügbarkeit und maximaler Performance zu entscheiden. Einen guten Kompromiss zwischen diesen Kriterien erreicht man mit Raid-Level 5. Ist aber eine maximale Performance und Redundanz gefragt, so würde man Raid-Level 0+1 wählen.

Die Raid-Controller

Eine weitere, sehr herstellerspezifische Einflussgröße für Performance entsteht durch den Raid-Controller beziehungsweise das Zusammenwirken mehrerer Raid-Controller in einem Storage-System. Durch mehrere Controller kann die Ausfallsicherheit erhöht werden. Ein Fail-over kann automatisch von einem Controller auf den anderen erfolgen. Für die Performance ist es dagegen wichtig, ob die Controller auch im Active-active-Mode arbeiten und somit über Load-Balancing-Mechanismen ein höheres Lastaufkommen bewältigen können. Für die Performance ebenfalls entscheidend ist die Anzahl der FC-Kanäle zu den Controllern. Ein Wert, der das verdeutlicht, ist die Transferrate. Sie reicht in zeitgemäßen Systemen von 100 MB/s bis zu einigen TB/s.

Natürlich prägt auch der Cache die Leistung des Primärspeichers. Von 512 MB an aufwärts bis zu 32 TB und teilweise noch darüber kann er dazu beitragen, dass die Zugriffszeiten von ausgewählten Daten wesentlich verkürzt werden. Die Vorteile des Caches treten allerdings nur in Erscheinung, wenn das Storage-System mit wenigen Applikationen arbeitet.

Im Bereich der Software zählen zunächst die Management-Tools. Ausschlaggebend für die Performance ist zum Beispiel, welche Funktionen zur Speichervirtualisierung ein Hersteller in seiner Lösung implementiert hat. Aber auch das Betriebssystem des Applikations-Servers und die Datenstruktur spielen eine wesentliche Rolle. Kleine Files und eine hohe Verzeichnistiefe gehen zu Lasten der Performance. Die Applikation selbst hat Einfluss auf die Art des Datenzugriffs. Während beispielsweise Videostreaming hohe Transferraten erfordert, sind für Online Trans- action Processing (OLTP) hohe I/O-Raten erforderlich.

Einfluss der Connectivity

Die Connectivity ist eine gemeinsam genutzte Ressource zur Verbindung von Applikationen und Storage-Systemen (zentraler Primärspeicher, Libraries). Deshalb ist insbesondere die ausreichend verfügbare Bandbreite eine wesentliche Voraussetzung für eine ordentliche Storage-Funktion. Ein Beispiel soll das veranschaulichen: Beim Backup werden die Daten von den Servern häufig über das LAN zum Backup-Server transportiert. Das geschieht immer dann, wenn der Server nicht in das SAN eingebunden wurde oder kein SAN vorhanden ist. Ein derartiger Datentransport hat gewöhnlich eine schlechte Performance, da die Ressource LAN von allen Netzwerkknoten genutzt wird und deshalb nicht mehr genug Bandbreite für das Backup zur Verfügung steht. Das Backup wird deshalb in die betriebsschwache Zeit verlegt. Dennoch gelingt es nicht, die schnellen LTO-Laufwerke ausreichend mit Daten zu versorgen. In diesem Fall muss zum Beispiel mit Hilfe der Backup-to-Disk-Technik ein Puffer eingerichtet werden, der den Leistungsmöglichkeiten der Laufwerke gerecht wird.

Backup und Recovery

Ein Backup hat die Aufgabe, im Desasterfall ein Recovery der Daten zu ermöglichen. Wesentlich ist dabei, wie viel Zeit für das Recovery benötigt wird beziehungsweise erlaubt ist und welcher absolute Datenverlust eintreten darf. Die Daten-Wiederherstellung aus einem vollständigen Backup, wie es oft freitags vorgenommen wird, ist kein Problem. Da aus Zeitgründen an den übrigen Wochentagen aber nur inkrementelle oder differenzielle Sicherungen erfolgen, benötigt die Backup-Software hier deutlich länger, um diese für ein Recovery zusammenzubauen. Ein anderer Grund ist das Multiplexing: Um das Backup zu beschleunigen, werden parallel mehrere Sicherungsvorgänge auf ein Laufwerk gestartet. Beim Recovery ist dieser Komplex von der Sicherungssoftware wieder zu entflechten.

Tritt ein Desaster ein, so ist für das Recovery auf den zuletzt gesicherten Datenbestand zurückzugreifen. Dabei entsteht zwangsläufig ein Datenverlust. Wie groß dieser ist ("zugelassener" Datenverlust), hängt davon ab, in welchen Zeitabständen ein Backup vorgenommen wird. Dieser auch als Recovery Point Objective bezeichnete Datenverlust sollte im Zuge von SLAs eindeutig definiert sein. Gleiches gilt für das Recovery Time Objective (RTO), also die maximale Zeit, die für die Wiederherstellung von Applikationsdaten nach dem Desaster benötigt wird.

SLAs entscheiden über Technik

Je nachdem, welche SLAs erforderlich sind, ist eine geeignete Technik auszuwählen. Dabei kann auf verschiedene Weise die Performance erhöht werden: So zum Beispiel, wenn das Backup statt auf Tape zunächst auf ein Plattensystem geschrieben, das aktive Datenvolumen durch hierarchisches Speicher-Management (HSM) verringert oder applikationsbezogen eine Lösung für Continuous Data Protection (CDP) eingesetzt wird.

"Backup to Disk" (B2D) beziehungsweise "Backup to Disk to Tape" (B2D2T) ist gegenwärtig ein sehr aktuelles Thema. Die Ursache liegt darin, dass wie bereits erwähnt die S-ATA-Plattensysteme inzwischen sehr preisgünstig erhältlich sind, die Performance-Anforderungen steigen und die Tape-Laufwerke mit den heute hohen Transferraten (zum Beispiel LTO3 mit 160 MB/s komprimiert) kaum noch ungepuffert betrieben werden können. So bietet fast jeder Hersteller von Backup-Software und -Hardware eine B2D- oder B2D2T-Lösung an. Die Virtual Tape Library (VTL) ist ebenfalls dieser Gruppe zuzuordnen.

Im Zusammenhang mit Backup und Recovery ist auch der "Snapshot" interessant. Er stellt eine Momentaufnahme des File-Systems oder des Blockspeichers dar, die nach festgelegten "Timemarks" erfolgt, zum Beispiel nach 30, 60 oder 120 Minuten. Je nach Hersteller erlauben die Produkte gegenwärtig, bis zu 256 Snapshots anzulegen. Sie können hardware- oder auch softwarebasierend ausgeführt werden.

Besondere Bedeutung hat der Snapshot für die SLAs der Recovery-Performance und den vertretbaren Datenverlust. Wird alle zwei Stunden ein Snapshot erstellt, so beträgt im Desaster-Fall der Datenverlust maximal zwei Stunden. Die Recovery-Zeit liegt in diesem Fall oft nur im Sekunden- oder Minutenbereich. Messungen bei der TIM AG ergaben, dass ein konventionelles Recovery eines Exchange-Servers mit 20 GB etwa 70 Minuten erfordert, während sich dieser Vorgang unter Einsatz von Snapshots auf unter drei Minuten reduziert.

Ein altbewährtes Prinzip zur Leistungsverbesserung einer Speicherlandschaft ist das hierarchische Speicher-Management (HSM).

HSM kam bereits vor zehn bis 15 Jahren zum Einsatz, als Plattenkapazität im Verhältnis zur Bandkapazität noch relativ teuer erkauft werden musste. Heute zwingt das unaufhaltsam wachsende Datenvolumen zu neuen Denkansätzen. So entstand das Konzept von Information-Lifecycle-Management. Anders formuliert: ILM ist die Zuordnung von Informationen zu ihrem Alter unter Beachtung von Kapazität, Performance und Kosten. Hierbei spielt "tiered" Storage eine wesentliche Rolle - also HSM.

Das Prinzip besteht darin, die Daten je nach Nutzungshäufigkeit in unterschiedlichen Speichermedien abzulegen. Der Zugriff auf neu erstellte Daten nimmt innerhalb der ersten 30 Tage stark ab. Zirka 70 bis 80 Prozent des Datenbestands sind in der Regel älter als ein Jahr. Bei einer HSM-Lösung wird diese Erscheinung genutzt und die weniger verwendeten Daten vom Primärspeicher auf S-ATA und Tape verschoben. Der Performance-Effekt besteht darin, dass der Primärspeicher wesentlich weniger aktive Daten vorhält und sich die Backup- und Restore-Zeiten verringern.

Messung der Performance

Die Speicher-Performance spielt eine wesentliche Rolle bei der Gestaltung und Sicherung der Applikationen. Mit Hilfe von Messwerten kann eine gewisse Bewertung und Vergleichbarkeit für Komponenten und Lösungen erreicht werden. Die wichtigsten Messgrößen dabei sind die Transferrate in MB/s, die I/Os pro Sekunde und für Datenbanken die Transaktionen pro Sekunde. Mit diesen Werten können Einzelsysteme wie Primärspeicher, Laufwerke von Libraries oder Datenbanken bewertet werden. Die Messung selbst lässt sich mit Hilfe von Performance-Tools wie dem "I/O-Meter" von Open Source Development Lab (www.iometer.org) vornehmen.

Zur Bewertung von Einzelsystemen sind aber auch Benchmarks geeignet. Mit definierten Testkonfigurationen und Workloads werden ausgewählte beziehungsweise von den Herstellern angebotene Storage-Systeme getestet und dabei Leistungsparameter sowie Preise verglichen. Da es aber um das Zusammenwirken mehrerer Performance-Elemente geht, ist dieses Verfahren sehr komplex und nicht mehr einfach abzubilden. Hier hilft nur die Arbeit mit "natürlichen Benchmarks" oder auch den real zu betrachtenden Applikationen. Beispiel Primärspeicher: Wenn ein zentraler Primärspeicher eingerichtet wird, dann muss dieser hinsichtlich der I/Os pro Sekunde und der Transferrate (MB/s) mindestens die Werte der einzubeziehenden Server abbilden können.

Keine Aussagekraft

Vorsicht vor Datenblattangaben! Viele Hersteller geben als I/O-Wert eine Burst Rate aus dem Cache heraus an. Diese Werte sind praktisch meistens nicht nutzbar, weil das Umfeld selten homogen genug ist, um die Vorteile des Caches zu nutzen. Die angegebene Transferrate wird oft nur auf die FC-Kanäle bezogen und hat mit der real erreichbaren Performance über die Controller wenig zu tun. Wichtiger dagegen ist, wie viele Platten zum Einsatz kommen, welche Umdrehungen pro Sekunde diese Platten haben und wie die Raid-Systeme konfiguriert werden.

Beispiel Backup: Für ein volles Backup von 3 TB in einem Zeitfenster von sechs Stunden würden theoretisch zwei Laufwerke LTO3 (unkomprimiert mit je 288 GB pro Stunde) ausreichen. Praktisch sieht das aber anders aus. Die Speicherknoten mit dezentralem oder zentralem Storage müssen ebenfalls in der Lage sein, die Performance von 288 GB/h oder 80 MB/s aufzubringen. Die Backup-Software muss durch Multiplexing sicherstellen, dass von mehreren Servern gleichzeitig auf ein Laufwerk geschrieben wird. Die Connectivity (FC oder Ethernet) muss eine derartige Transferrate ermöglichen. Letztendlich wird die Library durch Positionierzeiten und Bandwechsel die real erreichbare Performance schmälern. Die Erfahrung zeigt, dass unter günstigen Umständen von einem LTO3-Einzellaufwerk zwar 80 MB/s unkomprimiert erreicht werden, in der Gesamtinstallation aber weitere Einflüsse wirksam werden und die effektiv erreichbare Performance weit unter den Datenblattwert absinkt.

Best Practice

Performance kostet Geld! Deshalb sollte in Storage-Networking-Lösungen die Performance nicht maximal, sondern optimal gestaltet werden. Optimal bedeutet, dass eine Balance der Leistung zwischen den sich gegenseitig beeinflussenden Elementen angestrebt wird. Anders formuliert: Es sollte eine Geschwindigkeits- beziehungsweise Performance-Anpassung der Elemente geben. So kann es beispielsweise falsch sein, ein LTO2- durch ein LTO3-Laufwerk zu ersetzen, wenn nicht die Voraussetzungen des Datentransports zum Laufwerk gegeben sind. Es kommt dann zu einem Start-Stop-Betrieb des Laufwerks, so dass nicht die Performance steigt, aber die Lebensdauer der Technik sinkt.

In bestehenden Installationen lassen sich häufig Design- und Sizing-Fehler feststellen, deren Ursachen meist im nicht ausreichend vorhandenen Storage-Know-how der Anbieter liegen. Derartige Fehler bedeuten für die Kunden eine überteuerte beziehungsweise fehlerbehaftete Lösung. Bei der Beurteilung des realen Leistungszusammenspiels einzelner Speicherelemente helfen oft nur die Erfahrungswerte von Storage-Experten. Analytische Modelle oder Simulationen zur Ermittlung der möglichen Performance haben sich bislang nicht durchsetzen können. (ue)