Стратегия отработки отказа сервера баз данных EC2
Я планирую развернуть свое веб-приложение на EC2. У меня есть несколько экземпляров веб-сервера. У меня есть 1 экземпляр первичной базы данных. У меня есть 1 экземпляр отказоустойчивой базы данных. Мне нужна стратегия перенаправления веб-серверов на IP-адрес экземпляра отказоустойчивой базы данных, когда происходит сбой основного экземпляра базы данных.
Я надеялся, что смогу использовать эластичный IP-адрес в своих строках подключения. Но веб-серверы не могут получить доступ к эластичному IP-адресу. У меня есть несколько идей грубой силы, чтобы решить эту проблему. Тем Не Менее, Я я пытаюсь найти самое элегантное решение из всех возможных.
Я использую все .Net и SQL Server. Мои строки подключения зашифрованы.
Есть ли у кого-нибудь стратегия отказа экземпляра базы данных в EC2 с использованием какой-либо формы автоматизации или конфигурации DNS?
Пожалуйста, дайте мне знать.
5 ответов:
Http://alestic.com/2009/06/ec2-elastic-ip-internal
Показывает, как использовать эластичный IP-публичный DNS.
Не использовал EC2, но, конечно, вам нужно либо:
(a) переведите интерфейс в определенный пользовательский режим обслуживания, который вы определяете, в то время как вы переключаете IP; и попросите интерфейс выполнить необходимые шаги для управления потенциальной целостностью данных и проблемами потери данных, связанными с предыдущим сервером, выходящим из строя, и новым сервером, выходящим из вашего пользовательского режима обслуживания
Или, для системы нулевого времени простоя:
(b) проектирование системы на объектно-реляционный и транзакционный уровни от нуля до поддержки нулевого времени сбоя. Это не то, что вы можете легко прикрепить к любому приложению.
(c)используйте некоторую поддержку базы данных для автоматического перехода на другой ресурс. Я не знаю, существует ли поддержка SQL Server для отработки отказа, подходящая для вашего приложения, или она уместна здесь. Я предлагаю добавить к вопросу тег "sql-server", чтобы начать поиск нужной аудитории.
Если эластичные IP-адреса не работают (что звучит странно по меньшей мере-не следует ли вам поговорить об этом с EC2), вы, возможно, сможете указать своему интерфейсу, какой новый IP-адрес базы данных использовать одновременно с тем, чтобы он перешел из режима обслуживания в нормальный режим.
Если вы готовы выложить немного дополнительных денег, посмотрите на инструментыRightscale ; они создали пользовательские образы серверов и вспомогательные инструменты, которые обрабатывают отказоустойчивость базы данных (среди многих других вещей). Эта ссылка объясняет, как это сделать с 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, содержащего данные
- отказоустойчивая база данных: в случае сбоя ведомое устройство становится ведущим, а смонтированное хранилище переключается, если вышло из строя ведущее устройство и новые мастера находятся в той же АЗ, или снимок сделан из Тома
Если вы хотите построить свое собственное решение, вы можете повторить процесс, описанный ниже, который мы используем в Scalr:
Есть ли раб в том же АЗ? Если да, продвигайте его, переключайте EBS томов (которые ограничены одним АЗ), переключите любую ElasticIP вас может быть, перенастроить репликацию оставшихся рабов.
- Если нет, то существует ли раб, полностью реплицированный в другой АЗ? Если да, то продвигайте его, затем сделайте следующее выше.
- Если нет раба в том же АЗ, и нет раба полностью реплицируется в другой АЗ, затем создается моментальный снимок из Мастера том, и использовать этот моментальный снимок для создания нового тома в AZ, где a раб бежит. Затем сделайте то же самое.