Завтра, в 19.00 по московскому времени состоится официальная презентация vSphere. Лично я также польщен предложением российского представительства VMware выступить на презентации как инженера реального заказчика, решающего реальные задачи при помощи VMware Virtual Infrastructure.
В пятницу, 24го апреля, выступлю с презентацией vSphere на заседании нижегородского MCP клуба.
понедельник, 20 апреля 2009 г.
пятница, 17 апреля 2009 г.
vSphere: лицензирование
Сегодня про это не пишет только очень ленивый. Я, конечно, ленивый, но не очень - поэтому тоже напишу :)
Какие функции включены в пакеты:
Маппинг лицензий VI3 при переходе на VI4 aka vSphere:
И маркетинговое обоснование включения тех или иных функций в пакеты.
Какие функции включены в пакеты:
Маппинг лицензий VI3 при переходе на VI4 aka vSphere:
И маркетинговое обоснование включения тех или иных функций в пакеты.
четверг, 9 апреля 2009 г.
Скорость сети в ESXi
Недавно разговор заходил о том, какую скорость выдает 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.
Итак, две физические машины 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.
среда, 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.
Подписаться на:
Сообщения (Atom)
Сообщения
