© Andrew Poplavsky / 123RF.com

NAS-Geräte von Synology oder Qnap erfreuen sich großer Beliebtheit, nerven passionierte Admins aber mit ihren GUIs und ihrem überbordenden Funktionsumfang. Wer sich das nicht antun will, baut mit Hardware von der Stange und passender Software einen maßgeschneiderten, per Ansible automatisierbaren Ersatz.

Aus dem heutigen IT-Alltag sind NAS-Systeme längst nicht mehr wegzudenken. Network Attached Storage, so die ausgeschriebene Form der Abkürzung, bestechen durch mehrere Vorteile. Zunächst bekommt der Administrator hier seitens des Anbieters ein für den vorgesehenen Einsatz weitgehend perfektioniertes Stück Hardware an die Hand. Mainboard, RAM und CPU brauchen nicht sonderlich viel Leistung und Platz. Entsprechend kompakt fallen die Geräte aus: Selbst ein ausgewachsenes NAS von Qnap oder eine Diskstation von Synology finden problemlos im Büro Platz. Wer lieber ins Rechenzentrum ausweicht, bekommt dafür sogar 19-Zoll-Geräte.

Etwas anders liegen die Dinge, wenn der vorgesehene Einsatzzweck nicht dem ursprünglich vom Anbieter skizzierten Szenario entspricht. Ein paar Beispiele verdeutlichen das schnell: Möchte man auf einem Gerät zum Beispiel einen Streaming-Server wie jenen von Plex laufen lassen, stellt das an die Hardware sowie das genutzte Betriebssystem bereits einige Anforderungen. Den Plex-Server gibt es nämlich nicht für jede CPU-Architektur. Das liegt unter anderem daran, dass ARM-Prozessoren kaum die nötige Leistung aufbringen, um 4K-Videos zu streamen.

Ein weiterer Faktor ist die Hochverfügbarkeit: Gerade im professionellen Einsatz bilden NAS heute oft das Rückgrat ganzer Büros, etwa als Kernkomponente des Backup-Konzepts oder einfach als zentraler Speicher für benötigte Daten. Ist das NAS nicht verfügbar, steht vielerorts die Arbeit schlicht still. Interesse an umfassenden Konzepten für Hochverfügbarkeit bei NAS-Appliances ist also vorhanden. Sie liefert von den Herstellern jedoch nur Synology. Qnap bietet dagegen keine richtigen HA-Features (high availability), und bei Synology liegt diese Funktionalität nur eingeschränkt vor.

Vielen Administratoren missfällt zudem die Art und Weise, wie man NAS-Geräte der großen Anbieter betreiben und warten muss. Bei den beiden Platzhirschen nimmt die grafische Bedienoberfläche der Lösung eine zentrale Rolle ein. Ein Kommandozeilenzugang steht zwar zur Verfügung, ist aber nicht nahtlos mit der GUI integriert. Manche GUI-Funktion steht auf der Kommandozeile nicht zur Verfügung. Obendrein läuft auf den Geräten zwar Linux, doch mit einer klassischen Distribution haben die Betriebssysteme von Qnap und Synology nur kleine Schnittmengen. Wer beispielsweise auf dem NAS ein vom Anbieter in dessen Store nicht vorgesehenes Programm installieren möchte, hat ein großes Problem, wenn er im Netz kein passendes Paket aus der Community findet.

Was tun?

Die Situation ist pikant: Einerseits kaufen Administratoren die Geräte ja gerade, weil sie vorkonfiguriert viele Funktionen mitbringen und nicht schwer zu administrieren sind. Reduzierte Komplexität impliziert aber fast immer auch reduzierte Funktionalität. Es schaudert aber manchen Admin, wenn er darüber nachdenkt, statt eines fertigen Systems ein NAS selbst zu bauen. Immerhin gibt es für das Vorhaben in der FOSS-Community genügend Software.

FreeNAS, OpenNAS und XigmaNAS haben zwar alle denselben technischen Kern, kommen aber mit eigenen Feature-Sets daher. Der technische Kern allerdings ist BSD, genauer gesagt FreeBSD, das längst nicht jeder Linux-Admin einfach so administrieren kann. Konzepte und Ideen unterscheiden sich bei FreeBSD und den gängigen Linux-Distributionen zum Teil erheblich. Zudem gilt: Auch die Betriebssysteme für NAS im Eigenbau gehen Kompromisse zugunsten der Administrierbarkeit und zulasten der Funktionalität ein.

