Offlinemigrationsschritte für VMware-VMFS-Datenspeicher von SCSI zu NVMe

Offline-VMFS-Datenspeichermigrationsschritte von SCSI zu NVMe

Inhaltsverzeichnis

• Offline-VMFS-Datenspeichermigration von SCSI zu NVMe – Schritte 1
• Übersicht
• Umfang

1. Schritte für die Offlinemigration
   1.  Vor der Migration
   2. Überprüfen Sie sowohl die Anzahl der Geräte als auch die Pfade zu jedem ESXi-Host. 3 
   3. Suchen Sie nach nicht unterstützten Funktionen. 4 
   4. Potenzielle Auswirkungen von nach der Migration auf unterstützte Funktionen prüfen 4 
2. Migration
   1. Unmounten des VMFS-Volumes von allen Hosts 5 
   2. Überprüfen Sie die Metadatenkonsistenz des VMFS-Volume. 5 
   3. Erneute Signatur des VMFS-Volume 10 
   4. Umbenennen des VMFS-Datenspeichers (optional) 11 
   5. Überprüfen Sie die Konsistenz der VMFS-Volume-Metadaten nach der erneuten Signatur. 11 
   6. Präsentieren des Geräts als NVMe für alle ESXi-Hosts im Cluster 11 
   7. Registrieren und Einschalten aller VMs 11 
3. Nach der Migration. 12 

 

---

 

Übersicht

Mit der zunehmenden NVMe-Einführung erwägen immer mehr Kunden die Migration von Daten von SCSI zu NVMe. In diesem Dokument wird eine der effizienten, wenn auch störenden Methoden für die Migration von SCSI zu NVMe beschrieben, die als Offlinemigration bezeichnet wird. Die Offlinemigration des VMFS-Datenspeichers von SCSI zu NVMe beinhaltet keine Verschiebung von Daten. Das Gerät, das zuvor einem ESXi-Host oder -Cluster als SCSI-Gerät präsentiert wurde, wird nicht angezeigt und dann erneut als NVMe-Gerät angezeigt. Der VMFS-Datenspeicher wird dann erneut signiert und den Hosts zur Verfügung gestellt, wobei seine VM-Inhalte erhalten bleiben. Details zu den Schritten der Offlinemigration werden nachfolgend beschrieben.

Umfang

• Die Schritte für die Offline-Migration, die in den nachfolgenden Abschnitten beschrieben werden, gelten nur für VMFS6-Datenspeicher.
• Die Schritte decken funktionale Aspekte der Migration ab und decken nicht die Performancemerkmale von Workloads nach der Migration ab.
• Die Validierung der Skalierung (Anzahl der gleichzeitigen Migrationen usw.) oder der Limits (maximale Pfade pro Gerät, maximale VMDKs pro VM usw.) ist nicht im Umfang enthalten.
• Die Begriffe "Gerät", "Volume" und "LUN" werden im Dokument synonym verwendet.
• Die Offlinemigration erfordert, dass alle VMs im VMFS-Datenspeicher vor dem Start ausgeschaltet werden.  

 

---

 

1. Schritte für die Offlinemigration

   Die Offlinemigration eines VMFS6-Datenspeichers von SCSI zu NVMe besteht aus drei Phasen. Jede Phase kann mehrere Überprüfungen oder Schritte umfassen.

   1. Vor der Migration

      Diese Vorbereitungsphase umfasst Überprüfungen, um die Merkmale der Umgebung und die verwendeten Funktionen zu verstehen. Diese Phase ist erforderlich, um festzustellen, ob die Offlinemigration in der Umgebung machbar ist, und um die Auswirkungen nach der Migration zu verstehen. Einige der wichtigen Prüfungen sind unten aufgeführt. Diese Liste ist nicht vollständig, sondern deckt die häufigsten Prüfungen in einer Standardkundenumgebung ab.

   2. Auf Sperrmodus des VMFS-Volume prüfen

      Stellen Sie zunächst sicher, dass die LUN den ATS-Modus unterstützt. Die Migration sollte nur versucht werden, wenn der VMFS6-Datenspeicher den reinen ATS-Sperrmodus und keine SCSI-2-Reservierungen verwendet. 
      
      Um den Sperrmodus eines bestimmten Volumes zu bestimmen, führen Sie den folgenden Befehl aus: esxcli storage vmfs lockmode list -l <volume name/label> auf einem ESXi-Host mit Zugriff auf den Datenspeicher. Die Offlinemigration wird nur unterstützt, wenn der Sperrmodus für das VMFS6-Volume "ATS" ist. Der Modus "ATS+SCSI" wird nicht unterstützt.
      
      Ein Beispiel für ein Volume, das Offlinemigration unterstützt:

      esxcli storage vmfs lockmode list -l testVol1
      Volume Name UUID                                Type   Locking Mode ATS Compatible ATS Upgrade Modes ATS Incompatibility Reason
      
      ----------- ----------------------------------- ------ ------------ -------------- ----------------- --------------------------
      
      testVol1    5d1c5b0f-xxxxxxxx-xxxx-246e9xxxxdb0 VMFS-6 ATS          true           No upgrade needed
      
      An example of a volume not supporting offline migration:
      
      esxcli storage vmfs lockmode list -l testVol2
       Volume Name UUID                                Type   Locking Mode ATS Compatible ATS Upgrade Modes ATS Incompatibility Reason
      
      ----------- ----------------------------------- ------ ------------ -------------- ----------------- --------------------------
      
      testVol2    63510e51-xxxxxxxx-xxxx-246e9xxxxde6 VMFS-6 ATS+SCSI     false          None              Device does not support ATS

       

   3. Überprüfen Sie, ob vmdk einer beliebigen VM im ausgewählten Datenspeicher wird als RDM (physisch oder virtuell) verwendet

      Wenn eine VM im ausgewählten Datenspeicher über eine RDM im SCSI-Modus verfügt, kann sie nicht zu NVMe migriert werden. Es gibt keinen VMware-Befehl, um festzustellen, ob eine VM über eine RDM verfügt, aber das Dell VSI-Plug-in listet den Festplattentyp für jede VM auf. Unten sehen Sie einen Screenshot der Ansicht in VSI, in der aufgeführt ist, ob VMs (Laufzeitname) über eine RDM verfügen.
      
       
       

      Wenn eine VM über eine RDM verfügt, muss die RDM entweder von der VM entfernt, konvertiert oder vor der Migration in einen anderen Datenspeicher verschoben werden.

   4. 1.3 Zuordnung von Anspruchsregeln/-einstellungen zum Gerät überprüfen, auf dem der VMFS-Datenspeicher gehostet wird

      Wenn vor der Migration nutzerdefinierte Anspruchsregeln auf dem SCSI-Gerät vorhanden sind, werden diese wahrscheinlich nicht auf das Gerät angewendet, wenn sie über NVMe angezeigt werden. NVMe-Geräte werden nicht mit separaten Anbieter- und Modellfeldern angezeigt, wenn sie über eine Anfrage aufgerufen werden. Die Felder sind zusammen, und daher ist eine neue Anspruchsregel erforderlich, wenn dies gewünscht wird. Darüber hinaus schlagen Anspruchsregeln, die auf Gerätekennungen basieren, z. B. WWN (World Wide Name), fehl, da die SCSI-Kennung und die NVMe-Kennung unterschiedlich sind.
      Standardmäßig beansprucht VMware neu präsentierte NVMe-Geräte mit dem Standard-Pathing-Plug-in HPP.

   5. Überprüfen Sie sowohl die Anzahl der Geräte als auch die Pfade zu jedem ESXi-Host

      NVMe unterstützt weniger Geräte und Pfade zu jedem ESXi-Host als SCSI. Wenn die Anzahl der SCSI-Geräte die NVMe-Limits überschreitet, ist es nicht möglich, alle Datenspeicher auf demselben ESXi-Host zu konvertieren. Als Lösung können Kunden mehr ESXi-Hosts einsetzen oder Datenspeicher entweder vor oder nach der Konvertierung mit Storage vMotion konsolidieren. 

      1. SCSI – 1024 Geräte/4096 Pfade
      2. NVMe – 256 Geräte/2048 Pfade

   6. Überprüfen auf nicht unterstützte Funktionen 

      Einige VMware-Funktionen werden derzeit nicht mit NVMe unterstützt. Prüfen Sie vor der Migration, ob sie unterstützt werden können.

      Beispielsweise werden die folgenden Funktionen derzeit nicht auf NVMe unterstützt, das auf ESXi (bis Version 8.0U1) ausgeführt wird.

       

      Funktion	Kurze Beschreibung	Bemerkungen
      Gast-Clustering	Geclusterte VMDK-Funktion, die Hochverfügbarkeitslösungen wie Windows Server Failover Cluster (WSFC) unterstützt	Ein VMFS-Datenspeicher mit geclusterten VMDK Aktiviert kann nicht migriert werden.
      SRM	Die arraybasierte Replikation mit SRM wird auf NVMe nicht unterstützt.	Die Migration von Datenspeichern, die an der SRM-Arrayreplikation beteiligt sind, macht die Lösung nutzlos.

       
      Hinweis: Die obige Liste erhebt keinen Anspruch auf Vollständigkeit. Kunden sollten sich in der arrayspezifischen Dokumentation über die Auswirkungen der Migration auf die kritischen Funktionen informieren.

   7. Potenzielle Auswirkungen von nach der Migration auf unterstützte Funktionen prüfen

      Die fehlende Integration der folgenden Funktionen kann die Performance bestimmter Vorgänge auf NVMe im Vergleich zu SCSI ändern.

      Funktion	Art der Auswirkungen	Aktion
      Hardwarebeschleunigte Verschiebung – XCOPY	Derzeit gibt es keinen äquivalenten Befehl zu XCOPY. Stattdessen wird der VMware Software Data Mover verwendet. Dies kann die Performance von Vorgängen beeinträchtigen, die das Primitiv verwenden, z. B. Klonen oder SvMotion.	Keine
      Write Same/UNMAP	Wenn ein NVMe-Gerät das NVMe-Äquivalent von Schreibnullen oder unmap, kann es zu Auswirkungen auf die Leistung kommen.	Keine

 

---

 

1. Migration

   Diese Phase umfasst die Schritte zum Migrieren des Datenspeichers von SCSI zu NVMe.

2. Herunterfahren aller VMs und Aufheben der Registrierung

   Schalten Sie alle auf dem zu migrierenden Datenspeicher gehosteten VMs aus und heben Sie deren Registrierung auf. Stellen Sie sicher, dass Sie sie nicht löschen, sondern nur die Registrierung aufheben.

3. VMFS-Volume von allen Hosts unmounten

   Unmounten Sie das VMFS-Volume von allen ESXi-Hosts, sobald die Registrierung aller VMs aufgehoben wurde. Dadurch wird sichergestellt, dass es nicht verwendet wird, wenn die Konsistenzprüfung und Migration durchgeführt wird

4. Konsistenz der VMFS-Volume-Metadaten überprüfen

   Überprüfen Sie vor dem Initiieren der Migration die Konsistenz der VMFS-Metadaten auf der Festplatte. Dadurch wird sichergestellt, dass es keine Inkonsistenzen gibt, bevor Sie beginnen.

   1. Führen Sie VOMA (VMware On-Disk Metadata Analyzer) im Prüfmodus durch Ausführen von:

   voma -m vmfs -f check -d /vmfs/devices/disks/<DEVICE>:<PARTITION> -s <OUTPUT FILE>

    

   Wo:

   DEVICE ist das SCSI-Gerät, auf dem das zu migrierende VMFS6-Volume gehostet wird.

   PARTITION ist die Partitionsnummer, auf der das VMFS-Volume auf dem Gerät formatiert ist.

   OUTPUT FILE ist der absolute Pfad der Datei, in der die Ausgabe des Befehls gespeichert werden muss. Diese Datei befindet sich im folgenden Pfad: /tmp wenn ausreichend Speicherplatz vorhanden ist, oder ein anderes VMFS-Volume als das, das migriert wird.

   Wie in:

    

   voma -m vmfs -f check -d naa.60000970000120200302533030313031:1 -s /tmp/voma.out

   Die Ausgabe sollte in etwa wie folgt aussehen:

   [root@dsib0184:/dev/disks] voma -m vmfs -f check -d naa.60000970000120200302533030313031:1
   Running VMFS Checker version 2.1 in check mode
   Initializing LVM metadata, Basic Checks will be done
   
   Checking for filesystem activity
            Scsi 2 reservation successful                       st activity (4096 bytes/HB, 1024 HBs).                            
   Phase 1: Checking VMFS header and resource files
      Detected VMFS-6 file system (labeled:'SRM_UPGRADE_1') with UUID:6418928f-d0fb0a78-fa29-34800d0ed39c, Version 6:82
   Phase 2: Checking VMFS heartbeat region
   Phase 3: Checking all file descriptors.
   Phase 4: Checking pathname and connectivity.
   Phase 5: Checking resource reference counts.
   Total Errors Found:           0

   Hinweis: Wenn der Befehl den folgenden Fehler empfängt, wird das VMFS nicht ordnungsgemäß ungemountet:

    

VOMA Fehler beim Prüfen des Geräts: Gerät oder Ressource ausgelastet

2. Analysieren Sie die Ausgabedatei, um festzustellen, ob Metadateninkonsistenzen von gemeldet wurden voma. Wenn es welche gibt, müssen sie durch Ausführen von voma im erweiterten Korrekturmodus, bevor Sie fortfahren. Im Folgenden finden Sie ein Beispiel:

[root@dsib0184:/dev/disks] voma -m vmfs -f fix -d naa.60000970000120200302533030313031:1
Running VMFS Checker version 2.1 in fix mode
Initializing LVM metadata, Basic Checks will be done
Checking for filesystem activity
         Scsi 2 reservation successful                       st activity (4096 bytes/HB, 1024 HBs).                            
Phase 1: Checking VMFS header and resource files
   Detected VMFS-6 file system (labeled:'SRM_UPGRADE_1') with UUID:6418928f-d0fb0a78-fa29-34800d0ed39c, Version 6:82
Phase 2: Checking VMFS heartbeat region
Phase 3: Checking all file descriptors.
Phase 4: Checking pathname and connectivity.
Phase 5: Checking resource reference counts.
Total Errors Found:           0
Total Errors Fixed:           0
Total Partially Fixed errors: 0

 

3. Erfassen und speichern Sie ein VMFS-Metadaten-Dump. Dies wäre erforderlich, wenn in nachfolgenden Schritten Metadateninkonsistenzen festgestellt werden. 

https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.htmlWeitere Informationen zur Verwendung von  voma In Check, erweiterter Korrekturmodus oder Speicherabbildmodus.

Trennen der SCSI-LUN von ESXi-Hosts

Trennen Sie die SCSI-LUN von jedem ESXi-Host im VC. Detaillierte Schritte finden Sie im KB-Artikel https://kb.vmware.com/s/article/2004605 .

 

Beenden Sie die Präsentation der SCSI-LUN vom Array.

Die Schritte zum Aufheben der Bereitstellung der SCSI-LUN sind spezifisch für das Storage-Array. Kunden sollten sich in der arrayspezifischen Dokumentation über das Verfahren informieren.

 

Präsentieren Sie das Gerät als NVMe für einen ESXi-Host.

Die Schritte zur erneuten Darstellung des Geräts mithilfe von NVMe sind Storage-Array-spezifisch. Kunden sollten sich in der arrayspezifischen Dokumentation über das Verfahren informieren. 

Initiieren Sie eine erneute Geräteüberprüfung auf dem Host.

Sobald das Gerät dem ESXi-Host über NVMe angezeigt wird, erfolgt die Erkennung in der Regel sofort. Wenn das Gerät jedoch nicht angezeigt wird, scannen Sie einen oder mehrere Adapter mithilfe der vSphere-Benutzeroberfläche oder -CLI erneut:
 

esxcli storage core adapter rescan -a

 

Überprüfen Sie die Konsistenz der VMFS-Volume-Metadaten nach der Konvertierung.

Führen Sie auf dem ESXi-Host, der Zugriff auf das Gerät hat, erneut voma im Prüfmodus aus, um zu überprüfen, ob die VMFS-Metadaten auf dem Laufwerk weiterhin konsistent sind. Alle Metadateninkonsistenzen müssen untersucht werden, bevor Sie fortfahren. 
Voma verwendet den SCSI-2-Befehl "reserve", um das Gerät zu sperren, um jeglichen gleichzeitigen Zugriff oder jede Änderung des VMFS-Volumes zu verhindern, wenn die Voma-Sitzung aktiv ist. NVMe-Geräte unterstützen jedoch kein Äquivalent einer SCSI-2-Reservierung. Um dieses Problem zu umgehen, muss der Benutzer die "-N" auf VOMA wenn das Back-end-Gerät NVMe ist. Zum Beispiel:

• Führen Sie VOMA (VMware On-Disk Metadata Analyzer) im Prüfmodus durch Ausführen von:

 

voma -m vmfs -f check -N -d /vmfs/devices/disks/<DEVICE>:<PARTITION> -s <OUTPUT FILE> 

Beim Herunterladen von voma wird mit "-N" wird die folgende Warnmeldung angezeigt. 

 

########################################################################
# Warning !!! #
# #
# You are about to execute VOMA without device reservation. #
# Any access to this device from other hosts when VOMA is running #
# can cause severe data corruption #
# #
# This mode is supported only under VMware Support supervision. #
########################################################################
VMware ESXi Question:
Do you want to continue (Y/N)?
0) _Yes
1) _No

Wählen Sie eine Zahl zwischen 0 und 1 aus:
Dies dient der Benachrichtigung dazu, dass es in der Verantwortung des Nutzers liegt, zu verhindern, dass das Volume bereitgestellt oder gleichzeitig von anderen Hosts aus aufgerufen wird, während die aktuelle Voma-Sitzung ausgeführt wird. Wenn die hier beschriebenen Schritte befolgt wurden und das Gerät nur auf einem ESXi-Host zugeordnet und erkannt wurde, sollte der Vorgang sicher fortgesetzt werden können. Der Benutzer sollte an der Eingabeaufforderung "0" eingeben, um mit dem Voma-Prüfmodus fortzufahren. Es folgt ein Beispiel:
 

[root@dsib0180:~] voma -m vmfs -f check -N -d /vmfs/devices/disks/eui.03025330303130420000976000012020:1

Ausführen von VMFS Checker-Version 2.1 im Prüfmodus
LVM-Metadaten werden initialisiert. Grundlegende Prüfungen sind abgeschlossen
Prüfung auf Dateisystemaktivität
Reservierung wird nicht unterstützt für NVMe-Geräte ST-Aktivität (4096 Byte/HB, 1024 HBs).                                 \
Überprüfung der Dateisystem-Liveness wird durchgeführt ..|

########################################################################
#   Warning !!!                                                        #
#                                                                      #
#   You are about to execute VOMA without device reservation.          #
#   Any access to this device from other hosts when VOMA is running    #
#   can cause severe data corruption                                   #
#                                                                      #
#   This mode is supported only under VMware support supervision.      #
########################################################################

VMware ESXi Question:
Do you want to continue (Y/N)?

0) _Yes
1) _No

Select a number from 0-1: 0

Phase 1: Checking VMFS header and resource files
   Detected VMFS-6 file system (labeled:'Temp_Datastore') with UUID:64359f88-dd0fd27e-af5a-34800d0ed39c, Version 6:82
Phase 2: Checking VMFS heartbeat region
Phase 3: Checking all file descriptors.
Phase 4: Checking pathname and connectivity.
Phase 5: Checking resource reference counts.
Total Errors Found:           0

Wählen Sie eine Zahl zwischen 0 und 1:

0 Phase 1: Überprüfen des VMFS-Headers und der Ressourcendateien
Erkanntes VMFS-6-Dateisystem (gekennzeichnet:'Temp_Datastore') mit UUID:64359f88-dd0fd27e-af5a-34800d0ed39c, Version 6:82
Phase 2: Überprüfen der VMFS-Heartbeat-Region
Phase 3: Alle Dateideskriptoren werden überprüft.
Phase 4: Pfadname und Konnektivität werden überprüft.
Phase 5: Die Anzahl der Ressourcenreferenzen wird überprüft.
Gesamtzahl der gefundenen Fehler:           0

Erneutes Signieren des VMFS-Volumes 

Nachdem das Gerät nun als NVMe angezeigt wird, muss die Signatur aktualisiert werden, die sich auf dem Datenspeicher befindet. Dies liegt daran, dass die aktuelle Signatur zum Teil auf dem WWN des Geräts basiert, wenn es über SCSI präsentiert wird. Da die NVMe-Geräte-ID unterschiedlich ist, muss eine neue Signatur erzeugt werden. Führen Sie daher auf demselben ESXi-Host, der in den beiden vorherigen Schritten verwendet wurde, Folgendes aus, um das Volume erneut zu signieren:

1. Obwohl es redundant ist, scannen Sie das Dateisystem erneut, indem Sie den folgenden Befehl ausführen:

 

esxcli storage filesystem rescan

2. Führen Sie dann den folgenden Befehl aus, um eine Liste der VMFS-Snapshot-LUNs abzurufen:

 

esxcli storage vmfs snapshot list

Das neu vorgestellte NVMe-Gerät sollte vorhanden sein, abhängig von der Umgebung kann es jedoch andere Snapshots geben, die nicht mit diesem Prozess zusammenhängen.

3. Signieren Sie das VMFS-Volume erneut, indem Sie Folgendes ausführen:

esxcli storage vmfs snapshot resignature --volume-label=<label>|–volume-uuid=<id>  

Nachfolgend finden Sie ein Beispiel:
 

[root@dsib0180:~] esxcli storage filesystem rescan
[root@dsib0180:~] esxcli storage vmfs snapshot list
64359f88-dd0fd27e-af5a-34800d0ed39c
   Volume Name: Temp_Datastore
   VMFS UUID: 64359f88-dd0fd27e-af5a-34800d0ed39c
   Can mount: true
   Reason for un-mountability:
   Can resignature: true
   Reason for non-resignaturability:
   Unresolved Extent Count: 1
[root@dsib0180:~] esxcli storage vmfs snapshot resignature -l Temp_Datastore

 

Umbenennen des VMFS-Datenspeichers (optional)

Wenn ein VMFS-Volume erneut signiert wird, wird dem VMFS-Volume-Etikett das Tag "snap" gefolgt von einer alphanumerischen Zeichenfolge vorangestellt. Beispiel: Der VMFS-Datenspeicher aus dem vorherigen Schritt heißt jetzt snap-5c42a2bc-Temp_Datastore Falls gewünscht, benennen Sie den Datenspeicher wieder in den ursprünglichen Namen um und entfernen Sie dabei das Präfix.

Überprüfen Sie die Konsistenz der VMFS-Volume-Metadaten nach der erneuten Signatur.

Überprüfen Sie erneut, ob die VMFS-Metadaten auf dem Laufwerk nach der erneuten Signatur konsistent sind. Führen Sie voma im Prüfmodus auf dem VMFS-Volume aus. Siehe Abschnitt 2.8 für die voma-Befehlszeile, die das Flag "-N" enthalten muss. Überprüfen Sie, ob voma Inkonsistenzen meldet. Fahren Sie fort, wenn voma keine Fehler meldet. 

Präsentieren Sie das Gerät als NVMe für alle ESXi-Hosts im Cluster.

Wenn in keinem der vorherigen Schritte Probleme aufgetreten sind, kann das Gerät jetzt allen ESXi-Hosts im Cluster über NVMe präsentiert werden. Wie bereits erwähnt, werden NVMe-Geräte sofort erkannt, aber wenn nicht, scannen Sie die Adapter erneut über die vSphere-Benutzeroberfläche oder -CLI. Überprüfen Sie, ob das VMFS6-Volume gemountet und auf allen Hosts zugänglich ist.

Registrieren und Einschalten aller VMs

Registrieren Sie alle VMs, die auf dem Datenspeicher gehostet werden, und schalten Sie sie ein. Überprüfen Sie, ob die VMs erfolgreich eingeschaltet werden und auf die VMDKs zugreifen können. Als Best Practice kann der Nutzer VMs auf einem einzigen ESXi registrieren und einschalten. Sobald dies erfolgreich war, können sie auf andere Hosts migriert werden.

Anmerkung: Beim Einschalten der VMs über die vCenter-Benutzeroberfläche wird möglicherweise ein Pop-up-Fenster wie das unten gezeigte angezeigt. Dadurch wird der Nutzer aufgefordert, aufzuzeichnen, ob die VM kopiert oder verschoben wurde. Wählen Sie im Pop-up-Fenster "Ich habe es kopiert".

 

 

