Назад | Перейти на главную страницу

Является ли это надежной (и дешевой) идеей высокой доступности для моего веб-сайта и базы данных в случае атаки зомби?

У меня есть идея для отказоустойчивой высокой доступности для моего веб-сайта, но я не уверен, хорошо это, плохо или само по себе катастрофа.

На моем основном сервере размещен веб-сайт 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 ниже, но сначала я бы коснулся некоторых более фундаментальных вопросов.

Вот примерный порядок, в котором я буду работать:

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

  2. Убедитесь, что ваша среда хорошо спроектирована.

  3. Убедитесь, что ваша среда имеет избыточность (локальные зеркала всего критического, HA / Failover).
    Если у вас хороший провайдер, у вас хороший дизайн и все избыточно, чтобы справиться с отказом хотя бы одного компонента, о котором вы позаботились о большей части сбоев. Вы также, вероятно, дали себе возможность выполнять одновременное обслуживание если ваш дизайн из №2 был хорош.

  4. Убедитесь, что у вас есть резервные копии. Убедитесь, что вы можете восстановить их и вернуть работающую систему.

  5. Проверь, черт возьми, числа 3 и 4 (Думайте, как обезьяна Хаоса & смоделировать отказы)

  6. Сделав 1-4 готово, теперь подумайте, как бы вы скопировали это в удаленное место, если метеорит упадет в здание вашего провайдера.
    Если 2-4 выше были выполнены хорошо, эта часть должна иметь очевидные и относительно простые пути реализации.

  7. Протестируйте, черт возьми, отказоустойчивость / возврат с помощью того, что вы реализовали в # 6.
    Лаборатория VMWare здесь ОЧЕНЬ полезна.

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

Почему бы вам просто не получить экземпляр на AWS? Получите экземпляр на E2C, разместите там свое приложение и позвольте им беспокоиться о времени безотказной работы.

Чтобы быть вдвойне уверенным, у вас может быть два экземпляра (второй, возможно, в качестве горячей резервной копии) в разных регионах: один в их американском DC, а другой в их азиатском DC.