Русский
Русский
English
Статистика
Реклама

Mellanox

Быстрая сеть в домашней лаборатории или как я связался с InfiniBand

25.11.2020 20:07:40 | Автор: admin

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

tl;dr Если кому интересно, то сейчас такая ситуация, что пару десктопов можно связать 56Gb сеткой за <$100+доставка из штатов. Если хочется больше компьютеров, то это <$100 за 12 портовый свитч 40Gb и ~$60 за десктоп, плюс доставка. Но это всё б/у и ноль гарантий.

Заранее извиняюсь, но аббревиатур будет много. И это не реклама - всему этому оборудованию уже лет как много, оно уже не поддерживается производителем и легко ищется б/у на eBay за очень недорого, по сравнению с ценами на новое от производителя. Но должен сказать, что новое (анонсировано в конце 2020) - уже почти на порядок быстрее. Так что это всё про домашние эксперименты и самообучение.

Медный век

Когда появился в домашней лаборатории второй компьютер, а это год 2013, то в какой-то момент стало понятно, что скорости Ethernet в 1Gb - маловато будет, а хочется экспериментов. Стал выяснять, что же есть в природе на тот момент. 10GbE было ужасно дорого, и нашлись карточки производства Mellanox. Кроме Ethernet, они умеют и InfiniBand (это важно в дальнейшем). Можно почитать на Wiki, чем они отличается, но кроме всего прочего - IB умеет и IP over IB, а это ровно то, что нужно для нормальной жизни. Большим плюсом было то, что б/у адаптеры на eBay продавали чуть-ли не за копейки ($20-30). Поэтому было куплено сразу три (одна про запас) Mellanox-овские карточки MHEH28-XTC, которые умеют и InfiniBand SDR и Ethernet 10GbE, но имели странный разъем CX4. Также за пиво были найдены 3 кабеля (длиной всего 0.5м, но для лабы - самое то).

Дальше пошли всякие эксперименты, скорость передачи файлов по сети 600-700MB/s была получена. На RAM диске конечно, мои SSD в то время больше 250-300MB/s не умели.

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

Как известно, аппетит растет во время еды, поэтому апгрейд. Нашлись MHGH28-XTC, которые уже умеют InfiniBand DDR, а это уже 16Gbps. Выяснилось, что не все кабели одинаково полезны, скорость не выросла, пришлось искать новые. Нашлись медные, но аж 8 метров длины, и ощутимо тяжелые, это вам не Cat 5/6. С ними измерения показали до 1600MB/s, и до более тонкого тюнинга руки не дошли. Диски и рейды, что были - всё равно медленнее.

Следующий апгрейд, самый бестолковый, MHJH29-XTC, умеют аж QDR - 32Gbps. Только выяснилось, что Firmware для этих новинок - есть только очень старая. Такая, что под Win ничего работать даже не собирается. Хорошо хоть, что Linux выручил. Но ничего не работает на скорости QDR на старых кабелях, а кабели для скорости QDR найти - нереально.

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

Оптический век

С первых опытов уже прошло пять лет, и год стал 2018. Насколько я понимаю ситуацию, и почему так произошло - штатовские дата центры начали (и закончили) апгрейды своих сетей, и на eBay появилась куча новых интересных б/у железок за гуманную цены. А именно карточки ConnectX-3, свитчи, и оптические кабели. Это уже не предания старины глубокой, а относительно новое железо.

SIDENOTE: как я понимаю, это из-за перехода с 10/40GbE на 25/50/100+GbE. И у них есть вопросы совместимости, поэтому старое просто утилизировали.

Что тут можно рассказать, сначала были куплены карточки и кабели. Причем они уже были настолько распространены, что искать не обязательно Mellanox'ы, есть тоже самое под именами HP/Dell/IBM, и они дешевле. Драйвера встроенные есть и в Win, и в Linux, работает всё почти само. Это всё железо умеет QDR/FDR10/FDR14, то есть по сути 40/56Gbps. Реальную скорость при правильной настройке можно 4700+MB/sec увидеть. Хоть диски и стали NVMe (PCI 3 все-таки), но сеть всё равно оказалась быстрее.

А самое хорошее - есть свитчи за разумные деньги (<$100 за 8/12 портов 32/40Gb). Например старенький IS5022, из недостатков - умеет только QDR, и кому-то может быть важно, что только 8 портов, из плюсов - можно держать дома и даже спать рядом, если доработать.

Вообще не шумит, если вентилятор Noctua, дует холодным воздухом, но совершенно не продакшен решение, конечно. Зато по ГОСТ 26074-84 и ГОСТ 8486-86.

WARNING: если кто-то захочет повторить - надо перепаивать провода у вентилятора, там другая распиновка. При попытке просто воткнуть обычный вентилятор - он не вертится, а начинает дымиться!

Или SX6005 - эти уже умеют FDR10 на 12 портов, но главный чип у них снизу, и просто бросить кулер сверху я пока не решился. Но собираюсь этот свитч раскурочить и попробовать. DIY, всё-же.

Есть ещё много разных вариантов, но все их расписывать - я не настолько разбираюсь в ситуации (Brocade ICX серию можно посмотреть).

У всего этого благолепия есть один важный недостаток - те два примера железок, что я выше привёл - это InfiniBand свитчи. Они не умеют Ethernet, и получается только IPoIB. Что из этого следует - Win/Linux машины прекрасно видят друг друга, общаются и всё работает отлично. Главная проблема для меня была - если вам нужны виртуальные машины и чтобы они видели друг друга по быстрой сети - просто так не получится, IB не маршрутизируется на level 3 (поправьте, кто умнее, если я тут чушь написал). Точнее сделать это с виртуальными машинами можно, но не на домашнем железе (SR-IOV нужен и проброс VF внутрь виртуалки), с муторным процессом настройки, плюс с миграцией отдельные заморочки.

К сожалению, пока на eBay нет дешевых 40/56GbE Ethernet свитчей (можете поискать SX1012, если интересно), с которыми можно было-бы поэкспериментировать. Придётся ещё несколько лет подождать. А там, глядишь, и до 25/100GbE можно будет в домашней лабе подобраться.

PS: С IB есть ещё всякие нюансы типа необходимости OpenSM где-то, если switch non-managed, но это всё-же не про настройку IB статья.

Подробнее..

Из песочницы Из ничего к ЦОД с VXLANEVPN или как готовить Cumulus Linux. Часть 1

01.11.2020 20:22:23 | Автор: admin
В последние полгода удалось поработать над большим и интересным проектом, в котором было все: от монтажа оборудования до создания единого VXLAN/EVPN домена в 4-х ЦОД. Т.к. было получено много опыта и набито много шишек в процессе, решил что написать несколько статей на эту тему будет наилучшим решением. Первую часть я решил сделать более общей и вводной. Целевой дизайн фабрики будет раскрыт в следующей части.



Знакомство с Cumulus Linux. Установка оборудования и первоначальная настройка


Вводные к началу работ были следующие:

  1. Закуплено оборудование
  2. Арендованы стойки
  3. Проложены линии к старым ЦОД

Первой порцией оборудования, которое необходимо было поставить, стали 4 х Mellanox SN2410 с предустановленным на них Cumulus Linux. На первых порах еще не было понимания как все должно будет выглядеть (сложится оно только к этапу внедрения VXLAN/EVPN), следовательно, мы решили поднять их как простые L3 коммутаторы с CLAG (Аналог MLAG от Cumulus). Ранее опыта работы с Cumulus ни у меня, ни у коллег сильно не было, так что все в какой-то степени было в новинку, дальше как раз про это.

Нет лицензии нет портов


По умолчанию при включении устройства вам доступны только 2 порта console и eth0(он же Management port). Чтобы разблокировать 25G/100G порты нужно добавить лицензию. И сразу становится понятно, что Linux в названии ПО не просто так, т.к. после установки лицензии надо перезагрузить демона switchd, через systemctl restart switchd.service (по факту отсутствие лицензии как раз и не дает запуститься данному демону).

Следующее, что сразу заставит вас вспомнить что это все-таки Linux, будет обновление устройства используя apt-get upgrade, как в обычном Ubuntu, но обновиться так можно не всегда. При переходе между релизами, например, с 3.1.1 на 4.1.1, нужно устанавливать новый образ, что влечет за собой сброс конфиги в дефолт. Но спасает то, что в конфигурации по умолчанию на Management интерфейсе включен DHCP, что позволяет вернуть управление.

Установка лицензии
cumulus@Switch1:~$ sudo cl-license -i
balagan@telecom.ru|123456789qwerty
^+d

