Чому відключення DNS не рекомендується?

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

Мені здається, що аварійний перехід на DNS - це єдиний варіант відмови, але консенсус - це не гарний варіант. Але такі сервіси, як DNSmadeeasy.com, надають це, тому в цьому повинні бути заслуги. Будь-які коментарі?

Під «DNS-відмовою» я вважаю, що ви маєте на увазі DNS Round Robin у поєднанні з деяким моніторингом, тобто публікацією декількох IP-адрес для імені хоста DNS та видаленням мертвої адреси, коли моніторинг виявляє, що сервер не працює. Це може бути корисним для невеликих веб-сайтів, з якими не торгують.

Коли ви відповідаєте на запит DNS, ви також надаєте час жити (TTL) для відповіді, яку ви передаєте. Іншими словами, ви говорите іншим DNS-серверам і кешуєте, "ви можете зберігати цю відповідь і використовувати її протягом х хвилин, перш ніж перевірити мене". Недоліки випливають із цього:

• У разі відмови від DNS невідомий відсоток ваших користувачів буде зберігати кешовані дані DNS із різною кількістю TTL. Поки термін дії TTL не закінчиться, вони можуть підключитися до мертвого сервера. Існують більш швидкі способи завершити провал, ніж цей.
• Через вищезазначене ви схильні встановлювати рівень TTL досить низьким, скажімо, 5-10 хвилин. Але встановлення його вище дає (дуже малу) перевагу від продуктивності, і може допомогти вашому розповсюдженню DNS надійно працювати, навіть якщо у мережевому трафіку короткий збій. Тому використання відмови на основі DNS суперечить високим TTL, але високі TTL є частиною DNS і можуть бути корисними.

Більш розповсюджені методи покращення тривалості роботи включають:

• Розміщення серверів разом в одній локальній мережі.
• Розмістіть локальну мережу в центрі обробки даних з високодоступними площинами живлення та мережі.
• Використовуйте балансир завантаження HTTP, щоб розповсюджувати навантаження та виходити з ладу на окремих відмов сервера.
• Отримайте необхідний рівень надмірності / очікуваного часу роботи, необхідного для брандмауерів, балансирів навантаження та комутаторів.
• Створити стратегію комунікації для збоїв у центрі даних та випадкових збоїв на комутаторі / сервері баз даних / інших ресурсах, які неможливо легко відобразити.

Дуже невелика частина веб-сайтів використовує налаштування багатоцентрових центрів даних із "геобалансуванням" між центрами обробки даних.

Відмова від DNS, безумовно, чудово працює. Я використовую його вже багато років для ручного переміщення трафіку між центрами обробки даних або автоматично, коли системи моніторингу виявляють відключення, проблеми з підключенням або перевантажені сервери. Коли ви побачите швидкість, з якою вона працює, та обсяги реального світового трафіку, які можна зрушити з легкістю - ви ніколи не озирніться назад. Я використовую Zabbix для моніторингу всіх моїх систем, а візуальні графіки, які показують, що відбувається під час аварійної ситуації в DNS, поклали всі мої сумніви в кінець. Можливо, є кілька провайдерів, які ігнорують TTL, і деякі користувачі все ще там зі старими веб-переглядачами - але коли ви переглядаєте трафік із мільйонів переглядів сторінок на день у двох місцях центру обробки даних і ви змінюєте DNS-трафік, залишковий трафік, що надходить в ігнорує TTL, є смішним.

DNS не розрахований на відмову, але він був розроблений з TTL, які дивовижно працюють на аварійні потреби в поєднанні з надійною системою моніторингу. TTL можна встановити дуже коротко. Я ефективно використовував TTL протягом 5 секунд у виробництві для полегшення швидких рішень на основі відключення DNS. Ви повинні мати сервери DNS, здатні обробляти додаткове навантаження - і названі не будуть його скорочувати. Однак powerdns підходить до рахунку, коли підкріплюється реплікаційними базами даних mysql на надмірних серверах імен. Вам також потрібна міцна розподілена система моніторингу, якій ви можете довіряти для автоматизованої інтеграції в аварійному режимі. Zabbix працює для мене - я можу перевірити відключення з декількох розподілених систем Zabbix майже миттєво - оновлювати записи mysql, які використовуються powerdns, на ходу - і забезпечити майже миттєвий відмову під час відключень та спадів трафіку.

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

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

На жаль, це майже єдиний варіант, якщо ви не є достатньо великим, щоб зробити власну (зовнішню) маршрутизацію.

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

У будь-якому випадку,

http://crypto.stanford.edu/dns/dns-rebinding.pdf пояснює, що це неправда для більшості поточних браузерів HTML. Вони спробують наступний IP через секунди.

http://www.tenereillo.com/GSLBPageOfShame.htm здається ще сильнішим:

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

Можливо, якийсь експерт може прокоментувати і дати більш чітке пояснення, чому DNS RR не підходить для високої доступності.

Дякую,

Валентино

PS: вибачте за розірване посилання, але, як новий користувач, я не можу розмістити більше 1

Я багато років працював над відмовою від DNS RR на веб-сайті з помірною торгівлею, але критично важливим для бізнесу (у двох географіях).

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

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

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

2) Якщо хтось із ваших серверів імен (або одна з двох ваших географій повністю) знизиться, яка обслуговує ваш домен з круглим роботом, і якщо основний з них знизиться, я неясно нагадую, що ви можете зіткнутися з іншими проблемами, намагаючись усунути це скинутий сервер імен з DNS, якщо ви також не встановили для вашого сервера імен SOA TTL / термін дії достатньо низького значення. У мене можуть бути помилкові технічні деталі, але існує не одне налаштування TTL, яке потрібно отримати, щоб справді захищатись від одиничних пунктів відмови.

3) Якщо ви публікуєте веб-API, послуги REST тощо, браузери, як правило, не дзвонять, і, на мій погляд, помилка DNS починає виявляти реальні недоліки. Це може бути причиною того, що деякі кажуть, як ви говорите "це не рекомендується". Ось чому я це кажу. По-перше, програми, які споживають ці URL-адреси, як правило, не є браузерами, тому їм не вистачає 30-секундних властивостей відхилення / логіки звичайних браузерів. По-друге, те, чи буде викликаний другий запис DNS або навіть повторно опитується DNS, дуже залежить від деталі програмування низькорівневих бібліотек на мовах програмування, якими користуються ці клієнти API / REST, а також, як саме вони називаються клієнтське додаток API / REST (Під кришками, чи викликає бібліотека get_addr, і коли? Якщо сокети висять чи закриваються, додаток повторно відкриває нові сокети? Чи є якась логіка тайм-ауту? Тощо тощо)

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

Є купа людей, які використовують нас (Dyn) для відмови. З тієї ж причини сайти можуть або робити сторінку статусу, коли вони мають час простою (придумайте такі речі, як Fail Whale Twitter) ... або просто просто перенаправити трафік на основі TTL. Деякі люди можуть подумати, що DNS Failover - це гетто ... але ми серйозно розробили нашу мережу з відмовою від самого початку ... так, щоб вона працювала так само, як і апаратне забезпечення. Я не впевнений, як це робить DME, але у нас 3 з 17 наших найближчих спостережуваних PoP відстежують ваш сервер з найближчого місця. Коли він виявить з двох з трьох, що він знижений, ми просто перенаправляємо трафік на інший IP. Єдиний час простою - це для тих, хто був на той момент, який запитували протягом останнього інтервалу TTL.

Деякі люди хочуть використовувати обидва сервери одночасно ... і в цьому випадку можуть зробити щось на кшталт балансування навантаження круглим роботом ... або врівноваження навантаження на основі гео. Для тих, хто насправді дбає про продуктивність ... наш менеджер трафіку в режимі реального часу буде контролювати кожен сервер ... а якщо він повільніше ... перенаправляє трафік на найшвидший на основі того, які IP-адреси ви посилаєте у своїх іменах хостів. Знову ж таки ... це працює на основі значень, які ви встановили на нашому інтерфейсі / API / порталі.

Я думаю, моя думка полягає в тому, що ... ми спеціально спроектували dns failover. У той час як DNS не був створений для відмови, коли він був створений спочатку ... наша DNS-мережа була розроблена для того, щоб реалізовувати його з початку роботи. Зазвичай це може бути так само ефективно, як і апаратне забезпечення ... без амортизації або вартості обладнання. Сподіваюся, що це не викликає кульгавості для підключення Dyn ... Є багато інших компаній, які роблять це ... Я просто кажу з точки зору нашої команди. Сподіваюся, це допомагає ...

Іншим варіантом було б встановити сервер 1 імен у місці розташування A та сервері імен 2 у розташуванні B, але встановити кожен з них так, щоб усі записи A на трафіку точки NS1 до IP-адрес для місцезнаходження A, а в NS2 всі записи A вказували на IP місце розташування B. Потім встановіть свої TTL на дуже низьке число та переконайтесь, що запис домену в реєстраторі налаштовано для NS1 та NS2. Таким чином, він автоматично завантажить баланс, і не вдасться перейти, якщо один сервер або одне посилання на місце розташування зійдуть.

Я використовував цей підхід дещо по-іншому. У мене є одна локація з двома провайдерами, і я використовую цей метод для спрямування трафіку по кожному посиланню. Тепер це може бути трохи більше обслуговування, ніж ви готові зробити ... але мені вдалося створити просту програму, яка автоматично витягує записи NS1, оновлює записи IP-адрес для вибраних зон і підштовхує ці зони до NS2.

Альтернативою є система відмови на базі BGP. Налаштувати це не просто, але це має бути кулезахисним. Налаштуйте сайт A в одному місці, сайт B - вдруге, все з локальними IP-адресами, потім отримайте клас C або інший блок ip, які є портативними, і налаштуйте перенаправлення з портативних IP-адрес на локальні IP-адреси.

Є підводні камені, але це краще, ніж рішення, засновані на DNS, якщо вам потрібен такий рівень контролю.

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

Це повністю обходить проблему відмови DNS, підтримуючи лише кілька доменних імен. Користувачі, які переходять на www.company.com або company.com та входять у систему, спрямовуються на сервер1.company.com або server2.company.com та мають вибір закладки будь-якого з тих, якщо вони помічають, що вони отримують кращу ефективність за допомогою одного чи іншого. . Якщо один знижується, користувачі навчаються переходити на інший сервер.

Я використовую балансування сайтів на базі DNS і виправлення неполадок протягом останніх десяти років, і є деякі проблеми, але їх можна усунути. BGP, хоча перевага в чомусь не є 100% рішенням або зі збільшенням складності, ймовірно, додатковими витратами на обладнання, часом конвергенції тощо ...

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

Усі ці відповіді мають певну валідність для них, але я думаю, що це дійсно залежить від того, що ви робите, і який ваш бюджет. Тут у CloudfloorDNS великий відсоток нашого бізнесу - це DNS, який пропонує не тільки швидкий DNS, але й низькі варіанти TTL та відмову від DNS. Ми б не займалися бізнесом, якби це не працювало і працювало добре.

Якщо ви багатонаціональна корпорація з необмеженим бюджетом на час роботи, так, апаратні балансири навантаження GSLB та центри даних першого рівня чудові, але ваш DNS все-таки повинен бути швидким і міцним. Як багато хто з вас знає, DNS є важливим аспектом будь-якої інфраструктури, крім самого доменного імені, це сервіс найнижчого рівня, на якому їде кожна інша частина вашої присутності в Інтернеті. Починаючи з надійного реєстратора домену, DNS настільки ж критичний, як не дозволяти вашому домену закінчитися. DNS знижується, це означає, що весь Інтернет-аспект вашої організації також знижений!

Під час використання відключення DNS іншими важливими аспектами є моніторинг сервера (завжди декілька географічних місць для перевірки та завжди декілька (щонайменше 3) має бути перевірка, щоб уникнути помилкових позитивних результатів) та правильне управління записами DNS належним чином виявлено помилку. Низький рівень TTL та деякі варіанти з відмовою можуть зробити це безпроблемним процесом, і, якщо ви сис-адміністратор, вибиваєтесь із прокидання до пейджера посеред ночі.

Загалом, DNS Failover дійсно працює і може бути дуже доступним. У більшості випадків від нас або більшості керованих постачальників DNS ви отримуватимете Anycast DNS разом із моніторингом сервера та відмовою за частину вартості апаратних можливостей.

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

"і чому ви ризикуєте використовувати його для більшості виробничих середовищ (хоча це краще, ніж нічого)."

Насправді "краще, ніж нічого" краще виражається як "єдиний варіант", коли присутні географічно різноманітні. Апаратні балансири навантажень чудово підходять для однієї точки присутності, але одна точка присутності також є однією точкою відмови.

Є безліч сайтів з великим доларом, які використовують маніпуляції з трафіком на основі dns для хорошого ефекту. Вони є типом сайтів, які щогодини знають, чи продажі вимкнені. Здавалося б, вони останніми займаються тим, що "ризикувати, використовуючи його для більшості виробничих середовищ". Дійсно, вони уважно переглянули свої варіанти, відібрали технологію та добре сплатили її. Якби вони подумали, що щось краще, вони залишили б серце. Те, що вони все ще вирішили залишитися, говорить про використання реального світу.

Відмова на основі Днс страждає від певної кількості затримок. Не обійтися. Але це все ще єдиний життєздатний підхід до управління відмовою в багатопопулярному сценарії. Як єдиний варіант, це набагато більше, ніж «краще, ніж нічого».

Сьогодні хороші глобальні балансири навантаження, які працюють з використанням цієї техніки і працюють досить добре. Перевірте, наприклад, Azure Traffic Manager https://azure.microsoft.com/en-us/services/traffic-manager/

Якщо ви хочете дізнатися більше, прочитайте примітки до програми за адресою

http://edgedirector.com

Вони охоплюють: відмову, глобальне збалансування навантаження та безліч пов'язаних питань.

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

Коротка відповідь: це працює, але ви повинні розуміти обмеження.

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

Я рекомендую вам або A, обрати центр обробки даних, який має багатосмуговий власний AS, або B, розміщувати ваші сервери імен у загальнодоступній хмарі. Насправді навряд чи EC2, або HP, або IBM знизяться. Просто думка. Хоча DNS працює як виправлення, у цьому випадку це просто просто виправлення поганого дизайну в мережевій основі.

Інший варіант, залежно від вашого оточення, - використовувати комбінацію з IPSLA, PBR та FHRP для досягнення ваших потреб у надмірності.