Глава 2. Как устроен суперкомпьютер

Рассмотрим «анатомию» вычислительного кластера: из каких компонент он состоит? В зависимости от размера и архитектуры конкретного кластера некоторые компоненты могут объединяться. Далее мы часто будем писать «узел» – это синоним слова «сервер», но в HPC так принято.

Итак, обязательная часть любого кластера – вычислительные узлы, или так называемое счётное поле. Это серверы, на которых будут считаться задания. Кроме вычислительных узлов должен быть как минимум один управляющий узел, в больших системах к нему добавляются дополнительные служебные узлы, их может быть несколько десятков. Для эффективной совместной работы вычислительных узлов необходимы сети:

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

• управляющая, по которой происходит удалённый доступ на узлы, запуск заданий и т. п.;

• одна или несколько служебных – для доступа к сетевой файловой системе, управления через протоколы IPMI или iKVM, дополнительной синхронизации (прерываний, тактовой частоты, барьеров и т. п.) и, возможно, другие.

Обязательный компонент современного вычислительного кластера – сетевая файловая система.

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

Управляющий узел

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

Вычислительный узел

«Рабочая лошадка» кластера – счётное поле. Как правило, тут все узлы одинаковой конфигурации, но иногда в поле могут входить узлы двух и более конфигураций. Чем однороднее состав вычислительных узлов, тем проще ими управлять, тем проще работать планировщику. Создавать смешанные конфигурации стоит только в тех случаях, когда вы уверены, что все(!) они будут активно использоваться заданиями.

Аппаратная начинка вычислительного узла полностью определяется характером заданий, которые будут решаться на кластере, но всегда нужно стараться сбалансировать состав «железа», чтобы не возникло узких мест, например, таких, как большое число ядер при узком канале в память, недостаточная ширина канала в вычислительную сеть и т. п. Наличие жёсткого диска имеет как плюсы, так и минусы. Минусы – дополнительное место и энергопотребление с тепловыделением, а также высокая вероятность выхода из строя. В блейд-конфигурациях всё это особенно актуально. Плюсы – возможность установить локальную копию ОС, что сильно упрощает процедуру включения, ускоряет загрузку системных библиотек (а значит, и старт программ), а также возможность добавить swap-пространство и локальный каталог /tmp. Это значительно повышает эффективность работы памяти.

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

На вычислительном узле вполне можно отказаться от таких сервисов, как почта (можно отправлять сообщения через головной узел), cron (самые важные задания можно выполнять по ssh также с головного узла), udev, acpid и т. п. Оставьте только самые необходимые, а вместо udev, если возможно, используйте заранее созданные файлы устройств – они всё равно не будут меняться со временем. Самые важные сервисы для вычислительного узла – sshd и клиент сетевой файловой системы. Очень желательно настроить мониторинг работы узла. В некоторых современных дистрибутивах отключить udev невозможно: от него зависят важные сервисы (systemd, например). В этом случае оставьте его, не пытайтесь «обмануть» систему. Как правило, все вычислительные узлы логически объединяются в разделы (или очереди) в рамках системы управления заданиями. Если в поле есть узлы разных конфигураций, то удобно создать разделы для каждой конфигурации отдельно. Иногда бывает полезным объединить несколько вычислительных узлов в один раздел для запуска небольших тестовых заданий (тестовая очередь), при этом полезно ограничить время счёта таких тестовых заданий (например, 15–20 минут).

Служебные узлы

Все узлы, не включённые в счётное поле, – служебные. Совмещать функции вычислительного и служебного узла (например, NFS-сервера) крайне не рекомендуется, так как это наверняка приведёт к разбалансировке работы заданий и повышению вероятности отказа сервиса. Существует несколько ролей, которые выполняют служебные узлы, но часто один сервер выполняет несколько ролей, а то и все сразу.

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

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

Практически в любом кластере есть сетевая файловая система, а значит, и сервер для неё, а нередко – целая ферма, если файловая система распределённая. Довольно распространённым служебным узлом является лицензионный сервер, на котором располагаются специальные службы, отвечающие за лицензирование коммерческих программ и утилит. Например, может использоваться сервер лицензий FlexLM для нескольких коммерческих пакетов. Расположение лицензионных служб на отдельной машине оправдано как с точки зрения безопасности (защита от кражи лицензионных файлов), так и с точки зрения повышения отказоустойчивости комплекса в целом. Обязательно запишите MAC-адрес этого сервера, при его внезапной замене для большинства программ будет достаточно установить на новом сервере старый MAC-адрес. И не забудьте запросить перевыпуск лицензии для нового сервера, конечно, с его настоящим MAC-адресом.

В современных вычислительных комплексах довольно часто встречаются узлы подготовки входных и обработки выходных данных (так называемые узлы пред/постобработки, от англ. pre- и postprocessing). Такие узлы отличаются бóльшим объёмом оперативной памяти, чем на остальных узлах (256 Гбайт и более), что крайне важно для подготовки больши́х заданий и обработки результатов расчётов.

Часто полезными являются так называемые узлы визуализации. Обычно это выделенные серверы со специальными графическими картами для обработки визуальной информации и выдачи готовой картинки через сеть удалённому пользователю. Это бывает удобным, в частности, для удалённой подготовки заданий к расчёту (например, для визуализации сеток и иных входных данных). Узлы визуализации могут играть роль узлов пре/постобработки.

Для организации распределённого хранилища данных могут быть использованы узлы хранения данных. К каждому такому узлу подключается своё собственное дисковое хранилище, а все узлы хранения объединяются в единую сеть с общим доступом к файловой системе со всех узлов (подробнее об этом – в следующем разделе).

Среди служебных узлов также могут быть выделенные узлы:

• резервного копирования;

• удалённой загрузки;

• развёртывания ПО;

• авторизации и аутентификации;

• удалённого журналирования;

• сбора и обработки данных мониторинга;

• сбора и отображения статистики и состояния оборудования;

• служебных баз данных;

• и др.

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

Сетевое оборудование

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

Наиболее серьёзные требования предъявляются к коммуникационной сети. Для характеристик возможностей сетей используются два основных параметра: пропускная способность и латентность.

Пропускная способность характеризует, какой наибольший объём информации может быть передан в единицу времени (чаще всего это секунда). Производители сетевого оборудования нередко указывают пиковую пропускную способность. В реальных приложениях, как правило, наблюдается скорость в 1,5‒2 раза ниже пиковой. Термин латентность (задержка) – это чистое время на передачу сообщения нулевой длины. Оно в первую очередь зависит от времени, затрачиваемого сетевыми устройствами и системой на подготовку к передаче и получению информации.

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

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


Таблица 1: некоторые характеристики сетевых технологий


В таблице 1 приведены наиболее применяемые в кластерах сетевые технологии и их типичные характеристики. При проектировании сетей для вычислительных кластеров следует рассмотреть ещё один немаловажный вопрос – цену. Если не вдаваться в детали, то каждая сетевая карта высокоскоростной сети стоит около 1 000$, а цена коммуникатора может колебаться от 10 000$ до 1 000 000$ и выше. На сегодняшний день наиболее популярной технологией при построении кластеров для создания сетей обмена данными является технология InfiniBand. Причины её популярности связаны с хорошим соотношением между ценой и возможностями оборудования, доступностью программного обеспечения.

Некоторые сети могут использовать лишь один вариант топологии (способа коммутации узлов сети). Например, GigabitEthernet поддерживает только топологию «звезда», но так как в реальных приложениях она используется только совместно с TCP/IP, то допускается объединять несколько «звёзд» каналами, настроив маршрутизацию.

InfiniBand позволяет использовать практически любые топологии, которые поддерживаются установленным Subnet Manager. Стандартные реализации Subnet Manager поддерживают топологии «звезда», «дерево», «толстое дерево», «гиперкуб», но появляются и новые реализации. За счёт того, что в InfiniBand допускаются множественные маршруты, для средних конфигураций неплохо подходит топология «толстое дерево», которая хорошо использует дублирующиеся каналы. Топология – важный фактор эффективности сети. Наличие «узких мест» в топологии может свести на нет высокую скорость сети. Например, два GigabitEthernet-коммутатора, соединённых одним каналом, – явно не лучшее решение. А если соединять их несколькими каналами, то необходимо позаботиться о том, чтобы они объединялись на уровне коммутатора. Такое объединение поддерживается многими видами сетевого оборудования, существуют стандартные технологии, например EtherChannel, bonding, trunking. Важно заранее убедиться, что все стороны, участвующие в таком объединении, используют одинаковые стандарты (например, bonding может быть реализован по-разному у разных производителей).

InfiniBand

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

Развитием InfiniBand занимается альянс InfiniBand Trade Association, InfiniBand – это открытая технология, стандарты которой опубликованы и доступны. Также есть набор программного обеспечения c открытым исходным кодом OFED (OpenFabrics Enterprise Distribution), в котором содержится все необходимое для работы в сетях, построенных на основе InfiniBand (возможно, кроме драйверов адаптеров). Компании-производители оборудования InfiniBand могут выпускать и свои версии стека программного обеспечения. Чаще всего они включают в себя OFED и дополнительные компоненты, ориентированные на работу с оборудованием конкретного производителя.

Связь (link) в сети InfiniBand состоит из нескольких линий (lanes), работающих параллельно. Каждая линия работает как последовательный двунаправленный канал связи. Чаще всего используются связи 4x (четыре линии, работающие параллельно). Связи 12x используются для связи отдельных элементов, чаще всего микросхем коммутаторов, внутри одного большого коммутатора. Скорость передачи данных по линии зависит от поколения стандарта InfiniBand. Для передачи данных могут использоваться соединения на печатной плате, медные провода (для небольших расстояний) и оптические кабели, часто продающиеся уже с трансмиттерами. Сведения о скоростях передачи данных приведены в таблице 2.

В материалах по сетям InfiniBand обычно указывается «сырая скорость» (raw speed) передачи данных, т. е. та скорость, с которой данные передаются физически по среде передачи. При этом данные пользователя перед передачей кодируются для восстановления при возможных ошибках на линии. Для поколений SDR-QDR 8 бит пользовательских данных превращаются в 10 бит, которые надо передать, для поколений FDR-EDR используется кодирование 64/66. Поэтому доступная для передачи данных пользователя пропускная способность будет ниже, чем указанная в спецификации.


Таблица 2: производительность сетей InfiniBand


В каждое устройство, подключённое к сети InfiniBand (узел кластера, который в материалах по InfiniBand часто называют процессорным узлом, Processor Node, сервер системы хранения и т. п.), устанавливается адаптер канала хоста InfiniBand (HCA, Host Channel Adapter). Стандарт предусматривает упрощённый вариант HCA, называемый TCA (Target Channel Adapter), который предполагалось использовать для подключения систем хранения данных, но этот вид адаптеров не получил распространения.

Адаптер может иметь несколько портов (ports) для подключения к сети. Сеть InfiniBand (ещё говорят про фабрику InfiniBand, InfiniBand Fabric) состоит из адаптеров, которые соединяются при помощи коммутаторов (switches) и маршрутизаторов (routers). Коммутаторы и маршрутизаторы всегда имеют более одного порта. На каждом коммутаторе выделяется виртуальный порт 0, через который коммутатором можно управлять.

Порты, на которые могут быть направлены пакеты, называются оконечными (endports). Набор адаптеров, соединённых при помощи коммутаторов, составляет подсеть (subnet). Подсети имеют ограничение на количество устройств, которое в ней может содержаться, – не более 215 + 214 – 1 = 49 151 оконечных портов и коммутаторов. Подсети соединяются при помощи маршрутизаторов, позволяя создавать фабрики InfiniBand практически неограниченных размеров.

Идентификация компонентов и адресация в сетях InfiniBand

Компоненты сети InfiniBand имеют идентификаторы, которые называются GUID (Globally Unique ID, глобально уникальный идентификатор), длиной в 64 бита. В зависимости от типа устройства, таких идентификаторов может быть несколько. GUID назначаются производителем устройства, хотя могут иметься средства для их изменения. Каждый адаптер имеет NodeGUID и по одному PortGUID на каждый порт адаптера. Один из PortGUID может совпадать с NodeGUID адаптера. Коммутатор также имеет NodeGUID и PortGUID, однако все PortGUID должны быть одинаковыми для всех портов коммутатора.

Также есть идентификатор, называемый SystemImage GUID. Его назначение – дать возможность определить, какие компоненты составляют единую систему (находятся под управлением одной программы). Для многопортовых коммутаторов, например, этот параметр одинаков для всех элементарных коммутаторов, составляющих один большой составной коммутатор. Для адаптеров, установленных в один сервер, этот параметр будет различаться, так как каждый адаптер имеет независимую управляющую программу (то, что по-английски называется firmware). SystemImage GUID может быть равен NodeGUID одного из компонентов, составляющих единую систему, или быть нулевым, если компонент не входит ни в какую систему (или производитель не хочет дать возможность определения компонентов своей системы).

GUID используются для идентификации компонентов сети InfiniBand, то есть для того, чтобы отличить один компонент от другого. Они не используются как адреса при передаче данных. В качестве адресов при передаче данных внутри подсети используются LID (Local ID, локальный идентификатор). Для передачи данных между подсетями в качестве адресов используются GID (Global ID, глобальный идентификатор). GID могут использоваться и для передачи данных внутри одной подсети, но адресация при помощи GID требует присутствия в пакете с данными дополнительного заголовка GRH (Global Routing Header, заголовок глобальной маршрутизации), что увеличивает размер служебной информации в пакете данных.

Локальный идентификатор LID имеет длину в 16 бит. Значение LID = 

0
зарезервировано и не может быть использовано; LID от 
1
до 
0xBFFF
предназначены для обычных LID, используемых при передаче точка-точка (unicast): LID от 
0xC000
до 
0xFFFE
предназначены для организации многоадресной передачи (multicast); LID = 
0xFFFF
– так называемый разрешительный LID (permissive LID), пакет, адресованный такому LID, будет обработан первым портом, его получившим. Каждому оконечному порту и каждому коммутатору (LID назначается коммутатору в целом, а не отдельным его портам) в подсети во время её инициализации назначается минимум один LID, при этом внутри одной подсети LID не могут повторяться.

