XCAT: различия между версиями
Stanv (обсуждение | вклад) Нет описания правки |
|||
Строка 323: | Строка 323: | ||
KERNEL xcat/netboot/alt/x86_64/compute/kernel | 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 | APPEND initrd=xcat/netboot/alt/x86_64/compute/initrd.gz fastboot imgurl=nfs://172.16.2.2/install/netboot/alt/x86_64/compute/rootimg | ||
Команда: | |||
# rnetboot noderange | |||
аналог | |||
# nodeset noderange netboot | |||
# rpower noderange boot | |||
Проверим в каком режиме работает наш узел, после того как загрузится по сети: | Проверим в каком режиме работает наш узел, после того как загрузится по сети: | ||
Строка 340: | Строка 346: | ||
# nodeset node1 install | # nodeset node1 install | ||
# rinstall noderange # | Команда: | ||
# | # rinstall noderange | ||
аналог | |||
# nodeset noderange install | |||
# rpower noderange boot | |||
Комманда <tt>rinstall</tt>: | |||
* вызывает <tt>nodeset</tt> для обновления конфигурационного файла загрузчика | |||
* заставляет узел загрузится | |||
* инициализирует установку. | |||
После завершения установки, должны выполнится ряд <tt>post installation</tt> скриптов. Все post скрипты находятся в каталоге: <tt>$XCATROOT/install/postscripts</tt>. Модифицированные или персональные скрипты должны располагаться в каталоге: <tt>$XCATROOT/install/postscritps/custom</tt>. | После завершения установки, должны выполнится ряд <tt>post installation</tt> скриптов. Все post скрипты находятся в каталоге: <tt>$XCATROOT/install/postscripts</tt>. Модифицированные или персональные скрипты должны располагаться в каталоге: <tt>$XCATROOT/install/postscritps/custom</tt>. |
Версия от 11:26, 18 января 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"
- Пользователю _mknetboot разрешено просматривать таблицы xCAT, но сначала нужно создать сертификат, доказывающий подлинность пользователя:
# /usr/share/xcat/scripts/setup-local-client.sh _mknetboot
- Создать основу initrd образа и ядро для сетевой загрузки (discovery):
# nbcreate -v -a x86_64
будут созданы:
/usr/share/xcat/netboot/x86_64/nbroot_base /tftpboot/xcat/nbk.x86_64
- Создать initrd с учетом существующих SSL/SSH ключей:
# mknb x86_64 # ls /tftpboot/xcat/nbfs.x86_64.gz
Базовая настройка
Имя 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",,,,
Без механизма 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
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
Таблица hodehm
- ipmi - таблица 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 # обновит /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 входит:
- протоколирование активности всех узлов на последовательном порту
- мониторинг текущей ситуации для конкретных узлов
Параметры доступа к последовательному порту задаются в таблице 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
XXX: discovery не работает
# 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
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
Команда:
# rnetboot noderange
аналог
# nodeset noderange netboot # rpower noderange boot
Проверим в каком режиме работает наш узел, после того как загрузится по сети:
# nodestat node1 node1: sshd
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. Значение ключа system ассоциируется с вычислительными узлами.
# nodeset node1 install
Команда:
# rinstall noderange
аналог
# nodeset noderange install # rpower noderange boot
Комманда rinstall:
- вызывает nodeset для обновления конфигурационного файла загрузчика
- заставляет узел загрузится
- инициализирует установку.
После завершения установки, должны выполнится ряд post installation скриптов. Все post скрипты находятся в каталоге: $XCATROOT/install/postscripts. Модифицированные или персональные скрипты должны располагаться в каталоге: $XCATROOT/install/postscritps/custom. На последнем шаге происходит извещение managment node узла о удачной установке, на что MN изменит конфигурационный файл узла для загрузки ОС с локального диска (nodeset <noderange> boot).
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 для сети построенной с использованием свитчей можно получить здесь.
Пакеты 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 pathces # git merge -s subtree master
При наличии конфликтов, исправляем их:
# git add конфликтыный_файл # git commit
Втягиваем ветку patches в каждую ветку, отвечающую за отдельный RPM пакет. Например:
# git checkout perl-xCAT.rpm # git merge patches # должно проходить гладко
Обновляем SPEC файл.