Remote Home-Verzeichnis cachen

[~Gh05t~]

Hi all,
ich würde gerne mein Home-Verzeichnis von meinem Home-Server laden, da der über ein Raid-System etc. verfügt.
Ich möchte aber nicht davon abhängig sein, d.h. mein Rechner soll auch dann noch starten, wenn der Server gerade mal nicht erreichbar ist.

D.h. ich brauche ein Caching. Die Daten sollen auf meinem Server sein und auf meinem Client gecached werden.

Ist das möglich? Wie mache ich das?

[madfool]

Ich hab da leider keine Lösung parat, wäre an einer solchen aber definitiv auch interessiert, da ich die home-dirs im Moment über NFS einbinde und damit immer vom Server abhängig bin.

Gruß
D.

[unux]

Hi,

Für diese Aufgabenstellung gibt es meines Erachtens mehrere Lösungsansätze:

Vorneweg: Damit du auch bei Ausfall des Servers o.ä. auf dein Homedir zugreifen kannst und weiterarbeiten kannst, musst du imho eine Kopie desselben auf deinem Client haben. "Caching" wäre in diesem Zusammenhang somit ein falscher Begriff.

Nun musst du dir die Frage stellen, ob du die beiden Verzeichnisse (auf dem Server und lokal) in Realtime synchron halten willst. Willst du das, wird das ganze ein wenig tricky.

1. Lösung: Du machst täglich, oder so oft wie du das eben brauchst (hängt natürlich auch von der Größe des Homedirs ab), per rsync, unison o.ä. ein Backup deines lokalen Verzeichnisses auf den Server. Problem dabei ist natürlich, dass bei einem Ausfall deiner lokalen Platte alle geänderten Daten seit dem letzten Backup fehlen.

2. Lösung: Du beschäftigst dich mit DRBD (http://www.drbd.org). Somit werden deine Daten in Realtime sowohl auf die lokale Platte, als auch auf den Server geschrieben. Setzt du dabei ein primary-secondary-Konstrukt ein, hast du nur die Möglichkeit an der primary Node, Daten auf das Device zu schreiben. In dem Fall solltest du deinen Client zur primary Node zu machen, damit du bei einem Serverausfall weiterarbeiten kannst. Seit DRBD 8.0 ist es allerdings auch möglich ein primary-primary-Kontrukt zu fahren, dazu benötigst du allerdings dann ein Clusterfilesystem wie GFS oder OCFS2.
Ich muss hinzufügen, dass dieses System eigentlich nicht für deinen Einsatzzweck konzipiert ist.

Ich würde persönlich zur 1. Lösung raten, da die Wahrscheinlichkeit weit weniger groß ist hierbei auf Probleme zu stoßen.

Greetz UnuX

[~Gh05t~]

hmmm... die rsync Lösung hört sich gut an. Dann würde ich es aber andersherum machen, ich gehe davon aus, dass ich im normalfall auf dem Server-Verzeichnis über NFS arbeite und das lokale Verzeichnis synchronisiert wird.
Dann brauch ich mir nur noch irgend ein Script schreiben das automatisch das lokale Verzeichnis mountet falls der Server nicht erreichbar ist... (was in der Regel nicht der Fall sein sollte).

Eine rsync-Lösung hätte außerdem den vorteil, dass ich nicht alles synchronisieren muss, ich brauch ja nicht alles auf dem Client. Auf die Idee hätte ich auch kommen können, Danke! :)

[unux]

Hi,


hmmm... die rsync Lösung hört sich gut an. Dann würde ich es aber andersherum machen, ich gehe davon aus, dass ich im normalfall auf dem Server-Verzeichnis über NFS arbeite und das lokale Verzeichnis synchronisiert wird.
Dann brauch ich mir nur noch irgend ein Script schreiben das automatisch das lokale Verzeichnis mountet falls der Server nicht erreichbar ist... (was in der Regel nicht der Fall sein sollte).

Die Vorgehensweise will mir nicht ganz einleuchten. Soweit ich das verstanden habe willst du an deinem Client problemlos weiterarbeiten können, wenn der Server ausfällt. Ist bei der Lösung aber der Server nicht mehr zu erreichen, hast du auf deinem Client ja nur die Daten vom letzten Backup, d.h. alle geöffneten Dokumente usw. können nicht weiterbearbeitet werden. Von höherer Verfügbarkeit ist hierbei also nicht zu sprechen.


Eine rsync-Lösung hätte außerdem den vorteil, dass ich nicht alles synchronisieren muss, ich brauch ja nicht alles auf dem Client.

Wenn du dich dennoch für deine Vorgehensweise entscheidest, musst du natürlich aufpassen, das sich sämtliche essentiellen Dinge, wie z.B. Configs usw auf dem Client befinden.

Greetz UnuX