Hochverfügbarkeitsstrategien auf Open-Source-Basis

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Motivation zu dieser Arbeit
1.2 Warum Open Source Software?
1.3 Allgemeine Voraussetzungen zur Arbeit
1.4 Konventionsvereinbarung

2 Grundlagen
2.1 Verfügbarkeit
2.1.1 Definition und Kennzahlen
2.1.2 Gründe der Nichtverfügbarkeit
2.1.3 Messverfahren
2.2 RAID
2.2.1 RAID Level
2.2.2 Datenverlust im RAID
2.2.3 Hardware-RAID
2.2.4 Software-RAID
2.3 DRBD
2.3.1 Funktionsweise
2.3.2 Installation
2.4 iSCSI
2.4.1 Funktionsweise
2.4.2 iSCSI-Target
2.4.3 iSCSI-Initiator
2.5 Cluster
2.5.1 Active-Passive Cluster
2.5.2 Active-Active Cluster
2.5.3 Load-Balanced Cluster
2.5.4 High Performance Cluster
2.6 Heartbeat
2.6.1 Funktionsweise
2.6.2 Installation
2.6.3 Konfiguration
2.6.4 Fehlerszenarien
2.7 Storage
2.7.1 SAN versus NAS
2.7.2 Storage-Based Mirroring
2.7.3 Host-Based Mirroring
2.7.4 Dateisysteme
2.8 Literaturkritik

3 Hochverfügbarkeitsszenarien
3.1 Hochverfügbare Speicherlösung
3.1.1 Funktionsweise Shared Storage
3.1.2 Konfiguration
3.2 Datenbank-Cluster mit MySQL
3.2.1 Failover mit Shared Storage
3.2.2 Redundanz durch Replikation
3.2.3 Network Database Cluster
3.3 Sichere Webanwendungen
3.3.1 Linux Virtual Server
3.3.2 Apache Webserver
3.4 Zusammenfassung

4 Fazit und Ausblick

A Konfigurationsdateien
A.1 DRBD drbd.conf
A.2 iSCSI initiatorname.iscsi
A.3 iSCSI ietd.conf
A.4 Heartbeat ha.cf
A.5 Heartbeat haresources
A.6 Heartbeat authkey
A.7 Heartbeat cib.xml
A.8 Apache lb.conf
A.9 Apache Module

Literaturverzeichnis

Stichwortverzeichnis

Abbildungsverzeichnis

2.1 Kennzahlen

2.2 Serielle Abhängigkeit

2.3 Zusätzliche Redundanz

2.4 Grad der Redundanz

2.5 RAID Level

2.6 RAID Level

2.7 RAID Level

2.8 RAID Level 1+

2.9 Funktionsweise DRBD

2.10 iSCSI Schema

2.11 Vergleich Overhead iSCSI zu FibreChannel

2.12 Active-Passive Cluster

2.13 Active-Active Cluster

2.14 Linux Heartbeat GUI

2.15 Zwangsabschaltung von Cluster-Knoten

2.16 Storage Based Mirroring

2.17 Host Based Mirroring

3.1 DRBD Failover Cluster

3.2 DRBD im Zusammenspiel mit iSCSI

3.3 MySQL Replikation

3.4 Network Database Cluster

3.5 Datenpartitionierung im NDB-Cluster

3.6 Linux Virtual Server

3.7 Apache Webserver als Reverse Proxy

3.8 Weboberfläche des Balancer Manager

3.9 Ebenen der Anwendungsbereitstellung

3.10 Absicherung mit mehreren USV

Tabellenverzeichnis

2.1 Verfügbarkeit in Zahlen bei 24x7 Betrieb

2.2 Vergleich RAID Level

2.3 Heartbeatkonfigurationsparameter

3.1 IP-Konfiguration SAN

3.2 DRBD Protokollversionen

3.3 Module für Apache

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

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 Techno- logien ist so hoch angesiedelt, wie es früher nur beim Telefonnetz der Fall war^[1].

Alles muss verfügbar sein, das Telefon, das Internet, die eigene Webpräsenz. Dienststellen der BOS Leitstellen (Behörden und Organisationen mit Sicherheits- aufgaben), wie Polizei und Feuerwehr, nutzen ebenfalls IT-Systeme, um ihr Per- sonal zu disponieren und die Vielzahl von angeschlossenen Subsystemen zu ver- walten. Zu diesen Subsystemen der Feuerwehr gehören unter anderem die Brand- meldeanlage, Funk, Telefon und Notruf sowie Gebäudeleittechnik und Fahrzeug- steuerung. 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.

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^[2] zu erfüllen. Die drei wichtigsten sind^[3]:

