В разных ситуациях обновлять ядро 1С-Битрикс можно с разной степенью «вольности». Одно дело, если на сайте идёт поток из 100 посетителей в сутки и мы можем на пару-тройку часов закрыть проект на «техобслуживание». Совсем другое – если мы должны обеспечить гарантированный и незаметный для пользователей переход.
Подготовительные действия
1. Первым делом обновление ядра выполняется на отдельной площадке, после чего тестировщики проводят полное регрессионное тестирование (примечание редакции: регрессионное тестирование – то есть тестирование всего существующего функционала, а не только новых возможностей, добавляемых обновлением). Начинать обновление в продуктивной среде нельзя, пока не будет гарантий работоспособности обновленного продукта. Это хороший сценарий.
Более реалистичный и грустный случай, который можно встретить на большинстве проектов: вся проектная команда состоит из одного разработчика. В такой ситуации разработчику необходимо выполнить обновление где-нибудь, например локально, после чего самостоятельно примерить на себя роль тестировщика. Для того, чтобы разработчик не упустил чего-либо, желательно заранее составить подробный тест-план и проставлять «галочки» напротив выполненных тестов.
Этот шаг является обязательным. Каким бы незначительным ни был проект, посетители не должны знать что ведутся работы. И тем более наблюдать ошибки.
2.Обновление продуктивной среды следует запланировать на период с 3 до 5 ночи по местному для проекта времени. Практика показывает, что это время наибольшего спада посещаемости. Даже проекты с десятками миллионов хитов в сутки в это время могут практически простаивать.
3. Следует обеспечить отключение всех значимых фоновых процессов в это время. К таким процессам могут относиться импорты, экспорты, плановое резервное копирование, генерация отчетности и прочее. Если от процесса нельзя отказаться даже на одну ночь, то необходимо сдвинуть его на более раннее или более позднее время.
4. Перед началом работ по обновлению необходимо сделать полную резервную копию проекта. Следует обязательно убедиться, что копия является целостной. Для этого сразу же после создания копии требуется ее где-нибудь развернуть. Желательно всегда использовать для резервного копирования специализированные инструменты, которые имеют встроенную функциональность проверки целостности.
Предварительные работы
1. На доступных аппаратных ресурсах поднимается новый параллельный экземпляр MySql. Отмечу особо: не новая база данных в рамках существующего экземпляра (процесса), а именно отдельный экземпляр MySql. Далее для краткости, новый экземпляр будет обозначен как DB2, а оригинальный — DB1.
Под доступными ресурсами подразумевается либо аппаратный резерв (лучший случай), либо те же продуктивные ресурсы (ночью они не должны быть загруженными), либо ресурсы инфраструктуры разработки и тестирования (плохой случай), либо даже локальная машина разработчика (ужасный случай, только для маленьких проектов, обязательно нужен постоянный внешний IP).
2. Между DB2 и DB1 настраивается репликация master-master в режиме mixed.
3. На тех же доступных ресурсах размещается копия продуктивных файлов и настраивается веб-сервер.
4. Между продуктивной (далее FS1) и новой (далее FS2) файловыми системами настраивается односторонняя синхронизация: копия файловой системы (FS2) через короткий промежуток времени обновляется продуктивными изменениями (FS1) с помощью rsync или csync2.
Таким образом, на некоторый промежуток времени создается полный близнец продуктивного сайта, который в реальном времени обновляется продуктивными данными.
Этап перераспределения нагрузки
1. На уровне front-end веб-сервера в качестве back-end веб-сервера указывается близнец. Таким образом, нагрузка полностью снимается с продуктивной среды и перенаправляется на временную копию.
Так как дело происходит ночью и посещаемости почти нет, даже очень ограниченные ресурсы способны обслуживать продуктивную нагрузку без перебоев.
2. В DB2 выполняется команда STOP SLAVE, что превращает схему репликации в master-slave, причем в качестве мастера выступает DB2.
3. Файловая синхрониация между FS1 и FS2 разрывается.
Таким образом, вся продуктивная нагрузка обрабатывается временной копией проекта (близнецом), продуктивные ресурсы готовы для безболезненного проведения любых работ, при этом продуктивная база данных (DB1) обновляется в реальном времени, то есть, результат действия пользователей не теряется.
Заключительный этап
1. Штатными средствами выполняется обновление ядра Битрикс.
2. Силами доступных специалистов оперативно производится smoke test.
3. Если критических проблем не выявлено, то нагрузка вновь переключается на продуктивную среду.
4. Производится проверка статуса репликации между DB2 и DB1, если в какой-то момент времени она сломалась (что возможно из-за изменения структуры таблиц), то binlog анализируется с заданной позиции, проблемные запросы корректируются вручную (их будет немного, если будут вообще) и выполняются в продуктивной базе данных.
5. С помощью rsync в режиме dry-run получается список файлов, которые были добавлены или изменены в период перераспределенной нагрузки. Этот (короткий) список просматривается и отфильтровывается вручную, после чего нужные файлы, если такие обнаружатся, вручную переносятся в продуктивную среду.
Резюме
Такой подход к процессу обновления ядра:
- отлично подходит для небольших проектов (до 100 000 запросов к backend в сутки);
- обеспечивает окно в несколько часов для проведения работ по обновлению в спокойном режиме;
- гарантирует отсутствие потери данных, ошибок, аварий и простоев в работе проекта;
- предоставляет безаварийные возможности к отступлению (откат обновления).
Главный минус такого подхода — бессонная ночь.