Из доступного количества LID и вытекает ограничение на количество устройств в подсети. Именно при помощи LID получателя пакета коммутаторы определяют, на какой порт надо передавать полученный пакет: записи в таблице форвардинга коммутаторов (forwarding table) в качестве ключа используют именно LID. Для упрощения обработки подсетей, в которых имеется много возможных альтернативных маршрутов между заданными парами точек, порту или коммутатору может назначаться несколько LID. В этом случае назначается базовый LID (Base LID) и LMC (LID Mask Control, управляющая маска LID). LMC – это число от 0 до 128.

Младшие LMC бит базового LID должны быть равны нолю, и считается, что порту назначены 2LMC подряд идущих значений LID, т. е. значения от Base LID до Base LID + 2LMC – 1. Если на порт назначается только один LID, то LMC = 

0
. Обычно в одной подсети используются не более двух значений LMC: одно для назначения LID портам адаптеров и другое (чаще всего ноль) для назначения LID коммутаторам.

Глобальный идентификатор GID имеет длину в 128 бит. Он назначается каждому оконечному порту. Фактически, GID – это адрес IPv6, в котором младшие 64 бита – это GUID порта, которому назначен этот GID. Старшие 64 бита GID (GID Prefix, префикс GID) по умолчанию равны 

0xFE80::/64
(подробности по текстовому представлению адресов и префиксов IPv6 см. в RFC2373). Область действия этого префикса – подсеть (link-local scope). Пакеты данных с GID назначения, имеющим такой префикс, не будут переданы маршрутизаторами между подсетями, т. е. GID с такими префиксами могут использоваться только для передачи данных внутри подсети. При инициализации подсети может быть назначен один (или ни одного) префикс GID, отличный от префикса по умолчанию. При этом GID с префиксом по умолчанию все равно должен работать как GID порта.

Префикс 

0xFEC0::/64
– префикс с сайтовой областью действия (site-local scope). Пакеты данных, предназначенные таким адресам, могут передаваться маршрутизаторами из подсети в подсеть, но не должны покидать пределы сайта (области с единым администрированием адресного пространства). Также может быть назначен префикс с глобальной областью действия (global scope), он должен выбираться по правилам, установленным для адресов IPv6. Кроме одноадресных (unicast) GID есть и GID, предназначенные для многоадресной (multicast) передачи данных. Префикс многоадресных GID имеет старший байт 
0xFF
, про значение остальных бит префикса можно подробнее прочитать в RFC2373 и RFC2375.

Кроме адресации при помощи LID и GID есть еще один способ адресации, адресация при помощи направленного маршрута (Directed Route). Этим способом можно адресовать только пакеты управления подсетью (Subnet Management Packet, SMP). Он используется в основном при начальной инициализации подсети, когда портам еще не назначены LID и не установлены таблицы форвардинга коммутаторов, или после перезагрузки адаптера или коммутатора, когда доступ к ним при помощи LID ещё невозможен. В режиме адресации при помощи направленного маршрута в пакете перечисляется список портов коммутаторов, через которые должен пройти пакет данных (Initial Path). Также в пакете есть счётчик количества пересылок (hop count), который указывает число элементов в списке портов, указатель на текущий элемент в списке портов (hop pointer), указатель направления D (Direction, 0 – пакет пересылается от источника к адресату запроса, 1 – пакет содержит ответ и пересылается по направлению к источнику исходного запроса) и обратный маршрут (reverse path).

Получив пакет с полем D = 

0
, коммутатор при помощи указателя на текущий элемент Hop Pointer определяет порт, в который следует направить полученный пакет, записывает номер порта, через который пакет получен, в поле для сохранения обратного маршрута Reverse Path, и увеличивает поле hop pointer на единицу. Если список закончился, то получатель обрабатывает пакет, формирует ответ, меняет указатель направления на обратный (устанавливает поле D в 1) и посылает ответ. При получении пакета, в котором указатель направления установлен на обратное, коммутаторы используют обратный маршрут для определения порта для пересылки, соответственно не записывают нового обратного маршрута, и на каждом шаге уменьшают значение hop pointer на единицу.

Кроме чистого направленного маршрута возможен вариант, когда указывается LID коммутатора, до которого пакет должен быть направлен при помощи обычной адресации (по LID), и LID получателя, которому пакет должен быть направлен после того, как будет пройден путь, определяемый направленным маршрутом. Очевидно, что при этом части фабрики до и после пути, определяемого направленным маршрутом, должны быть уже инициализированы и поддерживать пересылки при помощи LID.

Управление подсетью InfiniBand

Как было сказано выше, для нормальной работы подсеть InfiniBand должна быть настроена: назначены LID портам адаптеров и коммутаторов, настроены таблицы форвардинга коммутаторов (в отличие от сетей Ethernet, в сетях InfiniBand коммутаторы не формируют свою таблицу форвардинга сами, она должна настраиваться извне).

Компонентом, который отвечает за такую настройку, а затем за поддержание подсети в рабочем состоянии, является менеджер подсети (Subnet Manager). Менеджер подсети – это программа, которая может работать на компьютере с адаптером InfiniBand или на коммутаторе (не все коммутаторы InfiniBand поддерживают запуск менеджера подсети). Для надёжности в подсети может быть запущено несколько менеджеров, в этом случае один из них является главным (master), а остальные – запасными (standby). В случае, если главный менеджер перестаёт работать, его функции берет на себя один из запасных. Также главный менеджер может явно передать роль главного одному из запасных менеджеров, например, в процессе нормальной остановки.

После запуска менеджер подсети при помощи пакетов управления подсетью, передаваемых по направленным маршрутам, выясняет структуру подсети: какие есть адаптеры, коммутаторы, маршрутизаторы, и какие между ними есть связи. Если после определения структуры подсети выяснится, что других, более приоритетных менеджеров подсети в этой подсети нет, данный менеджер становится активным и осуществляет настройку подсети, т. е. назначает всем конечным портам LID, каждому конечному порту сообщает LID порта, на котором работает сам менеджер подсети, устанавливает таблицы форвардинга коммутаторов и делает некоторые другие настройки. После этого подсеть готова к работе. В процессе работы подсети менеджер время от времени собирает информацию об изменениях её структуры (этот процесс называется Sweeping) и соответствующим образом меняет конфигурацию.

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

IP через InfiniBand (IP over IB, IPoIB)

Работа стека протоколов TCP/IP поверх InfiniBand не является частью спецификации InfiniBand, она определена в соответствующих документах RFC. Работа InfiniBand вполне возможна и без IPoIB. Однако некоторые программы и библиотеки хотя и предназначены для работы поверх InfiniBand, требуют также работающего IP поверх InfiniBand. Чаще всего при помощи IpoIB определяют InfiniBand-идентификаторы (LID, GID) процессов, работающих на других вычислительных узлах, а после определения дальнейшие коммуникации осуществляются без участия стека TCP/IP.

Настройка IP поверх InfiniBand, в общем, не отличается от настройки IP поверх Ethernet. Есть только несколько моментов, на которые следует обратить внимание. Интерфейсы IPoIB в системе называются 

ib0, ib1
и т. д. (по одному интерфейсу на порт InfiniBand). Адреса лучше назначать статически, прописывая их в конфигурационных файлах серверов и вычислительных узлов. Работа протокола DHCP поверх IPoIB возможна, но для надёжности мы рекомендуем его не использовать.

Адрес канального уровня (link layer address), который в сетях Ethernet называется MAC-адрес или hardware address, для IPoIB имеет длину в 20 байт. Поэтому некоторые утилиты, в частности, широко применяемая утилита 

ifconfig
, в которых жёстко прописана длина MAC-адреса Ethernet в 6 байт, не могут корректно работать и отображать адреса канального уровня для IPoIB. Утилита 
ip
, рекомендуемая для замены 
ifconfig
, такого недостатка лишена. В адресе канального уровня содержится GID порта, номер пары очередей (Queue Pair Number, QPN, аналог номера порта в TCP для InfiniBand) и флаги, указывающие, какие протоколы транспортного уровня InfiniBand могут использоваться для передачи IP.

Утилиты для просмотра информации по сетям InfiniBand

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

Команда 

ibstat
показывает состояние всех портов на всех адаптерах InfiniBand, установленных на узле, где она запущена



Сначала выводится информация по адаптеру: его имя (

mlx5_0
), тип адаптера (название модели), количество портов, версии встроенного программного (firmware) и аппаратного обеспечения, а также идентификаторы Node GUID и System Image GUID.

Для каждого порта в строке 

Link layer
выводится тип подключения: InfiiniBand или Ethernet. Некоторые адаптеры InfiniBand позволяют подключаться как к сети InfiniBand, так и к Ethernet. Тип подключения определяется установленным трансивером. Строка 
Port GUID
показывает GUID порта. 
Base lid
– первый LID, присвоенный данному порту. Всего порту присвоено, как говорилось выше, 2LMC подряд идущих LID. 
SM lid
– LID порта, на котором работает менеджер данной подсети. Rate – скорость передачи данных, на которой работает порт (56 в данном случае – это режим 4x FDR).

Physical state
– состояние физического уровня передачи данных. Нормальное состояние – 
LinkUp
. Также может быть 
Disabled
, 
Polling
(в это состояние порт переходит после включения), 
Configuration
(согласование режимов работы с другой стороной связи), 
Recovery
(восстановление после сбоя связи). Есть и другие состояния, но их появление означает серьёзный сбой в работе оборудования, и мы их здесь описывать не будем.

State
– состояние канального уровня передачи данных. 
Active
– состояние нормального функционирования, возможна передача любых типов данных. 
Down
– передача данных невозможна (физический уровень ещё не перешёл в состояние 
LinkUp
). 
Initialize
– состояние, в которое канальный уровень переходит сразу после того, как физический уровень перешёл в состояние 
LinkUp
. В этом состоянии возможны приём и передача только пакетов управления подсетью (SMP, Subnet Management Packets). В этом состоянии менеджер подсети должен настроить порт (задать LID и прочие параметры) и перевести порт в состояние 
Active
. Есть и другие состояния, но порт не должен находиться в них долгое время, поэтому мы опустим их описания.

Capability mask
– набор флагов, описывающих поддерживаемые портом режимы работы (скорости и т. п.).

Команда 

ibstatus
также выводит информацию обо всех портах, но немного в другом формате, и выдаёт частично отличающийся набор данных:



Обратите внимание, что информация о базовом LID и LID менеджера подсети дана в шестнадцатеричном виде. Более подробно дана информация о скорости, на которой работает порт. Ещё добавлена строка 

default gid
, в которой указан GID для данного порта.

Иногда нужно узнать, какой машине назначен конкретный LID. Для этого можно применить утилиту 

smpquery
. Вообще эта утилита предназначена для посылки пакетов управления подсетью SMP (Subnet Management Packet) и выдачи ответов в понятной человеку форме. В нашем случае нам нужен запрос описания узла (node description). Вот пример выдачи команды 
smpquery nodedesc 914
(запрос описания узла с LID 
914
):



Узел ответил, что LID 

914
назначен адаптеру HCA-1 вычислительного узла с именем 
n51001
.

При помощи 

smpquery
доступна информация о том узле, которому адресован запрос. В то же время менеджер подсети имеет информацию обо всех узлах подсети. Запросить информацию у менеджера подсети можно при помощи утилиты 
saquery
. Информацию об узле подсети с LID 
914
можно запросить командой 
saquery 914
. Вот пример выдачи такой команды:



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

smpdump
позволяет запрашивать информацию об узле в сети InfiniBand у самого этого узла, а команда 
saquery
– у менеджера подсети. Если результаты этих запросов различаются или если команда 
saquery
выдаёт ошибку – это свидетельство того, что имеются проблемы с менеджером подсети. Ещё две полезные утилиты при диагностике сетей InfiniBand – утилиты 
ibnetdiscover
и 
ibdiagnet
. Утилита 
ibnetdiscover
пытается обнаружить все компоненты подсети: конечные узлы, коммутаторы, маршрутизаторы и связи между ними, и выводит информацию обо всех найденных компонентах. Утилита 
ibdiagnet
также пытается найти все компоненты подсети, но кроме этого она ещё и пытается обнаружить ошибки в конфигурации подсети, такие как совпадающие GUID, скорости портов и т. п.

Мы не будем приводить примеры выдачи этих утилит, так как они достаточно объёмны, а для 

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

Утилиты, которые посылают информацию в сеть, имеют ключи для выбора адаптера и порта, с которым следует работать (напомним, что в разных подсетях один и тот же LID может относиться к разным устройствам). Ключ 

-C
предназначен для указания адаптера (например, 
mlx4_0
в примерах выше), а ключ 
-P
позволяет указать номер порта заданного адаптера (порты нумеруются, начиная с 1).

Хранение данных

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

Локальные жёсткие диски могут использоваться для загрузки операционной системы, как виртуальная память (область подкачки) и для хранения временных данных. Конечно, вычислительные узлы могут и не иметь локальных дисков, если загрузка операционной системы на них организована через сеть, хотя даже в этом случае локальный диск полезен для области подкачки и хранения временных данных. На управляющем узле локальные жёсткие диски обычно устанавливаются, а сетевая загрузка при этом не предусматривается.

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

По способу доступа СХД разделяются как минимум на три типа:

• непосредственно подключённая СХД – Direct Attached Storage или DAS;

• СХД с доступом по локальной сети или сетевое хранилище данных – Network Attached Storage, или NAS;

• СХД, подключённая через выделенную сеть хранения данных – Storage Area Network или SAN (см. рис. 3).

Непосредственно подключённая СХД подключается либо к выделенному узлу хранения данных, либо к управляющему узлу. Такая СХД всегда видна в операционной системе узла, к которому она подключена, как локально подключённое дисковое устройство (физическое подключение – по SATA, SAS, Fibre Channel).


Рис. 3: сеть хранения данных (SAN)


Для обеспечения отказоустойчивости и повышения скорости работы в системах хранения нередко используют технологию RAID (redundant array of independent disks – избыточный массив независимых дисков). В рамках RAID несколько дисков равного объёма объединяются в один логический диск. Объединение происходит на уровне блоков (которые могут не совпадать с физическими блоками дисков). Один логический блок может отображаться на один или несколько дисковых блоков.

Есть несколько «уровней», которые приняты как стандарт de-facto для RAID:

RAID-0 – логические блоки однозначно соответствуют блокам дисков, при этом они чередуются: блок0 = блок0 первого диска, блок1 = блок1 второго диска и т. д.;

RAID-1 – зеркальный массив, логический блок N соответствует логическим блокам N всех дисков, они должны иметь одинаковое содержимое;

RAID-2 – массив с избыточностью по коду Хэмминга;

RAID-3 и -4 – дисковые массивы с чередованием и выделенным диском контрольной суммы;

RAID-5 – дисковый массив с чередованием и невыделенным диском контрольной суммы;

RAID-6 – дисковый массив с чередованием, использующий две контрольные суммы, вычисляемые двумя независимыми способами.

Уровень 0 обеспечивает наибольшую скорость последовательной записи – блоки пишутся параллельно на разные диски, но не обеспечивает отказоустойчивости; уровень 1 – наибольшую отказоустойчивость, так как выход из строя N-1 диска не приводит к потере данных.

Уровни 2, 3 и 4 в реальности не используются, так как уровень 5 даёт лучшую скорость и надёжность при той же степени избыточности. В этих уровнях блоки дисков объединяются в полосы, или страйпы (англ. stripe).

В каждом страйпе один блок выделяется для хранения контрольной суммы (для уровня 6 – два страйпа), а остальные – для данных, при этом диск, используемый для контрольной суммы, чередуется у последовательных страйпов для выравнивания нагрузки на диски. При записи в любой блок рассчитывается контрольная сумма данных для всего страйпа, и записывается в блок контрольной суммы. Если один из дисков вышел из строя, то для чтения логического блока, который был на нём, производится чтение всего страйпа и по данным работающих блоков и контрольной суммы вычисляются данные блока.

Таким образом, для RAID-5 можно получить отказоустойчивость при меньшей избыточности, чем у зеркала (RAID-1), – вместо половины дисков можно отдать под избыточные данные только один диск в страйпе (два для RAID-6). Как правило, «ширина» страйпа составляет 3-5 дисков. Ценой этого становится скорость работы – для записи одного блока нужно сначала считать весь страйп, чтобы вычислить новую контрольную сумму.

Часто применяют двухуровневые схемы – RAID-массивы сами используются как диски для других RAID-массивов. В этом случае уровень RAID обозначается двумя цифрами: сначала нижний уровень, затем верхний. Наиболее часто встречаются RAID-10 (RAID-0, построенный из массивов RAID-1), RAID-50 и -60 – массивы RAID-0, построенные из массивов RAID-5 и -6 соответственно. Подробнее о RAID читайте в литературе и Интернете.

Если используется распределённое хранение данных, например, как в Lustre (о ней мы расскажем далее), то узлов хранения данных может быть несколько, а данные, хранящиеся на такой СХД, распределяются по узлам хранения данных. СХД с доступом по локальной сети (или сетевое хранилище данных, NAS) обычно предоставляет дисковое пространство узлам по специальным протоколам, которые можно объединить под общим названием сетевые файловые системы. Примерами таких файловых систем могут быть NFS (Network File System), Server Message Block (SMB) или её современный вариант – Common Internet File System (CIFS).

Строго говоря, CIFS и SMB – два разных названия одной и той же сетевой файловой системы, изначально разработанной компанией IBM и активно используемой в операционных системах компании Microsoft. Сейчас CIFS может применяться практически в любой операционной системе для предоставления доступа к файлам через локальную сеть. Как правило, кроме NFS и CIFS системы NAS могут предоставлять доступ к хранимым данным и по другим протоколам, например FTP, HTTP или iSCSI.

СХД, подключённые через специальные сети хранения данных (SAN), обычно видны в операционной системе как локально подключённые дисковые устройства. Особенность SAN в том, что для формирования такой сети в целях повышения надёжности могут использоваться дублированные коммутаторы. В этом случае каждый узел будет иметь несколько маршрутов для доступа к СХД, один из которых назначается основным, остальные – резервными. При выходе из строя одного из компонентов, через которые проходит основной маршрут, доступ будет осуществляться по резервному маршруту.

Переключение на резервный маршрут будет происходить мгновенно, и пользователь не обнаружит, что вообще что-то вышло из строя. Для того чтобы это работало, необходима поддержка множественных маршрутов (multipath) в оборудовании и ОС. Заметим, что хотя для multipath и есть стандарты, но в реальности часто встречается «капризное» оборудование, для корректной работы которого с multipath требуются нестандартные драйверы или пакеты системного ПО.

Отличие NAS от SAN довольно условное, поскольку существует протокол обмена iSCSI, позволяющий использовать обычную локальную сеть в качестве сети хранения данных. В этом случае сетевое хранилище данных будет видно в операционной системе как локально подключённое дисковое пространство. Сеть хранения данных может объединяться с высокоскоростной коммуникационной сетью. Например, в качестве SAN-сети способна выступать InfiniBand, используемая для высокоскоростного обмена данными между вычислительными узлами кластера.

Особенности аппаратной архитектуры

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

Для увеличения мощности сервера или рабочей станции производители устанавливали несколько «одноядерных» процессоров (обычно от двух до восьми). Такие системы существуют и сейчас и называются симметричными многопроцессорными системами, или SMP-системами (от англ. Symmetric Multiprocessor System) (см. рис. 4).


Рис. 4: симметричная многопроцессорная система (SMP)


Как видно из схемы, каждый процессор, представляющий собой одно вычислительное ядро, соединён с общей системной шиной. В такой конфигурации доступ к памяти для всех процессоров одинаков, поэтому система называется симметричной. В последнее время в каждом процессоре присутствует несколько ядер (обычно от 2 до 16). Каждое из таких ядер может рассматриваться как процессор в специфической SMP-системе. Конечно, многоядерная система отличается от SMP-системы, но эти отличия почти незаметны для пользователя (до тех пор, пока он не задумается о тонкой оптимизации программы).

Для ускорения работы с памятью нередко применяется технология NUMA – Non-Uniform Memory Access. В этом случае каждый процессор имеет свой канал в память, при этом к части памяти он подсоединён напрямую, а к остальным – через общую шину. Теперь доступ к «своей» памяти будет быстрым, а к «чужой» – более медленным. При грамотном использовании такой архитектуры в приложении можно получить существенное ускорение.


Рис. 5: схема узла NUMA на примере AMD Magny-Cours


Например, в архитектуре AMD Magny-Cours (см. рис. 5) каждый процессор состоит из двух кристаллов (логических процессоров), соединённых между собой каналами HyperTransport. Каждый кристалл (чип) содержит в себе шесть вычислительных ядер и свой собственный двухканальный контроллер памяти. Доступ в «свою» память идёт через контроллер памяти, а в «соседнюю» – через канал HyperTransport. Как видим, построить SMP- или NUMA-систему из двух или четырёх процессоров вполне возможно, а вот с большим числом процессоров – уже непросто.

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

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

Для того, чтобы избавиться от паразитного влияния миграции процессов между ядрами, используется привязка процессов к ядрам (processor affinity, или pinning). Привязка может осуществляться как к отдельному ядру, так и к нескольким ядрам или даже к одному и более NUMA-узлам. С применением привязки миграция процессов или будет происходить контролируемым образом, или будет исключена вовсе.

Аналогичная проблема присутствует и в механизме выделения памяти пользовательским процессам. Допустим, процессу, работающему на одном NUMA-узле, требуется для работы выделить дополнительную память. В какой области памяти будет выделен новый блок? А вдруг он попадёт на достаточно удалённый NUMA-узел, что резко уменьшит скорость обмена? Для того, чтобы избежать выделения памяти на сторонних узлах, есть механизм привязки процессов к памяти определённого NUMA-узла (memory affinity).

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

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

На суперкомпьютерах эта технология вообще может быть отключена в BIOS каждого узла, чтобы не вносить дополнительных трудностей в работу параллельных программ. Как правило, эта технология не приносит ускорения для вычислительных программ. Если вы используете небольшой набор программ на суперкомпьютере, проверьте их работу с включённым и отключённым HyperThreading и выберите лучший вариант. Обычно мы рекомендуем включить её, но при этом указать системе управления заданиями число ядер, как с отключённым HT. Это позволяет получить дополнительные ресурсы для системных сервисов, минимально влияя на работу вычислительных заданий.

Ещё одна особенность архитектуры касается уже не отдельного, а нескольких узлов. Как мы ранее указывали, вычислительные узлы в вычислительном кластере объединены высокоскоростной коммуникационной сетью. Такая сеть может предоставлять дополнительные возможности обмена данными между процессами параллельных программ, запущенных на нескольких вычислительных узлах. В рамках одного узла применяется технология прямого доступа в память (Direct Memory Access, или DMA), позволяющая устройствам узла связываться с оперативной памятью без участия процессора. Например, обмен данными с жёстким диском или с сетевым адаптером может быть организован с использованием технологии DMA.

Адаптер InfiniBand, используя технологию DMA, предоставляет возможность обращаться в память удалённого узла без участия процессора на удалённом узле (технология Remote Direct Memory Access, или RDMA). В этом случае возникнет необходимость синхронизации кэшей процессоров (данный аспект мы не будем рассматривать подробно). Применение технологии RDMA позволяет решить некоторые проблемы масштабируемости и эффективности использования ресурсов.

Существует достаточно серьёзная критика данной технологии. Считается, что модель двухстороннего приёма-передачи (two-sided Send/Receive model), применяемая в суперкомпьютерах компании Cray (коммуникационная сеть SeaStar) и в коммуникационных сетях Quadrics QsNet, Qlogic InfiniPath и Myrinet Express, более эффективна при использовании параллельной среды программирования MPI. Конечно, это не исключает эффективного использования технологии RDMA, но применение её ограничено. В большинстве практических приложений использование RDMA даёт снижение латентности, но на больших приложениях (сотни узлов) может вылиться в чрезмерное использование системной памяти.

Краткое резюме

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

Ключевые слова для поиска 

rdma, hpc interconnect, numa, smp, cache, latency.