gfs2 Erfahrungen?

gfs2 Erfahrungen? (14 Beiträge, 315 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Ich bin auif der Suche nach einem Filesystem, das ich von verschiedenen Clients gleichzeitig mounten kann. Auf dem sich aber -anders als auf einem NFS- auch Sockets öffnen lassen, sowie Dateirechte unterstüzt, das sich also als /home verwenden lässt.

Dabei bin ich als erfolgsversprechendstes FS auf das gfs2 von RedHat gestoßen.
Schon wer Erfahrung?
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Sorry keine...

Aber Thema Sockets... Die sind ja real nie im Filesystem - das Filesystem stellt sie nur als Eintrittspunkt für Unix-IPC dar. Mich würde überraschen, wenn das irgendwo transparent im Netz klappt - a la "Rechner 1 öffnet ihn zum schreiben, Rechner 2 zum lesen".

WENN das aber wo klappt - hätte ich ocfs2 in Verdacht. Das ist ja rein für die RAC von Oracle - hast das schon ausprobiert? Oder wo stehst Du mit deinen Evaluierungen gerade?

Oder wo stehst Du mit deinen Evaluierungen gerade?

Ich gestehe ich habs noch gar nicht ausprobiert, und teste immer noch, ob ich nicht mit einem Readonly mount am Server und einem vollen mount am Client nicht doch mit ext4 geht.

Mein eigentliches Ziel sind ja Servergestützte Home Verzeichnisse. Die möchte ich am Server einmounten können, um einerseits mit dem User auch per ssh am Server seine Daten zu haben, andererseits um die Daten für das Backup zur Verfügung zu haben. Und die Clients sollen sie per iscsi zur Verfügung gestellt bekommen.

Und obwohl da ein Cluster FS sicher optimal wäre, ist es wohl doch ein bisserl ein Overkill, das deshalb einen Cluster mit den Clients hinzubiegen.
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Mein eigentliches Ziel sind ja Servergestützte Home Verzeichnisse.

Benutzen die Clients echt FIFOs in /home?

Ansonsten: Wenn alle Daten eh am Server sind - wozu noch die ssh-Gschicht um Daten auf den Server zu holen?

Wenn eh schon iscsi - wozu dann Servergestützte /home-Laufwerke? Die Platte liegt dann eh am Server...

Ganz verstehe ich deine gedachte Gschicht noch nicht... Kannst eine Skizze machen? Inwiefern unterscheidet sich dein Setup von einem "normalen" Diskless Client? Und wozu iscsi - warum dann nicht den 30+ Jahre alten Weg mit PXE-Boot und NFS-Mount?

Kurz. Kein aktuelles System läuft auf NFS mounts. Da gibts Probleme mit Evolution, Pulseaudio, gvfs sonder Zahl. Wenn wer in seiner /home ein Alfresco z.B. installieren will oder ähnliches, geht derzeit gar nichts. D.h. ein echtes lokales Filesystem ist notwendig.

Szenario ist: Ich habe einen Ubuntu Server. Auf dem liegen meine Benutzer.
Diese Benutzer sind einerseits per iscsi- freigegeben, um Linux Clients servergestützte /homes zu erlauben. (läuft derzeit noch über sshfs aber eher schlecht als recht, mit einer Menge auf die lokalen Platten verbogenen Verzeichnissen.)

Weiters ist am Server, in einer zum Terminalserver aufgemotzten WinXP-VM einige Software installiert, die auf die Daten am Server derzeit über eine Samba Freigabe zugreifen.

Und zu guter Letzt, gibt es auch noch ein paar User, die von Remaote über ssh am Server einloggen dürfen, und ebenfalls auf ihr /home kommen müssen.

Ich habe also folgendes Problem. Die Daten müssen für die Linux Clients als lokales Filesystem bereitstehen.

Die Daten müssen für die Windows Clients als SAMBA Freigabe existieren, ohne nach Möglichkeit dreifach über die Leitung zu laufen.

Und die Daten müssen für lokale User am Server bereitstehen.

So wie ich das sehe, komme ich um ein Cluster-fs nicht herum.
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Nur mal zusammenfassend:

- Windows-Clients: SAMBA und fertig
- Linux-Clients iSCSI
- ssh-User: Wenn sie auf Windows-Clients arbeiten kein Problem - dann wurde ja eh ihr /home am Server freigegeben.

Das einzige Problem sind also die User, die per SSH auf den Server dürfen UND von Linux-Clients kommen, oder?

Kein aktuelles System läuft auf NFS mounts.

Das ist eine total wertvolle Information für mich - wollte nämlich sowas wieder mal tun (das letzte mal machte ich sowas Anfang 90er und das lief fein)

Alternativ: Muss es Gnome sein? Wie wäre es mit IceWM oder so?

Alternativ²: Wie wäre es mit LTSP? Das klingt danach
http://www.tecchannel.de/netzwerk/management/2035848/ltsp_workshop_linux_terminal_server_project_thin_clients_selbst_gemacht/

06.12.2012, 06:28 Uhr - Editiert von kombipaket, alte Version: hier

Das einzige Problem sind also die User, die per SSH auf den Server dürfen UND
von Linux-Clients kommen, oder?

Das eigentliche Problem ist das Windows.
Das braucht Zugriff auf die /home Freigaben. Diese Freigaben kann ich aber nur am Zentralen-All-Purpose-Server machen. Denn der MG User am Terminalserver muss auch dann Zugriff auf die MG-Daten haben, wenn MG nicht an der Linuxworkstation angemeldet ist.

MG will sich aber an einer von 5 Linux Workstations anmelden können, und sein /home Verzeichnis das am Zentralen-All-Purpose-Server liegt eingemountet bekommen, und seine gewohnte gnome/unity Umgebung so vorfinden, wie er sie am Tag zuvor an einer der anderen Workstations verlassen hat.

Der shell User MG, der gerne sein /home, wenn er direkt am Server eingeloggt ist, hätte, ist da nur noch die Draufgabe. MG und der zweite ssh User sind kompetent genug, dass sie zur Not auch ohne ihr gewohntes /home Directory zurecht kommen.

Die Lösung bisher ist, einbinden der /home über sshfs oder NFS, was aber verlangt, dass gvfs, der pulseaudiosocket, und ein Evolutionverzeichnis ihren "Müll" auf der jeweils lokalen Platte lagern dürfen. Das ist relativ mühsam, weil immer wieder was auftaucht, was nicht sauberläuft, und ich ein reichlich komplizirtes System aus binds und symlinks brauche, dass es dann doch geht.

Ein halbwegs brauchbares Cluster-fs verspräche da eine Lösung zu sein.
Naja. Sollte mir mal eine Woche fad sein, kann ich ja spielen.

Alternativ: Muss es Gnome sein? Wie wäre es mit IceWM oder so?

Igitt! Gnome, oder wenn man mich mit vorgehaltenen Waffen dazu zwingt KDE.

Alternativ²: Wie wäre es mit LTSP? Das klingt danach

Das krankt an den selben Problemen... . Bringt nur die Lösung für die nicht trivialen Probleme einen pxe-Boot zu realisieren. Brauch ich aber nicht. Ich habe eh Platten in den Clients.

--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Ich habe also folgendes Problem. Die Daten müssen für die Linux Clients als
lokales Filesystem bereitstehen.

Hast Du schonmal probiert einen einfachen Blockreplikator zu aktivieren ? DRBD ? Das Teil sollte eigentlich überall alles hin blockmässig spiegeln.

Ach vergiss es, Du willst ja von mehreren Quellen da auf das FS schreiben... galub das geht ned mit DRBD.

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

06.12.2012, 09:54 Uhr - Editiert von A national Acrobat, alte Version: hier

Nein. DRBD ist nur eine Hochverfüßgbarkeisstorage. Die Blockleveldevices der Clusternodes bilden dabei ein gemeinsames DRBD-Device, das dann als Träger für LVs dient.

Quasi ein RAID auf Serverbasis.
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Ja eh ich habs im Nachhinein eh gesehen das a Bledsinn war was ich geschrieben hab

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung