Настройка vSphere AutoDeploy

vladimir vSphere

Предисловие

В данной статье вернемся к теме AutoDeploy и попытаемся раскрыть ее более подробно. Разберем как оно работает и настроим реальный инфраструктурный пример. Функция эта доступна в лицензии vSphere Enterprise Plus.

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

Происходит это следующим образом:

  1. Физический сервер включается и пытается получить IP настройки с DHCP так как заранее настроена PXE загрузка в BIOS или UEFI сервера.
  2. Заранее настроенный DHCP сервер выдает серверу IP адрес, шлюз, DNS, опции 66 (адрес TFTP сервера) и 67(файл загрузки на TFTP сервере).
  3. Физический сервер с полученными IP параметрами лезет на TFTP сервер и загружает указанный в DHCP опции 67 файл загрузчика.
  4. Сервер исполняет код загрузчика, в котором указан адрес vCenter, затем сервер обращается к vCenter за образом ESXi, а vCenter в зависимости от настроенных правил предоставляет серверу определенный образ гипервизора для загрузки, определенный Host Profile с настройками гипервизора.
  5. Сервер «скачивает» образ ESXi вместе с назначенным ему Host Profile и загружается с него, применяя на себя настройки из профиля и становиться доступный в инвентаре vCenter.

Ключевое звено в данной технологии – PXE загрузка по сети. DHCP и TFTP сервера должны быть отказоустойчивы. На случай если это не так или если вы хотите иметь дополнительный уровень надежности загрузки ваших гипервизоров, то можно использовать функцию Stateless Caching. При ее включении образ гипервизора с настройками (Host Profile) кэшируется на локальных дисках или USB карте на физическом сервере и, если вдруг по какой-то причине во время перезагрузки ESXi DHCP, TFTP или VLAN для PXE загрузки недоступен, гипервизор может загрузиться с кэша и быть готовым к работе.

Немного про Host Profile. Это не менее важный компонент во всей цепи. Host Profile содержит в себе свод настроек ESXi хоста, который применяется для типовой настройки нескольких хостов. С помощью Host Profile можно задать конфиг почти любого параметра на хосте («почти»!). Host Profile содержит «общие настройки» которые применимы к нескольким хостам сразу – например, где хранить логи, какая портгруппа назначена на vmkernel интерфейсы, правила firewall и так далее. А что касается «личных» параметров гипервизора, типа IP адрес vmkernel интерфейса или hostname храниться в Host Customization, который является индивидуальным для каждого хоста, к которому применен Host Profile. После того как на хост назначается Host Profile, для этого хоста заполняется Host Customization. Список параметров указываемых в Host Customization хоста зависит от фигурируемых в Host Profile параметров. Например, если в Host Profile включена настройка vmkernel интерфейса, то у Host Customization хоста будет строка, заполняющая IP адрес этого интерфейса.

Вернемся к пункту номер 5. Что происходит если хост грузиться первый раз, и никогда еще не был в vCenter до этого, а также не имеет никакого назначенного c помощью Deployment Rule (правило определяющее какой образ грузить и какой профиль использовать) профиля с настройками? В такой ситуации хост после загрузки не имеет никаких настроек и даже пароля. Ему так же нужно добавиться в vCenter, но для этого нужно иметь сетевые настройки. И все будет нормально ведь у нас есть DHCP который настроит сеть на гипервизоре, ведь с AutoDeploy мы же используем DHCP, правда? Но если мы подумаем про все сетевое в перспективе инфраструктуры, то выплывают некоторые нюансы архитектуры нашего решения.

Management VLAN

В мало-мальски серьезных инфраструктурах присутствует сегмент управления или Management VLAN в котором заведены интерфейсы vmkernel, поговорим про них в контексте AutoDeploy. Так как у нас нет никаких предварительных настроек на гипервизоре после первой загрузки в том числе и настроенного VLAN для менеджмента, а наш vmkernel интерфейс по умолчанию болтается в не тегируемом VLAN, то и адрес с помощью DHCP он получит тоже только из так называемого Default VLAN. Если у нас сеть управления ESXi выделена в отдельный VLAN, и он не является не тегированным (что наверняка) то есть подан транком на сетевые интерфейсы хоста вместе со всеми другими VLAN-ами для виртуальных машин, то единственный шанс нам обеспечить DHCP для менеджмента без ручного взаимодействия с хостом – это выделенный интерфейс с подведенным менеджмент VLAN в режиме access. А это не особо хорошее решение так как с выделенным интерфейсом для управления мы теряем гибкость и отказоустойчивость, поэтому менеджмент VLAN в большинстве случаев приходит в одной «пачке» с остальными. Как быть?

Первый вариант. После первой загрузки ESXi хоста можно ручками подключиться к его DCUI и прописать ему Management VLAN и IP (если не используем DHCP) или только VLAN и дальше наш хост получит IP с DHCP. После этого он добавиться в vCenter, так как появилась сеть, и мы начнем его конфигурировать дальше уже из интерфейса vCenter. В нашем примере мы будем использовать именно этот вариант.

Второй вариант. Использовать Script Bundle – совсем без взаимодействия. Это достаточно гибкий и сложный вариант конфига хостов, мы его рассматривать не будем.

PXE сегмент

Теперь следующий нюанс. PXE сегмент или VLAN. Мы можем производить загрузку PXE хостов по тому же VLAN, где сидит менеджмент ну и соответственно иметь DHCP и общее IP пространство для vmk интерфейсов и для загружающихся по PXE хостов. И будет так что хост грузится по PXE с IP 192.168.1.10 (условно) и после загрузки его vmk получает этот же адрес. Это удобно, просто, но подойдет разве что для тестовой среды или лабы.

А для среды с сегментацией, безопасностью и изоляцией нам возможно придется разделить эти пространства. Что бы хост грузился в одном VLAN, а потом менеджмент поднимался в другом, это эстетически правильнее. Но по умолчанию обычные сетевые карточки в режиме PXE не понимают VLAN-ы и загрузиться могут только с VLAN поданного не тегированным, так произойдет если вы настраиваете лабу с виртуальными ESXi. Что бы решить эту проблему и загружаться с определенного VLAN-а — нам нужны серверные сетевые карты с функцией настройки VLAN-а для PXE.

Про DNS немного

Вкратце нам нужен DNS для всех тех же вещей что и без AutoDeploy. Что бы добавлять хосты по имени, что бы все работало и так далее. Но дополнительная важность DNS возникает при AutoDeploy. Если предварительно до развертывания хоста через AutoDeploy создать в DNS ему запись с обратной зоной (важно!), то при добавлении в vCenter хост добавиться по hostname. Удобно. Но обязательно нужна обратная зона.

Про DHCP

Понятно, что именно этот товарищ и обеспечит нам выдачу IP для PXE загрузки и укажет откуда грузиться и самое главное – какой файл грузить. Рекомендуется что бы для каждого хоста создавать резервацию IP адреса, то есть что бы при загрузке с PXE один и тот же хост всегда получал один и тот же IP адрес. Ну и, конечно, если мы выбрали использовать DHCP в Management сети, обязательно нужно создавать резервацию адреса на vmk интерфейс.

Об архитектуре

Итак, мы поняли, что нам нужно держать в отдельных VLAN-ах сегменты PXE загрузки и менеджмент хостов. А также использовать статические IP в менеджмент сети. То есть IP адреса vmk интерфейсов будут указываться в Host Customization каждого хоста, а не выдаваться DHCP. Хосты после загрузки будут применят их профиль вместе с IP.

Безусловно мы можем решить использовать и в менеджмент сети DHCP, предварительно настроив резервацию адреса для каждого хоста (без резервации будут проблемы), так же мы можем захотеть использовать один VLAN и для менеджмента, и для PXE и еще круче использовать для этого Native VLAN (не тегированный VLAN). Наш выбор зависит от архитектуры и принятого инженером решения, неважно какого.

В данном топике же я рассматриваю вариант наиболее пригодный для среднестатистической инфраструктуры, где — нужен AutoDeploy, присутствуют определенные ограничения безопасности и должна быть независимость сети управления гипервизорами от DHCP. А это значит отдельные сегменты для PXE и сети управления, статичекий адрес vmk интерфейса, прибитый в кастомизации хоста, а также Stateless Caching (если вдруг недоступна сеть PXE вообще – гипервизор загрузиться с кеша).

Итак, что требуется для настройки:

  • vCenter 7.0
  • Два VLAN-а — 1970 (PXE 10.15.70.0/24) и 1971 (Management 10.15.71. 0/24)
  • Два железных сервера HP ProLiant XL230a Gen9
  • DNS сервер
  • DHCP сервер в PXE VLAN (10.15.70.11)
  • TFTP сервер (10.15.70.11)

Для тестирования или домашней лабы, конечно, подойдет и виртуальный ESXi, но в таком случае мы не сможем настроить что бы VM выбирала для PXE определенный VLAN, так как логика виртуальной сетевой карточки не рассчитана на это. А в нашем примере происходит именно так.

Настройка

Конфигурация UEFI сервера

Для начала настроим в BIOS сервера загрузку с сетевого адаптера и укажем VLAN, с которого нужно грузиться. У меня в распоряжении были сервера HPE ProLiant XL230a Gen9, покажу на их примере. Итак, сервер грузиться, мы ловим момент, жмем F9 и заходим в конфигурацию UEFI или по-другому System Utilities.  Далее идем System Configuration>BIOS/Platform Configuration>Network Options> VLAN Configuration.

Теперь разберем нашу тестовую инфраструктуру.

И выставляем в поле VLAN ID номер VLAN с которого мы планируем грузиться. Теперь настало время настроить порядок загрузки сервера. Идем в System Configuration>BIOS/Platform Configuration и тут выставляем Boot Mode – UEFI Mode. Что странно, в Legacy Mode загрузиться по определенному VLAN у меня не получилось на этой модели сервера. Но в вашем случае вы можете выбрать режим Legacy исходя из каких-либо убеждений. Выбор режима не влияет на функционал AutoDeploy, от выбранного режима зависит только какой файл нужно грузить хосту с TFTP, но об этом позже.

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

Стоит отметить, что гипервизор загрузиться правильно и получит верные настройки в независимости от того какой адаптер учувствовал в PXE загрузки. И это отличная причина для того, чтобы не париться и оставить оба адаптера в списке загрузки для отказоустойчивости.

Итак, мы настроили PXE загрузку в UEFI, выбрали с какого VLAN-а это будет происходить и настроили что после неудачной попытки загрузиться из сети, хост «полезет» за кешом на диск.

Включение Auto Deploy

Включим службу Auto Deploy на vCenter. Идем из главного меню во вкладку Auto Deploy и включаем – Enable Auto Deploy and Image Builder.

Теперь нам нужно загрузить образ ESXi гипервизора которым будут грузиться наши будущие сервера на vCenter. Нам нужен не iso образ, а offline bundle. Я загрузил с My VMware образ HPE-ESXi-6.7.0-Update2-Gen9plus-670.U2.10.4.1.8. Который как раз рекомендован для моей модели сервера. Теперь нам нужно создать Software Depot на основе этого образа в vCenter. Идем в Auto Deploy>Software Depot и в правом верхнем углу интерфейса нажимаем IMPORT. Называем «как то» (я назвал 6.7 gen9 u3) наш новый Software Depot и выбираем скачанный zip файл с образом ESXi на нашем ПК. После импорта у нас появляются Software Depot с образом (Image Profile) и пакетами (их можно посмотреть во вкладке Software Package).

Этот образ и будем использовать для загрузки гипервизоров. Теперь нам нужно пойти во вкладку Configure и скачать TFTP file. В этом файле содержаться компонент, который скачивается загружающимся хостом и содержит загрузчик и инструкции куда обращаться за загрузкой образа ESXi, то есть координаты vCenter. Этот архив будет в дальнейшем распакован на TFTP сервере.

Так же во вкладке Configure указано какие файлы используются при каком режиме загрузки. Помним, что у нас UEFI без Secure Boot и нам нужен snponly64.efi.vmw-hardwired. Сохраняем архив на локальный компьютер, он нам понадобиться позже.

Теперь настало время настроить Deployment Rule. Это правила, которые определяют какой хост будет загружен каким образом ESXi, какой Host Profile примениться на этот хост и куда будет хост помещен в итоге (Datacenter или кластер). Правила применяются на загружающиеся хосты в момент контакта с vCenter, как раз после того, как хост получил загрузчик с TFTP и «полез» за образом на vCenter. Хосты сортируются и проходят обработку по правилам почти таким же образом как пакеты в сетевом ACL – сверху вниз. И если хост попадает под одно правило, то обработка останавливается, и он загружается с прописанными в правиле образом, профилем и помещается в определенное правилом место. Критериями для задействования того или иного правила служат многочисленные параметры хоста, которые он передает в vCenter во время обращения за образом ESXi. Среди этих параметров есть модель сервера, вендор, серийный номер и много чего еще, чтобы удобно сортировать хосты и сопоставлять их определенным версиям ESXi или настройками в Host Profile.

Давайте создадим первое правило. Жмем NEW DEPLOY RULE.

Отсортируем в нашем правиле хосты по имени производителя и по конкретной модели. Стоит отметить, что имя производителя – коварная штука. На одних серверах HP это HPE, на других просто HP.

На следующем шаге (Configuration) оставляем выбранным Host Location и Image Profile. Host Profile мы пока не указываем, так как его у нас просто еще нету, а первый хост загрузить надо. Локацию хоста указываем в Datacenter, так как кластеров еще нет. Сохраняем наше правило. Но это еще не все, пока что правило неактивно. Нажимаем ACTIVATE/DEACTIVATE RULES, в появившемся окне отмечаем галкой наше правило и перемещаем его в верхний отдел нажатием кнопки ACTIVATE. Так же в этом окне можно перемещать правила вверх и вниз, меняя их порядок.

Итак, дамы и господа, на этом этапе мы подготовили vCenter к загрузке первого хоста.

Настройка DHCP/TFTP/DNS

Настало время вспомогательных служб. Начнем с DHCP. Я использовал стандартный DHCP сервер от великого Microsoft. В нашем случае мы используем его в тестовых целях, и он смотрит своим интерфейсом напрямую в VLAN для PXE, никаких helper и так далее.

Настроен Scope 10.15.70.0/24 который имеет следующие Scope Options:

Router. Да-да это шлюз по умолчанию.

DNS Servers, тоже что то знакомое.

Boot Server Host Name. Этот параметр содержит IP адрес или hostname TFTP сервера. Сервера с которого будет происходить первоначальная загрузка хоста.

Bootfile Name. А это имя файла, который нужно будет хосту загрузить с TFTP сервера. Это имя будет зависеть от того в каком режиме грузиться хост (Legacy или UEFI).

Для удобства можно настроить Reservation адресов и «приколотить» каждому NIC свой IP адрес. Это можно сделать для удобства или если это большая продуктивная среда, что бы у каждого хоста и у каждого сетевого адаптера на хосте был гарантированный адрес для загрузки. А также в Reservation мы можем указать индивидуальные DHCP Options. Например, другой файл загрузчика на TFTP (67-я опция), допустим для сервера, который UEFI не поддерживает.

Теперь очередь TFTP. Я не стал изощряться и скачал доступный и бесплатный Tftpd64, простой и понятный. Установил его на ту же машину что и DHCP сервер и смотрит он соответственно в PXE VLAN. Так как у нас все-таки тест, никакой отказоустойчивости нет. А надо бы, но это тема не сегодняшней дискуссии.

После установки я создал директорию TFTP в корне диска C:\ и распаковал туда наш архив, скачанный с vCenter.

Далее настроил C:\TFTP как Base Directory в настройках Tftpd и «прибил» сервис TFTP к адресу сетевого интерфейса сервера.

На этом с TFTP все. Идем к DNS. Тут особо сказать нечего кроме того, что если мы хотим, чтобы хосты после загрузки добавлялись в инвентори vCenter по hostname а не по IP, то нам нужно создать ЗАРАНЕЕ им записи и добавить их так же в зону обратного просмотра (reverse zone). Потому что когда хост первый раз загружается с помощью Auto Deploy, vCenter проверяет присутствует ли для его IP обратная запись в DNS, и если да, то добавляет хост по имени. Если же ESXi был добавлен в vCenter по IP при первой загрузке (то есть обратной записи у него не было), то в дальнейшем даже если настроить после этого обратную запись в DNS, хост будет после каждой перезагрузки оставаться под своим IP в инвентаре, что бы это исправить, нужно удалить хост из vCenter и перезагрузить его, что бы он добавился в vCenter как новый объект.

На этом первичная настройка завершена и нам остается загрузить первый хост (Reference Host).

Загрузка Reference Host

Загружаем наш заранее настроенный хост. После того как прошли все этапы инициализации мы видим это:

Затем не обычную на первый взгляд загрузку ESXi.

А также на TFTP сервере мы будем видеть, что сервер обращается за файлами.

Этого достаточно что бы понять, что мы настроили все правильно.

Но это еще не все. Теперь, когда наш хост загрузился, он не имеет IP адреса, да и вообще ничего не имеет (даже пароля на root пользователе), так как согласно Deployment Rule, все что нужно дать новому хосту это Image Profile. Хост даже самостоятельно в vCenter из-за отсутствия IP адреса добавиться не может, но будет пытаться. Нам нужно ему немного помочь. Подключившись к нему по DCUI, мы конфигурируем хосту:

  • Management VLAN (1791 в нашем случае)
  • Статический IP (10.15.71.103), шлюз (10.15.71.1) и маску(24) (так как у нас нет DHCP в сети управления)
  • Активные vmnic-и (по умолчанию обычно выбирается один, но мы можем выбрать все необходимые, у меня это оба)
  • DNS сервера
  • Hostname и DNS суффикс(опционально)

Это нужно что бы хост был доступен по сети и смог достучаться до vCenter для последующего добавления. Далее идем в интерфейс vCenter и там с большой долей вероятности увидим уже добавленных в инвентори хост.

Мы добавили наш первых хост в vCenter. Теперь настало время для того, чтобы сделать его Reference Host-ом. Reference Host – эталонных хост, который будет «примером» всем остальным. А как — опишу ниже.

Далее последовательность действий, следующая:

  • Закончить конфигурацию Reference Host-а.
  • Извлечь с него Host Profile.
  • Подредактировать Host Profile.
  • Прикрепить к нашему Reference Host извлеченный с него же подредактированный Host Profile.
  • Заполнить Host Customization для нашего reference Host-а.
  • Добавить свеже созданный Host Profile в Deploument Rule.
  • Развернуть остальные хосты с помощью этого Deploument Rule.
  • ???
  • PROFIT

Настройка Reference Host-а

Тут все очень просто. Нам нужно довести до конца начатую выше операцию по конфигурированию первого ESXi хоста, загруженного с Auto Deploy. В предыдущем шаге мы настроили ему сетевую связность, но все остальные параметры остались не заданы и нужно это исправить.

Я не буду описывать тут все что нужно сконфигурировать на хосте, это было бы очень долго. Но я думаю такие вещи как добавление нашего Reference Host в VDS или настройка места сбора логов (ведь постоянного локального хранилища у хоста нет), должны иметь место. Reference Host конфигурируется таким же образом как и обычный, развернутый без участия Auto Deploy. Единственно только его перезагружать не следует до изменения Deployment Rule, иначе начинать настройку придется сначала, ведь хост загрузится без конфигов.

Предположим, что мы настроили хост и он готов к следующему шагу.

Возня с Host Profile

Наступило время повозиться с Host Profile. Для начала нам нужно извлечь его с только что настроенного хоста. Для этого выбираем наш ESXi в интерфейсе, жмем правую кнопку мыши, выбираем Host Profile> Extract Host Profile, даем ему имя (я назвал Gen9) и сохраняем. Когда мы извлекаем Host Profile из ESXi, мы копируем в профиль почти все настройки с этого хоста, исключая персональные параметры, такие как IP адрес хоста его hostname и так далее, ведь их одновременно не могут иметь несколько серверов. И эти самые персональные параметры каждый хост, на который назначили Host Profile, хранит в своем Host Customization.

Host Customization создается и заполняется когда на хост назначается Host Profile. А список параметров в Host Customization зависит от списка настроек, перечисленных в Host Profile, которые требую индивидуального значения на каждом хосте, например IP адрес vMotion интерфейса. Например, vMotion интерфейс согласно профилю должен быть в VLAN 15 (это прописано в Host Profile и это общая настройка для всех хостов), а IP адрес прописан в Customization (так как для каждого хоста он индивидуален).

Окей. Возвращаемся к нашему хосту и его профилю. Нужно отредактировать Host Profile и оставить в нем только нужные настройки, а не все подряд которые в нем есть. Идем в Menu> Policies and Profiles>Host Profiles>Gen 9(наш профиль)>Configure>EDIT HOST PROFILE. Во вкладке Settings нас ждут разделы и подразделы настроек ESXi гипервизора. Они многочисленны и все их описывать тут не буду.

Очень важны настройки сети, и они в 100% случаев должны содержаться в профиле, ну если только вы не используйте DHCP в сети управления, а сама сеть управления не подана access-ом на порты гипервизора. Также есть одна очень важная настройка, которая определяет какой режим Auto Deploy используется для хостов. Это Advanced Configuration Settings> System Image Cache Configuration, она описывает будет ли происходить кеширование образа гипервизора (Stateless Caching) на диск при загрузке или же может будет происходить установка ESXi при первой загрузке (Statefull Install), а может быть ничего не будет происходить и в этом случае гипервизору всегда придется грузиться по сети. В нашем варианте хост имеет подключенные локальные диски, и я бы хотел иметь кеш, что бы при недоступности опорной инфраструктуры PXE гипервизор мог загрузиться с диска. Поэтому в этой настройке я указываю – Enable stateless caching on the host. В аргументах указываем что для кеширования должен быть выбран по возможности локальный диск. А также в этом параметре мы можем указать использовать или нет SSD диски и можно ли пере затирать существующий том VMFS, если таковой имеется на выбранном диске. Я оставил эти галочки пустыми.

Другой очень важный аспект, это root пароль. Помним он у нас пуст. Найти его настройку можно в Security and Services> Security Settings> User Configuration>root. Да таким образом, назначая настройку в этом месте мы можем управлять паролями для всех хостов. И мы можем задать фиксированный пароль для всех хостов (что, конечно, не особо безопасно), или задавать для каждого хоста индивидуальный пароль в кастомизации.

После того как мы оставили только необходимые настройки, сохраняем профиль. Идем на наш хост и прикрепляем к нему наш отредактированный профиль, кнопкой ATTACH в разделе Configure>Host Profile.  После того как прикрепили, снизу появляется секция Host Customizations, да-а именно та самая. В ней уже автоматически заполнены параметры для хоста. Нам нужно лишь утвердить их. Нажимаем EDIT HOST CUSTOMIZATION. Некоторые параметры могут быть пустыми и требовать заполнения, это случается если у хоста отсутствуют некоторые настройки, которые есть в Host Profile, но у Reference Host-а такого как правило нет, потому что мы прикрепляем к нему профиль, который только что с него же и извлекли. Помним, что в нашей архитектуре мы используем статические IP адреса для сети управления ESXi и наш хост, когда будет грузиться в последующие разы IP адрес себе возьмёт именно отсюда.  Сохраняем Customizations.

Теперь идем и добавляем наш профиль Gen 9 в Deployment Rule, что бы теперь хосты этой модели загружались не просто с указанным нам образом, но и еще с набором четких настроек.

Для изменения Deployment Rule его для начала нужно деактивировать. Идем в Auto Deploy>Deploy Rules, а дальше следует процедура, обратная той, что мы проделывали совсем недавно, активируя правило. После деактивации у правила появиться подсвеченная кнопка EDIT. Используем ее и на шаге указания Host Profile… указываем его. Сохраняем и заново активируем правило.

Нужно теперь проверить все «наконфигурированное» на практике. Перезагрузим наш Reference Host и после того, как он успешно «подымится» и станет доступным в vCenter, убедимся в присутствии настроек из прикрепленного Host Profile. Перезагружаем.

После не очень быстрой процедуры загрузки мы ожидаемо видим, что хост снова становиться доступным в vCenter, но при этом в Maintenance Mode. И выходит из него похоже не собирается. В чем дело? Согласитесь неудобно, наверное, каждый хост руками выводить после перезагрузки или включения из Maintenance Mode. Дело в том, что хост после загрузки с Auto Deploy применяет на себя настройки, содержащиеся в Host Profile, и после того, как он стал доступен для vCenter, тот в свою очередь не допустит хост к работе пока не убедится в том, что хост полностью соответствует описанным в Host Profile настройкам.

Именно поэтому хост «загоняется» в режим обслуживания, и сразу запускается Pre-Check, а затем Remediation. Только после того, как Remediation полностью успешно завершился, хост выводится из Maintenance Mode автоматически и может вступать в работу. Теперь стоит вспомнить что мы настраивали кеширование на локальный диск. И оно как раз-таки случается на этапе Remediation. Если в этот момент мы зайдем в мониторинг дисковой активности, мы увидим всплеск активности ввода-вывода на наш локальный диск, который был выбран ESXi для кеширования.

На самом блочном устройстве мы найдем несколько разделов, которые и есть тот самый кеш. Так же на этом разделе может быть и VMFS раздел, который является локальным датастором.

Бывает и так что хост не может сделать Remediation, в таком случае он останется в режиме обслуживания и выдаст ошибку в Summary хоста. Такое случается, как правило, когда мы внесли какие-либо «неперевариваемые» ESXi настройки в Host Profile и применили его. Настройки могут быть некорректные, либо синтаксис значений в настройках нарушен. Вообще содержание Host Profile штука непростая и некорректные его параметры, заданные неправильно — способны вообще поломать хост, ну а в лучшем случае постоянно докучать ошибками и предупреждениями о несоответствии профиля и состояния хоста. Стоит относится к этому соответственно. Держите в Host Profile только те параметры, которые Вам необходимо применять ко всем хостам, исключите все лишнее. После того так хост развернутый с помощью Auto Deploy добавился в vCenter, и получил свой Host Profile и настройки согласно Deployment Rule, он появляется в разделе AutoDeploy>Deploued Hosts. В данном списке мы можем увидеть своеобразный маппинг Host-Image Profile-Host Profile-Location-Script Bundle. То есть совокупность настроек, получаемую конкретным хостом при загрузке.

И что примечательно, так это то, что если вы поменяете что то в Deployment Rule, с помощью которого разворачивали данный хост (допустим изменили Image Profile на более новый), то после перезагрузки хоста по факту загружаемый ему Image Profile не измениться. Для этого (именно для смены Image Profile) нужно изменить маппинг с помощью EDIT IMAGE PROFILE.

Настройка второго хоста

Итак, хост поднялся, все путем, и мы видим, что настроено все корректно и цикл перезагрузки с Auto Deploy работает корректно. Настало время добавить в инфраструктуру нашему Reference Host-у компаньона и настроить его. Посмотрим, как обстоит дело НЕ с Reference Host.

Помним, что у нас есть еще второй такой же железный сервер Gen 9. Настраиваем ему загрузку с PXE так же, как и первому (VLAN, порядок загрузки и так далее) и грузим. Не забываем про DNS запись.

Хост подымается, загружается гипервизор, применяется Host Profile. Ну и, наверное, все нормально будет, да? Почти. ESXi загрузиться, а вот настройки с Host Profile применяться за исключением Host Customization, где у нас IP, маска, hostname. Потому что у хоста отсутствует Customization, его еще не задавали ему, потому как он ни разу еще не был в vCenter. И что дальше? Дальше мы, как и в первом случае с Reference Host-ом лезем в DCUI и настраиваем ему IP, hostname, DNS и шлюз. Если вы задали общий пароль в Host Profile, то есть использовали в параметре Security and Services>Security Settings>Security>User Configuration>root в графе Password значение Fixed password configuration, то заметите что от Вас хотят пароль, это говорит о том что Host Profile применился, пусть и без Customization.

 Повторю, если у вас DHCP и в менеджмент сети, вас это минует. В моем же примере его нет и у всех хостов прибитая руками в Host Customization статика. Что подходит Вам больше, решать только Вам.

После того как хост станет доступен по сетке, он «полезет» сам в vCenter. Как только он будет добавлен в vCenter, нам остается простой шаг, зайти в Configure-Host Profile и заполнить ему Customization. После этого можно перезагрузить хост и убедиться, что настроено все правильно после того, как он загрузиться. Так же можно просто сделать Check-Compliance его Host Profile, а после Remediation что бы хост записал кеш своего образа на диск сразу, не дожидаясь перезагрузки (так на самом деле и с первым хостом можно было поступить, без перезагрузки, но рестарт дает нам проверку, что Auto Deploy работает).

В дальнейшем хосты можно добавлять в Auto Deploy по примеру второго сервера.

У нас есть два хоста, полностью загружаемые с помощью Auto Deploy, Host Profile для этой модели серверов и в принципе задачу разбора Auto Deploy можно закрыть.