Чи існує спосіб, щоб протокол DNS міг природно містити резервну адресу сервера запису, як, наприклад, сервер резервного копіювання імен або записи поштового сервера? Під час пошуку цього я бачив результати лише на резервних серверах імен (NS записи).
Якщо DNS не може підтримувати резервні копії записів A, який найкращий спосіб імітувати результати, щоб користувачі були спрямовані на робочий сервер у випадку, якщо основний сервер не відповідає?
Відповіді:
Так ... начебто.
Тут ви можете зробити дві речі: Якщо ви помістите кілька записів A на свій DNS-сервер на вказане ім’я, вони будуть надані клієнтам, і ці клієнти виберуть одну із набору для підключення, тобто трафік буде бути "досить" рівномірно розподіленим між усіма сайтами одночасно. Ви насправді це не так, як ви, начебто, описуєте, але це звичайна ситуація (хоча я не довіряю цьому з різних причин).
Інший варіант полягає в тому, що ви розміщуєте лише один запис A на своєму DNS-сервері, і DNS-сервер (або щось допоміжне до нього, як сценарій моніторингу) слідкує за основною адресою вашого веб-сайту, а якщо він не працює, то A сервера DNS запис змінюється на ваш інший сайт. Це означає, що лише один сайт буде отримувати трафік одночасно.
Недоліком цієї другої стратегії є кешування DNS. Кожен, хто отримав стару адресу сайту, буде SOL, поки не буде очищено записи кешу DNS, що містять стару адресу. Це означає, що ви повинні тримати низький рівень TTL (збільшуючи навантаження на вашу DNS-інфраструктуру, хоча це рідко є практичною проблемою), але все ще існує проблема "шахрайських" кешів DNS, які не шанують TTL. Це масовий біль для будь-кого кому коли-небудь доводиться змінювати записи DNS, але вони в мільйон разів гірші для тих, кому потрібно змінювати записи DNS "часто" (сподіваємось, ваш сайт не знижується кілька разів на день, але все-таки ...) за одним із цих кеш-пам'яті DNS керує вашим сайтом як "вниз" протягом надзвичайно тривалого періоду часу, і просто спробуйте пояснити їм, що в цьому винен їх кеш DNS ... Еге.
Коротше кажучи, я б не робив це для сайту, оскільки є кращі способи зменшити будь-який ризик, про який ви думаєте, але вам потрібно буде описати цей ризик, якщо ви хочете запропонувати, як зменшити його.
Здається, всі думають, що ви говорите про сервери WWW, навіть якщо ви прямо писали
Найчастіше ігнорована істина полягає в тому, що сервіс HTTP є винятком, а не нормою, коли йдеться про це. У звичайному випадку, так, це механізм для публікації інформації клієнтів через DNS , щоб вони правильно запасний варіант з первинних серверів на резервні сервера. Цей механізм - цеяк резервний сервер імен або поштовий сервер
SRVресурси записів, які використовуються клієнтами сервісу для багатьох інших протоколів, крім HTTP. Див. RFC 2782.
Записуючи SRVресурси, клієнтам повідомляється список серверів, з пріоритетами та вагою, і вони зобов'язані пробувати сервери в порядку черговості, вибираючи серед серверів з рівними пріоритетами відповідно до ваги, вибираючи більш зважені сервери частіше, ніж нижчі ті. Тож із SRVзаписами ресурсів адміністратори серверів можуть повідомити клієнтам, що таке резервні сервери та як розподілити їх навантаження на набір серверів з рівним пріоритетом.
Тепер контент DNS-серверів розміщений за допомогою спеціального типу власних NSзаписів ресурсів, записів ресурсів, які не мають інформації про пріоритет та вагу. Так само SMTP-реле-сервери розташовані за власним спеціальним типом запису ресурсів MX, який має пріоритетну інформацію, але не має вагової інформації. Таким чином, для DNS-серверів контенту не передбачено публікації інформації про резервне завантаження та завантаження; і якщо ви використовуєте MXзаписи ресурсів, то для серверів SMTP-реле не передбачено публікувати інформацію про розподіл навантаження.
Однак, SRVзараз можливі MTS. (Перший був exim, який може бути SRVз 2005 року.) А для інших протоколів обслуговування, не обтяжених багажем MXта NSресурсами, SRVприйняття є набагато більш ретельним та поширеним. Наприклад, якщо у вас є домен Microsoft Windows, то цілий ряд служб знаходиться через SRVпошук у DNS . Так було вже не одне десятиліття.
Проблема полягає в тому, що всі думають про HTTP, коли HTTP вже на сьогоднішній день є в 2011 році, виняток, а не правило тут.
SRVзаписи - це визначений спосіб пошуку послуг. Також зауважте, що питання полягало у тому, чи існує механізм та який він був. Механізм існує, і це механізм. Він широко застосовується протягом десятиліття.
якщо ви обслуговуєте динамічний контент, і це не практично просто мати два сервери, що надають вміст одночасно, то ваш інший варіант - це все одно мати кілька записів на вашому DNS і налаштувати сервер резервного копіювання, щоб передати ICMP-порт недоступним для клієнтів, які намагаються підключитися до нього. ; якщо в будь-який момент основний сервер вийде з ладу, ви просто видаліть блок 80 порта з резервної копії і трафік почне надходити.
Єдиний інший (бюджетний) спосіб, який ви зможете це зробити, - це встановити окрему машину (або дві) для виконання NAT на запити, таким чином, якщо веб-сервер помре, ви можете просто видалити для нього правило NAT.
Немає резервних записів A, але може бути кілька записів A, які видаються у випадковому порядку.
Більшість браузерів, які можуть спробувати інший сервер, якщо один не вдався. (Див.: Веб-стійкість із Round Robin DNS )
У вас може бути одна IP-адреса кластера, підкріплена кількома серверами з VRRP або CARP . Сервер резервного копіювання приймає адресу, коли основний сервер не працює.
Це досить давнє запитання, але у відповідях не було вироблено двох досить значущих технологій: Динамічні DNS та CDN.
Динамічний DNS налаштований так, що записи DNS можна змінювати майже в реальному часі, тому клієнт моніторингу може викликати зміни в загальнодоступних записах DNS A, як диктує доступність служби. (Звичайно, служба хостингу DNS повинна підтримувати динамічний DNS.)
CDN також можна використовувати для доставки DNS, як, наприклад, Cloudflare (який я вважаю, запущений у 2010 році).