Konsolidierung und Virtualisierung von Speichersystemen im SAN mit dem IBM SAN Volume Controller

Aus Winfwiki

Wechseln zu: Navigation, Suche

1 Titel

Name des Autors: Tim Hauptmeier
Titel der Arbeit: Konsolidierung und Virtualisierung von Speichersystemen im SAN mit dem IBM SAN Volume Controller
Hochschule und Studienort: Fachhochschule für Oekonomie und Management in Essen
Datum der Erstellung: 13.02.2009


2 Inhaltsverzeichnis

Inhaltsverzeichnis


3 Abkürzungsverzeichnis

AbkürzungBedeutung
CompassCommodity Parts Storage System
DASDirect Attached Storage
FCFibre Channel
GBGigabyte
Gbit/sGigabit pro Sekunde
HBAHost-Bus-Adapter
ITInformationstechnologie
K-FallKatastrophen-Fall
LANLocal Area Network
MDiskManaged Disk
RAIDRedundant Array of Independent Disks
SANStorage Area Network
SDDSubsystem Device Driver
SVCIBM SAN Volume Controller
VDiskVirtual Disk
WANWide Area Network

4 Abbildungsverzeichnis

Abb.-Nr.Abbildung
1historisch gewachsene "Direct Attaches" als Insellösungen
2zwei parallele "Switched Fabrics" sorgen für Ausfallsicherheit
3IBM SAN Volume Controller als Clusterverbund
4IBM-Server x3250 als Administrationskonsole des SVC
5logischer Aufbau einer "Dual Fabric" nach Einzug des SVC
6Virtualisiserung physikalischer Disks
7Auslastungen von Storage Subsystemen im Vergleich mit/ohne SVC

5 Einführung

Virtualisierung ist aktuell eines der bedeutendsten Schlagworte der Informationstechnologie (IT). War Virtualisierung lange Zeit auf den Großrechnerbereich begrenzt oder nur für bestimmte Anwendungen im Einsatz, drängt diese Technologie immer weiter in alle Bereiche der IT vor. Sogar Heimanwender profitieren von den Vorteilen eine Hardware gleichzeitig mehreren Systemen parallel zur Verfügung zu stellen. Die Vorteile für Unternehmen scheinen leicht erkennbar: Angesichts steigender Energiepreise, der allg. Wirtschaftskrise und einer einhergehenden Rezession kann Virtualisierung dazu beitragen die vorhandenen Ressourcen besser zu nutzen und die Kosten für Neuanschaffungen bzw. Energie zu senken. Es stellt sich die Frage, ob diese (und möglicherweise weitere) Aspekte lediglich auf Serverstrukturen oder auch für andere Komponenten einer IT-Infrastruktur zutreffen.

Die Firma International Business Machines Corporation (IBM) bietet neben weiteren Firmen Systeme zur Virtualisierung von Speichernetzwerken und Storagesubsystemen an und ist mit mehr als 4600 installierten Systemen Marktführer in diesem Bereich [1].

Ziel dieser Hausarbeit ist es dem Leser einen Einblick in die wesentlichen Komponenten einer Storagevirtualisierung mit dem IBM SAN Volume Controller, sowie deren Verfahrensweisen, Ziele und Auswirkungen besonders in mittelständischen IT-Unternehmen zu geben.

6 typisches Storage-Design in mittelständischen Unternehmen

Es gibt mehrere Möglichkeiten, Rechnersysteme und Storage miteinander zu verbinden. Neben der einfachen, direkten Anbindung in mittelständischen Unternehmen finden sich dabei meistens historisch gewachsene Konstruktionen, die früher oder später zu einem Engpass in der Realisierung der Anbindung zwischen Rechnersystemen und Storage führen. Zur Verdeutlichung dieses Umstandes, werden in diesem Kapitel zunächst die einzelnen Baugruppen erläutert und anschließend die verschiedenen Arten des Storage-Designs aufgezeigt.

6.1 Hardware

6.1.1 Storage

Als Storage werden Massenspeichersysteme bezeichnet, auf denen Daten im großen Umfang zentral gespeichert werden. Je nach Anforderungen des Unternehmens an die Maßkennzahlen eines Storages wie, z.B. Geschwindigkeit, Datendurchsatzraten, Latenzzeiten, Ausfallsicherheit, Wartungsaufwand, Anschaffungskosten, Kapazität, Erweiterbarkeit, etc. können im SAN-Umfeld unterschiedliche Massenspeichersysteme zum Einsatz kommen. Gängige Systeme sind z.B.:

  • Tape Libraries (dt.: Bandbibliotheken),
  • Optical Libraries oder
  • Disk-Arrays.

Für zentrale Daten, welche häufig abgerufen oder verändert werden, haben sich die Disk-Arrays etabliert. Disk-Arrays können derzeit Speicher in Größenordnungen bis zu Petabyte (1015 Byte) bereitstellen. Diese Disk-Arrays bestehen aus einer Vielzahl von Platten, die in der Regel als "Redundandent Array of Independend Disks" (RAID) organisiert und zur Verfügung gestellt werden.

6.1.2 Verbindungskomponenten

Hinsichtlich der Anforderungen von Unternehmen lassen sich die Verbindungen zwischen den Rechnersystemen und einem oder mehreren Storage-Systemen auf zwei Arten herstellen:

  1. durch einen sog. "Direct Attach" oder
  2. über ein "Storage Area Network" (SAN)

Beim "Direct Attach" handelt es sich um eine Direktverbindung des/der Server mit einem oder mehreren Storagesystemen über Lichtwellenleiter. Dabei kann die Anbindung je nach Kritikalität der Daten auf dem Massenspeicher redundant über zwei Lichtwellenleiter oder als einzelne Verbindung erfolgen.

Abb. 1: historisch gewachsene "Direct Attaches" als Insellösungen
Abb. 1: historisch gewachsene "Direct Attaches" als Insellösungen


Ein SAN ist ein spezielles Netzwerk mit der Aufgabe Massenspeichersysteme mit Servern zu verbinden. Dabei wird ein SAN, im Gegensatz zu anderen Allzweck-Netzwerken (z.B. "Local Area Network" (LAN) oder "Wide Area Network" (WAN)), ausschließlich zum Transport von zu speichernden oder lesenden Daten benutzt. Mit der Hilfe eines SAN werden die Server nicht mehr direkt mit dem Storage verbunden, sondern die Kommunikation erfolgt über einen oder mehrere Switche die miteinander verbunden sind. In diesem Falle spricht man von einer "Switched Fabric", einem kaskadiertem Netzwerk, bestehend aus mehreren Switchen. Eine aus nur einem Switch bestehende Fabric ist bereits sinnvoll, sofern mehr Server einen externen Storage nutzen müssen, als dessen Anzahl an SAN-Adaptern einen Anschluss der Systeme als "Direct Attach" ermöglichen. Sobald ein zweiter Switch benötigt wird, um weitere Systeme an das SAN anzubinden, erfolgt bereits eine Kaskadierung. Innerhalb des SAN sind über das sogenannte "Zoning" dann Verbindungen zwischen den angeschlossenen Endgeräten definiert und realisert, in dem entweder Switch-Ports in eine Zone aufgenommen oder Beziehungen über den World Wide Name (WWN, 64 Bit Adresse zur eindeutigen Identifizierung der Engeräte oder Ports) definiert werden.

Um eine hohe Ausfallsicherheit zu gewährleisten, können Rechner- und Storagesysteme auch über mehrere Verbindungen in zwei physikalisch getrennte SANs arbeiten. Man spricht dann von einer "Dual Fabric".

Abb. 2: zwei parallele "Switched Fabrics" sorgen für Ausfallsicherheit
Abb. 2: zwei parallele "Switched Fabrics" sorgen für Ausfallsicherheit


Das in einem SAN benutzte Übertragungsprotokoll für die Datenübertragung lautet "Fibre-Channel" (FC). "FC ist die vorherrschende Architektur, auf welcher SAN Implementationen aufbauen. FC ist ein Technologiestandard, der Datentransfers von einem zum anderen Netzwerkzugangspunkt mit extrem hohen Geschwindigkeiten erlaubt. Aktuelle Realisierungen unterstützen Datentransfers mit bis zu 10 Gigabit pro Sekunde (Gbit/s) und mehr[2]." Die Entwicklung des Protokolls startete 1988 und ist seit ca. 1998 der gängige Standard in fast 90% aller SANs weltweit[3]. Nicht zuletzt der offene Standard verhalf dem Protokoll zum Durchbruch. Das Synonym "Fibre" deutet auf das ursprüngliche Übertragungsmedium für die Kommunikation hin, nämlich Lichtwellenleiter, welche Verbindungen über sehr weite Strecken ermöglichen. Mittlerweile ist das FC-Protokoll ebenfalls auf kupferbasierten Übertragungsmedien etabliert. Der Name des Protokolls wurde jedoch beibehalten.


Lichtwellenleiter (auch: Glasfaserkabel) sind in unterschiedlichen Längen erhältlich. An beiden Enden sind die Kabel mit Steckern ausgerüstet, die den Anschluss an einen Verteiler oder ein Endgerät ermöglichen. Jedes Gerät, welches mit einem Lichtwellenleiter verbunden werden soll, benötigt somit einen Adapter, der

  1. einen Anschluss für Lichtwellenleiter bietet,
  2. einen Decoder zur Wandlung von Licht- in elektrische Signale besitzt und
  3. das FC-Protokoll beherrscht.

Diese Adapter werden "Host-Bus-Adapter" (HBA) genannt und werden als optionale Steckkarten in Servern verbaut.

6.1.3 Software/Treiber

Um externe Disk-Arrays den Servern unterschiedlicher Hersteller mit diversen Betriebssystemen bereitstellen zu können, werden Treiber eingesetzt. Diese Treiber (auch "Device-Treiber") haben zunächst die Aufgabe die Kompatibilität der Speichermedien mit den Servern sicherzustellen. Des Weiteren kann erst durch die Nutzung des geeigneten Device-Treibers eine redundante Auslegung der SAN-Struktur (Dual Fabric) ausgenutzt werden, da diverse Technologien eingesetzt werden um allzu hohen Latenzen oder Ausfällen vorzubeugen. Sofern ein Server auf mehrere Speichersubsysteme unterschiedlicher Hersteller oder Typen im SAN zugreifen soll, benötigt er somit alle dafür erforderlichen Treiber.

6.2 Einschränkungen / Nachteile

