Category: 7.0

Раздувание таблиц 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, то запланировать обслуживание БД.

Continue reading “Раздувание таблиц 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. В веб-консоли и в агенте аутентификации реализовано оповещение пользователя о времени его последнего входа.
    • Подробная документация:

Continue reading “Релиз Код Безопасности 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:

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

Предназначение ключей программы: 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”

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