Vorwort
Aufbau des Buchs
Die in diesem Buch verwendeten Konventionen
Danksagung
1. Einleitung
Hochverfügbarkeit
Was heißt »immer«?
Was heißt »Dienst«?
Gekoppelte Systeme
Serielle Kopplung
Parallele Kopplung und Redundanz
Komplexe zusammengesetzte Systeme
Linux Virtual Server (LVS)
Die Verteilung der Verbindungen
Weiterleitung per NAT
Weiterleitung durch direktes Routing
Weiterleitung per IP-Tunnel
Vor- und Nachteile von LVS
Linux-HA
2. Grundlagen
Theorie
Aufbau und Funktion
Split-Brain
Quorum
Fencing
Data Sharing
Linux-Cluster
Version 1
Version 2
Der CRM wird zu pacemaker
Änderungen an der Clusterkommunikation
heartbeat
OpenAIS
Fähigkeiten der Clustersoftware
Ein typischer Clusteraufbau
Terminologie
Architektur der Software
Komponenten der Software
Die Infrastruktur
Der Cluster-Manager
Ablauf
Die Pakete
Gemeinsam genutzte Daten
Die Zukunft der Clustersoftware
3. Installation und erste Konfiguration
Installation unter openSUSE
Installation unter Fedora
Installation unter RHEL, CentOS oder SLES
Installation unter Debian Squeeze
Installation unter Ubuntu
Ubuntu LTS
Installation aus dem Quelltext
cluster-glue
resource-agents
corosync
pacemaker
Die pacemaker-GUI
Eine Anfangskonfiguration mit heartbeat
Die Datei ha.cf
Konfiguration der Kommunikation im Cluster
authkeys
Eine Anfangskonfiguration mit corosync
Erste Eindrücke
heartbeat
Start mit corosync
Für die Ungeduldigen: ein Mini-Cluster
4. Ressourcen einrichten
XML – die Sprache der CIB
Die globalen Einstellungen der CIB
Knoten in der CIB
Einfache Ressourcen
Attribute
Globale Vorgaben
Operationen
Bedingungen
Anordnung (rsc_order)
Co-Lokation (rsc_colocation)
Platzierung (rsc_location)
Regeln
Das Punktesystem
Ressourcen für Fortgeschrittene
Gruppen
Klone
Multi-State-Ressourcen
Ressourcen migrieren
Bedingungen für Fortgeschrittene
Anordnungen von Bedingungen
Bedingungen im Zusammenhang mit Multi-State-Ressourcen
Bedingungen, die sich auf Knoten-Attribute beziehen
Zeitliche Vorgaben für Bedingungen
Erreichbarkeit im Netz
Frei definierbare Kriterien
Failover erst nach »N« Fehlern
Systemgesundheit
5. Verwaltung des Clusters
Die GUI
Start der GUI
Übersicht
Knoten
Management
Ressourcen
Einfache Ressourcen
Gruppen
Klone
Multi-State-Ressourcen
Bedingungen
Anordnungen
Co-Lokationen
Platzierungen
Der restlichen Schaltflächen
Die Befehle
crm_mon
Syntax
Optionen
Operationsmodi
Optionen zur Anzeige
Zusätzliche Optionen
cibadmin
Syntax
Operationen
Der Datenteil
Beispiele
crm_verify
Optionen
Beispiel
crm_resource
Queries
Kommandos
Befehle für Fortgeschrittene
Zusätzliche Optionen
Beispiele
crm_failcount
Syntax
Optionen
Kommandos
Zusätzliche Optionen
Beispiel
crm_standby
Syntax
Kommandos:
Beispiele
attrd_updater
Syntax
Optionen:
Kommandos
Beispiele
crm_attribute
Syntax
Optionen
Befehle
Zusätzliche Optionen
crm_diff
Syntax
Original-XML
Operationen
Zusätzliche Optionen
Beispiele
crm_shadow
Syntax
Queries
Befehle
Beispiele
ptest
Syntax
Optionen
Beispiele
Die Subshell zum CRM
Shell-Erweitung und Highlighting
Der Abschnitt node
Der Befehl cib
Der Befehl resource
Der Befehl ra
Der Befehl configure
Einfache Ressourcen: primitive
Gruppen: group
Klone: clone
Multi-State-Ressourcen: ms
Platzierungen: location
Co-Lokationen: colocation
Anordnungen: order
Clustereigenschaften: property
Überprüfung der Konfiguraion: show, verify und ptest
Überprüfung der Änderungen: show changed
Luxus: edit, delete und rename
Backup und Restore (save und load)
Anwendung
Java-GUI
High Availability Web Konsole (HAWK)
Installation unter SUSE
Andere Distributionen
Benutzung
Benutzerrechte
Zukunft
Master Control Process
Quorum-Dienst
Utilization
6. Planung, Aufbau und Betrieb
Technische Voraussetzungen
Hardware
Redundanz der Hardware
Software
Vorbereitung des Systems
Zeitabgleich
Planung
Aufbau und Tests
Betrieb
Fehlersuche
Upgrade
Shutdown
Rolling Upgrade
Disconnect und Reattach
Löschen und Austauschen von Knoten
Austausch defekter Knoten
STONITH
STONITH-Konfiguration
Eine weitere Applikation
logd
Weitere Hilfsprogramme
ptest
hb_report
Analyse
ocf-tester
Beispiele
corosync-cfgtool
7. Infrastruktur
Stromversorgung
Unterbrechungsfreie Stromversorgung (USV)
Netzwerkanbindung
Zwei Netzwerkkarten
Überwachung der Schnittstellen
miimon
arping
Beispiel
Virtueller Port-Channel mit Cisco Nexus
Layer 3
Plattenspeicher
RAID
Direct Attached Storage
Network Attached Storage
Storage Attached Network
Fiber Channel
iSCSI
Multipath
Überwachung
8. Agenten
init-Skripte (LSB-kompatibel)
OCF-Agenten
Aktionen von OCF-Agenten
Parameter
Debuggen von OCF-RAs
anything
AoEtarget (ATA over Ethernet)
Parameter
Beschreibung
apache
Parameter
Beschreibung
asterisk
Parameter
AudibleAlarm
Parameter
ClusterMon
Parameter
conntrackd
Parameter
CTDB
db2
Parameter
Delay
Parameter
drbd
Parameter
Anwendung
Dummy
Parameter
eDir88
Parameter
ethmonitor
Evmsd
Parameter
EvmsSCC
Parameter
exportfs
Parameter
Filesystem
Parameter
fio
ICP
Parameter
ids
Parameter
IPaddr
Parameter
IPaddr2
Parameter
Load-Sharing-Cluster
IPsrcaddr
Parameter
iscsi
Parameter
iSCSILogicalUnit
Parameter
iSCSITarget
Parameter
jboss
ldirectord
Parameter
LinuxSCSI
Parameter
LVM
Parameter
lxc
Parameter
MailTo
Parameter
ManageRAID
Parameter
ManageVE
Parameter
mysql
Parameter
mysql-proxy
Parameter
nfsserver
nginx
oracle
Parameter
oralsnr
Parameter
pgsql
Parameter
ping
Parameter
portblock
Parameter
postfix
Parameter
proftpd
Parameter
Pure-FTPd
Parameter
Raid1
Parameter
Route
Parameter
rsyncd
Parameter
SAPInstance
Parameter
Beispiel
SAPDatabase
Parameter
Beispiel
scsi2reservation
SendArp
Parameter
ServeRAID
Parameter
sfex
Parameter
slapd
SphinxSearchDaemon
Parameter
Squid
Parameter
Stateful
Parameter
SysInfo
Parameter
Beschreibung
syslog-ng
tomcat
Parameter
Varnish
VIPArip
Parameter
VirtualDomain
Parameter
vmware
Parameter
WAS
Parameter
WAS6
Parameter
WinPopup
Parameter
Xen
Parameter
Xinetd
Parameter
OCF-Agenten von pacemaker
ClusterMon
controld
Parameter
HealthCPU
Parameter
HealthSMART
Parameter
Sonstige OCF-Agenten
Eigene OCF-Agenten
STONITH-Agenten
Syntax
Optionen
Parameter
apcmaster
apcmastersnmp
apcsmart
baytech
bladehpi
cyclades
drac3
external/drac5
external/dracmc-telnet
external/hmchttp
external/ibmrsa
external/ibmrsa-telnet
external/ipmi
external/ippower9258
external/kdumpcheck
external/libvirt
external/nut
external/rackpdu
external/riloe
external/sbd
external/ssh
external/vmware
external/xen0
external/xen0-ha
ibmhmc
ipmilan
meatware
nw_rpc100s
rcd_serial
rps10
suicide
wti_mpc
wti_nps
Beispiele
Der external/ssh-Agent
Der IBMHMC-Agent
9. Beispielszenarien
Die Nutzung von DRBDs
Installation von DRBD
Konfiguration und Tests
DRBDs im Cluster
Rettung nach einem Problem
Automatisches Recovery
DRBD: Konfiguration für Fortgeschrittene
Ein neue Konfiguration
Fehlersuche
Anwendung: Ein hochverfügbarer NFS-Server
Clusterkonfiguration
Einbau im Cluster
NFSv4
NFSv4 und Kerberos
Anwendung: iSCSI-Targets
Der iSCSI-Client
Das LIO-Target
Virtuelle Rechner als Clusterressource
Installation von KVM und libvirt
Clustern des Rechners
Überwachung der virtuellen Rechner
Live-Migration
Eine hochverfügbare Firewall mit VPN-Endpunkt
Grundsystem
Netzwerk
Das Betriebssystem
Die Firewall im Cluster
Firewall mit fwbuilder
Der Regelsatz
Abgleich der Verbindungstabellen
VPN
IPsec mit OpenS/WAN
OpenVPN
Die komplette Firewall-Konfiguration
Synchronisation der Konfiguration
10. Linux Virtual Server
Der LVS-Director als Ressource unter pacemaker
Das Kernelmodul
Start durch init
Die Konfiguration von ldirectord
Dynamische Änderungen
Der ldirectord als Ressource im Cluster
Die Cluster-IP-Adressen
Das Director als Applikationsserver
Die Konfiguration im Netzwerk
Die Director
Die Clusterkonfiguration
11. Überwachung und Sicherheit
Überwachung
Ein kurzer Exkurs über SNMP
Der SNMP-Subagent von Linux-HA
Quick-and-dirty-SNMP
nagios und das SNMP-Plug-in
Überwachung des Clusters per SNMP
Überwachung des Fehlerzählers
SNMP-Traps von crm_mon
Sicherheit
Clusterkommunikation
GUI
Zugangskontrolle
A. Die Konfigurationsdateien
Die Konfiguration von heartbeat in ha.cf
Die Konfiguration von corosync
B. Über die Autoren
Stichwortverzeichnis
Kolophon
Impressum
Hochverfügbarkeit ist eine inzwischen ganz übliche und wichtige Anforderung an die IT-Abteilung oder den Dienstleister, der im Kundenauftrag ein neues System plant und aufbaut. Dieses Buch soll den Administratoren, Planern und dem Betrieb einen Leitfaden an die Hand geben, um dieser Anforderung mithilfe der Clustersoftware aus entsprechenden Projekten der Open-Source-Community gerecht zu werden.
Der Leser soll nach der Lektüre dieses Buchs in der Lage sein, solche Clustersysteme so zu entwerfen, aufzubauen und zu betreiben, dass eine Verfügbarkeit von 99,99 % oder mehr kein schönes Versprechen ist, sondern eine belastbare Zahl, die in Vereinbarungen mit Kunden überprüft werden kann. Außerdem kann der Referenzteil dieses Buchs immer wieder Verwendung als Nachschlagewerk finden.
Viele Administratoren setzen die Version 1 von heartbeat
noch heute ein und sind bisher vor der scheinbar komplexen Konfiguration mit pacemaker
zurückgeschreckt, weil sie dort ihre einfachen Konfigurationsdateien vermissen. Diesen Administratoren soll das vorliegende Werk helfen, den ersten Schritt zu einer Konfiguration mit dem neuen Cluster-Manager zu wagen. Es wird sich nämlich zeigen, dass man die Einstellungen auch hier in Dateien mittels einer einfachen Skriptsprache erstellt und der Administrator somit weiterhin die volle Kontrolle über den Cluster behält. Auch soll dieses Buch dabei helfen, diverse Missverständnisse im Hinblick auf den Übergang von Linux-HA mit heartbeat
hin zu pacemaker
mit corosync
auszuräumen. In Kapitel 2, wird sich zeigen, dass sich die Verwaltung im Cluster aus dem Manager von heartbeat
entwickelt hat.
Die Motivation, dieses Buch zu schreiben, ergab sich für mich aus der schieren Notwendigkeit, selbst solche Cluster zu entwerfen und zu betreiben. Ein Großteil der verfügbaren Dokumentationen und Beispielkonfigurationen im Internet bezog sich allerdings auf die Version 1 der Software, und die entsprechenden Beschreibungen für Version 2 waren noch nicht so ausgereift, wie ich mir sie gewünscht hätte. Da die Möglichkeiten, die die Nachfolgepakete bieten, aber so interessant sind, ergab sich aus der Projektdokumentation erst ein kleinerer Artikel, der sich dann zu einem ganzen Buch entwickelte. Ich hoffe, mit diesem Buch nun die durchgehende Dokumentation liefern zu können, die notwendig ist, um alle Feinheiten von pacemaker
zu nutzen.
Clusterbau ist eine hohe Kunst, vor allem wenn der Cluster auch in nicht vorhergesehenen kritischen Situationen seinen Dienst ohne Unterbrechung verrichten soll. Deshalb werden an den Leser keine geringen Ansprüche gestellt. Natürlich sollte er sich im Netzwerk hinreichend auskennen und mit tcpdump
umgehen können, um auf dieser Ebene einen Fehler finden zu können. Zudem sollte er mit der Applikation, die sein Cluster hochverfügbar im Netz anbieten soll, ebenfalls gut vertraut sein. Nur ein gutes Verständnis von den Applikationen bietet die Grundlage, diese Anwendung auch im Cluster zum Leben zu erwecken. Gerade bei Applikationen, die Benutzerdaten dynamisch verwalten, also bei denen diese Daten auf alle Knoten des Clusters repliziert werden müssen, ist dieser Überblick notwendig, damit es nicht zum GAU des totalen Datenverlusts kommt. Aber damit wird natürlich nicht vorausgesetzt, dass der Leser jede der beschriebenen Applikationen beherrscht. Nicht zuletzt kann man auch die Kunst, ein Logfile richtig zu lesen und zu interpretieren, nicht hoch genug einschätzen.
In der 3. Auflage des Buchs ist ein eigenes Kapitel für die Infrastruktur um einen Cluster herum dazugekommen. Es reicht nicht, wenn der Computercluster zwar die hohe Verfügbarkeit bietet, aber die Umgebung noch einige Schwachstellen aufweist. So soll dieses Kapitel dem Administrator helfen, auch diese Probleme anzugehen.
Ich habe versucht, die trockene Theorie von Ressourcen und Bedingungen mit Beispielen so weit wie möglich aufzulockern. Da diese Theorie jedoch notwendig ist, mag es mir nicht überall gelungen sein. Es lassen sich außerdem nicht alle Situationen und Probleme mit Beispielen abdecken – ich hoffe allerdings, dass ein tiefes Verständnis der vermittelten Grundlagen den Administrator befähigt, seine speziellen Aufgaben erfolgreich zu lösen.
Aus diesem Grund habe ich folgende Struktur für das Buch gewählt:
In Kapitel 1, werden die Grundlagen der Theorie von Hochverfügbarkeit dargestellt und dem Planer die Mittel an die Hand gegeben, die Verfügbarkeit eines komplexen Systems zu berechnen, indem er es in einfache Einheiten zerlegt. Am Ende des Kapitels stelle ich die zwei bekanntesten Projekte zur Hochverfügbarkeit vor.
Kapitel 2, beschreibt allgemein die Funktionsweise von Clustern und welche Probleme neu auftreten, die es bei Einzelsystemen nicht gibt. Zu nennen ist hier vor allem der eventuell notwendige Datenaustausch zwischen den Knoten eines Clusters. Dazu werden die Lösungen, die die Clustersoftware für die einzelnen Probleme bietet, dargestellt. Der zweite Teil des Kapitels beschreibt die interne Architektur des Programmpakets, die Bedeutung und das Zusammenspiel der einzelnen Server, die notwendig sind, um die hohe Verfügbarkeit zu erreichen.
In Kapitel 3, wird die Installation der Software auf den gängigsten Linux-Distributionen erklärt. Der Administrator, der die volle Kontrolle über das Programmpaket haben will, erfährt im Anschluss, wie er den Quellcode selbst übersetzen kann. Eine Anfangskonfiguration, der erste Programmstart und die Konfiguration einer Ressource bilden den Abschluss dieses Kapitels. Beim Schreiben des Abschnitts über die Konfiguration der ersten Ressource habe ich den ungeduldigen Administrator vor Augen gehabt. Deshalb erfolgt die Konfiguration an dieser Stelle ohne Erläuterung der Grundlagen. Methodisch veranlagte Leser mögen mir diesen Abschnitt bitte verzeihen und können ihn überspringen.
Kapitel 4, liefert die Grundlagen zu Ressourcen und Bedingungen. In den ersten Versionen des Buchs war dieses Kapitel relativ theoretisch gehalten, aber meine Lektorin hat mich überzeugt, den Stoff mit reichlich Beispielen aufzulockern. Diese Teile, die immer den gerade besprochenen Aspekt der Konfiguration noch einmal verdeutlichen, bilden keine komplette Konfiguration, die sofort ausprobiert werden soll. Vielmehr sind diese Beispiele kleine Abschnitte, die der Leser später zur Konfiguration seines eigenen Projekts verwenden kann. Komplette Konfigurationen stelle ich im Kapitel 9, weiter unten vor.
Kapitel 5, enthält die Beschreibung der verschiedenen Werkzeuge, die dem Administrator zu Verfügung stehen, angefangen bei der GUI. Nachdem der Leser im vorhergehenden Kapitel die textbasierte Konfiguration kennengelernt hat, kann er hier viele Aspekte grafisch konfigurieren. Den zweiten Abschnitt des Kapitels bilden die Werkzeuge der Kommandozeile. Mithilfe dieser Werkzeuge können die oben vorgestellten Konfigurationsschnipsel eingegeben werden – nun haben wir alles zusammen, was wir brauchen, um loslegen zu können.
Nachdem in den vorherigen Kapiteln die Grundlagen der Clustersoftware besprochen wurden, kann der Leser mithilfe der Ratschläge aus Kapitel 6, sein eigenes Projekt planen, umsetzen und betreiben. Hier erhält der Administrator die Mittel, seinen Aufbau zu testen und bei Problemen die Ursachen der Fehler zu suchen.
Das nächste Kapitel, Kapitel 7, beschreibt die Infrastruktur, in der sich ein Cluster richtig wohlfühlt. Nur wenn die Umgebung auch die hohe Verfügbarkeit bietet, können Server und Software ihre Arbeit verrichten.
Sogenannte Agenten bilden die Schnittstelle zwischen der Clustersoftware und den eigentlichen Applikationen. In Kapitel 8, werden die einzelnen Arten detailliert besprochen. Alle Agenten, die in der Software des Projekts enthalten sind, werden individuell behandelt.
In Kapitel 9, werden mit den bisher besprochenen Werkzeugen die Konfigurationen folgender Anwendungsfälle vollständig erklärt:
Distributed Redundant Block Devices (DRBD) als eine Grundlage der Datenspeicherung im Cluster.
Die DRBDs finden Anwendung in einem NFSv4-Dateiserver und einem iSCSISAN.
Ein Cluster als Basis für virtuelle Rechner, die im Fehlerfall als komplette Einheit auf den anderen Knoten verschoben werden.
Eine redundant aufgebaute Firewall, die im Fehlerfall die Tabelle der bestehenden Verbindungen mit übernehmen kann und somit eine echte Hochverfügbarkeit bietet. Die zwei VPN-Lösungen, die am weitesten verbreitet sind (OpenVPN und OpenS/WAN), werden im Rahmen dieses Beispiels mit einbezogen.
Das vorletzte Kapitel 10, beschreibt die Kombination von Linux-HA mit der Software des Linux Virtual Server (LVS), sodass ein hochverfügbarer, also hoch skalierbarer Servercluster aufgebaut werden kann. Da dieses Beispiel ein bisschen ausführlicher auf die Aspekte von LVS eingeht, habe ich hier ein eigenes Kapitel eingefügt.
Kapitel 11, beschäftigt sich abschließend mit der optimalen Überwachung des Clusters und einigen Sicherheitsaspekten, die im Betrieb zu beachten sind.
Im Anhang A werden alle Optionen der zentralen Konfigurationsdatei ha.cf von heartbeat
bzw. corosync.conf aufgeführt und einzeln erklärt.
An dieser Stelle möchte ich den Lesern viel Vergnügen bei der Lektüre und viel Erfolg bei der Umsetzung der eigenen Projekte wünschen!
In diesem Buch werden die folgenden typografischen Konventionen verwendet:
Nichtproportionalschrift
Wird innerhalb der Textabschnitte für Programmelemente wie Variablen- oder Funktionsnamen und für Programmlistings benutzt. Konfigurationsbeispiele, die einen Teil der Konfiguration eines Clusters darstellen, sind ebenfalls in dieser Schrift gesetzt.
Nichtproportionalschrift kursiv
Wird verwendet, um variable Eingaben anzuzeigen. Sie sollten sie durch einen Wert Ihrer eigenen Wahl ersetzen.
Wird für URLs, Hostnamen, Namen von Verzeichnissen und Dateien, und gelegentlich zur Hervorhebung eingesetzt.
Befehle werden oft mit einem Prompt dargestellt, um zu erläutern, in welchem Kontext sie verwendet werden. Unix-Benutzer sind es gewohnt, diesen Prompt zu sehen. Da Sie die meisten Befehle als root-Benutzer ausführen müssen, ist der Prompt durchgängig »#«.
Dieses Icon zeigt einen Tipp, einen Vorschlag oder eine allgemeine Bemerkung an.
Die Falle kennzeichnet eine Warnung oder ein Thema, bei dem man Vorsicht walten lassen sollte.
Für die Geduld, die meine Familie während der Zeit aufgebracht hat, in der ich an diesem Buch gearbeitet habe, möchte ich mich ganz herzlich bedanken: Danke Julia, Mark und Peter!
Die Hilfe bei Nachfragen und die Kontrolle des Texts durch Lars Marowsky-Brée und Andrew Beekhof war sehr hilfreich und hat viele Missverständnisse ausgeräumt. Deshalb an dieser Stelle auch noch mal ein herzliches Danke nicht nur für die Arbeit an der Software, sondern auch für die Hilfestellung beim Einsatz der Programme.
Von der modernen Informationstechnik wird erwartet, dass alle Dienste immer verfügbar sind. Ein Reisebüro will seine Flüge 24 Stunden am Tag anbieten, und der zentrale SAP-Server der Firma muss ebenfalls immer weltweit erreichbar sein. Aber was heißt »immer«? Und wie definiert sich »Dienst« genau? Was hat es mit der oft zitierten Verfügbarkeit von 99,99 % auf sich?
In dieser Einleitung werden die Grundbegriffe zur Hochverfügbarkeit eingeführt und die bekanntesten Projekte unter Linux vorgestellt. Mit einfachen Berechnungsmethoden kann ein IT-Architekt die Verfügbarkeit von einfachen und zusammengesetzten, komplexen Systemen vorhersagen und ihre Schwachstellen identifizieren, bevor Fehler auftreten. Sind diese Fragen geklärt, stellt sich für den Software-, Hardware- und Netzwerkarchitekten noch das Problem, wie er die Vorgaben mit dem immer zu knappen Budget erreicht.
Lassen Sie uns mit den eingangs aufgeworfenen Fragen beginnen.
»Immer« heißt »zu jedem Zeitpunkt«. Wenn jemand einen Dienst anbietet, dann also zu jedem einzelnen Zeitpunkt. Aber wie lange dauert der Zeitpunkt? Und wie lange will der »Kunde« den Dienst nutzen? Das hängt natürlich von der Art des Diensts und von der Vereinbarung ab, die mit dem Kunden getroffen wurde. Es ist einfach, einen Dienst für die einmalige Nutzung für eine Sekunde anzubieten. Die Wahrscheinlichkeit, dass das, was den Dienst erbringt, genau zu diesem Zeitpunkt versagt, ist relativ gering. Aber in der Informationstechnik wollen die Kunden die Dienste 24 Stunden am Tag an 7 Tagen die Woche oder genauer gesagt an 365,2425 Tagen pro Jahr[1] nutzen. Deshalb ist es ebenso wichtig, zu vereinbaren, für welchen Zeitraum der Dienst erbracht werden soll. Üblicherweise beziehen sich die Angaben von Verfügbarkeit auf Zeiträume von einem Monat oder einem Jahr.
Am besten sieht man das, wenn man ein Beispiel durchrechnet: Der Anbieter will einen Dienst mit einer gewissen Verfügbarkeit A anbieten. Daraus kann man einfach folgende Tabelle 1.1 errechnen:
Tabelle 1.1 Verfügbarkeit und Auszeit pro Monat bzw. Jahr. Eine Verfügbarkeit von 99,99 % bedeutet zum Beispiel, dass der Dienst pro Jahr maximal knapp eine Stunde nicht verfügbar ist.
Verfügbarkeit | Auszeit pro Monat[a] | Auszeit pro Jahr |
---|---|---|
99,0 % | 7,2 h | 87,66 h |
99,5 % | 3,6 h | 43,83 h |
99,9 % | 0,72 h | 8,77 h |
99,99 % | 4,32 min | 52,59 min |
99,999 % | 0,43 min | 5,26 min |
[a] Ein Monat wird hier der Einfachheit halber mit 30 Tagen angesetzt. |
Damit ist aber noch nicht festgelegt, wann diese Auszeiten auftreten und wie lange sie maximal dauern dürfen. Bei der Angabe einer Verfügbarkeit von 99,5 % bezogen auf den Basiszeitraum »ein Jahr« kann eine einzelne Störung eben doch über 40 Stunden (also fast zwei Tage) dauern, wenn sonst keine weitere Störung in diesem Jahr auftritt. Die mittlere Zeit bis zur Störungsbehebung (engl. Mean Time To Repair, MTTR) ist deshalb auch eine wichtige Größe, die in einer Servicevereinbarung (Service Level Agreement, SLA) ebenfalls festgehalten werden sollte. Aus Kundensicht wäre allerdings eine Vereinbarung der maximalen Zeit zur Behebung der Störung wünschenswert.
In der folgenden Tabelle 1.2 sind Größenordnungen der MTTR für einen Ausfall der Hardware dargestellt – in Abhängigkeit vom Betriebsaufwand, mit dem man den Dienst betreibt.
Sie zeigt, dass die Wiederherstellungszeit klar von den Kosten für den Betrieb abhängt. Dasselbe gilt für Ausfälle, die durch Softwarefehler verursacht werden: Je mehr Aufwand in den Betrieb investiert wird, desto geringer ist die mittlere Zeit bis zum Wiederanlaufen des Diensts (siehe Tabelle 1.3).
Tabelle 1.2 Größenordnungen für die Wiederherstellungszeit eines Diensts beim Ausfall einer Hardwarekomponente in unterschiedlichen Betriebskonzepten. Je aufwendiger der Betrieb gestaltet wird, desto kürzer ist auch die Zeit bis zum Neustart des Diensts.
Ersatzteile | Personal | Größenordnung für die MTTR |
---|---|---|
Vor Ort | 24 h/Tag | 30 Minuten |
Vor Ort | Rufbereitschaft | 2 Stunden |
Vor Ort | Normale Arbeitszeit | 3 Tage (Wochenende!) |
Kurierdienst | Rufbereitschaft | 1 Woche |
Kurierdienst | Techniker wird bestellt | 2 Wochen |
Das schnelle Wiederanlaufen des Diensts wird in Tabelle 1.3 durch automatisierte Systeme zur Erkennung des Fehlerfalls und zur Problembehebung durch Neustart erreicht.
Tabelle 1.3 Größenordnungen für die Wiederherstellungszeit eines Diensts bei einem Fehler der Software. Nur wenn Problemdiagnose und -behebung automatisiert sind, lassen sich wirklich kurze Zeiten erreichen.
Mechanismus zur Fehlererkennung | Mechanismus für den Neustart | Größenordnung der MTTR |
---|---|---|
Monitoring-System | Automatischer Neustart von ROM-Abbild | 30 Sekunden |
Monitoring-System | Automatischer Neustart des Diensts ohne Neustart des Systems | 30 Sekunden |
Monitoring-System | Automatischer Neustart des gesamten Systems | 3 Minuten |
Monitoring-System | Automatischer Neustart des Systems und Wiederherstellung durch Herunterladen von einem Zentralsystem | 10 Minuten |
Keine automatische Fehlererkennung | Manueller Neustart | min. 30 Minuten |
Noch eine wichtige Größe in diesem Zusammenhang ist die mittlere Zeit zwischen zwei Ausfällen. Im Englischen heißt diese Zeit Mean Time Between Failures und wird mit MTBF abgekürzt. Diese MTBF ist eine übliche Größenangabe bei Hardwarekomponenten. Bei neuen Komponenten ist hier ebenfalls die Zeit bis zum erstmaligen Ausfall gemeint (engl. Mean Time To Failure, MTTF). In Datenblättern von Festplatten ist sie zum Beispiel meist mit angegeben. Der Vergleich der MTBF-Werte zeigt auch, warum eine SCSI-Festplatte (SAS) für einen Server so viel mehr kostet als eine SATA-Festplatte für einen Desktop-Rechner.
Natürlich gelten diese Angaben der mittleren Zeiten bis zum Fehler (MTBF) immer nur für eine große Anzahl von Geräten. Von dem Ausfall einer Festplatte im Rechner zu Hause kann man nicht auf einen Fehler in der Produktion oder im Design schließen. Nur wenn sich Fehler beim Test einer ganzen Charge von Festplatten häufen, muss der Hersteller aufmerksam werden.
Die Verfügbarkeit (engl. Availability) errechnet sich aus den oben gegebenen Größen als Verhältnis der Zeit, in der das System funktioniert (also kein Fehler vorliegt), zur Gesamtzeit, die betrachtet wird:
Die in Tabelle 1.1 angegebene Auszeit (engl. Downtime), die intuitiv am besten erfassbare Größe, lässt sich leicht aus der Verfügbarkeit A ableiten:
Ausszeit = (1 – A) × Basiszeitraum
Der Basiszeitraum ist dabei die Zeit, die im SLA vereinbart wurde, meistens ein Monat oder ein Jahr. Bei der konkreten Berechnung ist auch zu beachten, ob ein Kalendermonat als Abrechnungszeitraum oder »die letzten 30 Tage« betrachtet werden.
Jeder versteht unter dem Begriff »Dienst« etwas anderes. Ein Provider (ISP) und sein Kunde werden in erster Linie an die Möglichkeit des Transports von IP-Paketen zwischen Hausanschluss und beliebigen anderen Hosts im Internet denken. Der Kunde, der einen Rootserver in einem Rechenzentrum gemietet hat, will dazu noch eine ausfallsichere Stromversorgung, eine funktionierende Klimaanlage und vielleicht ein Backup-System, wogegen der Webhoster sich auch noch um die entsprechende Applikation kümmern muss.
Der Internetnutzer, der bei seiner Bank seinen Kontostand überprüft oder gerade etwas ersteigert, will, dass sein Internetanschluss funktioniert, dass alle Router bei den verschiedenen Providern funktionieren, der Server der Gegenseite und die Applikation, die er gerade nutzen will, zum Beispiel der Webserver und die Datenbank, auf die dieser zurückgreift. Natürlich muss sein Rechner zu Hause auch noch funktionieren, damit er erfährt, dass er mit dem gerade ersteigerten Wunschtraum sein Konto endgültig in die roten Zahlen gebracht hat.
So versteht jeder Nutzer ein bisschen etwas anderes unter »Dienst«, und der Begriff wird meist erst im Kontext verständlich. Wenn das »Internet nicht geht«, kann das viele Ursachen haben, aber der Benutzer merkt nur, dass er nicht mehr surfen kann. Es kann daran liegen, dass gerade ein Bagger die Leitung vor seinem Haus durchtrennt hat oder dass der Provider ein Problem mit der Authentifizierung des Kunden hat, weil der RADIUS-Server Schwierigkeiten macht.
Im Weiteren werde ich versuchen, den Begriff »Dienst« im Sinne von »Dienst, den eine Applikation erbringt, die auf einem Rechner läuft« zu verwenden. Wenn diese Definition nicht überall durchgehalten wird, sollte zumindest der Sinn aus dem Kontext heraus klar werden.
Wie oben dargestellt wurde, müssen viele einzelne Komponenten zusammenspielen, damit ein Server einen Dienst erbringen kann und die Kommunikation zwischen Client und Server auch funktioniert.
Die Stromversorgung für den Server (oder gleich das ganze Rechenzentrum) ist ein schönes Beispiel. Die konstante Energiezufuhr ist eine der wesentlichen Voraussetzungen für das Funktionieren des Diensts. Zwar ist die Stromversorgung in Deutschland eine der sichersten der Welt, aber wie die Zahlen zeigen (siehe Tabelle 1.4), kann man sich auch nicht zu 100 % auf sie verlassen.
Tabelle 1.4 Versorgungssicherheit mit elektrischer Energie. Die Zahlen stammen vom Electric Power Research Institute (EPRI).
Durchschnittliche Ausfallzeit | Verfügbarkeit | |
---|---|---|
Japan | 6 Minuten | > 99,99 % |
Deutschland | 23 Minuten | > 99,99% |
Frankreich | 53 Minuten | 99,99% |
Großbritannien | 70 Minuten | 99,98% |
USA | 214 Minuten | 99,96% |
Wer im Durchschnitt einen Dienst mit mehr als den oben genannten Zahlen anbieten will, muss eine unterbrechungsfreie Stromversorgung mit einplanen. Grundsätzlich ist eine solche Stromversorgung auch deshalb sinnvoll, weil ein abrupteres Ausschalten noch keinem Server gutgetan hat und allein die Zeit zum Überprüfen der Festplatten und Anlaufen der Dienste die Zeit der meist sehr kurzen Probleme der Stromversorgung bei Weitem übersteigt.
Aber das Beispiel Stromversorgung zeigt noch etwas anderes: Der Dienst ist vom Funktionieren vieler einzelner Komponenten abhängig. Damit eine Applikation auf einem Server laufen kann, müssen zum Beispiel die Stromversorgung, die Hardware mit Prozessor, RAM und Festplatte, das Betriebssystem und die Applikation selbst funktionieren. Damit die Daten vom Client zum Server und zurück transportiert werden können, müssen die Netzwerkschnittstellen der beteiligten Rechner, die Kabel, Switches, Router, Firewalls und alle weiteren Netzwerkkomponenten dazwischen in Ordnung sein. Kann man aus der einfachen Formel von oben jetzt die Verfügbarkeit von komplexen Systemen herleiten? Grundsätzlich: Ja! Denn man kann jedes noch so komplexe System auf einfache Bausteine zurückführen, die untereinander nur auf zwei unterschiedliche Arten verschaltet sind.
Beginnen wir mit einer einfachen seriellen Kopplung (siehe Abbildung 1.1):
Abbildung 1.1 Serielle Kopplung zweier Teile zu einem Gesamtsystem.
Ein solches System besteht aus zwei Komponenten und das Funktionieren des Gesamtsystems hängt vom Funktionieren beider Komponenten ab. Die Verfügbarkeit Aser des Gesamtsystems berechnet sich aus der jeweiligen Verfügbarkeit der einzelnen Komponenten wie folgt:
Aser = A1 × A2
Die Verfügbarkeit ist also immer kleiner als die kleinste Verfügbarkeit der einzelnen Komponente. Wenn A1 = 99% und A2 = 99,95% ist, beträgt die gesamte Verfügbarkeit nur Aser = 98,95%. Sie wird hauptsächlich von A1 bestimmt. Wenn man also die Verfügbarkeit dieses Systems verbessern will, muss man eine bessere Komponente 1 verwenden. Es nützt nichts, die Komponente 2 zu verbessern. Hier drängt sich natürlich der Vergleich mit einer Kette auf: Auch sie ist immer nur so stark wie ihr schwächstes Glied.
Der andere grundlegende Fall ist die parallele Kopplung, bei der zwei Komponenten den gleichen Dienst erbringen (siehe Abbildung 1.2).
Abbildung 1.2 Parallele Kopplung zweier Teile zu einem Gesamtsystem.
Dieses System besteht ebenfalls aus zwei Komponenten, aber das Funktionieren des Gesamtsystems hängt von der Funktion einer der beiden Komponenten ab. Die Verfügbarkeit Apar des Gesamtsystems berechnet sich in diesem Fall aus der jeweiligen Verfügbarkeit der einzelnen Komponenten wie folgt:
Apar = 1 –(1 – A1)(1 – A2)
Im Fall, dass beide Komponenten identisch sind, reduziert sich die Formel auf:
Apar = 1 –(1 – A1)2
Man erkennt, dass die Verfügbarkeit des gesamten Systems in diesem Fall immer höher ist als die Verfügbarkeit der einzelnen Komponenten. Ein kleines Rechenbeispiel anhand einer Einzelkomponente mit einer Verfügbarkeit von 99% verdeutlicht das noch besser (siehe Tabelle 1.5). Die Redundanz gibt dabei an, wie oft eine einzelne Komponente im System vorhanden ist.
Tabelle 1.5 Verfügbarkeit bei redundanter Auslegung mit identischen Komponenten. Jede einzelne Komponente ist zu 99 % verfügbar. Je öfter diese Komponente im System vorhanden ist, desto besser ist das Gesamtsystem gegen Ausfall geschützt.
Grad der Redundanz | Verfügbarkeit Apar | Mittlere Auszeit |
---|---|---|
1 | 99,0 % | 87,66 h/Jahr |
2 | 99,99 % | 52,6 min/Jahr |
3 | 99,9999 % | 31,6 sek/Jahr |
Aus diesem Rechenbeispiel erkennt man, dass die Grundlage aller hochverfügbaren Systeme die 3R-Regel ist:
3R-Regel für hochverfügbare Systeme:
»Redundanz, Redundanz und noch einmal Redundanz!«
Jede einfache Komponente im System, von der die Funktion des gesamten Systems abhängt, nennt man auch Single-Point-of-Failure (SPoF). Die ganze Kunst der Hochverfügbarkeit ist ein Design, bei dem diese SPoF durch Einsatz von redundanten Einzelkomponenten vermieden werden.
Ein einfaches Beispiel für den erfolgreichen Einsatz des obigen Prinzips ist das »redundante Array billiger Festplatten« (Redundant Array of Inexpensive Disks, RAID). Da die Festplatten immer noch zu den anfälligsten Komponenten in einem Server gehören, ist der Einsatz von gespiegelten Festplattensystemen eine weitverbreitete Technik, um die Zuverlässigkeit zu erhöhen. Ein Beispiel dazu: Ein Server wird aus Kostengründen mit billigen Desktop-IDE-Festplatten ausgestattet. Zwei Festplatten sind als RAID1-System ausgelegt, bei dem die Daten auf zwei Festplatten redundant gespeichert werden. Der Hersteller gibt eine MTBF von 300.000 Stunden an, allerdings nur, wenn die Festplatten im Durchschnitt nicht länger als 330 Stunden pro Monat oder 11 Stunden pro Tag laufen. Diese Kennzahl findet sich in Datenblättern in der Rubrik Power-on-Hours (PoH). Aus diesem Grund kann man die tatsächliche MTBF im Betrieb als Speicher für einen Server gut mit maximal 150.000 Stunden abschätzen. Die Wahrscheinlichkeit, dass die Festplatte innerhalb der Lebensdauer des Servers von fünf Jahren ausfällt, kann man über den Umweg der Annual Failure Rate (AFR) berechnen. 300.000 Stunden ergeben bei einem Betrieb von 330 Stunden pro Monat 75,75 Jahre. Ein hypothetischer Fehler im Jahr ergibt dann:
AFR = (PoH pro Jahr / MTBF) × 100 %
In unserem Beispiel erhält man eine AFR von 1,32 %. Die Wahrscheinlichkeit, dass die Festplatte nach fünf Jahren Dauerbetrieb im Server noch immer ihren Dienst versieht, ist dann:
p = (1 – AFR)5 = 93,5 %
Umgekehrt (1 – p) ist die Wahrscheinlichkeit für einen Ausfall mit 6,5 % also nicht zu vernachlässigen.
Nach gut 4,5 Jahren Betrieb zeigen sich die ersten Ausfallerscheinungen bei einer Festplatte, und nach 42.000 Stunden Betrieb gibt sie ganz auf. Wahrscheinlich war die Umgebungstemperatur höher, als nach der Spezifikation zugelassen.
Der Administrator, durch die Warnsignale mittels S.M.A.R.T. (Linux: smartd
) alarmiert, kann schnell eine Ersatzfestplatte einbauen. Weil IDE-Festplatten nicht Hotplug-fähig sind, hat der Server dadurch eine Auszeit von 1 Stunde und 24 Minuten. Das Teilsystem »Festplatten« des Servers hat also in den ersten 4 Jahren und 9 Monaten eine Verfügbarkeit von 99,9967 %. Ohne RAID wäre die Zeit zur Rettung und zum Wiedereinspielen der Daten (Time To Repair, TTR) wesentlich länger als die 1,4 Stunden zum Einbau der neuen Festplatte und zur Wiederherstellung des funktionsfähigen RAID gewesen.
Bitte beachten Sie, dass in diesem Beispiel eine TTR angegeben ist. Eine mittlere Zeit (MTTR) kann nicht angegeben werden, da es sich bei diesem Server um ein Einzelbeispiel handelt und nicht um eine große Anzahl zur Berechnung der gemittelten Werte.
Ein komplexes System kann man in Einzelkomponenten zerlegen, die durch einfache serielle oder parallele Verknüpfungen untereinander verbunden sind. Anhand der obigen Regeln kann somit sukzessiv die Verfügbarkeit für das gesamte System berechnet werden. Betrachten wir noch ein Beispiel für die Berechnung eines solchen Gesamtsystems: Ein Webserver soll ans Internet angeschlossen werden. Die wesentlichen Komponenten, auf die der Planer Einfluss hat, sind das LAN im Rechenzentrum und der Server selbst. Es gelten die Annahmen aus Tabelle 1.6:
Tabelle 1.6 Annahmen für die Verfügbarkeit von Hard- und Software eines einfachen Webservers.
MTBF (aus Datenblättern) | MTTR (aus Tabelle 1.2) | Verfügbarkeit | |
---|---|---|---|
Applikation | - | - | 99,994 % (gemessen) |
Server (ideal) | 50.000 h | 2 h | 99,996 % |
Server (real) | 50.000 h | 48 h | 99,904 % |
Server + Applikation | 99,898 % (seriell) | ||
Switch | 250.000 h | 2 h | 99,999 % |
Router + Internet | 99,95 % (Vertrag mit ISP) | ||
Gesamt | 99,85% |
Wie kann der Planer jetzt mit einfachen Mitteln die Verfügbarkeit erhöhen? Es ist klar, dass die Hardware des Servers das Problem ist. Anhand der Zahlen sieht man, dass es zwei Ansätze gibt, um die Verfügbarkeit des Diensts zu erhöhen:
Der Planer könnte den Prozess der Sicherung und der Wiederherstellung des Servers verbessern: Die 48 Stunden Zeit zur Wiederherstellung sind für einen Administrator mit normalen Arbeitszeiten und für die Beschaffung der Hardware im Fehlerfall gerechnet. Ein Vergleich mit Tabelle 1.2 zeigt, dass diese Werte schon günstig geschätzt sind. Maßnahmen zur Verbesserung könnten die Lagerung von Ersatzhardware und die Einführung eines Bereitschaftsdiensts für Administratoren sein. Ebenfalls ist eine automatische Sicherung der Server und schnelle Wiederherstellung von der Sicherung wichtig. Dazu wird ein professionelles Backup-System benötigt.
Alternativ sollte es möglich sein, das System »Server+Applikation« redundant auszulegen. Wenn man die Ersatzhardware vor Ort hält, kann man gleich die beiden Server dazu nutzen, einen Webserver-Cluster laufen zu lassen. Für das redundante System aus Server und Applikation ergibt sich eine Verfügbarkeit von 1 –(1 – 0,999)2 = 99,9999%, das ist wesentlich besser als die Anbindung ans Internet, der nächste Schwachpunkt. Somit kann der Administrator wieder in Ruhe schlafen, und ein guter Sicherungsprozess mit schneller Wiederherstellung ist aufgrund der Verfügbarkeit nicht mehr dringend notwendig. Damit ist nicht gesagt, dass ein Backup überhaupt nicht mehr notwendig ist, aber eine so schnelle Wiederherstellung des Systems ist nicht mehr erforderlich.
Zusätzlich wird deutlich, dass eine Investition in das Netzwerk zur redundanten Auslegung des Switchs und der Kabel sowie eine doppelte Anbindung der Server ans Netz mit sogenannten bond-Schnittstellen auch nicht dringend erforderlich ist, wenn kein Systemheld im Rechenzentrum herumirrt, der willkürlich Kabel zieht. Eine nicht zu unterschätzende Fehlerquelle, die noch gar nicht in die Berechnung eingegangen ist, sind menschliche Fehler, besonders jegliche Art von Fehlern, die System-, Netzwerk- oder Firewall-Administratoren machen.
Anhand dieses kleinen Rechenbeispiels erkennt man die Notwendigkeit eines redundanten Aufbaus von Servern und Applikationen schnell. Welche Möglichkeiten gibt es dazu?
Am bekanntesten sind sicherlich die Projekte „Linux Virtual Server (LVS)“ (LVS[2]) und die „Linux-HA“[3]. Der Linux Virtual Server implementiert einen Switch auf Layer 4 des bekannten OSI-Modells (TCP bzw. UDP) als Dienst, der auf einem Server, Director genannt, läuft. Eingehende Verbindungen werden entgegengenommen und an reale Server zur Verarbeitung weitergeleitet. Der LVS fungiert hier nur als sogenannter Director, der die Verbindungen und die Last an die Server verteilt. Gleichzeitig wird mit einem Zusatzdienst gemessen, ob die Server noch leben oder ob keine Verbindungen mehr zu einem bestimmten Server weitergegeben werden sollen.
Das andere bekannte Software sind die Folgeprojekte von Linux-HA. Ein Heartbeat-Mechanismus überprüft die Erreichbarkeit von Servern, und der Cluster-Manager checkt die Verfügbarkeit von Diensten auf diesen Servern. Falls es Probleme mit der Verfügbarkeit eines Knotens im Cluster gibt, sorgt der Cluster-Manager dafür, dass die Ressourcen, die auf diesem Knoten liefen, auf andere Knoten des Clusters verschoben werden. Somit ist ein Cluster, der mit dieser Software aufgebaut wurde, in erster Linie dafür gedacht, eine hohe Verfügbarkeit durch redundanten Aufbau zu gewährleisten. Ein Skalieren des Aufbaus ist im Grunde nicht vorgesehen, da so ein Cluster als System ausgelegt ist, bei dem ein Knoten die Last übernimmt und der andere nur im Fehlerfall einspringt (Hot-Standby oder Aktiv/Passiv-System). Eine Lastverteilung, sodass mehrere Server die eingehenden Anfragen beantworten, findet in einem solchen Cluster normalerweise nicht statt. Mit welchen Mitteln das in bestimmten Fällen doch erreicht werden kann, wird später gezeigt (siehe Kapitel 8, Abschnitt „IPaddr“).
Natürlich lassen sich in großen Clustern auch viele Ressourcen auf vielen Servern ausführen, die zusammen den Cluster bilden.
Der Linux Virtual Server implementiert einen Layer-4-Switch im Kernel des Betriebssystems, auf dem der LVS läuft. Über den Switch werden eingehende Verbindungen an eine Reihe von Servern verteilt, auf denen der Dienst tatsächlich läuft. Dieser sogenannte Director macht nichts anderes, als die eingehenden Verbindungen zu verteilen. Da der Switch auf Layer 4 (tcp oder udp) arbeitet, werden alle Pakete, die zu einer tcp-Verbindung gehören, an denselben Server weitergeleitet, sodass dieser die komplette Anfrage beantworten kann. Der Director kann sich aber auch um Anwendungen, die udp-Pakete verschicken, kümmern und sogar icmp-Pakete an die Server im Hintergrund verteilen.
Ein Vorteil der Verteilung auf Layer 4 ist sicherlich die hohe Geschwindigkeit, mit der der Director arbeiten kann. Es wird nur der Header des Pakets überprüft, es werden aber keine Applikationsdaten inspiziert. Das Verfahren hat natürlich den Nachteil, dass neue tcp-Verbindungen nicht notwendigerweise zum selben Server weitergeleitet werden und somit das Problem des Datenaustauschs zwischen den Applikationen auf den einzelnen Servern besteht. Dieses Problem macht sich zum Beispiel bemerkbar, wenn Cookies eines Webservers über eine längere Zeit beibehalten werden müssen.
Dieses Problem umgeht LVS mit sogenannten Persistent Connections. Bei dieser Einstellung werden Verbindungen, die vom selben Client oder Netzwerk kommen, immer an denselben Server weitergeleitet. Die Granularität der Entscheidung für die Persistent Connections lässt sich einstellen.
Der einfachste Verteilungsalgorithmus des Director ist Round-Robin. Die Verbindung erhält einfach der nächste in der Reihe der verfügbaren Server. Dieser Algorithmus lässt sich noch über Wichtungen der Serverleistung verfeinern. Da der Director natürlich die Anzahl der aktuell bestehenden Verbindungen zu jedem einzelnen Server im Hintergrund kennt, können mittels eines entsprechenden Algorithmus auch neue Verbindungen an denjenigen Server weitergegeben werden, der aktuell am wenigsten verarbeitet. Bei diesem Algorithmus lassen sich ebenfalls wieder Wichtungen für einen einzelnen Server konfigurieren. Es sind noch eine Reihe weiterer Algorithmen implementiert. Insgesamt können zehn verschiedene Methoden ausgewählt werden, die aber meist nur Varianten einer grundlegenden Idee sind. Am gebräuchlichsten sind sicher (Weighted) Round-Robin und (Weighted) Least Connections.
Technisch ist die Verteilung der Pakete an die tatsächlichen Server über drei verschiedene Verfahren möglich:
Weiterleitung per Network Address Translation (NAT)
Weiterleitung durch direktes Routing
Weiterleitung per IP-Tunnel
Im ersten Fall verhält sich der Director wie ein einfacher Router, der per NAT-Mechanismus die Zieladressen der Pakete umsetzt und diese dann weiterleitet. Die Antwortpakete der Server müssen ebenfalls über den Director geroutet werden, um die Adressen wieder richtig umzuwandeln. Dieser Mechanismus ist in Abbildung 1.3 skizziert. Er hat den Vorteil, dass er relativ einfach zu implementieren ist und die tatsächlichen Server irgendwo stehen können, solange sie nur per IP-Adresse erreichbar sind. Ebenso kann auf den Servern im Hintergrund jedes beliebige Betriebssystem laufen, solange dieses eine TCP/IP-Schnittstelle bietet. Der Nachteil der Methode ist, dass alle Pakete, also auch die meistens großen Antwortpakete, über den Director geroutet werden müssen und dieser die NAT-Tabellen pflegen muss. Somit ist diese Methode nicht allzu weit skalierbar. Üblich sind Installationen mit bis zu 20 realen Servern.
Abbildung 1.3 Beim NAT-Mechanismus schickt der Client die IP-Pakete an den Director (1), der sie mit einer neuen IP-Adresse versieht und an den zuständigen Server weitersendet (2). Dieser schickt die Antwortpakete zurück an den Director (3), der wiederum die IP-Adresse austauscht und sie an den Client zurücksendet (4).
Bei der zweiten Methode schreibt der Director einfach nur die MAC-Adresse des Pakets um und schickt es so an den richtigen Server weiter. Diese Methode ist in Abbildung 1.4
Um die Aufzählung zu komplettieren, sei hier auch noch die dritte Methode erwähnt. Anstatt die eingehenden Pakete mit einer neuen MAC-Adresse zu versehen und weiterzuschicken, nutzt der Director IP-Tunnel, um die Pakete an die tatsächlichen Server weiterzuleiten. Der Director tunnelt die Pakete zum Server im Hintergrund, indem er sie mit einem neuen IP-Header versieht und an den Server weiterschickt. Dieser packt den Tunnel aus und beantwortet die Anfrage. Da die tatsächlichen Adressen der Clients auf dem Weg nicht verändert wurden und somit auf dem Server bekannt sind, kann dieser die Antwortpakete direkt an den Client senden. Diese Methode wird in skizziert. Das Paket muss nicht mehr über den Director zurückgeroutet werden. Somit ist diese Methode weitaus besser skalierbar als die erste Methode. Ein Fallstrick bei dieser Methode ist der Umstand, dass nicht mehr jedes beliebige Betriebssystem im Hintergrund verwendet werden kann. Die Schnittstellen müssen IP-in-IP-Tunnel beherrschen, da der Director die Pakete ja mit einem neuen IP-Header versieht. Weil die ursprüngliche Clusteradresse im weitergeleiteten Paket noch vorhanden ist, muss diese virtuelle IP-Adresse auf allen Servern im Hintergrund konfiguriert werden, damit sich die Server für dieses Paket zuständig fühlen.
Abbildung 1.5 Beim Tunneln packt der Director alle Pakete für den Server in einen IP-in-IP-Tunnel und schickt sie so weiter (1). Der Server packt den Tunnel aus und kann dem Client direkt antworten, ohne den Umweg über den Director zu nehmen (2).
Tabelle 1.7
Tabelle 1.7 Übersicht über die Methoden zur Weiterleitung der Pakete an die realen Server im Hintergrund. Jede Methode hat ihre Vor- und Nachteile.
NAT | Tunnel |
---|---|
Beliebig | IP-Tunnel notwendig, Non-ARP-Schnittstelle |
(Private Adressen) | LAN/WAN |
Bis zu 20 | > 100 |
Director | Eigenes Routing |
netfilter
netfilter
Mit dem LVS-System lässt sich die Last gut auf viele Server verteilen. Allerdings verfügt das Kernelmodul nicht über die Fähigkeit, zu überprüfen, ob die konfigurierten Server noch leben oder nicht. Es stellt nur die Grundfunktion des Switch auf Layer 4 zur Verfügung. Für einen kompletten Cluster ist noch ein Zusatzprozess notwendig, der die Server im Hintergrund andauernd abfragt. Anhand der Antwort entscheidet dieser Daemon, ob der Server noch lebt oder der entsprechende Server aus der Konfiguration genommen werden muss und die bestehenden Verbindungen auf andere Server verteilt werden müssen. Solche Programme sind zum Beispiel oder .
Es bleibt das Problem, dass der Director selbst einen Single-Point-of-Failure darstellt, da er selbst nur einmal im System vorhanden ist und alle Verbindungen über ihn vermittelt werden. Wenn er ausfällt, steht das gesamte System. Hier kommen die Nachfolgeprojekte von Linux-HA zum Zuge. Mit dieser Software können (fast) alle beliebigen Dienste redundant angeboten werden. Über zwei separate Rechner kann auch der Director-Dienst entsprechend hochverfügbar gestaltet werden.
Kapitel 9
heartbeat
[4]
heartbeat
Kapitel 2„Architektur der Software“
Unter Linux-HA sorgt ein heartbeat
-Dienst dafür, dass die Mitglieder eines Clusters ständig Nachrichten austauschen, um den Status gegenseitig zu überwachen. Sogenannte Ressourcen werden vom Cluster-Manager verwaltet und auf einzelnen Knoten gestartet. Ressourcen sind deshalb im Verständnis von Linux-HA all das, was vom Cluster verwaltet wird, von IP-Adressen bis zu Diensten wie einem Apache-Webserver, von der Überwachung des eigenen Systems bis zu komplexen Mechanismen zur Datenreplikation zwischen den Knoten des Clusters. Auf der Projektseite ist dies gut zusammengefasst: »If we manage it, it is a resource.«
Im Prinzip können alle beliebigen Dienste, für die ein init
-Skript im Stil von System-V existiert, mittels Linux-HA hochverfügbar angeboten werden. Zusätzlich gibt es im Projekt noch spezielle Skripte (Agenten), die weitere Funktionen wie IP-Adressen oder die Überwachung übernehmen. Für viele weitverbreitete Dienste gibt es auch spezielle Agenten, die im Gegensatz zu System-V-Skripten noch eine genauere Überwachung erlauben als nur die einfache Statusabfrage des Diensts.
Die weiteren Entwicklungen im Projekt ermöglichen der Verwaltung im Cluster, nun nicht nur heartbeat
als Kommunikationsplattform zu nutzen, sondern erlauben auch die fortgeschrittene Technik von OpenAIS
bzw. corosync
.
pacemaker
corosync
1
2
3
4