С первоначальным вопросом разобрались: мы выдёргивали один кабель, ставили на место, но затем выдёргивали второй слишком быстро - первый интерфейс не успевал добавляться в пул доступных подключений.
Как мы поняли из
документации, на это влияют следующие параметры:
- 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 не обновляет данные о хостах после восстановления связи?
