Здравствуйте!
В общих чертах:
Есть сервер A на котором трафка более 1.5млн в сутки.
Простой сайтов критичен по сути, более чем на 20 минут простоя уже влекут за собой проблемы.
Требуется сделать резервный сервер B в другом ДЦ где будет собственно располагаться дубль сервера A. Существуют ли готовые систем, или архитектуры перенаправления трафка на "здоровый" сервер B, в случае поломки или недоступности А. После того как сервер А поднят и протестирован по нужным параметрам, система снова пускает на него трафик.
Пробывали рассмотреть систему round robin, но это больше система распределения нагрузки нежели система защиты от сбоев, по этому от нее отказались.
Если можно по подробнее с указанием источников.

Самое простое по сути - распределение нагрузки между 1 и более(roundRobin, ага) прокси(squid nginx etc.), а прокся сама решает, использовать A, B или С.
По сути, слабое звено переносится с серверов на прокси, которыми управлять намного проще и меньше шансов выхода из стоя.

Да я тоже думал на счет проксирования, но вот не как не смог найти в сети готовых схем работы подобных систем, хотя бы посмотреть топологию. Я не сильно разбираюсь в этом, только поверхностно знаю. Но для того чтобы нанять кого либо надо четко сформировать задачу. Вот по этому и решил посоветоваться с специалистами. Может есть железки такие уже, которые выступают в виде проксирования, тк сервер конечно хорошо но просто с железкой шансов получить сбой на первом шаге будет меньше. Вобщем надо схемы видеть. Не могли бы вы дать ссылки?

Я, честно говоря, в подобных вещах тоже не силен.

Знаю, что товарищи покрывали огромное здание интернетом и для распределения нагрузки между серверами биллинга использовали какую-то циску. Но какую точно не скажу, ибо не в теме.

Готовых решений нет
Есть готовые инструменты для создания таких решений

Например, самое доступное по цене решение - это создание отказоустойчивого балансировщика в сверхнадежном ДЦ из двух серверов в режиме Active-Standby

На балансировщике делаем опрос серверов и перемещаем трафик на "живой сервер", делая 301 редирект на внутренний домен типа mirror1.site.com

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

Вобщем подобных решений - масса, все зависит от требований и бюджета.
Обращайтесь если что

Ну ставить железяки в чужой ДЦ как бы особо смыслом не наполнен, это имеет смысл когда я овнер ДЦ был бы. Но все же система с 301 ридеректом хороша. Надо ее додумать. Спасибо за совет.

Да незачто. Все нормальные cdn на этом основаны в принципе
Кстати - ставить ненадо, можно просто взять пару дедиков

Дешевое решение - NS на каждом сервере, отдает A только на себя. Плюсы - очень просто и дешево, минусы - в пролете все, кто работал с упавшей нодой в момент ее падения - как сама винда, так и браузеры кешируют IP... вопрос где-то в 20-30 минутах. Зато новые клиенты попадают уже на резерв. В минусы так же всякие "неправильные" ресолверы, которые кешируют дольше чем позволяет TTL.
Решение чуть подороже - аналогичное CDN. На самом деле это тот же первый вариант, только NS-ы унесены отдельно и они "умные" - решают кому какой A отдать. Минусы ровно все те же, что в первом варианте, в плюсы добавляется возможность рулить нагрузкой на ноды, давать пользователю ближайший к нему сервер и мониторить состояние не серверов, а _сервисов.
Решение с проксей не рассматриваю - оно бредовое, ибо оно из серии "а кто будет контролировать контролеров".
Решение подороже - AS, PI, договоренности со всеми ДЦ анонсировать вашу AS. Тут, понятно, отказоустойчивость определяется BGP. Дополнительно наворачиваем мониторинг сервиса, который положит BGP. Минусы - BGP тоже немного инерционен, хотя в общем меньше, чем DNS кеши в винде.
Самое дорогое решение - своя (ну или арендованная) сеть, которая соединяет минимум три точки - оба ДЦ и точку получения трафика (а лучше две точки). Ну, AS, LIR, железки с BGP тут еще дороже =) В общем минус - очень дорого.. особо если ДЦ далеко. Резервирование точкек связности тем же BGP.

CDN работает не на уровне ресолвинга а на уровне подмены заголовков http, чтоб разруливать трафик

CDN работают по разному
Но мы сейчас не о распределенной доставке контента говорим, а исключительно об отказоустойчивости. В этом контексте работает только метод DNS - все остальные требуют установки HTTP сессии с балансером, который будет слабым звеном. Почему все так DNS любят - там есть и реализован у всех fallback, а вот в HTTP с этим плохо.

По факту оказалось что ТС будет достаточно monit'а

А такие ДЦ бывают? ;)
Даже сверхнадежный (по каналам) ДЦ может быть физически затоплен при наводнении или разрушен грозой ;)

Я вот так и не смог найти решение (где 5 минут простоя уже критичны), которое бы не было завязано на что-то одно сверхнадежное (будь то ДЦ, Оператор и т.д).

Решение с NS, ссылающимися каждый на себя, выглядит в теории идеальным, но что-то подсказывает, что на практике (когда каждый интернет-провайдер у себя все как хочет настраивает) оно не идеально будет.

Я прав, что нет такого решения или оно есть, но стоит совсем заоблачных денег?

Бывают, но стоят заоблачных денег