Установка большого Linux-кластера: Часть 2. Конфигурирование управляющего сервера и установка узла

Содержание

Введение

Это вторая из нескольких статей, посвященных установке и настройке большого Linux-кластера компьютеров. Цель данной статьи - собрать в одном месте новейшую информацию из различных общедоступных источников о процессе создания рабочего Linux-кластера из нескольких отдельных частей аппаратного и программного обеспечения. Данные статьи не являются основой для полного проекта нового Linux-кластера. Ссылки на справочные материалы и руководства, описывающие общую архитектуру Linux-кластера, приведены в разделе "Ресурсы".

Данная серия статей предназначена для использования системными разработчиками и системными инженерами при планировании и внедрении Linux-кластера с использованием интегрированной среды IBM eServer Cluster 1350 (ссылки на дополнительную информацию по данной среде приведены в разделе "Ресурсы"). Некоторые статьи могут быть важны для администраторов кластера в качестве учебного материала, а также для использования во время обычного функционирования кластера.

В первой части данной серии приведены подробные инструкции по установке аппаратного обеспечения кластера. Во второй части рассматриваются следующие после конфигурирования оборудования действия: установка программного обеспечения с использованием программы управления системами IBM Cluster Systems Management (CSM) и установка узлов.

Последующие статьи данной серии посвящены серверу системы хранения кластера. В них описывается аппаратная конфигурация и процесс установки и настройки файловой системы IBM с общим доступом, General Parallel File System (GPFS).

Конфигурирование управляющего сервера

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

Установка Linux

Установите новую операционную систему на управляющий сервер. Определите его специфические характеристики. В данном примере используется машина System x 346, которая является типичным управляющим сервером IBM, выполняющим Red Hat Enterprise Linux (RHEL) 3. Однако это мог бы быть и другой тип компьютера с другим дистрибутивом Linux, например, Suse Linux Enterprise Server (SLES). System x 346 является 64-разрядной, поэтому установлена версия RHEL 3 архитектуры x86_64 на двухдисковом зеркальном массиве с использованием карты ServeRAID 7k. Опять же, ваша система может немного отличаться, но принципы установки управляющего сервера CSM должны быть в основном такими же.

Загрузите сервер с CD IBM ServeRAID последней версии для настройки встроенных дисков для RAID 1 (зеркалирование). Это предполагает наличие как минимум двух дисков на сервере и необходимости защиты диска от повреждения для вашей операционной системы.

После настройки дисков на зеркалирование загрузите сервер с первого CD RHEL для установки операционной системы. В зависимости от вашей консоли вам может понадобиться изменить внешний вид программы установки. Например, для консолей с низким разрешением, возможно, придется загрузить CD при помощи выполнения команды linux vga=normal в командной строке загрузки. После появления GUI программы установки Linux выполняйте установку в обычном режиме, следуя следующим инструкциям:

1. Выберите язык, раскладку клавиатуры, тип манипулятора мышь и т.д.
   
   
2. Настройте дисковые разделы следующим образом:
   • 128Mb /boot для первичного раздела.
   • 2 GB для раздела swap.
   • Остальное пространство выделите для раздела LVM без форматирования.
   
   
   
3. Выполните установку логического тома (LVM) следующим образом:
   • Назовите группу томов system.
   • Добавьте логические тома так, как показано в таблице 1.
   
   
   
4. Настройте сетевые интерфейсы следующим образом:
   • Активируйте eth0 на начальную загрузку с фиксированным IP-адресом 192.168.0.253/24, соответствующим нашему примеру файла hosts, рассмотренному ранее.
   • Установите имя хоста в mgmt001.cluster.com.
   • На данном этапе не требуется настройка шлюза/DNS, но если у вас имеется информация о внешних IP, вы можете настроить ее в процессе установки.
   
   
   
5. Отключите брандмауэр, чтобы разрешить все соединения. Опять же, если у вас есть требования для IP-таблиц, вы можете настроить их позже.
   
   
6. Подтвердите ваши локальные настройки и выберите соответствующий часовой пояс.
   
   
7. Установите пароль root; в нашем примере используется пароль cluster.
   
   
8. Настройте установку пакетов и включите следующие:
   • X Window system
   • KDE (то есть, K desktop environment)
   • Graphical internet
   • Server configuration tools
   • FTP server
   • Network servers
   • Legacy software development
   • Administration tools
   
   
   
9. Начните установку.

После завершения установки вы должны пройтись по всем появляющимся экранам. Выполните нужные изменения управляющего сервера для вашей среды. Например, вам, возможно, понадобится настроить X-сервер на комфортную работу согласно вашей настройке KVM (keyboard, video, mouse - клавиатура, видео, мышь).

Установка CSM

Установка программного обеспечения Cluster Systems Management (CSM) обычно является тривиальной задачей на поддерживаемой системе. В справочной библиотеке по IBM Linux Cluster доступна хорошая документация в форматах HTML и PDF (см. раздел "Ресурсы").

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

Для установки CSM установите RPM-пакет csm.core i386. Этот пакет работает также и для архитектуры x86_64. После установки этого пакета вы сможете установить управляющий сервер CSM. Сначала установите сценарий /etc/profile.d/Csm.sh в ваш текущий командный процессор для активизации новой настройки path. Затем выполните команду installms и подтвердите лицензию для CSM. Вот команды, которые вы должны ввести:

rpm -ivh /root/csm/csm.core*.i386.rpm
. /etc/profile.d/Csm.sh
installms -p /root/csm/downloads:/root/csm
csmconfig -L <Your License File>

Примечание: Если у вас нет файла лицензии для CSM, вы можете выполнить эту же команду csmconfig -L без него, тем самым, выбрав 60-дневную пробную лицензию. Впоследствии вы должны приобрести полную CSM-лицензию для продолжения функционирования CSM после истечения 60-дневного периода.

Оптимизация для использования с большим кластером

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

Прослушивание DHCP-запросов на конкретном интерфейсе.

Измените конфигурационный файл /etc/sysconfig/dhcpd DHCPD так, чтобы DHCPDARGS был установлен в соответствующий интерфейс. Переменная DHCPDARGS используется в Red Hat Linux в стартовом сценарии /etc/init.d/dhcpd DHCPD для запуска DHCP-демона с указанными аргументами. Убедитесь в том, что несколько аргументов указаны в кавычках на прослушивание интерфейса eth0, например:

DHCPDARGS="eth0"

Увеличение размера ARP-таблицы и тайм-аутов.

Если у вас имеется одна большая сеть со многими подсетями или весь кластер в одной и той же подсети, ARP-таблица может стать перегруженной, что выразится в замедлении CSM и сетевых запросов. Чтобы этого избежать, выполните следующие изменения в работающей системе, а также добавьте их в качестве записей в файл /etc/sysctl.conf, для того чтобы сделать эти изменения постоянными:

net.ipv4.conf.all.arp_filter = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.neigh.default.gc_thresh1 = 512 net.ipv4.neigh.default.gc_thresh2 = 2048 net.ipv4.neigh.default.gc_thresh3 = 4096 net.ipv4.neigh.default.gc_stale_time = 240

Увеличение количества NFS-демонов.

По умолчанию, стандартное значение CSM fanout (выходное разветвление) равно 16. Это означает, что выполняемые в кластере команды выполняются одновременно на 16 узлах, включая установку узла. Стандартное значение для NFS в Red Hat Linux установлено на восемь работающих демонов. Вы можете улучшить масштабирование NFS, увеличив количество NFS-потоков до 16 в соответствии со значением CSM fanout по умолчанию. Однако, если вы увеличите значение fanout, то, возможно, захотите увеличить количество NFS-потоков. Обычно значения fanout 32 с 32 NFS-потоками достаточно для получения хорошей скорости и надежности, кроме того, оно предоставляет возможность установить параллельно в одной стойке 32 узла. Для этого создайте конфигурационный файл /etc/sysconfig/nfs и добавьте следующую строку:

RPCNFSDCOUNT=16

Настройка NTP-сервера.

Конфигурация NTP-сервера в Red Hat Linux по умолчанию должна работать. Добавьте строку в конфигурационный файл /etc/ntp.conf NTP для разрешения синхронизации своего времени узлами вашего кластера с системными часами управляющего сервера, как показано ниже:

restrict 192.168.0.253 mask 255.255.255.0 notrust nomodify notrap

Если ваш управляющий сервер может обращаться ко внешнему серверу времени, добавьте следующую строку для синхронизации системного времени управляющего сервера с ним:

server server.full.name

Проверьте, что NTP-сервер работает и запускается автоматически во время загрузки, используя следующую команду:

chkconfig ntpd on service ntpd start

Установка узлов

Управляющий сервер CSM установлен и все действия по настройке завершены. Однако перед установкой какого-либо узла вы должны выполнить дополнительную настройку управляющего сервера CSM и определить, как устанавливаются узлы. Выполните инструкции по установке, приведенные в данном разделе.

Определение узлов

Вы можете определить узлы, используя любой метод, описанный на странице руководства definenode. Однако простым способом определения большого количества узлов является использование файла определения узла. При этом создается файл-строфа (stanza) и передается в качестве аргумента в CSM для определения всех перечисленных узлов. Легко запрограммировать сценарий на создание этого файла.

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

  default:
  ConsoleMethod = mrv
  ConsoleSerialDevice = ttyS0
  ConsoleSerialSpeed = 9600
  InstallAdapterName = eth0
  InstallCSMVersion = 1.4.1
  InstallMethod = kickstart
  InstallOSName = Linux
  InstallPkgArchitecture = x86_64
  ManagementServer = mgmt001.cluster.com
  PowerMethod = bmc
node001.cluster.com:
  ConsolePortNum = 1
  ConsoleServerName = term002
  HWControlNodeId = node001
  HWControlPoint = node001_d.cluster.com
  InstallDistributionName = RedHatEL-WS
  InstallDistributionVersion = 4
  InstallServiceLevel = QU1
node002.cluster.com:
  ConsolePortNum = 2
  ConsoleServerName = term002
  HWControlNodeId = node002
  HWControlPoint = node002_d.cluster.com
  InstallDistributionName = RedHatEL-WS
  InstallDistributionVersion = 4
  InstallServiceLevel = QU1
stor001.cluster.com:
  ConsolePortNum = 2
  ConsoleServerName = term001
  HWControlNodeId = stor001
  HWControlPoint = stor001_d.cluster.com
  InstallDistributionName = RedHatEL-AS
  InstallDistributionVersion = 3
  InstallServiceLevel = QU5

Файл определения узла, созданный вами с использованием сценария, может быть значительно длиннее для кластера большого масштаба. Но следующая команда при передаче в CSM быстро создает узлы:

definenode -f <node-def-filename>

Обратите внимание на то, что node-def-filename должен соответствовать имени файла, в котором вы определили узлы, например, definenode -f //tmp/my_nodes.def.

База данных CSM-узлов должна теперь содержать список всех ваших узлов. Для маленького кластера, например, она могла бы содержать 16 вычислительных узлов, пользовательский узел, узел планирования и сервер хранения данных. Управляющий сервер CSM не указывается в базе данных CSM. Список узлов можно просмотреть при помощи команды lsnodes. Для просмотра более подробного списка можно использовать команду lsnode -F, которую можно также использовать для резервного копирования определений ваших CSM-узлов. Перенаправьте выводимую этой командой информацию в файл и тогда сможете переопределить узлы, повторно выполнив команду definenode -f.

Определение групп узлов

CSM позволяет сгруппировать узлы вместе, используя произвольные условия, что впоследствии даст вам возможность использовать другие CSM-команды для работы с конкретной группой узлов. Это может быть особенно полезно для ссылки на определенные типы узлов с похожими атрибутами.

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

Подготовка Linux-дистрибутивов

Управляющий сервер CSM должен иметь содержимое CD всех Linux-дистрибутивов, которые вы будете устанавливать в кластере. Он также должен быть готов к установке CSM на клиентских машинах, что вы и должны сделать перед какими-либо установками. CSM предоставляет две вспомогательные команды, которые должны быть выполнены для каждого Linux-дистрибутива, который вы собираетесь установить.

Для подготовки древовидной структуры /csminstall/Linux с необходимыми CSM-данными выполните команду copycsmpkgs. Например:

copycsmpkgs -p /path/to/csm:/path/to/downloads InstallDistributionName=RedHatEL-WS 
	InstallDistributionVersion=4 InstallServiceLevel=QU1
copycsmpkgs -p /path/to/csm:/path/to/downloads InstallDistributionName=RedHatEL-AS 
	InstallDistributionVersion=3 InstallServiceLevel=QU5

Для подготовки древовидной структуры /csminstall/Linux с необходимыми CD-дисками Linux-дистрибутивов выполните команду copycds. Например:

copycds InstallDistributionName=RedHatEL-WS InstallDistributionVersion=4 
	InstallServiceLevel=QU1
copycds InstallDistributionName=RedHatEL-AS InstallDistributionVersion=3 
	InstallServiceLevel=QU5

После установки структуры каталогов для CD-дисков вы можете добавить любые специализированные пакеты для установки или обновления во время процесса установки системы, например:

• Скопируйте в каталог /csminstall/Linux/.../x86_64/install для гарантии их установки.
• Скопируйте в каталог /csminstall/Linux/.../x86_64/updates для установки только в случае наличия существующей версии.

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

Установка CFM

CSM предоставляет механизм, называемый Configuration File Manager (CFM), который вы можете использовать для распространения файлов в кластере. CFM можно использовать для передачи одинаковых файлов в кластере. Если вы настроили это перед установкой узлов, файлы будут распределены до процесса установки.

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

mkdir /cfmroot/etc
ln -s /etc/hosts /cfmroot/etc/hosts

Вместо связывания файлов вы можете скопировать файлы в CFM. Например:

• Скопировать файл конфигурации NTP по умолчанию в /cfmroot/ntp.conf
• Добавить строку для вашего управляющего сервера, используя следующие команды:

  /cfmroot/etc/ntp echo "management.server.full.name" gt; /cfmroot/etc/ntp/step-tickers

  
  

Этот файл будет распространен по кластеру.

Используйте CFM, если вам нужно передать несколько файлов в конкретное место в кластере. Однако обычно идея перегрузить CFM большим количеством файлов в большом кластере не очень хороша. Например, не используйте CFM для установки дополнительного программного обеспечения из tar-архива. При применении этого способа на большом сервере CFM будет работать очень долго. Устанавливайте программное обеспечение при помощи поддерживаемых механизмов установки. Например, для установки используйте RPM-пакеты вместо tar-файлов и копируйте только конфигурационные файлы (то есть, файлы, которые могут со временем измениться) в CFM.

Настройка компоновки узла

CSM взаимодействует со стандартным механизмом установки по сети операционной системы, которую вы планируете установить на каждом узле. Например, это может быть NIM на AIX®, autoYaST на Suse Linux и kickstart на Red Hat Linux. В качестве примера установки узла используется Red Hat с программой kickstart и файлом конфигурации kickstart.

Перед началом установки kickstart убедитесь, что вы можете управлять питанием на всех узлах при помощи программы rpower. Это помогает CSM получить UUID для каждого компьютера в последних версиях CSM. Если UUID недоступен (либо версия CSM старше 1.4.1.3), CSM пытается получить MAC-адрес от первого Ethernet-устройства узлов. Для функционирования системы сбора MAC-адресов в CSM конфигурация терминального сервера должна соответствовать настройкам BIOS на узлах. Протестируйте соединение терминального сервера при помощи команды rconsole. После проверки возможности управления питанием с использованием rpower и соединения терминального сервера (если нужно), продолжите конфигурирование kickstart.

CSM предоставляет шаблоны по умолчанию для kickstart в файле /opt/csm/install/kscfg.tmpl.*. Вы можете скопировать эти шаблоны в файлы с другим названием и настроить их под ваши требования, если это необходимо. Шаблоны являются хорошей отправной точкой и вам придется настраивать шаблон, а не какой-либо другой стандартный файл kickstart. Причина этого заключается в том, что шаблоны содержат макросы для различных CSM-функций, например, для запуска сценария, выполняемого после установки. CSM делает свой вклад в процесс kickstart, анализируя ваш шаблон перед формированием окончательного файла kickstart для использования на каждом узле. Окончательный файл содержит все проанализированные макросы и включает полные сценарии для всего, что определено в шаблоне.

Обычно вы можете захотеть изменить шаблон следующим образом:

• Изменить схему разбиения диска на разделы, например, для включения LVM
• Изменить пароль по умолчанию
• Изменить список устанавливаемых пакетов

После редактирования kickstart-шаблона запустите команду CSM setup для генерирования окончательного файла kickstart и соберите начальные UUID или MAC-адреса следующим образом:

csmsetupks -n node001 -k /opt/csm/install/your.kickstart.file -x

Примечание: Используйте ключ -x, поскольку команда copycds .skf выполнена ранее.

Обновление драйверов

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

Например, при использовании аппаратного обеспечения System x вы, возможно, захотите получить дополнительную производительность и надежность, обеспечиваемую сетевым драйвером Broadcom для встроенных Ethernet-адаптеров Broadcom. Для этого выполните следующие действия, которые объясняют, как использовать драйвер Broadcom bcm5700 вместо стандартного сетевого драйвера tg3, поставляемого с Red Hat Linux:

1. Поскольку вы компонуете модуль ядра, убедитесь в том, что исходные коды ядра, установленные на целевой системе, соответствуют уровню и типу ядра (UP или SMP).
   
   
2. Загрузите драйвер bcm57xx последней версии с сайта Broadcom (см. раздел "Ресурсы") и разархивируйте исходный код драйвера.
   
   
3. Выполните команду make из каталога src разархивированного вами драйвера bcm для компоновки с рабочим ядром.
   
   
4. Скопируйте скомпонованный драйвер (bcm5700.ko для ядра 2.6 или bcm5700.o для ядер 2.4) в каталог /csminstall/csm/drivers/lt;kernel versiongt;/x86_64 управляющего сервера.
   
   
5. Если вы хотите скомпоновать драйвер с другими версиями ядра, то можете выполнить команду make clean для сброса настроек компоновки и затем выполнить команду make LINUX=/path/to/your/kernel/source.

CSM использует драйверы из структуры каталогов /csminstall/csm/drivers/lt;kernel versiongt;/lt;architecturegt при компоновке образов RAM-диска. Эти образы используются для загрузки системы в процессе установки, если версия ядра соответствует версии ядра RAM-диска. Будьте внимательны при создании драйверов для установочных образов: номера некоторых версий ядра отличаются для установочного ядра. Например, Red Hat обычно добавляет слово BOOT в конец строки версии. Если версия ядра соответствует работающему ядру установленной системы, драйвер делается доступным для этой операционной системы тоже. Если вы не уверены насчет версий ядра, исследуйте образы RAM-диска, как описано в следующем разделе.

Изменение RAM-диска

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

Когда система хранения данных подключена к системе Red Hat Linux напрямую с использованием хост-адаптера шины (host bus adapter - HBA) на машине, на которой производится установка, драйвер системы хранения данных (например, драйверы qlogic qla2300) может загружаться до драйверов ServeRAID (используемых для внутреннего системного диска, то есть, для диска операционной системы). Если это происходит, установка выполняется не на нужном диске. /dev/sda указывает LUN (номер логического устройства) подключенной системы хранения данных, а не локальный диск. В этой ситуации остерегайтесь перезаписи данных на вашем SAN вместо локального диска при установке новой операционной системы. Чтобы этого не допустить, удалите драйверы qlogic с образа RAM-диска Red Hat по умолчанию, которые CSM использует для создания загрузочного образа для установки. Конечно же, эти драйверы вам нужны при работе системы, поэтому используйте другой механизм, например, сценарий, выполняющийся после установки, чтобы установить драйверы для операционной системы. Это рекомендуется делать, поскольку драйверы qlogic, используемые в Red Hat по умолчанию, обычно не являются драйверами с функцией восстановления после сбоя.

Например, удалите драйверы qla2300 из образа RAM-диска по умолчанию для Red Hat Enterprise Linux Advanced Server Version 3. В таблице 4 приведены команды для выполнения этого.

Примечание: Для изменения RAM-диска в Suse или SLES убедитесь в том, что ips (драйвер ServeRAID) указан до любых HBA-драйверов в файле /etc/sysconfig/kernel в строфе INITRD_MODULES. Механизм Suse или SLES для создания образов RAM-дисков гарантирует загрузку драйверов в указанном порядке.

Установка сценариев, выполняющихся до и после перезагрузки

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

1. Скопируйте сценарий конфигурации адаптера, поставляемый с CSM, в каталог исполняемых сценариев installprereboot для разрешения выполнения сценария во время установки и гарантируйте возможность его запуска следующим образом:

   cp /csminstall/csm/scripts/adaptor_config_Linux /csminstall/csm/scripts/ installprereboot/100_adapter_config._LinuxNodes chmod 755 /csminstall/csm/scripts/installprereboot/100_adaptor_config._LinuxNodes

   
   
2. Сгенерируйте файл строфы адаптера /csminstall/csm/scripts/data/Linux_adapter_stanza_file, записав заголовок следующим образом:

   default: machine_type=secondary network_type=eth interface_name=eth1 DEVICE=eth1 STARTMODE=onboot ONBOOT=yes BROADCAST=192.168.1.255 NETMASK=255.255.255.0 MTU=9000

   
   
3. Это настроит все вторичные адаптеры (eth1) на запуск при загрузке и на установку настроек по умолчанию для широковещательного драйвера, маски сети и размера MTU-пакетов. Настройки сети, предназначенные для конкретного компьютера, можно указать в дополнительных строках строфы, аналогично приведенной выше схеме файлов определения узлов:

   for node in $(lsnodes) do ip=$(grep $node /etc/hosts | head -n 1 | awk '{print $1}') echo -e "$node:n IPADDR=$ip" gt;gt; Linux_adaptor_stanza_file done

   
   
4. При этом в файл строфы адаптера добавятся следующие строки для конфигурирования каждого компьютера на различные IP-адреса:

   node001.cluster.com: IPADDR: 192.168.1.1 node002.cluster.com: IPADDR: 192.168.1.2 node003.cluster.com: IPADDR: 192.168.1.3

   
   

Установка

Есть две основные переменные среды командного процессора, применяемые во время установки узла: CSM_FANOUT и CSM_FANOUT_DELAY. Первая переменная управляет количеством узлов, передающих CSM-инструкции одновременно (например, количеством узлов, перезагружаемых с управляющего сервера). Вторая переменная управляет длительностью (в секундах) ожидания CSM перед перезагрузкой следующего набора устанавливаемых узлов. Эти переменные установлены в значение 16 узлов для CSM_FANOUT и на задержку в 20 минут перед перезагрузкой следующего набора узлов. Эти значения по умолчанию приемлемы для большинства установок, но могут быть увеличены для больших кластеров.

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

1. Сконфигурируйте и установите вычислительные узлы следующим образом:

   csmsetupks -N ComputeNodes -k /opt/csm/install/your.kickstart.file.nodes -x installnode -N ComputeNodes

   
   
2. Сконфигурируйте и установите пользовательские узлы следующим образом:

   csmsetupks -N UserNodes -k /opt/csm/install/your.kickstart.file.user -x installnode -N UserNodes

   
   
3. Сконфигурируйте и установите узлы планирования следующим образом:

   csmsetupks -N SchedulerNodes -k /opt/csm/install/your.kickstart.file.schd -x installnode -N SchedulerNodes

   
   
4. Сконфигурируйте и установите узлы хранения данных следующим образом:

   csmsetupks -N StorageNodes -k /opt/csm/install/your.kickstart.file.stor -x installnode -N StorageNodes

   
   

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

1. Установите атрибут InstallServer в CSM. Для каждого узла, который вы хотите установить с установочного сервера, укажите в атрибуте InstallServer имя хоста этого установочного сервера. Все узлы, не имеющие этого атрибута, по умолчанию настроены на установку с центрального управляющего сервера. В больших кластерных системах, где, например, у вас имеется 32 узла на стойку, вы могли бы выбрать нижний узел в каждой стойке в качестве установочного сервера для кластера. В этом случае настройте узлы с node002 по node032 в стойке 1 на установку с узла node001, а узел node001 на установку с управляющего сервера. Используйте следующую команду:

   chnode -n node002-node032 InstallServer=node001

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

   nodegrp -w "InstallServer like '_%'" InstallServers nodegrp -w "InstallServer not like '_%'" InstallClients

   
   
3. Сконфигурируйте и установите установочные серверы следующим образом:

   csmsetupks -N InstallServers -x installnode -N InstallServers

   
   
4. Увеличьте значение CSM fanout для одновременной перезагрузки большего количества узлов, для того чтобы воспользоваться преимуществом повышенной пропускной способности, обеспечиваемым установочными серверами. В примере "32 узла на стойку" наиболее эффективным значением для CSM fanout является произведение 32 на количество установочных серверов (или стоек, если в стойке имеется только один такой узел). В этом примере вы могли бы также увеличить количество NFS-потоков на каждом установочном сервере до 32 для повышения эффективности работы NFS. Используя этот метод, вы можете установить сотни или тысячи машин одновременно.
   
   
5. Сконфигурируйте и установите клиентские узлы следующим образом:

   csmsetupks -N InstallClients -x installnode -N InstallClients

   
   

Заключение

Выполнив все действия, подробно описанные в первых двух частях этой серии статей, вы завершите установку аппаратного и программного обеспечения для кластера, включая установку программы управления системой и полную установку узлов. В следующих частях данной серии будет рассмотрена установка сервера хранения данных; в частности, процесс конфигурирования аппаратного обеспечения системы хранения данных и установка и настройка файловой системы IBM с общим доступом, General Parallel File System (GPFS).

Ресурсы

Научиться

• Оригинал статьи "Installing a large Linux cluster, Part 2: Management server configuration and node installation".
  
  
• Интегрированная среда IBM eServer Cluster 1350: Информация о создании eServer Cluster.
  
  
• Библиотека документации по IBM Linux Cluster: Обращайтесь в библиотеку документации по IBM Linux Cluster.
  
  
• Служба поддержки IBM: Задавайте вопросы в службу поддержки IBM об аппаратном и программном обеспечении и новых версиях.
  
  
• IBM Systems™ : Хотите знать больше? В разделе developerWorks IBM Systems размещено множество информативных статей и учебных руководств начальной, средней и повышенной сложности.
  
  

Получить продукты и технологии

• Драйверы адаптера Broadcom: Загрузите последние версии драйвера Broadcom.
  
  
• IBM: Получите все программное и аппаратное обеспечение, упоминаемое в данной статье.
  
  
• Extreme Networks, Force 10 Networks и Cisco Systems: Посетите эти сайты и узнайте о производительных сетевых коммутаторах.
  
  
• Микропрограмма адаптера Broadcom: Загрузите микропрограмму адаптера Broadcom.
  
  
• Пробное программное обеспечение IBM: Разработайте ваш следующий проект с использованием программного обеспечения, доступного для загрузки непосредственно на сайте developerWorks.
  
  

Об авторах

Мэнди Квортли (Mandie Quartly) работает специалистом по информационным технологиям в группе IBM UK Global Technology Services. Мэнди выполняет разнообразную работу. В настоящее время занимается реализациями платформ Intel и POWER™, а также AIX и Linux (Red Hat и Suse). Она специализируется на продукте IBM General Parallel File System (GPFS). Получила степень доктора философии в University of Leicester в 2001 году.

Грэхем Уайт (Graham White) работает специалистом по системному управлению Linux Integration Centre в отделе Emerging Technology Services офиса IBM Hursley Park в Великобритании. Он имеет сертификат Red Hat Certified Engineer и специализируется на широком спектре технологий с открытым исходным кодом, открытых стандартах и технологиях IBM. В сферу его интересов входят LAMP, Linux, системы защиты, кластеризация и все аппаратные платформы IBM. Получил степень бакалавра по вычислительной технике и управлению с отличием в Exeter University в 2000 году.