Смерть узла ESX все равно приведет к смерти какой то части машин. В бесплатном кластере Hyper-V такого не будет. При условии что на живом узле Hyper-V хватит ресурсов поднять все нужные вирт. машины.
Hyper-V как и Windows Server 2008 R2 можно развернуть через WDS атоматом хоть на 1000 машин. Есть вариант bare metall provisioning. И делается это все не за сутки, а быстрее. :)
Крупные хостеры так и делают. Втыкают хосты в стойку и подключают к сети. Загрузка по PXE, установка и конфигурирование идет автоматом.
Для управления ESX нужны навыки командной строки. Для Hyper-V все делается графикой и при крайней необходимости автоматизации Powershell. И что проще для Windows админа по вашему?
У VMWare есть огромный недостаток для него физическое оборудование, вирт. машина и бизнес приложение это черный ящик.
opsMGR + SCVMM позволяют админстратору Hyper-V не напрягаясь мониторить все уровни от железа до конкретного инстанса приложения.
Где у VMWare такой функционал. Посчитайте как на досуге сколько денег вы за это отвалите разным партнерам.
Так что никакого ввода в заблуждения — обычная жестокая правда от человека который разбирается в системах виртуализации.
Кстати одна из первых русскоязычных документаций о VMWare по которой многие нынешние админы учились пользоваться виртуализацией была написана мной. Так что констатирую факт — ввожу людей в заблуждения качественно и чертовски давно.
ESXi не умеет VMotion это значит что все вашин вирт. машины лежат в одной корзине. Отказоустойчивости 0 И в чем тогда смысл?
Тонкие диски
Thin-provisioned disks are virtual disks that «appear» to the VM as one size, but only consume up to the amount of data that is required by that disk. So, a 10 GB drive that is 50% utilized will only store 5 GB on disk (a traditional «thick» virtual disk would consume the entire 10 GB on disk)
Все тоже самое в Hyper-V делает Dynamic VHD
Dynamic disks are disks that allocate space on the fly based on usage.
Ни разу не видел клиента который хочет использовать виртуализацию серверов и при этом у него нет AD. Это все равно что неандерталец сразу начнет писать картины эпохи Возрождения.
Скорее всего это означает что у него 1 физический сервер. В этом случае он сильно рискует сложив все яйца в отдельную корзину.
Единственный случай когда это может пригодиться удаленные филиалы где всего один сервер.
Смотря кому проще. Многим админам с инфраструктурой на Windows изучать Xen или KVM будет весьма накладно.
Более того тут встанет вопрос единой авторизации, резервного копирования вирт. машин и мониторинга. Сделать это все поверх Linux с XEN и KVM не многие в состоянии.
В Windows Server 2008 R2 со всеми установленными ролями и с графическим интерфейсом найдено 45 уязвимостей. В ESX их 79. Качество кода ESX еще не напоминает решето?
Идем дальше в системах используемых для виртуализации ставится только одна роль. Эта роль Hyper-V. Малое количество уязвимостей еще сильнее снижается.
Для систем виртуализации рекомендуется использовать Server Core это снижает количество патчей еще на 50%.
Более того атака на парент партишин Hyper-V не приведет к остановке гипервиpа. Для esx любая успешная атака фатальна ибо монолитный кусок кода.
Единственная уязвимость Hyper-V обнаруженная за все эти годы не является критической ибо для ее задействования надо быть локальным администратом.
Fault Tollerance интересная технология но у него огромное количество ограничений.
Поддерживаются только вот эти процессоры
Intel Xeon based on 45nm Core 2 Microarchitecture Category:
•3100 Series
•3300 Series
•5200 Series (DP)
•5400 Series
•7400 Series
Intel Xeon based on Core i7 Microarchitecture Category:
•3500 Series
•5500 Series
AMD 3rd Generation Opteron Category:
•1300 and 1400 Series
•2300 and 2400 Series (DP)
•8300 and 8400 Series (MP)
Виртуальая машина не может иметь более одного вирт. процессора.
На физическом хосте не может быть более 4-х вирт. машин.
Не все комбинации физ. процессора и виртуальной ОС будут работать.
Fault Tollerance не спасет вас от падения гостевой ОС. Вслед за BSOD или Kernell panic в первом экземпляре вирт. машины упадет и второй экземпляр машины.
Так же не спасет это вас и от падения самого бизнес приложения. Оно одинаково красиво рухнет в обоих экземплярах.
В мире есть гораздо больше процессоров и чипсетов чем вы тут написали и на большинстве из них ESX не будет работать.
Я понимаю что вы поклонник VMWare но думаю не стоит спорить c очевидным фактом что список совместимого с Hyper-V оборудования в десятки раз больше чем у ESX.
Последние 4 года использую Hyper-V в кластерах на оборудовании Sun, HP, DELL, IBM. Иногда у клиентов попадались самосборные сервера. И ни одного BSOD за столько лет на огромном количестве оборудования не было. Что я делаю не так?
Если хотите реально поговорить о качестве кода посмотрите количество патчей безопасноcти для ESX и Hyper-V.
Если у вас Suse или RedHat подобный Linux поставьте компонент Integration Services и каждая виртуалка получит по 4-е вирт процессора и быстрые виртуальные устройства.
Он действительно бесплатный. Правда в нем от Windows осталось совсем чуть чуть. :-)
Крупные хостеры так и делают. Втыкают хосты в стойку и подключают к сети. Загрузка по PXE, установка и конфигурирование идет автоматом.
Для управления ESX нужны навыки командной строки. Для Hyper-V все делается графикой и при крайней необходимости автоматизации Powershell. И что проще для Windows админа по вашему?
У VMWare есть огромный недостаток для него физическое оборудование, вирт. машина и бизнес приложение это черный ящик.
opsMGR + SCVMM позволяют админстратору Hyper-V не напрягаясь мониторить все уровни от железа до конкретного инстанса приложения.
Где у VMWare такой функционал. Посчитайте как на досуге сколько денег вы за это отвалите разным партнерам.
Так что никакого ввода в заблуждения — обычная жестокая правда от человека который разбирается в системах виртуализации.
Кстати одна из первых русскоязычных документаций о VMWare по которой многие нынешние админы учились пользоваться виртуализацией была написана мной. Так что констатирую факт — ввожу людей в заблуждения качественно и чертовски давно.
Особенно это касается систем интенсивно пишуших на жесткий диск.
А почему не хотите применить кластеризацию от самого Oracle?
Тонкие диски
Thin-provisioned disks are virtual disks that «appear» to the VM as one size, but only consume up to the amount of data that is required by that disk. So, a 10 GB drive that is 50% utilized will only store 5 GB on disk (a traditional «thick» virtual disk would consume the entire 10 GB on disk)
Все тоже самое в Hyper-V делает Dynamic VHD
Dynamic disks are disks that allocate space on the fly based on usage.
Скорее всего это означает что у него 1 физический сервер. В этом случае он сильно рискует сложив все яйца в отдельную корзину.
Единственный случай когда это может пригодиться удаленные филиалы где всего один сервер.
Смотря кому проще. Многим админам с инфраструктурой на Windows изучать Xen или KVM будет весьма накладно.
Более того тут встанет вопрос единой авторизации, резервного копирования вирт. машин и мониторинга. Сделать это все поверх Linux с XEN и KVM не многие в состоянии.
Идем дальше в системах используемых для виртуализации ставится только одна роль. Эта роль Hyper-V. Малое количество уязвимостей еще сильнее снижается.
Для систем виртуализации рекомендуется использовать Server Core это снижает количество патчей еще на 50%.
Более того атака на парент партишин Hyper-V не приведет к остановке гипервиpа. Для esx любая успешная атака фатальна ибо монолитный кусок кода.
Единственная уязвимость Hyper-V обнаруженная за все эти годы не является критической ибо для ее задействования надо быть локальным администратом.
Впечатляет не правда ли?
Более того она собирается в отказоустойчивый кластер с Live migration. ;-)
ultimatewhitebox.com/cpu
Я надеюсь вы понимаете что без поддержки в производственной среде никуда?
Поддерживаются только вот эти процессоры
Intel Xeon based on 45nm Core 2 Microarchitecture Category:
•3100 Series
•3300 Series
•5200 Series (DP)
•5400 Series
•7400 Series
Intel Xeon based on Core i7 Microarchitecture Category:
•3500 Series
•5500 Series
AMD 3rd Generation Opteron Category:
•1300 and 1400 Series
•2300 and 2400 Series (DP)
•8300 and 8400 Series (MP)
Виртуальая машина не может иметь более одного вирт. процессора.
На физическом хосте не может быть более 4-х вирт. машин.
Не все комбинации физ. процессора и виртуальной ОС будут работать.
Fault Tollerance не спасет вас от падения гостевой ОС. Вслед за BSOD или Kernell panic в первом экземпляре вирт. машины упадет и второй экземпляр машины.
Так же не спасет это вас и от падения самого бизнес приложения. Оно одинаково красиво рухнет в обоих экземплярах.
Подробнее читайте здесь.
communities.vmware.com/blogs/vmroyale/2009/05/18/vmware-fault-tolerance-requirements-and-limitations
Очень часто задачу можно решить дешевле задействовав механизмы кластеризации встроенные в само приложение.
В общем мое мнение дорогая, редко полезная и мало применяемая технология, о которой так любят рассказывать сотрудники VMWare.
Я понимаю что вы поклонник VMWare но думаю не стоит спорить c очевидным фактом что список совместимого с Hyper-V оборудования в десятки раз больше чем у ESX.
Если хотите реально поговорить о качестве кода посмотрите количество патчей безопасноcти для ESX и Hyper-V.
secunia.com/advisories/search/?search=ESX
secunia.com/advisories/search/?search=hyper-v
79 патчей у ESX и 1 у Hyper-V. Качество кода впечатляет?
www.techdays.ru/videos/2472.html
www.techdays.ru/videos/2415.html
www.techdays.ru/videos/1336.html
Так же я запускал под Hyper-v FreeBSD, OpenSolaris.
blogs.technet.com/b/abeshkov/archive/2009/11/02/SUSE-Linux-Enterprise-Server-10-Hyper_2D00_V-install.aspx
blogs.technet.com/b/abeshkov/archive/2008/12/15/3169299.aspx