Перенос крупного проекта на мощности REG.RU: как сохранить нервы технического директора

К нам часто обращаются заказчики с просьбой выполнить перенос их текущих проектов на новый сервер. Если речь идёт о нескольких типовых сайтах, то в этом случае трудностей не возникает. Однако бывают запросы на перенос очень крупных и сложных архитектур. Мы расскажем, с чем пришлось столкнуться в процессе такого переноса и каких типовых ошибок стоит избегать.

Предыстория и постановка задачи

Началось всё с того, что к нам обратилось крупное сетевое IT-издание с задачей по переносу своих данных на новые серверы. От нас требовалось выполнить максимально бесшовный перенос всех проектов на мощности REG.RU. То есть, ни сотрудники, ни клиенты заказчика не должны были столкнуться с какими-либо сбоями, связанными с перемещением данных на новые серверы.

Возможно, вы спросите, зачем вообще может понадобиться переносить данные? Причин может быть много: новые требования к оборудованию, желание сменить провайдера, недовольство уровнем отказоустойчивости ЦОД, необходимость модернизации архитектуры, сайта или самой компании. В нашем случае произошло разделение компании-заказчика, из-за чего пришлось переносить проекты на другие серверы, обновлять кодовую базу и организовывать новую надёжную инфраструктуру.

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

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

Исходя из требований отказоустойчивости мы решили максимально зарезервировать мощности. Мы выбрали два сервера с абсолютно одинаковыми конфигурациями, а дисковое пространство организовали двумя пулами носителей. Первый пул состоял из программного массива дисков SSD, второй — из программного массива HDD. Это решение соответствовало требованиям скорости работы дисковой подсистемы, поскольку серверы баз данных требовательны к быстродействию дисков, в то время как для хранения статики нужен большой объём памяти. SSD стоят довольно дорого, и мы использовали более медленные диски для организации хранения статических данных. Сетевые интерфейсы были также зарезервированы при помощи агрегации — то есть каналы связи дублировались для того, чтобы обрыв провода, выход из строя порта коммутатора или сетевой карты не прерывали работу серверов.

С чем мы столкнулись при анализе проекта

Поначалу нам показалось, что перенос не будет слишком сложным. Однако проект имел долгую историю, и сам заказчик не представлял полный объём задач. Дополнительной трудностью стало то, что сайт использовал устаревшее программное обеспечение. Для его переноса нам пришлось привлечь разработчиков со стороны заказчика, чтобы выполнить первичный запуск.

От использования панели управления сервером пришлось отказаться, так как она препятствовала правильному резервированию (то есть копированию данных с одного сервера на другой). К тому же, само техническое задание не предполагало, что мы предоставим специалистам заказчика функционал по администрированию программно-аппаратного комплекса.

Самым сложным оказалось составление списка подлежащих к переносу веб-проектов, баз данных и программного окружения. Сложность была обусловлена политикой безопасности компании-заказчика и закрытым доступом к текущей системе. Из-за этого специалисты REG.RU не могли досконально проанализировать все настройки сервера и сразу понять, как перенести их и где могут возникнуть трудности.

После предварительного анализа и переговоров мы пришли к выводу, что требуется перенести порядка 20 баз данных, 20 веб-проектов, два сервиса поиска и более 1 ТБ файлов статической информации. В итоге мы разделили первичный перенос проекта на 5 этапов:

1. Построение и тестирование архитектуры;
2. Перенос с сервера на сервер статической информации;
3. Перенос сервера базы данных SQL и настройка репликации между серверами;
4. Перенос вспомогательных веб-проектов и настройка программного окружения;
5. Перенос основного сайта компании.

Все данные переносились на выделенные серверы REG.RU.

Перенос проекта: друг за другом, шаг за шагом

Первый этап — построение и тестирование архитектуры — прошёл достаточно легко. У нас богатый опыт планирования архитектур, поэтому настройка и тестирование заняли пару дней. 

Перенести статическую информацию (второй этап) оказалось тоже нетрудно. Мы использовали стандартную настройку CDN с регламентированным доступом для обновления информации и транслирования видео-контента. 

С переносом базы SQL на другой сервер всё оказалось сложнее, поэтому этот этап мы разбили на три шага:

1. установка серверов баз данных;
2. настройка репликации серверов;
3. первичный перенос данных.

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

Затем был трудный и тернистый четвёртый этап — запуск сопутствующих веб-проектов. Сложность заключалась в устаревшей кодовой базе — пришлось параллельно обновлять ПО проектов до новых версий и переносить их по одному. Это растянуло процесс, но позволило сделать его незаметным для пользователей и клиентов заказчика.

К последнему этапу (перенос основного сайта) мы приступили с уже настроенной конфигурацией программного обеспечения. Заказчик остался доволен нашей работой, поскольку всё было выполнено гладко и соответствовало заявленному ТЗ.

В итоге весь перенос проекта занял несколько месяцев — такой срок обусловлен обновлением кодовой базы со стороны заказчика. При идеальном раскладе — то есть, если бы у нас изначально были полные сведения о проекте и доступ к системе, а у заказчика была актуальная кодовая база, — перенос занял бы три-четыре дня.

Выводы

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

При этом перенос сервера на другую машину или к другому провайдеру нужно планировать заранее, лучше за несколько месяцев. Обязательно уточните количество узлов, серверов, задействованных в работе проекта, версии ПО и схему текущей настройки. На сам перенос со всеми согласованиями закладывайте время с запасом — не менее двух недель.

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

Не стоит одновременно выполнять переделку проекта — лучше сначала обновить систему и только после этого переносить её на новые серверы.

И, конечно, нужно понимать, что как бы вы не старались всё-всё учесть, всё равно могут возникнуть какие-либо препятствия. И это нормально — масштабные задачи не обходятся без трудностей и ошибок. Главное — быть готовыми к ним и доверить работу профессионалам, которые могут быстро анализировать и решать любые сложности.