NFS Cache, LB Cluster oder wie würdet ihr das Problem lösen?

[Stefan307]

Hallo
Also folgendes Scenario ich habe(oder werde in Zukunft haben  ) zwei Gbit Netze in denen jewails ein NFS Server meinen Datenbestand vorhält. Diese beiden Netze sind aber nur mit 200Mbit via Steckdose verbunden , deshalb wohl 2 NFS Server damit ich in den Netzen  auch Gbit nutzen kann! Mein Problem ist jetzt ich möchte den Datenbestand auf beiden Servern möglichst permanent syncronisieren. Da es auf beiden Seiten Änderungen gibt scheidet rsync schon mal aus, ich stell mir das im Idealfall so vor:
Prizip wie Ram Cache bei SMP, beide Server haben einen gespiegelten Datenbestand und bedienen die Leseanfragen ihrer Netze, wird jetzt in einem Netz geschrieben erhält der andere Server die Mitteilung das sich diese Datei (bzw Dateiteil) verändert hat. Soll auf diese Datei zugegriffen werden verzögert er das solage bis die Datei wieder syncronisiert ist, in diesem Fall reduzeirt sich die Datenrate halt auf die langsamste Verbindung .
Stellt sich die Frage wie man sowas umsätzen könnte ? Cache scheint es bei NFS nur Clientseitig zu geben, man könnte höchstens die Daten von einem "Master NFS Server" einhängen (und einen riesen NFS Server Cache einrichten) und dann wieder per NFS Verteilen? Ich fürchte nur das die caching Funktionen dafür nicht ausgelegt sind.
Andere Möglichkeit beide Server zu einen Cluster verbinden, aber dann muß der Datenbestand ja an beide schnell herangebracht werden...
3. Idee die Festplatten des einen als Raid 1 mittels iSCSI beim anderen einhängen, auch blöd weil dann ja auch Lesezugriffe auf die 2. Platte gehen (kann man da vielleicht eine Umleitung einbauen, lesen nur loal schreiben global ?

Fragen über ich Fragen ich höffe ihr habt eine bessere Idee, ich vermute mal das Problem git es auch im Professionellen Bereich wenn Filialen nur  über WAN angebunten sind aber ein gemeinsamer Datenbestand vorgehalten werden muß! Wie wir das da gelöst ?

MFG S   

[Stefan307]

ich glaub ich habe gefunden was ich suche:
http://www.drbd.org/
mal schauen wie das so klapt ...

[dominik_bsl]

Das läuft aber nur unter Linux als Kernelmodul:

== Prerequisites ==

 You need to install the kernel-source package. Or, if you run the default
 distribution kernel, and there is some "precompiled kernel headers"
 directory, you can skip this, and compile against that directory of header
 files. If so, skip the "Prepare" section, and just jump to "Build DRBD".

      rpm.distros# rpm -Uhv kernel-source-2.4.XX-YYY.rpm
            debian# apt-get install kernel-source
        kernel.org# tar --bzip2 -xvf linux-2.4.XX.tar.bz2

Gruss
Dominik

[karakal]

Wie wärs mit dem Einsatz von AFS?

http://de.wikipedia.org/wiki/Andrew_File_System
http://en.wikipedia.org/wiki/Andrew_File_System

Aber auch da stellt sich immer die Frage, wie vernünftig ist das: Ist dein Storage-System überhaupt schnell genug, um Gigabit oder überhaupt schon die 200MBit Powerline Verbindung auszulasten?

Die Probleme die du dir hier einhandelst sind sowieso nicht ohne. Ich sage nur Konsistenz usw...
Ich kenne einige große Lösungen, die AFS einsetzen, dann kenne ich einige mehrstufige Lösungen: Direktzugriff für zeit- und zugriffskritische Daten über langsame WAN-Leitungen, Synchronisierung von größeren Datenmengen über Nacht...

Ist es vielleicht nicht einfach billiger, schneller und praktischer, einfach ein Loch zu bohren und ein Netzwerkkabel zu verlegen?

[Tschokko]

Hmmm... dein Problem liest sich wie ein klassischer Fall für ein Cluster File System. Ich würde mich eher damit mal auseinander setzen.

Gruß
Tschokko

[Tschokko]

Mit dem Linux GFS Cluster Dateisystem sollte dein Problem elegant und professionell lösbar sein. Das kann über TCP/IP die Daten abgleichen und verhindert, das zwei Clients die gleiche Datei auf verschiedenen Knoten verändern.

Musst du mal im Netz ein wenig dich schlau dazu machen. Sollte aber nicht soo fürchterlich schwierig sein.

Gruß
Tschokko

[Tschokko]

Und hier nun die Lösung: http://www.failover.de/cluster/vortrage-und-prasentationen/2-knoten-cluster-mit-drbd-und-gfs



Liest sich auf jeden Fall spannend !

Gruß Tschokko

[Ebbi]

Man kann Beiträge auch editieren, Herr Tschokko! (Hugh, der Moderator hat gesprochen. )

[Tschokko]

Man kann Beiträge auch editieren, Herr Tschokko! (Hugh, der Moderator hat gesprochen. )

Man man man, alles macht man falsch hier. Vor kurzem erst die Off-Topic Warnung und nun das hier. Tz tz tz...

Gruß Tschokko

[karakal]

Mit dem Linux GFS Cluster Dateisystem sollte dein Problem elegant und professionell lösbar sein. Das kann über TCP/IP die Daten abgleichen und verhindert, das zwei Clients die gleiche Datei auf verschiedenen Knoten verändern.

Da ich heute zu faul zum Selberformulieren bin, schreibe ich einfach aus http://de.wikipedia.org/wiki/Global_File_System#Irrt.C3.BCmer_in_Verbindung_mit_GFS ab:

Ein weit verbreiteter Irrtum ist die Annahme, ein Cluster-Dateisystem alleine könnte Daten global zur Verfügung stellen. Das ist so nicht richtig. Angenommen man stattet Rechner A und B mit GFS aus. Dadurch kann A nicht die Daten von B sehen und auch nicht anders herum. Warum? Es ist zwingend nötig, das alle GFS Rechner auf ein und den selben Storage zugreifen. Wenn A auf den lokalen Storage (also dessen Festplatte) zugreifen möchte, muss A seine Festplatte vorher mit einer Technik in das Netzwerk exportieren, damit B diesen Storage sehen kann. Genau das stellt GFS nicht zur Verfügung, sondern dieses so genannte Storage Area Network muss gekauft oder selbst gebaut werden (siehe Einleitung bzgl. der Möglichkeiten).

Ein weiterer Irrtum ist, man könnte eine Redundanz der Daten erreichen durch ein Cluster-Dateisystem. Auch das ist nicht seine Aufgabe. Das Storage Area Network selbst muss redundant sein, um die Verfügbarkeit der Daten zu gewährleisten. Das Cluster-Dateisystem kennt "lediglich" Mechanismen, um bei Problemen von A oder B selbständig für eine nahtlose Wiedereingliederung zu sorgen und eventuell noch nicht in das Storage Area Network übertragende Daten zu übertragen.

Der Sinn eines Cluster-Dateisystems ist es, die Zugriffe auf ein Storage Area Network zu regeln, da es zu einem Desaster käme, wenn A und B gleichzeitig die gleiche Datei im Storage Area Network schreiben würde. Nicht mehr und nicht weniger.

[Tschokko]

Mit dem Linux GFS Cluster Dateisystem sollte dein Problem elegant und professionell lösbar sein. Das kann über TCP/IP die Daten abgleichen und verhindert, das zwei Clients die gleiche Datei auf verschiedenen Knoten verändern.

Da ich heute zu faul zum Selberformulieren bin, schreibe ich einfach aus http://de.wikipedia.org/wiki/Global_File_System#Irrt.C3.BCmer_in_Verbindung_mit_GFS ab:

Darum wird auch in dem letzten Link von mir DRBD genutzt um die Daten auf beiden Geräten abzugleichen. GFS liegt nur als Dateisystem drüber und stellt den konkurrierenden Zugriff sicher. Gespiegelt wird über DRBD.

Gruß
Tschokkok

[Stefan307]

man man man erst schreibt keiner was und dann "alle" und widersprechen sich gegenseitig und haben doch alle recht weil sie das selbe meinen es aber anders sagen ...
also ich fasse mal zusammen :
- ihr gebt mir recht das DRBD geeignet ist daten über eine dünne Leitung zu syncronisieren!
- ich muß das Problem lösen was passiert wenn gleichzeitige Schreibzugriffe auf ein und den selben Speicherbereich erfolgen  Cluster FS

frag ich mich jetzt nur ob es nicht einfachen wäre das nicht auf Device sondern auf failsystem ebene zu machen...
nur was macht rssync z.b. wenn sich der datenbestand beim abglich ändert ...?

Ok, der Groschen ist gerade gefallen geht nur über das device sonnst bekommt die anwendung ja gar nicht mit das eine andere auch auf die Daten schreibt ...

also DRBD UND GFS schaun mer mal ....

[Stefan307]

So habe ein Blade:
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&rd=1&item=230273977429&ssPageName=STRK:MEWN:IT&ih=013
Ct ab Seite 178 gelesen und CentOS 5.2 wird downgeloaded
Cluster ich komme 

[karakal]

Hi alle zusammen.... Schon eine Zeit lang her dass da was los war, aber ich hätte da noch was für die Replizierung der Daten: http://hadoop.apache.org/core/docs/current/hdfs_design.html