Страница 5 из 14

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 08 сен 2013, 15:49
Barvinok
Приглядись к первой странице.
Я писал(а):Из статьи "Маршрутизация без скриптов" я взял на заметку проверку работоспособности канала пингуя не провайдерский шлюз, а удалённый хост.

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 08 сен 2013, 20:18
aabbyr
aabbyr писал(а):
Как быть в таком случае?


Это был риторический вопрос. Смысл в том, что "check-gateway=ping" не выход из положения.

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 08 сен 2013, 23:49
Barvinok
Вот я сейчас не понял.
Ты задавал вопрос не ради ответа, а просто упражняясь в риторике?

Если на то пошло, то прохождение пинга до яндекса так же не служит залогом успешной работы по HTTP с этим самым яндексом. Я полагаю более надёжным признаком возможность/невозможность установки TCP-соединения.
Тут можно развернуть ещё одно исследование (кстати, не хочешь проделать здесь эту работу?).
Я же собирал внимание читающих именно на способах распределении нагрузки по двум каналам: ECMP, PCC, NTH...

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 09 сен 2013, 00:42
aabbyr
В риторике не упражнялся. В теме статьи меня больше заинтересовала "отказоустойчивость", поэтому хотел обратить Ваше внимание на строчку "check-gateway=ping". И пропустил ссылку на статью "Advanced Routing Failover without Scripting". Приношу свои извинения.

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 09 сен 2013, 11:35
Barvinok
Ты прав. В названии темы действительно заявлена отказоустойчивость. Изначально я полагал, что она сама собой достигается использованием двух каналов, но как оказалось, не всё так просто.
То, что для конечного пользователя определяется, как "у меня не работает интернет", может иметь множество причин:
  • Тупо обрыв линии (тут "check-gateway=ping" на высоте);
  • Неполадки на маршруте или не оплачен провайдер. "check-gateway=ping" не прокатывает, поскольку шлюз пингуется;
  • Не доступен или плохо работает DNS-сервер;
  • Где-то срабатывают фильтры по протоколам на определённые порты. Пинги проходят, а HTTP не коннектится;
  • Значение MTU. Выглядит так, будто интернет то работает, то нет;
  • Может ещё что-то
Об этом надо крепко думать и писать скрипты (или искать готовые).

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 20 сен 2013, 21:48
wolf_ktl
Barvinok писал(а):Ты прав. В названии темы действительно заявлена отказоустойчивость. Изначально я полагал, что она сама собой достигается использованием двух каналов, но как оказалось, не всё так просто.
То, что для конечного пользователя определяется, как "у меня не работает интернет", может иметь множество причин:
  • Тупо обрыв линии (тут "check-gateway=ping" на высоте);
  • Неполадки на маршруте или не оплачен провайдер. "check-gateway=ping" не прокатывает, поскольку шлюз пингуется;
  • Не доступен или плохо работает DNS-сервер;
  • Где-то срабатывают фильтры по протоколам на определённые порты. Пинги проходят, а HTTP не коннектится;
  • Значение MTU. Выглядит так, будто интернет то работает, то нет;
  • Может ещё что-то
Об этом надо крепко думать и писать скрипты (или искать готовые).



Да было бы шикарно иметь такой скрипт

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 21 сен 2013, 00:35
Barvinok
Буду рассуждать.
1. Значение MTU явно задаются руками при настройке маршрутизатора, ежели в том будет необходимость. Т.е. мы изначально добиваемся работоспособности обоих каналов и больше к вопросу MTU не возвращаемся.

То же касается и DNS-серверов. Время от времени их нужно проверять на способность исполнять свои обязанности. Если не способен - вычёркивать из списка используемых. К сожалению в RouterOS отсутствует команда, подобная nslookup, пока не знаю, чем его заменить из наличествующего арсенала.
Но несомненно одно: используемый DNS-сервера должны действительно работать!


2. Можно ли считать прохождение пинга надёжным знаком того, что канал жив? Ну, в целом то да. Но возможен случай, когда ICMP-трафик проходит, а TCP - нет. У меня на домашнем Би-Лайне именно так: даже с выключенным L2TP-соединением пинги в интернет ходят через Билайновский интранет. TCP и UDP разумеется нет.
Но если такой ерунды не происходит, то в 9 из 10 случаев пинг удалённых серверов можно считать хорошим знаком.

3. Рассмотрим случай возможности/невозможности установить TCP-подключение на 80-й порт yandex.ru. Можно ли с уверенностью сказать, что если такое соединение устанавливается, то канал жив? Вероятно.
А если это прокси провайдера с сообщением о неуплате? Пинги к внешним серверам в этом случае, кстати, тоже могут ходить! Засада...
Значит нам нужно проверить не просто возможность подключения к некоему серверу, но и убедиться, что он отдаёт нам ожидаемую страницу! Т.е. нам придётся парсить HTML...
Мы можем использовать кусок кода из Dynamic DNS Update Script.

Код: Выделить всё

# get the current IP address from the internet (in case of double-nat)
/tool fetch mode=http address="checkip.dyndns.org" src-path="/" dst-path="/dyndns.checkip.html"
:delay 1
:local result [/file get dyndns.checkip.html contents]

# parse the current IP result
:local resultLen [:len $result]
:local startLoc [:find $result ": " -1]
:set startLoc ($startLoc + 2)
:local endLoc [:find $result "</body>" -1]
:local currentIP [:pick $result $startLoc $endLoc]
:log info "UpdateDynDNS: currentIP = $currentIP"

Мы можем сравнить полученный ip-адрес с нашим адресом на интерфейсе и если они совпадают - канал точно работает!
Но только при условии наличия белого адреса, разумеется. Если у вас на внешнем интерфейсе серые адреса нужно будет чуть по другому.

А если указанный сайт недоступен, можно ли с такой же уверенностью сказать, что канал упал? Не можем, поскольку:
а) может упасть сам checkip.dyndns.org;
б) ещё причина могла крыться в недоступности DNS-сервера. Т.е. канал то жив, но имя checkip.dyndns.org не преобразуется в ip-адрес. Но поскольку мы изначально эту возможность предусмотрели и приняли меры, то "б" вычёркиваем.

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

Вот такие мысли. Что скажите, уважаемые?

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 21 сен 2013, 16:15
wolf_ktl
Barvinok писал(а):Буду рассуждать.

3. Рассмотрим случай возможности/невозможности установить TCP-подключение на 80-й порт yandex.ru. Можно ли с уверенностью сказать, что если такое соединение устанавливается, то канал жив? Вероятно.
А если это прокси провайдера с сообщением о неуплате? Пинги к внешним серверам в этом случае, кстати, тоже могут ходить! Засада...
Значит нам нужно проверить не просто возможность подключения к некоему серверу, но и убедиться, что он отдаёт нам ожидаемую страницу! Т.е. нам придётся парсить HTML...
Мы можем использовать кусок кода из Dynamic DNS Update Script.

Код: Выделить всё

# get the current IP address from the internet (in case of double-nat)
/tool fetch mode=http address="checkip.dyndns.org" src-path="/" dst-path="/dyndns.checkip.html"
:delay 1
:local result [/file get dyndns.checkip.html contents]

# parse the current IP result
:local resultLen [:len $result]
:local startLoc [:find $result ": " -1]
:set startLoc ($startLoc + 2)
:local endLoc [:find $result "</body>" -1]
:local currentIP [:pick $result $startLoc $endLoc]
:log info "UpdateDynDNS: currentIP = $currentIP"

Мы можем сравнить полученный ip-адрес с нашим адресом на интерфейсе и если они совпадают - канал точно работает!
Но только при условии наличия белого адреса, разумеется. Если у вас на внешнем интерфейсе серые адреса нужно будет чуть по другому.

А если указанный сайт недоступен, можно ли с такой же уверенностью сказать, что канал упал? Не можем, поскольку:
а) может упасть сам checkip.dyndns.org;
б) ещё причина могла крыться в недоступности DNS-сервера. Т.е. канал то жив, но имя checkip.dyndns.org не преобразуется в ip-адрес. Но поскольку мы изначально эту возможность предусмотрели и приняли меры, то "б" вычёркиваем.

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

Вот такие мысли. Что скажите, уважаемые?


Ну можно заморочиться и воспользоваться и checkip.dyndns.org и no-ip.org ... одновременно )))

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 21 сен 2013, 20:43
Barvinok
По моему мы тут дурака валяем.
Интернет полон всякими потоковыми сервисами и мусорным трафиком. Зачем генерить свой, если можно использовать то, что есть?
Запустите /tool sniffer или /ip firewall connection и вы увидите, что какие-то добрые люди постоянно сканируют ваши порты и пытаются вам что-то прислать.
Это будет похоже на шум океана или большого города.
Если этот шум вдруг прекратился - значит канал пал (второй вариант - ядерный апокалипсис - я пока не рассматриваю).
Осталось только это как-то выразить в коде...


Однако, если вы находитесь за NATом провайдера (серый адрес), то шум большого Интернета до вас долетать не будет.
В этом случае можно положиться на UDP-протокол, который я незаслуженно обошёл вниманием.
При блокировке интернета ICMP может продолжать гулять. Но UDP перекрывается провайдером наравне с TCP. Можно, к примеру, слать запросы к NTP-серверам. Если ответы приходят - интернет жив!
Но хранители времени не любят, когда их часто тревожат и могут вас очень скоро забанить.

Ещё есть всякие широковещательные службы, вроде интернет-радио. Достаточно к ним один раз подключиться и они направят к вам UDP-поток.

Да много чего ещё есть - это же ИНТЕРНЕТ!

Буду думать, как бы это покрасивше всё оформить.

Re: Два провайдера: отказоустойчивость и распределение нагру

Добавлено: 21 сен 2013, 20:47
aabbyr
по поводу отказоустойчивости интересная статья
Скрипт автора пингует три разных узла. Интернет на интерфейсе считается нерабочим, если приходит менее 2/3 ответов
http://www.pvsm.ru/sistemnoe-administrirovanie/5083