Inhaltsverzeichnis
Netzwerkadministratoren sind oft besorgt über die Verfügbarkeit von Datei- und Druck-Diensten. Netzwerkbenutzer sind geneigt, intolerant gegenüber den Diensten zu sein, von denen sie, was ihre Aufgabenstellungen anbelangt, abhängig sind.
Ein Schild in einem Computerraum diente dazu, das Personal an seine Verantwortung zu erinnern. Es lautete:
Alle Menschen scheitern; sowohl im Großen wie im Kleinen scheitern wir fortwährend. Maschinen sind ebenfalls fehlerhaft. Computer sind Maschinen, die von Menschen verwaltet werden, und das Ergebnis eines Fehlers kann spektakulär sein. Ihre Verantwortung ist es, mit dem Scheitern umzugehen, es vorwegzunehmen und auszuschließen, so weit es menschlich und ökonomisch sinnvoll ist. Sind Ihre Handlungen Teil des Problems oder Teil der Lösung?
Wenn wir also mit Fehlern in geplanter und produktiver Art und Weise zu tun haben, dann müssen wir zuerst einmal das Problem verstehen. Dies ist die Zielsetzung dieses Kapitels.
In der folgenden Betrachtung sind unter anderem Informationen eingestreut, wie man Vorsorge gegen Fehler in Netzwerkinfrastrukturen trifft. Unsere Absicht ist hier keine langatmige Dissertation über die Hochverfügbarkeit selbst. Zusätzlich haben wir die bewusste Entscheidung getroffen, keine detaillierten Arbeitsbeispiele von Hochverfügbarkeitslösungen zur Verfügung zu stellen. Stattdessen zeigen wir einen Überblick über die Thematik in der Hoffnung, dass sich jemand der Herausforderung stellt, ein detailliertes Dokument zur Verfügung zu stellen, das sich ausschließlich auf die Präsentation des gegenwärtigen Wissensstandes und der Praktiken im Bereich der Hochverfügbarkeit beschränkt, soweit sie den Einsatz von Samba und anderen CIFS/SMB-Technologien betreffen.
Die folgende Zusammenfassung war Teil einer Präsentation von Jeremy Allison auf der SambaXP 2003-Konferenz, die im April 2003 in Göttingen abgehalten wurde. Es wurden Zusatzinformationen aus anderen Quellen hinzugefügt, aber Jeremy war es, der die folgende Struktur vorgab.
Alle Cluster-Technologien zielen auf einen oder mehrere der folgenden Punkte ab:
Sich die maximal erschwingliche rechnerische Power zu verschaffen
Sich eine schnellere Programmausführung zu verschaffen
Dienste zur Verfügung zu stellen, die nicht einfach stoppen
Fehler zu verhindern
Die genaue und höchsteffiziente Nutzung von Ressourcen
Ein geclusterter Dateiserver hat also idealerweise folgende Eigenschaften:
Alle Clients können sich transparent an jeden Server verbinden.
Ein Server kann ausfallen, und die Clients werden transparent wieder auf einen anderen Server verbunden.
Alle Server halten denselben Satz von Dateien bereit.
Alle Dateiänderungen sind sofort auf allen Servern zu sehen.
Das setzt ein verteiltes Dateisystem voraus.
Grenzenlose Fähigkeit zu skalieren durch Hinzufügen zusätzlicher Server oder Festplatten.
Kurz gesagt, das Problem ist eine Frage des Zustands.
Alle TCP/IP-Verbindungen sind von Zustandsinformationen abhängig.
Die TCP/IP-Verbindung enthält eine Paket-Sequenznummer. Diese Sequenznummer muss auf allen Maschinen in einem Cluster dynamisch aktualisiert werden, um eine nahtlose TCP-Ausfallsicherheit zu erreichen.
CIFS/SMB (die Windows-Netzwerkprotokolle) benutzen TCP-Verbindungen.
Dies bedeutet aus einer grundlegenden Designperspektive, dass Ausfallsicherheit nicht wirklich in Erwägung gezogen wurde.
Alle aktuellen SMB-Cluster sind Ausfallsicherheitslösungen, sie basieren darauf, dass die Clients sich neu verbinden. Sie stellen Server-Ausfallsicherheit zur Verfügung, aber die Clients können Informationen aufgrund eines Serverausfalls verlieren.
Server halten Zustandsinformationen über die Client-Verbindungen fest.
CIFS/SMB ist in viele Zustände verwickelt.
Jedes Öffnen einer Datei muss mit anderen Dateiöffnungen verglichen werden, um Freigabemodi zu überprüfen.
Um es einem Cluster von Dateiservern zu ermöglichen, als ein einzelner Server mit einem Namen und einer IP-Adresse zu erscheinen, müssen die eingehenden TCP-Datenströme von den Arbeitsstationen durch einen virtuellen Frontend-Server verarbeitet werden. Dieser Server muss die eingehenden Pakete auf SMB-Protokoll-Layerebene de-multiplexen und dann das SMB-Paket an verschiedene Server im Cluster weiterreichen.
Einer kann dann alle IPC$-Verbindungen und RPC-Calls auf einen Server aufsplitten, um Druckaufgaben und Benutzeranfragen abzuarbeiten. RPC-Druckaufgaben werden zwischen verschiedenen IPC4-Sitzungen aufgeteilt, da es schwierig ist, diese über geclusterte Server aufzuteilen!
Konzeptionell ausgedrückt: Alle anderen Server werden nur Dateidienste zur Verfügung stellen. Sich darauf zu konzentrieren, ist ein einfacheres Problem.
Das De-Multiplexen von SMB-Anfragen erfordert Wissen zu SMB-Zustandsinformationen. Alle müssen vom virtuellen Frontend-Server bereitgehalten werden. Dies ist ein verblüffendes und schwer zu lösendes Problem.
Windows XP und spätere Versionen von MS Windows haben die Semantik geändert, so dass Zustandsinformationen (vuid, tid, fid) für eine erfolgreiche Durchführung zueinander passen müssen. Dies macht die Dinge einfacher als zuvor und ist ein positiver Schritt vorwärts.
SMB-Anfragen werden durch vuid zu ihrem Bestimmungsserver gesendet. Es existiert zurzeit kein Code, um diese Lösung zu beeinflussen. Dieses Problem ähnelt im Grunde dem Problem, mehrere Anfragen an einen Windows 2000-Terminalserver in Samba zu bearbeiten.
Eine Möglichkeit, um damit zu beginnen ist es, den Serverpool den Clients direkt auszusetzen. Dies könnte den Schritt des De-Multiplexing überflüssig machen.
Es gibt viele verteilte Dateisysteme für UNIX und Linux.
Viele können von uns übernommen werden, um unsere Cluster abzusichern, solange wir immer die SMB-Semantik berücksichtigen (Freigabemodi, Sperren und Oplock-Themen im Speziellen). Allgemein übliche freie verteilte Dateisysteme enthalten:
NFS
AFS
OpenGFS
Lustre
Der Serverpool (Cluster) kann jedes verteilte Dateisystem-Backend nutzen, wenn die gesamte SMB-Semantik in diesem Pool durchgeführt wird.
Wo ein geclusterter Server nur SMB-Dienste zur Verfügung stellt, kann das Verwalten von Oplocks direkt im Serverpool erfolgen, ohne den Zwang, diese Aufgabe an den dahinterliegenden Dateisystem-Pool weitergeben zu müssen.
Auf der anderen Seite wird es essenziell notwendig sein, dass die Implementierung Oplock-fähig ist, so dass sie mit SMB-Diensten zusammenarbeiten kann, wenn der Serverpool auch NFS oder andere Dateidienste zur Verfügung stellt. Dies ist heutzutage eine bedeutende Herausforderung. Ein Fehler dabei hat einen bemerkenswerten Perfomanceverlust zur Folge, den die Benutzer von Microsoft Windows-Clients deutlich spüren.
Zuletzt müssen alle Zustandsinformationen über den Serverpool verteilt werden.
Die meisten Backend-Dateisysteme unterstützen die POSIX-Dateisemantik. Dies macht es schwierig, die SMB-Semantik zurück ins Dateisystem zu schieben. POSIX-Sperren haben andere Eigenschaften und eine andere Semantik als SMB-Sperren.
Alle smbd-Prozesse im Serverpool müssen notwendigerweise sehr schnell miteinander kommunizieren. Dadurch ist die gegenwärtig von Samba verwendete tdb-Dateistruktur nicht geeignet für die Nutzung über Netzwerke. Geclusterte smbds müssen eine andere Struktur verwenden.
Die Hochgeschwindigkeits-Interserverkommunikation innerhalb des Serverpools ist eine Design-Grundvoraussetzung für ein voll funktionsfähiges System. Verfügbare Möglichkeiten sind unter anderem:
Proprietäre Shared-Memory-Bussysteme (Beispiel: Myrinet oder SCI [Scalable Coherent Interface]). Diese sind äußerst kostenintensiv.
Gigabit-Ethernet (mittlerweile ziemlich erschwinglich)
Raw-Ethernet-Framing (um TCP- und UDP-Overheads zu umgehen)
Wir müssen nun die Maße für Performance-Anforderungen festlegen, um dies effektiv einsetzen zu können.
Samba muss entscheidend geändert werden, um mit einem Hochgeschwindigkeitsserver Inter-Connect-System zusammenzuarbeiten und transparente Ausfallsicherheits-Cluster zu erlauben.
Zu den Funktionen innerhalb von Samba, die dadurch betroffen sind, zählen:
Die Sperren-Datenbank, Oplock-Benachrichtigungen und die Freigabemodi-Datenbank
Die Fehlersemantik muss definiert werden. Samba verhält sich so wie Windows. Wenn Oplock-Nachrichten fehlschlagen, ist eine Anforderung zum Öffnen einer Datei erlaubt, doch dies ist in einer geclusterten Umgebung potenziell gefährlich. Wie soll also Inter-Serverpool-Fehlersemantik funktionieren, und wie soll diese implementiert werden ?
Soll dies durch Nutzung eines Point-to-Point-Sperren-Managers implementiert werden, oder kann dies durch Multicast-Techniken erreicht werden?
Indem man ausfallsicheren Servern erlaubt, verschiedene Funktionen innerhalb des exportierten Dateisystems zu verwalten, beseitigt man das Problem, ein verteiltes Sperrenprotokoll zu fordern.
Falls nur ein Server in einem Paar aktiv ist, wird die Forderung nach Hochgeschwindigkeits-Server-Interconnect vermieden. Dies erlaubt dann das Nutzen von vorhandenen Hochverfügbarkeitslösungen, anstatt neue erfinden zu müssen. Diese einfachere Lösung hat jedoch ihren Preis: Man muss jetzt einen wesentlich komplexeren Dateinamensbereich verwalten. Dadurch, dass es nun nicht nur ein Dateisystem gibt, müssen sich die Administratoren daran erinnern, wo all die Dienste beheimatet sind: eine Komplexität, mit der nicht einfach umzugehen ist.
Der virtuelle Server wird weiterhin benötigt, um Anfragen an den Backend-Server weiterzuleiten. Für die Integrität des Backend-Dateibereichs ist der Administrator verantwortlich.
Ausfallsichere Server müssen miteinander kommunizieren, um Ressourcenausfälle behandeln zu können. Dies ist für hochverfügbare Dienste lebensnotwendig. Der Einsatz eines dedizierten Heartbeats ist dabei eine gängige Technik, um etwas Intelligenz in den ausfallsichernden Prozess einzuführen. Dies wird oft durch einen dedizierten Link (LAN oder seriell) bewerkstelligt.
Viele Ausfallsicherungslösungen (der Red Hat Cluster Manager genauso wie Microsoft Wolfpack) können ein geteiltes SCSI von Fiberchannel Disk Storage Arrays für eine ausfallsichere Kommunikation nutzen. Informationen zu den Red Hat-Hochverfügbarkeitslösungen für Samba können Sie hier erhalten: www.redhat.com.
Das Linux-Hochverfügbarkeitsprojekt ist eine lesenswerte Quelle, falls Sie beabsichtigen, eine hochverfügbare Dateiserver-Lösung mit Samba aufzubauen. Bitte konsultieren Sie die Homepage www.linux-ha.org.
Die Komplexität der Frontend-Server bleibt eine Herausforderung an die Hochverfügbarkeit, weil diese anständig mit Backend-Fehlern umgehen müssen, während sie zur selben Zeit den Fortlauf der Dienste für alle Netzwerkclients zur Verfügung stellen müssen.
MS-DFS Links können dazu benutzt werden, Clients zu verschiedenen Backend-Servern umzuleiten. Dies verlagert die Komplexität auf den Netzwerkclient zurück, etwas, das bereits von Microsoft vorgesehen wurde. MS-DFS erzeugt die Illusion eines einfachen und fortlaufenden Dateinamensbereichs, der sogar auf Dateiebene arbeitet.
Darüber hinaus kann, auf Kosten der Komplexität der Verwaltung, ein verteilter (Pseudo-)Cluster durch Nutzung vorhandener Samba-Funktionalität erzeugt werden.
Transparentes SMB-Clustering ist schwer durchzuführen!
Client-Ausfallsicherung ist das Beste, was wir heutzutage machen können.
Sehr viel mehr Arbeit muss erledigt werden, bevor eine praktikable und verwaltbare transparente Hochverfügbarkeits-Clusterlösung möglich sein wird.
MS-DFS kann dazu benutzt werden, die Illusion eines einzelnen transparenten Clusters zu erzeugen.