Отказоустойчивый кластер linux

Отказоустойчивый кластер для виртуализации

Материал из Xgu.ru

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

Отказоустойчивый кластер — это комбинация из одного или более узлов (серверов) на двух или более общих дисках, которые называются группой ресурсов. Группу ресурсов вместе с ее сетевым именем и IP-адресом, которые составляют кластерное приложение или сервер, называют отказоустойчивым кластером или экземпляром отказоустойчивого кластера. В сети отказоустойчивый кластер представлен как один компьютер, но при этом он обеспечивает переход на другой узел в случае, если текущий узел становится недоступным. Отказоустойчивый кластер в сети выступает в роли обычного приложения или отдельного компьютера, но поддерживает дополнительные возможности, увеличивающие его доступность.

Чтобы создать HA кластер нужно создать отказоустойчивость по нескольким направлениям:

Содержание

[править] Почему Proxmox VE?

• Возможность использования как KVM так и OpenVZ.
• Web vnc-client.
• Возможность кластеризации.
• Неплохая система бэкапов виртуальных машин.

[править] Ключевые возможности Proxmox VE

• Простое управление через веб-интерфейс;
• Мониторинг нагрузки в реальном времени;
• Библиотека установочных образов (в локальном или удаленном хранилище);
• Подключение к «физической» консоли гостевых систем непосредственно из браузера (по VNC);
• Объединение серверов в кластер с возможностью живой миграции виртуальных машин (без остановки гостевой * системы);
• Быстрое развертывание гостевых систем из шаблонов (доступно только для OpenVZ);
• Автоматическое резервное копирование виртуальных машин.

[править] Устанавливаем Debian GNU/Linux amd64 Squeeze

Устанавливаем Debian GNU/Linux amd64 Squeeze. О том как установить лучше обратиться к русскому первоисточнику

[править] Дисковая подсистема

Предлагаю два варианта RAID

[RAID 6] — похож на RAID 5, но имеет более высокую степень надёжности — под контрольные суммы выделяется ёмкость 2-х дисков, рассчитываются 2 суммы по разным алгоритмам. Требует более мощный RAID-контроллер. Обеспечивает работоспособность после одновременного выхода из строя двух дисков — защита от кратного отказа. Для организации массива требуется минимум 4 диска[2]. Обычно использование RAID-6 вызывает примерно 10-15% падение производительности дисковой группы, по сравнению с аналогичными показателями RAID-5, что вызвано большим объёмом обработки для контроллера (необходимость рассчитывать вторую контрольную сумму, а также прочитывать и перезаписывать больше дисковых блоков при записи каждого блока).

[RAID 10] — зеркалированный массив, данные в котором записываются последовательно на несколько дисков, как в RAID 0. Эта архитектура представляет собой массив типа RAID 0, сегментами которого вместо отдельных дисков являются массивы RAID 1. Соответственно, массив этого уровня должен содержать как минимум 4 диска. RAID 10 объединяет в себе высокую отказоустойчивость и производительность. Нынешние контроллеры используют этот режим по умолчанию для RAID 1+0. То есть, один диск основной, второй — зеркало, считывание данных производится с них поочередно. Сейчас можно считать, что RAID 10 и RAID 1+0 — это просто разное название одного и того же метода зеркалирования дисков. Утверждение, что RAID 10 является самым надёжным вариантом для хранения данных, ошибочно, т.к., несмотря на то, что для данного уровня RAID возможно сохранение целостности данных при выходе из строя половины дисков, необратимое разрушение массива происходит при выходе из строя уже двух дисков, если они находятся в одной зеркальной паре.

Устанавливаем Raid 10 по схеме:

[править] Установка Debian на Linux RAID

[править] Установка grub на все жесткие диски

На все диски нужно устанвовить загрузчик. Пример установка на диск sda.

После установки сервера можно проверить скорость чтения и записи.

Кластер виртуализации. Часть 1. Разворачиваем бюджетное отказоустойчивое решение

Архив номеров / 2014 / Выпуск №11 (144) / Кластер виртуализации. Часть 1. Разворачиваем бюджетное отказоустойчивое решение

СЕРГЕЙ УРУШКИН, системный администратор ИТЦ Телрос, urusha.v1.0@gmail.com

Кластер виртуализации. Часть 1
Разворачиваем бюджетное отказоустойчивое решение

Подбор программного и аппаратного обеспечения и первоначальная настройка кластера

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

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

Так как кластер бюджетный, будем обходиться без SAN, Fibre Channel и т.п. Предлагается использовать два сервера (узла), у каждого две сетевые карты. Одна обеспечивает связь узлов и виртуальных машин (ВМ) с внешним миром, вторая – приватная сеть между узлами для обмена данными кластера. Все данные ВМ будут синхронизироваться между узлами в реальном времени, станет возможна живая миграция ВМ с одного узла на другой. При падении одного узла все ВМ, запущенные на нем, автоматически запускаются на другом узле.

Для понимания дальнейшего материала, читателю необходимы следующие навыки:

• знание составных частей и принципов работы аппаратной архитектуры x86 и периферийных устройств;
• понимание семиуровневой модели OSI, принципов построения и маршрутизации сетей TCP/IP, технологии VLAN;
• понимание терминов: виртуальный хост, виртуальная машина, гипервизор, RAID, файловая система (ФС), LVM, пакетный менеджер, кластер;
• умение работать с командной строкой Linux на уровне администратора.

Будет использоваться следующее свободное ПО:

• Гипервизор: KVM. Почему не XEN? Просто опыта работы больше с KVM, а на данный момент важных отличий по функциональности практически нет.
• Менеджер ВМ: libvirt. Обладает богатой функциональностью и широко используется в различных проектах облачного ПО, например, OpenStack.
• Хранение данных: DRBD + DLM + CLVM + GFS2. DRBD – реализация сетевого RAID1 для Linux, обеспечивает синхронизацию данных на узлах. DLM – распределенный менеджер блокировок. CLVM – менеджер томов с поддержкой кластеризации. GFS2 – кластерная ФС. Для максимальной производительности образы ВМ будут храниться как тома LVM. При такой схеме производительность ФС не важна, GFS2 тут вполне подходит. Остальные компоненты практически не имеют альтернатив.
• Менеджер кластера: Corosync + Pacemaker. Это основная связка, используемая в современных дистрибутивах.
• ОС: CentOS 7.0. Изначально схема была развернута на Ubuntu 14.04, но при тестировании отказоустойчивости наблюдались проблемы на связке Corosync + Pacemaker. В итоге был выбран CentOS. Это, по сути, RHEL, а, если судить по багтрекерам, именно в Red Hat кластерное ПО обкатывается особенно активно. К тому же в RHEL периодически интегрируется новая функциональность KVM/libvirt.

За основу были взяты бытовые PC на Intel i7. Кратко по конфигурации:

• Материнская плата – два слота PCIEx16 (или x8). Почему – см. ниже.
• CPU, RAM – по вашим потребностям. Главное – понимать, что, если один узлов выйдет из строя, на оставшемся должно хватить ресурсов, чтобы запустить все ВМ-кластеры.
• Аппаратный RAID с батарейкой (BBU). При использовании DRBD самый простой способ обеспечить высокую скорость и отзывчивость записи при сохранении надежности – BBU. Если скорости бытового HDD для задач достаточно, можно использовать и программное зеркало md-raid. В итоге при построении кластера использовался LSI Nytro 8100-4i + LSI00355 и 4 SATA HDD размером 3 Tб, собранные в RAID-10. SSD-кэш и BBU обеспечат высокую отзывчивость, а HDD – большой объем. Контроллер занимает один слот PCIEx8 (x16 также подойдет).
• Сетевые карты. Нужно как минимум две. Одна для управления и ВМ. В данном случае встроенная в материнскую плату гигабитная карта. У второй сетевой карты задача обеспечить синхронизацию данных между узлами с минимальными накладными расходами по пропускной способности и отзывчивости, т.е. производительность передачи данных не меньшую, чем у дискового массива. Опять же для бытового HDD достаточно гигабитной сетевой карты. Для выбранного RAID был взят 2x10Gbps Intel E10G42BTDA + 2 кабеля XDACBL1M, занимает второй слот PCIEx8 (x16).
• STONITH. В отказоустойчивом кластере при недоступности одного из узлов необходимо обеспечить fencing/STONITH – экстренное выключение сбойного узла. Это обязательная часть кластера. Без этого существует риск потерять данные. Механизмы бывают разные: IPMI, PDU и другие. В данном случае использовался PDU EG-PDU-002 (распределитель питания с удаленным управлением). Этот бюджетный вариант вполне подходит для кластера из двух узлов. Однако, если планируется масштабировать кластер и есть лишние средства, лучше взять PDU посерьезнее, например, APC. Если же в наличии серверное оборудование, можно использовать модули IPMI.
• SWITCH. Сетевой коммутатор/маршрутизатор для соединения узлов и ВМ с миром. По соображениям безопасности следует использовать коммутатор с поддержкой VLAN, хотя в принципе возможен и вариант без отдельных VLAN. В описании используется коммутатор компании Сisco.
• UPS – управляемый источник бесперебойного питания.

Итак, примерная стоимость сервера из приведенных выше компонентов с 32 Гб оперативной памяти – 110 000 руб., PDU – 10 000 руб. ИБП и коммутатор не считаем, т.к. эти компоненты необходимы для использования любого сервера. ПО бесплатное. Итого – 230 000 руб. Это сопоставимо со стоимостью одного брендового сервера аналогичной производительности, но в случае кластера имеется 100% резерв.

Сетевые системы хранения данных (СХД) обеспечивают высокую надежность и производительность, но одна такая система будет стоить не меньших средств. А ведь к СХД нужны еще и отдельные вычислительные узлы. Исходя из этого можно считать реализуемый кластер бюджетным, отказоустойчивым и обеспечивающим производительность ввода-вывода, близкую к производительности локальных дисковых массивов.

Основной минус бытового оборудования – ограниченное количество оперативной памяти. Если ваши нагрузки требуют (или могут вскоре потребовать) большего, чем 32 Гб, объема памяти или других ресурсов, следует смотреть в сторону серверного оборудования. Кластерное ПО будет работать эффективно на любых мощностях.

Статью целиком читайте в журнале «Системный администратор», №11 за 2014 г. на страницах 18-23.

PDF-версию данного номера можно приобрести в нашем магазине.

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Отказоустойчивая кластеризация — общие сведения.

Отказоустойчивая кластеризация — общие сведения.

• Автор: Уваров А.С.
• 03.06.2014

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

Начнем с того, что термин отказоустойчивый не совсем применим к кластерным решениям, он возник в результате неверного перевода термина failover cluster. Правильный перевод — с обработкой отказа, хотя сегодня все чаще употребляется иной термин — высокой доступности (high availability), который, на наш взгляд, наиболее точно отражает суть дел.

Чтобы понять, почему кластер не является отказоустойчивым, разберем более подробно его устройство и схему работы. Сразу уточним, что кластеры применяются не только для обеспечения отказоустойчивости, также кластерные схемы применяют для балансировки нагрузки или наращивания вычислительной мощности. Однако в рамках данного материала мы будем говорить именно о высокодоступных кластерах.

Классическая схема кластера содержит минимум два узла и общее хранилище, связанные между собой несколькими сетевыми соединениями.

Во-первых это служебная сеть кластера для передачи сигнала «пульса» (heartbeat), по которому кластер следит за состоянием своих узлов (на схеме показана красным), сеть хранения данных (SAN, синяя), в недорогих решениях это чаще всего iSCSI через отдельную Ethernet-сеть, но это может быть также и FibreChanell или иные технологии. Для обслуживания клиентов кластер включается в существующую локальную сеть.

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

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

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

Если в качестве хранилища используется iSCSI, то служебную сеть кластера и сеть хранения данных можно объединить. Но при этом у нас остается точка отказа — сеть, поэтому в ответственных системах следует использовать для доступа к SAN не менее двух сетей. Кроме повышения надежности данный подход позволяет повысить пропускную способность, что тоже актуально.

Нельзя не упомянуть и про программные решения, позволяющие создать отказоустойчивый кластер только на двух нодах, используя в качестве SAN виртуальное хранилище. Например, StarWind Virtual SAN, который создает виртуальное iSCSI хранилище на базе локальных дисков каждого из узлов. Это позволяет снизить затраты на создание и размещение отказоустойчивого хранилища, но в тоже время повышает требование к производительности сети между узлами кластера, так как при записи на диск все изменения тут-же синхронизируются между узлами.

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

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

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

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

В наших следующих материалах мы рассмотрим практическую реализацию отказоустойчивого кластера на базе Hyper-V.

Объявление

Отказоустойчивый, высокодоступный Linux кластер для BISquit

Коллеги, интересно мнение: кто и как решал эту задачу? Есть ли у кого отрицательный опыт виртуализации БИСквита?

Отказоустойчивый, высокодоступный Linux кластер для BISquit

Задача не нова, сама по себе, но из-за отсутствия поддержки Progress OpenEdge линуксовых кластеров, решение ее становится совсем не тривиальным. На вебинаре CSBI в мае этого года тема была поднята http://csbi-progress.ru/?p=242 ,но к линуксу OpenEdge Failover Cluster прикрутить в лоб пока не представляется возможным. Изгаления же с самописными скриптами, которые в зависимости от фенсиговых(fencing) событий будут поднимать базу данных, может привести к неординарным событиям — Split-Brain например. А оно нам надо?
Сразу хочу оговориться, что описываемое далее решение не снимает необходимости реплицировать данные на удаленную площадку, но значительно снижает риск необходимости нестись 5-го января в Банк, чтобы поднять внезапно сдохший сервер

Основываясь на более трехлетнем опыте промышленной эксплуатации виртуализированного БИСквита, задача была трансформирована в более простую: обеспечить отказоустойчивость и высокодоступность виртуальной машины с БИСквит. На текущий момент готовых, промышленных решений для виртуальных машин достаточно много и остается только выбрать оптимальное для данной задачи.
В качестве гипервизора выбран KVM, по ряду специфичных для задачи параметров. Теоретически можно использовать XEN в современном исполнении и актуальном ядре линукса. Вариация на тему VMware тоже рассматривалась, но стоимостные характеристики требуемого софта минимум в восемь раз больше чем отработанное решение.

За основу решения выбрана продукция немецкой компании( название убрано чтоб не рекламировать ). Это комплексное решение, базирующееся на кодовой базе Debian GNU/Linux с развитой веб системой управления жизненным циклом виртуальных машин. Кроме, привычных уже функций, как аутентификация через AD и матричного Firewall, система обладает развитыми функциями управления сетью, системой управления высокодоступной кластеризацией, содержит встроенное решение СХД, а также встроенную систему мониторинга и логирования хостов, виртуальных машин и сети.

Почему именно этот софт, а не SUSE , Red Hat или чистый Debian? По причине низкобюджетности и отсутствии необходимости долго и нудно править конфиги Нужно было решение которое от момента инсталляции до ввода в продакшен у системного администратора не отнимала бы более двух часов( в этом случае 30мин).

Короткое описание: Имеем два(или больше) многопроцессорных, многоядерных сервера с большим объемом операционной памяти, с минимум 4-мя 1ГБ/с Ethernet интерфейсами, и SAS дисковыми массивами на каждом сервере. Еще имеем UPS и PDU обеспечивающие контроль и переключения по электропитанию.
Для кластерного интерконекта выделяем по два 1ГБс Ethernet интерфейса и агрегируем. Для несильно нагруженных кластеров в теории должно хватать и 1ГБс, но практика показывает, что на этапе проектирования нужно сразу закладывать 10ГБ/с, а еще лучше 40 ГБ/с- ибо желание или необходимость добавить разных полезных виртуальных машин в кластер не пропорционально пропускной способности интерфейсов.
Архитектура кластерного решения практически один-в-один с SUSE Linux Enterprise High Availability Extension, отличается только удобным веб интерфейсом для конфигурации, управления и мониторинга. Внутренняя система СХД использует Oracle Cluster File System. Встроенная система бэкапирования позволяет восстанавливать как всю виртуальную машину так отдельные файлы. Система мониторинга, кроме мониторинга самих виртуальной машины, может быть дополнена мониторингом OpenEdge. Технология Live Snapshot для работающих виртуальных машин. Скорость переключения между нодами, в случае аварии, позволяет не терять ssh сессию.

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

Отказоустойчивый кластер linux

Юрий Сбитнев

Родился в 1965 г. в Волгограде.

Образование высшее: Волгоградский государственный университет, физический факультет, специальность — теоретическая физика.

С 1987 по 1997 г. — системный программист ВЦ ВолГУ, старший преподаватель кафедры радиофизики физического факультета ВолГУ.

В настоящее время руководитель Службы Информационно-Технического Обеспечения ОАО «Ювелиры Урала», Корпорация ЯВА, Екатеринбург.

Ubuntu кластер

*** ЧТО ТАКОЕ UBUNTU?

Ubuntu — это разрабатываемая сообществом, основанная на ядре Linux операционная система, которая идеально подходит для использования на персональных компьютерах, ноутбуках и серверах. Она содержит все необходимые программы, которые вам нужны: программу просмотра Интернет, офисный пакет для работы с текстами, электронными таблицами и презентациями, программы для общения в Интернет и много других.

Дистрибутивы семейства Ubuntu являются комплектом специально подобранного ПО. Это операционная система плюс множество нужных и полезных программ, которые свободно и без ограничений могут быть использованы вами и вашими друзьями и коллегами. Базовая полнофункциональная версия системы для персональных компьютеров и ноутбуков или версия для серверов занимают всего 1 CD, поэтому вы легко можете получить её для себя и делиться с окружающими. Специальные DVD версии дистрибутива включают практически всё ПО, которое вам может понадобиться для решения любых повседневных задач.

Для установки линукс-кластера на основе дистрибутива Ubuntu вам потребуется установочный диск Ubuntu Desktop Edition, с помощью которого вы установить операционную систему на консоль (главный компьютер) кластера. С того же самого диска нужно будет установить операционную систему на вычислительные узлы кластера. Однако, если вычислительные узлы не предполагается использовать в качестве офисных машин, но только как узлы кластера, то на эти компьютеры правильнее будет установить серверную редакцию дистрибутива — Ubuntu Server Edition, не содержащую графического интерфейса, и соответственно более легкую и быструю.

Сеть кластера следует спроектировать так, чтобы все узлы имели доступ в интернет. Это нужно для большего комфорта при настройке кластера и установки необходимого программного обеспечения на его узлах. Дело в том, что установка ПО в Ubuntu выполняется посредством закачки новейших версий необходимых пакетов из внешних репозиториев. В действительности достаточно будет обеспечить выходом в Интернет только главный компьютер (консоль кластера), а для вычислительных узлов необходима только возможность загружать программные пакеты через прокси. Осуществить это можно, установив на консоли кластера пакет apt-cacher-ng, а на вычислительных узлах сконфигурировать менеджер пакетов apt-get для работы через прокси. Для этого на консоли кластера выполним команду:

sudo apt-get install apt-cacher-ng

После этого на всех остальных узлах выполним команды:

sudo sh -c «echo «Acquire::http < Proxy \"http://192.168.1.1:3142\"; >; «> /etc/apt/apt.conf.d/01proxy»
sudo apt-get update

Здесь мы предполагаем, что адрес 192.168.1.1 — это адрес консоли кластера во внутренней сети кластера.

После установки базовой операционной системы необходимо доустановить необходимое для функциониования кластера по: компиляторы, библиотеки и программы OpenMPI, SSH, NFS. Выполнить это можно с помощью следующих команд:

sudo apt-get install mc build-essential fort77 gfortran libstdc++5 libltdl7-dev
sudo apt-get install openssh-server nfs-kernel-server
sudo apt-get install openmpi-bin openmpi-doc

Данная последовательность команд устанавливает в систему OpenMPI и компиляторы из набора Gnu Compiller Collection (gcc). Компиляторы gcc обладают одним существенным (в некоторых случаях) недостатком. В них нет поддержки работы с типами данных REAL*16 и COMPLEX*32 (в терминологии Фортрана). Если для ваших задач необходима такая точность вычислений, то вы вместо стандартного набора компиляторов и пакета OpenMPI из состава дистрибутива должны будете установить компиляторы фирмы Intel и скомпилировать OpenMPI с поддержкой этих компиляторов. Как это сделать — рассказано в следующих двух параграфах этой статьи. Если же точность REAL*8 и COMPLEX*16 вас устраивает, то следующие два параграфа вы можете пропустить.

ВАЖНО! Если вы решили использовать компиляторы фирмы Intel, то не следует устанавливать OpenMPI из состава дистрибутива. То есть команду sudo apt-get install openmpi-bin openmpi-doc (см. выше) выполнять не следует.

*** УСТАНОВКА КОМПИЛЯТОРА INTEL FORTRAN

Скачать свежую версию компилятора можно с официального сайта компании Intel, с этой страницы. Получив и разархивировав в своем домашнем каталоге архив с компилятором, выполним процедуру установки, запустив скрипт install.sh, который находится в каталоге, получившимся после разархивации. При запуске скрипт спросит вас о том, в каком варианте произвести установку компилятора. Нужно выбрать вариант N3 — установку в пользовательский каталог. Для ответа на все дальнейшие вопросы программы следует выбирать вариант, предложенный программой по умолчанию.

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

echo «. $HOME/intel/Compiler/11.1/046/bin/ifortvars.sh ia32″ >> $HOME/.bashrc

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

*** УСТАНОВКА OpenMPI ДЛЯ КОМПИЛЯТОРА INTEL

К сожалению пакет OpenMPI, имеющийся в дистрибутиве Ubuntu, не знает о существовании компилятора Intel. Поэтому его придется установить из исходников, которые можно загрузить с официального сайта проекта OpenMPI. Разархивировав загруженный файл, перейдем в полученный в результате этого каталог исходников и выполним процедуру установки, последовательно запустив на исполнение следующие команды:

./configure —prefix=$HOME/openmpi F77=ifort FC=ifort
make
make install

В случае, если вы намереваетесь использовать и установили кроме компилятора Intel Fortran, так же и Intel С++, то команда конфигурации должна будет выглядеть так:

./configure —prefix=$HOME/openmpi CC=icc CXX=icpc F77=ifort FC=ifort

По окончании процесса установки, как и в случае с компилятором, необходимо поправить некоторые переменные окружения. Делаем это с помощью следующих команд модифицируем файл .bashrc:

echo «PATH=$HOME/openmpi/bin:$PATH» >> $HOME/.bashrc
echo «export PATH» >> $HOME/.bashrc
echo «LD_LIBRARY_PATH=$HOME/openmpi/lib:$LD_LIBRARY_PATH» >> $HOME/.bashrc
echo «export LD_LIBRARY_PATH» >> $HOME/.bashrc

По окончании процедуры необходимо переподключиться в систему (перелогиниться).

*** НАСТРОЙКА СЕТИ КЛАСТЕРА

Для того, чтобы MPI имела возможность без дополнительных запросов запускать части параллельной прогаммы на вычислительных узлах кластера, вы должны будете организовать беспарольный доступ по протоколу SSH с консоли кластера на все вычислительные узлы. Как это сделать — читайте соответствующий раздел этого сайта.

Следующим нашим шагом будет организация общего для всех узлов кластера каталога, где будут храниться исходники параллельных программ, их исполняемые модули и файлы с данными. Сделать это можно, настроив сетевую файловую систему NFS. Для простоты общий каталог сделаем подкаталгом домашне директории пользователя. Назовем его к прмеру «mpi».

Предположим, что узлы кластера имеют адреса внутри сети 192.168.1.0/255.255.255.0, и консоль кластера имеет адрес 192.168.1.1.

На консоли кластера, выполнив следующую команду, добавляем строчку в файл /etc/exports для создания сетевого ресурса:

sudo sh -c «echo «$HOME/mpi 192.168.1.0/24(rw,insecure,nohide,all_squash,anonuid=1000,anongid=1000,no_subtree_check)» >> /etc/exports»

После этого необходимо перезапустить сервис NFS:

sudo /etc/init.d/nfs-kernel-server restart

На всех остальных узлах кластера мы должны будем поправить файл /etc/fstab, добавив туда запись для автоматического монтирования сетевого ресурса. Делается это командой:

sudo sh -c «echo «192.168.1.1:$HOME/mpi $HOME/mpi nfs rsize=8192,wsize=8192,rw,auto,exec 0 0″ >> /etc/fstab»

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

Если вы решили использовать компилятор Intel Fortran/Intel C++ и, соответственно, на консоли кластера установили этот компилятор и OpenMPI, скомпиленный из исходников, то то же самое вы должны сделать на всех вычислительных узлах. Однако последнее — не обязательно. Вместо этого вы можете подключить по сети (через NFS) каталоги с установленными компилятором и OpenMPI (openmpi и intel) аналогично тому, как вы только что это сделали подключая рабочий каталог mpi. В дополнение к этому вам необходимо подкорректировать на всех вычислительных узлах кластера файл /etc/environment следующими командами:

sudo sed -i -e ‘s;PATH=»;PATH=»‘»$HOME»‘/openmpi/bin:'»$HOME»‘/intel/Compiler/11.1/046/bin/ia32:;’ /etc/environment
sudo sh -c «echo «LD_LIBRARY_PATH=\»$HOME/openmpi/lib:$HOME/intel/Compiler/11.1/046/lib/ia32:$HOME/intel/Compiler/11.1/046/lib/32\»» >> /etc/environment»

*** НАСТРОЙКА ПАРАЛЛЕЛЬНОЙ СРЕДЫ

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

*** КОМПИЛЯЦИЯ ПАРАЛЛЕЛЬНОЙ ПРОГРАММЫ

Для примера и для проверки работоспособности кластера скачаем в каталог mpi тестовую программу вычисления числа flops.f. Для компиляции необходимо выполнить следующую простую команду:

mpif77 flops.f -o flops

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

*** ЗАПУСК ПАРАЛЛЕЛЬНОЙ ПРОГРАММЫ

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

mpiexec -hostfile mpi.hosts -np 5 ./flops

Параметр -np 5 означает, что программа будет запущена на пяти узлах кластера. Отработав, программа выдаст на экран информацию о скоростных характеристаках кластера в целом и отдельных его узлов.

В случае, если ваша параллельная программа состоит из отдельных программных модулей, то имеется возможность запускать из вместе, как единый комплекс. Предположим, что ваша программа состоит из двух модулей — visio и calc. Модуль calc — это собственно параллельная программа, которая в многопроцессороном режиме обрабатывает большой массив данных, и которая занимает 5 процессоров кластера. Модуль visio — программа визуализации полученных данных. Программа visio должна работать на одном процессоре. Запуск такой комплексной программы будет выглядеть так: