Тестирование СХД 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 для завершения изменений.

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. Как ни странно, помогло.

Опрос CDP/LLDP с ESXi через PowerShell/Python

Однажды у вас может возникнуть желание составить таблицу портов коммутаторов, к которым подключены ваши хосты.

Если у вас “гомогенное” окружение, состоящее из коммутаторов Cisco, то заморачиваться не нужно совсем (CDP настроен в Virtual Switch Standard/Distributed Virtual Switch по умолчанию).

Но если в окружении не только Cisco, то вам необходимо немного сильнее напрячься:

  • использовать только распределенные коммутаторы;
  • включать на них поддержку LLDP;
  • с удивлением обнаружить, что в API опрос CDP и LLDP происходит по-разному.

Continue reading “Опрос CDP/LLDP с ESXi через PowerShell/Python”

Заметочка про Custom Attributes

Потребовалось проставить Custom Attribute для виртуальных машин.

На помощь, как обычно, пришел Google и подсказал следующее решение:

VMware vSAN: как к нему подходить и с чего начинать

Статья прислана читателем бложика.

Предисловие

Изначально этот текст представлял собой выборку ссылок и пояснений из подготовленной где-то перед новым, 2022 годом, презентации «почему vSAN нам не очень нужен». В апреле 2022 года старый текст пришлось перечитать, переписать и существенно расширить. По логике надо бы этот текст разбить на четыре части – теория, подготовка развертывания, тестирование, и рабочие моменты, но вряд ли я этим займусь.

Уровень материала: 50-100.

Уровень требуемого английского для чтения: IELTS 3, способность скопировать непонятный текст и вставить в пока еще доступные онлайн переводчики.

Аффтар(ТМ) выражает отдельную благодарность участникам и администрации русского сообщества https://t.me/VMwarevSAN/ за внесенные коррективы, уточнения и огромную подготовительную работу.

Оглавление

Continue reading “VMware vSAN: как к нему подходить и с чего начинать”

PowerShell, SCSILunPath и Datastore Name

Обратился ко мне за советом постоянный читатель: помоги, говорит, с моим iSCSI-массивом NetApp. Пытаюсь вывести Get-SCSILunPath, так там ни имени датастора, ни IP-адреса “таргета” в SanId нет 🙁

Посмотрел – и действительно так: в отличие, например, от Huawei, NetApp не выводит IP-адрес IQN-Target в выводе атрибутов Get-SCSILunPath. Да и привязать CanonicalName вида naa.thebeststoragearray к датастору с первого взгляда не удается…

Continue reading “PowerShell, SCSILunPath и Datastore Name”

Февральские патчи ESXi 2022 года

Статья прислана читателем бложика.

Занимались аудитом и обслуживанием очередной пары фирм, попутно обновляли VMware  – увидели много интересного.

Первая фирма, обновления 7.0.1 – 7.0 Update 2e build 19290878.

Опять какие-то проблемы с iSCSI. На одном сервере полностью поменялся IQN, причем с изменением даже имени. После этого по возвращении сервер не увидел СХД, пришлось настраивать. На аналогичном втором сервере потерялся target, но IQN остался тот же.

Как оказалось, проблема описана в интернете, НО что-то не находится в VMware release notes: Continue reading “Февральские патчи ESXi 2022 года”