Сообщения
Интересная штука:
1) Идем сюда, скачиваем виртуальную машину под названием AutoDeploy (чуть более гигабайта размером).
2) Импортируем ее к себе на vSphere.
3) Включаем, выполняем минимальную настройку в локальной консоли.
4) Включаем [предполагается физический] сервер, указываем загружаться по PXE.
5) Видим такую картинку на его мониторе сервера из п.4:
Виртуальная машина AutoDeploy – предварительная версия официального (!) сервера сетевой загрузки ESXi.
Настройка
Какие минимальные настройки нужны для выполнения этой самой сетевой загрузки:- на шаге 3 AutoDeploy следует подключить к сети из которой есть доступ к управляющей сети vSphere (в частности, к vCenter);
- в составе AutoDeploy есть сервер DHCP. Если предполагается использовать его, а не внешнего DHCP сервера, то следует выполнить команду
sudo deploy-cmd dhcpconfig
- все, программа минимум выполнена.
- указать vCenter (или несколько), в консоль которых следует добавить сервера, и в которых хранятся Host Profiles для применения
- создать сами профили настроек
- и всякое по мелочи
Факты:
- AutoDeploy основан на vMA (внутри 64-битный Linux плюс всякий разный софт).
- cодержит в себе необходимые службы для организации загрузки (DHCP, TFTP, NFS, HTTP и др.).
- содержит базу соотношения MAC адресов серверов ESXi и профилей настроек, которые следует к каждому серверу применять.
- содержит набор специальных команд для настройки – deploy-cmd. Управление текущей версий AutoDeploy только из командной строки.
- для уникальной настройки каждого сервера ESXi используется механизм Host Profiles (доступен лишь в Enterprise Plus лицензии vSphere).
Мне пришлось загружать AutoDeploy на vSphere, а затем сразу экспортировать в VMware Workstation, где благополучно и запустилась. Напрямую в Workstation AutoDeploy импортироваться отказался.
UPD. http://vmpress.blogspot.com/2010/10/vmware-auto-deploy.html
Расскажите вкратце про плюсы и минусы (если есть) загрузки ESXi по PXE
ОтветитьУдалитьSkyrod7
skyrod7
ОтветитьУдалитьлокальные диски убрать можно
Кстати да, sky rod - сорри, я забыл сразу ответить на Ваш вопрос.
ОтветитьУдалитьДействительно, плюсом является то, что нет нужды в локальных дисках сервера, и в резервном копировании конфигурации серверов esxi. (справедливости ради стоит заметить, что последнее и так мало кто делает).
Минусом - то, что загрузку по pxe как-то надо организовать, и потом администрировать то что организовалось.
Михаил, но ведь локальная дисковая ёмкость (конечно, не абы какая, а достаточно шустрая) позволит держать на ней своп-файлы VM`ок, не отжирая трафф у сети и IOPSы у СХД.
ОтветитьУдалитьПонятно, что на тяжёлых СХД и/или толстых сетях это может (п)оказаться неактуальным, но в общем и целом быстрый своппинг на локальное хранилище может быть весьма полезным, нет?
С уважением,
Umlyaut.
Если вы имеете в виду vmkernel swap, то: он используется тогда, когда память сервера загружена более чем на 96%. Я рискну предположить, что такие ситуации редки. А ситуации, когда и свое начал таки использоваться, и расположение его на локальных дисках дало плюсы - можно пересчитать по большим пальцам одной руки.
ОтветитьУдалитьВсе имхо, но я готов обосновывать.
Выше: не свое а своп. Автоподсказки на мобильных дивайсах не всегда рулят
ОтветитьУдалить>Если вы имеете в виду vmkernel swap, то: он используется тогда, когда память сервера загружена более чем на 96%. Я рискну предположить, что такие ситуации редки.
ОтветитьУдалитьНу, в штатном режиме работы хорошо спланированной VI - возможно. Но если, скажем, VM`ки с лёгшего хоста (или хостов) расползутся по оставшимся в строю, то пуркуа бы и не получить подобный расклад на руки? В таком разе память работающих хостов может быть забита "под завязку" - вот тогда и будем радостно вытесняться не на сетевое СХД, а на шустрый локальный датастор.
А на счёт того, насколько вероятна подобная ситуация... ну-у-ууу... в этом мире вероятно всё (или почти всё), что имеет потенциальную возможность произойти - да и в конце-то концов не зря же Варя сделала возможность "отчуждать" этот файл от общего набора файлов конкретной VM`ки...
С уважением,
Umlyaut.
ЗЫ: а ещё локальные стораджи приличной ёмкости и шустрости дадут возможность (в случае чего) перекинуть на них на время VM`ки с СХД, чтобы иметь возможность что-то с ней сделать... :)
ЗЗЫ: >Автоподсказки на мобильных дивайсах...
Ага, так Вы, всё же, в отпуске! :) А то блог-то регулярненько подновляется - вот я и думал, что Вы "в строю"... Ну, я с завтрева тоже "выйду за скобки" до конца недели - и уж инет-гаджетов с собой точно брать не буду, отдохну в офф-лайне... :D
стоят ли локальные диски призрачных плюсов в маловероятных ситуациях - это каждый сам решает.
ОтветитьУдалитья считаю что плюсы от расположения свопа на локальных дисках - призрачны, и эти призрачные плюсы будут только в маловероятных ситуациях.
Umlyaut,
ОтветитьУдалитьРеально для того, чтобы локальные диски могли обеспечить нормальный swap, нужно, чтобы это были SSD. Иначе они только затормозят все еще больше.
Скажем, у меня есть несколько ESX'ов с 2*SATA 5400rpm в зеркале. Количество IOPS с таких диском можно сравнить с IOPS c той же MSA2000 на 16 SAS 10k дисках, например.
как я понял, Umlyaut имел в виду что своп на локальных дисках лучше тем, что он не занимает места на СХД, не тратит ее IOPS и не нагружает пути к ней.
ОтветитьУдалитьСам своп все равно тормозной, где бы он не лежал, чудес не бывает.
>как я понял, Umlyaut имел в виду что...
ОтветитьУдалитьМихаил, Вы действительно всё правильно поняли. :)
Насчёт того, что "сам своп всё равно тормозной, где бы он ни лежал"... ну-у-ууу... конечно, за оперативкой не угонится и своп на страйпе из SSD-шек (в крайнем случае упрётся в шину).
Другое дело, что локал сторадж - это совсем не обязательно "зеркало" на малооборотистых SATAх, как выше сутрировал Антон: "десятка" на полудюжине-десятке даже SATA-хардов на 7к2 и нормальном контроллере может оказаться достойной заменой в качестве свопохранилища тому же перегруженному запросами СХД.
Опять же, повторюсь - выгода от локального датастора хоста не ограничивается хранением свопов: сюда нужно приплюсовать и возможность временного переезда на него VM`ок с СХД для регламента последнего (надысь была темка на Варерусишюзергруппенфоруме - про апдейт фирмвари хранилки "на лету").
В эту же строку и лыко о "редундантности" (ага, пинали меня уже за етот термин-кальку, больше не нужно, да :) ) - конечно, хорошо, что хост будет жужжать свою песню даже с крякнувшей стартовой флешкой, но вот при перезагрузке будет бо-бо. Ага, можно переткнуть флешку на резервную со сбыкапленным конфигом - но требует вмешательства админа, тогда как с избыточным локальным стораджем мы поднимемся на автомате (ага-ага, ещё одна приснопамятная дискуссия на том же форуме... :)).
В общем, можете считать это моим "родимым пятном" (как говорится, "отрыжка проклятого прошлого"), но если у меня будет возможность использовать отказоустойчивую локальную дисковую подсистему на хосте, то я с удовольствием это сделаю...
Вот как-то так... :)))
С уважением,
Umlyaut.
Umlyaut, цена вопроса для используемых у меня HP BL460 и BL490:
ОтветитьУдалить1) 2*300 SAS 10k = 1050$
2) 2*146 SAS 15k = 1000$
3) 2*500 SAS 7.2k = 840$
4) 2*60 SATA SSD = 3000$
Это на (!)каждый сервер.
Что такое 1k$? Это почти лицензия на vSphere Standard, или почти апгрейд со Standard на Advanced.
3k$ - это больше, чем стоимость Advanced, или апгрейд со Standard на Enterprise Plus. В случае 2х-процессорного сервера - это 2 Standard с 2х-летней поддержкой или апгрейд со Standard до Advanced.
Или вернемся к чисто технической стороне вопроса.
1k$ = 8 GB модуль или 2*4GB
3k$ = 2*16GB
Как думаете, лучше 2 SSD по 60GB для свопа или 32GB памяти, чтобы своп не случился?
>Другое дело, что локал сторадж - это совсем не обязательно "зеркало" на малооборотистых SATAх, как выше сутрировал Антон
ОтветитьУдалитьКстати, никакого утрирования. В блейды ставится максимум два диска. И у меня действительно есть ESX'ы, у которых 2 SATA по 5400 rpm в зеркале.
Anton wrote:
ОтветитьУдалить>Umlyaut, цена вопроса для используемых у меня HP BL460 и BL490:
>Как думаете, лучше 2 SSD по 60GB для свопа или 32GB памяти, чтобы своп не случился?
Ну конечно оператива лучше любого свопа - кто бы спорил. :)
Правда, не всегда бывает возможным "добить планки" - мешают либо "заградительная цена" на модули максимального номинала (рядом возникает проблема "утилизации" заменяемых модулей меньшего размера), либо банальное отсутствие свободных слотов под память на имеющейся платформе.
Но это так, присказка. Сказка-то в другом совсем...
Антон, мы с Вами, в общем-то, тянем одну молитву - только с разных минаретов. :)))
Вы - матёрый виртуализатор (как я это про себя, бывает, бурчу, - "игрок высшей лиги"). Я же - простой админ, для которого виртуализация является лишь одним из многих инструментов его ремесла (хотя, следует признать, чертовски удобным и ухватистым инструментом).
У нас и масштабы другие.
Вы мыслите десятками (сотнями) хостов и сотнями (тысячами) VM`ок. У меня же точка приложения - SMB: в пределах десятка серверов (физических - в VI я могу позволить себе больше, ради рассредоточения сервисов) и сотни клиентов.
Соответственно, там где Вы оперируете блейдами и прочим "крупным калибром" с конским ценником на комплектующие, я обхожусь более скромным железом, вполне решающим мои задачи. И в рамках моих задач и бюджетов оснащение хостов локальными стораджами не влечёт за собою столь драматических (если вспомнить Вашу калькуляцию) расходов.
Ну а кроме того (как я уже неоднократно отмечал) не стОит педалировать тему локального стораджа _только_ в применении к свопингу: есть ещё пара моментов, в которых локальный сторадж хоста рулит. И это, кстати, вполне укладывается в мою личную парадигму "виртуализации в SMB"... :))
Вот как-то так...
С уважением,
Umlyaut.
>либо банальное отсутствие свободных слотов под память на имеющейся платформе.
ОтветитьУдалитьЕсть и такая проблема у меня с BL460c G1. Загрузка процессоров (2*5365) около 10% при загрузке 32ГБ памяти около 80%, а память ставить банально некуда.
>И в рамках моих задач и бюджетов оснащение хостов локальными стораджами не влечёт за собою столь драматических (если вспомнить Вашу калькуляцию) расходов.
В конечном итоге речь именно о том, что никакие локальные диски под быстрый своп не заменят лишнюю планку памяти, чтобы своп не происходил вообще. А при ценах не небрэндовую память это тем более верно.
>есть ещё пара моментов, в которых локальный сторадж хоста рулит.
Есть. Но не при свопе, о чем и весь разговор.
Заманчиво, конечно, отказаться от локальных дисков, RAID-контроллеров и необходимости как-то их мониторить. Но, если AutoDeploy у нас Virtual Appliance, то есть ВМ, то как быть при полном выключении оборудования, скажем, аварии на подстанции? Придется оставлять один хост с локальными дисками, флэшкой или загрузкой по SAN, и жестко привязывать AutoDeploy к этому хосту?
ОтветитьУдалитьSkyrod7
все так.
ОтветитьУдалитьв больших инфраструктурах это все равно может себя окупить - когда есть ядро из тройки esx(i) сделанные по старинке (на них вся инфраструктура, включая AutoDeploy), и куча серверов загружающаяся так.
Грамотная статья по теме -http://vmpress.blogspot.com/2010/10/vmware-auto-deploy.html
ОтветитьУдалитьугу, видел, спасибо.
ОтветитьУдалить