Зачем нужна Виртуализация? Что привнесла в современный мир?

[nicky-boom.livejournal.com]

Современный мир информационных технологий немыслим без Виртуализации "всего на свете" - серверов, операционных систем(ОС), сетевых плат(NIC-карт)-(Xsigo), дисковых массивов(NAS,RAID)-(HDS - Hitachi Data Systems).
Однако, мало кто задумывается над тем, что именно привнесла виртуализация в современный IT, и в чём на самом деле её недостатки, а где именно - достоинства.



Начать можно с того, что оказывается было нужно, чтобы появился термин паравиртуализация, который ничего специфического не означает, а лишь описывает некоторую подгруппу виртуализации, в которой исходный код гостевых ОС(тех, которые виртуализируются) был изменен таким образом, чтобы по предоставленному API(законченному набору функций) она могла обращаться к главной ОС(так называемой Хостовой) машине в случае наиболее неотложных операций(выделение памяти, страничный обмен, прерывания от внешних устройств, специфические функции отдельных приложений, требующие максимум hardware-ресурсов за короткий промежуток времени).
Паравиртуализация понадобилась неспроста, так как общеизвестно, что любая программа выполняется в виртуальной машине заведомо медленнее, чем на реальной физической hardware машине(сервере). Происходит это потому, что в виртуальной среде имеется дополнительный "слой", через который гостевая машина обращается к хостовой для выпонения любых операций и невозможно каким-либо образом исключить этот "избыточный" слой задержки. Так вот, придумали, что в случае таких "критических" операций на гостевой ОС - они (операции) передаются по прерыванию в главную хостовую машину и выполняются там, что позволяет значительно ускорить гостевую ОС.


Кроме того, широко обсуждается "мобильность" целой гостевой ОС, то есть возможность миграции(или переноса) по локальной или глобальной сети целой виртуальной машины(или аналога физического сервера), представленной в случае виртуализации в виде всего одного файла .VMDK, правда размером более чем несколько гигабайт. А что именно даёт такая мобильность?

Кроме достоинств, связанных с DR(Disaster Recovery-восстановление после пожара,стихийного бедствия) и BackUp(восстановление на случай кратковременного сбоя), сопряжена такая мобильность и с риском потери именно той актуальной копии данных, которая может понадобиться в любой момент. Другими словами, можно запутаться где именно что - поскольку копий виртуального сервера стало более одной, неизвестно в чём отличие одной от другой, и где наиболее "свежая".  Тот, кто хоть немного имел дело с виртуальными машинами и их "резервным копированием" - поймет, как это легко - запутаться в их множестве и/или актуальности на определенный момент в прошлом или будущем.



Вдобавок, существует целый класс серверных приложений, которые нуждаются в Кластеризации. Например, Oracle Grid - кластер из нескольких физических серверов для "распараллеливания" нагрузки на базу данных с одного - на несколько физических серверов.
Не приходится говорить, что не любую ОС возможно паравиртуализировать из-за закрытости кода например, и не все приложения нуждаются в виртуализации, есть такие, которые скорее наоборот хотят "больше есть hardware", чем быть виртуализированными.




Вообще, сложилось у меня впечатление, что виртуализация может быть оправдана(или обусловлена) лишь наличием legacy-hardware(унаследованное железо) и inherited-software(доставшийся в наследство софт). Причем, серверное программное обеспечение, как правило, менее нуждается в виртуализации, в сравнении с настольным ПО, так как оно легко комбинируется в виде NT-сервиса или Unix-процесса (устанавливается с другими приложениями на одном и том же физическом сервере). Зачем же тогда его виртуализировать, заранее предполагая потерю его производительности, связанную с выполнением в виртуальным домене, в котором всё эмулируется - память, процессор, жёсткий диск, сетевая плата?

Comments

[vpluto.livejournal.com]

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

Во-первых, виртуализация - это далеко не только для виртуализации ОС. Виртуализация процессов, приложений и пользовательских сред - это тоже виртуализация.

Во-вторых, главная цель виртуализации - предоставление виртуальному объекту универсального, не зависящего от используемой аппаратной платформы HAL. Что, как ни парадоксально это будет для автора, в некоторых случаях увеличивает итоговую производительность виртуализованного программного комплекса относительно запуска его на той же аппаратной платформе - особенно это касается старых ОС с их крайним разнообразием в качестве и производительности драйверов специфического железа и отсутствием эффективных алгоритмов дискового кэширования. Известный еще со времен VmWare 3 кейс с работой виртуализованного MS SQL на определенной аппаратной платформе с производительностью 110-112% от запуска его на той же аппаратной платформе без VmWare - далеко не единственный пример (и да, для современных MS SQL и VmWare уже не срабатывает - так 97-98% в пике и добиваются).

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

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

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

Короче, виртуализация и облачные среды - это сейчас основной инструмент квалифицированного ИТ-специалиста в области серверных систем и систем хранения. Автору имеет смысл разобраться в теме глубоко, не на уровне переписки в комментариях комьюнити.

[whiteelk.livejournal.com]

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

[vpluto.livejournal.com]

Ну да, согласен, сам изначально попенял автору, что он сужает виртуализацию до виртуализации серверов, а к концу комментария сам скатился в то же :)

С другой стороны, с этим примером есть нюанс, который хочется отметить.

В жизненном цикле любых систем можно грубо выделить следующие кучки специалистов:
1) разработчики компонентов - для систем общего назначения это серверные платформы, СХД, сетевое оборудование и т.д.
2) разработчики систем, архитекторы - это те, кто из компонентов собирает систему под конкретную задачу
3) администраторы систем - обеспечивающие функционирование этой системы после внедрения
4) пользователи систем - это, для случая виртуализации, например, разработчики/инсталляторы/администраторы гостевых операционных систем

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

А в случае узкоспециализированных решений, как то виртуализация внутри физической связной ноды из примера (да и что далеко уходить от ИТ - виртуализация инстансов коммутаторов в тех же Cisco Nexus) - задачи виртуализации закрыты на уровне разработчика компонентов, вендора. Т.е. там я бы разложил знания по категориям как 80-10-9-1. Архитектору систем в этом случае, как администратору и пользователям, нет разницы, виртуальные у него ноды или физические - это сказывается только на том, что нужно закупить для решения задачи меньшее количество физических коробок. Т.е. ИТ-специалисту в этом случае не нужно глубоко погружаться в тему, если он не работает на производителя компонентов.

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

[nicky-boom.livejournal.com]

Всё это хорошо и даже отлично замечено и написано.

Однако, я бы попросил вас по-возможности расшифровывать прямо в тексте(можно в скобках) такие аббревиатуры как HAL, СХД, ТСО и им подобные, так как мы находимся на engineering-ru (как верно подметил товарисч e_maksimov), а это обязывает быть понятым не только узкой категорией граждан, называющих себя архитекторами ;)
А цель данного комьюнити не померяться кое-чем, что очень любят делать многие, а донести до широких масс по возможности - что именно происходит, куда течет и откуда берется, не так ли? ;)

> "Известный еще со времен VmWare 3 кейс с работой виртуализованного MS SQL на определенной аппаратной платформе с производительностью 110-112% от запуска его на той же аппаратной платформе без VmWare "
- Спасибо за пример. Я поржал над МелкоМягкими в очередной раз! Это ж как нужно было уделать свой бд-сервак в плане работы с физическим, чтобы он в виртуале обгонял. Молодцы - орлы просто, продолжайте в том же духе выпускать свои программные безделушки ;)

[vpluto.livejournal.com]

1) Расшифровывать общеупотребительные аббревиатуры считаю бессмысленной работой. Гугл в соседней закладке браузера сделает это куда лучше меня.
Понятно, что нужно расписывать то, что нельзя нагуглить - сейчас вот гугл проиндексирует этот тред и - свят-свят - у людей на вопрос "зачем нужна виртуализация" будет этот пост открываться среди других в выдаче. А что неоднозначного в гуглении аббревиатур можно найти - я как-то не понимаю.

2) Выводы из ваших формулировок весьма неутешительны. Безапеляционность оценки кейса и автоматическое приписывание проблемы производителю прикладного ПО говорят само за себя.
Так вот в данном конкретном кейсе виной были неоптимальные драйвера дискового контроллера, написанные производителем для Win2k, и существенно более оптимальные драйвера для VmWare. MS тут ни при чем.

[nicky-boom.livejournal.com]

1) "Понятно, что нужно расписывать то, что нельзя нагуглить" ?
Что разве есть что либо, чего нельзя нагуглить?
- расписывать нужно свою личную и собственную оценку того, что можно нагуглить.
Кроме того, "А что неоднозначного в гуглении аббревиатур можно найти - я как-то не понимаю":
- я долго искал в гугле расшифровку SAS, так как это и Software As a Service(SAS), Special Air Service(SAS), Scandinavian Airline(SAS), SAS Group(SAS), SAS: Business Analytics and Business Intelligence Software(SAS) и наконец Serial attached SCSI(SAS). Что - не надо расшифровывать?

- что может быть плохого в том, чтобы человек задавался вопросом, подобными ""зачем нужна виртуализация"" ?

2) - побольше адеквата, я бы посоветовал в данном случае, и не нужно выискивать потайных переплетений там, где всё более-менее лежит на поверхности: Мелкософт - амбивалентный автор как драйверов для своей ОС, на которой только и может быть запущен MSSQL, так и самого "прикладного ПО" то есть своего сервера БД.

"Так вот в данном конкретном кейсе виной были неоптимальные драйвера дискового контроллера, написанные производителем для Win2k, и существенно более оптимальные драйвера для VmWare. MS тут ни при чем."
- Перечитайте ещё раз сами то что сформулировали, вы сами верите в то, что написали?

- Нет никаких специально написанных "более оптимальные драйвера для VmWare" драйверов VMware для MS.
В том и сила Vmware - что она уравнивает всех производителей осей между собой.

Скорее всего в данном случае не было учтено того фактора, что скорость железа, на котором запускался MSSQL и скорость абстрактного аналога железа, которое было выделено VMware - были не одинаково равны по производительности.

[vpluto.livejournal.com]

1) Плохого в том, чтобы задаваться такими вопросами, нет ничего. У меня единственная печаль в том, что этот пост будет в выдаче и заведет ищущих в тупик.

SAS - не надо расшифровывать. Элементарное умение формировать запросы должно таки быть. Вам не очевидно, что если вы видите несколько разнородных ответов в выдаче, необходимо и достаточно всего-лишь конкретизировать запрос? Написать "SAS жесткие диски" или "SAS системы хранения данных" (в зависимости от того, где именно вы столкнулись с этой аббревиатурой) - и не нужно выбирать между скандинавскими авиалиниями и специальными воздушными силами.

2) Майкрософт и в те времена, и сейчас практически не пишет драйверов самостоятельно.
В то, что производитель контроллера может написать плохие драйвера для MS и хорошие драйвера для VmWare (не специально, но так получилось - разные команды занимались) - верю не только я, это в те времена было даже самим производителем признано.
Нет у продукции VmWare никакой волшебной силы, она просто предоставляет гостевым операционным системам некий одинаковый (или разный, как настроишь) набор абстрактного железа HAL (http://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D0%BE%D0%B9_%D0%B0%D0%BF%D0%BF%D0%B0%D1%80%D0%B0%D1%82%D0%BD%D1%8B%D1%85_%D0%B0%D0%B1%D1%81%D1%82%D1%80%D0%B0%D0%BA%D1%86%D0%B8%D0%B9)

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

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

[nicky-boom.livejournal.com]

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

2) не мерьте всех по себе любимому - люди склонны сомневаться в аббревиатурах, особенно те, кто работают в смежных с ИТ областях.

Для этого драйвера и сертифицируют и цифрово-подписывают, что мол вот этот протестирован, а этот - на ваш страх и риск, если поставите.

"набор абстрактного железа HAL" - я бы так сформулировал: Уровень абстракции от аппаратного обеспечения.(хотя за расшифровку - благодарность от лица комьюнити).

Здесь никто никого не старается переубедить, а напротив, сформировать собственную точку зрения на вопрос обсуждения.

Чем больше самоубийц - тем меньше самоубийц.(напомнила ваша же фраза) ;)

[ichskh.livejournal.com]

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

[nicky-boom.livejournal.com]

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

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

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

[ichskh.livejournal.com]

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

[nicky-boom.livejournal.com]

Ответьте на вопрос:
Я принудил этого специалиста к общению в данном комьюнити?

[ichskh.livejournal.com]

Нет, вы от него требуете объяснения очевидных вещей.

[nicky-boom.livejournal.com]

Кто ? Я - требую? Вы меня ни с кем не путаете случаем?

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

[the-realistic.livejournal.com]

>Мелкософт - амбивалентный автор как драйверов для своей ОС

Нет, конечно.

[nicky-boom.livejournal.com]

Признаю. Тяпнул лишка.

Сказать хотел, что Мелкософт - амбивалентный автор как своей ОС, так и своего Сервера MSSQL.

А кроме того, в предложении:

"Так вот в данном конкретном кейсе виной были неоптимальные драйвера дискового контроллера, написанные производителем для Win2k, и существенно более оптимальные драйвера для VmWare. MS тут ни при чем."

Я не согласен с фразой "MS тут ни при чем."
MS тут - при чем. И очень даже причем.

[the-realistic.livejournal.com]

MS мало какие драйвера пишет.

Драйвер к контроллеру пишет почти точно его производитель. MS его на перформанс не тестирует. Точнее, вообще не тестирует - производитель должен оттестировать и прислать логи в MS.

То, что в свежем ESX драйвер актуальнее и работает быстрее, чем драйвер для старинной w2k - не удивительно.

[nicky-boom.livejournal.com]

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

>То, что в свежем ESX драйвер актуальнее и работает быстрее, чем драйвер для старинной w2k - не удивительно.

Согласен. Ничего удивительного. Как я уже писал, не было тогда HAL, и дрова поэтому W2K несовместимы ни с какими другими версиями виндовса.

Тогда только и стали задумываться о том, что предстоит виртуализация, и что для неё понадобится отвязка виртуального инстанса от аппаратного обеспечения.

[the-realistic.livejournal.com]

VMWare - имеется в виду ESX?

[vpluto.livejournal.com]

В данном конкретном кейсе - VmWare ESX3.5

[nicky-boom.livejournal.com]

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

- Что же здесь может быть парадоксального, когда взяли старую железку, произведенную ещё до того времени, когда вообще придумали HAL, без которого к примеру была вывалена на рынок W2K(Windows 2000) мелкомягкими "производителями" и драйвера которой поэтому несовместимы ни с какими другими даже наследниками её, так как напрямую работали с железом каждый конкретно со своим.
- и сравнили её с Windows XP - где уже был реализован этот HAL и поэтому виртуальные среды попросту смогли достучаться до более низкого слоя обработки команд и соответственно получить выигрыш именно за счет виртуализированной среды выполнения ?


>Виртуализация позволяет изолировать серверные процессы друг от друга, обеспечив минимализацию их взаимного влияния так, что падение одного серверного приложения в core dump не приведет к отказу другого (да, в идеале это должна делать ОС, но на практике...).

- Частично соглашусь с этим. Однако, и виртуализированных сред которые не подвержены никаким падениям вследствие падений их гостевых осей не так и много на сегодняшнем рынке.
На практике, в core dump падает XP когда ей ставят не подписанные драйверы.


>В-третьих, счетная производительность является главной целью только в High-Perfomance Computing, где виртуализация и - сюрприз! - не применяется.

- Да, это так. К примеру попробуйте поставить в виртуальную среду(виртуализировать) Операционную Систему реального времени QNX, которая в основном используется в embedded-системах.


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

- Да , это так. Только оверхеда надо бы дешифровать.


>Про существенные преимущества в виде полной отвязки виртуального инстанса от аппаратного обеспечения (когда мы в общем случае можем и не знать, на каком именно сервере и СХД работает и хранится эта виртуальная машина) и, таким образом, обеспечения катастрофоустойчивости системы автор упомянул, но как-то без энтузиазма. Между тем, это один из важнейших плюсов виртуализации, снижающим TCO в разы.

- прошу перефразировать, желательно с расшифровкой слов: "виртуального инстанса",
" таким образом, обеспечения катастрофоустойчивости системы автор упомянул, но как-то без энтузиазма"
- что именно упомянул и что без энтузиазма?