Как нашего заказчика не хотел отпускать провайдер

Всё довольно просто: заказчик жил у них много лет всей инфраструктурой и если переживёт даунтайм, то проживёт и дальше много лет. И всё время будет платить. Поэтому надо его максимально сохранить. Поэтому нужно вставлять ему палки в колёса до конца переезда. Куда он денется? Ну да, немного компенсировать неудобства ещё в рамках SLA или сделать символическую скидочку.

Заказчик, мягко говоря, не понял юмора. Точнее, он-то всё сразу понял и обратился к нам, чтобы перенести всю инфраструктуру как можно скорее. А затем делать уже две площадки после того, как этот кризис закончится.

Наша задача — вытащить все данные и развернуть всё то же самое в нашем облаке, лежащем в двух отказоустойчивых распределенных дата-центрах, сертифицированных Аптаймом. Рутинная процедура, три дня на всё, если нет редких ОС, например, или аппаратных ключей. Редких ОС, аппаратных ключей, старых СХД и тяжёлых серверов-молотилок нет. Просто 5 Тб данных.

С этим-то и начались проблемы.

В SLA провайдера был обозначен срок реакции — 3 дня. В последний час срока SLA на все наши запросы приходил ответ в духе незабвенной бангладешской поддержки с уточнением какой-нибудь мелочи. Затем — снова 2 дня и 23 часа.

Скорость интернета была до 50 Мбит/с (это с учётом, что заказчик утилизирует этот канал минимум наполовину вживую в продакшене и есть более-менее нормальная часть полосы только глубокой ночью). Расширять пропускную способность канала провайдер отказывался даже за дополнительные деньги.

Остаётся две недели.

«Шах и мат», — наверное, подумал их админ.

«А вот хрен тебе», — решили мы.

Есть такая штука — Carbonite (бывший Даблтейк), — предназначенная для асинхронных репликаций. У него есть расширение Carbonite Move, предназначенное для переезда. То есть лицензия только на один раз — пока всё не смигрируешь.

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

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

Почему неделя? Потому что именно столько мы тащили данные с агентов — с учётом, что канал был нищенски мал.

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

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

Вот страница ПО: https://www.carbonite.com/products/doubletake-migration-software/.

На главной написано про околонулевой даунтайм, и это так, когда изменений за время копирования было мало. То есть когда есть возможность переносить системы по одной или канал широкий. У нас было не так.

С помощью этой штуки можно тестировать новые площадки до запуска их в продакшен (лицензия позволяет) либо с помощью другого решения пакета просто настроить репликацию в режиме Active-Passive.

Простое управление через консоль:

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

Не всё можно взять по сценарию выше. Была одна нагруженная виртуальная машина (по процессору под 100 процентов), там крутилась горячая база данных. И когда мы поставили агента, он начал отжирать мощность и начался импакт на работу базы. По ночам нагрузка на базу была меньше, но база была очень большая, а окно — маленькое. Мы поняли, что придётся очень долго терпеть и в итоге копированием по ночам просто не успеем смигрировать.

Сделали бекап виртуальной машины, привезли его физически на свою площадку на диске и залили в облако. Развернулись из бекапа, накатили апдейто-разницу стандартными средствами MS SQL. Всё. Звучит просто, но надо было сделать это быстро и с первого раза.

Так что удачных вам переездов.

• Физические переезды и их чёртовы особенности.
• Disaster Recovery и риски.
• Моя почта: RSayfutdinov@croc.ru.