![[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-01-31 05:40 pm (UTC)1. Более рациональное использование оборудования. Как правило, большинство серверов недогружены, т.к. берутся с запасом мощностей. Если мы вместо десятка мелких серверов берем один мощный получакм существенную выгоду не только по цене железки, но и по месту в стойке, энергопотреблению и.т.д. При подходе мощностей железки к пределу - покупаем еще одну и переносим туда часто серверов. Операция простая как 3 копейки. Нужен новый сервер - вместо закупки новой железки ( это время, деньги, место в стойке, порты коммутатора, дополнительные затраты на электроэнергию, дополнительная мощность UPS и генератора ) просто поднимаем виртуальную машинку.
2. Простота обновления оборудования - При наличии трех или более нормально загруженных серверов, можон без проблем останавливать любой сервер на Upgrade или просто замену, с минимальными простоями работающих сервисов. Перед остановкой физического сервера виртуалы просто переносят на соседние физические сервера. Время простоя каждой виртуальной машинки составит несколько минут.
3. Разработка сложных систем. При разработке и доработке сложных систем иногда требуется иметь тестовые версии боевых систем, сотоящие иногда из нескольких десятков серверов. Тут виртуализация просто незаменима.
no subject
Date: 2014-01-31 06:32 pm (UTC)То есть за "При подходе мощностей железки к пределу" следит некая программа-монитор, называемая гипервизор, не так ли?
А что случится если вдруг произойдет непредвиденный скачок в мощности потребляемых ресурсов, который не был заложен в "берутся с запасом мощностей" ?
no subject
Date: 2014-02-01 08:05 am (UTC)"А что случится если вдруг произойдет непредвиденный скачок в мощности потребляемых ресурсов, который не был заложен в "берутся с запасом мощностей" ?"
То же что и в обычном случае, только возможностей для маневра больше.
К примеру живет нечто и потребляет 4G Ram, пару ядер и полтеррабайта дискотеки. В локальном исполнении для этого нечто, сисадмин отдаст старенький одноголовый сервачок с 8 Gb RAM и парой дисков по 1Tb в зеркале.
На VMWare админ выделит ту же конфигурацию, только к дискам повнимательнее отнесется и разместит что-то на локальном хранилище, Что то на быстром SAS NFS, а что-то, например логи, на большом, но медленном SATA NFS. Физическая машинка тоже не очень новенкий DELL 710 c двумя шеситядерными головами и 128G мозгов, и 8 SAS дисками по 900Gb каждый, объединенные в один 50RAID (гусары, молчать!) Это не самая мощная машинка ( закупка 2011 года) и загружена в пике примерно на 50%.
При резком возрастании аппетитов нашего нечто в 2-3 раза, в железном случае админу требуется выбивать деньги на новую железку или мириться с 80% недоступностью сервиса, По любому, простой составит несколько часов. А в случае с VMWare админ просто гасит машинку, добавляет необходимой памяти, голов и ядер, и запускает ее заново. Простой составит несколько минут. Диски переносятся без остановки сервиса.
Если все равно ресурсов не хватает, админ переносит другие машинки с нашего гипервизора на другие гипервизоры, или переносит машинку на более мощный гипервизор.
no subject
Date: 2014-02-01 04:31 pm (UTC)Однако, market share у вари снижается:
"Ну, виртуализация-то повальная, но, с одной стороны, vmware поджимает мелкософт с hyper-v, с другой redhat с rhev/kvm, с третьей - амазон со своими облаками на xen'е, так что, виртуализация-то повальная, но не всегда на vmware, на самом деле, market share у вари снижается, к сожалению."
"Плюс к тому, для того, чтобы специализироваться в vmware, надо попасть в большую контору, в которой есть необходимость в специалистах по vmware, а контор таких мало, и попасть туда сложно."