Hallo zusammen, ich will einen kleinen File- und Medienserver aufsetzen. Maximal drei Nutzer. Darauf laufen soll Nextcloud und ein paar andere Dienste - bis auf den Speicherplatz für Mediendateien sind also keine großen Anforderungen. Ich habe schon seit Jahren keinen Homeserver jenseits von Raspberry Pi mehr im Betrieb, deswegen die Frage ins Forum. "Klassisch" schreit das nach einem NAS. Was mir an diesen Geräten allerdings nicht gefällt, ist die Langzeitverfügbarkeit von Updates - die es bei den meisten Geräten einfach nicht gibt, und der Aufwand, wenn man einen Dienst installieren will, für den es noch keine fertigen Installation im Repository gibt. Also suche ich eine kleine Kiste auf mit geringer Leistungsaufnahme und geringer Geräusschemission im Idle-Zustand, auf der sich ein Debian installieren läßt und die Platz für drei bis vier 2,5-Zoll-Laufwerke (1/2x SSD, 2xHDD) bietet. (Im letzten Punkt bin ich nicht fix. Ich brauche keine Hochverfügbarkeit.) Wie heißt diese Gerätegattung? Ich nehme an, dass dieser Anwendungsfall keine Seltenheit hat. Also: Hat jemand ein derartiges Gerät im Betrieb und für welche Konfiguration aus welchen Gründen entschieden? Viele Grüße W.T.
Da ich auch keine Anforderung an Hochverfügbarkeit habe, läuft bei mir ein altes Thinkpad (T410) mit Ubuntu und einer zweiten Festplatte im Serialbay. Da ist dann quasi auch die USV schon eingebaut und wenn man will kann man den Server auch mit den vPro Features managen (AMT und so). Idle mit Display und WLAN aus und so liegt man ohne große Verrenkungen bei unter 10 Watt und hören tut man auch nichts. Falls du dann doch noch RAID willst, dann kannst ein NAS dazustellen, welches nur als iSCSI-Target arbeitet und sich um die Platten kümmert.
:
Bearbeitet durch User
Ich kann einen Selbstbau mit einnem j4105 ITX Board empfehlen. Hier gibt es eine Zusammenstellung die man ja an die eigenen Bedürfnisse noch abändern kann. https://www.elefacts.de/test-59-nas_basic_2.0__effizientes_selbstbau_nas_mit_4x_sata_im_mini_itx_format Ich habe diese Konfiguration mit einem anderen Gehäuse und nutze es mit OpenMediaVault und Kodi unter Debian als NAS und Entertainmentsystem.
Walter T. schrieb: > "Klassisch" schreit das nach einem NAS. Was mir an diesen Geräten > allerdings nicht gefällt, ist die Langzeitverfügbarkeit von Updates - > die es bei den meisten Geräten einfach nicht gibt, Die kriegst du mit FreeNAS oder OpenMediaVault, beide NAS Systeme sind Open Source, womit du prakitsch das NAS eine halbe Ewigkeit auf die nächsten Majorreleases hieven kannst, solange die Hardware mit macht. Und da der kleinste gemeinsame Nenner heute AMD64 ist, wird das wahrscheinlich noch sehr lange möglich sein. Der Nachteil ist der Resourcenbedarf eines x64 System, vor allem bei FreeNAS mit seinem ZFS Dateisystem und der Notwendigkeit von ECC RAM, womit sich weitere Einschränkungen bezüglich der Hardwarewal ergeben. Z.B: Mainboard mit C236 Serverchipsatz. Aber die Stärken von ZFS überwiegen meiner Meinung nach. Wenn es dich interessiert, kannst du dir folgenden Vortrag zu ZFS ja mal ansehen: https://www.youtube.com/watch?v=knKedtlCsa8 Aufgrund von Bit rot ist ZFS bei heutigen Plattengrößen je nach Einsatzzweck eigentlich fast schon ein muss. Bei ext4, XFS usw. hat man da keine Chance gegen kaputte Daten. Jetzt kommt es halt darauf an, wie wichtig dir das ist und welche Daten du sichern musst. Bei Bildern und Videomaterial wird's kaum eine Rolle spielen, wenn mal ein Pixel nicht mehr die richtige Farben anzeigt oder sich ein Klotzbereich von 8x8 Pixel nicht richtig dekodieren lässt. Aber falls du darauf Anwendungen sichern willst, dann sorgt ein gekipptes Bit eben unter Umständen dafür, dass das Programm nicht mehr richtig funktioniert. Siehe dazu: https://en.wikipedia.org/wiki/Data_degradation > und der Aufwand, wenn > man einen Dienst installieren will, für den es noch keine fertigen > Installation im Repository gibt. Auf FreeNAS kannst du Virtuelle Machinen laufen lassen und darin parktisch jede Distribution als Gasystem laufen lassen. Es geht aber auch mit sogenannten Jails auch leichtgewichteger als in einer VM. Offiziell als Jail unterestützt wird bspw. owncloud. Das Original, nextcloud ist nur ein Fork von diesem. > Also suche ich eine kleine Kiste auf mit geringer Leistungsaufnahme und > geringer Geräusschemission im Idle-Zustand, auf der sich ein Debian > installieren läßt und die Platz für drei bis vier 2,5-Zoll-Laufwerke > (1/2x SSD, 2xHDD) bietet. (Im letzten Punkt bin ich nicht fix. Ich > brauche keine Hochverfügbarkeit.) Im Bereich von x64 wäre das ein Intel Corei3, Pentium G4XXX oder Atom. Die Lautstärke ist mit leisen Lüftern problemlos in den Griff zu kriegen. Sparsamer geht es nur noch mit ARM CPUs, aber dann geht FreeNAS nicht mehr. Dann wäre nur noch OpenMediaVault eine Option, das aber ohne ZFS kommt. Bei ARM basierten Geräte kommen dann noch so Probleme wie die Treiberunterstützung dazu, außerdem wirst du mindesten SATA Anschlüsse haben wollen, um die SSD oder HDs irgendwo anschließen zu können. SSDs sind sparsamer als HDs und eigentlich zu bevorzugen, vor allem auch, da sie häufiges ein und ausschalten wesentlich besser vertragen als Festplatten. Ich würde auch sagen, dass sie robuster als Festplatten sind. Ihr Nachteil ist allerdings, dass die Daten auf denen nicht ewig halten. Bei Festplatten gilt das zwar auch, aber bis die magnetische Speicherung verloren geht, dauert das wesentlich länger, als die elektrische Ladung in der Flashspeicherzelle. Bei der Speicherdichte sind Festplatten natürlich auch immer noch im Vorteil, da kommt es darauf an, wie viel du speichern möchtest. > Wie heißt diese Gerätegattung? Letzten Endes ist auch ein NAS von bspw. Synology oder QNAP alles ein Computer. Was du suchst ist einfach sparsame Hardware, bei dem du deine SSDs anschließen kannst und dazu ein passendes Gehäuse und Mainboard mit der gewünschten CPU. > Ich nehme an, dass dieser Anwendungsfall keine Seltenheit hat. Also: Hat > jemand ein derartiges Gerät im Betrieb und für welche Konfiguration aus > welchen Gründen entschieden? Ich habe ein FreeNAS NAS System. Die Langzeitverfügbarkeit bezüglich Updates und ZFS waren meine Argumente dafür. Wobei man aber auch sagen muss, dass so eine Synology Diskstation, also so ein NAS Fertiggerät auch sehr lange mit Sicherheitsupdates versorgt wird. Da gibt es nämlich auch Unterschiede von Hersteller zu Hersteller. Ich habe mich aber dennoch gegen eine Synology und für FreeNAS entschieden, denn da habe ich wirklich die volle Kontrolle über die Hardware und kann gängige Komponenten auch günstig austauschen.
Walter T. schrieb: > > Ich nehme an, dass dieser Anwendungsfall keine Seltenheit hat. Also: Hat > jemand ein derartiges Gerät im Betrieb und für welche Konfiguration aus > welchen Gründen entschieden? > > Viele Grüße > W.T. wurde schon genannt, ich kann`s nur bestätigen: Microserver von HP, N54L sind gebraucht ohne Platten schon um ca. 100€ zu bekommen. CD-Laufwerk raus, SSD hinein und alle 4 Einschübe stehen als RAID oder was auch immer zur Verfügung.
Die Microserver von HP bieten sich für ein FreeNAS Gerät an, denn die kommen auch mit ECC RAM Unterstützung. Ihr Nachteil ist, dass deren Mainboards kein gängiger Formfaktor haben. D.h. wenn das Mainboard kaputt geht, dann kannst du das nicht einfach gegen ein anderes austauschen.
MiWi schrieb: > N54L sind gebraucht ohne Platten schon um ca. 100€ zu bekommen. Diese Turions sind AMDs Atom Prozessoren und ziemlich langsam. Ich bin ein bisschen skeptisch was die Anforderung "NextClound und andere Dienste" betrifft".
:
Bearbeitet durch User
Walter T. schrieb: > "Klassisch" schreit das nach einem NAS. Was mir an diesen Geräten > allerdings nicht gefällt, ist die Langzeitverfügbarkeit von Updates - > die es bei den meisten Geräten einfach nicht gibt, und der Aufwand, wenn Kürzlich ist mir ein >8 Jahre altes Synology-NAS in die Hände gefallen - liess sich problemlos auf die neueste DSM-Version upgraden (wenn auch in bestimmt 4 Schritten). Fand‘ ich durchaus bemerkenswert; trotzdem.... > man einen Dienst installieren will, für den es noch keine fertigen > Installation im Repository gibt. ...läuft bei mir u.a. deswegen inzwischen auch ein bereits genannter HP Microserver. Zieht mit 4 Platten, SSD und iLO-Karte zwar 30-40W, dafür rennt da ein Proxmox mit SMB-Freigaben einigen Containern sehr ordentlich...
Luther B. schrieb: > Diese Turions sind AMDs Atom Prozessoren und ziemlich langsam. Ich bin > ein bisschen skeptisch was die Anforderung "NextClound und andere > Dienste" betrifft". Als der Microserver vor Äonen rauskame, war der Prozessor schneller als Intels Atoms. Mittlerweile ist er es naürlich nicht mehr. Normale Athlon 64 Architektur, niedriger getaktet. Mein oller N36L schafft es problemlos und ohne ins Schwitzen zu kommen, Gigabit Ethernet mit Samba und NFS zu sättigen. Bei ZFS sollte man aber auf das RAM achten. ZFS ist gierig und Nachbeschaffung passenden alten ECC-RAMs kann teuer enden als der Server. Andere Filesysteme sind sparsamer.
:
Bearbeitet durch User
A. K. schrieb: > Bei ZFS sollte man aber auf das RAM achten. ZFS ist gierig und > Nachbeschaffung passenden alten ECC-RAMs kann teuer enden als der > Server. Andere Filesysteme sind sparsamer. RAM geht allerdings auch kaum kaputt. Wenn es läuft, dann läuft es. Eher fällt das Netzteil, das Mainboard, die HD sowieso oder die CPU aus, als das RAM. Notfalls tauscht man in 10 Jahren halt Mainboard, RAM und CPU einmal aus, den Rest kann man weiter benutzen.
Nano schrieb: > RAM geht allerdings auch kaum kaputt. > Wenn es läuft, dann läuft es. Im Prinzip ja. Wir mussten allerdings nach rund 5 Jahren sämtliche RAMs einer zweistelligen Anzahl Dell Server auswechseln (P4 Generation). Offensichtlich Serienfehler. Im restlichen Server-Zoo kommt ein Defekt mal vor, aber selten. Ich bezog mich aber auf die Kapazität. Der N36L/N54L kam mit 1-2GB, was bei ZFS etwas bescheiden sein kann. Das btrfs scheint sparsamer zu sein, meine 3GB reichen aus. > Notfalls tauscht man in 10 Jahren halt Mainboard, RAM und CPU einmal > aus, den Rest kann man weiter benutzen. In der Altersgruppe fällt schon mal ein Gehäuselüfter aus der Halterung (wieder Dell), weil die ihn befestigenden Gumminippel hoffnungslos versprödet sind. Und die Disks das Fussende der Badewanne erreicht haben. PS: Ich hatte für den N36L damals 155€ gezahlt, neu, und zu den 1GB noch 2GB ECC-RAM draufgelegt. Echtes Schnäppchen, immer noch im Einsatz, kein Ende abzusehen.
:
Bearbeitet durch User
A. K. schrieb: > Ich bezog mich aber auf die Kapazität. Der N36L/N54L kam mit 1-2GB, was > bei ZFS etwas bescheiden sein kann. Jo, Faustregel bei unseren Sysadmins: Pro TB ZFS-Storage mit 1GB RAM rechnen, wenn möglich..
Nano schrieb: > RAM geht allerdings auch kaum kaputt. > Wenn es läuft, dann läuft es. Darum geht es aber bei ECC nicht, sondern darum, daß auch bei funktionierendem RAM im Normalbetrieb durch externe Einflüsse Bits kippen können. https://stackoverflow.com/questions/2580933/cosmic-rays-what-is-the-probability-they-will-affect-a-program
A. K. schrieb: > Und die Disks das Fussende der Badewanne erreicht haben. Wo hast du denn deine Füße?
A. K. schrieb: > Ich bezog mich aber auf die Kapazität. Der N36L/N54L kam mit 1-2GB, was > bei ZFS etwas bescheiden sein kann. Das btrfs scheint sparsamer zu sein, > meine 3GB reichen aus. Ja, 1-2 GB sind bei ZFS etwas wenig. Als Richtwert wird etwa 1 GB RAM pro 1 TB Speicherkapazität empfohlen. Meinem FreeNAS System habe ich daher gleich 32 GB spendiert. Für deplucation (für die die es nicht kennen, ein Feature von ZFS um doppelt belegten Speicherplatz zu vermeiden) reicht das aber trotzdem noch nicht, bzw. wäre das nicht empfehlenswert. Anderseits brauche ich deplucation in meinem Anwendungsfall aber auch nicht, es lohnt sich aber für Leute, die viele VM betreiben. >> Notfalls tauscht man in 10 Jahren halt Mainboard, RAM und CPU einmal >> aus, den Rest kann man weiter benutzen. > > In der Altersgruppe fällt schon mal ein Gehäuselüfter aus der Halterung > (wieder Dell), weil die ihn befestigenden Gumminippel hoffnungslos > versprödet sind. Gut, das sind so Kleinigkeiten die immer mal wieder vorkommen können. Ein Lüfter kostet aber auch nicht viel. Meine sind festgeschraubt. > PS: Ich hatte für den N36L damals 155€ gezahlt, neu, und zu den 1GB noch > 2GB ECC-RAM draufgelegt. Echtes Schnäppchen, immer noch im Einsatz, kein > Ende abzusehen. Da stimme ich dir zu. Der Preis ist echt gut.
Luther B. schrieb: > Nano schrieb: >> RAM geht allerdings auch kaum kaputt. >> Wenn es läuft, dann läuft es. > > > Darum geht es aber bei ECC nicht, sondern darum, daß auch bei > funktionierendem RAM im Normalbetrieb durch externe Einflüsse Bits > kippen können. Du redest völlig am Thema vorbei. A. K. sprach wirklich von RAM, das richtig kaputt geht und dann ausgetauscht werden muss und darauf habe ich geantwortet. Natürlich hat ECC eine ganz andere Funktion, nämlich Fehler von kippenden Bits und dergleichen im laufenden Betrieb zu erkennen. Aber das ist eben etwas ganz anderes als RAM, das defekt gegangen ist.
Nano schrieb: > A. K. sprach wirklich von RAM, das richtig kaputt geht und dann > ausgetauscht werden muss und darauf habe ich geantwortet. Ich schrieb von wahrscheinlich zu schwacher Ausstattung des N54L mit RAM, wenn man ZFS im Auge hat. Mehr als 16 GB kann der ausserdem nicht und unbuffered ECC-RAM könnte heute rar/teuer sein (ZFS ohne ECC wird nicht empfohlen). Es gibt aber natürlich auch neuere Modelle mit mehr RAM. Da sollte man für ZFS dann allerdings auf ECC achten, das haben m.W. nicht alle der Microserver vorgesehen.
:
Bearbeitet durch User
A. K. schrieb: > Nano schrieb: >> A. K. sprach wirklich von RAM, das richtig kaputt geht und dann >> ausgetauscht werden muss und darauf habe ich geantwortet. > > Ich schrieb von wahrscheinlich zu schwacher Ausstattung des N54L mit > RAM, wenn man ZFS im Auge hat. Das auch, aber in dem Fall ging es dir um die Nachbeschaffung von ECC RAM nach ein paar Jahren. Siehe hier: >> Nachbeschaffung passenden alten ECC-RAMs kann teuer enden als der >> Server. Andere Filesysteme sind sparsamer. Beitrag "Re: Alternative zu NAS" Was soll eine Nachbeschaffung sonst sein, als einen RAM Riegel durch einen funktionstüchtigen zu ersetzen? Mit der ECC Funktion hat das nun wirklich nichts zu tun.
@TS Schau dir mal den HP ProLiant Microserver Gen10 an: https://www.hpe.com/de/de/product-catalog/servers/proliant-servers/pip.hpe-proliant-microserver-gen10.1009955118.html Der hat ein kleines Gehäuse, ECC RAM und auch gleich noch 4 Wechselschächte für 3,5" Laufwerke, in die man aber sicherlich auch 2,5" Festplatten einbauen kann. Für FreeNAS ist der also geeignet. Vom Preis her liegt er bei etwa 350 bis 400 €.
Man kann, wenn man will jedes Problem mit noch mehr, besserer, schnellerer und neuerer Hardware erschlagen. Die Frage des TO bezog sich mM nach vor allem auf die Möglichkeit der Software "up to date" zu bleiben. Obdas Filesystem darunter dann ZFS oder sonst was tolles ist - für einen Medienserver für 3 Personen sind Betriebskosten vermutlich relevanter als ein gekipptes Bit in einem Videofile. Denn egal wie grandios das Hardarezeug ist - nach 3 Monaten ist es veraltet und es gibt was noch besseres. Das auch Daten, die - egal auf welchem Filesystem sie herumlungern gesichert werden sollten ist ja auch ein durchaus interessantesn Thema. Daher sich an ECC für ein HomeNAS aufhängen ist mM nach mehr als nur Nerdig, da es die verfügbare Hardware dann doch sehr einschränkt. iaW: ich hab lieber einen gebrauchten preiswerten 2 Microserver als Hardwarebackup herumstehen wo ich nur die Platten übersiedeln muß (DHCP ist schon darauf vorbereitet) als das ich deutlich teurere neue Hardware kaufe, so groß sind die Kisten nicht - und es gibt genügend Leute die meinen was neues zu brauchen... Der einzige wesentliche Nachteil der Microserver ist - sie brauchen zu viel Strom für sich selbst wenn sie aktiv sind, das schaffen die ARM-basierten Kisten meistens besser.
Ansonsten eben ein normales miniITX oder µATX Mainboard mit passender CPU in einem passenden Gehäuse. Mainboards die ECC RAM Support bieten wären bswp. folgende: https://geizhals.de/?cat=mbxeon&xf=317_C236%7E4400_Mini-ITX%7E4400_%B5ATX%7E494_ECC-Unterst%FCtzung IPMI ist empfehlenswert, ebenso eines mit M.2 Steckplatz, dann kann man auf dem das OS installieren und die SATA Anschlüsse für den NAS Speicher verwenden. Schau dir vor allem die Boards von Supermicro an.
Nano schrieb: > Das auch, aber in dem Fall ging es dir um die Nachbeschaffung von ECC > RAM nach ein paar Jahren. Also wenn der A dem B beibringt, was der C gemeint hat, dann muss das zwar nicht stimmen, kann aber ein Ansatz sein, wenn C förderhin schwieg. Aber wenn der A den B beibringt, was der B gemeint hat, dann ist das Chuzpe. ;-) > Mit der ECC Funktion hat das nun wirklich nichts zu tun. Bisschen schon. Non-ECC gibts überall, registered ECC neu oder aus alten Servern auch. Unbuffered ECC war und ist weniger gebräuchlich. Das gibts, da sollte man aber drauf achten.
MiWi schrieb: > Die Frage des TO bezog sich mM nach vor allem auf die Möglichkeit der > Software "up to date" zu bleiben. > > Obdas Filesystem darunter dann ZFS oder sonst was tolles ist - für einen > Medienserver für 3 Personen sind Betriebskosten vermutlich relevanter > als ein gekipptes Bit in einem Videofile. Nun, so einfach ist es nicht. Denn wenn FreeNAS eine Option sein soll, dann geht es nicht ohne ZFS und damit auch nicht mit HW ohne ECC RAM. Ansonsten bleibt von den "up to date" Systemen nicht mehr viel übrig, außer eben OpenMediaVault. Man hat also die Wahl zwischen OpenMediaVault oder FreeNAS. Klar, man könnte mit irgendeiner beliebigen Linuxdistribution auch alles irgendwie händisch zusammenfrimmeln, aber dann sollte man auch den Arbeitsaufwand einkalkulieren. So ein NAS wie OpenMediaVault oder FreeNAS bietet eine Webgui mit der man alles einstellen kann, was man benötigt, für mehr steht natürlich auch ein Zugang via ssh zur Verfügung. Aber allein das Webinterface nimmt einem schon sehr viel Arbeit ab. > Daher sich an ECC für ein HomeNAS aufhängen ist mM nach mehr als nur > Nerdig, da es die verfügbare Hardware dann doch sehr einschränkt. Ja, aber ohne ECC schränkt man sich dann eben bei der Software bzw. den fertigen Open Source NAS Systemen ein. Und so klein ist die Auswahl bei Systemen mit ECC RAM auch nicht mehr. Man findet da schon etwas passendes. > Der einzige wesentliche Nachteil der Microserver ist - sie brauchen zu > viel Strom für sich selbst wenn sie aktiv sind, das schaffen die > ARM-basierten Kisten meistens besser. Und die Mainboards haben einen speziellen Formfaktor. Ein Austausch mit einem MB von der Stange ist also nicht so einfach bzw. nicht möglich.
Nano schrieb: > Denn wenn FreeNAS eine Option sein soll, dann geht es nicht ohne ZFS und > damit auch nicht mit HW ohne ECC RAM. Wobei ich mir nicht sicher bin, ob es sich mit dieser Besonderheit von ZFS vielleicht um ein Amok laufendes Gerücht handeln könnte. "“Authority” in this case doesn’t get much better than Matthew Ahrens, one of the cofounders of ZFS at Sun Microsystems and current ZFS developer at Delphix. In the comments to one of my filesystem articles on Ars Technica, Matthew said “There’s nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem.” Aus: "Will ZFS and non-ECC RAM kill your data?" http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/ Ich bevorzuge freilich trotzdem ECC-RAM in Servern. Ob ZFS oder nicht.
:
Bearbeitet durch User
A. K. schrieb: > Wobei ich mir nicht sicher bin, ob es sich damit nicht auch um ein Amok > laufendes Gerücht handeln könnte. Naja, das Problem ist das dir ZFS dann einfach die gesamte Platte beim scrubbing kaputt schreibt, wenn ein Bit im RAM defekt ist. Das FreeNAS Forum hat dazu einen schönen Artikel: https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/ Natürlich läuft ein FreeDOS basiertes FreeNAS auch auf einem Rechner ohne ECC RAM, aber die Daten bleiben auf dem nicht sehr lange intakt, wenn es zu einem Fehler im RAM kommt und die sind nicht selten. Bei Desktopsystemen ist so etwas egal, da stürzt im schlimmsten Fall die Anwendung oder das OS ab und dann startet man neu und alles ist wieder gut. Bei einem NAS werden die Daten auf der Platte dagegen dann kaputt geschrieben. Es gibt im FreeNAS Forum nicht wenige, die ihren gesamten ZFS Pool verloren haben, weil sie Hardware ohne ECC RAM verwendet haben.
Nano schrieb: > Naja, das Problem ist das dir ZFS dann einfach die gesamte Platte beim > scrubbing kaputt schreibt, Oder genau, die HW geht da natürlich nicht kaputt, aber die Daten die darauf sind.
Nano schrieb: > Natürlich läuft ein FreeDOS basiertes FreeNAS Korrektur, ich meinte natürlich FreeBSD basiert.
Nano schrieb: > Und die Mainboards haben einen speziellen Formfaktor. > Ein Austausch mit einem MB von der Stange ist also nicht so einfach bzw. > nicht möglich. Entweder findet man dann noch was, oder schreibt es ab und nimmt was Neues. Entscheidend für privaten Einsatz ist m.E., ob man beim Ausfall vom MB mit vertretbarem Aufwand den Inhalt der Disks ins neue System übernehmen kann.
Nano schrieb: > Naja, das Problem ist das dir ZFS dann einfach die gesamte Platte beim > scrubbing kaputt schreibt, wenn ein Bit im RAM defekt ist. Genau auf dieses Scrub of Death Szenario geht der verlinkte Artikel ein. Ich will das mangels Kenntnis der ZFS Details aber nicht bewerten.
:
Bearbeitet durch User
Ach noch etwas. Das Btrfs Dateisystem wird oftmals als ZFS Ersatz gepriesen. Auf dem Papier klingen die Features alle toll, aber in der Praxis läuft es so, dass bspw. RedHat Btrfs wieder aus ihrer Distribution rausgeschmissen hat, weil zu viele Nutzer damit ihre Daten verloren haben. Und RAID ist immer noch als experimental markiert. Damit bleiben nur Mirrors oder single Disks Konfigurationen übrig, single Disks wird man auf einem NAS wohl eher nicht wollen. Und bei Mirrors sind die Probleme von Btrfs auch noch nicht aus der Welt geschaffen. ZFS dagegen funktioniert in der Praxis einfach, es ist ausgereift und kommt direkt von Solaris, hat also schon viele Jahre reife im Servereinsatz hinter sich. Ein Weg, den btrfs in 8 Jahren noch nicht geschafft hat. Btrfs steht als Dateisystem unter OpenMediaVault zur Verfügung. Ich rate bei Verwendung von OpenMediaVault in dem Fall aufgrund der fehlenden Robustheit von Btrfs dann aber doch eher zu ext4 oder xfs.
PS: Die Aussage von Matthew Ahrens werte ich so, dass - wenn schon - dies auf alle Filesysteme und RAID Systeme zutreffen sollte, die Scrubbing verwenden.
Nano schrieb: > Und RAID ist immer noch als experimental markiert. > Damit bleiben nur Mirrors oder single Disks Konfigurationen übrig, Parity-RAID hatte einen bösen Bug drin. Ich habs bei 2 Disks aber sowieso mehr mit Mirroring. @biz würde ich btrfs nicht einsetzen, da ist in den Hauptsystemen sowieso RAID-TEC angesagt.
:
Bearbeitet durch User
A. K. schrieb: > Nano schrieb: >> Naja, das Problem ist das dir ZFS dann einfach die gesamte Platte beim >> scrubbing kaputt schreibt, wenn ein Bit im RAM defekt ist. > > Genau auf dieses Scrub of Death Szenario geht der verlinkte Artikel ein. > Ich will das mangels Kenntnis der ZFS Details aber nicht bewerten. Das Problem liegt meines Wissens nach im ARC. Das ist der Speicher der bei FreeNAS als Cache im RAM für ZFS reserviert wird. Da ZFS sehr stark von viel RAM profitiert und FreeNAS daher so eingestellt ist, dass es sehr viel RAM aus dem RAM für ZFS verwendet steigt natürlich mit kaputtem RAM die Gefahr, dass man durch Scrubbing die Daten kaputt schreibt. Denn die Wahrscheinlichkeit die kaputten Bits im RAM zu erwischen ist natürlich viel größer, wenn man sehr große Bereiche des RAMs für ZFS reserviert. Auf den typischen Desktopdateisystemen ist das etwas anders. Da begnügt sich bspw. ext4 mit einem Minimum an RAM, die Wahrscheinlichkeit, dass das Dateisystem vom kaputten Speicher betroffen ist, also genau die Bereiche für das Dateisystem reserviert werden, in denen das RAM kaputt ist, sinkt also. Insofern, ja, bei kaputtem RAM ist es besser, wenn man ein anderes Dateissystem als ZFS verwendet oder dafür sorgt, das ZFS nur noch einen Bruchteil des Speichers reserviert, aber das hat andere Nachteile. In der FreeNAS Doku wird das mit dem ARC recht gut erklärt.
A. K. schrieb: > @biz würde ich btrfs nicht einsetzen, da ist > in den Hauptsystemen sowieso RAID-TEC angesagt. Die erkennen leider kein bit rot bzw. sind keine Hilfe, wenn der Fehler auftritt. ZFS erkennt das. Ein weiterer Nachteil von HW Raid ist der, wenn man es austauschen muss, dann braucht man wieder den gleichen Raid Controller. Bei SW Raid ist das kein Problem. Außerdem bietet ZFS noch RaidZ3, d.h. da können 3 Platten ausfallen ehe man die Daten verliert. In HW gibt es das meines Wissens nach maximal nur mit 2 Platten. Als Desktopuser mag man meinen, das ist kein Problem, wenn man noch 2 Platten für die Redundanz hat. Aber im Servereinsatz fallen oftmals die Platten genau dann aus, wenn eine Platte bereits kaputt ist und dann wegen dem Umkopieren auf die neue Platte die anderen Platten stark belastet werden und in dem Prozess diese dann auch noch ausfallen. Wenn so ein Rebuild bei den Plattengrößen ein paar Tage dauert, dann steigt da auch die Wahrscheinlichkeit, weswegen es im business Bereich Leute gibt, die inzwischen nach ZFS Raidz3 verlangen. Sollte Performance kritisch sein, dann kann versuchen, diese bei ZFS mit mehr RAM und einer ZIL in den Griff zu kriegen. HW Raid braucht es dann nicht und die Datensicherheit ist bei HW Raid nicht höher, da ist SW Raid klar im Vorteil.
Nano schrieb: > Die erkennen leider kein bit rot bzw. sind keine Hilfe, wenn der Fehler > auftritt. RAID-TEC ist kein Hardware-RAID-Controller, sondern grob vergleichbar zu RaidZ3, aber von Netapp: "With RAID-TEC protection, ONTAP can use up to three spare disks to replace and reconstruct the data from up to three simultaneously failed disks within the RAID group." Ganz andere Klasse als hier im Thread betrachtet, klar. Weshalb ich das oben nur am Rande erwähnte. > ZFS erkennt das. Es gibt im Web natürlich zu allem Gegenpositionen, manchmal auch recht heftig vorgetragene. ;-) "ZFS won’t save you: fancy filesystem fanatics need to get a clue about bit rot (and RAID-5" https://www.jodybruchon.com/2017/03/07/zfs-wont-save-you-fancy-filesystem-fanatics-need-to-get-a-clue-about-bit-rot-and-raid-5/ > Aber im Servereinsatz fallen oftmals die > Platten genau dann aus, wenn eine Platte bereits kaputt ist und dann > wegen dem Umkopieren auf die neue Platte die anderen Platten stark > belastet werden und in dem Prozess diese dann auch noch ausfallen. Diese Theorie ist mir bekannt, aber in der Praxis habe ich das noch nie erlebt. Disk-Fehler gab es genug, die 2,5er SAS sterben recht häufig, häufiger als die 3,5er SAS davor, aber noch nie starben welche im Bündel.
:
Bearbeitet durch User
"ZFS benötigt ECC" ist einfach nur vielfach wiederholter Schwachsinn. Der "Scrub of Death" ist zwar möglich, aber massiv unwahrscheinlich. Ein Scrub läuft folgendermaßen ab: - Daten von Festplatte 1 lesen - Checksum von Festplatte 1 lesen - Checksum mit Daten vergleichen -> Wenn richtig, weiter gehen -> Wenn falsch, Daten von 2. Festplatte wiederherstellen Wenn wir jetzt RAM haben, der einen Block als "fehlerhaft" darstellt (falsche Checksum oder falsche Daten), obwohl er korrekt ist, werden einfach nur bereits richtige Daten ersetzt. Das ist also kein Problem. Wenn der RAM jetzt noch beim Wiederherstellen des Blocks einen Fehler macht, ist das schon etwas gefährlicher. Jedoch verifiziert ZFS auch hier die Checksum nach dem Kopieren des Blocks. Schlägt das fehl, wird die Festplatte als Defekt markiert und aus dem Array geworfen (-> ohne effektiv Daten zu verlieren). Die einzige Situation in der ein Scrub wirklich Daten zerstören könnte, ist wenn beim Wiederherstellen sowohl die Daten falsch ausgelesen werden UND der Checksumvergleich durch einen weiteren RAM Fehler auch noch eine Hash Kollision auslöst. Das ist selbst beim billigstem Consumer RAM einfach absurd unwahrscheinlich. Das ganze "Scrub of Death" Szenario ist etwas, was man mit präpariertem RAM erzeugen kann, aber nicht mit zufälligen Fehlern. Matthew Arens hat das im Arstechnica Forum vor langer Zeit auch schon mal erwähnt [1]. ZFS wird nicht dadurch schlechter als NTFS wenn beide ohne ECC laufen. [1] https://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=26303271#p26303271
ntldr schrieb: > ZFS wird nicht dadurch schlechter als NTFS wenn beide > ohne ECC laufen. Das mag sein, aber siehe oben. Der Anteil des reservierten RAMs kann hier eine Rolle spielen. Ungefähr gleich verhalten sich die beiden Dateisysteme somit nur dann, wenn man sie nur die gleiche Menge RAM nutzen lässt. Ein Dateisystem, das aber von viel RAM lebt oder so eingestellt ist, dass es viel RAM reserviert wird sehr schnell auf die defekten RAM Bereiche stoßen und die über die Zeit hinweg dann auch nutzen.
Ansonsten vertraue ich bezüglich der Aussagekraft ob man für ZFS jetzt ECC RAM braucht oder nicht eher den Entwicklern von FreeNAS, denn die haben diese Systeme täglich im Einsatz und ECC RAM wird hier mehr als oft genug extra betont. Wenn mögliche Datenverluste mit Non-ECC RAM so selten wären, dann würde man in der Doku ja nicht erwähnen, dass man auf jeden Fall auf die Verwendung ECC RAM achten soll. Da schlägt also die Praxiserfahrung die theoretischen Aussagen.
Hallo, danke für die rege Diskussion. Nano schrieb: > Denn wenn FreeNAS eine Option sein soll, FreeNAS - dafür sehe ich gerade keinen Anwendungsfall. Eigentlich ist NextCloud schon so gut wie gesetzt (wegen CalDAV-Server). MiWi schrieb: > Microserver von HP, > > N54L Nano schrieb: > Schau dir mal den HP ProLiant Microserver Gen10 Die Gen10-Mikroserver scheinen ja nichts so dolle Bewertungen zu haben, wobei wohl insgesamt eher der Rückschritt zum Vorgänger bemängelt wird. Und die Lautstärke. Der Rückschritt und besonders komfortable Montage interessieren mich nicht so. Lautstärke schon. Wie sieht denn beim N54L die Lautstärke aus? ZFS, ECC usw. - so weit werde ich wohl nicht gehen müssen. Ein normales RAID 1 auf zwei Datenplatten sollte ausreichen. Momentan müssen weniger als 1 TB bereitgehalten werden. Mit 2x3TB sollte ich auf der sicheren Seite sein. Luther B. schrieb: > Da ich auch keine Anforderung an Hochverfügbarkeit habe, läuft bei mir > ein altes Thinkpad (T410) mit Ubuntu und einer zweiten Festplatte im > Serialbay. So sieht mein Testsystem, dass ich gerade aufbaue, aus. Ein altes Thinkpad X220 mit MSata-SSD und HDD. Das kann insbesondere bei der Lautstärke punkten.
Walter T. schrieb: > Wie sieht denn beim N54L die Lautstärke aus? Der N36L steht bei mir in der Küche und ist hörbar, stört aber nicht. Fürs Schlafzimmer wärs nichts.
Walter T. schrieb: > Wie sieht denn beim N54L die Lautstärke aus? ich hab einen mit 4 Platten in einem relativ ruhigen Raum stehen und da fällt der nicht weiter auf. Allerdings steht der so das Schall nach hinten und auf die Seite gut gedämmt ist, es ist also nur das, was durch die Front durchkommt hörbar.
Walter T. schrieb: > Nano schrieb: >> Denn wenn FreeNAS eine Option sein soll, > > FreeNAS - dafür sehe ich gerade keinen Anwendungsfall. Eigentlich ist > NextCloud schon so gut wie gesetzt (wegen CalDAV-Server). Nun, Nextcloud ist kein NAS, es ist ein Clouddienst. Bitte nicht Äpfel mit Birnen vergleichen. Die NAS sind erstmal Datenspeicher, aber viele NAS werden inzwischen eben um weitere Serverdienste, wie eben ein Clouddienst erweitert. Und OwnCloud ist im Prinzip NextCloud, da NextCloud ein Fork von OwnCloud ist und OwnCloud kann CalDAV und ist auch Open Source wie NextCloud. Zu sagen man möchte Nextcloud ist also so, als würden man sagen man möchte kein Debian, weil man Ubuntu haben möchte. Siehe dazu auch: https://de.wikipedia.org/wiki/OwnCloud#Funktionsumfang Aber selbst wenn du jetzt ganz spezifische Features von Nextcloud benötigst, sofern es diese gibt, dann könntest du Nextcloud trotzdem innerhalb FreeNAS laufen lassen, eben weil es dafür die Jails und die VMs gibt. Hier gibt's einen Überblick, Owncloud findest du dort unter Plugins aufgelistet: https://freenas.org/about/features/ Aber es ist natürlich deine Entscheidung. > Die Gen10-Mikroserver scheinen ja nichts so dolle Bewertungen zu haben, > wobei wohl insgesamt eher der Rückschritt zum Vorgänger bemängelt wird. > Und die Lautstärke. Der Rückschritt und besonders komfortable Montage > interessieren mich nicht so. Lautstärke schon. Die Lautstärke ist in der Regel von den verbauten Lüftern abhängig. Die kann man gegen leise Lüfter auswechseln, dann wird so ein Mikroserver auch leise.
Nano schrieb: > Die Lautstärke ist in der Regel von den verbauten Lüftern abhängig. Und von den Platten. Die sind nicht geräuschgedämmt gelagert.
So, ich habe jetzt mal etwas im FreeNAS Forum herumgestöbert. Hier hat jemand eine Anleitung geschrieben, wie du NextCloud auf einer FreeNAS installierst: https://forums.freenas.org/index.php?threads/how-to-manually-install-nextcloud-14-15-on-freenas-11-2-with-hardened-security.72016/ Anderseits stelle ich gerade fest, dass NextCloud laut Doku, anders als die FreeNAS Featuresseite, suggeriert, doch ein offiziell unterstütztes Plugin zu sein scheint: https://www.ixsystems.com/documentation/freenas/11.2/plugins.html#official-plugins Während man owncloud nicht aufgezählt findet. Du könntest also Glück haben oder es ein falscher Eintrag entweder auf der Featureseite oder in der Doku. Du kannst natürlich auch FreeNAS mal kurz in einer VM ausprobieren und selber nachsehen.
A. K. schrieb: > Und von den Platten. Die sind nicht geräuschgedämmt gelagert. Ja stimmt, die kommen natürlich auch noch dazu. Sollte er SSDs einsetzen wollen, dann wäre das hinfällig. Ansonsten macht es Sinn welche mit niedriger Umdrehungszahl zu verwenden. Bei den 3,5" Platten bspw. die WD Red Serie. Bei den 2,5" habe ich keine Empfehlung, da ich die nicht kaufe.
Nano schrieb: > Da schlägt also die Praxiserfahrung die theoretischen Aussagen. Die Praxiserfahrung ist, dass ZFS mit ECC RAM super läuft. Das bezweifle ich auch nicht, denn das hab ich hier auch seit Jahren am laufen. Und natürlich ist es sinnvoll bei kritischen Daten auf ECC zu setzen, denn ein Bitflip kann auch an anderer Stelle auftreten, z.B. beim Schreiben einer Datei. Wenn da natürlich Mist aus dem RAM kommt, der noch auf keiner HDD liegt, wird der Mist auch so auf die HDD geschrieben. Und genau dieses Szenario wird auch in der FreeNAS Doku beschrieben. Das ist aber völlig unabhängig vom Dateisystem. Mir ging es nur um die Aussage "ZFS macht ECC RAM wichtiger", welche absoluter Blödsinn ist und leider immer noch weiterverbreitet wird. Nano schrieb: > ntldr schrieb: >> ZFS wird nicht dadurch schlechter als NTFS wenn beide >> ohne ECC laufen. > > Das mag sein, aber siehe oben. > Der Anteil des reservierten RAMs kann hier eine Rolle spielen. > > Ungefähr gleich verhalten sich die beiden Dateisysteme somit nur dann, > wenn man sie nur die gleiche Menge RAM nutzen lässt. > Ein Dateisystem, das aber von viel RAM lebt oder so eingestellt ist, > dass es viel RAM reserviert wird sehr schnell auf die defekten RAM > Bereiche stoßen und die über die Zeit hinweg dann auch nutzen. Das ist eher wenig relevant. Den Scrub of Death gibt es auch dann nur wenn du es schaffst sowohl die Daten falsch zu lesen und gleichzeitig einen passenden Hashwert mit einem zufällig Bitflip zu bilden. Da ZFS sha256 verwendet, muss dein RAM also genau den richtigen Hash aus 2^256 treffen und das ohne dass dein System abstürzt. Da empfehle ich eher Lotto zu spielen, der Hauptgewinn ist da nämlich deutlich wahrscheinlicher :). Der Normalfall ist einfach, dass ZFS bei einem falschen read sieht, dass die Checksum nicht passt und einfach nochmal liest und einen Logeintrag erstellt.
Nano schrieb: > A. K. schrieb: >> Und von den Platten. Die sind nicht geräuschgedämmt gelagert. > > Ja stimmt, die kommen natürlich auch noch dazu. > Sollte er SSDs einsetzen wollen, dann wäre das hinfällig. > Ansonsten macht es Sinn welche mit niedriger Umdrehungszahl zu > verwenden. > > Bei den 3,5" Platten bspw. die WD Red Serie. Ack. PS: auch wenn ich nicht bei allem Deiner Meinung bin - sehr nett und erfreulich das Du diesen Thread mit brauchbaren Infos würzt... ich hab - was NAS betrifft - schon ganz andere Grabenkriege erlebt.
Ich habe auch einen Proliant Gen10 Microserver in Betrieb. Das Betriebssystem ist ein Debian, worauf ich mir Proxmox eingerichtet habe. Das System läuft auf einer alten Samsung 840 SSD. Die Disks sind bei mir WD Red 3 TB, 3 Stück davon als raidz1. Die Performance ist sehr gut, und der Lärm absolut erträglich. Die WD Red hört man kaum. Zur Verringerung von Stress für die Disks lasse ich sie ständig drehen. Zuerst hatte ich Bedenken wegen des Stromverbrauchs, aber ich habe mit einem Wattmeter nachgemessen: der Microserver verbraucht im Idle (drehende Disks, aber keine VM läuft und kein Diskzugriff erfolgt) 22 Watt. Das sind weniger als 50 Franken pro Jahr. Wenn man auf die Disks zugreift, kann die Leistungsaufnahme bis 30 Watt steigen, beim Transcodieren eines h.265 Films mit PLEX Multimediaserver können es kurz auch mal 40 Watt sein. Der Stromverbrauch für Heimapplikationen hält sich also noch in akzeptablen Grenzen. Wenn man die Disks übrigens ausschaltet, kann man den Stromverbrauch auf ca. 5 Watt senken (ohne das Betriebssystem in den Standby zu fahren). Der Nachteil ist halt der grössere Stress für die Disks und die erhöhte Zugriffszeit, andererseits bekommt man den Server so nahezu lautlos hin. Vielleicht können also diese Stromverbrauchsangaben dem Entscheidungsprozess behilflich sein :-) Grüsse Tobias
Walter T. schrieb: > Welchen Vorteil bietet ZFS bei einem RAID 1 aus lediglich zwei > Platten? Vorteil gegenüber einem klassischen RAID? So aus dem Stegreif grob gesagt: Ein klassisches RAID 1 kann deine Daten gegen einen Ausfall der Hardware einer Platte absichern, aber nicht gegen einen Bit Rot, also fehlerhafte Daten. Also einen Fehler der im Laufe der Zeit auftreten kann und die Integrität der Daten gefährdet. Wenn das passiert, dann weiß ein klassisches RAID 1 nämlich nicht, welches die richtigen fehlerfreien Daten sind, es hat keine Möglichkeit zu erkennen ob der Datenträger 1 oder der Datenträger 2 nun die richtigen Daten liefert. Insofern ist nicht klar, von welcher Festplatte die richtigen Daten kommen und somit ist eine selbstständige Reparatur der Daten nicht möglich. Bei ZFS und auch Btrfs ist das anders. Das sichert sich mit Prüfsummen ab und kann anhand dieser Prüfsummen erkennen, welche Festplatte bei einem Mirror nun die richtigen Daten hat und welche die falschen. Da es das weiß, kann es die falschen Daten somit auch selbstständig reparieren, in dem es die richtigen Daten von der Festplatte mit den fehlerfreien Daten liest und sie auf die Festplatte, die die falschen Daten lieferte, zurückschreibt, danach stimmen die Daten wieder auf beiden Platten. Die Datenintegrität ist mit ZFS und Btrfs daher immer sichergestellt. Im Detail wird das ganze in folgendem Video recht genau und gut erklärt https://www.youtube.com/watch?v=yAuEgepZG_8
Nano schrieb: > Im Detail wird das ganze in folgendem Video recht genau und gut erklärt > Youtube-Video "RAID: Obsolete? New Tech BTRFS/ZFS and "traditional" > RAID" Hier ist übrigens der 2. Teil des Videos: https://www.youtube.com/watch?v=pv9smNQ5fG0
Tobias P. schrieb: > der Microserver verbraucht im Idle (drehende Disks, aber keine VM läuft > und kein Diskzugriff erfolgt) 22 Watt. .. > Wenn man die Disks übrigens ausschaltet, kann man den Stromverbrauch auf > ca. 5 Watt senken (ohne das Betriebssystem in den Standby zu fahren). 17 Watt Ersparnis passt irgendwie nicht zu 3x WD30EFRX idle=>sleep. Wie hast du gemessen?
Hi, anbei mein Setup: Intel J4105 auf ASROCK J4105-ITX 2*4GB RAM DDR4 2400 Toshiba SSD512GB für OS und Backups + Seagate Archive HDD 8 TB für Medien PicoPSU90 + Tischnetzteil 12V/5A USB 3.0 Hub Gehäuse: Ja gute Frage...steht nix drauf ;( hat 2 Schächte 3 1/2 Zoll und einen 5 1/4 Zoll System ist passiv gekühlt. OS: OpenSuse TumbleWeed mit Samba, Clamd, Apache, CUPS, SANE usw... (komplette Installation ist ca 2.5 GB groß) FS: Ext4 fuer System, Rest ReiserFS Heute würde ich eher btrfs verwenden, aber das ist "historisch gewachsen". Nutzung: Primär FileServer, Print&Scan-Server, Webserver für kleinere Tests. Wichtig war mir hauptsächlich die Geschwindigkeit bei Transfer großer Files und ein geringer Verbrauch sowie ein geringes Geräuschniveau. Max. Geschwindigkeit Filetransfers: ca 100 MB/s bei großen Files Verbrauch gemessen an der Steckdose: 5W idle HDD spindown, 13W idle HDD aktiv, 22W bei hoher Last und HDD aktiv Und falls einer fragt warum da kein RAID drinnen ist: Ich kopiere die Daten regelmässig auf eine externe zweite HDD. gruß tobi
ServerHeizung schrieb: > 17 Watt Ersparnis passt irgendwie nicht zu 3x WD30EFRX idle=>sleep. > > Wie hast du gemessen? ja, die 17W sind ein bisschen viel. Für so kleine Leistungen ist das Wattmeter ein ziemliches Schätzeisen :-(
Jan L. schrieb: > Kürzlich ist mir ein >8 Jahre altes Synology-NAS in die Hände gefallen - > liess sich problemlos auf die neueste DSM-Version upgraden (wenn auch in > bestimmt 4 Schritten). Das stimmt, aber viel Spaß macht das dann nicht mehr. Meine 6-7 Jahre alte DS212+ lässt sich zwar noch auf die aktuelle DSM-Version updaten, aber das ganze Frontend ist dann träge und zäh wie Kaugummi. Und dabei ist die DS212+ noch die potenteste aus dieser Reihe... Walter T. schrieb: > FreeNAS - dafür sehe ich gerade keinen Anwendungsfall. Eigentlich ist > NextCloud schon so gut wie gesetzt (wegen CalDAV-Server). Wenn es dir nur um CardDav/CalDav geht solltest du vielleicht Baikal nutzen. Rein dafür ist Owncloud IMO zu aufgeblasen und zu träge. Nextcloud ist da bestimmt nicht viel anders. Außer du brauchst noch was von den anderen Features. Mein System: ASRock J4205 2* 8GB RAM 64GB Samsung SSD für System, Einstellungen und Datenbank 2* WD Red (2TB & 3TB) für Daten Chenbro ES34069 mit zugehörigem Netzteil OMV auf Debian Das Ganze benötigt idle 20W wenn sich beide Disks drehen, unter Last etwas mehr. Mit einer PicoPSU ließe sich wahrscheinlich noch ein bisschen was holen. Die o.g. genannten 40W idle wäre mir persönlich zu viel, bei 24/7 sind das schon mehr als 90€ Stromkosten pro Jahr.
Walter T. schrieb: > "Klassisch" schreit das nach einem NAS. Was mir an diesen Geräten > allerdings nicht gefällt, ist die Langzeitverfügbarkeit von Updates Naja - definiere "Langzeitverfügbarkeit". Das Linux Mint 17 auf meinem Thinkpad kam 2014 und bekommt ab April 2019 keinen Support mehr. Eine debian LTS läuft normal nur 5 Jahre. Extended LTS dann noch mal ein Jahr mehr. So much about "Long Term Support" in der Szene. Nach 6 Jahren bist du alleine. Meine bisherigen NAS (von den beiden grossen Consumer NAS Anbietern) gingen alle in Pension lange bevor die updates abgekündigt wurden. Natürlich wird das Frontend langsam, aber das nutzt man ja nicht täglich. Wenn ich mir aber ansehe was ich alles an Diensten laufen habe und sogar nutze wird die Liste lang. Mit daap, fileserver & print fing es an. CalDAV, CardDAV, mail, A/V-Medienverwaltung mit live kodierung und on-board KI, vollindex, ebook Regal, Messdatenlogging, web... Synology & QNAP Consumergeräte sind manchmal wenig potent und strombesparend. Support gibt es aber sehr lange. Selberbauen kann man so wie man es will. Wenn man open source software nimmt, kann man auch selber dessen Fehler ausbessern und auf Lift-Time-Support erweitern.
10 Jahre Security Fixes gibts faktisch bei CentOS, weil das parasitär am Redhat Enterprise Linux dranhängt. Hat aber Nebeneffekte, denn ein Versionsupgrade von Teilprodukten wie PHP findet bisher innerhalb dieser 10 Jahre nicht statt. Weshalb da beispielsweise heute noch PHP 5.4 aktuell ist.
:
Bearbeitet durch User
Sebastian L. schrieb: > Das Linux Mint 17 auf meinem Thinkpad kam 2014 und bekommt ab April 2019 > keinen Support mehr. Eine debian LTS läuft normal nur 5 Jahre. Extended > LTS dann noch mal ein Jahr mehr. > So much about "Long Term Support" in der Szene. Nach 6 Jahren bist du > alleine. Bei einem NAS mit Open Source Lösung ist es nicht die Frage, wie lange eine bestimmte Distributionsversion unterstützt wird, sondern wie lange man die Hardware mit einer mit Sicherheitspatches versorgen Distribution am Laufen halten kann. Beispiel, mein altes NB aus dem Jahr 2006 mit 32 Bit Pentium M CPU bietet PAE Support und das NX Bit, darauf konnte ich noch ein aktuelle Ubuntu Version bis Ubuntu 17.10 installieren und eine aktuelle Debian Stable würde darauf noch heute laufen. Bei einer proprietären Hardware ist das nicht so, da kommt es wirklich darauf an, wie lange der Hersteller Softwaresupport gewährt. Ein Debian 9 (Stretch) hebt man daher einfach auf ein Debian 10 (buster) sobald das stable ist und dieses dann auf ein Debian 11 und von dort auf ein Debian 12, das kann man so lange machen, solange die Hardware unterstützt wird. Grenzen die sich durch die Hardware ergeben könnten, sind in der Regel die CPU Features und somit ihre Erweiterungen und das verfügbare RAM. Wer bspw. einen > 20 Jahre alten Pentium 60 hat, der wird auf dem zwar rein vom Prozessor her noch ein Linux Betriebssystem laufen lassen können, wenn der Rechner aber nur 4 MB RAM hat, dann geht das schon nicht mehr.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.