Кілька центрів обробки даних та трафік HTTP: DNS Round Robin - ТІЛЬКИЙ спосіб забезпечити миттєвий збій?

Кілька записів A, що вказують на один і той же домен, здається, використовуються майже виключно для реалізації DNS Round Robin як дешевої техніки балансування навантаження.

Зазвичай попередження проти DNS RR полягає в тому, що це не добре для високої доступності. Коли 1 IP знизиться, клієнти продовжуватимуть його використовувати протягом декількох хвилин.

Балансир навантаження часто пропонується як кращий вибір.

Обидві претензії не зовсім вірні:

1. Якщо трафік становить HTTP, то більшість браузерів HTML може автоматично спробувати наступний запис A, якщо попередній знижений, без нового пошуку DNS. Прочитайте тут главу 3.1 та тут .

2. Якщо тоді задіяно кілька центрів обробки даних, DNS RR - єдиний варіант розподілу трафіку по них.

Отже, чи правда, що при безлічі центрів обробки даних та трафіку HTTP використання DNS RR є ТІЛЬКИМ способом забезпечити миттєвий збій, коли один центр обробки даних знижується?

Дякую,

Валентино

Редагувати:

• Звичайно, кожен центр обробки даних має місцевий балансир завантаження з гарячими запасами.
• Добре пожертвувати спорідненістю сеансу для миттєвого відмови.
• AFAIK є єдиним способом для DNS запропонувати центр обробки даних, а не інший - відповісти лише на IP (або IP-адреси), пов'язані з цим центром обробки даних. Якщо центр обробки даних стає недоступним, всі ці IP-адреси також недоступні. Це означає, що навіть якщо розумні веб-браузери можуть миттєво спробувати інший запис A, всі спроби закінчуються, доки не закінчиться запис локального кешу і не буде виконано нове пошуку DNS, отримавши нові робочі IP-адреси (я припускаю, що DNS автоматично пропонує новий центр обробки даних, коли один вийшов з ладу). Отже, "розумний DNS" не може забезпечити миттєвий вихід з ладу.
• І навпаки, DNS-круговик дозволяє це. Коли один центр обробки даних виходить з ладу, розумні браузери HTML (більшість із них) миттєво спробують інші кешовані записи A перейти до іншого (робочого) центру обробки даних. Так, DNS-круїн не забезпечує спорідненість сеансу або найнижчу RTT, але, здається, це єдиний спосіб забезпечити миттєвий збій, коли клієнти "розумні" браузери HTML.

Редагувати 2:

• Деякі люди пропонують TCP Anycast як остаточне рішення. У цій роботі (глава 6) пояснено, що провал Anycast пов'язаний з конвергенцією BGP. З цієї причини Anycast може зайняти від 15 хвилин до 20 секунд для завершення. 20 мереж можливі в мережах, де для цього була оптимізована топологія. Можливо, просто оператори CDN можуть надати такі швидкі збої.

Редагувати 3: *

• Я зробив кілька DNS-оглядів і traceroutes (можливо, хтось експерт може перевірити) і:
  • Єдиним CDN, що використовує TCP Anycast, здається, є CacheFly, інші оператори, такі як мережі CDN та BitGravity, використовують CacheFly. Здається, їх краї не можна використовувати як зворотні проксі. Тому їх не можна використовувати для надання миттєвої відмови.
  • Akamai та LimeLight, здається, використовують геоінформаційний DNS. Але! Вони повертають кілька записів A. З traceroutes видається, що повернені IP-адреси знаходяться в одному центрі обробки даних. Отже, я спантеличений тим, як вони можуть запропонувати 100% SLA, коли один центр обробки даних знизиться.

Коли я використовую термін "DNS Round Robin", я, як правило, маю на увазі "техніку дешевого балансування навантаження", як це описує ОП.

Але це не єдиний спосіб використання DNS для глобальної високої доступності. Здебільшого людям з різним (технологічним) досвідом просто важко спілкуватися.

Найкращою технікою балансування навантаження (якщо гроші не є проблемою), як правило, вважають:

1. Світова мережа Anycast'ed "інтелектуальних" DNS-серверів,
2. і набір глобально розповсюджених центрів обробки даних,
3. де кожен вузол DNS реалізує DNS Split Horizon DNS,
4. а також моніторинг наявності та потоків трафіку доступні "розумним" вузлам DNS певним чином,
5. щоб запит DNS користувача надходив на найближчий DNS-сервер через IP Anycast ,
6. і цей DNS-сервер роздає низько-TTL A Record / набір записів A для найближчого / найкращого центру даних для цього кінцевого користувача через "розумний" розділений DNS-горизонт.

Використовувати anycast для DNS, як правило, добре, оскільки відповіді DNS не мають статусу і майже надзвичайно короткі. Тож якщо маршрути BGP змінюються, навряд чи перервати запит DNS.

Anycast менш підходить для більш тривалих і стаціонарних HTTP-розмов, тому ця система використовує DNS з розділеним горизонтом. Сеанс HTTP між клієнтом і сервером зберігається в одному центрі обробки даних; він, як правило, не може перейти в інший центр обробки даних, не порушивши сеанс.

Як я зазначив із "набором записів A", те, що я б назвав "DNS Round Robin", можна використовувати разом із налаштуваннями, наведеними вище. Зазвичай використовується для розповсюдження навантаження на трафік на декілька високодоступних балансирів навантажень у кожному центрі обробки даних (щоб ви могли отримати кращу надмірність, використовувати менші / дешевші балансири навантажень, не перевантажувати мережеві буфери Unix одного хост-сервера тощо).

Отже, чи правда, що за допомогою декількох центрів обробки даних та трафіку HTTP використання DNS RR є ТІЛЬКИМ способом забезпечити високу доступність?

Ні, це неправда. Якщо "DNS Round Robin" ми просто маємо на увазі передачу декількох записів A для домену. Але це правда, що розумне використання DNS є важливою складовою в будь-якій глобальній системі високої доступності. Сказане ілюструє один загальний (часто найкращий) шлях.

Редагувати: Папір Google "Переміщення інформації від шляху до кінця для оптимізації продуктивності CDN" мені здається найсучаснішим у глобальному розподілі навантаження для найкращої роботи кінцевого користувача.

Редагувати 2: Я читав статтю "Чому на базі DNS .. GSLB .. не працює", з якою пов'язана ОП, і це хороший огляд - рекомендую переглянути її. Прочитайте його зверху.

У розділі "Рішення проблеми кешування браузера" він виступає за відповіді DNS з декількома записами A, що вказують на кілька центрів обробки даних як єдине можливе рішення для миттєвого відмови.

У розділі "Полив його" внизу, він розкриває очевидне, що надсилання декількох записів A є неприкосною, якщо вони вказують на центри обробки даних на кількох континентах, оскільки клієнт підключиться навмання і, таким чином, досить часто отримує "повільний" DC на іншому континенті. Таким чином, щоб це справді працювало, потрібні кілька центрів обробки даних на кожному континенті.

Це інше рішення , ніж мої кроки 1 - 6. Я не можу забезпечити ідеальний відповідь на це, я думаю , що фахівець DNS від подібних Akamai або Google необхідна, так як більша частина цього зводиться до практичних ноу-хау на обмеження розгорнутих кеш-файлів і веб-переглядачів DNS сьогодні. AFAIK, мої кроки 1-6 - це те, що робить Akamai зі своїм DNS (може хто-небудь підтвердити це?).

Моє відчуття - походить від того, що я працював прем'єр-міністром на порталах мобільних браузерів (стільникових телефонів) - полягає в тому, що різноманітність та рівень загальної розбитості браузерів там неймовірний. Особисто я б не довіряв рішенню HA, яке вимагає, щоб кінцевий користувальницький термінал "зробив правильно"; таким чином я вважаю, що глобальний миттєвий збій без порушення сеансу сьогодні неможливий.

Я вважаю, що мої кроки 1-6 вище - найкращі, що доступні з товарною технологією. Це рішення не має миттєвого відмови.

Я хотів би, щоб хтось із цих спеціалістів DNS з Akamai, Google тощо прийшов і довів мені неправильність. :-)

Ваше запитання: "Чи єдиний спосіб DNS Round Robin забезпечити миттєвий збій?"

Відповідь: "DNS Round Robin НІКОЛИ не є правильним способом забезпечити миттєвий відмову".

(принаймні, не самостійно)

Правильний спосіб досягти миттєвого відмови - використовувати маршрутизацію BGP4 таким чином, що обидва сайти використовують однакові IP-адреси. Використовуючи це, основні технології маршрутизації Інтернету використовуються для маршрутизації запитів до потрібного центру обробки даних, а не для використання основної технології Інтернет- адресації .

У найпростішій конфігурації це забезпечує лише відмову. Він також може бути використаний для надання Anycast із застереженням, що протоколи, засновані на TCP, вийдуть з ладу в момент перемикання, якщо є якась нестабільність в маршрутизації.

Отже, чи правда, що за допомогою декількох центрів обробки даних та трафіку HTTP використання DNS RR є ТІЛЬКИМ способом забезпечити високу доступність?

Зрозуміло, що це помилкова заява - вам потрібно лише подивитися на Google, Akamai, Yahoo, щоб побачити, що вони не використовують відповіді навколо [*] як єдине рішення (деякі можуть використовувати його частково разом з іншими підходами .)

Існує багато можливих варіантів, але це дійсно залежить від інших ваших обмежень, залежно від вашої послуги / програми щодо вибору.

Можливе використання методів кругового обміну на простому підході до сервера, який не розміщується, і не потрібно турбуватися про збій сервера, якщо ви також домовитесь про «невдачу» IP-адреси. (Але більшість вибирає методи збалансування навантаження, єдину IP-адресу та відмову між балансирами навантаження.)

Можливо, вам потрібні всі запити для одного сеансу, щоб перейти на одні і ті ж сервери, але ви хочете, щоб запити поширювались в різних регіональних кластерних серверах? Для цього круглий робот не підходить: вам потрібно зробити щось, що забезпечує будь-якому клієнту доступ до одного і того ж фізичного кластерного сервера щоразу (за винятком випадків, коли виникають "винятки", наприклад, помилка сервера). Або вони отримують послідовну IP-адресу з запиту DNS, або отримують маршрутизацію до того ж фізичного кластерного сервера. Рішення для цього включають різні комерційні та некомерційні DNS "балансири навантаження" або (якщо ви більше контролюєте свою мережу) рекламні мережі BGP. Ви можете просто домовитись, щоб сервери імен вашого власного домену давали абсолютно різні відповіді (але, оскільки запити DNS можуть надсилатися в усьому місці, ви виграли "

[* Я буду використовувати "круглий", тому що "RR" в термінології DNS означає "запис ресурсів".]

Дуже приємне спостереження vmiazzo +1 для вас !! Я застряг саме там, де ти .. збентежений тим, як ці CDN роблять свою магію.

Далі мої здогадки про те, як CDN запускає свою мережу:

• Використовуйте DNS Anycast (згаданий Jesper Mortensen), щоб отримати найближчий центр обробки даних
• Вони запускають локальну мережу, яка охоплює різні центри обробки даних, що дозволяє їм робити щось на зразок CARP на своїх хостах у різних центрах обробки даних

Або

• Вони використовують протокол балансування завантаження шлюзу на своїх маршрутизаторах або протокол маршрутизатора гарячого режиму очікування (HSRP) . які мають справу з відключенням центрів обробки даних.
• Причина, що вони включають кілька IP-адрес, полягає в тому, що клієнт буде повторити спробу, і до моменту, коли клієнт повторить, шлях маршрутизації міг змінитися.

На даний момент для мене працює наступне рішення: - DNS повертає декілька IP, наприклад:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy

• Остання точка входу до зворотного проксі в хмарі Amazon, який інтелектуально передається на доступний сервер (або надається на сторінці обслуговування)

Зворотний проксі все ще потрапляє, але бот такий важкий, як основний.

Чому RFC 2782 (застосовувати те саме, що і MX / пріоритет для таких служб, як http, imap, ...) не реалізований у будь-якому браузері? Все було б простіше ... Є помилка, відкрита протягом десяти років у Mozilla !!! тому що це буде кінець галузі комерційного балансиру навантаження ??? Я дуже розчарований з цього приводу.

2 - Ви можете зробити це з Anycast використанням Quagga

(Навіть якщо є якась інформація, що Anycast поганий з TCP, є кілька великих компаній, які використовують його, як CacheFly)

Цікаво, скільки людей, відповідаючи на ці запитання, насправді мають велику світову мережу серверів? Google використовує кругленьку, і моя компанія використовує його роками. Це може працювати досить добре, з деякими обмеженнями. Так, це потрібно доповнити іншими заходами.

Справжнім ключем є бажання прийняти гикавку або два, якщо сервер не працює. Коли я перетягую плагін на сервер, якщо браузер намагається отримати доступ до цього сервера, буде затримка на хвилину або близько того часу, поки браузер дізнається, що IP-адреса вниз. Але він дуже швидко переходить на інший сервер.

Це чудово працює, і люди, які стверджують, що це викликає багато проблем, не знають, про що говорять. Це просто вимагає правильного дизайну.

Відмова відсмоктує. Найкращий НА весь час використовує всі ресурси.

Я працюю з HA з 1986 року. Я пройшов обширну підготовку зі створення аварійних систем, і я взагалі не шанувальник аварійних перешкод.

Крім того, RR працює над розподілом навантаження, навіть якщо пасивно, а не активно. Наші журнали серверів чітко показують відповідний відсоток трафіку на кожному сервері - в межах причини.

Іншим дуже простим вибором є використання низького (наскільки низький залежить від ваших потреб) TTL у записі DNS A або CNAME та оновлення цього запису, щоб вибрати, який IP буде використовуватися.

У нас є 2 ISP та декілька державних служб, і ми успішно використовуємо цей метод для високої доступності вже від 3 років.

Один із ключів у роботі полягає в тому, що ряд провайдерів погано налаштовують роздільні пристрої, які кешують записи за встановлений інтервал і повністю ігнорують налаштування TTL. Це не повинно бути так, і для цього немає виправдання, але, на жаль, з мого досвіду міграції численних веб-сайтів та служб це все-таки відбувається.

TCP Anycast насправді дуже стабільний і використовується принаймні CacheFly (з 2002 року), Prolexic і BitGravity. Гарна презентація про TCP Anycast була проведена в NANOG 37: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

Кілька записів A - це єдиний спосіб усунути можливу єдину точку відмови. Будь-яке інше рішення змушує всі вхідні запити пройти через один пристрій десь між сервером і клієнтом.

Тож для абсолютної надмірності це необхідно. Ось чому Google це робить, або будь-хто інший, хто хоче бути впевнений у постійній доступності послуг.

Цілком очевидно, чому це так ... кілька записів A є єдиним способом переміщення точки, в якій запити перенаправляються до клієнтського браузера. Будь-який інший метод покладається на єдину точку між клієнтським браузером та сервером, в якій може статися збій, що знижує вашу послугу. Використовуючи записи A, єдиним єдиним пунктом відмови від клієнта до сервера стає сам клієнт.

Якщо у вас немає кількох налаштувань записів A, ви просите простою ...

Цей метод, очевидно, не може покладатися на балансування навантаження.