Как рабочее место оторвалось от «железа»: история VDI через призму технологий, компаний и людей. Часть 2

Во второй части история подходит непосредственно к VDI. Первая часть закончилась на терминальных серверах середины 1990-х: приложения вернулись на сервер, но каждый пользователь по-прежнему делил одну операционную систему с остальными. Разберемся, почему терминальных серверов оказалось недостаточно, как VMware научила x86 делать то, для чего эта архитектура вообще не проектировалась. Также рассмотрим, как из экспериментов заказчиков вырос отдельный класс виртуальных рабочих мест и почему его судьбу в итоге определили не только гипервизоры, но и протоколы удаленного доступа, BYOD, облака и пандемия.

Сессия — это не компьютер

К середине 1990-х маятник качнулся обратно, к централизации. Приложения снова работали на сервере, пользователи подключались к ним по сети, а ИТ-службы вновь получили единый контроль над программами, обновлениями и данными. Но быстро выяснилось, что терминальные технологии решили лишь половину проблемы.

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

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

Рынок начал искать другой путь. Одним из самых интересных экспериментов стал Sun Ray, представленный Sun Microsystems в 1999 году. Это был ультратонкий клиент без жесткого диска, собственной операционной системы и локального хранилища — фактически экран, сетевой интерфейс и считыватель смарт-карт. Пользователь вставлял карту, получал свою рабочую сессию, затем мог перейти к другому терминалу и продолжить работу с того же места. Конечное устройство становилось максимально простым и практически не требовало обслуживания, а все вычисления переносились в центр обработки данных.

Любопытно, что здесь Sun фактически предвосхитила одну из ключевых идей будущих VDI и DaaS: рабочее место принадлежит не устройству, а пользователю. Сегодня возможность открыть одну и ту же корпоративную среду с ноутбука, тонкого клиента или домашнего компьютера кажется естественной. Sun Ray демонстрировала почти ту же модель — только технологическая база еще не позволяла сделать ее универсальной.

Однако рынок оказался к этой модели не готов. Серверы конца 1990-х еще не обеспечивали достаточной производительности для массовой консолидации рабочих мест, а жесткая привязка Sun Ray к экосистеме Solaris резко ограничивала круг потенциальных заказчиков. Вместо универсальной платформы получилось нишевое решение, хотя сама линейка просуществовала до 2014 года.

Направление развития стало очевидным: индустрии требовался не терминальный доступ к общей ОС, а изолированный виртуальный компьютер при централизованных вычислениях и управлении. Фактически рынок снова пришел к идее IBM начала 1970-х.

Оставалось перенести виртуальные машины с мейнфреймов на массовую архитектуру x86.

Виртуализация x86: невозможное стало стандартом

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

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

С x86 эта схема не работала. В 1999–2000 годах Джон Робин и Синтия Ирвин показали, что около двух десятков инструкций могли обращаться к системному состоянию из пользовательского режима, не вызывая прерывания и фактически оставаясь незаметными для гипервизора.

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

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

Поэтому в конце 1990-х вопрос звучал не «как ускорить виртуализацию x86», а «возможна ли она вообще».

Ответ пришел из Стэнфордского университета. Группа Мендела Розенблюма несколько лет исследовала виртуализацию архитектуры MIPS. Их проект Disco, представленный в 1997 году, показал, что несколько независимых операционных систем могут эффективно работать на одном физическом компьютере. Disco не поддерживал x86, но доказал главное: виртуализация снова имеет практический смысл.

В 1998 году команда основала VMware.

Розенблюм отвечал прежде всего за технологическую сторону проекта. Компанию возглавила Диана Грин, его супруга и инженер: до VMware она основала стартап VXtreme, который купила Microsoft, а до этого работала в Sybase, Tandem и Silicon Graphics. Университетская разработка довольно быстро превратилась в основу будущего рынка серверной виртуализации.

Первый продукт компании, VMware Workstation, вышел в мае 1999 года и продемонстрировал то, что еще недавно считалось невозможным: x86 все-таки поддается полноценной виртуализации. Инженеры VMware применили бинарную трансляцию: код гостевой системы просматривался блоками перед выполнением, проблемные инструкции заменялись безопасными эквивалентами, а остальное выполнялось напрямую на процессоре, практически без потери производительности.

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

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

Это изменило экономику эксплуатации. До широкого внедрения серверной виртуализации критически важные приложения нередко размещали по принципу «одно приложение — один физический сервер». Для таких систем загрузка CPU часто оставалась низкой — ориентировочно в диапазоне 5–15%, хотя конкретные показатели зависели от характера нагрузки. Виртуализация позволила консолидировать множество таких изолированных рабочих нагрузок на одном физическом узле, сохранив их логическую независимость и сократив расходы на оборудование, электропитание, охлаждение и сопровождение.

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

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

Открытая виртуализация: от Xen к KVM

Пока VMware превращала виртуализацию x86 в коммерческую платформу, альтернативный подход развивался в открытом сообществе. В 2003 году Компьютерная лаборатория Кембриджского университета выпустила Xen, построенный на паравиртуализации, и представила его на конференции SOSP. Вместо того чтобы скрывать гипервизор от гостевой системы, разработчики пошли от обратного: ОС знала, что работает в виртуальной среде, и вместо выполнения проблемных инструкций обращалась к гипервизору напрямую.

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

В конечном счете спор программных подходов во многом разрешили сами производители процессоров. Расширения Intel VT-x и AMD-V добавили в x86 аппаратную поддержку виртуализации и позволили гипервизору надежно перехватывать те операции, которые раньше требовали программных обходных решений или модификации гостевой ОС. Архитектура x86 наконец получила на уровне процессора возможности, которыми мейнфреймы IBM обладали еще с 1970-х. Бинарная трансляция и паравиртуализация из основного способа виртуализации превратились в частные решения для случаев, где аппаратной поддержки не было.

После этого виртуализация начала превращаться из специализированной технологии отдельных производителей в стандартный инфраструктурный слой. В 2006 году Ави Кивити начал разработку KVM, а 5 февраля 2007 года модуль вошел в ядро Linux 2.6.20. Вместо отдельной программной платформы гипервизором фактически становилась сама Linux. В июне 2008 года собственный гипервизор Hyper-V выпустила Microsoft.

Для истории VDI особенно интересно происхождение KVM. Компания Qumranet, в которой он появился, занималась не только серверной виртуализацией. Она разрабатывала Solid ICE — платформу, где рабочие столы Windows и Linux запускались в виртуальных машинах на сервере, а пользователи подключались к ним по протоколу SPICE. Один из будущих базовых гипервизоров открытой экосистемы создавался в компании, которая одновременно решала задачу виртуализации рабочих мест.

В сентябре 2008 года Red Hat приобрела Qumranet за $107 млн и получила сразу несколько ключевых технологий: KVM как основу виртуализации и наработки для удаленных рабочих столов, позволявшие конкурировать с XenDesktop и VMware View.

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

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

Рождение VDI: когда все элементы сложились вместе

К середине 2000-х серверная виртуализация уже стала привычной частью корпоративной инфраструктуры. VMware ESX использовали для консолидации серверов, сокращения затрат и повышения отказоустойчивости. Но вскоре заказчики начали применять платформу совсем не так, как задумывали ее создатели.

Вместо серверных приложений они стали запускать на ESX виртуальные машины с Windows XP. Пользователи подключались к ним по RDP напрямую — брокеров подключений еще не существовало, как и самого термина Virtual Desktop Infrastructure.

К 2005 году практика стала достаточно распространенной для того, чтобы ее заметили производители. На VMworld VMware показала прототип брокера подключений — промежуточного слоя, который избавлял пользователя от необходимости подключаться к конкретной виртуальной машине вручную. Система сама определяла, какой рабочий стол ему предоставить, и направляла соединение.

На той же конференции собственные брокеры демонстрировали и другие разработчики, в том числе британская Propero. Это был важный сдвиг: то, что начиналось как «обход» (запустить Windows в виртуальной машине и подключиться к ней по сети), постепенно обрастало средствами автоматизации и управления. Из набора отдельных технологий начинала складываться самостоятельная архитектура виртуальных рабочих мест.

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

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

В 2007 году VMware за $25 млн приобрела Propero, чтобы ускорить разработку своего брокера, и позже в том же году выпустила Virtual Desktop Manager (VDM), автоматизировавший подключение к виртуальным рабочим столам. К концу 2008 года продукт стал VMware View 3.0, а Virtual Desktop Infrastructure (VDI) оформился в самостоятельный класс технологий.

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

В том же 2008 году Citrix выпустила XenDesktop 2.0, годом ранее купив XenSource и получив собственную платформу виртуализации. Если раньше конкуренция шла вокруг терминальных серверов, то теперь вопрос звучал иначе: как дать каждому сотруднику полноценный персональный компьютер, не возвращаясь к тысячам физических ПК?

Ответом стала виртуальная машина.

К этому моменту индустрия прошла путь, начатый почти полвека назад. Тайм-шеринг научил делить дорогой компьютер между множеством пользователей. VM/370 дала каждому собственную виртуальную машину. Персональный компьютер вернул человеку полный контроль над рабочим местом, а терминальные серверы восстановили централизованное управление. VDI впервые объединила эти свойства в одной архитектуре.

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

Война протоколов: как VDI избавилась от «ощущения удаленности»

Основным средством подключения оставался RDP, появившийся в 1998 году вместе с Windows NT 4.0 Terminal Server Edition. Изначально протокол создавался именно для многопользовательской работы с приложениями, тогда как режим удаленного администрирования появился позднее, в Windows 2000.

RDP проектировался прежде всего для интерфейсов своего времени: текста, окон и относительно простой двухмерной графики. Для терминальной модели конца 1990-х этого было достаточно, но VDI постепенно предъявляла другие требования. При работе со сложной графикой, анимацией и видео ограничения становились заметны пользователю: изображение обновлялось рывками, курсор мог запаздывать, а динамический контент мог рассыпаться на артефакты.

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

Перелом произошел благодаря развитию протоколов удаленного доступа.

В ноябре 2009 года VMware представила View 4.0 с поддержкой PCoIP (PC-over-IP), разработанного компанией Teradici.

Подход PCoIP принципиально отличался от того, который за пятнадцать лет до этого выбрала Citrix. ICA создавался для эпохи медленных каналов и старался передавать как можно меньше данных. Вместо готового изображения сервер отправлял клиенту команды отрисовки: вывести строку, нарисовать прямоугольник, переместить область экрана. Само изображение собиралось уже на устройстве пользователя. Для модемных соединений середины 1990-х это было важным преимуществом, но у модели существовало ограничение: динамический контент, который плохо раскладывался на такие примитивы, передавался значительно хуже. Особенно заметно это становилось на видео и анимации.

PCoIP подошел к задаче с противоположной стороны. Экран отрисовывался на сервере, новый кадр сравнивался с предыдущим, а по сети передавались изменившиеся участки изображения. Протоколу уже не требовалось понимать, что именно происходит внутри приложения: текстовый редактор, презентация или видеоплеер в конечном счете превращались для него в набор меняющихся пикселей. Клиенту при таком подходе не нужно уметь ничего, кроме распаковки изображения. Teradici выпускала для этого отдельные чипы, превращавшие устройство в экран с сетевым разъемом.

Цена такого подхода заключалась в требованиях к сети. То, что было практически неприемлемо для модемных линий середины 1990-х, стало реалистичным к концу 2000-х, когда пропускная способность каналов заметно выросла. Поэтому переход от ICA к PCoIP отражал не только развитие протоколов удаленного доступа. За пятнадцать лет изменилась исходная инженерная задача: сеть перестала быть настолько дефицитным ресурсом, чтобы ради ее экономии приходилось воспроизводить интерфейс приложения на стороне клиента.

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

Практически одновременно Citrix развивала собственную платформу HDX (High Definition Experience). В отличие от PCoIP, она решала, что рисовать на сервере, а что отдать клиенту: видео могло декодироваться на устройстве пользователя, а сложная графика считалась на серверном GPU.

VMware и Citrix были не единственными участниками этой гонки. В 2009 году Red Hat открыла исходный код SPICE (Simple Protocol for Independent Computing Environments) — протокола, который компания получила вместе с Qumranet. В отличие от технологий, выросших из более ранних систем удаленного доступа, SPICE изначально проектировался именно для виртуальных рабочих мест. Он должен был передавать не только изображение, но и звук, ввод с клавиатуры и мыши, а также обеспечивать работу с периферией, превращая виртуальную машину на сервере в полноценное пользовательское окружение.

Свой ответ готовила и Microsoft. В 2010 году компания представила RemoteFX, вошедший год спустя в Service Pack 1 для Windows Server 2008 R2. Технология расширяла возможности RDP и позволяла использовать аппаратное ускорение серверной графики для удаленных рабочих столов. Это было особенно важно для интерфейсов и приложений, которым уже не хватало классической модели передачи относительно простой двухмерной графики.

