Ну насчет практически всего я бы не был так категоричен. Я, например, недавно человеку хендгам купил — человек пищит от него просто. Плюс забавные наклейки на холодильник. Плюс плюшевые микробы…
Да я понимаю. Там где подсветка или диммер, лампы дневного света использовать нельзя. Светодиодные и газоразрядные тоже. Только накаливания или аналоги.
Почти то же самое. Есть отдельный светильник на двух галогенах, и в туалете лампочка обычная (там часто свет включают-выключают, не оставлять же его?). СЛомали одну лампу при переезде, оторвался цоколь
Зрительно. Помните как сгорают обычные трубчатые лампы? При сгорании нити накала в такой лампе симптоматика будет такой же — сначала мерцание при запуске, затем лампа погаснет и светится будут только концы трубки.
90% сгоревших у меня ЭС-ламп — электроника. Кстати, оруганый здесь «космос» у меня работает уже два года. «Сгорела» одна лампа, при монтаже лопнул металлический цоколь :)
Ivlis, почитайте мой пост ниже, я там немного вам слов кинул… Идея микроядра чудесна по сути (mach/Plan9), но, к сожалению, отвртатительна по реализации. По хорошему я поддерживаю систему с микроядром и изоляцией программ в контейнеры. Драйвера тоже надо изолировать, а то ситуация, когда выдернутый не вовремя USB роняет ОСь — ненормальна. Но это архитектура ОС, что выходит за рамки этой статьи. И на эту тему я с удовольствием подискутирую.
Бенчмарк я имел ввиду не «синтетический». Понятно, что с точки зрения гостевой ОС бенчмарк может быть абсолютно любым (например, гигабитная Lance1010 в VMWare никого совершенно не удивляет). Я имел ввиду сверку скорости реальной работы ОС, которые сравнивались в паравиртуальном контейнере, на физической машине и в виртуальном контейнере. Разница там ну не очень большая. Понятно, что полная эмуляция железа иной архитектуры заставит прослезится даже самых суровых админов (dynamips, pearpc — привет!).
Про виртуальный диск. Тут есть два скользких момента. Один называется parition table (она бывает реально разная! iB, EFI, MAC, Solaris...), а другой — атрибуты в файловой системе. Как объяснить NTFS, что она должна знать про ZFS Snapshot я, например, не представляю. Нужно ставить драйвер-ловушку, чтобы хранить такую информацию во внешнем хранилище (при его повреждении файлсистеме наступит окончательный и бесповоротный карачун). Или использовать отдельные разделы диска, что убивает идею удобного и быстрого расширения файловой системы без перезагрузки хоста. Или использовать LVM, что по сути не отличается от виртуальных дисков vmware и hyperv
Насчет изменения кода ядра. Это всегда риск. Есть системы, где такой риск может быть не оправдан. Огромный плюс реальной виртуализации в том, что запустить там можно любую ОС, не модифицируя ее никак. Для тех, кому важна стабильность ОС это очень важно.
3) Не согласен. Завтра покопаю материалы, и если этот пост по сумме минусов не успеет удалится — отпишу подробно.
Про XEN. Я с ним имел любовь в одной «маленькой, но гордой» компании-интеграторе. У меня теперь при слове Xen начинает дергатся глаз. На всякий случай я замечу, что я сугубо за opensource. Я не считаю себя фанатом OS (фанатство порочно по сути, поскольку это вопрос веры — то есть примат над разумом). Но считаю что многие вещи в OS реализованы лучше (или по крайней мере — не хуже).
А теперь по XEN.
Первое. За необходимость патчить ядро хоста и ядро guest надо убивать сразу. Это маразм. Подобная реализация виртуализации маразматична по сути. Надо определится — шашечки или ехать. То есть виртуализация или изоляция.
Второе. Патч ядра гостевой системы гарантирует проблемы с запуском других ОС. История о запуске FreeBSD (кто сказал — сдохла?) — это эпопея в трех томах. О пользователях Windows (а такие странные люди тоже есть, представляете?) мы сейчас скромно умолчим. Про пользователей Solaris — тоже.
Третье. Я очень хорошо помню свои хитрые танцы вокруг настройки сети. Далеко не все сетевые карты работают с Xen нормально, а настройка сетей настолько неочевидна, что приходится курить маны на простейшие операции. Мне в принципе не страшно, я покурю. Но «осадочек остается».
Четвертое. Расскажите мне плз, как будете реализовывать кластер на Xen. Нормальный такой кластер, простенький HA (хотя бы!). DRBD не предлагать, по ощущениям он в кластере работает хуже, чем без него.
Пятое. Стабильность первых версий Xen надолго отбивает любовь к Linux вообще. Малопонятные kernel-panic достают до печенки, роняя хост-машину в непредсказуемые моменты.
Шестое. Я понимаю, что настоящий true-admin должен уметь использовать любые инструменты, сам начинал с FreeBSD 4.3. Но за ТАКИЕ средства управления надо казнить. Это вообще за гранью.
Седьмое. Поведение Xen в случае превышения ресурсов очень странно выглядит. Я не говорю что это нормальная практика, но такие ситуации случаются и их надо отрабатывать.
Мое мнение по сумме — для больших систем надо брать взрослые виртуализаторы, класса VMWare VSphere или Sun Cluster/Zones. Для малых и средних — HyperV или VMWare workstation / VMWare server.
Никто не спорит, что для каждой задачи свой инструмент. Кстати, а пользователю не все ли равно, есть ли AD на хост машине? Его туда все равно не пустят :)
А на гостевой машине AD не то что необязателен — он вообще не нужен.
1 и 2) Да, компания Citrix тут как-то лихо отожгла с обновлениями. Знаю минимум две конторы, которые ушли от XenServer в VMWare после этого фокуса. Насчет пара и полной — разница производительности там в проценты (3%-5%, есть бенчмарки). А удобство использования несравнимое. Про экспериментальные билды вы сами ответили на свой вопрос. Бизнес экспериментов не любит. Это простои и потери денег. Кстати, холивара ради — мне Hyper-V не нравится. Но XEN мне нравится еще меньше. Как за совершенно убийственные средства управления и контроля, так и за отказоустойчивость. Вообще на мой взгляд, технология паравиртуализации порочна по сути. Надо либо использовать полную виртуализацию (HyperV, VMWare, VirtualPC, QEMU), либо вообще ее не делать и изолировать ПО средствами ОС.
3) Нет. Они его не патчат. Это драйвер сетевой карты. Что как бы не совсем «ядро в паравиртуальном режиме». Кстати патч не принят :)
Попробую ответить я.
1) Паравиртуализация — это хорошо, когда не хватает ресурсов. Современные процы с аппаратной виртуализацией позволяют запускать виртмашины практически без потерь производительности (то есть преимущество OpenVZ на HyperV и ESX не столь заметно). А вот минусы у OpenVZ по сравнению с полноразмерной виртуализацией довольно заметны — это сложности в работе с памятью и делением процессорного времени, невозможность делать снпашоты, проблемы в переносе виртмашин… Ну и меньшее удобство управления оснастками. И еще. Есть клиенты, которые хотят себе VPS не на Linux. А, скажем, на FreeBSD. И что с ними делать прикажете? :)
2. XEN — некоммерческий продукт. У него нет нормальной поддержки и потому бизнес его внедрять не будет, потому что это риск. Xen — прекрасный продукт, я очень уважаю его разработчиков. Но бизнес не любит красивых решений. Он любит предсказуемые решения. В этом плане HyperV подходит лучше
3. Нет, это не правда.
Простите :)
90% сгоревших у меня ЭС-ламп — электроника. Кстати, оруганый здесь «космос» у меня работает уже два года. «Сгорела» одна лампа, при монтаже лопнул металлический цоколь :)
Бенчмарк я имел ввиду не «синтетический». Понятно, что с точки зрения гостевой ОС бенчмарк может быть абсолютно любым (например, гигабитная Lance1010 в VMWare никого совершенно не удивляет). Я имел ввиду сверку скорости реальной работы ОС, которые сравнивались в паравиртуальном контейнере, на физической машине и в виртуальном контейнере. Разница там ну не очень большая. Понятно, что полная эмуляция железа иной архитектуры заставит прослезится даже самых суровых админов (dynamips, pearpc — привет!).
Про виртуальный диск. Тут есть два скользких момента. Один называется parition table (она бывает реально разная! iB, EFI, MAC, Solaris...), а другой — атрибуты в файловой системе. Как объяснить NTFS, что она должна знать про ZFS Snapshot я, например, не представляю. Нужно ставить драйвер-ловушку, чтобы хранить такую информацию во внешнем хранилище (при его повреждении файлсистеме наступит окончательный и бесповоротный карачун). Или использовать отдельные разделы диска, что убивает идею удобного и быстрого расширения файловой системы без перезагрузки хоста. Или использовать LVM, что по сути не отличается от виртуальных дисков vmware и hyperv
Насчет изменения кода ядра. Это всегда риск. Есть системы, где такой риск может быть не оправдан. Огромный плюс реальной виртуализации в том, что запустить там можно любую ОС, не модифицируя ее никак. Для тех, кому важна стабильность ОС это очень важно.
3) Не согласен. Завтра покопаю материалы, и если этот пост по сумме минусов не успеет удалится — отпишу подробно.
Про XEN. Я с ним имел любовь в одной «маленькой, но гордой» компании-интеграторе. У меня теперь при слове Xen начинает дергатся глаз. На всякий случай я замечу, что я сугубо за opensource. Я не считаю себя фанатом OS (фанатство порочно по сути, поскольку это вопрос веры — то есть примат над разумом). Но считаю что многие вещи в OS реализованы лучше (или по крайней мере — не хуже).
А теперь по XEN.
Первое. За необходимость патчить ядро хоста и ядро guest надо убивать сразу. Это маразм. Подобная реализация виртуализации маразматична по сути. Надо определится — шашечки или ехать. То есть виртуализация или изоляция.
Второе. Патч ядра гостевой системы гарантирует проблемы с запуском других ОС. История о запуске FreeBSD (кто сказал — сдохла?) — это эпопея в трех томах. О пользователях Windows (а такие странные люди тоже есть, представляете?) мы сейчас скромно умолчим. Про пользователей Solaris — тоже.
Третье. Я очень хорошо помню свои хитрые танцы вокруг настройки сети. Далеко не все сетевые карты работают с Xen нормально, а настройка сетей настолько неочевидна, что приходится курить маны на простейшие операции. Мне в принципе не страшно, я покурю. Но «осадочек остается».
Четвертое. Расскажите мне плз, как будете реализовывать кластер на Xen. Нормальный такой кластер, простенький HA (хотя бы!). DRBD не предлагать, по ощущениям он в кластере работает хуже, чем без него.
Пятое. Стабильность первых версий Xen надолго отбивает любовь к Linux вообще. Малопонятные kernel-panic достают до печенки, роняя хост-машину в непредсказуемые моменты.
Шестое. Я понимаю, что настоящий true-admin должен уметь использовать любые инструменты, сам начинал с FreeBSD 4.3. Но за ТАКИЕ средства управления надо казнить. Это вообще за гранью.
Седьмое. Поведение Xen в случае превышения ресурсов очень странно выглядит. Я не говорю что это нормальная практика, но такие ситуации случаются и их надо отрабатывать.
Мое мнение по сумме — для больших систем надо брать взрослые виртуализаторы, класса VMWare VSphere или Sun Cluster/Zones. Для малых и средних — HyperV или VMWare workstation / VMWare server.
А на гостевой машине AD не то что необязателен — он вообще не нужен.
3) Нет. Они его не патчат. Это драйвер сетевой карты. Что как бы не совсем «ядро в паравиртуальном режиме». Кстати патч не принят :)
Сейчас и HyperV работает неплохо (как для пользователей, так и для админов)
1) Паравиртуализация — это хорошо, когда не хватает ресурсов. Современные процы с аппаратной виртуализацией позволяют запускать виртмашины практически без потерь производительности (то есть преимущество OpenVZ на HyperV и ESX не столь заметно). А вот минусы у OpenVZ по сравнению с полноразмерной виртуализацией довольно заметны — это сложности в работе с памятью и делением процессорного времени, невозможность делать снпашоты, проблемы в переносе виртмашин… Ну и меньшее удобство управления оснастками. И еще. Есть клиенты, которые хотят себе VPS не на Linux. А, скажем, на FreeBSD. И что с ними делать прикажете? :)
2. XEN — некоммерческий продукт. У него нет нормальной поддержки и потому бизнес его внедрять не будет, потому что это риск. Xen — прекрасный продукт, я очень уважаю его разработчиков. Но бизнес не любит красивых решений. Он любит предсказуемые решения. В этом плане HyperV подходит лучше
3. Нет, это не правда.