Плюсы и минусы виртуализации серверов приложения (AOS'ов) и, возможно, инфраструктурных серверов

[gl00mie]

Цитата:

Сообщение от fed

Об огромных экономических выгодах от виртуализации:
Встречаются два приятеля:
- Ты, я слышал, машину купил?
- Да, такая хорошая вещь, теперь все успеваю, представляешь, сегодня за день успел сменить масло, купить новые покрышки, поехал на авторынок за крыльями, сгонял в автосервис, поменял крылья, заехал в автомагазин за "Тосолом". И как бы я все это без машины успел?

Если кто еще не сталкивался с виртуализированными AOSами: На практике - экономия 1000 евро на сервере начального уровня для AOS, с лихвой перекрывается зарплатой специалиста по борьбе с граблями виртуализации.

Захотелось вынести это обсуждение из темы "анекдоты...", потому что, мне кажется, дело тут серьезное. Хотелось бы услышать мнение тех, кто как минимум пробовал работать с виртуализированными AOS'ами, т.е. не теоретиков, а практиков - не важно, на каком варианте (в виртуалке или на голом железе) установки AOS'ов вы остановились. Я могу сказать лишь, что:

• все доступные демо-версии 2009-й и 2012-й распространяются в виде виртуалок, хорошо это или плохо; мне этот вариант на нынешнем этапе кажется единственно верным;
• я лично работаю с виртуальными серверами примерно с 2006-го года, правда, сперва это никак к Аксапте не относилось;
• у меня лично опыт от использования виртуалок в большей мере положительный: есть некоторое падение производительности, есть проблемы (вполне себе разрешимые) одновременного старта на одном хосте зависимых виртуальных серверов, играющих разные роли, но возможность развернуть виртуалку практически везде, не заморачиваясь с мультизагрузкой, с особенностями железа (в вируталке все железо, кроме проца, стандартизировано), из-за смены которого винды приходилось зачастую переставлять с нуля, возможность перемещать виртуалку на другой физический сервер, в т.ч. в online, т.е. без перерыва в работе виртуалки, и очень гибко управлять ресурсами для меня лично покрывают минусы от некоторого проседания производительности.
• на нынешнем месте работы я во многом избавлен от решения вопросов администрирования, в т.ч. виртуализации серверов, поэтому не могу утверждать, что обладаю актуальным hands-on опытом работы с виртуалками в контексте названия темы.
• на счет цифр, а именно того, что якобы "экономия €1000 на сервере начального уровня для AOS с лихвой перекрывается зарплатой специалиста по борьбе с граблями виртуализации", могу ответить лишь, что сегодня €1000 - это по моим впечатлениям стоимость 2-4 недель работы нормального сисадмина без особой сетевой/БД специфики, не фонтан как много. Но возможность назначить серверу объем оперативки с гранулярностью до 4 Мб, возможность выделить 1-2-4-6-8 ядер, а не все, что есть в наличии на том или ином физическом сервере, возможность перемещать виртуалку между физическими серверами в любой момент... впрочем, я повторяюсь. Кроме того, любому нормальному админу в любом случае приходится решать такие вопросы, как создание новых серверов-клонов для уже существующих, резервное копирование и поддержание работоспособности ферм серверов. Раньше для этих целей годился какой-нить Norton Ghost или Acronis Backup & Recovery, но из моего скромного опыта если на компе меняется материнка, винды не заведутся - надо будет либо долго и мучительно возиться с ними, либо просто переставлять с нуля. Виртуалки, опять же, этого недостатка лишены, потому что там используется некое стандартизированное железо (кроме проца). Таким образом, лишняя €1000 при покупке хост-сервера для виртуалок может с лихвой окупиться на их поддержке за счет того, что можно будет не задумываться над тем, на какой именно материнке работает сервере, на каком числе процов и объеме памяти, и спокойно при необходимости "клонировать" его или перемещать на другой физический сервер ради банальной балансировки нагрузки.

В общем, это - мои соображения касаемо виртуализации. Хотелось бы услышать мнение тех, кто также занимался этими вопросами: стоит ли оно того (речь именно о серверах приложения и инфраструктурных серверах - не серверах БД или любых прочих) и почему именно.

[gl00mie]

PS. В настоящее время все сервера приложения AX 2009 (рабочие, разработческие, тестовые) и часть инфраструктурных (те же терминальные сервера) в моем случае виртуализированы.

[fed]

Я раза 3-4 сталкивался с виртуализацией, когда меня звали бороться с проблемами производительности у клиента. Надо заметить, что сама по себе, виртуализация никогда не была причиной проблем, но всегда добавляла мне работы. Дело в том, что средне-статистический клиентский админ очень плохо понимает как эта виртуализация работает, даже на очень базовом уровне (сам я отнюдь не специалист по VMWare). Просто на каждом клиенте мне приходилось админу рассказывать о том, что в виртуализованной среде не очень правильно мерять загрузку процессора в task manager виртуализованной винды, а надо смотреть то, сколько виртуалке выделяется ресурсов в мониторе самого VMWare. Самое смешное, что обычно админы про этот монитор знают, но все равно продолжают контроллировать загрузку по task manager. Еще достаточно типичная ситуация - AOS и SQL Server живут на одной физической машине, однако админ не догадывается поднять виртуальный сетевой адаптер, и весь трафик гоняется по реальной сети, а не внутри памяти между двумя компами. Ну и так далее..

То есть - мне рекламные листовки вендоров виртуализации очень напоминают рекламные листовки SAP vs Axapta. В SAPе очень, очень много интересной и богатой функциональности, которая в бэттлкарде очень красиво переигрывает Аксапту или 1c. Но при попытке внедрения этой интересной и богатой функциональности, клиент наталкивается на человеческий фактор. Вдруг выясняется что людей, которые эту богатую функциональность знают и понимают - почти что не существует в природе, а реальные консультанты, которых удалось нанять, не особо понимают все эти замечательные функции. Вот и с системами виртуализации точно также. Они, в принципе, имеют массу преимуществ, которые в теории могут принести большую выгоду от их использования. Однако, на практике, среднестатистический админ, который одной рукой поддерживает сервера, другой ищет пользователю клавишу anykey, а третьей - чего-то курочит в 1совской конфигурации, потому что 1совец в отпуске - не в состоянии толком разобраться в системе виртуализации и в его руках она скорее принесет больше вреда чем пользы...

Теперь немножочко об уровне цен: В Европе приличный специалист (приходящий консультант) стоит от 900 до 1200 Евро в день (На коротких проектах конечно. Но проекты по настройке производительности и не бывают длинными). В Турции - где-то 700-900 долларов в день. В России - вероятно поменьше чем в Турции, но все равно - день работы специалиста сопоставим со стоимостью сервера начального уровня.
Если говорить о внутренних спецах - да - они подешевле конечно, но во первых ты в своих рассчетах забываешь про налоги и накладняк, во вторых - клиенту вообще не очень выгодно держать в штате специалиста высокого уровня, потому что не хватит работы, чтобы его полноценно загрузить. Поэтому, борьба с проблемами производительности (все равно в чем в Аксапте или в VMWare) - это удел приходящих консультантов.

Вообще раздумывая над темой виртуализации, я вижу очень узкую нишу применения виртуализованных серверов. Ну то есть - виртуализация серверов начального уровня - типа AOS - это экономия на спичках. Не тот порядок экономии на железе, чтобы вообще замарачиваться. Гораздо интереснее было бы виртуализовать большое и дорогое серверное железо. Ну например - если мы купили сервер тысяч за 150, то, возможно, было бы интересно использовать его не только по прямому назначению (сервер БД на 600 человек), но и подселить туда вирталку, например, корпоративного sharepoint. Возможно, в данном случае, экономия на стоимости железа была бы более выгодной. Однако - во первых - день простоя SQL Server на 600 человек, обойдется гораздо дороже потенциальной экономии на железе. (Ты наверное помнишь про принцип биплана - самолет с двумя крыльями ломается в два раза чаще чем с одним крылом). Во вторых - я не уверен что при большой и пиковой нагрузке (600 юзеров при закрытии года это тебе не хухры мухры), гипервизор сможет нормально распараллелить нагрузку между двумя или тремя виртуалками.
На мой взгляд, единственное разумное применение систем виртуализации - это, условно говоря, сервер айти-службы. Купили айтшники себе сервер средней руки (тонн за 12-15 например), наставили туда 30 виртуалок и работают. Надо на этой неделе под OLAP поразрабатывать - подняли виртуалку с OLAP, сделали свое дело - опустили. Тормозит - не страшно (это не боевой сервер с реальными пользователями), глючит - обзовнили айтишников и через полчасика перегрузили вообще весь сервер со всеми виртуалками.

На мой взгляд, виртуализация - это еще один пример ложного технического прогресса, когда очередная нишевая технология ограниченной применимости, с помощью маркетинговой раскрутки выдается за технологический прорыв и втюхивается клиентам как обязательная к применению. Причем поскольку сейчас многие клиенты уже обвиртуалились и продать ту же туфту второй раз им уже не получится, ожидается новая волна отъема денег у клиентов, на сей раз под лозунгом "Облаков" и перемещения виртуалок из серверной клиента в Центры Обработки Данных. И через пару лет, когда я приеду бороться с аксаптовской производительностью, я выставлю клиенту еще большую сумму за почасовку, поскольку мне придется потратить время не только на борьбу с аксаптой и обучение клиентских адинов основам мониторинга производительности, но и на звонки тем индусам, которые это облако поддерживают...

P.S. У нас (на моем основном месте работы) сейчас три пользовательских AOS и два батч-сервера. Один батч и один AOS - виртуализированы. В принципе - работают без больших проблем, только почему-то на виртуализованном AOS при попытке включении трассировки AOS, очень часто теряются события. Сложилась такая странная конфигурация еще до того как я на проект пришел. Когда я спросил - почему так ? Админы мне ответили: А у нас в начале было много проблем с AOS (Вероятно - из за того что древняя версия ядра использовалась) так что мы когда с глюками боролись - переставили два AOS с виртуальных серверов на реальные. А оставшиеся два сервера тогда были тренировочными, мы их так на виртуалках и оставили. Ну а потом когда в боевую конфигурацию их включили попозже - они так и остались виртуальными. Очень показательная история про виртуализацию - не правда ли ?

[mazzy]

Цитата:

Сообщение от fed

На мой взгляд, виртуализация - это еще один пример ложного технического прогресса, когда очередная нишевая технология ограниченной применимости, с помощью маркетинговой раскрутки выдается за технологический прорыв и втюхивается клиентам как обязательная к применению.

не согласен.
про виртуализацию и облака я так понимаю

Цитата:

Сообщение от mazzy

изначально было: 1 железка - 1 логический сервер (с кучей сервисов в нем)
виртуализация: 1 железка - несколько логических серверов (с кучей сервисов в каждом)
облако: несколько железок - несколько логических серверов

причем каждый логический сервер может "переползать" на другие железки без перенастройки (скорее всего в заивисимости от нагрузки).

просто мы в середине процесса.

а потом будет еще что-нибудь...
такова жизнь.

Цитата:

Сообщение от fed

...Админы мне ответили
...Очень показательная история про виртуализацию - не правда ли ?

Дык... Она не только про админов.

раньше любую машину в любом месте мог чинить любой механик.
теперь нужны спецы по конкретным моделям. и даже внутри одной модели бывают специализации.
это не то чтобы дешевле. так удобнее.

а история действительно показательная.
история показывает, что с потребительской точки зрения - что виртуализаированные, что реальные сервера - одно и то же
естественно, что с точки зрения специалиста - это две большие разницы.
но платит то потребитель.

[Maxim Gorbunov]

Цитата:

Сообщение от mazzy

изначально было: 1 железка - 1 логический сервер (с кучей сервисов в нем)
виртуализация: 1 железка - несколько логических серверов (с кучей сервисов в каждом)
облако: несколько железок - несколько логических серверов

причем каждый логический сервер может "переползать" на другие железки без перенастройки (скорее всего в заивисимости от нагрузки).

Справедливости ради, "несколько железок - несколько логических серверов" - это называется распределённая инфраструктура. Она может использоваться в реализации облака, а может и не использоваться. В облаке всё же в основном уже оперируют понятием приложения, а не логического сервера.

[mazzy]

Цитата:

Сообщение от fed

И через пару лет, когда я приеду бороться с аксаптовской производительностью, я выставлю клиенту еще большую сумму за почасовку, поскольку мне придется потратить время не только на борьбу с аксаптой и обучение клиентских адинов основам мониторинга производительности, но и на звонки тем индусам, которые это облако поддерживают...

очень хорошая иллюстрация. включая индусов
dynamics-community.at: Was hat ein fahrender Schreibtisch auf der Mariahilfer Strasse zu bedeuten? My Office is were I am

честно - я не нарочно.

[gl00mie]

Цитата:

Сообщение от fed

Я раза 3-4 сталкивался с виртуализацией, когда меня звали бороться с проблемами производительности у клиента...

Если немного перефразировать сообщение, получаются такие минусы:

• недостаточная квалификация администраторов, неопнимание базовых принципов работы виртуализации препятствуют оптимальной настройке виртуалок и корректному мониторингу их загрузки;
• виртуализация осложняет (а в случае привлечения сторонних консультантов - еще и удорожает) решение проблем с производительностью;
• стоимость решения дополнительных проблем с производительностью, вызванных использованием виртуализации, может быть сопоставима с покупкой дополнительного сервера начального уровня;
• виртуализация больше подходит для серверов с низкой средней загрузкой и в меньшей степени - для "боевых" серверов с высокой пиковой загрузкой

В принципе, по-моему, эти аргументы как раз характерны для сторонних консультантов, приглашаемых для "тушения пожаров" и не занимающихся ежедневным обслуживанием серверов С точки же зрения ежедневной рутины (у меня есть некоторый опыт в этом плане) виртуализация позволяет:

• выделять на каждую роль (скажем, почтовый сервер, доменный контроллер, сервер активации ПО и т.п.) в пределе - собственный отдельный виртуальный сервер; в общем случае это намного удобнее и надежнее, чем вешать кучу ролей на один логический сервер (вспоминая тот же "эффект биплана");
• облегчить настройку резервного копирования серверов: конфигурационный файл и образ диска виртуального сервера можно скопировать, не останавливая сам сервер;
• существенно упростить развертывание инфраструктуры в новых офисах/филиалах/подразделениях: вместо кучки физических серверов в новом офисе можно поставить 1-2-3 физических сервера, на 1-2 из которых развернуть кучку виртуальных серверов с необходимыми ролями. При этом под каждый виртуальный сервер можно выделить минимум физических ресурсов, при необходимости постепенно увеличивая их по мере разрастания филиала;
• ощутимо упростить поддержку удаленных офисов: если нужно переконфигурировать сервер, переустановить ОС или еще что, то не нужно выезжать на место - достаточно иметь удаленный доступ к серверу, на котором крутятся виртуалки;
• более гибко управлять доступными аппаратными ресурсами: если на сервер выросла нагрузка, можно легко добавить ему процессорных ядер, памяти, места на диске, ради этого можно легко и просто "выселить" часть виртуальных серверов на другой хост; если нагрузка на сервер невелика, ему можно выделить всего одно виртуальное ядро (причем физически еще и разделяемое с другими серверами), урезать память, скажем, до 200-300 Мб и т.п. С физическим сервером такое не пройдет.
• обходить определенные ограничения по масштабируемости в случае тех же терминальных серверов: при одновременной работе, скажем, 80-и терминальных сессий (5-7 процессов в каждой, из которых обычно лишь один - непосредственно нужная пользователю программа) в виндах выполняется порядка 4-5 тысяч потоков, и с ростом их числа независимо от количества процессорных ядер винды уже просто хуже начинают распределять процессорное время между ними, т.е., скажем, 160 сессиям на 12 процессорных ядрах будет работаться куда менее комфортно, чем 80-и на 6-и ядрах. Выход тут простой: на одном большом сервере запустить несколько виртуальных терминальников и распределить имеющиеся ресурсы и нагрузку между ними.
• разумеется, экономить на серверах: можно купить "взрослый" сервер с резервным блоком питания, пачкой дисков в RAID-массиве, приличным объемом оперативки, которую можно добавлять на лету, несколькими многоядерными процессорами - и запускать на нем кучу виртуальных серверов, под каждый из которых денег на приличный надежный сервер просто не дадут. У буржуев ко всему этому еще добавляется экономия на электроэнергии и месте в ЦОДе.

Что касается виртуализации именно AOS'ов той же AX 2009: да, появилась 64-битная версия, да, за счет перехода на другую библиотеку работы с динамически выделяемой памятью и на обслуживание сессий рабочими потоками подсистемы RPC AOS, возможно, стал намного лучше масштабироваться, однако, он и легче стал валиться, а когда из-за одного глюка отваливается разом сотня-другая клиентских сессий, это как-то... неприятно. Поэтому на внедрениях с большим числом одновременно работающих пользователей хотя бы с точки зрения отказоустойчивости интереснее бывает иметь несколько AOS'ов на 70-90 сессий каждый, нежели один AOS, на котором работают все-все-все плюс еще и пакетные задания крутятся. И опять же, как наиболее гибко распределять ресурсы между AOS'ами? За счет все той же виртуализации...

[fed]

Цитата:

изначально было: 1 железка - 1 логический сервер (с кучей сервисов в нем)
виртуализация: 1 железка - несколько логических серверов (с кучей сервисов в каждом)
облако: несколько железок - несколько логических серверов

причем каждый логический сервер может "переползать" на другие железки без перенастройки (скорее всего в заивисимости от нагрузки).

То есть - Облако становиться выгодным в основном (или только) в случае сильно (то есть - не в два раза, а раз 5-10) и часто изменяющейся нагрузки на систему. Что, по моему опыту,случается не часто и вполне подпадает под термин "нишевое применение". Даже если рассматривать случай с нормальной работой и "закрытием года" нагрузка отличается раза в 2-2.5, что дешевле решить с помощью покупки железа с запасом, чем с помощью принципиального изменения технологической платформы.

[mazzy]

Цитата:

Сообщение от fed

То есть - Облако становиться выгодным в основном (или только) в случае сильно (то есть - не в два раза, а раз 5-10) и часто изменяющейся нагрузки на систему.

почему же часто?
достаточно и одного раза
ты же сам пишешь...

Цитата:

Сообщение от fed

Однако - во первых - день простоя SQL Server на 600 человек, обойдется гораздо дороже потенциальной экономии на железе.

если в результате облачной технологии
удасться хотя бы один два-раза избежать "простоя SQL Server на 600 человек" то оно уже себя окупает.

повторюсь: я воспринимаю "облако" вовсе не как технологию отдачи данных куда-то к провайдеру или "перемещения виртуалок из серверной клиента в Центры Обработки Данных".

я воспринимаю "облако" как технологию, которая позволит размазывать логический сервер по нескольким физическим машинкам. Где бы они ни находились - хоть у меня на кухне.

просто технологически обслуживание таких физических машинок проще будет отдать специалистам (тому же провайдеру).
как тот же аксфорум: технологически я могу разместить сервер где угодно, хоть у себя дома, хоть в офисе. но чтобы обеспечить доступность 24х7 я предпочитаю разместить его у провайдера. Но вполне отдаю себе отчет, что в некоторых случаях я бы ни за что не отдавал данные никакому провайдеру, а огранизовал бы режим доступности 24х7 у себя.

[mazzy]

Цитата:

Сообщение от mazzy

==============
в этой технологической благодати сразу возникают вопросы лицензирования и ценообразования.
даже если посмотреть на текущие виртуальные машины, то там предустановлено ПО на туеву хучу денег.

с одной стороны, хорошо иметь изолированные кластера ПО: отдельно для Аксапты, отдельно для биллинга, отдельно для фронт-офиса... Но ведь в каждом кластере будет свой Windows сервер, свой SQL, свой IIS, свой SharePoint, свой офис и т.п. Тут придется либо схему лицензирования менять, либо одно из двух. Менять схему лицензирования в Майкрософте дело настолько тяжелое...

Поэтому мне кажется, что с точки зрения сбора денег, первым провайдером будет сам Майкрософт. В этом случае они могут собирать деньги за "просто аренду". Не заморачиваясь с реальным ценообразованием по текущей схеме лицензирования.

да, и вполне отдаю себе отчет что первые предлагальщики этой технологии постараются снять сливки по-максимуму, выдаивая первых клиентов по-черному.
ничего не ново под луной.
так было с появлением первых телеграфных аппаратов
так было с появлением первых телефонов (проволочных)
так было с появлением первых телевизоров
так было с появлением первых компьютеров
так было с появлением первых мобильных телефонов

будут дичайшие предложения и на рынке облачных технологий.
но потом муть устаканится, а технология останется.

[egorych]

Добавлю свои 5 коп.
Сейчас у меня виртуализированы 4 АОСа (Ax3) - в кластере, ограничение по 50 клиентов. Проблем нет никаких (тьфу*3). Спокойно все поставилось - не вижу никаких проблем с VMWare для вменяемого админа.
Когда я начинал заниматься виртуалками, принцип был такой - если реальная машина занимает около 40% процессора (в среднем) - смысла в виртуализации нет.
Еще один небольшой + к виртуалкам - чтобы разместить 5 реальных компов нужен приличных размеров ящик, 4 упса+жменя проводов+5 портов свича. Сейчас это все хозяйство стоит на 1-юнитовом севере, с 1 упсом - реально удобней.

[Poleax]

Цитата:

Сообщение от fed

Еще достаточно типичная ситуация - AOS и SQL Server живут на одной физической машине, однако админ не догадывается поднять виртуальный сетевой адаптер, и весь трафик гоняется по реальной сети, а не внутри памяти между двумя компами. Ну и так далее..

вот cо слова "далее" поподробнее...

Цитата:

Сообщение от gl00mie

В общем, это - мои соображения касаемо виртуализации. Хотелось бы услышать мнение тех, кто также занимался этими вопросами: стоит ли оно того (речь именно о серверах приложения и инфраструктурных серверах - не серверах БД или любых прочих) и почему именно.

VMware юзаем, но видимо они больше подходят для различных тестов или для не требовательных задач (у нас к примеру Batch сервер шуршит на VM)

[-]
Пиковый производительности не стоит ожидать. VM конкурируют за ресурсы.
VM периодически приходится перезагружать. Был нюанс с VMware AOS Ax2009 SP1 RU6 слопал 7Гб. Решение автоперезагрузка сервера раз в неделю.
Иногда при создании snapshot(a) сеть может отвалится на несколько десятков секунд

[+]
Радует скорость создания нового сервера админом.
VM проще восстановить из snapshot. VM мобильны между физ. серверами.(в реальном времени)
Можно изменить кол-во CPU, ОЗУ и т.д.

Имхо для боевой аксапты лучше использовать физ. сервер.

[gl00mie]

Цитата:

Сообщение от Poleax

VMware юзаем, но видимо они больше подходят для различных тестов или для не требовательных задач. Пиковый производительности не стоит ожидать. VM конкурируют за ресурсы.

Интересно, а Hyper-V приходилось использовать? На буржуйских форумах пишут, что у них, у буржуев, в доморощенных сравнительных тестах производительность на Hyper-V ощутимо выше, чем на VMware.

[egorych]

Цитата:

Сообщение от gl00mie

Интересно, а Hyper-V приходилось использовать? На буржуйских форумах пишут, что у них, у буржуев, в доморощенных сравнительных тестах производительность на Hyper-V ощутимо выше, чем на VMware.

Я тестил - у меня получилось ровно наоборот (причем ощутимо), но правду сказать было это года 2 назад - наверняка что-то поменялось.
Опять-же по ссылке не ясно какую VMWare они брали - Server или ESXi - 2 большие разницы.

[Vadik]

Цитата:

Сообщение от gl00mie

Интересно, а Hyper-V приходилось использовать?

Приходилось

[fed]

Вообще, в очередной раз перечитывая в теме копипасты маркетингового баллшита про виртуализацию и облака, пришел к выводу, что термин fashion victim явно требует скорейшей адаптации к сфере айти-технологий...

[Удвой Покуров]

Сергей, коллеги. Вы забываете об истинном предназначении "облаков"- максмальной утилизации "железа". Лучше всего они работают на массовом рынке: днем все сидят в мордокниге.рф / одноклассниках, вечером - качают порно / торчат в ВОВ. Тогда да, утилизация приближена к оптимальной. На "рабочих" серверах очень сложно добиться такой загрузки... Только если днем - работают, вечером - выполняют периодические операции, перестраивают кубы или считают что-нибудь глобальное, типа тестируют косметику/ рассчитывают аэдинамику кокпита/ ищут лекарство против рака/ моделируют ядерный взрыв. Не очень частые задачи, надо отметить. Еще преимущество: office anywhere, но при чем тут облако?

[gl00mie]

Исчерпывающе! А есть что сказать по этому поводу в контексте данной темы?

[Vadik]

Цитата:

Сообщение от gl00mie

А есть что сказать по этому поводу в контексте данной темы?

Виртуализация imho штука однозначно полезная и нужная (но не всем). Пример:
- На прошлом месте работы большинство некритичных к производительности (перефразирую - тех, где не было необходимости выжимать последнее из возможностей железа) или продублированных серверов были виртуализированы (собственно, виртуализация как раз и дала возможность добавить избыточности во многие сервисы) . ЖилО все это на паре блейд-центров, железа хватало и вопросы типа "выделить новую машину с такими-то спеками", "забэкапить эту машину на всякий пожарный", "это приложение (и VM) выпускаем в production - добавить виртуалке ресурсов", "этот хост надо перезапустить или он тормозит - перенести временно виртуалки на другой" решались в рабочем порядке (в течение нескольких часов - одного дня)
- На нынешнем месте работы с железом все хуже (достаточно давно покупалось и апгрейдиться будет все сразу, а до этого будет согласовываться-утверждаться), физически недоступно (пять часов лету) и обслуживается чужими людьми, бизнес-приложений (много самописных) - пара десятков, под каждое по-уму надо выделить свои DEV\TEST\PROD среды, в идеале - изолированные. Малейшее телодвижение требует такого количества проверок-согласований, что гори оно все синим пламенем. Совершенно понятно (с) - первое, что лично я буду проталкивать по мере приближения апгрейда - это виртуализация

Цитата:

Сообщение от egorych

Когда я начинал заниматься виртуалками, принцип был такой - если реальная машина занимает около 40% процессора (в среднем) - смысла в виртуализации нет

+1

Я в принципе готов согласиться с формулировкой fed "поставили сервер, на нем 30 виртуалок - и работают", если ее экстраполировать до "поставили 10 серверов и на них держим 40 приложений \ сервисов, готовы в течение пары суток захостить еще 20". В меньших масштабах - подумайте, а не из пушек ли это по воробьям ?

[gl00mie]

Тут в VMware обнаружилась одна очень полезная особенность, связанная с тем, как для гостевой ОСи представляются виртуальные процессоры. Применительно к физическому железу принято различать сокеты (т.е. физически отдельные процы) и ядра, потому что на одном физическом сокете может быть несколько ядер. И еще, как известно, некоторый софт лицензируется именно по количеству сокетов, которые он может использовать. Так вот, VMware позволяет представлять для гостевой ОСи N виртуальных процессоров не только как N одноядерных сокетов, но и как M сокетов по N div M ядер в каждом!
Что это дает? Ну вот, к примеру, есть у вас некий сервер с 8-ю процами по 4 ядра на каждом, и хотите вы на этом сервере запустить в виртуалке некое виндовое серверное приложение, предоставив ему максимально возможное количество ядер. Для использования более чем 4-х виртуальных ядер в общем случае понадобится ставить в виртуалке Enterprise-версию виндов, которая стоит так нефигово, при том что приложение может не использовать никаких служб и ролей этой версии виндов. В то же время, в VMware можно сконфигурировать виртуалку так, что ОС будет видеть 4 сокета из имеющихся 8-и по 4 ядра в каждом - 16 ядер; более того, на указанном сервере можно даже предоставить гостевой ОСи 4 сокета по 8 ядер, 2 по 16 или 1 сокет с 32-я ядрами (последние версии VMware поддерживают до 32-х ядер на виртуалку). В этом случае в качестве гостевой ОС можно уже использовать обычный Windows Server Standard. Аналогичный финт ушами можно провернуть, скажем, с Ms SQL Server, имея процессорные лицензии на последний...
По поводу возможностей представления виртуальных ядер для гостевой ОСи как нескольких многоядерных сокетов см., например, эту статью http://www.vcritical.com/2009/09/use...-socket-count/ Насколько мне известно, Hyper-V всегда представляет виртуальные процы как одноядерные сокеты.