PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : HA mit NFSv4?



Dellerium
31.10.08, 13:20
Hallo,

ich bin gerade dabei, ein paar Tests mit NFSv4 durchzuführen. Laut allem,. was ich bisher gelesen habe, ist NFSv4 ja stateful, da es auf TCP aufsetzt...
Weiss einer von euch, ob es dennoch möglich ist, NFSv4 in einem HA Cluster einzusetzen? Wenn NFSv4 dafür nicht explizit ausgelegt wurde, müsste die NFS Verbindung ja im Fail-Over Fall zusammenbrechen, da die zugrundeliegende TCP Verbindung ja zu einem bestimmten Knoten aufgebaut wurde... oder ist das bereits so vorgesehen worden und der Client würde in dem Fall die Verbindung im Hintergrund einfach neu aufbauen?

Hat sich schon mal wer damit beschäftigt?

Gruß Dellerium

Grind
31.10.08, 18:08
Dellerium, ich bin mir nicht sicher ob ich dich richtig verstehe aber es ist doch so dass du von allen Cluster-Knoten den Export mountest und im Fehlerfall der Dienst auf einen anderen Knoten geswitcht wird?!

bla!zilla
01.11.08, 11:34
Bei einem Cluster hast du i.d.R. einen virtuellen Knoten, mit eigener IP und eigener Mac-Adresse, mit dem der Client redet. NetBIOS benutzt ja auch TCP. Klar, ein laufender Vorgang bricht ab, aber man muss nichts umkonfigurieren im Fehlerfall.

solarix
01.11.08, 12:05
Hallo,

ich bin gerade dabei, ein paar Tests mit NFSv4 durchzuführen. Laut allem,. was ich bisher gelesen habe, ist NFSv4 ja stateful, da es auf TCP aufsetzt...
Weiss einer von euch, ob es dennoch möglich ist, NFSv4 in einem HA Cluster einzusetzen? Wenn NFSv4 dafür nicht explizit ausgelegt wurde, müsste die NFS Verbindung ja im Fail-Over Fall zusammenbrechen, da die zugrundeliegende TCP Verbindung ja zu einem bestimmten Knoten aufgebaut wurde... oder ist das bereits so vorgesehen worden und der Client würde in dem Fall die Verbindung im Hintergrund einfach neu aufbauen?

Hat sich schon mal wer damit beschäftigt?

Gruß Dellerium

Im Sun Cluster ist es moeglich, fuer andere Produkte kann ich da im Moment nicht sprechen. Aber eigentlich sollten das alle anderen auch mehr oder weniger koennen.

Dellerium
02.11.08, 16:42
Das Szenario, das wir einsetzen hat Bla!zilla schon richtig angedeutet. Zum Einsatz kommen zwei Server die aufeinander via Heartbeat aufpassen. Fällt einer aus, so führt der zweite Server die Arbeit weiter. Da NFS (2 und 3) auch UDP nützen können, kann es zustandlos arbeiten. Im Idealfall merkt daher ein Client den Ausfall nicht, da nach der Übernahme die Arbeit normal weiterlaufen kann.
Da NFSv4 (afaik) nur mit TCP arbeitet, bekommen die Clients den Ausfall mit, denn die TCP Verbindung wird ja ungültig.
Bei "richtigen" Clients, also z.B. Workstations könnte ich damit leben. Aber wir binden auch (Cluster)Server via NFS an. Und die sollen davon im Idealfall nichts merken...

Eigentlich will ich von dem ganzen NFS Zeugs im Serverbereich weg, ich muss mal schauen, ob ich die entsprechenden Systeme auf GFS oder OCFS umstellen kann... Shared Storage wäre mittlerweile vorhanden ;)

Grind
03.11.08, 22:11
Was hast du gegen NFS? Kenne kein besseres Protokoll...
Und solche performance-Anforderungen dass man SAN braucht hat man doch so gut wie nie!

Dellerium
04.11.08, 10:34
Nun... ich kämpfe hier seit knapp 3 Jahren mit NFS...

Wir setzen es auf dem zentralen Fileservern (HA via Heartbeat) ein um die Dateisysteme für die Linux Clients und Server zu exportieren. Mal abgesehn davon, das es bis Version 3 tierisch unsicher war (das hat sich ja zum Glück mit v4 geändert - aber das setzen wir bisher noch nicht ein, da so eine Migration wohl geplant werden muss und ich bisher einfach nicht ide Zeit hatte...) habe ich ab und an mal das Problem das wir etwas an den Exports ändern müssen und anschliessned der eine oder andere Client ein "Permission Denied" bekommt. Manchmal hilft dann ein exportfs weiter, manchmal hilft es auch nur, einfach etwas in der Konfiguration zu ändern (irgend ein Flag das das wir nicht benötigen) und anschliessend nochmal via exportfs zu exportieren. Dann kann ich das gerade geänderte Flag wieder entfernen, nochmal exportieren und dann läuft es i.d.R. wieder. Sowas mach einfach keinen Spass - auch weil es nicht reproduzierbar ist und man auch keine vernüftigen Debug Meldungen bekommt.
In Verbindung mit den Clients wäre es noch kein so grosses Problem. Aber unsere Cluster beziehen ebenfalls via NFS Daten vom Fileserver. Und das macht mir dann schon was. Wozu treibe ich den Aufwand für die Pflege der Cluster, wenn dann NFS ab und an mal Amok läuft und die Ursache nicht herauszufinden ist?

Ein SAN stellt man sich ja auch nicht nur wegen der Performance hin - Wobei bei uns schon die Performance der Grund war ;) Allerdings nicht die Performance auf dem Fileservern sondern für einige Applikationen die recht IO intensiv sind und im Clusterbetrieb laufen sollen. Daher will und werde ich da nicht mit DRBD anfangen. Da sowieso ein SAN angeschaft werden musste und ein paar Platten mehr oder weniger nicht mehr in Gewicht fielen, werden die Fileservices in diesem Zuge ebenfalls auf das SAN migriert.