Gluster FS. 100 Linux Technical Review, Ausgabe 03

Transkript

1 Gluster FS Multimedia-Content ist im Internet seit langem auf dem Vormarsch. Eine Konsequenz dieser Entwicklung betrifft Kapazität und Verfügbarkeit der Storage-Ressourcen von Webservern, die immer größere Datenmengen ausfallsicher speichern und schnell ausliefern müssen. Dafür und für viele vergleichbare Fälle diskutiert dieser Beitrag eine hoch verfügbare, performante und dabei kostengünstige Alternative. Julian Hein 100 Linux Technical Review, Ausgabe 03

2 Websites wie Flickr oder Youtube haben multimedialen Content im Internet zum endgültigen Durchbruch verholfen. Auch die immer populäreren Social Networking Sites wie Myspace oder StayFriends erlauben ihren Usern den Upload eigener Bilder. Daneben verbreiten sich Videos und Bilder auch über zahlreiche weniger prominente Seiten. Beispielsweise bieten viele Web- Shops inzwischen hochauflösende Abbildungen, manchmal aus mehreren Perspektiven. Gerade diese Kombination von User Generated Content und Multimedia führt zu einem exponentiellen Datenwachstum. Rechnet man jetzt noch den Trend zu immer mehr Megapixeln bei den Digitalkameras und HD-Auflösung bei Videos hinzu, wird schnell klar, dass die Storage- Systeme vieler Websites vor neuen Herausforderungen stehen: Neben dem hohen Bedarf an Speicherplatz, müssen die sie ihre Inhalte auch hochverfügbar vorhalten und natürlich sehr performant an die User ausliefern. Technologien wie Clustering, Loadbalancing und High Availability ermöglichen es Datenbanken und Webservern längst fast unbegrenzt zu skalieren. Im Storage-Bereich sieht es da leider noch nicht so gut aus. Die Standardantwort lautet hier SAN oder NAS, aber diese Technologien führen meist schnell zu exorbitanten Kosten. Vor allem, wenn aufgrund der geforderten Hochverfügbarkeit viele teure SAN- und Fibre- Channel-Komponenten mehrfach anzuschaffen sind. Zwar bieten die Systeme eine gute Performance, aber es gibt kaum Skalierungsoptionen mit denen ein sie in den nächsten Jahren etwa um das Fünffache wachsen könnte. Genau diesem Dilemma begegnet GlusterFS [1], indem es das Cluster-Prinzip in den Storage-Bereich portiert und aus mehreren unabhängigen Storage-Servern, so genannten Bricks, einen großen Storage-Cluster schafft. Vorteile von GlusterFS Natürlich existieren längst die unterschiedlichsten Möglichkeiten, ein großes und performantes Storage-System aufzubauen. Beispiele sind die schon genannten Storage Area Networks auf Basis von iscsi- oder Fibre-Channel-Technologie, außerdem günstigere NAS-Systeme, bis hin zu Cluster-Filesystemen wie Lustre, Microsofts Distributed File System oder dem Andrew File System. Gegenüber diesen Alternativen zeichnet sich GlusterFS jedoch durch eine Reihe von bemerkenswertenvorteilen aus: Geringe Hardwarekosten: GlusterFS stellt keine besonderen Anforderungen an die Hardware, da kein teures SAN oder Fibre Channel benötigt wird. Es genügen normale Linux-Server, optimiert auf Speicherkapazität und I/ O-Performance. Die Netzwerkzugriffe erfolgen kostengünstig per Gigabit-Ethernet oder Infinniband. Natürlich sollte man trotzdem auf qualitativ hochwertige Festplatten und RAID-Controller achten, um die Performance und Ausfallsicherheit der Bricks und damit auch des Clusters zu erhöhen. Einfache Implementierung: Das gesamte System, also Clients und Server, ist im Userspace implementiert und erfordert daher keine Kernelmodifikationen. Besonders bei Updates spart das sehr viel Zeit und macht Wartung und Administration einfacher. Lineare Skalierbarkeit: Der Leistungszuwachs des Gesamtclusters, der durch einen weiteren Storage-Server zu erreichen ist, bleibt immer annähernd gleich, unabhängig davon, wie viele Server sich bereits im Cluster befinden. Im Gegensatz zu anderen Systemen nimmt der Verwaltungsaufwand für einen neuen Server im Gesamtverbund nicht zu. Diese Designeigenschaft von GlusterFS erlaubt es einen Storage-Cluster nahezu unendlich zu erweitern. Einfaches Backend: GlusterFS verwendet intern kein eigenes oder proprietäres Dateisystem, sondern speichert die Daten auf den Storage Bricks in einem normalem Dateisystem, also beispielsweise Ext3. Das vereinfacht Management und Überwachung gegenüber anderen Lösungen erheblich, da man die Daten sehr einfach sichern und wiederherstellen kann. Auch Servermigrationen bedeuten so nicht viel mehr als das Kopieren der Dateien auf einen neuen Server. Hohe Verfügbarkeit: GlusterFS benötigt keinen zentralen Metadaten- oder Katalogservice, sondern verteilt alle Daten und Informationen gemäß der Konfiguration in der Volume-Spezifikation über alle beteiligten Bricks. Einfache Konfiguration: Alle Erweiterungen der Grundfunktionalität realisiert GlusterFS durch so genannte Translators. Dadurch bleibt das System übersichtlich, flexibel und lässt sich sehr einfach um Zusatzfeatures erweitern, die Performance oder Verfügbarkeit verbessern. Linux Technical Review, Ausgabe

3 Nicht ganz verschweigen darf man, dass GlusterFS auch einige Nachteile gegenüber anderen Storage-Systemen hat. Der wichtigste ist, dass es bis jetzt noch keinen Mechanismus für eine automatische Resynchronisation bereitstellt. Nach dem Ausfall eines Storage-Servers muss der Admin den Ersatz-Server manuell mit den aktuellen Daten füllen. Im Prinzip kopiert er dazu den Inhalt eines Replikats per»rsync«auf den neuen Server. Eine der kommenden Versionen soll aber ein Feature enthalten, das diesen Schritt automatisiert. Aufbau und Bestandteile Zentrale Komponente von GlusterFS ist der Server»glusterfsd«. Er stellt den Clients die freigegebenen Volumes wie bei anderen Netzwerkdateisystemen etwa NFS zur Verfügung. Auf den Clients des Filesystems kommt der GlusterFS-Client»glusterfs«zum Einsatz. Er mounted die auf den Bricks freigegebenen Volumes. Zur einfacheren Administration kann er dafür nötige Konfigurationseinstellungen sogar von einem der Bricks abrufen. Listing 1: Konfiguration des AFR-Translators 01 ### Add client feature and attach to remote subvolume of server1 02 volume brick-master 03 type protocol/client 04 option transport-type tcp/client # for TCP/IP 05 option remote-host option remote-port 6996 # def. port is option remote-subvolume brick # emote volume ### Add client feature and attach to remote subvolume of brick1 11 volume brick-mirror 12 type protocol/client 13 option transport-type tcp/client 14 option remote-host # 15 option remote-port 6996 # def. port is option remote-subvolume brick # name ### Add replication to bricks 20 volume afr 21 type cluster/afr 22 subvolumes brick-master brick-mirror 23 option replicate *:2 # All files 2 copies (RAID-1) 24 Alle weiteren Funktionen, also auch beispielsweise die Netzwerkkommunikation, sind in GlusterFS als so genannte Translators implementiert. Dabei handelt es sich um Shared Objects die Server und Client zur Laufzeit entsprechend ihrer Konfiguration laden. Es gibt verschiedene Translators für Performanceverbesserungen, für Clustering und Load Balancing, für das Debugging, für zusätzliche Features und die Client-Server-Kommunikation. Die Volume-Spezifikation ist das Konfigurationsfile von GlusterFS, in ihr wird das Layout des Filesystems definiert. Jedes Volume in diesem Konfigurationsfile initialisiert einen entsprechenden Translator mit dessen spezifischen Konfigurationsoptionen. Durch die Flexibilität dieser Struktur kann man GlusterFS komplett an seine Bedürfnisse anpassen und es bleibt trotzdem übersichtlich und einfach zu managen. Translators Folgende Translator benötigt GlusterFS, um auf den Servern Verzeichnisse zu exportieren und über das Netzwerk freizugeben Posix Storage Translator: Dieser Translator verbindet das GlusterFS mit dem lokalen Filesystem, wie beispielsweise Ext3 oder XFS und definiert das Volume auf dem Brick: volume brick # POSIX FS translator type storage/posix # Export this directory option directory /home/export Server Protocol Translator: Der Server Translator gibt das im Storage Translator definierte Volumen über das Netzwerk frei: ### Add network serving capability to brick. volume server1 type protocol/server option transport-type tcp/server subvolumes brick option auth.ip.brick.allow Client Protocol Translator: Der Client Translator bindet das remote Volume des Storage Server wieder auf dem Client ein: ### Add client feature and attach to remote subvolume of server1 volume client1 type protocol/ client # for TCP/ IP transport option transport- 102 Linux Technical Review, Ausgabe 03

