Komplexität vs. Kostenreduzierung

Herausforderung Speichervirtualisierung

27.03.2007 von Martin Tutschek
Konsolidierte Speichersysteme verbessern die Speicherauslastung und tragen zur Kostenreduzierung bei. Die Verwaltung gestaltet sich jedoch schwieriger als bei klassischen Lösungen, Virtualisierung kann das Management vereinfachen.

In modernen Rechenzentren arbeitet eine große Zahl an Servern mit großen Speicher-Arrays zusammen. Die Verbindung zwischen diesen Komponenten wird in der Regel über Fibre-Channel-Fabrics realisiert. Einzelne Arrays unterstützen dabei hunderte - oft sogar tausende - Server und Anwendungen. Diese Architekturen haben sich im Lauf der Zeit durch umfassende Speicherkonsolidierungen entwickelt und sorgen durch gute Speicherausnutzungswerte für erhebliche Kosteneinsparungen. Ihre Verwaltung ist für die IT-Verantwortlichen allerdings deutlich schwieriger und kostenintensiver als zuvor, da sämtliche Änderungen am physikalischen Speicher hunderte von Anwendungen direkt betreffen.

Um dieses Problem zu lösen, kommen Virtualisierungstechniken ins Spiel. Diese helfen den Administratoren dabei, die Komplexität ihrer Infrastrukturen in den Griff zu bekommen und die Verwaltungskosten wieder zu senken. Die Virtualisierung vereinfacht zudem die Datenbewegungen und ermöglicht neben unkomplizierten Modifikationen an der Infrastruktur auch gestaffelte Speicherstrategien, Information Lifecycle Management (ILM) sowie die Implementierung von Business-Continuity- und Disaster-Recovery-Lösungen.

Technische Hintergründe

Die Storage-Virtualisierung stellt ein logisches Abbild des physikalischen Speichers dar. Dabei kommt zwischen Servern und Speicherkomponenten eine Abstraktionsschicht zum Einsatz. Die Server kommunizieren im Betrieb dann mit dieser Abstraktionsschicht und nicht mit den Speichergeräten selbst. Der zugrunde liegende physikalische Speicher lässt sich also bei Bedarf jederzeit modifizieren, ohne dass die Anwendungen, die auf den Speicher zugreifen, dadurch beeinträchtigt werden. Die Verantwortlichen haben folglich immer Gelegenheit, Arrays zu ersetzen oder Tiered-Storage- und ILM-Strategien zu realisieren, ohne sich dabei um die Applikationen kümmern zu müssen.

Ein weiterer Vorteil der Speichervirtualisierung liegt darin, dass sämtliche Daten sich - je nach den Anforderungen der Anwendungen oder den Geschäftswert der Informationen - stets von einer Speicherkomponente auf eine andere verschieben lassen. Die physikalischen Speichereinheiten können dabei sowohl aus mehreren unterschiedlichen Arrays, als auch aus heterogenen Storage-Einheiten unterschiedlicher Hersteller bestehen.

Vorteile flexibler Datenhaltung

Wurde einmal eine Speichervirtualisierung auf Unternehmensebene implementiert, so ermöglicht sie transparente Datenbewegungen, die ihrerseits die Grundlage für alle ILM-Strategien darstellen. Die Verantwortlichen haben dank dieser Technologie nicht nur die Möglichkeit, die Auslastung ihrer Speicherinfrastruktur weiter zu verbessern, sondern können auch sämtliche Informationen immer auf den jeweils kostengünstigsten Speicherkomponenten ablegen, ohne dabei Abstriche beim Datenschutz und bei der Erfüllung behördlicher Vorschriften machen zu müssen. In der Praxis können somit ältere und unkritische Daten nach und nach auf preiswertere Speichereinheiten ausgelagert werden.

Virtualisierte Umgebungen ermöglichen es außerdem, sämtliche Managementaufgaben über einheitliche Werkzeuge und Policies zu vereinfachen. Dazu sind äußerst skalierbare und sehr zuverlässige Speicherkomponenten - am besten in Form eines SANs - erforderlich.

Problem der Skalierbarkeit

Die Skalierbarkeit stellt die wichtigste Herausforderung beim Aufbau einer funktionierenden Virtualisierungsinfrastruktur auf Unternehmensebene dar. Viele Unternehmen haben bereits erfolgreich mit Virtualisierungstechniken experimentiert, um dann nach der Implementierung ihrer Lösung festzustellen, dass diese sich nicht entsprechend der Anforderungen skalieren lassen. Das bringt so viele Nachteile mit sich, dass der Nutzen des gesamten Projekts in Frage gestellt ist. In diesem Zusammenhang sind beispielsweise ungenügende I/O-Performance und ein hoher Verwaltungs-Overhead zu nennen. In extremen Fällen kann es sogar dazu kommen, dass im Netz genauso viele Virtualisierungskomponenten wie Speicher-Arrays Verwendung finden oder dass die Unternehmen ihre gesamte Switching-Architektur ersetzen müssen.

Um die mit der Skalierbarkeit zusammenhängenden Probleme zu verstehen, müssen sich die IT-Verantwortlichen klar machen, dass ein leistungsfähiges Virtualisierungssystem sich nach außen stets als der ganze im Unternehmen vorhandene Speicher präsentieren muss. Speicherbereiche, die nicht zu diesem System gehören, sind folglich zu vermeiden. Das Storage-Produkt sollte übrigens nicht nur den gesamten Speicher umfassen, sondern muss gleichzeitig auch die Abstraktion und die Zugriffe auf die darunter liegenden physikalischen Speicherkomponenten transparent verwalten. Dieses Vorgehen verringert den durch das Speichermanagement erzeugten Overhead und beeinträchtigt somit nicht die Anwendungsleistung.

Die mit der Realisierung dieses Ansatzes zusammenhängenden Schwierigkeiten wachsen mit der Zunahme der Speichergröße im Unternehmen an. Praktisch alle heute erhältlichen Lösungen bieten nämlich nicht die Skalierbarkeit, die für eine angemessene Unternehmensleistung erforderlich wäre. Deswegen sind Organisationen gezwungen, eine große Zahl unterschiedlicher Virtualisierungskomponenten (in Form von Blades, Switches oder Appliances) zu kaufen und anschließend zu verwalten. Generell unterscheidet man bei der Auswahl der Virtualisierungslösung zwischen geschlossenen Architekturen und einer Virtualisierung auf Fabric-Basis.

Methoden der Virtualisierung

Manche Virtualisierungsarchitekturen sind in sich geschlossen. Das heißt, die Steuerung und Übersetzung der Abstraktion finden sich im selben Gerät. Implementierungen mit in sich geschlossenen Architekturen umfassen Appliances und Lösungen auf Array-Controller-Basis. Bei diesem Ansatz machen sich die durch mangelnde Skalierbarkeit gesetzten Grenzen besonders bemerkbar. Denn Lösungen, die nach diesem Muster arbeiten, sind nur dazu in der Lage, bestimmte Teile der Fabric zu virtualisieren. Die Produkte stellen also nicht den gesamten Speicher dar. Es kommt zu so genannten Virtualisiserungsinseln, also virtualisierten Teilen des Gesamtspeichers, die nicht mit den anderen Speicherbereichen kommunizieren können. Daten, die sich auf solchen Inseln befinden, lassen sich nicht verschieben, ohne die darüber liegenden Anwendungen zu beeinflussen.

Ein Ansatz, der das ganze Speichernetz umfasst und durchdringt, eignet sich besser, um die mit der Skalierbarkeit zusammenhängenden Schwierigkeiten zu lösen und die Unternehmensanforderungen zu erfüllen. Bei diesem Ansatz bleibt die Virtualisierung nicht auf bestimmte Geräte oder Teile des Speichernetzes beschränkt. Folglich lässt sich mit der genannten Vorgehensweise, die auch als Netzwerk- oder Fabric-basierte Methode bezeichnet wird, das ganze SAN virtualisieren.

Virtualisierung auf Fabric-Basis

Ein Ansatz, der das ganze Speichernetz umfasst und durchdringt, eignet sich besser, um die mit der Skalierbarkeit zusammenhängenden Schwierigkeiten zu lösen und die Unternehmensanforderungen zu erfüllen. Bei diesem Ansatz bleibt die Virtualisierung nicht auf bestimmte Geräte oder Teile des Speichernetzes beschränkt. Folglich lässt sich mit der genannten Vorgehensweise, die auch als Netzwerk- oder Fabric-basierte Methode bezeichnet wird, das ganze SAN virtualisieren.

Die meisten Virtualisierungsstrategien auf Fabric-Basis arbeiten mit einem getrennten Datenpfad, während die physikalische Ein- und Ausgabe über einen unabhängigen Steuerungspfad abgewickelt wird. Diese Technik funktioniert ähnlich wie bei einem Plattensubsystem. Der Steuerungspfad „programmiert“ den Datenpfad und stellt gleichzeitig die logische Abstraktion der physikalischen Speicher-Array-LUNs für andere Werkzeuge, wie beispielsweise Storage Provisioning und Data Management, zur Verfügung.

In der Praxis

In der Praxis sieht das folgendermaßen aus: Beim Hochfahren eines Rechners übernimmt der Steuerungspfad die Aufgabe, die vorhandenen Platten zu katalogisieren und eine Mapping Table zu generieren (virtuelle vs. physikalische Adressen). Das System legt diese Tabelle dann in einem ASIC ab. Wenn nun im Betrieb eine Anwendung Daten anfordert, geht diese Anforderung zunächst an die virtuelle Adresse. Dabei wird ein bestimmter Port angesprochen. Hinter diesem Port arbeitet eine intelligenter, hochleistungsfähiger Prozessor (ASIC), der den Request über die Mapping Table so umsetzt, dass die Applikation die richtigen Daten von der richtigen physikalischen Speichereinheit erhält. All diese Vorgänge laufen über den Datenpfad ab. Auf diese Weise verlassen die Kundendaten nie die Fabric. Der Steuerungspfad dient also nur zum Beantworten von Inquieries und zum Abarbeiten von Fehlern. Das Volumen der über den Steuerungspfad übertragenen Kontrolldaten liegt insgesamt lediglich bei etwa zwei Prozent der Gesamtübertragung.

Der Vorteil dieser Technologie liegt vor allem in der Geschwindigkeit: Nur Storage-Komponenten mit getrennten Pfaden bieten die notwendige Kombination aus hoher Performance und Skalierbarkeit. Die Trennung zwischen dem Daten- und dem Steuerungspfad wird in der Industrie in der Regel als SPAID-Architektur (Split Path Acceleration of Independent Data Streams, auch: Split Path Acceleration of Intelligent Devices) bezeichnet. Sie macht eine unabhängige Skalierbarkeit der Virtualisierungsleistung auf Datenpfadebene und der Anwendungsleistung auf Steuerungspfadebene erst möglich.

Praktische Umsetzung

Anbieter leistungsfähiger Virtualisierungslösungen setzen auf hochskalierbare Einzelplattformen, die dazu in der Lage sind, auf einem hohen Leistungsniveau viele unterschiedliche Software-Anwendungen zu unterstützen, ohne dass es dabei erforderlich ist, für jede Applikation eine eigene Hardware-Plattform zu implementieren. Auf diese Weise haben sie die Möglichkeit, eine einzelne Investition für mehrere Software-Lösungen zu nutzen. In Zukunft werden die flexiblen Speicherplattformen auch zusätzliche Fabric-Dienste auf Software-Basis wie virtuelle Tape Libraries, Replikation und ständigen Datenschutz unterstützen.

Besonders innovative Produkte lassen sich sogar nahtlos in bestehende Produktionsumgebungen integrieren, ohne vorhandene Komponenten austauschen zu müssen. Es ist in solchen Fällen also nicht erforderlich, bestehende Speicherkomponenten (und Investitionen) abzuschreiben oder umfangreiche Rekonfigurierungen vorzunehmen. Wichtig ist jedoch, dass schließlich jegliche Zusatzfunktionalität dem ganzen Speichernetzwerk zur Verfügung stehen sollte und nicht auf bestimmte Ports oder Geräte beschränkt bleibt, um die Bildung von Inseln zu vermeiden. Ein Ansatz zum Beseitigen der durch den physikalischen Speicher gesetzten Limits darf keine neuen Einschränkungen im Netzwerk schaffen.

Management vs.Leistung

Traditionelle Ansätze zur Integration erweiterter Funktionen in SAN-Umgebungen (einschließlich Blades und Boxes), haben noch mit anderen Problemen zu kämpfen. So lassen sich beispielsweise Chassis-basierte Blades zwar gut verwalten, sind aber was ihre Leistung und Skalierbarkeit angeht, stark durch die Hitzeentwicklung und den Stromverbrauch eingeschränkt. In der Praxis schließen die Hersteller hier oft einen Kompromiss, bei dem die Leistungsfähigkeit der Komponenten auf der Strecke bleibt. Das gleiche gilt aber auch umgekehrt: Boxen, die gut mit Hitze umgehen können – zumeist handelt es sich dabei um voneinander getrennte Switches – bringen zwangsläufig einen höheren Verwaltungsaufwand mit sich.

Deswegen eignen sich in der Praxis die Produkte am besten, die als physikalisch unabhängige Module geliefert werden, dadurch eine hohe Leistung realisieren, gleichzeitig aber mit den bereits vorhandene Fabric-Verwaltungs-Tools gesteuert werden. Solche Lösungen verhindern Management-Overheads, garantieren eine hohe Leistung und sorgen gleichzeitig für Investitionsschutz.

Unabhängige Module

Im Betrieb lassen sich die modularen Lösungen über normale Fibre-Channel-Ports mit den Directoren verbinden. Die Directoren „absorbieren“ dann ihrerseits die Verwaltung des Moduls und stellen sie der gesamten Fabric als Virtualisierungs-Service zur Verfügung. Damit unterscheiden sich die genannten Produkte deutlich von Appliances und unabhängigen Switches, welche die Administratoren jeweils für sich verwalten müssen. Die Server und Speicherkomponenten des Produktionsnetzwerks bleiben von dem ganzen Vorgang unberührt. Im Betrieb leitet die Fabric nur „virtualisierten“ Verkehr für bestimmte Speichertransaktionen an das Virtualisierungsmodul weiter, und dieses führt dann die erforderlichen Line-Rate-Transaktionen durch.

Die dadurch entstehenden Vorteile liegen auf der Hand: Die Virtualisierungsmodule verfügen über eigene Kühlsysteme und Stromversorgungen, können bei neuen technologischen Anforderungen angepasst werden und arbeiten in Bezug auf Fibre Channel-Geräte generationsübergreifend. Das wiederum bedeutet in der Praxis, dass bestehende Kundenumgebungen, die in den letzten drei Jahren mit Fibre Channel-Directoren aufgebaut wurden, mit diesen neuen Fabric-Services aufgerüstet werden können. Gleiches gilt für aktuelle Anschaffungen sowie die Implementierung mit zukünftigen Directoren. Damit bieten diese Module einen einzigartigen Investitionsschutz über mehrere Fibre Channel Director Generationen.

Fazit

Viele Unternehmen haben bei der Arbeit mit Virtualisierungslösungen die Erfahrung gemacht, dass die Experimente zwar im Prinzip gut funktionierten, dass die Produkte sich aber gleichzeitig noch nicht ausreichend für den Einsatz in großen Produktivumgebungen skalieren lassen.

Desweiteren müssen auch die Möglichkeiten zur Fehlerannalyse und zum Fehlerlogging erweitert werden: Vor nichts haben die IT-Administratoren mehr Angst als einen „virtuellen Fehler“ in einer „virtuellen Storage-Welt“ zu suchen. Aus heutiger Sicht ist die zuvor erwähnte „Split-Path-Technologie“ als Hardware Platform die Lösung der Zukunft. Sie bietet heute alle Möglichkeiten, die Anforderungen an Performance, Skalierbarkeit, Hochverfügbarkeit, Managebarkeit und Investitionsschutz abzudecken. (mje)

Der Autor Martin Tutschek ist Solution Consult bei McData.