От редакции VM Guru: представляем вам статью нового автора VM Guru - Романа Гельмана. Роман специализируется на автоматизации IT-процессов и проектах миграции в физических и виртуальных средах.
Автоматическая установка сама по себе несложный процесс, хотя и требует некоторых базовых знаний. Сложно здесь другое – развернуть вспомогательную инфраструктуру для загрузки по сети, включающую в себя PXE, TFTP и DHCP сервера и настроить её должным образом. Возможно также понадобится web-сервер, плюс сконфигурировать Firewall и сами серверы IBM для PXE-загрузки. А для этого, во-первых, нужно обладать глубокими техническими знаниями во многих областях и, во-вторых, это требует длительных временных затрат, ну и, в-третьих, это не всегда возможно в связи с внутриорганизационной политикой. Если вы, как и я, не хотите всё это делать, но всё же хотите использовать все прелести автоматической установки, то эта статья для вас.
Из статьи вы узнаете:
Как создать файл автоматической установки KS.CFG
Как отредактировать конфигурационный файл загрузчика BOOT.CFG для чтения инструкций из вашего файла автоматической установки.
Как поместить эти файлы внутрь установочного образа диска (файл ISO) гипервайзора VMware ESXi на компьютере с Windows (большинство руководств используют для этого Linux).
Каким образом отредактировать мой PowerShell скрипт, чтобы он подходил к вашему файлу/файлам автоматической установки.
Как с помощью этого скрипта и образа диска гипервайзора полностью автоматически с нуля инсталлировать хост ESXi на сервере/серверах IBM/Lenovo.
KS.CFG - файл автоматической установки хоста ESXi
KS.CFG - это обычный текстовый файл, содержащий инструкции для установщика ESXi. Он заменяет собой ваши ответы в процессе интерактивной установки. Файл может включать в себя несколько видов инструкций: поддерживаемые команды инсталляции (Supported Installation Script Commands), команды ESXi (такие как vim-cmd и esxcli) и команды BusyBox (например cat или cp). Также вы можете объявлять и использовать переменные, как я это сделал в моём файле для задания сетевых параметров. Советую вам взять его за пример при построении вашего собственного файла.
В процессе статьи мы подробно разберём все команды из моего файла. Это лишь несколько ссылок для дополнительного исследования:
О Supported Installation Script Commands вы можете почитать в документе от VMware «vSphere Installation and Setup» на страницах 143-152.
Также советую почитать этот Knowledge Base от VMware и обязательно заглянуть на сайт William Lam в рубрику Kickstart.
О vim-cmd читайте здесь и esxcli команды описаны здесь.
На что стоит обратить внимание при автоматической установке?
1. Команда rootpw –-iscrypted содержит зашифрованный пароль root. Понятно, что хранить такой пароль в чистом виде даже внутри ISO-файла это потенциальная угроза, особенно, если вы его не меняете после окончания установки. Резонный вопрос, где его взять? Для этого нужно произвести одну установку именно с того образа, который вы планируете использовать, на контрольный ESXi, подключиться к хосту по SSH и запустить следующую команду:
cat /etc/shadow |grep root |cut -d':' -f2
Если соображения безопасности вас не беспокоят, или вы меняете пароль root по окончанию установки, то можно использовать директиву rootpw без -–iscrypted.
2. Команда install --firstdisk –-overwritevmfs с одной стороны очень гибкая и универсальная, с другой существует вероятность случайно отформатировать fiber LUN, содержащий важные данные, например, файлы виртуальных машин.
Здесь есть два решения, либо использовать более точные директивы install --disk=diskname или install –-firstdisk=disk-type, либо физически отключать порты HBA адаптеров перед установкой.
3. Для будущего использования…
BOOT.CFG - конфигурационный файл загрузчика ESXi
Файл BOOT.CFG находится на установочном диске ESXi в директории \EFI\BOOT\. Как и KS.CFG, это текстовый файл. Нас интересует только одна строчка kernelopt=runweasel, регулирующая опции загрузки ядра. Требуется заменить её на kernelopt=ks=cdrom:/KS.CFG - тем самым мы указываем установщику где находится наш файл KS.CFG (cdrom:/KS.CFG – в корне диска).
Есть ещё одна необязательная, но интересная директива title=. То, что вы напишете в этой строчке, будет отображаться в самом верху экрана во время установки. По умолчанию это «Loading ESXi installer». Можете тут разместить свою рекламу.
«Внедрение» файлов KS.CFG и BOOT.CFG внутрь установочного образа ESXi
Администраторы Linux для редактирования загрузочных образов пользуются утилитой командной строки mkisofs. Windows администраторы могут использовать для этих нужд программу WinISO с прекрасным и интуитивно понятным GUI.
После того, как вы создали и сохранили файлы KS.CFG и BOOT.CFG, откройте установочный образ ESXi с помощью WinISO, добавьте файл KS.CFG в корень образа, как показано на картинке (Add Files):
А файл BOOT.CFG в директорию \EFI\BOOT\:
И сохраните образ (Save). Вся прелесть в том, что образ при этом останется загрузочным!
PowerShell скрипт для управления автоматической установкой ESXi
В принципе, на создании образа автоматической установки можно было бы и остановиться. Всё, что осталось сделать - это вставить диск в привод или смонтировать образ диска в виртуальный привод сервера и загрузиться с него. Дальше сидите и наслаждайтесь ходом установки без единого вмешательства с вашей стороны.
Для чего же тогда нужен этот скрипт?
Условно можно разделить его работу на 3 основных этапа:
1. Необходимые предварительные проверки и конфигурирование.
2. Монтирование образа и слежение за ходом установки.
3. Пост-инсталляционная конфигурация.
Итак, начнём по порядку:
Необходимые предварительные проверки и конфигурирование
Отличительной особенностью данного метода установки является то, что каждый новый ESXi после установки будет иметь один и тот же IP адрес (тот, который присвоен переменной VMK0_IP в файле KS.CFG). С одной стороны, это недостаток, поскольку не позволяет запустить одновременно несколько инсталляций, что приведёт к конфликту IP-адресов. С другой, это большой плюс для пост-инсталляционной конфигурации, поскольку вы заранее знаете с каким IP поднимется ваш хост.
Одной из основных проверок является проверка трёх IP-адресов на предмет занятости и существования в DNS: начальный IP адрес хоста (VMK0_IP), будущий IP адрес (параметр -MgmtIPv4) и IP-адрес для vMotion (параметр -vMotionIPv4).
Поскольку изначальное имя хоста (задано командой esxcli system hostname set в файле KS.CFG) и пароль root (задан директивой rootpw в файле KS.CFG) также являются константами, есть смысл их сохранить на машине администратора для первичной аутентикации на всех хостах. Для надёжного хранения этих данных используется зашифрованный XML файл, так называемое «хранилище паролей» (VI credential store). По умолчанию этот файл находится в директории %APPDATA%\VMware\credstore\ и выглядит примерно вот так: vicredentials.xml.
Скрипт при запуске проверяет, есть ли уже подобная запись в «хранилище» и если нет, то создаёт её. Если вы по какой-то причине поменяли пароль root в файле KS.CFG, вы также можете поменять его и в «хранилище» на вашем компьютере, запустив скрипт с параметром –Cred.
Важно сказать, что данный скрипт предназначен только для серверов IBM/Lenovo. Предварительная конфигурация сервера (изменение порядка загрузки - CDROM first) и монтирование образа диска выполняется через карту управления сервером (IMM) при помощи специального пакета утилит IBM, называемых ASU (Advanced Settings Utility). Для скачивания и ознакомления с этими утилитами вы можете обратиться к моей статье «PowerShell модуль для управления серверами IBM». Не забудьте отредактировать переменные $asuExec, $rdMount и $rdUMount в соответствии с их расположением на вашем компьютере (все они находятся в регионе #region Variables).
Скрипт попросит у вас логин (credentials) для подключения к IMM, который вы указали либо в параметре –IMMHostname (имя IMM, если конечно оно прописано в DNS) либо в -IMMIPv4 (IP адрес IMM):
Далее скрипт изменяет порядок загрузки сервера (Boot Order) так, чтобы загрузиться с вашего образа (CD/DVD Rom -> Floppy Disk -> Hard Disk 0 -> PXE Network). Если вам важно сохранить порядок загрузки, то используйте параметр –SaveBootOrder, скрипт сохранит существующий порядок загрузки и восстановит его по окончанию установки.
Монтирование образа и слежение за ходом установки
Убедившись, что порядок загрузки успешно изменён, скрипт монтирует образ в виртуальный привод сервера (ISO-файл, указанный в параметре -KickstartISO) и делает рестарт сервера.
Надо понимать, что если образ, который вы создали, не является полностью автоматическим (содержит недостаточно информации с точки зрения установщика ESXi), либо содержит критические ошибки в файле KS.CFG, то и скрипт не будет корректно работать. Рекомендую вам первый раз испытать ваш образ вручную, убедившись, что он действительно совершенно не требует вашего вмешательства.
Если вы указали параметр –SaveBootOrder, то порядок загрузки будет восстановлен ещё до самого первого рестарта хоста. Учтите, что, если ваш оригинальный порядок загрузки не включает в себя устройство, с которого загружается ESXi (директива install файла KS.CFG), то скрипт будет ждать, пока вы это не скорректируете (либо вручную в BIOS сервера, либо с помощью моего модуля PowerShell для управления серверами IBM). Далее вы будете наблюдать за продвижением этапов установки, скрипт отследит все рестарты, требуемые в процессе установки и своевременно на них отреагирует (всё займёт в районе получаса).
Пост-инсталляционная конфигурация
По окончанию установки скрипт пытается подсоединиться к вашему новоиспечённому хосту, но уже не через IMM, а напрямую к хосту (по имени, присвоенному переменной $ksCfgVMHost). Чтобы это сработало, должны обязательно выполняться два условия:
Во-первых, ваш компьютер должен транслировать (resolve) имя, указанное в $ksCfgVMHost в IP-адрес, присвоенный переменной VMK0_IP в файле KS.CFG. Желательно прописать его в DNS, если кроме вас ещё кто-то в организации будет пользоваться этим скриптом, но будет вполне достаточно записать его в hosts файл на вашем компьютере. Для примера в моём файле KS.CFG имя (hostname или A-record) esxprdXX должно транслироваться в IP адрес 10.200.21.160.
Во-вторых, сетевые адаптеры (uplinks), определённые в файле KS.CFG для управления хостом должны быть подключены в соответствующую их настройкам физическую сеть. На примере моего файла KS.CFG.
Uplinks (vmnic0 и vmnic1), подключенные в vSwitch0, это обеспечивается следующими командами (строки, начинающиеся с символа «#» это комментарии):
### Uplinks ###
esxcli network vswitch standard uplink add --uplink-name=vmnic0 --vswitch-name=vSwitch0
esxcli network vswitch standard uplink add --uplink-name=vmnic1 --vswitch-name=vSwitch0
vSwitch0 содержит Portgroup, называемую «Management Network»:
PGMGMT="Management Network"
VLANMGMT=21
### Portgroups ###
esxcli network vswitch standard portgroup set --portgroup-name="${PGMGMT}" --vlan-id=${VLANMGMT}
И в этой Portgroup находится VMKernel порт, предназначенный для управления хостом:
VMK0_IP=10.200.21.160
### VMKernel ports ###
esxcli network ip interface add --interface-name=vmk0 --mtu=1500 --portgroup-name=${PGMGMT}
esxcli network ip interface ipv4 set --interface-name=vmk0 --ipv4=${VMK0_IP} --netmask=255.255.255.0 --type=static
esxcli network ip interface tag add -i vmk0 -t Management
Суммируя всё вышесказанное: хотя бы один сетевой адаптер (в моём случае vmnic0 или vmnic1) должен быть подключен в сеть 10.200.21.0/24 VLAN 21. Почему не оба, а хотя бы один? Потому что в Default Policies для vSwitch0 оба адаптера являются активными (--active-uplinks=):
### Default Policies ###
esxcli network vswitch standard policy failover set --active-uplinks=vmnic0,vmnic1 …
Несколько слов по поводу нумерации сетевых адаптеров. Гипервизор автоматически добавляет индекс, начиная с нуля, к каждому сетевому порту. Встроенные в плату (embedded) порты нумеруются в первую очередь слева направо, если вы смотрите на сервер сзади. Нумерация портов дополнительных адаптеров производится сверху вниз по портам адаптера и слева направо по адаптерам.
К сожалению данный скрипт не является универсальным в том смысле, что некоторые вещи в нём тесно связаны с конфигурацией вашего файла или файлов KS.CFG. Почему файлов? Конечно же, в каждом образе может быть только один файл KS.CFG, но у вас может быть сколько угодно таких образов для разных сред или для различных кластеров, например, один для производственной среды, один для тестов или лабораторий и ещё один для DMZ.
Все эти образы могут управляться одним скриптом, для этого создан параметр -Env или –Environment, который принимает одно из значений, указанных в атрибуте ValidateSet самого параметра: [ValidateSet('NET','DMZ','CLOUD')] в регионе #region Parameters. Каждый из них предназначен для конкретного образа, а точнее для конкретного файла KS.CFG и имеет набор настроек, объявленных в регионе #region Variables.
Допустим вы хотите добавить новую конфигурацию и назвать её VDI, вы просто добавляете в оператор Switch ещё одно значение и соответствующие ему параметры:
Значения переменных, начинающихся с $ksCfg должны подходить соответствующим настройкам файла KS.CFG, переменные, начинающиеся с $env относятся к инфраструктуре, в которой вы разворачиваете новый хост: $envDNSServer и $envDNSZone это DNS-сервер и DNS-зона, в которой скрипт будет создавать A-record для нового хоста. Кстати, не забудьте установить PowerShell модуль DnsServer перед использованием скрипта (он является частью Remote Server Administration Tools - RSAT).
Ну и, наконец, переменная $envBehindFW регулирует позволяют ли настройки сети, в которой вы разворачиваете хост ESXi отвечать на ping и взаимодействовать с DNS-сервером с вашего административного компьютера. Если значение этой переменной равно $true, то скрипт не будет проверять и создавать A-record в DNS и не будет выполнять никаких проверок занятости IP адресов (все эти проверки и действия вы возлагаете на себя).
Да, и не забудьте добавить вашу новую конфигурацию в атрибут ValidateSet параметра –Env следующим образом:
[ValidateSet('NET','DMZ','CLOUD','VDI')]
Напоследок скрипт переименовывает хост на имя, указанное в параметре –VMHostBorn, меняет IP-адрес для vMotion, если вы его указали (параметр -vMotionIPv4) и IP адрес для управления (параметр -MgmtIPv4), отсоединяется от хоста и прописывает хост в DNS.
В итоге, меньше чем за час вы получаете максимально сконфигурированный, а главное стандартизованный хост, готовый к регистрации в vCenter. Такой подход исключает ошибки и недоработки, которые неизбежно возникают при ручной установке и конфигурации.
Обратите внимание на одни из последних команд в файле KS.CFG:
Эти команды копируют лог файлы процесса установки на Datastore «LocalDS-XX», который мы переименовали со стандартного «datastore1»:
### Rename local datastore
vim-cmd hostsvc/datastore/rename datastore1 "LocalDS-XX"
Если что-то пошло не так во время установки, вы всегда можете просмотреть эти логи.
Сам скрипт Kickstart-VMHostIMM.ps1 вы можете скачать здесь. Он содержит в себе дополнительную информацию о всех поддерживаемых параметрах и несколько примеров использования. Всё это можно просмотреть с помощью следующих команд (предварительно перейдите в папку, где вы сохранили скрипт):
И здесь вы можете скачать все файлы, упомянутые в статье.
Из моей следующей статьи вы узнаете, как с помощью PowerCLi скрипта зарегистрировать ESXi хост в vCenter, добавить его в HA-cluster, переименовать локальный Datastore, подключить к Distributed vSwitch и многое другое. Забегая вперёд, скажу, что с помощью образа автоматической установки и этих двух скриптов один администратор за один рабочий день может полностью с нуля развернуть кластер из 10-12 хостов, параллельно занимаясь повседневными заботами, которых у нас всегда в избытке.