Mehrere NFS Shares in ein Verzeichnis Mounten

[RWarnecke]

Hallo zusammen,

ich habe folgende Ausgangssituation. Ich habe drei Linux Server Master, A und B. Auf den Servern A und B sind jeweils ein NFS Share mit einer bestimmten Größe. Jetzt möchte ich die beiden NFS Shares von den Servern A und B auf dem Master-Server in ein Verzeichnis mounten, so dass ich über den Mountpoint auf dem Master-Server zusammengerechnet eine Gesamtgröße von Server A und B erhalte. Meinetwegen soll als erstes zum Beispiel die Platte auf Server A voll laufen und dann der Speicherplatz auf Server B genutzt werden. Wie das ganze nachher im Hintergrund abläuft, wäre mir egal. Die beiden Voraussetzungen sind nur, dass der Speicherplatz von Server A und B komplett unter dem einen Mountpoint vom Master-Server zur Verfügung steht und das ich jederzeit weitere Server mit Speicherplatz auf diesen Mountpoint hängen kann.

Ist dieses mit NFS überhaupt möglich oder muss ich hier ein anderes Verfahren verwenden ? Ein paar Links zu Tutorials wären sehr hilfreich.

[Dalai]

Ich befürchte, das wird nichts werden, denn soweit ich weiß, zählt das zuletzt gemountete Verzeichnis. Das trifft jedenfalls auf lokale Laufwerke zu, und ich gehe nicht davon aus, dass das bei Netzfreigaben anders ist, denn relevant ist, wer den Krempel mountet.

Probier's selbst mal aus und mounte eine Partition nach /mnt und mounte danach eine weitere Partition dorthin. Alle Dateien, die nun in /mnt geschrieben werden, landen auf der zuletzt gemounteten Partition. Was den angezeigten Speicherplatz angeht, ist es anscheinend so, dass df den Speicherplatz der zuletzt gemounteten Partition mit der Kennung der zuerst gemounteten Partition anzeigt (gerade mit der System Rescue CD getestet), was dir also auch nicht weiterhilft und dazu noch verwirrt. [ADD] Gerade hab ich das auch noch mit SMB-Freigaben getestet, das Ergebnis bleibt dasselbe. [/ADD]

Mit Standardmitteln geht es also nicht, aber vielleicht gibt es Möglichkeiten, das hinzubekommen (was ich nicht glaube, denn das Mounting dürfte ziemlich eng mit dem Kernel in Verbindung stehen).

MfG Dalai

[Klaus01]

..vielleicht ist es so machbar (raid over network share)

Grüße
Klaus

[Namenloser]

Ich habe zufällig erst gestern noch in der aktuellen c't (3/2015) etwas interessantes gelesen, was anscheinend in die Richtung geht:

Zitat von c't 3/2015, Seite 148:

Bei den heute üblichen Datenmengen erstrecken sich Video-, Musik- und Bildarchive schnell über mehrere Festplatten – und damit auch über mehrere Mount-Points. Mhddfs vereint Ihre Festplatten in einem gemeinsamen Verzeichnis, ohne Ihnen die Möglichkeit zu nehmen, bei Bedarf Dateien von Hand einzusortieren. Außerdem kann Mhddfs den Restplatz auf mehreren Festplatten optimal ausnutzen, indem es bei Platzmangel Dateien auf ein anderes Laufwerk verlegt, ohne dass die schreibende Anwendung davon etwas mitbekommt. [...] Mhddfs ist ein Fuse-Union-Dateisystem, das Dateien aus mehreren Verzeichnissen analog zu transparenten Folien übereinander schichtet.

Es verschmilzt quasi mehrere getrennte Verzeichnisse/Mounts zu einem einzigen virtuellen Verzeichnis, so wie ich es verstanden habe.

Ich kann dir nicht garantieren, dass das für deine Zwecke geeignet ist, da ich es selbst nicht aus erster Hand kenne, aber es klingt so, als ob es mal einen Blick wert wäre.

[Valle]

Da würde ich keinesfalls NFS verwenden.

Es gibt viele Lösungen dafür. Dafür sind einige Parameter interessant.

• wie viel Bandbreite brauchst du?
• wie viel Latenz ist in Ordnung?
• wie viele Clients greifen zu?
• von welchen Größeren der Freigaben reden wir?
• muss das Cluster weiter funktionieren, wenn ein Server ausfällt?
• brauchst du eine Redundanz der Daten?

[RWarnecke]

Zitat von Valle:

wie viel Bandbreite brauchst du? wie viel Latenz ist in Ordnung?

Das Gebiet Cluster ist noch etwas neu für mich. Von Außen ist der Master-Server mit 100MBit erreichbar. Untereinander sind die Server mit 100MBit oder sogar mit 1GBit verbunden. Die Latenz sollte so niedrig sein, dass nicht die eingesetzte Lösung das Nadelöhr ist. Ich hoffe Du kannst damit etwas anfangen, da ich nicht so richtig wusste, was ich auf diese zwei Fragen antworten sollte.

Zitat von Valle:

wie viele Clients greifen zu?

zwischen 28 und 560 Leute pro Server

Zitat von Valle:

von welchen Größeren der Freigaben reden wir?

zwischen 900 GB und 1,9 TB pro Server

Zitat von Valle:

muss das Cluster weiter funktionieren, wenn ein Server ausfällt?

Das sollte er.

Zitat von Valle:

brauchst du eine Redundanz der Daten?

Nein, da diese nochmals woanders gesichert werden.

[jaenicke]

Das hört sich nach dem an was ich auf Windows Server 2012 mit Hilfe von ReFS und Storage Spaces mache. In meinem Fall sind das zweimal drei 2 TB Festplatten, die zu zwei virtuellen gespiegelten 3 TB Speicherplätzen (eben die Storage Spaces, also virtuelle Festplatten) zusammengefasst sind. Diese virtuellen Laufwerk sind wiederum im Netzwerk freigegeben.
Das ganze lief von Anfang an absolut problemlos und war mit wenigen Klicks eingerichtet.

Soweit ich weiß kann man die Festplatten auch von verschiedenen Servern zusammenfassen, aber das habe ich noch nicht gemacht.

Anfang Dezember ist eine Festplatte daraus ausgefallen. Ich konnte diese problemlos im laufenden Betrieb austauschen ohne dass die Freigaben nach außen hin in irgendeiner Weise beeinträchtigt waren.

Leider kenne ich keine analoge Lösung für Linux. Vorher hatte ich jahrelang einen Linux Server (Debian), aber mit dem hatte ich um Größenordnungen mehr Aufwand und konnte dennoch weniger damit machen. Deshalb habe ich nun seit einigen Monaten auch serverseitig nur noch Windows im Einsatz.

[Valle]

Okay, weniger als 4 TB sind wirklich sehr wenig. Wieso müssen es mehrere Server sein, die diesen Speicher halten?

>1k Clients hingegen sind ziemlich viel. Da kann ich deinen Wunsch nach Redundanz auch verstehen.

Mein Vorschlag wäre, dass du statt Master-Master (was im Storage-Bereich schnell kompliziert wird) einen Master-Slave Ansatz verfolgst. Zwei identische Storage Server mit einem erweiterbaren RAID (ich empfehle RAID 6). Da kannst du nach Belieben immer wieder Platten nachschieben.

Softwareseitig würde ich ein DRBD (sowas wie RAID 1 über Netzwerk) und Heartbeat vorschlagen. Der Master Server synchronisiert seine Daten permanent über eine schnelle Gigabit-Verbindung mit dem Slave. Fällt der Master Server aus, übernimmt der andere in wenigen Sekunden, indem er sich selbst zum Master promotet. Der Master kann dann, sobald er wieder verfügbar ist, seine Rolle als Slave wahrnehmen. Das Vorgehen ist hier gut beschrieben.

Eine Alternative, falls du wirklich mehrere Master benötigst, ist GlusterFS. Damit kannst du beliebig viele Server in dein Stroage-Cluster hinzufügen. GlusterFS unterstützt auch Redundanz der Daten, sodass alle Daten auch verfügbar sind, wenn ein Server dauerhaft oder temporär ausfällt. GlusterFS ist allerdings eher nach unten beschränkt als nach oben. Ob das mit nur 2 Servern schlau (oder überhaupt möglich) ist, wage ich zu bezweifeln.

Das Problem das du hast, ist, dass es immer einen Master braucht, der gleichzeitige Zugriffe auf deinen Storage kontrolliert. Darunter zählen auch Locks auf Dateien. Daher ist eine Aufteilung in zwei unabhängige Master nicht ohne weiteres möglich. Selbstverständlich kann man Storage auf mehrere Server aufteilen (Stichwort iSCSI). Man könnte dann ein RAID über die Netzlaufwerke erstellen und dieses freigeben. Fällt der Master, der dieses RAID freigibt allerdings aus, so fällt das gesamte Cluster aus. Daher mein Vorschlag mit DRBD und Heartbeat.

Vielleicht hilft dir das ein wenig weiter. Ansonsten wäre noch interessant, gerade in Bezug auf jaenickes Post, welches Betriebssystem vorgeschrieben ist. Auch Budget, Zeitaufwand und Kenntnisse mit entsprechender Software ist natürlich eine Frage. Kannst du genaueres über die Clients verraten?

[RWarnecke]

Hallo zusammen,

ich danke euch erstmal für euren vielen Antworten.

Hintergrund meiner Frage ist folgender :
Ich plane für einen Dienst, den ich zur Verfügung stellen will, entsprechend Speicherplatz festzulegen, damit die Anwender Ihre Anhänge bei dem Dienst darauf speichern können. Dazu hatte ich gedacht, dass ich einfach zum Anfang zwei dedicated Server mit Ubuntu 14.04 bei einem Provider miete, einen davon als Master und der zweite Server sollte irgendwie mit dem Master gekoppelt werden. Das war für mich ja noch der einfache Teil, da ich das in meinen Testaufbauten immer über NFS Shares gemacht habe. Jetzt kam aber die Frage auf, was ist wenn ich jetzt noch einen dritten oder vierten Server benötige, wie mache ich dass dann. Deshalb meine Frage, ob ich zum Beispiel mehrere NFS-Share so mounten kann, dass alle in ein Verzeichnis laufen.

Ich werde mich jetzt mal in mein stilles Kämmerlein zurückziehen und darüber nachdenken, ob mein Ansatz mit den NFS-Shares noch Sinn hat, oder ob ich eine ganz andere Schiene fahren muss. Ich fühle mich eigentlich recht fit in Linux, ganz besonders mit Ubuntu, deshalb würde ich mir auch schon zutrauen, mir so etwas nach Bedienungsanleitung einzurichten. Ich werde jetzt erstmal mit ein paar Providern telefonieren, ob ich überhaupt mit den dedicated Servern solch einen Cluster aufbauen kann.

[Valle]

Ah, okay, interessant. Hatte bisher andere Vorstellungen im Kopf.

In deinem Fall hast du ja einen dedizierten Dienst, der auf den gleichen Servern läuft, auf dem sich auch der Storage befindet. In diesem Fall wäre DRBD imho nicht so gut geeignet, da dies auch schlecht nach oben skaliert. Es geht wohl vor allem darum, die Last der laufenden Dienste auf mehrere Server aufzuteilen?

Vielleicht schaust du dir dann wirklich mal Ceph (Filesystem) oder GlusterFS an. Es gibt auch noch weitere verteilte Dateisysteme. Damit kannst du gut nach oben hin skalieren, wenn du noch mehr Server brauchst.