Server direkt mit Storagesystemen über "Direct Attaches" zu verbinden ist sehr wohl die einfachste und günstigste Variante, doch birgt dieses Verfahren auch die meisten Nachteile. Die Anzahl der Server, welche mit den Speichersystemen verbunden werden ist begrenzt auf die Anzahl der am Storage vorhandenen Anschlüsse für Lichtwellenleiter. Ein Rechnersystem mit einem HBA kann auch immer nur mit einem Storage-System verbunden werden. Diese Beschränkung wirkt sich auch nachteilig auf die Auslastung des Storagesystems aus:

"Nehmen wir an, dass von 20 Servern jeder 100 Gigabyte (GB) externen Storage in einer "direct attach"-Umgebung allokiert, und zusammen somit 2000 GB Speicher benötigt werden. Ein Teil des Speichers auf jedem Storagesystem bleibt frei. Dieser Teil ist bekannt als sog. "white space", oder "headroom". Liegt die durchschnittliche Ausnutzung dieses "direct attached storage" (DAS) bei 50%, so bleiben 50% "white space" übrig. Werden insgesamt 1200GB des Storages genutzt, so verbleiben 800GB "white space". Durch Nutzung eines SAN ist es möglich eine höhere Auslastung zu erzielen, da jeder Server Zugriff auf alle Storagesysteme im SAN hat. In diesem Beispiel kann eine kleine Verbesserung der Storage-Auslastung von 10-20%, eine Einsparung von mehreren hundert GB Speicher bedeuten. Zusätzlich würde dies auf eine Abführung der Kosten für diesen überflüssigen Speicher schließen. Sofern ein Server den Ihm zur Verfügung gestellten Storage nicht komplett verbraucht, ist im Storage-Konsolidierungsmodell möglich, den freien Speicher rasch einem anderen Server zuzuweisen. Es ist ebenfalls möglich zusätzlichen Storage bereitzustellen, auf den alle Server zugreifen können – im Gegenteil zur Bereitstellung neuer Storagesysteme pro Server. In einer "direct attach"-Umgebung sind solche Anforderungen schwieriger umzusetzen, da hohe "white spaces" erforderlich sind, um ein Wachstum der Serversysteme zu ermöglichen[4]."

Der Einsatz einer Einzelswitch-Lösung ist begrenzt auf die Anzahl der zur Verfügung stehenden Anschlüsse zur Anbindung der Storage-Systeme und Server. Mit einem SAN, welches aus mehren Switchen besteht und dynamisch erweitert werden kann, lässt sich dieser Engpass bereits umgehen.

Es bleibt jedoch auch hier der generelle Nachteil des Einsatzes physikalischer Massenspeicher bestehen: Der Server benötigt für jedes Massenspeichersystem einen herstellerspezifischen Treiber, um dessen Speicherplatz zu nutzen. Sollen externe Speichermedien eines Servers z.B. über 3 verschiedene Massenspeicher im SAN verteilt werden, so werden auch drei unterschiedliche Treiber erforderlich. Nicht immer lässt sich dieses problemlos realisieren, da Treiber zum Teil untereinander nicht kompatibel sind. Eine gleichmässige und optimierte Ausnutzung des externen Speichers über mehrer Speichersysteme verteilt ist so nicht immer möglich. Der Umzug des externen Speichers zwischen den diversen Massenspeichern, erfordert auf dem betroffenen Server sowohl eine Downtime, als auch den Austausch des Treibers für den Storage.

Ferner verfügt jedes Storage-System über eine eigene Administrationsoberfläche, was die Verwaltung in einem sehr heterogenen Storageumfeld zusätzlich erschwert.

7 Virtualisierung mit dem IBM SAN Volume Controller

"In einem konventionellen SAN werden die physikalischen Disks vom Storage-Subsystem direkt an den/die Server weitergereicht[5]". Bei der sog. "In-band virtualization" übernimmt eine Appliance die Steuerung der physikalischen Disks von einem oder mehreren unterschiedlichen Disk-Subsystemen und stellt diese den ans SAN angebundenen Servern als virtuelle Disk zur Verfügung. Dafür wird die Appliance zunächst an das SAN angebunden und die physikalischen Speicherbereiche werden dieser Steuereinheit zugewiesen. Danach kann das System die Kontrolle und Virtualisierung übernehmen. Der "IBM SAN Volume Controller" (SVC) ist eine solche Appliance, der diese Aufgabe übernimmt.

Neben der Virtualisierung über den Einzug einer Appliance-Lösung ins SAN, gibt es derzeit weitere Lösungsansätze, wie z.B. die komplette Virtualisierung der SAN-Fabric[6]. In historisch gewachsenen SANs bedeutet der Aufbau einer Virtualisierung über die Fabric selbst einen großen finanziellen, als auch technischen Aufwand für den Umbau. IBM geht daher einen anderen Weg mit dem SVC. Dieser bietet nebst Vorteilen einer Virtualisierung eine einfache Integration in ein bereits vorhandenes SAN.

7.1 Hardware

Abb. 3: IBM SAN Volume Controller als Clusterverbund
Abb. 3: IBM SAN Volume Controller als Clusterverbund

Der SVC leistet die zentrale Steuerung unterschiedlicher und verteilter Massenspeicher. Es besteht die Möglichkeit die Kapazität der heterogenen Storages zu einem großen Pool zusammenzufassen und den angebundenen Serversystemen zur Verfügung zu stellen[7]. Realisiert wird dies durch den Einzug einer geclusterten Steuereinheit, welche je nach Größe des vorhandenen SANs aus 2-8 Clusterknoten besteht. Die Hochverfügbarkeit des Systems durch Clusterung ergibt sich aus dessen zentraler Funktion, die es ausfallsicher aufzubauen gilt.

