Speichernetze: Grundlagen, Architekturen, Datenmanagement

Von Ulf Troppens und Nils Haustein

In der Vergangenheit wurden Daten vor allem auf Festplatten und Magnetbändern gespeichert, die in den Speichernetzen der eigenen Rechenzentren betrieben wurden. Heute erstreckt sich die Speicherlandschaft von Unternehmen über die Grenzen von Rechenzentren hinaus in die Cloud und auf mobile Endgeräte.
Dieses Buch vermittelt einen umfassenden Einblick in Techniken und Architekturen für die Speicherung von Daten und stellt Anwendungen für das Datenmanagement vor. Dieses Wissen befähigt Sie, eigene Lösungen für die effiziente Speicherung und Verwaltung von Daten zu entwickeln und zu betreiben.
Dazu erklärt das Buch zunächst grundlegende Techniken für die Speicherung auf Disk- und Flashsystemen, Magnetbändern, Dateisystemen sowie Objektspeichern und erläutert wesentliche Übertragungstechniken wie Fibre Channel, iSCSI, InfiniBand und NVMe. Außerdem lernen Sie die neuen Techniken zur Verarbeitung von unstrukturierten Daten im Pervasive Computing und in der Cloud kennen. Die Autoren leiten daraus die jeweiligen Anforderungen an den Speicher ab und zeigen, wie beide Welten miteinander kombiniert werden können.
Der zweite Teil des Buchs beschreibt den Einsatz dieser Techniken und wie sie helfen, Ausfallsicherheit, Anpassbarkeit und Erweiterbarkeit von Speichernetzen und Anwendungen zu gewährleisten. Weitere Schwerpunkte bilden Anwendungen für das Datenmanagement wie die Datensicherung, die digitale Archivierung und die Verwaltung von Speichernetzen.
Die 3. Auflage wurde komplett überarbeitet. Das Buch wurde um einige Kapitel erweitert und bestehende Kapitel aktualisiert, um den vielen neuen Entwicklungen der Speicherwelt Rechnung zu tragen.

• Sprache: Deutsch
• Herausgeber: dpunkt.verlag
• Erscheinungsdatum: 22. März 2019
• ISBN: 9783960887164

Buchvorschau

Inhaltsübersicht

1Einleitung

Ulf Troppens · Nils Haustein

Teil ITechniken für Speichernetze

2Disk- und Flashsysteme

Peter Kimmel · Ulf Troppens

3I/O-Techniken

Sebastian Thaele · Achim Christ · Ulf Troppens

4Dateisysteme und Network Attached Storage (NAS)

Achim Christ · Ulf Troppens · Nils Haustein

5Speichervirtualisierung

Nils Haustein · Ulf Troppens

6Objektspeicher

Jens-Peter Akelbein · Ulf Troppens

7Wechselmedien

Nils Haustein · Ulf Troppens

Teil IIEinsatz von Speichernetzen

8Basisarchitekturen

Ulf Troppens · Nils Haustein

9Pervasive Computing und Cloud

Ulf Troppens · Dennis Zimmer

10Datensicherung

Andre Gaschler · Nils Haustein · Ulf Troppens

11Archivierung

Nils Haustein · Ulf Troppens

12Business Continuity

Nils Haustein · Ulf Troppens

13Verwaltung von Speichernetzen

Dietmar Noll · Ulf Troppens

14Verwaltung von Wechselmedien

Nils Haustein · Ulf Troppens

15Schlussbemerkung

Ulf Troppens · Nils Haustein

Anhang

AAbbildungs- und Tabellenverzeichnis

BGlossar

CLiteratur- und Quellenverzeichnis

DBerechnung des Paritätsblocks von RAID 4 und 5

ECheckliste für die Verwaltung von Speichernetzen

Index

Inhaltsverzeichnis

1Einleitung

1.1Speicherhierarchie

1.2Die serverzentrierte IT-Architektur und ihre Beschränkungen

1.3Die speicherzentrierte IT-Architektur und ihre Vorteile

1.4Beispiel: Austausch eines Servers mit Speichernetzen

1.5Von verteilten Systemen zu Pervasive Computing und Cloud

1.6Gliederung des Buchs

Teil ITechniken für Speichernetze

2Disk- und Flashsysteme

2.1Grundlagen

2.1.1Architektur von Disk- und Flashsystemen

2.1.2Abgrenzung: Disksystem versus Flashsystem

2.1.3Laufwerke: Flashmodule, SSDs und Festplatten

2.1.4Interne I/O-Kanäle

2.1.5Just a Bunch of Disks (JBOD)

2.1.6Speichervirtualisierung durch RAID

2.2Verschiedene RAID-Level im Detail

2.2.1RAID 0: Blockweises Striping

2.2.2RAID 1: Blockweises Mirroring

2.2.3RAID 0+1/RAID 10: Striping und Mirroring kombiniert

2.2.4RAID 4 und RAID 5: Parity statt Mirroring

2.2.5RAID 6: Double Parity

2.2.6RAID 2 und RAID 3

2.2.7Die RAID-Level im Vergleich

2.2.8Distributed RAID

2.3Caching: Beschleunigung der Laufwerkszugriffe

2.3.1Caches in Festplatten und SSDs

2.3.2Schreib-Cache im Controller des Disksystems

2.3.3Lese-Cache im Controller des Disksystems

2.4Intelligente Disksysteme

2.4.1Instant Copies

2.4.2Remote Mirroring

2.4.3Konsistenzgruppen

2.4.4LUN Masking

2.5Speicheroptimierung

2.5.1Thin Provisioning

2.5.2Deduplizierung und Komprimierung

2.5.3Automatische Speicherortverlagerung

2.6Verfügbarkeit von Disksystemen

2.7Zusammenfassung und Ausblick

3I/O-Techniken

3.1Grundlagen

3.1.1Der physische I/O-Pfad von der CPU zum Speichergerät

3.1.2Small Computer System Interface (SCSI)

3.2Fibre Channel (FC)

3.2.1Links, Ports und Topologien

3.2.2FC-0: Kabel, Stecker und Signalcodierung

3.2.3FC-1: Codierungen, Ordered Set und Link Control Protocol

3.2.4FC-2: Datenübertragung

3.2.5FC-3: Gemeinsame Dienste

3.2.6Link Services: Login und Adressierung

3.2.7Fabric Services: Name Server und Co.

3.2.8FC-4 und ULPs: Anwendungsprotokolle

3.3Fibre Channel SAN

3.3.1Eignung für Speichernetze

3.3.2Begriffsbestimmung: SAN versus Speichernetz

3.3.3Die Point-to-Point-Topologie

3.3.4Die Fabric-Topologie

3.3.5Die Arbitrated-Loop-Topologie

3.3.6Hardwarekomponenten für Fibre Channel SAN

3.3.7Interoperabilität von Fibre Channel SAN

3.3.8Leistungsbetrachtungen

3.4WAN-Techniken

3.4.1Dark Fiber

3.4.2Multiplexer: DWDM, CWDM und TDM

3.4.3Fibre Channel over IP (FCIP)

3.4.4Fazit

3.5IP Storage

3.5.1TCP/IP und Ethernet als I/O-Technik

3.5.2Internet SCSI (iSCSI)

3.5.3Fibre Channel over Ethernet (FCoE)

3.6Weitere I/O-Techniken

3.6.1InfiniBand

3.6.2Virtual Interface Architecture (VIA)

3.6.3RDMA, RoCE & Co

3.6.4NVM Express (NVMe) und NVMe over Fabric (NVMeOF)

3.7Zusammenfassung und Ausblick

4Dateisysteme und Network Attached Storage (NAS)

4.1Lokale Dateisysteme

4.1.1Lokale und verteilte Dateisysteme

4.1.2Journaling

4.1.3Snapshots

4.1.4Volume Manager

4.1.5Information Lifecycle Management (ILM)

4.1.6Dateisysteme und Datenbanken

4.2Netzwerk-Dateisysteme und Fileserver

4.2.1Grundprinzip

4.2.2Network Attached Storage (NAS)

4.2.3Alternativen zu Netzwerk-Dateisystemen

4.3Authentisierung und Autorisierung

4.3.1Identifizierung

4.3.2Authentisierung

4.3.3Verzeichnisdienste

4.3.4Autorisierung und Zugriffskontrolle

4.4Optimierung für verteilte Zugriffe

4.4.1Leistungsengpässe in Fileservern

4.4.2Beschleunigung von Netzwerk-Dateisystemen

4.4.3Fallstudie: Direct Access File System (DAFS)

4.4.4Shared-Disk-Dateisysteme

4.4.5Fallstudie: General Parallel File System (GFPS)

4.4.6Shared-Nothing-Dateisysteme

4.4.7Fallstudie: Hadoop Distributed File System (HDFS)

4.5Vergleich: NAS und SAN

4.6Zusammenfassung und Ausblick

5Speichervirtualisierung

5.1Grundlagen

5.1.1Definition: Speichervirtualisierung

5.1.2Ziele der Speichervirtualisierung

5.1.3Realisierungsorte der Virtualisierungsinstanz

5.1.4Speichervirtualisierung auf Blockebene

5.1.5Speichervirtualisierung auf Dateiebene

5.1.6Vergleich: Blockebene versus Dateiebene

5.2Speichervirtualisierung im Speichernetz

5.2.1Architekturbedingte Einschränkungen von Speichernetzen

5.2.2Implementierungsbedingte Einschränkungen von Speichernetzen

5.2.3Notwendigkeit einer Speichervirtualisierung im Speichernetz

5.2.4Beispiel: Austausch von Speichergeräten mit Speichervirtualisierung im Speichernetz

5.2.5Symmetrische Speichervirtualisierung

5.2.6Asymmetrische Speichervirtualisierung

5.3Vergleich der Realisierungsorte

5.3.1Speichervirtualisierung im I/O-Pfad

5.3.2Speichervirtualisierung im Server

5.3.3Speichervirtualisierung im Speichergerät

5.3.4Speichervirtualisierung im Speichernetz

5.3.5Mehrstufige Speichervirtualisierung

5.4Implementierungsaspekte

5.4.1Erleichterung der Speicherverwaltung

5.4.2Höhere Verfügbarkeit der Daten

5.4.3Höhere Leistungsfähigkeit des Speichers

5.4.4Bessere Ausnutzung aller Speicherressourcen

5.5Zusammenfassung und Ausblick

6Objektspeicher

6.1Begriffsbestimmung

6.1.1Motivation: Speicher für nicht-strukturierte, statische Daten

6.1.2Referenzarchitektur für Objektspeicher

6.1.3Abgrenzung zu Dateien und Dateisystemen

6.1.4Abgrenzung zu anderen objektbasierten Speichern

6.1.5Abgrenzung zu Cloud Storage

6.2Anforderungen an Objektspeicher

6.2.1Speicher für Webanwendungen und Pervasive Computing

6.2.2Hardware-bezogene Anforderungen

6.2.3CAP-Theorem als Architekturtreiber

6.2.4Operative Anforderungen

6.3Zugriff auf Objekte

6.3.1Webtechniken

6.3.2Representational State Transfer (REST)

6.3.3Objektspeicherschnittstelle

6.3.4Fallstudie: Cloud Data Management Interface (CDMI)

6.3.5Vergleich von CDMI mit anderen API-Varianten

6.4Speichern der Objekte

6.4.1Systemsoftware des Objektspeichers

6.4.2Redundanz der Objekte

6.4.3Redundanz von Hardwarekomponenten

6.4.4Zonen und Regionen

6.4.5Fallstudie: OpenStack Swift

6.5Erweiterte Funktionen

6.5.1Suche

6.5.2Logging

6.5.3Darstellung als Netzwerkdateisystem

6.6Zusammenfassung und Ausblick

7Wechselmedien

7.1Motivation: Vorteile von Bändern

7.2Medientypen

7.2.1Bänder (Tapes)

7.2.2Optische Medien

7.2.3Tape Libraries

7.2.4Bandlaufwerke (Drives)

7.2.5Media Changer und Inventarverzeichnis

7.2.6Partitionierung von Tape Libraries

7.3Das Linear Tape File System (LTFS)

7.3.1Motivation

7.3.2Architektur

7.3.3Operationen

7.3.4Charakteristische Eigenschaften

7.3.5Nutzungsaspekte

7.3.6Hierarchische Speicherverwaltung mit LTFS

7.3.7Fazit

7.4Einsatzgebiete

