Kapitel 10. Cluster und HA - Lösungen
Linux ist Microsoft Windows NT/XP und auch fast allen anderen UNIXen beim Clustering weit voraus. In fast allen Rechenzentren der Welt wird Linux für verschiedene Arten von Clustering eingesetzt, wobei der Begriff recht weit gefasst ist. Er reicht von regelmäßiger Replikation der Dateien auf einem Server und Übernahme bei Ausfall, bis hin zu einem CPU - Verbund über Netzwerkkarte, wo Applikationen sich auf viele Server verteilen. Sämtliche benötigte Software ist in Linux serienmäßig enthalten, bzw. auf beliebigen Distributionen nachinstallierbar. Wer es eilig hat, kann eine bootfähige CD einlegen, und seinen Cluster nach 1 Minute in Betrieb nehmen. Dank des Quelloffenen Konzeptes von Linux gibt es solche Spezialdistributionen, siehe Kapitel 5. Hier nun ein Überblick über die Möglichkeiten und Einsatzgebiete von "Clustern":
Fileserver Replikation mit CODA, INTERMEZZO, GFS, OpenGFS, NFSv4, AFS, OpenAFS, RSYNC, dnotify, inotify, fam, changedfiles. Diese Lösungen bzw. Softwarepakete replizieren zeitnah nach dem Schließen der Datei diese auf einen oder mehrere andere Server, sogar durch Firewalls hindurch, und über Proxies hinweg. Hierbei werden z.B. bei einigen Systemen nur die Datei - Unterschiede übertragen, nicht die ganze Datei, wie z.B. bei Abschnitt 10.1. So sind mit RSYNC z.B. Verbundsysteme über viele Filialen hinweg bereits Standard, wo alle Daten in allen Filialen zeitnah gespiegelt zur Verfügung stehen, auch ohne daß teure Standleitungen erforderlich sind. Internet - Anschluß und Crypto - Tunnel - Software, genügen bereits, siehe Abschnitt 17.9. Interessant hierbei ist z.B. das Feature des CODA Filesystems, bei welchem die Arbeitsstationen nichts von einem Ausfall des Servers bemerken, dank spezieller Treiber für Clients (Windows 95/98/2000/XP...) mit fallback- und fallforward - Funktionen. Am interessantesten und vielseitigsten einsetzbar jedoch ist sicherlich Abschnitt 10.1.
Echtzeit - Spiegelung von Fileservern erfordern natürlich höhere Anforderungen bezüglich der Vernetzung. mehrere der o.a. Softwarepakete erlauben dies, weil z.B. Locking mit flock, fcntl im Cluster durch einen speziellen Service weitergegeben wird. Hierbei spielt in allen "Cluster - Lösungen" ein von IBM programmierter Dienst eine wichtige Rolle, Abschnitt 10.8.16OpenDLM (Distributed Lock Manager), welche u.a. mit OpenGFS (Global File System) perfekt zusammenarbeitet. Vorgeschaltete LOAD BALANCER (Layer 4 - Switching auch oft genannt) ermöglichen es, daß diese Fileserver sich die Last der Zugriffe von tausenden Internet - Surfern, z.B. - teilen, siehe Kapitel 22.
ENBD/NBD ((Enhanced) Network Block Device), stellt ein komplettes Festplattenlaufwerk über das Netzwerk als normales Device zur Verfügung (/dev/nbd, als wäre eine Festplatte /dev/hda, /dev/sda lokal eingebaut. Mit Hilfe des in Linux standardmäßig enthaltenen Software - Raid und Multipath I/O läßt sich z.B. ein RAID - System realisieren, bei welchem die Festplatten benachbarter Server genutzt werden. Im Falle eines Ausfalles sind alle Daten auf dem Slave - Server vorhanden, sodaß dieser die IP-Nummer des Master - Servers übernehmen kann.
Oracle hat mit OCFS (OraCle File System) den Ansatz von CODA weiter entwickelt und bietet ein Filesystem für RAW Devices an, welches, ähnlich NBD und ENBD, die Simulation von RAW Devices (bis 255) über Netzwerk ermöglicht. Spezielle Caching - Funktionen und eine Anpassung speziell für die Oracle typischen Blockgrößen beschleunigen dieses gegenüber NBD und ENBD. Natürlich kann man NBD, ENBD und OCFS auch für andere Datenbanken nutzen. Vorteil bei OCFS ist, daß speziell für Oracle entwickelte Toolkits mitgeliefert werden.
SAN (Storage Area Network) sind eine sehr teure Lösung, bei welcher die Linux Server keine eigenen Festplatten nutzen, sondern via Glasfaser ein Device von einer Blackbox zur Nutzung zur Verfügung gestellt bekommen. Ein Feature namens dynamic multipathing (DMP) ermöglicht hierbei sogar den wechselseitigen Zugriff mehrerer Linux Server auf ein SAN - Device, bzw. das Umschalten eines Servers auf ein anderes SAN, im Falle einer Störung. Dies kann sinnvoll sein, wenn LOAD Balancing betrieben wird, oder wenn mehrere Server als HA - System mehreren SAN Devices vorgeschaltet sind. Bei dieser Lösung wird eine hohe Redundanz und Ausfallsicherheit erreicht, weil kein SPOF (Single Point Of Failure) mehr vorhanden ist.
Aber auch diesen Lösungen fehlt eine wichtige Eigenschaft, die schon bereits seit NOVELL SFT III (3.x/4.x/5.x/6.x) beherrscht - die Weiterführung der TCP/IP - Übertragung bei Übernahme des Master - Servers durch den Slave. Fast alle auf TCP/IP basierenden Lösungen haben eine Eigenschaft gemeinsam. Im Falle eines Ausfalles des Servers und Übernahme durch einen Ersatzserver werden alle Datenübertragungen unterbrochen, und müssen neu gestartet werden. In vielen Fällen müssen Windows Clients sogar neu booten, um ihre Arbeit fortsetzen zu können, weil der Slave - Server bisher ja nur geruht hat, also nichts über den Zustand und die aktiven Verbindungen des Master - Servers weiß. Gefragt sind daher Lösungen, bei welcher die Zustandsinformationen des Master ununterbochen auf den Slave übertragen werden. Hierzu gibt es mehrere Lösungen:
Load - Balancer, siehe auch Kapitel 22 sind einem Server - Cluster vorgeschaltete Verteiler der Last, die doppelt ausfallsicher zur Verfügung stehen sollten, da sie ansonsten einen sogenannten SPOF (Single Point Of Failure) darstellen. Hierfür existiert ein Kernel - Modul namens ip_vs_user_sync, welches einen ipvs syncmaster und ein ipvs syncslave - Dienst startet, sodaß die Zustandsinformation der TCP/IP Verbindungen dem Statefull Packet Module des Firewallmoduls von Linux gespiegelt werden. So sind beide Loadbalancer ständig jeweis darüber informiert, wie der Zustand des anderen ist. Nun können sogar die Loadbalancer nicht nur die Last auf Server verteilen, sondern auch die Netzwerklast unter sich aufteilen, eine active-active Server/Verbindungs - Synchronisation Mehr hierzu siehe auch Active - Active Linux Director, bzw. LVS-HOWTO.
test Hinweis auf LVS, multipathing, NBD, RAID, geschlossene Dateien Posix Semantic mit Locks ACL's, Lockmanager. (flock...) (flock, fcntl) Wer unterstützt Kerberos OpenAFS, GFS, inotify dnotify...
10.1. RSYNC - Das Universal - Replikations - Werkzeug
RSYNC ist das mit Abstand umfangreichste und komplexeste Replikationssystem, welches jemals programmiert wurde, trotz einfachster Bedienung. Es ist seit Jahren bereits bewährt, und für alle UNIXe und Windows NT/2000/XP kostenlos verfügbar: RSYNC.SAMBA.ORG. Ich möchte hier folgende Einsatzgebiete einmal kurz skizzieren, weil oft die Phantasie kaum ausreicht, um zu erahnen, wofür man RSYNC alles einsetzen kann:
Datensicherung von Workstation auf Server
Datensicherung von Server auf Wechselplatte in Workstation
Echtzeit - synchrone Replikation von Server zu Server (Master - Slave, oder Master / Standby). In Verbindung mit Abschnitt 10.7 hat man hier eine Hochverfügbarkeits - Lösung.
Datensicherung eines Internet - Servers auf lokale Festplatte oder Server, sogar über die Firewall bzw. Proxy hinweg.
Synchronisation von Fileservern über das Internet. Hierbei ist es meist so, daß eine der Filialen (oder Zentrale) eine feste IP-Nummer besitzt, sodaß der sich einwählende Server die Synchronisation zwischen den beiden Fileservern initiiert. Hauptproblem bleibt hierbei die Überwindung der Firewall. Dies ist dank Portknocking, Socks 4, Socks 5, IPSec und SSL - Tunnel kein Problem mehr. Mehr hierzu siehe Abschnitt 17.9. Noch interessanter wird es, wenn die Fileserver aus mehreren Filialen via DSL, alle ohne feste IP-Nummer, sich zu einer bestimmten Zeit (cron) im Internet "treffen", um über einen Kryptokanal Daten ihrer Festplatten zu synchronisieren. Mehr hierzu siehe Abschnitt 17.10 Diese Lösung funktioniert sogar global nach China, Indien ... ohne teure Standleitungen, bzw. feste IP-Nummern.
Echtzeit - asynchrone Repliktion von Master - Server zu Slave/Standby - Server. Wer schon einmal versehentlich Daten auf einem Server gelöscht hat, wird glücklich darüber sein, wenn die Daten auf dem Slave - Server noch alle vorhanden sind, trotz zeitnaher Synchronisation der beiden Festplatten.
Zeitversetzte Synchronisation zwischen Servern in Filialen. Hierbei werden z.B. über Modemleitungen Dateien auf besondere Weise übertragen: Komprimiert, differenziell (nur veränderte Dateien eines Verzeichnisbaumes) und - es werden nur die Unterschiede innerhalb der Dateien übertragen. Dies erspart besonders bei großen Dateien, z.B. SQL - Dumps (MySQL, Oracle, PostgreSQL, Informix, DB2, Pervasive, Betrieve...) sehr viel Übertragungszeit.
Synchronisation von Datenbanken - RSYNC ist in der Lage, nur die Unterschiede zweier Datenbank - Dump - Files (erstellt mit mysqldump, pg_dump, Oracle imp/exp, Informix ontape, dbexport) komprimiert und verschlüsselt über Firewalls hinweg zu übertragen. Mit Hilfe des SSH - Clients ssh können auf dem entfernten Datenbankserver remote Befehle unter beliebigen User-Accounts abgesetzt werden (wichtig für Datenbanken!) und dort z.B. ein DUMP initiiert werden, der dann mit Hilfe von RSYNC gespiegelt wird. Diese kann man dann entweder in eine eigene Datenbank wieder einspielen, oder halt, sofern es keine Inkonsistenzen mit Triggern, UNIQUE IDs, o.ä. gibt, sogar in eine Datenbank übernehmen. So z.B. bei Bestellungen, die auf Datenbanken im Internet - Shop eingegangen sind. Ebenso kann man die Datenbank mit neuen Artikeln vollautomatisch synchronisieren.
Synchronisation bzw. Replikation von POP3 Postfächern, ähnlich mailsync. Dies kann sehr interessant sein, wenn man einen Standby-Server betreiben möchte, der im Falle eines Ausfalles des Master - Servers mit Hilfe von heartbeat dess IP-Nummer innerhalb weniger Sekunden übernimmt. Die Echtzeit-Synchronisation der Postfächer samt differeziellem Backup ist hierbei sehr interessant, weil nur die neuen Mails übertragen und in die bereits replizierten Postfächer eingearbeitet werden.
Synchronisation von kompletten LDAP - Bäumen. Ähnlich dem Verfahren für SQL - Server kann man mit Hilfe von SSHD und SSH einen Dump initiieren, der dann mit Hilfe von RSYNC differenziell übertragen wird.
RSYNC besitzt die Eigenschaft, als Daemon ständig über die Verzeichnisse zu wchen, und bei Veränderung einen Synchronisationsprozess direkt einzuleiten. Hierbei arbeitet RSYNC als Ersatz für replizierende Filesysteme, wie z.B. CODA, Intermezzo, AFS, GFS, DFS, ...
Backup von Windows NT/2000/XP oder Linux - Workstations auf einen Linux Server. RSYNC ist nicht nur für alle UNIXe verfügbar, sondern auch auf Microsoft Windows portiert. Mit Hilfe des unter Windows gestarteten Synchronisationsprogrammes werden die Festplatten der Workstations oder auch Server in kurzer Zeit, dank differenzieller Übertragung, gesichert. Ein komfortables Windows Programm ermöglicht die Synchronisation, Event - oder Zeitgesteuert. Mehr hierzu siehe auch Abschnitt 15.2, oder Sync2NAS Replikation und Abschnitt 15.3.
10.1.1. Plattenspiegelung in Workstation oder Server
Damit ein Server oder eine Workstation bei Ausfall einer Festplatte wieder schnell hergestellt werden kann, spiegelt man alle Inhalte auf eine Wechselplatte (300 - 500 GByte AT-BUS - Platte im Wechselrahmen). Man bindet (mount) die Festplatten unter /mnt/wechselplatte in das Filesystem ein, und startet dann einfach RSYNC.