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

[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'ами? За счет все той же виртуализации...