Правильний спосіб налаштування первинного / вторинного DNS /… для зменшення надмірності та затримки?

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

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

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

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

Які аргументи я можу використати, щоб творити дірки в міркуваннях наших сисадмінів? Будь-які інтернет-ресурси, з якими я можу проконсультуватися, щоб краще зрозуміти проблеми, які вони стверджують, існують?

Деякі додаткові замітки після прочитання відповідей:

• ми в Linux
• у нас є додаткові складні потреби DNS; нашими записами DNS керується деяким користувальницьким програмним забезпеченням, BIND наразі працює з Twisted-реалізацією DNS, а також деякими переглядами в поєднанні. Однак ми цілком здатні налаштувати власні сервери DNS в іншому центрі обробки даних.
• Я говорю про авторитетний DNS для сторонніх людей, щоб знайти наші сервери, а не рекурсивні DNS-сервери для наших місцевих клієнтів.

Існує дійсно чудовий, хоч і досить технічний документ "Кращі практики", який може виявитися корисним при боротьбі з вашим систематичним адміністратором. http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

Якщо він / вона не визнає дійсності статей, написаних Cisco, то ви можете також перестати сперечатися з sysadmin - підніміться на рівень управління.

У багатьох інших документах "Найкращі практики" рекомендується розділяти ваші первинні та вторинні сервери імен не тільки за блоком IP, але і за фізичним розташуванням. Фактично, RFC 2182 рекомендує, щоб вторинні служби DNS були географічно розділені. Для багатьох компаній це означає орендувати сервер в іншому центрі обробки даних або підписатися на розміщеного DNS-провайдера, такого як ZoneEdit або UltraDNS .

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

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

Особисто я переконаний, що ми не єдина компанія з таким видом проблеми, і це, швидше за все, вже вирішена проблема. Я не можу собі уявити, щоб усі ці інтернет-компанії зазнали нашої проблеми.

Ви не єдина компанія, і це, ймовірно, мільйон разів перероблялося в компаніях у всьому світі.

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

Які аргументи я можу використати, щоб творити дірки в міркуваннях наших сисадмінів? Будь-які інтернет-ресурси, з якими я можу проконсультуватися, щоб краще зрозуміти проблеми, які вони стверджують, існують?

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

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

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

Причини, що це неправильно робити:

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

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

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

Я хотів вирішити це, оскільки наш сервер імен Amazon EC2, який вирішує проблеми, недоступний для багатьох наших працівників. Це спричиняє великі затримки наших процесів і навіть простої в деяких випадках, оскільки ми покладаємося на рішення. Я хотів гарного відмови від серверів імен Google / Level3 у випадку, якщо Amazon знову знизиться. І відкиньтесь якнайшвидше, оскільки тоді Amazon буде вирішувати імена хостів за локальними адресами, де це можливо, вирішуючи з нижчою затримкою, наприклад, для інстанції зв'язку.

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

Я вирішив використовувати crontab & bash, і написав nsfailover.sh . Сподіваюсь, це допомагає.

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

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

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

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

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

Наша установка:

• 2 фізичні центри обробки даних (окремі схеми, Інтернет-провайдери та постачальники продуктів вище)
• 2 фізичні сервери запитів у кластері позаду SLB на кожному об'єкті
• 2 пристрої для балансування навантаження для обслуговування конкретних записів, якими ми хочемо керувати балансом між двома даними даних
• прихований майстер, доступний для внутрішніх обох кластерних серверів (я дуже вірю в приховані налаштування майстра для безпеки)

Ця налаштування була достатньо ефективною, щоб дати нам приблизно 5 9 років безперебійного користування протягом останніх 6 або 7 років, навіть із випадковим простоєм сервера на оновлення тощо. Якщо ви готові витратити кілька додаткових доларів, ви можете подивитися на аутсорсинг хостинг зони з кимось, як ультраднів ...

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

Я беру максимальне навантаження від усіх моїх крайових маршрутизаторів, додаю їх усі разом, а потім ділю на 0,65 ... це мінімальна пропускна здатність, яку ми повинні мати у кожному центрі обробки даних. Я встановив це правило близько 5 років тому, з деякими документами, які його виправдовували, я зібрав з ЦРУ та з Інтернету, і воно ніколи нас не підводило. Однак ви повинні перевірити ці статистичні дані принаймні щоквартально. Ми мали листопад-лютий минулого року зростання трафіку майже в 3 рази, і я до цього не був готовий. Ця яскрава сторона полягає в тому, що ситуація дозволила мені генерувати дуже чіткі жорсткі дані, які говорять, що при 72% завантаженні нашої схеми WAN ми починаємо скидати пакети. Жодного додаткового обгрунтування від мене ніколи не вимагалося для більшої пропускної здатності.

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

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

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

Якщо ваш основний центр обробки даних знижений, ніхто не зможе дістатися до цих серверів у будь-якому разі, але часто помилки з цього зрозуміліші, ніж помилки недоступних серверів DNS. "Не вдалося зв’язатися з сервером" або "Вимкнено час з'єднання" замість "Не вдалося знайти сервер" або "Немає такого сервера". Наприклад, більшість серверів SMTP чергуватимуть пошту протягом тижня, якщо вони бачать сервер у DNS, але просто не можуть його отримати; якщо вони взагалі не можуть знайти його в DNS, вони можуть негайно відмовитися навіть намагатися доставити його до вашого домену.

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

Томасе,

Прочитавши ваше оновлення, я переглянув свою публікацію (попередня публікація посилалася на програмне забезпечення Windows).

Мені це майже звучить так, як ваші sysadmin (s) говорять вам про те, що у вашому вторинному розташуванні немає необхідного обладнання для роботи з ПОВНИМ НАВ'ЯЗОМ?

Це звучить так, ніби він говорить: "Ей, приятель, якщо наше основне місце розташування (яке включає первинний DNS) знижується, DNS - НАЙКРАЩЕ з наших турбот, тому що якщо COLO1 знижений, COLO2 ніяк не може впоратися з навантаженням".

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

Все це в стороні, в ідеальному світі, COLO1 і COLO2 змогли б стояти окремо і впоратися з вашим вантажем.

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

Я використовував цей метод у невеликих та розумних розмірах, і він чудово працює. Перехід на помилку зазвичай займає менше 10 хвилин.

Вам просто потрібно переконатися, що ваші DNS-сервери можуть справлятися із додатковим навантаженням за короткий TTL (час жити).

Сподіваюсь, це допомагає.

Ваші сисадміни (в основному) помиляються.

Рекурсивні сервери, які запитують ваші авторитетні сервери, помітять дуже швидко, якщо будь-який сайт не відповідає.

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

У разі необхідності (щоб заспокоїти системні адміністратори) продовжуйте запускати два сервери у вашому первинному центрі обробки даних, але поставте принаймні ще один зовні.

Вторинний dns-сервер ніколи не шкодить, залежно від місця його розміщення він надасть вам більш-менш функціональні можливості.

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

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

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