 |
|
|
|
Red Hat Enterprise Virtualization. Полку систем виртуализации прибыло
Red Hat Enterprise Virtualization Давайте вместе изучим текущее состояние портфолио решений виртуализации от Red Hat и посмотрим, что нас ждет в ближайшем будущем В ноябре 2009 года компания Red Hat анонсировала доступность первого продукта из портфолио Red Hat Enterprise Virtualization (RHEV) под названием Red Hat Enterprise Virtualization for Servers (RHEV-S), а уже в марте 2010 года компания IBM назвала данный продукт – помимо конкурентов от VMware, Citrix и Microsoft – в качестве одного из основных в стратегии развития решений виртуализации на платформе x86 [1]. В конце июня 2010 года вышел следующий из продуктов линейки – Red Hat Enterprise Virtualization for Desktops (RHEV-D), включающий в себя реализацию нового открытого протокола для работы с виртуальными рабочими местами SPICE. Впервые компания Red Hat представила возможности виртуализации в своих продуктах еще в 2007 году, когда в состав корпоративного дистрибутива Red Hat Enterprise Linux 5 (RHEL) был включен гипервизор Xen, самый стабильный и функциональный из всех свободных гипервизоров тогда. В 2009 году в версии RHEL 5.4 к Xen прибавился второй гипервизор – KVM. За счет унификации доступа к гипервизору через библиотеку libvirt для конечного пользователя процесс миграции должен пройти практически безболезненно, а поддержка Xen будет осуществляться минимум до 2014 года. Нужно заметить, что KVM уже был доступен в бесплатной Fedora 7, а дистрибутив RHEL 6, который в момент написания статьи находился в состоянии бета-версии, будет поставляться с KVM в качестве основного гипервизора. Несмотря на то, что в дистрибутивах Linux, в том числе и корпоративного уровня, поддержка виртуализации появилась давно, такие продукты мало подходят для промышленного внедрения на большом числе хостов из-за отсутствия средств централизованного управления. Управлять одним-пятью, возможно, даже десятью хостами без средств централизованного управления жизненным циклом виртуальных машин еще можно. Но в масштабах более-менее крупного предприятия, где число хостов достигает сотен, о разумности внедрения такого решения не может быть и речи. Конечно, существовала возможность управления как физическими, так и виртуальными хостами при помощи сервера Red Hat Satellite или Spacewalk. Однако если вы хоть раз сталкивались с лидирующим на рынке продуктом VMware vCenter Server, то понимаете, как сильно ограничен функционал Satellite-сервера с точки зрения управления виртуальными машинами. Основные вендоры корпоративных систем Linux, безусловно, понимали необходимость включения в состав своего портфолио централизованных систем управления виртуализацией. Red Hat пошла по пути приобретения компании Qumranet, чьи наработки, в частности, SolidICE и KVM легли в основу продуктов RHEV, а их основной конкурент на рынке корпоративных Linux-систем – компания Novell – идет по пути альянса с VMWare [3]. Прежде чем перейти к более предметному разговору о RHEV и рассмотрению архитектуры решения, кратко перечислим основные функциональные возможности системы:
Обзор архитектуры На рис. 1 приведена общая архитектура решения RHEV. Перечислим основные компоненты, относящиеся к продукту RHEV-S. Компоненты, входящие в вышедший в конце июня RHEV-D (протокол SPICE и клиенты виртуальных рабочих мест), мы рассмотрим чуть позднее. Рисунок 1. Архитектура RHEV Хосты под управлением RHEV-H (RHEV Hypervisor) Основой решения является гипервизор KVM. Данный гипервизор интегрирован в стандартное ядро Linux, начиная с версии 2.6.20 (январь 2007 года). Благодаря этому хосты под его управлением могут использовать существующие драйверы, механизмы управления процессами и памятью стандартного ядра Linux, NUMA, механизмы безопасности и т.д. Иными словами – все, что идет на улучшение стандартного ядра Linux, улучшает гипервизор KVM. Из требований к хосту необходимо отметить наличие аппаратной поддержки виртуализации при помощи технологий AMD-V или Intel VT. По сути RHEV-H – это специализированный дистрибутив Linux, созданный при помощи утилит пакета livecd-tools с гипервизором KVM, основная задача которого – управление виртуальными машинами. За основу дистрибутива взяты наработки проекта oVirt [4], хотя в текущей версии используется свой интерфейс управления VDSM, разработанный Qumranet для решения SolidICE. VDSM по назначению аналогичен libvirt [5], но обладает несколько более расширенным функционалом. В частности, VDSM осуществляет поддержку протокола доступа к виртуальным рабочим местам SPICE, который используется в RHEV-D. В дальнейшем планируется более глубокая интеграция libvirt в RHEV-H. Из особенностей RHEV-H можно отметить следующее:
В качестве гостевых виртуальных машин поддерживаются RHEL 3,4 и 5, а также Windows Server 2003, Windows Server 2008, Windows XP SP 3 и Windows 7. Для всех перечисленных операционных систем, кроме RHEL 3, имеются драйверы для поддержки паравиртуализированных устройств. RHEV Hypervisor можно установить с USB, CD/DVD или по сети при помощи PXE. В дальнейшем гипервизор может поставляться предустановленным на сервер, как сейчас некоторые вендоры поставляют VMware ESXi. По умолчанию на хосте RHEV-H уже настроен брандмауэр. Также необходимо сказать пару слов касательно вышеупомянутых драйверов VirtIO. VirtIO – это независимый от гипервизора уровень абстракции, естественно, имеющий конкретную реализацию, призванный унифицировать доступ виртуальных машин к оборудованию и предоставляющий набор паравиртуализационных драйверов. В частности, в состав устройств, к которым может осуществляться доступ, входят блочные устройства, сеть, оперативная память через balloon-драйвер, консоль и PCI-устройства. Драйверы VirtIO входят в состав RHEL, начиная с версий 5.3 и 4.8, и должны автоматически загружаться во время установки операционной системы в виртуальном окружении. Драйверы VirtIO для Windows-систем устанавливаются при первой загрузке виртуальной машины. В состав поддерживаемых в настоящий момент драйверов входят как минимум драйверы доступа к блочным устройствам и сеть. Рисунок 2. Установка RHEV-M Хосты под управлением RHEL В качестве хоста для запуска виртуальных машин вполне можно использовать и стандартный RHEL. Согласно текущим соглашениям, при приобретении подписки RHEL на стандартной версии сервера можно запускать до четырех виртуальных машин, а на сервере редакции Advanced число определяется только техническими ограничениями самого хоста. Для работы необходима версия RHEL не ниже 5.4. Как известно, RHEL (и все его клоны) использует в качестве стандартного ядро 2.6.18, вышедшее еще четыре года назад. В версии RHEL 5.4 инженеры Red Hat добавили в ядро поддержку KVM. Особенности настройки системы для работы в качестве хоста инфраструктуры RHEV приведены в документации. В частности, необходимо установить пакеты для обеспечения работы сервиса VDSM. Общее дисковое хранилище Для хранения файлов и шаблонов виртуальных машин необходимо одно или более дисковых хранилищ. Поддерживаются хранилища, подключенные по протоколам NFS, iSCSI или Fiber Channel. При использовании миграции виртуальных машин соответствующее хранилище должно быть доступно всем хостам внутри кластера. Также на рис. 1 показан отдельный NFS-сервер, использующийся для хранения ISO-образов дистрибутивов. Для хранения установочных образов операционных систем в настоящее время можно использовать только NFS. Red Hat Enterprise Virtualization Manager (RHEV-M) Представляет собой единую платформу управления виртуальными серверами и рабочими местами. Текущая реализация основана на решении SolidICE, доставшемся компании Red Hat при покупке Qumranet. В настоящий момент сервисы работают только на платформе Windows Server 2003 R2 (RHEV 2.1) и Windows Server 2008 R2 (RHEV 2.2). Доступ к интерфейсу управления (веб-приложение ASP.NET) возможен только из браузера Internet Explorer. Для работы сервера требуются .NET Framework, Windows PowerShell, WPF, IIS и Microsoft SQL Server. В настоящее время код менеджера закрыт, однако ведется работа по реинженирингу кода с целью обеспечения кросcплатформенности и поддержки различных СУБД. Код переводится на Java, и в дальнейшем менеджер должен будет работать как веб-приложение на платформе JBoss. Начиная с версии 2.2 RHEV-M, менеджер может работать в кластере MSCS, однако и до этого высокую доступность можно было обеспечить при помощи продуктов третьих компаний. В настоящий момент RHEV-M может использовать как локальную аутентификацию, так и аутентификацию посредством Active Directory. В дальнейшем, вероятно, стоит ожидать официальную поддержку возможности работы с другими серверами каталогов, в первую очередь Red Hat Directory Server/Red Hat IPA. В свете планируемого открытия кода интересна дальнейшая судьба управляющего узла проекта oVirt – составной части еще одного проекта Red Hat, фактически призванного обеспечивать функционал, аналогичный RHEV-M, но пока находящегося в стадии разработки и не готового к промышленному применению. На момент написания статьи проект oVirt находился в стадии миграции на хостинг fedorahosted.org, и дорожная карта проекта была недоступна. Консоль управления Как уже было сказано ранее, доступ к веб-порталу управления в настоящий момент возможен только из браузера Internet Explorer 6 и выше. В качестве ОС рабочего места администратора необходимо использовать Microsoft Windows XP SP3 и выше. Внешний вид консоли приведен на рис. 3. Рисунок 3. Интерфейс администратора RHEV-M. Список хостов Кратко «пробежимся» по основным элементам интерфейса. Центральную часть окна занимают вкладки, позволяющие работать с логическими и физическими объектами системы виртуализации, такими как ЦОДы, кластеры, отдельные хосты, дисковые хранилища, пулы и шаблоны виртуальных машин, а также пользователи. В целом назначение тех или иных объектов аналогично соответствующим объектам в других системах виртуализации. По ссылке Configure можно открыть редактор ролей пользователей системы виртуализации. По умолчанию создано несколько типичных функциональных ролей (администратор, пользователь, пользователь VDI и т.д.), однако в зависимости от того, как выстроены процессы на предприятии, можно определить новые роли при помощи десятков отдельных разрешений. Отдельно стоит коснуться сетей. Логические сети можно определять как на уровне ЦОД, так и на уровне кластера (на соответствующих вкладках). Определять их можно как на основе физической топологии, так и на основе функционального назначения (сеть трафика iSCSI/NFS, управляющий трафик, сеть для трафика миграции виртуальных машин, трафика VDI и т.д.). Доступ к графической консоли виртуальных машин из интерфейса администратора возможен по одному из протоколов: SPICE, VNC и RDP. Также все или некоторые из виртуальных машин можно объявить «высокодоступными». В случае выхода из строя физического хоста виртуальные машины автоматически стартуют на другом хосте. Для того чтобы использовать данную возможность, необходимо на всех физических хостах кластера настроить функции управления питания при помощи одной из технологий соответствующего вендора аппаратного обеспечения: iLO, DRAC, IPMI или им подобных (см. рис. 4).
Рисунок 4. Создание нового виртуального сервера Аналога технологии VMware Storage VMotion, позволяющей перемещать файлы дисков виртуальных машин в пределах общего хранилища без прекращения обслуживания, в RHEV в настоящий момент нет. Впрочем, из моих бесед с коллегами из VMware известно, что данный функционал заказчики на практике используют нечасто. Тем не менее, поскольку в qemu-kvm возможность «живой» миграции блочных устройств уже появилась (впервые данная функция была реализована еще в 2009 году набором патчей от IBM), то в конце концов аналог Storage VMotion можно ожидать и в RHEV. Инфраструктура виртуальных рабочих мест (VDI) VDI-часть решения под названием RHEV-D появилась недавно. На рис. 1 компоненты, относящиеся к RHEV-D, включают в себя клиентов виртуальных рабочих мест и протокол SPICE. Кроме того, на сервер RHEV-M возлагается ряд новых функций, включая обеспечение доступа к пользовательскому порталу и брокеру подключений. Исходные коды клиента и сервера SPICE, спецификации протокола, а также инструкции по сборке и другая документация доступны на сайте [7]. Клиент виртуальных рабочих мест работает под ОС Linux или Windows и запускается при помощи веб-браузера с использованием подключаемого модуля в Mozilla или компонента ActiveX в Internet Explorer. Кроме того, клиент должен работать на большинстве терминалов «тонких клиентов» на Windows XP и WindowsCE. К моменту написания статьи, а это менее недели после выхода RHEV-D, автору не было известно ни одного «тонкого клиента», официально поддерживающего RHEV-D, но к моменту выхода номера, вполне возможно, таковые уже найдутся. Для запуска клиента предварительно необходимо зайти браузером на пользовательский портал и выбрать одну из разрешенных к использованию конкретному пользователю виртуальных машин. Благодаря технологии Single Sign On пользователь авторизуется при подключении к порталу, повторно при заходе на виртуальную машину свои имя и пароль вводить не требуется. Безусловно, данный сценарий возможен только при использовании решения централизованной аутентификации. Внешний вид пользовательского портала приведен на рис. 5. В браузере Mozilla портал выглядит аналогично. Рисунок 5. Пользовательский портал RHEV-D Как мы видим на рисунке, пользователю test доступны две виртуальные машины под названиями RHELDesktop1 и WinXP. Для машины WinXP открыты опции выбора протокола доставки рабочего стола. Несколько более подробно остановимся на протоколе удаленного доступа SPICE. В качестве основных характеристик с точки зрения пользователя можно отметить:
*** Выход еще одной компании на рынок серверной виртуализации и VDI – это, безусловно, отличная новость, поскольку каждое новое решение увеличивает конкуренцию в этом сегменте, что в итоге идет на пользу конечному заказчику. Тем более что это первое решение, которое должно стать полностью открытым, и, без сомнения, первое и единственное открытое решение инфраструктуры виртуальных рабочих мест. Практически одновременно с выходом RHEV-D был анонсирован [7] выход первого «чернового» релиза RESTful-интерфейса к Red Hat Virtualization Enterprise Manager. До этого был единственный вариант написания скриптов с использованием PowerShell API. Кроме того, хотелось бы упомянуть совместный с Cisco анонс [8] интегрированного решения Cisco Unified Computing System и RHEV, позволяющего получить виртуальным машинам прямой доступ к устройствам ввода/вывода и повысить защиту виртуальной инфраструктуры за счет технологии Cisco Virtual Network Link. Конечно, как и для каждого нового продукта, для RHEV можно привести ряд «детских» проблем, например, отсутствие истории внедрений или проработанной методологии сайзинга. Однако через данную стадию, когда продукт только вывели на рынок, проходит любое решение. И учитывая ряд потенциальных преимуществ RHEV, которые видны уже сейчас, я бы рекомендовал обратить пристальное внимание на данный продукт.
|
АНДРЕЙ МАРКЕЛОВ, системный архитектор в крупном российском интеграторе. С 2005 года читает авторизированные курсы по ИТ-технологиям. RHCA, MCSE, VCP
| Комментарии |
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
