На осенней конференции INFOSTART TECH EVENT 2025 ведущий 1С:Эксперт компании «ИТ-Экспертиза» Алёна Генералова и руководитель направления 1С «Тантор Лабс» Александр Симонов представили совместный доклад «Как мы провели этим летом нагрузочный тест на 30 тысяч пользователей». Выступление вызвало живой интерес, поэтому мы решили подробно рассказать про закулисье этого нагрузочного тестирования (НТ). И в этой статье рассмотрим особенности подготовки стенда для тестирования: как ускорить подготовку теста и настроить шаблон для 180 виртуальных машин (ВМ) с помощью Ansible. И откуда взялось именно 180 ВМ.
В начале 2025 года фирма «1С» анонсировала успешно проведенное нагрузочное тестирование на 30 тысяч пользователей в информационной системе 1С:ERP. Мы решили не просто повторить это НТ, а пойти дальше – проверить работу не только ERP-системы, но и всего контура отечественного аппаратного и системного обеспечения в максимально приближенных к реальности условиях.
В совместном испытании участвовали компании АНО «НЦК ИСУ», «ИТ-Экспертиза», «Группа Астра» и «YADRO». В качестве аппаратной платформы была использована машина баз данных (МБД) Tantor XData 2Y, в качестве системного ПО – ОС Astra Linux и СУБД Tantor.
* * *
Изначально на сборку стенда и проведение теста отводился месяц, но из-за увлеченности процессом сроки были превышены. Впрочем, это позволило детально проработать ключевые этапы, и теперь мы можем поделиться подробностями. Далее расскажем, как все автоматизировать, чтобы ускорить проведение теста, как настроить кластер 1С и СУБД Tantor для успешного прохождения испытаний.
Начнем с технических характеристик оборудования и задач по подготовке стенда. Серверы приложений было решено оставить физическими, а для генерации нагрузки развернули по 10 ВМ на каждом хосте.
Исходя из нашего прошлого опыта организовали 18 хостов, на которых совокупно запускалось 180 ВМ. Почему так? Рассказываем!
Во-первых, на каждом физическом сервере Linux можно запустить только один агент нагрузочного тестирования. Попытка запустить второй агент в другой RDP-сессии не будет успешной, так уже существует активный первый.
Во-вторых, существуют ограничения оконного менеджера графической оболочки операционной системы. Экспериментально было установлено, что для Astra Linux предельное количество виртуальных рабочих мест (ВРМ) на одной машине не должно превышать 250-300. Таким образом, выбрали оптимальные 180 – такое количество находится в установленных рамках и гарантирует стабильную работу. К слову, если быть совсем уж точным – эти 180 ВМ обеспечивали нам 167 ВРМ на одном сервере.
Для развертывания 180 виртуальных машин использовали автоматизированный подход, так как ручное создание заняло бы слишком много времени. Для этого наши специалисты подготовили шаблон, в котором за основу взяли специализированный образ Astra Linux с предустановленным Cloud-init. Cloud-init – это известный многоплатформенный пакет, который используется для инициализации ВМ при их первом запуске. Он позволяет автоматически настраивать виртуальные машины, применяя конфигурацию, переданную через метаданные. Также для массового развертывания ВМ были задействованы Ansible и API-системы виртуализации.
Затем настроили этот шаблон таким образом, чтобы при последующем развертывании сэкономить время и ничего не переделывать. И первым шагом адаптировали графический интерфейс FLY в Astra Linux, что позволяло увеличить максимальное количество одновременно открытых окон и предотвратить появление ошибки о достигнутом лимите. Пример реализации на слайде ниже.
Для удобства приводим эти параметры дополнительно текстом:
1) В файле /usr/lib/systemd/system/fly-dm.service в секции [Service] прописать параметр: LimitNPROC=infinity
2) Отключить сообщение о количестве открытых окон, увеличив значение параметра MaxWindowsNum: MaxWindowsNum=2000
в файлах:
/usr/share/fly-wm/theme/default.themerc
/home/user_name/.fly/theme/default.themerc
/home/user_name/.fly/theme/current.themerc где user_name заменить на имя пользователя, у которого появляется окно
Следующим шагом установили в наш шаблон необходимое программное обеспечение:
- 1C
- xrdp – для удаленного подключения к системе
- систему мониторинга – для контроля состояния машин и оперативного выявления возможных сбоев.
Важно понимать, что при выполнении нагрузочных тестов не используется онлайн-парсер ТЖ (технологический журнал 1С), так как это создает избыточную нагрузку на оборудование, что недопустимо во время испытаний. Весь анализ проблем и логов выполнялся уже после завершения теста.
Так как согласование дополнительного ПО в контуре заказчика часто сопряжено со сложностями, для сбора необходимых метрик применялись стандартные утилиты Linux – atop и iostat. Они позволяют извлекать артефакты, анализировать данные, строить графики и формировать наглядные отчеты. Кроме того, задействовали бенчмарки fio и SysBench, которые помогают убедиться в корректном состоянии стенда и оборудования перед началом теста. Этот этап критически важен, чтобы в рамках последующего тестирования не столкнуться с несоответствием оборудования заявленным характеристикам.
Сюрприз подкрался незаметно: даже самая тщательная подготовка не гарантирует, что все пойдет по плану. В нашем случае, при попытке открыть 1С выяснилось, что памяти для этой операции недостаточно. К счастью, эта ошибка уже зафиксирована на багборде 1С и для нее выработан порядок обхода.
Далее, для работы теста необходимы агенты тестирования. В данном кейсе применили следующий способ: как только запускается сессия RDP, сразу же, автоматически, в режиме агента открывается 1С. Для реализации этого сценария нужно разместить файл с расширением .desktop в папку автозагрузки пользователя. Подробности по настройкам – на слайде ниже.
Обратите внимание на командную строку для запуска 1С. В ней указаны ключи, которые активируют режим агента, отключают использование аппаратных лицензий и стартовых сообщений. Это критически важно, потому что без использования данных ключей при одновременном запуске 180 агентов на каждом будет появляться диалоговое окно с запросом на использование аппаратных лицензий, что максимально затормозит процесс и вообще не позволит провести НТ.
Пример файла «.desktop»:
[Desktop Entry]
Name=1C Application
Exec=/opt/1cv8/common/1cestart /IBConnectionString "Srvr='tst-1c';Ref=‘test';" /N "agent" /C TCA /UseHwLicenses- /DisableStartupMessages
Type=Application
Terminal=false
После подготовки шаблона потребовалось развернуть его 180 раз. Для этого использовали все тот же Ansible. Почему остановили свой выбор на Ansible? Это – простое и доступное решение, обладающее несколькими ключевыми свойствами. Для нас это три ключевых причины:
Во-первых, идемпотентность. Это позволяет многократно запускать плейбук (playbook, сценарий) без риска внесения нежелательных изменений. Например, если развертывание на одном из хостов завершилось ошибкой, повторный запуск плейбука исправит именно эту проблему, не затрагивая другие хосты, где развертывание прошло успешно.
Во-вторых, безагентная модель работы – Ansible не требует установки дополнительного ПО на хосты, необходим только Python. Либо можно использовать модуль RAW, который самостоятельно установит интерпретатор.
И, наконец, доступность и простота использования. Ansible присутствует во всех стандартных репозиториях российских ОС. Подготовка также не вызывает сложностей: плейбуки – это простые YAML-файлы, которые можно найти в Интернете или написать с помощью искусственного интеллекта.
В результате проведенных работ процесс создания и настройки всех виртуальных машин был полностью автоматизирован, что позволило сократить время подготовки тестового стенда до одного часа.
В следующей статье расскажем про запуск теста и сбор артефактов, а также поговорим про архитектуру кластера 1С и настройку свойств баз данных.
Ссылка на доклад на конференции: https://event.infostart.ru/2025/agenda/2443778/
Вступайте в нашу телеграмм-группу Инфостарт
