Abstract

This diploma thesis deals with high availibility specially on open source software. A short brief explained why using open source software. Availibilty and other operating figures will be defined. Measureplans to solve this problem were made by German Bundesamt fuer Sicherheit in der Informationstechnik and the IT infrastructure library. DRBD and iSCSI were used to realize a small prized storage attached network. Different kind of database clusters using MySQL. Heartbeat and Linux Virtual Server are needed for high availibility and loadbalancing. Some examples shows how to reach high availibility on low costs with open source software.

Inhaltsverzeichnis III

Inhaltsverzeichnis   

Abbildungsverzeichnis   V

Tabellenverzeichnis VI   

Abk  ürzungsverzeichnis  VII

1  Einleitung  1

1.1  Motivation zu dieser Arbeit  1

1.2  Warum Open Source Software?  2

1.3  Allgemeine Voraussetzungen zur Arbeit  3

1.4  Konventionsvereinbarung  3

2  Grundlagen  5

2.1  Verfügbarkeit  5

2.1.1  Definition und Kennzahlen  5

2.1.2  Gründe der Nichtverfügbarkeit  11

2.1.3  Messverfahren  12

2.2  RAID  14

2.2.1  RAID Level  14

2.2.2  Datenverlust im RAID  17

2.2.3  Hardware-RAID  21

2.2.4  Software-RAID  21

2.3  DRBD  22

2.3.1  Funktionsweise  23

2.3.2  Installation  24

2.4  iSCSI  25

2.4.1  Funktionsweise  25

2.4.2  iSCSI-Target  26

2.4.3  iSCSI-Initiator  27

2.5  Cluster  30

2.5.1  Active-Passive Cluster  31

2.5.2  Active-Active Cluster  32

2.5.3  Load-Balanced Cluster  33

2.5.4  High Performance Cluster  33

2.6  Heartbeat  34

2.6.1  Funktionsweise  34

2.6.2  Installation  34

2.6.3  Konfiguration  35

2.6.4  Fehlerszenarien  44

2.7  Storage  46

2.7.1  SAN versus NAS  47

Inhaltsverzeichnis IV

2.7.2  Storage-Based Mirroring  48

2.7.3  Host-Based Mirroring  49

2.7.4  Dateisysteme  49

2.8  Literaturkritik  50

3  Hochverfügbarkeitsszenarien  52

3.1  Hochverfügbare Speicherlösung  52

3.1.1  Funktionsweise Shared Storage  52

3.1.2  Konfiguration  54

3.2  Datenbank-Cluster mit MySQL  60

3.2.1  Failover mit Shared Storage  61

3.2.2  Redundanz durch Replikation  63

3.2.3  Network Database Cluster  66

3.3  Sichere Webanwendungen  68

3.3.1  Linux Virtual Server  69

3.3.2  Apache Webserver  72

3.4  Zusammenfassung  78

4  Fazit und Ausblick  81

A  Konfigurationsdateien  83

A.1  DRBD drbd.conf  83

A.2  iSCSI initiatorname.iscsi  83

A.3  iSCSI ietd.conf  83

A.4  Heartbeat ha.cf  85

A.5  Heartbeat haresources  86

A.6  Heartbeat authkey  86

A.7  Heartbeat cib.xml  86

A.8  Apache lb.conf  89

A.9  Apache Module  90

Literaturverzeichnis   92

Stichwortverzeichnis   98

Abbildungsverzeichnis V

Abbildungsverzeichnis

2.1 Kennzahlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Serielle Abhängigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Zusätzliche Redundanz . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Grad der Redundanz . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 RAID Level 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 RAID Level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.7 RAID Level 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.8 RAID Level 1+0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.9 Funktionsweise DRBD . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.10 iSCSI Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.11 Vergleich Overhead iSCSI zu FibreChannel . . . . . . . . . . . . . . 30

2.12 Active-Passive Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.13 Active-Active Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.14 Linux Heartbeat GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.15 Zwangsabschaltung von Cluster-Knoten . . . . . . . . . . . . . . . . 46

2.16 Storage Based Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.17 Host Based Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.1 DRBD Failover Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.2 DRBD im Zusammenspiel mit iSCSI . . . . . . . . . . . . . . . . . . 59

