Вступление
В данном посте я расскажу как происходит у нас обновление программного комплекса в организации.
Наша организация предоставляет некие услуги в круглосуточном формате и процесс обновления наших программ, баз данных стоит очень остро, т.к. время простоя системы без работы очень критично и ведет к потери денег наших клиентов. Поэтому я решил поделится с читателим тем что у нас есть и выслушать все комментарии, критику и предложения по улучшению данного процесса и уменьшению времени простоя работы системы в целом.
У нас установлено у провайдера в стойке два сервера IBM x3550 (один рабочий основной, второй тестовый зеркальный). На серверах установлены Windows Server 2008 R2.
Программный комплекс состоит из:
- БД на MS Sql Server 2008 R2 с настроенным зеркалом на второй сервер;
- Несколько серверных программ, разработкой которых и занимаемся сами;
- IIS для сайтов и веб-сервиса.
Основная проблема и её решение
Так вот основная проблема которая меня мучает — это процесс обновления всех наших компонентов системы (баз данных, программ). Когда я пришел работать в данную организацию, процесс обновления мог занимать от 15 минут до 30-60 минут (в зависимости от разных причин: ошибок программистов, тормозов системы и т.д.). Основным времени простоя был запуск наших программ, которые стартовали иногда ну очень долго.
Потом купили второй сервер и сразу решил для сохранения важных данных (это как я решил БД) настроить зеркало на второй сервер. Настроил и подумал, что задействовав второй резервный сервер будем обновлять через него. Но не тут-то было, зеркальная база вообще недоступна, даже для чтения.
Наш сценарий обновления
Чтобы сократить время простоя наших сервисов во время обновления я настроил следующую схему проведения обновлений (и как я думаю она замороченная). Настроил два сервера идентично между собой, чтобы их можно было менять местами и не надо было ничего дополнительно делать, чтобы наши сервисы работали одинаково как на основном так и на резервном (выполняя только отработку отказа в MS SQL), для этого настроил одинаково IIS и брандмауэр.
А дальше когда время подходит обновления происходит следующее:
- Выполняется отработка отказа баз данных настроенных как зеркальные;
- На втором сервере проводится обновление над базами данных и потом происходит запуск наших программ;
- После запуска у серверов меняются IP адреса между собой;
- После этого выполняются обновления программных продуктов на основном сервере;
- В заключении выполняется опять шаги 1, 2 и 3;
Результат
С помощью данной схемы мне удалось сократить время простоя наших сервисов с 15-60 минут до 7-15 минут. В среднем получается время простоя два раза по 5 минут.
Заключение
Я понимаю, что схема очень замороченная, трудоемкая и сложная. Но пока мы обновляемся именно так. Обновляться по той схеме как было до меня и, допустим, перенести время обновления на ночь, тоже вариант не очень. Т.к. после обновления возможны проблемы в работе системы и нужны программисты, чтобы исправить эти ошибки сразу же. Вызывать на такси ночью — это время простоя которое может потом исчисляться часами. Вызывать сразу к обновлению программистов для подстраховки — это тоже не выход, т.к. нарушится их ритм работы и отразится на качестве их кода.
Возможные варианты решения
Есть у меня идея перейти на репликацию слиянием, чтобы была доступны базы на втором сервере, проводить обновление на втором сервере и менять их местами потом: это уменьшит время простоя, но это прибавит проблем с самой репликацией и работой базы данных, т.к. возможны будут конфликты.
Очень хочу найти хорошее, несложное решение обновления, желательно без замены серверов, чтобы можно было не думать о других сторонних сервисах, как корпоративная почта, портал Sharepoint и т.д. Охотно выслаушаю предложения. Поможет ли решить мою проблему третий сервер в стойке?
Автор: djonik1562
