Я пытаюсь реализовать автоматическое переключение на отказ для веб-сайта ASP.NET MVC, работающего в Windows 2008 R2 Web Edition / SQL Server 2008 R2 Web Edition. Я знаю, что это не поддерживается из коробки, но мне приходится довольствоваться лицензиями на программное обеспечение, которые в настоящее время находятся в моем распоряжении.
Под автоматическим переключением при отказе я подразумеваю, что в случае аварии вторичный сервер должен подключиться со всеми данными из базы данных первичного сервера. Если это не вариант, я также доволен «всеми данными, за исключением того, что было записано в БД за последние 5 минут».
При необходимости я с радостью вернусь к основному серверу.
Вот что я до сих пор придумал:
Настройте доставку журналов из БД первичного сервера на вторичный сервер с очень маленьким временным интервалом (5 минут). БД не слишком велика (<50 МБ) и мало что записывает, поэтому, надеюсь, это не окажет большого влияния на производительность. Я бы предпочел зеркальное отображение, но это не поддерживается SQL Server Web Edition.
Всегда развертывайте веб-сайт на обоих серверах
Используйте DnsMadeEasy (dnsmadeeasy.com) для мониторинга первичного сервера и динамического переключения на вторичный, если первичный выйдет из строя
Запустите служебную задачу на вторичном сервере, которая отслеживает запись DNS каждую минуту. Если он указывает на вторичный, попробуйте запустить еще один запуск доставки журнала (в случае, если первичный веб-сервер не работает, но первичная БД все еще работает). И последнее, но не менее важное: отключите доставку журналов.
Что вы думаете? Есть ли более простой способ сделать это (кроме использования другой БД или облачного решения)?
Спасибо,
Адриан
Согласно информации о высокой доступности, расположенной Вот, единственный вариант для веб-версии - доставка журналов. (Репликация также не является вариантом, хотя я бы предложил это только в ограниченных случаях, потому что это очень навязчиво по отношению к схеме базы данных для приложения.)
При этом доставка журналов может быть отличной, если вы можете терпеть потерю данных на несколько минут.
«Автомат», однако, рискован. Следует помнить о некоторых вещах. Отработка отказа при доставке журналов не выполняется автоматически. «Сервер мониторинга» просто отслеживает, он не предпринимает никаких действий при возникновении проблемы. Кто-то или кто-то должен будет решить, что исходный сервер не работает и что базы данных на резервном сервере должны быть выведены из состояния восстановления. Вы могли бы написать программу для этого с риском, что это приведет к людям, или полагаться на людей, если у вас есть круглосуточный мониторинг, что делает пятиминутное окно простоя очень неудобным.
Какие бы задания у вас ни были (будь то «административные» вещи, такие как резервное копирование и переиндексация, или что-то особенное для вашего приложения), они должны существовать на обоих серверах, но они не должны выполняться при аварийном переключении, пока оно вам не понадобится. Если у вас много заданий, вам понадобится какой-то автоматический способ их включения / отключения. Совсем недавно была статья об этом, я не могу ее найти прямо сейчас, но вы сможете найти что-то, что даст вам идеи, немного погуглил.
То же самое для пакетов, связанных серверов и любых других вещей серверного уровня. Эти объекты всегда должны находиться на обоих серверах, и вы не можете «зарегистрировать» изменения этих объектов с первичного сервера на отказоустойчивый сервер. При сложных конфигурациях серверов сохранение идентичности на двух серверах может быть задачей, требующей значительного времени или некоторого программного обеспечения.
Вы должны убедиться, что имена входа, пароли и идентификаторы безопасности совпадают на обоих серверах. В противном случае ваше веб-приложение может не иметь доступа к базе данных на сервере аварийного переключения, когда оно запущено. Это проще, если вы используете безопасность домена для входа в приложение, потому что вам не нужно беспокоиться о SID. Если вы используете безопасность SQL Server, вам нужно быть более осторожным.
Основной сервер и сервер аварийного переключения будут иметь разные имена хостов. Вам понадобится способ изменить источники данных для вашего веб-приложения с SQLServer A на SQLServer B. Мы используем имена DNS C, поэтому мы можем обновлять запись в DNS, а не обновлять файлы на веб-сервере (ах). .
Естественно, вы хотите протестировать это, прежде чем вам это действительно понадобится.
Если у вас запланировано отключение для выпускаемых один раз в месяц исправлений Windows, вам следует интегрировать ручное переключение при сбое в процесс исправления серверов. Это минимизирует время простоя приложения, протестирует процесс отработки отказа и предоставит реалистичную информацию для тех, кто выполняет эту работу.
Вы, вероятно, больше раз будете отказываться для исправления окон и тому подобного, чем при сбое из-за реальной чрезвычайной ситуации.
Отказ вручную проверяет ваш процесс, поэтому вы знаете, сработает ли он в реальной чрезвычайной ситуации. Это также заставляет вас выполнить настройку доставки журналов в обратном направлении, что может занять значительное количество времени, если у вас большая база данных.