Официальный форум СВД Встраиваемые Системы
10 Декабря, 2016, 07:54:41 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.

Войти
 
 
 Сайт СВД ВС  Начало   Помощь Поиск Войти Регистрация  
Страниц: [1] 2   Вниз
  Печать  
Автор Тема: Проблемы при выключении узла из сети QNX4  (Прочитано 1308 раз)
LH
Опытный пользователь

Сообщений: 254


« : 18 Июня, 2013, 16:09:48 »

Имеется пять узлов с QNX4, соединенных в дублированную qnx-сеть. Все узлы "видят" друг друга. Логическая сеть 1 и 2
образуются подключением соответствующих сетевых карт каждого узла к отдельному коммутатору.

Программа nameloc запущен на каждом узле.

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

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

Команда sin net задумывается на несколько секунд перед началом вывода.

Через некоторое время ( 10 минут ) работа оставшихся в сети узлов нормализуется.

В чем может быть причина?
Похоже на nameloc?
Какие пути решения?

Обычно узлы 1...4 работают одновременно, а узел 5 может включаться и выключаться.

Спасибо.
Записан
LH
Опытный пользователь

Сообщений: 254


« Ответ #1 : 19 Июня, 2013, 16:34:44 »

Сегодня попробовал запускать nameloc с ключами

nameloc -S -s1 -e5 &

Никак не помогло, описанный выше эффект замедления остается.
Записан
deadarcher
Пользователь

Сообщений: 61


« Ответ #2 : 20 Июня, 2013, 09:03:43 »

Из личного опыта: немного разгрузить ситуацию можно, добавив к параметрам драйверов имеющихся сетевых карт ключей -n2 -t2.
Записан
Василий Дмитриев
Опытный пользователь

Сообщений: 295



« Ответ #3 : 20 Июня, 2013, 09:12:37 »

еще можно поиграть  -t от Net. И вообще, дублированная сеть, по личному опыту, дублированный тормоз:)
Записан

Санкции! Запрещаю Бараку Обаме и членам конгресса США читать мои посты!
LH
Опытный пользователь

Сообщений: 254


« Ответ #4 : 16 Июля, 2013, 03:33:15 »

М.б. более точно попытаюсь описать проблему.

В течение 10 минут после выключения другого узла из сети qnx4 выполнение
ф-ции qnx_name_locate() существенно замедляется если не блокируется.

Как мне представляется - по вине nameloc.

Записан
LH
Опытный пользователь

Сообщений: 254


« Ответ #5 : 22 Июля, 2013, 16:57:08 »

Применение -n2 -t2 для сетевого драйвера действительно смягчает проблему, но не решает ее полностью.

Почему тогда не сделать -n1 -t1 ?

По умолчанию используемые интерфейсы с Net.e1000 работают со скоростью 1Гбит, а применяется для связи между узлами
коммутатор со скоростью 100 мБит.

Требуется ли принудительно перевести Net.e1000 на пониженную скорость, соответственно скорости
коммутатора, или сетевая плата и "коммутатор" договариваются самостоятельно?

Записан
deadarcher
Пользователь

Сообщений: 61


« Ответ #6 : 24 Июля, 2013, 20:25:06 »

Коммутатор и сетевушка сами договорятся и будут на 100 работать. Хотя у нас иногда приходилось принудительно ставить ключ -s100 а то ерунда случалась. А ещё нам пришлось придумать такую штуку, типа широковещательного опроса с головного узла остальных. И как только определенный узел уходил, всем остальным рассылалась команда удалить его сетевой адрес. Правда у нас узлы уходят без возможности снова придти. Удаление сетевого адреса происходит из кэша Net а не из /etc/config/netmap. Это очень хорошо разгружает ситуацию замедления опроса через nameloc. Может сумбурно написал, ну как смог.
Записан
LH
Опытный пользователь

Сообщений: 254


« Ответ #7 : 25 Июля, 2013, 03:55:46 »

Спасибо за интересную идею!

Правильно ли я понял, что "удаление сетевого адреса из кэша Net" производится
командой

#netmap -f file2 ,

где file2 - новый состав узлов в сети?



Записан
deadarcher
Пользователь

Сообщений: 61


« Ответ #8 : 25 Июля, 2013, 07:53:06 »

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

# netmap -m "d node_number"

При этом удаляется узел node_number по всем сетям. Удаление можно делать на тех узлах, где nameloc крутятся или где name_locate вызывается для поиска в сети.
Записан
deadarcher
Пользователь

Сообщений: 61


« Ответ #9 : 25 Июля, 2013, 08:25:14 »

Вспомнил ! В вашем случае можно не удалять адреса, а делать на них mask. У нас удаление сделано просто из-за незнания о mask. Посмотрите справку use netmap, там есть подсказка как это сделать.
Записан
LH
Опытный пользователь

Сообщений: 254


« Ответ #10 : 27 Июля, 2013, 14:10:49 »

Описанный Вами метод работает в случае выключения работающего i-го узла из сети.

Проверку наличия узлов делал командой

#alive -uf

При потере узла i ставил маску:

#netmap -m "m i" ( i - номер узла )

Но при возвращении i-го узла в сеть команда alive его уже не видит : узел замаскирован.

Не могу сообразить, каким образом определять возврат i-го узла в сеть, если он ранее
был замаскирован командой netmap.

спасибо.
Записан
deadarcher
Пользователь

Сообщений: 61


« Ответ #11 : 29 Июля, 2013, 10:31:20 »

Здесь уже не подскажу. Только если узел при включении сам будет о себе сообщать исполняя удаленно на других узлах размаскирование типа on -n j netmap -m " u i "
Записан
LH
Опытный пользователь

Сообщений: 254


« Ответ #12 : 29 Июля, 2013, 18:41:04 »

Перечитываю netmap описание

Цитировать
Deleting vs masking
Deleting a mapping allows the map_entry to be reused, while masking an entry ties up the entry, preventing its reuse.

Похоже что я ошибочно маскировал , а не удалял (как Вы и предлагали !!),  описания ушедших из сети узлов. М.б. при возврате узлов в сеть их описания будут восстанавливаться автоматически?  Нужно будет проверить.

Еще получил оригинальное предложение от Hugh Brown. Полное описание здесь:
http://community.qnx.com/sf/discussion/do/listPosts/projects.community/discussion.qnx4_community_support.topc23930?_message=1375110723049

Обескуражен последним замечанием:

Цитировать
You must not have the same netmap file on every node. On node 1 the netmap
file should have nodes 2,3,4 & 5 in the netmap file, and on node 2 the
netmap file should have nodes 1,3,4 & 5 etc.

В предыдущих проектах на нескольких узлах сети использовал одинаковый /etc/config/netmap,
который запускался командой

netmap -f

в sysinit.*, причем на каждом узле был такой же как на других узлах netmap,
описывающий конфигурацию сети как других узлов, так и текущего узла.

Вроде все работает правильно и очень давно...

Почему указано такое ограничение: в /etc/config/netmap текущего узла описывать
конфигурацию только других узлов в сети, но не текущего узла?

Спасибо.



« Последнее редактирование: 29 Июля, 2013, 18:50:35 от LH » Записан
deadarcher
Пользователь

Сообщений: 61


« Ответ #13 : 29 Июля, 2013, 19:50:37 »

Кстати да, не подумал об этом - может их действительно стоит удалять. Ведь если на 5ом узле будет nameloc и netmap'ы везде одинаковые, то при включении узла в сеть nameloc сам постучиться ко всем и запишется ко всем.
Записан
LH
Опытный пользователь

Сообщений: 254


« Ответ #14 : 30 Июля, 2013, 16:59:39 »

Извините, так и не понял: что плохого в том, что в /etc/config/netmap текущего узла, кроме интерфейсов других узлов, описаны интерфейсы текущего узла ( т.е. в том, что netmap на всех узлах один и тот же ).

Буду признателен за пояснение.

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

#netmap -m "d i"

После этого замедления сети (длительностью 10 минут)  из-за  nameloc не наступает.

После включения узла , его информация автоматически восстанавливается в netmap других узлов и все вновь
"видят" друг друга...

Задержка составляет примерно 5-10 сек, т.к. после выключения  к-либо узла очередная команда alive все же немного тормозит.

Сокращение с 10 мин до 10 сек вроде уже результат, но не решение проблемы.
Записан
Страниц: [1] 2   Вверх
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP © 2002-2016 СВД Встраиваемые Системы.
При использовании материалов сайта ссылка на forum.kpda.ru обязательна.

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines | © Aiwan. Kolobok smiles | Sitemap
Valid XHTML 1.0! Valid CSS!
Сайт СВД ВС

В последний раз google посещал эту страницу 12 Ноября, 2016, 22:03:14