Erfahrungen mit verteilten Dateisystemen
Hi all,
ich habe eine Frage in die Runde bzgl. verteilten Dateisystemen.
Was ich vor habe:
Ich habe im RZ zwei Server stehen. Die sollen die gleichen Daten bevorraten
falls mal eine Maschine ausfällt. Gleichzeitig möchte ich aber auch den
gesamten Datenbestand von beiden Servern aus nutzen können.
Auf den echten Servern laufen div. virtuelle Maschinen. Die werde ich per DRBD
spiegeln, da immer nur eine VM zur gleichen Zeit läuft. Stirbt ein Server,
setze ich das DRBD-Device auf dem anderen Server als primary und fahre die VM
wieder hoch. Das habe ich zu Hause getestet und das geht absolut reibungslos
und rasend schnell (die Begrenzung ist quasi nur die Netzwerkanbindung und die
Geschwindigkeit der Platten).
Die gesamten Nutzerdaten möchte ich gerne über alle VMs teilen, einmal damit es
nur *einen* großen Storage gibt (beim bisherigen Setup verschwende ich Unmengen
an Platz schon dadurch, dass die /home's nicht richtig ausgelastet sind).
Außerdem möchte ich gerne so Sachen wie den IMAP-Server parallel auf beiden
Servern laufen lassen, so dass man DNS round robin machen kann (wenn schon zwei
Server im RZ stehen soll sie auch was zu tun haben).
Leider bin ich ziemlich unschlüssig womit ich ein solches verteiltes
Dateisystem umsetzen soll. Folgende Ideen hatte ich:
1. Verteilung der Daten per DRBD auf beide Server, ext4 formatiert und auf
*einem* Server gemountet. Gemeinsamer Zugriff über NFS4.
Vorteile:
- DRBD und ext4 laufen (da habe ich keine Bedenken bzgl. der Stabilität)
- geht was schief kann ich das mit Boardmitteln reparieren
- NFS4 ist bewährt
Nachteile:
- läuft der NFS4-Server auf Server A und es kommen Zugriffe auf die Daten vom
Server B ist der Flaschenhals das Netzwerk. 99,x% der Anfragen sind nur
lesender Natur. Ich habe die Daten auf Server B auch liegen, aber komme nicht
dran, weil ich durch ext4 nur einmal mounten darf.
2. Verteilung der Daten per DRBD auf beide Server, Einsatz von DRBD
dual-primary und GFS/OCFS2.
Vorteile:
- auf beiden Servern sind die gleichen Daten. Bei lesenden Zugriffe sind nur
Abgleiche über die DLMs nötig, die Daten selbst können lokal gelesen werden.
Das Netzwerk ist kein Flaschenhals.
Nachteile:
- beide FS - GFS und OCFS2 - sind für mich böhmische Dörfer. Ich vermag nicht
zu beurteilen wie solide, stabil, zuverlässig und pflegbar eine solche Lösung
ist und welche Fallstricke auf mich warten.
3. Verteilung über GlusterFS auf beide Server
Vorteile:
- GlusterFS vereint quasi die Spiegelung der Daten und das Locking/die
Synchronisation in einem.
- Zugriff per NFS4 möglich (NFS4-Server ist im GlusterFS eingebaut).
Nachteile:
- ich habe ein paar Tage mit GlusterFS aus Wheezy (3.2.0) rumgespielt. Ich
schaffe es nicht einen Storage mit nur einem Brick anzulegen (das brauche ich
für die Migration). Das finde ich komisch - der Entwickler preisen das
GlusterFS als RAID-gleiche Lösung. Mit einem vernünftigen RAID-Controller
kann ich auch ein RAID1 degraded mit nur einer Platte anlegen. Ich weiss auch
keinen einleuchtenden Grund warum das nicht gehen sollte.
- ich habe es nicht geschafft ein Replica mit 2 Bricks um eine weitere Brick zu
erweitern - die Brick-Anzahl muss ein ganzzahliges Vielfaches des
replica-counts sein. Dann habe ich zwei Bricks ergänzt und das GlusterFS hat
mir eine "dedicated replicity" raus gebastelt - vollkommen überraschend!
Sowas macht mich misstrauisch, weil ich mit sowas nicht rechne (um den
RAID-Vergleich heran zu ziehen: wenn ich in ein RAID1 aus 2 Platten zwei
weitere einfüge erwarte ich auch, das hinterher ein RAID1 rauskommt und kein
RAID10).
- ich bin mir nicht sicher ob die Clients immer auf den gleichen Server (den
ich beim mounten angebe) zugreifen oder ob sie sich über die Verbindung zum
ersten Server die Daten aller weiteren GlusterFS-Server für das Storage
holen. Die Doku [1] ist für den Anfang sehr schön, aber wenn man versucht
hinter die Kulissen zu schauen steht man im Dunkeln (es wird z.B. nirgends
erklärt was genau der replica-count bedeutet).
- das GlusterFS ist für mich ebenfalls ein böhmisches Dorf. Ich vermag nicht zu
beurteilen wie solide, stabil, zuverlässig und pflegbar eine solche Lösung
ist und welche Fallstricke auf mich warten.
Ich bin jetzt ratlos. Was habt ihr für Erfahrungen? Gibt es Empfehlungen was
man machen sollte (oder auch: wovon man um jeden Preis die Finger lassen
sollte)?
Viele Grüße
Meinhard
[1]: http://www.gluster.org/wp-content/uploads/2012/05/Gluster_File_System-3.3.0-Administration_Guide-en-US.pdf
Reply to: