„Ihr macht das so intuitiv und viel zu einfach, das gibt mir Selbstvertrauen. Warum kann nicht alles so einfach sein?“
— Anonymer Kunde
In meinem ersten Beitrag, unsere Diskussion zum Thema Upgrades endete mit einigen Hinweisen, die es im Zusammenhang mit der Replikation zu beachten gilt. Dieses Mal werden wir uns mit einigen Punkten befassen, die im Bereich „Customer Success“ auftauchen, und erörtern, wie man sie am besten angeht.
Fangen wir dort an, wo wir aufgehört haben – bei der Versionsnummerierung. Ab Version 5.0.1 wendet Qumulo bei der Replikation die „Zwei-Quartals-Regel“ an (wie Sie sich vielleicht noch aus dem letzten Monat erinnern: Quartalsversionen sind dadurch gekennzeichnet, dass die dritte Ziffer eine 0 ist). Betrachten wir Version 5.3.0, so umfasst dies die beiden vorangegangenen Quartalsversionen (5.1.0 und 5.2.0) sowie die beiden nachfolgenden Quartalsversionen (6.0.0 und 6.1.0). Es ist wichtig zu beachten, dass eine Punktversion oberhalb von .0 nicht in diesen Bereich fällt. Nehmen wir unser vorheriges Beispiel 5.3.0: 6.1.0 ist die harte Grenze, da dies die vierteljährliche Version ist. 6.1.1 ist, was die Replikation betrifft, eine ganz andere Liga, und 5.3.0 wird sich rundweg weigern, mit dieser Version zu kommunizieren.
Sie fragen sich vielleicht: Welche Möglichkeiten habe ich, wenn wir versehentlich außerhalb des Zeitfensters von zwei Quartalen ein Upgrade durchführen? In diesem Fall müssten Sie die Quellseite der Beziehung aktualisieren. In diesem Zusammenhang wird das Qumulo Customer Success-Team oft gefragt: „Sollte ich die Replikation während des Upgrades unterbrechen?“ Nein, das sollten Sie nicht. Die Replikations-Engine ist sehr clever und setzt die Replikation fort, sobald das Upgrade abgeschlossen ist. Wenn es um Upgrades und Replikationen geht, gilt: Einfach machen!
Eine weitere Frage, die im Bereich Customer Success immer wieder auftaucht, betrifft Änderungen an der Quelle – beispielsweise die Umbenennung eines Quellverzeichnisses. Nehmen wir zum Beispiel an, wir replizieren „/financials/current_fiscal“ und möchten es in „/financials/FY2023“ umbenennen. Müssen wir dann alle Daten erneut replizieren? Ganz und gar nicht. Da wir den Namen geändert haben, wird zwar eine Überprüfung ausgelöst, es findet jedoch keine erneute Replikation statt. Stattdessen würdet ihr in den Replikationsprotokollen beobachten, wie der Wert „Skipped“ anwächst, während die „kleine, aber leistungsstarke Replikations-Engine“ die Daten durchläuft und sicherstellt, dass nichts mehr auf die Übertragung wartet.
Was passiert, wenn Sie eine Verzeichnisstruktur wie `/zoo/animals/mammals/capybara` haben, aber eine spezielle Richtlinie nur für „mammals“ einrichten möchten? Wird die Verzeichnisstruktur automatisch für Sie kopiert, oder muss ich diese selbst anlegen? Unser Entwicklungsteam hat an diesem Tag an Sie gedacht – die Qumulo-Replikations-Engine erstellt die vorgängigen Verzeichnisse für Sie und baut die Verzeichnisstruktur als „/zoo/animals/mammals/“ am Zielort nach, sobald diese Richtlinie in Kraft tritt.
Lassen Sie uns einen Moment innehalten und über Richtlinien sprechen. Brauche ich Snapshot-Richtlinien? Überhaupt nicht. Sie können eine einfache kontinuierliche Replikationsbeziehung einrichten, ohne dass dafür Richtlinien erforderlich sind. Ob es sinnvoll ist, dies ohne Richtlinie zu tun, ist eine geschäftliche Entscheidung. In der Regel empfehlen wir jedoch Richtlinien – vor allem für erweiterte Konfigurationszwecke.
Mit Richtlinien können Sie die Replikation als „Richtlinie + kontinuierlich“ einrichten. Dadurch haben Sie die Möglichkeit, zu bestimmten Zeitpunkten Snapshots auf der Quellseite zu erstellen und zu übertragen sowie eine Ablaufzeit für Snapshots auf der Zielseite festzulegen. Ohne Richtlinie sind Sie auf einen einzigen Replikations-Snapshot auf der Zielseite beschränkt (es sei denn, Sie aktivieren dort die Snapshot-Funktion). Wenn Sie die Anzahl der Replikationen zu Ihrem Disaster-Recovery-Standort erhöhen, sollten Sie die Implementierung von Richtlinien in Betracht ziehen, sofern Sie dies nicht bereits getan haben.
Betrachten wir abschließend lokale Benutzer und die Replikation. Wenn Sie auf dem Quellcluster lokale Benutzer definiert haben, müssen Sie dieselben lokalen Benutzer dann auch auf dem Zielcluster definieren? Als bewährte Vorgehensweise sollten Sie dies tun. Der Cluster greift auf die NFS-UID zurück, wenn für Dateien lokale Berechtigungen festgelegt wurden. Werden diese repliziert und ist die UID auf der Zielseite nicht festgelegt, weiß der Cluster nicht, wem die Berechtigungen zugewiesen werden sollen, bricht die Replikation ab und gibt eine Fehlermeldung aus, die in etwa wie folgt lautet:
„Letzter Versuch: /data/ kann nicht repliziert werden, da es einem lokalen Benutzer gehört. Entfernen Sie entweder alle lokalen Benutzer und Gruppen aus der Datei oder stellen Sie sicher, dass allen lokalen Benutzern und Gruppen NFS-IDs zugeordnet sind, und bearbeiten Sie die Zuordnung, um die Zuordnung von lokalen IDs zu NFS-IDs zu aktivieren.“
Außerdem müssen Sie die lokalen Benutzer auf dem Quellserver überprüfen (Cluster -> Lokale Benutzer und Gruppen) und diese auf dem Zielserver neu anlegen. In der Verknüpfung müssen Sie das Kontrollkästchen „Lokale Benutzer-/Gruppen-IDs den zugehörigen NFS-IDs zuordnen“ aktivieren. Die Replikations-Engine führt nach 60 Sekunden automatisch einen erneuten Versuch durch. Solange Sie alles richtig gemacht haben, wird die Replikation daher wieder aufgenommen und läuft reibungslos weiter.
Hoffentlich konnten wir damit einige Unklarheiten zum Thema Replikation und deren Zusammenhang mit Ihrem Qumulo-Cluster ausräumen. Wie immer gilt: Wenn Sie Fragen haben, zögern Sie bitte nicht, sich in Ihrem Slack-Kanal an uns zu wenden – Ihr freundlicher Qumulo Customer Success Engineer hilft Ihnen gerne weiter. Schauen Sie bald wieder vorbei, dann tauchen wir gemeinsam in die wunderbare Welt der Snapshots ein.
Bis zum nächsten Mal!