⭐Master of Science (M.Sc.) Bewertung verschiedener verteilter Dateisysteme auf Linux-basierten Cluster-Rechnern\nMaster of Science (M.Sc.) Bewertung verschiedener verteilter Dateisysteme auf Linux-basierten Cluster-Rechnern\nDownload "Master of Science (M.Sc.) Bewertung verschiedener verteilter Dateisysteme auf Linux-basierten Cluster-Rechnern"\n1 2 Master-Thesis zum Erlangen des akademischen Grades Master of Science (M.Sc.) im Studiengang Informatik im Fachbereich Elektrotechnik und Informatik Bewertung verschiedener verteilter Dateisysteme auf Linux-basierten Cluster-Rechnern vorgelegt von Name: Janke Vorname: Felix Geb. am: in: Greifswald Erstgutachter: Prof. Dr. rer. nat. Michael Koch Fachbereich Elektrotechnik und Informatik Fachhochschule Stralsund Zweitgutachter: Prof. Dr.-Ing. Andreas Noack Fachbereich Elektrotechnik und Informatik Fachhochschule Stralsund Greifswald, den 16. September 20133 4 Vorwort Das Rechenzentrum der Ernst-Moritz-Arndt-Universität plant die Anschaffung eines neuen Compute-Clusters, welcher mehrere Server mit hunderten Kernen aufweisen wird. Dieser dient zur Unterstützung von Doktoranden und Studenten, die in ihrer Tätigkeit komplexe Berechnungen durchführen müssen. Insbesondere Mitarbeiter, die in physikalischen, chemischen, mathematischen oder biochemischen Bereichen tätig sind, benötigen leistungsstarke Hardware, damit mehr Rechenoperationen ausgeführt werden können. Dies ist möglich, indem Aufgaben schneller ausgeführt werden und das es während der Arbeitszeit zu keiner Zeit zu Speicherlimitierungen kommen kann. Aufgrund dessen ist es für das Rechenzentrum zur Ausarbeitung eines optimalen Nutzungskonzeptes wichtig, dass für die gegebenen Anforderungen das möglichst optimale Dateiystem herausgefunden wird. Besonders dieses ist in solchen komplexen Strukturen ein elementar wichtiges Produkt, da es oftmals als Flaschenhals ausgemacht werden kann. Das Lesen und Schreiben zwischengespeicherter Werte ist oftmals langsamer, als die Berechnungen selbst. Zudem ist das Zusammenfassen mehrerer Festplatten zu einem komplexen Datenspeicher notwendig, um eine Limitierung der Festplattenkapazitäten nicht zu schnell zu erreichen. Die folgende Arbeit gibt einen konkreten Überblick darüber, was ein Dateisystem ist, wie diese im allgemeinen aufgebaut sind und zusätzlich wird der Unterschied zwischen regulären und verteilten Dateisystemen aufgezeigt. Durch die nähere Betrachtung dieser, sowie durch verschiedene Testverfahren, welche für einzelne Systeme durchgeführt werden, wird eine Entscheidung bezüglich eines Systems getroffen. Zur Verfügung gestellt wird dafür ein kleinerer Cluster, welcher aus drei einzelnen Servern besteht. Auf diesen können verschiedene Dateisysteme installiert und unterschiedliche Tests durchgeführt werden. Besondere Punkte, die für das Universitätsrechenzentrum für die Entscheidungsfindung notwendig sind, sind die Performance, Stabilität und die Administrationsmöglichkeiten. Das gewählte Produkt sollte open-source verfügbar sein, das bedeutet, das System muss kommerziell zur Verfügung stehen, ohne zusätzliche Kosten zu verursachen. Insbesondere bei solchen Systemen ist es nicht möglich, eine pauschalisierte Aussage über die Stabilität zu treffen, da sich viele noch im Entwicklungsstadium befinden. Als Entscheidungshilfe dient der Blick in andere Rechenzentren, die solche Dateisysteme effektiv einsetzen. ii5 6 Inhaltsverzeichnis 1 Einleitung Motivation Bedeutung der Arbeit Aufbau der Arbeit Compute-Cluster Aufbau eines Compute-Clusters Hochverfügbarkeitscluster Load-Balancing-Cluster High-Performance-Computing-Cluster Eigenschaften Fail-Over Hochverfügbarkeit Skalierbarkeit Verwaltbarkeit Cluster-Filesystems Dateisysteme XFS Aufbau von XFS Fehlerbehandlung Aktuelle Entwicklungen ext Vorteile von ext Aufbau ext Verbreitung von ext BTRFS Aufbau BTRFS Metadatenbehandlung in BTRFS Sicherheit der Daten in BTRFS Rechtevergaben in BTRFS Ausblick iv7 3.4 Zusammenfassung Distributed Filesystems Unterschied zu regulären Filesystems Kriterien zur Auswahl der Dateisysteme FhGFS Interner Aufbau von FhGFS Administration Vor- und Nachteile von FhGFS MooseFS Interner Aufbau von MooseFS Administration Vor- und Nachteile MooseFS CephFS Interner Aufbau von CephFS Administration von CephFS Vor- und Nachteile CephFS GlusterFS Interner Aufbau von GlusterFS Administration Vor- und Nachteile GlusterFS Entscheidung Tests Testsystem Durchgeführte Tests Testauswertung Performance FhGFS MooseFS GlusterFS Zusammenfassung Performance Stabilität FhGFS MooseFS GlusterFS Zusammenfassung Stabilität v8 6.3 Skalierbarkeit FhGFS MooseFS GlusterFS Zusammenfassung Skalierbarkeit Verwaltbarkeit FhGFS MooseFS GlusterFS Zusammenfassung Verwaltbarkeit Zugriffskontrolle FhGFS MooseFS GlusterFS Zusammenfassung Zugriffskontrolle Replikation FhGFS MooseFS GlusterFS Zusammenfassung - Replikation Fehlerverhalten FhGFS MooseFS GlusterFS Zusammenfassung - Fehlerverhalten Heterogenität FhGFS MooseFS GlusterFS Zusammenfassung - Heterogenität Fazit 136 Abbildungsverzeichnis 140 Literaturverzeichnis 143 vi9 Einleitung Kapitel Motivation Die Ernst-Moritz-Arndt-Universität Greifswald zählt zu den ältesten Universitäten im deutschsprachigen Raum. Bereits im Jahr 1456 wurde diese auf Initiative von Bürgern der Hansestadt Greifswald gegründet. Aktuell sind über Studenten an der Universität eingeschrieben. Das Universitätsrechenzentrum verwaltet dabei alle technischen Aufgaben, die zur Unterstützung der Kernprozesse durch Computer anfallen. Dazu zählt der Betrieb des gesamten Datennetzes mit der Zusammenarbeit von Routern, Switches und Firewalls, sowie die Verwaltung der DNS- und DHCP-Services. Das Universitätsrechenzentrum verwaltet zusätzlich die gesamte Telefonie- und -Kommunikationsstruktur der Universität. Zentrales Thema ist allerdings das Nutzermanagement und die Verwaltung von Compute-Servern für komplexe Berechnungen in mathematischen, medizinischen, chemischen, biochemischen und physikalischen Bereichen. Für solche Anwendungen sind Hochleistungsserver nötig, um die Bearbeitungszeit möglichst gering zu halten. Durch optimierten, parallelisierten Quellcode ist ein Einsatz von Cluster-Servern sinnvoll, da mehrere Aufgaben gleichzeitig ausgeführt werden können. Außerdem kann eine Lösung der Limitierung von Festplattenkapazitäten durch das Zusammenfassen zu großen Dateisystemen gefunden werden. Das Rechenzentrum der Ernst-Moritz-Arndt-Universität Greifswald plant dazu die Anschaffung eines neuen Compute-Clusters, welcher mehrere hundert Kerne beinhalten wird. Für ein optimales Nutzungskonzept ist ein direkter Vergleich von verfügbaren Dateisystemen für solche Aufgabengebiete im Hinblick auf Performance, Stabilität, Skalierbarkeit, Ausfallsicherheit und Verwaltbarkeit nötig. Die folgende Arbeit dient dazu, eine Entscheidung hinsichtlich des Dateisystems zu treffen. Dafür werden diese im einzelnen in ihrer Arbeitsweise miteinander verglichen. Aus den Erkenntnissen werden bestimmte Systeme ausgewählt, die zur Durchführung 110 1 Einleitung von verschiedenen Testverfahren auf einem kleineren Compute-Cluster installiert werden. Dieser Vergleich soll darlegen, welches System für die vorherrschenden Anwendungsbereiche am besten geeignet ist. Das daraus resultierende Fazit beeinflusst die Entscheidung, welches Dateisystem auf dem Hochleistungscluster eingesetzt werden soll. Die enge Mitarbeit mit Nutzern des Compute-Clusters hilft dabei, ein Dateisystem herauszufinden, welches den Ansprüchen optimal gerecht werden kann. Dafür wird der Netzverkehr des Universitätsrechenzentrums auf dem aktuellen Cluster untersucht, um zu erkennen, welche Dateigrößen hauptsächlich genutzt werden. Dies ist darum von großer Bedeutung, weil die unterschiedlichen Arten von Dateisystemen unterschiedlich auf verschiedene Dateigrößen reagieren und entsprechend skalieren. 211 1.2 Bedeutung der Arbeit 1 Einleitung Durch die hohen Kosten für einen neuen Compute-Cluster, die auf etwa eine Million Euro beziffert werden, ist es für das Universitätsrechenzentrum äußerst wichtig, dass dieser auch die möglichst maximale Rechenleistung zur Verfügung stellen kann. Dafür sind viele Kriterien von entscheidender Bedeutung. Diese beginnen bei der Auswahl der korrekten Hardware, die für das Einsatzgebiet nötig ist, über die Anbindung der einzelnen Server durch verschiedene Netzwerktopologien, wie zum Beispiel InfiniBand, Myrinet oder 10GbE (10-Gigabit-Ethernet), bis zu den verschiedenen Arten von Kühlsystemen. Bei großen Compute-Clustern auftreten kann, ist, dass oftmals die Bearbeitungszeit eines Problems häufig schneller durchgeführt werden kann, als das die Werte auf Datenträgern abgelegt werden können. Dieser Flaschenhals soll bei dem neuen Cluster möglichst vermieden werden. Das Thema GreenIT spielt auch hierbei eine zentrale Rolle. Dazu zählt das optimale Verhältnis zwischen Betriebskosten und vorhandener Leistung, sowie die Nutzung der Abwärme des Serversystems zur Erwärmung der Warmwasservervorgung des Rechenzentrums. Auch wird darauf geachtet, dass die eingesetzte Hardware möglichst umweltschonend hergestellt wurde und nach der Nutzung entsprechend recycled werden kann. Dafür ist eine enge Zusammenarbeit mit den Herstellern notwendig. Ohne ein performantes Dateisystem ist es nicht möglich, die theoretisch zur Verfügung stehenden Leistung möglichst effizient zu nutzen. Daher ist ein solcher Vergleich von verschiedenen Distributed-File-Systems von großer Bedeutung, da dieser aufzeigt, welches System in welchen Einsatzgebieten die beste Performance bietet. Hierbei darf man allerdings den Punkt der Verwaltbarkeit nicht außer Acht lassen. Das Universitätsrechenzentrum ist bestrebt eine zuverlässige, sichere und einfach zu konfigurierende Implementation zu finden, welche ohne großen Aufwand und zusätzlichen speziellen Kenntnissen zu administrieren ist. 312 1 Einleitung 1.3 Aufbau der Arbeit Die Arbeit ist aufgeteilt in verschiedene Kapitel, die den Aufbau von Compute-Clustern erklären, die regulären und verteilten Dateisysteme beschreibt und miteinander vergleicht, sowie die durchgeführten Testverfahren beschreiben und auswerten. Anschließend erfolgt ein Fazit, welches Dateisystem für welche Einsatzgebiete besser geeignet sind und welches das Universitätsrechenzentrum für den neuen Hochleistungscluster einsetzen könnte. Inhaltsverzeichnis Im Inhaltsverzeichnis wird ein kurzer und prägnanter Überblick über das Thema gegeben und welche Punkte bei der Untersuchung bearbeitet werden. Compute-Cluster Im zweiten Kapitel der Ausarbeitung wird der Aufbau und die Funktionsweise von Compute-Clustern beschrieben. Dieses Wissen wird insbesondere für das bessere Verstehen der Arbeits- und Wirkungsweise von Filesystems und verteilten Dateisystemen benötigt. Dateisysteme In diesem Kapitel werden reguläre Dateisysteme vorgestellt, die sich auf den meisten Linux-basierten Computern befinden. Insbesondere das BTRFS-Filesystem ist hierbei von großer Bedeutung, da es zum einen als Dateisystem der Zukunft gehandelt, aber bereits jetzt schon bei einigen verteilten Dateisystemen als Unterlage empfohlen wird. Distributed Filesystems Insbesondere für den Betrieb in großen Serverfarmen ist der Einsatz von verteilten Dateisystemen eine sehr gute Alternative, um den Flaschenhals der begrenzten Lese- und Schreibgeschwindigkeiten von einzelnen Festplatten und Festplattenverbunde zu minimieren, indem das System automatisch eine Datei auf mehrere Server und dessen eigenen Speicher auslagert. Dabei existieren verschiedene Ansätze, die in unterschiedlichen Anwendungen zum Einsatz kommen, diese werden in diesem Kapitel beschrieben. Tests Im Kapitel Tests werden einzelne Testszenarien vorgestellt, die bei dieser Untersuchung zum Einsatz gekommen sind. Dabei untersuchen diese unterschiedliche Eigenschaften des Filesystems, von der Lese- und Schreibgeschwindigkeit, bis hin zu einem Lasttest des Systems. 413 1 Einleitung Testauswertung Die vorgestellten Testszenarien werden nicht nur theoretisch ausgearbeitet, sie werden auch auf einem vom Universitätsrechenzentrum zur Verfügung gestellten Serververbund nachgestellt und auf Performance, Skalierbarkeit, Stabilität und Verwaltbarkeit miteinander verglichen. Dabei sollte sich herauskristallisieren, welche Lösung sich für welche Einsatzgebiete am besten eignet. Fazit Die durchgeführten Tests, sowie dessen Auswertungen hinsichtlich verschiedener Aspekte führt dazu, dass das Universitätsrechenzentrum eine konkrete Übersicht erhält, welche Distributed-Filesystems-Arten sich aktuell auf dem Markt befinden, wie diese aufgebaut sind und welches für das Aufgabengebiet des neuen Compute-Clusters am besten geeignet ist. Im Fazit wird daher eine Empfehlung gegeben, welches System auf dem neuen Cluster eingesetzt werden sollte. 514 Compute-Cluster Kapitel 2 Ein Compute-Cluster ist in der Informationstechnologie ein Verbund aus Servern, die miteinander meist durch spezielle Hardware vernetzt sind und untereinander kommunizieren können, dabei erscheint dieser Zusammenschluss als eine zentrale Einheit nach außen. Der Begriff Cluster steht dabei für Rechner-Schwarm oder Rechner-Haufen. Cluster und Constellations sind Gruppen von Rechnern in einem High-Performance-Netzwerk, welches besonders für parallele Berechnungen optimiert wurde. Dabei existieren insbesondere im grundlegenden Aufbau, in der Netztopologie und in der Art des Speicherns der verwendeten Daten große Unterschiede, die dazu führen, dass der eine oder andere Punkt zu Begrenzungen der Performance führt und die Leistung des Clusters beeinträchtigt. Abbildung 2.1: Juqueen Cluster in Jülich  615 2 Compute-Cluster Compute-Cluster müssen spezielle Eigenschaften erfüllen, die für jeden Anwendungsfall unterschiedlich sein können, daher wurde mit der Zeit eine Typisierung entwickelt, die für jeden Einsatzzweck unterschiedlich aufgebaut ist. Grundlegende Eigenschaften bleiben allerdings bestehen, wenn diese auch für jede Art verschiedene Gewichtungen beinhalten. Grundlage für den Aufbau und dem Betrieb eines Compute Clusters ist das 1967 entwickelte Amdahls-Gesetz, was besagt, dass [...] sich der nicht parallelisierbare Anteil eines Programms auf die Gesamtrechenzeit auswirkt [...] . Das heißt, dass ein sequentieller Anteil eines Programms immer die Gesamtzeit des Rechnens so beeinflusst, dass diese immer höher ist, als bei rein parallelen Programmen. Dieses Gesetz wird heutzutage als Basis für Multiprozessor- und Cluster-Computer angesehen. T(p) = T (1) 1 α p + T (1) α S(p) = p (1 α) + p α Quelle:  In der angegeben Formel ist T (1), die Zeit, die ein Prozessor für ein sequentielles Programm benötigt, α der sequentielle Anteil des Programms, sowie p die Anzahl der verfügbaren Prozessoren. Somit ergibt sich T (p) als Zeit, die ein Programm benötigt, wenn diesem p Prozessoren zur Verfügung stehen. Der mögliche Speedup S(p) zeigt dabei auf, wie effizient die Parallelisierbarkeit arbeiten kann. Es ist zu erkennen, dass die Geschwindigkeit immer vom sequentiellen Anteil eines Programmes abhängig ist. Ein Compute-Cluster ist ein Zusammenschluss mehrerer einzelner Server, die durch einen Hauptknoten miteinander verbunden sind und somit die Möglichkeit besteht, einzelne Teilaufgaben eines Programms auf verschiedene Teilknoten auszugliedern, um einen parallelen Ablauf zu erhalten. 716 2 Compute-Cluster In der heutigen Zeit werden Compute-Cluster für die Bereitstellung von Daten in der Cloud verwendet, da diese mit sehr vielen Anfragen umgehen können und diese auf verschiedene Hosts aufteilbar ist. Außerdem ist die Nutzung von Compute-Clustern in High-Performance-Netzwerken elementar, da durch Parallelisierung die Performance durch mehrere vorhandene Serverknoten stark ansteigen kann. 817 2 Compute-Cluster 2.1 Aufbau eines Compute-Clusters Um den Aufbau eines Computer-Clusters zu beschreiben ist die Unterteilung in verschiedene Arten von großer Bedeutung, da sich diese in ihren Grundeigenschaften unterscheiden können. Es besteht die Möglichkeit, einen Hochverfügbarkeitscluster aufzubauen, Load-Balancing-Cluster und High-Performance-Computing-Cluster haben eine andere Arbeitsweise. Allerdings können heutzutage Mischformen auftreten, sodass die Übergänge zwischen den einzelnen Arten fließend ist. So ist es möglich, einen Hochverfügbarkeitscluster aufzubauen, der aber trotzdem eine sehr hohe Performance aufweisen kann Hochverfügbarkeitscluster Unter einem Hochverfügbarkeitscluster versteht man einen Serververbund, der eine sehr hohe Ausfallsicherheit bietet. Dies wird dadurch erreicht, dass zum einen besondere Hardware genutzt wird, die nicht nur auf Performance optimiert wurde, sondern auch auf Langlebigkeit. Des Weiteren gewährleistet man diesen Aspekt durch redundante Hardware, die entweder im gleichen Serverrack eingebaut wird und bei einem Ausfall eines Systems aktiviert werden und die Arbeit übernimmt oder es wird oftmals der gleiche Aufbau eines Hochverfügbarkeitsclusters in getrennten Räumen oder Häusern untergebracht. Dies hat den Vorteil, dass bei einem Ausfall des gesamten Servers die Daten automatisch auf den Sicherheitsserver übertragen werden und somit weitergearbeitet werden kann und anschließend der Server-Administrator die Fehlerquelle ausmachen und beheben kann, ohne das es zu Einschränkungen in der Betriebszeit kommt. 918 2 Compute-Cluster Abbildung 2.2: Hochverfügbarkeit durch Redundante Hardware  Hochverfügbarkeitscluster haben durch den Aufbau einen Nachteil: Es muss Hardware angeschafft werden, die lediglich im Notfall aktiviert wird und keine zusätzliche Rechenleistung zur Verfügung stellt. Jedoch bei besonders wichtigen Bereichen, die auf eine Hochverfügbarkeit angewiesen sind, ist dieser Umstand unumgänglich, da es sonst zu hohen Ausfallkosten für den Betreiber kommen kann. Eingesetzt werden solche Arten von Compute-Cluster in Bereichen bei Datenbanksystemen oder Cloud-Computing-Systeme, die eine möglichst hohe Verfügbarkeit aufweisen müssen, sodass die gespeicherten Daten, bzw. die Rechenzeit jederzeit zur Verfügung gestellt werden kann. 1019 2 Compute-Cluster Load-Balancing-Cluster Load-Balancing-Cluster dienen der Lastverteilung innerhalb eines komplexen Netzwerkes. Dies ist in Umgebungen nötig, wo viele Recheneinheiten zur Verfügung stehen und die benötigte Rechenleistung sehr hoch ist. Die Verteilung der einzelnen Lasten auf die einzelnen Server erhöht die Effizienz der gesamten Hardware, weil dadurch gewährleistet werden kann, wenn bestimmte Aufgaben nicht gut parallelisierbar sind, dass diese verteilt abgearbeitet werden können. Ein Beispiel dafür wäre ein Verbund aus vielen Servern, die als Suchmaschine im Internet eingesetzt werden. Durch die vielen verschiedenen Anfragen, die nichts miteinander gemein haben, muss eine Lastverteilung stattfinden, da sonst einzelne Server bei besonders vielen Anfragen schnell an die Leistungsgrenze gebracht werden können. Das Load-Balancing vermindert die Rechenzeit und erhöht die Performance des gesamten Systems. Bei besonders vielen gleichzeitigen Anfragen und Aufgaben ist eine Lastverteilung für eine möglichst performante Leistung unumgänglich. In der heutigen Zeit können solche Load-Balancing-Cluster auch die theoretische Geschwindigkeit jedes einzelnen angebundenen Servers abspeichern und können somit die Last besser verteilen, da komplexe Aufgaben auf schnelleren Prozessoren ausgeführt werden, kleinere Anwendungen auf, wenn vorhanden, langsamere. 1120 2 Compute-Cluster Abbildung 2.3: Beispiel von Load-Balancing durch Cluster  Eingesetzt werden solche Cluster im Bereich Web- und Application-Services, da man dort mit einer hohen Anzahl von Anfragen rechnen muss, die alle in möglichst geringer Zeit bearbeitet werden sollen. Daher ist eine Lastverteilung auf mehrere Server nötig, da die Performance eines einzelnen oftmals nicht ausreicht und dieser zusammenbrechen könnte. 1221 2 Compute-Cluster High-Performance-Computing-Cluster Diese Art von Compute-Clustern ist auf eine möglichst hohe Performance getrimmt. Genutzt werden diese hauptsächlich bei der Berechnung von wissenschaftlichen Problemen, sowie beim Rendern von 3D-Anwendungen und -animationen. Die Berechnungen werden auf mehrere Hosts aufgeteilt, um einen parallelen Ablauf zu erhalten. Dabei unterscheidet man, ob diese Verteilung global für alle Hosts gleichzeitig durchgeführt wird oder ob jeder sein eigenes spezielles Paket erhält, mit dem dieser rechnen soll. Dabei werden alle verfügbaren Recheneinheiten für die Berechnungen genutzt, damit das Problem in möglichst kurzer Zeit gelöst werden kann. Abbildung 2.4: Beispiel von High-Performance-Cluster  Eingesetzt werden solche Cluster-Systeme hauptsächlich bei komplexen Berechnungen in naturwissenschaftlichen Bereichen, weil diese die höchstmögliche Rechenkapazität benötigen und weniger als Storage dienen. Auch viele Suchmaschinen nutzen solche High-Performance-Cluster in deren Rechenzentren, um viele Anfragen in möglichst geringer Zeit ausführen zu können. 1322 2 Compute-Cluster Gerade in solchen Anwendungsgebieten entstehen auch Mischformen, besonders zwischen Load-Balancing-Cluster und High-Performance-Cluster. Eine Kombination mit einem Hochverfügbarkeitscluster ist hierbei möglich, widerspricht allerdings dem Konzept des High-Performance-Computing-Clusters. Daher entstehen immer mehr Mischformen, sodass eine genaue Abgrenzung immer schwieriger ist, die Grundgedanken bleiben aber immer erhalten. 1423 2 Compute-Cluster 2.2 Eigenschaften Ein Compute-Cluster hat je nach Anwendungsfall verschiedene wichtige Eigenschaften, die erfüllt sein müssen, damit man davon ausgehen kann, dass das gesamte System korrekt funktioniert. Allerdings müssen einige grundlegende Voraussetzungen immer gegeben sein Fail-Over Fail-Over bedeutet in der IT-Industrie das automatische Umschalten der Arbeitsprozesse eines Servers auf einen anderen im Falle eines Fehlers oder Defekts oder des gesamten Abschaltens eines Clusters und der Übernahme der Aktivitäten eines Backup-Clusters. Dies soll den Zweck haben, dass die Ausfallzeiten innerhalb der Arbeitszeiten minimiert werden und ein Administrator die Möglichkeit besitzt, diese Fehler zu beheben. Abbildung 2.5: Fail-Over-Cluster  1524 2 Compute-Cluster Ein solcher Fail-Over-Cluster besteht aus mindestens einem Haupt- und einem Backup-Cluster, der im Falle eines Fehlers ohne administratives Eingreifen die Aufgaben übernimmt. Dazu muss die Hardware physikalisch miteinander verbunden sein und es muss die Möglichkeit bestehen, dass die beiden Recheneinheiten auf einen gemeinsamen Speicherbereich zugreifen können, damit eine Übergabe der laufenden Prozesse möglich ist. Für solche Übertragungen werden von verschiedenen Herstellern unterschiedliche Lösungen angeboten, die dieses übernimmt. Diese Eigenschaft ist besonders bei Hochverfügbarkeitsclustern wichtig, da die Ausfallzeiten eines gesamten Clusters minimiert werden. Dieser ist zwar heruntergefahren, aber die Benutzer können durch das automatische Einschalten des Backup-Servers weiter arbeiten. Meist geschieht dies in sehr kurzer Zeit, sodass es zu keinem Arbeitsausfall kommt. Hinzu kommt, dass dies die Verfügbarkeit bzw. Hochverfügbarkeit des Systems erheblich verbessert. 1625 2 Compute-Cluster Hochverfügbarkeit Die Verfügbarkeit eines Systems ist in der heutigen Zeit wichtiger denn je geworden. Ein möglicher Serverausfall kann großen Unternehmen sehr viel Geld kosten und führt häufig dazu, dass Mitarbeiter völlig arbeitsunfähig sind. Daher existieren verschiedene Kenngrößen, die bei der Berechnung der Verfügbarkeit von Servern, bzw. Clustern genutzt werden. Wichtig ist diese Eigenschaft besonders bei, wie der Name vermuten lässt, Hochverfügbarkeitsclustern. Ein System gilt als hochverfügbar, wenn eine Anwendung auch im Fehlerfall weiterhin verfügbar ist und ohne unmittelbaren menschlichen Eingriff weiter genutzt werden kann.  Die Kenngröße Verfügbarkeit lässt sich berechnen durch: Verfügbarkeit = Uptime Downtime + Uptime Aus dieser Formel ist zu erkennen, dass die Verfügbarkeit besser wird, je kleiner die Downtime ist, das ist die Zeit, wo das System nicht zur Verfügung steht. Bei dieser Formel müssen auch geplante Wartungsarbeiten und ungeplante Abstürze mit einberechnet werden, die durch den Ausfall von einzelnen Komponenten zu Stande kommen kann oder durch das Ersetzen ganzer Hardwareeinheiten. Um Fehler im System und die daraus resultierende Nichtverfügbarkeit zu minimieren, muss es die Möglichkeit besitzen, diese so früh wie möglich erkennen zu können. Das kann durch so genanntes Proaktives Monitoring  geschehen, welches meist durch die Hardware-Hersteller bereits integriert ist. Ein Beispiel bei Festplatten sind die S.M.A.R.T.-Werte, die bereits vor einem eigentlichen Defekt den Administrator warnen können, das es zu Problemen mit der Hardware kommen wird. Neben der ständigen Überwachung der Hardware ist es aber nicht auszuschließen, dass diese auch abrupt einen Defekt aufweist, zum Beispiel durch eine Überspannung im System. Solche sogenannte Single Point of Failure (kurz: SPOF) können durch intelligente Hard- und Software im Server selbst und auch in der Netzwerkarchitektur bereits mit eingeplant werden. Insbesondere bei Netzwerken ist dies sehr wichtig, denn diese verbinden alle Server eines Rechenzentrums miteinander. Fällt ein Server aus, der 1726 2 Compute-Cluster möglicherweise durch einen Backup-Server gesichert ist, kann dieser SPOF bereits eliminiert werden, allerdings ist es häufig so, dass beide Server über den gleichen Netzwerkswitch an das gesamte Netzwerk angebunden sind. Fällt dieser Switch aus, ist keine Kommunikation mehr möglich und somit kommt es zu einem Systemausfall. Daher muss man auch bei der Entwicklung der Netztopologien solche Eventualitäten zu beachten, um ein möglichst hochverfügbares System zu erhalten. Durch den Einsatz eines Fail-Over-Clusters wird die Downtime stark verringert und dementsprechend die Verfügbarkeit verbessert, denn der Administrator hat nun die Möglichkeit die defekte Hardware auszutauschen und den primären Server wieder zu starten. Dies kann einige Zeit in Anspruch nehmen, insbesondere wenn für die defekte Hardware kein Ersatz direkt vorhanden ist und bestellt werden muss. Um ein solches Umschalten ohne Datenverlust zu gewährleisten, müssen die Cluster gleichzeitig auf einen gemeinsamen Speicher zugreifen können. Dies wird in der heutigen Zeit über ein zentrales Storage gelöst, wo alle wichtigen Komponenten, auf die ein Cluster Zugriff haben muss, zentral abgelegt werden. Bei einem Ausfall des Hauptclusters kann nun der Backup-Server automatisch die Arbeit fortsetzen, die unterbrochen wurde. Die Downtime ist daher sehr gering, da diese nur die Startzeit des Backup-Servers beträgt. Besonders bei großen Serverfarmen und in Rechenzentren wird die Verfügbarkeit in verschiedene Klassen unterteilt. Diese unterteilen sich zwischen maximal 3,7 Tagen und 3 Sekunden Downtime im Jahr. Abbildung 2.6: Verfügbarkeitsklassen  1827 2 Compute-Cluster Die Übersicht in Abbildung 2.6 zeigt deutlich, dass die Einteilung sich prozentual lediglich in den Nachkommastellen ändert, die Downtime aber rapide sinkt. Wenn ein Unternehmen auf eine absolute Hochverfügbarkeit angewiesen ist, zum Beispiel im Falle eines Call-Centers, die 24 Stunden täglich und 365 Tage im Jahr erreichbar sein müssen, muss eine absolut geringe Downtime durch hochverfügbare Server- und Netzwerk-Hardware zur Verfügung stehen. Da in der Downtime auch geplante Wartungsarbeiten mit einberechnet werden, können andere Unternehmen, die geregelte Arbeitszeiten aufweisen, auf eine geringere Verfügbarkeit zurückgreifen, da die Wartungsarbeiten außerhalb der Öffnungszeiten durchgeführt werden können. Bei dieser Überlegung ist es aber nicht absolut gewährleistet, dass es während der Arbeitszeit durch ungeplante Ausfallzeiten zu Einschränkungen kommen kann. 1928 2 Compute-Cluster Skalierbarkeit Skalierbarkeit ist die Fähigkeit, Ressourcen so zu erweitern, dass (im Idealfall) die Dienstkapazitäten linear zunehmen. Das wesentliche Merkmal einer skalierbaren Anwendung ist, dass bei steigender Auslastung lediglich zusätzliche Ressourcen und keine umfangreichen Veränderungen der Anwendung selbst erforderlich sind.  Abbildung 2.7: optimale Skalierbarkeit  Im Optimalfall soll die Skalierbarkeit dazu führen, dass durch das Hinzufügen von Hardware in einen Verbund eine lineare Verbesserung der Performance eintreten soll. Dies ist hauptsächlich für High-Performance-Cluster von großer Bedeutung, da diese jede Recheneinheit dazu benötigen, die Arbeitsgeschwindigkeit zu erhöhen. Um eine solche möglichst lineare Skalierung zu erreichen muss der ausgeführte Quellcode auch auf die Anzahl der verfügbaren Recheneinheiten ausführbar sein. Man erhält keinen zusätzlichen Geschwindigkeitsvorteil, wenn man ein Programm auf einem großen Cluster ausführt, welches mit maximal 4 CPU-Kernen umgehen kann. Die Parallelisierbarkeit muss softwareseitig gegeben sein. Ebenso hat das Filesystem des Clusters einen entscheidenen Einfluss auf die Skalierbarkeit. Wenn die Begrenzung des Filesystems erreicht ist und keine weiteren Server mehr angesprochen werden können, dann endet auch die Skalierbarkeit. Solche Punkte müssen im Vorfeld einer Anschaffung unbedingt beachtet werden. 2029 2 Compute-Cluster Verwaltbarkeit Das Thema Verwaltbarkeit ist von sehr großer Bedeutung im Bereich Cluster-Computing, da ein Administrator gleichzeitig die Verwaltung über verschiedene einzelne Server, die in einem Verbund von außerhalb erreichbar sind, übernehmen muss, aber auch die vorhandene Netzwerktopologie innerhalb des Clusters und die Anbindung ins übrige Netzwerk überwachen muss. Zusätzlich kann ein externes Storage zur Verfügung stehen, insbesondere bei Hochverfügbarkeitsclustern. Dies sind viele Punkte, die gleichzeitig beachtet werden müssen, daher ist eine gute Verwaltbarkeit von großer Bedeutung. Hersteller von großen Compute-Clustern und Serverfarmen besitzen eine eigene Verwaltungssoftware für ihre eigenen Geräte, allerdings sind diese grundlegend unterschiedlich, sodass jeder Administrator für jeden Hersteller eine eigene Schulung benötigt. Durch die komplexen Verwaltungsmöglichkeiten, die insbesondere sehr große Firmen anbieten, hat man allerdings die Möglichkeit, schnell einen Überblick über alle möglichen Ressourcen zu bekommen. Solche Management-Tools überwachen die gesamte Hardware innerhalb des Clusters und meldet sofort, wenn es zu Fehlern kommt. 2130 2.3 Cluster-Filesystems 2 Compute-Cluster Compute-Cluster sind ein Verbund aus mehreren einzelnen Servern, die von außerhalb als ein einziger Server angesprochen werden können. Dabei ist die Unterscheidung wichtig, ob es sich hierbei um einen Cluster mit externem Storage handelt, oder ob jeder einzelne Server einen bestimmten Teil an Festplattenkapazitäten zur gemeinsamen Benutzung anbietet. Bei einem externen Storage ist die wichtige Frage, ob es sich innerhalb des abgeschlossenen Systems um ein Filesystem handelt, welches mit möglichst großen Datenmengen, zum Beispiel die Anzahl von Dateien oder die Dateigröße, performant umgehen kann oder ob sich dieses mehr auf Sicherheit stützt. Die bestehende Hardware-Konfiguration spielt dabei eine sehr große Rolle. Zum Beispiel können durch einen Hardware-RAID-Controller ( Redundant Array of Independent Disks ) bestimmte Konfigurationen aufgebaut werden, die die einzelnen Festplatten als bestimmte Einheit zusammenfasst, um so die Performance und/oder die Sicherheit zu erhöhen. Es besteht sowohl die Lösung, dass jeder Server innerhalb eines Clusters seine eigene Festplattenkapazität bereitstellt, als auch Storage-Lösungen, dass dort verschiedene Dateisteme für jedes Betriebssystem installiert werden können und mit Hilfe von Netzprotokollen darauf zugegriffen werden kann. Dies vereinfacht die Installation der Dateisysteme, denn häufig wird für UNIX-Umgebungen XFS oder EXT2/3/4 genutzt, für Microsoft Windows Serverumgebungen NTFS-Dateisysteme. Es existieren weitere, weniger bekannte, wie zum Beispiel BTRFS, die einen interessanten Ansatz mit sich bringen, allerdings sich noch im Entwicklungsstadium befinden und daher insbesondere für hochverfügbare Systeme noch relativ uninteressant sind, da diese sichere und stabile Formate einsetzen müssen, da ein möglicher Datenverlust enorme Kosten entwickeln kann. Eine weitere Möglichkeit ist das Zusammenfassen einzelner Festplatten innerhalb der verschiedenen Server durch den Einsatz von verteilten Dateisystemen, Distributed Filesystems. Diese haben die Aufgabe, dass durch einen Master-Server die Daten automatisch auf verschiedene Festplatten verteilt werden. 2231 2 Compute-Cluster Diese beinhalten häufig dann keine vollständigen Dateien mehr, sondern die Datei wird in einzelne Objekte zerlegt und diese werden verteilt gespeichert. Das hat den Vorteil, dass die Daten von unterschiedlichen Servern zur gleichen Zeit angefragt werden können und so theoretisch die Performance ansteigen sollte. Dafür gibt es in der heutigen Zeit verschiedene Ansätze, die unterschiedliche Herangehensweisen an dieses Problem aufweisen. Jedes Dateisystem unterscheidet sich hinsichtlich der Performance, Sicherheit und Skalierbarkeit gegenüber der Konkurrenz. 2332 Dateisysteme Kapitel 3 Klassische Dateisysteme beschreiben die allgemeine Verwaltung der Abspeicherung von Daten auf physikalischen Datenträgern und dienen als direkte Schnittstelle zwischen dem Betriebssystem und den einzelnen Partitionen auf Festplatten und anderen Speichermedien. Dafür definiert jedes Dateisystem einen festgelegten Raum, wo die Daten eindeutig beschrieben werden. Dem Nutzer wird anschließend die Datei und das Verzeichnis zur Verfügung gestellt, man kann unter normalen Umständen die logische Speicherung auf dem Datenträger nicht erkennen. Die grundlegenden Aufgaben eines Filesystems sind das Anlegen von Verzeichnissen und Dateien, die Speicherung von Datumsinformationen, die Rechteverwaltung, sowie die Verwaltung von langen Dateinamen und deren besonderer Aufbau. Abhängig vom Filesystem können im Dateinamen Sonderzeichen und Umlaute vorhanden sein. Um einen optischen Performancegewinn aufzuzeigen und die Fehlertoleranz zu minimieren, existieren mittlerweile viele Dateisysteme, die das Journaling unterstützen. Journaling bedeutet, dass Änderungen an Daten und Verzeichnissen nicht direkt auf dem Datenträger geschrieben werden, sondern diese in einer externen Tabelle zwischengespeichert werden. Das führt zu einer hohen Geschwindigkeit beim Schreiben, da dies erst dann durchgeführt wird, wenn die Auslastung des Datenträgers nicht so hoch ist. Zum anderen können kurzfristige Änderungen durchgeführt werden, ohne die eigentliche Datei bearbeiten zu müssen. Ein vollständiges Rückholen einer Datei ist bis zu dem Zeitpunkt, bis die Änderungen geschrieben werden, auch möglich. Eingesetzt wird dieses Verfahren bereits im NTFS-Filesystem für Windows, Apple verwendet dieses im HFS Plus Dateisystem für Mac OS und Linux bietet diese Möglichkeit für EXT3/4 an, sowie für XFS, BTRFS und ReiserFS. 2433 3 Dateisysteme 3.1 XFS XFS wurde im Oktober 1993 von der Firma SGI (Silicon Graphics, Inc.) der Öffentlichkeit vorgestellt. Als Weiterentwicklung des nur intern genutzten Dateisystems EFS gilt es heutzutage als eines der häufigsten verwendeten Dateisysteme, insbesondere für Systeme mit einer großen Anzahl von CPU s, CPU-Kernen und Festplatten. Bereits im Linux Kernel 2.4 wurde XFS offiziell eingeführt. Der Hersteller verspricht sehr hohe Transaktionsgeschwindigkeiten, das bedeutet eine sehr hohe Input-Output-Rate, sehr schnelle Wiederherstellungsmechanismen, effizientes Allokieren von Speicher, eine perfekte Anbindung der Netzwerkhardware, sowie massive Skalierbarkeit Aufbau von XFS XFS ist ein reines 64-bit Dateisystem, welches in der Lage ist, mit 2 63 = 9 Exabyte Daten umzugehen. Insbesondere für Storage-Hoster ist dies ein Wert, welcher auch in der heutigen Zeit zu betrachten ist. Dazu ist XFS in der Lage, beim Verbund aus mehreren Systemen skalierbar zu arbeiten. Das Dateisystem beinhaltet einige wesentliche Eigenschaften, die die Unterschiede zu anderen Systemen verdeutlichen. Die Eigenschaft GRIO ( Guaranteed IO Bandwith ) ist dabei herauszustellen. Diese garantierte Mindestgeschwindigkeit ist besonders bei Streaming-Servern wichtig, da diese einen konstanten Datenstrom anbieten müssen. Eine weitere Eigenschaft nennt man Disk Quota. Dieses Feature besagt, dass für spezielle Benutzer des Systems Begrenzungen des Speicherplatzes eingeführt werden können. Das Filesystem bietet spezielle Technologien zur effizienten Speicherbehandlung an, welches die Performance beim Reservieren und Freigeben von Speicher wesentlich erhöht. Möglich macht dies eine besondere Unterteilung der Zuweisung von Daten. Das Dateisystem ist dabei unterteilt in gleich große Allocation Groups, welche zwischen 16MB und 1TB groß sein können. Da diese Gruppen sehr groß werden können, ist besonders die Performance bei großen Dateien sehr gut, da diese keinen großen Overhead erzeugen, da nur sehr wenige einzelne Allocation Groups ausgewertet werden müssen. 2534 3 Dateisysteme Abbildung 3.1: Aufbau des XFS-Filesystems  Aufbau der Metadaten Jede Gruppe ist unterteilt in einen Metadata- und Filesystemabschnitt. Der Metadatenabschnitt ist in unterschiedliche Blöcke eingeteilt, die zum einen zum optimalen Ausnutzen des vorhandenen Speichers genutzt werden, zum anderen auch den B+-Tree beinhaltet, sowie die Inode-Liste. Ein B+-Tree ist eine Indexstruktur, welche die eigentlichen Datenelemente leidiglich in den Endknoten (Blattknoten) speichert und die inneren Knoten nur die Schlüssel beinhaltet. Das hat den Vorteil, dass ein schneller und paralleler Zugriff auf den Baum möglich gemacht wird. Während andere Filesystems die Inodes, die die Metadaten der gespeicherten Dateien enthält, fest verankert, bietet XFS die Möglichkeit, diese dynamisch zur Laufzeit zu erzeugen und anzulegen. Das nennt man dynamische Inode Allkoation. Auch ist eine Begrenzung nicht gegeben, es ist also möglich, eine sehr hohe Anzahl von Dateien in einer einzigen Allocation Group abzulegen. 2635 3 Dateisysteme Fehlerbehandlung Insbesondere nach unerwarteten aufgetretenen Fehlern ist es elementar wichtig, dass aktuelle Dateisysteme in der Lage sind, diese Fehler zu korrigieren, ohne das die Anzahl von Dateien, die verwaltet werden, dabei entscheidend sind. Dieses Feature ist elementarer Bestandteil von XFS, welches unabhängig der Größe und der Auslastung des Filesystems eine vollständige Recovery-Funktion direkt mit sich bringt. Abbildung 3.2: Performance von XFS beim Löschen von vielen Dateien  2736 3 Dateisysteme Aktuelle Entwicklungen XFS wird heutzutage von der Firma SGI gepflegt, was die regelmäßigen Updates auf Linux-Systemen zeigen. Auch darum ist dieses Filesystem eine interessante Alternative, sowohl für Rechnersysteme mit einer sehr hohen Anzahl von CPUs und sehr viel Speicher, als auch für den privaten Anwender, da die Möglichkeit zur Rekonstruktion bei fehlgeschlagenden Transaktionen immer eine sehr gute Möglichkeit der Datenwiederherstellung bietet. Insbesondere seit dem Jahr 2010, wo die grundlegende Struktur an die heutigen Bedürfnisse angepasst wurden, ist XFS wieder ein Filesystem, welches in den Punkten Input-Output-Performance, Sicherheit und Stabilität im Vergleich mit dem Standard-Filesystem ext4 viel Zuspruch findet, insbesondere wenn es um die Behandlung von sehr großen Dateien geht. 2837 3 Dateisysteme 3.2 ext4 Das Extended File System ext wurde ursprünglich in seiner ersten Version 1992 von Remy Card veröffentlicht. Während dieses Format bereits zur damaligen Zeit eine Datengröße von 2GB verwalten konnte, wurde 1993 der Nachfolger ext2 veröffentlicht, welcher zunächst 2TB, ab dem Linux 2.6 Kernel 32TB verwalten konnte wurde das Journaling zu dem Filesystem hinzugefügt und ext3 genannt. Journaling bedeutet, dass Änderungen am Filesystem vor dem endgültigen Schreiben auf den Datenträger zunächst in einem festgelegten Speicherbereich geschrieben wird, um zu erreichen, dass ungewollte Transaktionen wieder rückgängig gemacht werden können. Das hat zunächst einen großen Vorteil, allerdings leidet die Gesamtperformance des Systems darunter, da die Limitierung des festgelegten Journaling-Bereiches ausschlaggebend für die Geschwindigkeit ist. Im Dezember 2008 wurde die aktuelle Version des Extended File Systems ext4 vorgestellt, welche, wie im Vergleich von ext2 zu ext3, keine Erweiterung, sondern eine völlige Neuentwicklung darstellt. Insbesondere in den Punkten Performance, Skalierbarkeit und Sicherheit wurden viele Verbesserungen angebracht, dass das System auf den aktuellen Stand der Zeit bringt und damit auch in der heutigen Zeit zum aktuell am häufigsten verwendeten Filesystem auf Linux-basierten Computern ist Vorteile von ext4 Zu den Vorteilen von ext4 gehört, dass es eine vollständige Funktionskompatibilität zu ext3 beinhaltet, dass bedeutet zum einen, dass Systeme, welche noch auf dem alten Standard formatiert sind, diese in ext4 umgewandelt werden können, ohne dass Datenverlust zu beklagen ist. Insbesondere bei sehr sensiblen Daten ist ein solcher Umstieg meist nicht ohne eine gründliche Datensicherung im Vornherein möglich, ext4 bietet diese Funktion bereits an, ohne am Betriebssystem selbst Änderungen vornehmen zu müssen. Die Größe des Filesystems und die Größe der zu speichernden Daten hat sich ebenfalls deutlich erhöht. Während ext3 nur mit maximal 16TB Speicherplatz und maximal 2TB große Dateien umgehen konnte, ist es jetzt möglich 1EB (1 Etabyte = 1024PB, 1 Petabyte = 1024TB) zu adressieren, wobei einzelne Dateien bis zu 16TB groß sein 2938 3 Dateisysteme können. Möglich macht dies, dass ext4 48bit große Blöcke adressiert, die Gegenwart zeigt, dass eine 64bit Umsetzung folgen muss, um mit anderen Filesystemen insbesondere in großen Rechnerverbunden, die sehr große Daten speichern, mithalten zu können. Positiv ist auch, dass die Grenze der möglichen Unterordner aufgehoben wurde, diese lag bei ext3 noch bei Aufbau ext4 Das Dateisystem ext4 ist nicht wie XFS in der Lage 64-bit-Blöcke zu adressieren, es verwaltet 48bit große Adressbereiche. Dies stellt in der Realität kaum ein Problem dar, da die maximale Dateisystemgröße 1 Exabyte beträgt, ohne Einschränkungen in der Anzahl der Unterordner zu besitzen. Die Dateilänge ist allerdings auf 255 Zeichen begrenzt. Um eine hohe Arbeitsgeschwindigkeit zu erreichen wurde das Adressieren und Verwalten von Speicherblöcken im Vergleich zu den Vorgängern grundlegend verändert. Während ältere Dateisysteme für jeden festgelegten Block Daten in einem Schema abspeichern ( indirect block mapping scheme ) existieren in ext4 Ausdrücke, die in einem Befehl einen gesamten Speicherbereich für eine Datei darstellen. Die Größe dieser Extents ist dabei variabel, bei sehr großen Dateien ist es möglich, dass diese in mehreren Extents gespeichert werden. Ein weiterer Unterschied zu ext3 ist das Multiblock Allocation - Feature. Ext3 fragte für jeden Block, der geschrieben werden sollte den Block Allocator an. Dies konnte auch schon bei kleinen Dateien zu großen Problemen führen, bei einer 100MB großen Datei und einer Blockgröße von 4KB wurde die Anfrage mal durchgeführt. 3039 3 Dateisysteme Abbildung 3.3: Extents im ext4 Dateisystem  Ext4 reduziert die Anfragen auf eine einzige, indem sofort der gesamte Bereich abgefragt wird. Dies hat zusätzlich den Vorteil, dass das Filesystem die Daten besser verteilen kann, da bereits beim ersten Kontakt die gesamte Größe der zu speichernden Datei übertragen wird. Dies führt zu einer besseren Auslastung und einer höheren Performance und Effizienz des Filesystems. Für eine direkte Zuordnungsmöglichkeit von Metadaten zu den gespeicherten Daten in den Blöcken arbeitet ext4 genau wie XFS mit sogenannten Inode-Blöcken Verbreitung von ext4 Sowohl XFS als auch ext4 haben eine große Entwicklungszeit überstanden und sind heutzutage die am häufigsten eingesetzten Dateisysteme. Bei Linux-Distributionen für den Endanwender, wie zum Beispiel Ubuntu, Debian, opensuse oder auch CentOS ist dies das Standarddateisystem, bei der automatischen Installation. Dies zeigt, dass das System ausgereift und eine Performance aufzeigt, welche für den Endanwender keine Änderungen nötig macht. Auch die Stabilität ist gegeben. Eine vollständig andere Herangehensweise zeigt BTRFS, welches sich zwar noch in Entwicklung befindet, aber bereits jetzt stabil und in vielen Fällen schneller als alle Kontrahenten ist. 3140 3 Dateisysteme 3.3 BTRFS Das neuartige Filesystem BTRFS wurde als Next Generation Linux  vorgestellt, welches insbesondere die Probleme und Einschränkungen der standardisierten Systeme ausmerzen soll. Im Jahr 2007 stellte Oracle das Produkt offiziell vor, im Linux-Kernel wurde es offiziell aufgenommen und steht für jeden Nutzer zur Verfügung. Bis zum aktuellen Stand der Zeit ist BTRFS allerdings noch nicht als stabil gekennzeichnet worden, das bedeutet, dass es immernoch zu Fehlern beim längerfristigen Einsatz kommen kann und nicht als sicheres Filesystem anzuerkennen ist. Möglicher Datenverlust bei unvorhergesehenen Fehlern ist daher leider nicht ausgeschlossen Aufbau BTRFS Im Vergleich zu XFS und ext3/4 basiert BTRFS auf eine andere Art der Formatierung eines Datenträgers. Wie ZFS für Sun-Systeme basiert BTRFS auf das Copy-On-Write System. Copy-On-Write bedeutet, dass geänderte Daten in neue Adressbereiche geschrieben werden. Nach dem erfolgreichen Schreiben erfolgt anschließend die Aktualisierung des B-Trees, die Metadaten zeigen solange auf die alten Speicherbereiche. Durch diese Eigenschaft sind Snapshots möglich, die einen Teil des Baumes direkt in andere Bereiche auslagern kann und auch zu anderen Dateisystemen zusätzlich eingehangen werden können. BTRFS bietet besondere Eigenschaften, die in anderen Systemen nicht zur Verfügung stehen. Die Verschlüsselung auf Dateisystemebene erhöht die Sicherheit und dient der besseren Zugriffskontrolle der gespeicherten Daten, die Komprimierung unterstützt das Speichermanagement. Auch das Journaling wurde grundlegend verändert, BTRFS bietet eine vollständig neuartige Verwaltung der Daten- bzw. Metadaten. BTRFS ist ein Dateisystem, welches mit 64bit großen Adressräumen arbeitet. Das bedeutet, eine einzelne Datei kann bis zu 16EiB groß werden. Die Größe des Filesystems ist unbegrenzt. 3241 3 Dateisysteme Metadatenbehandlung in BTRFS BTRFS steht für B-Tree-Filesystem, das aufzeigt, dass die Metadaten und Datenblöcke in Baumstrukturen aufgezeichnet werden, die jeweils aufeinander zeigen. Ähnlich wie bei ext4 existieren auch hier Extents, die für große Dateien einen Speicherbereich festlegen können, ohne einen großen Overhead zu erzeugen. Die dynamischen Inode-Tabellen unterstützden dies. Durch das dynamische Abspeichern und der Möglichkeit von Copy-On-Write können einzelne Teilbäume einfach kopiert werden, somit können Snapshots erstellt werden, diese dynamisch zur Laufzeit eingebunden oder entfernt werden. Diese Teilbäume nennt man Subvolumes. Die Unterstützung von Software-RAID (Redundant Array of Independent Disks ) können mehrere Festplatten gleichzeitig angesprochen werden. BTRFS unterstützt dabei die Formate RAID-0 ( Striping ), RAID-1 ( Mirroring ) und RAID-10 ( Striping + Mirroring ). RAID-5 und RAID-6 sind in Planung der Entwickler. Somit können mehrere Subvolumes auf einem Datenträger angelegt und ineinander geschachtelt werden Sicherheit der Daten in BTRFS Das Dateisystem nutzt Checksummen, die sicherstellen, dass die Metadaten und Datenblöcke korrekt ins Filesystem übertragen wurden. Bei der Nutzung von redundanten Speichermöglichkeiten können eventuelle Fehler automatisch korrigiert werden, indem der korrekte Wert vom anderen Medium übertragen wird. Diese Möglichkeit wird häufig für das Anlegen von inkrementellen Backups genutzt, die bei einem Ausfall die Daten schnell wiederherstellen können. Um solche Fehler ausfindig zu machen, existieren verschiedene Ansätze. Zum einen werden die Daten automatisch abgeglichen, zum anderen ist eine offline filesystem check -Möglichkeit eingebaut, welche Fehler finden und korrigieren kann. Durch das Anlegen und Abspeichern dynamischer Baumeinträge ist ein Verändern der Größe des Dateisystems im laufenden Betrieb möglich, die Defragmentierung kann auch live erfolgen. 3342 3 Dateisysteme Rechtevergaben in BTRFS Ähnlich wie ext4 bietet BTRFS Zugriffsbeschränkte Rechtevergaben an. Dies geschrieht über Access Control Lists (ACLs) nach dem POSIX-Standard ( Portable Operating System Interface ). Die Möglichkeit der Verschlüsselung unterstützt die Rechtevergabe zusätzlich, da ausgewählt werden kann, welcher Benutzer in der Lage ist, die Daten korrekt zu entschlüsseln. Diese Möglichkeit, bereits im Dateisystem die Rechtevergaben durchführen zu können, erhöht zudem die Sicherheit des Systems Ausblick Durch die Möglichkeit parallelen Zugriff auf den Verzeichnisbaum zu gewähren und der verteilten Speicherung der Daten ist eine hohe Performance zu erwarten. BTRFS bietet zudem eine direkte Umwandlung von bestehenden ext3/4 Filesystemen an, in der Praxis funktioniert diese hervorragend im laufenden Betrieb. Zum aktuellen Zeitpunkt befindet sich BTRFS bereits im offiziellen Linux-Kernel, ist aber noch als experimentell gekennzeichnet. Die Entwicklung ist nicht abgeschlossen, es werden in regelmäßigen Abständen Updates zur Verfügung gestellt. Von vielen Expertens soll BTRFS das Dateisystem der Zukunft werden, weil die grundlegenden Ansätze bei der Entwicklung des Systems noch nicht vollständig implementiert wurden. Die Geschwindigkeit beim Lesen und Schreiben können bereits in dem frühen Entwicklungsstadium mit denen von XFS und ext4 mithalten, es ist sogar vom Hersteller versprochen, dass dieses noch schneller werden kann. Auch die Möglichkeit, direkte Snapshots von einem Verzeichnisbaum anzulegen und somit inkrementelle Sicherungen anzulegen, ist heutzutage einzigartig und ist noch in keinem anderen Dateisystem mit eingearbeitet worden. 3443 3 Dateisysteme 3.4 Zusammenfassung In der heutigen Zeit existieren sehr viele verschiedene Dateisysteme, die auf der ganzen Welt für verschiedene Einsatzzwecke genutzt werden. Die vorgestellten Systeme ext4 und XFS sind die am häufigsten verwendeten auf Linux-basierten-Betriebssystemen, weil sich diese bereits seit fast 20 Jahren in der Entwicklung befinden und die grundlegende Performance im Umgang mit unterschiedlichen Dateigrößen und -fragmentierungen anbieten. XFS ist ein Dateisystem, welches häufig auf NAS-Servern ( Network Attached Storage ) zum Einsatz kommt, weil dieses besonders bei großen Dateien sehr performant ist. Auch durch die Eigenschaft GRIO ( Guaranteed IO Bandwith ) wird XFS häufig für Streaming-Server verwendet, da eine grundlegende Geschwindigkeit trotz hoher Anzahl von Transaktionen garantiert werden kann. Das Dateisystem ext4 ist in der heutigen Zeit das Standardsystem bei Neuinstallationen von Linux-Distributionen. Die Verbreitung kommt durch den performanten Umgang mit kleinen Dateien zustande, die häufig bei Betriebssystemen selbst zum Vorschein kommen. Diese Eigenschaft führt zu einem optischen Performancegewinn beim Arbeiten mit einer Distribution. Die Geschwindigkeit liegt durchschnittlich mit XFS auf einem Niveau. BTRFS gilt in der Linux-Welt als mögliches Dateisystem der Zukunft. Die Entwicklung wird in den letzten Jahren auch durch diesen Hype zusätzlich vorangetrieben, da durch den neuartigen Aufbau des Systems sich auch die Entwicklung von verteilten Dateisystemen beeinflussen lässt. Allerdings ist es zum aktuellen Zeitpunkt nicht als stabil im Linux-Kernel gekennzeichnet worden, sodass von einem produktiven Arbeiten mit diesem System abzuraten ist. 3544 3 Dateisysteme Abbildung 3.4: Zusammenfassung Eigenschaften regulärer Dateisysteme Die vorliegende Tabelle in Abbildung 3.4 zeigt einen generellen Überblick der vorgestellten regulären Dateisysteme. Alle diese können mit sehr großen Datenmengen umgehen, sie unterscheiden sich hauptsächlich im Aufbau der Metadaten, sowie den einzelnen Eigenschaften. Während BTRFS eine Komprimierung und Verschlüsselung auf Dateisystemebene anbietet, fehlen diese Punkte vollständig bei ext4 und XFS. Mit diesen können hingegen Software-RAID-Systeme mit allen verfügbaren Modi eingerichtet werden, BTRFS unterstützt zum aktuellen Zeitpunkt lediglich die Modi RAID-0, RAID-1 und RAID-10. In den folgenden Tests dient ein reguläres Dateisystem jeweils als Untergrund. Dabei wurden alle Durchläufe mit dem ext4-dateisystem durchgeführt, weil dieses bei kleineren Dateien performanter arbeitet als XFS. Für das Universitätsrechenzentrum sind Dateigrößen bis maximal 2GByte von Interesse, häufig befinden sich die Größen allerdings im Bereich von MByte. BTRFS wurde im Zusammenhang der Testumgebung installiert, um die Arbeitsweise von Snapshots zu erkennen, allerdings wird von einem produktiven Einsatz des Systems abgeraten. Dieser Umstand und die möglichst hohe Realitätstreue der Testverfahren ließen die Entscheidung verdeutlichen, dass BTRFS nicht zur Auswahl steht, im Hinblick auf die Zukunft allerdings im Auge behalten werden sollte. 3645 Distributed Filesystems Kapitel 4 Ein Dateisystem dient der automatischen Speicherzuweisung zum Ablegen von Dateien auf einem Computer. Dateien bestehen dabei dabei aus dem eigentlichen Inhalt und den Metadaten. Die Metadaten speichern alle wichtigen Informationen ab, wie zum Beispiel die Größe der Datei, die Zugriffsrechte und das Datum der letzten Änderung. Reguläre Dateisysteme dienen somit als Schnittstelle zum physischen, mit dem Computer verbundenen, Speichermedium. Ein verteiltes Dateisystem kommt hauptsächlich in Clusterverbunden zur Anwendung, dort sind die physikalischen Speichermöglichkeiten verteilt in einzelnen Servern zu finden. Ein verteiltes System fasst die verschiedenen Speichermedien zentral zusammen und zeigt dieses als einen großen Datenträger an. Die zentrale Verwaltung ist dadurch auch möglich. Dort können unterschiedliche Partitionen und Filesysteme installiert werden. Diese dienen in diesem Fall der Zugriffskontrolle für einzelne Nutzer. Nötig dafür ist, dass es eine zentrale Kontrolle geben muss, der die Zuweisung vornimmt, welche Daten auf welchem Medium gespeichert werden. Anforderungen an verteilte Dateisysteme Die Zugriffstransparenz muss gewährleistet werden, dass bedeutet, dass ein Nutzer des Systems keinen Unterschied bemerken darf, ob er eine Operation auf eine lokale Datei ausführt oder auf eine, die in einem verteilten Dateisystem abgelegt ist. In diesem Punkt spielt die Ortstransparenz mit ein, diese regelt, dass es keine Rolle spielt, auf welchem physikalischen Datenträger die Datei abgelegt wird. Besonders wichtig bei solchen Systemen ist die Möglichkeit, parallel auf eine Datei zugreifen zu können, ohne das die Zugriffe einander beeinflussen. Bei Schreibzugriffen ist dies problematisch, dabei muss die Datei entsprechend für andere Nutzer gesperrt werden, wenn diese bereits als in Bearbeitung gekennzeichnet ist. Das System muss dafür sorgen, dass bei Fehlern von Clients und des Servers keine Inkonsistenzen auftreten. Das kann auch durch eine sehr hohe Anzahl von Anfragen geschehen, diese dürfen sich nicht auf die Antwortzeiten auswirken. 3746 4 Distributed Filesystems Ein weiterer wichtiger Punkt ist die Hardware- und Betriebssystem-Transparenz - Heterogenität. Wenn in einem Serververbund unterschiedliche Hard- und Software zur Anwendung kommt ist es wichtig, dass das Dateisystem für den Anwender diese umwandelt, sodass dieser keinen Unterschied bemerkt. Viele Distributed-File-Systems implementieren eine Replikationsmöglichkeit direkt. Das bedeutet, dass Daten mehrfach abgespeichert werden auf unterschiedlichen physikalischen Datenträgern, um eine möglichst hohe Ausfallsicherheit zu gewährleisten. Wenn Replikationen eingesetzt werden, darf der Nutzer aber nur eine Datei angezeigt bekommen, da die anderen nur zur Sicherung verwendet werden. Dabei ist es auch von Bedeutung, dass der korrekte Speicherungsort für den Client nicht sichtbar ist. Besonders wenn durch verschiedene Verfahren der Speicherort verändert wurde, darf dieses nicht direkt zu erkennen sein. Ein wichtiger Punkt, der bei der Betrachtung von verteilten Dateisystemen zu nennen ist, ist das Caching. Caching bedeutet, dass ein gewisser Speicherplatz auf dem Client zur Verfügung gestellt wird, der die Daten zur schnelleren Bearbeitung zwischenspeichert. Das erhöht die Geschwindigkeit und sorgt für Entlastung der Netzwerkschnittstellen. Caching hat ein sehr großes Problem, welches gelöst werden muss. Die Daten müssen immer aktuell gehalten werden. Das bedeutet, wenn die originale Datei im verteilten Dateisystem geändert wird, muss dieses entsprechend die Änderungen an jeden Client, der die Daten zwischenspeichert, weitergeben. Das gleiche gilt selbstverständlich für die andere Richtung. Dieser Konflikt ist nur dann zu lösen, wenn der Metadatenserver alle Informationen über die abgelegten Kopien beinhaltet und bei entsprechenden Änderungen diese auch an die Kopien weiterleitet. Wenn dies nicht geschieht, kann es zu Inkonsistenzen kommen. 3847 4 Distributed Filesystems 4.1 Unterschied zu regulären Filesystems Die Hauptaufgabe aller Dateisysteme besteht darin, Dateien und Informationen abzuspeichern und diese zur Verfügung zu stellen. Dabei darf dem normalen Nutzer nicht bekannt gemacht werden, wo die Dateien abgelegt werden und in welchem Format. Alle Systeme müssen bestimmte Zugriffsrechte anbieten, weil, insbesondere bei parallelen Speicherzugriffen, Inkonsistenzen auftreten können. Jedes Dateisystem muss selbstständig die Speicherung der Daten durchführen, diese zur Verfügung stellen (entsprechende Rechte vorausgesetzt) und den verfügbaren Speicherplatz möglichst optimal ausnutzen. Der Unterschied zwischen regulären und verteilten Dateisystemen besteht in der Art der Speicherung. Während reguläre Systeme immer einen physikalischen Speicher direkt ansprechen müssen, können bei Rechnerverbunden mehrere Speicher, die sich verteilt in den unterschiedlichen Knoten befinden, angesprochen und zusammenfasst werden, sowie in das Filesystem mit eingebunden werden. Diese Art setzt eine schnelle Netzwerktopologie voraus, die möglichst so schnell ist wie eine interne Kommunikation. Verbindungstopologien, die häufig zum Einsatz kommen, sind Infiniband oder Myrinet, wobei der Marktanteil von Myrinet in den letzten Jahren aufgrund des proprietären Aufbaus immer weiter zurückgeht und Infiniband das am häufigsten verwendete Medium ist. Auch wird bei diesem System mindestens ein Hauptserver benötigt, welcher von der Außenwelt angesprochen werden kann, um die Bereitstellung des Speicherplatzes bzw. der bereits vorhandenen Dateien regelt. Der Nutzer darf dabei nicht erkennen, ob es sich um ein reguläres oder verteiltes Dateisystem handelt, dieser bekommt in jedem Fall die Möglichkeit, eine Datei zu lesen, zu verändern oder abzulegen. Die Kommunikation über verschiedene Rechner erfordert Zeit, die bei besonders hoher Auslastung oftmals zum Flaschenhals der Kommunikation werden kann. Diese muss so schnell wie möglich sein, damit das verteilte Ablegen von Dateien zu einem Performancegewinn führen kann. Ein weiterer großer Unterschied zwischen den Dateisystemen besteht in der unterschiedlichen Behandlung der Daten. Während bei regulären Systemen die Datei in verschiedene Objekte fester Chunkgröße zerlegt wird und anschließend in einen vorgeschriebenen Speicherbereich geschrieben werden können, wird eine Datei durch 3948 4 Distributed Filesystems einen Server zentral aufgespalten und über einen Verzeichnis- und Dateidienst an die entsprechenden Stellen geschrieben. Diese Aufsplittung der Daten führt zu einem sehr hohen Performancegewinn, da parallele Zugriffe möglich sind, um die Datei zu schreiben und wieder zusammensetzen zu können. Dadurch werden die Anfragen schneller bearbeitet. Abbildung 4.1: Grundsätzlicher Aufbau eines verteilten Dateisystems  Der Zugriffsdienst stellt hierbei die zentrale Schnittstelle zwischen Andwendungsprogramm und Dateisystem. Dieser bildet die Aufrufe ab. Das gesamte System ist lediglich über den Zugriffsdienst von außen anzusprechen, die restliche interne Kommunikation bleibt verborgen. Der Verzeichnisdienst verwaltet die Dateien und deren Metadaten. Dazu gehört sowohl auch die Zuordnung der Metadaten mit den Speicherorten der einzelnen Objekte, aus denen die Datei besteht, aber auch die Steuerung der Zugriffsrechte. Der Dateidienst regelt alle elementaren Operationen der gespeicherten Dateien. Dazu gehört das Lesen, Schreiben, das Setzen von Timestamps, die Allokation von Speicherbereichen und die Pufferung. Die Gemeinsamkeit der Dateisysteme liegt heutzutage in der Behandlung der Daten. Die strikte Trennung zwischen Metadaten und den eigentlichen Werten ist in beiden Ansätzen vorhanden. Der große Unterschied zwischen regulären und verteilten Dateisystemen besteht in der 4049 4 Distributed Filesystems Kommunikation. Während reguläre Systeme lediglich die physikalisch vorhandenen Speichermedien ansprechen können, ist es bei verteilten Dateisystemen möglich, mehrere Server und deren Datenträger zusammenzufassen. Die Kapazität erhöht sich somit für den Nutzer, der nun nicht mehr manuell seine Daten auf verschiedene Festplatten aufteilen muss, sondern diese zentral als eine Festplatte verwalten kann. 4150 4 Distributed Filesystems 4.2 Kriterien zur Auswahl der Dateisysteme Für das Universitätsrechenzentrum ist es wichtig, dass das zukünftige Dateisystem bestimmte Voraussetzungen erfüllt, damit dieses zur Auswahl stehen kann. Um eine Entscheidung für oder gegen ein Dateisystem treffen zu können, müssen Vergleichspunkte geschaffen werden, mit deren Hilfe die Unterschiede deutlich gemacht werden können. Diese sind allgemein für jedes System zur Datenspeicherung gültig. Performance Die Performance des Dateisystems gehört zu den elementarsten Voraussetzungen von verteilten Dateisystemen. In diesem Punkt spielen sowohl die Lese- und Schreibgeschwindigkeiten eine Rolle, als auch die Zugriffszeiten auf eine bestimmte Datei. Viele Dateisysteme bieten Speicherkapazitäten von hunderten von Petabyte an, was die Suche nach einer speziellen kleinen Datei stark erschweren kann. Dafür muss ein effizientes Metadatenkonzept eingefügt werden, damit diese in möglichst geringer Zeit gefunden werden kann. Aus dem "Parallel File System Survey Report" ist zu entnehmen, dass hauptsächlich in "High-Performance-Computing"Datencentern das Hauptaugenmerk auf die Performance des Gesamtsystems gelegt wird. Zugriffsmöglichkeiten und -kontrolle Die gespeicherten Daten im Dateisystem müssen jedem Nutzer zur Verfügung gestellt werden können. Die Zugriffsmöglichkeiten beschreiben dabei, welche Möglichkeiten der Nutzer hat, diese zu verwenden. Die Zugriffskontrolle regelt zum einen die Sicherheitsaspekte, die die Rechte jeder Datei kontrollieren und die Kollisionsbehandlung, wenn mehrere Nutzer auf eine Datei zugreifen (Konsistenz). Dieses ist häufig entscheidend bei simultanen schreibenden Zugriffen. Ortstransparenz Die Ortstransparenz gibt an, dass ein Nutzer eines Dateisystems keine Informationen über den tatsächlichen Speicherort der Datei erhalten muss. Ausreichend ist die Information über das Vorhandensein der Datei selbst. Replikation Das Kriterium Replikation zeigt auf, ob es die Möglichkeit besteht, die Daten redundant durch eventuell mehrere Replikationen abzuspeichern, um einen 4251 4 Distributed Filesystems möglichen Datenverlust bei Ausfall eines Servers zu verhindern. Fehlerverhalten Das Verhalten des gesamten Systems im Fehlerfall ist in diesem Kriterium zusammengefasst. Die Möglichkeiten reichen von automatisierten Neustarts einzelner Knoten, bis zur automatischen Wiederherstellung des Dateisystems nach Serverausfall. Skalierbarkeit Skalierbarkeit bedeutet, dass die Arbeitsgeschwindigkeit des Clusters ansteigt, je mehr Server hinzugefügt werden. Dabei ist der Unterschied häufig groß, ob ein Metadatenserver oder Storageserver hinzugefügt wird. Das Ergebnis sollte eine Verbesserung der Zugriffsgeschwindigkeiten darstellen. Heterogenität Dieses Kriterium beschreibt, wie das Dateisystem mit unterschiedlichen Hard- und Softwarekombinationen umgehen kann. Administration Die Administration ist ein zentraler Punkt, der sich in mehrere Bereiche unterteilen lässt. Zum einen ist es wichtig, dass die Konfiguration des Dateisystems relativ leicht zu handhaben ist und einzelne Server ohne großen Aufwand hinzugefügt oder entfernt werden können. Zum anderen ist es positiv, wenn die Administration auch dezentral über einen entfernten Rechner durchgeführt werden kann. Sicherheit Die Sicherheit der abgespeicherten Daten im Dateisystem darf niemals außer Acht gelassen werden. Es sollte sowohl eine Zugriffskontrolle existieren, optional ist eine direkte Verschlüsselung aller Daten von Vorteil, um diese vor Zugriffen von nicht authorisierten Personen zu schützen. Für das Universitätsrechenzentrum Greifswald sind selbstverständlich alle Punkte von großer Bedeutung, entscheidend sind jedoch die Kriterien Performance, Skalierbarkeit und Administration. Diese Punkte stehen neben der generellen Sicherheit im Vordergrund der Betrachtungen. 4352 4 Distributed Filesystems 4.3 FhGFS Das vom Fraunhofer Institut für Techno- und Wirtschaftsmathematik entwickelte verteilte parallele Dateisystem FhGFS wird als high performance parallel file system  beworben. Es wurde entwickelt, um in High-Performance-Clusterverbunden eine hohe Datenübertragungsrate und Skalierbarkeit zu gewährleisten, und dabei höchst flexibel im administrativen Gebrauch sein. Die Nutzung des Systems ist kostenfrei, der Support wird kommerziell vom Fraunhofer Institut und deren internationalen Partnern angeboten. Bereits in der heutigen Zeit arbeiten mehrere Supercomputer, welche in der Top500 Liste aufgeführt sind, mit diesem Dateisystem. Als Beispiel ist die Goethe-Universität in Frankfurt am Main aus Deutschland zu nennen, sie arbeitet bereits seit einigen Jahren erfolgreich damit. Abbildung 4.2: Administrationsoberfläche FhGFS  4453 4 Distributed Filesystems Das Fraunhofer ITWM entwickelte ihr Dateisystem für Debian-, SuSe- und RedHat-Linux-Distributionen, ein Installation auf anderen Systemen wird nicht empfohlen, aber auch nicht völlig untersagt. Eine mögliche Test-Installation auf einem Gentoo-System war nicht möglich Interner Aufbau von FhGFS Bei der Entwicklung des Dateisystems lag das Hauptaugenmerk auf die Optimierung des Datendurchsatzes. Dieser ist abhängig von der Anzahl der verfügbaren Clusterknoten, weil das System parallele Schreib- und Lesezugriffe auf mehrere verfügbare Knoten durchführen kann. Beim Schreiben einer Datei wird diese in Chunks aufgeteilt, welche häufig eine festgelegte Größe haben, die am Kommunikationsprotokoll gekoppelt ist, um eine möglichst hohe Performance gewährleisten zu können. Es ist keine Fragmentierung beim Übertragen der Daten nötig. Häufig wird dabei Infiniband oder IPoIB (IP over Infiniband) verwendet. FhGFS bietet eine direkte Unterstützung von Infiniband an, ohne große zusätzliche Veränderungen durchzuführen. Durch die parallele Nutzung mehrerer Server wird die Geschwindigkeit sowohl für Lese-, als auch für Schreibvorgänge erhöht. Das Ziel ist dabei ein linearer Speed-Up in beiden Richtungen. Spezielle Metadatenserver verwalten die Zuordnung einzelner Dateien. Durch diese Parallelität kann ein Speedup erfolgen. Das Fraunhofer Filesystem arbeitet im Hintergrund mit verschiedenen Servern. Für eine Grundinstallation ist dabei ein Management-, ein Metadaten- und ein Storageserver nötig. Optional ist die Einrichtung eines Administrationsservers, welcher eine grafische Oberfläche zur Installation und Wartung einzelner Server zur Verfügung stellt. Die Metadaten- und Storage-Server können beliebig während des laufenden Betriebes erweitert, bzw. aus dem Verbund entfernt werden. Dies ist über die Administrationsoberfläche oder über die Kommandozeile möglich. Die Clients müssen bei der Installation ein spezielles Programmpaket installiert haben, um auf das Dateisystem zugreifen zu können. Dieses Paket installiert einen Dienst, der automatisch das Verzeichnis mounted. 4554 4 Distributed Filesystems Abbildung 4.3: Kommunikation mit FhGFS  Durch die dynamische Bereitstellung der angegebenen Server ist es möglich, diese nach den persönlichen Bedürfnissen einzurichten. Es besteht die Möglichkeit, einen oder mehrere zentralisierte Metadatenserver einzurichten oder diese direkt an die einzelnen Storageservern zu binden. Dadurch wird der gesamte Aufbau sehr flexibel und vom theoretischen Standpunkt auch massiv skalierbar. Durch die interne Unterstützung von Infiniband als zusätzliche Netzwerkhardware erreicht man dynamischen Failover, wenn ein Infiniband- und Ethernetnetzwerk gleichzeitig verwendet werden, denn das Dateisystem bietet das automatische Umschalten und Auslasten beider Netzwerktopologien an. Wichtig ist hierbei auch zu erwähnen, dass das System zum aktuellen Zeitpunkt zwei verschiedene Arten von Caching unterstützt. Der buffered -Modus kann einen kleinen Teil der Dateien lokal zwischenspeichern, die Größe beträgt allerdings nur wenige hundert KByte. Die zweite Möglichkeit ist der paged -Modus. Dieser greift auf den Linux pagecache zu und kann die Größe des vorhandenen Arbeitsspeichers annehmen. Dieser Modus ist allerdings vom Fraunhofer Institut noch als experimentell gekennzeichnet. Die verschiedenen Typen vom Caching können in der fhgfs-client.conf angepasst werden. Im vorliegenden Testfall wurden diese ausgeschaltet, damit keine Verfälschungen in den Ergebnissen durch Caching möglich sind. 4655 4 Distributed Filesystems Abbildung 4.4: FhGFS möglicher Aufbau  FhGFS verändert das interne Dateisystem jedes einzelnen Knotens nicht, das macht es möglich, spezielle Konfigurationen der Festplatten, wie zum Beispiel ein RAID-Verbund, auszunutzen. Diese Methode hat den Vorteil, dass Sicherheitsaspekte (z.b. RAID-Mirroring pro Server) nicht verloren gehen und Geschwindigkeitsvorteile (z.b. RAID-Striping pro Server) ausgenutzt werden können. Nachteilig ist, dass diese zusätzlich verwaltet werden müssen und die optimale Kombination für die persönlichen Anwendungen muss im Vorfeld festgelegt werden. Das FhGFS ein verteiltes Dateisystem ist, zeigt sich im internen Aufbau. Durch das Zusammenfassen mehrerer Server und der Darstellung als einzelne Storage-Ressource nach außen, sowie die strikte Trennung zwischen Metadaten und den eigentlichen Dateiinhalten führen zu einer sehr guten Skalierbarkeit, hoher Flexibilität und hoher Arbeitsgeschwindigkeit. Das Fraunhofer Institut verspricht in späteren Releases die Implementation von Replikationsservern, die Verfügbarkeit der Daten trotz eines Serverausfalls erhöhen. Zum aktuellen Zeitpunkt verfügt FhGFS nicht über die Möglichkeit, Mirroring automatisch durchzuführen. Lediglich durch die Ausführung vorgefertigter Skripte können Kopien des Metadaten- und Storageservers erstellt werden. Diese sind noch nicht automatisiert verfügbar und müssen vom Administrator manuell gepflegt werden. 4756 4 Distributed Filesystems Administration Ein wichtiges Entscheidungskriterium für das Universitätsrechenzentrum ist der Punkt der Administration. Wichtig hierbei ist die einfache Bedienung. Da das Fraunhofer Institut eine grafische Oberfläche zur Installation und Administration anbietet, kann nach der Grundinstallation ohne besondere Kenntnisse die gewünschte Konfiguration eingerichtet werden. Die Flexibilität zeigt sich besonders in diesem Punkt, da neue Clients und Server hinzugefügt werden können, ohne das System herunterfahren zu müssen. Die Oberfläche bietet zudem eine Zustandsüberwachung, sowie Nutzungsstatistiken an, die sofort abrufbar sind. Diese können für jeden Knoten einzeln oder in der Gesamtübersicht der einzelnen Serverstrukturen abgefragt werden. Wichtig ist hierbei anzumerken, dass die automatisierte Installation durch die grafische Oberfläche nur möglich ist, wenn dieser Server, der den Dienst bereit stellt, passwordless ssh unterstützt und zwar für den Root-Nutzer. Zudem ist eine Internetverbindung nötig, da die benötigten Pakete durch den internen Paketmanager des Linux-Betriebssystems automatisch heruntergeladen werden. Diese Pakete werden für Suse-, RedHat-Enterprise- und Debian-Distributionen angeboten. Besondere Arten werden nicht direkt unterstützt, die Installation wird vom Fraunhofer Institut nicht empfohlen, aber auch nicht verboten. Abbildung 4.5: Administrationsoberfläche von FhGFS am Beispiel Datendurchsatz 4857 4 Distributed Filesystems Vor- und Nachteile von FhGFS Das Fraunhofer Filesystem hat den Vorteil, dass die Verteilung der Aufgaben völlig flexibel und schnell einzurichten ist. Während des laufenden Betriebs können zusätzliche Knoten hinzugefügt und entfernt werden. Dies gilt für die Metadaten- und Storageserver, selbstverständlich auch für die Clients. Die Aufteilung der Daten erfolgt automatisch im Hintergrund. Auch die Installation der einzelnen Server kann automatisiert durchgeführt werden. Durch die zur Verfügung stehende grafische Oberfläche ist es möglich, einzelne Server anzusprechen, denen eine bestimmte Rolle zuzuweisen und automatisch die benötigten Daten zu überspielen. Allerdings benötigt der Hauptserver, wo der Administrationsdienst gestartet wurde, für die Installation eine funktionierende Internetverbindung, da dieser die Pakete einzeln herunterlädt. Manuell ist die Installation auch möglich, die Installationsdateien liegen für RedHat-Enterprise-, Debian- und Suse-Linux-Distributionen vor. Die Installation der einzelnen Pakete auf einem Gentoo-Betriebssystem war nicht möglich, laut Aussage des Fraunhofer Institutes wird allerdings an einer einheitlichen Umsetzung gearbeitet. Die Kombination verschiedener Betriebssysteme ist ebenso möglich, wie die unterschiedliche Konfiguration und Partitionierung vorhandener Massenspeicher. FhGFS arbeitet dabei mit verschiedenen RAID-Kombinationen zusammen und unterstützt alle regulären Dateisysteme wie ext4, XFS und BTRFS als Untergrund. Durch die grafische Oberfläche bekommt der Administrator einen guten Überblick über die vorhandenen Metadaten- und Storageserver. Es können sowohl die Betriebszeiten, die Performance der einzelnen Server, als auch die Auslastung derer überblickt werden. Dadurch können Engpässe schnell erkannt werden. Außerdem kann bei Anbindung von FhGFS an einen Mailserver dieser automatische Nachrichten verschicken, wenn es zu Fehlern kommt. FhGFS zwingt diese grafische Umsetzung nicht auf, die einzelnen Server können zusätzlich über Konsolenbefehle administriert werden. Zusätzlich ist es möglich, den Metadatenserver vollständig im Arbeitsspeicher unterzubringen. Durch die fehlende Replikationsmöglichkeit, die noch nicht vollständig implementiert wurde, ist davon allerdings abzuraten, da bei einem Stromausfall diese vollständig zerstört wären und die Daten im System unbrauchbar sind. 4958 4 Distributed Filesystems 4.4 MooseFS MooseFS ist ein open-source-projekt, was damit wirbt A File System for highly reliable petabyte storage  zu sein. Im Jahr 2009 ist die erste offizielle Version der Öffentlichkeit vorgestellt worden und wird seit dem als open-source-projekt gepflegt und weiterentwickelt. Das Hauptaugenmerk liegt auf die Hochverfügbarkeit, sowie auf die hohe Flexibilität in der Einrichtung und Erweiterung des Dateisystems. Hochverfügbarkeit wird bei MooseFS durch die automatische Replikationsmöglichkeit gegeben, indem Daten zunächst auf einem Server abgelegt werden, dieser aber selbstständig Replikationen anlegt. Es stehen alle Dateioperationen zur Verfügung, wie sie von regulären Dateisystemen auch angeboten werden. Dazu gehören die Operationen Lesen, Schreiben und Ausführen. Bei der Entwicklung wurde auch großen Wert auf die Sicherheit der Daten gelegt. Durch die Limitierung der Zugriffsrechte auf bestimmte Dateien und Verzeichnisse auf Basis von IP-Adressen oder festgelegten Passwörtern erschwert dieses Dateisystem die Zugriffe von fremden Nutzern. Hinzu kommt, dass gelöschte Dateien für eine definierte Zeit in einem Dateisystem-Papierkorb verschoben werden, bevor diese endgültig gelöscht werden. Dadurch ist eine Wiederherstellung in einer bestimmten Zeit möglich. In Europa findet man MooseFS derweil in verschiedenen Einsatzgebieten vor. Die offizielle Homepage bietet einen Service an, mit dessen Hilfe die Verbreitung des Dateisystems in offiziellen Unternehmen und Universitäten auf der ganzen Welt aufzeigt. Als Beispiel arbeitet in Deutschland die Firma Adrodev GmbH mit dem Dateisystem in einem großen Fileserver, von anderen Unternehmen wird das Dateisystem als Backup-Lösung oder im Webhostingbereich eingesetzt. 5059 4 Distributed Filesystems Abbildung 4.6: Einsatz von MooseFS in Europa  Interner Aufbau von MooseFS Der Grundaufbau von MooseFS besteht aus vier verschiedenen Komponenten. Der Master-Server dient als Managementserver, welcher die gesamten Metadaten aller gespeicherten Dateien beinhaltet. Dazu gehört sowohl die Dateigröße, als auch die verschiedenen Attribute und der Speicherort. Darüber hinaus werden alle benötigten Informationen über die gesamte Architektur gespeichert, wie zum Beispiel die einzelnen Verzeichnisse, die unterschiedlichen Netzinterfaces und die angeschlossenen Geräte. Die zweite Komponente sind die Datenserver, hier chunk servers genannt. Diese sind zuständig für die Speicherung aller Verzeichnisse und Dateien. Diese erfüllen noch eine weitere wichtige Eigenschaft. Wenn mehrere Server zur Verfügung stehen, können diese selbstständig bei geringer Last die Synchronisierung einzelner Dateien durchführen, die auf mehreren Replikationsservern gespeichert werden sollen. Die neuen weiteren Speicherziele müssen mit einer kurzen Nachricht im Master-Server bekannt gemacht werden. Um Replikationen durchführen zu können, existieren bei MooseFS Metadata-Backup-Server - megalogger server. Diese Server speichern die Veränderungen der Metadaten, außerdem machen diese in regelmäßigen Abständen 5160 4 Distributed Filesystems eine Sicherheitskopie des Metadatenservers. Dadurch ist ein Weiterarbeiten möglich, auch wenn der Master-Server ausfällt. Die vierte Komponente in der Architektur ist der Client - mfsmount, welcher den Zugriff auf das Dateisystem ermöglicht und das Verzeichnis auf dem Client-Computer mounted. Außerdem regelt es die Kommunikation mit dem Master-Server für die Übertragung der Metadaten, sowie mit den Chunkservern, die die Dateien und Verzeichnisse zur Verfügung stellen. Zu den Operationen gehört das Schreiben und Lesen von Dateien, das Auslesen von Verzeichnissen, das Verändern vorhandener Dateien, sowie die Änderung vorhandener Dateiattribute. Damit dies möglich ist, benötigt der Client zusätzlich das FUSE -System. FUSE steht dabei für Filesystem in Userspace und dient für die Kommunikation. Das ermöglicht die Nutzung des Clients auf Linux, FreeBSD und MacOSX-Betriebssystemen. FUSE ist dabei ein Kernelmodul, welches ermöglicht, die Dateisystemoperationen aus dem Kernel in den Userspace zu portieren, sodass Programme auch solche Operationen ausführen können. Für die Kommunikation von mfsmount ist eine direkte Kommunikation mit dem Master-Server und den vorhandenen Chunkservern nötig. 5261 4 Distributed Filesystems Abbildung 4.7: Schreibzugriff auf MooseFS  Wenn ein Client eine Datei auf das Laufwerk schreiben möchte, welches von MooseFS bereitgestellt wird, wird eine Anfrage an den Master-Server gestellt, welcher die Informationen über die Architektur und die Metadaten beinhaltet. Dieser allokiert auf den verfügbaren Chunkservern die benötigte Anzahl von Chunks. Hierbei erfolgt sofort eine Verteilung, wenn mehrere Chunkserver verfügbar sind. Anschließend wird dem Client die Information bereitgestellt, auf welchen Servern dieser die Daten ablegen kann. Die Kommunikation erfolgt nun ausschließlich zwischen Client und den Chunkservern. Anschließend erfolgt die automatische Replikation, wenn Replikationsserver eingerichtet wurden. Nach erfolgreichem Schreiben bekommt der Client die Nachricht, dass die Datei erfolgreich gespeichert wurde. Der Client sendet abschließend die Informationen an den Master-Server, der die Metadaten verändert. Bei einer Veränderung einer bereits vorhandenen Datei wird die neue Dateigröße, sowie das Attribut der letzten Veränderung abgespeichert. 5362 4 Distributed Filesystems Durch die automatische Verteilung der Daten auf verschiedene Server ist davon auszugehen, dass eine hohe Schreibperformance möglich ist, da bereits vom Master-Server der benötigte Bereich allokiert wurde und somit die Daten mit höchstmöglicher Geschwindigkeit übertragen werden können. Abbildung 4.8: Lesezugriff auf MooseFS  Der Lesezugriff ist einfacher aufgebaut. Der Client fragt beim Master-Server eine Datei an, dieser kennt bereits den korrekten Speicherort, gibt diesen an den Client zurück, sodass dieser eine erneute Anfrage an den Chunkserver stellt mit den Informationen über den genauen Speicherort. Dieser schickt die geforderte Datei an den Client. Der Aufbau von MooseFS sieht zunächst sehr kompliziert aus, zeigt in der Realität viele positive Eigenschaften. Insbesondere der Leseprozess ist sehr einfach, da der Metadatenserver den genauen Speicherort der Datei kennt und diese Informationen dem Client bereitstellt, sodass dieser direkt mit den Chunkservern direkt kommunizieren kann. 5463 4 Distributed Filesystems Mit der Hilfe von FUSE werden alle Operationen des Betriebssystems übersetzt in das korrekte Format, welches mit mfsmount an die entsprechenden Server übertragen wird. Dabei ist das FUSE unersetzlich, da sonst die Kommunikation nicht zu stande kommt. Bei der Einrichtung des Dateisystems ist es direkt möglich, die Anzahl von Replikationen einzurichten. Diese können selbstverständlich nur so groß sein, wie die Anzahl der vorhandenen Chunkserver. Dieses goal, die Anzahl der Kopien, kann auf Verzeichnisse und einzelne Dateien angewendet werden. Durch das Heraufsetzen dieses Wertes wird eine automatische Fehlertoleranz gewährleistet, da die Daten nun mehrfach abgespeichert werden und im Fall eines Ausfalles einzelner Hardwarekomponenten trotzdem zur Verfügung stehen. Somit müssen Hardwareausfälle in einem einzelnen Knoten oder teilweise Netzausfälle nicht dazu führen, dass die Dateien nicht mehr verfügbar sind. In dem Fall, dass ein Server ausfällt, wird dieses vom Master-Server registriert und automatisch der Replikationsserver angesprochen. Dies führt dazu, dass der Nutzer keine Ausfälle mitbekommt. Wenn diese angeforderte Datei nun verändert zurückgeschrieben wird, wird automatisch die Datei zunächst auf einem anderen Server abgelegt, sodass immer die Anzahl der Replikationen eingehalten wird. Wenn der defekte Server wieder verfügbar ist, dann erhält dieser die neue Datei und ist wieder der Hauptchunkserver. Der temporäre Chunkserver erhält die Nachricht, dass die Datei gelöscht werden kann, weil diese nicht mehr benötigt wird. Außerdem werden die Metadaten des Master-Servers aktualisiert. Der Punkt des Cachings wurde in MooseFS noch nicht weiter verarbeitet. Ein Client hat keine Möglichkeiten, bestimmte Werte zwischenzuspeichern. Das bedeutet, dass für jede Datei erneut eine Anfrage an den Server gestellt werden muss. Das Dateisystem der einzelnen Clusterknoten wird mit MooseFS nicht verändert. Es arbeitet mit ext3/4, XFS und auch BTRFS zusammen. Die Daten werden in einem speziellen Verzeichnis gespeichert und sind direkt auf dem Server nicht als reine Datei zu erkennen, da die Zerlegung in Objekte - Chunks - bereits vom Client vorgenommen und verteilt verschickt wurde. Auch die Nutzung interner RAID-Konfigurationen ist 5564 4 Distributed Filesystems unabhängig von MooseFS. Offiziell exisiteren dabei keine Begrenzungen. Die Begrenzung der Dateigröße liegt bei 2TB, die Begrenzung des gesamten Dateisystems liegt bei 16EiB Administration Ähnlich wie FhGFS bietet MooseFS eine administrative Oberfläche, die per HTTP-Port direkt angesprochen werden kann. Daher ist eine spezielle Installation eines weiteren Dienstes nicht nötig, es muss lediglich auf dem Master-Server der entsprechende Dienst mfscgiservice gestartet werden. Dabei ist jeder HTTP-Port möglich, standardmäßig ist 9425 geöffnet. Abbildung 4.9: Administrationsübersicht von MooseFS  Der Zugriff auf das System wird über einen üblichen Browser angesteuert. Dies setzt voraus, dass der mfscgiservice gestartet wurde. Eine automatisierte Installation ist nicht vorgesehen, die Anzeigen dienen lediglich der Information über den aktuellen Zustand, sowie der Verteilung der Daten und der Auslastung der Festplattenkapazitäten auf den verschiedenen Chunkservern. Defekte werden zudem angezeigt, sodass die Ausfallzeit eines Knotens möglichst gering gehalten werden kann. Die grafische Oberfläche bietet zwar keine Einstellmöglichkeiten, sie zeigt detaillierte 5665 4 Distributed Filesystems Informationen über einzelne Hardwarekomponenten aller verfügbaren Knoten an. Während einzelne Festplatten und Partitionen angezeigt werden können, erhält der Nutzer auch eine Übersicht über die einzelnen Verteilungen der Daten auf den unterschiedlichen Partitionen. Auch die Geschwindigkeit einzelner Komponenten wird angezeigt, außerdem wird eine Übersicht gegeben, wie viele Chunks aktuell gespeichert sind. Die Installation einzelner Server muss manuell für jeden einzelnen Knoten eingerichtet werden. Da aktuell lediglich ein Installationspaket vorhanden ist, muss die Konfiguration entsprechend für jeden einzelnen Server angepasst werden. So muss für eine Storageserverinstallation darauf geachtet werden, dass dieser keine Metadaten verwaltet soll und auch die grafische Oberfläche nicht installiert wird. Auch die Konfiguration muss manuell getätigt werden, da der Dateiname der Konfigurationsdateien manuell verändert werden muss. Der Umstand, dass die configure -Datei mit entsprechenden Befehlen bereits vor der Installation angepasst werden muss, sowie die manuell benötigte Umbenennung der einzelnen Konfigurationsdateien führt dazu, dass die Installation sehr umständlich wird. Insbesondere bei der Installation auf besonders vielen Knoten eines Clusters ist der Aufwand größer als bei der autmatisierten Installation von FhGFS. Bei der Entfernung eines Storageservers muss die entsprechende mfs_mounts.conf Datei angepasst werden, dass dieser Pfad nicht mehr zur Verfügung steht. Nach dem Neustart erkennt dies der Master-Server und verteilt die vorhandenen Daten auf andere Knoten. Anschließend kann der Server entfernt werden, ohne das es zu einem möglichen Datenverlust kommt. Allerdings erfolgt keine Meldung, wenn dieser Prozess abgeschlossen ist, der Administrator muss eine entsprechende Zeit warten bis dass alle Daten korrekt übertragen wurden. 5766 4 Distributed Filesystems Vor- und Nachteile MooseFS Auf dem Papier wirkt MooseFS als ein sehr performantes, sicheres, flexibles und durchdachtes Dateisystem. Die Möglichkeit der direkten Implementation von Replikationen dient der Sicherung von Daten und erhöht die Hochverfügbarkeit durch automatischen Failover. Bei einem Hardwareausfall werden die Replikationsserver angesprochen und die Veränderungen temporär und selbstständig auf einen anderen Server verteilt. Beim Wiedererscheinen des Hauptchunkservers werden die Daten eigenständig auf den aktuellen Stand gebracht. Die Grundüberlegungen über die Zugriffsmöglichkeiten sind sehr durchdacht und ermöglichen die Sicherstellung von Dateien und verbietet den Zugriff Fremder, wenn dieses nicht gestattet ist. Das interne Dateisystem der einzelnen Knoten des Compute-Clusters wird nicht verändert, alle standardmäßigen Dateisyteme werden dabei unterstützt. Dabei können auch alle verfügbaren RAID-Konfigurationen, die entweder Geschwindigkeits- oder Sicherheitsvorteile anbieten, genutzt werden. Die Daten sind trotz virtuellem System noch verfügbar. Die Flexibilität des Dateisystems wird dadurch gewährleistet, dass zur Laufzeit bestimmte Server hinzugefügt oder entfernt werden können. Es ist zu erwähnen, dass das Kernelmodul FUSE genutzt werden muss, welches die Kommunikation mit einem Dateisystem aus dem Kernel in den Userspace umlegt. Dieses ist für die Verbindung mit dem Master-Server elementar wichtig. Der Punkt ist als neutraler Kritikpunkt anzusehen, weil die Nutzung eines zusätzliches Programms zur Benutzung des Dateisystems nicht immer positiv ausfallen muss. Die Anpassungen einzelner Teile der Kommunikation müssen auf beiden Seiten eingepflegt werden. Wenn die Entwickler von FUSE generelle Änderungen vornehmen, müssen die in MooseFS auch angepasst werden. 5867 4 Distributed Filesystems 4.5 CephFS CephFS ist ein paralleles verteiltes Dateisystem, welches Dateien in Objekte zerlegt und diese auf verschiedene Storageserver ablegt. Dabei soll dieses eine sehr gute Performance, Skalierbarkeit und Sicherheit bieten. Ceph ist ein Open-Source-Projekt, welches frei verfügbar und einsetzbar ist. Im Jahr 2006 wurde das erste Paper über Ceph veröffentlicht, seit 2010 ist dieses offiziell in den Linux-Kernel übernommen worden. Im August 2013 wurde eine aktualisierte Version zur Verfügung gestellt. Laut des Herstellers ist ein produktiver Einsatz allerdings noch nicht empfohlen, weil nicht verhindert werden kann, dass in dem frühen Entwicklungsstadium, in dem sich Ceph befindet, Fehler auftreten und es somit zu Datenverlust kommen kann. Trotz dieses Umstandes ist Ceph ein großes Thema und zählt als potentieller Primus aller bereits bekannten verteilten Dateisysteme Interner Aufbau von CephFS Das Dateisystem von Ceph besteht aus mindestens vier Komponenten. OSD steht für "Ceph OSD Daemonünd ist ein Storageserver. Dieser speichert die Daten, verwaltet die Replikationen und kann automatisch Recovery-Befehle ausführen, damit Daten bei einem Serverausfall weiter zur Verfügung stehen. Ceph Monitor verwaltet die Struktur der einzelnen Server, das bedeutet, dass Maps angelegt werden, welcher Server wofür zuständig ist und speichert die Änderungen ab. Die Ceph Metadata Server dienen der Speicherung der Metadaten der Dateien, die auf dem Storageserver gespeichert wurden. Die Clients mounten mit Hilfe von FUSE ( Filesystem in Userspace ) ein für sie vorgegebenes Netzlaufwerk. Diese können mit Hilfe des Befehls CEPHX verschlüsselt auf bestimmte Bereiche auf dem Dateisystem zugreifen. Die Verschlüsselung wird mit dem Austausch eines geheimen Schlüssels durchgeführt, welcher von jedem Client angelegt und dem Monitor bekannt gemacht werden muss. 5968 4 Distributed Filesystems Abbildung 4.10: Authentifizierung eines Clients bei CephFS  Mit Hilfe von mehreren Metadatenservern ist es möglich, die Aufgaben zu verteilen, standardmäßig übernehmen diese die Speicherung von Unterordnern des Dateisystems. Im Gegensatz zu der Konkurrenz berechnet Ceph die Blockgröße einer Datei, die geschrieben werden soll und allokiert diese sowohl im eigenen Metadatenspeicher, als auch auf dem Storageserver. Durch die integrierte Möglichkeit, Replikationen anzulegen, die sowohl für Metadatenund Storageserver möglich sind, ist eine automatische Lastverteilung und zugleich die Sicherung der Daten gewährleistet, da diese auf mehreren Servern gespeichert und zur Verfügung gestellt werden können. Genau wie MooseFS kann Ceph mit FUSE auf das Dateisystem zugreifen, allerdings steht hierbei eine angepasste Version zur Verfügung, diese verspricht eine bessere Performance und Ausfallsicherheit. Die Unterscheidung zwischen Metadaten- und Storageserver ist typisch für verteilte 6069 4 Distributed Filesystems Abbildung 4.11: Transaktionsübersicht CephFS  Dateisysteme. Die Metadatenoperationen werden dabei ausschließlich zwischen dem MDS und dem Client ausgehandelt. Bei einem Schreibzugriff wird der reservierte Block vom Metadatenserver an den Client übergeben, dieser kann seine Daten direkt in diesem Bereich schreiben. Beim Lesen verhält es sich dabei ähnlich. Die Anfrage wird an den MDS gestellt, dieser gibt den konkreten Speicherort zurück und die Kommunikation der Daten erfolgt aussschließlich über Client und OSD. Bei einem einfachen Dateilisting wird lediglich der Metadatenserver angesprochen, da dieser die gesamte Struktur gespeichert hat. Um diese Einträge möglichst schnell zu finden, verwendet Ceph einen Suchalgorithmus, der CRUSH genannt wird. CRUSH ist eine Art Hashingfunktion, die mit Hilfe der inode-nummer die Einträge wesentlich schneller finden kann. Auch wenn mehrere MDS zur Verfügung stehen ist die Performance beim Dateilisting sehr gut. Die Replikationsmöglichkeit beschränkt sich nicht nur auf die Storageserver, auch die Metadatenserver können abesichert werden. Ceph arbeitet als Copy-on-Write -System, das bedeutet, wie auch bei BTRFS, dass zunächst Kopien einer Datei angelegt werden, bevor diese auf dem gesamten System geschrieben und die Metadaten entsprechend angepasst werden. 6170 4 Distributed Filesystems Abbildung 4.12: Replikationsaufbau Ceph  Die Daten vom Client werden nur auf einem Server geschrieben, anschließend werden die Daten über die angelegten Replikationsserver verteilt. Dabei werden beim Schreiben der Replikationsdaten Checksummen eingeführt, die gewährleisten, dass die Daten korrekt übermittelt wurden. Auch bei einem Ausfall des Hauptstorageservers übernimmt der nächste Replikationsserver die Arbeit, ohne dass ein Eingreifen des Administrators nötig ist oder der Benutzer etwas davon spürt. Die Metadaten werden entsprechend angepasst, sodass auch der Metadatenserver weiß, welchen Server er aktuell ansprechen muss. Dieser überprüft auch ständig die Verfügbarkeit der einzelnen Knoten und kann selbstständig die Daten von Replikationsservern abrufen. Ein solcher Server ist nicht dafür vorgesehen, die Performance zu verbessern, es dient der Erhöhung der Hochverfügbarkeit. Als darunter liegendes Dateisystem empfiehlt Ceph die Nutzung von BTRFS, welches die Probleme von ext4 und XFS ausmerzen soll. Während XFS hauptsächlich die die Nutzung für große Dateien sehr gut funktioniert, möchte Ceph mit allen Arten von Dateigrößen performant arbeiten können. Da sich aber genau dieses System selbst noch in der Entwicklung befindet, ist die Sicherheit der Daten nicht gewährleistet. 6271 4 Distributed Filesystems Administration von CephFS Die Administration von Ceph bietet zum aktuellen Zeitpunkt keine grafische Oberfläche an, die einen Überblick über die vorhandene Infrastruktur geben könnte. Durch Kommandozeilenbefehle ist es möglich, die Erreichbarkeit einzelner Server und Dateien zu ermitteln, sowie deren Replikationsstatus. Das erfordert Wissen über die einzelnen Befehle, zudem muss der generelle Aufbau des Systems bekannt sein. Durch das Installieren des ceph-deploy -Paketes ist es möglich, automatisierte Installationen durchzuführen. Dies setzt eine aktive Internetverbindung, sowie den passwortlosen ssh-root-zugang zu den einzelnen Knoten voraus. Dieses Paket steht aktuell nur für RedHat-Linux-Distributionen zur Verfügung, eine Installation auf einem Gentoo-System war nicht möglich, da bestimmte Abhängigkeiten nicht aufgelöst werden konnten. Durch diese automatisierte Installation hat der Administrator bei der Einrichtung eines Systems zwar den Vorteil, dass die Einstellungen auf jedem Knoten gleichmäßig gespeichert werden, allerdings müssen spezielle Änderungen immernoch manuell für jeden Knoten einzeln getätigt werden. Dies macht die Installation umständlich und zeigt sich im Vergleich zu anderen verteilten Dateisystemen als schwierig zu konfigurieren. 6372 4 Distributed Filesystems Vor- und Nachteile CephFS Der große Vorteil von Ceph ist der modulare Aufbau des Dateisystems. Es ist durch spezielle Kommandozeilenbefehle möglich, die gesamte Infrastruktur einzurichten. Zusätzlich besteht die Möglichkeit, dass jeder Server nur die Pakete erhält, die auch gebraucht werden. Die Replikationsmöglichkeiten der Storage-, sowie der Metadatenserver machen Ceph zu einem sicheren, verteilten Dateisystem. Die Updatemöglichkeiten auf neuere Versionen ist unkompliziert möglich, diese können durch einen Update-Befehl durchgeführt werden, wenn das Dateisystem nicht in Benutzung ist. Das eigentliche Hauptaugenmerk von CephFS liegt dabei in der optimalen Nutzung der Festplattenkapazitäten, um Performance und Skalierbarkeit zu erreichen. Wenn alle diese Punkte zusammen ein einheitliches Ergebnis zusammentragen, ist Ceph eine sehr gute Alternative zu anderen, auch kommerziellen, Dateisystemen. Auch CephFS nutzt das Kernelmodul FUSE, allerdings in einer speziellen abgewandelten Version, die vom Hersteller zur Verfügung gestellt wird. Daher ist der Umstand, dass Änderungen am eigentlichen Programm erst dann nötig sind, wenn der Hersteller selbst diese auch am eigenen Ceph-FUSE -Paket einpflegt. Es existieren einige gravierende Nachteile. Die fehlende administrative Übersicht über alle vorhandenen Knoten machen die Einrichtung und Kontrolle kompliziert und zum Teil sehr umständlich. Diese Art der Einrichtung jedes einzelnen Servers stellt dabei eine Herausforderung dar, da keine gute und verständliche Dokumentation für die Installation des Systems vorhanden ist. Der größte Nachteil ist allerdings, dass sich das System aktuell noch in der Entwicklung befindet und der Hersteller explizit darauf verweist, dass es zu Datenverlusten kommen könnte und dass ein produktiver Einsatz des Systems nicht empfohlen wird. Das ist ein ausschlaggebendes Kriterium für die Betrachtung, welches Dateisystem produktiv zum Einsatz auf den neuen Compute-Cluster des Universitätsrechenzentrums installiert werden soll. 6473 4 Distributed Filesystems 4.6 GlusterFS GlusterFS ist ein Open-Source paralleles, verteiltes Dateisystem, welches von der Firma Red Hat entwickelt und weitergeführt wird. Aktuell in der Version bietet das System einen modularen Aufbau an, indem die einzelnen Komponenten flexibel eingesetzt werden können. GlusterFS soll ein extrem performantes Dateisystem sein, welches perfekte Skalierbarkeit bietet, sowie mit Storagegrößen umgehen kann, die über die Petabytegrenze hinaus gehen. Durch die Einrichtung von Replikationsservern können Daten automatisiert gesichert werden, die Hochverfügbarkeit kann somit gewährleistet werden. Zudem hält sich GlusterFS an generelle Namenskonventionen, sodass dieses in verschiedenen Umgebungen eingesetzt werden kann. GlusterFS kann durch seinen modularen Aufbau auf unterschiedliche Arten verwendet werden. Entweder stellt dieses ein einzelnes Netzlaufwerk über das Netzwerk zur Verfügung, indem Benutzer lesen und schreiben können oder, wenn mehrere Server zur Verfügung stehen, können diese verteilt ( distributed ) abgelegt werden. Durch die Möglichkeit, Replikationen einzurichten, kann GlusterFS auch als "Replicated Storageängesehen werden. Außerdem sind verschiedene Kombinationen einzelner Komponenten möglich. Dieses System ist bereits sehr weit verbreitet und wird von vielen Firmen produktiv verwendet. Die stetige Entwicklung von RedHat und der gesamten Gluster-Community zeigt sich in den Updates, sowie der Möglichkeit, wenn Fehler aufgetreten sind, dass diese direkt über die Internetadresse gemeldet werden können. 6574 4 Distributed Filesystems Interner Aufbau von GlusterFS Die Komponenten von GlusterFS bestehen aus Datenservern und Replikationsservern. Der große Unterschied zwischen den anderen bereits beschriebenen Dateisystemen ist die Behandlung der einzelnen Dateien. Diese werden nicht in einzelne Objekte zerlegt, sondern die gesamte Datei wird auf einem Server abgelegt. Dabei sind diese standardmäßig nicht verschlüsselt und für den Administrator frei zugänglich. Eine eigene Verschlüsselungsmethode kann bei der Installation zusätzlich mit eingerichtet werden. Die Auswahl, welche Datei auf welchem Server abgelegt wird, ist nicht möglich. Genau wie CephFS und MooseFS benutzt GlusterFS die Kommunikationsschnittstelle FUSE, welche die Dateisystemoperationen aus dem Kernel in den Userspace verlagert, sodass Applikationen darauf zugreifen können. Das darunter liegende Dateisystem kann dabei sowohl in ext3/4 partitioniert sein, auch XFS wird direkt angeboten. Durch die Nutzung von FUSE werden nahezu alle Linux-Distributionen unterstützt, sowie FreeBSD, OpenSolaris und Mac OS X. Abbildung 4.13: Übersicht über GlusterFS  6675 4 Distributed Filesystems Das virtuelle Dateisystem wird über ein vorhandenes gesetzt und die Daten werden in zuvor festgelegte Ordner abgelegt. Damit ist es für einen Administrator möglich, diesen zu durchsuchen, weil die gesamte Datei gespeichert wird. Die Nutzung von RAID-Konfigurationen ist direkt möglich, da dieses unabhängig vom virtuellen vorhandenen System ist. Zusätzlich bietet GlusterFS die Nutzung von Infiniband an, dafür wird ein eigens entwickeltes RDMA-Tool zur Verfügung gestellt. Dieses kann in den Kommunikationsdateien festgelegt werden, auch eine Redundanz über zusätzliche Netzwerkschnittstellen ist möglich. Es wird standardmäßig die schnellste Verbindung gewählt. Wenn diese nicht zur Verfügung steht, dann wird automatisch auf die nächste Verfügbare umgeschaltet, sodass ein Fail-Over gewährleistet werden kann. Abbildung 4.14: Datenverteilung über GlusterFS  Während andere verteilte Dateisysteme eine Trennung zwischen Metadaten und eigentlichen Daten vornimmt, unterscheidet GlusterFS sich in diesem Fall. Es wird generell die gesamte Datei auf einem Server gespeichert. Wenn ein Programm mehrere Dateien benötigt, können diese von mehreren Servern gelesen werden, ansonsten wird jede Datei nur von einem zur Verfügung gestellt. Dies hat auch den Nachteil, dass die Dateien nicht zur Verfügung stehen, wenn ein Server nicht erreichbar ist und kein Replikationsserver vorhanden ist. Dies kann zu Problemen führen, insbesondere bei sensiblen Daten. Diese Art der Verteilung von Daten hat insbesondere bei Zugriffen auf viele verschiedene Dateien große Vorteile, da die Anfragen stets verteilt werden können. Hinzu kommt, dass jeder Client auch als Server dienen und seinen verfügbaren Speicher zur Verfügung stellen kann. Es muss aber darauf geachtet werden, dass die Datenübertragung von sehr großen Dateien nicht die Größe einzelner Festplatten- und Festplattenkonfigurationen 6776 4 Distributed Filesystems überschreitet, zum Beispiel beim Schreiben einer 2TByte großen Datei, wenn nur 1TByte große Festplatten zur Verfügung stehen. Diese Dateiübertragung schlägt fehl. GlusterFS bietet zwar praktisch unendlich Speicherplatz an, die einzelne Dateigröße ist allerding limitiert auf die Festplattenkapazitäten einzelner Knoten im Cluster. Bei einem Hinzufügen von neuen Knoten in ein bereits existierendes System, gibt es eine Rebalance -Funktion, welche automatisch Daten auf diesen Server mit auslegt und dementsprechend die Geschwindigkeit erhöht werden kann. Die Möglichkeit des Zwischenspeicherns von Daten auf den lokalen Festplatten der Clients ist mit GlusterFS möglich. Die Caching-Konfigurationen sind dabei sehr weitläufig. Zum einen kann die generelle Größe angegeben werden, es ist aber auch möglich, eine Mindest- und Höchstgrenze einzustellen. Das ist insbesondere bei Daten von Vorteil, die häufig gelesen werden müssen. Da dieser Punkt für das Universitätsrechenzentrum allerdings nicht von Vorteil ist, da die Berechnungen auf dem Compute-Cluster erfolgen und die Ergebnisse immer in einer Datei aktualisiert werden, wird das Caching für die folgenden Testdurchläufe deaktiviert. Dies führt auch dazu, dass es zu einem besseren Vergleich der einzelnen Dateisysteme kommen kann. Generell bietet GlusterFS die Möglichkeit der Sicherungen an, die auf IP-Basis ausgelegt ist. Die Zugriffskontrolle kann sowohl beim Client, als auch beim Server eingestellt werden. Zusätzlich ist die Möglichkeit gegeben, dass bestimmte Clients auf bestimmte Verzeichnisse innerhalb des Dateisystems zugreifen dürfen. Bei der Installation des Clients müssen alle vorhandenen Storageserver bekannt gemacht werden, sodass dieser die Aufgabe der Verteilung der Daten automatisch übernimmt. Dadurch, dass keine Trennung zwischen Metawerten und den einzelnen Daten durchgeführt wird, ist es nicht nötig, einen eigenen Server anzusprechen. Jedoch wird immer ein Hauptserver ausgewählt, welcher immer zuerst angesprochen wird. Um einen Nutzer entsprechende Kapazitäten zur Verfügung zu stellen, bietet GlusterFS sogenannte Subvolumes an, welche mit einer gewünschten Dateigröße angelegt werden kann. 6877 4 Distributed Filesystems Administration Die Administration von GlusterFS ist nicht mit anderen Systemen zu vergleichen. Es fehlt generell eine grafische Oberfläche, allerdings werden bei der Installation Pakete installiert, die spzezielle Gluster-Kommandozeilenbefehle einrichten, mit dessen Hilfe die Infrastruktur aufgebaut, verwaltet und wieder aufgelöst werden kann. Die Möglichkeit des Anlegens von Replikationen wird bereits beim Erstellen des subvolumes eingerichtet. GlusterFS verarbeitet automatisch die Daten und führt die Replikationen aus, ohne dass der Benutzer davon etwas bemerkt. Diese doch recht komplizierte Möglichkeit, das Dateisystem zu administrieren, ist verbesserungswürdig, insbesondere weil Beispiele der Konkurrenz aufzeigen, dass eine einfachere und übersichtliche Art der Verwaltung möglich ist und auch Sinn macht Vor- und Nachteile GlusterFS Durch den grundlegenden Aufbau und der Verteilung der Dateien auf verschiedene Server, ohne dass diese selbst verändert werden, kann das System sehr flexibel und performant machen. Auch durch den Verzicht auf die Nutzung eines speziellen Metadatenservers wird Speicherplatz und Performance eingespart. Bei anderen Dateisystemen wird mindestens ein gesamter Knoten nur für die Verwaltung der Metadaten verwendet, dieser kann bei GlusterFS als zusätzlicher Storageserver verwendet werden. Allerdings kann, insbesondere bei sehr großen Dateien, der Geschwindigkeitsvorteil nicht mehr vorhanden sein, weil beim Zugriff immer ein einzelner Server angesprochen wird und damit eine direkte Datenübertragung zwischen einem Server und dem Client stattfindet. Positiv anzumerken ist, dass GlusterFS mit jeder Distribution genutzt werden kann, die FUSE unterstützt und somit sehr weitreichend verwendet werden kann. Die Performance sollte sich insbesondere beim Lesen oder Schreiben vieler Dateien beim Hinzufügen mehrerer Server verbessern, dies ist vom Grundaufbau des Systems zu erwarten. GlusterFS bietet zudem eine eigene Variante von FUSE an, welche besser auf das Dateisystem abgestimmt ist. GlusterFS bietet keine grafische Oberfläche, die den Aufbau und die Verteilung der Server aufzeigen könnte. Die Installation wird mit Kommandozeilenbefehlen durchgeführt. Durch die Einrichtung des glusterfs-utils -Pakets ist es möglich, die Erreichbarkeit der anderen Server zu überprüfen. 6978 4 Distributed Filesystems Für jeden Server muss eine eigene Konfigurationsdatei geschrieben werden, wo exakt aufgeführt wird, welcher Client darauf zugreifen kann und welche weiteren Storageserver sich im Netzwerk befinden. Dieser Umstand ist in der ersten Einrichtung relativ kompliziert, allerdings können verschiedene Ketten aufgebaut werden. Ketten bedeutet, dass wenn Server1 Server2 kennt und dieser Server3, dann kennen sich auch Server1 und Server3. Diese Möglichkeit vereinfacht die Einrichtung des Dateisystems. Zudem bietet GlusterFS an, lediglich eine bestimmte Größe des vorhandenen Dateisystems zur Verfügung zu stellen, indem eine virtuelle Partition eingerichtet wird. GlusterFS arbeitet dabei mit allen gängigen regulären Dateisystemen zusammen, empfohlen wird die Nutzung von ext4 bei besonders kleinen und XFS bei großen Dateien. Die Nutzung von BTRFS wird zwar unterstützt, allerdings durch den frühen Entwicklungsstand noch nicht empfohlen. 7079 4 Distributed Filesystems 4.7 Entscheidung Die vorliegende Arbeit erläutert den Aufbau der Systeme FhGFS, MooseFS, Ceph und GlusterFS genauer. Dabei existieren weitere, auch kommerzielle, Systeme, die einen ähnlichen internen Aufbau vorweisen können und eine ähnliche Struktur der Daten beinhaltet. Diese Dateisysteme wurden mit Bedacht ausgewählt, weil diese jeweils einen unterschiedlichen Grundgedanken haben und auf unterschiedliche Kerneigenschaften eines Dateisystems spezialisiert sind. Andere Dateisysteme, wie zum Beispiel Lustre, welches offiziell im Linux-Kernel aufgenommen wurde, zählen zu großen Vertretern dieser Arten. Lustre ist vom Grundaufbau vergleichbar mit MooseFS, allerdings bietet dieses noch keine direkten Replikationsmöglichkeiten an. Andere Systeme bieten spezielle Eigenschaften an, die für das Universitätsrechenzentrum nicht von Bedeutung sind und somit nicht getestet werden. Für die Entscheidung, welches Dateisystem für den neuen Compute-Cluster verwendet werden sollte, werden im Folgenden die Systeme FhGFS, MooseFS und GlusterFS auf einem zur Verfügung gestellten Test-Cluster installiert und auf unterschiedliche Eigenschaften hin überprüft. Es wird auf die Installation von CephFS verzichtet, da sich das System, ähnlich wie BTRFS als reguläres Dateisystem, noch in einer relativ frühen Entwicklungsphase befindet und daher für einen produktiven Einsatz noch ungeeignet ist. Allerdings sind erste Testberichte sehr vielversprechend, sodass CephFS bei der Betrachtung für die Zukunft nicht vergessen werden darf. 7180 4 Distributed Filesystems Abbildung 4.15: Zusammenfassung Eigenschaften verteilter Dateisysteme Wie aus der Abbildung 4.15 zu entnehmen, besitzen alle vorgestellten Dateisysteme die Möglichkeit, sehr große Datenmengen zusammenzufassen. FhGFS und GlusterFS bieten sogar theroetisch unbegrenzten Speicherplatz an, die verteilt auf einer sehr großen Anzahl von Servern liegen können. Dabei werden von allen Systemen alle unterliegenden regulären Dateisysteme und die dazugehörigen RAID-Konfigurationen unterstützt. Die Tabelle zeigt dabei die unterschiedlichen Gewichtungen der grundlegenden Eigenschaften, die an ein verteiltes Dateisystem gelegt werden. Dabei bedeutet ++, dass das System auf diesen Punkt spezialisiert ist, o, dass das System dies zwar anbietet, aber nicht als Hauptargument anzusehen ist und, dass dieser Eigenschaft vom Dateisystem nicht erfüllt wird. Dabei gibt es noch Abstufungen ( +, - ), die aufzeigen, dass diese Eigenschaft unterstützt wird, allerdings die Umsetzung im Vergleich zu den anderen Systemen komplizierter und unkomfortabler gelöst wurde. Die Verbreitung ist der einzelnen Dateisysteme ist unterschiedlich. Während GlusterFS und FhGFS auf zahlreichen großen Clusterverbunden zum Einsatz kommen, ist MooseFS ein relativ unbekanntes Dateisystem, welches bis zur heutigen Zeit nur vereinzelt eingesetzt wird. FhGFS und GlusterFS sind Dateisysteme, die auch auf Supercomputern zu finden sind, die in der Top500-Liste gelistet werden. Dieser Umstand zeigt, dass diese beiden Dateisysteme sehr ausgereift sein müssen und eine hohe Performance und Skalierbarkeit aufweisen. 7281 4 Distributed Filesystems Unterschiede gibt es in der Auswahl der Netzwerktopologien. MooseFS bietet lediglich den Umstand, über TCP-Verbindungen mit den einzelnen Servern zu kommunizieren. Dabei ist der Umweg über Infiniband-over-IP möglich. Die direkte Implementierung von Infiniband bieten FhGFS und GlusterFS an, dazu können spezielle Pakete installiert werden, die Erkennung erfolgt automatisch. In den zuvor festgelegten Kriterien zur Auswahl der Dateisysteme gibt es große Gegensätzlichkeiten, da sich bereits die grundlegenden Eigenschaften völlig unterscheiden. Während das Fraunhofer Dateisystem auf absolute Performance, Skalierbarkeit und Stabilität ausgelegt ist, dazu eine sehr gute administrative Oberfläche anbietet, liegt das Hauptaugenmerk bei MooseFS auf die Sicherheit und Replikationsmöglichkeit. Diese Punkte werden bei FhGFS nur sekundär behandelt und sollen in folgenden Versionen mit eingeführt werden. MooseFS steht nicht für hohe Performance, allerdings für Stabilität und Zugriffskontrolle. GlusterFS ist genau zwischen diesen beiden Konkurrenten einzuordnen. Es wirbt für eine gute Performance und ausgezeichnete Stabilität, bietet zudem noch die Sicherheit und Replikationsmöglichkeiten an, die auch bei MooseFS eingearbeitet wurden und bei FhGFS fehlen. Dafür existiert keine administrative Oberfläche für dieses System, die eine einfache und unkomplizierte Installation und Wartung ermöglichen könnte. Alle vorgestellten Dateisysteme haben die Eigenschaft, in heterogenen Netzwerken zu funktionieren. Während MooseFS und GlusterFS auf allen Linux-Distributionen, sowie OpenSolaris, FreeBSD und Mac OS X genutzt werden kann, stehen für das FhGFS Installationen für RedHat-Enterprise, Debian- und SuSe-Distributionen zur Verfügung. Die Verbindung unterschiedlicher Hardware und Betriebssystemen ist in allen vorgestellten Beispielen gegeben. Die Eigenschaft Fehlerverhalten zeigt allerdings große Unterschiede zwischen den Dateisystemen. Das Fraunhofer Dateisystem kann im Falle eines Ausfalles einzelner Knoten keine automatischen Replikationsmöglichkeiten anbieten. Daher ist damit zu rechnen, dass das gesamte Dateisystem kurzzeitig nicht zur Verfügung steht. Dieses Feature soll in späteren Versionen hinzugefügt werden, um Hochverfügbarkeit erreichen zu können. MooseFS und GlusterFS bieten sowohl Replikationsmöglichkeiten an, als auch die Eigenschaft, sich automatisch zu rekonfigurieren, sobald ein Server nicht zur Verfügung steht. Diese können bei entsprechender Anzahl von Replikationen automatisch auf den nächsten Server umschalten, um die Daten weiter verfügbar zu halten. Allerdings ist es auch hier nicht möglich die Daten zu retten und 7382 4 Distributed Filesystems wiederherstellen zu können, wenn keine Sicherungen angelegt sind. MooseFS bietet zudem einen Dateisystempapierkorb an, welcher für einen gewissen Zeitraum gelöschte Daten vorbehält, um eine Rekonstruktion durchführen zu können. Dieser Zeitraum ist flexibel einstellbar. Zusammenfassend ist zu sagen, dass die Eigenschaften aller vorgestellten Dateisysteme aufzeigen, dass es bei verteilten Dateisystemen nicht dazu kommen kann, dass ein Vertreter alle nötigen Eigenschaften erfüllt. CephFS ist hierbei ausgeklammert worden, weil dieses noch nicht als System anzusehen ist, welches in einem produktiven Einsatz installiert werden sollte. Die folgenden Testdurchläufe werden mit FhGFS, MooseFS und GlusterFS durchgeführt, um einen konkreten Überblick über die Performance, Skalierbarkeit, Sicherheit, Stabilität und Administration zu erhalten. Dies geschieht, damit die Entscheidung für ein bestimmtes Dateisystem für den neuen Compute-Cluster des Universitätsrechenzentrums getroffen werden kann. 7483 Tests Kapitel 5 Um ein Dateisystem auf Performance und Stabilität testen zu können, exisiteren mehrere Möglichkeiten und Programme, die automatisiert verschiedene Verfahren ablaufen lassen. Bei vielen Programmen werden Möglichkeiten angeboten, diese nach eigenen Bedürfnissen zu konfigurieren. Insbesondere der Datendurchsatz, der sich durch das Zusammenschalten von mehreren Servern und dem verteilten Abspeichern der Daten erhoffen lässt, soll dabei untersucht werden. Außerdem werden Langzeittests durchgeführt. Diese bestehen aus dem dauerhaften Schreiben und Lesen vom Daten, die in dem Dateisystem hinterlegt sind bzw. werden. Die Stabilität ist insbesondere im dauerhaften Einsatz unablässig. Ein möglicher Ausfall zieht unweigerlich das Stilllegen des gesamten Clusters nach sich, da keine Rechenoperationen mehr gespeichert, ausgeführt und verarbeitet werden können. Selbst wenn diese noch ablaufen würden, wäre die Gefahr, ein falsches Ergebnis zu bekommen, zu hoch, als das die Geschwindigkeit von Vorteil wäre. Insbesondere bei gleichzeitigen Zugriffen ist auch die Auslastung des Servers wichtig. Wenn dieser bereits mit einer Schreiboperation ausgelastet ist, ist ein Zusammenbruch bei vielen Zugriffen bereits vorprogrammiert. Daher ist die Speicher- und CPU-Auslastung während der Testphase immer im Auge zu behalten. 7584 5 Tests 5.1 Testsystem Das vorliegende Testsystem besteht aus drei Servern, die mit Infiniband, sowie Gigabit-Ethernet miteinander verbunden sind. Jeder Server besteht aus zwei Intel Xeon X5500 CPU s mit 4x2.6GHz und 48GB Arbeitsspeicher. Als Datenträger kommen pro Server 1TB Festplatten der Marke Samsung zum Einsatz. Diese Festplatten verfügen über einen SATA2-Anschluss, drehen mit 5400 Umdrehungen pro Minute und verfügen über 8MB Cache. Laut Testberichten  erreicht die Festplatte im Lesemodus eine maximale Geschwindigkeit von 110MByte/s, im Durchschnitt liegt die Leseperformance bei 85MByte/s. Die maximale Schreibrate war geringfügig langsamer, im Durchschnitt liegt diese bei 83MByte/s. Für den Metadatenserver wurden zwei solcher Festplatten zu einem RAID-0-Verbund zusammengefasst. Das bietet einen zusätzlichen Geschwindigkeitsvorteil, allerdings sind bei einem möglichen Ausfall einer Festplatte die gesamten Metadaten unbrauchbar. Für einen produktiven Einsatz ist diese Kombination nicht zu empfehlen, da sollte zusätzlich auf eine Sicherung auf dieser Ebene geachtet werden, als Beispiel wäre ein Raid-10-Verbund zu nennen, welches die gleichen Geschwindigkeiten anbietet und zusätzlich eine Sicherung der Daten durchführt. Für die Durchführung der Tests ist nicht von einem Defekt der Hardware auszugehen, daher kommt die Konstellation mit einem RAID-0 Verbund zum Einsatz. Die beiden weiteren Server werden jeweils mit einer 1TB Festplatte installiert. Nach Rücksprache mit den Nutzern des aktuellen kleineren Clusters werden die Dateigrößen entsprechend angepasst. Die laufenden Programme erzeugen häufig Dateien, die im Größenbereich von 128KByte bis 100MByte liegen. Selten werden Bereiche von über 1GByte überschritten. Die Ergebnisse der Programme werden wiederrum in das Dateisystem geschrieben, diese übersteigen aber zum aktuellen Zeitpunkt nicht die 1GByte-Grenze, sodass eine Performancemessung mit Dateien, die größer als 2GB sind, für das Universitätsrechenzentrum nicht von Bedeutung sind. Dabei ist sowohl die Lese-, als auch Schreibgeschwindigkeit von Interesse. Die komplexen Berechnungen werden auf dem Compute-Cluster ausgeführt, die jeweils lesende und schreibende Zugriffe auf die Festplatten durchführen. Die Ergebnisse werden anschließend in eine bestimmte Datei geschrieben. Nach weiteren Durchläufen können die Programme entweder neue Dateien schreiben oder die Ergebnisse an die vorhandene Datei anfügen. 7685 5 Tests Die durchgeführten Tests werden jeweils als One-Node- und Two-Node-Installation durchgeführt. Dies geschieht, damit eine mögliche Skalierbarkeit durch das Hinzufügen eines zusätzlichen Storageservers erkennbar gemacht wird. Abbildung 5.1: Aufbau des Testsystems 7786 5 Tests 5.2 Durchgeführte Tests Auf der vorhandenen Testumgebung werden mit Hilfe des Programmes Iozone verschiedene Testverfahren durchgeführt, die zur Performancemessung, sowie zur Validierung der Systemstabilität genutzt werden. Dieses Benchmarking-Tool wurde in der Programmiersprache C geschrieben, generiert gewünschte Dateigrößen und misst sowohl die Lese- als auch die Schreibrate im Dateisystem. Im "Parallel File System Survey Reportäus dem Jahr 2010  ist zudem zu entnehmen, dass Iozone am häufigsten verwendet wird, da dieses viele Möglichkeiten bietet, die Performance eines Parallelen Dateisystems messen zu können. Die Messungen und Methoden sind mittlerweile sehr umfangreich geworden, daher sind diese in verschiedene Szenarien unterteilt. Als Ergebnis erhält der Anwender eine Auswertung der einzelnen Testfälle entweder direkt auf der Konsole oder in einem speziellen Excel-Format, um diese grafisch auswerten zu können. Das Tool wurde ausgewählt, weil es international Anerkennung in allen größeren Rechenzentren gefunden hat und die Individualisierung auf die persönlichen Bedürfnisse und die nahezu perfekte Auswertungsmöglichkeit eine sehr gute Übersicht über die Gesamtperformance eines parallel verteilten Dateisystems gibt. Write-Mode In diesem Modus wird eine Datei erzeugt, die eine gewünschte Größe besitzt und unterschiedlich fragmentiert ist. Diese wird anschließend in das Dateisystem übertragen, dabei wird die Geschwidigkeit der Erstellung der Datei, sowie der Erstellung der Metadaten gemessen. Bei einer großen Datei, die in viele kleine Pakete unterteilt ist, sind die Metadaten entsprechend groß, wenn ein Dateisystem diese einzeln abspeichert. Um das zu verhindern, verwenden einige verteilte Dateisysteme sogenannte Ëxtents", die das Zusammenfassen von bestimmte Bereichen ermöglichen. Dieser Testmodus zeigt auf, ob dies funktioniert oder die Datenverwaltung entsprechend größer wird, da die Schreibgeschwindigkeit abnehmen sollte. Re-Write-Mode Mit Hilfe dieses Testszenarios wird eine Datei, die bereits existiert, erneut übertragen. Bei intelligenten Systemen sollte dieses schneller verlaufen, da sich die Metadaten nicht ändern und daher dieser Overhead nicht geschrieben werden muss. Read-Mode Die zuvor geschriebene Datei wird anschließend aus dem Dateisystem heraus gelesen, sodass man die Lesegeschwindigkeit messen kann. Dabei ist enscheidend, wie schnell die Zuordnung von Metadaten und der eigentlichen Datei gefunden werden kann, sodass eine Übertragung durchgeführt wird. Es ist auch zu 7887 5 Tests erwarten, dass die Geschwidigkeit zunimmt, wenn die Datei verteilt auf mehreren Servern liegt, die parallel arbeiten. Re-Read-Mode In diesem Modus wird eine Datei erneut gelesen. Ziel ist es, dass die Performance ansteigen sollte, da sich die Daten noch im Cache des Dateisystems befinden sollte und somit nicht erneut gesucht und eingelesen werden müssen. Random-Read-Mode Eine bereits zuvor geschriebene Datei wird in diesem Modus an unterschiedlichen Stellen gelesen. Insbesondere für verteilte Dateisysteme ist dies ein sehr wichtiger Test für die Performance. In größeren Ausführungen wird eine Datei verteilt auf mehrere Festplatten und Servern abgelegt. Wenn nur ein bestimmter Bereich der Datei angefordert wird, muss dieser entsprechend aus den Metadaten gefunden werden und angefordert werden. Dabei spielt die Anzahl der Server und Festplatten, sowie die Größe des Caches des Systems eine entscheidene Rolle. Random-Write-Mode Analog zum Random-Read-Mode führt dieser Änderungen an bestimmten Stellen einer Datei aus. Dabei wird diese nicht vollständig neu übertragen, sondern die Änderungen werden verschickt und das Dateisystem muss diese an den entsprechenden Stellen verändern. Random-Mix-Mode Dieser Modus ist eine Kombination aus Random-Read- und Random-Write-Modus. Durch die parallele Ausführung von Lese- und Schreibanfragen wird die Performance des Systems aufgezeigt, da auch hierbei nur bestimmte Teile einer Datei angefordert und abgespeichert werden. Backwards-Read-Mode In diesem Modus wird eine Datei, die zuvor im System abgelegt wurde, rückwärts gelesen. Die Möglichkeit, dass so ein Fall effektiv eintreten kann, ist im produktiven Einsatz zwar eher selten, allerdings nicht unmöglich. Insbesondere wenn eine Datei mit Messdaten erstellt wurde und die aktuellsten immer ans Ende der Datei geschrieben wurde und diese zunächst wichtig sind, kann eine Datei rückwärts übertragen werden, da die wichtigen Bereiche als erstes verschickt werden. Dateisysteme sind häufig nicht für einen solchen Lesemodus ausgelegt, wenn eine Datei angefordert wird, wird diese immer vorwärts übertragen, bzw. bei verteilten Dateisystemen werden die einzelnen Objekte vorwärts übertragen. Um dieses zu bewerkstelligen, müssen die Anfragen entsprechend häufig gestellt werden, damit ein Rückwärtslesen möglich gemacht wird. Das Ergebnis der Performancemessung gibt 7988 5 Tests zusätzlichen Aufschluss darüber, wie das System auch mit vielen Anfragen umgehen kann. Fwrite/Fread-Mode Ähnlich zum Write- und Read-Mode wird eine Datei mit einer bestimmten Größe und Fragmentierung erstellt. Allerdings unterscheiden sich diese Modi dadurch, dass die Bibliothek fwrite() genutzt wird. Diese führt zwischengespeicherte Schreiboperationen durch. Dieser Zwischenspeicher sollte im Arbeitsspeichers des Client-Computers liegen. Insbesondere bei großen Dateien, die stark fragmentiert sind, kann ein Zwischenspeicher diese zusammenfassen und gebündelt übertragen. Dadurch werden die Systemaufrufe reduziert und die Übertragung kann schneller durchgeführt werden. Durch diesen Modus werden sogenannte "Jumbo-Framesërzeugt, die gebündelt übertragen werden. Frewrite/Freread-Mode Auch dieser Modus führt eine erneute Lese- bzw. Schreiboperation einer bereits existierenden Datei durch. Diese sollte zu einem Performanceanstieg führen, da die Metadaten zwar übertragen aber nicht mehr ausgewertet werden müssen, wenn sich die Datei nicht verändert hat. Beim Lesevorgang ist die Größe des verfügbaren Caches für die Geschwindigkeit wichtig, da erhofft wird, dass sich die Datei noch im Zwischenspeicher befindet. Mmap Die Funktion mmap() adressiert eine bestimmte Datei aus einem Dateisystem in den Arbeitsspeicher des Empfängers. Anschließend wird die Datei zunächst in den Arbeitsspeicher übertragen, dieses System wird von vielen Programmen genutzt, um mögliche benötigte Dateien bereits im Hintergrund laden zu können, damit die Zugriffszeit verringert werden kann. Um diese Dateien als solche zu identifizieren, werden diese mit bestimmten Flags versehen, die häufigsten sind MS_SYNC und MS_ASYNC. In der vorliegenden Konfiguration werden die Dateisysteme im Automatik-Modus getestet. Dieser führt insgesamt 13 Tests automatisiert durch. Aufgerufen wird das Programm mit der Angabe des Pfades, wo das Dateisystem eingehangen ist und der Angabe der gewünschten Obergrenze der Datei. Zusätzlich können die Ergebnisse in einer Datei abgelegt werden, die anschließend grafisch ausgewertet werden können. Ein Beispiel für einen solchen Aufruf lautet:./iozone f/mnt/fhgfs/test Raboutput.wks g2g 8089 5 Tests Abbildung 5.2: Iozone Aufzeichnung eines Testdurchlaufes Dieser Aufruf führt den automatischen Test durch ( -a ), im Verzeichnis /mnt/f hgf s/test ( -f ) und gibt die Ergebnisse in der Datei output.wks ( -Rb ) aus. Das Verzeichnis ist optional anzugeben, es ist auch möglich, iozone direkt in das Verzeichnis zu kopieren und von dort zu starten. Im vorliegenden Beispiel wurde auf dem Client das Fraunhofer Filesystem in diesem Verzeichnis gemounted. Durch die Einstellung g kann man angeben, welche Größe die maximal getesteten Dateien haben sollen. Wenn diese nicht angegeben wurde, liegt die maximale Größe bei 512MB, welche in der heutigen Zeit nicht mehr zeitgemäß sind, da der Arbeitsspeicher heutzutage wesentlich größer ist und somit eine sehr genaue Betrachtung der einzelnen Testergebnisse nicht transparent ist. Das Tool bietet noch zusätzliche Einstellungsmöglichkeiten und Parameter an, die angepasst werden können. Durch die Auswahl der unterschiedlichen Dateigrößen ist dieses für den vorliegenden Testfall allerdings nicht weiter nötig, da sowohl die I/O-Performance bei sehr kleinen Dateien, als auch bei sehr großen Dateien mit entsprechender Fragmentierung überprüft wird. Somit wird ein sehr guter Überblick über die möglichen Übertragungsraten gegeben. 8190 Testauswertung Kapitel 6 Nach der Ausführung der unterschiedlichen Testszenarien folgt eine entsprechende Auswertung der Ergebnisse. Diese sind zunächst unterteilt in die verschiedenen vorausgesetzten Anforderungen des Universitätsrechenzentrums. Insbesondere die Punkte Skalierbarkeit und Performance können mit Messergebnissen verdeutlicht werden. Stabilität ist ein sehr wichtiger Punkt, welcher in der heutigen Zeit elementar ist. Allerdings gibt es für diesen Testpunkt keine explizite Möglichkeit, diese zu überprüfen. Die Verwaltbarkeit ist ein subjektiver Aspekt, welcher bei der Installation der unterschiedlichen Dateisysteme aufgefallen ist und in diesem Punkt betrachtet wird. 6.1 Performance Performance ist in Clusterverbunden das wichtigste Kriterium, worin sich die Dateisysteme unterscheiden könnten, sodass die Entscheidungsfindung maßgeblich beeinflusst wird. Versprochen wird von jedem Hersteller die höchstmögliche Performance, in der Realität unterscheiden sich diese aber oftmals sehr stark. Insbesondere der Unterschied zwischen Lese- und Schreibgeschwindigkeiten, sowie die Zugriffszeiten sind dabei teilweise eklatant groß. Dabei existieren große Unterschiede bei unterschiedlichen Dateigrößen und deren unterschiedliche Fragmentierung. Eine 1GB große Datei, die in 4KByte große Blöcke unterteilt wird, benötigt normalerweise Einträge im Metadatenserver. Diese können zunächst schnell abgelegt werden, allerdings bei Dateisystemen, die mit sehr vielen besonders kleinen Daten umgehen müssen, ist das Auffinden der Metadaten häufig der Flaschenhals. Jeder Hersteller von parallelen Dateisystemen arbeitet dabei mit unterschiedlichen Ansätzen, diese zu vereinheitlichen und so die Geschwindigkeit zu erhöhen. Ziel ist es, dass die Fragmentierung keine Unterschiede darstellt, ob das Dateisystem mit vielen oder wenigen Daten umgehen muss. 8291 6 Testauswertung Lese- und Schreibgeschwindigkeiten mit iozone Iozone ist ein Tool, mit dessen Hilfe die Lese- und Schreibgeschwindigkeiten eines Dateisystems untersucht werden können. Dabei werden unterschiedliche Dateigrößen mit unterschiedlichen Chunkgrößen betrachtet. Das Ergebnis sollte möglichst eine einheitliche Geschwindigkeitsdarstellung aufzeigen, ohne das die Dateigröße und Fragmentierung dabei eine Rolle spielt. Insbesondere bei verteilten Dateisystemen, wo Metadatenserver und Storageserver von einander getrennt sind, ist dies nur mit sehr viel Aufwand zu bewerkstelligen. Eine Datei von 128KByte Größe, welche in einem Chunk gespeichert werden kann, ist theoretisch schneller abzulegen, als eine 128GByte große Datei, die in 128Kbyte Chunks aufgeteilt wird. In diesem Test wird die reine Lese- und Schreibgeschwindigkeit gemessen und ausgewertet FhGFS Das Fraunhofer Institut wirbt mit der hohen Performance und der sehr guten Skalierbarkeit ihres Dateisystems. Im vorliegenden Testfall wird zunächst die Installation des Management-, Metadaten- und Storageservers auf einem einzigen Clusterknoten ausgeführt. Der Client ist ein weiterer Knoten, welcher über ein Gigabit-Netzwerkswitch und Infiniband mit dem Hauptknoten verbunden ist. Außerdem steht ein weiterer Knoten zur Verfügung, der einen weiteren Datenserver zur Verfügung stellt und im weiteren Testfall Metadaten- und Storageserver darstellt. Somit werden die alle möglichen verfügbaren Konstellationen im Testfall behandelt. One-Node-Installation mit Ethernetinterface Bei der Installation aller Server auf einem Cluster-Knoten wird erwartet, dass die Geschwindigkeit sich kaum von einem regulären Dateisystem unterscheidet, da eine direkte Verteilung der Daten nicht möglich ist, lediglich die Unterscheidung zwischen Meta- und Storagedaten stellt einen Unterschied dar. Auf einem weiteren Knoten wird mit Hilfe des zur Verfügung stehendem Clients das Netzlaufwerk gemounted. Der Test mit iozone zeigt die Lese- und Schreibgeschwindigkeiten von Dateigrößen zwischen 512Kbyte und 4GByte an, die auf dem Netzlaufwerk gespeichert werden. Diese werden in unterschiedlichen Chunkgrößen gemessen, zwischen 4KByte und 16MByte. Ab einer Dateigröße von 32MByte wird ab einer Chunkgröße von 64KByte gemessen. Dabei werden alle verfügbaren Tests des Programmes angeschaltet. 8392 6 Testauswertung Zunächst wird ein Testlauf mit diesen Werten durchlaufen, wobei das Infiniband ausgeschaltet ist und nur die Gigabit-Netzwerkschnittstelle zur Verfügung steht. Das resultierende Ergebnis zeigt auf, dass die Transferraten zwischen 95MByte und 105MByte pro Sekunde liegen, sowohl im Lese- als auch Schreibmodus. Die Gigabit-Netzwerkschnittstelle stellt eine theroetische maximale Transferrate von 125MByte/s zur Verfügung, daher ist anzunehmen, dass die Netzwerkschnittstelle der begrenzende Faktor ist. Abbildung 6.1: FhGFS - One-Node-Installation per Gigabit-Ethernet Two-Node-Installation mit Ethernetinterface Im zweiten Testfall wird ein zusätzlicher Knoten des Clusters als weiterer Storageserver hinzugeschaltet. Dadurch soll aufgezeigt werden, dass die Daten möglichst gleichmäßig verteilt werden. Durch die unterschiedliche Größe der verfügbaren Festplatten ist eine direkte Verteilung nicht möglich, da auf dem weiteren Storageserver lediglich 50% der Festplattenkapazität zur Verfügung stehen. Auch das Hinzuschalten eines zweiten Storageservers, sodass eine Verteilung der Daten erfolgt, zeigte bei der Nutzung des Ethernetinterfaces keine Unterschiede. Es ist also davon auszugehen, dass die Netzwerkkarte die maximale Geschwindigkeit von 1000Mbit/s ausreizen kann, diese aber als begrenzender Faktor für die Performancemessung des Dateisystems anzusehen ist. Mit Hilfe der grafischen Auswertungsmöglichkeiten, die von der grafischen Oberfläche angeboten werden, ist eine maximale Transferrate von durchschnittlich 105MByte/s zu erkennen, wenn nur ein Storageserver hinterlegt ist, bei zwei verfügbaren Knoten erkennt man sehr gut, 8493 6 Testauswertung dass die Verteilung der Daten gleichmäßig auf beide Server erfolgt, diese allerdings nur mit jeweils 55MByte/s lesen und schreiben können. Die Verteilung funktioniert also einwandfrei, lediglich die Übertragungsrate begrenzt die Geschwindigkeit. Abbildung 6.2: FhGFS - Lastverteilung FhGFS-Admin-Übersicht 8594 6 Testauswertung Um den Flaschenhals der begrenzten Netzwerkhardware auszuschalten, wurde in weiteren Testdurchläufen das Infiniband auf allen Knoten eingerichtet und aktiviert. Das Fraunhofer Dateisystem erkennt automatisch, dass dieses nun zur Verfügung steht und versucht von nun an, den Datenverkehr über diese Schnittstelle zu regeln. Das Abschalten der Ethernetverbindung ist dabei nicht nötig, diese dient als Failover, wenn das Infiniband nicht zur Verfügung steht. Diese Hardware bietet eine theoretische Geschwindigkeit von 12GBit/s an, sodass diese eine mehr als Verzehnfachung der eigentlichen Geschwindigkeit darstellt. In den folgenden Testdurchläufen ist auch eine wesentliche Erhöhung der Geschwindigkeit zu erkennen, allerdings liegen diese Werte weit unter der möglichen Übertragungsrate von Infiniband, sodass dieser Flaschenhals nicht mehr exisitert. 8695 6 Testauswertung One-Node-Installation mit Infiniband Die weitere Netzwerkschnittstelle soll dafür sorgen, dass die korrekte Performance des Systems gemessen werden kann. Die Erwartungshaltung ist dementsprechend so, dass die Lese- und Schreibgeschwindigkeit sich auf dem Niveau befindet, die die vorhandene Hardware bietet. Im vorhandenen Cluster arbeiten zwei Standard-2,5 -Festplatten in einem RAID-0 Verbund, welcher über einen zusätzlichen RAID-Controller bewerkstelligt wird. Die Geschwindigkeit liegt dabei bei durchschnittlich MByte/s im Lese- und Schreibmodus. Abbildung 6.3: Schreibgeschwindigkeit mit einem Knoten - Auswertung Wie zu erwarten war liegt die Schreibperformance im absoluten Oberlimit der möglichen Geschwindigkeit der Hardware. Im Durchschnitt liegt die Geschwindigkeit bei 180MByte/s. Dabei ist ein Anstieg der Geschwindigkeit bei größeren Chunks zu 8796 6 Testauswertung erkennen. Größere Dateien mit kleinen Chunks müssen häufig den Metadatenserver ansprechen, welcher Teil der Datei wo auf dem Server gespeichert werden soll. Dies kann allerdings nicht als Performanceeinbußen gemessen werden, denn die Hardware stellt keine höheren Transferraten zur Verfügung. Es ist somit ein weiterer Flaschenhals auszumachen, der nur durch schnellere Festplatten ausgemerzt werden kann, allerdings ist dies im vorliegenden Testfall nicht möglich. Insbesondere kleine Dateien können auch kaum gemessen werden, weil diese sich häufig noch im Zwischencache der Festplatten befinden und entsprechend schnell gelesen werden können, daher wurden Dateien, die kleiner als 512Kbyte sind, nicht in die Bewertung mit einbezogen. Abbildung 6.4: Lesegeschwindigkeit mit einem Knoten - Auswertung 8897 6 Testauswertung Auch bei der Lesegeschwindigkeit sind keine Überraschungen aufgetreten. Auch hier liegt die durchschnittliche Geschwindigkeit bei etwa 180MByte/s. Dieser Wert kommt zu Stande, weil kleinere Chunkgrößen mit MByte/s gelesen werden, größere Chunks mit bis zu 215MByte/s. Auch hier ist das gleiche Phänomen zu erkennen wie beim Schreibtest. Die maximale Performance der vorhandenen Hardware ist hier der begrenzende Faktor, welcher keine höheren Datenübertragungsraten ermöglicht. Die Performance des Dateisystems hat bei dieser Konstellation alle Erwartungen erfüllen können, auch die Performance bei großen Dateien mit sehr kleinen Chunkgrößen ist entsprechend als sehr gut zu betrachten, weil die Performance nur durch die gegebene Hardware begrenzt wird. Dies führt dazu, dass davon auszugehen ist, dass beim Hinzufügen eines weiteren Servers als Datenserver die Performance steigen sollte, weil eine Verteilung der Daten erfolgt und somit höhere Übertragungsgeschwindigkeiten erreicht werden können. 8998 6 Testauswertung Two-Node-Installation mit Infiniband Die Erwartungshaltung bei der Verteilung der Daten ist im Vergleich zu der One-Node-Installation so, dass die Performance sich möglichst verdoppelt, da nun zwei Server parallel angesprochen werden können. Bei mehreren Testdurchläufen ist eine Erhöhung der Datenübertragungsrate zu erkennen, allerdings liegt diese etwas unter der Erwartungshaltung. Dies ist dadurch zu erklären, dass bei dem weiteren Server nicht die gleiche Performance zu erwarten ist, weil dort nur eine einzelne Festplatte eingebaut wurde, die nicht so hohe Datenübertragungsraten bietet, wie im Hauptknoten. Die Schreibperformance bei der One-Node-Installation lag im Durchschnitt bei 180MByte/s, die interne Festplatte hat durchschnittlich eine Übertragungsrate von MByte/s, daher ist eine Performance von MByte/s zu erwarten. Abbildung 6.5: Schreibgeschwindigkeit mit zwei Knoten - Auswertung Das Ergebnis des durchgeführten Tests zeigt auf, dass auch hier die maximale Performance beider Server erreicht werden konnte. Durchschnittlich lag die Schreibgeschwindigkeit bei 260MByte/s. Dies sind genau die Werte, die von der Hardware maximal zur Verfügung gestellt werden können. Die Auslastung beider Server ist somit erreicht. Auch hier ist zu erkennen, dass ein Anstieg der Geschwindigkeit bei größeren Chunks erfolgt. Während bei 4KByte großen Fragmenten 9099 6 Testauswertung die durchschnittliche Schreibrate bei 240MByte/s lag, wurde bei einer Größe von 2048KByte die maximale Rate von 275,47MByte/s gemessen. Dies ist eine signifikante Änderung der Übertragungsgeschwindigkeit, was darauf schließen lässt, dass das Dateisystem mit größeren Chunks besser umgehen kann. Diese können auch für kleinere Dateien eingesetzt werden, weil diese mit weniger Metadaten geschrieben werden müssen. Abbildung 6.6: Lesegeschwindigkeit mit zwei Knoten - Auswertung Die Leseperformance lag bereits im vorigen Test mit einem Server höher als die Schreibgeschwindigkeit. Es wird erwartet, dass sich im Durchschnitt die Geschwindigkeit des One-Node-Tests multipliziert mit dem Faktor 1,5 ergibt, da sich im zweiten Server lediglich eine statt zwei Festplatten befindet. Daraus ergibt sich ein Erwartungswert von 320MByte/s. Nach der Durchführung des Tests zeigt sich deutlich, dass auch dieses Ergebnis erreicht werden konnte. Während Dateien mit kleinen Chunkgrößen mit MByte/s gelesen werden konnten, wurde die maximale Rate von 361MByte/s mit einer Größe von 256KByte erreicht, durchschnittlich liegt die Lesegeschwindigkeit bei 320MByte/s. Die Ergebnisse zeigen auf, dass auch in diesem Fall die maximale 91100 6 Testauswertung Performance der Server erreicht wurde und das Dateisystem mit größeren Datenraten umgehen kann. Die grafische Oberfläche, welche bereitgestellt wird, zeigt auf, dass die Daten auf beiden Servern gleichzeitig geschrieben werden, dass die Übertragungsgeschwindigkeit erreicht werden kann. Die Auslastung, welche während des Tests mit dem Befehl du sh auf beiden Knoten berechnet wurde, zeigt auch auf, dass die Daten auf 1MByte exakt genau aufgeteilt werden, sodass die Performance so stark verbessert werden konnte. Als Ergebnis der Performancemessung des Fraunhofer Dateisystems zeigt auf, dass die Begrenzung der Geschwindigkeit nicht am Dateisystem, sondern an der Performance der Hardware liegt. Dies ist damit zu begründen, dass für die Testzwecke Standard-Festplatten im 2,5Format und 5400U/min verbaut wurden. Diese sind für einen reinen Servereinsatz nicht konzipiert und bieten nicht die Übertragungsraten an, die Hochleistungsfestplatten mit SAS-Anschluss ( Serial Attached Storage ) und U/min anbieten können. Damit wäre eine weitere Verbesserung der Lese- und Schreibraten möglich. Auch das Thema der Skalierbarkeit wurde im Test aufgezeigt, dass die Geschwindigkeiten sich soweit verbessert haben, wie es die Performance einzelner Server zulässt. Durch das Hinzuschalten weiterer Datenserver und die Möglichkeit, die Metadaten aufzuteilen führt dazu, dass die Performance beim neuen Compute-Cluster des Universitätsrechenzentrums wesentlich verbessert werden wird und somit das Dateisystem eine sehr gute Wahl im Punkt Performance darstellt. 92101 6 Testauswertung Abbildung 6.7: FhGFS - Two-Node-Installation per Infiniband 93102 6 Testauswertung MooseFS Während der Betrachtung über die Arbeitsweise von MooseFS ist aufgefallen, dass das gesamte System sehr durchdacht ist und eine hohe Performance bieten könnte. Die Geschwindigkeiten wurden zunächst mit einem Master-, einem Storageserver und einem Client durchgeführt. Anschließend erfolgte eine Messung, indem ein weiterer Storageserver hinzugeschaltet wurde. Die Erwartungshaltung war so, dass die Geschwindigkeit möglichst die Grundperformance der genutzten Festplatten ausreizen konnte, sowie die Verbesserung, wenn ein weiterer Server hinzugeschaltet wird. Aufgrund der Begrenzung von Gigabit-Ethernet und der fehlenden Unterstützung von Infiniband, wurde IPoIB genutzt. Das bedeutet, dass einzelne Server mit einer IP-Adresse über Infiniband angesprochen werden können. Dieses erreicht nicht die volle theroetische Geschwindigkeit von 12GBit/s, im vorliegenden Testsystem wird eine maximale Übertragungsrate von 1-1,5Gbit/s erreicht. MooseFS bietet die Möglichkeit, dass Storageserver als Replikationsserver eingesetzt werden können. Die Geschwindigkeit wird dabei abnehmen, denn die Bestätigung, dass die Daten korrekt geschrieben wurden, erreicht den Client erst dann, wenn die Daten korrekt auf alle Server übertragen wurde. Dies würde das Ergebnis im Vergleich zum Fraunhofer Filesystem verändern, da dieses keine Replikationsmöglichkeiten anbietet. Performance mit einem Storageserver Die Auswertung der Testergebnisse ist sehr enttäuschend. Während FhGFS mit der Installation des Metadaten- und Storageservers auf einem einzelnen Knoten dessen maximale Performance erreichen konnte, bricht die Geschwindigkeit bei MooseFS stark ein. Aus den Testergebnissen ist zu entnehmen, dass die Schreibgeschwindigkeit unabhängig 94103 6 Testauswertung Abbildung 6.8: MooseFS - Schreibgeschwindigkeit mit einem Storageserver von der Chunkgröße zwischen 10 und 20MByte/s liegt. Dieses Ergebnis liegt weit entfernt von der theoretischen Leistung. Da der Storageserver auf dem Knoten mit nur einer Festplatte installiert wurde, liegt die theroetische Geschwindigkeit bei MByte/s. Besonders der Umstand, dass die Geschwindigkeit bei Dateigrößen über 512MByte weiter einbricht, zeigt, dass das System mit den Dateigrößen nur bedingt umgehen kann. Die Geschwindigkeit liegt dabei teilweise unter 10Mbyte/s, welches selbst mit einem 100Mbit-Ethernetinterface erreicht werden könnte. Dieses Ergebnis ist absolut inakzeptabel für das Universitätsrechenzentrums, daher wurde die Leseperformance nicht weiter getestet. Performance mit zwei Storageservern Nach den enttäuschenden Ergebnissen des Dateisystems mit einem einzelnen Storageserver ist die Erwartungshaltung entsprechend gering, dass sich die Performance beim Hinzufügen eines weiteren Storageservers weiter verbessern könnte. In der Tat ist die Geschwindigkeit überhaupt nicht angestiegen, sodass es zu keinen Geschwindigkeitsänderungen kam. 95104 6 Testauswertung Abbildung 6.9: MooseFS - Schreibgeschwindigkeit mit zwei Storageserver Wie auch die Ergebnisse der Testdurchläufe mit einem Storageserver sind auch diese Werte mehr als enttäuschend. Hier sticht lediglich der Testbereich mit einer Chunkgröße von 8KByte heraus, dort werden Werte von 50-70MByte/s erreicht. Ansonsten liegen die Werte wieder im Bereich von 5-15MByte/s. Diese Werte sind absolut inakzeptabel, daher wurde auch hier auf einen Test der Lesegeschwindigkeit verzichtet. MooseFS zeigt im internen Aufbau sehr gute Eigenschaften auf, die auf eine gute Performance schließen lassen könnten. Allerdings sind in der Realität die Werte so schlecht, dass der Test abgebrochen wurde und das Dateisystem nicht weiter zur Auswahl steht. Der Einbruch eines verteilten Dateisystems, insbesondere bei Dateigrößen ab 256MByte, auf solch niedrige Werte ist absolut inakzeptabel. Daher werden die Werte zwar erwähnt, allerdings steht dieses System nicht mehr zur Auswahl für das Universitätsrechenzentrum. 96105 6 Testauswertung GlusterFS Anders als die bereits vorgestellten Dateisysteme verfolgt GlusterFS eine andere Herangehensweise an den grundsätzlichen Aufbau und der Verteilung der Daten. Es erfolgt keine Aufteilung zwischen Metadaten und den eigentlichen Daten, sondern diese werden zentral pro Server abgelegt. Der Hauptknoten stellt somit automatisch auch seine verfügbaren Festplattenkapazitäten als Storageserver zur Verfügung. Die einzelnen Server müssen im Client bekannt gemacht werden, sodass bereits auf Clientseite eine Verteilung der Daten stattfinden kann. Es ist kein zusätzlicher Metadatenserver nötig. Die Installation von GlusterFS wurde daher mit einem Server und einem Client durchgeführt. Anschließend wurde ein zweiter Knoten hinzugeschaltet, welcher auch im Client bekannt gemacht wurde. Die Verteilung der Daten erfolgte somit automatisch, ohne dass größere Umstrukturierungen durchgeführt werden mussten. Es muss dabei darauf geachtet werden, dass der Client selbst keine Kapazitäten zur Verfügung stellt, dieses muss in den Konfigurationsdateien entsprechend ausgespart werden. Aufgrund der Limitierung der Geschwindigkeit des Gigabit-Ethernet-Interface wurde direkt Infiniband eingerichtet, sodass dieser Flaschenhals nicht zu verfälschten Ergebnissen führen kann. One-Node-Installation Die Installation von GlusterFS ist rein auf Kommandozeilen beschränkt worden. Es existiert keine grafische Oberfläche. Auch die Installationsanweisung und die Dokumentation auf der offiziellen Homepage sind nicht vollständig. Die Bekanntgabe der einzelnen Storageserver und Clients ist nicht beschrieben worden. Diese sind für den funktionierenden Betrieb allerdings elementar. Bei der One-Node-Installation wurde der Hauptknoten des vorhandenen Clusters, welcher mit zwei Standard-2,5 -Festplatten im RAID-0-Modus ausgestattet ist, als Storageserver ausgewählt. Der Client bietet keine zusätzliche Speicherkapazität an, sodass eine Verbindung nur auf einem Server gegeben ist. 97106 6 Testauswertung Abbildung 6.10: GlusterFS - Schreibperformance mit einem Knoten Die Schreibgeschwindigkeit von GlusterFS liegt im Durchschnitt bei ca. 135MByte/s. Dies liegt unterhalb der möglichen Geschwindigkeit, die von der Hardware zur Verfügung gestellt wird. Insbesondere der Umgang mit besonders kleinen Chunkgrößen stellt GlusterFS vor größeren Herausforderungen, die Geschwindigkeit liegt deutlich unter der von größeren Chunks. Die Geschwindigkeitseinbußen kommen hauptsächlich vom Schreiben von Dateien die Kleiner als 4096KByte sind. Dabei ist allerdings zu beachten, dass die exakte Bestimmung der Geschwindigkeit aufgrund der sehr schnellen Bearbeitung kaum möglich ist, die Werte dienen lediglich als Richtwerte. Die Performance steigt auch mit zunehmender Dateigröße an, dort ist eine exaktere Bestimmung der Geschwindigkeit möglich. Diese liegt im Durchschnitt bei 160MByte/s, welches eher der maximal möglichen Performance des Systems entspricht. 98107 6 Testauswertung Abbildung 6.11: GlusterFS - Leseperformance mit einem Knoten Die Leseperformance zeigt eine deutlich gleichmäßigere Performance. Sowohl bei kleinen, als auch bei großen Chunkgrößen beträgt der Unterschied maximal 10MByte/s. Auch hier ist zu erkennen, dass große Dateien schneller übertragen werden konnten, als sehr kleine. Grundsätzlich liegt die Leseperformance mit einem Storageknoten im Durchschnitt bei 150MByte/s. Bei großen Dateien ist bei Chunkgrößen von 32 und 64KByte zu erkennen, dass die Geschwindigkeit auf über 170MByte/s anwächst, dies ist in etwa die Performance, die die Hardware erreichen kann. Im Vergleich zu MooseFS und FhGFS liegt dieses Dateisystem im Mittelfeld. Die Geschwindigkeit sowohl im Lese- als auch im Schreibmodus ist für die vorhandene Hardware als gut anzusehen, allerdings liegt die Performance von FhGFS noch ein wenig höher und kann somit die Hardware noch besser ausnutzen. Die Performance von MooseFS ist dagegen sehr schlecht und kann sich nur ganz weit unten positionieren. 99108 6 Testauswertung Two-Node-Installation Aufgrund des Aufbaus von GlusterFS ist ein Anstieg der Geschwindigkeit im Lesen und Schreiben einzelner Dateien nicht zu erwarten. Durch den veränderten Aufbau wird eine einzelne Datei lediglich auf einem Knoten abgespeichert. Selbst beim Hinzufügen zusätzlicher Storageserver ist ein Anstieg beim Lesen und Schreiben einer einzelnen Datei nicht zu erwarten. Abbildung 6.12: GlusterFS - Schreibperformance mit zwei Knoten In der Abbildung 6.12 ist zu erkennen, dass sich die Schreibperformance gegenüber dem vorherigen Ergebnis mit einem Knoten nicht verändert hat. Die Geschwindigkeit liegt im Durchschnitt bei 135MByte/s. Auch hier ist eine Zunahme der Geschwindigkeit bei größeren Dateien unabhängig von der Chunkgröße zu erkennen, insbesondere bei kleinen Chunkgrößen ist die Schreibgeschwindigkeit fast doppelt so hoch. Dies scheint daran zu liegen, dass Geschwindigkeit sehr hoch ist und die Zeit, um die Datei zu übertragen, so gering, dass geringste Abweichungen schon zu einem großen Unterschied führen. Bei besonders großen Dateien liegt die durchschnittliche 100109 6 Testauswertung Schreibrate bei 165MByte/s. Es ist also auch hier ein Unterschied bei kleineren und sehr großen Chunkgrößen zu erkennen. Um die möglichst optimale Schreibperformance zu erhalten, sollte daher eine Chunkgröße zwischen 128 und 1024KByte gewählt werden. Abbildung 6.13: GlusterFS - Leseperformance mit zwei Knoten Im Gegensatz zur Schreibrate hat sich die Geschwindigkeit beim Lesen leicht erhöht. Der Durchschnitt liegt hier bei ca. 190MByte/s. Dies ist die maximale Performance, die vom Hauptknoten zur Verfügung gestellt wird. Die Unterschiede in den verschiedenen Lesegeschwindigkeiten sind allerdings auch höher. Daraus kann man erkennen, dass die Daten verteilt wurden und auch der zweite Storageserver benutzt wurde. Dieser bietet lediglich Transferraten von maximal 100MByte/s an, welche mit einigen Dateien auch erreicht wurden. 101110 6 Testauswertung Die Performancemessung mit zwei verschiedenen Knoten ist beim Aufbau von GlusterFS sehr schwierig, da immer eine einzelne Datei auf einem einzelnen Knoten abgelegt wird. Die Geschwindigkeit kann daher mit diesen Testverfahren nicht korrekt ermittelt werden. Insgesamt bietet GlusterFS ein durchschnittliches Ergebnis an. Während FhGFS die Daten verteilt auf mehrere Server speichern kann und damit sowohl einen Schreib- als auch Lesegeschwindigkeitsvorteil erhält, so kommt es bei GlusterFS nur zu einer Verteilung bei der Nutzung vieler Dateien. Erst dann kann die Geschwindigkeit stark ansteigen. Trotzdem ist GlusterFS im vorliegenden Testfall immer schneller als MooseFS. Beide bieten die Möglichkeit von Replikationen an Zusammenfassung Performance Zusammenfassend im Punkt Performance ist eindeutig zu erkennen, dass FhGFS die höchste Geschwindigkeit anbietet. GlusterFS ist aufgrund der Arbeitsweise nicht in der Lage die Geschwindigkeit zu erhöhen, weil im vorliegenden Testfeld immer nur eine Datei geschrieben wird, es ist allerdings noch schneller als MooseFS. Die Performance von diesem System ist absolut inakzeptabel, sodass dieses für das Universitätsrechenzentrum nicht weiter zur Auswahl steht. 102111 6 Testauswertung 6.2 Stabilität Damit aussagekräftige Ergebnisse zu dem Thema Stabilität von Dateisystemen gemacht werden können, müssen verschiedene Punkte beachtet werden. Stabilität bedeutet, dass das Dateisystem zum einen stets erreichbar ist, dass die einzelnen Serverkomponenten keine internen Fehler zum Vorschein bringen und dass die gespeicherten Daten zu jeder Zeit verfügbar sind. Stabilität im Fehlerfall ist ebenfalls ein sehr wichtiges Thema, da insbesondere bei Clustersystemen viel Hardware verbaut wird und diese dementsprechend wahrscheinlicher für einzelne Ausfälle gegenüber Einzelservern sind. Ein Dateisystem gilt als stabil, wenn die gespeicherten Daten zu jeder Zeit verfügbar sind und wenn im Falle eines Ausfalls einzelner Komponenten diese auch weiterhin zur Verfügung stehen FhGFS Das Fraunhofer Filesystem zeichnete sich im Testfeld als zunächst sehr stabil aus. Es kam zu keiner Zeit zu Ausfällen der einzelnen Serverkomponenten, sodass die Stabilität softwareseitig gegeben ist. Im Testszenario wurden Dauertests mit gleichzeitigen Leseund Schreibzugriffen über 72 Stunden durchgeführt. Dabei kam es zu keiner Zeit zu einem Fehler. Auch die Geschwindigkeit trotz hoher Datenmengen und hoher Anzahl an Metadateneinträgen wurde nicht beeinträchtigt. Allerdings fehlt dem Dateisystem die Möglichkeit von Replikationen. Es besteht lediglich der Grundansatz, dass ein Administrator zu bestimmten Zeiten kleinere Snapshots einzelner Festplatten durchführen kann, bei einem abrupten Ausfall einzelner Komponenten kommt es allerdings unweigerlich zu Datenverlusten, bzw. zu Systemausfällen, wo bestimmte Dateien nicht zur Verfügung stehen. FhGFS verändert das interne Dateisystem von einzelnen Knoten im Cluster nicht, sodass Festplattenfehler mit Hilfe von anderen Hilfsmitteln, wie zum Beispiel bestimmte RAID-Konfigurationen, abgefangen werden und somit der Datenverlust verhindert werden kann. Allerdings bietet das Dateisystem keine Möglichkeit, automatische Replikationen anzufertigen. 103112 6 Testauswertung Abbildung 6.14: FhGFS - Lasttest über 72 Stunden Das keine Fehler bei einem Lasttest auftreten, ist bei einem verteilten Dateisystem elementar wichtig. Dieses Feature konnte das Fraunhofer Dateisystem erfüllen, sodass dieser Punkt positiv zu rechnen ist für die Entscheidungsfindung des Universitätsrechenzentrums für die Auswahl des Dateisystems. 104113 6 Testauswertung MooseFS MooseFS wird als ein sehr ausfallsicheres und stabiles Dateisystem angepriesen. In der vorgegebenen Testkonfiguration wurde ein Dauertest durchgeführt, welcher aufzeigen sollte, ob es zu Fehlern kommt. Dieser wurde allerdings nach 24 Stunden abgebrochen, weil die Performance für die gegebenen Verhältnisse zu schlecht war, als das das Thema Stabilität noch eine Rolle spielen würde. Innerhalb der 24 Stunden konnten keine Fehler festgestellt werden, sodass zumindest für einen kurzen Zeitraum das Dateisystem als stabil anzusehen ist. Dies ist jedoch weniger aussagekräftig, weil der Test kurzfristig abgebrochen wurde GlusterFS Im vorliegenden Testfeld wurde ein GlusterFS Dateisystem mit 2 Servern und einem Client aufgebaut. Der Client führte einen Dauertest von 72 Stunden durch. Dafür wurde das Testprogramm iozone fünfmalig ausgeführt. Dieses führte sowohl Lese- als auch Schreiboperationen durch. GlusterFS zeigte sich als sehr stabiles Dateisystem, welches zu keiner Zeit Fehler aufzeichnete. Dieses wäre von iozone bemerkt worden. Zusätzlich ist durch die Möglichkeit der Selbstrekonfiguration die Möglichkeit gegeben, dass ein Weiterarbeiten möglich ist, auch im Falle eines Defektes eines Serverknotens. Während des Lasttests wurde der zusätzliche Storageserver vom Netzwerk getrennt, sodass dieser nicht mehr zur Verfügung stand. Die Geschwindigkeit ist dann kurzzeitig eingebrochen, allerdings waren keine Fehler zu erkennen. GlusterFS ist ein sehr ausgereiftes und stabiles Dateisystem, welches durch die automatische Rekonfiguration es ermöglicht, trotz Hardwareausfällen weiter zu arbeiten Zusammenfassung Stabilität Zusammenfassend ist zu erkennen, dass alle Dateisysteme zum aktuellen Zeitpunkt sehr stabil sind. Dies wird durch die weite Verbreitung von GlusterFS und FhGFS unterstützt, auch der Einsatz von MooseFS ist laut Berichten sehr zuverlässig. Für den Punkt Sicherheit ist GlusterFS am besten geeignet, da es durch die Replikationsmöglichkeiten, sowie die automatische Rekonfiguration es ermöglicht, dass 105114 6 Testauswertung es trotz Hardwareausfällen zu keiner Störung des laufenden Betriebes kommen kann. Auch MooseFS bietet diese Möglichkeiten an, allerdings ist wurde auf ein Lasttest verzichtet, da die Grundperformance nicht gegeben ist und das System nicht mehr zur Auswahl steht. FhGFS bietet ein sehr stabiles Dateisystem an, allerdings sind keine Möglichkeiten gegeben, dass das System auch nach einzelnen Hardwareausfällen weiter funktioniert. Die Möglichkeiten der Sicherung von Metadaten- und Storageservern ist zwar gegeben, müssen aber manuell vom Administrator geplegt werden. Die Sicherung besteht hauptsächlich auf Festplattenebene durch verschiedene RAID-Konfigurationen. Diese können allerdings auch bei anderen Dateisystemen eingesetzt werden. Dadurch, dass das Universitätsrechenzentrum einen Compute-Cluster hauptsächlich für wissenschaftliche Berechnungen benutzen wird, ist auf den Punkt Stabilität relativ viel Wert zu legen. Wenn ein Knoten zwischenzeitlich ausfällt, kann es passieren, dass beim Einsatz von FhGFS die gesamten Berechnungen erneut durchgeführt werden müssen, da die Ergebnisse verloren sind. Die kurzzeitigen Ausfälle könnten allerdings im laufenden Betrieb in Kauf genommen werden, da die Performance höher liegt. Rein für den Punkt Stabilität wird eine Empfehlung für GlusterFS gegeben. 106115 6 Testauswertung 6.3 Skalierbarkeit Das Thema Skalierbarkeit tritt insbesondere in großen High-Performance-Computing -Clusterverbunden auf. Durch das Hinzufügen zusätzlicher Hardware wird erwartet, eine möglichst lineare Skalierbarkeit zu erreichen. Dieses muss vom Dateisystem auch möglich gemacht werden. In der aktuellen Testkonstellation stehen dafür zwei Server zur Verfügung, die als Storageserver dienen. Um eine mögliche Skalierbarkeit aufzuzeigen, werden die gleichen Testverfahren zunächst mit einem Storageserver durchgeführt, bei einem weiteren Durchlauf wird der zweite hinzugeschaltet, sodass eine Erhöhung der Lese- und Schreibperformance zu erkennen sein sollte. Die Daten sollen verteilt auf die einzelnen Server geschrieben werden, um Skalierbarkeit zu erreichen FhGFS Das Thema Skalierbarkeit ist ein großes Aushängeschild in der Werbung des Fraunhofer Dateisystems. Es verspricht massive Skalierbarkeit unabhängig von der Hardware. Der Punkt, dass die Metadaten- und Storageserver in jeder Umgebung eingerichtet werden können und dass diese auch gleichzeitig auf einem Clusterserver laufen können, machen das System sehr flexibel einsetzbar. Bei der Einrichtung mehrerer Metadatenserver ist es vom Fraunhofer Institut so eingerichtet worden, dass ein Server immer als Hauptserver angesprochen wird und dieser selbstständig die Daten verteilt. Der Test mit Hilfe von iozone wurde zunächst auf einem Knoten, der Management-, Metadaten- und Storageserver in einem war, durchgeführt. Der Client wurde anschließend auf einem weiteren Knoten installiert. Die beiden Knoten wurden mit Infiniband verbunden, sodass der Flaschenhals der Gigabit-Netzwerkkarten nicht zum Vorschein kam. Um eine Skalierbarkeit erkennen zu können, wurde ein weiterer Knoten als Storageserver hinzugefügt, sodass die Verteilung der Daten auf zwei Servern durchgeführt werden konnte. One-Node-Installation Bei der Einrichtung des Dateisystems auf einem Knoten sind Lese- und Schreibgeschwindigkeiten zu erwarten, die sich nur gering vom normalen Dateisystem unterscheiden. In dem vorliegenden Testfall wurde das Programm iozone im Lese- und Schreibmodus durchgeführt, jeweils von Dateigrößen von 512KByte bis 4GByte. Der Vorteil dieses Test liegt darin, dass die geschriebenen Daten durch 107116 6 Testauswertung anschließendes Lesen überprüft werden. Installiert wurde das System auf zwei Standard-SATA2-Festplatten im 2,5 -Format, die durch einen RAID-Controller in einem RAID-0-Verbund zusammenarbeiten. Das hat Geschwindigkeitsvorteile, da bereits hier eine direkte Verteilung der Daten auf beide Festplatten von statten geht. Die normale Lese- und Schreibgeschwindigkeit der Festplatten in diesem Verbund liegt bei durchschnittlich 180MByte/s. Abbildung 6.15: FhGFS - Schreibgeschwindigkeit mit einem Knoten - Diagramm Die Schreibgeschwindigkeit wurde gemessen für unterschiedliche Dateigrößen mit unterschiedlicher Fragmentierung. Insbesondere Dateien mit großen Chunks wurden schneller geschrieben, als viele kleinere Dateien. Dies war auch zu erwarten, da die Anzahl der Metadateneinträge bei besonders kleinen Dateifragmenten zunimmt. Im Durchschnitt wurden Dateien mit besonders kleinen Chunkgrößen mit MByte/s geschrieben, Dateien mit angepasster Chunkgröße konnten mit etwa MByte/s geschrieben werden. Bei der Lesegeschwindigkeit verhält es sich sehr ähnlich. Die im Test zuvor geschriebenen Daten werden sofort vom Programm wieder ausgelesen, um die Performance messen zu können. Als Ergebnis ist wiederum eine Geschwindigkeit zu 108117 6 Testauswertung erwarten, die bei durchschnittlich 180MByte/s liegen sollte. Abbildung 6.16: FhGFS - Lesegeschwindigkeit mit einem Knoten - Diagramm Die Lesegeschwindigkeit weicht nur unwesentlich von der Schreibgeschwindigkeit ab, allerdings ist zu erkennen, dass die Performance bei größeren Chunks sich kaum noch verändert. Überschreiten diese die Größe von 1MByte/s ist kein Anstieg mehr zu erkennen. Dies lässt darauf schließen, dass die Metadaten bei solchen Größen stets zusammengefasst werden und die Geschwindigkeit somit nicht mehr veränderbar ist. Bei kleineren Chunkgrößen liegt die Lesegeschwindigkeit bei MByte/s, ab einer Größe von 1Mbyte liegt diese konsequent im Durchschnitt bei 210MByte/s. Diese Ergebnisse zeigen auf, dass die Lesegeschwindigkeit höher liegt als die Schreibgeschwindigkeit und die maximale Performance der vorhandenenen Hardware erreicht ist. Two-Node-Installation Beim Hinzuschalten eines weiteren Storageservers ist eine direkte Verteilung der Daten gegeben. Für eine optimale Skalierbarkeit wäre ein linearer Anstieg der Geschwindigkeit perfekt und in der Realität gewünscht, allerdings kann diese kaum erreicht werden, da andere Faktoren, wie die Übertragung der einzelnen Daten auf andere Server und die Berechnung der Chunkgrößen eine Rolle spielen, die eine Linearität nicht ermöglichen. 109118 6 Testauswertung Wenn eine solche lineare Skalierbarkeit erreicht werden würde, müssten die Schreibgeschwindigkeiten im Durchschnitt bei MByte/s liegen. Die Erwartungshaltung ist dementsprechend, dass die Geschwindigkeit im Durchschnitt 300MByte/s erreichen sollte, dann gilt das System als sehr gut skalierbar, dieser Wert entspricht 90% der optimalen Performance. Abbildung 6.17: FhGFS - Schreibgeschwindigkeit mit zwei Knoten - Diagramm Die Schreibgeschwindigkeit liegt im Durchschnitt bei 260MByte/s. Dabei ist zu erkennen, dass die Geschwindigkeit zwar stark erhöht, allerdings bleibt diese unter den Erwartungen zurück. Wenn man dazu betrachtet, dass der zweite Server lediglich mit einer einzigen 2,5 -Festplatte ausgerüstet wurde, die maximal eine Geschwindigkeit von 80MByte/s erreichen kann, ist dieses Ergebnis trotzdem sehr beachtlich. Denn die Geschwindigkeiten dieser magnetischen Festplatten verhindern, dass sich die Geschwindigkeit verdoppeln kann. Das zeigt sich auch in dem Punkt, dass die Chunkgrößen insbesondere bei größeren Dateien kaum noch Unterschiede aufzeigen, bis auf einige Ausreißer. Dass die Geschwindigkeit höher liegen kann, zeigt sich in der Dateigröße von 1GByte und der 110119 6 Testauswertung Chunkgröße von 512KByte. Die gemessene Geschwindigkeit lag bei 320MByte/s. Bei performanterer Hardware ist also eine bessere Skalierbarkeit zu erwarten. Bei der Lesegeschwindigkeit verhält es sich etwas anders. Wie schon bei der One-Node-Installation liegt diese höher als die Schreibgeschwindigkeit. Dies ist auf die verbaute Hardware zurückzuführen, dass Leseoperationen schneller durchgeführt werden als Schreibzugriffe. Abbildung 6.18: FhGFS - Lesegeschwindigkeit mit zwei Knoten - Diagramm Die Lesegeschwindigkeit liegt im Durchschnitt bei 320MByte/s. Auch hier exisiteren insbesondere bei kleinen Dateien mit kleiner Chunkgröße starke Ausreißer nach oben und unten. Bei einer Chunkgröße von 1024KByte schwankt die Messung zwischen 236MByte/s und 480MByte/s, dabei ist gerade der maximale Wert bei sehr kleinen Dateigrößen gemessen worden. Die Geschwindigkeit liegt im Durchschnitt bei der maximalen Performance der vorhandenen Hardware, sodass zwar keine prozentuale Aussage darüber getroffen werden kann, ob das System gut skalierbar ist, allerdings ist ein großer Anstieg von Lese- und Schreibgeschwindigkeiten bei allen Chunkgrößen zu erkennen. Es ist davon auszugehen, dass die Geschwindigkeiten bei schnelleren Festplatten auch diese 111120 6 Testauswertung entsprechend ausreizen kann. Das Fraunhofer Dateisystem zeigt also im vorliegenden Testfall eine sehr gute Skalierbarkeit. Das Ergebnis stellt einen maßgeblichen Anteil an der Entscheidungsfindung dar, welches Dateisystem auf dem neuen Compute-Cluster benutzt werden soll. Der Punkt der Skalierbarkeit ist mit der Performance darum so elementar wichtig, weil der neue Rechnerverbund auf mehreren hundert Knoten bestehen wird und daher die Möglichkeit gegeben sein muss, dass die Geschwindigkeit möglichst linear ansteigt, wenn neue Knoten hinzugeschaltet werden. In dem durchgeführten Testfall ist dies zumindest in diesem Ausmaß mit dem FhGFS absolut möglich. 112121 6 Testauswertung MooseFS Das Hauptaugenmerk von MooseFS wurde auf Sicherheit und Verfügbarkeit der gespeicherten Daten gelegt. Dies ist auch bei den Testergebnissen über die Skalierbarkeit zu erkennen. Die Performance des Dateisystems ist im Vergleich zum Fraunhofer Dateisystem als mieserabel anzusehen. Abbildung 6.19: MooseFS - Schreibgeschwindigkeit mit einem Storageserver Die Ergebnisse zeigen auf, dass die Geschwindigkeit sich generell auf einem sehr niedrigen Niveau befindet. Mit einem Storageserver ist zudem zu erkennen, dass es bei Dateigrößen zwischen 1 und 64MByte kaum Unterschiede macht, mit welchen Chunkgrößen diese Dateien übertragen wurden. Bei höheren Dateigrößen ist zudem meist ein Abfall der Geschwindigkeit zu erkennen, lediglich die Geschwindigkeit bei einer Dateigröße von 256MByte und einer Chunkgröße von 2048KByte ist ein Ausreißer zu erkennen, der anstelle von durchschnittlich 15-20Mbyte/s ca. 38Mbyte/s erreichen konnte. 113122 6 Testauswertung Abbildung 6.20: MooseFS - Schreibgeschwindigkeit mit zwei Storageservern Um eine möglichst optimale Skalierbarkeit erkennen zu können, müssten die Schreibraten bei dem Hinzufügen eines weiteren Storageservers wenigstens mit dem Faktor 2 multipliziert werden können, das bedeutet eine Geschwindigkeit von durchschnittlich 35-40Mbyte/s. Im Ergebnis ist zu erkennen, dass die Geschwindigkeit sich insbesondere bei größeren Dateien sich sogar verschlechtert hat. Die Übertragungsgeschwindigkeit von Dateien zwischen 1Mbyte und 128MByte liegt durchschnittlich bei 16Mbyte/s, welches vergleichbar ist mit der Performance von MooseFS mit einem Storageserver. Aufgrund der sehr schlechten Ergebnisse wurde auf eine Messung der Skalierbarkeit im Lesemodus verzichtet, weil die Geschwindigkeit völlig inakzeptabel ist. MooseFS zeigt auch bei dem sehr wichtigen Punkt Skalierbarkeit eine schlechte Performance. Die Geschwindigkeit konnte durch das Hinzuschalten eines weiteren Servers nicht gesteigert werden, bei größeren Dateien ist diese sogar noch geringer. Es kann hiermit keine Empfehlung für den Einsatz auf dem neuen Compute-Cluster des Universitätsrechenzentrums gegeben werden. 114123 6 Testauswertung GlusterFS GlusterFS wirbt mit sehr guter Skalierbarkeit. Durch den grundlegenden Aufbau, dass jede Datei vollständig auf einem Server vorhanden ist, wird deutlich, dass bei bestimmten Konstellationen eine Skalierung nicht stattfinden kann. Abbildung 6.21: GlusterFS - Schreibgeschwindigkeit mit einem Storageserver Die Schreibgeschwindigkeit mit einem Knoten liegt bei durchschnittlich 135MByte/s. Dabei erhöht sich die Geschwindigkeit mit Zunahme der Dateigröße. Bei der Auswahl der Chunkgröße ist die beste Performance bei 256 bis 1024KByte gegeben. Der Testdurchlauf mit Hilfe von iozone führt Schreibtests mit durch, indem eine Datei mit einer bestimmten Größe und Fragmentierung geschrieben wird. Diese wird auf jeweils einen vorhandenen Storageserver geschrieben. Eine Skalierung kann daher nicht stattfinden. 115124 6 Testauswertung Abbildung 6.22: GlusterFS - Schreibgeschwindigkeit mit zwei Storageservern Die grundlegende Geschwindigkeit beim Schreiben hat sich nicht verändert. Es ist zu erkennen, dass einige Ausreißer nach unten existieren, es ist dadurch zu erklären, dass der zweite Storageserver eine geringere Performance besitzt als der erste. Dies liegt daran, dass dieser mit nur einer Festplatte ausgestattet ist. Wie in Abbildung 6.23 zu erkennen ist, verändert sich erwartungsgemäß die Leseperformance von GlusterFS im vorliegenden Testfall auch nicht durch das Hinzufügen eines weiteren Storageservers. Die Leseperformance von GlusterFS mit einem Storageserver liegt auf dem Niveau der vorhandenen Hardware. Ein weiterer Anstieg der Geschwindigkeit ist nicht zu ermöglichen. Beim Zuschalten eines weiteren Storageservers ist kein Anstieg der Geschwindigkeit zu erwarten, eher ein Einbruch bei einzelnen Werte aufgrund der Verteilung auf unterschiedliche Hardware sollte zu erkennen sein. 116125 6 Testauswertung Abbildung 6.23: GlusterFS - Lesegeschwindigkeit mit einem Storageserver In Abbildung 6.24 ist die Leseperformance von GlusterFS mit zwei Storageservern aufgezeichnet. Die erwarteten Einbrüche bei einzelnen Testdurchläufen sind eindeutig zu erkennen. Der Grund dafür liegt in der Verteilung der Daten auf unterschiedliche Server. Während der erste Server zwei Festplatten im RAID-0-Verbund aufweisen kann und damit eine direkte Verteilung der Daten, beinhaltet der zweite Server nur eine Festplatte. Die Geschwindigkeitseinbußen sind daher vom zweiten Server zu erklären, der eine maximale Lesegeschwindigkeit von ca. 100MByte/s zur Verfügung stellt. Im vorliegenden Testfall konnte eine Verteilung der Daten zwar nachgewiesen werden, allerdings ist keine Skalierung erkennbar. Grund dafür ist der Aufbau von GlusterFS. Während andere verteilte Dateisysteme die einzelnen Dateien in Objekte zerlegen und diese unterschiedlich auf alle verfügbaren Storageserver aufteilen, speichert GlusterFS die gesamte Datei auf einem Server ab. Die Verteilung erfolgt erst, wenn mehrere Dateien zum Einsatz kommen. Das System ist für diesen Anwendungsfall nicht skalierbar, allerdings beim praktischen Einsatz, wo immer meherere Dateien erzeugt werden, erfolgt eine Verteilung und somit eine Erhöhung der Arbeitsgeschwindigkeit. 117126 6 Testauswertung Abbildung 6.24: GlusterFS - Lesegeschwindigkeit mit zwei Storageservern Zusammenfassung Skalierbarkeit Skalierung bedeutet, dass beim Hinzufügen mehrerer Storageserver die Lese- und Schreibgeschwindigkeit möglichst linear zunehmen sollte. Im durchgeführten Test konnte dies nur das Fraunhofer Dateisystem aufzeigen. Die maximale Performance von beiden vorhandenen Storageservern konnte erreicht werden, sodass eine Linearität zu erkennen war. MooseFS zeigte bereits im Schreibmodus sehr schlechte Ergebnisse, die sogar zu einer Verschlechterung bei großen Dateien beim verteilten Schreiben geführt haben. Der Test wurde daher abgebrochen und der Lesemodus nicht weiter untersucht. GlusterFS konnte mit dem durchgeführten Testfall auch keine Skalierung aufweisen. Das ist damit zu begründen, dass die Dateien generell auf einem Server geschrieben werden. Die Verteilung der Daten konnte besonders im Lesemodus erkannt werden, sodass angenommen werden kann, dass in der praktischen Anwendung, wo generell mehrere Dateien verwendet werden, eine Skalierung erfolgen kann. 118127 6 Testauswertung 6.4 Verwaltbarkeit Die Verwaltung von parallelen verteilten Dateisystemen ist ein großer Bestandteil des Testfeldes. Das Universitätsrechenzentrum benötigt ein System, welches möglichst leicht zu konfigurieren ist, sodass Erweiterungen im Nachhinein gut einzupflegen sind. Auch die administrativen Möglichkeiten müssen leicht verständlich sein, damit im Nachhinein die Verwaltung möglichst ohne großen Aufwand zu bewältigen ist. Viele Dateisysteme bieten dafür eine grafische Administrationsoberfläche an, die unterschiedliche Aufgaben bewältigen und anzeigen kann. Dafür ist der Vergleich hinsichtlich der Verwaltbarkeit nötig, um einen konkreten Überblick zu bekommen FhGFS Die Verwaltung des Fraunhofer Filesystems ist ein sehr gutes Beispiel, auf möglichst einfache Art ein sehr komplexes Programm administrieren zu können. Zum einen besteht die Möglichkeit, die Installationen und Überwachungsmethoden direkt auf der Konsole auszuführen. Die Pakete werden über ein spezielles Repository zur Verfügung gestellt oder direkt als Download angeboten. Für eine grafische Administration wird mit der Installation des Admon -Paketes eine Schnittstelle zwischen vorhandener JAVA-Anwendung und Management-Server hergestellt. Dieser ist sehr Ressourcenfreundlich, sodass eine Installation direkt auf dem Management-Server möglich ist und vom Fraunhofer Institut auch explizit angeboten wird. Hierbei ist allerdings zu beachten, dass die JAVA-Anwendung zwar betriebssystemunabhängig programmiert wurde, aber das Admon -Paket, wie alle verfügbaren Daten lediglich für Suse-, RedHat- und Debian-Distributionen und deren Derivate direkt zur Verfügung steht. Die Pakete sind nur in dem Punkt unterschiedlich, dass diese jeweils die betriebssysteminternen Paketmanager aufrufen. Eine Installation von FhGFS war auf einer Gentoo-Plattform nicht möglich, da bestimmte Pakete, die von einzelnen Servern vorausgesetzt werden, nicht verfügbar waren. 119128 6 Testauswertung Abbildung 6.25: Konfiguration FhGFS im Testfall Mit Hilfe der Administrationsoberfläche hat ein Nutzer die Möglichkeit, einen kompletten Überblick über die einzelnen Knoten zu bekommen, unterteilt in Metadaten- und Storageservern. Dabei wird eine direkte Anzeige der einzelnen Server gegeben, sowie einen gemeinsamen Überblick über alle verfügbaren. Außerdem besteht die Möglichkeit der automatisierten Installation neuer Knoten mit speziellen Anforderungen. Beim Hinzufügen neuer Server müssen diese lediglich über die Oberfläche bekannt gemacht werden und mit dem Befehl Install werden alle benötigten Pakete automatisch mit dem betriebssysteminternen Paketmanager heruntergeladen und installiert, sodass dieser nach kurzer Zeit verfügbar ist, ohne weiteres Zutun. Auch die Installation der Clients verläuft in diesem Fall problemlos und stellt keinen großen Aufwand für den Administrator dar. Durch diese Oberfläche wird auch angezeigt, ob bestimmte Knoten eventuell nicht zu erreichen sind. Zudem ist die automatische Benachrichtigung bei Fehlern per möglich, sodass automatisch Nachrichten verschickt werden, wenn es zu Problemen mit der Hardware kommt. 120 Mehr anzeigen\nT U M I N S T I T U T F Ü R I N F O R M A T I K. Franz Huber, Tobias Schröpf T E C H N I S C H E U N I V E R S I T Ä T M Ü N C H E N\nT U M I N S T I T U T F Ü R I N F O R M A T I K Hochverfügbarkeit für Linux Franz Huber, Tobias Schröpf TUM-I0828 August 08 T E C H N I S C H E U N I V E R S I T Ä T M Ü N C H E N TUM-INFO-08-I0828-0/1.-FI Mehr Cloud Computing. Seminararbeit im Studiengang M.Sc. IT-Management and Information Systems an der Fachhochschule der Wirtschaft (FHDW)\nSeminararbeit im Studiengang M.Sc. IT-Management and Information Systems an der Fachhochschule der Wirtschaft (FHDW) Cloud Computing Vorgelegt von: René Büst Prüfer: Prof. Dr. Wilhelm Nüsser Prof. Dr. Mehr Virtualisierung und Cloud Computing: Konzepte, Technologiestudie, Marktübersicht\nVirtualisierung und Cloud Computing: Konzepte, Technologiestudie, Marktübersicht Christoph Meinel, Christian Willems, Sebastian Roschke, Maxim Schnjakin Technische Berichte Nr. 44 des Hasso-Plattner-Instituts Mehr ERHÖHUNG DER FLEXIBILITÄT VON WORKFLOWS DURCH SERVICE MIGRATION\n- Studienarbeit ERHÖHUNG DER FLEXIBILITÄT VON WORKFLOWS DURCH SERVICE MIGRATION Sven Daxinger 19.10.2012 Betreuer: Prof. Dr. Paul Müller Dipl.-Inform. Tino Fleuren AG Integrierte Kommunikationssysteme Mehr Am Beispiel eines Debian Servers Mathias Maak\nAbsicherung von Serversystemen Am Beispiel eines Debian Servers Mathias Maak Praxisarbeit 4 Thema: Absicherung von Serversystemen Vorgelegt am: 01.02.2010 Studienbereich: Studienrichtung: Seminargruppe: Mehr - Backup & Restore - Konzepte, Strategien und Anwendungen von Einzelplatz bis Enterprise\nFachhochschule für Oekonomie & Management University of Applied Sciences Diplomarbeit zur Erlangung des Grads eines Diplom-Wirtschaftsinformatikers (FH) - Backup & Restore - Konzepte, Strategien und Anwendungen Mehr Terminal Server Sizing Guide\nTerminal Server Sizing Guide Ausgabe 4.0 Oktober 2009 Seiten 46 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur etabliert. Das vorliegende Mehr Betriebsinformatik-Projekt. Alternative Betriebssysteme\nBetriebsinformatik-Projekt Alternative Betriebssysteme Prof. Dr. Thorsten Spitta Dipl. Inform. Meik Teßmer Universität Bielefeld Fakultät für Wirtschaftswissenschaften Angewandte Informatik/Wirtschaftsinformatik Mehr Adaptives Scheduling für verteiltes Data Mining\nDiplomarbeit Adaptives Scheduling für verteiltes Data Mining Maxim Martens Diplomarbeit am Fachbereich Informatik der Universität Dortmund Dortmund, 14. November 2007 Betreuer: Prof. Dr. Katharina Morik Mehr URZ-BERICHTE. Studie zur Eignung von Windows NT für den Einsatz in Universitätsverwaltungen. (Bericht an die DFG)\nURZ-BERICHTE Studie zur Eignung von Windows NT für den Einsatz in Universitätsverwaltungen (Bericht an die DFG) Guido A. Hölting Email: guido.hoelting@rz.uni-ulm.de Oktober 1996 Universität Ulm Universitätsrechenzentrum Mehr Echtzeit-Betriebssysteme und -Bussysteme\nEchtzeit-Betriebssysteme und -Bussysteme Seminar im Wintersemester 2006/07 Steffen H. Prochnow Reinhard von Hanxleden Echtzeitsysteme und Eingebettete Systeme Institut für Informatik und Praktische Mathematik Mehr Universität Karlsruhe (TH) Fakultät für Informatik Institut für Theoretische Informatik. Diplomarbeit\nCloudRaid Ein sicherer Raid-Manager für freie Cloud Storages Bachelor-Thesis von Klaus Wilhelmi Sommersemester 2012 CloudRaid Ein sicherer Raid-Manager für freie Cloud Storages Vorgelegte Bachelor-Thesis Mehr Hochschule der Medien Stuttgart Fakultät Druck und Medien Computer Science and Media. Master-Thesis. Automatische Skalierung mit Amazon Webservices\nHochschule der Medien Stuttgart Fakultät Druck und Medien Computer Science and Media Master-Thesis Automatische Skalierung mit Amazon Webservices zur Erlangung des akademischen Grades Master of Science Mehr Cloud-Infrastrukturen\nUNIVERSITÄT LEIPZIG Institut für Informatik Abteilung Datenbanken Cloud-Infrastrukturen Seminararbeit Leipzig, 04.01.2010 vorgelegt von: Richard Beyer geb. am: 30.01.1981 Betreuer: Dr. Thor / Dipl. Ing. Mehr Ein erster Blick auf Windows Server 2012 R2 und Hyper-V\nEin erster Blick auf Windows Server 2012 R2 und Hyper-V Brien M. Posey Modern Data Protection Built for Virtualization Lange Zeit galt Windows Server als solide Serverplattform, doch in Bereichen wie der Mehr Lehrstuhl für Datenverarbeitung Prof. Dr.-Ing. Dr. E.h. Wolfgang Weber\nLehrstuhl für Datenverarbeitung Prof. Dr.-Ing. Dr. E.h. Wolfgang Weber Diplomarbeit 355 Entwurf und Realisierung eines Verfahrens zur optimierten Verteilung von Analyseprozessen in einem dezentralen Sicherheitskonzept Mehr Problemlose Migration auf Citrix Presentation Server 4.5 - Whitepaper\nProblemlose Migration auf Citrix Presentation Server 4.5 - Whitepaper www.visionapp.com Inhalt 1 Einleitung... 3 2 Neue und erweiterte Funktionen des Citrix Presentation Server 4.5... 3 2.1 Seit Citrix Mehr DIPLOMARBEIT. Problemmanagement bei Softwareprodukten\nDIPLOMARBEIT zum Thema Problemmanagement bei Softwareprodukten Eingereicht von Christian GRÜBL Kennzahl J151 Matrikel-Nr.: 9851392 Wien, 2005-06-20 WIRTSCHAFTSUNIVERSITÄT WIEN DIPLOMARBEIT Titel der Diplomarbeit: Mehr Netzwerkmonitoring in einer dynamischen Umgebung\nFachbereich 4 Informatik Netzwerkmonitoring in einer dynamischen Umgebung Diplomarbeit zur Erlangung des Grades eines Diplom-Informatikers im Studiengang Computervisualistik vorgelegt von Sebastian Mitnacht Mehr Analogie eines Serverclusters mit dem neuen Virtualisierungstrend Cloud Computing\nAnalogie eines Serverclusters mit dem neuen Virtualisierungstrend Cloud Computing Im Praxistest mit Magento Quelle: Lustratus REPAMA Bachelorarbeit Thema: Analogie eines Serverclusters mit dem neuen Virtualisierungstrend Mehr DPC. Clusterlösungen. für Windows-NT/2000. Auf Nummer Sicher\nAuf Nummer Sicher Cluster-Systeme sind mittlerweile in großer Zahl und Vielfalt auf dem Markt. So gibt es neben Lösungen, die ein breites Spektrum von Einsatzgebieten abdecken auch einige sehr auf spezielle Mehr Funktionsweise Beschreibung des Active Directory\n3 Funktionsweise und Beschreibung des Active Directory Nachdem Sie in den vergangenen Kapiteln einen Einblick in die Funktionsweise des Verzeichnisdienstes sowie die Vorteile von Active Directory gegenüber Mehr Seminar IT-Sicherheit - Sicherheit und Vertrauen in Cloud Computing\nFAKULTÄT FÜR INFORMATIK Seminar IT-Sicherheit - Sicherheit und Vertrauen in Cloud Computing Prof. Dr. Udo Helmbrecht Michael Kretzschmar Volker Eiseler (Hrsg.) Institut für Technische Informatik Bericht Mehr Hochschule für Technik, Wirtschaft und Kultur Leipzig Fakultät für Informatik, Mathematik und Naturwissenschaften. Projektarbeit\nHochschule für Technik, Wirtschaft und Kultur Leipzig Fakultät für Informatik, Mathematik und Naturwissenschaften Projektarbeit DAS NETZWERKDATEISYSTEM NFS FUNKTION UND SPEZIFIKATION EINES NETZWERKDATEISYSTEMS Mehr Entwerfen der Virtualisierung\n387 K A P I T E L 8 Entwerfen der Virtualisierung Von allen neuen Technologien, die in Windows Server 2008 eingeführt und in Windows Server 2008 R2 fortgeführt oder verbessert wurden, haben nur wenige Mehr Datenbanken II. Ausarbeitung zum Thema: Oracle 10g und MS SQL Server 2005 ein Vergleich. Thomas Wächtler MatrNr.: 39221\nDatenbanken II Ausarbeitung zum Thema: Oracle 10g und MS SQL Server 2005 ein Vergleich Thomas Wächtler MatrNr.: 39221 Inhaltsverzeichnis 0. Einführung 1. Komponenten 2. Architektur des SQL Server 2005 Mehr Hochschule Bonn-Rhein-Sieg University of Applied Sciences. Fachbereich Informatik Department of Computer Science. Master Thesis\nHochschule Bonn-Rhein-Sieg University of Applied Sciences Fachbereich Informatik Department of Computer Science Master Thesis im Studiengang Master of Science in Computer Science Vergleich paralleler Programmieransätze Mehr Designstudie für Hochverfügbarkeit und Lastausgleich bei Firewalls\nDesignstudie für Hochverfügbarkeit und Lastausgleich bei Firewalls am Beispiel von Gibraltar MAGISTERARBEIT zur Erlangung des akademischen Grades Diplom-Ingenieur in der Studienrichtung INFORMATIK Eingereicht Mehr e-journal of Practical Business Research\ne-journal of Practical Business Research Amazon EC2 von Julius Ollesch, Dirk Schweim, Michael Aydemir, Maria Ehrhardt und Marcel Hansch Erschienen im e-journal of Practical Business Research unter: http://www.e-journal-of-pbr.info Mehr 2016 © DocPlayer.org Datenschutzbestimmungen | Nutzungsbedingungen | Feedback