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

[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

[ichskh.livejournal.com]

Смешалось все в доме Облонских :) Вообще говоря, виртуализация - это отделение аппаратного уровня от уровня ОС. В общем случае оно работает на принципе многое со многим. То есть Не обязательно иметь несколько ОС на одной железке или одну ОС на нескольких железках, лучше иметь много ОС на многих железках и при этом динамически распределять нагрузку между системами.

При этом я бы на месте автора я бы был поаккуратнее с лидерами в тех или иных областях. Потому что я, например, плохо знаю, что такое Hitachi Data System, но вот намного лучше знаю что такое EMC Avamar. Про виртуализацию сетевых подключений я тоже промолчу.

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

Да, по поводу DR. Здесь как раз виртуализация имеет лишь ограниченные преимущества. Дело в том, что для обеспечения DR средствами виртуализации необходимо виртуальную машину разнести по разным серверам, находящимся в разных датацентрах (ведь нет смысла работать в рамках одного, иначе какой это DR). Так вот эта необходимость влечет за собой необходимость иметь довольно быстрый канал связи между этими датацентрами. Причем быстрый не в терминах толщины, а времени отклика. Ну и из чистой физики-инженерии, эти датацентры должны распологаться очень близко, вроде как не дальше чем 20-30 километров друг от друга, иначе задержка репликации будет слишком большой.

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

[alex9876543210.livejournal.com]

Дело в том, что для обеспечения DR средствами виртуализации необходимо виртуальную машину разнести по разным серверам, находящимся в разных датацентрах (ведь нет смысла работать в рамках одного, иначе какой это DR).
Типа "если жениться то на королеве" :D

Причем быстрый не в терминах толщины, а времени отклика.
хум хау как говориться

С образами ОС невозможно делать инкрементальный бэкап
Можно

[ichskh.livejournal.com]

http://en.wikipedia.org/wiki/Disaster_recovery

Посчитайте, сколько раз в тексте употреблено выражение "off-site". Собственно дальше обсуждать что-либо бессмысленно.

[alex9876543210.livejournal.com]

Посчитайте, сколько раз в тексте употреблено выражение "off-site".
off-site не означает реплику vm в другом дц, в частности оттуда
backups made to tape and sent off-site at regular intervals
да и реплика может быть какого-нибудь скуля на вполне себе железке без каких-либо виртуалок
ваш кэп :D

Собственно дальше обсуждать что-либо бессмысленно.
с вами про бэкап вируталок? согласен

[ichskh.livejournal.com]

Речь вроде о применении виртуализации в disaster recovery, а не об отсылке ленточек в какой-нибудь Iron Mountain.

[alex9876543210.livejournal.com]

вы предложили посчитать сколько раз употреблено конкретное слово
а оно оказывается вовсе не про виртуализацию и/или репликацию

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

а не об отсылке ленточек в какой-нибудь Iron Mountain
во во, опять "королева" :D

[ichskh.livejournal.com]

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

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

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

"после выхода из строя рейд контроллера"
Это не Disaster Recovery, это Service Continuity.

[alex9876543210.livejournal.com]

Потому что можно взять ноутбук, подключиться к работающему серверу хотя бы по публичным каналам и продолжать работать
максимализм - ваше всё, я понял

Если они еще работают совместно, то могут возникнуть с целостностью данных.
чего это на разнесённых на километры не возникает, а тут обязательно возникнет?

Пожарные при входе в здание первым делом отключают электричество, возможно, всю подстанцию, а если у вас два-три ввода в датацентр, то и их тоже
и тут космические масштабы
и я говорил по ДЦ?

Это не Disaster Recovery, это Service Continuity
тоже на вики сошлюсь
http://en.wikipedia.org/wiki/IT_service_continuity
IT Service Continuity is a subset of Business Continuity Planning (BCP) and encompasses IT disaster recovery planning and wider IT resilience planning
Видимо замена контроллера - это resilience planning


http://www.symantec.com/security_response/glossary/define.jsp?letter=d&word=disaster-recovery
site disaster - только один из вариантов, а "Recovering data from backups after a disk crash or other catastrophe." вас вообще наверно приводит в ужас своей мелочностью :D

[ichskh.livejournal.com]

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

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

Resilience planning - это resilience planning. Не надо выдумывать что-то новое и приписывать что-то к чему-то. Упавший RAID - это Service Continuity, читайте ITIL и COBIT, благо оба можно найти для прочтения даже на русском языке.

[nicky-boom.livejournal.com]

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

