Dioptas (NAS)

Der Host Dioptas fungiert als dedizierter Fileserver auf der Basis von TrueNAS mit einer Nutzkapazität von ca. 14 Terabyte. Er vereint die Datensicherheit von ZFS, User und Berechtigungsverwaltung durch Active Directory und ACLs und verschiedene Share-Typen, darunter das universell kompatible SMB, mit einem intuitiven Web-Interface, das die Wartung erleichtert.

Features

Genaue Informationen zu dem Dateisystem ZFS, auf dem das alles aufsetzt:

Zielsetzung

Wir brauchen generell einen gemeinsamen Datenspeicher im Haus Mauerseglerei für

• betriebliche Daten
• vereinsinterne Daten
• Daten der IT
• private Daten

Dies im hier etwas genauer aufgeschlüsselt:

In folgendem Artikel haben wir beschrieben, weshalb wir uns für dieses Konzept entschienden haben:

Historie

• 2017: Zunächst war dieses Gerät als Testgerät gedacht (Dioptas-PVE)
• Danach habe ich versucht hier FreeNAS zu virtualisieren – mit mäßigem Erfolg
• Schließlich habe ich beschlossen FreeNAS (Dioptas-FreeNAS) als dediziertes System laufen zu lassen. Im April 2019 habe ich den Server entsprechend adaptiert.
• Seit Ende November 2020 läuft nun erfolgreich TrueNAS auf diesem Gerät.

Die weitere Geschichte wird hier gepflegt:

Zugriff

Adresse

Für alle nachfolgenden Zugriffsmethoden braucht man eine Adresse.
Der Server ist unter folgenden Adressen erreichbar:

• Interne IP-Adresse: 172.18.2.106
• Interne, vollständige URL: dioptas-nas.it.mauerseglerei.at
• Nutzerfreundliche URL: files.mauerseglerei.at
• Externe Adresse: gibt es bewusst nicht. Zu hohes Sicherheitsrisiko.

Hardware

• 9 Festplatten zu je 4TB in Wechselschächten
• 3 verschiedene SSDs optimiert für Betriebssystem, Logging und Performacnetests
• Enterprise-Level Festplattencontroller
• Netzwerkkarte mit 10Gbit/s
• 64GB Arbeitsspeicher mit ECC (Fehlerkorrektur)
• Quad-Core Prozessor mit bis zu 3,7GHz und 8 Threads

Details findest hier:

Hier ein Paar Bilder von unserem Server:

Installation & Konfiguration

Komponenten im Host

Die Verfügbare Hardware ist im Artikel Dioptas (Host) beschrieben. Im Wesentlichen hat das Gerät 64GB Arbeitsspeicher, damit ZFS gut Daten puffern kann und Hot-Swap-Bays, für 9 Festplatten (HDD) im Format 3,5″ und für 1 SSD im Format 2,5″. Diese Hot-Swap-Bays dienen dazu, dass wir kaputte Datenträger rasch austauschen können bzw. im Falle eines Schadens am Host die Datenträger schnell in eine andere Maschine übersiedeln können. Die Datenträger sind alle mit SATA an das Mainboard bzw an einen SATA-Controller angebunden. Ferner habe ich noch eine kleine M.2 SSD am Mainboard installiert, die aufgrund ihrer enormen Geschwindigkeit (über 2GB/s lesen und 1GB/s schreiben) als Testmaterial und als Rangierbahnhof dienen soll. Außerdem gibt es in dem Gerät eine 10GbE Netzwerkkarte.

OS Installation

Die Installation erfolgte von einem USB-Stick, der als Installationsmedium diente, auf eine SSD mit Power-loss-protection (für ruhende Daten). Die Arbeitsgeschwindigkeit ist nicht von Bedeutung, da diese nur beim Boot-Vorgang zum Tragen kommt, nicht im laufenden Betrieb.

Bei der Installation selbst wurden keine nennenswerten Einstellungen vorgenommen.

OS-Einstellungen

Die IP-Adresse wird erst nach der Installation vergeben, vorzugsweise gleich über die Konsole. Hier habe ich ein neues VLAN-Interface „vlan100“ erstellt, damit das Gerät im Server-VLAN kommunizieren kann, ihm den Master „ix0“ (das ist der obere Anschluss der Netzwerkkarte) zugeteilt und die IP-Adresse 172.18.2.106 vergeben. Diese IP-Adresse wurde im Router so eingestellt, dass ein Zugriff auf diese mittels SMB aus allen User-VLANs im Haus und aus der DMZ heraus möglich ist. Die Konfiguration für das Ethernet-Interface ix0 (oder was am Anfang initialisiert wurde) habe ich gelöscht, damit es zu keien Konflikten kommen kann.

Außerdem setzt man hier das Default Routing aka Gateway auf 172.18.2.254 und den DNS ebenso.

Nun ist das System bereit und man kann über das Web-Interface darauf zugreifen.

• Zeitzone: Vienna
• Keyboard: German

ZFS-Pools und Datasets

hdd-pool

Als Pool wird ein Verband aus Datenträgern bezeichnet, die sich gegenüber zugreifenden Instanzen verhalten, als wäre es ein Datenträger. Der wichtigste Pool in diesem System ist der Festplattenpool, auf dem die Daten des Vereins, aber auch einzelner Gemeinschaftsmitglieder, Familien und Freunden als Speicherplatz zur Verfügung gestellt wird. Die Haus-IT wird sich bemühen die Daten so sicher als möglich zu verwahren, übernimmt allerdings keine Haftung. Dieser Pool, genannt „hdd-pool“ besteht aus folgenden Komponenten:

• 1 Datenspeicher über den alle Daten gleichmäßig verteilt (Striping) werden um die Geschwindigkeit zu maximieren. Bestandteile:
  • 4 Paare aus gespiegelten Festplatten (Mirror). Fällt eine aus, dann hat die andere immer noch alle Informationen. Konkret sind das 8 WD Red Festplatten mit je 4TB Kapazität, die speziell für den Einsatz in einer NAS konzipiert sind. Die Kapazität einer Platte mit 4TB wurde so gewählt, dass das Resilvering (siehe ZFS) ca. 7 Stunden, also eine Nacht, dauert. Nutzkapazität gesamt etwa 14TB.
• 1 SLOG-Device. Man könnte vereinfacht sagen, ein Schreibpuffer, was dem allerdings nicht gerecht. Details im Artikel ZFS. Das ist ein Datenträger, der den Inhalt aller synchronen Schreibprozesse aufbewahrt bis sie tatsächlich im Speicher-Pool abgelegt werden und daher erlaubt, dass das Antwort-„Acknwoledge“ des Schreibprozesses vorzeitig zurückgesendet wird. Nach außen hin wirkt der Pool daher viel zackiger. Das SLOG-Device ist eine Intel 900P die eine Schreiblatenz von nur 200µs hat.
• 1 Hot Spare: Noch eine WD Red Platte mit 4TB die auf ihren Einsatz wartet, wenn es zum automatischen Resilvering kommen sollte.

nvme-pool

Ich habe noch einen zweiten Pool eingerichtet, der „nvme-pool“ heißt. Dieser dient wie erwähnt nur zu Performance-Tests und als Rangierbahnhof und besteht aus

• 1 Datenspeicher aus 1 M.2 NVME-SSD SM951 von Samsung mit 256GB

Datasets

ZFS-Datasets sind Order, die ein bisschen mehr können. Datasets können auch in Datasets geschachtelt werden. Wichtig ist, dass wir bei jenen Datasets, die uns später als SMB-Shares dienen sollen auch den Typ SMB auswählen. An ZFS-Datasets habe ich im HPP-Pool folgendes angelegt:

• group
  • Familie
    • <Nachnamen>
  • Server
    • Proxmox
      • smb
      • zvol
  • Thema
    • Mauerseglerei
• user
  • home
  • manual
• system
  • truenas
  • test
    • download
    • upload
    • backup

Un im NVME-Pool:

• test
  • download
  • upload
• temp

Überall verwende ich default-einstellungen außer bei

• Datasets, die SMB-Shares werden sollen. Da wird der Typ auf SMB gesetzt womit der Case-Typ automatisch auf insensitiv springt.
• vm ist kein Dataset sondern ein zvol
• home ist ein homes-Share, aber dazu später
• temp ist ein guest-Share, auch hierzu später

User und Gruppen ACLs kann man erst nach der AD-Integration erstellen.

Active Directory Integration

CA Certifikat

Um sich erfolgreich mit dem zentralen Benutzerverwaltungssystem, bei uns ist das der Univention Corporate Server (UCS), verbinden zu können, müssen wir die Forderung von FreeNAS nach einem anerkannten SSL-Zertifikat erfüllen. Natürlich hat unser UCS ein selbstsigniertes Zertifikat. Um dieses FreeNAS schmackhaft zu machen muss man das CA-Zertifikat des UCS importieren.

