XCAT: различия между версиями

Материал из ALT Linux Wiki
Строка 273: Строка 273:


В таблицу <tt>passwd</tt> добавляется запись: <tt>key=>'omapi',username=>'xcat_key'</tt>.
В таблицу <tt>passwd</tt> добавляется запись: <tt>key=>'omapi',username=>'xcat_key'</tt>.
Следует убедится что настроенный bind и файл <tt>/etc/hosts</tt> несут одинаковую информацию (<tt>makehosts</tt><tt>makedns</tt>):
Пример не настроенного DNS-сервера:
# nslookup sn1-eth1 172.16.2.2
Server:        172.16.2.2
Address:        172.16.2.2#53
** server can't find sn1-eth1: NXDOMAIN


=== DHCP сервер ===
=== DHCP сервер ===

Версия от 12:25, 6 апреля 2010


Установка

Документация для xCAT постоянно обновляется. Последняя, обновлённая, официальная документация доступна: тут.

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

Особенности ALT Linux

После того как завершена установка пакетов xCAT необходимо провести несколько ALT Linux специфических настроек.

  • Отдельно, для каждой архитектуры создать sources.list файл, в котором указать способ доступа к репозиторию. Например:
# cat /etc/xcat/sources.list_x86_64
rpm file:/ALT/Sisyphus x86_64 classic
rpm file:/ALT/Sisyphus noarch classic
  • Задать в таблице site расположение этих файлов:
# chtab key=aptsrclist_x86_64 site.value="/etc/xcat/sources.list_x86_64"
# chtab key=aptsrclist_x86 site.value="/etc/xcat/sources.list_x86"
  • Пользователю _mknetboot разрешено просматривать таблицы xCAT, но сначала нужно создать сертификат, доказывающий подлинность пользователя:
# /usr/share/xcat/scripts/setup-local-client.sh _mknetboot
  • Создать основу initrd образа и ядро для сетевой загрузки (discovery):
# nbcreate -v -a x86_64
# nbcreate -v -a x86

Сборка образа initrd для сетевой загрузки происходит в домашнем каталоге пользователя _mknetboot. Будут созданы: 

/usr/share/xcat/netboot/x86_64/nbroot_base
/usr/share/xcat/netboot/x86/nbroot_base
/var/lib/tftpboot/xcat/nbk.x86_64
/var/lib/tftpboot/xcat/nbk.x86
  • Создать initrd с учетом существующих SSL/SSH ключей:
# mknb x86_64
# mknb x86
# ls /var/lib/tftpboot/xcat/nbfs.x86_64.gz

В такущей реализации XCAT нету возможности явно задать какая архитектура (32 бит или 64) будет использоваться для discovery. Если текущая не подходит то следует удалить файл: /var/lib/tftpboot/pxelinux.cfg/7F или /var/lib/tftpboot/xcat/xnba/nets/172.16.2.0_24

и сказать заново mknb <ARCH>

При установке RPM пакетов на Management Node происходит настройка службы syslog. Дополнительную информацию можно узнать из: /var/lib/xcat/postscripts/syslog. Архитектура xCAT предполагает что:

  1. Management Node хранит свои LOG файлы локально.
  2. Service Node может хранить файлы как локально так и отсылать своему Management Node. Поведение регулируется установкой пераметра site.svloglocal.
  3. Compute Node отсылает информацию о событиях на хранение Management Node.

При установке xCAT будут сгенерированы SSH ключи. Авторизованные ключи будут хранится в /var/lib/xcat/postscripts/_ssh/authorized_keys.

Ввиду того что ALT Linux после установки statefull узла форматирует файл /var/lib/xcat/mypostscript.pos вместо /tmp/xcat/mypostscript.pos, так как папка /tmp в ALT Linux очищается.

Базовая настройка

Имя managment node

Необходимо убедится, что во время установки xCAT правильно определил имя сервера на котором он будет работать: 

# openssl x509 -text -in /etc/xcat/cert/server-cert.pem -noout | grep Sub
Subject: CN=mn.cluster

Если имя managment node определено не правильно тогда:

  • настроить /etc/sysconfig/network, перезагрузить компьютер.
  • добавить имя managment node в файл /etc/hosts:
# cat /etc/hosts
127.0.0.1       localhost.localdomain localhost
172.16.2.2      mn.cluster mn
  • проверить правильно идет ли распознавание имени:
# gethostip mn.cluster
mn.cluster 172.16.2.2 AC100202
  • перегенерить все сертификаты для новго имени (все настройки будут сброшены):
# xcatconfig -f --installdir="/var/lib/xcat" --tftpdir="/var/lib/tftpboot"
# lsdef -t site -l -i domain
 Setting the name of the site definition to 'clustersite'.
 Object name: clustersite
     domain=cluster
# gettab key=domain site.value
  cluster
# lsdef -t site -l -i master
 Setting the name of the site definition to 'clustersite'.
 Object name: clustersite
     master=172.16.2.2

IP сети

Во время установки RPM пакетов xCAT автоматически заносит обнаруженные сети в таблицу. Ненужные сети можно удалить вручную.

Добавляем сети с которыми будет работать xCAT: 

# chtab net="172.16.2.0" networks.netname="clusterNet" networks.gateway="172.16.2.1" networks.dhcpserver="172.16.2.2" networks.tftpserver="172.16.2.2" networks.nameservers="172.16.2.2" networks.dynamicrange="172.16.2.200-172.16.2.250"

Посмотрим все сети о которых знает xCAT: 

# lsdef -t network -l
Object name: clusterNet
   dhcpserver=172.16.2.2
   dynamicrange=172.16.2.200-172.16.2.250
   gateway=172.16.2.1
   mask=255.255.255.0
   mgtifname=eth0
   nameservers=172.16.2.2
   net=172.16.2.0
   tftpserver=172.16.2.2

Данная запись содержится в таблице networks: 

# tabdump networks
#netname,net,mask,mgtifname,gateway,dhcpserver,tftpserver,nameservers,ntpservers,logservers,dynamicrange,nodehostname,comments,disable
"clusterNet","172.16.2.0","255.255.255.0","eth0","172.16.2.1","172.16.2.2","172.16.2.2","172.16.2.2",,,"172.16.2.200-172.16.2.250",,,

Параметры:

  • dynamicrange - задает диапазон IP адресов, которые будут выделятся для неопознанных узлов. Используется при discovery
  • mgtifname - имя интерфейса, ведущий в данную сеть

Вычислительные узлы

Таблица nodelist содержит все определённые узлы. Добавим узел: 

# nodeadd node1 groups=real,all
# chtab node=node1 hosts.ip="172.16.2.11"

Любой узел обязан находится в группе all. Часть параметров для узла хранятся в таблице `hosts': 

# tabdump hosts
#node,ip,hostnames,otherinterfaces,comments,disable
"node1","172.16.2.11",,,,

Или же, используя шаблон, можно создать, например, следующие правило:

  1. chtab node=real hosts.ip='|\D+(\d+)|172.16.2.(100+$1)|'

которое указывает, что узлам node1, node2,... будут соответствовать IP: 172.16.2.101, 172.16.2.102,... Без механизма Discovery необходимо знать MAC: 

# chtab node="node1" mac.mac="2a:2a:2a:2a:2a:2a"

Необходимо выполнить следующие команды: 

# makehosts
# makedns
# service bind restart

Команда makehosts пропишет соответствия `имя - IP' в файл /etc/hosts для всех узлов заданных в xCAT: 

# cat /etc/hosts
127.0.0.1       localhost.localdomain localhost
172.16.2.2      mn.cluster mn
172.16.2.11 node1 node1.cluster

Команда makedns обновит настройки BIND.


если использовали шаблон: 

# makehosts real
# cat /etc/hosts
127.0.0.1       localhost.localdomain localhost
172.16.2.2      mn.cluster mn
172.16.2.101 node1 node1.cluster

Hardware managment

Аппаратная часть вычислительных узлов управляются с помощью service processors.

xCAT поддерживает следующие типы service processors:

  • BMC - Intel, Baseboard Management Controller
  • MPA - IBM, Management Processor Assistan
  • FSP - IBM, Flexible Service Processor
  • BPA - IBM, Bulk Power Assembly
  • HMC - IBM, Hardware Management Console

Параметры service processors для каждого вычислительного узла задаются в таблице hodehm.

Поле nodehm.mgt может принимать следующее значение:

  • ipmi - тогда, специфические опции service processor указываются в таблице ipmi
  • blade - таблица mp
  • hmc - таблица ppc
  • ivm - таблица ppc (Integrated Virtualization Manager)
  • fsp - таблица ppc

Припустим у нас есть материнская плата производства Intel, на которой установлен BMC. Сведения о BMC занесем в xCAT. Контроллер BMC будет выступать отдельным узлом xCAT.

1. Поместим BMC в группу: managment module (mm): 

# chtab node=bmc1 nodelist.groups=mm

2. Укажем, что service processors в группе managment module (mm) управляются через IPMI интерфейс: 

# chtab node=mm nodehm.mgt=ipmi

3. Зададим параметры доступа к BMC-адаптеру: 

# chtab node=bmc1 ipmi.bmc=bmc1 ipmi.username=root ipmi.password=123

или, если все BMC имееют одинаковые настройки username/password: 

# chtab key=ipmi passwd.username=root passwd.password=123

Если параметры username/password не заданы в таблице ipmi, тогда будет использованы поля из таблицы passwd с ключом key=ipmi.

4. Сетевые настройки BMC контроллера должны быть заранее настроены. Сообщим xCAT IP адрес BMC контроллера: 

# chtab node=bmc1 hosts.ip="172.16.2.12"
# makehosts mm # обновит /etc/hosts

5. Проверим что BMC контроллер bmc1 действительно удалено управляется: 

# ipmitool -A PASSWORD -I lanplus -H bmc1 -U root -a lan print

Для взаимодействия с service processors xCAT предоставляет ряд утилит: 

# rspconfig bmc1 ip
bmc1: BMC IP: 172.16.2.12
# rpower bmc1 status
bmc1: on

Включили/выключили мигалку: 

# rbeacon bmc1 on
bmc1: on
# rbeacon bmc1 off
bmc1: off

Прочитать последних 5ть событий BMC контроллера: 

# reventlog bmc1 5
bmc1: 01/12/2010 21:12:18 Power Unit, Power Off / Power Down (Pwr Unit Status) - Recovered
bmc1: 01/12/2010 21:12:19 Power Unit, Power Unit Failure Detected (Pwr Unit Status) - Recovered
bmc1: 01/12/2010 21:12:28 System Event, BMC Time synchronization event (Sensor 0x83)
bmc1: 01/12/2010 21:12:28 System Event, BMC Time synchronization event (Sensor 0x83)
bmc1: 01/12/2010 21:12:53 System Event, Boot (Sensor 0x83)

Узнать модель материнской платы, версию биоса, серийные номера можно с помощью команды: 

# rinv bmc1 all
bmc1: System Description: S5500BC
...

Снять показания установленных датчиков можно: 

# rvitals bmc1 all
bmc1: BB +5.0V: 5.016 Volts
...

Временно изменить загрузочное устройство: 

# rsetboot bmc1 net
bmc1: Network

Предположение

припустим, у нас есть вычислительные узлы hw1-hw4: 

# nodeadd hw1-hw4 groups=all,compute,mm

Занесём hw1-hw4 к группе mm, это подразумевает, что вычислительные узлы управляются BMC контроллером. Скажем что все вычислительные узлы в группе compute управляются контроллером bmc1: 

# chtab node=compute ipmi.bmc="bmc1" ipmi.username=root ipmi.password=123

Тогда справедливо: 

# rpower hw1 status
hw1: on
# rpower hw2 status
hw2: on
# rpower hw3 status
hw3: on
# rpower hw4 status
hw4: on

Conserver

В задачи conserver входит:

  1. протоколирование активности всех узлов на последовательном порту
  2. мониторинг текущей ситуации для конкретных узлов

Параметры доступа к последовательному порту задаются в таблице nodehm (node's hardware managed): 

# chtab node=mm nodehm.mgt=ipmi nodehm.serialport="0" nodehm.serialspeed="115200" nodehm.serialflow="hard"
# makeconservercf

Команда makeconservercf генерирует конфигурационный файл /etc/conserver.cf. Для каждого отдельного узла который входит в группу mm будет занесена запись в файл /etc/conserver.cf. После обновления конфигурационного файла необходимо перезапустить службу: 

# service conserver restart

В случае успеха можно будет использовать команды мониторинга: 

# rcons bmc1
[Enter `^Ec?' for help]
[SOL Session operational.  Use ~? for help]
Welcome to R / ttyS0
node1.localdomain login:
# man wcons

А также просмотреть журнал для узла: 

# cat /var/log/consoles/bmc1

В списке процессов можно увидеть: 

8101 pts/5    Ss+    0:00 ipmitool -I lanplus -U root -P XXX -H bmc1 sol activate

BIND

Необходимо задать IP где работает bind, который будет обслуживать имена в рамках xCAT. Обычно такой bind работает на managment node: 

# chtab key=nameservers site.value="172.16.2.2"

Все другие запросы по разрешению имя-IP будут перенаправляться внешнему nameserver-у: 

# chtab key=forwarders site.value="10.2.0.1"

Проверим: 

# tabdump site | grep -E 'name|forw'
"nameservers","172.16.2.2",,
"forwarders","10.2.0.1",,

В ALT Linux bind работает в chroot окружении, поэтому: 

# chtab key=binddir site.value="/var/lib/bind/zone/"
# chtab key=bindzones site.value="/zone/"

Обновим настройки BIND: 

# makedns

Смотрим /etc/named.conf Смотрим /var/lib/bind/zone/db.* 

# service bind restart

В таблицу passwd добавляется запись: key=>'omapi',username=>'xcat_key'.

Следует убедится что настроенный bind и файл /etc/hosts несут одинаковую информацию (makehostsmakedns): Пример не настроенного DNS-сервера: 

# nslookup sn1-eth1 172.16.2.2
Server:         172.16.2.2
Address:        172.16.2.2#53
** server can't find sn1-eth1: NXDOMAIN

DHCP сервер

Если необходимо ограничить интерфейсы, на которых должен слушать DHCP сервер: 

# chtab key=dhcpinterfaces site.value='eth0'

О синтаксисе dhcpinterfaces параметра можно узнать: 

# tabdump -d site | sed -ne '/dhcpi/,+4 p'
dhcpinterfaces:  The network interfaces DHCP should listen on.  If it is the same
                 for all nodes, use simple comma-separated list of NICs.  To
                 specify different NICs for different nodes:
                      mn|eth1,eth2;service|bond0.

Для DHCP сервера скажем, что все неопознанные узлы должны пройти discovery: 

# makedhcp -n
# grep dynamic /etc/dhcp/dhcpd.conf
range dynamic-bootp 172.16.2.200 172.16.2.250;
# service dhcpd restart

# chtab node=compute chain.chain="runcmd=bmcsetup,standby" chain.ondiscover=nodediscover

Конфигурацией ISC DHCP сервера можно управлять без перезагрузки, что и делает xCAT. Обновим конфигурацию DHCP сервера информацией о узеле: 

# makedhcp node1
# cat /var/lib/dhcp/dhcpd/state/dhcpd.leases

TFTP сервер

XXX: Настройки для atftpd: edit /etc/sysconfig/atftpd : ATFTPD_EXTRA_ARGS="/var/lib/tftpboot" 

# service atftpd restart
# chkconfig atftpd on

NTPD

Можно использовать общедоступный NTP сервер, или самостоятельно настроить NTP сервер. 

# chtab key=ntpservers site.value=<имя настроенного NTP сервера>

Указанный NTP сервер будет использоваться statefull/stateless узлами. Для statefull узлов необходимо задать скрипт setupntp: 

# chtab node=node1 postscripts.postscripts=setupntp


Вычислительные узлы должны использовать ntpd а не opentpd (завязка под postscripts).

NFS

Во время установки xCAT, или вызове команды xcatconfig автоматически обновляется файл /etc/exports: 

$ cat /etc/exports 
# see also /etc/sysconfig/portmap (control portmap)
/var/lib/tftpboot *(rw,no_root_squash,sync)
/var/lib/xcat *(rw,no_root_squash,sync)

HTTP

HTTP-сервер используется для diskful установки. Параметры HTTP сервера находятся в файле /etc/httpd2/conf/extra-available/xcat.conf.

FTP

FTP-сервер используется для доступа к postscripts и credentials. Во время запуска xcatd:

  1. для пользователя vsftpd изменяется домашний каталог на /var/lib/xcat
  2. разрешается сервис vsftpd в xinetd
  3. если сервис xinetd выключен, тогда он включается (модуль AAsn.pm)

Stateless

В странице руководства xCAT упоминается, что stateles образ с необходимым Linux дистрибутивом можно создать лишь на этом же Linux дистрибутиве. Так что, мы не сможем создать stateles образ с Fedora используя ALT Linux. Для этого понадобится service node работающий под Fedora Linux. Но все еще остаётся возможность перманентной установки других Linux дистрибутивов для fullstate узлов, используя managment node с ALT Linux.

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

  • создать самому
  • использовать официальный репозиторий ALT Linux (Sisyphus, branch 4.x 5.x)
  • использовать пакетную базу из установочных CD/DVD дисков

Необходимо предоставить sources.list файл для требуемой архитектуры (x86, x86_64). Например: 

# cat /etc/xcat/sources.list_x86_64
rpm file:/salto/ALT/Sisyphus x86_64 classic
rpm file:/salto/ALT/Sisyphus noarch classic

В таблице site задаётся расположение sources.list файла: 

# chtab key=aptsrclist_x86 site.value="/etc/xcat/sources.list_x86"
# gettab key=aptsrclist_x86_64 site.value
/etc/xcat/sources.list_x86_64

Укажем какая ОС должна выполняться на узле: 

# chtab node=node1 nodetype.os=alt nodetype.arch=x86_64 nodetype.profile=compute nodetype.nodetype=osi
# chtab node=node1 noderes.netboot=pxe noderes.tftpserver=172.16.2.2 noderes.nfsserver=172.16.2.2 noderes.installnic=eth1 noderes.primarynic=eth1

или занести узел node1 в группу diskless: 

# chdef -t node -o node1 -p groups=diskless # удалить из группы -m
# nodech "node1" groups,=diskless # удалить из группы nodech "node1" groups^=diskless

задать параметры в nodetype,noderes для группы diskless: 

# chtab node=diskless nodetype.os=alt nodetype.arch=x86_64 nodetype.profile=compute nodetype.nodetype=osi
# chtab node=diskless noderes.netboot=pxe noderes.tftpserver=172.16.2.2 noderes.nfsserver=172.16.2.2 noderes.installnic=eth1 noderes.primarynic=eth1

Создадим stateless rootfs: 

# genimage -i eth1 -n e1000e -o alt -p compute
или используя диалог:
# genimage
или, если необходимо изменить архитектуру (поддерживается x86, x86_64):
/usr/share/xcat/netboot/alt/genimage -a x86 -i eth1 -n e1000e -o alt -p compute

Образ создаётся с помощью mkimage, запущенного от имени пользователя _mknetboot. Сборка будет происходить в домашнем каталоге /var/lib/_mknetboot/genimage.XXXXXX.

В случае успеха на выходе получим: 

# ls -1p /var/lib/xcat/netboot/alt/x86_64/compute/
initrd.gz
kernel
rootimg/

Упакуем этот rootfs с учётом текущих SSL сертификатов и ключей SSH: 

# packimage -p compute -o alt -a x86_64 -m nfs

Получим: /var/lib/xcat/netboot/alt/x86_64/compute/rootimg.nfs Возможные варианты образа:

  • nfs
  • squashfs
  • cpio

Скажем чтобы узел загрузился по сети в stateless режим: 

# nodeset node1 netboot

Параметр noderes.netboot=pxe указывает что сетевая загрузка ядра будет производится с использованием pxelinux.

Параметр noderes.netboot=xnba указывает что сетевая загрузка ядра будет производится с использованием gPXE, xNBA.

Команда nodeset node1 netboot создаст конфигурационный файл для загрузки через сеть: 

# cat /var/lib/tftpboot/pxelinux.cfg/node1 
 #netboot alt-x86_64-compute
 DEFAULT xCAT
 LABEL xCAT
 KERNEL xcat/netboot/alt/x86_64/compute/kernel
 APPEND initrd=xcat/netboot/alt/x86_64/compute/initrd.gz fastboot imgurl=nfs://172.16.2.2/install/netboot/alt/x86_64/compute/rootimg

или 

# cat /var/lib/tftpboot/xcat/xnba/nodes/node1
#!gpxe
 #netboot alt-x86_64-compute
 imgfetch -n kernel http://${next-server}/tftpboot/xcat/netboot/alt/x86_64/compute/kernel
 imgload kernel
 imgargs kernel fastboot imgurl=nfs://172.16.2.2//var/lib/xcat/netboot/alt/x86_64/compute/rootimg console=tty0 console=ttyS0,115200n8r
 imgfetch http://${next-server}/tftpboot/xcat/netboot/alt/x86_64/compute/initrd.gz
 imgexec kernel


В этих конфигурационных файлах можно задать ключи debug, shell. Они влияют только на работу /init скрипта из initrd.

Внимание: /var/lib/xcat/netboot/alt/x86_64/compute/initrd.gz - этот initrd образ, который будет искать и монтировать корневую файловую систему. Но пока мы не скажем: nodeset node1 netboot будет использоваться старый initrd образ: /var/lib/tftpboot/xcat/netboot/alt/x86/compute/initrd.gz

Команда: 

# rnetboot noderange

аналог 

# nodeset noderange netboot
# rpower noderange boot

Но, следует заметить что noderange, должны управляться неким managment node (см. поле nodehm.mgt).

Проверим в каком режиме работает наш узел, после того как загрузится по сети: 

# nodestat node1
node1: sshd

При вызове команды packimage:

  1. Пароль пользователя root буден записан в образ из значений: passwd.system, username=root.
  2. Будут синхронизированы файлы перечисленные в /install/custom/<inst_type>/<distro>/<profile>.<os>.<arch>.synclist (см. xCAT2SyncFilesHowTo.pdf).
  3. Записан скрипт для загрузки post-скриптов /etc/init.d/xcatpostinit.


Console

К узлу можно получить доступ через serial консоль. Для этого обычно используется протокол SoL (Serial Over Lan) на BMC контроллере. Скажем чтобы при загрузке узел открыл консоль на последовательном порту: 

# chtab node=serial nodehm.serialport=0 nodehm.serialspeed=115200

Тогда любой узел состоящий в группе serial будет открывать консоль на последовательно порту после загрузки.

Нужно убедится что PXE файл для узла создан правильно: 

# cat /var/lib/tftpboot/pxelinux.cfg/node1 
#netboot alt-x86_64-compute
DEFAULT xCAT
LABEL xCAT
 KERNEL xcat/netboot/alt/x86_64/compute/kernel
 APPEND initrd=xcat/netboot/alt/x86_64/compute/initrd.gz fastboot imgurl=nfs://172.16.2.2//var/lib/xcat//netboot/alt/x86_64/compute/rootimg console=tty0 console=ttyS0,115200

посмотреть на наличие параметра console=ttyS0,115200. При загрузке узла, саму консоль откроет скрипт: /etc/init.d/xcatconsole.

Для передачи данных с последовательно порта нужно настроить SoL на BMC. 

# ipmitool sol info 1

Изменим параметры SoL в BMC контроллере, используя Linux, загруженный на узле: 

# ipmitool sol set volatile-bit-rate 115.2 1
# ipmitool sol set non-volatile-bit-rate 115.2 1

Когда настроен BMC для предоставления доступа к последовательному порту узла, инициируем соединение к BMC: 

# ipmitool -I lanplus -H bmc1 -U root -a sol activate
 Password: 
[SOL Session operational.  Use ~? for help]
Welcome to R / ttyS0
localhost.localdomain login:

При настроенном conserver достаточно выполнить: 

# rcons bmc1

Параметры SоL на BMC контроллере также можно задать:

  1. при discovery узла. runcmd=bmcsetup
  2. после discovery, выполнив nodeset <node> runcmd=bmcsetup

Параметры BMC описываются в текстовом файле см раздел Nodes.

После загрузки узла, hostname будет установлено следуя: RESOLVE_HOSTNAME_COMMAND=/etc/init.d/xcathostname из /etc/sysconfig/init.

Statelite

Сокращения

  • Образ - image, каталог содержащий NFS root;
  • Узел - node, computing node, вычислительный узел;
  • Корень - корневая файловая система (обычно подразумевается NFS root);
  • Перманентные файлы - которые переживают перезагрузку.

Особенности

  1. узлы грузятся через сеть;
  2. в качестве корневой файловой выступает NFS;
  3. возможно указать имена файлов, которые будут сохраняться между перезагрузками узлов;

Преимущества

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

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

  • Способствует к уменьшению потребляемых системных ресурсов в решениях с использованием виртуализации. Если в kvm использовать образ диска (stateless - squashfs, stateful - файл диска) тогда будут нецелесообразно потребляется память и дисковое пространтсво.

Минусы

  • Использование NFS в качестве корневой файловой системы требует в передаче большого объёма сетевого трафика.
  • Усложнённая настройка узлов для использованием NFS в качестве корневой файловой системы.
  • Можно одновременно задать различные хранилища для перманентных файлов, что приводит к большим вероятностям возникновения ошибок.

Настройка

Образ загружаемый по сети размещается в /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg

Во время инсталляции xCAT обновляется конфигурационный файл NFS сервера: 

# cat /etc/exports 
/var/lib/tftpboot *(rw,no_root_squash,sync)
/var/lib/xcat *(rw,no_root_squash,sync)

как видно, к каталогам предоставляется доступ на запись (rw). Желательно ограничить доступ к файлам только на чтение, с последующей перезагрузкой службы NFS: 

# cat /etc/exports 
/var/lib/tftpboot *(ro,no_root_squash,sync)
/var/lib/xcat *(ro,no_root_squash,sync)
# service nfs restart

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

таблица litefile

Таблица litefile используется когда необходимо указать список уникальных файлов для statelite узла. По умолчанию такие файлы:

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

Таблица litefile содержит следующие поля: 

# tabdump litefile
#image,file,options,comments,disable
  • image - имя образа. Если узел будет использовать этот образ (см таблицу nodetype), тогда будет срабатывать это правило. Значение может принимать следующие значение:на запись
    • быть пустым или ALL - правило срабатывает для всех образов.
    • имя образа - аналогичное имени в таблице osimage.
  • file - полный путь к файлу. Если указывается каталог, тогда он должен заканчиваться с /.
  • options - задает параметры файла. Возможные пути синхронизации файла:
    • empty, ALL или tmpfs - используется по умолчанию. Файл будет размещен в tmpfs. Источником для файла будет служить первая подходящая запись из таблицы litetree.
    • con - режим подобен tmpfs. Из таблицы litetree будут выбраны все файлы с данным именем. Все файлы найденные в иерархии будут объединены. Содержимое указанного пути соединяется уже с существующим.
    • persistent - режим подобен tmpfs. Требует точку монтирования для statefull. Если файл отсутствует, он будет автоматически создан во время инициализации. Требует чтобы в таблице statelite указывалось хранилище для этого файла. Это означает что файл будет устойчивый к перезагрузкам.
    • persistent,con - файл в начале будет объединён, и потом будет размещен в постоянной точке монтирования.
    • ro - Файл доступный только на чтение. Это означает что файл будет встроен в некоторое место в иерархию каталогов.


Пример заполнения таблицы litefile. Приведённый ниже список может быть отправной точкой при заполнении litefile таблицы. Все файлы будут размещены в tmpfs. Постоянное хранилище для нижележащих файлов отсутствует. Что позволяет использовать NFS корень доступным только на чтение. 

image,file,options,comments,disable
"ALL","/etc/adjtime",,,
"ALL","/etc/fstab",,,
"ALL","/etc/inittab",,,
"ALL","/etc/lvm/.cache",,,
"ALL","/etc/mtab",,,
"ALL","/etc/ntp.conf",,,
"ALL","/etc/ntp.conf.predhclient",,,
"ALL","/etc/resolv.conf",,,
"ALL","/etc/resolv.conf.predhclient",,,
"ALL","/etc/ssh/",,,
"ALL","/tmp/",,,
"ALL","/var/account/",,,
"ALL","/var/arpwatch",,,
"ALL","/var/cache/alchemist",,,
"ALL","/var/cache/foomatic/",,,
"ALL","/var/cache/logwatch/",,,
"ALL","/var/cache/man/",,,
"ALL","/var/cache/mod_ssl/",,,
"ALL","/var/cache/mod_proxy/",,,
"ALL","/var/cache/php-pear/",,,
"ALL","/var/cache/systemtap/",,,
"ALL","/var/empty/",,,
"ALL","/var/db/nscd/",,,
"ALL","/var/gdm/",,,
"ALL","/var/lib/dav/",,,
"ALL","/var/lib/dhcp/",,,
"ALL","/var/lib/dhclient/",,,
"ALL","/var/lib/php/",,,
"ALL","/var/lib/scsi/",,,
"ALL","/var/lib/ups/",,,
"ALL","/var/lib/random-seed",,,
"ALL","/var/lib/iscsi",,,
"ALL","/var/lib/logrotate.status",,,
"ALL","/var/lib/ntp/",,,
"ALL","/var/lib/xen/ntp",,,
"ALL","/var/lock/",,,
"ALL","/var/log/",,,
"ALL","/var/run/",,,
"ALL","/var/tmp/",,,
"ALL","/var/tux/",,,

таблица litetree

# tabdump litetree
#priority,image,directory,comments,disable

При загрузке узла в statelite режиме, происходит копирование файлов с root образа в /.default каталог (tmpfs). Также существует возможность задать отдельно для каждого узла, откуда следует вытягивать файлы. Например, есть два различных файла /etc/motd:

  1. 10.0.0.1:/syncdirs/newyork-590Madison/rhels5.4/x86_64/compute/etc/motd
  2. 10.0.0.1:/syncdirs/shanghai-11foo/rhels5.4/x86_64/compute/etc/motd

В таблице litetree можно указать: 

1,,10.0.0.1:/syncdirs/$nodepos.room/$nodetype.os/$nodetype.arch/$nodetype.profile

тогда в зависимости от узла будет вытягиваться тот или иной файл.

Для начала можно проверить наличие файлов в каталогах содержащих в названии которых упоминается имя узла: $noderes.nfsserver:/syncdirs/$node Поле:

  • litetree.priority - задает приоритет. Каждое местоположение файла имеет свой приоритет.
  • litetree.priority - задаёт имя образа (ALL для все образов).
  • litetree.directory - точка монтирования.

Например: 1,,$noderes.nfsserver:/statelite/$node 2,,cnfs:/gpfs/dallas/ задает файлы которые мы хотим разместить на узлах:

  • каталог /statelite/$node размещен на сервере $noderes.nfsserver
  • каталог и /gpfs/dallas размещен на сервере cnfs.

Если файлы не найдены в первом каталоге, будет осуществлён поиск в следующем каталоге. Если файлы не обнаружены в иерархии таблицы litetree, тогда они ищутся в каталоге /.default на локальном образе.

Таблица statelite

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

# tabdump statelite
#node,image,statemnt,comments,disable
"japan",,"cnfs:/gpfs/state",,,

Все узлы состоящие в группе japan будут хранить своё состояния в каталоге /gpfs/state на машине с именем cnfs. Это правило будет применяться ко всем образам. Существует возможность задать различное местоположение хранилища.

Когда загружается узел:

  • значение поля statemnt будет смонтировано в /.statelite/persistent
  • автоматически создастся подкаталог: /.snapshot/persistent/<nodename>. Этот каталог будет служить корнем для постоянных файлов.

Замечание: не следует задавать имя каталога для постоянного хранилища после имени узла. Если всетаки нарушить эту рекомендацию, тогда каталог с именем /state/n01 будет хранить свое состояние в каталоге /state/n01/n01.

Права доступа

Следует убедится что политики безопасности настроены корректно. Когда загружается узел, он опрашивает базу xCAT и требует доступ к командам: 

# lite-files
# lite-tree

в таблице policy необходимо разрешить узлам доступ к этим командам: 

# chtab priority=4.7 policy.commands=litetree
# chtab priority=4.8 policy.commands=litefile

Эти команды выполняются автоматически при установке xCAT. Данные значения можно проверить если возникли какие-то ошибки.

Создание Statelite образа

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

  • Пусть имя образа будет test1.
  • Необходимо создать список пакетов, которые будут установлены в образ test1. Список пакетов задается в файле: /usr/share/xcat/netboot/alt/compute.pkglist
  • После чего, нужно выполнить команду:
# genimage

или: 

# /usr/share/xcat/netboot/alt/genimage -a x86 -i eth1 -n e1000e -o alt -p compute -m statelite

Команда genimage:

  • создает каталог в/var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg
  • создаст несколько каталогов для statelite режима внутри образа:
/.statelite
/.default
/etc/init.d/statelite
  • создаст initrd и ядро которые будут использоваться для загрузки узла.

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

Изменение statelite образа

Корневая FS созданную командой genimage доступна /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg. Чтобы внести какое-то изменния и выполнить команды внутри этого дерева можно воспользоваться командой chroot.

Для базовой настройки рабочего образа, все что необходимо, это, скопировать некоторые passwd файлы, и настройки ssh с xCAT в образ: 

# cd /opt/xcat/share/xcat/netboot/add-on/statelite/
# ./add_passwd /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg
# ./add_passwd /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg

Команда liteimg

Комманда liteimg вносит изменения в statelite образ и создаёт набор ссылок. Когда внесены все настройки в /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg можно выполнить: 

# liteimg <os>-<arch>-<profile>
# liteimg rhels5.3-x86_64-test1
# liteimg ­-o rhels5.3 ­-a x86_64 ­-p test1

Команда liteimg создаст 2 способа доступа к файлам, что позволит изменять файлы in their image state as well as during runtime.

Например, над файлом <$imgroot>/etc/ntp.conf были произведены следующие операции: 

# mkdir ­-p $imgroot/.default/etc
# mkdir ­-p $imgroot/.statelite/tmpfs/etc
# mv $imgroot/etc/ntp.conf $imgroot/.default/etc
# cd $imgroot/.statelite/tmpfs/etc
# ln ­-sf ../../../.default/etc/resolv.conf .
# cd $imgroot/etc
# ln ­-sf ../.statelite/tmpfs/etc/resov.conf .

оригинальный файл будет находится в $imgroot/.default/etc/ntp.conf.

$imgroot/etc/ntp.conf будет указывать на $imgroot/.statelite/tmpfs/etc/ntp.conf, который в свою очередь будет указывать на $imgroot/.default/etc/ntp.conf.

Внимание: при изменении параметров в таблице litefile необходимо заново выполнить комманду liteimg. Поскольку файлы и каталоги должны иметь два уровня перенаправлений.

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

# nodeset <noderange> statelite=centos5.3-x86_64-test1

данная команда создаст необходимые файлы в каталоге /var/lib/tftpboot для загрузки узла. Будет создан нужный PXE файл, так что узел будет загружаться с использованием nfsroot образа. Файл с параметрами загрузки будет выглядеть примерно: 

#statelite centos5.3-x86_64-all
DEFAULT xCAT
LABEL xCAT
 KERNEL xcat/netboot/centos5.3/x86_64/all/kernel
 APPEND initrd=xcat/netboot/centos5.3/x86_64/all/initrd.gz
 NFSROOT=172.10.0.1:/var/lib/xcat/netboot/centos5.3/x86_64/all
 STATEMNT=cnfs:/gpfs/state XCAT=172.10.0.1:3001 console=tty0 console=ttyS0,115200n8r

Перезагрузить узел 

# rpower <noderange> boot

Для просмотра процесса загрузки можно использовать rcons или wcons.

Команды

  • litefile <nodename> - показывает все statelite файлы, которые не берутся с базового образа.
  • litetree <nodename> - показывает точку монтирования NFS для узла.
  • Ilitefile <image name> - показывает stateless файлы которые будут использоваться для узла.
  • liteimg <image name> - создает набор символических ссылок в образе, которые совместимы с загрузкой statelite.

Структура каталогов statelite

Каждый образ statelite будет иметь следующие каталоги: 

/.statelite/tmpfs/
/.statelite/persistent/<nodename>
/.statelite/mnt # where directory tree is mounted from.
/.default/
/etc/init.d/statelite

Все файлы, которые представляют ссобой символичные ссылки будут указывать на /.statelite/tmpfs. Файлы в tmpfs которые постоянно указывают на: /.statelite/persistent/<nodename>/. Индивидуальное хранилище данного узла, будет смонтировано в каталог /.statelite/persistent/<nodename>. /.default - каталог, в который будут скопированы файлы с образа в tmpfs, если файлы не будут найдены в таблице litetree.

Значения полей

  • noderes.nfsserver - указывают сервер с корневым NFS каталогом. Если не задан, будет использоваться MN сервер.
  • noderes.nfsdir === /vol/xCAT/var/lib/xcat. At that point it assumes that the directory structure is the same as the install directory.

Отладка

При возникновении ошибки, для отладки можно воспользоваться следующими приёмами:

  1. При загрузке узла вызывается скрипт statelite из корневого каталога: $imgroot/etc/init.d/statelite. Этот скрипт не принадлежит к rc скриптам, а является частью pre switch root environment. В этом скрипте происходит создание ссылок. В начале скрипта есть строка, с вызовом set x. Если возникла необходимость просмотреть выполнение действий, можно раскомментировать эту строку. Тогда можно будет увидеть многочисленные вызовы команд для создания каталогов и ссылок.
  2. При загрузке узла, можно получить доступ к shell. Для этого в PXE файл узла можно добавить ключевое слово shell. Тогда скрипт из initramfs сделает несколько остановок, прежде чем выполнить switch_root.
  3. При создании ссылок, на узле создается протокол в лог-файле /.statelite/statelite.log


Пример

# nodeset <node> statelite

Statefull - вычислительный узел

Скопируем установочный CD. На основе этого CD будет создаваться statefull система: 

# copycds -n alt -a x86_64 /build/lioka/skif/altlinux-skif-x86_64-20091204.iso

На каждом узле заводится локальный аккаунт администратора (root). Пароль можно задать до установки системы: 

# chtab key=system passwd.username=root passwd.password=cluster

Возможные значения ключа: blade (management module), ipmi (BMC), system (nodes), omapi (DHCP), hmc, ivm, fsp.

Укажем какая ОС должна выполняться на узле: 

# chtab node=node1 nodetype.os=alt nodetype.arch=x86_64 nodetype.profile=compute nodetype.nodetype=osi
# chtab node=node1 noderes.netboot=pxe noderes.tftpserver=172.16.2.2 noderes.nfsserver=172.16.2.2 noderes.installnic=eth1 noderes.primarynic=eth1

Значение ключа system ассоциируется с вычислительными узлами. 

# nodeset node1 install

Команда: 

# rinstall noderange

аналог 

# nodeset noderange install

После этой команды в каталоге /var/lib/xcat/autoinst/node1 будут расположены файлы, необходимые для автоматической установки ALT Linux на узел node1. 

# rpower noderange boot

Комманда rinstall:

  • вызывает nodeset для обновления конфигурационного файла загрузчика
  • заставляет узел загрузится
  • инициализирует установку.

После завершения установки, должны выполнится ряд post installation скриптов. На последнем шаге происходит извещение managment node узла о удачной установке, на что MN изменит конфигурационный файл узла для загрузки ОС с локального диска (nodeset <noderange> boot).

Statefull - service node

Если задан профиль service тогда узел будет не вычислительным, а service node. В качестве базы данных нужно использовать БД отличную от sqlite.

Postinstall скрипты

Все стандартные скрипты находятся в каталоге /var/lib/xcat/postscripts. Свои личные или изменённые стандартные скрипты должны находится в /var/lib/xcat/postscritps/custom. Доступ к этип скриптам предоставляет FTP сервер. 

# lftp mn
lftp mn:~> ls
drwxr-xr-x    3 ftp      ftp          4096 Feb 15 14:54 alt
drwxr-xr-x    3 ftp      ftp          4096 Feb 15 14:54 autoinst
drwxr-xr-x    3 ftp      ftp          4096 Feb 12 20:32 netboot
drwxr-xr-x    8 ftp      ftp          4096 Feb 12 19:35 postscripts
drwxr-xr-x    2 ftp      ftp          4096 Feb 12 19:35 prescripts

Какие скрипты следует выполнить указывается для каждого узла/группы отдельно. Скрипты перечисленные в xcatdefaults будут выполняться для каждого diskfull/diskless узла, до выполнения всех личных скриптов.

Список необходимых к выполнению скриптов перечисляется в таблице postscripts: 

# tabdump postscripts
#node,postscripts,postbootscripts,comments,disable
"xcatdefaults","syslog,remoteshell,syncfiles","otherpkgs",,
"service","servicenode",,,

Внимание: поскольку многие скрипты были написаны предельно не аккуратно, и для других дистрибутивов (SuSe, RedHat), рекомендуется заранее убедится в их корректности. Не правильные скрипты могут быть причиной сбоя установки.

  1. Для diskful узлов postscripts будут выполнены после того как пакеты установлены, но до того как последует перезагрузка.
  2. Для diskless узлов postscripts будут выполнены в конце процесса загрузки.

Свои личные скрипты лучше писать чтобы они корректно выполнялись как для diskful так и для diskless узлов.

  • remoteshell - копирует SSH ключ на узел. Аутентификация по паролю запрещена. Если необходимо разрешить удалённый доступ по паролю, необходимо закомментировать в своём скрипте PasswordAuthentication no.
  • syslog - при запуске на Managment Node (/etc/xCATMN) разрешает принимать сообщения от узлов:
# cat /etc/sysconfig/syslogd
SYSLOGD_OPTIONS='-m 0 -r -u syslogd -j /var/resolv'

При запуске на вычислительном узле отправляет все сообщения на Managment Node: 

# cat /etc/syslog.conf
# xCAT settings
# *.* @172.16.2.2

При выполнении post скрипта на узле, передаются набор переменных:

  • MASTER ­- откуда будет грузится данный узел (service node или managment node)
  • NODE ­- имя текущего узла
  • OSVER, ARCH, PROFILE ­- атрибуты узла из таблицы nodetype
  • NODESETSTATE ­- аргумент переданный при вызове nodeset команды для текущего узла.
  • NTYPE - "service" or "compute"
  • Все атриббуты из таблицы site

Stateless

Узлы работающие в stateless режиме используют общий образ. Во время загрузки любого diskless узла будут выполнены скрипты в такой последовательности:

  1. node=xcatdefaults postscripts.postscripts
  2. node=xcatdefaults postscripts.postbootscripts
  3. node=<узел/группа> postscripts.postscripts
  4. node=<узел/группа> postscripts.postbootscripts

При загрузке diskless узла выполняется скрипт /etc/init.d/xcatpostinit, который находится в diskless образе. Он загрузит из Managment Node все необходимые к выполнению post-скрипты.

stateless узлы должны иметь установленный пакет openssl (см /opt/xcat/xcatdsklspost).

Во время загрузки stateless узла выполняется скрипт /etc/init.d/xcatpostinit, он выполняет файл /opt/xcat/xcatdsklspost.

/opt/xcat/xcatdsklspost узнает IP DHCP сервера, и считает его за IP Managment Node. Скачивает ftp://IPDHCP/poscripts в /xcatpost.

Используя /xcatpost/getpostscript.awk узел связывается с MN и получает список скриптов которые необходимо выполнить и сохраняет их в /tmp/mypostscrip

Создается файл /opt/xcat/xcatinfo IP MN.

Создается файл /tmp/mypostscript который последовательно выполняет все скрипты.


Statefull

Последовательность:

  1. Инсталятор собирается с пакетом: installer-feature-xCAT-stage3
  2. После установки пакетов выполняется скрипт: 81-xCAT-postinstall.sh
  3. Команда nodeset node15 install на основе шаблонов создаёт xcat-post.sh
  4. 81-xCAT-postinstall.sh запускает в CHROOT установленной системы скрипт xcat-post.sh
  5. Шаблон: /usr/share/xcat/install/scripts/post.alt принадлежит пакету xCAT-server
  6. Модуль alt.pm из шаблона создаёт для каждого узла свой файл /var/lib/xcat/autoinst/node15/xcat-post.sh
  7. Скрипт xcat-post.sh выкачивает из Managnent Node все пост-скрипты и выполняет только те которые заданы в postscripts.postscripts для текущего узла.
  8. Скрипт xcat-post.sh уведомляет Managment Node что установка закончена.
  9. Скрипт xcat-post.sh создает init скрипт который выполнит `postscripts.postbootscripts при первой загрузке.

Discovery

Механизм discovery предназначен для связки MAC-адресс сетевого интерфейса с именем узла. Сам процесс тесно связан с сетевой топологией узлов. В данном примере, рассмотрим случай, когда вычислительные узлы связаны посредством Ethernet протокола.

Добавим свитч и зададим параметры доступа (SNMPv1, community string = public): 

# nodeadd switch1 groups=switches
# chtab node=switch1 hosts.ip="10.2.XX.XX"
# makehosts
# chtab switch=switch1 switches.password=public

Имя switch1 должно резолвится в IP адресс. Каждому узлу соответствует некий порт коммутатора: 

# chtab node=node1 switch.switch="switch1" switch.port="13"

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

# chtab node="real" switch.switch="switch1" switch.port='|\D+(\d+)|($1)|'

При необходимости можно удалить информацию о обнаруженном узле: 

# chtab -d node=node1 mac
# makedhcp -d node1

При успешной идентификации узла xCAT обновляет таблицу mac задаёт дальнейшее действия для опознанного узла согласно таблице chain. 

# tabdump -d chain
 "compute",,,"standby","nodediscover",,

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

# gettab node=node1 nodelist.status
 standingby

В поле chain.chain Возможно задать следующие действия для обнаруженного узла, через запятую: discover, boot or reboot, install or netboot, runcmd=<cmd>, runimage=<image>, shell, standby. Перезагрузим обнаруженный узел: 

# chtab node=node1 chain.chain="reboot"

Чтобы забыть обнаруженный узел: 

# makedhcp -d node1
# chtab -d node=node1 mac

Не идентифицированные ранее узлы:

  • В биосе установлена загрузка через сеть
  • При загрузке узел получают ип адрес от DHCP сервера из диапазона:
# gettab netname=clusterNet networks.dynamicrange
172.16.2.200-172.16.2.250
  • загружают ядро и специальный образ initrd через сеть:
# cat /var/lib/tftpboot/xcat/xnba/nets/172.16.2.0_24

При отсутствии файла /var/lib/tftpboot/xcat/xnba/nets/172.16.2.0_24 он автоматически создаётся командой mknb <ARCH>.

Дополнительную информацию о discovery для сети построенной с использованием свитчей можно получить здесь.

Template records

Все таблицы в базе данных xCAT можно условно разделить на две категории:

  1. которые, определяют параметры узлов. В таких таблицах задаются параметры узла.
  2. которые, хранят параметры, не связанные со свойствами узлов. Значения в таких таких таблицах довольно прямолинейны. Данные сохраняются как есть, без дальнейшей интерпретации и без наследования (например nodehm.power наследуются из nodehm.mgt).

В параметрах узлов, можно использовать шаблоны.

Правила:

  • В поле имя узла можно использовать имя группы. Такая запись будет применяться для всех узлов, состоящих в группе. Когда требуется получить параметр для некого узла, и записи явно для данного узла не существует, тогда берётся соответствующая запись определённая для группы в которую входит данный узел. Если параметры заданы для нескольких групп, в которые входит узел, тогда преимущество отдаётся первой группе указанной в поле nodelist.groups для этого узла.
  • Параметр узла может быть в следующем формате: /pattern/replacement/.

где pattern:

регулярное выражение на языке Perl
применяется к имени узла

Например, дано:

    1. Таблица ipmi
    2. Поле ipmi.node=ipmi
    3. Поле ipmi.bmc установлено в /\z/-bmc/

Тогда, значение поля ipmi.bmc для конкретного узла входящего в состав группы ipmi будет сформировано с добавлением -bmc.

  • В регулярных выражениях, также можно использовать арифметические операции. Синтаксис: |pattern|replacement|. Часть заключённая между скобками () в replacement указывает некое арифметическое действие. Операции выполняются над целыми числами, например 5/4

выдаст 1.

Дано:

    1. имена узлов имеют вид: blade1, blade2...
    2. имена management modules имеют вид: amm1, amm2, ...
    3. таблица mp

Тогда, можно в одну строку записать следующие правило: 

#node,mpa,id,comments,disable
"blade","|\D+(\d+)|amm(($1-1)/14+1)|","|\D+(\d+)|(($1-1)%14+1)|",,

где:

blade - имя группы. В этом примере мы предполагаем что все узлы blade1, blade2... пренадлежат этой группе.

Таблица mp опрашивается когда необходимо получить management module и slot number для конкретного узла (например blade20). Данная строка стработает, поскольку blade20 находится в группе blade.

|\D+(\d+)|amm(($1-1)/14+1)| - выражение замены на языке Perl. Генерит значение для второй колонки mp.mpa. \D+(\d+) - регулярное выражение которое совпадает с именем узла (blade20). Текст совпавший с (\d+) будет назначет $1. В нашем примере \D+ совпадет с не числовой частью имени (blade), и \d+ совпадёт числовой частью имени узла (20). Таким образом, переменная $1 будет равно 20.
amm(($1-1)/14+1) - генерирует строку, которая будет возвращена в качестве значения поля mp.mpa для узла node1. Поскольку $1 равно 20 выражение ($1-1)/14+1 равно 19/14 + 1 = 2. Т.е. строка amm2 будет использована как значение поля mp.mpa.
|\D+(\d+)|(($1-1)%14+1)| - подобно предыдущему выражению, эта замена будет создавать значение для третей колонки mp.id.

Выражение ($1-1)%14+1 приймет значение 6.

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

Левая часть выражения указывает как получить номер из имени узла, заключая нужную часть в скобки. Права часть может выполнять необходимые арифметические операции над извлечённым числом.

"userbmc","|\D+(\d+).*$|172.29.4.($1)|",,,

Мониторинг

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

Список доступных модулей можно посмотреть следующей командой: 

# monls -a
snmpmon         monitored
xcatmon         not-monitored
pcpmon          not-monitored
gangliamon      not-monitored

Получить информацию о каждом модуле в отдельности можно командой: 

# monls -d xcatmon
xcatmon         not-monitored
  Description:
    xcatmon uses fping to report the node liveness status and update the ...

Используемые таблицы:

  1. monitoring
    • подключён модуль
    • используется \ не используется модуль (поле disabled)
    • используется ли отслеживания активности вычислительных узлов (поле nodestatmon)
  1. monsetting - содержит специфические настройки в отдельности для каждого модуля

Более детальную информацию можно узнать из: официального источника

xcatmon

Рассмотрим на примере работу с модулем xcatmon.

1. Узнаем доступные параметры модуля которые задаются при регистрации. 

# monls -d xcatmon
...
 Support node status monitoring:
   Yes

Видем что модуль xcatmon позволяет использовать опцию -n.

2. Зарегистрируем модуль: 

# monadd xcatmon -n -s ping-interval=4

3. Проверим что: модуль xcatmon зарегистрирован для отслеживания состояния узлов, но не активный (disable=1): 

# tabdump monitoring
#name,nodestatmon,comments,disable
"xcatmon","Y",,"1"

4. Параметры с которыми зарегистрирован модуль: 

# tabdump monsetting
#name,key,value,comments,disable
"xcatmon","ping-interval","4",,

5. О дополнительных параметрах для модуля xcatmon можно узнать из страницы руководства: 

# man nodestat

6. Чтобы начать мониторинг: 

# monstart xcatmon

После чего будет автоматически добавлена строка для cron: 

# crontab -l
*/6 * * * * XCATROOT=/usr PATH=/sbin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin XCATCFG= /usr/bin/nodestat all -m -u -q

7. При выключенном узле node1 получим: 

# tabdump nodelist
#node,groups,status,appstatus,primarysn,comments,disable
"node1","real,all","noping",,,,

при включённом: 

# tabdump nodelist
#node,groups,status,appstatus,primarysn,comments,disable
"node1","real,all","ping","xend=down,sshd=up,pbs=down",,,

8. Чтобы настроить проверку других служб на узлах следует отредактировать таблицу monsetting.

9. Приостановить работу модуля xcatmon можно: 

# monstop xcatmon
mn.cluster: stopped.
# crontab -l

Синхронизация файлов

Основной документ: xCAT2SyncFilesHowTo.pdf, man xdcp

Команда xdcp позволяет производить синхронизацию файлов с Managment Node на Compute Node, так и в обратном направлении.

Список фалов для синхронизации можно задать для:

  1. Узлов, которые используют один профиль osimage.
  2. Отдельно для одного узла.

Опции для команды xdcp

  1. -F | --File <synclist> - список с файлами.
  2. -i | --rootimg <PATH> - путь к файлам на MN для синхронизации.
  3. -R | --recursive - копирует рекурсивно каталог
  4. -T | --trace - отображать ход копирования
  5. -P | --pull - скопировать с узла
  6. -f | --fanout - максимальное количество одновременных экземпляров scp

Комманда xdcp поддерживает иерархию: 

Managment Node -> Service Node -> Compute Node

Сначала файлы подлежащие синхронизации загружаются на SN (site.SNsyncfiledir), потом на CN.

Команда updatenode -F также поддерживает иерархию узлов. В основе updatenode лежит вызов xdcp.

Для fullstate узлов post-скрипт syncfiles выполняется сразу после установки ОС на узел. Post скрипт syncfiles посылает сообщение к SN или MN, в ответ на которое будет запущена команда xdcp для узла.

Синтаксис файла синхронизации: 

/full/path/of/the/source/file/on/the/MN -> /full/path/of/the/destination/file/on/target/node
/path1/file1 /path2/file2 -> /full/path/of/the/destination/directory

При отсутствии каталога назначения он будет автоматически создан.

Примеры: 

# xdcp -i /install/netboot/fedora9/x86_64/compute/rootimg -F /tmp/myrsync

Установка дополнительного ПО

На Managmeng Node необходимо создать список пакетов, которые необходимо установить.

  1. Для diskless узлов списки с дополнительными пакетами находятся в /var/lib/xcat/custom/netboot/alt/.
  2. Для fullstate узлов списки с именами пакетов находятся в /var/lib/xcat/custom/install/alt/.
  3. Расположение каталога со списками пакетов можно также задать в таблице: linuximage.otherpkglist

Имя файла со списком может иметь вид:

  • <profile>.<os>.<arch>.otherpkgs.pkglist
  • <profile>.<os>.otherpkgs.pkglist
  • <profile>.<arch>.otherpkgs.pkglist
  • <profile>.otherpkgs.pkglist

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

# nodels node1 nodetype.os nodetype.arch nodetype.profile
node1: nodetype.profile: compute
node1: nodetype.arch: x86_64
node1: nodetype.os: alt

Дополнительные пакеты должны размещаться в APT-репозитории. Репозиторий не зависит от используемого профиля: 

# mkdir -p /var/lib/xcat/post/otherpkgs/alt
# genbasedir --create --flat --bloat --progress --topdir=/var/lib/xcat/post/otherpkgs/alt x86_64 xcat
# mkdir /var/lib/xcat/post/otherpkgs/alt/x86_64/RPMS.xcat
# в каталог /var/lib/xcat/post/otherpkgs/alt/x86_64/RPMS.xcat необходимо скопировать RPM пакеты которые планируется установить.

Ответственность замкнутости по зависимостям в каталоге /var/lib/xcat/post/otherpkgs/<os>/<arch> ложится на администратора.

Stateless

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

# updatenode node1 -S
Error: updatenode command does not support software maintenance to diskless node.

Steteful

Выполнение скриптов

Из Managment Node на заданном noderange можно выполнить скрипт. Для этого необходимо:

  1. на MN скопировать скрипт в /var/lib/xcat/postscripts/
  2. updatenode <noderange> <script>

Востановление БД

Все настройки xCAT хранятся в Базе Данных /etc/xact/###.sqlite.

Рабочую конфигурацию xCAT можно сохранить командой: 

# mkdir /tmp/backup
# dumpxCATdb -p /tmp/backup

Восстановить сохраненные настройки можно командой: 

# restorexCATdb -p /tmp/backup

Можно сохранить только одну таблицу из БД. Например чтобы сохранить таблицу site: 

# tabdump site > /install/dbbackup/site.csv

Чтобы восстановить таблицу: 

# tabrestore /install/dbbackup/site.csv


Service Node

Сокращения:

  • MN - Managment Node. Центральный управляющий узел. В одном экземпляре на весь кластер.
  • SN - Service Node. Вспомогательный управляющий узел. Несколько на весь кластер.
  • CN - Compute Node. Вычислительный узел. Как правило много.

xCAT позволяет создавать к дополнении к главному управляющему узлу MN вспомогательные узлы SN. SN управляют и производят установку Linux для отдельных групп вычислительных узлов.

  • Чтобы узел работал как Management Node необходимо установить пакет xCAT.
  • Чтобы узел работал как Service Node необходимо установить meta-пакет xCATsn.

%VERSION устанавливаемых RPM пакетов xCAT и xCATsn должны совпадать.

Модули xCAT определяют тип узла по наличию файла: /etc/xCATMN или /etc/xCATSN.

Существует два режима для функционирования SN:

  • Каждый отдельный SN узел отвечает за свою группу CN узлов.
  • Пул SN узлов, которые совместно обслуживают CN. Любой SN из множества может обработать поступивший запрос.

По умолчанию MN использует БД SQLite. БД SQLite не умеет работать с удалёнными клиентами. Для построения распределённого кластера с использованием SN надо мигрировать с SQLite на другую БД. На MN следует установить одну из следующих БД:

  • MySQL
  • PostgreSQL
  • IBM DB2

Каждая из этих БД, в отличии от SQLite, умеет работать с удалёнными клиентами. SN узлы будут выступать клиентами к этим БД.

Настройка каждой их этих БД имеет определённые свои особенности. Более детально о настройке каждой БД можно узнать на официальной странице c документацией xCAT.

Конфигурация MySQL

На Managment Node следует установить RPM пакеты c MySQL сервервером. Установка, первый запуск MySQL сервера и базовая настройка: 

# apt-get install MySQL-server MySQL-client perl-DBD-mysql mysql-connector-odbc
# service mysqld start
# mysql_secure_installation
# chkconfig mysqld on

Необходимая информация:

  1. Имя узла Managment Node: mn.cluster
  2. База данных xCAT: xcatdb
  3. Имя пользователья для доступа к базе данных xCAT: xcatadmin
  4. Пароль пользователя xcatadmin: pass123

Настройка сервера MySQL в ALT Linux осуществляется в файле: /var/lib/mysql/my.cnf. Все Service Node узлы должны иметь удалённый доступ к БД. Для этого нужно закомментировать строку skip-networking. 

# /usr/bin/mysql -u root -p
mysql > CREATE DATABASE xcatdb;
mysql> CREATE USER xcatadmin IDENTIFIED BY 'pass123';
mysql> GRANT ALL on xcatdb.* TO xcatadmin@mn IDENTIFIED BY 'pass123';
mysql> GRANT ALL on xcatdb.* TO xcatadmin@mn.cluster IDENTIFIED BY 'pass123';
mysql> GRANT ALL on xcatdb.* TO xcatadmin@sn1 IDENTIFIED BY 'pass123';
mysql> GRANT ALL on xcatdb.* TO xcatadmin@sn1.cluster IDENTIFIED BY 'pass123';
mysql> GRANT ALL on xcatdb.* TO xcatadmin@'%.cluster' IDENTIFIED BY 'pass123';
mysql> GRANT ALL on xcatdb.* TO xcatadmin@'8.113.33.%' IDENTIFIED BY 'pass123';
mysql> GRANT ALL on xcatdb.* TO xcatadmin@127.0.0.1 IDENTIFIED BY 'pass123';
mysql>  SELECT host, user FROM mysql.user;
+-------------+-----------+
| host        | user      |
+-------------+-----------+
| %           | xcatadmin | 
| %.cluster   | xcatadmin | 
| localhost   | root      | 
| mn          | xcatadmin | 
| mn.cluster  | xcatadmin | 
| sn1         | xcatadmin | 
| sn1.cluster | xcatadmin | 
+-------------+-----------+
7 rows in set (0.00 sec)
mysql > SHOW VARIABLES;
mysql > SHOW DATABASES;
mysql > use xcatdb;
mysql > SHOW TABLES;

mysql > DESCRIBE

; mysql > quit; Для безопасности можно сделать резервную копию настроек xCAT: # mkdir backup # dumpxCATdb -p backup Файл содержит параметры доступа к БД. # echo 'mysql:dbname=xcatdb;host=mn.cluster|xcatadmin|pass123' > /etc/xcat/cfgloc # chmod 0600 /etc/xcat/cfgloc Загрузить сохраненные настройки xCAT в базу MySQL, напрямик, без использования xcatd демона. # XCATBYPASS=1 restorexCATdb -p backup # service xcatd restart После настройки БД на MN следует разрешить доступ для удалённых клиентов. Данная процедура специфична для каждой БД: .

mysqlsetup

Чтобы упростить миграцию от SQLite можно использовать утилиту mysqlsetup.

  1. service mysqld stop
  2. service xcatd start
  3. mysqlsetup -i

Если команда завершилась неудачно, необходимо отменить ее недоделанную работу: 

# mysql -u root -p mysql
> show databases;
> show tables;
> select User,Host FROM user;
> DELETE from user where User = 'xcatadmin';
> drop database xcatdb;
> flush privileges;
> quit;
# rm -f /etc/xcat/cfgloc
# service xcatd restart # вернулись на SQLite
# mysqlsetup -i

Необходимо указать явно из каких адресов имеет право авторизироваться пользователь xcatadmin (Service Nodes). Для этого необходимо создать файл со списком разрешённых хостов: 

# cat allowed_hosts
node1
1.115.85.2
10.%.%.%
nodex.cluster.net

# mysqlsetup -u -f allowed_hosts -V
# chkconfig mysqld on

refcard

Managment узел

Для последующих настроек необходимо знать на какое имя выписан сертификат MN: 

# openssl x509 -text -in /etc/xcat/cert/server-cert.pem -noout|grep Subject:
 this will display something like:
 Subject: CN=mn.cluster

Обновим таблицу policy: 

# chtab priority=5 policy.name=<mn.cluster> policy.rule=allow

В итоге таблица policy должна содержать: 

#priority,name,host,commands,noderange,parameters,time,rule,comments,disable
"1","root",,,,,,"allow",,
"2",,,"getbmcconfig",,,,"allow",,
"3",,,"nextdestiny",,,,"allow",,
"4",,,"getdestiny",,,,"allow",,
"5","mn.cluster",,,,,,"allow",,

Необходимые значения для таблицы site: 

#key,value,comments,disable
"xcatiport","3002",,
"xcatdport","3001",,
"master","mn.cluster",,

Значание "master","mn.cluster" - это имя хоста под которым известен MN для SN.

Service узлы

xCAT предоставляет возможность устанавливать и настраивать Service Nodes непосредственно из Managment Node. Добавим два Service узла: 

# nodeadd sn[1-2] groups=all,service

Service узлы должны быть соединены с Managment узлом. От вычислительных узлов требуется чтобы они были соединены только со своим Service узлом. Прямой доступ к Managment узлу для Compute узлов не требуется.

Для удобства можно все Service узлы занести в группу service. В дальнейшем это позволит обновить все Service узлы указав группу service.

В таблице nodetype необходимо задать имя профиля для Service узлов: 

# chdef -t group -o service arch=x86_64 os=alt nodetype=osi profile=service
# tabdump nodetype
#node,os,arch,profile,provmethod,supportedarchs,nodetype,commee
"service","alt","x86_64","service",,,"osi",,

В таблице servicenode указываются:

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

В таблице servicenode ДОЛЖНЫ быть перечислены ВСЕ Service узлы, даже если они не будут выполнять никаких служб. По умолчанию xCAT подразумевает служба на данном Service отключена (0 или no).

При запуске xcatd сервера на Service узле он обратится к servicenode таблице, чтобы узнать какие службы должны выполнятся на этом Service узле. Проверка будет происходить каждый раз при перезапуске xcatd службы.

Указать какие службы будут выполняться на Service узле можно с помощью: 

# chdef -t group -o service setupnfs=1 setupnameserver=1 setuptftp=1

данная команда внесет изменения в таблицу servicenode.

Настройку Service узлов выполняют post-скрипты: 

# chdef -t group -o service postscripts=servicenode,xcatserver,xcatclient

Для корректной работы с Compute узлами необходимо задать два поля в таблице noderes:

  • servicenode - имя Service узла известного со стороны Managment узла
  • xcatmaster - имя Service узда известного для Compute узлов

Т.е. например: 

# chdef -t node -o compute1 servicenode=sn1 xcatmaster=sn1-dmz
# chdef -t node -o compute2 servicenode=sn2 xcatmaster=sn2-dmz
# chdef -t node -o sn1,sn2  servicenode=mn1 xcatmaster=mn
# tabdump noderes
#node,servicenode,netboot,tftpserver,nfsserver,monserver,nfsdir,installnic,primarynic,discoverynics,cmdinterface
"compute1","sn1",,,,,,,,,,"sn1-dmz",,,,,
"compute2","sn2",,,,,,,,,,"sn2-dmz",,,,,
"sn1","mn",,,,,,,,,,"mn",,,,,
"sn2","mn",,,,,,,,,,"mn",,,,,

Укажем что для загрузки Service и Compute узлов будет использоваться pxe (xnba):

  1. chdef -t group -o compute2,compute1,service netboot=pxe

Зафиксировать тот факт, что группа Compute узлов обслуживается несколькими Service узлами, можно: 

# chdef -t node -o compute1 servicenode=sn1,sn2
# chdef -t node -o compute2 servicenode=sn2,sn1

узлы принадлежащее группе compute1 при установке будут использовать sn1. Если sn1 будет недоступен, будет использоваться Service узел sn2. Тоже самое справедливо и для Compute узлов из группы compute2, только в обратном порядке. Поля xcatmaster, tftpserver, nfsserver должны быть пустыми.

На Managment узле следует задать значения для:

  • chtab key=installloc site.value=[hostname:]/install

Если поле hostname отсутствует, тогда будет использовано имя Managment узла. Данная опция говорит что Service узлы будут монтировать себе в каталог /install. Если значение поля installloc не задано, тогда синхронизация каталогов /install Service узлов и Managment узла ложится на плечи администратора.

  • chdef -t site -o clustersite sharedtftp=0

По умолчанию все Service узлы автоматически монтируют tftpboot каталог. Если используются пул из нескольких Service узлов, необходимо отключить авто-монтирование каталога tftpboot. Если Service узел является stateless тогда значение каталога /var/lib/tftpboot будет потеряно при перезагрузке Service узла и прийдеся заново вызывать комманду nodeset для каждого Compute узла.

Для каждого адресного пространства кластера необходимо внести запись в таблицу networks. 

# chtab net=10.3.1.0 networks.netname=public networks.disable=1

Если в сети присутствует пул Service узлов, тогда параметр:

  • net.dhcpserver должен равен одному Service узлу из пула.
  • net.tftpserver - сброшен
  • net.namerserver - сброшен

В настройках Managment узла, для Compute узлов необходимо указать Service узел со службами мониторинга conserver/monserver: 

# chdef -t node -o compute1 conserver=sn1 monserver=sn1

В случае использования пула Service узлов, необходимо явно выбрать некий Service узел, и делегировать ему атрибуты в полях: nodehm.conserver и noderes.monserver.

Service узлы могут быть stateless или statefull.

Stateless Service узлы

Цитата: Service nodes are the same OS and architecture as the management node.

При построении образа для Service узлов используется специальный профиль:

  • service.pkglist. Можно использовать более частный случай: service.<DISTRO>.<ARCH>.pkglist
  • service.otherpkgs.pkglist, или service.<DISTRO>.<ARCH>.otherpkgs.pkglist
  • /usr/xcat/share/xcat/netboot/alt - расположение стандартных списков с пакетами
  • /var/lib/xcat/custom/netboot/alt - в случае необходимости можно разместить изменённый список устанавливаемого ПО.

Репозиторий ALT Linux содержит пакеты xCAT, поэтому отпадает необходимость создавать локальный репозиторий с xCAT пакетами на Managment узле для установки на Service узлах.

Создать stateless образ Service узлов можно коммандой: 

# rm -rf /var/lib/xcat/netboot/alt/x86_64/service
# genimage -i eth0 -o alt -p service
# ls /var/lib/xcat/netboot/alt/x86_64/service
initrd.gz  kernel  rootimg  rootimg.nfs

Загрузить Service узелы: 

# packimage -o alt -p service -a x86_64
# nodeset service netboot
# rpower service boot

Diskfull Service узлы

Установка Diskfull Service узла происходит аналогично установке Diskfull Compute узлу. Отличия будут состоят: в имени профиля, и дополнительных post-скриптах. 

/install/custom/netboot/fedora/service.ferdora8.x86_64.otherpkgs.pkglist -- add xCATsn
# chdef -t group -o service postscripts=otherpkgs,servicenode,xcatserver,xcatclient
# nodeset service install
# rpower service boot

Post-скрипты

На Service-узле должны отработать три post-скрипта:

  • servicenode
    • Налаживает доступ к БД Management узла
    • Вызывает copycerts
    • Создаёт папку с post-скриптами /install/postscripts
    • Закачивает с Managment узла сертификаты/ключи: /etc/xcat/cert/server-cred.pem
    • Создаёт конфигурационный файл доступа к БД на Managеment узле: /etc/xcat/cfgloc
  • xcatserver
    • /etc/xcat/cfgloc
    • /etc/xcat/cert/*
  • xcatclient

/root/.xcat/client-cred.pem /root/.xcat/ca.pem

Проверка

  • После инсталляции профиля Service узла, с Managment node должен быть доступен вход на по ssh, без пароля.
  • На Service узле должен выполняться демон xcatd.
  • Следует убедится что команды tabdump site, nodels могут получить доступ к БД с Service узла.
  • Убедится что на Service узле смонтированы каталоги /var/lib/tftpboot и /var/lib/xcat с Management узла. В случае необходимости.
  • Пароль для пользователя root на Service узлах должен быть равен значению passwd.system
  • Чтобы обновить ключи на Service узлах в группе service достаточно выполнить команду: xdsh service -K
  • Файл /etc/xcat/cfgloc на Service и Managment узлах должен быть одинаковым.
  • Каталог /etc/xcat/cert должен содержать файлы: ca.pem server-cred.pem
  • Каталоги /etc/xcat/ca на Service и Managment узлах должны быть почти одинаковы (см. servicenode post-скрипт).
  • Каталог etc/xcat/hostkeys содержит SSH ключи, которые будут устанавливаться на Compute узлы. Этот каталог должны быть одинаковы на Service и Management узле.


Service Node Pools

По состоянию на Апрель 2010 года, ситуация c Pools не очень ясна. В рассылке говорится о:

  1. скудной документации
  2. не полной поддержке

Особенности:

  • Необходимо спроектировать сеть, так чтобы все Сompute узлы и Service узлы находились в одном адресном пространстве.
  • noderes.xcatmaster - может быть не определено. Тогда перечисленные Service узлы в noderes.servicenode будут обслуживать Compute узлы, внезависимости от того, кто загрузил(pxe) Compute узел.
  • site.dhcpinterfaces должен указывать на сетевые интерфейсы ведущие к Compute узлам, а не интерфейсы соединяющие с Managment узлом.

Пакеты ALT Linux

Клонируем официальный SVN репозиторий себе на локальную машину 

# rsync -av 'xcat.svn.sourceforge.net::svn/xcat/*' .

Исходники для RPM пакетов xCAT ведутся в git репозитории. Импортируем всю историю разработки xCAT в git репозиторий: 

# cat .git/config
  [svn-remote "svn"]
       url = file:///home/stanv/xcat.svn
       fetch = xcat-core/trunk:refs/remotes/trunk
# git svn fetch

Ветка remotes/trunk будет указывать на последний коммит в trunk SVN репозитории.

Ветка master соответствует исходному коду разработчиков, без каких либо изменений. 

# git checkout master
# git merge remotes/trunk

Ветка patches содержит все наработки по адаптированию xCAT для ALT Linux. 

# git checkout patches
# git merge -s subtree master

При наличии конфликтов, исправляем их: 

# git add конфликтыный_файл
# git commit

Втягиваем ветку patches в каждую ветку, отвечающую за отдельный RPM пакет. Например: 

# git checkout perl-xCAT.rpm
# git merge patches # должно проходить гладко

Обновляем SPEC файл. 

# git push --all git.alt:/people/stanv/packages/xcat-core.git

Исходный код xCAT

x=`echo ${x#-}`

string_type=0;  # install rpm

result=`rpm -ev $plain_pkgs_preremove 2>&1`
         echo "$result"
         if [ $? -ne 0 ]; then
               logger "otherpkgs $result"
         fi

chmod +x /tmp/mypostscript.post
if [ -x /tmp/mypostscript.post ];then
 /tmp/mypostscript.post
fi



# This is my comment. There are many others like it, but this one is mine.
# My comment is my best friend. It is my life. I must master it as I must master my life.
# Without me, my comment is useless. Without my comment, I am useless. 
# Jarrod to clean up.  It really should be in Table.pm and support
# the new statelite $table notation.
#I dislike spaces, tabs are cleaner, I'm too tired to change all the xCAT code.
#I give in.



# Универсальность:
           foreach () {
               unlink $_;
           }
           foreach () {
               unlink $_;
           }

# Реальные пацаны используют перл вот так:
       } else {
       use File::Path; 
       mkpath "/var/named/";

# IBM China Software Development Laboratory


NetCAT и awk

Для информации: официальный xCAT использует AWK с поддержкой сетевых сокетов. В ALT Linux AWK собран без поддержки сокетов. После некоторого обсуждения, было решено остановиться на netcat. И заменить строки вида: 

listener = "/inet/tcp/300/0/0"

на 

listener = "netcat -l 300"

Ппосле этого начались проблемы. 

allowcred.awk &
CREDPID=$!
...
kill -9 $CREDPID

Убивает сам скрипт AWK, причем процесс порожденный AWK while ((listener |& getline) > 0) { останется висеть. Пришлось добвить: 

CHLDPID=`pgrep -P $CREDPID`
kill $CHLDPID

Интересное

Две команды: 

# chdef -t group -o diskless -p postscripts=setupntp
# chdef -t node -o diskless -p postscripts=setupntp

Где diskless - имя группы. Тогда первая команда добавит одну запись. Вторая команда добавит для каждого узла состоящего в группе diskless отдельную запись.

/etc/xcat/cfgloc

man mysqlsetup