Вопрос

И что бы вы порекомендовали для веб-приложения ASP Net с не такой большой базой данных SQL server (около 10 Гб)?

Мне просто интересно, хорошая ли это идея - настроить экземпляр Amazon EC2, готовый к размещению вашего приложения в экстренной ситуации?

В этом сценарии, каков был бы наилучший подход для обновления базы данных (доставка журналов?восстановление резервной копии вручную?) и самый простой и быстрый способ изменить настройки dns?

Редактировать:приемлемое время простоя составило бы от 4 до 6 часов, вот почему я решил использовать опцию Amazon ec2 из-за ее более низкой стоимости по сравнению с арендой дополнительного сервера.

Это было полезно?

Решение

Обновить - Только что видел ваш комментарий.Amazon EC2 с доставкой журналов - это, безусловно, правильный путь.Не используйте зеркальное отображение, поскольку обычно при этом предполагается, что доступна другая резервная база данных.Изменение вашего DNS не должно занять более 1/2 часа, если вы настроили свой TTL на это.Это дало бы вам время интегрировать все журналы, которые находятся на рассмотрении.Может включать сервер раз в неделю или около того просто для интеграции журналов, которые находятся на рассмотрении (или реже, чтобы избежать увеличения почасовых затрат).


Ваше основное местоположение хостинга должно иметь избыточность на всех уровнях:

  • Несколько подключений к Интернету,
  • Несколько брандмауэров, настроенных на отказоустойчивость,
  • Несколько кластеризованных веб-серверов,
  • Несколько кластеризованных серверов баз данных,
  • Если вы храните файлы, используйте SAN или Amazon S3,
  • Каждый сервер должен иметь ту или иную форму RAID в зависимости от назначения сервера,
  • Каждый сервер может иметь несколько блоков питания, подключенных к отдельным источникам питания / выключателям,
  • Программное обеспечение для мониторинга внешних и внутренних серверов,
  • Электрогенератор, который автоматически включается при отключении питания, и резервный генератор на всякий случай.

Это позволит вам работать в вашем основном местоположении в случае большинства сценариев сбоев.

Затем настройте один сервер в удаленном расположении, который постоянно обновляется с помощью доставки журналов, и включите его в свой сценарий развертывания (после обновления ваших обычных производственных серверов ...) Сервер, расположенный на другом конце страны, прекрасно подходит для этих целей.Чтобы свести к минимуму время простоя из-за необходимости переключения на вторичное местоположение, поддерживайте свой TTL в записях DNS на максимально низком уровне, насколько вам удобно.

Конечно, такое количество оборудования будет крутым, поэтому вам нужно будет определить, что стоит отключить на 1 секунду, 1 минуту, 10 минут и т.д.и отрегулируйте соответствующим образом.

Другие советы

Все зависит от того, каковы ваши требования к времени простоя.Если у вас есть получил восстановиться за считанные секунды, чтобы не потерять свой многомиллиардный бизнес, тогда вы будете действовать совсем не так, как если бы у вас был сайт, который приносит вам около 1000 долларов в месяц и на чей доход не повлияет заметный сбой в течение дня.

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

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

Следующая статья поможет вам начать работу в правильном направлении.

https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1038783.html

Если вам нужны дополнительные рекомендации, старый добрый Google может предоставить вам еще много информации.

Проект такого рода требует от вас сотрудничества с ключевыми лицами, принимающими бизнес-решения, и вам нужно будет сообщить им, каковы связанные с этим затраты на простой и каковы будут последствия для бизнеса.Скорее всего, вам потребуется сотрудничать с несколькими бизнес-подразделениями, чтобы собрать необходимую информацию.Затем вам коллективно необходимо прийти к решению относительно того, что считается приемлемым временем простоя для вашего бизнеса.Только после этого вы сможете разработать стратегию DR с учетом этих требований.

Вы также обнаружите, что выполнение этого упражнения может выявить недостатки в текущей конфигурации вашей платформы в отношении высокой доступности, и это также может потребовать рассмотрения в качестве отдельного проекта.

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

Не забудьте протестировать свою стратегию DR, выполнив тестовый сценарий, чтобы подтвердить время восстановления и попрактиковаться в этом процессе.Если придет время, когда вам нужно будет реализовать свою стратегию DR, вы, скорее всего, окажетесь под давлением, ваш телефон будет часто звонить, а люди будут виться вокруг вас, как комары.Уже отточив и отрепетировав свой ответ на действия врача, вы можете быть уверены, что возьмете ситуацию под контроль и процесс выздоровления пройдет гладко.

Удачи вам в вашем проекте.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top