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

Материал из ALT Linux Wiki
Нет описания правки
 
(не показано 160 промежуточных версий 4 участников)
Строка 1: Строка 1:
[[Категория:HOWTO]]
== Обзор xCAT ==
== Обзор xCAT ==


Строка 11: Строка 9:
=== Архитектура xCAT ===
=== Архитектура xCAT ===


xCAT 2 – это полностью переработанный xCAT 1.3, содержащий множество архитектурных изменений и улучшений функциональности. Все команды являются клиент-серверными, поддерживают аутентификацию, протоколируются и управляются политиками. XCAT 2 поддерживает аутентификацию roll base. Клиенты могут работать под управлением любой ОС с Perl включая Windows. Все соединения шифруются при помощи SSL. Код полностью переписан на Perl, а данные таблиц теперь сохраняются в реляционной базе данных. Благодаря модульной архитектуре вы можете выбрать используемую базу: SQLite, MySQL или PostgreSQL.
xCAT 2 – это полностью переработанный xCAT 1.3, который содержит множество архитектурных изменений и улучшений функциональности. Все команды являются клиент-серверными, поддерживают аутентификацию, протоколируются и управляются политиками. XCAT 2 поддерживает разграничение прав на основе ролей (RollBase: таблица policy управляет полномочиями на выполнение определённых операций xCAT). Клиенты могут работать под управлением любой ОС с поддержкой интерпретатора Perl, включая ОС Windows. Все соединения шифруются при помощи протокола SSL. Код xCAT 2 полностью переписан на языке Perl, а данные таблиц теперь сохраняются в реляционной базе данных. А благодаря модульной архитектуре, Вы можете выбрать требуемую СУБД: SQLite, MySQL или PostgreSQL.


В клиент-серверном приложении xCAT весь поток между клиентом и сервером контролируется службой xcatd на управляющем узле (Management Node). Когда xcatd получает упакованную как XML команду, он проверяет полномочия отправителя сверяясь с списками контроля доступа (ACL) в таблице политик. Также служба получает информацию о состоянии узлов. За дополнительной информацией обращайтесь к [http://xcat.wiki.sourceforge.net/xCAT+2+Architecture xCAT 2 Architecture].
В клиент-серверном приложении xCAT весь поток между клиентом и сервером контролируется службой xcatd (xCAT
daemon) на управляющем узле (Management Node). Когда служба xcatd получает упакованную как XML команду, она проверяет полномочия отправителя, сверяясь со списками контроля доступа ACL в таблице политик. Также служба получает информацию о состоянии и статусе узлов с момента начала их работы. За дополнительной информацией об архитектуре xCAT обращайтесь к [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 и т.д., используют эту иерархию для масштабируемого управления системой.


=== Выбор Stateless, Statelite и Stateful ===
=== Типы узлов: Stateless, Stateful и Statelite ===


Stateless узлы являются в xCAT 2 важным понятием. Stateless узел – это такой узел, который не имеет постоянно хранящегося на нём "состояния" (изменений конфигурации, обновлений программного обеспечения и т.п.). В кластерах это очень полезно в силу следующих причин:
Stateless узлы являются важным понятием в xCAT 2. Stateless узел – это узел, который не имеет постоянно хранящегося на нём "состояния" (изменения конфигурации, обновления программного обеспечения и т.п.). В кластерах это очень полезно в силу следующих причин:


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


Для Linux кластеров xCAT 2 предоставляет выбор между stateless и stateful узлами. Stateful узел – это узел с установленной на локальном жёстком диске ОС. На таком узле могут выполняться изменения (изменения конфигурации, обновления программного обеспечения и т.п.), и эти изменения сохраняются на постоянной основе.
Для Linux кластеров xCAT 2 предоставляет выбор между stateless и stateful узлами. Stateful узел – это узел с установленной на локальном жёстком диске ОС. На таком узле могут выполняться изменения (изменения конфигурации, обновления программного обеспечения и т.п.), и эти изменения сохраняются на постоянной основе.
Строка 29: Строка 28:
Stateless узлы в xCAT 2 характеризуются не только наличием ОС на локальном жёстком диске узла. Существует 3 вида stateless:
Stateless узлы в xCAT 2 характеризуются не только наличием ОС на локальном жёстком диске узла. Существует 3 вида stateless:


# '''RAM-root''' – Весь образ ОС находится на RAM файловой системе, которая во время загрузки посылается узлу. Типичный минимальный размер вычислительного узла для Linux составляет 75-160 МБ.
# '''RAM-root''' – Весь образ ОС находится на RAM файловой системе, который пересылается на узел во время его загрузки. Типичный минимальный размер вычислительного узла для Linux составляет 75-160 МБ.
# '''Compressed RAM-root''' – Образ ОС является сжатым tar файлом. Отдельные файлы распаковываются и кэшируются во время чтения. Запись осуществляется в кэшированные копии. Типичный минимальный размер вычислительного узла для Linux составляет 30-64 МБ.
# '''Compressed RAM-root''' – Образ ОС является сжатым tar-файлом. Отдельные файлы распаковываются и кэшируются во время чтения. Запись осуществляется в кэшированные копии. Типичный минимальный размер такого вычислительного узла для Linux составляет 30-64 МБ.
# '''NFS Hybrid''' – Точнее NFS-root с copy-on-write. Узлу посылается минимальное загрузочное ядро, которое в режиме чтения монтирует (NFS) образ ОС на сервере. Чтение файлов кэшируется в памяти. Запись осуществляется в кэшированные копии. Типичный минимальный размер вычислительного узла для Linux составляет 5 МБ.
# '''NFS Hybrid''' – NFS-root с копированием при записи (copy-on-write). Узлу посылается минимальное загрузочное ядро, которое в режиме чтения монтирует (NFS) образ ОС на сервере. Прочтенные файлы кэшируются в памяти. Запись осуществляется в кэшированные копии. Типичный минимальный размер такого вычислительного узла для Linux составляет 5 МБ.


Statelite (xCAT 2.4 и выше) предоставляет гибкое и эффективное бездисковое решение, т.к. большинство образов ОС монтируется по NFS в режиме только чтение, но настраиваемый список каталогов и файлов может быть доступен в режиме чтения/записи. Файлы, доступные для чтения/записи, при перезагрузке могут оставаться либо в модифицированном состоянии, либо восстанавливаться в своём первоначальном, оригинальном состоянии. У Stateless есть как преимущества, так и недостатки, которые описаны в [http://xcat.svn.sourceforge.net/viewvc/xcat/xcat-core/trunk/xCAT-client/share/doc/xCAT-Statelite.pdf xCAT Statelite Cookbook].
Statelite (начиная с версии xCAT 2.4 и выше) предоставляет гибкое и эффективное бездисковое решение, т.к. большинство образов ОС монтируется по NFS в режиме только чтение, но настраиваемый список каталогов и файлов может быть доступен в режиме чтения/записи. Файлы, доступные для чтения/записи, при перезагрузке могут оставаться либо в модифицированном состоянии, либо восстанавливаться в своём первоначальном, оригинальном состоянии. У Stateless есть как преимущества, так и недостатки, которые описаны в [http://xcat.svn.sourceforge.net/viewvc/xcat/xcat-core/trunk/xCAT-client/share/doc/xCAT-Statelite.pdf xCAT Statelite Cookbook].


=== Указание имени хоста в xCAT ===
=== Формирование имени хоста в xCAT ===


Имена хостов в xCAT не должны содержать символы в смешанном регистре. Сервис разрешения имён (DNS) возвращает все имена в нижнем регистре. Таким образом все имена хостов в xCAT должны указываться в нижнем регистре.
Имена хостов (узлов) в xCAT не должны содержать символы в смешанном регистре. Сервис разрешения имён (DNS) переводит все имена хостов в нижний регистр. Таким образом все имена хостов в xCAT должны указываться в нижнем регистре. Имена хостов xCAT должны состоять только из цифр и букв. Использование специальных символов ( -, *, и т.д.) может привести к ошибкам, т.е. не следует их использовать. Для более подробной информации следует обратиться к руководству (man) для noderange в раздел опций (noderange options).  


В xCAT предпочтительным способом является использование коротких имён (без домена). Если необходимо использовать длинные имена, тогда нужно создать xCAT "алиас" для узла, указав соответствие длинного имени узла к группе узлов с коротким именем.
В xCAT предпочтительным способом является использование коротких имён (без домена) для всех узлов. Если необходимо использовать длинные имена, тогда нужно создать xCAT "алиас" для узла, указав соответствие длинного имени узла к группе узлов с коротким именем.


Например, запись в таблице узлов может выглядеть так:
Например, запись в таблице узлов (<tt>nodelist</tt>) может выглядеть так:
   "testnode.cluster.net","testnode,compute",,,,,
   "testnode.cluster.net","testnode,compute",,,,,


Строка 54: Строка 53:
== Установка xCAT ==
== Установка xCAT ==


=== Установка на Management Node ===
=== Установка xCAT на Management Node (управляющий узел) ===


Если xCAT не предустановлен в вашей системе, вы можете установить его, выполнив:
Если xCAT не предустановлен в вашей операционной системе, то вы можете установить его, выполнив:
   # apt-get install xCAT
   # apt-get install xCAT
Будут установлены все пакеты, необходимые для того, чтобы сервер стал управляющим узлом (Management Node).
После выполнения команды будут установлены все необходимые пакеты для того, чтобы ваш сервер стал управляющим узлом (Management Node).


=== Установка на Service Node ===
=== Установка xCAT на Service Node (вспомогательный узел) ===


Как правило, Service узлы устанавливаются из центрального Managment узла. Если же по какой-то причине администратору необходимо установить Service Node вручную, необходимо установить пакет xCATsn:
Как правило, вспомогательные узлы (Service Node) устанавливаются из центрального управляющего узла (Management Node). Если же по какой-то причине администратору необходимо установить вспомогательный узел вручную, то необходимо установить пакет xCATsn с помощью команды:
   # apt-get install xCATsn
   # apt-get install xCATsn


=== Установка на Compute Node ===
=== Установка на Compute Node (вычислительный узел) ===
 
Установка вычислительного узла (Compute Node) производится только из управляющего узла (Management Node).


Compute узлы устанавливаются исключительно из центрального Managment узла.
=== Особенности установки xCAT в ОС ALT Linux ===


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


После того как завершена установка xCAT первый раз, до настройки xCAT, необходимо перерегистрироваться в системе, так как выставляется переменная окружения XCATROOT.
Если на управляющий узел установлен дистрибутив ОС ALT Linux для процессора i586,
тогда этот управляющий узел не сможет обслуживать узлы с ОС для архитектуры x86_64.


==== Репозиторий для создания образа ОС ====
==== Репозиторий для создания образа ОС ====


Для обеспечения возможности создания образа ОС, необходимого для загрузки или установки Compute узлов, нужно провести несколько ALT Linux специфических настроек на Management узле:   
Для обеспечения возможности создания образа ОС, необходимого для загрузки или установки Compute узлов, нужно провести несколько специфических для ОС ALT Linux настроек на Management узле:   


* Отдельно, для каждой архитектуры создать файл <tt>sources.list</tt>, в котором указать способ доступа к репозиторию. Например:
* Отдельно, для каждой архитектуры создать файл <tt>sources.list</tt>, в котором указать способ доступа к репозиторию. Например:
Строка 100: Строка 102:
  # ls /var/lib/tftpboot/xcat/nbfs.x86_64.gz
  # ls /var/lib/tftpboot/xcat/nbfs.x86_64.gz


В текущей реализации XCAT отсутствует возможность явно задать тип архитектуры (32 или 64 бит), который будет использоваться для discovery.
В текущей реализации xCAT отсутствует возможность явно задать тип архитектуры (32 или 64 бит), который будет использоваться для discovery.
Если текущий тип не подходит, то следует удалить файл:  
Если текущий тип не подходит, то следует удалить файл:  
<tt>/var/lib/tftpboot/pxelinux.cfg/7F</tt>
<tt>/var/lib/tftpboot/pxelinux.cfg/7F</tt>
Строка 135: Строка 137:
  # gethostip mn.cluster
  # gethostip mn.cluster
  mn.cluster 172.16.2.2 AC100202
  mn.cluster 172.16.2.2 AC100202
* заново сгенерировать все сертификаты для нового имени (при этом все настройки будут сброшены):
* заново сгенерировать все сертификаты для нового имени (при этом все настройки будут сброшены!):
  # xcatconfig -f --installdir="/var/lib/xcat" --tftpdir="/var/lib/tftpboot"
  # xcatconfig -f --installdir="/var/lib/xcat" --tftpdir="/var/lib/tftpboot"
  # lsdef -t site -l -i domain
  # lsdef -t site -l -i domain
Строка 150: Строка 152:
=== IP сети ===
=== IP сети ===


Во время установки RPM пакетов xCAT автоматически заносит обнаруженные сети в таблицу. Ненужные сети можно удалить вручную.
Во время установки RPM пакетов xCAT автоматически заносит обнаруженные сети в таблицу. Ненужные сети можно удалить вручную или указать чтобы они игнорировались:
chtab netname="192_168_122_0-255_255_255_0" networks.disable=1


Для добавления сетей, с которыми будет работать xCAT, выполните:
Для добавления сетей, с которыми будет работать xCAT, можно выполнить команду <tt>chtab</tt>. Например:
  # 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"
  # 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:
Для просмотра всех сетей, о которых знает xCAT можно выполнить команду <tt>lsdef</tt>. Например:
  # lsdef -t network -l
  # lsdef -t network -l
  Object name: clusterNet
  Object name: clusterNet
Строка 170: Строка 173:
  "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",,,
  "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",,,
Параметры:
Параметры:
* <tt>dynamicrange</tt> - задает диапазон IP адресов, которые будут выделяться для неопознанных узлов. Используется при discovery
* <tt>dynamicrange</tt> - задает диапазон IP адресов, которые будут выделяться для неопознанных узлов. Используется при discovery.
* <tt>mgtifname</tt> - имя интерфейса, ведущего в данную сеть
* <tt>mgtifname</tt> - имя интерфейса, ведущего в данную сеть.


=== Вычислительные узлы ===
=== Compute Nodes (вычислительные узлы) ===


Таблица <tt>nodelist</tt> содержит все определённые узлы. Для добавления узла выполните:
Таблица <tt>nodelist</tt> содержит все определённые узлы. Для добавления узла используется команда <tt>nodeadd</tt>. Например:
  # nodeadd node1 groups=real,all
  # nodeadd node1 groups=real,all
  # chtab node=node1 hosts.ip="172.16.2.11"
  # chtab node=node1 hosts.ip="172.16.2.11"
Любой узел '''обязан''' находиться в группе <tt>all</tt>.
Любой узел '''обязан''' находиться в группе <tt>all</tt>.
Часть параметров для узла хранятся в таблице "hosts":
Часть параметров для узла хранятся в таблице <tt>hosts</tt>:
  # tabdump hosts
  # tabdump hosts
  #node,ip,hostnames,otherinterfaces,comments,disable
  #node,ip,hostnames,otherinterfaces,comments,disable
Строка 189: Строка 192:
  # chtab node="node1" mac.mac="2a:2a:2a:2a:2a:2a"
  # chtab node="node1" mac.mac="2a:2a:2a:2a:2a:2a"


Необходимо выполнить следующие команды:
Далее необходимо выполнить следующие команды:
  # makehosts
  # makehosts
  # makedns
  # makedns
  # service bind restart
  # service bind restart
Команда <tt>makehosts</tt> пропишет соответствия "имя - IP" в файл <tt>/etc/hosts</tt> для всех узлов, заданных в xCAT:
Команда <tt>makehosts</tt> прописывает соответствия "имя - IP" в файл <tt>/etc/hosts</tt> для всех узлов, заданных в xCAT:
  # cat /etc/hosts
  # cat /etc/hosts
  127.0.0.1      localhost.localdomain localhost
  127.0.0.1      localhost.localdomain localhost
  172.16.2.2      mn.cluster mn
  172.16.2.2      mn.cluster mn
  172.16.2.11 node1 node1.cluster
  172.16.2.11 node1 node1.cluster
Команда <tt>makedns</tt> обновит настройки BIND.
Команда <tt>makedns</tt> обновляет настройки служюбы BIND.
 


если использовали шаблон:
При необходимости, можно обновить связку "IP-адрес - имя узла" только для конкретной группы узлов. Например:
  # makehosts real
  # makehosts real
  # cat /etc/hosts
  # cat /etc/hosts
Строка 208: Строка 210:
  172.16.2.101 node1 node1.cluster
  172.16.2.101 node1 node1.cluster


=== Hardware managment ===
Указать сразу несколько узлов можно различными способами. Более детально см. руководство (man) по noderange:
# man noderange
 
=== Конфигурация Service Processor ===


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


Поле <tt>nodehm.mgt</tt> может принимать следующее значение:
Поле <tt>nodehm.mgt</tt> может принимать следующее значение:
* ipmi - тогда, специфические опции service processor указываются в таблице <tt>ipmi</tt>
* ipmi - специфические опции service processor указываются в таблице <tt>ipmi</tt>
* blade - таблица <tt>mp</tt>
* blade - специфические опции service processor указываются в таблице <tt>mp</tt>
* hmc - таблица <tt>ppc</tt>
* hmc   - специфические опции service processor указываются в таблице <tt>ppc</tt>
* ivm - таблица <tt>ppc</tt> (Integrated Virtualization Manager)
* ivm   - специфические опции service processor указываются в таблице <tt>ppc</tt> (Integrated Virtualization Manager)
* fsp - таблица <tt>ppc</tt>
* fsp   - специфические опции service processor указываются в таблице <tt>ppc</tt>


Допустим, у нас есть материнская плата производства Intel, на которой установлен BMC.
Допустим, что имеется материнская плата производства Intel, на которой установлен BMC.
Сведения о BMC занесем в xCAT. Контроллер BMC будет выступать отдельным узлом xCAT.
Тогда сведения о BMC следует занести в xCAT. Контроллер BMC будет выступать отдельным узлом xCAT. Для этого необходимо
произвести следующие операции/выполнить команды:


1. Поместим BMC в группу: managment module (mm):
1. Поместить BMC в группу <tt>managment module</tt> (mm) командой:
  # chtab node=bmc1 nodelist.groups=mm
  # chtab node=bmc1 nodelist.groups=mm
2. Укажем, что service processors в группе managment module (mm) управляются через IPMI интерфейс:
2. Указать, что <tt>service processors</tt> в группе <tt>managment module</tt> (mm) управляются через IPMI интерфейс.
  # chtab node=mm nodehm.mgt=ipmi
  # chtab node=mm nodehm.mgt=ipmi
3. Зададим параметры доступа к BMC-адаптеру:
3. Задать параметры доступа к BMC-адаптеру:
  # chtab node=bmc1 ipmi.bmc=bmc1 ipmi.username=root ipmi.password=123
  # chtab node=bmc1 ipmi.bmc=bmc1 ipmi.username=root ipmi.password=123
или, если все BMC имеют одинаковые настройки username/password:
или, если все BMC имеют одинаковые настройки username/password:
  # chtab key=ipmi passwd.username=root passwd.password=123
  # chtab key=ipmi passwd.username=root passwd.password=123
Если параметры username/password не заданы в таблице <tt>ipmi</tt>, тогда будут использованы поля из таблицы <tt>passwd</tt> с ключом <tt>key=ipmi</tt>.


4. Сетевые настройки BMC контроллера должны быть настроены заранее . Сообщим xCAT IP адрес BMC контроллера:
Примечание: Если параметры username/password не заданы в таблице <tt>ipmi</tt>, тогда будут использованы поля из таблицы <tt>passwd</tt> с ключом <tt>key=ipmi</tt>.
 
4. Сетевые настройки BMC контроллера должны быть настроены заранее. После этого необходимо сообщить xCAT IP адрес BMC контроллера:
  # chtab node=bmc1 hosts.ip="172.16.2.12"
  # chtab node=bmc1 hosts.ip="172.16.2.12"
  # makehosts mm # обновит /etc/hosts
  # makehosts mm # обновит /etc/hosts
5. Проверим, что BMC контроллер bmc1 действительно удаленно управляется:
5. Проверить, что BMC контроллер bmc1 действительно удаленно управляется:
  # ipmitool -A PASSWORD -I lanplus -H bmc1 -U root -a lan print
  # ipmitool -A PASSWORD -I lanplus -H bmc1 -U root -a lan print


Для взаимодействия с service processors, xCAT предоставляет ряд утилит:
Для взаимодействия с service processors, xCAT предоставляет ряд утилит (<tt>rspconfig</tt>,<tt>rpower</tt>):
  # rspconfig bmc1 ip
  # rspconfig bmc1 ip
  bmc1: BMC IP: 172.16.2.12
  bmc1: BMC IP: 172.16.2.12
Строка 253: Строка 260:
  bmc1: on
  bmc1: on


Включим/выключим мигалку:
Включить/отключить световой индикатор можно при помощи <tt>rbeacon</tt>:
  # rbeacon bmc1 on
  # rbeacon bmc1 on
  bmc1: on
  bmc1: on
Строка 259: Строка 266:
  bmc1: off
  bmc1: off
   
   
Прочитаем 5 последних событий BMC контроллера:
Вывести, например, 5 последних событий BMC контроллера можно с помощью команды <tt>reventlog</tt>:
  # reventlog bmc1 5
  # 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:18 Power Unit, Power Off / Power Down (Pwr Unit Status) - Recovered
Строка 267: Строка 274:
  bmc1: 01/12/2010 21:12:53 System Event, Boot (Sensor 0x83)
  bmc1: 01/12/2010 21:12:53 System Event, Boot (Sensor 0x83)


Узнать модель материнской платы, версию BIOS, серийные номера можно с помощью команды:
Узнать модель материнской платы, версию BIOS, серийные номера можно с помощью команды <tt>rinv</tt>:
  # rinv bmc1 all
  # rinv bmc1 all
  bmc1: System Description: S5500BC
  bmc1: System Description: S5500BC
  ...  
  ...  


Снять показания установленных датчиков можно с помощью команды:
Снять показания установленных датчиков можно с помощью команды <tt>rvitals</tt>:
  # rvitals bmc1 all
  # rvitals bmc1 all
  bmc1: BB +5.0V: 5.016 Volts
  bmc1: BB +5.0V: 5.016 Volts
  ...
  ...


Временно изменить загрузочное устройство можно с помощью команды:
Временно изменить загрузочное устройство можно с помощью команды <tt>rsetboot</tt>:
  # rsetboot bmc1 net
  # rsetboot bmc1 net
  bmc1: Network
  bmc1: Network


====Предположение====
Несколько физических серверов могут управляться одним Service Processor. Рассмотрим пример:


Допустим, у нас есть вычислительные узлы hw1-hw4:
Пусть, имеются вычислительные узлы hw1,hw2,hw3 и hw4.
1. Добавим узлы hw1-hw4 командой <tt>nodeadd</tt>, занеся их в группу <tt>mm</tt>, что подразумевает, что эти вычислительные узлы управляются BMC контроллером.
  # nodeadd hw1-hw4 groups=all,compute,mm
  # nodeadd hw1-hw4 groups=all,compute,mm
Занесём hw1-hw4 к группе <tt>mm</tt>, это подразумевает, что вычислительные узлы управляются BMC контроллером.
 
Укажем, что все вычислительные узлы в группе <tt>compute</tt> управляются контроллером bmc1:
2. Укажем, что все вычислительные узлы в группе <tt>compute</tt> управляются контроллером bmc1:
  # chtab node=compute ipmi.bmc="bmc1" ipmi.username=root ipmi.password=123
  # chtab node=compute ipmi.bmc="bmc1" ipmi.username=root ipmi.password=123
Тогда справедливо:
 
3. Тогда справедливо:
  # rpower hw1 status
  # rpower hw1 status
  hw1: on
  hw1: on
Строка 298: Строка 307:
  hw4: on
  hw4: on


==== Conserver ====
==== Служба Conserver ====


В задачи conserver входит:
В задачи службы conserver входит:
# протоколирование активности всех узлов на последовательном порту
# протоколирование активности всех узлов на последовательном порту;
# мониторинг текущей ситуации для конкретных узлов
# мониторинг текущей ситуации для заданных узлов;


Параметры доступа к последовательному порту задаются в таблице <tt>nodehm</tt> (node's hardware managed):
Параметры доступа к последовательному порту задаются командой <tt>chtab</tt> в таблице <tt>nodehm</tt> (node's hardware managed):
  # chtab node=mm nodehm.mgt=ipmi nodehm.serialport="0" nodehm.serialspeed="115200" nodehm.serialflow="hard"
  # chtab node=mm nodehm.mgt=ipmi nodehm.serialport="0" nodehm.serialspeed="115200" nodehm.serialflow="hard"
  # makeconservercf
  # makeconservercf
Команда <tt>makeconservercf</tt> генерирует конфигурационный файл <tt>/etc/conserver.cf</tt>. Для каждого отдельного узла, который входит в группу <tt>mm</tt>, будет занесена запись в файл <tt>/etc/conserver.cf</tt>. После обновления конфигурационного файла необходимо перезапустить службу:
 
Команда <tt>makeconservercf</tt> генерирует конфигурационный файл <tt>/etc/conserver.cf</tt>. Для каждого отдельного узла, который входит в группу <tt>mm</tt>, будет занесена запись в файл <tt>/etc/conserver.cf</tt>. После обновления конфигурационного файла необходимо перезапустить службу <tt>conserver</tt>:
  # service conserver restart
  # service conserver restart
В случае успеха можно будет использовать команды мониторинга:
В случае успеха можно использовать команды мониторинга:
  # rcons bmc1
  # rcons bmc1
  [Enter `^Ec?' for help]
  [Enter `^Ec?' for help]
Строка 318: Строка 328:
А также просмотреть журнал для узла:
А также просмотреть журнал для узла:
  # cat /var/log/consoles/bmc1
  # cat /var/log/consoles/bmc1
В списке процессов можно увидеть:
При этом в списке процессов можно увидеть, например, следующее:
  8101 pts/5    Ss+    0:00 ipmitool -I lanplus -U root -P XXX -H bmc1 sol activate
  8101 pts/5    Ss+    0:00 ipmitool -I lanplus -U root -P XXX -H bmc1 sol activate


=== BIND ===
=== Служба BIND ===


Необходимо задать IP-адрес, где работает DNS-сревер BIND, который будет обслуживать имена в рамках xCAT. Обычно такой сервер работает на management node:
Необходимо задать IP-адрес, где работает DNS-сревер BIND, который будет обслуживать имена в рамках xCAT. Обычно такой сервер работает на management node:
Строка 332: Строка 342:
  "forwarders","10.2.0.1",,
  "forwarders","10.2.0.1",,


В ALT Linux BIND работает в chroot окружении, поэтому:
В ОС ALT Linux BIND работает в chroot окружении, поэтому:
  # chtab key=binddir site.value="/var/lib/bind/zone/"
  # chtab key=binddir site.value="/var/lib/bind/zone/"
  # chtab key=bindzones site.value="/zone/"
  # chtab key=bindzones site.value="/zone/"
Обновим настройки BIND:
После чего следует обновить настройки службы BIND командой :
  # makedns
  # makedns
Смотрим /etc/named.conf
 
Смотрим /var/lib/bind/zone/db.*
Чтобы проконтролировать результат выполнения команды makedns, можно проанализировать содержимое следующих конфигурационных файлов:
# /etc/named.conf
# /var/lib/bind/zone/db.*
  # service bind restart
  # service bind restart


Строка 351: Строка 363:




==== Service Node ====
==== Служба BIND на Service Node ====
BIND на Service Node:
Служба BIND на Service Node имеет особенности:
* настраивается скриптом <tt>/usr/sbin/makenamed.conf[.alt]</tt>.
* настраивается скриптом <tt>/usr/sbin/makenamed.conf[.alt]</tt>.
* работает в качестве кэширующего DNS-сервера, и все запросы пересылает серверам, которые указаны в <tt>/etc/resolv.conf</tt>
* работает в качестве кэширующего DNS-сервера, и все запросы пересылает серверам, которые указаны в <tt>/etc/resolv.conf</tt>
Строка 359: Строка 371:
  chdef -t site -o clustersite -p nameservers=172.16.10.2
  chdef -t site -o clustersite -p nameservers=172.16.10.2


=== DHCP сервер ===
=== Служба DHCP ===


Если необходимо ограничить интерфейсы, на которых должен слушать DHCP сервер, следует выполнить:
Если необходимо ограничить интерфейсы, на которые должен "слушать" DHCP сервер, то следует выполнить команду:
  # chtab key=dhcpinterfaces site.value='eth0'
  # chtab key=dhcpinterfaces site.value='eth0'
О синтаксисе <tt>dhcpinterfaces</tt> параметра можно узнать выполнив:
О синтаксисе <tt>dhcpinterfaces</tt> параметра можно узнать, выполнив команду:
  # tabdump -d site | sed -ne '/dhcpi/,+4 p'
  # tabdump -d site | sed -ne '/dhcpi/,+4 p'
  dhcpinterfaces:  The network interfaces DHCP should listen on.  If it is the same
  dhcpinterfaces:  The network interfaces DHCP should listen on.  If it is the same
Строка 370: Строка 382:
                       mn|eth1,eth2;service|bond0.
                       mn|eth1,eth2;service|bond0.


Для DHCP сервера укажем, что все неопознанные узлы должны пройти discovery:
Для DHCP сервера следует указать, что все неопознанные узлы должны пройти discovery:
  # makedhcp -n
  # makedhcp -n
  # grep dynamic /etc/dhcp/dhcpd.conf
  # grep dynamic /etc/dhcp/dhcpd.conf
Строка 379: Строка 391:


Конфигурацией ISC DHCP сервера можно управлять без перезагрузки, что и делает xCAT.
Конфигурацией ISC DHCP сервера можно управлять без перезагрузки, что и делает xCAT.
Обновим конфигурацию DHCP сервера информацией об узле:
Тогда можно обновить конфигурацию DHCP сервера информацией об узле:
  # makedhcp node1
  # makedhcp node1
  # cat /var/lib/dhcp/dhcpd/state/dhcpd.leases
  # cat /var/lib/dhcp/dhcpd/state/dhcpd.leases


Для корректного заполнения в файле <tt>/etc/dhcp/dhcpd.conf</tt> параметра отвечающего за DNS-сервер которым будут пользоваться узлы при загрузке,
необходимо убедится что флаг <tt>networks.nameservers</tt> равен IP управляющего узла. В противном случае, узлы которые загружаются через XNBA (gPXE)
не смогут резолвить имена.


==== Service node ====
==== Service node ====
Если параметр <tt>servicenode.dhcpserver</tt> тогда Service узел будет иметь свои настройки:
Если установлен флаг <tt>servicenode.dhcpserver</tt>, тогда Service узел будет иметь свои настройки в следующих файлах:
<tt>/etc/dhcp/dhcpd.conf</tt>
# <tt>/etc/dhcp/dhcpd.conf</tt>
<tt>/var/lib/dhcp/dhcpd/state/dhcpd.leases</tt>
# <tt>/var/lib/dhcp/dhcpd/state/dhcpd.leases</tt>
 
Например, нужно убедится, что для изолированных сетей параметр <tt>option domain-name-servers</tt> отличается.
Например, нужно убедится, что для изолированных сетей параметр <tt>option domain-name-servers</tt> отличается.


=== TFTP сервер ===
=== Служба ATFTP ===
 
Для корректной работы xCAT требуется наличие atftp (Advanced Trivial File Transfer Protocol) сервера.
При установке xCAT пакет tftpd (Trivial File Transfer Protocol) будет заменен пакетом atftp.
Сервер xCAT должен знать месторасположение корневого каталога для atftp службы, этот параметр задается в поле:
 
# gettab key=tftpdir site.value
/var/lib/tftpboot
 
Основной конфигурационный файл для службы atftp находится в <tt>/etc/sysconfig/atftpd</tt>.
 
Следует убедится, что значение <tt>site.value</tt> и ATFTPD_EXTRA_ARGS совпадают.


XXX: Настройки для atftpd:
При загрузке ОС должен запускаться atftpd сервис. Для этого необходимо выполнить следующие команды:
edit /etc/sysconfig/atftpd : ATFTPD_EXTRA_ARGS="/var/lib/tftpboot"
  # service atftpd restart
  # service atftpd restart
  # chkconfig atftpd on
  # chkconfig atftpd on


=== NTPD ===
'''Внимание:''' следует убедится что в пакет tftpd удален, и после этого xinetd не занимает порт используемы atftpd:
# service xinetd stop
 
=== Служба NTPD ===


Можно использовать любой публичный NTP сервер, или самостоятельно настроить собсвенный NTP сервер.
Можно использовать любой публичный NTP (Network Time Protocol) сервер, или самостоятельно настроить собственный NTP сервер.
  # chtab key=ntpservers site.value=<имя настроенного NTP сервера>
  # chtab key=ntpservers site.value=<имя настроенного NTP сервера>
Указанный NTP сервер будет использоваться statefull/stateless узлами.
Указанный NTP сервер будет использоваться statefull/stateless узлами.
Строка 405: Строка 434:
  # chtab node=node1 postscripts.postscripts=setupntp
  # chtab node=node1 postscripts.postscripts=setupntp


Обратите внимание на то, что вычислительные узлы должны использовать <tt>ntpd</tt> а не <tt>opentpd</tt>.
Обратите внимание на то, что Compute узлы (вычислительные узлы) должны использовать <tt>ntpd</tt>, а не <tt>opentpd</tt>.


=== NFS ===
=== Служба NFS ===


Файл <tt>/etc/exports</tt> автоматически обновляется во время установки xCAT или вызова команды <tt>xcatconfig</tt>:
Файл <tt>/etc/exports</tt> автоматически обновляется во время установки xCAT или вызова команды <tt>xcatconfig</tt>:
Строка 415: Строка 444:
  /var/lib/xcat *(rw,no_root_squash,sync)
  /var/lib/xcat *(rw,no_root_squash,sync)


=== HTTP ===
=== Служба HTTP ===


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


=== FTP ===
=== Служба FTP ===


FTP-сервер используется для доступа к postscripts и credentials.
FTP-сервер используется для доступа к postscripts и credentials (открытым ключам пользователя root и ssh ключа Managment узла).
Во время запуска xcatd:
Во время запуска xcatd:
# для пользователя <tt>vsftpd</tt> изменяется домашний каталог на <tt>/var/lib/xcat</tt>
# для пользователя <tt>vsftpd</tt> изменяется домашний каталог на <tt>/var/lib/xcat</tt>
Строка 433: Строка 462:
== Stateless ==
== Stateless ==


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


Для stateless узлов необходимо создать образ, который будет загружаться через сетевое соединение.
Для stateless узлов необходимо создать образ, который будет загружаться через сетевое соединение.
Строка 442: Строка 471:
Для начала необходимо предоставить APT репозиторий с пакетной базой, на основе которого будет собран требуемый образ.
Для начала необходимо предоставить APT репозиторий с пакетной базой, на основе которого будет собран требуемый образ.
Такой репозиторий можно:
Такой репозиторий можно:
* создать самому
* создать самостоятельно
* использовать официальный репозиторий ALT Linux (Sisyphus, branch 4.x 5.x)
* использовать официальный репозиторий ALT Linux (Sisyphus, branch 4.x, 5.x)
* использовать пакетную базу из установочных CD/DVD дисков
* использовать пакетную базу из установочных CD/DVD дисков


Строка 456: Строка 485:
  /etc/xcat/sources.list_x86_64
  /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 nodetype.os=alt nodetype.arch=x86_64 nodetype.profile=compute nodetype.nodetype=osi
Для создания корректной конфигурации службы DHCP, необходимо также указать тип PXE-загрузчика (xnba,pxe) и адреса TFTP сервера:
  # chtab node=node1 noderes.netboot=pxe noderes.tftpserver=172.16.2.2 noderes.nfsserver=172.16.2.2 noderes.installnic=eth1 noderes.primarynic=eth1
  # chtab node=node1 noderes.netboot=pxe noderes.tftpserver=172.16.2.2 noderes.nfsserver=172.16.2.2 noderes.installnic=eth1 noderes.primarynic=eth1
или занести узел <tt>node1</tt> в группу <tt>diskless</tt>:
 
Аналогично все параметры можно задать для некой логической группы узлов.
Например, занести узел <tt>node1</tt> в группу <tt>diskless</tt>,
и указывать все последующие параметры уже непосредственно для группы <tt>diskless</tt>.
  # chdef -t node -o node1 -p groups=diskless # удалить из группы -m
  # chdef -t node -o node1 -p groups=diskless # удалить из группы -m
  # nodech "node1" groups,=diskless # удалить из группы nodech "node1" groups^=diskless
  # nodech "node1" groups,=diskless # удалить из группы nodech "node1" groups^=diskless
задать параметры в <tt>nodetype,noderes</tt> для группы <tt>diskless</tt>:
 
  # chtab node=diskless nodetype.os=alt nodetype.arch=x86_64 nodetype.profile=compute nodetype.nodetype=osi
  # 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
  # chtab node=diskless noderes.netboot=pxe noderes.tftpserver=172.16.2.2 noderes.nfsserver=172.16.2.2 noderes.installnic=eth1 noderes.primarynic=eth1
Строка 471: Строка 504:
  или используя диалог:
  или используя диалог:
  # genimage
  # genimage
  или, если необходимо изменить архитектуру (поддерживается x86, x86_64):
  или, если необходимо, изменить архитектуру (поддерживается x86, x86_64):
  /usr/share/xcat/netboot/alt/genimage -a x86 -i eth1 -n e1000e -o alt -p compute
  /usr/share/xcat/netboot/alt/genimage -a x86 -i eth1 -n e1000e -o alt -p compute


Строка 477: Строка 510:
Если необходимо внести изменения, тогда измененный список пакетов следует положить в <tt>/var/lib/xcat/custom/netboot/alt/compute.pkglist</tt>
Если необходимо внести изменения, тогда измененный список пакетов следует положить в <tt>/var/lib/xcat/custom/netboot/alt/compute.pkglist</tt>


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


В случае успеха на выходе получим:
В случае успеха на выходе будет получен:
  # ls -1p /var/lib/xcat/netboot/alt/x86_64/compute/
  # ls -1p /var/lib/xcat/netboot/alt/x86_64/compute/
  initrd.gz
  initrd.gz
Строка 485: Строка 518:
  rootimg/
  rootimg/


Упакуем этот rootfs с учётом текущих SSL сертификатов и ключей SSH:
Далее следует упаковать этот rootfs с учётом текущих SSL сертификатов и ключей SSH:
  # packimage -p compute -o alt -a x86_64 -m nfs
  # packimage -p compute -o alt -a x86_64 -m nfs
Получим: <tt>/var/lib/xcat/netboot/alt/x86_64/compute/rootimg.nfs</tt> Возможные варианты образа:
В результате выполнения это команды будет получен файл: <tt>/var/lib/xcat/netboot/alt/x86_64/compute/rootimg.nfs</tt>
 
Возможные варианты образа:
* nfs
* nfs
* squashfs
* squashfs
Строка 493: Строка 528:


Задавать параметр <tt>-i ethN</tt> не обязательно.
Задавать параметр <tt>-i ethN</tt> не обязательно.
В зависимости от загрузчика XNBA(gpxe), pxelinux.0 будет создаваться конфигурационный файл с параметром <tt>IPAPPEND 2</tt>.
В зависимости от загрузчика XNBA (gpxe, pxelinux) будет создаваться конфигурационный файл с параметром <tt>IPAPPEND 2</tt>.
Для загружаемого узла в /proc/cmdline будет передана строка: <tt>BOOTIF=00:15:17:bd:97:29</tt>.
Для загружаемого узла в /proc/cmdline будет передана строка: <tt>BOOTIF=00:15:17:bd:97:29</tt>.
Интерфейс с соответствующим MAC адресом и будет использоваться для дальнейшей загрузки.
Интерфейс с соответствующим MAC адресом и будет использоваться для дальнейшей загрузки.


Укажем, чтобы узел загрузился по сети в stateless режим:
Укажите, чтобы узел загрузился по сети в stateless режим:
  # nodeset node1 netboot
  # nodeset node1 netboot
Параметр <tt>noderes.netboot='''pxe'''</tt> указывает, что сетевая загрузка ядра будет производиться с использованием pxelinux.
Параметр <tt>noderes.netboot='''pxe'''</tt> указывает, что сетевая загрузка ядра будет производиться с использованием pxelinux.
Строка 503: Строка 538:
Параметр <tt>noderes.netboot='''xnba'''</tt> указывает, что сетевая загрузка ядра будет производиться с использованием gPXE, xNBA.
Параметр <tt>noderes.netboot='''xnba'''</tt> указывает, что сетевая загрузка ядра будет производиться с использованием gPXE, xNBA.


Команда <tt>nodeset node1 netboot</tt> создаст конфигурационный файл для загрузки через сеть:
Команда <tt>nodeset node1 netboot</tt> создает конфигурационный файл для загрузки через сеть:
  # cat /var/lib/tftpboot/pxelinux.cfg/node1  
  # cat /var/lib/tftpboot/pxelinux.cfg/node1  
   #netboot alt-x86_64-compute
   #netboot alt-x86_64-compute
Строка 524: Строка 559:


'''Внимание:'''
'''Внимание:'''
<tt>/var/lib/xcat/netboot/alt/x86_64/compute/initrd.gz</tt> - этот initrd образ, который будет искать, и монтировать корневую файловую систему.
<tt>/var/lib/xcat/netboot/alt/x86_64/compute/initrd.gz</tt> - это initrd образ, который будет искать, и монтировать корневую файловую систему.
Но пока мы не укажем:
Но пока не будет указан:
<tt>nodeset node1 netboot</tt>
<tt>nodeset node1 netboot</tt>
будет использоваться старый initrd образ: <tt>/var/lib/tftpboot/xcat/netboot/alt/x86/compute/initrd.gz</tt>
будет использоваться старый initrd образ: <tt>/var/lib/tftpboot/xcat/netboot/alt/x86/compute/initrd.gz</tt>
Строка 531: Строка 566:
Команда:
Команда:
  # rnetboot noderange
  # rnetboot noderange
аналог
или ее аналог
  # nodeset noderange netboot
  # nodeset noderange netboot
  # rpower noderange boot
  # rpower noderange boot
Строка 537: Строка 572:
Но следует заметить, что <tt>noderange</tt>, должны управляться неким managment node (см. поле <tt>nodehm.mgt</tt>).
Но следует заметить, что <tt>noderange</tt>, должны управляться неким managment node (см. поле <tt>nodehm.mgt</tt>).


Проверим, в каком режиме работает наш узел, после того как загрузится по сети:
Проверяем режим работы узла, после загрузки по сети:
  # nodestat node1
  # nodestat node1
  node1: sshd
  node1: sshd
Строка 543: Строка 578:
При вызове команды <tt>packimage</tt>:
При вызове команды <tt>packimage</tt>:
# Пароль пользователя <tt>root</tt> буден записан в образ из значений: <tt>passwd.system</tt>, <tt>username=root</tt>.
# Пароль пользователя <tt>root</tt> буден записан в образ из значений: <tt>passwd.system</tt>, <tt>username=root</tt>.
# Будут синхронизированы файлы, перечисленные в <tt>/install/custom/<inst_type>/<distro>/<profile>.<os>.<arch>.synclist</tt> (см. xCAT2SyncFilesHowTo.pdf).
# Будут синхронизированы файлы, перечисленные в <tt>/install/custom/<inst_type>/<distro>/<profile>.<os>.<arch>.synclist</tt> (см. [http://xcat.svn.sourceforge.net/viewvc/xcat/xcat-core/trunk/xCAT-client/share/doc/xCAT2SyncFilesHowTo.pdf xCAT2SyncFilesHowTo.pdf]).
# Записан скрипт для загрузки post-скриптов <tt>/etc/init.d/xcatpostinit</tt>.
# Записан скрипт для загрузки post-скриптов <tt>/etc/init.d/xcatpostinit</tt>.
# Будет обновлена таблица <tt>linuximage</tt>:  
# Будет обновлена таблица <tt>linuximage</tt>:  
Строка 550: Строка 585:




===Console===
=== Использование протокола SoL (Serial Over Lan) ===


К узлу можно получить доступ через serial консоль. Для этого обычно используется протокол SoL (Serial Over Lan) на BMC контроллере.
К узлу можно получить доступ через последовательный порт. Для этого обычно используется протокол SoL (Serial Over Lan) на BMC контроллере.
Укажем, чтобы при загрузке узел открыл консоль на последовательном порту:
Чтобы при загрузке узел открывал консоль на последовательном порту, необходимо выполнить команду:
  # chtab node=serial nodehm.serialport=0 nodehm.serialspeed=115200
  # chtab node=serial nodehm.serialport=0 nodehm.serialspeed=115200
Тогда после загрузки любой узел, состоящий в группе <tt>serial</tt> будет открывать консоль на последовательном порту.
В результате, после загрузки любой узел, состоящий в группе <tt>serial</tt> будет открывать консоль на последовательном порту.


Нужно убедится, что PXE файл для узла создан правильно:
Следует убедиться, что PXE файл для узла создан правильно:
  # cat /var/lib/tftpboot/pxelinux.cfg/node1  
  # cat /var/lib/tftpboot/pxelinux.cfg/node1  
  #netboot alt-x86_64-compute
  #netboot alt-x86_64-compute
Строка 565: Строка 600:
   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
   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


Необходимо проверить наличие параметра <tt>console=ttyS0,115200</tt>. При загрузке узла саму консоль откроет скрипт: <tt>/etc/init.d/xcatconsole</tt>.
Далее проверяется наличие параметра <tt>console=ttyS0,115200</tt>. При загрузке узла консоль откроет скрипт: <tt>/etc/init.d/xcatconsole</tt>.


Для передачи данных с последовательного порта нужно настроить SoL на BMC.
Для передачи данных с последовательного порта нужно настроить протокол SoL на BMC контроллере с помощью команды:


  # ipmitool sol info 1
  # ipmitool sol info 1


Изменим параметры SoL в BMC контроллере, используя Linux, загруженные на узле:
Далее меняются параметры SoL в BMC контроллере, используя Linux, загруженные на узле:
  # ipmitool sol set volatile-bit-rate 115.2 1
  # ipmitool sol set volatile-bit-rate 115.2 1
  # ipmitool sol set non-volatile-bit-rate 115.2 1
  # ipmitool sol set non-volatile-bit-rate 115.2 1
Строка 582: Строка 617:
  localhost.localdomain login:
  localhost.localdomain login:


При настроенном <tt>conserver</tt> достаточно выполнить:
При настроенной службе <tt>conserver</tt> достаточно выполнить команду:
  # rcons bmc1
  # rcons bmc1


Строка 588: Строка 623:
# при discovery узла. runcmd=bmcsetup
# при discovery узла. runcmd=bmcsetup
# после discovery, выполнив <tt>nodeset <node> runcmd=bmcsetup</tt>
# после discovery, выполнив <tt>nodeset <node> runcmd=bmcsetup</tt>
Параметры BMC описываются в текстовом файле [http://www-947.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-5082810&brandind=5000008 см раздел Nodes].
Параметры BMC описываются в текстовом файле [http://www-947.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-5082810&brandind=5000008 см. раздел Nodes].


После загрузки узла hostname будет установлено следуя: <tt>RESOLVE_HOSTNAME_COMMAND=/bin/xcathostname</tt> из <tt> /etc/sysconfig/init</tt> (см. исходный код <tt>/usr/share/xcat/netboot/alt/genimage</tt>).
После загрузки узла hostname будет установлено следуя: <tt>RESOLVE_HOSTNAME_COMMAND=/bin/xcathostname</tt> из <tt> /etc/sysconfig/init</tt> (см. исходный код <tt>/usr/share/xcat/netboot/alt/genimage</tt>).
Строка 594: Строка 629:
== Statelite ==
== Statelite ==


===Сокращения===
=== Сокращения и определения ===


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


===Особенности===
=== Особенности Statelite узлов ===


# узлы грузятся через сеть;
Statelite узлы имеют следующие особенности:
# в качестве корневой файловой системы выступает NFS;
# Statelite узлы загружаются через сеть;
# есть возможность указать имена файлов, которые будут сохраняться между перезагрузками узлов;
# В качестве корневой файловой системы Statelite узла выступает NFS;
# Для Statelite узла можно задать имена файлов перманентных файлов, т.е файлов, которые будут сохраняться при перезагрузке узла;


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


* Образ корневой файловой системы используется совместно многими узлами.
Statelite узлы имеют следующие преимущества:
* Заданные файлы сохраняется между перезагрузками узлов. Есть возможность сохранять состояние файлов, например файлы с лицензионными ключами.
* Образ корневой файловой системы используется совместно со многими узлами.
* Изменение в работу узлов можно внести немедленно, обновив при этом только один образ. В большинстве случаев, изменения вступают в силу, без перезагрузки вычислительных узлов.
* Заданные файлы сохраняется между перезагрузками узлов (т.е. являются перманентными). Есть возможность сохранять состояние файлов, например, файлы с лицензионными ключами.
* Упрощается администрирование, так как многие части образа предоставляются только на чтение.
* Изменения в работу узлов можно внести немедленно, обновив при этом только один образ. В большинстве случаев, изменения вступают в силу без перезагрузки вычислительных узлов.
* Файлы можно администрировать в иерархическом порядке. Например, имеется:
* Упрощенное администрирование, так как многие части образа предоставляются только для чтения.
* Файлы можно администрировать в иерархическом порядке. Например, может иметься:
** один общий образ
** один общий образ
** два узла
** два узла
тогда в таблице можно указать разные источники для синхронизации файлов.
и тогда в таблице можно указать разные источники для синхронизации файлов.
* Уменьшает потребление системных ресурсов в решениях с использованием виртуализации. Если в kvm использовать образ диска (stateless - squashfs, stateful - файл диска) тогда будут нецелесообразно потребляться память и дисковое пространство.
* Statelite узлы уменьшают потребление системных ресурсов в решениях с использованием виртуализации. Если в kvm использовать образ диска (stateless - squashfs, stateful - файл диска), тогда будут нецелесообразно потребляться память и дисковое пространство.


===Минусы===
=== Недостатки ===


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


===Настройка===
=== Настройка ===


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


Во время инсталляции xCAT обновляется конфигурационный файл NFS сервера:
Во время инсталляции xCAT обновляется конфигурационный файл NFS сервера:
Строка 633: Строка 672:
  /var/lib/tftpboot *(rw,no_root_squash,sync)
  /var/lib/tftpboot *(rw,no_root_squash,sync)
  /var/lib/xcat *(rw,no_root_squash,sync)
  /var/lib/xcat *(rw,no_root_squash,sync)
как видно, к каталогам предоставляется доступ на запись (rw). Желательно ограничить доступ к файлам только на чтение, с последующей перезагрузкой службы NFS:  
как видно, к каталогам предоставляется доступ на запись (rw). Желательно ограничить доступ к файлам только на чтение (read only), с последующей перезагрузкой службы NFS:  
  # cat /etc/exports  
  # cat /etc/exports  
  /var/lib/tftpboot *(ro,no_root_squash,sync)
  /var/lib/tftpboot *(ro,no_root_squash,sync)
Строка 641: Строка 680:
Список перманентных файлов указывается индивидуально для каждого узла. Теоретически, можно предоставить все файлы из образа на запись. Такой подход может привести к возникновению проблем, так как узлы будут изменять файлы в одном образе. Поэтому рекомендуется заблокировать главный образ, и предоставить только права на чтение.
Список перманентных файлов указывается индивидуально для каждого узла. Теоретически, можно предоставить все файлы из образа на запись. Такой подход может привести к возникновению проблем, так как узлы будут изменять файлы в одном образе. Поэтому рекомендуется заблокировать главный образ, и предоставить только права на чтение.


====таблица <tt>litefile</tt>====
==== Таблица <tt>litefile</tt> ====


Таблица <tt>litefile</tt> используется, когда необходимо указать список уникальных файлов для statelite узла. По '''умолчанию''' такие файлы:
Таблица <tt>litefile</tt> используется, если необходимо указать список уникальных файлов для statelite узла. По '''умолчанию''' такие файлы:
* будут доступны на запись;
* будут доступны на запись;
* каждый узел будет иметь свою копию;
* каждый узел будет иметь свою копию файлов;
* будут храниться в памяти работающего узла;
* будут храниться в памяти работающего узла;
* не будут являться перманентными;
* не будут являться перманентными;
* создаются во время загрузки узла, методом копирования с главного образа.
* создаются во время загрузки узла методом копирования с главного образа.


Таблица <tt>litefile</tt> содержит следующие поля:
Таблица <tt>litefile</tt> содержит следующие поля:
  # tabdump litefile
  # tabdump litefile
  #image,file,options,comments,disable
  image,file,options,comments,disable


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




Пример заполнения таблицы <tt>litefile</tt> для ОС ALT Linux. Приведённый ниже список может быть отправной точкой при заполнении <tt>litefile</tt> таблицы.
Приведем пример заполнения таблицы <tt>litefile</tt> для ОС ALT Linux. Приведённый ниже список может быть отправной точкой при заполнении <tt>litefile</tt> таблицы.
Все файлы будут размещены в tmpfs. Постоянное хранилище для нижележащих файлов отсутствует, что позволяет использовать NFS корень только для чтения.
Все файлы будут размещены в tmpfs. Постоянное хранилище для нижележащих файлов отсутствует, что позволяет использовать NFS корень только для чтения.
<pre>
<pre>
Строка 706: Строка 745:
</pre>
</pre>


====таблица <tt>litetree</tt>====
==== Таблица <tt>litetree</tt> ====
Назначение таблицы <tt>litetree</tt> - хранить NFS ресурсы с начальным состоянием файлов из таблицы <tt>litefile</tt>.
Назначение таблицы <tt>litetree</tt> - хранить NFS ресурсы с начальным состоянием файлов из таблицы <tt>litefile</tt>.
Таблица <tt>litetree</tt> содержит только R/O NFS ресурсы.
Таблица <tt>litetree</tt> содержит только R/O NFS ресурсы.
Строка 713: Строка 752:


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


При загрузке узла в statelite режиме происходит копирование файлов с root образа в <tt>/.default</tt> каталог (tmpfs). Также существует возможность задать отдельно для каждого узла, откуда следует брать файлы. Например, есть два различных файла <tt>/etc/motd</tt>:
При загрузке узла в statelite режиме происходит копирование файлов с root образа в <tt>/.default</tt> каталог (tmpfs). Также существует возможность задать отдельно для каждого узла, откуда следует брать файлы. Например, есть два различных файла <tt>/etc/motd</tt>:
Строка 737: Строка 776:
Если файлы не найдены в первом каталоге, будет осуществлён поиск в следующем каталоге. Если файлы не обнаружены в иерархии таблицы <tt>litetree</tt>, тогда они ищутся в каталоге <tt>/.default</tt> на локальном образе.
Если файлы не найдены в первом каталоге, будет осуществлён поиск в следующем каталоге. Если файлы не обнаружены в иерархии таблицы <tt>litetree</tt>, тогда они ищутся в каталоге <tt>/.default</tt> на локальном образе.


====Таблица <tt>statelite</tt>====
==== Таблица <tt>statelite</tt> ====


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


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


Все узлы, состоящие в группе <tt>japan</tt>, будут хранить своё состояния в каталоге /gpfs/state на машине с именем cnfs. Это правило будет применяться ко всем образам. Существует возможность задать различное местоположение хранилища.
Все узлы, состоящие в группе <tt>japan</tt>, будут хранить своё состояния в каталоге <tt>/gpfs/state</tt> на машине с именем <tt>cnfs</tt>. Это правило будет применяться ко всем образам. Существует возможность задать различное местоположение хранилища.
Нужно убедиться, что для одного узла отсутствуют несколько записей:
Необходимо убедиться, что для одного узла отсутствуют несколько записей:
<tt>node1</tt>
<tt>node1</tt>
<tt>group_with_node1</tt>
<tt>group_with_node1</tt>


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


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


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


Следует убедиться, что политики безопасности настроены корректно. Когда узел , он опрашивает базу xCAT и требует доступ к командам:
Следует убедиться, что политики безопасности настроены корректно. Когда узел загружается, он опрашивает базу xCAT и требует доступ к командам:
  # lite-files
  # lite-files
  # lite-tree
  # lite-tree
в таблице <tt>policy</tt> необходимо разрешить узлам доступ к этим командам:
В таблице <tt>policy</tt> необходимо разрешить узлам доступ к этим командам:
  # chtab priority=4.7 policy.commands=litetree
  # chtab priority=4.7 policy.commands=litetree
  # chtab priority=4.8 policy.commands=litefile
  # chtab priority=4.8 policy.commands=litefile
Строка 768: Строка 806:
Эти команды выполняются автоматически при установке xCAT. При возникновении ошибок данные значения можно проверить.
Эти команды выполняются автоматически при установке xCAT. При возникновении ошибок данные значения можно проверить.


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


После того, как заданы правила в таблицах, можно приступать к созданию базового образа.
После того, как заданы правила в таблицах, можно приступать к созданию базового образа.
Рассмотрим пример:
* Пусть имя образа будет <tt>test1</tt>.  
* Пусть имя образа будет <tt>test1</tt>.  
* Пусть необходимо создать список пакетов, которые будут установлены в образ <tt>test1</tt>.


* Необходимо создать список пакетов, которые будут установлены в образ <tt>test1</tt>. Список пакетов задается в файле: <tt>/usr/share/xcat/netboot/alt/compute.pkglist</tt>
Список пакетов задается в файле: <tt>/usr/share/xcat/netboot/alt/compute.pkglist</tt>
 
Далее необходимо выполнить команду:
* После чего нужно выполнить команду:
  # genimage
  # genimage
или:
или команду:
  # /usr/share/xcat/netboot/alt/genimage -a x86 -i eth1 -n e1000e -o alt -p compute -m statelite
  # /usr/share/xcat/netboot/alt/genimage -a x86 -i eth1 -n e1000e -o alt -p compute -m statelite
Команда <tt>genimage</tt>:
 
* создаёт каталог в/var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg
Команда <tt>genimage</tt> сделает следующее:
* создаст каталог в /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg
* создаст несколько каталогов для statelite режима внутри образа:
* создаст несколько каталогов для statelite режима внутри образа:
  /.statelite
  /.statelite
Строка 789: Строка 830:
Созданный образ может быть использован также для stateless загрузки.
Созданный образ может быть использован также для stateless загрузки.


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


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


Для базовой настройки рабочего образа всё что необходимо - это скопировать некоторые passwd файлы и настройки ssh с xCAT в образ:
Для базовой настройки рабочего образа необходимо скопировать некоторые passwd файлы и настройки ssh с xCAT в образ:
  # cd /usr/share/xcat/netboot/add-on/statelite
  # cd /usr/share/xcat/netboot/add-on/statelite
  # ./add_passwd /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg
  # ./add_passwd /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg
  # ./add_ssh /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg
  # ./add_ssh /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg


===Команда <tt>liteimg</tt>===
=== Команда <tt>liteimg</tt> ===


Команда <tt>liteimg</tt> вносит изменения в statelite образ и создаёт набор ссылок.
Команда <tt>liteimg</tt> вносит изменения в statelite образ и создаёт набор ссылок.


'''Внимание:''' при обновлении statelite образа необходимо выключить все statelite узлы, использующие этот образ.
'''Внимание:''' При обновлении statelite образа необходимо выключить все statelite узлы, использующие этот образ.


Когда внесены все настройки в /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg можно выполнить:
Когда внесены все настройки в /var/lib/xcat/netboot/<os>/<arch>/<profile>/rootimg можно выполнить следующие команды:
  # liteimg <os>-<arch>-<profile>
  # liteimg <os>-<arch>-<profile>
  # liteimg alt-x86-statelite-compute
  # liteimg alt-x86-statelite-compute
  # liteimg -p compute -a x86_64 -o alt
  # liteimg -p compute -a x86_64 -o alt


Комманда <tt>liteimg</tt>:
Команда <tt>liteimg</tt>:
# вносит изменения в statelite образ и создаёт набор ссылок
# вносит изменения в statelite образ и создаёт набор ссылок;
# портит diskless образ, т.е. один образ для diskless и statelite режима.
# делает непригодным diskless образ, т.е. один образ для diskless и statelite режима;
# может обновлять <tt>rootimg</tt> согласно записям из таблицы <tt>litefile</tt>
# может обновлять <tt>rootimg</tt> согласно записям из таблицы <tt>litefile</tt>;
# восстанавливает файлы в начальное состояние, если они были удалены из таблицы <tt>litefile</tt>
# восстанавливает файлы в начальное состояние, если они были удалены из таблицы <tt>litefile</tt>;
# копирует <tt>/usr/share/xcat/netboot/add-on/statelite/rc.statelite</tt> в <tt>/var/lib/xcat/netboot/alt/x86/compute/rootimg/etc/init.d/</tt>.
# копирует <tt>/usr/share/xcat/netboot/add-on/statelite/rc.statelite</tt> в <tt>/var/lib/xcat/netboot/alt/x86/compute/rootimg/etc/init.d/</tt>.
   
   
Команда <tt>liteimg</tt> создаст 2 способа доступа к файлам, что позволит изменять файлы in their image state as well as during runtime.
Команда <tt>liteimg</tt> создает 2 способа доступа к файлам, что позволит изменять файлы:
# непосредственно в корневом каталоге образа на управляющем узле;
# на работающем вычислительном узле.


Например, над файлом <tt><$imgroot>/etc/ntp.conf</tt> были произведены следующие операции:
Например, над файлом <tt><$imgroot>/etc/ntp.conf</tt> были произведены следующие операции:
  # mkdir ­-p $imgroot/.default/etc
  # mkdir ­-p $imgroot/.default/etc
  # mkdir ­-p $imgroot/.statelite/tmpfs/etc
  # mkdir ­-p $imgroot/.statelite/tmpfs/etc
Строка 826: Строка 870:
  # cd $imgroot/etc
  # cd $imgroot/etc
  # ln ­-sf ../.statelite/tmpfs/etc/resov.conf .
  # ln ­-sf ../.statelite/tmpfs/etc/resov.conf .
оригинальный файл будет находиться в <tt>$imgroot/.default/etc/ntp.conf</tt>.
оригинальный файл будет находиться в <tt>$imgroot/.default/etc/ntp.conf</tt>.


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


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


Команда <tt>packimage</tt> для statelite профиля не выполняется.
'''Примечание:''' Команда <tt>packimage</tt> для statelite профиля не выполняется.
 
===Команда <tt>lslite</tt>===
 
С помощью команды <tt>lslite</tt> можно получить информацию о состоянии statelite узлов.
Данная команда выводит следующую полезную информацию для узла:
* каталог, который хранит изменяемые файлы
* Файлы перечисленные в таблице <tt>litefile</tt>
* файлы перечисленные в таблице <tt>litetree</tt>
 
Также информацию можно получить для state-lite образа, используя ключ <tt>-i</tt>.


=== POST-скрипты ===
=== POST-скрипты ===
Для statlite режима можно использовать два типа POST-скриптов.
Для statlite режима можно использовать два типа POST-скриптов.
Скрипты первого типа:
Скрипты первого типа:
# исполняются при загрузке узла
# ...исполняются при загрузке узла;
# скачиваются с Managment Node
# ...скачиваются с Managment Node;
# перечисляются в таблице <tt>postscripts</tt>
# ...перечисляются в таблице <tt>postscripts</tt>.
Второй тип скрипта:
# Выполняется на стадии создания образа командой <tt>genimage</tt>
# Имя скрипта должно совпадать с профилем, на основе которого создается образ. Например: </tt>compute.alt.x86.postinstall</tt>
# Находится в каталоге <tt>/usr/share/xcat/netboot/alt</tt> или в каталоге <tt>/var/lib/xcat/custom/netboot/alt</tt>
# Скрипту передаются следующие аргументы: <tt>$rootimg_dir, $osver, $arch, $profile</tt>


===Установка узла===
Скрипты второго типа:
# ...выполняются на стадии создания образа командой <tt>genimage</tt>;
# Имя скрипта должно совпадать с профилем, на основе которого создается образ. Например: <tt>compute.alt.x86.postinstall</tt>;
# ...находятся в каталоге <tt>/usr/share/xcat/netboot/alt</tt> или в каталоге <tt>/var/lib/xcat/custom/netboot/alt</tt>;
# Скрипту передаются следующие аргументы: <tt>$rootimg_dir, $osver, $arch, $profile</tt>.


=== Установка узла ===
Установка Statelite узла производится командой <tt>nodeset</tt>:
  # nodeset hpc3 statelite=alt-x86-compute
  # nodeset hpc3 statelite=alt-x86-compute
  или
  или
  # nodeset cn-1 statelite
  # nodeset cn-1 statelite


'''Внимание''': если раньше для созданного образа вызывалась команда <tt>packimage</tt> тогда команда <tt>nodeset <node> statelite</tt> будет создавать конфигурационный файл PXE/XNBA для diskless загрузки. Смотри [https://sourceforge.net/tracker/?func=detail&aid=3017090&group_id=208749&atid=1006945 bugs tracker]
'''Внимание''': Если до этого для созданного образа вызывалась команда <tt>packimage</tt>, то команда <tt>nodeset <node> statelite</tt> будет создавать конфигурационный файл PXE/XNBA для diskless загрузки. Смотрите более подробно на [https://sourceforge.net/tracker/?func=detail&aid=3017090&group_id=208749&atid=1006945 bugs tracker]


данная команда:
Данная команда:
* обновит запись в таблице <tt>nodetype</tt>:
* обновит запись в таблице <tt>nodetype</tt>:
  # tabdump nodetype
  # tabdump nodetype
Строка 861: Строка 919:
  "cn-1",,,,"statelite",,,,
  "cn-1",,,,"statelite",,,,


* создаст необходимые файлы в каталоге <tt>/var/lib/tftpboot</tt> для загрузки узла; Будет создан нужный PXE или XNBA файл, так что узел будет загружаться с использованием nfsroot образа. Файл с параметрами загрузки будет выглядеть примерно так:
* создаст необходимые файлы в каталоге <tt>/var/lib/tftpboot</tt> для загрузки узла. Будет создан нужный PXE или XNBA файл, так что узел будет загружаться с использованием nfsroot образа. Файл с параметрами загрузки будет выглядеть, например, следующим образом:
  #statelite centos5.3-x86_64-all
  #statelite centos5.3-x86_64-all
  DEFAULT xCAT
  DEFAULT xCAT
Строка 870: Строка 928:
   STATEMNT=cnfs:/gpfs/state XCAT=172.10.0.1:3001 console=tty0 console=ttyS0,115200n8r
   STATEMNT=cnfs:/gpfs/state XCAT=172.10.0.1:3001 console=tty0 console=ttyS0,115200n8r


Параметр:
О параметрах:
* <tt>NFSROOT</tt> может быть равен <tt>noderes.nfsserver, noderes.tftpserver, noderes.xcatmaster</tt>.
* <tt>NFSROOT</tt> может быть равен <tt>noderes.nfsserver, noderes.tftpserver, noderes.xcatmaster</tt>.
* <tt>STATEMENT</tt> равен параметру <tt>statelite.statement</tt> для даного узла.
* <tt>STATEMENT</tt> равен параметру <tt>statelite.statement</tt> для даного узла.
* <tt>XCAT</tt>  равен <tt>noderes.xcatmaster:site.xcatdport</tt>
* <tt>XCAT</tt>  равен <tt>noderes.xcatmaster:site.xcatdport</tt>.


Параметр <tt>NFSROOT</tt> задаёт расположение NFS ресурса с корневой файловой системой, доступной только на чтение (<tt>/install или же /var/lib/xcat</tt>).
Параметр <tt>NFSROOT</tt> задаёт расположение NFS ресурса с корневой файловой системой, доступной только на чтение (<tt>/install или же /var/lib/xcat</tt>).
Строка 881: Строка 939:
  # cd /
  # cd /
  # prsync /var/lib/xcat <sn>:/var/lib/xcat ???
  # prsync /var/lib/xcat <sn>:/var/lib/xcat ???
Параметр <tt>site.installoc</tt> для Service узла не должен установлен в какое-либо значение.
Параметр <tt>site.installoc</tt> для Service узла не должен быть установлен в какое-либо значение.


Перезагрузить узел  
Перезагрузить узел можно командой:
  # rpower <noderange> boot
  # rpower <noderange> boot
Для просмотра процесса загрузки можно использовать <tt>rcons</tt> или <tt>wcons</tt>.
 
Для просмотра процесса загрузки можно использовать команду <tt>rcons</tt> или <tt>wcons</tt>.


Команда <tt>rpower</tt> по умолчанию выполняет указанное действие на всех узлах одновременно.
Команда <tt>rpower</tt> по умолчанию выполняет указанное действие на всех узлах одновременно.
Чтобы избежать пиковой нагрузки, можно задать параметр <tt>site.powerinterval</tt>, тогда указанное действие для каждого узла будет производится последовательно с некой задержкой.
Чтобы избежать пиковой нагрузки, можно задать параметр <tt>site.powerinterval</tt>. Тогда указанное действие для каждого узла будет производится последовательно с некоторой задержкой.


===Команды===
===Команды===
Строка 900: Строка 959:


Каждый образ statelite будет иметь следующие каталоги:
Каждый образ statelite будет иметь следующие каталоги:
  <tt>/.statelite</tt> <-- R/W с файловой системой TMPFS.
  <tt>/.statelite</tt> <-- R/W с файловой системой TMPFS.
  <tt>/.statelite/tmpfs/</tt>  <-- Файлы перечисленные в таблице <tt>litefile</tt> будут замещены ссылками. Эти ссылки будут указывают сюда, на другие ссылки, которые указывают на  <tt>/.statelite/persistent/<nodename></tt>
  <tt>/.statelite/tmpfs/</tt>  <-- Файлы перечисленные в таблице <tt>litefile</tt> будут замещены ссылками. Эти ссылки будут указывают
сюда, на другие ссылки, которые указывают на  <tt>/.statelite/persistent/<nodename></tt>
  <tt>/.statelite/persistent/<nodename>/</tt>  <--  Сюда будет смонтирован NFS ресурс <tt>statelite.statemnt</tt> для узла <tt>statelite.node</tt>.
  <tt>/.statelite/persistent/<nodename>/</tt>  <--  Сюда будет смонтирован NFS ресурс <tt>statelite.statemnt</tt> для узла <tt>statelite.node</tt>.
  <tt>/.statelite/mnt/<index>/</tt> <-- Сюда будет смонтированы R/O для <tt>litetree.image</tt> NFS ресурс <tt>litetree.directory</tt>
  <tt>/.statelite/mnt/<index>/</tt> <-- Сюда будет смонтированы R/O для <tt>litetree.image</tt> NFS ресурс <tt>litetree.directory</tt>
Строка 910: Строка 971:


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


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


===Пример===
Пример:
  # nodeset <node> statelite
  # nodeset <node> statelite


 
=== Последовательность загрузки statelite-узла ===
===Загрузка (цепочка)===
Последовательность загрузки statelite-узла:
Последовательность загрузки statelite-узла:
# Образ создается командой <tt>/usr/share/xcat/netboot/alt/genimage</tt>
# Образ создается командой <tt>/usr/share/xcat/netboot/alt/genimage</tt>
Строка 944: Строка 1004:
  #imagename,template,pkglist,pkgdir,otherpkglist,otherpkgdir,exlist,postinstall,rootimgdir,comments,disable
  #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",,,,,
  "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).
На каждом узле заводится локальный аккаунт администратора (root).
Строка 951: Строка 1010:
Возможные значения ключа: blade (management module), ipmi (BMC), system (nodes), omapi (DHCP), hmc, ivm, fsp.
Возможные значения ключа: 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 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
  # chtab node=node1 noderes.netboot=pxe noderes.tftpserver=172.16.2.2 noderes.nfsserver=172.16.2.2 noderes.installnic=eth1 noderes.primarynic=eth1
Строка 970: Строка 1029:


Пакетная база на установленном Statefull Compute Node соответствует стандартной установке дистрибутива.
Пакетная база на установленном Statefull Compute Node соответствует стандартной установке дистрибутива.
Если требуется установить дополнительные пакеты в момент установки (работы инсталлятора) создайте файл со списком пакетов:
Если требуется установить дополнительные пакеты в момент установки (работы инсталлятора), то необходимо создать файл со списком пакетов:
  /var/lib/custom/install/alt/<profile>.[alt].[<arch>].installer.pkglist
  /var/lib/custom/install/alt/<profile>.[alt].[<arch>].installer.pkglist
  или в
  или в
Строка 976: Строка 1035:
'''Внимание:''' пакеты должны быть доступны на установочном CD. В случае отсутствия хотя бы одного пакета все перечисленные пакеты не будут установлены.
'''Внимание:''' пакеты должны быть доступны на установочном CD. В случае отсутствия хотя бы одного пакета все перечисленные пакеты не будут установлены.


==== Для любопытных ====
==== Авто-установка ====
Последовательность действий при авто-установке:
Последовательность действий при авто-установке:


Строка 994: Строка 1053:
# <tt>xcat-post.sh</tt> создаётся на основе <tt> /usr/share/xcat/install/scripts/post.alt</tt>. См. модуль: <tt>/usr/lib/perl5/vendor_perl/xCAT_plugin/alt.pm</tt>
# <tt>xcat-post.sh</tt> создаётся на основе <tt> /usr/share/xcat/install/scripts/post.alt</tt>. См. модуль: <tt>/usr/lib/perl5/vendor_perl/xCAT_plugin/alt.pm</tt>
# Далее происходит скачивание и выполнение скриптов из таблицы <tt>postscripts</tt> для узла <tt>node1</tt>.
# Далее происходит скачивание и выполнение скриптов из таблицы <tt>postscripts</tt> для узла <tt>node1</tt>.
<tt>curl=http://172.16.2.2/install/autoinst/node1/</tt> -
соде


Команда:
Команда:
Строка 1004: Строка 1060:
После этой команды в каталоге <tt>/var/lib/xcat/autoinst/node1</tt> будут расположены файлы, необходимые для автоматической установки ALT Linux на узел <tt>node1</tt>.
После этой команды в каталоге <tt>/var/lib/xcat/autoinst/node1</tt> будут расположены файлы, необходимые для автоматической установки ALT Linux на узел <tt>node1</tt>.
  # rpower noderange boot
  # rpower noderange boot
Комманда <tt>rinstall</tt>:
Команда <tt>rinstall</tt>:
* вызывает <tt>nodeset</tt> для обновления конфигурационного файла загрузчика
* вызывает <tt>nodeset</tt> для обновления конфигурационного файла загрузчика
* заставляет узел загрузится
* заставляет узел загрузится
Строка 1010: Строка 1066:


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


# При завершении установки выполняются скрипты, указанные в <tt>postscripts.postscripts</tt>
# При завершении установки выполняются скрипты, указанные в <tt>postscripts.postscripts</tt>
Строка 1020: Строка 1076:
== Statefull - service node ==
== Statefull - service node ==
Если задан профиль service, тогда узел будет не вычислительным, а service node.
Если задан профиль service, тогда узел будет не вычислительным, а service node.
В качестве базы данных нужно использовать БД отличную от sqlite.
В качестве СУБД необходимо использовать СУБД отличную от sqlite.


== Postinstall скрипты ==
== Postinstall скрипты ==


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


  # lftp mn
  # lftp mn
Строка 1036: Строка 1092:
  drwxr-xr-x    2 ftp      ftp          4096 Feb 12 19:35 prescripts
  drwxr-xr-x    2 ftp      ftp          4096 Feb 12 19:35 prescripts


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


Список необходимых к выполнению скриптов перечисляется в таблице <tt>postscripts</tt>:
Список необходимых к выполнению скриптов перечисляется в таблице <tt>postscripts</tt>:
Строка 1045: Строка 1101:
  "service","servicenode",,,
  "service","servicenode",,,


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


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


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


* '''remoteshell''' - копирует SSH ключ на узел. Аутентификация по паролю запрещена. Если необходимо разрешить удалённый доступ по паролю, необходимо закомментировать в своём скрипте <tt>PasswordAuthentication no</tt>.
* '''remoteshell''' - копирует SSH ключ на узел. Аутентификация по паролю запрещена. Если необходимо разрешить удалённый доступ по паролю, необходимо закомментировать в своём скрипте <tt>PasswordAuthentication no</tt>.
Строка 1069: Строка 1125:
* Все атрибуты из таблицы <tt>site</tt>
* Все атрибуты из таблицы <tt>site</tt>


===Stateless===
=== Stateless ===
Узлы работающие в stateless режиме используют общий образ.
Узлы работающие в stateless режиме используют общий образ.
Во время загрузки любого diskless узла будут выполнены скрипты в такой последовательности:
Во время загрузки любого diskless узла будут выполнены скрипты в такой последовательности:
Строка 1084: Строка 1140:
Во время загрузки stateless узла выполняется скрипт <tt>/etc/init.d/xcatpostinit</tt>, который выполняет файл <tt>/opt/xcat/xcatdsklspost</tt>.
Во время загрузки stateless узла выполняется скрипт <tt>/etc/init.d/xcatpostinit</tt>, который выполняет файл <tt>/opt/xcat/xcatdsklspost</tt>.


<tt>/opt/xcat/xcatdsklspost</tt> определяет IP DHCP сервера и считает его за IP Managment Node. Скачивает ftp://IPDHCP/poscripts в /xcatpost.
<tt>/opt/xcat/xcatdsklspost</tt> определяет IP DHCP-сервера, принимает его за IP Managment Node и скачивает ftp://IPDHCP/poscripts в каталог /xcatpost.


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


Создаётся файл <tt>/opt/xcat/xcatinfo</tt> IP MN.
Создаётся файл <tt>/opt/xcat/xcatinfo</tt> IP MN.


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




===Statefull===
=== Statefull ===


Последовательность:
Последовательность установки:
# Инсталятор собирается с пакетом: <tt>installer-feature-xCAT-stage3</tt>
# Инсталятор собирается с пакетом: <tt>installer-feature-xCAT-stage3</tt>
# После установки пакетов выполняется скрипт: <tt>81-xCAT-postinstall.sh</tt>
# После установки пакетов выполняется скрипт: <tt>81-xCAT-postinstall.sh</tt>
Строка 1103: Строка 1159:
# Модуль <tt>alt.pm</tt> из шаблона создаёт для каждого узла свой файл <tt>/var/lib/xcat/autoinst/node15/xcat-post.sh</tt>
# Модуль <tt>alt.pm</tt> из шаблона создаёт для каждого узла свой файл <tt>/var/lib/xcat/autoinst/node15/xcat-post.sh</tt>
# Скрипт <tt>xcat-post.sh</tt> выкачивает из Managnent Node все пост-скрипты и выполняет только те, которые заданы в <tt>postscripts.postscripts</tt> для текущего узла.
# Скрипт <tt>xcat-post.sh</tt> выкачивает из Managnent Node все пост-скрипты и выполняет только те, которые заданы в <tt>postscripts.postscripts</tt> для текущего узла.
# Скрипт <tt>xcat-post.sh</tt> уведомляет Managment Node об окончании устновки.
# Скрипт <tt>xcat-post.sh</tt> уведомляет Managment Node об окончании установки.
# Скрипт <tt>xcat-post.sh</tt> создает init скрипт, который выполнит <tt>`postscripts.postbootscripts</tt> при первой загрузке.
# Скрипт <tt>xcat-post.sh</tt> создает init скрипт, который выполнит <tt>postscripts.postbootscripts</tt> при первой загрузке.


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


Добавим свитч и зададим параметры доступа (SNMPv1, community string = public):
Добавим свитч и зададим параметры доступа (SNMPv1, community string = public) к нему:
  # nodeadd switch1 groups=switches
  # nodeadd switch1 groups=switches
  # chtab node=switch1 hosts.ip="10.2.XX.XX"
  # chtab node=switch1 hosts.ip="10.2.XX.XX"
Строка 1131: Строка 1187:
  # gettab node=node1 nodelist.status
  # gettab node=node1 nodelist.status
   standingby
   standingby
В поле <tt>chain.chain</tt> через запятую можно задать следующие действия для обнаруженного узла:
В поле <tt>chain.chain</tt> через запятую можно задать следующие действия для обнаруженного узла:
discover, boot or reboot, install or netboot, runcmd=<cmd>, runimage=<image>, shell, standby.
discover, boot or reboot, install or netboot, runcmd=<cmd>, runimage=<image>, shell, standby.
Перезагрузим обнаруженный узел:
 
Для перезагрузки обнаруженного узла:
  # chtab node=node1 chain.chain="reboot"
  # chtab node=node1 chain.chain="reboot"


Чтобы забыть обнаруженный узел:
Для "забывания" обнаруженного узла:
  # makedhcp -d node1
  # makedhcp -d node1
  # chtab -d node=node1 mac
  # chtab -d node=node1 mac
Строка 1148: Строка 1206:
  # cat /var/lib/tftpboot/xcat/xnba/nets/172.16.2.0_24
  # cat /var/lib/tftpboot/xcat/xnba/nets/172.16.2.0_24
При отсутствии файла <tt>/var/lib/tftpboot/xcat/xnba/nets/172.16.2.0_24</tt> он автоматически создаётся командой <tt>mknb <ARCH></tt>.
При отсутствии файла <tt>/var/lib/tftpboot/xcat/xnba/nets/172.16.2.0_24</tt> он автоматически создаётся командой <tt>mknb <ARCH></tt>.
Если discovery нужно провести на другом ядре, тогда достаточно удалить файл <tt>/var/lib/tftpboot/xcat/xnba/nets/172.16.2.0_24</tt> и вызвать <tt>mknb <ARCH></tt>.


Дополнительную информацию о discovery для сети, построенной с использованием свитчей, можно получить
Дополнительную информацию о discovery для сети, построенной с использованием свитчей, можно получить
[http://sourceforge.net/apps/mediawiki/xcat/index.php?title=Node_Discovery здесь].
[http://sourceforge.net/apps/mediawiki/xcat/index.php?title=Node_Discovery здесь].


== Template records ==
==KVM==
 
'''Гостевой-узел''' - выполняется на хост узле.
 
'''Хост-узел''' - способен выполнять гостевые узлы.


Все таблицы в базе данных xCAT можно условно разделить на две категории:
На одном хост-узле, может выполняться одновременно несколько хост-узлов.
# таблицы, которые определяют параметры узлов. В таких таблицах задаются параметры узла.
# таблицы, которые хранят параметры, не связанные со свойствами узлов. Значения в таких таких таблицах довольно прямолинейны. Данные сохраняются как есть, без дальнейшей интерпретации и без наследования (например, <tt>nodehm.power</tt> наследуются из <tt>nodehm.mgt</tt>).


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


Правила:
Установка хост-узла может протекать по двум сценариям.
Администратор должен выбрать наиболее подходящий вариант установки хост-узла, в зависимости от сложившейся ситуации.


* В поле <tt>имя узла</tt> можно использовать имя группы. Такая запись будет применяться для всех узлов, состоящих в группе. Когда требуется получить параметр для некого узла, и записи явно для данного узла не существует, тогда берётся соответствующая запись определённая для группы, в которую входит данный узел. Если параметры заданы для нескольких групп, в которые входит узел, тогда преимущество отдаётся первой группе указанной в поле <tt>nodelist.groups</tt> для этого узла.
Сценарии:
# инсталяция statefull хост-узла из kvm профиля.
# установка дополнительных пакетов, чтобы узел стал хост-узлом.


* Параметр узла может быть в следующем формате: /<tt>pattern</tt>/<tt>replacement</tt>/.
====Вариант 1: инсталяция statefull хост-узла из kvm профиля====
где <tt>pattern</tt>:
: регулярное выражение на языке Perl
: применяется к имени узла


Например, дано:
Стандартный профиль для statefull хост-узла находится в: <tt>/usr/share/xcat/install/alt/kvm.tmpl</tt>
*# Таблица <tt>ipmi</tt>
*# Поле <tt>ipmi.node=ipmi</tt>
*# Поле <tt>ipmi.bmc</tt> установлено в <tt>/\z/-bmc/</tt>
Тогда значение поля <tt>ipmi.bmc</tt> для конкретного узла, входящего в состав группы <tt>ipmi</tt>, будет сформировано с добавлением <tt>-bmc</tt>.


* В регулярных выражениях также можно использовать арифметические операции. Синтаксис: <tt>|pattern|replacement|</tt>. Часть заключённая между скобками <tt>()</tt> в <tt>replacement</tt> указывает некое арифметическое действие. Операции выполняются над целыми числами. Например, <tt>5/4</tt>
При использовании профиля <tt>kvm.tmpl</tt> в момент установки (развертывания) хост-узла будет использован список с дополнительными пакетами:
выдаст <tt>1</tt>.
<tt>/usr/share/xcat/install/alt/kvm.installer.pkglist</tt>.


Дано:
Внимание: эти пакеты должны быть доступны на установочном CD.
*# имена узлов имеют вид: <tt>blade1, blade2...</tt>
*# имена management modules имеют вид: <tt>amm1, amm2, ...</tt>
*# таблица <tt>mp</tt>
Тогда можно в одну строку записать следующие правило:
#node,mpa,id,comments,disable
"blade","|\D+(\d+)|amm(($1-1)/14+1)|","|\D+(\d+)|(($1-1)%14+1)|",,
где:
: <tt>blade</tt> - имя группы. В этом примере мы предполагаем, что все узлы <tt>blade1, blade2...</tt> пренадлежат этой группе.
Таблица <tt>mp</tt> опрашивается когда необходимо получить management module и slot number для конкретного узла (например, <tt>blade20</tt>).
Данная строка сработает, поскольку <tt>blade20</tt> находится в группе <tt>blade</tt>.
: <tt>|\D+(\d+)|amm(($1-1)/14+1)|</tt> - выражение замены на языке Perl. Генерирует значение для второй колонки <tt>mp.mpa</tt>. <tt>\D+(\d+)</tt> - регулярное выражение, которое совпадает с именем узла (<tt>blade20</tt>). Текст совпавший с <tt>(\d+)</tt> будет назначен <tt>$1</tt>. В нашем примере <tt>\D+</tt> совпадёт с нечисловой частью имени (blade) и <tt>\d+</tt> совпадёт с числовой частью имени узла (20). Таким образом, переменная <tt>$1</tt> будет равна 20.
: <tt>amm(($1-1)/14+1)</tt> - генерирует строку, которая будет возвращена в качестве значения поля <tt>mp.mpa</tt> для узла <tt>node1</tt>. Поскольку <tt>$1</tt> равно 20, выражение <tt>($1-1)/14+1</tt> равно <tt>19/14 + 1 = 2</tt>. Т.е. строка <tt>amm2</tt> будет использована как значение поля <tt>mp.mpa</tt>.


: <tt>|\D+(\d+)|(($1-1)%14+1)|</tt> - подобно предыдущему выражению, эта замена будет создавать значение для третей колонки <tt>mp.id</tt>.
После команды copycds росжатый ISO образ находится: /var/lib/xcat/alt/x86_64/.
Выражение <tt>($1-1)%14+1</tt> примет значение <tt>6</tt>.


Справку по регулярным выражениям на языке Perl можно получить тут [http://www.perl.com/doc/manual/html/pod/perlre.html тут].
====Вариант 2: установка дополнительных пакетов, чтобы узел стал хост-узлом====
[http://xcat.sourceforge.net/man5/xcatdb.5.html источник].


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


"userbmc","|\D+(\d+).*$|172.29.4.($1)|",,,
Следующий список содержит имена дополнительных пакетов, которые необходимо установить на узел, чтобы он стал хост-узлом:


== prescripts ==
# cat /usr/share/xcat/install/alt/compute.otherpkgs.pkglist
  qemu-kvm
  libvirt
  perl-Sys-Virt
  bridge-utils
  qemu-system


Таблица <tt>prescripts</tt> позволяет задавать список скриптов, которые необходимо выполнить на узле.
При необходимости, этот список пакетов можно изменить:
  # tabdump prescripts
  # mkdir -p /var/lib/xcat/custom/install/alt
  #node,begin,end,comments,disable
  # cp /usr/share/xcat/install/alt/compute.otherpkgs.pkglist /var/lib/xcat/custom/install/alt/
# vim /var/lib/xcat/custom/install/alt/compute.otherpkgs.pkglist


Есть команда <tt>nodeset</tt>. Например:
Далее выполнить команду для установки этих пакетов. Смотри главу о установке дополнительного ПО на statefull узел:
# nodeset node5 install
# nodeset grp1 netboot


* Синтаксис полей <tt>prescripts.begin</tt> и <tt>prescripts.end</tt> одинаковый.
# updatenode hpc3 -V -S
* <tt>[action1:]s1,s2...[|action2:s3,s4,s5...]</tt>, где:
или
** <tt>s1,s2,s3,...</tt> - это имена скриптов.
# updatenode hpc3 -V -P otherpkgs
** <tt>action1, action2</tt> - второй аргумент команды <tt>nodeset</tt>
* Скрипты в поле <tt>beign</tt> выполняются до установки.
* Скрипты в поле <tt>end</tt> выполняются после установки.
* Все скрипты должны быть в каталоге <tt>/site.installdir/prescripts</tt>.
* Каждому скрипту во время выполнения передаются следующие переменные:
** <tt>NODES</tt> - спискок узлов, через запятую, на которых этот скрипт будет выполняться
** <tt>ACTION</tt> - в каком режим выполняется узел: <tt>install</tt>, <tt>netboot</tt> (см команду nodeset).


В теле скрипта можно указать строку:
Проверка:
<tt>#xCAT setting:MAX_INSTANCE=number</tt>. Тогда скрипт может выполняться параллельно не более чем на <tt>number</tt> узлах.


== Безопасность ==
[root@mn alt]# ssh hpc3
[root@hpc3 ~]# rpm -q qemu-kvm  libvirt perl-Sys-Virt bridge-utils qemu-system
qemu-kvm-0.12.4-alt1
libvirt-0.8.2-alt2
perl-Sys-Virt-0.2.2-alt1
bridge-utils-1.4-alt2
qemu-system-0.12.1-alt1


=== Таблица <tt>auditlog</tt> ===
На хост-узле должна работать служба libvirtd:
Все действия, которые проходят проверку на права доступа, записываются в таблицу <tt>auditlog</tt>.


  # tabdump auditlog
  [root@hpc3 ~]# virsh list
"2341","04-13-2010 20:55:52",,"sn2","other","getpostscript",,,"Allowed",,
  ID Имя              Статус
"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",,
 
====Общий каталог между Managment-узлом и Хост-узлами====


Администратор может указать в поле <tt>site.auditskipcmds</tt> команды через запятую, для которых нет необходимости вести протоколирование:
На сервере (<tt>noderes.nfsserver</tt>) нужно создать каталог, в котором будут храниться образа дисков гостевых-узлов.
Каталог должен размещаться на достаточно-большом хранилище. Допустим что образа дисков будут храниться по следующему пути:


  # chtab key=auditskipcmds site.value="tabdump,nodels,lsdef"
  # mkdir -p /var/lib/xcat/vms


Данная команда отключает протоколирование для команд: <tt>tabdump,nodels,lsdef</tt>
Необходимо изменить настройки NFS-сервера, чтобы данный каталог был доступен для хост-узлов на запись.
Добавим в конфигурационный файл NFS службы <tt>/etc/exports</tt> строку:


=== Таблица <tt>eventlog</tt> ===
# echo '/var/lib/xcat/vms *(rw,no_root_squash,sync,no_subtree_check)' >> /etc/exports
# service nfs restart


Хранит события, полученные мониторами.
Managment Node и хост-узлы должны иметь общий каталог, размещенный по одинаковому пути.
В <tt>/etc/fstab</tt> хост-узлов необходимо добавить запись, чтобы при загрузке хост-узла автоматически монтировалась общий сетевой каталог:


  # tabdump  eventlog
  $NFSSERVER:/var/lib/xcat/vms /var/lib/xcat/vms nfs rsize=8192,wsize=8192,timeo=14,intr,nfsvers=2 1 2
#recid,eventtime,eventtype,monitor,monnode,node,application,component,id,severity,message,rawdata,comments,disable


Это можно сделать, выполнив разово post-скрипты для нужных хост-узлов:


<tt>tabprune</tt> - удаляет записи из таблиц <tt>auditlog</tt> и <tt>eventlog</tt>.
# updatenode hpc3 -V -P mountvms


Проверка:


Вызвать команду <tt>tabedit</tt> для таблиц <tt>auditlog</tt> и <tt>eventlog</tt> не получится, так как будет нарушен индекс.
[root@mn alt]# ssh hpc3
[root@hpc3 ~]# mount | grep vms
172.16.2.2:/var/lib/xcat/vms on /var/lib/xcat/vms type nfs (rw,rsize=8192,wsize=8192,timeo=14,intr,nfsvers=2,addr=172.16.2.2)


== Динамические группы ==
====Настройка Managment узла====


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


Есть следующие таблицы:
* qemu-system
* <tt>nodelist</tt> - статическая принадлежность узла к группе. Задаёт администратор.
* qemu-user
* <tt>nodegroup</tt> - динамическая принадлежность узла к группе. Узел заносится автоматически на основании неких свойств узла.


Операции над динамическими группами можно условно разделить на две части:
====Настройка Хост-узлов====
# create/delete (<tt>tabedit</tt>), display (<tt>tabdump</tt>), modify (<tt>chtab</tt>)
# Передавать имя динамической группы в качестве аргумента для любой команды xCAT.


Например:
Настройка хост-узлов проводится post-скриптом <tt>mkhyperv</tt>.


  # chtab groupname=grp1 nodegroup.grouptype=dynamic nodegroup.wherevals="mgt=hmc,hcp=c76v1hmc04"
Его можно выполнить разово вручную:
  # updatenode hpc3 -V -P mkhyperv
или добавить в таблицу postscripts, чтобы он выпонялся автоматически для всех вновь установленных узлов:
# nodech x01 postscripts.postscripts,=mountvms
postscripts.postscripts - after installation or diskless boot.


Создаёт/изменяет динамическую группу <tt>grp1</tt>.
Проверка:
К этой группе будут относится узлы, у которых (OR AND ?):
# работает служба libvirtd:
* <tt>mgt=hmc</tt>
[root@mn alt]# ssh hpc3
* <tt>hpc=c76v1hmc04</tt>
[root@hpc3 ~]# virsh list
  ID Имя              Статус
  ----------------------------------
# правильно настроена сеть
# brctl show
bridge name    bridge id              STP enabled    interfaces
xcat-guests            8000.001517bd9729      no              eth1
                                                        vnet0
                                                        vnet1
                                                        vnet2
                                                        vnet3
                                                        vnet4


Для просмотра всех возможных атрибутов узла, по которым можно задавать их принадлежность к динамической группе:
# chdef -h -t node


Команды:
====Создание гостевых узлов====
* <tt>mkdef</tt> - позволяет создать динамическую группу указав флаг <tt>-d | --dynamic</tt>
* <tt>chdef</tt> - изменят свойства динамической группы. Для каждого ключа <tt>-w</tt> можно задать пару <tt>АТРИБУТ_УЗЛА</tt> и <tt>ЗНАЧЕНИЕ</tt>.
* Соотношения между <tt>АТРИБУТ_УЗЛА</tt> и <tt>ЗНАЧЕНИЕ</tt> задается операциями: <tt>== =~ != !~</tt>


Следует заметить о возможных конфликтах. Когда узел относится к динамической группе, согласно некоторым критериям, тогда, невозможно добавить данный узел в эту же группу статически.
# nodeadd v1-v4 groups=kvm,all
# chtab node=kvm hosts.ip='|\D+(\d+)|172.16.2.(150+$1)|'
# makehosts vm
# makedns
# service bind restart
# chtab node=kvm vm.migrationdest=hpc3 vm.memory=1024 vm.cpus=2 vm.nics="xcat-guests" vm.bootorder="network,hd"
# chtab node=kvm vm.vncport='|\D+(\d+)|($1)|'
# chtab node=kvm vm.storage='|^(.+)$|/var/lib/xcat/vms/($1)|'
# chtab node=kvm nodehm.mgt=kvm nodehm.serialport=0 nodehm.serialspeed=115200
# chtab node=kvm nodetype.os=alt nodetype.arch=x86 nodetype.profile=compute nodetype.nodetype=osi
# chtab node=kvm noderes.netboot=pxe noderes.tftpserver=172.16.2.2 noderes.nfsserver=172.16.2.2 noderes.primarynic=eth0
# mkvm v1-v4 -s 20G
# tabdump kvm_nodedata
# rpower v1-v4,v6 boot


== Мониторинг ==
# tabdump mac
#node,interface,mac,comments,disable
"hpc3",,"00:15:17:bd:97:29",,
"cn-1",,"1a:1a:1a:1a:1a:21",,
"v1",,"1e:86:ac:10:02:c9",,
"v4",,"0a:80:ac:10:02:cc",,
"v2",,"e2:8f:ac:10:02:ca",,
"v3",,"02:b1:ac:10:02:cb",,
"v6",,"6a:ee:ac:10:02:ce",,


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


Список доступных модулей можно посмотреть следующей командой:
Может ли stateless узел быть хост-системой?


# monls -a
== Template records ==
snmpmon        monitored
 
xcatmon        not-monitored
Все таблицы в базе данных xCAT можно условно разделить на две категории:
pcpmon          not-monitored
# таблицы, которые определяют параметры узлов. В таких таблицах задаются параметры узла.
gangliamon      not-monitored
# таблицы, которые хранят параметры, не связанные со свойствами узлов. Значения в таких таких таблицах довольно прямолинейны. Данные сохраняются как есть, без дальнейшей интерпретации и без наследования (например, <tt>nodehm.power</tt> наследуются из <tt>nodehm.mgt</tt>).


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


# monls -d xcatmon
Правила:
xcatmon        not-monitored
  Description:
    xcatmon uses fping to report the node liveness status and update the ...


Используемые таблицы:
* В поле <tt>имя узла</tt> можно использовать имя группы. Такая запись будет применяться для всех узлов, состоящих в группе. Когда требуется получить параметр для некого узла, и записи явно для данного узла не существует, тогда берётся соответствующая запись определённая для группы, в которую входит данный узел. Если параметры заданы для нескольких групп, в которые входит узел, тогда преимущество отдаётся первой группе указанной в поле <tt>nodelist.groups</tt> для этого узла.


# <tt>monitoring</tt>
* Параметр узла может быть в следующем формате: /<tt>pattern</tt>/<tt>replacement</tt>/.
** подключён модуль
где <tt>pattern</tt>:
** используется \ не используется модуль (поле <tt>disabled</tt>)
: регулярное выражение на языке Perl
** используется ли отслеживание активности вычислительных узлов (поле <tt>nodestatmon</tt>)
: применяется к имени узла
# <tt>monsetting</tt> содержит специфические настройки в отдельности для каждого модуля


Более детальную информацию можно узнать из: [http://xcat.svn.sourceforge.net/viewvc/xcat/xcat-core/trunk/xCAT-client/share/doc/xCAT2-Monitoring.pdf официального источника]
Например, пусть имеются:
*# Таблица <tt>ipmi</tt>
*# Поле <tt>ipmi.node=ipmi</tt>
*# Поле <tt>ipmi.bmc</tt> установлено в <tt>/\z/-bmc/</tt>


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


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


1. Узнаем доступные параметры модуля, которые задаются при регистрации.
Пусть имеются:
# monls -d xcatmon
*# имена узлов, имеющие вид: <tt>blade1, blade2...</tt>
...
*# имена management modules, имеющие вид: <tt>amm1, amm2, ...</tt>
  Support node status monitoring:
*# таблица <tt>mp</tt>
    Yes
Видим, что модуль xcatmon позволяет использовать опцию <tt>-n</tt>.


2. Зарегистрируем модуль:
Тогда можно в одну строку записать следующие правило:
  # monadd xcatmon -n -s ping-interval=4
  #node,mpa,id,comments,disable
"blade","|\D+(\d+)|amm(($1-1)/14+1)|","|\D+(\d+)|(($1-1)%14+1)|",,
где:
: <tt>blade</tt> - имя группы. В этом примере мы предполагаем, что все узлы <tt>blade1, blade2...</tt> принадлежат этой группе.
Таблица <tt>mp</tt> опрашивается, когда необходимо получить management module и slot number для конкретного узла (например, <tt>blade20</tt>).
Данная строка сработает, поскольку <tt>blade20</tt> находится в группе <tt>blade</tt>.
: <tt>|\D+(\d+)|amm(($1-1)/14+1)|</tt> - выражение замены на языке Perl. Генерирует значение для второй колонки <tt>mp.mpa</tt>. <tt>\D+(\d+)</tt> - регулярное выражение, которое совпадает с именем узла (<tt>blade20</tt>). Текст совпавший с <tt>(\d+)</tt> будет назначен <tt>$1</tt>. В нашем примере <tt>\D+</tt> совпадёт с нечисловой частью имени (blade) и <tt>\d+</tt> совпадёт с числовой частью имени узла (20). Таким образом, переменная <tt>$1</tt> будет равна 20.
: <tt>amm(($1-1)/14+1)</tt> - генерирует строку, которая будет возвращена в качестве значения поля <tt>mp.mpa</tt> для узла <tt>node1</tt>. Поскольку <tt>$1</tt> равно 20, выражение <tt>($1-1)/14+1</tt> равно <tt>19/14 + 1 = 2</tt>. Т.е. строка <tt>amm2</tt> будет использована как значение поля <tt>mp.mpa</tt>.


3. Проверим, что модуль xcatmon зарегистрирован для отслеживания состояния узлов, но не активный (<tt>disable</tt>=1):
: <tt>|\D+(\d+)|(($1-1)%14+1)|</tt> - подобно предыдущему выражению, эта замена будет создавать значение для третей колонки <tt>mp.id</tt>.
# tabdump monitoring
Выражение <tt>($1-1)%14+1</tt> примет значение <tt>6</tt>.
#name,nodestatmon,comments,disable
"xcatmon","Y",,"1"


4. Параметры с которыми зарегистрирован модуль:
Справку по регулярным выражениям на языке Perl можно получить по адресу [http://www.perl.com/doc/manual/html/pod/perlre.html].
# tabdump monsetting
[http://xcat.sourceforge.net/man5/xcatdb.5.html].
#name,key,value,comments,disable
"xcatmon","ping-interval","4",,


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


6. Чтобы начать мониторинг:
"userbmc","|\D+(\d+).*$|172.29.4.($1)|",,,
# monstart xcatmon


После чего будет автоматически добавлена строка для <tt>cron</tt>:
== Таблица prescripts ==
# 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. При выключенном узле <tt>node1</tt> получим:
Таблица <tt>prescripts</tt> позволяет задавать список скриптов, которые необходимо выполнить на узле.
# tabdump nodelist
  # tabdump prescripts
#node,groups,status,appstatus,primarysn,comments,disable
  node,begin,end,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. Чтобы настроить проверку других служб на узлах следует отредактировать таблицу <tt>monsetting</tt>.
* Синтаксис полей <tt>prescripts.begin</tt> и <tt>prescripts.end</tt> одинаковый.
* <tt>[action1:]s1,s2...[|action2:s3,s4,s5...]</tt>, где:
** <tt>s1,s2,s3,...</tt> - это имена скриптов.
** <tt>action1, action2</tt> - второй аргумент команды <tt>nodeset</tt>
* Скрипты в поле <tt>beign</tt> выполняются до установки.
* Скрипты в поле <tt>end</tt> выполняются после установки.
* Все скрипты должны быть в каталоге <tt>/site.installdir/prescripts</tt>.
* Каждому скрипту во время выполнения передаются следующие переменные:
** <tt>NODES</tt> - спискок узлов, через запятую, на которых этот скрипт будет выполняться
** <tt>ACTION</tt> - в каком режим выполняется узел: <tt>install</tt>, <tt>netboot</tt> (см команду nodeset).


9. Приостановить работу модуля xcatmon можно:
В теле скрипта можно указать строку:
# monstop xcatmon
<tt>#xCAT setting:MAX_INSTANCE=number</tt>. Тогда скрипт может выполняться параллельно, но не более, чем на <tt>number</tt> узлах.
mn.cluster: stopped.
# crontab -l


== Синхронизация файлов ==
== Безопасность ==
Основной документ: <tt>xCAT2SyncFilesHowTo.pdf</tt>, <tt>man xdcp</tt>


Команда <tt>xdcp</tt> позволяет производить синхронизацию файлов как с Managеment Node на Compute Node, так и в обратном направлении.
=== Таблица <tt>auditlog</tt> ===
Все действия, которые проходят проверку на права доступа, записываются в таблицу <tt>auditlog</tt>.


Список фалов для синхронизации можно задать для:
# tabdump auditlog
# Узлов, которые используют один профиль osimage.
"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",,
 
Администратор может указать в поле <tt>site.auditskipcmds</tt> команды через запятую, для которых нет необходимости вести протоколирование:


Опции для команды <tt>xdcp</tt>
# chtab key=auditskipcmds site.value="tabdump,nodels,lsdef"
# -F | --File <synclist> - список с файлами.  
# -i | --rootimg <PATH> - путь к файлам на MN для синхронизации.
# -R | --recursive - копирует рекурсивно каталог
# -T | --trace - отображать ход копирования
# -P | --pull - скопировать с узла
# -f | --fanout - максимальное количество одновременных экземпляров scp


Комманда <tt>xdcp</tt> поддерживает иерархию:
Данная команда отключает протоколирование для команд: <tt>tabdump,nodels,lsdef</tt>.
Managеment Node -> Service Node -> Compute Node
Сначала файлы подлежащие синхронизации загружаются на SN (<tt>site.SNsyncfiledir</tt>), потом на CN.


Принудительно синхронизировать файлы можно, вызвав команду <tt>updatenode <noderange> -F -V</tt>.
=== Таблица <tt>eventlog</tt> ===
Команда <tt>updatenode</tt> также поддерживает иерархию узлов. В основе <tt>updatenode</tt> лежит вызов <tt>xdcp</tt>.


Для fullstate узлов post-скрипт <tt>syncfiles</tt> выполняется сразу после установки ОС на узел.
Хранит события, полученные мониторами.
Список файлов для синхронизации перечисляется в <tt>/var/lib/xcat/custom/<install|netboot>/alt/<profile>.<os>.<arch>.synclist</tt>
Post скрипт <tt>syncfiles</tt> посылает сообщение к SN или MN, в ответ на которое будет запущена команда <tt>xdcp</tt> для узла.


Синтаксис файла синхронизации:
# tabdump  eventlog
  /full/path/of/the/source/file/on/the/MN -> /full/path/of/the/destination/file/on/target/node
  recid,eventtime,eventtype,monitor,monnode,node,application,component,id,severity,message,rawdata,comments,disable
/path1/file1 /path2/file2 -> /full/path/of/the/destination/directory
При отсутствии каталога назначения он будет автоматически создан.


Примеры:
# xdcp -i /install/netboot/fedora9/x86_64/compute/rootimg -F /tmp/myrsync


Команда <tt>psh</tt> - позволяет выполнить команду параллельно на нескольких узлах.
Команда <tt>tabprune</tt> - удаляет записи из таблиц <tt>auditlog</tt> и <tt>eventlog</tt>.
Команда <tt>xdsh</tt> - ???


# xdsh -e u /var/xvat/syncfiles
'''Примечание:''' Вызвать команду <tt>tabedit</tt> для таблиц <tt>auditlog</tt> и <tt>eventlog</tt> не получится, так как будет нарушен индекс.


== Установка дополнительного ПО ==
== Динамические группы ==


На Managеment Node необходимо создать список пакетов, которые необходимо установить.
Исходя из свойств узла, данный узел автоматически добавляется в группы.
Принадлежность узла к группе основана на характеристиках узла.


# Для diskless узлов списки с дополнительными пакетами находятся в <tt>/var/lib/xcat/custom/netboot/alt/</tt>.
Имеются следующие таблицы, описывающие принадлежность узлов:
# Для fullstate узлов списки с именами пакетов находятся в <tt>/var/lib/xcat/custom/install/alt/</tt>.
* <tt>nodelist</tt> - статическая принадлежность узла к группе. Задаётся администратором.
# Расположение каталога со списками пакетов можно также задать в таблице: <tt>linuximage.otherpkglist</tt>
* <tt>nodegroup</tt> - динамическая принадлежность узла к группе. Узел заносится автоматически на основании некоторых свойств узла.


Имя файла со списком может иметь вид:
Операции над динамическими группами можно условно разделить на две части:
* <tt><profile>.<os>.<arch>.otherpkgs.pkglist</tt>
# create/delete (<tt>tabedit</tt>), display (<tt>tabdump</tt>), modify (<tt>chtab</tt>)
* <tt><profile>.<os>.otherpkgs.pkglist</tt>
# Передавать имя динамической группы в качестве аргумента для любой команды xCAT.
* <tt><profile>.<arch>.otherpkgs.pkglist</tt>
* <tt><profile>.otherpkgs.pkglist</tt>


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


  # nodels node1 nodetype.os nodetype.arch nodetype.profile
  # chtab groupname=grp1 nodegroup.grouptype=dynamic nodegroup.wherevals="mgt=hmc,hcp=c76v1hmc04"
node1: nodetype.profile: compute
node1: nodetype.arch: x86_64
node1: nodetype.os: alt


Дополнительные пакеты должны размещаться в APT-репозитории. Репозиторий не зависит от используемого профиля:
Создаёт/изменяет динамическую группу <tt>grp1</tt>.
# mkdir -p /var/lib/xcat/post/otherpkgs/alt
К этой группе будут относится узлы, у которых:
# genbasedir --create --flat --bloat --progress --topdir=/var/lib/xcat/post/otherpkgs/alt x86_64 xcat
* <tt>mgt=hmc</tt>
# mkdir /var/lib/xcat/post/otherpkgs/alt/x86_64/RPMS.xcat
* <tt>hpc=c76v1hmc04</tt>
# в каталог /var/lib/xcat/post/otherpkgs/alt/x86_64/RPMS.xcat необходимо скопировать RPM пакеты которые планируется установить.
Ответственность замкнутости по зависимостям в каталоге <tt>/var/lib/xcat/post/otherpkgs/<os>/<arch></tt> ложится на администратора.


=== Stateless ===
Для просмотра всех возможных атрибутов узла, по которым можно задавать их принадлежность к динамической группе, следует выполнить команду:
# chdef -h -t node


Дополнительные пакеты инсталлируются сразу в образ для сетевой загрузки при вызове команды <tt>genimage</tt>.
О командах:
Обновить программное обеспечение на работающем diskless узле возможности нет:
* <tt>mkdef</tt> - команда, позволяющая создать динамическую группу, указав флаг <tt>-d | --dynamic</tt>;
# updatenode node1 -S
* <tt>chdef</tt> - команда, изменяющая свойства динамической группы. Для каждого ключа <tt>-w</tt> можно задать пару <tt>АТРИБУТ_УЗЛА</tt> и <tt>ЗНАЧЕНИЕ</tt>.
Error: updatenode command does not support software maintenance to diskless node.
* Соотношения между <tt>АТРИБУТ_УЗЛА</tt> и <tt>ЗНАЧЕНИЕ</tt> задается операторами: <tt>== =~ != !~</tt>


=== 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


<tt>xcatdsklspost</tt>:
xCAT использует модульную архитектуру для мониторинга работы кластера. В зависимости от задач, можно использовать различные средства мониторинга. Для каждой системы мониторинга используется отдельный модуль.
# сделает запрос к Management Node (xcatd)
# будет вызвана часть xcatd - <tt>getpostscript.pm</tt> -> <tt>Postage.pm</tt>
# сервер xcatd сгенерит и передаст его post-script вычислительному узлу.
# xcatdsklspost сохранит его под именем<tt>/tmp/mypostscript</tt>.


Внутри этого скрипта будут определены переменные:
Список доступных модулей можно посмотреть следующей командой:
* $OTHERPKGS<N> - поле <tt>linuximage.otherpkglist</tt> - указывает на список дополнительных пакетов. Этот список может включать другие списки.
* $OTHERPKGS_INDEX - сколько списков пакетов получилось в итоге после того, как были обработаны все включенные списки.
* $OHTERPKGSDIR - равно полю linuximage.otherpkgdir
* Будет вызван сам скрипт <tt>otherpkgs[.alt]</tt>


=== Установка ПО на работающем fullstate узле ===
# monls -a
snmpmon        monitored
xcatmon        not-monitored
pcpmon          not-monitored
gangliamon      not-monitored


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


'''Первый шаг''' - на Managment Node нужно создать sources.list для Compute узлов.
# monls -d xcatmon
xcatmon        not-monitored
  Description:
    xcatmon uses fping to report the node liveness status and update the ...


Для каждой отдельной архитектуры и версии 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 узлы имеют доступ к серверу <tt>salto</tt>.
Возможен случай, что Compute Node монтируют NFS-ресурс, тогда sources.list можно переписать как:
rpm file:/mnt/server/Sisyphus x86_64 classic
rpm file:/mnt/server/Sisyphus noarch classic


'''Второй шаг''' - указать, куда поместить созданный sources.list на Compute узлах:
# <tt>monitoring</tt>
#* подключён модуль
#* используется \ не используется модуль (поле <tt>disabled</tt>)
#* используется ли отслеживание активности вычислительных узлов (поле <tt>nodestatmon</tt>)
# <tt>monsetting</tt> содержит специфические настройки в отдельности для каждого модуля


# cat /var/lib/xcat/custom/install/alt/kvm.alt.x86_64.synclist
Более детальную информацию можно узнать из: [http://xcat.svn.sourceforge.net/viewvc/xcat/xcat-core/trunk/xCAT-client/share/doc/xCAT2-Monitoring.pdf официального источника]
/etc/xcat/alt/nodes/sources.list_x86_64 -> /etc/apt/sources.list.d/xcat.list


'''Третий шаг''' - поместить на нужные Compute узлы созданный sources.list. Это можно сделать двумя способами:
=== xcatmon ===


* Если имя synclist соответствует используемому профилю узлов:
Рассмотрим на примере работу с модулем <tt>xcatmon</tt>. Для этого:
# updatenode <noderange> -V -F
* Для любой группы узлов
# xdcp <noderange> -F /var/lib/xcat/custom/install/alt/kvm.alt.x86_64.synclist


(на MN см.: # cat /tmp/rsync_hpc3)
1. Доступные параметры модуля, которые задаются при регистрации, выводятся следующей командой:
# monls -d xcatmon
...
  Support node status monitoring:
    Yes


'''Четвёртый шаг''' - создать список дополнительных пакетов, согласно используемому профилю:
Как видно, что модуль xcatmon позволяет использовать опцию <tt>-n</tt>.
/usr/share/xcat/install/alt/kvm.otherpkgs.pkglist


В списке можно использовать макросы:
2. Далее зарегистрируем модуль <tt>xcatmon</tt>:
  Рекурсивно включить другой список пакетов
  # monadd xcatmon -n -s ping-interval=4
#INCLUDE:/usr/share/xcat/install/alt/other#
Установить нижележащие пакеты отдельным шагом
#NEW_INSTALL_LIST#


'''Пятый шаг''' - указать для нужного профиля список дополнительных пакетов в <tt>linuximage.otherpkglist<tt>, причём поле <tt>linuximage.otherpkgdir</tt> можно оставить незаполненным.
3. Убедимся, что модуль <tt>xcatmon</tt> зарегистрирован для отслеживания состояния узлов, но не активен (<tt>disable</tt>=1):
  # gettab imagename=alt-x86_64-install-kvm linuximage.otherpkglist
# tabdump monitoring
  /usr/share/xcat/install/alt/kvm.otherpkgs.pkglist
  #name,nodestatmon,comments,disable
  "xcatmon","Y",,"1"


'''Шестой шаг''' - выполнить для нужных Compute узлов post-скрипт <tt>otherpkgs</tt>.
4. Параметры с которыми зарегистрирован модуль <tt>xcatmon</tt> выводятся командой:
  # updatenode <noderange> -P otherpkgs
  # tabdump monsetting
  или
  #name,key,value,comments,disable
  # updatenode <noderange> -S
  "xcatmon","ping-interval","4",,


(на CN см.: # cat /tmp/mypostscript)
5. О дополнительных параметрах для модуля <tt>xcatmon</tt> можно узнать из страницы руководства:
# man nodestat


===Выполнение скриптов===
6. Для начала мониторинга следует выполнить команду:
# monstart xcatmon


Из Managment Node на заданном noderange можно выполнить скрипт. Для этого необходимо:
После этого будет автоматически добавлена строка для <tt>cron</tt>:
# на MN скопировать скрипт в <tt>/var/lib/xcat/postscripts/</tt>
# crontab -l
# <tt>updatenode <noderange> <script></tt>
*/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. При выключенном узле <tt>node1</tt> получим:
# 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",,,


Все настройки xCAT хранятся в базе данных <tt>/etc/xact/###.sqlite</tt>.
8. Для того, чтобы настроить проверку других служб на узлах следует отредактировать таблицу <tt>monsetting</tt>.


Рабочую конфигурацию xCAT можно сохранить командой:
9. Приостановить работу модуля xcatmon можно следующей командой:
  # mkdir /tmp/backup
  # monstop xcatmon
  # dumpxCATdb -p /tmp/backup
  mn.cluster: stopped.
Восстановить сохраненные настройки можно командой:
  # crontab -l
  # restorexCATdb -p /tmp/backup


При восстановлении базы данных xCAT таблицы <tt>eventlog</tt>, <tt>auditlog</tt> по умолчанию не восстанавливаются.
== Синхронизация файлов ==
Чтобы восстановить таблицы <tt>eventlog</tt> и <tt>auditlog</tt> необходимо указать флаг <tt>-a</tt>.
Справочную информацию можно найти:
# [http://xcat.svn.sourceforge.net/viewvc/xcat/xcat-core/trunk/xCAT-client/share/doc/xCAT2SyncFilesHowTo.pdf] xCAT2SyncFilesHowTo.pdf
# man xdcp
# man updatenode


Можно сохранить только одну таблицу из БД. Например, чтобы сохранить таблицу <tt>site</tt>:
Команда <tt>xdcp</tt> позволяет производить синхронизацию файлов как с Managеment Node на Compute Node, так и в обратном направлении.
# tabdump site > /install/dbbackup/site.csv
Чтобы восстановить таблицу:
# tabrestore /install/dbbackup/site.csv


== Service Node ==
Список фалов для синхронизации можно задать для:
# ...узлов, которые используют один профиль osimage;
# ...каждого узла в отдельности;


Сокращения:
Опции для команды <tt>xdcp</tt>:
* MN - Managment Node. Центральный управляющий узел. В одном экземпляре на весь кластер.
# -F | --File <synclist> - список с файлами;
* SN - Service Node. Вспомогательный управляющий узел. Несколько на весь кластер.
# -i | --rootimg <PATH> - путь к файлам на Management Node для синхронизации;
* CN - Compute Node. Вычислительный узел. Как правило много.
# -R | --recursive - копирует рекурсивно каталог;
# -T | --trace - отображать ход копирования;
# -P | --pull - скопировать с узла;
# -f | --fanout - максимальное количество одновременных экземпляров scp;


xCAT позволяет создавать в дополнение к главному управляющему узлу MN вспомогательные узлы SN.
Команда <tt>xdcp</tt> поддерживает иерархию:
SN управляют и производят установку Linux для отдельных групп вычислительных узлов.
Managеment Node -> Service Node -> Compute Node
Сначала файлы подлежащие синхронизации загружаются на Service Node (<tt>site.SNsyncfiledir</tt>), затем на Compute Node.


* Чтобы узел работал как Management Node необходимо установить пакет <tt>xCAT</tt>.
Принудительно синхронизировать файлы можно, вызвав команду:
* Чтобы узел работал как Service Node необходимо установить meta-пакет <tt>xCATsn</tt>.
# updatenode <noderange> -F -V


Версии устанавливаемых RPM пакетов xCAT и xCATsn должны совпадать.
Команда <tt>updatenode</tt> также поддерживает иерархию узлов. В основе <tt>updatenode</tt> лежит вызов <tt>xdcp</tt>.


Модули xCAT определяют тип узла по наличию файла: <tt>/etc/xCATMN</tt> или <tt>/etc/xCATSN</tt>.
Для fullstate узлов post-скрипт <tt>syncfiles</tt> выполняется сразу после установки ОС на узел.
Список файлов для синхронизации перечисляется в <tt>/var/lib/xcat/custom/<install|netboot>/alt/<profile>.<os>.<arch>.synclist</tt>
Post скрипт <tt>syncfiles</tt> посылает сообщение к SN или MN, в ответ на которое будет запущена команда <tt>xdcp</tt> для узла.


Существует два режима для функционирования SN:
Синтаксис файла синхронизации:
* Каждый отдельный SN узел отвечает за свою группу CN узлов.
/full/path/of/the/source/file/on/the/MN -> /full/path/of/the/destination/file/on/target/node
* Пул SN узлов, которые совместно обслуживают CN. Любой SN из множества может обработать поступивший запрос.
/path1/file1 /path2/file2 -> /full/path/of/the/destination/directory
При отсутствии каталога назначения он будет автоматически создан.


По умолчанию MN использует БД SQLite.
Примеры:
БД SQLite не умеет работать с удалёнными клиентами.
# xdcp -i /install/netboot/fedora9/x86_64/compute/rootimg -F /tmp/myrsync
Для построения распределённого кластера с использованием SN надо мигрировать с SQLite на другую БД.
На MN следует установить одну из следующих БД:
* MySQL
* PostgreSQL
* IBM DB2
Каждая из этих БД, в отличие от SQLite, умеет работать с удалёнными клиентами.
SN узлы будут выступать клиентами к этим БД.


Настройка каждой их этих БД имеет свои определённые особенности. Более детально о настройке каждой БД можно узнать на официальной [http://xcat.svn.sourceforge.net/viewvc/xcat/xcat-core/trunk/xCAT-client/share/doc/index.html странице] c документацией xCAT.
Команды <tt>psh</tt> и <tt>xdsh</tt> - позволяют выполнять команды параллельно на нескольких узлах.


=== Конфигурация MySQL ===
# xdsh -e u /var/xvat/syncfiles


На 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


Необходимая информация:
На Managеment Node необходимо создать список пакетов, которые необходимо установить.
# Имя узла Management Node: <tt>mn.cluster</tt>
# База данных xCAT: <tt>xcatdb</tt>
# Имя пользователья для доступа к базе данных xCAT: <tt>xcatadmin</tt>
# Пароль пользователя <tt>xcatadmin</tt>: <tt>pass123</tt>


Настройка сервера MySQL в ALT Linux осуществляется в файле: <tt>/var/lib/mysql/my.cnf</tt>.
# Для diskless узлов списки с дополнительными пакетами находятся в <tt>/var/lib/xcat/custom/netboot/alt/</tt>.
Все Service Node узлы должны иметь удалённый доступ к БД. Для этого нужно закомментировать строку <tt>skip-networking</tt>.
# Для fullstate узлов списки с именами пакетов находятся в <tt>/var/lib/xcat/custom/install/alt/</tt>.
# Расположение каталога со списками пакетов можно также задать в таблице <tt>linuximage.otherpkglist</tt>.


# /usr/bin/mysql -u root -p
Имя файла со списком может иметь вид:
mysql > CREATE DATABASE xcatdb;
* <tt><profile>.<os>.<arch>.otherpkgs.pkglist</tt>
mysql> CREATE USER xcatadmin IDENTIFIED BY 'pass123';
* <tt><profile>.<os>.otherpkgs.pkglist</tt>
mysql> GRANT ALL on xcatdb.* TO xcatadmin@mn IDENTIFIED BY 'pass123';
* <tt><profile>.<arch>.otherpkgs.pkglist</tt> 
mysql> GRANT ALL on xcatdb.* TO xcatadmin@mn.cluster IDENTIFIED BY 'pass123';
* <tt><profile>.otherpkgs.pkglist</tt>
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';
  # nodels node1 nodetype.os nodetype.arch nodetype.profile
mysql> GRANT ALL on xcatdb.* TO xcatadmin@127.0.0.1 IDENTIFIED BY 'pass123';
  node1: nodetype.profile: compute
mysql> SELECT host, user FROM mysql.user;
  node1: nodetype.arch: x86_64
+-------------+-----------+
  node1: nodetype.os: alt
| host        | user      |
 
+-------------+-----------+
Дополнительные пакеты должны размещаться в APT-репозитории. Репозиторий не зависит от используемого профиля:
| %          | xcatadmin |
  # mkdir -p /var/lib/xcat/post/otherpkgs/alt
  | %.cluster  | xcatadmin |
# genbasedir --create --flat --bloat --progress --topdir=/var/lib/xcat/post/otherpkgs/alt x86_64 xcat
  | localhost  | root      |
  # mkdir /var/lib/xcat/post/otherpkgs/alt/x86_64/RPMS.xcat
  | mn          | xcatadmin |
   
  | mn.cluster  | xcatadmin |
В каталог /var/lib/xcat/post/otherpkgs/alt/x86_64/RPMS.xcat необходимо скопировать RPM пакеты которые планируется установить.
| sn1        | xcatadmin |
Ответственность за замкнутость по зависимостям в каталоге <tt>/var/lib/xcat/post/otherpkgs/<os>/<arch></tt> лежит на администраторе.
| 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:
=== Stateless ===
# mkdir backup
# dumpxCATdb -p backup


Файл <tt>/etc/xcat/cfgloc</tt> содержит параметры доступа к БД.
Дополнительные пакеты инсталлируются сразу в образ для сетевой загрузки при вызове команды <tt>genimage</tt>.
  # echo 'mysql:dbname=xcatdb;host=mn.cluster|xcatadmin|pass123' > /etc/xcat/cfgloc
Обновить программное обеспечение на работающем diskless узле возможности нет:
# chmod 0600 /etc/xcat/cfgloc
  # updatenode node1 -S
Error: updatenode command does not support software maintenance to diskless node.


Загрузить сохраненные настройки xCAT в базу MySQL напрямую, без использования службы xcatd.
=== Steteful ===
# XCATBYPASS=1 restorexCATdb -p backup
# service xcatd restart


После настройки БД на MN следует разрешить доступ для удалённых клиентов. Данная процедура специфична для каждой БД: <tt>man mysqlsetup</tt>.
# 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


==== mysqlsetup ====
Команда <tt>xcatdsklspost</tt>:
Чтобы упростить миграцию от SQLite, можно использовать утилиту <tt>mysqlsetup</tt>.
# сделает запрос к Management Node (xcatd);
# service mysqld stop
# будет вызвана часть xcatd - <tt>getpostscript.pm</tt> -> <tt>Postage.pm</tt>;
# service xcatd start
# сервер xcatd сгенерирует и передаст его post-script вычислительному узлу;
# mysqlsetup -i
# xcatdsklspost сохранит его под именем<tt>/tmp/mypostscript</tt>.


Если команда завершилась неудачно, необходимо отменить её недоделанную работу:
Внутри этого скрипта будут определены переменные:
# mysql -u root -p mysql
* $OTHERPKGS<N> - поле <tt>linuximage.otherpkglist</tt> - указывает на список дополнительных пакетов. Этот список может включать другие списки.
> show databases;
* $OTHERPKGS_INDEX - сколько списков пакетов получилось в итоге после того, как были обработаны все включенные списки.
> show tables;
* $OHTERPKGSDIR - равно полю linuximage.otherpkgdir
> select User,Host FROM user;
* Будет вызван сам скрипт <tt>otherpkgs[.alt]</tt>
> DELETE from user where User = 'xcatadmin';
> drop database xcatdb;
> flush privileges;
> quit;
# rm -f /etc/xcat/cfgloc
# service xcatd restart # вернулись на SQLite
# mysqlsetup -i


Необходимо указать явно, из каких адресов имеет право авторизироваться пользователь <tt>xcatadmin</tt> (Service Nodes).
=== Установка ПО на работающем fullstate узле ===
Для этого необходимо создать файл со списком разрешённых хостов:
 
'''Внимание:''' этот метод установки дополнительного ПО является неофициальным и подходит только для дистрибутивов ОС ALT Linux.


# cat allowed_hosts
'''Первый шаг''' - на Managment Node необходимо создать sources.list для Compute узлов.
node1
1.115.85.2
10.%.%.%
nodex.cluster.net


  # mysqlsetup -u -f allowed_hosts -V
Для каждой отдельной архитектуры и версии ОС ALT Linux создается свой sources.list. Информацию по написанию sources.list файлов можно получить из страницы руководства:
  # chkconfig mysqld on
# 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 узлы имеют доступ к серверу <tt>salto</tt>.
Возможен случай, что Compute Node монтируют NFS-ресурс, тогда sources.list можно переписать как:
rpm file:/mnt/server/Sisyphus x86_64 classic
  rpm file:/mnt/server/Sisyphus noarch classic


[http://www.pantz.org/software/mysql/mysqlcommands.html refcard]
'''Второй шаг''' - необходимо указать, куда поместить созданный sources.list на Compute узлах:


=== Management узел ===
# cat /var/lib/xcat/custom/install/alt/kvm.alt.x86_64.synclist
Для последующих настроек необходимо знать, на какое имя выписан сертификат MN:
  /etc/xcat/alt/nodes/sources.list_x86_64 -> /etc/apt/sources.list.d/xcat.list
  # openssl x509 -text -in /etc/xcat/cert/server-cert.pem -noout|grep Subject:
  this will display something like:
  Subject: CN=mn.cluster


Обновим таблицу <tt>policy</tt>:
'''Третий шаг''' - следует поместить на нужные Compute узлы созданный sources.list.
  # chtab priority=5 policy.name=<mn.cluster> policy.rule=allow
 
В итоге таблица <tt>policy</tt> должна содержать:
Это можно сделать двумя способами:
  #priority,name,host,commands,noderange,parameters,time,rule,comments,disable
* Если имя synclist соответствует используемому профилю узлов:
"1","root",,,,,,"allow",,
  # updatenode <noderange> -V -F
"2",,,"getbmcconfig",,,,"allow",,
* Для любой группы узлов:
"3",,,"nextdestiny",,,,"allow",,
  # xdcp <noderange> -F /var/lib/xcat/custom/install/alt/kvm.alt.x86_64.synclist
"4",,,"getdestiny",,,,"allow",,
"5","mn.cluster",,,,,,"allow",,


Необходимые значения для таблицы <tt>site</tt>:
(на Management Node см.: # cat /tmp/rsync_hpc3)
#key,value,comments,disable
"xcatiport","3002",,
"xcatdport","3001",,
"master","mn.cluster",,
Значание <tt>"master","mn.cluster"</tt> - это имя хоста под которым известен MN для SN.


=== Service узлы ===
'''Четвёртый шаг''' - создание списка дополнительных пакетов, согласно используемому профилю:
/usr/share/xcat/install/alt/kvm.otherpkgs.pkglist


xCAT предоставляет возможность устанавливать и настраивать Service Nodes непосредственно из Managment Node.
В списке можно использовать макросы:
Добавим два Service узла:
# nodeadd sn[1-2] groups=all,service
Service узлы должны быть соединены с Management узлом. От вычислительных узлов требуется чтобы они были соединены только со своим Service узлом. Прямой доступ к Management узлу для Compute узлов не требуется.


Для удобства можно все Service узлы занести в группу <tt>service</tt>. В дальнейшем это позволит обновить все Service узлы указав группу <tt>service</tt>.
''Рекурсивно включить другой список пакетов''
#INCLUDE:/usr/share/xcat/install/alt/other#
''Установить нижележащие пакеты отдельным шагом''
#NEW_INSTALL_LIST#


В таблице <tt>nodetype</tt> необходимо задать имя профиля для Service узлов:
'''Пятый шаг''' - указание для нужного профиля списка дополнительных пакетов в <tt>linuximage.otherpkglist</tt>, причём поле <tt>linuximage.otherpkgdir</tt> можно оставить незаполненным.
  # chdef -t group -o service arch=x86_64 os=alt nodetype=osi profile=service
  # gettab imagename=alt-x86_64-install-kvm linuximage.otherpkglist
  # tabdump nodetype
  /usr/share/xcat/install/alt/kvm.otherpkgs.pkglis
  #node,os,arch,profile,provmethod,supportedarchs,nodetype,commee
  # chtab imagename=alt-x86-install-compute linuximage.otherpkglist=/usr/share/xcat/install/alt/compute.otherpkgs.pkglist
"service","alt","x86_64","service",,,"osi",,


В таблице <tt>servicenode</tt> указываются:
'''Шестой шаг''' - выполнение для нужных Compute узлов post-скрипта <tt>otherpkgs</tt>.
* Service узлы или группы с Service узлами
# updatenode <noderange> -P otherpkgs
* какие службы будут выполняться на Service узлах.
или
В таблице <tt>servicenode</tt> '''ДОЛЖНЫ''' быть перечислены '''ВСЕ''' Service узлы, даже если они не будут выполнять никаких служб.
# updatenode <noderange> -S
По умолчанию xCAT подразумевает, что служба на данном Service отключена (<tt>0</tt> или <tt>no</tt>).


При запуске <tt>xcatd</tt> сервера на Service узле он обратится к таблице <tt>servicenode</tt>, чтобы узнать, какие службы должны выполнятся на этом Service узле. Проверка будет происходить каждый раз при перезапуске службы <tt>xcatd</tt>.
(на Compute Node см.: # cat /tmp/mypostscript)


Указать, какие службы будут выполняться на Service узле, можно с помощью:
=== Выполнение скриптов ===
# chdef -t group -o service setupnfs=1 setupnameserver=1 setuptftp=1
данная команда внесёт изменения в таблицу <tt>servicenode</tt>.


Настройку Service узлов выполняют post-скрипты:
Из Managment Node на заданном noderange можно выполнить скрипт. Для этого необходимо:
# chdef -t group -o service postscripts=servicenode,xcatserver,xcatclient
# На Management Node необходимо скопировать скрипт в <tt>/var/lib/xcat/postscripts/</tt>;
# Выполнить команду <tt>updatenode <noderange> <script></tt>;


Для корректной работы с Compute узлами необходимо задать два поля в таблице <tt>noderes</tt>:
== Востановление БД ==
* <tt>servicenode</tt> - имя Service узла известного со стороны Managment узла
* <tt>xcatmaster</tt> - имя Service узда известного для Compute узлов


Т.е. например:
Все настройки xCAT хранятся в базе данных <tt>/etc/xact/###.sqlite</tt>.
# 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 узлов будет использоваться <tt>pxe</tt> (<tt>xnba</tt>):
Рабочую конфигурацию xCAT можно сохранить командой:
# chdef -t group -o compute2,compute1,service netboot=pxe
# mkdir /tmp/backup
# dumpxCATdb -p /tmp/backup
 
Восстановить сохраненные настройки можно командой:
# restorexCATdb -p /tmp/backup


Зафиксировать тот факт, что группа Compute узлов обслуживается несколькими Service узлами, можно:
При восстановлении базы данных xCAT таблицы <tt>eventlog</tt>, <tt>auditlog</tt> по умолчанию не восстанавливаются.
# chdef -t node -o compute1 servicenode=sn1,sn2
Чтобы восстановить таблицы <tt>eventlog</tt> и <tt>auditlog</tt> необходимо указать флаг <tt>-a</tt>.
# chdef -t node -o compute2 servicenode=sn2,sn1
узлы, принадлежащее группе <tt>compute1</tt>, при установке будут использовать <tt>sn1</tt>. Если <tt>sn1</tt> будет недоступен, будет использоваться Service узел <tt>sn2</tt>. Тоже самое справедливо и для Compute узлов из группы <tt>compute2</tt>, только в обратном порядке.
Поля <tt>xcatmaster, tftpserver, nfsserver</tt> должны быть пустыми.


На Management узле следует задать значения для:
Можно сохранить только одну таблицу из БД.
* <tt>chtab key=installloc site.value=[hostname:]/install</tt>
Например, чтобы сохранить таблицу <tt>site</tt>, следует выполнить команду:
Если поле <tt>hostname</tt> отсутствует, тогда будет использовано имя Management узла.
# tabdump site > /install/dbbackup/site.csv
Данная опция указывает, что Service узлы будут монтировать себе в каталог <tt>/install</tt>. Если значение поля <tt>installloc</tt> не задано, тогда синхронизация каталогов <tt>/install</tt> Service узлов и Managment узла ложится на плечи администратора.
А чтобы восстановить эту же таблицу, выполним команду:
* <tt>chdef -t site -o clustersite sharedtftp=0</tt>
# tabrestore /install/dbbackup/site.csv
По умолчанию все Service узлы автоматически монтируют каталог <tt>tftpboot</tt>. Если используются пул из нескольких Service узлов, необходимо отключить авто-монтирование каталога <tt>tftpboot</tt>. Если Service узел является stateless, тогда значение каталога <tt>/var/lib/tftpboot</tt> будет потеряно при перезагрузке Service узла и прийдеся заново вызывать комманду <tt>nodeset</tt> для каждого Compute узла.
В поле <tt>site.sharedtftp</tt> можно задать имя хоста, с которого необходимо монтировать каталог <tt>tftpboot</tt>.


Для каждого адресного пространства кластера необходимо внести запись в таблицу <tt>networks</tt>.
== Service Node ==
# chtab net=10.3.1.0 networks.netname=public networks.disable=1
Если в сети присутствует пул Service узлов, тогда параметр:
* <tt>net.dhcpserver</tt> должен быть равен одному Service узлу из пула.
* <tt>net.tftpserver</tt> - сброшен
* <tt>net.namerserver</tt> - сброшен


В настройках Management узла для Compute узлов необходимо указать Service узел со службами мониторинга conserver/monserver:
Сокращения:
# chdef -t node -o compute1 conserver=sn1 monserver=sn1
* MN - Managment Node. Центральный управляющий узел. В одном экземпляре на весь кластер.
В случае использования пула Service узлов, необходимо явно выбрать некий Service узел и делегировать ему атрибуты в полях: <tt>nodehm.conserver</tt> и <tt>noderes.monserver</tt>.
* SN - Service Node. Вспомогательный управляющий узел. Несколько на весь кластер.
* CN - Compute Node. Вычислительный узел. Как правило много.
 
xCAT позволяет создавать в дополнение к главному управляющему узлу MN вспомогательные узлы SN.
SN управляют и производят установку Linux для отдельных групп вычислительных узлов.


Service узлы могут быть stateless или statefull.
* Чтобы узел работал как Management Node необходимо установить пакет <tt>xCAT</tt>.
* Чтобы узел работал как Service Node необходимо установить meta-пакет <tt>xCATsn</tt>.


Для Service узлов можно указать, разрешен ли IP-форвардинг в поле <tt>servicenode.ipforward</tt>.
Версии устанавливаемых RPM пакетов xCAT и xCATsn должны совпадать.


==== Stateless Service узлы ====
Модули xCAT определяют тип узла по наличию файла: <tt>/etc/xCATMN</tt> или <tt>/etc/xCATSN</tt>.


Цитата: '''Service nodes are the same OS and architecture as the management node.'''
Существует два режима для функционирования SN:
* Каждый отдельный SN узел отвечает за свою группу CN узлов.
* Пул SN узлов, которые совместно обслуживают CN. Любой SN из множества может обработать поступивший запрос.


При построении образа для Service узлов используется специальный профиль:
По умолчанию MN использует СУБД SQLite.
* <tt>service.pkglist</tt>. Можно использовать более частный случай: service.<DISTRO>.<ARCH>.pkglist
СУБД SQLite не умеет работать с удалёнными клиентами.  
* <tt>service.otherpkgs.pkglist</tt>, или <tt>service.<DISTRO>.<ARCH>.otherpkgs.pkglist</tt>
Для построения распределённого кластера с использованием SN надо мигрировать с SQLite на другую БД.
На MN следует установить одну из следующих СУБД:
* MySQL
* PostgreSQL
* IBM DB2


* <tt>/usr/xcat/share/xcat/netboot/alt</tt> - расположение стандартных списков с пакетами
Каждая из этих СУБД, в отличие от SQLite, умеет работать с удалёнными клиентами.
* <tt>/var/lib/xcat/custom/netboot/alt</tt> - в случае необходимости можно разместить изменённый список устанавливаемого ПО. Сюда также можно положить .postinstall файл (например <tt>compute.postinstall</tt>).
SN узлы будут выступать клиентами этих СУБД.


Репозиторий ALT Linux содержит пакеты xCAT, поэтому отпадает необходимость создавать локальный репозиторий с xCAT пакетами на Managуment узле для установки на Service узлах.
Настройка каждой их этих СУБД имеет свои определённые особенности. Более детально о настройке каждой СУБД можно узнать на официальной [http://xcat.svn.sourceforge.net/viewvc/xcat/xcat-core/trunk/xCAT-client/share/doc/index.html странице] c документацией xCAT.


Создать stateless образ Service узлов можно коммандой:
=== Конфигурация MySQL ===
# 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 узелы:
На Management Node следует установить RPM пакеты c MySQL сервером.
# packimage -o alt -p service -a x86_64
# nodeset service netboot
# rpower service boot


==== Diskfull Service узлы ====
Установка, первый запуск MySQL сервера и базовая настройка производится командами:
# apt-get install MySQL-server MySQL-client perl-DBD-mysql mysql-connector-odbc
# service mysqld start
# mysql_secure_installation
# chkconfig mysqld on


Установка Diskfull Service узла происходит аналогично установке Diskfull Compute узлу.
Необходимая информация:
Отличия будут состоят: в имени профиля и дополнительных post-скриптах.
# Имя узла Management Node: <tt>mn.cluster</tt>
# База данных xCAT: <tt>xcatdb</tt>
# Имя пользователя для доступа к базе данных xCAT: <tt>xcatadmin</tt>
# Пароль пользователя <tt>xcatadmin</tt>: <tt>pass123</tt>


/install/custom/netboot/fedora/service.ferdora8.x86_64.otherpkgs.pkglist -- add xCATsn
Настройка сервера MySQL в ОС ALT Linux осуществляется в файле: <tt>/var/lib/mysql/my.cnf</tt>.
# chdef -t group -o service postscripts=otherpkgs,servicenode,xcatserver,xcatclient
Все Service Node узлы должны иметь удалённый доступ к БД. Для этого нужно закомментировать строку <tt>skip-networking</tt>.
# nodeset service install
# rpower service boot


==== Post-скрипты ====
# /usr/bin/mysql -u root -p
 
mysql > CREATE DATABASE xcatdb;
На Service-узле должны отработать три post-скрипта:
mysql> CREATE USER xcatadmin IDENTIFIED BY 'pass123';
* <tt>servicenode</tt>
mysql> GRANT ALL on xcatdb.* TO xcatadmin@mn IDENTIFIED BY 'pass123';
** Налаживает доступ к БД Management узла
mysql> GRANT ALL on xcatdb.* TO xcatadmin@mn.cluster IDENTIFIED BY 'pass123';
** Вызывает <tt>copycerts</tt>
mysql> GRANT ALL on xcatdb.* TO xcatadmin@sn1 IDENTIFIED BY 'pass123';
** Создаёт каталог с post-скриптами <tt>/install/postscripts</tt>
mysql> GRANT ALL on xcatdb.* TO xcatadmin@sn1.cluster IDENTIFIED BY 'pass123';
** Закачивает с Managment узла сертификаты/ключи: <tt>/etc/xcat/cert/server-cred.pem</tt>
mysql> GRANT ALL on xcatdb.* TO xcatadmin@'%.cluster' IDENTIFIED BY 'pass123';
** Создаёт конфигурационный файл доступа к БД на Managеment узле: <tt>/etc/xcat/cfgloc</tt>
mysql> GRANT ALL on xcatdb.* TO xcatadmin@'8.113.33.%' IDENTIFIED BY 'pass123';
* <tt>xcatserver</tt>
mysql> GRANT ALL on xcatdb.* TO xcatadmin@127.0.0.1 IDENTIFIED BY 'pass123';
** <tt>/etc/xcat/cfgloc</tt>
mysql> SELECT host, user FROM mysql.user;
** <tt>/etc/xcat/cert/*</tt>
+-------------+-----------+
* <tt>xcatclient</tt>
| host        | user      |
/root/.xcat/client-cred.pem
+-------------+-----------+
/root/.xcat/ca.pem
| %          | xcatadmin |
 
| %.cluster  | xcatadmin |
==== Проверка ====
| localhost  | root      |
 
| mn          | xcatadmin |
* После инсталляции профиля Service узла, с Managment node должен быть доступен вход по ssh без пароля.
| mn.cluster  | xcatadmin |
* На Service узле должна выполняться служба <tt>xcatd</tt>.
| sn1        | xcatadmin |
* Следует убедится в том, что команды <tt>tabdump site</tt>, <tt>nodels</tt> могут получить доступ к БД с Service узла.
| sn1.cluster | xcatadmin |
* Убедится, что на Service узле смонтированы каталоги <tt>/var/lib/tftpboot</tt> и <tt>/var/lib/xcat</tt> с Management узла. В случае необходимости.
+-------------+-----------+
* Пароль для пользователя <tt>root</tt> на Service узлах должен быть равен значению <tt>passwd.system</tt>
7 rows in set (0.00 sec)
* Чтобы обновить ключи на Service узлах в группе <tt>service</tt> достаточно выполнить команду: <tt>xdsh service -K</tt>
mysql > SHOW VARIABLES;
* Файл <tt>/etc/xcat/cfgloc</tt> на Service и Management узлах должен быть одинаковым.
mysql > SHOW DATABASES;
* Каталог <tt>/etc/xcat/cert</tt> должен содержать файлы: <tt>ca.pem</tt> <tt>server-cred.pem</tt>
mysql > use xcatdb;
* Каталоги <tt>/etc/xcat/ca</tt> на Service и Management узлах должны быть почти одинаковы (см. <tt>servicenode</tt> post-скрипт).
mysql > SHOW TABLES;
* Каталог <tt>etc/xcat/hostkeys</tt> содержит SSH ключи, которые будут устанавливаться на Compute узлы. Этот каталог должны быть одинаковы на Service и Management узле.
mysql > DESCRIBE < table name >;
mysql > quit;


==== Замечания ====


Если для Service узла задан параметр <tt>chtab key=service servicenode.dhcpserver=1</tt>, тогда на Service узле будет запущен DHCP сервер, который будет слушать на <tt>"dhcpinterfaces","mn|eth0;service|eth1",,</tt>,
Для безопасности можно сделать резервную копию настроек xCAT следующими командами:
и команда <tt>makedhcp dmz1node1</tt> обновит файл на Service узле: <tt>/var/lib/dhcp/dhcpd/state/dhcpd.leases</tt>.
# mkdir backup
# dumpxCATdb -p backup


В документации xCAT2SetupHierarchy.pdf для Service узлов предлагается вручную отредактировать файл: <tt>/var/lib/xcat/netboot/alt/x86_64/service/rootimg/etc/exports</tt>
Файл <tt>/etc/xcat/cfgloc</tt> содержит параметры доступа к БД.
  /var/lib/tftpboot *(rw,no_root_squash,sync)
  # echo 'mysql:dbname=xcatdb;host=mn.cluster|xcatadmin|pass123' > /etc/xcat/cfgloc
  /var/lib/xcat *(rw,no_root_squash,sync)
  # chmod 0600 /etc/xcat/cfgloc


==== Service Node Pools ====
Загрузить сохраненные настройки xCAT в базу данных MySQL напрямую (без использования службы xcatd) можно командами:
# XCATBYPASS=1 restorexCATdb -p backup
# service xcatd restart


По состоянию на Апрель 2010 года, ситуация c Pools не очень ясна.
После настройки СУБД на MN следует разрешить доступ для удалённых клиентов. Данная процедура специфична для каждой СУБД:
В
# <tt>man mysqlsetup</tt>.
[http://sourceforge.net/mailarchive/forum.php?thread_name=OF37AC3175.7215C1CE-ON852576F8.005EAB6F-852576F8.00618A83%40us.ibm.com&forum_name=xcat-user рассылке]
говорится о:
# скудной документации
# не полной поддержке


Особенности:
==== mysqlsetup ====
* Необходимо спроектировать сеть так, чтобы все Сompute узлы и Service узлы находились в одном адресном пространстве.
* <tt>noderes.xcatmaster</tt> - может быть не определено. Тогда перечисленные Service узлы в <tt>noderes.servicenode</tt> будут обслуживать Compute узлы, вне зависимости от того, кто загрузил (pxe) Compute узел.
* <tt>site.dhcpinterfaces</tt> должен указывать на сетевые интерфейсы ведущие к Compute узлам, а не интерфейсы, соединяющие с Management узлом.


==== Stateless service node====
Чтобы упростить "миграцию" на SQLite (установку/настройку), можно использовать утилиту <tt>mysqlsetup</tt>.
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 ==
# service mysqld stop
# service xcatd start
# mysqlsetup -i


Клонируем официальный SVN репозиторий себе на локальную машину
Если команда завершилась неудачно, необходимо отменить её недоделанную работу:
  # rsync -av 'xcat.svn.sourceforge.net::svn/xcat/*' .
  # mysql -u root -p mysql
Исходники для RPM пакетов xCAT ведутся в git репозитории. Импортируем всю историю разработки xCAT в git репозиторий:
> show databases;
  # cat .git/config
> show tables;
  [svn-remote "svn"]
> select User,Host FROM user;
        url = file:///home/stanv/xcat.svn
> DELETE from user where User = 'xcatadmin';
        fetch = xcat-core/trunk:refs/remotes/trunk
> drop database xcatdb;
  # git svn fetch
> flush privileges;
Ветка remotes/trunk будет указывать на последний коммит в trunk SVN репозитории.
> quit;
  # rm -f /etc/xcat/cfgloc
  # service xcatd restart # вернулись на SQLite
# mysqlsetup -i


Ветка master соответствует исходному коду разработчиков, без каких либо изменений.
Необходимо указать явно, из каких адресов имеет право авторизироваться пользователь <tt>xcatadmin</tt> (Service Nodes).
# git checkout master
Для этого необходимо создать файл со списком разрешённых хостов:
# git merge remotes/trunk


Ветка patches содержит все наработки по адаптированию xCAT для ALT Linux.
  # cat allowed_hosts
  # git checkout patches
  node1
  # git merge -s subtree master
  1.115.85.2
При наличии конфликтов, исправляем их:
  10.%.%.%
  # git add конфликтыный_файл
  nodex.cluster.net
  # git commit
 
Втягиваем ветку patches в каждую ветку, отвечающую за отдельный RPM пакет. Например:
  # mysqlsetup -u -f allowed_hosts -V
  # git checkout perl-xCAT.rpm
# chkconfig mysqld on
# git merge patches # должно проходить гладко
Обновляем SPEC файл.
  # git push --all git.alt:/people/stanv/packages/xcat-core.git


== Исходный код xCAT ==
[http://www.pantz.org/software/mysql/mysqlcommands.html refcard]
x=`echo ${x#-}`


string_type=0;  # install rpm


result=`rpm -ev $plain_pkgs_preremove 2>&1`
====runsqlcmd====
          echo "$result"
Команда <tt>runsqlcmd</tt> позволяет выполнить набор SQL забросов к базе данных xCAT под управлением MySQL или PostgreSQL.
          if [ $? -ne 0 ]; then
На вход команде можно подать каталог с <tt>.sql</tt> файлами.
                logger "otherpkgs $result"
Файл содержащий SQL запросы должен иметь имя:
          fi
* <name>.sql
* <name>_<data‐base>.sql
Где:
* составляющая имени <name> может принимать любое значение.
* составляющая имени <data-base> может иметь одно из следующих значений:
** mysql
** pgsql
** db2
Файл содержащий SQL запрос должен иметь права: <tt>0755</tt>.
Более подробную информацию по использованию команды <tt>runsqlcmd</tt> можно узнать из страницы руководства:


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


=== Management узел ===
Для последующих настроек необходимо знать, на какое имя выписан сертификат MN. Для этого выполняется команда:
# openssl x509 -text -in /etc/xcat/cert/server-cert.pem -noout|grep Subject:
  this will display something like:
  Subject: CN=mn.cluster


Далее необходимо обновить таблицу <tt>policy</tt>:
# chtab priority=5 policy.name=<mn.cluster> policy.rule=allow


  # This is my comment. There are many others like it, but this one is mine.
В итоге таблица <tt>policy</tt> должна содержать:
  # My comment is my best friend. It is my life. I must master it as I must master my life.
  #priority,name,host,commands,noderange,parameters,time,rule,comments,disable
  # Without me, my comment is useless. Without my comment, I am useless.
  "1","root",,,,,,"allow",,
  # Jarrod to clean up.  It really should be in Table.pm and support
  "2",,,"getbmcconfig",,,,"allow",,
  # the new statelite $table notation.
  "3",,,"nextdestiny",,,,"allow",,
#I dislike spaces, tabs are cleaner, I'm too tired to change all the xCAT code.
  "4",,,"getdestiny",,,,"allow",,
  #I give in.
  "5","mn.cluster",,,,,,"allow",,


Необходимые значения для таблицы <tt>site</tt>:
#key,value,comments,disable
"xcatiport","3002",,
"xcatdport","3001",,
"master","mn.cluster",,


# Универсальность:
Значение <tt>"master","mn.cluster"</tt> - это имя хоста под которым известен MN для SN.
            foreach (</var/named/db.*>) {
 
                unlink $_;
=== Service узлы ===
            }
            foreach (</var/lib/named/db.*>) {
                unlink $_;
            }


# Реальные пацаны используют перл вот так:
xCAT предоставляет возможность устанавливать и настраивать Service Nodes непосредственно из Managment Node.
        } else {
        use File::Path;
        mkpath "/var/named/";


  # IBM China Software Development Laboratory
Например, можно добавить два Service узла:
  # nodeadd sn[1-2] groups=all,service


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
Service узлы должны быть соединены с Management узлом. От вычислительных узлов требуется чтобы они были соединены только со своим Service узлом. Прямой доступ к Management узлу для Compute узлов не требуется.
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
Для удобства можно все Service узлы занести в группу <tt>service</tt>. В дальнейшем это позволит обновить все Service узлы указав группу <tt>service</tt>.
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 ==
В таблице <tt>nodetype</tt> необходимо задать имя профиля для Service узлов:
Для информации: официальный xCAT использует AWK с поддержкой сетевых сокетов.
# chdef -t group -o service arch=x86_64 os=alt nodetype=osi profile=service
В ALT Linux AWK собран без поддержки сокетов. После некоторого обсуждения, было решено остановиться на netcat.
# tabdump nodetype
И заменить строки вида:
#node,os,arch,profile,provmethod,supportedarchs,nodetype,commee
  listener = "/inet/tcp/300/0/0"
  "service","alt","x86_64","service",,,"osi",,
на
listener = "netcat -l 300"


Ппосле этого начались проблемы.
В таблице <tt>servicenode</tt> указываются:
allowcred.awk &
* Service узлы или группы с Service узлами;
CREDPID=$!
* Какие службы будут выполняться на Service узлах;
...
kill -9 $CREDPID
Убивает сам скрипт AWK, причем процесс порожденный AWK <tt>while ((listener |& getline) > 0) {</tt> останется висеть.
Пришлось добвить:
CHLDPID=`pgrep -P $CREDPID`
kill $CHLDPID


== Интересное ==
В таблице <tt>servicenode</tt> '''ДОЛЖНЫ''' быть перечислены '''ВСЕ''' Service узлы, даже если они не будут выполнять никаких служб.
Две команды:
По умолчанию xCAT подразумевает, что служба на данном Service отключена (<tt>0</tt> или <tt>no</tt>).
# chdef -t group -o diskless -p postscripts=setupntp
# chdef -t node -o diskless -p postscripts=setupntp
Где <tt>diskless</tt> - имя группы.
Тогда первая команда добавит одну запись.
Вторая команда добавит для каждого узла состоящего в группе <tt>diskless</tt> отдельную запись.


Параметры можно задать конкретно для некого узла, но можно и для целой группы узлов.
При запуске <tt>xcatd</tt> сервера на Service узле, он обратится к таблице <tt>servicenode</tt>, чтобы узнать, какие службы должны выполнятся на этом Service узле. Проверка будет происходить каждый раз при перезапуске службы <tt>xcatd</tt>.
Если узел принадлежит группе, то он унаследует все параметры для данной группы.
Узел может принадлежать одновременно двум и более группам.
Чтобы узнать какое значение получит конкретный узел можно использовать опцию <tt>--blame</tt> для команды <tt>nodels</tt>.
# 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)


  Таблица <tt>nodepos</tt> задает физическое месторасположение узлов.
Указать, какие службы будут выполняться на Service узле, можно с помощью команды:
  # chdef -t group -o service setupnfs=1 setupnameserver=1 setuptftp=1


Команды <tt>chkosimage,mknimimage</tt> - работают только для AIX систем.
Данная команда внесёт изменения в таблицу <tt>servicenode</tt>.
/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".
Настройку Service узлов выполняют post-скрипты:
  # chdef -t group -o service postscripts=servicenode,xcatserver,xcatclient


== Другое ==
Для корректной работы с Compute узлами необходимо задать два поля в таблице <tt>noderes</tt>:
* <tt>servicenode</tt> - имя Service узла известного со стороны Managment узла
* <tt>xcatmaster</tt> - имя 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 узлов будет использоваться <tt>pxe</tt> (<tt>xnba</tt>):
# 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
 
Узлы, принадлежащее группе <tt>compute1</tt>, при установке будут использовать <tt>sn1</tt>. Если узел <tt>sn1</tt> будет недоступен, то будет использоваться Service узел <tt>sn2</tt>. Тоже самое справедливо и для Compute узлов из группы <tt>compute2</tt>, только в обратном порядке.
Поля <tt>xcatmaster, tftpserver, nfsserver</tt> должны быть пустыми.
 
На Management узле следует задать значения для:
* <tt>chtab key=installloc site.value=[hostname:]/install</tt>
Если поле <tt>hostname</tt> отсутствует, тогда будет использовано имя Management узла.
Данная опция указывает, что Service узлы будут монтировать себе каталог <tt>/install</tt>. Если значение поля <tt>installloc</tt> не задано, тогда синхронизация каталогов <tt>/install</tt> Service узлов и Managment узла ложится на плечи администратора.
* <tt>chdef -t site -o clustersite sharedtftp=0</tt>
По умолчанию все Service узлы автоматически монтируют каталог <tt>tftpboot</tt>. Если используются пул из нескольких Service узлов, необходимо отключить авто-монтирование каталога <tt>tftpboot</tt>. Если Service узел является stateless, тогда значение каталога <tt>/var/lib/tftpboot</tt> будет потеряно при перезагрузке Service узла и прийдеся заново вызывать комманду <tt>nodeset</tt> для каждого Compute узла.
В поле <tt>site.sharedtftp</tt> можно задать имя хоста, с которого необходимо монтировать каталог <tt>tftpboot</tt>.
 
Для каждого адресного пространства кластера необходимо внести запись в таблицу <tt>networks</tt>.
# chtab net=10.3.1.0 networks.netname=public networks.disable=1
Если в сети присутствует пул Service узлов, тогда параметр:
* <tt>net.dhcpserver</tt> должен быть равен одному Service узлу из пула.
* <tt>net.tftpserver</tt> - сброшен
* <tt>net.namerserver</tt> - сброшен
 
В настройках Management узла для Compute узлов необходимо указать Service узел со службами мониторинга conserver/monserver:
# chdef -t node -o compute1 conserver=sn1 monserver=sn1
 
В случае использования пула Service узлов, необходимо явно выбрать некий Service узел и делегировать ему атрибуты в полях: <tt>nodehm.conserver</tt> и <tt>noderes.monserver</tt>.
 
Service узлы могут быть stateless или statefull.
 
Для Service узлов можно указать, разрешен ли IP-форвардинг в поле <tt>servicenode.ipforward</tt>.
 
==== Stateless Service узлы ====
 
Цитата из официальной документации:
'''Service nodes are the same OS and architecture as the management node.'''
 
'''Перевод :'''
 
'''Сервисные узлы должны работать под управлением той же ОС и быть той же архитектуры, что и управляющие узлы.'''
 
Таким образом, если на Managment узел работает под ОС ALT Linux, тогда Managment узел не может работать под другой Linux системой.
 
При построении образа для Service узлов используется специальный профиль:
* <tt>service.pkglist</tt>. Можно использовать более частный случай: service.<DISTRO>.<ARCH>.pkglist
* <tt>service.otherpkgs.pkglist</tt>, или <tt>service.<DISTRO>.<ARCH>.otherpkgs.pkglist</tt>
 
* <tt>/usr/xcat/share/xcat/netboot/alt</tt> - расположение стандартных списков с пакетами;
* <tt>/var/lib/xcat/custom/netboot/alt</tt> - в случае необходимости можно разместить изменённый список устанавливаемого ПО. Сюда также можно положить .postinstall файл (например <tt>compute.postinstall</tt>).
 
Репозиторий ОС ALT Linux содержит пакеты xCAT, поэтому отпадает необходимость создавать локальный репозиторий с xCAT пакетами на Management узле для установки на 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-скрипта:
* <tt>servicenode</tt>
** Налаживает доступ к БД Management узла;
** Вызывает <tt>copycerts</tt>;
** Создаёт каталог с post-скриптами <tt>/install/postscripts</tt>;
** Закачивает с Managment узла сертификаты/ключи: <tt>/etc/xcat/cert/server-cred.pem</tt>
** Создаёт конфигурационный файл доступа к БД на Managеment узле: <tt>/etc/xcat/cfgloc</tt>
* <tt>xcatserver</tt>
** <tt>/etc/xcat/cfgloc</tt>
** <tt>/etc/xcat/cert/*</tt>
* <tt>xcatclient</tt>
** /root/.xcat/client-cred.pem
** /root/.xcat/ca.pem
 
==== Проверка ====
 
* После инсталляции профиля Service узла, с Managment node должен быть доступен вход по ssh без пароля.
* На Service узле должна выполняться служба <tt>xcatd</tt>.
* Следует убедится в том, что команды <tt>tabdump site</tt>, <tt>nodels</tt> могут получить доступ к БД с Service узла.
* В случае необходимости убедится, что на Service узле смонтированы каталоги <tt>/var/lib/tftpboot</tt> и <tt>/var/lib/xcat</tt> с Management узла.
* Пароль для пользователя <tt>root</tt> на Service узлах должен быть равен значению <tt>passwd.system</tt>
* Чтобы обновить ключи на Service узлах в группе <tt>service</tt> достаточно выполнить команду: <tt>xdsh service -K</tt>
* Файл <tt>/etc/xcat/cfgloc</tt> на Service и Management узлах должен быть одинаковым.
* Каталог <tt>/etc/xcat/cert</tt> должен содержать файлы: <tt>ca.pem</tt> <tt>server-cred.pem</tt>
* Каталоги <tt>/etc/xcat/ca</tt> на Service и Management узлах должны быть почти одинаковы (см. <tt>servicenode</tt> post-скрипт).
* Каталог <tt>etc/xcat/hostkeys</tt> содержит SSH ключи, которые будут устанавливаться на Compute узлы. Этот каталог должны быть одинаковым на Service и Management узлах.
 
==== Замечания ====
 
Если для Service узла задан параметр <tt>chtab key=service servicenode.dhcpserver=1</tt>, то на Service узле будет запущен DHCP сервер, который будет слушать на <tt>"dhcpinterfaces","mn|eth0;service|eth1",,, </tt> и команда
 
# makedhcp dmz1node1
 
обновит следующий файл на Service узле:
 
/var/lib/dhcp/dhcpd/state/dhcpd.leases
 
В документации [http://xcat.svn.sourceforge.net/viewvc/xcat/xcat-core/trunk/xCAT-client/share/doc/xCAT2SetupHierarchy.pdf xCAT2SetupHierarchy.pdf] для Service узлов предлагается вручную отредактировать файл: <tt>/var/lib/xcat/netboot/alt/x86_64/service/rootimg/etc/exports</tt>
/var/lib/tftpboot *(rw,no_root_squash,sync)
/var/lib/xcat *(rw,no_root_squash,sync)
 
==== Service Node Pools ====
 
По состоянию на Апрель 2010 года, ситуация c Pools не очень ясна.
 
В
[http://sourceforge.net/mailarchive/forum.php?thread_name=OF37AC3175.7215C1CE-ON852576F8.005EAB6F-852576F8.00618A83%40us.ibm.com&forum_name=xcat-user рассылке]
говорится о:
# ...скудной документации;
# ...не полной поддержке;
 
Особенности:
* Необходимо спроектировать сеть так, чтобы все Сompute узлы и Service узлы находились в одном адресном пространстве.
* <tt>noderes.xcatmaster</tt> - может быть не определено. Тогда перечисленные Service узлы в <tt>noderes.servicenode</tt> будут обслуживать Compute узлы, вне зависимости от того, кто загрузил (pxe) Compute узел.
* <tt>site.dhcpinterfaces</tt> должен указывать на сетевые интерфейсы ведущие к 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 (</var/named/db.*>) {
                unlink $_;
            }
            foreach (</var/lib/named/db.*>) {
                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 <tt>while ((listener |& getline) > 0) {</tt> (что за код?) останется висеть.
 
Пришлось добвить: (опечатка, конкретнее? где эти команды или код следует написать? в каком файле?)
CHLDPID=`pgrep -P $CREDPID`
kill $CHLDPID
 
== Интересное ==
Две команды:
# chdef -t group -o diskless -p postscripts=setupntp
# chdef -t node -o diskless -p postscripts=setupntp
 
Где <tt>diskless</tt> - имя группы.
Тогда первая команда добавит одну запись.
Вторая команда добавит для каждого узла состоящего в группе <tt>diskless</tt> отдельную запись.
 
Параметры можно задать конкретно для некого узла, но можно и для целой группы узлов.
Если узел принадлежит группе, то он унаследует все параметры для данной группы.
Узел может принадлежать одновременно двум и более группам.
Чтобы узнать какое значение получит конкретный узел можно использовать опцию <tt>--blame</tt> для команды <tt>nodels</tt>.
# 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)
 
Таблица <tt>nodepos</tt> задает физическое месторасположение узлов.
 
Следующие команды работают только на оборудовании, поставляемом фирмой IBM:
* chkosimage
* mknimimage
* /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.
* mkdsklsnode
* renergy
* rmdsklsnode
* db2sqlsetup
 
Новый, установленный узел получает *.pub и _ssh ключи c Managmen Node с помощью post-скрипта "getcredentials.awk".
 
Иногда возникают ситуации, когда необходимо техническая поддержка. xCAT позволяет создать отчет о среде выполнения и конфигурации.
Этот отчет можно отослать службе поддержки xCAT или специалисту.
Для создания отчета необходимо запустить команду <tt>xcatsnap</tt>.
Созданные отчеты будут хранится по следующему адресу: <tt>/tmp/xcatsnap</tt>
 
== Другое ==


===XNBA===
===XNBA===


В конфигурационные файлы:
В конфигурационные файлы:
* $tftpdir . "/xcat/xnba/nodes/" . $node
* $tftpdir . "/xcat/xnba/nodes/" . $node
* $tftpdir . "/xcat/xnba/nodes/" . $node. ".pxelinux"
* $tftpdir . "/xcat/xnba/nodes/" . $node. ".pxelinux"
прописывается:
прописывается:
* IPAPPEND 2
* IPAPPEND 2
* BOOTIF=${netX/mac}
* BOOTIF=${netX/mac}
 
 
<tt>IPAPPEND 2</tt> - указывает что в <tt>/proc/cmdline</tt> будет добавлена строка: BOOTIF=hardware-address-of-boot-interface  
<tt>IPAPPEND 2</tt> - указывает что в <tt>/proc/cmdline</tt> будет добавлена строка: BOOTIF=hardware-address-of-boot-interface  
Это позволяет сообщить initrd программе с какого интерфейса была загружена система (pxelinux.doc).
Это позволяет сообщить initrd программе с какого интерфейса была загружена система (pxelinux.doc).
 
 
===Проверка узлов===
===Проверка узлов===
Для проверки узлов администратору доступна утилита <tt>sinv</tt>.
Для проверки узлов администратору доступна утилита <tt>sinv</tt>.
Её действие сводится к тому, чтобы проверить, одинаков ли вывод любой команды на узлах.
Её действие сводится к тому, чтобы проверить, одинаков ли вывод любой команды на узлах.
Порядок действия:
Порядок действия:
* Выбирается эталонный узел, для которого на MN выполняется следующая команда:  
* Выбирается эталонный узел, для которого на MN выполняется следующая команда:  
  # xdsh cn-1 "ls -l /" | xdshcoll > /tmp/sinv.template
  # xdsh cn-1 "ls -l /" | xdshcoll > /tmp/sinv.template
* Для всех узлов, которые необходимо проверить на идентичность вывода команды <tt>ls -l /</tt> можно выполнить:
* Для всех узлов, которые необходимо проверить на идентичность вывода команды <tt>ls -l /</tt> можно выполнить:
  # sinv -c "xdsh <noderange> ls -l /" -p /tmp/sinv.template
  # 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, и использовал ее.
* Не используется <tt>linuximage.pkgdir</tt>
* Вставить строку use diagnostics; см <tt>/usr/share/xcat/netboot/alt/genimage</tt> - и будет кучу WARNING (perl -cw) на стандартные xCAT модули.
* В diskless установку добавляется пользователь <tt>altlinux</tt>, нужно решить, нужен ли он нам.
* Необходимо решить как управляются пользователи на вычислительных узлах. Для statelite вызывается утилитка: <tt>/usr/share/xcat/netboot/add-on/statelite/add_passwd</tt>
* Непонятное назначение:
**<tt>/usr/share/xcat/templates/cmos_settings</tt>
**<tt>/usr/share/xcat/tools/mac2linklocal</tt> -- Mac to IPv6 link local address utility.
* Список пакетов может включать другие пакеты #INCLUDE_PKGLIST или шаблон #INCLUDE_PTRNLIST. Не понятно как работают шаблоны (см. Template.pm).
* Требуется корректировка специалистами (администраторами) по xCAT:
** NetCAT и awk - перевести на человеческий язык: где команды, а где результаты их выполнения?
** Исходный код xCAT - что это и для чего?
** Пакеты ALT Linux - что настраиваем/делаем в этом пункте?
** Stateless service node - не содержит комментарии/пояснения!
 
== Основные понятия ==
Здесь необходимо определить однозначный перевод некоторых понятий и дать необходимые определения:


== TODO ==
* Management Node (MN) - центральный управляющий узел кластера под управлением xCAT. В кластере может быть только один такой узел.  
* FullState. Установка проходит через сеть. В модуле alt.pm задается имя сетевой карточки с которой происходит установка. Эту карточку инициализирует propagator. В pxelinux есть возможность задать опцию IPAPPEND 2. Тогда pxelinux передает ядру через cmdline строку BOOTIF=hardware-address-of-boot-interface. Нужно чтобы Progpagator умел парсить параметр: BOOTIF=MAC, и использовал ее.
* Service Node (SN) - вспомогательный управляющий узел кластера под управлением xCAT. Таких узлов может быть несколько на весь кластер. Service узлы могут быть stateless или statefull.
* Не используется <tt>linuximage.pkgdir</tt>
* Compute Node (CN)- вычислительный узел кластера под управлением xCAT. Как правило таких узлов в кластере много.
* Вставить строку use diagnostics; см <tt>/usr/share/xcat/netboot/alt/genimage</tt> - и будет кучу WARNING (perl -cw) на стандартные xCAT модули.
* Stateless node (stateless-узел) - это узел, который не имеет постоянно хранящегося на нём "состояния" (изменения конфигурации, обновления программного обеспечения и т.п.).
* В diskless установку добавляется пользователь <tt>altlinux</tt>, нужно решить, нужен ли он нам.
* Statefull node (statefull-узел) - это узел с установленной на локальном жёстком диске ОС. На таком узле могут выполняться изменения (изменения конфигурации, обновления программного обеспечения и т.п.), и эти изменения сохраняются на постоянной основе.  
* Необходимо решить как управляются пользователи на вычислительных узлах. Для statelite вызывается утилитка: <tt>/usr/share/xcat/netboot/add-on/statelite/add_passwd</tt>
* Statelite node (statelite-узел) - это узел, представляющий собой гибкое и эффективное бездисковое решение, т.к. большинство образов ОС монтируется по NFS в режиме только чтение, но настраиваемый список каталогов и файлов может быть доступен в режиме чтения/записи.
* Непонятное назначение:
{{Category navigation|title=HOWTO|category=HOWTO|sortkey={{SUBPAGENAME}}}}
**<tt>/usr/share/xcat/templates/cmos_settings</tt>
**<tt>/usr/share/xcat/tools/mac2linklocal</tt> -- Mac to IPv6 link local address utility.
* Список пакетов может включать другие пакеты #INCLUDE_PKGLIST или шаблон #INCLUDE_PTRNLIST. Не понятно как работают шаблоны (см. Template.pm).

Текущая версия от 15:27, 19 июля 2015

Обзор 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, который содержит множество архитектурных изменений и улучшений функциональности. Все команды являются клиент-серверными, поддерживают аутентификацию, протоколируются и управляются политиками. XCAT 2 поддерживает разграничение прав на основе ролей (RollBase: таблица policy управляет полномочиями на выполнение определённых операций xCAT). Клиенты могут работать под управлением любой ОС с поддержкой интерпретатора Perl, включая ОС Windows. Все соединения шифруются при помощи протокола SSL. Код xCAT 2 полностью переписан на языке Perl, а данные таблиц теперь сохраняются в реляционной базе данных. А благодаря модульной архитектуре, Вы можете выбрать требуемую СУБД: SQLite, MySQL или PostgreSQL.

В клиент-серверном приложении xCAT весь поток между клиентом и сервером контролируется службой xcatd (xCAT daemon) на управляющем узле (Management Node). Когда служба xcatd получает упакованную как XML команду, она проверяет полномочия отправителя, сверяясь со списками контроля доступа ACL в таблице политик. Также служба получает информацию о состоянии и статусе узлов с момента начала их работы. За дополнительной информацией об архитектуре xCAT обращайтесь к xCAT 2 Architecture.

xCAT 2 спроектирован для масштабирования очень больших кластеров. Благодаря поддержке иерархии, один управляющий узел может иметь любое количество stateless или statefull сервисных узлов, что повышает производительность и позволяет управлять очень большими кластерами. Все службы кластера такие, как: LDAP, DNS, DHCP, NTP, Syslog и т.д., могут быть автоматически настроены в рамках всего кластера. Исходящие команды управления кластером такие, как: rpower, xdsh, xdcp и т.д., используют эту иерархию для масштабируемого управления системой.

Типы узлов: Stateless, Stateful и Statelite

Stateless узлы являются важным понятием в xCAT 2. Stateless узел – это узел, который не имеет постоянно хранящегося на нём "состояния" (изменения конфигурации, обновления программного обеспечения и т.п.). В кластерах это очень полезно в силу следующих причин:

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

Для Linux кластеров xCAT 2 предоставляет выбор между stateless и stateful узлами. Stateful узел – это узел с установленной на локальном жёстком диске ОС. На таком узле могут выполняться изменения (изменения конфигурации, обновления программного обеспечения и т.п.), и эти изменения сохраняются на постоянной основе.

Stateless узлы в xCAT 2 характеризуются не только наличием ОС на локальном жёстком диске узла. Существует 3 вида stateless:

  1. RAM-root – Весь образ ОС находится на RAM файловой системе, который пересылается на узел во время его загрузки. Типичный минимальный размер вычислительного узла для Linux составляет 75-160 МБ.
  2. Compressed RAM-root – Образ ОС является сжатым tar-файлом. Отдельные файлы распаковываются и кэшируются во время чтения. Запись осуществляется в кэшированные копии. Типичный минимальный размер такого вычислительного узла для Linux составляет 30-64 МБ.
  3. NFS Hybrid – NFS-root с копированием при записи (copy-on-write). Узлу посылается минимальное загрузочное ядро, которое в режиме чтения монтирует (NFS) образ ОС на сервере. Прочтенные файлы кэшируются в памяти. Запись осуществляется в кэшированные копии. Типичный минимальный размер такого вычислительного узла для Linux составляет 5 МБ.

Statelite (начиная с версии xCAT 2.4 и выше) предоставляет гибкое и эффективное бездисковое решение, т.к. большинство образов ОС монтируется по NFS в режиме только чтение, но настраиваемый список каталогов и файлов может быть доступен в режиме чтения/записи. Файлы, доступные для чтения/записи, при перезагрузке могут оставаться либо в модифицированном состоянии, либо восстанавливаться в своём первоначальном, оригинальном состоянии. У Stateless есть как преимущества, так и недостатки, которые описаны в xCAT Statelite Cookbook.

Формирование имени хоста в xCAT

Имена хостов (узлов) в xCAT не должны содержать символы в смешанном регистре. Сервис разрешения имён (DNS) переводит все имена хостов в нижний регистр. Таким образом все имена хостов в xCAT должны указываться в нижнем регистре. Имена хостов xCAT должны состоять только из цифр и букв. Использование специальных символов ( -, *, и т.д.) может привести к ошибкам, т.е. не следует их использовать. Для более подробной информации следует обратиться к руководству (man) для noderange в раздел опций (noderange options).

В xCAT предпочтительным способом является использование коротких имён (без домена) для всех узлов. Если необходимо использовать длинные имена, тогда нужно создать xCAT "алиас" для узла, указав соответствие длинного имени узла к группе узлов с коротким именем.

Например, запись в таблице узлов (nodelist) может выглядеть так:

 "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

Установка xCAT на Management Node (управляющий узел)

Если xCAT не предустановлен в вашей операционной системе, то вы можете установить его, выполнив:

 # apt-get install xCAT

После выполнения команды будут установлены все необходимые пакеты для того, чтобы ваш сервер стал управляющим узлом (Management Node).

Установка xCAT на Service Node (вспомогательный узел)

Как правило, вспомогательные узлы (Service Node) устанавливаются из центрального управляющего узла (Management Node). Если же по какой-то причине администратору необходимо установить вспомогательный узел вручную, то необходимо установить пакет xCATsn с помощью команды:

 # apt-get install xCATsn

Установка на Compute Node (вычислительный узел)

Установка вычислительного узла (Compute Node) производится только из управляющего узла (Management Node).

Особенности установки xCAT в ОС ALT Linux

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

Если на управляющий узел установлен дистрибутив ОС ALT Linux для процессора i586, тогда этот управляющий узел не сможет обслуживать узлы с ОС для архитектуры x86_64.

Репозиторий для создания образа ОС

Для обеспечения возможности создания образа ОС, необходимого для загрузки или установки 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 предполагает что:

  1. Management Node хранит свои LOG файлы локально.
  2. Service Node может хранить файлы как локально, так и отсылать своему Management Node. Поведение регулируется установкой параметра site.svloglocal.
  3. 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 автоматически заносит обнаруженные сети в таблицу. Ненужные сети можно удалить вручную или указать чтобы они игнорировались:

chtab netname="192_168_122_0-255_255_255_0" networks.disable=1

Для добавления сетей, с которыми будет работать xCAT, можно выполнить команду chtab. Например:

# 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. Например:

# 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 - имя интерфейса, ведущего в данную сеть.

Compute Nodes (вычислительные узлы)

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

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

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

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

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

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

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

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

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

# makehosts
# makedns
# service bind restart

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

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

Команда makedns обновляет настройки служюбы BIND.

При необходимости, можно обновить связку "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:

# 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 - специфические опции service processor указываются в таблице mp
  • hmc - специфические опции service processor указываются в таблице ppc
  • ivm - специфические опции service processor указываются в таблице ppc (Integrated Virtualization Manager)
  • fsp - специфические опции service processor указываются в таблице 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,rpower):

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

Включить/отключить световой индикатор можно при помощи rbeacon:

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

Вывести, например, 5 последних событий BMC контроллера можно с помощью команды reventlog:

# 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:

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

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

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

Временно изменить загрузочное устройство можно с помощью команды rsetboot:

# rsetboot bmc1 net
bmc1: Network

Несколько физических серверов могут управляться одним Service Processor. Рассмотрим пример:

Пусть, имеются вычислительные узлы hw1,hw2,hw3 и hw4. 1. Добавим узлы hw1-hw4 командой nodeadd, занеся их в группу mm, что подразумевает, что эти вычислительные узлы управляются BMC контроллером.

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

2. Укажем, что все вычислительные узлы в группе compute управляются контроллером bmc1:

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

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

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

Служба Conserver

В задачи службы conserver входит:

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

Параметры доступа к последовательному порту задаются командой chtab в таблице 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. После обновления конфигурационного файла необходимо перезапустить службу conserver:

# 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, можно проанализировать содержимое следующих конфигурационных файлов:

  1. /etc/named.conf
  2. /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


Служба BIND на 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

Для корректного заполнения в файле /etc/dhcp/dhcpd.conf параметра отвечающего за DNS-сервер которым будут пользоваться узлы при загрузке, необходимо убедится что флаг networks.nameservers равен IP управляющего узла. В противном случае, узлы которые загружаются через XNBA (gPXE) не смогут резолвить имена.

Service node

Если установлен флаг servicenode.dhcpserver, тогда Service узел будет иметь свои настройки в следующих файлах:

  1. /etc/dhcp/dhcpd.conf
  2. /var/lib/dhcp/dhcpd/state/dhcpd.leases

Например, нужно убедится, что для изолированных сетей параметр option domain-name-servers отличается.

Служба ATFTP

Для корректной работы xCAT требуется наличие atftp (Advanced Trivial File Transfer Protocol) сервера. При установке xCAT пакет tftpd (Trivial File Transfer Protocol) будет заменен пакетом atftp. Сервер xCAT должен знать месторасположение корневого каталога для atftp службы, этот параметр задается в поле:

# gettab key=tftpdir site.value
/var/lib/tftpboot

Основной конфигурационный файл для службы atftp находится в /etc/sysconfig/atftpd.

Следует убедится, что значение site.value и ATFTPD_EXTRA_ARGS совпадают.

При загрузке ОС должен запускаться atftpd сервис. Для этого необходимо выполнить следующие команды:

# service atftpd restart
# chkconfig atftpd on

Внимание: следует убедится что в пакет tftpd удален, и после этого xinetd не занимает порт используемы atftpd:

# service xinetd stop

Служба NTPD

Можно использовать любой публичный NTP (Network Time Protocol) сервер, или самостоятельно настроить собственный NTP сервер.

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

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

# chtab node=node1 postscripts.postscripts=setupntp

Обратите внимание на то, что Compute узлы (вычислительные узлы) должны использовать 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:

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

Stateless

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

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

  • создать самостоятельно
  • использовать официальный репозиторий 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

Для создания корректной конфигурации службы DHCP, необходимо также указать тип PXE-загрузчика (xnba,pxe) и адреса TFTP сервера:

# 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, и указывать все последующие параметры уже непосредственно для группы diskless.

# chdef -t node -o node1 -p groups=diskless # удалить из группы -m
# nodech "node1" groups,=diskless # удалить из группы nodech "node1" groups^=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) будет создаваться конфигурационный файл с параметром 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:

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


Использование протокола SoL (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 контроллере также можно задать:

  1. при discovery узла. runcmd=bmcsetup
  2. после 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);
  • Перманентные файлы - файлы, которые не изменяются при перезагрузке системы.

Особенности Statelite узлов

Statelite узлы имеют следующие особенности:

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

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

Statelite узлы имеют следующие преимущества:

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

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

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

Недостатки

Statelite узлы имеют следующие недостатки:

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

Настройка

Образ, загружаемый по сети на Statelite узел, размещается в /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). Желательно ограничить доступ к файлам только на чтение (read only), с последующей перезагрузкой службы 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:

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

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

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

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

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

  • litetree.priority - задаёт приоритет. Каждое местоположение файла имеет свой приоритет.
  • litetree.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:

  1. вносит изменения в statelite образ и создаёт набор ссылок;
  2. делает непригодным diskless образ, т.е. один образ для diskless и statelite режима;
  3. может обновлять rootimg согласно записям из таблицы litefile;
  4. восстанавливает файлы в начальное состояние, если они были удалены из таблицы litefile;
  5. копирует /usr/share/xcat/netboot/add-on/statelite/rc.statelite в /var/lib/xcat/netboot/alt/x86/compute/rootimg/etc/init.d/.

Команда liteimg создает 2 способа доступа к файлам, что позволит изменять файлы:

  1. непосредственно в корневом каталоге образа на управляющем узле;
  2. на работающем вычислительном узле.

Например, над файлом <$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 профиля не выполняется.

Команда lslite

С помощью команды lslite можно получить информацию о состоянии statelite узлов. Данная команда выводит следующую полезную информацию для узла:

  • каталог, который хранит изменяемые файлы
  • Файлы перечисленные в таблице litefile
  • файлы перечисленные в таблице litetree

Также информацию можно получить для state-lite образа, используя ключ -i.

POST-скрипты

Для statlite режима можно использовать два типа POST-скриптов.

Скрипты первого типа:

  1. ...исполняются при загрузке узла;
  2. ...скачиваются с Managment Node;
  3. ...перечисляются в таблице postscripts.

Скрипты второго типа:

  1. ...выполняются на стадии создания образа командой genimage;
  2. Имя скрипта должно совпадать с профилем, на основе которого создается образ. Например: compute.alt.x86.postinstall;
  3. ...находятся в каталоге /usr/share/xcat/netboot/alt или в каталоге /var/lib/xcat/custom/netboot/alt;
  4. Скрипту передаются следующие аргументы: $rootimg_dir, $osver, $arch, $profile.

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

Установка Statelite узла производится командой nodeset:

# 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 - путь который должен быть смонтированный с NFS-сервера.

Отладка

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

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

Пример:

# nodeset <node> statelite

Последовательность загрузки statelite-узла

Последовательность загрузки statelite-узла:

  1. Образ создается командой /usr/share/xcat/netboot/alt/genimage
  2. init для initrd создается на основе /var/lib/_mknetboot/mkimage-profile-diskless/initrd-init.in
  3. PXE/GPXE конфигурация создается командой nodeset <node> statelite
  4. По tftp/http загружается initrd и ядро.
  5. /init
  6. $NEWROOT/etc/init.d/statelite - файл скопирован genimage из /usr/share/xcat/netboot/add-on/statelite/rc.statelite
  7. Монтируются все NFS ресурсы из таблиц statelite и litetree
  8. switch_root
  9. Загрузка сервиса /etc/init.d/xcatpostinit.alt - файл скопирован genimage из /var/lib/xcat/postscripts/xcatpostinit.alt
  10. /opt/xcat/xcatdsklspost - загружает с Managment Node все POST-скрипты в /xcatpost
  11. Выполнение 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. В случае отсутствия хотя бы одного пакета все перечисленные пакеты не будут установлены.

Авто-установка

Последовательность действий при авто-установке:

  1. nodeset node1 install - эта команда создаст:
    1. PXE конфигурационный файл для узла node1.
    2. каталог /var/lib/xcat/autoinst/node1. Содержимое каталога: autoinstall.scm root.pub xcat-post.sh xcat-pre.sh
  2. Через PXE конфиг в /proc/cmdline передается пераметр ai
  3. Установщик запускает скрипт 20-metadata-autoinstall.sh
  4. Вызывается cp-metadata для autoinstall.scm и vm-profile.scm
  5. cp-metadata - скрипт, который читает /proc/cmdline на предмет опции curl=http://172.....
  6. Из указанного адреса curl=http://172..... скрипт cp-metadata выкачивает файлы: autoinstall.scm и vm-profile.scm
  7. Файлы autoinstall.scm и vm-profile.scm содержат инструкции и параметры для конкретного узла о том, как проводить авто-установку. Генерируются модулем /usr/lib/perl5/vendor_perl/xCAT_plugin/alt.pm
  8. Файл autoinstall.scm создаётся на основе текущего профиля узла, например из /usr/share/xcat/install/alt/compute.tmpl
  9. Файл vm-profile.scm - профиль для alterator-vm. Можно поместить в каталог /usr/share/xcat/install/alt/. Смотри пример /var/lib/xcat/alt/x86_64/Metadata/vm-profile.scm
  10. После установки пакетов выполняется скрипт: 81-xCAT-postinstall.sh
  11. Скрипт cp-metadata скачивает xcat-post.sh из адреса: curl=http://172.16.2.2/install/autoinst/node1/
  12. xcat-post.sh создаётся на основе /usr/share/xcat/install/scripts/post.alt. См. модуль: /usr/lib/perl5/vendor_perl/xCAT_plugin/alt.pm
  13. Далее происходит скачивание и выполнение скриптов из таблицы postscripts для узла node1.

Команда:

# rinstall noderange

аналог

# nodeset noderange install

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

# rpower noderange boot

Команда rinstall:

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

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

  1. При завершении установки выполняются скрипты, указанные в postscripts.postscripts
  2. После установки Statefull узла при первой загрузке выполняется скрипт /etc/init.d/xcatpostinst.alt
  3. Скрипты, которые необходимо выполнить при первой загрузке узла указываются в postscripts.postbootscripts
  4. Список скриптов из postscripts.postbootscripts сохраняется в файле: mypostscript.pos
  5. Ввиду того, что каталог /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",,,

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

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

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

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

При запуске на вычислительном узле отправляет все сообщения на 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 узла будут выполнены скрипты в такой последовательности:

  1. node=xcatdefaults postscripts.postscripts
  2. node=xcatdefaults postscripts.postbootscripts
  3. node=<узел/группа> postscripts.postscripts
  4. 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, узел связывается с Management Node и получает список скриптов, которые необходимо выполнить, и сохраняет их в /tmp/mypostscrip.

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

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


Statefull

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

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

Discovery

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

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

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

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

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

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

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

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

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

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

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

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

# gettab node=node1 nodelist.status
 standingby

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

Для перезагрузки обнаруженного узла:

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

Для "забывания" обнаруженного узла:

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

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

  • В 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 нужно провести на другом ядре, тогда достаточно удалить файл /var/lib/tftpboot/xcat/xnba/nets/172.16.2.0_24 и вызвать mknb <ARCH>.

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

KVM

Гостевой-узел - выполняется на хост узле.

Хост-узел - способен выполнять гостевые узлы.

На одном хост-узле, может выполняться одновременно несколько хост-узлов.

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

Установка хост-узла может протекать по двум сценариям. Администратор должен выбрать наиболее подходящий вариант установки хост-узла, в зависимости от сложившейся ситуации.

Сценарии:

  1. инсталяция statefull хост-узла из kvm профиля.
  2. установка дополнительных пакетов, чтобы узел стал хост-узлом.

Вариант 1: инсталяция statefull хост-узла из kvm профиля

Стандартный профиль для statefull хост-узла находится в: /usr/share/xcat/install/alt/kvm.tmpl

При использовании профиля kvm.tmpl в момент установки (развертывания) хост-узла будет использован список с дополнительными пакетами: /usr/share/xcat/install/alt/kvm.installer.pkglist.

Внимание: эти пакеты должны быть доступны на установочном CD.

После команды copycds росжатый ISO образ находится: /var/lib/xcat/alt/x86_64/.

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

На любой вычислительный работающий узел можно установить набор пакетов, чтобы он стал хост-узлом.

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

# cat /usr/share/xcat/install/alt/compute.otherpkgs.pkglist
 qemu-kvm
 libvirt
 perl-Sys-Virt
 bridge-utils
 qemu-system

При необходимости, этот список пакетов можно изменить:

# mkdir -p /var/lib/xcat/custom/install/alt
# cp /usr/share/xcat/install/alt/compute.otherpkgs.pkglist /var/lib/xcat/custom/install/alt/
# vim /var/lib/xcat/custom/install/alt/compute.otherpkgs.pkglist

Далее выполнить команду для установки этих пакетов. Смотри главу о установке дополнительного ПО на statefull узел:

# updatenode hpc3 -V -S

или

# updatenode hpc3 -V -P otherpkgs

Проверка:

[root@mn alt]# ssh hpc3
[root@hpc3 ~]# rpm -q qemu-kvm  libvirt perl-Sys-Virt bridge-utils qemu-system
qemu-kvm-0.12.4-alt1
libvirt-0.8.2-alt2
perl-Sys-Virt-0.2.2-alt1
bridge-utils-1.4-alt2
qemu-system-0.12.1-alt1

На хост-узле должна работать служба libvirtd:

[root@hpc3 ~]# virsh list
 ID Имя               Статус
 ----------------------------------

Общий каталог между Managment-узлом и Хост-узлами

На сервере (noderes.nfsserver) нужно создать каталог, в котором будут храниться образа дисков гостевых-узлов. Каталог должен размещаться на достаточно-большом хранилище. Допустим что образа дисков будут храниться по следующему пути:

# mkdir -p /var/lib/xcat/vms

Необходимо изменить настройки NFS-сервера, чтобы данный каталог был доступен для хост-узлов на запись. Добавим в конфигурационный файл NFS службы /etc/exports строку:

# echo '/var/lib/xcat/vms *(rw,no_root_squash,sync,no_subtree_check)' >> /etc/exports
# service nfs restart

Managment Node и хост-узлы должны иметь общий каталог, размещенный по одинаковому пути. В /etc/fstab хост-узлов необходимо добавить запись, чтобы при загрузке хост-узла автоматически монтировалась общий сетевой каталог:

$NFSSERVER:/var/lib/xcat/vms /var/lib/xcat/vms nfs rsize=8192,wsize=8192,timeo=14,intr,nfsvers=2 1 2

Это можно сделать, выполнив разово post-скрипты для нужных хост-узлов:

# updatenode hpc3 -V -P mountvms

Проверка:

[root@mn alt]# ssh hpc3
[root@hpc3 ~]# mount | grep vms
172.16.2.2:/var/lib/xcat/vms on /var/lib/xcat/vms type nfs (rw,rsize=8192,wsize=8192,timeo=14,intr,nfsvers=2,addr=172.16.2.2)

Настройка Managment узла

Для создания дисков гостевых узлов на Managment Node необходимо установить пакеты:

  • qemu-system
  • qemu-user

Настройка Хост-узлов

Настройка хост-узлов проводится post-скриптом mkhyperv.

Его можно выполнить разово вручную:

# updatenode hpc3 -V -P mkhyperv

или добавить в таблицу postscripts, чтобы он выпонялся автоматически для всех вновь установленных узлов:

# nodech x01 postscripts.postscripts,=mountvms
postscripts.postscripts - after installation or diskless boot.

Проверка:

  1. работает служба libvirtd:
[root@mn alt]# ssh hpc3
[root@hpc3 ~]# virsh list
 ID Имя               Статус
 ----------------------------------
  1. правильно настроена сеть
# brctl show
bridge name     bridge id               STP enabled     interfaces
xcat-guests             8000.001517bd9729       no              eth1
                                                       vnet0
                                                       vnet1
                                                       vnet2
                                                       vnet3
                                                       vnet4


Создание гостевых узлов

# nodeadd v1-v4 groups=kvm,all
# chtab node=kvm hosts.ip='|\D+(\d+)|172.16.2.(150+$1)|'
# makehosts vm
# makedns
# service bind restart
# chtab node=kvm vm.migrationdest=hpc3 vm.memory=1024 vm.cpus=2 vm.nics="xcat-guests" vm.bootorder="network,hd"
# chtab node=kvm vm.vncport='|\D+(\d+)|($1)|'
# chtab node=kvm vm.storage='|^(.+)$|/var/lib/xcat/vms/($1)|'
# chtab node=kvm nodehm.mgt=kvm nodehm.serialport=0 nodehm.serialspeed=115200
# chtab node=kvm nodetype.os=alt nodetype.arch=x86 nodetype.profile=compute nodetype.nodetype=osi
# chtab node=kvm noderes.netboot=pxe noderes.tftpserver=172.16.2.2 noderes.nfsserver=172.16.2.2 noderes.primarynic=eth0
# mkvm v1-v4 -s 20G
# tabdump kvm_nodedata
# rpower v1-v4,v6 boot
# tabdump mac
#node,interface,mac,comments,disable
"hpc3",,"00:15:17:bd:97:29",,
"cn-1",,"1a:1a:1a:1a:1a:21",,
"v1",,"1e:86:ac:10:02:c9",,
"v4",,"0a:80:ac:10:02:cc",,
"v2",,"e2:8f:ac:10:02:ca",,
"v3",,"02:b1:ac:10:02:cb",,
"v6",,"6a:ee:ac:10:02:ce",,


Может ли stateless узел быть хост-системой?

Template records

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

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

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

Правила:

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

где pattern:

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

Например, пусть имеются:

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

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

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

Пусть имеются:

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

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

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

где:

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

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

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

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

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

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

"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 - динамическая принадлежность узла к группе. Узел заносится автоматически на основании некоторых свойств узла.

Операции над динамическими группами можно условно разделить на две части:

  1. create/delete (tabedit), display (tabdump), modify (chtab)
  2. Передавать имя динамической группы в качестве аргумента для любой команды 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 ...

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

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

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

xcatmon

Рассмотрим на примере работу с модулем xcatmon. Для этого:

1. Доступные параметры модуля, которые задаются при регистрации, выводятся следующей командой:

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

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

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

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

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

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

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

# 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. [3] xCAT2SyncFilesHowTo.pdf
  2. man xdcp
  3. man updatenode

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

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

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

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

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

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

Managеment Node -> Service Node -> Compute Node

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

Принудительно синхронизировать файлы можно, вызвав команду:

# 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 необходимо создать список пакетов, которые необходимо установить.

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

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

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

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

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

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

# mkdir -p /var/lib/xcat/post/otherpkgs/alt
# genbasedir --create --flat --bloat --progress --topdir=/var/lib/xcat/post/otherpkgs/alt x86_64 xcat
# mkdir /var/lib/xcat/post/otherpkgs/alt/x86_64/RPMS.xcat

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

Stateless

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

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

Steteful

# 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:

  1. сделает запрос к Management Node (xcatd);
  2. будет вызвана часть xcatd - getpostscript.pm -> Postage.pm;
  3. сервер xcatd сгенерирует и передаст его post-script вычислительному узлу;
  4. 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

(на Management Node см.: # 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.pkglis
# chtab imagename=alt-x86-install-compute linuximage.otherpkglist=/usr/share/xcat/install/alt/compute.otherpkgs.pkglist

Шестой шаг - выполнение для нужных Compute узлов post-скрипта otherpkgs.

# updatenode <noderange> -P otherpkgs

или

# updatenode <noderange> -S

(на Compute Node см.: # cat /tmp/mypostscript)

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

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

  1. На Management Node необходимо скопировать скрипт в /var/lib/xcat/postscripts/;
  2. Выполнить команду 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

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

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

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

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

refcard


runsqlcmd

Команда runsqlcmd позволяет выполнить набор SQL забросов к базе данных xCAT под управлением MySQL или PostgreSQL. На вход команде можно подать каталог с .sql файлами. Файл содержащий SQL запросы должен иметь имя:

  • <name>.sql
  • <name>_<data‐base>.sql

Где:

  • составляющая имени <name> может принимать любое значение.
  • составляющая имени <data-base> может иметь одно из следующих значений:
    • mysql
    • pgsql
    • db2

Файл содержащий SQL запрос должен иметь права: 0755. Более подробную информацию по использованию команды runsqlcmd можно узнать из страницы руководства:

# man runsqlcmd

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):

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

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

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

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

На 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 узел не может работать под другой 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 пакетами на Management узле для установки на 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 узлов. Отличия будут состоять в:

  1. имени профиля;
  2. дополнительных 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 не очень ясна.

В рассылке говорится о:

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

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

  • Необходимо спроектировать сеть так, чтобы все С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 задает физическое месторасположение узлов.

Следующие команды работают только на оборудовании, поставляемом фирмой IBM:

  • chkosimage
  • mknimimage
  • /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.
  • mkdsklsnode
  • renergy
  • rmdsklsnode
  • db2sqlsetup

Новый, установленный узел получает *.pub и _ssh ключи c Managmen Node с помощью post-скрипта "getcredentials.awk".

Иногда возникают ситуации, когда необходимо техническая поддержка. xCAT позволяет создать отчет о среде выполнения и конфигурации. Этот отчет можно отослать службе поддержки xCAT или специалисту. Для создания отчета необходимо запустить команду xcatsnap. Созданные отчеты будут хранится по следующему адресу: /tmp/xcatsnap

Другое

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).
  • Требуется корректировка специалистами (администраторами) по xCAT:
    • NetCAT и awk - перевести на человеческий язык: где команды, а где результаты их выполнения?
    • Исходный код xCAT - что это и для чего?
    • Пакеты ALT Linux - что настраиваем/делаем в этом пункте?
    • Stateless service node - не содержит комментарии/пояснения!

Основные понятия

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

  • Management Node (MN) - центральный управляющий узел кластера под управлением xCAT. В кластере может быть только один такой узел.
  • Service Node (SN) - вспомогательный управляющий узел кластера под управлением xCAT. Таких узлов может быть несколько на весь кластер. Service узлы могут быть stateless или statefull.
  • Compute Node (CN)- вычислительный узел кластера под управлением xCAT. Как правило таких узлов в кластере много.
  • Stateless node (stateless-узел) - это узел, который не имеет постоянно хранящегося на нём "состояния" (изменения конфигурации, обновления программного обеспечения и т.п.).
  • Statefull node (statefull-узел) - это узел с установленной на локальном жёстком диске ОС. На таком узле могут выполняться изменения (изменения конфигурации, обновления программного обеспечения и т.п.), и эти изменения сохраняются на постоянной основе.
  • Statelite node (statelite-узел) - это узел, представляющий собой гибкое и эффективное бездисковое решение, т.к. большинство образов ОС монтируется по NFS в режиме только чтение, но настраиваемый список каталогов и файлов может быть доступен в режиме чтения/записи.