Verteilte Systeme WS 04/05

Größe: px
Ab Seite anzeigen:

Download "Verteilte Systeme WS 04/05"

Transkript

1 Fehlertolerante Dienste auf einer Cluster-Software am Beispiel OpenSSI Achim Christ Der Inhalt dieses Dokuments darf uneingeschränkt verwendet und vervielfältigt werden. Daraus entstehende Arbeiten müssen jedoch eine Referenz auf dieses Dokument und dessen Autor enthalten. The contents of this document can be freely used and distributed as far as the source is mentioned as a reference that is, its bibliograph. Version vom Mittwoch, 23. Februar 2005 Die Anforderungen an Computersysteme in unternehmenskritischen Prozessen sind enorm. Insbesondere die Forderung nach einer permanenten Verfügbarkeit bestimmter Dienste, ist durch reine Hardwarelösungen kaum umzusetzen. Festplatten können Fehler aufweisen, Prozessoren können durchbrennen, und Netzteile können ausfallen. Damit der Ausfall eines einzelnen Rechners nicht zum Stillstand des gesamten Systems führt, ist es möglich mehrere Rechner zu sog. Clustern zusammenzuschließen. Viele Computer erledigen dann eine gemeinsame Aufgabe. Dies ermöglicht es Dienste zu implementieren, deren Verfügbarkeit über die Lebenszeit einzelner Rechner hinweg gewährleistet werden kann. Dieser Artikel untersucht die Möglichkeiten, die die Linux Clustersoftware OpenSSI für die Implementierung solch hochverfügbarer Dienste bietet. Nachdem zunächst einige Grundlagen erläutert wurden, wird ein beispielhafter Dienst implementiert, der auch dann noch zur Verfügung stehen soll, wenn einzelne Rechner des Clusters ausfallen... 1

2 Inhaltsverzeichnis 1. Einleitung Motivation Ansätze Das OpenSSI Projekt Übersicht Installation Funktionsweise Funktionsumfang Komponenten Interprozesskommunikation Named Pipes (FIFOs) Signale Semaphore Sockets Shared Memory Hochverfügbarkeit Backupmodelle sicherer Speicher automatischer Prozessneustart Wiederaufsetzpunkte (Checkpoints) Designentscheidungen Beispielszenario Implementierung Verifikation Zusammenfassung Verbesserungsmöglichkeiten Performancetests Einschätzung/Ausblick...48 Literaturverzeichnis

3 1. Einleitung Was ist SSI? SSI steht für Single System Image. Dabei handelt es sich um den Ansatz, mehrere Rechner, die über ein Netzwerk miteinander verbunden sind (sog. Cluster), zu einem virtuellen System zusammenzufassen. Dieses virtuelle System stellt sich nach außen hin als ein einziger, hochverfügbarer Server dar. Ziel ist es, eine leicht skalierbare, einfach zu verwaltende Cluster- Infrastruktur bereitzustellen, die es erlaubt Anwendungen darauf auszuführen, die entweder gar nicht, oder in nur geringem Maße auf die Besonderheiten der darunter liegenden Hardwarearchitektur angepasst ist Motivation Die Anforderungen an Rechnersysteme im kommerziellen Umfeld sind in den letzten Jahren enorm angestiegen. In modernen Unternehmen laufen viele zentrale Geschäftprozesse, die eine unerlässliche Komponente für die Unternehmensvitalität darstellen, computergestützt. Ein Ausfall eines kritischen Dienstes kann gewaltige finanzielle Einbuße für ein Unternehmen darstellen. Wenn der Internetshop Amazon beispielsweise über Stunden oder Tage hinweg aufgrund eines ausgefallenen Webservers nicht erreichbar ist, und dadurch keine Artikel verkaufen kann, entsteht dem Unternehmen ein enormer Schaden. Doch eine hohe Verfügbarkeit ist nur ein Anspruch, der an moderne Rechnersysteme in Unternehmen gestellt wird. Hier die drei grundsätzlichen Anforderungen, denen unternehmenskritisch eingesetzte Computersysteme genügen müssen: Verfügbarkeit (availability) Ein computergestützter Dienst sollte auch dann erreichbar sein, wenn einzelne Komponenten in einem Computersystem ausfallen. Die Ausfallsicherheit einer einzelnen Festplatte ist beispielsweise nicht ausreichend für die Anforderungen an die Kundenkartei eines Kreditunternehmens. Skalierbarkeit (scalability) Der Erfolg eines Dienstes, und die damit verbundene Last die das Computersystem zu bewältigen hat, ist hochgradig dynamisch. Bei plötzlich auftretenden Lastspitzen sollte das Computersystem entsprechend mit der Bereitstellung von zusätzlichen Ressourcen reagieren können. Diese Anpassung muss im laufenden Betrieb möglich sein, also ohne die Abarbeitung laufender Anfragen unterbrechen zu müssen. Verwaltbarkeit (manageability) Moderne Computersysteme erfordern auf Grund ihrer Komplexität einen enormen Wartungsaufwand. Die Zeit, die für regelmäßig zu erledigende Verwaltungsarbeiten aufgewendet werden muss, sollte so gering wie möglich sein. Zu diesem Zweck ist es nötig, dass sich moderne Computersysteme so einfach und zentral wie möglich verwalten lassen, und den Systemadministrator bei Wartungsarbeiten unterstützen. 3

4 1.2. Ansätze Es gibt im Wesentlichen zwei Ansätze, die oben erwähnten Ziele, allen voran die Hochverfügbarkeit, zu erreichen: zentrale Systeme mit redundanten Komponenten, sowie verteilte, über ein Netzwerk verbundene, Systeme. Beide Ansätze werden im Folgenden kurz beschrieben: Zentrale Systeme mit redundanten Komponenten Redundante Systeme sind in der Lage, den Ausfall aller für den Betrieb notwendigen Komponenten auszugleichen. Um dieses Ziel zu erreichen wird i.d.r. ein einfaches Primär-Backup-Modell verwendet. Hierbei ist jede Komponente doppelt vorhanden, wobei jeweils nur eine Komponente aktiv ist. Fällt diese aus, übernimmt die Backup-Komponente deren Aufgaben. Ein Beispiel für die Anwendung sind RAID-Festplattensysteme, bei denen eine Platte im sog. HotSpare-Modus darauf wartet, das eine aktive Festplatte ausfällt. Einen Nachteil dieses Ansatzes stellt die Tatsache dar, dass relative teure Spezialhardware zum Einsatz kommen muss. Redundante Hardwarelösungen wie z.b. Tandem sind eher selten und erfordern speziell angepasste Softwarekonzepte. Ein gemeinsamer Betriebssystemkern verwaltet alle an das System angeschlossenen Komponenten Rechnercluster Der Begriff Cluster ohne weiter Adjektive, die den Typ des Clusters spezifizieren, kann für unterschiedliche Personengruppen unterschiedliche Bedeutungen haben. Allgemein lässt sich sagen, dass bei Clustern eine Hardwareredundanz durch den Einsatz vernetzter Standardsysteme erreicht wird. Anders als bei zentralen System mit redundanten Komponenten, sind diese Standardsysteme Massenware, und daher wesentlich kostengünstiger. Ein Ausfall eines einzelnen Systems führt nicht zum Stillstand des gesamten Clusters. Andere Rechner in dem Cluster (sog. Nodes, Knoten) können die Aufgaben des ausgefallenen Systems übernehmen (Failover). Anders als zentrale Systeme verfügen Rechnercluster i.d.r. über keine gemeinsamen physikalischen Speicherbereiche, und auf jedem Knoten läuft ein eigener Betriebssystemkern. Es gibt verschiedene Ansätze, einen Verbund von über ein Netzwerk gekoppelten Rechnern zu einem Cluster zusammenzufassen: High Performance (HP) Cluster Load-Leveling Cluster Web-Service Cluster Storage Cluster Datenbank Cluster High Availability Cluster All diese Ansätze verfolgen unterschiedliche Zielsetzungen, wobei den oben erwähnten Anforderungen an moderne Computersysteme in unterschiedlicher Weise entsprochen wird. Diese Klassifizierungen beziehen sich jedoch eher auf die Philosophie, die hinter dem Cluster steht. Eine klare Abgrenzung ist i.d.r. nicht möglich: in der Realität muss ein Web-Service Cluster natürlich auch eine (möglichst hochverfügbare) Storage-Komponente enthalten, etc. Konkrete Cluster- Implementierungen sind demnach immer Mischformen der hier aufgeführten abstrakten Typen. Im Folgenden werden die einzelnen Clustertypen näher erläutert: 4

5 High Performance Cluster High Performance Cluster (HPCs) sind darauf ausgelegt komplexe, parallele Programme (z.b. Wettersimulationen) möglichst schnell auszuführen. Dabei steuert i.d.r. ein sog. Master-Node zentral alle anderen Knoten. Der wohl berühmteste Vertreter für ein HPC ist wohl das sog. Beowulf Cluster [Beowulf]. Bei diesem Clustertyp verursacht der Ausfall eines Knotens i.d.r. einen Systemstillstand - es werden keine Ressourcen für Mechanismen wie Failover aufgewendet Load-Leveling Cluster Load-Leveling Cluster sind so konstruiert, dass ein Nutzer an einem Knoten seine Prozesslast transparent auf andere Knoten im Cluster verteilen kann. Sie eignen sich dazu rechenintensive Aufgaben mit hoher Laufzeit (long running tasks) zu bearbeiten, wenn die Programme nicht beliebig parallelisierbar sind. Der Ausfall eines Knotens kann i.d.r. ausgeglichen werden, indem Prozesse auf anderen Knoten fortgesetzt werden. Die Information des ausgefallenen Knotens geht jedoch verloren, wenn nicht andere Vorkehrungen getroffen werden (High Availability, s.u.). Ein typischer Vertreter für Load-Leveling Cluster ist Mosix [Mosix] Web-Service Cluster Der Begriff Web-Service Cluster bezeichnet eine Spezialform der Load-Leveling Cluster. Es wird nicht nur die Prozesslast, sondern insbesondere auch die Netzwerklast transparent über alle Knoten im Cluster verteilt. Einkommende Web-Service Anfragen werden an eine Gruppe von Standardservern verteilt. Da die Webserver nicht zwingend an einer gemeinsamen Kommunikation untereinander teilnehmen müssen, bezeichnet man eine solche Infrastruktur streng genommen nicht als Rechnercluster, sondern als eine sog. Rechnerfarm. Typische Vertreter sind Linux Virtual Server [LVS] und Piranha. Der Aspekt des load-leveling von Netzwerkressourcen findet jedoch in vielen Clustern Anwendung, so auch im OpenSSI Cluster, s.u Storage Cluster Die Aufgabe von Storage Clustern ist es, einen parallelen, kohärenten und hochverfügbaren Zugriff auf gemeinsame Dateisysteme zu gewährleisten. Zu den klassischen Clusterdateisystemen gehören Sistinas GFS [GFS], OpenGFS [OpenGFS] und Lustre [Lustre] Datenbank Cluster Datenbank Cluster erlauben einen gemeinsamen Zugriff auf eine hochverfügbare Datenbank. Insbesondere müssen hierbei Probleme der Transaktionskontrolle und der Kohärenz gelöst werden (ACID-Prinzip). Der berühmteste Vertreter dieses Clustertyps ist Oracle Parallel Server (OPS, inzwischen Oracle 9I RAC) [Oracle] High Availability Cluster High Availability (HA) Cluster - Hochverfügbarkeitscluster werden oft auch als Failover Cluster bezeichnet. Ein spezieller Mechanismus überwacht dabei bestimmte Ressourcen im Cluster (hauptsächlich Prozesse und Knoten), und startet im Fehlerfall vorher definierte Skripte. Mit Hilfe dieser Skripte ist das Cluster in der Lage die IP-Adressen, Dateisysteme und Prozesse des ausgefallenen Knotens auf andere Knoten umzuverteilen (sog. takeover). Zu den typischen HA Clusterkomponenten gehören [ServiceGuard], [Lifekeeper], [FailSafe] und Heartbeat [HALinux]. 5

6 2. Das OpenSSI Projekt Single System Image auf Linux-Clustern In erster Instanz ist OpenSSI eine freie Cluster-Middleware (Linux mit installiertem OpenSSI ist ein Distributed OS ), die das gesamte Rechnernetz wie eine sehr große (virtuelle) Maschine erscheinen lässt, auf der Applikationen laufen wie auf einem Multiprozessorsystem (enge Kopplung, UMA oder NUMA Eigenschaften). Da das Cluster in der Realität allerdings aus mehreren lose gekoppelten (über ein Netzwerk verbundenen) Standardrechnern besteht (es liegen NORMA-Eigenschaften vor) können nicht alle Aspekte eines Multicomputersystems verborgen werden. Im diesem Kapitel werden die einzelnen Aspekte näher beleuchtet, und aufgezeigt in wieweit die NUMA-Emulation für den Nutzer transparent abläuft Übersicht Abbildung 1. Schematischer Aufbau eines SingleSystemImage-Clusters: Abbildung aus dem Vorlesungsskript der LV 7358 'Liste V: Verteilte System' von Reinhold Kröger Der Grundgedanke besteht darin, das gesamte Cluster wie ein einzelnes System erscheinen zu lassen. Dieser Gedanke ist allerdings nicht neu! Bereits in den achtziger Jahren stellte das Locus Distributed System [Popek] eine SSI-Umgebung zur Verfügung. Auch Sun Microsystems arbeitete in der Vergangenheit an einem SSI-Projekt [Khalidi], und Gregory Pfister widmete dem Single System Image ein Kapitel in seinem Buch In Search of Clusters, in dem er behauptet das die generelle Entwicklung von Clustern erheblich beschleunigt werden könne, wenn eine größere Vielzahl an SSI-Software zur Verfügung stünde [Pfister]. Dieser Forderung folgend hat es sich das OpenSSI-Projekt zum erklärten Ziel gemacht, eine allen Ansprüchen genügende Lösung auf der Basis von Open-Source Komponenten zusammenzustellen. Die zugrunde liegenden Projekte wurden entweder integriert, oder einzelne Komponenten adaptiert bzw. portiert. OpenSSI kombiniert unterschiedlichste Werkzeuge aus der Linux-Cluster Umgebung, und erweitert diese teilweise um zusätzliche Funktionen um der Forderung nach einer einheitlichen Sicht auf das Gesamtsystem nachzukommen. Eine genauere Betrachtung der enthaltenen Komponenten folgt weiter unten. 6

7 2.2. Installation Die Installation des Clusters, sowie das hinzufügen neuer Knoten ist ein zentraler Punkt der Systemverwaltung, und damit ein wichtiges Qualitätsmerkmal von Clustersoftware. Sie sollte natürlich so einfach und schnell wie möglich erfolgen, und insbesondere das hinzufügen neuer Knoten sollte im Optimalfall vollautomatisch ablaufen. Um ein OpenSSI-Cluster aufzusetzen, muss zunächst der Init-Knoten installiert werden. Es gibt zu jedem Zeitpunkt nur einen Init-Knoten pro Cluster - fällt dieser aus, so übernimmt ein anderer Knoten seine Aufgabe (Failover). Der Init-Knoten nimmt eine zentrale Rolle in jedem Cluster ein: auf ihm läuft der Init-Prozess ( Mutter aller Prozesse - PID 1), er verwaltet z.b. die Zugehörigkeit anderer Knoten und übernimmt deren Konfiguration, synchronisiert die Systemzeit und kümmert sich um die Lastverteilung im Cluster (Load-Leveling). Die Installation des Init-Knotens unterscheidet sich daher grundlegend von der Installation aller weiteren Knoten. Auf dem Init-Knoten muss zunächst ein normales GNU/Linux-Betriebssystem installiert und konfiguriert werden. OpenSSI ist kompatibel zu RedHat-Distributionen (im Beispielszenario die Version Fedora Core 2 ), sowie Debian-Distributionen. Da die OpenSSI-Programmpakete sehr eng an den Kernel geknüpft sind, bestehen komplexe Paketabhängigkeiten, die exakt eingehalten werden müssen. Ein ursprünglicher Installationsversuch auf die an diesem Zeitpunkt aktuelle Fedora- Version 3 schlug fehl! Erst die Installation mit der älteren Version 2 führte zum Erfolg. Für die Installation der Pakete, und die Konfiguration des Init-Knotens liegen dem OpenSSI-Paket Shellskripte bei, die die nötigen Informationen vom Benutzer abfragen. Auch die anschließende Konfiguration weiterer Knoten erfolgt über solche Shellskripte. Dabei werden auf dem Init-Knoten sämtliche Daten des neuen Knotens abgefragt, so auch dessen (statische) IP-Adresse, die dem auf dem Init-Knoten laufenden DHCP-Server zur Verfügung gestellt werden. Die Installation weiterer Knoten erfolgt auf eine andere Weise. Es besteht keine Notwendigkeit ein anderes Betriebssystem zu installieren. Stattdessen wird der Rechner einfach aus dem Ethernet- Netzwerk gebootet. Es stehen zwei verschiedene Protokolle zur Verfügung: PXE, welches auf neueren Netzwerkkarten mit Intel-Chipsätzen in der Hardware implementiert ist, sowie das OpenSource-Projekt Etherboot, das für eine Vielzahl von gängigen Chipsätzen fertige Bootdisk- Images anbietet [Etherboot]. Letzteres Protokoll kommt im Beispielszenario zum Einsatz, da zwei der drei zur Verfügung stehenden Netzwerkkarten PXE nicht unterstützen (kein Eintrag im BIOS). Der zweite Knoten bootet (falls vorher dessen Konfiguration auf dem Init-Knoten vorgenommen wurde: /usr/sbin/ssi-addnode), tritt dem Cluster bei, und steht sofort zur Verfügung. Die einzigen Konfigurationsschritte die noch manuell erfolgen sollten, sind die Einrichtung einer lokalen Swap-Partition, sowie das Speichern des Boot-Images. Da auf beide Schritte aber prinzipiell auch verzichtet werden kann, ist es tatsächlich möglich dem Cluster neue Knoten hinzuzufügen, ohne an den Rechnern direkt irgendeine Konfiguration vornehmen zu müssen. Die Clusterrechner müssen damit weder über eine eigene IO-Schnittstelle verfügen (Grafikkarte, Tastatur), noch müssen sie zwingend über eine eigene Festplatte verfügen, bzw. müssen diese nicht verwenden. Zur Steigerung der Performance sollte allerdings eine lokale Partition als Swap-Partition eingerichtet werden, sowie eine lokale Kopie des Boot-Images auf einer geeigneten Partition gespeichert werden, damit dieses nicht bei jedem Bootvorgang über das Netz übertragen werden muss. 7

8 Abbildung 2. Aufbau des Clusters im Beispielszenario: Jeder der drei Knoten ist über eine Ethernet-Netzwerkkarte mit dem Clusterinternen Netzwerk verbunden. Zusätzlich verfügt der Init-Knoten über ein weiteres Netzwerkinterface, mit dem er Zugang zum Netz der Fachhochschule hat. Von dort aus ist er, und damit das gesamte Cluster, unter einer externen IP-Adresse erreichbar. Da zwei der drei Knoten kein eigenes Netzwerkinterface besitzen, das direkt mit dem Netz der Fachhochschule verbunden ist, ist ein weiterer Konfigurationsschritt notwendig. Die Knoten ohne externes NIC müssen den Init-Knoten als Gateway verwenden - seine interne Adresse wird mit onnode <knotennummer> route add -net default gw in die Kernel- Routingtabellen des entsprechenden Knotens geschrieben. Der Knoten der direkten Kontakt zum äußeren Netz hat (dies könnten auch mehrere sein), muss die einkommenden IP-Pakete an das externe Interface weiterleiten. Dies erfolgt über die Aktivierung des sog. IP-Forwarding mit dem Befehl echo "1" > /proc/sys/net/ipv4/ip_forward. Da die externe IP-Adresse auf einem anderen Subnetz liegt als die des Cluster-Interconnects, muss nach außen hin zusätzlich noch eine Network Adress Translation (NAT) durchgeführt werden. Dabei werden die Absender-Adressen von ausgehenden IP-Paketen mit der IP-Adresse des externen Interfaces ersetzt - von außen betrachtet scheinen alle IP-Pakete von dem NIC im externen Subnetz zu stammen. Die internen IP-Adressen bleiben nach außen verborgen. Die Konfiguration der NAT erfolgt im Beispielszenario mit dem Befehl iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE. Als weiterführende Dokumentation seien an dieser Stelle die verschiedenen README-files im Verzeichnis /usr/share/doc/openssi_tools/ empfohlen. Speziell die Datei README.CVIP, die sich mit der Konfiguration der CVIP beschäftigt, ist sehr hilfreich! 8

9 2.3. Funktionsweise Das OpenSSI-Cluster besitzt einige Merkmale, die es von anderen Lösungen grundsätzlich unterscheidet. So besteht das Cluster aus einem Betriebssystem-Kernel pro Knoten, die alle über eine Netzwerkverbindung miteinander kommunizieren. Dabei arbeiten alle Kernel mit dem selben Root-Dateisystem - dieses enthält keine, bzw. nur wenige knotenspezifischen Dateien. Mit Hilfe der Kernel-zu-Kernel Kommunikationskanäle stellen alle Knoten gemeinsam eine hochverfügbare virtuelle Maschine auf Systemaufrufebene bereit. Durch diese Zusammenarbeit wird ein clusterweiter Namensraum für alle Kernelobjekte, sowie ein kohärenter Zugriff darauf gewährleistet. Die folgende Darstellung veranschaulicht wie nichtangepasste Anwendungen mit einem Standard-Kernel kommunizieren, der mit speziellen SSI- Erweiterungen ausgestattet ist. Diese Erweiterungen erlauben es dem Kernel seinen Zugriff auf Objekte wie Prozesse, Dateien, Message Queues oder Devices mit anderen Knoten zu koordinieren. Darüber hinaus erlaubt eine zusätzliche Systemschnittstelle (API) speziell angepassten Anwendungen selbst Eingriff in die SSI-Funktionalität zu nehmen. Nur auf diesem Weg können Anwendungen alle Dienstleistungen der Cluster-Software voll ausnutzen, um eine höhere Skalierbarkeit, Verfügbarkeit und Wartbarkeit zu erreichen. Abbildung 3. Schematische Funktionsweise der Software: 9

10 2.4. Funktionsumfang Die offene SSI-Implementierung OpenSSI besteht aus mehreren Modulen, die einige Aspekte eines eng gekoppelten Systems nachbilden. Von OpenSSI emulierte Aspekte eines Multiprozessorsystems: Gemeinsames, clusterweites Root-Dateisystem Atomare Sichtbarkeit aller Dateisysteme auf allen Knoten Auf alle angeschlossenen Devices kann von allen Knoten aus zugegriffen werden Gemeinsamer, clusterweiter Prozessraum Sämtliche Möglichkeiten der Interprozesskommunikation wurden umgesetzt, und sind in gleicher Weise anwendbar wie auf klassischen Einprozessorsystemen Besonders interessant hierbei: Distributed Shared Memory! automatische und manuelle Lastverteilung ( Load Balancing ) von Prozessor-, Speicher- und Netzwerkressourcen Cluster Alias : virtuelle IP Adresse, unter der das gesamte Cluster erreichbar ist zentrale Systemverwaltung ( System Management ) Die oben erwähnten Aspekte werden jeweils von unterschiedlichen Komponenten der Clustersoftware umgesetzt, die im Folgenden näher beschrieben werden: 2.5. Komponenten OpenSSI integriert, wie bereits erläutert, eine Vielzahl anderer Open-Source-Projekte. Eine zentrale Rolle bei der Entwicklung von OpenSSI spielt dabei zunächst einmal NonStop Clusters for Unixware [NSC], einem Produkt von Compaq und SCO/Caldera. Es basierte auf früheren Arbeiten von G. Popek [Popek] und B. Walker [Walker], und große Teile der OpenSSI-Funktionalitäten wurden von NSC portiert (z.b. Prozessverwaltung, Filesysteme, Failover...). Der Teil von NSC, der die Verwaltung der Zugehörigkeit von Knoten, und die Interprozesskommunikation zur Verfügung stellt, wurde bereits früher vom Cluster-Infrastructure [CI] Projekt auf Linux portiert. Das CI- Projekt wurde vollständig in OpenSSI integriert. Das Clusterdateisystem GFS wurde ursprünglich von Sistina entwickelt [GFS], steht jedoch auch als freie Implementierung [OpenGFS] zur Verfügung, genau wie das Lustre Dateisystem [Lustre]. Der Distributed Lock Manager ist ein IBM-Produkt, dessen Codebasis unter die GPL gestellt wurde [OpenDLM], und das für OpenSSI mit dem CI-Projekt kombiniert wurde, um ein dynamisches hinzufügen bzw. entfernen von Knoten zu erlauben. Das Linux Virtual Server Projekt [LVS] wurde integriert um ein Failover von IP-Adressen zu ermöglichen, und vom Mosix Projekt [Mosix] stammt der Code der Load-Leveling realisiert. 10

11 Cluster Membership Der ClusterMembership Code wurde größtenteils vom NonStop Cluster-Projekt adaptiert. Er enthält Algorithmen um das Cluster zu bilden, also die Zugehörigkeit von einzelnen Knoten zu verwalten und zu überwachen. Dazu gehört die Abarbeitung von sog. Nodeup / Nodedown -Routinen und der Versand von entsprechenden Signalen um Prozesse von solchen Ereignissen zu informieren. Außerdem wird dem Anwendungsentwickler eine sog. Membership API zur Verfügung gestellt, um entsprechend auf diese Ereignisse reagieren zu können. Der sog. Cluster Membership Service (CLMS) ist ein Programmcode, der auf allen Knoten ausgeführt wird. Dabei läuft jeder Knoten entweder als Master, oder als Slave. Es gibt zu jedem Zeitpunkt nur einen Master-Knoten im Cluster - fällt dieser aus, so findet ein entsprechendes Takeover statt. Der Master-Knoten führt Algorithmen aus, die die Zustände aller Knoten im Cluster verwalten und überwachen. Mögliche Zustände sind: NeverUP, ComingUP, UP, Shutdown, Goingdown und Down. Da diese Zustandsverwaltung zentral auf dem Master-Knoten durchgeführt wird, sind Zustandswechsel immer atomar und clusterweit - alle Knoten erhalten stets die selben Information. Um zu überwachen, ob Knoten noch aktiv, oder bereits ausgefallen sind, ist im CLMS Code auch eine spezielle Version der Heartbeat-Software enthalten. Diese sendet in regelmäßigen Abständen spezielle IP-Pakete an alle Knoten des Clusters. Die Knoten, von denen nach Ablauf einer bestimmten Zeitspanne keine Antwort zurückkommt, werden als Down eingestuft. Die Konfiguration der Parameter dieses Verhaltens erfolgt im /proc/cluster-verzeichnis, welches auch für andere Einstellungen genutzt wird (z.b. Parameter des Load-Leveling, Cluster-Alias etc.). Das CLMS Subsystem verwendet das darunter liegende Inter-node Communication Subsystem: Inter-node Communication Subsystem (ICS) ICS ist der zentrale Kernel-zu-Kernel Kommunikationkanal, der von allen anderen SSI- Komponenten (direkt oder indirekt) genutzt wird. Genau wie CLMS wurde ICS vom NonStop Cluster-Projekt adaptiert. Dabei besteht die Kommunikationsschicht genau genommen aus zwei weiteren Schichten: eine transportunabhängige (obere), und eine transportabhängige (untere) Schicht. Die obere, transportunabhängige Schicht stellt die Schnittstelle zu anderen Kernelsubsystemen dar. Dabei werden drei Programmierparadigmen unterstützt: RPC, request/response (asynchrones RPC) sowie Nachrichtenaustausch. Die obere Schicht enthält einen dynamischen Threadpool um einkommende Anfragen zu bearbeiten, zu priorisieren und evtl. in Messagequeues einzureihen. Die untere, transportabhängige Schicht stellt die Schnittstelle zur darunter liegenden Netzwerkschicht dar. Die aktuelle OpenSSI-Version unterstützt dabei nur TCP-Verbindungen. Andere Protokolle werden aber in Zukunft auch unterstützt werden... Das ICS arbeitet mit dem CLMS zusammen, um die Kommunikation mit einem Knoten aufzubauen wenn er dem Cluster beitritt, bzw. abzubauen wenn er das Cluster verlässt. 11

12 Distributed Lock Manager (DLM) Der DLM ist ein hauptsächlich von IBM vorangetriebenes OpenSource-Projekt. Er läuft auf jedem Knoten, und ist in das CLMS integriert. Die wesentliche Aufgabe des DLMs ist es, verschiedene Formen von Cache-Kohärenz zwischen den Knoten des Clusters zu gewährleisten. Eine konkrete Form ist z.b. der Kernel-Filesystem-Cache. Eine andere Aufgabe ist die Kohärenz von Applikationscaches sicherzustellen. Die Oracle Parallel Server (OPS) Datenbank war eine der ersten Anwendungen, die den DLM nutzte - aber auch die in OpenSSI enthaltene Version des GFS- Dateisystems macht davon Gebrauch Clusterweites Dateisystem Das Ziel des Dateisystems im OpenSSI-Projekt ist es, zu jeder Zeit einen automatischen, transparenten, kohärenten Zugriff auf alle Dateien von allen Knoten aus zu gewährleisten. Dazu gehört neben dem eigentlichen Root-Dateisystem auch der Zugriff auf alle angeschlossen Devices. Es gibt im Wesentlichen drei Ansätze für Cluster-Dateisysteme - OpenSSI unterstützt sie alle: Der erste Ansatz kann als paralleles physikalisches Dateisystem bezeichnet werden. Dabei läuft auf jedem Knoten eine Instanz des Dateisystems. Jede dieser Instanzen greift direkt auf das (einzige) "physikalische" Speichermedium zu, besitzt dort jedoch einen eigenen Bereich für z.b. Log-Daten. Dieses Speichermedium kann entweder die interne Festplatte eines Knotens im Cluster darstellen (Beispielszenario), oder ein externes, unabhängiges Festplattensystem sein. Letztere Alternative bietet den Vorteil, das mehrere Knoten für das eigentliche Ansteuern der Festplatte in Frage kommen, und daher ein entsprechendes Failover stattfinden kann... Die einzelnen Dateisysteminstanzen koordinieren ihren Cache mit Hilfe des DLMs. Beispiele für diesen Ansatz sind Sistina GFS und OpenGFS, welches in OpenSSI standardmäßig zum Einsatz kommt. Ein anderer Ansatz wird beispielsweise vom Lustre-Projekt verfolgt: das Root-Dateisystem ist über mehrere sog. Storage-Nodes verteilt. Jeder Knoten im Cluster kontaktiert zunächst einen sog. Metadata-Server, von dem er die Informationen über das Layout des Dateisystems erhält - also welche Storage-Nodes welche Teile des Dateisystems bereitstellen. Danach ist es möglich, Daten parallel von mehreren Knoten gleichzeitig zu beziehen, was einen erheblichen Geschwindigkeitsvorteil mit sich bringt. Außerdem können Storage-Nodes so konfiguriert werden, dass sie Daten mehrfach redundant vorhalten: ein Verfahren wie es von RAID-Devices bekannt ist. Die Verfügbarkeit wichtiger Daten wird so auch bei Ausfall einzelner Storage-Knoten gewährleistet. Der dritte Ansatz funktioniert ähnlich wie der eben vorgestellte: Die Klienten kommunizieren mit einem bestimmten Knoten für jedes Dateisystem. Jeder Knoten im Cluster kann ein oder mehrere Dateisysteme zur Verfügung stellen. Der Zugriff auf Daten erfolgt nicht so parallel wie beim Lustre- Projekt, doch der Ansatz bietet dafür einen anderen Vorteil: Es können unterschiedliche physikalische Dateisysteme miteinander kombiniert werden, wie z.b. JFS, XFS, cdfs, ext3 usw., und daher wesentlich heterogenere Cluster aufgebaut werden Clusterweites Prozess-Subsystem Zu den Zielen des clusterweiten Prozesssystems gehört die Gewährleistung der transparenten Sichtbarkeit und Ausführbarkeit aller Prozesse auf allen Knoten. Daraus entsteht die Fähigkeit einzelne Prozesse oder ganze Prozessgruppen von einem Knoten auf einen anderen zu migrieren, während der Prozess läuft. Außerdem werden Mechanismen zur Verfügung gestellt, die Prozesslast 12

13 möglichst gleichmäßig im Cluster zu verteilen - das sog. Load-Leveling. Folgende Maßnahmen wurden im OpenSSI-Projekt ergriffen, um die oben erwähnten Ziele zu erreichen: Prozesse werden mit clusterweit eindeutigen Prozess-IDs (pids) gekennzeichnet, welche sie auch dann behalten, wenn sie auf einen anderen Knoten migrieren. Betriebssystemaufrufe (system calls) werden zunächst auf dem Knoten ausgeführt, auf dem der aufrufende Prozess läuft. Falls zur Abarbeitung Ressourcen benötigt werden, die sich auf anderen Knoten im Cluster befinden, werden entsprechende Anfragen über das ICS gesendet. Der Prozess merkt davon jedoch nichts! Ressourcen (wie z.b. IPC-Objekte) werden redundant im Cluster gespeichert, um deren Rekonstruktion bei einem Knotenausfall zu ermöglichen. Es wurden spezielle Betriebssystemaufrufe hinzugefügt, ohne jedoch vorhandene Aufrufe zu modifizieren. Mit den Funktionen rexec(), rfork(), migrate() und kill3() können speziell angepasste Applikationen das sog. Process-Placement steuern. Außerdem steht ein sigmigrate Signal zur Verfügung, mit dem die Applikation auf Änderungen des Process-Placements von außen reagieren kann. Es steht ein optionales Process Load-Balancing Subsystem zur Verfügung, mit dem eine automatische Umverteilung der Prozesslast im Cluster realisiert werden kann, um die zur Verfügung stehenden Ressourcen optimal auszunutzen. Die entsprechenden Algorithmen entstammen dem Mosix-Projekt. Um diesen Vorteil auch für Anwendungen zu nutzen, die selbst nicht speziell für OpenSSI- Cluster angepasst wurden, steht eine sog. load-leveling-shell (bash-ll) zur Verfügung. Von dort aus aufgerufene Anwendungen werden automatisch auf dem Knoten gestartet, der die niedrigste Prozesslast aufweist. Außerdem können auch aus der normalen Shell heraus einzelne Programme auf dem Knoten gestartet werden, der die niedrigste Prozesslast aufweist (fast- Kommando). Dieses Verhalten setzt sich auch bei Prozessen fort, die wiederum von der Anwendung gestartet werden. Der Apache Webserver beispielsweise erzeugt nach seinem Start mehrere sog. Worker-Prozesse. Diese werden vom Load-Balancing Subsystem ebenfalls automatisch auf alle Knoten im Cluster verteilt. Zur Konfiguration welche Anwendungen automatisch auf andere Knoten migriert werden dürfen, und unter welchen Kriterien diese Auswahl stattfindet, steht im /proc-verzeichnis des Betriebssystems ein spezielles Unterverzeichnis /proc/cluster zur Verfügung. Dort können noch weitere Einstellungen für das gesamte Cluster vorgenommen werden, z.b. das Cluster- Alias, oder Parameter der Heartbeat-Komponente. Ein wichtiger Aspekt, auf den bei all diesen Maßnahmen geachtet wurde, ist die Kompatibilität zu nicht angepassten Anwendungen. Herkömmliche Applikationen laufen ohne weitere Anpassungen in einem OpenSSI-Cluster. Trotzdem haben speziell angepasste Anwendungen die Möglichkeit mit zusätzlichen Betriebssystemaufrufen selbst Eingriff in das Process-Placement zu nehmen, um beispielsweise die Vorteile von automatischem load-balancing zu nutzen. 13

14 Keepalive/Spawndaemon Eine zusätzlich in OpenSSI enthaltene Komponente ist das Programm Keepalive. Dessen Integration stellt eine der offensichtlichsten Neuerungen der OpenSSI-Version gegenüber der Version dar. Der Code des Keepalive-Mechanismus entstammt, wie viele andere Komponenten auch, dem NonStop-Cluster Projekt. spawndaemon stellt dabei eigentlich nur ein Konfigurationsinterface für den verwendeten keepalive-daemon zur Verfügung. Dieser überwacht bestimmte Anwendungen (welche mit Hilfe von Spawndaemon-Konfigurationsskripten registriert werden). Fällt eine ihm unterstellte Anwendung aus, führt er im Normalfall ein entsprechendes Restartskript aus, um eine neue Instanz des Prozesses zu erzeugen. Der Keepalive-Daemon bietet umfassende Konfigurationsmöglichkeiten, und erlaubt es sehr genau festzulegen wann, wo und wie ein Programm neu zu starten ist. Über ein Commandlineinterface ist es möglich unterschiedlichste Parameter zu definieren, um beispielsweise Prozesse nur, oder bevorzugt auf einer bestimmten Knotenmenge auszuführen. Außerdem kann das Verhalten abhängig von Returncodes der Anwendung festgelegt werden. So ist es beispielsweise auch möglich, beim Beenden der Anwendung mit einem bestimmten Rückgabewert eben keinen Neustart mehr auszuführen Clusterweites Device-Subsystem Die Ziele des Device-Managers in SSI-Clustern sind eindeutige, clusterweite Namen für alle angeschlossenen Devices zu vergeben, und einen transparenten Zugriff von allen Knoten aus zu gewährleisten. Devices die eine physikalische Verbindung zu mehreren Knoten besitzen, sollten nur einen einzigen Namen erhalten. Die Device-Nummern (die mit dem stat() Systemaufruf eingesehen werden können) müssen clusterweite Gültigkeit haben, und sowohl die Namen, als auch die Device-Nummern müssen einen Reboot des Clusters überdauern - ihre Vergabe muss unabhängig von der Reihenfolge erfolgen, in der die Knoten des Clusters gebootet werden. Die Umsetzung dieser Ziele erfolgt mit Hilfe von Kernel-Erweiterungen, und nicht über Anpassung der Device-Treiber! Zunächst wird jedem Device eine im Cluster eindeutige Nummer zugeordnet, die auf eine knotenspezifische Nummer gemappt wird, die der Device-Treiber benötigt. Diese clusterweite Nummer wird dem stat()-interface zur Verfügung gestellt, zusammen mit der Information an welchen Knoten das Device angeschlossen ist, und welche knotenspezifische Nummer der Treiber hat. Diese Informationen werden an alle Kernel im Cluster weitergegeben, wodurch ein Aufruf direkt vom aufrufenden Knoten zu dem Knoten ausgeführt werden kann, an dem das Device angeschlossen ist. Es muss keine zentrale Instanz zwischengeschaltet werden, was einen Performancevorteil mit sich bringt. Das /dev Verzeichnis ist in OpenSSI-Clustern ein kontextabhängiger Symlink. Per Default zeigt er auf ein Verzeichnis, in dem sämtliche im Cluster vorhandenen Devices aufgeführt sind, sowie Unterverzeichnisse mit den Devices für jeden Knoten. Zusätzlich zu diesem Default kann der Symlink auch auf ein Verzeichnis zeigen, in dem nur die an den jeweiligen Knoten angeschlossenen Devices aufgeführt sind. Dadurch wird eine Kompatibilität zu Anwendungen erreicht, die nicht mit speziellen OpenSSI-Libraries gelinkt wurden, 14

15 Cluster Logical Volume Management (CLVM) Der logical volume manager (LVM) stellt eine Abstraktionsebene dar, der die Grenzen physikalischer Partitionen aufweicht, um logische Einheiten zur Verfügung zu stellen. Eine solche logische Einheit kann aus mehreren physikalischen Partitionen bestehen - mehrere Festplatten können zu einem einzigen, großen Filesystem zusammengefasst werden. Die Umsetzung dieses Konzeptes ist im OpenSSI-Projekt bisher noch unvollständig - unter Anderem auf Grund der vielen unterschiedlichen Dateisystemansätze, und komplexer Kohärenzprobleme, die auftreten wenn zwei Knoten gleichzeitig versuchen die Struktur der logischen Volumes zu verändern. Dieses Problem zu lösen ist der DLM (noch) nicht in der Lage. Für die Zukunft ist aber die Integration eines CLVM-Subsystems geplant. Ein Kandidat ist z.b. EVMS doch dessen Integration in OpenSSI ist noch nicht vollzogen Clusterweites Netzwerk-Subsystem Um eine möglichst hohe Netzwerkperformance des Clusters zu erreichen, ist es nötig die Kommunikation zwischen Knoten im Cluster so gering wie möglich zu halten. Es sollten so viele Ressourcen wie möglich für die Kommunikation nach außen zur Verfügung stehen. Um den SSI- Aspekt des Clusters zu realisieren ist ein gewisser Kommunikationsaufwand zwischen den Clusterknoten jedoch unumgänglich. Gegenüber der Außenwelt sollte sich das gesamte Cluster wie eine einzige, hochverfügbare Maschine darstellen. Das Linux Virtual Server (LVS) Projekt erfüllt einen Großteil dieser Anforderungen, und wurde daher in das OpenSSI-Projekt integriert. Dem Cluster wird eine einzige IP-Adresse zugewiesen, unter der es von außen zu erreichen ist. Einkommende Verbindungen werden an verschiedene Knoten weitergeleitet. An dieser Stelle kommen Load-Leveling-Algorithmen zum Einsatz, um die anfallende Netzwerklast möglichst gleichmäßig im Cluster zu verteilen. Das OpenSSI-Projekt erweitert dabei das eigentliche LVS-Projekt dahingehend, dass es die Konfiguration teilweise automatisiert und zusätzliche Failover-Funktionalitäten zur Verfügung stellt. Einige Aspekte eines SSI-Netzwerksystems im strengen Sinne werden allerdings durch LVS nicht abgedeckt. So sollten beispielsweise Prozesse innerhalb des Clusters über das Loopback-Interface kommunizieren können, auch wenn sie auf unterschiedlichen Knoten laufen. Außerdem sollten alle im Cluster vorhandenen Netzwerkinterfaces (also auch die für die interne Kommunikation verwendeten), bzw. deren IP-Adressen auf allen Knoten wie lokale IP-Adressen erscheinen. LVS lässt nur die Cluster-IP-Adresse auf allen Knoten lokal erscheinen. Die bisher integriert Basisfunktionalität reicht aber für die meisten Anwendungen aus. Eine Erweiterung des Konzepts um weitere, SSI-spezifische Aspekte ist in Arbeit Clusterweite Systemverwaltung Das Ziel der Systemverwaltung in OpenSSI-Clustern ist es, dem Administrator die Möglichkeit zu bieten klassische Systemtools für Einzelsysteme weiterzuverwenden. Es sollten keine, bzw. möglichst wenige spezielle Cluster-Management Tools benötigt werden. Dieses Ziel war auch einer der Hauptaspekte, der beim NonStop Clusters Projekt im Vordergrund stand. Tools, deren Notwendigkeit in einem Cluster allerdings unumgänglich ist, sind z.b. Monitore, die anzeigen welche Knoten zur Verfügung stehen, sowie Monitore die Anzeigen von welchen Knoten eine bestimmte Ressource verwendet wird. 15

16 Einige Befehle, die für OpenSSI-Cluster angepasst wurden, um das selbe Verhalten zu realisieren wie auf klassischen Systemen sind: ps zum Anzeigen aller im Cluster laufenden Prozesse (um zusätzliche Parameter erweitert, um nur die Prozesse bestimmter Knoten anzuzeigen), top zum Darstellen der Prozesslast in Echtzeit, sowie fuser, rc, sysinit und who. Außerdem steht ein localview Kommando zur Verfügung, mit dem Programme in einem Kompatibilätsmodus gestartet werden können, in dem sie nur Informationen über den Knoten erhalten, auf dem sie ausgeführt werden (localview ps zeigt beispielsweise nur die Prozesse des aktuellen Knotens an). Außerdem bietet OpenSSI dem Administrator die Möglichkeit von einem Terminal auf einem beliebeigen Knoten aus, Befehle auf anderen Knoten auszuführen, ohne dort ein Terminal öffnen zu müssen. Auch das Ausführen eines Befehls auf allen oder nur bestimmten Knoten des Clusters ist möglich (sog. Broadcast ). Aus diesem Grund muss prinzipiell nur ein einziger Knoten über ein User-Interface verfügen (Grafikkarte, Tastatur, etc). Dieses Verhalten ist nicht mit der Möglichkeit zu verwechseln, die auch klassische Linux-Systeme bieten z.b. über Telnet oder SSH eine Verbindung zu dem Rechner aufzubauen. Die Fernwartungsmöglichkeiten von OpenSSI-Clustern liegen auf Betriebssystemebene, und nich auf Applikationsebene. Wenn auf einem klassischen Linux-System z.b. der SSH-Daemon abstürzt oder beendet wird, gibt es keine Möglichkeit mehr auf dem System von der Ferne aus Befehle auszuführen. Solange auf einem OpenSSI-Knoten der Kernel läuft, akzeptiert er Befehle von anderen Knoten. Diese Kommunikation erfolgt über das clusterinterne Kommunikationssubsystem ICS, und ist z.b. nicht auf vom Anwender konfigurierte IP-Routing-Tabellen angewiesen, und wird auch nicht von evtl. vorhandenen Firewalls beeinflusst. Zur Systemverwaltung gehört weiterhin auch die Installation neuer Knoten, sowie der Bootvorgang. Um ein OpenSSI-Cluster aufzusetzen muss nur der erste Knoten im herkömmlichen Sinne installiert werden. Zusätzliche Knoten booten automatisch über die Netzwerkverbindung, über die dann auch die Installation der nötigen Software geschieht. Dabei muss keine bestimmte Reihenfolge eingehalten werden Clusterweite Zeitsynchronisation OpenSSI-Cluster enthalten einen rudimentären Mechanismus, um die Systemzeit aller Knoten abzugleichen. Während des Boot-Vorgangs werden die Systemzeiten aller Knoten an die Systemzeit des Init-Knotens angegelichen (es gibt immer nur einen Init-Knoten, im Fehlerfall findet ein failover statt). Eine manuelle Synchronisation kann mit dem Shellbefehl ssi-timesync erzwungen werden Clusterweite Interprozesskommunikation (IPC) In Linux gibt es eine Fülle an IPC-Konzepten: Signale, Pipes, FIFOs, Semaphore, Message Queues, Shared Memory sowie Internet- und UnixDomain-Sockets. All diese Konzepte wurden in OpenSSI umgesetzt. Vergebene Namen haben clusterweite Gültigkeit (zentralen IPC-Nameserver), was eine Verwendung von allen Knoten aus ermöglicht. IPC-Objekte werden aus Performancegründen stets lokal erzeugt. Allerdings werden Kopien auch auf anderen Knoten gespeichert, um deren Weiterverwendbarkeit nach einem Knotenausfall zu gewährleisten. Diese Mechanismen sollen für den Anwendungsentwickler völlig transparent ablaufen. Alle IPC- Aufrufe verhalten sich wie auf klassischen Einprozessorsystemen gewohnt. Für die Anwendung sollte es keinen Unterschied machen, ob z.b. eine Pipe nur zwischen zwei Prozessen eines Knotens aufgebaut wird, oder ob Knotengrenzen überschritten werden. 16

17 3. Interprozesskommunikation Test der IPC-Betriebssystemeigenschaften auf OpenSSI-Clustern Moderne UNIX-basierte Betriebssysteme stellen dem Anwender eine Vielzahl von Mechanismen zur Verfügung, Anwendungen über Prozessgrenzen hinweg miteinander interagieren zu lassen. Der Austausch von Nachrichten ist nur einer der Hauptaspekte der Iterprozesskommunikation. Daneben ermöglichen z.b. Semaphore die Zugriffskontrolle kritischer Ressourcen, und unterstützen den Entwickler bei der Implementierung zeitlicher Synchronisationsmechanismen. Im Folgenden werden einige Interprozess-Konzepte näher untersucht. Dabei wird vor allem die Frage beantwortet, in wieweit die Abbildung des SingleSystemImage auf ein Multicomputersystem für den Nutzer transparent verläuft Named Pipes (FIFOs) Named Pipes stellen global referenzierbare Kommunikationskanäle dar, in die geschrieben, bzw. aus denen gelesen werden kann wie aus normalen Dateien (read(),write()). Die Bereitstellung des nötigen Puffers (FIFO, First In First Out), sowie die Bewältigung des damit verbundenen Erzeuger- Verbraucher-Problems, realisiert das Betriebssystem über spezielle Einträge (I-Nodes) im Dateisystem, die einen Speicherbereich abbilden. Auf einem SSI-Cluster sollten diese Kommunikationskänale von allen Knoten aus sichtbar und benutzbar sein. Folgendes Beispiel testet dieses Verhalten: Beispiel 1. Erzeugung und Test einer Named Pipe: Die Pipe wird auf einem beliebigen Knoten initialisiert: achim]$ mkfifo./fifo1 Von verschiedenen Knoten aus wird nun etwas hineingeschrieben: achim]$ onnode 1 echo "Hallo vom Init-Knoten" >./fifo1 achim]$ onnode 2 echo "Nochmal Hallo, diesmal vom \ > Knoten 2" >>./fifo1 Der letzte Knoten gibt nun den Inhalt der Pipe aus achim]$ onnode 3 cat./fifo1 Hallo vom Init-Knoten Nochmal Hallo, diesmal vom Knoten 2 Die Funktionalität von Named Pipes ist in der OpenSSI-Umgebung eigentlich trivial. Durch die Bereitstellung eines clusterweiten Root-Dateisystems (GFS, Lustre, etc.), sind auch alle anderen Dateien von überall aus les- und schreibbar. Gleiches Verhalten ist also auch mit normalen Dateien realisierbar - in dem obigen Beispiel könnte die erste Zeile (mkfifo...) auch weggelassen werden, und es würde stattdessen eine normale Datei zur Speicherung der Daten verwendet. 17

18 Pipes (auch solche ohne Namen) stellen also automatisch aufgebaute Kommunikationskanäle zwischen den Knoten dar. Folgendes Beispiel zeigt, wie die Shell eine Pipe zwischen zwei Knoten aufbaut: Beispiel 2. Normale Pipe zwischen zwei Knoten: achim]$ onnode 2 echo "Dieser Text wird automatisch \ > auf einen anderen Knoten übertragen" onnode 3 wc -c Signale Signale sind kleine Nachrichten die das Betriebsystem automatisch zwischen verschiedenen Prozessen zustellt. Im Gegensatz zu echten Nachrichten, können Signale allerdings keine Nutzinformation enthalten - ihre bloße Existenz ist die einzige Information die der Empfänger verwerten kann. Außerdem treffen sie asynchron zum normalen Programmfluss ein, und unterbrechen dadurch evtl. in der Ausführung befindliche Befehle! Das Linux-Betriebssystem selbst nutzt Nachrichten, um z.b. Prozesse zu beenden (SIGTERM bzw. SIGKILL), oder davon zu Informieren, das ein Kindprozess gestorben ist (SIGCHLD). Useranwendungen können ebenfalls Signale versenden, und eintreffende Signale empfangen (es besteht auch die Möglichkeit die vom Betriebssystem versandten Signale abzufangen, und damit selbst Einfluss auf das Verhalten in einem entsprechenden Fall zu nehmen). Daneben stehen noch Signale zur Verfügung, die der User für seine eigenen Zwecke verwenden kann (SIGUSR). Auf SSI-Clustern sollte es keinen Unterschied machen, ob die an der Signalkommunikation beteiligten Prozesse auf dem selben Knoten, oder auf unterschiedlichen Knoten des Clusters laufen. Folgendes Beispiel untersucht, ob das Senden und Empfangen von Signalen tatsächlich transparent über Knotengrenzen hinweg möglich ist: Beispiel 3. Senden und Empfangen von Signalen: Folgendes C-Programm versendet zunächst Usersignale an den Prozess mit der als Parameter übergebenen PID, und schickt ihm letztlich eine Aufforderung sich zu beenden: 1 /* sigsend.c */ #include <stdlib.h> #include <signal.h> 5 int main(int argc, char* argv[]) int i, recv_pid; recv_pid = atoi(argv[1]); 10 for (i=0; i<5; i++) kill(recv_pid, SIGUSR1); sleep(1); kill(recv_pid, SIGUSR2); 15 sleep(1); 20 kill(recv_pid, SIGTERM); return 0; Das entsprechende Gegenstück stellt folgendes Programm dar. Es teilt dem Betriebssystem mit, 18

19 welche Prozeduren beim Eintreffen eines entsprechenden Signals auszuführen sind. Zusätzlich wird ein weiterer Signal-Handler für das Abarbeiten eines Timerevents registriert: 1 /* sigrecv.c */ #include <stdio.h> #include <stdlib.h> 5 #include <signal.h> #include <unistd.h> int main(int argc, char* argv[]) 10 struct sigaction sig1; sig1.sa_flags = 0; sigemptyset(&sig1.sa_mask); 15 /* Signal-Handler aufsetzen */ sig1.sa_handler = usrsig_handler; if ((rv = sigaction(sigusr1, &sig1, &sig2))!= 0) perror("sigaction(sigusr1)"), exit(1); if ((rv = sigaction(sigusr2, &sig1, &sig2))!= 0) 20 perror("sigaction(sigusr2)"), exit(1); 25 sig1.sa_handler = alarm_handler; if ((rv = sigaction(sigalrm, &sig1, &sig2))!= 0) perror("sigaction(sigalrm)"), exit(1); sig1.sa_handler = term_handler; if ((rv = sigaction(sigterm, &sig1, &sig2))!= 0) perror("sigaction(sigterm)"), exit(1); 30 /* Wecker stellen (3sek.) */ alarm(3); 35 /* Endlos Loopen */ while(1); return 0; Die hier referenzierten Signal-Handler, also die Prozeduren die beim Eintreffen eines entsprechenden Signals aufgerufen werden, sehen folgendermaßen aus: 1 void term_handler(int sig) printf("programmende!\n"); exit(0); 5 void alarm_handler(int sig) printf("timer abgelaufen!\n"); /* neuen Alarm stellen */ 10 alarm(3); void usrsig_handler(int sig) 15 if (sig == SIGUSR1) printf("signal SIGUSR1 empfangen!\n"); else printf("signal SIGUSR2 empfangen!\n"); Nun werden beide Programme auf unterschiedlichen Knoten ausgeführt: achim]$ onnode 2 sigrecv & [1] achim]$ onnode 3 sigsend Signal SIGUSR1 empfangen! Signal SIGUSR2 empfangen! Signal SIGUSR1 empfangen! Timer abgelaufen! Signal SIGUSR2 empfangen! Signal SIGUSR1 empfangen! Signal SIGUSR2 empfangen! Timer abgelaufen! Signal SIGUSR1 empfangen! Signal SIGUSR2 empfangen! Signal SIGUSR1 empfangen! Timer abgelaufen! Signal SIGUSR2 empfangen! Programmende! 19

20 3.3. Semaphore Es gibt zwei Typen von Semaphoren: binäre und Zählsemaphore. Erstere (sog. Mutexe ) können nur die Zustände 0 und 1 annehmen, wogegen letztere als Zähler verwendet werden können. Da die Änderung des Wertes eines Semaphors stets eine atomare, also ununterbrechbare Aktion darstellt, eignen sich Semaphore dazu den Zugang zu kritischen Ressourcen zu schützen. Es kann sichergestellt werden, dass nur eine bestimmte Anzahl parallel ablaufender Prozesse (oft nur ein einziger) einen bestimmten Codeabschnitt betritt, in dem der Zugriff auf eine kritische Ressource stattfindet. Solch kritische Ressourcen sind typischerweise komplexe Datenstrukturen oder IO- Geräte, wie z.b. Festplatten. In folgendem Beispiel ist die zu schützende Ressource das tty-device des Users, also der Bildschirm. Das Beispiel demonstriert, wie Semaphore im gesamten Cluster Gültigkeit besitzen und sich daher dazu eignen, clusterweite Ressourcenzugriffe zu kontrollieren: Beispiel 4. Erzeugen und Testen eines clusterweiten Semaphors: Zunächst muss ein entsprechender Semaphor erzeugt werden. Dies erledigt ein kleines C- Programm... Dabei ist in diesem Beispiel ein binärer Semaphor nötig, da nur eine Prozessinstanz zur gleichen Zeit Zugriff auf den kritischen Abschnitt des Codes haben soll: 1 /* mksem.c */ #include <stdio.h> #include <sys/types.h> 5 #include <sys/ipc.h> #include <sys/sem.h> int main(int argc, char *argv[]) 10 key_t semkey; semkey = atoi(argv[1]); /* Name wurde als Parameter übergeben */ return semget(semkey, 1, 0666 IPC_CREAT); Nachdem der Code compiliert und auf einem beliebigen Knoten ausgeführt wurde, ist der neue Semaphor einsatzbereit. Die Ausgabe des ipcs Befehls bestätigt dies: Semaphore Arrays key semid owner perms nsems 0x achim Nachdem der Semaphor erzeugt wurde, muss eine Möglichkeit gefunden werden, dessen Wert zu verändern. Folgendes C-Programm setzt den angegebenen Wert des jeweiligen Semaphors: 1 /* setsem.c */ #include <sys/types.h> #include <sys/ipc.h> 5 #include <sys/sem.h> union semun int val; /* value für SETVAL */ struct semid_ds *buf; /* buffer für IPC_STAT & IPC_SET */ 10 ushort *array; /* array für GETALL & SETALL */ ; int main(int argc, char *argv[]) 15 int semid, old_val, new_val; key_t semkey; 20

21 union semun arg; /* Semaphor holen */ 20 semkey = atoi(argv[1]); semid = semget(semkey, 1, 0); /* alten Wert auslesen */ old_val = semctl(semid, 0, GETVAL, arg); /* neuen Wert speichern */ arg.val = atoi(argv[2]); semctl(semid, 0, SETVAL, arg); new_val = semctl(semid, 0, GETVAL, arg); Damit lässt sich der Semaphor mit einem definierten Wert initialisieren. Als nächstes folgt das eigentliche Hauptprogramm. Es trägt der Übersichtlichkeit bei zwei Hilfsfunktionen zu definieren. Die p()-funktion wird vor betreten des kritischen Abschnitts aufgerufen, die v()- Funktion nach dessen verlassen. Die Funktionen Zählen den Wert des Semaphors jeweils um eins herauf, bzw. herunter: 1 /* semsynch.c */ void p(int semid) 5 struct sembuf p_buf; 10 p_buf.sem_num = 0; p_buf.sem_op = -1; p_buf.sem_flg = SEM_UNDO; if (semop(semid, &p_buf, 1) == -1) perror("p(semid) failed"), exit(1); return; 15 v(int semid) struct sembuf v_buf; 20 v_buf.sem_num = 0; v_buf.sem_op = 1; v_buf.sem_flg = SEM_UNDO; 25 if (semop(semid, &v_buf, 1) == -1) perror("v(semid) failed"), exit(1); return; Nun kann das Hauptprogramm implementiert werden. Es wird von der Konsole aus mit einem Buchstaben und dem Namen des zu verwendenden Semaphors aufgerufen: 1 int myrand() return 1 + (int) (10.0*rand()/(RAND_MAX + 1.0)); 5 int main(int argc, char *argv[]) 10 char buf[1]; int i,j,semid; buf[0] = argv[1][0]; semid = semget(atoi(argv[2]),1,(int)null); for (i=0; i<5; i++) 15 /* Prolog */ p(semid); /* kritischer Abschnitt */ 20 usleep( ); for (j=0; j<60; j++) write(1, &buf, 1); if ( myrand() < 2) usleep(100); 25 puts(""); 21

22 30 /* Epilog */ v(semid); return 0; Die Ausgabe wird mittels einer Zufallsfunktion bei manchen Durchläufen verlängert, um ein asynchrones Verhalten zu simulieren. Da der in p() ausgeführte Befehl den Wert des Semaphors zu erniedrigen blockiert wenn der Semaphor bereits den Wert 0 hat, wartet der entsprechende Prozess bis die andere Instanz den Semaphor wieder heraufzählt, also den kritischen Abschnitt verlässt. Bei der Ausgabe ihrer Zeichenketten kommen sich die einzelnen Prozesse dadurch nicht in die Quere - hier die Ausgabe des Programms: achim]$./mksem sem1 achim]$./setsem sem1 1 achim]$ onnode 1./semsynch A sem1 & achim]$ onnode 2./semsynch B sem1 & achim]$ onnode 3./semsynch C sem1 & AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 3.4. Sockets Ein wichtiges logisches Kommunikationsmodell ist das Socket-Modell, das eine punktorientierte Kommunikation mit Warteschlange realisiert. Es unterscheidet zwischen einem Server, der die Kommunikation für eine Dienstleistung anbietet und auf Kunden wartet, und den Clients, die eine zeitweilige Kommunikation zu ihm aufbauen. Im SSI-Umfeld sollte eine solche Kommunikation möglich sein, egal ob sich Server und Client auf dem selben Knoten befinden, oder über das Netzwerk getrennt sind. Außerdem sollte eine bestehende Socketverbindung zusammen mit einem Prozess auf einen anderen Knoten migriert werden können, ohne dass die Verbindung unterbrochen wird. Folgendes Beispiel verifiziert dies: Beispiel 5. Erzeugen und Testen einer Socketverbindung: Zunächst wird der Server besprochen. Er erzeugt einen streambasierten Socket in der Internetdömane - gemeint ist eine TCP/IP-Verbindung. Es besteht außerdem auch die Möglichkeit datagrammbasierte Sockets zu erzeugen, sowie die alternative Unixdomäne zu verwenden. Der Socket wird erzeugt, an einen Port gebunden und es wird darauf gewartet, dass Verbindungen von außen eintreffen: 22

23 1 /* server.c */ #define PORT void dead_child(int sig) int pid; pid = wait(null); /* kill zombie */ 10 int main() int orig_sock, new_sock, clnt_len; struct sockaddr_in clnt_adr, serv_adr; 15 struct sigaction sig1; clnt_len = sizeof(clnt_adr); /********************* set up signal handler *********************/ sig1.sa_flags = 0; 20 sigemptyset(&sig1.sa_mask); sig1.sa_handler = dead_child; if (sigaction(sigchld, &sig1, NULL)!= 0) perror("sigaction error"), exit(1); 25 /*************** generate Internet-Domain socket ***************/ if ((orig_sock = socket(af_inet, SOCK_STREAM, 0)) < 0) perror("generate error"), exit(1); /********************* bind socket to PORT *********************/ 30 serv_adr.sin_family = AF_INET; serv_adr.sin_addr.s_addr = htonl(inaddr_any); serv_adr.sin_port = htons(port); if (bind(orig_sock, (struct sockaddr *) &serv_adr, sizeof(serv_adr)) < 0) perror("bind error"), exit(2); 35 /********************* listen *********************/ if (listen(orig_sock, 5) < 0) perror("listen error"), exit(3); Nun werden endlos lang Verbindungen entgegengenommen - für jede dieser Verbindungen wird eine neue Prozessinstanz erzeugt, die dann den Klienten bedient. Für dieses Beispiel ist das Übertragen einer statischen Zeichenkette ausreichend... Der accept-befehl blockiert das Programm solange, bis eine Anfrage eintrifft: 1 while(1) /* loop forever */ /********************* accept *********************/ new_sock=accept(orig_sock,(struct sockaddr*)&clnt_adr,&clnt_len); 5 if (new_sock < 0) if (errno == EINTR) continue; else perror("accept error"); close(orig_sock); 10 exit(4); /* fork a new child */ 15 if (fork() == 0) /***************** write String to Socket *****************/ while(1) /* write to socket */ 20 write(new_sock, "Dieser Text wird ueber einen TCP/IP-Socket \ uebertragen...",57); sleep(1); 25 exit(0); /* Never executed */ 30 return 0; Der zugehörige Client ist einfacher zu implementieren. Er baut über das Loopbackinterface ( localhost ) eine Verbindung zu dem Port auf, an dem der Server wartet. Die Zeichenkette die über die Socketverbindung übertragen wird, wird nun einfach auf der Standardausgabe ausgegeben: 23

24 1 /* client.c */ #define PORT int main(void) int orig_sock; /* original socket descriptor in client */ struct sockaddr_in serv_adr; /* internet address of server */ struct hostent *host; /* the host (server) */ 10 if ((host = gethostbyname("localhost")) == (struct hostent *) NULL) perror("unknown Host"), exit(1); memset(&serv_adr, 0, sizeof(serv_adr)); /* clear structure */ 15 serv_adr.sin_family = AF_INET; /* set address type */ memcpy(&serv_adr.sin_addr, host->h_addr, host->h_length); /* Adr */ serv_adr.sin_port = htons(port); /* use our port */ if ((orig_sock = socket(af_inet, SOCK_STREAM, 0)) < 0) 20 perror("socket error"), exit(3); if (connect(orig_sock,(struct sockaddr*)&serv_adr,sizeof(serv_adr))<0) perror("connect error"), close(orig_sock), exit(4); 25 while(1) char buf[bufsiz]; /* buffer for messages */ read(orig_sock, buf, BUFSIZ); write(1,buf,strlen(buf)); 30 puts(""); return 0; Ein Test des Programms zeigt, das wenn beide Prozesse auf dem selben Knoten gestartet werden, eine Verbindung problemlos aufgebaut werden kann. Dies ist ja aber noch nichts besonderes: achim]$./server & [1] 6574 achim]$./client Dieser Text wird ueber einen TCP/IP-Socket uebertragen. Dieser Text wird ueber einen TCP/IP-Socket uebertragen. Dieser Text wird ueber einen TCP/IP-Socket uebertragen. Von einer anderen Konsole aus können nun die Prozesse auf andere Knoten migriert werden. Offene Socketverbindungen bleiben dabei erhalten: achim]$ ps -ef grep client achim :30 pts/0 00:00:00./client achim]$ migrate achim]$ ps -ef grep server achim :30 pts/0 00:00:00./server achim]$ migrate Dieser Text wird ueber einen TCP/IP-Socket uebertragen. Dieser Text wird ueber einen TCP/IP-Socket uebertragen. Dieser Text wird ueber einen TCP/IP-Socket uebertragen. Es wäre natürlich auch möglich gewesen, die Prozesse gleich auf unterschiedlichen Knoten auszuführen. Die Verbindung hätte dann allerdings nicht nach localhost aufgebaut werden dürfen, sondern es hätte der Knotenname bzw. die interne IP-Adresse des Knotens verwendet werden müssen. Wie dem gesamten Cluster eine gemeinsame IP-Adresse zugeordnet werden kann (dazu ist die Konfiguration des LVS-Subsystems erforderlich), wird weiter unten bei der Implementierung des Projekts näher ausgeführt. 24

25 3.5. Shared Memory Eine weitere Möglichkeit um eine Kommunikation zwischen zwei Prozessinstanzen zu realisieren, stellt das sog. Shared Memory dar. Dabei werden bestimmte Speicherbereiche von zwei oder mehr Prozessen gleichzeitig benutzt. In klassischen Szenarien wird einer der Prozesse etwas in den gemeinsamen Speicherbereich hineinschreiben, während der andere Prozess die Daten daraus ausliest. Dieses Verhalten, und insbesondere die transparente Überschreitung von Knotengrenzen, testet folgendes Beispiel: Beispiel 6. Erzeugen und Testen eines clusterweiten SHM-Segments: Zunächst werden in dem Hauptprogramm zwei Funktionen definiert, die nachher auf unterschiedlichen Knoten in jeweils eigenen Prozessen ausgeführt werden. Für dieses Beispiel ist es ausreichend, dass die Funktionen einfach einen Zähler hochzählen. Der gemeinsame Speicherbereich muss also nur einen Integer aufnehmen, und lässt sich daher mit int* referenzieren - die Adresse des Speicherbereichs wird den Funktionen als Parameter übergeben: 1 /* sharedmem.c */ void do_one_thing(int *pnum_times) 5 int i; for (i = 0; i < 5; i++) printf("doing one thing\n"); sleep(2); (*pnum_times)++; 10 void do_another_thing(int *pnum_times) 15 int i; for (i = 0; i < 5; i++) printf("doing another thing\n"); sleep(2); (*pnum_times)++; 20 Außerdem wird noch eine dritte Funktion definiert, die den Inhalt des gemeinsamen Zählers am Ende ausgibt: 1 void do_wrap_up(int *pnum_times) 2 3 printf("all done, a total of %d times!\n", *pnum_times); 4 Nun kann die Main-Funktion implementiert werden. Zunächst erzeugt sie ein Shared- Memory-Segment von der Größe 4 Byte (sizeof(int)). Anschließend werden auf zwei verschiedenen Knoten jeweils Prozesskopien erzeugt. Dazu kommt der spezielle SSI- Systemaufruf rfork() zum Einsatz. Als Parameter erwartet er die Nummer des Knotens, auf dem die Prozesskopie erzeugt werden soll. Alle speziellen Befehle der OpenSSI-API sind in der Datei /usr/include/sys/cluster.h deklariert, und ein Programm das diese verwenden möchte muss mit der libcluster.a gelinkt werden (z.b. gcc -o sharedmem sharedmem.c -lcluster). 25

26 1 int main(void) pid_t child1_pid, child2_pid; int status, shared_mem_id, *shared_mem_ptr; 5 /* create shared memory segment... */ if ((shared_mem_id = shmget(ipc_private, sizeof(int), 0660)) == -1) perror("shmget"), exit(1); 10 /*...attach it... */ if ((shared_mem_ptr = shmat(shared_mem_id, (void *)0, 0)) == -1) perror("shmat failed"), exit(1); /*...and initialize it */ 15 *shared_mem_ptr = 0; /* create first child */ if ((child1_pid = rfork(2)) == 0) do_one_thing(shared_mem_ptr); 20 return 0; else if (child1_pid == -1) perror("rfork"), exit(1); sleep(1); 25 /* create second child */ if ((child2_pid = rfork(3)) == 0) do_another_thing(shared_mem_ptr); return 0; else if (child2_pid == -1) perror("rfork"), exit(1); 30 /* wait for childs to exit */ if ((waitpid(child1_pid, &status, 0) == -1)) perror("waitpid"), exit(1); if ((waitpid(child2_pid, &status, 0) == -1)) 35 perror("waitpid"), exit(1); /* print value of counter */ do_wrap_up(shared_mem_ptr); 40 return 0; Nachdem das Programm wie oben beschrieben compiliert wurde, kann es ausgeführt werden. Die Prozesse greifen von unterschiedlichen Knoten aus auf einen gemeinsamen Speicherbereich zu, es liegt also ein Distributed Shared Memory -Verhalten vor. Hier die Ausgabe des Programms: doing one thing doing another thing doing one thing doing another thing doing one thing doing another thing doing one thing doing another thing doing one thing doing another thing All done, a total of 10 times! Das verwendete SHM-Segment steht übrigens auch nach Beendigung des Programms noch zur Verfügung (wie auch auf herkömmlichen Linuxsystemen), wie die Ausgabe des ipcs Befehls zeigt: Shared Memory Segments key shmid owner perms bytes nattch status 0x achim Im Gegensatz zu normalen Speicherbereichen ist die Lebensdauer von Shared Memory Segmenten also nicht an die Lebensdauer eines einzelnen Prozesses, und im OpenSSI-Umfeld nicht einmal an die Lebensdauer eines einzelnen Knotens gebunden. Dies ist ein enormer Vorteil für die Entwicklung hochverfügbarer Dienste. Das folgende Kapitel geht auf diesen und andere Punkte näher ein... 26

27 4. Hochverfügbarkeit Konzepte für hochverfügbare Dienste Für unternehmenskritische Prozesse ist eine ständige Verfügbarkeit bestimmter Dienste notwendig. Dabei hängt die Verfügbarkeit eines Dienstes natürlich von der Zuverlässigkeit der zugrunde liegenden Hardware ab. Diese Zuverlässigkeit ist jedoch begrenzt - aufgrund der hohen Komplexität moderner Computersysteme, enthalten diese eine Vielzahl von Fehlerquellen. Einzelne Mikroprozessoren auf dem Motherboard können ausfallen, das Netzteil kann durchbrennen und Peripheriegeräte können nach einer Zeit Fehler aufweisen. Um solche Hardwarefehler auszugleichen, können Dienste derart entworfen werden, dass sie Ihre Aufgaben auch bei Vorliegen eines Knotenfehlers fortsetzen können. Interne Fehler werden nach außen nicht sichtbar - daher spricht man auch von Fehlermaskierung. Die Fähigkeit eines Systems intern auftretende Fehler zu maskieren wird auch als Fehlertoleranz oder eben Hochverfügbarkeit bezeichnet. Der Einfachheit halber wird dabei in dieser Seminararbeit davon ausgegangen, dass ein auftretender Fehler stets den Knoten zum Absturz bringt. Die Kommunikationswege werden als sicher angesehen, was in der Realität natürlich oftmals nicht der Fall ist: wenn z.b. die Netzwerkkarte eines Knotens ausfällt, wird er in diesem Beispielszenario als Down eingestuft. Um dies zu vermeiden, könnte das Cluster-Interconnect seinerseits Redundant aufgebaut werden - jeder Knoten müsste über mehrere NICs verfügen, die über unabhängige Switches bzw. Hubs miteinander verbunden sind. Eine weitere Vereinfachung von der ausgegangen wird, betrifft die Auswirkung von Fehlern. In diesem Szenario wird nicht berücksichtigt, das sog. schleichende- oder byzantinische Fehler auftreten können, bei denen zwar die Gesamtfunktionalität des Clusters erhalten bleibt, einzelne Knoten aber verfälschte Werte erhalten (wenn z.b. ein Speicherchip in einem Knoten derart defekt ist, das von Zeit zu Zeit einzelne Bits umkippen ). Die Behandlung solcher Fehler ist extrem aufwendig, und stellt ein generelles Problem der Informatik dar, das nicht nur speziell bei Rechnerclustern auftreten kann Backupmodelle Um nach außen hin eine Hochverfügbarkeit zur Verfügung zu stellen, müssen die Daten von Diensten repliziert werden. Fällt ein Knoten des Clusters aus, gehen alle darauf gespeicherten Informationen verloren. Da in einem solchen Fall auch sämtliche Prozesse ausfallen, die auf dem Knoten liefen, ist es nötig deren Informationen anderen Prozessen auf anderen Knoten zur Verfügung zu stellen (Replikation, Backup). Es gibt verschiedene Modelle die beschreiben wie dieses Verhalten realisiert werden kann. Die wichtigsten werden im Folgenden kurz vorgestellt: 27

28 passives Backupmodell Das passive Backupmodell wird auch als Primär-Backup-Modell bezeichnet. In diesem Modell gibt es zu jeder Zeit nur eine einzige aktive Dienstinstanz, die alle Anfragen entgegennimmt und bearbeitet. Daneben existieren weitere Dienstinstanzen (Backups oder Slaves), die Kopien der aktualisierten Daten vom Master erhalten. Fällt der Master aus, übernimmt einer der Slaves seine Aufgabe. Durch die Daten, die er zuvor vom Master erhalten hatte, ist er in der Lage dessen Aufgaben zu übernehmen. Abbildung 4. Funktionsweise bei passivem Backup: Die passive Replikation hat den Nachteil, dass dadurch relativ große Overheads entstehen. Die Synchronisation der inaktiven Dienste mit dem Master bedingt mehrere Kommunikationsdurchgänge pro Anfrage. Wenn der aktive Dienst ausfällt, entsteht noch mehr Latenz während das Gruppenkommunikationssystem einen neuen Master ermittelt und aktiviert. Aufgrund der relativ langen Zeit, die verstreicht bis der Dienst nach einem Fehler wieder zur Verfügung steht, eignet sich dieses Modell nur für Szenarien in denen dieses Verhalten akzeptabel ist (Transaktionsbasierte Systeme, die eine Antwortzeit im Sekunden- bis Minutenbereich tolerieren können). Ein Beispiel für die konkrete Anwendung dieses Modells in Reinform stellt der Sun Network Information Service ([NIS] früher Yellow Pages) dar, sowie das replizierte Dateisystem Harp [Harp] aktives Backupmodell Im aktiven Backupmodell gibt es mehrere aktive Dienste gleichzeitig. Diese sind Zustandsmaschinen, die äquivalente Rollen spielen und in einer Gruppe angeordnet sind. Anfragen von außen landen zunächst bei einem zentralen Verteiler, der einen Multicast an alle aktiven Dienste durchführt. Jeder Dienst erhält die gleichen Eingabeparameter, und berechnet unabhängig von allen anderen eine Antwort. Diese erhält der zentrale Verteiler, der die erste erhaltene Antwort an den Client weiterleitet. Alle nachfolgend eintreffenden Antworten werden verworfen. 28

29 Abbildung 5. Funktionsweise bei aktivem Backup: Alle Dienstinstanzen erhalten die selben Anfragen, und reagieren unabhängig aber identisch darauf. Daher befinden sie sich stets im gleichen Zustand - eine explizite Synchronisation ist hier nicht nötig. Fällt eine Komponente des Systems aus, arbeiten alle anderen Dienste normal weiter. Da der Verteiler immer die zuerst eingetroffene Antwort an den Klienten weiterleitet, ist von außen nicht sichtbar von welcher Dienstinstanz die Antwort ursprünglich kam. Fällt ein Instanz aus, muss dies keine Auswirkung auf die Leistung des Dienstes haben, weil die anderen Instanzen weiterhin ganz normal antworten. Darin besteht der hauptsächliche Vorteil dieses Modells gegenüber der passiven Replikation. Es wird daher hauptsächlich in der Prozessdatenverarbeitung und bei Echtzeitsystemen eingesetzt, wo auch im Fehlerfall eine Antwortzeit im Millisekundenbereich erforderlich ist. Eine Variante des Modells sieht vor, das die Dienste ihre ermittelten Antworten direkt an den Klienten schicken. Der Verteiler wird dadurch entlastet, allerdings gerät das System in eine at-least-once Semantik: der Client erhält in der Regel mehrere Antworten auf seine Anfrage, nämlich von jedem aktiven Dienst eine. Dieses Verhalten ist nicht immer akzeptabel ( exactly-once Semantik des klassischen Modells). Ein weiterer Nachteil besteht in der Verwaltung externer Devices. Auch diese Devices erhalten eine Anfrage in der Regel mehrmals (von jedem aktiven Dienst). Handelt es sich dabei um kritische Ressourcen, für die dieses Verhalten nicht akzeptabel ist, kann das aktive Backupmodell nicht ohne weiteres verwendet werden. Ein Beispiel hierfür sind exklusive Locks im Dateisystem oder einer Datenbank, die ein spezielles Verhalten der Clients verlangen. In diesem Fall muss eine weitere Komponente zwischengeschaltet werden, die wiederholt eintreffende Antworten verwirft, oder diese evtl. vergleicht um byzantinische Fehler auszugleichen (hier nicht weiter behandelt) Variante des passiven Backupmodells Sowohl das passive, als auch das aktive Modell haben ihre Nachteile (siehe oben). Die OpenSSI- Clusterinfrastruktur bietet jedoch einen entscheidenden Vorteil, der ein weiteres Modell möglich macht. Vom Cluster wird eine sichere Storage-Komponente zur Verfügung gestellt, die nicht an die Lebensdauer von Knoten gebunden ist. Wie genau dieser Speicher realisiert werden kann wird im nächsten Kapitel näher untersucht. Hier zunächst das Replikationsmodell, das dadurch ermöglicht wird: 29