Der SVC besteht aus n-mal (je nach Anzahl der Clusterknoten) IBM System xTM - Servern, welche auf x86-Architektur basieren und für den Einbau in ein Serverrack ausgelegt sind. Diese Hausarbeit beschäftigt sich mit einer Infrastruktur, in der 2 Clusterknoten für die gesamte "Switched Fabric" verbaut sind.


Abb. 4: IBM-Server x3250 als Administrationskonsole des SVC
Abb. 4: IBM-Server x3250 als Administrationskonsole des SVC

Des Weiteren wird der SVC mit einem weiteren x86-basierten IBM-Server x3250 ausgeliefert, der als Plattform für die grafische Administrationsoberfläche dient. Dieses System weist aktuell folgende Hardwarekonfiguration auf[8] (Stand 26.10.2008):

  • 2.13 GHz Intel Xeon dual core processor
  • 4 GB SDRAM
  • 2 x 160 GB SATA Hard Disk Drive

Die Administrationsplattform ist in der Regel nicht hochverfügbar ausgelegt, da diese keine produktions-, bzw. betriebsrelevanten Aufgaben erfüllt.

7.2 Software / Treiber

"Der IBM SVC basiert auf der "Commodity Parts Storage System" (Compass) Architektur, welche im Forschungszentrum von IBM in Almaden entwickelt wurde. (...) Der Code der Architektur basiert auf einem Linux-Kernel, jedoch nicht die Clusterfunktionalität. Diese Funktion ist Bestandteil der SVC Anwendungssoftware[9]." Die Administrationsplattform wird aktuell mit dem Betriebssystem Microsoft Windows Server 2003 Standard ausgeliefert[10]. Die Applikation zur Steuerung des SVC selbst basiert auf dem herstellerspezifischen Webserver "Websphere".

"Jeder SVC-Knoten stellt den HBAs der angebundenen Server externe Disks über mehrere Pfade durch das SAN zur Verfügung (i.d.R. 4 Pfade) [11]." Das Bereitstellen über mehrere Pfade ermöglicht eine höchstmögliche Verfügbarkeit eines Devices für den Host. Der Ausfall einer jeden Verbindungskomponente vom Host bis zum Storage kann dadurch abgefangen werden und eine unterbrechungsfreie Verfügbarkeit sichergestellt werden. Voraussetzung ist die redundante Anbindung eines Servers ans SAN. Viele Betriebssysteme unterstützen jedoch kein Multipathing, d.h. die Möglichkeit mehrere Abbilder eines Devices über unterschiedliche Pfade aufzulösen. Daher bietet IBM den proprietären Multipathing-Treiber "Subsystem Device Driver" (SDD) in Verbindung mit dem IBM SVC an. "Der SDD balanciert und optimiert die I/O-Arbeitslast zwischen den bevorzugten Pfaden des Servers zum SVC. Im Falle eines Fehlers auf allen bevorzugten Pfaden, steuert der SDD die nicht-bevorzugten Pfade auf gleiche Art und Weise. Sobald die bevorzugten Pfade wiederhergestellt sind, verläuft der Failback automatisch[11]."

7.3 Topologie

Nach dem Einzug des SVCs ins SAN ergibt sich ein leicht veränderter logischer Aufbau des Konstruktes. Beide Cluster in SAN A, als auch in SAN B werden redundant angebunden (auch hier gilt das Prinzip der Ausfallsicherheit). Da beide Cluster die Steuerung der Storage-Systeme übernehmen sind sie von der Priorität gleich kritisch, wie die "Switched Fabric" anzusiedeln.

Abb. 5: logischer Aufbau einer "Dual Fabric" nach Einzug des SVC
Abb. 5: logischer Aufbau einer "Dual Fabric" nach Einzug des SVC

7.4 Managed Disks

"Managed Disks" (MDisk) sind die in der Regel im RAID organisierten Festplatten eines oder auch mehrerer heterogener Storage-Systeme, die dem SVC als Speicher Pool zur Verfügung gestellt werden. Mehrer Managed Disks derselben Charakteristik (Geschindigkeit, Kapazität) können dabei zu einer Gruppe zusammengefasst werden. Der SVC verteilt dabei die Daten der Virtual Disks selbstständig auf diese Managed Disks. Dabei werden auch Verfahren genutzt, um die Geschwindigkeit von Schreibe- und Leseoperationen zu beschleunigen (Stripping: Das gleichmässige Verteilung der Daten auf alle Platten) und damit den Storage optimal auszunutzen. Die Zuteilung der Platten eines Storage Systems als Managed Disks an den SVC wird in der Regel nur einmalig vorgenommen, was den administrativen Aufwand auf dem jeweiligen Storage System minimiert.

7.5 Virtual Disks

"Virtual Disks" (VDisk) sind die Platten, die den Rechner Systemen vom SVC zur Verfügung gestellt werden. Dabei sind die Größe der Platten und die Zugehörigkeit der Virtual Disks zu einer Managed Disk oder einer Managed Diskgroup frei wählbar. Das zuordnen der Virtual Disks zu einem Rechnersystem findet auf dem SVC statt (Mapping). Man arbeitet also nur noch mit der Adminstrativen Oberfläche des SVC, um Speicherresourcen den Rechnersystemen zuzuordnen.

