FreeBSD als Cluster - Clusterdateisystem?

I

igno2k

Member
Hallo zusammen,

ich überlege im Moment FreeBSD für eins meiner nächsten Projekte zu wählen: einen HA Webcluster. Dieser soll eigentlich mit Debian gebaut werden. Als Clusterdateisysteme hatte ich da an GFS oder OCFS gedacht. Die Datenträger sollten übers Netz per iSCSI oder ATAoE exportiert werden.

Gibt es Vergleichbares für FreeBSD? Eine freie iSCSI / ATAoE Implementation? Ein performantes und ausgereiftes Clusterdateisystem?

Für den Loadbalancer und die Failoverlösung habe ich bereits die passenden Programme gefunden, die es sowohl unter Linux als auch unter BSD gibt.

Matthias
 
Wofür braucht ein HTTP-Cluster ein Clusterfilesystem?

GFS, OCFS und GoogleFS kannst du jedenfalls knicken. Vielleicht hast du aber mit GlusterFS Erfolg? Ansonsten wuerde ich zu NFS, besser noch rsync raten.
 
Die Anwendung, die auf dem HTTP Cluster laufen wird, kann Dateien im WWWROOT und an anderen Stellen ändern - sprich schreiben und löschen. Hat man nun mehrere Application Nodes, müssen alle in Echtzeit denselben Datenstand haben. Daher ein Cluster Dateisystem.

rsync fällt raus, da es nicht in Echtzeit arbeitet. NFS hat Probleme mit dem Locking der Dateien. GlusterFS? Hab ich in den Ports leider nichts gefunden. Unterstützt FreeBSD das überhaupt?

Kann FreeBSD denn Partitionen via iSCSI oder ATAoE exportieren? Oder gibt es andere Möglichkeiten hierfür unter FreeBSD?

Matthias
 
iSCSI oder AoE nuetzt dir nichts, weil da immer nur ein Host auf das FS zugreifen kann. NFS locking innerhalb von FreeBSD funktioniert, selbst mit Linux-Clients.

GlusterFS basiert auf FUSE, und hat eine ansehnliche Liste von Features. Ob's laeuft? k.a.

Dass im WWWROOT rumgeschrieben wird, halte ich aber fuer einen Designfehler. Kannst du nicht auf eine Art Datenbank zurueckgreifen? Da hast du wenigstens *richtige* Transaktionen.
 
Klar kann man iSCSI / ATAoE rw auf mehreren Clients gleichzeitig nutzen. Für das Locking ist dann ja das Clusterdateisystem zuständig.

Von FUSE basierten Lösungen halte ich aus Erfahrung nicht allzuviel - so eine Lösung würde wegfallen.

Das NFS Locking unter FreeBSD läuft also ohne Probleme? Ich werde das mal testen und schauen wie gut das performt.

Im WWWROOT werden nicht direkt Änderungen durch die Webapplikation gemacht. Per FTP (evtl. auch bald WebDAV) Zugriff können (gleichzeitig) Änderungen gemacht werden. Am wichtigsten sind jedoch die DATA Verzeichnisse, die durch die Webapplikationen verändert werden. Sprich Bilder, Dateien jeder Art, automatische Thumbnails und und und. Muss also in Echtzeit gesynct werden, um überall denselben Datenbestand zu haben.

Eine Umstellung auf die Speicherung aller Daten in einer DB ist keine Alternative, da hier die komplette Applikation geändert werden müsste (bereits seit 2001 in ständiger Entwicklung). Ein Datenbank-Backend gibt es "nur" für alle Formen von Textdaten.

Matthias
 
NFS Locking läuft unter FreeBSD ohne Probleme. Davon abgesehen hat FreeBSD aber derzeit kein richtiges Clusterdateisystem, weder UFS noch ZFS können (entgegen teils anderer Gerüchte) geclustert werden. Das wird HAMMER können, das in Entwicklung befindliche Dateisystem von DragonflyBSD.
 
Danke für die Antwort Yamagi.

Das ist schade, da ich denke, dass Clusterdateisystem wie GFS bzw. OCFS in Sachen Performance und Stabilität bei einem solchen Einsatzgebiet NFS voraus sind. Trotzdem werde ich das mal nächste Woche testen. Vielleicht ist der Unterschied doch nicht so hoch.