30 Abbildung 6. Funktionsweise bei passivem Backup mit sicherem Speicher: Wie im passiven Backupmodell gibt es zu jedem Zeitpunkt nur eine aktive Dienstinstanz, die alle Anfragen bearbeitet. Diese sichert ihren Zustand in regelmäßigen Abständen in dem sicheren Speichermedium (sog. Checkpoints ). Fällt die aktive Dienstinstanz aus, übernimmt eine andere, bis dahin inaktive Instanz deren Aufgaben. Anders als beim klassischen passiven Replikationsmodell erhält der inaktive Dienst die Daten jedoch nicht direkt vom Master, sondern liest sie aus dem Speichermedium aus. Es findet also keine direkte Kommunikation zwischen den einzelnen Dienstinstanzen statt. Das Design der Dienste wird dadurch erheblich vereinfacht! Die einzelnen Dienstinstanzen müssen gar nicht über die Existenz der anderen informiert werden. Mehr noch: da ein inaktiver Dienst an keinerlei Kommunikation teilnimmt, und erst bei seiner Aktivierung auf das Speichermedium zugreift, ist es möglich ihn erst dann zu starten. Das System muss nur sicherstellen, dass bei Ausfall der (einzigen) Dienstinstanz eine neue erzeugt wird. Diese kann dann ihren Zustand aus dem Speichermedium auslesen und wiederherstellen sicherer Speicher Im vorigen Abschnitt wurden verschiede Replikationsmodelle erläutert. Das letztgenannte Modell kann durch die Verwendung eines sicheren Speichers erheblich gegenüber dem klassischen, passiven Backupmodell verbessert werden. Die Existenz eines Speichermediums, welches nicht an die Lebenszeit einzelner Knoten gebunden ist, erleichtert die Entwicklung von hochverfügbaren Applikationen ungemein. Im Folgenden wird näher betrachtet welche konkreten Techniken für ein solches Speichermedium im OpenSSI-Umfeld in Frage kommen: Globales Root-Dateisystem Der wohl offensichtlichste Ansatz besteht darin, Daten im Dateisystem abzulegen. Das GFS basierte Root-Dateisystem ist in OpenSSI-Clustern von allen Knoten aus sichtbar. Daten die auf dem Knoten A in das Dateisystem geschrieben werden, sind auch vom Knoten B aus erreichbar. Konkret können normale Files zum Einsatz kommen, wie auch z.b. Named Pipes (siehe oben). Ein Nachteil dieses Ansatzes stellt die Tatsache dar, dass es sich bei Files um sog. Streams handelt. Da auf Streams nur eindimensional zugegriffen werden kann, müssen die Daten serialisiert werden, um sie darin abzulegen. Dies kann gerade bei komplexeren Datenstrukturen ein sehr aufwendiger Prozess sein. Ein Wort zur Hochverfügbarkeit des Dateisystems in OpenSSI-Clustern: In der zur Verfügung stehenden Beispielkonfiguration (3 Standardrechner mit IDE-Festplatten), befindet sich das Root- 30

31 Dateisystem physikalisch nur auf der Festplatte des ersten Knotens (Init-Knoten). Es stellt dadurch einen sog. Single Point of Failure dar: fällt der Init-Knoten aus (und mit ihm die Festplatte mit dem Root-Dateisystem), fällt das gesamte Cluster aus - auch die anderen Knoten haben keine Verbindung mehr zum Dateisystem. Da dieses Verhalten für kritische Anwendungen natürlich nicht akzeptabel ist, unterstützt die OpenSSI-Software auch folgende Konfiguration: Das Root-Dateisystem befindet sich auf einem externen, seinerseits redundant aufgebauten Speichermedium, wie z.b. externen RAID-Devices. Es sind mehrere Knoten direkt (über SCSI) mit dem Speichermedium verbunden, von denen jedoch nur einer aktiv ist, und das Dateisystem für das gesamte Cluster zur Verfügung stellt. Fällt dieser Init-Knoten aus, übernimmt ein anderer. direkt mit dem Speichermedium verbundener Knoten seine Aufgaben. Das Dateisystem bleibt weiterhin für das restliche Cluster sichtbar. Dieser Prozess nennt sich Root-Failover. Bei OpenSSI-Clustern kann der Init-Prozess ( Mutter aller Prozesse : PID 1) nur auf Knoten laufen, die direkt mit dem Root-Dateisystem verbunden sind. Andernfalls würde die Performance zu sehr leiden. Aus diesem Grund bezeichnet man solche Knoten als Potenzielle Init-Knoten. Neben diesen GFS basierten Lösungen besteht auch noch die Möglichkeit, die Storage-Komponente selbst als ein eigenes Cluster aufzubauen. Das Lustre Projekt bietet diese Option. Obwohl diese Alternative in der Realität wohl die höchste Anwendungsrelevanz besitzt (höchst verfügbar und sehr detailliert konfigurierbar), wird auf dieses Szenario im Rahmen dieses Projekts nicht weiter eingegangen, da keine entsprechende Hardwarestruktur zur Verfügung steht Distributed Shared Memory Das Schreiben in das Dateisystem hat den Nachteil, dass sämtliche abzulegende Daten serialisiert werden müssen. Für komplexe Datenstrukturen (structs, unions, etc.) ist diese Methode also sehr aufwendig. OpenSSI-Cluster stellen allerdings noch eine weitere Möglichkeit zur Verfügung, Daten global sichtbar zu hinterlegen. Wie in den Beispielen zur Interprozesskommunikation gezeigt wurde, sind Shared-Memory Segmente global im ganzen Cluster sichtbar. Die Speicherbereiche werden auf alle Knoten gespiegelt. Es handelt sich also um eine Distributed Shared-Memory Infrastruktur. Shared-Memory Segmente lassen sich beschreiben wie normale, lokale Speichersegmente. Es können also auch komplexere Datenstrukturen wie z.b. structs direkt abgelegt und ausgelesen werden, ohne sie in eine spezielle Darstellungsform transformieren zu müssen (Serialisierung ist nicht nötig). Da die Namensgebung für neue SHM-Segmente (Vergabe von Nummern, sog. SHM-IDs) vom Betriebssystem übernommen wird, und Nutzerprogramme keinen Einfluss darauf nehmen können, ist eine Zuordnung von SHM-IDs zu Programmen notwendig. Diese Zuordnung kann mit Hilfe des (ebenfalls global sichtbaren) Dateisystems geschehen: Damit Instanzen eines Programms entscheiden können, ob sie ein neues SHM-Segment anfordern sollen, oder ein bereits vorhandenes Segment weiter verwenden sollen, muss dem Programm ein Datum im Dateisystem eindeutig zugeordnet sein. Dieses Datum (konkret: ein reguläres File) enthält die SHM-ID des Speichersegments, sollte ein solches bereits existieren. Ist das File nicht vorhanden, fordert das Nutzerprogramm ein neues SHM-Segment an, und schreibt die Referenz darauf (die SHM-ID) in das ihm zugeordnete File. Sollte das Nutzerprogramm nun ausfallen und neu gestartet werden, kann es anhand der im File gespeicherten SHM-ID den vorhandenen Speicherbereich weiter verwenden - 31

32 mitsamt den darin enthaltenen Daten! Somit ist es möglich, Daten (fast) beliebiger Komplexität so zu hinterlegen, dass sie von einer Programminstanz auf einem anderen Knoten wieder ausgelesen werden können - solange noch zumindest ein Knoten im Cluster aktiv ist. Als nächstes ist nun die Frage zu klären, welche Daten überhaupt abgelegt werden müssen, und zu welchem Zeitpunkt. Vorher muss jedoch noch geklärt werden, wie in einem Fehlerfall überhaupt eine neue Prozessinstanz gestartet werden kann, die die entsprechenden Informationen wieder auslesen kann hochverfügbare Datenbank Für große Datenmengen sind beide oben dargestellten Alternativen natürlich ungeeignet. In der Realität werden größere Datenmengen, die unternehmenskritische Informationen enthalten, in einer geeigneten Persistenzschicht (Datenbankschicht) abgelegt. Diese Datenbankschicht stellt dann selbst ein hochverfügbares Cluster-Subsystem dar, welches mit Hilfe von Logs auch nach einem Systemausfall wieder hergestellt werden kann. Cluster-Datenbanksysteme werfen aber komplexe Fragestellungen z.b. aus dem Bereich verteilter Transaktionen auf. Auf deren Betrachtung wird jedoch im Weiteren verzichtet, da dies den Rahmen der Seminararbeit sprengen würde! 4.3. automatischer Prozessneustart Ein Ausfall eines Knotens bewirkt immer den Ausfall aller darauf laufenden Prozesse. Das Betriebssystem erhält eine Nachricht mit den PIDs der ausgefallenen Prozesse, sobald dieser Ausfall festgestellt wird. Die Dauer bis ein entsprechender Ausfall bemerkt wird, ist von den Parametern des Heartbeat-Mechanismus abhängig - einzustellen in /proc/cluster/... Um den ausgefallenen Dienst weiterhin zur Verfügung zu stellen, ist es notwendig einen neuen Prozess des betroffenen Programms zu starten. Wie im vorigen Abschnitt besprochen muss dieser Prozess dann die für den Dienst relevanten Informationen des vorherigen Programmlaufs wieder auslesen. Es gibt mehrere Mechanismen die registrierte Prozesse überwachen, und im Fehlerfall eine neue Instanz davon starten. Zwei dieser Möglichkeiten werden im Folgenden näher betrachtet, und es wird aufgezeigt welche Möglichkeit in dieser Beispielanwendung Verwendung findet, und weshalb: Keepalive/Spawndaemon Für genau diese Problemstellung bieten OpenSSI-Cluster eine sehr mächtige Lösung an: Den Keepalive/Spawndaemon-Mechanismus. Er überwacht Prozesse, und startet sie im Fehlerfall neu. Dabei lässt sich sehr genau definieren wo und wie ein solcher Neustart durchgeführt werden soll. Dazu lassen sich Skripte angeben, die bei entsprechenden Ereignissen ausgeführt werden. Die Konfiguration des Keepalive/Spawndaemon-Mechanismus erfolgt dabei über spezielle Konfigurationsdateien im Verzeichnis /etc/spawndaemon.d/. In diesen Konfigurationsdateien wird ein sog. Startup-Skript angegeben, welches bei Start des Dienstes ausgeführt wird. Die Startup- Skripte befinden sich in /etc/keepalive.d/: etc]# cat /etc/spawndaemon.d/ka_konzept :/achim/konzept/konzept:::500:0::::konzept.startup::::: etc]# cat /etc/keepalive.d/konzept.startup #!/bin/bash echo "Starting..." /achim/konzept/konzept & echo "OK!" 32

33 Mit Hilfe des Commandlineinterfaces spawndaemon kann der entsprechende Dienst dann registriert, und der Status beobachtet werden: etc]# spawndaemon -r ka_konzept spawndaemon: User Id is obtained from the executable spawndaemon: Group Id is obtained from the executable etc]# spawndaemon -L Keepalive daemon status slot state pid errs total max last_exec_time node node_set 0 ok Thu Feb 3 13:45: Für eine genauere Erklärung der Funktionsweise, sowie der zur Verfügung stehenden Optionen sei an dieser Stelle auf die sehr guten Manpages zu spawndaemon bzw. keepalive verwiesen. Folgend wird noch ein weiterer Prozessneustart-Mechanismus betrachtet, den auch der Spawndaemon selbst nutzt um bei Ausfall eines Knotens erneut gestartet zu werden. Programme können direkt beim Init- Prozess registriert werden, der daraufhin deren Überwachung übernimmt Init-Prozess Eine andere Möglichkeit Prozesse zu überwachen bietet der Init-Prozess. Auch der Standard-Kernel in normalen Linux-Distributionen stellt mit dem Init-Prozess ein Interface zur Verfügung, bei dem zu überwachende Anwendungen registriert werden können. Die entsprechende Konfigurationsdatei ist /etc/inittab. Die meisten klassischen Anwendungen benötigen ein solches Verhalten jedoch nicht. Auf klassischen PC-Systemen fällt ein Prozess nur dann aus, wenn dies entweder gewollt ist (reguläres Programmende), ein Softwarefehler vorliegt (dann macht aber auch ein Neustart keinen Sinn), oder ein Hardwarefehler vorliegt (dann kann der Prozess allerdings auch nicht neu gestartet werden - im Normalfall führt ein solcher Fehler zum Ausfall des gesamten Systems). Die inittab wird daher meist nur für das automatische Ausführen von Diensten während des Systemstarts verwendet. Die Option RESPAWN ist außerhalb von Cluster-Umgebungen eher unbekannt. Für das gewöhnliche Starten von Diensten während des Bootvorgangs bietet das Verzeichnis /etc/rc.d/ übrigens wesentlich detailliertere Konfigurationsmöglichkeiten als ein Eintrag in /etc/inittab. Ein entsprechender Eintrag für unseren Beispieldienst sieht folgendermaßen aus: <name>:<runlevel>:respawn:<programmname> also zum Beispiel achim:2345:respawn:/achim/konzept Der erste Eintrag ist ein frei wählbarer Bezeichner mit dem der Eintrag referenziert werden kann, dann folgt eine Liste der Runlevel, in denen der entsprechende Dienst gestartet werden soll (wenn er nicht bereits läuft), und nach dem Schlüsselwort respawn folgt der Programmaufruf inklusive eventueller Parameter. In der Datei /etc/inittab findet sich übrigens auch ein Eintrag für den Spawndaemon! Dabei sind die hier zur Verfügung stehenden Konfigurationsmöglichkeiten im Vergleich zu denen von Keepalive natürlich sehr beschränkt. Es können weder spezielle Skripte für unterschiedliche Ereignisse angegeben werden, noch kann Einfluss darauf genommen werden auf welchem Knoten die neue Programminstanz gestartet wird. Insbesondere hat ein hier eingetragener Dienst keine Möglichkeit dafür zu sorgen nicht mehr gestartet zu werden. Dafür ist die Entfernung des entsprechenden Eintrages aus der inittab nötig! 33

34 Nachdem Änderungen an der besprochenen Konfigurationsdatei vorgenommen wurden, muss der Init-Prozess entweder neu gestartet werden (was einen Reboot des Systems bedeutet), oder er muss mit folgendem Befehl von der neuen Konfiguration in Kenntnis gesetzt werden telinit Q. Anschließend werden die entsprechenden Programme gestartet, wobei sowohl Standardausgabe, als auch Standardfehlerausgabe in die Mailbox des root-users umgeleitet werden (ähnlich wie dies von cronjobs bereits bekannt ist). Abschließend muss nun noch untersucht werden, welche Daten überhaupt gesichert bzw. wieder aufgenommen werden, und zu welchem Zeitpunkt Wiederaufsetzpunkte (Checkpoints) In den vorigen Abschnitten wurde erläutert, wie ein Programm Daten in einem sicheren Medium ablegen kann, und wie dafür gesorgt werden kann, dass bei Ausfall eines Prozesses eine neue Instanz davon gestartet wird. Die letzte Frage die noch zu klären ist, ist die Frage wann welche Daten abgelegt werden müssen. Dies ist äquivalent zur Fragestellung wo sog. Checkpoints eingefügt werden sollten, und welchen Inhalt diese haben sollten. Ein Fehler kann prinzipiell zu jedem beliebigen Zeitpunkt, asynchron zum Programmfluss auftreten - es lässt sich nicht voraussagen, und nur in sehr begrenztem Maße abschätzen wann dies der Fall ist (Festplattenfehler sind während der Abarbeitung aufwendiger IO-Vorgänge wahrscheinlicher, als zu Zeitpunkten in denen gar kein Zugriff auf die Platte stattfindet). In einem Fehlerfall muss sichergestellt werden, dass gerade in der Abarbeitung befindliche Aufträge von Klienten nicht verloren gehen! Ein bereits teilweise bearbeiteter Auftrag muss entweder weiterbearbeitet werden (was je nach Art des Dienstes ein sehr schwieriges Vorhaben darstellt), oder wieder als unbearbeitet markiert, und die Bearbeitung von neuem begonnen werden. Welche der beiden Alternativen zur Anwendung kommen kann ist hochgradig von der Art des Dienstes abhängig. Im Folgenden werden beide Ansätze näher untersucht: Neustart von Aufträgen Die einfachere Alternative ist es, in der Abarbeitung befindliche Aufträge nach einem Knotenfehler wieder ganz von vorne zu bearbeiten. Ein Checkpoint wird dadurch immer nur dann erreicht, wenn die Abarbeitung eines Auftrags vollständig ist. Es muss nur die Information gespeichert werden, welche Aufträge noch nicht (bzw. noch nicht vollständig) bearbeitet wurden. Dieses Verhalten kann über eine einfache Warteschlange realisiert werden. Eintreffende Aufträge werden in diese Warteschlange eingereiht (erster Checkpoint), und bleiben dort während der gesamten Dauer der Abarbeitung unverändert. Tritt ein Knotenfehler auf, und die Warteschlange wird wieder hergestellt, erscheinen bereits teilweise bearbeitete Aufträge in gleicher Weise wie noch gar nicht angefangene - die Abarbeitung beginnt von vorne. Erst wenn ein Auftrag vollständig abgearbeitet wurde, wird er aus der Warteschlange entfernt (zweiter Checkpoint) Fortsetzen von Aufträgen Die aufwendigere Alternative ist es, die Abarbeitung von Aufträgen nach einem Knotenfehler fortzusetzen. Neben der bloßen Existenz eines Auftrages in der Warteschlange, müssen dazu auch noch Informationen über den Bearbeitungsverlauf eines einzelnen Auftrages gespeichert werden. Ein Checkpoint wird nicht nur am Ende eines Auftrages erreicht, sondern es können während der 34

35 Abarbeitung noch beleibig viele Checkpoints erreicht werden. An welchen Stellen solche Checkpoints zu platzieren sind, und welche Informationen darin gesichert werden müssen, hängt natürlich von der entsprechenden Anwendung ab. Generell kann gesagt werden, dass sämtliche Informationen gespeichert werden müssen, die den Abarbeitungsstatus eindeutig beschreiben - also alle Informationen die nötig sind um den Systemzustand nach einem Ausfall wieder zu rekonstruieren. Daher empfiehlt es sich, solche Checkpoints an den Stellen zu platzieren, an denen möglichst wenige Informationen nötig sind, um eine Rekonstruktion zu ermöglichen. Zu sichernde Informationen sind typischerweise: Zwischenergebnisse von Berechnungen, Positionen von Filepointern, etc Designentscheidungen Die Wahl des Replikationsmodells fiel auf die Variante des passiven Backups mit sicherem Speicher. Die Verfügbarkeit von sicheren Speichermedien, die nicht an die Lebenszeit einzelner Knoten gebunden sind, stellt einen enormen Vorteil dar, und erleichtert die Anwendungsentwicklung wesentlich. Gegenüber dem klassischen passiven Backupmodell ist die Variante deutlich einfacher zu implementieren, und daher weniger Fehleranfällig. Der Nachteil der relativ hohen Latenz bei einem Knotenausfall haftet allerdings auch ihr an. Dies kann jedoch toleriert werden, da eine Antwortzeit des Systems im Sekundenbereich für Demonstrationszwecke ausreichend ist. Für Echtzeitanwendungen wäre dies jedoch nicht akzeptabel, und es müsste das aktive Backupmodell implementiert werden. Als sicheres Speichermedium kommt Distributed Shared-Memory zum Einsatz. Gegenüber dem reinen Dateisystem bietet es den Vorteil dass auch komplexere Datenstrukturen relativ einfach abgelegt werden können. Es muss keine Serialisierung durchgeführt werden, was einen wesentlichen Vorteil darstellt. Aus Zeitgründen wurden hochverfügbare Datenbanksysteme nicht weiter betrachtet, obwohl diese Alternative in der Realität wohl die größte Relevanz besitzt. Um den Prozessneustart zu realisieren ist der Keepalive/Spawndaemon-Mechanismus prädestiniert. In der Praxis zeigt er allerdings Schwächen: So kam es bei Tests immer wieder vor, dass ein beendeter Prozess nicht sofort neu gestartet wurde. Erst als ein zweiter registrierter Prozess starb, startete der Spawndaemon beide Prozesse erneut. Da dieses Verhalten aber nur manchmal auftrat, wird ein Konfigurationsfehler ausgeschlossen. In verschiedenen OpenSSI-Foren, wie auch in der Projektdokumentation selbst, findet sich allerdings der Hinweis dass der Keepalive/ Spawndaemon-Code erst vor kurzem in den OpenSSI-Code integriert (portiert) wurde. Bei der verwendeten OpenSSI-Version handelt es sich um einen sog. Development-Release, der noch nicht für den Produktiveinsatz vorgesehen ist. Die als Stable klassifizierte Version enthält den Keepalive Mechanismus gar nicht! Für die Zukunft ist also noch eine Verbesserung des Funktionsumfangs dieser Komponente zu erwarten. Auf Grund der (noch) niedrigen Zuverlässigkeit dieser Alternative, fiel die Wahl daher auf den Init- Prozess. Gegenüber dem Keepalive-Mechanismus ist er zwar wesentlich weniger detailliert zu konfigurieren, zeigt bei Tests aber eine sehr hohe Zuverlässigkeit. Da die von OpenSSI zur Verfügung gestellte API nur für C implementiert ist, fällt die Wahl der Programmiersprache entsprechend eindeutig aus. 35

36 5. Beispielszenario Im Laufe der Analyse und der Betrachtung verschiedener Architekturmodelle ergaben sich einige Anforderungen an den zu implementierenden Dienst. So sollte er zunächst eine lange Laufzeit aufweisen, damit genügend Zeit zur Verfügung steht eine Fehlersituation herbeizuführen, und deren Bearbeitung zu beobachten. Die Anfrage eines Clients sollte also möglichst mehrere Minuten Abarbeitungszeit hervorrufen. Dies bedingt die Sicherung des inneren Zustands des Prozesses (Fortsetzen von Aufträgen, siehe oben). Des weiteren sollten Informationen aus dem Filesystem ausgelesen, bzw. geschrieben werden. Daran kann untersucht werden, wie offene Files nach einem Knotenausfall wieder aufgenommen werden können. Gleiches Verhalten soll für offene Socketverbindungen untersucht werden. Der Dienst soll also über einen TCP/IP-Socket mit der Außenwelt kommunizieren. Angesichts dieser Anforderungen fiel die Wahl auf die Implementierung eines Medien-Servers. Er sollte beispielhaft demonstrieren wie Anfragen eines Clients entgegengenommen werden, und als Antwort ein Medien-Stream gesendet wird. Zu diesem Zweck wird einfach z.b. ein MP3-File aus dem Dateisystem geöffnet, und in kleinen Stücken über die vom Klienten aufgebaute Socketverbindung übertragen. Da der Client die Musikdatei abspielt, und auch nur in dieser Geschwindigkeit Daten aus dem Socket liest, dauert die Abarbeitung eines Auftrages mehrere Minuten (Dauer des Audio-Stücks). Auch das Failoververhalten lässt sich daran sehr intuitiv beobachten - bei Ausfall eines Knotens sollte die Wiedergabe an der Stelle fortgesetzt werden, an der sie unterbrochen wurde. Der Dienst verwaltet sowohl geöffnete Files, als auch Socketverbindungen Implementierung Der zu implementierende MP3-Server soll folgende Eigenschaften besitzen: Er soll auf einem definierten Port auf Verbindungen von außen warten (horchen, listen ). Ein Client (MP3-Player, unter Linux z.b. XMMS ) baut eine Verbindung zu diesem Port auf. Daraufhin sendet der Server einen Audio-Stream über die aufgebaute Socketverbindung. Da auch mehrere Clients bedient werden können sollen, muss der Server für jede Anfrage eine eigene Prozessinstanz erzeugen, die die entsprechende Anfrage bearbeitet. Die ursprüngliche Prozessinstanz kann dadurch weitere Anfragen entgegennehmen, während der Kindprozess laufende Anfragen bearbeitet. Auf diese Weise kann auf die Implementierung einer Warteschlange im klassischen Sinne verzichtet werden. Da der Client durch eine bereits existierende Anwendung repräsentiert wird, ist es nötig das Stream- Protokoll auf diesen Client anzupassen. Der XMMS-Audioplayer erwartet Streams im HTTP- Format: im Wesentlichen muss zunächst ein sog. HTTP-Header übertragen werden, gefolgt von den eigentlichen Audiodaten im MP3-Format. Der HTTP-Header sieht folgendermaßen aus: HTTP/ OK Content-Type:audio/mpeg Die danach folgenden binären Audiodaten sollen einfach aus einer Datei im MP3-Format ausgelesen werden, und dann in kleinen Stücken zu je 8KB (Standardpuffergröße auf Linux-Systemen) übertragen werden. Da der Client die Daten nur in der Geschwindigkeit ausliest, in der er sie auch wiedergibt, blockiert der Schreibbefehl in den Socket, falls dieser bereits seinen maximalen Füllstand erreicht hat. 36

37 Tritt nun ein Knotenfehler auf, fallen alle laufenden Prozesse aus. Die geöffneten Dateien werden geschlossen, und die Socketverbindung wird unterbrochen. Über den init-prozess (siehe oben) kann sichergestellt werden, dass unmittelbar danach eine neue Prozessinstanz erzeugt wird. Der Server horcht wieder auf Verbindungsanfragen von außen. Wenn der Client nun eine neue Verbindung aufbaut, soll die Wiedergabe des MP3-Files nicht wieder von vorne beginnen, sondern an der Stelle fortgesetzt werden, an der sie unterbrochen wurde (Fortsetzen von Aufträgen, siehe oben). Daher ist es notwendig, das während der Wiedergabe in regelmäßigen Abständen die Position innerhalb des MP3-Files in das sichere Medium (SHM-Segment) gespeichert wird. Anhand dieser Information kann zu Beginn der erneuten Wiedergabe der Filepointer wieder an die Position bewegt werden, an der er sich unmittelbar vor Ausfall des Knotens befand. Abbildung 7. Funktionsweise des MP3-Servers: Die Wiedergabe des Audiostücks kann durch diesen Mechanismus auch über einen Knotenfehler hinweg durchgeführt werden. Allerdings muss der Client eine neue Verbindungsanfrage an den Server stellen (dazu später mehr). Hier zunächst der implementierte Code: 37

38 Hilfsfunktionen Zunächst wurden einige Hilfsfunktionen in einer kleinen Library programmiert. Diese Hilfsfunktionen kapseln die benötigten Betriebssystemaufrufe, mit dem Ziel das eigentliche Hauptprogramm sauber und schlank zu halten: 1 /* lib.c */ int new_shm(void) 5 int shm_id; 10 /* Create a new _SharedMem-segment */ if ((shm_id = shmget(ipc_private, sizeof(status), 0660)) == -1) perror("error creating shm-segment"), exit(1); return shm_id; 15 void att_shm(int shm_id) /* Attach the _SharedMem-segment to the process */ if ((_SharedMemPtr = (Status *)shmat(shm_id, NULL, 0)) == (void *)-1) perror("error attaching shm-segment"), exit(1); 20 void det_shm(void) 25 /* Detach _SharedMem-segment */ if (shmdt(_sharedmemptr) == -1) perror("error detaching shm-segment"), exit(1); Diese Funktionen verwalten die Behandlung der Shared-Memory-Segmente. new_shm() erzeugt ein neues SHM-Segment (von der Größe der zu definierenden Struktur Status), att_shm() hängt dieses an den Prozess (zu erreichen über eine globale Variable _SharedMemPtr) und det_shm() löst die Bindung an den Prozess. Da der Server Kindprozesse forken wird, muss ein Signal-Handler aufgesetzt werden, der das SIGCHLD-Signal abarbeitet: Bei Beendigung eines Kindprozesses erhält der Vaterprozess ein solches Signal, und solange er nicht mit einem wait() darauf reagiert, existieren die Kindprozesse weiterhin im Zombiestatus im Systemspeicher. Ein entsprechender Handler sieht folgendermaßen aus: 1 void dead_child(int sig) /* Kill the zombie process */ 5 wait(null); Die letzte Hilfsfunktion, die implementiert werden muss, behandelt das migrieren des Prozesses auf einen anderen Knoten. Bei erreichen eines Checkpoints (also in regelmäßigen Abständen) muss, um ein Load-Leveling Verhalten zu realisieren, eine Prozessmigration auf den am besten bewerteten Knoten geschehen. Dies geschieht durch einen Aufruf der OpenSSI-API: 1 void chnode(void) /* Migrate the process to another node (do load-leveling) */ 5 migrate(clusternode_best); Durch die Implementierung dieser Funktion (und deren Aufruf in regelmäßigen Abständen) kann der Prozess selbst dafür sorgen, dass er immer auf dem Knoten mit der niedrigsten Last läuft. Er ist nicht darauf angewiesen, von außen beim Load-Leveling Subsystem registriert zu werden. 38

39 Wichtig Headerdatei Der Aufruf der migrate()-funktion hat allerdings noch einen weiteren, sehr wichtigen Effekt. Er erzwingt die Synchronisation aller Kernel-Objekte im gesamten Cluster. Selbst wenn gar keine tatsächliche Migration stattfindet (wenn der Prozess etwa bereits auf dem besten Knoten läuft), führt der Aufruf von migrate() dazu, das u.a. die Shared- Memory-Segmente der Knoten synchronisiert werden. Ohne eine solche explizite Aufforderung (in regelmäßigen Abständen), ist es dem Kernel überlassen wann er eine solche Synchronisation durchführt. Es kann dadurch zu einem Informationsverlust im Falle eines Knotenfehlers kommen, da die anderen Knoten noch eine ältere Kopie der SHM- Segmente besitzen. Die Hilfsfunktionen sind damit vollständig. Bevor das eigentliche Hauptprogramm implementiert wird, muss zunächst noch eine Headerdatei erstellt werden, die sowohl in der Library, als auch im Hauptprogramm inkludiert wird. Hier werden einige Headerdateien des Betriebssystems inkludiert, sowie globale Variablen und eigene Datentypen definiert. Außerdem werden sämtliche eigene Funktionen deklariert, und der zu verwendende Port definiert: 1 /* local.h */ #include <errno.h> #include <stdio.h> 5 #include <string.h> #include <signal.h> #include <ctype.h> #include <stdlib.h> #include <unistd.h> 10 #include <sys/types.h> #include <sys/socket.h> #include <sys/wait.h> #include <netdb.h> #include <netinet/in.h> 15 #include <arpa/inet.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/cluster.h> 20 #include <sys/ipc.h> #include <sys/shm.h> #define PORT /* * This structure represents the inner state of the Service. * All information that should be available after a failover, * must be stored here... */ 30 typedef struct S int fileposition; Status; 35 /* * Some global variables... */ Status* _SharedMemPtr; /* Points to the SharedMem-Segment */ char _FirstRun; /* Is this the first run, 40 or do we takeover after a previous run? */ /* * Some helper functions... */ 45 int new_shm(void); /* Create a new SharedMem-Segment */ void att_shm(int); /* Attach a SharedMem-Segment to the process */ void det_shm(void); /* Detach a SharedMem-Segment from the process */ void dowork(void); /* Do some work... */ void chnode(void); /* Migrate the process to another node */ 50 void playsong(int); /* Plays the Song... */ void dead_child(int);/* Kill zombies... */ 39

40 Hauptprogramm Nun kann das eigentliche Hauptprogramm, und damit die Anwendungslogik implementiert werden. Zunächst die main()-funktion: 1 /* server.c */ int main(int argc, char *argv[]) 5 int fd; /* For the shmid-file */ /* Some buffers... */ char buf[20]; char filename_shm[100]; 10 /* Set up Signal-Handler... */ struct sigaction sig1; sig1.sa_flags = 0; sigemptyset(&sig1.sa_mask); 15 sig1.sa_handler = dead_child; if(sigaction(sigchld, &sig1, NULL)!= 0) perror("sigaction error"), exit(1); /* Initialize buffers */ 20 memset(buf,0,sizeof(buf)); memset(filename_shm,0,sizeof(filename_shm)); /* Compute the filenames (static, but we could also use getpid() f.e.) */ sprintf(filename_shm,"/home/achim/work/mp3stream/streamserver.shm"); Zunächst wird der oben erwähnte Signal-Handler für das SIGCHLD aufgesetzt. Außerdem wird der Name für eine Datei erzeugt, die später die ID des SHM-Segments enthalten wird. Anhand der Existenz dieser Datei kann nun entschieden werden, ob noch kein SHM-Segment zur Verfügung steht (erster Durchlauf), oder ob bereits ein vorheriger Programmdurchlauf ein solches Segment erzeugt hatte, und dessen Informationen weiterverwendet werden sollen: 1 /* Check if a shmid-file already exists */ fd = open(filename_shm,o_rdonly); if ((fd < 0) && (errno == ENOENT)) 5 int shm_id, len; /* We are run for the first time!!! */ _FirstRun = 1; 10 /* Create a new shm-segment and attach it... */ shm_id = new_shm(); att_shm(shm_id); /* Create a new File... */ 15 if ((fd = open(filename_shm,o_wronly O_CREAT,0600)) < 0) perror("error creating shmid-file"),exit(1); /*...write the shm-id to it... */ len = sprintf(buf, "%d", shm_id); 20 if (write(fd, buf, len) < 0) perror("error writing to shmid-file"),exit(1); /*...and close the file */ close(fd); 25 else if (fd < 0) perror("error opening shmid-file"),exit(1); else /* We are run for the n-th time!!! */ _FirstRun = 0; 30 /* Read the shm-id from the file... */ if (read(fd,buf,100) < 0) perror("error reading from shmid-file"),exit(1); 35 /*...close the file... */ close(fd); 40 /*...and attach the existing shm-segment */ att_shm(atoi(buf)); 40

41 Nun steht auf jeden Fall ein SHM-Segment zur Verfügung (entweder ein neues, oder eines das bereits vorhanden war). Die eigentliche Arbeit kann beginnen: 1 /* do the main work */ dowork(); /* Cleanup (will never be executed!!!) */ 5 det_shm(); return 0; Da der Server kein reguläres Programmende vorsieht, wird der anschließende Code zum entfernen des SHM-Segments niemals ausgeführt werden! Die eigentliche Arbeit gestaltet sich für den Server in relativ klassischer Weise: Er horcht auf dem definierten Port, und falls eine Verbindungsanfrage eintrifft, wird eine neue Prozessinstanz erzeugt, die die Anfrage bearbeitet: 1 void dowork(void) /* Some vars for the socket... */ int orig_sock, new_sock, clnt_len; 5 struct sockaddr_in clnt_adr, serv_adr; /* generate socket */ if ((orig_sock = socket(af_inet, SOCK_STREAM, 0)) < 0) perror("generate error"), exit(1); 10 /* bind socket */ serv_adr.sin_family = AF_INET; serv_adr.sin_addr.s_addr = htonl(inaddr_any); serv_adr.sin_port = htons(port); 15 if (bind(orig_sock, (struct sockaddr *) &serv_adr, sizeof(serv_adr)) < 0) perror("bind error"), exit(1); /* listen for connections... */ if (listen(orig_sock, 5) < 0) 20 perror("listen error"), exit(1); /* MainLoop */ while(1) 25 /* accept a new connection */ new_sock=accept(orig_sock,(struct sockaddr*)&clnt_adr,&clnt_len); if (new_sock < 0) if (errno == EINTR) continue; 30 else perror("accept error"); close(orig_sock); exit(1); 35 /* fork a new child to handle the request */ if (fork() == 0) playsong(new_sock); 40 exit(0); /* end MainLoop */ /* Never executed: */ 45 close(orig_sock); Die neu erzeugte Prozessinstanz bearbeitet nun die Anfrage. Dazu gehört zunächst die Positionierung des Filepointers an die richtige Stelle. Hierfür könnte der fseek()-befehl zum Einsatz kommen, doch zu Demonstrationszwecken werden einfach entsprechend viele Stücke des Files gelesen und verworfen: 1 void playsong(int socket) int file, nread, i; char buf[bufsiz]; 41

42 5 /* open the file */ file = open("/home/achim/work/mp3stream/song.mp3",o_rdonly); if (file < 0) perror("file open error"); 10 close(socket); exit(1); /* do we continue a playback? */ 15 if (_FirstRun) _SharedMemPtr->filePosition = 0; else /* seek to correct position */ 20 for (i = 128; i < _SharedMemPtr->filePosition; i++) /* XMMS-Buffer ~ 128*8KB = 1MB */ read(file, buf, BUFSIZ); Da der Linux MP3-Player XMMS über einen internen Puffer von ca. 1MB verfügt, der bei Abbruch der Verbindung jedoch verworfen wird, muss ein entsprechend großes Stück erneut gesendet werden. Das Vorspulen der Datei wird also um ca. 1MB verkürzt. Die Systemkonstante BUFSIZ beträgt bei Linux-Systemen übrigens 8K (Standardpuffergröße). Das Audio-Stück wurde geöffnet, und der Filepointer an die korrekte Position bewegt. Die eigentliche Wiedergabe kann nun beginnen: 1 /* write HTTP-Header to socket */ memset(&buf, 0, BUFSIZ); /* clear buffer */ sprintf(buf,"http/ OK\r\nContent-Type:audio/mpeg\r\n\r\n"); write(socket, buf, BUFSIZ); /* write buffer to socket */ 5 /* write file to socket */ do memset(&buf, 0, BUFSIZ); /* clear buffer */ nread = read(file, buf, BUFSIZ); /* read file to buffer*/ 10 if (nread == 0) break; /* file is empty */ write(socket, buf, BUFSIZ); /* write buffer to socket */ /* CHECKPOINT! */ _SharedMemPtr->filePosition++; 15 chnode(); while (nread == BUFSIZ); /* file longer than BUFSIZ... read again! */ Nach jedem Schreibvorgang von jeweils 8KB wird ein Wiederaufsetzpunkt implementiert: Der Filepointer wird im SHM-Segment gesichert, und die Speichersegmente werden im Cluster synchronisiert (mit Hilfe des migrate()-systemaufrufs). Die Wiedergabe wird fortgesetzt, solange das Ende der Datei noch nicht erreicht ist. Nach Ende der Wiedergabe werden sowohl die Datei, als auch der Socket geschlossen, und das SHM-Segment wird wieder auf den Anfangswert initialisiert, damit bei nachfolgenden Anfragen die Wiedergabe wieder von vorne beginnt: 1 close(socket); 2 close(file); 3 _SharedMemPtr->filePosition = 0; 4 42

43 5.2. Verifikation Nachdem das Hauptprogramm mitsamt dem Lirary-File compiliert wurde (wegen der Verwendung von OpenSSI-API Funktionen muss mit der libcluster gelinkt werden: gcc... -lcluster), kann verifiziert werden, ob die gewünschte Funktionalität erbracht wird. Hier noch einmal eine schematische Übersicht des Zusammenspiels der einzelnen Komponenten des hochverfügbaren Dienstes: Abbildung 8. Schematischer Aufbau der Hochverfügbarkeitskomponenten: Der hochverfügbare Dienst wird im init-prozess registriert, und über ihn automatisch gestartet. Der Kernel überwacht daraufhin die Aktivität des Prozesses, und falls dieser ausfällt (dies wird mit Hilfe der Heartbeat-Software überwacht) wird eine neue Instanz gestartet. All diese Instanzen sind unter einer gemeinsamen IP-Adresse erreichbar - egal auf welchem Knoten der Dienst läuft. Dieses Verhalten wird über einen LVS-Routerknoten (sog. Redirector ) realisiert. Die Daten, die den Zustand des Dienstes repräsentieren, sind in einem SHM-Segment abgelegt und von allen Knoten aus erreichbar. Für einen Klienten erscheint das gesamte Cluster wie eine einzige hochverfügbare Maschine. Er kann nicht erkennen, welcher Knoten die Anfrage tatsächlich bearbeitet. Ein MP3-Player (im Beispiel das Linuxprogramm XMMS), der eine Anfrage an den entsprechenden Port des Medienservers stellt, erhält als Antwort einen Audiostream, den er nach und nach abspielt: 43

44 Abbildung 9. Der Linux MP3-Player XMMS spielt den Audiostream: Fällt der Knoten aus, auf dem der Prozess lief, der den Klienten bedient, bricht die Verbindung zunächst nicht ab! Der MP3-Player XMMS verfügt über einen internen Puffer, der ausreicht um die Wiedergabe noch ca. 10 bis 15 Sekunden fortzusetzen. Doch wenn dieser Puffer aufgebraucht ist, stoppt die Wiedergabe - die Verbindung wurde auf TCP/IP-Ebene unterbrochen. Die Clustersoftware hat zwischenzeitlich allerdings dafür gesorgt, dass unter der gleichen IP-Adresse und dem gleichen Port eine neue Instanz des Dienstes zur Verfügung steht. Ein erneuter Verbindungsaufbau des Klienten bewirkt das Fortsetzen der Wiedergabe an der Stelle, an der sie unterbrochen wurde. Dieser erneute Verbindungsaufbau kann entweder manuell geschehen, oder über die Repeat -Funktion des MP3-Players. Ist der Repeat-Modus aktiviert, so wird unmittelbar nachdem die Verbindung abgebrochen ist (das Audiostück scheint zu Ende zu sein) eine neue Verbindung zum gleichen Host aufgebaut. Dadurch schrumpft die Pause in der Wiedergabe auf den Bruchteil einer Sekunde - ein Knotenausfall ist kaum hörbar. Natürlich ist der erneute Verbindungsaufbau durch den Klienten ein Schwachpunkt des Konzepts. Doch ein anderes Verhalten ist durch ein Linux-OpenSSI System nicht realisierbar: Eine Socketverbindung besteht immer zwischen genau zwei Prozessen. Fällt einer der beiden Prozesse aus, bricht auch auch die Socketverbindung ab. Da ein Knotenfehler nicht vorhergesehen werden kann, kann auch immer erst im Nachhinein darauf reagiert werden - und auf TCP/IP-Ebene ist die Session dann bereits verloren gegangen. Da nicht mehrere Prozesse gleichzeitig eine Socketverbindung bedienen können, können auch keine anderen Replikationsmodelle (z.b. aktive Replikation: mehrere Serverinstanzen bedienen redundant einen Klienten) zum Einsatz kommen. Ein weiteres Hindernis stellt der interne Puffer des MP3-Players dar. XMMS verfügt über insgesamt ca. 1MB Puffer, der allerdings teilweise verworfen wird, falls die Verbindung zum Server abbricht. Es muss also ein Stück der Audiodatei erneut versendet werden. Die im obigen Programmbeispiel dafür vorgesehenen Größen beruhen auf Erfahrungswerten - die exakte Größe schwankt je nach Zeitpunkt der Unterbrechung. Eine ganz exakte Wiedergabe über einen Knotenausfall hinweg ist daher nicht möglich. Die erreichte Genauigkeit liegt jedoch im einstelligen Sekundenbereich. Durch die beiden oben erwähnten Punkte äußert sich ein Knotenausfall durch einen kleinen Sprung in der Wiedergabe der Audiodatei. Diese hat ihren Ursprung in der Architektur des Klienten, also des MP3-Spielers XMMS. Andere Klienten (z.b. WinAMP) wurden im Rahmen des Projekts nicht weiter untersucht, weisen aber vergleichbare Architekturmerkmale auf. 44

Cluster Operating Systems

Cluster Operating Systems Lehrstuhl für Rechnerarchitektur, Professor Brüning Cluster Operating Systems Seminarvortrag im Wintersemester 2003/04 von Frank Ueltzhöffer 1. Einführung und Motivation 2. Charakterisierung 3. Herausforderungen

Mehr

RAC auf Sun Cluster 3.0

RAC auf Sun Cluster 3.0 RAC auf Sun Cluster 3.0 Schlüsselworte RAC, OPS, Sun Cluster, Performance, Availability Zusammenfassung Oracle hat mit dem Real Application Cluster (RAC) aus einer Hochverfügbarkeitslösung eine Höchstverfügbarkeitslösung

Mehr

Red Hat Cluster Suite

Red Hat Cluster Suite Red Hat Cluster Suite Building high-available Applications Thomas Grazer Linuxtage 2008 Outline 1 Clusterarten 2 3 Architektur Konfiguration 4 Clusterarten Was ist eigentlich ein Cluster? Wozu braucht

Mehr

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis...

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis... 1 Einführung................................................ 1 1.1 Was ist ein Betriebssystem?............................... 1 1.1.1 Betriebssystemkern................................ 2 1.1.2 Systemmodule....................................

Mehr

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen Albrecht Achilles 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Betriebssysteme Eine kompakte Einführung mit Linux

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Oracle Database 10g Die RAC Evolution

Oracle Database 10g Die RAC Evolution Oracle Database 10g Die RAC Evolution Markus Michalewicz BU Database Technologies ORACLE Deutschland GmbH 2 Page 1 www.decus.de 1 RAC-Revolution, RAC-Evolution & Computing Oracle8i mit OPS Oracle9i Rel.

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

2. Braunschweiger Linux-Tage. Vortrag über RAID. von. Thomas King. http://www.t-king.de/linux/raid1.html. 2. Braunschweiger Linux-Tage Seite 1/16

2. Braunschweiger Linux-Tage. Vortrag über RAID. von. Thomas King. http://www.t-king.de/linux/raid1.html. 2. Braunschweiger Linux-Tage Seite 1/16 2. Braunschweiger Linux-Tage Vortrag über RAID von Thomas King http://www.t-king.de/linux/raid1.html 2. Braunschweiger Linux-Tage Seite 1/16 Übersicht: 1. Was ist RAID? 1.1. Wo wurde RAID entwickelt? 1.2.

Mehr

Eine hochverfügbare Firewall mit iptables und fwbuilder. Secure Linux Administration Conference, 11. Dec 2008

Eine hochverfügbare Firewall mit iptables und fwbuilder. Secure Linux Administration Conference, 11. Dec 2008 Eine hochverfügbare Firewall mit iptables und fwbuilder Secure Linux Administration Conference, 11. Dec 2008 Dr. Michael Schwartzkopff HA Firewall mit fwbuilder, SLAC 2008 / 1 Eine einfache Firewall Eine

Mehr

OpenSSI Cluster. Seminararbeit. felix.bindschaedler@students.fhnw.ch. Studiengang: Informatik

OpenSSI Cluster. Seminararbeit. felix.bindschaedler@students.fhnw.ch. Studiengang: Informatik OpenSSI Cluster Seminararbeit Autor: Felix Bindschädler 6im felix.bindschaedler@students.fhnw.ch Department: Technik Studiengang: Informatik Richtung: IT System Management Dozenten: Prof. H.P. Oser Dr.

Mehr

Mailbox Cluster Konzepte

Mailbox Cluster Konzepte Ideen für grosse Mailstores Mailbox Cluster Konzepte Felix J. Ogris (fjo@dts.de) Version 1.0 2008-05-25 Inhaltsverzeichnis Inhaltsverzeichnis Inhaltsverzeichnis 1 Schema 4 2 Storage 5 2.1 Mailbox- und

Mehr

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

Installations-Dokumentation, YALG Team

Installations-Dokumentation, YALG Team Installations-Dokumentation, YALG Team Version 8.1 1 Benötigtes Material 2 Vor der Installation 3 Beginn 4 Installation 4.1 Sicherheit 4.2 Partitionierung 4.3 Paketauswahl 4.4 Paketauswahl (fein) 5 Konfiguration

Mehr

Eine hochverfügbare Firewall mit Linux-HA, iptables und fwbuilder

Eine hochverfügbare Firewall mit Linux-HA, iptables und fwbuilder Eine hochverfügbare Firewall mit Linux-HA, iptables und fwbuilder FROSCON, 23.8.2009 Dr. Michael Schwartzkopff HA Firewall mit fwbuilder, Seite 1 Eine einfache Firewall Eine einfache Firewall mit Linux

Mehr

Clustering und Failover mit Linux

Clustering und Failover mit Linux Grazer Linux-Tage 2003 25. April Markus Oswald Worum geht es? Load-Balanced Cluster Failover Cluster Shared Storage Computational Cluster Beowulf Distributed Computing Worum es nicht

Mehr

Cluster Quick Start Guide

Cluster Quick Start Guide Cluster Quick Start Guide Cluster SR2500 Anleitung zur Konfi guration KURZÜBERBLICK CLUSTER SEITE 2 FUNKTIONSWEISE DES THOMAS KRENN CLUSTERS (SCHAUBILD) SEITE 3 CLUSTER AUFBAUEN UND KONFIGURIEREN SEITE

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

Lab 13: Multi Processor Systems II

Lab 13: Multi Processor Systems II Lab 13: Multi Processor Systems II 1. Können Sie sich erklären warum die Summe nicht 200% ergibt? Warum entspricht die Auslastung nicht 100% pro Prozessor? 100% ist die gesamte Auslastung vom System alle

Mehr

High Performance Computing Cluster-Lösung mit MOSIX im Einsatz bei VA-TECH HYDRO

High Performance Computing Cluster-Lösung mit MOSIX im Einsatz bei VA-TECH HYDRO High Performance Computing Cluster-Lösung mit MOSIX im Einsatz bei VA-TECH HYDRO Anastasios Stomas SFI Technology Services AG 12. März 2003 anastasios.stomas@sfi.ch Seite 1 Hintergrund INHALT Cluster-

Mehr

Netzwerke 3 Praktikum

Netzwerke 3 Praktikum Netzwerke 3 Praktikum Aufgaben: Routing unter Linux Dozent: E-Mail: Prof. Dr. Ch. Reich rch@fh-furtwangen.de Semester: CN 4 Fach: Netzwerke 3 Datum: 24. September 2003 Einführung Routing wird als Prozess

Mehr

Solaris Cluster. Dipl. Inform. Torsten Kasch 8. Januar 2008

Solaris Cluster. Dipl. Inform. Torsten Kasch <tk@cebitec.uni Bielefeld.DE> 8. Januar 2008 Dipl. Inform. Torsten Kasch 8. Januar 2008 Agenda Übersicht Cluster Hardware Cluster Software Konzepte: Data Services, Resources, Quorum Solaris Cluster am CeBiTec: HA Datenbank

Mehr

VPN mit Windows Server 2003

VPN mit Windows Server 2003 VPN mit Windows Server 2003 Virtuelle private Netzwerke einzurichten, kann eine sehr aufwendige Prozedur werden. Mit ein wenig Hintergrundwissen und dem Server- Konfigurationsassistenten von Windows Server

Mehr

DSLinux Skriptbasierte Inventarisierung für Linux

DSLinux Skriptbasierte Inventarisierung für Linux DSLinux Skriptbasierte Inventarisierung für Linux www.docusnap.com TITEL DSLinux AUTOR Docusnap Consulting DATUM 21.04.2015 Die Weitergabe, sowie Vervielfältigung dieser Unterlage, auch von Teilen, Verwertung

Mehr

Agenda. Einleitung Produkte vom VMware VMware Player VMware Server VMware ESX VMware Infrastrukture. Virtuelle Netzwerke

Agenda. Einleitung Produkte vom VMware VMware Player VMware Server VMware ESX VMware Infrastrukture. Virtuelle Netzwerke VMware Server Agenda Einleitung Produkte vom VMware VMware Player VMware Server VMware ESX VMware Infrastrukture Virtuelle Netzwerke 2 Einleitung Virtualisierung: Abstrakte Ebene Physikalische Hardware

Mehr

Byte-Taxi. Bedienungsanleitung. Seite 1 von 8

Byte-Taxi. Bedienungsanleitung. Seite 1 von 8 Byte-Taxi Bedienungsanleitung Seite 1 von 8 Inhaltsverzeichnis 1. Beschreibung 3 2. Systemvoraussetzungen 4 3. Installationsanleitung 5 4. Bedienung 6 5. Infos & Kontakt 8 Seite 2 von 8 1. Beschreibung

Mehr

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Virtuelle StruxureWare Data Center Expert-Appliance Der StruxureWare Data Center Expert-7.2-Server ist als virtuelle Appliance verfügbar, die auf

Mehr

Linux-Kernel- Programmierung

Linux-Kernel- Programmierung Michael Beck, Harald Böhme, Mirko Dziadzka, Ulrich Kunitz, Robert Magnus, Dirk Verworner Linux-Kernel- Programmierung Algorithmen und Strukturen der Version 1.0 ADDISON-WESLEY PUBLISHING COMPANY Bonn Paris

Mehr

Shibboleth Clustering und Loadbalancing

Shibboleth Clustering und Loadbalancing Shibboleth Clustering und Loadbalancing STEINBUCH CENTRE FOR COMPUTING - SCC KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Computercluster

Mehr

The Unbreakable Database System

The Unbreakable Database System The Unbreakable Database System Real Application Cluster Unterföhring, 04.2005 M. Kühn 1 Comparisson HA - HA Ziele, DataGuard, HA Oracle, RAC RAC Features - Cache Fusion, TAF, Load Balancing RAC on Solaris

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

KURZANLEITUNG CLOUD BLOCK STORAGE

KURZANLEITUNG CLOUD BLOCK STORAGE KURZANLEITUNG CLOUD BLOCK STORAGE Version 1.12 01.07.2014 SEITE _ 2 INHALTSVERZEICHNIS 1. Einleitung......Seite 03 2. Anlegen eines dauerhaften Block Storage...Seite 04 3. Hinzufügen von Block Storage

Mehr

6.6.4 Cluster Interconnect im Private Network

6.6.4 Cluster Interconnect im Private Network Hardware-Architektur 221 6.6.4 Cluster Interconnect im Private Network Zwischen den Knoten des RAC werden viele, meist sehr kleine Pakete über den Cluster Interconnect ausgetauscht. Kurze Latenzzeiten

Mehr

storage management (c) Till Hänisch 2003, BA Heidenheim

storage management (c) Till Hänisch 2003, BA Heidenheim storage management (c) Till Hänisch 2003, BA Heidenheim warum? haenisch@susi:~ > df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda3 35115800 16351708 16980076 50% / /dev/sda1 23300 3486 18611

Mehr

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria Seite 2 von 10 1 Inhaltsverzeichnis 2 Warum CORVUS by init.at... 3 3 Ihre Vorteile durch CORVUS... 3 4 CORVUS Features... 4

Mehr

VirtualBox und OSL Storage Cluster

VirtualBox und OSL Storage Cluster VirtualBox und OSL Storage Cluster A Cluster in a Box A Box in a Cluster Christian Schmidt Systemingenieur VirtualBox und OSL Storage Cluster VirtualBox x86 und AMD/Intel64 Virtualisierung Frei verfügbar

Mehr

[Geben Sie Text ein] ISCSI Targets mit der Software FreeNAS einrichten

[Geben Sie Text ein] ISCSI Targets mit der Software FreeNAS einrichten [Geben Sie Text ein] ISCSI Targets mit der Software FreeNAS einrichten ISCSI Targets mit der Software FreeNAS einrichten Inhalt FreeNAS Server Vorbereitung... 2 Virtuelle Maschine einrichten... 3 FreeNAS

Mehr

Softwareverteilung. mit. m23

Softwareverteilung. mit. m23 Softwareverteilung mit m23 Überblick Was ist Softwareverteilung? Was ist m23? Warum m23? Wie funktioniert m23? Live-Demonstration Was ist Softwareverteilung? Was ist Softwareverteilung? Installation von:

Mehr

Linux-HA-Cluster Heartbeat mit DRBD

Linux-HA-Cluster Heartbeat mit DRBD Linux-HA-Cluster Heartbeat mit DRBD Thomas Röhl 01. Oktober 2004 Inhalt Was ist ein HA-Cluster? Vorbereiten des Projekts Hardware Software Allgemeiner Aufbau des Clusters Installation von DRBD Installation

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

LVM AUSARBEITUNGEN ZUM THEMA A6: TIMO BÖLLINGER DOMINIC ECKART DOZENT: PROF. TISCHHHAUSER MANNHEIM 2004 VON UND

LVM AUSARBEITUNGEN ZUM THEMA A6: TIMO BÖLLINGER DOMINIC ECKART DOZENT: PROF. TISCHHHAUSER MANNHEIM 2004 VON UND 1 AUSARBEITUNGEN ZUM THEMA A6: LVM VON TIMO BÖLLINGER UND DOMINIC ECKART DOZENT: PROF. TISCHHHAUSER MANNHEIM 2004 2 INHALTSVERZEICHNIS 1. LOGICAL VOLUME MANAGEMENT EINFÜHRUNG...3 1.1. WAS KANN LVM?...4

Mehr

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network.

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network. 56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen aktiv inaktiv Node 1 ( Aktiv ) Node 2 ( Passiv ) Private Network aktiv inaktiv (exklusiver Zugriff) Abbildung 3.1: Schematische Darstellung

Mehr

Herzlich willkommen zur Präsentation:

Herzlich willkommen zur Präsentation: Seite 1 Herzlich willkommen zur Präsentation: Der Diskless Shared Root Cluster eine optimale Plattform für SAP Dipl. Ing. (FH) Reiner Rottmann rottmann@atix.de 19 April 2007 Seite 2 Wir helfen Ihnen, Ihre

Mehr

The Unbreakable Database System

The Unbreakable Database System The Unbreakable Database System Real Application Cluster auf Sun Cluster 3.0 Unterföhring, 11.2002 M. Beeck, M. Kühn 1 Comparisson HA - HA Ziele, DataGuard, HA Oracle, RAC Sun Cluster 3.0 Key Features

Mehr

Win7Deploy Seite 2 von 17. Was ist Win7Deploy?

Win7Deploy Seite 2 von 17. Was ist Win7Deploy? Win7Deploy Seite 1 von 17 Win7Deploy Eine einfache, passgenaue und kostengünstige Lösung um Windows 7 in Ihrem Unternehmen einzuführen [ www.win7deploy.de ] Ablauf einer Win7Deploy Installation am Beispiel

Mehr

