Virtualisierung von Storage Area Networks

Aus Winfwiki

1 Titel

Name der Autoren:	Kerstin Neu, Thorsten Schulte, Daniel Damm
Titel der Arbeit:	"Virtualisierung von Storage Area Networks"
Hochschule und Studienort:	FOM Leverkusen

2 Inhaltsverzeichnis

Inhaltsverzeichnis 1 Titel 2 Inhaltsverzeichnis 3 Abkürzungsverzeichnis 4 Abbildungsverzeichnis 5 Einleitung 6 Storage Area Network 6.1 Storage Infrastruktur 6.1.1 Switche 6.1.2 Anbindung von Storage Subsystemen 6.1.3 Anbindung von Hosts 6.1.4 Zoning 6.2 Features 6.2.1 Definition von LUNs 6.2.2 Cloning 6.2.3 Snapshots 6.2.4 Remote Mirroring 6.2.4.1 Synchron 6.2.4.2 Asynchron 6.3 Administration 6.3.1 In-Band-Management 6.3.2 Out-Band-Management 6.3.2.1 SNMP 6.3.2.2 WBEM 6.3.2.3 SMI-S 7 SAN Virtualisierung 7.1 Definition 7.2 Gründe für SAN Virtualisierung 7.3 Formen von SAN Virtualisierung 7.3.1 Blockorientierte und Fileorientierte Virtualisierung 7.3.2 In-Band Virtualisierung 7.3.3 Out of Band Virtualisierung 7.4 Features von SAN Virtualisierung 7.4.1 Herstellerübergreifende Administration 7.4.2 Skalierbarkeit 7.4.3 Migrationsfähigkeit / Flexibilität 7.4.4 Thin Provisioning 7.4.5 Quality of Service 7.4.6 Landschaftsübergreifende SAN Features 7.4.7 Hochverfügbarkeit 7.5 Verwaltung und Monitoring 7.6 Standards 7.7 Hersteller 7.7.1 IBM SAN Volume Controller 7.7.2 DataCore 7.7.2.1 DataCore SANmelody 7.7.2.2 DataCore SANsymphony 7.7.3 Hitachi Universal Storage Platform V 7.7.4 Hewlett Packard SAN Virtualization Services Platform (HP SVSP) 7.7.5 Benchmarks 7.8 Anwendungsbeispiele 7.8.1 Anwendungsbeispiele DataCore SANsymphony 7.8.2 Anwendungsbeispiele DataCore SANmelody 7.8.3 Anwendungsbeispiel DataCore SANmelody und SANsymphony(Felix Schoeller Gruppe) 7.8.4 Anwendungsbeispiel IBM SVC (British Telecom) 7.8.5 Anwendungsbeispiel IBM SVC (St. Michael) 7.9 Wirtschaftlichkeit 8 Fazit 9 Fußnoten 10 Glossar 11 Literatur- und Quellenverzeichnis

3 Abkürzungsverzeichnis

Abkürzung	Bedeutung
Abb.	Abbildung
ANSI	American National Standards Institut
CDP	Continuous Data Protection
CIM	Common Information Model
CIMOM	CIM Object Manager
CPU	Central Processing Unit
CRM	Customer Relationship Management
DAS	Direct Attached Storage
DMTF	Distributed Management Task Force
etc.	et cetera
Fa.	Firma
FC	Fibre-Channel
HBA	Host-Bus-Adapter
HP	Hewlett-Packard Development Company
HTTP	Hypertext Transfer Protocol
I/O	Input/Output
IBM	International Business Machines Corporation
iSCSI	internet Small Computer System Interface
LAN	Local Area Network
LUN	Logical Unit Number
MIB	Management Information Base
NAS	Network Attached Storage
NMS	Network Management System
o.g.	oben genannt
RZ	Rechenzentrum
SAN	Storage Area Network
SATA	Serial Advanced Technology Attachment
SCM	Supply Chain Management
SMI	Structure of Management Information
SMI-S	Storage Management Initiative - Specification
SNIA	Storage Networking Industry Association
SNMP	Simple Network Management Protocol
SPC	Storage Performance Council
SVSP	SAN Virtualization Services Platform
TB	Terrabyte
TWG	Technical Work Groups
UDP	User Datagram Protocol
VSM	Virtualization Services Manager
WBEM	Web Based Enterprice Management
WMI	Windows Management Instrumentation
XML	Extensible Markup Language
z.B.	zum Beispiel
24/7	24 Stunden täglich, 7 Tage pro Woche

4 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
01	San Switch
02	LC Fibre-Channel Kabel
03	Host-Bus-Adapter
04	SAN Infrastruktur
05	Copy-on-Write 1/3
06	Copy-on-Write 2/3
07	Copy-on-Write 3/3
08	synchrones Remote Mirroring
09	asynchrones Remote Mirroring
10	In-Band-Management
11	Out-Band-Management
12	Virtualisierungsorte
13	In-Band Virtualisierung
14	Out-of-Band Virtualisierung
15	Speicherauslastung vor und nach der Virtualisierung
16	Datenmigration mit IBM SVC
17	Thin Provisioning
18	Beispiel Hochverfügbarkeit Datacore

5 Einleitung

Storage Area Networks in Ihrer heutigen (2009) Ausprägung sind das Ergebnis stetig neuer und wachsender Anforderungen an die Datenhaltungssysteme. Waren hier zunächst Themen wie Performance und Sicherheit der Fokus der Entwicklungen, hat sich dies in den letzten Jahren gewandelt. Die fortschreitende Virtualisierung von Servern und Desktops setzen Hochverfügbarkeit und gute Skalierbarkeit des Speichernetzes voraus. Ein Ansatz diesen Anforderungen zu begegnen ist, die Virtualisierung des SAN. Durch die Entkopplung des bereitgestellten Speichers von den physikalischen Speicherressourcen sollen nicht nur die aufgeführten Anforderungen erfüllt, sondern auch die Verwaltung erleichtert und die Kosten reduziert werden.

Eine Strategie des voll virtualisierten Rechenzentrums soll der IT zu mehr Agilität, Effizienz und Hardwareunabhängigkeit verhelfen.

Die vorliegende Fallstudie soll zunächst einen Überblick über die Funktionsweise eines SANs geben und anschließend auf die Möglichkeiten, die sich durch dessen Virtualisierung ergeben, aufzeigen.

6 Storage Area Network

Ein Storage Area Network (SAN) bezeichnet ein vom LAN abweichendes, leistungsfähiges Netzwerk zwischen Speichersubsystemen und Servern, die auf diese Subsysteme zugreifen. Die Leistungsfähigkeit basiert auf der Verwendung von Glasfaserkabeln als Übertragungsmedium und blockorientierten Protokollen. Vor der Entwicklung von Speichernetzen war der Speicher dediziert am jeweiligen Gerät angeschlossen. Die Entwicklung zum Speichernetz kann an folgenden Entwicklungsstufen verfolgt werden:

Direct Attached Storage (DAS)

"Klassisch" wird das Speichermedium direkt an den Server angeschlossen. Diese Methode ist zwar sehr performant, hat aber den Nachteil, dass die Speicherressourcen nur unzureichend genutzt werden können. Soll durch den Einsatz von Raid-Verbünden die Performance und Sicherheit bei der Speichernutzung erhöht werden, gewinnt die unzureichende Speichernutzung an Dynamik.

Network Attached Storage (NAS)

Die Entwicklung von Network Attached Storage sollte diesem Umstand entgegenwirken. Bei diesem System handelt es sich im Prinzip um reine Fileserver. Daten werden also auf Dateiebene im Netzwerk zur Verfügung gestellt. Hierbei wird die vorhandene Ethernet-Infrastruktur genutzt. Durch die relativ kleinen Blockgrößen des Ethernetprotokolls und den daraus resultierenden Overhead, sowie der Verfügbarkeit der Daten ausschließlich auf Dateiebene stoßen NAS-Lösungen schnell an netzwerkbedingte Leistungsgrenzen.

Storage Area Network (SAN)

Die Limitierungen des NAS werden durch ein SAN aufgehoben. Neben dem LAN wird eine paralleles Netz eigens für die Kommunikation zwischen Anwendungs-/Datenbankservern und den angeschlossenen Speichersubsystemen geschaffen. Diese Infrastruktur wird im nachfolgenden Kapitel näher beschrieben. Anstelle des Ethernet-Protokolls kommen blockorientierte Protokolle wie iSCSI oder Fibre-Channel zum Einsatz. Hierdurch kann der notwendige Datenfluss stark reduziert werden. Auf diese Weise können Übertragungsraten von bis zu 16 Gbit/s (Stand Juni 2009) erreicht werden. Durch den geringen Overhead beim Einsatz blockorientierter Protokolle resultiert eine mögliche Netto-Datenrate von ca. 1,6 GB/s.

6.1 Storage Infrastruktur

Zum reibungslosen Betrieb einer herkömmlichen SAN Infrastruktur sind verschiedene Komponenten notwendig, die je nach Bedarf an Ausfallsicherheit und Hochverfügbarkeit unterschiedlich konfiguriert und miteinander verbunden werden können. Zur Übertragung der Daten von einem zentralen Storage System zu einem angeschlossenen Host kann z.B. das bestehende LAN genutzt werden. In diesem Fall erfolgt die Kommunikation über das iSCSI Protokoll. Dies ist eine verhältnismäßig kostengünstige Alternative zum Anschluss von zentralem Storage. Außer dem Storage und eventuell zusätzlichen Netzwerkkarten auf Hostseite zur Steigerung der Performance, ist keine zusätzliche Infrastruktur erforderlich. Größere Installationen setzen jedoch zur Trennung des Netzwerk- und Storagedatenverkehrs auf einer eigenen Infrastruktur auf. Hier erfolgt der Datenverkehr über eigens dafür vorgesehene Switche mittels des Fibre-Channel(FC)Protokolls^[1]. Virtualisierungslösungen unterstützen in der Regel beide Topologien. Wenn Unternehmen über eine Virtualisierung nachdenken, ist häufig bereits eine heterogen gewachsene Fibre-Channel-Struktur mit angeschlossenen Storagesystemen verschiedener Hersteller gegeben. In diesem Fall spielen die eventuell zusätzlich vorhandenen, über iSCSI verbundenen Geräte eher eine untergeordnete Rolle, da diese den günstigeren Speicherbereich für weniger wichtige Anwendungsfälle darstellen. Aus diesem Grunde werden die Komponenten einer SAN Infrastruktur im Folgenden unter der Annahme beschrieben, dass der Datenverkehr mittels eigener Fibre-Channel-Switche über das FC-Protokoll erfolgt.

6.1.1 Switche

Eine Anbindung von Storage an einen Server via FC Protokoll kann nach drei unterschiedlichen Topologien erfolgen. Die einfachste Möglichkeit stellt eine direkte Verbindung zwischen Server und Festplattensubsystem dar. Dies wird als Point to Point Verbindung bezeichnet. Etwas komplexer ist die Variante, bei der Server und Storage Systeme ringförmig miteinander verbunden werden. Eine solche Verbindungsart stellt eine Arbitrated Loop Topologie dar. Aufgrund der Skalierbarkeit hat sich jedoch die Fabric Topologie durchgesetzt, bei der Switche zur Herstellung der Verbindung zwischen Server und Storagesystem zum Einsatz kommen^[2]. Vor diesem Hintergrund wird im weiteren Verlauf dieser Arbeit immer von einer Fabric Topologie ausgegangen. Aktuelle Fibre-Channel Switche bieten Übertragungsraten von bis zu 8Gbit/s ^[3]. Zur Eliminierung von Single Points of Failures und Erreichung von Hochverfügbarkeit sind pro Standort mindestens zwei nicht miteinander verbundene Switche empfehlenswert. Eine solche Konfiguration wird Dual-Fabric genannt. Switche, die untereinander verbunden sind, gehören genau einer gemeinsamen Fabric an. Da Konfigurationsänderungen an SAN Switchen immer Fabricweit erfolgen (für alle miteinander verbundenen Switche), kann nur über eine Dual-Fabric gewährleistet werden, dass ein Produktionsausfall aufgrund eines Administrationsfehlers vermieden werden kann^[4]. Für die Verbindung von Fibre-Channel-Switchen untereinander gibt es verschiedene Möglichkeiten. Die Auswahl der geeigneten Topologie hängt von den jeweiligen Ansprüchen an Skalierbarkeit, Performance, and Hochverfügbarkeit ab. Mögliche Topologien sind Cascade, Ring, Partial Mesh und Full Mesh. Während Cascade einer Bus-Topologie gleicht, in der jeder Switch mit einem Vor- und eventuell einem Nachgänger verbunden ist, sind im Falle von Full Mesh alle Switche einer Fabric untereinander verbunden^[5]. Je mehr Inter-Switch Verbindungen, desto höher die Performance und Verfügbarkeit und desto mehr Ports werden für reine Switchverbindungen verbraucht.

6.1.2 Anbindung von Storage Subsystemen

Die Anbindung der Storage Subsysteme an die Switche erfolgt heute fast ausschließlich über Glasfaserleitungen. Es haben sich verschiedene Steckertypen etabliert, auf die an dieser Stelle nicht detailliert eingegangen wird. Storage Subsysteme haben mehrere SAN Anschlüsse, die wahlweise zum Bereitstellen von Speicherressourcen für die einzelnen an das SAN angeschlossenen Server oder für die Kommunikation mit einem anderen Plattensubsystem genutzt werden können. Hierüber können beispielsweise Datenspiegelungen betrieben werden. Auch Storage Systeme müssen in sich hochverfügbar sein, daher sind intern in der Regel zwei Controller verbaut, die den Storage verwalten. Im Normalbetrieb teilen sich diese Controller die auf dem System, durch Plattenzugriffe, generierte Last. Im Failover Fall kann jeder Controller die Arbeit des anderen Controllers übernehmen^[6]. In einer solchen Konstellation bietet sich eine Verkabelung wie in Abb. 04 dargestellt an.

6.1.3 Anbindung von Hosts

Auch die Anbindung der Server, deren Speicherplatz über ein SAN konsolidiert wird, erfolgt heute weitgehend über Glasfaserkabel. Zur Verbindung des Switches mit dem Serversystem ist auf Seiten des Servers mindestens ein sog. Host-Bus-Adapter erforderlich. Wenn eine Dual-Fabric zur Vermeidung des Single Point of Failures genutzt werden soll, benötigt jeder Host mindestens zwei oder einen Dual-Port Adapter. Diese Realisierung einer dualen Anbindung ist in Abb. 04 dargestellt.^[7]. Bei nicht virtualisierten SAN Umgebungen gibt es Einschränkungen bezüglich der gleichzeitigen Anbindung von Hosts an mehrere Storage Systeme, vor allem, wenn diese von unterschiedlichen Herstellern kommen^[8].

6.1.4 Zoning

Ähnlich wie bei einer MAC-Adresse im Ethernet, hat auch im FC-Umfeld jeder Teilnehmer eine eindeutige Identifikationsnummer pro an den Switch angeschlossenem Port. Diese Identifikationsnummer nennt man WWPN (World Wide Port Number). Hierdurch kann jeder Host-Bus-Adapter-Port (Initiator) eindeutig identifiziert werden. Um einen möglichst störungsfreien Betrieb gewährleisten zu können, wird mittels des Zonings erreicht, dass jeder Teilnehmer im SAN nur Verbindungen zu Partnern aufbauen kann, mit denen er auch tatsächlich kommunizieren muss. Vor allem wird hierdurch vermieden, dass sich HBA's der angeschlossenen Server gegenseitig erkennen und stören würden. Angenommen ein Datenbankserver sei mit zwei HBAs über zwei Switche mit einem Plattensubsystem verbunden, welches über vier Hostanschlüsse verfügt. Damit der angschlossene Server über alle redundanten Pfade Zugriff auf die ihm dargebotenen LUNs bekommen kann, müssen beide HBAs Zugriff auf alle vier Hostanschlüsse des Disk Systems bekommen. Häufig werden für jeden Host-Bus-Adapter eines Servers Zonen angelegt, in denen der Initiator selbst und die in unserem Beispiel vier Anschlüsse des Plattensubsystems (Targets) aufgenommen werden. Dies ist zwar sehr übersichtlich seitens der Administration, birgt jedoch den Nachteil, dass sich die vier Targets untereinander kommunizieren können. Vor diesem Hintergrund wird ein eins zu eins Zoning empfohlen ^[8]. Hierzu wird für jedes Initiator-Target Pärchen eine eigene Zone angelegt. Die Zonen können wahlweise auf Grundlage der Portnummern seitens der Switche (Port Based Zoning) oder auf Basis der WWPN Nummern der angeschlossenen Komponenten erfolgen (WWPN Based Zoning)^[9]. Portbased Zoning hat den Vorteil, dass nach einem Auswechseln von Adapterkarten die Konnektivität bestehen bleibt. WWPN Based Zoning hingegen gestattet es, die verschiedenen Teilnehmer an einem beliebigen Port der Switche aus einer gemeinsamen Fabric zu verbinden. Grundsätzlich ist die Auswahl der Methode eine "Geschmacksfrage" mit leichter Tendenz zum WWPN Based Zoning, da diese Form eine etwas größere Flexibilität bietet.

6.2 Features

Features bedeute zu Deutsch Fähigkeiten, Eigenschaften oder Besonderheiten und sind damit in Bezug auf Systeme zusätzliche Dienste. Heute sind das in Bezug auf Storage Area Networks vor allem Cloning (Instant Copies), Remote Mirroring, Snapshots und Definition von LUNs (LUN Masking). Diese Begriffe werden im Folgenden genauer erläutert.

6.2.1 Definition von LUNs

"Ein [...]Subsystem stellt die Speicherkapazität seiner internen physikalischen Festplatten Servern zur Verfügung, indem es über die Anschlussports den Zugriff auf einzelne physikalische Festplatten oder auf mittels RAID zusammengefasst virtuelle Festplatten ermöglicht. Alle außerhalb des Disksubsystems sichtbaren Festplatten, physikalische wie virtuelle, werden in Anlehnung an das SCSI-Protokoll auch als LUN (Logical Unit Number)"^[10]

"LUN Masking schränkt den Zugriff auf die Festplatten ein, die das Subsystem an die angeschlossenen Server exportiert."^[10]

Verzichtet man auf LUN Masking müssen Server sorgfältig konfiguriert werden um den Schutz der Daten zu gewährleisten. Das LUN Masking bringt Ordnung in das Chaos, indem es Festplatten nur für bestimmte, den ihnen zugeordneten, Server zuteilt. ^[11]

Beim LUN Masking kann man zwischen portbasiertem LUN Masking und rechnerbasiertem LUN Masking. Beim portbasierten LUN Masking sind die Festplatten für alle Rechner sichtbar die über den gleichen Port an das Subsystem angeschlossen sind. Hingegen beim rechnerbasierten LUN Masking sieht jeder Rechner nur die Festplatten die ihm zugeteilt sind. ^[12]

6.2.2 Cloning

Unter Cloning oder Instant Copy versteht man das Klonen von Daten, das heißt Daten von einem Subsystem auf ein anderes zu kopieren um so beispielsweise Testdaten, Datensicherungen und Datenkopien für das Data Mining zu erzeugen.^[13] Auch wenn es scheint das "mehrere Terabyte große Datenbestände innerhalb eines Subsystems in wenigen Sekunden virtuell kopiert"^[14] werden, dauert es tatsächlich wesentlich länger^[13]. So kosten alle Realisierung von Instant Copies Rechenzeit und Cache ^[15] „und belastet interne I/O Kanäle und Festplatten.“ ^[16] Es gibt viele Arten der Implementierung im Folgenden werden zwei näher erläutert, Abspaltung eines Spiegels und Kopieren im Nachhinein.

Abspaltung eines Spiegels

"Mit dem Kopierbefehl werden beide Spiegel getrennt: Der abgetrennte Spiegel kann dann unabhängig vom Original benutzt werden. Nach dem Abtrennen des Spiegels sind die Produktionsdaten nicht mehr vor dem Ausfall einer Festplatte geschützt. Zur Erhöhung der Datensicherheit werden deshalb vor dem Abtrennen des Spiegels oft drei Spiegel […] gehalten, sodass nach dem Abtrennen der Kopie die Produktionsdaten immer noch gespiegelt werden."^[16]

Kopieren im Nachhinein

"Vor dem Kopierbefehl werden in diesem Fall überhaupt keine Daten (kopiert), sondern erst nachdem die Instant Copy angefordert wird. Der Controller verwaltet dazu zwei Datenbereiche: einen für die Originaldaten und einen für die mittels Instant Copy erstellte Datenkopie. Der Controller muss dafür sorgen, dass er bei Schreib- und Lesezugriffen auf die Originaldaten und Datenkopien die jeweiligen Blöcke in die entsprechenden Datenbereichen schreibt bzw. aus den entsprechenden Datenbereichen liest. [...] Manche Implementierungen kopieren nur die Blöcke, die [...] verändert werden; andere kopieren alle Blöcke".^[16]

Lesezugriffe werden je nachdem ob ein Block verändert wurde aus dem Bereich der Datenkopie oder wenn sie nicht verändert wurde aus dem Originaldaten bedient. Bei Schreibzugriffen ist der Zugriff auf die Datenkopie unproblematisch die Daten werden dann im nächsten Schritt darf der Controller die veränderten Blöcke in den Bereich für die Originaldaten kopiert.^[17]

Eine weitere wichtige Funktion der Instand Copy ist die Umkehrung der Instand Copy im Fehlerfall.^[18] "Am einfachsten geht dies, wenn man die Anwendung herunterfährt, dann die Daten der Produktivfestplatten per zweiter Instand Copy von der Kopie auf die Produktivfestplatte zurückkopiert und dann die Anwendung wieder hochfährt."^[19]

6.2.3 Snapshots

Unter einem Snapshot im SAN - Umfeld versteht man eine sofortige, momentane, virtuelle Kopie einer LUN bzw. einer LUN-Gruppe innerhalb eines Storage Systems. Es handelt sich also um eine Momentaufnahme des aktuellen Datenbestandes ohne dass ein tatsächliches Kopieren von Daten erforderlich ist, daher kann dieser Vorgang auch für Terabyte große Datenbestände in Sekundenschnelle vollzogen werden. Sowohl die virtuelle Kopie, als auch das Original können von zwei verschiedenen Hosts sowohl lesend, als auch schreibend in Zugriff genommen werden. Zum Zeitpunkt des Snapshots wird mittels Zeiger auf die aktuellen Datenblöcke des aktuellen Datenbestandes referenziert. Erfolgen nun Änderungen am Original oder am Snapshot, so werden diese in einem dafür vorgesehenen Speicherbereich gesondert abgespeichert. Außerdem werden die Zeiger für Originaldaten und Snapshot entsprechend angepasst ^[20].

Motivationen zur Erstellung von Snapshots:

• Erstellen von sekundenschnellen konsistenten Datensicherungen
• Erstellen von eigenständigen Systemkopien
• Basis für schnelles Recovery von Systemen (Vorstufe von CDP)
• Bereitstellen von Teststellungen

Ohne den Einsatz von Snapshot-Technologien müssen Anwendungsserver und insbesondere Datenbankserver in der Regel für den Zeitpunkt der Datensicherung in einen konsistenten Zustand gebracht werden. Dies bedeutet das Stoppen der Applikation bzw. der Datenbank und ist in einem 24/7 Betrieb oft nicht akzeptabel. Dies lässt sich durch den Einsatz von Snapshots umgehen, indem für die kurze Dauer des Snapshots auf Seiten der Anwendung für eine Schreibpause gesorgt wird. Nach wenigen Sekunden kann der Betrieb mit Fertigstellung des Snapshots wieder aufgenommen werden. Dies stellt sich für den Anwender in der Regel durch kurzzeitiges Anzeigen einer Sanduhr dar. Danach können andere Systeme für die Dauer des Backups auf den Snapshot zugreifen. Ist das Backup erfolgt, kann der Snapshot wieder verworfen werden. Z.B. zum Aufbau von Teststellungen werden für aussagekräftige Tests häufig aktuelle Kopien des Originalsystems benötigt. Mittels Snapshots kann solch eine Kopie ebenfalls unterbrechungsfrei für das Originalsystem erfolgen. Hierzu wird wie im obigen Beispiel ein Snapshot der Original LUNs erzeugt. Dieser wird zur Erstellung einer konsistenten Kopie auf eine neu angelegte LUN mit gleicher Größe wie die Original-Lun benötigt. Solche Kopien innerhalb einer SAN Umgebung können automatisiert und mit höherem Datendurchsatz erstellt werden, als z.B. durch Wiederherstellung einer Sicherung vom Backup Medium. Wenn schnelle Recoveryzeiten erforderlich sind werden Snapshots auch zusätzlich zum herkömmlichen Backup als Datensicherungsmöglichkeit verwendet. Durch Erzeugen mehrerer Backups pro Tag kann das betroffene Serversystem sehr schnell auf jeden Datenstand der jeweiligen Snapshot-Zeitpunkte zurückgesetzt werden. Dies stellt die technische Grundlage für Continous Data Protection dar. Dies ist eine Technik, bei der automatisiert jede Änderung der Daten einen Snapshot auslöst. Hierdurch kann ein angeschlossenes System auf jeden Zeitpunkt des eingestellten Zeitfensters zurückgesetzt werden^[21].

Grundsätzlich gibt es zur Erstellung von Storage - Snapshots im Wesentlichen die beiden Verfahrensweisen Copy-on-Write und Split Mirror. Im Rahmen von SAN Storage hat sich jedoch die erstere Methode etabliert, die aus diesem Grunde im Folgenden näher erläutert werden soll^[22].

Abb. 05: Copy-on-Write 1/3, Schreibvorgang Server 1[20]

Abb. 06: Copy-on-Write 2/3, Kopieren der Originalblöcke in einen Pufferbereich[20]

Abb. 07: Copy-on-Write 3/3, Ändern der Zeiger auf den Snapshot[20]

Wie bereits geschildert werden bei dem Copy-on-Write Verfahren zum Zeitpunkt des Snapshots keinerlei Daten bewegt oder kopiert. Die bestehenden Blöcke einer LUN werden lediglich mittels Zeigern referenziert. So verweist der Snapshot unmittelbar nach seiner Erzeugung auf die originalen Datenbereiche. Erfolgt nun ein schreibender Zugriff von Server 1 (Abb. 05), so werden die betroffenen Blöcke vor der Datenmanipulation in einen Pufferbereich kopiert. Außerdem wird ein Flag gesetzt um zu kennzeichnen, dass der Originalblock verändert wurde (Abb. 06). Danach werden die Zeiger des Snapshots entsprechend auf die kopierten Blöcke im Pufferbereich umgesetzt (Abb. 07). So wird gewährleistet, dass dieser Snapshot immer den konsistenten Datenbestand zum Zeitpunkt seiner Erzeugung beinhaltet. In der Regel bieten Storage Systeme auch die Möglichkeit an, auf den Snapshot schreibend zugreifen zu können. Um dies zu realisieren, werden die in den Pufferbereich kopierten Originale ein weiteres mal kopiert und gekennzeichnet, so dass in jedem Fall wieder auf den Ursprungszustand zurückgegriffen werden kann^[23].

6.2.4 Remote Mirroring

Mit Snapshots erstellte Kopien eignen sich zum Schutz vor dem versehentlichen Löschen von Daten oder logischen Fehlern wie Sie bei der Verwendung von Datenbanken auftreten können. Beim Ausfall oder Untergang eines kompletten Disksubsystems ist diese Technik jedoch nicht hilfreich. Ebenso wie die Originaldaten wären die erstellten Kopien in so einem Fall nicht erreichbar, da sie sich auf dem gleichen System befinden. Aus diesem Grund ist die redundante Auslegung von Disksubsystemen obligatorisch.^[24] Die Spiegelung auf ein zweites Disksubsystem, welches sich in sicherer Entfernung zum ersten System befindet nennt man Remote Mirroring oder auch Remote Replication.

Diese Funktionalität ist fester Bestandteil moderner Disksubsysteme und wird vollständig von diesen ausgeführt. Angeschlossenen Applikationsservern bleibt die Funktionalität verborgen, ihre Ressourcen werden hierdurch nicht angetastet. In Abhängigkeit vom Zeitpunkt der Replikation unterscheidet man zwischen synchronem und asynchronem Remote Mirroring.

6.2.4.1 Synchron

Dieser Zeitpunkt ist beim synchronem Remote Mirroring vor der Quittierung eines Schreibvorgangs an den angeschlossenen Server. Ein Schreibvorgang läuft also nach folgendem Schema ab: Ein Server löst einen Schreibbefehl für ein Disksubsystem aus. Dieses führt den Befehl aus und gibt den entsprechenden Befehl an das Replika-Disksubsystem ab. Erst wenn dies den Schreibbefehl quittiert wird die Quittung zum auslösenden Server abgegeben.

Abb. 08 zeigt das Schema des synchronen Remote Mirrorings. Der Vorteil dieser Variante der Replikation liegt darin, dass die Daten auf dem zweiten Disksubsystem immer auf dem neusten Stand sind. Fällt das Primärsystem aus, kann der Betrieb auf dem Sekundärsystem mit dem aktuellen Datenstand fortgesetzt werden.^[25] Der Nachteil dieser Vorgehensweise liegt in der Verzögerung, die durch den zweiten Schreibvorgang und das Abwarten der Quittierung entsteht. Ist die Performance der Sekundärsysteme nicht ausreichend oder die Entfernung dieser Systeme zu groß (> ca. 5 km), ist das asynchrone Remote Mirroring vorzuziehen, da es sonst zu spürbaren Verzögerungen bei den Anwendungen kommt.

6.2.4.2 Asynchron

Hier quittiert ein Disksubsystem den vom Server ausgelösten Schreibbefehl sofort nachdem er ausgeführt (bzw. im Cache zwischengespeichert) wurde. Die Replizierung findet erst in einem nachgelagerten Vorgang statt. Die Quittung des Sekundärsystems ist für den auslösenden Server obsolet.

Die schnellen Antwortzeiten, die auf diese Weise realisiert werden können haben Ihren Preis: Der Ablauf des asynchronen Remote Mirroring, wie ihn Abb. 09 zeigt, birgt den Nachteil, dass die Daten auf dem Sekundärsystem nicht auf dem neusten Stand sind.

6.3 Administration

Für die Verwaltung wie auch das Monitoring eines virtualisieren Speichernetzes gilt: Ein zentrales Tool zur Verwaltung und Überwachung ist notwendig, um den Überblick zu wahren und die Kosten im Zaum zu halten. So gehen Experten davon aus, dass bis zum zehnfachen der Anschaffungskosten für die Verwaltung eines Speichernetzes aufgebracht werden müssen. Grundsätzlich reichen zentrale Verwaltungs- und Überwachungstools nicht an die Verwaltungstiefe heran, die das jeweils proprietäre Verwaltungswerkzeug des Herstellers eines Speichergeräts bietet. Für die tägliche, administrative Arbeit ist der Einsatz einer zentralen Verwaltung und Überwachung unerlässlich.

Im nachfolgenden werden verschiedene Möglichkeiten der zentralen Administration und Überwachung von virtualisierten Speichernetzen vorgestellt.

6.3.1 In-Band-Management

Als In-Band-Management bezeichnet man die Administration der Geräte eines Netzwerkes aus selbigem heraus. Im Bezug auf Speichernetze bedeutet dies, dass die angeschlossenen Speichergeräte über das SAN selbst administriert werden, also über Fibre-Channel. Die Kommunikation stützt sich hierbei auf einen Management-Agent, der sowohl mit dem LAN als auch mit dem SAN verbunden ist.

Über eine API und den ANSI-Standard FC-GS-4 können so verschiedene Management-Dienste realisiert werden:

• Discovery
• Überwachung
• Nachrichten

Für die Dienste Discovery und Überwachung ergibt sich bei dem In-Band-Management die Limitierung auf die jeweilige Zone. Dies kann Überwunden werden indem entweder der Management-Agent in allen zu überwachenden Zonen platziert wird oder man richtet entsprechende Fibre-Channel Dienste ein, die das Sammeln oder Eintragen von Informationen gestatten und von der Zoning-Problematik nicht betroffen sind.^[26]

6.3.2 Out-Band-Management

Das Out-Band-Management kombiniert zur Vereinheitlichung der Administration die Ethernet-Schnittstelle, die nahezu jedes Speichergerät in einem SAN aufweist, mit bereits bestehenden Standards zur Systempflege und -überwachung.

6.3.2.1 SNMP

Bei Simple Network Management Protocol (SNMP) handelt es sich streng genommen ausschließlich um ein Kommunikations-Protokoll. Das Akronym wird jedoch pars pro toto für das Protokoll und das Informationsmodell SMI (Structure of Management Information) genutzt.^[27] Der Vorteil von SNMP ist, dass aufgrund der Verbreitung des bereits 1988 verabschiedeten Standards nicht nur Speichergeräte, sondern diverse Hardware in einem zentralen Management-System verwaltet werden können. Die Verwaltung von SNMP-fähigen Geräten erfolgt mittels eines Network Management Systems (NMS). Hierbei erfolgt die Verwaltung der Geräte durch sogenannte Managed Objects. Damit das NMS die Managed Objects kennt wird eine Management Information Base (MIB) in das NMS eingelesen. Ist dies geschehen können entsprechende Daten per Request abgefragt und per Nachricht (Trap) gesendet werden. Um im Bereich der Speichergeräte eine Mindestmaß an Interoperabilität zu gewährleisten wurden zwei Geräteklassen-MIBs verabschiedet, die Fabric Element MIB (definiert von SNIA) und die Fibre-Channel MIB (definiert von Fibre Alliance).^[28]

Im Vergleich zu den Kommunikationsmöglichkeiten eines In-Band-Managements schneidet SNMP denkbar schlecht ab. Durch die Verwendung von UDP ist die Zustellung von Nachrichten nicht sicher gestellt. Ferner gilt die Nutzung von SNMP-Agents als unsicher.

6.3.2.2 WBEM

Web Based Enterprice Management (WBEM) ist eine Entwicklung der Distributed Management Task Force (DMTF) und zielt darauf ab mittels Webtechniken wie XML und HTTP eine zentrale Überwachung und Administration von Komponenten in einem professionellen Umfeld zu ermöglichen. Ferner gibt es Schnittstellen zu Techniken wie SNMP. Hierbei werden sämtliche Aspekte der Umgebung mit dem objektorientierten Common Information Model (CIM) beschrieben. Die bekannteste Implementierung dieser Technologie ist die Windows Management Instrumentation (WMI) mit der Windows Server verwaltet werden.

Die WBEM-Architektur sieht vor, dass die Instanzen der Objekte durch einen CIM Object Manager (CIMOM) am CIM Client (Verwaltungssystem) verwaltet. "Die Erfahrungen in der Vergangenheit haben gezeigt, dass WBEM und CIM alleine nicht ausreichend sind, um im Umfeld der Speichernetze die Interoperabilität zwischen CIM Clients, also Verwaltungssystemen, und CIMOMs zu gewährleisten."^[29]

6.3.2.3 SMI-S

SMI-S ist ein Standard, welcher von den Mitgliedern der SNIA Storage Management Initiative (SMI) und den technischen Arbeitsgruppen (TWGs) in Verbindung mit weiteren Standards und Gruppen unter Federführung der SNIA entwickelt wurde. Die Spezifikation standardisiert und vereinfacht Storage-Management-Funktionen in einem gemeinsamen Satz von Werkzeugen, die die täglichen Aufgaben der IT-Umgebung ausmachen.^[30]

Die wichtigsten Aspekte des Standards sind die Ermöglichung der gemeinsamen Nutzung von großen Speicherressourcen zwischen mehreren System über das Netzwerk, LAN freie Backups, Spiegelung von kritischen Unternehmensdaten, das Clustering von fehlertoleranten Anwendungen und Systemen und verteilte Datenbanken und Dateisysteme. Zudem sollte es nach dem Standard möglich sein verschiedene Arten von Hardware und Software Produkten von mehreren Anbietern zuverlässig und nahtlos zu überwachen und kontrollieren. Dieser Aspekt ist ein besonderer Vorteil von Virtualisierung von SANs^[31].

7 SAN Virtualisierung

Virtualisierung von Speicher findet auf mehreren Ebenen statt. In mittleren und großen Umgebungen kommen hierbei in der Regel Disksubsysteme zum Einsatz. Diese Disksubsysteme agieren logisch gesehen als Festplattenserver. Dem zugreifenden Applikations- oder Datenbankserver bleibt der Aufbau dieser Speichersysteme vollkommen verborgen, der Speicher ist also virtualisiert. Der Applikations- oder Datenbankserver greift lediglich auf die vom Speichersystem zur Verfügung gestellten Speicherressourcen zu. Abweichend von dieser Ebene der Virtualisierung behandelt diese Arbeit eine darüber liegende Ebene der Virtualisierung. So hat der Markt in den vergangenen drei Jahren Systeme hervorgebracht, welche eine weitere logische Abstraktionsschicht zwischen den zugreifenden Systemen auf der einen und den verwendeten Speichersystemen auf der anderen Seite darstellen. Diese Technologie wird auch als SAN-Virtualisierung bezeichnet.

7.1 Definition

Das IT-Konsortium SNIA (Storage Networking Industry Association) definiert die SAN-Virtualisierung als Integration einer oder mehrerer (back end) Dienste oder Funktionen mit zusätzlichen (front end) Funktionalitäten durch die Bereitstellung nützlicher Abstraktion. Typischer Weise verbirgt die Virtualisierung die Komplexität der (back end) Systeme oder implementiert zusätzliche (front end) Funktionalitäten mit existierenden (back end) Systemen. Beispiele von SAN-Virtualisierung sind hierbei die Aggregation mehrerer Instanzen eines Dienstes zu einem einzigen virtualisierten Dienst oder die sichere Nutzbarkeit eines ansonsten unsicheren Dienstes.^[32]

In der Praxis bedeutet dies, dass die logische Darstellungsebene zur Verwendung des Speichers durch Betriebssysteme, Anwendungen und Benutzer von der physikalischen Implementierungsebene entkoppelt und getrennt wird. Es wird eine logische Virtualisierungsschicht zwischen Speichergeräten und Speichernutzern eingefügt. Der physikalische Speicher eines oder mehrerer Speichergeräte wird zu virtuellem Speicher abstrahiert. Ein Zugriff auf die Speichergeräte geschieht nun nur noch indirekt über den gebildeten virtuellen Speicher.^[33]

7.2 Gründe für SAN Virtualisierung

Die Gründe für eine SAN-Virtualisierung sind vielfältig und die Entscheidung für die Einführung und den Betrieb einer SAN-Virtualisierung hängen stark von den jeweiligen Rahmenbedingungen der zu betrachtenden Organisation ab. Die meisten Gründe für eine SAN-Virtualisierung können aus den Limitierungen der klassischen Speicherung auf Disksubsystemen abgeleitet werden.

Die Einführung einer SAN-Virtualisierung kann auch eine strategische Entscheidung sein. So betrachten viele Organisationen die vollständige Virtualisierung Ihrer IT-Strukturen als strategisches Ziel. Auf diese Weise soll größtmögliche Herstellerunabhängigkeit erreicht werden.^[34]

Die Administration von konsolidierten Speichern innerhalb eines Speichernetzes stellt bereits eine Erleichterung gegenüber der Administration einzeln an einen jeweiligen Server angeschlossenen Speicherressourcen dar. Als Beispiel sei hier der Wechsel eines Servers genannt. Sind die benötigten Speicherressourcen direkt am Server angeschlossen stellt der Serverwechsel eine administrative Herausforderung dar, welche mit erheblichem Aufwand verbunden ist. In einer 24/7 Umgebung wird dies nochmals gesteigert. Hier müssen für die Migration entweder zusätzlicher Speicher zum Einsatz kommen oder es werden Downtimes akzeptiert. Das gleiche Szenario in einer SAN-Umgebung gestaltet sich deutlich weniger problematisch. Hier kann durch dem gleichzeitigen Zugriff auf die gleiche Speicherressource ein unterbrechungsfreier Serverwechsel ohne zusätzliche Speichersysteme durch den Einsatz eines Disksubsystems realisiert werden. Die Funktionalitäten unterscheiden sich hier je nach Disksubsystem deutlich. Doch durch bloßen Einsatz eines Speichernetzes und von einem oder mehreren Disksubsystemen wird die Verbindung zwischen Server und Speichergerät noch nicht aufgehoben. Dies bedeutet in der Praxis, das Änderungen an der Konfiguration des Speichergerätes gegenüber dem angeschlossen Server sichtbar werden. Dieses mündet letztlich im Wechsel des Disksubsystems. Dies stellt wieder eine hohe administrative Hürde dar, die allein dadurch verschärft wird, dass der Wechsel eine Vielzahl von Server betrifft. Auch hier stellt die Migration in einer 24/7 Umgebung nochmals eine Steigerung der Problematik dar.

7.3 Formen von SAN Virtualisierung

Zur Virtualisierung von Storage wird eine Instanz benötigt, die zwischen dem virtualisierten und physikalischen Storage eingebettet wird. Diese Instanz kann sich auf mehreren Ebenen befinden. Sie kann auf den Servern selbst in Form eines Volume Managers, auf dem angeschlossenen Plattensubsystem, oder in Form einer zusätzlichen Komponente im Speichernetz eingebettet sein. Diese zusätzliche Komponente wird häufig in Form einer Applience Lösung (oft Metadaten-Controller genannt) implementiert. Abbildung 04 zeigt eine Übersicht der möglichen Virtualisierungsorte für Datenspeicher^[35]. Im Folgenden soll der Fokus auf Virtualisierung innerhalb des Speichernetzes liegen.

7.3.1 Blockorientierte und Fileorientierte Virtualisierung

Werden dem Betriebssystem virtuelle Festplatten zur Verfügung gestellt, die von einer außerhalb der Serverebene liegenden Schicht verwaltet werden, so spricht man von einer blockorientierten Virtualisierung. Das Betriebssystem und die Anwendung arbeiten also auf Blöcken einer virtuellen Festplatte, die wie gewohnt von einem Filesystem oder einer Datenbank verwaltet werden. Die Virtualisierungsinstanz hat dafür Sorge zu tragen, dass die virtuellen Blöcke auf physische Blöcke der realen Speichergeräte abgebildet werden^[35]. Hierbei ist es sogar möglich, die Blöcke einer Datei durch die Virtualisierungsschicht auf verschiedene Plattensubsysteme zu verteilen. Eine solche blockorientierte Virtualisierungsschicht ist in der Lage, mehrere Speichergeräte wie z.B. Bandlaufwerke oder LUNs als Gruppen zu verwalten^[37]. Die Bildung solcher Gruppen sollte hierbei nach Performancekriterien erfolgen, da z.B. verschiedene Festplattentechnologien wie SATA oder Fibre-Channel deutliche Unterschiede im I/O Verhalten aufweisen und damit auch für andere Verwendungsarten gedacht sind. So können virtualisierte Platten aus einem SATA-Pool für unkritische Anwendungen, Backup oder File-Serving bereitgestellt werden, während zeitkritische Unternehmensanwendungen und Datenbanken mit virtuellen Disks aus dem Fibre-Channel-Bereich bedient werden. Eine solche blockorientierte Virtualisierung ermöglicht auch das Migrieren von Daten zwischen Storage Subsystemen verschiedener Hersteller ohne Beeinträchtigung der Applikation auf dem betroffenen Server^[37]. Im Gegensatz hierzu werden dem Betriebssystem bei einer fileorientierten Virtualisierung die virtualisierten Speicherbereiche in Form von Dateien oder Verzeichnissen präsentiert. Das Umsetzen der Dateien auf Blöcke wird in diesem Fall komplett von der Virtualisierungsschicht übernommen.^[35]. Diese Virtualisierungsform ermöglicht auch die gemeinsame Nutzung von Speicherbereichen für mehrere Anwendungsserver. Bezüglich der Einsatzgebiete ist zu sagen, dass die blockorientierte Technologie dann sinnvoll ist, wenn Daten für eine heterogene Systemlandschaft mit verschiedenen Betriebssystemen und Anwendungen virtualisiert werden sollen. Für die Daten des Betriebssystems selber oder Datenbanken, die mit Raw Devices arbeiten, ist dies sogar die einzige Form, die eine Virtualisierung ermöglicht. Wenn eine gemeinsame Datennutzung zwischen Servern etabliert werden soll, ist hingegen der Einsatz fileorientierter Virtualisierung unumgänglich^[38].

7.3.2 In-Band Virtualisierung

Wenn die Virtualisierungslösung im Datenpfad zwischen den Storage Systemen und den angeschlossenen Servern implementiert wird, so spricht man von einer In-Band oder auch symmetrischen Virtualisierung. Der Datenfluss zwischen Anwendung und Storage Subsystem wird hierbei komplett durch den Metadaten Controller geleitet. Um dies zu gewährleisten wird das SAN Zoning so konfiguriert, dass die Server im Speichernetz nur noch die Virtualisierungsapplience erreichen können. Diese wiederum erhält über das SAN Netzwerk Zugriff auf die verschiedenen Plattensubsysteme.

Die Virtualisierung der Daten kann sowohl auf Block-, als auch auf Dateiebene erfolgen. Hierzu ist der Metadaten Controller in die beiden Schichten zur Verwaltung der logischen Volumens, sowie der Datenzugriffsschicht aufgeteilt. In der Volume-Management Schicht können sowohl eigene Speichergeräte des Controllers, sowie angeschlossene Speichergeräte verwaltet, konfiguriert und zusammengefasst werden. Die Datenzugriffsschicht übernimmt die Bereitstellung des logischen Speichers auf Block- oder Dateiebene^[40].

Da der gesamte Datenverkehr durch den Metadatencontroller geleitet wird, stellt dieser einen Flaschenhals für die Performance aller angeschlossenen Systeme, sowie einen Single Point auf Failure dar. Um Performanceeinbußen zu vermeiden wird dieses Gerät in der Regel mit einem eigenen Cache ausgestattet, wodurch sogar eine Verbesserung hinsichtlich der Performance im Vergleich zu direkt angeschlossenen Plattensubsystemen erzielt werden kann. Weiterhin wird Performance durch Clustern von zwei oder mehr Metadatencontrollern verbessert. Hierdurch wird auch die benötigte Ausfallsicherheit erreicht^[41]. Vorteile einer solchen In-Band Lösung sind eine leichte Bereitstellung von Daten auf Block- oder Dateiebene, sowie eine zentrale Administration der Speicherressourcen. Diese Lösung eignet sich besonders für heterogene Serverlandschaften, da es keine Einschränkungen hinsichtlich der unterstützten Betriebssysteme gibt. SAN Features wie Snapshot, Mirroring etc., die auf den verschiedenen Plattensubsystemen zusätzlich zu lizensieren sind, oder bei einfacheren Systemen nicht verfügbar sind, können auf die Virtualisierungsschicht verschoben werden^[39]. Dies hat den Charme, dass diese Features nicht nur in den Grenzen der einzelnen Subsysteme, sondern übergreifend angewendet werden können^[42]. Mögliche Nachteile einer solchen Lösung hängen stark von der Auswahl der Komponenten und Art und Weise der Implementierung ab. So können beispielsweise Konfigurationsfehler am Metadatencontroller den Verlust sämtlicher Speicherressourcen und damit den Komplettausfall eines Rechenzentrums hervorrufen. Wenn für eine geclusterte Virtualisierungsapplience keine zentrale Administrationsoberfläche vorgesehen oder eingerichtet ist, so kann eine gewünschte Erleichterung der Administration sehr schnell in zusätzlichen Aufwand für die Pflege und das Monitoring der Systemlandschaft münden. Außerdem kann statt einer Verbesserung der Performance durch zu kleine Bandbreiten an den SAN Verbindungen, zu kleine Cachebereiche oder fehlendem Load Balancing ebenso eine Verschlechterung der Performance das Ergebnis einer In-Band Virtualisierung sein^[43].

7.3.3 Out of Band Virtualisierung

Im Falle einer Out of Band oder auch asymmetrischen Virtualisierung werden Kontroll- und Datenpfad voneinander getrennt. Dies geschieht durch die Trennung von Kontroll- und Metadaten. Hierzu werden alle Mapping und Locking Tabellen zum Metadatencontroller verschoben^[44]. Dieser kümmert sich in diesem Fall ausschließlich um die administrativen und Kontrollaufgaben der Virtualisierung. Der Datenfluss hingegen erfolgt weiterhin vom Anwendungsserver zu den Storage Systemen. Die Kommunikation zwischen dem Metadatencontroller und dem benötigten Agenten auf Seiten der Applikation Server erfolgt meist über das LAN, kann aber auch In-Band über das SAN erfolgen. Der Agent wird benötigt, um den direkten Zugriff auf die physikalischen Speicherressourcen zu ermöglichen.

Der Agent setzt sich aus einer Datenzugriffsschicht und einer Kontrollschicht zusammen. Wenn nun Daten von einem Applikationsserver angefragt werden, holt sich der Agent die entsprechenden Metainformationen vom Metadatencontroller mit Hilfe der Kontrollschicht ab. Anschließend können die Daten direkt vom physikalischen Speichersubsystem gelesen werden. Die Zugriffskontrolle obliegt hierbei dem Metadatencontroller. Die benötigten Agents müssen nicht zwangsweise im Speicher der Anwendungsserver laufen. Zu deren Entlastung können diese auch in deren Hostbus-Adapter implementiert werden. Auch die Out of Band Technik ermöglicht sowohl die Block- als auch die Fileorientierte Virtualisierung. Ebenso ist die Anwendung von Technologien wie Snapshot, Mirroring oder Datenmigration implementierbar. Im Gegensatz zu der In-Band Lösung ist der Implementierungsaufwand aufwendiger. Das Entstehen eines Flaschenhalses durch zusätzliches Gerät im I/O Datenstrom aus Sicht der Anwendungsserver wird bei Out of Band durch den direkten Zugriff auf die Daten verhindert. Auf der anderen Seite ist das bereitstellen eines zusätzlichen Caches ebenfalls aufwendiger als bei einer In-Band Virtualisierung, da der Cache auf Seite eines jeden Serversystems, dass es zu optimieren gilt, zu installieren ist. Einen Single Point of Failure erhält man auch bei einer Out of Band Virtualisierung, wenn die Hardware nicht in Form einer Clusterlösung ausgeprägt ist. In diesem Fall ist diese mit geringerem Aufwand herzustellen, da es lediglich den Kontrollfluss auf mehrere Rechner zu verteilen gilt.^[46] Als weitere Vorteile dieser Lösung sind zu nennen, dass aus der Trennung von Kontroll- und Datenpfad ein geringer Overhead im Datenpfad resultiert und somit für den reinen I/O die gesamt SAN Bandbreite genutzt werden kann. Zusätzlich werden die Host CPU's durch die Auslagerung der Zugriffsüberprüfung entlastet^[44]. Nachteilig, besonders in einem heterogenen Umfeld, ist die Notwendigkeit einer zusätzlichen Agent Software. Läuft diese nicht stabil, kann es zu Speicherzugriffsproblemen kommen, welche bei Unternehmenskritischen Anwendungen weitreichende Auswirkungen haben können. Besonders hohe Anforderungen werden an diese Software gestellt, wenn neben dem Zugriff über die Blockebene auch noch der Zugriff auf die Dateiebene realisiert werden soll. Wird ein Server ohne Installation eines Agents angeschlossen, kann dies dazu führen, dass dieser Dateien in Zugriff nimmt, die bereits von anderen Systemen verwendet werden^[47].

7.4 Features von SAN Virtualisierung

Sowie die schon seit einigen Jahren in vielen Rechenzentren implementierte Servervirtualisierung wie z.B. in Form von VMware, eröffnet auch die Virtualisierung des Speichernetzwerkes neue Möglichkeiten. Einige der Features wie z.B. bessere Skalierbarkeit, einheitliches Monitoring oder landschaftsübergreifende SAN Features erfüllen erst dann ihren Mehrwert, wenn die entsprechenden Voraussetzungen dafür gegeben sind. In einem Unternehmen mit einer homogenen SAN Infrastruktur mit z.B. nur zwei gespiegelten Disk Arays wird eine Virtualisierung zwar auch Vorteile bringen, jedoch nicht die Kosten für die Anschaffung einer solchen Lösung rechtfertigen.

7.4.1 Herstellerübergreifende Administration

Wenn Virtualisierungssoftware als zentrale Schnittstelle für alle Speichergeräte genutzt wird und damit eine einheitliche Administrationsoberfläche für die gesamte Infrastruktur zum Einsatz kommt, bedeutet dies eine Senkung des administrativen Aufwandes. Dieser wird noch weiter verringert, da sich alle Speichersysteme gleich verhalten und somit einheitlich verwaltet werden können. Administratoren benötigen keine Schulungen wenn neue Systeme hinzukommen^[48]. Ein weiterer Vorteil ist, dass Monitoring und Alerting nur für die Virtualisierungsinstanz konfiguriert und betrieben werden muss. Als nachteilig kann empfunden werden, dass wie bei jeder Form von Virtualisierung die Tranzparens der Zusammenhänge zwischen Anwendung und Hardware stark eingeschränkt wird, was ggf. zu längeren Fehleranalysen führen kann.

7.4.2 Skalierbarkeit

In der Praxis sind Speicherressourcen in Unternehmen oft historisch gewachsen. Mit dem Bedarf an neuen Anwendungen wie CRM, Business Warehouse, SCM etc. entsteht auch der Bedarf an zusätzlichem Speicherplatz. Im Rahmen der Investition für die neue Software wird dann häufig auch ein zusätzliches Plattensubsystem angeschafft. Dies führt zu einer heterogenen Storageinfrastruktur mit Disk Arrays unterschiedlicher Hersteller. Da das Wachstum der einzelnen Anwendungen nicht genau kalkulierbar ist, führt dies automatisch zu einer ungleichen Auslastung der einzelnen Plattensysteme hinsichtlich ihrer Kapazität. So muss dann für einzelne Systeme zusätzliche Plattenkapazität angeschafft werden, obwohl in anderen Plattensubsystemen noch Kapazität brach liegt. Dieses Problem lässt sich durch eine Virtualisierung beseitigen, da diese für eine gleichmäßige Auslastung der angeschlossenen Systeme sorgen kann. Nachfolgende Abbildung soll den Effekt der Virtualisierung verdeutlichen.

Um diesen Effekt zu erzielen ist es nicht erforderlich, die Virtualisierungsschicht bereits bei Anschaffung der Plattensubsysteme zu implementieren, sondern ist auch nachträglich ohne Beeinträchtigung der Angeschlossenen Server möglich. Es ist lediglich eine kurze Downtime zur Änderung des Zonings und erneutem Einbinden der virtualisierten Platten in den jeweiligen Betriebssystemen erforderlich. Der Kapazitätsausgleich kann dann im laufenden Betrieb im Hintergrund erfolgen. Ergebnis ist, dass die gesamte Storage Kapazität für alle angeschlossenen Server gleichermaßen zur Verfügung steht. Hierdurch kann der Schwellwert zur Neuanschaffung von Hardware deutlich erhöht werden.

7.4.3 Migrationsfähigkeit / Flexibilität

Bei Anschaffung neuer Hardware ist in der Regel so, dass diese eine gewisse Zeit (oft drei Jahre) von Wartungsgebühren befreit sind. Nach diesem Zeitraum führen die geänderten Anforderungen an Kapazität und Performance, sowie auch die Tatsache, dass die anfallenden Wartungskosten eine Neuanschaffung rechnerisch sinnvoll machen, ggf. zu einem Hardwareaustausch. Wenn das neue Plattensubsystem nicht vom gleichen Hersteller kommt, können sich erhebliche Migrationsaufwände ergeben. Eine weitere Motivation für eine Datenmigration könnte sein, dass weniger wertvolle Daten auf günstigere Speicherbereiche verschoben werden sollen^[49]. Mögliche Szenarien zur Migration ohne Virtualisierung können hostbasierende Spiegelungen, Backup und Restore oder beispielsweise inkrementelle Kopien sein. Alle diese Möglichkeiten bedeuten Aufwand, viel Know How und benötigen mindestens eine kurze Downtime. Es kann jedoch auch zu langer Downtime oder sogar zu Datenverlust kommen. Ist zum Zeitpunkt der Migration bereits eine Virtualisierung gegeben, kann diese ohne Downtime der angeschlossenen Systeme erfolgen. Ansonsten ist analog zum vorherigen Kapitel eine kurzer Applikationsstop zum Anpassen des Zonings und erneutem Einbinden der alten Platten über die Virtualisierungslösung erforderlich. Die folgende Abbildung zeigt die Vorgehensweise für eine Datenmigration mittels des San Volume Controllers der IBM.

In diesem Beispiel wird das Volume eines Servers an die Virtualisierungsschicht gemappt und somit virtualisiert. Ohne Veränderung wird dieses virtualisierte Volume wieder an den Host angebunden. Nachdem die betroffene Anwendung wieder in Betrieb genommen wurde, kann die Migration der Daten auf eine beliebige von der Virtualisierungsumgebung verwaltete Hardware erfolgen. Die hierdurch gewonnene Flexibilität kann noch durch die Auswahl einer Virtualisierungssoftware erweitert werden, die den gemischten Einsatz von FC-, SCSI-, SAS-, SATA-Storage gestattet^[48].

7.4.4 Thin Provisioning

Thin Provisioning ist eine Technik aus dem Umfeld SAN Virtualisierung, die es ermöglicht, dass immer nur genau soviel Plattenkapazität auf den Plattensubsystemen belegt wird, wie die angeschlossenen Servern in Form von abgelegten Daten tatsächlich in Anspruch nehmen. Die Server erhalten eine oder mehrere LUNS von beliebiger Größe. In Wirklichkeit muss diese Plattenkapazität auf Seite der Plattensubsysteme noch nicht einmal vorhanden sein. Gewährleistet sein muss nur, dass die Gesamtplattenkapazität der Storage Systeme das gesamte Nutzdatenvolumen der angeschlossenen Server übersteigt. Ohne die Möglichkeit von Thin Provisioning ist man darauf bedacht, den einzelnen Servern immer nur genau soviel Speicherkapazität zuzugestehen, wie diese auch benötigen, damit keine nicht benötigten Speicherbereiche von den Systemen belegt werden. Um gewährleisten zu können, dass die Systeme lauffähig bleiben und die entsprechenden Anwendungen ausreichend Pufferplatz bekommen, wird hier selbst bei kaum wachsenden Anwendungen ein Puffer von ca. 20% über dem tatsächlich belegten Speicherplatz nötig. Die Größe des gewählten Puffers entspricht den Erfahrungswerten des Autors und ist individuell abhängig von dem Verhältnis des zur Verfügung stehenden Speichers und dem Gesamtdatenvolumen, sowie der Vorgehensweise der zuständigen Administratoren. Da man beim ersten Sizing in den seltensten Fällen das Datenwachstum der entsprechenden Systeme genau vorhersehen kann, führt das Feature Thin Provisioning neben deutlichen Kapazitätseinsparungen und einer höheren Verfügbarkeit zu einer wesentlichen Entlastung seitens der Administration:

• Das nachträgliche Hinzufügen von Kapazitäten in Form von Vergrößern oder Hinzufügen von LUNS kann entfallen. Dies ist eine deutliche Erleichterung, da derartige Anpassungen je nach Betriebssystem auch eine Migration der Daten bedeuten kann.
• Die vielen benötigten Speicherpuffer pro angeschlossenem System können durch einen Puffer auf Seiten der Virtualisierungslösung im SAN abgelöst werden. Dieser "Gesamtpuffer" kann wesentlich kleiner als die Summe der "Einzelpuffer" ausgelegt werden.
• Durch das Bereitstellen von großzügigen LUN-Größen ist die Gefahr des Systemstillstands eines angeschlossenen Servers aufgrund von vollgelaufenen Plattenbereichen deutlich verringert. Allerdings ist ein Monitoring der Gesamtkapazitäten umso wichtiger, da ein Kapazitätsengpass an dieser Stelle alle angeschlossenen Systeme beeinträchtigen würde.

Nach einer Umfrage der Storage Dienstleistungsfirma Glasshouse in Großunternehmen und im Mittelstand aus dem Jahre 2003, war den Befragten schon damals bewusst, dass der Grund für nicht genutzte Storage Ressourcen brach liegende Bereiche sind, die seitens der Host Systeme zu viel allokiert sind ^[51]. Eine Analyse von 750 Host Systeme ergab, dass durchschnittlich 75% der verfügbaren Ressourcen zugewiesen waren. Davon waren 36% auf Hostseite nicht zur Aufnahme von Daten konfiguriert. Von den übrigen 61% der zugewiesenen Kapazitäten waren insgesamt nur 39% der Speicherressourcen in Benutzung. "Ein typischer Host hat also beispielsweise 500 GB an externer Speicherkapazität gebucht, 375 GB davon sind in Volume Groups aufgeteilt, 240 GB in File-Systemen und effektiv werden typischerweise bei diesem Verhältnis nur 93 GB tatsächlich genutzt"^[51]. Dies würde bedeuten, dass lediglich ca. 14% der Gesamtressourcen auch tatsächlich benötigt würden. Eine weitere Studie des Marktforschungsunternehmens Enterprise Strategy aus dem Jahre 2005 hatte die Zahlen nochmals bestätigt und darüber hinaus ergeben, dass 30% der befragten Firmen nach einem Jahr erneut in Speicherkapazitäten investieren mussten, obwohl noch nicht alle Ressourcen tatsächlich in Benutzung waren. Grund hierfür sei die Schwierigkeit, dass die Konfiguration der bestehenden Landschaft nicht dahingehend angepasst werden konnte, dass die brach liegenden Kapazitäten für andere Systeme zugänglich wurden.^[51]

7.4.5 Quality of Service

Ursprünglich war Quality of Service (QoS) eine Metrik für Daten Netzwerke. Sie diente zum Messen bestimmter Leistungsmerkmale wie Latenzzeit, Bandbreite und Fehlerraten. Ziel ist es, diese ggf. zu verbessern, um den Benutzern und Anwendungen einen bestimmten Leistungsgrad garantieren zu können. Da Server und deren Speicher immer unternehmenskritischer werden und die Komplexität der Storage Infrastrukturen immer mehr zunimmt, hat der Begriff QoS auch im SAN Umfeld Einzug gehalten. QoS bedeutet in diesem Zusammenhang der zuverlässige, kombinierte Betrieb jeder Komponente wie Host Bus Adapter (HBA), Treiber, Switche, Storage Systeme und auch Virtualisierungsschicht. QoS umfasst Zuverlässigkeit, Verfügbarkeit, Effizienz, Benutzerfreundlichkeit, Wartbarkeit sowie die Fähigkeit Veränderungen vorzunehmen und die Systeme nach einem Fehler wiederherstellen zu können^[52]. In einer virtualisierten Storage Umgebung bietet es sich an, gleich schnelle LUN's der einzeln Storage Systeme auf der Virtualisierungsebene zu Diskgruppen zusammenzufassen, so dass beispielsweise günstigere Datenspeicher wie SATA für weniger zeitkritische Applikationen zum Einsatz kommen, während schnelle Datenspeicher für zeitkritische Anwendungen und Datenbanken Verwendung finden. Zusätzlich bieten In-Band Lösungen wie San Symphony oder der San Volume Controller von IBM Möglichkeiten, die Performance der angeschlossenen Anwendungen zu messen und zu beeinflussen. Durch die Platzierung im Datenpfad können Schreib-/Lesevorgänge kontrolliert und ausgewertet werden. Reporting- und Analysetools für die Dokumentation der gesamten Speicherinfrastruktur, die Administration und die interne wie externe Rechnungsstellung sind in heute integriert^[48].

7.4.6 Landschaftsübergreifende SAN Features

Durch den Einsatz von Virtualisierungstechniken auf der Ebene des Speichernetzwerkes können Funktionen, die einzelne Storage Arrays bieten, für den gesamten verwalteten Storage verfügbar gemacht werden. Gemeint sind die o.g. Funktionen wie Caching, Snapshots, Cloning von Disks und Mirror Beziehungen. Voraussetzung ist, dass die Virtualisierungsapplience die entsprechenden Features mit sich bringt. Dies bietet folgende Vorteile:

• Die sogenannten Premium Features brauchen für die Plattensubsysteme nicht mehr lizensiert werden.
• Nicht intelligente Plattensubsysteme erhalten ebenfalls diese Funktionen.
• Die Features können nicht nur innerhalb eines Plattensubsystemes, sondern auch zwischen beliebigen Plattensubsystemen unterschiedlicher Hersteller verwendet werden.

7.4.7 Hochverfügbarkeit

Auch ohne Virtualisierung ist der Verzicht auf Hochverfügbarkeitsmechanismen von Speichersystemen zusätzlich zu Backup und Recovery Lösungen kaum denkbar. Wie bei jeder Hochverfügbarkeitslösung kommt es darauf an, Single Point auf Failures auszumerzen und getrennte Lokationen, die ausreichend weit von einander entfernt sind, auszuwählen. Ein Beispiel für eine Hochverfügbarkeitslösung zeigt folgende Abbildung.

In diesem Fall kommen sowohl an der primären, als auch an der sekundären Lokation zwei SAN Switche zum Einsatz. Als Performancegründen werden auch zwei Virtualisierungsappliences vom Typ SANsymphony verwendet. Das dritte San Symphony Box dient der Redundanz. Der komplette produktive Datenbestand wird mit Hilfe der Virtualisierungssoftware an die zweite Lokation gespiegelt, so dass die Produktion beispielsweise im Falle eines Brandes dort fortgesetzt werden kann. Im Gegensatz zu den eingeschränkten Möglichkeiten von Storage Subsystemen, die üblicherweise nur ein Protokoll zur Datenspiegelung zulassen ist es in diesem Beispiel mit Hilfe der Virtualisierung vollkommen unerheblich, ob die Datenspiegelung mittels des IP oder Fibre-Channel Protokolls erfolgt. Hiermit besteht die Möglichkeit, die gesamte Infrastruktur synchron an ein nah gelegenes Ausweichrechenzentrum oder asynchron an ein beliebig weit entferntes Rechenzentrum zu spiegeln. Ein weiterer Vorteil ist, dass die Maßnahmen zum Umschalten der Systeme vom Produktiven- in das Backuprechenzentrum ebenfalls vereinheitlicht werden kann.

7.5 Verwaltung und Monitoring

Die Forderung nach einer zentralen Verwaltung und Überwachung des angeschlossenen Speichers wird durch die Virtualisierung vollständig erfüllt. Hierbei handelt es sich typischer Weise um ein In-Band-Management Konzept. Operationale Dienste wurden bisher lediglich im In-Band-Management implementiert.^[54] Der Virtualisierungsserver fungiert hierbei als Management Agent. Hierbei kann der Server die Grenzen einzelner Topologien aufheben und je nach Ausführung LAN, iSCSI und Fibre-Channel Speichergeräte synchron bedienen.

Das bisher notwendige Fachwissen zur Einrichtung und Administration einzelner Speichergeräte muss nicht mehr vorgehalten werden. Es ist nun möglich die Verwaltung von unterschiedlichen Speichergeräten mehrerer Hersteller unter einem Verwaltungssystem vorzunehmen. Dies kommt nicht nur der Forderung nach mehr usability nach, sondern reduziert die Betriebskosten von Speichersystemen.^[55] Es ist denkbar, dass durch die zentrale Verwaltung auch eine höhere Kompetenz in der Anwendung der Verwaltungswerkzeuge aufgebaut werden kann und sich dies positiv auf die Betriebssicherheit auswirkt.

Das Monitoring eines virtualisierten SANs verliert im Gegensatz zur Überwachung einzelner Speichersysteme innerhalb des SANs deutlich an Komplexität. Dies betrifft insbesondere die Auswertung von Performancedaten. Durch die Anbindung des Virtualisierungsservers an das jeweilige Speichernetz können die Statistikdaten der entsprechenden Ports (iSCSI, Fibre-Channel) abgerufen werden. So kann der Hersteller einer virtuellen SAN-Lösung nicht nur eine zentrale Überwachung realisieren, sondern auch ein Reporting in Bezug auf die Leistungsdaten der Speichergeräte implementieren. Die Leistung von elektronischen Datenträgern wird in Ein- und Ausgabebefehlen pro Sekunde (IOPS) gemessen. Leistungsfähige Speicherarrays erreichen hierbei Werte von > 200.000 IOPS.^[56]

7.6 Standards

Storage Networking Industry Association (SNIA)

Die Storage Networking Industry Association ist ein Non-Profit-Unternehmen, das von 400 Mitgliedern des globalen Speichermarktes gegründet wurde.

Für die Virtualisierung von Storage Area Network gibt es zur Zeit keinen eigenen Standard. SAN-Virtualisierungslösungen folgen dem SMI-S Standard (siehe 6.3.2.3) der von der Storage Management Initiative (SMI), entwickelt wurde. Die SMI ist eine Gruppe von Mitgliedsfirmen innerhalb der SNIA mit diesen Mitgliedsfirmen^[57]:

• 3PAR
• HP
• NetApp
• Quest Software
• EMC²
• Hitachi
• Olocitiy
• Sun
• Fujitsu
• IBM
• PMC
• Symantec (Speicherbereich ehemals Veritas)

Bisher sind folgende Versionen des Standards offiziel ratifiziert:

• SMI-S V1.0 (ISO/IEC 2007)
• SMI-S V1.1 (ANSI 2008) - Ratifizierung durch ISO ist beantragt

Momentan befindet sich die Version 1.4 in der Entwicklung und die Spezifizierung der Version 1.5 hat begonnen.^[58]

7.7 Hersteller

Im Bereich der Speichervirtualisierung gibt es bisher nur wenige Anbieter, doch das System wird mit fortschreitendem Datenwachstum für Unternehmen immer interessanter zu implementieren. Durch den Anstieg potenzieller Kunden kann der Markt auch für Anbieter lukrativer werden.

In dieser Arbeit konzentriert man sich auf die Hersteller IBM, DataCore und Hitachi. Von IBM wird im Folgenden der SAN Volume Controller, von DataCore die Produkte SANmelody und SANsymphony, von Hitachi der Hitachi Universal Storage PlatformTM V und von HP die HP SAN Virtualization Services Platform vorgestellt.

7.7.1 IBM SAN Volume Controller

„IBM ist einer der weltweit größten Anbieter von Informationstechnologie (Hardware, Software und Services). Das Lösungsportfolio reicht vom Supercomputer über Software und Dienstleistungen, inklusive Beratungsleistungen, bis zur Finanzierung.

Als IT-Unternehmen mit der am breitesten gefächerten Erfahrung, vor fast 100 Jahren gegründet, hat sich das Unternehmen immer wieder neu definiert. Dank herausragender Technologien und Innovationen ist IBM zu einer der stärksten Marken aufgestiegen.“ ^[59]

"Der IBM System Storage SVC ist ein Speichervirtualisierungssystem, das die Kontrolle ungleichartiger, heterogener Speicherressourcen von einer einzigen Stelle aus für die Verfügbarkeit und bessere Nutzbarkeit von Unternehmensapplikationen ermöglicht. Ziel ist es, alle Speicherressourcen in Ihrer IT-Infrastruktur zu verwalten und sicherzustellen, dass sie zu Ihrem geschäftlichen Vorteil genutzt werden – schnell, effizient, in Echtzeit und möglichst kostengünstig."^[60]

Der SAN Volume Controller bietet die Möglichkeit die Speichersysteme zu einem zentralen Speicherpool zusammenzufassen und damit eine bessere Verwaltung zu gewährleisten. Die Speichernutzung wird durch den SVC besser ausgelegt, so dass Anwendungen benötigte Kapazitäten flexibler nutzen können.

Zudem ermöglicht es die bereits im vorhinein beschrieben Features einer Virtualisierung von SANs wie beispielsweise der Datenspiegelung, dem Snapshot, der Datenmigration zwischen verschiedenen Speichersystemen und die Performance wird durch den Speicherpool verbessert.

Eine einheitliche Funktionsplattform für die verschiedenen Speichersysteme erleichtert den Systemadministratoren die Arbeit.

Das interne Spiegeln erlaubt das gleichzeitige Schreiben auf 2 verschiedene Diskpools. Des Weiteren unterstützt es erweiterte Kopierdienste von teureren auf billigere Geräte und zwischen Subsystemen verschiedener Hersteller.^[61]

Lizenzmodelle

IBM schafft es seine Virtualisierungssoftware in zwei verschiedenen Lizenzmodellen für kleine und mittelständige Unternehmen und für Großunternehmen zu unterteilen. Kleine und mittelständige Unternehmen lizensieren die Virtualisierungssoftware nach genutzten Festplatten. Dabei ist es möglich bis maximal 60 Festplatten zu lizensieren, zudem ist die Spiegelung und die Snapshotfunktion optional je Festplatte zu erwerben. Für große Unternehmen wird der SAN Volume Controller nach Terabyte Kapazitäten lizensiert. Auch in diesem Fall ist die Spiegelung und der Snapshot optional je Terabyte zu erlangen.^[61]

Preise für die verschiedenen Lizensierungen konnten nicht ermittelt werden.

7.7.2 DataCore

Die DataCore Software Corporation wurde 1998 gegründet und ist ein privates Unternehmen das weltweit agiert. Es gehört neben IBM zum Marktführer auf dem Gebiet der Speichervirtualisierung. Die Räumlichkeiten der DataCore Software Corporation befinden sich in den Vereinigten Staaten, Europa und Asien. Die DataCore Software Corporation hat sich darauf spezialisiert Speicherlösungen, Netzwerkspeichervirtualisierung, Speicherbeschaffung, Datenwiederherstellung, Speicherressourcenmanagement und virtuelle Speicherinfrastruktur bis hin zur kompletten Servervirtualisierung zu realisieren. Die Produkte zur Speichervirtualisierung des Unternehmens sind SANsymphony und das kostengünstige SANmelody.^[62]

Diese Produkte bieten dem Nutzer die Chance Speichersysteme zu managen und zu kontrollieren, durch die Virtualisierungssoftware steigt die Kosteneffizient der vorhandenen Systeme. Zudem wird ein höheres Level an Datensicherheit geboten und die Wiederherstellung im Katastrophenfall. Sie erzielen eine hohe Flexibilität und Zukunftssicherheit. Es können Hardwareelemente verwendet werden, die keine eigene Software besitzen oder bereits im Unternehmen vorhanden sind. Dabei sind der Herstellertyp und die Fähigkeiten des Systems einerlei. ^[62]

7.7.2.1 DataCore SANmelody

Mit dem kostengünstigen SANmelody kann der Umgang physikalischer Speicherressourcen vereinfacht und somit den Administrator entlastet werden. So wird aus einem Standard-PC-Server ein Festplattenserver, der den Anwendungen im LAN als Speicherpool zur Verfügung steht, dabei ist der Einsatz von iSCSI/Fibre-Channel-SAN-Geräten mit lokalen S-ATA-Platten möglich.

SANmelody bietet dabei die gleichen Funktionen, die auch ein High-End-Array oder ein SAN bietet. Es ist durch die Virtualisierungsschicht eine bessere Auslastung, niedrigere Hardwarekosten, weniger Administrationsaufwand und höhere Produktivität und damit eine insgesamt Kostensenkung möglich.^[63]

"Die Zentralisierung der Speicherverwaltung, Konsolidierung der Speicherressourcen und Zusammenlegung von Sicherungs- und Replikationssystemen auf einen Server verringert Aufwand und Zeit gegenüber herkömmlichen Konzepten die auf vielen verschiedenen Servern verwaltet werden."^[64]

Funktionen:

• iSCSI Disk Emulation
• Unterstützung jedes denkbaren Festplattentyps
• I/O Schreib- und Lese-Caching
• Virtuelle LUNs
• Intuitive Administration
• Performanceanzeige
• Ergebnisprotokollierung

Zur Steigerung von Kapazität, Leistung und Hochverfügbarkeit bietet SANmelody weiterhin

• automatischen Speicherbereitstellung
• erleichtert die Verwaltung
• verringert ungenutzte Kapazitäten
• liefert Servern automatisch den erforderlichen Speicherplatz in exakter Größe und zur rechten Zeit
• Thin Provisioning
• gibt Warnungen bei einem aufgebrauchtem Speicher von 80%
• Reduzierung der Downtimes

Erweiterte Speicherfunktionen können durch Einsatz der folgenden optionalen Komponenten hinzugefügt werden:

• Fibre-Channel Disk Emulation
• Auto Failover (HA)
• Vollständige Snapshots
• Auto Provisioning (Virtual Capacity)
• Asynchrones Remote Mirroring über IP ^[63]

Lizenzmodell

DataCore SANmelody ist eine kostengünstige und einfache Lösung für kleine und mittelständige Unternehmen. DataCore Software Corporation lizensiert SANmelody nach Nutzung der Kapazitäten. Hierbei gibt es die Möglichkeit zwischen 3 TB, 4 TB, 8TB, 16 TB und 32 TB zu entscheiden. Die einzelnen Lizenzen besitzen den gleichen Funktionsumfang lediglich die Kapazität des Speichers ist für die Kosten entscheidend. ^[65]

Die optionalen Komponenten müssen zusätzlich lizensiert werden. Dabei beginnt die Lizensierung bei einem Kostenpunkt von 1.231,80€ für eine Basislizenz von 4 TB, für optionale Komponenten Fibre-Channel, Thin Provisioning und Snapshot je 821,20€.(Stand: 02.02.2009)^[66]

7.7.2.2 DataCore SANsymphony

SANsymphony ist eine Speichermanagementplattform für größer skalierte Netzwerke, die organisierte öffentlich verbreitete Speichergeräte in einen hochverfügbaren, sicheren und zentral gemanagten Netzwerkspeicherpool verwandeln. Im Weiteren werden die wichtigsten Features aufgezeigt die SANsymphony bietet.

SANsymphony dupliziert den effektiven Festplattennutzen indem es die Größe von mehreren Platten vereint und eine automatische Zuteilung genügender Kapazität vornimmt. Zudem bietet SANsymphony automatische Speicherkontrolle, leichte Erhöhung der Kapazitäten und eine bessere Produktivität.

Weitere Features beinhalten automatische Zuteilung von neuen Volumes, flexible Speicherdomänen, Drag-and-drop Administration, Synchrone und Asynchrone Spiegelung und Snapshots. Diese Fähigkeiten eliminieren überflüssige Zeit, Geld und Anstrengungen und garantieren das Speicher und Personal viel effektiver genutzt werden können.^[67]

Weiterhin bietet DataCore SANsymphony:

• Single Storage Domain Server (SDS)
• Synchrone Netzwerkspiegelung
• iSCSI & FC Support
• Thin Provisioning
• Snapshot
• Asynchrone Spiegelung
• Zusätzliche Speicherdomänen
• ‘HotSwap’ Thin pools
• Quality of Service ^[67]

Lizenzmodell

Die DataCore Software Corporation lizensiert SANsymphony nach genutzter Kapazität. Hierbei gibt es die Möglichkeit zwischen 8 TB, 16 TB und unbegrenzt zu entscheiden. Die einzelnen Lizenzen unterscheiden sich allerdings nicht in den möglichen Funktionen sondern ausschließlich in der Kapazität des Speichers. ^[68]

Die Kosten für eine Basislizenz bei einer Kapazität von 8TB beläuft sich auf 18.025,12 €. (Stand: 01.01.2009 Listenpreise) ^[69]

7.7.3 Hitachi Universal Storage Platform V

Hitachi Data Systems, mit Hauptsitz in Santa Clara Californien, ist ein Unternehmen mit dem Augenmerk auf Speicherinfrastrukturlösungen und Speichermanagementsoftware. ^[70] "Hitachi Data Systems nutzt weltweite Forschungs- und Entwicklungs-Ressourcen, um Speicherlösungen mit einer branchenweit führenden Technologie, Performance, Verfügbarkeit und Skalierbarkeit zu entwickeln(.) […]Hitachi Data Systems beschäftigt rund 4.100 Mitarbeiter und tätigt Geschäfte über direkte und indirekte Vertriebswege mit Kunden aus dem öffentlichen und privaten Sektor sowie aus Regierungseinrichtungen in über 170 Ländern und Regionen."^[71]

Hitachi Data Systems hat sich bereits auf dem Markt der Speicherinfrastruktur als Hersteller etabliert. "Mit der Einführung der Hitachi Universal Storage Platform™ V (USP V) hat Hitachi […] ein neues Kapitel in der Geschichte der Speichersysteme aufgeschlagen."^[72] Hitachi bietet ebenso wie seine Konkurrenten die bereits im Vorfeld betrachteten Features:

• Thin Provisioning
• E/A-Lastausgleich
• Volume-Verwaltung über heterogene Speichersysteme hinweg
• Unterbrechungsfreie Datenmigration
• Sicherheitsdienste (Unveränderlichkeit, Protokollierung, Auditing, Datenvernichtung)
• Business Continuity-Services
• Content Management-Dienste (Suchfunktion, Indexierung)
• Datendeduplikation
• Datenklassifizierung
• Dateiverwaltungsdienste ^[72]

"Von schnell wachsenden mittelständischen Unternehmen bis hin zu global agierenden Großkonzernen kann nun jede Firma die leistungsstärkste und skalierbarste Speicherlösung der Branche nutzen. Unterstützt wird sie von einer Reihe Speicher- und Datendiensten, darunter Thin Provisioning mit der Hitachi Dynamic Provisioning™-Software, anwendungszentriertes Storage Management und logische Partitionierung sowie vereinfachte und vereinheitlichte Datenreplikation über heterogene Speichersysteme hinweg.[…] Somit werden Kosten gesenkt, die Nutzungsdauer verlängert und die Verwaltung vereinfacht." ^[72]

Lizenzmodell

Hitachi Data Systems lizensiert sein Universal Storage Platform V nach genutzten Diensten. Nach Wahl des Kunden wird für die eingesetzten Dienste Lizenzkosten erhoben, so können Unternehmen nach Budget und Nutzen eine Virtualisierung von Speichersystemen realisiert werden. ^[73]

In diesem Fall liegen keine Lizenzkosten pro Dienst vor.

7.7.4 Hewlett Packard SAN Virtualization Services Platform (HP SVSP)

Hewlett Packard mit Sitz in Palo Alto, Kalifornien (USA) ist nach eigenen Angaben der Marktführer im Bereich von Storage Area Networks. Das Unternehmen beschäftigt weltweit ca. 210.000 Mitarbeiter und erzielte im Geschäftsjahr 2007 einen Umsatz von 118 Bill. US-Dollar.^[74]

Mit dem Produkt StorageWorks etablierte die Fa. Compaq im Jahre 2001 ein System, mit dem der Speicher vom Server entkoppelt wurde. Nach der Übernahme von Compaq durch HP im Jahre 2002 wurde diese Produktreihe in das Portfolio übernommen und kontinuierlich weiterentwickelt. Mit dem StorageWorks Virtualization Services Manager (VSM) Server bietet HP ein Produkt an welches eine Virtualisierungsschicht gemäß den obigen Ausführungen realisiert. Die Appliance bietet folgende Services:

• Mirroring
• Cloning
• Snapshotting
• Migration
• Thin Provisioning

Lizenzmodell

Die Realisierung geschieht mittels einer Windows 2003 basierenden Appliance, auf der einzelne Services sukzessiv nach Volumen lizensiert werden. Der Hersteller bezeichnet diese Services in seinem Lizenzmodell als Module. Der Produktübersicht können diese Module entnommen werden:

• HP SAN Virtualization Services Platform Volume Manager SW
• HP SAN Virtualization Services Platform Business Copy SW
• HP SAN Virtualization Services Platform Continuous Access
• HP SVSP Thin Provisioning SW

Die Lizensierung der Module erfolgt in 1 TB Schritten. Der Kunde kann durch den modularen Aufbau des Lizenzmodells, die Lizensierung am konkreten Bedarf ausrichten.^[75]

7.7.5 Benchmarks

Unter Benchmarking versteht man die gezielte und umfassende Suche nach Vergleichsgrößen und Richtwerten, die repräsentativ sind für die besten Verfahren und Methoden. Eine immer wichtigere Rolle spielt die Kundenzufriedenheit.^[76]

Im Benchmark von Storage Performance Council erreicht IBM, DataCore, Hitachi und HP für ihre Speichervirtualisierungsprodukte gute Ergebnisse.

Storage Performance Council (SPC) definiert, administriert und veröffentlicht Industriestandards und anbieterunabhängige Benchmarks um die Performanz von Speichersystemen zu charakterisieren. ^[77]Die Benchmark-Tests im Bereich der Speichervirtualisierung sind SPC-1 und SPC-2.

Der SPC-1 Benchmark dient der Leistungsdarstellung einer Speicherkomponente bei laufendem Betrieb von Anwendungen, die zufällige I/O Aktionen verlangen wie Datenbank-Operationen und Mail-Server-Implementierungen. ^[78]

Der SPC-2 Benchmark besteht aus drei verschiedenen Worklloads, die der Leistungsdarstellung einer Storage.Komponente während des Betriebs von Applikationen wie Video-on-demand, File Processing und Datenbankabfragen dienen, die sequentiellen Transfer großer Datenmengen erfordern.^[79]

IBM schnitt bei dem SPC-1 besonders gut ab, laut eigenen Aussagen haben sie einen neuen "Weltrekord beim Storage Performance Council-plattenbasierten Benchmark [erlangt]. Dieser belegt die hohe Skalierbarkeit von SVC und bestätigt die technologisch starke Rolle von IBM im Bereich Speicher-Virtualisierung mit dem derzeit als schnellstem getesteten System."^[80] Der neue SPC-1 Benchmark zeigt, dass IBM auf einem IBM DS4700 Laufwerk 274.997,58 IO Aktionen pro Sekunde unterstützt.^[81]

"DataCore bricht mit SANsymphony drei Rekorde in Schlüsselkriterien der SPC-1 Benchmark-Tests, und zwar bei der Datentransferrate, dem Preis-/Leistungsverhältnis sowie bei der Speicherauslastung."^[82]

• 50.003,55 IO Aktionen pro Sekunde (Datentransferrate (I/O-Leistung))
• 6,11 US Dollar pro IO pro Sekunde(halbiert DataCore die Kosten im Vergleich zum günstigsten Midrange-Subsystem)
• Resultate mit einem Drittel der Plattenlaufwerke, die der bisherige Rekordhalter bei den SPC-1-Tests benötigte^[83]

"Der Speicherhersteller Hitachi Data Systems baut seine Führungsrolle im Bereich hochperformanter High-End-Speichersysteme aus. Die Hitachi Universal Storage PlatformV (USP V) erzielte gemäß des Storage Performance Council (SPC) unter allen Speichersystemen seiner Klasse die besten Performance-Ergebnisse bei der "Benchmark 2"- Bewertung. Nach der SPC-2 Methodik erreichte die Hitachi Universal Storage PlatformV einen Gesamtdurchschnitt von 8.724,67 MB pro Sekunde mit einem einzigen Controller und übertrifft damit die ebenfalls getesteten Datendurchsatzlevel von Speichersystemen anderer Hersteller um das Achtfache."^[84]

Auch HP erzielte mit seinen Produkten im Benchmark gut Ergebnisse. Zu dem Produkt das hier beschrieben ist konnte allerdings keine genauen Angaben ermittelt werden.

7.8 Anwendungsbeispiele

Im Folgenden wird aufgezeigt in welchem Zusammenhang eine Virtualisierung mit den verschiedenen Systemen sinnvoll ist und die jeweiligen Vorteile.

7.8.1 Anwendungsbeispiele DataCore SANsymphony

Die Basler Versicherung mit Sitz im hessischen Bad Homburg hat auf der Basis von DataCores Virtualisierungsplattform SANsymphony, eine Lösung die nicht nur die Datenreplikation über die Distanz von 400km meistert, sondern auch lokale Ausfallsicherheiten bietet und die Speicherkosten durch freie Wahl der Storage Hardware senkt, realisiert.^[85]

Die Herausforderung bei diesem Projekt lag darin, dass ein kontinuierliches Datenwachstum, durch die Archivierungspflicht, wachsenden Email- und Geschäftskommunikation und neuen Applikationen wie beispielsweise ein DokumentenManagementSystem, entgegenzusehen ist. Man benötigt weiterhin eine hohe Verfügbarkeit der IT-Systeme und hatte ein bereits bestehendes SAN von 3,5 TB mit in die Planung einzubinden. Die größter Herausforderung lag allerdings darin eine Datenspiegelung über eine 1,5 Mbit-ATM- Standleitung und einer Entfernung von ca. 400km zu realisieren, ohne das Produktivsystem zu beeinträchtigen.^[86]

Die Basler-Versicherung entschied sich nach langer Auswahlphase dazu das Konzept von der DataCore zu implementieren, da es sich im Marktvergleich als effektiv und kostengünstig erwies.^[87]

Das Projekt wurde von der DataCore in mehreren Schritten implementiert. Zunächst wurden zwei Server im RAID 1-Verbund installiert.^[87] "Mit SANsymphony Server Edition 5.2 wurden diese als Storage Domain Server (SDS) in das SAN integriert und als zentrale Schaltstelle für sämtliche Plattenspeicher im SAN eingerichtet"^[88]. Zu den Features dieses Systems gehören, die Einrichtung zentraler virtueller Partitionen und Zonen aus dem Speicherpool, die automatische Zuweisung von Speicherkapazitäten für Applikationen, und aufsetzen synchroner Spiegel, sowie das Booten aus dem SAN. Zudem lizensierte man das Snapshot Verfahren zusätzlich, für eine geeignete Backup-Lösung.^[87]

"Zur Wartung der SANsymphony-Umgebung erhielten drei […] Mitarbeiter im IT-Team der Basler eine zweitätige Schulung von Kramer & Crew. Damit wurde den Mitarbeitern genügend Know-How vermittelt, um den täglichen Betrieb ohne Probleme zu meistern: Server-Einbildung in das SAN, Zuweisung von Plattenkapazität aus dem Storage-Pool, Erweiterung der Plattensysteme etc..

"Die Integration von SANsymphony in das SAN ging problemlos von statten, auch weil wir in intensiver Zusammenarbeit mit den Verantwortlichen bei der Basler exakte Vorbereitungen getroffen haben", sagt Servet Büyük, Vertriebsbeauftragter bei Kramer & Crew. "Es ist dabei wichtig, die Zertifizierungen aller Komponenten exakt zu prüfen und alle Installationen gründlich zu dokumentieren. Die Bedienung von SANsymphony ist dann relativ einfach"."^[89]

Um die Lösung zu realisieren wurden in der Basler Versicherung zwei Lizenzen SANsymphony Server Edition 5.2, eine Lizenz SANmelody Version D, die Optionen DataCore Snapshot-Option und DataCore Asyncoronous IP Mirroring (AIM) beschafft und in das bestehende System integriert. Die Vorteile die sich aus dieser Umsetzung ergeben sind der Katastrophenschutz, die Hochverfügbarkeit, die Hardwareunabhängigkeit und die Kosteneinsparungen.^[90]

7.8.2 Anwendungsbeispiele DataCore SANmelody

SANmelody wurde bei der Volkswagen Financial Services implementiert und galt als Projekt des Jahres. Die größte Herausforderung war das enorme Datenwachstum von ca. 300 Prozent jährlich.^[91]

„Das virtualisierte Speichernetz mit zentralem Management, Autofailover und -recovery sichert unternehmenskritische Daten, deren Menge jährlich um 300% wächst.

Volkswagen Financial Services (VWFS) virtualisiert mit SANmelody den vorhandenen Netzwerkspeicher, weist zentrale Speicherkapazität nach Bedarf zu und profitiert von höherer Auslastung, Ausfallsicherheit und minimiertem Verwaltungsaufwand.“^[92]

7.8.3 Anwendungsbeispiel DataCore SANmelody und SANsymphony(Felix Schoeller Gruppe)

Die Felix Schoeller Gruppe ist einer der größten Papierhersteller. Das Unternehmen ist seit über 110 Jahren in der Produktion von Spezialpapieren tätig. Mit Hauptsitz in Osnabrück und 5 weiteren Standorten in Deutschland beschäftigt das Unternehmen rund 2.400 Mitarbeiter die Spezialpapier für besondere Anwendungen herstellen, wie beispielsweise Foto- und Dekorpapier.^[93]

„Die IT-Infrastruktur am Hauptstandort Osnabrück war weitestgehend zweigeteilt. Unternehmenskritische SAP-Datenbanken und –Anwendungen sowie branchenspezifische Applikationen liefen auf einer Fibre-Channel-Infrastruktur mit dem Enterprise Storagesystem EVA von HP“, die seit kurzem mit EVA 4400 auch eine Speichervirtualisierung vornehmen. „Andere Anwendungen, darunter weniger geschäftskritische, aber auch File-, Exchange-, Citrix Terminal-, DNS- und Webservices waren in einer Speicherumgebung mit MSA- 1000- beziehungsweise MSA-1500-Plattenspeicher untergebracht.“^[94]

Der IT-Leiter von Schoeller hält fest das er eine leistungsstarke ausfallsichere SAN-Lösung benötigt um den Produktivbetrieb aufrecht zu erhalten. Der Dienstleister ISO Datentechnik, mit dem die Schoeller Gruppe in diesem Projekt zusammenarbeitet, hatte bereits zu Beginn die DataCore Speichervirtualisierung empfohlen, nach zahlreichen Tests, vor allem im Bereich der Ausfallszenarien, konnte DataCore SANmelody im Zusammenspiel mit VMware durch Flexibilität und hohe Sicherheit überzeugen.^[93]

Bei Lösung die bei der Felix Schoeller Gruppe implementiert wurde, wurde vor allem auf Performancewerte und eine Hochverfügbarkeit geachtet. Storage Domain Server (SDS) mit 8 GB RAM ermöglichen es das 32-fache an Chaching-Volumen aus den MSA-Controllern herauszuholen. Die Storage Server sind mit netto 6 TB großen Platten versehen. Auch die vier Fibre-Channel Karten sorgen für eine redundante Anbindung des SANs an den Switch. Zwei Verbindungen sind für die Darstellung der virtuellen Systeme, die anderen zwei werden für die synchrone Datenspiegelung benötigt. Für den VMware Server wurde eine Maschine mit 32 GB RAM gewählt. Um eine Ausfallsicher zu garantieren wurde ^[95]"die Hardware auf zwei Rechenzentren verteilt, sodass auch bei einer physischen Einwirkung der Betrieb einer Siete gewährleistet ist."^[96]

Nach der Migration des bisherigen Systems musste das neue System unter Beweis stellen wozu es in der Lage war.^[95] "Über die zentrale Managementoberfläche werden Volumes eingerichtet, zugwiesen und mit Hochverfügbarkeitsservices versorgt. DataCore Thin Provisioning optimiert dabei die Speicherauslastung indem den Hosts die vom Betriebssystem maximal zugelassenen Volume-Größen suggeriert werden, Speicherplatz aber erst beim tatsächlichen Beschreiben belegt wird."^[96] Dadurch ergab sich für die Felix Schoeller Gruppe weniger ungenutzter Speicherkapazität und eine Systemauslastung von bis zu 80 Prozent.^[95] "Im Normalbetrieb tragen dabei beide DataCore Maschinen zur Performance bei[…]. Beim Ausfall eines Systems übernimmt das verbleibende die gesamten I/O-Transaktionen durch vollautomatisches Failover/Failback für Daten und Datenpfade."^[96] So konnte eine Hochverfügbarkeitsergänzung auf der Speicherseite erzielt werden.

Die am Hauptstandort der Felix Schoeller Gruppe implementierte Lösung musste ihr Können auch schon einmal im Ernstfall unter Beweis stellen. Denn drei Server wurden von einem Stromausfall lahmgelegt. Doch das System arbeitet wie im Test und schaltete die virtuellen Maschinen und Laufwerke im laufenden Betrieb um. Nach einem Neustart der planmäßigen Maschinen wurde erneut umgeschaltet und alles ohne Downtimes.^[97]

In einem nächsten Schritt sollen die SANmelody Systeme auf SANsymphony am Hauptstandort geupgradet werden und zwar ohne Kapazitätslimit. SANmelody soll in weiteren Niederlassungen der Felix Schoeller Gruppe installiert werden und auf Basis der DataCore-Lösung das Disaster Recovery an einem dritten Standort sichergestellt werden. ^[97]

7.8.4 Anwendungsbeispiel IBM SVC (British Telecom)

British Telecom ist ein globales Telekommunikationsunternehmen, welches Sprach-, Daten- und Videokontakte für Unternehmen und Privatkunden weltweit anbietet. Aus historischen Gründen verwendet die British Telecom Speichersysteme auf die direkt zugegriffen wird. Das Problem bei dieser Speicherinfrastruktur ist der sich ständig ändernde Speicherbedarf, auf dem anderen hat man Probleme ihn zu füllen doch die Applikationen können nicht Plattenübergreifend arbeiten. Des Weiteren mussten Ausfallzeiten verringert werden und die Kosten insgesamt gesenkt werden.

Die British Telecom entschied sich dazu ein SAN auf Basis der Speichervirtualisierung von IBM zu implementieren. Das neue System sollte es dem Unternehmen ermöglichen Speicherkapazität dem System hinzuzufügen ohne Ausfallzeiten und eine zentrale Steuerung und Überwachung des Systems Die Vorteile die sich aus der Umsetzung ergaben waren:

• 10-fach schnelleres Speichern und Abrufen,
• Speicher kann exakter zugewiesen werden,
• Management-Kosten wurden um 30 % reduziert und
• System-Upgradezeit wurden um 50 % reduziert^[98]

7.8.5 Anwendungsbeispiel IBM SVC (St. Michael)

Eine katholische Krankenhaus gegründet im Jahre 1892 von den Schwestern von St. Joseph, St. Michael's Hospital hat eine lange und stolze Geschichte von Mitgefühl und die herausragenden Leistungen. Als führendes innenstädtisches Krankenhaus hat das St. Michael’s Hospital über 550 stationäre Betten und ein ausgedehntes Netz von ambulanten Kliniken, und der Innenstadt von Toronto ist der benannten Trauma Zentrum für Erwachsene. St. Michael ist für Exzellenz in Lehre und Forschung bekannt und ist ein Marktführer in vielen Bereichen, einschließlich Herz-Gentherapie und Trauma Pflege.^[99]

Zur Verbesserung der Verwaltung, Flexibilität und Erreichbarkeit der Röntgen- und Ultraschall-Filme sollte ein Online-Bildarchiv und Kommunikationssystem (PACS) eingerichtet werden, die alle Bilder speichert und elektronisch abruft. Allerdings bestand die bisherige IT-Infrastruktur aus einem Daten-Center mit 150 Compaq-Servern und Band- und Tape-Libraries. Zudem sollte ein unternehmensweiter Disaster-Recovery-Plan eingerichtet werden. Die Administratoren waren damit beschäftigt die Probleme die durch das bisherige System entstanden zu beheben, anstatt aktiv die Entwicklung neuer, strategischer IT-Lösungen voranzutreiben.^[99]

St. Michael's sollte um eine skalierbare, zuverlässige Speicherlösung bereichert werden, die Unterstützung der bestehenden Informationstechnologie (IT)-Infrastruktur sowie die neuen PACS Initiative sollten umgesetzt werden. Es erforderte eine Lösung, die mit großen Datenmengen und Durchsatz umgehen kann. Zudem sollte die neue Lösung hoch Verfügbar sein und flexibel sein. Um das IT-Personal und Ressourcen besser/ effizienter nutzen zu können, sollte eine zentrale Lösung geschaffen werden, die die Vereinfachung des Storage-Managements ermöglicht und einen Schutz der Systeme und Daten mit einem Disaster-Recovery-Plan realisiert.^[99]

Die Lösung des oben beschriebenen Problems wurde mit verschiedenen IBM Produkten gelöst um eine einheitliche Umgebung zu schaffen. Die unterschiedliche Speicherinfrastruktur im St. Michael wurde durch die Anschaffung eines 8TB IBMEnterprise Storage Server 800 ersetzt mit 3 TB für das Krankenhaus-Informations-System (HIS) und 5 TB für das PACS Repository. Um dem Personal des Krankenhauses einen schnellen zuverlässigen Zugriff auf die PACS-Umgebung zu gewährleisten wurde ein spezielles IBM TotalStorage Fast T900 Speichergerät zum Einsatz gebracht.^[99]

Um den Backup-Prozess zu zentralisieren wurde eine IBM Ultra Scalable Ultrium 3584 Tape Library installiert, die mit Hilfe der IBM Tivoli Storage Manger-Software eine automatische Sicherung aller Daten und Serveranwendungen vornimmt. Um die IT Belastung weiter zu minimieren wurde der IBM SAN Volume Controller eingerichtet, der die Virtualisierung der Storageumgebung vornimmt und so eine bessere Nutzung der Ressourcen-, Daten-Replikations-und Disaster-Recovery ermöglicht. ^[99]

Durch die robuste Speicherinfrastruktur konnte die Verfügbarkeit des Speichers von 97 Prozent auf 99,999 Prozent erhöht werden. Die Belastung der Mitarbeiter der IT-Abteilung konnte reduziert werden ohne neue Mitarbeiter einzustellen, da die Systeme zentral verwaltet werden können und das Backupverfahren automatisiert funktioniert. Zudem konnten die Gefahr von Ausfallzeiten und Datenverlust durch das neue System minimiert werden. Die Kontrolle aller IT-Systeme kann nun zentral erfolgen. ^[99]

7.9 Wirtschaftlichkeit

Um die Wirtschaftlichkeit einer Investition zu betrachten gibt es viele Verfahren. Das interessanteste Verfahren für die Käufer ist das Total-Cost-of-Ownership (TCO) und Return on Investment (RoI), da die Verfahren aufzeigen wann sich eine Investition lohnt oder ob sie sich überhaupt lohnt und was an Kosten auf den Käufer auch in Zukunft entstehen.

Die Total-Cost-of-Ownership ermittelt Lebenszykluskosten, d.h. die Anschaffungs- und Betriebskosten eines Produktes.

Der Return on Investment soll vor allem verdeckte Betriebskosten aufdecken, er zeigt auf zu welchem Zeitpunkt sich eine Investition amortisiert.

Die täglichen Herausforderungen werden immer komplexer, die IT-Infrastruktur muss skalierbar und flexibel sein. Die Kapazität muss in Echtzeit schnell und problemlos erweiterbar oder veränderbar sein. Trotz steigender Speicheranforderungen müssen IT-Abteilungen mit immer geringeren Budgets auskommen, die TCO (Total Cost of Ownership) reduzieren und die Effektivität der Mitarbeiter erhöhen, um die Gesamtkosten zu senken. Darüber hinaus muss die Benutzerfreundlichkeit der Systeme sichergestellt werden, um so eine möglichst einfach Administration zu ermöglichen.^[100]

Das neue Stichwort bei Investitionen lautet Kosteneffektivität, dass heißt es muss ein positiver ROI (Return on Investment) erzielt werden und die Investition muss von höchstem Nutzen für das Unternehmen sein.^[100]

Virtualisierung ist eine strategische Technologie, es hilft Unternehmen in vielen Bereichen Kosten zu reduzieren und dabei die Performance zu erhöhen.^[101] "Branchenspezifische Untersuchungen zeigen, dass nur 40 % der Speicherressourcen und Mitarbeiter im IT-Bereich effektiv eingesetzt werden. In Verbindung mit begrenzten Budgets und knapper Personalverfügbarkeit müssen Unternehmen deshalb nach neuen Ansätzen suchen, um die Auslastung der Speicherressourcen signifikant zu erhöhen."^[102] Weniger Hardware, sinkender Aufwand für Management und Wartung, niedrigere Betriebskosten gehören zu den Vorteilen einer virtualisierten IT-Infrastruktur.^[101]

Ob eine Investition im Bereich der Speichervirtualisierung in einem Unternehmen sinnvoll ist muss allerdings jedes Unternehmen im Einzelfall für sich entscheiden. Es gibt keine allgemeingültige Aussage. Bei einer Entscheidung sollte nicht nur der monetäre Nutzen einer Investiton im Vordergrund stehen, sondern auch der nicht-monetäre Mehrwert einer Investition beachtet werden.

8 Fazit

Dem Markt für Server-Virtualisierung wird auch in den kommenden Jahren ein hohes Wachstumspotential zugeschrieben. Um alle Vorteile eines virtualisierten Rechenzentrums nutzen zu können, ist die Virtualisierung des SANs ein notwendiger Schritt. Wie unter Punkt (7.4) bereits ausgeführt ist mit der Virtualisierung von Storage Area Networks eine Technologie entstanden, die es einer Organisation gestattet Ihre Datenhaltung flexibler, sicherer und effizienter zu auszurichten.

Markt

Ein Anbieter für SAN-Virtualisierung muss nicht nur über ein ausgeprägtes Know-How im Speicherbereich verfügen, sondern gleichermaßen das Vertrauen der Kunden, die angebotene Lösung über einen Fokus von 5-10 Jahren und darüber hinaus am Markt etablieren zu können. Ferner sind hohe Aufwendungen für Test erforderlich, um die Interoperabilität mit möglichst vielen Speichersystemen sicherzustellen. Dies stellen hohe Markteintrittsbarrieren für potentielle Anbieter von virtuellen SAN-Lösungen dar und hat die Zahl der Anbieter bisher übersichtlich gehalten. Dem entsprechend sind die Preise für diese Lösungen relativ hoch. Die hohen Anschaffungskosten und häufig volumenorientierten Lizenzmodelle halten momentan noch viele Organisationen von einer Implementierung einer Virtualisierungsschicht in Ihr Datenhaltungsmodell ab. Eine Darstellung der Wirtschaftlichkeit hängt zum Teil auch an der schwer darstellbaren monetären Bewertungen von Faktoren wie Sicherheit oder Flexibilität bei der Auswahl von Speichergeräten. Zwar wird der Nutzen von Features wie unterbrechungsfreiem Failover oder Thin-Provisioning nicht in Frage gestellt, es gelingt jedoch häufig nicht die Wirtschaftlichkeit dieser Punkte zu thematisieren und schlüssig darzustellen.

Die meisten Anbieter von SAN-Virtualisierung verkaufen Ihre Lösung als Appliance. Im Kern handelt es sich bei allen Lösungen um eine Software. Es ist also bei steigender Verbreitung von virtuellen SAN-Lösungen mit deutlich fallenden Preisen zu rechnen, was wiederum die Verbreitung begünstigt. Die Virtualisierung von Storage Area Networks wird demnach in den kommenden Jahren stark ansteigen. Ob es noch eine Open Source Entwicklung in diesem Bereich gibt, bleibt abzuwarten.

Stellung im RZ

Aufgrund der hohen Preise ist die Virtualisierung des SAN im Moment noch eine Enterprice-Technologie. Das heißt, die Technologie kommt nur in größeren Umgebungen zum Einsatz. Mit sinkenden Preisen wird die Virtualisierung von Storage Area Networks auch in kleinere Rechenzentren Einzug halten. Durch die Möglichkeit ein virtuelles SAN hybrid mit verschiedenen Netzwerktopologien zu betreiben, ist es denkbar, dass sich die SAN-Virtualisierung zu einer Schlüsseltechnologie entwickelt an der Schwelle zum professionellen Rechenzentrum steht. Ein zuvor virtualisiertes des SAN, welches günstige NAS-Systeme unter iSCSI nutzt, kann später sukzessiv, bedarfsorientiert deutlich leichter ausgebaut werden als herkömmliche Umgebungen. Hier zeigen die Anbieter durch entsprechende Lizenzmodelle (Punkte 7.7.1 - 7.7.4) erste Ansätze, den Einstieg in die Technologie zu günstigen Konditionen zu ermöglichen.

9 Fußnoten

1. ↑ Vgl. Troppens (2008) S.127
2. ↑ Vgl. Troppens (2008) S.71
3. ↑ Vgl. IBM (2009)
4. ↑ Vgl. Troppens (2008) S.106
5. ↑ Brocade (2002) S.39 - S.43
6. ↑ Vgl. Troppens (2008) S.58
7. ↑ Vgl. Brocade (2002) S.16 f.
8. ↑ ^{8,0 8,1} Vgl. Launer (2009)
9. ↑ Vgl. Froehlich (2009)
10. ↑ ^{10,0 10,1} Troppens (2008) S.54
11. ↑ Vgl. Troppens (2008) S.55 f
12. ↑ Vgl. Troppens (2008) S.57
13. ↑ ^{13,0 13,1} Vgl. Troppens (2008) S.44
14. ↑ Troppens (2008) S.44
15. ↑ Vgl. Troppens (2008) S.45
16. ↑ ^{16,0 16,1 16,2} Troppens (2008) S.45
17. ↑ Vgl. Troppens (2008) S.45 f
18. ↑ Vgl. Troppens (2008) S.47
19. ↑ Troppens (2008) S.47
20. ↑ ^{20,0 20,1 20,2 20,3} Vgl. EMC (2005) S.5
21. ↑ Vgl. SearchDataCenter (2009)
22. ↑ Vgl. SearchDataCenter (2009b)
23. ↑ Vgl. EMC (2005) S.11-S.13
24. ↑ Vgl. Troppens (2008) S.48
25. ↑ Vgl. Troppens (2008) S.49
26. ↑ Vgl. Troppens (2008) S.420
27. ↑ Vgl. Dinger (2008) S.71
28. ↑ Vgl. Troppens (2008) S.425 ff.
29. ↑ Troppens (2008) S.435 ff.
30. ↑ Vgl. SNIA (2009)
31. ↑ Vgl. SNIA (2007) S.19 ff.
32. ↑ Vgl. IBM (2003) S.7
33. ↑ Vgl. Troppens (2008) S.178
34. ↑ Vgl. HP (2008) S.2
35. ↑ ^{35,0 35,1 35,2} Vgl. Troppens (2008) S.184
36. ↑ Vgl. Troppens (2008) S.187
37. ↑ ^{37,0 37,1} Vgl. IBM (2003) S.8
38. ↑ Vgl. Troppens (2008) S.186
39. ↑ ^{39,0 39,1} Vgl. Troppens (2008) S.193
40. ↑ Vgl. Troppens (2008) S.191
41. ↑ Vgl. Troppens (2008) S.192
42. ↑ Vgl. IBM (2003) S.10
43. ↑ Vgl. Troppens (2008) S.194
44. ↑ ^{44,0 44,1} Vgl. IBM (2003) S.11
45. ↑ Vgl. Troppens (2008) S.197
46. ↑ Vgl. Troppens 2008) S.194-S.197
47. ↑ Vgl. Troppens (2008) S.198-S.199
48. ↑ ^{48,0 48,1 48,2} Vgl. Datacore (2007)
49. ↑ Vgl. IBM (2006) S.378
50. ↑ Vgl. IBM (2006) S.379
51. ↑ ^{51,0 51,1 51,2} Vgl.Schmitt (2007)
52. ↑ Vgl. Emulex (2004)
53. ↑ Datacore (2009)
54. ↑ Vgl. Troppens (2008) S.441
55. ↑ Vgl. Data Core (2007) S.1
56. ↑ Vlg. M&C Deutschland (2009)
57. ↑ SNIA (2009b)
58. ↑ Vgl. SNIA (2009)
59. ↑ IBM (2009b)
60. ↑ IBM (2009c)
61. ↑ ^{61,0 61,1} Vgl. IBM (2009c)
62. ↑ ^{62,0 62,1} Vgl. DataCore (2009b)
63. ↑ ^{63,0 63,1} Vgl. Datacore (2005)
64. ↑ Datacore (2005)
65. ↑ Vgl. DataCore (2009c)
66. ↑ Vgl. TargoSoft (2009)
67. ↑ ^{67,0 67,1} Vgl. Datacore (2007b)
68. ↑ Vgl. DataCore (2009d)
69. ↑ Vgl. BCD-SINTRAG AG (2009)
70. ↑ Vgl. Hitachi (2009)
71. ↑ Vgl. Hitachi (2009)
72. ↑ ^{72,0 72,1 72,2} Hitachi (2009b)
73. ↑ Vgl. Hitachi (2009b)
74. ↑ Vgl. HP (2009b) S.1 f.
75. ↑ Vgl. HP (2009c) S.6 f.
76. ↑ Vgl. Ehrmann (2007) S.170
77. ↑ Vgl. Storage Performance Council (2009)
78. ↑ Vgl. Storage Performance Council (2009b)
79. ↑ Vgl. Storage Performance Council (2009c)
80. ↑ M&C Deutschland (2009)
81. ↑ Vlg. M&C Deutschland (2009)
82. ↑ Pressebox (2009)
83. ↑ Vgl. Pressebox (2009)
84. ↑ Hitachi (2009c)
85. ↑ Vgl. Datacore (2009e) S.1
86. ↑ Vgl. Datacore (2009e) S.1 f
87. ↑ ^{87,0 87,1 87,2} Vgl. Datacore (2009e) S.2
88. ↑ Datacore (2009e) S.2
89. ↑ Datacore (2009e) S.2 f
90. ↑ Vgl. Datacore (2009e) S.4
91. ↑ Vgl. Datacore(2009f)
92. ↑ Datacore(2009f)
93. ↑ ^{93,0 93,1} Vgl. SearchDataCenter.de (2008) S.65
94. ↑ SearchDataCenter.de (2008) S.65
95. ↑ ^{95,0 95,1 95,2} Vgl. SearchDataCenter.de (2008) S.66
96. ↑ ^{96,0 96,1 96,2} SearchDataCenter.de (2008) S.66
97. ↑ ^{97,0 97,1} Vgl. SearchDataCenter.de (2008) S.67
98. ↑ IBM (2004)
99. ↑ ^{99,0 99,1 99,2 99,3 99,4 99,5} Vgl. IBM (2006b)
100. ↑ ^{100,0 100,1} Vgl. HP (2005) S.3
101. ↑ ^{101,0 101,1} Vgl. SearchDataCenter (2009c)
102. ↑ Seceidos (2009)

10 Glossar

Agenten/Software-Agent	Computerprogramm, das zu gewissem eigenständigem Verhalten fähig ist
Appliance	Computer, der darauf ausgelegt ist, eine eng begrenzte Funktionalität zu bieten und wenige Eingriffe seines Besitzers zu erfordern
API	standardisierte Programmierschnittstelle
Array	strukturierte Anordnung von Zahlen, Texten, Funktionsbausteinen, Anschlussstiften oder Hardware-Elementen
	hier: Synonym für RAID-System
Backup	partielles oder vollständiges Kopieren der in einem Computersystem vorhandenen Daten auf ein alternatives Speichermedium
Cache	Zwischenspeicher
Continous Data Protection	Technik für die Datenspeicherung bei der nur die Veränderungen der Daten kontinuierlich nachverfolgt und erfasst werden
Cloning	Erstellen einer identischen Kopie
	hier: Duplizieren einer durch ein Storage System bereitgestellten Festplatte
Controller	Steuereinheit
Copy-on-Write	Optimierungsmethode zur Vermeidung überflüssiger Kopien von Daten
Cluster	Anzahl von vernetzten Computern, die von außen in vielen Fällen als ein Computer gesehen werden können mit dem Ziel der Performancesteigerung oder der verbesserten Ausfallsicherheit
Clustern/Clustering	Bildung eines oder mehrerer Cluster
central processing unit/CPU	(engl. Hauptprozessor)
Data Core	international agierender, US-amerikanischer Softwarehersteller
Discovery	(engl. Entdeckung)
	hier: Dienst, der in Speichernetzen nach vorhandenen Nachbarn oder anderen Endgeräten sucht
Disk	magnetische, drehende Speicher oder Begriffe die sich auf diese beziehen
Downtime	(engl. Stillstandszeit, Ausfallzeit, Abstellzeit) Zeit, in der ein System (insb. ein Computersystem) nicht verfügbar bzw. nicht funktionstüchtig ist
Ethernet	Satz von Standards für Kabeltypen, Stecker, Paketformate und Protokolle einer kabelgebundenen Datennetztechnik
Fabric	(engl. Gewebe) redundante Art der Vernetzung
	hier: Verbindung zwischen zwei oder mehreren Fibre Channel Switchen
Failover	Funktion einer Komponente wird im Falle eines Fehlers von einer anderen Komponente übernommen
Fibre-Channel/FC	Standardprotokoll aus dem Bereich der Speichernetzwerke
Fibre Alliance	von EMC2 gegründetes Zweckbündnis zur Definition der Fibre Alliance MIB
Fileserver	Station in einem Netzwerk, die für die Verwaltung eines lokalen Dateisystems zuständig ist
Host	(engl. Wirt, Gastgeber) (Betriebs-) System, das Server oder Clients beherbergt
Host-Bus-Adapter/HBA	Hardwareschnittstelle, die ein Computersystem mit externen oder internen Netzwerk-, Speicher- oder anderen Geräten verbindet
Hot Swap	Austauschen von Systemkomponenten während des normalen laufenden Betriebs
Hewlett-Packard/HP	weltweit agierendes, US-amerikanisches IT- und Beratungsunternehmen
Hitachi	weitweit agierender, japanischer Elektronikkonzern
International Business Machines Corporation/IBM	weltweit agierendes, US-amerikanisches IT- und Beratungsunternehmen
Load Balancing	Verfahren, um bei der Speicherung, dem Transport und der Verarbeitung von Daten, die Auslastung gleichermaßen auf zwei oder mehr Systemkomponenten zu verteilen
Logical Unit Number/LUN	von einem Disk Array zugewiesene virtuelle Festplatte
MAC-Adresse	eindeutige Adresse für alle Rechner, die über eine Ethernet-Adapterkarten an ein Ethernet angeschlossen sind
Mapping u. Locking Tabellen	Tabellen, in denen dokumentiert ist, welches System gerade welche Dateien lesend oder schreibend geöffnet hat
Metadaten-Controller	hier: Appliance die die Funktion der SAN Virtualisierung übernimmt
Mirroring	hier: das synchrone oder asynchrone Spiegeln zweier Volumes
Monitoring	Überbegriff für alle Arten der unmittelbaren systematischen Erfassung, Beobachtung oder Überwachung eines Vorgangs, Prozesses oder Zustands mittels technischer Hilfsmittel oder anderer Beobachtungssysteme
Overhead	alle Informationen, die zusätzlich zu den Nutzdaten übertragen werden
RAID	Organisation mehrerer physischer Festplatten eines Computers zu einem logischen Laufwerk mit dem Ziel der Performancesteigerung oder der verbesserten Ausfallsicherheit
Raw Devices	zeichenorientierte Gerätedatei, die unter Unix bzw. Linux den direkten Zugriff auf eine Festplattenpartition erlaubt
Recovery	Wiederherstellung von Daten
Restore	Wiederherstellung gelöschter oder beschädigter Daten von einem Sicherungsmedium
Single Point auf Failure/SPOF	Bestandteil eines technischen Systems, dessen Ausfall den Ausfall des gesamten Systems zur Folge hat
Serial ATA/SATA	ein für den Datenaustausch zwischen Prozessor und Festplatte entwickelter Datenbus
Sizing	hier: Einschätzung der benötigten Kapazitätsbedarfe eines neuen, noch nicht implementierten Computersystems und dessen Wachstum in der Zukunft
Snapshot	(engl. Schnappschuss)
	hier: Einfrieren des Zustandes einer durch ein Storage System bereitgestellten Festplatte
Split Mirror	Spiegeltechnologie zur Datensicherung
Thin Provisioning	"schlanke Speicherzuweisung": Eine kostensparende Zuweisung von Speicherkapazitäten in virtualisierten SAN Umgebungen.
Topologie	Struktur der Verbindungen mehrerer Geräte untereinander
VMware	VMware, ist ein US-amerikanisches Unternehmen, das Software im Bereich der Virtualisierung herstellt.
(Logical) Volume Manager/LVM	hauptsächlich im Unix- und Linux-Umfeld verbreitete Abstraktionsebene zwischen Festplatten und Dateisystemen
Zoning	Unterteilung von Speichernetzen in Teilnetzwerke

11 Literatur- und Quellenverzeichnis

Bücher
Boddenberg (2009)	Boddenberg, Ulrich: "Windows Server 2008": Das umfassende Handbuch, 2. Auflage, Galileo Computing
Dinger (2008)	Dinger, Jochen; Hartenstein, Hannes: "Netzwerk- und IT-sicherheitsmanagement": Eine Einführung, Universitätsverlag, Karlsruhe 2008
Ehrmann (2007)	Prof. Dr. Ehrmann, Harald: "Unternehmensplaung", 5. Auflage, Friedrich Kiehl Verlag, Ludwigshafen(Rhein) 2008
EMC (2005)	EMC (Hrsg.): SnapView Configuration and Management Student Guide, 2005
Poelker (2009)	Poelker, Christopher; Nikitin, Alexander: "Storage Area Networks": For Dummies, 2nd Edition, Wiley, Indianapolis 2009
Troppens (2008)	Troppen, Ulf; Erkens, Rainer; Müller, Wolfgang: "Speichernetze": Grundlage und Einsatz von Fibre Channel SAN, NAS, ISCSI und Infiniband, 2. Auflage, dpunkt.verlag, Heidelberg 2008

Zeitschrift
SearchDataCenter.de (2008)	SearchDataCenter.de (Hrsg.): Kompendium zur Virtualisierung - DataCore SANmelody und SANsymphony bei der Felix Scholler Gruppe, 2008

Internetquellen
BCD-SINTRAG AG (2009)	BCD-SINTRAG AG (Hrsg.): Endkunden-Preisliste Schweiz für DataCore Software, http://www.bcd-sintrag.ch/doc/doc_download.cfm?uuid=ECC88C2B14C260EC79FA059C911094FC&&IRACER_AUTOLINK&&, Stand:11.06.2009
Brocade (2002)	Brocade(Hrsg.): SAN Design Guide, http://www.brocadekorea.com/download/resource/53-0000231-03.pdf, 2002
Datacore (2005)	Datacore (Hrsg.): SANmelody Datasheet, http://www.ccpsoft.de/Virtualisierung_2009/datacore/DataCore_SANmelody_DS.pdf, Stand:11.06.2009
Datacore (2007)	Hagen, Christian: 10 Gründe für Speichervirtualisierung, http://germany.datacore.com/downloads/GR%2010%20Gr%C3%BCnde%20f%C3%BCr%20Speichervirtualisierung_fin.pdf
Datacore (2007b)	Datacore (Hrsg.): Datacore - SANsymphony Produktbroschüre , http://germany.datacore.com/downloads/dc_enduser_gr.pdf, Stand:11.06.2009
Datacore (2009)	Datacore (Hrsg.): SAN Symphany Presentation, http://www.datacore.com/products/prod_SANsymp_data_protection.asp?l=de, Stand:11.06.2009
Datacore (2009b)	Datacore (Hrsg.): Datacore - About Us, http://datacore.com/about_datacore/about_home.asp?l=de, Stand:11.06.2009
Datacore (2009c)	Datacore (Hrsg.): Datacore - SANmelody - How to Buy , http://www.datacore.com/products/prod_SANmelody_buy.asp, Stand:11.06.2009
Datacore (2009d)	Datacore (Hrsg.): Datacore - SANsymphony - How to Buy , http://www.datacore.com/products/prod_SANsymp_howtobuy.asp?l=de, Stand:11.06.2009
Datacore (2009e)	Datacore (Hrsg.): Datacore - SANsymphony - Fallstudie Basler Versicherung , http://www.datacore.de/downloads/Fallstudie_Basler.pdf, Stand:11.06.2009
Datacore (2009f)	Datacore (Hrsg.): Datacore - 300 Prozent Datenwachstum durch Virtualisierung gemeistert, http://www.datacore.de/downloads/Fallstudie_Volkswagen.pdf, Stand:10.06.2009
Emulex (2004)	Emulex (Hrsg.): Maximizing Solaris Quality of Service–the Role of Fibre Channel HBAs, http://www.emulex.com/artifacts/c513cb4e-2fc8-404d-a527-e8954c363573/solaris-maximizing.pdf
Fröhlich (2009)	Karl Fröhlich: Grundlagen: Fibre-Channel-Switches, http://www.tecchannel.de/storage/san/429772/grundlagen_fibre_channel_switches/index5.html, Stand:11.06.2009
Hitachi (2009)	Hitachi(Hrsg.): Hitachi - Über Hitachi Data Systems, http://www.hds.com/de/corporate/about-hds/, Stand:11.06.2009
Hitachi (2009b)	Hitachi(Hrsg.): Hitachi - Produkte: Hitachi Universal Storage Platform V, http://www.hds.com/at/products/storage-systems/universal-storage-platform-v.html, Stand:11.06.2009
Hitachi (2009c)	Hitachi(Hrsg.): Hitachi - Produkte: Hitachi Universal Storage Platform V - Pressemitteilung, http://www.hds.com/de/corporate/press-analyst-center/press-releases/2008/de080912.html, Stand:10.06.2009
HP (2005)	HP (Hrsg.): Die HP StorageWorks 4000/6000/8000 Enterprise Virtual Array (EVA) Produktfamilie, http://www.alpha2000.de/download/hp_eva_familie.pdf, Stand:10.06.2009
HP (2008)	Hewlett-Packard Development Company (Hrsg.): HP StorageWorks virtualization - White Paper 4AA0-7358ENW, http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA0-7358ENW.pdf
HP (2009)	Hewlett-Packard Development Company (Hrsg.): HP StorageWorks SAN Virtualization Services Platform (HP SVSP) - White Paper 4AA2-3242ENW, http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA2-3242ENW.pdf
HP (2009b)	Hewlett-Packard Development Company (Hrsg.): HP in brief 2009 - Dokument 4AA0-8427ENW, http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA0-8427ENW.pdf
HP (2009c)	Hewlett-Packard Development Company (Hrsg.): Quickspecs HP StorageWorks SAN Virtualization Services Platform - Dokument DA - 13172, http://h18000.www1.hp.com/products/quickspecs/13172_div/13172_div.pdf
IBM (2003)	Tate, Jon: IBM Redbook Virtualization in a SAN, http://www.redbooks.ibm.com/redpapers/pdfs/redp3633.pdf
IBM (2004)	IBM (Hrsg.): IBM - BT Conferencing cuts remote meeting costs with a virtualised storage solution from IBM, http://157.22.20.165/Document.nsf/40FCAAA3CD1D8EAB8825704A006A8AAE/$FILE/IBM-06.04-BT%20high%20res.pdf?OpenElement, Stand:10.06.2009
IBM (2006)	Brooks, Charlotte; Byrne, Frank; Higuera, Leonardo; Krax, Carsten: John Kuo: IBM System Storage Solutions Handbook,http://www.redbooks.ibm.com/redbooks/pdfs/sg245250.pdf
IBM (2006b)	IBM (Hrsg.): IBM - Fallbeispiel St. Michael's Hospital, http://209.85.129.132/search?q=cache:s2pQ1FikkSgJ:gomezrocha.com/manuals/STORAGE/Storage%2520Informacion%25202007/System%2520Storage%2520Portfolio%2520Top%2520Gun%2520Feb%252019-23/Presentations/Day%25203/SSPTG%2520Feb07%2520%2520Selling%2520Disk%2520Virtualization%2520Solutions%2520print.ppt+%22St.+Michael%27s%22+consolidated+its+disparate+storage+infrastructure+by+connecting+its+IBM+eServer&cd=1&hl=de&ct=clnk&gl=de&client=firefox-a, Stand:10.06.2009
IBM (2009)	IBM (Hrsg.): IBM SAN Produkte, http://www-03.ibm.com/systems/de/storage/san/, Stand:11.06.2009
IBM (2009b)	IBM (Hrsg.): IBM Leistungsspektrum, http://www-05.ibm.com/de/ibm/leistungen/index.html, Stand:11.06.2009
IBM (2009c)	IBM (Hrsg.): IBM Datenblatt SVC, ftp://ftp.software.ibm.com/common/ssi/pm/sp/e/tsd00254dede/TSD00254DEDE.PDF, Stand:11.06.2009
Launer (2009)	Albert Launer: Fehler bei der Server- und Storage-Virtualisierung vermeiden, http://www.tecchannel.de/server/virtualisierung/1776255/fehler_virtualisierung/index8.html, Stand:11.06.2009
M&C Deutschland (2009)	M&C Deutschland (Hrsg.): IBM erweitert Speicher-Virtualisierungsmöglichkeiten, http://www.monstersandcritics.de/artikel/200843/article_107964.php/IBM-erweitert-Speicher-Virtualisierungsm%F6glichkeiten, Stand:10.06.2009
Pressebox (2009)	Pressebox (Hrsg.): DataCore bricht erneut Rekord bei Speicherleistung, http://www.pressebox.de/meldungen/pdf/presse-9973.pdf, Stand:10.06.2009
Schmitt (2007)	Schmitt, Kathrin: Thin Provisioning spielt mit den Träumen der Storage Admins,http://www.silicon.de/hardware/netzwerk-storage/0,39039015,39184571,00/thin+provisioning+spielt+mit+den+traeumen+der+storage+admins.htm, Stand: 30.05.2009
SearchDataCenter (2009)	SearchDataCenter (Hrsg.): Continuous Data Protection, http://www.searchdatacenter.de/glossar/Continuous%20Data%20Protection/articles/181719/, Stand:11.06.2009
SearchDataCenter (2009b)	SearchDataCenter (Hrsg.): Storage Snapshot, http://www.searchdatacenter.de/glossar/Storage%20Snapshot/articles/183577/, Stand:11.06.2009
SearchDataCenter (2009c)	SearchDataCenter (Hrsg.): Storage TCO/RoI, http://www.searchdatacenter.de/specials/herausforderung-management/, Stand:11.06.2009
Seceidos (2009)	Seceidos (Hrsg.): DataCore - Speichervirtualisierung und SAN Management, http://www.seceidos.de/de/produkte/technologien-und-loesungen/datacore/, Stand:10.06.2009
SNIA (2007)	Storage Networking Industry Association (Hrsg.): Storage Networking Industry Association - Storage Management Technical Specification, Overview Version 1.2.0, Revision 6, http://www.snia.org/tech_activities/standards/curr_standards/smi/SMI-S_Technical_Position_v1.2.0r6.zip
SNIA (2009)	Storage Networking Industry Association (Hrsg.): Storage Networking Industry Association - SNIA - SMI-S (SMI spec), http://www.snia.org/forums/smi/tech_programs/smis_home, Stand:10.06.2009
SNIA (2009b)	Storage Networking Industry Association (Hrsg.): Storage Networking Industry Association - SNIA - SNIA - SMI Member Companies, http://www.snia.org/forums/smi/about/member/smi_members, Stand:10.06.2009
Storage Performance Council (2009)	Storage Performance Council(Hrsg.): Storage Performance Council - SPC Benchmark Results, http://www.storageperformance.org/results/benchmark_results_all, Stand:10.06.2009
Storage Performance Council (2009b)	Storage Performance Council(Hrsg.): Storage Performance Council - SPC-1 Benchmark Results, http://www.storageperformance.org/results/benchmark_results_spc1#c00008, Stand:10.06.2009
Storage Performance Council (2009c)	Storage Performance Council(Hrsg.): Storage Performance Council - SPC-2 Benchmark Results, http://www.storageperformance.org/results/benchmark_results_spc2#c00008, Stand:10.06.2009
TargoSoft (2009)	TargoSoft (Hrsg.): TargoSoft - SANmelody Price List , http://www.targosoft.de/xtras/software/Datacore.pdf, Stand:11.06.2009