Бета-версия VMware vCenter Converter Standalone 6.3.0

На прошлой неделе анонсирована бета-версия долгожданного релиза VMware vCenter Converter Standalone 6.3.0 с поддержкой целевой платформы vSphere 7.0.

Вступите в vCenter Convert Beta Community для участия либо напишите на vc-converter-beta@vmware.com.

В этом релизе:

  • Поддерживается только чистая установка, поэтому необходимо удалить старые версии.
  • Поддерживается установка Converter на:
    • Windows Server 2012 (64-bit
    • Windows 8.1 (32-bit and 64-bit)
    • Windows Server 2012 R2 (64-bit)
    • Windows 10 (32-bit and 64-bit)
    • Windows Server 2016 (64-bit)
    • Windows Server 2019 (64-bit)
    • Windows 11 (64-bit)
    • Windows Server 2022 (64-bit)
  • VMware Converter Standalone может конвертировать выключенные виртуальные  машины Hyper-V со следующих серверов Microsoft:
    • Windows Server 2012 (64-bit)
    • Windows Server 2012 R2 (64-bit)
    • Windows 10 (64-bit)
    • Windows Server 2016 (64-bit)
    • Windows Server 2019 (64-bit)
    • Windows 11 (64-bit)
    • Windows Server 2022 (64-bit)
  • VMware Converter Standalone может конвертироваться выключенные виртуальные машины из следующих продуктов VMware:
    • VMware vSphere 6.5 (Update 3)
    • VMware vSphere 6.7 (Update 3)
    • VMware vSphere 7.0 + Update 1 + Update 2 + Update 3
    • VMware Workstation 16.x
    • VMware Fusion 12.x
  • VMware Converter Standalone поддерживает следующие гостевые ОС:
    • Windows Server 2012 (64-bit)
    • Windows 8.1 (32-bit and 64-bit)
    • Windows Server 2012 R2 (64-bit)
    • Windows 10 (32-bit and 64-bit)
    • Windows Server 2016 (64-bit)
    • Windows Server 2019 (64-bit)
    • Windows 11 (64-bit)
    • Windows Server 2022 (64-bit)
    • CentOS 6.x (32-bit and 64-bit)
    • CentOS 7.x (64-bit)
    • Red Hat Enterprise Linux 6.x (32-bit and 64-bit)
    • Red Hat Enterprise Linux 7.x (64-bit)
    • Ubuntu 14.04 LTS (32-bit and 64-bit)
    • Ubuntu 16.04 LTS (32-bit and 64-bit)

Примечание: VMware Converter Standalone 6.3.0 НЕ поддерживает Virtual Hardware выше версии 11. При выборе vHW>11 функциональный уровень будет ограничен по версии 11.

Раздувание таблиц vPostgres в VMware VCSA

В СУБД PostgreSQL присутствует эффект раздувания таблиц aka table bloat. Он выражается в падении производительности при интенсивном обновлении данных, например,  при частых UPDATE, INSERT, DELETE. Данное поведение характерно и для СУБД vPostgres в VMware VCSA.

Для диагностики раздувания необходимо выполнить следующие действия:

  1.  Скачать скрипт 51981_check_bloat.sql из БЗ VCSA database storage /storage/db is full or nearly full (51981) (скрипт является копией официального Show database bloat).
  2. Подключиться к БД: /opt/vmware/vpostgres/current/bin/psql -U postgres -d VCDB.
  3. Скопировать и вставить содержимое файла и нажать Enter.
  4. Проанализировать отчёт. Если значение колонок tbloat либо ibloat column больше 25, то запланировать обслуживание БД.

Читать далее «Раздувание таблиц vPostgres в VMware VCSA»

Релиз Код Безопасности vGate 4.5 SP1

Код безопасности выпустил свежую версию своего продукта для защиты виртуальных сред vGate 4.5 (сразу с первым сервис-паком) для vSphere.

В данной версии реализованы новые функции:

  1. Реализован контроль операций Cloud Director и управление организациями.
  2. В веб-консоли реализован контроль состояния соединений (SPI — Stateful packet inspection).
  3.  В веб-консоли реализован анализатор трафика (DPI — Deep packet inspection).
  4. В веб-консоли реализован контроль прикладных протоколов с помощью правил фильтрации компонента «Сегментирование».
  5. Реализован безагентный контроль операций vCSA.
  6. Реализована возможность доступа администратора виртуальной инфраструктуры к защищаемым серверам через веб-интерфейс vGate (без агента аутентификации).
  7. Реализована поддержка политик шаблона «VMware vSphere 7 Security Configuration Guide».
  8. Выполнен перенос функции управления правилами доступа из консоли управления vGate в вебконсоль. Добавлено управление настройками регистрации событий правил доступа.
  9. Выполнен перенос функций управления политиками безопасности, механизмом полномочного управления доступом, а также контролем целостности защищаемых серверов из консоли управления vGate в веб-консоль.
  10. Выполнен перенос функции управления защищаемыми серверами из консоли управления vGate в веб-консоль.
  11. В веб-консоли реализовано отображение последних операций с ESXi-серверами и виртуальными машинами.
  12. В агенте аутентификации и в веб-консоли обеспечена возможность настройки уровня логирования NDIS-драйвера.
  13. В агенте аутентификации реализована проверка сетевой доступности сервера авторизации.
  14. В веб-консоли и в агенте аутентификации реализовано оповещение пользователя о времени его последнего входа.
    • Подробная документация:

Читать далее «Релиз Код Безопасности vGate 4.5 SP1»

Релиз 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:

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

Предназначение ключей программы: Читать далее «Утилита самообслуживания 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, что обеспечивает следующие шаги для решения проблемы. Читать далее «Утилита самообслуживания VMware vSphere Diagnostic Tool»

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

Disclamer:  все дальнейшие рассуждения, настройки и выбранные методы тестирования могут быть ошибочны. Никакого отношения к компаниям 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).

Краткое резюме по этапам тестирования производительности приведено в таблице: Читать далее «Тестирование систем хранения данных 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.

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

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

Disclamer:  все дальнейшие рассуждения, настройки и выбранные методы тестирования могут быть ошибочны. Никакого отношения к компаниям 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-адаптеров. Читать далее «Тестирование СХД Lenovo ThinkSystem DE6000F по протоколу передачи NVMe over FC»