HAST für FreeBSD committet

[Yamagi]

In den letzten Monaten hat Pawel Jakub Dawidek (Diverse GEOM-Klassen, ZFS) - hauptsächlich von der FreeBSD Foundation, OMCnet Internet Service GmbH und TransIP BV finanziert - mit HAST ein System zur dateisystemunabhängigen Storage-Replikation entwickelt. Dies erlaubt es zwei Storage-Server als Failoverover-Lösung zu betreiben, diese synchronsieren sich automatisch und wenn einer ausfällt, übernimmt der andere dessen Tätigkeit. Die Synchronisation erfolgt über IP, es können also normale Netzwerkkarten bis hin zur 10Gbit/s Klasse genutzt werden. Eine genaue Erklärung mit Hinweisen zur Einrichtung findet sich unter: http://wiki.freebsd.org/HAST. Die Entwicklung ist damit natürlich nicht beendet, dies ist nur eine erste Version, welche noch drastisch erweitert werden wird.

Date: Fri, 19 Feb 2010 00:16:20
From: Pawel Jakub Dawidek <pjd@FreeBSD.org>
To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject: svn commit: r204076 - in head: etc/defaults etc/rc.d sbin
sbin/ggate/ggatec sbin/ggate/ggatel sbin/hastctl sbin/hastd share/examples
share/examples/hast share/man/man5 sys/geom/gate

Author: pjd
Date: Thu Feb 18 23:16:19 2010
New Revision: 204076
URL: http://svn.freebsd.org/changeset/base/204076

Log:
Please welcome HAST - Highly Avalable Storage.

HAST allows to transparently store data on two physically separated machines
connected over the TCP/IP network. HAST works in Primary-Secondary
(Master-Backup, Master-Slave) configuration, which means that only one of the
cluster nodes can be active at any given time. Only Primary node is able to
handle I/O requests to HAST-managed devices. Currently HAST is limited to two
cluster nodes in total.

HAST operates on block level - it provides disk-like devices in /dev/hast/
directory for use by file systems and/or applications. Working on block level
makes it transparent for file systems and applications. There in no difference
between using HAST-provided device and raw disk, partition, etc. All of them
are just regular GEOM providers in FreeBSD.

For more information please consult hastd(8), hastctl(8) and hast.conf(5)
manual pages, as well as http://wiki.FreeBSD.org/HAST.

Sponsored by: FreeBSD Foundation
Sponsored by: OMCnet Internet Service GmbH
Sponsored by: TransIP BV

 

[bofh_hannibal]

COOOOL, endlich :-)


Ich hab das Wiki nur kurz überflogen. und etwas von ucarp gelesen. Da bin ich etwas zusammengezuckt. Weil ucarp echt mies läuft (Echt schlecht Erfahrungen gemacht) :-)

FreeBSD hat doch das Kernel CARP, da ist doch 10 Mal besser als der ucarp (c)rap.

Wenns so weitergeht können wir FreeBSD in Beasty Solaris 11 umbenennen (Aus Feature sicht, ZFS, DTRACE, ...... )

 

[MuffiXXL]

COOOOL, endlich :-)

Endlich?
Ging doch super flott!
Pawel the human coding machine.

 

[Yamagi]

Man kann natürlich jede CARP-Implementierung nehmen, es muss nicht UserCARP sein.

 

[cosmo]

Wenns so weitergeht können wir FreeBSD in Beasty Solaris 11 umbenennen (Aus Feature sicht, ZFS, DTRACE, ...... )

Wenns dann noch COMSTAR + FCoE gibt ...

 

[MuffiXXL]

Oh ja, ein COMSTAR in FreeBSD das wäre Genial!
Was nicht ist kann ja aber auch noch werden.

 

[mark05]

Man kann natürlich jede CARP-Implementierung nehmen, es muss nicht UserCARP sein.

jein, so wie ich das sehe steuert er ueber die up und down scripte auch hast.
um das mit dem kernel carp abzubilden muss man den ifstated nehmen
und die funktionalitaeten dort hinein anpassen.

das sollte zwar kein problem darstellen jedoch sieht das gescriptete schon anders aus.

holger

 

[Yamagi]

Ich würde über devd(8) gehen. Der erkennt durch ein Kernelereignis, wenn sich am CARP was ändert. Ruft daraufhin ein Script auf, das die ganze Sache weiterverarbeitet. Alternativ könnte man CARP seinen Status auch in eine Datei loggen lassen und die regelmäßig pollen, was aber natürlich nicht wirklich schön ist.

 

[mark05]

Ich würde über devd(8) gehen. Der erkennt durch ein Kernelereignis, wenn sich am CARP was ändert. Ruft daraufhin ein Script auf, das die ganze Sache weiterverarbeitet. Alternativ könnte man CARP seinen Status auch in eine Datei loggen lassen und die regelmäßig pollen, was aber natürlich nicht wirklich schön ist.

hi

devd kenne ich so nicht da es unter openbsd den nicht gibt.

hoert sich aber gut an und auch sinnvoll im gegen satz zum 2ten ansatz
da hier wieder ein proccess mehr noetig ist.

ifstated ist in sofern interesant als das es genau dafuer entwickelt worden ist
den status von carp zu erkennnen und der physischen maschine und dann zu agieren.

holger

 

[Yamagi]

HAST ist gestern in 8-STABLE eingegangen, wird also Teil des im Sommer kommenden FreeBSD 8.1 sein.

 

[kai_001]

Hey,

danke für die Info. Mal langsam anfangen zu testen


Grüße,
Kai

 

[mark05]

hi

kann sich mal jemand anschauen was sich bei hast veraendert bei
freebsd 9 ( current )

es scheint so als ob hast das auch mit ge share ten devices umgehen
kann.

was fuer ein ha storage loesung natuerlich optimal waehren ( doppelte
kapazitaet faellt weg )

2 rechner + jbod mit 2 scsi oder fc kanaelen fertig ist die storage.

holger

 

[crotchmaster]

Ist HAST eigentlich schon für den produktiven Betrieb geeignet?

 

[Yamagi]

Ja. Allerdings würde ich dann gleich 8.2 nehmen, da es dort eine Reihe Bugfixes gab.

 

[solarix]

Ja. Allerdings würde ich dann gleich 8.2 nehmen, da es dort eine Reihe Bugfixes gab.

Danke für den Tip, by the way, ich bin noch nicht so im Thema HAST drin, aber gibt es da schon Überlegungen, zum Application Failover? Oder hat das schon jemand versucht? Failover von kompletten Jails wäre natürlich richtig lecker.

 

[roman]

Ich habe mir gestern damit ein Poor-Mans-SAN gebaut: HAST + iscsi_target und ucarp um die IP hin- und herzuschubsen / Dienste zu stoppen und zu starten. Funktioniert bis jetzt reibungslos. Leider kann HAST soweit ich weiß noch keinen Primary-Primary Betrieb, aber vielleicht kommt das ja noch

 

[solarix]

Primary primary Betrieb ist für mich auch relativ uninteressant.

Für mich wäre es in der Hinsicht interessant Dienste wie Dovecot oder Apache als Failover Löesung aufzubauen.


Szenario in meinem Falle wäre folgendes..:

Zwei Büchsen bieten Apache, Dovecot/Postfix/Mysql und Openfire an.
Wenn eine Büchse weg fliegt sollte über Cluster Interconnect, der Kram auf der anderen Kiste weiter laufen.

Aber was ich bisher so gesehen habe... geht das auf HAST noch nicht, da es bisher eher auf Storage ausgerichtet ist.
Ich mag mich da aber täuschen so tief hab ich es mir noch nicht angesehen. Es ist aber nach meinem Kenntnisstand das einzige Framework das momentan für High Availabilty im Ansatz ausgerichtet ist.

 

[mark05]

Ich habe mir gestern damit ein Poor-Mans-SAN gebaut: HAST + iscsi_target und ucarp um die IP hin- und herzuschubsen / Dienste zu stoppen und zu starten. Funktioniert bis jetzt reibungslos. Leider kann HAST soweit ich weiß noch keinen Primary-Primary Betrieb, aber vielleicht kommt das ja noch

wieso ucarp ? carp ist doch in freebsd enthalten , ggf kernel neu bauen,

und fuer den rest ifstated .

holger