Мы в компании Аквариус стремимся к тому, чтобы тестирование проходило без активного участия человека. Поэтому, продолжая предыдущую нашу статью про автоматизированное тестирование BMC: Тестирование BMC: Автоматизировать! Нельзя все руками, я расскажу про универсальное решение, которое мы создаем для получения показателей производительности BMC. Зачем это нужно и как мы пытаемся применять накопленный опыт в других направлениях, например при тестировании производительности нового для компании направления — СХД (Система Хранения Данных).
Что такое BMC и зачем он нужен?
BMC (Baseboard Management Controller) — это специализированный микроконтроллер, который выполняет такие задачи, как инвентаризация серверов, мониторинг и управление питанием. Благодаря BMC можно удаленно управлять серверами, отслеживать их состояние и поддерживать стабильную работу. Без надежного BMC администраторы могут столкнуться с трудностями в управлении и мониторинге серверным парком.
Какие особенности при тестировании микроконтроллеров?
BMC — это в первую очередь микроконтроллер, имеющий небольшую производительность. На момент написания статьи самый популярный чип, используемый для BMC, — ASPEED AST2500 с ядром на базе ARM11 с частотой 800MHz и памятью DDR4 SDRAM объемом 512MB. Поэтому это накладывает свою специфику при проведении тестирования производительности.
Две основные особенности, с которыми сталкиваются при тестировании производительности — недостаточная пропускная способность и заполнение очереди запросов, причем в большинстве ситуаций одно вытекает из другого. На сколько бы не было оптимизировано ПО для BMC, подавать нагрузку, аналогичную серверным или настольным решениям, не получится. Если сразу начать с больших значений RPS (Requests Per Second), то BMC может заполнить все свои очереди запросами и как следствие ему не хватит ресурсов (CPU/RAM) для обслуживания каждого из них. Это может замедлить работу микроконтроллера или вообще превратить его в «зомби».
Сразу отмечу два важных момента. Во‑первых, BMC не обязан обрабатывать тысячи запросов в секунду. Обычно его опрашивают одна‑две системы менеджмента и мониторинга северного оборудования. В качестве такой системы может служить DCIm (Data center infrastructure management), которая совместима с Redfish запросами для BMC. И второй важный момент, про который необходимо знать — с помощью тестирования производительности мы можем давать рекомендации своим клиентам о том, как часто опрашивать сервера. Это необходимо в первую очередь для оптимизации рабочего времени системных администраторов, которые хотят всегда видеть актуальное состояние систем, а не заниматься подбором времени опроса серверного парка.
Какие методы и технологии использовать при нагрузочном тестировании микроконтроллеров?
К 2024 году у сообщества уже накопился огромный опыт работы с Entrerprise‑решениями. Поэтому мы решили делать все в лучших традициях данного подхода, дорабатывая под особенности нашей задачи.
Наша работа с нагрузочным тестированием охватывает несколько основных концепций, который мы рекомендуем и другим:
• Контейнеризация: Основное преимущество — развертывание тестов в контейнерах для изоляции и упрощения масштабирования. Например, если у вас 20 и более серверов с разными версиями прошивок, которые необходимо протестировать, то самое оптимальное решение — создать очередь тестов (мы сделали это на базе RabbitMQ), которая распределяется на несколько генераторов нагрузки, упакованных в Docker контейнеры. Таким решением мы предлагаем разработчикам самостоятельно ставить тестирование в очередь или оно будет ставится в очередь с выходом новой прошивки, а наша система уже самостоятельно пришлет результаты прошедших бенчмарков.
• Автоматизация: Автоматизация процесса подбора профилей нагрузки позволяет быстрее выявлять узкие места. Наша рекомендация заключается в том, чтобы один раз реализовать сервис для поиска граничных значений нагрузки в зависимости от SLA или иных факторов, что позволит в будущем не тратить время на ручной подбор конфигурации теста. Также максимальная автоматизация нужна в создании отчетов о тестировании. Это позволяет QA переключиться на написание новых тестов и прочие проекты, а не погружаться в десятки страниц отчетов.
• Широкий выбор инструментов генерации нагрузки: Мы рассмотрели различные инструменты (JMeter, Locust, K6) и выстроили для себя концепцию бенчмарков. В нашем проекте бенчмарк — это составное понимание, включающее в себя тест производительности, указание генератора нагрузки и экстрактора данных для соответствующего генератора. Это позволяет реализовывать тесты на любом привычном для решении, что сильно упрощает работу команды и минимизирует время включения в работу новых людей.
Эти три метода позволяют нам в кратчайшие сроки создавать новые бенчмарки, своевременно выдавать отчеты о тестировании, а так же применять любой опыт разработки. Такой подход мы называем Performance Testing as a Service.
Сильно ли влияние Enterprise‑разработки на тестирование BMC?
Давайте все же обсудим, что еще из мира Enterprise нам удалось перенять и как это повлияло на эффективность нашей работы:
-
Проектирование и планирование: Архитектура системы должна учитывать особенности микросервисов и возможность масштабирования. Моя рекомендация — используйте C4 модели, это позволит хранить простые файлы в формате «архитектура как код». И не забывайте о всех возможностях, которые дает K8S с его огромным зоопарком различных функций и решений, это упростит масштабирование, например его можно организовать по требованию в случае переполнения очереди ожидаемых тестов.
-
Обобщайте сущности для переиспользования в других ситуациях: Как сервисы уведомлений уже стали обычным решением в проектах, так и мы решили обобщить тесты в бенчмарки. Это позволило нам унифицировать тесты, делать результаты более однотипными и понятными, быстро начать тестировать не только BMC, но и СХД.
-
Интеграция и взаимодействие микросервисов между собой и с внешними системами: Мы используем REST и MQ для оптимизации взаимодействия сервисов. Это позволило нам предоставлять несколько интерфейсов для запуска нагрузочного тестирования. Например, сейчас любой специалист имеет выбор между Web UI, Jenkins и CLI, как ему удобней. А под капотом всех трех методов запуска тестов лишь один единственный REST запрос!
-
UI и CLI интерфейсы: Интуитивный интерфейс и командная строка позволяют тестировщикам быстрее взаимодействовать с системой. Упрощайте работу сотрудников, предоставляя им максимум возможностей, и тогда у вас получится отличное решение. Специалисты быстрее поймут влияние патчей еще даже до публикации их в основных ветках проекта. Руководствуясь этими подходами мы создаем коммунальный сервис с гибким и удобным интерфейсом для тестирования BMC и адаптируем их для других серверных продуктов. Причем создаем мы это небольшой, но очень активной командой.
Как наш подход помог улучшить BMC?
Success Story #1: улучшение системы логирования
Мы выявили, что логирование в BMC может не справляться с высокой нагрузкой, что приводило к потере некоторых логов. С помощью бенчмарков мы выявили критические моменты в подсистеме логов и предложили улучшения, которые позволили повысить надежность логирования.
Success Story #2: адаптация сервиса под другие команды
Благодаря внедренным бенчмаркам и унификации интерфейсов нам удалось создать коммунальный сервис, который могут использовать не только тестировщики, но и разработчики, аналитики и другие команды для исследования производительности. Это позволило значительно расширить возможности тестирования и облегчило взаимодействие между отделами, а также помогло оптимизировать время, которое тратится на получение результатов проверки новых прошивок и версий продуктов.
Заключение
Нагрузочное тестирование BMC оказалось по‑настоящему интересной задачей, связанной не только с проверкой производительности, но и с глубоким пониманием работы микроконтроллеров. Наш опыт показывает, что сочетание классических методов и современных Enterprise‑практик даёт отличные результаты и позволяет лучше понять все нюансы работы BMC. Мы смогли выявлять узкие места, повышать производительность и создавать универсальный продукт, подходящий для использования различными командами.
А как у вас обстоит дело с нагрузочным тестированием BMC или других микроконтроллеров? Сталкивались ли вы с похожими проблемами? Давайте обсудим! Делитесь в комментариях своими мыслями, историями и подходами — всегда интересно узнать, как другие справляются с аналогичными задачами.
Кстати, если вам интересна эта тема, приглашаю вас на конференцию Highload++ 2–3 декабря 2024, где можно обсудить вопросы производительности лично на стенде ПК Аквариус! Буду рад обменяться опытом и поговорить о новых возможностях и инструментах. На стенде можно будет пообщаться и с коллегами из других направлений. Все вместе будем играть в «AQ Memo», собирать сервер и каждый день разыгрывать суперприз — книгу «Сто лет недосказанности. Квантовая механика для всех в 25 эссе» с подписью автора!
До встречи!
Автор: BorisBochkaryov
