У меня есть веб-приложение на IIS7 с SQL Server 2008 в качестве СУБД.
Также необходимо получить нулевое время простоя во время будущих обновлений кода ASP.NET и схемы БД. Мне нужно найти правильный сценарий для этого.
У меня есть 2 веб-сервера и 2 сервера sql и один балансировщик нагрузки http, который позволяет переключать внутренний веб-сервер для веб-запросов.
Основная цель - запустить и запустить 1-й веб-сервер и сервер БД, обновить код и схему базы данных на 2-м сервере, а затем переключить все запросы на 2-й сервер, а затем основная проблема - как скопировать данные из 1-й базы данных 2-й (которая была изменена во время Обновить).
Это зависит от вашего определения «нулевого времени простоя». Сценарий «разделение-> обновление-> отказоустойчивость-> восстановление» может быть довольно легко реализован путем настройки репликации между двумя вашими серверами SQL, что также дает вам преимущество избыточности. .
Это работает очень похоже на то, что вы описали выше: когда вы выполняете обновление, вы разделяете свою пару репликации и обновляете один из них (вместе с несколькими серверами приложений), переключаете нагрузку на обновленный набор машин, затем обновляете другие и повторно -установить репликацию. Предостережение: вам, вероятно, все равно придется прекратить принимать изменения (вставки / обновления) во время окна обновления (по крайней мере, до тех пор, пока обновленные серверы не будут запущены), в противном случае вы получите сценарий с разделенным мозгом, когда у вас есть изменения в «старой» системе, которые будут потеряны в «новой» " один.
В зависимости от типа изменений схемы, о которых вы говорите, и от того, насколько хорошо написано ваше приложение, вы можете вносить некоторые изменения без простоев (добавление новых таблиц / представлений, добавление столбца и т. Д. Часто можно выполнить без простоя. при условии, что ваше приложение не волнуется при изменении количества столбцов в таблице).
Я предлагаю вам настаивать на адекватных окнах обслуживания для всех изменений / обновлений, включая время простоя, если это необходимо. Очень немногие системы должны быть действительно 24x7x365, и если вы столкнетесь с неожиданной проблемой, всегда лучше, чтобы система была отключена и у вас было достаточно времени, чтобы исправить проблему или отменить свои изменения, чем спешить с исправлением с разгневанными пользователями дышать тебе в шею, потому что они не ожидали отключения электричества ...