Поиск по сайту Поиск

Перенос крупного проекта на мощности 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. первичный перенос данных.

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

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

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

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

Выводы

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

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

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

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

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

10 лучших IDE и редакторов кода для веб-разработчиков

10 лучших IDE и редакторов кода для веб-разработчиков

Писать код при желании можно и в текстовом редакторе — ничто не мешает вам создать простейший сайт в «Блокноте», сохранив...
Read More
Domains weekly: .РФ на страже русского языка, рост new gTLDs и пассивный доход от PORNO.COM

Domains weekly: .РФ на страже русского языка, рост new gTLDs и пассивный доход от PORNO.COM

В новой подборке новостей мы расскажем, как развивался русский язык вместе с зоной .РФ, что за риски таит в себе...
Read More
VPS нового поколения, ИИ, юникодные домены и мини‑сериал об админах: всё, что вы знали и чего могли не знать о REG.RU

VPS нового поколения, ИИ, юникодные домены и мини‑сериал об админах: всё, что вы знали и чего могли не знать о REG.RU

Ура-ура! 22 мая нам исполнилось 14 лет, и мы по-прежнему двигаемся только вперёд и становимся лучше. Мы решили поделиться с...
Read More
Domains weekly: старт .MEET от Google, годовой рост .RU и .РФ, вирусная реклама рэп‑альбома с new gTLDs

Domains weekly: старт .MEET от Google, годовой рост .RU и .РФ, вирусная реклама рэп‑альбома с new gTLDs

В новой еженедельной подборке новостей расскажем о старте регистраций в зоне  .MEET от Google, вирусной рекламной кампании нового рэп-альбома Future...
Read More
Как скорость загрузки страниц на мобильных устройствах влияет на посещаемость сайта

Как скорость загрузки страниц на мобильных устройствах влияет на посещаемость сайта

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

Популярные уязвимости сайтов: чем опасны и как их избежать

Для любого, кто управляет веб-сайтом, на первом месте должен стоять вопрос безопасности. Критические угрозы и уязвимости могут сильно ударить как...
Read More
Domains weekly: 10 лет .РФ, новый топ регистраторов в .COM и спор за ягодный домен

Domains weekly: 10 лет .РФ, новый топ регистраторов в .COM и спор за ягодный домен

В свежей подборке новостей расскажем о юбилее .РФ, отчёте ICANN о динамике регистраций в зоне .COM и неудачной попытке канадской...
Read More
С днём рождения, .РФ!

С днём рождения, .РФ!

В этом году кириллической национальной российской доменной зоне исполняется 10 лет. Мы решили вспомнить, как всё начиналось: в этом материале...
Read More
Domains weekly: стагнация ccTLD, конец страстей по .ORG и взлом клиентов GoDaddy

Domains weekly: стагнация ccTLD, конец страстей по .ORG и взлом клиентов GoDaddy

В сегодняшней подборке новостей расскажем, как изменилось число регистраций национальных доменов по сравнению с прошлым годом, чем закончилась сделка с...
Read More
Как поменять домен, чтобы сайт не просел в поисковой выдаче

Как поменять домен, чтобы сайт не просел в поисковой выдаче

Итак, вы решили изменить имя своего сайта после ребрендинга или просто выбрали более короткий домен. Но как при этом сохранить...
Read More