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

Войти
 
 
 Сайт СВД ВС  Начало   Помощь Поиск Войти Регистрация  
Страниц: [1]   Вниз
  Печать  
Автор Тема: Проблема резервирования qnet  (Прочитано 618 раз)
Александр Гусев
Интересующийся

Сообщений: 9

Gravatar


« : 30 Сентября, 2015, 18:14:03 »

Здравствуйте, коллеги!

У нас есть проблема с резервированием qnet.
Собран стенд из двух физических машин на платформе Интел: uvk-1 и uvk-2, сетевые адаптеры на чипе Интел, маркировка закрыта радиатором, точно сказать не могу
На одной физической машине запущен простейший сервер приема сообщений, на второй машине - его клиент, посылающий сообщения в цикле.
Организовано резервирование сетевых соединений через два независимых сегмента ЛВС.
При отключении одного из кабелей ЛВС uvk-1 в /proc/qnetstats наблюдаются ожидаемые события отключения одного из интерфейсов. uvk-2 отписывает потерю одного из каналов связи.
При подключении кабеля обратно к uvk-1 на другой физической машине uvk-2 в /proc/qnetstats в бесконечном цикле записываются следующие события (цифры в левом столбце обновляются):
Цитировать
00165745 lr_add_ndb(): adding L4 0 addr to ndb for nd 6  uvk-1.net.intra
00165745: tx_conn_idle_l4(): tc_up_max_retries of 3 exceeded, deleting iface for L4 0 for nd 6 conn 3
00165745: tx_ndb_del_if(): deleting mapping for L4 0 for nd 6
Они прекращают резервирование, так как при отключении другого физического кабеля qnet-соединения обрываются, а в логах появляются события потери соседней машины.
Цитировать
00170518: tx_ndb_del_if(): no more interfaces, tearing down nd 6
00170518: nd_change_notify(): Node Down: nd 6 uvk-1.net.intra
Соответственно, программы получают ошибки обрыва соединения, клиент должен его пересоздавать заново.

Ситуация воспроизводится при любой последовательности отключения интерфейсов, отключение интерфейсов производилось с разными паузами от 1 до 10 секунд
Пробовали драйверы e1000 и i82544, замена на ситуацию не влияет. От изменения параметров qnet меняется только скорость появления циклических сообщений

Машины одинаковой аппаратной конфигурации, различаются только сетевыми идентификаторами (hostname, mac-address, ip-address)
gns-сервер запущен на виртуальной машине также с двумя сетевыми интерфейсами, на ней наблюдаются похожие сообщения, но они прекращаются через 2-5 итераций, а на физических машинах цикл бесконечен.
Записан

Инженер-программист
ОАО РТИ
Андрей Сеньков
Администратор
Опытный пользователь

Сообщений: 262



WWW
« Ответ #1 : 01 Октября, 2015, 15:27:00 »

Здравствуйте, Александр!

Для упрощения анализа данной ситуации, не могли бы Вы подготовить и выслать нам на e-mail исходные коды клиента и сервера.
Записан

Александр Гусев
Интересующийся

Сообщений: 9

Gravatar


« Ответ #2 : 02 Октября, 2015, 10:19:20 »

Здравствуйте, Андрей
Для упрощения анализа данной ситуации, не могли бы Вы подготовить и выслать нам на e-mail исходные коды клиента и сервера.

В прилагаемом архиве четыре проекта
iaos_dummy - сервер работающий через gns, создает канал вызовом name_attach
client_dummy - его клиент, подключается вызовом name_open
С ними все совсем плохо, клиент при обрыве пытается переподключиться и ему это не удается.

iaos2_dummy - сервер создает канал вызовом ChannelCreate и публикует свои pid и chid в файл
client2_dummy - его клиент, подключается и переподключается вызовом ConnectAttach, для которого получает идентификатор nd вызовом netmgr_strtond, pid и chid считывает из файла.
В этом варианте обрыв канала все равно происходит, то есть резервирование канала отказывает, перечитывается обновленный nd, соединение переустанавливается.

С уважением.
Александр.
Записан

Инженер-программист
ОАО РТИ
Павел Арцишевский
Интересующийся

Сообщений: 1


« Ответ #3 : 03 Октября, 2015, 18:32:31 »

С первоначальным вопросом разобрались: мы выдёргивали один кабель, ставили на место, но затем выдёргивали второй слишком быстро - первый интерфейс не успевал добавляться в пул доступных подключений.

Как мы поняли из документации, на это влияют следующие параметры:
  • auto_add - интервал, через который io-pkt посылает сообщения о доступных ему связях на все интерфейсы
  • probe_no_l4_time - интервал, через который io-pkt пробует поднять подключение по интерфейсу, на котором нет маппинга с нужной нодой (т.е. нужная нода ещё не послала нам бродкаст о себе, но уже может быть доступна?)
Мы правильно понимаем значения этих параметров? Может, еще какие-либо параметры на это влияют?

Также, непонятно, как определить, перешел ли недавно подключенный линк в пул доступных.
В документации сказано:
Цитировать
While load-balancing among the live links, Qnet will send periodic maintenance packets on the failed link in order to detect recovery. When the link recovers, Qnet places it back into the pool of available links.
Через какое время возвращённое подключение вернётся обратно в пул, от чего это зависит?

Цитировать
If a link does fail, Qnet will switch to the next available link
Можно ли как-либо, например, через API, узнать, что подключение перешло на резервный линк (для отображения, что одно из подключений сломалось)?
Узнать, по скольки и каким интерфейсам на данный момент работает подключение?

Сейчас мы пытаемся анализировать /proc/qnetstats, данную секцию:
Код:
**** Tx Connections:
mpz5-1.net.intra i 2 st 3 ln 5 rn 7 lc 1 rc 6 hq 0 tq 0 ns 303292 ds 303291
uvk-2.net.intra i 2 st 3 ln 12 rn 9 lc 4 rc 4 hq 0 tq 0 ns 2488 ds 2487
Есть ли какое-то описание данной секции?

В документации ничего не нашли про формат записей, но, видимо, после i указано количество интерфейсов, которые доступны подключению.
Как показали эксперименты, после подключения ранее выдернутого кабеля проходит некоторое время до того, как будет написано "i 2", но если после этого отключить другой кабель - резервирования не происходит. Т.е. вначале мы ждём пока появится "i 2", затем ждём ещё какое-то время, и только тогда отключение другого кабеля не приводит к разрыву. Причём, если сделать "ls /net", ждать не приходится, резервируется сразу. То есть эта секция не определяет однозначно, что оба линка подняты и зарезервированы?

Всё, что написано выше - проверялось без gns, на тестах iaos2_dummy и client2_dummy из архива.

В начальном посте мы писали так же про проблему с gns:
Цитировать
С ними все совсем плохо, клиент при обрыве пытается переподключиться и ему это не удается.
Как оказалось, с резервированием QNet эта проблема напрямую не связана - там были все те же задержки возврата линков в пул доступных. Но, если отключить оба интерфейса на клиенте, а затем подключить обратно, то даже перезапуск клиента client_dummy не помогает - name_open выдаёт ошибку "Host is down". (При том, что в /net уже появились все хосты). Подключается лишь после "ls /dev/name/global". Если отключать иинтерфейсы на сервере, подобного не происходит. На сервере запускаю gns -s и iaos_dummy, а на клиенте - gns -c и client_dummy. Т.е. клиент gns не обновляет данные о хостах после восстановления связи?

Записан

Инженер-программист
ОАО РТИ
Игорь Рондарев
Сотрудник СВД ВС
Пользователь

Сообщений: 77


Сотрудник СВД ВС


WWW
« Ответ #4 : 07 Октября, 2015, 11:49:00 »

Павел, Александр,
мы постараемся воспроизвести данное поведение на нашем оборудовании и по результатам дать ответы на поставленные вопросы.
Записан

Игорь Рондарев
Сотрудник СВД ВС
Пользователь

Сообщений: 77


Сотрудник СВД ВС


WWW
« Ответ #5 : 27 Октября, 2015, 16:31:38 »

За поведение узлов Qnet (в т.ч. в отказоустойчивой конфигурации) отвечают несколько групп параметров. В частности:

  • tx_retries и tx_ticks - определяют поведение системы при невозможности передать данные по каналу. Параметр tx_ticks устанавливает значение тайм-аута, по истечении которого будет предпринята повторная попытка передачи данных. Параметр tx_retries, в свою очередь, определяет максимальное количество таких попыток. Если количество неудачных попыток достигнет значения tx_retries, данный канал исключается из списка доступных. Обратите внимание, что размер одного "тика" таймаута равен удвоенному стандартному тику Qnet, определяемому параметром periodic_ticks. Т.е., например, при значении periodic_ticks=5 (5 ticks/sec = 200ms), tx_ticks=1 определяет тайм-аут длительностью 400ms.
  • conn_up_retries и conn_up_idle - определяют поведение системы в случае, если по какому-либо из каналов в течение определённого времени не передаются данные (как по причине их отсутствия, т.е. канал простаивает как idle, так и по причине возможных технических проблем в сети). Соответственно, по истечении тайм-аута conn_up_idle (измеряется в стандартных "тиках" Qnet) будет предпринята попытка проверить состояние канала путём отправки специального пакета TCS_UP. Если количество неудачных попыток достигнет значения conn_up_retries, канал также будет исключён из списка доступных для передачи.
  • probe_no_l4_time - определяет периодичность проверки текущего состояния соединения, ранее признанного неработоспособным. Т.е. в случае выхода канала связи из строя в него будет непрерывно с заданным интервалом отправляться broadcast-пакет, и в случае прохождения данного пакета канал связи будет добавлен в пул доступных.

Таким образом, за время реакции на отключения кабеля отвечают первые две пары параметров (в случае передачи данных и в случае простоя канала соответственно), а за время восстановления после выключения и последующего включения кабеля - в первую очередь, параметр probe_no_l4_time. Документация, конечно, рекомендует использование значений параметров по умолчанию; тем не менее, для обеспечения более оперативной реакции на изменение конфигурации сети можно уменьшить тайм-ауты и соответствующие им счётчики до необходимых значений.

В том случае, если первый линк успешно возвращён в пул до отключения второго линка, перерыва в IPC происходить не должно. Если же были одновременно отключены и заново включены оба линка (т.е. произошёл полный физический сбой сети), то, действительно, требуется переподключение ConnectAttach()/name_open(). Относительно поведения name_open() в связке с GNS: чтобы после восстановления конфигурации сети name_open() не возвращала Host is down, необходимо запускать клиента GNS с явным указанием имени используемого GNS-сервера или пула серверов. Пример:
Код:
# gns -c имя_сервера_gns опциональное_имя_резервного_gns

Что касается циклических сообщений в файле /proc/qnetstats, актуальности значений его записей и скорости возврата соединений в пул доступных - нам потребуется дополнительная информация.
Записан

Страниц: [1]   Вверх
  Печать  
 
Перейти в:  

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 посещал эту страницу 13 Ноября, 2016, 13:02:23