Митап «Виртуализация на отечественном»

Эксперты «Инфосистем Джет», которые уже успели поработать с основными отечественными решениями по серверной виртуализации, поделились впечатлениями и дали оценку готовности этих решений заменить западные аналоги.

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

  • 00:00:00 Интро
  • 00:01:47 Дмитрий Горохов, начальник отдела серверных решений и виртуализации «Инфосистемы Джет» — Общий обзор рынка отечественной виртуализации, технические подробности по продуктам zVirt, ECP VEIL, Альт Сервер Виртуализации, БРЕСТ
  • 00:59:25 Всеволод Козинов, независимый эксперт — Что важно знать заказчикам (и не только) об отечественных продуктах по виртуализации
  • 01:26:38 Алексей Рогожин, технический эксперт «Инфосистемы Джет» — Live demo zVirt
  • 01:53:48 Илья Марченко, технический эксперт «Инфосистемы Джет» — Live demo ECP VEIL
  • 02:08:59 Сергей Коняшкин, руководитель эксплуатации ИТ одного банка, Дмитрий Горохов, Всеволод Козинов — Применение отечественных решений по виртуализации в Enterprise

Релиз VMware vSphere 7.0 Update 3f/g

Компания VMware выпустила в середине июле vSphere 7.0 Update 3f, а уже через несколько дней выпустила исправление vCenter 7.0 Update 3g.

По моим ощущениям, это первый релиз vSphere 7.0 Update 3, подходящий для продуктивных сред. Для понимания болячек и исправлений пришло время выпустить свежий обзор KB, предыдущие – Релиз VMware vSphere 7.0 Update 3с, Заметки в базе знаний VMware по платформе vSphere 7.0 Update 3:

Утилита самообслуживания VMware Lookup Service Doctor

Следующая утилита самообслуживания от VMware – Lookup Service Doctor aka lsdoctor.

В результатах диагностики с помощью Утилита самообслуживания VMware vSphere Diagnostic Tool вы  можете получить ссылку на lsdoctor:

Lookup Service Doctor (lsdoctor) – это скрипт, используемый для решения проблем с данными, хранящимися в базе данных PSC, а также с данными, локальными для vCenter (независимо от того, является ли PSC внешним или встроенным). Данный инструмент можно использовать для обнаружения и устранения проблем, которые могут привести к сбоям при изменении топологии (converge, repoint и т.д.), обновлении или сбоям, возникшим в результате технического обслуживания (например, неправильное применение новых SSL-сертификатов).

Прежде чем использовать lsdoctor для внесения каких-либо изменений, убедитесь, что вы сделали надлежащие снимки вашего домена SSO. Это означает, что вы должны одновременно выключить все VC или PSC, которые находятся в домене SSO, затем сделать снимки и снова включить их. Если вам нужно вернуться к одному из этих снимков, выключите все узлы и верните все узлы к снимку. Невыполнение этих шагов приведет к проблемам репликации между базами данных PSC.

Утилита предназначена для использования с vCenter 6.5 и новее. Скачивается из KB Using the ‘lsdoctor’ Tool (80469), тут же размещены подробные инструкции по использованию. Затем распаковывается и заливается на vCenter, запускается справка из папки lsdoctor-master:

Выведутся ключи программы:

Предназначение ключей программы: Continue reading “Утилита самообслуживания VMware Lookup Service Doctor”

Утилита самообслуживания VMware vSphere Diagnostic Tool

В настоящее время наблюдаются затруднения с получением технической поддержки по продуктовой линейке VMware на одной восьмой части суши.

Соответственно, для диагностики и решения проблема приходится переходить на самообслуживание.

Ранее была опубликована статья Утилита самообслуживания VMware Skyline Health Diagnostic Tool, рассказывающая о ВМ с набором тестов и анализом логов vSphere, vSAN, VMware Cloud Foundation.

Теперь мне на глаза попалась прекрасная утилита самообслуживания vSphere Diagnostic Tool.

vSphere Diagnostic Tool – это скрипт на языке python, который выполняет диагностические команды на vCenter Server Photon Appliance для получения полезных данных по устранению неполадок, работая в пределах локальной среды без внешних зависимостей. Скрипт проверяет чеклист и выдает Pass/Warning/Fail для быстрой изоляции проблем, возникающих в среде vSphere.

Данный скрипт протестирован группой сотрудников службы поддержки GS VMware и представляет собой набор самостоятельных сценариев на python и bash, которые могут выполнять следующие тесты для vCenter Server Appliance 6.5 или более новой версии:

  • vCenter Basic Info
  • Lookup Service Check
  • AD Check
  • vCenter Certificate Check
  • Core File Check
  • Disk Check
  • vCenter DNS Check
  • vCenter NTP Check
  • vCenter Port Check
  • Root Account Check
  • vCenter Services Check
  • VCHA Check

Кроме выдачи статуса Pass/Warning/Fail для каждого теста, также указываются KBs или другие источники знаний для результатов Warning и Fail, что обеспечивает следующие шаги для решения проблемы. Continue reading “Утилита самообслуживания VMware vSphere Diagnostic Tool”

Прекращение поддержки устройств в 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 (хе-хе, у нас почему-то установщик продлил сертификат).