Наверх

ECM на "бюджетных" облаках

Время чтения: 16 минут
13
ECM на

В этой статье будет рассмотрен эксперимент по размещению ECM системы на бюджетной облачной инфраструктуре. Целью эксперимента является выяснение максимального числа пользователей, которые смогут комфортно работать с ECM-системой, находящейся на недорогом облачном сервере, подходящем для компаний малого и среднего бизнеса, которые по той или иной причине не желают вкладывать средства в собственную ИТ-инфраструктуру.

Введение

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

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

Ограничения на эксперимент

Цена вопроса

Допустим, есть компания, у которой в ECM-системе одновременно работает до 50 человек, причем бюджет на развитие ИТ-инфраструктуры у этой компании ограничен суммой в 10 тыс. рублей в месяц. Поскольку число пользователей не большое, достаточно арендовать один виртуальный сервер, осталось выяснить, каких характеристик сервера будет достаточно.

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

  • VM1 (стоимость по конфигуратору провайдера 4730,6 руб./мес): 1 vCPU, ОЗУ 2 ГБ, ПЗУ 60 ГБ ПЗУ (RAID-10 SATA для операционной системы) + 100 ГБ (RAID-10 SAS для хранения файлов БД), 1 внешний IP-адрес, общий канал провайдера 100Мб/с, ОС Microsoft Windows Server 2008 R2 Standard;
  • VM2 (стоимость по конфигуратору провайдера 6602,6 руб./мес): 2 vCPU, ОЗУ 4 ГБ, ПЗУ 60 ГБ ПЗУ (RAID-10 SATA для операционной системы) + 100 ГБ (RAID-10 SAS для хранения файлов БД), 1 внешний IP-адрес, общий канал провайдера 100Мб/с, ОС Microsoft Windows Server 2008 R2 Standard;
  • VM3 (стоимость по конфигуратору провайдера 8474,6 руб./мес): 2 vCPU, ОЗУ 8 ГБ, ПЗУ 60 ГБ ПЗУ (RAID-10 SATA для операционной системы) + 100 ГБ (RAID-10 SAS для хранения файлов БД), 1 внешний IP-адрес, общий канал провайдера 100Мб/с, ОС Microsoft Windows Server 2008 R2 Standard;
  • VM4 (стоимость по конфигуратору провайдера 9842,6 руб./мес): 4 vCPU, ОЗУ 8 ГБ, ПЗУ 60 ГБ ПЗУ (RAID-10 SATA для операционной системы) + 100 ГБ (RAID-10 SAS для хранения файлов БД), 1 внешний IP-адрес, общий канал провайдера 100Мб/с, ОС Microsoft Windows Server 2008 R2 Standard.

Требования к быстродействию виртуального «железа»

Определим требования к допустимому уровню загруженности сервера, на котором функционируют службы ECM-системы:

Метрика

Допустимый уровень

% загруженности процессора

(% 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%

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

Профиль нагрузки

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

Профиль

Нагрузка, (одно событие в час)

Количество пользователей

От 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

170

108

Экспорт версии документа, 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

Выводы

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

Исходя из аналитических таблиц, представленных выше в разделе Аналитика, минимальная конфигурация виртуального сервера, которая подходит под предложенные условия – это VM2. Наиболее предпочтительной является конфигурация VM3, поскольку она имеет достаточный запас оперативной памяти (наиболее ценного ресурса для ECM-системы).

Также немаловажным ресурсом для ECM-систем является дисковая подсистема, а именно скорость ее работы. Если посмотреть на графики «Среднее время обращения к диску, сек», можно увидеть, что для диска, на котором находится операционная система, скоростных характеристик дисков SATA явно не достаточно, в то же время на диске с БД (SAS диски) не наблюдается каких-либо пороговых значений. Поэтому для рабочей системы желательно выбирать именно SAS диски или же SSD хранилища.

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

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

Оригинал материала опубликован на DIRECTUM Club:club.directum.ru/post/DIRECTUM-na-nedorogom-oblachnom-servere-Vozmozhno-li.aspx

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 13

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

Это потому, что вы выбрали совершенно неадекватных поставщиков услуг. Посмотрите хотя бы Digital Ocean - у них гораздо более приятное соотношение цены и того, что вы за нее получаете. Причем уровень сервиса вполне достойный.

Кроме того, я не понимаю, причем здесь вообще облака. VPS и Cloud - это не синонимы.

Андрей, спасибо за комментарий.

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

Отличие между облаками и VPS разумеется есть, но преимущественно в способе оказания услуги. Облака в отличие от VPS позволяют быстро масштабировать инфраструктуру, обладают отказоустойчивостью, балансировкой нагрузки и оплатой за использованные ресурсы. Мы тестировали именно услугу Cloud. В тексте статьи я не акцентировал на услуге, наверное зря. Спасибо, Андрей, что заметили этот момент, на будущее учту.

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

А это не тот же поставщик, который хостит сайт ECM-Journal, периодически отправляя его в даун? ;-)

