Введение
Виртуализация, как и само слово «виртуальный», не новы в компьютерном мире. Виртуальные диски, виртуальные каталоги, виртуальная реальность – это словосочетания нам приходилось слышать уже довольно давно. Само же значение слова «виртуальный» довольно размыто. Самым точным будет, пожалуй, такое определение: «То, что является не таким, как кажется». Соответственно, слово «виртуализация» проще всего понимать как «перенос чего-либо из привычного нам места».
Виртуализация стала особенно популярна в последние годы. Существует множество видов виртуализации, но мы рассмотрим лишь те, что применимы к самому массовому сегменту – серверам стандартной архитектуры, рабочим станциям, и ПО для них. То есть тот сегмент, который интересен широкому кругу работников ИТ индустрии.
Виды виртуализации и история
До 90-х годов компьютерные вычисления были связаны главным образом с мейнфреймами (см. Рис. 1):
Рис. 1 |
Клиентская рабочая станция была лишь терминалом для доступа к серверу, а все вычисления производились на мейнфрейме. На что была похожа подобная многопользовательская система, можно примерно представить по текстовому многопользовательскому режиму современных UNIX/Linux систем.
Шло время, вычислительные ресурсы становились все доступнее, менее энергоемкими и меньшими по размерам, пока не превратились в знакомые нам персональные компьютеры. В начале 90-х годов устоялась привычная нам модель – разделение на серверы и рабочие станции, каждые со своими операционными системами, и приложениями, которые взаимодействовали друг с другом посредством сетевых протоколов. С развитием персональных компьютеров вычисления стали производиться непосредственно на рабочих местах, программное обеспечение устанавливалось локально, а обмен данных с удаленным сервером происходил посредством каналов связи с крайне невысокой по сегодняшним меркам пропускной способностью (модемные соединения около 9600 бит в секунду) (см. Рис. 2):
Рис. 2 |
В то время на персональных компьютерах в большинстве своем устанавливались однопользовательские операционные системы, и возникала проблема взаимодействия людей внутри рабочей группы. В это же время начали развиваться локальные сети, соединяющие машины в пределах одного здания, начали появляться сетевые операционные системы, в частности, Windows и OS/2.
Модель организации рабочего места, когда у каждого пользователя есть свой компьютер со своей персональной операционной системой хорошо подходила для работы в текстовых и графических редакторах, но не всегда подходила для работы с базами данных, так как объем передаваемых данных зачастую превышал возможности каналов, надежность которых была невысока, а запросы в базу данных должны были происходить надежно.
Для решения подобных проблем компания Citrix в 1995 выпустила продукт WinFrame, который стал частью ОС Windows NT 4 Terminal Server Edition.
Суть решения была такова: персональные компьютеры являются лишь терминалами, которые передают нажатия клавиш и движения мыши, принимают изменения изображения, а все вычисления происходят на стороне сервера. Для этого код Windows NT был модифицирован, чтобы позволить одновременный вход в систему нескольких пользователей. Данное решение можно считать первой реализацией виртуализации рабочих столов. Пользователь физически находится за своим персональным компьютером, но видит на своем экране рабочий стол сервера, и с точки зрения операционной системы – является локально работающим на сервере пользователем (см. Рис. 3):
Рис. 3 |
Компания Citrix в рамках соглашения с Microsoft выпускает продукт Metaframe, являющийся надстройкой к NT4 Terminal Server Edition. Помимо некоторых технических преимуществ, этот продукт позволял показывать пользователю не рабочий стол сервера, а окно отдельного приложения. Этот продукт можно считать первым вариантом виртуализации приложений. Пользователь мог независимо работать и с локально установленными приложениями, и с приложениями, установленными на сервере, переключаясь между ними по мере надобности.
Данные продукты применялись в основном для ненагруженных графикой приложений, таких как клиенты СУБД, а также для некоторых офисных приложений. В ряде случаев они позволяли экономить пропускную способность каналов, в ряде случаев наоборот, но в качестве плюсов можно заметить, что при потере связи процессы на сервере продолжали выполняться, что положительно сказывалось на надежности работы с СУБД.
Тем временем в 1997 году компания Connectix создала продукт Virtual PC для эмуляции работы Windows на MacOS. Позже, в 2003 году, Connectix была куплена Microsoft, и продукты Virtual PC и Virtual Server отошли к Microsoft. А в 1998 году образовалась компания VMWare, которая стала локомотивом виртуализации ОС. Ее первый продукт, VMWare Workstation, вышел в 1999 году. И если Virtual PC особой популярности не снискала (хотя используется до сих пор, в виде Windows XP Mode в Windows 7), то продукты VMWare получили заслуженное признание, и вывели виртуализацию рабочих мест на новый уровень.
Суть работы данных продуктов была в виртуализации операционной системы целиком. В отдельном окне пользователь видел рабочий стол полностью независимой операционной системы, со своим собственным набором приложений. Появился новый термин – Гипервизор, означающий программное обеспечение, на котором запускалась другая операционная система. Гипервизор управляет доступом к физическим ресурсам компьютера.
Существуют гипервизоры первого типа и гипервизоры второго типа.
Обозначение «гипервизор первого типа» означает, что гипервизор является операционной системой, устанавливаемой на железо, а все остальные ОС с полезной нагрузкой работают через него.
Обозначение «гипервизор второго типа» означает, что гипервизор работает на операционной системе, выполняющей также другую полезную работу. VMWare Workstation и Virtual PC относятся к гипервизорам второго типа (см. Рис. 4):
Рис. 4 |
Очевидное преимущество гипервизоров второго типа, сделавшее их популярными, это работа поверх имеющейся операционной системы. Пользователь не лишается привычного функционала, все устройства работают как раньше, драйверы для всех устройств – это проблема производителей устройств, а не производителя гипервизора или пользователя. А поскольку в качестве несущей операционной системы выступает ОС Windows – драйверы проблемой не являются. Пользователь всего лишь лишается некоторого количества памяти, процессорного времени и места на диске. Поэтому гипервизоры второго типа снискали популярность у разработчиков ПО и ИТ – персонала в качестве тестовых лабораторий, а также из-за возможности содержать несколько рабочих мест на одном физическом компьютере.
Важнейшим недостатком гипервизоров второго типа является отсутствие монопольного доступа к вычислительным ресурсам компьютера. Это значит, что гипервизор имеет точно такую же долю процессора и оперативной памяти, как запущенное в несущей ОС приложение, которое может быть очень ресурсоемким. Подобная ситуация делает гипервизоры второго типа непригодными в качестве платформы для виртуализации серверных приложений, несущих серьезную нагрузку.
Исходя из того, что гипервизоры второго типа являются, пусть и специфическими, но всё же приложениями операционной системы, такой продукт как VMWare GSX Server не снискал популярности в качестве платформы для виртуализации серверных операционных систем, несмотря на достойный функционал – он использовал Windows Server в качестве платформы.
Подобным недостатком не обладает гипервизор первого типа, работающий на голом железе (см. Рис. 5):
Рис. 5 |
Также гипервизоры первого типа называются Bare-Metal гипервизорами. Операционная система–гипервизор устанавливается непосредственно на железо, и управляет аппаратными ресурсами. Таким образом, гостевые операционные системы имеют одинаковые привилегии на доступ к физическим ресурсам. По этому принципу был построен VMWare ESX Server, выпущенный в 2001 году. Изначально продукт базировался на RedHat Linux, но со временем от Linux остался практически только загрузчик, который запускает специализированное ядро. Начиная с версии 3.5, продукт начинает широко применяться в промышленной эксплуатации, также применяются продукты Microsoft, Citrix и несколько OpenSource реализаций, и в данный момент большинство компаний использует серверную виртуализацию с гипервизорами первого типа, устанавливаемыми на голое железо.
Стоит отметить, что гипервизоры первого типа применяются и при виртуализации рабочих мест, при этом положительные и отрицательные качества усиливаются – позитивным моментом является то, что на одном сервере становится возможно разместить большое число виртуальных машин пользователей, но при этом становятся острее проблемы с драйверами устройств, например, страдают устройства, подключаемые к портам USB.
Серверная виртуализация оказалась для IT стопроцентным выигрышным методом, но ведущие компании решили не останавливаться на достигнутом, ведь на рынке оставались миллионы рабочих станций, для которых некоторые наработки серверной виртуализации также могут быть применены. А с учетом тенденции к значительному увеличению пропускной способности каналов, возникла модель, в которой физически рабочее место располагается в дата-центре, а пользователь имеет удаленный доступ к нему посредством протокола удаленного доступа. С одной стороны – подобный подход уже много лет использовался с продуктами Citrix и Microsoft, с другой – подобное пересечение технологий удаленного доступа и серверной виртуализации позволяет предоставить пользователю действительно персональное рабочее место – виртуальную машину, в которой он будет единственным пользователем и сможет монопольно распоряжаться всеми ресурсами, доступными этой виртуальной машине. Такая гибридная модель является видом виртуализации рабочих мест под названием «инфраструктура виртуальных десктопов» или VDI (см. Рис. 6):
Рис. 6 |
Организация ИТ-инфраструктуры компании при таком способе виртуализации рабочих мест позволяет выделить каждому пользователю действительно персональное рабочее место, не зависящее от других пользователей и работающее на высокопроизводительном аппаратном обеспечении, при этом люди, работающие на таких виртуальных ПК, физически могут находиться на огромном расстоянии от центра обработки данных. А пользовательские персональные компьютеры можно заменить на тонкие клиенты, которые стоят дешевле и имеют больший срок жизни. На практике идея оказалась не столь успешной, но определенную долю рынка она завоевала.
Примерно с 2009 года у людей стали массово появляться смартфоны и планшеты, что сильно изменило привычные запросы пользователей к ИТ-службе предприятия, так как пользователи захотели использовать свои планшеты для работы. И индустрия отреагировала на это оптимизацией технологий под мобильные устройства, для доступа к привычным ресурсам с мобильных устройств с приемлемым уровнем удобства. Конечно, мобильные устройства существовали и раньше, но существующие на тот момент интерфейсы не позволяли использовать эти устройства для полноценной работы. И устройства на Windows Mobile и Palm оставались уделом немногих. Именно появление удобных интерфейсов ОС iOS и Android спровоцировало взрывной рост популярности мобильных устройств. И в этих ОС не обошлось без виртуализации приложений – все приложения, которые устанавливает пользователь, запускаются в Sandbox, дословно – в песочнице. Это означает, что приложение функционирует в своей защищенной среде. Но эта среда защищает не столь приложение от внешних факторов, сколько само устройство и другие приложения от него. Это позволяет добиться высокого уровня надежности устройства, что также положительно влияет на популярность мобильных устройств в качестве устройств для серьезных задач.
Параллельно с развитием технологий серверной виртуализации шло совершенствование методов виртуализации десктопов и приложений. Протоколы RDP и ICA совершенствовались, функционал расширялся, значительно улучшилось то, что всегда было больным местом терминальных серверов – печать. Также появилась поддержка более широкого спектра устройств – веб-камер, сканеров. Стало возможно использовать 3D-приложения с использованием некоторых новых технологий перенаправления. И в том числе друзья/конкуренты старались решить задачу с отделением приложений от операционной системы сервера. Microsoft перекупил компанию Softricity и ее продукт SoftGrid, пока Citrix вел с оной переговоры о цене. Citrix тем не менее представил сначала среду изоляции приложений (AIE), позволяющую запускать приложения в Sandbox, а потом добавил к этому функционалу возможность загрузки образов приложения по сети, Application Streaming. Вскоре Microsoft представил App-V, собственную среду изоляции приложений, обладающую схожим функционалом. А компания VMWare в 2008 году приобрела компанию Jitil и на базе их продукта Thinstall предлагает решение для виртуализации приложений ThinApp.
Также следует упомянуть о таком методе виртуализации, как стриминг образов дисков. Этот метод не нов, и заключается в том, что обычный ПК превращается в бездисковую станцию, загрузка которой осуществляется по локальной сети, посредством доставки образа диска.
Следующий шаг виртуализации – это облачные вычисления. Виртуализация позволяет переместить ИТ-сервисы из собственных помещений в дата-центр обслуживающей организации, поменяв попутно подход к оплате расходов на ИТ: вместо покупки оборудования, лицензий на ПО, затрат на внедрение, поддержку, кондиционирование, электропитание и т. д. – оплачиваются предоставляемые сервисы. Это позволяет более точно рассчитывать бюджеты, так как месячные платежи фиксированы и призвано снизить расходы конечных заказчиков на ИТ. Модели именуются как «Software as a Service» (SaaS), «Desktop as a Service», «Infrastructure as a Service» (IaaS) и т. д.
Но с технической точки зрения за этими аббревиатурами стоят уже знакомые нам технологии виртуализации, которые могут быть классифицированы (см. Рис. 7):
Рис. 7 |
Более того – методы виртуализации можно комбинировать, достигая конкретных специфичных конфигураций, позволяющих заказчикам извлекать из этих технологий максимальную выгоду. Можно смело утверждать, что каждая организация может извлечь ту или иную выводу из технологий виртуализации.
Серверная виртуализация
Серверная виртуализация – это самый распространенный и самый популярный вид виртуализации.
ИТ-службы компаний любого размера сталкивались с двумя противоположными задачами. С одной стороны, нужно максимально полно использовать возможности серверного аппаратного обеспечения. С другой – необходимо разносить критические сервисы по разным серверам, в идеале: один сервер – одна ОС – один сервис. Администраторы решали, какие сервисы можно совместить на одной ОС и одном сервере, находя определенный баланс между этими требованиями максимальной загрузки оборудования и изоляции сервисов друг от друга. Например, нередка была ситуация, когда на контроллере домена устанавливался терминальный сервер, что порождало много проблем с конфигурацией и настройкой. Появление продуктов для серверной виртуализации позволило решить эти проблемы позволяя консолидировать сервисы, не смешивая их в пределах одной операционной системы. Таким образом, небольшие компании получили возможность разместить на небольшом парке серверов большее количество операционных систем, упростить конфигурацию сервисов, повысить степень отказоустойчивости. Крупные же компании смогли сэкономить на аппаратном обеспечении значительные суммы.
Более эффективное использование ресурсов в виртуализованной среде достигается в первую очередь за счет более эффективного использования процессоров. В большинстве физических сред процессоры серьезно недогружены, так как не каждый сервис создаёт нагрузку на процессор, способную его полностью загрузить. Уплотнение серверов на гипервизорах позволяет загружать процессоры более полно.
Оперативная память в виртуализованной среде также используется эффективнее за счет уплотнения серверов и из счёт применения технологий уплотнения памяти.
Ещё одним большим плюсом серверной виртуализации помимо консолидации вычислительных ресурсов, стала возможность обслуживания аппаратного обеспечения без прерывания работы. Появилась возможность эвакуации работающего виртуального сервера с аппаратного сервера, отправляемого в режим обслуживания на страховочный сервер без прерывания работы. Более того, живая миграция серверов между гипервизорами позволила реализовать сценарии высокой доступности средствами гипервизора, а технология снэпшотов позволяет легко откатить назад сервер к состоянию, предшествующему обновлению или установки ПО. Совместно эти две технологии позволяют проводить резервное копирование «на лету».
Рис. 8 |
Ещё одним достоинством серверной виртуализации является виртуализация сетевой подсистемы, позволяющая получить небывалую гибкость в настройке сетевых топологий, так как виртуальная машина может содержать множество сетевых интерфейсов, отвязанных от конкретных портов сетевого оборудования. Отказоустойчивость также повышается – если ранее требовалось использовать два сетевых интерфейса, подключаемых к разным коммутаторам и настраивать работу портов в совместном режиме (teaming), то теперь использование двух сетевых адаптеров не требуются благодаря обеспечению отказоустойчивости гипервизором. При использовании Tagged Vlan настройку требуют лишь гипервизоры, сами виртуальные операционные системы не требуют специальной настройки, а лишь включаются в виртуальные сети (см. Рис. 9):
Рис. 9 |
При виртуализации дисковой подсистемы, с одной стороны, происходит некое падение производительности, за счет появления дополнительного уровня абстракции между ОС и данными, но с другой – диск виртуальной машины является файлом в определенном формате, который не привязан к оборудованию (контроллеру, жесткому диску) и может мигрировать между серверами и системами хранения. Или, при реализации инфраструктур высокой доступности, диск виртуальной машины может храниться в единой точке и подключаться к тому гипервизору, на котором в данный момент запущена виртуальная машина. Еще один плюс серверной виртуализации – возможность экономить дисковое пространство за счет совместного использования виртуальными серверами одного виртуального жесткого диска (см. Рис. 10):
Рис. 10 |
Несмотря на все свои преимущества, у серверной виртуализации есть несколько минусов. Во-первых – это усложнение системы по сравнению с базовой архитектурой, так как добавляется новый уровень абстракции в виде гипервизора первого типа. Во вторых – для обслуживания системы требуется более квалифицированный персонал пусть и в меньшем количестве. В третьих – наиболее функциональные системы серверной виртуализации стоят значительных средств. И в четвертых – усложняется использование периферии. Подключение разнообразных ключей, USB- и COM- устройств сильно усложняется в виртуальной среде, и может потребовать применения дополнительного ПО, что также не прибавляет системе простоты.
На первый взгляд, значительным минусом является удорожание системы за счет большего числа ОС, а значит и лицензий на них. Но у Microsoft и других вендоров действуют особые условия лицензирования в виртуальной среде. Например, купив 1 лицензию Windows Server 2008 Enterprise, мы можем установить 1 копию ОС на физический сервер, установить там Hyper-V и разместить на нем еще 4 ОС на виртуальных машинах.
Плюсы и минус
- Экономия на аппаратном обеспечении, охлаждении и электропитании.
- Упрощение администрирования.
- Повышение отказоустойчивости.
- Упрощение миграций, резервного копирования, обновлений системы.
- Усложнение системы.
- Требуется более высокая квалификация персонала.
- Усложнение работы с нестандартной периферией серверов;
- Удорожание системы за счёт приобретения дополнительного ПО.
Основные игроки рынка серверной виртуализации
На рынке серверной виртуализации много продуктов и вендоров. Но в первую очередь следует упомянуть компанию VMWare. Первые продукты сегмента были гипервизорами второго типа и ставились на Windows Server (VMWare GSX). Особой популярности продукт не достиг, и позже был переименован в VMWare Server, применяемый для лабораторий. Другой продукт, VMWare ESX, постоянно эволюционировал, и является на данный момент самым передовым продуктом в области серверной виртуализации, с самым широким функционалом. Продукт поддерживает сложные технологии, такие как технология разделения памяти, позволяющих экономить физическую память и позволяет нескольким гипервизорам работать вместе под управлением сервера vSphere для реализации самых сложных топологий, в том числе, распределенных по разным площадкам.
Припозднившаяся на арене виртуализации компания Microsoft активно включилась в конкурентную борьбу со своим продуктом Hyper-V, который на данный момент обладает хорошим набором функций за разумные деньги, и хорошо интегрируется в инфраструктуры Microsoft. Консоль управления Virtual Machine Manager, входящая в пакет System Center, позволяет управлять разными гипервизорами (даже разных вендоров) из одной точки. Поскольку базой для гипервизора является Windows Server, Hyper-V обладает самой лучшей поддержкой оборудования среди других гипервизоров, за счет того, что драйверы оборудования в первую очередь создаются для Windows систем.
Среди коммерческих гипервизоров также следует отметить Citrix XenServer. Основанный на бесплатном гипервизоре Xen, он предлагается в разных редакциях. Базовые редакции бесплатны, самые сложные и дорогие по функционалу приближаются к гипервизору VMWare. Консоль управления Xen Center обладает очень удобным и понятным интерфейсом. Также существуют виртуальные устройства, расширяющие функционал при работе в пуле гипервизоров, например, Distributed Virtual Switch. В целом, гипервизор не получил особой популярности, на некоторый взгляд – незаслуженно.
Среди бесплатных реализаций нужно отметить XEN Source и KVM (Kernel-Based Virtualization). Также есть бесплатные системы управления гипервизорами и не только (проект Open Stack).
Практические рекомендации
Планируя внедрение серверной виртуализации очень важно правильно сформулировать решаемые задачи и выбрать подходящую платформу и ее редакцию, которая будет эти задачи решать. Рекомендуется потратить некоторое время на сравнение функционала и цен на разные решения. Так, например, решение от VMWare обойдется дороже конкурентов, но на практике большинство компаний использует решения этого вендора. Hyper-V разумно внедрять как дополнение к имеющейся инфраструктуре Microsoft. Для его работы потребуется иметь один невиртуализованный контроллер домена. Citrix XenServer имеет хороший функционал за свои деньги, но нужно быть готовым к некоторой капризности продукта, и что иногда потребуется запускать консоль для решения тонких моментов.
В качестве платформы для виртуализации подойдут как серверы, устанавливаемые в стойку, так и blade-серверы. Количество серверов стоит подбирать так, чтобы они были загружены по процессору и памяти не более чем на 80% в нормальном режиме, но при выходе из строя или выводе на обслуживание одного сервера загрузка не превысила 100%. Важно рассчитать решение так, чтобы все сервера были загружены равномерно. Прикинув количество серверов, следует посчитать загрузку процессора, не выходя за ограничения количества виртуальных машин на ядро. Количество памяти – самый гибкий параметр, и его проще всего подсчитать, но важно иметь возможность добавить модули памяти, не стоит брать серверы со всеми слотами, забитыми памятью. После первого подсчета следует еще раз прикинуть, не станет ли нагрузка чрезмерной при выходе из строя одного сервера, а также прикинуть нагрузку на сетевую и дисковую подсистему. Для расчёта дисковой подсистемы нужно учитывать три параметра: ёмкость, ширину полосы пропускания и количество операций ввода-вывода (IOPS). И уже исходя из этих параметров выбрать систему хранения, метод подключения (iSCSI, FC, NFS), уровень RAID с требуемой отказоустойчивостью, количество и размер дисков. Общее хранилище данных необходимо при реализации сценариев балансировки нагрузки и высокой доступности, живая миграция виртуальных машин также возможна только при наличии разделяемого хранилища.
Виртуализация приложений
Классический метод использования приложений – это установка их на рабочее место пользователя. Этот метод был, есть и останется с нами. Но в целом ряде случаев он не соответствует реалиям времени. Во-первых, некоторые приложения могут часто обновляться. Во-вторых – набор приложений может расширяться. В-третьих – приложения могут конфликтовать друг с другом. В средних и крупных компаниях эти факторы приводят к большим временным затратам на поддержку ПО. Раньше службы поддержки ПО старались обеспечить унификацию рабочих станций и распространять готовые образы жестких дисков. Но процедура создания эталонного образа довольно продолжительна по времени и не учитывает тот факт, что разным сотрудникам для работы требуется разное ПО, поэтому ИТ-службе приходится изготавливать несколько эталонных образов. Рассмотренные ниже технологии виртуализации программного обеспечения позволяют решить ряд указанных проблем.
Удаленный доступ к приложениям (терминальный доступ)
Вкратце про этот метод уже было сказано выше - пользователи запускают браузер или просто кликают на особом ярлыке, и, используя сетевое подключение, осуществляют удаленный вход на ферму терминальных серверов. При входе загружается пользовательский профиль, пользователь осуществляет вход на терминальный сервер, а потом запускает приложение. При этом пользователь не видит рабочего стола сервера, ему отображается лишь окно приложения, которое интегрируется в рабочее место абсолютно также, как окно локально установленного приложения. Пользователь может сворачивать и перемещать его, как будто оно является окном локального приложения, и может вообще не заметить разницы между локальным приложенным и приложением, работающем в терминальном режиме. Пользователь в своей работе может использовать локальные ресурсы (диски, вебкамеры, микрофоны, сканеры, принтеры и т.п.). При закрытии приложения осуществляется закрытие пользовательской сессии на сервере и выгрузка профиля.
Плюсы и минус
Предоставление приложений с помощью терминального сервера позволяет решить ряд задач. На оконечное рабочее место не требуется устанавливать ПО кроме клиента Citrix, а клиент Microsoft предустановлен и с 2008 версии Windows Server позволяет запускать отдельные приложения, а не рабочие столы, как раньше. Но с совместимостью приложений в такой схеме все стало только хуже, и ряд приложений не работает на серверных ОС или не может быть запущено одновременно несколькими пользователями. А при большом количестве терминальных серверов установка и обновление приложений также становится проблемой. Также усложняются задачи, связанные с использованием печати, и в целом администрирование систем требует более высокой квалификации персонала.
Итак, какие плюсы и минусы виртуализация приложений при помощи терминального сервера:
- Унификация рабочих мест.
- Возможность удаленного доступа.
- Снижение затрат на обслуживание ПО.
- Доступ с устройств с неподдерживаемой производителем ПО архитектурой.
- Увеличение затрат на серверную инфраструктуру.
- Возрастает потребность в высококвалифицированном персонале.
- Появляются дополнительные затраты на лицензии.
- Возникает риск несовместимость некоторого ПО и невозможности запуска его в терминальном режиме.
- Требуется сетевой доступ.
Основные игроки рынка систем терминального доступа
Создатель технологии терминального доступа, компания Citrix, по-прежнему лидирует в области предоставлении приложений с помощью терминального сервера. Скорость работы возрастает, функциональность расширяется, интеграция с другими продуктами развивается. Доступ к приложениям возможен со всего спектра устройств через сети общего пользования с высоким уровнем безопасности. Помимо стандартного метода доставки приложений, XenApp также может доставлять приложения на клиентское рабочее место (streaming) и на терминальный сервер для упрощения развертывания программного обеспечения (streaming to server). На данный момент можно считать, что технология достигла некого пика в версии XenApp 6.5, и следующий шаг компании – объединить продукты XenApp и XenDesktop, и предоставить единый продукт для всех методов виртуализации ПО и рабочих мест.
Компания Microsoft постоянно расширяла функционал своего терминального сервера и на данный момент Remote Desktop Session Host обладает характеристиками, достаточными большинству компаний. Стоимость лицензий TSCAL намного ниже лицензий XenApp. Но продукт не имеет такого спектра поддерживаемых устройств, как XenApp, а также уступает в плане удобства удаленного доступа и поддерживаемых периферийных устройств на клиенте, в частности – принтеров.
Потоковая доставка приложений и запуск их в изолирующей среде
Вести разговор о потоковой доставке приложений, не рассказав о запуске приложений в изолирующей среде нет смысла, так эти технологии тесно связаны.
Sandbox («песочница») – это программная среда для изоляции приложений. Приложение в ряде случаев не знает, что оно запускается не на обычной операционной системе, а в «песочнице». Сам принцип изоляции приложений используется очень широко. Например, приложения Java запускаются на JVM, виртуальной машине Java, и за счет этого работают на устройствах различной архитектуры без изменения кода. Еще один пример - приложения для смартфонов и планшетов iOS/Android. За счет изоляции приложений в «песочнице» достигается две трудно совместимые цели: запуск широкого перечня ПО и стабильность работы устройства.
Таким образом, наличие «песочницы» - это обязательное условие виртуализации приложений. А методы доставки ПО в «песочницу» разнятся: можно устанавливать запускаемое ПО предварительно, а можно доставлять его по требованию. В первом случае требуется предварительно загрузить пакет с ПО, и сетевой доступ нужен в момент загрузки, во втором случае требуется сетевой доступ в момент запуска. Системы, интересующие нас, как правило, могут реализовывать оба подхода (см. Рис. 11):
Рис. 11 |
Методы распространения пакетов ПО различаются в деталях. Это протоколы HTTP/s, CIFS, системы распространения Active Directory или MS SCCM. Важно лишь то, что в какой-то момент времени требуется подключение по сети к точке распространения.
Плюсы и минус
К плюсам запуска ПО в изолирующей среде можно отнести лучшую совместимость программ друг с другом. Использование "песочницы" позволяет одновременно запустить два экземпляра программ, которые одновременно не работают в обычной операционной среде. Также крах одного из приложений, запущенного в "песочнице", не так влияет на другие приложения, как в классической схеме. Обновление ПО упрощается – администратору требуется лишь создать пакет с новой версией программы и распространить его на рабочие станции пользователей. Также использование "песочницы" позволяет отделить операционную систему от программного обеспечения, так как все обращения к диску и реестру перехватываются ПО "песочницы", и в привычном смысле программы не устанавливается. С другой стороны, изоляция приложения от ОС не позволяет использовать некоторое ПО таким методом, например, использующее свои драйверы, или тесно взаимодействующие с ОС. Также для распространения пакетов программного обеспечения требуется наличие сети передачи данных, и специально обученный персонал, который создает и обновляет эти пакеты. К персоналу повышенные требования по квалификации, так как процесс создания пакета ПО может оказаться очень трудоёмким в зависимости от разрядности операционной системы, наличия/отсутствия в ней определённых обновлений и т.п.
- Повышение стабильности ОС за счет изоляции ПО.
- Обновление ПО в одной точке, а не на каждом рабочем месте.
- Запуск несовместимых между собой приложений.
- Запуск ПО без фактической установки на ОС.
- Требуется сеть передачи данных – при предварительном кешировании или в момент запуска.
- Не каждое ПО можно виртуализовать.
- Повышенные требования к квалификации персонала, трудоемкий процесс подготовки пакетов.
Основные игроки рынка потоковой доставки приложений
Ведущим игроком рынка потоковой доставки приложений является компания Citrix, осознавшая необходимость виртуализации ПО на терминальных серверах для решения проблем совместимости и надежности. Citrix первой начала разработку решений по изоляции приложений, создав продукт под названием Installation Manager, обеспечивающий запись процесса установки и репликацию ПО между терминальными серверами. Первая реализация, Application Isolation Environment, обеспечивала лишь некую изоляцию, без механизмов создания, хранения и доставки пакетов. Но развитие этого направления, получившее название «Application Streaming», всеми этими механизмами уже обладало. Решение интегрировано в Citrix XenApp. Использование выглядит таким образом (см. Рис. 12):
- Создается профиль ПО на специальной машине с ПО Citrix Profiler.
- Профиль размещается на сетевой папке и тестируется.
- ПО публикуется на сервере XenApp в режиме Streamed to Client или Streamed to Server.
- Пользователь подключается к серверу XenApp, получает список приложений и осуществляет доступ. В случае, если пакет опубликован в режиме "Streamed to Client", профиль ПО передается на рабочую станцию и выполняется локально на ней, а в случае "Streamed to Server" - передается на терминальный сервер, а пользователь получает доступ по протоколу ICA, как и к локально установленному приложению на сервере.
Рис. 12 |
Сам пакет приложения представляет из себя папку со всеми папками и файлами, созданными в процессе инсталляции, и описание пакета, включая контрольную сумму всех файлов. Есть возможность упаковать приложение в формат VHD.
Вторым игроком на рынке потоковой доставки приложений можно назвать компанию Microsoft, создавшую решение под названием App-V, которое по архитектуре не сильно отличается от решения Citrix. Можно отметить возможность запуска приложений с общего хранилища профилей ПО, без передачи на сторону клиента. В версии 5.0 появился выделенный сервер управления, что позволяет не использовать System Center для публикации приложений App-V и в целом упрощает администрирование системой. Сам пакет приложения представляет из себя MSI файл, который может содержать в себе разные компоненты для запуска приложения, а может включать ссылки на нужные компоненты.
Запуск приложения может осуществляться как с рабочего стола, так и с использованием WebApps (см. Рис. 13):
Рис. 13 |
Третьим игроком на рынке потоковой доставки приложений можно назвать компанию VMWare, чьё решение называется ThinApp. В архитектуре этого решения подразумевается разделение среды хранения пакетов приложений на Источник (Source), Тестирование (UAT) и Продуктивную среду (Production). Источник содержит исходные файлы, дистрибутивы. Тестирование – максимально приближенная к пользовательской среда для проверки готовых пакетов. И продуктивная среда – доступный только для чтения файловый ресурс, на который обращаются пользователи.
Рассматриваются два метода выполнения приложений. Streaming execution – доступ пользователей на файловый ресурс для запуска приложений. Deployed execution – предварительное размещение пакетов на файловую систему клиентских устройств (а также на сменные носители).
Продукт не содержит инфраструктуры для управления доступом к пакетам, и предполагает распространения ПО совместно с Active Directory или продуктами VMWare. Однако при создании пакета можно указать, пользователи каких групп могут запускать пакет.
Сам пакет приложения представляет из себя исполняемый файл, который может запускаться стартовыми скриптами или из ярлыков.
Однозначным плюсом продукта можно признать ThinApp Factory. Это проект, который включает виртуальный Appliance, который позволяет не создавать и обновлять пакеты под распространенные приложения вручную, а скачивать их из доверенных источников.
Практические рекомендации
Удаленный доступ к ПО посредством терминального сервера до сих пор является самым дешевым методом централизованного предоставления ПО пользователям. На один терминальный сервер на практике вмещались от 50 до 100 пользователей в 32-битной архитектуре, а с появлением 64-битных процессоров это число значительно увеличилось. Тем не менее, использовать в продуктивной среде несколько физических серверов с огромным числом пользователей – это не самый лучший вариант. Если требуется решение для доступа нескольких сотен или тысяч пользователей, лучше внедрить систему виртуализации и применить несколько виртуальных терминальных серверов с загрузкой около 150-200 пользователей. Чем больше пользователей на одном сервере – тем больше вероятность того, что они запустят процессы, которые приведут к перегрузке сервера. К тому же, аппаратный сервер нельзя перенести на другое оборудование, не останавливая его работы. Таким образом, даже в классическом методе предоставления ПО, лучшей практикой будет совместить серверную виртуализацию с предоставлением ПО в терминальном режиме.
Оценивать нагрузку в терминальном режиме лучше всего при тестировании. Опубликовав планируемый набор приложений, нужно провести тестирование работы в нем, лучше с реально работающими пользователями, при невозможности – с использованием автоматических средств наподобие Login VSI. Оценив загрузку сервера по важным параметрам можно аппроксимировать на то количество пользователей, которое сможет поддерживать сервер, не уперевшись в ограничения сетевой или дисковой подсистемы.
Если тестирование провести невозможно – можно воспользоваться общедоступными данными по загрузке, но надежность такого метода невысока.
Виртуализация ПО, как правило, используется совместно с системой виртуализации конкретного вендора. Но тем не менее, стоит рассмотреть возможности, например, использования App-V в среде Citrix. Каждая система имеет свои преимущества - так, Citrix Streaming позволяет виртуализовать очень широкий спектр приложений, и предоставить их пользователю вместе с приложениями XenApp, и обладает широкими возможностями тонкой настройки. Но с некоторыми приложениями процесс упаковки становится очень сложным. Также, приложение кешируется на рабочую станцию. App-V имеет возможности интеграции с SCCM и позволяет размещать приложения через Active Directory, а также позволяет запускать ПО непосредственно с сетевого ресурса. ThinApp имеет предварительно собранные пакеты. Какую именно систему выбрать – зависит от приложений, а также от выбранной системы виртуализации и условий покупки.
Также, далеко не все приложения следует виртуализовать. Например, если приложение используется всеми пользователями, и ИТ-службы предоставляют пользователям виртуальные десктопы, то практичнее установить это приложение в образ операционной системы и обновлять вместе с обновлением образа. Если приложение загружает процессор и память, но не обладает интенсивной графической частью, его лучше предоставить через терминальный сервер (или Streamed to Server). Использовать стриминг приложения на рабочую станцию имеет смысл с графическими пакетами, которые использует небольшой процент пользователей, и использование которых в терминальном режиме сильно нагружает канал. Следует помнить, что приложение, запущенное в песочнице, потребляет больше ресурсов и дискового пространства.
При создании пакетов следует уделять особое внимание тестированию. Желательно создать группу для проверки приложения, проверить функционал приложения и получить обратную связь от пользователей. Например, время загрузки приложения может быть значительным, и пакет большого объема, например Microsoft Office, может иметь смысл разбить на несколько частей для ускорения запуска. Также следует учесть, что пользователь не сможет сохранять изменения в профиль ПО, и настройки должны храниться в профиле пользователя.
Также не следует обходить вниманием пропускную способность сетевого интерфейса сервера, содержащего сетевой ресурс с профилями. При запуске пакетов множеством пользователей на него ложится значительная нагрузка, которую желательно распараллелить и возможно распределить по разным точкам с помощью DFS. Оценить эту нагрузку заранее очень сложно, поэтому тестирование – ключ к успеху.
Виртуализация рабочих мест
На текущий момент, как и 20 лет назад, самый распространенный метод предоставления рабочих мест пользователям – это локально установленная операционная система.
В случае частного использования этот подход вряд ли будет вытеснен, тем более что за последние годы ситуация с обновлениями и безопасностью сильно улучшилась, но в корпоративных сетях содержание большого парка классических рабочих мест зачастую приводит к большим накладным расходам на администрирование, либо не подходит с точки зрения безопасности, сохранности данных и требованиям к удаленному доступу. Для реализации этих требований внедрялись сложные системы централизованного управления, защиты данных, резервного копирования, антивирусной защиты, комплексы административных мер, но рост числа угроз был значительнее. Поэтому ИТ-службы всегда стремились сделать так, чтобы от рабочего места зависело как можно меньше. Реализовать это стремление позволяет виртуализация рабочих мест, или виртуализация представлений, как её ещё называют.
Удаленный доступ к рабочим столам
Самым первым решением было предоставить пользователю рабочий стол терминального сервера. Этот подход позволяет избежать установки ПО локально и унести данные с локальных рабочих станций, но обладает рядом минусов, не позволявших полноценно заменить обычное рабочее место. Первый большой минус - доступ к рабочему столу сервера не исключает возможности записи рабочих данных локально, так как пользователь видит два рабочих стола (если не используются тонкие клиенты). Второй минус состоит в том, что большое число пользователей на одном сервере не способствует повышению стабильности, и даже один активно работающий пользователь (или запущенное им приложение) мог сделать работу других пользователей невыносимо медленной.
Различия между удаленным доступом к приложениям и целиком к рабочему столу с технической стороны минимальны. И в том и в другом случае пользователь осуществляет вход в систему и работает локально на сервере, запуская приложения. Отличия в том, что пользователю показывается не окно определенного приложения, а полноценное рабочее окружение – меню приложений, рабочий стол, ярлыки и прочее, к чему пользователь привык. Тем не менее, заменить обычное рабочее место такой рабочий стол не в состоянии, так как пользователи на сервере ограничены в правах. Ресурсы сервера делятся на всех пользователей, и скорость работы может очень сильно варьироваться. Сначала Citrix а потом Microsoft ввели системы справедливого распределения ресурсов по пользователям, с ними ситуация улучшилась. Тем не менее, терминальный сервер не может считаться полноценным рабочим столом, обеспечивающим персональную пользовательскую среду.
Плюсы и минусы удалённого доступа к рабочим столам
К плюсам удаленного рабочего стола на терминальном сервере следует отнести то, что сессия пользователя не завершается при отключении и при проблемах с подключением. Пользователь может открыть несколько приложений, начать в них работу, потом отключиться, подключиться из другого места и продолжать работу. Но это же может считаться и минусом – потребление ресурсов происходит и тогда, когда пользователи не работают. Конечно, можно завершить сессию принудительно или по таймауту, но несохраненные документы пропадут. В случае публикации ПО такая проблема не стоит, так как пользователь закрывает программу и сохраняет документ, а от рабочего стола чаще просто отключается, а не осуществляет выход из системы.
К минусам также можно отнести и незнакомый пользователю интерфейс серверной ОС, и требование сетевого подключения, и невозможность запуска тяжелых графических приложений.
- Технически простое решение;
- Наиболее экономичный способ предоставления рабочего стола;
- Пользовательские приложения выполняются в ЦОД, что надежнее локального десктопа;
- Позволяет надежно работать с рядом ПО, обращающимся к ресурсам ЦОД (клиенты СУБД);
- Возможность безопасного удаленного доступа;
- Доступ с разных устройств разной архитектуры;
- Отключенные пользователи потребляют ресурсы сервера;
- Требуется сетевое подключение;
- Невозможно дать пользователю права администратора для установки ПО;
- Нет возможности запускать графические приложения (или нужно 3D оборудование на сервере и у пользователя);
- Интерфейс серверной ОС, непривычный пользователю.
Основные игроки
Самый известный производитель программного обеспечения для удалённого доступа к рабочим столам – это Citrix и его продукт XenApp. Продукт очень развитый, имеющий самый широкий функционал и полный попыток обойти ограничения и минусы этого метода доступа. Например, пользователю можно показывать интерфейс Windows 7, а не Windows Server 2008 R2, а протокол ICA имеет множество возможностей, позволяющих приблизить удобство работы с тяжелыми графическими приложениями к удобству работы с такими приложениями локально. К тому же решение хорошо интегрируется с VDI решением XenDesktop и позволяет доставлять виртуализованные приложения как на сервер, так и напрямую на рабочую станцию – в одном продукте. Огромный плюс – возможность доступа с широкого спектра устройств – Citrix Reciever существует практически под каждое устройство.
Второй, менее функциональный вариант – это Microsoft RDSH. Он обладает функционалом, достаточным для большинства организаций, менее затратный, и обладает меньшим спектром клиентских устройств (фактически, поддерживаются только устройства с ОС от Microsoft).
Потоковая доставка образов дисков
Требование к отсутствию рабочих данных на локальном диске рабочей станции также решали с помощью бездисковых рабочих станций. В этом случае станции загружались и работали по локальной сети, что создавало на нее значительную нагрузку. Такие решения требовали высокопроизводительную сеть, а также емкую и высокопроизводительную дисковую подсистему на стороне сервера, так как диски монтировались из расчета "один файл жесткого диска на одну ОС". Но с развитием виртуализации данные методы обрели второе дыхание. Виртуализация оперирует виртуальными образами жестких дисков, динамически изменяющими размер. При применении технологий стриминга жесткого диска стало возможно использовать один «золотой» образ жесткого диска для загрузки рабочей станции, и записывать все изменения, сделанные в процессе работы, в небольшой диск различий, который может быть постоянным или может удаляться при перезагрузке ОС. Таким образом, вместо большого парка жестких дисков мы оперируем небольшим количеством образов. За счет этого экономится дисковое пространство на системе хранения.
Технически современные технологии стриминга диска напоминают то, что было ранее. При использовании виртуализации создается некое количество бездисковых машин (этот процесс можно автоматизировать), они загружаются через локальную сеть с использованием PXE или TFTP, подключаются к назначенному виртуальному диску и работают обычным образом через локальную сеть. Поскольку все компоненты размещаются в пределах ЦОД, достигается высокая степень надежности и скорости. Конечно, данный метод можно применять и для физических машин, но это потребует развитой сетевой топологии и образов дисков, специально рассчитанных на аппаратное обеспечение физической машины. Также технология применима не только к рабочим станциям, но и для большого количества однотипных серверов (например, серверов XenApp) (см. Рис. 14):
Рис. 14 |
Строго говоря, стриминг – скорее метод доставки диска, чем рабочего места, но возможность применения совместно с VDI и на физических машинах позволяет рассматривать его наравне с другими методами.
Плюсы и минусы потоковой доставки образов дисков
Использование технологий потоковой доставки наиболее оправдано для инфраструктуры виртуальных рабочих станций (VDI). При использовании технологии потоковой доставки для загрузки физических машин нужно либо иметь парк одинаковых рабочих станций, либо создавать большое количество стандартных образов. В первом случае можно добиться схожих результатов и стандартными методами управления образами (подготовка машины один раз и последующее её обновление средствами Microsoft). Во втором – теряется выгода за счет экономии дискового пространства и возникает большая нагрузка на обслуживание большого числа образов. Также загрузка и работа машин будет создавать большую нагрузку на клиентскую часть локальной сети.
Выгода от экономии дискового пространства теряется и в том случае, когда диски используются в соотношении «один к одному», для того, чтобы все изменения пользователей сохранялись на жестком диске.
В виртуальной среде все машины обладают однотипным виртуальным оборудованием, а трафик не покидает пределов высокопроизводительной сети ЦОД. Тем не менее, подобные системы требуют серверов с большим количеством оперативной памяти и с высокопроизводительными сетевыми интерфейсами.
- Безопасность – локальные машины не содержат данных;
- Экономия дискового пространства на СХД;
- Удобство подготовки образов;
- Упрощение администрирования виртуальных машин – не содержат дисков;
- Большая нагрузка на серверную подсистему, сеть и СХД;
- Нет возможности сохранять изменения при перезагрузке ИЛИ нет экономии пространства.
Основные игроки
Среди основных вендоров на рынке виртуализации подобные решения есть лишь у Citrix. Компания VMWare обладает похожим функционалом в своём продукте Horizon View (программное обеспечение Mirage 4.0, купленное в своё время вместе с компанией-разработчиком), но у него несколько другие принципы работы.
Citrix Provisioning Services – решение для потоковой доставки, которое поставляется вместе с некоторыми редакциями продуктов компании. Технически это программное обеспечение, устанавливаемое на Windows Server, которое содержит базу соответствий MAC-адресов и имен машин, и предоставляет каждой машине виртуальный жесткий диск – либо уникальный, либо собранный из золотого образа и диска различия. Также ПО Provisioning Services (PVS) следит за уникальностью ОС и за лицензиями и активациями. В архитектуре высокой доступности должно быть 2 и более сервера PVS, также это полезно для балансировки нагрузки. ПО позволяет назначить виртуальным машинам диск одной drag-and-drop операцией. Также есть функционал, облегчающий контроль за версионностью дисков.
Инфраструктура виртуальных десктопов (VDI)
После успешного становления серверной виртуализации возникла инициатива применить ставшие надежными гипервизоры для решения задач, связанных с десктопами. Так появилась концепция VDI – инфраструктуры виртуальных десктопов. Суть концепции в том, чтобы взять корпоративную ОС, и поместить ее в дата-центр, а пользователю предоставить доступ к ней. С точки зрения администрирования и безопасности идея выигрышная – ни данные, ни сама ОС не покидают пределы серверной. Но обеспечить при этом привычный пользователю уровень комфортной работы – задача очень непростая. А главный недостаток – требуется постоянный доступ пользователя к сети.
Плюсы и минусы VDI
Плюсы решения достаточно серьезные. Можно фактически целиком убрать составляющую администрирования рабочих мест. Вместо стандартного обновления десктопов раз в 4 года можно поставить тонкий клиент со сроком жизни 7-8 лет. Также, доступ к виртуальной машине может осуществляться отовсюду, где есть интернет, а скорость и надежность ее работы обеспечивается надежным и производительным серверным оборудованием. С точки зрения пользователя обеспечивается хорошая поддержка оборудования, и пользователь получает выделенные именно ему аппаратные ресурсы – другие пользователи не повлияют на комфорт его работы, как в случае использования терминального сервера. В целом, VDI – технология замечательная, но ее перспективы сильно переоценены. Каждый год все ожидают роста миграций с физических десктопов на VDI, но год за годом он оказывается достаточно скромным. Причины этого в том, что далеко не всем организациям нужна и подходит эта технология. Если нужны удаленные приложения – есть проверенные решения терминального доступа. Если нужно снизить расходы на обновление парка рабочих станция – то VDI оказывается дороже, чем обычные компьютеры. Некого выигрыша можно добиться, используя общий диск для виртуальных машин – за счет этого сильно снижается стоимость СХД. Но это достигается за счет невозможности предоставить пользователю именно свой уникальный десктоп, на который можно поставить программы. Не всем это подходит. Также не стоит забывать про сложность технологии. Внедрение VDI задействует практически все сферы корпоративной ИТ-инфраструктуры: сетевая инфраструктура, серверная инфраструктура, инфраструктура хранения, инфраструктура безопасности обслуживание ПО. Поэтому часто проекты внедрения VDI не достигают поставленной цели.
- Предоставление пользователю персонального рабочего места
- Удаленный доступ к выделенному персональному рабочему месту
- Все пользовательские данные не покидают пределы дата-центра
- Пользователь работает в изолированном окружении в собственной ОС
- Снижение расходов на администрирование рабочих мест и ПО
- Сложность реализации
- Высокие требования к персоналу
- Высокий уровень затрат на оборудование и лицензии.
- Требуется постоянный доступ к сети
Основные игроки
Самые известные продукты – XenDesktop от компании Citrix, Horizon View от компании VMWare. Есть также реализация от компании Microsoft, а также заслуживающее внимания решение от компании Quest.
XenDesktop можно считать технически самым развитым продуктом, давно присутствующим на рынке. У продукта есть преимущество интеграции с XenApp – можно совместно использовать часть инфраструктуры, предоставляя пользователям в одной точке и приложения, и контент, и рабочие столы. Доступ к рабочим столам может осуществляться с помощью собственных SSL шлюзов, которые использовались также и для XenApp. Также XenApp можно использовать для доставки приложений на рабочие столы, либо методом потоковой доставки, либо через терминальный доступ. Создавать виртуальные машины можно с помощью Machine Creation Service, или используя Citrix Provisioning Services. Каждый из двух методов позволяет экономить пространство на СХД и упрощает процесс обновления виртуальных рабочих станций. Также плюсом продукта является использование протокола ICA (или HDX) для доступа к рабочим столам – он позволяет получить наилучшую производительность и поддержку клиентского оборудования среди конкурентов. Еще один плюс – наличие клиентов под любые устройства любой архитектуры. Последние версии продукта имеют оптимизации для доступа с планшетов – интерфейс подстраивается под конечное устройство пользователя. Также, при использовании собственного гипервизора XenServer есть возможность использовать функцию IntelliCache для разгрузки подсистемы хранения с использованием кэша на локальном диске гипервизора.
Продукт VMWare View в недалёком прошлом обновился и теперь называется Horizon View, что должно подчеркнуть интеграцию с продуктами Horizon Suite. Один из продуктов в наборе – Horizon Mirage – позволяет разделять клиентские рабочие станции на 3 слоя: системный, приложений, и пользовательских данных, и доставлять эти слои пользователям по отдельности. Таким образом, этот продукт имеет некое сходство с Provisioning Service компании Citrix, так как может использоваться на физических машинах. Продукт также позволяет экономить дисковое пространство с помощью использования Linked Clones – виртуальных машин созданных из единого образа. Также в сам продукт VMWare View входит ThinApp, что позволяет интегрировать виртуализацию приложений с виртуализацией десктопов. VMVare View проще в установке по сравнению с Xen Desktop, но протокол PC over IP проигрывает протоколу ICA/HDX, а спектр клиентских устройств, позволяющих подключаться к рабочим столам, намного уже. Однако производительность PCoIP улучшается с каждой новой версией, а клиенты View уже есть под большое количество популярных платформ.
Виртуализация на стороне клиента
Поскольку пользователям периодически требуется работать вне пределов корпоративной сети, и иногда даже вне публичных сетей, то появилась идея поступать с корпоративным десктопом также, как с ПО – выгрузить его на клиентское рабочее место для работы в режиме Offline. С первого взгляда ничего сложного в этом нет, но при детальном рассмотрении этой концепции возникает большое число труднорешаемых задач, которые препятствуют совместить виртуализацию на стороне клиента и VDI и вообще применять ее в корпоративной среде.
Плюсы и минус
Виртуализация на стороне клиента очень полезна для разработчиков и инженеров, работающих в сфере IT, поскольку позволяет эмулировать нужные среды на своем рабочем месте. Для обычного пользователя данный режим имеет множество минусов. В случае XenClient – пользователь может лишиться работы ряда устройств, которые не поддерживаются Linux средой гипервизора. В случае использования Hyper-V – можно ожидать проблемы с производительностью, а также некоторые проблемы с работой обычных функций ОС. Основная проблема этих продуктов – теряется непрерывность использования рабочей станции при удаленном и локальном доступе.
Продукт VMWare выглядит на этом фоне чуть лучше – пользователь может выгрузить машину из ЦОД на свой ноутбук отправляясь в командировку, выбрав пункт Check-Out в клиенте VMWare View. Но процесс выгрузки занимает много времени и создает большую нагрузку на сеть.
- Работа с виртуальной машиной на локальном устройстве.
- Не требуется подключение к сети.
- Производительность не зависит от пропускной способности канала в Интернет.
- Поддержка локального оборудования на самом высоком уровне.
- Нет прозрачности в использовании для пользователя.
- Требуется значительное время для синхронизации с ЦОД или такой возможности нет.
- С точки зрения безопасности решение уступает удаленному доступу.
- Клиентское устройство должно быть производительным.
Основные игроки
Запускать виртуальные машины на стороне клиента позволяют множество продуктов. Так, у компании Citrix есть продукт XenClient – гипервизор первого типа. Он устанавливается на определенное количество моделей ноутбуков и рабочих станций известных производителей, как правило - с интегрированными графическими адаптерами. Полный список поддерживаемых моделей есть в HCL на сайте производителя. Поскольку гипервизор первого типа – производительность виртуальных машин не зависит от производительности гипервизора, однако есть ряд устройств, которые не будут работать в виртуальных машинах, например, считыватели карт памяти на шине PCI. Поддерживаемые устройства на шине USB тоже могут работать неожиданно. Виртуальные машины могут инсталлироваться на клиенте, а могут синхронизироваться с корпоративным сервером.
Самый известный продукт – VMWare Workstation, а также VMWare Player, позволяет запускать виртуальные машины на ОС Windows. Также существует VMWare View Local Mode и, в отличие от решений Citrix, позволяет выгружать виртуальные машины из существующей инфраструктуры виртуальных десктопов VMWare View.
Hyper-V от компании Microsoft входит в клиентские операционные системы Windows 8 и позволяет запускать и импортировать виртуальные машины – но существует ограничение в 2 Гб памяти на одну VM, что не позволяет запускать серверные ОС с серьезной загрузкой.
Также как бесплатную альтернативу VMWare Workstation можно отметить продукт VirtualBox от компании Oracle – популярный среди разработчиков своей простотой.
Практические советы
Все, что сказано про практику использования приложений на терминальном сервере – применимо и к публикации рабочего стола. Единственно, нужно больше уделить внимания профилю пользователей. При использовании терминального сервера для публикации приложений профиль максимально облегчается, папки перенаправляются на сетевые ресурсы. Частично эту практику можно применить и при публикации десктопов. Нужно помнить, что пользователю потребуется привычное рабочее окружение, персонализированное меню, рабочий стол – и следует оценить, какие папки следует перенаправить, а какие использовать в пределах терминального профиля. При большом числе пользователей важно все то, что пользователи привыкли помещать на рабочий стол, в папку «Мои документы», а также хранилище временных файлов. И если документы и рабочий стол можно перенаправить, то временные файлы лучше хранить на локальной для сервера сетевой подсистеме. Как обычно, нужно оценить нагрузку и специфику пользователей и ПО.
На практике Citrix XenApp редко используется для предоставления рабочего стола целиком. Большинство организаций, которым подходит данный метод, остановились на использовании Microsoft RDSH. К тому же исторически до Windows Server 2008 это был единственный режим работы продукта Microsoft. Использование продуктов Citrix для такого решения выглядело неоправданно дорогим. Улучшенный функционал печати успешно решался продуктами третьих фирм, а меньший спектр клиентских устройств компенсировался тем, что клиент RDSH был встроен в любую ОС от Microsoft, с которых и осуществлялась работа. На данный момент наличие устройств iOS и Android несколько портит картину – клиентской части RDSH от производителя под них не существует.
При внедрении VDI нужно четко представлять, нужно ли именно VDI, и нельзя ли обойтись более простыми и дешевыми решениями. Как правило, VDI имеет смыл внедрять при масштабах от одной тысячи рабочих мест. При уверенности, что именно VDI позволит решить задачи предприятия, нужно очень внимательно спроектировать решение, так как проектирование инфраструктуры VDI сильно отличается от проектирования других решений. Так, первым шагом нужно определить, какие десктопы нужны пользователям – индивидуальные или без возможности сохранять пользовательские данные на диск, или и то и другое в определенном соотношении. В первом случае – нужно быть готовым, что решение не будет экономным – дисковое пространство в ЦОД стоит дороже дискового пространства локальных ПК, и обновление ОС и ПО придется проводить индивидуально. Во втором случае – пространства требуется намного меньше, но пользовательские данные, сохраненные вне профиля пользователя, пропадут при первом обновлении мастер-диска.
После определения целей решения следует много внимания уделить расчетам. Нагрузка, создаваемая VDI, сильно отличается от обычной нагрузки на серверные инфраструктуры. Главным «бутылочным горлышком» чаще всего становится не мощность процессора и оперативная память, а количество дисковых операций ввода-вывода (IOPS), производимых виртуальными рабочими местами пользователей. Одна тысяча операционных систем даже при бездействии пользователя создает серьезную нагрузку на дисковую подсистему, причем характер этой нагрузки очень отличается от той, на которую рассчитаны корпоративные системы хранения. Нагрузка от VDI – это на 80% операции случайной записи и 20% - операции чтения. Причем нагрузка от разных пользователей также разнится. Пользователь-операционист может генерировать порядка 10 IOPS, обычный пользователь 15-20 IOPS, а разработчик или активный пользователь – 50 IOPS. Если помножить эти числа на 1000 выйдет очень серьезная нагрузка, для которой требуются СХД с большим числом дисков. По этой причине для VDI популярен RAID10 а не RAID5, так как он способен обеспечить куда больше число IOPS на запись. Высокие требования к СХД можно уменьшить, разделив нагрузку по слоям. Первый слой (Tier 1) характеризует высокая нагрузочная способность по IOPS, но малый объем. Его можно размещать на локальных дисках гипервизоров, на SSD дисках (локально или на СХД), или на устройствах вроде Fusion IO Drive. Существуют даже специальные решения для VDI, которые снимают высокую нагрузку с СХД. Второй слой (Tier 2) характеризуется большим объемом, но небольшими требованиями к IOPS и может размещаться на стандартных СХД. Разбиение по слоям может значительно удешевить решение VDI. Иногда бывает, что одна СХД с SSD и SAS дисками может заменить три СХД с 15К SAS дисками. Но SSD диски имеют высокую стоимость и небольшой ресурс, поэтому более верным с технической точки зрения выглядит решение по совмещению кеша записи в оперативной памяти и SSD дисков, что позволяет заменить частую запись маленьких блоков на более редкую запись больших блоков и увеличить срок жизни SSD (или применять более дешевые диски).
Рассчитывая систему хранения, следует учитывать моменты массовой загрузки виртуальных машин (boot storm) и массовые входы пользователей в систему(logon storm). И если нагрузку от boot storm можно уменьшить предварительной загрузкой виртуальных машин до начала работы пользователей, то logon storm создает интенсивную нагрузку в течение небольшого времени, как час-пик на дорогах. Во время logon storm число IOPS на запись больше примерно вдвое, а число IOPS на чтение – примерно раз в 10 больше, по сравнению со стандартной загрузкой. Учитывать logon storm просто необходимо, иначе время входа пользователей в систему может занимать часы. Уменьшить влияние logon storm можно уменьшением пользовательских профилей, перенаправлением папок, и меньшим числом запускаемых в момент старта сервисов и приложений.
Расчет хостов под гипервизоры следует производить исходя из планируемых ресурсов для виртуальных машин. Скажем, для Windows 7 может быть достаточно 2 Гб памяти, 200 МГц частоты процессора, и размещать не более чем 10 (максимум 15) машин на 1 ядро. Следует учесть выход из строя 1 сервера (или более). В этом случае остальные серверы должны быть способны принять нагрузку на себя. С учетом баланса всех этих параметров нужно выбрать оборудование – с одной стороны производительности должно быть достаточно, с другой – оно не должно простаивать. Например, часто нет смысла покупать 8-ядерные процессоры с частотой 3,2 ГГц так как количество виртуальных машин, которые выдержит сервер, не загрузит их полностью, и лучше выбрать сервер с 6-ядерными процессорами на частоте 2,4 ГГц.
При выборе сервера следует сверить планируемую нагрузку на дисковую и сетевую подсистему с той, которую могут выдержать серверы. Если она не укладывается – можно уменьшить степень консолидации машин на сервере со 100 машин до 80 и взять большее количество менее мощных серверов.
Если используются серверы Provisioning Services, следует отнестись внимательно к расчету их параметров. Так, оперативной памяти желательно иметь столько, чтобы хватило для размещения нескольких ходовых образов виртуальных машин целиком в ОЗУ. Также желательно использовать 10-гигабитные сетевые интерфейсы, так как нагрузка на сеть особенно в момент boot storm/logon storm становится очень серьезной. Количество серверов можно увеличивать для того чтобы распараллелить нагрузку. Следует избегать единой точки отказа, например TFTP сервер нужно балансировать с использованием специальных сетевых устройств, например Citrix NetScaler.
Проектируя комплексное решение, включающее виртуализацию серверов, приложений, терминальный доступ и VDI, можно взять самое лучшее из каждой технологии, и доставлять приложения пользователям самым подходящим способом. Например, можно совместить VDI с доставкой приложений на виртуальные рабочие места и выполнение в «песочнице». Лучшая практика такова: общие для всех пользователей приложения включать в образ операционной системы. Приложения, нужные некоторому проценту пользователей, доставлять на виртуальный десктоп методом стриминга или публикуя на терминальном сервере. При этом следует помнить, что более выгодный метод – именно публикация. Следует избегать большого числа стандартных образов – так как увеличивается число накладных расходов на обновление образа.
Виртуализации на стороне клиента пока что не стоит уделять много внимания, но ситуация в этой сфере должна измениться. На данный момент технологии еще не могут обеспечить незаметный пользователю рабочий стол, быстро и удобно доставляемый ему на локальную машину для оффлайн доступа.
Перспективы, взгляд в будущее
В принципе, в будущем ожидается дальнейшее развитие технологий виртуализации и перенос их в датацентры сервис-провайдеров.
В предоставлении десктопов и терминальных серверов не стоит ожидать чего-то нового, данная технология достигла своего пика. Виртуализация приложений скорее всего будет упрощена – появятся стандартные сборки приложений, доставка будет обеспечиваться через любые сети. VDI в таком виде, в котором существует сейчас, вряд ли ожидает рост популярности, но доля таких реализация будет медленно увеличиваться. Также компании Citrix и VMWare сделают новые шаги в разделении систем, приложений и данных в отдельные сущности, и будут реализованы сценарии, доставки каждой из них и для онлайн и для оффлайн доступа прозрачно для пользователей. Возможно, пользовательские данные или профили целиком, а также пользовательское ПО будут синхронизироваться методами, какими сейчас работают сервисы вроде Dropbox. С развитием HTML5 уйдет в прошлое зависимость от клиентской архитектуры - пользователи смогут осуществлять доступ ко всему с использованием браузеров. Также ожидается дальнейшее увеличение роли мобильных устройств, и появление продуктов, призванных решить проблемы с безопасностью использования оных для корпоративных нужд. Также со временем возможно размещение всей инфраструктуры вне ЦОД предприятия в дата-центрах копаний, специализирующихся на предоставлении инфраструктуры как сервис. Вероятно, это подойдет не всем предприятиям. Таким образом, в целом можно ожидать слияние различных видов виртуализации в единое цельное решение от одного вендора, предоставляющее широкие методы настройки под конкретные нужды (см. Рис. 15):
Рис. 15 |
Редакция Практики