Author: Mister Nobody

Прекращение поддержки устройств в VMware ESXi 8.0

Компания VMware анонсировала список оборудования, который снимается с поддержки в ESXi 8.0 – Devices deprecated and unsupported in ESXi 8.0 (88172).

Поддержка ряда устройств ввода-вывода была удалена в ESXi 8.0 в связи с тем, что эти устройства были сняты с производства производителями. Эти устройства не будут перечислены в руководстве по совместимости ESXi 8.0 VMware, а VMware GSS не будет принимать запросы на поддержку проблем клиентов, связанных с этими устройствами в версии 8.0.

Хотя эти устройства не поддерживаются в ESXi 8.0, поддерживающие их драйверы устройств все равно будут установлены на хост ESXi 8.0 при обновлении, и устройства будут распознаваться, за следующими исключениями:

  • все устройства, ранее поддерживаемые драйвером nmlx4_en. Этот драйвер не существует в ESXi 8.0.
  • часть устройств, ранее поддерживаемых драйвером lpfc. Эти устройства были удалены из драйвера (например, повсеместно использующиеся Emulex LPe1205/1250, LPe 1200x).

Если выполнить обновление хоста до ESXi версии 8.0 с устройством, поддерживаемым драйвером nmlx4_en, или устройством, удаленным в драйвере lpfc, могут возникнуть следующие неисправимые последствия:

  • потеря доступа к хранилищам данных
  • потеря доступа к сети
  • потеря предыдущей конфигурации на хосте.

Перед обновлением до ESXi 8.0 необходимо заменить устройства, ранее поддерживаемые драйвером nmlx4_en, или устройства, которые были удалены в драйвере lpfc версии 8.0. Другие устройства, не поддерживаемые в ESXi 8.0, следует заменить при первой же возможности, чтобы не допустить разрыва в поддержке.

Полный список устройств, которые больше не поддерживаются в ESXi 8.0.

P.S. Также стоит обратить внимание на прекращение поддержки:

Тестирование систем хранения данных Huawei Dorado V6 в кластере HyperMetro

Disclaimer:  все дальнейшие рассуждения, настройки и выбранные методы тестирования могут быть ошибочны. Никакого отношения к компаниям Lenovo, Huawei, Broadcom мы не имеем.

Цели тестирования:

  • определить производительность системы хранения данных (СХД) в кластере HyperMetro и её изменение при различных вариантах отказа оборудования;
  • оценить влияние на производительность и доступность программно-аппаратного комплекса (ПАК) фирменного MPIO-драйвера (драйвер балансировки подключения по нескольким путям ввод-вывода) Huawei Ultrapath;
  • протестировать функциональность SmartVirtualization СХД Huawei Dorado 5000V6 – способность выдавать через себя дисковые разделы других СХД.

Дополнительно была проведена проверка работоспособности одного из серверов системы управления базами данных (СУБД) Oracle DB при отказе узла кластера HyperMetro. Для этого сервер был временно перенесён в кластер HyperMetro без прерывания его работы, а по окончании тестирования возвращён обратно.

Оборудование было предоставлено системным интегратором,  который также составил и выполнил программу и методику испытаний. Тестирование осуществлялось при помощи программы VDBench, имитировалась нагрузка, аналогичная создаваемой основным сервером СУБД Oracle DB в ежедневной эксплуатации. Профиль  нагрузки  приведён  в Приложении 1.

Для проведения тестирования был собран стенд, имитирующий размещение оборудования в двух пространственно-разнесённых центрах обработки данных, установлено и настроено программное обеспечение (ПО) и развёрнуты тестовые виртуальные машины. Схема стенда и описание используемого ПО приводятся в Приложении 2.

Первичное конфигурирование системы проводилось с использованием штатных MPIO-драйверов среды виртуализации VMware ESXi. Драйвер оказывает решающее влияние на производительность системы и её отказоустойчивость, поэтому было проведено две серии тестов – со штатными драйверами VMware, и с фирменными драйверами Huawei Ultrapath от изготовителя СХД. Перед началом тестирования выживаемости кластера при различных вариантах отказов оборудования и влияние отказов на производительность был выполнен эталонный замер производительности системы в штатном режиме работы. Методика замера и результаты приведены в Приложении 3.

После определения исходного уровня производительности системы, была выполнена оценка изменения производительности при отказе удалённой системы хранения (Приложение 4), локальной системы хранения (Приложение 5) и дирижёра кластера (Quorum Server). С целью проверки выживаемости, в тестовую среду был мигрирован сервер СУБД Oracle DB (DEV03). Оценивалось влияние на работоспособность и доступность сервера  отказ одной из реплик хранилища. Результаты приведены в Приложении 6.

Следующим этапом стала оценка влияния на производительность и доступность системы использование MPIO-драйвера Huawei Ultrapath. В процессе подготовки стенда выяснилось, что драйвер существует только для версии VMware ESXi 6.7U3, а на стенде развёрнута VMware ESXi 7. Для проведения работ был подготовлен и подключен новый сервер с требуемой версией ESXi, описание стенда приведено в Приложении 7.

Поскольку среда поменялась, были проведены замеры производительности системы в штатном режиме (Приложение 8). Затем выполнены замеры производительности при отказе удалённого хранилища (Приложение 9) и локального (Приложение 10).

После проведения серии опытов по определению производительности работы и отказоустойчивости кластера, была выполнена оценка функционала виртуализации СХД (SmartVirualization) и сделаны замеры производительности работы системы при прямом подключении к серверу раздела СХД  EMC VNX5700 и подключении его через функцию виртуализации СХД Huawei Dorado 5000 V6. Схема стенда и результаты тестирования приведены в Приложении 11.

Дополнительно была выполнена оценка влияния процесса создания и удаления моментальных снимков (снапшотов, snapshots) виртуальных машин (ВМ) на производительность работы ВМ при использовании традиционных томов VMFS (Приложение 12), при использовании виртуальных томов VVOL (Приложение 13), а также влияние на производительность процедуры установки обновлений управляющего ПО СХД (Приложение 14).

Краткое резюме по этапам тестирования производительности приведено в таблице: Continue reading “Тестирование систем хранения данных Huawei Dorado V6 в кластере HyperMetro”

Стек хранения в VMware vSphere 7 и 8+

Приятно получать обратную связь от наших читателей. Николай Куликов уточнил ситуация со стеком хранения в текущей и перспективной версией VMware vSphere. Особый интерес представляет архитектура и компоненты стремительно распространяющего протокола NVMe, включая NVMe over Fabric (NVMe-oF).

В соответствии с Basic VMware NVMe Architecture and Components:
В средах NVMe-oF цели могут представлять пространства имен, эквивалентные LUN в SCSI, хосту в active/active или асимметричном режимах доступа. ESXi [7.0] может обнаруживать и использовать пространства имен, представленные любым из этих режимов. ESXi [7.0] внутренне эмулирует цели NVMe-oF как цели SCSI и представляет их как active/active цели SCSI или неявные цели ALUA SCSI.

Изменения в архитектуре можно увидеть на следующих схемах. Continue reading “Стек хранения в VMware vSphere 7 и 8+”

Тестирование СХД Lenovo ThinkSystem DE6000F по протоколу передачи NVMe over FC

Disclaimer:  все дальнейшие рассуждения, настройки и выбранные методы тестирования могут быть ошибочны. Никакого отношения к компаниям Lenovo, NetApp, Broadcom мы не имеем.

Вступление

Осенью 2021 года в наши загребущие ручонки попала система хранения данных (СХД) Lenovo ThinkSystem DE6000F с внутренней поддержкой протокола передачи NVMe и установленными дисками SAS SSD. Система также позволяет использовать протокол NVMe в среде сети хранения данных (SAN, Storage Area Network). Поскольку это вторая система хранения такого типа в наших руках, то решено подключить её к SAN по протоколу NVMe over FC (NVMe/FC) и проверить, реализуются ли на практике теоретические преимущества протокола NVMe.  Чтобы переключить СХД на использование нового протокола, на сайте Lenovo FOD получена соответствующая лицензия. СХД не может одновременно использовать несколько протоколов в одной среде передачи, поэтому включение протокола NVMe/FC приводит к отключению возможности работы по протоколу FC. Соответственно, СХД пропадает из зоны доступности серверов, FC-адаптеры которых не могут работать с новым протоколом.  Из имеющихся для стендирования серверов поддержку NVMe over FC «из коробки» имеют серверы Lenovo ThinkServer SR650 c 32-гигабитными FC-адаптерами и серверы Lenovo ThinkServer SR630 с 16 -гигабитными FС-адаптерами после обновления прошивок и драйверов FC-адаптеров. Continue reading “Тестирование СХД Lenovo ThinkSystem DE6000F по протоколу передачи NVMe over FC”

Хосты VMware ESXi не переходят в режим обслуживания

Столкнулись с прекрасной ситуацией – надо обновить хосты, а они не уходят в режим обслуживания (Maintenance).

Разбор лога vpxd.log  указал на проблемы со службой WCP (Workload Control Plane):

2022-08-04T04:48:07.990Z warning vpxd[10191] [Originator@6876 sub=MoHost opID=l39uvjin-8399622-auto-5016v-h5:70917492-ff] [Invoke] Host ‘localhost’ Failed to acquire Session: N3Vim5Fault12InvalidLogin9ExceptionE(Fault cause: vim.fault.InvalidLogin
–> )
–>[context]zKq7AVECAQAAAJCaGQEZdnB4ZAAAcnY0bGlidm1hY29yZS5zbwAAAaopAAmfKgBDaS8BX6dfdnB4ZAABK3ltAXn/0QFiSmUBKE9lAS5UZQFk+WcBHA1oAVEcaAKnuPZsaWJ2aW0tdHlwZXMuc28Agf8vKgGBEIooAYGyxSgBgVvVKAGB92AoAYE0NikBAOFBIADynSAARgU0A4d/AGxpYnB0aHJlYWQuc28uMAAEvzUPbGliYy5zby42AA==[/context] 2022-08-04T04:48:07.995Z info vpxd[10191] [Originator@6876 sub=MoHost opID=l39uvjin-8399622-auto-5016v-h5:70917492-ff] WCP enterMaintenanceMode vAPI returns error: Error:
–> com.vmware.vapi.std.errors.unauthenticated
–> Messages:
–> vapi.security.authentication.invalid<Unable to authenticate user>

При диагностике отработали 3 варианта (от простого к сложному):

  1. Служба остановлена. Случай не наш, но достаточно стартнуть службу в VAMI либо в консоли VCSA. Диагностика:
  2. Ошибка в настройке порта.
    1. Создать снимок [выключенного] vCenter.
    2. Сделать резервную копию /etc/vmware/wcp/wcpsvc.yaml командой:
    3. Исправить указание порта rhttpproxy_port: {rhttpproxy.ext.port2} в yaml-файле на rhttpproxy_port: 443
    4. Запустить службу WCP командой:
  3. Проблема с сертификатом.
    1. Запускаем скрипт:
    2. Находим строки – что сертификат протух:

      Примечание: могут быть и другие поломки сертификатов, тогда смотрим KB “com.vmware.vapi.std.errors.unauthenticated” and “vapi.security.authentication.invalid” errors for the WCP service causing multiple workflow failures (88508).
    3. Чиним через менеджер сертификатов либо выполняем обновление vCenter (хе-хе, у нас почему-то установщик продлил сертификат).

Расширенное управление сертификатами VMware vCenter

Для управления сертификатами в VMware vCenter есть простейший графический интерфейс и более полноценный vSphere Certificate Manager, работающий в командной строке.

Технической поддержке VMware доступна расширенная версия данной утилита, которая недавно утекла в интернет с такими функциями в меню:

  1. Check current certificates status
  2. Check CA certificates in VMDir and VECS
  3. View Certificate Info
  4. Generate certificate report
  5. Check SSL Trust Anchors
  6. Update SSL Trust Anchors
  7. Replace the Machine SSL certificate
  8. Replace the Solution User certificates
  9. Replace the VMCA certificate and re-issue Machine SSL and Solution User certificates
  10. Replace the Authentication Proxy certificate
  11. Replace the Auto Deploy CA certificate
  12. Replace the VMware Directory Service certificate
  13. Replace the SSO STS Signing certificate(s)
  14. Replace all certificates with VMCA-signed certificates
  15. Clear all certificates in the BACKUP_STORE in VECS
  16. Check vCenter Extension thumbprints
  17. Check for SSL Interception
  18. Check STS server certificate configuration
  19. Check Smart Card authentication configuration
  20. Restart reverse proxy service
  21. Restart all VMware services

Копия с исправлениями переноса строк для Linux доступна тут.

Также рекомендую статью от Navion – Продлеваем сертификаты vCenter правильно.

Потеря доступности LUN-ов и VMFS-томов на хранилищах с прямым FC-подключением после обновления до vSphere 7.0 Update 3

После обновления хостов до ESXi 7.0 Update 3f получили замечательную вещь – диски и тома на них, подключенные к системе хранения данных напрямую (Direct-Attached FC) исчезли на серверах напрочь.

Диагностика проблемы выявила, как минимум, две возможных ситуации:

  1. Кривой драйвер в составе дистрибутива –  qlnativefc 4.1.14.0-26vmw.703.0.20.19193900. Пересобрали образ с самой новой версией 5.1.68.0-1OEM.703.0.0.18644231 и проблема у нас ушла.
  2. Начиная с версии vSphere 7.0 Update 3, драйвер brcmnvmefc больше не доступен. Функциональность NVMe over FC, ранее реализованная в  brcmnvmefc, теперь включена в драйвер lpfc.Чтобы включить поддержку только протокола SCSI в драйвере lpfc, установите lpfc_enable_fc4_type=1.
    Чтобы включить поддержку протоколов SCSI и NVMe, установите lpfc_enable_fc4_type=3.

    1. Переведите хост ESX в режим обслуживания
    2. Включите SSH-доступ к хосту ESX и подключитесь к хосту ESXi от имени root.
    3. Используйте следующую команду esxcli, чтобы отключить поддержку FC-NVMe в драйвере lpfc:
      esxcli system module parameters set -m lpfc -p lpfc_enable_fc4_type=1
    4. Перезагрузите хост ESXi для завершения изменений.

Руководство по синтетическому бенчмаркингу корпоративных систем хранения данных и лучшие практики. Часть 3. Практическая иллюстрация на примере бенчмаркинга VMware vSAN

Николай Куликов опубликовал своё руководство по тестированию систем хранения на английском языке, поэтому захотелось получить русский вариант. Данный перевод выполнен ИИ с моими правками (возможны правки формулировок).

Сценарий и определение целей
ВМ-испытатели
Размер виртуального диска и общее использование ёмкости
Тесты воздействия на производительность набора активных рабочих нагрузок
Анализ влияния продолжительности тестирования и прогрева
Тестирование влияния OIO
Лимиты IOPS
Результаты тестирования
Заключение
Особая благодарность
Приложение A

Что ж, давайте пройдемся по пунктам, изложенным в первой и второй частях, и рассмотрим пример того, как может выглядеть сквозное тестирование.

Как я уже говорил, всегда стоит начинать с определения целей и задач. Истинная цель дальнейших бенчмарков – продемонстрировать на конкретном примере процесс проведения тестирования, а также проиллюстрировать влияние отдельных параметров на результаты теста. Чтобы сделать это ближе к реальности, давайте придумаем некую гипотетическую, но все же реалистичную ситуацию. Continue reading “Руководство по синтетическому бенчмаркингу корпоративных систем хранения данных и лучшие практики. Часть 3. Практическая иллюстрация на примере бенчмаркинга VMware vSAN”

Руководство по синтетическому бенчмаркингу корпоративных систем хранения данных и лучшие практики. Часть 2. Критерии успеха и параметры бенчмаркинга

Николай Куликов опубликовал своё руководство по тестированию систем хранения на английском языке, поэтому захотелось получить русский вариант. Данный перевод выполнен ИИ с моими правками (возможны правки формулировок).

Определение критериев успеха для синтетического бенчмаркинга
Исходные данные и вводные
Сбор метрик из существующих систем
Список параметров, которые необходимо определить

Заключение

Определение критериев успеха для синтетического бенчмаркинга

Как я уже упоминал в первой части руководства, определение целей и критериев успеха является обязательным шагом для успешного POC. Конечно, критерии успеха могут быть разными, но у них есть нечто общее – они должны следовать правилам S.M.A.R.T:

  • Конкретность – цель должна быть конкретной и ясной для всех, кто участвует в тестировании. Не должно быть никаких разночтений, двусмысленных толкований или “само собой разумеется”.
  • Измеримость – это означает, что существует метрика или число, которое может однозначно определить прохождение/непрохождение или результат A лучше, чем B.
  • Достижимость – требования должны быть реалистичными и достижимыми (хотя бы теоретически) для каждого участника. В противном случае нет смысла тратить на это время.
  • Релевантность – здесь это самый важный пункт. Вы должны быть в состоянии прояснить и очень четко показать, почему были выбраны именно такие цели и метрики. Как они связаны с потребностями бизнеса? Почему именно эта метрика или число, а не другая? И будьте осторожны со ссылками на “отраслевые стандарты”, “вот как мы делали это раньше”, “опыт других компаний”. Слишком легко ошибиться и потерять релевантность вашим конкретным бизнес-потребностям.
  • Ограниченность во времени – в вашем плане POC должны быть четко и заранее определены временные рамки и сроки.

Цели, а также подробная контрольная программа (описывающая, как именно будут проводиться тесты) должны быть написаны ДО начала POC и одобрены/подтверждены каждым участником.

Я также рекомендую отправить черновик программы участникам, часто они могут дать полезные советы, рекомендации или комментарии, а также для того, чтобы они были готовы. А также быть на связи с производителями/партнерами в процессе бенчмаркинга, особенно, если есть какие-то проблемы или система не смогла достичь поставленных целей. Часто эти проблемы можно легко решить, просто правильно настроив и отрегулировав систему.

Упрощенный пример критерия успеха может выглядеть следующим образом: “Задержка в гостевых ОС, работающих на системе хранения данных в нормальных условиях и полностью рабочем состоянии, должна быть менее 1,5 мс при 95-м процентиле при обеспечении 100 тыс. IOPS с профилем 8K 70/30 Чтение/Запись 90% Случайный доступ”. Рабочая нагрузка генерируется 12 ВМ с 5 виртуальными дисками в каждой, использование хранилища (общий объем данных, хранимых этими ВМ) должно составлять 70% от полезной ёмкости хранилища, размер набора активной рабочей нагрузки составляет 10%, продолжительность теста 2 часа после 1 часа прогрева”. Continue reading “Руководство по синтетическому бенчмаркингу корпоративных систем хранения данных и лучшие практики. Часть 2. Критерии успеха и параметры бенчмаркинга”

Руководство по синтетическому бенчмаркингу корпоративных систем хранения данных и лучшие практики. Часть 1. Общая теория, методы и подходы

Николай Куликов опубликовал своё руководство по тестированию систем хранения на английском языке, поэтому захотелось получить русский вариант. Данный перевод выполнен ИИ с моими правками (возможны правки формулировок).

Введение
Определение целей бенчмаркинга
Выбор подхода и методологии бенчмаркинга

Выбор инструментов и утилиты для синтетического бенчмаркинга хранилища данных
Формирование конфигурации демонстрационной среды

Заключение

Введение

За более чем десять лет работы в ИТ-индустрии я провел множество тестов и проверок концепций (proof-of-concepts, POC) различных систем хранения данных (СХД). Хотя это были совершенно разные типы систем хранения – традиционные SAN-системы хранения с подключением по FC, NAS, SDS (Software Defined Storage, программно-определяемое хранилище) и платформы HCI (Hyper Converged Infrastructure, гиперконвергентная инфраструктура), задачи были практически одинаковыми. И довольно часто я сталкивался с ситуацией, когда тесты никак не соответствовали потребностям бизнеса и даже были технически некорректны, что приводило к невозможности получить какие-либо значимые результаты.

Все мы знаем, насколько критически важными могут быть системы хранения данных для ИТ- и бизнес-операций. Мы также знаем, как много усилий требуется от всех вовлеченных сторон, чтобы правильно протестировать систему хранения и получить значимые результаты, способствующие процессу принятия решений. Именно поэтому я верю, что хорошо структурированный подход с полным вниманием к деталям является обязательным условием для любого вида тестирования и/или бенчмаркинга систем хранения данных.

В большинстве случаев валидация/POC систем хранения данных состоит из трех частей – тесты доступности, функциональные тесты и тесты производительности (они же бенчмаркинг):

  1. Функциональные тесты очень специфичны для конкретной организации, поскольку они должны быть согласованы с ИТ-ландшафтом заказчика, бизнес-процессами и другими отличительными аспектами.
  2. Тесты доступности требуют много времени, но это самая очевидная часть – заказчик должен составить список потенциальных рисков, описать ожидаемое поведение в каждом случае, определить с производителем/поставщиком/дистрибьютором варианты моделирования таких сценариев и выполнить такие тесты.
  3. Тесты производительности или бенчмаркинг – сложная и часто противоречивая часть плана тестирования, потому что это всегда баланс между применимостью и точностью против осуществимости и сложности.

В этом руководстве я рассмотрю только аспект тестирования производительности, и он будет связан в основном с синтетическим бенчмаркингом основной системы хранения общего назначения. Основная цель данного руководства – предоставить указания и рекомендации по проведению бенчмаркинга любого типа корпоративных систем хранения данных для получения значимых результатов при минимизации усилий. Я не буду много говорить об общих вещах, связанных с тестированием в целом и с организацией POC.

Это руководство состоит из двух частей – первая часть более универсальна и подходит практически для любой ситуации, когда вам необходимо провести синтетическое нагрузочное тестирование. Поэтому она состоит в основном из общих приемов, лучших практик и рекомендаций (хотя я постараюсь добавить больше примеров), а не из конкретных действий. Вторая часть – практическая и конкретная, где я на примере показываю, как можно проводить нагрузочное тестирование и как каждый из параметров нагрузочного тестирования влияет на результат.

Чтобы быть более конкретным и, по сути, отразить мой самый последний опыт, все дальнейшие примеры будут связаны с тестированием систем хранения данных в среде виртуальной инфраструктуры VMware.  Однако эти рекомендации могут быть применены и в других случаях с минимальными изменениями. Continue reading “Руководство по синтетическому бенчмаркингу корпоративных систем хранения данных и лучшие практики. Часть 1. Общая теория, методы и подходы”