По поводу рекламируемом Вами Digital Ocean ничего сказать не могу, нагрузочные тесты на их оборудовании мы не проводили.

Я его не рекламирую, а просто привожу пример, как одного из наиболее адекватных поставщиков современных VPS и иже с ними. На текущий момент на Digital Ocean активно переходят клиенты Amazon (пока не очень крупные, но это все равно показатель). 

Вы бы, кстати, назвали вашего поставщика, чтобы я начал понимать его роль на мировом рынке VPS/Cloud (и его уровень по сравнению с Amazon/DO/Linode). 

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

В любом случае спасибо автору за проделанную работу, это явно не пару часиков заняло! :) 

Вы бы, кстати, назвали вашего поставщика, чтобы я начал понимать его роль на мировом рынке VPS/Cloud (и его уровень по сравнению с Amazon/DO/Linode). 

Не хотелось бы рекламировать того или иного провайдера на ecm-journal, и целью не было проведения нагрузочных тестов какого-то определенного провайдера. Для эксперимента был взят один из наиболее известных провайдеров, который согласился предоставить ресурсы.

В любом случае спасибо автору за проделанную работу, это явно не пару часиков заняло! :) 

Спасибо за теплый комментарий, Вячеслав!

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

Поскольку это точно не Amazon, Google, Digital Ocean или Linode, то это либо Microsoft, либо вы очень сильно заблуждаетесь насчет термина "один из наиболее известных провайдеров".

Поскольку это точно не Amazon, Google, Digital Ocean или Linode, то это либо Microsoft, либо вы очень сильно заблуждаетесь насчет термина "один из наиболее известных провайдеров".

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

Один из наиболее известных отечественных провайдеров, предоставляющих недорогие облачные решения.

Т.е. на мировом рынке он никто и звать его никак. Понятно, спасибо за информацию.

Очень хорошо, что вы подняли эту тему. Но есть много вопросов и пожеланий.

Опубликовал пост-комментарий по поводу этом статьи: http://www.pcweek.ru/ecm/blog/ecm/5129.php

Ну и какой был смысл скрывать, что это ActiveCloud?

Цена вопроса

Какая-то у вас странная постановка вопроса...
Почему вы считаете, только стоимость "железа", но не стоимость ПО?

Вот ценник от того же ActiveCloud, на котором вы игрались (http://www.activecloud.ru/ru/services/rentsoft/).

Возьмем только SQL Server (цена аренды руб/мес):

SQL Server Standard Edition 1 User         400
SQL Server Standard Edition 1 CPU   9900

Все, мы уже вылетели вдвое за обозначенную границу:

бюджет на развитие ИТ-инфраструктуры у этой компании ограничен суммой в 10 тыс. рублей в месяц.

А ведь мы еще не закупали:

  • терминальный доступ (который стоит еще 150 руб/мес на человека)
  • офисный пакет (еще 450 руб/мес на человека)
  • собственно, саму ECM систему

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

Объясните пожалуйста, что именно вы пытались выяснить? О каком "бюджетном" решении идет речь?

Ну и полностью соглашусь с замечанием Андрея Подкина: вы тестировали производительность одного конкретного поставщика. Для другого поставщика все цифры будут абсолютно иными!!!

Зачем тогда пытаться выдать частное исследование (как я понимаю для какого-то конкретного клиента) за некий обобщенный результат? Кого вы хотите ввести в заблуждение и главное зачем?

Андрей Ардашев, а почему Вы стесняетесь говорить о поставщике услуги? Вы являетесь представителем определенного вендора, Вы протестировали работу СЭД (этот вендор правда чаще использует термин ECM) у конкретного провайдера. Ну так и рекомендуйте его заказчикам, зачем им каждый раз самостоятельно проводить нагрузочные тесты? Не многие заказчики захотят связываться с нагрузочным тестированием.

Чтобы прокомментировать, или зарегистрируйтесь