cumulus@Switch1:~$ sudo systemctl restart switchd.service


P.S. Дефолтная конфигурация eth0(mgmt) интерфейса:
cumulus@Switch1:~$ net show configuration commands | grep eth
net add interface eth0 ip address dhcp
net add interface eth0 vrf mgmt


Система commitов


Как человек, много работавший с Juniper, для меня такие вещи как rollbackи, commit confirm и т.д. были не в новинку, но наступить на пару граблей удалось.

Первое, на что я напоролся, была нумерация rollback у cumulus, в силу привычки rollback 1 == последняя рабочая конфигурация. Я с огромной уверенностью вбиваю данную команду, чтобы откатить последние изменения. Но каково было мое удивление, когда железка просто пропала по управлению, и какое-то время я не понимал, что произошло. Потом, прочитав доку от cumulus, стало понятно, что случилось: вбив команду net rollback 1 вместо отката на последнюю конфигурацию, я откатился на ПЕРВУЮ конфигурацию устройства.(И опять же, от фиаско спас DHCP в дефолтной конфигурации)

commit history
cumulus@Switch1:mgmt:~$ net show commit history
# Date Description
2 2020-06-30 13:08:02 nclu net commit (user cumulus)
208 2020-10-17 00:42:11 nclu net commit (user cumulus)
210 2020-10-17 01:13:45 nclu net commit (user cumulus)
212 2020-10-17 01:16:35 nclu net commit (user cumulus)
214 2020-10-17 01:17:24 nclu net commit (user cumulus)
216 2020-10-17 01:24:44 nclu net commit (user cumulus)
218 2020-10-17 12:12:05 nclu net commit (user cumulus)

cumulus@Switch1:mgmt:~$


Второе, с чем пришлось столкнуться, был алгоритм работы commit confirm: в отличие от привычного нам commit confirm 10, где в течении 10 минут нужно еще раз прописать commit, у Cumulus было свое виденье данной фичи. Ваше подтверждение commit confirm это простое нажатие Enter после ввода команды, что может сыграть с вами злую шутку, если связность потеряется не сразу после commit.

net commit confirm 10
cumulus@Switch1:mgmt:~$ net commit confirm 10
/etc/network/interfaces 2020-10-17 12:12:08.603955710 +0300
+++ /run/nclu/ifupdown2/interfaces.tmp 2020-10-29 19:02:33.296628366 +0300
@@ -204,20 +204,21 @@

auto swp49
iface swp49
+ alias Test
link-autoneg on

net add/del commands since the last net commit
================================================

User Timestamp Command
cumulus 2020-10-29 19:02:01.649905 net add interface swp49 alias Test

Press ENTER to confirm connectivity.


Первая топология


Следующим этапом была проработка логики работы коммутаторов между собой, на данном этапе железо только ставилось и тестировалось, ни о каких целевых схемах речи еще не шло. Но одним из условий было, что сервера подключенные к разным MLAG парам должны быть в одном L2 домене. Делать одну из пар простым L2 не хотелось, в связи с чем было решено поднять L3 связность поверх SVI, для маршрутизации был выбран OSPF, т.к. он уже использовался в старых ЦОД, что упрощало соединение инфраструктуры на следующем этапе.



На данной схеме отображена схема физики + разделение устройств по парам, все линки на схеме работают в режиме Trunk.



Как и говорилось, вся L3 связность сделана через SVI, следовательно, IP адрес в каждом Vlan есть только у 2 устройств из 4, что позволяет сделать своего рода L3 p2p связку.

Основные команды для заинтересованных


Bond(Port-channel)+CLAG(MLAG)
#Используем vrf mgmt согласно всем best-practice
net add interface peerlink.4094 clag backup-ip Х.Х.Х.Х vrf mgmt
#Чем меньше адресов тем лучше(можно вместо linklocal использовать IP адреса)
net add interface peerlink.4094 clag peer-ip linklocal
#Берем из пула указанного в документации 44:38:39:ff:00:00-44:38:39:ff:ff:ff
net add interface peerlink.4094 clag sys-mac Х.X.X.X.X
#Cоздание Bond#Добавляем интерфейсы которые нужно агрегировать
net add bond bond-to-sc bond slaves swp1,swp2
#Выбираем LACP
net add bond bond-to-sc bond mode 802.3ad
#Подаем VLAN в Bond
net add bond bond-to-sc bridge vids 42-43
#Присваиваем уникальный ID
net add bond bond-to-sc clag id 12
P.S. Всю указанную конфигурацию можно реализовать через /etc/network/interfaces

