Speicherlayout zuerst oder NAS-Betriebssystem zuerst: Welche Entscheidung sollte beim Bau eines neuen NAS den Anfang machen?

Definieren Sie die Speicheranforderungen, bevor Sie das NAS-Betriebssystem auswählen. Legen Sie jedoch kein irreversibles Pool-Layout fest, bevor Sie geprüft haben, ob das in Betracht gezogene Betriebssystem diese Anforderungen erfüllt. Beginnen Sie mit Datenwert, nutzbarer Kapazität, Laufwerksgrößen, Redundanz, Erweiterbarkeit, Workload und Wiederherstellung. Erstellen Sie anschließend eine Vorauswahl der Betriebssysteme, die dieses Modell unterstützen, und legen Sie die genaue Array-, Pool- oder vDev-Struktur innerhalb der Plattform fest, die Sie tatsächlich verwalten werden.

Die eigentliche Wahl lautet: Anforderungen zuerst oder Plattform zuerst

„Speicherlayout zuerst“ kann zweierlei bedeuten. Es kann bedeuten, festzulegen, wie viel Schutz, Kapazität, Leistung und Erweiterbarkeit der Server benötigt, oder bestimmte Laufwerke einem Mirror, einer RAIDZ-Gruppe, einem Paritäts-Array oder einem Btrfs-Profil zuzuweisen, bevor das Betriebssystem ausgewählt wurde. Nur die erste Auslegung ist durchgehend sicher.

„NAS-Betriebssystem zuerst“ kann entweder bedeuten, ein Verwaltungsmodell auszuwählen, das zum Betreiber passt, oder einer ausgereiften Benutzeroberfläche automatisch die Speicherarchitektur zu überlassen. Ersteres kann sinnvoll sein; Letzteres birgt das Risiko, später festzustellen, dass die ausgewählte Plattform uneinheitliche Laufwerke nicht nutzen, nicht wie erwartet erweitert werden oder das gewünschte Dateisystem nicht importieren kann.

Der bestehende ZimaSpace-Vergleich von CasaOS, ZimaOS und Unraid für gemischte Laufwerke zeigt, warum sich Benutzeroberfläche und Speicher nicht vollständig getrennt betrachten lassen. Die richtige Reihenfolge lautet: Anforderungen, Kompatibilitätsauswahl und anschließend Implementierung.

Beginnen Sie mit den Daten und dem Fehlermodell

Listen Sie auf, welche Daten unersetzlich sind, welche erneut heruntergeladen werden können, welche sich häufig ändern und welche Anwendungen lange Speicherunterbrechungen nicht tolerieren. Ein Familienarchiv, ein Backup-Repository, eine Mediensammlung, ein VM-Datenspeicher und ein Aufbewahrungspool für NVR-Aufnahmen können dieselben Laufwerke verwenden, aber unterschiedliche Prioritäten bei Redundanz, Snapshots und Wiederherstellung erfordern.

OpenZFS dokumentiert, dass ein Pool aus virtuellen Geräten der obersten Ebene besteht, deren Struktur Redundanz und Fehlerverhalten bestimmt. Die vdev-Konzepte machen die Konsequenz für die Planung deutlich: Der Name eines Dateisystems beschreibt nicht das Schutzniveau, solange die zugrunde liegende Geräteanordnung nicht ebenfalls festgelegt ist.

Legen Sie den akzeptablen Fehlerzustand fest, bevor Sie eine markenbezogene Benutzeroberfläche auswählen. Entscheiden Sie, ob ein ausgefallenes Laufwerk das System in einen eingeschränkten Zustand versetzen darf, ob zwei Ausfälle toleriert werden müssen, wie lange ein Wiederaufbau dauern darf und ob ein unabhängiges Backup die Daten wiederherstellen kann, falls das Array selbst verloren geht.

Laufwerksgrößen und Erweiterungsmöglichkeiten können ein Betriebssystem frühzeitig ausschließen