3.3 MySQL Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.4 Network Database Cluster . . . . . . . . . . . . . . . . . . . . . . . . 67

3.5 Datenpartitionierung im NDB-Cluster . . . . . . . . . . . . . . . . . 67

3.6 Linux Virtual Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.7 Apache Webserver als Reverse Proxy . . . . . . . . . . . . . . . . . . 72

3.8 Weboberfläche des Balancer Manager . . . . . . . . . . . . . . . . . 77

3.9 Ebenen der Anwendungsbereitstellung . . . . . . . . . . . . . . . . 78

3.10 Absicherung mit mehreren USV . . . . . . . . . . . . . . . . . . . . . 80

Tabellenverzeichnis VI

Tabellenverzeichnis

2.1 Verfügbarkeit in Zahlen bei 24x7 Betrieb . . . . . . . . . . . . . . . . 7

2.2 Vergleich RAID Level . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 Heartbeatkonfigurationsparameter . . . . . . . . . . . . . . . . . . . 36 3.1 IP-Konfiguration SAN . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.2 DRBD Protokollversionen . . . . . . . . . . . . . . . . . . . . . . . . 55

3.3 Module für Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Abkürzungsverzeichnis VII

Abkürzungsverzeichnis

AFR Annualized Failure Rate AJP Apache JServ Protocol ARP Address Resolution Protocol ATA Advanced Technology Attachment BER Bit Error Rate BOS Behörden und Organisationen mit Sicherheitsaufgaben BSI Bundesamt für Sicherheit in der Informationstechnik CIB Cluster Information Base

CIFS CRM DAS DNS DRBD Distributed Replicated Block Device FCP Fibre Channel Protocol FSTP Fast Spanning Tree Protocol FTP File Transfer Protocol GPL GNU General Public License

HA HPC HTTP ICMP iFCP IP Internet Protocol IPMI Intelligent Platform Management Interface iqn iSCSI Qualified Name iSCSI Internet SCSI ISO International Organization for Standardization IT Informations- und Telekommunikationstechnik LAN Local Area Network

LRM LUN LVM LVS MAC Media Access Control MAN Metropolitan Area Network

Abkürzungsverzeichnis VIII

MTBF Mean Time Between Failure MTFF Mean Time (To) Find Failure MTTDL Mean Time To Data Loss MTTF Mean Time To Failure MTTR NAS NAT NDB Network Database

NFS NIC OSI OSS PoH

RAC RAID RDBMS RSTP SAN SAS SATA Serial ATA

SCSI SLA SMART SMB SMTP SNMP SOAP SPOF SQL STONITH

STP TCP

TLD URL

USV WAN

XML XOR

1 Einleitung 1

1 Einleitung

Dieses erste Kapitel soll Aufschluss über die Motivation geben, sich mit diesem besonderem Thema zu beschäftigen. Es soll hier erläutert werden, warum Open Source Software eine wichtige Rolle spielt. Weiterhin erfolgt sowohl eine kurze Abgrenzung des Themas als auch Voraussetzungen zum besseren Verständnis dieser Ausarbeitung.

1.1 Motivation zu dieser Arbeit

In der heutigen Zeit sind IT-Systeme wichtiger denn je. Sie haben eine wichtige Stelle im privaten Umfeld, vor allem aber im geschäftlichen Umfeld eingenommen. Kritische Geschäftsprozesse werden heute mittels SOAP über das Internet abgewickelt. Menschen können 24 Stunden am Tag auf den eigenen Webshop zugreifen und ihre Bestellung absenden.

Dies war noch vor 20 Jahren undenkbar. Die Verfügbarkeit der heutigen Technologien ist so hoch angesiedelt, wie es früher nur beim Telefonnetz der Fall war ¹ . Alles muss verfügbar sein, das Telefon, das Internet, die eigene Webpräsenz. Dienststellen der BOS Leitstellen (Behörden und Organisationen mit Sicherheitsaufgaben), wie Polizei und Feuerwehr, nutzen ebenfalls IT-Systeme, um ihr Personal zu disponieren und die Vielzahl von angeschlossenen Subsystemen zu verwalten. Zu diesen Subsystemen der Feuerwehr gehören unter anderem die Brandmeldeanlage, Funk, Telefon und Notruf sowie Gebäudeleittechnik und Fahrzeugsteuerung. Gerade hier, wo es um jede Minute geht, um ein Menschenleben zu retten, gilt es, die Funktionsfähigkeit der Systeme stets zu gewährleisten. Um die Funktionsfähigkeit des Gesamtsystems sicherzustellen, ist es unabdingbar das System verfügbar zu halten.

