Всем доброго дня.

Данной статьей хотелось бы поделится специфичной настройкой серверов High-End класса от компании Oracle Sun. При добавлении/удалении/перемещении материнской платы в high-end серверах (в данной статье речь пойдет о серверах Е класса, а именно Е25К) не редко наталкивавшийся на одну очень характерную ошибку — DCA/DCS Communications errors. Ошибка указывает на то, что отсутствует какое-либо соединение между двумя доменами одного сервера. Гугл и саппорт от оракл подсказали одно решение. Собрав все воедино, было принято решение объединить все это в одну статью. Самое интересное, что после инсталляции Solaris10/11 на сервер, в каких то случаях это ошибка имеет место быть, в каких то нет. Но это не суть, самое главное есть решение как побороть данную проблему.

Как уже было сказано выше, проблема вызвана тем, что нарушена взаимосвязь между двумя доменами, т.е., один сервер ведет себя как два отдельных сервера/домена (это закономерно и логично), но не подозревает о том, что он состоит из двух «частей» и может «общаться» между собой. И так имеем: сервер Е25К, SC ALOM (Service controller), OS Solaris 10. Все работает, все пропатченно, но вот не задача, любые операции между доменами невозможны.

За данную взаимосвязь отвечают несколько компонентов:

1. Domain Configuration Agent. DCA. Должен быть включен на service controler-е.

2. Domain Configuration Server. DCS. Должен быть включен на доменах, в solaris.

3. Корректно настроен файл /ets/inetd.conf

4. Правильно выстроены политики ipsec в файле конфигурации /etc/inet/ipsecinit.conf.

5. Включен демон sckmd. Это демон отвечающий за криптографию протокола IPSec.

6. Внутренние сетевые устройства. На SC — это интерфейс scman0, в домене — это интерфейс dman0.

7. Domain X Server.

Если нарушено одно из условий указанных выше, то вывод команды showdevices будит отрицательным:

#showdevices -d -v [идентификатор домена]
Unable to get device information from domain x

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

#ifconfig -a

На sc:

scman0: flags=1008843<UP,BROADCAST,RUNNING,MULTICAST,PRIVATE,IPv4> mtu 1500 index 3 inet 10.1.1.1 netmask ffffffe0 broadcast 10.1.1.31

Domain:

dman0: flags=1008843<UP,BROADCAST,RUNNING,MULTICAST,PRIVATE,IPv4> mtu 1500 index 3 inet 10.10.1.3 netmask ffffffe0 broadcast 10.10.1.31 ether 0:0:be:a8:17:57

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

#ndd /dev/dman man_get_hostinfo
manc_magic = 0x4d414e43
manc_version = 01
manc_csum = 0x0
manc_ip_type = AF_INET
manc_dom_ipaddr = 10.1.1.0
manc_dom_ip_netmask = 255.255.255.224
manc_dom_ip_netnum = 10.1.1.0
manc_sc_ipaddr = 10.1.1.1
manc_dom_eaddr = 0:0:be:a8:48:26
manc_sc_eaddr = 8:0:20:f9:e4:54
manc_iob_bitmap = 0x400 io boards = 10.1,
manc_golden_iob = 10

Подкорректируем файл /etc/netmasks,

#vi /etc/netmasks
<manc_dom_ip_netnum> <man_dom_ip_netmask>

Что то вроде этого:

10.1.1.0 255.255.255.224

#vi /etc/hostname.dman0, если его нет, то создаем:
<manc_dom_ipaddr> netmask + broadcast + private up
wq!

#ifconfig dman0 plumb

Убедимся что все Ок:

#cat /etc/syslog.conf
…
*.notice @10.1.1.3

Если нет, то выполняем еще раз шаги настройки интерфейса:

#ifconfig dman0 plumb
#ifconfig dman0 <manc_dom_ipaddr> netmask + broadcast + private up

В моем случае:

# ifconfig dman0 plumb
# ifconfig dman0 10.1.1.3 netmask + broadcast + private up

Теперь нам необходимо проверить службы и демоны отвечающие за обмен информацией между доменами. На сервис контролере это DCA. Domain Configuration Agent. Он «слушает» по порту 665 всю входящую, управляющую информацию. Ели он не включен, то выполнение команд showdevices и rcfgadm не будит возможным. Проверяем:

#ps -ef | grep dca
sms-dca 1614 361 0 Feb 26? 0:00 dca -d A
sms-dca 1758 431 0 Feb 26? 0:00 dca -d B

Далее, на обоих доменах проверяем демон DCS. Он является «серверной» частью между доменами. Для корректной его работы, необходимо следующее обязательное условие. В конфигурационном файле /etc/inetd.conf должны быть строки:

#vi /etc/inetd.conf file:

sun-dr stream tcp wait root /usr/lib/dcs dcs
sun-dr stream tcp6 wait root /usr/lib/dcs dcs

Перезапустим его с новыми дополнениями:
# ps -ef | grep inetd
root 2021 1 0 Feb 11? 0:00 /usr/sbin/inetd -s
# kill -HUP 2021

Проверим, запустился ли dcs, т.к. inetd это приложение SMF (Service Management Facility), то проверяется он командой inetadm:

# inetadm
ENABLED STATE FMRI
…
enabled online svc:/application/font/stfsloader:default
…
disabled disabled svc:/network/talk:default
…
enabled online svc:/platform/sun4u/dcs:default

Служба dcs должна быть в состоянии вкл., т.е. enable. А вот еще пара команд, для более детального разбора dcs:

# /usr/sbin/svccfg -s svc:/platform/sun4u/dcs:default listprop
# svcs dcs

Все ок, идем дальше. Теперь нам нужно убедится, что домены «слушают» порт 665. Порт по которому «общаются», как было сказано выше dca и dcs: Из под solaris, набираем:

#netstat -an | grep 665
# netstat -an | grep 665
*.665 *.* 0 0 49152 0 LISTEN
*.665 *.* 0 0 49152 0 LISTEN

А теперь самое интересное, для обмена информацией между доменами, необходимо прописать политики обмена информацией. Дефолтные настройки не всегда являются достаточным условием! Редактируем файл
/etc/inet/ipsecinit.conf и добавляем следующие строки:

{ dport sun-dr ulp tcp } permit { auth_algs md5 }
{ sport sun-dr ulp tcp } apply { auth_algs md5 sa unique }
{ dport cvc_hostd ulp tcp } permit { auth_algs md5 }
{ sport cvc_hostd ulp tcp } apply { auth_algs md5 sa unique }

Обновляем политики:

#ipsecconf -a /etc/inet/ipsecinit.conf

#ipsecconf

Следующий в очереди DXS. Из sc смотрим запущен ли он:

# ps -ef | grep dxs
sms-dxs 1609 361 0 Feb 26? 0:57 dxs -d A
sms-dxs 1609 361 0 Feb 26? 0:57 dxs -d B
sms-dxs 1609 361 0 Feb 26? 0:57 dxs -d C

Обычно он всегда в состоянии enable. Так что с ним не возникает проблем. Если нет, то просто включаем командой svcadm. Двигаемся дальше — демон sckmd (Sun cryptographic key management daemon). Он отвечает за IPSec туннелирование. Смотрим запущен ли он:

# ps -ef | grep sckmd

root 24156 1 0 Apr 02? 0:00 /
usr/platform/SUNW,Sun-Fire-15000/lib/sckmd

К счастью у меня он был состоянии вкл. Но если нет, то так же его нужно будет просто активизировать командой svcadm.
Ну а в конце, проверяем все ли у нас работает:
# showdevices
#rcfgadm
#addboard -d [id_domain] SBx
#deletboard SBx
#moveboard -d [id_domain] SBx

Спасибо за внимание!

DCA/DCS Communications Error в high-end серверах Oracle Sun