Category: 6.7

VMware PSC replication

Компонент Single Sign On, выполняющий проверку подлинности, появился в VMware vSphere 5.1. К vSphere 5.5 он стал “адекватнее” и стабильнее.

Его можно было поставить как на отдельный сервер, так и совместить вместе с vCenter Server.

В vSphere 6 этот компонент был объединен с другими сервисами в роли Platform Service Controller.

С тех пор и до vSphere 6.7 (или 6.7 Update 1) рекомендуемой схемой высокодоступного размещения PSC была следующая:

  1. Несколько внешних/отдельных PSC-серверов. Размещать PSC совместно с vCenter и реплицировать данные не некомендовалось.
  2. Требовался балансировщик между PSC и vCenter-серверами (хотя я видел скрипты, переключающие vCenter на резервный psc при недоступности основного).

Наверное, особенно круто было заниматься обновлением этого зоопарка из 4+ систем.

Особенно я прослезился со следующего KB – правила репликации PSC, рассказавшего о том, что репликация происходит в том порядке, в каком ранее добавлялись PSC (если развернули первый, на него нацелили второй, на второй – третий, то и репликация пойдет по такой схеме). Все связи между SSO-службами добавляются и удаляются только вручную.

Попутно узнал, что рекомендуемая топология – c центральным PSC.

Еще несколько KB:

А теперь к хорошим новостям: забудьте все, что только что прочитали 🙂

Начиная с vCenter 6.7 рекомендуемой топологией является встроенный PSC для любой топологии. Вы даже можете сделать vCenter HA (vCenter High Availability) для встроенного PSC, если хотите его защитить.

Ну и к вопросу резервной копии – в v6.7 появился ручной File-Based Backup, позволяющий сделать бэкап системы vCenter+PSC, восстанавливаемой с нуля с помощью этих файлов.

А в v6.7 Update 1 – возможность запуска бэкапа по расписанию.

В общем, администрирование нескольких vCenter-серверов в v6.7 стало значительно легче.

Анонс VMware vSphere 6.7 update 2

На днях анонсирована новая версия VMware vSphere 6.7 update 2, которая будет доступен в ближайшее время. Подборка статей с описанием различного функционала:

Также анонсирована новая версия Operations Managere 7.5:

VMFS vs NFS in vSphere

Как-то Diz задал вопрос: “правда ли, что NFS гораздо лучше, чем SCSI для хранилищ в случае одного большого хранилища? Как ситуация изменилась в 6.x?”

Наше путешествие будет включать в себя следующие пункты:

  • SCSI-очереди.
  • А что там с NFS?
  • Решает ли скорость протокола?
  • vSphere 6.x?
  • Рекомендации.

SCSI-очереди

Отлично тема очередей раскрыта тут. Continue reading “VMFS vs NFS in vSphere”

Изменение имени хоста VMware ESXi

Иногда возникают простые задачи, при решении которых возникают странные эффекты.

В нашей организации есть требование именовать все серверы по FQDN имени с указанием суффикса домена.

Но, как обычно, часть работничков на это дело забивает.

При инвентаризации хостов ESXi несколько таких замечаний было обнаружено. Для переименования воспользовались заметкой Changing the name of an ESX or ESXi host (1010821) и подали команды в SSH:

В результате получили esxi-01.domain.local.domain.local ;). Ошибка была простая – указали параметру host имя с суффиксом домена.

Проверить каждый параметр можно одной командой:

Исправить ошибку можно двумя способами – задать fqdn или домен:

Не работает мониторинг в vCenter Server Appliance

Встретилась проблема – раздел Monitor в VCSA не показывает новых данных. При этом в разделе Services служба VMware Appliance Monitoring Service находится в состоянии Stopped либо в консоли проверить статус службы vmware-statsmonitor:

Гугление подсказало решение – выставить время ожидания старта службы в 10 минут (предварительно сделать снимок VCSA – после проверки удалить):

  1. Подключиться по  SSH к VCSA, используя root.
  2. Изменить время ожидания:
  3. Убить процесс
  4. Принудительно выполнить перезапуск сервиса
  5. Перезапустить VCSA и проверить через 15 минут, что VMware Appliance Monitoring Service запущен.

PowerCLI – CloneVM

Понадобилось наполнить объект vAPP однотипными клонами одной и той же ВМ.

Клонировать ее вручную показалось трудоемко – изучил возможности PowerCLI и написал себе шпаргалку:

После подключения к vCenter запускаем подобный скрипт:

После запуска данного скрипта у вас появится 67 однотипных клонов виртуальной машины vm01_bi.

Вместо параметра VApp рекомендуется использовать параметр “ResourcePool”

Минимальная рекомендуемая версия vHW

На днях озадачился проблемой с минимальной версией vHW в ESXi.

Текущая ситуация с ESXi такова:

  1. ESXi 6.7 поддерживает vHW версий с 4 по 14 – Virtual machine hardware versions.
  2. vSphere 5.5 сошла с дистанции.
  3. В связи с Чипокалипсом минимальная рекомендуемая версия – 9, сильно рекомендуемая – 11: Hypervisor-Assisted Guest Mitigation for Branch Target injection, Performance impact on VMware appliances after patching for Spectre/Meltdown.
  4. VCSA 6.7u1 использует Photon OS 1.0, который у нас не работает, если поднять версию старше 11.
  5. Есть непонятки с EVC Mode и vHW.
  6. UNMAP в тонких дисках поддерживается с версии vHW 11, для Linux с версии vHW 13.
  7. Поддержка Per-VM EVC требует vHW версии 14.
  8. Поддержка Secure Boot требует vHW версии 13.
  9. Поддержка Dynamic DirectPath требует vHW версии 17.
  10. Поддержка Virtual NUMA Topology и Virtual HT требует vHW версии 20.

В итоге мы ориентируемся на следующие версии (предварительно делается копия *.vmx либо бэкап ВМ, после повышения проверка, Upgrading a virtual machine to the latest hardware version (multiple versions)):

  1. Готовые Virtual Appliances и шаблоны виртуальных машин повышаются до версии 11 либо 14.
  2. Целевая версия для Linux с тонкими дисками – 14 либо 17.
  3. Целевая версия для ПО, требующего новых инструкций CPU – 14 либо 17.
  4. В частных случаях смотрим на фунционал Hardware Features Available with Virtual Machine Compatibility Settings и  Hardware Features Available with Virtual Machine Compatibility Settings.

Обновление версии VCSA с 6.7 до 6.7 update 1

Ранее в бложике были описаны два сценария установки обновлений на VCSA 6.7:

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

Для обновления VCSA 6.7  в режиме HA до версии 6.7 update 1 опубликована отдельная статья в БЗ VMware Changes in patching VCHA enabled vSphere 6.7 systems to any 6.7 update/patch release:

  1. Зайдите vSphere Client.
  2. Перейдите в Configure > vCHA.
  3. Нажмите Edit.
  4. Выберите “Remove vCenter HA”.
  5. Обновите vCenter Server.
  6. Заново создайте vCHA.

После пары матюков в адрес разработчиков были выполнены данные рекомендации и осуществлена попытка обновить vCenter через VAMI (по инструкции для одиночного сервера), но установщик вставал на 73% и заваливал vCenter. После этого запущено обновление через CLI (один цикл из инструкции по обновление в конфигурации HA), которое прошло без сбоев.

EVC Mode и vHW

Заметил странный факт, что на процессорах Skylake и гипервизоре ESXi 6.7u1 “не отрабатывает” EVC Mode, выставленный в  Skylake – все машины стоят в режиме Broadwell.

Обратил внимание, что у нас 80% виртуальных машин работают на virtual hardware(vHW)  версии 11, он же Compatibility: ESXi 6.0 and later (VM version 11).

Предположил, что данный уровень дополнительно ограничивает уровень ЦПУ, хотя в EVC and CPU Compatibility FAQ и Enhanced vMotion Compatibility (EVC) processor support ничего про такое поведение не заметил.

Решил пойти опытным путём – создал ВМ и прогнал все версии vHW c 4 до 14. В результате выявилось, что ВМ с vHW от 4 до 12 имеют максимальный EVC Mode -Broadwell, а ВМ с vHW равным 13 или 14 могут быть в режиме Skylake.