Сравнение производительности «1C» в инфраструктуре on-premise и в Microsoft Azure

За последнее время в нашей практике в COMPAREX мне пришлось столкнуться с большим количеством миграций инсталляций «1С:Предприятия» (далее «1C») в облако Microsoft Azure (Azure IaaS). Миграция представляет из себя непростой процесс, состоящий из различных этапов, таких как: подбор оптимальных конфигураций виртуальных машин, нагрузочное тестирование, оценка производительности и собственно сам перенос серверов «1С». Накопленный нами опыт наверняка может пригодиться тем, кто задумывается о миграции. Поэтому мы решили написать цикл статей, посвященных данной тематике. В качестве первой, вводной статьи решили описать методику получения данных для оценки производительности инфраструктуры «1С» и сравнить результаты в аналогичных по техническим характеристикам инфраструктуах — «наземной» (on-premise) и Microsoft Azure IaaS. Данный вопрос является одним из самых важных при планировании процесса миграции, и необходимо хорошее понимание самого процесса, так как именно здесь мы получаем один из главных аргументов для миграции «1С» в Azure – лучшую производительность виртуальных машин при аналогичных технических характеристиках.

Сама фирма «1C» для получения объективной интегральной оценки производительности своей платформы рекомендует использовать методику APDEX. (Термин «интегральная оценка» означает, что оценка учитывает все аспекты работы системы, все требования бизнес-логики системы и удовлетворенность работы пользователей.) Оценка состоит из следующих этапов:

1. Список ключевых операций.
2. Приоритизация ключевых операций.
3. Допустимое время выполнения для каждой операции.
4. Замер выполнения каждой ключевой операции.
5. Обработка данных замеров и получение оценки APDEX.

Немного подробнее о каждом пункте. Получение списка ключевых операций – не технический вопрос, здесь необходимо привлечь бизнес-подразделения организации, которые смогут указать, какие операции при недостаточной производительности приведут к бизнес-потерям. Также необходимо учитывать частоту использования данной операции (например, более 10-20 пользователей выполняют ее одновременно) и изучить историю обращений сотрудников с жалобами на производительность, если такие имелись.

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

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

В результате после трех этапов мы получаем, например, подобную таблицу:

После этого в течение довольно длительного времени (как минимум полный рабочий день) необходимо производить замеры по выбранным операциям. Таким образом мы получаем набор данных, характеризующий время отклика системы по каждой ключевой операции из фокусной группы при ее каждом выполнении. Процесс замера осуществляется с помощью встроенного механизма «1C» (например, конфигуратора) и довольно хорошо описан на официальном сайте фирмы «1C».

На основании собранных данных вычисляем и интерпретируем значения по шкале APDEX. Для расчета APDEX используется формула:

APDEX = (NS + NT / 2) / N,

где N – общее количество выполнений данной операции; NS – количество выполнений с временем отклика от 0 до Т (где Т – назначенное представителями бизнеса время выполнения операции); NT – количество выполнений с временем отклика от T до 4T. Интерпретацию результатов осуществляем по следующей шкале:

Обсудив методику, давайте рассмотрим практический кейс: необходимо получить сравнение производительности аналогичных по характеристикам «наземной» и облачной инфраструктур (on-premise и Microsoft Azure).

Ниже приведены результаты тестирования инфраструктуры со следующими параметрами: размер базы — 500 Гбайт и количество пользователей – около 300. В качестве фокусной группы – указанные выше ключевые операции, относящиеся к модулю ЗУП. Архитектура решения: 2 сервера – сервер «1C» и сервер СУБД.

Итак, согласно рекомендациям «1C» для заказчика, выберем следующие технические требования к серверам:

• Сервер «1C»: процессор с 16 ядрами, 96 Гбайт оперативной памяти и 200 Гбайт дисковой, ОС — Windows Server 2012 R2.
• Сервер СУБД (Microsoft SQL): 16 ядер, 96 Гбайт оперативной памяти и 1000 Гбайт дисковой, ОС — Windows Server 2012 R2.

В Azure существует деление виртуальных машин на разные классы исходя из требований к количеству ядер, оперативной памяти и цене. В данном сценарии оптимально использовать виртуальные машины серии D14v2 cо следующими характеристиками: процессор с 16 ядрами, 112 Гбайт оперативной памяти, временный диск на 800 Гбайт. Дополнительно необходимо также подключить диски данных к серверам «1C» и СУБД, так как по умолчанию у виртуальной машины заявлен размер временного диска, на котором не гарантируется сохранение данных (создание виртуальной сети оставляем за рамками данной статьи).

Само тестирование состояло из абсолютно аналогичных нагрузочных тестов на «наземную» инфраструктуру и на облачную (Azure IaaS). Нагрузка шла из подсети заказчика, в случае с облачными серверами использовалось VPN-подключение Site to Site, что позволяет эмулировать реальную ситуацию.

В результате мы получили следующие интерпретированные результаты:

Как видно, инфраструктура «1C» в Azure (Azure IaaS) показала однозначно лучший результат по производительности по сравнению с аналогичной «наземной» реализацией.

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

Итак, согласно указанным выше параметрам, серверы должны иметь следующие характеристики (по аналогии с Dv2-серией в Azure):

• Сервер «1C»: 2 процессора, 16 ядер 3,2 ГГц суммарно, 96 Гбайт оперативной памяти, 2 диска SSD по 200 Гбайт каждый (в отказоустойчивой конфигурации RAID 1), контроллер RAID, отказоустойчивые конфигурации блоков питания и вентиляторов охлаждения, система мониторинга, работы по инсталляции, поддержка на три года с SLA 24x7, в котором отводится 4 часа для реакции на сервисные события.
• Сервер SQL: 2 процессора, 16 ядер 3,2 ГГц суммарно, 96 Гайт оперативной памяти, 4 диска SSD по 400 Гбайт каждый (в отказоустойчивой конфигурации RAID 5), контроллер RAID, отказоустойчивые конфигурации блоков питания и вентиляторов охлаждения, система мониторинга, работы по инсталляции, поддержка на три года с соглашением SLA 24x7, отводящим 4 часа для реакции на сервисные события.

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

Андрей Петров — облачный архитектор компании COMPAREX, Andrey.Petrov@comparex.ru

Необходимо учитывать, что виртуальные машины D-серии второго поколения (Dv2) оптимизированы под работу с приложениями, требующими быстрых процессоров, большей производительности локального диска или большего количества памяти. Они предлагают оптимальную комбинацию вычислительных ресурсов для многих приложений корпоративного уровня. Данное поколение виртуальных машин имеет процессоры Intel Xeon® E5-2673 v3 (Haswell) с технологией Intel Turbo Boost Technology 2.0, работающие на частоте 2,4 ГГц. Данные технические характеристики в совокупности с SSD-дисками премиального уровня и оптимизированной работой виртуальной сети в Azure IaaS как раз и объясняют полученный в ходе тестирования выигрыш в производительности.

Ну что же, нам удалось описать подход к методике оценки производительности инфраструктур для развертывания «1C» и привести референсные конфигурации. Этих данных вполне достаточно, чтобы предельно точно в каждом конкретном случае ответить на вопрос целесообразности размещения «1C» в облаке и для понимания, насколько облако Microsoft позволяет оптимизировать затраты, при этом имея большую гибкость инфраструктуры для реагирования на потребности бизнеса как в сторону увеличения необходимых вычислительных ресурсов, так и наоборот.

Поводя итог, отметим, что мы с вами рассмотрели один из наиболее важных моментов, которые необходимо учитывать при планировании миграции «1C» в Microsoft Azure IaaS. Конечно, в реальных проектах возникает огромное количество других вопросов, которые мы хотим рассмотреть в дальнейшем, – от настройки системы резервного копирования до оптимального использования ресурсов с минимальными затратами. Поэтому очень просим вас указывать в комментариях наиболее актуальные вопросы, а мы постараемся ответить на них в следующих статьях.