Мы много писали о том, что нового появилось в обновленной платформе виртуализации VMware vSphere 7, которая недавно стала доступной для загрузки. Сегодня мы поговорим о том, чего больше нет в vSphere, ведь многие администраторы привыкли использовать некоторые средства, поэтому, возможно, подождут с апгрейдом. Об этих запланированных изменениях мы писали еще в 2017 году.
1. Больше нет vSphere Web Client на базе Flash
Об этом говорили давно, долго задерживали снятие с производства тяжеловесного vSphere Web Client, но все откладывали из-за несоответствия функциональности клиенту нового поколения vSphere Client на базе технологии HTML5. Теперь в vSphere 7 этот переход окончательно завершен, и старого Web Client больше нет.
Клиент на HTML5 включает в себя не только все старые рабочие процессы Web Client, но и давно получил новые возможности, такие как, например, упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM).
2. Больше нет внешнего PSC (Platform Services Controller)
Как мы уже рассказывали, Embedded PSC - это теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается. Встроенный PSC имеет все необходимые сервисы для управления доменом vSphere SSO (подробнее описано в KB 60229).
С помощью утилиты Converge Tool, которая появилась в vSphere 6.7 Update 1, можно смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC, используя командный интерфейс vCenter Server CLI или графический клиент vSphere Client:
3. Больше нет VMware vCenter for Windows
Как мы уже писали, vSphere 6.7 - это была последняя версия платформы, где для vCenter еще была версия под Windows. Теперь остался только виртуальный модуль vCenter Server Appliance (vCSA) на базе Photon OS. Многие привыкли к сервисам vCenter на базе Windows, теперь придется отвыкать.
VMware рекомендует выполнить 2 основных шага для миграции с vCenter на vCSA:
Migration Assistant - консольная утилита, которую нужно выполнить до мастера миграции vCenter. Она выясняет соответствие требованиям к миграции и показывает дальнейшие шаги.
Migration Tool - это мастер миграции, который доступен из основного дистрибутива vCenter.
4. Больше нет Update Manager Plugin
На протяжении долгого времени это был плагин для vSphere Web Client. Теперь вместо продукта VMware Update Manager (VUM) в vSphere 7 есть более широкое по функциональности решение VMware Lifecycle Manager.
Ранее администраторы vSphere использовали Update Manager (VUM) для обновлений платформы и драйверов, а утилиты от производителей серверов для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.
5. Больше нет VNC-сервера в ESXi
Ранее в ESXi был встроенный VNC-сервер, который был убран в последней версии VMware vSphere 7. Раньше можно было соединиться с консолью виртуальной машины с помощью VNC-клиента, добавив в конфигурацию параметр RemoteDisplay.vnc.enable.
Теперь такой возможности больше нет (ей пользовались администраторы систем, не использующих средства VMware). Для соединения с консолью виртуальной машины используйте vSphere Client, хостовый клиент ESXi Host Client или средство VMware Remote Console.
6. Мелочи, которых или уже больше нет или их не рекомендуется использовать (не будет потом)
В эту категорию попали:
VMware vSphere 7.0 и протокол TLS Protocol (TLS 1.0 и 1.1 отключены по умолчанию).
Нет поддержки резервного копирования на уровне образов (Image-Based Backup) для сервера vCenter.
Интерфейс VMKlinux API уже давно безнадежно устарел, вместо него используется архитектура нативных драйверов под vSphere, начиная еще с ESXi 5.5. vmkLinux - это такая прослойка между VMkernel и Linux-драйверами, которая позволяла транслировать команды от ядра (так как VMkernel - это НЕ Linux) к драйверам и обратно. Но теперь нативных партнерских драйверов устройств для ESXi накопилось достаточно, и старая архитектура Linux-драйверов ушла в прошлое.
Депрекация поддержки 32-bit Userworld. Ранее партнерам VMware была доступна возможность делать 32-битные драйверы, плагины и другие компоненты в VIB-пакетах. Теперь, начиная со следующих версий vSphere, такой возможности больше не будет.
Почти убрана поддержка Integrated Windows Authentication. В этой версии IWA еще работает, но в следующей версии уже не будет. Подробнее в KB 78506.
Депрекация аутентификации DCUI Smart Card Authentication. Пользователям со смарт-картами рекомендовано использовать vCenter, PowerCLI или API-вызовы, ну либо логин и пароль по-старинке.
Депрекация Core Partition Profile для функциональности Host Profiles. Вместо разделов Coredump Partitions пользователям нужно использовать файлы Coredump Files.
Некоторое время назад мы писали о новых возможностях платформы виртуализации VMware vSphere 7, среди которых мы вкратце рассказывали о нововведениях механизма динамического распределения нагрузки на хосты VMware DRS. Давайте взглянем сегодня на эти новшества несколько подробнее.
Механизм DRS был полностью переписан, так как его основы закладывались достаточно давно. Раньше DRS был сфокусирован на выравнивании нагрузки на уровне всего кластера хостов ESXi в целом, то есть бралась в расчет загрузка аппаратных ресурсов каждого из серверов ESXi, на основании которой рассчитывались рекомендации по миграциям vMotion виртуальных машин:
При этом раньше DRS запускался каждые 5 минут. Теперь же этот механизм запускается каждую минуту, а для генерации рекомендаций используется механизм VM DRS Score (он же VM Hapiness). Это композитная метрика, которая формируется из 10-15 главных метрик машин. Основные метрики из этого числа - Host CPU Cache Cost, VM CPU Ready Time, VM Memory Swapped и Workload Burstiness. Расчеты по памяти теперь основываются на Granted Memory вместо стандартного отклонения по кластеру.
Мы уже рассказывали, что в настоящее время пользователи стараются не допускать переподписку по памяти для виртуальных машин на хостах (Memory Overcommit), поэтому вместо "Active Memory" DRS 2.0 использует параметр "Granted Memory".
VM Happiness - это основной KPI, которым руководствуется DRS 2.0 при проведении миграций (то есть главная цель всей цепочки миграций - это улучшить этот показатель). Также эту оценку можно увидеть и в интерфейсе:
Как видно из картинки, DRS Score квантуется на 5 уровней, к каждому из которых относится определенное количество ВМ в кластере. Соответственно, цель механизма балансировки нагрузки - это увеличить Cluster DRS Score как агрегированный показатель на уровне всего кластера VMware HA / DRS.
Кстати, на DRS Score влияют не только метрики, касающиеся производительности. Например, на него могут влиять и метрики по заполненности хранилищ, привязанных к хостам ESXi в кластере.
Надо понимать, что новый DRS позволяет не только выровнять нагрузку, но и защитить отдельные хосты ESXi от внезапных всплесков нагрузки, которые могут привести виртуальные машины к проседанию по производительности. Поэтому главная цель - это держать на высоком уровне Cluster DRS Score и не иметь виртуальных машин с низким VM Hapiness (0-20%):
Таким образом, фокус DRS смещается с уровня хостов ESXi на уровень рабочих нагрузок в виртуальных машинах, что гораздо ближе к требованиям реального мира с точки зрения уровня обслуживания пользователей.
Если вы нажмете на опцию View all VMs в представлении summary DRS view, то сможете получить детальную информацию о DRS Score каждой из виртуальных машин, а также другие важные метрики:
Ну и, конечно же, на улучшение общего DRS Score повлияет увеличения числа хостов ESXi в кластере и разгрузка его ресурсов.
Кстати, ниже приведен небольшой обзор работы в интерфейсе нового DRS:
Еще одной важной возможностью нового DRS является функция Assignable Hardware. Многие виртуальные машины требуют некоторые аппаратные возможности для поддержания определенного уровня производительности, например, устройств PCIe с поддержкой Dynamic DirectPath I/O или NVIDIA vGPU. В этом случае теперь DRS позволяет назначить профили с поддержкой данных функций для первоначального размещения виртуальных машин в кластере.
В видео ниже описано более подробно, как это работает:
Ну и надо отметить, что теперь появился механизм Scaleable Shares, который позволяет лучше выделять Shares в пуле ресурсов с точки зрения их балансировки. Если раньше высокий назначенный уровень Shares пула не гарантировал, что виртуальные машины этого пула получат больший объем ресурсов на практике, то теперь это может использоваться именно для честного распределения нагрузки между пулами.
Этот механизм будет очень важным для таких решений, как vSphere with Kubernetes и vSphere Pod Service, чтобы определенный ярус нагрузок мог получать необходимый уровень ресурсов. Более подробно об этом рассказано в видео ниже:
В блоге VMware vSphere появилась интересная запись о том, как происходит работа с памятью в гипервизоре VMware ESXi. Приведем ее основные моменты ниже.
Работа виртуальной машины и ее приложений с памятью (RAM) идет через виртуальную память (Virtual Memory), которая транслируется в физическую память сервера (Physical Memory). Память разбита на страницы - это такие блоки, которыми виртуальная память отображается на физическую. Размер этого блока у разных систем бывает разный, но для ESXi стандартный размер страниц равен 4 КБ, а больших страниц - 2 МБ.
Для трансляции виртуальных адресов в физические используется таблица страниц (Page Table), содержащая записи PTE (Page Table Entries):
Записи PTE хранят в себе ссылки на реальные физические адреса и некоторые параметры страницы памяти (подробнее можно почитать здесь). Структуры записей PTE могут быть разного размера - это WORD (16 bits/2 bytes), DWORD (32 bits/4 bytes) и QWORD (64 bits/8 bytes). Они адресуют большие блоки адресов в физической памяти, к примеру, DWORD адресует блок адресов 4 килобайта (например, адреса от 4096 до 8191).
Память читается и передается гостевой системе и приложениям страницами по 4 КБ или 2 МБ - это позволяет читать содержимое ячеек памяти блоками, что существенно ускоряет быстродействие. Естественно, что при таком подходе есть фрагментация памяти - редко когда требуется записать целое число страниц, и часть памяти остается неиспользуемой. При увеличении размера страницы растет и их фрагментация, но увеличивается быстродействие.
Таблицы страниц (а их может быть несколько) управляются программным или аппаратным компонентом Memory Management Unit (MMU). В случае аппаратного MMU гипервизор передает функции по управлению трансляцией ему, а программный MMU реализован на уровне VMM (Virtual Machine Monitor, часть гипервизора ESXi):
Важный компонент MMU - это буфер ассоциативной трансляции (Translation Lookaside Buffer, TLB), который представляет собой кэш для MMU. TLB всегда находится как минимум в физической памяти, а для процессоров он часто реализован на уровне самого CPU, чтобы обращение к нему было максимально быстрым. Поэтому обычно время доступа к TLB на процессоре составляет около 10 наносекунд, в то время, как доступ к физической памяти составляет примерно 100 наносекунд. VMware vSphere поддерживает Hardware MMU Offload, то есть передачу функций управления памятью на сторону MMU физического процессора.
Итак, если от виртуальной машины появился запрос на доступ к виртуальному адресу 0x00004105, то этот адрес разбивается на адрес виртуальной страницы (Virtual page number - 0x0004) и смещение (Offset - 0x105 - область внутри страницы, к которой идет обращение):
Смещение напрямую передается при доступе к физической странице памяти, а вот тэг виртуальной страницы ищется в TLB. В данном случае в TLB есть запись, что соответствующий этому тэгу адрес физической страницы это 0x0007, соответственно трансляция виртуальной страницы в физическую прошла успешно. Это называется TLB Hit, то есть попадание в кэш.
Возможна и другая ситуация - при декомпозиции виртуального адреса получаемый тэг 0x0003 отсутствует в TLB. В этом случае происходит поиск страницы в физической памяти по тэгу (страницу номер 3) и уже ее адрес транслируется (0x006). Далее запись с этим тэгом добавляется в TLB (при этом старые записи из кэша вытесняются, если он заполнен):
Надо отметить, что такая операция вызывает несколько большую задержку (так как приходится искать в глобальной памяти), и такая ситуация называется TLB Miss, то есть промах TLB.
Но это не самая плохая ситуация, так как счет latency все равно идет на наносекунды. Но доступ может быть и гораздо более долгий (миллисекунды и даже секунды) в том случае, если нужная гостевой ОС страница засвопировалась на диск.
Посмотрим на пример:
Виртуальная машина обратилась к виртуальному адресу 0x00000460, для которого есть тэг 0x0000. В физической памяти для этого тэга выделена страница 0, которая означает, что искать эту страницу нужно на диске, куда страница была сброшена ввиду недостатка физической оперативной памяти.
В этом случае страница восстанавливается с диска в оперативную память (вытесняя самую старую по времени обращения страницу), ну и далее происходит трансляция адреса к этой странице. Эта ситуация называется отказ страницы (Page Fault), что приводит к задержкам в операциях приложения, поэтому иногда полезно отслеживать Page Faults отдельных процессов, чтобы понимать причину падения быстродействия при работе с памятью.
Как знают многие администраторы, во время установки vCenter Server Appliance (vCSA) для управления виртуальной инфраструктурой изменить MAC-адрес управляющего сервера нельзя - он генерируется при развертывании виртуального модуля установщиком и прописывается внутрь конфигурации. Между тем, если вам это все-таки по каким-то причинам требуется, Вильям Лам привел способ, как это сделать.
Ниже приведена процедура развертывания vCSA с сервера VMware ESXi.
Во-первых, надо преобразовать OVA-модуль в формат OVF, где можно будет потом изменить настройки. Делается это с помощью утилиты ovftool следующим образом:
Далее изменяем скрипт VCSAStaticMACAddress.sh на сервере ESXi, чтобы добавить туда нужные параметры вашего vCSA и начать его развертывание в вашей виртуальной среде. Для этого его нужно выполнить с параметром --injectOvfEnv, про который написано вот тут. Он позволяет внедрить свойства OVF в виртуальный модуль vCSA при его включении.
Если вы все сделали правильно, то сможете наблюдать за прогрессом развертывания вашего виртуального модуля из браузера по ссылке:
https://[адрес VCSA]:5480
В итоге вы должны увидеть, что в настройках модуля vCSA вы получили нужный вам MAC-адрес:
Если вы хотите пропустить стадию конфигурации сетевых настроек (IP-адрес и прочее) при исполнении скрипта, нужно выставить переменную VCSA_STAGE1ANDSTAGE2 в значение false. Тогда после развертывания модуля vCSA нужно будет закончить его конфигурацию по ссылке:
https://[адрес VCSA]:5480
После развертывания эта возможность будет доступна на открывшейся странице:
На Reddit коллеги заметили, что при включении технологии Turbo Boost в процессорах Intel, из виртуальной машины увеличения производительности не наблюдается. Напомним, что Turbo Boost — это технология компании Intel для автоматического увеличения тактовой частоты процессора свыше номинальной, если при этом не превышаются ограничения мощности, температуры и тока в составе расчётной мощности (TDP).
При этом емкость CPU показывается прежней, даже при создании существенной нагрузки на процессор:
В комментариях люди правильно отвечают, что поскольку Turbo Boost - это аппаратная возможность, гостевая система виртуальной машины не ловит отображение увеличения аппаратной мощности в виртуальную машину. При этом если вы посмотрите на виртуальную машину с 4 процессорами 2.4 ГГц с уровня хоста ESXi с включенным Turbo Boost до 3 ГГц, вы увидите утилизацию процессора 4*3=12 ГГц.
То есть гостевая система вполне будет использовать преимущества этой технологии, но отображать утилизацию процессора она будет в соответствии с его номинальной мощностью.
На сайте проекта VMware Labs обновился пакет USB Network Native Driver for ESXi до версии 1.4, который содержит в себе драйверы для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.
Давайте посмотрим, что там появилось нового:
Добавлена поддержка USB-устройств SuperMicro/Insyde Software Corp.
Исправлена проблема больших кадров 9K Jumbo frames для устройств с чипсетом RTL8153.
Устранена ошибка с неправильным отображением пропускной способности для некоторых устройств на дефолтной скорости.
У VMware обнаружилась полезная интерактивная инфографика, которая наглядно показывает, что происходит с дисковыми объектами виртуальных машин хоста кластера хранилищ VMware vSAN, когда его переводят в режим обслуживания (Maintenance Mode). Напомним, что о том, как это работает, мы подробно писали вот тут.
Чтобы посмотреть различные сценарии работы данного режима, нужно открыть страничку по этой ссылке и нажать на кнопку Explore maintenance mode:
Далее можно будет выбрать основные параметры перевода в этот режим.
Сначала указываем способ миграции данных:
Full data migration - данные копируются на другие хосты таким образом, чтобы обеспечить исполнения политики FTT/RAID на оставшемся наборе хостов ESXi при введении в режим обслуживания одного или двух хостов.
Ensure Accessibility – это миграция только тех компонентов, которые есть в кластере в единственном экземпляре. При этом, для некоторых объектов на период обслуживания не будет соблюдена политика Failures to tolerate (FTT).
No Data Migration – в этом случае никакие компоненты не будут перемещены с хоста, поэтому некоторые ВМ могут оказаться недоступными (если на этом хосте их дисковые компоненты находятся в единственном экземпляре, а уровень RAID недостаточен для предоставления доступа к объекту).
Потом надо задать значение политики FTT и тип организации избыточности RAID0 для FTT=0, RAID1 или RAID5 для FTT=1, RAID6 для FTT=2. А далее нужно указать, один или два хоста мы переводим в режим обслуживания.
Например, если мы укажем, что нам нужен тип миграции Full data migration, при этом надо соблюсти политику FTT=2/RAID-6, то система попросит добавить еще один хост ESXi в кластер, так как оставшихся 5 хостов в этом случае будет не хватать, чтобы обеспечить требуемые политики.
Ну а при выборе выполнимого сценария будет показана анимация происходящего при переводе одного или двух хостов в режим обслуживания процесса, который вовлекает перемещение дисковых объектов виртуальных машин на другие хосты.
Надо сказать, что не рекомендуется переводить сразу 2 хоста в режим обслуживания, так как это может привести к тому, что невозможно будет обеспечить требуемые политики FTT/RAID в имеющейся аппаратной конфигурации (хотя перевод двух хостов в maintenance mode вполне поддерживается со стороны vSAN).
В общем, интересная штука - попробуйте посмотреть, как визуализируются различные сценарии.
Некоторые пользователи виртуальной инфраструктуры VMware vSphere после недавнего обновления браузера Google Chrome (а недавно вышел Chrome 80) заметили, что через vSphere Client 6.7 больше не получается подключиться:
В консоли браузера Chrome можно увидеть вот такую ошибку:
Error in connection establishment: net:: ERR_CERT_AUTHORITY_INVALID
Проблему эту подсветили наши коллеги с Reddit. Связана она с тем, что новый Chrome 80 имеет повышенные требования к безопасности и требует повторной генерации и установки сертификата с хоста ESXi. Решается проблема, как отметили в комментариях, следующим образом:
1. Идем на хост ESXi, открываем Networking -> TCP/IP stacks -> Default TCP/IP stack по ссылке:
Устанавливаем Host-name (например: esx1) и Domain-name (например: my.local) и сохраняем файл.
3. Идем по ssh на хост ESXi и выполняем там следующие команды:
cd /etc/vmware/ssl
/sbin/generate-certificates
Копируем файл castore.pem на клиентский комьютер и устанавливаем его в раздел "Trusted Root Certification Authorities". Для Windows переименовываем файл castore.pem в castore.pem.cer и просто устанавливаем его двойным кликом. Выбираем Local Machine->Manual->Browse->выбираем Trusted Root Certification Authorities.
4. Перезапускаем службу хоста ESXi:
/etc/init.d/hostd restart
После этого vSphere Client через Chrome 80 должен работать без проблем.
На сайте проекта VMware Labs появилась очередная интересная штука - утилита Pallas. Нужна она тем, у кого серверы ESXi находятся в изолированной относительно средств vCenter управления среде (за сетевыми экранами и далеко).
Понадобиться, например, это может в следующих случаях:
У вас несколько хостов ESXi, которые работают в полностью изолированной сети, но у вас есть требование по управлению ими из публичной сети.
Ваш хост ESXi не имеет кабельного соединения с сетью и должен быть подключен через WiFi или мобильное подключение. Например, ESXi работает на нефтяной вышке или в вагоне поезда, а вам нужно безопасно управлять этим хостом с сервера vCenter.
Ваш ESXi работает на IoT-компьютере (edge-девайс), а вам нужно удаленное управление таким хостом (патчинг, создание ВМ и т.п.).
Для этих целей создается специальная агентская виртуальная машина (Dominate agent VM), в которую напрямую (через pass-through) пробрасывается устройство, которое дает интернет (например, LTE-модем). Такая ВМ уже, в свою очередь, взаимодействует с хостом через ESXi SDK для выполнения функций управления (например, передача команд по развертыванию новой ВМ).
Эта машина взаимодействует уже с Pallas Manager через протокол MQTT, который не разрешает любые входящие соединения, то есть инфраструктура оказывается защищенной от доступа извне. Больше деталей об этом продукте можно узнать из видео ниже:
Документация по проекту Pallas находится здесь (просто выберите PDF из комбо-бокса загрузки), а скачать сам виртуальный модуль в формате OVA можно по этой же ссылке.
На днях компания VMware сделала анонс о грядущих изменениях в лицензировании платформы виртуализации VMware vSphere. Теперь понятие "лицензия на CPU" будет включать в себя процессоры, которые содержат до 32 физических ядер.
Если в процессоре больше ядер, то квантоваться они будут по 32 штуки - то есть, если в физическом CPU 64 ядра, то вам потребуется 2 лицензии VMware vSphere (2x32). Надо понимать, что речь идет о физических ядрах процессоров, а не о логических, доступных через Hyper-threading.
Процессоры с таким количеством ядер уже не за горами - например, AMD анонсировала процессор Ryzen 9 3990X с 64 ядрами, который будет стоить $4 000 (его обещают выпустить уже 7 февраля). Intel уже продает процессор Xeon Platinum 8280 с 28 ядрами на борту, но скоро в соревновании с AMD неизбежно надо будет делать больше ядер - так что изменения в лицензировании vSphere уже скоро станут вполне актуальны.
Наглядно новую схему лицензирования процессоров можно представить так:
Данные изменения вступят в силу 2 апреля 2020 года, но до 30 апреля действует grace period - то есть до этой даты вы сможете купить и лицензировать хосты VMware ESXi по старым правилам (очевидно, что VMware потребует доказательства приобретения и самих серверов до этой даты). Поэтому если до этого времени вдруг у ваших процессоров окажется очень много ядер - самое время будет приобрести лицензии VMware vSphere впрок.
Хотя бы раз у каждого администратора VMware vSphere была такая проблема, когда один или несколько хостов VMware ESXi в консоли vSphere Client на сервере vCenter отображались в статусе Not Responding. Причин для этого может быть масса, сегодня мы постараемся разобрать наиболее частые из них.
1. Прежде всего, надо убедиться, что хост ESXi находится во включенном состоянии.
Желательно убедиться в этом как физически (сервер включен в стойке), так и взглянуть на его консоль (например, через iLO/iDRAC). Ситуация может быть такой, что хост выпал в PSOD (Purple Screen of Death, он же Purple Diagnostic Screen).
В этом случае с хостом надо разбираться в соответствии со статьей KB 1004250 и повторно добавлять его к серверу vCenter, когда он успешно загрузится.
2. Если хост ESXi включен, но все еще находится в статусе Not Responding, надо попробовать перезапустить там Management agents (операция Restart Management Network).
Они включают в себя сервисы по коммуникации между сервером vCenter и хостом ESXi. Делается это в соответствии со статьей KB 1003490.
Также будет не лишним выполнить тест сети управления - опция Test Management Network. Ошибки, возникающие при этом, помогут понять, что случилось:
3. Проверьте, что со стороны vCenter Server у вас есть соединение с хостом ESXi - как по IP, так и по FQDN.
Казалось бы очевидный шаг, который не все выполняют первым при первичной диагностике. Просто сделайте пинг хоста ESXi со стороны сервера vCenter:
4. Убедитесь, что со стороны сервера ESXi также виден сервер vCenter.
Дело в том, что vCenter ожидает регулярных хартбитов со стороны хостов ESXi, чтобы считать их подключенными. Если в течение 60 секунд он не получает таких хартбитов, то он объявляет хост ESXi Not Responding, а в конечном итоге и Disconnected.
Иногда такое состояние возникает, когда сервер vCenter спрятан за NAT относительно хостов ESXi:
В этом случае серверы ESXi не смогут достучаться до сервера vCenter. Более того, такая конфигурация вообще не поддерживается со стороны VMware (см. статью KB 1010652), несмотря на то, что для нее существует workaround.
Ваша задача - обеспечить коммуникацию хоста ESXi с сервером vCenter по порту 902 (TCP/UDP):
Кстати, таймаут в 60 секунд для хартбитов можно увеличить, например, до 120 секунд, если у вас большие задержки в сети. Для этого нужно изменить значение параметра config.vpxd.heartbeat.notrespondingtimeout в расширенных настройках сервера vCenter, как описано в статье KB 1005757.
5. Попробуйте убрать хост ESXi из инвентори vCenter и добавить его снова.
Делается это в соответствии со статьей KB 1003480. Просто выберите для хост ESXi в контекстном меню vSphere Client опцию Disconnect:
Потом просто добавьте хост ESXi в окружение vCenter снова.
6. Если ничего из этого не помогло - время заглянуть в логи.
В первую очередь надо посмотреть в лог агента vpxa (/var/log/vpxa.log), как описано в статье KB 1006128. Например, причиной того, что агент vpxa не стартует может оказаться нехватка памяти, выделенной для сервисов ESXi. Тогда в логе vpxa будет что-то вроде этого:
[2007-07-28 17:57:25.416 'Memory checker' 5458864 error] Current value 143700 exceeds hard limit 128000. Shutting down process.
[2007-07-28 17:57:25.420 'Memory checker' 3076453280 info] Resource checker stopped.
Также нужно убедиться, что процесс hostd работает и отвечает на команды. Для этого можно заглянуть в лог hostd (/var/log/vmware/hostd.log), как описано в KB 1002849. Например, там может быть вот такая ошибка:
2014-06-27T19:57:41.000Z [282DFB70 info 'Vimsvc.ha-eventmgr'] Event 8002 : Issue detected on sg-pgh-srv2-esx10.sg-pgh.idealcloud.local in ha-datacenter: hostd detected to be non-responsive
Ошибки могут вызывать разные причины, но наиболее частая из них - нехватка ресурсов для сервиса hostd.
7. Последнее, но не менее важное - проверить, нет ли проблем с хранилищем.
Если все остальное уже посмотрели, то нужно обязательно отработать вариант с неполадками хранилища на хосте ESXi. Основные рекомендации по этому случаю даны в KB 1003659. Диаграмма траблшутинга в этом случае выглядит следующим образом (кликабельно):
Вывод
Если ваш хост ESXi перешел в статус Not Responding или Disconnected, попробуйте сначала такие простые действия, как проверка включенности самого ESXi, пинг хостов vCenter и ESXi в обе стороны (не забыв также порт 902), рестарт Management agents, передобавление хоста ESXi в инвентори. Потом посмотрите более сложные варианты, такие как работоспособность агента vpxa и сервиса hostd. Ну а потом уже проверяйте работу хранилищ на ESXi, где может быть много всякого рода проблем.
На сайте проекта VMware Labs появилась действительно интересная новинка - утилита vSphere Software Asset Management (vSAM). С помощью vSAM можно собрать подробную информацию об инсталляции VMware vSphere на вашей площадке, касающуюся лицензий - весь инвентарь и доступные лицензии, проще говоря, ассеты.
Утилита забирает все данные по API и генерирует отчет об использовании лицензий виртуальной инфраструктуре в формате PDF, который могут использовать администраторы, менеджеры и консультанты для целей отчетности, планирования и любых других.
Сама утилита vSAM представляет собой легковесное Java-приложение, которое может работать под Windows, Linux или Mac OS. Давайте посмотрим на его возможности:
Поддержка кластера хостов ESXi под управлением vCenter Server, а также отдельных серверов ESXi с версиями vSphere 5.5, 6.x или более новыми.
Генерация комплексных отчетов в следующих категориях:
Высокоуровневая информация об инсталляции
Отчет о компонентах (отдельные ESXi или кластер серверов с vCenter)
Высокоуровневый отчет об использовании лицензионных ключей
Генерация рекомендаций в следующих сферах:
Оповещение об использовании триальной лицензии
Срок лицензии:
Оповещение об истечении лицензии через 90 дней
Алерты об истекших лицензиях
Емкость доступных лицензий
Оповещение об использовании лицензий выше заданного порога
Оповещение о нехватке лицензий
Алерт о превышении лицензионных лимитов
Жизненный цикл продуктов
Информация по вступлении в фазу End of General Support info
Оповещение за 90 дней для EoGS
Нотификация о неподдерживаемых больше продуктах
Защита чувствительной информации за счет:
Сбор данных только для задачи Software Asset Management
Маскирование чувствительной информации в отчете
Поддержка шифрования файла с сырыми данными
Поддержка объединения нескольких отчетов в один
Поддержка английского и китайского языков
Поддержка кастомизации отчетов
Вот примеры сгенерированных отчетов:
Скачать утилиту VMware vSphere Software Asset Management Tool можно по этой ссылке.
Некоторые администраторы сталкиваются с такой конфигурацией виртуальной инфраструктуры, когда управляющий сервер VMware vCenter оказывается за NAT или сетевым экраном относительно части хостов VMware ESXi:
В этом случае получается добавить хосты ESXi в vCenter, но через примерно одну минуту они уходят в офлайн, при этом успешно пингуются. Также в течение этой минуты, пока они видны в vCenter, хосты не могут синхронизировать свою конфигурацию. Причина такого поведения проста - в агент vCenter на хостах ESXi (он же vpxa) прописывается внутренний адрес vCenter для связи со стороны ESXi.
Эти хартбиты идут на целевой порт 902 TCP/UDP (источник варьируется):
Если погуглить, то можно найти статью KB 1010652, где сказано, что такая конфигурация не поддерживается со стороны VMware.
Но есть обходной путь, который вполне работает у многих пользователей. Нужно открыть 902 порт на вашем фаерволе/NAT, а также поменять в файле конфигурации агента vCenter
/etc/vmware/vpxa/vpxa.cfg
строчку:
<serverIp>10.0.0.1</serverIp> на внешний IP-адрес вашего NAT-маршрутизатора. Также нужно добавить следующий параметр в этот файл, чтобы указанный IP не поменялся назад:
<preserveServerIp>true</preserveServerIp>
Перед редактированием файла vpxa.cfg нужно поменять права доступа командой:
chmod 744 /etc/vmware/vpxa/vpxa.cfg
а после редактирования вернуть их назад:
chmod 444 /etc/vmware/vpxa/vpxa.cfg
По окончании процедуры надо перезапустить management agents на хостах ESXi командой:
services.sh restart
И надо понимать, что данная конфигурация хоть и работает, но не поддерживается со стороны VMware. Официально для размещения vCenter за NAT workaround не существует.
Многие крупные организации до сих пор используют платформу VMware vSphere 6.0 в качестве основы своей ИТ-инфраструктуры. Это обусловлено трудностями планирования апгрейда для большого парка серверов, лицензионной спецификой и в целом нежеланием трогать то, что работает хорошо.
Но надо обязательно напомнить, что 12 марта 2020 года, согласно плану, указанному в документе VMware Lifecycle Product Matrix, платформе vSphere 6.0 и гипервизору ESXi 6.0 наступает End of Life (EoL), а в терминологии VMware - End of General Support:
Согласно политикам VMware Support Policies, статус End of General Support для продуктов VMware означает, что для них перестают выпускаться существенные обновления и патчи. Поддержка по телефону также заканчивается, а с точки зрения апдейтов выпускаются только самые критичные обновления, закрывающие дырки безопасности и самые серьезные баги. То есть продукт входит в фазу Technical Guidance:
В связи с этим, пользователям vSphere 6.0 настоятельно рекомендуется провести обновление до версий vSphere 6.5 или 6.7 к этому времени. Кстати, надо отметить, что у обеих версий дата перехода в фазу Technical Guidance одна и та же - 15 ноября 2021 года:
Совместимость вашей платформы VMware vSphere 6.0, а точнее ее компонентов ESXi 6.0 и vCenter 6.0, с другими продуктами VMware вы можете проверить на специальной странице VMware Product Interoperability Matrices:
Для большинства ИТ-специалистов виртуализация ассоциируется с накладными расходами на ее содержание. Виртуальная машина имеет такие-то потери по CPU и столько-то издержки по оперативной памяти. Но иногда бывает и обратная ситуация - например, в статье про производительность контейнеров на платформе Project Pacific утверждается, что в виртуальных машинах они работают на 8% быстрее, чем на голом железе с Linux на борту.
Давайте посмотрим, почему это может быть так.
Сначала для тестирования взяли 2 идентичных аппаратных конфигурации (кластер из двух узлов), на одной из которых развернули гипервизор ESXi на платформе Project Pacific (там Kubernetes pods работают в виртуальных машинах), а на второй поставили Linux с Kubernetes pods (видимо, подразумевается Red Hat) с настройками из коробки, которые работают нативно:
VMware объясняет высокую производительность Project Pacific тем, что гипервизор воспринимает Pods как изолированные сущности, которые можно адресовать на CPU для наиболее подходящих локальных NUMA-узлов. Планировщик ESXi уже давно умеет эффективно работать с NUMA-узлами для vCPU ВМ, поэтому вполне логично ожидать здесь хороших результатов.
При настройке Kubernetes на Linux пользователь, с точки зрения выделения ресурсов CPU, оперирует логическими ядрами, которые дает технология hyperthreading, а при настройке виртуальных машин - физическими pCPU, то есть физическими ядрами процессора. Поэтому для чистоты эксперимента в тестах производительности VMware отключала hyperthreading.
Конфигурация каждого Pod выглядела так:
Всего было развернуто 10 Kubernetes pods, каждый из которых имел лимит по ресурсам 8 CPU и 42 ГБ RAM. Далее там был запущен один из Java-бенчмарков, целевым показателем которого была полоса пропускания (maximum throughput).
Результат оказался следующим:
Из графика видно, что кластер vSphere дал на 8% лучше результаты, чем нативный кластер Kubernetes на Linux.
Чтобы понять механику процесса, VMware замерила число попаданий в local DRAM (на уровне локального NUMA-домена) по сравнению с remote DRAM при условии промаха кэша в L3 процессора.
Для ESXi число таких попаданий составило 99,2%:
Это означает, что планировщик ESXi умеет размещать процессы ВМ таким образом, чтобы они могли получать более быстрый доступ к local DRAM.
Если же использовать привязку узлов к NUMA-доменам (Numactl-based pinning) в Linux, то результат работы нативных контейнеров выглядит лучше, чем таковой в виртуальных машинах:
Между тем, такая жесткая привязка узлов Kubernetes к NUMA-узлам оказывается непрактичной, когда требуется развертывать большое количество контейнеров, и возникает большая вероятность ошибок в конфигурациях.
Поэтому из коробки получается, что контейнеры Project Pacific работают лучше, чем на Linux-платформе в контексте использования ресурсов CPU.
Таги: VMware, Kubernetes, Performance, ESXi, vSphere, CPU
На днях компания VMware зарелизила небольшие обновления компонентов платформы виртуализации vSphere 6.7 Update 3b. Release notes для vCenter 6.7 Update 3b можно посмотреть тут, а для ESXi 6.7 Update 3b - тут.
Нововведений особо никаких в новых апдейтах нет, в основном это фиксы подсистемы безопасности, которые регулярно выходят для всех компонентов VMware vSphere. Хотя один стоящий внимания багофикс все же есть - это исправление ошибки "After you revert a virtual machine to a snapshot, change block tracking (CBT) data might be corrupted". То есть, снова возрождался баг о том, что данные, резервируемые с использованием трекинга изменившихся блоков CBT (а это используют все системы резервного копирования), могут оказаться поврежденными.
Напомним, что прошлый апдейт пакета (vSphere 6.7 Update 3a) также не содержал существенных обновлений.
Скачать компоненты платформы VMware vSphere 6.7 Update 3b можно по этой ссылке.
Инфраструктура remote offices and branch offices (ROBO), как правило, удалена от основного датацентра компании, что вызывает влияние на сетевые характеристики, такие как полоса пропускания, задержки в сети и ошибки в доставке пакетов. На эту тему в документе есть интересная табличка:
Авторы документа отмечают, что больше всего на производительность операций vCenter влияет не полоса пропускания, а latency между сервером vCenter (который может быть в головном офисе) и хостами ESXi (которые могут быть на удаленной площадке). В случае больших задержек для прохождения команд от vCenter, время выполнения операций с виртуальными машинами также возрастает:
В общем, всем тем, кто использует виртуальную инфраструктуру в удаленных офисах и филиалах, документ рекомендуется к прочтению.
Многим администраторам VMware vSphere иногда требуется собрать некоторые базовые сведения об имеющихся в виртуальной инфраструктуре виртуальных машинах и их гостевых системах. Традиционные способы сбора такой информации применимы лишь частично - ведь стандартный софт для собора ассетов не может взглянуть внутрь хостов ESXi и задокументировать их внутреннюю структуру. Также надо понимать, что софт, использующий ICMP-протокол (а именно команду ping) также не подходит для этой задачи, так как далеко не все системы сегодня отвечают на пинг.
Давайте посмотрим на способы, которые доступны для этой задачи:
1. Функция экспорта в vSphere Client.
Это самое первое, что вам следует сделать для решения проблемы инвентаризации ассетов в виртуальной среде. Кнопка экспорта находится в нижнем правом углу инвентори клиента. С помощью этой фичи можно выгрузить любое представление с нужными колонками в формат CSV:
Здесь вы сможете выгрузить то, чего больше не сможете выгрузить нигде, например, сведения о поддержке TPM, функциях безопасной загрузки Secure Boot для ESXi и гостевых ОС, поддержке Microsoft Device Guard & Credential Guard и функций шифрования VM Encryption.
2. Экспорт через PowerCLI.
PowerCLI, как вы знаете, может все, что может GUI, плюс несколько больше. Поэтому он вам может понадобиться для расширенных параметров виртуальной среды. Основные шаблоны для работы с PowerCLI можно найти здесь.
Вот так, например, работают командлеты Get-VM и Get-VMGuest:
А вот так Get-VMHost:
Результаты работы можно сохранить в текстовый файл с помощью командлета Out-File или в CSV-файл с помощью Export-Csv.
3. Утилита nmap.
Эта утилита знакома всем сетевым администраторам, ведь ей уже более 20 лет. Ее используют как в физической, так и в виртуальной среде для сбора информации о системах и сервисах, висящих на соответствующих портах. Для Linux систем утилита часто поставляется в комплекте дистрибутива, для Windows она доступна тут.
Вот такой командой можно просканировать подсеть:
nmap -sn 192.168.1.0/24
Помните, что такое сканирование может привлечь внимание систем безопасности, и к вам обязательно придет сотрудник соответствующей службы, если такая у вас в компании есть)
4. Утилита RVTools.
Мы часто пишем об этой утилите (последний раз писали тут). Она предназначена для помощи администраторам при выполнении рутинных операций с виртуальной инфраструктурой VMware vSphere в различных аспектах, в том числе документировании.
Вот так выглядит инвентаризация виртуальных машин:
Удобно, что результаты можно сохранить не только в CSV, но и в нативный Excel-формат.
5. Утилита vDocumentation.
Об этой утилите мы писали вот тут. По сути, это набор сценариев, который позволяет через PowerCLI сгенерировать отчетность в форматах CSV или XLS, посвященную различным сторонам виртуальной инфраструктуры (сеть, хосты, кластеры vSAN и т.п.).
6. Утилита vCheck.
Об этой утилите для VMware vSphere мы уже писали вот тут. Кстати, недавно вышла ее версия для инфраструктуры виртуальных ПК VMware Horizon. vCheck - это PowerCLI-скрипт, который готовит отчетность по объектам окружения VMware vSphere и отсылает результат на почту администратора, из которого можно узнать о текущем состоянии виртуальной инфраструктуры и определить потенциальные проблемы.
Бесспорно, всего этого достаточно для сбора сведений об объектах виртуальной инфраструктуры, но не забывайте, что нужно еще иногда инвентаризировать и прочие объекты - интерфейсы iLO/iDRAC, физические коммутаторы, аппаратные сетевые экраны и прочие системы в датацентре.
В сентябре этого года мы рассказывали о возможностях новой версии решения для мониторинга и защиты сетевой составляющей виртуальной среды VMware vRealize Network Insight 5.0 (vRNI). Напомним, что это решение позволяет системным и сетевым администраторам (а также администраторам информационной безопасности) наблюдать за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.
В рамках прошедшего VMworld Europe 2019 компания VMware анонсировала обновление этой платформы - vRNI 5.1. Давайте посмотрим, что в этом решении появилось нового.
Во-первых, VMware продолжает улучшать функции SD-WAN, которые появились в продукте благодаря технологиям купленной компании VeloCloud. В духе фичи Virtual Network Assessment for NSX, версия vRNI 5.1 имеет функцию SD-WAN Assessment. Она анализирует трафик и данные из имеющейся невиртуализированной сети WAN и рассчитывает возврат инвестиций, если вы решите вложить деньги во внедрение решения SD-WAN.
Во-вторых, VMware добавила в vRNI новый дэшборд - VMware Cloud on AWS dashboard. Он позволяет вести мониторинг среды AWS в контексте концепции software defined data center (SDDC) и поддерживает компонент AWS Edge firewall, что дает возможности просмотра правил и их маппинга на сетевые потоки.
Третья интересная возможность vRNI 5.1 - функции для операций ежедневного обслуживания (Day-2 operation), такие как просмотр общего состояния инфраструктуры приложений, возможность просмотра упавших по скорости потоков, анализ трафика и другие средства, доступные в Application Dashboard.
Четвертая новая фича - поддержка физического NAT при анализе пути VM-VM, а также поддержка аппаратного Arista VTEP.
Ну и последняя новая возможность vRNI 5.1 - это улучшение функций для операций ежедневного обслуживания для решения VMware NSX-T, а также доработанные средства визуализации развернутых и затронутых изменениями компонентов.
Решение VMware vRealize Network Insight 5.1 пока нельзя скачать, но в скором времени VMware обещает его публичную доступность.
Project Pacific был одним из главных анонсов конференции VMworld в этом году, и VMware обращала на него особенное внимание. Это неудивительно - ведь VMware делает поддержку Kubernetes не для галочки. Тут дело в том, что многие пользователи планируют развертывание инфраструктуры контейнеризованных приложений на физической инфраструктуре - в этом случае не надо нести издержки на гипервизор и лицензии, а сами приложения в контейнерах работают быстро и имеют встроенные средства обеспечения доступности.
На сайте проекта VMware Labs очередное обновление - вышла новая версия продукта Virtual Machine Compute Optimizer 2.0. Это средство представляет собой PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.
Напомним, что о первой версии данной утилиты мы писали летом этого года вот тут. Давайте посмотрим, что нового появилось в Virtual Machine Compute Optimizer 2.0:
Собираются приоритеты найденных несоответствий.
Вывод деталей найденных несоответствий.
Собирается информация о кластере, чтобы определить совместимость оборудования хостов на уровне кластера.
В отчет добавляется информация, если виртуальная машина использует разные физические pNUMA узлы, которые транслируются в гостевую ОС.
Добавляется информация об измененных расширенных настройках на уровне ВМ или хоста ESXi, касающихся представления pNUMA-узлов в гостевую ОС.
В отчет попадают ВМ, если у них число vCPU (с использованием гипертрэдов как vCPU) превышает число физических ядер CPU на хосте ESXi.
Возможность использовать отдельную функцию Get-OptimalvCPU для получения еще большей гибкости.
Скачать VM Compute Optimizer 2.0 можно по этой ссылке. Данный сценарий PowerCLI можно запустить различными способами, смотрите сопровождающий PDF (можно выбрать в комбобоксе при загрузке) для получения более детальной информации.
Большинство из вас, конечно же, слышало о серии уязвимостей в процессорах Intel (например, Meltdown и Spectre), которые потенциально могли приводить к получению контроля над исполнением систем (в том числе виртуальных машин), работающих на базе определенных CPU. Об этом можно прочитать у нас, например, тут и тут.
При обнаружении таких уязвимостей Intel выпускает обновления микрокода (firmware) для своих процессоров, которые нужно применить как к серверам ESXi, так и к виртуальным машинам. Например, для устранения уязвимости типа MDS была добавлена инструкция MD_CLEAR, которую гостевая ОС может обнаружить и использовать для защиты от определенных уязвимостей.
В виртуальной среде виртуальная машина - это VMX-процесс на сервере ESXi, который обеспечивает исполнение гостевой операционной системы. При этом ВМ может перемещаться между серверами ESXi средствами vMotion, поэтому она может иметь довольно большой аптайм (больше самих хостов, где она работает) и, как следствие, долго не обновлять виртуальное аппаратное обеспечение.
В то же время, для патчинга некоторых уязвимостей нужно обновить микрокод CPU и пересоздать VMX-процесс виртуальной машины, чтобы она могла инициализировать и подхватить обновления микрокода (что происходит только при первой загрузке). Простая перезагрузка тут не поможет, так как в этом случае пересоздания VMX не происходит, а лишь идет ребут гостевой системы. Кстати, это вам на заметку - если хотите "почистить" виртуальную машину, то лучше выключить и включить ее, а не перезагружать.
Чтобы выполнить процедуру выключения и включения, начиная с vSphere 6.5 Update 3 и vSphere 6.7 Update 3, компания VMware ввела инструкцию vmx.reboot.PowerCycle, которая выполняет цикл питания виртуальной машины. Этот параметр, который можно добавить в VMX-файл, считывается со стороны VMware Tools, которые уже совместно с хостом ESXi обеспечивают исполнение этого цикла.
Чтобы добавить этот параметр в VMX-файл через PowerCLI, вы можете использовать следующую команду:
Эти команды можно сопроводить принудительным флагом исполнения -Force и контролировать поведение в случае ошибки с помощью -ErrorAction.
После того, как параметр PowerCycle будет выставлен, VMware Tools (вы же помните, что они должны быть установлены) смогут совершить цикл сброса питания для виртуальной машины, а затем сам параметр будет удален из VMX-файла. Также он будет удален автоматически, если вы вручную завершите и снова запустите виртуальную машину.
Для контроля того, что параметр установлен, вы можете посмотреть в vSphere Client, в разделе Configuration Parameters (в самом низу):
Также использование данного параметра может вам помочь в случае кластеров Enhanced vMotion Compatibility (EVC). Такие кластеры требуют от виртуальных машин поддержки единого базового уровня инструкций CPU для обеспечения vMotion между хостами с разным аппаратным обеспечением.
В случае, если у вас где-то поменялось железо на хостах, то нужно выполнить перезапуск цикла питания виртуальных машин, что приведет кластер EVC к единому базовому уровню и позволит избавиться от потенциальных проблем.
Часто при миграциях vMotion виртуальной машины с одного хоста ESXi на другой возникает проблема, источник которой не очень понятен. Большинство администраторов знают основные требования vMotion, также при миграции иногда показываются информационные сообщения, отражающие причину, по которой процесс завершился неудачно.
Но такое бывает не всегда, поэтому давайте посмотрим, как правильно искать причины ошибок vMotion в логах хостов. Для начала напомним основные причины проблем с vMotion:
Проблемы сетевых соединений vMotion
Хосты ESXi не пингуются или отваливаются по таймауту в 20 секунд.
Несоответствие MTU между интерфейсом VMkernel и данным параметром в сети (на коммутаторах или маршрутизаторах).
Неправильная конфигурация сети на хостах ESXi.
Проблемы хранилищ
Целевой датастор недоступен или переведен в статус APD (All Paths Down).
Таймаут операций ввода-вывода (I/O) составляет 20 секунд или более.
Операция vMotion прошла успешно, но наблюдаются проблемы с гостевой ОС.
Ошибка VM network is not reachable – на уровне layer-2 нет соединения на целевом хосте ESXi.
Ошибки, связанные с ресурсами.
В течение долгого времени хост не может выделить память виртуальной машине.
Свопирование идет очень долго, что приводит к вываливанию vMotion по таймауту.
При траблшутинге vMotion, в первую очередь, проверьте, что в вашей инфраструктуре соблюдаются основные требования, приведенные здесь.
С точки зрения логирования процесса vMotion, он устроен следующим образом:
Из картинки видно, что 4 лог-файла можно найти на хосте ESXi и один - на сервере vCenter.
Демоны vCenter Daemon (VPXD), vCenter Agent (VPXA) и Host Daemon (hostd) - это основные службы, которые отвечают за процесс миграции vMotion, и именно там следует начинать искать проблему. Что касается компонентов, отвечающих за реализацию на стороне ВМ - это процесс VMX и службы VMkernel.
Первый шаг траблшутинга - это найти Operation ID (opID) операции vMotion в логах. Этот opID отсылает уже к нужному Migration ID на обоих хостах ESXi.
VPXD-лог на vCenter Server позволит найти opID. Для этого залогиньтесь на VCSA (vCenter Server Appliance) и выполните команду:
grep "relocate" /var/log/vmware/vpxd/vpxd-*.log | grep BEGIN
В выводе команды вы найдете нужный opID:
/var/log/vmware/vpxd/vpxd-214.log:2019-09-24T15:38:10.042Z info vpxd[29243] [Originator@6876 sub=vpxLro opID=jzlgfw8g-11824-auto-94h-h5:70003561-20] [VpxLRO] — BEGIN task-8031 — vm-269 — vim.VirtualMachine.relocate — 52b17681-35d1-998b-da39-de07b7925dda(520681db-25b7-c5d6-44d7-6a056620e043)
Далее, зная opID, вы можете найти Migration ID в hostd-логах на соответствующих хостах ESXi. Делается это следующей командой:
В выводе вы можете увидеть такие интересные вещи, как, например, средняя скорость (average bandwidth), которая была получена при передаче данных (см. вывод).
В папке с виртуальной машиной находится файл vmware.log, в котором также можно найти информацию о неудавшемся vMotion с учетом исходного и целевого IP-адресов хостов ESXi:
2019-09-24T15:38:47.280Z| vmx| I125: Received migrate ‘from’ request for mid id 3117907752192811422, src ip <192.168.200.93>.
2019-09-24T15:38:47.280Z| vmx| I125: MigrateSetInfo: state=8 srcIp=<192.168.200.93> dstIp=<192.168.200.91> mid=3117907752192811422 uuid=4c4c4544-004a-4c10-8044-c7c04f4d4e32 priority=high
2019-09-24T15:38:47.282Z| vmx| I125: MigID: 3117907752192811422
2019-09-24T15:39:34.971Z| vmx| I125: Migrate_Open: Restoring from <192.168.200.93> with migration id 3117907752192811422
2019-09-24T15:39:35.023Z| vmx| I125: Migrate_Open: Restoring from <192.168.200.93> with migration id 3117907752192811422
Некоторое время назад мы писали о новых возможностях решения для создания отказоустойчивых хранилищ на базе хост-серверов VMware vSAN 6.7 Update 3. Среди прочего там появилось пара расширенных настроек, на которые обратил внимание Cormac Hogan. Давайте посмотрим, чем управляют эти Advanced Options в кластере.
Чтобы увидеть новые опции, надо в vSphere Client пойти в Cluster > Configure > vSAN > Services > Advanced Options, где можно увидеть параметры Large Cluster Support и Automatic Rebalance:
Первая настройка, как понятно из названия, регулирует возможность создания кластеров, которые имеют более 32 узлов. Ранее, чтобы расширить кластер, нужно было выставить параметр TcpipHeapMax на всех его хост-серверах ESXi. Теперь это удобно сделано в Advanced Options и применяется на уровне всего кластера.
Настройка Large Cluster Support требует перезагрузки каждого из хост-серверов:
Если вы не перезагрузите хосты, что в разделе статуса "vSAN extended configuration in sync" будут отображаться ошибки:
Вторая настройка, Automatic Rebalance, относится к дисковым объектам кластера vSAN, которые распределяются по дисковым группам разных хостов. Если данная настройка включена, то кластер vSAN автоматически наблюдает за балансом распределения дисковых объектов по хостам ESXi и выравнивает нагрузку на дисковые устройства. По умолчанию пороговое значение составляет 30%, что означает, что когда разница нагрузки между двумя дисковыми устройствами достигнет этого значения - начнется перебалансировка и перемещение дисковых объектов. Она будет продолжаться, пока это значение не снизится до 15% или меньшей величины.
Также в разделе vSAN Disk Balance вы найдете информацию по использованию дисковой подсистемы кластера:
В случае, если у вас включена настройка Automatic Rebalance, кластер vSAN будет стараться поддерживать этот хэлсчек всегда зеленым. Если же отключена - то в случае возникновения дисбаланса загорится алерт, и администратору нужно будет вручную запустить задачу Rebalance Disks.
На блогах VMware появилась интересная статья о том, как работает связка кэширующего яруса (Cache tier) с ярусом хранения данных (Capacity tier) на хостах кластера VMware vSAN в контексте производительности. Многие пользователи задаются вопросом - а стоит ли ставить более быстрые устройства на хосты ESXi в Capacity tier и стоит ли увеличивать их объем? Насколько это важно для производительности?
Системы кэширования работают в датацентре на всех уровнях - это сетевые коммутаторы, процессоры серверов и видеокарт, контроллеры хранилищ и т.п. Основная цель кэширования - предоставить высокопроизводительный ярус для приема операций ввода-вывода с высокой интенсивностью и малым временем отклика (это обеспечивают дорогие устройства), после чего сбросить эти операции на постоянное устройство хранения или отправить в нужный канал (для этого используются уже более дешевые устройства).
В кластере vSAN это выглядит вот так:
Второе преимущество двухъярусной архитектуры заключается в возможности манипуляции данными не на лету (чтобы не затормаживать поток чтения-записи), а уже при их сбрасывании на Capacity tier. Например, так работают сервисы компрессии и дедупликации в VMware vSAN - эти процессы происходят уже на уровне яруса хранения, что позволяет виртуальной машине не испытывать просадок производительности на уровне яруса кэширования.
Общая производительность двухъярусной системы зависит как от производительности яруса хранения, так и параметров яруса кэширования (а именно скорость работы и его объем). Ярус кэширования позволяет в течение определенного времени принимать операции ввода-вывода с очень большой интенсивностью, превышающей возможности приема яруса хранения, но по прошествии этого времени буфер очищается, так как требуется время для сброса данных на уровень постоянного хранения.
С точки зрения производительности это можно представить так (слева система с ярусом кэширования и хранения, справа - только с ярусом хранения):
Оказывается, в реальном мире большинство профилей нагрузки выглядят именно как на картинке слева, то есть система принимает большую нагрузку пачками (burst), после чего наступает некоторый перерыв, который устройства кэширования кластера vSAN используют для сброса данных на постоянные диски (drain).
Если вы поставите более производительное устройство кэширования и большего объема, то оно сможет в течение большего времени и быстрее "впитывать" в себя пачки операций ввода-вывода, которые возникают в результате всплесков нагрузки:
Но более быстрое устройство при равном объеме будет "наполняться" быстрее при большом потоке ввода-вывода, что уменьшит время, в течение которого оно сможет обслуживать такие всплески на пиковой скорости (зато во время них не будет проблем производительности). Здесь нужно подбирать устройства кэширования именно под ваш профиль нагрузки.
С точки зрения устройств кэширования и хранения, кластер VMware vSAN представлен дисковыми группами, в каждой из которых есть как минимум одно устройство кэширования и несколько дисков хранения:
Для устройств кэширования на уровне одной дисковой группы установлен лимит в 600 ГБ. Однако это не значит, что нельзя использовать ярус большего объема. Мало того, некоторые пользователи vSAN как раз используют больший объем, так как в этом случае запись происходит во все доступные ячейки SSD (но суммарный объем буфера все равно не превышает лимит), что приводит к меньшему изнашиванию устройств в целом. Например, так происходит в кластере All-flash - там все доступная свободная емкость (но до 600 ГБ) резервируется для кэша.
Надо еще понимать, что если вы поставите очень быстрые устройства кэширования, но небольшого объема - они будут быстро заполняться на пиковой скорости, а потом брать "паузу" на сброс данных на ярус хранения. Таким образом, здесь нужен компромисс между объемом и производительностью кэша.
На базе сказанного выше можно дать следующие рекомендации по оптимизации производительности двухъярусной системы хранения в кластерах VMware vSAN:
Старайтесь использовать устройства кэширования большего объема, чтобы они могли впитывать большой поток ввода-вывода в течение большего времени. Производительность устройств уже рассматривайте во вторую очередь, только если у вас уж очень большой поток во время всплесков, который нужно обслуживать очень быстро.
Добавляйте больше дисковых групп, каждую из которых может обслуживать свое устройство кэширования. На уровне дисковой группы установлен лимит в 600 ГБ, но всего на хосте может быть до 3 ТБ буфера, поделенного на 5 дисковых групп.
Используйте более производительные устройства в ярусе хранения - так сброс данных буфера (destage rate) на них будет происходить быстрее, что приведет к более быстрой готовности оного обслуживать пиковую нагрузку.
Увеличивайте число устройств хранения в дисковой группе - это увеличит скорость дестейджинга данных на них в параллельном режиме.
Отслеживайте производительность кластера с помощью vSAN Performance Service, чтобы увидеть моменты, когда ярус кэширования захлебывается по производительности. Это позволит соотнести поведение буфера и профиля нагрузки и принять решения по сайзингу яруса кэширования и яруса хранения.
Используйте самые последнии версии VMware vSAN. Например, в vSAN 6.7 Update 3 было сделано множество программных оптимизаций производительности, особенно в плане компрессии и дедупликации данных. Всегда имеет смысл быть в курсе, что нового появилось в апдейте и накатывать его своевременно.
На сайте проекта VMware Labs появилось очередное обновление USB Network Native Driver 1.2 - драйвера для сетевых адаптеров серверов, которые подключаются через USB-порт. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. Напомним, что о версии 1.1 данного драйвера мы писали в июне этого года вот тут.
Обновленный USB Network Native Driver 1.2 теперь дополнительно поддерживает следующие устройства:
Aquantia Multi-Gig (1G/2.5G/5G) USB network adapter (компания Aquantia - это часть Marvell, кстати это также и производитель адаптеров 10GbE NICs в Mac Mini 2018 и новых iMac Pro).
Поддержка функции Auto Speed/Connection detection для чипсетов RTL8153/RTL8152.
Таким образом, полный список поддерживаемых теперь устройств выглядит так:
Как пишет Вильям Лам, адаптер USB-based Multi-Gigabit Network Adapter (QNA-UC5G1T) от QNAP теперь полностью поддерживается (он есть в таблице выше), и он может работать на скоростях 1Gbps, 2.5Gbps и 5Gbps. Но на практике USB 3.1 выдает не больше 3Gbps:
Скачать USB Network Native Driver 1.2 можно по этой ссылке.
В рамках серии анонсов, представленных на прошедшей конференции VMworld 2019, компания VMware представила интересное средство, которое может оказаться полезным администраторам виртуальной инфраструктуры - vSphere Assessment Tool (vSAT).
Главное назначение этой утилиты - помочь ИТ-специалистам перед миграцией инфраструктуры VMware vSphere на новую версию: заранее понять потенциальные проблемы с виртуальными машинами после апгрейда и проанализировать общую готовность инфраструктуры к обновлению. Также можно выявить возможные трудности в плане поддержки аппаратного обеспечения, что очень важно, когда у вас либо очень старое, либо очень новое оборудование.
Утилита vSAT реализована двумя компонентами:
Десктопный клиент, который связывается с сервером vCenter и организует передачу данных.
Онлайн-портал vSphere Assessment Portal, обрабатывающий ваши данный и визуализующий результаты.
Десктопный клиент поддерживает ОС Windows, OS X и Linux. В клиенте вы просто добавляете сервер vCenter, который нужно проанализировать. Для этого либо потребуется использовать административный аккаунт, либо создать пользователя с кастомной ролью с привилегиями "Host Settings".
После того, как в вашей инфраструктуре завершен сбор данных, есть 2 способа отправить их в облако:
Онлайн-отправка на vSphere Assessment portal с использованием vSAT passcode (чтобы его получить, можно использовать опцию клиента "Forgot Your vSAT passcode?").
Также Passcode можно получить из меню аккаунта на vSAT Portal:
Офлайн-отправка путем скачивания данных в файл и их последующая загрузка на портал в ручном режиме:
Результатом анализа будет дэшборд, на котором представлена сводная информация по имеющимся проблемам для выбранного пути апгрейда. В левой панели можно выбрать нужный хост ESXi (по аналогии с vSphere Client).
В представлении Summary вы найдете список всех версий vSphere, на которые вы можете выполнить миграцию, а также узнать, какие хосты ESXi рискуют оказаться в неподдерживаемой конфигурации. При клике на хост ESXi возникает панель host details, где можно увидеть текущую версию vSphere, модель сервера, сетевые адаптеры и контроллеры хранилищ. Для каждого компонента верифицируется поддержка соответствующей версией vSphere.
В общем, очень полезная штука для админа перед обновлением vSphere на новую версию. Особенно полезно будет запустить ее в большой инфраструктуре, где присутствует различное оборудование и, возможно, разные версии хостов ESXi.
Вчера мы писали о том, что в перед предстоящим VMworld 2019 компания VMware рассказала о новых возможностях решения для организации отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. Одновременно с этим была анонсирована и новая версия главной платформы виртуализации VMware vSphere 6.7 Update 3.
Напомним, что прошлая версия - vSphere 6.7 Update 2 - вышла весной этого года. Давайте посмотрим, что нового будет в vSphere 6.7 U3:
1. Поддержка нескольких vGPU (от NVIDIA) для одной виртуальной машины.
Теперь vSphere поддерживает несколько устройств NVIDIA GRID virtual GPU (vGPU), привязанных к одной виртуальной машине. Это, прежде всего, даст возможность увеличения вычислительных мощностей для тяжелых нагрузок, предъявляющих высокие требования к расчетам графического процессора (например, задачи машинного обучения).
2. Поддержка AMD EPYC Generation 2.
Новый релиз vSphere будет полностью совместим с поколением процессоров AMD EPYC. VMware и AMD работают в тесном сотрудничестве в целях поддержки самых последних нововведений в плане безопасности и производительности, заявленных в последних моделях данной линейки CPU.
3. Возможность изменить PNID для vCenter.
Идентификатор PNID (Primary Network IDentifier) сервера vCenter Server - это его сетевое имя (оно же FQDN), которое задается на этапе установки. Теперь есть возможность изменить его прямо в интерфейсе:
4. Поддержка Dynamic DNS (DDNS).
Dynamic DNS - это механизм обновления записей DNS-серверов новыми данными при изменении IP-адресов хостов. Ранее при использовании динамических IP для vCenter Server appliance (VCSA), в случае, если адрес менялся, приходилось вручную обновлять DNS-записи (собственно, поэтому никто и не использовал динамические IP). Теперь же с поддержкой DDNS этот процесс автоматизирован.
5. Улучшения поддержки драйверов.
Для сетевого драйвера VMXNET3 версии 4 были добавлены следующие возможности:
Guest encapsulation offload and UDP (расчет контрольных сумм)
Поддержка ESP RSS для стека Enhanced Networking Stack (ENS)
Также было обновлено множество драйверов, например, в драйвере ixgben появились функции queue pairing для оптимизации производительности CPU, а в драйвере bnxtnet добавилась поддержка адаптеров Broadcom 100 GbE и потоков multi-RSS.
Вот полный список обновленных драйверов:
VMware nvme
Microchip smarpqi
Marvell qlnativefc
Broadcom lpfc/brcmfcoe
Broadcom lsi_msgpt2
Broadcom lsi_msgpt35
Broadcom lsi_msgpt3
Broadcom lsi_mr3
Intel i40en
Intel ixgben
Cisco nenic
Broadcom bnxtnet
Скорее всего, новая версия VMware vSphere 6.7 Update 3 будет доступна для скачивания либо во время VMworld 2019, либо через несколько дней после его завершения. Следите за нашими обновлениями.
Вчера мы писали об очередной новинке на VMware Labs, мобильном клиенте vSphere Mobile Client для iOS и Android, а сегодня расскажем еще об одной утилите - Virtual Machine Compute Optimizer. Это средство представляет собой PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.
Для этого в отчете есть колонка VMCPUsOptimized, которая принимает значения Yes или No.
Далее также идут колонки, где показаны оптимальные количества сокетов и ядер для виртуальных машин, которые было бы неплохо сделать для текущей конфигурации (OptimalSockets и OptimalCores). Текущая конфигурация также представлена в колонках VMNumSockets и VMCoresPerSocket.
Назначения колонок представлены на картинке ниже:
Надо понимать, что VMCO анализирует вашу инфраструктуру только на базе рекомендаций для оптимальной конфигурации виртуальных машин без учета реальной нагрузки, которая исполняется внутри. Для такой задачи нужно средство для сайзинга посерьезнее - например, VMware vRealize Operations Manager.
Скрипт Virtual Machine Compute Optimizer можно запускать как минимум под аккаунтом с правами на чтение инфраструктуры vCenter. Скачать его по этой ссылке.
На днях компания VMware выпустила третий пакет обновления для предыдущего поколения своей главной платформы виртуализации - VMware vSphere 6.5 Update 3. Напомним, что Update 2 вышел в мае прошлого года, так что давно было уже пора выпускать апдейт, так как версия 6.5 по-прежнему широко используется, особенно в крупных предприятиях.
Давайте посмотрим, что нового в vSphere 6.5 U3.
Новые функции vCenter 6.5 Update 3:
События о добавлении, удалении и модификации пользовательских ролей содержат информацию о пользователе, который производит изменения.
Улучшения возможностей аудита в компоненте VMware vCenter Single Sign-On - теперь появились события для следующих операций: управление пользователями, логин, создание групп, изменение источника идентификации, управление политиками. Доступна эта фича только для виртуального модуля vCSA с интегрированным Platform Services Controller. Поддерживаемые источники идентификации: vsphere.local, Integrated Windows Authentication (IWA) и Active Directory over LDAP.
Поддержка новых внешних баз данных - добавлена поддержка Microsoft SQL Server 2014 SP3.
Драйвер ixgben добавляет функцию queue pairing для оптимизации эффективности CPU.
С помощью ESXi 6.5 Update 3 вы можете отслеживать использование лицензий и обновлять топологию коммутаторов. Также улучшения можно увидеть в Developer Center клиента vSphere Client.
Поддержка устаревших серверов AMD Zen 2.
Множество обновлений драйверов устройств: lsi-msgpt2, lsi-msgpt35, lsi-mr3, lpfc/brcmfcoe, qlnativefc, smartpqi, nvme, nenic, ixgben, i40en и bnxtnet.
Поддержка Windows Server Failover Clustering и Windows Server 2019.
Добавлено свойство com.vmware.etherswitch.ipfixbehavior в распределенные виртуальные коммутаторы, чтобы позволить пользователям выбирать способ трекинга входящего и исходящего трафика. Значение 1 включает сэмплирование для входящего и исходящего трафика, значение 0 включает его только для исходящего (значение по умолчанию).
Если вы ожидали среди возможностей чего-то действительно нового - увы, этого не бывает. VMware надо развивать ветку vSphere 6.7 и следующие версии платформы. Скачать VMware vSphere 6.5 Update 3 можно по этой ссылке.
Какие еще продукты VMware были обновлены параллельно с этим релизом:
RSS
