IT служба Microsoft разработала стандарт, определяющий, какие именно машины подлежат виртуализации. Под него подпало большое количество лабораторных и development серверов с очень низкой загрузкой и требованиями. Для хостинга данных серверов используются 4-сокетные серверы с 16 и 24 ядрами и 64ГБ памяти, что дает возможность запуска большого количества виртуальных машин (ВМ) со средним соотношением 10.4 ВМ на хост.
Представьте себе, сервер с 16 ядрами и более 32ГБ памяти тянет только 10.4 "лабораторных машины с очень низкой загрузкой". А теперь представьте сколько "боевых" машин с рабочей нагрузкой смогут там работать.
Для рабочих машин Microsoft IT использует 2-сокетные серверы с 8 или 12 ядрами и 32ГБ памяти.
...
В среднем, хост-серверы с 8 процессорами и 32ГБ памяти хостят 5.7 ВМ на хост.
Меньше 6 машин на 8-процессорную железку с 32ГБ!
Затем они переходят к обалденной "высокой доступности". Убедитесь, что вы крепко сидите, и вообще находитесь в каком-нибудь неофициальном месте типа своего дома, дверь в ванную открыта и скорая на подходе. Потому что очень вероятно, что вы просто обмочите себе штаны и развалитесь напополам со смеху, когда прочитаете эти жемчужины мудрости:
При использовании Windows Server 2008 failover clustering необходимо хранить каждую ВМ на отдельном LUN. Поскольку администратор должен предоставить доступ к каждому разделяемому хранилищу под той же буквой, то в failover cluster может работать максимум 23 машины. Microsoft IT может обойти данное ограничение, используя точки монтирования и группы виртуальных машин, но было сочтено, что в данной конфигурации администрирование станет слишком сложным. Из-за этого ограничения Microsoft IT приняла в качестве стандарта использование кластеров из 3-х узлов, сконфигурированных так, чтобы выдерживать отказ 1 узла.
Я даже не знаю что сказать. Из-за своего дурацкого дизайна (точнее двух сразу, с использованием букв, и 1 ВМ на LUN), они расходуют впустую огромное количество процессорной мощности и памяти.
А теперь вставьте выпавшую на предыдущем абзаце челюсть и крепко ее держите:
При миграции машины в Windows Server 2008 failover cluster сервисы должны сохранить состояние ВМ, передать контроль над разделяемым хранилищем другому узлу и перезапустить ВМ из сохраненного состояния. Несмотря на то, что процесс занимает всего несколько секунду, ВМ остается в этот промежуток времени недоступной. Если же администратору необходимо перезагрузить все хосты в кластере (например, при установки обновлений безопасности), ВМ в кластере придется мигрировать несколько раз, и соотв. каждый раз ВМ будут недоступны. Таким образом Microsoft IT определила, что виртуальные машины высокой доступности могут иметь большее время недоступности, чем виртуальные машины на одиночных серверах, в случаях простых запланированных простоев, таких как установка обновлений ПО.
Кажется, кабина разгерметизировалась. Виртуальные машины "высокой доступности", размещенные в кластере, могут иметь большее время недоступности, чем обычные, на одиночных хостах.
Теперь мы знаем, зачем Microsoft выпускает эти дурацкие маркетинговые видеоролики - чтобы отвлечь внимание от неприятной действительности, которую они знают сами слишком хорошо.
Общий смысл статьи очевиден. Все расчеты стоимости можно выкинуть в помойку, теорию и коэффициенты консолидации тоже. Сравнения производительности к черту. О сравнении эффективности датацентров можно даже и не задумываться. В свете холодных и бездушных фактов маркетинговые ходы для VMware не нужны. С Microsoft, рождающей подобные документы и выставляющей их в публичный доступ, VMware просто не нужен никакой маркетинг. Заранее прошу прощения за то, что ставлю под вопрос рабочие места 90% отдела маркетинга VMware. Пожалуйста, в любом случае оставьте Джона Тройера (John Troyer), ему придется восстанавливать сообщество после того, как мы все помрем со смеху.
Оригинальная статья Microsoft: http://technet.microsoft.com/en-us/library/cc974012.aspx
Пост Stu: http://vinternals.com/2009/04/microsoft-myths-and-realities
Сообщения
Антон,
ОтветитьУдалитьа когда появится "версия для печати"? А то у меня такой уж шрифт тут мелкий, читать сложно.
Увы, в данном случае ничего не могу поделать. Это стандартный шаблон blogger.com.
ОтветитьУдалитьА как-то шрифт поболее сделать? У меня в нескольких браузерах он очень мелкий... конечно я могу руками каждую заметку увеличивать, но очень уж это неудобно.
ОтветитьУдалитьICQ 51009767 - давайте обсудим как оно.
ОтветитьУдалитьCtrl + колесико работает, по моему, во всех браузерах.
ОтветитьУдалитьоткровенно говоря непонятно откуда столько негатива к МС.
ОтветитьУдалитьС точки зрения продаж и маркетинга можно сколько угодно смеяться над Майкросом, но сравнивать Vmware даже вместе с EMC против MS просто бессмыслено. В этом мире кроме техники есть еще и бизнес. Огромное количество компаний МС уже обошел на поворотах и я думаю еще обойдет.
Я понимаю Ваше злорадство по поводу того, что МС сначала выпускает такую статью, а потом Вы находите технический материал показывающий все недостатки решения. НО по существу кроме отдельной группы инженеров выше среднего, на это никто внимание не обратит. В то время как МС направлен на масс рынок. Этот рынок можно нелюбить, но игнорировать его нельзя.
Да, и не забывайте пожалуйста, что при всех словах маркетологов из МС, приоритетный рынок для них - десктопы. А все остальное, по существу, дополнительный заработок
Уважаемый комментатор, насчет злорадства Вы адресом ошибаетесь. Я статью перевел, хоть и сократив, но по возможности близко к оригиналу.
ОтветитьУдалитьМоя позиция относительно всей этой ситуации такова. Hyper-V имеет место быть, первая версия продукта со всеми вытекающими вроде малого количества функций. Объективно сейчас Hyper-V находится на уровне ESX несколько лет назад, но за ним стоит Microsoft, имеющая тысячи инженеров и миллиарды долларов.
Hyper-V в целом неплохой продукт, весьма интересный для сектора SMB, но для Enterprise он не дотягивает. Позор маркетингу MS за откровенную ложь и смену позиций в стиле флюгера. Определенные выводы относительно собственной IT службы Microsoft мы все тоже сделали.
Вот, собственно, и все. Мы-то, в конце концов, инженеры, а не маркетологи.
не покидает ощущение, что Stu несколько туповат...
ОтветитьУдалитьнаверное слишком молод и вырос на Бивисе и Батхеде
в тексте Микрософта - напротив, ничего смешного не нашёл, фактически всё сводится к одной схеме - "мы пробовали и так и сяк и по-разному, а остановились именно на такой схеме, потому что нам так показалось удобнее и экономичнее"
мы, если что, смеемся над тем, что
ОтветитьУдалитьодной рукой МС пишет маркетинговые материалы, поднимающие свои и опускающие чужие продукты - тот самый видеоролик просто концентрированный пример.
а другой рукой пишутся технические документы, из которых следует откровенная слабость своего продукта.
Антон,
ОтветитьУдалитьк сожалению опять мне придется защищать MS.
Вы не учитываете одну важную деталь - майкрософт обладает одним из самых крупных парков серверов.
И страдают стандартной болезнью больших корпораций - пока все сервера обновишь, те с которых начали уже устарели.
У них нет оверкоммитмента - и на сервере с 32 ГБ памяти может работать всего с семью ВМ с 4Гб. Но для многих серверов они выделяют - 8Гб и больше... А теперь представьте, что будет стоить поменять(именно заменить, поскольку они уперлись в физическое ограничение по слотам) память на 200 серверах... А что делать с оставшимися планками?
Кстати под лабораторными серверами понимаются не только то что принято считать у нас... В частности это сервера для тестирования сырых сборок продуктов - не оптимизированных для нормальной производительности.
As Microsoft IT developed standards for which physical machines to virtualize, it identified many lab and development servers with very low utilization and availability requirements.
ОтветитьУдалитьПодразумевается - ресурсы железа используются мало. Но при этом вы же не знаете какое железо у них стоит.
Детский сад.
А видимо оно не слабое, раз на сервере с 24 ядрами и 64 гигами озу они могут запустить только 10 виртуалок. У меня их работает 6 на сервере с 2 ядрами и 8 гигами ОЗУ.
ОтветитьУдалитьЧитайте первоисточник. И учите английский. И мозг включайте.
Про то, почему выбрана схема 1 LUN - 1 ВМ мне просто лень переводить - умный прочитает и поймет, а вы выдрали вторую часть из контекста.
ОтветитьУдалитьВ кратце - сначала была схема 1 LUN - несколько ВМ.
Почему отказались, с какими проблемами столкнулись при такой конфигурации - читайте в статье.
Ну если лень переводить, то может и вовсе комментарий писать не стоило? А то вся информация, что мы почерпнули, заключается в "Некоему анонимному читателю лень переводить, а все вокрг читать не умеют".
ОтветитьУдалитьДа товарищ автор у тебя у самого видать большие проблемы с пониманием написаного на инглише, если ты ТАК напереводил... Хотя для прыщавого красноглазика пойдет.
ОтветитьУдалитьЕще один кусочек специально для тебя переведу, мегачтец.
ОтветитьУдалитьВ качестве аппаратной платформы были выбраны blade-сервера с двумя гигабитными сетевыми интерфейсами на борут.
В статье написано, что это так же (а мое мнение что именно это в первую очередь) повлияло на определение числа виртуальных машин, работающих на одном сервере. 10-11 машин на гигабитный интерфейс это пожалуй максимум, который можно позволить (второй интерфейс используется для управления родительской ОС). Еще вопросы будут, или все же попробуешь почитать первоисточник?
Несмотря на хамство, отвечу, поскольку мегачтец здесь товарищ анонимный, так и не дочитавший, что оба интерфейса использовались для балансировки нагрузки. Как для трафика виртуальных машин, так и для управляющего.
ОтветитьУдалить"it configures both network adapters so that both Hyper-V management and guest networks can use them. Microsoft IT then configures a virtual network for each of the network adapters to provide load balancing of guest network traffic between the two virtual networks."
С другой стороны никто не мешал достичь больших коэффициентов консолидации с использованием более двух сетевых портов. Очевидно, что стоимость дополнительной сетевой карты несколько меньше стоимости еще одного блейда. И более того, следующим же абзацем говорится, что для виртуальных машин, требовательных к сети, Microsоft устанавливает на хосты дополнительные адаптеры, хотя в большинстве случаев этого не требуется.