4 Schedulingoptionen Der Unify Translator verteilt die Dateien wie beschrieben auf verschiedene Volumes der beteiligten Bricks. Über die Scheduling-Option kann man dabei festlegen, nach welchem Mechanismus das geschehen soll. Hier hat ClusterFS gegenüber reinem Striping erhebliche Vorteile, denn es bietet nicht nur zufällige oder sequentielle Verteilung, sondern man kann die Daten auch nach der Auslastung der Bricks gewichtet verteilen. Diese Optionen sind verfügbar: Non-Uniform Filesystem Scheduler (»nufa«): Dieser Scheduler ist vor allem für Situationen gedacht, bei denen alle Maschinen im Cluster sowohl Server als auch Client des Filesystems sind, wenn also der Cluster neben dem Datenspeichern auch noch Rechenaufgaben hat. Da der Zugriff auf die lokalen Volumes immer schneller sein wird als der Remotezugriff via Ethernet, bevorzugt dieser Scheduler bei Schreiboperationen immer das lokale Volume und verwendet nur in Ausnahmefällen ein nicht-lokales Volume. Random Scheduler (»random«): Unabhängig von Auslastung oder Art der Dateien verteilt der Random Scheduler alle Schreibotype tcp/ client # IP address of the remote brick option remote-host # name of the remote volume option remote-subvolume brick Clustering Für das Clustering stehen unterschiedliche Mechanismen zur Verfügung. Sie Replizieren die Daten auf mehrere Storage-Server und sorgen so wahlweise für mehr Redundanz, mehr Performance oder mehr Speicherplatz. Automatic File Replication (AFR) Translator: Der Automatic File Replication Translator implementiert die Spiegelung über mehrere Bricks des Clusters (Listing 1). Dies entspricht im Prinzip RAID 1, allerdings mit wesentlich verbesserten Konfigurationsmöglichkeiten, denn man kann für unterschiedliche Dateitypen verschiedenen Redundanzlevel festlegen. Also beispielsweise wichtige Dateien dreifach innerhalb des Clusters speichern, gleichzeitig andere aber nur doppelt sichern. Diese redundante Speicherung der Daten bildet die Grundlage der Hochverfügbarkeit des Clusters. Auch bei Ausfalls eines Storage-Servers steht so immer noch mindestens ein Replikat der Daten zur Verfügung. Unify Translator: Der Unify Translator fasst mehrere Bricks zusammen und kombiniert sie zu einem großen und schnellen Storage- Server. Das funktioniert ähnlich wie bei einem RAID 0, indem er die Daten möglichst gleichmäßig auf alle Bricks verteilt. Durch dieses Quasi-Striping addiert sich die Kapazität, so dass der verfügbare Speicherplatz damit der Summe aller freigegebenen Volumes entspricht. Aber nicht nur die Kapazität erhöht sich, sondern auch die Geschwindigkeit nimmt zu, denn die Schreib- und Leseoperationen verteilen sich nun auf die Schultern aller Teilnehmer. Außerdem vermindert sich die Netzlast der einzelnen Bricks. ### Add clustering to bricks volume unify brick4 type cluster/unify subvolumes brick1 brick2 brick3 option scheduler rr Ebenfalls analog zum RAID-System erzielt man auch mit GlusterFS dann die beste Performance und trotzdem Redundanz, wenn man beide Me- chanismen kombiniert. In der Plattenwelt würde das einem RAID-10 entsprechen. Listing 2: Server-Konfiguration 01 ### Export volume "brick-master" 02 volume brick-master 03 type storage/posix # POSIX FS translator 04 option directory /home/brick-master # Export this dir ### Export volume "brick-slave" 08 volume brick-slave 09 type storage/posix # POSIX FS translator 10 option directory /home/brick-slave # Export this dir ### Add network serving capability to above bricks 14 volume server 15 type protocol/server 16 option transport-type tcp/server 17 subvolumes brick brick-afr 18 option auth.ip.brick-master.allow * 19 option auth.ip.brick-slave.allow * 20 Linux Technical Review, Ausgabe

5 perationen zufällig über die konfigurierten Bricks. Er ist einfach zu konfigurieren, kann aber zu Ungleichgewichten bei Last oder Speicherplatz auf den Bricks führen. Round-Robin Scheduler (»rr«): Er verteilt alle Dateien im Prinzip reihum auf die einzelnen Server. Jeder Client hat dabei seine eigene Round-Robin Liste, so dass sich Ungleichgewichte bei den Clients auch in einer ungleichen Load auf den Bricks niederschlagen. Adaptive Least Usage Scheduler (»alu«): ALU ist der fortschrittlichste aller verfügbaren Scheduling Mechanismen, da er die Schreiboperationen je nach Last der Bricks verteilt. Er berücksichtigt dabei den noch verfügbaren Speicherplatz, die Anzahl der aktuellen Lese- und Schreiboperationen und die Anzahl der offenen Files. Er versucht also immer dasjenige Volume zu finden, das gerade am wenigsten Arbeit zu verrichten und den meisten freien Platz hat. Performance Optimierungen Zur Verbesserung der Performance des Clusters stehen ebenfalls verschiedene Mechanismen als Translator zur Verfügung: Stat Pre-Fetch Translator: Bei interaktiven Kommandos, wie beispielsweise»ls -l«muss der Client für jedes File einen eigenen»stat«- Aufruf ausführen, um die Metadaten zu ermitteln. Dieser Translator liest die Metadaten aller Files eines Verzeichnisses immer in einem einzigen Durchgang.. Dies beschleunigt interaktive Kommandos und entlastet die Server erheblich. volume stat-performance type performance/stat-prefetch # Time-out for stat cache. option cache-seconds 1 Read Ahead Translator Je nach Konfiguration kann dieser Translator eine bestimmte Anzahl von Blocks, die der Client noch gar Listing 3: Client-Konfiguration 01 ### Add client feature and attach to remote volumes of server1 02 volume brick1-master 03 type protocol/client 04 option transport-type tcp/client 05 option remote-host option remote-subvolume brick-master # name volume brick1-slave 10 type protocol/client 11 option transport-type tcp/client 12 option remote-host option remote-subvolume brick-slave ### Add client feature and attach to remote volumes of server volume brick2-master 19 type protocol/client 20 option transport-type tcp/client 21 option remote-host option remote-subvolume brick-master volume brick2-slave 26 type protocol/client 27 option transport-type tcp/client 28 option remote-host option remote-subvolume brick-slave # name ### Add replication (AFR) brick1 & brick volume afr1 35 type cluster/afr 36 subvolumes brick1-master brick2-slave 37 option replicate *: volume afr2 41 type cluster/afr 42 subvolumes brick2-master brick1-slave 43 option replicate *: ### Add unify feature to cluster the servers. 47 ### Choose an ppropriate scheduler volume cluster 50 type cluster/unify 51 subvolumes afr1 afr2 52 option scheduler rr #RR Scheduler 53 option rr.limits.min-free-disk 10GB Linux Technical Review, Ausgabe 03

