Anforderungen für die Container-Migration für Nodes
Änderungen vorschlagen
PDFs
Mit der Funktion zur Node-Migration können Sie einen Node manuell von einem Host auf einen anderen verschieben. Normalerweise befinden sich beide Hosts im selben physischen Datacenter.
Dank der Node-Migration können Sie physische Host-Wartungsarbeiten durchführen, ohne Grid-Vorgänge zu unterbrechen. Sie verschieben einfach alle StorageGRID Nodes nacheinander auf einen anderen Host, bevor Sie den physischen Host offline schalten. Die Migration von Nodes erfordert nur kurze Ausfallzeiten für jeden Node. Der Betrieb und die Verfügbarkeit von Grid-Services sollte dabei nicht beeinträchtigt werden.
Wenn Sie die StorageGRID-Node-Migrationsfunktion nutzen möchten, muss Ihre Implementierung zusätzliche Anforderungen erfüllen:
-
Konsistente Netzwerkschnittstellennnamen über Hosts in einem einzigen physischen Datacenter hinweg
-
Shared Storage für StorageGRID Metadaten und Objekt-Repository-Volumes, auf die alle Hosts in einem einzigen physischen Datacenter zugreifen können So können Sie beispielsweise ein NetApp E-Series Storage-Array verwenden.
Wenn Sie virtuelle Hosts verwenden und die zugrunde liegende Hypervisor-Ebene die VM-Migration unterstützt, ist diese Funktion anstelle der Node-Migrationsfunktion von StorageGRID wahrscheinlich sinnvoll. In diesem Fall können Sie diese zusätzlichen Anforderungen ignorieren.
Bevor Sie eine Migration oder eine Hypervisor-Wartung durchführen, müssen Sie die Nodes ordnungsgemäß herunterfahren. Siehe Anweisungen für Herunterfahren eines Grid-Node.
VMware Live Migration wird nicht unterstützt
OpenStack Live Migration und VMware Live vMotion sorgen dafür, dass die Virtual Machine-Uhr springen und für Grid-Nodes jeglicher Art nicht unterstützt wird. Obwohl selten, falsche Uhrzeiten können zum Verlust von Daten oder Konfigurations-Updates führen.
Cold-Migration wird unterstützt. Bei der „Cold“-Migration sollten Sie die StorageGRID Nodes herunterfahren, bevor Sie sie zwischen Hosts migrieren. Siehe Anweisungen für Herunterfahren eines Grid-Node.
Konsistente Namen von Netzwerkschnittstellen
Um einen Node von einem Host zum anderen zu verschieben, muss der StorageGRID-Hostdienst die Gewissheit haben, dass die externe Netzwerkverbindung, die der Node an seinem aktuellen Standort besitzt, an dem neuen Standort dupliziert werden kann. Dies schafft Vertrauen durch die Verwendung konsistenter Netzwerk-Interface-Namen in den Hosts.
Angenommen, beispielsweise, dass StorageGRID NodeA, der auf Host1 ausgeführt wird, mit den folgenden Schnittstellenzuordnungen konfiguriert wurde:
Die linke Seite der Pfeile entspricht den traditionellen Schnittstellen, die aus einem StorageGRID-Container betrachtet werden (das sind die Grid-, Administrator- und Client-Netzwerk-Schnittstellen). Die rechte Seite der Pfeile entspricht den tatsächlichen Host-Schnittstellen, die diese Netzwerke bereitstellen. Dabei handelt es sich um drei VLAN-Schnittstellen, die derselben physischen Interface-Verbindung untergeordnet sind.
Nehmen Sie an, Sie möchten NodeA zu Host2 migrieren. Wenn Host2 auch Schnittstellen mit den Namen bond0.1001, bond0.1002 und bond0.1003 besitzt, ermöglicht das System die Verschiebung, vorausgesetzt, dass die „Gefällt mir“-Schnittstellen auf Host2 die gleiche Konnektivität wie auf Host1 bereitstellen. Wenn Host2 keine Schnittstellen mit demselben Namen hat, ist die Verschiebung nicht zulässig.
Es gibt viele Möglichkeiten, eine konsistente Netzwerkschnittstelle über mehrere Hosts hinweg zu benennen; siehe Konfigurieren Sie das Hostnetzwerk Für einige Beispiele.
Shared Storage
Für schnelle Node-Migrationen mit geringem Overhead werden Node-Daten durch die StorageGRID Node-Migrationsfunktion nicht physisch verschoben. Stattdessen werden die Node-Migration als Export- und Importpaar durchgeführt:
-
Während des Vorgangs „
Node Export“ wird eine kleine Menge von persistenten Zustandsdaten aus dem Node-Container extrahiert, der auf Hosta ausgeführt wird und auf dem Systemdatenvolume dieses Node zwischengespeichert wird. Anschließend wird der Knoten-Container auf Hosta deaktiviert. -
Während des Vorgangs „
Node Import“ wird der Node-Container auf HostB, der die gleiche Netzwerkschnittstelle und die Blockspeicherzuordnungen verwendet, die auf Hosta wirksam waren, instanziiert. Anschließend werden die im Cache gespeicherten Persistent State-Daten in die neue Instanz eingefügt.
In Anbetracht dieses Betriebsmodus müssen alle Systemdaten und Objekt-Storage-Volumes des Node sowohl von Hosta als auch von HostB aus zugänglich sein, damit die Migration erlaubt und ausgeführt werden kann. Außerdem müssen sie auf dem Knoten mit Namen abgebildet worden sein, die garantiert auf die gleichen LUNs auf Hosta und HostB verweisen.
Das folgende Beispiel zeigt eine Lösung für die Zuordnung von Blockgeräten für einen StorageGRID-Speicherknoten, bei dem auf den Hosts DM-Multipathing verwendet wird und in das Alias-Feld verwendet wurde /etc/multipath.conf Um konsistente, freundliche Blockgerätnamen zu liefern, die auf allen Hosts verfügbar sind.
