В любой среде, где учитывается время простоя, вы наверняка используете какой-нибудь кластер серверов для повышения надежности за счет избыточности. Я бы вынул хост из кластера, обновил его, а затем выбросил обратно в кластер. Если у вас есть обновление, которое не может работать в смешанной среде (например, для БД требуется несовместимое изменение схемы), вам придется закрыть весь сайт, по крайней мере, на мгновение. Хитрость заключается в том, чтобы вызвать процессы замены, прежде чем бросать оригиналы.
Используя tomcat в качестве примера - вы можете использовать CATALINA_BASE, чтобы определить каталог, в котором будут найдены все рабочие каталоги tomcat, отдельно от исполняемого кода. Каждый раз, когда я развертываю программное обеспечение, я развертываю в новый базовый каталог, чтобы у меня мог быть новый код, находящийся на диске рядом со старым кодом. Затем я могу запустить другой экземпляр tomcat, который указывает на новый базовый каталог, запустить и запустить все, а затем заменить старый процесс (номер порта) на новый в балансировщике нагрузки.
Если меня беспокоит сохранение данных сеанса через коммутатор, я могу настроить свою систему таким образом, чтобы у каждого хоста был партнер, на которого он реплицирует данные сеанса. Я могу отбросить один из этих хостов, обновить его, вернуть его обратно, чтобы он восстановил данные сеанса, а затем переключить два хоста. Если у меня есть несколько пар в кластере, я могу отбросить половину всех пар, затем выполнить массовое переключение, или я могу сделать их по паре за раз, в зависимости от требований выпуска, требований предприятия и т. Д. Лично, однако, я предпочитаю просто позволить конечным пользователям страдать от очень частой потери активного сеанса, а не пытаться выполнить обновление с сохранением сеансов.
Это все компромисс между ИТ-инфраструктурой, сложностью процесса выпуска и усилиями разработчика. Если ваш кластер достаточно большой и ваше желание достаточно сильное, то достаточно легко спроектировать систему, которая может быть заменена без простоев для большинства обновлений. Большие изменения схемы часто приводят к фактическому простою, поскольку обновленное программное обеспечение обычно не может вместить старую схему, и вам, вероятно, не удастся скопировать данные в новый экземпляр БД, выполнить обновление схемы, а затем переключить серверы на новый БД, поскольку вы будете пропускать любые данные, записанные в старую после того, как из нее будет клонирована новая БД. Конечно, если у вас есть ресурсы, вы можете поручить разработчикам модифицировать новое приложение, чтобы использовать новые имена таблиц для всех обновляемых таблиц, и вы можете установить триггеры на действительной базе данных, которая будет корректно обновлять новые таблицы с данными как он записывается в старые таблицы предыдущей версией (или может использовать представления для эмуляции одной схемы из другой). Поднимите свои новые серверы приложений и поменяйте их местами в кластере. Существует множество игр, в которые вы можете играть, чтобы минимизировать время простоя, если у вас есть ресурсы для их создания.
Возможно, самый полезный механизм сокращения времени простоя при обновлении программного обеспечения - это обеспечение того, чтобы ваше приложение могло работать в режиме только для чтения. Это предоставит пользователям необходимую функциональность, но предоставит вам возможность вносить изменения в масштабе всей системы, которые требуют изменений в базе данных и тому подобное. Переведите ваше приложение в режим только для чтения, затем клонируйте данные, обновите схему, подключите новые серверы приложений к новой базе данных, затем переключите балансировщик нагрузки для использования новых серверов приложений. Ваше единственное время простоя - это время, необходимое для переключения в режим только для чтения, и время, необходимое для изменения конфигурации вашего балансировщика нагрузки (большинство из которых может справиться с этим без какого-либо простоя вообще).