Современный мир информационных технологий немыслим без Виртуализации "всего на свете" - серверов, операционных систем(ОС), сетевых плат(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-процесса (устанавливается с другими приложениями на одном и том же физическом сервере). Зачем же тогда его виртуализировать, заранее предполагая потерю его производительности, связанную с выполнением в виртуальным домене, в котором всё эмулируется - память, процессор, жёсткий диск, сетевая плата?
Однако, мало кто задумывается над тем, что именно привнесла виртуализация в современный IT, и в чём на самом деле её недостатки, а где именно - достоинства.

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

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

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

Вообще, сложилось у меня впечатление, что виртуализация может быть оправдана(или обусловлена) лишь наличием legacy-hardware(унаследованное железо) и inherited-software(доставшийся в наследство софт). Причем, серверное программное обеспечение, как правило, менее нуждается в виртуализации, в сравнении с настольным ПО, так как оно легко комбинируется в виде NT-сервиса или Unix-процесса (устанавливается с другими приложениями на одном и том же физическом сервере). Зачем же тогда его виртуализировать, заранее предполагая потерю его производительности, связанную с выполнением в виртуальным домене, в котором всё эмулируется - память, процессор, жёсткий диск, сетевая плата?
no subject
Date: 2014-02-01 03:25 pm (UTC)Понятно, что нужно расписывать то, что нельзя нагуглить - сейчас вот гугл проиндексирует этот тред и - свят-свят - у людей на вопрос "зачем нужна виртуализация" будет этот пост открываться среди других в выдаче. А что неоднозначного в гуглении аббревиатур можно найти - я как-то не понимаю.
2) Выводы из ваших формулировок весьма неутешительны. Безапеляционность оценки кейса и автоматическое приписывание проблемы производителю прикладного ПО говорят само за себя.
Так вот в данном конкретном кейсе виной были неоптимальные драйвера дискового контроллера, написанные производителем для Win2k, и существенно более оптимальные драйвера для VmWare. MS тут ни при чем.
no subject
Date: 2014-02-01 03:51 pm (UTC)Что разве есть что либо, чего нельзя нагуглить?
- расписывать нужно свою личную и собственную оценку того, что можно нагуглить.
Кроме того, "А что неоднозначного в гуглении аббревиатур можно найти - я как-то не понимаю":
- я долго искал в гугле расшифровку 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 - были не одинаково равны по производительности.
no subject
Date: 2014-02-01 05:05 pm (UTC)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 архитектуре концептуально не может выделить одной виртуальной машине больше физических ресурсов, чем их есть в одном физическом хосте этой системы.
Но в целом эта дискуссия бесперспективна, я ничуть не пытаюсь вас переубедить в вашей позиции. Как говорится, чем больше таких как вы - тем дороже такие как мы.
no subject
Date: 2014-02-01 06:31 pm (UTC)2) не мерьте всех по себе любимому - люди склонны сомневаться в аббревиатурах, особенно те, кто работают в смежных с ИТ областях.
Для этого драйвера и сертифицируют и цифрово-подписывают, что мол вот этот протестирован, а этот - на ваш страх и риск, если поставите.
"набор абстрактного железа HAL" - я бы так сформулировал: Уровень абстракции от аппаратного обеспечения.(хотя за расшифровку - благодарность от лица комьюнити).
Здесь никто никого не старается переубедить, а напротив, сформировать собственную точку зрения на вопрос обсуждения.
Чем больше самоубийц - тем меньше самоубийц.(напомнила ваша же фраза) ;)
no subject
Date: 2014-02-01 05:13 pm (UTC)no subject
Date: 2014-02-01 06:13 pm (UTC)Ну а то, что человек разбирается в предмете видно невооруженным глазом. Вот ещё бы научился не наезжать на аудиторию, а пытаться поставить себя на место оппонента, взглянуть с другой стороны - цена бы спеца неуклонно пошла вверх, не так ли?
Цель стоит такая перед всеми кто считает себя инженерами/технарями- донести до широких масс понимание принципов работы непростых технологий - если хотите на пальцах, с которыми мы имеем дело и если возможно сделать некий абстрактный взгляд в будущее, в мэйнстрим - осветить так сказать.
no subject
Date: 2014-02-01 06:24 pm (UTC)no subject
Date: 2014-02-01 06:35 pm (UTC)Я принудил этого специалиста к общению в данном комьюнити?
no subject
Date: 2014-02-01 06:42 pm (UTC)no subject
Date: 2014-02-01 06:45 pm (UTC)Я всего лишь прошу изъясняться более приемлемым для широких слоев инженеров языком и по-возможности объяснять - что стоит за той или иной аббревиатурой.
no subject
Date: 2014-02-03 05:27 am (UTC)Нет, конечно.
no subject
Date: 2014-02-03 01:33 pm (UTC)Сказать хотел, что Мелкософт - амбивалентный автор как своей ОС, так и своего Сервера MSSQL.
А кроме того, в предложении:
"Так вот в данном конкретном кейсе виной были неоптимальные драйвера дискового контроллера, написанные производителем для Win2k, и существенно более оптимальные драйвера для VmWare. MS тут ни при чем."
Я не согласен с фразой "MS тут ни при чем."
MS тут - при чем. И очень даже причем.
no subject
Date: 2014-02-03 01:42 pm (UTC)Драйвер к контроллеру пишет почти точно его производитель. MS его на перформанс не тестирует. Точнее, вообще не тестирует - производитель должен оттестировать и прислать логи в MS.
То, что в свежем ESX драйвер актуальнее и работает быстрее, чем драйвер для старинной w2k - не удивительно.
no subject
Date: 2014-02-03 02:24 pm (UTC)>То, что в свежем ESX драйвер актуальнее и работает быстрее, чем драйвер для старинной w2k - не удивительно.
Согласен. Ничего удивительного. Как я уже писал, не было тогда HAL, и дрова поэтому W2K несовместимы ни с какими другими версиями виндовса.
Тогда только и стали задумываться о том, что предстоит виртуализация, и что для неё понадобится отвязка виртуального инстанса от аппаратного обеспечения.
no subject
Date: 2014-02-03 05:26 am (UTC)no subject
Date: 2014-02-03 05:48 am (UTC)