LINUX.ORG.RU
решено Форум — General  

Проблема в транзитном узле между серверами, как решать?

 ,


0

1

Приветствую! Есть два сервера (А и Б), каждый из которых находится в разных датацентрах (физически в одном городе). Датацентры принадлежат разным компаниям.

Буквально сутки назад, система мониторинга(nagios) показала, что связь между серверами сильно ухудшилась - соединения с сервера А с агентом nagios, на удаленном сервере Б, стали отваливаться по таймауту. Далее, при попытке установить FTP соединение с одного сервера на другой, примерно 50% соединений тоже отваливается по таймауту. При этом не важно в какую сторону устанавливается соединение.

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

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

Уже сутки бьюсь с обоими техподдержками в этих датацентрах, КАЖДАЯ из них говорит у нас все хорошо, мы не виноваты, виноваты не мы, «от нас пакеты уходят», обращайтесь в датацентр с другой стороны. Увиливают, придумывают отмазки, но разбираться в проблеме вне их сети не хотят. Как я понимаю, транзитный узел на котором проблема, не относится ни к одному из этих двух датацентров.

Не понятно, что делать мне?, у меня есть два сервера, которые не могут нормально передавать данные друг другу по вине какой-то четвертой стороны. Как, вообще, правильно решать такие задачи?

← Front end
hp omen 17-an107ur. Загрузка. Выбор видео. →

Использовать 3 узел для обмена, который доступен хорошо и из первого и из второго. )

vvn_black ★★★★★
()
Ответ на: комментарий от vvn_black

Использовать 3 узел для обмена, который доступен хорошо и из первого и из второго. )

:)))))

Вот вам и High Availability по русски.

samson_b ★
() автор топика

что делать мне?

Выявить виновного и писать в их поддержку. Контакы брать в RIPE и т.п. местах. Обычно эту работу должен делать специально обученный человек со стороны провайдра. Но если там такого нет или он МПХ положил на это дело, то придется самому.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)

Конкретный пример:

traceroute to www.abc.co.jp (153.122.6.15), 30 hops max, 60 byte packets
 1  (censored)  0.088 ms  0.102 ms  0.116 ms
 2  (censored)  1.503 ms  1.518 ms  1.512 ms
 3  (censored)  103.725 ms  101.983 ms  103.782 ms
 4  198.32.160.42  102.360 ms  102.529 ms  102.527 ms
 5  58.138.81.49  103.981 ms 58.138.81.53  102.179 ms 58.138.81.49  103.328 ms
 6  58.138.81.210  163.190 ms  163.893 ms  163.847 ms
 7  58.138.88.137  225.065 ms 58.138.88.141  232.873 ms  232.871 ms
 8  58.138.105.242  225.716 ms 58.138.105.246  229.001 ms  229.706 ms
 9  210.130.135.118  234.270 ms  227.220 ms  228.292 ms
10  153.124.130.25  226.365 ms  227.103 ms 153.124.130.33  222.396 ms
11  153.124.130.142  234.019 ms 153.124.130.134  228.072 ms  231.988 ms
12  180.222.177.117  224.773 ms  230.748 ms  231.481 ms
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  *^C
di@di:~$

Например, виноват 58.138.88.137. Смотрим:

di@di:~$ whois 58.138.88.137 
% [whois.apnic.net]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

% Information related to '58.138.0.0 - 58.138.127.255'

% Abuse contact for '58.138.0.0 - 58.138.127.255' is 'hostmaster@nic.ad.jp'

inetnum:        58.138.0.0 - 58.138.127.255
netname:        IIJ
descr:          Internet Initiative Japan Inc.
descr:          Iidabashi Grand Bloom,
descr:          2-10-2 Fujimi, Chiyoda-ku,
descr:          Tokyo, 102-0071 Japan
country:        JP
admin-c:        JNIC1-AP
tech-c:         JNIC1-AP
status:         ALLOCATED PORTABLE
remarks:        Email address for spam or abuse complaints : abuse-contact@iij.ad.jp
mnt-irt:        IRT-JPNIC-JP
mnt-by:         MAINT-JPNIC
mnt-lower:      MAINT-JPNIC
last-modified:  2014-07-31T09:18:02Z
source:         APNIC

irt:            IRT-JPNIC-JP
address:        Urbannet-Kanda Bldg 4F, 3-6-2 Uchi-Kanda
address:        Chiyoda-ku, Tokyo 101-0047, Japan
e-mail:         hostmaster@nic.ad.jp
abuse-mailbox:  hostmaster@nic.ad.jp
admin-c:        JNIC1-AP
tech-c:         JNIC1-AP
auth:           # Filtered
mnt-by:         MAINT-JPNIC
last-modified:  2017-10-18T10:21:54Z
source:         APNIC

