In sieben Schritten zur Storage-Konsolidierung

Schritt 4: Design

Unter Design lassen sich Verfügbarkeit, Performance und Protokolle zusammenfassen:

Verfügbarkeit

Die Anforderungen an die Verfügbarkeit lassen sich nicht ausschließlich im Storage-Projekt definieren. Hier ist man gut beraten, die Hubschrauber-Perspektive einzunehmen und die Anforderungen an die Verfügbarkeit der gesamten IT aus der Sicht der Geschäftsprozesse zu definieren. Hier helfen Itil-konforme Vorgehensweisen aus dem Business- und Infrastructure Continuity Management.

Die Verfügbarkeit ist eine kritische Größe des Storage-Designs, Redundanz ist hier das Zauberwort. Storage-Systeme basieren auf Festplatten, also mechanischen Bauelementen und haben damit den Verschleiß quasi schon eingebaut. Daher empfiehlt sich generell die Verwendung von Raid-Schutz und Hot-Spare-Platten. Besonders bei SATA Disks sollte es ein doppelter Raid-Schutz sei, da ein Datenverlust aufgrund der hohen Datendichte besonders schwerwiegend sein kann.

Geht man von der Plattenebene auf die Systemebene, so bieten sich andere Mechanismen an. Ein Cluster mit doppeltem Controller sichert zwar die Controllerverfügbarkeit ab, schützt jedoch noch nicht bei Ausfall von Platten-Shelves. Nur durch die Spiegelung der Daten wird die effektive Verlustrate im Ernstfall gering ausfallen. Fordern geschäftskritische Anwendungen sehr kurze Recovery-Zeiten, so sollte eine synchrone Spiegelung mit automatischem Failover in getrennten Rechenzentren in Betracht gezogen werden.

Über das Niveau der notwendigen Verfügbarkeit entscheiden letztlich die Applikationen und die darauf aufsetzenden Geschäftsprozesse. Je stärker die Bedingungen einem 24x7-Betrieb entsprechen, wie etwa in der Dreischicht-Produktion, desto eher empfiehlt sich ein Split Cluster, bei dem die Systeme auf mehrere RZ-Standorte verteilt. Zusätzlich kann man sich an den Erfahrungswerten zur jährlichen, durchschnittlichen Uptime eines Storage-Systems orientieren und sie in Beziehung zu den Interessen des eigenen Unternehmen setzen.

Das Bestimmen des Verfügbarkeitsniveaus zählt zu den wichtigsten Aufgaben in Konsolidierungsprojekten. Sicherheit ist ein massiver Kostenfaktor, deshalb sollten Kosten und Nutzen gut gegeneinander abgewogen werden. Eine nicht zu unterschätzende Rolle spielt der Grad der Absicherung des Systems durch den Hersteller, sei es durch Redundanz, Fernüberwachung der Funktionen oder kurze Reaktionszeiten in der Wiederherstellung und Ersatzteillieferung. Entgegen mancher Vorstellung ersetzen selbst synchrone Datenspiegel das Backup keineswegs. Ein synchroner Spiegel spiegelt eben auch logische Fehler. Sind etwa aus Gründen der Datenintegrität Roll-Backs erforderlich oder ältere Versionsstände gefragt, wird es ohne Backup schnell sehr schwierig.

Performance

Kapazität ist nicht alles, es kommt auch auf die Performance an. "Sizing" lautet hier das Stichwort. Vor allem bei Datenbanken geht es darum, die Anzahl und den Typ der Festplatten richtig zu bemessen. Zu wenige oder zu langsame Platten können vor allem bei Lastspitzen sehr schnell zu Performance-Engpässen führen. Das würde bedeuten, am falschen Ende zu sparen. Neben den noch hochpreisigen Solid State Disks ist die Kombination von Beschleunigerkarten / Cache-Erweiterungen und SATA-Disks eine interessante Option. Wenn die Datenbank in den Cache passt, dann steht die Frage der Festplattenperformance nicht mehr im Vordergrund.

Die Frage, in welchem Verhältnis FC-, SATA- oder auch SAS-Festplatten eingesetzt werden, richtet sich nach dem Performance-Bedarf einzelner Applikationen, ist aber auch ein Kostenfaktor. Wichtig ist die passende Balance zwischen den Technologien und die bedarfsorientierte Bereitstellung von Speicher - Menge für Fileservices und Archive, Leistung für Datenbanken. Storage-Konsolidierung bietet die Option, die passende Kombination zu wählen.

Protokolle

Die Wahl der Protokolle für die konsolidierte Storage-Landschaft richtet sich nach technischen Gegebenheiten, nach der Performance und nach den Kosten. FC ist definitiv teurer in der Implementierung als iSCSI. VMware läuft über NFS genauso gut wie über FC. Oracle ist auf NAS mit NFS hoch performant. SQL Server funktioniert auch mit CIFS. Diese Erkenntnisse zeigen vor allem eines: Schablonendenken ist hier fehl am Platz.