Matthias
 
Hi,

selbiges Design habe ich auch am Werken.

GIbt aber extreme Probs mit nfs ... ich bin noch am werkeln ob man diese weg bekommt.

( Dateien werden angelegt, sind aber für andere Webserver nicht sichtbar, rekursives löschen funzt nicht immer und so weiter .... )


Sind jetzt 4 Webserver die so arbeiten.

Gruß
Kai
 
kai_001 schrieb:
Hi,

selbiges Design habe ich auch am Werken.

GIbt aber extreme Probs mit nfs ... ich bin noch am werkeln ob man diese weg bekommt.

( Dateien werden angelegt, sind aber für andere Webserver nicht sichtbar, rekursives löschen funzt nicht immer und so weiter .... )


Sind jetzt 4 Webserver die so arbeiten.

Gruß
Kai
Zum Vergrößern anklicken....

Hallo Kai,

du rätst also eher davon ab NFS für viele gleichzeitige Schreib- und Lesezugriffe zu verwenden? Wie lange hast du das so im Einsatz? Wie performt das mit dem NFS Dateisystem?

Gibt es bei NFS evtl. Caching oder so, dass die anderen Server von den Änderungen am Dateisystem nichts mitbekommen? Ich glaube NFS ist hierfür auch eigentlich nicht gemacht :/

Matthias
 
Hallo Matthias,

