пятница, 22 октября 2010 г.

Установка приложений в среде VMware View 4.5 + ThinApp 4.6

Рабочие станции, пускай и виртуальные, предназначены, в первую очередь, для запуска пользовательских приложений. А чтобы запустить приложение, требуется его установить (а иногда и купить). По этой причине сегодня мы рассмотрим различные варианты установки приложений, виртуализованных с помощью VMware ThinApp 4.6, которые можно использовать для виртуальных рабочих станций, а в частности - для VMware View 4.5.

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

Копирование и установка приложений вручную. Администратор может выполнять установку отдельных приложений, подключаясь к рабочей станции через vSphere Client или RDP. Кроме того существует простая и функциональная утилита psexec, позволяющая запускать программы и выполнять команды на удаленном компьютере без необходимости отвлекать пользователей от работы. Для установки приложений можно воспользоваться командой вроде этой:
psexec \\<имя_компьютера> /u <имя_пользователя> msiexec /i \\<имя_сервера>\<путь_к_установочному_файлу> /qn


Для некоторых приложений вы можете разрешить рядовым пользователям без административных прав самостоятельно производить установку. В этом случае приложение будет установлено в каталог %AppData% пользователя вместо %ProgramFiles% и будет доступно лишь этому пользователю. Такой вариант может является предпочтительным для  приложений вроде текстовых редакторов или программ обмена мгновенными сообщениями. Для включения режима индивидуальной установки при упаковке приложения с помощью ThinApp требуется отредактировать параметр MSIDefaultInstallAllUsers в файле Package.ini и установить его значение в 0.

Для этого выполните следующие действия. При создании пакетированного приложения с помощью ThinApp в окне Package Settings выберите Generate MSI Package.


Перед финальной сборкой в окне Ready to Build нажмите Edit Package.ini.

При желании вы можете задать параметр MSIDefaultInstallAllUsers=2 и разрешить как административную установку для всех пользователей, так и индивидуальную установку (в зависимости от прав, которыми обладает учетная запись, от имени которой был запущен установочный файл).

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

Использование средств электронной дистрибуции ПО (например, Microsoft SCCM 2007). Наиболее функциональный вариант из представленных, позволяет полностью автоматизировать процесс установки, а также проводить инвентаризацию ПО, хотя и требует покупки дополнительных лицензий, установки агентов и настройки серверов управления.

Наконец, начиная с версии 4.5 в VMware View есть собственные встроенные механизмы публикации приложений, виртуализованных с помощью ThinApp. Публиковать приложения можно на пул или на отдельные виртуальные рабочие станции.

VMware View предоставляет на выбор два режима установки:
  • В полном (Full) режиме приложение устанавливается на виртуальную рабочую станцию, создает ярлык на рабочем столе и настраивает ассоциации с нужными типами файлов. Процесс установки выполняется в фоновом режиме и не требует от пользователей каких-либо действий. Запуск приложения выполняется с диска виртуальной рабочей станции.
  • В потоковом (Streaming) режиме на рабочем столе пользователя создается ярлык, указывающий на исполняемый файл .exe приложения, расположенный на файловом сервере. Запуск приложения выполняется с общей сетевой папки файлового сервера. Такой вариант установки с одной стороны позволит сэкономить место на хранилище, на котором располагаются диски виртуальных рабочих станций, особенно в случае, когда пользователи запускают одинаковый набор приложений, с другой - приведет к увеличению нагрузки на сеть. Также учтите, что в случае отсутствия доступа к файловому серверу, например, при запуске ВМ в Local Mode режиме, приложения не смогут запуститься.

Пример публикации приложений с помощью VMware View
Перед тем, как опубликовать приложение вам потребуется соответствующим образом упаковать его с помощью Setup Capture, входящего в состав VMware ThinApp 4.6. Для режима полной установки достаточно будет создать .msi файл, содержащий нужное приложение.

Для Streaming режима перед сборкой вам потребуется отредактировать файл настроек Package.ini и установить параметр MSIStreaming=1. В этом случае после создания пакета размер .msi файла не превысит нескольких мегабайт и для корректной установки вам потребуется сохранять его вместе с созданным .exe файлом.

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

Запустите консоль View Administrator добавьте общую папку файлового сервера в список репозиториев: View Configuration -> ThinApp Configuration кнопка Add Repository.

В поле Display Name введите имя репозитория, в поле Share path введите UNC путь к общей папке, содержащей упакованные приложения (в формате \\<имя_сервера>\<имя_папки>). При желании можете добавить дополнительное описание в поле Description.

Нажмите Save.

Просканируйте и добавьте приложения в список доступных. В консоли View Administrator выберите Inventory -> ThinApps. На вкладке Summary нажмите Scan New ThinApps.

Выберите одно из расположений, добавленных ранее и папку для сканирования, и нажмите Next.

Выберите одно или несколько (с помощью зажатых клавиш CTRL или SHIFT) приложений из списка доступных и нажмите Scan.

После завершения сканирования вы увидите перечень добавленных приложений. Нажмите Finish.

Добавленные приложения появятся в окне на вкладке Summary.

Для назначения приложений вы можете воспользоваться той же вкладкой Inventory -> ThinApps. Выберите необходимое приложение из списка и нажмите Add Assigment и в контекстном меню выберите область назначения - на пул (Pools...) или на рабочие станции (Desktops...).

