Я не раз рассматривал этот вопрос во многих статьях и книгах: насколько можно судить об ИТ-инфраструктурах, мы действительно находимся на третьем уровне их развития. Изначально администраторы были сосредоточены на каждом физическом сервере, на котором установлена операционная система. Они ходили по центру обработки данных, указывая на каждый сервер:  «Это  мой контроллер домена; а это моя система Microsoft SQL  Server»  и т.д. Управление осуществлялось только одним компьютером, поскольку на каждом сервере запускается лишь одна операционная система с одним приложением. Затем операционные системы объединились в меньшее число физических серверов, осуществляющих хостинг различных виртуальных машин, и мы вступили в эпоху виртуализации. Мы сосредоточились на каждом экземпляре операционной системы: «Эта система выполняет набор таких-то виртуальных машин; а эта  —  набор других виртуальных машин». Неудивительно, что туры по центрам обработки данных уже непопулярны. Как и в случае с управлением, упростилась подготовка систем, но появились дополнительные элементы гипервизора, требующие управления. Каждой операционной системой все еще управляли индивидуально. Как администратор, вы подключаетесь к серверу через RDP – если вы опытный администратор, то устанавливаете удаленное соединение через System Center Service Manager – но по-прежнему сосредотачиваетесь на одной операционной системе.

Третий уровень

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

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

Неудивительно, что Microsoft System Center 2012 Virtual Machine Manager реализует эти две возможности.

Виртуализация приложений

Читатели, знакомые с технологиями для настольных решений, вероятно, знают, что несколько лет назад Microsoft приобрела компанию под названием Softricity, переименовав ее решение Softricity для виртуализации приложений, Softgrid, в Microsoft Application Virtualization. App-V позволяет приложению работать на операционной системе без установки в ней, с использованием виртуального окружения. Данное окружение имеет виртуальные уровни, такие как файловая система и системный реестр, где постоянно хранятся артефакты приложений (например, файлы, настройки). Виртуализация приложений позволяет сделать доставку приложений очень быстрой. Установки приложений не происходит. Поскольку каждое приложение выполняется в своей виртуальной среде, решается главная проблема приложения – а именно, проблема совместимости приложений, например когда приложение А не может быть на том же экземпляре операционной системы, что и приложение В. Поскольку приложения виртуализованы и работают в своей среде-«песочнице», они не видят друг друга.

Цели виртуализации на сервере и виртуализации на компьютере пользователя различны. Изоляция серверных приложений требуется нечасто. Более того, потоковая передача данных серверных приложений в режиме реального времени – необычное требование. Что необходимо, так это возможность упростить развертывание серверных приложений, которое может иметь описание процесса установки на 100 страниц. Также желательна возможность разрешить перенос серверного приложения между экземплярами операционной системы, так чтобы можно было обслуживать операционные системы без продолжительного простоя приложений, перемещая экземпляр приложения с одной системы на другую.

Для этого технология App-V усовершенствована так, чтобы осуществлять поддержку требований к серверу, с помощью Microsoft Server Application Virtualization (Server App-V), специальной версии App-V, компонента Virtual Machine Manager 2012. Основные отличия от возможностей App-V для настольного решения следующие:

  • поддержка системных служб;
  • компоненты COM, COM+ и DCOM захватываются с помощью инструментов типа Dcomcnfg;
  • виртуализация провайдеров и классов Windows Management Instrumentation (WMI), которые устанавливают приложения;
  • создание локального пользователя и группы;
  • виртуализация Microsoft Internet Information Services (IIS) 6.0 и более ранних веб-сайтов;
  • поддержка виртуализации SQL Server Reporting Services (SSRS);
  • виртуализация настроек приложения и данных, позволяющая установить приложение так, чтобы его можно было легко скопировать и восстановить.

Данная технология означает, что серверное приложение один раз устанавливается в среде Server App-V Sequencer, в которой создается упакованная версия приложения для Server App-V. Процесс установки выполняется полностью, и извлекаются настройки, специфичные для компьютера (например, учетные данные службы, имена хостов, номера портов). Это упакованное приложение Server App-V затем может быть быстро и последовательно развернуто, просто посредством передачи настроек, специфичных для экземпляра, во всех необходимых средах (например, разработки, тестирования, производственной). Этот подход помогает решать многие проблемы, обычно возникающие в процессе развертывания комплексных приложений. К тому же развернутый экземпляр приложения Server App-V и все его данные могут быть легко скопированы и развернуты на другом экземпляре операционной системы, с поддержкой всех состояний приложения. Происходит виртуализация не только серверного приложения, но и относящихся к нему настроек и данных, связанных с упакованным приложением, которые легко могут быть скопированы и восстановлены с помощью команд Server App-V Windows PowerShell, обеспечивающих легкий перенос между экземплярами операционной системы.

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

Шаблоны служб

Server App-V предназначен для использования вместе с шаблонами служб, очередной новой возможностью Virtual Machine Manager 2012. Хотя вы можете применять команды PowerShell для развертывания и работы с упакованными приложениями Server App-V, Server App-V рассчитан на то, чтобы применяться как часть шаблона службы, для которого особенно полезными будут легкое развертывание и переносимость.

Немногие приложения сегодня являются изолированными. Приложения подключаются к службам других операционных систем, используют базы данных и т.д. Шаблоны служб позволяют вам моделировать работу всей службы в новом инструменте проектирования Service Template Designer Virtual Machine Manager. С этим инструментом вы можете создать уровни приложения в виде схемы. Затем вы можете определить свойства каждого требуемого уровня, наряду с шаблонами виртуальных машин и приложениями, которые должны выполняться на этих виртуальных машинах, чтобы уровень функционировал. Далее вы можете создать связи между уровнями и с другими ресурсами, например сетями и хранилищем. Для каждого уровня службы можно настроить исходное, минимальное и максимальное число экземпляров виртуальных машин, составляющих уровень. Это делает возможной масштабируемость, поскольку экземпляры виртуальных машин могут в случае необходимости добавляться или удаляться.

Различные логические сети и уровни хранения могут быть заданы или оставлены в качестве вариантов, чтобы их можно было настроить при полном развертывании экземпляра службы. На экране 1 показана базовая трехуровневая служба, использующая аппаратный балансировщик нагрузки для веб-уровня, который задействует созданную Server App-V версию Apache. Перед вами очередная эффективная возможность шаблонов служб и Virtual Machine Manager 2012 управлять не просто компьютерной средой. Если сеть и структура хранилища были настроены в Virtual Machine Manager (например, с помощью устройства балансировки нагрузки), в дальнейшем эти ресурсы могут автоматически применяться как часть шаблона службы. Когда экземпляр данного шаблона службы развернут, Virtual Machine Manager автоматически создает все требуемые виртуальные машины на основании исходного числа экземпляров виртуальных машин для каждого уровня. Virtual Machine Manager затем автоматически подключается к аппаратному балансировщику нагрузки, формирует новый пул с IP-адресами виртуальных машин, составляющих веб-уровень, и создает новую службу на балансировщике нагрузки, в соответствии с настройками, определенными в выбранном виртуальном IP-шаблоне. Вы сможете за пять минут запустить с нуля сложную многоуровневую службу.

 

Трехуровневая служба
Экран 1. Трехуровневая служба

Чем больше вы погружаетесь в детали функций, доступных на каждом уровне, тем более знакомыми будут настройки, если вы уже работали с шаблонами виртуальных машин Virtual Machine Manager. По существу, каждый из уровней просто использует шаблон, который может иметь дополнительные настройки, являющиеся частью обычного определения шаблона. По сути, шаблон службы просто дает возможность в случае необходимости выполнить дальнейшие настройки существующих шаблонов службы. Первоначально, когда вы перетаскиваете шаблон службы на схеме шаблона, настройки в точности соответствуют исходному шаблону. Тем не менее, вы можете открыть свойства уровня и внести изменения. Такие изменения могут включать модификацию требований к оборудованию виртуальных машин, но они, скорее всего, будут относиться к настройкам приложений или настройкам SQL Server, как показано на экране 2. С помощью данных настроек приложения могут быть добавлены к уровню: так уровень приобретает необходимую функциональность. Это могут быть виртуализованные приложения Server App-V, SQL Server или веб-приложения, а также другие приложения, развернутые через сценарий – содержащие все необходимое для приложений корпоративного класса.

 

Настройка приложения
Экран 2. Настройка приложения

Шаблоны служб предоставляют еще одну важную возможность. Типичная ситуация, когда после развертывания из шаблона виртуальной машины она теряет с ним связь. Если шаблон обновляется, то способа обновить развернутую виртуальную машину с новыми возможностями нет. Но службы, которые развертываются из шаблона службы, поддерживают с ним связь. Вы можете обновить шаблон службы, например с новым Virtual Hard Disk (VHD) операционной системы. Или вы можете изменить спецификации виртуальной машины и затем указать на развернутый экземпляр службы, чтобы выполнить обновление. Если VHD актуальной операционной системы обновлялись, работающие приложения Server App-V копируются со всеми данными и состоянием, VHD новой операционной системы развертывается и настраивается с теми же параметрами, что и заменяемая виртуальная машина, а также переносятся приложения Server App-V. Образ операционной системы восстанавливается, но ни одна настройка или функция приложения не утрачивается. Это только один случай обновления развернутых служб через обновление шаблона. Пример показывает эффективность акцента на службу, а не на базовые экземпляры операционной системы.

Области обновления также поддерживаются шаблонами Virtual Machine Manager. Предположим, я выбираю экземпляр развернутого шаблона службы и запрашиваю обновление шаблона до более новой версии. Развернутая служба будет недоступна, поскольку существующие виртуальные машины в составе развернутого экземпляра службы удаляются и воссоздаются согласно определению нового шаблона службы. С наличием области обновлений развернутая служба может делиться на разные домены, которые по существу являются группами серверов внутри развернутой службы. Когда выполняется обновление, за раз обновляется одна область, а серверы в других областях обновлений остаются доступными, чтобы предоставлять службу и исключить простой. Это ключ к сохранению доступности служб, подобно модели, предлагаемой многими службами публичного «облака», включая Windows Azure.

При создании исходного шаблона службы каждый уровень настраивается по умолчанию с минимальным и начальным числом экземпляров – минимум 1 и максимум 5. Однако эти значения могут быть изменены, будучи частью настроек уровня. Хотя по умолчанию исходное и минимальное число экземпляров – 1, это значение не должно использоваться в производственной среде. Единственный экземпляр уровня не обеспечит его доступности в случае отказа виртуальной машины. К тому же, требуется не меньше двух экземпляров уровня, чтобы обслуживать уровень без простоя, позволяя одному экземпляру обновляться, перезапускаться и даже пересоздаваться, в то время как другой экземпляр обслуживает запросы пользователей. Я рекомендую использовать 2 в качестве минимального значения; чтобы обеспечить доступность во время обслуживания, используйте, как минимум, значение 3. Эти значения определяют только возможности масштабируемости для уровня; это не автоматическое масштабирование службы с помощью Virtual Machine Manager на основе уровня нагрузки. Если уровень нагрузки становится весьма высоким, можно добавить дополнительные экземпляры, но это не произойдет автоматически. Как консоль управления Virtual Machine Manager, так и веб-приложение System Center App Controller позволяют добавлять или удалять дополнительные экземпляры уровня, но это делается вручную. Масштабирование удобно выполнить с помощью PowerShell и других интерфейсов. Довольно простая задача – создать собственные процессы, чтобы отслеживать использование экземпляров уровня и выполнять автоматическое масштабирование в случае необходимости  —  предоставляют System Center 2012 Operations Manager и System Center 2012 Orchestrator.

Скачок от виртуальных машин к службам

Немногие организации в полной мере используют Server App-V и технологию шаблонов служб. В этом нет ничего удивительного, ведь они совершенно новы; организациям нужно время, чтобы понять и принять Server App-V, и еще больше времени, чтобы начать думать о развертывании служб с использованием шаблонов служб, нежели об индивидуальных виртуальных машинах. Но перемены произойдут.

Развертывание многоуровневых служб не всегда идет должным образом. То и дело находятся единичные приложения, которые не будут для организации хорошими кандидатами для превращения в службу. Однако, воспользовавшись преимуществом Server App-V и моделированием службы, можно упростить развертывание и даже управление службами единичных виртуальных машин. Со временем эти технологии могут стать чрезвычайно выгодными для организаций. И, поскольку концепция частного «облака» постепенно принимается, и фокус смещается на приложения, то Virtual Machine Manager, вероятно, станет центральным звеном вашей ИТ-инфраструктуры.

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF