Рубрика: Статьи

VMware vSphere 7 Update 3: обновления службы vCLS

Перевод статьи vSphere 7 Update 3: vCLS Updates.

Глоссарий

В данном тексте используется биологический термин «аффинность» для перевода «Affinity», так как русский вариант «сродство» встречается в ИТ-лексиконе практически никогда. Под аффинностью в статье подразумевается принудительное размещение нескольких ВМ на одном хосте, под анти-аффинностью — запрет их совместного одновременного размещения на одном хосте.

Вступление

Служба vSphere Cluster Service (vCLS) была представлена в vSphere 7 Update 1. В vSphere 7 Update 3 появилось несколько хороших обновлений vCLS для повышения эффективности таких операций, как размещение агентских ВМ vCLS службы на хостах и хранилищах данных (datastores).

Аффиность стала умнее

Используя конструкцию Compute Policies, которая теперь является частью vSphere, мы можем обеспечить более разумное размещение ВМ агентов. Compute Policies уже были частью решения VMC on AWS. Это динамический способ создания правил (анти-)аффинности или создание динамического размещения ВМ в кластере с использованием тегов vSphere. В vSphere 7 Update 3 Compute Policies можно использовать только для агентских ВМ службы vCLS.

Это решает потенциальную проблему, с которой сталкивались клиенты, например, с рабочими нагрузками SAP HANA, требующими выделенных сокетов на узлах. Клиенты не могут использовать сокеты рабочих нагрузок HANA для запуска других приложений или даже агентских ВМ, как в случае с vCLS. Таким образом, клиенты теряют целиком весь сокет в кластере HANA для запуска агентских виртуальных машин vCLS, что может привести к потере значительных вычислительных ресурсов, в зависимости от размера и конфигурации кластера.

С помощью интеллектуальных конфигураций аффинности для агентских виртуальных машин vCLS, используя Compute Policies, мы можем запускать агентские ВМ vCLS на хостах внутри кластера, которые не будут мешать специфичным виртуальным машинам. Таким образом, пользователи SAP HANA могут задать аффинность, чтобы агентские виртуальные машины использовали выделенный хост. Причина использования Compute Policies, а не правил (анти-)аффинности DRS заключается в том, что DRS будет недоступна во время настройки аффинности агентских ВМ vCLS.

Как настроить?

Читать далее «VMware vSphere 7 Update 3: обновления службы vCLS»

Эволюция производительности VMware vSphere 7

В продолжении цикла

vSphere6 — эволюция

публикую перевод статьи What’s New in Performance for VMware vSphere 7.x?

В основе каждого выпуска VMware vSphere лежит множество улучшений производительности и масштабируемости. Платформа vSphere 7.x продолжает обеспечивать лучшую в отрасли производительность и функции для успешной виртуализации и управления вашим программно-определяемым центром обработки данных.

Последний технический документ «What’s New in Performance for VMware vSphere 7?» охватывает VMware vSphere 7.0, U1, U2 и U3. Некоторые основные моменты включают: Читать далее «Эволюция производительности VMware vSphere 7»

Требования к загрузочному накопителю в VMware ESXi 7 и нюансы использования

Перевод статьи ESXi 7 Boot Media Consideration and VMware Technical Guidance.

Исторически сложилось так, что для освобождения отсеков для устройств и снижения стоимости установки узлов ESXi выбирались SD-карты или USB-устройства. Однако такие устройства имеют низкий ресурс и со временем проявляют проблемы с надежностью. SD-карты и USB-накопители также могут иметь проблемы с производительностью и не выдерживать высокочастотных операций чтения-записи. В настоящее время мы все чаще наблюдаем проблемы, связанные с загрузкой в ESXi 7.x, с узлами, использующими SD-карты или USB-накопители в качестве загрузочных накопителей. В этой статье мы подробно расскажем о том, что мы видели, и предоставим техническое руководство по устранению таких проблем.

Прежде чем перейти к деталям, важно понять новую схему системы. До появления vSphere 7 управление разделами было ограничено: размеры разделов были фиксированными, а номера разделов — статичными. Существовали ограничения на использование нескольких решений с размерами разделов vSphere 6.x, например, если вы начинали комбинировать NSX-T, vSAN, Tanzu, vGPU и т.д. Это ограничивало поддержку установки больших модулей, отладочных функций и возможных сторонних компонентов.

