Технология Infiniband (IB, www.infinibandta.org) разрабатывалась как открытое решение, которое могло бы заменить собой все остальные сетевые технологии в самых разных областях. Это касалось и общеупотребительных технологий локальных сетей (все виды Ethernet и сети хранения, в частности, Fibre Channel), и специализированных кластерных сетей (Myrinet, SCI и т.д.), и даже подсоединения устройств ввода/вывода в персональных компьютерах. Кроме того, IB-инфраструктура могла бы использоваться для объединения в целое фрагментов, использующих разные технологии.

Подобное открытое решение предполагало участие многих независимых производителей, в первую очередь, производителей аппаратуры (как это происходит, скажем, с Ethernet-платами, коммутаторами и т.д.), что способствовало бы снижению цен. Очень важной была и поддержка IB со стороны корпорации Intel, которая вроде бы собиралась выпускать микросхемы для IB.

Но Intel отказалась от собственной реализации IB, что несомненно сказалось на развитии IB крайне отрицательно: массовое применение в ПК способствовало бы удешевлению продуктов IB. Критики IB говорят, что сегодня аппаратуру IB производит только компания Mellanox, а потому IB все еще не стала открытым решением, предлагаемым многими. В этом есть доля истины: Mellanox — ветеран рынка IB, ее решения поставляются уже несколько лет, ее микросхемы применяются и в IB-устройствах других фирм. И при подготовке данной статьи были использованы аппаратные и программные средства от Mellanox. К сентябрю 2005 года в мире было поставлено IB-оборудование на более чем 1 млн. портов, при том что Mellanox к весне нынешнего года поставила свыше 0,5 млн. портов.

Впрочем, аппаратуру IB поставляют еще несколько компаний, в том числе Infinicon (ныне SilverStorm), Cisco и Voltaire. Собственные микросхемы InfiniBlue разработала и IBM. Микросхема IB-коммутатора от Agilent, которую, по-видимому, применяет InfiniCon, имеет задержку всего 110 нс — вдвое меньше, чем у Mellanox. Если же сравнить, например, стоимость адаптеров IB 4x (скорость 10 Гбит/с), с адаптерами 10-Gigabit Ethernet от той же Intel, то IB оказывается дешевле, в то время как «пользовательские» свойства IB, в том числе, и производительность, явно выше.

Преимуществом IB перед специализированными, ориентированными на высокопроизводительные кластеры сетевыми технологиями является ее универсальность. Oracle, например, поддерживает IB в своих кластерных решениях. Год назад HP и Oracle установили рекорд производительности на тестах TPC-H (для баз данных емкостью 1 Тбайт) в IB-кластере на базе ProLiant DL585 с использованием СУБД Oracle 10g в среде Linux. Летом 2005 года IBM достигла рекордных показателей для TPC-H (для баз данных емкостью 3 Тбайт) в среде DB2 и SuSE Linux Enterprise Server 9 в IB-кластере на базе xSeries 346. При этом достигнутая стоимость одной транзакции оказалась почти вдвое ниже, чем у ближайших конкурентов (www.tpc.org).

Если IB будет активно использоваться при работе с СУБД , ее ждет успех. Решения на базе IB продвигаются и в нашей стране. Все это вызывает интерес к практике применения IB.

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

Infiniband, Linux и Mellanox

Не будем рассматривать известные технические преимущества IB перед альтернативными технологиями и архитектуру IB как таковую. IB обладает очень богатыми возможностями и предполагает возможность применения большого числа протоколов, ориентированных на различные области (рис. 1). Ограничимся рядом базовых широко используемых компонентов в реализации Mellanox.

Тот факт, что для описания архитектуры IB [1] понадобилось два тома, только первый из которых содержит свыше 1600 страниц (второй том содержит электрические и механические спецификации), уже говорит о ее сложности. Другой вопрос, кто с этой сложностью сталкивается: эти сложности — проблема для разработчиков. Linux — основная операционная система для IB. Кроме программного обеспечения производителей IB-аппаратуры, имеется общий проект OpenIB (www.openib.org), предполагающий, в частности, создание модулей ядра Linux, поддерживающих различные протоколы IB. Этот проект поддерживается крупнейшими компьютерными компаниями, и Mellanox также использует эти разработки. Стек OpenIB входит в ядра, начиная с 2.6.11, и будет поддерживаться крупнейшими дистрибуторами, в т.ч. RedHat и Novell/SuSE.

Введем термины, относящиеся к IB как к таковой. Чтобы изложение было предметнее, в примерах будем использовать аппаратуру, поставляемую Mellanox. Это, в частности, сетевые адаптеры InfiniHost MT23108 для PCI-X/133 МГц (существуют платы Mellanox и для PCI-Express) и коммутаторы InfiniScale MT43132 или MTS2400. Сетевые платы имеют два порта IB 4x и собственную память.

Для передачи данных в IB применяются 4-проводные двунаправленные соединения. При этом 1х (4 провода) отвечает скорости 2,5 Гбит/с, 4х (16 проводов) — соответственно 10 Гбит/с, а в перспективе планируется и 12х. Эти данные относятся к сигнальной скорости; пиковая пропускная способность данных для 1x равна 2 Гбит/с. IB-каналы дуплексные, поэтому для передачи данных в двух противоположных направлениях пропускную способность следует удвоить. Напомним также, что IB базируется на соединениях «точка-точка», обеспечиваемых «коммутирующей фабрикой», в которой коммутаторы могут каскадироваться.

IB-устройствами будем называть аппаратуру, содержащую микросхемы, реализующие совместимые со стандартом IB коммуникации. Набор IB-устройств, соединенных кабелями, называется IB-фабрикой. (Примером IB-фабрики является кластер, в узлах которого используются IB-адаптеры.) Кроме коммутаторов и канальных адаптеров, IB-фабрика может включать маршрутизаторы, повторители, а также специальную инфраструктуру управления, включающую, в частности, программные средства — так называемые менеджеры подсетей (subnet manager, SM), осуществляющие общее централизованное управление подсетью. Канальные адаптеры бывают двух типов — сетевые адаптеры HCA (Host CA) для процессорных хостов, и TCA (Target CA) для устройств ввода/вывода.

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

Доступ к IB-устройствам для целей управления может осуществляться, непосредственно задействуя IB-сеть (сервис In-Band). Альтернативный способ управления — через вспомогательную сеть (сервис Out-of-Band). На рис. 2 изображен простейший IB-кластер из двух хостов, IBH-1 и IBH-2, подсоединенных кабелями к коммутатору MTS2400, управляемому через Ethernet. Альтернативный путь управления обозначен на рисунке пунктиром.

Каждому порту сетевых адаптеров IB-фабрики менеджер подсети присваивает уникальный для подсети адрес (local ID, LID), который используется для маршрутизации пакетов в подсети. В каждом коммутаторе имеются таблицы Unicast Linear Forwarding Tables, где указано, через какой порт следует отправлять пакеты для каждого адреса LID. Если идентификация портов осуществляется с помощью LID, то идентификация канального адаптера осуществляется посредством GUID (Globally Unique Identifier), присваиваемого адаптеру компанией-производителем.

В основе архитектуры IB лежит способность создавать очереди команд, которые выполняются IB-устройствами. Рабочие очереди всегда создаются парами (queue pair, QP): одна — для операций посылки, другая — для операций получения. Пары идентифицируются номером.

IB предоставляет как сервисы, ориентированные на соединения, так и сервисы, ориентированные на датаграммы. Для сервиса, основанного на соединениях, каждая пара очередей связана с парой другого конца соединения, которое, кроме QP, идентифицируется портом. При установлении соединения узлы обмениваются этой информацией между собой. Для сервиса датаграмм пара очередей «не завязана» на одну удаленную пару, а идентификация получателя помещается в элементах рабочей очереди.

Оба варианта сервисов в IB бывают двух типов — надежный (reliable, R) и ненадежный (unreliable, U). Так, UD означает ненадежный сервис датаграмм (пара очередей может принимать и передавать сообщения длиной в один пакет в любую другую пару, при этом аппаратура не гарантирует доставку сообщения получателю, когда сообщает о завершении посылки; не гарантируется и порядок поступления пакетов); RD — надежный сервис датаграмм (он не ограничен одним пакетом); RC — надежный сервис с соединением.

Структура программного обеспечения Mellanox

Компания Mellanox вместе со своими IB-устройствами предлагает бесплатно загрузить программный инструментарий Infiniband Gold Distribution (IBGD), который включает IB-драйверы, базовые сервисы, уровень доступа (Access Layer, AL) к сетевым адаптерам, и набор программных средств, реализующих стек IB-протоколов верхнего уровня (Upper Level Protocol, ULP) для ОС Linux. IBGD включает HCA-драйвер, реализующий интерфейс VAPI (Verbs API), а также AL и ULP, основанные на кодах OpenIB (рис. 1).

Среди протоколов верхнего уровня — протокол SDP (Socket Device Protocol) и драйвер IPoIB (IP over IB), менеджер соединений, uDAPL/kDAPL (User/Kernel Direct Access Programming Library), DAT (Direct Access Transport), а также средства поддержки протокола SCSI RDMA Programming Layer (SRP), служащего для общения с удаленными блочными устройствами хранения. В состав IBGD входит SRP Initiator, клиентская часть, заменяющая низкоуровневые SCSI-драйверы Linux при работе с подсоединенными через IB удаленными устройствами хранения, на которых работает серверный компонент SRP.

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

Не все эти протоколы являются уникальными особенностями IB. Так, для аппаратуры Myrinet имеется аналог DAPL. Вообще, DAPL — это общий API-интерфейс для приложений, работающих с удаленными устройствами через RDMA. Он не зависит от конкретной аппаратуры; соответствующие спецификации созданы DAT Collaborative (www.datcollaborative.org). Этот API предназначен для разработчиков программного обеспечения и является более высокоуровневым, чем, скажем, VAPI или AL [2].

IBGD включает также OpenSM (SM с открытым кодом), инструменты администрирования Mellanox Software Tools (MST) и IBADM, а также свежие версии прошивки (firmware) для коммутаторов и сетевых адаптеров, средства верификации IB и тестирования на физическом уровне. Кроме того, IBGD включает параллельную «удаленную» оболочку pdsh и две версии MPI — от Национального центра суперкомпьютерных приложений США и университета штата Огайо.

IBGD развивается так же быстро, как и Linux: за год с небольшим выпущено шесть версий. Более того, уже и к последней версии IBGD 1.8.0 в Mellanox предлагают загрузить «заплаты». После внесения изменений в исходный текст IBGD транслируется, создаются двоичные RPM-пакеты, которые затем и устанавливаются.

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

Низкоуровневое программное обеспечение

Коротко рассмотрим Mellanox Software Tools [3]; сюда же можно отнести не входящий в состав IBGD пакет Mellanox Firmware Tools (MFT) [4].

Средства MST в большей степени ориентированы на разработчика программного обеспечения для сетевых адаптеров и коммутаторов, чем на системного администратора. MST включает унифицированный драйвер и три однотипных набора средств — InfiniHost MST (hMST), Infiniscale III MST (is3MST), InfiniScale MST (isMST), различающиеся поддерживаемыми ими IB-устройствами.

Драйвер MST обеспечивает базовый доступ к аппаратуре Mellanox и включает модули ядра, библиотеку libmtcr.a, утилиты доступа mread/mwrite и удаленного доступа. Утилиты по умолчанию расположены в /usr/mst/bin. Для общего управления драйвером MST имеется сценарий mst. Команда

mst start,

которая обычно выполняется при загрузке операционной системы в самом начале загрузки программного обеспечения IB, в /dev/mst создаются специальные файлы для IB-устройств; загружаются модули ядра; заголовки PCI-конфигурации сохраняются в /usr/mst/etc/pci. Команда mst stop выполняет обратную последовательность действий, mst restart перезапускает MST, а mst status выдает информацию об устройствах из /dev/mst. Команда

mst reset

осуществляет сброс IB-устройства. Сценарий mst позволяет делать и более «тонкие» вещи — запустить или удалить сервер или удаленный сервер MST, загрузить или сохранить заголовки PCI-конфигурации.

С использовавшимися нами сетевыми адаптерами MT23108 применяются средства hMST, которые включают infinivision (графические средства для получения информации о модулях и содержимом регистров), iTrace (печать трассировочных сообщений) и др. Утилита FLINT работает в командной строке и позволяет проверить прошивку, «прожечь» двоичный образ прошивки или отдельное двойное слово в флэш-памяти IB-устройства, стереть сектор в этой памяти и т.п.

Вообще задаче обслуживания прошивки в Mellanox уделили много внимания. Имеется даже специализированный независимый от IBGD пакет MFT, в состав которого входят более универсальная утилита mlxburn, FLINT и spark (прожиг двоичного образа EEPROM для коммутаторов). MFT могут использовать внешнюю сеть управления между хостом, где выполняется менеджер прошивки, и сетевым адаптером или коммутатором.

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

Другие наборы средств MST содержат аналогичные утилиты (например, is3MST — is3infinivision, is3trace и is3burn для работы с EEPROM). В isMST утилита EMT является графическим средством для управления EEPROM; еще две утилиты — eburn и gz_burn (последняя может обслуживать несколько IB-устройств) работают с прошивкой в интерфейсе командной строки.

VAPI и базовые сервисы

Итак, стек программного обеспечения IBGD включает VAPI и базовые сервисы — интерфейс управления SMI/GSI, CM, интерфейсы администратора подсети (SA) и агента управления устройствами (DM). Этот стек включает компоненты, работающие как в составе ядра, так и в пользовательском режиме. Базовые сервисы работают как модули ядра и обеспечивают интерфейсы пользовательского режима.

В ядре можно выделить два основных блока, поддерживающих IB, — VAPI-драйвер и AL. При загрузке Linux общее управление загружаемыми модулями IBGD осуществляется через файл /etc/infiniband/openib.conf. Установка ONBOOT=yes в этом файле означает запуск драйвера HCA при загрузке, IPOIB=yes отвечает автоматической загрузке IPoIB, SDP_LOAD указывает аналогичным образом на загрузку модуля SDP, KDAPL_LOAD — на загрузку kDAPL; SRP_LOAD и SRP_TARGET_LOAD отвечают за загрузку соответствующих SRP-модулей. Вручную этим стеком можно управлять через сценарий /etc/init.d/openibd, имеющий традиционные ключи start, stop, restart, status.

Сами модули ядра пишутся в /lib/modules/версия_ядра/kernel/drivers/ infiniband, а какие модули загружать, описано в файлах /etc/modules-openib.conf для ядер 2.4 (/etc/modprobe-openib.conf для ядер 2.6), подключаемых через include в /etc/modules.conf. При запуске VAPI-драйвера выполняется modprobe mod_thh (для плат MT23108), и загружаются также модули mlxsys и mod_vip; сетевой адаптер открывается с портами, находящимися в неинициализированном состоянии.

При загрузке модулям можно передать ряд параметров, например, указать thh_legacy_sqp=1 (тогда сетевой адаптер будет работать во внутреннем режиме, не используя специальные пары очередей). Далее выполняется загрузка модуля mod_ib_mgt, при которой порты сетевого адаптера перейдут в инициализированное состояние, если они соединены с другими активными портами [6]. Чтобы вручную выгрузить драйвер, надо выдать modprobe -r на mod_ib_mgt, а затем на mod_thh.

Если при загрузке mst создаются файлы IB-устройств, то proc-интерфейс к IB (/proc/infiniband) появляется только после запуска сценария openibd. Общая информация о сетевом адаптере находится в каталоге /proc/infiniband/ca1. Она содержит данные обо всем устройстве, в том числе, версии прошивки, и о состоянии портов (подкаталоги port1 и port2), включая значения LID, счетчиков числа переданных и полученных байт и пакетов, число ошибок и др. Возможно также управлять режимами трассировки различных компонентов стека IBGD, изменяя параметры в файле /proc/infiniband/tracelevel.

Если openibd отработал корректно, на сетевом адаптере сервера, подключенного к IB-подсети, загорятся оба (зеленый и желтый) индикатора, и в выводе ifconfig появятся сетевые интерфейсы ib0 и ib1 (если, по умолчанию, активизируется IPoIB).

Для того чтобы посмотреть состояние сетевого адаптера, можно выполнить команду vstat. В ее выводе приводится используемая версия прошивки, состояние портов, значения LID и др. В комплект программного обеспечения HCA-драйвера включены тесты базовой функциональности IB, в том числе, vping (сервис UD) и rctp (сервис RC). Оба теста работают в форме пар «клиент-сервер».

Простейшая форма запуска vping-сервера (в ключе -p задается номер порта):

vping -p 1 -v -d

В ответ появится сообщение типа «vpingd: InfiniHost0 listening on; LID 0xB9 (port1) QP: 0x5001D ...». Эти значения LID и QP указываются при запуске клиента на другом хосте:

vping -p 1 0xB9 0x5001D,

В ответ при нормальной работе IB выдадутся сообщения о посылке клиентом, а затем о завершении сеанса со счетчиком ошибок, равном нулю. Для rctp серверный и клиентский режимы задаются в первом ключе (-server и -client соответственно), а далее могут указываться дополнительные ключи — размер MTU (-m), длина сообщения (-s) и др. Например, запуск сервера на порт 2 с выдачей «эхо» на команды от клиента (-r):

rctp -server -port 2 -r

и посылка клиентом 1000 команд серверу с IP-адресом 10.0.0.1:

rctp -client -r 10.0.0.1 -n 1000

Для оценки производительности IB в комплект HCA-драйвера входит утилита perf_main, также работающая в модели клиент-сервер. Все параметры, включая тип транспортного сервиса (-t ud/rc/uc), размер сообщения (-s), режим теста — для задержек или пропускной способности (-m lat или bw соответственно), номер порта (-p), число повторений посылок (-n) и др. задаются в одной команде, например

perf_main -send -trc -s128000 -n1000 -mbw

а на втором хосте нужно указать только IP-адрес первого:

perf_main -a10.0.0.1

В результате будет выдана достигнутая величина пропускной способности для RC.

Менеджеры подсетей

В руководстве по архитектуре IB описано, как осуществляется управление IB-устройствами. Чтобы уменьшить стоимость аппаратуры (по сравнению с традиционным подходом, использующим распределенное управление сетями) в IB остановились на централизованном подходе. Маршрутизация и управление отданы в распоряжение SM [8]. В составе IBGD имеется два SM — minism, утилита из комплекта программного обеспечения HCA-драйвера, и пакет OpenSM.

Относительно простая утилита minism решает базовые задачи — установление физической топологии подсети, присвоение значений LID конечным узлам и установление путей между ними, активизация логических каналов. minism, как и некоторые компоненты OpenSM, использует Tcl. При вызове minism можно указать номер порта (в ключе -p, по умолчанию 1) и имя сетевого адаптера:

minism -p 2 InfiniHost0

После этого minism переходит в режим ввода подкоманд. Так, указав ?d?, можно установить физическую топологию подсети; указав ?r?, можно сгенерировать таблицы маршрутизации, а указав ?b? — «взвести» логические каналы. В типичном случае можно ввести подкоманду ?x?, которая выполнит все необходимое вместе, а затем выйти из minism, набрав ?q?.

OpenSM включает три основных утилиты — opensm, osmsh и osmtest, а также разделяемую библиотеку osm_svc. Основное орудие системного администратора — opensm. Это исполняемый модуль, который реализует все необходимые функции SM по инициализации IB-аппаратуры для стандартных случаев. В простейшей ситуации модуль opensm вызывается вообще без параметров. Указав ключ -V, можно получить наиболее подробную информацию об ошибке (при задании -v устанавливается «средний» уровень детальности). При указании -o произойдет однократное конфигурирование подсети и выход из opensm; по умолчанию «осмотр» подсети осуществляется каждые 10 секунд, что можно изменить в параметре -s. Если задать в ключе -l значение LMC>0, то число LID, присваиваемых порту, установится равным 2^LMC (по умолчанию — один LID на порт). Это необходимо делать для подсетей, имеющих больше одного пути между портами.

Для вызова opensm в IBGD имеется специальный сценарий /etc/init.d/opensmd c традиционными ключами start/stop/status/restart. После выполнения opensm start остаются работать несколько процессов opensm. При получении сигнала HUP opensm запускает новую попытку инициализации, как если бы изменилась топология подсети [8].

Сообщения opensm заносятся в системный журнал /var/log/messages, а также в собственный журнал /tmp/osm.log (последний можно переназначить при вызове opensm, указав в ключе -f другое имя файла). В первый отправляется информация о наиболее важных событиях, а во второй — детальная информация об ошибках. В обоих журналах при корректном срабатывании opensm помещается сообщение «SUBNET UP».

В opensm 1.20 появились переменные окружения. Временные файлы (subnet.1st, osm.fdbs, osm.mcfdbs) пишутся в каталог OSM_TMP_DIR (по умолчанию — /tmp). В каталог OSM_CACHE_DIR (по умолчанию — /var/cache/osm) записываются данные, используемые для согласования при последующих вызовах opensm.

osmsh использует Tcl и является средством, позволяющим применять полный набор команд OpenSM наиболее гибким способом, однако в типичных практических ситуациях достаточно opensm. Утилита osmtest может использоваться для тестирования с применением как opensm, так и osmsh. В Mellanox рекомендуют после установки OpenSM выполнить «osmtest -f c», чтобы сгенерировать файл (по умолчанию — osmtest.dat в /tmp) с «описью» всех узлов, портов и путей между ними. Затем рекомендуется прогнать полный набор тестов OpenSM, выдав «osmtest -f a»; osmtest.dat используется при этом в качестве исходных данных. Кроме того, целесообразно время от времени выполнять тест «osmtest -f v», проверяющий, что этот файл по-прежнему соответствует реальному состоянию IB-аппаратуры.

IB и сокеты

В IBGD с сокетами работают два компонента — IPoIB и SDP. Драйвер IPoIB занимается инкапсуляцией IP-датаграмм в сообщения IB. Спецификаия IPoIB описана в двух документах IETF (www.ietf.org). При инкапсуляции к IP-датаграммам добавляется инкапсуляционый заголовок, а посылка осуществляется с использованием сервиса UD.

Внешне применение IPoIB выглядит как обычная работа с TCP/IP поверх Ethernet, но в ifconfig вместо eth0 и eth1 появляются ib0 и ib1. Единственное, заготовки для конфигурирования портов ib0 и ib1 (содержащие IP-адрес, маску сети, адрес для широковещательной рассылки и т.д.) находятся в другом месте — в /etc/infiniband/ifcfg-ib0 и аналогично — для ib1. Дополнительная информация об этих «виртуальных устройствах» доступна через интерфейс /proc.

SDP — транспортный протокол, использующий сервис RC и полностью аналогичный TCP в том смысле, что все системные вызовы могут прозрачным образом переадресоваться не к стандартной библиотеке, а к библиотеке libsdp.so, и при этом исполняемые модули приложения будут работать (перекомпиляция не нужна). Для этого нужно установить переменную среды LD_PRELOAD, чтобы она указывала на эту библиотеку (или добавить эту библиотеку в /etc/ld.so.preload). Возможно и заставить программу работать только с SDP, для чего ее надо перекомпилировать, лишь заменив AF_INET на константу AF_INET_SDP, определенную в sdp_inet.h.

Цель применения SDP — улучшить производительность по сравнению с неэффективным TCP. Это достигается за счет использования возможностей IB по разгрузке процессора при обслуживании протокола и устранения избыточного копирования в памяти [3].

В конфигурационном файле libsdp.conf, на который должна указывать переменная LIBSDP_CONFIG_FILE, можно задать, какие программы будут работать через SDP, и — отдельно для клиентской и серверной частей — ограничить его применение определенными IP-адресами и номерами портов.

Работу SDP обеспечивает также модуль ядра ib_sdp, который должен быть загружен до установки переменных окружения. После его загрузки и установки этих переменных (предполагается, что libsdp.conf настраивается заранее) можно вызывать TCP-приложения обычным образом, и они будут работать через SDP.

ib_sdp может работать в двух режимах — Bcopy (данные перед посылкой копируются в собственный SDP-буфер) и Zcopy, («нулевое» копирование, использует RDMA при прямом синхронном обмене данными между буферами приложений). Zcopy эффективнее при работе с длинными сообщениями; для загрузки ib_sdp в этом режиме требуется указать порог в байтах (_src_thresh), по достижению которого длиной сообщения оно будет передаваться в режиме Zcopy:

modprobe ib_sdp _use_zcopy=1 _src_thresh=число_байт.

IBADM

IBADM — пакет программ для мониторинга, поддержки и конфигурирования IB-аппаратуры, обеспечивающий унифицированный способ управления (как In-Band, так и Out-of-Band) всеми IB-устройствами от Mellanox. IBADM основан на программных агентах, работающих на каждом сетевом адаптере и коммутаторе IB-фабрики, — так называемых серверах шин (bus server, BS). Серверы шин используют механизм сокетов, ожидая соединения от клиентов, и отвечая на получаемый от них стандартный набор команд («получить список IB-устройств», «прочитать/записать в конфигурационный регистр IB-устройства», «сбросить устройство» и т.п.).

В зависимости от типа физической шины, связывающей сервер шины с IB-устройствами, имеются In-Band BS (IBBS) и Out-of-Band BS (OBBS): PCI OBBS или I2C-OBBS. По умолчанию PCI OBBS выполняется на каждом хосте, имеющем сетевой адаптер. I2C OBBS входит в состав встроенного программного обеспечения управляемых коммутаторов Melanox. IBBS, работая поверх IB-фабрики, управляет всеми IB-устройствами подсети, взаимодействуя с локальными администраторами подсети.

Приложения IBADM взаимодействуют с серверами шин, используя указанные выше команды. В IBADM входит специальное приложение — сервер имен IB-устройств; он собирает данные об устройствах от IBBS и OBBS, обеспечивая интерфейс имен для других приложений IBADM.

В типичной ситуации один хост работает с IBBS, а другие IB-cистемы (узлы и управляемые коммутаторы) — с OBBS, при этом IBADM инсталлируется на всех узлах. Для конфигурирования IBADM требуется создать файл /etc/ibadm.conf (изменив имеющиеся в заготовке параметры IBBS_HOST на имя хоста с IBBS), и размножить этот файл на узлы кластера. Нужно также создать /etc/ibadm.hosts, поместив туда имена или IP-адреса IB-cистем. Трансляция этих имен должна осуществляться обычным для TCP/IP способом, а файл ibadm.hosts может содержать просто по одному имени на строку. В результате становится возможной работа утилит IBADM с применением OBBS (Ethernet/PCI/I2C) для доступа к IB-устройствам — в случае, если IBBS-cоединения не будут работать.

Третий конфигурационный файл IBADM — файл топологии /etc/ibadm.topo, который описывает IB-коннективность кластера. Расположение ibadm.topo можно изменить параметром IBBS_TOPO_FILE в ibadm.conf. IBADM использует файл топологии при создании отчетов с использованием имен систем из этого файла, проверяя заодно соответствие файла реальной топологии соединения, что позволяет IBADM обнаруживать и сообщать об ошибке типа отсутствия соединяющих кабелей или неверных соединений.

После подготовки конфигурационных файлов инициализация IBADM происходит после выполнения команды ibadm start (для каждого узла); для опроса состояния сервера следует выполнить ibadm status, а в случае изменения файла топологии — ibadm restart.

Файл топологии состоит из секций; каждая из них описывает коннективность одной системы. Секция начинается с заголовка, содержащего тип системы (модель коммутатора или сетевого адаптера), локальное имя системы и, возможно, дополнительные детали конфигурации [5]. В следующих строках для каждого имени локального порта системы задается тип удаленной системы, имя удаленной системы и имя удаленного порта. Заканчивается секция пустой строкой. Простейший пример секции, описывающей связность коммутатора MTS2400 с двухпортовыми сетевыми адаптерами в кластере:

MTS2400 S-1

P1-> MT23108 H-1 P1

P2-> MT23108 H-1 P2

P3-> MT23108 H-2 P1

P4-> MT23108 H-2 P2

...

Здесь первая строка описывает коммутатор, а последующие строки для каждого порта коммутатора задают, с каким типом системы (MT23108), имеющей какое имя (H-1, H-2, ...) и с каким ее портом связаны.

Файл топологии описывает IB-фабрику в удобных системному администратору терминах — именах и типах систем. При создании этого файла для больших кластеров удобно воспользоваться утилитой ibtopogen, которая генерирует данный файл для IB-фабрик, имеющих топологию «толстого дерева».

Кроме ibtopogen, в состав IBMON входят следующие утилиты: ibcon — для чтения конфигурационных регистров IB-устройств; ibls — для получения списка IB-систем, устройств и кабелей в подсети; ibmon — для мониторинга устройств и систем; ibfwmgr — для работы с прошивкой.

Все эти утилиты работают с IB-фабрикой в целом. Так, формат вызова ibls:

ibls [ключи] [-g GUID] [-n имя] [-i имя_устройства] [-e],

где ключи задают, какая именно информация будет выводиться, параметры GUID, «имя_устройства» и «имя» позволяют ограничить вывод информацией об устройствах с данным GUID, с данным «именем_устройства» и с данными именами систем/каналов. Ключ -e задается для проведения проверки топологии соединения (по умолчанию не производится). Если выдать ibls без параметров, будет получена информация обо всех системах, устройствах и каналах.

