company_banner

Хотите попробовать VDI, но боитесь? Тогда мы идем к Вам!

    Общаясь со многими Заказчиками, обратил внимание на то, что многие из них вроде хотят попробовать VDI на вкус, но боятся, что не проглотят – слишком сложно, говорят. Специально для тех, кто думает, что даже пилотное внедрение VDI – это слишком сложно, компания QUEST серьезно переработала установщик ПО vWorkspace с целью значительно упростить «вхождение» в увлекательный мир VDI. В этом посте я пройду вместе с вами, уважаемые коллеги, по всему пути, от самого начала, с установки первого сервера виртуализации, до показа Директору на его любимом iPad, что же это такое — загадочная «инфраструктура виртуальных рабочих столов».

    Итак, начнем! Небольшое уточнение – рассматривается стенд на гипервизоре VMware vSphere 4.1, сервер управления виртуализации VMware vCenter 4.1 и ПО VDI Quest vWorkspace 7.2. Триальный ключ для vWorkspace можно получить при скачивании ПО с сайта вендора (http://www.quest.com/vworkspace/download.aspx). Также предполагается, что в инфраструктуре уже есть домен Active Directory. Если же такового нет (или же, например, для полной изоляции тестового стенда от текущей инфраструктуры, хотя я не считаю это правильным хотя бы потому, что это затруднит тестирование бизнес-ПО, которое уже развернуто в инфраструктуре), то понадобиться еще одна ВМ с ролью контроллера домена. Для начала нам необходимо определиться с тем, сколько же рабочих станций мы будет предоставлять нашим пользователям. Предлагаю ограничиться 5-7, этого должно хватить для того, чтобы понять, оно нам вообще надо или как. Клиентская ОС пусть будет Windows 7, во-первых, эта ОС уже де-факто индустриальный стандарт, а во-вторых я уже знаю, как её оптимизировать :). Что же касается аппаратных характеристик, то предлагаю следующие:
    • 1 CPU;
    • 768 Мб RAM;
    • 40 Гб HDD.
    При этом надо не забывать, что нам еще понадобиться два сервер управления виртуальной инфраструктурой и собственно брокер подключений, сердце VDI. Для пилотного внедрения вполне подойдут виртуальные серверы на том же гипервизоре, на котором будут размещаться и гостевые рабочие станции. Серверные ОС – Windows Server 2008 R2 x 64.
    Аппаратным требованиям серверов:
    • 2 CPU;
    • 2048 Мб RAM;
    • 60 Гб HDD.
    Итого, для всего пилотного проекта нам понадобится сервер со следующими характеристиками:
    • 1 CPU * 4 core;
    • 16 ГБ RAM;
    • 500 Гб HDD (желательно в RAID 10).
    Как видите, коллеги, для нашего стартапа нужно не так уж и много. Грубо говоря, в качестве подобного сервера подойдет даже мощная рабочая станция. Например, я на ноутбуке внутри VMware Workstation с 8 Гб оперативки и Core2Quad развернул подобный стенд на 2 одновременно работающие пользовательские ВМ. Правда, надо уточнить, что я использовать серверы управления на базе ОС Windows Server 2003 x64, дабы максимально эффективно использовать оперативную память.
    Ну что же, приступим. Начнем с установки гипервизора. Я уверен, что большинство из вас так или иначе сталкивались с ESX или ESXi. В нашем стенде можно использовать как первый, так и второй гипервизор. Настройки сервера виртуализации абсолютно стандартные, фактически «next-next-next». Можно использовать сетевые настройки, получаемые с помощью сервера DHCP, однако лучше всего назначить их вручную.
    Теперь на любой рабочей станции (например, на ПК админа) нам необходимо установить VMware Infrastructure Client 4.1 для дальнейшей работы с нашим сервером виртуализации. Сам клиент абсолютно бесплатный и его можно найти на сайте компании VMware.
    После того, как клиент будет установлен, запускаем его и указываем параметры подключения к ESX (IP-адрес сервера, имя пользователя – root, пароль, заданный при установки).

    image

    После подключения проверяем, что ошибок в работе ESX нет. Затем создаем две ВМ, на которые в дальнейшем мы будем ставить ПО VMware vCenter и ПО Quest vWorkspace. Аппаратные характеристики я уже приводил выше. Контроллер жесткого диска желательно выбрать LSI Logic SAS, тип жесткого диска – Thin, сетевую карту – VMXNet3.

    image

    На все три сервера устанавливаем ОС Windows Server 2008 R2 и вводим их в домен. Желательно разрешить удаленное подключения (RDP) для этих серверов, так будет удобнее. После этого на первую ВМ устанавливаем ПО VMware vCenter. Опять же, по принципу «next-next-next». В качестве базы данных выбираем локально устанавливаемый SQL Express.
    Теперь подключаемся к vCenter. Можно перенастроить тот же Infrastructure Client на ПК админа или же подключиться через RDP к самому серверу. Для продолжения работы нам необходимо подключить к vCenter наш сервер виртуализации.

    image

    image

    Отлично! На этом этапе давайте создадим ВМ, которая и будет нашим «золотым» образом клиентского рабочего места. Здесь я, пожалуй, отдам всё на откуп вам, коллеги. Ставьте всё необходимое ПО, патчи и т.п. Главное – не забыть установить VMware Tools и Quest PNTools для корректного управления гостевой ВМ и разрешить подключение Remote Desktop.
    Для оптимизации Windows 7 можно воспользоваться моими же рекомендациями (http://habrahabr.ru/company/croc/blog/110027/). Для ленивых можно воспользоваться бекапом групповой политики, которая позволяет несколько оптимизировать Windows 7 и сэкономить около 100 Мб для «голой» ОС. Казалось бы – копейки, но умножьте это хотя бы на 50-100 (типовой проект VDI) и получается уже 5-10 Гб. Сразу оговорюсь, что применять эту политику в рабочую инфраструктуру без дополнительного тестирования я не советую хотя бы потому, что для различного бизнес-ПО требуются различные сервисы. Идеальный вариант – привязать эту политику на тестовую OU, переместить в неё 3-4 тестовых ПК и убедиться, что всё работает. Политика была создана одним из специалистов компании Quest (http://blogs.inside.quest.com/provision/2010/12/17/tuning-windows-7-for-vdi-with-group-policy/).
    Итак, осталось дело за малым – установить и настроить VDI. Для этого на втором сервере запускаем установку ПО Quest vWorkspace. Уже на первых экранах нам будет предложено выбрать простую установку (Simple):

    image

    Если выбрать эту опцию, то на одном сервере будет установлены следующие компоненты:

    image

    После первого запуска консоли управления vWorkspace Management Console необходимо добавить лицензионный файл, который будет прислан по почте после регистрации на сайте www.quest.com при скачивании ПО.
    Процесс установки завершен, теперь осталось совсем чуть-чуть – несколько простых шагов по настройке vWorkspace. И здесь компания Quest значительно упростила нашу задачу! Уже при первом запуске консоли управления можно выбрать опцию «Virtual Desktops» и пройтись по порядку по всем пунктам.

    image

    image

    image

    image

    image

    image

    image

    Вуаля, как говорится, всё готово!

    image

    Достаточно поставить клиентскую часть Quest AppPortal и всё, пилотный стенд нашего решения VDI можно показывать Директору :).
    Пример настроек Quest AppPortal показан ниже.

    image

    image

    image

    image

    image

    image

    image

    Всегда готов выслушать любые замечания и предложения.
    Искренне ваш, Mikhalych.
    КРОК
    285.53
    IT-компания
    Share post

    Comments 34

      +2
      А что такое VDI?
        0
        Надо полагать www.quest.com/vdi/
          0
          В виртуалбоксе это Virtual Disk Image. А в этой статье это что-то сложное и страшное, но увлекательное. Имеет сердце и вкус.
            0
            Google и Wikipedia намекают, что Virtual Desktop Infrastructure
            0
            Virtual Desktop Infrastructure — Инфраструктура Виртуальных Рабочих мест. Фактически, это перенос пользовательского рабочего места на серверы виртуализации.
              0
              это что-то наподобие терминал сервера, но для каждого пользователя загружается своя виртуальная машина. По виртуальной машине на одного пользователя. При это подключение к виртуальным машинам происходит с тонких клиентов. Трудно сразу так найти преимущества данной схемы. Наверное основное преимущество изоляция пользователя внутри своей ВМ. При отключении в образе ни чего не сохраняется. Получается при каждом подключении всегда чистая ВМ, вирусы пофигу… Наверное удобно когда всем загружается ВМ из одного образа. Внес изменения в мастер образ и у всех появилось новое ПО.
                0
                Не совсем так. Например, можно привязывать ВМ конкретным пользователям и тогда все изменения будут сохраняться. Более того, можно хранить профиль пользователя на сетевой папке (перенаправлять в него данные средствами Quest в данном случае) и тогда при пересоздании ВМ все пользовательские настройки, документы и т.п. также сохранятся.
                  0
                  а можно пример использования, который показывает как с помощью этой технологии можно на чем-нибудь сэкономить? Просто я слишком мелко плаваю и ничего в голову придти не может, как это может пригодится мелким предприятиям.
                    0
                    Самый простой пример — call-центр. Второй вариант — банки или любые другие организации, где необходимо максимально ограничить физический доступ к неким данным. Т.е., пользователь работает с удаленными данными без возможности скопировать их на локальное рабочее место.
                      0
                      так это понятно, но какое преимущество по сравнению со схемой терминалсервер и РДПклиенты.
                        0
                        Терминальные серверы — это, фактически, расшаренный на несколько пользователей одного сервера. VDI — это персональная ВМ для каждого пользователя. Плюс есть приложения, которые категорически не работают в терминальных сессиях.
                        По сравнению с обычным RDP это автоматическое развертывание ВМ в зависимости от кол-ва подключений из единого образа, полный контроль за подключениями, простота администрирования.
                          0
                          как на счет фотошопа и 3дмакса по такой схеме для студии?
                            0
                            Фотошоп — работает, проверено :)
                            Что касается 3дмакса и вообще 3д-моделирования, то здесь можно использовать bladePC, доступом к которым, опять же, управлять с помощью vWorkspace. Плюс такого решения в том, что bladePC находятся в серверной (охлаждение, пожарная и физическая безопасность и т.п.), а на клиентском рабочем месте стоит маленький клиентик, монитор, клава и графический планшет.
                            ЗЫ. У нас есть опыт внедрения решений на bladePC для 3д-проектирования, к слову сказать.
              –2
              Я может немножко туплю, но ведь у VMware есть View, зачем же нужно стороннее ПО (Quest Software)? Или VMware View настолько убог, что без сторонних костылей — никак?
                0
                vWorkspace — это аналог View. Для View не надо никакого стороннего ПО. Речь идет об использовании гипервизора VMware vSphere.
                  0
                  Ну я примерно так и понял. Не понял только смысла городить огород из нескольких вендоров. Логичнее, казалось бы, сделать все на VMware.
                    0
                    К сожалению, VMware View не позволяет буквально за «два клика», как описано в данном топике, настроить полностью работоспособную инфраструктуру VDI. Если брать функционал, то оба продукта примерно одинаковы, однако Quest позволяет чуть больше за те же деньги.
                      0
                      Это например какой функционал? Полагаю, у Quest нет аналогов Linked Clones, Local Mode или Thin App?

                      Сильной стороной VMware также является то, что при покупке любого Bundle, в комплекте идут лицензии VMware vSphere for Desktops.
                        0
                        Коллега, Вы не правы :)
                        Linked Clone у Quest есть. Насчет Local Mode — будет в Q1 2011. Хотя, если честно, я не вижу пока смысла его использования. Ведь досту к своему рабочему месту из Интернет необходим для доступа к неким корпоративным данным в локальной сети предприятия. А если нет доступа к Интенет, зачем тогда просто виртуальная машина?
                        По поводу лицензий — а в неё входить Composer? Если нет — тогда это бесполезно, потому что сразу теряется такая нужная фича, как Linked Clone или ThinApp.
                        Насчет ThinApp — Quest умеет использовать как его, так и App-V от Microsoft. Можно также управлять просто msi-файлами. Плюс есть возможность опубликовывать приложения, запущенные в другой ВМ. Например, опубликовывать в Windows XP те приложения, которые не работают в Windows 7. При этом пользователь даже не узнает, что его приложение работает в другой ВМ.
                        Кстати, насчет доступа из Интернета. View, к сожалению, не умеет работать ТОЛЬКО через собственный SSL-шлюз по протоколу PCoIP. Для этого необходимо подключение точка-точка между пользователем в Интернет и его ВМ внутри сети предприятия, что никак не вяжется хоть с какой-нибудь безопасностью. Тогда как Quest может работать через свой SSL-шлюз, и в данном случае достаточно открыть для доступа из Интернета только порт 443 (или любой другой по решению администраторов) на SSL-шлюзе.
                        У Quest есть другое преимущество — данное ПО позволяет управлять всем окружением пользователя (профиль, настройки рабочего стола, перенаправления реестра и др.), включая детельные настройки подключения (протокол подключения, возможность подключать принтеры, USB-устройства, гарнитуры, битность рабочего стола и еще много чего) из одной консоли. Плюс есть возможность даже без настройки клиентской части определять настройки подключения (сервер, порт, автоматический запуск приложений/ВМ и т.п.).
                        В любом случае, у каждого ПО есть те или иные преимущества и говорить о том, что View или vWorkspace однозначно лучше в ЛЮБЫХ случаях я бы поостерегся :).
                          0
                          Linked Clone у Quest есть

                          С аналогом Recompose, Rebalance и Storage Tier?

                          А если нет доступа к Интенет, зачем тогда просто виртуальная машина?

                          Local Mode и аналоги — вполне себе конкурентное преимущество, недаром Citrix спешила его в XenDestop 5 реализовать.

                          По поводу лицензий — а в неё входить Composer? Если нет — тогда это бесполезно, потому что сразу теряется такая нужная фича, как Linked Clone или ThinApp.

                          Кхм… это зависит о того, какие клиентские лицензии — VMware View Enterprise или Premier покупаем, но в бандл, в любом случае, vSphere входит.

                          Насчет ThinApp — Quest умеет использовать как его, так и App-V от Microsoft.

                          Хм, любое VDI решение на Windows может использовать виртуализацию приложений, вопрос — входит ли решение по виртуализации приложений в стоимость лицензий, как, например, у VMware, Citrix или Microsoft?

                          Кстати, насчет доступа из Интернета. View, к сожалению, не умеет работать ТОЛЬКО через собственный SSL-шлюз по протоколу PCoIP.

                          Не умеет, пока что. Но никто не мешает использовать сторонние решения по организации VPN доступа или переключаться на RDP.
                            0
                            C аналогом Rebalance и Recompose. Storage Tier можно построить на аналоге от EMC, например.
                            Насчет Local Mode — у Citrix и их Xen это совсем другое. Local Mode у View — это всего лишь виртуальная машина, установленная в ОС Windows, которая синхронизируется с серверами. В Citrix — это гипервизор, установленный на «железе», не даром у них поддерживаемых конфигурациях раз-два и всё.
                            В любом случае, у Quest такая фича тоже планируется.
                            Насчет лицензий — Вы же говорили про лицензии, которые входят в «любой» бандл, а там самая простая лицензия, без Composer. А Enterprise значительно дороже. По памяти не помню, но что-то около 2 раз на пользователя.
                            В стоимость Quest не входит, это минус, согласен. Однако управление из единой консоли тоже стоит денег :).
                            Сторонние решения можно, но зачем, если есть «из коробки»? :) А использовать «голый» RDP — зачем же тогда городить огород? Ведь RDP на данный момент весьма требователен к каналу, особенно это касается мультимедийных вещей.
                              0
                              В Citrix — это гипервизор, установленный на «железе», не даром у них поддерживаемых конфигурациях раз-два и всё.

                              И какая же концептуальная разница между этими решениями? Кроме того, что у Citrix крайне ограничен список поддерживаемого оборудования?

                              Насчет лицензий — Вы же говорили про лицензии, которые входят в «любой» бандл, а там самая простая лицензия, без Composer. А Enterprise значительно дороже. По памяти не помню, но что-то около 2 раз на пользователя.

                              Enterprise как раз без Composer, Premier — с Composer. Стоят, соответственно, 150 и 250$ если брать в бандле.

                              Ведь RDP на данный момент весьма требователен к каналу, особенно это касается мультимедийных вещей.

                              Но мы же говорим о медленном канале с высокими latency, например, когда сотрудник работает из дома или в командировке? Не комфортнее ли им было бы работать с локальной виртуальной машиной? :)
                                0
                                Концептуально-то одинаково, реализация сильно отличается, о чем я и говорил.
                                Насчет лицензий — спасибо, это действительно моя «беда» — никак запомнить не могу. :)
                                Я вот до сих пор в проектах не сталкивался с тем, что есть требования работать с ВМ без канала связи. Скорее наоборот, о чем я уже писал, стоят задачи доступа (пусть даже по плохим каналам связи) к внутренним ресурсам. И тут Local Mode не поможет, я боюсь.
                                Зато стоят задачи, к примеру, доступа из сети Интернет через единую точку входа как раз на плохих каналах, где RDP показывает себя крайне плохо, а PCoIP использовать не получается. Зато EOP (оптимизированный протокол Quest) расцветает во всей красе.
                                И всё-таки я настаиваю, что нет однозначно подходящих решений. Где-то View, где-то Quest, где-то даже Citrix :).
                                Я не вижу смысла продолжать данный ходивар здесь. Если есть желание — давайте пообщаемся лично, через почту.
                              0
                              ЗЫ. И уж если затронули тему «что будет». В том же Q1 2011 с помощью vWorkspace появиться возможность построить VDI на полностью бесплатных решениях ESXi и Hyper-V без необходимости использования vCenter и SCVVM для управления.
                              Но этак, к слову.
                  0
                  Я правильно понял, что из сети грузится и запускается VMWare-образ на клиентской машине? Плюс ко всему через специальный софт на этом образе идет мониторинг этих гостевых ОС?
                    0
                    Немного не так. Сами ВМ физически располагаются внутри системы виртуализации. Никакие образы по сети не грузятся. ПО сети пользователи получается доступ к ВМ посредством оптимизированного протокола RDP. Специальный софт (PNTOOLS или Quest vWorkspace Agent) мониторит состоянии пользовательской сессии и состояние самой ВМ (доступна — недоступна). Плюс через этот же софт, установленный в образе, происходит SYSPREP клонов.
                    +1
                    все это хорошо, но есть ли какие-то расчеты по мощности?
                    «N таких-то лезвий на M проектировщиков с acad2010 + msoffice 2010»? Опять же интересно как это все будет жить при количестве юзеров, стремящемся к сотне, к тысячи. Понятно, что сама сфера позволяет собирать совершенно эпические по масштабам кластера, но как показывает моя практика — нагрузка на бОльшую часть серверов как правило не такая большая, и в основном ресурсы кушают сервера БД, в то время как файловые сервера, сервера лицензий и т.д. и т.п. — имеют вполне скромные аппетиты. А тут предлагается перетянуть воркстейшены, которые и должны мало того что протягивать 3д графику (кстати, как оно с этим? Каким образом сейчас реализуется ускорение 3D в отсутствие видюх?), так еще и оставаться комфортными для мышеползания юзеров. Короче хочется хотя бы примерных раскладок по масштабируемости и нагрузке. Ежели есть опыт внедрения в немалых офисах — опять же интересно.
                      0
                      Начну с конца :)
                      В отсутствии полноценных видео карт реализовать 3Д-графику не представляется возможным. Для этого используются bladePC (о чем говорилось выше) как раз с нормальным мощным видеоускорителем, а пользователям отдается всего лишь удаленный рабочий стол к этим bladePC.
                      Насчет нагрузки на серверы — можно принимать, что для стандартного пользователя (Office, IE, не «тяжелое» видео) на каждое серверное ядро можно посадить до 12-16 пользовательских ВМ. Реальными являются порядка 8-10. По памяти всё сложнее. Всё зависит от задач, которые выполняют пользователи. Если это, например, операторы call-центра, то предполагается, что в один момент времени эти задачи отличаются не слишком сильно, а значит, экономия памяти при использовании ESX может достигать 30-40% и больше. Таким образом, если взять 6 ядерный сервер с 64 Гб памяти, то на него можно «посадить» до 60-70 пользовательских ВМ (Windows XP с 1 CPU и 1Гб каждая).
                      Насчет опыта внедрения в больших офисах — есть пилот с ростом до на ~4000 пользователей в разных регионах с единым ЦОД.
                        0
                        «4000 пользователей в разных регионах с единым ЦОД» что-то мне это напоминает. Не атомный пилот часом? =)

                        По теме — я правильно понимаю, что все же этот подход рассчитан более на «стандартного пользователя (Office, IE, не «тяжелое» видео)», то есть когда есть несколько десятков воркстейшенов с офисом и более ничего — отдаем сервак и все счастливы? То есть в ситуации когда имеется несколько сотен юзеров с разнообразным софтом (акад такой, акад другой, у пары человек скад, у десятка — электрикс) — эффект может быть противоположным?
                        В пилоте какие-то достижения интересные есть?
                          0
                          Не атомный :) Совсем из другой оперы.
                          VDI вообще больше расчитан именно на стандартизованный подход к рабочему месту. В противном случае затраты на поддержание всех этих различных десктопов не окупится.
                            0
                            А вот еще такой вопрос — как обстоят дела с периферией? Принтеры/сканеры, локальные, сетевые. У меня вот дикое уважение к цитриксу в этом плане — то что они допилили проброс локальных принтеров, это вообще здорово облегчает жизнь =). В данном случае все эти радости присутствуют? Внутри виртуалки надо что-то шаманить, чтобы юзер имел счастье печатать на свою тумбочку? =)
                              0
                              Никаких проблем. Хоть каждому пользователю по своей тумбочке, включая USB :)
                              Есть возможность гибко настраивать возможность печати + оптимизация трафика печати, если пользователь и его принтер находится в одном регионе, а собственно серверы виртуализации — в другом.
                                +1
                                Ок, это хорошо! Спасибо за пост и за ответы =)
                                0
                                PS. И ничего внутри каждой виртуалки шаманить не обязательно — настраивается всё на уровне серверов, групп пользователей, IP-подсетей, устройств подключения и т.п., и др. :)

                      Only users with full accounts can post comments. Log in, please.