Привет, Хабр! На связи Сережа Королев, инженер департамента инфраструктурных решений и сервисов КРОК. Почти весь 2023 год я провел в наших лабораториях, занимаясь тестированием различного оборудования. Западные вендоры ушли с рынка, и им на замену появилось огромное количество альтернатив отечественного и азиатского производства. И нам нужно было все изучить и проверить на прочность.
В течение года (в перерывах между тестами и написанием отчетов) я рассказывал на Хабре о своем опыте тестирования серверов и СХД. А сегодня я хочу пригласить вас на импровизированную «экскурсию» по лаборатории. Расскажу и покажу, как и по каким методологиям мы в КРОК тестируем различные инфраструктурные решения. Все подробности – под катом!
Начну с того, что в офисе КРОК почти на каждом этаже находятся лаборатории. Каждая по-своему уникальна: имеет свою вместительность, цели, задачи и набор оборудования (не только инфраструктурного, но и, например, телеком; для внутреннего пользования или для демонстрации заказчикам).
Для нас лаборатории – это неотъемлемая часть компании, они нужны для поддержания скиллов команды Центра компетенций по ИТ-инфраструктуре КРОК. Тестирование оборудования и запчастей, проверка нагрузки, моделирование штатных и нештатных ситуаций – все происходит там. В них же есть свой парк старого оборудования, на котором каждый стажер проходит обучение, а «старички»-инженеры прокачивают там свои навыки.
На самом деле это очень круто, когда новичкам предоставляется возможность сразу работать на практике с разным железом. Обычно им выдается лабораторная работа, которую они должны выполнить в течение стажировки, завершением которой становится «боевое крещение»! Мой коллега Жора Дубовец уже выпустил отличную статью о том, с какими трудностями сталкиваются стажеры во время обучения и как проходит их путь до ведущего специалиста.
Добро пожаловать в инфраструктурную лабораторию!
Как только на рынке появляется перспективное решение, мы привозим его в лабораторию. Железо мы обычно либо берем на тесты у вендоров, либо закупаем самостоятельно для нашего демофонда. После чего мы готовы предоставлять его для тестирования по запросу.
За 2022-2023 годы объем оборудования и ПО вырос в несколько раз, потому что появилось много новых вендоров и решений.
Мы многое повидали за последние годы. Раньше было спокойно и привычно нам всем: крупные производители выпускали новые железки или софт. Мы их проверяли и тестировали. Все это сопровождалось качественной документацией. Вендор всегда был на связи, жизнь была прекрасной и все инженеры счастливы. Даже были случаи, когда вендор выпускал новые бета-версии своего софта и присылал нам свои собственные методики (Excel таблицу, в которой было прописано, как проверить их новую версию продукта с набором действий и ожидаемым результатом).
Сейчас же обстановка другая, появилось много ноунеймов (крупные производители, конечно, остались, но в меньшем объеме). Ничего против новых вендоров не имею, но изредка попадаются и такие, где документации к оборудованию может и не быть, либо она есть без перевода (хотя бы на английский язык), кому писать и плакаться – непонятно. Такое мы отбраковываем и не унываем.
На данный момент в кроковских лабораториях я протестировал огромное количество разного оборудования и ПО. Тестировал решения российских, китайских и других производителей, доступных на российском рынке.
Вместе с коллегами рассмотрели разные типы оборудования — реестровое, не реестровое, китайское — которое может в той или иной мере закрыть большую часть базовых потребностей крупных компаний. В частности, я в прошлом году писал статьи о тестировании СХД Infortrend, серверов OpenYard и Sitonica.
Для определения топовых решений проводим тестирование по собственной методологии, основываясь на запросах рынка и на том, что мы чаще всего видим в проектах. Оцениваем функциональность каждой единицы оборудования или софта и сравниваем аналогичное оборудование между собой. Конечно, задачи и запросы со временем меняются, поэтому методологию мы постоянно адаптируем.
Для записи результатов тестирования ведем специальную Excel таблицу:
Методология тестирования железа
Если рассказать кратко, у нас есть два типа тестирования: функциональное и нагрузочное.
При функциональном тестовые сценарии выполняются вручную без использования автоматизированных инструментов. Цель такого тестирования – выявление ошибок, проблем и дефектов в аппаратном решении и проверка «юзабельности» определенного решения.
Приведу пример функционального тестирования сервера. Оно включает в себя следующие шаги:
- Проверить упаковку и состав оборудования, наличие инструкции по инсталляции в комплекте;
- Проверить наличие необходимых компонентов в сервере;
- Смонтировать сервер в стойку. Оценить простоту инсталляции и удобство салазок. Зачастую также оцениваем, насколько качественно выполнен корпус устройства. Устранить неисправности если такие есть;
- Связаться с вендором и запросить у него всю возможную документацию и микрокоды для данного оборудования. Таким образом, мы оцениваем, насколько быстро и качественно вендор отвечает на запросы от потенциального клиента;
- Проверить версии микрокодов всех компонентов сервера, обновить их до последних версий;
- Оценить удобство использования BMC, как основного инструмента для удаленного управления сервером, проверить максимальное количество функций, заложенных производителем;
- Настроить RAID-массив;
- Удаленно, с использованием virtual media установить на сервер необходимые ОС несколько раз, используя разные версии, оценить их совместимость с конкретным решением;
- Составить отчет по итогу функционального тестирования и перейти к нагрузочному тестированию.
Нагрузочное тестирование — это процесс проверки работы системы или приложения под определенной нагрузкой, чтобы понять, насколько хорошо оно справляется с выполнением своих задач. Цель нагрузочного тестирования — выявление возможных проблем и узких мест в системе, чтобы их можно было устранить и оптимизировать производительность. Потому что бывает, что визуально и функционально все хорошо, а при продуктивной нагрузке начинаются сюрпризы и непредсказуемое поведение железа.
Обычно во время нагрузочного тестирования мы используем различные инструменты и бенчмарки, которые предназначены для разных целей. Для серверов наиболее часто мы используем следующие:
- Синтетический тест 7zip LZMA для проверки способностей железа к компрессии и декомпрессии файлов;
- nginx ApacheBench, позволяющий оценить число транзакций, которые сервер может обработать в единицу времени;
- PostgreSQL (pgbench) для проверки сервера на пригодность к работе с большими и сложными базами данных;
- Redis-benchmark, который используется для симуляции произвольного числа клиентов, одновременно подключающихся и выполняющих действия на сервере. Это позволяет понять, сколько времени требуется для выполнения запросов при определенном количестве клиентов;
- Тест Гилева, который помогает нам определить быстродействие платформы «1С:Предприятие» для использования сервера в качестве вычислительного узла «1С».
Мы используем и другие инструменты для проведения нагрузочного тестирования, тут все индивидуально. Выбор зависит от входящего запроса и преследуемых целей.
Приведу пример одного из не самых удачных кейсов тестирования.
Проблемы начались буквально, когда мы доставали сервер из коробки. Как я уже писал выше, мы оцениваем все возможные качества рассматриваемого решения. В том числе и насколько качественно собран сервер, насколько качественный металл и его обработка. У нашего «подопытного» с качеством сборки и обработки было всё довольно плохо. Несколько порезов о корпус, проблемные салазки (из коробки были кривые направляющие), отсутствие классической «полосы» вентиляторов в передней части корпуса (в этом решении использовались кулеры на радиаторах процессоров). Отсутствие документации в комплекте. Уже на этом этапе можно отбраковывать подобное решение, потому что оно больше напоминало стандартный ПК в корпусе для Rack-стойки в 2 юнита, но нам было интересно узнать, что он может.
Далее сервер решил преподнести нам сюрприз в виде отказа добавления драйверов для RAID-контроллера при установке Windows. На официальном сайте микрокодов и драйверов нет, вендор не отвечал, время шло… В процессе поиска, конечно, на просторах интернета были найдены совместимые драйвера, и сервер таки увидел сконфигурированный RAID-массив, после чего удалось установить ОС. Но осадочек остался.
Крайне интересно было, как себя поведет сервер с нестандартной системой охлаждения под нагрузкой. Мы запустили стресс-тест на сутки. Результаты были неутешительные:
Температуры переваливали за 80 градусов (при условии средней температуры в лаборатории в 18 градусов Цельсия). При этом у подавляющего большинства серверов других производителей с классической схемой охлаждения температуры на наших тестах зачастую едва переваливают за 60 градусов Цельсия. В общем и целом, это решение ощущалось горячим, что и требовалось ожидать.
В конце концов дело дошло до нагрузочного тестирования. Мы попытались оценить его производительность с помощью бенчмарков, и результаты были неутешительны. Сервер оказался крайне слабым по сравнению с решениями других производителей со схожими характеристиками.
К слову, в данном случае производитель вышел на связь через несколько дней, когда его помощь уже не требовалась. Но так происходит не всегда, у нас есть случаи, когда мы ждем ответ от некоторых вендоров до сих пор… ¯\_(ツ)_/¯
Конечно, подобное решение нельзя советовать к покупке. Ради таких «экземпляров» мы и проводим наши тестирования и изучаем текущий рынок.
Как мы тестируем ПО
Помимо железа мы тестируем еще и ПО. И тут две истории:
1. Проверяем работу оборудования, установив на него различные ОС и платформы виртуализации. Время такое, что преимущественно российские, но и про привычные не забываем.
2. Проверяем работу инфраструктурного ПО. Классов много, методики и наборы тестирования свои. Например, платформ виртуализации более 30 и нам приходится проверять их все и сравнивать между собой. Тестируем также операционные системы, системы резервного копирования (например, Aishu и Vinchin), почтовые серверы, инструменты для мониторинга, файлообменники и т.д.
Везде в основном на выходе получаем достаточно объемные таблички сравнений решений между собой, которыми можем поделиться, если есть запрос на выбор подходящего продукта. Конечно же, наши сравнения нужно дополнять теми требованиями, которые важны для тех или иных задач. Но то, что мы можем этот выбор упростить — это факт.
Зачастую сравниваем с привычным «эталоном», насколько закрывает его функционал. Но хочу отметить, что все новые производители стараются не только повторить, но где-то и дать нужные функции, которых не было раньше. И это очень круто.
Пишем отчет… и начинаем снова!
Весь смысл тестов в том, чтобы создать рабочие ситуации и проверить функциональные возможности инфраструктурных решений. По результатам тестирования мы готовим отчеты для внутреннего использования с целью передачи опыта (например, сервисная команда должна уметь поддерживать то, что установила команда внедрения), а иногда можем предоставить их по запросу. В отчетах мы честно рассказываем о плюсах и минусах, даем свои рекомендации по решению. Делимся впечатлением о наших тестах с коллегами, выкладывая все информацию в нашу базу знаний и пишем интересные статьи на Хабре!
Очень хочу услышать ваши идеи и предложения, как бы вы тестировали новинку. Как нам можно (и нужно ли) усилить методику? Может, есть пожелания, что нам протестировать и о чем рассказать на Хабре? Пишите комментарии 🙂
