Записки о виртуализации и о жизни
Как-то потребовалось мне решить задачу “сосуществования” в рамках vCenter нескольких команд администраторов, обслуживающих свои кластера vSphere.
В vSphere есть достаточно гибкий механизм предоставления полномочий вплоть до отдельной виртуальной машины, однако выяснилось, что есть ряд полномочий, задающихся не на уровне кластера хостов или папки виртуальных машин.
Компонент 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 была следующая:
Наверное, особенно круто было заниматься обновлением этого зоопарка из 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 стало значительно легче.
Как-то Diz задал вопрос: “правда ли, что NFS гораздо лучше, чем SCSI для хранилищ в случае одного большого хранилища? Как ситуация изменилась в 6.x?”
Наше путешествие будет включать в себя следующие пункты:
Отлично тема очередей раскрыта тут. Continue reading “VMFS vs NFS in vSphere”
Иногда возникают простые задачи, при решении которых возникают странные эффекты.
В нашей организации есть требование именовать все серверы по FQDN имени с указанием суффикса домена.
Но, как обычно, часть работничков на это дело забивает.
При инвентаризации хостов ESXi несколько таких замечаний было обнаружено. Для переименования воспользовались заметкой Changing the name of an ESX or ESXi host (1010821) и подали команды в SSH:
|
1 |
esxcli system hostname set --host=esxi-01.domain.local |
В результате получили esxi-01.domain.local.domain.local ;). Ошибка была простая – указали параметру host имя с суффиксом домена.
Проверить каждый параметр можно одной командой:
|
1 |
esxcli system hostname get |
Исправить ошибку можно двумя способами – задать fqdn или домен:
|
1 2 3 |
esxcli system hostname set --fqdn=fqdn esxcli system hostname set --domain=domain |
Понадобилось наполнить объект vAPP однотипными клонами одной и той же ВМ.
Клонировать ее вручную показалось трудоемко – изучил возможности PowerCLI и написал себе шпаргалку:
После подключения к vCenter запускаем подобный скрипт:
|
1 |
for($i=2;$i -lt 69;$i++){new-vm -Name ("vm0"+$i+"_bi") -VM vm01_bi -Datastore "VMFS01" -VMHost "esxi" -DiskStorageFormat thin -VApp Big} |
После запуска данного скрипта у вас появится 67 однотипных клонов виртуальной машины vm01_bi.
Вместо параметра VApp рекомендуется использовать параметр “ResourcePool”
После обновления Windows vCenter до версии 6.0 Update 3h (с 3d или 3e), на ряде кластеров стала наблюдаться замечательная картина – агенты на хостах vSphere 6.0U3 в разных кластерах стали выдавать ошибку:
|
1 |
vSphere HA agent for this host has an error: vSphere HA agent cannot be installed or configured. |
Перенастройка HA (Reconfigure for vSphere HA) завершалась таймаутом.
Чтение журнала fdm.log показало, что в момент начала переконфигурирования агента выдается следующее сообщение:
|
1 |
Cluster config fault domain id (version 267) != host list fault domain id - replacing with empty cluster config |
Смутно похожая статья из KB рекомендовала “просто выключить и включить HA”.
Удостоверившись, что настройки кластера стандартные, я выключил HA, подождал несколько минут, проверил статус служб “vSphere High Availability Agent” и заново включил HA.
Помогло.
На днях озадачился проблемой с минимальной версией vHW в ESXi.
Текущая ситуация с ESXi такова:
В итоге мы ориентируемся на следующие версии (предварительно делается копия *.vmx либо бэкап ВМ, после повышения проверка, Upgrading a virtual machine to the latest hardware version (multiple versions)):
Благодаря подписке на рассылку от Veeam Community Forums, углядел наличие одной прелестной проблемы с vSphere.
При использовании SEsparse-снапшотов могут наблюдаться следующие симптомы:
Continue reading “VMware – возможна потеря данных в SEsparse”
Для большей совместимости со своим оборудованием производители серверов выпускают преднастроенные образы ESXi.
Проблемы возникают при попытке перейти с версии на версию ESXi с помощью Update Manager – вылазят ошибки с таким текстом:
|
1 2 3 |
The upgrade has VIBs that are missing dependencies: .. Remove the VIBs or use Image Builder to create a custom upgrade ISO image that contains the missing dependencies, and try to upgrade again. |
При попытке заменить образ ESXi 6.0 от IBM на образ ESXi 6.7 от Lenovo получил охапку конфликтов с различными утилитами для железяк: Continue reading “Ошибка при обновлении Custom Image VMware ESXi “The upgrade has VIBs that are missing dependencies””
Прошлый месяц был богат на развлечения.
Не успели мы решить проблему с “где-то” исчезающими хранилищами, как пришла новая беда: после сбоя пара виртуальных машин отказались включаться с одного VMFS-хранилища.
Операция Browse Datastore ясности не принесла – содержимое хранилища было абсолютно пустым.
Я не поленился проверить – включенные с этого хранилища виртуальные машины успешно работали.