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

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


Sample Data
Sample Data
 
<pre>
image,file,options,comments,disable
image,file,options,comments,disable
"ALL","/etc/adjtime",,,
"ALL","/etc/adjtime",,,
Строка 511: Строка 511:
"ALL","/var/tmp/",,,
"ALL","/var/tmp/",,,
"ALL","/var/tux/",,,
"ALL","/var/tux/",,,
</pre>
Таблица <tt>litetree</tt>
Во время загрузки узда в statelite режиме он скопирует все свои файлы c tmpfs с root образа в </tt>/.default<tt> каталог.
Есть возможность задать чтобы файлы были вытянуты и других мест, которые отличаются для каждого узла. Например, пользователь может иметь два каталога с различными /etc/motd для каждого месторасположения, в разных языках:
10.0.0.1:/syncdirs/newyork-590Madison/rhels5.4/x86_64/compute/etc/motd
10.0.0.1:/syncdirs/shanghai-11foo/rhels5.4/x86_64/compute/etc/motd
Ты можешь объеденить их в одном каталоге, в таблице <tt>litetree</tt>.
1,,10.0.0.1:/syncdirs/$nodepos.room/$nodetype.os/$nodetype.arch/$nodetype.profile
Также можно для начала проверить наличие файлов в каталогах содержащих в имени имя узла:
$noderes.nfsserver:/syncdirs/$node
В таблице <tt>litetree</tt> места где создаются файлы узлов имеют приоритет. Первое <tt>litetree.priority</tt> поле является приоритетом.
Второе поле <tt>litetree.priority</tt> задаёт имя образа (<tt>ALL</tt> для все образов).
Последние поле <tt>litetree.directory</tt> - точка монтирования.
Например:
1,,$noderes.nfsserver:/statelite/$node
2,,cnfs:/gpfs/dallas/
Два каталога /statelite/$node размещенных на $noderes.nfsserver узла
и /gpfs/dallas размещенный cnfs содержит корень которое разброссано добавленны файлы которые мы хотим разместить на этих узлах.
Если файлы не найдены в первом каталоге, будет осуществлён поиск в следующем каталоге. Если файлы не обнаружены в иерархии litetree, тогда они ищутся в <tt>/.default</tt> на локальном образе.
Место расположение состояния.
Припустим есть необходимость в постоянном хранении некоторых файлов для образа, чтобы они переживали перезагрузку узлов.
Это достигается с помощью задания нужной информации в таблице <tt>statelite</tt>.
#node,image,statemnt,comments,disable
"japan",,"cnfs:/gpfs/state",,,
Все узлы группе japan будут хранить свои состояния в каталоге /gpfs/state на машине с именем cnfs.
Это правило будет применяться ко всем образам, т.е. есть возможность задать что некоторые образа будут хранится в различных местах.
Когда узел загружается, тогда значение поля <tt>statelite.statemnt</tt> будет смонтировано в /.statelite/persistent.
Код потом создаст следующий подкаталог:
/.snapshot/persistent/<nodename>
Этот каталог будет корнем для образа для постоянных файлов.
Замечание: не следует задавать имя каталога для постоянного хранилища после имени узла, так как это будет размещено автоматически. Если всетаки нарушить рекомендацию, тогда каталог с именем /state/n01 будет хранить свое состояние в каталоге /state/n01/n01.


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

Версия от 13:53, 28 января 2010


Установка

После того как завершена установка 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
/tftpboot/xcat/nbk.x86_64
/tftpboot/xcat/nbk.x86
  • Создать initrd с учетом существующих SSL/SSH ключей:
# mknb x86_64
# mknb x86
# ls /tftpboot/xcat/nbfs.x86_64.gz

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

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

Имя 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
# lsdef -t site -l -i domain
 Setting the name of the site definition to 'clustersite'.
 Object name: clustersite
     domain=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 сети

Добавляем сети с которыми будет работать 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"

Часть параметров для узла хранятся в таблице `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

Эта команда пропишет соответствия `имя - IP' в файл для всех узлов заданных в 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

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

# 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

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: пока /tftpboot находится в корне необходимо изменить настройки для atftpd: edit /etc/sysconfig/atftpd : ATFTPD_EXTRA_ARGS="/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

NFS

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

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

HTTP

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

FTP

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

  1. для пользователя vsftpd изменяется домашний каталог на /install
  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

Создадим 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 /install/netboot/alt/x86_64/compute/
initrd.gz
kernel
rootimg/

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

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

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

  • nfs
  • squashfs
  • cpio

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

# nodeset node1 netboot

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

# cat /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 

Внимание: /install/netboot/alt/x86_64/compute/initrd.gz - этот initrd образ, который будет искать и монтировать корневую файловую систему. Но пока мы не скажем: nodeset node1 netboot будет использоваться старый initrd образ: /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

Stateless - statelite

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

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

Можно выделить следующие преимущества statelite по сравнению с stateless:

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

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

  • Изменения к сотне машин можно применить немедленно и автоматически обновляя только одно главное образ.

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

  • Упрощается администрирование, возможность заблокировать образ. Многие части образа предоставляются только на чтение.

Нельзя внести модификацию без обновления главного образа.

  • Администрировать файлы можно в иерархическом порядке. Например.

Имеется: один образ два вычислительных узла, каждый из который использует общий образ в таблице xCAT можно указать разные источники для синхронизации файлов

  • Подходит для виртуализации. В виртуальном окружении использовать образ диска (stateless, stateful) не целесобразно, так как потребляется память и адресное пространство. Виртуализация с statelite позволяет чтобы образ был маленький, упрощенний для управления, меньше дискового пространства, меньше потребляемой памяти, более подвижный (проворный).

Минусы:

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

Разработчики xCAT постарались обрабатывать ясно ошибки, и предоставили средства для отладки, но всегда существуют случаи которые сложны для представления.

Любой statelite образ будет требоваться чтобы некоторые файлы были доступны на чтение/запись для индивидуальных узлов. Потенциально можно предоставить что бы все файлы образа были доступны на запись. Но как правило будут возникать проблемы если многочисленные узлы будут требовать доступ к одном root image и начнут изменять файлы.

managment node хранит все изменения.

Рекомендуется заблокировать главный образ. Образ размещается в /install/netboot/<os>/<arch>/<profile>/rootimg

По умолчанию xCAT во время установки будут созданы на MN запись в /etc/exports что позволит записывать в этот каталог. Желательно изменить эту запись в следующий вид, чтобы можно было только читать файлы:

/install *(ro,no_root_squash,sync)

Перезагрузим службу NFS:

# service nfs restart


2.2 litefile

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

Список файлов будет сохраняться в таблице litefile.

  1. tabdump -d litefile
  2. image,file,options,comments,disable

image:

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

file: - имя файла, с полным путем, если указывается каталог, тогда он должен заканчиваться с / например /etc/hosts options: Задает параметры файла. Возможные пути синхронизации файла

       - <empty>,ALL, or tmpfs.  tmpfs - используется по умолчанию для statelite. Файл будет размещен в tmpfs. Когда будет искаться файл тогда будет использован первый найденный в таблице litetree иерархии. 
       - con - Этот файл доступен на запись который связывается. Содержимое указанного пути соединяется в существующий файл. Для этого типа, поиск в иерархии не остановится при обнаружении первого совпадения. Этот режим подобен tmpfs, но все файлы найденные в иерархии будут обьеденнены когда будут найдены.
       - persistent - Требует точку монтирования для statefull. Подобно tmpfs,rw но будет сохранять сквозь перезагрузки. Если файл отсутствует, он будет автоматически создан во время инициализации. Требует чтобы таблица statelite была заполнена с постоянным хранилищем. Это означает что файл будет устойчивый к перезагрузкам.  Every time there after the file will be left alone if it exists.


       - persistent,con - файл доступные на запись, который в начале будет объединен, и потом будет размещен в постоянной точке монтирования.
       - ro - Файл доступный только на чтение. Это означает что файл будет встроен в некоторое место в иерархию каталогов.

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

Пример данных

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

Sample Data

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

Во время загрузки узда в statelite режиме он скопирует все свои файлы c tmpfs с root образа в /.default каталог. Есть возможность задать чтобы файлы были вытянуты и других мест, которые отличаются для каждого узла. Например, пользователь может иметь два каталога с различными /etc/motd для каждого месторасположения, в разных языках: 10.0.0.1:/syncdirs/newyork-590Madison/rhels5.4/x86_64/compute/etc/motd 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 места где создаются файлы узлов имеют приоритет. Первое 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.

  1. node,image,statemnt,comments,disable

"japan",,"cnfs:/gpfs/state",,,

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

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

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

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

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

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

Список необходимых к выполнению скриптов перечисляется в таблице 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.

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

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

Discovery

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

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

# chtab switch=switch1 switches.password=public

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

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

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

# 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 /tftpboot/xcat/xnba/nets/172.16.2.0_24

При отсутствии файла /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)|",,,

Пакеты 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