Как мы запускали NVME over RDMA под Alt Virtualization p11 с Huawei Dorado 5000V6. Уроки импортозамещения

Pr.S. Поскольку пришлось начать с конца, то постскриптум тоже будет в самом начале, и он будет называться, например, pre‑scriptum.

Вообще‑то, эта статья планировалась последней в цикле технических статей, в которой по шагам планировалось изложить технические заметки о внедрении нами NVMEoF через ROCEv2.

Но потом подумалось, а ведь сам процесс, как это всё организовалось, происходило, и все пережитые эмоции, интереснее, чем чисто техническое изложение.

По заведённой здесь традиции, представлюсь. Меня зовут Алексей Лукин, я начальник отдела ИТ и связи, Иркутского филиала АО «Саянскхимпласт» и хотелось бы рассказать о нашем своеобразном, опыте, как мы у себя импортозамещали существующее оборудование, а именно: HPE C7000.

Называем вещи своими именами, перечисляем вендоров, персоналии, срываем покровы, приводим жареные факты, публикуем субъективные мнения и так далее

Часть 1. NVME over RDMA

Всё началось достаточно давно. HPE прислал предупреждение о снятии системы с сопровождения. Мы прикинули стоимость сервис‑паков, сервисных контрактов, посчитали дальнейшую стоимость эксплуатации и пришли к выводу, что пора поменять систему из 16 лезвийных серверов в корзине HPE с7000 с Microsoft Hyper‑V, на что‑то более новое.

Слева вид с фронта, справа — вид с тыла. За картинку спасибо ittelo, только у них такую красивую нашёл:

Для тех, кто с такими системами не сталкивался. HPE c7000 — это 10U корзина, которая с фронта набивается лезвийными серверами (или блейдами, от blade — лезвие) в количестве 16 штук. Всё это запитано от 10×2500W блоков питания. При холодном запуске, звук, издаваемый c7000, очень похож на взлёт Ту-134, со всеми звуковыми тонами.

Вот эти «сетевые модули» с задней стороны‑ это проходной Ethernet (passthrough) с блейдов на коммутаторы, для подключения серверов к сети Ethernet рабочих станций, а также выход SFP FiberChannel (FC) для подключения блейдов к сети SAN по оптике. Каждый блейд подключён в обе сети, что, в общем, логично. Там ещё видно CX4, но на серверах мы ими не пользовались.

Изначально c7000 работал с 2 шт. СХД HPE EVA4400 по чистому FC. Со временем её заменили на HPE 3par 8200 c Full Flash SSD тоже на FC, а EVA подарили в Иркутский Политех.

На что менять?

Конечно же, смотрели в первую очередь в сторону HPE Synergy, но с началом определённых событий, всё это стало не очень доступно. Поставщики, конечно, всё могли привезти, но оставались сложно закрываемые вопросы по гарантии и запчастям. К тому времени мы уже примерно понимали, как устроено теневое закулисье китайских ОЕМ, делавших существенную часть оборудования для многих вендоров A‑класса.

«Единственное, что нас беспокоило — Это FiberChannel»

Транспортная сеть

И хотя к этому мему всегда постят картинку с Джонни Деппом, но нет, на самом деле, не особо она и беспокоила. Хотя, конечно, у этой технологии, есть свои минусы и плюсы:

Плюсы:

• Хорошо проверенная временем, технология для построения сетей хранения данных (SAN).

• Сеть без потерь. Все пакеты гарантированно доходят от отправителя до адресата.

• Применение оправдано при большом количестве уже существующего FC‑оборудования. Если у вас стойки с FC SAN уходят за горизонт, однозначно про неё стоит подумать.

Минусы:

• Несовместима с обычным Ethernet и, как следствие, это полностью отдельная сеть.

• Эксплуатация требует отдельных компетенций у специалистов, потому что это не Ethernet.

• Высокая стоимость в пересчёте на порт (5–6 раз) vs Ethernet на той же скорости.

• На практике, из‑за больших начальных вложений, многие лицензии на FC покупались по мере необходимости. Сейчас надо заказывать всё сразу, иначе потом все дополнительные приобретения могут оказаться очень сложными.

Немного истории

FC за последние десятилетия, неоднократно пытались потеснить на рынке. Похоронная команда FiberChannel, в разные годы, состояла из FCoE, Infiniband и iSCSI.

Тем не менее, после каждых похорон FC умудрялся выходить из могилы и, как настоящий зомби, продолжал наводить панику по округе. Определённое спокойствие всё‑таки наступило, и каждая из технологий определилась со своей нишей:

• FC — корпоративные СХД с высокой доступностью и надёжностью. До сих пор работает.

• FCoE — конвергентный FC over Ethernet, на который возлагалось много надежд, фактически умер, и FC реально простудился на его похоронах. Хотя у некоторых вендоров до сих пор есть поддержка на эти системы.

• Infiniband (IB) — кластеры HPC и AI (Поскольку Nvidia купила компанию Mellanox, то эта технология сейчас является базовой для приложений), хотя на основе IB пытались даже делать СХД для корпоративного применения. На основе её сигнализации сделали тот самый Ethernet 10GbaseCX4, но, с удешевлением оптических модулей SFP+, он также ушёл в закат.

• iSCSI — Стал дешёвым массовым стандартом. Де‑факто для NAS и многих СХД любого уровня, начиная с домашних. Массовая реализация началась после того, как iSCSI инициатор был включён в MS Windows Server 2012, хотя поддержка в качестве отдельного пакета была реализована уже в WS 2008.

И если вы дочитали до этого места, то вполне имеете право сказать: «Так падажжи, падажжи…». Это же всё транспортные протоколы, а FCoE — даже транспорт поверх транспорта, кроме iSCSI. Тот вообще прикладной протокол поверх TCP.

Всё правильно. Именно так оно и работает.

Поэтому возник простой вопрос: а если у вас планируется использовать всего пару‑тройку другую СХД, нужен ли там FC? И есть ли сейчас полноценная замена? Ну так, чтобы дёшево, сердито и без вот этого всего.

Ещё один шаг в сторону. Вспомнить всё про NVME

На всякий случай напомню основное отличие NVME‑дисков от SAS — это используемый протокол и количество очередей команд. Для NVME 65 536 очередей и 65 536 команд в очереди. Для SAS (AHCI) — 1(одна) очередь с 254 командами. SAS всегда подключается через отдельный Host Board Adapter (HBA), контроллер NVME устроен проще и подключается напрямую к 1,2 или 4 линии PCIe.

На одну условную операцию чтения SAS требует около 200 команд, тогда как NVME — около 40. Микросхемы памяти в дисках, плюс‑минус, те же самые.

Опять же SAS дисков вы можете подключить больше, чем NVME. Количество PCIe линий в системе ограничено.

Поэтому ниши между этими устройствами также распределены: NVME — быстрые данные, SAS — медленные

Как и iSCSI, NVME умеет работать поверх сетевого транспорта (технология NVMEoF — NVME over Fiber):

1. NVME over Fiber Channel — привычно, понятно, надёжно и, конечно же, недёшево.

2. NVME over TCP — недорогая альтернатива FC с использованием стандартного TCP/IP стека, для которого не требуется ни специальных карт, ни коммутаторов. (iSCSI, привет!).

3. NVME over RDMA — тот самый вариант (Mellanox ROCEv2 или Intel iWARP), который нам показался интересным.

Но и в RDMA тоже есть два транспорта:

1. ROCEv2 (RDMA over Converged Ethernet. Разработан в Mellanox, теперь входит в состав Nvidia), работает в обход стандартного TCP стека.

2. iWARP (Internet Wide Area RDMA Protocol. Отцы‑создатели — компания Intel), работает через стандартный TCP стек.

Картинка из старого документа компании Intel:

Видно, что упоминается ещё RoCEv1. Это самая первая реализация RoCE, L2 протокол, который хорошо работает в пределах VLAN (кстати, он имеет свой тип фрейма) и у него проблемы проброса за пределы локальной сети, потому что это IB over Ethernet. Некоторые вендоры его иногда до сих пор вспоминают в технических бюллетенях.

Присутствует уже упомянутый RoCEv2, работающий через UDP. Infiniband внутри RoCEv2 тоже есть: передача делается через пары очередей, как это принято в IB и «словами» (verbs). IB нагрузка упаковывается в Ethernet. Эта реализация от приложений скрыта.

Протокол iWARP (Intel). Конечно же, он поддерживается интеловскими картами и некоторыми СХД. Microsoft также за него поначалу впрягся, но несмотря на благоприятный старт, большого распространения этот протокол не получил. Хотя имеет свои интересные особенности — для iWARP не нужна поддержка на коммутаторах.

NVME over ROCEv2 быстрее, чем NVME over TCP или iWARP. В зависимости от задач, разница может составлять до 30%.

Да, есть ещё прикладной протокол NFS over RDMA. Некоторые NAS его поддерживают, но это не наш случай.

Сетевые карты для RoCEV2 делают три основных производителя:

• Mellanox, карты серии CX (ROCEv2)

• Broadcom, карты NetXtream (ROCEv2)

• Intel, карты E810 и др. (ROCEv2+iWarp)

Есть ещё такой производитель как Chelsio Communications, изначально топивший за iWARP, но потом быстро перекинувшийся в лагерь RoCEv2. Карты на основе ASIC Mellanox сейчас делают китайцы — LR‑LINK. У них есть доступ к этим чипам.

Мы для себя выбрали Mellanox CX-5 (2×100GbE) — это относительно недорогие карты, доступные на рынке. А почему? Потому что…

СХД

Вот почему. У карт СХ-5 есть ещё разные p/n, и нужно было выбрать те, что были в списке совместимости с Huawei Dorado 5000V6.

Почему Dorado? Фактически Huawei Dorado — это единственный доступная СХД, производимая вендором A‑класса. Я не буду говорить, через кого мы его купили, чтобы случайно не «спалить контору». Наши коллеги из компании Слата (г.Иркутск), дали о ней хорошие отзывы, правда, они её не использовали в RDMA режиме.

СХД впечатлила комплектацией. Я давно уже не видел в комплекте таких приятных мелочей, как антистатические перчатки и браслеты, щипцы для извлечения SFP/QSFP модулей. В комплекте даже были два медных 100GbE патч‑корда.

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

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

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

Про Dorado в планах написать отдельную статью, особенно по её CLI, потому что она не такая простая СХД, как может показаться на первый взгляд.

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

Ещё рассматривался Infortrend EonStor DS 4024U, даже были на референсе у одного дистрибьютора и посмотрели на неё живьём, но в ней нас смущали некоторые моменты:

1. У неё нет полноценной CLI‑консоли (по крайней мере, на то время). Через терминал была доступна стартовая форма с простыми установочными действиями.

2. На вопрос: «А как работает RDMA?», последовал ответ: «достаточно на неё поставить более чем 96GB RAM и RDMA „запускается автоматически“». Маски в самолёте выпадают в точности так же.

3. NVME‑диски для EonStor требовались только Kioxia с адаптированной Infortrend прошивкой, то есть классический vendor‑lock. Они это мотивировали тем, что не всякая Kioxia хорошо исполняет в EonStor и нужен отбор. Каких‑то отличий, кроме x2 цены, замечено не было. Исключая NVME диски, EonStor был всеяден, хотя свои списки совместимости по контроллерам, памяти и картам у него тоже есть.

Dorado, правда, тоже работает на кастомных дисках, это собственный конструктив Huawei Palm Disk NVME. Оправдано это только плотной упаковкой дисков, китайцам удалось на передней панели разместить 36 дисков в 2U, против стандартных 24. Есть вариант исполнения Dorado на SAS дисках, вот в ней их тоже 24. Смотрите, не перепутайте!

Вот так это выглядит. Сверху — Dorado 5000V6 NVME, снизу 3par 8200 Full Flash SSD SAS:

И мы уже были готовы подписать договор на поставку Infotrend EonStor, как Infortrend свернул все операции в РФ и растворился в сиреневой дали.

«Вот и верь после этого людям, о любви говорил при Луне…», после чего была куплена Huawei Dorado.

Китайцы немного ошиблись с комплектацией СХД и прислали поначалу с обычными 100Gb Ethernet картами. Dorado сказала: «iSCSI — нихао, RDMA — пухао», в смысле с «iSCSI работать — это всегда, пожалуйста, RDMA — давай, до свидания!». Проверили все спецификации у нас и поставщика — это была ошибка при сборке. Поменяли они их достаточно быстро, недели за две. А за это время мы поработали с Dorado как c большой и шустрой iSCSI‑целью, пособирали в LACP 100GbE интерфейсы (почему бы и нет?), проверили, как с ними работает MLAG на коммутаторах. Всё работало как положено.

Коммутаторы

Повторюсь. Если для iWARP или NVME over TCP поддержка на коммутаторах не требуется, то для NVME over ROCEv2 она обязательна. RDMA должно поддерживаться в ASIC на коммутаторе.

Для RoCEv2 нужна настройка PFC (Priority Flow Control — управление приоритетом трафика) при помощи PCP(L2) или DSCP (L3) (ETS). Должна поддерживаться передача сообщений об управлении трафиком (ECN). 

Это всё необходимо для полноценной работы «Ethernet без потерь», или lossless Ethernet. У новых ASIC Broadcom, емнип, начиная с Tomahawk IV, есть ещё DLB — Dynamic Load Balancing, для избежания перегрузки по некоторым путям передачи.

Поддержка DCBX (модифицированный LLDP) — это плюс, но если у вас не очень большой дата‑центр, то работать будет и без него.

Также коммутатор должен иметь на борту много быстрой, коммутаторной памяти. При включении RDMA под буферизацию легко отнимается около 40% RAM.

Поскольку у нас в поле зрения был Huawei, то, конечно, было бы проще всё сделать на оборудовании одного вендора (к чему дорогие товарищи Hewlett и Packard нас приучили), но вот незадача, интересные нам модели CloudEngine были плохо доступны.

Так, в поле зрения попали Qtech 6600–32 и Sofinet 8500–32, внешне выглядевшие как близнецы‑братья. Кто прародитель у «Котиков» они так и не сознались, хотя они могли использовать труды ODM, продукцию OEM на заводе DCN (но это ничем не обоснованные предположения, конечно же!). А вообще, все российские производители любят говорить: «Мы всё сами изготовляем!», на что приходится отвечать: «А мы в это охотно верим, ага!»

Внутри Qtech стоит ASIC Broadcom Trident III, RDMA поддерживает. Под санкциями ли Broadcom? Ну так… вообще‑то, не очень.

C продукцией Sofinet всё оказалось интереснее. В девичестве это Maipu NSS5950-32QFP. К этому моменту уже было известно, что всю сетевую продукцию для очень многих мировых брендов делают три основные китайские компании: DCN, Ruijie и Maipu, в промежутках мелькают H3C и прочие мелкие (по китайским меркам) другие компании. Результаты их трудов вы найдёте под марками Dell, HPE/Aruba, D‑Link, TP‑link, SNR и очень многих других.

Maipu использует ASIC под названием TsingMA, производства Centec. Эти чипы представляют собой лицензированные копии Broadcom Trident III (и, видимо, более свежих Tomahawk, потому что у Maipu есть и 200G и 400G оборудование), а также есть свои лицензированные версии Marvel и Realtek — для коммутаторов попроще.

На самом деле там ситуация ещё запутаннее. Centec — дочка Maipu. И (тадамм!), они ещё делают свои коммутаторы, на сайте производителя они фигурируют.

Есть сложившаяся практика, что производитель ASIC не изготовляет сетевого оборудования, они максимум работают как ODM (Original Design Manufacturer) — определяют типовые схемы включения своих чипов, разводку компонентов на плате, делают макетные платы со своими ASIC, разрабатывают SDK и консультируют сторонних разработчиков, которые как раз занимаются созданием коммутаторов на их платформах.

Впрочем, если эти коммутаторы расходятся по сети badge‑engineering производителей как продукция OEM, то им претензий за использование преимущественного положения на рынке никто предъявлять не будет.

Особых претензий к Sofinet 8500 нет. Техподдержка адекватная, отвечают быстро и по сути, даже на непростые вопросы.

Есть недочёты по эргономике и комплектации самих коммутаторов:

1. Вся индикация сделана на LED одного цвета. Даже за индикацию работы блоков питания отвечают два LED на морде, и они оба имеют тусклый зелёный цвет. При имитации аварии по питанию, например, извлечение БП из корпуса или отключение силового кабеля, коммутатор не начинает угрожающе моргать большой красной лампой, как это делает древний HPE Procurve 2910, у него просто тухнет один зелёный светодиодик! Попробуй заметить при утреннем осмотре оборудования. Спасёт только мониторинг по SNMP, только хард‑кор!

2. Коммутаторы глубокие и тяжёлые, у Maipu предусмотрены для них установочные рельсы, регулируемые по длине на всю длину стойки. У Софинет, натурально, только уши приехали. Чтобы мы делали без ещё одних китайцев — никому не известных изготовителей торгового оборудования, которое продавалось чуть ли не с 90-х годов. Система называется Vertical (под этим обозначением их можно найти до сих пор на Ozon, например). Совершенно случайно шаг их кронштейнов для ДСП полок, совпадает с высечными отверстиями на стойке (всё‑таки требуется небольшая доработка напильником):

   

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

4. Нормальной практикой для поиска в стойке является команда locate chassis, когда на морде коммутатора начинает моргать светодиод определённого цвета, например, синего. У Софинет тоже такого нет. Нет проблем, если их в стойке всего 2, а если 42?

   Хотя сам по себе девайс очень и очень неплохой. Никаких сожалений о приобретении.

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

Серверное хозяйство

Мы смотрели много железа.

Нам предлагали NERPA, а это оригинальные серверы с другим безелем на морде, но по документам всё «ок» и ценник ощутимо больше, чем оригинал. Вопросы с гарантией и запчастями, если они возникали, то имели ответы, начинавшиеся с «Ну, вы же понимаете…». Мы всё понимали. Решили не рисковать.

Рассматривали производителя Inspur, тот был сумбурен — вроде бы в РФ зашёл, а потом так же резко ушёл. Хотя, казалось бы, государственная компания. Нет.

Своим пришествием облагодетельствовало Yadro, ребята пытались агрессивно продать свои серверы за какие‑то невероятные деньги, но объяснить, чем их железо отчаянно хорошо за эту цену, так и не сумели.

Тестировали Inferit — всё было бы ничего, но то, что привёз Софтлайн — это уже на момент теста была устаревшая модель с DDR4, укомплектованная очень жиденькими рельсами для 2U. При выкате сервера Inferit в сервисное положение существовал неиллюзорный риск согнуть направляющие, с последующим падением инженеру на ноги. Мы не хотели рисковать и подкладывали под сервер коробки.

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

В итоге сошлись на том, что в него были случайно приложены рельсы от 1U (Как так?).

Для Softline был написан подробный отчёт с картинками. Обновлённую версию серверов Inferit, нам так показать и не сумели. Увы, но нет.

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

Серверы Qtech. Они были неплохи. На тест серверы приехали в совершенно шикарных ящиках из чистой фанеры, с металлическими уголками, с прочными, ухватистыми ручками. Фото, увы, не сохранилось. Конструкция мощная и надёжная, как бабушкин сундук (здесь фоном поётся джингл Севы Новгородцева из службы BBC, но это, если честно, для совсем олдовых олдов, так что эта реплика отметается как неорганизованная). На самом деле это нормальная история для тестового оборудования. Вот как у Qtech — оно такое и должно быть.

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

Поставку отрабатывали с несколькими потенциальными поставщиками.

Компания Зеон (Владимир Оськин, г.Иркутск) задал вопрос: «а почему бы не посмотреть серверы сборки iRU?». Про iRU я помнил, как про некоторые ноутбуки, которые мы как‑то раз покупали очень давно, в середине 2000-х, потому что денег сильно не было. Но почему бы и нет?

Парни из iRU были достаточно честными. «Реестр — это не к нам, но, если вам нужен адекватный китаец, с поддержкой в течение длительного времени, длительной гарантией (при необходимости) и относительно быстрыми заменами — это к нам». Китайца звали Gooxi.

Так что, с некоторых пор, «жили у бабуси три весёлых Gooxi — один серый, другой серый, третий — непонятный» в составе (Gooxi G2DLR0 AMD Epic 7004 48 ядер x2 = 96 железных ядер на сервер, 768 GB DDR5 RAM)x3 — поставщик Зеон.

Вскрытие серверов показало, то же самое, что мы видели у одной компании на букву Q, в сервере которой были полностью заклеены логотипы на матери и ценник почти в 2 раза дороже. А если нет разницы… то, действительно, зачем платить больше?

И да, поскольку рельсы стали для нас больным вопросом, по опыту Inferit, мы их внимательно осмотрели. У Gooxi OEM rack‑mount‑kit — Accuride. Это, вообще‑то, американская компания, которая делает выкатную фурнитуру для чего угодно, начиная от кухонных ящиков, заканчивая решениями для очень увесистых промышленных конструкций. Стоечные серверы — где‑то в промежутке.

Рельсы Accuride были очень неплохи. Хороший, толстый металл, который даже слона выдержит, но вылез небольшой нюанс.

Чтобы рельсы немного расслабить и отрегулировать по длине стойки, надо открутить на каждой рельсе сбоку, по две гаечки. Одна гаечка упала, и мы не стали её искать — гаек, что ли, нет? Это было жесточайшей ошибкой: гайка М4 на резьбу не заходила, а М5 легко надевалась. Так, мы случайно узнали, что гайки на рельсах — дюймовые 11/32«. И резьба под гайкой тоже дюймовая. М4 закручивается на один виток и дальше никто никуда не идёт. »

На рельсах красовалось MADE IN CHINA, казалось бы, вот он — метрический Китай, и где дюймовые резьбы США и ВБ, а вот поди же ты…

Гаечку нашли, и всех предупредили: не дай бог, кто‑нибудь отвернёт эти гайки полностью!

В итоге всё было помещено в стойку, а мы перешли к следующему пункту:

Что поставить сверху всего этого?

Конечно же, мы этот вопрос изучали параллельно и сильно заранее. Нам была нужна замена Hyper‑V. Я лично слышал массу хороших отзывов от моего коллеги из компании Форус (г.Иркутск) Дмитрия Заиграева в отношении Proxmox Virtual Environment (PVE). Однажды в нашем клубе юных айтишников (сообщество IT‑директоров г.Иркутска) он делал подробный доклад на эту тему, чем и окончательно обратил в свою веру. Развернуть несколько десятков серверов под конкретные задачи в связке PVE+Debian было достаточно легко.

Но поскольку в мире PVE всё было устроено несколько по‑другому, чем в Hyper‑V, то нам была очень нужна поддержка.

Поэтому пришлось внимательно посмотреть, что у нас есть на рынке.

SpaceVM (ООО ДАКОМ)

Ребята, видимо, хорошо вкладывались в PR, потому что в 22–23 году — они звучали из каждого утюга, то есть телеграм‑канала о виртуализации и импортозамещении. Почему бы и не попробовать? Тем более что они клялись сделать поддержку RDMA, вот, прям, в ближайшем будущем.

Скачали, развернули пилот. Выглядит SpaceVM интересно, но странновато. Некоторые кнопки интерфейса находятся в середине экрана, ну это половина беды, хотя я на юзабилити всегда внимательно смотрю. Другое дело, что по мере тестирования, появлялись вопросы всё сложнее и сложнее, а техподдержка SpaceVM отвечала всё медленнее и медленнее.

Вроде бы ничего не предвещало проблем, но внезапно разваливается весь наш пилотный кластер. У той версии, которая была у нас в руках, сеть кворума (через которую хосты обмениваются информацией о своём состоянии) собиралась на… BMC‑интерфейсах!

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

«Штааа?бабка.jpg». Вы серьёзно? На пилоте?

Не очень была понятна позиция вендора SpaceVM. Заработать денег на ТП в пресейле? Вообще‑то, у нас ещё смотрины, на уровне «у вас товар, у нас купец», о свадьбе говорить было ещё очень рано.

По телефону задаю другой вопрос: «Хорошо, был бы у нас с вами контракт, вы бы сумели решить проблему? От наличия денег у вас появятся какие‑то знания? Или вы будете просто быстрее гуглить  суетиться?»

В ответ, увы, ничего логически связного нам так ответить и не смогли. SpaceVM — отказать.

zVirt (OrionSoft)

Здесь до тестов даже дело не дошло, запросили стоимость их лицензии и присвистнули от удивления. К этому моменту мы уже достаточно хорошо понимали, что нам продают, а продавали нам нечто, на базе опенсорса, за какие‑то произвольные цифры. Всё понятно — все хотят есть, и всех специалистов надо содержать, но такая разница в цене должна быть как‑то логически объяснима. Голосом Каневского: «Никакой логики, в объяснениях, конечно же, не было».

ROSA Virtualization (АО «НТЦ ИТ РОСА»)

Начали пилот. Столкнулись со сходными проблемами, как и со SpaceVM. Ценник за лицензию в два раза дешевле, чем zVirt, но тоже странный, и непонятно за что. Вылезли проблемы на пилоте (ошибка 881, про которую речь будет дальше), и разговор свернул на ту же тропу, как и ранее: «А был бы у вас контракт на поддержку, всё сложилось бы иначе», «А были бы у вас нужные навыки, то подсказали бы, что делать».

«Нет, ребята, с таким настроением вы слона никому не продадите» ©

Пожелали им «творческих узбеков» и решили не связываться.

Недели через три, на связь вышел их менеджер, в надежде всё исправить, но ROSA Виртуализация уже плыла по реке забвения, с уклоном 0.5 градуса на метр.

Astra (“Группа Astra”)

Наши коллеги с завода пытались наладить тестирование с Astra. Очень распространённая система, но отношения не сложились, чем сложнее вопросы, тем дольше ответы и меньше желание поставщика этим заниматься. Отказались.

Vmmanager (теперь тоже «Группа Астра»)

Я очень хотел его потестировать лично, потому что делали этот продукт в Иркутске, и потом удачно продали в Astra. Но наши коллеги с промплощадки вынесли свой суровый вердикт: много чего надо грубо подгонять напильником и тонко дорабатывать зубилом. Нет.

vStack (ИТглобалком Лабс)

Одна из систем виртуализации была на FreeBSD — vStack. Они очень любили Ceph и не поддерживали внешние СХД. Я очень хорошо отношусь к фре, но нам такую экзотику было не надо.

Предварительные итоги

Мы вышли примерно туда, откуда начали, и как в том анекдоте, «оказались снова на Дерибасовской».

Резервный план был понятен: Debian+PVE. И если с Debian мы бы ещё справились, то с PVE нужен опыт, которого не было. И нам была нужна постоянная поддержка. Мы же не можем позволить нашим сервисам стоять, если что‑то пошло не так. Обратились в Форус, потому что они по этой теме работали давно, но они честно сказали: «Дать совет и проконсультировать в частном порядке — да, а вот отвечать за ‘вот это ваше всё’ — однозначно нет».

За всеми нашими движениями молча следил Зеон, его специалистов мы добавляли в ТГ‑чаты пилотирования с каждым новым вендором ПО. Им тоже была небезразлична судьба оборудования, оказавшегося в наших руках. Они предложили базальтовскую Alt Virtualization.

Alt Virtualization p11 (ООО «Базальт СПО»)

Если вы айтишничали в 90-е, то про Alt / Mandriva точно слышали. Слышал про них и я, но Alt и наша инфраструктура — поначалу даже в голову не приходило, что эти буквы, в принципе, могут стоять рядом.

Близкое знакомство показало:

1. Alt Linux, на самом деле, живее всех живых.

2. Самая недорогая лицензия из всего, что есть на рыночке. (Это факт. Соберите ТКП со всех). Дешевле только бесплатный Debian.

3. С поддержкой всё примерно то же самое, что плюс/минус у всех на рынке. Тем не менее выделенный инженер на три хоста за один год обойдётся дороже, это мы посчитали сразу.

Продукт Alt Virtualization р11 — это предустановленный PVE, который работает из коробки, и не меняет ядро в целевой системе на собственное, иногда это важно.

И главное — Базальт поступил не так, как все: назначил со своей стороны выделенного менеджера, Николая Мальцева, а также в качестве первой линии поддержки назначил компанию Зеон, потому что у них был необходимый опыт. Это нам сильно помогло в дальнейшем.

Кроме того, у Alt оказался самый простой и быстрый инсталлятор. В качестве основной файловой системы для установки виртуализации предлагается зеркало на BTRFS. Непривычно, но сто́ит попробовать, BTRFS быстрее, чем linux raid (md).

Во время суровых тестов у нас как‑то получилось это зеркало на нём разломать, так что теперь существует отдельная инструкция по восстановлению BTRFS. Она далека от полной, но вполне имеет право на жизнь.

«И заверте…»

То, чем мы занимались — это полноценный проект.

PMBOK (свод знаний по управлению проектами от PMI) объясняет это правильно и скучно: проект — это вре́менное предприятие, направленное на создание уникального продукта, услуги или результата. Если вы делаете это повторно — это уже (мало) серийное воспроизводство вашего результата.

Главные признаки проекта:

• Временный характер. Определённые даты начала и окончания.

• Уникальность. Получаемый результат отличается от других.

• Ограниченность ресурсов. Время, деньги, люди.

Во всех этих определениях не хватает одной важной вещи: любой проект, это всегда неопределённость. Если вы делаете что‑то новое: осваиваете новую технологию, оборудование или софт — неопределённость крадётся за вами следом, как тень. Оттуда возникают все риски и угрозы. Чем больше вы знаете о предметной области, тем меньше тёмных пятен, но их невозможно ликвидировать полностью. И каждое из них может вам доставить немало неприятных моментов. Более того, вы смотрите на ваши теоретические представления о предмете, и в них всё кажется кристально чистым и понятным, но, когда дойдёте до практики, всё изменится.

Неопределённость — это суслик из «ДМБ». «Видишь суслика? И я не вижу… А он там есть!»

Идеальным куратором нашего проекта был бы «Кирпич»:

Мы относительно быстро разобрались с нюансами настройки серверов и начальных настроек ОС — здесь нам хорошо помог Зеон.

У Huawei хорошая документация по СХД Dorado, даже есть отдельный том по NVMEoF, но это не про Alt Linux — формально, для них это неподдерживаемый дистрибутив. Читаем про RHEL и Debian, натягиваем мысленно на Alt.

Чтение доков показало, что китайцы очень старались, создавая Dorado. И хотя местами прорывался Chinglish, к документации они тоже подошли очень аккуратно. Конечно же, нашлись места, где документация Huawei не соответствует действительности, а кое‑где они упустили описание ряда моментов просто потому, что посчитали это само собой разумеющимся. Например, RDMA линки не собираются со стороны СХД в LACP, а линки с одного контроллера СХД нельзя размещать в одном и том же VLAN и прочее.

Первая попытка обнаружения СХД по сети (nvme discover) завершилась не так, как планировалась. Так, мы столкнулись с тем, что впоследствии было названо Dorado empty bogus page. СХД отвечала по сети, но не возвращала имя своей цели (NQN — NVME Qualified Name). В сетевой реализации NVME, nqn — это то же самое как iqn в iSCSI.

Пример проблемного вывода:

nvme discover ‑t rdma ‑a 172.16.144.35 
Discovery Log Number of Records 1, Generation counter 2 
=====Discovery Log Entry 0======
trtype: fc
adrfam:
subtype: unrecognized
treq: not specified
portid: 0 
trsvcid:
subnqn:
traddr:
eflags: none

После проверки на других дистрибутивах (Astra 1.8.4(Debian 9), Debian 12 (Bookworm), Debian 13 (Trixie)), обнаружилось, что у них такой проблемы нет.

Пример правильного вывода, c Debian 13:

nvme discover ‑t rdma ‑a 172.16.143.35 
Discovery Log Number of Records 1, Generation counter 2 
=====Discovery Log Entry 0======
trtype: rdma
adrfam: ipv4 
subtype: nvme subsystem
treq: not specified
portid: 1 
trsvcid: 4420 
subnqn: nqn.2020–02.huawei.nvme:nvm‑subsystem‑sn‑xxxxxxxxxxxxxxxxxxxxxx
traddr: 172.16.144.102 
eflags: none
rdma_prtype: roce‑v2 
rdma_qptype: connected
rdma_cms: rdma‑cm
rdma_pkey: 0×0000 
[root@host2 ~]#

xxxxxxxxxx — здесь находится серийный номер СХД.

Мы напрягли ТП Alt и ТП дистрибьютора Huawei, но, к сожалению, хоть они и очень постарались, но ничем не сумели помочь.

Пришлось разбираться самостоятельно. Долгое сравнительное изучение показало, что Debian до сих пор использует старую версию подсистемы linux‑nvme 2.3, вместе с библиотекой libnvme 1.3, вместо новой 2.15, которая использовалась в Alt.

ТП Alt прислала заниженную (как Лада Седан‑Баклажан!) версию linux‑nvme 2.3, с инструкцией по «прибиванию гвоздями», чтобы случайно не обновить её. Все системы Linux хорошо обновляются, а вот понижение версий (downgrade) всегда требует бубна и камланий.

Стало очень интересно, а как выглядит сетевой трафик в обоих случаях, и здесь выяснилось, что это нетривиальная задача. У каждой карты Mellanox CX-5 в системе есть два драйвера. Один отвечает за работу Ethernet в целом — ensXfXnpX, а ещё есть ROCE часть — драйвер rocepXsXfX

Так как трафик идёт в обход сетевого стека, то стандартный Wireshark, установленный на зеркальном хосте, поймать ничего не может. Более того, с некоторых пор, Mellanox решил, что трафик с ROCE драйвера собирать сторонними средствами нельзя и старые инструкции, которых было много в интернете, оказались нерабочими, а Perplexity AI несла убедительную ахинею, основываясь именно на этих инструкциях.

Но решение есть. У Mellanox выложен автономный образ контейнера, позволяющий эту задачу решить. Ставится контейнер, а вот из контейнера есть доступ к сбору пакетов с ROCE‑драйверов. Так, у нас появилась ещё одна инструкция — как собирать RDMA‑трафик с сетевых интерфейсов.

Что удивительно — перехваченные отправляемые пакеты на СХД, как в старой, так и в новой версиях подсистемы linux‑nvme, были полностью идентичны, но ответы от СХД были разные. Проблема была в чём‑то другом.

Вопрос с кривым nvme discover на время оставили, благо nvme connect отрабатывался как положено, и СХД, свои нарезанные LUN, презентовало на хосты.

Но с презентацией тоже была незадача. Подсоединение к СХД (nvme connect) отрабатывалось, но не работал мультипассинг. Система виделась только по одному пути.

MPIO — multipath input/output, он же мультипассинг, нужен чтобы к СХД с каждого хоста был доступ минимум по двум избыточным путям. При исправности всех путей решается вопрос расширения пропускной полосы, а если один из путей станет неисправен, то в этом случае обеспечивается резервирование. Perplexity AI использовала термин «мультипутёвость» — почему бы и нет?

Для Linux есть свободная система MPIO под названием dm‑mapper. Некоторые производители СХД предоставляют для Linux свои подсистемы мультипассинга. У Dell — Omnipath, своя подсистема есть у IBM (хотя с некоторых пор, они рекомендуют пользоваться общедоступным dm‑mapper), Huawei — не исключение, у него есть свой Ultrapath, и набор скриптов для работы со своей версией MPIO. Китайцы утверждают, что Ultrapath работает лучше, но и против dm‑mapper возражений не имеют, это отражено в их документации, хотя и без особых подробностей. Ultrapath на Alt не поддерживается, но по всем признакам, потратив определённое количество времени, его туда можно прикрутить.

ТП Alt прислала инструкцию по настройке и проверке мультипассинга. Первой мыслью было: где‑то я это уже видел. Нечто подобное я находил в недрах форума Mellanox (а инженеры Mellanox его читают и в него пишут) — это была инструкция по настройке nvme инициатора и цели. Пошаговое выполнение инструкции к включению MPIO в системе не привело. Ответ ТП Alt был шикарен: «А у нас на стенде всё работает!» «А у нас, хе‑хе, нет!», — отписался я.

Только благодаря менеджеру проекта со стороны Базальт (Николаю Мальцеву спасибо и большая благодарность за это) у нас как‑то получалось продвигаться по сложным вопросам. Не знаю, какими способами, но он сумел мотивировать техподдержку внимательно относится к нашей переписке.

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

После внимательного изучения стало понятно, что в Alt Linux по умолчанию включено два драйвера (подсистемы) MPIO: первый — в ядре, второй — dm‑mapper. Последний ставится вместе с дистрибутивом из коробки, и при этом не проверяет наличие мультипассинга в ядре, и они мешают друг другу. Захватить путь к цели (сделать takeover) не может ни тот ни другой. «В живых остаться должен только один!».

После отключения мультипассинга в ядре, система, через dm‑mapper, сразу же увидела 4 пути до каждой цели. Сообщили в Alt, чтобы эта информация не потерялась.

root@host2 ~] multipath ‑l
eui.7100fa95d65907e148bd4a220000000a dm-0 NVME,Huawei‑XSG1 
size=200G features=“1 queue_if_no_path” hwhandler=‘0’ wp=rw
`‑± policy=“round‑robin 0” prio=0 status=active
|‑ 3:263:1:1 nvme3n1 259:4 active undef running
|‑ 4:1:1:1 nvme4n1 259:11 active undef running
`‑ 5:261:1:1 nvme5n1 259:16 active undef running
eui.7100fa95d65a1c9748bd4a490000000b dm-2 NVME,Huawei‑XSG1 
size=4.9T features=“1 queue_if_no_path” hwhandler=‘0’ wp=rw
`‑± policy=“round‑robin 0” prio=0 status=active
|‑ 3:263:2:2 nvme3n2 259:5 active undef running
|‑ 4:1:2:2 nvme4n2 259:12 active undef running
`‑ 5:261:2:2 nvme5n2 259:18 active undef running
eui.7100fa95d65f31f648bd4a9a0000000c dm-1 NVME,Huawei‑XSG1 
size=1.4T features=“1 queue_if_no_path” hwhandler=‘0’ wp=rw
`‑± policy=“round‑robin 0” prio=0 status=active
|‑ 3:263:3:4 nvme3n3 259:6 active undef running
|‑ 4:1:3:4 nvme4n3 259:9 active undef running
`‑ 5:261:3:4 nvme5n3 259:15 active undef running
eui.7100fa95d6d57f6f48bd4a0c0000000e dm-3 NVME,Huawei‑XSG1 
size=550G features=“1 queue_if_no_path” hwhandler=‘0’ wp=rw
`‑± policy=“round‑robin 0” prio=0 status=active
|‑ 3:263:4:3 nvme3n4 259:7 active undef running
|‑ 4:1:4:3 nvme4n4 259:10 active undef running
`‑ 5:261:4:3 nvme5n4 259:14 active undef running

Ошибка 881

Она заслуживает отдельного раздела. Я уже упоминал, что у нас было три Gooxi, два были, как обычно, а третий — непонятный.

Все попытки выполнения nvme discover или nvme connect на host1 приводили к возникновению ошибки 881 в системном журнале и отсутствию всякого соединения с СХД.

[root@host1 ~]# nvme discover ‑t rdma ‑a 172.16.144.35 
failed to add controller, error failed to write to nvme‑fabrics device

Иногда может выводиться:

Failed to write to /dev/nvme‑fabrics: Input/output error
failed to add controller, error failed to write to nvme‑fabrics device

В dmesg при этом регистрируется информация вида:

nvme nvme2: I/O tag 0 (0000) opcode 0×7f (Fabrics Cmd) QID 0 timeout
nvme nvme2: Connect command failed, error wo/DNR bit: 881 
nvme nvme2: failed to connect queue: 0 ret=881

Эта ошибка попортила немало нервов и отняла очень много времени. Реально с ней пришлось возиться несколько месяцев.

И получалась только на одном сервере — host1.

Host2 и host3 работали без замечаний, а поскольку у нас была обменная база в виде ещё двух идентичных серверов, были поменяны местами почти все компоненты: сетевые карты, модули памяти, платы PCIE экстендеров, их кабели и даже блоки питания. Переставлялись загрузочные NVME диски, на них заново ставилось ПО — проблема оставалась. Достали из запасников пару Intel SAS SSD, вместе с контроллером; убрали загрузочные NVME диски из системы вовсе — ничего не изменилось. Ошибка не уходила и присутствовала только на host1.

Под лупой изучили настройки портов на коммутаторе. Нашли одну проблему с LACP, Софинет прислал свежую прошивку, ошибка с LACP ушла. Коммутировали порты у хостов. Host1 был «непокобелим» — он исправно выдавал ошибку 881, на каком бы порту в коммутаторе он ни сидел.

Познакомились с замечательным бесплатным продуктом Meld (есть под Windows), с помощью которого можно наглядно и быстро сравнивать похожие текстовые файлы и выявлять различия.

Были установлены утилиты из репозитория Сизиф (Alt Linux) и написан скрипт, который по максимуму выдёргивает всю системную и аппаратную информацию с каждого из хостов. Всё загрузили в Meld, он как раз сравнивает до трёх файлов одновременно.

Собирает очень много чего, в том числе и дублирующейся информации (требуется установка соответствующих пакетов — lscpu, hwinfo, lshw, biosdecode, dmidecode).

На проблемной машине копируем его в dmi_info_problem, на нормальной — в dmi_info_normal

И грузим в Meld:

Синим отмечены различающиеся строки. Зелёным — блоки текста, которого нет во втором файле:

Очень удобная штука.

На debian 12 обнаружилось, что утилита lshw подвирает при выводе ‑class network и врёт она в выводе предельных скоростей: пишет доступность 40Gbit/sec вместо 100Gbit/sec. Совсем не будет лишним проверить корректную скорость и свойства адаптеров посредством ethtool. В Alt Virt p11 утилита lshw имеет версию B.02.20 и данные выводятся корректно.

В новой версии Gooxi BIOS (Version: 01.33.00.01.00000, Release Date: 04/24/2025) прекратила читаться информация по слотам. Хэндлеры 0×69-0×6F теперь недоступны. В старой версии BIOS (Version: G2DLR.1.30, Release Date: 08/27/2024) они есть, и данные читаются. Информация нужная, было бы хорошо, если бы китайцы всё это вернули. В iRU мы про это написали.

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

Всё указывало на то, что проблема, скорее всего, связана с материнской платой.

Мы сделали большой и очень жирный убедительный отчёт и отправили его в iRU. ТП iRU всё внимательно прочитала, сказала: «Ого!» и нам прислали новую серверную плату, которую поменяли в местном авторизованном iRU СЦ.

Какова же была наша досада, когда эта же ошибка 881 появилась на НОВОЙ плате!

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

С ними был подробно обсуждён весь набор тестов. Взяли на карандаш ещё пару гипотез. Пока Иван Исаев(iRU) не предложил: «а вы попробуйте скопировать при помощи Clonezilla диски с исправного сервера на проблемный сервер». Я это сделал, и на проблемном сервере всё заработало!

В ушах заиграла композиция «Toto Cutugno — Лашара ми кантара.mp3»

Неужели проблема с дисками? Их проверяли, но проверяли‑то мы чистую инсталляцию ОС, а не swap дисков между хостами. «Таак, падажжи… падажжи…». Диски из host3 перебрасываем в проблемный host1 — работает. Переставляем диски из host1 в host3 — проблема 881 вылазит. Но смарты на дисках из host1 — всё в идеале. Диски — новые, да и диски не для десктопов — это серверные диски: не что‑то там, а Samsung Enterprise SSD PM9A3 NVME U.2.

С ними вылез интересный нюанс. Фирмвари под серию Enterprise распространяются только через авторизованных дистрибьюторов Samsung. Сейчас с этим есть определённые проблемы.

После плотного копания в интернете я стал обладателем около 200Mb прошивок для дисков Samsung, разного назначения и поколений, в том числе и на Enterprise, почитал на них описания релизов, и кое‑что стало понятно. Samsung достаточно подробно излагает проблемы, которые лечатся на дисках от версии к версии, включая описания сигналов и особенности работы контроллеров внутри, вместо традиционного китайского «fixed some bugs». Выглядит как «ноу‑хау» и коммерческий секрет. Нашлась более свежая прошивка для идентичного диска, но в конструктиве M.2, зашивать её в U.2 было что‑то боязно. Прошивки под U.2 были, я видел упоминания о них на сайте HPE.

Кстати, «Зашиватор фирмварей Samsung» работает строго под Ubuntu. Заодно проверили nvme discover / connect на проблемном сервере под Ubuntu. Ошибка 881 присутствовала.

Вроде бы всё сходилось на дисках, и iRU был готов поменять и их, но был проведён ещё один эксперимент: На диски, взятые с host1, и установленные в host3, по новой был развёрнут host3. Песня Тото Кутуньо резко перестала играть, когда я увидел обнаружение СХД со стороны host3 с NVME дисками от host1. Получается, что диски тоже были ни при чём.

Позвонил в iRU, рассказал о результатах. В iRU обрадовались, что ничего не надо менять, а я «чот приуныл». Проблема оставалась.

Все компоненты по отдельности были исправны, они прекрасно работали где угодно, но всё вместе не работало только на host1. Осталась гипотеза, что в момент инсталляции системы, происходит нечто, и это влияет на работу в целом. Но как это поймать?!

А здесь ещё и Базальт развёл руками: мы больше ничем вам не можем помочь.

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

В проекте до сих пор не было понимания, где локализуется ошибка: Уровень ядра / уровень протокола NVMEoF / транспорт ROCE или Ethernet/ модуль NIC в ядре / драйверы карты или проблема в её фирмвари? Что это за ошибка — это натуральное число или комбинация битов? Попутно поделился неотступно меня преследовавшей мыслью, что источник проблемы — очень простой, но он постоянно ускользает между пальцев, и мы почему‑то его не видим…

«Фима, мне сдаётся, что мы опять сделали кружок, и таки снова стоим на Дерибасовской?».

Увы, таки да.

Если где и можно спросить за карты Mellanox (израильская компания), то это на сайте Nvidia, к которой, с некоторых пор относится компания Mellanox. Написал пост с вопросом, приложил все имевшиеся логи. «Пришёл невод с одной Тиной Тёрнер». Пост на форуме посмотрели, но реакции никакой не было. Данных было мало.

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

В запасе был ещё один, более длинный путь.

Где можно спросить про linux‑nvme? Конечно же, в месте расположения исходного проекта — на Github, под управлением Daniel Wagner(igaw) и др. Я завёл issue и рассказал суть проблемы, а он подсказал, как включить отладку загружаемых модулей в ядре.

Также он попросил поучаствовать в отладке той самой истории c Dorado empty bogus page. Я очень удачно зашёл: у него в issues велась переписка c ещё одним эксплуатантом Dorado 5000V6 NVME, имевшего аналогичные проблемы с пустой страницей nvme discover. Он вылечил её обновлением фирмвари Dorado до самой свежей SPH53 (и это несмотря на то, что за время проекта мы обновляли на Дораде фирмварь несколько раз!). Вагнер попросил эту информацию подтвердить.

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

Так, мы узнали, что начиная с 6.1.8 SPH50 проблема с ошибочной страницей nvme уходит. Дэниэль (разработчик!) тоже недоумевал, почему работает старая версия его подсистемы и не работает новая. С нашей стороны было подтверждено, что это лечится апгрейдом софта на СХД. Вагнер, со своей стороны, пообещал связаться с Huawei, потому что в их Release Notes на фирмварь, про эту проблему было ничего не написано, а это важно, ведь linux‑nvme используется на массе дистрибутивов Linux во всём мире. В том числе и на Huawei EulerOS.

Кстати, пришлось немного замаскироваться, чтобы никто не задавал вопросов: «Alt Linux? Wie alt ist Alt?» (и прочие каламбуры на немецком). Поскольку проблема идентично воспроизводилась в Debian, то логи также публиковались с выводом из развёрнутого Debian. С ровно теми же ошибками.

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

Ядро в Alt Linux изначально собрано с динамической отладкой, и для драйверов удалось её включить. Логи стали сильно подробнее и стали видны скрытые сообщения об ошибках:

На секунду почувствовал себя капитаном Коноваловым, который увидел выползающие на него немецкие «Тигры»:

Отписался Вагнеру. Он сказал, что linux‑nvme можно исключить, ошибка лежит ниже. Скорее всего, это драйвер в ядре.

Коды синдромов ведомы только Mellanox, никакой (полу) открытой документации на них нет.

На сайте Nvidia был опубликован новый пост с новой информацией и подробными логами с ошибками драйвера mlx5_core.

А вот здесь инженер из Mellanox ответил достаточно быстро: «У вас по непонятной причине не отвечает уровень RDMA‑транспорта, это проблема в драйвере. Если у вас есть номер контракта на сопровождение, мы готовы решить вашу проблему».

Морально стало сильно легче. Не виновато железо, не виноваты мы. Alt — и тот, не виноват!

А что дальше делать‑то? Один сервер по‑прежнему не работает

Немного отвлечёмся

«Знаете, кто этот мощный старик?» Это не Лев Толстой, хотя очень похож. Лев Николаевич, теорию этого джентльмена c фотографии, критиковал нещадно: «Господа! Где человек, а где обезьяна, я вас спрашиваю? Как одно может произойти из другого?».

Чарльз Дарвин говорил: I love fools experiments. I am always making them. «Я люблю дурацкие эксперименты и всегда ими занимаюсь», повторяя вслед за своим дедом. Деда звали Эразм Дарвин, и он был известным для своего времени биологом и естествоиспытателем Великобритании, считавшим, что время от времени следует производить самые дикие эксперименты (wild experiments): «Из них почти никогда ничего не выходит, но если они удаются, то результат бывает потрясающим».

Эразм Дарвин играл на трубе перед тюльпанами — никаких результатов.

Чарльз Дарвин играл на фаготе перед дождевыми червями. Из этого он понял, что у червей нет никакого слуха, но если фагот прижать к столу, то черви начинали бурно реагировать. Дарвин‑внук сделал вывод, что у червей есть органы, которыми они чувствуют вибрацию.

Отличный эксперимент!

«Дичайший» эксперимент. Начало

Снова пришлось вернуться на исходную позицию и ещё раз проанализировать, чем у нас отличаются системы. Ничем, кроме серийных номеров компонентов, а системно — только имя хоста(host1, host2, host3) и сетевые адреса хостов (x.x.x.101, 102, 103). «Дикость» эксперимента заключалась в том, что, даже в самой безумной теории, он не должен хоть на что‑либо влиять.

Было решено поменять имя host1 на host4, а адрес с x.x.x.101 на x.x.x.104.

Та же подсеть, та же маска, тот же шлюз.

От увиденного отпала челюсть.

«Да ну на фиг, так не бывает!»,‑ сказал я и пересказал решение нашему сетевому инженеру, Василию Балканову, очень квалифицированному специалисту. Он меня выслушал, сказал: «Да ну на фиг, так не бывает!», но пришёл и убедился лично.

ВСЁ ЗАРАБОТАЛО!

Смена адреса убрала проблему с обнаружением СХД. Что там не так, до сих пор непонятно. Есть гипотеза о возникновении проблемы где‑то на стыке между модулем ядра mlx5_core и драйверами RoCE и Ethernet, и это Mellanox частично подтвердил.

Интуиция не обманула. Проблема действительно решалась очень просто, и она действительно возникала во время инсталляции Alt и последующей настройки PVE. В момент присвоения IP адреса на карте Mellanox.

Во внутренней документации этот факт зафиксирован с комментарием: «Дэти! Это понят нелзя, это нада запомнэт!»

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

Хосты выдают между собой практически идентичные IOPS (384К на 8К блоке), что даже быстрее, чем локальные NVME диски с BTRFS зеркалом сверху.

При использовании IB perftest и соединении через коммутатор, RDMA‑транспорт показывает 96 Гб/сек с узла на узел.

тест скорости одного линка, через RDMA (‑R), 10 сек. (‑D), с выводом в Gbit/sec:

[root@host3 ~]#  ib_write_bw -i 1  -R -D 10 --report_gbits
************************************
Waiting for client to connect... 
************************************
---------------------------------------------------------------------------------------
                    RDMA_Write BW Test
 Dual-port       : OFF          Device         : mlx5_bond_0
 Number of qps   : 1            Transport type : IB
 Connection type : RC           Using SRQ      : OFF
 PCIe relax order: ON
 ibv_wr* API     : ON
 CQ Moderation   : 1
 Mtu             : 4096[B]
 Link type       : Ethernet
 GID index       : 3
 Max inline data : 0[B]
 rdma_cm QPs     : ON
 Data ex. method : rdma_cm
---------------------------------------------------------------------------------------
 Waiting for client rdma_cm QP to connect
 Please run the same command with the IB/RoCE interface IP
---------------------------------------------------------------------------------------
 local address: LID 0000 QPN 0x135a PSN 0x8ba4ee
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:172:16:01:103
 remote address: LID 0000 QPN 0x135c PSN 0x2ab2ce
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:172:16:01:102
---------------------------------------------------------------------------------------
 #bytes     #iterations    BW peak[Gb/sec]    BW average[Gb/sec]   MsgRate[Mpps]
 65536      1120663          0.00               96.93              0.186790
---------------------------------------------------------------------------------------

На клиенте идентично, только добавляем адрес сервера

ib_write_bw -i 1 -R -D 10 --report_gbits 172.16.144.103

Статистика клиента также совпадает с сервером:

#bytes     #iterations    BW peak[Gb/sec]    BW average[Gb/sec]   MsgRate[Mpps]

 65536      1120663          0.00               96.93              0.186790
  
---------------------------------------------------------------------------------------

По результатам измерений получилось 96.93Gb/sec при соединении хостов через коммутатор. 

HPE у себя в документах, приводит цифру в 98Gb/sec и утверждает, что это практический предел на 100GbE линках Mellanox (2–3GbE — оверхед пакетов и накладные расходы). Весь трафик идёт через RDMA.

«See you later, alligator»,‑ сказал бы Кирпич. — «I keep eye on you, lucky bastard».

Позвонил Николаю Мальцеву в Базальт, обрадовал, что после всех происшествий, у нас всё получилось.

Он тоже обрадовался и немного приоткрыл завесу, со слов Базальт — мы первые у кого получилось развернуть в Alt Virt работу с Huawei Dorado через NVME over RDMA. Другие заказчики в таком режиме её до сих пор не используют.

Как говорил Энди Уорхол, «каждый человек в мире имеет право на 15 минут славы» (Весёлая передача была на ТВ6 в своё время). Если бы в нашем офисе был балкон, я бы сделал вот так:

Сейчас система запущена в опытно‑промышленную эксплуатацию. Разворачиваем на новой базе серверы и мониторим их работу. Кое‑что подкручиваем на транспортной сети. Попутно пишем заметки для себя про PVE.

С PVE, если у вас создан кластер, завязанный на внешнюю СХД, тоже всё немного не так, как это пишется в этих ваших «инторнетах». Выясняем, проверяем, документируем.

Как говорил вышеупомянутый Каневский, «это уже совсем другая история».

FIN!

Часть 2. Уроки проекта импортозамещения

«Если не сделано никаких выводов, то весь полученный опыт прошёл впустую».

О результате

Мы получили рабочее решение транспорта NVME over ROCEv2. Знаем, как оно работает, иногда понимаем, почему оно не работает. Как при этом надо конфигуривать серверы, коммутаторы и СХД. Это всё документировано. Заметок на коленке получилось около 140 страниц, которые ещё надо нещадно вычищать, и есть практически готовая документация по разворачиванию Alt Virt на серверах iRU/Gooxi.

Надо дописать несколько скриптов и интегрировать их в систему, ещё нужны тесты и проверки.

Вот после этого Базальту ничто не мешает официально заявить о поддержке RDMA (то, что разработчики zVirt (Orion Soft)и SpaceVM (ДАКОМ) обещают уже давно. Я лично «уже джва(!) года жду эту игру»).

Надо также помнить, что новые вендоры, заявившие о поддержке RDMA, часто немного лукавят и имеют в виду не NVME over ROCEv2, а NVME over TCP. Это не RDMA в его исходном смысле. Внимательно смотрите справочные листки по оборудованию, они же — datasheets.

А когда есть пошаговые инструкции, то это уже начинает выглядеть как тиражируемая технология для других вендоров железа и ОС, особенно тех, кто изготовляет серверы/коммутаторы/СХД. (Yadro/Aquarius/Depo). У Yadro и Aquarius есть в планах сделать полноценный RDMA в коммутаторах. Емнип, и там, и там Broadcom Trident III или что‑то совместимое.

О вендорах, продуктах и заказчиках

Неверные ожидания заказчика

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

Даже если к нам вернутся все старые вендоры, стыдливо свалившие в закат при наступлении дня X и времени Ч, то где гарантия того, что не возникнут другие обстоятельства, и они не сделают это снова?

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

Очень неприятно, когда рабочие системы с оплаченной поддержкой, превращаются в тыкву или по ним прекращается обслуживание (есть персональный опыт с Fortinet, HPE и другими).

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

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

Неверные ожидания от продукта

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

Остаётся проработка способов решения существующих задач возможностями другого продукта, с делением на три категории: возможное, невозможное и делаемое другим способом.

Попадались западные статьи, в которых упоминалось, что именно после приобретения VMWare компанией Broadcom, возник всплеск интереса к PVE. Хотя вроде бы ничего такого не произошло, у компании поменялся собственник, но появляется та самая неопределённость, которая заставляет внимательно просматривать альтернативу и иметь запасной план на тот случай, если что‑то пойдёт не так.

Broadcom, кстати, прибрал к рукам практически всех значимых производителей FiberChannel. «Это ж‑ж‑ж — неспроста!». Какая интересная штука получается: левой рукой Broadcom подгребает под себя рынок FiberChannel, правой рукой Broadcom всячески поддерживает развитие RDMA. Если в момент X возникнет необходимость выбирать между двумя системами, какая из них будет отдана под нож?

Неверные ожидания вендоров

Внезапно требования коммерческих компаний отличаются от госсектора и образования. Это камень в огород всех наших новых вендоров. И до многих это осознание ещё не дошло. В мире Linux всё всегда было по‑другому. Почти как по А.П. Чехову в его «Жалобной книге»: «Лопай, что дают».

Госсектор и образование связаны определёнными рамками при выборе продуктов и процедуре закупок, и работают по принципу: «Есть реестровые (сертифицированные) продукты, с ними и работаем, удобно/неудобно — это уже второй вопрос», но коммерческий сектор свободнее в реализации своих требований, и, главное — хорошо понимает, что ему надо. Он привык применять лучшие из доступных решений, согласен платить за это деньги, но и требует отдачу за каждый рубль, выделяемый на продукт и его поддержку.

Здесь тоже ничего нового, это всё уже было у прежних вендоров.

Поддержка продукта не даёт ответов на все вопросы

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

«Если проблема решается деньгами, то это не проблема, а расходы». Расходы на ТП надо закладывать в бюджет. К сожалению, техподдержка при экономии бюджетов, режется в первую очередь.

Говорить, что ТП у прежних вендоров была идеальна — я бы не стал.

Ресурсы

Есть интересное отличие мира Linux от мира Windows. Оно совершенно очевидно, но никто не говорит про это вслух. В мире Windows сильно больше денег, он всегда был коммерческим. Главная крепость платформы Windows — компания Microsoft. У Microsoft сейчас 230 тыс. сотрудников, при этом сам Microsoft продаёт 53 продукта и сервиса. Денег, собираемых за лицензии и техподдержку компании хватает на текущие расходы и развитие, а подписка делает этот поток гарантировано устойчивым.

В любом репозитории Linux — десятки взаимопересекающихся продуктов. Имеет ли ТП вендора 100% компетенции по всем продуктам? Ответ тоже очевиден — нет.

Что делать? Тоже ничего нового: cотрудничество и консолидация, консолидация и сотрудничество.

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

Об управлении проектами

Проект, без ответственного менеджера со стороны вендора, обречён на неудачу в 90% случаев. Менеджер проекта у вендора, менеджер проекта у заказчика должны очень хорошо понимать друг друга и говорить на одном языке, пусть это даже будет суахили. Если специалисты у заказчика упираются в проблему, и она со стороны вендора оперативно не решается, очень высок риск того, что проект будет убран в сторону. Потому что перспективы непонятны, подпирают другие задачи, бесконечно тратить время на тестирование нельзя — так оно обычно всё и происходит.

Всегда есть риск попасть в серую зону неопределённости, где быстро заканчиваются компетенции участников. Если другого выхода нет, то надо быть готовыми, что заниматься придётся полностью самостоятельно. «Спасение утопающих — дело рук самих утопающих». Никто не поможет и не придёт на помощь. Особенно когда оборудование за много денег куплено и прикручено в стойки.

Всё происходит в соответствии с одним из законов Мерфи: «Простая проблема — решается сложно, сложная проблема — не решается вообще».

Оборудование в демо

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

Другой пример. После всех работ сложилось впечатление, что Mellanox CX-5 — не самое лучшее решение проблемы. Возможно, CX-6 и CX-7 были бы лучше. Как это проверить? Продавец и дистрибьютор предлагает купить. К сожалению, стоимость их не копейка. Останавливает ещё один вопрос: А если не заработает как надо? Куда их деть? Убрать в шкаф? Только он и так забит исправным, но ненужным хламом, оставшимся после неудачных экспериментов.

А если бы заработало — мы бы сразу их купили шесть штук.

Заказчик не хочет брать на себя ответственность за этот риск, и продавца тоже можно понять — он не хочет зависнуть с товаром на руках. В текущих условиях эта проблема не решаема.

Только если кто‑то рискнёт, проверит, а потом поделится этой информацией, но этого может никогда не случиться.

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

О документации и документировании

«Документация она как секс. Либо она очень‑очень хороша, либо она лучше, чем ничего».

Документация по импортозамещённым продуктам сейчас сделана так, что она не даёт никаких ответов на вопросы. Это некоторое вводное описание свойств продукта, хорошо, если на русском языке, переведённое с оригинала. Часто устаревшее, потому что быстро (и качественно) переводить не получается несмотря на наличие нейросетей.

Проблема в другом: документация не содержит ответов на вопросы: Как использовать свойства продукта наилучшим образом для потребностей заказчика? Как с помощью этого продукта решить задачу заказчика?

Многие сотрудники новых вендоров работали у прежних вендоров. Неужели они так быстро забыли, как всё это было организовано?

Нового здесь ничего не придумано. Нужно документирование реализаций технологий и хороших практик. «Все леди вендоры делают это»:

• white papers — описания технологий;

• application notes / solution guides — описание конкретных частных случаев (проблем), или некоторых общих подходов к решению;

• integration guides — руководства по интеграции с другими системами;

• best practices — лучшие практики, описания практических реализованных проектов и задач.

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

Заказчику нельзя забывать про локальную документацию проекта. Если участники проекта со стороны заказчика не документируют каждый шаг в проекте — вся боль и страдание пройдут впустую. Примерно через месяц проекта вы уже не будете помнить, что делалось на конкретном шаге в самом начале. Через год вы натолкнётесь на собственные записки и будете удивляться, ну надо же, как интересно написано, а главное, кто тот умный человек, что всё это написал? Так устроена человеческая память — невостребованное благополучно забывается.

У вас появился новый сотрудник? Такие записки — идеальный вариант быстро включить человека в рабочий процесс.

Делитесь знаниями. Это уменьшает боль и экономит время для тех, кто пошёл следом.

Нового здесь ничего придумывать не надо.

Если интересно, то могу начать публиковать «Инструкции по запуску NVME over RDMA»

Вот теперь точно FIN!

Спасибо, если дочитали.

Благодарности

Огромное спасибо всем, кто помог этому проекту состоятся.

В общей сложности к нему имело отношение около 40 человек, из самых разных компаний из нескольких стран.

Спасибо ТП Хабра за терпение при создании статьи.