Storage Management in Unternehmen


Seminararbeit, 2011
32 Seiten, Note: 1,0

Leseprobe

Inhaltsverzeichnis

Abkürzungsverzeichnis

Tabellenverzeichnis

Abbildungsverzeichnis

1 Einleitung

2 Begri sde nitionen
2.1 Storage Management
2.2 Speicher

3 Storage-Systeme
3.1 Serverzentrierte Architektur
3.1.1 Direct Attached Storage
3.1.2 Network Attached Storage
3.1.3 Bewertung serverzentrierte Architektur
3.2 Speicherzentrierte Architektur
3.2.1 Storage Area Network
3.2.2 Disksubsysteme
3.2.2.1 Systeminterne Datenkopien .
3.2.2.2 LUN-Masking
3.2.2.3 Thin Provisioning
3.2.2.4 Hochverfügbarkeit
3.2.3 Storagevirtualisierung
3.2.4 Bewertung speicherzentrierte Architektur .

4 Storage-Verwaltung
4.1 Anforderungen
4.2 Verwaltungsschnittstellen
4.3 Storage Management Initiative Speci cation . .
4.4 Verwaltungswerkzeuge
4.4.1 Gerätebezogene Werkzeuge
4.4.2 Zentrale Werkzeuge
4.5 Bewertung Storage-Verwaltung

5 Schlussbetrachtung

Anhang 1: Abbildung Storage-Architekturen

Anhang 2: De nitionen und Funktionen der SMI-S Level

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten1

Tabellenverzeichnis

1 Vergleich Verfahren zur Datenkopieerstellung

2 De nitionen und Funktionen der SMI-S Level

Abbildungsverzeichnis

1 Vereinfachtes SMI-S Referenzmodell

2 Übersicht Storage-Architekturen

1 Einleitung

Die Entwicklung der IT-Komponenten ist von kontinuierlicher Erhöhung der Leistungsparamter geprägt. Dies macht auch vor Datenträgern nicht halt. Während 1989 eine Festplatte mit einer Kapazität von 20 Megabyte als sehr groÿ und kaum befüllbar galt, sind heute (im Jahre 2011) Festplatten mit einer Gröÿe von 2 Terabyte im Verkaufsportfolio kein besonderer Anblick mehr. Dass diese Kapazität auf Dauer ausreichen wird, ist nicht abzusehen.

So steigen auch die von Unternehmen gespeicherten Datenmengen in der Regel konti- nuierlich an. In der Literatur ist oft von rasantem Datenwachstum zu lesen, dessen Ende nicht absehbar ist . Gesetzliche und organisatorische Anforderungen tragen dazu bei. Dieses Wachstum ist eine Herausforderung für die IT-Abteilungen, auf dass sie meist nur reagieren kann. Eine Eindämmung ist ihnen kaum möglich, da die IT keinen direkten Ein uss auf das Wachstum hat. Daher müssen die IT-Abteilungen zum Einen fortlaufend die zusätzlich benötigten Kapazitäten bereitstellen und diese zum Anderen fortan verwalten.

Das soll nicht heiÿen, dass das Wachstum mit der Entwicklung gröÿerer Speicherkapazitäten einhergeht. Unternehmen, deren Datenwachstum schneller ist als die Entwicklung von Speicherkapazität, können nicht einfach die Festplatten tauschen. Doch auch wenn Kapazitäten ausreichend schnell zum Datenwachstum entwickelt werden, ist der Austausch von Festplatten losgelöst vom Server ohne spezielle Systeme oder aufwändiges Vorgehen nicht einfach möglich.

Es gilt aber nicht nur, hinreichende Kapazitäten bereitzustellen. Die gespeicher- ten Daten müssen verfügbar sein, wenn sie benötigt werden. Führen Ausfälle dazu, dass dies nicht möglich ist, entstehen den Unternehmen je nach Branche in unter- schiedlichem Ausmaÿ schnell groÿe Schäden, die im schlimmsten Fall zum Konkurs führen können.