В перспективе потребность в поддержке хостами ESXi других решений VMware или сторонних производителей постоянно возрастает. Поэтому потребность в более надежном, гибком и высокопроизводительном устройстве хранения данных для системного хранилища является необходимостью.

В новой схеме разделов vSphere 7.x только загрузочный раздел системы имеет фиксированный размер 100 МБ. Остальные разделы являются динамическими, то есть размер раздела будет определяться в зависимости от размера загрузочного накопителя. Читать далее «Требования к загрузочному накопителю в VMware ESXi 7 и нюансы использования»

Падучая ESXi или возвращение блудного хоста

И снова статья от участника телеграм-канала VMware User Group Rus.

Третьего дня в чат опять пришли коллеги с стандартной проблемой – хост отвалился от vCenter  — ШТО ДЕЛАТЬ?

Правильный ответ – писать сценарии отказа и отрабатывать их, это один из таких случаев, с которыми надо быть знакомыми до начала эксплуатации.

Вводные

Есть некий хост с VMware (разумеется, с последними патчами – а то было тут как-то PR 2412475: You see Sensor -1 type hardware health alarms on ESXi hosts and receive excessive mail alerts). Хост отвалился от VCenter (разумеется, тоже с последними патчами – особенно это касается линейки 7.0). Виртуальные машины на хосте продолжают работать, отказоустойчивости на уровне сервисов (Oracle real application clusters, database availability group, MS SQL Always On и так далее) нет, но и просто так перезагрузить хост – не вариант. Нет никаких гарантий, что хост поднимется, что есть ресурсы на других хостах.

В данном случае имеет смысл обратиться в поддержку — если, конечно, у вас система работает на поддерживаемой конфигурации, куплены лицензии и куплена эта самая поддержка. Поддержку можно купить «поштучно» — VMware Per Incident Support.

Шаг 1. Что было, то и будет; и что делалось, то и будет делаться, и нет ничего нового под солнцем

Читать далее «Падучая ESXi или возвращение блудного хоста»

Обновляем серверы Lenovo Thinksystem/ThinkAgile VX с помощью VMware vSphere Lifecycle Manager

В VMware vSphere 7.0 появился новый встроенный продукт для управления обновлениями Lifecycle Manager. Кратко я о нём упоминал в статье:

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

Данный менеджер умеет проверять HCL и даже, по слухам, обновлять прошивки оборудования!

После несколько обращений по поводу функционала и неполным пониманием собеседников как это работает настало время написать про интеграцию с экосистемой Lenovo. Читать далее «Обновляем серверы Lenovo Thinksystem/ThinkAgile VX с помощью VMware vSphere Lifecycle Manager»

Переход на VMware vSphere 7.0 update 2

Постоянный читатель прислал свои мысли о выборе гипервизоров и убедительной победе vSphere 7.0, несмотря на все грабли ;).

С чего все началось

Недавно у наших коллег появилось осознание, что:

  1. самым старым серверам в продуктивной среде уже 8 и больше лет,
  2. поддержки и запчастей на них нет,
  3. нагрузка по памяти под 90%, но ее там очень немного,
  4. установлена максимально возможная для этих серверов ESXi 6.5 , на тот момент 17477841 (сейчас 18071574).

Поэтому  было решено:

  1. начать закупку новых серверов,
  2. обновить, где  возможно, до ESXi 7.0 для единообразия.

Серверы, в основном, производства HPE и Huawei, на каких-то задачах используются серверы Supermicro. Предлагают закупать Dell, HPE, Lenovo. У Huawei сейчас все сложно, а присматриваться к линейке Kunpeng на Arm сейчас нет времени. Хотя под Arm есть и MS Server, и ESXi.

Почему ESXi, а не что-то еще Читать далее «Переход на VMware vSphere 7.0 update 2»

Порядок восстановления ИТ-инфраструктуры

Однажды поручили разработать нам DRP (Disaster Recovery Plan) — План восстановления деятельности после кризисной ситуации. План как план, таких мильон.

Но один раздел запал мне в душу — Порядок восстановления ИТ-инфраструктуры.

В моём видении, базирующемся на опыте переездов ЦОДов, порядок получился таким: Читать далее «Порядок восстановления ИТ-инфраструктуры»

Статья про 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 и неподдерживаемое оборудование»