У меня есть идея для отказоустойчивой высокой доступности для моего веб-сайта, но я не уверен, хорошо это, плохо или само по себе катастрофа.
На моем основном сервере размещен веб-сайт ASP.net, который использует базу данных SQL-сервера на другом сервере.
На обоих серверах установлены зеркальные raid-диски, две сетевые карты, 2 коммутатора и т. Д. Провайдер гарантирует 99,999% времени безотказной работы, но что-то пошло не так, и потребовался почти день, прежде чем проблема разрешилась.
Меня больше беспокоят такие проблемы, как доменное имя / DNS, которые находятся вне нашего прямого контроля и на распространение которых может уйти от 6 до 24 часов.
Или, если на то пошло, широко распространенные бедствия, которые могут вывести из строя наш главный центр обработки данных, линии электропередач, инфраструктуру сетевого подключения, захват домена и рост людей, поедающих нежить;) и т. Д.
Моя идея такова: разместить второй домен у другого провайдера в другой стране. Назовите домен чем-то похожим на название основного сайта.
У этого вторичного провайдера должны быть сервер для сайта и сервер для базы данных SQL. Веб-сервер настраивается и настраивается с веб-сайтом точно так же, как и с основным сайтом.
Мой основной сервер SQL зеркалирует (используя высокопроизводительное зеркалирование) на вторичный сервер у вторичного провайдера каждые 5 минут.
Предположим, что по какой-то причине основной сайт недоступен из-за того, что происходит что-то большое и неприятное.
Измените DNS, чтобы он указывал на резервный домен, и сообщите в Twitter, Facebook и т. Д., Что любой, кому нужен мой сайт, может использовать www.backupdomain.com, пока обновления DNS не распространятся по сети.
Будет ли это работать, и есть ли лучший вариант для решения подобных проблем?
Большинство проведенных мною исследований указывают на отказоустойчивость кластеров, балансировку нагрузки, дублирование оборудования, зеркалирование и тому подобное, что, как я понимаю, сделает локальный хостинг избыточным, но как мне справиться с более обширными прерываниями.
Бюджет также ограничен, поэтому мы не можем тратить миллионы на супер-пуперскую систему Google Never die. Но то, что может справиться с действительно серьезными сбоями и занять всего от 30 минут до 1 часа, было бы идеально.
Совет, предложения, ссылки приветствуются.
Варианты, которые вы описываете, неплохие - на самом деле они хорошие, и тот факт, что вы обдумываете это, говорит о вас хорошо.
Вы, безусловно, можете реализовать то, что вы описали выше, или использовать облачного провайдера в качестве (гораздо менее дорогостоящего) сайта резервного копирования, как предлагает ksm ниже, но сначала я бы коснулся некоторых более фундаментальных вопросов.
Вот примерный порядок, в котором я буду работать:
Убедитесь, что ваш хостинг-провайдер достойный
Минимум избыточного питания, трубопроводов и охлаждения.
Убедитесь, что ваша среда хорошо спроектирована.
Убедитесь, что ваша среда имеет избыточность (локальные зеркала всего критического, HA / Failover).
Если у вас хороший провайдер, у вас хороший дизайн и все избыточно, чтобы справиться с отказом хотя бы одного компонента, о котором вы позаботились о большей части сбоев. Вы также, вероятно, дали себе возможность выполнять одновременное обслуживание если ваш дизайн из №2 был хорош.
Убедитесь, что у вас есть резервные копии. Убедитесь, что вы можете восстановить их и вернуть работающую систему.
Проверь, черт возьми, числа 3 и 4 (Думайте, как обезьяна Хаоса & смоделировать отказы)
Сделав 1-4 готово, теперь подумайте, как бы вы скопировали это в удаленное место, если метеорит упадет в здание вашего провайдера.
Если 2-4 выше были выполнены хорошо, эта часть должна иметь очевидные и относительно простые пути реализации.
Протестируйте, черт возьми, отказоустойчивость / возврат с помощью того, что вы реализовали в # 6.
Лаборатория VMWare здесь ОЧЕНЬ полезна.
Обратите внимание, что я не вдавался в подробности - ваша среда будет определять, как вы будете выполнять каждый из шагов выше.
Почему бы вам просто не получить экземпляр на AWS? Получите экземпляр на E2C, разместите там свое приложение и позвольте им беспокоиться о времени безотказной работы.
Чтобы быть вдвойне уверенным, у вас может быть два экземпляра (второй, возможно, в качестве горячей резервной копии) в разных регионах: один в их американском DC, а другой в их азиатском DC.