Comments 159
спасибо, в мемориз.
доступно и по делу.
доступно и по делу.
У меня были проблемы при установке pfsense в Hyper-V ( на Windows server 2008).
При выключении система виртуальная машина зависла в состоянии «выключаюсь» и так и осталась. Ни тпру, ни ну. Пришлось перезагружать host os…
Потом смотрели knowledge base:
social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/1c916783-ba02-411d-b52d-640a8a415f26/
Hyper-V «не любит» нестандартные системы и «устаревший» сетевой адаптер. Возможно, это изменилось в R2, не знаю.
Есть еще XenServer (купленный Citrix и без средств управления бесплатный и GPL). Потребляет образы VM в формате vhd. В нем есть живая миграция виртуальных машин.
Брать можно отсюда:
www.citrix.com/English/ps2/products/feature.asp?contentID=1686939
При выключении система виртуальная машина зависла в состоянии «выключаюсь» и так и осталась. Ни тпру, ни ну. Пришлось перезагружать host os…
Потом смотрели knowledge base:
social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/1c916783-ba02-411d-b52d-640a8a415f26/
Hyper-V «не любит» нестандартные системы и «устаревший» сетевой адаптер. Возможно, это изменилось в R2, не знаю.
Есть еще XenServer (купленный Citrix и без средств управления бесплатный и GPL). Потребляет образы VM в формате vhd. В нем есть живая миграция виртуальных машин.
Брать можно отсюда:
www.citrix.com/English/ps2/products/feature.asp?contentID=1686939
Все верно, только виртуализация противопоказана тяжелым вещам. Это стоит отметить. Такие вещи как СУБД, системы скоринга и прочие тяжести, как правило, работают на Enterprice-северах, для которых, есть понятие домена, но не понятия VMware.
А вот для всякой мелочи, особенно для девелоперских и тестовых сред — это просто идеальное решение.
А вот для всякой мелочи, особенно для девелоперских и тестовых сред — это просто идеальное решение.
Спасибо! Добавляю в статью.
Согласен. Для тестирования намного проще сделать несколько виртуалок с нужным окружением, чем тоже самое на нескольких реальных компьютерах.
UFO just landed and posted this here
Ну разумеется, что все в мире относительно. Правило «семь раз отмерь» никто не отменял.
UFO just landed and posted this here
А у вас нагрузка на сервера всегда одинаковая и не прыгает? Какие у вас интересные сервера (потыкал веточкой).
128 гигов не «пердел». но вообще для виртуалок чаще всего проца хватает, а мозги кончаются, так что в типичном случае лучше пара машин с 64 гигами, чем десяток с 2-4.
за стоимость сервера 128 гигами можно смело собрать пяток чуть менее пижонистых серверов и сделать из них то, что нужно.
Чем больше я работаю с виртуализацией, тем больше я против принятия её как основы инфраструктуры в отсутствие человека, который бы только на ней и специализировался. Для резервирования — самое то. Для пробирок — замечательно. Боевые сервера — не очень.
Чем больше я работаю с виртуализацией, тем больше я против принятия её как основы инфраструктуры в отсутствие человека, который бы только на ней и специализировался. Для резервирования — самое то. Для пробирок — замечательно. Боевые сервера — не очень.
Я не очень понимаю факторов против. При том, что ты поднимаешь более теоретические вопросы, а я тебе с т.з. практики говорю.
UFO just landed and posted this here
за стоимость сервера 128 гигами можно смело собрать пяток чуть менее пижонистых серверов и сделать из них то, что нужно.
Возьмем самый простой сервер, HP DL160. Есть модели с 12 слотами оперативки, есть — с 18. Процессорных сокетов у него — одна штука. Неужто вы думаете, что DL160G6 с 16 8-гиговыми планками памяти будет стоить, ну, к примеру, как 10 DL160 по 16 гиг в каждом? Даже с более слабыми процами? Да даже один DL580 с четырьмя 6-ядерными Xeon'ами 7000-й серии и 256 гигами памяти (32 слота по 8 гиг планки) обойдется дешевле десятка 160-х.
Про то, что десять серверов занимают 10 юнитов в стойке, а 4-процовый — всего 4 юнита, и энергии один мощный сервер жрет намного меньше, чем десяток более слабых — можно и не говорить, это очевидно.
UFO just landed and posted this here
я где-то на хабре новости видел про то что планки уже по 32Г выпускаются.
Давно не смотрел хьюлеттовский product bulletin, возможно уже и есть.
а когда вся БД помещается в памяти, то только тут начинаются юзаться ресурсы CPU, а до этого постоянный своппинг не дает еще использовать весь ресурс CPU :)
От дисковой все зависит. И от операций с базой.
UFO just landed and posted this here
хотелось бы услышать мнение по поводу использования ESXi для «тяжелых» вещей. как то мне по обзорам показалось что оверхед там минимальный и ее можно использовать хотя бы для упрощения миграции с одного «железа» на другое на время обслуживания/ремонта. не?
Для упрощения миграции лучше всего использовать Microsoft Hyper-V Server 2008 R2: он бесплатный, поддерживает кластеры и Live Migration, и при этом совсем не требует лицензий на каждый чих и пых.
и про него тоже было бы интересно :)
hyper-v смутил тем что гарантированно поддерживает только SLES в качестве гостей. догадываюсь что при должном желании на него можно вкатить все что угодно (по крайней мере все что на 2.6.x ядре), но пока ни подтверждений ни опровержений не встречал, а экспериментировать самому нет ни времени ни желания в обозримом будущем.
но вообще да, в далеких планах у меня есть пунктик на предмет пощупать и то и другое. hyper-v прельщает бесплатностью и гладкостью«гостевания» виндов, а ESXi просто любопытно покурить, уж больно красиво на сайте про него написано :)
hyper-v смутил тем что гарантированно поддерживает только SLES в качестве гостей. догадываюсь что при должном желании на него можно вкатить все что угодно (по крайней мере все что на 2.6.x ядре), но пока ни подтверждений ни опровержений не встречал, а экспериментировать самому нет ни времени ни желания в обозримом будущем.
но вообще да, в далеких планах у меня есть пунктик на предмет пощупать и то и другое. hyper-v прельщает бесплатностью и гладкостью«гостевания» виндов, а ESXi просто любопытно покурить, уж больно красиво на сайте про него написано :)
Из не-Microsoft OS поддерживается официально SLES и RHEL. Это значит, что под них существуют официальные интеграционные компоненты (драйвера синтетических устройств, то же, что у VMware называется VMware Tools). В принципе, можно поставить туда любую ОС, используя эмулируемые устройства (к примеру — Legacy Network Adapter) вместо синтетических, но некоторые особые фичи (типа Offloading у сетевых адаптеров) поддерживаться не будут.
Ставили вообще туда и FreeBSD, и еще кучу всего — подробнее можно почитать в блоге Андрея Бешкова, и в частности — вот в этом посте: blogs.technet.com/abeshkov/archive/2010/04/01/3322594.aspx
Ставили вообще туда и FreeBSD, и еще кучу всего — подробнее можно почитать в блоге Андрея Бешкова, и в частности — вот в этом посте: blogs.technet.com/abeshkov/archive/2010/04/01/3322594.aspx
спасибо, обязательно почитаю!
интересно, насколько просто дрова от RHEL можно будет прикрутить к CentOS и Mandriva :)
интересно, насколько просто дрова от RHEL можно будет прикрутить к CentOS и Mandriva :)
Попробуйте — и напишите статью. Интересно же!
Разумеется, это unsupported solution, но все же интересно.
Разумеется, это unsupported solution, но все же интересно.
да я бы и рад, но пока как в истории про лесорубов — «нет времени точить, пилить надо!», когда руки доберутся до поиграться я даже приблизительно предполагать не могу. все ищу стимулы, но пока их не достаточно чтобы все отложить и поискать замену xen'у. вроде как все работает и есть более приоритетные вопросы.
но если разберусь обязательно напишу, если меня не опередят, конечно :)
но если разберусь обязательно напишу, если меня не опередят, конечно :)
у меня убунту крутится…
UFO just landed and posted this here
Э… Я позвонил в Microsoft, они сказали, что Hyper-V стоит не меньше 20 тысяч рублей.
Вы нагло брешете.
Вы нагло брешете.
Microsoft Hyper-V Server 2008 (core edition) бесплатная
«Из этого интерфейса нельзя устанавливать дополнительные операционные системы». Как бы офигенный бесплатный гипервизор из которого нельзя устанавливать гостевые операционные системы, а нужно купить какую-то феерическую хрень для установки на ещё более феерически хреновый сервер.
Достаточно купить Windows 7 — и но проблемз. В любой организации есть хотя бы одно рабочее место с Windows. Набор средств управления (RSAT), в которые входит и Hyper-V Manager — бесплатен.
(хлопая глазками) А у нас нет. И как бы потребности не испытываем. Убунта на ноутбуках полностью покрывает все возможные сценарии работы.
А платное ПО означает:
а) Геморрой для бухгалтерии (учёт его)
б) Геморрой для сисадмина (учёт лицензий) или выделение отдельного человека для работы с лицензиями.
в) Постоянное спотыкание на проблемы [нельзя иметь несколько запущенных сессий, нельзя то, нельзя это, а вот тут надо докупить лицензий]
Так что мы как бы без использования «бесплатного» ПО от майкрософт обходимся, ибо выясняется, что таки надо покупать-покупать-покупать. Сначала windows7 для консоли администрирования, потом windows server для домена, потом mssql потому что иначе оно хреново хранит данные, потом ещё что-то…
А платное ПО означает:
а) Геморрой для бухгалтерии (учёт его)
б) Геморрой для сисадмина (учёт лицензий) или выделение отдельного человека для работы с лицензиями.
в) Постоянное спотыкание на проблемы [нельзя иметь несколько запущенных сессий, нельзя то, нельзя это, а вот тут надо докупить лицензий]
Так что мы как бы без использования «бесплатного» ПО от майкрософт обходимся, ибо выясняется, что таки надо покупать-покупать-покупать. Сначала windows7 для консоли администрирования, потом windows server для домена, потом mssql потому что иначе оно хреново хранит данные, потом ещё что-то…
(хлопая глазками) А у нас нет. И как бы потребности не испытываем. Убунта на ноутбуках полностью покрывает все возможные сценарии работы.
А что за контора, если не секрет? Первый раз о таком слышу.
А платное ПО означает:
А как у вас там с цисками? IOS тоже платный, и на отдельные фичи иногда приходится покупать лицензии.
Пока секрет. Вот испытательный срок закончится, будем рассказывать.
IOS'ы есть, но по словам техдиректора (я не по цискам работаю) очень сосут. Большая часть трафика идёт через juniper'ы.
… Закупкой которых занимаются железячники, которые и так и так закупают.
IOS'ы есть, но по словам техдиректора (я не по цискам работаю) очень сосут. Большая часть трафика идёт через juniper'ы.
… Закупкой которых занимаются железячники, которые и так и так закупают.
У меня то же была такая контора. больше тысячи рабочих мест, несколько десятков серверов. на серверах — только unix-like. на рабочих местах — 90% это терминалы (linux) для торговой системы. ну в офисах были XP, плавно мигрировавшиеся в SUSE, но их в самом плохом сценарии было не больше 10% парка.
И работает она без покупки Microsoft Windows Server?
Microsoft Hyper-V Server 2008 R2 — урезанный Windows Server, в котором оставили только Hyper-V. Стоимость — $0.00. Качается с сайта microsoft.com.
Я не спрашиваю, как оно качается, я спрашиваю, оно работает без покупки ПО от майкрософт? В соседнем треде мне уже мимоходом заявляют о покупке семёрки.
да, оно работает без покупки по от майкрософт. но не на все 100. как и любая другая платформа виртуализации, она требует клиента для управления.
в хайпер-ви это RSAT (H-V Manager), в ESX это VI Client и т.д. Где вы будете запускать клиента — это уже ваше дело. Если уж идти на принцип, то ставим БЕСПЛАТНЫЙ хайпер-ви, ставим БЕСПЛАТНУЮ триальную версию любой современной ОСвиндовс, ставим БЕСПЛАТНЫЙ RSAT и настраиваем бесплатные виртуалки.
Если уж быть совсем принципиальным — режим Core полноценно поддерживает павершелл, которым можно при желании рулить виртуалками прямо с хоста. Об удобстве речь конечно не идет.
в хайпер-ви это RSAT (H-V Manager), в ESX это VI Client и т.д. Где вы будете запускать клиента — это уже ваше дело. Если уж идти на принцип, то ставим БЕСПЛАТНЫЙ хайпер-ви, ставим БЕСПЛАТНУЮ триальную версию любой современной ОСвиндовс, ставим БЕСПЛАТНЫЙ RSAT и настраиваем бесплатные виртуалки.
Если уж быть совсем принципиальным — режим Core полноценно поддерживает павершелл, которым можно при желании рулить виртуалками прямо с хоста. Об удобстве речь конечно не идет.
В ESX же веб-интерфейс вроде был? Или он был только в платном ESX, а в ESXi его нет?
Вот только я не уверен, что оттуда можно подключиться к консоли виртуалки.
Если уж быть совсем принципиальным — режим Core полноценно поддерживает павершелл, которым можно при желании рулить виртуалками прямо с хоста. Об удобстве речь конечно не идет.
Вот только я не уверен, что оттуда можно подключиться к консоли виртуалки.
никогда не было веб-интерфейса. ни в ESX ни в ESXi.
очень не хочется расстраивать amarao, но вообще «оттуда» можно делать все что угодно. БЕСПЛАТНО!
pshyperv.codeplex.com/
очень не хочется расстраивать amarao, но вообще «оттуда» можно делать все что угодно. БЕСПЛАТНО!
pshyperv.codeplex.com/
Hyper-V стоит столько же, сколько и IIS — то есть бесплатно. Входит в состав Windows Server 2008.
Есть еще целый Hyper-V Server, который бесплатен — на хабре даже про него пара статей была.
Есть еще целый Hyper-V Server, который бесплатен — на хабре даже про него пара статей была.
Кожанные сидения в автомобиле бесплатные, они входят в состав автомобиля, типа так?
Про Hyper-V Server уже сказали выше, и даже ссылку дали — без внешней системы управления (под всё той же виндой) он не умеет ставить новые гостевые ОС.
Про Hyper-V Server уже сказали выше, и даже ссылку дали — без внешней системы управления (под всё той же виндой) он не умеет ставить новые гостевые ОС.
Комплектация с кожаными сиденьями стоит, как правило, чуть дороже :)
Внешняя система управления — а что в этом плохого? :)
Кстати, раз на то пошло — есть vmware esxi, который тоже бесплатен, и имеет встроенный веб-интерфейс.
Внешняя система управления — а что в этом плохого? :)
Кстати, раз на то пошло — есть vmware esxi, который тоже бесплатен, и имеет встроенный веб-интерфейс.
не умеет в юзерфрендли моде. это я на случай если будут всякие зены в пример приводиться.
Совсем не «противопоказано».
С Vmotion немножко не так все, время переезда сильно зависит от сервера и может занять даже до часа времени и в это время сервер будет подтормаживать.
В общем, я против виртуализации в высоконагруженном продакшне — слишком большие риски.
В общем, я против виртуализации в высоконагруженном продакшне — слишком большие риски.
Час — это при очень больших объемах памяти. При миграции копируется только память, виртуальные диски остаются на СХД. В высоконагруженных системах для быстрого копирования памяти при миграции можно использовать отдельные сетевые адаптеры, и даже — 10-гигабитные.
Опять же, час «подтормаживания» все же лучше, чем час даунтайма на разборку-сборку сервера, к примеру, для добавления оперативки.
Опять же, час «подтормаживания» все же лучше, чем час даунтайма на разборку-сборку сервера, к примеру, для добавления оперативки.
Лучше не жмотиться и сразу поставить столько памяти, сколько нужно с запасом. Виртуализация нагруженного продакшна — она от жмотства в основном, к сожалению, а потом оказывается чревато теми же затратами в виде простоя сервисов =(
Лучше не жмотиться и сразу поставить столько памяти, сколько нужно с запасом.
Microsoft (и я тоже) в этом полностью с Вами согласны. Память, да и все остальное железо необходимо проектировать с запасом.
VMware же почему-то так не считает, и во всю пиарит Memory Overcommitment :)
Давайте-ка без holywar'а.
Для Memory Overcommitment реальный коэффициент экономии памяти в 1.3-1.4 раза.
Полтора года назад vMotion и Storage vMotion были, почему-то, не для продакшен сред. А как вышел R2, ветер подул в другую сторону. Про горячее добавление — та же песня, до SP1 будет.
Для Memory Overcommitment реальный коэффициент экономии памяти в 1.3-1.4 раза.
Полтора года назад vMotion и Storage vMotion были, почему-то, не для продакшен сред. А как вышел R2, ветер подул в другую сторону. Про горячее добавление — та же песня, до SP1 будет.
Дык MS vs VMware — это самая благодатная тема для холивара, после Wnn vs Lin, Intel vs AMD, PC vs MAC, PC vs XBox vs PS3 и nVidia vs ATI :)
Я сам это заметил — даже безобидная статья про Live Migration подобна вбросу на вентилятор.
vMotion — не то что не для продакшна, MS позиционировал его просто как не особо нужную фичу. Полезную — да, но не жизненно необходимую. Потому и отложили до R2.
Я сам это заметил — даже безобидная статья про Live Migration подобна вбросу на вентилятор.
vMotion — не то что не для продакшна, MS позиционировал его просто как не особо нужную фичу. Полезную — да, но не жизненно необходимую. Потому и отложили до R2.
>Виртуализация приложений – достаточно интересное, и относительно новое направление.
Нуууууу… Скорее хорошо забытое старое. Таким вещам, как bind-chroot, например, 100 лет в обед. Теперь же о них вспомнили на волне моды на виртуализацию.
Нуууууу… Скорее хорошо забытое старое. Таким вещам, как bind-chroot, например, 100 лет в обед. Теперь же о них вспомнили на волне моды на виртуализацию.
Термин виртуализация несет в себе более глубокий смысл, нежели раскрыт в статье, существует также виртуализация рабочих станций (VDI), виртуализация состояния пользователей, виртуализация сетей, виртуализация систем хранения данных…
Виртуализация может прекрасно использоваться в высоконагруженных средах (там, где вообще уместно говорить о x86 архитектуре), у VMware, у Microsoft, у вендоров по системам хранения есть много хороших гайдов и best practices по планированию и сайзингу виртуальной инфраструктуры.
Виртуализация может прекрасно использоваться в высоконагруженных средах (там, где вообще уместно говорить о x86 архитектуре), у VMware, у Microsoft, у вендоров по системам хранения есть много хороших гайдов и best practices по планированию и сайзингу виртуальной инфраструктуры.
VDI — это виртуализация железа, у нее очень много общего с виртуализацией серверов. Виртуализация сетей, СХД — это все известно, просто не хотелось копать уж настолько вглюбь, иначе статья получилась бы километровой. Потому что даже сами многопроцессорные системы — это уже виртуализация. Захотелось раскрыть те аспекты виртуализации, о которых сейчас во всю трубят маркетоиды всех калибров. А это — именно те три аспекта, которые я и привел.
У нас стоит 4 VM хоста. Сумарно на них стоит около 10 серверов. Это и DC01, DC02, Sharepoint, WSUS, Sqiud, некоторые сервера терминалов отделов, локальные веб-сервера, лаборатория (3-4 виртуалки для обкатки решений перед выводом в продакшен. DC01 и DC02 стоят на разных хостах. Не виртуализируем 1С и MS Exchange по причине высоких нагрузок.
Вообще есть негласное правило виртуализации, «если средняя нагрузка составляет более 50% — виртуализация бессмыслена и вредна.»
Вообще есть негласное правило виртуализации, «если средняя нагрузка составляет более 50% — виртуализация бессмыслена и вредна.»
плюсом также для нас является быстрая выкатка готовых ОС в использование. 10-15 мин и установленная и предварительно настроенная ОС готова.
Контроллер домена все же хотя бы один нужно иметь «железный». Надо, чтобы хотя бы один КД стартовал раньше всех остальных серверов. Особенно это касается Exchange.
Спасибо, здравая мысль!
Вообще есть негласное правило виртуализации, «если средняя нагрузка составляет более 50% — виртуализация бессмыслена и вредна.»
Спасибо, здравая мысль!
Мы много думали над этим. И тоже хотели хотя бы Secondary DC отставить на железе, но все же решили контроллеры виртуализировать, но на разные хосты.
Мы конструируем системы в 24/7/365, и у нас не будет проблемы «чтобы хотя бы один КД стартовал раньше всех остальных серверов». В случае аварии Secondary держит AD. С питанием все ок, подведены 2 независимые линии. Хосты находятся в отдельных автозалах, тоесть физически разделены (на случай, не дай Бг, пожара).
Мы конструируем системы в 24/7/365, и у нас не будет проблемы «чтобы хотя бы один КД стартовал раньше всех остальных серверов». В случае аварии Secondary держит AD. С питанием все ок, подведены 2 независимые линии. Хосты находятся в отдельных автозалах, тоесть физически разделены (на случай, не дай Бг, пожара).
у меня — jдин железный, второй в виртуалке
Спасибо за статью.
По теме виртуализации представлений я с Вами немного не соглашусь в плане достоинств, перечисленных выше. Не стоит уповать на снижение требований к «железу» и к пропускной способности сети, это не правда. В случае, если мы разговариваем о полноценной работе на тонком клиенте, упрощать конфигурацию ТК или закупать дешевые конфигурации крайне не рекомендуется. Основной упор на быстродействие при массовом внедрении ТК в организации, следует делать на производительную графическую систему, достаточно мощный процессор и как минимум нормальную пропускную способность сети в пределах 1 Гигабита. Конечно, можно посадить клиента на lo-bandwith схему, пусть он работает в 256 цветах и прочее, однако это не тот путь, которым надо идти.
По теме виртуализации представлений я с Вами немного не соглашусь в плане достоинств, перечисленных выше. Не стоит уповать на снижение требований к «железу» и к пропускной способности сети, это не правда. В случае, если мы разговариваем о полноценной работе на тонком клиенте, упрощать конфигурацию ТК или закупать дешевые конфигурации крайне не рекомендуется. Основной упор на быстродействие при массовом внедрении ТК в организации, следует делать на производительную графическую систему, достаточно мощный процессор и как минимум нормальную пропускную способность сети в пределах 1 Гигабита. Конечно, можно посадить клиента на lo-bandwith схему, пусть он работает в 256 цветах и прочее, однако это не тот путь, которым надо идти.
А что есть «полноценная работа»? Никто в здравом уме не собирается смотреть HD-фильмы, или там рендерить в 3DSMax на тонких клиентах. Терминальные среды предназначены для работы множества пользователей в относительно простых приложениях. В частности, для того, чтобы забивать накладные в 1С — не нужна гигабитная сеть и разрешение 1920*1080*32bit, достаточно и 256 цветов ;)
А
это уже не тонкий, а толстый клиент :)
А
производительную графическую систему, достаточно мощный процессор и как минимум нормальную пропускную способность сети в пределах 1 Гигабита
это уже не тонкий, а толстый клиент :)
А что есть «полноценная работа»? Никто в здравом уме не собирается смотреть HD-фильмы, или там рендерить в 3DSMax на тонких клиентах.
Тем не менее, сейчас все вендоры стремятся наделить свои решения подобным функционалом. :)
Полноценная работа подразумевает работу в терминале, предоставляющем не только доступ к рабочему окружению, но и к мультимедиа. Сейчас это очень востребовано, ввиду широкого распространения VoIP и прочих коммуникаций.
Конечно, 256 цветов достаточно, если смотреть на такой экран 5-10 минут в день. А вы пробовали так работать? Пожалейте глаза пользователя, в конце концов ;)
Конечно, 256 цветов достаточно, если смотреть на такой экран 5-10 минут в день. А вы пробовали так работать? Пожалейте глаза пользователя, в конце концов ;)
VoIP, по моему скромному мнению, лучше все же реализовывать на железках. Да и самая простая встроенная звуковая карта позволит общаться через MS OCS например. X-Fi и HD-разрешение для коммуникаций, опять же, не нужно. Для TelePresence есть аж целые специальные железки.
Пробовали, во времена WinNT/2000. Я еще даже 60-герцовые мониторы застал :)
Конечно, 256 цветов достаточно, если смотреть на такой экран 5-10 минут в день. А вы пробовали так работать?
Пробовали, во времена WinNT/2000. Я еще даже 60-герцовые мониторы застал :)
Ну если мы говорим о консолидации информации, ведь это одна из первых целей виртуализации десктопов, стоит заметить, что ТК как правило либо не включают в домен вообще, либо включают для управления, но не в целевой. Как вы себе представляете интеграцию Office Communicator и Outlook в таких условиях? Естественно в большинстве случаев они будут установлены на TS.
Конечно, можно работать и через OWA/CWA, но это либо домашний вариант, либо недофункциональный saas.
Конечно, можно работать и через OWA/CWA, но это либо домашний вариант, либо недофункциональный saas.
Это да. Но много ли надо клиенту для обработки картинки низкого качества с низким FPS и низкокачественного звука? Все равно основная нагрузка ляжет на сервер, а клиент будет только показывать «картинку». Да, может для видеотелефонии 256 цветов будет и маловато, можно поставить 16bit. Человек все равно разницы между 16 и 32-битным цветом не заметит.
>> Пожалейте глаза пользователя, в конце концов ;)
Некрасиво «Малое количество цветов» не означает «вредно для глаз». Радары вообще двухцветные и ничего. :)
Некрасиво «Малое количество цветов» не означает «вредно для глаз». Радары вообще двухцветные и ничего. :)
>> Еще одно неоспоримое преимущество – ОС, запущенная внутри виртуальной машины (гостевая ОС) понятия не имеет, какое оборудование установлено на физическом сервере, внутри которого она работает (хост).
Это не всегда так.
cat /proc/cpuinfo и видно будет ваш реальный процессор
>> Поэтому, при замене железа, при апгрейде или даже переезде на новый сервер необходимо обновить драйверы только на ОС самого хоста (хостовой ОС).
А как же старый баян с VMWare: при копировании виртуалки на другой комп eth0 меняется на eth1
Это не всегда так.
cat /proc/cpuinfo и видно будет ваш реальный процессор
>> Поэтому, при замене железа, при апгрейде или даже переезде на новый сервер необходимо обновить драйверы только на ОС самого хоста (хостовой ОС).
А как же старый баян с VMWare: при копировании виртуалки на другой комп eth0 меняется на eth1
Я, признаюсь честно, не очень силен в unix-like OS, специализируюсь на MS :) Там вроде таких проблем с интерфейсами не было.
>А как же старый баян с VMWare: при копировании виртуалки на другой комп eth0 меняется на eth1
копировании или переносе? она ведь честно спрашивает что Вы сделали с образом? если «перенесли» то все остается как было. А если скопировали, то она генерит новый мак для сетевушки, что логично ведь скопировать вы ее могли для использования в той же сети где и источник, а два одинаковых мака в одной сети это зло.
копировании или переносе? она ведь честно спрашивает что Вы сделали с образом? если «перенесли» то все остается как было. А если скопировали, то она генерит новый мак для сетевушки, что логично ведь скопировать вы ее могли для использования в той же сети где и источник, а два одинаковых мака в одной сети это зло.
UFO just landed and posted this here
Копирование без копирования настроек — это просто тупой перенос VHD-файла? Ну да, разумеется, сетевой адаптер будет уже вроде как новый, с новым MAC-адресом. Это то же самое, что заменить сетевку в обычном компе. На сетевку той же модели — но MAC уже другой, и разумеется настраивать придется заново.
Для переноса виртуалки с сервера на сервер в Hyper-V нужно использовать импорт-экспорт или Live Migration.
Для переноса виртуалки с сервера на сервер в Hyper-V нужно использовать импорт-экспорт или Live Migration.
чем хорошо, на мой взгляд, использование виртуальных серверов — это возможность разделить серверные роли по принципу один сервер — одна роль, особенно в кластерном окружении, где на ноды кластера нежелательно прикручивать разные роли и проч., так как они аппаратно и программно должны быть идентичны.
Выделяя необходимое пространство и ресурсы под каждую задачу, виртуальные сервера легко раскидать по нодам, и отслеживать возможные программные сбои проще. В случае же сбоев на одном из физических серверов, всё хозяйство, будь то WSUS, Exchange, DHCP или IIS, автоматически подхватывается другими серверами.
Выделяя необходимое пространство и ресурсы под каждую задачу, виртуальные сервера легко раскидать по нодам, и отслеживать возможные программные сбои проще. В случае же сбоев на одном из физических серверов, всё хозяйство, будь то WSUS, Exchange, DHCP или IIS, автоматически подхватывается другими серверами.
[em]Виртуализация приложений – достаточно интересное, и относительно новое направление. Рассказывать здесь подробно о нем я не буду, поскольку это тема для целой отдельной статьи. Коротко говоря, виртуализация приложений позволяет запускать отдельное приложение в своей собственной изолированной среде (иногда называется «песочница», sandbox).[/em]
в 2010 году Microsoft наконец-то изобрела «относительно новые» chroot/jail?
в 2010 году Microsoft наконец-то изобрела «относительно новые» chroot/jail?
Не только Microsoft, но и VMWare и Citrix. И не в 2010 году, а чуть раньше.
пожалуй, мне нужно было прикрепить к комментарию табличку «сарказм».
Сарказм тут немного не к месту. Технологии виртуализации приложений — это чуть большее, чем chroot/jail. Это все равно, что конструктору космических кораблей говорить «ха-ха, ракеты еще китайцы тыщу лет назад изобрели!»
я кажется конкретный абзац указал, а не общие словеса. моя претензия была к «относительно новое», в части, касающейся «приложение в своей изолированной среде».
господа, кто еще хочет наминусовать за красноглазость, так я не только solaris администратор, я еще и microsoft certified в далеком прошлом. и я действительно искренне рад, что таки да — не в 2010, а «чуть раньше» наконец изобрели нечто «чуть большее».
господа, кто еще хочет наминусовать за красноглазость, так я не только solaris администратор, я еще и microsoft certified в далеком прошлом. и я действительно искренне рад, что таки да — не в 2010, а «чуть раньше» наконец изобрели нечто «чуть большее».
А насколько давно было это прошлое? Если это, скажем, XP/2003, то почти совпадает с выходом MS Virtual Server и, например, Xen. Если 2000 и раньше, то тогда и VMWare GSX/ESX еще не было. Оригинальный же продукт от Connectix, который впоследствии и купила MS с VMWare одногодки. Так что сдается мне, здесь не сарказм, а просто незнание предмета вкупе с желанием при каждом удобном случае пнуть мелкомягких и податливых :)
это Windows NT 3.51/4.0, если я правильно понял вопрос и он был про мое далекое прошлое «подоконника» :) если понял неправильно, поправьте.
о чем я и пишу, не о vmware, hyper-v, connectix, а о том, об «относительно новом» в части «приложение в изолированной среде», о самой концепции, которой сто лет в обед. просто теперь её придумали (не прошло и 20 лет) и «податливые» тоже, и придумали назвать красивыми buzzwords.
если углубляться в детали. оригинальный connectix и vmware workstation — это виртуализация приложений, о которой шла речь в моем первом комментарии? ну извините. и эти люди переходят на личности и намекают на незнание предмета и додумывают про мое желание кого-то/что-то пнуть? прелесть.
написал вроде по-русски: «приложение в изолированной среде» называть «относительно новым» можно только хорошо объевшись вкусного тортика на презентации Microsoft. выйдя из зоны coffee break, так веселиться уже не стОит :) ну или стОит, но тогда непременно добавлять, «да, теперь chroot/jail изкоробки придумали и у нас, и даже круче!».
о чем я и пишу, не о vmware, hyper-v, connectix, а о том, об «относительно новом» в части «приложение в изолированной среде», о самой концепции, которой сто лет в обед. просто теперь её придумали (не прошло и 20 лет) и «податливые» тоже, и придумали назвать красивыми buzzwords.
если углубляться в детали. оригинальный connectix и vmware workstation — это виртуализация приложений, о которой шла речь в моем первом комментарии? ну извините. и эти люди переходят на личности и намекают на незнание предмета и додумывают про мое желание кого-то/что-то пнуть? прелесть.
написал вроде по-русски: «приложение в изолированной среде» называть «относительно новым» можно только хорошо объевшись вкусного тортика на презентации Microsoft. выйдя из зоны coffee break, так веселиться уже не стОит :) ну или стОит, но тогда непременно добавлять, «да, теперь chroot/jail изкоробки придумали и у нас, и даже круче!».
Ну как-то совсем «в далеком прошлом».
вот именно. и «виртуализация приложений в собственной изолированной среде» была уже тогда. правда не у microsoft, и под другим именем. но всё еще «относительно новое направление»?
хотя в комментариях к насквозь proMicrosoft'ованному посту выразить недоумение было неосмотрительно :) святое задел, видимо.
хотя в комментариях к насквозь proMicrosoft'ованному посту выразить недоумение было неосмотрительно :) святое задел, видимо.
Вы забыли про прекрасную технологию VMWare HA. Кушаем и нахваливаем.
Я, к сожалению, VMware маловато откушал — только два ESX-сервера было, никаких HA, DRS и прочих «сладостей» — увы :( Зато с Hyper-V я и кластеры собирал, и Live Migration юзал :)
Сколько мигрирует машина с 10Гб реального диска и гигом занятой в работе памяти?
(сколько времени она не отвечает на запросы)
(сколько времени она не отвечает на запросы)
машина мигрирует с ноды на ноду с гигом памяти примерно 15-25 секунд. не отвечает она 1-2 секунды в самом конце, в момент переключения между нодами.
диски на сторе, по этому они не мигрируют.
(можно мигрировать диски в целях перераспределения дискового пространства. Миграция 10 гигов примерно минута, может чуть больше. машина отвечает все время, ибо для виртуалки ничего не меняется)
диски на сторе, по этому они не мигрируют.
(можно мигрировать диски в целях перераспределения дискового пространства. Миграция 10 гигов примерно минута, может чуть больше. машина отвечает все время, ибо для виртуалки ничего не меняется)
померял.
vmotion (миграция вм) 1gb, загрузка 20% проца — миграция за 1 минуту. потеряно 2 пинга.
storage vmotion (перенос стора включенной машины) 10 gb — 4 минуты, нет потерь.
скорости не линейны — из этого времени довольно большой процент занимает подготовка, проверка(?), в общем внутренние процессы, например 20 gb перенесла за 5-6 минут.
vmotion (миграция вм) 1gb, загрузка 20% проца — миграция за 1 минуту. потеряно 2 пинга.
storage vmotion (перенос стора включенной машины) 10 gb — 4 минуты, нет потерь.
скорости не линейны — из этого времени довольно большой процент занимает подготовка, проверка(?), в общем внутренние процессы, например 20 gb перенесла за 5-6 минут.
В VMware — не скажу, ибо не видел. В Hyper-V — меньше минуты сама миграция, при этом ни одного ping timeout'a, и даже терминальная сессия к виртуалке не отваливается. Подозреваю, что у vmware не хуже — иначе б они не носились со своим vmotion как с писаной торбой.
у меня — отваливается. чяднт?
Смотреть надо. При правильной настройке ничего отваливаться не должно: сама виртуалка становится «недоступной» только в момент перемонтирования стораджей на новом хосте. Что-то значит со стораджем, если процесс монтирования такой долгий, что успевают отвалиться TCP-сессии. Во время копирования памяти (а это — самая долгая часть процесса миграции) виртуалка остается на старом хосте и продолжает работать.
Так что — смотрите хранилище.
Есть, правда, у меня другие предположения, но они совсем уж невероятные: у вас Windows Server 2008 не R2 — в нем просто нет Live Migration, или же вы используете Quick Migrtaion вместо Live Migration в R2.
Так что — смотрите хранилище.
Есть, правда, у меня другие предположения, но они совсем уж невероятные: у вас Windows Server 2008 не R2 — в нем просто нет Live Migration, или же вы используете Quick Migrtaion вместо Live Migration в R2.
А сможете объяснить, почему в тегах только Hyper-V? Есть же еще openVZ, KVM, XEN…
Смогу. Потому, что я специализируюсь на Hyper-V, и по ней смогу ответить наиболее точно, и потому и в статье речь шла больше о Hyper-V.
На самом деле, то, что применимо к Hyper-V, тоже применимо и к KVM и к XEN в большей степени, за очень редкими и достаточно специфичными случаями. Не такое уж принципиальное отличие может быть в ядре хоста и способе подготовки гостевых систем, только и всего…
Есть старый анекдот про Василия Иваныча, Петьку и нюансы.
Так вот, если сравнивать, например, VMware ESXi и Hyper-V — вроде как делают они одно и то же, но архитектура гипервизора разная принципиально — у ESXi она монолитная, у Hyper-V — микроядерная. В результате, у VMware очень и очень ограниченный список поддерживаемого железа.
Я уверен, такие же нюансы есть и в перечисленных Вами продуктах, и потому, поскольку о них я не знаю ничего, кроме названий — решил и не упоминать, от греха подальше. Если Вы напишите соотвтетсвующую статью — буду только рад.
Так вот, если сравнивать, например, VMware ESXi и Hyper-V — вроде как делают они одно и то же, но архитектура гипервизора разная принципиально — у ESXi она монолитная, у Hyper-V — микроядерная. В результате, у VMware очень и очень ограниченный список поддерживаемого железа.
Я уверен, такие же нюансы есть и в перечисленных Вами продуктах, и потому, поскольку о них я не знаю ничего, кроме названий — решил и не упоминать, от греха подальше. Если Вы напишите соотвтетсвующую статью — буду только рад.
xen это xen, а есть ещё xen cloud, после которого hyper-v выглядит примерно как vmware workstation по сравнению с любым *server.
Все же не очень понятно, почему нынче это модный тренд? ведь VMware существует уже достаточно долго и виртуальными машинами пользуются уже достаточно долго. О тонких клиентах говорили еще в начале 2000-х, если не раньше.
Модный тренд — потому что о виртуализации всего и вся говорят все, кому не лень. Я заметил это еще во времена Virtual Server 2005 на конференциях вендоров железа — HP и Fujitsu-Siemens. Ну а с появлением Hyper-V все только усилилось, и холивар MS vs VMware уступит разве что Win vs Lin и PC vs Mac.
Потому что память подешевела, а виртуализация — это память. 5% загрузки процессора и винчестера на машину — это хорошо было и раньше, но любой сервер память занимает на 100%, поэтому как только стало возможно выделить гарантированную память — виртуализация и заработала.
Ну и количество серверов резко растёт.
Ну и количество серверов резко растёт.
здравая статейка, спасибо
Ох уж эти горе-маркетологи: кто-нибудь знает, что такое «Linux-подобная операционная система»?
жаль, ничего не было сказано о непроприетарных системах виртуализации, которые очень отличаются от Hyper-V и VMWare.
А сколько денег виртуализация приносит хостинговым компаниям!
Сколько-то. Могу сказать, что виртуализацию начали двигать в хостинг против воли крупных операторов дата-центров. Сдавать в аренду юниты, шкафы и розетки с дополнительной мощностью куда проще и выгоднее, чем мутить виртуализацию.
Так что это форма такого злобненького демпинга: дать всем по руту, не забирая при этом денег за dedicated/colocation.
Так что это форма такого злобненького демпинга: дать всем по руту, не забирая при этом денег за dedicated/colocation.
мы наоборот отказываемся от виртуализации постепенно. хотя 4 года юзали сначала vmware gsx (который теперь бесплатный), потом citrix xenserver. причина — проекты банально выросли за пределы одной виртуалки.
хорошая инфраструктура с FC-хранилищами, примерно одинаковым железом и правильной планировкой обеспечивает не худшую, если не лучшую надежность. так что единственное что теперь юзаем — виртуализация «для поражений в правах» типа solaris zones. ну и отдельный проект лучше в таком контейнере держать конечно — таскать удобней.
хорошая инфраструктура с FC-хранилищами, примерно одинаковым железом и правильной планировкой обеспечивает не худшую, если не лучшую надежность. так что единственное что теперь юзаем — виртуализация «для поражений в правах» типа solaris zones. ну и отдельный проект лучше в таком контейнере держать конечно — таскать удобней.
угу, таскать вообще прекрасно, даже если не FC хранилище. перекидывание с железа на железо занимает zfs-snapshot-send-receive, zonecfg create и покурить.
вопрос не столько в надежности, сколько в адекватности использования железа.
покупать слабые машины смысла нет, а более-менее современный сервер редко когда загружен больше 10%.
виртуалки дают возможность равномернее нагрузить железо, при этом в должной степени изолировать хосты друг от друга.
покупать слабые машины смысла нет, а более-менее современный сервер редко когда загружен больше 10%.
виртуалки дают возможность равномернее нагрузить железо, при этом в должной степени изолировать хосты друг от друга.
а это проблема сугубо систем вроде лялеха которые сервер нормально загрузить не могут
в чем радость грузить систему «ничем»?
винды, кстати, так же не грузят. я могу пяток средне нагруженных виндов свалить на одну ноду без ущерба для производительность каждой.
винды, кстати, так же не грузят. я могу пяток средне нагруженных виндов свалить на одну ноду без ущерба для производительность каждой.
а в чём радость покупать 5 серверов если задача умещается на одном? для виндов да — там всякие PDC с терминал-серверами на одной машине очень плохо живут. но это отдельная история
ну именно тем, что мелкософт категорически рекомендует разносить сервисы по разным машинам. с пдц много что не рекомендуют, и я даже видел лично грабли с экченджем и тс.
и потом, если не говрить о линухе (из-за вашей нелюбви) и о винде (из-за необходимости изолировать сервисы) то о чем тогда? какие операционки нужны вам в энтерпрайзе?
и потом, если не говрить о линухе (из-за вашей нелюбви) и о винде (из-за необходимости изолировать сервисы) то о чем тогда? какие операционки нужны вам в энтерпрайзе?
обхожусь соляркой и изредка линуксом. а винда кстате у нас крутит на одной машине бедная и PDC и ексченч и шарепоинт. но признаю что это очень неправильно и hyper-v у мелкософта это единственный вариант разделения системы на куски.
а вообще это конечно перевод гигабайт и гигагерц — зачем поднимать 5 машин в hyper-v которые крутят одинаковый NT-ячий кернель, если он действительно везде одинаковый? зачем на каждый сервер класть на 90% одинаковую 10-гиговую C:\Windows? хорошо если это дешевый терабайтник. а если это пром. SSD или два SAS в зеркале, уже 20-30 евро на сетап каждого domu (или как они там называются у мелкомягких) просто выкинули на одну сраную папку.
могли бы поднапрячься и сделать какие-то контейнеры потоньше.
а линупсу — виртуализация нужна и еще как нужна. попробуйте поставить линукс на машину с 16 головами (да уже и на 8 всё прекрасно заметите), нафаршировать всякими HBA и запустить пару тяжелых java-приблуд или оракле. а потом включите mpstat и полюбуйтесь какие затыки по лоаду будут на паре-тройке голов, в то время как действительно, остальные будут тупо гонять NOPы в idle. вот за это да, за это я лёлекс не просто не люблю а можно даже сказать ненавижу. потому что этой недосистеме больше 4х голов на одно ядро давать противопоказано. а 4 головы — это нынче десктопный проц средней паршивости.
а вообще это конечно перевод гигабайт и гигагерц — зачем поднимать 5 машин в hyper-v которые крутят одинаковый NT-ячий кернель, если он действительно везде одинаковый? зачем на каждый сервер класть на 90% одинаковую 10-гиговую C:\Windows? хорошо если это дешевый терабайтник. а если это пром. SSD или два SAS в зеркале, уже 20-30 евро на сетап каждого domu (или как они там называются у мелкомягких) просто выкинули на одну сраную папку.
могли бы поднапрячься и сделать какие-то контейнеры потоньше.
а линупсу — виртуализация нужна и еще как нужна. попробуйте поставить линукс на машину с 16 головами (да уже и на 8 всё прекрасно заметите), нафаршировать всякими HBA и запустить пару тяжелых java-приблуд или оракле. а потом включите mpstat и полюбуйтесь какие затыки по лоаду будут на паре-тройке голов, в то время как действительно, остальные будут тупо гонять NOPы в idle. вот за это да, за это я лёлекс не просто не люблю а можно даже сказать ненавижу. потому что этой недосистеме больше 4х голов на одно ядро давать противопоказано. а 4 головы — это нынче десктопный проц средней паршивости.
обхожусь соляркой и изредка линуксом.
у вас специфичный энтерпрайз.
в большинстве наблюдаемых мной контор 90% винды. и только в парочке 50% и меньше. и это еще что, тут регулярно попадаются решения, которые еще используются, но работают исключительно на какой-нибудь win98. вот и думай где такую железяку держать без виртуалок и как скоро она грохнется.
а вообще это конечно перевод гигабайт и гигагерц — зачем поднимать 5 машин в hyper-v которые крутят одинаковый NT-ячий кернель, если он действительно везде одинаковый?
оно там уже умеет не дублировать в памяти идентичные страницы.
просто в какой-то момент производительность процессоров заметно увеличилась, а типичные серверные задачи остались старыми, которым хватает ресурсов. почему бы их не уплотнить.
зачем на каждый сервер класть на 90% одинаковую 10-гиговую C:\Windows? хорошо если это дешевый терабайтник. а если это пром. SSD или два SAS в зеркале, уже 20-30 евро на сетап каждого domu (или как они там называются у мелкомягких) просто выкинули на одну сраную папку.
да ладно, мне и на внешней полке 10 г на бутраздел не жалко. не такие уж объемы.
полюбуйтесь какие затыки по лоаду будут на паре-тройке голов, в то время как действительно, остальные будут тупо гонять NOPы
да ерунда, я думаю допилят постепенно, с ростом количества многоядерных машин. я помню какие стенания были в начале века, на двухпроцовых и на первых гипертрейдинговых машинах. но годик-другой прошел — запилили…
>в большинстве наблюдаемых мной контор 90% винды
ну это удел совковых контор. когда винда была бесплатной, строили на ней инфраструктуры а теперь или выкупили или ныкаются.
>оно там уже умеет не дублировать в памяти идентичные страницы.
это не совсем одно и тоже. хотя конечно предсказуемое решение.
> просто в какой-то момент производительность процессоров заметно увеличилась, а типичные серверные задачи остались старыми
да почему остались старыми. в вебе с появлением «2.0» как они его называют — увеличился трафик на веб-сайтах, увеличился размер контента, увеличилась динамика. почты стало больше, voip гоняется, базы данных везде всё больше и больше, нагрузка на базы тоже увеличивается.
> да ерунда, я думаю допилят постепенно,
не допилят. мультипроцессорность или работает или ее нужно писать с нуля. а не пилить полуфабрикаты. тут кстате была пара популярных статей от интеля типа «8 ядер на камень — последний звоночек для пингвина», меня еще там люто, бешенно минусовали :)
ну это удел совковых контор. когда винда была бесплатной, строили на ней инфраструктуры а теперь или выкупили или ныкаются.
>оно там уже умеет не дублировать в памяти идентичные страницы.
это не совсем одно и тоже. хотя конечно предсказуемое решение.
> просто в какой-то момент производительность процессоров заметно увеличилась, а типичные серверные задачи остались старыми
да почему остались старыми. в вебе с появлением «2.0» как они его называют — увеличился трафик на веб-сайтах, увеличился размер контента, увеличилась динамика. почты стало больше, voip гоняется, базы данных везде всё больше и больше, нагрузка на базы тоже увеличивается.
> да ерунда, я думаю допилят постепенно,
не допилят. мультипроцессорность или работает или ее нужно писать с нуля. а не пилить полуфабрикаты. тут кстате была пара популярных статей от интеля типа «8 ядер на камень — последний звоночек для пингвина», меня еще там люто, бешенно минусовали :)
ну это удел совковых контор. когда винда была бесплатной, строили на ней инфраструктуры а теперь или выкупили или ныкаются.
сейчас уже почти у всех честное.
самое масштабное — около 20 серверных лицензий, включая шарепоит, экчендж и т.п., и семь-восемь сотен xp.
почты стало больше, voip гоняется, базы данных везде всё больше и больше, нагрузка на базы тоже увеличивается.
в вебе — да.
в типичной конторе на 100-300 юзеров за последние 5 лет ничего глобально не изменилось. ну почтовая база стала не 30 гигов, а 80. ну нагрузка на сеть/диски подросла. но по серверным задачам — почти все осталось как было. есть отдельные редкие задачи. есть отдельные отделы, типа дизайнеров. но это исключения, а не общая практика.
не допилят.
ну нет, так нет. мне пока все равно.
статью почитаю, что-то в тот раз времени не было.
Раньше были одни грабли, теперь появились другие, и неизвестно, которые из них бьют больнее.
Прекратите копипастить тексты маркетологов.
Про тонкие клиенты каждое второе утверждение совершенно не соответствует реальной действительности. не все так красиво как в брошюрках вендоров.
Про виртуализацию. Где Xen\KVM\OpenVZ? Почему рассмотрена вируализация только продуктов MS? Они меньше всего интересны в плане виртуализации.
Про тонкие клиенты каждое второе утверждение совершенно не соответствует реальной действительности. не все так красиво как в брошюрках вендоров.
Про виртуализацию. Где Xen\KVM\OpenVZ? Почему рассмотрена вируализация только продуктов MS? Они меньше всего интересны в плане виртуализации.
Прекратите копипастить тексты маркетологов.
Где Вы увидели копипасту? Я рассказывал то, что знаю сам, на собственном опыте.
Про тонкие клиенты каждое второе утверждение совершенно не соответствует реальной действительности. не все так красиво как в брошюрках вендоров.
Можно раскрыть тему подробнее?
Про виртуализацию. Где Xen\KVM\OpenVZ?
Я уже несколько раз написал, что я пишу о том, что знаю. То, что не знаю — не пишу. Буду рад, если Вы дополните мою статью.
Почему рассмотрена вируализация только продуктов MS? Они меньше всего интересны в плане виртуализации.
Еще раз: я пишу о том, что знаю и с чем работаю. Кроме этого, по-моему продукты MS интересны в этом плане ничуть не меньше, чем все остальные.
Даже не знаю с какого места начинать ругаться.
Во-первых, зачем-то удалённый доступ засунули в «виртуализацию представления» (да-да, из-под крана тёк чистейший дигидрид кислорода). Во-вторых совершенно нереальные цифры для терминальных служб. Как по трафику, так и по производительности.
В третьих чушь насчёт вирусов на флешах. Малейшая ошибка сисадмина, и «вирус на флеше» размножается уже на сервере. А ошибок там можно очень много сделать. Например, если в RSP прописать только исполняемые файлы, то kiddo прекрасно запустится, т.к. является библиотекой.
Насчёт «бежать и нажимать резет» реально смешно. Все сервера, даже 5-7 летней давности имеют impi, который позволяет и включить, и выключить и сделать кучу других вещей.
Я сегодня уж второй день как е#$%сь с xen cloud, и я хочу сказать, что если бы это не было моей основной работой, то послал бы я нафиг все эти заморочки.
Да, виртуализация имеет свои плюсы. Но это равноценный обмен: на возможность сказать xe vm-migrate host=other_node vm=my_virtual_machine --live вы получаете масштабнейший геморрой с администрированием уже xen'овских серверов (не дай бог сервера различаются по степпингу процессоров), вероятность, что засранец не только хакнет машину, но и вылезет в гипервизор (и уже есть примеры).
Про прелесть возни с hyper-v вообще говорить нечего, на этом фоне даже «шуточки» с xenconsole кажутся детским лепетом.
Виртуализация — это СЛОЖНО. Это требует тщательной балансировки (да, когда мы ставим ОДИН сервер на одно железо, то он имеет 10-кратный запас по производительности для пиков, если же мы на это железо пихаем гипервизор и пачку виртуалок, то малейший взбрык на одном сервере начинает страшно мешать соседям.).
До сих пор нет ни одного адекватного метода управления нагрузкой на диски. Ни у MS, ни у VMWare, ни у parallels, ни у quest, ни у citrix/xen, ни у прочих вендоров. Я на спор положу любой хост для сервера без NAS'а из-под рута с виртуальной машины. (Пять сотен рандомных операций чтения/записи малых блоков в секунду — и даже сказёвые рейды идут на йюх, включая соседей по виртуализации).
Я пока даже не говорю про растущую опасность ошибки, потому что одно неверное движение с бриджем/биндингом интерфейсов, и машины смотрят не туда или не то делают.
Чем больше критических для бизнеса сервисов в организации (а гипервизор для всех серверов — это явно не дёшево), тем больше денег надо платить сисадмину, и тем сложнее ему найти замену (и аутсорс не поможет, потому что там ТОЖЕ умеют считать деньги за работу).
Во-первых, зачем-то удалённый доступ засунули в «виртуализацию представления» (да-да, из-под крана тёк чистейший дигидрид кислорода). Во-вторых совершенно нереальные цифры для терминальных служб. Как по трафику, так и по производительности.
В третьих чушь насчёт вирусов на флешах. Малейшая ошибка сисадмина, и «вирус на флеше» размножается уже на сервере. А ошибок там можно очень много сделать. Например, если в RSP прописать только исполняемые файлы, то kiddo прекрасно запустится, т.к. является библиотекой.
Насчёт «бежать и нажимать резет» реально смешно. Все сервера, даже 5-7 летней давности имеют impi, который позволяет и включить, и выключить и сделать кучу других вещей.
Я сегодня уж второй день как е#$%сь с xen cloud, и я хочу сказать, что если бы это не было моей основной работой, то послал бы я нафиг все эти заморочки.
Да, виртуализация имеет свои плюсы. Но это равноценный обмен: на возможность сказать xe vm-migrate host=other_node vm=my_virtual_machine --live вы получаете масштабнейший геморрой с администрированием уже xen'овских серверов (не дай бог сервера различаются по степпингу процессоров), вероятность, что засранец не только хакнет машину, но и вылезет в гипервизор (и уже есть примеры).
Про прелесть возни с hyper-v вообще говорить нечего, на этом фоне даже «шуточки» с xenconsole кажутся детским лепетом.
Виртуализация — это СЛОЖНО. Это требует тщательной балансировки (да, когда мы ставим ОДИН сервер на одно железо, то он имеет 10-кратный запас по производительности для пиков, если же мы на это железо пихаем гипервизор и пачку виртуалок, то малейший взбрык на одном сервере начинает страшно мешать соседям.).
До сих пор нет ни одного адекватного метода управления нагрузкой на диски. Ни у MS, ни у VMWare, ни у parallels, ни у quest, ни у citrix/xen, ни у прочих вендоров. Я на спор положу любой хост для сервера без NAS'а из-под рута с виртуальной машины. (Пять сотен рандомных операций чтения/записи малых блоков в секунду — и даже сказёвые рейды идут на йюх, включая соседей по виртуализации).
Я пока даже не говорю про растущую опасность ошибки, потому что одно неверное движение с бриджем/биндингом интерфейсов, и машины смотрят не туда или не то делают.
Чем больше критических для бизнеса сервисов в организации (а гипервизор для всех серверов — это явно не дёшево), тем больше денег надо платить сисадмину, и тем сложнее ему найти замену (и аутсорс не поможет, потому что там ТОЖЕ умеют считать деньги за работу).
перегибаешь все же.
больше всего возилс с вмварью esx, так что скажу по ней.
ничего подобного тут нет. есть маска регистров процессора, которая выставляется по минимальной ноде. все виртуалки видят только минимальный процессор из имеющихся, несовместимостей нет, при миграции ничего не падает.
В вмвари — нет. Это просто. 99% никогда не полезет в консоль (хотя там можно сделать то же самое и чуть больше). Все делает в гуевой морде или на вебе.
При включенном DRS машинки тут же автоматом будут раскиданы по разным нодам, и пик пройдет более-менее мирно.
Опять же, все гуевое и понятное. Сделать что-то случайно не так — очень сложно.
Я просто не могу представить пример.
нагрузка в принципе видна, известны пути как ее смотреть, хотя балансеров готовых я не видел. с другой стороны я не пробовал «упереться в диск», возможно там есть механизмы по банальному замедлению черезчур активных пожирателей, что бы осталось время для остальных.
В общем про чрезмерную сложность и запутанность — ты не прав.
больше всего возилс с вмварью esx, так что скажу по ней.
вы получаете масштабнейший геморрой с администрированием уже xen'овских серверов (не дай бог сервера различаются по степпингу процессоров), вероятность, что засранец не только хакнет машину, но и вылезет в гипервизор (и уже есть примеры).
ничего подобного тут нет. есть маска регистров процессора, которая выставляется по минимальной ноде. все виртуалки видят только минимальный процессор из имеющихся, несовместимостей нет, при миграции ничего не падает.
Виртуализация — это СЛОЖНО.
В вмвари — нет. Это просто. 99% никогда не полезет в консоль (хотя там можно сделать то же самое и чуть больше). Все делает в гуевой морде или на вебе.
Это требует тщательной балансировки (да, когда мы ставим ОДИН сервер на одно железо, то он имеет 10-кратный запас по производительности для пиков, если же мы на это железо пихаем гипервизор и пачку виртуалок, то малейший взбрык на одном сервере начинает страшно мешать соседям.).
При включенном DRS машинки тут же автоматом будут раскиданы по разным нодам, и пик пройдет более-менее мирно.
Я пока даже не говорю про растущую опасность ошибки, потому что одно неверное движение с бриджем/биндингом интерфейсов, и машины смотрят не туда или не то делают.
Опять же, все гуевое и понятное. Сделать что-то случайно не так — очень сложно.
Я просто не могу представить пример.
До сих пор нет ни одного адекватного метода управления нагрузкой на диски. Я на спор положу любой хост для сервера без NAS'а из-под рута с виртуальной машины.
нагрузка в принципе видна, известны пути как ее смотреть, хотя балансеров готовых я не видел. с другой стороны я не пробовал «упереться в диск», возможно там есть механизмы по банальному замедлению черезчур активных пожирателей, что бы осталось время для остальных.
В общем про чрезмерную сложность и запутанность — ты не прав.
Слушай, ну если бы это маркетолог говорил, то вопросов бы не было. Но…
Если бы это писал маркетолог…
Раз:
bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1068
Два:
www.securityfocus.com/bid/39394
Дальше лень искать.
Раз:
bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1068
Два:
www.securityfocus.com/bid/39394
Дальше лень искать.
Во-первых, зачем-то удалённый доступ засунули в «виртуализацию представления»
Засунули, очевидно, за тем, что так и есть. Удаленный доступ — это когда админ удаленно заходит на сервер что-то подправить. А когда 100 пользователей работают с приложениями на сервере, получая только «картинку» — это уже виртуализация представлений.
Во-вторых совершенно нереальные цифры для терминальных служб. Как по трафику, так и по производительности.
Где именно «нереальные»? Все реально. При разрешении 800*600*8бит вполне реально работать даже через GPRS, а для 1С например — больше и не нужно.
В третьих чушь насчёт вирусов на флешах. Малейшая ошибка сисадмина, и «вирус на флеше» размножается уже на сервере.
Если явно не разрешено монтирование локальных дисков в терминальных сессиях — то флэшка, воткнутая в клиентский комп на сервере и не появится. А следовательно, и вирь с флэшки на сервер не попадет. А от кидо давно уже и патчи существуют, и нативири о них знают. К тому же в WS2008 групповыми политиками AD можно запретить флэшки вообще как класс, а так же политиками AppLocker запретить запуск любых приложений кроме разрешенных.
Насчёт «бежать и нажимать резет» реально смешно. Все сервера, даже 5-7 летней давности имеют impi, который позволяет и включить, и выключить и сделать кучу других вещей.
Ну, к примеру, в HP-шных серверах полноценный iLO с графической консолью и монтированием удаленного CD-ROM'а стоит денег. А виртуальные машины позволяют делать это бесплатно.
Я сегодня уж второй день как е#$%сь с xen cloud, и я хочу сказать, что если бы это не было моей основной работой, то послал бы я нафиг все эти заморочки.
Несколькими постами выше, Вы писали, что Xen Cloud — это мегарулез, по сравнению с которым Hyper-V просто отдыхает, и даже vSphere курит в уголке. По-видимому, это правда — если Вы второй день не можете заставить его работать как надо :)
вы получаете масштабнейший геморрой с администрированием уже xen'овских серверов (не дай бог сервера различаются по степпингу процессоров)
Вообще «правила хорошего тона» говорят, что все ноды в составе кластера должны иметь целиком и полностью идентичное железо.
вероятность, что засранец не только хакнет машину, но и вылезет в гипервизор
У vmware — было. У Hyper-V это сделать намного сложнее из-за микроядерной архитектуры гипервизора.
Про прелесть возни с hyper-v вообще говорить нечего, на этом фоне даже «шуточки» с xenconsole кажутся детским лепетом.
www.techdays.ru/videos/1439.html
Вот пример построения кластера под Windows Server 2008 R2 с Hyper-V и Live Migration. Где тут возня? Во всяком случае, двух дней секса тут точно не было.
Виртуализация — это СЛОЖНО.
Да ничего там сложного нет. Про сайзинг инфраструктуры писали все вендоры систем виртуализации — и vmware, и MSFT, и Citrix. RTFM, как говорится.
До сих пор нет ни одного адекватного метода управления нагрузкой на диски. Ни у MS, ни у VMWare, ни у parallels, ни у quest, ни у citrix/xen, ни у прочих вендоров.
Ваще-т этим железки должны заниматься — RAID-контроллеры и контроллеры СХД.
Пять сотен рандомных операций чтения/записи малых блоков в секунду — и даже сказёвые рейды идут на йюх, включая соседей по виртуализации
Пятистами iops'ами просадить дисковую на сервере? Е-мое, да самая завалящая MSA2000 с легкостью перенесет и более высокие нагрузки (в тысячу-другую иопсов) на одном контроллере. А контроллеров у нее два. Боюсь, 500 иопсов не просадит даже дерьмовенький adaptec с RAID10 из 4 SATA-дисков.
Я пока даже не говорю про растущую опасность ошибки, потому что одно неверное движение с бриджем/биндингом интерфейсов, и машины смотрят не туда или не то делают.
Наша служба и опасна и трудна, и на перый взгляд как будто не видна…
Чем больше критических для бизнеса сервисов в организации (а гипервизор для всех серверов — это явно не дёшево)
Зависит от сервисов и количества серверов. Гипервизор и два сервера вполне могут обойтись дешевле десятка серверов, а если там ПО Microsoft — то дешевле и по лицензиям.
тем больше денег надо платить сисадмину, и тем сложнее ему найти замену (и аутсорс не поможет, потому что там ТОЖЕ умеют считать деньги за работу).
Да, верно. Но это справедливо для любой системы, и виртуализация не особо систему усложняет, а я б сказал даже упрощает.
> Ваще-т этим железки должны заниматься — RAID-контроллеры и контроллеры СХД.
балансировку нагрузки на диски хорошо бы так же видет и гипервизору. потому что если он свалит на один стор слишком много прожорливых машин — плохо станет всем. store vmotion они уже большинство умеет, осталось привязать измерялку и переносить диски вируталок между сторами в зависимости от статистики. Ну или минимум — банально показать какая машина сожрала весь диск.
> Боюсь, 500 иопсов не просадит даже дерьмовенький adaptec с RAID10 из 4 SATA-дисков.
для недорогих полок 500 иопсов могут быть заметной нагрузкой. недавно приводились цифры от разработчиков СХД — 100 иопсов на винт saта, 150 sas. Можно больше, но время ответа растет непредсказуемо вверх.
балансировку нагрузки на диски хорошо бы так же видет и гипервизору. потому что если он свалит на один стор слишком много прожорливых машин — плохо станет всем. store vmotion они уже большинство умеет, осталось привязать измерялку и переносить диски вируталок между сторами в зависимости от статистики. Ну или минимум — банально показать какая машина сожрала весь диск.
> Боюсь, 500 иопсов не просадит даже дерьмовенький adaptec с RAID10 из 4 SATA-дисков.
для недорогих полок 500 иопсов могут быть заметной нагрузкой. недавно приводились цифры от разработчиков СХД — 100 иопсов на винт saта, 150 sas. Можно больше, но время ответа растет непредсказуемо вверх.
балансировку нагрузки на диски хорошо бы так же видет и гипервизору. потому что если он свалит на один стор слишком много прожорливых машин — плохо станет всем. store vmotion они уже большинство умеет, осталось привязать измерялку и переносить диски вируталок между сторами в зависимости от статистики.
Hyper-V, к сожалению, не умеет переносить виртуалки на другой стор без шатдауна. Во всяком случае — пока не умеет. Поэтому нужно заранее, при планировании инфраструктуры — размещать виртуалки так, чтобы нагрузка на один лун была минимальной.
для недорогих полок 500 иопсов могут быть заметной нагрузкой. недавно приводились цифры от разработчиков СХД — 100 иопсов на винт saта, 150 sas.
Боюсь, что пятьюстами иопсами можно положить только совсем уж недорогие полки. А приведенные цифры от разработчиков — это сферический конь в вакууме. Очень многое зависит от интерфейса (iscsi/sas/fc), от контроллеров полки, да и от самих хардов — контроллеры на них бывают разные, оборотистость разная. А бывают вообще диски вроде как SAS, а на самом деле — те же SATA только с SAS-чипом на плате. Еще очень многое зависит от типа операций (рандом, последовательно, запись, чтение) и разумеется — от типа массива.
Боюсь, что пятьюстами иопсами можно положить только совсем уж недорогие полки.
Полки — они все не дешевые. так что в большинстве фирм, которые таки перешли на СХД стоят entry level, это данность.
Да, у меня была возможность пользоваться XP 20000, но это исключение, по этому невысокие iops это то, что мы имеем сейчас в реальности. Давай исходить из этого.
А приведенные цифры от разработчиков — это сферический конь в вакууме. Очень многое зависит от интерфейса (iscsi/sas/fc), от контроллеров полки, да и от самих хардов — контроллеры на них бывают разные, оборотистость разная.
Самое узкое место — это как раз сами диски. Все остальное — контроллеры, транспорт значительно быстрее и не являются узким местом.
Вот голые цифры, которые дают винты на маленьких блоках (в худшем случае) которые используются сейчас для расчета сторов: «SAS 15k — 180, SAS 10k — 140, SATA 7200 — 80, SATA 5400 — 40». Это среднее по больнице, но инсайдеры утверждают, что девиации там не больше 5% в зависимости от производителя/модели.
То есть в простом случае, что бы получить 500 иопсов нам нужен рейд из 4-5 дисков, без redundancy.
Еще очень многое зависит от типа операций (рандом, последовательно, запись, чтение) и разумеется — от типа массива.
Конкретная производительность одного диска зависит от нескольких входных характеристик:
— размер блока (от 512 байт до мегабайт)
— тип обращения (соотношение чтение/запись)
— случайный, последовательный или смешанный доступ
— длительность (всплеск, устойчивая, переменная нагрузка)
— геометрия данных на диске (частичное, полное заполнение, внешний или внутренний край пластины, плотности записи, итп)
При последовательном чтении блоками по 512 Байт один диск может обслуживать до 800 IOPS (это предел процессора диска).
При многопоточном случайном чтении блоками по 8КБ можно достичь 280 IOPS
При многопоточном случайном чтении блоками по 64КБ можно достичь всего 240 IOPS (больше времени нужно на непосредственную передачу данных)
И далее, чем больше размер блока, тем меньше IOPS может выдать диск.
На практике, обычно используют вышеприведенные немного более консервативные значения. И дело тут во времени отклика.
Время отклика определяет, например, промежуток времени между операциями ввода-вывода одного пользователя (одного из многих потоков запросов). Если время отклика большое, то пользователи жалуются что невозможно работать, и «система тормозит». И им все равно, что система обслуживает 1000 таких как они, а суммарное количество выполняемых IOPS зашкаливает за 2000. Им важно что лично у них тормозит почта. Система работает на пределе возможного, но среднее время отклика 50-100 мс, субъективно «сервер работает очень медленно», а приложения постоянно «подвисают». Зато, когда нагрузка низкая, или пользователей мало, у них «все летает». Суммарное к-во IOPS не больше 200, зато время отклика 5 мс и к тому же стабильно. Значит «производительность хорошая». Однако, когда спрашивают про производительность дисков, все равно часто хотят услышать именно про IOPS-ы.
Чем выше максимум, тем лучше время отклика в нижней и средней части шкалы производительности.
При почти нулевой загрузке диска response time равно service time, которое является временем необходимым на выполнение одной операции без учета очередей.
При случайном доступе к данным, этот параметр вычисляется по формуле:
Service Time = Disk Rotational Latency + Average Disk Seek Time
что для диска 15К rpm дает 2мс + 4 мс = 6 мс
До тех пор пока очередей на диске нет (Utilization 0%), этот параметр сохраняется почти на одном и том же уровне.
Утилизация определяется соотношением нагрузки на диск к максимально достижимой производительности.
Utilization% = Current IOPS / Max IOPS
Чем ближе загрузка диска к максимально возможной, тем больше время отклика.
При 100% загруженности диска время отклика растет до бесконечности (т.е. растет очередь запросов, которые диск физически не может обслужить).
Формула связывающая response time, service time и утилизацию диска основана на законе обслуживания очередей (законе Литла) и опирается на факт, что диск может обслуживать только одну операцию в один момент времени (имеется ввиду традиционный механический диск). Response Time = Service Time / (1-Utilization%)
Например, для диска работающего в режиме многопоточного случайного чтения блоками по 8КБ со скоростью 140 IOPS (50% от предельных 280 IOPS на 8КБ блоках) среднее время отклика составит 6 мс/(1-50%)=12 мс.
В целом, процесс прецизионного расчета производительности СХД, хотя технически возможен, но достаточно сложен и должен учитывать множество нюансов. Поэтому, в первом приближении берутся вышеуказанные, рекомендуемые производителем показатели производительности для дисков разного типа.
to amarao
с уважением, коллега, во многом с Вами согласен. Маркетинг делает свое дело. Статья тому подтверждение.
с уважением, коллега, во многом с Вами согласен. Маркетинг делает свое дело. Статья тому подтверждение.
не рассмотрены юридические ограничения на виртуализацию!
Sign up to leave a comment.
Зачем же нужна виртуализация?