Diese Arbeit zeigt auf, wie diesen Anforderungen begegnet werden kann. Sie führt den Leser zunächst zur De nition der verwendeten Begri e Storage Management und Speicher . Im Abschnitt Storage-Systeme wird die herkömmliche, serverzen- trierte Architektur, bezogen auf die Speicherung, dargestellt. Anschlieÿend wird dar- gelegt, was eine speicherzentrierte Architektur ist und was sie leistet. Der Aufbau der Netze selbst wird dabei nicht betrachtet, um den übrigen Bereichen hinrei- chend Raum geben zu können. Die ausgegrenzte Betrachtung wird dem grundle- genden Überblick über die Architekturen aber nicht im Wege stehen. Jeweils am Abschnittsende werden die beiden Architekturen zusammengefasst und bewertet. Im Abschnitt Storage-Verwaltung wird erläutert, wie Storage-Systeme einer spei- cherzentrierten Architektur verwaltet werden können. Dies ist insbesondere in kom- plexen Umgebungen eine Herausforderung. Auch dieser Abschnitt endet mit einer Zusammenfassung und Bewertung. Abschlieÿend werden die gewonnenen Erkenntnisse in einer Schlussbetrachtung zusammengefasst.

2 Begri sde nitionen

2.1 Storage Management

Eine einheitliche De nition des im Titel dieser Arbeit verwendeten Begri es Storage Management existiert nicht. Im Folgenden werden die Sichtweisen unterschiedlicher Quellen dargelegt und das daraus resultierende Vorgehen in dieser Arbeit darge- stellt.

Stahlknecht und Hasenkamp verstehen unter Storage Management2 eine dem tatsächlichen Bedarf angepasste Speicherkapazität sowie das Vermeiden von Redundanzen. (Vgl. Stahlknecht und Hasenkamp, 2005, S. 131.)

Konkret wird die Speicherplatzverwaltung auf den Plattenlaufwerken und die Da- tenträgerverwaltung (gemeint sind primär Magnetbänder) dem klassischen Stora- ge Management zugeordnet. Das moderne Storage Management will dagegen eine Trennung von logischer und physischer Datenorganisation erreichen. Hierbei werden die Strategien Direct Attached Storage (DAS), Network Attached Storage (NAS) und Storage Area Network (SAN) unterschieden. (Vgl. Stahlknecht und Hasenkamp, 2005, S. 456 f.)

Auch Döllinger et al. sehen einen Wandel des Storage Managements. Die Kapazitäten waren bisher nur einem oder mehreren Rechnern im näheren Umkreis zugehörig. Nun erleben die zentralen Speichersysteme und dezidierten Speichernetze einen Siegeszug. Standardaufgaben der für das heutige Storage Management zuständigen Personen sind die Überwachung, Zuweisung und Kon guration des Speichers. (Vgl. Döllinger et al., 2010, S. 255.)

Die Service Operating Publikation der IT Infrastructure Library (ITIL) beschreibt Storage Management in allgemeiner Form: Es ist ein Prozess, der für die Verwaltung des Speichers und die P ege der Daten über ihre gesamte Nutzungsdauer hinweg verantwortlich ist. (Vgl. Wheeldon et al., 2007, S. 247.)

Diesen Darstellungen folgend beginnt diese Arbeit mit der Betrachtung von Stora- ge Management bei den zugrundeliegenden Systemen (DAS, NAS und SAN) und Konzepten als ersten Bereich. Der zweite Bereich ist die Verwaltung von Speicher- systemen.3

Der Schwerpunkt wird dabei auf zentrale Speichersysteme, konkret auf die SANArchitektur, gelegt.

2.2 Speicher

In dieser Arbeit liegt der Schwerpunkt der Betrachtung auf dem peripheren Massenspeicher. Dem gegenüber ist der Begri Speicher allgemein auch für den Hauptspeicher (auch Primärspeicher) eines Computersystems geläu g. (Vgl. Stahlknecht und Hasenkamp, 2005, S. 22 u. 55 f.) Entsprechend des Schwerpunktes ist in dieser Arbeit mit dem Wort Speicher immer der Massenspeicher gemeint es sei denn, Hauptspeicher wird explizit als solcher benannt.

3 Storage-Systeme

Um die von einem Unternehmen genutzten Daten speichern und bei Bedarf wieder aufrufen zu können, existieren unterschiedliche Architekturen und Konzepte, die im Folgenden dargestellt werden.

