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

[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

[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, благо оба можно найти для прочтения даже на русском языке.

[alex9876543210.livejournal.com]

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

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

Упавший RAID - это Service Continuity
А восстановление из бэкапа после выхода из строя контроллера? Только цунами, только тайфун?

Каково максимальное время простоя, чтобы процедуры восстановления работоспособности заслужили в ваших глазах звания DRP?

http://h20566.www2.hp.com/portal/site/hpsc/template.BINARYPORTLET/public/kb/docDisplay/resource.process/?spf_p.tpst=kbDocDisplay_ws_BI&spf_p.rid_kbDocDisplay=docDisplayResURL&javax.portlet.begCacheTok=com.vignette.cachetoken&spf_p.rst_kbDocDisplay=wsrp-resourceState%3DdocId%253Demr_na-c02529231-1%257CdocLocale%253D&javax.portlet.endCacheTok=com.vignette.cachetoken

Disaster Recovery Guide for Windows 2008 and RHEL 5.x platforms with external disk support
HP Data Protector 6.11

1. Assisted Manual Disaster Recovery
ручное, какой кошмар, да? :D

Phase 0
• Perform a full host backup and an IDB backup (Cell Manager only).
• Update the SRD (system recovery data) file. Collect information on the original system to enable installation and configuration of the DR OS (disaster recovery operating system).
Phase 1
• Replace the faulty hardware.
• Re-install the operating system. (Create and format the necessary partitions.)

читайте ITIL и COBIT
спасибо, но мне практика более по душе

[ichskh.livejournal.com]

О, забавно, вы теперь еще и ссылки даете на наш сайт :)

[alex9876543210.livejournal.com]

Ух ты какие специалисты у хьюлета классные

исправлено, промахнулся с продуктом, вот так правильнее
http://h20195.www2.hp.com/V2/GetPDF.aspx%2F4AA3-0867ENW.pdf
VMware vStorage API for Data Protection backups
VADP is a framework for vSphere to enable backup products to provide protection for VMware
vSphere environment. VADP ensures application-consistent backups of Windows virtual
machines and Windows applications through support of Microsoft’s Volume Shadow Copy
Service (VSS). It also allows backup software to back up and restore incremental, differential,
and full-image backups

[nicky-boom.livejournal.com]

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

[ichskh.livejournal.com]

Я уже писал, что пропускная способность не так важна. Сейчас можно получать по 100 мегабит на домашнем канале. Важна задержка, latency, время отклика. Поэтому дальность физического размещения реплик ограничена.

[nicky-boom.livejournal.com]

Получается, по-вашему, что latency совсем не зависит от пропускной способности канала?

[ichskh.livejournal.com]

Очевидно, да :) Вы можете заказать у оператора канал 128К с заданными параметрами задержки для своих критичных приложений. У нашего клиента долгое время региональные офисы сидели на 256/512К плюс Интернет. По тонкому каналу работала их ЕРП, по Интернет каналу - все остальное некритичное.