Novus Storage-Systemumgebung und -verarbeitung
Änderungen vorschlagen
PDFs
Es gibt einige wichtige Aspekte der Novus-Umgebung und ihrer Verarbeitung, die Sie verstehen sollten.
Interne Kommunikation zwischen Novus Data Director und ONTAP data server
Die Novus Data Directors kommunizieren mit den ONTAP Datenservern, um Dateizugriff und Verwaltung zu unterstützen. Meist geht dies vom NDD aus und nicht von den ONTAP Servern.
ONTAP Datenserver-Erkennung
Die Novus Data Directors müssen identifizieren, welche Datenserver verfügbar sind. ONTAP initiiert keine Kommunikation mit dem Novus Data Director. Ein Operator oder ein Tool registriert jeden Datenserver über die mds.conf Konfigurationsdatei, die beim Start verwendet wird; Datenserver können auch mit dem Befehl mds-admin ds add manuell hinzugefügt werden. Jeder Datenserver erscheint als Zeile im verteilten Metadatenspeicher, einschließlich Host, Export, Ports, Status und Kapazität.
Verfügbarkeit des ONTAP Datenservers
Zur Ermittlung der Verfügbarkeit jedes ONTAP Datenservers kommen verschiedene Verfahren zum Einsatz.
- Heartbeat
-
Der MDS sendet über TCP einen NFSv3-NULL-RPC-Aufruf an jeden Online-Datenserver. Standardmäßig geschieht dies alle 5 Sekunden mittels einer Heartbeat-Nachricht.
- Offline gehen
-
Nach einer bestimmten Anzahl aufeinanderfolgender Ausfälle wird der Datenserver als offline markiert. Der MDS legt keine neuen Dateien mehr darauf ab und fordert Clients auf, die Layouts zurückzugeben, die auf ihn verweisen.
- Rückkehr
-
Nach genügend erfolgreichen Prüfungen in Folge kehrt es in den Online-Status zurück. Eine Wartezeit verhindert, dass es ständig hin- und herwechselt.
- Client-Fehler zählen nicht
-
Wenn ein Client einen Fehler meldet, wird dieser lediglich protokolliert. Der Systemstatus des ONTAP Datenservers wird ausschließlich durch die Probes bestimmt.
- ONTAP Failover ist unsichtbar
-
Wenn ein ONTAP HA pair ein Takeover ausführt, bemerkt das MDS dies nur anhand von Probe-Timeouts.
Dateninhalte des ONTAP Datenservers
Das NDD fragt ONTAP nicht, was es speichert. Es weiß es bereits, da es jede Backing-Datei selbst erstellt:
-
Beim Erstellen einer Datei wählt der MDS die Datenserver aus, erstellt die Backing-Dateien auf ihnen und speichert das Ergebnis in der Stripe Map im verteilten Metadatenspeicher. Die Stripe Map zeichnet auf, welcher Datenserver und welches NFS-Dateihandle jeden Stripe und jede Spiegelung enthalten.
-
Die Sicherungsdateien auf ONTAP haben ein bestimmtes Namensformat im NDD.
-
Die Kapazität ist der einzige Betriebswert, den das NDD mit statvfs() bei jedem gemounteten Export von ONTAP ausliest.
-
Die Dateigröße wird nicht anhand von ONTAP überprüft. Sie wird aus dem Layout-Commit des Clients ermittelt.
Hochverfügbarkeit und Ausfallsicherheit für den NDD Cluster
Die von den Novus Data Directors verankerte Metadatenebene gewährleistet im System eine hohe Verfügbarkeit und Ausfallsicherheit.
Clusterdesign
Novus nutzt einen Multi-Host-Cluster, um eine hohe Verfügbarkeit und Fehlertoleranz für die NDD Services sicherzustellen.
- Drei Hosts mit drei Ausfalldomänen
-
Ein minimaler NDD-Cluster besteht aus drei physischen Hosts oder virtuellen Maschinen (VMs), die auf separaten Servern bereitgestellt sind. Auf jedem Host läuft ein MDS-Prozess und ein Metadatenspeicherknoten. Der Cluster ist so konzipiert, dass er den Ausfall eines Hosts übersteht.
- Alle Replikate dienen
-
Jede MDS-Replik bedient Clients gleichzeitig, ohne dass eine davon als Standby vorgesehen ist. Alle fehlerfreien Replikate geben dieselbe VIP über BGP bekannt. BFD (fast link-failure detection) ist erforderlich, da die BGP-eigenen Timer allein kein vollständig akzeptabler Failover-Mechanismus sind. Eine Replik gibt die VIP nur dann bekannt, wenn ihr NFS-Service, ihr Gateway und ihre Metadatenspeicherverbindung vollständig für die Client-Verarbeitung bereit sind.
- Metadatenreplikation
-
Der verteilte Metadatenspeicher verwaltet drei synchrone Kopien. Ein Arbitrator verhindert ein Split-Brain-Szenario, indem er sich für Nichtverfügbarkeit entscheidet, statt zuzulassen, dass beide Seiten schreiben.
- Neustarts sind sicher
-
MDS-Prozesse speichern keinen eigenen Zustand; der verteilte Metadatenspeicher enthält die maßgeblichen Metadaten.
Einschränkungen und Vorsichtsmaßnahmen
Außerdem sollten Sie sich der folgenden Einschränkungen und Vorsichtsmaßnahmen bewusst sein:
-
Für die Eigentümerschaft von Unterbäumen erfolgt kein automatisches Failover. Der Namespace kann in Unterbäume aufgeteilt werden, von denen jeder einem MDS gehört. Fällt ein Eigentümer aus, hängt sein Unterbaum, bis der Eigentümer zurückkehrt, selbst wenn der VIP bereits verschoben wurde.
-
Ein Hostausfall betrifft alle Mandanten auf diesem Host, da jeder Mandant über eine Replik pro Host verfügt.
-
Clients müssen die VIP und nicht eine Host-IP einbinden. Andernfalls kann der Client kein Failover durchführen.
-
Hard Mounts können während der Wiederherstellung blockieren. Eine blockierte Mount-Verbindung bedeutet nicht, dass Daten verloren gegangen sind.
-
Wartungsarbeiten erfolgen immer nur an jeweils einer Replik. Zunächst wird die Replik aus der VIP entfernt und entlastet.