Bei den genutzten Speichermedien handelt es sich meistens um Magnetplatten (vgl. Stahlknecht und Hasenkamp, 2005, S. 56 f.), deren Bedeutung aber zukünftig wohl abnehmen wird. (Vgl. Mücke, 2011, S. 13.) Oftmals bessere Performance bieten Solid State Disks (SSDs), welche von nahezu allen Storage-Anbietern entdeckt wurden. (Vgl. Riepe, 2011, S. 8 u. 10.) Es kommen aber auch andere Medien in Betracht, deren Nutzung je nach Anforderungen vorteilhaft ist, insbesondere für die Datensi- cherung und Archivierung. (Vgl. Stahlknecht und Hasenkamp, 2005, S. 57.)

Diese Arbeit betrachtet Speichersysteme, welche für die Ablage von Daten und de- ren zeitkritischen Abruf geeignet sind. Die genutzten Speichermedien nden dabei nachfolgend aufgrund des begrenzten Umfanges nur beiläu ge Berücksichtigung. Im Anhang be ndet sich auf S. 22 die Abbildung 2, welche die folgenden Darstel- lungen visualisiert.

3.1 Serverzentrierte Architektur

Troppens et al. beschreiben als serverzentrierte Architektur diejenigen Systeme, in welchen ein Speicher direkt an (zumeist4 ) einen Server angeschlossen ist. Um auf den Speicherinhalt zugreifen zu können, muss der Zugri immer über den dem Speicher zugehörigen Server erfolgen deshalb die Bezeichnung serverzentrierte Architektur. (Vgl. Troppens et al., 2008, S. 1.)

3.1.1 Direct Attached Storage

Der Speicher, welcher ohne ein Speichernetz direkt mit einem Host verbunden ist, wird Direct Attached Storage (DAS) genannt. Die Anbindung erfolgt z.B. über Small Computer System Interface (SCSI) oder Serial Attached SCSI (SAS). (Vgl. Troppens et al., 2008, S. 487.) Es handelt sich hierbei um die klassische Konstellation. Nach Stahlknecht und Hasenkamp hat DAS innerhalb des modernen Storage Management (siehe hierzu auch Seite 2 in Abschnitt 2.1) nur noch für Backupmaÿnahmen und kleinere Anwendungssysteme eine Bedeutung. (Vgl. Stahlknecht und Hasenkamp, 2005, S. 456.)

3.1.2 Network Attached Storage

Server, welche direkt an sie angeschlossenen Speicher in einem Netzwerk bereitstellen, werden als Network Attached Storage (NAS) bezeichnet. Die Nutzung des NAS kann dabei sowohl durch Clients als auch durch Anwendungsserver erfolgen. (Vgl. Stahlknecht und Hasenkamp, 2005, S. 456 f.)

Troppens et al. de nieren NAS enger. Demnach handelt es sich um vorkon gurierte Fileserver, welche oftmals mit einem angepassten Betriebssystem ausgeliefert werden. (Vgl. Troppens et al., 2008, S. 500.)

Die Daten auf einem NAS werden also aus dessen Sicht auf DAS gespeichert.

In seltenen Konstellationen sind zur Erhöhung der Ausfallsicherheit zwei Server an einen Speicher angeschlossen. Jedoch kann immer nur ein Server aktiv mit dem Speicher arbeiten.

3.1.3 Bewertung serverzentrierte Architektur

Der Vorteil eines NAS gegenüber einem herkömmlichen Server mit DAS kann eine höhere Leistung sein, da das Betriebssystem auf den Datentransfer ausgelegt ist. (Vgl. Hansen und Neumann, 2005, S. 132.) Jedoch werden mit NAS die Daten dateibasiert übertragen. Dies ist z.B. bei Datenbankservern nicht sinnvoll, da bei jeder Änderung die gesamte Datenbankdatei übertragen würde. Bei Fileservern ist dies hingegen irrelevant. (Vgl. Robbe, 2004, S. 31.)

Serverzentrierte Architekturen sind verglichen mit und ausblickend auf speicher- zentrierte Architekturen einfache und preisgünstige Methoden, um Daten zu spei- chern und wieder zur Verfügung stellen zu können. (Vgl. Hansen und Neumann, 2005, S. 131 f.)

