Одно доменное имя для двух серверов.

11.11.11.11

Никто тебе не даст такой красивый айпи.

22.22.22.22

И такой тоже.

Просто создать две «A» записи с одним доменным именем, вызовет конфликт

Кто тебя так обманул? Никаких конфликтов не будет.

Скажем если по основному ip 11.11.11.11 сайт не доступен, то запрос перенаправлялся на резервный ip 22.22.22.22. Но если ip 11.11.11.11 вновь стал доступным, то все запросы отправлялись исключительно на него!

Меняй записи в днс в зависимости от доступности айпи-адресов. И поставь им маленькое TTL чтобы изменения быстрее доходили до клиентов. Других способов нет.

Если пропишешь две A записи то клиенты поровну рандомно распределятся между ними, приоритеты там не предусмотрены.

Просто создать две «A» записи с одним доменным именем, вызовет конфликт

$ dig google.com a
google.com.		300	IN	A	142.250.150.102
google.com.		300	IN	A	142.250.150.113
google.com.		300	IN	A	142.250.150.138
google.com.		300	IN	A	142.250.150.101
google.com.		300	IN	A	142.250.150.139
google.com.		300	IN	A	142.250.150.100

Просто создать две «A» записи с одним доменным именем, вызовет конфликт.

нет. Так и делают, используют dns round robin. Только оно не равномерно распределяется.

dns round robin

Именно так

Только оно не равномерно распределяется.

не везде и не у всех работает. Так скорее правильнее будет.

От резолвера зависит, ага.

Кроме того, используй CNAME. Этот чит позволяет игнорировать ttl. Просто перебиваешь CNAME на другую запись и оно сразу выдаёт новый.

То есть тот из двух сайтов, который ещё живой, он может переписать CNAME прямо в рантайме и всё сразу на него пойдёт?

Когда прописывают в DNS два ip-адреса — это подразумевает, что оба эти адреса всё время доступны.

Базово не гарантируется, что браузер получит оба ip-адреса, и в случае чего попробует подключится по второму адресу. Если вы пропишите в DNS два ip, но один будет недоступен, у части клиентов сайт будет доступен.

Как уже написали, для резервирования только правка DNS и низкий TTL.

Да. Даёшь в зоне A записи на именные уникальные имена и потом испльзуешь CNAME как указатель. Полагаю, оба метода можно совмещать.

Откуда инфа? Почему гугл про свои dns пишет такое:

Если Google Public DNS возвращает ответы с устаревшими записями CNAME, вам необходимо очистить тип записи CNAME для каждого домена CNAME, начиная с последнего CNAME в цепочке и возвращаясь к запрошенному имени. После того, как вы сбросите все CNAME, сбросьте запрошенные имена со всеми типами записей, которые отвечают устаревшим CNAME.

Сорян, я доку не читал, я просто оттестировал. Это же легко проверить. Проверь.

Не понял, что проверить. google DNS выдаёт TTL для CNAME-записи.

dig www.urfu.ru @8.8.8.8

; <<>> DiG 9.16.15 <<>> www.urfu.ru @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62490
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.urfu.ru.                   IN      A
;; ANSWER SECTION:
www.urfu.ru.            1917    IN      CNAME   urfu.ru.
urfu.ru.                3600    IN      A       93.88.179.200

;; Query time: 73 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Dec 24 09:04:33 +05 2022
;; MSG SIZE  rcvd: 70

Проверить, что google DNS не кеширует CNAME? Или что CNAME не кешируют браузеры?

Как проверить, что там кеширует google я вобще не знаю, допустим, я сделал несколько запросов к @8.8.8.8 с интервалом примерно 10 секунд, получил такое:

www.urfu.ru.            3600    IN      CNAME   urfu.ru.
www.urfu.ru.            3590    IN      CNAME   urfu.ru.
www.urfu.ru.            3498    IN      CNAME   urfu.ru.
www.urfu.ru.            1469    IN      CNAME   urfu.ru.

Из этого получается, что менять содержимое CNAME записи и делать запрос к 8.8.8.8 не вариант. Мы можем попасть на сервер, где нашей CNAME нет (уже нет) в кеше и получить в ответ новое значение. Но не потому, что это CNAME (с якобы TTL 1), а потому, что кеш пустой.

Или реверс прокси с балансером, nginx умеет round robin.

Upd. Тьфу, глупость написал ) тут уже третий сервер нужен

Этот чит позволяет игнорировать ttl.

4.2.

Сначала разберись какую конкретно проблему ты пытаешься решить. Сейчас ты занимаешься ерундой.

Вот как подобные задачи решаются в DNS-сервисе Amazon Route 53:

• Configuring DNS failover
• Active-passive failover
• How Amazon Route 53 determines whether a health check is healthy

А как же чётвёртый, если один лоад балансер ляжет:)

А если серьёзно, то ничего не мешает развернуть обратный прокси на существующий серверах

На nic.ru есть подробная инструкция.