Dazu verbindet man sich mit SSH mit dem UCS.

cat /etc/univention/ssl/ucsCA/CAcert.pem

Den Bereich

-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

kopieren.

Dies kann nun im FreeNAS-Webinterface unter System > CAs > Add > Type > Import CA (wähle name, no private key, no passphrase) eingefügt werden.

DNS-Server

Es ist unumgänglich, dass die DNS-Setting stimmen, denn sonnst klappt das Kommando kinit, das vom WebGUI beim Beitritt zur AD-Domain aufgerufen wird, nicht. im WebGUI gehe man daher zur Rubrik Network und dort zu Global Configuration.

Hostname: dioptas-nas

Nameserver:

• 172.18.2.104 (unser AD-Domaincontroller)
• 172.17.2.254 (unser Router, falls der AD-DC mal offline ist)
• 8.8.8.8 (Google-DNS, just in Case)

Ich habe auch die Domain auf IT.MAUERSEGLEREI.AT gesetzt.

Kerberos Realm

Gehe im FreeNAS GUI zu den Directory Services und darin zu Kerberos Realms. Datin gege auf „Add“ und auf „Advanced Mode“. Gib folgende Parameter ein und speichere dann:

• Realm: IT.MAUERSEGLEREI.AT
• KDC: 172.18.2.104
• Admin Server: 172.18.2.104
• Pasword Server: 172.18.2.104

Ich hege die Vermutung, dass dies bei korrekt konfiguriertem DNS-Server gar nicht nötig ist, aber die Info habe ich noch nicht verifiziert.

SMB Service

Gehe im FreeNAS GUI zu den Services und in der Zeile SMB auf Configure. Dort stelle die Workgroup um. Die Workgroup in der Mauerseglerei heißt „IT“.

Starte und Autostarte den SMB-Service.

Active Directory Service

Ich habe mir angewöhnt zuerst die Daten einzutragen, vorerst nicht zu enablen, dann die Daten zu checken, dann das Passwort eintragen und dann erst enablen. So passieren weniger Fehler. Außerdem notiere ich im Folgenden nur die aktiven neuen Eintragungen und Änderungen. Standardwerte werden belassen und nicht weiter erwähnt.

Als erstes klicke man mal auf „advanced mode“ und beginne mit den Eintragungen:

• Domain Name: IT.MAUERSEGLEREI.AT
• Domain Account Name: Administrator (dies ist der quasi-root aufm Univention Corporate Server)
• Kerberos Realm: Select IT.MAUERSEGLEREI.AT

Save. Ich schließe den Vorgang noch nicht ab, damit ich die Settings zwischenzeitlich speichern kann, falls der Join schiefgeht.

• Domain Account Passwort
• Enable

Save. Nun ist ein Button „leave domain“ erschienen. Das ist ein gutes Zeichen. Wir sind in der Domain.

ACLs für User und Gruppen setzen

ACLs lassen sich im Web-Interface für Pools, Datasets und zVOLs erstellen. Ich spreche fortan von Datasets, meine allerdings alle drei.
Um ACLs für Datasets zu bearbeiten kehrt man zurück zum Menü Storage > Pools
Für jedes Dataset gibt es am Ende der Zeile das Symbol mit den drei Punkten um an das Kontextmenü zu gelangen. Hierin findet sich „Edit Permissions“.

Per default haben alle Datasets das klassische Benutzer(Owner)/Gruppe(Ownergroup)/Andere(Everyone) Berechtigungsschema, welches von ACLs abgelöst werden kann.
Wir verwenden ACLs nur bei Datasets, die wir sharen (z.B. via SMB) und deren Unterordnern.

Beim User (Owner) eines Datatsets belasse ich meistens root.
Bei dem Gruppen (Ownergroup) trage ich üblicherweise die Berechtigungsgruppe oder Usergruppe ein, die ich tatsächlich schreibend zugreifen lassen möchte. Dies spart mir einen zusätzlichen ACL Eintrag. Hier nicht auf das Hakerl bei „Apply Group“ vergessen. Wenn man für eine Gruppe die Ownergroup verwendet steht beim ACL-Item im Feld „Who“ der Wert „@group“, während, wenn man nicht die Ownergroup verwendet ist es einfach „Group“ und die Gruppe wird im Feld darunter ausgewählt.

Im Dropdown für User und Gruppen erscheinen nach erfolgreicher AD-Integration sowohl die lokalen User und Gruppen als auch jene von unserem zentralen Userverwaltungssystem. Letztere beginnen mit IT\… . Das Dropdown listet nicht alle User/Gruppen sofort, da die Liste längenlimitiert ist, daher beginne man zu tippen um die besten Matches zu erhalten.

SMB-Shares einrichten

Im Web-Interface unter Sharing werden die tatsächlichen Shares eingerichtet. Wir verwenden zwecks möglichst weitreichender Kompatibilität SBM-Shares. Wenn man einen Share Einrichtet werden einem anfänglich keine Einstellungsparameter angeboten, sondern nur Presets. Für viele Anwendungszwecke reichten die „Deault Settings“ aus. Will man manuelle Anpassungen an den Einstellungen vornehmen (z.B. um einen home-Share oder guest-Share zu errichten) ist es nötig auf „keine Defaults“ zu wechseln. Dann finden sich unter „Advanced“ alle verfügbaren settings.

Nachdem man die Shares erstellt hat kann man deren Berechtigungen einrichten. Dabei gibt es zwei Aspekte

• Filesystem Permissions: Dies gilt für die Datasets zu den Shares, siehe oben
• Share Permissions: Dies git für die SMB Permissions. Eingentlich reicht es aus mit den Permissions auf Datasets zu arbeiten. Diese Persmissions sind interessant, wenn man Access Based Enumeration verwendet (d.h. der Share wird beim Browsing nur dargestellt, wenn der browsende User Berechtigungen hat). Hierzu löscht man die SID raus, trägt als Domain ID ein und bei Gruppe ebendiese. Die korrekte SID wird dann beim Speichern ermittelt.

Wichtiger Hinweis: Die Shares funktionieren nur, wenn der Pfad bis dahin (alle Datasets in der Kette bis zu jenem das geshared wird) zumindest Lese und/oder (?) Ausführungsberechtigungen für „other“/“Everyone“/“Jeder“ haben.

Automatische Tasks

• SMART Tests:
  Zur Tauglichkeitsprüfung laufen wöchentlich SMART Tests aller Datenträger. Jeden Sonntag um 1:00 nachts.
• Scrub Tests:
  Prüfsummentestes aller Datenblöche aller Datenträger. Läuft jeden Samstag um 1:00nachts.
• Snapshots:
  Speicherabbilder für die Wiederherstellung von alten Versionen aller veränderten Dateien im gesamten hdd-pool (d.h. von allen Datasets) werden erstellt. In der Testphase werden Snapshots 2 Wochen behalten, dann automatisch gelöscht. Läuft täglich um 0:00 nachts.
• RSync:
  Backups werden via SSH und RSync an den Backupserver übertragen (siehe hier). Das Backupkonzept ist noch nicht fertig (siehe Backup-Strategie). Läuft täglich um 2:00 nachts.

Performance

Es sieht so aus, als könnten wir auf den HDD-Pool (wenn wir von der NVME große Dateien kopieren) mit rund 500MB/s konstant schreiben. Wenn man über das Netzwerk schreibt und der Cache zum Einsatz kommt kann man kurzftistig 1GB/s erreichen. Realistische Geschwindigkeiten für Uploads liegen bei konstanten 350MB/s. Für Downloads verhält es sich ähnlich, vielleicht etwas besser. Im Alltag erweist sich die 1Gbit/s (120MB/s) Netzwerkleitung in den Wohneinheiten bzw. das WLAN als Bottleneck. Was sich bei den Tests ebenfalls als Bottlenech kerausstellt ist, dass bei SSDs (auch bei NVME) dir hiohen Geschwindigkeiten nur solange erreicht werden, solange deren Cache nicht voll ist. Sobald der Cache gefüllt ist gibt es einen massiven Einbruch in der Geschwindigkeit und dann eine Erholung zu einem Steady State. Ebenfalls macht sich der Cache am ZFS-system bemerkbar. Beim zweiten mal Herunterladen ist die Geschwindigkeit fast am Maximum der Netzwerkgeschwindigkeit.

Die Probleme mit Network Congestion bei 10GBit-Network die wir bei FreeNAS 11 hatten (siehe Dioptas-FreeNAS) sind bei TrueNAS 12 verschwunden.

Zuletzt bearbeitet am 10. Juli 2022 von Adrian Kowar