Еда и кластеры на скорую руку

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

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

Начинаем с нуля - двух «голых» ПК с процессорами 1 ГГц и 512 Мбайт оперативной памяти. Связь осуществляется по обычной сети Fast Ethernet (100 Мбит/с), альтернативы которой у нас просто нет. Оба компьютера соединены через обычный коммутатор, что, конечно же, теоретически уменьшает пропускную способность, а также увеличивает латентность по сравнению c соединением кросс-кабелем нос в нос ¹. Однако таким образом сохранялось соединение с внешним миром - для удаленного управления.

В качестве программной платформы, после некоторых раздумий, выбрали Linux - классическую среду для Beowulf. Впрочем, от Windows пока не отказываемся, существуют же NT-кластеры. Прочитав документацию и форумы на parallel.ru, полазив в Google по разделу, из свободно распространяемых пакетов для реализации параллельных вычислений выбираем PVM, MPICH и LAM; после некоторых колебаний - оставляем MPICH. «Под него» уже выбираем операционную систему - Red Hat Linux 7.2. Все «линуксы» немного разные, а процедура установки и запуска MPICH под RH 7.2 хорошо описана на сайте, с указанием путей обхода возможных подводных камней.

А вот о несколько «надводных» мы все же стукнулись. Странно, но при выборе варианта инсталляции «Workstation», RH 7.2 по умолчанию не ставит компиляторы Си (gcc) и Фортрана (g77). Так что нужно не забыть указать эти пакеты, когда инсталлятор поинтересуется, что именно ставить. Кроме того, машинам нужно обязательно дать имена и сделать так, чтобы они узнавали друг друга и самих себя по именам, а не только по IP-адресам (прописать их в /etc/hosts).

Для программ, использующих библиотеку MPI, нужна возможность исполнения команд на удаленном компьютере через remote shell (rsh) или secure shell (ssh). Мы выбрали самый простой вариант и поставили на каждую из двух машин сервер rsh, но категорически не советуем использовать такую конфигурацию иначе, как в тестовых целях! Rsh - огромная дыра в безопасности системы, поскольку логин и пароль передаются в ней открытым текстом и легко перехватываются снифферами. Тем более что настройка ssh для нужд MPICH подробно описана в разделе FAQ. Обратите внимание, что программы, которые будут работать на кластере, должны запускаться из-под обычного пользователя, а не из-под root. Во-первых, суперпользователя вообще нужно стараться эксплуатировать поменьше, и, во-вторых, удаленная машина просто не пустит его по rsh или ssh.

Настроив удаленный доступ и научив машины ходить друг к другу в гости без пароля, приступаем к установке собственно MPICH. Распаковываем дистрибутив объемом около 11 Мбайт, запускаем стандартную процедуру конфигурации и установки (./configure … make … make install) и минут через пять получаем готовый к работе кластер… правда, пока только на одной машине. Ищем файл machines.LINUX и вносим туда поименно все машины, которые будут задействованы в расчетах.

На другой машине можно повторить процедуру компиляции MPICH, а можно перенести скомпилированные файлы с первой. Главное, положить их в то же место, где они лежали на первой машине (например, в /usr/local/mpich). Исполняемые и прочие задействованные в расчетах файлы тоже должны лежать в одних и тех же директориях. Когда машин две, за этим легко уследить, а если больше? Поэтому лучше держать эти файлы на одной машине, а на остальных - автоматически подцеплять через сеть директорию, где они хранятся, - по NFS либо Samba.

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

MPICH встал на обе машины как влитой - можно пользоваться. Но для начала хорошо бы проверить, все ли вы сделали правильно с rsh (ssh), структурой директорий и т. д. Для этого служит скрипт tstmachines из поддиректории share. Если при запуске скрипт молчит, значит все в порядке. Если ругается - вам не повезло и вы возвращаетесь на два хода назад - конфигурировать доступ и права.

Итак, что же мы будем использовать из всего установленного нами? На первых порах практически важно найти две вещи. Во-первых - скрипты mpicc, mpif77 и mpif90, которые теперь надо указывать в качестве компилятора для программ, поддерживающих MPI. Он подключает нужные библиотеки и вызывает компиляторы Си и Фортрана, установленные в системе. Во-вторых - скрипт mpirun, посредством которого программа запускается на исполнение.

Подготовительная часть работы наконец закончена. Руки чешутся приступить к испытанию кластера, благо тесты уже под рукой - в директории examples. Компилируются они все разом командой make. Эти нехитрые демонстрационные программки на Си и Фортране, по максимуму накачанные вызовами MPI. В их числе «классика» - cpi, которая реализует известный алгоритм вычисления приближенного значения p в виде интеграла. Если мы хотим, чтобы программа cpi выполнялась, например, на двух процессорах кластера, запускаем ее командой mpirun -np 2 cpi, при этом mpirun анализирует файл machines.LINUX и раскладывает задачу на первые две указанные в этом файле машины. Если содержание файла выглядит так:

то на компьютерах belka и strelka команда запустит по одному процессу. А если там записано

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

Запустим программу cpi на миллиард циклов сначала на одной, а потом на двух машинах. Посмотрим на время выполнения (диаграмма 1).

Линейная масштабируемость! Чего и следовало ожидать - алгоритм подсчета числа p распараллеливается идеально, каждый из узлов получает непересекающееся с другими узлами задание в начале расчета и в течение всего времени выполнения программы работает автономно, лишь в конце они синхронизируются и складывают полученные результаты. В результате наш двухкомпьютерный кластер способен считать ровно вдвое быстрее одиночной машины.

Число p - это, конечно, хорошо. Но было бы интересно погонять на кластере известные бенчмарки для многопроцессорных Linpack, благо они есть для MPI в готовом виде (www.netlib.org/benchmark/hpl). Однако с ходу их не удалось скомпилировать, и мы успокоили себя мыслью, что важны не тесты, а производительность на конкретных приложениях.

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

Под рукой оказалась бесплатная, портированная на многие платформы программа трассировки лучей Povray, рисующая безумно красивые картинки. Исходные тексты, которые можно скачать с www.povray.org, не поддерживают параллельность, однако существуют заплатки, реализующие ее в рамках PVM и MPI.

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

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

Если компиляция параллельного варианта Povray труда не составила, то с тестированием вышла заминка. Запустив трассировщик на двух процессорах, мы не получили никакого выигрыша по сравнению с однопроцессорной программой. Посмотрев в список задач, мы обнаружили два процесса, один из которых занимал 100% вычислительных ресурсов, а второй… как будто ничего не делал. Запуск с ключом -np 3 подтвердил нашу догадку, дав почти двукратный выигрыш в производительности! Один из процессов, по-видимому, всегда играет только управляющую роль и не берет на себя вычислительной нагрузки. Сверив свои результаты с www.tabsnet.com, мы обнаружили, что два наших компьютера с Athlon 1 ГГц дают почти такую же производительность, что и Athlon 1800XP. Неплохо, если учесть, что Povray мы компилировали без оптимизации по производительности.

Мы говорили только о Linux. А как же Windows? Недавно MPICH была портирована и под NT, где обрела графический интерфейс и стандартный инсталлятор. Однако приложений, использующих возможности библиотеки, в свободном домене мы не обнаружили. Если, конечно, не считать вездесущей программы по вычислению важного и нужного числа p, результаты тестирования которой, как и следовало ожидать, в точности повторяли линуксовые. Чтение документации («…это вполне корректная, но неоптимальная реализация…») оставляет впечатление, что Windows, в отличие от Linux, не является приоритетной средой для развития кластерных технологий. Что вполне объяснимо: мощные вычислительные программы в общем-то все равно под какую операционную систему компилировать, а преимущества Windows в плане удобства пользовательского интерфейса не играют роли в расчетных задачах. Одной из возможных областей применения MPI под Windows может стать использование для инженерных расчетов ПК, простаивающих в корпоративных сетях.

Однако приложения должны учитывать как сильную гетерогенность компьютерного парка, так и медленную коммуникативную среду. Кстати, для компиляции Windows-версии MPICH и разработки программ под нее рекомендуется использовать пакет Microsoft Visual Studio 6.0, который, как известно, далеко не бесплатен.