В жизни любого перенос клиентов между собственными серверами – задача достаточно обыденная. Для подобного переноса может быть множество причин: начиная с планового апгрейда оборудования или софта и планового «перераспределения» клиентов в связи с неравномерной загрузкой серверов, заканчивая срочным перемещением пользователей в случае аварий.
Реже в жизни провайдеров возникают задачи по переносу клиентов от другого провайдера shared-хостинга.
Причиной такого переноса может быть как «усталость» хостера-«донора» от подобного высокотехнологичного бизнеса, так и вынос услуг на аутсорсинг в более крупную хостинг-компанию в случае, если оказание этих услуг не является для решившейся на перемены организации профильным бизнесом (например, если речь идет о веб-студии, интернет-провайдере, провайдере сервис-услуг и т.д.).
Количество потенциальных проблем при переносе клиентов между разными провайдерами намного больше, нежели при переносе внутри одного . Это связано с тем, что инфраструктура «старого» и «нового» провайдера может значительно отличаться:
- Используются разные биллинг-панели;
- Используются разные панели управления ;
- Разные версии PHP / других интерпретаторов с разными настройками;
- Разные режимы запуска скриптов (fastcgi vs mod_something);
- Разные настройки веб-серверов;
- Разная схема включения веб-серверов (с использованием / без использования frontend);
- Разные настройки и различия в политике безопасности;
- Разные пути в системе к сайтам и к внешним утилитам;
- Разные почтовые серверы и схемы отправки почты (отправка на 25 порт vs вызов sendmail).
При этом, полностью копировать чужую инфраструктуру, которая может оказаться неоптимальной или имеющей какие-либо ограничения, не хочется. Даже если исходная инфраструктура качественная и интересная, нет смысла плодить «зоопарк» — можно разве что позаимствовать интересные находки, чтобы в будущем внедрить их у себя. Таким образом, обычно приходится переносить сайты в совершенно новое окружение и отображать «чужую» инфраструктуру на «свою».
Существуют ещё и различные потенциальные «нестыковки» из реальной жизни, учитывающие возможности небольших хостинг-провайдеров:
- Разные опции и разное количество ресурсов на тарифных планах (1:1 тарифы не стыкуются почти никогда);
- Разные клиенты одного хостера могут жить в разных хостинговых / биллинговых панелях, а часть клиентов, вообще могут быть заведены «в Excel'е», а их оплата отслеживаться вручную (разумеется, часть такой информации может быть не актуальна);
- Сайты, которые физически есть на серверах, но отсутствуют в биллинге;
- Одни и те же клиенты могут дублироваться на разных физических серверах. Например, если клиент переносился с сервера на сервер, а со старого сервера его удалить забыли;
- Разные сайты одного и того же хостингового клиента (имеющего единственный аккаунт в хостинговой панели) могут обслуживаться на разных серверах;
- Прочие экзотические варианты, которые надо как-то разруливать.
Естественно, со всем этими проблемами нам приходится иметь дело и как-то их разруливать. При этом, нужно делать это так, чтобы никто из клиентов «не пострадал»: ничьи сайты не «упали», а тарифные условия не ухудшились. В общем, чтобы был «никто не забыт и ничто не забыто» и, при этом, всё продолжало работать.
Фактически в таком случае нужно решать три задачи:
- Отображать чужую инфраструктура на свою, так чтобы всё продолжало работать;
- «Наводить порядок», устраняя все возможные нестыковки и избавляясь от технологического хаоса;
- Минимизировать даунтаймы при переносе.
В этой обзорной статье я постараюсь рассказать, как эти задачи решаются в .
Обычно процесс состоит из нескольких технологических, организационных и информационных этапов:
1. Уведомление клиентов о предстоящем переносе:
а) Новость на сайте хостера;
б) Новость на сайте ;
в) Пресс-релиз;
г) Рассылка клиентам о предстоящем переносе;
д) Пауза 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 зонах и т.п.), которые можно заказать в формате «одного окна» (одного аккаунта в );
- Компания получила новых лояльных клиентов, нацеленных на длительное сотрудничество, т. к. с верфей веб-студий редко сходят сайты-однодневки;
- Инженеры компании получили дополнительные очки опыта и очередное пополнение набора автоматических скриптов, позволяющих разруливать сложные ситуации, связанные с переносом.
Но на этом история с Hostingjoomla.ru не закончилась — мы оптимизировали под нужды пользователей CMS Joomla! линейку уже существующих тарифов, добавили возможность заказа Joomla-тарифов в наш API, доработали REG.Panel, также добавив туда новые тарифы и даже выбор версии Joomla для автоинсталляции. В результате, клиенты веб-студии получили продукт, полностью оптимизированный под их нужды. А это уже PROFIT для всего рынка.
Вообще, перенос хостинг-инфраструктуры от небольших провайдеров к более крупным стал сложившейся тенденцией на российском рынке, так как это – шанс передать хостинг-инфраструктуру в надёжные руки, получив взамен возможность сосредоточиться на других задачах. Есть вопросы — пишите: поможем, подскажем!
Автор: nastik
