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

Преимущества и недостатки

Есть два способа хранения файлов данных: на "расшаренном" в NFS ресурсе и на локальном диске. Оба способа имеют свои преимущества и недостатки. В случае, когда используется виртуальный кластер, альтернативы нет - может использоваться только NFS. Когда же мы используем стационарный кластер, имаются варианты.

Чем хороша NFS? Преимущества NFS заключаются в простоте ее использования и экономии места на диске. Ресурс, экспортированный в NFS, доступен каждому узлу кластера. Нет необходимости копировать исполняемые файлы и файлы данных на все вычислительные узлы. Если данные занимают много места, а обычно бывает именно так - сохраняется состояние всей разностной сетки на какой-то момент времени,- то хранятся они в одном экземпляре на главном узле кластера. Нет необходимости заботиться о доступности нужных для конкретного процесса параллельной программы данных - все доступно всем.

Чем плоха NFS? Плоха она тем, что запись данных на сетевой ресурс происходит существенно медленнее по сравнению с записью на локальный диск. Это драматически сказывается на быстродействие всего кластера. Конечно можно минимизировать такое отрицательное влияние, как можно реже используя процедуры записи. В идеальном случае - сохранять данные только в конце работы программы. Однако это не всегда удобно, поскольку не всегда можно определить сколько будет работать программа и не придеться ли остановить ее раньше срока. Например, придя утром, вы обнаруживаете, что программа еще не закончила работу, а кластер нужно уже освободить. Наша тестовая программа решения уравнения теплопроводности, которую мы рассматривали ранее, в модификации, когда запись происходит на каждом втором цикле, в случае записи на локальный диск выполнялась 1 мин. 12 сек., а в случае записи на сетевой ресурс время счета уже составило 4 мин. 53 сек., при общем объеме записываемых данных 1.125 Гб и 30 итерационных циклах.

Чем хороша локальная ФС? Локальная файловая система хороша тем, что у нее отсуствуют недостатки NFS. Запись данных на современные винчестеры происходит достаточно быстро, позволяя нам по мере необходимости более часто выполнять сохранение данных.

Чем плоха локальная ФС? Недостаток локальной файловой системы заключен в ее локальности. Необходимым условием запуска параллельной программы является доступность исполняемого файла и файлов данных всем вычислительным узлам кластера, на которых программа будет запущена. Если в отношение исполняемого модуля все не так страшно - MPI имеет средства для автоматического распротсранения программы на те узлы, где она будет выполняться, то с файлами данных все не так хорошо. У параллельной программы есть особенность - в общем случае мы заранее не знаем, на каких узлах будет выполняться тот или иной процесс. Поэтому на потребуется скопировать все файлы на все узлы кластера, что приводит к многократному дублированию информации и неоптимальному расходованию дискового пространства. Конечно, мы можем явно указать на каких узлах кластера будет запущен данный конкретный параллельный процесс, однако это требует от пользователя знания архитектуры и топологии кластера, что не всегда удобно или возможно.

Тем не менее, если проблема свободного дискового пространства не является для вас проблемой, то предпочтительнее использовать локальную файловую систему. Давайте посмотрим, как можно сгладить недостатки локальной ФС, о которых мы упомянули выше.

Использование локальной файловой системы

Нет необходимости копировать исполняемый модуль на узлы кластера. Команда запуска параллельной программы mpirun имеет для этого встроенные средства. Достаточно указать дополнительный ключ -s и программа будет автоматически распространена между узлами. Например:

mpirun -hostfile ./../mpi/mpi.hosts -np 3 -s ./diffpw

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

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

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

Для синхронизации данных между многочисленными узлами кластера удобно использовать программу pdsh. Эта программа не входит в список программ, устанавливаемых в систему по умолчанию, поэтому придется ее доустановить. В Ubuntu это можно сделать следующей командой: sudo apt-get install pdsh.

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

cat $HOME/nodes| pdsh -R ssh -w - "rsync -uti supergate:$HOME/mpi1/node*.dat $HOME/mpi1/"
mpirun -hostfile $HOME/mpi.hosts -np 3 -s ./diffpw
cat $HOME/nodes| pdsh -R ssh -w - "rsync -uti $HOME/mpi1/node*.dat supergate:$HOME/mpi1/"

Здесь мы предполагаем, что файлы с данными называются node00.dat, node01.dat, node02.dat и т.д., рабочая директория программы - $HOME/mpi1, текстовый файл $HOME/mpi.hosts содержит список всех узлов кластера (по одному узлу в строке), первый среди которых - главный компьютер, и, наконец, файл $HOME/nodes содержит список всех узлов кластера (аналогично $HOME/mpi.hosts), но в котором отсутствует главный компьютер.

В случае использования для запуска параллельной задачи менеджера ресурсов Torque, задание на размещение задачи в очередь может быть оформлено примерно так:

#!/bin/sh
#
#PBS -l nodes=supergate:ppn=1+2:ppn=1
#PBS -N Flops_TEST
#PBS -m abe
#PBS -M yuri@linux-ekb.info
#PBS -l pmem=100mb
#PBS -l pcput=10:00:00
cd /home/mpiuser/mpi1
cat $HOME/nodes| pdsh -R ssh -w - "rsync -uti supergate:$HOME/mpi1/node*.dat $HOME/mpi1/"
mpirun -np 3 -s ./diffpw
cat $HOME/nodes| pdsh -R ssh -w - "rsync -uti $HOME/mpi1/node*.dat supergate:$HOME/mpi1/"

Для синхронизации данных используется команда pdsh, которая на всех компьютерах, перечисленных в $HOME/nodes, в параллельном режиме запускает процедуру копирования файлов с главного компьютера кластера, или в обратном направлении. Копирование выполняется с помощью утилиты rsync, которая анализирует время модификации файлов и копирует только файлы с наиболее свежими данными. Перед запуском нашей параллельной программы мы распространяем среди всех узлов наиболее свежие данные, которые, если программа это предусматривает, могут быть использованы для загрузки начального состояния разностной сетки. После окончания работы программы процедура копирования загружает на главный компьютер все результаты счета.

Резюме

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