1.4 Функциональное описание модулей

Модульная архитектура ПО TIONIX позволяет адаптировать типовое решение под частные нужды Заказчика, развертывая рабочую платформу на предоставленной площадке по готовому сценарию, учитывающему рефересную архитектуру типовой облачной инфраструктуры (виртуального ЦОД).

Ниже приведено текстовое описание потребительских свойств, присущим каждому из модулей TIONIX в отдельности. Полный перечень модулей приведен в таблице (описание логической структуры, Раздел 1.2.2).

1.4.1 TIONIX.Client

Модуль TIONIX.Client необходим для работы всех остальных модулей TIONIX и должен быть установлен и настроен в первую очередь.

Функциональность модуля составляют:

  • REST API (доступен через токен);
  • консольные утилиты;
  • дополнения к интеграции с LDAP;
  • исправления к интеграция с Cinder.

В составе модуля содержится модифицированная реализация identity-драйвера для сервисов LDAP, называемая драйвером tnx_ldap. По умолчанию используется стандартный драйвер LDAP Keystone.

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

Модуль расширяет возможности консольной утилиты openstack дополнительными командами. Для получения списка доступных команд следует вызвать справку об использовании:

openstack tnx --help

Примечание.

Миграция виртуальной машины может быть выполнена при помощи консольной утилиты.

1.4.2 TIONIX.NodeСontrol

Модуль TIONIX.NodeСontrol предоставляет доступ к вычислительным узлам, используемым виртуальными машинами (ВМ) облачной инфраструктуры.

Модуль использует БД, реализующую модель данных OpenStack [1], с которой может взаимодействовать служба openstack-nova-compute (Compute Service), которая сосредоточена на таких функциях как:

  • обработка запросов на создание ВМ;
  • связь ВМ с внешним миром;
  • контроль за работоспособностью ВМ;
  • распределение нагрузки на физические машины и каналы связи;
  • детерминированная реакция на сбои.

Модуль TIONIX.NodeСontrol позволяет осуществлять:

– назначение расширенных атрибутов для вычислительного узла (инвентарный номер, локация);

– управление PXE-образами вычислительных узлов;

– мониторинг состояния вычислительных узлов в реальном времени и запуск автоматической эвакуации;

– создание и управление резервными узлами;

– действия над программно-определяемыми хранилищами (SDS) и блоками, в случае настроенной системы Ceph;

– сбор информации о блочных хранилищах Cinder и управление локальным общим хранилищем.

Кроме того, модуль обеспечивает взаимодействие с системой бесперебойного питания.

Модуль содержит консольные утилиты, интегрируемые в окружение управляющего узла:

  • tnx-node-control-api;
  • tnx-node-control-node-syncer;
  • tnx-node-control-node-tracker;
  • tnx-node-control-worker;
  • tnx-node-control-nova-listener;
  • tnx-node-control-drs-trigger;
  • tnx-node-control-storage-syncer.

1.4.3 TIONIX.Scheduler

С помощью планировщика задач – модуля TIONIX.Scheduler – другие модули TIONIX могут выполнять запуск определенных задач, в том числе – по расписанию. Непосредственно сами задачи выполняет модуль TIONIX.NodeControl. Задачи выстраиваются в очередь, имеют определенную периодичность и различные приоритеты запуска.

Планирование задач доступно для модулей:

Примечание.

Установка всех вышеперечисленных модулей позволяет раскрыть полный функционал модуля TIONIX.Scheduler.

1.4.4 TIONIX.Dashboard

Модуль TIONIX.Dashboard характеризуется как «приборная панель» [2], которая предоставляет стандартный функционал графических инструментов, имеющих доступ к:

  • проектам, организуемым в облаке;
  • функциям администрирования;
  • настройке параметров идентификации;
  • параметрам среды (ТИОНИКC).

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

Для доставки контента может использоваться протокол передачи гипертекста – HTTP, а также его защищенная реализация – HTTPS [3]. Протокол HTTPS поддерживается большинством популярных веб-браузеров.

С помощью веб-интерфейса может также осуществляться ограниченный доступ к VDI-машинам. Организовать веб-доступ возможно только при установленном и настроенном модуле TIONIX.VDIserver (Раздел 1.4.7.1).

1.4.5 TIONIX.Monitor

Модуль TIONIX.Monitor осуществляет предоставление статистики о работе виртуальных машин в виде фактических показателей (метрик):

  • процента использования центрального процессора;
  • процента использования оперативной памяти;
  • количества запросов на чтение/запись с диска;
  • количества запросов на прием/отправку пакетов (по сети).

Модуль позволяет осуществлять интеграцию с некоторыми внешними системами, например – c Zabbix [4].

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

  1. Производить восстановление работы виртуальных машин.
  2. Безопасно вывести из эксплуатации вычислительный узел (выключить питание).

Восстановление производится после поступления сигнала о недоступности или некорректности работы ВМ.

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

1.4.6 TIONIX.Agent

Модуль TIONIX.Agent устанавливается на вычислительные узлы и необходим для корректной работы следующего функционала:

  • включения и выключения режима динамического конфигурирования компонентов (DCC) на вычислительных узлах;
  • включения и выключения механизма SNMP на вычислительном узле;
  • включения и выключения доступа к гипервизору (по протоколу SSH).

1.4.7 TIONIX.VDI*

VDI – программное решение по организации инфраструктуры виртуальных рабочих столов, в рамках которой организовывается персональный удаленный Рабочий стол, закрепленный за конкретным пользователем инфраструктуры [5].

Виртуализация рабочих мест – концепция, в которой данные любого корпоративного сотрудника хранятся централизованно, а АРМ сотрудника состоит из виртуальной машины (вместо привычного ПК) и подключаемого к ней клиента. Эта концепция востребована для распределения бизнес-приложений, при этом на жестком диске отдельно взятого АРМ не хранятся бизнес-данные.

Администратор сервера создает виртуальное рабочее место с отдельным набором приложений, программ, документов и доступов и это всё хранится на сервере в (виртуальном) ЦОД. Подключение клиента VDI к серверу выполняется по сети, с применением различных аппаратных средств, от ПК до «тонкого клиента» (микрокомпьютера) [6].

Предусмотрено хранение (в облаке) типового виртуального рабочего стола, созданного на основе «золотого образа».

Допускается поочередное предоставление одного виртуального рабочего места нескольким пользователям (организация посменной работы и т.п.).

Функциональные возможности TIONIX VDI:

  • поддержка популярных пользовательских (гостевых) операционных систем;
  • поддержка удаленной работы через тонкие клиенты;
  • поддержка кэширования (на стороне клиента);
  • поддержка работы с несколькими дисплеями;
  • поддержка работы с USB-устройствами;
  • поддержка периферийных устройств (принтеры, сканеры);
  • интеграция с Microsoft Active Directory (AD/LDAP).

Благодаря AD/LDAP администратор может разворачивать программное обеспечение на множестве виртуальных узлов через групповые политики или посредством System Center Configuration Manager, устанавливать обновления ОС (Windows), прикладного и серверного ПО на всех компьютерах в сети, используя Службу обновления Windows Server [7].

1.4.7.1 VDIserver

VDI-машина – виртуальная машина, хранящаяся вместе с образом гостевой ОС в облаке. Она содержит среду Рабочего стола и некоторое количество учетных записей, позволяющих выполнять вход и осуществлять определенные операции в установленных и настроенных приложениях, с использованием графического интерфейса пользователя «тонкого клиента».

Модуль TIONIX.VDIserver предоставляет следующие способы доступа к VDI-машине:

  1. Веб-доступ, осуществляемый из браузера (TIONIX.Dashboard).
  2. Сетевой доступ, реализуемый посредством клиента VDI.

1.4.7.2 VDIclient

Для доступа к виртуальному рабочему столу (VDI-машине) в ПК или ТК устанавливается и запускается ПО клиента VDI, подробные сведения об использовании которого изложены в документе Руководство пользователя TIONIX VDI.

Модуль TIONIX.VDIclient содержит ПО клиента, является нелицензируемым компонентом. Клиент VDI взаимодействует с сервером VDI, функционирующим в облачной инфраструктуре и устанавливаемым в составе модуля TIONIX.VDIserver.

С помощью текстового или графического интерфейса VDI-клиента выполняются:

  • авторизация пользователя (с выданными реквизитами доступа или смарт-картой);
  • подключение к удаленному рабочему столу (по терминальному протоколу).

Если с пользователем сопоставлено несколько проектов, то перед подключением происходит запрос выбора (одного из возможных вариантов).

1.4.8 TIONIX.PointMeter

Модуль TIONIX.PointMeter предназначен для рассылки данных статистического учета и должен быть обязательно установлен в составе ОП TIONIX.

Модуль осуществляет сбор статистики об использовании вычислительных ресурсов за отчётный период, которая используется для оплаты использования лицензий TIONIX Cloud Platform и TIONIX VDI по сервисной модели (OPEX). Использование ПО оценивается на основании ежемесячных отчетов потребления.

Модуль привязывается к интерфейсу управления (TIONIX.Dashboard), и настраивается для передачи почтовых сообщений для автоматической рассылки отчетов (E-mail), в соответствии с настроенным расписанием рассылки.

Алгоритм сбора статистики (по умолчанию):

  1. Ежедневно, с периодичностью 1 час система получает данные о выделенных вычислительных ресурсах всех виртуальных машин в рамках проекта.
В подсчёте индекса использования ресурсов используется информация о времени жизни всех виртуальных машин внутри проекта (реализация OpenStack).
  1. В конце отчётного периода суммируются общие показатели использования ресурсов.

В рассчётах используются показатели по каждому проекту, за все время его существования и с учетом времени жизни всех ВМ внутри этого проекта.

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

  1. На основе собранной информации (использование vCPU, RAM) по всем виртуальным машинам за отчётный период, в разрезе программных продуктов (TVDC и TVDI), формируется файл отчёта.
Формирование отчёта происходит на основании утилизации (потребления) ресурсов, по проектам или доменам.

Для лицензии TVDC учитываются ресурсы, выделенные в рамках классических проектов Openstack.

Для лицензий TVDI используется информация о ресурсах, выделенные в рамках проектов с типами «VDI.Стандартный» и «VDI.Совместный».

Примечания.

Отчёт генерируется для всей облачной платформы, пользователь не может получить отчёт для конкретного проекта или домена.

Пользователь имеет возможность скачивания отчёта по выбранному периоду и получения файла отчёта по запросу.

Сноски

[1]https://docs.openstack.org/shade/latest/user/model.html
[2]https://www.openstack.org/software/releases/queens/components/horizon
[3]https://dic.academic.ru/dic.nsf/ruwiki/6259
[4]https://www.zabbix.com/ru/zabbix_agent
[5]https://www.vmware.com/ru/topics/glossary/content/virtual-desktop-infrastructure-vdi.html
[6]https://selectel.ru/blog/vdi-technology-review/
[7]https://ru.m.wikipedia.org/wiki/Active_Directory