Массовая миграция клиентов между хостинг-провайдерами: боремся с энтропией в промышленных масштабах

В жизни любого хостинг-провайдера перенос клиентов между собственными серверами – задача достаточно обыденная. Для подобного переноса может быть множество причин: начиная с планового апгрейда оборудования или софта и планового «перераспределения» клиентов в связи с неравномерной загрузкой серверов, заканчивая срочным перемещением пользователей в случае аварий.

Реже в жизни провайдеров возникают задачи по переносу клиентов от другого провайдера shared-хостинга.
Причиной такого переноса может быть как «усталость» хостера-«донора» от подобного высокотехнологичного бизнеса, так и вынос услуг хостинга на аутсорсинг в более крупную хостинг-компанию в случае, если оказание этих услуг не является для решившейся на перемены организации профильным бизнесом (например, если речь идет о веб-студии, интернет-провайдере, провайдере сервис-услуг и т.д.).
Количество потенциальных проблем при переносе клиентов между разными провайдерами намного больше, нежели при переносе внутри одного хостинг-провайдера. Это связано с тем, что инфраструктура «старого» и «нового» провайдера может значительно отличаться:

• Используются разные биллинг-панели;
• Используются разные панели управления хостингом;
• Разные версии PHP / других интерпретаторов с разными настройками;
• Разные режимы запуска скриптов (fastcgi vs mod_something);
• Разные настройки веб-серверов;
• Разная схема включения веб-серверов (с использованием / без использования frontend);
• Разные настройки и различия в политике безопасности;
• Разные пути в системе к сайтам и к внешним утилитам;
• Разные почтовые серверы и схемы отправки почты (отправка на 25 порт vs вызов sendmail).

При этом, полностью копировать чужую инфраструктуру, которая может оказаться неоптимальной или имеющей какие-либо ограничения, не хочется. Даже если исходная инфраструктура качественная и интересная, нет смысла плодить «зоопарк» — можно разве что позаимствовать интересные находки, чтобы в будущем внедрить их у себя. Таким образом, обычно приходится переносить сайты в совершенно новое окружение и отображать «чужую» инфраструктуру на «свою».

Существуют ещё и различные потенциальные «нестыковки» из реальной жизни, учитывающие возможности небольших хостинг-провайдеров:

• Разные опции и разное количество ресурсов на тарифных планах (1:1 тарифы не стыкуются почти никогда);
• Разные клиенты одного хостера могут жить в разных хостинговых / биллинговых панелях, а часть клиентов, вообще могут быть заведены «в Excel'е», а их оплата отслеживаться вручную (разумеется, часть такой информации может быть не актуальна);
• Сайты, которые физически есть на серверах, но отсутствуют в биллинге;
• Одни и те же клиенты могут дублироваться на разных физических серверах. Например, если клиент переносился с сервера на сервер, а со старого сервера его удалить забыли;
• Разные сайты одного и того же хостингового клиента (имеющего единственный аккаунт в хостинговой панели) могут обслуживаться на разных серверах;
• Прочие экзотические варианты, которые надо как-то разруливать.

Естественно, со всем этими проблемами нам приходится иметь дело и как-то их разруливать. При этом, нужно делать это так, чтобы никто из клиентов «не пострадал»: ничьи сайты не «упали», а тарифные условия не ухудшились. В общем, чтобы был «никто не забыт и ничто не забыто» и, при этом, всё продолжало работать.

Фактически в таком случае нужно решать три задачи:

• Отображать чужую инфраструктура на свою, так чтобы всё продолжало работать;
• «Наводить порядок», устраняя все возможные нестыковки и избавляясь от технологического хаоса;
• Минимизировать даунтаймы при переносе.

В этой обзорной статье я постараюсь рассказать, как эти задачи решаются в REG.RU.
Обычно процесс состоит из нескольких технологических, организационных и информационных этапов:

1. Уведомление клиентов о предстоящем переносе:
а) Новость на сайте хостера;
б) Новость на сайте REG.RU;
в) Пресс-релиз;
г) Рассылка клиентам о предстоящем переносе;
д) Пауза 1-2 недели. Это делается для того, чтобы те, кто не хочет переноситься, могли заявить об этом или самостоятельно перейти к другому хостинг-провайдеру.

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

2. Техническая подготовка к переносу.
2.1. Составление базы клиентов и услуг для переноса:
а) Читаем и приводим к единому формату данные из биллинговых панелей (которых может быть несколько);
б) Собираем данные из прочих источников (клиенты без биллинга);
в) Среди просроченных хостингов, но ещё физически не удалённых, вычленяем клиентов, которые фактически уже не пользуются хостингом и которых переносить не имеет смысла, скорее всего хостинг они уже не продлят.
Можно было бы, скажем, проверить делегированность домена на IP хостинга, но не всё так просто – существуют ситуации, когда:

• Клиент забыл продлить домен, хотя планирует пользоваться услугами;
• Клиент использует хостинг только для почты (тогда надо смотреть только MX);
• Клиент использует хостинг для хранения каких-то личных файлов;
• Клиент использует хостинг для тестов или какого-то обучения и при этом не использует домен (для доступа к сайту редактирует hosts).

Так что, в идеале — нужно смотреть по логам, есть ли / были ли реальные заходы на сайт.

Цель этапа – составление точного списка клиентов и услуг для переноса, включая услуги регистрации доменов. Кроме того, необходимо собрать все данные для биллинга, включая контактные данные клиентов, информацию об остатках на счетах, об оплаченных услугах и периодах их оплаты, а также о тарифах и тарифных опциях услуг, имеющих отношение к биллингу.

2.2. Внесение данных о клиентах и их услугах в базу биллинга:
а) Генерация имени пользователя (префикс с именем хостера, суффикс – логин у предыдущего хостера или преобразованный e-mail, если логина нет);
б) Генерация пароля;
в) Перенос контактов;
г) Перенос остатков на лицевых счетах / данных о датах отключения услуги;
д) Создание доменов (возможно дописывание API к сторонним регистраторам, если домены находятся у других регистраторов и их массовый перенос невозможен);
е) Создание услуг. Учитываем отображение тарифов у предыдущего хостера и у нас. В случае, если клиент не умещается в лимиты тарифа – повышаем тариф «за наш счёт»).

Цель этапа – внести в базу биллинга информацию обо всех клиентах и их услугах.

2.3. Подготовка к физической миграции / разбиение клиентов по серверам:
а) Составляем полный и «окончательный» список аккаунтов, которые нужно мигрировать;
б) Наводим порядок в ранее созданном списке (можно сказать, что наводим порядок на хостинге, откуда переносим аккаунты): смотрим, нет ли на двух или более серверах одинаковых пользователей или www-доменов. Если такие имеются – в полуавтоматическим и ручном режиме разбираемся и удаляем лишнее;
в) Делим весь список юзеров на группы, которые удовлетворяют следующим условиям:

• В одной группе должно быть не больше n пользователей;
• В одной группе не должны быть превышены суммарные лимиты используемых ресурсов;
• Для облегчения последующего проксирования трафика со старых серверов на новые (которое включится после переноса) желательно также не разделять аккаунты с одного исходного сервера на разные группы.

г) Сверяем настройки серверов источника и разрешенные права на источнике с настройками и правами на сервере назначения.

Цель этапа – распределить клиентов между серверами назначения с учётом всех ограничений и нюансов.

2.4. Перенос аккаунтов между хостинговыми панелями:
а) Подготовка списков сайтов для переноса (учитываем алиасы, редиректы);
б) Перенос настроек аккаунтов (версия и режим запуска PHP и т.п.);
в) Перенос настроек почты (почтовые аккаунты, почтовые группы, редиректы);
г) Перенос настроек DNS (попутно меняем IP-адреса серверов старой инфраструктуры на новые, оставляя без изменений дополнительные DNS-записи, внесённые клиентом);
д) Переименование / приведение в порядок имён баз. Готовим таблицу замен (старое имя баз => новое), добавляя префикс с ID пользователя. Особое внимание обращаем на:

• Базы с именами меньше n символов;
• Базы с именами типа sql, mysql, new, user и т.д., которые вносят неразбериху в пространство имён баз.

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

Цель этапа – создание всех необходимых аккаунтов и их настроек в базе «принимающей» хостинговой панели.

3. Физический перенос сайтов:
Для каждой группы клиентов, предназначенной для переноса на очередной сервер:
а) Запускаем автоматический механизм миграции одной группы;
б) Запускаем автоматический скрипт по автоматической перенастройке конфигов сайтов под новое окружение:

• Меняем старые имена баз на новые (см. п. 2.4 (д));
• Меняем старые пути к файлам / каталогам на новые;
• Разрешаем конфликтные ситуации, когда автомат сомневается в корректности замены: по-хорошему, нужно прогнать автомат до переноса и подготовить ручной патч для сомнительных мест, который накатывается в данный момент.

г) Запускаем автомат для тестирования главных страниц сайтов после переноса: автомат смотрит, что HTTP-статусы главных страниц всех сайтов не поменялись;
в) Дополнительно проводим ручную проверку – отдаем список www-доменов данной группы службе поддержки хостинга / службе тестирования;
д) Правим найденные баги;
е) Включаем для доменов перенесенной группы проксирование к нам, блокируем клиентов этой группы на источнике.

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

4. Действия после переноса:
а) Отправляем клиентам уведомления с их новыми реквизитами для доступа к биллингу / панелям управления и особенностями нового хостинга, на которые следует обратить внимание.
б) Финальный контроль корректности переноса, исправление ошибок;
в) Автоматически меняем DNS-серверы на наши (для тех доменов, которые находятся под нашим управлением);
г) Делаем рассылку по клиентам с собственными DNS с просьбой поменять DNS на наши (для доменов вне зоны нашей досягаемости).

Цель этапа – сменить DNS на новые IP и разослать клиентам все необходимые уведомления.

Один из последних примеров подобного массового переноса клиентов — сотрудничество с Hostingjoomla.ru, в результате которого перенесено более 500 клиентов (750+ www-доменов) с нескольких старых серверов на новые. Попутно была проведена большая работа по борьбе с хаосом (элементы этой работы были перечислены выше).

В результате все получили желанный PROFIT:

• Веб-студия RedSoft (которой принадлежит проект Hostingjoomla.ru), специализирующаяся на запуске проектов на базе CMS Joomla!, передала сопровождение услуг хостинга специализированному оператору и получила возможность полностью сосредоточится на основном бизнесе, опираясь на более стабильную платформу для проектов своих клиентов;
• Клиенты получили более качественный и стабильный хостинг-сервис по выигрышной цене, круглосуточную качественную техническую поддержку и значительно большее количество опций и дополнительных услуг (выделенные IP-адреса, SSL-сертификаты, домены в более чем 200 зонах и т.п.), которые можно заказать в формате «одного окна» (одного аккаунта в REG.RU);
• Компания REG.RU получила новых лояльных клиентов, нацеленных на длительное сотрудничество, т. к. с верфей веб-студий редко сходят сайты-однодневки;
• Инженеры компании REG.RU получили дополнительные очки опыта и очередное пополнение набора автоматических скриптов, позволяющих разруливать сложные ситуации, связанные с переносом.

Но на этом история с Hostingjoomla.ru не закончилась — мы оптимизировали под нужды пользователей CMS Joomla! линейку уже существующих тарифов, добавили возможность заказа Joomla-тарифов в наш API, доработали REG.Panel, также добавив туда новые тарифы и даже выбор версии Joomla для автоинсталляции. В результате, клиенты веб-студии получили продукт, полностью оптимизированный под их нужды. А это уже PROFIT для всего рынка.

Вообще, перенос хостинг-инфраструктуры от небольших провайдеров к более крупным стал сложившейся тенденцией на российском рынке, так как это – шанс передать хостинг-инфраструктуру в надёжные руки, получив взамен возможность сосредоточиться на других задачах. Есть вопросы — пишите: поможем, подскажем!