Virtuelle Platten können im laufenden Betrieb und im Hintergrund von einer Managed Disk auf eine andere Managed Disk migriert werden, also auch von einem Storage System auf ein anderes. Der Server, der diese Virtuelle Platte benutzt, kann dabei weiterhin ganz normal mit Ihr arbeiten.

Abb. 6: Virtualisiserung physikalischer Disks
Abb. 6: Virtualisiserung physikalischer Disks

7.6 Flash Copy

"Flash Copy" ist ein Verfahren des SVC zur Erstellung konsistenter Kopien von Speicher, welcher permanent verändert wird. Bei der Erstellung eines "Flash Copy" wird der I/O auf den Strorage für ein paar Sekunden "eingefroren", bis ein Abbild des zu kopierenden Speichers erstellt wurde. Danach läuft der I/O auf den Quellbereich normal weiter, während die Kopie (das Ziel) im Hintergrund mit dem Dateninhalt zum Zeitpunkt des Kopierstarts erstellt wird. Obwohl der Kopiervorgang einige Zeit in Anspruch nehmen kann, behält das Ziel den Datenstand, den die Quelle zum Zeitpunkt des Kopiervorganges hatte.

Der Einsatzbereich von Flash Copy ist sehr vielseitig, so kann dieser Mechanismus Systemkopien vereinfachen und beschleunigen, indem zunächst die Applikation auf System A gestoppt, danach ein Flash Copy initiiert und der Zielspeicher der Kopie System B zugewiesen wird. Die Speicherkopie steht System B unverzüglich zur Verfügung und somit kann die Applikation dort sofort mit dem konsistenten Datenstand von System A wieder in Betrieb genommen werden, ohne lange Downtimes für die Migration der Daten in Kauf zu nehmen.

Ebenso sind Nutzungsmöglichkeiten im Bereich Backup/Restore gegeben, indem das System A mit den Quelldaten kurz gestoppt, ein Flash Copy eingeleitet und die Datenkopie System B zur Verfügung gestellt wird. Über System B kann unverzüglich ein Backup gestartet werden, während das produktive System A wieder in Betrieb geht.

7.7 Metro-Mirroring

Die Funktion "Metro Mirrioring" bezeichnet die Möglichkeit ganze Datensätze synchron als Kopie bereitzustellen. Ein Datensatz stellt z.B. der gesamte externe Speicherplatz für einen dedizierten Server, der auf mehrere Festplatten verteilt ist, dar. Es besteht ferner die Möglichkeit diese Kopie auf zwei voneinander unabhängige SVC-Cluster zu spiegeln, was den Vorteil hat die Kopie geographisch unabhängig vorzuhalten. Praktische Anwendung findet dies zum Aufbau von Systemen, die im Falle einer Störung des Storages im Rechenzentrum A weiterhin verfügbar sein müssen. Ein Wiederanfahren des Systems mit der synchronen Kopie auf dem Storage in Rechenzentrum B ist innerhalb weniger Minuten möglich. Durch den parallelen Aufbau eines Systems in Rechenzentrum A und Rechenzentrum B und den Einsatz von Clustersoftware, kann diese Übernahme sogar vollautomatisch erfolgen.

8 Bedeutung für das Unternehmen

"Heutige Storage-Infrastrukturen werden durch Ihre Komplexität gehemmt. Die Infrastruktur ist unflexibel, schwierig zu verwalten und ihre Kosten sind nicht mit Ihrer Informationsdichte gleichzusetzen. (…). Heutzutage müssen IT-Administratoren mit einer großen Anzahl unterschiedlicher Systeme, Architekturen und Softwaresystemen arbeiten. Sie müssen sich Wissen über die Hard- und Software der diversen Hersteller zum gegenwärtigen Stand aneignen und gleichzeitig auf veralteten Konfigurationen arbeiten. (…). Die Vereinfachung der Infrastruktur hilft dem Geschäft zur Erfüllung der Anforderungen (…):

  • Beheben von Schwierigkeiten bei der Erfüllung administrativer Aufgaben und dem Aufbau neuer Anwendungen
  • Die Reduzierung von Testlandschaften…
  • Sie hilft menschliche Fehler zu vermeiden, welche Datenverlust nach sich ziehen können
  • Sie spart Zeit ein, die genutzt werden kann, um andere Geschäftsziele zu erreichen
  • Kosteneinsparung [12]."

8.1 Auswirkungen auf Speichersubsysteme

Durch den Einsatz von Massenspeichern in einer oder mehreren "Switched Fabrics" wird bereits deren Auslastung im Gegensatz zum "Direct Attach" verbessert. Jedoch besteht weiterhin das Problem unterschiedlich genutzter und ausgelasteter Speichersysteme im SAN. Durch die Zusammenfassung der physikalischen Disks unterschiedlicher Speichersubsysteme zu MDisks und der einhergehenden Bereitstellung dieses Speichers als VDisks an die angebundenen Server kann die Auslastung des Storages gleichmäßig verteilt werden[13]:

Abb. 7: Auslastungen von Storage Subsystemen im Vergleich mit/ohne SVC
Abb. 7: Auslastungen von Storage Subsystemen im Vergleich mit/ohne SVC

Die Einrichtung der vom Speichersubsystem zur Verfügung gestellten Festplatten in den SVC muss nur einmalig erfolgen. Danach stehen diese Disks dem SVC als MDisks permanent zur Verfügung.

Der SVC ist hardwareseitig mit einem großzügigen Schreib-/Lesecache ausgestattet. Je nach Auslegung des SVC steht ein Schreib-/Lesecache von 16-64 GB zur Verfügung. In diesem Cache werden häufig benutzte Speicherbereiche vorgehalten und den Serversystemen zur Verfügung gestellt. Das bedeutet, dass die Zugriffe auf diese Speicherbereiche ausschließlich im Cache des SVC stattfinden und nicht auf dem Storage erfolgen. Somit wird der Zugriff beschleunigt und die Speichersubsysteme entlastet.

8.2 Auswirkungen auf Server

Ändern sich die Anforderungen eines Serversystems an das Speichersubsystem (bspw. wird ein schnelleres System benötigt oder der Speicherbedarf übersteigt die Kapazität des Massenspeichers), so hat dies in einer nicht-virtualisierten Umgebung einen Umzug der betroffenen Speicherbereiche zur Folge, der wiederum eine geplante Ausfallzeit für den Server bedeutet. In dieser sog. "Downtime" muss zunächst das entsprechende Zoning angepasst werden. Danach erfolgt die Erzeugung von Speicherbereichen auf dem neuen Subsystem und deren Bereitstellung für den Server. Schließlich erfolgt ein Umzug der Daten von Speichersystem A nach Speichersystem B. Dieser Kopiervorgang muss häufig vom Serversystem aus administrativ gesteuert werden und bedarf der Kontrolle durch einen Systemverantwortlichen. Nach dem Kopiervorgang muss nochmals das Zoning verändert werden. Abschließend erfolgt ein Wiederanfahren des Serversystems auf dem neuen Storage. Für Umzüge von Speicherbereichen zwischen unterschiedlichen Storagesystemen über den SVC sind wesentlich weniger Schritte notwendig. So entfallen bspw. die Anpassungen des Zonings, sowie die Erstellung neuer Speicherbereiche. Die dem System zugewiesenen Speicherbereiche können einfach zwischen den Storagesubsystemen verschoben werden. Die Steuerung und Kontrolle des Vorganges steuert der IBM SVC. Besonders hervorzuheben ist, dass der Kopiervorgang online erfolgen kann, d.h. es ist keine Downtime für den betroffenen Server erforderlich. Waren in der physikalischen Umgebung noch mehrere Treiber für Festplatten von unterschiedlichen Storages erforderlich, so wird im SVC-Umfeld nur noch ein Treiber benötigt, der die VDisks des SVC interpretieren und am Serversystem anmelden kann. Die bereits genannten Vorteile des Schreib-/Lesecaches für die Massenspeichersysteme gelten ebenfalls für die Server. Auch die Server profitieren von schnelleren Plattenzugriffen.

8.3 Entkopplung von Funktionalität und Hardware

Durch die Einführung einer Storagevirtualisierung mit dem IBM SVC und der einhergehenden Bereitstellung von VDisks für die angebundenen Serversysteme erfolgt eine hardwareunabhängige Bereitstellung von Speicherplatz (siehe Kapitel Virtual Disks). War die Einrichtung zusätzlichen externen Speichers für an das SAN angebundene Server vor einer Virtualisierung mit dem IBM SVC an zahlreiche hardwarebedingte Einschränkungen gebunden, spielt dies nach einer Virtualisierung keine Rolle mehr. Dem Server wird vom SVC Speicherplatz zur Verfügung gestellt. Auf welchem Storagesubsystem der Speicher letztendlich abgelegt wird oder in welcher Lokalität ist aus Sicht der Server nicht mehr von Belang. Eine Steuerung und Koordinierung erfolgt ausschließlich über die MDisks, welche dem SVC definiert wurden (siehe Kapitel Managed Disks). Für den Server ist somit nur die Kompatibilität zum SVC als logische Ebene zwischen Endsystem und Storage von Bedeutung.

8.4 Strategische Vorteile

"Der heutzutage in hohem Maße konkurrierende Geschäftsmarkt erlaubt Unternehmen wenig Spielraum für Fehler, was Verfügbarkeiten, den fortlaufenden Betrieb und die Wiederherstellung nach ungeplanten Unterbrechungen betrifft. Nur wenige Ereignisse beeinflussen ein Unternehmen so sehr, wie der Ausfall von Computersystemen und das Auffinden der Störung mit den zur Verfügung stehenden Mitteln, selbst wenn es nur eine Angelegenheit von Minuten ist.

Gegenwärtig erwarten Kunden, Mitarbeiter und Zulieferer einen Geschäftsbetrieb rund um die Uhr und aus allen Winkeln des Globus. Ausfälle können dabei das Ansehen und das Markenbild zerstören[14]."

Unternehmen haben also ein begründetes Interesse an möglichst geringen Systemstillständen und an Werkzeugen zur schnellen Wiederherstellung der Betriebsbereitschaft bei ungeplanten Ausfällen der Informationstechnologie (IT). Durch die Virtualisierung des SAN als neuralgischen Knotenpunkt einer Rechenzentrumsinfrastruktur mit dem IBM SVC, wird diesem Interesse entsprochen. Die vollkommen redundante und somit ausfallsichere Auslegung sämtlicher Komponenten (angefangen bei zwei FC-Adaptern pro Server, doppelter Anbindung an zwei voneinander unabhängigen SANs ("Dual-Fabric") und der Steuerung des Storages über die fehlertolerante Konstruktion der Virtualisierung über den SVC), wird das Risiko von Verfügbarkeitsstörungen auf Grund von Hardwaredefekten drastisch minimiert. Ein Anwachsen der SAN-Landschaft im Unternehmen stellt keinerlei Probleme in Form von Umstrukturierungen oder Downtimes der angebundenen Systeme mehr dar. Bei einer "Dual Fabric" haben selbst Wartungsarbeiten an einem der beiden SANs keine Downtimes mehr zur Folge. Somit wird den Anforderungen an einen durchgehenden und störungsfreien Betrieb des SAN und des Storages in vollem Maße entsprochen.

Neben den bisher aufgeführten Vorteilen des IBM SVC bedeutet der Einsatz des Systems für das Unternehmen eine Herstellerunabhängigkeit im Storagebereich. Nahezu alle gängigen Storagesysteme, sowie Betriebssysteme unterschiedlicher Hersteller werden von der aktuellen Version 4.3.x des SVC unterstützt[15][16] (Stand 10.11.2008).

Ferner ermöglicht der IBM SVC über die sog. "Metro-Mirror"-Funktionalität die komplette Spiegelung von Datenbereichen über zwei oder mehr Rechenzentren. Diese Spiegelung verläuft synchron, sodaß beide Datenbereiche identische Informationen besitzen. Somit ist es dem Unternehmen möglich eine sog. "Katastrophenfall" (K-Fall)-Absicherung aufzubauen. Dies stellt einen wichtigen strategischen Vorteil dar, da der komplette Ausfall eines Rechenzentrums nur eine kurzzeitige Downtime der abgesicherten Systeme bedeutet.

9 Fazit

Durch die Erläuterung der Arbeitsweise des IBM SVC konnten die Auswirkungen einer Speichervirtualisierung auf die bestehende Infrastruktur aufgezeigt werden. Dabei zeigte sich, dass eine Virtualisierung sowohl Konsequenzen für die an das SAN angebundenen Systeme, als auch für administrative Aufwände und Tätigkeiten im SAN- und Storageumfeld eines Unternehmens hat. Die Einrichtung einer Storagevirtualisierung in eine bestehende Infrastruktur hilft heterogene Speichernetzwerke zu vereinfachen und deren Steuerung zu zentralisieren. Zudem erhöht sich die Möglichkeit Systemstillstände auf Grund von Speichermangel oder –ausfällen zu minimieren. Im Rahmen der Ausführungen wurden darüber hinaus diverse weitere Funktionalitäten vorgestellt, die einen noch flexibleren Umgang mit Daten erlauben.

Eine Storagevirtualisierung zeichnet sich dadurch aus, dass die physikalischen Grenzen von Speichersubsystemen nicht mehr länger von Bedeutung sind. Eventuelle Kompatibilitätsprobleme zwischen einzelnen Storage- und Serversystemen können ebenfalls durch den Einzug einer Virtualisierung als logische Ebene in ein vorhandenes SAN beseitigt werden.

Damit die Virtualisierung erfolgreich etabliert werden kann, muss das Speichernetzwerk zunächst diverse Anforderungen erfüllen, was Redundanzen, Aufbau und Kaskadierungen betrifft.

Sind diese Anforderungen erfüllt, kann eine zusätzliche logische Schicht in das SAN eingezogen werden. Diese logische Schicht übernimmt ferner die Steuerung der physikalischen Speichersubsysteme, sowie die Verteilung des gesamten verfügbaren Speichers über die möglicherweise recht heterogenen Systeme. Neben der Steuerung der Speichersubsysteme auf der einen Seite übernimmt diese logische Schicht auf der anderen Seite die Zuweisung des Speichers an die einzelnen angebundenen Serversysteme. Der den Servern zugewiesene Speicher kann somit auf mehrere Subsysteme verteilt werden, ohne dass mehrere Treiber für die unterschiedlichen Storagesubsysteme benötigt werden. Lediglich ein Treiber für die Zusammenarbeit mit der Virtualisierungsebene ist erforderlich. Neben der Harmonisierung des heterogenen Storages ist es weiterhin möglich, storageseitig konsistente Kopien von zugewiesenem Speicher zu erstellen, ohne dass das Serversystem dafür angehalten oder verändert werden muss. Eine Spiegelung von Speicherbereichen über mehrere Rechenzentren ist ein weiteres Feature, welches mit Hilfe der Speichervirtualisierung ermöglicht wird, da das betroffene Serversystem von dieser Aktion nichts bemerkt. Somit ist es möglich den Storage eines Servers gegen einen K-Fall abzusichern.

Die Steuerung des insgesamt zur Verfügung stehenden Storages erfolgt zentral über die logische Schicht (in diesem Falle der IBM SVC). Dadurch entfallen hohe administrative Aufwände zur Bedienung unterschiedlicher Speichersubsysteme. Die Zuweisung von Speicher zu Servern erfolgt ebenfalls über diese zentrale Komponente. Die Virtualisierungsschicht bildet somit die zentrale und einzige Steuerung des Speichers. Diese Tatsache bedingt die redundante Auslegung der Virtualisierungsebene, so dass diese gegen Ausfälle abgesichert ist.

Insgesamt bedeutet eine Storagevirtualisierung für das mittelständische Unternehmen eine größere Unabhängigkeit von Systemkompatibilitäten und weniger administrative Aufwände. Durch diese zusätzlichen Vorteile und die erweiterten Funktionen des IBM SVC im Speichermanagement gewinnt das Unternehmen an Flexibilität und kann die Verfügbarkeiten von Serversystemen deutlich erhöhen.

10 Fußnoten

  1. ↑ vgl. IBM Corporation (Hrsg.): Information Infrastructure Newsletter
  2. ↑ vgl. IBM Redbook: Introduction into Storage Area Networks, S.29
  3. ↑ vgl. SNIA.org (Hrsg.): Fibre Channel Features
  4. ↑ vgl. Brocade Communications Systems, Incorporated (Hrsg.):Brocade SAN Design Guide, S.12
  5. ↑ vgl. IBM Redbook: Implementing the IBM System Storage SAN Volume Controller V4.3, S.3
  6. ↑ vgl. EMC Corporation (Hrsg.): EMC White Paper "The next Phase of SANs and IT Consolidation", S.4f
  7. ↑ vgl. IBM Redbook: SAN Volume Controller: Best Practices and Performance Guidelines, S22
  8. ↑ vgl. IBM Corporation (Hrsg.): Master Console V4.2 Hardware Components
  9. ↑ vgl. IBM Redbook: Implementing the IBM System Storage SAN Volume Controller V4.3, S.12ff
  10. ↑ vgl. IBM Corporation (Hrsg.): Supported IBM System Storage SVC Console (SVCC) V4.1.1.544 Software
  11. ↑ 11,0 11,1 vgl. IBM Redbook: System Storage SAN Volume Controller, S.17
  12. ↑ vgl. IBM Redbook: Introduction into Storage Infrastructure Simplification, S.4f
  13. ↑ vgl. IBM Redbook: Introduction into Storage Infrastructure Simplification, S.94
  14. ↑ vgl. IBM Redbook: Using the SVC for Business Continuity, S.2
  15. ↑ vgl. IBM Redbook: Introduction into Storage Infrastructure Simplification, S.101f
  16. ↑ vgl. IBM Corporation (Hrsg.): Supported Hardware List, Device Driver and Firmware Levels for SAN Volume Controller

11 Quellenverzeichnis

[01] Brocade Communications Systems, Incorporated (Hrsg.):Brocade SAN Design Guide, 2002, 69 S., URL: http://www.brocadekorea.com/download/resource/53-0000231-03.pdf (Abrufdatum: 18.10.2008)

[02] EMC Corporation (Hrsg.): EMC White Paper “The next Phase of SANs and IT Consolidation”, 2006, 15 S., URL: http://germany.emc.com/collateral/hardware/white-papers/h2156-sans-it-consolidation.pdf (Abrufdatum: 26.10.2008)

[03] IBM Corporation (Hrsg.): Information Infrastructure Newsletter, URL: http://www-01.ibm.com/support/docview.wss?uid=swg27012086&aid=2 (Abrufdatum: 09.02.2009)

[04] IBM Corporation (Hrsg.): Master Console V4.2 Hardware Components, URL: http://www-01.ibm.com/support/docview.wss?rs=591&uid=ssg1S1002211 (Abrufdatum: 26.10.2008)

[05] IBM Corporation (Hrsg.): Supported IBM System Storage SVC Console (SVCC) V4.1.1.544 Software, URL: http://www-01.ibm.com/support/docview.wss?rs=591&context=STPVGU&context=STPVFV&q1=master+console&uid=ssg1S4000525&loc=en_US&cs=utf-8&lang=en (Abrufdatum 26.10.2008)

[06] IBM Corporation (Hrsg.): Supported Hardware List, Device Driver and Firmware Levels for SAN Volume Controller, URL: http://www-01.ibm.com/support/docview.wss?rs=591&uid=ssg1S1003277 (Abrufdatum: 10.11.2008)

[07] IBM Redbook: Implementing the IBM System Storage SAN Volume Controller V4.3, 7.Edition, IBM International Technical Support Organization, 2008, 970 S., URL: http://www.redbooks.ibm.com/redbooks/pdfs/sg246423.pdf ISBN 073843163X

[08] IBM Redbook: Introduction into Storage Area Networks, 4.Edition, IBM International Technical Support Organization, 2006, 352 S., URL: http://www.redbooks.ibm.com/redbooks/pdfs/sg245470.pdf ISBN 0738495565

[09] IBM Redbook: Introduction into Storage Infrastructure Simplification, 1.Edition, IBM International Technical Support Organization, 2006, 222 S., URL: http://www.redbooks.ibm.com/redbooks/pdfs/sg247114.pdf ISBN 0738494429

[10] IBM Redbook: SAN Volume Controller: Best Practices and Performance Guidelines, 1.Edition, IBM International Technical Support Organization, 2008, 326 S., URL: http://www.redbooks.ibm.com/redpieces/pdfs/sg247521.pdf ISBN 0738485780

[11] IBM Redbook: System Storage SAN Volume Controller, 5.Edition, International Technical Support Organization, 2007, 818 S., ISBN 073848850X

[12] IBM Redbook: Using the SVC for Business Continuity, 1.Edition, International Technical Support Organization, 2007, 266 S., URL: http://www.redbooks.ibm.com/redbooks/pdfs/sg247371.pdf ISBN 0738489336

[13] SNIA.org (Hrsg.): Fibre Channel Features, URL: http://www.snia.org/about/alliances/fcia/ (Abrufdatum: 15.10.2008)

Von „http://winfwiki.wi-fom.de/index.php/Konsolidierung_und_Virtualisierung_von_Speichersystemen_im_SAN_mit_dem_IBM_SAN_Volume_Controller“
Persönliche Werkzeuge