Новости Статьи VMware Veeam StarWind vStack Microsoft Nakivo Citrix Symantec События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Все самое нужное о виртуализации и облаках

Более 6290 заметок о VMware, AWS, Azure, Veeam, Kubernetes и других

VM Guru | Ссылка дня: Полный список лабораторных работ VMware Hands-on Labs

Использует ли гипервизор VMware ESXi 6.7 возможности процессора Intel Turbo Boost?


На Reddit коллеги заметили, что при включении технологии Turbo Boost в процессорах Intel, из виртуальной машины увеличения производительности не наблюдается. Напомним, что Turbo Boost — это технология компании Intel для автоматического увеличения тактовой частоты процессора свыше номинальной, если при этом не превышаются ограничения мощности, температуры и тока в составе расчётной мощности (TDP).

При этом емкость CPU показывается прежней, даже при создании существенной нагрузки на процессор:

В комментариях люди правильно отвечают, что поскольку Turbo Boost - это аппаратная возможность, гостевая система виртуальной машины не ловит отображение увеличения аппаратной мощности в виртуальную машину. При этом если вы посмотрите на виртуальную машину с 4 процессорами 2.4 ГГц с уровня хоста ESXi с включенным Turbo Boost до 3 ГГц, вы увидите утилизацию процессора 4*3=12 ГГц.

То есть гостевая система вполне будет использовать преимущества этой технологии, но отображать утилизацию процессора она будет в соответствии с его номинальной мощностью.

Также нужно убедиться, что ваш хост не использует политику питания High performance power management policy, которая отключает Turbo Boost. Вместо этого используйте политику Balanced, которая включена по умолчанию.


Таги: VMware, ESXi, Hardware, Performance, vSphere, VMachines, Intel

На VMware Labs обновился USB Network Native Driver for ESXi до версии 1.4


На сайте проекта VMware Labs обновился пакет USB Network Native Driver for ESXi до версии 1.4, который содержит в себе драйверы для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Давайте посмотрим, что там появилось нового:

  • Добавлена поддержка USB-устройств SuperMicro/Insyde Software Corp.
  • Исправлена проблема больших кадров 9K Jumbo frames для устройств с чипсетом RTL8153.
  • Устранена ошибка с неправильным отображением пропускной способности для некоторых устройств на дефолтной скорости.

Новые номера билдов теперь следующие:

  • ESXi670-VMKUSB-NIC-FLING-33242987-offline_bundle-15615590.zip
  • ESXi650-VMKUSB-NIC-FLING-33268102-offline_bundle-15620342.zip

Список поддерживаемых устройств на сегодняшний день выглядит так:

Скачать USB Network Native Driver for ESXi версии 1.4 можно по этой ссылке.


Таги: VMware, ESXi, Labs, Hardware, Update, Network

Интерактивная инфографика режима обслуживания VMware vSAN (Maintenance Mode)


У 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, vSAN, Diagram, Обучение, ESXi

Ошибка браузера Google Chrome 80 при подключении к ESXi через vSphere Client


Некоторые пользователи виртуальной инфраструктуры 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 по ссылке: 

https://<current-hostname>/ui/#/host/networking/netstacks/defaultTcpipStack

2. Изменяем настройки хоста.

Устанавливаем 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, vSphere, Client, Bug, Google, Chrome, ESXi

Новое на VMware Labs: решение Pallas для доступа vCenter к изолированным хостам ESXi.


На сайте проекта 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, ESXi, Labs, Security

Изменения в лицензировании VMware vSphere для процессоров с большим числом ядер


На днях компания 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, Licensing, CPU, Update, ESXi

Хост VMware ESXi в состоянии Not Responding на сервере vCenter - в чем может быть проблема?


Хотя бы раз у каждого администратора 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):

Проверить коммуникацию по порту 902 можно с помощью Telnet.

Также тут вам могут помочь следующие статьи базы знаний VMware:

Кстати, таймаут в 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, ESXi, Troubleshooting, vCenter, vSphere

Очень полезная штука на VMware Labs: vSphere Software Asset Management (vSAM)


На сайте проекта 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, Labs, Licensing, vSphere, ESXi

Сервер VMware vCenter за NAT для хостов VMware ESXi - как это сделать?


Некоторые администраторы сталкиваются с такой конфигурацией виртуальной инфраструктуры, когда управляющий сервер 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, vCenter, Networking, ESXi, Troubleshooting

Платформе VMware vSphere 6.0 настает End of Life уже 12 марта этого года.


Многие крупные организации до сих пор используют платформу 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:


Таги: VMware, vSphere, Support, ESXi, vCenter, Lifecycle

Как контейнеры в виртуальных машинах на VMware vSphere могут работать на 8% быстрее, чем на голом железе с Linux.


Для большинства ИТ-специалистов виртуализация ассоциируется с накладными расходами на ее содержание. Виртуальная машина имеет такие-то потери по 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 - ничего нового.


На днях компания 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 можно по этой ссылке.


Таги: VMware, vSphere, Update, vCenter, ESXi, CBT

Новый документ "Performance of VMware vCenter Server 6.7 in Remote Offices and Branch Offices".


На днях компания VMware выпустила документ "Performance of VMware vCenter Server 6.7 in Remote Offices and Branch Offices", в котором рассказывается о производительности сервера vCenter в инфраструктуре небольших офисов и филиалов, где развернуто всего несколько хостов VMware ESXi.

Инфраструктура remote offices and branch offices (ROBO), как правило, удалена от основного датацентра компании, что вызывает влияние на сетевые характеристики, такие как полоса пропускания, задержки в сети и ошибки в доставке пакетов. На эту тему в документе есть интересная табличка:

Авторы документа отмечают, что больше всего на производительность операций vCenter влияет не полоса пропускания, а latency между сервером vCenter (который может быть в головном офисе) и хостами ESXi (которые могут быть на удаленной площадке). В случае больших задержек для прохождения команд от vCenter, время выполнения операций с виртуальными машинами также возрастает:

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


Таги: VMware, vCenter, Performance, ESXi, Whitepaper

Как сделать инвентаризацию систем в виртуальной инфраструктуре VMware vSphere?


Многим администраторам 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, vSphere, Documentation, Reporting, VMachines, ESXi

Анонсы VMworld Europe 2019 - часть 3. Новые возможности решения VMware vRealize Network Insight 5.1.


В сентябре этого года мы рассказывали о возможностях новой версии решения для мониторинга и защиты сетевой составляющей виртуальной среды 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 обещает его публичную доступность.


Таги: VMware, vRNI, vRealize, Update, vNetwork, Networking, ESXi, vSphere

VMware Project Pacific - подход VMware к объединению миров виртуальных машин и контейнеризованных приложений.


Project Pacific был одним из главных анонсов конференции VMworld в этом году, и VMware обращала на него особенное внимание. Это неудивительно - ведь VMware делает поддержку Kubernetes не для галочки. Тут дело в том, что многие пользователи планируют развертывание инфраструктуры контейнеризованных приложений на физической инфраструктуре - в этом случае не надо нести издержки на гипервизор и лицензии, а сами приложения в контейнерах работают быстро и имеют встроенные средства обеспечения доступности.


Таги: VMware, Tanzu, Kubernetes, Pacific, Containers, Docker, ESXi, vSphere, vCenter

Новая версия Virtual Machine Compute Optimizer 2.0 доступна на VMware Labs.


На сайте проекта 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 (можно выбрать в комбобоксе при загрузке) для получения более детальной информации.


Таги: VMware, PowerCLI, CPU, ESXi, VMachines, Labs, Update

Новый параметр vmx.reboot.PowerCycle для упрощения процедуры устранения уязвимостей CPU виртуальных машин VMware vSphere и не только.


Большинство из вас, конечно же, слышало о серии уязвимостей в процессорах 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, вы можете использовать следующую команду:

New-AdvancedSetting -Entity YOUR_VM_NAME -Name vmx.reboot.PowerCycle -Value TRUE -Confirm:$false

Это же можно сделать и для групп виртуальных машин, например, находящихся в папке Test Group 1:

Get-Folder "Test Group 1" | Get-VM | New-AdvancedSetting -Name vmx.reboot.PowerCycle -Value TRUE -Confirm:$false

Эти команды можно сопроводить принудительным флагом исполнения -Force и контролировать поведение в случае ошибки с помощью -ErrorAction.

После того, как параметр PowerCycle будет выставлен, VMware Tools (вы же помните, что они должны быть установлены) смогут совершить цикл сброса питания для виртуальной машины, а затем сам параметр будет удален из VMX-файла. Также он будет удален автоматически, если вы вручную завершите и снова запустите виртуальную машину.

Для контроля того, что параметр установлен, вы можете посмотреть в vSphere Client, в разделе Configuration Parameters (в самом низу):

 

Также использование данного параметра может вам помочь в случае кластеров Enhanced vMotion Compatibility (EVC). Такие кластеры требуют от виртуальных машин поддержки единого базового уровня инструкций CPU для обеспечения vMotion между хостами с разным аппаратным обеспечением.

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


Таги: VMware, vSphere, Hardware, CPU, VMachines, Blogs, Security, ESXi

Траблшутинг операций VMware vMotion - как искать проблемы в логах при миграциях виртуальных машин.


Часто при миграциях 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. Делается это следующей командой:

grep jzlgfw8g-11824-auto-94h-h5:70003561-20 /var/log/hostd.log | grep -i migrate

Исходный хост ESXi

2019-09-24T15:38:47.070Z info hostd[2100388] [Originator@6876 sub=Vcsvc.VMotionSrc.3117907752192811422 opID=jzlgfw8g-11824-auto-94h-h5:70003561-20-01-10-e036 user=vpxuser:VSPHERE.LOCAL\Administrator] VMotionEntry: migrateType = 1 2019-09-24T15:38:47.072Z info hostd[2100388] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/b86202d8-fb958817-0000-000000000000/NH-DC-02/NH-DC-02.vmx opID=jzlgfw8g-11824-auto-94h-h5:70003561-20-01-10-e036 user=vpxuser:VSPHERE.LOCAL\Administrator] VigorMigrateNotifyCb:: hostlog state changed from success to none

Целевой хост ESXi

2019-09-24T15:38:47.136Z info hostd[2099828] [Originator@6876 sub=Vcsvc.VMotionDst.3117907752192811422 opID=jzlgfw8g-11824-auto-94h-h5:70003561-20-01-2c-3c35 user=vpxuser:VSPHERE.LOCAL\Administrator] VMotionEntry: migrateType = 1

На стороне VMkernel вы можете найти информацию о неудачной миграции следующей командой:

grep VMotion /var/log/vmkernel*

Исходный хост ESXi:

019-09-24T15:38:47.402Z cpu13:46101760)VMotionUtil: 5199: 3117907752192811422 S: Stream connection 1 added.
2019-09-24T15:38:47.445Z cpu8:46092538)XVMotion: 2062: Allocating pool 0.
2019-09-24T15:38:47.445Z cpu8:46092538)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.
2019-09-24T15:38:47.445Z cpu8:46092538)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.
2019-09-24T15:38:47.445Z cpu8:46092538)VMotion: 8134: 3117907752192811422 S: Requiring explicit resume handshake.
2019-09-24T15:38:47.445Z cpu13:46101760)XVMotion: 3384: 3117907752192811422 S: Starting XVMotion stream.
2019-09-24T15:39:34.622Z cpu14:46101762)VMotion: 5426: 3117907752192811422 S: Disk copy complete, no bandwidth estimate.
2019-09-24T15:39:34.905Z cpu24:46092539)VMotion: 5281: 3117907752192811422 S: Stopping pre-copy: only 37 pages left to send, which can be sent within the switchover time goal of 0.500 seconds (network bandwidth ~185.134 MB/s, 1536000% t2d)
2019-09-24T15:39:34.965Z cpu13:46101760)VMotionSend: 5095: 3117907752192811422 S: Sent all modified pages to destination (network bandwidth ~281.100 MB/s)
2019-09-24T15:39:35.140Z cpu15:46101757)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.
2019-09-24T15:39:35.140Z cpu15:46101757)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.

Целевой хост ESXi:

2019-09-24T15:38:47.397Z cpu15:2099283)VMotionUtil: 5199: 3117907752192811422 D: Stream connection 1 added.
2019-09-24T15:38:47.440Z cpu3:3543984)XVMotion: 2062: Allocating pool 0.
2019-09-24T15:38:47.440Z cpu3:3543984)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.
2019-09-24T15:38:47.440Z cpu3:3543984)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.
2019-09-24T15:38:47.440Z cpu3:3543984)VMotion: 8134: 3117907752192811422 D: Requiring explicit resume handshake.
2019-09-24T15:39:34.907Z cpu3:3543984)VMotionRecv: 761: 3117907752192811422 D: Estimated network bandwidth 205.138 MB/s during pre-copy
2019-09-24T15:39:34.960Z cpu3:3543984)VMotionRecv: 2961: 3117907752192811422 D: DONE paging in
2019-09-24T15:39:34.960Z cpu3:3543984)VMotionRecv: 2969: 3117907752192811422 D: Estimated network bandwidth 200.096 MB/s during page-in
2019-09-24T15:39:35.059Z cpu6:3543972)VMotion: 6675: 3117907752192811422 D: Received all changed pages.
2019-09-24T15:39:35.067Z cpu1:3543972)VMotion: 6454: 3117907752192811422 D: Resume handshake successful
2019-09-24T15:39:35.082Z cpu6:3543980)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.
2019-09-24T15:39:35.082Z cpu6:3543980)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.

В выводе вы можете увидеть такие интересные вещи, как, например, средняя скорость (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, vMotion, Troubleshooting, ESXi, vCenter

Новые расширенные настройки (Advanced Options) кластера VMware vSAN 6.7 Update 3.


Некоторое время назад мы писали о новых возможностях решения для создания отказоустойчивых хранилищ на базе хост-серверов 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, vSAN, Blogs, Storage, ESXi

Производительность устройств для кэширования в кластерах VMware vSAN и рекомендации по использованию.


На блогах 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, vSAN, Performance, Storage, ESXi, VMachines, SSD

Новая версия USB Network Native Driver 1.2 для серверов ESXi доступна на VMware Labs.


На сайте проекта 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 можно по этой ссылке.


Таги: VMware, USB, Driver, Labs, Update, ESXi, Hardware

Анонсы VMworld 2019 - часть 7. Утилита VMware vSphere Assessment Tool для подготовки апгрейда виртуальной инфраструктуры.


В рамках серии анонсов, представленных на прошедшей конференции VMworld 2019, компания VMware представила интересное средство, которое может оказаться полезным администраторам виртуальной инфраструктуры - vSphere Assessment Tool (vSAT).

Главное назначение этой утилиты - помочь ИТ-специалистам перед миграцией инфраструктуры VMware vSphere на новую версию: заранее понять потенциальные проблемы с виртуальными машинами после апгрейда и проанализировать общую готовность инфраструктуры к обновлению. Также можно выявить возможные трудности в плане поддержки аппаратного обеспечения, что очень важно, когда у вас либо очень старое, либо очень новое оборудование.

Утилита vSAT реализована двумя компонентами:

  • Десктопный клиент, который связывается с сервером vCenter и организует передачу данных.
  • Онлайн-портал vSphere Assessment Portal, обрабатывающий ваши данный и визуализующий результаты.

Для начала работы просто нажимаете Get Started на первой странице портала:

Десктопный клиент поддерживает ОС 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.

Пользуйтесь!


Таги: VMware, vSphere, Upgrade, Assessment, Tool, ESXi

Анонсирована новая версия платформы виртуализации VMware vSphere 6.7 Update 3.


Вчера мы писали о том, что в перед предстоящим 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, vSphere, Update, vCenter, ESXi

Еще одна новая штука на VMware Labs - Virtual Machine Compute Optimizer.


Вчера мы писали об очередной новинке на 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, Labs, Compute, vSphere, ESXi, PowerCLI, PowerShell

Вышел VMware vSphere 6.5 Update 3 и обновления других продуктов.


На днях компания 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.
  • Обновления ОС Photon для vCSA.

Release Notes для vCenter 6.5 U3 находятся здесь.

Новые функции ESXi 6.5 Update 3:

  • Драйвер 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 включает его только для исходящего (значение по умолчанию).

Release Notes для ESXi 6.5 U3 находятся здесь.

Если вы ожидали среди возможностей чего-то действительно нового - увы, этого не бывает. VMware надо развивать ветку vSphere 6.7 и следующие версии платформы. Скачать VMware vSphere 6.5 Update 3 можно по этой ссылке.

Какие еще продукты VMware были обновлены параллельно с этим релизом:

  • vSphere Replication 6.5.1.4 - просто обновление с исправлением ошибок.
  • App Volumes 2.17 - поддержка Windows 10 1903, коммуникация с SQL Server по протоколу TLS 1.2. Остальное - здесь.
  • User Environment Manager 9.8.0 - это большое обновление, подробнее о нем вот тут.

Таги: VMware, vSphere, Update, ESXi, vCenter, vCSA, AppVolumes, Replication, UEM

Ошибка "Unable to login" в интерфейсе VAMI виртуального модуля VMware vCenter Server Appliance (vCSA) и неработающий Syslog.


Некоторые пользователи, особенно после апгрейда сервера VMware vCenter Server Appliance 6.5 на версию 6.7, получают вот такое сообщение при попытке входа через интерфейс VAMI (Virtual Appliance Management Infrastructure):

Напомним, что интерфейс VAMI для управления виртуальным модулем vCSA доступен по ссылке:

https://<vCenter_FQDN>:5480

Причин проблемы может быть 2:

1. Пароль пользователя root устарел (кстати, помните, что в пароле нельзя использовать двоеточие). Для этого надо зайти в консоль vCSA и проверить это командой:

chage -l root

2. Не поднялась служба VMware Appliance Management Service.

Эта служба также кратко называется "applmgmt". Чтобы запустить ее через vSphere Client, зайдите в administrator@vsphere.local > Administration > Deployment > System Configuration > Services, выделите Appliance Management Service и нажмите Start.

Также можно сделать это из командной строки шелла vCSA:

service-control --start applmgmt

Далее нужно проверить, что служба действительно запустилась:

service-control --Status

Можно также поднять все сервисы vCSA одной командой:

service-control --start --all

Кстати, иногда после апгрейда хостов ESXi 6.5 на версию 6.7 внешний сервер Syslog может перестать принимать логи от vCSA из-за того, что правило фаервола ESXi для Syslog почему-то перестает быть активным. Можно снова включить это правило через интерфейс vSphere Client, либо вот такой командой PowerCLI:

Get-VMHost | Get-VMHostFirewallException | where {$_.Name.StartsWith(‘syslog’)} | Set-VMHostFirewallException -Enabled $true


Таги: VMware, vCSA, Bug, Bugs, vCenter, ESXi, Troubleshooting, VAMI, Virtual Appliance

10 полезных вещей, которые надо знать об SSL-сертификатах VMware vSphere.


Многие администраторы платформы VMware vSphere очень часто интересуются вопросом замены сертификатов для серверов ESXi в целях обеспечения безопасности. Как правило, это просто инструкции, которые не дают понимания - а зачем именно нужно менять эти сертификаты.

Недавно VMware выпустила интересную статью на тему сертификатов в vSphere и других продуктах, приведем ниже основные выдержки из нее.

1. Сертификаты - это вопрос доверия и шифрования.

При соединении с различными веб-консолями компонентов инфраструктуры VMware vSphere используется протокол HTTPS, где S означает "Secure". Инфраструктура SSL, а точнее ее последователь Transport Layer Security (TLS), использует известный в криптографии принцип открытого и закрытого ключей, который позволяет узлам, доверяющим друг другу безопасно обмениться информацией по шифрованному каналу.

TLS развивается по следующему пути:

  • Версия 1.0 имеет уязвимости, он небезопасен и больше не должен использоваться.
  • Версия 1.1 не имеет таких уязвимостей, как 1.0, но использует такие алгоритмы шифрования, как MD5 и SHA-1, которые больше не считаются безопасными.
  • Версия 1.2 добавляет шифрование AES, которое работает быстро и не использует небезопасные методы, сам же алгоритм использует SHA-256. На текущий момент это стандарт TLS.
  • Версия 1.3 не содержит слабых точек и добавляет возможности увеличения скорости соединения, этот стандарт скоро будет использоваться.

Если вы используете сертификаты vSphere, то независимо от того, какие они (самоподписанные или выданные центром сертификации) - общение между компонентами виртуальной инфраструктуры будет вестись посредством TLS с надежным шифрованием. Вопрос сертификатов тут - это всего лишь вопрос доверия: какому объекту, выпустившему сертификат, вы доверяете - это и есть Центр сертификации (он же Certificate Authority, CA).

Многие крупные компании, имеющие определенный вес (например, Microsoft) сами являются Центрами сертификации, а некоторые компании используют службы Microsoft Active Directory Certificate Services, чтобы встроить собственные CA в операционную систему и браузеры (импортируют корневые сертификаты), чтобы "научить" их доверять этим CA.

2. В VMware vSphere сертификаты используются повсеместно.

Как правило, они используются для трех целей:

  • Сертификаты серверов ESXi, которые выпускаются для управляющих интерфейсов на всех хост-серверах.
  • "Машинные" сертификаты SSL для защиты консолей, с которыми работает человек - веб-консоль vSphere Client, страница логина SSO или Platform Service Controllers (PSCs).
  • "Solution"-сертификаты, используемые для защиты коммуникаций со сторонними к платформе vSphere продуктам, таким как vRealize Operations Manager, vSphere Replication и другим.

Полный список компонентов, где vSphere использует сертификаты, приведен вот тут.

3. vSphere имеет собственный Центр сертификации.

Платформа vSphere из коробки поставляется с собственным CA, который используется для коммуникации между компонентами. Называется он VMware Certificate Authority (VMCA) и полностью поддерживается для vSphere как с внешним PSC, так и для vCenter Server Appliance (vCSA) со встроенным PSC.

Как только вы добавляете хост ESXi в окружение vCenter, то VMCA, работающий на уровне vCenter, выпускает новый сертификат на этот ESXi и добавляет его в хранилище сертификатов. Такая же штука происходит, когда вы настраиваете интеграцию, например, с решениями vRealize Operations Manager или VMware AppDefense.

Надо понимать, что CA от VMware - это всего лишь решение для защищенной коммуникации между серверами, которое поставляется из коробки. Ваше право - доверять этой модели или нет.

4. Есть 4 способа внедрить инфраструктуру сертификатов на платформе vSphere.

Вот они:

  • Использовать самоподписанные сертификаты VMCA. Вы можете просто скачать корневые сертификаты с веб-консоли vCenter, импортировать их в операционную систему клиентских машин. В этом случае при доступе к веб-консоли, например, vSphere Client у вас будет отображаться зеленый замочек.
  • VMCA можно сделать подчиненным или промежуточным (subordinate/ intermediate) центром сертификации, поставив его посередине между CA и конечными хостами, что даст дополнительный уровень сложности и повысит вероятность ошибки в настройке. VMware не рекомендует так делать.
  • Отключить VMCA и использовать собственные сертификаты для любых коммуникаций. Ваш ответственный за сертификаты должен нагенерировать запросы Certificate Signing Requests (CSR) для всех компонентов. Эти CSR-запросы вы отсылаете с CA, которому вы доверяете, получаете их подписанными, после чего устанавливаете их в ручном режиме. Это отнимает время и чревато ошибками. 
  • Использовать гибридный подход - для хостов ESXi в их коммуникации с vCenter использовать самоподписанные VMCA сертификаты, а для веб-консолей vSphere Client и прочих использовать перевыпущенные сертификаты, которые надо установить на сервере vCenter и хостах, с которых будет управляться инфраструктура через браузер (тогда в нем появится зеленый замочек). Это самый рекомендуемый VMware вариант использования сертификатов.

5. Enterprise-сертификаты - тоже самоподписанные.

Подумайте - самоподписанными являются не только сертификаты VMCA, но и ваши корпоративные сертификаты. Если вы выпускаете эти сертификаты только на уровне своей компании, то у вас 2 точки потенциального недоверия - сторона, выпустившая сертификаты у вас в компании, а также, собственно, сам VMCA. Такая схема создает дополнительный уровень сложности администрирования, а также нарушения безопасности.

6. Не создавайте промежуточный Центр сертификации.

Если вы создаете intermediate CA (он же subordinate CA) для VMCA, превращая его в посредника, вы создаете потенциальную опасность для виртуальной инфраструктуры - если кто-то получает доступ к корпоративному центру сертификации и его парам ключей, то он может навыпускать любых сертификатов от имени VMCA и перехватывать потом любые коммуникации.

7. Можно изменять информацию для самоподписанных сертификатов CA.

С помощью утилиты  Certificate Manager utility вы можете сгенерировать новый VMCA с необходимой информацией о вашей организации внутри него. Эта утилита перевыпустит все сертификаты и заменит их на всех хостах виртуальной инфраструктуры. Это хорошая опция для гибридной модели. Кстати, вы можете менять даты устаревания сертификатов, если дефолтные вас не устраивают.

8. Тестируйте инфраструктуру сертификатов перед внедрением.

Вы можете развернуть виртуальную инфраструктуру и провести все эксперименты с сертификатами в виртуальной среде, где вы можете использовать виртуальные (nested) серверы ESXi. Приятная штука в том, что вы можете создавать снапшоты виртуальных машин, а значит в случае чего - быстро откатитесь на рабочий вариант. Еще одна среда для экспериментов - это облачная инфраструктура VMware Hands-on Labs, где можно безопасно ставить любые эксперименты.

Попробуйте также новую vSphere 6.7 Lightning Lab.

9. Делайте бэкапы своей инфраструктуры.

Делайте резервную копию вашего vCenter и PSC на уровне файлов через веб-консоль VAMI. Также утилитой Certificate Manager можно скопировать старый набор сертификатов перед развертыванием новых (но только один набор сертификатов, учитывайте это). Также эта процедура полностью поддерживается со стороны VMware Global Support Services.

10. Понимайте, зачем вы заморачиваетесь с заменой сертификатов.

Ответьте для себя на несколько вопросов:

  • Стоит ли иконка зеленого замочка в браузере всех этих заморочек?
  • Нужно ли всем видеть этот замочек или только команде администрирования vSphere?
  • Почему вы доверяете vCenter для управления всем в виртуальной инфраструктуре, но не доверяете VMCA?
  • В чем отличие самоподисанного сертификата вашего предприятия от самоподписанного сертификата VMCA?
  • Действительно ли комплаенс требует от вас кастомных CA-сертификатов?
  • Какова будет цена процедур по замене сертификатов в инфраструктуре vSphere во времени и деньгах?
  • Увеличивает или уменьшает риск итоговое решение и почему конкретно?

Дополнительные ресурсы


Таги: VMware, vSphere, Security, Certificates, SSL, ESXi

На сайте VMware Labs обновилась утилита HCIBench до версии 2.1.


На сайте VMware Labs обновилась утилита HCIBench до версии 2.1.

Напомним, что о версии HCIBench 2.0 мы писали вот тут, а здесь мы рассматривали использование этой утилиты для замеров производительности кластеров VMware vSAN. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.

Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

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

Что нового появилось в HCIBench 2.1:

  • Интерфейс переключили на темную тему.
  • Переработанная технология подготовки VMDK, которая теперь работает гораздо быстрее за счет использования рандомизации на дедуплицированных хранилищах.
  • Добавлена возможность обновления процесса подготовки VMDK.
  • Добавлена проверка портов базы данных Graphite в процесс превалидации.
  • Пароли vCenter и хостов ESXi затемняются при сохранении
  • Добавлена кнопка удаления гостевой ВМ ("Delete Guest VM").
  • Пофикшены проблемы с дисплеями для Grafana.
  • Пофикшена проблема с пустыми результатами при отработки модели нагрузки FIO (Flexible I/O).
  • Множество мелких исправлений ошибок.

Скачать HCIBench 2.1 можно по этой ссылке. Документация пока доступна только для версии 2.0.


Таги: VMware, HCIBench, Update, Performance, ESXi, vSphere, vSAN, VMDK, Storage

На VMware Labs обновился USB Network Native Driver for ESXi до версии 1.1.


На сайте проекта VMware Labs появилось очередное обновление - стала доступна новая версия средства USB Network Native Driver for ESXi до версии 1.1. Напомним, что ранее мы писали о нем вот тут. Это нативный драйвер для сетевых адаптеров серверов, которые подключаются через USB-порт.

Такой адаптер можно использовать, когда вам необходимо, например, подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. В каких-то еще случаях подключение такого адаптера может помочь, чтобы получить еще одно сетевое соединение без необходимости перезагружать сервер (и так же просто отключить его).

Новая версия драйвера содержит поддержку девяти новых устройств USB NIC, включая девайсы USB 2.0 RTL8152 & TPLINK. Полный список поддерживаемых устройств теперь таков:

VendorChipsetVendorIDProductID
ASIXAX881790x0b950x1790
ASIXAX88178a0x0b950x178a
CISCO LINKSYSRTL81530x13b10x0041
DLINKAX881790x20010x4a00
LENOVOAX881790x17ef0x304b
LENOVORTL81530x17ef0x7205
LENOVORTL81530x17ef0x3069
LENOVORTL81530x17ef0x720a
LENOVORTL81530x17ef0x3062
NVIDIARTL81530x09550x09ff
REALTEKRTL81530x0bda0x8153
REALTEKRTL81520x0bda0x8152
SITECOMEUAX881790x0df60x0072
TP-LINKRTL81530x23570x0601

Помимо этого, в драйвер также была добавлена поддержка Jumbo Frames (размером до 4K) для устройств RTL8153 и AX88179.

Для установки драйвера нужно развернуть на ESXi 6.5 или 6.7 один из двух VIB-пакетов для соответствующей версии:

  • ESXi670-VMKUSB-NIC-FLING-20124247-offline_bundle-11613968
  • ESXi650-VMKUSB-NIC-FLING-20123976-offline_bundle-11613344

Делается это следующей командой:

esxcli software vib install -d /path/to/the/offline/bundle

После установки нужно перезагрузить хост VMware ESXi, после чего устройство USB NIC будет автоматически смонтировано как, например, vusb0.

Скачать USB Network Native Driver for ESXi можно по этой ссылке.


Таги: VMware, ESXi, USB, Driver, Labs, Hardware, Network

<<   <    1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30    >   >>
Интересное:





Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

Быстрый переход:
VMware Broadcom Offtopic Microsoft Veeam Cloud StarWind VMachines NAKIVO vStack Gartner Vinchin Nakivo IT-Grad Teradici VeeamON VMworld PowerCLI Citrix VSAN GDPR 5nine Hardware Nutanix vSphere RVTools Enterprise Security Code Cisco vGate SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud DevOps Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs IDC Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V vSAN Private AI VCPP VCF Workstation Labs Backup Explore vDefend Data Protection ONE Tanzu AI Intel Live Recovery VCP V2V HCX Aria NSX DPU Update EUC Avi Community Skyline Host Client Chargeback Horizon SASE Workspace ONE Networking Ransomware Tools Performance Lifecycle Network AWS API USB SDDC Fusion Whitepaper SD-WAN Mobile VMUG SRM ARM HCI Converter Photon OS Operations VEBA App Volumes Certification VMConAWS Workspace Imager SplinterDB DRS SAN vMotion Open Source iSCSI Partners HA Monterey Kubernetes vForum Learning vRNI UAG Support Log Insight AMD vCSA NSX-T Graphics NVMe HCIBench SureBackup Carbon Black vCloud Обучение Web Client vExpert OpenStack UEM CPU PKS vROPs Stencils Bug VTL Forum Video Update Manager VVols DR Cache Storage DRS Visio Manager Virtual Appliance PowerShell LSFS Client Datacenter Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Encryption Nested XenDesktop VSA vNetwork SSO VMDK Appliance VUM HoL Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP iOS SC VMM VDP PCoIP RHEV vMA Award Licensing Logs Server Demo vCHS Calculator Бесплатно Beta Exchange MAP DaaS Hybrid Monitoring VPLEX UCS GPU SDK Poster VSPP Receiver VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V KB VirtualCenter NFS ThinPrint Memory SIOC Troubleshooting Stretched Bugs Director ESA Android Python Upgrade ML Hub Guardrails CLI Driver Foundation HPC Orchestrator Optimization SVMotion Diagram Ports Plugin Helpdesk VIC VDS Migration Air DPM Flex Mac SSH VAAI Heartbeat MSCS Composer
Полезные постеры:

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Сравнение Oracle VirtualBox и VMware Workstation.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Диски RDM (Raw Device Mapping) для виртуальных машин VMware vSphere и серверов ESX.

Работа с дисками виртуальных машин VMware.

Где скачать последнюю версию VMware Tools для виртуальных машин на VMware ESXi.

Подключение локальных SATA-дисков сервера VMware ESXi в качестве хранилищ RDM для виртуальных машин.

Как перенести виртуальную машину VirtualBox в VMware Workstation и обратно

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Как использовать возможности VMware vSphere Management Assistant (vMA).

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Полезные ресурсы:

Последние 100 утилит VMware Labs

Новые возможности VMware vSphere 8.0 Update 1

Новые возможности VMware vSAN 8.0 Update 1

Новые документы от VMware

Новые технологии и продукты на VMware Explore 2022

Анонсы VMware весной 2021 года

Новые технологии и продукты на VMware VMworld 2021

Новые технологии и продукты на VMware VMworld 2020

Новые технологии и продукты на VMware VMworld Europe 2019

Новые технологии и продукты на VMware VMworld US 2019

Новые технологии и продукты на VMware VMworld 2019

Новые технологии и продукты на VMware VMworld 2018

Новые технологии и продукты на VMware VMworld 2017



Copyright VM Guru 2006 - 2025, Александр Самойленко. Правила перепечатки материалов.
vExpert Badge