VDI в современных реалиях: Часть 2 — как это работает

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

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

Для более простого понимания, схема работы очень условно похожа на работу по RDP — неважно откуда ты подключился, с телефона или с компа, рабочий стол везде один. Современные решения для VDI это по сути то же самое, но немного круче :)

Вступление

Мне очень нравится следующая картинка, потому что она очень «наглядно» (сарказм) демонстрирует работу решений по виртуализации рабочих станций:

DesktopVirtualization

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

В начале моего знакомства с решениями для построения VDI, я долго не мог понять, что они делают и зачем они вообще нужны, если казалось бы — поставил себе «вмварэ» с торента, клонировал пачку виртуалок, включил RDP, раздал пользователям айпишники и вперед…

В целом — да, но суть современных решений для виртуализации рабочих мест заключается в том, что создание 1000 виртуалок делается в несколько кликов и при этом тысяча виртуальных машин может занимать скажем 100 ГБ (да-да, 100 Гигабайт а не 100 Терабайт). Используются более продвинутые протоколы, которые позволяют комфортно работать без задержек на скорости мобильного интернета, а обновление этой тысячи виртуальных машин займет 20 минут. По сути, это оркестрация и разного рода плюшки, ни больше ни меньше.

Архитектура

На самом деле, за этим безобидным облачком на на первой картинке, скрывается примерно вот такая архитектура (оооочень упрощенно):

citrix-architecture

Это рисунок из документации по Citrix XenApp&Desktop но архитектура почти у всех решений такая же, только квадратики называются по другому.

Citrix делит все на 5 уровней, каждый квадратик на картинке это отдельный уровень (или слой), они подписаны. Это типа должно упростить понимание, но как по мне — это только усложняет, поэтому я делю все на три слоя, как я уже и говорил:

  1. Клиентский (пользовательский);
  2. Непонятная хрень (на работе я обычно применяю термин «компоненты инфраструктуры»);
  3. Ресурсный (железо и платформа виртуализации).

В качестве клиентов обычно выступают либо тонкие/зеро клиенты, мобильные устройства или старые писюки (в смысле PC). Клиентскую часть как правило стараются по максимуму обрезать, упростить и стандартизировать, т.к. по сути у клиентского устройства две задачи — быть стабильным и подключаться к удаленному рабочему столу посредством определенного протокола (ну, справедливости ради, это достаточно общий случай, как правило есть нюансы).

«Непонятная хрень» (я скоро перестану ее так называть, обещаю) это по сути самая важная часть VDI, это то что отличает VDI от набора виртуалок с RDP, здесь происходит вся магия.  Основные функции этого слоя (или уровня) это «брокерринг» (дословно переводится как «посредничество») подключений между клиентской частью и непосредственно самой виртуальной рабочей станцией а также — создание удаление и обновление этих виртуалок из единой концоли.

Ну, ресурсный уровень — это обычная горка серверных железяк, соединенных между собой проводами и сверху еще с установленной системой виртуализации. Это может быть VMware vSphere, Citrix XenServer, Hyper-V или даже нечто другое (я встречался только с этими тремя и только эти 3 поддерживает Citrix XenApp&Desktop). Железо может быть вообще любое, главное что бы поддерживало выбранную платформу и было хоть немного надежным.

Несколько примеров

Работает это примерно так (в случае с тонким/зеро клиентом):

  1. Пользователь ничего не подозревая включает вместо «процессорного блока» маленькую коробочку, к которой подключены монитор, клавиатура, мышка и сеть (сеть это вообще обязательно) понимает что никакой винды на самом деле там нет, но при этом коробочка спрашивает у него логин и пароль, которые пользователь не задумываясь водит (мало ли, вдруг сработает)
  2. Коробочка передает данные аутентификации на «компоненты инфраструктуры» (ну вот, перестал) и происходит авторизация пользователя
  3. Брокер подключений, который собственно и является одним из «компонентов инфраструктуры» смотрит на пользователя как на… и думает на какую машину его отправить (например на основе членства в группах), с другой стороны смотрит на все доступные машины и либо случайным образом выбирает любую свободную машину (в случае с pooled VMs) или берет личную машину пользователя (в случае с dedicated VM, если ему полагается по статусу)
  4. После того как нужная машина найдена, брокер отправляет на коробочку параметры подключения к самой виртуальной машине и коробочка выполняет подключение и сквозную авторизацию на виртуальной машине уже напрямую
  5. Пользователь, наконец-то получив свою винду (или линукс, если админ садист) одной рукой вытирает слезы радости, а другой запускает пасьянс «косынку» и начинает усердно работать
  6. Все время, пока пользователь работает, наша «непонятная хрень» (ну вот опять..) в этом не участвует (есть исключения в случае с удаленным подключением), клиентский девайс (коробочка) напрямую общается с виртуальной машиной, до тех пор, пока пользователю не вздумается переподключиться

Надеюсь что ничего не понятно, потому что я старался.

С другой стороны сидит админ, и легко и непринужденно этим хозяйством управляет. Допустим захотел он пропатчить KDE 3.5 под FreeBSD поставить апдейты на винду в сорок пятый раз за неделю и прям так что бы сразу на все 100500 машин:

  1. Админ устанавливает апдейты на одну «эталонную» виртуалку, которая зовется в узких кругах Golden Image (или Master Image, или «зоротой образ», как угодно)
  2. С помощью консоли VDI выполняет обновление всех пользовательских машин и легким движением руки перезагружает все стопитсот виртуалок (или ждет пока пользователи сами перезагрузят, что не случится никогда)
  3. После перезагрузки, все машины выравниваются к текущей версии «золотого образа» с уже установленными обновлениями и из-за этого у пользователей перестает работать пасьянс «косынка» и «один эс бухгалтерия» что практически означает смЭрть админу
  4. После нескольких десятков жалобных звонков от пользователей админ решает «досить!!», собственное спокойствие дороже чем какие-то обновления винды и решает одним кликом вернуть все взад
  5. После еще одной перезагрузки, пользователи получают предыдущее состояние виртуального десктопа с точностью до байта, правда уже без обновлений (зато все работает!)
  6. Админ спокоен, пользователи счастливы, хеппиэнд

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

НЕБОЛЬШОЙ ДИСКЛЕЙМЕР: У некоторых возможно начнет бомбить от стиля изложения в этой статье, но это ничего.

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

Upd1: Ссылка на продолжение

VDI в современных реалиях: Часть 2 — как это работает: 2 комментария

  1. злий бЄндера

    Как происходит процесс подтягивания данных пользователя (документы, шаблоны и прочая мутотень) к случайной ВМ? Сетевая шара, что-то ещё?…

    1. Доктор Добрянский Автор записи

      «Сетевая шара» и «что-то еще» )))
      Для этих целей у каждого вендора как правило есть свои плюшки типа Citrix Profile Manager или VMware Persona Management, ну и конечно же никто не отменял стандартные виндовые вещи типа Redirected Folders etc.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Не робот ли ты часом? * Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.