performen tut es gut ... wenn die Probleme nicht währen. Abraten würde ich nicht sagen, teste es einfachmal. Im Netz gibt es viele Threads grade im Bezug auf NFS und rm -rf. Im Einsatz habe ich es jetzt seit knapp 2 Jahren, Project ist gewachsen und langsam stellen sich diese genannten Sachen als doch größeres Problem dar :-(. Bin jetzt erstmal wieder am intensiven Testen und hoffe es so hinzubekommen.

Noch ein großes Problem ist, man kann NFS ( < Version 4 ) nicht clustern, also wenn der NFS Server wegbricht ist Handarbeit angesagt. Wollte es mit Carp auf 2 Server verteilen, ging aber in die Hose. Muss mich da nochmal zwecks Version4 schlaumachen.

Hier noch ein aktueller Thread von mir: klick

Gruß
Kai
 
Dass das Clustern von NFS<4 nicht ohne Weiteres möglich ist, wäre nicht so das Problem. Wichtig ist, dass alle Clients den gleichen Datenstand haben und das in Echtzeit. Und dann darf es natürlich keine Lockingprobleme geben.

Ordner gelöscht werden auch hin und wieder. Wenn das natürlich nicht sauber funktioniert, ist das schon ein Problem. Spätestens dann, wenn Ordner mit demselben Namen neu erstellt werden sollen.

Gibt es unter FreeBSD weitere Dateisysteme, die sauberes Locking und gute Performance beherrschen? Ein echtes Clusterdateisystem scheint es ja nicht zu geben :/

Matthias
 
Hi!

Hast du schon eine Lösung gefunden?

Bin gerade dabei einen Webserver Cluster zu konzipieren.
Die Frage ist jetzt eben, ob die Daten einzeln auf den jeweiligen Maschinen liegen und gesynct werden, oder ein gemeinsamer Datenstorage die Webapplikation anbietet.

Wenn keine Änderungen durch die Webuser an den jeweiligen Hosts bzw. am Webinhalt gemacht wird, dann könnte es ja theoretisch funktionieren, dass man die Hosts lesend auf ein NFS Share zugreifen lässt. Und es dann eben einen "Master" Host gibt, von welchem aus man die Änderungen auf das NFS Share machen kann (vollzugriff)?!

Also solch eine Lösung war mittels einer NetApp kein Problem, arbeitete mit NFSv3. Auch aktiv/passiv Cluster wurden so realisiert, das locking sprang genau dann per api um, wenn der hearbeat den aktiven host wechselte.

Was mir noch fehlt, ist die Datenbankanbindung. Ich möchte einen mysql cluster mit n Nodes. Dieser sollte getrennt vom Webcluster arbeiten. Für den Webcluster verwende ich HAProxy (mittels heartbeat aktiv-passiv)

Aber für den mysql cluster habe ich seitens freebsd noch keinen passenden load balancer gefunden! HAProxy funktioniert da nicht so zuverlässig...
 
worel schrieb:
Hi!

Hast du schon eine Lösung gefunden?

Bin gerade dabei einen Webserver Cluster zu konzipieren.
Die Frage ist jetzt eben, ob die Daten einzeln auf den jeweiligen Maschinen liegen und gesynct werden, oder ein gemeinsamer Datenstorage die Webapplikation anbietet.

Wenn keine Änderungen durch die Webuser an den jeweiligen Hosts bzw. am Webinhalt gemacht wird, dann könnte es ja theoretisch funktionieren, dass man die Hosts lesend auf ein NFS Share zugreifen lässt. Und es dann eben einen "Master" Host gibt, von welchem aus man die Änderungen auf das NFS Share machen kann (vollzugriff)?!

Also solch eine Lösung war mittels einer NetApp kein Problem, arbeitete mit NFSv3. Auch aktiv/passiv Cluster wurden so realisiert, das locking sprang genau dann per api um, wenn der hearbeat den aktiven host wechselte.

Was mir noch fehlt, ist die Datenbankanbindung. Ich möchte einen mysql cluster mit n Nodes. Dieser sollte getrennt vom Webcluster arbeiten. Für den Webcluster verwende ich HAProxy (mittels heartbeat aktiv-passiv)

Aber für den mysql cluster habe ich seitens freebsd noch keinen passenden load balancer gefunden! HAProxy funktioniert da nicht so zuverlässig...
Zum Vergrößern anklicken....


grundsaetzlich solltest du dich mit dem hauseigen cluster system von
mysql beschaeftigen. dann musst du nicht irgenwelche hartbeats etc utzen (
ich selber halte von hartbeat ueberhaupt nix )

theroretisch sollte eine mysql cluster mit 2 maschinen machbar sein
vorrausgesetzt man benutzt jails.

man kann z.b. den nbd in einem jail laufen lassen.

ansonsten mal hier lesen mysql cluster

holger
 
Bezüglich MySQL Cluster:

die Data Nodes brauchen MASSIG Ram - d.h. wenn die Anforderung nicht zu 100% da ist, zahlt es sich imho echt nicht aus. Mit 5.1 wieder ein wenig anders...
Und auch hier hast du am besten 2 SQL Nodes (API Nodes), über welche die Data Nodes abgefragt werden. Die beiden wären schön per loadbalancer aufzuteilen.
(damit es eine zentrale Anlaufstelle für die App. gibt und hier nicht herumgedoktert werden muss)

Ich bin jetzt vom cluster wieder weg, hin zu einer anderen redundaten MySQL Variante welche ich mit einem loadbalancer abfragen kann. Da bin ich gerade am abklären...

Das Problem mit HAProxy ist, dass es derzeit noch keinen Check für mysql gibt. Workaround: ein Script am (auf den) Destinationhost(s) laufen lassen welches die DB abfrägt und einen Status zurückgibt. Dieser Status wird dann von HAProxy abgefragt. Nur so lässt sich verhindern dass der HAProxy auch dann noch an einen Node Verbindungen weitergibt, wenn dieser verreckt ist.

PS: falls jemand eine Variante kennt, womit ich auf mindestens 2 mysqlnodes eine redundante DB fahren kann, dann her damit - wiegesagt, sollte per loadbalancer angesprochen werden - einer der kisten müsste also abrauchen dürfen :D
 
worel schrieb:
Bezüglich MySQL Cluster:

die Data Nodes brauchen MASSIG Ram - d.h. wenn die Anforderung nicht zu 100% da ist, zahlt es sich imho echt nicht aus. Mit 5.1 wieder ein wenig anders...
Und auch hier hast du am besten 2 SQL Nodes (API Nodes), über welche die Data Nodes abgefragt werden. Die beiden wären schön per loadbalancer aufzuteilen.
(damit es eine zentrale Anlaufstelle für die App. gibt und hier nicht herumgedoktert werden muss)

Ich bin jetzt vom cluster wieder weg, hin zu einer anderen redundaten MySQL Variante welche ich mit einem loadbalancer abfragen kann. Da bin ich gerade am abklären...

Das Problem mit HAProxy ist, dass es derzeit noch keinen Check für mysql gibt. Workaround: ein Script am (auf den) Destinationhost(s) laufen lassen welches die DB abfrägt und einen Status zurückgibt. Dieser Status wird dann von HAProxy abgefragt. Nur so lässt sich verhindern dass der HAProxy auch dann noch an einen Node Verbindungen weitergibt, wenn dieser verreckt ist.

PS: falls jemand eine Variante kennt, womit ich auf mindestens 2 mysqlnodes eine redundante DB fahren kann, dann her damit - wiegesagt, sollte per loadbalancer angesprochen werden - einer der kisten müsste also abrauchen dürfen :D
Zum Vergrößern anklicken....

hi

die idee von mir war ja die das man zum testet erstmal 2 physische kisten nimmt den cluster aufsetzt und
die einzelenen funktionen in jails verteilt .

wenn die performance dan nicht ok ist kann man immer noch aufruesten.

alternativ
solltest du dir mal den relayd ( oder vormal < 4.3 hoststated ) anschauen

laeuft zwar nur zz unter openbsd hat aber die moeglichkeit eigene check scripte
mit einzubiden , somit koennte man z.b. ein perl oder php script schreiben
was die verfuegbarkeit der db prueft .

man relayd.conf

hinzu kommt das es sehr schoen mit carp zusammen arbeitet. eigenlich die ideale basis fuer eine ha loadblancer der vor der db arbeitet.

holger

holger
 
Hi,


Nur so als Kranke Idee :-)

