Стремление минимизировать трудозатраты на построение и дальнейшую поддержку высокопроизводительной вычислительной системы привело группу исследователей по ядерной химии, принимающих участие в проекте RHIC/Phenix, к созданию собственного небольшого кластера для проведения экспериментов в области физики высоких энергий.

Группа ядерной химии (Nuclear Chemistry Group — NCG) университета Стони Брука (штат Нью-Йорк, США) участвует в работе коллаборации Phenix (www.phenix.bnl.gov) в Брукхевенской национальной лаборатории на ускорителе RHIC (www.rhic.bnl.gov/RCF). Коллаборация записывает на ленты около 500 Тбайт экспериментальной информации в год. Нашей задачей была организация вычислительной установки для физического анализа экспериментальных данных для небольшой группы физиков. NCG решила построить собственный небольшой вычислительный кластер, используя имеющийся опыт создания кластеров такого вида для экспериментов в области физики высоких энергий. Естественно, был принят во внимание опыт Phenix и вычислительного центра ускорителя RHIC, а также опыт Петербургского института ядерной физики. Предполагалось, что создаваемый вычислительный кластер должен стать не просто большим калькулятором, но и интеллектуальным инструментом обработки данных.

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

Центральный компьютер используется в основном для традиционных, хорошо известных задач: файловый сервер для относительно большого объема данных, выполнение регулярного резервного копирования критических данных, обеспечение безопасности вычислительной установки от атак из Сети, поддержка Х-сеансов и т. д. С другой стороны, периферийные компьютеры под управлением Linux — главная вычислительная мощность. Нашей задачей было найти приемлемый баланс между объемом работ по созданию и эксплуатации кластера, а также необходимыми финансовыми ресурсами.

Оборудование

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

Мы оборудовали две стойки по 16 узлов в каждой c предустановленной системой RedHat Linux 6.1. В качестве центрального узла нужна была машина, удовлетворяющая следующим требованиям:

  • пропускная способность шины около 1,1 Гбайт/c при средней скорости доступа к памяти 750 Мбайт/c;
  • не менее 16 PCI-слотов; каждый из 4 каналов 64-разрядной шины PCI способен передавать данные со скоростью 250 Мбайт/c;
  • возможность увеличения числа процессоров;
  • оперативная память не менее 2 Гбайт;
  • жесткие диски емкостью от 10 Гбайт с возможностью горячей замены;
  • 4 интерфейса Ethernet 10/100 и три оптических канала Gigabit Ethernet со скоростью 1 Гбит/с (100-мегабитный канал пока не используется; один оптический канал служит для связи с периферийными машинами и для выхода в Internet 2, а два других находятся в стадии конфигурирования с целью увеличения пропускной способности соедиения между центральной машиной и периферийными вычислителями);
  • 2 канала SCSI пропускной способностью 80 Mбайт/c (в настоящее время используется один из них для связи с массивом RAID емкостью 3 Тбайт).

Таким требованиям удовлетворяют машины разных производителей; в нашем случае был приобретен сервер Alpha 4100.

Каждый периферийный вычислитель укомплектован двумя процессорами Pentium III/500 МГц, материнской платой Intel L440GX+, 512 Mбайт оперативной памяти, 2 портами Fast Ethernet; 9-гигабайтным жестким диском.

Кроме этого, были приобретены ленточная библиотека суммарной емкостью 3 Tбайт и общей скоростью чтения/записи 24 Mбайт/c, а также дисковый массив RAID полезной емкостью 2,2 Tбайт с двумя контроллерами (ведущий/ведомый) и общей теоретически достижимой пропускной способностью 80 Mбайт/c.

Архитектура

Каждая периферийная машина имеет свою собственную копию ОС, включая все системные библиотеки и дополнительное свободно распространяемое программное обеспечение. Все периферийные узлы сконфигурированы одинаково, включая каталоги /tmp и /scratch. Все пользовательские файлы и компоненты прикладного ПО хранятся на дисковом массиве RAID и монтируются на каждой периферийной машине посредством NFS3.

Все узлы были объявлены частью домена NIS, чтобы обеспечить полную прозрачность для пользователя, который «видит» свои данные и программы вне зависимости от машины, на которой он в данный момент работает. Известно, что NIS очень активно использует протокол RCP и во время старта задания на периферийном компьютере порождает мощный поток запросов. Если задания запускаются сразу на многих машинах, это может привести к медленному старту каждого из них. Таким образом, NIS может привести к снижению производительности системы на коротких заданиях [1], однако, в нашем случае среднее время выполнения задания составляет от 10 минут до полутора часов.

Сервер Alpha 4100 оснащен операционной системой Tru64 Unix, а на периферийных машинах, как и в BNL, установлена ОС Red Hat Linux 6.1. Используемая распределенная файловая система Transarc AFS позволяет обращаться к серверам BNL за программным обеспечением для коллаборации Phenix. Хранилище CVS также располагается в пространстве AFS, что позволяет поддерживать автоматически обновляемые локальные копии всех необходимых программ. В дальнейшем не исключен переход на версию OpenAFS (www.openafs.org).

В обеих средах установлен также программный инструментарий из проекта GNU — одинаковые версии gcc, grep, sed, make.

Сохранность данных

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

Ленточная библиотека используется вместе с программой Networker компании Legato, предназначенной для организации системы резервного копирования. Что касается содержания резервных копий, было решено копировать только часть файлов: пользовательские каталоги, критические системные и конфигурационные файлы. Автоматическое инкрементальное копирование производится каждый день, раз в неделю — полная копия. Хранится примерно полугодовой цикл полных копий. Типичная полная копия содержит 1,2 млн. файлов общим объемом около 100 Гбайт.

Дополнительную стабильность работе файлового сервера придает файловая система AdvFS для Tru64 Unix, позволяющая: использовать «мусорную корзину» при удалении файлов; гибко реконфигурировать логические тома, в том числе в горячем режиме; использовать встроенные средства резервного копирования.

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

Еще один аспект безопасности состоит в предотвращении несанкционированного доступа к вычислительному ресурсу по Сети. В нашем случае это тем более важно, поскольку кластер располагается в университете, который часто оказывается мишенью атак. В системе были выключены все старые и небезопасные демоны (ftpd, telnetd, fingerd и т.д.); все пользователи должны входить в систему с использованием клиентов на основе протоколов ssh. Кроме того, вход на любую периферийную машину извне возможен только с центрального компьютера. На Linux-машинах задействованы все механизмы по ограничению числа IP-адресов, с которых возможен вход на данный узел (файлы /etc/hosts.deny, /etc/hosts.allow, /etc/ssh).

На центральной машине дважды в месяц автоматически просматриваются записи о всех входах в систему (файлы auth.log и daemon.log); готовится отчет. В дополнение, для анализа вторжений используется утилита logcheck (см. www.psionic.com/abacus/logcheck).

Следующая линия защиты базируется на обнаружении любых изменений в системных конфигурационных файлах и исполняемых компонентах. Мы используем такие программы сканирования, как cops (www.fish.com/cops), tiger (net.tamu.edu/network/tools/tiger.html), SATAN (www.cs.ruu.nl/cert-uu/ satan.html), а также собственное средство сканирования всех критических файлов на предмет изменения контрольной суммы, прав доступа, даты создания/модификации и прочих параметров каждого файла из наблюдаемой группы каталогов типа /etc, /bin, /usr/bin, /sbin, /usr/sbin и т.д. Любые изменения становятся известными администратору. Такая процедура оказалась исключительно полезной — хотя бы для сопровождения конфигурационных файлов и системных программ. Особенно удобно это средство в нашем случае, когда лица, ответственные за разные части системы, находятся на значительном удалении друг от друга и от вычислительного кластера. Имеется и готовый пакет с аналогичными функциями — Tripwire (www.tripwire.com), который поставляется в составе Red Hat Linux, однако наша разработка более точно адаптирована к конкретным условиям.

Посредством заданий cron несколько скриптов периодически анализируют текущее состояние вычислительной системы, выполняя поиск файлов, которые никому не принадлежат или имеют sticky uid и проверку паролей на тривиальность.

Как уже упоминалось, доступ к прикладным программам в BNL реализуется посредством распределенной файловой системы afs, однако для удаленных пользователей такой способ оказался довольно медленным и нестабильным. Часть причин, которые приводили к перерывам в работе afs, очевидны: перерывы из-за проблем с сетевым периметром безопасности в BNL, окольная сетевая маршрутизация и проч. В других случаях точную картину того, что происходит в сети, было составить труднее. Например, иногда возникало длительное снижение пропускной способности; суммарный эффект от всех имеющихся задержек был таков, что сборка программы с использованием удаленной библиотеки могла занять несколько часов. При использовании же локальной копии библиотеки сборка занимала несколько минут. Поэтому было решено реализовать полуавтоматическую зеркальную копию всех прикладных программ из эксперимента Phenix. Общий объем реплики составляет около 30 Гбайт.

Реальная скорость передачи данных с использованием команды scp между университетом и BNL колеблется от 80 до 200 Kбайт/c. С помощью специализированного инструментария многопоточной передачи данных bbftp (ccweb.in2p3.fr/bbftp) нам удалось увеличить скорость передачи до 2,9 Mбайт/c при передаче группы файлов общим объемом 40 Mбайт, такая реальная скорость передачи имеет место, несмотря на пропускную способность опорной сети около 100 Mбайт/c. Близкие значения были получены независимо в университете Вандербильта и коллегами из Японии.

Подход к копированию программного обеспечения Phenix довольно прост. Определенные области дерева afs в BNL сканируются Perl-скриптом. Для каждого файла из дерева afs выполняются обычные проверки, которые требуются для процедуры зеркального копирования. Логические ссылки в дереве afs должным образом распознаются и создаются в соответствующих местах локальной копии. Единственной проблемой было автоматическое преобразование скриптов, которые создают стандартный для Phenix набор переменных окружения (более ста переменных). К счастью, выяснилось, что скрипты легко анализируются и преобразуются в вид, который пользователи кластера применяют при входе в систему.

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

Важным элементом обсуждаемого решения могла бы служить реализация локальной копии базы данных Objectivity/DB [2], которая имеет встроенный механизм копирования. Однако мы не могли его использовать из-за наличия периметра сетевой безопасности BNL. В результате была разработана другая система репликации базы данных на основе идеи Сатоши Йоккаичи (RIKEN/CCJ), в которую мы внесли несколько модификаций.

В качестве исходного материала для копирования используется основная копия базы данных Phenix Objectivity/DB, хранящаяся в BNL (файлы, распределенные по нескольким серверам). В процессе создания мастер-копии все файлы объединяются таким образом, что созданная копия содержит все файлы базы данных независимо от их первоначального расположения. Мастер-копия размером около 60 Мбайт переносится на кластер посредством команды scp. После завершения копирования создается новая (локальная) федеративная база данных, в которую и восстанавливается мастер-копия. На хосте, где восстановлена база данных, необходимо запустить два демона: oolock и ooams. В своей основе все перечисленные действия с базой данных основаны на использовании команд Objectivity/DB. Имея сублицензию на версию Objectivity/DB на платформе Linux, мы развернули СУБД на одной из периферийных машин.

Пакетная обработка

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

В качестве системы пакетной обработки заданий была использована Portable Batch System (www.openpbs.org), доступная сейчас как минимум в двух вариантах: свободно распространяемый Open PBS и коммерческий Professional PBS (коммерческий продукт). В нашем кластере использован свободно распространяемый вариант, что потребовало разработки нескольких скриптов, гарантирующих, что никакой пользователь не сможет монополизировать кластер для своих задач в ущерб остальным. Пришлось ввести ограничение на запуск заданий, если загрузка центрального сервера является слишком большой (мы относим к таким ситуации, когда команда uptime дает величину загрузки равной 15.0 или более). Все остальные возможности открытого варианта PBS оказались вполне приемлемыми для небольшого кластера с максимальным потоком в 1-2 тыс. заданий в день.

Сопровождение

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

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

Кластер включает 33 периферийных машины, которые могут генерировать поток данных около 100 Mбит/c * 33, т.е. суммарный поток может достигать 3,3 Гбит/c, что более чем в три раза превышает пропускную способность канала между сетевым коммутатором 3Com 3300 и сервером Alpha 4100 (1 Гбит/c). Можно было предположить, что для ряда задач это может оказаться узким местом. Когда средствами PBS допустимое число заданий в стадии выполнения было уменьшено с 66 до 20, то загрузка центрального сервера снизилась до приемлемых величин (12.0 — 20.0).

Когда была предпринята попытка измерить сетевой трафик (команда ls -l /proc/n/fd, где n — номер процесса для исследуемого задания), обнаружилось, что типичное задание из вызова системы ROOT (root.cern.ch) и интерпретации скрипта с использованием CINT открывает от 6 до 20 файлов в смонтированной посредством NFS файловой системе. В то же время реальный сетевой трафик меняется во время выполнения задания и не превышает 3,3 Mбайт/c на любой Linux-машине; эти данные были получены посредством пакета ntop (www.ntop.org), во время выполнения длинной последовательности заданий, состоящей из 500 заданий. Другими словами, суммарный трафик не мог превышать 3,3 * 33 = 108,9 Mбайт/c, следовательно, канал между центральным сервером и коммутатором не может рассматриваться как перегруженный. Это верно даже с учетом того факта, что ntop дает не точные значения, а лишь оценки сетевого трафика, которые по опыту могут отличаться от реальных значений вдвое.

Другим возможным узким местом может быть канал между дисковым массивом и центральным сервером. Канал имеет максимальную пропускную способность 80 Mбайт/c. Далее, пришлось изучить особенности настройки операционной системы Tru64 Unix и после изучения результатов команды sys_check были увеличены значения параметра name-cache-size в ядре системы. Загрузка кластера сразу существенно уменьшилась, что позволило вновь увеличить число заданий в стадии исполнения, увеличив тем самым производительность кластера.

Затратив значительное времени на поиски и устранение проблем, мы оформили полученный опыт в скрипты двух видов:

  • скрипты для установки и развёртывания отдельных программных компонентов;
  • скрипты для слежения за ситуацией в системе посредством заданий cron или установки параметров.

В процессе установки программного обеспечения на периферийных машинах число скриптов для установки программных компонентов постепенно росло; когда их стало 5, потребовалась некоторая стандартизация. Некоторые программы устанавливались с использованием простейшей последовательности:

configure
make
make install

Однако около половины установленных продуктов нуждались в дополнительных корректировках и не могли быть полностью настроены простейшей последовательностью. Естественным образом возникали скрипты для установки отдельных программных компонентов. Для интеграции всех инсталляционных скриптов потребовалось предусмотреть специальный каталог (InstallScripts), а также мастер-скрипт (GenInstall) для интерпретации содержимого каталога. В каталоге могут быть любые файлы с любыми именами, однако мастер-скрипт обращает внимание лишь на имена с форматом Snnn_W_name, где nnn — номер скрипта; W — параметр, значением которого может быть L (выполнять в Linux) или C (выполнять на центральном кластере); name — имя скрипта.

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

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

Из организационных вопросов упомянем регистрацию новых пользователей, которая реализована в виде полуавтоматической процедуры. Потенциальный пользователь заходит на кластер с использованием протокола ssh, в качестве оболочки используется регистрационный скрипт. Пользователь отвечает на ряд вопросов, вводя, среди прочих сведений, имя, телефон и адрес. Администраторы автоматически уведомляются о любых попытках регистрации. Если пользователь ввел всю необходимую информацию, копия автоматически направляется его руководителю. Администрация в течение одного-двух рабочих дней уведомит пользователя о решении относительно его регистрации.

Будущее

Учитывая масштабы вычислительного процесса в коллаборации Phenix, созданный вычислительный кластер рассматривается как элемент более крупной сети. Поэтому было решено протестировать относительно новое программное обеспечение интеграции разнообразных вычислительных ресурсов на более высоком уровне, нежели обычный удаленный вход в систему или простая пересылка файлов по сети. В качестве ориентира была взята система с архитектурой grid, например, система Globus (www.globus.org). В контексте Globus описываемый кластер можно рассматривать как один элемент (узел) вычислительной сети коллаборации.

Инструментальные средства Globus были развернуты на кластере и протестированы с аналогичной системой в Петербургском институте ядерной физики, а также с тестовой установкой Atlas в BNL. Особое значение Globus может иметь для пользователей, которым требуется сразу несколько распределенных кластеров с различными особенностями вычислений и данных. Для конечного пользователя проще послать задание туда, где находятся данные, а не наоборот. Одно и то же задание, но с разными данными, может выполняться на разных кластерах.

В ближайшем будущем можно ожидать, что один набор данных будет составлять от 30 до 100 Гбайт. На основании предыдущего опыта известно, что последовательность заданий для обработки различных порций одного набора требуется около 10 часов счета. Нетрудно видеть, что сама по себе передача данных на периферийные машины занимает немного времени, примерно 20 минут (100 Гбайт при пропускной способности 80 Mбайт/c). Можно заметить, что в наших условиях последовательность заданий выполняется на двух третях узлов кластера. Таким образом, учитывая, что периферийные процессоры загружены на 90% или около того, большая часть времени выполнения заданий уходит на счет, а не на передачу данных.

Имеется несколько путей модернизации аппаратной конфигурации:

  • увеличение числа каналов SCSI для дискового массива;
  • реализация частной сети для трафика NFS, которая не имеет контактов с Internet и локальной сетью университета;
  • замена процессоров более производительными (плата L440GX+ позволяет установить Pentium III/850 МГц, что в 1,7 раза быстрее).

Заключение

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

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

Литература

[1] T. Sterling, J. Salmon, D. Becker, D. Savarese. «How to Build a Beowulf», 1999, MIT

[2] Objectivity/DB Administration Release 5.2, 1999

Андрей Шевель (Andrei.Chevel@ pnpi.spb.ru) — сотрудник Петербургского института ядерной физики, Джером Лаурет (jlauret@mail.chem.sunysb.edu) — сотрудник университета Стони Брука (США).

Другие системы пакетной обработки

Перечислим ряд других систем пакетной обработки заданий, на которые мы также обратили внимание [1, 2].

  • Network Queueing System. Свободно распространяемая система (www.gnqs.org).
  • Load Sharing Facility. Коммерческий продукт; хорошо продуманная система с массой разнообразных полезных свойств (www.lsf.com).
  • FBSNG. Относительно новая свободно распространяемая система (www-hppc.fnal.gov). Система написана на языке Python, однако к ней прилагается библиотека на Си, зависящая от версий интерпретатора Python. Не совсем ясно, кто будет модернизировать эту библиотеку вслед за версиями интерпретатора. Есть сомнения в возможности ее поддержки без помощи разработчиков.
  • Sun Gridware. Свободно распространяемая в готовых к исполнению кодах система (www.sun.com/gridware). Приобретена компанией Sun Microsystems в прошлом году; ранее поставлялась как коммерческий продукт под названием CODINE.
  • CONDOR [3].
Литература

[1] Михаил Кузьминский. NQS и пакетная обработка в Unix. «Открытые системы», 1997, № 1

[2] Виктор Коваленко, Евгения Коваленко. Пакетная обработка заданий в компьютерных сетях. «Открытые системы», 2000, № 7-8

[3] Дмитрий Владимиров. Кластерная система Condor. «Открытые системы», 2000, № 7-8