Взвешенные циклические алгоритмы через TTL - возможный?
Никогда нет никакого "доказательства", что Вы владеете конкретным доменом на уровне DNS, идея состоит в том, что необходимо указать серверы имен регистраторов на серверы, которым Вы доверяете, и что серверу DNS доверяют, потому что Вы сказали, что ему можно доверять путем указания на записи DNS на него.
Как тест, у меня есть две отдельных учетных записи с DNS, Сделанным Легкий. Я взял домен из одной учетной записи и попытался добавить его к своей другой учетной записи для наблюдения то, что происходит. Инструмент управления остановил меня в моих дорожках, говоря, что домен был уже размещен в другой учетной записи.
Так, единственный способ, которым кто-то мог угнать мой DNS, должен будет создать записи для моего домена, прежде чем я сделал. Наблюдение, поскольку Вы (всегда должен) создаете свои записи DNS прежде, чем обновить Ваши серверы имен, Вы сможете сказать, пытается ли кто-то угнать Ваши записи DNS прежде, чем указать на Ваши серверы имен на сервис.
Так, в теории, если кто-то знал, Вы планировали переместить свой DNS в общий хост, и они добрались там, прежде чем Вы сделали, затем да, они могли создать записи от Вашего имени. Но затем ВЫ не смогли бы создать записи, и необходимо будет быть довольно плотными для указания на NS на поставщика DNS a) перед установкой Ваших записей DNS и b) после получения сообщения, говоря кого-то еще уже, имеет.
Во-первых, я полностью согласен с @Alnitak в том, что DNS не предназначен для такого рода вещей, и лучше всего не (ab) использовать DNS в качестве балансировщика нагрузки для бедняков.
Мой вопрос теперь ... есть ли какие-нибудь лучшие варианты / методы / практические правила для взвешивания циклического распределения с использованием атрибута TTL записей DNS?
Чтобы ответить на предпосылку вопроса, подход, используемый для выполнения базового взвешенного циклического перебора с использованием DNS, следующий: to:
- Настроить относительное вхождение записей в ответах авторитетных DNS. Т.е. если
сервер Aдолжен иметь 1/3 трафика, асервер Bдолжен иметь 2/3, тогда 1/3 авторитетных ответов DNS на DNS-прокси будет содержать только IPAи 2/3 ответов только IPB. (Если 2 или более серверов имеют одинаковый «вес», их можно объединить в один ответ.) - Сохраняйте низкий TTL DNS, чтобы несбалансированная нагрузка выровнялась относительно быстро. Поскольку нисходящие DNS-прокси имеют за собой очень неравномерное количество клиентов, вам нужно часто перетасовать записи.
Amazon DNS-сервис Route 53 использует этот метод .
Количество пропускной способности (не запросов) превышает то, что может обработать один сервер с Ethernet. Поэтому мне нужно решение для балансировки, которое распределяет полосу пропускания между несколькими серверами.
Верно. Насколько я понимаю, у вас какой-то "дешевый" загрузка / распространение видео / служба загрузки больших файлов, где общий битрейт службы превышает 1 ГБит.
Не зная точных характеристик вашей службы и схемы вашего сервера, трудно быть точным. Но общее решение в этом случае:
- Циклический перебор DNS для двух или более экземпляров балансировщика нагрузки уровня TCP / IP или HTTP.
- Каждый экземпляр балансировщика нагрузки имеет высокую доступность (2 идентичных балансировщика нагрузки
- Каждый экземпляр балансировщика нагрузки использует взвешенный циклический перебор или взвешенную обработку случайных соединений с внутренними серверами.
Такой тип настройки может быть построен с использованием программного обеспечения с открытым исходным кодом или специально -встроенная бытовая техника от многих поставщиков. Тег балансировки нагрузки здесь - отличная отправная точка,
У меня вопрос ... есть ли какие-нибудь лучшие способы / методы / практические правила для взвешивания циклического распределения с использованием атрибута TTL записей DNS?
Да, наилучшая практика - не делайте этого !!
Пожалуйста, повторяйте за мной
- DNS не предназначен для балансировки нагрузки
- DNS не обеспечивает отказоустойчивость
- DNS не предоставляет средства аварийного переключения
DNS предназначен для отображения имени на один или несколько IP-адресов . Любое последующее уравновешивание происходит благодаря удаче, а не дизайну.
Take a look at PowerDNS. It allows you to create a custom pipe backend. I've modified an example load-balancer DNS backend written in perl to use the Algorithm::ConsistentHash::Ketama module. This lets me set arbitrary weights like so:
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);
And another one:
# 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);
I've added a cname from my desired top level domain to a subdoman I call gslb, or Global Server Load Balancing. From there, I invoke this custom DNS server and send out A records according to my desired weights.
Works like a champ. The ketama hash has the nice property of minimal disruption to existing configuration as you add servers or adjust weights.
I recommend reading Alternative DNS Servers, by Jan-Piet Mens. He has many good ideas in there as well as example code.
I'd also recommend abandoning the TTL modulation. You are getting pretty far afield already and adding another kludge on top will make troubleshooting and documentation extremely difficult.
Чтобы справиться с такого рода настройками, вам нужно взглянуть на реальное решение для балансировки нагрузки. Прочтите Виртуальный сервер Linux и HAProxy . Вы получаете дополнительное преимущество, заключающееся в том, что серверы автоматически удаляются из пула в случае их сбоя, а последствия гораздо легче понять. Взвешивание - это просто параметр, который нужно изменить.
You can use PowerDNS to do weighted round robin, although distributing load in such an unbalanced fashion (100:1?) may get very interesting, at least with the algorithms I used in my solution, where each RR entry has a weight associated with it, between 1-100, and a random value is used to include or exclude records.
Here's an article I wrote on using the MySQL backend in PowerDNS to do weighted RR DNS: http://www.mccartney.ie/wordpress/2008/08/wrr-dns-with-powerdns/
R.I.Pienaar also has some Ruby based examples (using the PowerDNS pipe backend): http://code.google.com/p/ruby-pdns/wiki/RecipeWeightedRoundRobin