Технология виртуализации

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

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

Графическая оболочка обеспечивает взаимодействие пользователя с приложением виртуальной машины, позволяя настраивать создаваемые виртуальные машины под свои нужды и управлять ее работой.

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

Хостовая операционная система и эмулятор распределяют между собой ресурсы реальной ЭВМ и составляют второй уровень иерархии.

Также хостовая операционная система занимается управлением работающих на ней приложений и распределением между ними ресурсов реальной ЭВМ.

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

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

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

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

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

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

Все существующие мониторы виртуальных машин можно разделить на четыре вида:

1. Использующие аппаратную виртуализацию.

2. Использующие аппаратно-программную виртуализацию.

3. Использующие программную виртуализацию.

4. Использующие доменную виртуализацию.

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

Существуют три типа программной эмуляции инструкций:

1. Полная эмуляция инструкций.

2. Выборочная эмуляция инструкций.

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

Однако, интерпретация каждой инструкции приводит к значительному расходу ресурсов реальной ЭВМ и снижает быстродействие приложений, работающих в гостевой операционной системе. Принимая во внимание, что современные серверы и персональные ЭВМ обладают все большей производительностью, виртуализация, с использованием интерпретации инструкций, приобретает все большую популярность. Яркими представителями этого класса виртуальных машин являются: Microsoft Virtual PC, Bochs, Simics и другие.

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

Например, аналогичный способ виртуализации был использован при эмуляции ЭВМ А15К на ЭВМ «Багет 23В», позволивший без изменения запускать программное обеспечение, разработанное на языке низкого уровня А-15, на современной вычислительной технике. Это дало возможность значительно ускорить модернизацию бортовой вычислительной техники, минимизировать трудоемкость и сохранить без изменений годами отлаживаемое программное обеспечение, а, следовательно, значительно повысить конкурентоспособность разрабатываемого продукта.

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

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

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

К виртуальным машинам этого типа относятся, например: VMware Workstation, VMware Server, Serenity Virtual Station и другие.

В третьем случае, эмулируются API гостевой операционной системы. API (Application Programming Interface) – это интерфейс прикладного программирования.

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

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

К сожалению, у такой системы виртуализации есть ряд недостатков:

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

2. Операционные системы активно развиваются, вносятся корректировки в API и добавляются новые возможности, поэтому эмуляторы API быстро устаревают, и необходимы большие затраты трудоемкости для их модернизации.

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

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

В качества примера виртуальных машин, использующих эмуляцию API, можно привести такие продукты, как:

— UML (User Mode Linux), встраиваемый в ядро Linux и позволяющий запускать несколько копий операционной системы на одном компьютере.

Источник

Технологии виртуализации

Одной из наиболее существенных технологических новаций, лежащих в основе облачных вычислений, являются технологии виртуализации.

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

Основные понятия технологии виртуализации

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

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

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

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

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

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

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

Гостевая операционная система – это операционная система, устанавливаемая на созданную виртуальную машину. В качестве гостевых операционных систем можно использовать Window, Linux и др.

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

Хостовая операционная система и эмулятор распределяют между собой ресурсы реальной ЭВМ и составляют второй уровень иерархии. Хостовая операционная система занимается управлением работающих на ней приложений и распределением между ними ресурсов реальной ЭВМ.

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

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

Гостевые операционные системы управляют работой своих приложений в рамках выделенных эмулятором ресурсов.

Рассматривая технологию виртуализации, необходимо изучить эмулятор виртуальных машин, а именно монитор виртуальных машин, являющийся базовой частью технологии виртуализации.

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

Доменная виртуализация основывается на логическом распределении ресурсов на отдельные части (домены). В основном она используется в мэйнфреймах. Этот тип виртуализации появился первым и использовался для распределения ресурсов больших ЭВМ между отдельными пользователями.

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

Существуют три типа программной эмуляции инструкций: полная эмуляция инструкций, выборочная эмуляция инструкций, эмуляция API.

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

Интерпретация каждой инструкции приводит к значительному расходу ресурсов реальной ЭВМ и снижает быстродействие приложений, работающих в гостевой операционной системе. Современные серверы и персональные ЭВМ обладают все большей производительностью. Поэтому виртуализация, с использованием интерпретации инструкций, приобретает популярность. Представителями данного класса виртуальных машин являются: Microsoft Virtual PC, Bochs, Simics и др.

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

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

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

