Das Thema Konsolidierung in der IT ist weder neu, noch jemals wirklich abgeschlossen. Die Tatsache, dass derzeit vor allem Server- und Storage-Projekte laufen, hängt mit den großen Sparpotenzialen zusammen (siehe auch das CW-Drilldown Storage-Kosten senken). Storage ist ein massiver Kostenfaktor. Angesichts weiter wachsender Datenmengen und dem komplexem Management der Speichersysteme ist für IT-Verantwortliche auch der sinkende Preis pro Gigabyte kein Trost. Storage-Konsolidierung ist der erste und wichtigste Schritt, um die Datenhaltung zu zentralisieren. Um das Potenzial eines Konsolidierungsprojekts voll auszuschöpfen, ist es wichtig, dass ALLE Daten von lokalen Serverspeichern auf die zentrale Storage-Einheiten migriert werden.
Eine runde Sache wird daraus jedoch erst durch Virtualisierung. Festplatten und Daten werden mittels einer Abstraktionsschicht voneinander entkoppelt und die physischen Realitäten werden maskiert. Dies vereinfacht das Handling und revolutioniert geradezu den Ressourcenbedarf. Die Möglichkeiten der Storage-Virtualisierung sind vielfältig. Der Spielraum reicht von Pooling über Thin Provisioning und Global Namespace bis hin zu Cloud-Services.
Storage-Konsolidierung und -Virtualisierung sind - auch im Sinne einer Best Practice - das ideale Gespann. Bei der reinen Virtualisierung durch vorgelagerte Storage-Controller oder einer Softwarelösung entfällt die Migration, die physische Datenhaltung bleibt unverändert. Eine derartige Lösung kann angeraten sein, wenn zum Beispiel die bestehende Hardware noch nicht vollständig abgeschrieben ist oder aus anderen Gründen nicht ersetzt werden soll. Während die alleinige Virtualisierung die Kostenvorteile einer optimierten Hardware verschenkt (nicht jede Applikation benötigt FC-Platten…), bleiben bei der lediglich konsolidierten Datenhaltung Virtualisierungsvorteile wie einfaches Handling und geringerer Ressourcenverbrauch ungenutzt. Storage-Projekte, die Konsolidierung und Virtualisierung kombinieren, bieten zudem nicht nur die größten Kostenvorteile, sondern auch das größte Optimierungspotenzial. In der Praxis haben sich sieben Schritte in Projekten zur Storage-Konsolidierung bewährt.
Schritt 1: Die Bedarfsanalyse
Auf die Bedeutung der Klärung und möglichst genauen Definition des Bedarfs kann gar nicht oft genug hingewiesen werden. Zu berücksichtigen ist auch, dass nicht automatisch alle Fachabteilungen in einem Unternehmen oder auch in einer Behörde von einem Konsolidierungsvorhaben begeistert sind. Konsolidierung bedeutet letztlich auf Abteilungsebene auch Kontrollverlust und Einschränkung der Entscheidungsfreiheit. Neben der Erhebung der technischen Fakten ist also möglicherweise auch Überzeugungsarbeit zu leisten, um intern Kooperationsbereitschaft herzustellen. Für beides haben sich Projekt-Workshops bewährt.
Die IT-Abteilung muss die Frage beantworten, ob sich eine Storage-Konsolidierung überhaupt lohnt. Eine zentralisierte Datenhaltung erfordert oft weitere Maßnahmen wie ein neues Backup-Konzept, ein Disaster Recovery-Szenario, neue Service Level Agreements, Möglichkeiten des Monitorings, der Verrechnung etc. Und damit fallen weitere Kosten an. Dass den Kosten ein messbarer Nutzen gegenüber steht, sollte entsprechend der Fachkenntnis des Entscheiderkreises herausgearbeitet werden.
Der erste konkrete Schritt in Richtung Planung ist die Analyse des Status quo. Welche Storage-Architektur besteht oder fehlt? Welche Applikationen werden die Storage-Systeme nutzen? Wie viele User haben worauf Zugriff? Wie viele Concurrent User greifen auf die Datenbanken zu?
In die Ist-Analyse müssen auch Angaben zu Wachstumstrends Eingang finden. Das kann sich ausschließlich auf die gesamte benötigte Datenmenge beziehen oder aber differenzierter nach Nutzungszweck unterscheiden. So ist zum Beispiel das Verhältnis von unstrukturierten (File-)Daten zu Datenbanken interessant, aber auch die Bestände und Wachstumstendenzen einzelner Abteilungen. Ist starkes Wachstum erkennbar, stellt sich die Frage nach den Ursachen. Waren es Unstetigkeiten zum Beispiel durch die Einführung einer neuen Applikation oder ist es Ausdruck der geplanten Entwicklung eines bestimmten Geschäftsfelds? Für die Erstellung dieser Angaben ist die Unterstützung möglichst vieler Abteilungen äußerst hilfreich.
Schritt 2: Kapazitätsplanung
Auf die Ist-Analyse folgt die Kapazitätsplanung. Hier werden Leistungsmerkmale wie Storage-Kapazität, Skalierbarkeit, Anzahl und Technologie der Festplatten, Größe des Cache festgelegt und damit schon eine gewisse Vorauswahl der Produkte getroffen. Die Kapazitätsplanung wird zudem davon beeinflusst, ob ein online Backup projektiert ist. Sollen mithilfe einer Snapshot-Technik das Backup und Restore beschleunigt werden, ist zusätzlich zu den produktiven Daten eine so genannte Snapshot-Reserve einzuplanen. Wie groß sie ist, richtet sich danach, wie der Hersteller seine Snapshot-Technik implementiert hat. Im ungünstigsten Fall kann die Speicherkapazität für die Snapshots genauso groß wie die Menge der zu sichernden Daten sein.
Schritt 3: Produktauswahl
Ob die Wahl auf ein klassisches SAN Array, auf Unified Storage oder Grid-Technologie fällt, richtet sich stark nach den Applikationen oder Daten, die zu konsolidieren sind. Den universellsten Ansatz bietet Unified Storage. Hier sind NAS, IP SAN und FC SAN auf einer Plattform vereint. Wer möglichst breit konsolidieren will, liegt damit in jedem Fall richtig - und hat eine Zukunftsperspektive, wenn sich Anforderungen ändern. Aktiviert wird nur, was nötig ist. Der genaue Zeitpunkt spielt dabei keine Rolle.
Schritt 4: Design
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 immer günstigeren SSDs (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.
Schritt 5: Migration
Die eigentliche Migration ist der Punkt der Wahrheit und stellt die gesamte Planung auf den Prüfstand. Dabei ist es mit dem Kopieren der Daten allein nicht getan. Denn Storage-Konsolidierungsprojekte bieten die seltene Chance, Datenstrukturen zu überdenken statt sie einfach zu übernehmen. Wer sich vorgenommen hat, den Datenbestand eines Tages zu bereinigen, hat jetzt die beste Gelegenheit. Der Zeitpunkt der Migration will gut gewählt sein. In der Regel wird parallel zur bestehenden die neue Infrastruktur aufgebaut, so dass am Tag X nur mehr Daten zu kopieren sind. Ob man das Projekt nun in mehrere Tranchen zerlegt, wie etwa den File-Service zuerst und anschließend gestaffelt die Datenbanken, ist im Grunde nur eine Frage der Vielschichtigkeit und des Umfangs des Projekts.
Schritt 6: Projekt-Management
Es empfiehlt sich im Rahmen eines Konsolidierungsprojekts, nicht nur die Reihenfolge und den Zeitaufwand für die einzelnen Schritte festzulegen, sondern auch eine Projektleitung als Schnittstelle für alle Projektbeteiligten einzusetzen. Eine dafür geeignete Person sollte nicht nur das technische Know-how mitbringen, sondern auch über die notwendigen Kontakte zu den involvierten Herstellern und Dienstleistern verfügen. Diese Rolle ist alles andere als trivial: Sie sorgt dafür, dass alle Schritte ineinander greifen und dass bei noch so umsichtiger Planung auftretende Verzögerungen oder Unstimmigkeiten möglichst schnell bereinigt werden. Gute Kommunikationsfähigkeiten sind für diese Position unabdingbar.
Schritt 7: Dokumentation
Begleitend zur Migration muss eine ausführliche Dokumentation entstehen; vor allem die detaillierte Beschreibung der Installation zum Zeitpunkt der Endabnahme ist festzuhalten. Sie ist Basis der Endabnahme und Grundlage eines ordnungsgemäßen Betriebs. Auch hier sei auf Itil und ISO verwiesen.
Fazit
Konsolidierungsprojekte sind insbesondere dann nicht einfach, wenn sie wie im Falle Storage massiv in eine bestehende Infrastruktur eingreifen. Mit guter Planung, genauer Definition des eigenen Bedarfs und einem versierten Projekt-Management wird daraus ein Erfolg.