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

Начало работы по установке большого Linux-кластера

Создайте работающий Linux-кластер. В этой (второй) части серии статей описывается конфигурирование управляющего сервера и процедура установки узлов в кластере.

Мэнди Квортли (Mandie Quartly), специалист по информационным технологиям, IBM

Мэнди Квортли фотоМэнди Квортли (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), специалист по системному управлению, IBM

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



21.02.2007

Введение

Это вторая из нескольких статей, посвященных установке и настройке большого 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. Начните установку.
Таблица 1. Схема логических томов
Логический томТочка монтированияРазмер
Root/8192 MB
Var/var8192 MB
Usr/usr8192 MB
Opt/opt4096 MB
Tmp/tmp2048 MB
Csminstall/csminstall10240 MB

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

Установка CSM

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

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

Таблица 2. Программное обеспечение CSM
КаталогОписание
/root/manuals/csm/Документация по CSM в формате PDF
/root/manuals/gpfs/Документация по GPFS в формате PDF
/root/manuals/rsct/Документация по RSCT в формате PDF
/root/csm/Программное обеспечение CSM (содержимое tar-архива CSM)
/root/csm/downloads/Загруженные RPMS-пакеты для CSM (например, autorpm)

Для установки 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. После нее каждая строфа должна представлять имя узла с перечисленными в ней специфичными для узла атрибутами. В примере показано, как определить три машины в кластере - два вычислительных узла и один сервер хранения данных.

Листинг 1. Пример файла определения узла
  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 показаны некоторые примеры определений динамических групп узлов.

Таблица 3: Динамические группы узлов
Команда определенияКомментарий
Nodegrp -w "Hostname like 'node%'" ComputeNodesСоздать группу узлов ComputeNodes
Nodegrp -w "Hostname like 'schd%'" SchedulerNodesСоздать группу узлов SchedulerNodes
Nodegrp -w "Hostname like 'stor%'" StorageNodesСоздать группу узлов StorageNodes
Nodegrp -w "Hostname like 'user%'" UserNodesСоздать группу узлов UserNodes
Nodegrp -w "Hostname like 'node%' && ConsoleServerName=='term002'" Rack02 nodegrp -w "Hostname like 'node%' && ConsoleServerName=='term003'" Rack03 nodegrp -w "Hostname like 'node%' && ConsoleServerName=='term...'" Rack... Создать группу узлов для каждой стойки на основе Hostname и ConsoleServerName. Присвоить один консольный сервер для каждой стойки autorpm)

Подготовка 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 приведены команды для выполнения этого.

Таблица 4: Команды для RAM-диска
КомандаНазначение
cd /csminstall/Linux/RedHatEL-AS/3/x86_64/RedHatEL-AS3-QU5/images/pxeboot Перейти в каталог, содержащий образ RAM-диска, который вы хотите изменить.
cp initrd.img initrd.img.orig Выполнить резервное копирование оригинального образа.
mkdir mnt Создать точку монтирования.
gunzip -S .img initrd.img Разархивировать образ.
mount -o loop initrd.img /mnt Смонтировать образ к точке монтирования.
manual stepВручную удалить все ссылки на qla[23]00 в mnt/modules/*.
cp mnt/modules/modules.cgz Скопировать архив модулей из образа в текущий каталог.
gunzip -c modules.cgz | cpio -ivd Разархивировать архив модулей.
rm modules.cgz Удалить архив модулей.
rm 2.4.21-32.EL/ia32e/qla2*Удалить модули qlogic из распакованного архива модулей.
find 2.4.21-32.EL -type f | cpio -–o -H crc | gzip -c -9 > modules.cgz Создать архив модулей с удаленными модулями qlogic.
rm -rf 2.4.21-32.EL Удалить распакованный архив модулей.
mv -f modules.cgz mnt/modules Заменить старый архив модулей новым.
umount mnt Демонтировать образ RAM-диска.
rmdir mnt Удалить точку монтирования.
gzip -S .img initrd Снова создать образ RAM-диска.

Примечание: Для изменения 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).

Ресурсы

Научиться

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

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux
ArticleID=197072
ArticleTitle=Установка большого Linux-кластера: Часть 2. Конфигурирование управляющего сервера и установка узла
publish-date=02212007