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

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

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

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

В данном разделе детализируются специфические вопросы управления сервером кластера (cluster server management - CSM), связанные с системой хранения данных примера кластера. К ним относятся установка GPFS-кода на каждом узле и настройка адаптеров Qlogic для узлов системы хранения. Обращаем внимание на то, что эта настройка не обязательно должна выполняться с использованием CSM; ее можно сделать и вручную. В примере данной статьи используется CSM для практически полной автоматизации установки нового сервера, в том числе и сервера хранения данных.

Обзор архитектуры

Перед прочтением данного раздела полезно повторить материал раздела "Общая архитектура кластера" из первой статьи данной серии. Также полезно просмотреть раздел по архитектуре системы хранения данных в третьей статье. Понимание архитектуры обеспечит необходимый контекст для наилучшего использования приведенной ниже информации.

Установка узлов системы хранения данных в правильном порядке

Установка в нужном порядке является обязательным условием для устранения проблемы переполнения ROM, описанной позже, поскольку используемые в данной конфигурации системы xSeries™ 346 не имеют карт RAID 7K. Выполните следующие действия в указанном порядке:

1. Выполните команду csmsetupks -vxn <nodename> на управляющем сервере.
   
   
2. Отключите сервер системы хранения данных от SAN, для того чтобы избежать установки операционной системы на SAN-дисках, которые обнаруживаются первыми.
   
   
3. Выполните команду installnode -vn <nodename> на управляющем сервере.
   
   
4. Нажмите F1 в консоли после перезагрузки узла системы хранения данных для входа в BIOS.
   
   
5. Перейдите в раздел Start Options и измените PXEboot с disabled на enabled for planar ethernet 1.
   
   
6. Перезагрузите узел; начнется установка.
   
   
7. Следите за установкой через терминальный сервер; пусть узел полностью завершит начальную загрузку.
   
   
8. Зарегистрируйтесь на узле и просмотрите log-файл установки csm log /var/log/csm/install.log.
   
   
9. Перезагрузите узел после завершения задания post reboot.
   
   
10. Нажмите клавишу F1 на консоли после перезагрузки узла для входа в BIOS.
    
    
11. Перейдите в раздел Start Options и измените PXEboot на disabled.
    
    
12. Подключите SAN-кабели и подождите завершения начальной загрузки узла.
    
    
13. Настройте пути к диску при помощи MSJ, как описано в разделе "Настройка путей к дискам и распределения нагрузки".

Организация беспарольного доступа к учетной записи root между узлами

GPFS требует, чтобы все узлы в GPFS-кластере были способны обращаться друг к другу, используя root ID без предоставления пароля. GPFS использует этот межузловой доступ, чтобы разрешить любому узлу в GPFS-кластере выполнять соответствующую команду на других узлах. В приведенном в этой статье примере для предоставления доступа используется ssh (secure shell), однако можно использовать также rsh (remote shell). Для этого создайте ключ, относящийся ко всему кластеру, и соответствующие конфигурационные файлы, которые распределите при помощи CSM, выполнив следующие действия:

1. Создайте два новых каталога в /cfmroot/root/.ssh и /cfmroot/etc/ssh.
   
   
2. Создайте пару RSA-ключей, открытый и закрытый ключи для аутентификации, выполнив команду

   ssh-keygen -b 1024 -t rsa -f /cfmroot/etc/ssh/ssh_host_rsa_key -N "" -C "RSA_Key"

   
   
3. Создайте пару DSA-ключей, открытый и закрытый ключи для аутентификации, выполнив команду

   ssh-keygen -b 1024 -t dsa -f /cfmroot/etc/ssh/ssh_host_dsa_key -N "" -C "DSA_Key"

   
   
4. Создайте файл авторизации, содержащий открытые ключи, как показано ниже. Это файл, который SSH использует для определения необходимости запроса пароля.

   cat /root/.ssh/id_rsa.pub > /cfmroot/root/.ssh/authorized_keys2 cat /root/.ssh/id_dsa.pub >> /cfmroot/root/.ssh/authorized_keys2 cat /cfmroot/etc/ssh/ssh_host_rsa_key.pub >> /cfmroot/root/.ssh/authorized_keys2 cat /cfmroot/etc/ssh/ssh_host_dsa_key.pub >> /cfmroot/root/.ssh/authorized_keys2

   
   
5. Отключите поддержку CSM файла known_hosts, как показано ниже. Этот файл содержит имена хостов. Если имя хоста имеется в файле, SSH не запрашивает у пользователя подтверждения подключения. CSM пытается поддерживать данный файл, но в стационарной среде кластера с беспарольным root-доступом это может быть помехой.

   stopcondresp NodeFullInstallComplete SetupSSHAndRunCFM startcondresp NodeFullInstallComplete RunCFMToNode perl -pe 's!(.*update_known_hosts.*)!#$1!' -i /opt/csm/csmbin/RunCFMToNode

   
   
6. Сгенерируйте файл known_hosts для системы. Лучше всего сделать это путем создания сценария, как показано ниже. Выполните сценарий и направьте вывод информации в /cfmroot/root/.ssh/known_hosts.

   #!/bin/bash RSA_PUB=$(cat "/cfmroot/etc/ssh/ssh_host_rsa_key.pub") DSA_PUB=$(cat "/cfmroot/etc/ssh/ssh_host_dsa_key.pub") for node in $(lsnodes); do ip=$(grep $node /etc/hosts | head -n 1 | awk '{print $1}') short=$(grep $node /etc/hosts | head -n 1 | awk '{print $3}') echo $ip,$node,$short $RSA_PUB echo $ip,$node,$short $DSA_PUB done

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

   cd /cfmroot/root/.ssh ln -s ../../etc/ssh/ssh_host_dsa_key id_dsa ln -s ../../etc/ssh/ssh_host_dsa_key.pub id_dsa.pub ln -s ../../etc/ssh/ssh_host_rsa_key id_rsa ln -s ../../etc/ssh/ssh_host_rsa_key.pub id_rsa.pub

   
   
8. Убедитесь, что данная конфигурация устанавливается на каждую систему, перед первой перезагрузкой операционной системы. CSM не гарантирует порядок действий после установки, поэтому, если какое-либо задание зависит от наличия данной конфигурации, оно может не выполниться. Оно может также выполниться успешно, но выдать ошибку несовместимости. Например, в случае, если у вас есть послеустановочный сценарий, и вам необходимо добавить узел к GPFS-кластеру и смонтировать все файловые системы GPFS. Одним из способов избежать такого поведения могло бы быть создание tar-архива всех созданных здесь файлов и их разархивирование при помощи сценария CSM, выполняющегося после установки до перезагрузки.

Определение относящихся к GPFS CSM-групп

Для данного примера определяются две главных CSM-группы, использующиеся во время настройки GPFS, как показано ниже.

• StorageNodes, включающая только те узлы, которые подключаются напрямую к SAN, например, nodegrp -w "Hostname like 'stor%'" StorageNodes.
  
  
• NonStorageNodes, включающая только те узлы, которые являются частью GPFS-кластера, например, nodegrp -w "Hostname not like 'stor%'" NonStorageNodes.

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

Обобщенно процесс установки проходит следующие этапы:

1. PXE-загрузка/DHCP с сервера установки.
2. Установка NFS с сервера установки.
3. Сценарии, выполняющиеся до перезагрузки (pre-reboot).
4. Перезагрузка.
5. Сценарии, выполняющиеся после перезагрузки (post-reboot).
6. Передача CFM-файла.
7. Послеустановочная настройка CSM.

Изменения конфигурации в данной статье происходят на этапах pre-reboot и передачи CFM-файла.

Установка RPM-файлов GPFS

GPFS требует наличия на каждом члене кластера базового набора установленных RPM-файлов GPFS. В примере использовалась GPFS версии 2.3.0-3. Установка этих RPM представляет собой процесс из двух этапов: установка базовой версии 2.3.0-1 и последующее обновление до 2.3.0-3. Для данной установки использовались следующие RPM-файлы:

• gpfs.base
• gpfs.docs
• gpfs.gpl
• gpfs.msg.en_US

Примечание: Поскольку пример использует GPFS Version 2.3, установка Reliable Scalable Cluster Technology (RSCT) и создание домена одноранговой сети (peer) не требуется. Версии GPFS до Version 2.3 требовали выполнения этих действий вручную.

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

Одним из альтернативных методов является написание сценариев для CSM (выполняющихся до перезагрузки и после установки), чтобы установить необходимые RPM-файлы. В данном случае скопируйте все RPM-файлы GPFS, включая RPM-файлы обновления, в каталог /csminstall/Linux управляющего сервера. CSM обычно резервирует каталог для данных сценариев /csminstall/csm/scripts/data, который будет монтироваться к узлу во время установки, делая необходимые RPM-файлы доступными через NFS.

Напишите сценарий /csminstall/csm/scripts/installprereboot/install-gpfs.sh для установки GPFS. Вот пример такого сценария:

#! /bin/bash
# Устанавливает набор файлов GPFS и обновляет до последних версий
# Переменная среды CSMMOUNTPOINT устанавливается CSM
DATA_DIR=$CSMMOUNTPOINT/csm/scripts/data
cd $DATA_DIR
rpm -ivh gpfs.*2.3.0-1*.rpm
rpm -Uvh gpfs.*2.3.0-3*.rpm
echo 'export PATH=$PATH:/usr/lpp/mmfs/bin' > /etc/profile.d/gpfs.sh

После установки GPFS на сервере хранения данных вы, возможно, также захотите автоматически установить программу FAStT MSJ, что можно сделать в невидимом (не интерактивном) режиме. MSJ используется для настройки адаптеров Qlogic, системы восстановления после сбоев и нескольких каналов передачи, что подробно описывается в разделе по настройке HBA. Установка не основывается на RPM-файлах, поэтому нелегко интегрировать ее в CSM по умолчанию. Для выполнения установки вы можете добавить сценарий в конец установки GPFS для проверки того, является ли узел сервером хранения данных, а также для установки MSJ. Для установки в невидимом режиме используйте команду FAStTMSJ*_install.bin -i silent

Настройка системы восстановления после сбоев Qlogic

Пример кластера использует драйвер Qlogic qla2300 версии 7.01.01 для адаптеров Qlogic QLA 2342. Каждый из узлов в группе узлов системы хранения данных имеет два таких PCI-адаптера. Драйвер qla2300 поставляется стандартно с дистрибутивом Red Hat Enterprise Linux 3 update 4. Однако вы должны выполнить следующие изменения для примера кластера:

• Измените драйвер qla2300 на выполнение восстановления после сбоев. Это позволит вам воспользоваться другим путем к диску и восстановить работоспособность после возникновения сбоя в предпочтительном пути. По умолчанию эта функция отключена.

  Первое изменение выполните с использованием сценария, выполняющегося CSM перед перезагрузкой во время установки. Выполняющий это действие сценарий находится в каталоге /csminstall/csm/scripts/installprereboot/. Этот сценарий содержит следующие команды:

  #! /bin/bash # Добавляет строки в /etc/modules.conf для разрешения системы # восстановления после сбоев для драйверов qla2300 echo "options qla2300 ql2xfailover=1 ql2xmaxsectors=512 ql2xmaxsgs=128" >> /etc/modules.conf echo "Updating initrd with new modules.conf set up" mkinitrd -f /boot/initrd-`uname -r`.img `uname -r`

  
  
• Установите предпочтительный путь к дискам на каждом хосте соответствующим установленному в каждом контроллере DS4500. Используйте массивы с нечетными номерами, видимые через HBA0, и массивы с четными номерами, видимые через HBA1.

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

Тонкая настройка GPFS-сети

Пример предлагает добавить несколько строк в файл /etc/sysctl.conf на каждом узле для тонкой настройки GPFS-сети. Это выполняется с использованием установочного сценария CSM, выполняющегося после перезагрузки. Сценарий расположен в каталоге /csminstall/csm/scripts/installpostreboot и содержит следующие строки:

FILE=/etc/sysctl.conf

# Добавляет строки в /etc/sysctl.conf для тонкой настройки GPFS-сети
echo "# CSM added the next 8 lines to the post installation script for 
 GPFS network tuning" >> $FILE
echo "# increase Linux TCP buffer limits" >> $FILE
echo "net.core.rmem_max = 8388608" >> $FILE
echo "net.core.wmem_max = 8388608" >> $FILE
echo "# increase default and maximum Linux TCP buffer sizes" >> $FILE
echo "net.ipv4.tcp_rmem = 4096 262144 8388608" >> $FILE
echo "net.ipv4.tcp_wmem = 4096 262144 8388608" >> $FILE
echo "# increase max backlog to avoid dropped packets" >> $FILE
echo "net.core.netdev_max_backlog=2500" >> $FILE

# Следующие строки не относятся к настройке GPFS 
echo "# Allow Alt-SysRq" >> $FILE
echo "kernel.sysrq = 1" >> $FILE
echo "# Increase ARP cache size" >> $FILE
echo "net.ipv4.neigh.default.gc_thresh1 = 512" >> $FILE
echo "net.ipv4.neigh.default.gc_thresh2 = 2048" >> $FILE
echo "net.ipv4.neigh.default.gc_thresh3 = 4096" >> $FILE
echo "net.ipv4.neigh.default.gc_stale_time = 240" >> $FILE

# Сброс текущих параметров ядра 
sysctl -p /etc/sysctl.conf
 

Распределение уровня переносимости GPFS

Уровень переносимости (portability layer - PL) GPFS является зависимым от ядра и должен быть создан отдельно для каждой версии операционной системы вашего кластера. Назначение PL и подробная информация по созданию для примера кластера описаны в разделе "Создание и установка уровня переносимости". Скопируйте бинарные файлы PL в каталог /cfmroot/usr/lpp/mmfs/bin управляющих серверов и назовите их так, чтобы они распределялись только на узлы с определенными версиями ядра в соответствующих группах. Например:

/cfmroot/usr/lpp/mmfs/bin/dumpconv._<nodegroup>
/cfmroot/usr/lpp/mmfs/bin/lxtrace._<nodegroup>
/cfmroot/usr/lpp/mmfs/bin/mmfslinux._<nodegroup>
/cfmroot/usr/lpp/mmfs/bin/tracedev._<nodegroup>

Обратите внимание на то, что в большом кластере для уменьшения нагрузки на CFM можно добавить эти четыре файла в специализированный RPM и установить вместе с GPFS, используя метод, приведенный выше для установки RPM-файлов GPFS.

Автоматизация добавления новых узлов в GPFS-кластер

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

В листинге 1 показан пример сценария, который может быть использован для настройки GPFS. Вам, возможно, понадобится несколько изменить его для вашей конфигурации. В листинге предоставлена основа. Сценарий принимает имя узла (переданное CSM-мониторами), добавляет его в GPFS-кластер и пытается запустить GPFS на этом узле с некоторой тривиальной обработкой ошибок.

 
#!/bin/bash

# Сценарий CSM условие/ответ, используемый в качестве ответа на условие 
# InstallComplete. Он будет пытаться добавить узел в GPFS-кластер, обрабатывая
# попутно некоторые обычные ошибочные ситуации.
# Выполняются только тривиальные действия; более сложные проблемы должны
# решаться вручную.

# Примечание: требуется файл GPFS gpfs-nodes.list. Этот файл должен содержать список
# всех узлов в GPFS-кластере с подробной информацией клиент/менеджер и 
# кворум/отсутствие кворума, подходящей для передачи в команду mmcrcluster.

# Выводимая информация направляется в /var/log/csm/

# Возвращаемые коды ошибок:
# 1 - GPFS уже активен
# 2 - нельзя прочитать файл gpfs-nodes.list 
# 3 - отсутствует имя узла в файле gpfs-nodes.list 
# 4 - узел является узлом кворума
# 5 - нельзя добавить узел в кластер (mmaddnode выполнилась неудачно)
# 6 - нельзя запустить GPFS на узле (mmstartup выполнилась неудачно)

# укажите месторасположение вашего файла со списком узлов
gpfs_node_list=/etc/gpfs-nodes.list
# укажите интерфейс GPFS, используемый для взаимодействия
gpfs_interface=eth1

PATH=$PATH:/usr/lpp/mmfs/bin # ensure GPFS binaries are in the PATH
log_file=/var/log/csm/`basename $0`.log # log to /var/log/csm/
touch $log_file

# Получить краткое имя узла, установленное RSCT-условием ENV var ERRM_RSRC_NAME
node=`echo $ERRM_RSRC_NAME | cut -d. -f1`

(

[ ! -r "$gpfs_node_list" ] && echo " ** error: cannot read GPFS 
node list $gpfs_node_list" && exit 2

echo
echo "--- Starting run of `basename $0` for $node at `date`"

# Является ли узел узлом кворума? Если да, выйти.
quorum_status=`grep $node $gpfs_node_list | cut -d: -f2 | cut -d- -f2`
if [ -n "$quorum_status" ]; then
 if [ "$quorum_status" = "quorum" ]; then
 echo "** error: this is a quorum node, stopping..."
 exit 4
 else
 node_s=`grep $node $gpfs_node_list | cut -d: -f1`
 fi
else
 echo "** error: could not find node $node in GPFS node list $gpfs_node_list"
 exit 3
fi

# Определить, является ли уже узел частью кластера
if mmlscluster | grep $node >/dev/null; then

 # проверить состояние узла
 status=`mmgetstate -w $node | grep $node | awk '{print $3}'`
 if [ "$status" = "active" ]; then
 echo "** error: this node already appears to have GPFS active!"
 exit 1
 fi

 # попытаться удалить узел из кластера
 echo "Node $node is already defined to cluster, removing it"

 # попытаться запретить интерфейс системы хранения данных на узле
 if ssh $node $ifdown $gpfs_interface; then
 mmdelnode $node
 ssh $node ifup $gpfs_interface
 else
 echo "** error: could not ssh to $node, or ifdown $gpfs_interface failed"
 fi
fi

# попытаться добавить узел в GPFS-кластер
if mmaddnode $node; then
 echo "Successfully added $node to GPFS cluster, starting GPFS on $node"
 if mmstartup -w $node; then
 echo "mmstartup -w $node succeeded"
 else
 echo "** error: cannot start GPFS on $node, please investigate"
 exit 6
 fi
else
 echo "** error: could not add $node to GPFS cluster"
 exit 5
fi

) >>$log_file 2>&1

Можно использовать CSM для автоматического запуска сценария, приведенного в листинге 1, после завершения базовой установки операционной системы на узле, так чтобы при ее загрузке автоматически монтировалась файловая система GPFS. Прежде всего, вы должны определить сценарий как механизм ответа в CSM-мониторе. Например: mkresponse -n SetupGPFS -s /path/to/script/SetupGPFS.sh SetupGPFS.

Теперь у вас имеется ответ под названием SetupGPFS, который будет запускать ваш сценарий. Затем вы должны назначить этот ответ CSM-условию по умолчанию NodeFullInstallComplete следующим образом: startcondresp NodeFullInstallComplete SetupGPFS.

Теперь CSM всегда будет автоматически запускать сценарий с управляющего сервера при установке нового узла. На управляющем сервере CSM вы можете увидеть условие NodeFullInstallComplete, связанное с ответом SetupGPFS, при запуске команды lscondresp. Условие или ответ должны быть указаны как Active.

Переполнение адресации ROM

Существует известная проблема с объемом ROM-памяти, доступной на xSeries 346, - ошибки распределения PCI во время загрузки. Сообщения указывают, что системная ROM-память заполнена, и больше нет места для дополнительных адаптеров, использующих память ROM (более подробно в разделе "Ресурсы").

Эта проблема влияет на узлы системы хранения данных, поскольку, если разрешена PXE-загрузка, нет достаточного объема памяти для корректной инициализации PCI-адаптеров Qlogic. Вот один из способов решения данной проблемы:

1. Запретите PXE-загрузку на PCI-карте Broadcom, используемой для GPFS-сети. Используя доступную для загрузки возможность diag b57udiag -cmd, выберите устройство, а затем запретите PXE-загрузку.
   
   
2. Используйте PXE-загрузку для установки узла с использованием CSM, а затем запретите PXE-загрузку для обоих адаптеров, используя BIOS (в порядке, описанном в разделе "Установка узлов системы хранения данных в правильном порядке").

Другое решение проблемы - использование карты RAID 7K в каждой xSeries 346. Она уменьшит объем ROM, используемый SCSI BIOS, и позволит успешно загрузиться Qlogic BIOS даже с разрешенной PXE-загрузкой.

Определение конфигурации HBA на серверах хранения данных

На серверах хранения данных xSeries 346 примера кластера в качестве HBA используются адаптеры модели IBM DS4000 FC2-133 Host Bus Adapter (HBA). Они известны также под названием Qlogic 2342. В примере используется версия встроенной микропрограммы 1.43 и, как упоминалось в предыдущем разделе, драйвер v7.01.01-fo qla2300. Суффикс -fo драйвера обозначает функциональность восстановления после сбоев, которая не является параметром по умолчанию для этого драйвера. Данная функциональность разрешается путем изменения настроек в /etc/modules.conf на каждом узле системы хранения данных. Это действие выполняется при помощи CSM во время установки и описано в разделе "Настройка системы восстановления после сбоев Qlogic".

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

Загрузка микропрограммы HBA

Микропрограмму для HBA-адаптеров FC2-133 можно выполнить с Web-сайта поддержки IBM System x (см. раздел "Ресурсы"). Обновить микропрограмму можно при помощи IBM Management Suite Java, или используя загрузочную дискету и программу flasutil.

Настройка параметров HBA

Для данного примера кластера были изменены (со значений по умолчанию) приведенные ниже настройки HBA-адаптеров. Значения можно найти в файле README, поставляемом вместе с драйвером. Изменения можно сделать в Qlogic BIOS, который вызывается во время загрузки путем нажатия комбинации клавиш <ctrl>-q при запросе либо при помощи служебной программы MSJ. Вот эти настройки:

• Настройки адаптера хоста
  • Loop reset delay: 8
• Расширенные настройки адаптера
  • LUNs per target: 0
  • Enable target reset : Yes
  • Port down retry count: 12

Установка IBM Management Suite Java

IBM FAStT Management Suite Java (MSJ) - это Java-приложение с графическим интерфейсом пользователя (GUI), управляющее HBA-адаптерами в управляющих серверах. Его можно использовать для настройки и диагностики. Ссылки на источники для загрузки этой программы приведены в разделе "Ресурсы".

В нашем примере используется CSM для установки MSJ на каждом узле системы хранения данных как части общей установки GPFS. Бинарный файл является частью tar-файла, содержащего RPM-файлы GPFS, который CFS распространяет во время установки CSM-узла. Сценарий, выполняющийся после установки, разархивирует этот tar-файл, который, в свою очередь, запускает сценарий установки, содержащийся внутри tar-файла. В примере используется 32-разрядная версия FAStT MSJ, чтобы обойти потенциальные проблемы, возможные при установке 64-разрядной версии. Пример сценария использует следующую команду для установки MSJ: FAStTMSJ*_install.bin -i silent.

Устанавливается приложение и агент. Обратите внимание на то, что поскольку это 32-разрядная версия MSJ, даже при том, что пример использует не интерактивную установку, код ищет и загружает 32-разрядные версии некоторых библиотек. Следовательно, используйте установленную 32-разрядную версию XFree86-libs, также как 64-разрядную версию, включаемую при базовой 64-разрядной установке. 32-разрядные библиотеки содержатся в файле XFree86-libs-4.3.0-78.EL.i386.rpm, включенном в tar-файл. Установкой этого rpm-файла занимается сценарий install.sh, который затем устанавливает MSJ.

Настройка путей к дискам и распределения нагрузки

Наличие MSJ требуется на каждом узле системы хранения данных для ручной настройки путей к массивам на DS4500 и распределения нагрузки между двумя HBA-адаптерами на каждом компьютере. Если эту настройку не выполнить, по умолчанию все массивы будут доступны через первый адаптер на каждом компьютере (HBA0) и, соответственно, через контроллер A на каждой системе DS4500. Распределяя диски между HBA-адаптерами и, следовательно, между двумя контроллерами на DS4500, вы распределяете нагрузку и улучшаете производительность сервера.

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

1. Откройте новое окно на локальном компьютере из вновь установленного сервера с установкой xforwarding (ssh <nodename> -X).
   
   
2. В одной сессии запустите # qlremote.
   
   
3. В другой сессии запустите # /usr/FAStT MSJ & для загрузки MSJ GUI.
   
   
4. В MSJ GUI выделите один из адаптеров в закладке HBA и выберите Configure. Появится окно, аналогичное изображенному на рисунке 1.
   
   Рисунок 1. Вид MSJ при выборе DS4500
   
   
   
   
   
5. Для разрешения распределения нагрузки выделите подсистему хранения данных, представляемую после щелчка правой кнопкой мыши на имени узла, и выберите LUNs > Configure LUNs. Появится окно настройки LUN. Вы можете автоматически настроить распределение нагрузки, выбрав Tools > Load Balance. Затем появится окно, аналогичное изображенному на рисунке 2.
   
   Рисунок 2. Вид MSJ при настройке системы восстановления после сбоев
   
   
   
   
   
6. После настройки логических дисков окно настройки LUN закроется, сохраняя конфигурацию на хост-системе в окне Port Configuration (используется пароль по умолчанию config). В случае успешного сохранения конфигурации вы увидите подтверждение. Конфигурация сохраняется в виде файла /etc/qla2300.conf. Необходимо добавить новые параметры в строку драйвера qla2300 в файле /etc/modules.conf для индикации существования данного файла и необходимости его использования.
   
   
7. Вернитесь в окно, в котором был запущен процесс qlremote, и остановите его, используя клавиши <ctrl>-c. Это важный шаг.
   
   
8. Для активизации новой конфигурации перезагрузите модуль драйвера qla2300. Этого сделать нельзя, если диск смонтирован на подсистеме Fibre Channel, подключенной к адаптеру, использующему данный драйвер. Настройте драйвер адаптера хоста, который нужно загрузить, через исходный RAM-диск. Конфигурационные данные применятся для резервных дисков при загрузке модуля адаптера во время начальной загрузки. Обратите внимание на то, что необходимо выполнить эту процедуру для сохранения корректной настройки в системе при любом изменении конфигурации модуля адаптера.

Одним из наиболее эффективных способов использования MSJ при установке (когда нужно выполнить настройку распределения нагрузки на более чем одном узле системы хранения данных) является сохранение MSJ в открытом состоянии на одном узле, запуск qlremote на каждом из остальных узлов и использование одной MSJ-сессии для подключения к ним.