7.4.1Einsatz zur Datensicherung

7.4.2Einsatz zur Archivierung

7.4.3Einsatz für den Austausch großer Datenmengen

7.5Zusammenfassung

Teil IIEinsatz von Speichernetzen

8Basisarchitekturen

8.1Begriffsbestimmung »Speichernetz«

8.1.1Schichtung der Übertragungstechniken und Protokolle

8.1.2Speichernetze im I/O-Pfad

8.1.3Abgrenzung: Rechnernetze versus Speichernetze

8.2Basiskonzepte

8.2.1Konsolidierung von Disksystemen

8.2.2Konsolidierung von Tape Libraries

8.2.3Data Sharing

8.2.4Datenkopien

8.2.5Hierarchical Storage Management (HSM)

8.3Verfügbarkeit

8.3.1Ausfall eines I/O-Busses

8.3.2Ausfall eines Servers

8.3.3Ausfall eines Speichersystems

8.3.4Ausfall einer Virtualisierung im Speichernetz

8.3.5Ausfall eines Rechenzentrums am Beispiel »Schutz eines wichtigen Datenbanksystems«

8.3.6Ausfall eines Storage-rich Servers

8.4Anpassbarkeit und Skalierbarkeit

8.4.1Begriffsbestimmung: »Cluster«

8.4.2Shared-Null-Konfiguration

8.4.3Shared-Nothing Cluster

8.4.4Enhanced Shared-Nothing Cluster

8.4.5Shared-Everything Cluster

8.4.6Cluster mit Storage-rich Servern

8.5Zusammenfassung und Ausblick

9Pervasive Computing und Cloud

9.1Pervasive Computing

9.1.1Definition: »Pervasive Computing«

9.1.2Dezentrale Erzeugung, Verarbeitung und Speicherung von unstrukturierten Daten

9.1.3Höheres Datenvolumen

9.1.4Höhere Skalierbarkeit

9.1.5Höhere Anpassbarkeit

9.1.6Geringere Veränderungsrate

9.1.7Verfügbarkeit wichtiger als Konsistenz

9.1.8Höhere Fehlertoleranz

9.1.9Geringere Belastung durch Partitionierung

9.1.10Lose gekoppelte Replikate

9.1.11Fazit

9.2Cloud Computing

9.2.1Definition »Cloud Computing«

9.2.2Charakteristische Eigenschaften

9.2.3Dienstmodelle: IaaS, PaaS, SaaS

9.2.4Bereitstellungsmodelle: Public, Privat, Hybrid

9.2.5Fallbeispiel: OpenStack

9.2.6Abgrenzung zu Webanwendung

9.2.7Abgrenzung zu Virtualisierung

9.2.8Cloud Computing in Unternehmen

9.3Servervirtualisierung

9.3.1Grundlagen und Definition

9.3.2Vorteile von Servervirtualisierung

9.3.3Speicher für Servervirtualisierung

9.3.4Problem: Hypervisor im I/O Pfad

9.3.5Fallstudie: Speicher für VMware ESXi

9.3.6Hyperconverged Systems

9.3.7Container

9.4Speicher in, aus und für die Cloud

9.4.1Speicher in und aus der Cloud

9.4.2Enterprise File Sync&Share (EFSS)

9.4.3Big Data

9.4.4Speicher für Cloud und Pervasive Computing

9.5Zusammenfassung und Ausblick

10Datensicherung

10.1Rahmenbedingungen

10.1.1Begriffsbestimmung

10.1.2Herausforderungen

10.1.3Anforderungen

10.1.4Abgrenzung

10.2Referenzarchitektur für Backup-Systeme

10.2.1Komponenten und Prozesse

10.2.2Backup-Server

10.2.3Backup-Client

10.2.4Verwaltung

10.3Konzepte und Techniken

10.3.1Backup-Verfahren

10.3.2Kenngrößen

10.3.3Backup-Strategien

10.3.4Backup-Profile

10.3.5Datenreduktion

10.3.6Speicherhierarchien im Backup-Speicher

10.3.7Sicherung und Auslagerung der Backup-Daten

10.3.8Verschlüsselung

10.4Erweiterung der Referenzarchitektur

10.4.1Index-Server und Medien-Server

10.4.2Server-free Backup

10.4.3LAN-free Backup

10.4.4Datensicherung mit Instant Copies

10.5Cloud-Backup

10.5.1Grundlagen

10.5.2Backup-Systeme mit Cloud-Speicher

10.5.3Backup-as-a-Service

10.5.4Disaster-Recovery-as-a-Service für Backup-Systeme

10.5.5Backup-Systeme für Off Premise Private Clouds

10.5.6Fazit

10.6Sicherung von Dateisystemen

10.6.1Grundlagen

10.6.2Identifizierung der zu sichernden Daten

10.6.3Lösungen für die Sicherung von Dateisystemen

10.6.4Sicherung von Fileservern

10.7Sicherung von NAS-Systemen

10.7.1Sicherung von NAS-Systemen über NFS oder SMB

10.7.2Das Network Data Management Protocol (NDMP)

10.7.3Integration von NDMP in Backup-Systeme

10.8Sicherung von Datenbanksystemen

10.8.1Grundlagen Datenbanksysteme

10.8.2Wiederanlauf und Recovery

10.8.3Backup-Verfahren für Datenbanksysteme

10.8.4Vollständige Sicherung der Datenbasis

10.8.5Differenzielle Sicherung der Datenbasis

10.8.6Sicherung der Datenbasis mit Instant Copies

10.9Sicherung von Servern

10.9.1Sicherung von physischen Servern

10.9.2Besonderheiten der Sicherung virtueller Server

10.9.3Sicherung im virtuellen Server

10.9.4Sicherung über den Hypervisor

10.9.5Anwendungskonsistente Sicherung von virtuellen Servern

10.10Organisatorische Aspekte der Datensicherung

10.11Zusammenfassung und Ausblick

11Archivierung

11.1Begriffsbestimmung

11.1.1Abgrenzung: Informationen versus Daten

11.1.2Archivierung

11.1.3Digitale Archivierung

11.1.4Referenzarchitektur für digitale Archivsysteme

11.1.5Der Archivierungsprozess

11.1.6Abgrenzung: Archivierung versus Datensicherung

11.1.7Abgrenzung: Archivierung versus ILM

11.2Grundlagen

11.2.1Gründe für die Archivierung

11.2.2Gesetzliche Anforderungen

11.2.3Technischer Fortschritt

11.2.4Beständigkeit

11.2.5Risiken aus Umwelt und Gesellschaft

11.2.6Anpassbarkeit und Skalierbarkeit

11.2.7Operative Anforderungen

11.2.8Kostenbezogene Anforderungen

11.2.9Fazit: Archivsysteme als strategische Investition

11.3Speichermedien für die Archivierung

11.3.1Motivation

11.3.2Diskbasierter WORM-Speicher

11.3.3Optische WORM-Medien

11.3.4WORM-Bänder

11.3.5Vergleich und Einsatzgebiete der WORM-Techniken

11.4Implementierungsüberlegungen

11.4.1Datensicherheit

11.4.2Datenintegrität

11.4.3Nachweis der Revisionssicherheit

11.4.4Löschen von Daten

11.4.5Unterbrechungsfreier Betrieb

11.4.6Verlustfreier Betrieb

11.4.7Datensteuerung: Speicherhierarchie und Migration

11.4.8Komponentenneutrale Archivierung

11.4.9Auswahl von Komponenten und Herstellern

11.5Schnittstellen im Archivsystem

11.5.1Referenzarchitektur mit Schnittstellen

11.5.2Schnittstelle zwischen Anwendung und DMS

11.5.3Fallstudie: Java Content Repository (JCR)

11.5.4Schnittstelle zwischen DMS und Archivspeicher

11.5.5Fallstudie: eXtensible Access Method (XAM)

11.5.6Verwaltungsschnittstellen

11.5.7Schnittstelle zwischen DMS-Systemen

11.5.8Fallstudie: Content Management Interoperability Services (CMIS)

11.5.9Referenzarchitektur mit standardisierten Schnittstellen

11.6Archivlösungen

11.6.1Archivierung von E-Mails

11.6.2Archivierung von Dateien

11.6.3Archivierung von ERP-Systemen

11.6.4Archivierung in Krankenhäusern

11.6.5Zentrales Archiv

11.7Langzeitarchivierung

11.7.1Spezielle Herausforderungen

11.7.2Prozesse bei der Langzeitarchivierung

11.7.3Das OAIS-Referenzmodell zur Langzeitarchivierung

11.7.4Implementierung eines Langzeitarchivs

11.8Operative und organisatorische Aspekte

11.9Zusammenfassung und Ausblick

12Business Continuity

12.1Grundlagen

12.1.1Motivation: Betrifft Unternehmen aller Größen

12.1.2Begriffsbestimmungen

12.1.3Klassifikation von Ausfällen

12.1.4Auswirkung von IT-Ausfällen

12.1.5Wiederanlauf von Geschäftsprozessen

12.1.6Kostenoptimierung für Business Continuity

12.1.7Risikomanagement im Kontext der Business Continuity

12.1.8Beschreibung der Anforderungen

12.2Business-Continuity-Ziele

12.2.1Ziele der Business Continuity

12.2.2Hochverfügbarkeit (High Availability)

12.2.3Desasterschutz (Disaster Recovery)

12.2.4Kontinuierlicher Geschäftsbetrieb (Continuous Operation)

12.2.5Hochverfügbarkeit versus Desasterschutz

12.3Kenngrößen der Business Continuity

12.3.1Verfügbarkeit

12.3.2Charakterisierung der Verfügbarkeit

12.3.3Berechnung von Gesamtverfügbarkeiten

12.3.4Recovery Time Objective (RTO)

12.3.5Recovery Point Objective (RPO)

12.3.6Network Recovery Objective (NRO)

12.3.7Noch einmal: Hochverfügbarkeit versus Desasterschutz

12.3.8Service Level Agreements (SLAs)

12.4Business-Continuity-Lösungen

12.4.1Basistechniken

12.4.2Das Sieben-Stufen-Modell

12.4.3Lösungssegmente des Sieben-Stufen-Modells

12.4.4Datensicherung

12.4.5Schnelle Datenwiederherstellung mit Kopien

12.4.6Schnelle Datenwiederherstellung mit Spiegeln

12.4.7Kontinuierliche Verfügbarkeit

12.4.8Drei Standorte zum Schutz vor weiträumigen Katastrophen

12.5Business-Continuity-Plan

12.5.1Erstellen eines Business-Continuity-Plans

12.5.2Operativer Standortwechsel

12.5.3Organisatorische Aspekte

12.6Zusammenfassung und Ausblick

13Verwaltung von Speichernetzen

13.1Anforderungen

13.1.1Benutzerbezogene Anforderungen

13.1.2Komponentenbezogene Anforderungen

13.1.3Architekturbezogene Anforderungen

13.1.4Ein zentrales Verwaltungswerkzeug

13.1.5Fünf Basisdienste

13.1.6Unterstützung agiler Geschäftsumfelder

13.1.7Datenprofile

13.2Charakterisierung von Verwaltungsschnittstellen

13.2.1In-Band-Schnittstellen

13.2.2Out-Band-Schnittstellen

13.2.3Standardisierte Schnittstellen

13.2.4Proprietäre Schnittstellen

13.2.5Fazit

13.3In-Band- und Out-Band-Management

13.3.1Grundlagen In-Band-Management

13.3.2In-Band-Management im Fibre Channel SAN

13.3.3Grundlagen Out-Band-Management

13.3.4Das Simple Network Management Protocol (SNMP)

13.3.5CIM und WBEM

13.3.6Storage Management Initiative Specification (SMI-S)

13.3.7Redfish und Swordfish

13.3.8Vergleich In-Band-Management versus Out-Band-Management

13.4Zusammenfassung und Ausblick

14Verwaltung von Wechselmedien

14.1Grundlagen

14.1.1Merkmale von Wechselmedien

14.1.2Notwendigkeit einer Wechselmedienverwaltung

14.1.3Basisdienste einer Wechselmedienverwaltung

14.1.4Zentrale Wechselmedienverwaltung

14.2Anforderungen an eine Wechselmedienverwaltung

14.2.1Effiziente Nutzung der Ressourcen

14.2.2Zugriffskontrolle

14.2.3Zugriffssynchronisation

14.2.4Priorisierung der Mount Requests und Warteschlangen

14.2.5Gruppierung von Medien und Laufwerken

14.2.6Media Tracking und Vaulting

14.2.7Cartridge Lifecycle Management

14.2.8Monitoring

14.2.9Reporting

14.3IEEE 1244 Standard for Removable Media Management

14.3.1Entstehung und Entwurfsziele

14.3.2Architektur des Media-Management-Systems

14.3.3Media Manager und MMP

14.3.4Library Manager und Drive Manager

14.4Zusammenfassung

15Schlussbemerkung

Anhang

AAbbildungs- und Tabellenverzeichnis

BGlossar

CLiteratur- und Quellenverzeichnis

DBerechnung des Paritätsblocks von RAID 4 und 5

ECheckliste für die Verwaltung von Speichernetzen

E.1Anwendungen

E.1.1Überwachung

E.1.2Verfügbarkeit

E.1.3Leistung

E.1.4Skalierbarkeit

E.1.5Effiziente Nutzung

E.2Daten

E.2.1Verfügbarkeit

E.2.2Leistung

E.2.3Datensicherung

E.2.4Archivierung

E.2.5Migration

E.2.6Gemeinsame Datennutzung

E.2.7Sicherheit/Zugriffskontrolle

E.3Ressourcen

E.3.1Inventur/Asset Management und Planung

E.3.2Überwachung

E.3.3Konfiguration

E.3.4Ressourcennutzung

E.3.5Kapazität

E.3.6Effiziente Ressourcennutzung

E.3.7Verfügbarkeit

E.3.8Ressourcenmigration

E.3.9Sicherheit

E.4Netz

E.4.1Topologie

E.4.2Überwachung

E.4.3Verfügbarkeit

E.4.4Leistung

Index

1Einleitung

Ulf Troppens · Nils Haustein

Ziel und Gliederung des Kapitels

In diesem Kapitel wollen wir die Grundidee des vorliegenden Buchs vermitteln. Dazu erläutern wir zunächst die Speicherhierarchie vom Prozessor über den Hauptspeicher zu Solid-State-Disks (SSDs), Festplatten und Bändern (Abschnitt 1.1). Danach stellen wir die beiden Speicherarchitekturen vor, die sich über Jahrzehnte bewährt haben: Wir erklären die serverzentrierte IT-Architektur und zeigen an einem Beispiel deren Nachteile (Abschnitt 1.2). Im Anschluss beschreiben wir als Alternative die speicherzentrierte IT-Architektur (Abschnitt 1.3) und erklären ihre Vorteile am Beispiel »Austausch eines Anwendungsservers« (Abschnitt 1.4). Dann beleuchten wir den Paradigmenwechsel von verteilten Systemen zu Pervasive Computing und Cloud Computing und die damit verbundenen neuen Anforderungen an die Verarbeitung und Speicherung von Daten (Abschnitt 1.5). Abschließend stellen wir die Gliederung des gesamten Buchs vor und benennen, welche Themen wir nicht behandeln (Abschnitt 1.6).

1.1Speicherhierarchie

Flüchtiger Speicher

Seit Jahrzehnten ist die Architektur von Rechnern (Servern), Betriebssystemen und Anwendungen von einer Speicherhierarchie geprägt (Abb. 1–1). In und nahe an den Prozessoren (Central Processing Units, CPUs) findet sich schneller, flüchtiger Speicher wie Prozessorregister, Prozessor-Cache und Hauptspeicher (Random Access Memory, RAM). Flüchtig heißt, der Speicher verliert die gespeicherten Daten, wenn er nicht mehr mit Strom versorgt wird, wie bereits bei einer kurzen Stromunterbrechung.

Abb. 1–1Speicherhierarchie

Die Architektur von Servern, Betriebssystemen und Anwendungen ist von einer Speicherhierarchie geprägt.

Persistenter Speicher

Deswegen wird flüchtiger Speicher immer mit persistentem Speicher wie Solid-State-Disks (SSDs), Festplatten und Bändern kombiniert, der weiter von den Prozessoren entfernt ist. Persistent heißt, der Speicher behält die gespeicherten Daten auch dann, wenn er lange nicht mit Strom versorgt wird.

Zusammenspiel von flüchtigem und persistentem Speicher

Programmcode von Betriebssystem und Anwendungen und die eigentlichen Daten werden deswegen zunächst auf persistentem Speicher abgelegt. Betriebssystem und Anwendungen kopieren den Programmcode und die Daten vom persistenten Speicher in den flüchtigen, um dort den Code auszuführen und die Daten zu verarbeiten. Neue und veränderte Daten werden wiederum auf den persistenten Speicher geschrieben, um diese langfristig zu speichern.

Speicherhierarchie

Aus dem Zusammenspiel von flüchtigem und persistentem Speicher ergibt sich eine Speicherhierarchie. Es gilt, dass Speicher umso schneller und umso teurer ist, je dichter er am Prozessor ist. Deswegen sind Server in der Regel mit erheblich mehr persistentem Speicher ausgestattet als mit flüchtigem und es werden nur die Programmcodes und die Daten in flüchtigen Speicher kopiert, die man gerade benötigt. Alle anderen Programme und Daten verbleiben im persistenten Speicher.

Pervasive Computing

Die über Jahrzehnte bewährte Speicherhierarchie wird derzeit an zwei Stellen aufgebrochen. In der Vergangenheit wurden Daten überwiegend zentral auf einem oder wenigen Servern verarbeitet. Mit dem Einzug von Internet, Smartphones und Internet of Things (IoT) werden immer mehr Daten auf dezentralen, mobilen Geräten erzeugt, verarbeitet und gespeichert. Diese dezentralen Daten werden immer mehr mit zentral gespeicherten Daten verknüpft, sodass geschäftskritische Daten nun auch außerhalb der etablierten Speicherhierarchie verarbeitet werden. Diese neue Form der dezentralen Datenerzeugung, Datenverarbeitung und Datenspeicherung wird auch als Pervasive Computing bezeichnet.

Non-Volatile Memory (NVM)

Zum anderen ist es mit der Entwicklung von persistentem Hauptspeicher (Non-Volatile Memory, NVM) möglich, in einem Server persistenten Speicher nahe am Prozessor zu integrieren, sodass dieser darauf auf die gleiche Art und Weise zugreifen kann wie auf Hauptspeicher. Es sind erhebliche Änderungen an der Architektur der über Jahrzehnte gewachsenen Programme und Betriebssysteme notwendig, um daraus vollen Nutzen zu schöpfen. Diese Technologie steht heute (2018) erst noch am Anfang. Es deutet sich aber an, dass NVM die Architektur von Anwendungen und Betriebssystemen verändern wird.

Weitere Vorgehensweise

Im weiteren Verlauf dieses Kapitels werden wir uns zunächst mit Architekturen für herkömmliche verteilte Systeme beschäftigen (Abschnitte 1.2 bis 1.4) und dann mit dem Pervasive Computing auf die neue dezentrale Speicherung und Verarbeitung von Daten eingehen (Abschnitt 1.5). Techniken für die Einbindung von persistenten Hauptspeicher beschreiben wir später (Abschnitt 3.6.4).

1.2Die serverzentrierte IT-Architektur und ihre Beschränkungen

Serverzentrierte IT-Architektur

Die serverzentrierte IT-Architektur war bis etwa zum Jahr 2000 die vorherrschende Architektur für verteilte Systeme. In serverzentrierten IT-Architekturen werden Speichergeräte in der Regel nur an einen einzelnen Server angeschlossen (Abb. 1–2). Zur Erhöhung der Verfügbarkeit werden Speichergeräte manchmal auch mit zwei Servern verbunden (Twin-tailed Cabling), wobei zu einem Zeitpunkt aber immer nur ein Server das Speichergerät wirklich nutzen kann. In beiden Fällen existiert Speicher immer nur in Abhängigkeit von den Servern, an die er angeschlossen ist. Andere Server können nicht direkt auf die Daten zugreifen; sie müssen immer über den Server gehen, an dem der Speicher angeschlossen ist.

Abb. 1–2Serverzentrierte IT-Architektur

In der serverzentrierten IT-Architektur existiert Speicher nur in Abhängigkeit von Servern.

Mangelnde Verfügbarkeit der Daten

Wie bereits erwähnt existiert in herkömmlichen serverzentrierten IT-Architekturen Speicher immer nur in Abhängigkeit von den ein bis zwei Servern, an die er angeschlossen ist. Fallen diese beiden Server aus, so kann nicht mehr auf die Daten zugegriffen werden, wenn es keine weiteren Kopien gibt. Dies ist für viele Anwendungen nicht mehr akzeptabel: Zumindest ein Teil der Unternehmensdaten (zum Beispiel Patientendaten, Webseiten) muss rund um die Uhr verfügbar sein.

Unflexibel: Zuweisung freier Speicherkapazität

In serverzentrierten IT-Architekturen ist Speicher den Servern statisch zugeordnet, an die er angeschlossen wird. Klassische Anwendungen können nicht auf Speicher zugreifen, der mit anderen Servern verbunden ist. Wenn also ein Datenbanksystem mehr Speicher benötigt, als an einem Server angeschlossen ist, so nützt es überhaupt nichts, dass an anderen Servern noch Speicher vorhanden ist, der gerade nicht benötigt wird (Abb. 1–3).

Abb. 1–3Unflexible Zuweisung freier Speicherkapazität

Auf Server 2 ist die Speicherkapazität erschöpft. Anwendungen können nicht davon profitieren, dass an den Servern 1 und 3 noch Speicher frei ist.

1.3Die speicherzentrierte IT-Architektur und ihre Vorteile

Speichernetze

Speichernetze lösen die soeben geschilderten Einschränkungen der serverzentrierten IT-Architektur. Darüber hinaus bieten Speichernetze neue Möglichkeiten, Daten zu verwalten. Die Idee von Speichernetzen ist, die Kabel zwischen Server und Speicher durch ein Netz zu ersetzen, das zusätzlich zu dem bereits existierenden Rechnernetz (LAN) installiert und überwiegend für den Datenaustausch zwischen Servern und Speichergeräten genutzt wird (Abb. 1–4).

Speicherzentrierte IT-Architektur

Im Gegensatz zur serverzentrierten IT-Architektur existiert Speicher in Speichernetzen völlig unabhängig von irgendwelchen Servern. Über das Speichernetz können mehrere Server direkt auf dasselbe Speichergerät zugreifen, ohne dass dabei zwangsläufig ein anderer Server involviert ist. Speichergeräte rücken damit in das Zentrum der IT-Architektur; Server hingegen werden zum Anhängsel an die Speichergeräte, die »gerade mal noch Daten verarbeiten dürfen«. IT-Architekturen mit Speichernetzen werden deshalb auch als speicherzentrierte IT-Architekturen bezeichnet.

Abb. 1–4Speicherzentrierte IT-Architektur

In der speicherzentrierten IT-Architektur werden die Kabel durch ein Netz ersetzt. Speichergeräte existieren nun unabhängig von einem Server.

Speicherkonsolidierung

Mit der Einführung eines Speichernetzes wird meistens auch der Speicher konsolidiert. Dabei werden die vielen kleinen, an die Server angehängten Festplatten durch wenige große Disksysteme ersetzt. Disksysteme haben heutzutage (im Jahr 2018) eine maximale Speicherkapazität von bis zu mehreren Petabytes und statt Festplatten wird zunehmend Flashspeicher eingesetzt. Über das Speichernetz können alle Server auf das Disk- oder Flashsystem zugreifen und es so gemeinsam nutzen. Freie Speicherkapazität kann auf diese Weise demjenigen Server flexibel zugewiesen werden, der sie gerade benötigt. Auf die gleiche Art und Weise können auch andere Arten von Speichergeräten konsolidiert werden, wie zum Beispiel viele kleine Tape Libraries durch eine große.

Einsatz von Speichernetzen

Speichernetze werden seit etwa dem Jahr 2000 von Unternehmen aller Größen für verteilte Systeme eingesetzt. Für die Speicherung und Verarbeitung strukturierter Daten (zum Beispiel Kontobuchungen) ist es wichtig, dass diese immer konsistent sind. Eine speicherzentrierte Architektur unterstützt die Hochverfügbarkeit konsistenter Daten.

1.4Beispiel: Austausch eines Servers mit Speichernetzen

Beispiel: Server-Upgrade

Im Folgenden verdeutlichen wir einige Vorteile der speicherzentrierten IT-Architektur anhand eines Beispiels: In einer Produktionsumgebung ist ein Anwendungsserver nicht mehr leistungsfähig genug. Der altersschwache Server muss durch ein leistungsfähigeres Gerät ersetzt werden. Während eine solche Maßnahme in einer herkömmlichen, serverzentrierten IT-Architektur sehr kompliziert sein kann, lässt sich dies mit einem Speichernetz elegant durchführen.

Vor dem Upgrade

Vor dem Austausch ist der alte Server über das Speichernetz mit einem Speichergerät verbunden, das er teilweise nutzt (Abb. 1–5 zeigt die Schritte 1, 2 und 3).

Abb. 1–5Server-Upgrade: Vorbereiten des neuen Servers

Der alte Server ist über ein Speichernetz mit dem Speichergerät verbunden (1). Der neue Server wird aufgebaut und an das Speichernetz angeschlossen (2). Die Produktionsdaten werden zur Erzeugung von Testdaten innerhalb des Speichers kopiert (3).

Entkoppelung von Server und Speicher

Zunächst wird der neue Server mit der notwendigen Anwendungssoftware installiert. Der neue Server wird direkt an dem Ort aufgebaut, an dem er letztendlich stehen soll. Mit Speichernetzen ist es nämlich möglich, Server und Speicher mehrere Kilometer entfernt voneinander aufzustellen.

Sekundenschnelles Kopieren von Daten

Als Nächstes werden die Produktionsdaten zur Erzeugung von Testdaten innerhalb des Disk- oder Flashsystems kopiert. Moderne Disk- und Flashsysteme können selbst sehr große Datenbestände in Bruchteilen von Sekunden (virtuell) kopieren. Diese Funktion wird Instant Copy genannt und in Kapitel 2 genauer erklärt.

Konsistenz der Daten beachten!

Oft ist es erforderlich, zum Kopieren der Daten die Anwendungen herunterzufahren, damit sich die kopierten Daten in einem konsistenten Zustand befinden. Die Konsistenz ist Voraussetzung dafür, dass die Anwendung auf dem neuen Server in der Lage ist, mit den Daten wieder den Betrieb aufzunehmen. Einige Anwendungen sind sogar fähig, im laufenden Betrieb einen konsistenten Zustand auf der Platte zu halten.

Remote Mirroring

Anschließend werden die kopierten Daten dem neuen Server zugewiesen und der neue Server intensiv getestet (Abb. 1–6). Sollte das Speichersystem durch die Tests so stark belastet werden, dass die Leistung der eigentlichen Anwendung zu sehr beeinträchtigt wird, müssen die Daten erst mittels Remote Mirroring auf ein zweites Speichersystem kopiert werden. Remote Mirroring wird ebenfalls in Kapitel 2 genauer erklärt.

Abb. 1–6Server-Upgrade: Testen des neuen Servers

Alter und neuer Server teilen sich das Speichergerät. Der neue Server wird mit den kopierten Produktionsdaten intensiv getestet (4).

Dynamische Zuweisung vorhandener Datenbestände

Nach erfolgreichem Test werden beide Server heruntergefahren und die Produktionsdaten dem neuen Server zugewiesen. Die Zuweisung der Produktionsdaten an den neuen Server geht ebenfalls sehr schnell (Abb. 1–7 zeigt die Schritte 5 und 6).

Abb. 1–7Server-Upgrade: Inbetriebnahme des neuen Servers

Schließlich wird der alte Server abgeschaltet (5) und der neue Server mit den Produktionsdaten hochgefahren (6).

Upgrade abgeschlossen

Schließlich wird der neue Server mit den Produktionsdaten wieder hochgefahren.

1.5Von verteilten Systemen zu Pervasive Computing und Cloud

Bisher: Verteilte Systeme

Über Jahrzehnte war die Datenverarbeitung in verteilten Systemen von Client-Server-Anwendungen geprägt. Mitarbeiter arbeiten an festen Arbeitsplätzen wie Workstations, PCs und Terminals. Auf diesen läuft eine grafische Benutzeroberfläche, um Anwendungen zu bedienen, die zentral in einem Rechenzentrum laufen. Die zuvor vorgestellte serverzentrierte IT-Architektur (Abschnitt 1.2) und speicherzentrierte IT-Architektur (Abschnitt 1.3) haben sich bewährt, zentrale Server und Server in Außenstellen mit Speicher zu versorgen.

Pervasive Computing: Hochgradig vernetzte Systeme

Seit etwa dem Jahr 2010 vollzieht sich ein Paradigmenwechsel von verteilten Systemen zu Pervasive Computing und Cloud Computing. Unter Pervasive Computing versteht man immer und überall verfügbare Systeme, die unseren Alltag durchdringen und deshalb auch als hochgradig vernetzte Systeme bezeichnet werden. Neue Übertragungstechniken wie UMTS, LTE, WLAN und DSL ermöglichen, dass IT-Dienste immer, überall und mit großer Bandbreite verfügbar sind. Menschen können jederzeit mit Geräten wie Smartphones, Tablets und Laptops Unternehmensanwendungen nutzen und auf vielen Wegen mit anderen Menschen – beruflich und privat – kommunizieren. Neben Telefon und E-Mail sind zahlreiche neue Kommunikationsmittel eine Selbstverständlichkeit wie Social Media (z.B. Facebook, YouTube, Twitter), Instant Messaging (z.B. WhatsApp, SnapChat), und weitere kollaborative Anwendungen (z.B. Slack, Google Docs, Trello), die in Form von ähnlichen Produkten in immer mehr Unternehmen verwendet werden.

Integration von Geräten

Ein weiteres Kennzeichnen des Pervasive Computings besteht in der Integration von Geräten und Maschinen (Internet of Things, IoT). So werden Fahrzeuge mit Geräten versehen, die Messdaten an Versicherungen senden, um den Versicherungstarif je nach zurückgelegter Fahrstrecke und Fahrstil festzusetzen. Über die GPS-Daten von Smartphones aller Verkehrsteilnehmer lässt sich die Verkehrssituation von Haupt- und Nebenstraßen in Echtzeit ermitteln und die Routenplanung für alle Fahrzeuge unmittelbar anpassen. Mit vernetzten Fahrzeugen führt eine Vollbremsung automatisch zum Bremsen von dahinter fahrenden Fahrzeugen.

Große Mengen unstrukturierter Daten

Im Pervasive Computing finden sich neue Datenquellen, die das Datenvolumen herkömmlicher verteilter Systeme um ein Vielfaches übersteigen. Die Daten in verteilten Systemen sind in der Regel strukturiert, in Datenbanksystemen abgelegt und deren Nutzung ist in der Regel vorhersagbar. Im Pervasive Computing überwiegen unstrukturierte Daten (z.B. Bilder, Filme, Freitext, Logdateien), die oft spontan erzeugt werden, zum Beispiel bei besonderen Ereignissen wie einer Naturkatastrophe, einem Terroranschlag oder dem Endspiel einer Fußballweltmeisterschaft.

Dezentrale Verarbeitung der Daten

In verteilten Systemen werden Daten überwiegend zentral auf den Servern im Rechenzentrum verarbeitet. Im Pervasive Computing findet zusätzlich eine dezentrale Datenverarbeitung statt. Auf Smartphones, Tablets und PC werden Daten erzeugt, gespeichert und offline verarbeitet, also auch wenn gerade kein Netz zur Verfügung steht. Aufgrund des Volumens von Messdaten im Internet of Things ist es nicht mehr sinnvoll, alle Rohdaten in das Rechenzentrum zu übertragen, sodass sie auf dem Weg in das Rechenzentrum vorverarbeitet werden müssen, indem sie beispielsweise gefiltert und komprimiert werden. Für das oben genannte Bremsen von dahinter fahrenden Fahrzeugen würde zudem eine Übertragung aller relevanten Daten zu einem zentralen Rechenzentrum viel zu lange dauern, sodass die Daten in oder nahe an den Fahrzeugen verarbeitet werden müssen.

Neue Anforderungen

Pervasive Computing benötigt für die Verarbeitung der Daten neue Methoden und Anwendungen, um dezentrale Datenverarbeitung zu ermöglichen und um aus den neuen Datenquellen Informationen und Erkenntnisse zu gewinnen. Aus dem Pervasive Computing ergibt sich somit die Anforderung an die Unternehmens-IT, zusätzlich zu den bestehenden Daten diese neuen, riesigen, unstrukturierten Datenmengen zu speichern, zu verarbeiten und mit den herkömmlichen Daten zu verknüpfen und hierbei Geräte und Dienste außerhalb der eigenen Rechenzentren zu integrieren. Die dafür notwendige Infrastruktur und Anwendungen sollen schnell und automatisiert bereitgestellt werden und sich wechselnden Lastanforderungen flexibel anpassen.

Lösungsansatz: Cloud Computing

Unter Cloud Computing versteht man neue Architekturen, Techniken und Betriebskonzepte, um IT-Systeme für herkömmliche verteilte Systeme und neue hochgradig vernetzte Systeme automatisiert und schnell bereitzustellen und auf schnell wechselnde Lastanforderungen anzupassen. Viele dieser Neuerungen werden vor allem im Umfeld Pervasive Computing entwickelt, zum Beispiel von den großen Internetunternehmen, weil die herkömmliche Mittel und Methoden für verteilte Systeme den Anforderungen des Pervasive Computings nicht genügen. Viele der dort entwickelten Techniken und Methoden werden zunehmend auch für herkömmliche verteilte Systeme verwendet, um diese effizienter zu betreiben. Pervasive Computing ist heute somit ein Technologietreiber, der maßgeblich beeinflusst, welche Techniken und konkrete Produkte für verteilte Systeme verfügbar sind.

Weitere Vorgehensweise

Viele grundlegende Konzepte der herkömmlichen Datenverarbeitung in verteilten Systemen haben im Pervasive Computing weiterhin Bestand. Wir haben deshalb die bewährte Struktur der ersten Auflagen dieses Buchs beibehalten und an entsprechenden Stellen um neue Konzepte erweitert wie Servervirtualisierung, Objektspeicher, Hadoop Distributed File System (HDFS) und Enterprise File Sync&Share (EFSS), um diese neuen Themen aufzugreifen und Unterschiede zwischen herkömmlichen verteilten Systemen und dem neuen Pervasive Computing herauszuarbeiten.

1.6Gliederung des Buchs

Der Weg vom Speicher zur Anwendung als roter Faden durch das Buch

Unser Anliegen ist es, in diesem Buch die Grundlagen und den Einsatz von Speichernetzen anschaulich zu erklären. Zum Einstieg in das Thema haben wir die Speicherhierarchie mit flüchtigen und persistenten Speichern beschrieben. Dann haben wir die serverzentrierte und die speicherzentrierte IT-Architektur vorgestellt und Vorteile der speicherzentrierten IT-Architektur anhand der Aufrüstung eines Anwendungsservers beschrieben. Im Anschluss haben wir den Paradigmenwechsel von verteilten Systemen zu Pervasive Computing und Cloud Computing erläutert. In den weiteren Kapiteln behandeln wir die bereits erwähnten Konzepte und Techniken sowie weitere Beispiele im Detail. Der Aufbau des ersten Teils des Buchs orientiert sich an dem I/O-Pfad des Speichergeräts bis hin zur Anwendung. Schwerpunkte des zweiten Teils sind der Einsatz dieser Techniken, ausgewählte speichernahe Anwendungen wie die Datensicherung und die Archivierung sowie die Verwaltung von Speichernetzen.

Kapitel 2: Intelligente Disk- und Flashsysteme

In heutigen (2018) IT-Systemen werden für die persistente Speicherung von Daten vor allem Flashmodule, SSDs, Festplatten und Bänder eingesetzt. Die Anschaffung und Verwaltung einiger großer Speichersysteme ist wirtschaftlich günstiger als die Anschaffung und Verwaltung vieler kleiner Speichersysteme. Für Laufwerke (Flashmodule, SSDs und Festplatten) heißt dies, dass die einzelnen Laufwerke durch große externe Disk- und Flashsysteme ersetzt werden. Im Gegensatz zu einem Fileserver kann man sich Disk- und Flashsysteme als Laufwerkserver vorstellen. Andere Server können diese über das Speichernetz exportierten Laufwerke genauso benutzen wie lokal angeschlossene Laufwerke. In Kapitel 2 zeigen wir, was moderne Disk- und Flashsysteme neben den bereits erwähnten Funktionen Instant Copy und Remote Mirroring noch alles leisten können. Wechselbare Speichermedien wie Bänder und optische Speicher behandeln wir später in Kapitel 7.

