1. Низкоуровневая оболочка типа 1 работает непосредственно на физическом оборудовании, а не как приложение ОС. Примерами таких оболочек являются Microsoft Hyper-V и VMware ESX Server.
2. Низкоуровневая оболочка типа 2 требует для работы операционной системы. Обычно оболочка типа 2 работает, в первую очередь, как приложение пользовательского режима на размещающей ее ОС. Примерами оболочек типа 2 являются Microsoft Virtual PC и VMware Workstation.

Чаще всего, низкоуровневую оболочку типа 1 желательно использовать для «постоянных» рабочих нагрузок, таких, как виртуализованная SQL или файловый сервер. Как минимум, она использует меньше ресурсов, чем тип 2. Однако, в зависимости от носителя, она может требовать для запуска входа пользователя в систему, что не является идеальным вариантом для критически важных систем. Оболочка типа 2, с другой стороны, более адекватна для виртуальных машин, включаемых по мере необходимости. Этот тип роли включает виртуальные машины, предназначенные для тестирования, совместимости приложений или безопасного доступа.

Какова экономия от виртуализации?

Очевидный ответ состоит в том, что виртуализация позволяет сэкономить на оборудовании, но на деле это не так просто. Конечно, если имеются две серверные системы в конфигурациях для размещения на стройке 1U и две их рабочие нагрузки возложить на одну систему 1U, предварительные затраты на закупку оборудования будут сокращены – но тут есть фокус. Если взять те же две системы серверов, обе будут нормально работать на двух отдельных серверах 1U, каждый с двухядерным ЦПУ, 2 ГБ ОЗУ и жестким диском SATA на 160 ГБ.

Если поместить их обе на один сервер, с той же конфигурацией оборудования, ресурсы придется делить пополам – так ведь? Низкоуровневая оболочка типа 2 обычно требует больше ресурсов.

Затраты на ЦПУ, ОЗУ и жесткий диск следует принимать в расчет при планировании консолидации физических рабочих нагрузок в виртуальные. Виртуализованная консолидация часто называется «вертикальным расположением систем вместо горизонтального», поскольку в ее ходе мы устраняем зависимость от получения n физических систем от поставщика. В свою очередь, мы предъявляем гораздо большие требования к одной отдельной системе, чем вероятно предъявляли до виртуализации. Это сказывается на управлении системами, чего многие организации не учитывают, когда они бросаются в объятия виртуализации.

Каковы затраты на виртуализацию?

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

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

Даже если вы просто виртуализируете группу гостевых ОС для тестирования или разработки, используя низкоуровневую программу типа 2, вам все равно необходимо выделить достаточно ОЗУ для работы одной или нескольких таких систем (помимо размещающей ОС). Наиболее часто забываемая проблема управления виртуализацией – это потребление пространства на диске.

Я использовал виртуализацию для создания тестовых сред безопасности в течении некоторого времени. Нет ничего лучше, чем найти потенциальный эксплойт на виртуальной машине, увидеть его в деле и вернуться к предыдущей версии, используя функции отмены или снимка низкоуровневой оболочки, только чтобы повторить тестирование снова. Однако, настоящая «прелесть» накладывания одной отмены на другую подобным образом состоит в том, что потребление пространства на диске может быстро выйти из под контроля. Оно может далеко превзойти собственно размер жесткого диска в гостевой ОС.

Один из виртуальных компьютеров, который я регулярно использовал, имел образ жесткого диска в 50 ГБ – я не осознавал, насколько вещи вышли из под контроля, пока не попытался переместить его (он включал шесть снимков VMware) и не обнаружил, что размер диска превышает 125 ГБ.

 Вот несколько советов по минимизации негативного воздействия/издержек виртуализации:

• Если вы используете клиентскую операционную систему Windows на низкоуровневой оболочек типа 2 с функцией отмены, то отключите восстановление системы Windows. В ином случае размер диска будет расти при каждом внесении изменений в систему.
• Если вы выполнили этап 1, очень тщательно подходите к разметке того, когда следует создавать точку отмены.
• Если вы выполняете тестирование безопасности/поиск эксплойтов – не полагайтесь на Windows в плане отката к предыдущей по времени точке. Используйте функцию отмены низкоуровневой оболочки, ибо она обычно не ведет к такому загрязнению, как точки восстановления.
• Запускайте свои гостевые ОС с минимальным необходимым объемом ресурсов.
• Убедитесь, что клиентским ОС выделено достаточно ОЗУ, чтобы не требовалась постоянная подкачка содержимого ОЗУ на диск. Это может замедлить работу как вашей системы размещения так и всех гостевых систем.
• Дефрагментируйте свои гостевые ОС внутренне и затем дефрагментируйте их внешне (см. раздел по дефрагментации ниже). Осуществляйте то и другое регулярно.

Размножение виртуальных машин

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

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

Управление системами

Целые компании начали специализироваться на помощи в восстановлении контроля над виртуализованными системами. Как Майкрософт, так и VMware сознательно уделяют основное внимание не ценности виртуализации, а управлению системами. Это важно, поскольку мы не избавляемся от систем – мы только виртуализируем их.

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

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

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

Одно из дополнительных соображений – наличие или отсутствие у вашей низкоуровневой оболочки функции отката изменений. Держите это в уме при принятии решений в области управления обновлениями. Проще простого обновить гостевую ОС в среду после вторничного патча, откатить ее обратно к понедельничной точке восстановления и стать жертвой атаки нулевого дня, от которой она была теоретически «защищена». Это большая проблема, учитывая, что технологии отката работаю возвращая к предыдущей точке представления всего диска из низкоуровневой оболочки – это значит, что вы утратите все обновления и исправления Windows и приложений, а также все сигнатуры антивирусов.

Программы обеспечения безопасности

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

Но есть и большой различие – второстепенные виртуальные машины (которые не всегда включены) часто получают исправления и обновления антивирусов с заподанием. Как следствие, они могут стать гораздо большими, непрослеживаемыми целями для эксплойтов нулевого дня. Тем больше причин обеспечить использование полноценного решение управления системами, которое может принять это во внимание и обновлять также и виртуальные системы.

Исходящие угрозы – иное дело. Виртуальная машина может стать лазейкой для воровства интеллектуальной собственности. Это важно понимать, поскольку виртуальные машины, запускаемые на неконтролируемых носителях, могут быть использованы для похищения ваших данных. Во-первых, если виртуальную среду легко скопировать, это проблема – особенно если вы имеете дело с любыми требованиями соответствия, управляющим доступом к данным (как я объяснил в своей стать еще в 2008 году, (http://technet.microsoft.com/ru-ru/magazine/2008.06.desktopfiles).

Во-вторых, как вы можете вспомнить из моей статьи по RMS и IRM (http://technet.microsoft.com/ru-ru/magazine/2008.11.desktopfiles), эти элементы управления полагаются на ОС в плане предотвращения снимков экрана, печати, и так далее. Однако, эти элементы управления не распространяются на низкоуровневую оболочку – это значит, что если защищенное RMS содержимое отображается на гостевой ОС, размещающая ОС по прежнему может распечатывать отдельные снимки экрана или производить видеозахват.

Хотя технически это и не аналоговое копирование, по сути это похоже на «аналоговую дыру». Я не знаю никаких способов защиты контролируемого DRM содержимого от подобных эксплойтов. Говоря здраво, даже если бы это было возможно, мы бы просто вернулись к проблеме защиты от пользователей с фотоаппаратами и видеокамерами, пользующихся тем же «эксплойтом».

Дефрагментация диска

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

1. Обычно у них возникает два уровня фрагментации: внутри самого контейнера виртуального диска (которую будет видеть каждый из гостей), которую я называю «первичной фрагментацией» и фрагментация собственно файла, содержащего виртуальный диск на дисках размещающей ОС, которую я называю «вторичной фрагментацией».
2. Продукты виртуализации с дисками минимального требуемого размера, растущими по требованию, могут создать вторичную фрагментацию.
3. Функция отката может быстро привести не только к росту занимаемого места, но и к широкой вторичной фрагментации – поскольку по мере того, как она поглощает дополнительное пространство на физическом диске, гостевые ОС начинают соперничать за доступные секторы.
4. В случае дисков, развертываемых по требованию, большинство из них не имеют возможности сжиматься соответственно сокращению требований. Если выделить 40 ГБ, использовать изначально только 10 ГБ, но затем довести требования до 35 ГБ, диск не восстановится сам по себе – а это значит, что у нас будет большой файл, с повышенной вероятностью вторичной фрагментации.

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

Вот один из подходов к защите ваших файлов:

1. Минимизируйте использование технологии отката, поскольку она вызывает чрезмерный рост общего размера файлов на диске и затрудняет дефрагментацию на гостевой ОС, хотя носитель может дефрагментировать файлы, из которых состоит виртуальный диск.
2. Используйте хороший продукт дефрагментации диска на своих гостевых системах с самого начала и запускайте его регулярно.
3. Если вы используете технологию развертывания дисков по требованию:
   А) Используйте служебную программу Sysinternals sdelete.exe следующим образом: sdelete –c drive_letter где drive_letter является томом, который вы хотите обнулить. Например, sdelete –c C: обнулит все неиспользуемое дисковое пространство после дефрагментации.
   б) Используйте любую технологию сжатия виртуальных дисков (если она предоставлена вашим поставщиком), чтобы уменьшить размер контейнера виртуального диска до минимума.
4. Дефрагментируйте тома размещающей ОС, содержащие виртуальные машины.

Многие пользователи игнорируют дефрагментацию. Сам объем писем читателей, которые я получил после моей статьи по дефрагментации дисков в 2007 (technet.microsoft.com/magazinebeta/2007.11.desktopfiles) доказал, что этот вопрос часто понимается неправильно, но его нельзя игнорировать – даже в случае виртуализированных систем.

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