Курс лекций Составитель Соркина В. Е. Введение 12
| Вид материала | Курс лекций |
- Курс лекций. Спб, 639.95kb.
- Курс лекций. Спб, 1118.16kb.
- Курс лекций. Спб, 172.51kb.
- Курс лекций введение в профессию "социальный педагог", 4415.45kb.
- Курс лекций Часть 2 Составитель: кандидат экономических наук Г. Н. Кудрявцева Электроизолятор, 1210.68kb.
- Курс лекций Тамбов 2008 Составитель: Шаталова О. А., преподаватель спецдисциплин тогоу, 1556.11kb.
- Курс лекций Барнаул 2001 удк 621. 385 Хмелев В. Н., Обложкина А. Д. Материаловедение, 1417.04kb.
- Г. П. Щедровицкий Методология и философия организационно-управленческой деятельности:, 3029.36kb.
- Темы контрольных работ по дисциплине «Экономическая теория» спо специальность 080110., 17.75kb.
- Введение в курс. Курс лекций Начертательная геометрия в которой рассматриваются следующие, 848.58kb.
Виртуализация отдельного сервера по сравнению с виртуальной инфраструктурой
Когда пользователи привыкают к виртуализации, они начинают рассматривать варианты,выходящие за рамки виртуализации отдельных серверов, и более интенсивно внедрять технологию виртуализации в ИТ-инфраструктуру, расширяя охватываемую ей область с отдельных сервером сначала до комплексных систем, а затем до центров обработки данных или организаций. По мере того, как виртуализация становится стандартной функцией различных платформ, пользователи могут быть все более уверены в том, что по крайней мере некоторые возможности виртуализации будут доступны на всех их системах. Когда базовые функции виртуализации сочетаются с высокоуровневыми средствами управления, которые специально предназначены для управления несколькими виртуальными системами, они могут стать основой для всей виртуальной инфраструктуры. В виртуальных инфраструктурах несколько виртуальных систем рассматриваются как гибкий пул ресурсов, которые могут динамически выделяться в зависимости от изменения рабочей нагрузки или перерывов в работе. Целью создания таких виртуальных инфраструктур является снижение стоимости приобретения и выполнение мероприятий, направлены на снижение эксплуатационных расходов. Так как виртуализация изолирует рабочие нагрузки от аппаратной части серверов, на которых они размещаются, возможно перемещение рабочих нагрузок с одного компьютера на другой без нарушения их прикладного окружения. Например, некоторые реализации виртуальных машин позволяют сохранять все состояние работающей виртуальной машины в стандартный файл, который u1084 может передаваться по сети. Рабочие нагрузки можно переносить с одного физического сервера на другой, просто копируя этот файл по сети. Выполняющиеся на виртуальной машине приложения продолжают работать в том же окружении (включая ОС и ПО промежуточного слоя), для их работы не нужны сведения о фактическом физическом размещении. Возможность передавать виртуальные рабочие нагрузки по сети таким способом позволяет выполнять ряд операций, значительно сокращающих эксплуатационные расходы,включая:
Управление планировыми и внеплановыми простоями. Администраторы могут обновлять оборудование или заменять старый сервер на новый без переустановки ОС или приложений. При совместном использовании с кластерными функциями высокой доступности эта возможность также может использоваться для перезапуска рабочих нагрузок на резервном хосте в случае отказа основного хоста.
Обслуживание сервисных уровней. Возможность миграции виртуальных машин в сети с помощью простого копирования файлов также упрощает реализацию балансировки загрузки серверов. Рабочие нагрузки можно перемещать с сильно загруженных серверов на менее загруженные машины. Внедрение виртуализации может помочь повысить доступность системы различными способами. Во-первых, сокращение затрат на приобретение серверов позволяет консолидировать средства, которые могут быть инвестированы в средства для реализации автоматического поддержания высокой доступности и восстановления при аварии. Кроме того, консолидация нескольких серверов в виртуальные машины на меньшем количестве физических систем уменьшает общее количество оборудования и, следовательно, сокращает количество потенциальных причин отказов, вызванных неисправностью оборудования.Сокращение количества серверов в результате консолидации также упрощает инфраструктуру, облегчая создание ее резервной копии для восстановления. Так как виртуальные машины не привязаны к физическому оборудованию, на котором они размещаются, администраторы имеют возможность сконфигурировать резервную инфраструктуру на оборудовании, класс которого отличается от основной платформы. Т. е. для резервной системы, обычно работающей в резервном режиме, может использоваться более дешевое оборудование. Хотя производительность таких систем при передаче на них производственных рабочих нагрузок будет меньше, клиенты обычно соглашаются на снижение производительности на ограниченный период времени после аварии. Другим возможным способом сокращения стоимости обеспечения резервной системы является использование тестовых систем/систем для разработки в качестве резервных. Эти системы могут быть предварительно сконфигурированы с виртуальным образом, который остается в режиме готовности, пока он не потребуется для восстановления производственных рабочих нагрузок в случае аварии. Ресурсы могут динамически забираться у систем для разработки или тестовых систем и передаваться производственной системе, когда они потребуются. Виртуализация быстро становится стандартной частью ИТ-инфраструктуры, как в области оборудования, так и в области ПО. Почти все основные операционные системы включают поддержку виртуализации, новые опции для платформ виртуальных машин анонсируются. В конечном счете, виртуализация может изменить конфигурирование или обслуживание центров обработки данных. Однако, процесс развертывания виртуальной инфраструктуры начинается с выбора платформы виртуальной машины для исходных приложений, и при этом выборе должны рассматриваться некоторые важные факторы.
Позиционирование архитектур виртуальных машин
Компания IBM уже давно разрабатывала возможности виртуализации для мэйнфреймов. Позднее компания VMware представила ПО виртуальных машин для платформы x86. Компания VMware впервые начала поставлять сервер предприятия ESX Server в 2001 году. С тех пор на рынке появилось несколько альтернатив продуктам VMware. Одной из первых серверных платформ виртуальных машин, получивших значительный успех на рынке после продукции VMware, стала платформа Microsoft Virtual Server, поставки которой начались в 2004 году. Затем появился гипервизор виртуальных машин Xen, основанный на ПО с открытым кодом. Гипервизор Xen был интегрирован в несколько ведущих дистрибутивов Linux, первым из которых стал Novell’s SUSE Linux Enterprise Server 10 (SLES 10), в котором виртуализация на основе Xen появилась в 2006 году. Реализация платформы виртуализации Microsoft Hyper-V, которая будет интегрироваться в новую ОС Windows Server 2008, очень похожа на Xen и обеспечивает совместимость с реализациями Xen, например, в SLES 10. 1 Для миграции необходима некоторая общность оборудования хостов. Например, если платформа виртуальной машины использует виртуализацию на аппаратном уровне, например, Intel VT, то резервный сервер также должен быть сконфигурирован с Intel VT. VMware, SLES 10 и Windows Server 2008 созданы для виртуализации серверов. Однако, некоторые ключевые различия в реализации этих платформ виртуализации могут оказать значительное влияние на требования к их развертыванию и управляемость. Для понимания этих различий необходимо подробно рассмотреть организацию платформ виртуальных машин.
Основные технические аспекты виртуализации
Одним из основных достоинств виртуализации является возможность одновременной работы нескольких ОС на одном сервере. Наиболее гибким способом решения этой задачи является использование виртуальных машин, которые программно создают полную компьютерную систему и могут использоваться и управляться как приложения. Реализация платформы виртуальной машины имеет несколько специфичных требований, включая следующие:
Планировщик. Этот компонент предоставляет разным виртуальным машинам доступ к физическим ресурсам. Планировщик использует механизм квантования времени с политиками, основанными на приоритетах и резервах, назначенных администратором виртуальным машинам
-
Управление памятью. Этот компонент выделяет виртуальную память различнымвиртуальным машинам на сервере и освобождает ее.
Машина состояний. Этот компонент содержит информацию о текущем состоянии виртуальной машины, включая процессор, память, устройства и т. д.
Хранение данных и сеть. Эта функция обеспечивает совместный доступ нескольких виртуальных машин к ресурсам хранения данных и сети. Для выполнения этой задачи компонент должен обеспечивать мультиплексный (т. е. с квантованием времени) доступ к реальным устройствам (например, адаптерам шины хоста или сетевым картам) из виртуальных машин. Мультиплексирование должно быть согласованным (т. е. запись и чтение данных должны осуществляться корректно, независимо от порядка выполнения виртуальных машин), изолированным (т. е. сбой ПО во время операций ввода/вывода на одной виртуальной машине не должен вызывать нестабильность другой виртуальной машины) и защищенным (т. е. виртуальная машина не должна получать информацию об операциях ввода/вывода, выполняемых на другой виртуальной машине).
Виртуальные устройства. Эта функция является связующим звеном между виртуальным и физическим миром. Она предоставляет выполняющейся на виртуальной машине ОС информацию об устройствах, которые ведут себя так же, как их реальные аналоги. Таким образом, приложения могут получить доступ к устройствам также, как если бы они выполнялись на физическом сервере (например, с помощью драйвера устройства — см. ниже).
Драйверы виртуальных устройств. Эти компоненты устанавливаются в гостевой ОС, выполняющейся на виртуальной машине, чтобы приложения смогли получить доступ к виртуальному представлению оборудования и каналов ввода/вывода также, как они получают доступ к физическому оборудованию и каналам ввода/вывода физической машины.
Двоичная трансляция. Эта функция была необходима в первых поколениях реализаций виртуальных машин для архитектуры x86, которая не была предназначена для виртуализации, и поэтому, в некоторой степени не обладала функциональностью, необходимой для виртуальных машин. Традиционно платформы виртуальных машин выполняли процедуру трансляции или эмуляции при каждом попытке гостевой ОС выполнить «привилегированную» инструкцию (т. е. низкоуровневую инструкцию, права на выполнение которой для поддержания согласованности были только у ОС хоста). Позднее Intel и AMD изменили свои процессоры для поддержки виртуализации. Эта поддержка разрешает нескольким виртуальным машинам выполнять привилегированные инструкции, которые могут определяться и выполняться непосредственно на аппаратном уровне. Поэтому платформам виртуальных машин более не требуется выполнять эту функцию на уровне ПО.
Интерфейс управления. Платформа виртуальной машины должна предоставлять различные интерфейсы управления ее работой и контроля виртуальных машин, выполняющихся на хосте. Этот интерфейс должен поддерживать множество операций, например, создание и конфигурирование виртуальных машин, контроль их работы и т. д. Кроме того, необходимо обеспечить интерактивный интерфейс (используемый администраторами) и программный интерфейс (используемый другими программами через интерфейс прикладного программирования (API)). Также в современной ИТ-инфраструктуре необходимо, чтобы интерфейс управления был полностью доступен по сети для дистанционного конфигурирования и управления хостом виртуальных машин и самими виртуальными машинами.
Сравнение реализованной в операционной системе виртуализации и специализированного программного обеспечения для виртуализации. Платформы виртуальных машин должны в той или иной форме реализовывать перечисленные выше компоненты и функции. На практике способы реализации этих функций и их взаимодействия сильно различаются в платформах виртуальных машин. Основные функции платформы виртуальной машины — планировщик, управление памятью, и машина состояний (т. е. компоненты для выделения виртуальным машинам основных вычислительных ресурсов, например, процессора и памяти). В новых платформах виртуальных машин, например, Xen and Microsofts Hyper-V, эти функции имеют общее название «гипервизор». Гипервизор также отвечает за создание разделов и поддержание жесткой изоляции между разделами. Профессиональная платформа виртуальной машины VMware реализует эти функции в пакете программного обеспечения ESX Server, который согласно описанию также основан на механизме, похожем на гипервизор. Несомненно, нет больших различий в том, как: Hyper-V, Xen и ESX Server выполняют фундаментальный контроль виртуальных машин13.Однако, реализации Xen, например, SLES 10 и реализация Microsoft Hyper-V, фундаментально отличаются от VMware ESX Server на гипервизорном уровне и на уровне обработки процедур ввода/вывода — т. е. в двух аспектах работы, которые являются наиболее критичными для виртуальных инфраструктур. Все три реализации подразумевают установку драйверов виртуальных устройств в гостевой ОС, которая взаимодействует с драйверами реальных устройств для выполнения фактических операций ввода/вывода. Однако u1074 в VMware ESX Server драйверы реальных устройств находятся в самом гипервизоре. В Xen и Hyper-V драйверы реальных устройств находятся в специальной административной виртуальной машине со стандартной ОС, например, SLES 10 или Windows Server 2008. Используя высокопроизводительный канал, драйверы виртуальных устройств в гостевых операционных системах взаимодействуют со стандартными драйверами устройств в административной ОС, выполняющей непосредственно аппаратные операции ввода/вывода (см. Рис. 1). В результате административная ОС выполняет все функции хранения данных и работы с сетью, в то время как в VMware эти функции выполняются в гипервизоре. Хотя различие этих реализаций может показаться незначительным, оно может оказать значительное влияние на развертывание и управление платформами виртуальных машин. Виртуализация ввода/вывода с помощью драйверов реальных устройств в стандартной операционной системе может обеспечить следующие преимущества:
Совместимость. Выполняющиеся на виртуальной машине операционные системы могут получить доступ к устройствам, используя стандартные драйверы устройств (т. е. те самые драйверы, которые используются при установке административной ОС непосредственно на оборудование). Например, если в качестве административной ОС используется дистрибутив Linux, например, SLES 10, гостевая ОС получит доступ ко всем драйверам устройств, поддерживаемым SLES 10. А если в качестве административной ОС используется Windows Server 2008, то гостевая ОС получит доступ к любому оборудованию, поддерживаемому этой версией Windows. VMware, напротив, требует, чтобы пользователи u1087 получали драйверы устройств, специально разработанные для ESX Server. Хотя модель драйвера устройства ESX Server похожа на модель драйвера для Linux, разработчики должны используя свой код создавать специальную версию для VMware — что означает для них тестирование и поддержку еще одной платформы. Как правило, разработчики драйверов сначала сосредотачиваются на Windows и/или Linux, и лишь затем начинают заниматься другими платформами, например, ESX Server. Поэтому пользователи VMware могут не сразу получить виртуализованный доступ к новому оборудованию.
Надежность и безопасность. Перенося задачу управления драйверами устройств, а также функциями доступа к устройствам хранения данных и сети в административную ОС, сам гипервизор становится проще и требует меньше кода (по этой причине архитектура гипервизоров, похожих на Xen и Microsoft Hyper-V, обычно называется «тонкой»). Сокращение кода может увеличить надежность гипервизора просто потому, что в нем будет меньше возможностей для сбоев. Сокращение кода также повышает безопасность, так как уменьшает «поле для атаки» через которое может осуществляться вторжение. Безопасность гипервизора также увеличивается благодаря отсутствию функций доступа к устройствам хранения данных и к сети, в которых может быть много уязвимостей. Подводя итог можно сказать, что если функции виртуализации реализованы в стандартных операционных системах, они могут использовать преимущества проактивных функций для поддержания защищенной инфраструктуры, например, службы каталогов для авторизации и аутентификации.
Интеграция с существующей инфраструктурой. Использование стандартных драйверов устройств и традиционных функций доступа к сети и устройствам хранения данных хостом виртуальной машины облегчает интеграцию виртуальных машин в существующие системы. Поддержка стандартных драйверов устройств позволяет виртуальным машинам получить доступ к фактически используемому оборудованию. Неразрывное использование функций доступа к системам хранения данных и сети означает, что пользователи могут разворачивать в точности те же расширения в виртуальной и физической инфраструктурах.
Унификация эксплуатации. Если административная операционная система является стандартной, например, Windows или Linux, пользователи могут использовать стандартные инструменты системного управления для хостов виртуальных машин. Унификация применима и интерактивным инструментам (например, консолям и графическим интерфейсам) и к программным интерфейсам (т. е. интерфейсам прикладного программирования, используемым дополнительными приложениями). Реализация виртуализации в ОС также повышает уровень интеграции с существующей инфраструктурой, позволяя использовать существующие инструменты и процессы для обновления, поддержки и т. д.