Пошаговый план как перенести веб-проект с 2.5 Тб данных на новый сервер с простоем до 30 минут (Битрикс 24 и не только)

Недавно мы в Инитлаб закончили переезд со старого сервера на CentOS 7 на новый сервер на CentOS 9 одного из самых крупных внедрений Битрикс 24 в России. В системе одновременно работает до 500 пользователей, размер базы данных превышает 1 Тб, а объем файлов в хранилище документов -- 1,5 Тб. Рассказываю как мы сделали миграцию с простоем всего не более 30 минут.

Заказчик обратился с просьбой ускорить работу CRM Битрикс 24, сотрудники жаловались на медленную работу. Мы провели профилировку на боевом сервере, аудит кода узких мест, поставили сервер на мониторинг и собрали данные о нагрузке. Почти все найденные способы оптимизации включали в себя или переписывание стандартного функционала, или уменьшение объема БД за счет архивирования старых документов. Ни то ни другое не давало быстрого прогнозируемого результата и не подходило заказчику. Рассматривали также варианты выноса базы данных на отдельный сервер, построения кластера веб-серверов из имеющихся у заказчика серверов. В итоге после анализа затрат было решено обновить железо переехав на один новый более мощной сервер с удвоенным количеством ядер и NVME RAID вместо SSD RAID. Последний переезд на новый сервер заказчика силами его собственного ИТ-отдела вызвал простой в работе компании более суток. Так как у нас большой опыт переездов больших проектов, то получилось успешно переехать с простоем не более 30 минут. Чтобы минимизировать простой мы используем следующие технологии и шаги работы:

1. Настраиваем временный прокси сервер и переключаем DNS на него. Прокси позволяет быстро переключить трафик на новый сервер, не дожидаясь обновления DNS у пользователей. А также, что немало важно, быстро переключить трафик обратно на старый сервер если что-то пойдет не так )

2. Настраиваем и оптимизируем новый сервер под нужный стек технологий на основе наших шаблонов конфигураций Ansible. В данном случае был CentOS 9 с Nginx, PHPFPM, MariaDB, Битрикс 24. Для тюнинга параметров базы данных используем Releem.

3. Заливаем последнюю резервную копию базы данных и копируем файлы на новый сервер. В данном случае это заняло более суток.

4. Тестируем работу на новом сервере, исправляем проблемы, возвращаем базу данных и файлы в исходное до тестов состояние.

5. Настраиваем репликацию Master / Slave между БД старого сервера и нового соответственно. Новый сервер начинает подкачивать изменения с боевой базы так как пользователи продолжают все это время работать на старом сервере. Синхронизируем файлы с помощью rsync.

6. В оговоренное время останавливаем работу старого сервера. Дожидаемся синхронизации БД и файлов. Меняем местами базы данных Master и Slave в настройках репликации. Переключаем трафик на прокси на новый сервер.

7. С помощью прокси мониторим, что весь трафик пошел на новый сервер. Если все ок, то отключаем старый сервер. Переключаем DNS на новый сервер. Когда видим что через временный прокси трафик уже не идет, отключаем его.

По такой схеме большинство веб-проектов мы переносим вообще практически без простоя. А в случаях особо сложных архитектур или большого объема данных простой минимальный. Схожий подход используем при миграции проектов в кластер Kubernetes, при переезде в облако и т.д.

Одним из наших ноухау, позволяющих быстро мигрировать, являются собственные скрипты бекапов для резервного копирования и восстановления базы данных из копии. Работают они на больших базах данных в ~10 раз быстрее штатных механизмов бекапов Битрикс 24. Поэтому используем не только при миграциях, но и для ежедневных бекапов.