Nachteilig ist die insgesamt beschränkte Leistung der Systeme sowie die Nutzung und damit Belastung des lokalen Netzes. (Vgl. Hansen und Neumann, 2005, S. 133.) Fällt ein Server aus, stehen die Daten seines DAS nicht mehr zur Verfügung. Zudem ist die Speicherzuordnung statisch: Server A kann in der Regel nicht den Speicher von Server B nutzen. Wenn Server A voll ist, können freie Kapazitäten von Server B nicht einfach genutzt werden. Auch die maximal mögliche Zuordnung von Speicher zu einem Server ist begrenzt, da er nur eine beschränkte Anzahl an Input/Output (I/O)- Karten aufnehmen kann. (Vgl. Troppens et al., 2008, S. 1 f.)

Wenn aber die Grenzen nicht relevant werden, ist die Nutzung von serverzentrierten Architekturen aus Kostengründen sinnvoll.

3.2 Speicherzentrierte Architektur

In speicherzentrierten Architekturen ist der Zugri auf den Speicher ohne einen dafür zuständigen Server möglich. Es können mehrere Server gleichzeitig auf ein Speichergerät zugreifen. Troppens et al. betrachten Server hier nur noch als Anhängsel am Speicher. Die Speichergeräte dagegen stehen im Zentrum der IT-Architektur. SCSI-Kabel werden dabei durch ein Speichernetz ersetzt, was zusätzlich zum Local Area Network (LAN) existiert.5 (Vgl. Troppens et al., 2008, S. 3.)

3.2.1 Storage Area Network

Das Speichernetz, was den Zugri der Server auf die Speichergeräte ermöglicht, wird Storage Area Network (SAN) oder auch Speichernetz genannt. Speichergeräte können z.B. Disksubsysteme, Bandbibliotheken oder Jukeboxen für optische Daten- träger sein. (Vgl. o. V., Heise Zeitschriftenverlag GmbH & Co. KG (Hrsg.), 2011, S. 185.) Meistens werden im Rahmen einer SAN-Einführung die DAS an den Ser- vern durch groÿe, gemeinsam genutzte Disksubsysteme ersetzt. (Vgl. Troppens et al., 6 2008, S. 3 f.) Auf sie wird im nachfolgenden Abschnitt 3.2.2 genauer eingegangen.6 Übertragungsprotokolle eines SAN sind beispielsweise Fibre Channel, iSCSI oder Fibre Channel over Ethernet (FCoE).7 (Vgl. o. V., Heise Zeitschriftenverlag GmbH & Co. KG (Hrsg.), 2011, S. 185.) Die Datenübertragung erfolgt im Gegensatz zum dateibasierten NAS (vgl. S. 5 in Abschnitt 3.1.3) blockbasiert. (Vgl. Troppens et al., 2008, S. 60 u. 485.) Es existieren jedoch auch Geräte am Markt, die neben den blockbasierten Protokollen gleichzeitig auch als NAS-Server mit Network File System (NFS) und Common Internet File System (CIFS) dateibasiert Daten zur Verfügung stellen. (Vgl. Wurm und Nolte, 2011, S. 80.) So kann z.B. mit der Server- virtualisierungssoftware VMware als Storage-Architektur ein NFS-Storage verwen- det werden. Aus Performancegründen sollten die NFS-Daten das SAN nutzen. (Vgl. Zimmer, 2010b, S. 403 u. 405.)

3.2.2 Disksubsysteme

Disksubsysteme stehen in unterschiedlichster Gröÿe zur Verfügung: Von Festplattengehäusen mit mehreren Platten bis hin zu Speicherschränken mit einem Gewicht über einer Tonne. (Vgl. Troppens et al., 2008, S. 16 f.)

Nachfolgend werden die Systeme aufgrund ihres Controllers unterschieden. (Vgl. Troppens et al., 2008, S. 21.)

Kein Controller Festplattengehäuse ohne Controller nehmen Festplatten auf und versorgen diese mit Strom. Die Festplatten werden von einem angeschlossenen Server einzeln erkannt. Eine geläu ge Bezeichnung ist Just a Bunch of Disks (JBOD). Der Vorteil ist ein besseres Handling gegenüber losen Platten.8 (Vgl. Troppens et al., 2008, S. 21 f.)

