Где брать ресурсы
Для нагрузочного тестирования ИТ-партнер может использовать свое или выделенное заказчиком оборудование. Однако бывает, что свободных ресурсов нет у обеих сторон, их недостаточно или они не соответствуют требованиям. В таком случае можно уменьшить масштаб тестирования и упростить сценарии. Но, как правило, это негативно сказывается на точности результатов. Есть другой вариант — арендовать облачные серверы.
Классический подход — аренда серверов на все время испытаний. Главный недостаток — значительную часть времени они будут простаивать. В проектах по нагрузочному тестированию основная часть работ проводится либо в рамках подготовки сценариев и их отладки, либо уже после испытаний, когда команда анализирует результаты.
Тогда почему бы не сэкономить и не арендовать мощности только на время выполнения теста, который занимает не так много времени относительно всего проекта? Этим вопросом озадачился Дмитрий Овчаренко, технический архитектор департамента 1С «КОРУС Консалтинг».
Рассмотрим ключевые требования к решению.
- Использование облачных ресурсов только во время выполнения сценариев.
- Максимальная автоматизация создания инфраструктуры для нагрузочного тестирования и сбора результатов (выгрузка отчетов и логов, сохранение скриншотов дашбордов).
- Возможность масштабирования и переиспользования. Решение должно быть достаточно гибким, чтобы запускать тесты в разных условиях (версия платформы 1С, количество серверов в кластере, версия СУБД Postgres и ее параметры).
Решение
Проект состоит из двух частей. Первая управляет развертыванием серверов в облаке с помощью Terraform, вторая — установкой и настройкой ПО с помощью Ansible.
Сетевая топология проекта «КОРУС Консалтинг».
В качестве провайдера выбран Selectel. Уже был фиксированный сервер лицензирования 1С (lic) и файловый сервер (Shared folder).
Для тестирования производительности каждой новой системы выделяют отдельный проект в облаке (обозначено синим). Подсеть проекта соединяется с подсетью пула выделенных машин. Это дает возможность использовать клиентские и серверные лицензии 1С, а также разворачивать испытываемые базы из бэкапов. Каждый раз после завершения теста все ресурсы облачного проекта удаляются.
Разберем вкратце основные компоненты инфраструктуры.
- DB — сервер с базой данных.
- app1c — кластер серверов 1С. Проект поддерживает различные конфигурации кластера. Например, с одним или двумя центральными серверами, основным и рабочим и т. д.
- RDP-01, RDP-02, RDP-NN — терминальные серверы, которые выполняют роль агентов. На них запускаются виртуальные рабочие места.
- Bastion host — сервер на Linuх c доступом в интернет по белому (статическому) IP. На нем подняты служебные компоненты для контура, сбора метрик и анализа, а также различные утилиты.
- Control Host — сервер на Windows для запуска испытаний через тест-центр. Для удобства сервер тоже получает белый IP.
- Global router — глобальный роутер, программно-аппаратное средство облака, которое позволяет связывать разные сегменты и сети в единое пространство. Благодаря ему контур нагрузочного тестирования может получать лицензии 1С, которые развернуты на выделенных серверах Selectel.
- lic — сервер лицензирования 1С. Он подключается к кластеру машин 1С, чтобы выдавать лицензии.
- Shared folder — файловый сервер, где размещаются резервные копии тестируемых баз.
Этапы работы
- Создаем инфраструктуру. Вводим параметры контура в конфигурационный файл. Запускаем Terraform, который разворачивает все серверы, затем — Ansible Playbook, который устанавливает на них необходимое ПО: 1С для соответствующего кластера серверов, Postgres на сервер СУБД и другое.
- С помощью Ansible Playbook загружаем базу данных в подготовленную инфраструктуру.
Второй этап может занять несколько часов, если база большая. При тестировании 1С, рассчитанной на 1 000 пользователей, требуется около 16 RDP. Чтобы сэкономить, мы поднимаем терминальные серверы только на следующих этапах. - Выполняем terraform apply для RDP-серверов и с помощью Ansible Playbook устанавливаем на них тонкие клиенты. Затем на каждом RDP запускаем базу в режиме агента тестирования.
- Интерактивно открываем базу в режиме «1C: Предприятие», настраиваем и запускаем сценарий.
- После окончания теста собираем со всех хостов логи, скриншоты дашбордов, формируем отчеты и сохраняем прочую информацию, которая позволит проанализировать результаты. Этот процесс также автоматизирован — после выполнения Ansible Playbook все нужные данные сохраняются локально в виде архива.
- Запускаем terraform destroy. Команда удаляет все ресурсы из облачного проекта.
- Анализируем результаты
Ключевые параметры
Вкратце рассмотрим параметры, которым уделили внимание при конфигурировании решения. Проведение нагрузочного тестирования на 100, 1 000 и 10 000 пользователей системы отличается необходимой мощностью оборудования. В конфигурационный файл вынесены следующие характеристики терминальных серверов:
- количество RDP,
- объем ОЗУ,
- количество vCPU,
- размер диска.
На данный момент решение поддерживает единственный инстанс Postgres. Среди настроек, которыми можно управлять:
- количество vCPU,
- объем ОЗУ и дисков,
- типы дисков,
- версия Postgres Pro.
В кластере серверов тоже много параметров. Наиболее важные:
- общее количество серверов,
- количество vCPU,
- объем ОЗУ,
- размер диска,
- количество центральных серверов.
Что еще указываем в файле конфигурации решения?
- Настройки, которые позволяют включить в кластер «внешний» сервер лицензирования 1С.
- Версию платформы 1C. Если подходящий дистрибутив не будет найден локально, скрипт скачает и установит все необходимое с официального сайта вендора.
- Путь к dt-файлу, из которого загружается база для проведения испытаний.
Система онлайн-мониторинга
Система построена на Grafana. Дашборды подготовлены заранее, а Ansible отвечает за то, чтобы они были скопированы в правильный каталог. Все виртуальные машины отслеживают следующие показатели: CPU, ОЗУ, I/O, сеть.
Дополнительно на сервере Postgres мониторятся:
- shared buffers,
- cache hit ratio,
- блокировки и транзакции,
- объемы обрабатываемых данных операциями SELECT, INSERT UPDATE, DELETE.
- память rphost, ragent, rmngr суммарно/по сеансам;
- сессии, лицензии;
- текущее время вызова (и время вызова СУБД);
- ожидания на управляемых блокировках;
- доступная производительность;
- количество исключений.
На скриншоте выше видно, что нагрузка распределилась очень плавно — это хороший показатель для «чистового» нагрузочного тестирования. Каждая точка — это короткий серверный вызов, который произошел только в одно окно сбора метрик. Более длительные вызовы относятся к определенной категории пользователей, которые выполняли сложные отчеты.
Дашборд выше — это показатели рабочего процесса в консоли серверов 1С.
Панель с длительностью управляемых блокировок берет данные из ClickHouse. Плагин Filebeat (установлен на каждом сервере в кластере 1С) разбирает технологический журнал 1С и отправляет его в Logstash. Последний не только агрегирует эти данные, но и заменяет имена таблиц по специальному словарю, чтобы они отображались в терминах 1С, а не СУБД. После этих манипуляций данные отправляются на хранение в ClickHouse.
Grafana запрашивает из таблицы ClickHouse события блокировок TLOCK с ненулевой длительностью и наличием WaitConnections, затем суммирует их по области (Region) и выводит результат в панель.
Анализ полученных данных
В ходе нагрузочного тестирования генерируется много важных для дальнейшего анализа данных. Перед уничтожением всех ресурсов в облачном проекте запускаем еще один Ansible Playbook.
Полезная информация, которую необходимо собрать и локально сохранить:
- сводный отчет «Тест-центра»,
- выгрузка технологического журнала,
- журнал регистрации,
- логи PostgreSQL,
- отчет pgBadger,
- планы запросов,
- скриншоты дашбордов Grafana.
Некоторые отдельные отчеты и скриншоты все еще приходится сохранять вручную, однако проект стремится к полной автоматизации.
Отчет pgBadger.
Одна из самых популярных утилит для анализа логов и сбора метрик PostgreSQL — pgBadger. В отчете имена таблиц БД заменяются по словарю на имена в контексте метаданных 1С.
Скрипт, выполняемый при выгрузке данных.
Скрипт сохраняет планы запросов из логов PostgreSQL в отдельные файлы. Далее их можно использовать для графического анализа.
Как новый подход уменьшил расходы в 7 раз
Специалисты подсчитали затраты на нагрузочное тестирование в рамках реального проекта. Дано: 1 000 пользователей ИТ-системы, 30 дней, 10 запусков по 8 часов. Стоимость необходимого контура — 12 000 рублей/день. При классическом подходе, который предполагает аренду сервера на все время работы над проектом, пришлось бы заплатить 360 000 рублей. При новом — 48 000 рублей, так как оплата производится только за продолжительность использования мощностей.
Финальная стоимость аренды стала ниже примерно в 7 раз. Поскольку большинство процессов автоматизировано, на подготовительный этап (настройку контура под проект, поиск конфликтов и ошибок в сценариях) потребовалось всего около 16 часов.
Графическое сравнение затрат двух подходов.
Возможности и дальнейшее применение
Решение позволяет в разы сократить затраты на тестирование производительности, а также снять с ИТ-партнера и заказчика головную боль в виде поиска необходимых ресурсов для проведения испытаний. Кроме того, из-за высоких требований к объему вычислительных ресурсов у проектных команд может уходить много сил на согласование и поиск компромиссов. Использование облачного провайдера решает и этот вопрос.
Новый подход стандартизирует процессы проверки производительности 1С, после чего они становятся понятнее для документирования. Решение применимо на большинстве проектов благодаря автоматизированному созданию инфраструктуры и возможности настройки всех важных параметров.
Помимо прочего, минимизация ручных операций позволяет ИТ-специалистам уделять больше времени написанию сценариев. Чем выше их качество, тем более релевантные результаты получит заказчик. У решения есть еще один плюс — оно значительно упрощает повторное проведение нагрузочных испытаний. Например, при переходе на новую версию платформы или при внесении изменений в конфигурацию кластера 1С.