Ein zusammengehöriger Satz neuer Laufwerke bietet andere Möglichkeiten als eine Sammlung wiederverwendeter 4-TB-, 8-TB- und 16-TB-Laufwerke. Herkömmliche Spiegel und Paritätsgruppen können Kapazität opfern oder eine gruppenweise Erweiterung erfordern, während andere Speichermodelle darauf ausgelegt sind, Datenlaufwerke unterschiedlicher Größe schrittweise hinzuzufügen.

Die offizielle Array-Dokumentation von Unraid besagt, dass keine Datenträger größer als der Paritätsdatenträger sein darf, und empfiehlt, SSDs für Cache-Pools statt für das primäre Paritäts-Array zu reservieren. Das ist keine unbedeutende Einstellung; sie beeinflusst, welche vorhandenen Laufwerke weiterhin sinnvoll genutzt werden können und wie die nächste Erweiterung angeschafft wird.

Wenn der Wachstumsplan vorsieht, „bei knapp werdender Kapazität jeweils ein Laufwerk mit abweichender Größe hinzuzufügen“, sollten Plattformen ausgeschlossen werden, die eine Neuerstellung fester Gruppen erfordern – es sei denn, der Betreiber akzeptiert eine spätere Migration. Wenn der Plan vorsieht, „gespiegelte Laufwerkspaare durch größere Laufwerke gleicher Größe zu ersetzen“, kann ein Speichermodell, das für die schrittweise Erweiterung mit Laufwerken unterschiedlicher Größe optimiert ist, unnötige Komplexität hinzufügen.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Das NAS-Betriebssystem bestimmt, welche Layouts nativ unterstützt werden

Nachdem die Anforderungen definiert sind, sollten Sie Betriebssysteme anhand der Speichermodelle in die engere Auswahl nehmen, die sie nativ und transparent verwalten. Ein Betriebssystem kann ein Dateisystem technisch unterstützen, jedoch integrierte Warnmeldungen, Austausch-Workflows, Kapazitätsschätzungen oder die Wiederherstellung der Konfiguration für die von Ihnen geplante Nutzung vermissen lassen.

TrueNAS bietet einen Workflow zur Pool-Erstellung, bei dem der Benutzer Layouts, Festplattengrößen, Datengeräte und die Anzahl der vdevs auswählt. Die aktuelle Dokumentation zur Pool-Erstellung von TrueNAS veranschaulicht, dass die Plattform erwartet, dass die Speicherarchitektur über ihr unterstütztes ZFS-Modell und nicht unabhängig davon festgelegt wird.

Gehen Sie nicht davon aus, dass die Installation einer Weboberfläche unter Linux jeden zugrunde liegenden Pool gleichermaßen verwaltbar macht. Die Plattform zeigt möglicherweise nur Speicher an, den sie selbst erstellt oder registriert hat, während die erweiterte Wiederherstellung weiterhin von den Befehlszeilentools und der Dokumentation des zugrunde liegenden Dateisystems abhängt.

Erstellen Sie den endgültigen Pool nicht, bevor Sie die Betriebssystemkompatibilität geprüft haben

Ein zu früh erstellter Pool kann Daten an eine Implementierung binden, die das bevorzugte NAS-Betriebssystem nicht über den üblichen Workflow importieren, überwachen, erweitern oder reparieren kann. Selbst wenn zwei Systeme dieselbe Dateisystemfamilie unterstützen, können Funktionsmerkmale, Verschlüsselung, Gerätepfade, Boot-Umgebungen und Anwendungs-Datasets die Migration erschweren.

OpenMediaVault dokumentiert, dass Dateisysteme, die außerhalb seiner Oberfläche eingebunden werden, nicht automatisch in der Backend-Datenbank registriert werden, um gemeinsam genutzte Ordner zu erstellen. Das Integrationsmodell für Dateisysteme zeigt, warum „Linux kann es einbinden“ nicht dasselbe ist wie „die NAS-Plattform kann es sauber verwalten“.

Verwenden Sie ungenutzte Festplatten oder virtuelle Datenträger, um zunächst das infrage kommende Betriebssystem zu testen. Überprüfen Sie die Erstellung von Pools und Freigaben, Snapshots, Warnmeldungen, den Austausch, die Erweiterung, den Export und den Import, bevor Sie Primärdaten verschieben. Der Test sollte den Verwaltungsweg validieren und nicht nur nachweisen, dass das Installationsprogramm die Laufwerke erkennt.

Die Zuordnung von Workloads erfolgt erst, wenn die Plattformgrenzen feststehen

In der Anforderungsphase sollten die Workloads ermittelt werden, die genaue Zuordnung sollte jedoch erst erfolgen, wenn Betriebssystem und Speicherverwaltungstools ausgewählt sind. Ein VM-Dataset, eine Metadatenebene, ein Anwendungspool, ein temporärer Download-Bereich und ein Medienarchiv können unterschiedliche Geräte erfordern, doch die verfügbaren Tiering- und Dataset-Steuerungen unterscheiden sich je nach Plattform.

Btrfs ermöglicht das Hinzufügen, Entfernen und Ersetzen von Geräten sowie die Konvertierung von Daten- und Metadatenprofilen, sofern ausreichend Arbeitsbereich vorhanden ist. Die offizielle Dokumentation zur Volume-Verwaltung zeigt ein anpassungsfähigeres Modell als die Planung mit festen vdevs. Diese Flexibilität erfordert jedoch weiterhin Überwachung und operatives Fachwissen.

Die ZimaSpace-Analyse zu NVMe-Arbeitsebenen für VMs und Datenbanken liefert den Workload-Test. Definieren Sie den Bedarf vor dem Betriebssystem und implementieren Sie die Ebene anschließend mit dem Speichermodell, das die gewählte Plattform sicher unterstützt.

Die Wiederherstellung sollte vor einer der beiden endgültigen Entscheidungen geplant werden

Ein NAS-Aufbau ist nicht abgeschlossen, sobald der Pool eingebunden ist. Der Besitzer sollte wissen, wie das Startlaufwerk neu installiert, die NAS-Konfiguration wiederhergestellt, der verbleibende Speicher importiert, Verschlüsselungsschlüssel wiederhergestellt, ein ausgefallenes Laufwerk ersetzt und Daten wiederhergestellt werden, wenn der Pool nicht importiert werden kann.

Das Speicherlayout bestimmt, was einen Laufwerksausfall übersteht, während das NAS-Betriebssystem festlegt, wie übersichtlich der verbleibende Zustand dargestellt wird und wie viel Konfiguration exportiert werden kann. Ein widerstandsfähiger Pool mit nicht dokumentierten Anwendungspfaden kann dennoch schwer wiederherzustellen sein; ein ausgereiftes Betriebssystem kann keine Daten wiederherstellen, die ausschließlich auf einem ausgefallenen Laufwerk ohne Redundanz vorhanden waren.

Dies ist die Abbruchgrenze: Wenn der Wiederherstellungsplan von einer Funktion abhängt, die nur ein bestimmtes Betriebssystem bietet, muss diese Plattform vor dem endgültigen Layout ausgewählt werden. Hängt die Wiederherstellung hauptsächlich von portablen Dateisystemen und deklarativer Konfiguration ab, bleibt mehr Flexibilität bei der Wahl des Betriebssystems.

Verwenden Sie einen Auswahlprozess in drei Durchgängen

1. Beschreiben Sie Kapazität, Laufwerksbestand, Workload, Ausfalltoleranz, Wachstum und Wiederherstellungsanforderungen, ohne ein Betriebssystem zu nennen.
2. Schließen Sie Betriebssysteme aus, die diese Anforderungen nicht mit einem dokumentierten und wartbaren Speichermodell erfüllen können.
3. Erproben Sie die übrigen Plattformen mit Ersatz- oder virtuellen Laufwerken und testen Sie Erstellung, Ausfall, Austausch, Erweiterung, Export und Import.
4. Wählen Sie das Betriebssystem, dessen üblicher Arbeitsablauf den Kenntnissen und der Wartungsbereitschaft des Besitzers entspricht.
5. Legen Sie das exakte Layout für Arrays, Pools, vdevs, Dateisysteme, Datasets, Caches und Anwendungsspeicher innerhalb dieser Plattform fest.
6. Dokumentieren Sie den Aufbau und stellen Sie ihn einmal wieder her, bevor Sie nicht ersetzbare Daten verschieben.

Die Reihenfolge verhindert zwei häufige Fehler: die Wahl einer attraktiven Benutzeroberfläche, die die geplanten Laufwerke nicht unterstützen kann, und den Aufbau eines technisch eleganten Pools, den das spätere NAS-Betriebssystem ohne nicht unterstützte Umgehungslösungen nicht verwalten kann.

Welche Entscheidung sollte den Ausschlag geben?

Lassen Sie die Speicheranforderungen den Ausschlag geben, wenn

Lassen Sie die Anforderungen den Ausschlag geben, wenn Laufwerksgrößen, Redundanz, Wachstum oder das Verhalten der Arbeitslast harte Einschränkungen vorgeben. Dies ist besonders wichtig bei gemischten Laufwerken, großen RAIDZ-Gruppen, der Aufbewahrung von Überwachungsaufnahmen, VM-Speicher oder Systemen, bei denen eine Erweiterung ohne vollständige Migration erfolgen muss.

Lassen Sie die Vorauswahl des NAS-Betriebssystems das endgültige Layout bestimmen, wenn

Lassen Sie die Vorauswahl der Plattform die Implementierung bestimmen, wenn dem Besitzer ein integrierter Laufwerksaustausch, Warnmeldungen, App-Speicher, der Export der Konfiguration und eine geführte Wiederherstellung wichtig sind. Wählen Sie nur Layouts, die das ausgewählte Betriebssystem über seinen üblichen Verwaltungsweg unterstützt.

Überdenken Sie die Hardware, wenn keine der beiden Optionen passt

Ändern Sie den Laufwerksbestand, fügen Sie eine separate SSD-Ebene hinzu, trennen Sie Speicher und Rechenleistung oder verschieben Sie den Aufbau, wenn kein Betriebssystem die Anforderungen sauber erfüllen kann. Eine inkompatible Kombination zu erzwingen, führt später genau dann zu zusätzlichem Migrationsaufwand, wenn sich die Daten am schwierigsten verschieben lassen.

Häufig gestellte Fragen

Kann man das NAS-Betriebssystem auswählen, bevor man Laufwerke kauft?

Ja, vorausgesetzt, die Anforderungen an Arbeitslast und Erweiterbarkeit sind bereits bekannt. Ermitteln Sie anhand der Dokumentation des Betriebssystems die unterstützten Layouts, die Mindestanzahl an Laufwerken, die Dimensionierung der Parität, die Rollen der SSDs, die Controller-Anforderungen und die Verfahren zum Austausch von Laufwerken, bevor Sie den endgültigen Laufwerkssatz kaufen.

Kann derselbe ZFS-Pool zwischen verschiedenen NAS-Betriebssystemen verschoben werden?

Manchmal, aber die Kompatibilität hängt von den unterstützten Pool-Funktionen, der Verschlüsselung, dem Importverhalten, dem Gerätezugriff, den System-Datasets und der Anwendungskonfiguration ab. Betrachten Sie den plattformübergreifenden Import als getesteten Migrationspfad und nicht als Selbstverständlichkeit.

Sollten Einsteiger das vorgeschlagene Pool-Layout übernehmen?

Erst nachdem nutzbare Kapazität, Ausfallsicherheit, Erweiterbarkeit, Arbeitslast und Backup-Anforderungen geprüft wurden. Ein vorgeschlagenes Layout kann ein sicherer Ausgangspunkt sein, kennt aber weder den Wert der Daten noch den künftigen Plan des Besitzers zum Austausch von Laufwerken.

Abschließendes Urteil

Legen Sie zuerst die Speicheranforderungen fest, nicht eine bereits vollständig festgelegte Speicherimplementierung. Erstellen Sie anschließend eine Vorauswahl von NAS-Betriebssystemen, die diese Anforderungen erfüllen, und legen Sie das genaue Layout innerhalb der gewählten Plattform fest. Diese Reihenfolge bewahrt die architektonische Disziplin, ohne so zu tun, als sei das Betriebssystem unabhängig von Array, Pool, Dateisystem, Erweiterungs- und Wiederherstellungsprozessen, die es verwalten muss.