Етапи міграції 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
- Огляд
- Масштаб
- Етапи міграції в автономному режимі
- Передміграція
- Перевірте як кількість пристроїв, так і шляхи до кожного хоста ESXi 3
- Перевірте наявність непідтримуваних функцій 4
- Перевірте потенційний вплив постміграції на підтримувані функції 4
- Міграції
- Демонтувати том VMFS з усіх хостів 5
- Перевірте узгодженість метаданих гучності VMFS. 5
- Повторне підписання 10-го тому VMFS
- Перейменування сховища даних VMFS (необов'язково) 11
- Перевірте узгодженість метаданих гучності VMFS після повторного підпису. 11
- Представте пристрій як NVMe для всіх хостів ESXi у кластері 11
- Зареєструйте та увімкніть усі віртуальні машини 11
- Після міграції. 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 -
Перевірте, чи є такі
vmdkбудь-якої віртуальної машини в обраному сховищі даних використовується як RDM (фізична або віртуальна)Якщо віртуальна машина у вибраному сховищі даних має RDM у режимі SCSI, то їй не можна дозволити мігрувати на NVMe. Немає команди VMware для визначення, чи має віртуальна машина RDM, однак плагін Dell VSI вказує тип диска для кожної віртуальної машини. Нижче наведено скріншот перегляду у VSI, на якому вказано, чи мають якісь віртуальні машини (ім'я виконання) RDM.
Якщо віртуальна машина має RDM, то перед міграцією її потрібно видалити з віртуальної машини, перетворити, або перемістити її в інше сховище даних.
-
1.3 Перевірте відповідність правил/налаштувань претензій на пристрій, на якому розміщено сховище даних VMFS
Якщо перед міграцією на пристрої SCSI є якісь правила користувацького вимоги, вони, швидше за все, не будуть застосовані до пристрою під час використання NVMe. Пристрої NVMe не представлені окремими полями постачальника та моделі, якщо доступ до них здійснюється за запитом. Поля знаходяться разом, і тому необхідне нове правило вимоги, якщо ви цього хочете. Крім того, правила подання вимог, засновані на ідентифікаторах пристроїв, наприклад, World Wide Name (WWN), не спрацюють, оскільки ідентифікатор SCSI та ідентифікатор NVMe відрізняються.
За замовчуванням VMware вимагатиме нещодавно представлені пристрої NVMe з плагіном шляху за замовчуваннямHPP. -
Перевірте як кількість пристроїв, так і шляхи до кожного хоста ESXi
NVMe підтримує менше пристроїв і шляхів, ніж SCSI, до кожного хоста ESXi. Якщо кількість пристроїв SCSI перевищує межі NVMe, конвертувати всі сховища даних на одному хості ESXi неможливо. Як рішення, клієнти можуть використовувати більше хостів ESXi або консолідувати сховища даних до або після перетворення за допомогою Storage vMotion.
- SCSI - 1024 пристроїв/4096 шляхів
- NVMe - 256 пристроїв/2048 шляхів
-
Перевірте наявність непідтримуваних функцій
Деякі функції 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 на диску. Це гарантує відсутність невідповідностей перед початком.
- Бігти
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 Не вдалося перевірити пристрій: Пристрій або ресурс зайняті
- Проаналізуйте вихідний файл, щоб побачити, чи немає невідповідностей у метаданих, про які повідомляє
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
- Збирайте та зберігайте дамп метаданих VMFS. Це буде потрібно, якщо на наступних кроках будуть виявлені будь-які невідповідності метаданих.
Будь ласка , перегляньте https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html для отримання більш детальної інформації про використання
voma в режимі Check, Advanced Fix mode або Dump Mode.
Від'єднання SCSI LUN від хостів ESXi
Від'єднайте SCSI LUN від кожного хоста ESXi у ВК. Докладні кроки дивіться в статті КБ https://kb.vmware.com/s/article/2004605 .
Зупиніть представлення 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, який використовувався на попередніх двох кроках, запустіть наступне, щоб повторно підписати том:
- Незважаючи на зайве, перескануйте файлову систему, виконавши команду:
esxcli storage filesystem rescan
- Далі виконайте наступну команду, щоб отримати список LUN знімків VMFS:
esxcli storage vmfs snapshot list
Нещодавно представлений пристрій NVMe повинен бути присутнім, хоча в залежності від оточення можуть бути й інші знімки, не пов'язані з цим процесом.
- Повторно підписайте том 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.
Якщо віртуальна машина має 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.
- SCSI - 1024 пристроїв/4096 шляхів
- 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 на диску. Це гарантує відсутність невідповідностей перед початком.
- Бігти
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 не вдалося перевірити пристрій: Пристрій або ресурс зайняті
- Проаналізуйте вихідний файл, щоб побачити, чи немає невідповідностей у метаданих, про які повідомляє
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
- Збирайте та зберігайте дамп метаданих VMFS. Це буде потрібно, якщо на наступних кроках будуть виявлені будь-які невідповідності метаданих.
Будь ласка , перегляньте https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html для отримання більш детальної інформації про використання
voma в режимі Check, Advanced Fix mode або Dump Mode.
Від'єднання SCSI LUN від хостів ESXi
Від'єднайте SCSI LUN від кожного хоста ESXi у ВК. Докладні кроки дивіться в статті КБ https://kb.vmware.com/s/article/2004605.
Зупиніть представлення 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, який використовувався на попередніх двох кроках, запустіть наступне, щоб повторно підписати том:
- Незважаючи на зайве, перескануйте файлову систему, виконавши команду:
Повторне сканування файлової системи сховища esxcli
- Далі виконайте наступну команду, щоб отримати список LUN знімків VMFS:
Список
знімків vmfs сховища esxcli Нещодавно представлений пристрій NVMe повинен бути присутнім, хоча залежно від оточення можуть бути й інші знімки, не пов'язані з цим процесом.
- Повторно підписайте том 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 може з'явитися спливаюче вікно, подібне до того, що показано нижче. Це запропонує користувачеві записати, чи була скопійована або переміщена віртуальна машина. Виберіть «Я його скопіював» у спливаючому вікні.
Після міграції
Перевірте, чи не вплинули на будь-які ключові функції, і виконайте будь-яке очищення, якщо потрібно.