Публичное облако и IaaS на opensourse в "10 кликов".

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

Сервис позволяющий конечному пользователю в зависимости от модели использования существенно снизить издержки на содержание IT инфраструктуры, а так же уменьшить сопутствующие издержки компании (электричество, персонал, сервисные контракты).

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

Начнем с того, что в классическом понимании сервис виртуализации рабочих столов у многих компаний разработчиков\поставщиков решений, не является “честными”, и господа поверьте, я сейчас не про обман или заговор, а про реализацию. Простыми словами возьмем довольно распространенные решения “VDI” решения:
- использование протокола RDP
- использование протокола VNC
- использование SPICE
Все эти протоколы позволяют, в той или иной форме, при правильной настройке , толстого или тонкого клиента реализовать, назовем это “классический VDI”, когда у вас оконечный пользователь подключается в среду отличную от классического ПК и операционной системы запущенной на нем.

Если, в случае с RDP – все понятно, протокол быстр и многогранен, позволяет подключаться как в терминальные сессии так и виртуальные машины по RDP протоколу, то VNC в данном случае имеет ограничения по количеству сессий на виртуальную машину, да и в производительности бывают проблемы, не говоря уже о возможных проблемах при работе с виртуальными средами. Отдельно стоит разработка компании RED HAT и Linux сообщества – протокол SPICE – взявший в себя многое от своих предшественников, и ставший на данный момент стандартом для многих, кто реализует “классический VDI” в своих инфраструктурах.

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

Что же нам необходимо для VDI?
- хост виртуализации (xen, xcp-ng, kvm и многие иные их форки и реализации)
- тонкий или толстый клиент, но для чистоты экономии конечно лучше все же тонкий.
- поддержка одного из трех протоколов подключения описанных выше для подключения к виртуальной машине.

Этот план справедлив, для инфраструктурных решений внутри компаний, но не дает необходимой экономии и гибкости системы.

Такую гибкость предлагает Amazone, Google, Azure и многие иные сервисы облачных провайдеров.
Что же включают в себя эта гибкость?
- мульти платформу подключения
- выбор операционных систем
- ресурсы и систему по требованию

В основном, если кратко это основные параметры которых не хватает “классической реализации VDI”.

Конечный пользователь должен получить гибкую и масштабируемую систему с простым подключением. И не платить за ресурсы которые не используются.
Многие меня вероятно сейчас хотят сжечь, ведь метод напильника и синей изоленты не отменял никто, особенно в linux сообществе, но ведь системой надо управлять и обслуживать ее, что при выше упомянутом технологическом стеке (жвачка и палки) не подходит. Да существуют реализации под управлением библиотеки ovirt, кто то ставит подпорки cloudstack и openstack, но это реализации скорее точечного применения, которые необходимо контролировать.

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

К нашему сожалению таких решений не много, но они есть:

- ravada vdi
- kvm-vdi (практически мертв)
- lsard vdi

Наиболее перспективным смотрится молодая разработка lsard VDI, но я бы не убирал со счетов и ravada vdi , за его простоту.

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

Стек предложенный нами покрывает посредством решений поставляемых из коробки 90% процентов сервисов посредством opensource решений, за исключением пользовательских операционных систем, вся инфраструктурная часть представлена opensource, облако и портал самообслуживания представлен xoa, xcp-ng и kvm закрывают часть виртуализации, брокеры реализуют поддержку VDI, хостинг и почтовые сервисы реализованы либо самописными оболочками на python, либо решениями точечной почты Sogo с коллективной работой.

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