Статья про RAID

@kr0k0k0t прислал статью про неСХД и RAID.

Вместо эпиграфа:
«Был неправ, вспылил. Но теперь считаю своё предложение безобразной ошибкой, раскаиваюсь, прошу дать возможность загладить, искупить. Всё, ушел.» (C) «Обыкновенное чудо.»

Часто приходится быть свидетелем споров типа «а QNAP – это СХД?» «В чем разница между СХД и NAS?», «а можно ли использовать QNAP такие-то цифры для бекапов?» и т.п. Вот и здесь недавно было. Посему, в качестве деятельного раскаяния за флуд решил поделиться своим IMHO’м на эту тему. Возможно, будет для кого-то полезно. Осторожно, многабукаф. Читать далее «Статья про RAID»

Обновление VCSA 7.0 до update 1 или тренировка восстановления с резервной копии

Недавно мы писали о выходе нового обновления для vSphere 7.0

Релиз VMware vSphere 7.0 update 1

И вот, встав не с той ноги, решили обновить VCSA в нашей инфраструктуре Horizon.

Облом с обновлением через GUI

Как у нас заведено, сделали снимок ВМ VCSA с оперативной памятью и запустили в GUI обновление, аналогично

Обновление одиночного VMware vCenter 6.7

Как это бывает с GUI, обновление не завершилось:

Статусы служб при попытке пнуть вручную:

Решили откатить снимок и запустить обновление с CLI, но vpxd был с нами не согласен:

Предположительно, во время снятия снимка Horizon клепал ВМ и мы попали в конфликт записей о ВМ.

Грабли при восстановлении VCSA с file-based резервной копии

Сделав несколько вздохов, приступили к восстановлению из резервной копии. На всякий случай, прогулялись по граблям:

  1. ВМ VCSA привязали к обычным портгруппам vDS, соответственно, сетка попала в пустоту. Исправили, переключив на ephemeral.
  2. Стали накатывать резервную копию, оказалось, номер сборки vCenter не совпал с резервной копией. Скачали нужный, переразвернули VCSA.
  3. При повторном накате опять получили ошибку, что не совпадает deployment size — мы выбрали medium, а был другой. Посмотрели конфигурацию старой ВМ, переразвернули VCSA в large.

Обновление VCSA с CLI

Как обновлять с помощью ISO в CLI описано в статье

Обновление VMware vCenter 6.7 в конфигурации HA

В этот же раз мы обновляли с URL:

VMware ESXi 7.0 и неподдерживаемое оборудование

Disclaimer:  все дальнейшие рассуждения и действия не соответствуют политике технической поддержки VMware. Любое использование оборудования вне VMware HCL может быть использовано только на свой страх и риск. В статье рассматривается только то оборудование, на котором возможен технический запуск ESXi 6.7U3.

В связи с выходом платформы VMware vSphere 7.0 виртуальные системные администраторы стали анализировать возможность обновления либо внедрения данного продукта.

Если проблемы с vCenter 7.0 вполне решаемы и описаны в нашей статье Обновление VMware vCenter с версии 6.7 до 7.0, то с ESXi 7.0 всё не так просто.

Для «упрощения» работы администраторов VMware расширила функциональность Update Manager (VUM) полуавтоматическим анализом оборудования: сверкой моделей серверов с HCL, проверкой версий прошивок и драйверов компонентов. Данная функциональность уже была частично представлена  в VSAN [Skyline] Health Hardware compatibility для дисковой подсистемы. Новая версия VUM стала называться vSphere Lifecycle Manager (vLCM). Для загрузки HCL следует в административном интерфейсе нажать ACTIONS->Sync HCL.

Мои ожидания от vLCM были примерно такие — запускаю на хосте Updates -> Hardware Compatibility и система пишет, что оборудование не в HCL, такие-то компоненты не имеют драйверов и не будут работать. В реальности, если сервер не в HCL, то на этом проверка останавливается:

Host model is not compatible with ESXi 7.0
Skipped checking host devices.

Что как бы нас совершенно не устраивает, так как наша цель — запуститься вне HCL, и хотелось бы понимать какие компоненты не имеют драйверов и поддержки.

Поэтому с компонентами придётся разбираться самостоятельно. Читать далее «VMware ESXi 7.0 и неподдерживаемое оборудование»

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

Дождавшись выхода VMware vSphere 7.0.0b, мы решились на обновление нашей инфраструктуры, построенной на платформе версии 6.7.

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

Проблема с сертификатами

При попытке обновления вылезла ошибка с сертификатами:

Error: A vCenter Single Sign-On endpoint certificate validation error has occurred.
Resolution: Ensure that the endpoint service registrations in vmdir match their corrsponding machine SSL certificates in VECS. For more information, see Knowledge Base article KB 2121701

Как это бывает, КБшка не помогла, как и не помог совет в форуме VMware.

Обратились в ТП VMware, получили волшебный скрипт и инструкцию: ls_ssltrust_fixer_p3.

  1. Проверить наличие актуальной резервной копии и сделать snapshot.
  2. Подключиться к vCenter по SSH.
  3. Скопировать «ls_ssltrust_fixer.py» в папку /usr/lib/vmidentity/tools/scripts (например, с помощью WinSCP).
    1. Перейти в папку:
    2. Изменить права:
  4. Выполнить проверку ошибок «certificate thumbprint mismatch» с помощью команды:
  5. Выполнить исправление ошибок «certificate thumbprint mismatch» с помощью команды:

После магических пасов руками vCenter обновился.

Проблема с vLCM

Зная рецепт, обновили несколько vCenter и получили разную функциональность в обновлении Update Manager — vSphere Lifecycle Manager (vLCM). Местами он категорически отказывался показывать Image Depot и видеть обновления для ESXi 7.0. Недолго думая, мы решили сделать сброс БД, чтобы заодно её почистить от компонентов для ESXi6.0 —  Resetting VMware Update Manager Database on a vCenter Server Appliance 6.5/6.7/7.0 (2147284). Это исправило «видимость» семёрочных обновлений.

Проблема с безагентской антивирусной проверкой

Для безагентской антивирусной проверки требуются компоненты VMware NSX Data Center for vSphere, поддержка которого не была заявлена (вышел новый продукт) при релизе vSphere 7.0. Но, VMware одумалась и в этом месяце всё таки выпустила патч версии 6.4.7.

Проблема с плагином Veeam BR

Также отвалился плагин для Veeam BR — порешалось переустановкой.

P.S. В придачу слетел файловый бэкап vCenter ;). Требуется перенастройка.

Настройка NVMe-oF подключения к RHEL 8.1

Dmitriy Shevchenko прислал продолжение цикла инструкций по настройке NVMe-oF. Сегодня речь пойдёт об операционной системе RHEL.

Перечень оборудования и ПО

Система хранения: Netapp AFF A320, версия ПО ONTAP Release 9.7P1.

Коммутаторы сети хранения данных: Switch Brocade 6505 16Gb 24 Port 2шт. FW 8.2.1c.

Серверы: Fujitsu PRIMERGY RX2530 M5 c FC адаптерами Broadcom (EMULEX) LPe32002 версия FW 12.6.240.22 (рекомендованная в матрице совместимости Netapp).

Операционная система: Red Hat Enterprise Linux release 8.1 (Ootpa) (Примечание: в 8.2 с установкой драйверов, были проблемы, нет ключа -n).


Предварительная подготовка

  1. Устанавливаем Red Hat Enterprise Linux release 8.1 (без установки обновлений):

  1. Скачиваем необходимые драйвера и ПО с сайта broadcom.com:
  1. Устанавливаем OneCommand Manager: Читать далее «Настройка NVMe-oF подключения к RHEL 8.1»

Настройка NVMe-oF подключения к VMware vSphere 7.0

В связи с выходом VMware vSphere 7.0 стала доступна технология NVMe over Fabric (NVMe-oF) для управления операциями с накопителями и передачи данных по протоколу NVMe вместо SCSI.

Dmitriy Shevchenko прислал инструкцию, которую мы сегодня и публикуем.

Перечень оборудования и ПО

Система хранения: Netapp AFF A320; версия ПО: ONTAP Release 9.7P1.

Коммутаторы сети хранения данных: Brocade 6505 16Gb 24 Port 2 шт. ; FOS FW 8.2.1c.

Сервер: Fujitsu PRIMERGY RX2530 M5 c FC-адаптерами Broadcom (EMULEX) LPe32002, версия FW 12.4.243.17 (рекомендованная в матрице совместимости Netapp).

Гипервизор: ESXi-7.0.0-15843807.

Схема подключения: Читать далее «Настройка NVMe-oF подключения к VMware vSphere 7.0»

Удаленное подключение к ПК через VMware Horizon Direct Connection

В связи с потребностью в удаленной работе возникает вопрос об эффективных протоколах для передачи удаленного рабочего стола.

Кроме штатного протокола RDP, повысить удобство работы может VMware Horizon Client, который дополнительно поддерживает протоколы Blast (Blast Extreme) и PCoIP (PC over IP).

Подготовка ПК, к которому будем подключаться

Совместимость версий Windows и Horizon:

Windows Version Horizon Version Protocol
Windows 11 Education and Pro 21H2 and later 8 (2206 and later) Blast only
Windows 10 Education and Pro 20H2 and later 8 (2206 and later) Blast only
Windows 10 Enterprise 1909 and later 7.12 and later

8 (2006 and later)

Blast or RDP
Windows 10 Enterprise 1903 7.12 and later Blast or RDP
Windows 10 Enterprise 1803-1809 7.7 and later Blast or RDP
Windows 10 Enterprise 17xx 7.x RDP only
Windows 10 (non-Enterprise) 7.x

8 (2006 and later)

RDP only
Windows 7 7.x RDP only

Для установки требуется агент:
VMware-Horizon-Agent-x86_64-7.12.0-15805436.exe
Чтобы пропустить указание Connection Server необходимо использовать параметр запуска:

А также плагин:
VMware-Horizon-Agent-Direct-Connection-x86_64-7.12.0-15805436.exe

Для мониторинга показателей протокола при установке отметить VMware Horizon Perfomance Tracker, дополнительно можно использовать Remote Display Analyzer https://rdanalyzer.com/

ПК с клиентом

Для подключения необходимо установить клиента:
VMware-Horizon-Client-5.4.0-15805437.exe

После установки указываем имя/адрес удаленного ПК. Для настроек и выбора протокола следует отключить опцию в клиенте Autoconnet to This Desktop.

Переключение между Blast и PCoIP возможно в рамках сессии.
Для переключения на RDP и обратно сессию нужно завершать.

Мониторинг

Читать далее «Удаленное подключение к ПК через VMware Horizon Direct Connection»

Как (не) утопить проект VDI?

Хотелось написать заголовок «Как утопить любой проект?», но получился бы уж слишком абстрактный. Поэтому в продолжение статьи Как получить экономическую целесообразность при внедрении VDI? напишу свои мысли по ИТ-проектному управлению. Дальше идёт сплошное IMHO aka поток мыслей.

Проект как плот

Для меня управление проектом — это плот, который несёт полезную нагрузку. Грузоподъёмность плота определяется качеством управления, командой, ресурсами, финансами. Затраты (финансовые; трудовые, включая способность к воплощению задуманного) на реализацию проекта — этот тот груз, который плот может осилить. Если мы плот перегрузим, то утопим судно.

Откуда берётся перегруз?

Предположим, что проектная команда отлично потрудилась и пообещала выполнить проект в сроки и бюджет с допуском +/- 10%, то есть максимальный проектный перегруз нашего плота составляет 10%: меньше можно, больше нельзя.

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

Приходят «сетевики» и говорят, в проекте VDI требования к VSAN All-flash от 10 Гбит/с, заложите в проект модернизацию сетевой инфраструктуры ЦОДа. А ещё на рабочих местах местами старые свитчи и хабики стоят, сеть работает на 10 мегабит/с, надо бы АСО поменять. Да, и не забудьте, были заявки на прокладку СКС, но работы не были выполнены, накиньте в проект.

Приходят «энергетики», говорят — если в ЦОД желаете новое оборудование, то надо бы ИБП-шник прикупить, на другую подстанцию заодно переключиться — заложите в проект.

Приходят «печатники», в VDI сканеры и LPT-принтеры криво работают, надо бы на сетевые МФУ денежку предусмотреть.

Что в этом момент происходит с затратами (в попугаях): Читать далее «Как (не) утопить проект VDI?»

Как получить экономическую целесообразность при внедрении VDI?

Темой виртуализации рабочих мест служба ИТ предприятия заинтересовалась в 2015 году.  Для ИТ это был вариант замены более старого проекта с посредственным результатом — внедрения терминальной фермы на MS Windows Server 2003.

MS WS RDS

Пилот