RAID-Controller Ein Disksubsystem mit Redundant Array of Independent Disks (RAID)-Controller ist eine Erweiterung von JBOD. Ein RAID scha t einer- seits eine Erhöhung der Performance durch Verteilung der Daten über mehrere Festplatten ( Striping ). Andererseits kann die Ausfallsicherheit durch mehr- fache Speicherung der Daten auf mehreren Festplatten erhöht werden ( Red- undanz ).9 Die physikalischen Eigenschaften der Platten werden durch den RAID-Controller zusammengefasst und den angeschlossenen Systemen virtu- ell in anderer Form präsentiert. (Vgl. Troppens et al., 2008, S. 22.) Der Controller besitzt wie auch bereits die einzelnen Festplatten einen schnellen Zwischenspeicher ( Cache ) zur Beschleunigung der Lese- und (ins- besondere der) Schreibzugri e. (Vgl. Wurm und Nolte, 2011, S. 76 f.)

Intelligenter Controller Troppens et al. kategorisieren Disksubsysteme, deren Con- troller über RAID hinaus Funktionen anbietet, als Systeme mit intelligentem Controller. (Vgl. Troppens et al., 2008, S. 44.)

Die Systeme sind häu g modular. So lassen sich Geräte mit einem Gehäuse meist erweitern. Highend-Systeme besitzen meist mehrere Controller je Ge- häuse. (Wurm und Nolte, 2011, S. 78.) Die Systeme können so konstruiert sein, dass sie den Ausfall jeder beliebigen Komponente verkraften können. Sie haben in diesem Fall also keinen Single Point of Failure. (Vgl. Troppens et al., 2008, S. 58.)

Funktionen dieser Disksubsysteme sind z.B. systeminterne Datenkopien in Form von Snapshots (siehe Abschnitt 3.2.2.1) und Logical Unit Number (LUN)- Masking (siehe Abschnitt 3.2.2.2), welche bereits in Einsteigermodellen zu n- den sind. Funktionen gröÿerer (und teurer) Disksubsysteme sind z.B. Thin Provisioning (siehe Abschnitt 3.2.2.3) und Remote Mirroring (siehe Abschnitt 3.2.2.4). (Vgl. Troppens et al., 2008, S. 44; Wurm und Nolte, 2011, S. 78.)

Die nachfolgend durchgeführte Betrachtung von Funktionen der Disksubsysteme möchte häu g genannte Funktionen beleuchten. Sie ist daher keine vollständige Auflistung aller in Disksubsystemen verfügbaren Funktionen.

3.2.2.1 Systeminterne Datenkopien

Datenkopien können innerhalb des Disksubsystems erstellt werden, sofern dieses die entsprechende Funktion bietet. Da die Kopien durch das Speichergerät erstellt werden, werden die Server entlastet.

Unterschieden werden zwei grundsätzliche Verfahren: Snapshots sind virtuelle Kopien, bei welchen fortlaufend die Veränderung der Kopie gegenüber dem Original (oder andersherum) gespeichert wird. Gibt es zwischen beiden Kopien keine Unterschiede, sind die Daten nur einmal auf den physikalischen Datenträgern gespeichert. Andernfalls belegt der Snapshot Speicherplatz in der Gröÿe der Änderungen. Den an das Disksubsystem angeschlossenen Systemen stehen transparent die beiden Kopien unabhängig voneinander zur Verfügung.

Dem gegenüber stehen Clones, welche Vollkopien der kopierten Daten sind. (Vgl. Döllinger et al., 2010, S. 103 bis 105.)

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung an: Döllinger et al., 2010, S. 105

Tabelle 1: Vergleich Verfahren zur Datenkopieerstellung

Anwendungsbeispiele (vgl. Döllinger et al., 2010, S. 106):

- Verlangt eine Anwendung zum Erstellen konsistenter Backups, in einen Backup- modus geschaltet zu werden, so kann dies kurzfristig während der Erstellung eines Snapshots geschehen. Anschlieÿend kann die Anwendung wieder in den produktiven Betrieb gehen, während ein externes Backup unter Nutzung des Snapshot erstellt wird.
- Für Tests von notwendigen Änderungen (z.B. Patches) an den Daten können Kopien erstellt werden. An diesen können die Tests durchgeführt werden, ohne die für den produktiven Betrieb benötigten Daten zu gefährden.

3.2.2.2 LUN-Masking

Die von einem Disksubsystem an einen Server zur Verfügung gestellten Festplatten werden LUN genannt. Hierbei handelt es sich entweder um physikalische oder mittels RAID virtuell zusammengefasste Platten.

Ohne LUN-Masking würde jeder Server alle Festplatten sehen, die von einem Disksubsystem zur Verfügung gestellt werden. Mit LUN-Masking stellt der Controller des Disksubsystems nur diejenigen Platten zur Verfügung, die jeweils für die Bereitstellung kon guriert wurden. (Vgl. Troppens et al., 2008, S. 54 bis 57.)

3.2.2.3 Thin Provisioning

Bei der Speicherzuweisung wählen Verantwortliche laut Wurm oftmals einen Mit- telweg zwischen Bedarf und Wachstum. Statistisch gesehen sind nur 25% der Res- sourcen tatsächlich ausgelastet.10 Storage habe hier keine Änderung gegenüber DAS gebracht.

Bei der Zuweisung von Speicher ohne Thin Provisioning wird der benötigte Speicherplatz einem Server fest zugewiesen ( Dedicate on Allocation ). Er steht anderen Servern nicht zur Verfügung. (Vgl. Wurm, 2011, S. 169.)

Mit Thin Provisioning wird den Servern virtuell eine groÿe LUN zugewiesen ( Sto- ragevirtualisierung , siehe auch Abschnitt 3.2.3 auf S. 11). Die Kapazität wird im Subsystem aber erst belegt, wenn Daten geschrieben werden ( Dedicate on Write ). Dadurch kann den Servern in Summe virtuell mehr Speicher zugewiesen werden, als physikalisch tatsächlich vorhanden ist. Da Thin Provisioning eine Funktion des Disksubsystems ist, ist es für den Server transparent. Aus seiner Sicht steht die zu- gewiesene LUN in voller Gröÿe zur Verfügung. (Vgl. Döllinger et al., 2010, S. 111 f.; Wurm, 2011, S. 169 f.) So kann eine bessere Auslastung der Kapazität erreicht wer- den.

Dieser Flexibilität stehen aber auch Nachteile gegenüber. Zwar wächst die physikalische Speicherbelegung mit der Belegung durch den Server sie sinkt jedoch nicht, wenn der Server Daten in seinem Speicherplatz löscht. Z.B. löscht ein WindowsServer in einem New Technology File System (NTFS) nur die Verweise auf die Blöcke, sie selbst aber nicht. Die Daten werden erst wieder überschrieben, wenn Windows der Platz ausgeht. Das Disksubsystem erkennt nur, dass ein Block belegt ist allerdings nicht, ob er noch genutzt wird. Disksubsystemhersteller bieten Software an, welche die Blöcke leert. Dies hat allerdings Folgen für Datenwiederherstellung und Snapshots im Serverbetriebssystem.

Zudem besteht die Gefahr, dass das Volume des Diskubsystems voll läuft, wenn die genutzte Kapazität die physikalische Grenze erreicht. Auch gibt es Applikationen z.B. Datenbanken die sofort den gesamten Speicherplatz belegen. (Vgl. Döllinger et al., 2010, S. 112 f; Wurm, 2011, S. 170.)

3.2.2.4 Hochverfügbarkeit

Während mittels der in Abschnitt 3.2.2.1 vorgestellten Datenkopien logischen Fehlern in Anwendungen inklusive der Serverbetriebssysteme vorgebeugt werden kann, können auch für den Ausfall ganzer Disksubsysteme Maÿnahmen getro en werden. Gründe für einen Ausfall können beispielsweise Stromausfall, Feuer, Wasser oder Fehler im Disksubsystem sein.

Abhilfe verscha t die Spiegelung ( Remote Mirroring ) der Daten eines Disksubsys- tems auf ein zweites, welches einem anderen Brandabschnitt und Stromkreis zugehörig sein sollte. Die Abwicklung erfolgt durch die beiden beteiligten Disksubsysteme.11 (Vgl. Troppens et al., 2008, S. 47 f. u. 219 f.) Typischerweise ist die Spiegelung aber nur hersteller-, teils sogar nur modellspezi sch möglich. (Vgl. Döllinger et al., 2010, S. 107.)

Es wird zwischen synchronem und asynchronem Remote Mirroring unterschieden. Synchrones Remote Mirroring schreibt die Daten auf beiden Disksubsystemen und bestätigt dies dem Server erst dann. Dadurch ist der Datenbestand immer gleich, jedoch steigt die Antwortzeit.

Bei asynchronem Remote Mirroring wird dem Server das Schreiben vom primären Disksubsystem schon bestätigt, wenn die Daten noch nicht zum sekundären System gelangt sind. Die Spiegelung wird erst anschlieÿend vorgenommen. Dadurch entsteht kein Performance-Verlust, für den Stand der Daten auf dem Sekundärsystem gibt es aber keine Garantie. (Vgl. Troppens et al., 2008, S. 48 bis 50.)

Sind am sekundären Disksubsystem Server angeschlossen und diese Bestandteil eines Clusters, kann an diesem Standort bei Ausfall des primären Disksubsystems (oder auch des primären Servers) der Betrieb mit dem Datenstand des Sekundärsystems fortgesetzt werden. (Vgl. Troppens et al., 2008, S. 218 f. u. 405.) Voraussetzung ist, dass die Anwendungen Cluster-aware sind.

Ein anderes Verfahren der Betriebsfortsetzung kann mit Servervirtualisierungssoft- ware wie beispielsweise VMware realisiert werden. Hier können virtuelle Serverbe- triebssysteme auf einem sekundären Virtualisierungshost wieder angefahren werden ( Fast Server Recovery ), wenn das primäre Disksubsystem oder der primäre Virtua- lisierungshost nicht mehr zur Verfügung stehen.12 (Vgl. Zimmer, 2010a, S. 124.)

3.2.3 Storagevirtualisierung

In kleineren Umgebungen wird der Einsatz von SAN nach Troppens et al. ausrei- chen, um der Daten Herr zu werden (Troppens et al., 2008, S. 165). In gröÿeren Umgebungen werden aber zusätzliche Hilfsmittel benötigt, um eine e ziente Ver- waltung der Daten realisieren zu können. (Vgl. Troppens et al., 2008, S. 165.) Storagevirtualisierung (nachfolgend auch Virtualisierung genannt) wird unterschied- lich ausgelegt und verstanden. (Vgl. Döllinger et al., 2010, S. 95.) Die Storage Net- working Industry Association (SNIA), eine Handelsvereinigung zur Förderung von Speicherstandards und -lösungen, hat den Begri virtualization de niert: Dem- nach ist Virtualisierung das Vorgehen, die internen Funktionen eines Storage- (Sub-) Systems oder Storagedienstes vor Anwendungen, Hosts oder Netzwerkressourcen zu abstrahieren, zu isolieren oder zu verstecken. Zweck ist dabei, anwendungs- und netz- werkunabhängige Verwaltung von Daten oder Storage zu ermöglichen. Des Weiteren ist damit der Einsatz von Virtualisierung auf Storagedienste oder -geräte mit dem Zweck, Funktionen oder Geräte zusammenzufassen, Komplexität zu verbergen oder low level -Ressourcen um Möglichkeiten zu erweitern, gemeint. (Vgl. Bunn et al., 2004, S. 3.)

Die Virtualisierung kann an den nachfolgend aufgeführten Orten durchgeführt wer- den.

[...]


1 SAN steht auch für System Area Network , wird aber in diesem Zusammenhang in dieser Arbeit nicht genutzt. (Vgl. Troppens et al., 2008, S. 504.)

2 In der Quelle wird das Wort Speichermanagement verwendet. Dies wird mit Storage Manage- ment gleich gesetzt. Ebensowenig wie eine genaue De nition existiert eine exakte Übersetzung. Jedoch wird z.B. der Begri hierarchisches Speichermanagement zu hierarchical storage ma- nagement (vgl. o. V., Paul Hemetsberger IT-Dienstleistungen (Hrsg.), o. S.) übersetzt. Dies wird von Pultorak et al. gestützt: Das Storage-Management (Speicher-Management) umfasst [...] (Pultorak et al., 2005, S. 52).

Diese Arbeit verwendet entsprechend dem Titel den Begri Storage Management, auch wenn in einer Quelle das (halb-)deutsche Wort Speichermanagement o.ä. verwendet wird.

3 Die in der ITIL beschriebene P ege von Daten kann in dieser Arbeit keine Berücksichtigung nden, da dies den Rahmen sprengen würde.

5 Hansen und Neumann ordnen auch NAS (siehe Abschnitt 3.1.2 auf S. 4) in die Speichernetze ein, sprechen aber von dem Anschluss an das reguläre LAN. (Vgl. Hansen und Neumann, 2005, S. 131.) Diese Einordnung geschieht wohl aufgrund des Umstandes, dass der Speicher im Netz(-werk) verfügbar gemacht wird. Das Werk von Robbe behandelt DAS (siehe Abschnitt 3.1.1 auf S. 4) in der Kategorie der Client/Server-Architektur. (Vgl. Robbe, 2004, S. 20 f.) NAS wird (zusammen mit Internet SCSI (iSCSI)) als LAN-basiertes Subsystem in die Speicherzentralisierung eingeordnet. (Vgl. Robbe, 2004, S. 25, 28 u. 30.) Ein SAN ist ein Hochgeschwindigkeitsnetzwerk zwischen Subsystemen und Servern. Es beendet durch den any to any -Ansatz das Besitzen und Handhaben von Speichersubsystemen durch Server. Ein SAN basiert nach Robbe (2004) auf Fibre Channel- Technologie. (Vgl. Robbe, 2004, S. 33 u. 36.) Robbe kategorisiert also anhand des Anschlusses von Speicher-Subsystemen [Anm.: in logischer und physikalischer Hinsicht]. (Vgl. Robbe, 2004, S. 19.)

6 Auf weitere Speichergeräte wie Bandbibliotheken wird hier aufgrund des begrenzten Umfanges nicht eingegangen.

7 Auf die Netzstrukturen wird in dieser Arbeit aufgrund des begrenzten Umfanges nicht eingegan- gen. Weiterführende Literatur ist z.B. Troppens et al., 2008; Robbe, 2004.

8 Anm.: Wird ein JBOD nicht an eine Instanz im Speichernetz, sondern direkt an einen Server angeschlossen, handelt es sich um DAS.

9 Für weitere Informationen zu den verschiedenen RAID-Level siehe z.B. Troppens et al., 2008,

S. 25 .; Wurm und Nolte, 2011, S. 78 f.

10 Nach Döllinger et al. 50-60%. (Vgl. Döllinger et al., 2010, S. 111.)

11 Es gibt auch gute Gründe dafür, dass nicht die Disksubsysteme selbst, sondern andere Instanzen die Spiegelung durchführen. Siehe Troppens et al., 2008, S. 220 bis 223.

12 Die Möglichkeiten für serverseitige Verfügbarkeit sind hier nur vereinfacht dargestellt. Weiter- führendes u.a. in Troppens et al., 2008, S. 403 . und Zimmer, 2010a, passim. 13 Adapterkarte, welche in einem Server verbaut wird. Beispiele sind SCSI-Controller, Fibre- Channel-Karten und iSCSI-Karten. (Vgl. Troppens et al., 2008, S. 493.)

Ende der Leseprobe aus 32 Seiten

Details

Titel
Storage Management in Unternehmen
Hochschule
FOM Hochschule für Oekonomie und Management gemeinnützige GmbH, Hochschulstudienzentrum Hamburg
Note
1,0
Autor
Jahr
2011
Seiten
32
Katalognummer
V231613
ISBN (eBook)
9783656477389
ISBN (Buch)
9783656478690
Dateigröße
1020 KB
Sprache
Deutsch
Schlagworte
Storage Management, Speicher, Storage-Systeme, Serverzentrierte Architektur, Direct Attached Storage, Network Attached Storage, Speicherzentrierte Architektur, Storage Area Network (SAN), Storage-Virtualisierung, SMI-S, Storage-Verwaltung, Tools, Element Manager, Storage Resource Manager (SRM)
Arbeit zitieren
Jakob Engelmartin (Autor), 2011, Storage Management in Unternehmen, München, GRIN Verlag, https://www.grin.com/document/231613

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Storage Management in Unternehmen


Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden