Подключение NVMe SSD в VMWare

Предисловие. В этой статье речь пойдет про подключение NVMe дисков к VMware (внутреннего подключения к физическому серверу) . Понятно, что маркетологи убедили многих провайдеров и ИТ крупных компаний, что удобство администраторов важнее результата работы дисковой подсистемы для конечных пользователей. Поэтому статья может вызывать неприятие типа «а у нас корпоративная политика», «это не вписывается в нашу концепцию» и т.п.
Однако наша задача поделиться практическим опытом по решению конкретных проблем с конкретным оборудованием и для конкретной системы виртуализации, а пользоваться ли плодами статьи это личное дело каждого.

Также обращаю внимание, что проблема разбирается на конкретной модели Samsung 970 pro и VMWare 6.7. Не надо думать, что все виртуалки и все диски NVMe ведут себя одинаково и бездумно тиражировать текущий подход статьи  ко всему. В каждом конкретном случае надо проходить полный путь расследования, как в статье.

Проблема с дисковой производительностью

Ситуация: сервер 1С/СУБД, на котором наблюдаются существенные проблемы с производительностью дисковой подсистемы: время обслуживания дисковых операций исчисляется не единицами миллисекунд (как хотелось бы), не десятками (как ещё допустимо), а несколькими сотнями, причём это же видно и средствами операционной системы.

Выглядит это например вот так:

Открываем в Windows монитор ресурсов — наблюдаем аналогичную ситуацию и там (обратите внимание на колонку “время ответа”, значение в миллисекундах):

Первая реакция: такие показатели характерны для загруженного механического (дефакто медленного) диска.

 

Первые тесты

Дожидаемся технологического окна, когда службы 1С и СУБД можно полностью остановить, нагрузку с диска снимаем, и прогоняем тест CrystalDiskMark

Результаты выглядят вполне прилично для недорогого NVMe SSD (отклик должен быть около 10 мс, а не сотнями мс как у нас). Идём выяснять, что же там “под капотом”. Выясняем, что данные расположены на неплохом (для десктопа, не для сервера) NVMe SSD Samsung 970 Pro, который хоть и не “энтерпрайз класса”, но и вот настолько проседать под такой нагрузкой вроде как не должен.

Вот нормальный результат диска на физическом сервере для сравнения.
Идём разбираться дальше: сервер развёрнут на виртуальной машине на базе VMWare ESXi 6.7, SSD используется в “виртуализованном” виде:

Из диспетчера устройств виртуальной Windows устройство видно например так:

В данном виде гостевая операционная система видит SSD как некий сетевой массив, и управлять этим SSD не может (например, не передаётся команда TRIM). И явно для данного SSD это не является “комфортным” режимом работы. Попробуем это изменить.

 

Вносим изменения в конфигурацию

И вот здесь наступает пора внести изменения!

Первым делом бэкапим целиком содержимое используемого диска на какой-либо другой носитель, потому что следующий шаг включает в себя форматирование диска!

Затем идём в консоль ESXi хост-машины, где развёрнута наша система, и делаем следующее:

в консоли заходим в пункт Manage — Hardware, выбираем в списке нужное нам устройство, в данном случае Samsung NVMe SSD, и на его строчке жмём кнопку Toggle passthrough, чтобы в поле Passthrough надпись Disabled сменилась на Active. Это будет означать, что с текущего момента хост-система перестаёт отвечать за обслуживание данного устройства, это устройство можно будет передать внутрь виртуальной системе в его исходном виде, и дальше уже виртуальная система будет с ним работать напрямую. 

После этого изменения система вас предупредит, что потребуется рестарт хост-машины. Если на хост-машине работают и другие виртуалки — учитывайте это!

После рестарта хоста — снова заходим в консоль ESXi, заглянем в пункт Storage — Devices и убедимся, что наше устройство из списка пропало.

Далее идём в настройки конкретной виртуальной машины, нажимаем Edit settings — Add other device — PCI Device, и здесь выбираем нужный NVMe SSD Controller, жмём Save:

причём если попытаться добавлять путём Add other device — NVMe controller, то ничего не получится.

 

Что же изменилось?

Далее загружаем виртуальную ОС, и внутри наблюдаем вместо устройства с добавлением VMWare “родное” название устройства, рядом с двумя устройствами, для которых проброс не включен и которые продолжают обслуживаться средствами VMWare.

Теперь этот SSD надо заново отформатировать (мы использовали размер кластера 8 килобайт, так как именно таков размер страницы данных в MS SQL, а именно базы СУБД на этом диске и будут расположен).

И настала пора сравнить результаты тестов CrystalDiskMark:

Как видно из снимка — результаты заметно подросли по всем пунктам. Но главное — заметно выросли показатели в нижней строчке, чтение-запись блоками по 4 килобайта при глубине очереди в 32 операции, по сути именно она и похожа на характер многопоточной нагрузки на сервере СУБД.

Но теперь самое важное — как себя поведёт СУБД, будучи развёрнутой на этом диске. 

 

Итоговый результат

Разница оказалась весьма существенной, хороший десктопный (хоть и не серверный) SSD начал работать заметно лучше.

Результаты снимков монитора ресурсов “до и после” для удобства свели в одну картинку.

Обратите внимание, насколько ускорилось время ответа дисковой подсистемы, и при этом насколько увеличились объёмы чтения и записи. Оборудование сервера по факту не изменилось, но драматически выросла его производительность!

 

Вывод

Как минимум в данном сценарии, использование десктопного NVMe SSD в VMWare ESXi 6.7 в виртуализованном варианте приводило к существенному ухудшению производительности SSD, при этом “формальный” тест CrystalDiskMark мог выглядеть “вполне прилично” (если не сравнивать “в лоб” с показателями ровно такого же устройства, подключенного напрямую). Подключение же NVMe SSD напрямую в виртуализованную операционную систему привело к тому, что ОС смогла управлять диском напрямую (например, подавать команды TRIM), и производительность диска увеличилась и стала больше соответствовать  данной модели NVMe SSD.

смотрите также Про диски для 1С

Почему для NVMe дисков под 1С не нужны RAID-массивы

Подбираем хороший сервер

смотрите также http://www.gilev.ru/virtual/