UCS als ausfallsicherer Fileserver

UCS - Univention Corporate Server
, ,
#1

Hi,

ich versuche gerade mit UCS eine AD-Domäne aufzusetzen, Da diese möglichst ausfallsicher laufen soll, wird sie aus einem UCS-Master- und einem UCS-Slave-Server bestehen. Somit wäre zumindest was die Netzwerk-Dienste (AD, Keberos, DNS, DHCP) angeht, eine gewisse Redundanz gegeben.

Zusätzlich soll allerdings auch ein Fileservice mögliichst ausfallsicher bereitgestellt werden. Zu diesem Themenbereich habe ich allerdings in der Dokumentation und den Univention-Seiten leider nur relativ wenig Informationen gefunden.

Eine Überlegung war den Speicher via iSCSI bereitzustellen und diesen bereits redundant auszulegen. Das iSCSI-Target wird anschließend in ein UCS-System gemountet. Somit wäre weiterhin die Möglichkeit gegeben die Shares via UMC zu verwalten. In der UCS-Dokumentation findet das Thema iSCSI eigentlich nur im Kontext von UVMM. Können iSCSI targets auch via UMC eingebunden werden, sodass man diese nicht maneull über die Kommandozeile einrichten muss und die Mounts auch bei Updates/Upgrades etc. erhalten bleiben?

Gibt es hier evtl. jemand, der in diesem Bereich bereits Erfahrungen sammeln konnte oder auch alternative Umsetzungen im Einsatz hat? Vielen Dank im Voraus!

Viele Grüße
Frank

BackupDC mit Kopie der Freigaben
#2

Hallo :slight_smile: ,

Kleine Empfehlung meinerseits: Nimm einen UCS Master und einen UCS Backup. Dann hast du auch automatisch die SSL-PKI auf dem Backup nochmal vorgehalten und hättest im Fall der Fälle sogar die Option ein backup2master zu machen.

Nein, leider nicht.

Die bleiben erhalten, egal ob Kommandozeile oder nicht. Ein Update wird i.d.R. nicht die /etc/fstab anfassen und dir auch nicht die mounts wegkegeln.

#3

Hallo Michael,

danke für die super-schnelle Antwort!

Manchmal sollte man sich seine Posts nochmal genauer durchlesen :wink: :
UCS-Backup war gemeint - UCS-Slave habe ich geschrieben - sorry.

Ok d.h. also ein iSCSI-Mount dann einfach ‘klassich’ eingebunden werden.

Gibt es seitens Univention irgendeine Art ‘best practices’ / Empfehlungen was einen ausfallsicheren CIFS-Fileservice angeht?

Die Lösung via iSCSI war hier nur eine erste Idee meinerseits dazu. Im Gegensatz DHCP, DNS etc. habe ich in der Dokumentation leider in der Richtung nichts finden können.

Ein alternative Variante, die ich sehe, wäre, den Fileservices via CIFS über einen AD-Memberserver bereitzustellen, der bereits eine gewisse Ausfallsicherheit beinhaltet (hier stünden z.B. NAS-Server von Synology zur Verfügung). Wenn ich das allerdings richtig verstanden habe, würde dann nicht mehr die Möglichkeit bestehen, auch die Freigaben-Verwaltung via UMC zu machen, da es sich in diesem Fall ja dann um Non-UCS-Systeme handelt, Die Verwaltung der Freigaben würde dann über Tools der jeweiligen AD-Memberserver erfolgen.

Gruß
Frank

#4

Moin,

es gibt keine offizielle Empfehlung, weil die Szenarien alle ausgesprochen unterschiedlich sind. Wie mache ich das Storage hochverfügbar? Wie mache ich den Bereitstellungsdienst (also NFS- und Samba-Daemonen) hochverfügbar? Was für ein Budget habe ich für Hardware zur Verfügung? Welche Performance benötige ich?

Letztes Jahr hatte ich mal eine grobe Übersicht geschrieben (in Englisch). Da ich zu faul bin, das alles noch mal zu übersetzen, verlinke ich’s einfach nur. Das dort erwähnte DRBD gibt es z.B. inzwischen im AppCenter.

Bei konkreten Fragen: immer her damit.

Gruß,
mosu

#5

Moin Moritz,

danke für die Info zu dem Artikel! DRBD hatte ich bereits vor eingiger im Rahmen eines anderen Projekts verwendet . Im aktuellen Fall würde ich allerdings gerne mal iSCSI als Alternative testen.

Die Einbindung eines iSCSI-Targets in UCS war via Kommandozeile relativ problemlos möglich. Manuell lässt sich das Dateisystem anschließend auch problemlos mounten.

Beim automatischen Mount über die fstab via

LABEL=... <mountpoint> ext4 _netdev,user_xattr 0 0

hängt der boot-Prozess für 90 sec bis zu einem (systemd?)-Timout beim Versuch das Remote-FS einzubinden bzw. den iSCSI-Daemon zu starten. Am Ende des Boot-Prozesses ist das Dateisystem dann dennoch gemountet.

Im Debian-Bugtracker habe ich hierzu zwar einen älteren Bugreport gefunden, der ziemlich gut passt:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775778

Dieser Bug sollte allerdings mit dem aktuell im UCS mitgelieferten open-iscsi-Paket bereits behoben sein. Muss für iSCSI-Freigaben neben ‘_netdev’ evtl. noch ein spezieller Mount-Paramenter gesetzt werden?

Gruß,
Frank

#6

Huhu,

Keine Ahnung. Ich nutze iSCSI momentan gar nicht, hatte es aber mal in Benutzung, und dabei aufgrund der Abhängigkeiten beim Booten eben nicht über die fstab eingebunden. Statt dessen hatte ich den Auto-Mount-Support von systemd genutzt, weil ich damit zuverlässig das Scannen der iSCSI-Targets mit einbinden konnte. War aber alles nicht ganz trivial beim Aufsetzen, und da ich’s wie gesagt nicht mehr nutze, habe ich auch die dazugehörenden Dateien leider nicht mehr alle.

Was ich grob gemacht hatte, war einen Service zu schreiben, der beim Starten auf das benötigte Target gewartet hat (/etc/systemd/system/iscsi-disky-target1.service):

[Unit]
Description=log in to disky Target-1 iSCSI target
Requires=open-iscsi.service
After=open-iscsi.service
Before=remote-fs-pre.target

[Service]
RemainAfterExit=true
ExecStart=/bin/iscsiadm -m node --targetname=iqn.2000-01.com.synology:disky.Target-1.043d258dcb -p 192.168.191.11 --login
ExecStartPost=/etc/systemd/bin/wait_for /dev/disk/by-path/ip-192.168.191.11:3260-iscsi-iqn.2000-01.com.synology:disky.Target-1.043d258dcb-lun-0
ExecStop=/bin/iscsiadm -m node --targetname=iqn.2000-01.com.synology:disky.Target-1.043d258dcb -p 192.168.191.11 --logout

[Install]
WantedBy=remote-fs.target

Das wait_for sah so aus:

!/bin/zsh

if [[ -z $1 ]] exit 1

while [[ ! -e $1 ]]; do
  sleep 0.1
done

Und damit die Magie funktioniert hat, hatte ich .mount- und .automount-Units für systemd für den entsprechenden Pfad, die von besagtem Service oben abgehangen haben.

Gruß,
mosu

Mastodon