vmware autodeploy что это
blog.vmpress.org
Страницы
пятница, 29 октября 2010 г.
Настраиваем VMware Auto Deploy
Признаться, я всегда мечтал, чтобы когда-нибудь во всех современных приложениях появилась большая круглая красная кнопка «Работать», нажав которую, администратор по прошествии определенного времени получал бы полностью настроенную и работоспособную систему. И хотя VMware Auto Deploy пока не обладает такой кнопкой, но, во всяком случае, делает уверенные шаги в нужном направлении.
На текущий момент Auto Deploy находится на этапе Techinal Preview, что не гарантирует стабильной работы в производственной среде, но не мешает нам опробовать ее в деле. Загрузить предварительную версию Auto Deploy можно по этой ссылке.
Установка Auto Deploy
Распакуйте содержимой в любой доступный для vCenter Server каталог. Подключитесь клиентом VMware vSphere Client к серверу. Запустите мастер импорта виртуальных машин из OVF шаблона, нажав File -> Deploy OVF Template.
На странице Ready to Complete нажмите Finish.
Дождитесь, пока файлы скопируются на хранилище и машина будет зарегистрирована в vCenter. Запустите виртуальную машину Auto Deploy.
Настройка Auto Deploy
Откройте консоль виртуальной машины Auto Deploy и дождитесь окончания загрузки ОС. При первом старте будет автоматически запущен мастер настройки, позволяющий задать сетевые параметры ВМ. Если в вашей сети еще не настроен DHCP сервер, можете задать статические настройки.
Настройка DHCP
Для автоматической выдачи сетевых параметров серверам ESXi вам потребуется развернуть сервер DHCP. Вы можете использовать DHCP сервер, встроенный в виртуальную машину или сторонний сервер DHCP в вашей сети. Для примера рассмотрим конфигурацию DHCP сервера в ОС Windows Server 2008.
Откройте консоль управления DHCP сервером. Если у вас уже настроена область с нужным диапазоном адресов, можете использовать ее, в противном случае создайте новую область.
Раскройте область, щелкните правой кнопкой мыши по Scope Options и выберите Configure Options. На вкладке General укажите в качестве значения для опции 066 Boot Server Host Name имя или IP сервера Auto Deploy.
Теперь можно попробовать загрузить на сервер виртуализации ESXi по сети. Зайдите на ваш сервер и в качестве предпочитаемого источника загрузки выберите сетевой адаптер. В данном примере в качестве такого сервера я использовал другую виртуальную машину.
Если вы правильно настроили DHCP и Auto Deploy, то сервер виртуализации получит необходимые сетевые настройки и начнет процесс загрузки. После ее завершения вы получите вполне работоспособный сервер ESXi, который можете настроить по собственному желанию.
Использование Host Profiles
Понятно, что в силу особенностей загрузки ESXi по сети, настройки вашего сервера и все изменения, которые вы на нем выполните сохранятся до первого выключения. И хотя сервер, развернутый в производственной среде, может не перезагружаться месяцами, а то и годами, гораздо более практичным будет использование функции Host Profiles, доступной в редакции vSphere Enterprise Plus, которая позволяет применять нужные настройки автоматически при каждой загрузке сервера.
Для создания профиля в Host Profiles вам понадобится эталонный сервер, например тот, который вы только что загрузили по сети. Для начала откройте локальную консоль и задайте пароль для учетной записи root (по умолчанию пароля нет).
Выполните на нем все необходимые настройки (добавьте виртуальные коммутаторы и группы портов, настройте синхронизацию времени, добавьте учетные записи пользователей и группы).
На странице Ready to complete the profile нажмите Finish.
Настоятельно рекомендуется отредактировать созданный профиль и настроить в нем автоматическое назначение пароля для учетной записи root. Для этого щелкните правой кнопкой мыши по созданному профилю и выберите Edit Profile.
На запрос системы введите имя и пароль учетной записи пользователя, которая имеет административные права на сервере vCenter.
Для проверки успешности добавления сервера можете воспользоваться командой:
vifp listservers
Каждую запись характеризует следующий набор параметров:
При каждой загрузке сервера виртуализации Auto Deploy просматривает базу и, исходя из назначенного серверу профиля, передает ему нужный загрузочный образ ESXi, а также регистрирует сервер в vCenter, применяет Host Profiles и п.р.
Для просмотра списка доступных профилей используйте команду:
deploy-cmd listprofiles
Например, следующая команда позволит настроит профиль default так, чтобы Auto Deploy автоматически регистрировал серверы в vCenter и применял к ним ранее созданный Host Profile:
Если вас не устраивает, что в vCenter серверы ESXi регистрируются по IP адресу, а не по DNS имени, то исправить это можно, создав соответствующие PTR записи в reversed lookup зоне на DNS сервере, который обслуживает vCenter.
Наконец, я заметил следующую закономерность. При тестах использовались виртуальные серверы ESXi. Частенько при добавлении такого сервера в кластер, если для него выделено меньше 3 Гб памяти, можно получить следующее сообщение об ошибке: «Cannot complete the configuration of the HA agent on the host. Other HA configuration error«.
Auto Deploy
Enabling the GUI for Image Builder
Because the Image Builder and Auto Deploy features are tightly coupled, the UI is only visible when both of these services are running. To enable the GUI, navigate to Administration > System Configuration > Services in the vSphere Web Client. Start both services, and set them to start automatically, if desired. Then log out and back in to the Web Client to verify the Auto Deploy object is available.
Alternatively, these services can be enabled via command line. Simply SSH into the VCSA and run the following commands:
Regardless of whether Auto Deploy is in use in an environment or not, the Image Builder GUI is a convenient alternative to the PowerCLI cmdlets previously required for creating custom VMware ESXi images. Administrators can upload zip depots of images and drivers, as well as create online depots that connect to VMware or OEM partner image repositories.
In addition to being available to Auto Deploy for deploy rule creation, the UI also allows administrators to customize, compare, or export images to ISO or zip format for a variety of uses. The vSphere 6.5 product documentation describes the functionality in more detail.
Even though the PowerCLI Image Builder is still available, this new Image Builder GUI helps those customers that prefer a more guided approach for these tasks.
Using the GUI for Auto Deploy
Auto Deploy GUI – Software Depots and Deploy Rules Walkthrough
New Discovered Hosts Workflow
Auto Deploy GUI – Discovered Hosts Walkthrough
VMware vSphere 6.5 Auto Deploy Discovered Hosts Workflow Demo
Adding Reverse Proxy Caching
The latest release of VMware vSphere contains improvements to Auto Deploy, including a new graphical user interface, a new deployment workflow, and various manageability and operational enhancements. One such enhancement is a dramatically-simplified caching capability.
There are several reasons why you might consider adding reverse proxy caching to your Auto Deploy infrastructure. First, this design will reduce the load on the vCenter Server Appliance and Auto Deploy service, freeing up resources for other processes. Second, the boot time of individual stateless VMware ESXi hosts is modestly improved – saving about 30 seconds in a typical setup, possibly more in a heavily-loaded environment. Finally, you can potentially boot far more stateless hosts concurrently without overwhelming the VCSA.
Resiliency is a natural priority when changing critical infrastructure components. I’m glad to report that the new reverse proxy design does not create a single point of failure, since you can deploy multiple proxy servers that are tried in a round-robin sequence with no load balancers. Furthermore, if all proxies happen to become unavailable, the stateless clients fail gracefully back to the default behavior of directly accessing the Auto Deploy server. This is a welcome improvement over previous releases. Just keep in mind that the caches are only for performance optimization, and not for redundancy of the overall stateless infrastructure – the Auto Deploy server is still in charge and must be online for successful host boot operations.
Instant Reverse Proxy Container
If you like the sound of these benefits, then it’s easy enough to test this design by quickly deploying a Docker container configured for the task. Create one or two Linux VMs running Docker (I’m using PhotonOS in my lab) and fire up the Nginx container that I published on Hub:
In the above example, the proxy will listen on port 5100 and fetch any requested ESXi image files from your existing Auto Deploy server located at 10.197.34.22. Run this container on each VM that will act as a proxy, and make note of their IP addresses for the next part.
Connectivity Test
Before you configure Auto Deploy to use these new caches, it’s a good idea to verify connectivity. One way to do this is to watch the Nginx log file while manually requesting a file from the cache.
To watch the Nginx log, get the id of the container and use the docker logs –f command:
Then, request the Auto Deploy tramp file from another system, like so:
Confirm that the proxy responds immediately with the above output. If it does not, go back and double-check addresses, ports, and other potential connectivity problems. Also, observe the log file that is being tailed for a corresponding hit.
Activate the Proxies
Now that you have one or more reverse proxies up and running, it’s time to configure Auto Deploy to start using them. This is done by using PowerCLI, through a new cmdlet introduced in the 6.5 release. Run the following command for each proxy you need to register, adjusting the address accordingly:
Check the configuration by running Get-ProxyServer, and if necessary, remove a proxy from rotation with the Remove-ProxyServer cmdlet.At this point, any stateless hosts that boot will use the cache. You can verify the configuration by accessing the Auto Deploy diagnostics web interface:
Action!
Boot or reboot stateless hosts, and they will access the proxy caches. You can monitor requests coming to the Auto Deploy server and to the caches to verify the changes have taken effect. Note that the first time a host boots, the proxy will need to fetch all the files from Auto Deploy to cache them. After that, everything but a small set of non-cacheable files will be served from the caches.
The caches are easy to monitor through the docker logs command, as described above. It’s also pretty simple to watch key activity on the Auto Deploy (VCSA) system. Try the following command with and without the caches enabled if you want to get a feel for the boot time reduction in your environment:
From Concept to Production
The example above is a proof of concept, intended to help you understand how to configure and monitor the effects of reverse proxies. For most production datacenters, it would be wise to create a proxy server that is equipped with SSL certificates so that the traffic between hosts and the proxies can be encrypted. The Nginx SSL configuration is straightforward, but beyond the scope of this article. You can also read how I created the container if you want to use that as a reference.
Summary
The new reverse proxy cache feature in Auto Deploy 6.5 is very easy to set up, and will boost performance without introducing additional failure points to your vSphere infrastructure. Docker containers running Nginx offer a simple way to demonstrate the concept in your environment.
Vmware autodeploy что это
Добрый день уважаемые читатели блога pyatilistnik.org, сегодня хочу рассказать, как производится установка Auto Deploy. Уверен, что многие из вас уже слышали про данный продукт, а может быть и уже пробовали внедрять, если нет, то эта статья для вас. Я всегда стараюсь вам подкидывать интересные проекты, статьи по теме виртуализации, давно известно, что когда ты кому-то объясняешь, как и что работает, то сам в этом становишься разбираться лучше, поэтому старайтесь общаться и не зажимать знания, не будьте редисками. Всегда приятно, когда куму-то помог.
Что это:
Auto Deploy – это сервер дистанционной загрузки ESXi по PXE
Зачем он нужен :
Для упрощения ввода в эксплуатацию новых серверов, обновления существующих.
Как это работает:
Для того, чтобы ввести новый сервер в эксплуатацию, нам не надо устанавливать на него ESXi. Нам надо:
После этого при каждой перезагрузке пункт 2 будет повторятся, но уже без нашего вмешательства к серверу будут применяться настройки.
Заменив только образ на сервере AutoDeploy, мы получим обновленные сервера ESXi просто после их перезагрузки, так как стартовать они будут с этого обновленного образа.
Выводы
Прикольная штука. Работает. Нареканий, на удивление, не вызвало. Однако с использование в производственной среде пока непонятно – смущает зависимость возможности старта всех(!) серверов ESXi от машин vCenter и AutoDeploy. Получается, они должны работать или на отдельном кластере vSphere, или на железном сервере, рядом с которым стоит резервный железный сервер. Интересно послушать ваши мнения, особенно тех, в чем ведении десятки и сотни серверов ESXi.
Настройка VMware Auto Deploy
Шаги настройки этого продукта.
1) Устанавливаем Auto Deploy под Windows.
Установка Auto Deploy
По идее, правильно это делать на отдельную машину, однако у меня почему-то не получилось – выдавало ошибки о невозможности сгенерить ssl. В итоге поставил на машину с vCenter.
Кстати, на vCenter Appliance служба Auto Deploy уже предустановлена.
После успешной установки появляется пиктограмма на странице Home в клиенте vSphere
2) Устанавливаем доп-софт, настраиваем DHCP и TFTP
Также TFTP и DHCP требует специальной настройки:
Пройдя по иконке Auto Deploy в клиенте vSphere, мы получим возможность загрузить файл – TFTP Boot.
Установка Auto Deploy-03
Следует загрузить этот архив, и распаковать в папку, выбранную для доступности по TFTP. Файл “undionly.kpxe.vmw-hardwired” следует указать как загрузочный образ.
В настройках DHCP следует прописать параметры:
66 – адрес сервера TFT
67 – имя файла загрузки (undionly.kpxe.vmw-hardwired)
(для серверов с EFI вместо BIOS файл вроде другой).
Теперь в данном сегменте сети сервера могут загрузиться по PXE, однако загружается только предварительная оболочка, которая ругается что нет образа ESXi для загрузки его на данный сервер
Установка Auto Deploy-04
3) Настраиваем Auto Deploy
Нам потребуется PowerCLI и в нем открытая сессия к vCenter.
Кроме этого, потребуется дистрибутив ESXi (не в виде iso, а в виде zip. Т.н. software depot, загружается там же, где и iso-вариант).
Обратите внимание – этот дистрибутив можно изменить под себя, обновив или добавив драйверы под свое железо, или такие компоненты как, например, виртуальная циска.
Установка Auto Deploy-05
В командлете New-DeployRule параметром –Item мы привязываем к стартующим с этого правила серверам контейнер в vCenter (datacenter, cluster, folder) куда они должны быть помещены, Image profile, host profile.
Кроме как для самого первого сервера указывать, скорее всего, будем сразу несколько параметров, как в моем примере:
Установка Auto Deploy-06
Теперь сервера начнут загружаться в ESXi. И даже автоматически будут зарегистрированы в vCenter, в тот Datacenter, Cluster или Folder, который был указан при создании правила (у меня это кластер). Какие паттерны, признаки серверов, доступны:
Установка Auto Deploy-07
Как видите, мы можем довольно точно назначать тот или иной образ ESXi на сервера по критериям. По производителю, по mac адресу, и пр.
4) Настройка автоматической настройки серверов
Итак, первый сервер стартовал и даже был добавлен в vCenter.
Однако – сервер никак не настроен.
С учетом того, что ESXi был загружен в память по сети, даже если что-то настроить руками – эти настройки пропадут после перезагрузки.
Поэтому для настройки серверов, разворачиваемых при помощи Auto Deploy используется механизм Host Profiles, параметры которого сохраняются в базе vCenter.
Нам потребуется настроить этот первый сервер:
Теперь создадим с этого сервера профиль, и сразу на этот же сервер его и назначим.
Проверим на соответствие. Проверка покажет расхождения в конфигурации, нам потребуется создать файл ответов (Update answer file).
После прохождения мастера – Check answer file, затем check complince.
Значение в столбце Answer File Status должно стать Complete, настройки сервера должны стать соответствующими этому профилю.
Все. Теперь при перезагрузках сервер будет не только загружать на себя ESXi, но и конфигурацию подтягивать.
На этом этапе мы имеем первый сервер, и этот сервер загружается по сети, и настраивается профилем настроек.
5) Настройка загрузки второго и всех следующих серверов:
Надо изменить правило AutoDeploy так, чтобы оно еще профиль настроек привязывало к загружаемым серверам. Допустим, вы делали по моему примеру, и создали правило командой:
Установка Auto Deploy-08
Удалим это правило командой
Установка Auto Deploy-09
Создадим заново, но теперь указав и ранее созданный профиль настроек:
Установка Auto Deploy-10
Установка Auto Deploy-11
Теперь любой новый сервер, будучи загруженным в первый раз, сразу попадает в кластер “ClusterAutoDeploy”, и на него назначается профиль настроек “2AutoDeploy”.
Нам остается нажать “Update answer file”, указать уникальные параметры типа IP адресов и т.п., и все – сервер готов к эксплуатации, его настройки после каждой перезагрузки будут подтягиваться из этого файла ответов.
Обновление образа
Допустим, у нас есть желание заменить дистрибутив ESXi, с которого стартуют сервера. Например, мы хотим использовать VMware HA – и нам имеет смысл добавить его агента сразу в образ. Для этого нам потребуется следующие команды:
Настройка vSphere Auto Deploy
Рассмотрим vSphere Auto Deploy. Данная функция позволяет хостам грузиться по PXE и не иметь локальных дисков, а также может служить прекрасным автоматизированным инструментом для массовой установки ESXi. Это отличная функция, которая облегчает и сводит к одной перезагрузки гипервизора обновление или апгрейд инфраструктуры. Но на этом ее плюсы не ограничиваются, перечислять их можно довольно долго, но данная статья носит более технический характер, нежели маркетинговый. Что нужно для использования Auto Deploy в инфраструктуре:
У Auto deploy присутствуют несколько режимов использования, а именно:
Stateless
Хост загружается по сети всегда, для этого нужен высоко доступный Auto Deploy, если он не доступен, ESXi не загрузится
Stateless Caching
Образ ESXi (Image Profile) вместе с настройками и параметрами кэшируется на локальных дисках сервера. Это не полноценная установка, а временное хранение профиля гипервизора. В случае, когда сервер Auto Deploy недоступен и только тогда, ESXi будет грузиться с локального кэша, но при этом есть казус, добавиться в vCenter без доступного Auto Deploy хост все равно не сможет. Но сам ESXi будет доступен для администрирования через Host Client.
Statefull Install
В данном режиме происходит полноценная установка ESXi на локальные диски или флешку сервера и Auto Deploy после этого уже не нужен для загрузки.
Как работает?
Терминология
Заранее подготовленная инфраструктура
Как упоминалось выше нам понадобятся DHCP, TFTP и DNS. Освещать процесс их развертывания тут я не буду, ибо есть масса специализированных гайдов в сети. Стоит правда затронуть несколько моментов. Для ESXi, которые мы будем развертывать стоит настроить заранее записи DNS, причем как A запись, так и PTR. PTR запись будет использоваться службой Auto deploy при назначении hostname для хоста во время как первого развертывания, так и всех последующих, что даст нам удобство использования имен вместо IP для ESXi. В области DHCP, которая будет обслуживать нашу инфраструктуру нужно настроить параметры 66 и 67. В параметре 66 просто указать IP или hostname нашего TFTP сервера, в параметре 67 имя файла загрузчика, об этом позже. Так же нужно настроить резервацию адресов для каждого хоста, что бы одному и тому же хосту всегда назначался один и тот же IP. На TFTP разместить все необходимые файлы, а это и файл загрузчика и многие другие, но об этом тоже позже. Просто это действия нужно выполнить до начала использования Auto Deploy и развертывания первого хоста. Дополнительно на необходимо скачать для дальнейшего использования и развертывания хостов, подходящий для нас ESXi Offline Bundle с сайта VMware или из другого источника. Следует настроить на серверах, которые будут использовать Auto Deploy, в BIOS или UEFI загрузку с сетевой карты и поставить ее на первое место в Boot Order. Так же следует убедиться, что сервера DHCP, DNS, TFTP и сам Auto Deploy доступны хостам по сети и VLAN-ы настроены корректно на сетевом оборудовании.
Настройка Auto Deploy
Начнем настраивать нашу службу Auto Deploy. В приведенном мной примере используется инфраструктура vSphere 6.7 и HTML5 клиент, хоть она уже и не является самой последней версией «сферы», но шаги, описанные тут, актуальны и для vSphere 7.0, к тому же моя «лаба» используется для подготовки к сертификации VCAP-DCV Deploy, а экзамен пока что основан на 6.7.
Включим службу Auto Deploy пройдя в Administration> Auto Deploy> Enable Auto Deploy and Image Builder, после этого мы можем конфигурировать его.
Теперь нужно добавить ESXi Offline Bundle, который мы заблаговременно скачали в Software Depot. Переходим Software Depot> New> Custom, задаем имя и указываем файл ZIP. После чего бандл загружается в Auto Deploy, и мы можем увидеть какие Image Profile и Software Package он содержит.
Далее нам необходимо загрузить на TFTP сервер нужные файлы, что бы хосты ESXi могли грузиться по сети и настроить 67 параметр DHCP. Эти файлы нужно скачать с самого Auto Deploy, который при старте службы сгенерировал их и прописал в них свой адрес и параметры подключения. Идем в Auto Deploy> Configure и нажимаем DOWNLOAD TFTP ZIP FILE.
Нам загружается архив с множеством файлов, среди которых и сами загрузчики. Распаковываем архив и копируем все содержимое на TFTP, можно в корневую папку. Определяем какой файл загрузчика нам нужно использовать. Посмотрим на Summary на слайде выше. Доступно три загрузчика – один для BIOS и два для UEFI систем. Выбираем подходящий для наших серверов, с учетом того с какой подсистемы они будут грузиться. Названия этого файла, или путь до него (если положили его не в корень TFTP) указываем в 67 параметре DHCP, с этого загрузчика будут грузиться хосты, которые обслуживаются DHCP. Если в инфраструктуре будут находиться хосты, использующие разные подсистемы (BIOS и UEFI), стоит разделить их пулами DHCP и в настройка пулов прописать разные файлы загрузчиков.
Настроим Deploy Rules. Переходим в одноименную вкладку и нажимаем New Deploy Rule.
Выбираем ему имя и указываем к каким хостам оно будет применяться. Можно выбрать все хосты без исключения или же разграничить использования этого правила только на сервера, соответствующие определенному критерию, или сразу нескольким, что делает наши правила очень гибкими. Для тестового стенда можно ограничиться выбором All hosts.
Далее мы назначаем какие компоненты будут применяться к развертываемым с помощью данного правила хостам. Выбираем только Image Profile, так как у нас нет еще Reference хоста, с которого мы будем снимать Host Profile. Жмем NEXT. Выбираем Image Profile, в моем примере это — ESXi-6.7.0-20191204001-standard. Подтверждаем, и вот мы создали провило, которое будет определять какие хосты каким образом обеспечивать и что с ними дальше делать.
После того, как правило готово, что бы оно стало применься к хостам в момент их загрузки, нужно активировать его. В Deployment Rules нажимаем ACTIVATE/DEACTIVATE RULES и перемещаем наше правило наверх, это активирует его.
На этом этапе мы подготовили инфраструктуру к использованию Auto Deploy и настал момент это проверить и загрузить наш Reference Host. Как описано выше, это первый хост, который в дальнейшем послужит «примером» для остальных. Штош… приступим… Включаем первый сервер, предварительно убеждаемся в том что загрузка по сети включена. После инициализации BIOS/UEFI, и скачивания загрузчика с TFTP наблюдаем картинку ниже.
Первый хост загрузился и через некоторое время появился в vCenter. Если настроена PTR запись на DNS, то ESXi будет добавлен по hostname, что существенно облегчит администратору жизнь.
Далее нужно настроить Reference Host и извлечь с него Host Profile. Описывать настройку тут я не буду, потому как это процесс сугубо индивидуальный для каждой инфраструктуры, но есть характерные для Auto Deploy хостов параметры, которые стоит настроить:
Эта процедура описана тут. А мы двигаемся дальше.
После настройки Reference хоста и извлечения с него Host Profile необходимо вернуться к Deploy Rules, деактивировать действующее правило, так как изменить его в активном состоянии нельзя. Редактируем наше Deploy Rule и на шаге Configure ставим галочку на позиции Host Profile и выбираем извлеченный профиль с Reference хоста. Сохраняем наши изменения. Готово, теперь все хосты, развернутые по данному правилу, будут наследовать этот профиль и применять его настройки.
Дальше мы можем разворачивать новые хосты с помощью этого правила, на них будут применятся настройки из выбранного Host Profile за исключением параметров customization, или если по-другому, то это персональные настройки хоста, например, IP, iqn и так далее, которые должны быть индивидуальны у каждого хоста. Они заполняются вручную после развертывания нового хоста и добавления его в vCenter.
Так как у хоста первый раз загруженного посредством Auto Deploy и добавленного в vCenter отсутствуют данные Customizations в применяемом Host Profile — хост перейдет в Maintenance Mode. Наша задача – это заполнить ему Host Customizations и вывести из Maintenance Mode. Дальше можно использовать его для эксплуатации. После того как мы проделаем с каждым хостом такую операцию, работу по настройке Auto Deploy инфраструктуры можно считать завершенной.