Zur Veranschaulichung der Einsatzbereiche von Open Source Software in der Hochverfügbarkeit werden Beispiele gezeigt. Diese Beispiele umfassen die Bereiche Speichermanagement, Datenbank und Lastverteilung.

¹ Vgl. Römer/Peitzsch[47], S. 26.

1 Einleitung 2

1.2 Warum Open Source Software?

Bei Open Source Software handelt es sich per Definition um Software, deren Quellcode frei zur Verfügung steht.

Unter Open Source Software wird in der Regel kostenlose und lizenzfreie Software verstanden. Dies ist jedoch nicht der Fall. Open Source Software wird zwar nicht entgeltlich erworben, jedoch gilt für die meiste Open Source Software eine Lizenz. Die meistgenutzte Lizenz für Open Source Software ist die GNU GPL (GNU General Public License).

Damit eine Software als Open Source Software bezeichnet werden darf, sind zehn Kriterien gemäß der Open Source Initiative ² zu erfüllen. Die drei wichtigsten sind ³ :

∙ Kostenlose Weitergabe der Software ∙ Freier Zugang zum Quellcode auf Anfrage

∙ Veränderung am Quellcode folgen der gleichen Lizenz wie das Original Gerade bei den heutzutage recht engen Budgets, ist es einfacher und vor allem kostengünstiger Open Source Software zu verwenden. Aus diesem Grunde verbreitet sich Open Source Software auch recht schnell. Es kann vermutet werden, dass Software, welche nichts kostet auch genauso viel wert ist. Diese Ansicht lässt sich mit einigen Gegenbeispielen schnell widerlegen.

Zu den bekanntesten Beispielen der Open Source Software zählt der freie Dateiserver Samba, der Linux-Computer in ein Microsoft Windows Netzwerk integriert.

Das berühmteste und erfolgreichste Open Source Projekt ist der Webserver Apache. Der Apache gilt mit ca. 47 % Marktanteil im März 2009 laut Netcraft ⁴ als weitverbreitetster Webserver.

Viele Entwickler auf der ganzen Welt arbeiten an Open Source Projekten, um diese weiterzuentwickeln. Dadurch, dass sich viele Augen den Quellcode ansehen, können sowohl Fehler als auch versteckte Funktionen, wie Backdoors ⁵ , schnell entdeckt und behoben werden.

² http://www.opensource.org

³ In Anlehnung an Müller[34].

⁴ Vgl. Studie von Netcraft[40].

⁵ Unter Backdoors sind Hintertüren im Software-Code zu verstehen, die einen ungewollten Zu-

gang erlauben.

1 Einleitung 3

Selbst in Behörden wird vermehrt Open Source Software eingesetzt. Die Stadt München hat dabei die Rolle des Vorreiters eingenommen, in dem sie die komplette Stadtverwaltung auf Linux und Open Source Software, wie das freie Openoffice, umstellt ⁶ .

1.3 Allgemeine Voraussetzungen zur Arbeit

Diese Arbeit richtet sich vornehmlich an einen Leserkreis, der sich für das Thema der Hochverfügbarkeit interessiert. Die theoretische Grundlage zum vollständigen Verständnis dieser Ausarbeitung kann hier sowohl aus Platz- als auch aus Übersichtlichkeitsgründen nicht behandelt werden. Zum besseren Verständnis eignet sich Hintergrundwissen: ∙ zum ISO OSI 7-Schichten Modell ∙ zu TCP/IP ∙ zu SNMP ∙ zum Betriebssystem Linux ∙ zu Netzwerk-Bonding, Link Aggregation ∙ Spanning-Tree, RSTP

Die hier dargestellten Beispiele basieren auf einem GNU/Debian 5.0 alias Lenny. Die meisten Befehle lassen sich 1 : 1 auf andere Distributionen übertragen. Gegebenenfalls sind vereinzelt Änderungen im Pfad vorzunehmen. Viele Distributionen, wie die von SuSE, bringen auch einfach zu bedienende textliche und grafische Konfigurationswerkzeuge mit, die manuelle Anpassungen der Dateien nahezu obsolet machen.

