Привет, Хабр! На связи Сережа Королев, инженер департамента инфраструктурных решений и сервисов КРОК. Почти весь 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), почтовые серверы, инструменты для мониторинга, файлообменники и т.д.
Везде в основном на выходе получаем достаточно объемные таблички сравнений решений между собой, которыми можем поделиться, если есть запрос на выбор подходящего продукта. Конечн�� же, наши сравнения нужно дополнять теми требованиями, которые важны для тех или иных задач. Но то, что мы можем этот выбор упростить — это факт.
Зачастую сравниваем с привычным «эталоном», насколько закрывает его функционал. Но хочу отметить, что все новые производители стараются не только повторить, но где-то и дать нужные функции, которых не было раньше. И это очень круто.
Пишем отчет… и начинаем снова!
Весь смысл тестов в том, чтобы создать рабочие ситуации и проверить функциональные возможности инфраструктурных решений. По результатам тестирования мы готовим отчеты для внутреннего использования с целью передачи опыта (например, сервисная команда должна уметь поддерживать то, что установила команда внедрения), а иногда можем предоставить их по запросу. В отчетах мы честно рассказываем о плюсах и минусах, даем свои рекомендации по решению. Делимся впечатлением о наших тестах с коллегами, выкладывая все информацию в нашу базу знаний и пишем интересные статьи на Хабре!
Очень хочу услышать ваши идеи и предложения, как бы вы тестировали новинку. Как нам можно (и нужно ли) усилить методику? Может, есть пожелания, что нам протестировать и о чем рассказать на Хабре? Пишите комментарии :)
