Вы не учли более простой (как мне кажется) вариант с Dynamic DNS.
Есть простое решение, которое делается за час на базе okerr + dynamic DNS.
https://habr.com/ru/articles/359372/
Зайдите на
https://cat.okerr.com/ и если вы увидите котенка и надпись "status=OK" - значит, эта система работает. При том что там всего 3 сервера и каждые 20 минут мы условно "пристреливаем" один из них :-) В первый заход вы почти 100% попадете на живой сервер. В последующие можете оставаться на "умершем" короткое время, пока DNS запись не переключится (это уже проблема с браузером, часто в инкогнито загружается правильная страница).
Кратко - при детектировании ошибки, изменяется DNS запись на то значение, которое работает. (Для этого не требуется, чтобы DNS хостер умел в DynDNS, можно даже и без этого)
Несколько тонкостей:
1. Ситуация "падает доступ" только в теории очевидная и однозначная (потому что мы ее сами выдумали, а не исследуем Н.Ё.Х. ). В реальности - это более серая ситуация. Что именно мы считаем "падает доступ"? Например, если потерялся один сетевой пакет (на самом деле случается регулярно) - это уже "доступ упал"? Если с сервера мониторинга в Амстердаме доступ есть, а с сервера мониторинга в Твери через минуту доступа нет - то как это понимать: Ваш сервис за эту минуту упал или просто какие-то локальные проблемы в Твери? И даже если проблема видна с обоих серверов - это уже повод для паники и переключения, или мы полагаем, что проблема может быть минутная и лучше пусть через минуту сама исправится? Придется ответить себе на эти вопросы, но любой ответ будет по-своему ошибочный, всегда будет trade off между скоростью переключения и ложными срабатываниями.
2. Все равно сохраняется некоторое временное "окно" недоступности. Представим, что в момент T0 вы выдергиваете кабель (симулируете проблему). Мониторинг может заметить первую проблему во время T1, которое зависит от настроек и удачи (если перепроверка каждые 30 секунд, то заметить может и через 1 секунду и через 29 секунд). Если у нас есть перепроверки (чтобы избежать ложных результатов), то перепроверка будет во время T2 (причем, вы самим можете хотеть, чтобы Т2 было не в ту же секунду, а дать хотя бы минуту, чтобы ситуация может быть сама решилась). Затем уйдет 1-2 секунды чтобы изменить DNS запись. И вот после этого момента, если клиент решил зайти на ваш сайт, он получит новый (работающий) IP - для него все супер. Но другой человек, кто уже работает с ним, в момент переключения будет иметь старую DNS запись, и для него все еще будет не работать, пока эта запись не протухнет в DNS кеше (в браузере, на компьютере, на DNS резолвере/роутере). Этот период времени можно сократить выставив низкий TTL в DNS.
Замечания по вашим вариантам:
1. Облака - тоже падают. Может постабильнее, но вот я через окерр слежу за своими серваками на разных хостерах, иногда ложится и дешевый hetzner и дорогой AWS. (Причем, я бы не сказал, что даунтайм у hetzner выше. Субъективно и по моему личному опыту - наоборот). Небольшое утешение - если вы НЕ будете использовать мониторинг - скорее всего, вы этого не заметите. :-) Но в целом облачный вариант достаточно надежен (если не ожидать от него абсолютных 100%).
2. Раунд-робин DNS - в принципе могло бы подойти. Но тоже каждая попытка будет занимать какое-то время и даже когда будет очевидно, что один IP у вас умер, раундробин по прежнему будет его выдавать. Но если юзер будет долбиться в кнопку refresh - то рано или поздно пробьется -). Хотя есть еще проблема с браузерным кешем (как выше вот описал). Как вариант - вообще сделать собственное веб-приложение (не путать с веб-страничкой), которое все все данные умеет брать с разных серверов. Не смогла взять с www1.example.com, ну значит лезет на www2.example.com. Тогда это будет почти незаметно для пользователя. Но дорого разрабатывать приложение с этой сложностью. И да, это только для веба.
3. Обновление DNS записей. Вы пишете про ужасные 12 часов. Это должно регулироваться полем TTL записи - если изменить ее, все будет лучше. Но до секунды лучше не менять, а вот 30 секунд (наверное, это минимум, не уверен, что подойдет), минута ли пять минут - выглядят как разумный компромисс в вашей ситуации.
4. AS, BGP и все прочие сатанинские слова.
Страшно, очень страшно, мы не знаем что это такое, если бы мы знали, что это такое, но мы не знаем, что это такое. Вам это может быть кажется интересным вариантом именно потому, что вы не знаете, насколько этот вариант ужасен, не имеете опыта с ним и все его минусы и сложности и ужасы для вас пока скрыты. Проблем там будет дофига. А кроме всего прочего, подумайте вот о чем - я выше написал, как в окерре все сложно и неоднозначно с простой казалось бы вещью - "доступен ли у нас сервер или нет" (хотя старались сделать как можно проще). Так вот с динамической маршрутизацией - не лучше. Там ведь тоже есть те же самые проблемы диагностики (как отличить кратковременное падение линка на 2 секунды, от выхода из строя и избежать ненужного переключения?) и проблемы переключения (окей, один роутер догадался, что линк лежит - а как скоро все роутеры мира обновят свои таблицы маршрутизации? К ноябрю?). Даже если вы наймете супер гуру в AS / BGP вряд ли он вам гарантирует переключение за секунду или хотя бы минуту. BGP обеспечивает связность сети в принципе (вот, в масштабе "хотя бы к ноябрю"), но не обеспечивает моментальности или даже минутности, пятиминутности. И те процедуры обнаружения неисправности и восстановления скорее всего вам будет сложнее использовать и подкручивать под себя. Весь мир использует BGP, но не забывайте, что это тот же самый мир, который в 2024 году использует IPv4 из 1981 и не может перейти на IPv6. В общем, ну его.
Средний
