![[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:30 am (UTC)>Универсальные ОС также невозможны, как универсальные автомобили. Потому что есть разные производители, они предлагают разные возможности своим клиентам, клиенты вправе выбирать, что им нужно. Кому-то нужно нагруженное веб-приложение и они выбирают линукс, кому-то интеграция с дайнамикс и шэрпойнтом и они выбирают виндоус. При этом выбор исходит из потребностей и наличия компетенций внутри компании, а не из того кому что нравится. Вы же не ездите на феррари по бездорожью, а на хаммере по автобану.
- Всё это так, точнее было так до наступления эры повальной виртуализации, а теперь смотрите что происходит:
"Кому-то нужно нагруженное веб-приложение и они выбирают линукс," - допустим так,
" кому-то интеграция с дайнамикс и шэрпойнтом и они выбирают виндоус." - и это так,
а теперь в какой-то момент времени тем, кто выбрал виндовс для своих задач, вдруг понадобился "нагруженное веб-приложение" для продолжения выкладывания в вэб данных из их задачи. В то же время как вы правильно пишете " выбор исходит из потребностей и наличия компетенций внутри компании, а не из того кому что нравится." - а у них и нет компетенции в работе с линуксом, зато есть компетенция в работе с MS(так как компания вложилась на эту даже язык не поворачивается назвать - компанию), то естественно что им остается IIS для этих целей, который вообще не предназначен для высоконагруженных вэб-приложений.
Так вот , о чем то бишь мы тут... а , так вот - что они делают - выкладывают в IIS свои данные, и ставят естественно его на виртуальную среду выполнения с неограниченными ресурсами памяти, проц.времени, жесткого диска, которые гипервизор выделит MS-серверу, где запущен IIS в случае если , вдруг возникнет отставание по показателям обслуживания нагруженное веб-приложения от аналогичного линуксового. И не беда, что линуксовый в разы меньше требует памяти, проца и харда, ведь он тоже запущен в виртуальной среде. В данном случае - мы имеем неограниченные ресурсы для гипервизора MS, у которого "этого гуталина - ну просто завались - вот и шлёт кому попало, и сколько попало". А производителям железа только и выгоднее, чтобы у них покупали как можно больше памяти, железа, MS-софта.
Что в итоге имеем? Что при всё большем удешевлении ресурсов и увеличении их объёмов продаж - всё меньше становятся требования к ресурсоэкономии и к соответственно спецам с разнообразной квалификацией, в данном случае - Apache, Tomcat on Linux.
>Универсальные ОС также невозможны, как универсальные автомобили. ?
- в данном случае - получается что как раз возможны ;)
и не просто возможны, а даже необходимы - чтобы "выбор исходил из потребностей и наличия компетенций внутри компании, а не из того кому что нравится". ;)
no subject
Date: 2014-02-03 06:03 pm (UTC)Во-вторых, перестаньте рассматривать абстрактные приложения в абстрактном мире на абстрактном железе. Каждое приложение кто-то разрабатывает, при этом задействуется цикл разработки, включающий анализ, сбор требований, проектирование, разработку и передачу в поддержку. Затем приложение попадает во вполне реальный жизненный цикл. Внимание, разработка стоит на порядки дороже всего аппаратного оборудования.
Во время проектирования проводится сайзинг в зависимости от прогнозируемых потребностей. Сюда же закладывается возможность к расширению. Если сайзинг проведен некорректно, то никакая виртуализация и выделение дополнительных ресурсов не спасут.
Также во время проектирования проводится выбор архитектуры в зависимости от требований и ожиданий. Обычно выбирают одну платформу, а не несколько. Потому что так будет дешевле и для разработки и, что не менее важно, для дальнейшей поддержки.
Поэтому ваши идеи по переключению одного ПО между различными платформами - оно немного диковато звучит для моего уха. Оно конечно так бывает, но довольно редко и в довольно специфичных случаях. Настолько специфичных, что заранее к ним готовиться смысла большого нет.
(frozen) no subject
Date: 2014-02-03 07:03 pm (UTC)- назовите хотя бы один серьезный сайт, работающий на IIS, за исключением microsoft.com ? :)
- Девелоперы всех сред разработки от MS - это бедные люди с дебильным VBasic-ком в головах...
"Во-вторых, перестаньте рассматривать абстрактные приложения в абстрактном мире на абстрактном железе."
- Тема данного обсуждения и топика - как раз обязывает именно так абстрактно обсуждать ;))
"Поэтому ваши идеи по переключению одного ПО между различными платформами - оно немного диковато звучит для моего уха. Оно конечно так бывает, но довольно редко и в довольно специфичных случаях. Настолько специфичных, что заранее к ним готовиться смысла большого нет."
- это просто Перл! ;) Где бы его записать. ;)
В целом, меня позабавил этот реплай, так как я понимаю, что вы не девелопили софт в своей жизни, а вероятно занимались более плотно организацией девелоперов как PM, и/или маркетинговыми изысканиями и принимали участие в предоставлении услуг и/или каналов связи.