Рубрика: Советы

Добавление FC-коммутаторов с FabricOS 9.x в Brocade Network Advisor

Disclaimer:  все дальнейшие рассуждения и действия не соответствуют политике технической поддержки Broadcom. Любое использование оборудования вне списков совместимости Broadcom может быть использовано только на свой страх и риск. В статье рассматриваются коммутаторы на основе G620 первого и второго поколения. BNA ничего не знает про новую функциональность FabricOS 9.x и не сможет с ней правильно взаимодействовать.

Для управления FC-фабриками мы используем Brocade Network Advisor, который прекратил свой жизненный путь и заменен на SANNav.

К сожалению, SANNav поставляется по подписки и у нас есть проблемы с её приобретением.

Первой проблемой для нас стало то, что последняя версия BNA 14.4.5 перестала интегрироваться с VMware vCenter 7.0. Пришлось интеграцию удалить.

Второй проблемой — отсутствие поддержки Fabric OS 9.x, которая стала базовой для новых и обновленных коммутаторов.

У нас коммутаторы G620 второго поколения отображались в схеме фабрик как имеющие неправильные имя-пароль для подключения. Изменение настроек в разделе snmp коммутаторов и сервера — задание уровня шифрования для пользователя мониторинга в BNA и коммутаторе, включения информера не помогали.

Просмотр текущих настроек snmp:

Изучение настроек BNA выявило, что для сканирования оборудования фабрик используется аккаунт domain\access_bna, то есть коммутаторы должны позволять вход под доменными учётными записями.

Настроили и для новых коммутаторов RADIUS- авторизацию:

После этого коммутатор стал доступен для мониторинга и отобразился в схеме фабрики.

А вот коммутатор в другой фабрике по-прежнему остался недоступным. В консоли BNA выводилась ошибка с фразой:

Начали выяснять отличия первого коммутатора от второго.
Вспомнили, что на первом ломала и пересоздавали сертификат для подключения по https, а второй избежал этой участи, так как  проблема была в браузере — подключаться необходимо из Windows 10 с установленной кодовой страницей профиля пользователя EN-US.

Просмотр сертификатов для https выдается командой:

Разница видна сразу:

Команда генерации сертификата, по найденному лайфхаку, была:

Примечание: не все советы в интернете оказываются полезными. Помните это, читая и данную статью!

Создали новый сертификат с другим алгоритмом, соответствующий второму коммутатору:

После перегенерации сертификата, BNA увидел коммутатор и в этой фабрике.

Veeam Backup&Replication и восстановление дедуплицированных дисков

При попытке восстановить файлы на дедуплицированных томах из виртуальной машины с помощью Veeam BR FLR процесс восстановления зависает.
При запуске восстановления появляется сообщение:

Это связано с отсутствием компонентов дедупликатора. Добавляем их вручную на сервер Veeam BR:

Повторно восстанавливаем файлы.

Сохранение активации лицензий ПО при замене оборудования в VMware vSphere 6.7+

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

Время от времени серверы устаревают, а на замену им приходит новое оборудование с новыми процессорами.

Для абстрагирования vCPU от физического процессора от оборудования в VMware vSphere много лет развивается технология маскирования флагов процессора:

Обычно, технологии защиты ключей лицензий, разрешенные к использованию в виртуальных средах, используют привязки к:

  1. BIOS/UEFI;
  2. операционной системе;
  3. имени сервера/ПК;
  4. идентификаторам либо серийным номерам жестких дисков;
  5. MAC-адресам сетевых карт;
  6. CPUID, описывающему имя, семейство и модель процессора, доступные SIMD-инструкции.

В соответствии с этим мы можем использовать фиксацию части параметров.

Для фиксации UUID BIOS можно отредактировать VMX-файл:

Также возможны и более хардкорные модификации BIOS/UEFI. Получить данные можно получить через команду wmic bios.

Для привязки по MAC-адресу мы фиксируем адрес с физического сервера лицензий, либо генерируем его сами до получения лицензий. Адрес можно указать в настройках сетевого адаптера либо прописать в VMX-файле:

Parameter Value
ethernetX.addressType static
ethernetX.address MAC_address_of_the_virtual_NIC

В большинстве случаев получается привязать MAC к выключенному адаптеру либо подключенному в пустую виртуальную сеть.

Для сохранения CPUID необходимо собрать следующую информацию:

  • EVC/поколение ЦПУ виртуальной машины в vSphere.
  • Поколение(CPU-Z), название, id и модель процессора в операционной системе (wmic cpu get caption, name, processorid; в Linux /proc/cpuinfo).

После этого в конфигурации выключенной виртуальной машины (vHW>=14) устанавливается нужный уровень Per-VM EVC, при необходимости прописываются в VMX-файл прочие параметры маскинга CPUID (*в примере левые параметры):

Примечание.  При изменении vHW и/или обновлении ESXi версии BIOS/UEFI могут меняться. Изменение BIOS/UEFI, CPUID происходит по время выключения/включения (powercycle) виртуальной машины.

Всегда делайте копию виртуальной машины и VMX-файла перед правками!!!

Отключение Hyper-V с помощью BCDEDIT

Решил на домашнем компе поэкспериментировать с виртуальной машиной. Для этого включил компонент Hyper-V, компьютер ушёл в перезагрузку и больше не захотел загружаться.

После 2-3 сбросов я смог попасть в безопасный режим и удалить компонент в оснастке, но при следующей же перезагрузке Windows сказала, что доудалять не может и восстановила Hyper-V  — и система ушла в цикл.

На просторах Интернета нашёл команду, запрещающую старт Hyper-V (запустить в командной строке от имени администратора):

обратная (если понадобится):

Управляем неуправляемым VMware ESXi

Иногда бывает, что ESXi теряет управление — отваливается от vCenter.

Что с этим делать расписано на русском в статье «Хост VMware ESXi в состоянии Not Responding на сервере vCenter — в чем может быть проблема?»

Опытные админы, обычно, идут в консоль и подают 2-3-4 команды:

либо полный фарш:

Недавно у нас случилась аналогичная ситуация — отвалилось несколько хранилищ (datastore) и ESXi решил прикурить: vCenter отпал, хостовый веб-клиент отпал, вышеупомянутые команды якобы отрабатывали с нулевым результатом. Хорошо хоть виртуальные машины продолжали работать.

В итоге решили перезагрузить хост. Вот только для этого нужно было погасить виртуальные машины — часть выключили штатно изнутри, но некоторым нужно подать команду shutdown снаружи.

Типовые команды для выключения ВМок описаны  в статье «Powering off an unresponsive virtual machine on an ESXi host (1004340)»

Но у нас-то случился клинический случай  и ESXi не отрабатывал команд esxcli. Соответственно, пришлось искать более низкоуровневое решение — localcli.

localcli — это набор команд для работы технической поддержки VMware. Команды localcli эквивалентны командам ESXCLI, но обходят hostd. Команды localcli предназначены только для ситуаций, когда hostd недоступен и не может быть перезапущен.

Предупреждение: Использование LOCALCLI официально не поддерживается. Все действия выполняются на свой страх и риск.
Однако команда очень интересна тем, что при использовании специального внутреннего каталога плагинов появляются некоторые недокументированные пространства имен. Вы можете просмотреть эти пространства имен и открыть для себя некоторые интересные функциональные возможности. Просто войдите в ESXi и используйте команду

результат вывода:

Осталось написать скрипт массового выключения ВМок. Пока думал как написать решил поискать готовые решения и  поисковик выдал примечательную статью о шифровальщиках для VMware vSphere c готовым скриптом New Linux-Based Ransomware Cheerscrypt Targeting ESXi Devices Linked to Leaked Babuk Source Code. В статье косяки с кавычками и апострофами, так что держите верный код:

Ну, а для нашей задачи такой жести не надо, но нужны другая команда и обычное выключение:

Если же перед вами стоят другие задачи, но esxcli не работает, то попробуйте использовать доступные пространства имен для localcli.

Раздувание таблиц 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»

Утилита самообслуживания 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 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 для завершения изменений.

VMware vCenter 7.0 Lifecycle Manager не скачивает обновления через прокси

Попали на странные грабли — VMware vCenter 7.0 Lifecycle Manager не скачивает обновления через прокси.

При запуске Sync Update выпадает в ошибку ‘A general system error occurred: Download patch definitions task failed while syncing depots. Error: ‘integrity.fault.NoSignatureSiteConnection’.

Поиск в интернете выдает пару рекомендаций:

  1. vCenter 7.0, Lifecycle Manager fails downloading patches Error: “integrity.fault.NoSignatureSiteConnection”
  2. “A general system error occurred: Download patch definitions task failed while syncing depots. Error: ‘integrity.fault.MetadataDownloadFailure’.” Sync Updates vCenter 7.0.3c

Про второй случай я уже писал — и второй раз сбрасывать базу не собирался.

Обновление VMware vCenter с версии 6.7 до 7.0

А вот первый совет навёл на странную мысль, что в указании https прокси надо вместо https://ip_proxy указать http://ip_proxy. Как ни странно, помогло.