Утилита ibmon позволяет выдавать отчеты о «здоровье» IB-фабрики — о ее состоянии, трафике, сбоях и т.п. Для этого в ключах ей могут быть переданы пороговые значения (например, уровня температуры, счетчика числа восстановлений каналов и т.д.).

Наконец, ibfwmgr позволяет установить или заменить прошивки во всем кластере или в отдельных устройствах, а также получить информацию об установленной прошивке. Эта утилита по умолчанию работает через OBBS, а если это не удается, автоматически переключается на IBBS.

Также в состав IBADM входит утилита mlxburn, не зависящая и от других компонентов IBADM, и вообще от программного обеспечения IB. Утилита работает только с прошивкой локального сетевого адаптера или коммутатора. Ее вызов:

mlxburn [-dev mst-устройство | -wrimage файл_образа_FW]

[-fw файл_FW_Mellanox | -image файл_образа_FW]

[- format BINARY | IMG] [-conf файл_конфигурации_FW]

Работа mlxburn состоит из двух стадий: генерация образа (-wrimage) и его прожиг. На первой стадии прошивка «от Mellanox» преобразуется в генерируемый образ; на второй этот образ прожигается (переносится во флэш-память). По умолчанию mlxburn выполняет сразу обе стадии. В ключе -dev задается IB-устройство, в которое записывается образ, а в -fw указывается имя поставляемого Mellanox файла прошивки.

Если не указать -dev, прожига не будет, а если указать -image, утилита пропустит стадию генерации образа, используя образ, задаваемый данным ключом. При необходимости тонкая настройка прошивки на конкретный сетевой адаптер с установкой необходимых параметров может осуществляться через задаваемый в -conf конфигурационный файл [5].

Измерения производительности

Результаты различных измерений производительности, призванных доказать лидерство IB, можно найти, в частности, на сайте Mellanox. В основном они касаются рекордов производительности при распараллеливании с использованием MPI. Мы ставили перед собой совсем иную цель — изучить, как IB ведет себя на серверах с относительно скромными процессорами (Opteron 242 с платой Tyan S2880 и шиной PCI-X/133) и сетевыми адаптерами (MTLP23108 с 128 Мбайт памяти на плате), а также с не самыми последними версиями программного обеспечения (ядро 2.4.21-SMP/x86-64 в составе SuSE Linux 9.0, IBGD-1.6.1). Понятно, что более новые платы с PCI-Express с более быстрыми процессорами для более новых ядер 2.6 и версий IBGD могут дать более высокие результаты.

Кроме того, мы хотели посмотреть производительность на разных приложениях, а не только в MPI.

Так, в тестах perf_main для сообщений размером 256000 байт была получена пропускная способность около 796 Мбайт/с и задержка (для сообщений нулевой длины) около 5,9 мкс (при измерениях два двухпроцессорных узла были соединены напрямую без коммутатора). Загруженность процессора во время этого теста близка к 100%.

Для измерений производительности стека протоколов TCP при работе с IPoIB были использованы тесты netperf 2.3 [9]. Год назад, когда только появилась первая версия IBHPC 0.5.0, обнаружилось, что получаемые показатели производительности гораздо ниже, чем можно было бы ожидать. Пропускная способность оказалась крайне далека от потенциального предела 10 Гбит/с: в TCP_STREAM достигались показатели не более 1633 Мбит/с, в то время как Gigabit Ethernet в тех же условиях давал 939 Мбит/с. В тестах TCP_RR для однобайтовых сообщений ускорение по отношению к Gigabit Ethernet было близким: 15985 против 10031 транзакций в секунду. UDP_STREAM при работе с IPoIB также дает пропускную способность, немного большую 1,5 Гбит/с.

При переходе к IBGD 1.6.1 достигаемая в тестах TCP_STREAM пропускная способность осталась примерно на том же уровне 1,5 Гбит/с. Измерения на тестах netperf 2.3 были проведены нами также в IB-кластере, в узлах которого использовались двухпроцесорные серверы с более быстрыми процессорами Xeon Nocona/3,2 ГГц, и аналогичные сетевые адаптеры для IB 4x от Mellanox, но для шин PCI-Express. Вероятно, из-за большой нагрузки процессора в тестах TCP_STREAM работа с более быстрыми процессорами позволила достичь более высокой пропускной способности — 2386 Мбит/с. В тестах TCP_RR, в которых нагрузка на процессор гораздо ниже, ускорения почти не наблюдалось — до 16082 транзакций в секунду.

Более высокую пропускную способность при более низких задержках и более низкой процессорной нагрузке обеспечивает работа с сокетами SDP. В Opteron-кластере c IBGD-1.8.0 на netperf 2.4 была достигнута пропускная способность в TCP_STREAM до 5333 Мбит/с в режиме Zcopy и 2294 Мбит/с при работе в режиме Bcopy. В TCP_RR с однобайтовыми сообщениями достигнутая производительность составила 14355 транзакций в секунду в режиме Bcopy. Процессорная нагрузка на этих тестах в режиме Bcopy близка к 50%, в то время как в Zcopy она составляет порядка 10%.

Высокая производительность TCP/IP важна и для распараллеливания в кластерах, поскольку некоторые средства распараллеливания, например, Linda и DDI, работают поверх TCP/IP. Мы измеряли также производительность и на стандартных тестах MPI с использованием MPICH 0.9.4 разработки университета штата Огайо. Собственные «стандартные для этого пакета» тесты дают величину задержки 5,2 мкс.

В известных тестах Pallas 2.2 измерения проводятся для многих типичных MPI-вызовов, включая коллективные операции, при различных длинах сообщений. В тесте SendRecv максимальная пропускная способность, 758 Мбайт/с, была получена при длине сообщения в 256 Кбайт (в тесте ping-pong пропускная способность достигает при этом 695 Мбайт/с). Задержки в тесте ping-pong при длине сообщения до 4 байт не превышают 5 мкс, в тесте SendRecv при длине сообщения до 4 байт — не больше 5,85 мкс, в тесте bcast при длине сообщения до 8 байт — не больше 5 мкс; на операцию barrier уходит около 5,8 мкс (все измерения проведены для двух узлов, по одному процессу на узел).

В коммуникационном тесте из состава пакета Presto MPI дал максимальную пропускную способность 717 Мбайт/с при однонаправленной передаче (сообщения размером 4 Мбайт) и 809 Мбайт/с при двунаправленной передаче (сообщения размером 0,5 Мбайт). Задержки в тесте двунаправленной передачи близки к 8 мкс.

Еще одна иллюстрация преимуществ IB — ускорение при распараллеливании в IB-кластере на базе процессоров Nocona, достигаемое в разрабатываемой программе прямого построения матрицы плотности больших органических молекул. Программа, распараллеленная в MPI, является примером, когда ограничивающим фактором является пропускная способность межсоединения. Измеренные величины ускорений при равном числе процессоров оказались выше, чем достигнутые в Myrinet-кластере, использующем процессоры с близкой к Nocona производительностью на данной программе. Преимущество IB возрастало с числом процессоров; на шести процессорах ускорение в кластере IB на 37% выше, чем в кластере Myrinet.

Настоящее, будущее и конкуренты

Пиковый уровень пропускной способности 10 Гбит/с у IB 4x задает планку для конкурентов. Кроме упомянутого 10-Gigabit Ethernet следует отметить недавний анонс нового поколения кластерного межсоединения Myrinet 10G.

Однако IB снова уходит вперед. Mellanox объявила о новых коммутаторах и сетевых адаптерах InfiniHost III, использующих технологию MemFree (в ней вместо локальной памяти применяется память системы, что удешевляет решение) и память DDR. Эти сетевые адаптеры разработаны для PCI-Express x4 и x8 и имеют пропускную способность порта вдвое выше — 20 Гбит/c. В SDP удается при этом получить пропускную способность, близкую к 1100 Мбайт/с [10]. Достигаемая в MPI пропускная способность однонаправленной передачи составляет 1475 Мбайт/с, задержка — 2,7 мкс. В ноябре 2005 года в новой версии OSU MPI достигнута пропускная способность 1502 Мбайт/с. Соответственно и пропускная способность соединения коммутаторов увеличена до 60 Гбит/с. А стоимость такого DDR-оборудования всего на 30% выше, чем у «обычного». Возможно, появится и QDR-вариант IB.

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

Литература
  1. Infiniband Architecture Specification, Release 1.2, Volumes 1-2.
  2. IB Gold Distribution Stack User?s Manual, Rev.1.8.0, Mellanox Technologies, 2005.
  3. Mellanox Software Tools (MST) User?s Manual, Rev.4.20, Mellanox Technologies, 2005.
  4. Mellanox Firmware Tools User?s Manual, Rev. 0.10, Mellanox Technologies, 2005.
  5. Infiniband Administration Package User?s Manual, Rev. 1.3.0, Mellanox Technologies, 2005.
  6. Linux HCA Driver for InfiniHost and InfiniHost III HCA families, Rev. 4.1.0 Release Notes, Mellanox Technologies, 2005.
  7. InfiniHost SDK User Guide. Linix Platforms, Rev. 1.20, Mellanox Technologies, 2002.
  8. OpenSM User?s Manual, Rev. 1.20, Mellanox Technologies, 2005.
  9. Михаил Кузьминский, А. Мускатин, Fast Ethernet в кластерах Beowulf. «Открытые системы», № 7-8, 2001.
  10. D. Goldenberg, M. Kagan, R. Ravid, et. al., Transparrently Achieving Superior Socket Performance using Zero Copy Socket Direct Protocol over 20 Gb/s Infiniband Links. Mellanox, White Paper, 2005.

Михаил Кузьминский (kus@free.net) — старший научный сотрудник Института органической химии РАН. Работа поддержана РФФИ, проект 04-07-90220. Автор выражает также благодарность компании «Т-платформы» за предоставленную возможность удаленного доступа к кластеру на базе Xeon Nocona.