Как мы адаптировали «1С: Предприятие» под работу в облаке VK Cloud

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


Результаты теста Гилева — одна из основных метрик производительности платформы «1С: Предприятие». На результаты теста обращают внимание как поставщики облачных услуг, так и клиенты, которым нужно решение с лучшими параметрами. 

Меня зовут Тимур Явкин, я архитектор облачных решений VK Cloud. Расскажу, как прошел тест Гилева наш облачный сервис «1С: Предприятие» версии 7.х в связке с СУБД MS SQL 2019 Enterprise, как мы повысили результаты с 11 до 32 баллов и к каким выводам пришли.

Задачи и методика тестирования


На нашей серверной платформе bare metal был развернут сервис «1С:ERP Управление предприятием», который мы использовали для собственных нужд. Со временем мы решили, что подобный сервис можно перенести в облако. Но на его функциональности мы решили не ограничиваться и развернули в публичном облаке «1С: Предприятие» в сочетании с СУБД MS SQL — такая связка позволяет компаниям сократить расходы на ПО, отказаться от самостоятельного администрирования и работать с любого рабочего места без привязки к физическому серверу.

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

В качестве основного метода проверки мы выбрали тест Гилева — синтетический тест, позволяющий оценить быстродействие платформы «1С: Предприятие», в том числе при использовании СУБД для хранения баз данных 1С. Он дает объективную оценку с понятной градацией: 10 — плохо, 15 — удовлетворительно, 35 — хорошо, 60 — отлично.

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

Первая фаза теста 


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

На первом этапе тестирования мы выбрали стоковую конфигурацию:

  • для «1С: Предприятие» — 4 vCPU с частотой 2,1 ГГц и 8 Гб оперативной памяти DDR4 с частотой 3330 МГц;
  • для СУБД MS SQL — 8 vCPU с частотой 2,1 ГГц и 16 Гб оперативной памяти DDR4 с частотой 3330 МГц.

При запуске теста Гилева без дополнительной настройки получили значение в 11–14 очков. Результат неудовлетворительный: такой производительности недостаточно для работы с базой предприятия на 250 сотрудников.

Чтобы улучшить результаты, мы попытались поднять тактовую частоту процессора, применив запинивание ядер к инстансу. Но результата это не дало: на пике оценка не превысила 14 очков.

После консультаций с отделом администрирования мы поняли, что между частотой процессора и производительностью инстанса есть прямая зависимость: математический расчет зависит от тактовой частоты и скорости обработки в единицу времени. Исходя из этого, мы решили увеличить частоту ядер процессора. На обслуживающем гипервизор сервере включили High-Freq-режим — это позволило поднять частоту до 3,7 ГГц. 

При анализе результатов мы также увидели, что в момент запроса к базе данных проседает в дисковая подсистема. Чтобы уйти от этого, мы вынесли раздел базы и логов в отдельные тома, разметили разделы как отдельные диски типа High-Iops и вынесли запись данных в каждый том по отдельности.

Внесение двух изменений — повышения частоты и разделения на отдельные тома — помогло поднять результаты теста до 28,9 очка по значениям таблицы теста Гилева.

Вторая фаза теста


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

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

По результатам замеров получили 30 очков по тесту Гилева — хороший результат.

Также мы обнаружили повышенный обмен данных с дисковой подсистемой. Решили увеличить IOPS (Input/Output Operations Per Second, частоту операций ввода/вывода). В итоге получили:

  • размер блока данных — 64 Кб;
  • минимальный размер раздела — 300 Гб;
  • рекомендуемый размер раздела — 500 Гб.

Использовали диски типа HighIOPS. После увеличения разделов результаты теста выросли до 32 очков.

Тест на количество инстансов


Изначально мы проводили тесты с базой на 250 сотрудников — один инстанс нашего облачного сервиса рассчитан именно на такую нагрузку, сопоставимую со средним размером компаний SMB-сегмента.

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

Чтобы оптимизировать конфигурацию под многопоточную параллельную нагрузку, мы применили технологию Multiqueue: она помогла увеличить производительность сетевого стека и исключить накопление запросов в очереди.

Тестирование проводили в несколько этапов с постепенным увеличением количества инстансов и замерами результатов на каждом этапе. 

Тест показал, что сервис «1С: Предприятие» может быть запущен на выделенном хосте (а также отдельном High-Freq-агрегате) в четырех экземплярах без просадки производительности под параллельной нагрузкой и с сохранением оценки в 32 очка. На пяти и более экземплярах производительность падает.

В результате мы определили оптимальную конфигурацию по количеству процессоров и оперативной памяти:

  • для «1С: Предприятие» — 8 vCPU с частотой 3,7 ГГц и 32 Гб оперативной памяти DDR4 с частотой 3330 МГц;
  • для СУБД MS SQL — 16 vCPU с частотой 3,7 ГГц и 64 Гб оперативной памяти DDR4 с частотой 3330 МГц.

Данный маппинг решили использовать для дальнейшей подготовки флейвора под наш облачный сервис. В сам фреймворк вошел виртуальный инстанс с развернутым приложением «1С: Предприятие» и развернутой СУБД MS SQL. Подготовленный флейвор с набором предустановленных настроек для «1С: Предприятие» и СУБД MS SQL значительно сокращает путь по тюнингу производительности: можно сразу получить настроенную среду в облаке с выделенным гипервизором.

Что в итоге


  1. Проверка нового сервиса по тесту Гилева помогла нам определить аппаратную конфигурацию, необходимую для стабильно высокой производительности даже при пиковых нагрузках.
  2. Производительность инстанса зависит от частоты процессора: повысив частоту, мы улучшили результаты теста почти в два раза.
  3. Размеры логических томов и тип дисков влияют на IOPS и производительность сервиса.
  4. Сервис можно запустить на выделенном хосте (а также отдельном High-Freq-агрегате) в четырех экземплярах без просадки производительности под параллельной нагрузкой и с сохранением оценки в 32 очка. Четырех инстансов достаточно компаниям, в которых до 1000 сотрудников. Но для получения этого результата необходимо запускать сервис только на выделенных гипервизорах или агрегатах.
Источник: https://habr.com/ru/company/vk/blog/681782/


Интересные статьи

Интересные статьи

«Бюрократия» — про обычные кадровые процессы. Мы в Skyeng всегда работали удалённо с основания. С ростом встала задача удобного поддержания HR-процессов, так как в ручном режиме поддерживать их ст...
Можно ли расти профессионально, не меняя работу. Думаю, я не одна такая, кто задавался этим вопросом.Всем привет! Меня зовут Настя и я frontend разработчик. Начинала в небольшой веб-студии, где приход...
Привет, Хабр! Меня зовут Анна Лунева, я руководитель направления по работе с брендом работодателя в ГК «Иннотех». Это группа компаний, которая занимается разработкой высоконагруженных фронтальных ...
Source Планировщик распределенных ресурсов (Distributed Resource Scheduler, DRS) — необходимый компонент любой виртуализированной среды, за исключением редких случаев с небольшой и нен...
В то время как коронавирус шагает по планете, на рынке ценных бумаг лидирует туалетная и целые страны закрывают на карантин, все больше компаний вынуждены переводить сотрудников на удаленную рабо...