Да ... вроде.
Здесь вы можете сделать две вещи: если вы поместите несколько записей A на своем DNS-сервере для данного имени, то все они будут переданы клиентам, и эти клиенты выберут одну из набора для подключения, что означает, что трафик будет быть «справедливо» равномерно распределенным по всем сайтам одновременно. Это не совсем то, что вы, похоже, описываете, но это обычная ситуация (хотя я не доверяю этому по ряду причин).
Другой вариант заключается в том, что вы помещаете только одну запись A на свой DNS-сервер, а DNS-сервер (или что-то вспомогательное для него, например сценарий мониторинга) следит за основным адресом вашего сайта, и в случае сбоя A DNS-сервера A запись будет изменена на ваш другой сайт. Это означает, что только один сайт будет получать трафик одновременно.
Недостатком этой второй стратегии является кеширование 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-поддерживаемые МТС сейчас существуют. (Первый был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 . Резервный сервер получает адрес при сбое основного сервера.
источник
Да, но вы должны сделать это сами ;-)
Не могли бы вы дать больше информации о том, зачем вам нужна «резервная запись A», как и при каких обстоятельствах вы хотите перейти к резервной копии.
Кроме того, было бы полезно узнать отношение с точки зрения сети между основным и резервным хостами.
источник
Это довольно старый вопрос, но две довольно важные технологии не были затронуты в ответах: динамический DNS и CDN.
Динамический DNS настроен таким образом, чтобы записи DNS можно было изменять практически в реальном времени, чтобы клиент мониторинга мог инициировать изменения в общедоступных записях DNS A в зависимости от доступности службы. (Конечно, ваш DNS-хостинг должен поддерживать Dynamic DNS.)
CDN также могут использоваться для доставки DNS, как, например, Cloudflare (который, я полагаю, был запущен в 2010 году).
источник