Есть ли способ, которым протокол DNS может естественным образом хранить резервный адрес сервера записи A, например, резервный сервер имен или записи почтового сервера? При поиске этого я видел результаты только на резервных серверах имен (записи NS).
Если DNS не поддерживает резервные записи A, как лучше всего имитировать результаты, чтобы пользователи перенаправлялись на рабочий сервер, если основной сервер не отвечает?
Да ... вроде того.
Здесь вы можете сделать две вещи: если вы поместите несколько записей A на свой DNS-сервер для заданного имени, тогда все они будут обслуживаться клиентам, и эти клиенты выберут одну из набора для подключения, что означает, что трафик будет быть "справедливо" равномерно распределенными по всем сайтам одновременно. Это не совсем то, что вы, кажется, описываете, но это обычная ситуация (хотя я ей не доверяю по разным причинам).
Другой вариант заключается в том, что вы помещаете только одну запись A на свой DNS-сервер, а DNS-сервер (или что-то связанное с ним, например, сценарий мониторинга) следит за основным адресом вашего сайта, и если он не работает, то DNS-сервер A запись будет изменена на другой ваш сайт. Это означает, что только один сайт будет получать трафик одновременно.
Обратной стороной этой второй стратегии является кеширование DNS. Любой, кто получил старый адрес сайта, будет иметь статус SOL, пока его записи кэша DNS, содержащие старый адрес, не будут удалены. Это означает, что вам нужно поддерживать низкие TTL (увеличивая нагрузку на вашу DNS-инфраструктуру, хотя это редко бывает практической проблемой), но все еще существует проблема «мошеннических» DNS-кешей, которые не соблюдают TTL. Это огромная боль для кто угодно кому когда-либо приходилось менять записи DNS, но они в миллион раз хуже для тех, кому нужно менять записи DNS «часто» (надеюсь, ваш сайт не отключается несколько раз в день, но все же ...) В принципе, любой за одним из этих некорректных DNS-кешей увидит, что ваш сайт "не работает" в течение очень длительного периода времени, и просто попытайтесь объяснить им, что это их DNS-кеш, виноват ... Эх.
Короче говоря, я бы не стал делать этого для сайта, потому что есть более эффективные способы уменьшить любой риск, о котором вы думаете, но вам нужно описать этот риск, если вам нужны предложения о том, как его уменьшить.
Кажется, все думают, что вы говорите о серверах WWW, хотя вы явно написали
The oft-overlooked truth is that HTTP service это исключение and not the norm when it comes to this. In the normal case, yes, there является a mechanism for publishing information to clients via the DNS so that they properly fallback from primary servers to backup servers. Этот механизмкак резервный сервер имен или почтовый сервер
SRV записи ресурсов, используемые сервисными клиентами для многих других протоколов Помимо HTTP. See RFC 2782. С участием SRV записи ресурсов, клиентам сообщается список серверов с приоритетами и весами, и они должны опробовать серверы в порядке приоритета, выбирая среди серверов с равными приоритетами в соответствии с весом, выбирая серверы с более высоким весом чаще, чем серверы с меньшим весом . Так что с SRV записей ресурсов, администраторы серверов могут сообщать клиентам, что такое резервные серверы и как распределять их нагрузку по набору серверов с равным приоритетом.
Теперь DNS-серверы контента располагаются с помощью специального типа собственной записи ресурса, NS записи ресурсов, которые не имеют информации о приоритете и весе. Точно так же серверы ретрансляции SMTP располагаются по своему собственному особому типу записи ресурса, MX, который имеет информацию о приоритете, но не имеет весовой информации. Таким образом, для контентных DNS-серверов нет возможности публиковать информацию об откате и распределении нагрузки; и если вы используете MX записи ресурсов, то для серверов ретрансляции SMTP не предусмотрено публикации информации о распределении нагрузки.
Тем не мение, SRV-мощные МТС сейчас существуют. (Первый был exim, который был SRV-возможен с 2005г.) И для Другой служебные протоколы, не обремененные багажом MX и NS записи ресурсов, SRV принятие гораздо более основательно и широко. Если у вас, например, домен Microsoft Windows, то целый ряд услуг расположен через SRV поиск в DNS. На данный момент так было уже более десяти лет.
Проблема в том, что все думают о HTTP, тогда как HTTP в настоящее время в 2011 году является здесь исключением, а не правилом.
если вы обслуживаете динамический контент и нецелесообразно просто иметь два сервера, предоставляющих контент одновременно, то другой вариант - в любом случае иметь несколько записей в вашем DNS и настроить сервер резервного копирования так, чтобы порт ICMP был недоступен для клиентов, которые пытаются подключиться к нему ; если в какой-то момент основной сервер выйдет из строя, вы просто удалите блок порта 80 на резервной копии, и трафик начнет поступать.
Единственный другой (бюджетный) способ, которым вы сможете это сделать, - это настроить отдельный компьютер (или два) для выполнения NAT по запросам, поэтому, если веб-сервер умирает, вы можете просто удалить для него правило NAT.
Резервных A-записей нет, но может быть несколько A-записей, которые выдаются в случайном порядке.
Большинство браузеров могут попробовать другой сервер в случае сбоя одного из них. (Видеть: Веб-устойчивость с циклическим перебором DNS)
У вас может быть один IP-адрес кластера, поддерживаемый несколькими серверами с VRRP или Карп. Резервный сервер принимает адрес в случае отказа основного сервера.
Да, но вы должны это сделать сами ;-)
Не могли бы вы предоставить дополнительную информацию о том, почему вам нужна «резервная копия A-записи» и как и при каких обстоятельствах вы хотите перейти к резервной копии.
Кроме того, было бы полезно знать отношения с точки зрения сети между основным и резервным хостами.
Это довольно старый вопрос, но в ответах не упоминались две довольно важные технологии: динамический DNS и CDN.
Динамический DNS настроен таким образом, что записи DNS могут быть изменены практически в реальном времени, поэтому клиент мониторинга может инициировать изменения в общедоступных записях DNS A в соответствии с требованиями доступности службы. (Конечно, ваша служба хостинга DNS должна поддерживать динамический DNS.)
CDN также можно использовать для доставки DNS, как, например, Cloudflare (который, я полагаю, был запущен в 2010 году).