1.4 Konventionsvereinbarung

In dieser Arbeit werden auszugsweise Programmausgaben und Befehle dargestellt. Um die Übersichtlichkeit zu wahren, sind hier einige Konvention vereinbart.

Befehlseingaben auf einer typischen Linux-Shell folgen einem Prompt, wie er hier dargestellt wird.

⁶ Vgl. Schießl[51].

1 Einleitung 4

#>apt-get update

Befehle innerhalb einer Datenbank werden wie folgt geschrieben. SQL>SELECT FIELDNAME FROM TABLENAME WHERE FIELDID=1;

Genauso abgesetzt vom Fliesstext, allerdings ohne Prompt sind Textausgabe bzw. Auszüge aus einer Datei.

Relevante Datei- und Verzeichnisnamen von zum Beispiel Konfigurationsdateien werden geneigt geschrieben. Beispiel: /dev/ -Verzeichnis Sonstige Hervorhebungen werden kursiv geschrieben. Beispiel: Initiator

2 Grundlagen 5

2 Grundlagen

2.1 Verfügbarkeit

Verfügbarkeit ist die Wahrscheinlichkeit, ein System zu einem vorgegebenen Zeitpunkt in einem funktionsfähigen Zustand anzutreffen ¹ . Die übrige Zeit ist der Zustand entweder nicht funktionsfähig oder unbekannt. Diese Wahrscheinlichkeit wird häufig in Dienstleistungsverträgen in der IT als Rahmenbedingung mitaufgenommen. Dies kann in verschiedenen Abstufungen erfolgen. Diese Abstufungen werden auch Service Level Agreement genannt.

2.1.1 Definition und Kennzahlen

Nach der Definition des Begriffs Verfügbarkeit (engl. Availibility, kurz A) sind in diesem Zusammenhang weitere Begriffe zu erläutern. Die meistbenutzte Größe, wenn man von Verfügbarkeit spricht, ist die MTBF (Mean Time Between Failure). Sie beschreibt die Zeit zwischen zwei aufeinander folgenden Ausfällen. Diese Angabe ist in den Datenblätter der meisten Hardwarekomponenten zu finden. Da dies aber nur statistische Werte sind, besagen sie nicht, wann der Ausfall tatsächlich eintreten wird. Die zweite wichtige Größe ist die MTTR (Mean Time To Repair). Sie beschreibt die durchschnittliche Zeitspanne, die verwendet wird, um die Funktionsfähigkeit nach einem Ausfall wiederherzustellen. Diese Kennzahl kann beeinflusst werden durch:

∙ Bereitstellung von Ersatzteilen vor Ort ∙ Bereitstellung von Ersatzteilen in der Nähe des Standorts ∙ 24 Stunden Bereitschaftsdienst

¹ Vgl. Hein/Köhler[25], S. 40.

2 Grundlagen 6

∙ Dauer der Fehleranalyse

Für jede Komponente, welche ausfallen könnte, ein Ersatzteil vorzuhalten ist weder wirtschaftlich noch sinnvoll. Zum einen werden hier große Lagerkapazitäten benötigt, des Weiteren ist das Kapital der Unternehmung gebunden und unterliegt dem Risiko des ständigen Technologiewandels. Die Kenngröße MTTF (Mean Time To Failure) ist die Differenz aus den beiden oben genannten Größen und beschreibt die durchschnittliche Zeitspanne zwischen der Wiederherstellung der Funktionsfähigkeit (MTTR) und einem erneuten Ausfall (MTBF) ² .

MTBF = MTTR + MTTF (2.1)

Die durchschnittliche Zeitspanne zur Wiederherstellung der Funktionsfähigkeit (MTTR) lässt sich weiter differenzieren in die durchschnittliche Zeitspanne, die benötigt wird, um den Fehler zu lokalisieren. Dies wird als MTFF (Mean Time (To) Find Failure) bezeichnet ³ . Aus Gründen der Vereinfachung wird diese Zeit hier der MTTR zugrechnet.

Allgemein berechnet sich die Verfügbarkeit A nach der folgenden Formel ⁵ :

Umgekehrt lässt sich jetzt die Zeitspanne errechnen, wie lang das System durch- ² Vgl.Troppens/Erkens/Müller[56], S. 383.

³ Vgl. Soltau[54], S. 17.

⁴ Angelehnt an Troppens/Erkens/Müller[56], S. 382.

⁵ Vgl. Schwartzkopff[52], S. 4.

2 Grundlagen 7

schnittlich nicht funktionsfähig sein wird ⁶ .

Ausszeit = (1 − A) ⋅ Basiszeitraum (2.3)

Oder als Dauerunverfügbarkeitsformel q ausgedrückt ⁷ .

Der Basiszeitraum ist die vereinbarte Zeit, in der das System funktionsfähig sein soll, beispielsweise zwischen 8:00 Uhr und 17:00 Uhr. In der Regel wird für den Basiszeitraum eine 24 Stunden Funktionsbereitschaft im kompletten Jahr betrachtet.

Um die Verfügbarkeit des gesamten Systems zu steigern gibt es zwei wesentliche Ansätze. Auf einer Seite kann die MTTF gesteigert werden und auf der anderen Seite sollte die MTTR reduziert werden ⁸ .

Tabelle 2.1: Verfügbarkeit in Zahlen bei 24x7 Betrieb

Verfügbarkeit Ausfallzeit pro Jahr ⁹ Ausfallzeit pro 30 Tage Klasse

100,000 %

Die Tabelle 2.1 zeigt, abhängig von der Verfügbarkeitsaussage, wie lang ein System nicht funktionsfähig sein darf. Ferner sind in der Tabelle die zugehörigen Verfügbarkeitsklassen nach BSI ¹⁰ aufgeführt, die im nächsten Abschnitt erläutert werden.

⁶ Vgl. Schwartzkopff[52], S. 4.

⁷ Vgl. Quade[42].

⁸ Vgl. BSI[11], S. 29.

⁹ Entspricht 365,2524 Tage, Vgl. Schwartzkopff[52], S. 2.

¹⁰ In Anlehnung an BSI[12], S. 15.

2 Grundlagen 8

2.1.1.1 Bundesamt für Sicherheit in der Informationstechnik

Das Bundesamt für Sicherheit in der Informationstechnik, kurz BSI, ist der zentrale IT-Dienstleister des Bundes und verantwortlich für dessen IT-Sicherheit ¹¹ . Mit dem IT-Grundschutz stellt das BSI ein Handbuch mit Empfehlungen zur Verfügung, wie ein System abgesichert werden kann ¹² .

Die Themen zur Absicherung werden in fünf Schichten eingeteilt. Diese Schichten sind:

1. Übergreifende Aspekte

2. Infrastruktur 3. IT-Systeme 4. Netze 5. Anwendungen

Zusätzlich bietet das IT-Grundschutz-Handbuch zwei Kataloge, welche die Gefährdungspotentiale aufzeigen und erläutern welche Maßnahmen ergriffen werden können.

Das Bundesministerium für Sicherheit in der Informationstechnik hat weiterhin ein Kompendium aus drei Bänden erstellt, welches sich speziell dem Thema der Hochverfügbarkeit widmet ¹³ .

Innerhalb des Hochverfügbarkeitskompedium wird die Abstufung der Verfügbarkeit in Klassen einsortiert.

Die Verfügbarkeitsklasse 0 stellt keine besonderen Anforderungen. Die Klasse 1 ist bei normalen Schutzbedarf durch Planung und Umsetzung des BSI IT-Grundschutzes erreicht. Die Verfügbarkeitsklasse 2 für erhöhten Schutzbedarf kann erreicht werden durch Umsetzung des BSI IT-Grundschutzes mit Elementen für hohe Verfügbarkeit. Ab Klasse 3 spricht man von hochverfügbar. Die weiteren Klassen stellen Anforderungen, wie sie unter anderem in dieser Arbeit behandelt werden.

¹¹ Vgl. Helmbrecht[27].

¹² Vgl. BSI[9].

¹³ Vgl. BSI[13].

2 Grundlagen 9

2.1.1.2 Harvard Research Group

Die Harvard Research Group (HRG) hat einen anderen Weg zur Klassifizierung der Verfügbarkeiten gewählt. Nach der Havard Research Group ist nicht die Zeitspanne des Ausfalls alleine ausschlaggebend, sondern viel mehr dessen Auswirkung.

Die Verfügbarkeitsklassen benennt die Harvard Research Group als Availability Environment Classification (AEC). Nachfolgend sind die Beschreibungen der Availability Environment Classification aufgeführt ¹⁴ .

AEC-0 Conventional - Die Geschäftsfunktion kann unterbrochen werden. Die Datenintegrität ist nicht wichtig. Die Arbeit des Anwenders wird unterbrochen. Es kann zu Datenverlusten kommen.

AEC-1 Highly Reliable - Die Geschäftsfunktion kann unterbrochen werden. Die Datenintegrität muss gewahrt bleiben. Die Arbeit des Anwenders wird ohne Datenverlust unterbrochen.

AEC-2 High Availability - Die Geschäftsfunktion erlaubt nur kurzzeitige oder geplante Unterbrechungen innerhalb festgelegter Zeiten. Die Arbeit des Anwenders stoppt, kann aber unmittelbar nach dem Ausfall fortgesetzt werden. Die Performance kann verringert sein.

AEC-3 Fault Resilient - Die Geschäftsfunktion erfordert einen unterbrechungsfreien Betrieb innerhalb festgelegter Zeiten. Unter Umständen sind Transaktion zu wiederholen und die Performance kann verringert sein. AEC-4 Fault Tolerant - Die Geschäftsfunktion erfordert einen unterbrechungsfreien Betrieb. Fehler sind für den Anwender transparent. Die Performance ist stetig und es gehen keine Transaktionen verloren.

AEC-5 Disaster Tolerant - Die Geschäftsfunktion erfordert einen unterbrechungsfreien Betrieb. Fehler sind für den Anwender transparent. Die Performance ist stetig und es gehen keine Transaktionen verloren. Dies gilt auch im Fall einer Katastrophe, wie zum Beispiel Feuer, Erdbeben und Stromausfall.

¹⁴ Anm. d. A.: Originalquelle nicht mehr verfügbar, daher in Anlehnung an Brendel[7], S. 8 und

Held[26].

2 Grundlagen 10

2.1.1.3 IT-Infrastructure Library

Die IT-Infrastructure Library (ITIL) ist eine Zusammenfassung von Büchern zum Thema IT-Service-Management. Sie wurde durch das Office Of Government Commerce (OGC) im Vereinigten Königreich in Zusammenarbeit mit vielen Unternehmen erstellt. ITIL orientiert sich an sogenannten „Best Practise“ Lösungen ¹⁵ . Die fünf Bücher der Kernpublikation sind: ∙ Service Strategy ∙ Service Design ∙ Service Transition ∙ Service Operation ∙ Continual Service Improvement

Im Service Design sind die Themengebiete Availibility Management und Continuity Management aufgeführt.

Das Availability Management beinhaltet die Vereinbarung der Verfügbarkeit gegenüber dem Vertragspartner. Um das Ziel der Verfügbarkeit zu erreichen, werden die passenden Mittel und Techniken eingesetzt ¹⁶ . Die Überwachung auf Störereignisse ist aus vertraglicher Sicht ebenfalls relevant, da hier die Ausfall-, Reaktions- und Wiederherstellungszeiten definiert sind.

Das Continuity Management dient zur schnellen Wiederherstellung der Funktion nach Notfällen ¹⁷ .

Die Abgrenzung des Continuity Management zum Availability Management erfolgt anhand von nicht planbaren Ausfällen ¹⁸ . Um den Geschäftsbetrieb aufrecht zu erhalten, gilt es bei Datensicherungen und Wartungsarbeiten weder die Verfügbarkeit der Anwendungen noch die der Daten zu stören ¹⁹ . Ferner definiert die IT-Infrastructure Library in diesem Zusammenhang noch drei weitere Anforderungen neben der Verfügbarkeit. Zuerst wird die Zuverlässigkeit eines Systems bzw. der Komponenten definiert. Diese Zuverlässigkeit gibt an, wie lange das Fortlaufen ²⁰ der Funktion ohne Unterbrechung gewährleistet ist. Dies wird anhand eines Basiszeitraums festgemacht.

¹⁵ Vgl. BSI[8], S. 58.