MVB3. Einrichten eines Servers für MVB3 ab Version 3.5. Admin-Dokumentation. Inhalt V3.05.001

MVB3. Einrichten eines Servers für MVB3 ab Version 3.5. Admin-Dokumentation. Inhalt V3.05.001 V3.05.001 MVB3 Admin-Dokumentation Einrichten eines Servers für MVB3 ab Version 3.5 Inhalt Organisatorische Voraussetzungen... 1 Technische Voraussetzungen... 1 Konfiguration des Servers... 1 1. Komponenten

Mehr

Internet Security 2009W Protokoll Firewall

Internet Security 2009W Protokoll Firewall Internet Security 2009W Protokoll Firewall Manuel Mausz, Matr. Nr. 0728348 manuel-tu@mausz.at Aldin Rizvanovic, Matr. Nr. 0756024 e0756024@student.tuwien.ac.at Wien, am 25. November 2009 1 Inhaltsverzeichnis

Mehr

Netzwerk Teil 2 Linux-Kurs der Unix-AG

Netzwerk Teil 2 Linux-Kurs der Unix-AG Netzwerk Teil 2 Linux-Kurs der Unix-AG Zinching Dang 17. Juni 2015 Unterschied Host Router Standardverhalten eines Linux-Rechners: Host nur IP-Pakete mit Zieladressen, die dem Rechner zugeordnet sind,

Mehr

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND init.at informationstechnologie GmbH - Tannhäuserplatz 2 - A-1150 Wien - www.init.at Dieses Dokument und alle Teile von ihm bilden ein geistiges Eigentum

Mehr

Linux Desaster Recovery. Kai Dupke, probusiness AG

Linux Desaster Recovery. Kai Dupke, probusiness AG Linux Desaster Recovery Kai Dupke, probusiness AG Agenda Vorstellung Problemstellung Desaster Recovery Verfahren Linux & Desaster Recovery Lösungen - Kommerziell & Open Source Enterprise Desaster Recovery

Mehr

Verfügbarkeit von Applikationen und Failover Szenarien. Winfried Wojtenek. wojtenek@mac.com

Verfügbarkeit von Applikationen und Failover Szenarien. Winfried Wojtenek. wojtenek@mac.com Verfügbarkeit von Applikationen und Failover Szenarien Winfried Wojtenek wojtenek@mac.com Verfügbarkeit % Tage Stunden Minuten 99.000 3 16 36 99.500 1 20 48 99.900 0 9 46 99.990 0 0 53 99.999 0 0 5 Tabelle

Mehr

Cluster und Load Balancer

Cluster und Load Balancer Cluster und Load Balancer Hochverfügbare Systeme... vermindern das Risiko eines Totalausfalls durch Redundante und ausfallsichere Serverkonfiguration Redundante und ausfallsicher Netzwerkkonfiguration

Mehr

NAT und Firewalls. Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de. Universität Bielefeld Technische Fakultät

NAT und Firewalls. Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de. Universität Bielefeld Technische Fakultät NAT und Firewalls Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät Stand der Veranstaltung 13. April 2005 Unix-Umgebung 20. April 2005 Unix-Umgebung 27. April 2005

Mehr

7 Transportprotokolle

7 Transportprotokolle 7 Transportprotokolle 7.1 Transmission Control Protocol (TCP) 7.2 User Datagram Protocol (UDP) 7.3 Ports 7.1 TCP (1) IP-Pakete (Datagramme) von A nach B transportieren reicht nicht interaktive Verbindungen

Mehr

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen Konzept für eine Highperformance- und Hochverfügbarkeitslösung für Anforderungen : einen Anbieter von Krankenhaus Abrechnungen Es soll eine Cluster Lösung umgesetzt werden, welche folgende Kriterien erfüllt:

Mehr

Root-Server für anspruchsvolle Lösungen

Root-Server für anspruchsvolle Lösungen Root-Server für anspruchsvolle Lösungen I Produktbeschreibung serverloft Internes Netzwerk / VPN Internes Netzwerk Mit dem Produkt Internes Netzwerk bietet serverloft seinen Kunden eine Möglichkeit, beliebig

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

Collax Web Application

Collax Web Application Collax Web Application Howto In diesem Howto wird die Einrichtung des Collax Moduls Web Application auf einem Collax Platform Server anhand der LAMP Anwendung Joomla beschrieben. LAMP steht als Akronym

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

Mehr

How-to: Webserver NAT. Securepoint Security System Version 2007nx

How-to: Webserver NAT. Securepoint Security System Version 2007nx Securepoint Security System Inhaltsverzeichnis Webserver NAT... 3 1 Konfiguration einer Webserver NAT... 4 1.1 Einrichten von Netzwerkobjekten... 4 1.2 Erstellen von Firewall-Regeln... 6 Seite 2 Webserver

Mehr

Documentation. OTRS Appliance Installationshandbuch. Build Date:

Documentation. OTRS Appliance Installationshandbuch. Build Date: Documentation OTRS Appliance Installationshandbuch Build Date: 10.12.2014 OTRS Appliance Installationshandbuch Copyright 2001-2014 OTRS AG Dieses Werk ist geistiges Eigentum der OTRS AG. Es darf als Ganzes

Mehr

Wenn XP-Programme in Windows 7 nicht laufen, muss man eine XP-Umgebung bereit stellen. Wie das geht, zeigt dieser Artikel.

Wenn XP-Programme in Windows 7 nicht laufen, muss man eine XP-Umgebung bereit stellen. Wie das geht, zeigt dieser Artikel. XP-Programme in Windows 7 mittels VirtualBox Wenn XP-Programme in Windows 7 nicht laufen, muss man eine XP-Umgebung bereit stellen. Wie das geht, zeigt dieser Artikel. Inhalt Was ist eine virtuelle Maschine

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Linux Desaster Recovery

Linux Desaster Recovery Linux Desaster Recovery Schlomo Schapiro Senior Consultant sschapiro@probusiness.de 05.04.2005 Agenda Vorstellung Problemstellung Desaster Recovery Verfahren Linux & Desaster Recovery Lösungen - Kommerziell

Mehr

2 Virtualisierung mit Hyper-V

2 Virtualisierung mit Hyper-V Virtualisierung mit Hyper-V 2 Virtualisierung mit Hyper-V 2.1 Übersicht: Virtualisierungstechnologien von Microsoft Virtualisierung bezieht sich nicht nur auf Hardware-Virtualisierung, wie folgende Darstellung

Mehr

Clustering und Failover mit Linux 2004. Markus Oswald

Clustering und Failover mit Linux 2004. Markus Oswald <moswald@iirc.at> Grazer Linux-Tage 2004 7. / 8. Mai Clustering und Failover mit Linux 2004 Markus Oswald 2004 Worum geht es? Load-Balanced Cluster Failover Cluster Shared Storage (DRBD) Computational

Mehr

Securepoint Security Systems

Securepoint Security Systems HowTo: Virtuelle Maschine in VMware für eine Securepoint Firewall einrichten Securepoint Security Systems Version 2007nx Release 3 Inhalt 1 VMware Server Console installieren... 4 2 VMware Server Console

Mehr

Software Bedienungsanleitung. ENiQ Access Management: Online-Inbetriebnahme

Software Bedienungsanleitung. ENiQ Access Management: Online-Inbetriebnahme Software Bedienungsanleitung ENiQ Access Management: Online-Inbetriebnahme V1.0 April 2015 Inhaltsverzeichnis 1 Voraussetzungen... 3 2 Allgemeine Hinweise... 3 3 Generelle Einstellungen... 3 4 Dienste

Mehr

Server Installation 1/6 20.10.04

Server Installation 1/6 20.10.04 Server Installation Netzwerkeinrichtung Nach der Installation müssen die Netzwerkeinstellungen vorgenommen werden. Hierzu wird eine feste IP- Adresse sowie der Servername eingetragen. Beispiel: IP-Adresse:

Mehr

Mit Clustertechnik zu mehr Verfügbarkeit:

Mit Clustertechnik zu mehr Verfügbarkeit: Mit Clustertechnik zu mehr Verfügbarkeit: Überraschend kostengünstig umgesetzt mit Open Source Werner Fischer, Thomas-Krenn.AG Perspektive Open Source Systems 2006 25. Oktober 2006 Folie 1/20 Agenda 1.

Mehr

Verwaltung der MSATA-SSD bei HP Envy Ultrabook 4 und Ultrabook 6 mit Intel Smart Response Technologie

Verwaltung der MSATA-SSD bei HP Envy Ultrabook 4 und Ultrabook 6 mit Intel Smart Response Technologie Verwaltung der MSATA-SSD bei HP Envy Ultrabook 4 und Ultrabook 6 mit Intel Smart Response Technologie 1. Allgemeine Verwaltung / Feststellen der Größe der MSATA-SSD Die MSATA-SSD bei HP Envy Ultrabook

Mehr

Windows 7 parallel zu XP oder Vista installieren ohne aufwändige Partitionierung - einfach in ein Datei mittels virtueller Festplatte (VHD)

Windows 7 parallel zu XP oder Vista installieren ohne aufwändige Partitionierung - einfach in ein Datei mittels virtueller Festplatte (VHD) Windows 7 parallel zu XP oder Vista installieren ohne aufwändige Partitionierung - einfach in ein Datei mittels virtueller Festplatte (VHD) Windows 7 läßt sich auch einfach in eine Datei installieren (VHD

Mehr

Tapps mit XP-Mode unter Windows 7 64 bit (V2.0)

Tapps mit XP-Mode unter Windows 7 64 bit (V2.0) Tapps mit XP-Mode unter Windows 7 64 bit (V2.0) 1 Einleitung... 2 2 Download und Installation... 3 2.1 Installation von WindowsXPMode_de-de.exe... 4 2.2 Installation von Windows6.1-KB958559-x64.msu...

Mehr

Dokumentation Schulprojekt: Samba als Serverdienst

Dokumentation Schulprojekt: Samba als Serverdienst Dokumentation Schulprojekt: Samba als Serverdienst Sandra Schreiner und Sascha Lenhart 20. September 2007 Inhaltsverzeichnis 1 Einleitung 3 1.1 Projektbeschreibung.............................. 3 1.2 Projektziele...................................

Mehr

Prototypvortrag. Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning. Projektseminar WS 2009/10

Prototypvortrag. Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning. Projektseminar WS 2009/10 Prototypvortrag Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning Projektseminar WS 2009/10 Eugen Fot, Sebastian Kenter, Michael Surmann AG Parallele

Mehr

IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT

IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT Version 2.1 Original-Application Note ads-tec GmbH IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT Stand: 28.10.2014 ads-tec GmbH 2014 Big-LinX 2 Inhaltsverzeichnis 1 Einführung... 3 1.1 NAT

Mehr

Die wichtigsten Vorteile von SEPPmail auf einen Blick

Die wichtigsten Vorteile von SEPPmail auf einen Blick Die wichtigsten Vorteile von SEPPmail auf einen Blick August 2008 Inhalt Die wichtigsten Vorteile von SEPPmail auf einen Blick... 3 Enhanced WebMail Technologie... 3 Domain Encryption... 5 Queue-less Betrieb...

Mehr

bintec Workshop Dynamic Host Configuration Protocol Copyright 8. November 2005 Funkwerk Enterprise Communications GmbH Version 0.9

bintec Workshop Dynamic Host Configuration Protocol Copyright 8. November 2005 Funkwerk Enterprise Communications GmbH Version 0.9 bintec Workshop Dynamic Host Configuration Protocol Copyright 8. November 2005 Funkwerk Enterprise Communications GmbH Version 0.9 Ziel und Zweck Haftung Marken Copyright Richtlinien und Normen Wie Sie

Mehr

Clustering mit Shared Storage. Ing. Peter-Paul Witta paul.witta@cubit.at

Clustering mit Shared Storage. Ing. Peter-Paul Witta paul.witta@cubit.at Clustering mit Shared Storage Ing. Peter-Paul Witta paul.witta@cubit.at Clustering mehrere kleine Rechner leisten gemeinsam Grosses günstige dual intel/amd Server load sharing High Availability combined

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

Benutzerhandbuch für FaxClient für HylaFAX

Benutzerhandbuch für FaxClient für HylaFAX Benutzerhandbuch für FaxClient für HylaFAX Vielen Dank, daß Sie entschlossen haben, dieses kleine Handbuch zu lesen. Es wird Sie bei der Installation und Benutzung des FaxClients für HylaFAX unterstützen.

Mehr

Stefan Dahler. 1. Konfiguration der Stateful Inspection Firewall. 1.1 Einleitung

Stefan Dahler. 1. Konfiguration der Stateful Inspection Firewall. 1.1 Einleitung 1. Konfiguration der Stateful Inspection Firewall 1.1 Einleitung Im Folgenden wird die Konfiguration der Stateful Inspection Firewall beschrieben. Es werden Richtlinien erstellt, die nur den Internet Verkehr

Mehr

Technische Übersicht über den Netzwerklastenausgl eich (Network Load Balancing) Einführung

Technische Übersicht über den Netzwerklastenausgl eich (Network Load Balancing) Einführung Technische Übersicht über den Netzwerklastenausgl eich (Network Load Balancing) Einführung - Dienst wird in den Betriebssystemen Windows 2000 Advanced Server und Windows 2000 Datacenter Server bereitgestellt.

Mehr

SMTP und POP3 mit Windows Server 2003 (Gastbeitrag tecchannel)

SMTP und POP3 mit Windows Server 2003 (Gastbeitrag tecchannel) SMTP und POP3 mit Windows Server 2003 (Gastbeitrag tecchannel) Windows Server 2003 ist der erste Server von Microsoft, der einen kompletten SMTP- und POP3- Dienst mitbringt. Wir zeigen, wie Sie diese Dienste

Mehr

Netzwerk- Konfiguration. für Anfänger

Netzwerk- Konfiguration. für Anfänger Netzwerk- Konfiguration für Anfänger 1 Vorstellung Christian Bockermann Informatikstudent an der Universität Dortmund Freiberuflich in den Bereichen Software- Entwicklung und Netzwerk-Sicherheit tätig

Mehr

Anleitung zur Installation eines Clusters unter VMWare 4.0 (Built 4460)

Anleitung zur Installation eines Clusters unter VMWare 4.0 (Built 4460) Anleitung zur Installation eines Clusters unter VMWare 4.0 (Built 4460) Schritt 1: Erstellen der virtuellen Maschinen 1. Menü File, New, New Virtual Machine... wählen. 2. Auf Weiter > klicken. 3. Die Option

Mehr

4 Aufruf des Servers, Kommandozeilen-Optionen

4 Aufruf des Servers, Kommandozeilen-Optionen 4 Aufruf des Servers, Kommandozeilen-Optionen 4.1 Einführung In diesem Abschnitt lernen Sie verschiedene Methoden zum Start des Apache-Servers, einige der wichtigsten Kommandozeilen-Optionen und Methoden

Mehr

TL-PS110P TL-PS110U TL-PS310U Parallelport-/USB-Printserver

TL-PS110P TL-PS110U TL-PS310U Parallelport-/USB-Printserver TL-PS110P TL-PS110U TL-PS310U Parallelport-/USB-Printserver Rev: 1.2.0 INHALTSVERZEICHNIS 1. IP-Adresse des Printservers einstellen 3 2. Manuelle Erstellung eines TCP/IP-Druckeranschlusses 4 3. TCP/IP-Einstellungen

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Clustering mit Network Appliance Filer

Clustering mit Network Appliance Filer Clustering mit Network Appliance Filer Ing. Peter-Paul Witta paul.witta@cubit.at paul.witta@cubit.at Clustering mit intel/linux mehrere kleine Rechner leisten gemeinsam Grosses günstige dual intel/amd

Mehr

Kurzanleitung. MEYTON Migrationstool. 1 Von 16

Kurzanleitung. MEYTON Migrationstool. 1 Von 16 Kurzanleitung MEYTON Migrationstool 1 Von 16 Inhaltsverzeichnis Sinn und Zweck des Migrationsprogramms...3 Die LIVE C D...3 START...3 Erste Schritte...4 Login...4 Einleitung...5 Die Bedienung...5 Das Hauptmenü...6

Mehr

KNX IP Interface 730 KNX IP Router 750 KNX IP LineMaster 760 KNX IP BAOS 770 KNX IP BAOS 771 KNX IP BAOS 772 KNX IP BAOS 777

KNX IP Interface 730 KNX IP Router 750 KNX IP LineMaster 760 KNX IP BAOS 770 KNX IP BAOS 771 KNX IP BAOS 772 KNX IP BAOS 777 KNX IP Interface 730 KNX IP Router 750 KNX IP LineMaster 760 KNX IP BAOS 770 KNX IP BAOS 771 KNX IP BAOS 772 KNX IP BAOS 777 Fernzugriff mit der ETS Achatz 3 84508 Burgkirchen Tel.: 08677 / 91 636 0 Fax:

Mehr

ab Redirector-Version 2.14

ab Redirector-Version 2.14 Installation: FilterSurf ab Redirector-Version 2.14 Hier werden nun die Schritte erläutert, die nacheinander zu durchlaufen sind, um einen der zentralen FilterSurf -Server verwenden zu können. Die Installationsschritte

Mehr

VMware als virtuelle Plattform

VMware als virtuelle Plattform VMware als virtuelle Plattform Andreas Heinemann aheine@gkec.informatik.tu-darmstadt.de Telekooperation Fachbereich Informatik Technische Universität Darmstadt Übersicht Einführung VMware / Produkte /

Mehr

Erweiterung für Premium Auszeichnung

Erweiterung für Premium Auszeichnung Anforderungen Beliebige Inhalte sollen im System als Premium Inhalt gekennzeichnet werden können Premium Inhalte sollen weiterhin für unberechtigte Benutzer sichtbar sein, allerdings nur ein bestimmter

Mehr

1KONFIGURATION ADDRESS TRANSLATION VON NETWORK. Copyright 24. Juni 2005 Funkwerk Enterprise Communications GmbH Bintec Workshop Version 0.

1KONFIGURATION ADDRESS TRANSLATION VON NETWORK. Copyright 24. Juni 2005 Funkwerk Enterprise Communications GmbH Bintec Workshop Version 0. 1KONFIGURATION VON NETWORK ADDRESS TRANSLATION Copyright 24. Juni 2005 Funkwerk Enterprise Communications GmbH Bintec Workshop Version 0.9 Ziel und Zweck Haftung Marken Copyright Richtlinien und Normen

Mehr

Produkte und Systeme der Informationstechnologie ENERGIE- MANAGEMENT

Produkte und Systeme der Informationstechnologie ENERGIE- MANAGEMENT Produkte und Systeme der Informationstechnologie ENERGIE- MANAGEMENT Folie 1 VDE-Symposium 2013 BV Thüringen und Dresden Virtualisierung von Leittechnikkomponenten Andreas Gorbauch PSIEnergie-EE Folie

Mehr

Hochverfügbarkeits-Szenarien

Hochverfügbarkeits-Szenarien Series Hochverfügbarkeits-Szenarien Mehrere Telefonanlagen können redundant aufgebaut werden. Dabei sind alle Anlagen aktiv geschaltet und teilen sich die Last (Anrufe, Telefonkonferenzen, usw.) gleichmässig

Mehr

XEN Performance. Projektpraktikum Informatik. Arne Klein 2008-02-26. Arne Klein () XEN Performance 2008-02-26 1 / 25

XEN Performance. Projektpraktikum Informatik. Arne Klein 2008-02-26. Arne Klein () XEN Performance 2008-02-26 1 / 25 XEN Performance Projektpraktikum Informatik Arne Klein 2008-02-26 Arne Klein () XEN Performance 2008-02-26 1 / 25 1 Virtualisierung mit XEN 2 Performance von XEN Allgemeines Netzwerk-Performance IO-Performance

Mehr