Поклонники Hyper-V не сдаются и предлагают рассмотреть причины поглубже. James O’Neill в своем блоге написал ответ на статью “9 причин, из-за которых крупные предприятия не должны переключаться на Hyper-V“, пересказ который был опубликован на нашем сайте.
Итак, пересказ “Углубимся в те причины, которые против переключения на Hyper-V“:
- Живая миграция. Автор причин против, писал, что вы устанете ждать миграции 40 ВМ на другой хост, по причине миграции по одной ВМ. В реальности вы можете использовать простоя powershell-скрипт.
Get-ClusterNode -Name grommit-r2 | Get-ClusterGroup |
where-object { Get-ClusterResource -input $_ | where {$_.resourcetype -like “Virtual Machine*”}} |
Move-ClusterVirtualMachineRole -Node wallace-r2
- Широкая поддержка ОС. Если MS говорит, что система поддерживается, значит, в случае проблем будет выпущен ho-fix. И для этого заключены соглашения с Novell по Suse Linux и Red Hat по RHEL. А VMware говорит, что поддерживается, если система запускается в виртуальной среде. Вы можете запустить NT4 в Hyper-V, но hot-fix не будет. Так что мы имеем разночтение понятия.
- Безопасность. Уязвимостей в гипервизоре VMware больше, чем в Hyper-V, смотрите бюллетени. Так что зависимость “обратно пропорциональна” размеру кода.
- Memory over-commit, share memory pages. Сам VMware советует не использовать данный механизм для большей производительности. Вы не можете предсказать какой кусок памяти понадобится и получите затыки по производительно. Для операционных систем Vista, Win7, Server 2008/2008-R2, больших данных в оперативной памяти ВМ, набора гетерогенных ОС технология общих страниц не применима либо неэффективна. Лозунг дня “Screw the budget, Screw the workload. Keep the memory constant !” (Типа, “Что хотите делайте с бюджетом и нагрузкой, но память не трогайте!”). Купить память стоит дешевле лицензий VMware.
- Горячее добавление памяти. Hyper-V может диск на лету подключить. Не все операционные системы могут на лету добавить память, зачем платить за VMware?
- Приоритеты рестарта ВМ. Напишите скрипты, сделайте задержки на загрузку сервисов.
- Непрерывная отказоустойчивость. VMware имеет кучу ограничей, Hyper-V позволяет делать тоже самое с помощью продуктов третьих фирм. Но вы все равно патчи не сможете внутрь ВМ ставить, так что зачем вам оно, приложениям-то все равно не поможет?
- Зрелость. Зрелость VMware не спасла он наступания их на грабли:… (перечислено пара граблей, я бы смог привести больше).
- Поддержка третьих сторон. На мероприятии у нашего стенда народу было больше. Потому что при притащили 3 ноута, где запустили System Center и Hyper-V (VMware видать не смогли).
1. “Просто и интуитивного понятно”. Unix и Windows меняются местами? Теперь вместо графического интерфейса поклонники MS предлагают Unix-way, курить конфиги и командную строку.
Все бы ничего, но миграция все равно будет осуществляться по одной машине, каждый хост Hyper-V может участвовать лишь в одном процессе Live Migration.
2. И… и ничего. Просто увод темы в сторону. Да, будет выпущен, наверное. Но то, как они поддерживаются сейчас, даже сертифицированные SLES / RHEL – это повод стыдливо помолчать в уголочке, а не хвастаться хотфиксами.
3. Больше функций, больше багов… Обычная ситуация. Но не стоит забывать, что из Hyper-V исключают стандартные баги Windows, без которой он не работает. Так что есть ложь, наглая ложь и статистика.
4. “Вам не нужна функциональность, которой нет у нас”.
5. Зачем тогда горячее добавление памяти в Windows 2003 и 2008? Подробнее о горячих дисках в Hyper-V тут – http://blog.vadmin.ru/2009/11/esx-vs-hyper-v.html
6. Зачем тогда вообще нужен Hyper-V, если все надо скриптовать для _базовой_ функциональности? Почему бы тогда сразу не взять Ubuntu и скриптовать сколько влезет?
7. Строго говоря, перевод иной: “если ВМ упадет в BSOD, то упадет она в обеих копиях, зачем тогда вам вообще FT”.
Затем, что FT защищает не от BSOD в гостевой, а от смерти хоста. И основное применение FT – как раз защита сервисов, не поддерживающих кластеризацию на уровне приложений.
Так что налицо ярчайшая подмена понятий и увод в сторону.
9. Аргумент вообще прекрасен, даже без комментариев.
+100
1. Итак, ситуация – мне надо погасить корзину, там глючит KVM, т.е. несколько десятков ВМ надо мигрировать. Предлагаете писать скрипт???
2. Это как осетрина второй свежести – либо, либо. Какие фиксы, что так и писать скрипты, мигрировать и обновляться???
3. Чья бы корова мычала!!! Сравните уязвимости по степени критичности. Поднимите руки кто уверен, что Hyper-V без антивируса и файрвола можно выпустить в интернет???
4. А вы ее пробовали? Вы VDI запускать не планировали? Что каждому юзверю по 2ГБ аллоцируем на 1000 пользователй например?
5. У вас не было случая когда память потекла, а перегрузиться нет возможности? У меня 1С и такое каждый раз после бух. отчетности.
6. Еще помимо админа на виртуализацию брать программиста. А как насчет ROI, TCO и прочее???
7. Не забываем про генерацию прибыли! Партнеров не обидим. Оригинально.
8. Старый конь борозды не портит, но и не пашет! Зрелость не продукта, а команд разработчиков, опыт называется.
9. Публика падка на дармовые развлечения, а цирк уродов во все времена пользовался успехом.
По-моему, мы все повторяемся. Давайте подождем обновлений и там и там и будем делать выводы. Пока, рано.
В продолжение темы Memory Overcommitment.
Контроллеры домена 2008 R2, в одиночку на разных хостах.
1 vCPU, 1024 MB RAM – 160MB и 350MB shared. Это значит, что технология Transparent Page sharing полностью компенсировала оверхед и еще чуть-чуть освободила память. Это плохо?
Виртуальный десктоп Windows 7, 4 машины для админов. Все машины на одном хосте, что, разумеется, повышает объем shared памяти.
2 vCPU 2 GB – 800 MB shared
2 vCPU 3 GB – 1900 MB shared
1 vCPU 2 GB – 430 MB shared
1 vCPU 1.5 GB – 970 MB shared
Кто там говорил, что TSP не имеет смыслы для Windows 2008 R2 / Windows 7?
ESXi 3.5 4u
куча линусков и freebsd и одна винда
SQL сервер для 1С – выданно 1.6 гига из них 700 shared (иногда чуть больше-чуть меньше)
Пожалуй и я вставлю пять копеек 🙂
Есть сервер с 12Гб памяти. На нем крутится несколько win2k3 машинок различной направленности (всус, скл, шарепоинт и т.п.).
ESXTOP показывает по памяти – занятой ~ 8Gb, shared ~ 4 Gb, swp – 0.
Антон,
я вот сижу и пытаюсь вкурить – из четырех w7 с кем самая большая 1900МБ может шарить?
Посмотри, плз, а сколько памяти использвовано внутр ОС, те с помощью taskmanager?
Чтобы не влудить здесь – моегм уйти в почту…
ЗЫЖ Hyper-V рулит, когда рядом нету esx и xs.
Денис, довольно затруднительно посмотреть внутри машины – чужая она. Но уверен, что память загружена несильно.
На хосте, где они все живут, такая статистика:
Shared Common 2.13 GB
Shared 9.64 GB
Granted 28.5 GB
Consumed 21.5 GB
Active 5.01 GB
Всего физической 32GB, vCenter рапортует Memory Usage 20965 MB
Сдается мне, так как балунинг не работает, то TPS пустую память шарит… 😉
Я как бы про TPS и говорил, Balloon = 0