Comments 21
Вы беспокоитесь, что DNS-клиент в XP переключается только при таймауте выше секунды, а в примере в SLA у вас 5 секунд прописаны — как-то нелогично. ;)
> Теперь стандартный механизм балансировки per-flow будет последовательно раскладывать запросы от разных абонентов
Имеется в виду per port? А трафик от одного и того же клиента куда пойдет? На один и тот же сервер? А если он отказал, вы предлагаете клиенту подождать «до 9 * 2 = 18 секунд» (и накинем еще 5 сверху на прописанный таймаут) вместо стандартной секунды, когда у клиента несколько DNS прописаны?
По-моему, этот подход не стоит применять сам по себе — надо комбинировать со стандартной практикой выдачи нескольких DNS (каждый из которых уже может на самом деле являться балансировщиком).
> если в определенный момент один из серверов не ответит или ответит некорректно на DNS-запрос
А «ответит некорректно» — это как? Каковы критерии «корректности» ответа и вообще настраиваются ли они?
А что будет, если «некорректный ответ» выдадут все включенные в настройку DNS (ну, например, домен гугла разделегируется :D)? Есть ли возможность сделать дополнительные критерии для проверки?
> Теперь стандартный механизм балансировки per-flow будет последовательно раскладывать запросы от разных абонентов
Имеется в виду per port? А трафик от одного и того же клиента куда пойдет? На один и тот же сервер? А если он отказал, вы предлагаете клиенту подождать «до 9 * 2 = 18 секунд» (и накинем еще 5 сверху на прописанный таймаут) вместо стандартной секунды, когда у клиента несколько DNS прописаны?
По-моему, этот подход не стоит применять сам по себе — надо комбинировать со стандартной практикой выдачи нескольких DNS (каждый из которых уже может на самом деле являться балансировщиком).
> если в определенный момент один из серверов не ответит или ответит некорректно на DNS-запрос
А «ответит некорректно» — это как? Каковы критерии «корректности» ответа и вообще настраиваются ли они?
А что будет, если «некорректный ответ» выдадут все включенные в настройку DNS (ну, например, домен гугла разделегируется :D)? Есть ли возможность сделать дополнительные критерии для проверки?
а в примере в SLA у вас 5 секунд прописаны
Скажу больше. Это timeout. Более критичен threshold (который тоже неявно 5000мс). Так что все еще жестче! ))) Конечно это ошибка. Спасибо! Исправил и добавил в конфиг
threshold 10Имеется в виду per port? А трафик от одного и того же клиента куда пойдет?
Если мне не изменяет память, Cisco по умолчанию раскладывает per flow. Критерии отдельного flow: src ip + dst ip + src port + dst port. Так что, по идее, трафик нового запроса должен уйти на другой сервер (в пределах вероятности), так как flow другой. Но есть мнение, что Cisco не учитывает src port, так как в production замечены случаи, что запросы одного абонента стабильно попадали на один резолвер.
вы предлагаете клиенту подождать
По сути — да. Только threshold можно поправить, так что просто <=9 секунд. И тут, в комментариях ниже, что нужно присмотреться к версии IOS. Вроде бы можно и меньше, но ничего не могу сказать — у меня 9.
А «ответит некорректно» — это как?… домен гугла разделегируется
Например NXDOMAIN:
IPSLA operation id: 200 Latest RTT: 0 milliseconds Latest operation start time: 20:20:02 UTC+7 Wed Aug 17 2016 Latest operation return code: DNS query error Number of successes: 0 Number of failures: 11 Operation time to live: Forever
Конечно, тут основная идея, что мы выбираем неких «контрольный» домен и допускаем, что вероятность его сбоя или сбоя корневых серверов существенно ниже сбоя вашей инфраструктуры или ошибки конфигурации ваших инженеров. Например, DNS-ом у вас внезапно начал заниматься студен-практикант. )))) Тогда, если однажды Вы получите nxdomain вместо www.google.com, логично в первую очередь проверить, как там дела у студента и что он делает с кэшом, а потом звонить в гугол ))))
Но есть мнение, что Cisco не учитывает src port, так как в production замечены случаи, что запросы одного абонента стабильно попадали на один резолвер.
Конечно это всё от Cisco зависит, но если есть возможность то решается вот этой командой: ip cef load-sharing algorithm include-ports source destination. По умолчанию не так.
Собственно абонент может и запросы постоянно с одного порта посылать. Особенно если это активный DNS.
Добрый день.
Разве
track 1 ip sla 1
track 2 ip sla 1
track 3 ip sla 1
не значит что все три трека опираются на 1й sla?
И может это ограшничения именного вашей версии IOS, но я использовал меньшие значения frequency
Разве
track 1 ip sla 1
track 2 ip sla 1
track 3 ip sla 1
не значит что все три трека опираются на 1й sla?
И может это ограшничения именного вашей версии IOS, но я использовал меньшие значения frequency
«Активация и настройка трэкинга:»
Предполагаю, что настройка привязки трэкинга не совсем правильно написана:
track 1 ip sla 1
track 2 ip sla 1
track 3 ip sla 1
может надо так:
track 1 ip sla 1
track 2 ip sla 2
track 3 ip sla 3
Предполагаю, что настройка привязки трэкинга не совсем правильно написана:
track 1 ip sla 1
track 2 ip sla 1
track 3 ip sla 1
может надо так:
track 1 ip sla 1
track 2 ip sla 2
track 3 ip sla 3
А мы просто выдаём на каждый DHCP-запрос DNS-сервера в случайном порядке, а сами IP серверов — виртуальные через VRRPv3, которые распределены по реальным серверам.
В итоге имеем практически идеальную балансировку нагрузки и время реакции при отказе сервера в 0.1 секунды.
В итоге имеем практически идеальную балансировку нагрузки и время реакции при отказе сервера в 0.1 секунды.
Это с DHCP. А если DNS прописан в настройка Virtual-Template для PPPoE и настраивается по LCP? Либо два Vt и думать как их распределить равномерно. Либо менять конфиг Vt через равные интервалы времени. Либо опять же — уходить на DHCP.
Да, тут всё зависит от архитектуры, но сейчас всё больше популярен т.н. IPoE где эта схема вполне применима.
Она, как минимум, проще в настройке, не имеет SPOF в виде роутера (который тоже тогда придётся резервировать, городить динамику и т.п.).
Ну, и как сказали ниже, анонсы IP со стороны сервера выглядят красивее. На том же OSPF можно настроить суб-секундные таймауты и время реакции будет почти мгновенным.
Она, как минимум, проще в настройке, не имеет SPOF в виде роутера (который тоже тогда придётся резервировать, городить динамику и т.п.).
Ну, и как сказали ниже, анонсы IP со стороны сервера выглядят красивее. На том же OSPF можно настроить суб-секундные таймауты и время реакции будет почти мгновенным.
А мне нравится когда подобные задачи решены чистой маршрутизацией — anycast адресацией. Конечно это не самый простой способ и для этого нужно активное взаимодействие с таблицей маршрутизации со стороны устройств в сети назначения. Но, IMHO, в целом получается красивее. Нету NAT, нету внешнего по отношению к сети сервиса такого как IP SLA.
Интересно. А чуть подробней?
Собственно это просто продолжение вашего примера. Вместо статик маршрутов поднимаем динамические в каком-либо из протоколов маршрутизации. Если серверы в разных устройствах то просто делаем redistribute, но тут опять имеем проблему что линк может быть, а сервер не отвечать.
Поэтому поднимаем маршрутизацию на самом сервере, фильтруем максимально анонсы чтобы обрабатывалось по минимуму и не сильно ресурсов отбирало. Если ломается что-то на сервере с маршрутизацией или сетью то соответственно маршрут исчезает. Время реакции накручивается таймерами. Т.е. делаем сервер активным непосредственным участником, а не просто чтобы он отпинывался на IP SLA.
Для link-state протоколов удобно иметь данные маршруты как external, чтобы проще метрикой управлять было.
Так же можно полностью резервный сервер поднимать, сервера распределённые по территориям — трафик пойдёт по таблице маршрутизации: как ближе, как настроил администратор. Для DNS, DHCP, NTP вообще никаких проблем не будет.
Поэтому поднимаем маршрутизацию на самом сервере, фильтруем максимально анонсы чтобы обрабатывалось по минимуму и не сильно ресурсов отбирало. Если ломается что-то на сервере с маршрутизацией или сетью то соответственно маршрут исчезает. Время реакции накручивается таймерами. Т.е. делаем сервер активным непосредственным участником, а не просто чтобы он отпинывался на IP SLA.
Для link-state протоколов удобно иметь данные маршруты как external, чтобы проще метрикой управлять было.
Так же можно полностью резервный сервер поднимать, сервера распределённые по территориям — трафик пойдёт по таблице маршрутизации: как ближе, как настроил администратор. Для DNS, DHCP, NTP вообще никаких проблем не будет.
Ясно. Такое делаем. Я просто как-то не сразу понял, что под anycast имеется ввиду. Тут только один аспект в пользу IP SLA: сам маршрутизатор, по сути, живость сервиса контролирует, а не только достижимость хоста. Т.е. ловим падение демона, к примеру, или ошибку конфигурации без внешнего мониторинга.
А в остальном — согласен. Quagga на самом DNS и полный вперед.
А в остальном — согласен. Quagga на самом DNS и полный вперед.
Sign up to leave a comment.
Балансировка кэширующего DNS на основе Cisco IP SLA