В открывшемся окне выберите один из двух доступных типов установки (Installation type): Streaming или Full и с помощью кнопки Add... добавьте один или несколько пулов или рабочих станций на которые требуется назначить приложение. Нажмите OK для сохранения настроек.

Теперь пользователям достаточно будет подключиться к своим рабочим станциям и приложение будет автоматически установлено. Учтите, что при использовании Full режима в зависимости от размера приложения для копирования и установки может потребоваться некоторое время, поэтому ярлык может появится не сразу.

Обновление опубликованных приложений
Установка приложений - половина дела. Когда-нибудь вам придется их обновить. ThinApp предоставляет несколькомеханизмов по обновлению приложений, однако их использование совместно с VMware View имеет свои нюансы.

Для обновления приложения вам потребуется выполнить следующие шаги:
  1. Удалить назначенное приложение (Remove Assigment) с пула или рабочих станций.
  2. Подождать, пока все пользователи войдут на свои рабочие станции, чтобы устаревшая версия приложения удалилась.
  3. Удалить устаревшее приложение из списка ThinApps.
  4. Скопировать обновленную версию приложения на файловый сервер и добавить его в список ThinApps.
  5. Назначить обновленную версию приложения на пул или рабочую станцию.
  6. Подождать, пока все пользователи войдут на свои рабочие станции, чтобы обновленная версия приложения установилась.
Не слишком просто и быстрый вариант, учитывая, что из-за некоторых пользователей процесс обновления может растянуться на несколько дней. С другой стороны, для Linked Clones машин также может быть выполнен Refresh, который вернет виртуальную машину к исходному состоянию и удалит установленные приложения.

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

Более корректным вариантом является использование встроенного механизма обновления, поддерживаемого в ThinApp - исполняемый файл обновленной версии приложения переименовывается из <имя_приложения>.exe в <имя_приложения>.1 (например, "Adobe Reader.1") и помещается в ту же папку, что и исполняемый файл старого приложения. При следующем запуске приложение автоматически обнаружит наличие обновленной версии и запустит ее. При этом пользователи, работающие с текущей версией приложения, смогут продолжать с ней работать до следующего запуска. При необходимости последующего обновления приложения вы можете просто добавлять новые версии .3 или .4 и удалять устаревшие .1 или .2, по мере того, как пользователи будут прекращать работать с ними.

Для Full режима установки ситуация несколько отличается. Вы можете настроить приложение на автоматическую проверку обновленной версии при каждом запуске, указав при создании пакета в параметре AppSyncURL в файле Package.ini путь к обновленной версии на файловом сервере в формате file://<имя_сервера>/<путь_к_файлу> или http://<имя_сервера>/<путь_к_файлу> (например: "file://Fileserver/Software/Firefox/Firefox.exe").

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

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

На сегодня всё.

воскресенье, 26 сентября 2010 г.

Статья: Сравнение решений компаний Microsoft и VMware в области виртуализации серверной инфраструктуры

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

Введение
На сегодняшний день все больше компаний применяют различные решения по виртуализации в своей ИТ инфраструктуре. Так, например, по оценкам аналитического агенства IDC в четвертом квартале 2009 года 18.2% всех поставляемых на рынок серверов использовали те или иные решения по виртуализации. Цифры выглядят не слишком впечатляющими, если не брать в расчет тот факт, что на одном физическом сервере может размещаться, в среднем, от 5-ти до 10 виртуальных машин. Именно за счет столь впечатляющих показателей консолидации вычислительных ресурсов, многие компании рассматривают виртуализацию как основное средство повышения эффективности работы собственной ИТ инфраструктуры.

Виртуализация позволяет не только существенным образом сократить капитальные и операционные затраты на поддержку ИТ инфраструктуры компании, но также упрощает развертывание и управление бизнес-сервисами и предоставляет новые механизмы по повышению уровня доступности сервисов, гарантируя исполнение соглашения об уровне услуг (SLA).

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

Ниже будут рассмотрены ключевые особенности организации виртуальной инфраструктуры на базе VMware vSphere 4.1 и Microsoft Hyper-V 2008 R2 и Microsoft System Center Virtual Machine Manager 2008 R2 и описаны преимущества каждого из решений по виртуализации.

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

Компания VMware предоставляет комплексное решение по виртуализации инфраструктуры – VMware vSphere 4.1, которое включает в себя как серверы виртуализации (гипервизоры), так и инструменты управления инфраструктурой.


На выбор доступны два варианта гипервизоров – VMware ESXi или VMware ESX. Основное отличие гипервизоров заключается в наличии у VMware ESX так называемой служебной консоли (Service Console) – специализированной виртуальной машины, отвечающей за управление сервером ESX и позволяющей устанавливать программы-агенты сторонних производителей (средства мониторинга и контроля дисковых массиов, переферийного оборудования, ИБП и т.д.). VMware ESXi, в свою очередь, имеет меньший размер, что позволяет записать его, например, на flash накопитель, позволяя отказаться от размещения жестких дисков внутри сервера, снижая, тем самым, энергопотребление и тепловыделение сервера и повышая его надежность за счет уменьшения количества механических компонентов.
Отличительными особенностями гипервизоров VMware ESX/ESXi являются:
  • Поддержка большинства современных и унаследованных ОС семейств Windows, Linux или Unix.
  • Хранение и запуск виртуальных машин с локальных дисков или хранилищ (DAS), сетей хранения данных (SAN), подключающихся по протоколам Fibre Channel, iSCSI, а также сетевых хранилищ (NAS), использующих протокол NFS.
  • Поддержка кластерной файловой системе VMFS для доступа к виртуальным машинам одновременно с нескольких узлов.
  • Удаленное управление с помощью клиент VMware vSphere Client, с помощью консоли SSH, набора скриптов (RemoteCLI) или модуля расширения для PowerShell (PowerCLI).
  • Поддержка технологий управления и экономии оперативной памятью (Memory Overcommitment), позволяющих улучшить показатели консолидации инфраструктуры по сравнению с решениями конкурентов.
  • Поддержка проброса в отдельные виртуальные машины физических устройств с сервера (VMDirectPath I/O), а также устройств, подключенных по шинам USB (USB device passthrough) или COM.
  • Возможность настройки последовательности и интервала запуска виртуальных машин при старте или перезагрузке физического сервера.
  • Поддержка ˈгорячегоˈ добавления виртуальных устройств: процессоров, памяти, дисков, контроллеров и сетевых карт.
Компания Microsoft предоставляет гипервизор Hyper-V R2 в качестве одной из ролей своей ОС Windows Server 2008 R2 (Hyper-V Role), либо отдельного продукта – Hyper-V Server 2008 R2. Среди особенностей Microsoft Hyper-V 2008 R2 следует отметить:
  • Небольшой размер кода гипервизора.
  • Поддержку широкого перечня современного аппаратного обеспечения.
  • Наличие родительской виртуальной машины (Parent Partition) для управления сервером Hyper-V и распределения ресурсов другим виртуальным машинам (Child Partition).
  • Возможность размещения виртуальных машин на локальных дисках или на СХД, подключаемых по протоколам SCSI, Fibre Channel или iSCSI.
  • Управление через MMC консоль Hyper-V Manager, или с помощью средств командной строки (Powershell, CMD и т.д.).
  • Поддержку отказоустойчивых кластеров (Failover Cluster), включих до 16 узлов.
  • Поддержку переноса виртуальных машин с одного узла кластера на другой – Live Migration.
  • Интеграцию с доменной инфраструктурой на базе Active Directory.
  • Наличие встроенных средств резервного копирования и восстановления виртуальных машин с помощью Windows Server Backup.
  • Совместную интеграцию со службами Microsoft Remote Desktop Services для развертывания инфраструктуры виртуальных рабочих станций (VDI).

Централизованное управление
Для крупной ИТ инфраструктуры, насчитывающей десятки или даже сотни серверов виртуализации, работа с каждым сервером в отдельности может стать весьма утомительным и трудоемким занятием. Для решения этой проблемы VMware и Microsoft предлагают свои решения по централизованному управлению виртуальной инфраструктурой.

VMware vCenter Server позволяет:
  • Централизованно управлять серверами ESX/ESXi. Несколько серверов vCenter Server могут быть объединены в связанную группу (Linked Groups) для контроля всей виртуальной инфраструктурой из единой консоли.
  • Создавать виртуальные машины копированием из заранее настроенных шаблонов для упрощения и ускорения развертывания новых серверов.
  • Выполнять автоматическое обновление виртуальных машин, шаблонов и других компонентов виртуальной инфраструктуры с помощью VMware vCenter Update Manager.
  • Контролировать и динамически перераспределять вычислительные ресурсы серверов виртуализации (процессоры, память, диски) при помощи пулов ресурсов (Resource Pool).
  • Настраивать кластеры высокой доступности (High Availability) и управлять кластерами с распределением ресурсов (Distributed Resource Schedule).
  • Выполнять операции переноса виртуальных машин (vMotion и Storage vMotion).
  • Мигрировать при помощи VMware vCenter Converter в виртуальную среду существующие физические серверы и виртуальные серверы с других платформ.
  • Следить за состоянием гипервизоров и виртуальных машин, создавать отчеты по текущей загрузке инфраструктуры и настраивать выполнение задач по расписанию.
  • Настраивать разрешения на управление виртуальной инфраструктурой для учетных записей пользователей.
  • Создавать и настраивать распределенные виртуальные коммутаторы (Distributed vSwitches) для централизованного управления виртуальной сетевой инфраструкторой.
  • Использовать профили узлов (Hosted Profiles) для быстрого изменения настроек серверов ESX и контроля изменений в их конфигурации.
  • Подключать плагины сторонних производителей для управления виртуальной инфраструктой (системами резервного копирования, средствами конвертирования виртуальных машин, антивирусной защитой, управления СХД и т.д.).
  • Интегрироваться с VMware View и Citrix XenDesktop для создания инфраструктуры виртуальных рабочих станций (VDI).