Kapitel 3: I/O-Techniken: Fibre Channel und weitere I/O-Techniken

I/O-Techniken stellen die Übertragung der Daten zwischen Servern und Speichergeräten sicher. Fibre Channel ist die I/O-Technik für die Realisierung von Speichernetzen für verteilte Systeme und wird es voraussichtlich noch einige Jahre bleiben. Für bestimmte Einsatzzwecke kommen auch andere Techniken zum Einsatz wie iSCSI, FCoE, InfiniBand und NVMeOF. All diese Netzwerktechniken erläutern wir in Kapitel 3.

Kapitel 4: Network Attached Storage (NAS) und …

Dateisysteme sind für dieses Buch aus zweierlei Gründen interessant. Zum einen sind mit Network Attached Storage (NAS) vorkonfigurierte Fileserver ein wichtiger Baustein heutiger IT-Systeme. Auch mit NAS-Systemen können Speichernetze realisiert werden. Im Gegensatz zum blockorientierten Datenverkehr von Fibre Channel, iSCSI und FCoE werden hier ganze Dateien oder Dateifragmente übertragen.

… verteilte Dateisysteme

Die andere interessante Entwicklung im Bereich von Dateisystemen sind verteilte Dateisysteme. Mit verteilten Dateisystemen können mehrere Server über das Speichernetz auf die gleichen Dateien zugreifen. Verteilte Dateisysteme können deutlich leistungsfähiger sein als Netzwerkdateisysteme wie NFS und SMB sowie die oben genannten NAS-Systeme. Anhand verteilter Dateisysteme erläutern wir exemplarisch Probleme, die in gleicher Weise auch für vergleichbare Anwendungen wie parallele Datenbanksysteme gelöst werden müssen. Mit dem Hadoop Distributed File System (HDFS) stellen wir ein verteiltes Dateisystem näher vor, das für die Analyse von unstrukturierten Daten optimiert ist. In Kapitel 4 behandeln wir Network Attached Storage (NAS) und verteilte Dateisysteme.

Kapitel 5: Speichervirtualisierung

In den ersten vier Kapiteln des Buchs beschreiben wir grundlegende Komponenten und Techniken für Speichernetze. Mit dem zunehmenden Wachstum an Daten zeigt sich, dass die Implementierung von Speichernetzen allein nicht ausreicht. In Kapitel 5 stellen wir mit der Speichervirtualisierung einen Ansatz vor, der die Zuweisung vorhandener Speicherkapazität an die Server vereinfacht. Dazu umreißen wir in diesem Kapitel Schwierigkeiten des Einsatzes von Speichernetzen. Weiter beschreiben wir mögliche Orte für die Realisierung der Speichervirtualisierung und diskutieren verschiedene Alternativen der Speichervirtualisierung wie die Virtualisierung auf Blockebene und die Virtualisierung auf Dateiebene sowie die symmetrische und die asymmetrische Speichervirtualisierung.

Kapitel 6: Objektspeicher

Objektspeicher ist eine vergleichsweise junge Speichertechnik, die etwa in den Jahren 2004 bis 2008 im Umfeld von Cloud Computing aufgekommen ist. Objektspeicher ist sehr skalierbar und erlaubt die Speicherung von Daten variabler Größe. Objektspeicher eignet sich somit besonders für Webanwendungen, wird aber zunehmend für andere Zwecke eingesetzt, wo früher NAS-Systeme und Bänder eingesetzt wurden. In Kapitel 6 erläutern wir die Grundlagen von Objektspeichern und zeigen Unterschiede und Ähnlichkeiten zu Dateisystemen.

Kapitel 7: Wechselmedien

Auswechselbare Speichermedien wie Bänder sind ein wichtiger Bestandteil der Speicherarchitektur großer Rechenzentren. Sie ergänzen Disksysteme, Dateisysteme und Objektspeicher für große Datenmengen, die nur selten oder gar nicht verändert werden und auf die nur selten oder gar nicht zugegriffen wird. Bänder zeichnen sich durch hohe Zuverlässigkeit und geringe Kosten aus. In Kapitel 7 beschäftigen wir uns vor allem mit Bändern, Bandlaufwerken und Tape Libraries. Des Weiteren stellen wir mit dem Linear Tape File System (LTFS) einen Ansatz vor, die Benutzbarkeit von Bändern für gewisse Einsatzzwecke zu vereinfachen. Mit diesem Kapitel schließen wir Teil I des Buchs und damit die Grundlagen für Speichernetze.

Kapitel 8: Basisarchitekturen

Bis einschließlich Kapitel 7 stellen wir Techniken für Speichernetze vor. Ab Kapitel 8 wenden wir uns deren Anwendung zu und fassen zunächst die vorgestellten Techniken in grundlegenden Architekturen zusammen. Wir zeigen in vielen Beispielen, wie Speichernetze helfen, flexible und hochverfügbare IT-Systeme zu entwerfen. Die hier beschriebenen Basisarchitekturen für Verfügbarkeit, Anpassbarkeit und Skalierbarkeit haben sich in herkömmlichen verteilten Systemen bewährt und sind für das Pervasive Computing weiterhin von Bedeutung.

Kapitel 9: Pervasive Computing und Cloud

Cloud Computing beschreibt eine Architektur und ein Betriebskonzept für die Bereitstellung und die Nutzung von IT-Diensten. Servervirtualisierung und Cloud Computing ermöglichen eine flexible Infrastruktur, die es erlaubt, auf neue und schnell wechselnde Anforderungen des Pervasive Computings zu reagieren. In Kapitel 9 befassen wir uns mit Pervasive Computing, Cloud Computing und Servervirtualisierung und zeigen, wie diese die Anforderungen an Speicher und die Nutzung von Speicher verändern.

Kapitel 10: Datensicherung

Eine zentrale Anwendung in jedem IT-System ist die Datensicherung. Datensicherungssysteme (Backup-Systeme) können heterogene IT-Umgebungen mit vielen Tausend Servern und Anwendungen weitgehend automatisch sichern. Die unterschiedlichen Anforderungen für die Sicherung von Dateisystemen, Datenbanksystemen und virtualisierten Umgebungen müssen von einem modernen Backup-System ebenso gemeistert werden wie die stetig steigende Menge der zu sichernden Daten. Flexible Backup-Strategien sind erforderlich, um Backup-Fenster einzuhalten und Wiederherstellungsläufe zu beschleunigen. In Kapitel 10 erklären wir Grundlagen der Datensicherung und zeigen, wie Speichernetze helfen, Daten effizienter zu sichern und wiederherzustellen.

Kapitel 11: Archivierung

Eine weitere wichtige Anwendung von Speichernetzen ist die digitale Archivierung. Der Gesetzgeber fordert, immer mehr Daten Jahre, Jahrzehnte oder noch länger aufzubewahren. Die langen Aufbewahrungszeiten und der technische Wandel erzwingen, die Archivdaten hin und wieder umzukopieren. Dabei dürfen die Archivdaten aber nicht verändert oder gar gelöscht werden können. In Kapitel 11 beschreiben wir grundlegende Anforderungen an die digitale Archivierung und stellen zahlreiche Techniken und darauf aufbauende Lösungsansätze vor. Wir gehen auch auf die Besonderheiten der Langzeitarchivierung ein, bei der die Aufbewahrungszeiten unbestimmt oder gar unendlich sind.

Kapitel 12: Business Continuity

Der kontinuierliche Zugriff auf geschäftskritische Daten und Anwendungen selbst im Krisenfall ist entscheidend für das Fortbestehen eines Unternehmens. Dies gilt nicht nur für gerne genannte Bereiche wie Börsengeschäfte, Flugsicherung, Patientendaten und Internetunternehmen. Auch immer mehr kleinere und mittlere Unternehmen beliefern weltweit ihre Kunden oder sind über Just-in-time-Fertigung und vertraglich festgelegte kurze Lieferzeiten sehr eng in die Produktionsprozesse von großen Unternehmen wie Automobilhersteller verzahnt. In Kapitel 12 führen wir unter besonderer Berücksichtigung von Speichernetzen in den Bereich Business Continuity ein und beschreiben verschiedene Techniken und Lösungsansätze.

Kapitel 14: Verwaltung von Wechselmedien

Speichernetze sind komplexe Systeme, die aus zahlreichen Komponenten zusammengesetzt sind. Für die Verwaltung von Speichernetzen muss man im ersten Schritt die aktuelle Konfiguration automatisiert erfassen. Hierzu braucht man Werkzeuge, die helfen, Fragen zu beantworten wie »Welcher Server belegt wie viel Platz auf welchen Speichersystemen?«, »Welche Server sind überhaupt an mein Speichernetz angeschlossen?« oder »Welche Hardwarekomponenten werden eingesetzt und wie stark ist das Netz ausgelastet?«. In diesem Zusammenhang ist auch die Überwachung des Speichernetzes im Hinblick auf Leistungsengpässe, Kapazitätsengpässe von Dateisystemen und Störungen wichtig. Der zweite Schritt betrifft die Automation der Verwaltung von Speichernetzen: Wichtige Themen sind die regelbasierte Fehlerbehandlung und die automatische Zuweisung freier Speicherkapazität. In Kapitel 13 behandeln wir die Verwaltung von Speichernetzen im Detail sowie in diesem Zusammenhang eingesetzte Techniken wie SNMP, CIM/WBEM und SMI-S.

Kapitel 13: Verwaltung von Speichernetzen

In großen Umgebungen werden Tausende von Bändern und Hunderte von Bandlaufwerken eingesetzt. Verwaltungssysteme für Wechselmedien sind notwendig, um diese optimal zu nutzen. In Kapitel 14 beschreiben wir Dienste einer und Anforderungen an eine Wechselmedienverwaltung und stellen mit dem IEEE 1244 Standard for Removable Media Management einen Ansatz vor, diese zu erfüllen.

Was behandelt dieses Buch nicht?

Was behandelt dieses Buch nicht?

Zur Abgrenzung des Inhalts ist es auch wichtig zu wissen, welche Themen nicht behandelt werden:

Konkrete Produkte

Konkrete Produkte

Der Lebenszyklus von Produkten ist für ein Buch zu kurz. Produkte ändern sich, Konzepte nicht.

Ökonomische Aspekte

Ökonomische Aspekte

Dieses Buch beschreibt vor allem technische Aspekte von Speichernetzen. Es behandelt Konzepte und Lösungsansätze. Preise ändern sich sehr häufig, Konzepte nicht.

Zu technische Details

Zu technische Details

Das Buch ist eine Einführung in Speichernetze. Es behandelt nicht die notwendigen Details für die Entwicklung von Komponenten für Speichernetze. Uns ist es wichtiger, das gesamte Bild zu vermitteln.

Planung und Implementierung von Speichernetzen

Die Planung und Implementierung von Speichernetzen

Die Planung und Implementierung erfordert Wissen über konkrete Produkte, aber Produkte ändern sich sehr häufig. Planung und Implementierung erfordern zudem viel Erfahrung. Das Buch dagegen ist als Einführung konzipiert. Unerfahrene Leser sollten sich bei der Einführung eines Speichernetzes von Experten beraten lassen. Außerdem muss eine Implementierung immer die jeweiligen konkreten Rahmenbedingungen berücksichtigen. Genau dies kann ein Buch nicht leisten.

Teil I

Techniken für Speichernetze

2Disk- und Flashsysteme

Peter Kimmel · Ulf Troppens

Ziel des Kapitels

Flashmodule, SSDs, Festplatten und Bänder sind heute (2018) die wichtigsten Medien für die persistente Speicherung von Daten. Persistent bedeutet, dass gespeicherte Daten auch dann erhalten bleiben, wenn das Speichergerät nicht an Strom angeschlossen ist. Mit der Einführung von Speichernetzen werden die vorhandenen kleinen Speichergeräte durch wenige große Speichersysteme ersetzt (Speicherkonsolidierung). Beispielsweise werden einzelne Laufwerke und kleinere Laufwerksstapel durch große Disk- und Flashsysteme ersetzt, die je nach Größe zwischen einigen Terabytes und einigen Petabytes Daten speichern können. Außerdem haben sie den Vorteil, dass Funktionen wie hohe Verfügbarkeit, hohe Leistungsfähigkeit, Instant Copies und Remote Mirroring auch im Open-Systems-Bereich (Unix, Windows und macOS) zu einem vernünftigen Preis erhältlich sind. Die Verwaltung weniger großer Speichersysteme ist wesentlich einfacher und dadurch billiger als die Verwaltung vieler kleiner Laufwerksstapel. Allerdings muss der Administrator bei großen Disk- und Flashsystemen genauer planen, was er tut. Dieses Kapitel beschreibt die Funktionen solcher modernen Disk- und Flashsysteme.

