XCAT: различия между версиями
| Строка 11: | Строка 11: | ||
=== Архитектура xCAT === | === Архитектура xCAT === | ||
xCAT 2 – это полностью переработанный xCAT 1.3, | xCAT 2 – это полностью переработанный xCAT 1.3, который содержит множество архитектурных изменений и улучшений функциональности. Все команды являются клиент-серверными (client/server), поддерживают аутентификацию (authenticated), протоколируются (logged) и управляются политиками (policy driven). XCAT 2 поддерживает разграничение прав на основе ролей (roll base authentication, таблица policy управляет полномочиями на выполнение определённых операций xCAT). Клиенты могут работать под управлением любой ОС с поддержкой интерпретатора Perl, включая ОС Windows. Все соединения шифруются при помощи протокола SSL (англ. Secure Sockets Layer (уровень защищённых сокетов) — криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером). Код xCAT 2 полностью переписан на языке Perl, а данные таблиц теперь сохраняются в реляционной базе данных. А благодаря модульной архитектуре, Вы можете выбрать требуемую СУБД: SQLite, MySQL или PostgreSQL. | ||
В клиент-серверном приложении xCAT весь поток между клиентом и сервером контролируется службой xcatd на управляющем узле (Management Node). Когда xcatd получает упакованную как XML команду, он проверяет полномочия отправителя сверяясь | В клиент-серверном приложении xCAT весь поток между клиентом и сервером контролируется службой xcatd на управляющем узле (Management Node). Когда xcatd получает упакованную как XML команду, он проверяет полномочия отправителя, сверяясь со списками контроля доступа (ACL) в таблице политик. Также служба получает информацию о состоянии узлов. За дополнительной информацией обращайтесь к [http://xcat.wiki.sourceforge.net/xCAT+2+Architecture xCAT 2 Architecture]. | ||
xCAT 2 спроектирован для масштабирования в очень больших кластерах. Благодяря поддержке иерархии один управляющий узел может иметь любое количество stateless или statefull сервисных узлов, что повышает производительность и позволяет управлять очень большими кластерами. Все службы кластера такие, как: LDAP, DNS, DHCP, NTP, Syslog и т.д., могут быть автоматически настроены в рамках всего кластера. Исходящие команды управления кластером такие, как: rpower, xdsh, xdcp и т.д., используют эту иерархию для масштабируемого управления системой. | xCAT 2 спроектирован для масштабирования в очень больших кластерах. Благодяря поддержке иерархии один управляющий узел может иметь любое количество stateless или statefull сервисных узлов, что повышает производительность и позволяет управлять очень большими кластерами. Все службы кластера такие, как: LDAP, DNS, DHCP, NTP, Syslog и т.д., могут быть автоматически настроены в рамках всего кластера. Исходящие команды управления кластером такие, как: rpower, xdsh, xdcp и т.д., используют эту иерархию для масштабируемого управления системой. | ||
Версия от 22:03, 31 августа 2010
Обзор xCAT
xCAT (Extreme Cluster Administration Tool) – инструментарий для развёртывания и администрирования больших кластеров.
Ранние версии xCAT использовались для развёртывания и управления множества Linux кластеров начиная с 1999 года. Новая версия xCAT 2.X – это полностью переработанный xCAT, содержащий множество архитектурных изменений и улучшений функциональности.
xCAT – масштабируемый, распределённый инструмент, который предоставляет унифицированный интерфейс для управления аппаратным оборудованием, обнаружением и развёртыванием diskful/diskless операционных систем (ОС). xCAT является программным обеспечением с открытым исходным кодом (http://xcat.sourceforge.net/). Таким образом вы можете беспрепятственно использовать и даже улучшать его.
Архитектура xCAT
xCAT 2 – это полностью переработанный xCAT 1.3, который содержит множество архитектурных изменений и улучшений функциональности. Все команды являются клиент-серверными (client/server), поддерживают аутентификацию (authenticated), протоколируются (logged) и управляются политиками (policy driven). XCAT 2 поддерживает разграничение прав на основе ролей (roll base authentication, таблица policy управляет полномочиями на выполнение определённых операций xCAT). Клиенты могут работать под управлением любой ОС с поддержкой интерпретатора Perl, включая ОС Windows. Все соединения шифруются при помощи протокола SSL (англ. Secure Sockets Layer (уровень защищённых сокетов) — криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером). Код xCAT 2 полностью переписан на языке Perl, а данные таблиц теперь сохраняются в реляционной базе данных. А благодаря модульной архитектуре, Вы можете выбрать требуемую СУБД: SQLite, MySQL или PostgreSQL.
В клиент-серверном приложении xCAT весь поток между клиентом и сервером контролируется службой xcatd на управляющем узле (Management Node). Когда xcatd получает упакованную как XML команду, он проверяет полномочия отправителя, сверяясь со списками контроля доступа (ACL) в таблице политик. Также служба получает информацию о состоянии узлов. За дополнительной информацией обращайтесь к xCAT 2 Architecture.
xCAT 2 спроектирован для масштабирования в очень больших кластерах. Благодяря поддержке иерархии один управляющий узел может иметь любое количество stateless или statefull сервисных узлов, что повышает производительность и позволяет управлять очень большими кластерами. Все службы кластера такие, как: LDAP, DNS, DHCP, NTP, Syslog и т.д., могут быть автоматически настроены в рамках всего кластера. Исходящие команды управления кластером такие, как: rpower, xdsh, xdcp и т.д., используют эту иерархию для масштабируемого управления системой.
Выбор Stateless, Statelite и Stateful
Stateless узлы являются в xCAT 2 важным понятием. Stateless узел – это такой узел, который не имеет постоянно хранящегося на нём "состояния" (изменений конфигурации, обновлений программного обеспечения и т.п.). В кластерах это очень полезно в силу следующих причин:
- Все узлы будут иметь намного большую вероятность оставаться в консистентном состоянии. Если администратор подозревает, что узел находится в несинхронизированном со всем остальным кластером состоянии, он может просто перезагрузить его и быть уверенным, что узел вернётся в своё прежнее, оригинальное состояние.
- При возникновении на узле проблем с оборудованием оно может быть заменено новым, а узел после перезагрузки будет иметь прежнее состояние.
- В provisioning окружении новые узлы могут свободно provisioned или перемещаться без потери статуса.
Для Linux кластеров xCAT 2 предоставляет выбор между stateless и stateful узлами. Stateful узел – это узел с установленной на локальном жёстком диске ОС. На таком узле могут выполняться изменения (изменения конфигурации, обновления программного обеспечения и т.п.), и эти изменения сохраняются на постоянной основе.
Stateless узлы в xCAT 2 характеризуются не только наличием ОС на локальном жёстком диске узла. Существует 3 вида stateless:
- RAM-root – Весь образ ОС находится на RAM файловой системе, которая во время загрузки посылается узлу. Типичный минимальный размер вычислительного узла для Linux составляет 75-160 МБ.
- Compressed RAM-root – Образ ОС является сжатым tar файлом. Отдельные файлы распаковываются и кэшируются во время чтения. Запись осуществляется в кэшированные копии. Типичный минимальный размер вычислительного узла для Linux составляет 30-64 МБ.
- NFS Hybrid – NFS-root с copy-on-write. Узлу посылается минимальное загрузочное ядро, которое в режиме чтения монтирует (NFS) образ ОС на сервере. Чтение файлов кэшируется в памяти. Запись осуществляется в кэшированные копии. Типичный минимальный размер вычислительного узла для Linux составляет 5 МБ.
Statelite (xCAT 2.4 и выше) предоставляет гибкое и эффективное бездисковое решение, т.к. большинство образов ОС монтируется по NFS в режиме только чтение, но настраиваемый список каталогов и файлов может быть доступен в режиме чтения/записи. Файлы, доступные для чтения/записи, при перезагрузке могут оставаться либо в модифицированном состоянии, либо восстанавливаться в своём первоначальном, оригинальном состоянии. У Stateless есть как преимущества, так и недостатки, которые описаны в xCAT Statelite Cookbook.
Указание имени хоста в xCAT
Имена хостов в xCAT не должны содержать символы в смешанном регистре. Сервис разрешения имён (DNS) возвращает все имена в нижнем регистре. Таким образом все имена хостов в xCAT должны указываться в нижнем регистре.
В xCAT предпочтительным способом является использование коротких имён (без домена). Если необходимо использовать длинные имена, тогда нужно создать xCAT "алиас" для узла, указав соответствие длинного имени узла к группе узлов с коротким именем.
Например, запись в таблице узлов может выглядеть так:
"testnode.cluster.net","testnode,compute",,,,,
Лицензия xCAT
Лицензия xCAT 2: Eclipse Public License
Документация xCAT
Документация для xCAT постоянно обновляется. Последняя, обновлённая, официальная документация доступна по адресу http://xcat.svn.sourceforge.net/viewvc/xcat/xcat-core/trunk/xCAT-client/share/doc/index.html
Установка xCAT
Установка на Management Node
Если xCAT не предустановлен в вашей системе, вы можете установить его, выполнив:
# apt-get install xCAT
Будут установлены все пакеты, необходимые для того, чтобы сервер стал управляющим узлом (Management Node).
Установка на Service Node
Как правило, Service узлы устанавливаются из центрального Managment узла. Если же по какой-то причине администратору необходимо установить Service Node вручную, необходимо установить пакет xCATsn:
# apt-get install xCATsn
Установка на Compute Node
Compute узлы устанавливаются исключительно из центрального Managment узла.
Особенности ALT Linux
После того как завершена установка xCAT первый раз, до настройки xCAT, необходимо перерегистрироваться в системе, так как выставляется переменная окружения XCATROOT.
Репозиторий для создания образа ОС
Для обеспечения возможности создания образа ОС, необходимого для загрузки или установки Compute узлов, нужно провести несколько ALT Linux специфических настроек на Management узле:
- Отдельно, для каждой архитектуры создать файл sources.list, в котором указать способ доступа к репозиторию. Например:
# cat /etc/xcat/alt/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/alt/sources.list_x86_64" # chtab key=aptsrclist_x86 site.value="/etc/xcat/alt/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>
Протоколирование (syslog)
При установке RPM пакетов на Management Node происходит настройка службы syslog. Дополнительную информацию можно узнать из: /var/lib/xcat/postscripts/syslog. Архитектура xCAT предполагает что:
- Management Node хранит свои LOG файлы локально.
- Service Node может хранить файлы как локально, так и отсылать своему Management Node. Поведение регулируется установкой параметра site.svloglocal.
- Compute Node отсылает информацию о событиях на хранение Management Node.
SSH ключи
При установке xCAT будут сгенерированы SSH ключи. Авторизованные ключи будут храниться в /var/lib/xcat/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 --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",,,,
Или же, используя шаблон, можно создать, например, следующее правило:
- 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.
При необходимости, можно обновить связку "IP-адрес - Имя узла" только для конкретной группы узлов:
# 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
Указать сразу несколько узлов можно различными способами. Более детально см. страницу руководства "man noderange".
Конфигурация Service Processor
Аппаратная часть вычислительных узлов управляется с помощью 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)
Узнать модель материнской платы, версию BIOS, серийные номера можно с помощью команды:
# rinv bmc1 all bmc1: System Description: S5500BC ...
Снять показания установленных датчиков можно с помощью команды:
# rvitals bmc1 all bmc1: BB +5.0V: 5.016 Volts ...
Временно изменить загрузочное устройство можно с помощью команды:
# rsetboot bmc1 net bmc1: Network
Несколько физических серверов могут управляться одним Service Processor.
Пусть, имеются вычислительные узлы 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-адрес, где работает DNS-сревер BIND, который будет обслуживать имена в рамках xCAT. Обычно такой сервер работает на management node:
# chtab key=nameservers site.value="172.16.2.2"
Все другие запросы по разрешению имён будут перенаправляться на внешний сервер:
# 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
Чтобы проконтролировать результат выполнения команды 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
Service Node
BIND на Service Node:
- настраивается скриптом /usr/sbin/makenamed.conf[.alt].
- работает в качестве кэширующего DNS-сервера, и все запросы пересылает серверам, которые указаны в /etc/resolv.conf
Необходимо позаботится, чтобы для Compute узлов из изолированной сети был виден хотя бы один DNS-сервер, указанный в site.nameservers и при необходимости изменить значение:
chdef -t site -o clustersite -p nameservers=172.16.10.2
Служба 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
Service node
Если установлен флаг servicenode.dhcpserver, тогда Service узел будет иметь свои настройки: /etc/dhcp/dhcpd.conf /var/lib/dhcp/dhcpd/state/dhcpd.leases Например, нужно убедится, что для изолированных сетей параметр option domain-name-servers отличается.
Служба 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.
Служба NFS
Файл /etc/exports автоматически обновляется во время установки xCAT или вызова команды xcatconfig:
$ 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 установки.
- Загрузки XNBA (gpxe) конфигурационных файлов.
Параметры HTTP сервера находятся в файле /etc/httpd2/conf/extra-available/xcat.conf.
Служба FTP
FTP-сервер используется для доступа к postscripts и credentials (открытым ключам пользователя root, и ssh ключа Managment узла). Во время запуска xcatd:
- для пользователя vsftpd изменяется домашний каталог на /var/lib/xcat
- разрешается сервис vsftpd в xinetd
- если сервис xinetd выключен, тогда он включается (модуль AAsn.pm)
Stateless
В странице руководства xCAT упоминается, что stateles образ с необходимым Linux дистрибутивом можно создать лишь на этом же Linux дистрибутиве. Так что, мы не сможем создать stateles образ с Fedora, используя ALT Linux. Для этого понадобится service node, работающий под Fedora Linux. Но все еще остаётся возможность перманентной установки других Linux дистрибутивов для fullstate узлов, используя managment node с ALT Linux.
Для stateless узлов необходимо создать образ, который будет загружаться через сетевое соединение. Образ создается под конкретные специфические нужды. Есть возможность задания списка необходимых устанавливаемых пакетов. Для начала необходимо предоставить 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
Внимание: перед вызовом команды genimage следует убедиться, что в текущий момент отсутствуют работающие stateless узлы. Команда genimage приведет к зависанию всех stateless узлов. Создадим 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
Образ будет создан на основе списка пакетов: /usr/share/xcat/netboot/alt/compute.pkglist Если необходимо внести изменения, тогда измененный список пакетов следует положить в /var/lib/xcat/custom/netboot/alt/compute.pkglist
Образ создаётся с помощью 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
Задавать параметр -i ethN не обязательно. В зависимости от загрузчика XNBA(gpxe), pxelinux.0 будет создаваться конфигурационный файл с параметром IPAPPEND 2. Для загружаемого узла в /proc/cmdline будет передана строка: BOOTIF=00:15:17:bd:97:29. Интерфейс с соответствующим MAC адресом и будет использоваться для дальнейшей загрузки.
Укажем, чтобы узел загрузился по сети в 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:
- Пароль пользователя root буден записан в образ из значений: passwd.system, username=root.
- Будут синхронизированы файлы, перечисленные в /install/custom/<inst_type>/<distro>/<profile>.<os>.<arch>.synclist (см. xCAT2SyncFilesHowTo.pdf).
- Записан скрипт для загрузки post-скриптов /etc/init.d/xcatpostinit.
- Будет обновлена таблица linuximage:
#imagename,template,pkglist,pkgdir,otherpkglist,otherpkgdir,exlist,postinstall,rootimgdir,comments,disable "alt-x86-netboot-compute",,"/usr/share/xcat/netboot/alt/compute.pkglist","/var/lib/xcat/alt/x86",,"/var/lib/xcat/post/otherpkgs/alt/x86","/usr/share/xcat/netboot/alt/compute.exlist",,"/var/lib/xcat/netboot/alt/x86/compute",,
Использование протокола Serial Over Lan
К узлу можно получить доступ через последовательный порт. Для этого обычно используется протокол 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 контроллере также можно задать:
- при discovery узла. runcmd=bmcsetup
- после discovery, выполнив nodeset <node> runcmd=bmcsetup
Параметры BMC описываются в текстовом файле см раздел Nodes.
После загрузки узла hostname будет установлено следуя: RESOLVE_HOSTNAME_COMMAND=/bin/xcathostname из /etc/sysconfig/init (см. исходный код /usr/share/xcat/netboot/alt/genimage).
Statelite
Сокращения
- Образ - image, каталог содержащий NFS root;
- Узел - node, computing node, вычислительный узел;
- Корень - корневая файловая система (обычно подразумевается NFS root);
- Перманентные файлы - которые переживают перезагрузку.
Особенности
- узлы грузятся через сеть;
- в качестве корневой файловой системы выступает NFS;
- есть возможность указать имена файлов, которые будут сохраняться между перезагрузками узлов;
Преимущества
- Образ корневой файловой системы используется совместно многими узлами.
- Заданные файлы сохраняется между перезагрузками узлов. Есть возможность сохранять состояние файлов, например файлы с лицензионными ключами.
- Изменение в работу узлов можно внести немедленно, обновив при этом только один образ. В большинстве случаев, изменения вступают в силу, без перезагрузки вычислительных узлов.
- Упрощается администрирование, так как многие части образа предоставляются только на чтение.
- Файлы можно администрировать в иерархическом порядке. Например, имеется:
- один общий образ
- два узла
тогда в таблице можно указать разные источники для синхронизации файлов.
- Уменьшает потребление системных ресурсов в решениях с использованием виртуализации. Если в 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 для ОС ALT Linux. Приведённый ниже список может быть отправной точкой при заполнении litefile таблицы.
Все файлы будут размещены в tmpfs. Постоянное хранилище для нижележащих файлов отсутствует, что позволяет использовать NFS корень только для чтения.
# tabdump litefile #image,file,options,comments,disable "ALL","/etc/adjtime",,, "ALL","/etc/fstab",,, "ALL","/etc/inittab",,, "ALL","/etc/mtab",,, "ALL","/etc/ntp.conf",,, "ALL","/etc/resolv.conf",,, "ALL","/etc/issue",,, "ALL","/etc/issue.net",,, "ALL","/etc/ssh/",,, "ALL","/tmp/",,, "ALL","/var/cache/",,, "ALL","/var/adm/",,, "ALL","/var/empty/",,, "ALL","/var/db/nscd/",,, "ALL","/var/lib/dhcp/",,, "ALL","/var/lib/dhcpcd/",,, "ALL","/var/lib/logrotate/",,, "ALL","/var/lib/ntp/",,, "ALL","/var/lock/",,, "ALL","/var/log/",,, "ALL","/var/run/",,, "ALL","/var/resolv/",,, "ALL","/var/spool/",,, "ALL","/var/tmp/",,, "ALL","/opt/xcat/",,, "ALL","/xcatpost/",,, "ALL","/etc/sysconfig/",,, "ALL","/etc/syslog.d/",,, "ALL","/etc/syslog.conf",,, "ALL","/home/",,, "ALL","/root/","persistent",, "ALL","/etc/postfix/",,, "ALL","/etc/openssh/",,,
таблица litetree
Назначение таблицы litetree - хранить NFS ресурсы с начальным состоянием файлов из таблицы litefile. Таблица litetree содержит только R/O NFS ресурсы. Таблицу literee заполнять не обязательно, так как отсутствующие файлы будут взяты из каталога /.default. Таблица litetree может задавать несколько источников для файлов. Если файл отсутствует в первом источнике, тогда он будет искаться в другом месте. Если файл не будет найден, тогда он будет скопирован из .default.
# tabdump litetree #priority,image,directory,comments,disable
При загрузке узла в statelite режиме происходит копирование файлов с root образа в /.default каталог (tmpfs). Также существует возможность задать отдельно для каждого узла, откуда следует брать файлы. Например, есть два различных файла /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.priority - задаёт приоритет. Каждое местоположение файла имеет свой приоритет.
- litetree.image - задаёт имя образа (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. Это правило будет применяться ко всем образам. Существует возможность задать различное местоположение хранилища. Нужно убедиться, что для одного узла отсутствуют несколько записей: node1 group_with_node1
Когда загружается узел:
- значение поля 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 образа
Корневая файловая система, созданная командой genimage доступна в /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg. Чтобы внести какие-то изменения и выполнить команды внутри этого дерева можно воспользоваться командой chroot.
Для базовой настройки рабочего образа всё что необходимо - это скопировать некоторые passwd файлы и настройки ssh с xCAT в образ:
# cd /usr/share/xcat/netboot/add-on/statelite # ./add_passwd /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg # ./add_ssh /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg
Команда liteimg
Команда liteimg вносит изменения в statelite образ и создаёт набор ссылок.
Внимание: при обновлении statelite образа необходимо выключить все statelite узлы, использующие этот образ.
Когда внесены все настройки в /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg можно выполнить:
# liteimg <os>-<arch>-<profile> # liteimg alt-x86-statelite-compute # liteimg -p compute -a x86_64 -o alt
Комманда liteimg:
- вносит изменения в statelite образ и создаёт набор ссылок
- делает непригодным diskless образ, т.е. один образ для diskless и statelite режима.
- может обновлять rootimg согласно записям из таблицы litefile
- восстанавливает файлы в начальное состояние, если они были удалены из таблицы litefile
- копирует /usr/share/xcat/netboot/add-on/statelite/rc.statelite в /var/lib/xcat/netboot/alt/x86/compute/rootimg/etc/init.d/.
Команда 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, поскольку файлы и каталоги должны иметь два уровня перенаправления.
Команда packimage для statelite профиля не выполняется.
POST-скрипты
Для statlite режима можно использовать два типа POST-скриптов. Скрипты первого типа:
- исполняются при загрузке узла
- скачиваются с Managment Node
- перечисляются в таблице postscripts
Второй тип скрипта:
- Выполняется на стадии создания образа командой genimage
- Имя скрипта должно совпадать с профилем, на основе которого создается образ. Например: compute.alt.x86.postinstall
- Находится в каталоге /usr/share/xcat/netboot/alt или в каталоге /var/lib/xcat/custom/netboot/alt
- Скрипту передаются следующие аргументы: $rootimg_dir, $osver, $arch, $profile
Установка узла
# nodeset hpc3 statelite=alt-x86-compute или # nodeset cn-1 statelite
Внимание: если раньше для созданного образа вызывалась команда packimage тогда команда nodeset <node> statelite будет создавать конфигурационный файл PXE/XNBA для diskless загрузки. Смотри bugs tracker
данная команда:
- обновит запись в таблице nodetype:
# tabdump nodetype #node,os,arch,profile,provmethod,supportedarchs,nodetype,comments,disable "hpc3","alt","x86","compute","statelite","x86,x86_64",,, "cn-1",,,,"statelite",,,,
- создаст необходимые файлы в каталоге /var/lib/tftpboot для загрузки узла; Будет создан нужный PXE или XNBA файл, так что узел будет загружаться с использованием 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.16.2.2:/var/lib/xcat/netboot/alt/x86_64/compute STATEMNT=cnfs:/gpfs/state XCAT=172.10.0.1:3001 console=tty0 console=ttyS0,115200n8r
Параметр:
- NFSROOT может быть равен noderes.nfsserver, noderes.tftpserver, noderes.xcatmaster.
- STATEMENT равен параметру statelite.statement для даного узла.
- XCAT равен noderes.xcatmaster:site.xcatdport
Параметр NFSROOT задаёт расположение NFS ресурса с корневой файловой системой, доступной только на чтение (/install или же /var/lib/xcat). Поскольку двойное экспортирование (переэкспортирование) NFS ресурса невозможно, Service узлы должны быть diskfull.
Важно держать в актуальном состоянии каталог /var/lib/xcat. Для этого его необходимо синхронизировать с diskfull Service узел с Managment узлом:
# cd / # prsync /var/lib/xcat <sn>:/var/lib/xcat ???
Параметр site.installoc для Service узла не должен установлен в какое-либо значение.
Перезагрузить узел
# rpower <noderange> boot
Для просмотра процесса загрузки можно использовать rcons или wcons.
Команда rpower по умолчанию выполняет указанное действие на всех узлах одновременно. Чтобы избежать пиковой нагрузки, можно задать параметр site.powerinterval, тогда указанное действие для каждого узла будет производится последовательно с некой задержкой.
Команды
- litefile <nodename> - показывает все statelite файлы, которые не берутся с базового образа для данного узла.
- litetree <nodename> - показывает NFS источник с начальным значениями файлов для узла.
- ilitefile <image name> - показывает statelite файлы, актуальные для данного statelite-профиля.
- liteimg <image name> - создаёт набор символических ссылок в образе, которые совместимы с загрузкой statelite.
Структура каталогов statelite
Каждый образ statelite будет иметь следующие каталоги:
/.statelite <-- R/W с файловой системой TMPFS. /.statelite/tmpfs/ <-- Файлы перечисленные в таблице litefile будут замещены ссылками. Эти ссылки будут указывают сюда, на другие ссылки, которые указывают на /.statelite/persistent/<nodename> /.statelite/persistent/<nodename>/ <-- Сюда будет смонтирован NFS ресурс statelite.statemnt для узла statelite.node. /.statelite/mnt/<index>/ <-- Сюда будет смонтированы R/O для litetree.image NFS ресурс litetree.directory /.default/ <-- Каталог с оригинальными файлами из образа, перечисленные в таблице litefile.file /etc/init.d/statelite <-- Файл, который вызывается из initrd, для подготовки statelite файлов.
Значения полей
- 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.
Отладка
При возникновении ошибки, для отладки можно воспользоваться следующими приёмами:
- При загрузке узла вызывается скрипт statelite из корневого каталога: $imgroot/etc/init.d/statelite. Этот скрипт не принадлежит к rc скриптам, а вызывается непосредственно из initramfs образа, до того, как будет вызвана команда chroot в будущий корень системы. В этом скрипте происходит создание ссылок. В начале скрипта есть строка с вызовом set x. Если возникла необходимость просмотреть выполнение действий, можно раскомментировать эту строку. Тогда можно будет увидеть многочисленные вызовы команд для создания каталогов и ссылок.
- При загрузке узла можно получить доступ к shell. Для этого в PXE файл узла можно добавить ключевое слово shell. Тогда скрипт из initramfs сделает несколько остановок прежде чем выполнить switch_root.
- При создании ссылок на узле создается протокол в файле /.statelite/statelite.log
Пример:
# nodeset <node> statelite
Загрузка (цепочка)
Последовательность загрузки statelite-узла:
- Образ создается командой /usr/share/xcat/netboot/alt/genimage
- init для initrd создается на основе /var/lib/_mknetboot/mkimage-profile-diskless/initrd-init.in
- PXE/GPXE конфигурация создается командой nodeset <node> statelite
- По tftp/http загружается initrd и ядро.
- /init
- $NEWROOT/etc/init.d/statelite - файл скопирован genimage из /usr/share/xcat/netboot/add-on/statelite/rc.statelite
- Монтируются все NFS ресурсы из таблиц statelite и litetree
- switch_root
- Загрузка сервиса /etc/init.d/xcatpostinit.alt - файл скопирован genimage из /var/lib/xcat/postscripts/xcatpostinit.alt
- /opt/xcat/xcatdsklspost - загружает с Managment Node все POST-скрипты в /xcatpost
- Выполнение POST-скриптов из таблицы postscripts
Statefull - вычислительный узел
Скопируем установочный CD. На основе этого CD будет создаваться statefull система:
# copycds -n alt -a x86_64 /build/lioka/skif/altlinux-skif-x86_64-20091204.iso
Результатом выполнения этой команды будет запись в таблице linuximage:
# tabdump linuximage #imagename,template,pkglist,pkgdir,otherpkglist,otherpkgdir,exlist,postinstall,rootimgdir,comments,disable "alt-x86_64-install-compute","/usr/share/xcat/install/alt/compute.tmpl",,"/var/lib/xcat/alt/x86_64",,"/var/lib/xcat/post/otherpkgs/alt/x86_64",,,,,
На каждом узле заводится локальный аккаунт администратора (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
В случае noderes.netboot == pxe будет создан конфигурационный файл:
# cat /var/lib/tftpboot/pxelinux.cfg/node1 #install alt-x86_64-compute DEFAULT xCAT LABEL xCAT KERNEL xcat/alt/x86_64/vmlinuz APPEND initrd=xcat/alt/x86_64/full.cz automatic=method:http,interface:eth0,network:dhcp,server:172.16.2.2,directory:/install/alt/x86_64 ai xcat curl=http://172.16.2.2/install/autoinst/node1/ ramdisk_size=165536 noipv6 IPAPPEND 2
Для отладки хода установки можно добавить опцию instdebug в /proc/cmdline.
Пакетная база на установленном Statefull Compute Node соответствует стандартной установке дистрибутива. Если требуется установить дополнительные пакеты в момент установки (работы инсталлятора) создайте файл со списком пакетов:
/var/lib/custom/install/alt/<profile>.[alt].[<arch>].installer.pkglist или в /usr/share/xcat/install/alt/<profile>.[alt].[<arch>].installer.pkglist
Внимание: пакеты должны быть доступны на установочном CD. В случае отсутствия хотя бы одного пакета все перечисленные пакеты не будут установлены.
Для любопытных
Последовательность действий при авто-установке:
- nodeset node1 install - эта команда создаст:
- PXE конфигурационный файл для узла node1.
- каталог /var/lib/xcat/autoinst/node1. Содержимое каталога: autoinstall.scm root.pub xcat-post.sh xcat-pre.sh
- Через PXE конфиг в /proc/cmdline передается пераметр ai
- Установщик запускает скрипт 20-metadata-autoinstall.sh
- Вызывается cp-metadata для autoinstall.scm и vm-profile.scm
- cp-metadata - скрипт, который читает /proc/cmdline на предмет опции curl=http://172.....
- Из указанного адреса curl=http://172..... скрипт cp-metadata выкачивает файлы: autoinstall.scm и vm-profile.scm
- Файлы autoinstall.scm и vm-profile.scm содержат инструкции и параметры для конкретного узла о том, как проводить авто-установку. Генерируются модулем /usr/lib/perl5/vendor_perl/xCAT_plugin/alt.pm
- Файл autoinstall.scm создаётся на основе текущего профиля узла, например из /usr/share/xcat/install/alt/compute.tmpl
- Файл vm-profile.scm - профиль для alterator-vm. Можно поместить в каталог /usr/share/xcat/install/alt/. Смотри пример /var/lib/xcat/alt/x86_64/Metadata/vm-profile.scm
- После установки пакетов выполняется скрипт: 81-xCAT-postinstall.sh
- Скрипт cp-metadata скачивает xcat-post.sh из адреса: curl=http://172.16.2.2/install/autoinst/node1/
- xcat-post.sh создаётся на основе /usr/share/xcat/install/scripts/post.alt. См. модуль: /usr/lib/perl5/vendor_perl/xCAT_plugin/alt.pm
- Далее происходит скачивание и выполнение скриптов из таблицы postscripts для узла node1.
Команда:
# 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).
- При завершении установки выполняются скрипты, указанные в postscripts.postscripts
- После установки Statefull узла при первой загрузке выполняется скрипт /etc/init.d/xcatpostinst.alt
- Скрипты, которые необходимо выполнить при первой загрузке узла указываются в postscripts.postbootscripts
- Список скриптов из postscripts.postbootscripts сохраняется в файле: mypostscript.pos
- Ввиду того, что каталог /tmp в ОС ALT Linux может очищаться при перезагрузке, скрипт mypostscript.pos сохраняется в /var/lib/xcat/mypostscript.post
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), рекомендуется заранее убедится в их корректности. Неправильные скрипты могут быть причиной сбоя установки.
- Для diskful узлов postscripts будут выполнены после того как пакеты установлены, но до того как последует перезагрузка.
- Для 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'
При запуске на вычислительном узле отправляет все сообщения на Managеment Node:
# cat /etc/syslog.conf # xCAT settings # *.* @172.16.2.2
При выполнении post скрипта на узле передаётся набор переменных:
- MASTER - откуда будет грузится данный узел (service node или managеment node)
- NODE - имя текущего узла
- OSVER, ARCH, PROFILE - атрибуты узла из таблицы nodetype
- NODESETSTATE - аргумент, переданный при вызове nodeset команды для текущего узла.
- NTYPE - "service" или "compute"
- Все атрибуты из таблицы site
Stateless
Узлы работающие в stateless режиме используют общий образ. Во время загрузки любого diskless узла будут выполнены скрипты в такой последовательности:
- node=xcatdefaults postscripts.postscripts
- node=xcatdefaults postscripts.postbootscripts
- node=<узел/группа> postscripts.postscripts
- node=<узел/группа> postscripts.postbootscripts
При загрузке diskless узла выполняется скрипт /etc/init.d/xcatpostinit, который находится в diskless образе. Он загрузит из Managеment 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</tt,> который последовательно выполняет все скрипты.
Statefull
Последовательность:
- Инсталятор собирается с пакетом: installer-feature-xCAT-stage3
- После установки пакетов выполняется скрипт: 81-xCAT-postinstall.sh
- Команда nodeset node15 install на основе шаблонов создаёт xcat-post.sh
- 81-xCAT-postinstall.sh запускает в CHROOT установленной системы скрипт xcat-post.sh
- Шаблон: /usr/share/xcat/install/scripts/post.alt принадлежит пакету xCAT-server
- Модуль alt.pm из шаблона создаёт для каждого узла свой файл /var/lib/xcat/autoinst/node15/xcat-post.sh
- Скрипт xcat-post.sh выкачивает из Managnent Node все пост-скрипты и выполняет только те, которые заданы в postscripts.postscripts для текущего узла.
- Скрипт xcat-post.sh уведомляет Managment Node об окончании устновки.
- Скрипт 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
Неидентифицированные ранее узлы:
- В BIOS установлена загрузка через сеть
- При загрузке узел получают IP адрес от 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 можно условно разделить на две категории:
- таблицы, которые определяют параметры узлов. В таких таблицах задаются параметры узла.
- таблицы, которые хранят параметры, не связанные со свойствами узлов. Значения в таких таких таблицах довольно прямолинейны. Данные сохраняются как есть, без дальнейшей интерпретации и без наследования (например, nodehm.power наследуются из nodehm.mgt).
В параметрах узлов, можно использовать шаблоны.
Правила:
- В поле имя узла можно использовать имя группы. Такая запись будет применяться для всех узлов, состоящих в группе. Когда требуется получить параметр для некого узла, и записи явно для данного узла не существует, тогда берётся соответствующая запись определённая для группы, в которую входит данный узел. Если параметры заданы для нескольких групп, в которые входит узел, тогда преимущество отдаётся первой группе указанной в поле nodelist.groups для этого узла.
- Параметр узла может быть в следующем формате: /pattern/replacement/.
где pattern:
- регулярное выражение на языке Perl
- применяется к имени узла
Например, дано:
- Таблица ipmi
- Поле ipmi.node=ipmi
- Поле ipmi.bmc установлено в /\z/-bmc/
Тогда значение поля ipmi.bmc для конкретного узла, входящего в состав группы ipmi, будет сформировано с добавлением -bmc.
- В регулярных выражениях также можно использовать арифметические операции. Синтаксис: |pattern|replacement|. Часть заключённая между скобками () в replacement указывает некое арифметическое действие. Операции выполняются над целыми числами. Например, 5/4
выдаст 1.
Дано:
- имена узлов имеют вид: blade1, blade2...
- имена management modules имеют вид: amm1, amm2, ...
- таблица 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)|",,,
prescripts
Таблица prescripts позволяет задавать список скриптов, которые необходимо выполнить на узле.
# tabdump prescripts #node,begin,end,comments,disable
- Синтаксис полей prescripts.begin и prescripts.end одинаковый.
- [action1:]s1,s2...[|action2:s3,s4,s5...], где:
- s1,s2,s3,... - это имена скриптов.
- action1, action2 - второй аргумент команды nodeset
- Скрипты в поле beign выполняются до установки.
- Скрипты в поле end выполняются после установки.
- Все скрипты должны быть в каталоге /site.installdir/prescripts.
- Каждому скрипту во время выполнения передаются следующие переменные:
- NODES - спискок узлов, через запятую, на которых этот скрипт будет выполняться
- ACTION - в каком режим выполняется узел: install, netboot (см команду nodeset).
В теле скрипта можно указать строку: #xCAT setting:MAX_INSTANCE=number. Тогда скрипт может выполняться параллельно не более чем на number узлах.
Безопасность
Таблица auditlog
Все действия, которые проходят проверку на права доступа, записываются в таблицу auditlog.
# tabdump auditlog "2341","04-13-2010 20:55:52",,"sn2","other","getpostscript",,,"Allowed",, "2347","04-13-2010 20:55:59",,"sn2","other","getcredentials",," xcat_client_cred","Allowed",, "2348","04-21-2010 23:03:36","root","localhost.localdomain","cli","tabdump",," prescripts","Allowed",,
Администратор может указать в поле site.auditskipcmds команды через запятую, для которых нет необходимости вести протоколирование:
# chtab key=auditskipcmds site.value="tabdump,nodels,lsdef"
Данная команда отключает протоколирование для команд: tabdump,nodels,lsdef
Таблица eventlog
Хранит события, полученные мониторами.
# tabdump eventlog #recid,eventtime,eventtype,monitor,monnode,node,application,component,id,severity,message,rawdata,comments,disable
tabprune - удаляет записи из таблиц auditlog и eventlog.
Вызвать команду tabedit для таблиц auditlog и eventlog не получится, так как будет нарушен индекс.
Динамические группы
Исходя из некоторых свойств узла, он автоматически добавляется в группы. Принадлежность узла к группе основана на неких характеристиках узла.
Есть следующие таблицы:
- nodelist - статическая принадлежность узла к группе. Задаёт администратор.
- nodegroup - динамическая принадлежность узла к группе. Узел заносится автоматически на основании неких свойств узла.
Операции над динамическими группами можно условно разделить на две части:
- create/delete (tabedit), display (tabdump), modify (chtab)
- Передавать имя динамической группы в качестве аргумента для любой команды xCAT.
Например:
# chtab groupname=grp1 nodegroup.grouptype=dynamic nodegroup.wherevals="mgt=hmc,hcp=c76v1hmc04"
Создаёт/изменяет динамическую группу grp1. К этой группе будут относится узлы, у которых:
- mgt=hmc
- hpc=c76v1hmc04
Для просмотра всех возможных атрибутов узла, по которым можно задавать их принадлежность к динамической группе:
# chdef -h -t node
Команды:
- mkdef - позволяет создать динамическую группу указав флаг -d | --dynamic
- chdef - изменят свойства динамической группы. Для каждого ключа -w можно задать пару АТРИБУТ_УЗЛА и ЗНАЧЕНИЕ.
- Соотношения между АТРИБУТ_УЗЛА и ЗНАЧЕНИЕ задается операторами: == =~ != !~
Следует заметить о возможных конфликтах. Когда узел относится к динамической группе, согласно некоторым критериям, тогда, невозможно добавить данный узел в эту же группу статически.
Мониторинг
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 ...
Используемые таблицы:
- monitoring
- подключён модуль
- используется \ не используется модуль (поле disabled)
- используется ли отслеживание активности вычислительных узлов (поле nodestatmon)
- 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
Синхронизация файлов
Справочная информация:
- [1] xCAT2SyncFilesHowTo.pdf
- man xdcp
- man updatenode
Команда xdcp позволяет производить синхронизацию файлов как с Managеment Node на Compute Node, так и в обратном направлении.
Список фалов для синхронизации можно задать для:
- Узлов, которые используют один профиль osimage.
- Каждого узла в отдельности.
Опции для команды xdcp
- -F | --File <synclist> - список с файлами.
- -i | --rootimg <PATH> - путь к файлам на MN для синхронизации.
- -R | --recursive - копирует рекурсивно каталог
- -T | --trace - отображать ход копирования
- -P | --pull - скопировать с узла
- -f | --fanout - максимальное количество одновременных экземпляров scp
Комманда xdcp поддерживает иерархию:
Managеment Node -> Service Node -> Compute Node
Сначала файлы подлежащие синхронизации загружаются на SN (site.SNsyncfiledir), потом на CN.
Принудительно синхронизировать файлы можно, вызвав команду
updatenode <noderange> -F -V
Команда updatenode также поддерживает иерархию узлов. В основе updatenode лежит вызов xdcp.
Для fullstate узлов post-скрипт syncfiles выполняется сразу после установки ОС на узел. Список файлов для синхронизации перечисляется в /var/lib/xcat/custom/<install|netboot>/alt/<profile>.<os>.<arch>.synclist 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
Команда psh - позволяет выполнить команду параллельно на нескольких узлах. Команда xdsh - ???
# xdsh -e u /var/xvat/syncfiles
Установка дополнительного ПО
На Managеment Node необходимо создать список пакетов, которые необходимо установить.
- Для diskless узлов списки с дополнительными пакетами находятся в /var/lib/xcat/custom/netboot/alt/.
- Для fullstate узлов списки с именами пакетов находятся в /var/lib/xcat/custom/install/alt/.
- Расположение каталога со списками пакетов можно также задать в таблице: 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
# updatenode <noderange> -P otherpkgs равноценно: (из updatenode.pm) XCATBYPASS=Y $::XCATROOT/bin/xdsh $nodestring -s -e $installdir/postscripts/xcatdsklspost $mode -M $snkey otherpkgs 2>&1 # updatenode <noderange> -S равноценно (из updatenode.pm) XCATBYPASS=Y $::XCATROOT/bin/xdsh $nodestring -s -e $installdir/postscripts/xcatdsklspost 2 -M $snkey otherpkgs 2>&1
xcatdsklspost:
- сделает запрос к Management Node (xcatd)
- будет вызвана часть xcatd - getpostscript.pm -> Postage.pm
- сервер xcatd сгенерит и передаст его post-script вычислительному узлу.
- xcatdsklspost сохранит его под именем/tmp/mypostscript.
Внутри этого скрипта будут определены переменные:
- $OTHERPKGS<N> - поле linuximage.otherpkglist - указывает на список дополнительных пакетов. Этот список может включать другие списки.
- $OTHERPKGS_INDEX - сколько списков пакетов получилось в итоге после того, как были обработаны все включенные списки.
- $OHTERPKGSDIR - равно полю linuximage.otherpkgdir
- Будет вызван сам скрипт otherpkgs[.alt]
Установка ПО на работающем fullstate узле
Внимание: этот метод установки дополнительного ПО не официальный, и подходит только для дистрибутивов ALT Linux.
Первый шаг - на Managment Node нужно создать sources.list для Compute узлов.
Для каждой отдельной архитектуры и версии ALT Linux создается свой sources.list. Информацию по написанию sources.list файлов можно получить из страницы руководства:
# man sources.list
Примерное содержимое sources.list:
# cat /etc/xcat/alt/nodes/sources.list_x86_64 rpm ftp://server/Sisyphus x86_64 classic rpm ftp://server/Sisyphus noarch classic
Важно убедится, что Compute узлы имеют доступ к серверу salto. Возможен случай, что Compute Node монтируют NFS-ресурс, тогда sources.list можно переписать как:
rpm file:/mnt/server/Sisyphus x86_64 classic rpm file:/mnt/server/Sisyphus noarch classic
Второй шаг - указать, куда поместить созданный sources.list на Compute узлах:
# cat /var/lib/xcat/custom/install/alt/kvm.alt.x86_64.synclist /etc/xcat/alt/nodes/sources.list_x86_64 -> /etc/apt/sources.list.d/xcat.list
Третий шаг - поместить на нужные Compute узлы созданный sources.list. Это можно сделать двумя способами:
- Если имя synclist соответствует используемому профилю узлов:
# updatenode <noderange> -V -F
- Для любой группы узлов
# xdcp <noderange> -F /var/lib/xcat/custom/install/alt/kvm.alt.x86_64.synclist
(на MN см.: # cat /tmp/rsync_hpc3)
Четвёртый шаг - создать список дополнительных пакетов, согласно используемому профилю:
/usr/share/xcat/install/alt/kvm.otherpkgs.pkglist
В списке можно использовать макросы:
Рекурсивно включить другой список пакетов
#INCLUDE:/usr/share/xcat/install/alt/other#
Установить нижележащие пакеты отдельным шагом
#NEW_INSTALL_LIST#
Пятый шаг - указать для нужного профиля список дополнительных пакетов в linuximage.otherpkglist, причём поле linuximage.otherpkgdir можно оставить незаполненным.
# gettab imagename=alt-x86_64-install-kvm linuximage.otherpkglist /usr/share/xcat/install/alt/kvm.otherpkgs.pkglist
Шестой шаг - выполнить для нужных Compute узлов post-скрипт otherpkgs.
# updatenode <noderange> -P otherpkgs
или
# updatenode <noderange> -S
(на CN см.: # cat /tmp/mypostscript)
Выполнение скриптов
Из Managment Node на заданном noderange можно выполнить скрипт. Для этого необходимо:
- на MN скопировать скрипт в /var/lib/xcat/postscripts/
- updatenode <noderange> <script>
Востановление БД
Все настройки xCAT хранятся в базе данных /etc/xact/###.sqlite.
Рабочую конфигурацию xCAT можно сохранить командой:
# mkdir /tmp/backup # dumpxCATdb -p /tmp/backup
Восстановить сохраненные настройки можно командой:
# restorexCATdb -p /tmp/backup
При восстановлении базы данных xCAT таблицы eventlog, auditlog по умолчанию не восстанавливаются. Чтобы восстановить таблицы eventlog и auditlog необходимо указать флаг -a.
Можно сохранить только одну таблицу из БД. Например, чтобы сохранить таблицу 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.
Версии устанавливаемых 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
На Management 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
Необходимая информация:
- Имя узла Management Node: mn.cluster
- База данных xCAT: xcatdb
- Имя пользователья для доступа к базе данных xCAT: xcatadmin
- Пароль пользователя 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 < table name >; mysql > quit;
Для безопасности можно сделать резервную копию настроек xCAT:
# mkdir backup # dumpxCATdb -p backup
Файл /etc/xcat/cfgloc содержит параметры доступа к БД.
# 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 следует разрешить доступ для удалённых клиентов. Данная процедура специфична для каждой БД: man mysqlsetup.
mysqlsetup
Чтобы упростить миграцию от SQLite, можно использовать утилиту mysqlsetup.
# service mysqld stop # service xcatd start # 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
Management узел
Для последующих настроек необходимо знать, на какое имя выписан сертификат 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 узлы должны быть соединены с Management узлом. От вычислительных узлов требуется чтобы они были соединены только со своим Service узлом. Прямой доступ к Management узлу для 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 указываются:
- Service узлы или группы с 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):
- 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 должны быть пустыми.
На Management узле следует задать значения для:
- chtab key=installloc site.value=[hostname:]/install
Если поле hostname отсутствует, тогда будет использовано имя Management узла. Данная опция указывает, что 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 узла. В поле site.sharedtftp можно задать имя хоста, с которого необходимо монтировать каталог tftpboot.
Для каждого адресного пространства кластера необходимо внести запись в таблицу networks.
# chtab net=10.3.1.0 networks.netname=public networks.disable=1
Если в сети присутствует пул Service узлов, тогда параметр:
- net.dhcpserver должен быть равен одному Service узлу из пула.
- net.tftpserver - сброшен
- net.namerserver - сброшен
В настройках Management узла для Compute узлов необходимо указать Service узел со службами мониторинга conserver/monserver:
# chdef -t node -o compute1 conserver=sn1 monserver=sn1
В случае использования пула Service узлов, необходимо явно выбрать некий Service узел и делегировать ему атрибуты в полях: nodehm.conserver и noderes.monserver.
Service узлы могут быть stateless или statefull.
Для Service узлов можно указать, разрешен ли IP-форвардинг в поле servicenode.ipforward.
Stateless Service узлы
Цитата из официальной документации: Service nodes are the same OS and architecture as the management node. Сервисные узлы должны работать под управлением той же ОС и быть той же архитектуры, что и управляющие узлы.
Таким образом, если на Managment узел работает под ОС ALT Linux, тогда Managment узел не может работать под SLES/RHEL Linux.
При построении образа для 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 - в случае необходимости можно разместить изменённый список устанавливаемого ПО. Сюда также можно положить .postinstall файл (например compute.postinstall).
Репозиторий ALT Linux содержит пакеты xCAT, поэтому отпадает необходимость создавать локальный репозиторий с xCAT пакетами на Managуment узле для установки на 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 и Management узлах должен быть одинаковым.
- Каталог /etc/xcat/cert должен содержать файлы: ca.pem server-cred.pem
- Каталоги /etc/xcat/ca на Service и Management узлах должны быть почти одинаковы (см. servicenode post-скрипт).
- Каталог etc/xcat/hostkeys содержит SSH ключи, которые будут устанавливаться на Compute узлы. Этот каталог должны быть одинаковы на Service и Management узле.
Замечания
Если для Service узла задан параметр chtab key=service servicenode.dhcpserver=1, тогда на Service узле будет запущен DHCP сервер, который будет слушать на "dhcpinterfaces","mn|eth0;service|eth1",,, и команда
# makedhcp dmz1node1
обновит файл на Service узле:
/var/lib/dhcp/dhcpd/state/dhcpd.leases
В документации xCAT2SetupHierarchy.pdf для Service узлов предлагается вручную отредактировать файл: /var/lib/xcat/netboot/alt/x86_64/service/rootimg/etc/exports
/var/lib/tftpboot *(rw,no_root_squash,sync) /var/lib/xcat *(rw,no_root_squash,sync)
Service Node Pools
По состоянию на Апрель 2010 года, ситуация c Pools не очень ясна. В рассылке говорится о:
- скудной документации
- не полной поддержке
Особенности:
- Необходимо спроектировать сеть так, чтобы все Сompute узлы и Service узлы находились в одном адресном пространстве.
- noderes.xcatmaster - может быть не определено. Тогда перечисленные Service узлы в noderes.servicenode будут обслуживать Compute узлы, вне зависимости от того, кто загрузил (pxe) Compute узел.
- site.dhcpinterfaces должен указывать на сетевые интерфейсы ведущие к Compute узлам, а не интерфейсы, соединяющие с Management узлом.
Stateless service node
chdef -t group -o dmz1 servicenode=sn1 xcatmaster=dmz1-sn1 netboot=pxe chdef -t group -o dmz2 servicenode=sn2,sn3 chdef -t group -o service setupnfs=1 setupnameserver=1 setuptftp=1 chdef -t node -o sn1,sn2,sn3 servicenode=mn xcatmaster=mn chdef -t group -o service arch=x86_64 os=alt nodetype=osi profile=service chdef -t group -o service ip='|\D+(\d+)|172.16.2.(100+$1)|' # nodeadd sn[1-2]-eth1 groups=all,remote nodeadd dmz1node[1-3] groups="diskless,compute,all,dmz1" nodeadd dmz2node[1-3] groups="diskless,compute,all,dmz2" chdef -t group -o dmz1 ip='|^\S+(\d+)$|172.16.3.(100+$1)|' chdef -t group -o dmz2 ip='|^\S+(\d+)$|172.16.4.(100+$1)|' makehosts chtab key=dhcpinterfaces site.value="mn|eth0;service|eth1" chdef -t group -o remote ip='|\D+(\d+)-eth1|172.16.($1*10).2|' chdef -t group -o remote ip='|\D+(\d+)-eth1|172.16.($1*10).2|' chdef -t network -o sn-1-net net="172.16.10.0" mask="172.16.10.0" mgtifname="eth1" gateway="172.16.10.2" dhcpserver="172.16.10.2" tftpserver="172.16.10.2" nameservers="172.16.10.2" chdef -t group -o service otherinterfaces='|\D+(\d+)|-eth1:172.16.($1*10).2|' chdef -t group -o service --plus postbootscripts="configeth" chdef -t group -o dmz1 xcatmaster="sn1-eth1" chdef -t node -o dmz1node1 mac="2a:2a:2a:2a:2a:11" MN - не может пересылать DHCP запросы chtab node=service servicenode.dhcpserver=1 "dhcpinterfaces","mn|eth0;service|eth1",, site nameservers = SN1 ... если нет прямого доступа...
Пакеты 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
109 echo "Warning: $nic took more than 45 seconds to receive DHCP reply, spanning-tree may not be configured well, examine switch configuration" >> /etc/motd 110 echo "Warning: $nic took more than 45 seconds to receive DHCP reply, spanning-tree may not be configured well, examine switch configuration"
#disabled networking code in init.d/kvm rm -f /etc/libvirt/qemu/networks/*.xml rm -f /etc/libvirt/qemu/networks/autostart/*.xml cat <<EOF > /etc/init.d/kvm && chmod u+x /etc/init.d/kvm && chkconfig --add kvm #!/bin/sh
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 отдельную запись.
Параметры можно задать конкретно для некого узла, но можно и для целой группы узлов. Если узел принадлежит группе, то он унаследует все параметры для данной группы. Узел может принадлежать одновременно двум и более группам. Чтобы узнать какое значение получит конкретный узел можно использовать опцию --blame для команды nodels.
# nodels cn-1 noderes.tftpserver cn-1: 172.16.2.2
# nodels --blame cn-1 noderes.tftpserver cn-1: 172.16.2.2 (inherited from group diskless)
Таблица nodepos задает физическое месторасположение узлов.
Команды chkosimage,mknimimage - работают только для AIX систем. /usr/share/xcat/tools/mktoolscenter - The IBM System x® ToolsCenter is a collection of server management tools to help manage your IBM System x and BladeServer environment.
Новый, установленный узел получает *.pub и _ssh ключи c Managmen Node с помощью post-скрипта "getcredentials.awk".
Другое
XNBA
В конфигурационные файлы:
- $tftpdir . "/xcat/xnba/nodes/" . $node
- $tftpdir . "/xcat/xnba/nodes/" . $node. ".pxelinux"
прописывается:
- IPAPPEND 2
- BOOTIF=${netX/mac}
IPAPPEND 2 - указывает что в /proc/cmdline будет добавлена строка: BOOTIF=hardware-address-of-boot-interface Это позволяет сообщить initrd программе с какого интерфейса была загружена система (pxelinux.doc).
Проверка узлов
Для проверки узлов администратору доступна утилита sinv. Её действие сводится к тому, чтобы проверить, одинаков ли вывод любой команды на узлах. Порядок действия:
- Выбирается эталонный узел, для которого на MN выполняется следующая команда:
# xdsh cn-1 "ls -l /" | xdshcoll > /tmp/sinv.template
- Для всех узлов, которые необходимо проверить на идентичность вывода команды ls -l / можно выполнить:
# sinv -c "xdsh <noderange> ls -l /" -p /tmp/sinv.template
TODO
- FullState. Установка проходит через сеть. В модуле alt.pm задается имя сетевой карточки с которой происходит установка. Эту карточку инициализирует propagator. В pxelinux есть возможность задать опцию IPAPPEND 2. Тогда pxelinux передает ядру через cmdline строку BOOTIF=hardware-address-of-boot-interface. Нужно чтобы Progpagator умел парсить параметр: BOOTIF=MAC, и использовал ее.
- Не используется linuximage.pkgdir
- Вставить строку use diagnostics; см /usr/share/xcat/netboot/alt/genimage - и будет кучу WARNING (perl -cw) на стандартные xCAT модули.
- В diskless установку добавляется пользователь altlinux, нужно решить, нужен ли он нам.
- Необходимо решить как управляются пользователи на вычислительных узлах. Для statelite вызывается утилитка: /usr/share/xcat/netboot/add-on/statelite/add_passwd
- Непонятное назначение:
- /usr/share/xcat/templates/cmos_settings
- /usr/share/xcat/tools/mac2linklocal -- Mac to IPv6 link local address utility.
- Список пакетов может включать другие пакеты #INCLUDE_PKGLIST или шаблон #INCLUDE_PTRNLIST. Не понятно как работают шаблоны (см. Template.pm).