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

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

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

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

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

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

Выводы

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

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

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

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

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

Установка, настройка и использование RabbitMQ

Интернет версии Веб 2.0 начал активно развиваться в начале 21 века, с появлением новых сайтов и веб-приложений. Используя синхронные вызовы,...
Read More

Node.js простыми словами: что это, плюсы и минусы

Асинхронное программирование необходимо для управления устройствами умного дома, создания соцсетей и онлайн-чатов, а также разработки игр. Оно позволяет обрабатывать задачи...
Read More

Мониторинг дисковой подсистемы в Zabbix

Стабильная работа серверов играет важную роль в бизнес-процессах. Сбой в работе сервера может привести к серьезным последствиям: от потери данных...
Read More

О методологии CI/CD простыми словами — принципы, этапы, плюсы и минусы

Подход CI/CD в последнее время много обсуждается в IT. Он часто используется для создания приложений или разработки облачных решений. Но...
Read More

Разбираемся с IP: адреса, маски и маршруты

Сетевые технологии — это неотъемлемая часть любого современного бизнеса и повседневной жизни. Будь то работа в офисе или использование интернета...
Read More

Хостинг Майнкрафт

Minecraft — это культовая игра-песочница, в которой игроки могут строить, исследовать, выживать и создавать свои уникальные миры из блоков. Однако...
Read More

Российские ОС для серверов: какие решения лучше подходят для корпоративной инфраструктуры?

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

Какую российскую ОС выбрать для бизнеса

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

Что такое Grafana

У современной компании есть тысячи различных показателей, которые она получает из различных источников. Grafana ― это программа, которая может объединить...
Read More

Что такое бизнес-аналитика

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