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