6 nicht angefordert hat, schon im Voraus einlesen. Wenn dann der Client diese Dten anfragt, beantwortet der Server sie aus dem Cache. Zusätzlich arbeitet der Translator als Read-Aggregator, indem er viele kleinere I/ O-Operationen zu wenigen größeren zusammengefasst.. volume readahead type performance/read-ahead # size in bytes option page-size # p-size x p-count = U read-ahead data per file option page-count 16 Write Behind Translator: Schreiboperationen brauchen immer wesentlich mehr Zeit als Leseoperationen. Um diesen Nachteil etwas auszugleichen, aggregiert dieser Translator die Schreiboperationen und führt sie etwas zeitversetzt im Hintergrund aus. volume writebehind type performance/write-behind # aggregate block size in bytes option aggregate-size Threaded I/ O Translator: Normalerweise führt GlusterFS alle Schreib- und Leseoperationen synchron aus: Der Client wartet auf die Bestätigung, des Servers. Dieser translator ermöglicht asynchrones Arbeiten. Dies lastet die Ressourcen besser aus und führt zu weniger Blockaden. volume iothreads type performance/io-threads option thread-count 8 Konfigurationsbeispiele Ein Nachteil des AFR-Translators, der die Daten auf einen zweiten Server repliziert, ist, dass der Slave-Server im Normalfall nicht für Leseanfragen zur Verfügung steht. Nur wenn der Master ausfällt, benutzen die Clients den Slave als Alternative. Besser wäre es, wenn diese Server auch für Leseanfragen zu nutzen wären. Dies kann man erreichen, indem jeder Server selbst ein Mastervolumen und das Replikat eines anderen Servers erhält. Die nachfolgende Beispielkonfiguration implementiert genau diese Alternative mit zwei Bricks und zwei Volumes, die sich gegenseitig replizieren. Auf den Servern und den Clients ist die Konfiguration jeweils vollkommen gleich. Zuerst installiert man GlusterFS mit Hilfe des üblichen Dreisatz»configure; make; make install«und konfiguriert anschließend die beiden Verzeichnisse und die Netzwerkfreigaben in der Konfigurationsdatei»/etc/glusterfs-server.vol«so wie es das passende Beispiel in Listing 2. demonstriert. Danach muss man das GlusterFS nur noch mit»glusterfsd«starten. Auf den Clients installiert der Admin GlusterFS analog mit # tar xvzf glusterfs-version.tar.gz # cd gluster-version # CFLAGS="-O3"./configure --prefix=u /usr --sysconfdir=/etc --disable-server # make # make install Anschliessend konfiguriert man in der Datei»/etc/glusterfs-client.vol«das Filesystem-Layout. Die vier Remote-Volumes werden importiert, mit dem AFR Translator repliziert und dann mit Unify Translator zu einem großen Filesystem zusammengefügt (Listing 3). Zuletzt mountet man das Filesystem nur noch lokal und schon lässt es sich verwenden:»# glusterfs -f /etc/glusterfs-client.vol /mnt/glusterfs«. Will man das Filesystem schon beim Starten des Systems mounten, kann man den Aufruf dazu wie gewohnt in der»/etc/fstab«vorgeben:»/etc/ glusterfs-client.vol /mnt/glusterfs glusterfs defaults 0 0«. Fazit Für den produktiven Einsatz müsste man das dieses Beispiel natürlich noch mit dem Adaptive Least Usage (ALU) Scheduler verbessern und je nach Einsatzzweck entsprechende Performanceoptimierungen konfigurieren. Dennoch kann bereits erkennen, dass GlusterFS ziemlich einfach einzurichten ist. Auch die Verwaltung und Erweiterung ist nicht viel komplizierter. Der Grund dafür ist vor allem, dass kein proprietäres Dateisystem zum Einsatz kommt und dass das System komplett im Userspace implementiert ist. (jcb) Infos [1] GlusterFS: [ www. gluster. org] Der Autor Julian Hein ist Gründer und geschäftsführender Gesellschafter der NETWAYS GmbH ([ www. netways. de]), die sich seit mehr als 10 Jahren mit den Themen Netz- und Systemmanagement durch Open Source Tools beschäftigt. Linux Technical Review, Ausgabe