DIRECTUM на недорогом облачном сервере. Возможно ли?
Информационные технологии подобно моде изменяются очень быстро. Вчерашние фавориты уже пылятся на свалке истории или используются, но крайне редко. Облачными технологиями уже никого не удивишь, некоторые активно используют их в бизнес-процессах, некоторые боятся оторвать от себя частичку ИТ-инфраструктуры, опасаясь за безопасность данных. Интернет-блоги хостинг-провайдеров завлекают минимальными стартовыми финансовыми инвестициями в ИТ-инфраструктуру, высокой надежностью, быстрой окупаемостью и т.д.В этой статье будет рассмотрен эксперимент произведенный компанией DIRECTUM по размещению одноименной системы на облачной инфраструктуре, любезно предоставленной компанией ActiveCloud.
Целью эксперимента является выявление максимального числа пользователей, которые смогут комфортно работать через толстый клиент с системой DIRECTUM, находящейся на недорогом облачном сервере, подходящем для компаний малого и среднего бизнеса, которые по той или иной причине не хотели бы вкладывать большие денежные средства в собственную ИТ-инфраструктуру.
Ограничения на эксперимент. Цена вопроса
Допустим, есть компания, у которой в системе документооборота одновременно работает до 50 человек, причем бюджет на развитие ИТ-инфраструктуры у этой компании ограничен суммой 10 000 рублей в месяц. Поскольку число пользователей не большое, достаточно арендовать один виртуальный сервер (в соответствии с рекомендациями к аппаратной части http://www.directum.ru/SystemTreb.pdf), осталось выяснить, каких характеристик сервера будет достаточно.Для нагрузочного эксперимента провайдером ActiveCloud были предоставлены виртуальные серверы со следующими характеристиками:
- VM1 (стоимость по конфигуратору 1 180 323.93 бел. руб./мес): 1 vCPU, ОЗУ 2 ГБ, ПЗУ 60 ГБ ПЗУ (RAID-10 SATA для операционной системы) + 100 ГБ (RAID-10 SAS для хранения файлов БД), 1 внешний IP-адрес, общий канал провайдера 100Мб/с;
- VM2 (стоимость по конфигуратору 1 649 883,93 бел. руб./мес): 2 vCPU, ОЗУ 4 ГБ, ПЗУ 60 ГБ ПЗУ (RAID-10 SATA для операционной системы) + 100 ГБ (RAID-10 SAS для хранения файлов БД), 1 внешний IP-адрес, общий канал провайдера 100Мб/с;
- VM3 (стоимость по конфигуратору 2 119 443,93 бел. руб./мес): 2 vCPU, ОЗУ 8 ГБ, ПЗУ 60 ГБ ПЗУ (RAID-10 SATA для операционной системы) + 100 ГБ (RAID-10 SAS для хранения файлов БД), 1 внешний IP-адрес, общий канал провайдера 100Мб/с;
- VM4 (стоимость по конфигуратору 2 462 583,93 бел. руб./мес): 4 vCPU, ОЗУ 8 ГБ, ПЗУ 60 ГБ ПЗУ (RAID-10 SATA для операционной системы) + 100 ГБ (RAID-10 SAS для хранения файлов БД), 1 внешний IP-адрес, общий канал провайдера 100Мб/с.
Требования к быстродействию виртуального «железа»
Системой DIRECTUM предъявляются определенные требования к допустимому уровню загруженности сервера, на котором функционируют службы системы DIRECTUM. Некоторые из них будут рассматриваться в рамках данной статьи:Метрика | Допустимый уровень |
---|---|
% загруженности процессора (% Processor Time) |
Не более 75% |
Длина очереди процессора (Processor Queue Length) |
Не более «число процессоров» * 2 |
Доступно МБ (Available Mbytes) |
Не менее 10% |
Обмен страниц/сек (Pages/sec) |
Не более 2500 |
Среднее время обращения к диску, сек (Avg. Disk sec/Transfer) |
Не более 0,015 |
Средняя длина очереди диска (Avg. Disk Queue Length) |
Не более 2 |
% активности диска (% Disk Time) |
Не более 50% |
Исходя из представленных выше требований, на нагружаемой инфраструктуре будут сниматься соответствующие счетчики производительности.
Профиль нагрузки
Профиль нагрузки представляет собой список основных пользовательских операций и частоту их выполнения. В данном эксперименте интенсивности выполнения операций соответствуют увеличенным в 2 раза максимальным значениям у клиентов компании DIRECTUM. Профиль нагрузки составлен таким образом, чтобы ввести виртуальную инфраструктуру в насыщение. Запланировано, что инфраструктура пробудет в насыщенном состоянии продолжительное время, это необходимо, для того, чтобы удостовериться в надежности сервиса. Либо сервис откажет, либо продолжит обрабатывать запросы.Профиль | Нагрузка, (одно событие в час) |
---|---|
Количество пользователей | От 10 до 500 с шагом 10 пользователей каждые 20 сек. |
Продолжительность нагрузки, ч. | 0,5 |
Документы | |
Изменение прав доступа на документ | 0,56 |
Создание документа | 0,9 |
Экспорт версии документа | 2,82 |
Импорт в версию документа | 1,68 |
Открытие карточки документа | 0,14 |
Задачи и задания | |
Изменение задач | 6,34 |
Создание задач | 1,72 |
Выполнение заданий | 2,96 |
Просмотр заданий | 2,84 |
Справочники | |
Изменение записи справочника | 7,1 |
Создание записи справочника | 1,96 |
Открытие карточки справочника | 4,3 |
Открытие справочника | 3,82 |
Проводник системы | |
Получение универсальной папки | 1,66 |
Получение папки компонент | 0,62 |
Получение папки задач | 0,88 |
Получение папки заданий | 4,34 |
Получение папки документов | 1,22 |
Поиск | |
Универсальный поиск | 0,12 |
Поиск документов | 2,46 |
Поиск папок | 0,22 |
Поиск заданий | 0,7 |
Поиск задач | 1,14 |
Вход в систему и выход из системы | |
Вход | 0,25 |
Выход | 0,25 |
Результаты эксперимента
Схематично экспериментальный стенд можно изобразить следующим образом:

Собранные данные были обработаны, но поскольку число точек измерения довольно большое (значения счетчиков производительности снимались ежесекундно), для удобства восприятия графиков ниже представлены линии тренда с линейной фильтрацией по 40 точкам. По оси абсцисс указано изменение числа пользователей в течение 1 часа, по оси ординат указано значение параметра в текущий момент времени.
1. % загруженности процессора (% Processor Time)

2. Длина очереди процессора (Processor Queue Length)

3. Доступно МБ (Available Mbytes)

4. Обмен страниц/сек (Pages/sec)

5. Среднее время обращения к диску, сек (Avg. Disk sec/Transfer)
5.1. Диск с ОС

5.2. Диск с БД

6. Средняя длина очереди диска (Avg. Disk Queue Length)

7. % активности диска (% Disk Time)

Аналитика
В результате анализа графиков, представленных выше, для каждого исследуемого параметра системы было определено число пользователей, при котором параметр не достигает порогового значения.
Параметр | VM1 | VM2 | VM3 | VM4 |
---|---|---|---|---|
% загруженности процессора (% Processor Time) |
55 | 90 | 90 | 170 |
Длина очереди процессора (Processor Queue Length) |
20 | 50 | 50 | 70 |
Доступно МБ (Available Mbytes) |
290 | 500 | Не достигло порога | Не достигло порога |
Обмен страниц/сек (Pages/sec) |
85 | 110 | 220 | 160 |
Среднее время обращения к диску, сек (Avg. Disk sec/Transfer) |
20 | 50 | 55 | 60 |
Средняя длина очереди диска (Avg. Disk Queue Length) |
55 | 110 | 215 | 170 |
% активности диска (% Disk Time) |
310 | Не достигло порога | Не достигло порога | 420 |
Число пользователей, при котором ни один параметр не достигает порогового значения. | 20 | 50 | 50 | 60 |
Скорость выполнения запросов в условиях максимальной загруженности виртуальных машин представлены в следующей таблице:
Тесты | VM1 | VM2 | VM3 | VM4 |
---|---|---|---|---|
Количество пользователей, которым удалось авторизоваться в системе | 51 | 118 | 190 | 190 |
Среднее время выполнения тестов | ||||
Изменение прав доступа на документ, 1 операция в сек | 45,6 | 172 | 206 | 87,8 |
Изменение записи справочника, 1 операция в сек | 75,1 | 184 | 175 | 89,7 |
Изменение задач, 1 операция в сек | 77,7 | 164 | 164 | 68,5 |
Создание документа, 1 операция в сек | 103 | 246 | 138 | 145 |
Создание записи справочника, 1 операция в сек | 80 | 199 | 184 | 118 |
Создание задач, 1 операция в сек | 95 | 211 | 149 | 144 |
Выполнение заданий, 1 операция в сек | 86,1 | 187 | 149 | 144 |
Экспорт версии документа, 1 операция в сек | 62,6 | 185 | 161 | 61,3 |
Получение универсальной папки, 1 операция в сек | 38,9 | 149 | 173 | 91,7 |
Получение папки компонент, 1 операция в сек | 37 | 190 | 206 | 36,5 |
Получение папки документов, 1 операция в сек | 44,4 | 188 | 191 | 67,3 |
Получение папки заданий, 1 операция в сек | 98,2 | 165 | 161 | 54,1 |
Получение папки задач, 1 операция в сек | 106 | 114 | 175 | 37,9 |
Импорт в версию документа, 1 операция в сек | 93,3 | 203 | 171 | 85,7 |
Вход в систему, 1 операция в сек | 2,65 | 28,4 | 33,1 | 30,1 |
Открытие карточки документа, 1 операция в сек | 0,11 | 202 | 216 | 16,5 |
Просмотр заданий, 1 операция в сек | 87,2 | 170 | 165 | 57,7 |
Открытие карточки справочника, 1 операция в сек | 76,9 | 174 | 189 | 87,2 |
Открытие справочника, 1 операция в сек | 79,1 | 181 | 178 | 148 |
Универсальный поиск, 1 операция в сек | 2,16 | 300 | 156 | 6,36 |
Поиск документов, 1 операция в сек | 113 | 187 | 163 | 83,7 |
Поиск папок, 1 операция в сек | 0,077 | 10,3 | 97,7 | 47,6 |
Поиск заданий, 1 операция в сек | 49,9 | 172 | 129 | 80 |
Поиск задач, 1 операция в сек | 30,2 | 158 | 208 | 65 |
Среднеарифметическая скорость выполнения операций, 1 операция в сек | 61,84 | 172,48 | 164,95 | 75,74 |
Выводы
Итак, можно ли разместить систему DIRECTUM на облачном сервере? Утвердительно да, но с условием выполнения определенных требований.Исходя из аналитических таблиц, представленных выше в разделе Аналитика, минимальная конфигурация виртуального сервера, которая подходит под предложенные условия – это VM2. Однако наиболее предпочтительной является конфигурация VM3, поскольку она имеет достаточный запас оперативной памяти (наиболее ценного ресурса для системы DIRECTUM и подобных систем).
Также немаловажным ресурсом для системы DIRECTUM является дисковая подсистема, а именно скорость ее работы. Если посмотреть на графики «Среднее время обращения к диску, сек», можно увидеть, что для диска, на котором находится операционная система, скоростных характеристик дисков SATA явно не достаточно, в то же время на диске с БД (SAS диски) не наблюдается каких-либо пороговых значений. Поэтому для рабочей системы желательно выбирать именно SAS диски или же SSD хранилища.
Что касается стоимости данного решения, то годового бюджета на виртуальный сервер с такими характеристиками хватит на физический сервер, удовлетворяющий всем необходимым требованиям, однако если учесть расходы на потребляемую сервером электроэнергию, обслуживающий персонал, кондиционирование помещения, в котором расположен сервер и т.д., то стоимость облачного сервера может быть предпочтительнее.
В данной статье были рассмотрены только нагрузочные характеристики облачных серверов, но не затрагивался вопрос защиты данных на облачном хостинге, в том числе защиты персональных данных. Этот вопрос, безусловно, интересен, и заслуживает отдельной статьи.
Андрей Ардашев для компании DIRECTUM