>При этом я бы на месте автора я бы был поаккуратнее с лидерами в тех или иных областях. Потому что я, например, плохо знаю, что такое Hitachi Data System, но вот намного лучше знаю что такое EMC Avamar. Про виртуализацию сетевых подключений я тоже промолчу.
- Hitachi Data Systems (http://en.wikipedia.org/wiki/Hitachi_Data_Systems) - это один из лидеров и основатель стандартов в NAS(Network Attached Storage).
- почему же "промолчу про виртуализацию сетевых подключений"? На мой взгляд, одно из интересных и необходимых направлений виртуализации, которое и позволяет иметь широко-виртуализированные сервера и технологии. В частности, не было бы возможным иметь загруженные трафиком сервера, виртуализированные без применения infinite bandwidth, который предоставляется такими железами как Xsigo.

[vadim rumyantsev (from livejournal.com)]

Сам по себе NAS по ряду причин (производительность, надёжность) не является мэйнстримом в этом деле.

[nicky-boom.livejournal.com]

Возможно и так.
А что - является?

[vadim rumyantsev (from livejournal.com)]

Как правило, SAN через быстродействующие интерфейсы (SAS, Fibre Channel).

[nicky-boom.livejournal.com]

Хорошо, а расшифровать для широкой публики, что есть SAS, и в чем достоинства/отличия её от Fibre Channel и SAN можете? Я например знаю что речь идет о SAS - как о Scsi-Attached-Storage, а не о Software As a Service (SAS или SAaS) :)
мы же не в узком кругу сетевых админов здесь. ;)

[vadim rumyantsev (from livejournal.com)]

Я имел в виду Serial Attached SCSI. Отличие от Fibre Channel прежде всего в физической среде – медь или оптика.

[nicky-boom.livejournal.com]

Становится ли оптика широкодоступной для масс, также как медь?

Основное достоинство оптики - не восприимчива к ЭМИ, скорость передачи конечно - так как другой физический носитель информации - световая волна, а что ещё?

[nicky-boom.livejournal.com]

Почему называется Serial ? В чем её преимущество перед Parallel?
Казалось бы по нескольким проводам(в случае Parallel) можно передавать больше данных, чем по одному(или двум) в случае Serial. Однако происходит вытеснение IDE-интерфейсов SATA-шными, так же как SCSI-параллельный вытесняется Searial Attached SCSI. В чем тут фокус и причина?

[ichskh.livejournal.com]

Подозреваю, что SAN/FAS ;)

[ichskh.livejournal.com]

Мы же не про бюджеты :) Потребности малого и большого бизнеса конечно различаются, но если мы говорим о виртуализации, то должны рассматривать все стороны медали.

Возможно Hitachi и был основателем стандартов, но они уже давно не лидеры рынка, на их долю приходится меньше 10 процентов и доля стремительно падает. Большой бизнес (а основные потребители NAS именно они) в основном предпочитаю EMC и IBM.

http://www.storagenewsletter.com/rubriques/market-reportsresearch/idc-2q13-ww-disk-systems/

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

[nicky-boom.livejournal.com]

Да, мы не про бюджеты.;)
Вообще изначально пост задумывался как "поговорить на тему, или помечтать о романтической составляющей" виртуализации, о том, что нас может ожидать в будущем, какой софт,железо станет "нормальным" или "принятым" в таких вероятно и невероятно виртуализированных средах, к которым намечается движение уже сейчас.

А не только обсудить кто сейчас лидер в той или иной зоне.

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

[ichskh.livejournal.com]

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

А на уровне малого и среднего бизнеса виртуализация применяется реже, так как потребности немного другие. Плюс виртуализация дорога даже не железом и не программами, а наличием подготовленных и обученных кадров. Вон если люди путают DR и Service Continuity, то как можно говорить о грамотном внедрении виртуализированных серверов?

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

[nicky-boom.livejournal.com]

>Так все тенденции уже давно реализованы.

А как вам такая вот тенденция:

- Имеем некоторое многообразие классов hardware/software-платформ Unix/Linux, MS, MacOS, HP, IBM и другие, которое можно считать legacy, то есть которое пришло исторически в эру виртуализации, и для которого софт создавался отдельно для каждой платформы свой, так как несовместим. Выходила какая-нибудь софтинка и в дистрибутиве отдельно для виндовс и для линукс. Причём характерно, что одно более хорошо работало с тем, а другое с другим.

- Что имеем теперь(в "Виртуализация - это довольно устоявшаяся технология"):
Целесообразность написания софта отдельно для каждой платформы теряется, так как приходится рассчитывать, что платформа эта более как отдельно стоящая(standalone) физическая не существует(или всё менее существует), и потенциально будет виртуализирована, а значит нужно заложить и в софт, чтобы он умел быть грамотно виртуализированным, мог использовать например Гипервиртуализацию, чтобы не тормозить соседей по гипервизору.

В результате тенденция намечается такая:
- Возникает потребность в некоей универсальной операционной системе, которая бы умела быть кластиризованной и виртуализированной лучше других. Что и происходит, например, с кланом RedHat, RHEL?
Когда инсталлируется, то спрашивает сама или определяет: вы ставите в виртуальную среду, или на физическую машину?

То есть получается тенденция идет к тому, что многообразие осей скоро мы будем вспоминать только, и вопрос: хорошо ли это?

[ichskh.livejournal.com]

Во-первых, давайте сразу вычеркнем из вашего списка IBM и HP, то есть HPUX и AIX, они используют другие процессоры и не виртуализируются на x86 архитектуре.

Во-вторых, давайте разбираться. Любая ИТ система - это набор слоев. Снизу - аппаратный слой, потом слой ОС, потом слои приложений. Между аппаратным слоем и слоем ОС добавляют слой с виртуализацией. Практически все современные ОС уже давно можно виртуализировать (не уверен за МакОС, но он редко кому нужен на серверах). Слой приложений практически не в курсе что там и как виртуализировано или нет, ему все равно, он работает со слоем ОС. Поэтому что-либо добавлять в приложение специально для виртуализации никто особо не будет.

Далее, приложения соседей по гипервизору тоже тормозить не могут. Потому что гипервизор не в работает с приложениями, гипервизор выделяет доступные ресурсы и делит их согласно заданным правилам. То есть сказано 4 гигабайта оперативной памяти и 40% процессорного времени, значит столько и выделит на одну ОС, что бы там приложения ни думали.

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

[nicky-boom.livejournal.com]

>Во-первых, давайте сразу вычеркнем из вашего списка IBM и HP, то есть HPUX и AIX, они используют другие процессоры и не виртуализируются на x86 архитектуре.

- С чего вдруг вы вычеркиваете HPUX и AIX? Они что - не подвержены виртуализации? На них как тут уже говорили виртуализация уже лет 30-40 как живет, в отличие от x86. Свет клином не сошелся на x86 архитектуре, для рассмотрения общих тенденций важно как раз охватывать весь спектр архитектур.


>Во-вторых, давайте разбираться. Любая ИТ система - это набор слоев. Снизу - аппаратный слой, потом слой ОС, потом слои приложений. Между аппаратным слоем и слоем ОС добавляют слой с виртуализацией. Практически все современные ОС уже давно можно виртуализировать (не уверен за МакОС, но он редко кому нужен на серверах). Слой приложений практически не в курсе что там и как виртуализировано или нет, ему все равно, он работает со слоем ОС. Поэтому что-либо добавлять в приложение специально для виртуализации никто особо не будет.

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

" Слой приложений практически не в курсе что там и как виртуализировано или нет, ему все равно, он работает со слоем ОС. Поэтому что-либо добавлять в приложение специально для виртуализации никто особо не будет."

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


>Далее, приложения соседей по гипервизору тоже тормозить не могут. Потому что гипервизор не в работает с приложениями, гипервизор выделяет доступные ресурсы и делит их согласно заданным правилам. То есть сказано 4 гигабайта оперативной памяти и 40% процессорного времени, значит столько и выделит на одну ОС, что бы там приложения ни думали.

- Нигде не было сказано, что гипервизор работает с приложениями, он работает с распределением имеющихся в его распоряжении ресурсов между всеми "соседями по гипервизору" - то есть ОСями, которые в свою очередь обслуживают слой приложений, которые могут запрашивать ресурсы у своих ОСей, а те в свою очередь у гипервизора. Если этих 40% и 4 ГигаБайта памяти окажется приложению недостаточно для обслуживания нагрузки от клиентов, оно запросит у своей ОСи еще, та пойдет запрашивать дальше, или сваповать на диск - выгружать память, чтобы отдать как можно больше этому наиболее актуальному в данный момент приложению, если гипервизор откажется выдавать больше этого лимита ресурсов, разумеется.

[nicky-boom.livejournal.com]

>continuing<


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

- Всё это так, точнее было так до наступления эры повальной виртуализации, а теперь смотрите что происходит:

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

а теперь в какой-то момент времени тем, кто выбрал виндовс для своих задач, вдруг понадобился "нагруженное веб-приложение" для продолжения выкладывания в вэб данных из их задачи. В то же время как вы правильно пишете " выбор исходит из потребностей и наличия компетенций внутри компании, а не из того кому что нравится." - а у них и нет компетенции в работе с линуксом, зато есть компетенция в работе с MS(так как компания вложилась на эту даже язык не поворачивается назвать - компанию), то естественно что им остается IIS для этих целей, который вообще не предназначен для высоконагруженных вэб-приложений.
Так вот , о чем то бишь мы тут... а , так вот - что они делают - выкладывают в IIS свои данные, и ставят естественно его на виртуальную среду выполнения с неограниченными ресурсами памяти, проц.времени, жесткого диска, которые гипервизор выделит MS-серверу, где запущен IIS в случае если , вдруг возникнет отставание по показателям обслуживания нагруженное веб-приложения от аналогичного линуксового. И не беда, что линуксовый в разы меньше требует памяти, проца и харда, ведь он тоже запущен в виртуальной среде. В данном случае - мы имеем неограниченные ресурсы для гипервизора MS, у которого "этого гуталина - ну просто завались - вот и шлёт кому попало, и сколько попало". А производителям железа только и выгоднее, чтобы у них покупали как можно больше памяти, железа, MS-софта.

Что в итоге имеем? Что при всё большем удешевлении ресурсов и увеличении их объёмов продаж - всё меньше становятся требования к ресурсоэкономии и к соответственно спецам с разнообразной квалификацией, в данном случае - Apache, Tomcat on Linux.

>Универсальные ОС также невозможны, как универсальные автомобили. ?
- в данном случае - получается что как раз возможны ;)
и не просто возможны, а даже необходимы - чтобы "выбор исходил из потребностей и наличия компетенций внутри компании, а не из того кому что нравится". ;)