Стратегия обработки отказа сервера базы данных EC2
Я планирую развернуть свое веб-приложение на EC2. У меня есть несколько экземпляров веб-сервера. У меня есть 1 основной экземпляр базы данных. У меня есть 1 экземпляр базы данных обработки отказа. Мне нужна стратегия перенаправить веб-серверы к IP экземпляра базы данных обработки отказа, когда основной экземпляр базы данных перестал работать.
Я надеялся, что мог использовать Эластичный IP в своих строках подключения. Но, веб-серверы не могут получить доступ/проверить с помощью ping-запросов к Эластичному IP. У меня есть несколько идей грубой силы решить проблему. Однако я пытаюсь найти самое изящное решение возможным.
Я использую весь .NET и SQL Server. Мои строки подключения шифруются.
У кого-либо есть стратегия обработки отказа экземпляра базы данных в EC2 с помощью некоторой формы автоматизации или конфигурации DNS?
Пожалуйста, дайте мне знать.
3 ответа
http://alestic.com/2009/06/ec2-elastic-ip-internal
расскажет, как использовать общедоступный DNS с эластичным IP-адресом.
Если вы готовы выложить немного дополнительных денег, взгляните на инструменты Rightscale ; они создали пользовательские образы серверов и вспомогательные инструменты, которые обрабатывают отработку отказа базы данных (среди прочего). Эта ссылка объясняет, как это сделать с MySQL, поэтому, надеюсь, покажет вам некоторые принципы, даже если он не использует SQL Server.
Не использовал EC2, но, конечно, вам нужно либо:
(a) перевести ваш внешний сервер в режим пользовательского обслуживания, который вы определяете, в то время как вы переключаете IP-адрес; и заставить внешний сервер выполнить необходимые шаги для управления потенциальными проблемами целостности и потери данных, связанными с выходом из строя предыдущего сервера и нового сервера, когда он входит и выходит из пользовательского режима обслуживания
ИЛИ, для системы с нулевым временем простоя:
(b) проектируйте систему на уровне объектов/проектов и транзакций с нуля для поддержки обхода отказа с нулевым временем простоя. Это не то, что вы можете подключить quicjkly к любому приложению.
(c) используйте некоторую поддержку базы данных для автоматического обхода отказа. Я не знаю, существует ли поддержка SQL Server для обхода отказа, подходящая для вашего приложения, или она здесь уместна. Я предлагаю добавить в вопрос тег "sql-server", чтобы начать поиск нужной аудитории.
Если эластичные IP не работают (что, мягко говоря, звучит странно - не стоит ли вам поговорить об этом с EC2), вы, возможно, сможете указать вашему фронт-енду, какой новый IP базы данных использовать, и одновременно сказать ему, чтобы он перешел из режима обслуживания в нормальный режим.
.