ADMIN

2023

09

2023-08-30T12:00:00

Hochverfügbarkeit und Monitoring

SCHWERPUNKT

076

Hochverfügbarkeit

Cluster

Hochverfügbarkeit bei QNAP und Synology

Doppeltes Lottchen

von Martin Loschwitz

Veröffentlicht in Ausgabe 09/2023 - SCHWERPUNKT

Speichergeräte von QNAP und Synology erfreuen sich großer Beliebtheit. Gerade in kleineren Firmen bilden sie das Rückgrat des Backups und dienen als zentraler lokaler Speicher für Abteilungen und ganze Unternehmen. Entsprechend groß ist der Katzenjammer, wenn ein NAS ausfällt, denn dann steht in Teilen der Firma im schlimmsten Fall die Arbeit still. Wie sich das durch ein sinnvolles Konzept zur Hochverfügbarkeit mittels Clustering umgehen lässt, zeigt dieser Artikel.

Datenbanken, unstrukturierte Inhalte wie Fotos und Videos sowie heruntergeladene Dateien knabbern kontinuierlich am verfügbaren Speicherplatz. Längst sind Unternehmen dazu übergegangen, aus diesem Grund lokale wie zentrale Speicher zum festen Bestandteil ihrer IT zu machen. NAS-Appliances von QNAP oder Synology sind hier sehr beliebt. Denn sie sind auch in kleineren Konfigurationen zu bekommen und erleichtern dank ihrer umfangreichen GUI die Verwendung der Speicher erheblich.
Auch können Unternehmen so Geld sparen und gleichzeitig die Sicherheit der hinterlegten Daten erhöhen. Denn einerseits lässt sich ein NAS mit normalen Festplatten problemlos betreiben, die obendrein sehr groß sind. Der limitierende Faktor beim Zugriff ist in der Regel das Netzwerk, sodass schneller, Flash-basierter Speicher gar keine Notwendigkeit ist. Und andererseits lässt sich ein NAS hervorragend zu einem zentralen Dienst im jeweiligen Backupkonzept machen.
NAS als Single Point of Failure
Was viele Administratoren im Eifer des Gefechts allerdings vergessen: Ein NAS stellt einen klassischen Single Point of Failure (SPOF) dar. Zwar werden die Geräte seitens der Anbieter mittlerweile mit etlichen Ebenen interner Redundanz ausgeliefert. RAID5 oder RAID6 gehören bei größeren NAS-Appliances mittlerweile etwa ebenso zum guten Ton wie redundante Netzteile bei 19-Zoll-Geräten im professionellen Umfeld. Doch ein Fehler auf dem Mainboard eines solchen Geräts, kaputter RAM oder die Notwendigkeit, den Strom abzustellen, macht den Kisten trotzdem schnell den Garaus.
Datenbanken, unstrukturierte Inhalte wie Fotos und Videos sowie heruntergeladene Dateien knabbern kontinuierlich am verfügbaren Speicherplatz. Längst sind Unternehmen dazu übergegangen, aus diesem Grund lokale wie zentrale Speicher zum festen Bestandteil ihrer IT zu machen. NAS-Appliances von QNAP oder Synology sind hier sehr beliebt. Denn sie sind auch in kleineren Konfigurationen zu bekommen und erleichtern dank ihrer umfangreichen GUI die Verwendung der Speicher erheblich.
Auch können Unternehmen so Geld sparen und gleichzeitig die Sicherheit der hinterlegten Daten erhöhen. Denn einerseits lässt sich ein NAS mit normalen Festplatten problemlos betreiben, die obendrein sehr groß sind. Der limitierende Faktor beim Zugriff ist in der Regel das Netzwerk, sodass schneller, Flash-basierter Speicher gar keine Notwendigkeit ist. Und andererseits lässt sich ein NAS hervorragend zu einem zentralen Dienst im jeweiligen Backupkonzept machen.
NAS als Single Point of Failure
Was viele Administratoren im Eifer des Gefechts allerdings vergessen: Ein NAS stellt einen klassischen Single Point of Failure (SPOF) dar. Zwar werden die Geräte seitens der Anbieter mittlerweile mit etlichen Ebenen interner Redundanz ausgeliefert. RAID5 oder RAID6 gehören bei größeren NAS-Appliances mittlerweile etwa ebenso zum guten Ton wie redundante Netzteile bei 19-Zoll-Geräten im professionellen Umfeld. Doch ein Fehler auf dem Mainboard eines solchen Geräts, kaputter RAM oder die Notwendigkeit, den Strom abzustellen, macht den Kisten trotzdem schnell den Garaus.
Das beutelt gerade KMUs, die nicht über redundanten Strom verfügen oder auf Geräte im klassischen NAS-Format setzen, weil ein 19-Zoll-Rack nicht verfügbar ist. Wie wichtig Netzwerkspeicher im professionellen Umfeld sind, fällt vielerorts erst auf, wenn das Gerät gerade mal nicht zur Verfügung steht. Spätestens dann bereut der Admin, sich über das Thema Hochverfügbarkeit im NAS-Kontext keine Gedanken gemacht zu haben.
Die gute Nachricht ist, dass auch mit klassischen SoHo-Appliances der NAS-Kategorie Hochverfügbarkeit durchaus machbar ist. Das gilt für Synology noch mehr als für QNAP, denn hier ist eine entsprechende Funktion sogar in der Firmware der Geräte implementiert. Bevor es um die praktische HA-Ausprägung bei beiden Herstellern geht, wollen wir kurz noch etwas die Theorie rund um das Thema Hochverfügbarkeit beleuchten.
Hardware und Konzepte
Zwar kommt das Thema Hochverfügbarkeit ursprünglich nicht aus dem NASKontext, doch gelten die meisten Prämissen der klassischen Hochverfügbarkeit auch bei QNAP und Synology. Grundsätzlich gilt: Je nach Art des Diensts und der Beschaffenheit des genutzten Protokolls ist Hochverfügbarkeit leicht oder komplizierter zu implementieren. Ein Beispiel verdeutlicht das gut.
Eine zentrale Rolle beim Thema HA spielt stets das Thema Netzwerk. Praktisch alle Dienste, für die auf der Serverseite HA konfiguriert werden kann, folgen dem Server-Client-Prinzip und sind über eine klassische Ethernet-Anbindung zu erreichen. Dabei lassen sich zwei Kategorien von Verbindungen unterscheiden: Verbindungen mit Zustand (stateful) sowie solche ohne Zustand (stateless).
Verbindungen letzteren Typs sind relativ einfach hochverfügbar zu gestalten. Damit HA hier klappt, muss im Falle des Ausfalls eines Diensts oder eines ganzen Geräts lediglich ein anderes Gerät an dessen Stelle treten, das identisch konfiguriert ist. Von herausragender Bedeutung ist dabei die IP-Adresse, über die der Netzwerkzugriff stattfindet. Denn alle Protokolltypen, die nicht erst in jüngster Vergangenheit entstanden sind, setzen die Konfiguration eines Servers mit einer festen Adresse oder einem festen Hostnamen voraus. Ein Webserver-Setup ohne vorgeschalteten Loadbalancer beispielsweise geht davon aus, dass der Client exakt eine Adresse aufruft, um die Verbindung zum Server herzustellen.
In HTTP ist es schlicht nicht möglich, dem Client mehrere Adressen zu übergeben, die er dann der Reihe nach oder zufällig durchprobiert. Fällt ein System mit einem laufendem Webserver aus, genügt es hier bei Vorliegen einer klassischen HTTP-Verbindung jedoch, wenn ein anderes System die nun verwaiste IP lokal aktiviert und dafür sorgt, dass der Webserver unter dieser lauscht. Haben beide Webserver Zugriff auf dieselben Assets, landet der anfragende Client beim nächsten Versuch beim neuen, laufenden Server und bekommt die passende Antwort. Auf der technischen Ebene genügt es dazu regelmäßig, eben nur die IP-Adresse umzuziehen.
Komplexer Aufbau bei Stateful-Verbindungen
Komplexer ist Hochverfügbarkeit, wenn es um Verbindungen mit Zustand geht. Das ist beispielsweise bei Datenbanken der Fall. Hat ein Client eine aufrechte Verbindung zur Datenbank und diese stürzt ab, wird er beim nächsten Schreib- oder Leseversuch vermutlich in einen Timeout laufen. Wichtig: Sie als Administrator können das nicht ändern. Hochverfügbarkeit für Stateful-Verbindungen lässt sich nur dadurch sinnvoll implementieren, dass die Clients ein sogenanntes Retry-Feature verwenden. Dann versuchen sie nach dem Zusammenbruch der bestehenden Verbindung automatisch, sie erneut zu starten. Auch hier ist dazu die IP-Adresse des Systems, auf dem die Datenbank nun läuft, lokal zu aktivieren. Um das zu merken und entsprechende Maßnahmen einzuleiten, kommt dabei ein sogenannter Cluster-Manager zum Einsatz.
Bei NAS-Laufwerken bekommen Sie als Administrator es je nach Umgebung mit beiden Diensttypen zu tun. Ein NFS-Server beispielsweise lässt sich heute stateful oder stateless betreiben, was im Alltag jeweils eigene Vor- wie Nachteile hat. Andere Protokolle bieten diesen Luxus nicht. Datenbanken etwa erzwingen einen neuen Aufbau der Verbindung, was zu unangenehmen Nebeneffekten führen kann, etwa im Hinblick auf den letzten Zustand der Datenbank. Stateful-Protokolle müssen jedenfalls die Option für Clients bieten, zuverlässig zu merken, ob ein Schreibvorgang erfolgreich abgeschlossen werden konnte. "Erfolgreich" impliziert dabei, dass eine Änderung der Daten nicht nur auf dem eigentlichen Zielsystem stattgefunden hat, sondern auch auf dessen Clusterpartner.
Je nach Diensttyp kann der Ausfall eines NAS-Systems zudem größere oder kleine Auswirkungen haben. Etliche NAS-Geräte bieten beispielsweise die Möglichkeit, iSCSI-Targets für virtuelle Instanzen zu exportieren. Hier ist es in aller Regel jedoch nötig, die VM zumindest neu zu starten, wenn auf Seiten des NAS ein Failover stattgefunden hat. Was technisch automatisiert durchaus machbar ist, den Rahmen dieses Artikels jedoch sprengen würde. Für die klassischen NAS-Umgebungen sind die Grundvoraussetzungen mithin ein synchroner Datenbestand und eine wie auch immer geartete Funktion eines Cluster-Managers, um im Fehlerfall einzugreifen.
Anforderungen stellen sich zudem an die genutzte Hardware. Es hilft nicht, ein uraltes NAS als HA-Partner eines nagelneuen Systems mit ordentlich Bumms unter der Haube zu konfigurieren. Das findet sich in vielen Firmen zwar so wieder, weil das alte NAS für "zu schade" zum Wegwerfen scheint. Bei einem tatsächlichen Failover-Ereignis ist aber davon auszugehen, dass die Grundlast die alte Kiste überfordert, während das neuere System problemlos mit ihr klargekommen ist. Sinnvoll ist stattdessen die Anschaffung zweier identischer Geräte mit gleicher Konfiguration und identischem verfügbaren Speicherplatz. Das zwingt zwar dazu, anfangs tiefer in die Tasche zu greifen. Es erspart dem Admin im weiteren Verlauf aber auch viel Arbeit und Stress.
Synology: HA ab Werk
Den Anfang der beiden großen Hersteller macht Synology, weil dort das Paket "Synology High Availability" fester Bestandteil des Betriebssystems vieler Geräte ist und entsprechende Konfigurationen sich einfach per GUI anlegen lassen. Es sei allerdings erwähnt, dass nicht jede Diskstation von Synology die SHA-Funktionalität unterstützt. Wer vor dem Kauf eines Geräts steht und wissen möchte, ob dieses Hochverfügbarkeit bietet oder nicht, schaut idealerweise auf der Website des Herstellers zu eben diesem Feature nach, denn dort findet sich eine komplette Liste der supporteten Modelle [1].
Anhand äußerer Faktoren wie dem Preis lässt sich kein zuverlässiger Rückschluss darauf ziehen, ob ein Gerät SHA unterstützt oder nicht. Die teureren Geräte der 19-Zoll-Klasse bieten SHA fast ohne Ausnahme. Auch klassische SoHo-Geräte wie die DS718+ beherrschen die HA-Funktionalität. Wichtig: SHA setzt zwingend zwei Synology-Geräte gleicher Konfiguration voraus, sogar die Firmware der Geräte muss abgeglichen sein. Ansonsten verweigert der SHA-Manager kategorisch die Arbeit.
Wer die beschriebenen Anforderungen erfüllt, kommt jedoch in den Genuss umfassender HA-Features. Denn in SHA sind viele Funktionen verbaut, die Ihnen aus dem Kontext klassischer Cluster-Manager wie Pacemaker möglicherweise bereits bekannt vorkommen. Erkennt ein Synology-Gerät den Ausfall des Clusterpartners, initiiert es den Failover automatisch. Den Gesundheitszustand der HA-Konfiguration überprüfen die Geräte ebenfalls regelmäßig selbst. Das verringert die Gefahr, dass HA-Funktionen zwar vorhanden sind, aufgrund von Konfigurationsänderungen zwischenzeitlich aber nicht mehr korrekt funktionieren.
In seiner Dokumentation weist Synology darauf hin, dass der HA-Dienst nicht sämtliche Funktionen der Geräte vollständig unterstützt. So ist Hochverfügbarkeit nur für die Protokolle CIFS (also Samba), iSCSI, AFP, FTP, NFS sowie den Synology Directory Server verfügbar. Damit dürfte allerdings der größte Teil der täglich benötigten Dienste in den meisten Umgebungen abgedeckt sein.
Voraussetzungen für SHA
Wer zwei passende Synology-Geräte sein eigen nennt, bringt diese für einen HA-Aufbau relativ schnell an den Start. Allerdings müssen ein paar technische Voraussetzungen erfüllt sein, damit SHA richtig funktioniert. Von essenzieller Bedeutung ist beispielsweise ein "Heartbeat"-Link zwischen den Knoten. Ein Synology-Cluster aus zwei Systemen ist vor dem Hintergrund verteilter Systeme eine Art Sonderfall. Denn eigentlich benötigen Systeme dieser Art mindestens drei Clustermitglieder, um auf Ereignisse wie eine Netzwerkpartition durch defekte Netzwerkhardware adäquat reagieren zu können.
Damit es in Clustern nicht zu Split-Brain-Situationen kommt, während derer Clients unkoordiniert auf beide Seiten eines Clusters schreiben (und dadurch einen Restore aus dem Backup erzwingen), setzen moderne Lösungen für HA-Cluster auf das so genannte Quorum. Das bedingt, dass nur solche Systeme aktiv sind, die mehr als die Hälfte ihrer Clusterpartner als aktiv und funktional erkennen. Eben das geht bei Zwei-Knoten-Clustern aber nicht; hier ist stets nur die eine Hälfte aktiv.
Es empfiehlt sich deshalb dringend, dem Herstellerrat zu folgen und eine direkte, kabelbasierte Netzwerkverbindung ohne Switches zwischen den beiden Synology-Geräten herzustellen. Hier gibt es dann doch wieder eine (indirekte) Einschränkung der nutzbaren Hardware – denn wer einerseits einfachen Switch-Ausfällen vorbeugen will und andererseits HA verwenden möchte, braucht effektiv vier Netzwerk-Schnittstellen. Manche Geräte gerade kleinerer Konfiguration kommen allerdings nur mit zwei NICs daher.
Der Hersteller weist zudem darauf hin, dass nach dem Anlegen eines HA-Clusters verschiedene Optionen in der Diskstation nicht mehr verfügbar sind. So lassen sich etwa die Positionen von Festplatten in den einzelnen Einschüben der Geräte nicht mehr wahllos verändern, wenn die HA-Funktion einmal aktiv ist. Zudem ist zu berücksichtigen, dass die HA-Features eine gewisse Grundlast auf den betroffenen Systemen erzeugen.
Assistenten-geführte HA-Konfiguration
Wenn Grundinstallation und Netzwerkverkabelung fertig sind und auch eventuell redundante Verbindungen passen, steht die Konfiguration der Geräte selbst auf dem Plan. Loggen Sie sich dazu mit einem Account in Ihr Synology-NAS ein, der in der Gruppe "administrators" ist. Klicken Sie gleich im Hauptfenster auf "Synology High Availability" (Bild 1) und dann auf "High-Availability-Cluster erstellen". Vollziehen Sie diesen Schritt zunächst allerdings nur auf dem System, das gerade die "aktive" Rolle innehat – von dem aus also die Konfiguration von Diensten und Volumes auf das andere Gerät gespiegelt werden soll.
Bild 1: Synology bringt einen eigenen Konfigurationsassistenten für HA mit, der sich aus dem Hauptmenü des Betriebssystems heraus aufrufen lässt.
Klicken Sie auf "Weiter" und quittieren Sie die Empfehlungen zur Netzwerkkonfiguration durch einen erneuten Klick auf "Weiter". Geben Sie dann die Benutzerdaten eines Accounts ein, der auf dem anderen – also aktuell passiven – Synology-System zur Gruppe "administrators" gehört, sowie dessen IP-Adresse. Der Setupassistent der HA-Funktion loggt sich dann beim künftigen Cluster-Partner ein.
Dann fragt der Assistent Sie nach der so genannten virtuellen IP für Cluster-Dienste. Das ist die IP-Adresse, die im Fall eines Failovers später zwischen den Clusterpartnern hin- und herschwenkt. Es sollte sich also nicht um eine der beiden IP-Adressen handeln, die auf den Synology-Systemen bereits fest vergeben sind. Danach überprüft der Assistent, ob alle Voraussetzungen für ein HA-Setup gegeben sind. Ist das der Fall, sehen Sie einen Bestätigungsdialog, in dem Sie auf "Übernehmen" klicken. Aktivieren Sie im nächsten Fenster das Kontrollkästchen, nachdem Sie die Informationen dort gelesen haben, und klicken Sie auf "Ja". Dann beginnt die automatische Einrichtung des HA-Clusters.
Die Synology-App für High Availability leistet über die Konfiguration des Clusters hinaus übrigens sehr wertvolle Dienste. Hier können Sie einen Switchover initiieren, also das Umschalten von einer auf die andere Synology-Instanz. Das sollten Sie tun, wenn Sie eines der Systeme warten oder seine Hardware aufstocken wollen – was das Ausschalten des Gerätes bedingt. Auch lässt sich der HA-Cluster hier auf Wunsch wieder zurückbauen.
Ein letzter Hinweis: Wird ein Synology-Gerät zum Mitglied eines HA-Clusters, installiert das Betriebssystem auf der Maschine automatisch NTPd und SSHd. Falls die Geräte aus dem Internet zu erreichen sind, müssen Sie die genutzten Firewallregeln an dieser Stelle möglicherweise anpassen. Für einzelne Dienstarten gibt es zudem noch Sonderkonfigurationen im Synology-NAS. So lassen sich zwei separate NAS-Laufwerke beispielsweise als primärer und sekundärer Mailserver betreiben. Das hat mit Clustering zwar nicht unmittelbar etwas zu tun, kann im Fehlerfall aber dafür sorgen, dass E-Mails auf den Systemen zustellbar bleiben (Bild 2).
Bild 2: Neben klassischem Clustering lässt sich ein Synology-NAS für spezifische Dienste wie E-Mail im HA-Modus betreiben.
QNAP: umständlicher und nicht so leistungsfähig
Auch wenn die einzelnen Schritte zur Installation und Konfiguration von HA bei Synology nicht zu unterschätzen sind, betten sich Synology-Kunden letztlich doch recht komfortabel. Denn wer beim Konkurrenten QNAP schaut, hat deutlich mehr Aufwand vor sich, bekommt dafür aber nur ein relativ beschnittenes Featureset geboten. Das hat mehrere Gründe. Der wichtigste: QNAP sieht in der eigenen Software, also in QTS oder QuTS hero, schlicht keine native HA-Funktionalität vor. Funktionen wie das Management eines HA-Clusters lassen sich mit den werkseigenen Betriebssystemen insofern kaum sinnvoll realisieren. Möglich ist aber, sich ein Konstrukt aus zwei QNAP-Geräten zu bauen, die gewisse Features eines HA-Clusters nachahmen.
Wie das in der Praxis aussehen kann, beschreibt der Hersteller auf einer eigens dafür eingerichteten Website [2]. Schritt eins besteht demnach darin, zwei QNAPSysteme mit einer identischen Konfiguration zu versehen. Hierfür rät der Anbieter dazu, zunächst baugleiche Geräte mit identischer Plattenkonfiguration zu kaufen und eines davon als Mustersystem zu konfigurieren. Mittels der in QTS vorhandenen Restore-Funktionalität lässt sich von der Konfiguration des Geräts im Anschluss ein Backup anlegen. Das importieren Sie im zweiten Schritt dann auf das andere QNAP-Gerät. Wirklich schön ist das aber nicht. Denn über den Umweg des Exports und des Imports der gesamten Konfiguration des Geräts übernimmt das zweite System beispielsweise auch die IP-Adresse des ersten. Nach dem Import des Backups auf dem zweiten System müssen Sie also Hand anlegen, um lokal keinen Konflikt im Netz zu riskieren.
Sind die Devices identisch aufgesetzt, empfiehlt der Hersteller weitere Maßnahmen. So bietet es sich laut QNAP an, ein zentrales Verzeichnis wie LDAP oder Active Directory für die Benutzerverwaltung zu verwenden, das auf beiden Systemen konfiguriert ist. So ist sichergestellt, dass User-IDs zugreifender Nutzer konsistent über beide Systeme hinweg sind. Dasselbe gilt für die Mitgliedschaft in Gruppen. Ferner schlägt der Anbieter vor, die Volume- und Ordnerkonfiguration zwischen den Instanzen abzugleichen. Das bedeutet dann allerdings nicht, dass deren Inhalte automatisch repliziert oder synchronisiert werden. Dafür müssen Sie eine eigene Funktion nutzen, die "Real-Time Remote Replication" oder kurz RTRR.
Am Ende ist der Admin trotzdem deutlich schlechter gestellt als bei Synology. Denn fällt der aktive Knoten aus, bemerkt der passive Knoten das gar nicht und initiiert entsprechend auch keinen Failover. Das müssen Sie stattdessen selbst erledigen. Keine Frage – wenn es hart auf hart kommt, ist das immer noch besser als eine stunden- oder gar tagelange Downtime, falls die Hardware des aktiven Systems kaputtgeht. Für das Konstrukt mit QNAP bedarf es aber eines Admins mit Ahnung von dem, was er tut, um den Failover schnell händisch zu initiieren.
Wer also wirkliche HA-Funktionalität braucht, ist mit Synology besser beraten als mit QNAP. Wer sich für keinen der beiden Ansätze begeistern kann, hat noch eine weitere Option. Denn für Hardware von der Stange existieren etliche fertige NAS-Betriebssysteme wie OpenNAS, XigmaNAS oder FreeNAS. Sie alle basieren im Kern auf BSD, bringen aber ausgefeilte Cluster-Mechanismen mit sich, auch wenn diese zum Teil über die ausgelieferten GUIs nicht erreichbar sind. Stattdessen blüht dem Administrator bei dieser Variante ein Ausflug auf die Kommandozeile. Im Gegenzug bekommt er die sichere Gewissheit, dass ein echter Cluster am Werk ist und ein Failover ohne händisches Eingreifen funktioniert.
Fazit
Die beiden Platzhirsche performen beim Thema Clustering sehr unterschiedlich. Wer ohnehin auf Synology gebucht ist, bekommt in Form von SHA eine gut funktionierende HA-Implementierung, die sich über das ausgelieferte GUI auch noch stringent und schnell konfigurieren lässt. In QNAPs QTS hingegen ist HA eher ein Krückenthema, das viel Handarbeit benötigt. Hier kann sich ein Umstieg auf Synology oder auf ein NAS Marke Eigenbau lohnen.
(ln)
Link-Codes