Как собрать кластер

Linux.yaroslavl.ru

2. Как,что и где.

4. Настройка

Теперь после перезапуска mosix ваша машина уже будет работать в кластере, что можно увидеть запустив монитор командой mon. В случае, если вы увидите в мониторе только свою машину или вообще не увидите никого, то, как говорится — надо рыть. Скорее всего у вас ошибка именно в /etc/mosix.map.
Ну вот, увидили, но не победили. Что дальше? А дальше очень просто 🙂 — нужно собрать утилиты для работы с измененным /proc из пакета mproc. В частности в этом пакете идет неплохая модификация top — mtop, в который добавили возможность отображения узла(node), сортировки по узлам, переноса процесса с текущего узла на другой и установления минимальной загрузки процессора узла, после которой процессы начинают мигрировать на другие MOSIX — узлы.
Запускаем mtop, выбираем понравившийся не спящий процесс (рекомендую запустить bzip) и смело давим клавишу «g» на вашей клавиатуре, после чего вводим на запрос PID выбранного в качестве жертвы процесса и затем — номер узла, куда мы хотим его отправить. А уже после этого внимательно посмотрите на результаты, отображаемые командой mon — та машина должна начать брать на себя нагрузку выбранного процесса.
А собственно mtop — в поле #N отображать номер узла, где он выполняется.
Но это еще не все — ведь вам правда не хочется отправлять на другие узлы процессы вручную? Мне не захотелось. У MOSIX есть неплохая встроенная балансировка внутри кластера, которая позволяет более-менее равномерно распределять нагрузку на все узлы. Ну а вот здесь нам придется потрудится. Для начала я расскажу, как сделать тонкую настройку (tune) для двух узлов кластера? в процессе которой MOSIX получает информацию о скоростях процессоров и сети:
Запомните раз и навсегда — tune можно выполнять только в single-mode. Иначе вы либо получите не совсем корректный результат, либо ваша машина может просто зависнуть.
Итак, выполняем tune. После перевода операционной системы в single — mode например командой init 1 или init S запускаем скрипт prep_tune, который поднимет cетевые
интерфейсы и запустит MOSIX. После этого на одной из машин запускаем tune, вводим ему номер другого узла для настройки и ждем результата — утилита должна выдать запрос на ввод шести чисел, полученных от выполнения команды tune -a на другом узле. Собственно операцию придется повторить на другом узле командой tune -a , а результат из шести чисел ввести на первый узел. После подобного тюнинга в вашей системе должен появится файл /etc/overheads, содержащий информацию для MOSIX в виде неких числовых данных. В случае, если по каким-то причинам tune не смог сделать его, просто скопируйте из текущего каталога файл mosix.cost в /etc/overheads. Это поможет ;-).
При тюнинге кластера из более чем двух машин нужно использовать утилиту, которая также поставляется с MOSIX — tune_kernel. Данная утилита позволяет
вам в более простом и привычном виде настроить кластер, ответив на несколько вопросов и проведя тюнинг с двумя машинами кластера.
Кстати, по собственному опыту могу сказать, что при настройке кластера я рекомендую вам не загружать сеть, а наоборот — приостановить все активные операции в локальной сети.

5. Управление кластером

mosctl — контроль над узлом. Позволяет изменять параметры узла — такие, как block, stay, lstay, delay и т.д
Давайте рассмотрим несколько параметров этой утилиты:
stay — позволяет останавливать миграцию процессов на другие узлы с текущей машины. Отменяется параметром nostay или -stay
lstay — запрещает только локальным процессам миграцию, а процессы с других машин могут продолжать это делать. Отменяется параметром nolstay или -lstay.
block — запрещает удаленным/гостевым процессам выполнятся на этом узле. Отменяется параметром noblock или -block.
bring — возвращает обратно все процессы с текущего узла выполняемые на других машинах кластера. Этот параметр может не срабатывать, пока мигрировавший процесс не получит прерывание от системы.
setdelay устанавливает время, после которого процесс начинает мигрировать.
Ведь согласитесь — в случае, если время выполнения процесса меньше секунды смысл переносить его на другие машины сети исчезает. Именно это время и выставляется утилитой mosctl с параметром setdecay. Пример:
mosctl setdecay 1 500 200
устанавливает время перехода на другие узлы 500 миллисекунд в случае, если процесс запущен как slow и 200 милисекунд для fast процессов. Обратите внимание, что параметр slow всегда должен быть больше или равен параметру fast.

mosrun — запускает приложение в кластере. например mosrun -e -j5 make запустит make на 5-ом узле кластера, при этом все его дочерние процессы будут также выполнятся на 5-ом узле. Правда здесь есть один нюанс, при чем довольно существенный:
в случае, если дочерние процессы выполняются быстрее чем установленная утилитой mosctl задержка (delay) то процесс не будет мигрировать на другие узлы кластера. у mosrun еще довольно много различных интересных параметров, но подробно узнать
о них вы сможете из руководства по этой утилите. (man mosrun)

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

mtop — модифицированная для использования на узлах кластера версия команды top. Отображает на экране динамическую информацию о процессах, запущенных на данном узле, и узлах, куда мигрировали ваши процессы.

mps — тоже модифицированная версия команды ps. Добавлено еще одно поле — номер узла, на который мигрировал процесс.

Вот на мой взгляд и все основные утилиты. На самом деле конешно можно обойтись даже без них. Например используя для контроля над кластером /proc/mosix.
Там кроме того, что можно найти основную информацию о настройках узла, процессах запущенных с других узлов и т.д.,а также поменять часть параметров.

6. Эксперементируем.

7. Использование

8. Заключение

В заключение хочу сказать, что в этой статье не рассмотрены все возможности MOSIX, т.к. я просто до них еще не добрался. Если доберусь — ждите продолжения. 🙂

Домашний Мини-кластер

Ранние суперкомпьютеры использовали параллельную обработку данных и распределенные вычисления для того, чтобы соединить процессоры вместе в одну машину. Сегодня же это возможно повторить буквально в домашних условиях используя подручные инструменты и некоторое количество недорогих материнских плат с процессорами и памятью – такой подход к созданию мощных машин называется «создать кластер». Глену Гарднеру понравилась эта идея, поэтому он решил построить самостоятельно у себя дома массивный кластер из параллельно соединенных компьютеров на основе материнских плат Mini-ITX. В кластере используется двенадцать 800 Мегагерцовых кластерных узлов.

Оригинальная конфигурация из шести узлов.

Завершенный кластер состоящий из двенадцати узлов.

На фотографии показано, сколько мощности потребляют шесть узлов в режиме бездействия – всего-то 60 ватт (по 10 ватт на каждый узел).
На тот момент, когда я закончил работу над кластером, весь кластер с 12-ю узлами потреблял в режиме бездействия приблизительно 140 Ватт (это, считай, 12 полноценных компьютеров), пиковая нагрузка составляла приблизительно 200 Ватт. Никаких проблем с чрезмерным выделением тепла и перегревами замечено не было. Контролирующий узел обладал оперативной памятью объемом в 256 Мегабайт, и, как я уже говорил, винчестером объемом 160 Гигабайт. Официальных тестов на этой машине я еще не проводил, но на первый взгляд с простыми задачами мини-кластер справлялся быстрее, чем четыре машины с процессорами P4 2.4 GHz объединенные в одну сеть с параллельной обработкой данных, это еще не учитывая энергопотребление и цену!

Питание и охлаждение

Платы Mini-ITX обладают очень малым рассеянием мощности по сравнению с большинством популярных комбинаций современных материнских плат с процессорами. Это означает, что кластер построенный на материнских платах Mini-ITX с, например, шестнадцатью вычислительными узлами не потребует абсолютно никакого специального охлаждения. Маленькое рассеяние мощности также означает, что кластер будет потреблять минимальное количество электроэнергии (примеры я приводил выше), что в свою очередь означает, что можно использовать всего одну недорогую UPS-ку для обеспечения «чистого» и стабильного питания всему кластеру.

Как говорится, все познается в сравнении, поэтому я приведу контрастный пример использования 12-16 вычислительных узлов построенных на основе процессоров от Intel или AMD, которые будут генерировать достаточно тепла для того, чтобы помещение пришлось охлаждать кучей кондиционеров. В добавок ко всему для питания такой монструозной системы вам понадобится стабильная электрическая линия выдерживающая пиковую нагрузку в два-три киловатта (сравниваем с 200 Ваттами пиковой нагрузки кластера построенного на матплатах Mini-Itx (что как минимум в 10 раз меньше)), которые будет потреблять ваш кластер состоящий всего-то из 12 вычислительных узлов на пентиумах. Так что если вы будете использовать процессоры от Intel или AMD, то готовьтесь к дополнительным счетам за электричество и кондиционирование…

Конструкция с точки зрения «железа»

Кластер построен на двух приблизительно одинаковых «шкафах». В каждом «шкафу» установлено два отдельных стеллажа – на каждом стеллаже по три материнские платы и по три адаптера dc-dc (постоянный ток – постоянный ток), которые установлены на алюминиевых стержнях-ножках.

Также поверх каждого стеллажа крепился стек с адаптерами IDE -> CompactFlash, также по три адаптера на один стеллаж. Каждый стек с платами крепился между двух алюминиевых листов (размерами 18 см на 25 см) толщиной 1,6 мм. В общей сложности на каждый «шкаф» использовалось семь алюминиевых панелей.

На верхней крышке я закрепил кронштейн с шестью кнопками (включить-выключить-перезагрузить).

Плата установленная ниже играла роль терминала раздачи электропитания. Кабель, подающий напряжение на каждый шкаф, естественно был достаточно мощным – многожильный (под номером 14) в поливинилхлоридной изоляции. Кабели, забирающие питание с терминала и подводящие его к каждому вычислительному узлу (вернее к dc-dc адаптеру) были попроще – обычный (номер 18) многожильный подвесной монтажный провод с поливинилхлоридной изоляцией. Кабели шедшие от кнопок сброса/включения питания были совсем простыми многожильными проводами (номер 24), также облаченными в поливинилхлоридную изоляцию.

В первом «шкафу» кластера содержится шесть узлов (с первого по шестой), причем первый узел является управляющим узлом, остальные узлы являются вычислительными. В основании первого «шкафа» также крепится винчестер на 160 Гигабайт, который используется управляющим узлом. Все остальные узлы подключаются к накопителям IBM Microdrive. Узел номер три имеет отдельный адаптер Compact Flash, который может использоваться для дублирования накопителей Microdrive, что достаточно заметно упрощает обслуживание.

Кабели идущие от накопителей (шлейфы и кабели питания) были аккуратно, на сколько это возможно, уложены в одну линию на задней панели. Везде и всюду для стяжки кучи проводов я использовал пластиковые хомуты, которые помогли избежать «джунглей» из проводов, в которых я вряд ли бы смог отыскать хоть одну материнскую плату или накопитель.

Нижний «шкаф» включал в себя узлы с седьмого по двенадцатый, к каждому узлу устанавливался один накопитель Microdrive (крепились накопители точно также, как и в верхнем шкафу). Таким образом нижний шкаф отличается от верхнего только лишь отсутствием установленного снизу винчестера. Вся работа по металлу производилась вручную – для этого я использовал алюминиевые листы толщиной 1,6 миллиметров и двухсантиметровый алюминиевый уголок. Все это устанавливалось на вертикальные металлические опоры. На днище корпуса были установлены самоклеящиеся резиновые ножки, которые предотвращали повреждение деликатных поверхностей.
Никаких сложных работ по сверлению и резке не производилось, все просто – отрезал, просверлил несколько отверстий, закрепил.
Все прровода подсоединялись, естественно, вручную – использовались обычные инструменты вроде кусачек и плоскогубцев. Провода зажимались в обычные зажимы с винтом.

Провода также вручную припаивались к выключателям и кнопкам обыкновенным паяльником. Другая сторона подключалась к стандартному 2,5 миллиметровому коннектору, который в свою очередь подключался к материнской плате.
Сеть

Что можно сказать по поводу сети? Да здесь тоже нет ничего необычного. Для соединения компьютеров я использовал обыкновенные встроенные в материнские платы сетевые адаптеры (fast Ethernet, 100 Мегабит). Сетевой концентратор (ну если по-простому, то свитч или хаб), который установлен между двух шкафов представлял собой простой дешевый сетевой концентратор на 16 портов, приобретенный в обычном магазине офисного оборудования всего за 80$. Сетевой кабель я обжал вручную, использовалась хорошая, высококачественная витая пара (8 жил) пятой категории.

Некоторые соображения по поводу питания

Конвертеры DC-DC требуют чистое и точное напряжение в 12 вольт постоянного тока, лишенное каких-либо помех, перепадов и скачков. Для подачи такого напряжения я выбрал мощный импульсный блок питания на 60 ампер, выдающий стабильное ровное напряжение в 12 вольт. Блок питания выдает до 60 ампер в пике. Для обеспечения ровного переменного тока на входе (у нас напряжение не совсем стабильное и бывают перепады) я выбрал UPS на 1 КВА. Этот монстр заодно будет обеспечивать питанием компьютеры в то время, когда местная компания отключит электричество. Вообще я думаю, что иногда стоит заранее подумать об электропитании – мой «мод» вышел далеко недешевым и я не согласен жить с мыслью, что в один прекрасный день весь кластер погорит к чертям. После того, как я обеспечил своему мини-кластеру такую отличную защиту, я могу быть спокойным за безопасность и отказоустойчивость оборудования.

delirium_00

Журнал физика-программиста

Мой домашний компьютерный кластер на MPI

Наконец, нашлось время перевести мою многопоточную программу на рельсы MPI и сделать ее «многопроцессовой». В данный момент она исполняется на домашнем компьютерном кластере, состоящем из 4 компьютеров. Теоретически, точно также она должна работать и на 1000 компьютерах и на суперкомпьютере. Как мне это удалось?

Начать с того, что алгоритм прекрасно параллелится. То есть мне не нужно ломать голову, как разбить всю задачу на 1000 независимых подзадач и как потом объединить результаты вычислений.

Для начала нужно установить на всех компьютерах кластера библиотеку MPI. Я использовал реализацию MPICH. Уточню, что я работаю пока почти исключительно в ОС Windows. Для успешной совместной работы, необходимо, чтобы на всех компьютерах были заведены пользовательские аккаунты с одинаковыми именами и паролями. Также при установке MPICH спросит кодовое слово, оно должно быть одно для всех компьютеров кластера.
Лучшая статья о том, как начать работу с MPICH в Windows.
smpd -install
mpiexec -remove
mpiexec -register
mpiexec -validate (it should return SUCCESS )
smpd -status (it should return ‘smpd running on ‘)
И вот, в конфигураторе я вижу:

А значит все узлы кластера готовы к работе.
Теперь нужно переписать программу для использования MPI.
Организовать вычисления я решил максимально просто. Инициализируются все процессы с помощью конфигурационных файлов совершенно одинаково. Процесс с нулевым рангом (назовем его координатором) не участвует в непосредственных вычислениях, а ожидает сообщений с результатами от остальных процессов и накапливает статистику(объединяет результаты). В ответ на сообщение с результатом, координатор посылает вычислительному процессу сообщение с указанием, стоит ли ему продолжить вычисления или завершить работу. Затем, после окончания расчетов, процесс-координатор запускает GUI, где отрисовывает результаты.
Решено было оставить возможность работы программы в обычном многопоточном режиме, также как возможность компиляции программы без зависимости от библиотеки MPI. Для этого использовались директивы типа

И выбор типа «параллизма» через перечисления:

Из всего многообразия функций MPI понадобятся только эти:

MPI_Recv и MPI_Send для получения и отправки сообщений соответственно.

Здесь от вычислительного потока получается структура TMPISendResultStruct result, а обратно отправляется значение типа boolean. Также здесь прописано условие завершения вычислений. А вот так выглядит код на «другом конце».

Не обошлось и без проблем. Например, с инициализацией генератора случайных чисел. Раньше можно было просто привязаться ко времени. Теперь же есть вероятность инициализации нескольких процессов в один момент времени. Решено было добавлением в информацию для инициализации зависимости от номера процесса. Следующая проблема была связана с выводом GUI. Оказалось, что такая возможность предусмотрена, но только на том компьютере, откуда происходит запуск программы. Для этого в команду нужно добавить параметр -localhost.
А вот так выглядит сама команда для исполнения программы на моем импровизированном кластере:

Создание ClickHouse-кластера

ClickHouse-кластер — это один или несколько хостов базы данных, между которыми можно настроить репликацию.

Важно

При создании кластера ClickHouse из 2 и более хостов Managed Service for ClickHouse автоматически создает кластер из 3 хостов ZooKeeper для управления репликацией и отказоустойчивостью. Эти хосты учитываются в расчете использованной квоты ресурсов в облаке , и в расчете стоимости кластера . Подробнее — в разделе о репликации для ClickHouse.

Количество хостов, которые можно создать вместе с ClickHouse-кластером, зависит от выбранного варианта хранилища:

При использовании сетевых дисков вы можете запросить любое количество хостов (от 1 до пределов текущей квоты).

При использовании SSD-дисков вместе с кластером можно создать не меньше 2 реплик (минимум 2 реплики необходимо, чтобы обеспечить отказоустойчивость). Если после создания кластера доступных ресурсов каталога останется достаточно, вы можете добавить дополнительные реплики.

В консоли управления выберите каталог, в котором нужно создать кластер БД.

Выберите сервис Managed Service for ClickHouse.

Нажмите кнопку Создать кластер.

Введите имя кластера в поле Имя кластера. Имя кластера должно быть уникальным в рамках каталога.

Выберите окружение, в котором нужно создать кластер (после создания кластера окружение изменить невозможно):

• production — для стабильных версий ваших приложений.
• prestable — для тестирования, в том числе самого сервиса Managed Service for ClickHouse. Prestable-окружение обновляется чаще, из-за чего в нем раньше исправляются уже известные проблемы, но могут происходить обратно несовместимые изменения.

Выберите класс хостов — он определяет технические характеристики виртуальных машин, на которых будут развернуты хосты БД. Все доступные варианты перечислены в разделе Классы хостов. При изменении класса хостов для кластера меняются характеристики всех уже созданных экземпляров.

В блоке Размер хранилища:

Выберите тип хранилища — более гибкое сетевое (network-hdd или network-ssd) или более быстрое локальное SSD-хранилище (local-ssd). Размер локального хранилища можно менять только с шагом 100 ГБ.

Выберите объем, который будет использоваться для данных и резервных копий. Подробнее о том, как занимают пространство резервные копии, см. раздел Резервные копии.

В блоке База данных укажите атрибуты БД:

• Имя БД.
• Имя пользователя.
• Пароль пользователя. Минимум 8 символов.

В блоке Хосты укажите параметры хостов БД, создаваемых вместе с кластером (помните, что используя SSD-диски при создании ClickHouse-кластера можно задать не меньше 2 хостов). Чтобы изменить добавленный хост, наведите курсор на строку хоста и нажмите значок .

При необходимости настройте параметры СУБД:

Geobase uri — адрес архива с пользовательской геобазой в Object Storage.

Keep alive timeout — время в секундах после поступления последнего запроса к ClickHouse, в течение которого сервер ожидает новый запрос. Если в течение этого времени запросов не поступит, ClickHouse разорвет соединение. Подробнее см. в документации ClickHouse.

Log level — уровень логирования событий. На каждом следующем уровне лог будет содержать всю информацию из предыдущего:

1. ERROR — информация об ошибках в работе кластера;
2. WARNING — информация о событиях, которые могут привести к ошибкам в работе кластера;
3. INFORMATION — подтверждения, информация о событиях, не приводящих к ошибкам в работе кластера;
4. DEBUG — системная информации для последующего использования в отладке;
5. TRACE — вся доступная информации о работе кластера.

Подробнее об уровнях логирования см. в документации ClickHouse.

Mark cache size — приблизительный размер в байтах кэша засечек, используемых движками таблиц семейства MergeTree. Кэш общий для сервера, память выделяется по мере необходимости. Подробнее о логировании в ClickHouse см. в документации.

Max concurrent queries — максимальное количество одновременно обрабатываемых запросов. Подробнее см. в документации ClickHouse.

Max connections — максимальное количество входящих соединений. Подробнее см. в документации ClickHouse.

Max partition size to drop — максимальный размер в байтах партиции таблицы семейства MergeTree, которую можно удалить с помощью запроса DROP .

Max table size to drop — максимальный размер в байтах таблицы семейства MergeTree, которую можно удалить с помощью запроса DROP . Значение 0 означает, что можно удалять все таблицы без ограничений. Подробнее см. в документации ClickHouse.

Timezone — временная зона сервера. Указывается идентификатором IANA в виде часового пояса UTC или географического положения (например, Africa/Abidjan). Подробнее см. в документации ClickHouse.

Uncompressed cache size — размер кеша в байтах для несжатых данных, используемых движками таблиц семейства MergeTree. Подробнее см. в документации ClickHouse.

Compression — правила сжатия данных для таблиц семейства MergeTree.

• Method — метод сжатия. Доступно два метода: LZ4 и zstd.
• Min part size — минимальный размер куска данных таблицы в байтах. ClickHouse будет применять правило только к тем таблицам, у которых размер кусков больше или равен значению Min part size.
• Min part size ratio — отношение размера наименьшего куска таблицы к полному размеру таблицы. ClickHouse будет применять правило только к тем таблицам, у которых такое отношение больше или равно значению Min part size ratio.

Вы можете добавить несколько правил сжатия. ClickHouse проверит условия Min part size и Min part size ratio и применит правила к тем таблицам, для которых выполнены оба условия. Если к одной таблице подходит несколько правил, ClickHouse применит первое из них. Если ни одно из правил не подходит, ClickHouse применит метод сжатия LZ4. Подробнее см. в документации ClickHouse

Graphite rollup — конфигурации движка GraphiteMergeTree для прореживания и агрегирования/усреднения (rollup) данных Graphite. Вы можете настроить несколько конфигураций и использовать их для разных таблиц.

Подробнее о поддержке Graphite в ClickHouse читайте в документации.

• Name — имя конфигурации.
• Patterns — набор правил прореживания. Правило применяется, если имя метрики соответствует значению параметра Regexp, а возраст данных соответствует значению группы параметров Retention.
  • Function — имя агрегирующей функции.
  • Regexp — регулярное выражение, которому должно соответствовать имя метрики.
  • Retention — параметры задержки. Функция применяется к данным, чей возраст оказался в интервале [Age, Age + Precision]. Вы можете задать несколько групп таких параметров.
    • Age — минимальный возраст данных в секундах.
    • Precision — точность определения возраста данных в секундах. Должен быть делителем для 86400 (количество секунд в сутках).

Merge tree — конфигурация движка MergeTree. Подробнее см. в документации ClickHouse

• Max bytes to merge at min space in pool — максимальный общий размер куска данных для слияния, когда в фоновом пуле минимум свободных потоков.
• Max replicated merges in queue — максимальное число задач слияния, которые могут одновременно находиться в очереди ReplicatedMergeTree .
• Number of free entries in pool to lower max size of merge — предельное значение свободных записей в пуле. Если количество записей в пуле становится меньше этого значения, ClickHouse уменьшает максимальный размер куска данных для слияния. Это позволяет быстрее обрабатывать небольшие слияния, а не заполнять пул длительными.
• Parts to delay insert — число активных кусков данных таблицы, при превышении которого ClickHouse будет искусственно уменьшать скорость вставки данных в таблицу.
• Parts to throw insert — предельное число активных кусков данных таблицы, при превышении которого ClickHouse отправляет исключение ‘Too many parts . ‘.
• Replicated deduplication window — число последних блоков хешей, которые ZooKeeper будет хранить (старые блоки будут удалены).
• Replicated deduplication window seconds — время, в течение которого ZooKeeper хранит блоки хешей (старые блоки будут удалены).

Нажмите кнопку Создать кластер.

Если у вас еще нет интерфейса командной строки Яндекс.Облака, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра —folder-name или —folder-id .

Чтобы создать кластер:

Проверьте, есть ли в каталоге подсети для хостов кластера:

Если ни одной подсети в каталоге нет, создайте нужные подсети в сервисе VPC.

Посмотрите описание команды CLI для создания кластера:

Как построить кластер?

Автор: Сбитнев Ю.И.

Хорошая новость заключается в том, что развертывание кластера как такового — задача экстремально простая. Причем, для этого подойдет любой дистрибутив по вашему выбору. Какой именно из дистрибутивов Linux ставить в качестве базовой ОС — не имеет значения. Ubuntu, Mandriva, Alt Linux, Red Hat, SuSE. Выбор зависит только от ваших предпочтений.

Попытаюсь по шагам объяснить, как развернуть кластер, используя дистрибутив общего назначения.

Итак. Вы должны будете:

1. Установить операционную систему на компьютер, который будет выступать в роли консоли кластера. То есть на этом компьютере будут компилироваться и запускаться параллельные программы. Другими словами, за этим компьютером будет сидеть человек, запускать программы и смотреть, что получилось.
2. После инсталлирования базовой ОС на консоли кластера, если это не сделано в процессе первоначальной установки, Вы должны будете установить необходимые компиляторы (фортран, С) и все необходимые библиотеки, desktop environment (GNOME или KDE по вашему выбору), текстовые редакторы и пр., то есть превратить этот компьютер в рабочую станцию разработчика.
3. Установить из репозитория или из исходников пакет MPICH или OpenMPI, если он Вам более по душе. Я лично предпочитаю OpenMPI.
4. Описать в /etc/hosts будущие узлы вашего кластера, в том числе и консоль кластера.
5. Установить NFS и расшарить для всех узлов кластера некую директорию, в которой будут размещаться исполняемые модули параллельных программ и файлы данных, которыми эти программы будут пользоваться в процессе своей работы.
6. Установить на консоли кластера ssh-клиент (обязательно) и ssh-сервер (опционально, если Вы предполагаете давать доступ к консоли кластера по сети).
7. На всех узлах кластера установить операционную систему, библиотеки, необходимые для выполнения пользовательских параллельных программ, установить MPICH, NFS-client, ssh-server. Узлы кластера в целях экономии ресурсов должны грузиться в runlevel 3, так что ставить туда GNOME или KDE не надо. Максимум — поставить туда гномовские или кдешные библиотеки, если они нужны пользовательским программам.
8. Описать в /etc/hosts всех узлов кластера будущие узлы вашего кластера, в том числе и консоль кластера.
9. На всех узлах кластера необходимо автоматом при загрузке монтировать расшаренный в п. 5 ресурс. Причем, путь к этому ресурсу должен быть одинаков, как на консоли кластера, так и на его узлах. Например, если на консоли кластера Вы расшариваете каталог /home/mpiuser/data, то на узлах кластера этот ресурс также должен быть смонтирован в /home/mpiuser/data.
10. На всех узлах кластера обеспечить безпарольный доступ по ssh для консоли кластера. Как это сделать вы можете посмотреть на моем сайте.
11. Собственно, все. Кластер собран и полностью готов к использованию. Фактически для развертывания кластера нам потребовалось установить ОС, зайти в так сказать в «Установку и удаление программ», отметить для установки пакеты SSH и MPICH, запретить запрос пароля удаленного доступа к узлам кластера, расшарить на центральном узле каталог, где будут храниться наши параллельные программы и данные и поставить на узлах кластера автоматическое подключение к этому каталогу при загрузке. Как компилировать и запускать на исполнение параллельные программы Вы можете посмотреть в других разделах этого сайта и в документации к MPICH.

Как видите, все очень просто и ничего, кроме дистрибутива с репозиториями не нужно. Более подробно вопрос установки кластера на базе операционной системы Linux описан в разделе Ubuntu кластер.

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

Таким образом и в консоли кластера и в его узлах необходимо иметь два сетевых интерфейса (две сетевые карты), Соответственно, нужно два набора свитчей, не связанных друг с другом, и два набора сетевых реквизитов для этих интерфейсов. То есть, NFS работает, например, в сети 192.168.1.0/24, а обмен данными происходит в сети 192.168.2.0/24. И соответственно, в файлах /etc/exports и /etc/fstab должны будут быть прописаны адреса из первой сети, а в файлах /etc/hosts и в файла machines.LINUX, описывающих кластер — адреса из второй. Что за файл machines.LINUX — смотрите в документации MPICH.

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

Еще одно. Настоятельно рекомендуется использовать гигабитную сеть, как наиболее доступную для университета (с точки зрения финансов). Строго говоря, Gigabit Ethernet — не лучший выбор в качестве сети кластера в силу того, что эта сеть обладает достаточно большой латентностью. Но это доступное решение. Если же финансы позволят, то лучше конечно обратить внимание на Myrinet или 10Gbit Ethernet.

Далее. Параметры сети никогда не бывают слишком хорошие. Поэтому, если есть возможность, надо стараться их улучшить. Если Myrinet или 10GbE для вас будут недоступны, то можно попытаться улучшить характеристики гигабитной сети. Собственно, сделать из нее двухгигабитку! Погуглите по ключевым словам channel bonding, кроме того, у меня на сайте немного про это написано. Суть дела в том, что вместо одной сетевой карты мы используем две, объединив их специальным драйвером в единый виртуальный канал с двойной пропускной способностью. В этом случае карты должны быть подключены к двум отдельным свитчам, то есть потоки по этим картам мы разделяем так же, как мы это делали раньше, разделяя NFS и передачу данных. Создание такого канала — немного геморройное занятие, поэтому только от вашего желания и энтузиазма зависит, делать это или нет. В принципе, это не обязательно, хотя эффект будет заметный.

Теперь собственно о том, а зачем вообще Вам нужен кластер. Дело в том, что утверждение «чем больше узлов в кластере, тем быстрее он работает» — в общем случае не верно. Давайте посмотрим, в каких случаях нам захочется считать наши программы на кластере. Существует только две цели использования кластера.

1. Имеется разностная сетка размера R, вычисления на которой при использовании обычного компьютера занимают время T. Время T — критический параметр. Нам хочется существенно уменьшить время вычислений, имея R как константу.
2. Имеется разностная сетка размера R, вычисления на которой при использовании обычного компьютера занимают время T. Время T — не критично. Нас интересует увеличение размера сетки сверх имеющейся в одном компьютере памяти для более детального счета, возможного получения более тонких эффектов и т.п.

Все вычисления на разностной сетке имеют один общий и важный для нас параметр: время одной итерации. В случае использования кластера это время состоит из двух частей: время счета на сетке Titer и время обмена данными между узлами Texch. (Почитайте про граничный обмен на моем сайте.) Titer зависит только от мощности процессора. А вот Texch зависит уже, от размера разностной сетки, количества узлов кластера и пропускной способности сети. Я не буду приводить формул, вы их сами можете при желании вывести. (Посмотрите еще вот этот файл. Именно по нему были построены графики.) Приведу окончательный результат для случая двухгигабитной сети, размера разностной сетки 64 гигабита и времени одной итерации 100 сек.

На графике ось ординат — временная характеристика, ось абсцисс — количество узлов кластера.

Обратите внимание на синий график . Это модель первого случая, когда разбиваем разностную сетку постоянного размера на несколько узлов. Как видно из графика, время счета вначале уменьшается, при увеличении количества узлов кластера. Что мы и хотели получить. Однако уменьшение происходит до определенного предела. При количестве узлов более четырех общее время счета снова начинает расти. Происходит это из-за увеличения объема данных, пересылаемых между узлами. Таким образом получается, что при постоянном размере сетки, увеличивать размер кластера свыше четырех узлов не имеет смысла.

Теперь рассмотрим случай 2, когда нам важен размер сетки, а со временем счета мы можем смириться.
Давайте представим, что у нас есть один компьютер с неограниченной памятью. Увеличивая размер разностной сетки, мы получаем линейное (с коэффициентом 1) увеличение время счета. Теперь сравним это время с тем, которое получится, если мы будем считать такую же сетку, но на кластере. Причем увеличивая размер сетки вдвое, мы увеличиваем вдвое и количество узлов кластера. Поскольку две чати сетки обсчитываются параллельно, то время итерации не увеличивается, но появляется время обмена данными. Красный график показывает отношение времени счета на одном компьютере (с неограниченной памятью) ко времени счета такой же сетки на кластере. Желтый график показывает рост времени счета при увеличении узлов кластера (и, соответственно, увеличении размера сетки). И рост этот, что важно, меньше, чем линейный.

Мы видим, что время счета на кластере существенно меньше, чем если бы мы считали сетку на одном компьютере. Причем, даже при увеличении размера сетки (и узлов кластера) в 40 раз, мы, тем не менее, получаем выигрыш во времени.

Для кластерных вычислительных систем одним из широко применяемых способов построения коммуникационной среды является использование концентраторов (hub) или коммутаторов (switch) для объединения процессорных узлов кластера в единую вычислительную сеть. В этих случаях топология сети кластера представляет собой полный граф, в котором, однако, имеются определенные ограничения на одновременность выполнения коммуникационных операций. Так, при использовании концентраторов передача данных в каждый текущий момент времени может выполняться только между двумя процессорными узлами; коммутаторы могут обеспечивать взаимодействие нескольких непересекающихся пар процессоров.

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

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

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

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