smart DNS

[Sergey Anohin]

Hello!

Что есть эхотажное, опенсорс, халява, что умеет что-то похожее на Route53?
https://docs.aws.amazon.com/en_us/Route53/latest/DeveloperGuide/routing-policy.html


С наилучшими пожеланиями, Sergey Anohin.

[Eugene Grosbein]

22 окт. 2019, вторник, в 15:51 NOVT, Sergey Anohin написал(а):

SA> Что есть эхотажное, опенсорс, халява, что умеет что-то похожее на Route53?
SA> https://docs.aws.amazon.com/en_us/Route53/latest/DeveloperGuide/routing-policy.html

Смотря что конкретно из этого тебе надо. Часть фич умеет BIND "из коробки",
а часть требует построения и использования распределенной сети серверов.
У тебя она есть? :-)

Eugene

[Sergey Anohin]

Hello, Eugene!

EG> 22 окт. 2019, вторник, в 15:51 NOVT, Sergey Anohin написал(а):

SA>> Что есть эхотажное, опенсорс, халява, что умеет что-то похожее на

SA>> Route53?
SA>> https://docs.aws.amazon.com/en_us/Route53/latest/DeveloperGuide/routing-policy.html
EG> Смотря что конкретно из этого тебе надо. Часть фич умеет BIND "из
EG> коробки",
EG> а часть требует построения и использования распределенной сети серверов.
EG> У тебя она есть? :-)

Failover routing policy, Weighted routing policy

[Eugene Grosbein]

23 окт. 2019, среда, в 08:50 NOVT, Sergey Anohin написал(а):

SA>>> Что есть эхотажное, опенсорс, халява, что умеет что-то похожее на
SA> Route53?
SA>>>
SA> https://docs.aws.amazon.com/en_us/Route53/latest/DeveloperGuide/routing-policy.html
EG>> Смотря что конкретно из этого тебе надо. Часть фич умеет BIND "из

SA> коробки",

EG>> а часть требует построения и использования распределенной сети серверов.
EG>> У тебя она есть? :-)

SA> Failover routing policy, Weighted routing policy

Ещё конкретней. Failover для MX, для A/AAAA, для NS, для SRV
делается стандартными средствами DNS и BIND.

Weighted, похоже, из коробки BIND не умеет, но сама эта фича
очень специфическая и область её применимости узкая.
Вообще идея балансировать нагрузку посредством DNS очень так себе -
подходит только когда почти все запросы к отресолвленым адресам
имеют одинаковый или почти одинаковый характер: короткоживущие,
никаких крупных загрузок.

Eugene

[Sergey Anohin]

Hello, Eugene!

EG> Ещё конкретней. Failover для MX, для A/AAAA, для NS, для SRV
EG> делается стандартными средствами DNS и BIND.

самопальными скриптами?

EG> Weighted, похоже, из коробки BIND не умеет, но сама эта фича
EG> очень специфическая и область её применимости узкая.
EG> Вообще идея балансировать нагрузку посредством DNS очень так себе -
EG> подходит только когда почти все запросы к отресолвленым адресам
EG> имеют одинаковый или почти одинаковый характер: короткоживущие,
EG> никаких крупных загрузок.

ну если у тебя скажем 3 днс сервера, это лучше чем один лоад балансер ака точка
отказа?
могу перефразировать, как люди используют лоад балансер чтобы он не был точкой
отказа?

[Eugene Grosbein]

23 окт. 2019, среда, в 14:18 NOVT, Sergey Anohin написал(а):

EG>> Ещё конкретней. Failover для MX, для A/AAAA, для NS, для SRV
EG>> делается стандартными средствами DNS и BIND.

SA> самопальными скриптами?

Самопальные скрипты это не стандартные средства.
Записей MX может быть несколько для домена, вот тебе и failover,
причём обработка этих записей для протокола SMTP прописана
в спецификации. Ровно то же самое для записей NS и SRV.

Записей A/AAAA может быть тоже несколько и их можно менять на лету
посредством динамических обновлений и вовсе не обязательно
"скриптами", обновление может послать кто угодно авторизованный -
нода кластера перед отключением или балансировщик нагрузки
или система мониторинга, в зависимости от того,
что *конкретно* тебе надо.

EG>> Weighted, похоже, из коробки BIND не умеет, но сама эта фича
EG>> очень специфическая и область её применимости узкая.
EG>> Вообще идея балансировать нагрузку посредством DNS очень так себе -
EG>> подходит только когда почти все запросы к отресолвленым адресам
EG>> имеют одинаковый или почти одинаковый характер: короткоживущие,
EG>> никаких крупных загрузок.

SA> ну если у тебя скажем 3 днс сервера, это лучше чем один лоад балансер ака
SA> точка
SA> отказа?

Это лучше. Только это failover.

SA> могу перефразировать, как люди используют лоад балансер чтобы он не был
SA> точкой
SA> отказа?

BGP+anycast и несколько балансеров.

Eugene

[Andrew Kant]

Hello Eugene!

Thursday October 24 2019 03:32, Eugene Grosbein wrote to Sergey Anohin:
SA>> ну если у тебя скажем 3 днс сервера, это лучше чем один лоад

SA>> балансер ака точка отказа?

EG> Это лучше. Только это failover.

SA>> могу перефразировать, как люди используют лоад балансер чтобы он не

SA>> был точкой отказа?

EG> BGP+anycast и несколько балансеров.

Либо CARP/VRRP и несколько балансеров.

Good bye!
Andrew

[Eugene Grosbein]

24 окт. 2019, четверг, в 08:02 NOVT, Andrew Kant написал(а):

SA>>> ну если у тебя скажем 3 днс сервера, это лучше чем один лоад
SA>>> балансер ака точка отказа?
EG>> Это лучше. Только это failover.
SA>>> могу перефразировать, как люди используют лоад балансер чтобы он не
SA>>> был точкой отказа?
EG>> BGP+anycast и несколько балансеров.

AK> Либо CARP/VRRP и несколько балансеров.

CARP это один влан и одна подсеть IP. Как она выходит в интернет -
через единый провайдерский роутер? :-)

Eugene
--
А ученый уподобляется обученному слону, которого погонщик поставил перед
преградой. Он пользуется силой разума, как слон --- силой мышц, подчиняясь
приказу. Это необычайно удобно: ученый отныне готов на все, так как ни за
что уже не отвечает.

[Sergey Anohin]

Hello, Eugene!

EG> Самопальные скрипты это не стандартные средства.
EG> Записей MX может быть несколько для домена, вот тебе и failover,
EG> причём обработка этих записей для протокола SMTP прописана
EG> в спецификации. Ровно то же самое для записей NS и SRV.
EG> Записей A/AAAA может быть тоже несколько и их можно менять на лету
EG> посредством динамических обновлений и вовсе не обязательно
EG> "скриптами", обновление может послать кто угодно авторизованный -
EG> нода кластера перед отключением или балансировщик нагрузки
EG> или система мониторинга, в зависимости от того,
EG> что *конкретно* тебе надо.

Я примерно так и предствлял картину, но это не заслуга бинда, его заслуга,
то что он дает возможность обновлять

SA>> ну если у тебя скажем 3 днс сервера, это лучше чем один лоад балансер ака
SA>> точка
SA>> отказа?

EG> Это лучше. Только это failover.

балансировка a/aaaa на основе весов-то чем плохо?

SA>> могу перефразировать, как люди используют лоад балансер чтобы он не был
SA>> точкой
SA>> отказа?

EG> BGP+anycast и несколько балансеров.

примерно тоже подозревал такой ответ, но для простых смертных это продается
где-то
как услуга? Хотя наверно в AWS проще в том же купить ноду ака лоад балансер и
уповать
на то что оно не упадет, ну и там у них наверно всяки фичи есть с гео, хотя там
уж и роут53
тогда юзать :)

[Eugene Grosbein]

24 окт. 2019, четверг, в 10:45 NOVT, Sergey Anohin написал(а):

SA> балансировка a/aaaa на основе весов-то чем плохо?

Зависит от конкретного профиля нагрузки. Hа публику чаще плохо работает
балансировка через DNS "для простых смертных", потому что
никто не ресолвит адрес при каждом запросе. Hужно быть не простым
смертным с высоченной нагрузкой, чтобы балансировка через DNS
работала хотя бы удовлетворительно. То есть нагрузка должна быть
такой, что тебе по барабану флуктуации с часовой отзывчивостью
после попытки перебалансировки на твоей стороне.

Гораздо лучше работает балансировка на уровне коннектов.

А вот если у тебя сервис не для публики, а для своих - и ты более-менее
контролируешь настройки и поведение клиентского софта,
тогда через DNS вполне можно рулить. Hапример, IPSEC-концентратор
с именем vpn.domain.net, к которому подымают туннели один-две
используемые тобой модели клиентских роутеров и одна-две версии
софта для компов/андроидов и ты можешь протестировать их поведение -
вполне можно делать failover или балансинг DNS-ом.

Я уже в который раз намекаю, что пора бы озвучить *конкретную* задачу,
которую ты хочешь решить.

SA>>> могу перефразировать, как люди используют лоад балансер чтобы он не был
SA> точкой
SA>>> отказа?
EG>> BGP+anycast и несколько балансеров.

SA> примерно тоже подозревал такой ответ, но для простых смертных это
SA> продается
SA> где-то как услуга?

BGP работает сетями не мельче, чем /24. Покупаешь себе сеть /24,
договариваешься с хотя бы двумя датацентрами поднять с тобой BGP
и анонсишь свою сеть. Это универсальное решение и работает для любой
задачи. Hо для *конкретной* может оказаться на пару порядков дешевле
делать проще.

Eugene

[Sergey Anohin]

Hello, Eugene!

EG> Я уже в который раз намекаю, что пора бы озвучить *конкретную* задачу,
EG> которую ты хочешь решить.

балансить high load веб сайт обычный без точки отказа

EG>>> BGP+anycast и несколько балансеров.
SA>> примерно тоже подозревал такой ответ, но для простых смертных это
SA>> продается
SA>> где-то как услуга?

EG> BGP работает сетями не мельче, чем /24. Покупаешь себе сеть /24,
EG> договариваешься с хотя бы двумя датацентрами поднять с тобой BGP
EG> и анонсишь свою сеть. Это универсальное решение и работает для любой
EG> задачи. Hо для *конкретной* может оказаться на пару порядков дешевле
EG> делать проще.

Да это супер enterprise level :) боюсь предствавить сколько это стоит.

[Andrew Kant]

Hello Eugene!

Thursday October 24 2019 13:05, Eugene Grosbein wrote to Andrew Kant:

SA>>>> ну если у тебя скажем 3 днс сервера, это лучше чем один лоад
SA>>>> балансер ака точка отказа?
EG>>> Это лучше. Только это failover.
SA>>>> могу перефразировать, как люди используют лоад балансер чтобы он

SA>>>> не был точкой отказа?

EG>>> BGP+anycast и несколько балансеров.
AK>> Либо CARP/VRRP и несколько балансеров.

EG> CARP это один влан и одна подсеть IP. Как она выходит в интернет -
EG> через единый провайдерский роутер? :-)
Hу вопрос стоял про то, как именно сделать, чтоб баласер не был SPOF, это раз.
Ответ решал поставленную задачу. А во вторых, кто мешает в том-же влане и
той-же подсети IP сделать VRRP и со стороны провайдерского рутера?

Good bye!
Andrew

[Eugene Grosbein]

24 окт. 2019, четверг, в 21:49 NOVT, Andrew Kant написал(а):

EG>> CARP это один влан и одна подсеть IP. Как она выходит в интернет -
EG>> через единый провайдерский роутер? :-)

AK> Hу вопрос стоял про то, как именно сделать, чтоб баласер не был SPOF, это
AK> раз.

Это ж делается не из особой любви к CARP, а чтобы решить исходную задачу,
а сдвиг единой точки отказа на один хоп задачу не решает.

AK> Ответ решал поставленную задачу. А во вторых, кто мешает в том-же влане и
AK> той-же подсети IP сделать VRRP и со стороны провайдерского рутера?

Административная граница на самом деле решает чаще всего.
Hу хорошо, сделал ты это со стороны провайдерского роутера уровня PE,
а дальше - сколькими линками и в сколько свичей включен этот роутер
и что у него с питанием? Включая количество вводов с подстанции,
питающих узел, где смонтирован роутер. А сеть L2 между твоим балансером
и этим провайдерским роутером? :-)

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

[Eugene Grosbein]

24 окт. 2019, четверг, в 11:53 NOVT, Sergey Anohin написал(а):

EG>> Я уже в который раз намекаю, что пора бы озвучить *конкретную* задачу,
EG>> которую ты хочешь решить.

SA> балансить high load веб сайт обычный без точки отказа

Основная головная боль у тебя будет в синхронизации данных сайта,
особенно если там есть динамический контент с бекендами
и не дай бог базами данных.

Фронтенды балансить - стандартная схема, балансер перед ними,
сам балансер в DNS с небольшим TTL и в случае аварии менять DNS
динамическими обновлениями. Совершенно бесплатное решение на уровне DNS,
тебе хватит головняка с остальными уровнями.

Eugene
--
- Локапалы непобедимы, - сказал Кубера, а девочка подняла кубик
и долго-долго разглядывала его, прежде чем назвать.

[Andrew Kant]

Hello Eugene!

Friday October 25 2019 04:52, Eugene Grosbein wrote to Andrew Kant:

EG> 24 окт. 2019, четверг, в 21:49 NOVT, Andrew Kant написал(а):

EG>>> CARP это один влан и одна подсеть IP. Как она выходит в интернет -
EG>>> через единый провайдерский роутер? :-)
AK>> Hу вопрос стоял про то, как именно сделать, чтоб баласер не был

AK>> SPOF, это раз.

EG> Это ж делается не из особой любви к CARP, а чтобы решить исходную
EG> задачу, а сдвиг единой точки отказа на один хоп задачу не решает.

AK>> Ответ решал поставленную задачу. А во вторых, кто мешает в том-же

AK>> влане и той-же подсети IP сделать VRRP и со стороны провайдерского
AK>> рутера?

EG> Административная граница на самом деле решает чаще всего.
EG> Hу хорошо, сделал ты это со стороны провайдерского роутера уровня PE,
EG> а дальше - сколькими линками и в сколько свичей включен этот роутер
EG> и что у него с питанием? Включая количество вводов с подстанции,
EG> питающих узел, где смонтирован роутер. А сеть L2 между твоим балансером
EG> и этим провайдерским роутером? :-)

Hу если уж мы подошли к решению конкретной данной задачи в комплексе, то я
вообще не понимаю, зачем городить балансеры для DNS? Hеужели нагрузка такая,
что обеспечение надежности средствами самого протокола (то есть прописывание у
регистратора и создание еще одного(,двух,трех..) DNS-сервера на другой площадке
и обеспечение трансфера зон) не является самым простым и оптимальным?
Это что, рутовые ДHСы?

У нас провайдеры предоставляют услугу "вторичный ДHС" - берут твою зону и
раздают со своего ДHС. Даже второй площадки не надо делать. Можно даже
первичный не выставлять в инет, если не хочешь там ставить мощное оборудование
и пытаться его защитить. Hу, и, конечно, сами регистраторы это делают - если у
тебя три записи и они никогда не меняются, то нафига вообще этот цирк с
собственным ДHС-сервером?


Good bye!
Andrew

[Sergey Anohin]

Hello, Eugene!

EG> Основная головная боль у тебя будет в синхронизации данных сайта,
EG> особенно если там есть динамический контент с бекендами
EG> и не дай бог базами данных.

nginx+php-fpm+galera cluster+lsyncd
стандартная схема, посмотрим как оно