Максимальный uptime

Если каждый из dns-серверов осуществляет мониторинг доступности серверов сайта, то он может выдавать клиентам IP сайта в зависимости от доступности сервера(-ов).

При разрешении имен, библиотеки dns, обязаны опрашивать следующий ns-сервер, если очередной не отвечает. Это поведение dns было задумано с самого начала и документировано. Именно этим оно и лучше.

Нет. Допускаю, что решение об использовании RR было принято только ради балансировки. Все остальное вы придумали.

Мониторить доступность серверов и выдавать IP в зависимости от доступности - это уже не простое решение, которое каждый мог бы реализовать самостоятельно, и явно сложнее, чем прописать в зоне несколько IP. Хотя в арсенале средств фейловера специалистами это и применяется, но в качестве единественного и все решающего средства это не подходит. Только вместе с другими. Например, DNS-сервер мониторит веб-серверы и отдает списом все IP-адреса, исключая из него недоступные.

Полагаться только на TTL DNS - плохая идея. Ресолвер опрашивает следующий ns-сервер, если во время запроса к DNS не ответил очередной ns-сервер. Браузер в этом никак не участвует. Если браузер получил из кэша своего dns-сервера IP-адрес, который барузеру не ответил, перезапрашивать по DNS браузер не будет, не смотря на любые TTL. В стандартах этого нет, в стандартах есть multiple A-records.

То, что "Все остальное вы придумали" - это допущение, утверждение или вы так припоминаете? Если утверждение, то где подтверждение утверждения? Если допущение, то ладно, допускать можно все-то угодно, и что земля плоская.

Да, в течении некоторого небольшого времени TTL в проекте этой схемы некоторые пользователи получали бы ошибки.

Однако, плюсы тоже есть :

- Более широкий выбор схем дублирования. можно задействовать резервные сервера, которые не работают постоянно и не обязаны быть такими же быстрыми как основные.

- К асинхронной односторонней репликации данных в другой ДЦ совсем другие требования по скорости. Она гораздо быстрее и проще, чем поддержание актуальных копий данных на каждом сервере для RR. Синхронная репликация в другой ДЦ может вообще так медленно работать, что функционирование RR-кластера будет невозможно.

- Можно в некоторой степени устроить распределение нагрузки по географическому признаку как в BGP.

- По сравнению с BGP, стоимость организации мизерная. В минимальной конфигурации нужно всего лишь два VPS в разных ДЦ.

Все это было бы, если бы не поведение IE.

Для RR получаем, что некоторые пользователи, браузеры которых не поддерживают RR особым образом при наступлении сбоя в 50% случаев не смогут открыть сайт до устранения сбоя. Как много таких браузеров еще нужно выяснить.

В браузере могли реализовать работу с RR, но для работы с DNS-файловером точно не нужно никакого особенного кода в программе. Этим она и лучше.

По-моему, все прекрасно понятно. Перечитывайте.

У небольшого времени TTL есть проблема - если TTL будет 1 минута, то у посететеля сайта после каждой минуты будут возникать дополнительные задержки на повторный ресолвинг. Получается, что для того, чтобы повысить отказоустойчивость для редких, в общем-то, простоев, нужно будет в той или иной степени ухудшить скорость отдачи страниц. Если TTL увеличивать, то увеличивается процент посетителей, попавших на умерший сервер.

Из плюсов по сравнению с multiple IP, согласен только с одним:

Удешевление репликации - это его следствие.

Геобалансинг от низкого TTL никак не зависит, к плюсам относить бессмысленно.

У multi IP по сравнению с BGP тоже стоимость мизерная, поэтому к плюсом низкого TTL относить не надо.

Не только IE, не забывайте игнорирующих TTL провайдеров и поисковики. Это может быть неприятно припоминать, но это реальность.

Я не встречал таких браузеров, но допускаю, что какие-то редкие экзотические есть. Скорее всего доля таких в общем числе чуть отличается от нуля. Для них, да 50% - это если в сети два хоста и вышел из строя один. Если их больше, то вероятность того, что он окажется в списке первым, уменьшается. На практике сочетают обе схемы - multi IP и небольшой TTL (10 - 60 минут), и исключение недоступного хоста из списка, что позволяет получить практически достижимый максимум. Правда, исключение делается в первую очередь не для предполагаемых проблемных браузеров, а для минимизации задержек на подключение к неотвечающим хостам.

Прямой ответ вы дать не можете. Это можно понять.