АССОЦИАЦИЯ СИБИРСКИХ И ДАЛЬНЕВОСТОЧНЫХ ГОРОДОВ
 

Секции

 
 
Информатизация органов местного самоуправления
Положение о секции
Правление
Новости
Материалы
К 25-летию секции
Муниципальная информатизация в АСДГ. История создания
О работе секции за 20 лет
Об информатизации в муниципальных образованиях АСДГ (2014-2017 гг.)
Разработки партнеров секции в сфере информационно - коммуникационных технологий в муниципальных образованиях (2014-2017 гг.)
Статьи экспертов в сфере применения информационно-коммуникационных технологий в муниципальном управлении (2014-2018 гг.)
Видеозапись конференции АСДГ от 5, 6 апреля 2018 г., Новосибирск
Видеозапись вебинара «Официальный сайт муниципалитета в рамках современного законодательства» от 28.11.2018
Земельно-имущественные отношения
По информационной политике
По местному самоуправлению
Жилищно-коммунальное хозяйство и строительство
Потребительский рынок и услуги
Городской пассажирский транспорт
Градоустройство
Юридическая секция
Муниципальное образование
Экономика и финансы города
Муниципальная молодежная политика
Организационная и кадровая работа органов местного самоуправления
Внешнеэкономическая и международная деятельность
Социально-трудовые отношения
По вопросам организации муниципальных выборов
По вопросам ГО,ЧС и ОПБ
Муниципальный спорт и физическая культура

Директор департамента
компании «РедСис Сибирь»
А.П. Семинихин

Эволюция клиентов

1. История развивается по спирали или смерь классической инфраструктуры

Идея освобождения пользователя в компьютерных системах от бремени оборудования (hardware) с предоставлением функционала программного обеспечения (software, ПО) в чистом виде услуги не нова. В разные времена она реализовывалась в том или ином объёме в зависимости от возможностей и акцентов.
Первоначально это реализовывалось в виде терминальных устройств больших вычислительных машин. Деловой функционал обеспечивался, но вот красочность и удобство интерфейса, к которым мы привыкли сейчас, напрочь отсутствовали. Да и форм-фактор терминальных устройств позволял говорить об освобождении пользователей от оборудования только на фоне больших машин, к которым они подключались. Но, однако, это было первое облако (Cloud), «машина = сеть».
Появление персональных компьютеров (ПК) и их дешевизна дали пользователям иллюзию автономности и принесли временную радость, связанную с личным сепаратизмом. Ввиду дороговизны и отсутствием желания делить радость обладания ПК с другими, сеть была заброшена. Стало «машина = ПК». Но не на долго.

Прошло время, основные метрики компьютерного мира, такие как вычисление (создание) информации, хранение её и передача, претерпели революционные изменения и то, чего раньше было мало и стоило очень дорого, теперь стало почти бесплатно и очень много. Вычислительные мощности вошли в парадоксальную стадию: для одного их слишком много (мощность подавляющего числа компьютеров избыточна для используемых на них приложений), а для всех – мало (например, постоянное усложнение вычислений, связанных с крипто валютами, требуют вовлечение всё большего числа единиц техники). Анонсы двухлетней давности флэш-памяти огромных ёмкостей и малой стоимость заставляют нас подозревать, что мы не пользуемся этим благом только потому, что пришлось бы распустить всю «шпиндельную» индустрию, закрыть гигантские производства со всеми вытекающими последствиями. Что же касается передачи информации, то мы уже привыкли к тому, что это неотъемлемый атрибут всего, что нас окружает: всё передаёт всё со скоростями, для которых необходимо передавать ещё что-то ещё кому-то. «Машина = снова сеть», но уже другая сеть, гиперконвергентная, т. е. «машина = весь мир».

Пользователи в полной мере насладились владением hardware со всеми его атрибутами: многогранная стоимость, совместимость, обслуживание, поддержка, обновление и т. д. и стали отчётливо желать избавиться от этого бремени. Сложность software уже такова, что даже специалисты не уверены в том, что там работает, для чего работает и где точно это работает. Однако мощностей хватает и ограничивать процессы всё более сложно и дорого. Пусть работает, но лучше бы, чтобы это непонятное было где-то, а пользователю доставался уже функционал программного обеспечения в чистом виде услуги. Благо, технологии это позволяют. Нам так кажется. История развивается по спирали.

Остальное доделает идея гиперконвергентности и иерархия SaaS-Cloud-Fog-IoT (ПО как услуга, облачный сервис, вычисляющий туман, Интернет вещей). Когда решительно всё на свете начинает вычислять, хранить и передавать, то классические ЦОДы с серверами, СХД, коммутаторами и периметрами выглядят нелепо и очень дорого. Классическая инфраструктура умирает, хотя мы из последних сил пытаемся её реанимировать. Многие утверждают, что «Cloud = ЦОД», но уже очевидно, что это простое упрямство особо упёртых реаниматологов.

ПО гиперконвергентной эпохи вынуждено быть гиперпереносимым и способным исполняться полностью и/или частично на всём, что подвернётся, выживать любым способом, чтобы предлагать себя как услугу наибольшему количеству клиентов. Там же, где оказываются услуги, обязательно должны быть клиенты, которые получают эти услуги? Вот оно, ключевое слово: «клиент», клиент-ориентированная инфраструктура.

2. Уникальное совпадение или как импортозамещение стало
передовыми технологиями

Обратим внимание на некоторый не систематизированный список требований, который касается ПО и может соответствовать миру, к которому мы идём:
- ПО работает не только инклюзивно относительно hardware, но и эксклюзивно.
- Масштабирование любым путём не позволяет рассматривать «что там внутри» «железа».
- Отдельные части, «подпрограммы», могут работать на разных и сильно удалённых агрегациях оборудования. Это «микросервисы».
- Переносимый транслируемый код. Java уже устарела. Ждём новостей.
- Переносимый компилируемый (открытый) код, предпочтительный с точки зрения контроля качества и безопасности.
- Разработка ПО сообществом, не объединённым в некоторую административную группу, но имеющим общую цель.
- Открытые стандарты во всём: от технологий организации труда до технологий производства ПО.

Теперь перефразируем каждый тезис с точки зрения соответствия некоторой другой цели:
- Ввиду того, что мощностей, производимого в России аппаратного обеспечения, может быть недостаточно, то необходимо, чтобы прикладное ПО было способно работать не внутри одного сервера, а над неоднородной группой серверов.
- Из-за возможной ресурсной ограниченности прикладное ПО должно масштабироваться вне зависимости от того, какого рода архитектуры и аппаратную единицу ему для этого предложили.
- Для наибольшей устойчивости и надёжности ПО должно быть способно исполняться как на локальных ресурсах, так и на доступных доверенных ресурсах внешних партнёров и операторов.
- Разнородность и развитие доступных аппаратных платформ требуют, чтобы ПО легко адаптировалось к новым ресурсам. Первоначально это может быть реализовано при помощи современных средств переноса, например, Java, но ввиду некоторого списка критических недостатков следует искать другие пути.
- Самый доступный путь переносить ПО – наличие прозрачного качественного кода, который легко проверить на безопасность и скомпилировать для новой аппаратной платформы.
- Объём ПО, которое должно быть произведено в короткие сроки, а также требование к открытости и качеству кода, требует привлечение всех, в том числе и независимых, ресурсов производства ПО.
- Все описанные выше характеристики ПО диктуют необходимость использовать при производстве только открытые промышленные стандарты, не имеющие двусмысленных толкований.

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

3. Технологическая реальность.

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

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

Разберёмся подробнее.
VDI подразумевает наличие следующих компонентов:
- Клиент, который мы по привычке будем называть ТК;
- Гипервизор виртуализации;
- Операционной системы (ОС), которая способна адекватно работать в среде виртуализованного рабочего места.

На данный момент, к всеобщему счастью, клиентом может быть практически любое вычисляющее устройство: ПК, классический ТК, телефон или микрокомпьютер на ARM/MIPS. Последние особенно интересны, так как малы по размерам, имеют также малую стоимость и энергопотребление, надёжны. Самое интересное, что их производительности, как показывает практика, хватает даже для того, чтобы воспроизводить видео в формате 4K без потери качества изображения и звука. Можно использовать, например, очень распространённое устройство Raspberry Pi.

Особые требования предъявляются к ПО для клиента, то есть к операционной системе, которую также можно обозначит термином «прошивка» (firmware). С одной стороны, функционально оно достаточно просто, ибо исполняет только соединение и обмен данными с виртуальным рабочим местом. С другой стороны, оно должно быть очень быстро и просто переносимо, чтобы без особых усилий осваивать новые типы клиентов. Лучше всего в исходном коде. А также использовать открытые стандарты для обеспечения максимальной совместимости с прикладным ПО, работающим внутри виртуальной машины, например, HTML 5. С третьей стороны, необходимо, чтобы firmware было дёшево. Только в таком случае реализуется идея клиента, стоимость которого стремиться к нулю. Не трудно понять, что этим требованиям удовлетворяю ОС семейства Linux.

Вот один из возможных сценариев нового мира. Такого клиента операторы связи могут выдавать абонентам бесплатно при покупке/аренде у оператора виртуального рабочего места и/или вовсе SaaS. Пользователь или абонент при этом может даже считать, что внутри клиента вообще нет никакого ПО, либо думать, что внутри клиента нет никакой логики и это просто носитель для ПО, как раньше CD-диски. Естественно, что к купленной услуге абонент может получить доступ откуда угодно и с любого адекватного клиента без ограничения. Очевидно, что места для стационарного ПК или даже ноутбука в этой схеме не остаётся. Рассуждать о мощности виртуального рабочего места также мало смысла, особенно в разрезе SaaS.

Гипервизоров нам известно шесть. Так как пятый (https://www.nomachine.com/) очень слабо распространён и не совсем гипервизор даже, а шестой, Virtuozzo от Parallels, нами слабо изучен (но можно посмотреть тут: https://habr.com/company/ibs/blog/322734/), то рассматривать будем только четыре:
- Microsoft HyperV (протокол RDP);
- VMWare Horizon (протокол Blast);
- Citrix XenDesktop (протокол HDX);
- Linux KVM (протокол Spice).

Признаём, что первые два наиболее ориентированы на пользователя. Однако и HyperV, и, казалось бы, независимый от Microsoft Horizon влекут за собой неизбежное погружение в пучину продуктов Microsoft и, как следствие, ношение крупных сумм денег в одну кассу. При этом размер сумм определяет кассир, спорить с которым бесполезно и небезопасно.

Citrix добился выдающих успехов в области виртуализации рабочих мест. В решение XenDesktop предлагается установить агента внутрь ОС, которую использует виртуальное рабочее мест, что позволяет работать в виртуальной среде практически как на отдельном физическом ПК, включая всевозможные мультимедиа приложения и игры. Достаточно клиента на ARM, чтобы смотреть видео 4K и полноценно выполнять офисные задачи. Однако список ОС, которые позволяют сделать корректную установку агента, ограничен: конечно, Windows и те Linux-ы, которые в качестве графической оболочки используют GNOME (возможны вариации). «Плюсом» также является и стоимость одного подключения: $182, но гипервизор при этом даётся бесплатно. Да, цена, конечно, в USD – это американцы. В то же время имеется сертификации ФСТЭК.

Взвесив все «за» и «против» можем сказать, что Citrix XenDesktop можно принять как временное решение в переходный период: и задаче уменьшения совокупной стоимости рабочего места соответствует, и критериям современной технологичности, которые, мы считаем, равны импортозамещению (если взять клиенты российского производства и в качестве ОС для виртуального рабочего места использовать «наш» Linux). Добавляет оптимизма наличие всевозможных гибридных вариантов реализации: например, с существующего ПК под Windows можно запускать приложения в виртуальной среде под Linux, но какую-то часть использовать и на самом ПК под Windows.

Однако, «…как временное решение в переходный период». Переходный к чему? Необходим выбор, который позволял бы взять какой-то коммерческий гипервизор, желательно из списка, либо свободно распространяемое решение с открытым кодом. А может быть и коммерческую реализацию на базе свободно распространяемого решения, как это часто делает, например, компания RedHat. Всех их объединяет одно: необходим открытый промышленный стандарт на протокол доставки виртуального рабочего места. Ни один из списка: RDP, Blast, HDX для этого не подходит. Это проприета́рные протоколы, принадлежащие их изобретателям и влекущие за собой определённые нюансы в использовании и существенные отчисления правообладателям.

А как же Spice и KVM? Многие отечественные производители ОС утверждают, что у них реализована VDI на базе этой пары. Трудно возразить на это утверждение, если воспринимать его бинарно: выбрать между «да – есть VDI» или «нет – VDI не реализован». Но если широко рассматривать функционал VDI на Spice и KVM для реального использования, то мгновенно выявляется незаконченность реализации. Особенно в отношении мультимедиа функционала. Изображение получается статичное и сильно «подвисает» при интенсивном изменении (например, перемещении/переключении окон), уже не говоря о полноценном видео. Звук при этом стремиться отстать от картинки, либо пропасть вообще. Возможно, и такое решение применимо в каких-то урезанных терминальных приложениях, где окно на весь экран, оно единственное и требуется только заполнять и/или читать какие-либо информационные поля. Однако, с точки зрения современных технологий, применить к такой схеме термина VDI никак невозможно.

Как же быть? Получается, что выбора нет: только XenDesktop. На данный момент – да, но выбор может появиться в ближайшем будущем. Фактически функционально решение Citrix отличается наличием агента, о котором упоминалось ранее. Если доработать пару Spice и KVM таким образом, чтобы также использовать соответствующего агента для ОС рабочего места, то, возможно, функционал этой пары стал бы более приемлем. Видится даже более законченная схема: отечественный разработчик ОС, который уже производит Linux-подобную ОС для многих аппаратных платформ (x86, ARM, в перспективе – Эльбрус, и т. д.), разработал бы агента (Агент) для своих ОС, реализующего цепочку: ТК (ARM, поддержка Агента со стороны клиента) -> Spice и KVM (поддержка Агента по доставке от клиента к ОС виртуального рабочего места) -> виртуальная машина рабочего места с интегрированным Агентом. Это был бы революционно новый шаг, реально реализующий VDI и освобождающий пользователя от бремени оборудования на рабочем месте. С учетом Linux-подобности ОС, можно с уверенность сказать, что Агент подойдёт (или потребует для этого минимальных доработок) для других ОС отечественного производства, т. е. будет возможен выбор и/или простая адаптация уже работающих систем. В целом общий объём положительных последствий представить и описать невозможно.

Нужен разработчик! Пока ещё есть время…