Етапи міграції SCSI на NVMe VMware VMFS Datastore в автономному режимі

概要: У цьому документі описано, як виконати автономну міграцію зі сховища даних VMware vSphere SCSI до сховища даних NVMeoF. Міграція сховища даних VMFS з SCSI на NVMe в автономному режимі не передбачає переміщення даних, хоча і вимагає простою для задіяних віртуальних машин. Детальна інформація про кроки міграції в автономному режимі описана нижче. Цей КБ застосовується до будь-якої системи зберігання даних Dell, яка підтримує протоколи SCSI та NVMeoF. Це включає, але не обмежується ними, PowerFlex, PowerMax і PowerStore. VMware і Dell співпрацювали над цією базою даних. ...

この記事は次に適用されます: この記事は次には適用されません: この記事は、特定の製品に関連付けられていません。 すべての製品パージョンがこの記事に記載されているわけではありません。

手順

Етапи міграції сховища даних SCSI на NVMe в автономному режимі VMFS

Зміст

  • Міграція сховища даних SCSI на NVMe в автономному режимі VMFS Кроки 1
  • Огляд
  • Масштаб
  1. Етапи міграції в автономному режимі
    1.  Передміграція
    2. Перевірте як кількість пристроїв, так і шляхи до кожного хоста ESXi 3 
    3. Перевірте наявність непідтримуваних функцій 4 
    4. Перевірте потенційний вплив постміграції на підтримувані функції 4 
  2. Міграції
    1. Демонтувати том VMFS з усіх хостів 5 
    2. Перевірте узгодженість метаданих гучності VMFS. 5 
    3. Повторне підписання 10-го тому VMFS 
    4. Перейменування сховища даних VMFS (необов'язково) 11 
    5. Перевірте узгодженість метаданих гучності VMFS після повторного підпису. 11 
    6. Представте пристрій як NVMe для всіх хостів ESXi у кластері 11 
    7. Зареєструйте та увімкніть усі віртуальні машини 11 
  3. Після міграції. 12 

 


 

Огляд

Зі зростанням популярності NVMe все більше клієнтів розглядають можливість міграції даних з SCSI на NVMe. Цей документ описує один з ефективних, хоча і руйнівних методів міграції SCSI на NVMe, відомий як автономна міграція. Міграція сховища даних VMFS в автономному режимі з SCSI на NVMe не передбачає переміщення даних. Пристрій, який раніше був представлений хосту або кластеру ESXi як пристрій SCSI, не представляється, а потім знову представлений як пристрій NVMe. Потім сховище даних VMFS повторно підписується та стає доступним для хостів, зберігаючи вміст віртуальної машини. Детальна інформація про кроки міграції в автономному режимі описана нижче.

Масштаб

  • Кроки для міграції в автономному режимі, описані в наступних розділах, застосовні лише до сховищ даних VMFS6.
  • Кроки охоплюють функціональні аспекти міграції та не охоплюють характеристики продуктивності робочих навантажень після міграції.
  • Перевірка масштабу (кількість одночасних міграцій тощо) або обмежень (максимальна кількість шляхів на пристрій, максимальна кількість VMDK на віртуальну машину тощо) не входить до сфери застосування.
  • Терміни «пристрій», «гучність» і «ЛУН» використовуються в документі як синоніми.
  • Міграція в автономному режимі вимагає, щоб усі віртуальні машини в сховищі даних VMFS були вимкнені перед запуском.  

 


 

  1. Етапи міграції в автономному режимі

    Автономна міграція сховища даних VMFS6 з SCSI на NVMe складається з трьох етапів. Кожен етап може включати кілька перевірок або кроків.

    1. Передміграція

      Цей підготовчий етап включає перевірку для розуміння характеристик навколишнього середовища та функцій, які використовуються. Цей етап необхідний для визначення того, чи можлива офлайн-міграція в середовищі, а також для розуміння наслідків після міграції. Деякі з важливих перевірок перераховані нижче. Цей список не є вичерпним, скоріше він охоплює найпоширеніші перевірки в стандартному середовищі клієнтів.

    2. Перевірте режим блокування гучності VMFS

      По-перше, переконайтеся, що LUN підтримує режим ATS. Міграцію слід намагатися здійснити лише в тому випадку, якщо сховище даних VMFS6 використовує режим блокування лише ATS і не використовує резервування SCSI-2. 

      Щоб визначити режим блокування заданого обсягу, виконайте команду esxcli storage vmfs lockmode list -l <volume name/label> на хості ESXi з доступом до сховища даних. Міграція в автономному режимі підтримується лише в тому випадку, якщо для гучності VMFS6 вибрано режим блокування «ATS». Режим "ATS+SCSI" не підтримується.

      Приклад обсягу, який підтримує міграцію в автономному режимі:

       
      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. Перевірте, чи є такі vmdk будь-якої віртуальної машини в обраному сховищі даних використовується як RDM (фізична або віртуальна)

      Якщо віртуальна машина у вибраному сховищі даних має RDM у режимі SCSI, то їй не можна дозволити мігрувати на NVMe. Немає команди VMware для визначення, чи має віртуальна машина RDM, однак плагін Dell VSI вказує тип диска для кожної віртуальної машини. Нижче наведено скріншот перегляду у VSI, на якому вказано, чи мають якісь віртуальні машини (ім'я виконання) RDM.

      Пристрої з масивами Dell у vSphere 
       

      Якщо віртуальна машина має RDM, то перед міграцією її потрібно видалити з віртуальної машини, перетворити, або перемістити її в інше сховище даних.

    4. 1.3 Перевірте відповідність правил/налаштувань претензій на пристрій, на якому розміщено сховище даних VMFS

      Якщо перед міграцією на пристрої SCSI є якісь правила користувацького вимоги, вони, швидше за все, не будуть застосовані до пристрою під час використання NVMe. Пристрої NVMe не представлені окремими полями постачальника та моделі, якщо доступ до них здійснюється за запитом. Поля знаходяться разом, і тому необхідне нове правило вимоги, якщо ви цього хочете. Крім того, правила подання вимог, засновані на ідентифікаторах пристроїв, наприклад, World Wide Name (WWN), не спрацюють, оскільки ідентифікатор SCSI та ідентифікатор NVMe відрізняються.
      За замовчуванням VMware вимагатиме нещодавно представлені пристрої NVMe з плагіном шляху за замовчуванням HPP.

    5. Перевірте як кількість пристроїв, так і шляхи до кожного хоста ESXi

      NVMe підтримує менше пристроїв і шляхів, ніж SCSI, до кожного хоста ESXi. Якщо кількість пристроїв SCSI перевищує межі NVMe, конвертувати всі сховища даних на одному хості ESXi неможливо. Як рішення, клієнти можуть використовувати більше хостів ESXi або консолідувати сховища даних до або після перетворення за допомогою Storage vMotion. 

      1. SCSI - 1024 пристроїв/4096 шляхів
      2. NVMe - 256 пристроїв/2048 шляхів
    6. Перевірте наявність непідтримуваних функцій 

      Деякі функції VMware в даний час не підтримуються NVMe. Перевірте можливість підтримки перед міграцією.

      Наприклад, наведені нижче функції наразі не підтримуються на NVMe, що працює на ESXi (до випуску 8.0U1).

       
      Ознака  Короткий опис Зауваження
      Кластеризація гостей Функція кластеризованого VMDK, яка підтримує рішення високої доступності, такі як кластер відмовостійкості Windows Server (WSFC)  Сховище даних VMFS з кластеризованим VMDK увімкнено не можна перенести.
      СРМ Реплікація на основі масиву з SRM не підтримується на NVMe. Міграція сховищ даних, пов'язаних з реплікацією масиву SRM, робить рішення марним.
       
      Примітка: Наведений перелік не є вичерпним. Клієнти повинні ознайомитися з документацією для конкретного масиву щодо впливу міграції на критичні функції.
    7. Перевірте потенційний вплив постміграції на підтримувані функції

      Відсутність інтеграції наведених нижче функцій може змінити те, як певні операції виконуються на NVMe порівняно з SCSI.

      Ознака Характер впливу Дії, які необхідно вжити
      Апаратне прискорення переміщення - XCOPY В даний час не існує еквівалентної команди to XCOPY. Замість цього використовується програмний перенаповнювач даних VMware. Це може знизити продуктивність операцій, які використовують примітив, таких як клонування або SvMotion. Ніхто
      Записати те саме/UNMAP Якщо пристрій NVMe не підтримує NVMe-еквівалент запису нулів або unmap, це може вплинути на продуктивність. Ніхто

 


 

  1. Міграції

    Цей етап включає в себе кроки з міграції сховища даних з SCSI на NVMe.

  2. Вимкніть усі віртуальні машини та скасуйте реєстрацію

    Вимкніть живлення та скасуйте реєстрацію всіх віртуальних машин, розміщених у сховищі даних для міграції. Обов'язково не видаляйте їх, а лише зніміть з реєстрації.

  3. Демонтувати том VMFS з усіх хостів

    Від'єднайте том VMFS від усіх хостів ESXi, коли всі віртуальні машини будуть зняті з реєстрації. Це зроблено для того, щоб він не використовувався під час перевірки стабільності та міграції

  4. Перевірте узгодженість метаданих гучності VMFS

    Перш ніж ініціювати міграцію, перевірте узгодженість метаданих VMFS на диску. Це гарантує відсутність невідповідностей перед початком.

    1. Бігти VOMA (VMware On-Disk Metadata Analyzer) у режимі перевірки запустивши:
    voma -m vmfs -f check -d /vmfs/devices/disks/<DEVICE>:<PARTITION> -s <OUTPUT FILE>
     

    Де:

    DEVICE – це пристрій SCSI, на якому розміщено том VMFS6, який мігрується

    PARTITION – це номер розділу, на якому відформатовано том VMFS на пристрої

    OUTPUT FILE – це абсолютний шлях до файлу, в якому має бути збережено виведені дані команди. Цей файл може бути розташований у /tmp якщо у ньому достатньо місця або будь-якого тому VMFS, відмінного від того, який переноситься.

    А саме:

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

    Вихідні дані повинні виглядати приблизно так:

    [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
    Примітка. Якщо команда отримує наступну помилку, то VMFS не демонтована належним чином:
     

VOMA Не вдалося перевірити пристрій: Пристрій або ресурс зайняті

  1. Проаналізуйте вихідний файл, щоб побачити, чи немає невідповідностей у метаданих, про які повідомляє voma. Якщо такі є, то їх необхідно усунути за допомогою запуску voma у розширеному режимі виправлення, перш ніж продовжити. Нижче наведено приклад:
[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

 

  1. Збирайте та зберігайте дамп метаданих VMFS. Це буде потрібно, якщо на наступних кроках будуть виявлені будь-які невідповідності метаданих. 

Будь ласка , перегляньте https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.htmlЦе гіперпосилання веде вас на веб-сайт за межами Dell Technologies. для отримання більш детальної інформації про використання voma в режимі Check, Advanced Fix mode або Dump Mode.

Від'єднання SCSI LUN від хостів ESXi

Від'єднайте SCSI LUN від кожного хоста ESXi у ВК. Докладні кроки дивіться в статті КБ https://kb.vmware.com/s/article/2004605Це гіперпосилання веде вас на веб-сайт за межами Dell Technologies. .

 

Зупиніть представлення SCSI LUN з масиву.

Кроки для скасування представлення SCSI LUN є специфічними для масиву зберігання. Клієнти повинні ознайомитися з документацією, що стосується масиву, щодо процедури.

 

Представте пристрій як NVMe одному хосту ESXi.

Кроки для повторного представлення пристрою за допомогою NVMe залежать від масиву зберігання. Клієнти повинні ознайомитися з документацією, що стосується масиву, щодо процедури. 

Запустіть повторне сканування пристрою на хості.

Як тільки пристрій представлено хосту ESXi за допомогою NVMe, виявлення зазвичай відбувається негайно. Однак, якщо пристрій не відображається, повторно відскануйте один або кілька адаптерів за допомогою vSphere UI або CLI:
 

esxcli storage core adapter rescan -a

 

Перевірте узгодженість метаданих гучності VMFS після перетворення.

На хості ESXi, який має доступ до пристрою, ще раз запустіть voma в режимі перевірки, щоб перевірити, що метадані VMFS на диску все ще узгоджені. Будь-які невідповідності метаданих мають бути досліджені, перш ніж продовжити. 
Voma використовує команду резерву SCSI-2 для блокування пристрою, щоб запобігти будь-якому одночасному доступу або зміні гучності VMFS, коли сеанс voma активний. Однак пристрої NVMe не підтримують еквівалент резервування SCSI-2. Щоб обійти це, користувач повинен передати «-N" на VOMA коли серверним пристроєм є NVMe. Наприклад:

  • Бігти VOMA (VMware On-Disk Metadata Analyzer) у режимі перевірки запустивши:

 

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



Коли voma викликається за допомогою "-N" На дисплеї з'явиться наступне попереджувальне повідомлення. 

 

########################################################################
# 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


Виберіть номер з 0-1:
Це означає, що користувач несе відповідальність за запобігання одночасному монтуванню або доступу до гучності з інших хостів під час поточної сесії voma. Якщо кроки, описані тут, були дотримані, а пристрій було відображено та виявлено лише на одному хості ESXi, то продовжувати слід безпечно. Користувач повинен ввести «0» у підказці, щоб продовжити роботу з режимом перевірки voma. Наведемо приклад:
 

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


Запуск VMFS Checker версії 2.1 у режимі
перевірки Ініціалізація метаданих LVM, Основні перевірки виконані
Перевірка активності
файлової системи Підтримка резервування відсутня для пристроїв NVMe st активність (4096 байт/HB, 1024 HB).                                 \
Виконання перевірки жвавості файлової системи..|

########################################################################
#   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


Виберіть число з 0-1:

0 Фаза 1: Перевірка заголовка VMFS та файлів
ресурсів Виявлена файлова система VMFS-6 (позначена:'Temp_Datastore') з UUID:64359f88-dd0fd27e-af5a-34800d0ed39c, Version 6:82
Етап 2: Перевірка області
серцебиття VMFS Фаза 3: Перевірка всіх дескрипторів файлів.
Етап 4: Перевірка шляху та підключення.
Етап 5: Перевірка кількості посилань на ресурси.
Всього знайдених помилок:           0

Повторне підписання тому VMFS 

Тепер, коли пристрій представлено як NVMe, необхідно оновити підпис, який знаходиться на сховищі даних. Це пов'язано з тим, що поточна сигнатура частково базується на WWN пристрою під час представлення за допомогою SCSI. Оскільки ідентифікатор пристрою NVMe відрізняється, має бути створено новий підпис. Тому на тому ж хості ESXi, який використовувався на попередніх двох кроках, запустіть наступне, щоб повторно підписати том:

  1. Незважаючи на зайве, перескануйте файлову систему, виконавши команду:

 

esxcli storage filesystem rescan
  1. Далі виконайте наступну команду, щоб отримати список LUN знімків VMFS:

 

esxcli storage vmfs snapshot list


Нещодавно представлений пристрій NVMe повинен бути присутнім, хоча в залежності від оточення можуть бути й інші знімки, не пов'язані з цим процесом.

  1. Повторно підписайте том VMFS, виконавши наступне:
esxcli storage vmfs snapshot resignature --volume-label=<label>|–volume-uuid=<id>  


Приклад наведено нижче:
 

[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

 

Перейменування сховища даних VMFS (необов'язково)

Коли том VMFS повторно підписується, мітка тому VMFS має префікс "snap", за яким слідує буквено-цифровий рядок. Наприклад, сховище даних VMFS на попередньому кроці тепер має назву: snap-5c42a2bc-Temp_Datastore Якщо потрібно, перейменуйте сховище даних назад на оригінальне ім'я, видаливши префікс.

Перевірте узгодженість метаданих гучності VMFS після повторного підпису.

Ще раз перевірте, чи метадані VMFS на диску узгоджені після повторного підпису. Запустіть voma в режимі перевірки гучності VMFS. Дивіться розділ 2.8 для командного рядка voma, який повинен включати прапорець "-N". Перевірте, чи не повідомляє voma про будь-які невідповідності. Продовжуйте, якщо voma не повідомляє про будь-які помилки. 

Представте пристрій як NVMe для всіх хостів ESXi у кластері.

Якщо на жодному з попередніх кроків не виникло проблем, пристрій тепер можна представити за допомогою NVMe всім хостам ESXi у кластері. Як уже зазначалося, NVMe-пристрої розпізнаються відразу, але якщо не пересканувати адаптери через vSphere UI або CLI. Переконайтеся, що том VMFS6 змонтовано та доступно на всіх хостів.

Зареєструйтесь та увімкніть усі віртуальні машини

Зареєструйте всі віртуальні машини, розміщені в сховищі даних, і увімкніть їх. Переконайтеся, що віртуальні машини успішно ввімкнулися та мають доступ до vmdks. Як найкраща практика, користувач може зареєструвати та увімкнути віртуальні машини на одному ESXi. Після успіху їх можна буде перенести на інші хостинги.

Примітка: Під час увімкнення віртуальних машин з інтерфейсу vCenter UI може з'явитися спливаюче вікно, подібне до того, що показано нижче. Це запропонує користувачеві записати, чи була скопійована або переміщена віртуальна машина. Виберіть «Я його скопіював» у спливаючому вікні.

Дайте відповідь на запитання для клонування віртуальної машини. 

 


 

Після міграції

Перевірте, чи не вплинули на будь-які ключові функції, і виконайте будь-яке очищення, якщо потрібно. 

1.4 Перевірте кількість пристроїв і шляхи до кожного хоста ESXi 3
1.5 Перевірте наявність непідтримуваних функцій 4
1.6 Перевірте потенційний вплив після міграції на підтримувані функції 4
2.  Міграція 4
2.2 Демонтування гучності VMFS з усіх хостів 5
2.3 Перевірка узгодженості метаданих гучності VMFS.
5 2.9 Повторне підписування тому VMFS 10
2.10 Перейменування сховища даних VMFS (необов'язково) 11
2.11 Перевірка узгодженості метаданих тому VMFS після повторного підпису. 11
2.12 Представте пристрій як NVMe для всіх хостів ESXi у кластері 11
2.13 Зареєструйте та увімкніть усі віртуальні машини 11
3. Після міграції. 12

Огляд

Зі зростанням популярності NVMe все більше клієнтів розглядають можливість міграції даних з SCSI на NVMe. Цей документ описує один з ефективних, хоча і руйнівних методів міграції SCSI на NVMe, відомий як автономна міграція. Міграція сховища даних VMFS в автономному режимі з SCSI на NVMe не передбачає переміщення даних. Пристрій, який раніше був представлений хосту або кластеру ESXi як пристрій SCSI, не представляється, а потім знову представлений як пристрій NVMe. Потім сховище даних VMFS повторно підписується та стає доступним для хостів, зберігаючи вміст віртуальної машини. Детальна інформація про кроки міграції в автономному режимі описана нижче.

Масштаб

  • Кроки для міграції в автономному режимі, описані в наступних розділах, застосовні лише до сховищ даних VMFS6.
  • Кроки охоплюють функціональні аспекти міграції та не охоплюють характеристики продуктивності робочих навантажень після міграції.
  • Перевірка масштабу (кількість одночасних міграцій тощо) або обмежень (максимальна кількість шляхів на пристрій, максимальна кількість VMDK на віртуальну машину тощо) не входить до сфери застосування.
  • Терміни «пристрій», «гучність» і «ЛУН» використовуються в документі як синоніми.
  • Міграція в автономному режимі вимагає, щоб усі віртуальні машини в сховищі даних VMFS були вимкнені перед запуском.  

Етапи міграції в автономному режимі

Автономна міграція сховища даних VMFS6 з SCSI на NVMe складається з трьох етапів. Кожен етап може включати кілька перевірок або кроків.

Передміграція

Цей підготовчий етап включає перевірку для розуміння характеристик навколишнього середовища та функцій, які використовуються. Цей етап необхідний для визначення того, чи можлива офлайн-міграція в середовищі, а також для розуміння наслідків після міграції. Деякі з важливих перевірок перераховані нижче. Цей список не є вичерпним, скоріше він охоплює найпоширеніші перевірки в стандартному середовищі клієнтів.

Перевірте режим блокування гучності VMFS.

По-перше, переконайтеся, що LUN підтримує режим ATS. Міграцію слід намагатися здійснити лише в тому випадку, якщо сховище даних VMFS6 використовує режим блокування лише ATS і не використовує резервування SCSI-2. 

Щоб визначити режим блокування заданого обсягу, виконайте команду esxcli storage vmfs lockmode list -l <volume name/label> на хості ESXi з доступом до сховища даних. Міграція в автономному режимі підтримується лише в тому випадку, якщо для гучності VMFS6 вибрано режим блокування «ATS». Режим "ATS+SCSI" не підтримується.

Приклад обсягу, який підтримує міграцію в автономному режимі:

 
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 Перевірте, чи є такі vmdk будь-якої віртуальної машини в обраному сховищі даних використовується як RDM (фізична або віртуальна)

Якщо віртуальна машина у вибраному сховищі даних має RDM у режимі SCSI, то їй не можна дозволити мігрувати на NVMe. Немає команди VMware для визначення, чи має віртуальна машина RDM, однак плагін Dell VSI вказує тип диска для кожної віртуальної машини. Нижче наведено скріншот перегляду у VSI, на якому буде вказано, чи мають якісь віртуальні машини (ім'я виконання) RDM.

Список VMFS та RDM для міграції. 

Якщо віртуальна машина має RDM, то перед міграцією її потрібно видалити з віртуальної машини, перетворити, або перемістити її в інше сховище даних.

1.3 Перевірка claim rules/settings прив'язка до пристрою, на якому розміщено сховище даних VMFS.

Якщо перед міграцією на пристрої SCSI є якісь правила користувацького вимоги, вони, швидше за все, не будуть застосовані до пристрою під час використання NVMe. Пристрої NVMe не представлені окремими полями постачальника та моделі, якщо доступ до них здійснюється за запитом. Поля знаходяться разом, і тому необхідне нове правило вимоги, якщо ви цього хочете. Крім того, правила подання вимог, засновані на ідентифікаторах пристроїв, наприклад, World Wide Name (WWN), не спрацюють, оскільки ідентифікатор SCSI та ідентифікатор NVMe відрізняються.
За замовчуванням VMware заявляє про нещодавно представлені пристрої NVMe з плагіном HPP для визначення шляху за замовчуванням.

1.4 Перевірте як кількість пристроїв, так і шляхи до кожного хоста ESXi.

NVMe підтримує менше пристроїв і шляхів, ніж SCSI, до кожного хоста ESXi. Якщо кількість пристроїв SCSI перевищить межі NVMe, не вдасться конвертувати всі сховища даних на одному хості ESXi. Як рішення, клієнти можуть використовувати більше хостів ESXi або консолідувати сховища даних до або після перетворення за допомогою Storage vMotion. 

  1. SCSI - 1024 пристроїв/4096 шляхів
  2. NVMe - 256 пристроїв/2048 шляхів

1.5 Перевірте наявність непідтримуваних функцій. 

Деякі функції VMware в даний час не підтримуються NVMe. Перевірте можливість підтримки перед міграцією.
Наприклад, наведені нижче функції наразі не підтримуються на NVMe, що працює на ESXi (до випуску 8.0U1). 
 

Ознака  Короткий опис Зауваження
Кластеризація гостей Функція кластеризованого VMDK, яка підтримує рішення високої доступності, такі як кластер відмовостійкості Windows Server (WSFC)  Сховище даних VMFS з увімкненим кластерним VMDK не може бути перенесене.
СРМ Реплікація на основі масиву з SRM не підтримується на NVMe. Міграція сховищ даних, пов'язаних з реплікацією масиву SRM, робить рішення марним.


Примітка: Наведений перелік не є вичерпним. Клієнти повинні ознайомитися з документацією для конкретного масиву щодо впливу міграції на критичні функції. 

 

Перевірте потенційний вплив постміграції на підтримувані функції.

Відсутність інтеграції наведених нижче функцій може змінити те, як певні операції виконуються на NVMe порівняно з SCSI.
 

Ознака Характер впливу Дії, які необхідно вжити
Апаратне прискорення переміщення - XCOPY В даний час не існує еквівалентної команди to XCOPY. VMware Замість цього буде використовуватися програмний переміщувач даних. Це може знизити продуктивність операцій, які зазвичай використовують примітив, таких як клонування або SvMotion. Ніхто
Записати те саме/UNMAP Якщо пристрій NVMe не підтримує NVMe-еквівалент запису нулів або unmap, це може вплинути на продуктивність. Ніхто

Міграції

Цей етап включає в себе кроки з міграції сховища даних з SCSI на NVMe.

Вимкніть усі віртуальні машини та скасуйте реєстрацію

Вимкніть живлення та скасуйте реєстрацію всіх віртуальних машин, розміщених у сховищі даних для міграції. Обов'язково не видаляйте їх, а лише зніміть з реєстрації.

Демонтувати том VMFS з усіх хостів

Від'єднайте том VMFS від усіх хостів ESXi, коли всі віртуальні машини будуть зняті з реєстрації. Це зроблено для того, щоб він не використовувався під час перевірки узгодженості та міграції. 

Перевірте узгодженість метаданих гучності VMFS.

Перш ніж ініціювати міграцію, перевірте узгодженість метаданих VMFS на диску. Це гарантує відсутність невідповідностей перед початком.

  1. Бігти VOMA (VMware On-Disk Metadata Analyzer) у режимі перевірки запустивши:
voma -m vmfs -f check -d /vmfs/devices/disks/<DEVICE>:<PARTITION> -s <OUTPUT FILE>


Де:
DEVICE — це пристрій SCSI, на якому розміщено том VMFS6, який мігрується.
PARTITION — це номер розділу, на якому відформатовано том VMFS на пристрої.
OUTPUT FILE – це абсолютний шлях до файлу, в якому має бути збережено виведені дані команди. Цей файл може бути розташований у /tmp якщо у ньому достатньо місця або будь-якого тому VMFS, відмінного від того, який переноситься.

Наприклад:

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



Вихідні дані повинні виглядати приблизно так:
 

[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


Примітка: Якщо команда отримує наступну помилку, то VMFS не демонтована належним чином:

VOMA не вдалося перевірити пристрій: Пристрій або ресурс зайняті

  1. Проаналізуйте вихідний файл, щоб побачити, чи немає невідповідностей у метаданих, про які повідомляє voma. Якщо такі є, то їх необхідно усунути за допомогою запуску voma у розширеному режимі виправлення, перш ніж продовжити. Нижче наведено приклад:
[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

 

  1. Збирайте та зберігайте дамп метаданих VMFS. Це буде потрібно, якщо на наступних кроках будуть виявлені будь-які невідповідності метаданих. 

Будь ласка , перегляньте https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.htmlЦе гіперпосилання веде вас на веб-сайт за межами Dell Technologies. для отримання більш детальної інформації про використання voma в режимі Check, Advanced Fix mode або Dump Mode.

Від'єднання SCSI LUN від хостів ESXi

Від'єднайте SCSI LUN від кожного хоста ESXi у ВК. Докладні кроки дивіться в статті КБ https://kb.vmware.com/s/article/2004605Це гіперпосилання веде вас на веб-сайт за межами Dell Technologies..

Зупиніть представлення SCSI LUN з масиву.

Кроки для скасування представлення SCSI LUN є специфічними для масиву зберігання. Клієнти повинні ознайомитися з документацією, що стосується масиву, щодо процедури.

Представте пристрій як NVMe одному хосту ESXi.

Кроки для повторного представлення пристрою за допомогою NVMe залежать від масиву зберігання. Клієнти повинні ознайомитися з документацією, що стосується масиву, щодо процедури. 

Запустіть повторне сканування пристрою на хості.

Як тільки пристрій представлено хосту ESXi за допомогою NVMe, виявлення зазвичай відбувається негайно. Однак, якщо пристрій не відображається, повторно відскануйте один або кілька адаптерів за допомогою vSphere UI або CLI:
 

esxcli storage core adapter rescan -a

Перевірте узгодженість метаданих гучності VMFS після перетворення.

На хості ESXi, який має доступ до пристрою, ще раз запустіть voma в режимі перевірки, щоб перевірити, що метадані VMFS на диску все ще узгоджені. Будь-які невідповідності метаданих мають бути досліджені, перш ніж продовжити. 
Voma використовує команду резерву SCSI-2 для блокування пристрою, щоб запобігти будь-якому одночасному доступу або зміні гучності VMFS, коли сеанс voma активний. Однак пристрої NVMe не підтримують еквівалент резервування SCSI-2. Щоб обійти це, користувач повинен передати «-N" на VOMA коли серверним пристроєм є NVMe. Наприклад:

  • Запустіть VOMA (VMware On-Disk Metadata Analyzer) у режимі перевірки, виконавши:
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


Виберіть номер з 0-1:
Це означає, що користувач несе відповідальність за запобігання одночасному монтуванню або доступу до гучності з інших хостів під час поточної сесії voma. Якщо кроки, описані тут, були дотримані, а пристрій було відображено та виявлено лише на одному хості ESXi, то продовжувати слід безпечно. Користувач повинен ввести «0» у підказці, щоб продовжити роботу з режимом перевірки voma. Наведемо приклад:
 

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


Запуск VMFS Checker версії 2.1 у режимі
перевірки Ініціалізація метаданих LVM, Основні перевірки виконані
Перевірка активності
файлової системи Підтримка резервування відсутня для пристроїв NVMe st активність (4096 байт/HB, 1024 HB).                                 \

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


 

Повторне підписання тому VMFS 

Тепер, коли пристрій представлено як NVMe, необхідно оновити підпис, який знаходиться на сховищі даних. Це пов'язано з тим, що поточна сигнатура частково базується на WWN пристрою під час представлення за допомогою SCSI. Оскільки ідентифікатор пристрою NVMe відрізняється, має бути створено новий підпис. Тому на тому ж хості ESXi, який використовувався на попередніх двох кроках, запустіть наступне, щоб повторно підписати том:

  1. Незважаючи на зайве, перескануйте файлову систему, виконавши команду:

Повторне сканування файлової системи сховища esxcli

  1. Далі виконайте наступну команду, щоб отримати список LUN знімків VMFS:

Список

знімків vmfs сховища esxcli Нещодавно представлений пристрій NVMe повинен бути присутнім, хоча залежно від оточення можуть бути й інші знімки, не пов'язані з цим процесом.

  1. Повторно підписайте том VMFS, виконавши наступне:
esxcli storage vmfs snapshot resignature --volume-label=<label>|–volume-uuid=<id> 

 

Приклад наведено нижче:

[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

Перейменування сховища даних VMFS (необов'язково)

Коли том VMFS повторно підписується, мітка тому VMFS має префікс "snap", за яким слідує буквено-цифровий рядок. Наприклад, сховище даних VMFS на попередньому кроці тепер має назву: snap-5c42a2bc-Temp_Datastore. Якщо потрібно, перейменуйте сховище даних назад на оригінальне ім'я, видаливши префікс.

Перевірте узгодженість метаданих гучності VMFS після повторного підпису.

Ще раз перевірте, чи метадані VMFS на диску узгоджені після повторного підпису. Запустіть voma в режимі перевірки гучності VMFS. Дивіться розділ 2.8 для командного рядка voma, який повинен включати прапорець "-N". Перевірте, чи не повідомляє voma про будь-які невідповідності. Продовжуйте, якщо voma не повідомляє про будь-які помилки. 

Представте пристрій як NVMe для всіх хостів ESXi у кластері.

Якщо на жодному з попередніх кроків не виникло проблем, пристрій тепер можна представити за допомогою NVMe всім хостам ESXi у кластері. Як уже зазначалося, NVMe-пристрої розпізнаються відразу, але якщо не пересканувати адаптери через vSphere UI або CLI. Переконайтеся, що том VMFS6 змонтовано та доступно на всіх хостів.

Зареєструйтесь та увімкніть усі віртуальні машини

Зареєструйте всі віртуальні машини, розміщені в сховищі даних, і увімкніть їх. Переконайтеся, що віртуальні машини успішно ввімкнулися та мають доступ до vmdks. Як найкраща практика, користувач може зареєструвати та увімкнути віртуальні машини на одному ESXi. Після успіху їх можна буде перенести на інші хостинги.

Примітка: Під час увімкнення віртуальних машин з інтерфейсу vCenter UI може з'явитися спливаюче вікно, подібне до того, що показано нижче. Це запропонує користувачеві записати, чи була скопійована або переміщена віртуальна машина. Виберіть «Я його скопіював» у спливаючому вікні.

Відповідь на запитання під час клонування. 

Після міграції

Перевірте, чи не вплинули на будь-які ключові функції, і виконайте будь-яке очищення, якщо потрібно. 

 

その他の情報

Це офіційно перевірений VMware процес міграції автономного сховища даних. Онлайн-міграцію окремих віртуальних машин можна здійснити за допомогою Storage vMotion. VMware не має окремої КБ для цього процесу.

対象製品

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 ...
文書のプロパティ
文書番号: 000213232
文書の種類: How To
最終更新: 14 3月 2025
バージョン:  2
質問に対する他のDellユーザーからの回答を見つける
サポート サービス
お使いのデバイスがサポート サービスの対象かどうかを確認してください。