- 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 widerle- gen.

Zu den bekanntesten Beispielen der Open Source Software zählt der freie Datei- server Samba, der Linux-Computer in ein Microsoft Windows Netzwerk inte- griert.

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^[4] 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^[5], schnell entdeckt und behoben werden.

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 kom- plette Stadtverwaltung auf Linux und Open Source Software, wie das freie Ope- noffice, umstellt^[6].

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 Len- ny. Die meisten Befehle lassen sich 1 : 1 auf andere Distributionen übertragen. Gegebenenfalls sind vereinzelt Änderungen im Pfad vorzunehmen. Viele Distri- butionen, 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 darge- stellt. Um die Übersichtlichkeit zu wahren, sind hier einige Konvention verein- bart.

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

#>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

2.1 Verfügbarkeit

Verfügbarkeit ist die Wahrscheinlichkeit, ein System zu einem vorgegebenen Zeitpunkt in einem funktionsfähigen Zustand anzutreffen^[1].

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
- 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 zwi- schen der Wiederherstellung der Funktionsfähigkeit (MTTR) und einem erneuten Ausfall (MTBF)^[2].

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^[3]. Aus Gründen der Vereinfachung wird diese Zeit hier der MTTR zugrechnet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Kennzahlen im Zeitverlauf^[4]

Allgemein berechnet sich die Verfügbarkeit A nach der folgenden Formel^[5]:

Abbildung in dieser Leseprobe nicht enthalten

Umgekehrt lässt sich jetzt die Zeitspanne errechnen, wie lang das System durch schnittlich nicht funktionsfähig sein wird^[6].

Abbildung in dieser Leseprobe nicht enthalten

Oder als Dauerunverfügbarkeitsformel q ausgedrückt^[7]. MTTR

Abbildung in dieser Leseprobe nicht enthalten

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 betrach- tet.

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^[8].

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

Abbildung in dieser Leseprobe nicht enthalten

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

2.1.1.1 Bundesamt für Sicherheit in der Informationstechnik

Das Bundesamt für Sicherheit in der Informationstechnik, kurz BSI, ist der zen- trale IT-Dienstleister des Bundes und verantwortlich für dessen IT-Sicherheit^[11].

Mit dem IT-Grundschutz stellt das BSI ein Handbuch mit Empfehlungen zur Verfügung, wie ein System abgesichert werden kann^[12].

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

1. Übergreifende Aspekte
2. Infrastruktur
3. IT-Systeme
4. Netze
5. Anwendungen

Zusätzlich bietet das IT-Grundschutz-Handbuch zwei Kataloge, welche die Ge- fährdungspotentiale aufzeigen und erläutern welche Maßnahmen ergriffen wer- den 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^[13].

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-Grund- schutzes erreicht. Die Verfügbarkeitsklasse 2 für erhöhten Schutzbedarf kann er- reicht 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.

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 Zeit- spanne des Ausfalls alleine ausschlaggebend, sondern viel mehr dessen Aus- wirkung.

Die Verfügbarkeitsklassen benennt die Harvard Research Group als Availability Environment Classification (AEC). Nachfolgend sind die Beschreibungen der Availability Environment Classification aufgeführt^[14].

AEC-0 Conventional - Die Geschäftsfunktion kann unterbrochen werden. Die Datenintegrität ist nicht wichtig. Die Arbeit des Anwenders wird unterbro- chen. 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 oh- ne Datenverlust unterbrochen.

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

AEC-3 Fault Resilient - Die Geschäftsfunktion erfordert einen unterbrechungs- freien Betrieb innerhalb festgelegter Zeiten. Unter Umständen sind Trans- aktion zu wiederholen und die Performance kann verringert sein.

AEC-4 Fault Tolerant - Die Geschäftsfunktion erfordert einen unterbrechungs- freien 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 unterbrechungs- freien 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.

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 Com- merce (OGC) im Vereinigten Königreich in Zusammenarbeit mit vielen Unterneh- men erstellt. ITIL orientiert sich an sogenannten „Best Practise“ Lösungen^[15].

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^[16]. 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^[17].

Die Abgrenzung des Continuity Management zum Availability Management erfolgt anhand von nicht planbaren Ausfällen^[18]. 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^[19].

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^[20] der Funktion ohne Unterbrechung gewährleistet ist. Dies wird anhand eines Basiszeitraums festgemacht.

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^[21].

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

2.1.2 Gründe der Nichtverfügbarkeit

Der Zeitraum, in der das System nicht verfügbar ist, wird allgemein als Downti- me 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^[23]. 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 Be- triebssystemfehler (27 %) begründen, gefolgt von Hardwarefehlern (23 %). Wei- terhin werden Fehler durch Menschen (18 %) und Netzwerk (17 %) als Verursa- cher genannt^[24].

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

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^[26].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Serielle Abhängigkeit der Gesamtverfügbarkeit^[27]

Beispiel:

Es werden zwei Festplatten als RAID Level 0 verbunden; sie sind seriell voneinander 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 Einzel- komponenten erhöht werden. Dies geschieht beispielsweise durch die Verwen- dung eines RAID und einer doppelten Stromversorgung an zwei verschiedenen Energieversorgungen. Hierbei ergibt sich die Verfügbarkeit aus der nachstehen- den Formel^[28]:

Abbildung in dieser Leseprobe nicht enthalten

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 %.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Redundanz erhöht Gesamtverfügbarkeit^[29]

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.

Der Grad der Redundanz gibt an, wieviele Komponenten, die die Funktion erfül- len können, redundant sind^[30]. Die sogenannte n+k-Redundanz bezeichnet dabei, wieviele Komponenten des selben Typs für den Betrieb notwendig sind, und wel- che 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 je- doch mit eingesetzt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Grad der Redundanz^[31]

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^[32]. Im Sinne der Hochverfügbarkeit und Risikominimierung gilt es, solche SPoF zu vermeiden.

Sowohl die Überwachung der Verfügbarkeit des Systems als auch die Vorwar- nung vor einem möglichen Ausfall können durch ein Monitoring System ge- schehen. Das Monitoring System übernimmt die Überwachung des Gesamtsy- stems und der Einzelkomponenten. Ein Festplattenausfall lässt sich beispielswei- se durch Auswertung der SMART-Werte prognostizieren^[33]. SMART steht für eine selbstüberwachende Analyse- und Berichtstechnologie von Festplatten. Dadurch ist es dem Monitoring System (auch Network Monitoring System genannt) mög- lich, 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.

[...]

---

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

^[2] http://www.opensource.org

^[3] In Anlehnung an Müller[34].

^[4] Vgl. Studie von Netcraft[40].

^[5] Unter Backdoors sind Hintertüren im Software-Code zu verstehen, die einen ungewollten Zugang erlauben.

^[6] Vgl. Schießl[51].

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

^[2] Vgl. Troppens/Erkens/Müller[56], S. 383.

^[3] Vgl. Soltau[54], S. 17.

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

^[5] Vgl. Schwartzkopff[52], S. 4.

^[6] Vgl. Schwartzkopff[52], S. 4.

^[7] Vgl. Quade[42].

^[8] Vgl. BSI[11], S. 29.

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

^[10] In Anlehnung an BSI[12], S. 15.

^[11] Vgl. Helmbrecht[27].

^[12] Vgl. BSI[9].

^[13] Vgl. BSI[13].

^[14] Anm. d. A.: Originalquelle nicht mehr verfügbar, daher in Anlehnung an Brendel[7], S. 8 und Held[26].

^[15] Vgl. BSI[8], S. 58.

^[16] Vgl. van Bon et. al.[6].

^[17] Vgl. van Bon et. al.[6].

^[18] Vgl. Ritter[46], S. 15.

^[19] Vgl. Troppens/Wolafka[57], S. 118.

^[20] Vgl. Tanebaum[55], S. 410.

^[21] Vgl. van Bon et. al.[6].

^[22] Vgl. van Bon et. al.[6].

^[23] Vgl. Soltau[54], S. 14.

^[24] Vgl. Marcus/Stern[32], S. 15.

^[25] Vgl. Marcus/Stern[32], S. 15.

^[26] Vgl. Schwartzkopff[52], S. 6.

^[27] In Anlehnung an Brendel[7], S. 10.

^[28] Vgl. Schwartzkopff[52], S. 7.

^[29] In Anlehnung an Brendel[7], S. 11.

^[30] Vgl. BSI[14], S. 18f.

^[31] In Anlehnung an BSI[14], S. 19.

^[32] Vgl. Hein und Koehler[25], S. 40.

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