Решение Microsoft System Center Virtual Machine Manager 2008 R2 предоставляет следующий функционал:
  • Единую консоль управление серверами виртуализации Microsoft Hyper-V и Microsoft Virtual Server 2005 и
  • Поддержку управления серверами VMware ESX/ESXi с помощью vCenter Server.
  • Поддержку развертывания виртуальных машин из шаблонов.
  • Использование библиотек (SCVMM Library) для хранения и организации централизованного доступа к ISO образам дистрибутивов, дискам и шаблонам виртуальных машин.
  • Установку актуальных обновлений для виртуальных маши, используя Offline Virtual Machine Servicing Tool.
  • Встроенные средства по миграции физических серверов (P2V) и виртуальных серверов (V2V) в инфраструктуру Hyper-V.
  • Использование портала самообслуживание для управления виртуальными машинами из Web браузера.
  • Выполнение операции Quick Storage Migration для переноса виртуальных машин между хранилищами.
  • Интеграцию с Microsoft System Center Operation Manager 2007.
  • Интеграцию с Citrix XenDesktop для создания инфраструктуры виртуальных рабочих станций (VDI).
  • Поддержку удаленного управления с помощью коммандлет PowerShell.

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

Так, например, технологии VMware vMotion и Microsoft Live Migration обеспечивают перенос работающих машин с одного физического узла на другой в реальном времени без остановки и простоя служб. Это может быть полезно как при проведении технического обслуживание одного из серверов виртуализации, так и при постепенной замене оборудования или обновлении инфраструктуры виртуализации. Аналогично, при необходимости переноса виртуальной машины с одного диска или хранилища на другое могу быть использованы технологии VMware Storage vMotion или Microsoft Quick Storage Migration.

Для снижения времени незапланированного простоя виртуальной среды применяются решения VMware High Availability и Microsoft Failover Cluster. Все защищаемые виртуальные машины должны располагаться на общем хранилище к которому имеют доступ несколько узлов виртуализации, объединенных в кластер. Сбой или отказ одного из узлов отслеживается остальными участниками кластера, а запущенные на нем виртуальные машины автоматически регистрируются и перезапускаются на оставшихся работоспособных узлах. Использование кластеров высокой доступности позволяет уменьшить время незапланированного простоя серверов до 5-20 минут.

Серверы VMware ESX поддерживают организацию двух типов кластеров: высокодоступные кластеры (HA – High Availability) и кластеров с распределением ресурсов (DRS – Distributed Resource Schedule).

Для первоначальной настройки кластера HA, требуется, чтобы все узлы были зарегистрированы на одном сервере VMware vCenter Server, а также были подключены к общему хранилищу, на котором располагаются виртуальные машины. При отказе одного сервера, работавшие на нем виртуальные машины автоматически перезапускаются на других доступных узлах HA кластера.

Кластер DRS позволяет серверу VMware vCenter Server балансировать нагрузку, равномерно распределяя виртуальные машины между всеми узлами и, при необходимости, выполняя перенос виртуальных машин на наименее загруженные узлы.

Одной из разновидностей DRS кластера является кластер распределенного управления питанием (DPM – Distributed Power Management), позволяющий выключать часть серверов ESX при низкой загрузке на серверы, снижая тем самым энергопотребление, и включая их снова, при возникновении потребности виртуальных машин в вычислительных ресурсах.

Кроме того, VMware предоставляет уникальный механизм непрерывной защиты наиболее критических сервисов, путем запуска дополнительной копии виртуальной машины на другом узле, и синхронизации в реальном времени состояния между основной (primary) и дополнительной (secondary) копиями виртуальной машины. В случае сбоя основного сервера, все управление и запросы переходят к дополнительной виртуальной машины без простоя.

Для защиты виртуальных машин Hyper-V от незапланированного простоя используются отказоустойчивые кластеры (Failover Cluster), построенные на базе служб Microsoft Clustering Services, доступных. Для кластера требуется наличие общего дискового хранилища для размещения виртуальных машин, а также доменной инфраструктуры Active Directory.

Системая мониторинга и управления ресурсами (PRO Tips) в SCVMM 2008 R2, работающая совместно с SCOM 2007 R2, отслеживает разничные параметры виртуальной инфраструктуры: доступные вычислительные ресурсы, загрузку физических и виртуальных машин, наличие ошибок в работе различных компонентов и служб, и на основании полученных данных выдавать рекомендации по оптимальному размещению виртуальных машин на кластерах серверов Hyper-V.

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

VMware Data Recovery (VDR) позволяет осуществлять централизованное резервное копирование виртуальных машин VMware ESX на локальные диски или сетевую папку по расписанию. Преимущество VDR заключается в использовании технологии дедупликации данных, которая позволяет уменьшать размер резервной копии. VDR позволяет восстанавливать как виртуальные машины целиком, так и отдельные папки и файлы.

Microsoft DPM 2010 позволяет выполнять резервное копирование и восстановление виртуальных машин, расположенных на серверах Hyper-V, а также устанавливать агенты внутри виртуальных машин для резервирования данных приложений (баз SQL серверов, почтовых ящиков Exchange и порталов SharePoint).

Лицензирование
Оба вендора предоставляют решения как для малого и среднего бизнесы, так и для крупных компаний.
Для небольших компаний или удаленных филиалов с несколькими серверами, которым не требуется централизованное управление, доступна бесплатная версия VMware ESXi Free.

Компаниям, испытывающим необходимость в централизованном управлении виртуальной инфраструктурой, предлагаются VMware vSphere Essentials и Essentials Plus, в которые входят лицензии на три двухпроцессорных сервера и одна лицензий VMware vSphere Essentials. Дополнительно, в лицензии Essentials Plus доступны средства резервного копирования VMware Data Recovery, организации HA кластера и выполнения переноса vMotion между узлами.

Для средних и крупных компаний доступны различные типы лицензий для серверов ESX (редакции от Standard до Enterprise Plus) и vCenter Server (редакции Foundation или Standard), обеспечивающих требуемый функционал.

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

Для централизованного управления небольшой инфраструктурой Hyper-V могут применяться продукты System Center Essentials 2010 или System Center Virtual Machine Manager 2008 R2 Workgroup Edition (позволяет управлять пятью серверами виртуализации).

Для средних и крупных компаний доступен SCVMM 2008 R2 в качестве отдельного продукта, либо в составе пакетов лицензий System Center Server Management Suite Enterprise (SMSE) и Datacenter (SMSD), включающих в себя, помимо SCVMM, другие продукты линейки System Center (SCCM, SCOM, SCDPM и т.п.) и предоставляющие расширенные права на установку агентов и управление виртуальными машинами, запущенными на лицензированном сервере.

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

четверг, 23 сентября 2010 г.

Использование функции RemoteApp for Hyper-V для работы с устаревшими приложениями

С выходом Windows Server 2008 (Terminal Services, ныне Remote Desktop Services) у пользователей появилась возможность подключаться не только к удаленному рабочем столу, но и к отдельным опубликованным приложениям (RemoteApp или т.н. Seamless Mode). Данный режим существенно облегчает работу, позволяя перенести выполнение большинства приложений на терминальный сервер прозрачно для пользователей.

Тем не менее, во многих организациях до сих пор используются различные устаревшие приложения, которые не могут выполняться на ОС Windows Server 2008 и выше, что может препятствовать переходу на новые ОС. Данную проблему можно решить различными способами, например, используя решения сторонних производителей (например, Citrix XenApp) или запуская виртуальную машину на локальной рабочей станции пользователя (Windows XP Mode или MED-V), однако есть и другой вариант.

Для клиентских ОС существует возможность публикации отдельных приложений с организацией удаленного доступа к ним по протоколу RDP (RemoteApp for Hyper-V).

Как и в классическом варианте терминального доступа в режиме RemoteApp for Hyper-V существует хост - виртуальная машина с установленными приложениями, к котором требуется обеспечить удаленный доступ и клиент - устройство, за которым работает пользователь.

Microsoft предоставляет на выбор два сценария публикации:
  • В Standalone режиме администратор создает .rdp файл, в котором указывает название приложения и имя хоста, к которому планирует подключаться один или несколько пользователь. Для каждого публикуемого приложения должен быть создан отдельный .rdp файл. Кроме того, в силу ограничений клиентских ОС, на хосте может быть активной лишь одна пользовательская сессия, иными словами, только один пользователь сможет получить доступ к опубликованным приложениям на данном хосте. Хотя данный вариант не требует установки дополнительных служб и компонентов, но может быть сложен в управлении и обслуживании при наличии большого количества хостов и публикуемых приложений.
  • VDI конфигурация предполагает развертывание полноценной инфраструктуры виртуализации рабочих станций на базе сервера виртуализации Hyper-V, Remote Desktop Session Host и Connection Broker из состава Windows Server 2008 R2. Данный вариант обеспечивает единую точку подключения ко всем публикуемым приложениям, отслеживает активные сеансы пользователей, дабы избежать одновременного подключения сразу к нескольким хостам, однако не избавляет администраторов от необходимости создавать .rdp файлы и выполнять настройку виртуальных машин.
В качестве хостовой ОС для публикации приложений поддерживаются следующие ОС:
  • Windows XP x32 Professional SP3;
  • Windows Vista x32 SP1 или выше в редакции Enterprise или Ultimate;
  • Windows 7 x32 в редакции Enterprise или Ultimate.
В Windows 7 данный функционал поддерживается по умолчанию, а для Windows XP и Windows Vista придется загрузить дополнительное обновление (отсюда и отсюда, соответственно).

В качестве клиентской ОС с которой выполняются подключения, поддерживается Windows 7 x32 или x64 (однако, в роли клиентов также могут выступать Windows XP и Windows Vista с установленным клиентом RDP Client 7.0).

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

Перед тем, как переходить к самой процедуре настройки хостовой машины, вам потребуется установить актуальную версию клиента RDP (RDP Client 7.0) для соответствующей версии ОС и обновление, включающее функционал RemoteApp for Hyper-V (ссылки приведены выше). После установки обновления на компьютер потребуется его перезагрузить.

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

Откройте редактор реестра (regedit) на хостеовой машине и измените параметр fDisabledAllowList расположенный в HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList, установив его значение в 1.

Запустите клиент RDP, укажите имя хоста, к которому требуется подключиться, и сохраните файл конфигурации (.rdp), нажав Save As.

Откройте созданный файл в текстовом редакторе, найдите строчки и замените их значения на приведенные ниже:
Alternate shell:s:rdpinit.exe
RemoteApplicationMode:i:1

Добавьте в файл следующие строчки:
RemoteApplicationName:s:<ИМЯ_ПРИЛОЖЕНИЯ>
RemoteApplicationProgram:s:<ПУТЬ_К_ФАЙЛУ>
DisableRemoteAppCapsCheck:i:1
Prompt For Credentials on Client:i:1
, где <ИМЯ_ПРИЛОЖЕНИЯ> - описательное имя приложения (например, Notepad);
<ПУТЬ_К_ФАЙЛУ> - полный путь к исполняемому файлу приложения (например, "C:\Windows\System32\Notepad.exe").

Пример модифицированного файла показан на рисунке:

Сохраните файл и перенесите его на клиентский компьютер.

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

Учтите, что если вы планируете использовать один и тот же хост для подключения нескольких пользователей поочередно, то крайне желательно настроить автоматическое завершение сеанса после отключения пользователя. Сделать это можно отредактировав групповые политики хоста (через локальные или доменные групповые политики). Интересующая Set time limit for disconnected sessions настройка находится:
Для Windows XP: Computer Configuration -> Administrative Templates -> Windows Components -> Terminal Services -> Sessions
Для Windows Vista: Computer Configuration -> Administrative Templates -> Windows Components -> Terminal Services -> Terminal Server -> Session Time Limits
Для Windows 7: Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Session Time Limits
Установите значение параметра в Enable и укажите интервал отключения через 1 минуту.

При подготовке статьи использовались следующие материалы:
  1. RemoteApp for Hyper-V (VDI) Deployment.

вторник, 17 августа 2010 г.

Работаем с App-V (часть IV)

Продолжая цикл статей и заметок об App-V, я хотел бы рассказать о возможности публикации и загрузки пакетов приложений с использованием Web-сервера.

Часть 1: http://blog.vmpress.org/2010/05/app-v-i.html
Часть 2: http://blog.vmpress.org/2010/05/app-v-ii.html
Часть 3: http://blog.vmpress.org/2010/06/app-v-iii.html

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

При реализации подобной конфигурации важно разделять два момента: публикацию приложений и, собственно, саму загрузку файлов.

С настройкой загрузки файлов по HTTP нет ничего сложного.

Чтобы клиент App-V определил, что загрузка .sft пакета должна осуществляться по протоколу HTTP, вам нужно отредактировать .osd файл. Откройте нужный пакет в программе-упаковщике Sequencer, и на вкладке Deployment в качестве протокола выберите HTTP или HTTPS, а также задайте имя сервера (Hostname) и путь (Path) к web-директории, где будет располагаться .sft файл.


При желании, вы можете вручную отредактировать .osd, прописав в параметре CODEBASE HREF= полный путь к .sft файлу.


Далее вам потребуется установить Web-сервер, на котором будут располагаться пакеты приложений. В качестве примера возьмем IIS 7.0.

Для IIS вам потребуется установить следующие компоненты:
  • ASP.Net
  • ASP
  • Integrated Authentication
После установки откройте консоль управления IIS, выберите web-сайт и добавьте новую web-директорию, в которой в дальнейшем будут располагать пакеты приложений. Перейдите в созданную директорию в секции IIS, выберите Directory Browsing и включите (Enable) возможность просмотра содержимого папки.

Также вам потребуется задать MIME Types для корректной обработки расширений файлов Web-сервером. Для этого выберите ваш сайт и в секции IIS выберите MIME Types.

С помощью кнопки Add... задайте MIME типы для следующих расширений файлов.

Расширение: .osd, MIME type: application/softricity-osd
Расширение: .sft, MIME type: application/softricity-sft
Расширение: .sprj, MIME type: application/softricity-sprj

После этого скопируйте пакет в соответствующую директорию на Web-сервере. В данном примере пакеты приложений располагаются в отдельных дочерних папках внутри главной директории.

Если вы планируете, чтобы клиенты самостоятельно подключались к Web-серверу и получали список опубликованных пакетов вам предстоит выполнить еще ряд действий.

Для получения информации о доступных пакетах клиенты используют файл-описатель (manifest) в формате .xml.

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

Структура файла выглядит следующим образом.
Информация об приложениях находится внутри секции <APPLIST><APP></APP></APPLIST>.

Обратите внимание на переменную %SFT_MIME_SOURCE%, присутствующую в файле-описателе. С ее помощью клиент определяет абсолютный путь к файлу .osd и изображениям ярлыков приложения. Значение переменной можно задать при установке или при помощи групповых политик, а также отредактировав соответствующие ключи реестра:
HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration\IconSourceRoot
HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration\OSDSourceRoot

Использование переменной %SFT_MIME_SOURCE% вместо жесткого прописывания абсолютного пути может быть полезно в случае, когда у вас в компании есть несколько мобильных пользователей, переезжающих с места на место. В этом случае, с помощью групповых политик вы можете задавать путь к ближайшему дистрибутивному серверу для ускорения процедуры загрузки новых опубликованных пакетов. Аналогичным образом вы можете менять ключ HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration\ApplicationSourceRoot для изменения пути к пакету .sft, указанном в .osd файле.

Еще один момент на который стоит обратить внимание - если вы планируете размещать содержимое каждого пакета не в корневой папке, а в отдельной директории (например, "App-V/Adobe9"), вам, все-таки, придется отредактировать файл-описатель .xml, добавив после %SFT_MIME_SOURCE% имя дочерней папки.

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

Вариант с использованием скрипта достаточно подробно описан (например, здесь), кроме того, John Sheehan выложил пример скрипта для создания файла-описателя на C#. Исходный код сценариев с небольшими правками вы можете загрузить отсюда или отсюда.

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

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

Все, что вам осталось - это настроить клиентов на Web-сервер публикаций. Сделать это можно в процессе установки клиента, как описано в данной статье, либо вручную.

В консоли Application Virtualization Client щелкните правой кнопкой мыши по Publishing Servers и выберите New.

В мастере New Publishing Server укажите тип публикации (Type) и задайте отображаемое имя (Display Name). Нажмите Next.

Укажите имя Web-сервера (Host Name) и путь к скрипту публикации (Path).

Для завершения настроек нажмите Finish.

Если для публикации приложения вы использовали переменную %SFT_MIME_SOURCE% не забудьте изменить соответствующие ключи реестра.

Теперь настало время для тестов.

Нажмите правой кнопкой мыши по созданной записи сервера публикации и нажмите Обновить Сервер (Refresh Server). Если вы правильно указали пути в файле-описателе процесс должен будет отработать без ошибок.

Кроме того, ваше опубликованное приложение должно будет появится в списке Applications. Запустите приложение, чтобы проверить корректность загрузки по протоколу HTTP.

Если на каком-то этапе у вас возникли ошибки, можете проверить журнал событий приложений.
Скорее всего, вы некорректно задали путь к .osd или .sft файлу и клиент App-V не может их обнаружить.

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

Вместо анонимной аутентификации на сервере вы можете включить Integrated аутентификацию (для всего сервера, или для отдельных папок), после чего предоставить разрешения на уровне NTFS на соответствующую папку требуемому пользователю или группе (например, "App-V <Имя_приложения> Users"). Для этого в консоли IIS, выбрав нужную директорию с приложением, в секции IIS выберите Authentication. Включите (Enable) тип аутентификации Windows Authentication.

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

На этом знакомство с публикацией пакетов App-V с помощью HTTP можно считать завершенным.

вторник, 10 августа 2010 г.

Средства аудита инфраструктуры

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


Сбор общей информации об инфраструктуре

Microsoft Assessment & Planning Toolkit (MAPT) - одна из лучших утилит по инвентаризации серверов и рабочих станций в сети. Позволяет использовать различные варианты обнаружения компьютеров, включая поиск в Active Directory, через сетевое окружение, в указанном диапазоне IP адресов, импортирование имен из текстового файла.
С помощью WMI запросов к каждому компьютеру собирает необходимую информацию, включая версию и редакцию ОС, установленные программы и компоненты, аппаратную конфигурацию, сетевые настройки.

Для хранения собранных данных используется база SQL сервера (поддерживается SQL Server 2008 Express Edition).

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

Active Directory Topology Diagrammer (ADTD) - утилита для построения диаграмм и схем в Visio (поддерживает Vision 2003 / 2007) на основе данных, собранных из AD.
ADTD позволяет строить диаграммы: лесов, доверительных отношений и доменов, существующей иерархии организационных подразделений, почтовых серверов Exchange и коннекторов отправителей, организации сайтов и настройки репликации.

Следующая утилита - Microsoft IT Environment Health Scanner позволяет проверить общее состояние вашей инфраструктуры. Среди проверяемых параметров:
  • Конфигурация сайтов и подсетей Active Directory.
  • Состояние репликации Active Directory с использование DFS и FRS.
  • Разрешение имен с помощью DNS.
  • Настройка сетевых адаптеров на всех контроллерах домена
  • Конфигурация серверов DNS и почтовых серверов Microsoft Exchange.
  • Ошибки в журналах событий, связанных с работой домена
Результат работы программы экспортируется в html файл.
При наличии ошибок или предупреждений в результирующий отчет также будет добавлено краткое описание проблемы и дана ссылка на статью из базы знаний Microsoft. Загрузить Microsoft IT Environment Health Scanner можно отсюда.

Для сбора информации о групповых политиках можно воспользоваться скриптами ListSOMPolicyTree.wsf и GetReportsForAllGPOs.wsf, входящими в состав Group Policy Management Console (GPMC).
ListSOMPolicyTree.wsf выводит структуру организационных подразделений Active Directory с указанием всех примененных к ним групповых политик.
GetReportsForAllGPOs.wsf генерирует отчеты в формате html по всем созданным групповым политикам в указанной папке.

Из сторонних программ неплохо себя зарекомендовала ADScribe от компании LEADUM Software. Как нетрудно догадаться, ADScribe собирает информацию об объектах каталога Active Directory (пользователях, группах, компьютерах, контактах, организационных подразделениях, принтерах), сайтах и групповых политиках и сохраняет их в виде единого справочного chm или html файла. Программа может быть запущена с любого компьютера, входящего в обследуемый домен, при наличии у пользователя соответствующих прав.
К сожалению, ADScribe несовместима с 64-разрядными ОС (проявляется в виде проблемы с регистрацией библиотеки msxml.dll). Для ознакомления доступна полнофункциональная trial версия на 15 дней.

Сбор информации о сервере
В качестве основного средства по сбору информации о конфигурации сервера можно использовать Microsoft Product Support Reports (MPSReports). MPSReports собирает подробную информацию о конфигурации и настройках сервера, включая текущую аппаратную конфигурацию, установленные программы, драйверы, службы, версии библиотек и системных файлов, сетевые настройки, вывод утилит NetDiag, DCDiag, GPResult. Дополнительно в отчет могут быть включены результаты проверки настроек системы обновлений WSUS, служб SQL и Exchange. Вся собранная информация будет упакована в один .cab архив. Для его просмотра лучше всего использовать Microsoft Product Support Reports Viewer (MPS Reports Viewer).

В Windows Server 2008 R2 также есть встроенные инструменты по анализу установленных компонентов сервера на соответствие рекомендациям (Best Practice Analyzer). BPA устанавливается вместе с той или иной ролью и доступен из оснастки Server Manager.
Для автоматизации процесса сбора информации с локального сервера вы можете выполнить приведенный ниже скрипт:
#Get-BPAResults.ps1
#v.1.0
Import-Module ServerManager
Import-Module BestPractices

$ResultDir = "C:\Temp\"

foreach ($BPAModel in Get-BpaModel)
{
$BPAinstance = $BPaModel.Id
$FileName = $BPAinstance.Substring($BPAinstance.LastIndexOf("/")+1)
Invoke-BpaModel $BPAinstance
Get-BPAResult $BPAinstance | ConvertTo-Html > ($ResultDir + $FileName + ".html")
}
Результат анализа BPA по каждой роли будет сохранен в отдельном HTML файле в папке "C:\Temp".

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

вторник, 6 июля 2010 г.

Оценка стоимости вариантов лицензирования виртуальной среды на базе Microsoft Hyper-V + SCVMM

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


Схожие правила распространяются на пакеты лицензий System Center Server Management Suite Enterprise (SMSE) и System Center Server Management Suite Datacenter (SMSD), включающих в себя право на использование ПО семейства System Center: System Center Configuration Manager 2007 R2, System Center Data Protection Manager 2010, System Center Operation Manager 2007 R2, System Center Virtual Machine Manager 2008 R2 и д.р. как на физических серверах, так и в виртуальной среде.

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

Дополнительными преимуществами Software Assurance является возможность перехода на новую версию продукта (в данном случае серверной ОС Windows Server) без необходимости покупки новых лицензий.

Вдобавок, Microsoft предоставляет решения по управлению серверами виртуализации для малого бизнеса: Microsoft System Center Virtual Machine Manager 2008 R2 Workgroup Edition и System Center Essentials 2010.

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

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

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

Для сравнения использовались следующие выпуски ОС:

  • Microsoft Windows Server 2008 R2 Standard Edition.
  • Microsoft Windows Server 2008 R2 Enterprise Edition.
  • Microsoft Windows Server 2008 R2 Datacenter Edition.
В расчетах не оценивается функционал, который могут предоставлять старшие редакции ОС. Оценка выполнялись как для случая покупки обычных лицензий, так и совместно с Software Assurance.

Также сравнивалась стоимость SCVMM 2008 R2 в составе:
  • Microsoft System Center Virtual Machine Manager 2008 R2 Workgroup Edition.
  • Набора приложений System Center, приобретаемых отдельно (SCCM 2007 R2, SCDPM 2010, SCOM 2007 R2 и SCVMM 2008 R2).
  • Пакета лицензий SMSE.
  • Пакета лицензий SMSD.
Предполагается, что в случае покупки приложений System Center лицензируются все серверы, как физические, так и виртуальные, что отражается на количестве лицензий, необходимый для SCCM, SCDPM и SCOM. При этом на все серверы (физические и виртуальные) приобретаются лицензии SCDPM Enterprise ML, хотя в реальной среде это, как правило, не так.

В расчетах не учитывается стоимость дополнительных лицензий, таких как: лицензии SQL Server'а или лицензии клиентского доступа (CAL). Все цены для Windows Server и System Center были взяты с сайта Microsoft.

Вот какие результаты были получены.

Стоимость лицензий Windows Server 2008 Standard Edition растет линейно при росте количества, и в некоторых случаях может быть выгодно лицензировать виртуальные машины именно с помощью редакции Standard, нежели Enterprise. Однако, когда количество виртуальны машин вырастает до 25 и более, стоимость Datancenter становится самой низкой по сравнению с другими редакциями.
Еще более интересные результаты получаются при планировании Failover конфигурации. В этом случае, если ваша инфраструктура насчитывает 17 и более виртуальных машин, выгоднее, опять же, покупать Windows Server 2008 R2 Datacenter Edition.
Для вариантов лицензирования с учетом Software Assurance (как для Failover конфигурации, так и без нее) общий вид графиков не меняется.
и
Стоимость SCVMM 2008 R2 Workgroup Edition в расчете на 3 сервера виртуализации ожидаемо оказывается самой низкой в независимости от количества виртуальных машин. Что касается пакетов лицензий из отдельных продуктов, SMSE и SMSD, то последний выгоднее покупать при наличии 9 и более виртуальных машин (либо 5 и более при планировании отказоустойчивой конфигурации).
Для собственных расчетов вы можете загрузить таблицу отсюда или отсюда.
Примечание: поскольку расчеты производятся для одного кластера, то максимальное число физических серверов, указанных в таблице не должно превышать 16. Аналогично, при использовании кластера, максимальное число виртуальных машин на одном узле - 64. Все поля, доступные для редактирования выделены полужирным. Красным цветом выделены расчеты для отказоустойчивой конфигурации.

Конструктивная критика и предложения приветствуются.