Привет, меня зовут Александр, я руковожу Управлением исследований и разработки новых решений в «Ростелеком-ЦОД», если коротко — лабораторией R&D.

Сейчас лаборатория хорошо прокачана и продуктивна, но так было не всегда. В этой статье я расскажу, как мы ее создавали, к чему пришли и как тестируем оборудование, ПАК и ПО.

Что у нас есть на сегодняшний день

Лаборатория расположена в ЦОД «Москва II» в кластере «Курчатовский». Дата-центр построен по стандарту Tier III. Это стабильная инфраструктура, которая обеспечивает бесперебойную работу лаборатории. Сегодня в ней восемь стоек, плюс двадцать стоек мы собираем в дата-центре «Медведково».

Наше подразделение занимается испытаниями программно-аппаратных комплексов, различного софта, виртуализации и оборудования: серверов, СХД, сетей хранения данных, сетей передачи данных, сетевого оборудования, систем резервного копирования и т. д.

У нас восемь стоек по 7 кВт на 42 юнита. Бесперебойное электропитание первой категории, независимые энерговводы в каждой стойке продублированы дизель-роторными ИБП. Есть свое интернет-подключение с использованием протокола BGP, а также появился IPv6, и мы сами выдаем учетки для подключения к лаборатории.

Сеть передачи данных собрана на оборудовании Cisco Nexus, все это работает в виде L3-фабрики с использованием EVPN/VXLAN. Spine-уровень — это 72-портовые Cisco Nexus 9272Q по 40 Гбит/c на порт. Leaf уровень — это медные Cisco Nexus 93108TC-EX под менеджмент и оптические Cisco Nexus 93180YC-EX под дата-сеть 48 портов 10/25 Гбит/с. Есть своя сеть хранения: два 48-портовых коммутатора Huawei по 16 Гбит/с на порт. Есть система хранения данных HPE 3par 8450N.

Выработаны собственные методики тестирования серверов, СХД, сетевого оборудования. Есть регламент работы лаборатории и взаимодействия с нами.

Теперь расскажем все по порядку.

1. Как появилась наша лаборатория

2. Какие задачи мы выполняем

3. С какими проблемами сталкиваемся

4. Кто наш заказчик

5. Что мы тестируем

6. Как мы проводим испытания

7. Какие инструменты используем

8. Этапы тестирования

Как появилась наша лаборатория

Летом 2020 года еще не было жестких санкций. Импортозамещением занимались вяло, оборудование время от времени испытывали разные подразделения компании. Не было ПМИ, централизованного процесса, подробных отчетов.

Руководитель дирекции по развитию инфраструктуры поставил мне задачу создать лабораторию, где мы будем тестировать оборудование и ПО, прежде чем оно пойдет в прод.

Начали мы с одной стойки в ЦОД «Москва II». Отдел состоял всего из трех человек.

Протянули локальную сеть от ЦХД, для удаленного подключения использовали VPN внутренней сети предприятия Fortinet, установили б/у коммутатор Juniper EX3300, который постоянно зависал и который приходилось перезагружать каждые три месяца.

Нашим первым испытуемым в лабораторных условиях стал сервер AIC c Intel Optane Memory 100, его предложили нам для тестирования ребята из Intel. Мы рассчитывали использовать Optane в качестве дополнения к классической оперативке в проектах компании. В итоге оказалось, что он не подходит нам, так как работает с большими задержками.

После завершения испытаний мы отчитались о запуске лаборатории. Теперь можно было привозить, подключать и тестировать железо. Начался процесс доработки лаборатории под конкретные задачи.

Следующими объектами исследования стали серверы SuperMicro, причем тестировали мы их дистанционно в китайской лаборатории. Нам выдали удаленный доступ, VPN, мы к ним подключались, просили развернуть ту или иную инфраструктуру и сравнивали, как работают процессоры Intel 6248R и AMD 7F72. Тогда мы приобрели огромный опыт в тестировании серверов, обкатали бенчмарки и составили первую версию программы и методики испытаний (ПМИ) по серверам.

Плюс удаленного тестирования — не надо ничего втискивать в свою маленькую лабораторию. Минус — нужно постоянно писать запросы, вроде: «Поставьте нам вот такой коммутатор», — а это дольше, чем делать у себя. Поэтому мы старались все везти в нашу лабораторию.

В начале 2021 года ушел один человек, и мы остались вдвоем на целый департамент. Нас называли «Двое из ларца».

И тогда к нам приехал здоровенный шкаф СХД Infinidat высотой 42 юнита, который занимал целое стойко-место. Он работал на обычных жестких дисках, но вендор заверял, что его производительность не хуже, чем у all-flash СХД. Нам нужно было оценить его пригодность к применению в проектах «Ростелеком-ЦОД».

Мы создали стенд из восьми серверов Huawei, на них развернули систему виртуализации VMware, настроили виртуальные нагрузочные машины, на которых развернули ПО для создания синтетической нагрузки Vdbench, а вдобавок нашли на складе два коммутатора Fibre Channel.

С этими коммутаторами произошла забавная история. Они остались от какого-то проекта, и никто не знал к ним логина и пароля. Даже вендор не мог нам сбросить их на дефолт, потому что на Huawei на тот момент наложили санкции, и Brocade (производитель коммутаторов) отрезал им доступ к служебным программам.

Я неделю ходил по всей компании и пытался узнать в каком проекте использовали эти коммутаторы. Филды помогли мне найти специалиста, который их настраивал года три назад, он дал нам логин/пароль, и они заработали.

Это было важное событие, потому что в такой гигантской компании очень трудно найти людей, которые когда-то админили две железки. Если бы мы не нашли этого человека, то два дорогих коммутатора просто бы превратились в пару бесполезных кирпичей.

Этот стенд мы собирали и настраивали целый месяц. Потом я уехал в отпуск в Вологодскую область, будучи уверенным, что все собрано и должно работать.

И вот сижу я в избушке, за окном минус тридцать, волки воют, снег хрустит, и тут мне приходит сообщение, что стенд упал. Вдобавок еще и централизованное отопление отключилось, дом начал остывать, пришлось «топить» избу конфорками электроплиты.

Я чудом поймал интернет с мобильного, удаленно подключился к стенду и всю ночь просидел за ноутбуком в этой глуши. К утру выяснили, что у коммутаторов, долго лежавших на складе, запылились оптоволоконные трансиверы и плохо выдавали сигнал. Мы поменяли трансиверы, и стенд заработал.

При помощи различных настроек мы тогда дали синтетическую нагрузку из 20 профилей VDbench, которые были максимально приближены к продуктиву и создавались по результатам нагрузки на реальных проектах. Некоторые из этих профилей у нас есть до сих пор: Ultra Fast (самый мощный), SAS fast (средний) и Sata standart (медленный).

В процессе пусконаладки Infinidat мы писали наше первое ПМИ по СХД вместе с ребятами из эксплуатации СХД, за что им огромное спасибо. Затем мы составили подробный отчет о проведенных испытаниях, всё прошло замечательно. Но я никогда не забуду, как проводил диагностику из заваленной снегом избушки в 750 км от Москвы.

В ходе тестирования Infinidat мы выяснили, что у нее есть проблемы с деградацией производительности после 20 часов работы под полной нагрузкой. И после публикации отчета все в компании окончательно убедились в том, насколько важны отдельная лаборатория и предварительное тестирование.

В середине 2021 года к нам пришел новый сотрудник и здорово подхватил тестирование серверов, в том числе российского производства. Так что к началу безумного импортозамещения у нас на руках уже были отчеты о тестировании отечественного оборудования. Мы потратили на них три месяца и в целом очень круто прокачались, а по результатам испытаний сервера одного из наших производителей написали расширенную ПМИ.

Но не только мы тащили лабораторию. Одними из самых трудоемких задач занимались наши филды: монтажом, коммутацией, первоначальными настройками по нашим заявкам.

Подключение новой железки может занять неделю: смонтировать, воткнуть в стойку, скрутить провода, которые еще нужно найти, заказать расходники. Наша лаборатория — это постоянно меняющаяся инфраструктура, поэтому работа для филдов есть всегда. Кроме того, они помогают нам разобраться, если что-то не работает.

Хочу их поблагодарить за то, что они делают огромную работу. Без них мы бы, наверное, не выжили.

Когда мы тестировали первые отечественные серверы, то составляли методику тестирования на ходу. Это было сложно. Нужно было и тестировать, и писать ПМИ, и оформлять отчет. Потом у нас завязалась тема с тестированием сетей передачи данных. Никто ничего не знал, не понимал, как это оборудование настраивать и что от нас хотят. Мы строили тестовые стенды, писали ПМИ и учились тестировать разное оборудование.

Был случай, когда мы протестировали железку, выдали негативный отчет и рекомендовали ее не закупать. Но по какой-то причине ее все-таки закупили и начали использовать в продуктиве, а она начала грохаться везде. После этого инцидента к нашим рекомендациям стали относиться еще внимательнее и поняли, что без тестов лучше в прод ничего не ставить.

Какие задачи мы выполняем

Когда лаборатория была полностью укомплектована, мы смогли полноценно выполнять поставленные в 2020 году задачи:

• организовывать и проводить испытания новых технологий;

• разрабатывать программы и методики испытаний;

• участвовать в разработках новой технической архитектуры;

• участвовать во внедрении новых решений;

• консультировать архитекторов, эксплуатацию, РП и продуктологов.

И главное — мы стали исследовать и испытывать новые технологии и продукты для ИТ-инфраструктуры.

С какими проблемами сталкиваемся

В первую очередь, это сырое и забагованное оборудование и ПАК.

У оставшихся в России вендоров часто нет своих ПМИ, а иногда нет даже документации на продукт. Но еще хуже, когда вендор сам не знает, как работает его продукт, какая у него производительность, как он реагирует на сервисные операции.

С 2022 года головной болью стали жесткие санкции и отсутствие возможности закупать импортное оборудование и ПО. Прекратилась техподдержка многих зарубежных вендоров.

К сожалению, не все понимают трудоемкость процесса тестирования. Недостаточно просто сесть, воткнуть вилку в розетку, пару недель поиграться с оборудованием, написать пару комментариев и отправить его в прод.

Под каждую задачу мы собираем уникальный стенд, что порой занимает много времени, ведь нам нужно найти или заказать и ждать нужные компоненты. Потом мы начинаем настраивать это оборудование, а оно может не заработать вообще или откажет при первоначальной настройке.

Например, мы все нашли, подключили, решили с вендором проблемы, настроили и начинаем испытания. И тут снова тысяча сюрпризов: там что-то грохнулось, тут что-то сломалось, тут выдернули проводок, и СХД накрылась. Пишем вендору — он уходит в астрал на две недели, а мы ждем, пока он решит эту проблему. Особенно трудно нам было, когда мы имели всего три стойки в ЦОДе, которых катастрофически не хватало под наши задачи.

Есть такой миф, что тестирование — это быстро, легко и увлекательно. На деле же это всегда сложно и долго.

Один только отчет в среднем составляет около 100–150 страниц. В нем мы полностью описываем каждую железку, конфигурацию тестового стенда, собираем все результаты, строим графики производительности, описываем тестирование отказоустойчивости и функциональное тестирование, пишем вывод: может это железо применяться в конкретном проекте или нет.

Как мы работаем сейчас

Сегодня наша лаборатория может вести около пятнадцати проектов одновременно. Сейчас мы тестируем три отечественных сервера, три СХД, три стенда для сетей передачи данных. Недавно уехала с тестов китайская СРК.

Комфортный режим — одно устройство или один испытательный стенд на одного сотрудника. Но по факту оборудования часто оказывается больше.

Лаборатория — это не количество стоек, а экспертиза: что мы умеем, за что можем взяться. Важно не количество тестов, а их качество.

Большой пласт нашей работы — это аналитика. Мы изучаем новые технологии и продукты, следим за появлением новых продуктов на рынке, анализируем данные и выбираем, какую новинку взять в лабораторию на испытания. По результатам анализа мы выдаем аналитическую записку и говорим, что на рынке есть перспективная технология.

Мы не берем на тест, например, один коммутатор: берется так называемая фабрика, чтобы отработать различные протоколы и технологии. А на основе этого тестового стенда архитекторы могут по нашим рекомендациям построить техрешение. Мы не только помогаем архитекторам разрабатывать техническую архитектуру, но и вместе с ними стараемся повысить эффективность технических решений.

Также коллеги обращаются к нам, если идет внедрение уже протестированного железа, спрашивают, как его настроить. Иногда мы просто консультируем по конкретному проекту.

Работа сложная, достаточно творческая, постоянно берем что-то новое — и железо, и софты, — задач много.

90% успеха лаборатории — это слаженный, мотивированный коллектив энтузиастов, который тащит все на своем горбу 24/7.

Кто наш заказчик

Главный источник задач на данный момент — это внутренние заказчики «Ростелеком-ЦОД»: эксплуатация, архитекторы, центр компетенций, разработчики софта, например отечественные производители систем виртуализации.

Иногда прилетают задачи из ПАО «Ростелеком» и его дочерних подразделений. Они запрашивают отчеты на определенное оборудование или просят провести новое тестирование, потому что у них нет таких компетенций.

Может быть, в будущем мы будем предоставлять услуги тестирования для внешних заказчиков.

Что мы тестируем

Приоритетными считаем исследования оборудования и ПАК производителей из России и дружественных стран:

• систем виртуализации. Можем оценить переподписку в кластере;

• сетевого оборудования и балансировщиков нагрузки;

• СРК;

• серверов, в том числе ОСР;

• процессоров различных архитектур для сравнения производительности;

• High Performance Computing (GPU);

• операционных систем.

• СХД:
  - iSCSI, iSER, NVMeOF;
  - SDS и классических СХД;
  -S3.

• инженерных систем:
  - сравнение технологий построения ЦОД, например, классическое охлаждение, freecooling и жидкостное охлаждение.

Как мы проводим испытания

1. Получаем ТЗ от заказчика.

2. Согласовываем ПМИ и сроки.

3. Проводим тестирование.

4. Составляем и публикуем отчет.

5. Выступаем с презентацией внутри компании на «Архклубе».

6. Представляем результаты тестирования на Архкоме.

Есть регламент взаимодействия с нами. Он регулирует поток сознания от наших внутренних заказчиков — инженеров эксплуатации, архитекторов и прочих. Когда они что-то от нас хотят, то согласовывают это со своим руководителем и пишут нам заявку.

Еще у нас есть внутренняя система учета заявок — реестр R&D,— где прописаны проведенные и запланированные испытания.

Какие инструменты используем

• VMware VMmark,

• Sysbench,

• Stress-ng,

• Geekbench,

• Vdbech,

• Trex,

• Iperf2 и Iperf3,

• Intel MP Linpack,

• Phoronix Test Suite,

• Тест Гилева,

• Fio,

• Passmark CPUMark.

Этапы тестирования

Прежде чем оборудование пойдет на тестирование, должен быть определен заказчик. Он составляет техническое задание, в котором обязательно описывает набор профилей нагрузочного тестирования и прочих тестов. Заказчик определяет список факультативных тестов, которые из-за ограниченного времени тестирования имеют низкий приоритет.

Иногда мы сами выбираем оборудование на тест, иногда нам поступает запрос от коллег из других отделов.

Часто мы приглашаем производителя на наше внутреннее мероприятие «Архитектурный клуб», где он рассказывает про свою разработку. По результатам аналитики и выступления производителя мы делаем вывод, стоит ли вообще брать на тест это оборудование. Еще у нас есть опросник, который мы отправляем вендору. Он заполняет, и по его результатам мы тоже решаем, имеет ли смысл брать это оборудование на тестирование.

Затем мы делаем внутреннюю рассылку «Новости R&D», где пишем, что начинаем тестирование такой-то железки. К нам приходят и просят заодно протестировать конкретные функции в определенных условиях и прочее.

Далее собираем рабочую группу из наших специалистов, архитекторов, специалистов из эксплуатации и вендора. Согласовываем с ними ПМИ и сроки.

Сам процесс тестирования строится так.

• Функциональное тестирование — проверка функций, позволяющих определить применимость оборудования или ПАК в инфраструктуре нашей компании.

• Нагрузочное тестирование — тестирование производительности синтетическими тестами, профили нагрузки которых эмулируют типовые и перспективные задачи в инфраструктуре компании, например, в публичных облаках.

• Тестирование отказоустойчивости — отработка отказов, время восстановления, деградация производительности при сбоях.

• Стресс-тест — оценивается работа под 100-процентной нагрузкой в течение 2 суток.

• Проводим оценку взаимодействия с вендором. Если вендор не идет на контакт, не хочет дорабатывать железо и исправлять баги, то с ним каши не сваришь. Важно оценивать способы взаимодействия не только при тестировании, но и при согласовании конфигурации тестового оборудования, и даже при организации доставки оборудования в ЦОД.

  Мы смотрим, выделяют ли нам технического специалиста со стороны поставщика или производителя под проводимое тестирование, которому мы можем напрямую задавать вопросы, например, про настройки, выявленные ошибки или некорректное поведение железа.

  Важна скорость ответа специалиста, его качество и полнота. Всегда смотрим, насколько содержательна техническая документация и доступна ли она для скачивания, а также насколько быстро вендор найдет документацию, если ее нет в публичном доступе.

По сути, мы вместе с вендором изучаем новое. Берем железо, которое никто никогда в глаза не видел, и вместе проходим настройку с нуля, ведь зачастую документации либо нет, либо она написана крайне плохо.

В процессе испытаний вендор не может порой объяснить, почему возникла та или иная проблема. То есть мы для вендоров выступаем как бесплатный испытательный полигон, ведь они даже не подозревают об ошибках, которые мы выявляем. Они делают патч, который исправляет эту ошибку, и отдают его уже всем своим клиентам.

Результатом тестирования становится отчет, в котором есть карточка объекта, схема стенда, описаны узкие места стенда (если есть), всякие особенности. Отчет используется при проектировании технических решений.

Приводим аналитику по полученным результатам функционального, нагрузочного тестирования и тестирования отказоустойчивости оборудования, отмечаем выявленные ошибки и нештатные ситуации в работе оборудования в процессе испытаний.

Отдельно указываем критические замечания, которые потенциально могут приводить к остановке работы оборудования, и в таком случае протестированное железо считается неприменимым в инфраструктуре компании до полного исправления вендором или разработчиком критических замечаний и завершения повторного тестирования оборудования. Мы их называем стоп-факторами применимости.

Повторное тестирование может быть проведено после исправления производителем всех критических замечаний, выявленных при первичном тестировании.

Если, допустим, СХД провалила один тест отказоустойчивости, то мы ее сразу признаем негодной и сообщаем вендору. Если он устранит проблему за неделю, то мы продолжаем испытание, если нет — прекращаем работу и берем на тест следующее оборудование.

При отсутствии критических замечаний формируем общий вывод о применимости протестированного оборудования в инфраструктуре компании и в проектах.

Потом мы рассылаем отчет о тестировании, и любой желающий сотрудник компании может прийти к нам с вопросами или комментариями.

Все отчеты по тестированию оформляем в презентацию и показываем на «Архклубе». Это неформальное мероприятие, которое проводится по теме одной железки.

Затем черед архитектурного комитета – Архкома. Это коллегиальный орган, где собираются эксперты и руководители отделов. Они обсуждают проект и принимают решение, использовать это оборудование или нет.

Заключение

Сейчас идет стадия становления полного импортозамещения, и мы помогаем нашим архитекторам и отделу эксплуатации повышать эффективность технических решений.

Мы хотим вывести нашу компанию в технологические лидеры, чтобы она достигла максимального уровня санкционной устойчивости и расширила портфель услуг.

В следующих статьях расскажем подробно, как мы тестируем СХД, сетевые технологии, серверы и ПАК.