На первый взгляд это была обычная конкуренция производителей. На деле компании соревновались в том, кто убедительнее создаст ощущение, что никакой виртуализации вообще нет. Эта гонка продолжается и сегодня: удаленный рабочий стол по-прежнему должен решить, что обработать на сервере, что — на клиенте, как экономно передать изображение и скрыть сетевую задержку.

Каждое поколение протоколов справлялось с этим лучше. Пороги чувствительности при этом зависят от задачи. По опыту эксплуатации VDI-сервиса Carnegie Mellon University, для большинства приложений приемлемой остается сквозная задержка до 150 мс, тогда как инженерным и конструкторским пакетам с насыщенной графикой нужны значения ниже 50 мс, чтобы работа ощущалась так же, как на локальной машине. VDI преодолела главный психологический барьер: технология стала достаточно незаметной, чтобы виртуальный рабочий стол воспринимался пользователем как полноценное рабочее место, а не как инструмент администратора.

Три волны, которые сделали VDI массовой

К концу 2000-х гипервизоры, брокеры, протоколы и серверы уже позволяли строить зрелые VDI, но технология оставалась преимущественно корпоративной нишей. Массовому распространению помогли уже не инженерные открытия, а изменения самой организации работы.

Первая волна — BYOD

В начале 2010-х распространилась концепция Bring Your Own Device (BYOD): сотрудники все чаще работали с собственных ноутбуков, планшетов и смартфонов. Контролировать конечные устройства становилось сложнее, тогда как требования к защите корпоративных данных росли.

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

Вторая волна — облачные платформы

В 2013 году Amazon представила WorkSpaces с виртуальными рабочими столами по подписке, в 2019-м Microsoft выпустила Windows Virtual Desktop — сервис, который позже переименуют в Azure Virtual Desktop. Организациям больше не требовалось самостоятельно покупать серверы, строить кластер и содержать команду его эксплуатации. VDI из капиталоемкого инфраструктурного проекта постепенно превращалась в облачный сервис, доступный компаниям меньшего масштаба.

Порог входа резко снизился.

Это был следующий уровень отвязки от «железа». Классическая VDI отделила рабочий стол пользователя от его физического ПК, а DaaS постепенно начала отделять саму VDI от оборудования конкретного дата-центра и команды, которая им управляет. Заказчику все меньше требовалось знать, на каких именно серверах работает его виртуальный десктоп: инфраструктура сама становилась услугой.

Третья волна — пандемия

До 2020 года удаленная работа во многих компаниях оставалась скорее исключением, чем стандартной практикой.

Весной 2020 года ситуация изменилась практически мгновенно.

До пандемии постоянно из дома работали около 6,5% американских сотрудников частного сектора. Уже к маю 2020 года, по данным Bureau of Labor Statistics, 35,4% работников — около 48,7 миллиона человек — выполняли работу из дома хотя бы раз за предыдущие четыре недели именно из-за пандемии. В Евросоюзе доля удаленной занятости за год выросла более чем вдвое, с 5,4% в 2019 году до 12,3% в 2020-м, притом что предыдущее десятилетие она держалась на уровне около 5%.

В России, по данным ВШЭ на основе обследования рабочей силы Росстата, дистанционная занятость выросла с 215 тысяч человек в 2019 году до 1,2 миллиона в среднем за 2020-й, а в пиковые месяцы достигала 4,5 миллиона. Российская статистика при этом считала удаленных работников строже западной: отдельный вопрос о дистанционной занятости Росстат ввел только в 2022 году, и при пересчете по обновленной методике охват 2020 года оценивают уже в 25–30%. Разница объясняется тем, что считают: 1,2 миллиона — это постоянно работавшие из дома, а 25–30% — все, кто переходил на удаленный режим хотя бы временно.

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

При этом VDI не стала универсальным ответом: компании одновременно использовали VPN, SaaS, корпоративные ноутбуки и браузерные приложения. Ее ниша проявилась четче: дать удаленный доступ к полноценной корпоративной среде, сохранив приложения и данные внутри контролируемой инфраструктуры.

Как это шло в России

Отечественные платформы виртуальных рабочих мест начали разрабатывать в 2010-е годы, задолго до пандемии, когда спроса на удаленную работу в нынешнем объеме еще не было.

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

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

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

Что на самом деле изменила VDI

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

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

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

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

Начало истории в первой части: тайм-шеринг, мейнфреймы IBM, советские ЕС ЭВМ, персональный компьютер и первые терминальные серверы.