Gliederung des Kapitels

Wir beginnen Kapitel 2 mit Grundlagen von Disk- und Flashsystemen wie interner Aufbau, Laufwerke (Flashmodule, SSDs und Festplatten) sowie Gestaltungsmöglichkeiten der internen I/O-Kanäle und der Controller (Abschnitt 2.1). RAID-Controller fassen mehrere physische Laufwerke zu virtuellen Laufwerken zusammen, die schneller und ausfallsicherer sind als einzelne physische Laufwerke. Die Gestaltungsmöglichkeiten für die Zusammenfassung der physischen Laufwerke werden in RAID-Level unterschieden. In Abschnitt 2.2 stellen wir zahlreiche RAID-Level vor und vergleichen diese. Manche RAID-Controller setzen einen Cache ein, um Schreib- und Lesezugriffe der Server noch mehr zu beschleunigen (Abschnitt 2.3). Zusätzlich stellen intelligente Controller Dienste wie Instant Copy, Remote Mirroring (Abschnitt 2.4) und Speicheroptimierung (Abschnitt 2.5) bereit. Zum Schluss fassen wir die in diesem Kapitel beschriebenen Maßnahmen zur Erhöhung der Verfügbarkeit von intelligenten Disk- und Flashsystemen zusammen (Abschnitt 2.6). Das Kapitel schließt wie alle Kapitel mit einer Zusammenfassung des Kapitels und dem Ausblick auf die nächsten Kapitel (Abschnitt 2.7).

2.1Grundlagen

Gliederung des Abschnitts

In diesem Abschnitt beschäftigen wir uns mit den Grundlagen von Disk- und Flashsystemen. Dazu beginnen wir mit deren innerem Aufbau (Abschnitt 2.1.1) und der Abgrenzung von Disksystemen und Flashsystemen (Abschnitt 2.1.2). Dann beschreiben wir darin verwendete Speichermedien wie Flashmodule, SSDs und Festplatten (Abschnitt 2.1.3) und Gestaltungsmöglichkeiten für die internen I/O-Kanäle (Abschnitt 2.1.4). Der Controller ist die Schaltzentrale eines Disk- oder Flashsystems. Systeme ohne Controller werden JBODs (Just a Bunch of Disks) genannt. JBODs stellen lediglich ein Gehäuse und eine gemeinsame Stromversorgung für mehrere Laufwerke bereit (Abschnitt 2.1.5). Sogenannte RAID-Controller fassen mehrere physische Laufwerke zu virtuellen Laufwerken zusammen, die schneller und ausfallsicherer sind als einzelne physische Laufwerke (Abschnitt 2.1.6).

2.1.1Architektur von Disk- und Flashsystemen

Anschlussports

Im Gegensatz zu einem Fileserver kann man sich Disk- und Flashsysteme als Laufwerksserver vorstellen. Server werden mit Standard-I/O-Techniken wie Fibre Channel, SAS, iSCSI oder InfiniBand mit den Anschlussports des Disksystems verbunden (Kap. 3). Sie können so die Speicherkapazität nutzen, die das Disksystem zur Verfügung stellt (Abb. 2–1). Für den Server bleibt der interne Aufbau des Disk- oder Flashsystems vollkommen verborgen; er sieht nur die Laufwerke, die das Speichersystem dem Server zur Verfügung stellt.

Aufbau eines Disk- oder Flashsystems

Die Anschlussports werden über interne I/O-Kanäle zu den Laufwerken des Disk- oder Flashsystems weitergeführt (Abb. 2–2). In vielen Disk- und Flashsystemen befindet sich ein Controller zwischen den Anschlussports und den Laufwerken. Der Controller kann mithilfe der sogenannten RAID-Verfahren (RAID = Redundant Array of Independent Disks) die Verfügbarkeit von Daten und die Performanz von Datenzugriffen deutlich erhöhen. Darüber hinaus realisieren manche Controller die Kopierdienste Instant Copy und Remote Mirroring sowie weitere Zusatzdienste. Der Controller versucht in Zusammenarbeit mit dem Cache, Schreib- und Lesezugriffe der Server zu beschleunigen.

Abb. 2–1Anschluss von Servern an ein Disksystem

Server werden mit Standard-I/O-Techniken an Disk- und Flashsysteme angeschlossen. Die Abbildung zeigt einen Server, der über iSCSI angeschlossen ist. Zwei weitere sind über ein Fibre Channel SAN verbunden.

Abb. 2–2Architektur intelligenter Disksysteme

Server werden über die Ports an das Disk- oder Flashsystem angeschlossen. Intern besteht es aus Laufwerken (Flashmodule, SSDs und Festplatten), einem Controller, einem Cache und internen I/O-Kanälen.

Verschiedene Größen

Disk- und Flashsysteme gibt es in allen Größen. Kleine Systeme haben ein bis zwei Anschlüsse für Server oder Speichernetze, sechs bis acht Laufwerke und je nach Plattenkapazität eine Speicherkapazität von wenigen Terabytes. Große Disk- und Flashsysteme haben mehrere Dutzend Anschlussports für Server oder Speichernetze, mehrere Controller und mehrere interne I/O-Kanäle. Durch die Anbindung über ein Speichernetz können noch wesentlich mehr Server darauf zugreifen. Große Disk- und Flashsysteme können bis zu mehreren Petabytes an Daten speichern und wiegen je nach Hersteller weit über eine Tonne. Die Abmessungen eines großen Disk- oder Flashsystems sind durchaus mit denen eines Kleiderschranks vergleichbar.

Der Aufbau realer Disk- und Flashsysteme ist komplexer

Abbildung 2–2 zeigt eine vereinfachte schematische Darstellung. Die Architektur realer Disk- und Flashsysteme ist komplexer und variiert sehr stark. Letztendlich finden sich aber immer die in der Abbildung gezeigten Komponenten wieder. Für die weitere Diskussion im Buch ist die vereinfachte Darstellung in Abbildung 2–2 vollkommen ausreichend.

Abb. 2–3Flexible Zuweisung freier Speicherkapazität

Alle Server teilen sich die Speicherkapazität eines Disk- oder Flashsystems. Je nach Bedarf kann jedem Server noch freier Speicher flexibel zugewiesen werden.

Speicherkonsolidierung: flexible Zuweisung von freiem Speicher

Unabhängig von Speichernetzen haben die meisten Disk- und Flashsysteme den Vorteil, dass freier Speicher flexibel jedem Server zugewiesen werden kann, der an das Speichersystem angeschlossen ist (Speicherkonsolidierung). Abbildung 2–3 greift noch einmal das Beispiel von Abbildung 1–3 auf Seite 5 auf. In Abbildung 1–3 ist es nicht möglich, dem Server 2 mehr Speicher zuzuweisen, obwohl auf den Servern 1 und 3 noch freier Speicher vorhanden ist. In Abbildung 2–3 ist dies kein Problem: Alle Server sind entweder direkt oder über ein Speichernetz indirekt an das Speichersystem angeschlossen. Jedem Server kann hier freier Speicher zugewiesen werden. Unter freier Speicherkapazität sind übrigens sowohl bereits installierte, aber noch nicht benutzte Laufwerke als auch freie Einschübe für noch zu installierende Laufwerke zu verstehen.

2.1.2Abgrenzung: Disksystem versus Flashsystem

Disksystem versus Flashsystem

Ursprünglich wurden in dieser Art von Speichersystemen Festplatten (engl. Disks) als Medien verbaut, sodass diese als »Disksubsysteme« oder »Disksysteme« bezeichnet wurden. Mit dem Aufkommen von Flashspeichern wie Flashmodulen und SSDs werden Disksysteme, die ausschließlich Flashspeicher verbauen, als »Flashsysteme« bezeichnet, um deren besondere Leistungsfähigkeit gegenüber Disksystemen herauszustellen. Disksysteme und Flashsysteme haben jedoch viele Gemeinsamkeiten bezüglich Architektur und Funktion, sodass wir im Weiteren den Begriff »Disksystem« als Oberbegriff für »Disk- und Flashsysteme« verwenden.

2.1.3Laufwerke: Flashmodule, SSDs und Festplatten

Definition: Laufwerk

Der Controller des Disksystems muss alle Daten letztendlich auf Speichermedien ablegen wie Festplatten, Solid-State-Disks (SSDs) und Flashmodulen. Die in diesem Kapitel vorgestellten Konzepte für Disksysteme wie RAID, Caching, Instant Copy, Remote Mirroring und Speicheroptimierung sind unabhängig von der Laufwerkstechnologie. Wir verwenden deswegen im Weiteren den Begriff »Laufwerk« als Oberbegriff für Medien wie Flashmodule, SSDs und Festplatten.

Festplatten

Festplatten bestehen aus einem Controller mit Cache (nicht zu verwechseln mit Controller und Cache des Disksystems), einer oder mehreren sich drehenden Scheiben, über den Scheiben beweglichen Schreib-/Leseköpfe sowie einem oder zwei Anschlussports für die Übertragung von Befehlen und Daten. Der Controller steuert die Schreib-/Leseköpfe, um auf die Scheiben Daten zu schreiben und von diesen Daten zu lesen. Dazu nimmt er zu schreibende Daten über die Anschlussports entgegen beziehungsweise übergibt diesen gelesene Daten. Für die Anschlussports werden heute (2018) überwiegend SAS und SATA eingesetzt (Kap. 3). Die erste Festplatte wurde 1956 von IBM vorgestellt und war bis etwa 2015 das überwiegend in Disksystemen eingesetzte Speichermedium.

Solid-State-Disks (SSDs)

Solid-State-Disks (SSDs) haben einen ähnlichen Aufbau wie Festplatten, ersetzen aber die sich drehenden Scheiben und die Schreib-/Leseköpfe durch Flashspeicher. Flashspeicher sind digitale Speicherbausteine, die im Gegensatz zum Hauptspeicher (Random Access Memory, RAM) persistent sind. Persistent bedeutet, dass sie über einen langen Zeitraum Daten ohne die Zufuhr von Energie speichern können. SSDs zeichnen sich gegenüber herkömmlichen Festplatten aus durch geringe Zugriffszeiten, geringen Energieverbrauch, geringere Wärmeentwicklung, geringe Lärmemission, geringes Gewicht und hohe Robustheit. SSDs haben wie Festplatten Anschlussports, um zu schreibende Daten entgegenzunehmen und um gelesene Daten zu übergeben. Seit 2008 werden SSDs in Disksystemen eingesetzt. Heute (2018) sind SSDs genauso verbreitet wie Festplatten, und es ist abzusehen, dass sie zusammen mit anderen flashbasierten Speichermedien in der Zukunft Festplatten weitgehend oder vollständig ersetzen werden.

Flashmodule

SSDs werden wie Festplatten über Anschlussports und I/O-Techniken wie SAS und SATA mit der Außenwelt verbunden. Dies hat den Vorteil, dass sie sich nahtlos in die bestehende Architektur von Disksystemen, Servern und Betriebssystemen eingliedern. Jedoch stellen die Anschlussports und I/O-Techniken wie SAS und SATA einen Engpass dar. In neuen Disksystemen für besonders hohe Leistungsanforderungen werden deshalb Flashmodule eingesetzt, die der Controller des Disksystems direkt ohne SAS und SATA ansprechen kann. Disksysteme mit Flashmodulen sind dadurch deutlich leistungsfähiger als Disksysteme mit SSDs. Der Einsatz der Flashmodule ist in den Disksystemen gekapselt. Von außen werden sie weiterhin über SAS oder Fibre Channel angeschlossen, sodass sich die Architektur der Server nicht ändert. Seit 2012 werden Flashmodule in Disksystemen eingesetzt. Es ist heute (2018) abzusehen, dass der Einsatz von Flashmodulen genauso wie der Einsatz von SSDs zunehmen wird. Es wäre auch interessant, Flashmodule direkt in Servern zu verbauen. Jedoch ändert sich dadurch die über Jahrzehnte entwickelte Speicherhierarchie der Server, Betriebssysteme und Anwendungen (Abschnitt 1.1), sodass dies vermutlich länger dauert. Mit Non-Volatile Memory Express (NVMe) entsteht jedoch schon eine neue I/O-Technik, die diesen Ansatz unterstützt (Abschnitt 3.6.4).

Schneller Fortschritt

Der Fortschritt bei den Speichermedien schreitet schnell voran. In der ersten Auflage des Buchs im Jahr 2001 hatten wir noch Beispiele, in denen Festplatten mit 36 GB Kapazität als groß bezeichnet wurden. Medien wie Flashmodule und SSDs und I/O-Techniken wie SAS und SATA gab es noch nicht. Einer der Autoren erinnert sich dunkel daran, als er seinen ersten USB-Stick mit 128 MB Speicherkapazität erhalten hat. Heute (2018) werden in Disksystemen Standardfestplatten in der Größe von 300 GB bis 10 TB und SSDs in der Größe von 200 GB bis 15 TB eingesetzt, wobei die Hersteller von SSDs und Festplatten bereits Laufwerke mit deutlich größeren Kapazitäten vorgestellt haben. Disksysteme mit Flashmodulen haben heute (2018) eine Gesamtkapazität zwischen einigen Terabytes bis hin zu einigen Petabytes.

Marktsegmentierung

Bei SSDs und Festplatten haben sich zwei Marktsegmente ausgebildet: Unter Enterprise-Disks versteht man SSDs und Festplatten, die für einen ununterbrochenen Serverbetrieb (24×7-Betrieb = 7 Tage à 24 Stunden) im industriellen Bereich (Enterprise) ausgelegt und für den Einsatz hinter RAID-Controllern abgestimmt sind. Consumer-Disks beschreiben SSDs und Festplatten, die für den Einsatz im Büro und den privaten Gebrauch entworfen worden sind (8×5-Betrieb = 5 Tage à 8 Stunden). Heute (2018) verfügen Enterprise-Disks über SAS- und SATA-Anschlussports, während Consumer-Disks nur mit SATA ausgestattet sind. Consumer-Disks sind preiswerter, dafür fehleranfälliger. Deshalb sollten in Disksystemen immer Enterprise-Disks eingesetzt werden (Abschnitt 2.2.5). In der weiteren Beschreibung der Konzepte verwenden wir wie oben beschrieben den Oberbegriff »Laufwerke«.

Auswahl der Laufwerkstypen

Die Anzahl der maximal in ein Disksystem einsetzbaren Laufwerke ist in der Regel begrenzt. Deshalb bedingt die Größe der verwendeten Laufwerke die Maximalkapazität des gesamten Disksystems. Bei der Auswahl der Größe der internen physischen Laufwerke muss man zwischen den Anforderungen maximale Leistung und maximale Kapazität des Gesamtsystems abwägen. Oft wird ein kleiner Kapazitätsanteil an schnellen Flashmodulen oder SSDs mit langsameren Festplatten größerer Kapazität gemischt, sodass sich in der Summe des Gesamtsystems eine ausreichende Leistung einstellt. Dabei sorgen Daten-Verschiebungsalgorithmen dafür, dass die Daten mit den höchsten Zugriffsdichten auf Flashmodulen oder SSDs platziert werden, während Daten, auf die nur selten zugegriffen wird, auf langsameren Laufwerken gespeichert werden (Abschnitt 2.5.3).

Auswahl der Laufwerkgrößen

Im Hinblick auf die Leistungsfähigkeit ist es dabei häufig vorteilhaft, zulasten der Maximalkapazität kleinere Laufwerke einzusetzen: Stehen etwa in einem Disksystem mit klassischen drehenden Festplatten bei gleicher Kapazität mehr Platten zur Verfügung, so werden die Daten über mehr Festplatten und damit die Gesamtlast über mehr Arme und Schreib-/Leseköpfe und meist auch über mehr I/O-Kanäle verteilt (Abb. 2–4). Für viele Anwendungen sind Festplatten mittlerer Größe ausreichend. Für Anwendungen mit sehr hohen Leistungsanforderungen sollten allerdings Flashmodule oder SSDs erwogen werden. Auch bei diesen ist es so, dass die SSDs hoher Kapazität meist für eine geringere I/O-Zugriffsdichte ausgelegt sind, während SSDs mit kleinen Kapazitäten und entsprechender Spezifikation auch sehr hohe Schreibraten vertragen und damit mehr Leistung liefern, bei einem allerdings höheren Preis pro Terabyte.

Abb. 2–4Vergleich: Große und kleine interne Laufwerke

Beispiel reines Festplatten-Speichersystem: Bei kleinen internen Laufwerken wird die Last über mehr Laufwerke und damit über mehr Schreib- und Leseköpfe verteilt. Dafür ist die maximale Speicherkapazität kleiner, denn in beiden Disksystemen können nur sechzehn Laufwerke eingebaut werden.

2.1.4Interne I/O-Kanäle

Interner I/O-Kanal

Die Verbindungen zwischen Anschlussports und Controller und zwischen Controller und den internen Laufwerken werden als I/O-Kanal bezeichnet. Hierfür werden in der Regel Standard-I/O-Techniken wie SATA (Serial ATA) und SAS (Serial Attached SCSI) verwendet, zum Teil auch noch Fibre Channel (Kap. 3). Manchmal werden aber auch proprietäre, also herstellerspezifische, I/O-Techniken eingesetzt. Die I/O-Kanäle können unabhängig von der verwendeten I/O-Technik redundant ausgelegt werden, um die Verfügbarkeit des Disksystems zu erhöhen. Hierbei sind folgende Fälle zu unterscheiden:

Nicht redundant

Nicht redundant

Bei der nicht redundanten Verkabelung werden die einzelnen physischen Laufwerke nur über einen I/O-Kanal angeschlossen (Abb. 2–5, links). Fällt dieser Zugriffspfad aus, so kann nicht mehr auf die Daten zugegriffen werden.

Active/Passive

Active/Passive

Bei der Active/Passive-Verkabelung werden die einzelnen Laufwerke über zwei I/O-Kanäle angeschlossen (Abb. 2–5, rechts). Im Normalbetrieb kommuniziert der Controller mit den Laufwerken nur über den ersten I/O-Kanal; der zweite I/O-Kanal wird in dieser Zeit nicht benutzt. Bei Ausfall des ersten I/O-Kanals schaltet der Controller vom ersten auf den zweiten I/O-Kanal um.

Active/Active (No Load Sharing)

Active/Active (No Load Sharing)

Bei dieser Verkabelung nutzt der Controller beide I/O-Kanäle im Normalbetrieb (Abb. 2–6, links). Die Laufwerke werden dazu in zwei Gruppen aufgeteilt: Im Normalbetrieb wird die erste Gruppe über den ersten I/O-Kanal und die zweite über den zweiten angesprochen. Fällt ein I/O-Kanal aus, so werden beide Gruppen über den verbliebenen I/O-Kanal angesprochen.

Active/Active (Load Sharing)

Active/Active (Load Sharing)

Hier werden im Normalbetrieb alle Laufwerke über beide I/O-Kanäle angesprochen (Abb. 2–6, rechts). Der Controller verteilt die Last dynamisch über beide I/O-Kanäle, sodass die verfügbare Hardware optimal genutzt wird. Fällt ein I/O-Kanal aus, so wird nur noch über den verbliebenen kommuniziert.

Vergleich der Anschlussalternativen

Die nicht redundante Verkabelung ist am einfachsten und damit auch am billigsten zu realisieren; dafür bietet sie keinen Ausfallschutz. Zur Erhöhung der Verfügbarkeit wird mindestens eine Active/Passive-Verkabelung benötigt, während die Active/Active-Verkabelung mit Load Sharing die zugrunde liegende Hardware am besten ausnutzt.

Abb. 2–5Interne I/O-Kanäle: Active und Active/Passive

Bei der nicht redundanten Verkabelung werden alle Laufwerke nur über einen I/O-Kanal angeschlossen. Bei der Active/Passive-Verkabelung werden alle Laufwerke zusätzlich mit einem zweiten I/O-Kanal verbunden. Fällt der primäre I/O-Kanal aus, so schaltet der Controller auf den zweiten I/O-Kanal um.

Abb. 2–6Interne I/O-Kanäle: Active/Active

Die Active/Active-Verkabelung (No Load Sharing) nutzt beide I/O-Kanäle gleichzeitig. Jedoch wird jedes Laufwerk nur über einen I/O-Kanal angesprochen, wobei im Fehlerfall auf den jeweils anderen umgeschaltet wird. Bei der Active/Active-Verkabelung (Load Sharing) werden die Laufwerke über beide I/O-Kanäle angesprochen.

2.1.5Just a Bunch of Disks (JBOD)

Komplexitätsstufen

Vergleicht man Disksysteme im Hinblick auf ihre Controller, so kann man drei Komplexitätsstufen unterscheiden: (1) kein Controller (Abschnitt 2.1.5), (2) RAID-Controller (Abschnitt 2.1.6) und (3) intelligente Controller mit Zusatzdiensten wie Instant Copy und Remote Mirroring (Abschnitt 2.4) und Speicheroptimierung (Abschnitt 2.5).

Disksysteme ohne Controller: Just a Bunch of Disks (JBOD)

Hat das Disksystem keinen internen Controller, so ist es lediglich ein Gehäuse mit Laufwerken (Just a Bunch of Disks, JBOD). Hierbei sind die Laufwerke fest in das Gehäuse eingebaut und die Anschlüsse für I/O-Kanäle und Stromversorgung an einer Stelle nach außen geführt. Dadurch ist ein JBOD einfacher zu handhaben als mehrere lose Laufwerke. Große JBODs enthalten heute (2018) in der Regel um die 60 Laufwerke. Ein angeschlossener Server erkennt alle Laufwerke als eigenständige Laufwerke. Für ein JBOD mit 60 Laufwerken werden also 60 Geräteadressen benötigt. Bei älteren I/O-Techniken wie SCSI (Abschnitt 3.1.2) und Fibre Channel Arbitrated Loop (Abschnitt 3.3.5) kann dies zu einem Engpass an Geräteadressen führen.

In den folgenden Abschnitten: RAID-Controller und intelligente Controller

Im Gegensatz zu intelligenten Disksystemen ist ein JBOD insbesondere nicht in der Lage, RAID oder andere Formen der Speichervirtualisierung zu unterstützen. Diese können bei Bedarf aber außerhalb des JBODs, etwa als Software im Server (Abschnitte 5.3.2 und 9.3.6) oder als eigenständige Virtualisierungsinstanz im Speichernetz (Abschnitt 5.2.3), realisiert werden.

2.1.6Speichervirtualisierung durch RAID

Disksysteme mit RAID-Controller

Ein Disksystem mit RAID-Controller bietet einen größeren Funktionsumfang als ein JBOD. Im Jahr 1988 erschien die erste Veröffentlichung zu RAID. Damals waren Festplatten teurer und unzuverlässiger als heute, sodass dort RAID als ein »Redundant Array of Inexpensive Disks« eingeführt wurde. Heute steht RAID für »Redundant Array of Independent Disks«. Disksysteme, die RAID unterstützen, werden manchmal auch als RAID-Array bezeichnet.

RAID-Ziele: Erhöhung von Leistung und Verfügbarkeit

RAID verfolgt vor allem zwei Ziele: Erhöhung der Leistung durch Striping und Erhöhung der Verfügbarkeit durch Redundanz. Striping verteilt die Daten über mehrere Laufwerke und somit die Last auf mehr Hardware. Redundanz speichert die Daten mehrfach, sodass der Betrieb der Anwendung selbst bei Ausfall eines Laufwerks fortgesetzt werden kann. Die Leistungsfähigkeit eines einzelnen Laufwerks kann genauso wenig erhöht werden wie dessen Verfügbarkeit. Einzelne physische Laufwerke sind langsam und haben eine begrenzte Lebenszeit. Durch die geschickte Kombination von physischen Laufwerken ist es aber möglich, Verfügbarkeit und Leistung des Gesamtsystems deutlich zu erhöhen.

RAID-Arrays

Die von dem RAID-Controller zusammengefassten Bündel physischer Laufwerke bezeichnen wir als »RAID-Array« oder nur »Array«, wobei die Begriffsbildung in der Literatur hierzu nicht eindeutig ist. Manche Autoren verwenden stattdessen Begriffe wie »Stripe Set«, »Stripe Group« oder »RAID-Gruppe«. Andere Autoren wiederum bezeichnen mit RAID-Array das komplette Disksystem wie bei All-Flash Array (AFA). Wir verstehen unter einem RAID-Array immer eine Gruppierung von mehreren physischen Laufwerken.

Virtuelle Laufwerke

Die meisten RAID-Controller erlauben es, ein RAID-Array in mehrere virtuelle Laufwerke aufzuteilen und jedes virtuelle Laufwerk einem anderen Server zuzuweisen. In der nachfolgenden Beschreibung der verschiedenen RAID-Level (Abschnitt 2.2) zeigen wir jedoch eine 1:1-Zuordnung von virtuellen Laufwerken zu RAID-Arrays. Die Zuordnung von virtuellen Laufwerken zu RAID-Arrays ist für die Beschreibung der RAID-Level unerheblich, sodass wir diese zur Vereinfachung der Darstellung dort weglassen.

Server sehen virtuelle Laufwerke als normale physische Laufwerke

Ein Server, der an ein RAID-System angeschlossen ist, sieht nur virtuelle Laufwerke. Für ihn bleibt vollkommen verborgen, dass der RAID-Controller die virtuellen Laufwerke tatsächlich auf ein RAID-Array mit mehreren physischen Laufwerken verteilt (Abb. 2–7). Dies ist nur für den Administrator von außen sichtbar.

RAID-Level

Ein RAID-Controller kann die Daten, die ein Server auf das virtuelle Laufwerk schreibt, auf verschiedene Art und Weise auf die einzelnen physischen Laufwerke verteilen. Diese unterschiedlichen Verfahren werden als RAID-Verfahren oder als RAID-Level bezeichnet. Im folgenden Abschnitt 2.2 erläutern wir verschiedene RAID-Level im Detail.

Austausch eines defekten Laufwerks

Fast allen RAID-Leveln ist gemeinsam, dass sie redundante Informationen speichern. Fällt ein physisches Laufwerk aus, so können dessen Daten aus den Daten der verbleibenden intakten Laufwerke rekonstruiert werden. Das defekte Laufwerk kann bei entsprechender Hardware des Disksystems sogar im laufenden Betrieb durch ein neues ersetzt werden. Im Anschluss rekonstruiert der RAID-Controller die Daten des ausgetauschten physischen Laufwerks. Für den Server bleibt dieser Vorgang bis auf mögliche Leistungseinbußen verborgen: Er kann unterbrechungsfrei auf dem virtuellen Laufwerk weiterarbeiten.

Abb. 2–7Virtualisierung durch RAID

Der RAID-Controller kombiniert mehrere physische Laufwerke zu einem RAID-Array mit einem oder mehreren virtuellen Laufwerken. Der Server sieht nur die virtuellen Laufwerke. Der Controller verbirgt die Zuordnung der virtuellen Laufwerke zu RAID-Arrays und den entsprechenden physischen Laufwerken.

Automatische Wiederherstellung des Mirrors mit Hot-Spare-Disks

Moderne RAID-Controller stoßen die Rekonstruktion automatisch an. Dazu müssen sogenannte Hot-Spare-Disks (Ersatzlaufwerke, Abb. 2–8) beziehungsweise Hot-Spare-Kapazität (Abb. 2–20 auf S. 55) definiert werden. Hot-Spare-Disks werden im Normalbetrieb nicht genutzt. Fällt ein Laufwerk aus, so beginnt der RAID-Controller sofort, die Daten von den verbleibenden intakten Laufwerken zu rekonstruieren und auf eine Hot-Spare-Disk zu schreiben. Nach Austausch des defekten Laufwerks wird dieses in den Pool der Hot-Spare-Disks aufgenommen. Moderne RAID-Controller können für mehrere virtuelle RAID-Laufwerke einen gemeinsamen Pool an Hot-Spare-Disks verwalten. Hot-Spare-Disks können für alle RAID-Level definiert werden, die Redundanz bieten.

Abb. 2–8Austausch eines defekten physischen Laufwerks

Hot-Spare-Disk: Das Disksystem stellt dem Server zwei virtuelle Laufwerke bereit, für die eine gemeinsame Hot-Spare-Disk zur Verfügung steht (1). Der Server kann wegen der redundanten Datenspeicherung unter Leistungseinbußen auf den Daten weiterarbeiten, obwohl ein physisches Laufwerk ausgefallen ist (2). Der RAID-Controller stellt die Daten des defekten physischen Laufwerks auf der Hot-Spare-Disk wieder her (3). Nach dem Austausch des defekten Laufwerks steht wieder eine Hot-Spare-Disk zur Verfügung (4).

Priorität der Datenwiederherstellung

Die Wiederherstellung der Daten eines defekten physischen Laufwerks findet zur gleichen Zeit statt wie Schreib- und Leseoperationen des Servers auf dem entsprechenden virtuellen Laufwerk, sodass von Serverseite her zumindest Leistungseinbußen beobachtbar sind. Heutige Laufwerke sind mit Selbstdiagnoseprogrammen ausgestattet, die eine Zunahme an Schreib- und Lesefehlern frühzeitig an den Systemadministrator melden: »Achtung, ich bin kurz davor, das Zeitliche zu segnen. Bitte ersetze mich durch ein neues Laufwerk. Danke!« Die einzelnen Laufwerke speichern dazu die Daten mit einem redundanten Code wie dem Hamming Code. Der Hamming Code erlaubt die korrekte Wiederherstellung der Daten, selbst wenn auf dem Laufwerk einzelne Bits verändert werden. Bei entsprechender Pflege der Disksysteme kann man deshalb davon ausgehen, dass die installierten physischen Laufwerke noch eine Zeit lang halten. Deshalb ist in der Regel das Risiko akzeptabel, zugunsten einer höheren Leistung Zugriffe des Servers höher zu priorisieren als die Wiederherstellung der Daten eines ausgetauschten physischen Laufwerks. Moderne RAID-Level schützen die Daten mehrfach und vollziehen einen zweistufigen Rebuild, bei dem je nach Schwere des Ausfalls mal der Rebuild und mal die Zugriffe des Servers höher priorisiert werden (Distributed RAID, Abschnitt 2.2.8).

Nebeneffekt: höhere Kapazität der virtuellen Laufwerke

Ein weiterer Nebeneffekt der Zusammenfassung von mehreren physischen Laufwerken zu einem virtuellen Laufwerk ist die höhere Kapazität des virtuellen Laufwerks. Dadurch werden im I/O-Kanal weniger Geräteadressen verbraucht und somit die Verwaltung des Servers vereinfacht, weil dort nun mit weniger Laufwerken (Laufwerksbuchstaben beziehungsweise logischen Datenträgern oder Volumes) gearbeitet werden muss.

2.2Verschiedene RAID-Level im Detail

Auswahl der vorgestellten RAID-Level

Die RAID-Technik wird seit ihrer ursprünglichen Definition im Jahre 1988 kontinuierlich weiterentwickelt. Aufgrund des technischen Fortschritts sind einige RAID-Level heute praktisch bedeutungslos; andere wurden modifiziert oder nachträglich hinzugefügt. In diesem Abschnitt stellen wir die RAID-Level vor, die heute (2018) in der Praxis am bedeutendsten sind. Nicht vorgestellt werden RAID-Level, die herstellerspezifische Varianten darstellen, sowie Varianten, die die im Folgenden vorgestellten Grundformen nur minimal modifizieren.

2.2.1RAID 0: Blockweises Striping

RAID 0: blockweises Striping

RAID 0 verteilt die Daten, die der Server auf die virtuellen Laufwerke schreibt, blockweise auf ein physisches Laufwerk nach dem anderen (blockweises Striping). Abbildung 2–9 zeigt ein virtuelles Laufwerk mit vier physischen Laufwerken. In der Abbildung schreibt der Server nacheinander die Blöcke A, B, C, D, E usw. auf das virtuelle Laufwerk. Der RAID-Controller verteilt die Folge von Blöcken auf die einzelnen physischen Laufwerke: Er schreibt den ersten Block (Block A) auf das erste physische Laufwerk, den zweiten Block (Block B) auf das zweite, Block C auf das dritte und Block D auf das vierte. Danach beginnt er, wieder das erste physische Laufwerk zu beschreiben: Er schreibt Block E auf das erste Laufwerk, Block F auf das zweite und so weiter.

Abb. 2–9RAID 0 (Striping)

Der Server sieht wie bei allen RAID-Leveln nur virtuelle Laufwerke. Der RAID-Controller verteilt die Schreiboperationen des Servers auf mehrere physische Laufwerke. Durch das parallele Schreiben ist das virtuelle Laufwerk leistungsfähiger als die einzelnen physischen Laufwerke.

Leistungssteigerung durch parallele Festplattenzugriffe

RAID 0 wurde Ende der 1980er Jahre für Festplatten entwickelt. Es steigert die Leistung des virtuellen Laufwerks wie folgt: Die einzelnen physischen Laufwerke können über den I/O-Kanal mit dem RAID-Controller wesentlich schneller Daten austauschen, als sie diese auf die rotierende Scheibe schreiben beziehungsweise von ihr lesen können. In Abbildung 2–9 sendet der RAID-Controller den ersten Block (Block A) zur ersten Festplatte. Diese benötigt einige Zeit, um den Block auf die Festplatte zu schreiben. Während die erste Festplatte den ersten Block auf die physische Scheibe bringt, sendet der RAID-Controller bereits den zweiten Block (Block B) an die zweite Festplatte und Block C an die dritte Festplatte. Während dieser Zeit sind die beiden ersten physischen Festplatten noch damit beschäftigt, ihre jeweiligen Blöcke auf die physische Scheibe zu bringen. Wenn der RAID-Controller nun Block E an die erste Festplatte sendet, dann hat diese Block A zumindest zum Teil, wenn nicht sogar schon ganz auf die physische Scheibe geschrieben.

Rechenbeispiel für Leistungssteigerung

Im Beispiel konnte so im Jahr 2002 der Durchsatz ungefähr vervierfacht werden: Einzelne Festplatten erbrachten damals einen Durchsatz von etwa 50 MByte/s. Die vier physischen Festplatten erbrachten einen Gesamtdurchsatz von etwa 4 × 50 MByte/s = 200 MByte/s. Damalige I/O-Techniken wie SCSI oder Fibre Channel erreichten einen Durchsatz von 160 MByte/s beziehungsweise 200 MByte/s. Hätte das virtuelle Laufwerk nur aus drei physischen Festplatten bestanden, so wäre der Gesamtdurchsatz der Festplatten die limitierende Größe gewesen. Hätte dagegen das virtuelle Laufwerk aus fünf physischen Festplatten bestanden, so wäre der I/O-Pfad der limitierende Faktor gewesen. Bei fünf und mehr Festplatten waren also nur dann weitere Leistungssteigerungen möglich, wenn die Festplatten an verschiedenen I/O-Pfaden angeschlossen wurden, sodass die Last nicht nur über mehrere physische Festplatten, sondern auch über mehrere I/O-Pfade gestript werden konnte.

RAID 0: kein Ausfallschutz

RAID 0 steigert die Leistung des virtuellen Laufwerks, nicht aber dessen Verfügbarkeit. Fällt ein physisches Laufwerk aus, so sind alle Daten des virtuellen Laufwerks verloren. Genau genommen wird also das »R«=»Redundant« in RAID für RAID 0 zu Unrecht vergeben, vielmehr steht »RAID 0« für »null Redundanz«. Wegen des fehlenden Ausfallschutzes wird reines RAID 0 kaum eingesetzt.

2.2.2RAID 1: Blockweises Mirroring

RAID 1: blockweises Mirroring

Im Gegensatz zu RAID 0 steht bei RAID 1 die Verfügbarkeit im Vordergrund. Die Grundform von RAID 1 fasst zwei physische Laufwerke zu einem virtuellen Laufwerk zusammen, indem sie die Daten auf die beiden physischen Laufwerke spiegelt: Schreibt der Server einen Block auf das virtuelle Laufwerk, so schreibt der RAID-Controller diesen Block auf beide physischen Laufwerke (Abb. 2–10). Die einzelnen Kopien bezeichnet man auch als Mirror (Spiegel). Im Normalfall werden zwei, manchmal auch drei oder vier Kopien der Daten vorgehalten.

Nur geringe Leistungsveränderung

Im Normalbetrieb sind mit purem RAID 1 nur bei Leseoperationen Leistungssteigerungen möglich: Beim Lesen