Зважені круглі робіни через 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 Gbps-сервери, але я хочу працювати зі 100 Mbps, а також 10 Gbps-серверами.

Тому я хочу представити сервер з 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 проти балансирів навантаження обладнання.

Зараз у мене запитання: чи є найкращі практики / методи / правила розповсюдження великого кругообігу за допомогою вагомого атрибута записів DNS?

Редагувати:

Система - система прямого проксі-сервера. Обсяг пропускної здатності (не запитів) перевищує обробку одного сервера з Ethernet. Тому мені потрібне рішення для балансування, яке розподіляє пропускну здатність на декілька серверів. Чи є альтернативні методи, ніж використання DNS? Звичайно, я можу використовувати балансир навантаження з волоконним каналом тощо, але витрати смішні, і це також збільшує лише ширину вузького місця і не усуває його. Єдине, про що я можу придумати, це IP-адреси anycast (це anycast або багатоадресна передача?) IP-адреси, але у мене немає засобів для створення такої системи.

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

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

Щоб відповісти на передумови питання, підхід, який використовується для виконання зваженого кругообігу на базісі за допомогою DNS:

• Налаштуйте відносну кількість записів у авторитетних відповідях DNS. Тобто, якщо Server Aмає бути 1/3 трафіку і Server Bмає 2/3, то 1/3 авторитетних відповідей DNS на проксі-сервери DNS міститиме лише A IP-адресу, а 2/3 відповідей лише BIP-адресу. (Якщо 2 або більше серверів мають однакову "вагу", їх можна об'єднати в одну відповідь.)
• Тримайте низький рівень TNS DNS, щоб порівняно швидко вирівняти незбалансоване навантаження. Оскільки у проксі-серверів 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);

Я додав ім'я від потрібного домену верхнього рівня до субдомену, який я називаю gslb, або глобального балансування завантаження сервером. Звідти я запускаю цей користувальницький 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 та HAProxy . Ви отримуєте додаткову вигоду від того, що сервери автоматично видаляються з пулу, якщо вони не спрацьовують, а ефекти набагато легше зрозуміти. Зважування - це просто настройка, яку слід підготувати.