Проверка работоспособности

cumulus@Switch1:mgmt:~$ net show clag
The peer is alive
Our Priority, ID, and Role: 32768 1c:34:da:a5:6a:10 secondary
Peer Priority, ID, and Role: 100 b8:59:9f:70:0e:50 primary
Peer Interface and IP: peerlink.4094 fe80::ba59:9fff:fe70:e50 (linklocal)
VxLAN Anycast IP: 10.223.250.9
Backup IP: 10.1.254.91 vrf mgmt (active)
System MAC: 44:39:39:aa:40:97


Trunk/Access port mode
#Создаем интерфейс Vlan
net add vlan 21 ip address 100.64.232.9/30
#Назначаем ID
net add vlan 21 vlan-id 21
#Подаем в L2 Bridge
net add vlan 21 vlan-raw-device bridge
P.S. На данном этапе VLAN уже будет подан на Bridge порты
#Trunk порт (все bridge vlan)
net add bridge bridge ports swp49
#Trunk порт (ограниченный пул VLAN)
net add interface swp51-52 bridge vids 510-511
#Access порт
net add interface swp1 bridge access 21
P.S. Всю указанную конфигурацию можно реализовать через /etc/network/interfaces

OSPF+Static
#Static route для mgmt
net add routing route 0.0.0.0/0 10.1.255.1 vrf mgmt
#OSPF с включением по принадлежности к Network
net add ospf network 0.0.0.0 area 0.0.0.0
#OSPF на определенном интерфейсе
net add interface lo ospf area 0.0.0.0
P.S. На Cumulus может быть только один Loopback интерфейс
#OSPF редистрибьюции
net add ospf redistribute connected
P.S. Данный функционал так же можно конфигурировать через vtysh(c Cisco like синтаксисом), т.к. в Cumulus используется FRR

Заключение


Надеюсь, кому-нибудь данная статья покажется интересной. Хотелось бы увидеть feedback: что добавить, а что совсем лишнее. В следующей статье уже перейдем к самому интересному к дизайну целевой сети и настройке VXLAN/EVPN. И в будущем возможна статья по автоматизации VXLAN/EVPN средствами Python.
Подробнее..

Linux Switchdev по-мелланоксовски

09.11.2020 18:08:51 | Автор: admin
Это транскрипция выступления прозвучавшего на Yandex NextHop 2020 видео в конце страницы



Приветствую. Меня зовут Александр Зубков, я хочу рассказать про Linux Switchdev что это такое и как мы с ним живем в Qrator Labs.



Мы используем Switchdev на коммутаторах Mellanox уже примерно 2-3 года. Коммутаторы Mellanox на чипе Spectrum относятся к категории white-box, что значит что вы можете поставить разные операционные системы на данные коммутаторы. Обычно вендор предоставляет для этого некоторый SDK и операционные системы используют этот SDK для того чтобы взаимодействовать с коммутатором. И в случае со свитчами Mellanox есть операционка от самого Mellanoxа, есть Cumulus. Также поддерживается SAI (Switch Abstraction Interface) это некоторая попытка создать стандартный SDK для разных коммутаторов, который используется уже, в свою очередь, SONiC операционкой. И, естественно, Switchdev поддерживается коммутаторами Mellanox.



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



Мы на коммутаторах Mellanox используем довольно стандартный набор функций: маршрутизация, ECMP, в общем ничего необычного. Все это поддерживается с возможностью оффлоада в датаплейн. Единственное чего не хватает это policy-based routing в драйвере Mellanox отсутствует поддержка.



Драйвер Mellanoxа находится в ванильном ядре Linuxа с поддержкой Switchdev то есть не надо никаких патчей или дополнительных бинарных драйверов. Вы можете, практически, брать ядро в вашем любимом дистрибутиве или сами скомпилировать ванильное ядро и пользоваться. Прошивка в свитче обновляется самим драйвером нужно только соответствующий файл подложить, который обычно содержится в пакете linux-firmware или каком-нибудь подобном.



Для настройки самого свитча используются, естественно, стандартные утилиты Linuxа, в большом количестве. Набор из iproute2, ethtool, LLDP-демон для QoSа используется в том числе. И sysctl для некоторых параметров.



Для vrfа в Linuxе есть как сетевые неймспейсы. Но есть и так называемая подсистема vrf она отличается от сетевых неймспейсов. В этом случае все ваши интерфейсы находятся в одном неймспейсе при работе с vrf. И для того чтобы управлять маршрутизацией есть специальное правило в ip rule, которое определяет какому vrfу относится пакет и в соответствии с этим направляет его в определенную таблицу маршрутизации. Чтобы это настроить vrf в Linuxе создается специальный интерфейс типа vrf и во время создания к нему привязывается эта таблица. И дальше, если вы хотите какой-то интерфейс добавить в ваш vrf, то соответственно вы с помощью команды ip link устанавливаете вот это специальное устройство в качестве master-интерфейса для вашего интерфейса. И так как все эти интерфейсы находятся в одном пространстве имен то вы можете маршруту указать явно интерфейс из другого vrfа и таким образом сделать маршруты между интерфейсами.



У нас есть например такая задача, в которой бы помог policy based routing мы получаем трафик с аплинка и хотим его направлять целиком и безусловно на какие-то фильтрующие узлы. В Cisco или в Arista мы бы сделали policy route mapы или service policy какие-нибудь, в Linuxе и ip rule можно сделать но в Linuxе все это, к сожалению, не оффлоадится.



И нам приходится вертеться. Вот мы сделали, например, такую фишку мы разделили vrf на две части, то есть в одной части во внешней, находится интерфейс с нашим аплинком, а во внутренней части находятся интерфейсы с нашими фильтрующими узлами.



И примерно так вот выглядит маршрутизация. Во внутреннем vrfе у нас более менее стандартный набор маршрутов то есть у нас там внутренние маршруты и default-маршрут через наш аплинк. А уже во внешнем интерфейсе у нас только default-маршрут лежит, но он лежит через наши фильтрующие узлы. Таким образом у нас получился псевдо Policy Based Routing для интерфейсов. Весь трафик который приходит через интерфейс аплинка направляется по другому маршруту.



И в целом когда вы конфигурируете коммутатор на Switchdevе вам приходится сначала обычно настраивать порты, потом бонд, потом подключаете к бриджу, потом vlanы, vrfы и уже в конце адреса и маршруты. Это в основном диктуется самой структурой интерфейсов в Linuxе то как вы все должны настраивать, ну и существуют еще какие-то ограничения не позволяющие вам произвольно менять настройки. То есть это довольно муторная работа, которая в нашей компании изначально выполнялась большим init-скриптом, который все это настраивал. Но, естественно, нам приходится иногда делать изменения в runtime, в продакшене.



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



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



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





Там довольно много команд, но в целом если это у вас в init-скрипте, то это более-менее можно поддерживать.



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



Дальше. ACL настраивается вы можете iptables использовать, но он не оффлоадится вы можете его только для фильтрации control plane трафика использовать. А если вы хотите в дата-плейне фильтровать, то вам необходимо использовать tc filter в случае Switchdevа. И тут стоит иметь в виду что tc filter будет уже фильтровать не только маршрутизируемый трафик, но и тот который коммутируется. И также tc filter можно повесить только на физические порты, поэтому если вы работаете с vlanами тут нужно уже более сложные конструкции делать. Но там есть интересные фичи, например можете повесить такой блок на несколько интерфейсов и они будут шарить (в смысле делить между собой) общий фильтр. Также есть оператор goto в правилах tc, что тоже довольно прикольно и позволяет делать нелинейные aclи в отличие от того же Cisco или Arista.



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



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



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



Но нам нужно для этого сначала посмотреть текущее состояние и так примерно выглядит вывод tc filter довольно сложно с этим работать.



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



Данные утилиты, про которые я рассказал, мы их выложили в паблик на Гитлабе можете пользоваться. Они под MIT лицензиями, соответственно свободно доступные.



Естественно без какой-либо гарантии. Это пара скриптов на Perl (предвосхищая ваши вопросы потому что я знаю Perl и он просто работает), относительно небольшие, почти без зависимостей там используется пара Perl-модулей которые есть в стандартной поставке Perlа и утилиты Linuxа, естественно.



Напоследок я хочу, если вы мало с последовательной консолью, с COM-портами, работали, дать несколько советов. Например если кто-то подумал что это способ выхода из Vimа вы почти угадали.



