![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
nicky-boom.livejournal.com posting in ![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}
engineering_ruСовременный мир информационных технологий немыслим без Виртуализации "всего на свете" - серверов, операционных систем(ОС), сетевых плат(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-процесса (устанавливается с другими приложениями на одном и том же физическом сервере). Зачем же тогда его виртуализировать, заранее предполагая потерю его производительности, связанную с выполнением в виртуальным домене, в котором всё эмулируется - память, процессор, жёсткий диск, сетевая плата?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2014-02-02 12:29 am (UTC)- С чего вдруг вы вычеркиваете HPUX и AIX? Они что - не подвержены виртуализации? На них как тут уже говорили виртуализация уже лет 30-40 как живет, в отличие от x86. Свет клином не сошелся на x86 архитектуре, для рассмотрения общих тенденций важно как раз охватывать весь спектр архитектур.
>Во-вторых, давайте разбираться. Любая ИТ система - это набор слоев. Снизу - аппаратный слой, потом слой ОС, потом слои приложений. Между аппаратным слоем и слоем ОС добавляют слой с виртуализацией. Практически все современные ОС уже давно можно виртуализировать (не уверен за МакОС, но он редко кому нужен на серверах). Слой приложений практически не в курсе что там и как виртуализировано или нет, ему все равно, он работает со слоем ОС. Поэтому что-либо добавлять в приложение специально для виртуализации никто особо не будет.
- Ну давайте разберемся. "Практически все современные ОС уже давно можно виртуализировать" - большинство да, но не все - исключим ОС реального времени, или как назвал товарищ c ником vpluto: "В-третьих, счетная производительность является главной целью только в High-Perfomance Computing, где виртуализация и - сюрприз! - не применяется."
" Слой приложений практически не в курсе что там и как виртуализировано или нет, ему все равно, он работает со слоем ОС. Поэтому что-либо добавлять в приложение специально для виртуализации никто особо не будет."
- будет добавлять в приложение специально для виртуализации - никто бы не стал придумывать Гипервиртуализацию, - зачем тогда, когда и так все сложно. Как только возникнет потребность в высоконагруженных запросами системах, таких как транзакционные сервера, где ассиметрично нагрузка падает только на один из ресурсов - например будет запрашивать всё больше памяти под запросы, при том, что процессорное время не особенно потребуется, - что же теперь ради кратковременного скачка загрузки - наращивать/распределять ресурсы гипервизору?
>Далее, приложения соседей по гипервизору тоже тормозить не могут. Потому что гипервизор не в работает с приложениями, гипервизор выделяет доступные ресурсы и делит их согласно заданным правилам. То есть сказано 4 гигабайта оперативной памяти и 40% процессорного времени, значит столько и выделит на одну ОС, что бы там приложения ни думали.
- Нигде не было сказано, что гипервизор работает с приложениями, он работает с распределением имеющихся в его распоряжении ресурсов между всеми "соседями по гипервизору" - то есть ОСями, которые в свою очередь обслуживают слой приложений, которые могут запрашивать ресурсы у своих ОСей, а те в свою очередь у гипервизора. Если этих 40% и 4 ГигаБайта памяти окажется приложению недостаточно для обслуживания нагрузки от клиентов, оно запросит у своей ОСи еще, та пойдет запрашивать дальше, или сваповать на диск - выгружать память, чтобы отдать как можно больше этому наиболее актуальному в данный момент приложению, если гипервизор откажется выдавать больше этого лимита ресурсов, разумеется.
no subject
Date: 2014-02-02 06:04 am (UTC)HPUX, AIX - это уже почти мертвые системы. На них живут какие-либо старые приложения, но новые приложения для них уже не пишут. Поэтому будем откровенны в перспективе 10-20 лет их роль будет сходить на нет. Кому нужен Юникс выберут Линакс и БСД системы.
Далее, выкинули из списка Хай Пефоманс. Еще выкинули из списка ОС реального времени, они используются в узком спектре встроенных систем. Остается довольно небольшой класс Вин и Юникс х86 систем, которые используются как сервера приложений, веб, баз данных, а также файловых хранилищ.
Про гипервиртуализацию я вам сказать ничего не могу, я от вас первого услышал такой забавный термин.
По поводу того, что приложения запрашивают ресурс у ОС, ОС у визора, а тот поджимает соседние ОС. Это, простите, слишком усложняет жизнь. Откуда визору знать, что можно поджать соседюю ОС по ресурсам? Простейший пример - висит в одной ОС нагруженная БД, в другой ОС - Актив Дайректори. БД требует ресурсов, визор перекрывает кран АД, в это время в сеть входит пользователь и его вход жестко тормозится. Кто виноват? Поэтому проще и надежнее поставить ограничения по ресурсам каждой ОС. Остальные фантазии приведут к потенциальному отказу чего-нибудь нужного.