Oracle Cloud Infrastructure - Dokumentation

Live-, Neustart- und manuelle Migration: Compute-Instanzen auf neuen Host verschieben

Dieses Thema enthält Informationen zu Wartungsaktionen, die das Verschieben von VM- und Bare-Metal-Instanzen während der Wartungsereignisse für die Infrastruktur umfassen. Verfügbare Aktionen:

Wichtig

Informationen dazu, wann eine virtuelle Maschine migriert werden muss, finden Sie unter Infrastrukturwartung.
Tipp

Migration von dedizierten VM-Hosts: Informationen zum Umspeichern dedizierter VM-Hosts während Infrastrukturwartungsereignissen finden Sie unter Wartungsneustartmigration für dedizierte VM-Hosts verwalten.
Hinweis

Oracle Platform Services: Für Instanzen, die mit Oracle Platform Services erstellt wurden und sich im Compartment ManagedCompartmentForPaaS befinden, müssen Sie die Schnittstelle für den jeweiligen Platform Service verwenden, um die Instanzen neu zu starten.

Livemigration

Die fehlerhafte Instanz wird auf einen fehlerfreien Host kopiert, während die vorhandene Instanz noch ausgeführt wird. Es gibt nur eine geringfügige Unterbrechung der ausgeführten Instanzen.

Während eines Infrastrukturwartungsereignisses migriert Oracle Cloud Infrastructure unterstützte VM-Instanzen per Livemigration vom physischen VM-Host, der gewartet werden muss, zu einem fehlerfreien VM-Host mit nur einer geringfügigen Unterbrechung der ausgeführten Instanzen.

Wenn eine Instanz nicht per Livemigration migriert werden kann, plant Oracle Cloud Infrastructure ein Fälligkeitsdatum für die Neustartmigration innerhalb von 14 bis 16 Tagen und sendet Ihnen eine Benachrichtigung. Wenn Sie die Instanz nicht proaktiv vor dem Fälligkeitsdatum neu starten, wird die Instanz für Sie per Neustart migriert.

Standardmäßig migriert Oracle Cloud Infrastructure die Instanz per Livemigration, ohne Benachrichtigungen über die bevorstehende Wartung zu senden. Bei Beginn und Ende einer Livemigration wird ein Infrastrukturwartungsereignis ausgegeben. Sie können die Automatisierung verwenden, um Infrastrukturwartungsereignisse zu verfolgen.

Unterstützung für Live-Migration

Wenn Sie eine Instanz erstellen, wählen Sie Einstellungen aus, die mit der Livemigration kompatibel sind. Wenn eine vorhandene Instanz unterstützt wird, können Sie die Livemigration aktivieren, indem Sie die Instanz so bearbeiten, dass sie Einstellungen verwendet, die mit der Livemigration kompatibel sind. Einige Einstellungen, die mit der Livemigration nicht kompatibel sind, können nach dem Erstellen einer Instanz nicht mehr bearbeitet werden.

In der folgenden Tabelle sind die Kriterien aufgeführt, die eine Instanz mit der Livemigration kompatibel machen. Alle Kriterien müssen erfüllt sein, damit eine Instanz die Livemigration unterstützt.

Kategorie Kriterien zur Unterstützung der Livemigration Kann die Einstellung nach dem Erstellen der Instanz bearbeitet werden?
Realm Mandant befindet sich in der kommerziellen Realm. Nein.
Ausprägung

Die Instanz verwendet eine der folgenden Ausprägungen:

  • VM.Standard1-Reihe
  • VM.Standard.A1.Flex
  • VM.Standard.B1-Reihe
  • VM.Standard2-Reihe
  • VM.Standard3.Flex
  • VM.Standard.E2-Reihe
  • VM.Standard.E2.1.Micro
  • VM.Standard.E3.Flex
  • VM.Standard.E4.Flex
  • VM.Standard.E5. Flex
  • VM.Optimized3.Flex

Andere VM-Ausprägungen, Bare-Metal-Instanzen und Instanzen auf dedizierten Hosts für virtuelle Maschinen unterstützen keine Livemigration.

Ja, für einige Formen. Ändern Sie die Ausprägung der Instanz in eine unterstützte Ausprägung.

Alternativ können Sie die Instanz beenden (löschen), aber nicht das zugehörige Boot-Volume löschen. Verwenden Sie dann das Boot-Volume, um eine neue Instanz zu erstellen und eine Ausprägung zu verwenden, die eine Livemigration unterstützt.
Image

Instanzen, die Linux- oder Windows-Plattformimages verwenden, unterstützen die Livemigration.

Bei Instanzen, die benutzerdefinierte Images oder Oracle Cloud Infrastructure Marketplace verwenden, versucht Oracle Cloud Infrastructure, die Instanz per Livemigration zu migrieren.

 Nein.
Starttyp für Networking Instanz verwendet paravirtualisiertes Networking. Ja, bearbeiten Sie den Networkingstarttyp.
Abgeschirmte Instanzen Nicht unterstützt. Nein.
Windows Defender Credential Guard ist aktiviert Nicht unterstützt. Nein.
Virtuelle Netzwerkkarten (VNICs) Die maximale Gesamtanzahl der angehängten VNICs beträgt sechs. Ja, trennen und löschen Sie sekundäre VNICs, bis insgesamt sechs oder weniger VNICs angehängt sind.

So ermitteln Sie, ob eine Instanz die Livemigration unterstützt:

  1. Öffnen Sie das Navigationsmenü, und klicken Sie auf Compute. Klicken Sie unter Compute auf Instanzen.
  2. Klicken Sie auf die gewünschte Instanz.
  3. Prüfen Sie das Feld Livemigration für die Instanz. Wenn im Feld Inkompatibilitäten anzeigen angezeigt wird, unterstützt die Instanz keine Livemigration.
  4. (Optional) Um zu sehen, welche Einstellungen nicht mit der Livemigration kompatibel sind, klicken Sie auf Inkompatibilitäten anzeigen.

Neustartmigration

Die Instanz wird gestoppt, zu einem fehlerfreien Host migriert und neu gestartet. Während der Migration kommt es zu einer kurzen Ausfallzeit. Sie können steuern, wann die Ausfallzeit eintritt, indem Sie die Instanz proaktiv vor dem Fälligkeitsdatum der Wartung per Neustartmigration migrieren.

Die Neustartmigration wird für VM-Instanzen mit Standard-, GPU- und dicht besiedelten I/O-Ausprägungen sowie für Bare-Metal-Instanzen mit Standardformen unterstützt. Die Standardwartungsaktion hängt von der Ausprägung der Instanz ab.

  • VM-Instanzen:

    • Standardausprägungen: innerhalb von 24 Stunden nach dem Fälligkeitsdatum der Wartung wird die VM-Instanz gestoppt, zu einem fehlerfreien Host migriert und neu gestartet. Während der Migration kommt es zu einer kurzen Ausfallzeit.

      Sie können steuern, wann die Ausfallzeit eintritt, indem Sie die Instanz proaktiv vor dem Fälligkeitsdatum der Wartung per Neustartmigration migrieren.

    • DenseIO-Ausprägungen: Am Fälligkeitsdatum der Wartung wird die VM-Instanz gestoppt, neu erstellt und neu gestartet. Während des Wartungsprozesses kommt es zu einer Ausfallzeit von mehreren Stunden.

      Wenn Sie die Ausfallzeit minimieren möchten und die lokal angehängte NVMe-basierte SSD löschen können, können Sie die Instanz vor der geplanten Wartung proaktiv neu starten. Die Instanz wird per Neustartmigration auf einen fehlerfreien Host migriert, und die SSD wird endgültig gelöscht. Während der Migration kommt es zu einer kurzen Ausfallzeit.

  • Bare-Metal-Instanzen:

    • Standardausprägungen: Innerhalb von 24 Stunden nach dem Fälligkeitsdatum der Wartung wird die Bare-Metal-Instanz gestoppt, zu einem fehlerfreien Host migriert und neu gestartet. Während der Migration kommt es zu einer kurzen Ausfallzeit.

      Sie können steuern, wann die Ausfallzeit eintritt, indem Sie die Instanz proaktiv vor dem Fälligkeitsdatum der Wartung per Neustartmigration migrieren.

      Wenn die Neustartmigration nicht erfolgreich verläuft, sendet Oracle Cloud Infrastructure eine Benachrichtigung. Sie müssen die Instanz manuell zu einem fehlerfreien Host migrieren.

Wenn die Instanz neu gestartet wurde, wird der Wert im Feld Wartungsneustart gelöscht. Diese Änderung gibt an, dass die Instanz erfolgreich verschoben wurde.

Wichtig

Verwenden Sie die Konsole, die CLI oder das SDK, um eine VM-Instanz per Neustartmigration zu migrieren. Beim Neustart der Instanz vom Betriebssystem wird die Instanz nicht auf neue Hardware migriert.

Nach einer Migration wird die Instanz standardmäßig in denselben Lebenszyklusstatus wiederhergestellt wie vor dem Wartungsereignis. Wenn Sie über einen alternativen Prozess verfügen, um die Instanz nach einer Neustartmigration wiederherzustellen, können Sie festlegen, dass die Instanz gestoppt bleibt, nachdem sie auf fehlerfreie Hardware migriert wurde. Weitere Informationen zur Konfiguration von Migrationsoptionen einschließlich des Lebenszyklusstatus von Instanzen nach einer Migration finden Sie unter Instanzverfügbarkeit während Wartungsereignissen festlegen.

Frist für die Neustartmigration verlängern

Sie können das Wartungsfälligkeitsdatum für Instanzen verlängern, die für die Neustartmigration geplant sind. Eine Fristverlängerung wird für VM- und Bare-Metal-Instanzen mit Standardausprägungen unterstützt. Oracle Cloud Infrastructure bestimmt den letztmöglichen Zeitpunkt, bis zu dem das Fälligkeitsdatum verlängert werden kann.

Konsole verwenden: So verlängern Sie das Fälligkeitsdatum der Wartung für eine Instanz
  1. Öffnen Sie das Navigationsmenü, und klicken Sie auf Compute. Klicken Sie unter Compute auf Instanzen.

  2. Klicken Sie auf die gewünschte Instanz, und prüfen Sie das Feld Wartungsneustart für die Instanz. Wenn die Schaltfläche Frist verlängern aktiv ist, kann das Fälligkeitsdatum der Wartung verlängert werden.

  3. Klicken Sie auf Frist verlängern.
  4. Wählen Sie im Feld Neuer Termin ein neues Datum und eine neue Uhrzeit aus.

  5. Klicken Sie auf Änderungen speichern.

    Das Fälligkeitsdatum der Wartung wird verlängert. Binnen 24 Stunden nach dem Fälligkeitsdatum der Wartung wird die Instanz gestoppt, auf einen fehlerfreien Host migriert und neu gestartet. Während der Migration kommt es zu einer kurzen Ausfallzeit.

API verwenden: So verlängern Sie das Fälligkeitsdatum der Wartung für eine Instanz
  1. Prüfen Sie mit dem GetInstanceMaintenanceReboot-Vorgang, bis wann das Fälligkeitsdatum maximal verlängert werden kann.

  2. Verlängern Sie das Fälligkeitsdatum für die Wartung wie folgt:

    • VMs und Bare-Metal-Instanzen: Verwenden Sie den Vorgang InstanceAction, und übergeben Sie den Wert REBOOTMIGRATE als auszuführende Aktion. Geben Sie im Attribut timeScheduled das aktualisierte Fälligkeitsdatum an.
    • VMs: Verwenden Sie den Vorgang UpdateInstance, und übergeben Sie das aktualisierte Fälligkeitsdatum im Attribut timeMaintenanceRebootDue.

    Das Fälligkeitsdatum der Wartung wird verlängert. Binnen 24 Stunden nach dem Fälligkeitsdatum der Wartung wird die Instanz gestoppt, auf einen fehlerfreien Host migriert und neu gestartet. Während der Migration kommt es zu einer kurzen Ausfallzeit.

Voraussetzungen für die Neustartmigration

Bereiten Sie die Instanz für die Neustartmigration vor:

  • Stellen Sie sicher, dass alle in /etc/fstab definierten Block-Volumes die empfohlenen Optionen verwenden.
  • Stellen Sie sicher, dass alle File Storage Service-(NFS-)Mounts die Option nofail verwenden.
  • Wenn Sie mit dem von Oracle bereitgestellten Skript sekundäre VNICs konfigurieren, stellen Sie sicher, dass das Skript beim Hochfahren automatisch ausgeführt wird.

  • Wenn die Instanz eine DenseIO-Ausprägung verwendet, sichern Sie die lokal angehängte NVMe-basierte SSD:

    1. Erstellen und ordnen Sie ein oder mehrere Block-Volumes der Instanz zu.
    2. Kopieren Sie die Daten von den NVMe-Geräten auf die Block-Volumes.

VM-Instanzen mit Neustartmigration verschieben

Wenn alle Voraussetzungen erfüllt sind:

  1. Stoppen Sie alle ausgeführten Anwendungen.

  2. Verwenden Sie die Konsole, die CLI oder das SDK, um die Instanz neu zu starten. Die Neustartmigration wird nicht ausgeführt, wenn Sie die Instanz aus dem Betriebssystem neu starten.

    Wenn die Instanz eine DenseIO-Ausprägung verwendet:

    • Mit der Konsole: Wählen Sie im Dialogfeld Instanz neu starten die Option Lokale NVMe-basierte SSD löschen und Migration zu einem fehlerfreien Host neu starten aus.
    • CLI oder SDK verwenden: Legen Sie im Vorgang InstanceAction das Attribut allowDenseRebootMigration auf true fest.
    Achtung

    Bei DenseIO-Instanzen wird die auf NVMe basierende SSD endgültig gelöscht. Wir empfehlen, dass Sie ein Backup der SSD erstellen, bevor Sie fortfahren.
  3. Vergewissern Sie sich, dass das Feld Wartungsneustart kein Datum mehr enthält.
  4. Starten und testen Sie alle Anwendungen auf der Instanz.

  5. Wenn Sie bei DenseIO-Instanzen die NVMe-basierte SSD wiederherstellen möchten:

    1. Hängen Sie die Block-Volumes an, mit denen Sie lokale NVMe-Geräte sichern.
    2. Kopieren Sie die Daten in den NVMe-Speicher auf der neuen Instanz.
    3. Trennen und löschen Sie optional die Block-Volumes.

Bare-Metal-Instanzen mit Neustartmigration verschieben

Wenn alle Voraussetzungen erfüllt sind:

  1. Stoppen Sie alle ausgeführten Anwendungen.

  2. Verwenden Sie die Konsole, die CLI oder das SDK, um die Instanz neu zu starten. Die Neustartmigration wird nicht ausgeführt, wenn Sie die Instanz aus dem Betriebssystem neu starten.

    • Mit der Konsole: Wählen Sie im Dialogfeld Instanz neu starten die Option Instanz mit Neustart zu einem fehlerfreien Host migrieren aus.
    • CLI oder SDK verwenden: Übergeben Sie im Vorgang InstanceAction den Wert REBOOTMIGRATE als auszuführende Aktion. Um die Instanz sofort mit Neustart zu migrieren, lassen Sie das Attribut timeScheduled leer.
  3. Stellen Sie nach der Migration sicher, dass das Feld Wartungsneustart kein Datum mehr enthält.
  4. Starten und testen Sie alle Anwendungen auf der Instanz.

Instanzen mit manueller Migration verschieben

Instanzen ohne Datum im Feld Wartungsneustart (in der Konsole, der CLI und den SDKs verfügbar) müssen Sie manuell verschieben. Bei dieser Methode müssen Sie die Instanz löschen (beenden) und eine neue Instanz aus dem beibehaltenen Boot-Volume starten. Instanzen, die zusätzliche VNICs, sekundäre IP-Adressen, angehängte Remoteblock-Volumes oder ein aktiviertes Trusted Platform Module (TPM) aufweisen oder zu einem Backend-Set eines Load Balancers gehören, erfordern zusätzliche Schritte.

Einschränkungen und Warnungen für die manuelle Migration

Beachten Sie die folgenden Einschränkungen und Warnungen für die manuelle Migration:

  • Öffentliche IP-Adressen, die Ihrer Instanz von einem reservierten öffentlichen Pool zugewiesen wurden, werden beibehalten. Alle nicht von einem reservierten öffentlichen IP-Adresspool zugewiesenen IP-Adressen werden geändert. Private IP-Adressen werden nicht geändert.
  • MAC-Adressen, CPU-IDs und andere eindeutige Hardware-IDs werden jedoch während des Verschiebevorgangs geändert. Wenn auf der Instanz ausgeführte Anwendungen diese IDs zur Lizenzierung oder für andere Zwecke verwenden, müssen Sie daher diese Informationen vor dem Verschieben der Instanz notieren.
  • Für abgeschirmte Instanzen gelten zusätzliche Einschränkungen. Siehe Abgeschirmte Instanzen migrieren.

Voraussetzungen für die manuelle Migration

  1. Bevor Sie die Instanz verschieben, dokumentieren Sie alle kritischen Details:

    • Die Region, Availability-Domain und Faultdomain der Instanz.
    • Der Anzeigename der Instanz.
    • Alle privaten IP-Adressen, Namen und Subnetze. Beachten Sie, dass die Instanz mehrere VNICs und jede VNIC mehrere sekundäre IP-Adressen haben kann.
    • Alle privaten DNS-Namen. Die Instanz kann mehrere VNICs haben, und jede VNIC kann mehrere sekundäre IP-Adressen haben. Jede private IP-Adresse kann einen DNS-Namen haben.
    • Alle öffentlichen IP-Adressen, die von einem reservierten öffentlichen Pool zugewiesen werden. Beachten Sie, dass die Instanz mehrere VNICs und jede VNIC mehrere sekundäre private IP-Adressen haben kann. Jede VNIC und sekundäre private IP-Adresse kann eine zugeordnete öffentliche IP-Adresse haben.
    • Alle Block-Volumes, die an die Instanz angehängt sind.
    • Alle Tags in der Instanz oder den angehängten Ressourcen.

  2. Bereiten Sie die Instanz für die manuelle Migration vor:

    • Stellen Sie sicher, dass alle in /etc/fstab definierten Block-Volumes die empfohlenen Optionen verwenden.
    • Stellen Sie sicher, dass alle File Storage Service-(NFS-)Mounts die Option nofail verwenden.
    • Wenn Sie zu sekundären VNICs gehörende Netzwerkschnittstellen (wie in /etc/sysconfig/network-scripts/ifcfg*) mit deren MAC-Adressen statisch definiert haben, werden diese Schnittstellen aufgrund der Änderung der MAC-Adresse nicht gestartet. Entfernen Sie die statische Zuordnung.
    • Wenn Sie mit dem von Oracle bereitgestellten Skript sekundäre VNICs konfigurieren, stellen Sie sicher, dass das Skript beim Hochfahren automatisch ausgeführt wird.

Instanzen manuell verschieben

Wenn alle Voraussetzungen erfüllt sind:

  1. Stoppen Sie alle ausgeführten Anwendungen.

  2. Stellen Sie sicher, dass diese Anwendungen nicht automatisch gestartet werden.

    Achtung

    Wenn die umgespeicherte Instanz zum ersten Mal gestartet wird, werden Block-Volumes, sekundäre VNICs oder davon abhängige Ressourcen nicht angehängt. Wenn diese Ressourcen nicht vorhanden sind, können Anwendungsprobleme auftreten.

  3. Wenn die Instanz eine DenseIO-Ausprägung verwendet, sichern Sie die lokal angehängte NVMe-basierte SSD:

    1. Erstellen und ordnen Sie ein oder mehrere Block-Volumes der Instanz zu.
    2. Kopieren Sie die Daten von den NVMe-Geräten auf die Block-Volumes.
  4. Unmounten Sie alle Block-Volumes oder File Storage Service-(NFS-)Mounts.
  5. Sichern Sie alle Block-Volumes.

  6. Erstellen Sie ein Backup des Boot-Volumes.

    Wichtig

    Windows-Instanzen dürfen nicht generalisiert oder spezialisiert werden.

  7. Beenden (löschen) Sie die Instanz, und behalten Sie das zugeordnete Boot-Volume bei:

    Konsole verwenden

    Befolgen Sie die Schritte unter Instanz beenden, und stellen Sie sicher, dass das Kontrollkästchen Angehängtes Boot-Volume endgültig löschen deaktiviert ist. Dadurch wird das Boot-Volume, das mit der Instanz verknüpft ist, beibehalten.

    API verwenden

    Verwenden Sie den Vorgang TerminateInstance, und übergeben Sie in der Anforderung den Parameter preserveBootVolume, der auf true gesetzt ist.

    CLI verwenden

    Verwenden Sie den Vorgang instance termin, und setzen Sie die Option preserve-boot-volume auf true.

  8. Erstellen Sie eine neue Instanz mit dem Boot-Volume aus der beendeten Instanz.

    Geben Sie im Workflow zum Erstellen der Instanz die private IP-Adresse an, die der primären VNIC zugeordnet wurde. Wenn die öffentliche IP-Adresse von einem reservierten IP-Adresspool zugewiesen wurde, müssen Sie dieselbe IP-Adresse zuweisen.

  9. Wenn der Instanzstatus zu Wird ausgeführt wechselt, stoppen Sie die Instanz.
  10. Erstellen Sie alle sekundären VNICs und sekundären IP-Adressen neu.

  11. Hängen Sie alle Block-Volumes an.

    Hinweis

    Dieser Schritt umfasst alle Volumes für das Backup von lokalen NVMe-Geräten. Kopieren Sie die Daten in den NVMe-Speicher auf der neuen Instanz, und heben Sie die Zuordnung der Volumes auf.
  12. Starten Sie die Instanz.
  13. Starten und testen Sie alle Anwendungen auf der Instanz.
  14. Konfigurieren Sie die Anwendungen so, dass sie bei Bedarf automatisch gestartet werden.
  15. Erstellen Sie die erforderlichen Tags neu.
  16. (Optional) Nachdem Sie sich vergewissert haben, dass Instanz und Anwendungen fehlerfrei sind, können Sie die Volume-Backups löschen.