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

Автор: Михаил Попов
Опубликовано в журнале "Компьютерра" №5 от 11 февраля 2002 года

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

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

Делай раз…

Начинаем с нуля - двух «голых» ПК с процессорами 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 и strelka команда запустит по одному процессу. А если там записано

belka
belka,

то оба процесса будут запущены параллельно на машине 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, который, как известно, далеко не бесплатен.

---

1 (обратно к тексту) - Вариант, в котором компьютеры соединены только отрезком витой пары, без промежуточных устройств, позволяет достичь теоретической пиковой пропускной способности для полнодуплексных сетевых карточек порядка 200 Мбит/с.

версия для печати другие статьи автора оставить комментарий (0)
ТАКЖЕ В РАЗДЕЛЕ 24 февраля 2009 года Не отрываясь  24 февраля 2009 года Жилец вершин  10 февраля 2009 года Гаджеты, которых нет  10 февраля 2009 года Схватка  10 февраля 2009 года Мобильный телефон 2015 года  10 февраля 2009 года Список задач		MARKETGID Загрузка...

Аэроплан на солнечных батареях начал первый круглосуточный полёт «Яндекс» вытесняет конкурентов с поискового рынка Сети LTE в России могут быть запущены хоть сейчас Мантии Земли и Луны, скорее всего, имеют одно строение Влюблённость сродни наркотической зависимости