¹⁶ Vgl. van Bon et. al.[6].

¹⁷ Vgl. van Bon et. al.[6].

¹⁸ Vgl. Ritter[46], S. 15.

¹⁹ Vgl. Troppens/Wolafka[57], S. 118.

²⁰ Vgl. Tanebaum[55], S. 410.

2 Grundlagen 11

Des Weiteren wird gefordert, dass ein System wartbar sein soll. Dies bedeutet, dass vorbeugende Maßnahmen ergriffen werden, um den Betrieb bei Wartungsarbeiten aufrecht zu erhalten ²¹ .

Als letzte Anforderung wird die Servicefähigkeit genannt. Diese bezieht sich auf die vertragliche Gestaltung mit dem jeweiligen Dienstleister ²² .

2.1.2 Gründe der Nichtverfügbarkeit

Der Zeitraum, in der das System nicht verfügbar ist, wird allgemein als Downtime bezeichnet. Hier gibt es die Möglichkeit der geplanten und der ungeplanten Downtime.

2.1.2.1 Geplante Downtime

Die geplante Downtime ist die vorsätzliche Verringerung der Verfügbarkeit ²³ . Hierzu zählen das manuelle Herunterfahren des Systems, um eine neue Hardwarekomponente einzubauen und das Neustarten nach Einspielen eines Sicherheitspatches oder anderer Software.

2.1.2.2 Ungeplante Downtime

Während bei der geplanten Downtime in der Regel ein Mensch bei der Reduzierung der Verfügbarkeit involviert ist, ist dies bei der ungeplanten Downtime nicht der Fall. Die Ursachen für diese Nicht-Verfügbarkeit sind häufig ein Ausfall der Hardware-Komponenten im System.

In der Studie von Gartner/Dataquest lassen sich die meisten Ausfälle durch Betriebssystemfehler (27 %) begründen, gefolgt von Hardwarefehlern (23 %). Weiterhin werden Fehler durch Menschen (18 %) und Netzwerk (17 %) als Verursacher genannt ²⁴ .

Die Studie von CNT benennt hingegen das Versagen der Hardware (44 %) und menschliche Fehler (32 %) als Hauptursache für eine ungeplante Downtime ²⁵ .

²¹ Vgl. van Bon et. al.[6].

²² Vgl. van Bon et. al.[6].

²³ Vgl. Soltau[54], S. 14.

²⁴ Vgl. Marcus/Stern[32], S. 15.

²⁵ Vgl. Marcus/Stern[32], S. 15.

2 Grundlagen 12

2.1.3 Messverfahren

Die Verfügbarkeit eines Systems ist abhängig von ihren einzelnen Bestandteilen. Sie lässt sich als Produkt der Einzelverfügbarkeiten berechnen ²⁶ .

Beispiel:

Es werden zwei Festplatten als RAID Level 0 verbunden; sie sind seriell vonein-ander abhängig. Jede Festplatte hat eine Einzelverfügbarkeit von 90 %. Hieraus ergibt sich eine Gesamtverfügbarkeit für das RAID Level 0 von 81 %. Die Verfügbarkeit des Systems kann durch redundante Auslegung der Einzelkomponenten erhöht werden. Dies geschieht beispielsweise durch die Verwendung eines RAID und einer doppelten Stromversorgung an zwei verschiedenen Energieversorgungen. Hierbei ergibt sich die Verfügbarkeit aus der nachstehenden Formel ²⁸ :

A G = 1 − [(1 − (A 1 ) ⋅ (1 − A 2 ) ⋅ . . . ⋅ (1 − A n )] (2.6)

Beispiel:

Es werden zwei Festplatten als RAID Level 1 verbunden, d.h. die Festplatten sind vollredundant. Jede Festplatte hat eine Einzelverfügbarkeit von 90 %. Hieraus ergibt sich eine Gesamtverfügbarkeit für das RAID Level 1 von 99 %.

Wie das obige Beispiel zeigt, kann die Verfügbarkeit eines Systems durch Redundanz erheblich gesteigert werden. Dies bedingt allerdings erhöhte Kosten, da die Komponenten mehrfach vorhanden sein müssen.

²⁶ Vgl. Schwartzkopff[52], S. 6.

²⁷ In Anlehnung an Brendel[7], S. 10.

²⁸ Vgl. Schwartzkopff[52], S. 7.

²⁹ In Anlehnung an Brendel[7], S. 11.

2 Grundlagen 13

Der Grad der Redundanz gibt an, wieviele Komponenten, die die Funktion erfüllen können, redundant sind ³⁰ . Die sogenannte n+k-Redundanz bezeichnet dabei, wieviele Komponenten des selben Typs für den Betrieb notwendig sind, und welche zusätzliche Redundanz bieten. Die Abbildung 2.4 zeigt eine n+2 Redundanz. Die Komponenten K4 und K5 sind für den Betrieb nicht notwendig, können jedoch mit eingesetzt werden.

Die Einzelkomponenten, die im System nicht redundant vorhanden sind und von denen die Funktion des Systems abhängt, werden als Single Point of Failure (SPoF) bezeichnet ³² . Im Sinne der Hochverfügbarkeit und Risikominimierung gilt es, solche SPoF zu vermeiden.

Sowohl die Überwachung der Verfügbarkeit des Systems als auch die Vorwarnung vor einem möglichen Ausfall können durch ein Monitoring System geschehen. Das Monitoring System übernimmt die Überwachung des Gesamtsystems und der Einzelkomponenten. Ein Festplattenausfall lässt sich beispielsweise durch Auswertung der SMART-Werte prognostizieren ³³ . SMART steht für eine selbstüberwachende Analyse- und Berichtstechnologie von Festplatten. Dadurch ist es dem Monitoring System (auch Network Monitoring System genannt) möglich, eine Trendanalyse zu erstellen.

Im Open Source Bereich wird für diese Aufgabe meist Nagios eingesetzt. Mittels Agenten lassen sich hardwarenahe Daten der zu überwachenden Computer erhalten und auswerten. Bei dem Agenten handelt es sich um eine Software, welche auf dem Zielrechner läuft und eine vordefinierte Abfrage ausführt.

³⁰ Vgl. BSI[14], S. 18f.

³¹ In Anlehnung an BSI[14], S. 19.

³² Vgl. Hein und Koehler[25], S. 40.

³³ Vgl. Pinheiro/Weber/Barroso[41], S. 2.

2 Grundlagen 14

2.2 RAID

Um die Verfügbarkeit zu erhöhen ist in der Regel Redundanz erforderlich. Mehrere Systeme müssen doppelt oder mehrfach vorhanden sein. RAID-Systeme können diese erforderliche Redundanz liefern.

Ein RAID ist ein Verbund aus mehreren Festplatten. Der Verbund wird in der Regel als ein logisches Laufwerk dargestellt. Die Daten in diesem Verbund sind auf die zugehörigen Festplatten verteilt. Zusätzlich zu den Datenblöcken werden Prüfsummen verteilt auf den Festplatten gespeichert. Die Prüfsummen schaffen die Möglichkeit, bei Ausfall eines Datenblocks, die fehlenden Informationen zu errechnen.

RAID-Systeme sind heute aus Servern nicht mehr wegzudenken. Sie können den Ausfall eines Servers bei einer fehlerhaften Festplatte verhindern. Weitere Vorteile sind:

∙ Vergrößerung des Speicherplatzes

∙ Höhere Performance durch zeitglichen Zugriff auf mehreren Festplatten ∙ Ausfall einzelner Platten enden nicht im Totalausfall 34

2.2.1 RAID Level

Ein RAID lässt sich auf verschiedene Weise realisieren. Die einzelnen Varianten werden als Level bezeichnet. Jedes Level erstellt einen Verbund und sichert diesen mehr oder weniger vor einem Ausfall ab. Die Höhe des Levels hat nichts mit der Ausfallsicherheit zu tun. Sie dient lediglich zur Unterscheidung. Die wichtigsten RAID Level sind nachfolgend erläutert.

RAID 0 - Striping Beim Striping werden die Datenblöcke verteilt auf die im Verbund befindlichen Festplatten geschrieben. Durch die parallel angesprochenen Festplatten wird die Schreib- und Leseperformance erhöht. Per Definition ist RAID Level 0 kein RAID im eigentlichem Sinne, da die Daten nicht redundant vorgehalten werden.

³⁴ Sofern nicht RAID Level 0 eingesetzt wird.