Это для некоторых biosов эквивалент Ctrl+Alt+Del, они так это воспринимают через последовательный порт. То есть если у вас в загрузчике зависло, например, и вам нужно как-то перезагрузить коммутатор можете использовать.

Дальше когда дело до ядра доходит оно естественно перехватывает работу с клавиатурой, поэтому тут вам лучше чтобы ваше ядро SysRq команды принимало иначе будет сложно свитч перезагрузить. И в случае с SysRq когда вы с клавиатурой работаете и обычным терминалом там PrintScreen используется, а в случае с последовательной консолью, с COM-портом, вам нужно послать специальный break-сигнал в minicomе это Ctrl+F, в screenе Ctrl+A, Ctrl+B, и дальше уже специальную клавишу SysRq делаете.

И чтобы в bios попасть при загрузке в bios коммутатора конечно же, потому что фактически там как в обычном компьютере есть bios через который он загружается обычно Ctrl+B можете нажать.

Вот и все что я хотел кратко рассказать. Если у вас есть вопросы с удовольствием отвечу.

Подробнее..

Использование недорогих 1040 Гбитс сетевых адаптеров с интерфейсом HP FlexibleLOM

25.11.2020 10:14:05 | Автор: admin

Для соединения пары домашних серверов мне захотелось выйти за пределы привычных 1Гбит/с и при этом сильно не переплачивать за сетевое оборудование. На известном сайте были приобретены недорогие серверные адаптеры HP 764285-B21, по сути являющиеся ОЕМ аналогами Mellanox ConnectX-3 Pro, и QFSP+ медный кабель (DAC). Эти двухпортовые адаптеры могут работать на скоростях 10 и 40 Гбит/с в режиме Ethernet портов и до 56 Гбит/с в режиме InfiniBand. Низкая цена на вторичном рынке обусловлена нестандартным интерфейсом HP FlexibleLOM, разъем которого хотя и похож на стандартный PCIe x8, но имеет иное расположение линий PCIe и поэтому может использоваться только в совместимых серверах HP. Тем не менее выход есть - Tobias Schramm спроектировал специальный адаптер для установки карт HP FlexibleLOM в обычный слот PCIe. Я заказал платы адаптера на jlcpcb.com и 8х коннекторы на алиэкспресс. После монтажа коннектора на плату адаптера и установки всей конструкции в слот она успешно определилась как устройство на шине PCIe:

lspci | grep Mellanox23:00.0 Ethernet controller: Mellanox Technologies MT27520 Family [ConnectX-3 Pro]

Однако после установки Ethernet драйвера Mellanox (я использовал Ubuntu 16.04 и 20.04, предполагаю для других версий и для Windows порядок действий будет аналогичен) Ethernet интерфейсы не появились в системе. Это означало, что драйвер по какой-либо причине не смог распознать адаптер и скорее всего потребуется перешивка. Изучая вывод dmesg можно примерно установить причину ошибки, в моём случае в прошивке адаптеров была включена опция SR-IOV, несовместимая с используемой материнской платой.

Для перешивки адаптера скачиваем и распаковываем Mellanox firmware tools для вашей ОС. Установку производим с ключом --oem (sudo ./install --oem), это позволит сразу установить дополнительные утилиты для сборки новой прошивки.

После установки MFT определяем текущую версию прошивки:

mlxfwmanager -d 23:00.0Querying Mellanox devices firmware ...Device #1:----------  Device Type:      ConnectX3Pro  Part Number:      764285-B21_Ax  Description:      HP InfiniBand FDR/Ethernet 10Gb/40Gb 2-port 544+FLR-QSFP Adapter  PSID:             HP_1380110017  PCI Device Name:  23:00.0  Port1 MAC:        24be05c557c1  Port2 MAC:        24be05c557c2  Versions:         Current        Available          FW             2.42.5700      N/A             Status:           No matching image found

...и делаем бэкап текущей прошивки и конфигурации адаптера:

flint -d 23:00.0 ri original_firmware.binflint -d 23:00.0 dc original_config.ini

Изучив раздел [HCA] файла конфигурации находим требуемый параметр sriov_en и, предварительно скопировав конфигурацию в новый файл new_config.ini, выставляем ему нулевое значение. Также проверяем, что eth_xfi_en равен единице - это позволит активировать Ethernet режим портов:

[HCA]...eth_xfi_en = 1sriov_en = 0...

Далее нам потребуется исходный файл прошивки .mlx для нашего чипсета (в моём случае это ConnectX-3 Pro), как выяснилось раньше их можно было свободно скачать с сайта Mellanox, однако сейчас лавочку прикрыли, оставив только готовые бинарные прошивки, которые, к сожалению, нам не подходят. В результате поисков мне удалось найти прямую ссылку на скачивание исходной прошивки предыдущей версии 2.36:

wget http://www.mellanox.com/downloads/firmware/ConnectX3Pro-rel-2_36_5000-web.tgz

Распаковываем архив и извлекаем искомый fw-ConnectX3Pro-rel.mlx, затем собираем новую прошивку с помощью mlxburn:

mlxburn -fw fw-ConnectX3Pro-rel.mlx -conf new_config.ini -wrimage new_firmware.bin

На всякий случай проверяем новую прошивку:

flint -i new_firmware.bin verify     FS2 failsafe image. Start address: 0x0. Chunk size 0x80000:     NOTE: The addresses below are contiguous logical addresses. Physical addresses on           flash may be different, based on the image start address and chunk size     /0x00000038-0x0000065b (0x000624)/ (BOOT2) - OK     /0x0000065c-0x00002b9b (0x002540)/ (BOOT2) - OK     /0x00002b9c-0x00003b27 (0x000f8c)/ (Configuration) - OK     /0x00003b28-0x00003b6b (0x000044)/ (GUID) - OK     /0x00003b6c-0x00003cc3 (0x000158)/ (Image Info) - OK     /0x00003cc4-0x00010fc3 (0x00d300)/ (DDR) - OK     /0x00010fc4-0x00012027 (0x001064)/ (DDR) - OK     /0x00012028-0x000123f7 (0x0003d0)/ (DDR) - OK     /0x000123f8-0x0005008b (0x03dc94)/ (DDR) - OK     /0x0005008c-0x00054f0f (0x004e84)/ (DDR) - OK     /0x00054f10-0x00059103 (0x0041f4)/ (DDR) - OK     /0x00059104-0x00059bfb (0x000af8)/ (DDR) - OK     /0x00059bfc-0x0008915f (0x02f564)/ (DDR) - OK     /0x00089160-0x0008cd0b (0x003bac)/ (DDR) - OK     /0x0008cd0c-0x000a1d7f (0x015074)/ (DDR) - OK     /0x000a1d80-0x000a1e87 (0x000108)/ (DDR) - OK     /0x000a1e88-0x000a6a8b (0x004c04)/ (DDR) - OK     /0x000a6a8c-0x000a827b (0x0017f0)/ (Configuration) - OK     /0x000a827c-0x000a82ef (0x000074)/ (Jump addresses) - OK     /0x000a82f0-0x000a8e03 (0x000b14)/ (FW Configuration) - OK     /0x00000000-0x000a8e03 (0x0a8e04)/ (Full Image) - OK-I- FW image verification succeeded. Image is bootable.

...и затем прошиваем в адаптер:

flint -d 23:00.0 -i new_firmware.bin -allow_psid_change burn    Current FW version on flash:  2.42.5700    New FW version:               2.36.5000    Note: The new FW version is older than the current FW version on flash. Do you want to continue ? (y/n) [n] : yBurning FS2 FW image without signatures - OK  Restoring signature                     - OK

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

В моём случае после всех вышеперечисленных манипуляций драйвер mlx4_core успешно распознал адаптер и сетевые интерфейсы появились в системе. Для ускорения процесса загрузки я дополнительно отключил boot options:

mlxconfig -d 23:00.0 set BOOT_OPTION_ROM_EN_P1=falsemlxconfig -d 23:00.0 set BOOT_OPTION_ROM_EN_P2=falsemlxconfig -d 23:00.0 set LEGACY_BOOT_PROTOCOL_P1=0mlxconfig -d 23:00.0 set LEGACY_BOOT_PROTOCOL_P2=0

...и удалил BootROM:

flint -d 23:00.0 --allow_rom_change drom

Кроме того, если не планируется использование интерфейсов InfiniBand, можно принудительно перевести оба порта в режим Ethernet:

mlxconfig -d 23:00.0 set LINK_TYPE_P1=2mlxconfig -d 23:00.0 set LINK_TYPE_P2=2
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru