Возможно ли внедрить приложение ASP.NET для предприятия и изменения схемы SQL с нулевым временем простоя?

Ответ 1

Во-первых, вы, вероятно, не знаете о " момент восстановления времени. Достаточно долгое и то, что если вы правильно создаете резервные копии журналов транзакций, неважно, сколько времени потребуется для ваших резервных копий - у вас всегда есть возможность восстановить обратно в любой момент времени. Вы просто восстанавливаете свою последнюю резервную копию и повторно применяете журналы транзакций с тех пор, и вы можете получить восстановление вплоть до места развертывания.

То, что я хотел бы рекомендовать, - это переустановка веб-сайта с другим определением веб-сайта с настроенным "мертвым" заголовком хоста - это ваш сайт-постановщик. Создайте script, который запускает ваши изменения в базе данных сразу (в транзакции), а затем переворачивает заголовки хоста между сайтом live и промежуточным сайтом.

Ответ 2

Окружающая среда:

• Текущий веб-сайт в реальном времени
• Текущая база данных
• Новая версия веб-сайта (ов)
• Новая версия базы данных

подход:

• Настройте канал (например, репликацию, хранимую процедуру и т.д.), чтобы текущий сервер текущей базы данных отправлял обновления данных в новую версию базы данных.
• Измените свой маршрутизатор так, чтобы новые запросы указывали на новую версию веб-сайта, пока старые сайты больше не будут обслуживать запросы.
• Снимите старый сайт и базу данных.

В этом подходе отсутствует нулевое время простоя, поскольку и старый сайт, и новый сайт (и их соответствующие базы данных) разрешены для обслуживания запросов бок о бок. Единственный проблемный сценарий - это клиенты, у которых один запрос отправляется на новый сервер, а последующий запрос - на старый сервер. В этом случае они не будут видеть новые данные, которые могли быть созданы на новом сайте. Решением этого является настройка вашего маршрутизатора для временного использования липких сеансов и обеспечения того, чтобы новые сеансы переходили на новый веб-сервер.

Ответ 3

Одной из возможностей было бы использовать управление версиями в вашей базе данных.

Итак, у вас есть глобальная настройка, которая определяет текущую версию всех используемых хранимых процедур.

When you come to do a release you do the following:
1. Change database schema, ensuring no stored procedures of the previous 
   version are broken.
2. Release the next version of stored procedures
3. Change the global setting, which switches the application to use the 
   next set of stored procedures/new schema.

Сложная часть - это то, что вы не нарушаете ничего при изменении схемы базы данных.

Если вам нужно внести фундаментальные изменения, вам нужно либо использовать "временные" таблицы, которые используются для одной версии, прежде чем перейти к схеме, которую вы хотите в следующей версии, или можете изменить предыдущие сохраненные версии процедуры должны быть более гибкими.

Это должно означать почти нулевое время простоя, если вы можете это исправить.

Ответ 4

Во-первых, делайте регулярные небольшие изменения. Я работал независимым разработчиком в нескольких крупных инвестиционных банках в различных системах торговли в реальном времени 24/7, и самая лучшая, самая плавная модель развертывания, которую я когда-либо видел, была регулярной (ежемесячной) четко определенную стратегию отката каждый раз.

Таким образом, все изменения сведены к минимуму, ошибки исправляются своевременно, в разработке нет ползучести, и поскольку это происходит так часто, EVERYONE мотивирован, чтобы процесс развертывания был автоматическим и икотой насколько это возможно.

Но неизбежно возникают большие изменения схемы, которые делают откат очень сложным (хотя все же важно знать и тестировать - как вы будете откатываться, если вам нужно).

Для этих больших изменений схемы мы использовали модель "преодоления разрыва". То есть мы реализуем уровень преобразования базы данных, который будет работать почти в реальном времени, обновляя живую копию данных схемы нового стиля во второй базе данных на основе живых данных в в настоящее время развернутой системы.

Мы будем копировать это пару раз в день в систему UAT и использовать ее в качестве основы для тестирования (поэтому у тестеров всегда есть реалистичный набор данных для тестирования, а уровень трансформации тестируется как часть этого).

Итак, изменение в базе данных постоянно работает вживую, а развертывание новой системы - это просто случай:

• Заморозить всех
• Отключение слоя преобразования
• Включение нового уровня приложения
• Переключение пользователей на новый уровень приложения
• Отменить все

В этом случае откаты становятся чем-то вроде проблемы. Если новая система работает в течение часа, откат назад к старой системе непросто. Обратный слой преобразования был бы идеальным, но я не думаю, что мы когда-либо заставляли кого-либо покупать идею потратить на это время.

В конце концов, мы разворачивались в самый тихий период, чтобы заставить всех согласиться с тем, что откат приведет нас к точке переключения, и все, что вам нужно, нужно будет вручную переделать. Имейте в виду - это мотивирует людей правильно проверять материал:)

Наконец - как сделать слой преобразования - в некоторых более простых случаях мы использовали триггеры в самой базе данных. Только однажды я думаю, что мы перенесли код в предыдущий выпуск, который сделал "двойные обновления", исходное обновление текущей системы и другое обновление для новой схемы стиля. Цель состояла в том, чтобы выпустить новую систему в следующем выпуске, но тестирование выявило необходимость в настройках базы данных, и "уровень трансформации" был в производстве на тот момент, так что процесс стал беспорядочным.

Модель, которую мы чаще всего использовали для слоя преобразования, была просто очередным процессом сервера, наблюдающим за базой данных и обновлением новой базы данных на основе любых изменений. Это хорошо работает, так как этот код работает вне производства, его можно изменить по своему усмотрению, не влияя на производственную систему (хорошо - если вы используете репликацию производственной базы данных, но в противном случае вы должны следить за тем, чтобы не связывать производство база данных с некоторыми суицидальными запросами - просто поставьте лучших самых добросовестных ребят в эту часть кода!)

В любом случае - извините за долгий ход - надеюсь, что я передумал, - постоянно развертывайте развертывание базы данных как "живое, запущенное" развертывание во вторую базу данных, тогда все, что вам нужно сделать для развертывания новой системы, - это развернуть прикладной уровень и передать ему все.

Ответ 5

Я бы рекомендовал использовать Analysis Services вместо механизма базы данных для ваших потребностей в отчетах. Затем вы можете обработать свои кубы.. переместите свою базу данных.. измените строку соединения, переработайте свои кубы и, таким образом, получите нулевое время простоя.

Мертвый серьезный... В мире нет лучшего продукта, чем Analysis Services для этого типа вещей.

Ответ 6

Как вы говорите, у вас нет проблем с покупкой нового сервера, я предлагаю, что лучшим способом было бы получить новый сервер, который сначала будет развертывать ваше приложение. Выполните следующие шаги:
1. Добавьте все сертификаты, если это требуется на этот новый сервер, и протестируйте приложение с новыми настройками.
2. Завершите работу старого сервера и назначьте его IP новому серверу, время простоя будет таким же, как и ваш сервер, чтобы завершить работу и назначить новый IP-адрес новому серверу.
3. Если вы видите, что новый Deploy не работает, вы всегда можете вернуться назад, повторив шаг 2.
Что касается резервного копирования базы данных, вам нужно будет установить расписание резервного копирования.

Ответ 7

Я видел этот пост некоторое время назад, но никогда не использовал его, поэтому не могу ручаться за простоту использования/пригодности, но у MS есть бесплатная среда для развертывания веб-ферм, которая может вам подойдет:

http://weblogs.asp.net/scottgu/archive/2010/09/08/introducing-the-microsoft-web-farm-framework.aspx

Ответ 8

См. мой ответ здесь: Как развернуть приложение ASP.NET с нулевым временем простоя

Мой подход заключается в использовании комбинации опроса AppDomains и именованного мьютекса для создания атомарного агента развертывания.

Ответ 9

Я просто ответил на аналогичный вопрос: Разверните веб-сайт ASP.NET и обновите базу данных MSSQL с нулевым временем простоя

В нем обсуждается, как обновлять базу данных и веб-сайт IIS во время развертывания с нулевым временем простоя, главным образом, гарантируя, что ваша база данных всегда обратная совместимость (но только до последней версии приложения).