„Ihr macht es so intuitiv und zu einfach, es gibt mir Selbstvertrauen. Warum kann nicht alles so einfach sein?“
— Anonymer Kunde
Bei meinem XNUMX Post, endete unsere Diskussion über Upgrades mit einigen Vorbehalten, die es bei der Replikation zu beachten gilt. Dieses Mal werden wir uns mit einigen Dingen befassen, die für den Kundenerfolg von Bedeutung sind, und wie wir sie am besten angehen können.
Beginnen wir dort, wo wir aufgehört haben – der Versionierung. Ab Version 5.0.1 erzwingt Qumulo bei der Replikation eine zweivierteljährliche Regel (wenn Sie sich an den letzten Monat erinnern, werden vierteljährliche Veröffentlichungen dadurch gekennzeichnet, dass die dritte Ziffer eine 0 ist). Wenn wir uns Version 5.3.0 ansehen, würde das auf zwei Quartale davor (5.1.0 und 5.2.0) und zwei Quartale danach (6.0.0 und 6.1.0) hinweisen. Es ist wichtig zu beachten, dass eine Punktfreigabe über .0 nicht innerhalb des Bereichs liegt. In unserem vorherigen Beispiel von 5.3.0 ist 6.1.0 das feste Limit, da es sich um das Quartal handelt. 6.1.1 ist, was die Replikation betrifft, ein völlig neues Stadion und 5.3.0 wird sich entschieden weigern, mit ihm zu sprechen.
Sie fragen sich vielleicht: Welche Möglichkeiten habe ich, wenn wir versehentlich ein Upgrade außerhalb des Zweiviertelfensters durchführen? In diesem Fall müssten Sie die Quellseite der Beziehung aktualisieren. In diesem Sinne wird das Qumulo Customer Success-Team oft gefragt: „Soll ich die Replikation während des Upgrades anhalten?“ Nein, Sir, das sollten Sie nicht. Die Replikations-Engine ist ein intelligentes Cookie und wird nach Abschluss des Upgrades wieder aktiviert. Wenn es um Upgrades und Replikationen geht, bleibt uns nichts anderes übrig, als es zu tun.
Eine weitere Frage, die im Bereich Customer Success aufkommt, bezieht sich auf Änderungen an der Quelle – beispielsweise die Umbenennung eines Quellverzeichnisses. Angenommen, wir replizieren „/financials/current_fiscal“ und möchten es in „/financials/FY2023“ umbenennen. Werden wir am Ende alle Daten erneut replizieren? Großes Negativ da. Da wir den Namen geändert haben, wird eine Überprüfung ausgelöst, es wird jedoch nichts erneut repliziert. Stattdessen würden Sie in den Replikationsprotokollen sehen, dass der Wert „Übersprungen“ größer wird, da die „kleine Replikations-Engine“, die die Daten durchläuft und sicherstellt, dass nichts auf die Übertragung wartet.
Was passiert, wenn Sie die Verzeichnisstruktur „/zoo/animals/mammals/capybara“ haben, aber nur eine spezielle Richtlinie für „Säugetiere“ einrichten möchten? Wird die Verzeichnisstruktur für Sie kopiert oder muss ich diese erstellen? Unser Entwicklungsteam hat an diesem Tag nach Ihnen Ausschau gehalten – die Qumulo-Replikations-Engine erstellt die vorherigen Verzeichnisse für Sie und erstellt den Baum als „/zoo/animals/mammals/“ am Ziel neu, sobald diese Richtlinie in Kraft tritt.
Lassen Sie uns einen Moment innehalten und die Richtlinien besprechen. Benötige ich Snapshot-Richtlinien? Gar nicht. Sie können eine kontinuierliche Vanilla-Replikationsbeziehung einrichten, ohne dass Richtlinien erforderlich sind. Ob es sinnvoll ist, auf eine Police zu verzichten, ist eine geschäftliche Entscheidung. In der Regel empfehlen wir jedoch Richtlinien – meist für erweiterte Konfigurationszwecke.
Mit Richtlinien können Sie die Replikation als „Richtlinie+kontinuierlich“ einrichten. Dies gibt Ihnen die Möglichkeit, zu bestimmten Zeiten Snapshots auf der Quelle zu erstellen und zu übertragen sowie einen Snapshot-Ablauf auf der Zielseite festzulegen. Ohne Richtlinie sind Sie auf den einzelnen Replikations-Snapshot auf der Zielseite beschränkt (es sei denn, Sie aktivieren dort Snapshots). Wenn Sie die Anzahl der Replikationen auf Ihrem Disaster-Recovery-Standort erhöhen, möchten Sie wahrscheinlich die Implementierung von Richtlinien prüfen, sofern Sie dies noch nicht getan haben.
Betrachten wir abschließend lokale Benutzer und die Replikation. Wenn Sie lokale Benutzer auf dem Quellcluster definiert haben, müssen Sie dann dieselben lokalen Benutzer auf dem Ziel definieren? Als Best Practice sollten Sie dies tun. Der Cluster verweist auf die NFS-UID, wenn lokale Berechtigungen für Dateien festgelegt wurden. Wenn beim Replizieren dieser Daten die UID nicht auf der Zielseite festgelegt ist, weiß der Cluster nicht, wer die Berechtigungen erhalten soll, stoppt die Replikation und gibt einen Fehler wie folgt aus
„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 alle lokalen Benutzer und Gruppen über zugeordnete NFS-IDs verfügen, und bearbeiten Sie die Beziehung, um die Zuordnung lokaler IDs zu NFS-IDs zu ermöglichen.“
Sie müssten auch die lokalen Benutzer auf der Quelle überprüfen (Cluster -> Lokale Benutzer und Gruppen) und diese auf dem Ziel neu erstellen. In der Beziehung müssen Sie das Kontrollkästchen „Lokale Benutzer-/Gruppen-IDs zugeordneten NFS-IDs zuordnen“ bearbeiten. Die Replikations-Engine wird nach 60 Sekunden automatisch einen neuen Versuch starten. Solange Sie also alles richtig gemacht haben, wird die Replikation wieder aufgenommen und läuft weiter.
Im Idealfall hat dies einige Verwirrung über die Replikation und deren Zusammenhang mit Ihrem Qumulo-Cluster beseitigt. Wenn Sie Fragen haben, können Sie sich wie immer jederzeit über Ihren Slack-Kanal an uns wenden. Ihr freundlicher Qumulo Customer Success Engineer hilft Ihnen gerne weiter. Kommen Sie bald wieder vorbei und wir tauchen ein in die wunderbare Welt der Schnappschüsse.
Bis zum nächsten Mal!
