Недавно разговор заходил о том, какую скорость выдает ESXi виртуальным машинам.
Итак, две физические машины SUN x4150, 4x SAS HDD RAID5. Distributed vSwitch с 1 аплинком, 82571EB. ESXi Installable 4.0RC build 140815.
На каждом сервере по одной машине с Xtravirt Virtual SAN, с одной сетевой картой VMXNET3 и thick диском 256GB. Запущена первичная синхронизация дисков. Средняя скорость сети согласно показаниям самих машин 78 500 KB/sec, показания загрузки канала в vCenter для хоста колеблются от 78 200 до 83 200 KB/sec.
четверг, 9 апреля 2009 г.
среда, 8 апреля 2009 г.
Мифы и реальность Microsoft
Stu (vinternals.com) нашел очень интересный документ, опубликованный самой Microsoft, описывающий достижения Microsoft по консолидации серверов на платформе Hyper-V. Только холодные и бездушные цифры. Сама статья и пост Stu на английском, поэтому перевод мой (в сокращенном виде).
Представьте себе, сервер с 16 ядрами и более 32ГБ памяти тянет только 10.4 "лабораторных машины с очень низкой загрузкой". А теперь представьте сколько "боевых" машин с рабочей нагрузкой смогут там работать.
Меньше 6 машин на 8-процессорную железку с 32ГБ!
Затем они переходят к обалденной "высокой доступности". Убедитесь, что вы крепко сидите, и вообще находитесь в каком-нибудь неофициальном месте типа своего дома, дверь в ванную открыта и скорая на подходе. Потому что очень вероятно, что вы просто обмочите себе штаны и развалитесь напополам со смеху, когда прочитаете эти жемчужины мудрости:
Я даже не знаю что сказать. Из-за своего дурацкого дизайна (точнее двух сразу, с использованием букв, и 1 ВМ на LUN), они расходуют впустую огромное количество процессорной мощности и памяти.
А теперь вставьте выпавшую на предыдущем абзаце челюсть и крепко ее держите:
Кажется, кабина разгерметизировалась. Виртуальные машины "высокой доступности", размещенные в кластере, могут иметь большее время недоступности, чем обычные, на одиночных хостах.
Теперь мы знаем, зачем 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
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
VMware vSphere
Собрал небольшой стенд с VMware vSphere RC. Сколько же там всего вкусного!
Жаль, что до 21 апреля я связан NDA и не могу рассказать.
Ну все, интригу создал :)
Жаль, что до 21 апреля я связан NDA и не могу рассказать.
Ну все, интригу создал :)
понедельник, 6 апреля 2009 г.
10 "мифов" от VMware развенчаны Microsoft
Gabrie van Zanten написал очень развернутый комментарий на "развенчание 10 мифов". В меру сил перевел "разбор полетов" на русский язык.
***
Сегодня посмотрел видеоролик, выпущенный Microsoft якобы для "развенчания мифов" о VMware ESX. Разозлился - почему нельзя просто играть честно? Я считаю, что Hyper-V достаточно хорош для версии 1.0, но все эти маркетинговые кампании, уверяющие нас, что он уже достаточно стабилен и "взросл"... Почему нельзя признать, что Hyper-V 1.0 не конкурент ни Xen, ни ESX и просто рассказать про новую функциональность R2?
В видеоролике они собираются развенчать 10 мифов, 10 пунктов, в которых VMware некорректно сравнивает ESX и Hyper-V. При этом сами "развенчания" весьма некорректны. Итак, мой список:
1) У Microsoft нет Live Migration
Согласно двум джентльменам в видеоролике у Microsoft есть Live Migration: "В Windows 2008 R2, которая очень скоро выйдет, есть Live Migration". Точно!!! В R2 есть Live Migration, которая работает так же, как и VMware VMotion. Миф развенчан!!!
Хотя нет, погодите. Windows 2008 R2 все еще в бете, и пока нет официальной даты выхода. Последний раз я что-то слышал про начало 2010, но до него еще 8 месяцев. Так что на сегодня (Апрель 2009) Hyper-V не поддерживает Live Migration.
2) Кластерная файловая система
И снова джентльмены говорят о Windows 2008 R2. И снова правильным ответом был бы: "Нет, в Hyper-V 1.0 нет такой функциональности, но она будет в R2". Вместо этого миф снова, по их утверждению, "развенчан".
3) Hyper-V - продукт версии 1.0
Джентльмены ссылаются на VMware, которая утверждает, что Hyper-V - продукт версии 1.0, а следовательно, недостаточно масштабируем, недостаточно "взросл" и недостаточно быстр. В противовес приводится 4500 виртуальных машин, работающих под управлением Hyper-V в датацентрах Microsoft. Позвольте, но это ровным счетом ничего не говорит о масштабируемости, стабильности и надежности. Если у вас все системы 1-к-1 (одна ВМ на один хост), то у вас точно так же целых 4500 машин, и наверняка они работают весьма стабильно. Нет, я, конечно, не верю, что у Microsoft все эти машины работают 1-к-1, но никаких подтверждений стабильности и масштабируемости я тоже не вижу. Если хотите действительно развенчать миф, то приведите аргументы получше.
4) Низкая производительность
Должен признать, что производительность Hyper-V выглядит куда лучше, чем я ожидал. Но вот проблема: во всех этих тестах слишком мало деталей "что" и "как". Пожалуйста, кто-нибудь, покажите мне хороший проработанный отчет о тесте, который я могу собственноручно воспроизвести в собственной лаборатории, и который охватывает три главных гипервизора на сегодня - ESX, Hyper-V и Xen.
5) "Отпечаток"
А так ли велика разница в размере "отпечатка", и вдобавок поднимается вопрос "а так ли это вообще важно?"
Должен с ними согласиться. Если вы собираетесь установить ESX или Hyper-V на диск, то не так уж и важно, сколько занимает места гипервизор или ОС с гипервизором, 2 ГБ или 10. Сегодня самый маленький доступный на рынке диск имеет размер 36ГБ, и только если очень поискать, то можно найти 18. К тому же вы в большинстве случаев можете считать этот диск "потерянным", на нем не будут размещаться виртуальные машины.
Но совсем другой вопрос, разумеется, про бездисковые серверы и загрузке с USB Flash. Здесь размер действительно играет большое значение.
Отпечаток в оперативной памяти, на мой взгляд, не имеет решающего значения. По умолчанию ESX использует 272МБ для загрузки ядра, сервис-консоли и агентов управления. Тем не менее, большинство администраторов устанавливают резерв памяти для консоли на уровне 800МБ. Windows 2008 Server Core с установленным Hyper-V будет занимать примерно столько же.
Самый большой вопрос: а миф ли это вообще? Есть ли конечным пользователям какое-то дело до этого?
6) Широкая поддержка оборудования
Джентльмены показывают скриншот сайта VMware и говорят, что VMware сравнивает HCL (список поддерживаемого оборудования) с Citrix и VirtualIron, но не с Hyper-V HCL. Чисто формально они право, однако если взглянуть поближе, то VMware дает комментарий: "Microsoft заявляет об очень широком HCL потому что в Hyper-V используются драйверы для Windows 2008. Однако драйверы всегда были повинны в большой доле проблем со стабильностью Windows." Я предлагаю джентльменам возразить на данное замечание вместо утверждения, что Hyper-V может работать на любом оборудовании.
Еще один момент, который следует прояснить - большинство драйверов сторонних вендоров не были оптимизированы для Hyper-V и не были оптимизированы для высокой производительности. Я припоминаю некоторые сетевые адаптеры, к которым шли драйверы размером 45 МБ со всеми модными функциями, о которых я никогда не просил, и которые явно не добавляли системе стабильности. Вдобавок, список сетевых адаптеров, которые вы можете использовать, если хотите иметь поддержку транков, VLAN'ов и автоматического переключения линков при отказах, весьма невелик. Что в конечном итоге ведет нас к еще более короткому списку оборудования, действительно совместимого с Hyper-V.
7) Управление
Они утверждают: "В VMware говорят лишь о Virtual Machine Manager, они (VMware) не говорят о полном Systems Center". В данном случае джентльмены хотят сказать, что следует сравнивать vCenter не с System Center Virtual Machine Manager, а с полным Systems Center. Довольно сложно понять к чему это вообще, и к тому же я не уверен, что в VMware что-то вообще утверждали по данному вопросу.
8) Memory Overcommit
Утверждение джентльменов в том, что memory overcommit (MO) полезно лишь в очень редких случаях, и они ни разу не видели соотношение 2 к 1, о котором говорит VMware. Если вы хотите действительно техническую дискуссию, то они правы, что MO не дает соотношение 2 к 1. Но что они забыли упомянуть, так то, что MO лишь одна часть из технологий экономии памяти, а наибольший эффект достигается технологией "Transparent Page Sharing" (TSP). Эти две технологии, работающие вместе, могут давать соотношение 2 к 1 и даже более (у некоторых моих заказчиков).
Следующий пункт. Если вы тщательно мониторите свои виртуальные машины и выдаете им ровно необходимое количество памяти, то MO вам не нужно. Честно, я никогда не даю виртуальной машине 893МБ памяти. Скорее всего, это будет 1ГБ или даже 1,5ГБ, чтобы не попасть в процесс свопирования при внезапном пике нагрузки. Если же у вас на хосте работает 50-60 ВМ, то вы явно некоторое немаленькое количество памяти расходовали бы впустую, если бы не MO. Вдобавок, это экономит мне немало времени, которое пришлось бы потратить на мониторинг сколько памяти требуется виртуальной машине, 893МБ, 900МБ или может быть 1150МБ.
9) Более низкая цена из расчета на одну ВМ
Всегда сложные расчеты цены на одну ВМ. Все эти расчеты стоимости решения виртуализации полностью зависят от того, сколько виртуальных машин и приложений вы собираетесь запускать в конечном итоге, сколько физических хостов и сколько лицензий вам для этого потребуется. Если продукт А дороже, но позволяет запускать вдвое больше виртуальных машин на хост и соотв. требуется меньше лицензий на продукт А, в конечном итоге может оказаться дешевле, чем купить большее количество лицензий дешевого продукта В.
Как уже было рассмотрено в п. 8, технологии Memory Overcommit работают и позволяют экономить память, а в конечном итоге уменьшить количество требуемых хостов.
Во второй части "развенчания" мифа номер 9, они говорят о том, что VMware требуется более высокий коэффициент консолидации, чтобы приблизиться к Hyper-V по цене. Хм, но что в этом плохого? Разве виртуализация не была в большой своей части консолидацией? И как я уже говорил, если более высокая консолидация позволяет покупать меньше хостов и лицензий, то что же в этом плохого?
Тем не менее, я считаю, что крайне тяжело сравнивать цены между двумя гипервизорами, поскольку много зависит от коэффициента консолидации, который в свою очередь полностью зависит от количества и вида приложений, работающих в вашем датацентре.
10) Вам нужна виртуализация VMware
Это начинает уже раздражать... Первое утверждение джентльменов касается уровней Hyper-V, в сравнении с VMware ESX. Джентльмен слева говорит: "В случае с VMware вам приходится иметь дело с 4 уровнями - железом, уровень VMware, уровень ОС, уровень приложений. С нашим решением (Hyper-V), уровня всего 3. Железо, ОС и приложения". Прошу прощения! В Hyper-V у вас ровно столько же уровней, как и в ESX, с одной лишь разницей - какие именно компоненты на каком уровне. К счастью, не все в Microsoft так плохо информированы, см. http://technet.microsoft.com/en-us/magazine/2008.10.hyperv.aspx, рисунок 2. Ошибочные утверждения в данном случае превращают само развенчание мифа в миф.
***
Сегодня посмотрел видеоролик, выпущенный Microsoft якобы для "развенчания мифов" о VMware ESX. Разозлился - почему нельзя просто играть честно? Я считаю, что Hyper-V достаточно хорош для версии 1.0, но все эти маркетинговые кампании, уверяющие нас, что он уже достаточно стабилен и "взросл"... Почему нельзя признать, что Hyper-V 1.0 не конкурент ни Xen, ни ESX и просто рассказать про новую функциональность R2?
В видеоролике они собираются развенчать 10 мифов, 10 пунктов, в которых VMware некорректно сравнивает ESX и Hyper-V. При этом сами "развенчания" весьма некорректны. Итак, мой список:
1) У Microsoft нет Live Migration
Согласно двум джентльменам в видеоролике у Microsoft есть Live Migration: "В Windows 2008 R2, которая очень скоро выйдет, есть Live Migration". Точно!!! В R2 есть Live Migration, которая работает так же, как и VMware VMotion. Миф развенчан!!!
Хотя нет, погодите. Windows 2008 R2 все еще в бете, и пока нет официальной даты выхода. Последний раз я что-то слышал про начало 2010, но до него еще 8 месяцев. Так что на сегодня (Апрель 2009) Hyper-V не поддерживает Live Migration.
2) Кластерная файловая система
И снова джентльмены говорят о Windows 2008 R2. И снова правильным ответом был бы: "Нет, в Hyper-V 1.0 нет такой функциональности, но она будет в R2". Вместо этого миф снова, по их утверждению, "развенчан".
3) Hyper-V - продукт версии 1.0
Джентльмены ссылаются на VMware, которая утверждает, что Hyper-V - продукт версии 1.0, а следовательно, недостаточно масштабируем, недостаточно "взросл" и недостаточно быстр. В противовес приводится 4500 виртуальных машин, работающих под управлением Hyper-V в датацентрах Microsoft. Позвольте, но это ровным счетом ничего не говорит о масштабируемости, стабильности и надежности. Если у вас все системы 1-к-1 (одна ВМ на один хост), то у вас точно так же целых 4500 машин, и наверняка они работают весьма стабильно. Нет, я, конечно, не верю, что у Microsoft все эти машины работают 1-к-1, но никаких подтверждений стабильности и масштабируемости я тоже не вижу. Если хотите действительно развенчать миф, то приведите аргументы получше.
4) Низкая производительность
Должен признать, что производительность Hyper-V выглядит куда лучше, чем я ожидал. Но вот проблема: во всех этих тестах слишком мало деталей "что" и "как". Пожалуйста, кто-нибудь, покажите мне хороший проработанный отчет о тесте, который я могу собственноручно воспроизвести в собственной лаборатории, и который охватывает три главных гипервизора на сегодня - ESX, Hyper-V и Xen.
5) "Отпечаток"
А так ли велика разница в размере "отпечатка", и вдобавок поднимается вопрос "а так ли это вообще важно?"
Должен с ними согласиться. Если вы собираетесь установить ESX или Hyper-V на диск, то не так уж и важно, сколько занимает места гипервизор или ОС с гипервизором, 2 ГБ или 10. Сегодня самый маленький доступный на рынке диск имеет размер 36ГБ, и только если очень поискать, то можно найти 18. К тому же вы в большинстве случаев можете считать этот диск "потерянным", на нем не будут размещаться виртуальные машины.
Но совсем другой вопрос, разумеется, про бездисковые серверы и загрузке с USB Flash. Здесь размер действительно играет большое значение.
Отпечаток в оперативной памяти, на мой взгляд, не имеет решающего значения. По умолчанию ESX использует 272МБ для загрузки ядра, сервис-консоли и агентов управления. Тем не менее, большинство администраторов устанавливают резерв памяти для консоли на уровне 800МБ. Windows 2008 Server Core с установленным Hyper-V будет занимать примерно столько же.
Самый большой вопрос: а миф ли это вообще? Есть ли конечным пользователям какое-то дело до этого?
6) Широкая поддержка оборудования
Джентльмены показывают скриншот сайта VMware и говорят, что VMware сравнивает HCL (список поддерживаемого оборудования) с Citrix и VirtualIron, но не с Hyper-V HCL. Чисто формально они право, однако если взглянуть поближе, то VMware дает комментарий: "Microsoft заявляет об очень широком HCL потому что в Hyper-V используются драйверы для Windows 2008. Однако драйверы всегда были повинны в большой доле проблем со стабильностью Windows." Я предлагаю джентльменам возразить на данное замечание вместо утверждения, что Hyper-V может работать на любом оборудовании.
Еще один момент, который следует прояснить - большинство драйверов сторонних вендоров не были оптимизированы для Hyper-V и не были оптимизированы для высокой производительности. Я припоминаю некоторые сетевые адаптеры, к которым шли драйверы размером 45 МБ со всеми модными функциями, о которых я никогда не просил, и которые явно не добавляли системе стабильности. Вдобавок, список сетевых адаптеров, которые вы можете использовать, если хотите иметь поддержку транков, VLAN'ов и автоматического переключения линков при отказах, весьма невелик. Что в конечном итоге ведет нас к еще более короткому списку оборудования, действительно совместимого с Hyper-V.
7) Управление
Они утверждают: "В VMware говорят лишь о Virtual Machine Manager, они (VMware) не говорят о полном Systems Center". В данном случае джентльмены хотят сказать, что следует сравнивать vCenter не с System Center Virtual Machine Manager, а с полным Systems Center. Довольно сложно понять к чему это вообще, и к тому же я не уверен, что в VMware что-то вообще утверждали по данному вопросу.
8) Memory Overcommit
Утверждение джентльменов в том, что memory overcommit (MO) полезно лишь в очень редких случаях, и они ни разу не видели соотношение 2 к 1, о котором говорит VMware. Если вы хотите действительно техническую дискуссию, то они правы, что MO не дает соотношение 2 к 1. Но что они забыли упомянуть, так то, что MO лишь одна часть из технологий экономии памяти, а наибольший эффект достигается технологией "Transparent Page Sharing" (TSP). Эти две технологии, работающие вместе, могут давать соотношение 2 к 1 и даже более (у некоторых моих заказчиков).
Следующий пункт. Если вы тщательно мониторите свои виртуальные машины и выдаете им ровно необходимое количество памяти, то MO вам не нужно. Честно, я никогда не даю виртуальной машине 893МБ памяти. Скорее всего, это будет 1ГБ или даже 1,5ГБ, чтобы не попасть в процесс свопирования при внезапном пике нагрузки. Если же у вас на хосте работает 50-60 ВМ, то вы явно некоторое немаленькое количество памяти расходовали бы впустую, если бы не MO. Вдобавок, это экономит мне немало времени, которое пришлось бы потратить на мониторинг сколько памяти требуется виртуальной машине, 893МБ, 900МБ или может быть 1150МБ.
9) Более низкая цена из расчета на одну ВМ
Всегда сложные расчеты цены на одну ВМ. Все эти расчеты стоимости решения виртуализации полностью зависят от того, сколько виртуальных машин и приложений вы собираетесь запускать в конечном итоге, сколько физических хостов и сколько лицензий вам для этого потребуется. Если продукт А дороже, но позволяет запускать вдвое больше виртуальных машин на хост и соотв. требуется меньше лицензий на продукт А, в конечном итоге может оказаться дешевле, чем купить большее количество лицензий дешевого продукта В.
Как уже было рассмотрено в п. 8, технологии Memory Overcommit работают и позволяют экономить память, а в конечном итоге уменьшить количество требуемых хостов.
Во второй части "развенчания" мифа номер 9, они говорят о том, что VMware требуется более высокий коэффициент консолидации, чтобы приблизиться к Hyper-V по цене. Хм, но что в этом плохого? Разве виртуализация не была в большой своей части консолидацией? И как я уже говорил, если более высокая консолидация позволяет покупать меньше хостов и лицензий, то что же в этом плохого?
Тем не менее, я считаю, что крайне тяжело сравнивать цены между двумя гипервизорами, поскольку много зависит от коэффициента консолидации, который в свою очередь полностью зависит от количества и вида приложений, работающих в вашем датацентре.
10) Вам нужна виртуализация VMware
Это начинает уже раздражать... Первое утверждение джентльменов касается уровней Hyper-V, в сравнении с VMware ESX. Джентльмен слева говорит: "В случае с VMware вам приходится иметь дело с 4 уровнями - железом, уровень VMware, уровень ОС, уровень приложений. С нашим решением (Hyper-V), уровня всего 3. Железо, ОС и приложения". Прошу прощения! В Hyper-V у вас ровно столько же уровней, как и в ESX, с одной лишь разницей - какие именно компоненты на каком уровне. К счастью, не все в Microsoft так плохо информированы, см. http://technet.microsoft.com/en-us/magazine/2008.10.hyperv.aspx, рисунок 2. Ошибочные утверждения в данном случае превращают само развенчание мифа в миф.
среда, 1 апреля 2009 г.
ESX3.5 u4: пропал VMFS datastore
В некоторых случаях, как утверждают на форуме VMware, в основном если используются SATA контроллеры, может пропасть локальный VMFS datastore при обновлении до 3.5 u4.
В большинстве случаев пожет следующая программа действий
1. Откройте вкладку "Configuration" в VI Client
2. Advanced Settings
3. В разделе LVM, измените LVM.EnableResignature на 1 (по умолчанию 0)
4. Для локального контроллера сделайте "Rescan"
5. Он может появиться под иным "дружественным именем", но в остальном ничего не изменится.
6. Установите EnableResignature обратно в 0
7. Вручную добавьте VMX обратно в inventory.
В большинстве случаев пожет следующая программа действий
1. Откройте вкладку "Configuration" в VI Client
2. Advanced Settings
3. В разделе LVM, измените LVM.EnableResignature на 1 (по умолчанию 0)
4. Для локального контроллера сделайте "Rescan"
5. Он может появиться под иным "дружественным именем", но в остальном ничего не изменится.
6. Установите EnableResignature обратно в 0
7. Вручную добавьте VMX обратно в inventory.
вторник, 31 марта 2009 г.
ESX3.5 u4 released!
Вышел пакет обновлений u4 для ESX3.5.
Expanded Support for Enhanced vmxnet Adapter — This version of ESX Server includes an updated version of the VMXNET driver (VMXNET enhanced) for the following guest operating systems:
Microsoft Windows Server 2003, Standard Edition (32-bit)
Microsoft Windows Server 2003, Standard Edition (64-bit)
Microsoft Windows Server 2003, Web Edition
Microsoft Windows Small Business Server 2003
Microsoft Windows XP Professional (32-bit)
The new VMXNET version improves virtual machine networking performance and requires VMware tools upgrade.
Enablement of Intel Xeon Processor 5500 Series — Support for the Xeon processor 5500 series has been added. Support includes Enhanced VMotion capabilities. For additional information on previous processor families supported by Enhanced VMotion, see Enhanced VMotion Compatibility (EVC) processor support (KB 1003212).
QLogic Fibre Channel Adapter Driver Update — The driver and firmware for the QLogic fibre channel adapters have been updated to version 7.08-vm66 and 4.04.06 respectively. This release provides interoperability fixes for QLogic Management Tools for FC Adapters and enhanced NPIV support.
Emulex Fibre Channel Adapter Driver Update — The driver for Emulex Fibre Channel Adapters has been upgraded to version 7.4.0.40. This release provides support for the HBAnyware 4.0 Emulex management suite.
LSI megaraid_sas and mptscsi Storage Controller Driver Update — The drivers for LSI megaraid_sas and mptscsi storage controllers have been updated to version 3.19vmw and 2.6.48.18 vmw respectively. The upgrade improves performance and enhance event handling capabilities for these two drivers.
Newly Supported Guest Operating Systems — Support for the following guest operating systems has been added specifically for this release:
For more complete information about supported guests included in this release, see the Guest Operating System Installation Guide: http://www.vmware.com/pdf/GuestOS_guide.pdf.
SUSE Linux Enterprise Server 11 (32-bit and 64-bit).
SUSE Linux Enterprise Desktop 11 (32-bit and 64-bit).
Ubuntu 8.10 Desktop Edition and Server Edition (32-bit and 64-bit).
Windows Preinstallation Environment 2.0 (32-bit and 64-bit).
Furthermore, pre-built kernel modules (PBMs) were added in this release for the following guests:
Ubuntu 8.10
Ubuntu 8.04.2
Newly Supported Management Agents — Refer to VMware ESX Server Supported Hardware Lifecycle Management Agents for the most up-to-date information on supported management agents.
Newly Supported I/O Devices — in-box support for the following on-board processors, IO devices, and storage subsystems:
SAS Controllers and SATA Controllers:
The following are newly supported SATA Controllers.
PMC 8011 (for SAS and SATA drives)
Intel ICH9
Intel ICH10
CERC 6/I SATA/SAS Integrated RAID Controller (for SAS and SATA drivers)
HP Smart Array P700m Controller
Notes:
Some limitations apply in terms of support for SATA controllers. For more information, see SATA Controller Support in ESX 3.5 (KB 1008673).
Storing VMFS datastores on native SATA drives is not supported.
Network Cards: The following are newly supported network interface cards:
HP NC375i Integrated Quad Port Multifunction Gigabit Server Adapter
HP NC362i Integrated Dual port Gigabit Server Adapter
Intel 82598EB 10 Gigabit AT Network Connection
HP NC360m Dual 1 Gigabit/NC364m Quad 1 Gigabit
Intel Gigabit CT Desktop Adapter
Intel 82574L Gigabit Network Connection
Intel 10 Gigabit XF SR Dual Port Server Adapter
Intel 10 Gigabit XF SR Server Adapter
Intel 10 Gigabit XF LR Server Adapter
Intel 10 Gigabit CX4 Dual Port Server Adapter
Intel 10 Gigabit AF DA Dual Port Server Adapter
Intel 10 Gigabit AT Server Adapter
Intel 82598EB 10 Gigabit AT CX4 Network Connection
NetXtreme BCM5722 Gigabit Ethernet
NetXtreme BCM5755 Gigabit Ethernet
NetXtreme BCM5755M Gigabit Ethernet
NetXtreme BCM5756 Gigabit Ethernet
Expanded Support: The E1000 Intel network interface card (NIC) is now available for NetWare 5 and NetWare 6 guest operating systems.
Onboard Management Processors:
IBM system management processor (iBMC)
Storage Arrays:
SUN StorageTek 2530 SAS Array
Sun Storage 6580 Array
Sun Storage 6780 Array
Expanded Support for Enhanced vmxnet Adapter — This version of ESX Server includes an updated version of the VMXNET driver (VMXNET enhanced) for the following guest operating systems:
Microsoft Windows Server 2003, Standard Edition (32-bit)
Microsoft Windows Server 2003, Standard Edition (64-bit)
Microsoft Windows Server 2003, Web Edition
Microsoft Windows Small Business Server 2003
Microsoft Windows XP Professional (32-bit)
The new VMXNET version improves virtual machine networking performance and requires VMware tools upgrade.
Enablement of Intel Xeon Processor 5500 Series — Support for the Xeon processor 5500 series has been added. Support includes Enhanced VMotion capabilities. For additional information on previous processor families supported by Enhanced VMotion, see Enhanced VMotion Compatibility (EVC) processor support (KB 1003212).
QLogic Fibre Channel Adapter Driver Update — The driver and firmware for the QLogic fibre channel adapters have been updated to version 7.08-vm66 and 4.04.06 respectively. This release provides interoperability fixes for QLogic Management Tools for FC Adapters and enhanced NPIV support.
Emulex Fibre Channel Adapter Driver Update — The driver for Emulex Fibre Channel Adapters has been upgraded to version 7.4.0.40. This release provides support for the HBAnyware 4.0 Emulex management suite.
LSI megaraid_sas and mptscsi Storage Controller Driver Update — The drivers for LSI megaraid_sas and mptscsi storage controllers have been updated to version 3.19vmw and 2.6.48.18 vmw respectively. The upgrade improves performance and enhance event handling capabilities for these two drivers.
Newly Supported Guest Operating Systems — Support for the following guest operating systems has been added specifically for this release:
For more complete information about supported guests included in this release, see the Guest Operating System Installation Guide: http://www.vmware.com/pdf/GuestOS_guide.pdf.
SUSE Linux Enterprise Server 11 (32-bit and 64-bit).
SUSE Linux Enterprise Desktop 11 (32-bit and 64-bit).
Ubuntu 8.10 Desktop Edition and Server Edition (32-bit and 64-bit).
Windows Preinstallation Environment 2.0 (32-bit and 64-bit).
Furthermore, pre-built kernel modules (PBMs) were added in this release for the following guests:
Ubuntu 8.10
Ubuntu 8.04.2
Newly Supported Management Agents — Refer to VMware ESX Server Supported Hardware Lifecycle Management Agents for the most up-to-date information on supported management agents.
Newly Supported I/O Devices — in-box support for the following on-board processors, IO devices, and storage subsystems:
SAS Controllers and SATA Controllers:
The following are newly supported SATA Controllers.
PMC 8011 (for SAS and SATA drives)
Intel ICH9
Intel ICH10
CERC 6/I SATA/SAS Integrated RAID Controller (for SAS and SATA drivers)
HP Smart Array P700m Controller
Notes:
Some limitations apply in terms of support for SATA controllers. For more information, see SATA Controller Support in ESX 3.5 (KB 1008673).
Storing VMFS datastores on native SATA drives is not supported.
Network Cards: The following are newly supported network interface cards:
HP NC375i Integrated Quad Port Multifunction Gigabit Server Adapter
HP NC362i Integrated Dual port Gigabit Server Adapter
Intel 82598EB 10 Gigabit AT Network Connection
HP NC360m Dual 1 Gigabit/NC364m Quad 1 Gigabit
Intel Gigabit CT Desktop Adapter
Intel 82574L Gigabit Network Connection
Intel 10 Gigabit XF SR Dual Port Server Adapter
Intel 10 Gigabit XF SR Server Adapter
Intel 10 Gigabit XF LR Server Adapter
Intel 10 Gigabit CX4 Dual Port Server Adapter
Intel 10 Gigabit AF DA Dual Port Server Adapter
Intel 10 Gigabit AT Server Adapter
Intel 82598EB 10 Gigabit AT CX4 Network Connection
NetXtreme BCM5722 Gigabit Ethernet
NetXtreme BCM5755 Gigabit Ethernet
NetXtreme BCM5755M Gigabit Ethernet
NetXtreme BCM5756 Gigabit Ethernet
Expanded Support: The E1000 Intel network interface card (NIC) is now available for NetWare 5 and NetWare 6 guest operating systems.
Onboard Management Processors:
IBM system management processor (iBMC)
Storage Arrays:
SUN StorageTek 2530 SAS Array
Sun Storage 6580 Array
Sun Storage 6780 Array
понедельник, 30 марта 2009 г.
"Композитная" виртуальная машина
Один из часто задаваемых вопросов касается "композитной" виртуальной машины. "Можно ли сделать так, чтобы ресурсы двух хостов ESX объединить в одну виртуальную машину?"
Нет, нельзя. Почему?
Кластерные суперкомпьютеры, которые позволяют "объединять" ресурсы множества узлов, строятся под задачи. ПО для работы на этих суперкомпьютерах разрабатывается специально, с учетом всех их особенностей.
Виртуальные машины в общем случае - это универсальное и неспециализированное ПО, которое даже понятия не имеет, что работает не на физическом железе. И ведет себя соответствующим образом.
Даже при использовании специальных высокоскоростных сетей, разработанных для суперкомпьютеров, задержки доступа составляют порядка микросекунды, в то время как задержка доступа к локальной памяти несколько наносекунд, т.е. объединение памяти физических машин в одну "композитную" выльется в 1000-кратное замедление скорости работы. Про процессорные шины и говорить не приходится. Да, пожалуй, если задаться подобной целью, то мы сможем в конечном итоге реализовать проект, который позволит на железе стоимостью сотни тысяч долларов создать виртуальную машину с производительностью на уровне 386 процессора. Извините, 32-процессорной машины с 386 процессорами.
Почему же все тогда говорят про "облако" и ресурсы по заказу? Все очень просто. Мы действительно может давать ресурсы по заказу и относиться к большому Fully automated DRS кластеру ESX как к облаку. Но при одном условии - каждая ВМ требует ресурсов, значительно меньших, чем ресурсы одного хоста. Как только уровень ресурсов становится сравним, облако рассеивается на отдельно стоящие хосты.
Виртуальные машины могут многое, и избавляют нас от многих забот, но они могут не все. И даже при всей автоматизации управления виртуальной инфраструктурой, не следует забывать то, что в первую очередь виртуальные машины - это консолидация серверов, деление ресурсов очень мощного хоста между виртуальными машинами. Если нам надо больше ресурсов для ВМ, чем есть у хоста, то вывод может быть только один - виртуализация здесь не нужна и проблемы с правильным проектированием, а не с недостатком возможностей платформы виртуализации.
Нет, нельзя. Почему?
Кластерные суперкомпьютеры, которые позволяют "объединять" ресурсы множества узлов, строятся под задачи. ПО для работы на этих суперкомпьютерах разрабатывается специально, с учетом всех их особенностей.
Виртуальные машины в общем случае - это универсальное и неспециализированное ПО, которое даже понятия не имеет, что работает не на физическом железе. И ведет себя соответствующим образом.
Даже при использовании специальных высокоскоростных сетей, разработанных для суперкомпьютеров, задержки доступа составляют порядка микросекунды, в то время как задержка доступа к локальной памяти несколько наносекунд, т.е. объединение памяти физических машин в одну "композитную" выльется в 1000-кратное замедление скорости работы. Про процессорные шины и говорить не приходится. Да, пожалуй, если задаться подобной целью, то мы сможем в конечном итоге реализовать проект, который позволит на железе стоимостью сотни тысяч долларов создать виртуальную машину с производительностью на уровне 386 процессора. Извините, 32-процессорной машины с 386 процессорами.
Почему же все тогда говорят про "облако" и ресурсы по заказу? Все очень просто. Мы действительно может давать ресурсы по заказу и относиться к большому Fully automated DRS кластеру ESX как к облаку. Но при одном условии - каждая ВМ требует ресурсов, значительно меньших, чем ресурсы одного хоста. Как только уровень ресурсов становится сравним, облако рассеивается на отдельно стоящие хосты.
Виртуальные машины могут многое, и избавляют нас от многих забот, но они могут не все. И даже при всей автоматизации управления виртуальной инфраструктурой, не следует забывать то, что в первую очередь виртуальные машины - это консолидация серверов, деление ресурсов очень мощного хоста между виртуальными машинами. Если нам надо больше ресурсов для ВМ, чем есть у хоста, то вывод может быть только один - виртуализация здесь не нужна и проблемы с правильным проектированием, а не с недостатком возможностей платформы виртуализации.
Подписаться на:
Сообщения (Atom)
Сообщения