К виртуальным машинам этого типа относятся, например: VMware Workstation, VMware Server, Serenity Virtual Station и др.

В третьем случае, эмулируются API гостевой операционной системы. API (Application Programming Interface) – это интерфейс прикладного программирования.

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

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

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

Однако у такой системы виртуализации есть недостатки:

Однако использование эмуляции API позволяет избежать значительных потерь производительности.

В качестве примера виртуальных машин, использующих эмуляцию API, можно привести такие продукты, как:

Безопасность в виртуальных облаках

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

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

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

Для анализа этой опасности попытаемся для начала понять природу гипервизора. Консультант по безопасности и одного из основателей компании Nemertes Research Group Inc. Андреаса Антонопулоса (Andreas Antonopoulos) считает, что «Гипервизоры – узкоспециализированные устройства. Обычный гипервизор меньше и более специализирован, чем операционная система общего назначения, и меньше открыт для атак, так как у него меньше или вообще нет открытых во вне сетевых портов. Гипервизор нечасто меняется и не выполняет приложения сторонних разработчиков. У гостевой ОС, которая может стать жертвой атак, нет прямого доступа к гипервизору. Гипервизор прозрачен для сетевого трафика, если не считать входящий и исходящий трафик выделенного интерфейса управления гипервизором. На настоящий момент не задокументировано ни одной атаки на гипервизоры, что говорит о низкой вероятности таких атак. Поэтому хотя масштаб разрушений в случае компрометации гипервизора может быть огромным (компрометация всех гостевых систем), вероятность такого события низка, потому что уязвимость гипервизора и вероятность атаки очень низкие».

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

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

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

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

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

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

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

При таком подходе может использоваться одна из форм маркировки, подобно той, что применяется в многоуровневых ОС (Trusted Solaris или SE-Linux). Можно также использовать базу данных управления конфигурацией для отслеживания запросов арендаторов на изоляцию приложений.

Билл Майне (Bill Meine), архитектор ПО и специалист по облакам в компании Blackhawk Network отмечает, что во всех этих примерах проблемы возникают, когда арендатору также требуется максимальная защита компонентов приложения от отказов по стандартным причинам, например, из-за необходимости высокой доступности. Дело не в том, что такую схему нельзя заставить работать, а в стоимости всех несовместимых и недогруженных фрагментов сервера (которые нельзя продать), которую приходится учитывать в цене сервиса.

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

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

Источник

Зачем же нужна виртуализация?

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

Типы виртуализации

Виртуализация приложений – достаточно интересное, и относительно новое направление. Рассказывать здесь подробно о нем я не буду, поскольку это тема для целой отдельной статьи. Коротко говоря, виртуализация приложений позволяет запускать отдельное приложение в своей собственной изолированной среде (иногда называется «песочница», sandbox). Такой способ помогает решить множество проблем. Во-первых – опять же безопасность: приложение, запущенное в изолированной среде – не способно нанести вред ОС и другим приложениям. Во-вторых – все виртуализированные приложения можно обновлять централизованно из одного источника. В-третьих – виртуализация приложений позволяет запускать на одном физическом ПК несколько разных приложений, конфликтующих друг с другом, или даже несколько разных версий одного и того же приложения. Более подробно о виртуализации приложений можно посмотреть, к примеру, в этом вебкасте: www.techdays.ru/videos/1325.html Возможно, однажды я даже напишу статью на эту тему.

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

Но кроме этого, виртуализация серверов может использоваться и в продакшн-среде. Причин тому много.
Виртуализация позволяет сократить количество серверов благодаря консолидации, то есть там, где раньше требовалось несколько серверов – теперь можно поставить один сервер, и запустить нужное число гостевых ОС в виртуальной среде. Это позволит сэкономить на стоимости приобретения оборудования, а так же снизить энергопотребление, а значит и тепловыделение системы – и, следовательно, можно использовать менее мощные, и, соответственно – более дешевые системы охлаждения. Но у этой медали есть и обратная сторона, и не одна. Дело в том, что при внедрении решений на базе виртуализации, скорее всего придется покупать новые сервера. Дело в том, что виртуальные сервера используют аппаратные ресурсы физического сервера, и, соответственно – понадобятся более мощные процессоры, большие объемы оперативной памяти, а так же более скоростная дисковая подсистема, и, скорее всего – большего объема. Кроме того, некоторые системы виртуализации (в частности – MS Hyper-V) требуют поддержки процессором аппаратных технологий виртуализации (Intel VT или AMD-V) и некоторых других функций процессора. Многие процессоры, которые выпускались до недавнего времени, в частности – все x86_32bit – этим требованиям не удовлетворяют, и поэтому от старых, хотя и вполне рабочих серверов придется отказаться. Однако же, один более мощный сервер скорее всего будет стоить намного дешевле нескольких менее мощных, да и старые сервера, скорее всего давно пора менять из-за морального устаревания.

Есть еще один очень важный момент: виртуализация северов позволяет до предела упростить администрирование инфраструктуры. Главное преимущество, которое оценят все сисадмины – это возможность удаленного доступа к консоли виртуальных серверов на «аппаратном», точнее – «вирутально-аппаратном» уровне, независимо от установленной гостевой ОС и ее состояния. Так, чтобы перезагрузить «зависший» сервер, теперь не нужно бежать в серверную, или покупать дорогостоящее оборудование типа IP-KVM-переключателей, достаточно просто зайти в консоль виртуального сервера и нажать кнопку «Reset». Помимо этого, виртуальные сервера поддерживают технологию моментальных снимков (о ней см. мою предыдущую статью), а так же бэкап и восстановление виртуальных систем намного легче.

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

Так же, хочется напомнить, что в виртуальной среде могут действовать особые правила лицензирования ПО (в частности, покупка лицензии на Microsoft Windows Server 2008 Enterprise позволяет использовать бесплатно четыре копии ОС в качестве гостевой, а Microsoft Windows Server 2008 Datacenter вообще разрешает использовать неограниченное число гостевых ОС при условии полного лицензирования по процессорам).

Еще нельзя не упомянуть о технологиях отказоустойчивости. Физические сервера, на которых запускаются виртуальные машины, могут быть объединены в кластер, и в случае отказа одного из серверов – автоматически «переезжать» на другой. Полной отказоустойчивости добиться не всегда возможно (в частности, в MS Hyper-V такой «внезапный переезд» будет выглядеть так же, и иметь такие же возможные последствия, как внезапное обесточивание сервера), но возможные простои сильно сократятся: «переезд» занимает несколько минут, тогда как ремонт или замена самого сервера может занять часы, а то и дни. Если же «переезд» виртуальных машин происходит в штатном режиме, то он может пройти совершенно незаметно для пользователей. Такие технологии у разных вендоров называются по-разному, к примеру у MS она называется «Live Migration», у VMware – Vmotion. Использование таких технологий позволит проводить работы, связанные с выключением сервера (к примеру – замену некоторых аппаратных компонент, или перезагрузку ОС после установки критических обновлений) в рабочее время и не выгоняя пользователей из их любимых приложений. Кроме этого, если инфраструктура построена соответствующим образом – запущенные виртуальные машины могут автоматически перемещаться на менее нагруженные сервера, или же наоборот «разгружать» наиболее загруженные. В инфраструктуре на базе технологий Microsoft для этого используются System Center Virtual Machine Manager и Operations Manager.

В заключение темы по виртуализации серверов — отмечу, что виртуализация не всегда одинаково полезна. В частности, не всегда будет хорошей идеей переносить в виртуальную среду высоконагруженные сервера, а особенно — высоконагруженные по дисковой подсистеме — это «тяжелые» СУБД, Exchange Server, особенно — роль Mailbox Server, и прочие высоконагруженные приложения. А вот сервера с меньшей нагрузкой (контроллеры доменов AD, WSUS, всевозможные System Center * Manager, веб-сервера) виртуализировать можно и даже нужно. Замечу, кстати, что именно с контроллерами доменов — очень желательно, чтобы хотя бы один из контроллеров был «железным», то есть не виртуальным. Нужно это потому, что для корректной работы всей инфраструктуры желательно, чтобы при запуске всех остальных серверов хотя бы один КД уже был доступен в сети.

Резюме

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

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

Если же вам нужно освободить место в стойке, снизить энергопотребление систем, избавиться от «серверного зоопарка» — то ваше решение – виртуализация серверов.

Недостатки – в принципе, те же, что и у терминальных решений:

Надеюсь, моя статья окажется для кого-то полезной. Благодарность и конструктивную критику, как всегда, можно высказать в комментариях.

Источник