HAST - Neuer Wiki-Artikel - Fragen / Anmerkungen

M

m4rkus

Well-Known Member
Hallo zusammen, (Hallo Yamagi).

Um den Ursprungsartikel nicht zu weit abdriften zu lassen mal hier die Fortführung:
Yamagi schrieb:
Ich klinge bei sowas immer geschwollen. Aber trotzdem, hier mal schnell zusammengekleistert: https://wiki.bsdforen.de/freebsd:hast_best_practices
Zum Vergrößern anklicken....

Sehr interessant zu lesen.

Fragen:
  • Im Beispiel ist also ein RaidZ1 mit 4 Platten / Partition, damit im Falle eines Ausfalls einer Platte lokal auf dem Node noch alles funktioniert
  • Jede Partition hat ein Gegenpart über HAST und der Zpool wird über alle Partitionen angelegt, richtig?
  • Manche Tutorials legen erst einen ZFS-Pool an (lokal) und machen dann über ein ZVOL die HAST-Implementierung (quasi ZFS lokal + ZFS HAST) - Spricht da was gegen?
  • Gibt es Erfahrungswerte zur Performance (Geschwindigkeit / Zugriffszeit)
  • Was genau für eine Anwendung betreibt ihr darauf?

Danke und Gruß
Markus
 
Also, rattern wir das mal am Block runter:
  • HAST ist grundsätzlich selbst redundant. Wenn eine Festplatte (oder korrekter ein HAST-Device) auf dem Master aussteigt, erkennt HAST es und wechselt auf die entsprechende Festplatte vom Slave. Es schreibt dann über das Netz auf den Slave und liest über das Netzwerk vom Slave. So gesehen braucht ZFS keine eigene Redundanz, man kann also auf das RAIDZ1 verzichten. Aber damit verliert man ZFS Self Healing, wenn ZFS Fehler erkennt, hat es keine eigene Redundanz um sie zu korrigieren. Das kann gerade im Katastrophenfall problematisch sein: Der Master ist nicht anständig gestorben, hat Müll in das HAST geschrieben. Nachdem der Slave übernommen hat, erkennt ZFS die Datenfehler und will sie per Self Healing korrigieren. Hat ZFS keine eigene Redundanz, klappt das nicht und man darf das Backup einspielen.
  • Genau. Ich lege auf jeder Festplatte eine Partition an und lege dann HAST über die Partitionen. Das kann man praktisch endlos weit treiben, wobei man bei zu vielen HAST-Devices ein Script zum Switchen benutzen sollte. Nachts um 3 im Delirium 12 HAST-Devices zu switchen ist mittelgefährlich. :) Über die HAST-Devices kommt dann der ZPool. Ein ZPool lokal anzulegen, HAST auf ein ZFS-Volume und über das HAST ein weiteres Dateisystem ist in meinen Augen Schwachsinn. Das führt zu Doppelcaching, du doppelter Dateisystemlogik und so weiter. ZFS auf ZFS zu stapeln ist eh so eine Sache, man müsste dann als oberes Dateisystem UFS nehmen. Damit handelt man sich allerdings wieder ein fsck ein...
  • Die Anwendung ist proprietär. Das größte HAST-Setup im Haus besteht aus 12 Devices, die beiden Nodes sind über eine optische 10GBit/s Verbindung verbunden und verarbeiten eine hohe zweistellige Zahl Terabytes Daten am Tag. Betriebssystem ist noch FreeBSD 10.1, das Setup läuft seit inzwischen 2,5 Jahren einwandfrei.
 
Danke für die schnellen Antworten.

Noch zwei Fragen hinterher:
  • Switchen tust du dann händisch basierend auf externem Alarming / Monitoring?
  • Funktionieren Host-Updates wie bei einem Cluster ohne Probleme (Slave updaten, Schwenken, Slave update, Schwenken, Fertig)?
Gruß
Markus
 
  • Ja, ich switche manuell. Ich hatte es zu Beginn automatisch, aber es gab zu viele Randfälle. Das Problem geht damit los, den Ausfall des Master sicher zu erkennen und sicherzustellen, dass er nicht wieder zum Leben erwacht. ZFS ist auch nicht unbedingt glücklich darüber, plötzlich auf einem anderen Host zu laufen. Man kann zwar beiden Hosts die gleiche UUID (/etc/hostid) geben, damit ZFS den Wechsel nicht bemerkt, aber damit steigt wieder das Risiko für Splitbrains. Die nicht wirklich einfach zu startenden Anwendungen waren dann das Sahnehäubchen oben drauf. Am Ende hatte ich >1.000 Zeilen Script und musste immer noch manuell nacharbeiten, also sind wir von der Automatisierung wieder weggekommen. Statt CARP zu nutzen haben wir nun einen DNS CNAME, den wir vom Master auf den Slave umstellen.
  • Genau, so kann man updaten. Man sollte mit dem "zpool upgrade" aber warten, bis beide Seiten aktualisiert sind. Sonst kann die ältere der beiden Maschinen den schon aktualisierten ZPool eventuell nicht mehr importieren. Wenn man ausgerechnet in dem Moment ungeplant umschalten muss, wird es hektisch ("Bau schon durch, blöde Welt!").
 
Hallo nochmal,

ich versuche ja auch noch Anwendungsfälle und Gründe für und gegen HAST zu finden.
  • Bei Datenbanken würde ich glaube ich jeweils mit den entsprechenden Mitteln des DB-Systems arbeiten (PostgreSQL Replication o.ä, MySQL Galera...)
  • Bei Dateiservern muss ich bei manuellem Switch stark überlegen, ob ein ZFS send/receive nicht ebenso gut wäre. Vorteil: Weniger Overhead, Nachteil: Nicht so "konsistent" wie HAST, richtig?
  • Was wäre sonst noch als Anwendungsfall realisierbar / SINNVOLL?
Gruß
Markus
 
Bei Backup hab ich immer den Spruch "RAID != Backup" im Ohr :) - Meinst du die Möglichkeit zwischen Brandabschnitten o.ä. zu schwenken - also eher Hochverfügbarkeit / Redundanz? (RZ übergreifende Verbindungen werden glaube ich schnell teuer mit geringer Latenz).

Backup an sich würde ich glaube ich mit Send/Receive realisieren.

Gruß
Markus
 
Es kommt auf das Problem an, was man lösen möchte: HAST ist eine vergleichsweise einfache und günstige Möglichkeit um bis zu einem gewissen Grad hochverfügbare Systeme zu bauen. Man stellt sich die Kiste doppelt hin, legt das HAST rüber und gut ist. Mehr Infrastruktur wird nicht benötigt. Fällt eine aus, wirft man die andere ins Rennen. Genau das gleiche Spiel bei Backups.

Natürlich gibt es andere Möglichkeiten, die im professionellen Umfeld besser geeignet sein mögen. Wenn es möglich ist, würde ich zu einem zentralen Storage raten, das benötigt aber ein entsprechendes Netzwerk um die Daten vom Storage mit ausreichend Durchsatz und vor allem Latenz zu den Maschinen zu bekommen. Sowas wird sehr schnell sehr teuer, vor allem, wenn es bis zur kleinsten Workernode irgendwo unter dem Tisch vom Entwickler skalieren soll. Dann könnte man:
  • Ein Headnode nehmen, das Storage als externe SCSI-Enclosures anschließen und per NFS bereitstellen. Mit der entsprechend Hardware kann man sogar mehrere Headnodes an den Enclosures haben, fällt eine aus, schaltet man die andere aktiv. Das Ganze kann man noch mit gmultipath kombinieren, um Daten redundant zu speichern.
  • iSCSI kann unter FreeBSD inzwischen ebenfalls High Avalaibility Extensions, die allerdings wieder in ein entsprechendes Storage eingebunden werden müssen.
Das ist ein komplexes Thema und ich kann nicht einfach ein Setup aus dem Ärmel schütteln. ;) Ich glaube, dass es im FreeBSD Journal eine Artikelserie zu dem Thema gab. Oder vielleicht war es auch das BSD Magazine. Man findet Online auch das Eine oder Andere, wenn man etwas gräbt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben