 |
|
|
|
Знакомимся с HPC-кластером OpenMosix
Знакомимся с HPC-кластером OpenMosix Большую часть времени ПЭВМ, скажем честно, простаивает. Средняя загрузка не превышает 20%. Но как только начинается сборка приложений, например на C++, или оцифровка видео-, аудиофайлов, то становится очевидным недостаток вычислительных ресурсов. Основная идея HPC-кластеров – задействовать ресурсы, свободные на других узлах кластера. Что такое кластер Кластер – это две или более самостоятельные системы, объединенные в единое целое посредством специального программного и аппаратного обеспечения. Основное звено кластера – это единичный компьютер, называемый узлом. Кластеры могут расти – «масштабироваться» – путем добавления новых узлов. При этом синергетическое целое мощнее, нежели отдельный узел. Изменения в структуре кластера, например, появление и удаление узлов из состава кластера (по разным причинам – авария или, наоборот, восстановление после критической ситуации) фиксируется всеми оставшимися/новыми узлами. Типы кластеров На сегодняшний момент широко известны и распространены 3 типа кластеров – отказоустойчивые (например, LifeKeeper – см. [1]), с балансировкой загрузки (Load-Balancing) и высокопроизводительные (High-Perfomance Computing):
Суперкомпьютеры и кластеры Традиционно ресурсоемкие математические вычисления выполнялись на суперкомпьютерах. Они выпускались определенным количеством производителей и организация, которая хотела купить суперкомпьютер, должна была обладать немалым финансовым ресурсом. Естественно, что большинство университетов не могли себе позволить такого рода дорогую игрушку, поэтому в их недрах начала создаваться концепция кластера для академических кругов. Цель данной концепции – подготовить условия для распараллеливания задачи между узлами, передать обработку подзадач на узлы и затем собрать результаты каждой подзадачи. Кластер предполагалось собирать на PC-платформе, благо она становилась всё более и более распространенным явлением и по сути дешевой. Кластерные модели Существует несколько методов распараллеливания – N(UMA), DSM, PVM и MPI. Некоторые из этих схем реализованы аппаратно, другие программно. Бывают и смешанные решения:
Сущность OpenMosix Пакет OpenMosix – это патчи к ядру Linux. На момент написания этого материала существуют патчи для ядра 2.4.26 и для ветки 2.6. Так как OpenMosix реализован в виде патчей, то сохраняется полная совместимость между программами, файлами и другими ресурсами в Linux. Обычный пользователь может и не заметить изменений между Linux-машиной и OpenMosix-кластером, ибо последний будет расматриваться как рядовая Linux-машина, только немного производительнее. Внутренний механизм балансировки прозрачно производит миграцию процессов на узлы кластера. Оптимальная загрузка кластера вычисляется динамически через определенные промежутки времени. Вы также можете произвести нужную подстройку параметров кластера. Прозрачный механизм миграции играет интересную роль – из-за него весь кластер выглядит как большая SMP-машина со множеством процессоров (каждый узел в роли процессора). В рамках OpenMosix разработана файловая система (oMFS) для HPC-приложений, которая в отличие от NFS поддерживает целостность ссылок, атрибуты времени и кеширование. Сегодня в нашем обзоре в качестве узлов кластера будут выступать 3 машины:
Все узлы соединены через хаб (100 МБит) в единое пространство. Операционная система, OC Linux, первоначально установлена на самой быстрой машине, а затем была клонирована на все остальные. Стоит отметить, что при установке, помимо базовых пакетов, также следует выбрать и QT-библиотеку (на базе QT мы впоследствии соберем утилиты мониторинга кластера). Итак, первый шаг по установке и настройке ПЭВМ с ядром по умолчанию пропускаем. Следует настроить SSH-сервис, т.к. благодаря ему мы будем управлять узлами. Далее заберем ядро (2.4.26) с включенными патчами для OpenMosix (32 Мб): wget http://citkit.dl.sourceforge.net/sourceforge/openmosix/openmosix-kernel-source-2.4.26-openmosix1.i386.rpm Для экономии трафика можно взять только патчи и наложить их на оригинальное ядро с kernel.org самостоятельно (200 Кб): wget http://citkit.dl.sourceforge.net/sourceforge/openmosix/openMosix-2.4.26-1.bz2 # rpm -ih --nodeps openmosix-kernel-source-2.4.26-openmosix1.i386.rpm # cd /usr/src/linux-2.4.26-openmosix1/ # make xconfig Ставим галочки для компонентов OpenMosix (рис. 1), остальные компоненты для ядра не изменяем, сохраняем конфигурацию и собираем ядро. # makedep&& make && make bzImage && make modules # make modules_install Добавляем нужную опцию в загрузчик. В случае lilo: image = /boot/mosix-bzImage root = /dev/sda1 label = om.Linux read-only # /sbin/lilo -v И перезагрузка.
Рисунок 1. Компоненты ядра, отвечающие за функционирование OpenMosix Для управления и тюнинга узлов в OpenMosix предусмотрен специальный пакет утилит – openmosix-tools. Установим его. wget http://citkit.dl.sourceforge.net/sourceforge/openmosix/openmosix-tools-0.3.6-2.tar.gz # tar xzvf openmosix-tools-0.3.6-2.tar.gz # cd openmosix-tools-0.3.6-2 # ./configure --prefix=/opt/OpenMosix --with-kerneldir=/usr/src/linux-2.4.26-openmosix1 # make && make install После установки этого пакета есть два варианта, каким именно образом узлы будут сообщать друг другу о своих характеристиках (загрузка, вычислительная мощность) и координатах (IP-адрес). Либо указать жестко в файле /etc/openmosix.map, либо положиться на сервис автоопределения узлов (omdiscd). Структура файла openmosix.map представлена ниже: # MOSIX-# IP number-of-nodes # ============================ 1 10.0.0.1 1 100 0.0.0.100 1 В первой колонке указывается номер узла (в моем случае первый узел имеет номер 1, второй – 100), во второй колонке IP-адрес, в третьей колонке – количество узлов в диапазоне. Т.е. предполагая, что первые пять узлов имеют последовательные адреса от 10.0.0.1 до 10.0.0.5 смысла их перечислять нет. Стоит только указать, что количество узлов равно в этом случае 5. 1 10.0.0.1 5 Так раздаются адреса статически. А для их динамического определения будет использоваться файл /etc/openmosix/openmosix.config, где прописываются такие параметры, как:
Я пошел по пути динамического определения узлов и для этого включил старт автоматического определения omdiscd – добавил в /etc/rc.d/rc.local строку: /opt/OpenMosix/sbin/omdiscd -i eth0 Таким образом, при последовательном старте узлов вы можете отслеживать в логах процесс формирования кластера:
Для того чтобы системные процессы (те, что отвечают за загрузку и выключение узла) не мигрировали на другие узлы, используем в файле /etc/inittab такую конструкцию: строки с участием директории rc.d: si:S:sysinit:/etc/rc.d/rc.S перепишем так: si:S:sysinit:/bin/mosrun -h /etc/rc.d/rc.S что дословно означает «запускать стартовый скрипт rc.S на домашнем узле». Также следует поменять строки, где участвует rc.d, а также строку: ca::ctrlaltdel:/sbin/shutdown -t5 -r now которая будет выглядеть так: ca::ctrlaltdel:/bin/mosrun -h /sbin/shutdown -t5 -r now Все готово, чтобы первый настроенный узел клонировать на другие машины. Воспользуйтесь либо командой dd, либо программой Norton Ghost. Затем в клонированных узлах поменять IP-адреса, hostname, и дело в шляпе. Для тестирования производительности сформированного кластера я решил проверить, за какое время будет собран MPlayer [2]. Тестируем быстродействие Как я проводил замеры. Когда кластер обнаруживает новый узел, он создает в виртуальном каталоге /proc/hpc/nodes новую ветку, совпадающую с номером обнаруженного узла. Следует отметить, что весь каталог /proc/hpc относится к функционированию OpenMosix. Таким образом, если появляется новый узел с номером XXX, то автоматически появляется каталог /proc/hpc/nodes/XXX, в котором хранятся файлы с характеристиками данного узла. В частности, содержимое файла load нас и будет интересовать. Производительность узлов в OpenMosix оценивается по сравнению с виртуальной ПЭВМ класса Celeron 1 ГГц, поэтому не удивляйтесь, когда увидите, что производительность конкретного узла, например, равняется 20000. Это означает, что по сравнению с эталонным 1 ГГц данный узел в 2 раза производительнее. Итак, производим калькуляцию. Сохраним данный скрипт, использующийся в наших подсчетах в дальнейшем. #!/bin/sh NODE1=/proc/hpc/nodes/573 NODE2=/proc/hpc/nodes/574 NODE3=/proc/hpc/nodes/575 FILENAME=hpc_load.txt i=0 while true do DateStr='date +%H-%M-%S' Load1='cat $NODE1/load' Load2='cat $NODE2/load' Load3='cat $NODE3/load' echo "$DateStr ($i): $Load1, $Load2, $Load3" >> $FILENAME echo "Time: $DateStr ($i). Load: $Load1, $Load2, $Load3"; i='expr $i + 1'; sleep 1s; done Скрипт получился простеньким для понимания. Нагрузку «в попугаях» мы трансформируем в график, где посмотрим, какое участие принял каждый конкретный узел в процессе сборки. Так как считается, что кластер в нашем случае – это единое пространство с увеличенным количеством процессоров, то используем данный факт. Сначала посчитаем время сборки, когда работает только один узел, самый быстрый. Предварительно распакуем MPlayer: # wget MPlayer # tar xzvf MPlayer # cd MPlayer # ./configure Теперь запускаем наш скрипт collect_hpc_load.sh и считаем время: # time make dep # time make
Включаем узел с самым медленным CPU. Теперь производим подсчет.
Получили еще худший результат. Почему? Очень просто – у нас сформировалось много процессов, но с маленькими вычислительными запросами. Общее время миграции по 100-Мбитной сети плюс время компиляции превысило предыдущий результат. Включаем третий узел с 1.8 ГГц CPU. Посмотрим на цифры.
Отлично. А что произойдет при отключении самого медленного узла? Отключаем, проверяем.
Выигрыш от медленного узла составил примерно 6 секунд. Как говорится – спорный результат. Стоит ли овчинка выделки – а именно, нужен ли третий узел? Очевидно стоит отказаться в пользу двухузловой модели. Полученные результаты удобнее анализировать графически. Импорт в OpenOffice и дальнейшее преобразование в диаграммы закончилось получением этих рисунков. Синим цветом отмечен узел на базе Pentium 4 CPU 3 ГГц, красным – узел Pentium 4 CPU 1.8 ГГц, белым – Pentuim 3 CPU 600 МГц (рис. 2-5).
Рисунок 2. Загрузка кластера при одноузловом варианте
Рисунок 3. Загрузка кластера при двухузловом варианте (оба узла Pentium 4)
Рисунок 4. Загрузка кластера при двухузловом варианте (один из узлов Pentium 3)
Рисунок 5. Загрузка кластера при трехузловом варианте Утилиты мониторинга Как производить текущий мониторинг загрузки? К счастью, у OpenMosix достаточно широкая аудитория пользователей, благодаря которым появились утилиты визуального контроля и управления. Нужный нам сейчас пакет называется openmosixview. # wget openmosixview-1.5.tar.gz # tar xzvf openmosixview-1.5.tar.gz # cd openmosixview-1.5 Данное ПО написано на QT – надеюсь, вы его поставили, не забыли. Оно состоит из следующих программ:
К сожалению, у меня последняя программа не захотела собираться. Решение оказалось простым – при компиляции приложения 3dmosmon следует заменить инициализацию переменных в файле materials.h из вида: static material_struct whiteMaterials = { {1.0, 1.0, 1.0, 1.0}, {0.0, 0.0, 0.0, 1.0}, {1.0, 1.0, 1.0, 1.0}, {20.0} }; в вид: static material_struct whiteMaterials = { {1.0, 1.0, 1.0, 1.0}, {0.0, 0.0, 0.0, 1.0}, {1.0, 1.0, 1.0, 1.0}, 20.0 }; А для приложения mosstatd добавить ключи, чтобы строка выглядела следующим образом (красным шрифтом отмечены добавленные параметры): gcc -I/usr/src/linux-2.4.26-openmosix1/include/ -I/usr/local/openmosix-tools/include/ -o mosstatd -L/usr/local/openmosix-tools/lib/ -lmos mosstatd.c В итоге, запустив предварительно сервис сбора статистики mosstatd (например, через инициализационный скрипт /etc/rc.d/rc.local), мы сможем отслеживать загрузку кластера в виде трехмерного изображения (см. рис. 6). # 3dmosmon localhost
Рисунок 6. Трехмерное изображение загрузки кластера Сборка остальных программ достаточно тривиальна: # cd openmosixview # make # ./openmosixview По такому же принципу собираются и остальные утилиты. openMosixview – наглядный пример, какие узлы в данный момент загружены и общая картина по производительности (см. рис. 7).
Рисунок 7. Визуальная картина загрузки посредством утилиты openMosixview Приведена ситуация, когда отключен наименее производительный узел. Отключение узла от кластера отображается индикатором красного цвета. Графическая утилита openmosixmigmon позволяет, не утруждая себя поисками PID конкретного процесса, перебросить его выполнение на другой узел (см. рис. 8).
Рисунок 8. Контроль за миграцией процессов в кластере В частности, некоторые процессы с головного узла уже насильно мигрированы к соседям и используют их вычислительные мощности. Следующая интересная утилита из данного пакета называется openMosixanalyzer. Видна нагрузка как в целом на кластер, так и на отдельные узлы за определенный момент времени (см. рис. 9).
Рисунок 9. Статистика по загрузке кластера в определенное время А чтобы такая статистика велась на постоянной основе, придуман сервис openMosixcollector, как видим из названия, его работа заключается в сборе данных и сохранении их на диске. Запускается он просто – «openmosixcollector -d» – работает в качестве сервиса. Собранная информация раз в сутки сбрасывается в директорию /tmp/openmosixcollector_ДАТА_ВРЕМЯ. Давайте теперь ознакомимся с утилитами по настройке кластера. mosctl – утилита для просмотра/редактирования параметров узла. Рассмотрим характерные конструкции на основе данной утилиты. # mosctl –help
Как видите, тот пример, что мы рассмотрели и использовали в своей работе, можно переписать намного нагляднее при использовании утилиты mosctl. # moslimit –help
Для миграции процессов в пределах кластера предназначена утилита migrate. # migrate –help
А вот список процессов, который мы сможем увидеть при запуске утилиты ompsinfo. root@node0:~# ompsinfo
Утилита mosmon предназначена для визуального отображения текущей загрузки кластера. Она скомпилирована на основе библиотеки ncurses, поэтому текстовой консоли вполне будет достаточно для ее запуска. Для запуска заданий предназначена утилита mosrun. С ее помощью можно указать, к какому типу процессов принадлежит наше задание. Либо это CPU-intensive, т.е. задание, использующее процессорные ресурсы, либо I/O-intensive – задание, где основной упор делается на процесс ввода/вывода.
Утилита showmap выводит список узлов кластера. root@node0:~# showmap
Сервис, отвечающий за динамическое определение узлов кластера. В частности, когда на узле используется несколько сетевых интерфейсов, следует явно указать, по какому из них проводить идентификацию узлов. omdiscd-i eth0 Выводы Как и в любом аспекте нашей жизни можно найти минусы и плюсы, так и решения на базе OpenMosix-кластера содержат некие «узкие» точки. В частности, оцифровка звуковых файлов из формата .wav в формат .mp3 показала, что общее время процесса обработки на кластере превысило аналогичное время на одной ПЭВМ. Повлияла на столь странный результат низкоскоростная среда передачи данных – 100-мегабитная сеть. В целом применение OpenMosix-кластеров целесообразно в тех случаях, когда требуется использовать задачи с высокими интенсивными вычислительными запросами, например сборка программного обеспечения (как показано в этой статье), симуляторы погоды, обработка геофизических данных, математических моделей и в других подобных ситуациях. Ссылки, литература:
|
АНТОН БОРИСОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