---

 

Nach der Migration

Prüfen Sie, ob wichtige Funktionen betroffen sind, und führen Sie bei Bedarf eine Bereinigung durch. 

1.4 Prüfen Sie die Anzahl der Geräte und die Pfade zu den einzelnen ESXi-Hosts. 3
1.5 Prüfen Sie, ob nicht unterstützte Funktionen vorhanden sind 4
1.6 Prüfen Sie, ob sich die Migration nach der Migration auf die unterstützten Funktionen auswirkt 4
2.  Migration 4
2.2 Unmounten des VMFS-Volumes von allen Hosts 5
2.3 Überprüfen der Metadatenkonsistenz des VMFS-Volumes.
5 2.9 VMFS-Volume erneut signieren 10
2.10 VMFS-Datenspeicher umbenennen (optional) 11
2.11 Konsistenz der VMFS-Volume-Metadaten nach erneuter Signatur überprüfen. 11
2.12 Präsentieren des Geräts als NVMe für alle ESXi-Hosts im Cluster 11
2.13 Registrieren und Einschalten aller VMs 11
3. Nach der Migration. 12

Übersicht

Mit der zunehmenden NVMe-Einführung erwägen immer mehr Kunden die Migration von Daten von SCSI zu NVMe. In diesem Dokument wird eine der effizienten, wenn auch störenden Methoden für die Migration von SCSI zu NVMe beschrieben, die als Offlinemigration bezeichnet wird. Die Offlinemigration des VMFS-Datenspeichers von SCSI zu NVMe beinhaltet keine Verschiebung von Daten. Das Gerät, das zuvor einem ESXi-Host oder -Cluster als SCSI-Gerät präsentiert wurde, wird nicht angezeigt und dann erneut als NVMe-Gerät angezeigt. Der VMFS-Datenspeicher wird dann erneut signiert und den Hosts zur Verfügung gestellt, wobei seine VM-Inhalte erhalten bleiben. Details zu den Schritten der Offlinemigration werden nachfolgend beschrieben.

Umfang

• Die Schritte für die Offline-Migration, die in den nachfolgenden Abschnitten beschrieben werden, gelten nur für VMFS6-Datenspeicher.
• Die Schritte decken funktionale Aspekte der Migration ab und decken nicht die Performancemerkmale von Workloads nach der Migration ab.
• Die Validierung der Skalierung (Anzahl der gleichzeitigen Migrationen usw.) oder der Limits (maximale Pfade pro Gerät, maximale VMDKs pro VM usw.) ist nicht im Umfang enthalten.
• Die Begriffe Gerät, Volume und LUN werden in diesem Dokument synonym verwendet.
• Bei der Offlinemigration müssen vor dem Start alle VMs im VMFS-Datenspeicher heruntergefahren werden.  

Schritte für die Offlinemigration

Die Offlinemigration eines VMFS6-Datenspeichers von SCSI zu NVMe besteht aus drei Phasen. Jede Phase kann mehrere Überprüfungen oder Schritte umfassen.

Vor der Migration

Diese Vorbereitungsphase umfasst Überprüfungen, um die Merkmale der Umgebung und die verwendeten Funktionen zu verstehen. Diese Phase ist erforderlich, um festzustellen, ob die Offlinemigration in der Umgebung machbar ist, und um die Auswirkungen nach der Migration zu verstehen. Einige der wichtigen Prüfungen sind unten aufgeführt. Diese Liste ist nicht vollständig, sondern deckt die häufigsten Prüfungen in einer Standardkundenumgebung ab.

Überprüfen Sie, ob das VMFS-Volume gesperrt ist.

Stellen Sie zunächst sicher, dass die LUN den ATS-Modus unterstützt. Die Migration sollte nur versucht werden, wenn der VMFS6-Datenspeicher den reinen ATS-Sperrmodus und keine SCSI-2-Reservierungen verwendet. 

Um den Sperrmodus eines bestimmten Volumes zu bestimmen, führen Sie den folgenden Befehl aus: esxcli storage vmfs lockmode list -l <volume name/label> auf einem ESXi-Host mit Zugriff auf den Datenspeicher. Die Offlinemigration wird nur unterstützt, wenn der Sperrmodus für das VMFS6-Volume "ATS" ist. Der Modus "ATS+SCSI" wird nicht unterstützt.

Ein Beispiel für ein Volume, das Offlinemigration unterstützt:

esxcli storage vmfs lockmode list -l testVol1
Volume Name UUID                                Type   Locking Mode ATS Compatible ATS Upgrade Modes ATS Incompatibility Reason

----------- ----------------------------------- ------ ------------ -------------- ----------------- --------------------------

testVol1    5d1c5b0f-xxxxxxxx-xxxx-246e9xxxxdb0 VMFS-6 ATS          true           No upgrade needed

An example of a volume not supporting offline migration:

esxcli storage vmfs lockmode list -l testVol2
 Volume Name UUID                                Type   Locking Mode ATS Compatible ATS Upgrade Modes ATS Incompatibility Reason

----------- ----------------------------------- ------ ------------ -------------- ----------------- --------------------------

testVol2    63510e51-xxxxxxxx-xxxx-246e9xxxxde6 VMFS-6 ATS+SCSI     false          None              Device does not support ATS

1.2 Prüfen, ob vorhanden vmdk einer beliebigen VM im ausgewählten Datenspeicher wird als RDM (physisch oder virtuell) verwendet

Wenn eine VM im ausgewählten Datenspeicher über eine RDM im SCSI-Modus verfügt, kann sie nicht zu NVMe migriert werden. Es gibt keinen VMware-Befehl, um festzustellen, ob eine VM über eine RDM verfügt, aber das Dell VSI-Plug-in listet den Festplattentyp für jede VM auf. Unten sehen Sie einen Screenshot der Ansicht in VSI, in der aufgelistet wird, ob VMs (Laufzeitname) über eine RDM verfügen.

 

Wenn eine VM über eine RDM verfügt, muss die RDM entweder von der VM entfernt, konvertiert oder vor der Migration in einen anderen Datenspeicher verschoben werden.

1.3 Prüfen claim rules/settings Zuordnung zu dem Gerät, auf dem der VMFS-Datenspeicher gehostet wird.

Wenn vor der Migration nutzerdefinierte Anspruchsregeln auf dem SCSI-Gerät vorhanden sind, werden diese wahrscheinlich nicht auf das Gerät angewendet, wenn sie über NVMe angezeigt werden. NVMe-Geräte werden nicht mit separaten Anbieter- und Modellfeldern angezeigt, wenn sie über eine Anfrage aufgerufen werden. Die Felder sind zusammen, und daher ist eine neue Anspruchsregel erforderlich, wenn dies gewünscht wird. Darüber hinaus schlagen Anspruchsregeln, die auf Gerätekennungen basieren, z. B. WWN (World Wide Name), fehl, da die SCSI-Kennung und die NVMe-Kennung unterschiedlich sind.
Standardmäßig beansprucht VMware neu präsentierte NVMe-Geräte mit dem Standard-Pathing-Plug-in HPP.

1.4 Überprüfen Sie sowohl die Anzahl der Geräte als auch die Pfade zu jedem ESXi-Host.

NVMe unterstützt weniger Geräte und Pfade zu jedem ESXi-Host als SCSI. Wenn die Anzahl der SCSI-Geräte die NVMe-Limits überschreitet, ist es nicht möglich, alle Datenspeicher auf demselben ESXi-Host zu konvertieren. Als Lösung können Kunden mehr ESXi-Hosts einsetzen oder Datenspeicher entweder vor oder nach der Konvertierung mit Storage vMotion konsolidieren. 

1. SCSI – 1024 Geräte/4096 Pfade
2. NVMe – 256 Geräte/2048 Pfade

1.5 Prüfen Sie, ob nicht unterstützte Funktionen vorhanden sind. 

Einige VMware-Funktionen werden derzeit nicht mit NVMe unterstützt. Prüfen Sie vor der Migration, ob sie unterstützt werden können.
Beispielsweise werden die folgenden Funktionen derzeit nicht auf NVMe unterstützt, das auf ESXi (bis Version 8.0U1) ausgeführt wird. 
 

Funktion	Kurze Beschreibung	Bemerkungen
Gast-Clustering	Geclusterte VMDK-Funktion, die Hochverfügbarkeitslösungen wie Windows Server Failover Cluster (WSFC) unterstützt	Ein VMFS-Datenspeicher mit aktivierter geclusterter VMDK kann nicht migriert werden.
SRM	Die arraybasierte Replikation mit SRM wird auf NVMe nicht unterstützt.	Die Migration von Datenspeichern, die an der SRM-Arrayreplikation beteiligt sind, macht die Lösung nutzlos.

Hinweis: Die obige Liste erhebt keinen Anspruch auf Vollständigkeit. Kunden sollten sich in der arrayspezifischen Dokumentation über die Auswirkungen der Migration auf die kritischen Funktionen informieren. 

 

Überprüfen Sie die potenziellen Auswirkungen von nach der Migration auf unterstützte Funktionen.

Die fehlende Integration der folgenden Funktionen kann die Performance bestimmter Vorgänge auf NVMe im Vergleich zu SCSI ändern.
 

Funktion	Art der Auswirkungen	Aktion
Hardwarebeschleunigte Verschiebung – XCOPY	Derzeit gibt es keinen äquivalenten Befehl zu XCOPY. VMware Stattdessen wird der Software Data Mover verwendet. Dies kann die Performance von Vorgängen beeinträchtigen, die normalerweise das Primitiv verwenden, z. B. Klonen oder SvMotion.	Keine
Write Same/UNMAP	Wenn ein NVMe-Gerät das NVMe-Äquivalent von Schreibnullen oder unmap, kann es zu Auswirkungen auf die Leistung kommen.	Keine

Migration

Diese Phase umfasst die Schritte zum Migrieren des Datenspeichers von SCSI zu NVMe.

Herunterfahren aller VMs und Aufheben der Registrierung

Schalten Sie alle auf dem zu migrierenden Datenspeicher gehosteten VMs aus und heben Sie deren Registrierung auf. Stellen Sie sicher, dass Sie sie nicht löschen, sondern nur die Registrierung aufheben.

VMFS-Volume von allen Hosts unmounten

Unmounten Sie das VMFS-Volume von allen ESXi-Hosts, sobald die Registrierung aller VMs aufgehoben wurde. Dadurch wird sichergestellt, dass es nicht verwendet wird, wenn die Konsistenzprüfung und Migration durchgeführt wird. 

Überprüfen Sie die Metadatenkonsistenz des VMFS-Volume.

Überprüfen Sie vor dem Initiieren der Migration die Konsistenz der VMFS-Metadaten auf der Festplatte. So wird sichergestellt, dass es zu Beginn keine Inkonsistenzen gibt.

1. Führen Sie VOMA (VMware On-Disk Metadata Analyzer) im Prüfmodus durch Ausführen von:

voma -m vmfs -f check -d /vmfs/devices/disks/<DEVICE>:<PARTITION> -s <OUTPUT FILE>

Dabei gilt:
DEVICE das SCSI-Gerät, auf dem das VMFS6-Volume gehostet wird, das migriert wird.
PARTITION ist die Partitionsnummer, auf der das VMFS-Volume auf dem Gerät formatiert ist.
OUTPUT FILE ist der absolute Pfad der Datei, in der die Ausgabe des Befehls gespeichert werden muss. Diese Datei befindet sich im folgenden Pfad: /tmp wenn ausreichend Speicherplatz vorhanden ist, oder ein anderes VMFS-Volume als das, das migriert wird.

Zum Beispiel:

voma -m vmfs -f check -d naa.60000970000120200302533030313031:1 -s /tmp/voma.out

Die Ausgabe sollte in etwa wie folgt aussehen:
 

[root@dsib0184:/dev/disks] voma -m vmfs -f check -d naa.60000970000120200302533030313031:1
Running VMFS Checker version 2.1 in check mode
Initializing LVM metadata, Basic Checks will be done

Checking for filesystem activity
         Scsi 2 reservation successful                       st activity (4096 bytes/HB, 1024 HBs).                            
Phase 1: Checking VMFS header and resource files
   Detected VMFS-6 file system (labeled:'SRM_UPGRADE_1') with UUID:6418928f-d0fb0a78-fa29-34800d0ed39c, Version 6:82
Phase 2: Checking VMFS heartbeat region
Phase 3: Checking all file descriptors.
Phase 4: Checking pathname and connectivity.
Phase 5: Checking resource reference counts.
Total Errors Found:           0

Hinweis: Wenn der Befehl den folgenden Fehler empfängt, wurde das VMFS nicht ordnungsgemäß ungemountet:

VOMA konnte das Gerät nicht überprüfen: Gerät oder Ressource ausgelastet

2. Analysieren Sie die Ausgabedatei, um festzustellen, ob Metadateninkonsistenzen von gemeldet wurden voma. Wenn es welche gibt, müssen sie durch Ausführen von voma im erweiterten Korrekturmodus, bevor Sie fortfahren. Im Folgenden finden Sie ein Beispiel:

[root@dsib0184:/dev/disks] voma -m vmfs -f fix -d naa.60000970000120200302533030313031:1
Running VMFS Checker version 2.1 in fix mode
Initializing LVM metadata, Basic Checks will be done
Checking for filesystem activity
         Scsi 2 reservation successful                       st activity (4096 bytes/HB, 1024 HBs).                            
Phase 1: Checking VMFS header and resource files
   Detected VMFS-6 file system (labeled:'SRM_UPGRADE_1') with UUID:6418928f-d0fb0a78-fa29-34800d0ed39c, Version 6:82
Phase 2: Checking VMFS heartbeat region
Phase 3: Checking all file descriptors.
Phase 4: Checking pathname and connectivity.
Phase 5: Checking resource reference counts.
Total Errors Found:           0
Total Errors Fixed:           0
Total Partially Fixed errors: 0

 

3. Erfassen und speichern Sie ein VMFS-Metadaten-Dump. Dies wäre erforderlich, wenn in nachfolgenden Schritten Metadateninkonsistenzen festgestellt werden. 

https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.htmlWeitere Informationen zur Verwendung von  voma In Check, erweiterter Korrekturmodus oder Speicherabbildmodus.

Trennen der SCSI-LUN von ESXi-Hosts

Trennen Sie die SCSI-LUN von jedem ESXi-Host im VC. Detaillierte Schritte finden Sie im KB-Artikel https://kb.vmware.com/s/article/2004605.

Beenden Sie die Präsentation der SCSI-LUN vom Array.

Die Schritte zum Aufheben der Bereitstellung der SCSI-LUN sind spezifisch für das Storage-Array. Kunden sollten sich in der arrayspezifischen Dokumentation über das Verfahren informieren.

Präsentieren Sie das Gerät als NVMe für einen ESXi-Host.

Die Schritte zur erneuten Darstellung des Geräts mithilfe von NVMe sind Storage-Array-spezifisch. Kunden sollten sich in der arrayspezifischen Dokumentation über das Verfahren informieren. 

Initiieren Sie eine erneute Geräteüberprüfung auf dem Host.

Sobald das Gerät dem ESXi-Host über NVMe angezeigt wird, erfolgt die Erkennung in der Regel sofort. Wenn das Gerät jedoch nicht angezeigt wird, scannen Sie einen oder mehrere Adapter mithilfe der vSphere-Benutzeroberfläche oder -CLI erneut:
 

esxcli storage core adapter rescan -a

Überprüfen Sie die Konsistenz der VMFS-Volume-Metadaten nach der Konvertierung.

Führen Sie auf dem ESXi-Host, der Zugriff auf das Gerät hat, erneut voma im Prüfmodus aus, um zu überprüfen, ob die VMFS-Metadaten auf dem Laufwerk weiterhin konsistent sind. Alle Metadateninkonsistenzen müssen untersucht werden, bevor Sie fortfahren. 
Voma verwendet den SCSI-2-Reservebefehl, um das Gerät zu sperren, um jeglichen gleichzeitigen Zugriff oder jede Änderung des VMFS-Volumes zu verhindern, wenn die Voma-Sitzung aktiv ist. NVMe-Geräte unterstützen jedoch kein Äquivalent einer SCSI-2-Reservierung. Um dieses Problem zu umgehen, muss der Benutzer die "-N" auf VOMA wenn das Back-end-Gerät NVMe ist. Zum Beispiel:

• Führen Sie VOMA (VMware On-Disk Metadata Analyzer) im Prüfmodus aus, indem Sie Folgendes ausführen:

voma -m vmfs -f check -N -d /vmfs/devices/disks/<DEVICE>:<PARTITION> -s <OUTPUT FILE> 

 

When voma is invoked with "-N" option following warning message is displayed. 
########################################################################
# Warning !!! #
# #
# You are about to execute VOMA without device reservation. #
# Any access to this device from other hosts when VOMA is running #
# can cause severe data corruption #
# #
# This mode is supported only under VMware Support supervision. #
########################################################################
VMware ESXi Question:
Do you want to continue (Y/N)?
0) _Yes
1) _No

Wählen Sie eine Zahl zwischen 0 und 1 aus:
Dies dient der Benachrichtigung dazu, dass es in der Verantwortung des Nutzers liegt, zu verhindern, dass das Volume bereitgestellt oder gleichzeitig von anderen Hosts aus aufgerufen wird, während die aktuelle Voma-Sitzung ausgeführt wird. Wenn die hier beschriebenen Schritte befolgt wurden und das Gerät nur auf einem ESXi-Host zugeordnet und erkannt wurde, sollte der Vorgang sicher fortgesetzt werden können. Der Benutzer sollte an der Eingabeaufforderung "0" eingeben, um mit dem Voma-Prüfmodus fortzufahren. Es folgt ein Beispiel:
 

[root@dsib0180:~] voma -m vmfs -f check -N -d /vmfs/devices/disks/eui.03025330303130420000976000012020:1

Ausführen von VMFS Checker-Version 2.1 im Prüfmodus
LVM-Metadaten werden initialisiert. Grundlegende Prüfungen sind abgeschlossen
Prüfung auf Dateisystemaktivität
Reservierung wird nicht unterstützt für NVMe-Geräte ST-Aktivität (4096 Byte/HB, 1024 HBs).                                 \

Performing filesystem liveness check..|
########################################################################
#   Warning !!!                                                        #
#                                                                      #
#   You are about to execute VOMA without device reservation.          #
#   Any access to this device from other hosts when VOMA is running    #
#   can cause severe data corruption                                   #
#                                                                      #
#   This mode is supported only under VMware support supervision.      #
########################################################################

VMware ESXi Question:
Do you want to continue (Y/N)?

0) _Yes
1) _No

Select a number from 0-1: 0

Phase 1: Checking VMFS header and resource files
   Detected VMFS-6 file system (labeled:'Temp_Datastore') with UUID:64359f88-dd0fd27e-af5a-34800d0ed39c, Version 6:82
Phase 2: Checking VMFS heartbeat region
Phase 3: Checking all file descriptors.
Phase 4: Checking pathname and connectivity.
Phase 5: Checking resource reference counts.
Total Errors Found:           0

 

Erneutes Signieren des VMFS-Volumes 

Nachdem das Gerät nun als NVMe angezeigt wird, muss die Signatur aktualisiert werden, die sich auf dem Datenspeicher befindet. Dies liegt daran, dass die aktuelle Signatur zum Teil auf dem WWN des Geräts basiert, wenn es über SCSI präsentiert wird. Da die NVMe-Geräte-ID unterschiedlich ist, muss eine neue Signatur erzeugt werden. Führen Sie daher auf demselben ESXi-Host, der in den beiden vorherigen Schritten verwendet wurde, Folgendes aus, um das Volume erneut zu signieren:

1. Obwohl es redundant ist, scannen Sie das Dateisystem erneut, indem Sie den folgenden Befehl ausführen:

Erneuter Scan des ESXCLI-Speicherdateisystems

2. Führen Sie dann den folgenden Befehl aus, um eine Liste der VMFS-Snapshot-LUNs abzurufen:

ESXCLI-Storage VMFS-Snapshot-Liste

Das neu präsentierte NVMe-Gerät sollte vorhanden sein, je nach Umgebung kann es jedoch andere Snapshots geben, die nicht mit diesem Prozess zusammenhängen.

3. Signieren Sie das VMFS-Volume erneut, indem Sie Folgendes ausführen:

esxcli storage vmfs snapshot resignature --volume-label=<label>|–volume-uuid=<id> 

 

Nachfolgend finden Sie ein Beispiel:

[root@dsib0180:~] esxcli storage filesystem rescan
[root@dsib0180:~] esxcli storage vmfs snapshot list
64359f88-dd0fd27e-af5a-34800d0ed39c
   Volume Name: Temp_Datastore
   VMFS UUID: 64359f88-dd0fd27e-af5a-34800d0ed39c
   Can mount: true
   Reason for un-mountability:
   Can resignature: true
   Reason for non-resignaturability:
   Unresolved Extent Count: 1
[root@dsib0180:~] esxcli storage vmfs snapshot resignature -l Temp_Datastore

Umbenennen des VMFS-Datenspeichers (optional)

Wenn ein VMFS-Volume erneut signiert wird, wird dem VMFS-Volume-Etikett das Tag "snap" gefolgt von einer alphanumerischen Zeichenfolge vorangestellt. Der VMFS-Datenspeicher aus dem vorherigen Schritt heißt jetzt beispielsweise snap-5c42a2bc-Temp_Datastore. Falls gewünscht, benennen Sie den Datenspeicher wieder in den ursprünglichen Namen um, und entfernen Sie dabei das Präfix.

Überprüfen Sie die Konsistenz der VMFS-Volume-Metadaten nach der erneuten Signatur.

Überprüfen Sie erneut, ob die VMFS-Metadaten auf dem Laufwerk nach der erneuten Signatur konsistent sind. Führen Sie voma im Prüfmodus auf dem VMFS-Volume aus. Siehe Abschnitt 2.8 für die voma-Befehlszeile, die das Flag "-N" enthalten muss. Überprüfen Sie, ob voma Inkonsistenzen meldet. Fahren Sie fort, wenn voma keine Fehler meldet. 

Präsentieren Sie das Gerät als NVMe für alle ESXi-Hosts im Cluster.

Wenn in keinem der vorherigen Schritte Probleme aufgetreten sind, kann das Gerät jetzt allen ESXi-Hosts im Cluster über NVMe präsentiert werden. Wie bereits erwähnt, werden NVMe-Geräte sofort erkannt, aber wenn nicht, scannen Sie die Adapter erneut über die vSphere-Benutzeroberfläche oder -CLI. Überprüfen Sie, ob das VMFS6-Volume gemountet und auf allen Hosts zugänglich ist.

Registrieren und Einschalten aller VMs

Registrieren Sie alle VMs, die auf dem Datenspeicher gehostet werden, und schalten Sie sie ein. Überprüfen Sie, ob die VMs erfolgreich eingeschaltet werden und auf die VMDKs zugreifen können. Als Best Practice kann der Nutzer VMs auf einem einzigen ESXi registrieren und einschalten. Sobald dies erfolgreich war, können sie auf andere Hosts migriert werden.

Anmerkung: Beim Einschalten der VMs über die vCenter-Benutzeroberfläche wird möglicherweise ein Pop-up-Fenster wie das unten gezeigte angezeigt. Dadurch wird der Nutzer aufgefordert, aufzuzeichnen, ob die VM kopiert oder verschoben wurde. Wählen Sie im Pop-up-Fenster "Ich habe es kopiert".

 

Nach der Migration

Prüfen Sie, ob wichtige Funktionen betroffen sind, und führen Sie bei Bedarf eine Bereinigung durch. 

 

Dies ist ein offiziell von VMware geprüfter Prozess für die Offline-Datenspeichermigration. Onlinemigrationen einzelner VMs können mithilfe von Storage vMotion durchgeführt werden. VMware verfügt nicht über einen separaten Wissensdatenbank-Artikel für diesen Prozess.

PowerFlex Appliance, PowerFlex custom node, PowerMax 2000, PowerMax 2500, PowerMax 8000, PowerMax 8500, PowerStore 1000X, PowerStore 1000T, PowerStore 1200T, PowerStore 3000X, PowerStore 3000T, PowerStore 3200T, PowerStore 5000X, PowerStore 5000T , PowerStore 500T, PowerStore 5200T, PowerStore 7000X, PowerStore 7000T, PowerStore 9000X, PowerStore 9000T, PowerStore 9200T, VMAX 250F, VMAX 450F, VMAX 950F, VMware ESXi 7.x, VMware ESXi 8.x ... 表示を増やす about warranties 表示を減らす about warranties