До запуска в реальном проекте оборудование намеренно подвергают предельным нагрузкам, отключают от питания и создают другие нештатные ситуации. Вместе с Александром Власовым, руководителем управления исследований и разработок новых решений РТК-ЦОД, разбираемся, как R&D-лаборатория выявляет скрытые проблемы оборудования, почему заявленная производительность не всегда выдерживает проверку и какие новые требования к инфраструктуре предъявляет искусственный интеллект.

Лаборатория как фильтр
Еще пять лет назад российский рынок ИТ-оборудования был более предсказуемым. Компании годами работали в основном с крупными зарубежными производителями, знали особенности их решений, опирались на накопленный мировой опыт эксплуатации. Курс на импортозамещение потребовал перехода на отечественные продукты. Если в 2021 году в реестре российской радиоэлектронной продукции Минпромторга насчитывалось около 3,8 тыс. изделий, то к середине 2026 года — уже порядка 43 тыс., то есть более чем в 11 раз больше. Количество решений увеличилось, но степень их зрелости различается, а сопоставимого объема экспертизы нет.
При этом оценить надежность по рекламным материалам и техническому описанию невозможно. Во время презентации оборудование может показывать высокую производительность и работать без ошибок, но иначе повести под продолжительной нагрузкой. R&D-лаборатория выступает фильтром между рынком и действующей инфраструктурой: новые решения испытывают до запуска в проектах.
Результаты таких испытаний используют при развитии собственной инфраструктуры РТК-ЦОД, а также в клиентских проектах. Нестабильное оборудование может вызвать сбои во внутренних системах компании, а при работе с заказчиками — привести к нарушению SLA, штрафам и потере доверия. Лаборатория позволяет выявить эти риски заранее.
Пять шагов оценки
1. Знакомство с производителем
Есть два сценария, по которым лаборатория начинает работу с новым оборудованием. В первом запрос приходит от внутреннего заказчика, который рассматривает конкретное решение для проекта. Во втором специалисты лаборатории сами находят на рынке перспективный продукт и знакомятся с производителем. Для этого проводят отдельную встречу или приглашают компанию в R&D-клуб, где она рассказывает о своих разработках.
2. Заполнение опросника с подробными сведениями о продукте
В лаборатории его называют «идеальным техническим описанием» — компания должна раскрыть характеристики решения, его возможности и ограничения. Уже на этом этапе можно увидеть, что оборудование пока не готово к испытаниям.
3. Подготовка оборудования
Если явных препятствий нет, оборудование доставляют в лабораторию, устанавливают и производят наладку. Одновременно собирают рабочую группу. В нее входят специалисты лаборатории, архитекторы, которые планируют использовать решение в проекте, и представители производителя. Последние помогают с настройкой и консультируют при возникновении вопросов.
4. Испытания
Проверка проходит по собственной программе и методике испытаний (ПМИ) с заранее определенными критериями. Здесь оценивают функциональность, производительность и стабильность оборудования, воспроизводят отказ отдельных компонентов. При необходимости проверяют совместимость с другим оборудованием и ПО.
5. Отчет и заключение — применимо ли решение в проектах или его пока нельзя допускать
Если решение не проходит испытания, компания либо ищет альтернативу, либо вместе с производителем начинает цикл доработок. После исправления дефектов оборудование проверяют повторно, причем одной дополнительной итерации часто недостаточно. Особенно долго процесс может идти с уникальными решениями без доступных аналогов: тогда лаборатория фактически помогает производителю подготовить продукт к реальным проектам.
Как проверяют серверы и СХД
Подробнее остановимся на четвертом шаге — непосредственно испытаниях — и на примере серверов и систем хранения данных (СХД) рассмотрим, из чего состоит проверка обещанных производителем характеристик.
Тестирование серверов
Для серверов тестирование включает пять этапов:
- Функциональное тестирование проверяет корректность реализации каждой заявленной производителем возможности сервера, включая работу контроллера удаленного управления BMC и других подсистем.
- Нагрузочное тестирование с помощью специализированных утилит оценивает производительность оборудования в различных сценариях эксплуатации. При таких проверках в отдельных случаях серверы показывали лишь 30% от заявленной производительности. Такой результат может указывать на проблемы в архитектуре решения и его настройке. В рамках этого же направления выполняется стресс-тест — непрерывная работа под 100% нагрузки всех вычислительных ресурсов на протяжении 48 часов для оценки стабильности.
- Тестирование отказоустойчивости имитирует выход из строя отдельных компонентов оборудования. Фиксируется, работает ли сервер стабильно и корректно в деградировавшей конфигурации.
- Тестирование совместимости серверов с аппаратными модулями доверенной загрузки. Испытание позволяет подтвердить возможность безопасного применения оборудования в средах с повышенными требованиями к защите информации.
- Тестирование совместимости серверов с платформой виртуализации.
Для испытаний серверов команда разработала собственную утилиту с веб-интерфейсом. Она устанавливает необходимое ПО, запускает функциональные проверки и тесты производительности, затем собирает результаты.
Тестирование отказоустойчивости по-прежнему приходится воспроизводить вручную:
- Отключение одного из блоков питания. Если система спроектирована правильно, сервер продолжит работать на оставшемся блоке, а пользователи ничего не заметят.
- Отказ накопителей. Сервер нагружают работой, а затем извлекают диски. К примеру, классический массив RAID-6 должен переживать выход из строя двух. Специалисты проверяют, сохранились ли данные, продолжает ли система работать, началось ли автоматическое восстановление массива.
- Отключение сетевых портов под нагрузкой. Специалисты проверяют, как сервер и установленное ПО реагируют на потерю соединения. Например, во время испытаний возникали случаи, когда драйверы неправильно реагировали на отключение порта.
Тестирование СХД
Системы хранения данных (СХД) тестируются похожим образом, но этот процесс имеет свои особенности. Производители такого оборудования часто заявляют высокие показатели, однако сами по себе цифры мало говорят о том, как система ведет себя в реальности.
Производительность СХД оценивают по трем основным параметрам: числу операций ввода-вывода в секунду (IOPS), пропускной способности (bandwith) и задержке (latency).
Например, производитель может декларировать в маркетинговых материалах, что система выполняет 10 тыс. операций ввода-вывода в секунду. Но результат зависит от профиля нагрузки. Одно дело — тестирование производительности СХД профилем нагрузки — последовательное чтение или запись (как, например, в системах видеонаблюдения), другое — одновременно записывать и читать множество фрагментированных данных.
На результат влияют соотношение операций чтения и записи, а также размер блока — объем данных, который система обрабатывает за раз. Благодаря тестированию СХД по одной программе и методике испытаний показатели разного оборудования можно сравнивать друг с другом.
Две недели под нагрузкой
При этом даже подтвержденная производительность не означает, что оборудование готово к эксплуатации. Во время испытаний одной из СХД сотрудники лаборатории убедились, что система демонстрирует высокую производительность, но работает нестабильно. Стресс-тест продолжался две недели — за это время 35 раз зафиксировали полную остановку операций ввода-вывода, то есть система на 30–40 секунд переставала принимать и передавать данные. Представьте, если бы с такими простоями сталкивались пользователи «Госуслуг» или ключевых банков.
Тестирование отказоустойчивости у СХД более сложное, чем у серверов. Например, во время работы один из двух контроллеров могут принудительно перевести в аварийный режим или отключить. Специалисты проверяют, произошла ли остановка ввода-вывода и снизилась ли производительность. Такие испытания заранее согласовывают с производителем: некоторые СХД не поддерживают подобный сценарий и могут выйти из строя.
ИИ под нагрузкой
Искусственный интеллект все чаще становится одной из задач, под которые создают и обновляют ИТ-инфраструктуру, поэтому решения для ИИ постепенно становятся отдельным направлением работы лаборатории. Вычисления выполняются на центральных процессорах или графических ускорителях — GPU. Последние требуют много электроэнергии и выделяют значительное количество тепла, поэтому оценивать такое оборудование только по производительности нельзя.
Серверы в дата-центре устанавливают в специальные шкафы — стойки, для каждой из которых предусмотрена определенная электрическая мощность. Стандартная стойка может быть рассчитана на 5, 7 или 10 кВт. Если в нее установить несколько серверов с большим количеством GPU, доступной мощности не хватит.
Например, если у заказчика кластер насчитывает 60 шкафов, каждый из которых потребляет 30 кВт, а в установленных там серверах по восемь GPU, то такую инфраструктуру важно обеспечить электричеством и спроектировать так, чтобы оборудование не перегревалось.
Один из способов охлаждения оборудования — разделение воздушных потоков. Холодный воздух поступает к передней части серверов, а нагретый отводится в изолированный горячий коридор.
Для более мощного оборудования могут использоваться жидкостно-воздушные системы. В стойке устанавливают радиатор, который охлаждает проходящий через оборудование воздух. Другой вариант — прямое жидкостное охлаждение с подводом жидкости непосредственно к процессорам или GPU. Оно позволяет отводить больше тепла, но требует сложной и дорогой инфраструктуры, которую труднее обслуживать.
Энергопотребление и тепловыделение рассчитывают до установки оборудования. Специалисты лаборатории заранее передают параметры серверов инженерам дата-центра, которые определяют, получится ли инфраструктуре выдержать такую нагрузку. Если доступной мощности или возможностей охлаждения нет, конфигурацию приходится менять.
Переезд без потери данных
Помимо испытаний самого оборудования, лаборатория отдельно проверяет, как проходит миграция с одной инфраструктуры на другую, поскольку она не заканчивается простым копированием данных. Информация может перенестись не полностью, система — не запуститься на новых мощностях, а процесс занять больше времени, чем планировалось.
Чтобы заранее выявить такие риски, лаборатория испытывает системы миграции и репликации — переноса и постоянного копирования данных между хранилищами. Например, специалисты проверяют работу репликации на отечественных СХД и перенос виртуальных машин.
Если системы находятся на удалении друг от друга, слабым местом может стать канал связи. Низкая скорость и высокие задержки способны замедлить перенос и вызвать ошибки. Испытания позволяют проверить, сохранится ли целостность данных и заработает ли система после переезда, а также заранее оценить его продолжительность.
Что нужно R&D-лаборатории
Для работы R&D-лаборатории нужна изолированная инфраструктура, позволяющая собирать разные конфигурации оборудования.
Например, в распоряжении лаборатории РТК-ЦОД находятся 35 стоек в двух московских дата-центрах, собственные сеть и облако. Одновременно команда может испытывать около 15 решений.
Не менее важны программы и методики испытаний с едиными критериями оценки. Они позволяют воспроизводить процесс, сопоставлять модели и накапливать базу результатов. Благодаря этому каждое новое решение оценивают в сравнении с уже изученным оборудованием.
Но главный ресурс лаборатории — специалисты с инженерным опытом и интересом к исследованию новых технологий. Специфика работы в том, что им приходится иметь дело не только с оборудованием, где уже существуют готовые методики, но и с новыми решениями, которые еще только предстоит научиться правильно испытывать. Готовых R&D-инженеров на рынке почти нет, поэтому специалистов приходится обучать внутри команды: подготовка занимает от трех до шести месяцев. За несколько лет штат лаборатории вырос с 3 до 18 человек.
Что касается будущего, то сейчас одна из главных тем для лаборатории — развитие инфраструктуры для ИИ. Рост вычислительных нагрузок одновременно повышает требования к системам хранения и сетям, ведь они должны работать быстрее и с минимальными задержками.
Еще одно перспективное направление — серверы на отечественных процессорах. Сейчас в российском оборудовании по-прежнему преимущественно используются зарубежные чипы, но с появлением новых решений на базе «Эльбруса» лаборатория планирует оценить их производительность и возможности применения в реальных проектах.
Однако появление перспективного решения на рынке еще не означает, что его можно сразу использовать в действующей инфраструктуре. Чем быстрее развиваются технологии, тем важнее проверять их до запуска в проектах. R&D позволяет инфраструктурному бизнесу осваивать новое без экспериментов на клиентах.