Viele Administratoren wären jedoch erstaunt, wie gut sich ein NAS mit einer gängigen Linux-Distribution selbst bauen lässt, ohne große Abstriche in Sachen Komfort in Kauf nehmen zu müssen. Ein NAS ist im Grunde nichts anderes als ein kleiner Computer mit einer spezifischen Konfiguration. Dafür bietet sich Linux als Basis an. Wer Systemadministration unter Linux beherrscht, kommt bei einem solchen NAS nicht selten zu besseren und weniger komplexen Ergebnissen als die großen Hersteller.

Im Gegenzug ermöglicht der Eigenbau mit Werkzeugen von der Stange wie Ansible viele Automatisierungsfunktionen. Gleichzeitig reduziert er die Angriffsfläche für Hacker deutlich: Schließlich läuft auf einem Eigenbau-NAS in der Regel nur die tatsächlich benötigte Software statt eines ganzen Fundus an Programmen, die vielleicht irgendwann einmal für irgendetwas nützlich sein könnten. Auch das Thema Hardware ist weniger schwierig als mancher Administrator vielleicht glaubt.

Wir zeigen im Folgenden, welche Optionen es in Sachen Hard- und Software gibt und wie sich ein NAS im Eigenbau auf Basis von Debian GNU/Linux 12 “Bookworm” sinnvoll umsetzen lässt.

Zur Hardware

Damit es überhaupt etwas zu installieren gibt, steht zunächst die Anschaffung passender Hardware auf dem Programm. Mancher Administrator mag an dieser Stelle intuitiv an 19-Zoll-Geräte denken, doch ist das heute gar keine Notwendigkeit mehr. Selbst Rechner im Format eines Mac Mini oder noch kleinere Computer liefern heute genug Performance, um ein NAS komfortabel zu betreiben. Tatsächlich dürften die meisten der im Netz feilgebotenen Mini-PCs sogar deutlich mehr Leistung an Bord haben als gängige NAS-Geräte von Qnap oder Synology. Ein Blick in die Quellen im Netz, etwa beim lokalen Elektrofachmarkt oder bei Amazon, bestätigt das schnell.

Die naheliegendste Option sind die NUCs von Intel (Abbildung 1), die in der Barebone-Konfiguration mit Core-i5-CPUs einer aktuellen Generation ab 480 Euro zu bekommen sind. Eine moderat große M2-SSD sowie 16 oder 32 Gigabyte RAM schlagen mit weiteren 100 bis 150 Euro zu Buche, sodass das gesamte Gerät maximal 650 Euro kosten sollte. Zwar fehlt noch die Möglichkeit, Festplatten sinnvoll anzuschließen, dafür liefert ein solches System aber eben auch deutlich mehr Leistung. Zudem lässt es sich mit Standardsoftware gut nutzen, weil es die x86_64-Architektur nutzt.

Abbildung 1: Intels NUCs – hier ein Exemplar mit Core-i5-CPU – sind eine hervorragende Wahl für kleine Systeme, die als Eigenbau-NAS funktionieren sollen. Quelle: Intel

Mögliche Alternativen zu Intel-NUCs bieten Geräte von Lenovo, Fujitsu oder Beelink (Abbildung 2), die in ähnlichen Preisregionen liegen und als Barebones sowie als fertige Systeme mit 32 Gigabyte RAM und 500 Gigabyte SSD zu haben sind. Der Nachteil dieser Komplettsysteme: Meist umfassen sie auch eine Lizenz für Windows 11 Pro, mit der sich im NAS-Szenario eher wenig anfangen lässt.

Abbildung 2: Wer nicht auf Intel oder Fujitsu setzen möchte, bekommt bei Beelink passende Hardware, oft mit AMD-CPU. Bei Thunderbolt-Geräten sollte man aber vorab die Kompatibilität prüfen. Quelle: Beelink

Bei manchen aktuellen Systemen ist Vorsicht geboten, weil sie auf AMD-CPUs basieren und mit USB 4 statt mit dem Intel-spezifischen Thunderbolt 4 kommen. USB 4 ist zwar in der Theorie zu Thunderbolt 3 kompatibel, aber nicht jedes am Markt verfügbare externe Gehäuse für den Betrieb von HDDs harmoniert mit dem USB-C-Chip. Hier kommt es auf einen Versuch an. Möchten Sie auf Nummer sicher gehen, greifen Sie zu einer Intel-CPU mit Thunderbolt und setzen auf ein externes Thunderbolt-Gehäuse oder eines mit USB-C 3 oder höher.

Apropos externes Gehäuse: Die gibt es in verschiedenen Arten und Formen, meist mit USB-C-3-Anschluss oder Thunderbolt. Geräte von Digitus oder Icybox haben sich bewährt, auch OWC spielt in der ersten Liga. Das OWC Thunderbay 3 beispielsweise bietet vier Einschübe für 3,5-Zoll-Festplatten und zwei Thunderbolt-3-Anschlüsse. Es ist mit rund 600 Euro Straßenpreis aber auch ziemlich teuer. Können Sie mit USB-C leben, findet Sie in der Icybox IB-3804-C31 von Raidsonic eine Alternative für 239 Euro. Das OWC-Gerät bietet zwar 40 Gbit/s, während der Konkurrent von Raidsonic nur mit 10 Gbit/s an den Host angebunden ist. Ein Durchsatz von 40 Gbit/s erscheint aber ohnehin illusorisch: NAS-Festplatten wie die Red Pro mit 12 TByte Kapazität erreichen im Test selbst unter idealen Voraussetzungen keine 250 MByte/s. Verbauen Sie vier davon in Ihrem NAS, lasten Sie den Thunderbolt-Uplink in der Theorie also gerade eben so aus.

Allerdings gibt es einige Faktoren, die Sie beim Kauf eines externen Gehäuses auf jeden Fall im Kopf haben sollten. Viele Geräte haben einen eigene RAID-Controller. Hier handelt es sich aber nicht um klassische Controller, wie man sie aus dem Rechenzentrum kennt, sondern um spezielle Chips, die auf der Systemseite einen eigenen Treiber brauchen (“Sw-RAID”). Unter Linux sind diese Bauteile nicht beliebt, weil es die benötigten Treiber zum Teil für das freie Betriebssystem gar nicht gibt und die genannten Chips keinen Mehrwert gegenüber einer MD-RAID-Konfiguration unter Linux bieten.

Beim Kauf eines externen Gehäuses für Festplatten sollte der Administrator also darauf achten, dass das Gerät einen JBOD- oder Passthrough-Modus unterstützt. Dann schleift es die vorhandenen Festplatten einfach an das angeschlossene Linux-System durch, wo Möglichkeiten für RAID über den Kernel selbst zur Verfügung stehen. Eigentlich sollte das selbstverständlich sein, doch gibt es Geräte, die sogar in einer JBOD-Konfiguration noch eine Signatur auf die Festplatten malen, die nur sie selbst verstehen. Diese Platten lassen sich dann nicht einfach aus dem NAS-Gehäuse ziehen und beispielsweise zur Datenrettung an einen normalen Computer anstecken, weil der die Signaturen nicht lesen kann. JBOD oder Passthrough ohne Schnickschnack auf der Geräteseite sind der Königsweg, um das Problem zu lösen.

Abschließend stellt sich beim Thema Hardware noch die Frage nach der Anbindung ans Netzwerk. Planen Sie ohnehin ein NAS im Eigenbau, bietet es sich theoretisch an, hier gleich eine dickere Anbindung als die ab Werk meist verfügbaren 1 Gbit/s zu verwenden. Das ist im Büro gar nicht so aufwendig als man im ersten Augenblick vermuten würde. Neuere CAT-5e-Kabel ermöglichen eine Verbindung mit bis zu 5 Gbit/s. Gerade bei einem zentralen Speichergerät wie einem NAS zahlt sich das aus. Das gilt aber freilich nur, wenn der Switch, an dem das NAS hängt, selbst 5 Gbit/s unterstützt. Stehen das Eigenbau-NAS und der Switch im selben Raum, sind mit einem lokalen Cat-6-Kabel sogar 10 Gbit/s möglich.

Ein passender Switch wäre der Qnap QSW-M408-4C, der mit ungefähr 400 Euro zu Buche schlägt. Sie benötigen dann aber auch das passende Gegenstück. Hier zahlt es sich aus, auf Thunderbolt zu setzen: Steht ein Thunderbolt-3-Anschluss zur Verfügung, kommt nämlich der Sonnet Solo 10G (Abbildung 3) als NIC in Betracht. Das bedeutet zwar ein erhebliches Hardware-Investment, das jedoch nichts mit dem Eigenbau zu tun hat. Die nötige Switch-Infrastruktur braucht man so oder so. Selbst Fertigsysteme von Qnap oder Synology kommen ab Werk nicht mit 10-Gbit/s-Anschluss und müssten über eine entsprechende Karte erweitert werden. Sie kostet auch rund 250 Euro.

Abbildung 3: Mit dem Solo 10G von Sonnet lassen sich Geräte mit Thunderbolt-Schnittstelle leicht auf 10-Gigabit-Ethernet aufrüsten – bei einem NAS ist das oft sehr praktisch. Quelle: Sonnet

Übrigens: Wollen Sie auch gleich Ihre Probleme in Sachen Hochverfügbarkeit lösen, benötigen Sie das gesamte Setup zwei Mal. Auf die Softwareaspekte des Themas HA gehen wir später noch im Detail ein.

Softwaregrundlagen

Zunächst stellt sich allerdings die Frage, welche grundlegenden Themen in Sachen Software es beim Setup des Systems zu beachten gilt und welche Standardeinstellungen Sie wählen sollten. Hier hängt viel davon ab, wie viel Automation und Lifecycle-Management vor Ort bereits gegeben ist.

Steht etwa ein Deployment-Mechanismus für blankes Blech zur Verfügung, spricht nichts dagegen, ihn für das Eigenbau-NAS zu nutzen. Falls bis dato von Automation noch nicht die Rede gewesen ist – wie bei den meisten KMUs üblich –, stellt das keinen Beinbruch dar. Dann passen Sie schlicht die Strategie an: Die Erstinstallation des Betriebssystems erfolgt dann zwangsläufig händisch, den Rest der benötigten Dienste setzen Sie idealerweise aber mit einem lokalen Ansible auf. Das gilt ganz besonders, wenn zwei NAS-Systeme als HA-Verbund zu konfigurieren sind.

Aufzusetzen gibt es bei einem Eigenbau-NAS eine ganze Menge. Die folgende Liste ist als nicht vollständige Zusammenfassung zu verstehen: Je nach Art und Beschaffenheit des lokalen Setups können durchaus noch Faktoren hinzukommen oder wegfallen. Obendrein besteht an verschiedenen Stellen die Gefahr, das Setup gleich von Anfang an nicht optimal zu verbauen, was man später bereuen wird. Das beginnt schon bei der Installation des Betriebssystems: Sie tun gut daran, es auf das eingebaute Speichermedium zu packen und die eventuell bereits angeschlossenen externen Laufwerke vorerst unangetastet zu lassen. Die lassen sich später aus dem laufenden System heraus viel besser per MD-RAID und LVM einrichten als während der Betriebssysteminstallation.

Ein besonderes Augenmerk sollten Sie während der Installation auf den Aspekt Netzwerk legen. Wollen Sie die Maschine beispielsweise in Form einer externen Netzwerkkarte redundant mit zwei Switches verbinden, konfigurieren Sie das dafür benötigte Bonding-Gerät idealerweise schon während der Grundinstallation des Systems.

Authentifizierung

Nach dem grundlegenden Setup geht es an die Einstellungen des Systems selbst. Hier spielen die Dienste, die das Eigenbau-NAS später Clients zur Verfügung stellt, noch keine große Rolle. Vielmehr geht es um Einstellungen, die Ihnen später das Leben erleichtern – und die finden sich insbesondere im Bereich der Authentifizierung und Autorisierung.

Gibt es irgendwo im Unternehmen ein zentrales Benutzerverzeichnis in Form von LDAP oder Active Directory, möchten Sie das NAS oder Ihre beiden NAS-Instanzen selbstredend daran anschließen: Das garantiert konsistente Benutzernamen und Benutzer-IDs über alle Systeme und Dienste hinweg. Auf diese Weise verhindern Sie, sich später beim Betrieb von Diensten wie Samba, Netatalk, NFS und iSCSI in der Berechtigungshölle wiederzufinden. Die entsteht in der Regel, wenn auf einem System verschiedene Ordner unterschiedlichen Benutzer- oder Gruppen-IDs gehören, auf die aber mehrere Leute zugreifen sollen. Kommen alle Benutzer und Gruppen einheitlich aus einem zentralen Verzeichnis, ist diese Gefahr gebannt. Besonders bei hochverfügbaren Setups spielt dieser Aspekt eine wichtige Rolle. Zudem ersparen Sie sich auf diese Weise die Pflege einer (oder im HA-Cluster zweier) lokalen Benutzerdatenbank(en).

Dienste einrichten

Nach dem Abschluss der Basiseinrichtung steht die Konfiguration der eigentlichen NAS-Dienste auf dem Programm. Hier kommt der eingangs erwähnte Ansatz zum Tragen, wonach sich ein lokales Setup mit Ansible auch dann lohnt, wenn der Automatisierer bislang im Unternehmen noch nicht zum Einsatz kommt (Abbildung 4). Zu den typischen NAS-Diensten zählen Samba für CIFS (also Windows-Shares), Netatalk für Backups von Apple Time Machine, NFS für das Teilen von Daten unter Unix-Systemen und iSCSI, um virtuelle Instanzen auf anderen Systemen mit persistentem Speicher auszustatten. Das eigentliche Setup der Dienste lässt sich dabei für alle genannten Beispiele bequem per Ansible abwickeln. Vorher steht jedoch die Konfiguration des Speichers im Fokus.

Abbildung 4: Ansible ermöglicht das schnelle Aufsetzen von Diensten, selbst wenn es bisher noch keine lokale Ansible-Infrastruktur gab.

Gegeben sei für dieses Beispiel ein Setup aus vier 3,5-Zoll-Festplatten mit jeweils 14 TByte Kapazität. Es bietet sich an, daraus einen RAID-5-Verbund zu machen, der den Ausfall mindestens einer Platte überlebt. Das lässt sich mit dem MD-RAID-Treiber des Linux-Kernels unter Debian GNU/Linux 12 gut und schnell einrichten. Ein großes Volume ist für die diversen beschriebenen Aufgaben allerdings äußerst unpraktisch. Sinnvoller wäre es, separate Volumes für CIFS, Netatalk und so weiter zu verwenden. Dafür kommt unter Linux LVM zum Einsatz. Aus administrativer Sicht ergibt es durchaus Sinn, das gerade angelegte MD-RAID 5 zu einem großen Physical Volume zu machen und darin eine Volume Group namens data anzulegen. Innerhalb derer kann es dann einzelne Volumes geben, etwa samba, netatalk und nfs. iSCSI setzt ein gesamtes Block-Device voraus, was sich mit LVM aber ebenfalls leicht einrichten lässt.

Aus Sicht des Administrators lohnt es sich, sich vor dem Anlegen der Volumes ein paar Gedanken über deren Layout und Größe zu machen. Klein anfangen ist dabei ein sinnvoller Ansatz, denn alle gängigen Dateisysteme unter Linux lassen sich vergrößern. Und auch LVM selbst beherrscht eine Online-Resize-Funktion. Nach dem Einrichten der Logical Volumes (LVs) benötigen sie bloß noch ein Dateisystem (etwa XFS) und einen Einhängepunkt im System, schon ist auch dieser Drops gelutscht. Bauen Sie ein hochverfügbares Setup, sollten Sie damit allerdings noch warten: Hier gehört zwischen Logical Volume und Dateisystem noch der Replizierer DRBD, um die Daten zwischen den Knoten synchron zu halten.

Nun folgt das Setup der eigentlichen Dienste. Im Netz finden sich zahlreiche entsprechende Anleitungen für das Einrichten von Samba, NFS, Netatalk und iSCSI unter Debian “Bookworm” oder Ubuntu 22.04 – Letztere lassen sich in weiten Teilen auf Debian übertragen. Zusätzlich sollten Sie übrigens Avahi und seine korrekte Konfiguration im Hinterkopf haben: Anderenfalls funktioniert UPnP und damit Protokolle wie Apples Bonjour nicht, sodass vorhandene Volumes auf MacOS-Geräten nicht erscheinen.

Bei diesem Teil des Setups spielt Ansible seine Kunst grandios aus: Für Samba, Netatalk sowie NFS finden sich im Netz vorgefertigte Playbooks, die die jeweiligen Dienste aus Debian GNU/Linux 12 schnell und reproduzierbar aufsetzen. Die Community hat hier gut geliefert und nimmt Ihnen als Admin eines Eigenbau-NAS einen großen Teil der Last von den Schultern. Sie müssen im Normalfall nur noch die passenden Variablen für die Konfiguration des Playbooks (und der Rollen) setzen und es danach einmal gegen Ihr Eigenbau-NAS laufen lassen.

Hochverfügbarkeit

Sind Sie unseren Ratschlägen bis hierhin gefolgt, haben Sie nun ein NAS-System oder ein identisch konfiguriertes Pärchen, für das Ansible verantwortlich zeichnet. Ein richtiges HA-Setup ist das Konstrukt aber noch nicht: Es fehlt sowohl die Replikation der Daten als auch ein Cluster-Manager, der gegebenenfalls einen Failover initiiert. Mit den Bordwerkzeugen von Debian “Bookworm” lässt sich ein HA-Setup jedoch recht einfach einrichten.

Dazu widmen Sie sich zunächst der Datenreplikation. Damit beim Ausfall des jeweils aktiven Cluster-Knotens dessen Partner nahtlos übernehmen kann, benötigen beide Systeme dieselben Daten. Der Linux-Kernel bringt dafür das Distributed Replicated Block Device DRBD mit. Zwar ist die im Kernel integrierte Version nicht mehr ganz taufrisch, genügt für den gewünschten Einsatzzweck aber völlig. Sie brauchen lediglich das Paket drbd-utils auf den Systemen zu installieren und können anschließend DRBD-Ressourcen für die angelegten Volumes konfigurieren [1]. Sobald für alle benötigten Volumes DRBD-Ressourcen vorliegen, lassen sich die übrigen Dienste grundsätzlich so einrichten wie für das schon beschriebene Setup ohne Hochverfügbarkeit.

Fehlt noch ein Cluster-Manager, der sowohl die DRBD-Ressourcen als auch die Dienste verwaltet, die einen Ausfall überleben sollen. Wie Sie Pacemaker dazu einsetzen, haben wir bereits einige Male detailliert erläutert, zuletzt am Beispiel von MariaDB [1]. Möglicherweise gibt es zwischen dem für MariaDB beschriebenen Setup auf RHEL und der hier angestrebten Einrichtung unter Debian kleinere Unterschiede. Im Großen und Ganzen sollte aber alles wie beschrieben funktionieren.

Stattdessen können Sie auch Ansible für das Setup von Pacemaker verwenden. Die im Netz verfügbaren Rollen und Playbooks für Pacemaker variieren in ihrer Qualität jedoch stark. Weil das einmal in Pacemaker eingebrachte Setup grundsätzlich persistiert, erscheint die Lösung zu Fuß an dieser Stelle ausnahmsweise legitim. Ein echter zeitlicher Gewinn ergibt sich bei der automatisierten Lösung im direkten Vergleich zum manuellen Weg jedenfalls nicht.

Ist Pacemaker eingerichtet, fehlt noch die Steuerung der Cluster-Anwendungen. Alle im Artikel bisher beschriebenen Dienste lassen sich auf der Systemebene via Systemd steuern. Pacemaker hat zudem eine Systemd-Schnittstelle, über die sich Dienste steuern lassen. Insofern genügt es, die Dienste als Ressource des Typs Systemd in Pacemaker aufzunehmen und per Constraint mit einer eventuell dazugehörenden DRBD-Ressource zu verbinden. Das stellt sicher, dass die DRBD-Ressourcen im Falle eines Failovers mit dem Dienst auf den verbliebenen Cluster-Partner schwenken (Abbildung 5).

Abbildung 5: Sind alle Dienste auf dem Eigenbau-NAS eingerichtet, kann es via Samba oder Netatalk beispielsweise als Ziel für Time-Machine-Backups von MacOS dienen.

Fazit

Zugegeben: Der Eigenbau eines NAS macht erheblich mehr Arbeit als das Auspacken eines Qnap-Geräts und seine Inbetriebnahme. Investieren Sie diesen Aufwand, wartet als Belohnung jedoch ein ganzes Füllhorn an Vorteilen auf Sie.

Hardware von der Stange ist leistungsfähiger und oft günstiger als das, was Qnap und Synology in ihre Bundles einschließen. Weil auf dem System oder den HA-Systemen eine echte Linux-Distribution die Grundlage bildet, arbeiten Sie in einer gewohnten Umgebung und haben viel mehr Möglichkeiten als auf den reduzierten Betriebssystemen der Appliance-Anbieter. Setzen Sie konsequent auf Automation, ersparen Sie sich zudem einen großen Teil der ansonsten anfallenden Mühe.

Zudem fällt der berüchtigte Vendor-Lock-in weg: Ein defektes Gerät lässt sich ohne großen Aufwand durch Hardware von der Stange ersetzen und dank der vorhandenen Automation schnell wieder in Betrieb nehmen. Nach einer dank DRBD problemlosen Replikation der Daten ist der Zwei-Knoten-Cluster wieder voll funktionstüchtig.

So mühsam es im ersten Augenblick also auch erscheinen mag: Ein NAS der Marke Eigenbau auf Basis von Debian GNU/Linux hat viele Reize. (jcb/jlu)