Pull to refresh

Comments 15

Главный вопрос — зачем это нужно? Почему сразу не использовать загрузку из SAN или у Hyper-V есть с этим проблемы?
Простой вопрос: SAN сама настроится на новом сервере? «Вот только что вынутом из коробки»?
Хм, в vSphere и правда нет инструментов для управления через BMC, так что придётся подготавливать серверы через SIM или Systems Director, либо грузиться по сети через Auto Deploy.
Ну и ещё одно: если это просто Hyper-V Server (не Windows Server с ролью Hyper-V), то расходовать на него SAN просто бессмысленно. У меня вот под рукой есть два, проверил: на харде занято ~20Gb из них 16Gb — pagefile.sys, т.к. я его не трогал, т.к. стоит на диске в 250GB. Так что рабочая система влезает 8Gb флешку/DOM, и никаких требований по отказоустойчивости (там и так 95% времени только чтение, 5% записи — локальные логи и обновления раз в квартал). Расходовать на эти задачи SAN — дорого, как с точки зрения $/Gb (а SAN, как мы прекрасно знаем не дёшевы), так и с точки зрения банального административного ресурса.
Для хранилища с дедупликацией эта не проблема, но мелкого образа (как у VMware) все же не хватает.
UFO just landed and posted this here
Если уже есть FC-инфраструктура, то ничего не понадобится — по одному шлангу можно грузиться и шарить лун для датастора :)
Административные расходы (в связи с усложнением схем коммутации, обслуживанием СХД для этих серверов и т.п.) меряются в человеко\часах (в том числе и при DR), и в большинстве случаев не имеют смысла для голых гипервизоров. Ну а мелкий образ ценен разве что для загрузки по PXE, в остальном — какая разница, поставился сервер за 1 минуту или за 3, физическая установка займёт больше времени.
Настраивать её всё равно придётся, но да — надо делать лун и зону для каждого хоста (+ может понадобиться покупка лицензий на это дело).

Идеальная архитектура мне видится в виде единого образа для всех хостов, усправления железками по IPMI и раздачи настроек с сервера череp host profiles (с отбором по MAC, WWN или ещё как) и скидывании логов на сервер мониторинга. Сами серверы будут выступать в роли тонких клиентов.
Ну, собственно говоря, VMM именно этим и занимается. =)
Про уменьшенный образ гипервизора они (MSFT) сами упоминали, впрочем, как и про установку обновлений без перезагрузки перед выходом 2008 R2.
Вы, наверно, имеете ввиду тот самый Hyper-V Server. По сравнению с полным Windows Server, что в Full, что в Core варианте он существенно меньше, как installation media, так и footprint на диске, плюс меньшее количество служб => меньший профиль обновления.
Не совсем, очень надеюсь на совсем маленький дистрибутив в Hyper-V 3.0 (в несколько сот мегабайт), потому что даже у RH такая штука уже есть.
Ну и чтобы два раза не вставать: на SAN откуда возьмётся образ ОС с нужными настройками, в т.ч. введнный в домен?
VMM2012 позволяет управлять всей инфраструктурой частного облака из одной консоли. Начиная с сервера только что вылезшего из коробки и заканчивая сервисами предоставляемыми конечному пользователю.
Насколько востребованным будет Bare Metal Deployment через VMM покажет время.
Sign up to leave a comment.