role:           Japan Network Information Center
address:        Urbannet-Kanda Bldg 4F
address:        3-6-2 Uchi-Kanda
address:        Chiyoda-ku, Tokyo 101-0047,Japan
country:        JP
phone:          +81-3-5297-2311
fax-no:         +81-3-5297-2312
e-mail:         hostmaster@nic.ad.jp
admin-c:        JI13-AP
tech-c:         JE53-AP
nic-hdl:        JNIC1-AP
mnt-by:         MAINT-JPNIC
last-modified:  2012-08-28T07:58:02Z
source:         APNIC

% Information related to '58.138.88.0 - 58.138.89.255'

inetnum:        58.138.88.0 - 58.138.89.255
netname:        IIJNET
descr:          IIJ Internet
country:        JP
admin-c:        JP00010080
tech-c:         JP00010080
remarks:        This information has been partially mirrored by APNIC from
remarks:        JPNIC. To obtain more specific information, please use the
remarks:        JPNIC WHOIS Gateway at
remarks:        http://www.nic.ad.jp/en/db/whois/en-gateway.html or
remarks:        whois.nic.ad.jp for WHOIS client. (The WHOIS client
remarks:        defaults to Japanese output, use the /e switch for English
remarks:        output)
last-modified:  2015-09-07T19:29:04Z
source:         JPNIC

% This query was served by the APNIC Whois Service version 1.88.15-47 (WHOIS-UK3)


di@di:~$

Видим: tech-c: JNIC1-AP

di@di:~$ whois JNIC1-AP
% [whois.apnic.net]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

% Information related to 'JNIC1-AP'

role:           Japan Network Information Center
address:        Urbannet-Kanda Bldg 4F
address:        3-6-2 Uchi-Kanda
address:        Chiyoda-ku, Tokyo 101-0047,Japan
country:        JP
phone:          +81-3-5297-2311
fax-no:         +81-3-5297-2312
e-mail:         hostmaster@nic.ad.jp
admin-c:        JI13-AP
tech-c:         JE53-AP
nic-hdl:        JNIC1-AP
mnt-by:         MAINT-JPNIC
last-modified:  2012-08-28T07:58:02Z
source:         APNIC

person:         JPNIC Engineering Group
nic-hdl:        JE53-AP
e-mail:         hostmaster@nic.ad.jp
address:        Urbannet-Kanda Bldg 4F
address:        3-6-2 Uchi-Kanda
address:        Chiyoda-ku, Tokyo 101-0047,Japan
phone:          +81-3-5297-2311
fax-no:         +81-3-5297-2312
country:        JP
mnt-by:         MAINT-JPNIC
last-modified:  2012-08-28T08:00:01Z
source:         APNIC

person:         JPNIC IP Department
nic-hdl:        JI13-AP
e-mail:         hostmaster@nic.ad.jp
address:        Urbannet-Kanda Bldg 4F
address:        3-6-2 Uchi-Kanda
address:        Chiyoda-ku, Tokyo 101-0047,Japan
phone:          +81-3-5297-2311
fax-no:         +81-3-5297-2312
country:        JP
mnt-by:         MAINT-JPNIC
last-modified:  2012-08-28T08:00:04Z
source:         APNIC

% This query was served by the APNIC Whois Service version 1.88.15-47 (WHOIS-UK3)


di@di:~$

Пишешь указанным лицам, подробно объясняя проблему и почему ты пишешь именно им.

Deleted
()

Пробовал посмотреть трейсроут с одного сервера до другого? В каком месте задержка возникает?

Zhbert ★★★★★
()
Ответ на: комментарий от Deleted

Ситуация решилась следующим образом. Я объяснил все директору, он позвонил в оба датацентра, начал на них давить уже как человек, который принимает решение с кем мы будем работать, а с кем нет. Один датацентр пошёл в отказ, типа ничего не знаем, проблема не у нас. Второй взялся за дело и в итоге проблему решили. Т.е. в итоге угрозами и давлением удалось заставить работать.

samson_b ★
() автор топика
Ответ на: комментарий от Zhbert

Там проблема была не в icmp, пинги проходили на ура. Проблема была именно в TCP соединениях. Я прикладывал репорты от mtr с настройками на ftp порт. Но даже с ними все было не однозначно, т.к. маршруты в одну и в другую - отличались. Плюс, были узлы, которые статистику не давали. Узлов под подозрением было штуки 3, можно было просто методом перебора найти виновного. Может так в итоге и слелали.

samson_b ★
() автор топика
Последнее исправление: samson_b (всего исправлений: 1)
Ответ на: комментарий от samson_b

Т.е. в итоге угрозами и давлением удалось заставить работать. Мда, как всегда в России. В свое время так же решали вопрос с подписками в мегафоне на рабочий мопед.

Zhbert ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Front end
General
hp omen 17-an107ur. Загрузка. Выбор видео. →