 |
|
|
|
Настраиваем и тестируем HPC MPI-кластер
Настраиваем и тестируем HPC MPI-кластер Вычислительные кластеры в прошлом использовались в основном для военных целей, тогда как сегодня спектр их применения более широк, от классических военных и научных до мультимедийных целей. Но всегда вычислительные кластеры служили для одной задачи – обработки больших массивов данных. Сегодня мы рассмотрим установку и настройку вычислительного кластера, предназначенного для научных целей, а также проведем его тестирование. Но прежде чем перейти к практике, осветим несколько теоретических вопросов. Самый главный из них – что такое кластер? Кластер Пожалуй, одним из лучших определений понятия кластера является высказывание Грегори Пфистера (Gregory F. Pfister). «Кластер – это разновидность параллельной или распределенной системы, которая:
Говоря же проще, кластер, это система, состоящая из нескольких вычислительных единиц (нод), связанных между собой (чаще всего локальной сетью), имеющая единую систему управления. Кластеры бывают трех основных видов:
Первый вид кластеров чаще всего применяется для создания высоконадежных систем, там, где остановка комплекса приведет к большим финансовым потерям предприятия, чаще всего это серверы баз данных и веб-сервера. Второй вид кластера предназначен для распределения нагрузки по узлам системы, в основном применяется для создания высокоэффективных веб-серверов. Иногда первые два вида кластеров объединяются для создания высоконадежных, распределенных систем, тогда как последний тип кластеров предназначен для обособленной задачи – параллельных вычислений. Для последнего вида кластерных систем существуют различные модели, реализующие распараллеливание. Сегодня мы рассмотрим одну из них – MPI (The Message Passing Interface). MPI Message Passing Interface (интерфейс передачи сообщений) – это хорошо стандартизированный механизм передачи сообщений между компьютерами, выполняющими одну задачу параллельно. В данной модели параллельная программа представляет собой множество процессов, взаимодействие которых (обмен данными) осуществляется путем передачи сообщений. Данная технология берет свое начало в 1993 году, когда обобщение различных библиотек привело к появлению первой версии стандарта. Изначально в его разработке участвовали 60 человек из 40 крупных организаций (производители параллельных ЭВМ, университеты, государственные лаборатории и научные центры). На данный момент дальнейшей разработкой стандарта занимается MPI-Forum [1], общественная организация, призванная модернизировать и расширять стандарт. Текущая последняя законченная версия стандарта является 2.0, обсуждаемая версия 2.1, в разработке последней с легкостью может принять участие каждый желающий или просто поучаствовать в дискуссии (при соответствующей квалификации, конечно же). Сама по себе модель передачи данных (не только для MPI) достаточно сложна, поэтому для простоты работы MPI представляет собой набор библиотечных функций для последовательного языка программирования, например для С, С++, Фортран 77/90, с которыми мы в конечном счете и работаем. Почему механизм должен быть хорошо стандартизирован и работать как швейцарские часы? Потому что несогласованность распределения вычисления приведет к тому, что параллельная программа будет работать намного медленнее последовательной. Описание кластера Итак, оставив историю и теорию позади, приступим к рассмотрению и конфигурированию нашего HPC MPI-кластера. Вся настройка будет выполняться на базе ОС Scientific Linux, основанного на семействе операционных систем компании RedHat. Выбор данного дистрибутива обусловлен тем, что в нем присутствует компилятор Intel Fortran Compiler в стандартной комплектации, необходимый для работы, и некоторые другие специализированные пакеты. Аппаратную конфигурацию кластера см. в таблице. Аппаратное обеспечение вычислительного кластера
Некоторые дополнительные пояснения к таблице. Только на управляющем ЭВМ есть жесткие диски (о них позже), остальные станции бездисковые. Вторая и третья группа станций поддерживает технологию Hyper Threading в процессорах, а четвертая 64-битную архитектуру. Кроме различий в процессорах, группы различаются количеством оперативной памяти и ее скоростными характеристиками. Уже заранее можно прогнозировать, что более медленные вычислительные единицы предыдущего поколения будут затормаживать весь кластер в целом, и далее на тестах мы увидим это наглядно, но более подробно мы рассмотрим этот момент в конце статьи. Стоит отметить, что отличительной чертой процессоров Xeon серии 5130 является высокая производительность при более низких частотах. Еще одной важной деталью является то, что в кластере используется коммуникационная технология Gigabit Ethernet, самая дешевая, но и, к сожалению, самая медленная для организации связи в кластере. Все эти данные помогут нам в будущем распределять типы задач и соответственно нагрузку на единицы кластера. Вся система функционирует следующим образом (см. рис. 1): управляющей является машина с единственным дисковым массивом, все остальные модули являются вычислительными (далее вычислительные модули – ВМ) и загружаются по сети с управляющей машины. С головной машины также производится распределение вычислительных задач по модулям.
Рисунок 1. Схема кластера Дисковый массив управляющей машины Дисковое пространство всегда лучше планировать заранее и, если есть возможность, всегда резервировать некоторое количество гигабайт «про запас». Итак, первый дисковый состоит из двух жестких дисков объемом 70 Гб, объединенных в RAID 1. Второй массив (под пользовательские данные), четыре винчестера по 160 Гб, объединенных в RAID 10 (1+0). Таблица разделов будет выглядеть так: Системный RAID-1 разбит следующим образом:
Создана группа логических томов SysVolGroup, занимающая всё оставшееся пространство на системном RAID, включающая следующие логические тома:
RAID-10 (RAID данных) был разбит следующим образом. Создана группа логических томов DataVolGroup, занимающая всё пространство на RAID-10. Включает единственный том UserData (/home) – под данные пользователей ~217 Гб. В запасе примерно 100 Гб неразмеченного пространства, которое можно при необходимости добавить. Сервисы кластера Для работы кластера нам необходимы следующие сетевые сервисы:
Это все основные сетевые службы, они необходимы для работы кластера, рассмотрим их настройку и некоторых других служб подробнее. Настройка сети Настройка сети может осуществляться на этапе установки ОС, может и после установки системы. Конфигурирование сетевых интерфейсов может производиться как с помощью графических средств, так и с помощью консольных утилит. Ниже приведен пример настройки путём прямого редактирования файлов настроек. Файлы с настройками сетевых интерфейсов находятся в каталоге /etc/sysconfig/networking-scripts (пожалуй, стоит напомнить, что вся настройка осуществляется в дистрибутиве Scientific Linux, основанном на RedHat Linux, в иной ОС *nix, данные файлы могут находиться в другом месте). Название этих файлов ifcfg-eth0 и ifcfg-eth1 для первого и второго сетевого интерфейса соответственно. Листинг файла ifcfg-eth0 (внутренний интерфейс): cat /etc/sysconfig/networking-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=none BROADCAST=192.168.31.255 IPADDR=192.168.31.1 NETMASK=255.255.255.0 NETWORK=192.168.31.0 ONBOOT=yes TYPE=Ethernet Листинг файла с внешним интерфейсом не приводится из-за неактуальности в данном контексте и незначительности различий с предыдущим. DNS-сервер DNS-сервер, bind-9.2.4-27.0.1.el4 управляющего узла выполняет прямое и обратное преобразование имён узлов в IP-адреса. Обратное преобразование требуется некоторыми пакетами программ, например, torque-pbs (система организации очередей заданий). DNS-сервер настроен как кэширующий сервер и обслуживающий внутреннюю сеть (сеть вычислительных модулей). Основной файл настройки выглядит следующим образом: options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; // query-source address * port 53; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; }; zone "." IN { type hint; file "named.ca"; }; zone "localdomain" IN { type master; file "localdomain.zone"; allow-update { none; }; }; zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; }; }; zone "0.0.127.in-addr.arpa" IN { type master; file "named.local"; allow-update { none; }; }; // Указание, в каком файле находится описание прямой зоны // cluster и то, что сервер является главным для этой зоны zone "cluster" IN { type master; file "cluster"; allow-update { none; }; }; // Указание, где находится описание обратного преобразования // для зоны cluster zone "31.168.192.in-addr.arpa" { notify no; type master; file "192.168.31"; allow-update { none; }; }; include "/etc/rndc.key"; Файл с описанием прямой зоны cluster находится в каталоге /var/named/chroot/var/. Содержимое файла cluster выглядит следующим образом:
Файл с описанием обратных преобразований для зоны cluster находится в том же каталоге (/var/named/chroot/var/named), на него также существует мягкая ссылка, которая находится в каталоге /var/named. Имя файла с данными обратной зоны – 192.168.31. Содержимое выглядит следующим образом:
tftp-сервер Trivial File Trasfer Protocol – простой протокол передачи файлов. Используется главным образом для первоначальной загрузки бездисковых рабочих станций. Не содержит возможностей аутентификации и использует в качестве транспорта протокол UDP. Пакет, в котором содержится данный сервер, называется: tftp-server. Если он отсутствует в системе, необходимо его установить. tftp-служба работает через суперсервер xinetd; чтобы запустить её, выполните следующие команды: /sbin/chkconfig --level 345 xinetd on /sbin/chkconfig --level 345 tftp on Эти команды настраивают запуск служб tftp и xinetd на уровнях выполнения 3, 4 и 5. Запуск выполняется командой: /sbin/service tftp start /sbin/service xinetd start DHCP-сервер Протокол динамической конфигурации узлов (Dynamic Host Configuration Protocol, DHCP) – сетевой протокол для автоматической выдачи IP-адресов и других сетевых параметров клиентским компьютерам. Каждый клиент DHCP соединяется с выделенным DHCP-сервером, который возвращает ему параметры сети, включая IP-адрес, адреса шлюза и DNS-серверов. Конфигурационный файл для кластера /etc/dhcpd.conf содержит следующие данные: default-lease-time 600; max-lease-time 7200; authoritative; ddns-update-style none; option domain-name "cluster"; option routers 192.168.31.1; option domain-name-servers 192.168.31.1; option swap-path code 128 = string; option swap-size code 129 = integer 32; subnet 192.168.31.0 netmask 255.255.255.0 { range 192.168.31.11 192.168.31.21 option subnet-mask 255.255.255.0; option broadcast-address 192.168.31.255; group { filename "linux-install/pxelinux.0"; option root-path "/diskless/root"; next-server 192.168.31.1; host m01 { option host-name "m01.cluster"; hardware ethernet 00:0E:0C:4D:16:95; fixed-address 192.168.31.11; } # Полный конфигурационный файл не приводится # ввиду неактуальности и однотипности настройки … … … … … host m12 { option host-name "m12.cluster"; hardware ethernet 01:0E:0C:4D:19:95; fixed-address 192.168.31.21; } } } allow booting; allow bootp; Дополнительно в файл /etc/sysconfig/dhcpd добавлена строчка: DHCPDARGS=eth0 указывающая на то, что сервер должен будет «слушать» только интерфейс eth0 (интерфейс внутренней сети – 192.168.31.0/24). NFS-сервер Необходим для экспорта файловых систем или отдельных каталогов для бездисковых клиентов. Файл настроек /etc/exports выглядит следующим образом: # export filesystems for dumb nodes # Экспорт корневой файловой системы доступной только для чтения /diskless/root 192.168.31.0/24(ro,sync,no_root_squash) # Экспорт файловой системы с программами для всех модулей /usr/local 192.168.31.0/24(ro,sync,no_root_squash) # Файловая система с файлами бездисковых клиентов, к которым необходим доступ на запись /diskless/snapshot 192.168.31.0/24(rw,sync,no_root_squash) # Файловая система для хранения swap-файлов бездисковых машин /diskless/swap 192.168.31.0/24(rw,sync,no_root_squash) # Домашний каталог пользователей с доступом на запись /home 192.168.31.0/24(rw,sync,no_root_squash) NTP-сервер Используется для синхронизации машинного времени на всех вычислительных модулях кластера. Конфигурационный файл сервера выглядит следующим образом: restrict 192.168.31.0 mask 255.255.255.0 nomodify notrap restrict 127.0.0.1 restrict 127.127.1.0 restrict 127.127.27.0 nomodify server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift broadcastdelay 0.008 keys /etc/ntp/keys Управляющая машина является сервером синхронизации времени, при этом не производит синхронизации с внешними серверами времени. ВМ локальной сети могут только прочитать данные сервера, прав на изменение времени нет. Библиотеки MPI. LAM MPI На управляющей машине и ВМ установлен пакет lam-7.0.6-5, который входит в дистрибутив Scientific Linux. В данном случае использовался именно он. Более новую версию (исходные коды, а также rpm-пакеты для RedHat) можно найти по адресу [2]. Его конфигурационный файл: /etc/lam/lam-bhost.def. Содержимое конфигурационного файла: m11 cpu=4 m10 cpu=4 m09 cpu=4 m08 cpu=4 m07 cpu=4 m06 cpu=4 m05 cpu=4 m04 cpu=2 m03 cpu=2 m02 cpu=2 m01 cpu=2 master cpu=2 MPICH MPICH версии 1.2.7p1 [3] cобирался из исходных кодов со следующими опциями: -rsh=ssh -with-device=ch_p4 --with-comm=shared --prefix=/usr/local/gmpich-1.2.7p1 -f90=gfortran В каталоге /usr/local создана мягкая ссылка mpich на каталог gmpich-1.2.7p1. Конфигурационный файл machines.LINUX находится в каталоге /usr/local/mpich-1.2.7p1/share. Содержимое файла настроек: m11:4 m10:4 m09:4 m08:4 m07:4 m06:4 m05:4 m04:2 m03:2 m02:2 m01:2 parallel:2 На каждой строке находится имя машины или IP-адрес, после двоеточия указывается количество ядер. «Заводим» клиентов Итак, наша управляющая машина почти настроена, осталось только «завести» бездисковых клиентов. Полную инструкцию на русском языке, как это делается, можно найти здесь [4], поэтому коротко пройдемся по пунктам и рассмотрим некоторые изменения. Мы уже создали на сервере каталог, который будет корнем файловых систем бездисковых станций /diskless/root, и каталог /diskless/snapshot, где будут находиться все изменяемые файлы бездисковых станций. Скопируем корневую файловую систему командой: rsync -a -e / /diskless/root/ Далее, следуя указаниям по ссылке выше, добавьте новые узлы. После чего в каталоге /diskless/snapshot появятся следующие файлы:
где m01, ..., m11 – каталоги вычислительных станций, они содержат сгенерированные скриптами при добавлении новых узлов стандартные каталоги (boot, dev, etc, lib, root и var). Файл «files» мы изменять не будем, в нем содержится список файлов, которые копирует каждый клиент, а вот в файл «files.custom» при желании можно изменять, так как он создан специально для добавления необходимых файлов (см. дополнительную информацию). В директориях /diskless/snapshot/MХX/etc/ (где ХХ – номера ВМ) наших вычислительных станций внесем некоторые изменения. Файл fstab: none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /tmp tmpfs defaults 0 0 parallel:/usr/local /usr/local nfs defaults,ro 0 0 parallel:/home /home nfs defaults,rw 0 0 Файл hosts (пример на ВМ m01): 127.0.0.1 m01.cluster m01 localhost.localdomain localhost И файл ntp.conf: restrict 127.0.0.1 server parallel.cluster server 127.127.1.0 # local clock driftfile /var/lib/ntp/drift keys /etc/ntp/keys Также необходимо скопировать файлы passwd, group, shadow и gshadow из директории /etc/ в папки на вычислительные станции. Далее выполним chroot в /diskless/root и с помощью утилиты chkconfig выключим необязательные на ВМ сервисы. Наверное, более «красивым» решением было бы использовать NIS и LDAP в данном случае, эта задача, возможно, будет реализована в будущем на кластере. Еще одним, казалось бы, явным решением было использовать символические ссылки, но в данном случае, если сделать ссылки на не экспортируемой файловой системе – «не заработает». Все, если все было правильно сделано (и несомненно прочитана документация, приведенная в начале абзаца), то наш кластер будет готов для тестирования. Тестирование кластера План: тестирование «новых» модулей на параллельной версии linpack (HPLinpack [5] и библиотека ATLAS [6]), отдельное тестирование модулей с предыдущим поколением процессоров, далее этап измерения производительности системы из «новых» и «старых» модулей. Изменение в производительности будут отражать графики. Тестирование модулей с процессорами Xeon 5130. Размерность матрицы для тестовых запусков варьируется от 1000 до 15000 и верхняя граница определяется объёмом доступной оперативной памяти. Несмотря на то что на 28 процессорах есть возможность использовать тестовый набор с квадратной матрицей размерностью 20000, на одном процессоре запуск задачи с матрицей 16000 был невозможен – недостаточно памяти на вычислительном модуле. График тестов выглядит следующим образом (см. рис. 2), где слева показана производительность в Gflop/s, снизу количество задействованных ядер, справа – размерность матрицы.
Рисунок 2. Производительность Xeon 5130 В следующем тесте (см. рис. 3) количество ядер увеличивалось за счёт машин с процессорами Xeon 5130. Последние восемь ядер – более ранние модели (P4 Xeon c 3,0 и 2,8 Ггц соответственно). На графике хорошо видно, как падает производительность системы на матрицах больших размерностей, на матрицах малого размера, изменение производительности незначительно на 24 ядрах, по сравнению с запуском теста на 8, 16 и 20 ядрах.
Рисунок 3. Производительность Xeon 5130 плюс P4 (без Hyper Threading) Следующий тест (см. рис. 4) проводился на 20 ядрах Xeon 5130 и 4 процессорах Xeon 3.0 Ггц с использованием технологии Hyper Threading (HT). По графику видно, как сильно падает суммарная производительность системы. То есть несмотря на то, что в некоторых задачах технология Hyper Threading может дать существенный прирост производительности, на данном тесте ситуация только ухудшилась.
Рисунок 4. Производительность Xeon 5130 плюс P4 (с Hyper Threading) Следующий график (см. рис. 5) – результаты отдельного тестирования производительности модулей на базе Intel Xeon P4. Очень хорошо видно, что модули на базе Intel Xeon P4 почти доходят всего лишь до отметки в 11 GFlop/s, в этом, вероятно, играет некоторую роль разброс в тактовых частотах процессоров вычислительных модулей и разная скорость памяти.
Рисунок 5. Производительность Xeon P4 Последний график (см. рис. 6) представит изменение производительности при добавлении в вычислительном процесе к 28 новым ядрам Xeon 5130 четырех ядер Xeon 3.0 Ггц.
Рисунок 6. Производительность Xeon 5130 и Xeon 3.0 Ггц Выводы Итак, тестирование завершено, теперь можно делать выводы. Различные группы (см. таблицу) кластера не имеет смысла объединять для решения одной задачи, так как суммарная производительность системы существенно снизится. Лучшим вариантом будет распределение задач по модулям в зависимости от приоритетов: низкоприоритетные задачи запускать на модулях с процессорами предыдущего поколения, а задачи с высоким приоритетом запускать на модулях, оснащённых процессорами Xeon 5130 с высокоскоростной памятью DDR2. Сделать это можно редактированием на ВМ конфигурационных файлов mpich, что и делалось на первых этапах. Но более верным решением будет использование систем управления заданиями: OpenPBS [8] либо TorquePBS [9]. Для повышения производительности кластера следует как минимум использовать иную сетевую технологию, а как максимум заменить старые вычислительные модули на аналогичные новым Xeon 5130. P.S. Хочу выразить благодарность за помощь в составлении материала моему доброму другу Селянину Олегу. Приложение Архитектуры параллельных ЭВМ MPI всего лишь модель программирования, базирующаяся на двух возможных архитектурах – классическая кластерная и массивно-параллельная система (MPP). Основное отличие этих архитектур от других в том, что система состоит из блоков (ЭВМ) с одним или несколькими процессорами, локальной памятью и отсутствием доступа к памяти другого блока ЭВМ. Пожалуй, именно эти архитектуры наиболее распространены в государственных учреждениях из-за своей дешевизны, так как могут быть собраны из стандартных ЭВМ. Другой распространенной архитектурой является симметрично мультипроцессорные системы (SMP). Их главной отличительной чертой является наличие единой памяти (зачастую это независимые блоки). Процессоры имеют доступ к любой ячейке этой памяти. Двумя другими, менее распространенными архитектурами являются: системы с неоднородным доступом к памяти (NUMA), где каждый блок (ЭВМ) имеет свою локальную память, но другие блоки имеют удаленный доступ к ним (т.е. поддерживается единое адресное пространство) и системы параллельно векторные (PVP). Основным отличием последних систем является работа на специальных векторно-конвейерных процессорах и как правило с единой памятью (так же как и SMP). Эффективность данной архитектуры заключается в том, что набор (вектор) данных обрабатывается одной командой, что гораздо быстрее скалярной (классической) обработки. Говоря же проще, подобный процессор способен за меньшее количество тактов обработать больше информации, поступающей в определённой форме, в данном случае – векторов или массивов. Сети для кластеров Несмотря на широкое распространение ethernet-сетей, для связи в кластере данная технология крайне не эффективна. Связано это с тем, что для синхронизации задач на кластере между вычислительными единицами требуется пересылать большое количество коротких сообщений и время задержки в их пересылке по сети играет огромную роль. Но это скорее следствие, дело в том, что Ethernet построен на CSMA/CD – конкурентном доступе к среде передачи с возможными коллизиями, что при массированном доступе создает непредсказуемые задержки, что и является причиной неэффективности технологии. Специально для решения этих задач были разработаны различные сетевые технологии, вот наиболее распространенные из них и их характеристики:
Что за чудо-юдо зверь – HPLinpack? HPLinpack представляет собой пакет для тестирования вычислительных кластеров с распределенной памятью. В основу тестов пакета заложено: решение систем линейных алгебраических уравнений (СЛАУ) методом LU-факторизации (разложения) с выбором ведущего элемента столбца матрицы, при этом матрица системы заполняется случайными вещественными числами с двойной точностью. Говоря же проще, HPLinpack – это набор тестов (программ), которые решают задачи линейной алгебры (если еще проще – решают задачи с большими матрицами). Алгоритм работы пакета (математику) и другие интересные темы, связанные с тестированием кластерных систем, можно почитать либо на сайте программы, либо в статье Андрея Сапронова «Обзор некоторых пакетов измерения производительности кластерных систем» [7]. «Ну а как же Gigabit Ethernet?» – возможно, спросит кто-то. К сожалению, кроме дешевизны, сильных сторон у этой технологии для организации кластеров – нет. Пропускная способность на уровне MPI у данных сетей максимум 120 Мб/сек при времени задержки 10 мс.
|
Иван Максимов
| Комментарии |
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
