Cуперкомпьютеры: администрирование

скачать книгу бесплатно

Cуперкомпьютеры: администрирование
Константин Сергеевич Стефанов

Сергей Анатольевич Жуматий

Как стать администратором суперкомпьютера? Что нужно знать и уметь? Какие подводные камни ждут на этом нелёгком пути? В книге есть ответы на эти и некоторые другие вопросы. Материал поможет имеющим опыт системного администрирования повысить свою квалификацию, а тем, кто пока не имеет такого опыта, разобраться в том, что нужно изучить. Издание подготовлено при поддержке издательства МАКС-Пресс. ISBN 978-5-317-05877-7 © Московский государственный университет имени М. В. Ломоносова, 2018 © Оформление. ООО «МАКС Пресс», 2018

Введение

Здравствуй, читатель!

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

Рассматривать будем только кластеры на базе Linux – это стандарт de-facto на настоящее время. Кластеры строят и на базе других ОС, например Windows, AIX и других, но здесь о них говорить не будем. Под суперкомпьютером мы понимаем вычислительный кластер, хотя большинство информации в этой книге применимо не только к кластерам. В тексте нами часто будет использоваться более широкое понятие – вычислительный комплекс. Все суперкомпьютеры разные, а уж кластеры и подавно – каждый со своими особенностями, требованиями и капризами. А значит, и навыки для каждого нужны свои.

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

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

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

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

Как выяснить, на каких серверах определился не весь объём оперативной памяти при последнем включении? Запустить на каждом «системный монитор»? Зайти на вкладку «система» и посмотреть объём ОЗУ? На это уйдёт весь рабочий день. А вот выполнив на каждом узле, например с помощью pdsh, команду типа

grep MemTotal /proc/meminfo | awk '{print $2}'

можно получить этот самый объём ОЗУ за секунды. Добавив ещё пару команд shell, можно сравнить полученное значение с эталоном (даже с учётом допусков) и выдать имена узлов, не прошедших проверку. Магия, вызываемая заклинанием? В чём-то – да, магия, но с понятными законами и вполне осваиваемая.

Нередко очень непростые действия можно выполнить с помощью комбинации стандартных команд. К счастью, это практически всегда возможно без большого труда. Труд потребуется для начального освоения этих команд, а потом – вся магия Linux будет в ваших руках! Очень советуем изучить «Advanced Bash Scripting Guide» (в Интернете есть хороший русский перевод). Это пособие позволит использовать огромную мощь инструмента, который всегда под рукой, – оболочки bash (практически всё работает и для zsh). Добавив в свой арсенал несколько простых приёмов sed и awk (а если захочется абсолютной магии, то и perl, а может быть, python или ruby), узнав возможности find, ps и подобных команд, вы многократно повысите эффективность своей работы.

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

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

Соглашения и обозначения, принятые в книге

Код скриптов, текст конфигурационных файлов выделяются так:

Предупреждения, важные моменты, о которых необходимо помнить:

Внимание! Не наступайте на одни грабли дважды!

Термины или важные понятия даны полужирным шрифтом.

Короткие команды выделяются в тексте так: ls -la.

Материал для новичков, который можно пропустить опытным специалистам, выделяется так:

Для начала работы включите компьютер в сеть.

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

Свои отзывы и пожелания, пожалуйста, присылайте на адрес superbook@parallel.ru.

Авторы выражают искреннюю благодарность:

Владимиру Воеводину за идеи и критику,

Александру Наумову и Антону Коржу за предоставленный материал и консультации,

Виктору Дацюку, Павлу Костенецкому, Алексею Лацису и Юрию Хребтову за важные замечания.

Вадиму Кузнецову (dikbsd) за неоценимую помощь в конвертации книги в электронный формат.

Глава 1. Что же такое «супер»?

Общие понятия о параллельной обработке и параллельных программах

Все современные суперкомпьютеры используют параллельную обработку данных. С самого начала компьютерной эры именно этот путь был и остаётся наиболее важным для достижения высокой производительности. Сейчас даже самый простой настольный компьютер если не многоядерный, то уж почти наверняка с технологией simultaneous multithreading (например, HyperThreading от Intel или AMD SMT), позволяющей работать двум (иногда более) программным потокам одновременно. Даже мобильные телефоны и фотоаппараты становятся параллельными и многоядерными.

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

Параллелизм – параллельное выполнение машинных команд разными устройствами. Например, команды x=a+b и y=b*c, где a, b и с – регистры, процессор может выполнить независимо, если он имеет раздельные устройства сложения и умножения (см. рис. 1). Этот принцип воплощён в большинстве современных процессоров.

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

Рис. 1: Параллельное выполнение

Рис. 2: Векторизация + конвейер

Чаще всего элементы вектора расположены друг за другом. Типичный пример – сложение векторов. Так как операция, выполняющаяся над векторами, одна и та же, то её разбивают на фазы – ступени конвейера. Например, загрузка элементов из памяти, нормализация мантисс, сложение, коррекция, запись в память. После выполнения первой ступени над первым элементом вектора эту стадию можно сразу же выполнить над вторым элементом, не дожидаясь завершения всей операции над первым. После завершения каждой ступени над одним элементом можно выполнить её над следующим. Таким образом, если самая медленная ступень конвейера выполняется за К тактов, а все ступени – за S тактов, то вектор из N элементов обработается за K*(N–1)+S.

Первый элемент обработается за положенные S тактов (это называется «время разгона конвейера»), а потом устройство будет выдавать по одному результату в K тактов. В современных процессорах чаще всего K=1. Однако конвейеризация не обязательно подразумевает векторизацию и наоборот. Например, если устройство сложения конвейерное и мы выполняем несколько обычных сложений подряд, они могут отлично задействовать конвейер.

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

Это параллелизм, заложенный в «железе». Для того, чтобы задействовать его максимально, заставить вычислители (ядра, процессоры, вычислительные узлы…) работать параллельно, необходимо составить программу таким образом, чтобы она использовала все эти ресурсы. Т. е. написать параллельную программу. Этим мы заниматься не будем (по крайней мере, в рамках этой книги), но иметь дело с параллельными программами нам придётся постоянно, и знать, как они работают, нам необходимо.[1 - Можем порекомендовать отличную книгу по параллельному программированию: Антонов А.С. Технологии параллельного программирования MPI и OpenMP: учеб. пособие. Предисл.: В.А. Садовничий. – М.: Издательство Московского университета, 2012. – 344 с. – (Серия «Суперкомпьютерное образование»).]

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

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

Для нас в первую очередь интересен параллелизм на уровне процессов UNIX (в том числе на разных узлах) и нитей. Именно здесь заложен основной потенциал параллельных приложений. Именно такой параллелизм используют наиболее популярные среды параллельного программирования MPI и OpenMP. Это не значит, что на других уровнях этого потенциала нет, но именно отсюда всегда нужно начинать. Среды (технологии) параллельного программирования представляют собой библиотеки или языки программирования, позволяющие упростить написание параллельных программ.

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

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

Например, в кластере используется скоростная коммуникационная сеть (InfiniBand или другая) и обычный Ethernet для управления. Установленная среда MPI работает, но эффективность работы программ низкая. Нередко причиной является неверная настройка, в результате которой MPI использует медленную управляющую сеть вместо скоростной.

Виды кластеров

Когда говорят «кластер», подразумевают множество компьютеров, объединённых в нечто единое. Но вариантов этого «нечто» может быть несколько. Они отличаются целью и, как следствие, – реализацией.

Первый вид кластеров – High-Availability, или кластеры высокой доступности. Их задача – предоставить доступ к какому-то ресурсу с максимальной скоростью и минимальной задержкой. Ресурсом обычно выступают web-сайт, база данных или другой сервис. В таком кластере при выходе из строя одного узла работоспособность всего ресурса сохраняется – клиенты сбойного узла переподключаются и получают доступ к ресурсу с другого узла кластера. Очень похожий принцип применяется в «облачных» технологиях: вы не знаете, на каком именно узле будет работать ваше приложение или образ операционной системы, облако само подберёт свободные ресурсы.

Другой вид кластеров – High Productivity. Этот тип похож на предыдущий, но в данном случае все узлы кластера уже работают над одним заданием, разбитым на части. Если какой-то узел отказал, его часть задания отправляется другому; если в кластер добавляются новые узлы, им выделяются не посчитанные ещё части, и общий счёт идёт быстрее. В качестве примеров можно назвать GRID, программы типа Seti@home, Folding@Home. Однако с помощью таких кластеров может быть решён только узкий класс задач. Да и сам кластер для таких задач нередко становится не нужен, можно воспользоваться домашними компьютерами или серверами, связав их через локальную сеть или Интернет.

Третий вид – High Performance (HPC – High Performance Computing). Именно он интересен нам. В отличие от остальных, выход из строя одного из узлов кластера, как правило, ведёт к аварийному завершению параллельной программы, только в редких случаях выполнение программы автоматически продолжается с сохранённой ранее контрольной точки. Именно поэтому, в отличие от предыдущих видов, HPC-кластеры менее устойчивы в работе, и без должного контроля и мониторинга использовать их просто не получится.

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

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

Кластеры и суперкомпьютеры – общее и разное

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

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

Построить Blue Gene самостоятельно невозможно: ключевые компоненты отдельно не продаются. И дело не в марке, а в уникальных технологиях. Кроме Blue Gene есть множество иных серий, иных уникальных разработок. Обратный пример – «вычислительные фермы», т. е. группы компьютеров, работающих над одной задачей, но обычно даже не передающие данные друг другу, или кластеры класса «BeoWulf[2 - Подробнее см. http://parallel.ru/computers/reviews/beowulf.html.]», т. е. собранные практически из подручных средств.

Как видим, грань между понятиями «кластер» и «не-кластер» достаточно чёткая, но какой кластер считать суперкомпьютером, а какой нет – вопрос размытый. Часто вместо «кластер» говорят более тактично: «обладающий кластерной архитектурой». В этой книге мы будем рассматривать технологии, доступные для всех или большинства. Следовательно, большинство из них будет относится именно к кластерам. Но это не значит, что в вычислительных комплексах, которые мы формально не относим к кластерам, этих технологий не встретится. Большинство современных суперкомпьютеров используют те же наработки, что и кластеры, более того, почти все они построены как кластеры с добавлением особо быстрых сетей, техник работы с общей памятью, синхронизации или иных технологий. А значит, все знания о кластерах вам только помогут.

Что означает «супер» для администратора суперкомпьютера

На первый взгляд, большой кластер ничем не отличается от множества офисных компьютеров, объединённых локальной сетью, и нескольких стандартных серверов – дискового хранилища и т. п. На самом деле отличия есть, и очень важные. Начнём с оборудования – для кластера требования намного выше. Если в локальной сети можно временно заменить сломанный коммутатор на более простой или даже на несколько дней нарушить связность сети (ну, придётся отчёты печатать на втором этаже, потерпите), то в кластере это недопустимо. Заменив IB-коммутатор на GigabitEthernet или узел с 8ГБ памяти на узел с 4ГБ, мы получим неработающий кластер или работающий так, что все пользователи завалят нас жалобами.

Настоятельно рекомендуем иметь ЗИП (аварийный запас) всех ключевых компонент оборудования, если у них нет аппаратного дублирования, и сервисный договор о замене оборудования в чётко оговорённый срок.

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

В современных кластерах вычислительная часть может занимать меньше четверти от всей площади установки, всё остальное занимает климатическое и энергетическое оборудование. А контроль и управление этим оборудованием (но не обслуживание) – тоже часть работы администратора. Более того, в отличие от офиса, если вычислительный узел, кондиционер или UPS вышли из строя, то об этом нельзя узнать от прибежавшего сотрудника, у которого «горит отчёт, а монитор не включается». Хуже всего, если об этом придётся узнать от пользователей, у которых программа перестала работать как надо или запускается два раза из трёх. Эту задачу решает мониторинг всего и вся. Очень важно знать как можно больше о состоянии кластера. На этом отличия не заканчиваются. Одно из самых важных связано с режимом работы. В офисе нагрузка на компьютеры не высока: большая мощность от них требуется несколько минут в день, чтобы отобразить большой документ или проиграть видеоролик новой рекламы продукта. 99% времени эти компьютеры ждут клика мышкой или нажатия на клавишу. В кластере всё принципиально иначе, его нормальный режим работы – 80–100% загрузки каждого узла постоянно.

В офисе даже пиковая нагрузка одного или двух компьютеров не будет заметна на общем фоне. Но каждый опытный администратор знает, что такое «все компьютеры схватили какой-то вирус» – нагрузка на сеть возрастает в сотни раз, сетевое хранилище не справляется с потоком запросов, всё начинает жутко «тормозить»… А в кластере ситуация, когда все узлы, занятые под одно задание, начинают обмениваться данными или писать промежуточные данные на сетевой диск – это не вирус, а совершенно нормальная ситуация. Особый тип пиковой нагрузки – включение. В офисе всё происходит само собой: утром все приходят, кто-то пораньше, кто-то попозже, включают компьютеры, подключают ноутбуки… Для суперкомпьютера же процедура включения означает резкое увеличение энергопотребления на десятки, а то и тысячи киловатт, дружное обращение вычислительных узлов к дисковому хранилищу, сервисным серверам. Если включить всё разом, то, скорее всего, установка просто сгорит. И даже «плавное» включение узлов одного за одним с интервалом в несколько секунд может привести к сетевым конфликтам, перегрузке какого-то сервиса запросами.

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

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

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

Централизованное управление вычислительным комплексом

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

Тут на помощь вам придут знания скриптовых языков – большинство таких действий автоматизируется скриптами. Но, к сожалению, не все действия можно выполнить набором скриптов. В нелёгкие будни системный администратор большого вычислительного комплекса всё чаще задумывается об удобной «консоли», в которой можно сделать всё, что требуется, не запуская лишних программ, скриптов, не копируя промежуточных файлов и текста с экрана терминала. Особенно часто такие мысли возникают при виде продуктов типа 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-адресом.