Стратегия отработки отказа сервера баз данных EC2
Я планирую развернуть свое веб-приложение в EC2. У меня есть несколько экземпляров веб-сервера. У меня есть 1 экземпляре базы данных. У меня есть 1 экземпляр базы данных отработки отказа. Мне нужна стратегия перенаправления веб-серверов на IP-адрес экземпляра базы данных отработки отказа при сбое основного экземпляра базы данных.
Я надеялся, что смогу использовать эластичный IP в моих строках соединения. Но веб-серверы не могут получить доступ/ping к эластичному IP-адресу. У меня есть несколько идей грубой силы, чтобы решить проблему. Тем не менее, я пытаюсь найти самое элегантное решение.
Я использую все .Net и SQL Server. Мои строки подключения зашифрованы.
есть ли у кого-нибудь стратегия отказа от экземпляра базы данных в EC2 с использованием какой-либо формы автоматизации или конфигурации DNS?
пожалуйста, дайте мне знать.
5 ответов
http://alestic.com/2009/06/ec2-elastic-ip-internal
говорит вам, как использовать эластичный IP public DNS.
не использовали EC2, но, конечно, вам нужно либо:
(a) поместите свой интерфейс в некоторый пользовательский режим обслуживания, который вы определяете, при переключении IP-адреса; и попросите интерфейс выполнить необходимые шаги для управления потенциальной целостностью данных и проблемами потери данных, связанными с предыдущим сервером, и новым сервером, когда он входит и выходит из вашего пользовательского режима обслуживания
или, для нулевой системы времени простоя:
(b) проектирование системы на объектно-реляционном и транзакционном уровнях с нуля до поддержки нулевого времени простоя. Это не то, что вы можете болт на quicjkly только для любого приложения.
(c) используйте некоторую поддержку базы данных для автоматической отработки отказа. Я не знаю, существует ли здесь поддержка SQL Server для отработки отказа, подходящая для вашего приложения. Я предлагаю добавить тег "sql-server" к вопросу, чтобы начать поиск нужной аудитории.
Если эластичные IPs не работают (что звучит странно, мягко говоря, - не следует ли вам поговорить об этом с EC2), вы, возможно, сможете проинструктировать свой интерфейс, какой новый IP-адрес базы данных использовать одновременно с сообщением ему перейти из режима обслуживания в нормальный режим.
Если вы готовы выложить немного денег, взглянем на RightScale, позволяющее производить это tools; они создали пользовательские образы серверов и вспомогательные инструменты, которые обрабатывают отказоустойчивость базы данных (среди многих других вещей). этой ссылке объясняет, как это сделать с MySQL, поэтому, надеюсь, покажет вам некоторые принципы, даже если он не использует SQL Server.
Я всегда думал, что есть такая возможность в строке подключения
это взято (но еще не протестировано) из как добавить отказоустойчивого партнера в строку подключения в VB.NET:
Если вы соединяетесь с ADO.NET или SQL Собственный клиент для базы данных, которая будучи зеркальным, ваше приложение может воспользуйтесь возможностями драйверов автоматическое перенаправление соединений когда на зеркальный ресурс происходит. Вы должны укажите начальную основной сервер и база данных в строку подключения и перехода сервер-партнер.
Data Source=myServerAddress;Failover Partner=myMirrorServerAddress; Initial Catalog=myDataBase;Integrated Security=True;
есть конечно много других способов запись строки подключения с помощью зеркальное отображение базы данных, это только один пример, указывающий на отказоустойчивость функциональность. Вы можете объединить это с другими строками соединения доступные варианты.
чтобы расширить ответ Гарета, программное обеспечение для управления облаками обычно решает этот тип проблем. RightScale является одним из них, но вы можете попробовать enStratus или Scalr (отказ от ответственности: я работаю в Scalr). Эти инструменты обеспечивают отказоустойчивые решения, такие как:
- резервные копии: вы можете запланировать автоматические снимки Тома EBS, содержащего данные
- отказоустойчивая база данных: в случае отказа, невольник повышенный Мастер и установленное хранение будут переключены если неудачный Мастер и новый мастер находятся в одном AZ или снимок Тома
Если вы хотите создать свое собственное решение, вы можете повторить процесс, описанный ниже, который мы используем в Scalr:
- есть ли раб в том же AZ? Если это так, продвигайте его, переключайте EBS тома (которые ограничены одним AZ), переключают любой ElasticIP вы возможно, перенастроить репликацию оставшихся рабов.
- если нет, есть ли раб полностью реплицируется в другом AZ? Если да, то продвигайте его, затем сделайте все вышесказанное.
- если нет раба в том же AZ, и нет раба полностью реплицируется в другой AZ, а затем создает снимок из master том и используйте этот снимок для создания нового тома в AZ, где раб бежит. Затем сделайте все вышесказанное.