Nimm ggate und gmirror.

Ich hab sowas mal aufgesetzt. Läuft auch :-)

Einfach 2 Platten oder 3 Pro Server.
Dann jeweils die Platten Mirrorn und 1 oder 2 Platten mit Gate Exportieren.
Dann am 2. Server einbinden und mit gmirror das ganze spiegeln.

Die Lösung ist Krank, aber hat bei mich gefunzt :-)

Als Ausfall Mechanik hab ich ifstated genutzt und einige Scripte dazu gebastelt für den jeweilgen Fehlerfall.
 
Hi,

hat sich vielleicht in den letzten Jahren etwas getan? Ich probiere gerade wieder einmal mit HAST auf FreeBSD 8.2RC3 herum und es funktioniert leider immer noch nicht
Feb 23 08:03:20 hastb ucarp[1261]: [WARNING] Switching to state: BACKUP
Feb 23 08:03:20 hastb ucarp[1261]: [WARNING] Spawning [/usr/local/bin/vip-down.sh em0 192.168.0.37]
Feb 23 08:08:59 hastb hastd[1274]: [test] (secondary) Unable to receive request header: Socket is not connected.
Feb 23 08:09:04 hastb hastd[908]: [test] (secondary) Worker process exited ungracefully (pid=1274, exitcode=75).
Zum Vergrößern anklicken....

Ich überlege, CARP einzusetzen und die Festplatten mit rsync zu synchronisieren, allerdings bin ich davon nicht sonderlich überzeugt.

Viele Grüße, Morfio
 
Morfio schrieb:
Hi,

hat sich vielleicht in den letzten Jahren etwas getan? Ich probiere gerade wieder einmal mit HAST auf FreeBSD 8.2RC3 herum und es funktioniert leider immer noch nicht


Ich überlege, CARP einzusetzen und die Festplatten mit rsync zu synchronisieren, allerdings bin ich davon nicht sonderlich überzeugt.

Viele Grüße, Morfio
Zum Vergrößern anklicken....

Guten Morgen. :-)

Stehe gerade vor dem gleichen Thema, im Moment versuche ich das ganze ebenfalls über HAST was den Storage angeht, abzufackeln und CARP für die Netzwerke zu nehmen.

Aber das löst das Problem für die Services nicht, im Moment tendiere ich dazu Heartbeat auszuprobieren. Bei mir soll es eine reine Failover Lösung sein. Mal schauen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben