Взвешенные круглые робины через TTL - возможно?

В настоящее время я использую циклический перебор DNS для балансировки нагрузки, который прекрасно работает. Записи выглядят так (у меня TTL 120 секунд)

;; ANSWER SECTION:
orion.2x.to.        116 IN  A   80.237.201.41
orion.2x.to.        116 IN  A   87.230.54.12
orion.2x.to.        116 IN  A   87.230.100.10
orion.2x.to.        116 IN  A   87.230.51.65

Я узнал, что не каждый провайдер / устройство обрабатывает такой ответ одинаково. Например, некоторые DNS-серверы меняют адреса случайным образом или всегда их перебирают. Некоторые просто распространяют первую запись, другие пытаются определить, какая из них лучше (ближе к региону), посмотрев на IP-адрес.

Однако, если пользовательская база достаточно велика (распределена по нескольким интернет-провайдерам и т. Д.), Баланс достаточно хорош. Расхождения от самого высокого до самого низкого загруженного сервера едва ли превышают 15%.

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

В настоящее время у меня есть только серверы 1 Гбит / с, но я хочу работать со 100 Мбит / с, а также с серверами 10 Гбит / с.

Итак, я хочу представить сервер со скоростью 10 Гбит / с весом 100, сервер 1 Гбит / с весом 10 и сервер 100 Мбит / с весом 1.

Ранее я дважды добавлял серверы для увеличения трафика (что работало хорошо - пропускная способность почти удвоилась). Но добавление сервера 10 Гбит / с 100 раз в DNS немного нелепо.

Поэтому я подумал об использовании TTL.

Если я даю серверу A 240 секунд TTL, а серверу B - только 120 секунд (что примерно равно минимуму, который следует использовать для циклического перебора, поскольку для многих DNS-серверов установлено значение 120, если указан более низкий TTL (как я слышал)). Я думаю, что-то подобное должно происходить в идеальном сценарии:

First 120 seconds
50% of requests get server A -> keep it for 240 seconds.
50% of requests get server B -> keep it for 120 seconds

Second 120 seconds
50% of requests still  have server A cached -> keep it for another 120 seconds.
25% of requests get server A -> keep it for 240 seconds
25% of requests get server B -> keep it for 120 seconds

Third 120 seconds
25% will get server A (from the 50% of Server A that now expired) -> cache 240 sec
25% will get server B  (from the 50% of Server A  that now expired) -> cache 120 sec
25% will have server A cached for another 120 seconds
12.5% will get server B (from the 25% of server B that now expired) -> cache 120sec
12.5% will get server A (from the 25% of server B that now expired) -> cache 240 sec

Fourth 120 seconds
25% will have server A cached -> cache for another 120 secs
12.5% will get server A (from the 25% of b that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of b that now expired) -> cache 120 secs
12.5% will get server A (from the 25% of a that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of a that now expired) -> cache 120 secs
6.25% will get server A (from the 12.5% of b that now expired) -> cache 240 secs
6.25% will get server B (from the 12.5% of b that now expired) -> cache 120 secs
12.5% will have server A cached -> cache another 120 secs
... I think I lost something at this point, but I think you get the idea...

Как видите, это довольно сложно предсказать, и на практике это не сработает. Но это определенно должно повлиять на распространение!

Я знаю, что взвешенный круговой метод существует и управляется только корневым сервером. Он просто циклически просматривает записи DNS при ответе и возвращает записи DNS с установленной вероятностью, соответствующей весу. Мой DNS-сервер не поддерживает это, и мои требования не настолько точны. Если он не весит идеально, это нормально, но он должен идти в правильном направлении.

Я думаю, что использование поля TTL могло бы быть более элегантным и более простым решением, и для него не требуется DNS-сервер, который динамически управляет этим, что экономит ресурсы - что, на мой взгляд, является всем смыслом балансировки нагрузки DNS по сравнению с аппаратными балансировщиками нагрузки.

Мой вопрос сейчас таков: существуют ли лучшие практики / методы / правила, чтобы приблизить распределение по кругу с использованием атрибута TTL записей DNS?

Редактировать:

Система является системой прямого прокси-сервера. Количество пропускной способности (не запросов) превышает то, что может обрабатывать один сервер с Ethernet. Поэтому мне нужно решение для балансировки, которое распределяет пропускную способность по нескольким серверам. Есть ли альтернативные методы, чем использование DNS? Конечно, я могу использовать балансировщик нагрузки с оптоволоконным каналом и т. Д., Но это смешные затраты, которые также увеличивают только ширину узкого места и не устраняют ее. Единственное, о чем я могу подумать, это IP-адреса anycast (это anycast или multicast?), Но у меня нет возможности настроить такую ​​систему.

Прежде всего, я полностью согласен с @Alnitak, что DNS не предназначен для такого рода вещей, и лучшая практика заключается в том, чтобы не использовать (ab) DNS в качестве балансировщика нагрузки бедного человека.

Теперь у меня вопрос: есть ли лучшие методики / методики / практические правила для распределения по круговой схеме с использованием атрибута TTL записей DNS?

Чтобы ответить на предпосылку вопроса, подход, используемый для выполнения базисного взвешенного циклического перебора с использованием DNS, заключается в следующем:

• Настройте относительное вхождение записей в официальные ответы DNS. Т.е. если Server Aбудет иметь 1/3 трафика и Server B2/3, то 1/3 авторитетных ответов DNS на прокси-серверы DNS будут содержать только A IP-адрес, а 2/3 только BIP-адрес ответов . (Если 2 или более серверов имеют одинаковый «вес», их можно объединить в один ответ.)
• Поддерживайте низкий DNS TTL, чтобы несбалансированная нагрузка была сравнительно быстро выровнена. Поскольку нижестоящие прокси-серверы DNS имеют очень неравное количество клиентов, вам нужно часто переставлять записи.

DNS-сервис Amazon Route 53 использует этот метод .

Количество пропускной способности (не запросов) превышает то, что может обрабатывать один сервер с Ethernet. Поэтому мне нужно решение для балансировки, которое распределяет пропускную способность по нескольким серверам.

Правильно. Итак, насколько я понимаю, у вас есть своего рода «дешевая» служба загрузки / распространения видео / загрузки больших файлов, где общий битрейт службы превышает 1 Гбит.

Не зная точных особенностей вашего сервиса и структуры вашего сервера, трудно быть точным. Но общее решение в этом случае:

• Циклическая перестановка DNS для двух или более экземпляров балансировщика нагрузки на уровне TCP / IP или HTTP.
• Каждый экземпляр балансировщика нагрузки является высокодоступным (2 идентичных балансировщика нагрузки совместно работают над тем, чтобы один IP-адрес всегда был включен).
• Каждый экземпляр балансировщика нагрузки использует взвешенную циклическую обработку или обработку взвешенного случайного соединения с внутренними серверами.

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

Теперь у меня вопрос: есть ли лучшие методики / методики / практические правила для распределения по круговой схеме с использованием атрибута TTL записей DNS?

Да, лучшая практика - не делай этого !!

Пожалуйста, повторите за мной

• DNS не для балансировки нагрузки
• DNS не обеспечивает отказоустойчивость
• DNS не предоставляет средства отработки отказа

DNS для отображения имени для одного или нескольких IP - адресов . Любая последующая балансировка, которую вы получаете, происходит благодаря удаче, а не дизайну.

Посмотрите на PowerDNS . Это позволяет вам создавать пользовательский конвейер. Я изменил пример DNS-сервера балансировки нагрузки, написанного на perl, чтобы использовать модуль Algorithm :: ConsistentHash :: Ketama. Это позволяет мне устанавливать произвольные веса следующим образом:

my $ketamahe = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamahe->add_bucket("192.168.1.2", 50);
$ketamahe->add_bucket("192.168.1.25", 50);

И еще один:

# multi-colo hash
my $ketamamc = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamamc->add_bucket("192.168.1.2", 33);
$ketamamc->add_bucket("192.168.1.25", 33);
$ketamamc->add_bucket("192.168.2.2", 17);
$ketamamc->add_bucket("192.168.2.2", 17);

Я добавил cname из желаемого домена верхнего уровня в поддомен, который я называю gslb, или Global Server Balancing. Оттуда я вызываю этот пользовательский DNS-сервер и отправляю записи A в соответствии с моими желаемыми весами.

Работает как чемпион. Хэш ketama обладает приятным свойством минимального нарушения существующей конфигурации при добавлении серверов или настройке весов.

Я рекомендую прочитать Альтернативные DNS-серверы, автор Jan-Piet Mens. У него есть много хороших идей, а также пример кода.

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

Вы можете использовать PowerDNS для выполнения взвешенного циклического перебора, хотя распределение нагрузки таким несбалансированным способом (100: 1?) Может стать очень интересным, по крайней мере с алгоритмами, которые я использовал в своем решении, где каждая запись RR имеет вес, связанный с ней , между 1-100, и случайное значение используется для включения или исключения записей.

Вот статья, которую я написал об использовании бэкэнда MySQL в PowerDNS для выполнения взвешенного RR DNS: http://www.mccartney.ie/wordpress/2008/08/wrr-dns-with-powerdns/

RIPienaar также имеет несколько примеров на основе Ruby (с использованием бэкэнда канала PowerDNS): http://code.google.com/p/ruby-pdns/wiki/RecipeWeightedRoundRobin

Чтобы справиться с подобными настройками, вам нужно взглянуть на реальное решение для балансировки нагрузки. Прочитайте Linux Virtual Server и HAProxy . Вы получаете дополнительное преимущество, заключающееся в автоматическом удалении серверов из пула, если они выходят из строя, а эффекты гораздо легче понять. Взвешивание - это просто настройка, которую нужно настроить.