четверг, 9 декабря 2010 г.

Работаем с XenDesktop 5

Недавно очередная, на этот раз уже пятая, версия Citrix XenDesktop показала всем свое новое "лицо".

Программисты Citrix'а сжалились над простыми смертными вроде нас с вами и полностью переработали интерфейс продукта, сделав его более удобным и дружелюбным. Эту работу трудно переоценить, вспоминая то множество оснасток, которыми приходилось ранее управлять в XenDesktop 4 и до сих пор приходится - в XenApp.

Одно из основных нововведений - централизованная консоль управления Citrix Desktop Studio с помощью которой можно назначать виртуальные рабочие станции пользователям, настраивать пользовательские и компьютерные политики, управлять веб-сайтами Citrix.


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


Каким образом эти нововведения затронули процедуру установки и настройки?

В качестве примера рассмотрим самый простой вариант развертывания VDI инфраструктуры, включающий в себя сервер XenDesktop, рабочую станцию и клиентский компьютер, с которого будет осуществляться подключение. В качестве рабочей станции можно использовать выделенный физический компьютер или виртуальную машину, работающую под управлением любого доступного гипервизора (Citrix XenServer, Microsoft Hyper-V или VMware ESX). В данном примере не предполагается выполнять интеграцию XenDesktop с подсистемой виртуализации для автоматизации развертывания и управления виртуальными машинами, поэтому каждую рабочую станцию, добавляемую в XenDesktop придется устанавливать и настраивать отдельно. Пример схемы развертывания приведен на рисунке.


В качестве ОС, устанавливаемой на серверы, рекомендуется использовать Windows Server 2008 R2, а в качестве клиентской ОС - Windows 7.

Перед началом установки требуется выполнить настройку сети на всех компьютерах и ввести их в домен Active Directory.

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

Установка и настройка сервера XenDesktop
Распакуйте XD5_Plat_Single.zip и подмонтируйте образ XenDesktop5.iso к серверу. Запустите установщик и выберите Install XenDesktop.


Примите лицензионное соглашения, выбрав I accept terms and conditions и нажмите Next.


На странице выбора компонентов (Select Components to Install) убедитесь, что выбраны все компоненты и нажмите Next.


На странице Firewall Configuration нажмите Next.

На странице Summary нажмите Install.

Дождитесь окончания установки. На странице Installation Successful убедитесь, что Configure XenDesktop after closing выбрано и нажмите Close.


В открывшейся консоли Citrix Desktop Studio выберите выберите вариант Advanced Configuration.


Укажите имя сайта (Site), путь к файлу лицензий (License file location) и редакцию (Edition). Проверьте, что выбран вариант использования сервер баз данных по умолчанию (Use default database). Нажмите Next.


При добавлении первого сервера система сама предложит создать и настроить подключение к базе. Нажмите OK.


На вкладке Host укажите тип хоста (Host type) - None, нажмите Next.


На вкладке Summary нажмите Finish.


Дождитесь, пока система завершит настройку.

Настройка рабочих станций
Установите Citrix XenDesktop Agent на виртуальной машине или рабочей станции, к которой удаленно будет подключаться пользователь. Запустите установщик, нажмите Install Virtual Desktop Agent.


Выберите вариант Advanced Install.


Если для видеокарты используется WDDM драйвер, то при установке на физический компьютер или виртуальную машину VMware ESX, вы получите сообщение с предложением отключить данный драйвер. Согласитесь, нажав Yes, так как если этого не сделать, то драйвер Citrix System Inc. Display Driver не сможет работать (подробнее об проблеме можно прочитать тут).


На странице Select Components to Install снимите Support for XenApp Application Delivery и нажмите Next.

На странице Controller Location в поле Manually enter controller location(s) введите имя сервера, на котором установлены службы XenDesktop. Нажмите Next.


На странице Virtual Desktop Configuration нажмите Next.


На странице Summary нажмите Install.


Дождитесь завершения установки и нажмите Close, чтобы перезагрузить рабочую станцию.

Откройте консоль Citrix Desktop Studio на сервере, щелкните правой кнопкой мыши по Machines и выберите Create Catalog.


В мастере Create Catalog на странице Machine Type выберите Physical и нажмите Next.


На странице Machines & users с помощью кнопки Add Computers... добавьте из Active Directory учетную запись рабочей станции, которую вы настроили ранее.


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


На странице Administrators нажмите Next.


На странице Summary задайте имя создаваемого каталога (Catalog name) и нажмите Finish для завершения настройки.


Теперь требуется назначить пользователям рабочие станции.

Щелкните правой кнопкой мыши по Assigments и выберите Create Desktop Group.

В мастере Create Desktop Group на странице Catalog выберите ранее созданный каталог, в поле Add machines введите количество машин, которое требуется назначить. Нажмите Next.


На странице Users с помощью кнопки Add... добавьте из Active Directory группы или пользователей, которым следует разрешить подключаться к удаленным рабочим станциям, и нажмите Next.


На странице Delegation нажмите Next.

На странице Summary введите имя, которое будут видеть пользователи при подключении (Display name) и имя группы (Desktop Group name) и нажмите Finish.


Проверка работы XenDesktop
На клиентской машине откройте браузер. В адресной строке впишите имя сервера XenDesktop. При первом входе на сайт вам предложат установить плагин Citrix Online Plugin Web.


После установки плагина войдите, используя учетные данные пользователя, для которого был назначен виртуальный рабочий стол.


Если вы все сделали правильно, то вам будет доступен удаленный рабочий стол.


Поздравляю с успешной настройкой.

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

Решение проблемы The View Connection Server connection failed. Network error

В определенных ситуациях при подключении к серверу VMware View Connection Server, например версии 4.5, с помощью клиента VMware View Client, установленного в Windows Vista/7, вы можете получать ошибку следующего содержания:


The View Connection Server connection failed. Network error. Contact your network administrator.

При этом, если попытаться подключиться к серверу с компьютера, входящего в тот же домен, что и сервер View, или с компьютера с ОС Windows XP, то все работает замечательно.

Просмотр журнала "debug-<date>.txt
", который располагается в "%userprofile%\AppData\Local\VMware\VDM\logs", позволяет получить более детальное сообщение об ошибке:

DEBUG [wswc_http] WININET ErrorCode = 12057

Поиск по номеру ошибки в Интернете приводит к статьям, описывающим проблемы со списками отзывов сертификатов (CRL). Проверить это предположение можно, отключив проверку CRL в свойствах настроек Интернет: Start -> Control Panel -> Internet Options -> Advanced -> Check for server certificate revocation.

Так и есть! Теперь клиент нормально подключается.

Но что могло послужить причиной? Посмотрим на сертификат, который используется в VMware View Connection Server.

Так и есть. Список отзыва сертификатов содержит лишь LDAP путь (т.к. Центр Выдачи Сертификатов был установлен с настройками по умолчанию), который не может использоваться для проверки компьютерами, не входящими в домен.

Публикация дополнительных путей, доступных клиентам (например, http:// или file://), и повторная выдача сертификата серверу View позволит решить проблему.

P.S. а проверку CRL на клиенте лучше включить обратно. :-)

среда, 3 ноября 2010 г.

Различия VMware vShield Zones и vShield App 4.1 update 1

Если попытаться коротко описать vShield App, то это ни что иное, как более продвинутая (и более дорогая) версия vShield Zones.

Основное назначение vShield Zones и vShield App заключается в возможности создавать правила, которые фильтруют IPv4 пакеты (IPv6 не фильтруется) от виртуальных машин и к виртуальным машинам, подпадающие под определенные правила (совпадение адреса отправителя, адреса получателя, порта и используемого протокола). Какие функции становятся доступными при переходе на vShield App? Давайте посмотрим.

Лицензия на право использования vShield Zones входит в редакции vSphere Advanced, Enterprise или Enterprise Plus; vShield App лицензируется отдельно по количеству защищаемых виртуальных машин.

Обновление с vShield Zones до vShield App производится путем добавления соответствующей лицензии в vCenter Server и не требует установки дополнительных компонентов.

По сравнению с предыдущими версиями vShield Zones, процедура установки в 4.1 существенно упростилась. Больше не требуется загружать и добавлять в vCenter отдельную виртуальную оснастку (appliance) vShield Zones. Вся процедура установки и настройки выполняется из консоли виртуальной машины vShield Manager, которая содержит в себе необходимые компоненты.


Кроме того, больше нет разделения групп портов и виртуальных коммутаторов на незащищенные (Unprotected), подключенные к физическим сетевым адаптерам, и защищенные (Protected), подключенные к виртуальным машинам. После установки агента vShield Zones на сервер ESX правила фильтрации начинают действовать на все виртуальные машины независимо от их расположения.

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

Пакеты анализируются vShield Zones/App в соответствии с существующей таблицей и при нахождении первого подходящего правила отбрасываются или доходят до получателя. Порядок просмотра правил следующий:
  • правила для датацентра с высоким приоритетом;
  • правила для кластера;
  • правила для группы портов;
  • правила для датацентра с низким приоритетом;
  • правила по умолчанию.
Для vShield Zones при редактировании правила администратор может задавать в качестве адреса отправителя и получателя только определенный IP адрес или подсеть.

В vShield App возможности по созданию правил расширены - в качестве источника или назначения трафика можно указывать виртуальные машины, расположенные в определенном датацентре, кластере, группе портов, VLAN'е; либо, наоборот, все виртуальные машины, которые НЕ находятся внутри датацентра, кластера, группы портов.

Администратор также может создавать свои собственные группы безопасности (Security Groups) и включать в них выбранные виртуальные сетевые адаптеры.

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

Средство просмотра графиков и отчетов по типу трафика (VM Flow) было переименовано в Flow Monitoring и перекочевало из vShield Zones в vShield App, что крайне огорчает, т.к. никаких других нововведений замечено не было.

Администратор все также может добавить описание для протоколов (Port Mapping), неизвестных vShield App, для более наглядного их отображения в отчетах и при создании правил.

Наконец, начиная с версии 4.1 Update 1, в vShield App появилась функция SpoofGuard, которая позволяет избежать подмены IP адресов в виртуальных машинах. При включении SpoofGuard
для каждой виртуальной сетевой карты ставится в соответствие один определенный IP адрес (администратор может подтвердить корректность IP адреса вручную или автоматически при первом назначении), в случае изменения IP адреса система заблокирует отправку и прием пакетов на данную сетевую карту до тех пор, пока администратор не подтвердит корректность новых настроек в vShield App.

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

Настраиваем VMware Auto Deploy

Признаться, я всегда мечтал, чтобы когда-нибудь во всех современных приложениях появилась большая круглая красная кнопка "Работать", нажав которую, администратор по прошествии определенного времени получал бы полностью настроенную и работоспособную систему. И хотя VMware Auto Deploy пока не обладает такой кнопкой, но, во всяком случае, делает уверенные шаги в нужном направлении.


VMware Auto Deploy представляет из себя виртуальную оснастку (Virtual Appliance), которая будучи развернута вместе с VMware vCenter Server позволяет автоматизировать процесс загрузки и настройки серверов виртуализации ESX по сети с использованием протокола PXE. Использование Auto Deploy позволяет, во-первых, отказаться от локальных носителей для установки ESXi, что может несколько повысить надежность сервера, во-вторых, разворачивать новые серверы виртуализации, ограничиваясь тремя операциями - смонтировать сервер, скоммутировать сервер, включить сервер. :-)

На текущий момент Auto Deploy находится на этапе Techinal Preview, что не гарантирует стабильной работы в производственной среде, но не мешает нам опробовать ее в деле. Загрузить предварительную версию Auto Deploy можно по этой ссылке.

Установка Auto Deploy
Распакуйте содержимой в любой доступный для vCenter Server каталог. Подключитесь клиентом VMware vSphere Client к серверу. Запустите мастер импорта виртуальных машин из OVF шаблона, нажав File -> Deploy OVF Template.


На первой странице мастера в поле Deploy from a file or URL укажите путь к .ova файлу из распакованного архива. Нажмите Next.

На странице OVF Template Details нажмите Next.

На странице End User License Agreement прочтите и примите лицензионное соглашение с помощью кнопки Accept и нажите Next.

На странице Name and Location задайте имя (Name) виртуальной машины и укажите ее расположение (ЦОД и папку). Нажите Next.

На странице Host / Cluster укажите сервер виртуализации или кластер, на котором будет зарегистрирована виртуальная машина. Нажмите Next.

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

На странице Disk Format укажите тип виртуального диска. Нажмите Next.

На странице Network Mapping привяжите виртуальный сетевой адаптер к нужному виртуальному коммутатору и группе портов. Нажмите Next.

На странице Ready to Complete нажмите Finish.

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

Настройка Auto Deploy
Откройте консоль виртуальной машины Auto Deploy и дождитесь окончания загрузки ОС. При первом старте будет автоматически запущен мастер настройки, позволяющий задать сетевые параметры ВМ. Если в вашей сети еще не настроен DHCP сервер, можете задать статические настройки.

Затем система предложит задать пароль для административной учетной записи vi-admin. После завершения всех настроек откроется окно приветствия.

Настройка DHCP
Для автоматической выдачи сетевых параметров серверам ESXi вам потребуется развернуть сервер DHCP. Вы можете использовать DHCP сервер, встроенный в виртуальную машину или сторонний сервер DHCP в вашей сети. Для примера рассмотрим конфигурацию DHCP сервера в ОС Windows Server 2008.

Откройте консоль управления DHCP сервером. Если у вас уже настроена область с нужным диапазоном адресов, можете использовать ее, в противном случае создайте новую область.
Раскройте область, щелкните правой кнопкой мыши по Scope Options и выберите Configure Options... На вкладке General укажите в качестве значения для опции 066 Boot Server Host Name имя или IP сервера Auto Deploy.

Для опции 067 Bootfile Name впишите "undionly.kpxe.vmw-hardwired". Сохраните настройки.

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

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

Использование Host Profiles
Понятно, что  в силу особенностей загрузки ESXi по сети, настройки вашего сервера и все изменения, которые вы на нем выполните сохранятся до первого выключения. И хотя сервер, развернутый в производственной среде, может не перезагружаться месяцами, а то и годами, гораздо более практичным будет использование функции Host Profiles, доступной в редакции vSphere Enterprise Plus, которая позволяет применять нужные настройки автоматически при каждой загрузке сервера.

Для создания профиля в Host Profiles вам понадобится эталонный сервер, например тот, который вы только что загрузили по сети. Для начала откройте локальную консоль и задайте пароль для учетной записи root (по умолчанию пароля нет).

Теперь зарегистрируйте сервер виртуализации в vCenter.

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

Откройте окно управления профилями Host -> Host Profiles.

Щелкните кнопкой мыши по кнопке Create Profile.

В мастере создания профиля на первой странице выберите Create Profile from existing host. Нажмите Next.

На странице Specify Reference Host укажите добавленный и настроенный вами сервер. Нажмите Next.

На странице Profile Details задайте имя и описание создаваемого профиля. Нажмите Next.

На странице Ready to complete the profile нажмите Finish.

Настоятельно рекомендуется отредактировать созданный профиль и настроить в нем автоматическое назначение пароля для учетной записи root. Для этого щелкните правой кнопкой мыши по созданному профилю и выберите Edit Profile.

В открывшемся окне раскройте Security configuration -> Administrator password, выберите Configure a fixed administrator password, задайте пароль администратора и нажмите OK для сохранения настроек.

Теперь откройте консоль управления Auto Deploy. В главном меню нажмите комбинацию клавиш Alt + F2, в поле autodeploy login введите имя учетной записи (vi-admin), в поле Password - пароль.

Нам потребуется добавить один или несколько серверов vCenter Server, в которых Auto Deploy будет регистрировать серверы виртуализации при каждой загрузке. Сделать это можно с помощью команды:
vifp addserver <АДРЕС_VCENTER>
, где: <АДРЕС_VCENTER> - DNS имя или IP адрес сервера.
На запрос системы введите имя и пароль учетной записи пользователя, которая имеет административные права на сервере vCenter.

Для проверки успешности добавления сервера можете воспользоваться командой:
vifp listservers

Для каждого сервера виртуализации, который хотя бы раз загрузился, используя Auto Deploy создается отдельная запись в базе "/var/lib/deploy/db". Для просмотра записей вы можете воспользоваться командой:
deploy-cmd listhosts
Каждую запись характеризует следующий набор параметров:

  • Boot MAC - MAC адрес сетевой карты, с которой осуществляется загрузка по PXE.
  • IP Address - IP адрес, назначенный DHCP сервером.
  • Asset Tag - идентификатор данного компьютера.
  • Boot Profile - профиль, используемый для загрузки.
  • Status - состояние сервера (дата последней загрузки по сети).

Вы можете создать записи для ваших серверов заранее, используя команду:
deploy-cmd addhost --bootmac=<MAC_АДРЕС> --profile=<ПРОФИЛЬ>

При каждой загрузке сервера виртуализации Auto Deploy просматривает базу и, исходя из назначенного серверу профиля, передает ему нужный загрузочный образ ESXi, а также регистрирует сервер в vCenter, применяет Host Profiles и п.р.

Для просмотра списка доступных профилей используйте команду:
deploy-cmd listprofiles

По умолчанию в Auto Deploy присутствует лишь один профиль - default. Для редактирования настроек профиля используется команда deploy-cmd updateprofile:
deploy-cmd updateprofile --name=default --vcenter=<АДРЕС_VCENTER> --hostprofile=<ИМЯ_HOST_PROFILE> --hostfolder=<ПУТЬ_К_ПАПКЕ>
, где: <ПУТЬ_К_ПАПКЕ> - путь, включающий в себя имя датацентра, в котором требуется зарегистрировать сервер виртуализации. При необходимости включения сервер в HA кластер, путь к папке можно указать в формате "/<ИМЯ_ДАТАЦЕНТРА>/<ИМЯ_КЛАСТЕРА>".

Например, следующая команда позволит настроит профиль default так, чтобы Auto Deploy автоматически регистрировал серверы в vCenter и применял к ним ранее созданный Host Profile:

Теперь перезагрузите сервер. Если вы выполнили все настройки правильно, то после загрузки сервер будет автоматически добавлен в vCenter, переведен в режиме обслуживания (Maintenance Mode), для него будут применены настройки из соответствующего профиля, после чего он будет переведен обратно в штатный режим работы.

Дополнительные сведения
Для всех серверов настоятельно рекомендуется создавать резервации в DHCP, это позволит серверу не только получать каждый раз один и тот же IP адрес, но и задавать ряд индивидуальных настроек, в частности - имя сервера (параметр 012 Host Name).

Если вас не устраивает, что в vCenter серверы ESXi регистрируются по IP адресу, а не по DNS имени, то исправить это можно, создав соответствующие PTR записи в reversed lookup зоне на DNS сервере, который обслуживает vCenter.

Наконец, я заметил следующую закономерность. При тестах использовались  виртуальные серверы ESXi. Частенько при добавлении такого сервера в кластер, если для него выделено меньше 3 Гб памяти, можно получить следующее сообщение об ошибке:  "Cannot complete the configuration of the HA agent on the host. Other HA configuration error".

Заключение
Как вы видите VMware Auto Deploy крайне прост в настройке и работе. Тем не менее, его применение рождает следующие вопросы - кто же будет загружать виртуальные машины с Auto Deploy и vCenter, чтобы те, в свою очередь, загружали серверы виртуализации, почему функционал Host Profiles доступен только в редакции Enterprise Plus, и когда в профилях появится поддержка программного инициатора iSCSI?