Для примера: в больших дисковых массивах (из нескольких стоек) полки и диски запускаются поочерёдно в определённой последовательности не только из-за больших пусковых токов, а ещё и для того, чтобы не раскачивалась стойка от раскручивающихся дисков. Другой пример: серверы организованы в коридор – стойки стоят напротив друг друга и серверы выдувают горячий воздух внутрь получившегося коридора, тогда и включать их надо пáрами, чтобы не перегреть ещё не включённые серверы.
Многое зависит от того, как спроектирован конкретный суперкомпьютер, поэтому хорошо изучите его структуру и процедуру старта. Конечно, эти и другие проблемы касаются и больших офисов, но в кластере они возрастают многократно. Все эти проблемы решаемы с той или иной степенью эффективности, но нередко методы их решения отличаются от «офисных». Во многом всё зависит от оборудования – при планировании суперкомпьютера очень важно помнить о пиковых нагрузках. Тут они – серая повседневность, поэтому изначально надо закладывать решения, позволяющие их выдерживать.
Кроме чисто аппаратных решений важны и программные: если один ключевой сервис поставить даже на супермощный сервер, то он всё равно может не справиться с нагрузкой, и, возможно, надо подумать о дублировании или разделении нагрузки. Если же при планировании по какой-то причине не удалось всё учесть и под нашей опекой оказался кластер с «бутылочным горлышком», то нужно суметь найти способ расширить или совсем ликвидировать это горлышко, например, заменив часть оборудования и/или программного обеспечения, но это обычно непросто.
Централизованное управление вычислительным комплексом
Как мы увидим далее, аспектов управления вычислительным комплексом масштаба вычислительного кластера очень много. Тут и развёртывание системы, и обновление ПО, и контроль учётных записей, удалённого доступа, управление доступом и заданиями, мониторинг, резервное копирование и многое другое. Каждая из этих задач по отдельности решается, а как – мы покажем в этой книге. Однако объём действий, совершаемый администратором при массовых операциях, таких, как заведение групп пользователей с присвоением им специфических прав, изменения в настройках сетевых устройств или узлов, становится весьма внушительным.
Тут на помощь вам придут знания скриптовых языков – большинство таких действий автоматизируется скриптами. Но, к сожалению, не все действия можно выполнить набором скриптов. В нелёгкие будни системный администратор большого вычислительного комплекса всё чаще задумывается об удобной «консоли», в которой можно сделать всё, что требуется, не запуская лишних программ, скриптов, не копируя промежуточных файлов и текста с экрана терминала. Особенно часто такие мысли возникают при виде продуктов типа HP OpenView или Zenoss. «Вот она – панацея!» – так и хочется воскликнуть. И правда, такие продукты нацелены на решение очень похожих задач. Они сами инвентаризируют оборудование, ведут учёт пользователей и ПО, делают массу автоматизированных действий… Более того, их действительно можно (а если есть возможность, то и нужно) приспособить для решения части ваших задач.
Увы, лишь части. Подобные продукты, как коммерческие, так и свободные, нацелены именно на похожие, пересекающиеся с нашими, но всё же другие задачи. Заставить их делать то, чего они не умеют, но что нужно нам, иногда можно, но это требует колоссальных затрат – людских, финансовых, времени… А как только конфигурация вашего суперкомпьютера поменяется, всё это придётся делать заново. По нашему личному опыту и опыту многих администраторов суперкомпьютеров, с которыми мы общались, универсальных решений нет. К сожалению, создание таких инструментов востребовано только узким кругом администраторов, при этом оно дорого в разработке и поддержке. Именно поэтому мы хотим обратить ваше внимание на важность системного подхода ко всем учётным и организационным действиям с вычислительным комплексом. Однако это не значит, что нужно выбирать как можно более интегрированные решения. Это значит, что все действия должны быть хорошо описаны – не для того, чтобы не забыть, а для того, чтобы видеть картину в целом и в изменившихся условиях быстро адаптировать к ним устоявшиеся процессы.
Старайтесь использовать гибкие и расширяемые инструменты. И не забывайте учиться новому, применять адекватные (а не только самые модные) технологии к решению всего комплекса задач администрирования суперкомпьютера!
Краткое резюме
Суперкомпьютер очень похож на «много-много обычных серверов», но в то же время особенностей работы с ним намного больше, чем с множеством серверов. Очень многие серверные технологии тут используются для решения стандартных задач, но не для всех они применимы. Кроме того, есть множество специфичных задач и технологий, применяемых только в области супервычислений.
Ключевые слова для поиска
HPC, beowulf, supercomputer.
Глава 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 не могут повторяться.