Von Daniel Seuffert am Mo, 7. Dezember 2009 um 13:21 #
Wunderbar, sehr sinnvolle Sache, damit dürfen alle zufrieden sein. Die einen kriegen ein verbessertes FreeNAS mit FreeBSD, hinter dem iXsystems steht (yeah Matt!) und die Linux-Fraktion bekommt ein Debian-basierendes OpenMediaVault. So dürfen alle glücklichs ein imho. Und wenn genug Zeit ins Land gestrichen ist können wir hofgfentlich vermelden, daß beides zur Zufriedenheit funktioniert. In meinen Augen bereits jetzt ein sehr ungewöhnlicher Ausgang der Geschichte. Offensichtlich sind die Zielsetzungen bzw. anforderungen der Nutzer sowieso so grundverschieden (minimale NAS-Kiste auf der einen Seite und ziemlich feature-angefettetes Teil auf der anderen Seite), daß eine Fortführung in einem Projekt sinnlos gewesen wäre.
> Offensichtlich sind die Zielsetzungen bzw. anforderungen der Nutzer sowieso so grundverschieden (minimale NAS-Kiste auf der einen Seite und ziemlich feature-angefettetes Teil auf der anderen Seite), daß eine Fortführung in einem Projekt sinnlos gewesen wäre.
Ich frage mich gerade was man noch alles für Features für ein NAS benötigt. Ich meine FreeNAS bringt alles mit was man benötigt um ein NAS aufzusetzen. Nicht mehr, nicht weniger. Alles was darüber hinausgeht (z.B. Firewall, HTTP-Server, usw.) ist in meinen Augen kein NAS mehr, sondern ein ganz normaler Server
Ich glaube es geht eher um Features wie Fullsnapshots, inkr. Snapshots, RAID-Verwaltung, Datenabgleich zwischen NAS, Rechteverwaltung, ... . Also Aufgaben die im Weitergefassten sinn noch sinnvoll für ein NAS sind.
Wie man dem verlinkten Artikel und seinen Kommentaren entnehmen kann, fehlt FreeNAS u.A.
- besseres Powermanagement - Überwachung der Hardware-Sensoren - Wake on LAN - Lauffähigkeit auf Embedded Prozessoren, z.B. ARM oder MIPS - bessere Unterstützung aktueller Serverhardware - bessere Performance von Samba - NFSv4 - Hochverfügbarkeitsfunktionen
Zitat: "Wake-On-LAN (WOL) würde funktionieren. Ferner bietet Linux ein funktionierendes Hardware-Sensor-Framework (lmsensors), das in FreeNAS bisher schmerzlich vermisst wird. Die Geschwindigkeit von Samba soll besser sein, und es können Hochverfügbarkeits-Funktionen und NFSv4 verwirklicht werden. Updates des Systems wären einfach zu machen, und die Treiberunterstützung wäre generell besser."
Ich denke, das ganze ist nicht primär eine Frage der Machbarkeit, sondern des Aufwandes. Das Debian-Projekt hat hier schon eine Menge Vorarbeit geleistet, auf der man einfacher aufbauen kann.
Von bsdforen.de am Mo, 7. Dezember 2009 um 23:25 #
Für das Sensor Framework(von den Puffy Leuten) gibts ein Patch, der (hoffentlich) irgendwann mal in FreeBSD reinkommt. Und wie schon gesagt, 0.7 basiert sicherlich noch nicht auf FreeBSD 8.
Von Daniel Seuffert am Di, 8. Dezember 2009 um 10:12 #
Das ist mir klar Yamagi, aber es ging ja nicht um den Beitrag von diesem ominösen "bsdforen.de", wer immer der/die sein mag, sondern um die Aussage von Theile, welche hier "SailorMoon" kritiklos übernommen hat (vermutlich ist SailorMoon kein BSD-Nuzer, sonst hätte er das so nicht geschrieben). Ich hatte schon an anderer Stelle hier geschrieben, daß ich manches verstehen kann an Kritik seitens Theile, aber speziell an dem Punkt WoL bleibt mir nur Kopfschütteln. Also das funktioniert einfach, Punkt, aus, Amen, Ende. Ob das nun nicht tut weil die FreeNAS-Leute gestripped haben oder es falsch konfiguriert haben oder nicht können entzieht sich meiner Kenntnis. Ich will nur klarstellen, daß dieses Argument nicht haltbar ist und in den Bereich der Fama gehört.
Man muss sich nur mal ansehen, was andere - Linux basierte - vorkonfigurierte NAS an Funktionen mitbringen. Vom UPNP server bis zum Downloadmanager, vom automatischen Backup angeschlossener USB Geräte bis zu optionalen Spezialservern. Ob das sinnvoll ist oder nicht ist Geschmackssache.
Die einen wollen ein ein performantes und stabiles System, die anderen wollen ein System, das ihnen möglichst viele Möglichkeiten bietet. Beides lässt sich nur schwer unter einen Hut bringen.
ich denke, das Problem ist, dass FreeNAS so gut wie gar nicht zu erweitern ist. Ich spreche jetzt auch nicht von den typischen Mediaserver und Torrent Sachen. Ich wollte meinen abgerauchten NSLU2 ersetzen. FreeNAS war hier ne super Sache. Nur hätte ich auch gerne noch ne PostgresDB laufen lassen. und hier wirds schwierig. Selbst die passenden FreeBSD Pakete liesen sich nicht out of the box installieren. Nach einen Neustart war der User pgsql (aka postgres) nicht mehr da, etc. MySQL lässt sich mit Klimmzügen einrichten (laut Inetforen). Brauch/will ich aber nicht. O.K. ein FreeBSD Freak bringt es wahrscheinlich ohne Probleme hin.
ich bin bereit zu erfahren wie es geht. Die Installation über das Webinterface lief laut Konsole ohne Probleme, User und Gruppe wurden angelegt (laut Konsolenausgabe). Beim Initialisieren des Custers gabs aber die ersten (Rechte-) Probleme. Beim Reboot war dann weder die Gruppe noch der User mehr da. Die "normale" FreeBSD Anleitung half hier nicht wirklich. Aber wie gesagt, wenn Du mir sagst wie, teste ich gerne nochmal (kannst mir auch einfach den Link geben).
Von Daniel Seuffert am Mo, 7. Dezember 2009 um 17:43 #
nuja, das liegt jetzt aber nicht an FreeBSD an sich sondern am Konzept von FreeNAS. Wenn Sie auf ein "normales" FreeBSD setzen würden, dann wäre das kein Thema, würde aber mehr Resourcen verbrauchen. Das ist aber imho in heutigen Zeiten mit leistungsstarker Hardware bis in unterste Bereiche aber kein Argument mehr. Man hat dies offensichtlich erkannt und das "neue" FreeNAS von iXsystems wird das siche rnicht aufweisen. In diesem Sinne handelt es sich um hiistorsich gewachsene Altlasten aus einer Zeit als Hardware noch deutlich kostbarer war. Bedeutet aber dann auch, daß man nicht seinen zB. ausrangierten Pentium III mit von mir aus 256 MB ram mehr wiederverwenden kann. Das sollte jedem bewußt sein (geht aber mit z.B. ZFS sowieso nicht ramtechnisch).
> Ob das sinnvoll ist oder nicht ist Geschmackssache.
Ein NAS ist ein NAS und kein Mediaserver oder sonst irgendwas. Der Sinn eines NAS ist es Plattenplatz über ein Netzwerk bereitzustellen. Und diese Aufgabe erledigt es gut genug. Für alles was darüber hinausgeht, gibt es das "richtige" FreeBSD oder irgendeine Linux-Distribution.
Du ziehst eine Grenze wo es keine gibt. Viele NAS-Lösungen haben solche Features, und das ist für viele User auch durchaus von Vorteil. Zumal sie auch gleich eine gut nutzbare Adminoberfläche bieten, die teils besser sind als das was die Linux-Distries selbst mitbringen.
die gute Oberfläche etc. waren ja auch ausschlagegebend für mich, dass ich mir FreeNAS mal ansehe. Ich wollte aber auch eine Postgres DB vom Desktop ins Netz setzen (wenn ich schon dabei bin). Und hier gab sich FreeNAS einfach sehr verschlossen. Wobei ich jetzt nicht beurteilen kann, woran es liegt. Ich wollte damit auch nicht das Projekt verurteilen, nur ist mir das halt zu wenig für zuhause (wenn ich schon einen Rechner laufen lasse).
Von Daniel Seuffert am Mo, 7. Dezember 2009 um 17:53 #
Sagen wir es ganz nüchtern: Jedes System sollte die Anforderungen erfüllen, die der Nutzer an es stellt. Ob das dann ein NAS ist oder ehr ein "richtiger" Server steht auf einem anderem Blatt, dann muß man eben auch entsprechende Hardware einsetzen. Wer auf ZFS setzen will braucht sowieso keine schmale Kiste, sonst wird er nicht glücklich. Wenn er dann schon eine entsprechende Kiste einsetzt stellt sich für mich gleich die Frage ob diese Kiste nicht für andere Dinge gut sein sollte, von Multimedia bis mail bis keine Ahnung was, you name it. Ob ich auf der gleichen Kiste eine Firewall und einen Apache kaufen lassen möchte darf ich für mich definitiv verneinen, aber das mag jeder sehen wie er will. Mir scheint du bist verliebt in das ursprünliche Konzept von FreeNAS. Nichts dagegen aber es gibt halt auch noch andere Wünsche und warum sollte der Nutzer nicht schnell noch ne jail auf seinem TB-großen NAS anlegen und was anderes draufpacken (ich rede nicht von sicherheitsrelevanten Dingen wie einen HTTP-server)?
Aus meiner Sicht sollte FreeNAS resp. die FreeNAS Truppe erstmal bestehende Features & die Doku auf einen ordentlichen Stand bringen bevor sie darüber nachdenken das Projekt zu teilen und weiterzuentwickeln.
Nur mal drei konkrete Beispiele/Kritikpunkte aus meinen persönlichen Erfahrungen mit FreeNAS: Ich habe bei uns in der Firma aus einem ausrangierten PC (P4 3GHz/1GB RAM/2x1TB HDD) ein kostengünstiges NAS zusammengebaut zur Anbindung an zwei Citrix Xen-Server (Virtualisierungsserver).
1) Hohe CPU Last: Bei der Einbindung des FreeNAS Server als NFS-Server an die Xen-Server zeigte der NAS-Host massive CPU Last beim Zugriff auf den NFS-Share (> 40%). Nach Installation von Debian Etch produzieren NFS-Zugriffe nur noch 10%. Meine Tests mit der iSCSI Target Implementierung von FreeNAS 0.69.2 (Muad'Dib) zeigten ähnlich hohe Lasten. Ein NAS Betriebssystem soll IMO Resourcen verwalten und nicht verbrauchen. Sonst kann ich mir gleich nen Windowsserver aufsetzen :-(
2) Fehlerhafte (?) iSCSI Targetimplentierung in FreeNAS 0.69.2 (Muad'Dib): Die Nutzung der FreeNAS iSCSI Target als virtuelle Festplatte für Virtualbox ging einfach nicht (ominösen Fehlermeldungen). Andere Lösungen (Windows iSCSI Cake) und Linux iSCSI Enterprise Target (im Userspace) funktionierten hingegen einwandfrei.
3) Mangelhafte bzw. garnicht vorhandene Doku: Beim Wechsel von FreeNAS 0.69.2 (Muad'Dib) auf FreeNAS 0.7 (Khasadar) wurde die iSCSI Target Implementierung komplett getauscht. ................ Replace iSCSI target by istgt. ................ Inzwischen ist zumindest auf der Webseite der Target vernünftige Doku vorhanden: http://www.peach.ne.jp/archives/istgt/
Zum Zeitpunkt meiner Tests mit Win2k8 im Cluster war gar keine Doku im Hinblick auf die supporteten iSCSI Features zu finden.
Ich denke FreeNAS "verspielt" viele Chancen eingesetzt zu werden. Ich persönlich würde FreeNAS auch zu Hause nicht einsetzen, sondern zu Debian (oder einer anderen Linuxdisti) greifen und exakt nur die Features aufsetzen, die ich brauche.
Wirklich schade, denn von der Oberfläche her und der Grundidee finde ich so etwas wie FreeNAS toll und jeder dem schon mal ein "propritäres" NAS abgeraucht ist und man aufgrund ominöser Filesystem-Strukturen nicht mehr an die Daten rankommt, der wird offene Lösungen mit Kusshand nehmen.
> Bei der Einbindung des FreeNAS Server als NFS-Server an die Xen-Server > zeigte der NAS-Host massive CPU Last beim Zugriff auf den NFS-Share > (> 40%).
In virtuellen Umgebungen: 'sysctl kern.hz=100'. Zumindest unter vmware und virtualbox gibt es nachweislich einen signifikanten Unterschied in der CPU-Last. XEN hatte ich noch nicht am laufen, aber das wäre die erste Adresse dem Problem beikommen zu wollen.
> Die Nutzung der FreeNAS iSCSI Target als virtuelle Festplatte für > Virtualbox ging einfach nicht (ominösen Fehlermeldungen).
Das BSDs überhaupt unter virtualbox laufen ist wohl ein hübscher Seiteneffekt der Entwicklung. SUNs Prioritäten liegen woanders.
ich habe mich wohl missverständlich ausgedrückt. Die deutlich höhere CPU Last zeigte FreeNAS auf einem physikalischen Host (nix virtualisiert). Da finde ich 40% Last bei zwei angebundenen NFS Clients doch ein wenig hoch, wenn man im Vergleich die 10% eines Debian sieht :)
Bezüglich VirtualBox hatte ich nicht FreeNAS in VirtualBox laufen, sondern lediglich vom selben physikalischen FreeNAS Host eine iSCSI Target exportiert, die einer VBox VM auf einem Linuxserver als virtuelle Festplatte dient. VirtualBox unterstützt hier nämlich neben Dateien auch iSCSI Targets und das wollte ich aus Neugier einfach mal testen.
Mit der neuen Targetimplementierung scheint es aber inzwischen zu gehen.
lg. Trächtige Tröllin
Ich frage mich gerade was man noch alles für Features für ein NAS benötigt. Ich meine FreeNAS bringt alles mit was man benötigt um ein NAS aufzusetzen. Nicht mehr, nicht weniger. Alles was darüber hinausgeht (z.B. Firewall, HTTP-Server, usw.) ist in meinen Augen kein NAS mehr, sondern ein ganz normaler Server
- besseres Powermanagement
- Überwachung der Hardware-Sensoren
- Wake on LAN
- Lauffähigkeit auf Embedded Prozessoren, z.B. ARM oder MIPS
- bessere Unterstützung aktueller Serverhardware
- bessere Performance von Samba
- NFSv4
- Hochverfügbarkeitsfunktionen
Zitat: "Wake-On-LAN (WOL) würde funktionieren. Ferner bietet Linux ein funktionierendes Hardware-Sensor-Framework (lmsensors), das in FreeNAS bisher schmerzlich vermisst wird. Die Geschwindigkeit von Samba soll besser sein, und es können Hochverfügbarkeits-Funktionen und NFSv4 verwirklicht werden. Updates des Systems wären einfach zu machen, und die Treiberunterstützung wäre generell besser."
Ich denke, das ganze ist nicht primär eine Frage der Machbarkeit, sondern des Aufwandes. Das Debian-Projekt hat hier schon eine Menge Vorarbeit geleistet, auf der man einfacher aufbauen kann.
Die einen wollen ein ein performantes und stabiles System, die anderen wollen ein System, das ihnen möglichst viele Möglichkeiten bietet. Beides lässt sich nur schwer unter einen Hut bringen.
Grüße p
Grüße p
Ein NAS ist ein NAS und kein Mediaserver oder sonst irgendwas. Der Sinn eines NAS ist es Plattenplatz über ein Netzwerk bereitzustellen. Und diese Aufgabe erledigt es gut genug. Für alles was darüber hinausgeht, gibt es das "richtige" FreeBSD oder irgendeine Linux-Distribution.
Aus meiner Sicht sollte FreeNAS resp. die FreeNAS Truppe erstmal bestehende Features & die Doku auf einen ordentlichen Stand bringen bevor sie darüber nachdenken das Projekt zu teilen und weiterzuentwickeln.
Nur mal drei konkrete Beispiele/Kritikpunkte aus meinen persönlichen Erfahrungen mit FreeNAS:
Ich habe bei uns in der Firma aus einem ausrangierten PC (P4 3GHz/1GB RAM/2x1TB HDD) ein kostengünstiges NAS zusammengebaut zur Anbindung an zwei Citrix Xen-Server (Virtualisierungsserver).
1) Hohe CPU Last:
Bei der Einbindung des FreeNAS Server als NFS-Server an die Xen-Server zeigte der NAS-Host massive CPU Last beim Zugriff auf den NFS-Share (> 40%). Nach Installation von Debian Etch produzieren NFS-Zugriffe nur noch 10%. Meine Tests mit der iSCSI Target Implementierung von FreeNAS 0.69.2 (Muad'Dib) zeigten ähnlich hohe Lasten. Ein NAS Betriebssystem soll IMO Resourcen verwalten und nicht verbrauchen. Sonst kann ich mir gleich nen Windowsserver aufsetzen :-(
2) Fehlerhafte (?) iSCSI Targetimplentierung in FreeNAS 0.69.2 (Muad'Dib):
Die Nutzung der FreeNAS iSCSI Target als virtuelle Festplatte für Virtualbox ging einfach nicht (ominösen Fehlermeldungen). Andere Lösungen (Windows iSCSI Cake) und Linux iSCSI Enterprise Target (im Userspace) funktionierten hingegen einwandfrei.
3) Mangelhafte bzw. garnicht vorhandene Doku:
Beim Wechsel von FreeNAS 0.69.2 (Muad'Dib) auf FreeNAS 0.7 (Khasadar) wurde die iSCSI Target Implementierung komplett getauscht.
................
Replace iSCSI target by istgt.
................
Inzwischen ist zumindest auf der Webseite der Target vernünftige Doku vorhanden:
http://www.peach.ne.jp/archives/istgt/
Zum Zeitpunkt meiner Tests mit Win2k8 im Cluster war gar keine Doku im Hinblick auf die supporteten iSCSI Features zu finden.
Ich denke FreeNAS "verspielt" viele Chancen eingesetzt zu werden. Ich persönlich würde FreeNAS auch zu Hause nicht einsetzen, sondern zu Debian (oder einer anderen Linuxdisti) greifen und exakt nur die Features aufsetzen, die ich brauche.
Wirklich schade, denn von der Oberfläche her und der Grundidee finde ich so etwas wie FreeNAS toll und jeder dem schon mal ein "propritäres" NAS abgeraucht ist und man aufgrund ominöser Filesystem-Strukturen nicht mehr an die Daten rankommt, der wird offene Lösungen mit Kusshand nehmen.
> zeigte der NAS-Host massive CPU Last beim Zugriff auf den NFS-Share
> (> 40%).
In virtuellen Umgebungen: 'sysctl kern.hz=100'. Zumindest unter vmware und virtualbox gibt es nachweislich einen signifikanten Unterschied in der CPU-Last. XEN hatte ich noch nicht am laufen, aber das wäre die erste Adresse dem Problem beikommen zu wollen.
> Die Nutzung der FreeNAS iSCSI Target als virtuelle Festplatte für
> Virtualbox ging einfach nicht (ominösen Fehlermeldungen).
Das BSDs überhaupt unter virtualbox laufen ist wohl ein hübscher Seiteneffekt der Entwicklung. SUNs Prioritäten liegen woanders.
ich habe mich wohl missverständlich ausgedrückt.
Die deutlich höhere CPU Last zeigte FreeNAS auf einem physikalischen Host (nix virtualisiert). Da finde ich 40% Last bei zwei angebundenen NFS Clients doch ein wenig hoch, wenn man im Vergleich die 10% eines Debian sieht :)
Bezüglich VirtualBox hatte ich nicht FreeNAS in VirtualBox laufen, sondern lediglich vom selben physikalischen FreeNAS Host eine iSCSI Target exportiert, die einer VBox VM auf einem Linuxserver als virtuelle Festplatte dient. VirtualBox unterstützt hier nämlich neben Dateien auch iSCSI Targets und das wollte ich aus Neugier einfach mal testen.
Mit der neuen Targetimplementierung scheint es aber inzwischen zu gehen.
Gruß,
Holger
www.CoreNAS.org
Grusse
Corne