Для начала запустили маленький пилот на базе MS WS Hyper-V  2012 R2/RDS VDI, терминальная ферма под проект не подходила по причине большого количества legacy-программ, которые не работали в 64-битном окружении.

Пилот благополучно завершился с кучей нерешённых вопросов относительно подключения периферийных устройств, также повлияли политические настроения.

VMware Horizon

Пилот

Спустя полтора года ситуация с парком ПК на базе Windows XP накалилась до предела — прогноз показывал, что 30-35% компьютерного парка будут старее 10 лет, и их надо сдавать в утиль.

Снова решили запустить пилот, но уже на VMware Horizon.

Обсуждение проекта с коллегами и партнёрами всегда приводило к одному выводу — VDI однозначно будет дороже, чем купить новые офисные ПК.

Первой задачей была — ничего не потратить на клиентское место! Как это сделать? Все окружающие нас публичные проекты были построены на брендовых тонких клиентах с нехилой стоимостью от 20-25 тысяч рублей за системный блок, что по нижней планке конкурировало с классическим офисным системным блоком.

Стали искать варианты, как задействовать текущий системный блок (Celeron 420/440; 1 ГБ ОЗУ) для установки клиентского ПО.

Решение пришло из прошлого терминального опыта — использовать бесплатную ОС Thinstation, которая поддерживает актуальные версии VMware Horizon Client.

Второй задачей была — обеспечить функционирование компонентов ПК и периферии. На проверку совместимости оборудования и ПО, доводку клиента и драйверов потратили 80% времени пилота.

Тестировались:

  1. Десятки моделей USB-принтеров.
  2. USB-считыватели пропусков.
  3. USB-накопители.
  4. Сетевые МФУ и USB-сканеры.
  5. USB-сканеры штрих-кодов/USB-принтеры штрих-кодов.
  6. Несколько типов видеокарт.
  7. Несколько типов материнских плат.
  8. Несколько типов сетевых карт.

Из системных блоков были выкинуты жесткие диски, а загрузка клиента была организована через PXE.

На выходе из пилота стало ясно — 95% наших потребностей VMware Horizon технологически закрывает. Из проблем остались только сканеры, но по ним у нас был запущен параллельно проект по приобретению МФУ со сканированием на файл-серверы.

Проект Читать далее «Как получить экономическую целесообразность при внедрении VDI?»

Epic fail story

Всем привет!

Пятница, вечер, дождик…

1) В одной компании вышел из строя RAID6 на HP Proliant Gen6, виртуальные машины на VMware ESXi стали частично недоступны.

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

Владелец взял где-то два брендовых SATA-диска IBM, объединил их в программное зеркало (динамический диск MS Windows) и скинул туда данные с сервера Hyper-V. Сервер Hyper-V был переформатирован под ESXi.

Когда через месяц-два он раздобыл новый сервер под Hyper-V, оказалось, что оба IBM-диска неживые.

Я не уточнял у него, как он вышел из этой ситуации.

2) В другой компании внезапно стали недоступными виртуальные машины, находящиеся на одном из RAID-массивов. Как оказалось, LUN3, состоящий из двух SSD-дисков в зеркала, решил что ну его…

У нас же есть бэкапы, заявил мой тезка. Угу-угу, VMware Data Protection 6.1.2 не загружался, в консоли висела надпись:

Перезагрузка не помогла, через час все было точно также.

vDP пытались оживить сначала вручную, потом через техподдержку VMware. Третий по счету инженер из EMC смог оживить бэкапы и мы узнали… что последний бэкап сделан год назад. Так как «Retention Policy» требует хранить бэкапы за последние 90 дней…

Тут мой тезка и говорит «у меня есть еще одна система резервного копирования, сохраняющая файлы на сервер в Amazon. Но я залогиниться туда не могу 🙁

В общем, сервер с бэкапами на Amazon оказался заражен каким-то ransomware…

Параллельно была сделана попытка выключить и включить система храения с выдергиванием/втыканием SSD-дисков (потому что она еще и на RAID-контроллер ругалась)…

После включения массива сдохло еще 4 SAS-диска (2 уже не работали), вследствие чего Lun2 ушел следом за Lun3. Как оказалось, MD3220i более 7 лет.

Какие выводы (кроме настройки уведомлений) вы бы сделали из обоих историй?

Какие epic fail были у вас?