История довольно короткая, но смешная. С ней реально столкнулся наш заказчик. Началось всё в тот момент, когда один из провайдеров ИТ-инфраструктуры решил перевезти свой дата-центр. И предупредил примерно за полгода всех своих клиентов о трёхдневном даунтайме, но так тянул время и организовывал бюрократическую волокиту, что некоторые заказчики к миграции попросту не успели подготовиться.
Представьте: вы CIO. Бюджета на аварийную дублирующую площадку у вас нет. Старого оборудования тоже нет. Бизнес связан с предоставлением медицинских услуг, здесь каждый лишний час промедления стоит дорого: один день простоя грозит финансовыми и имиджевыми потерями, равными годовой прибыли, два часа — начнут страдать клиенты.
А теперь добивающий аккорд: переезд вам по факту осложняют, ставя в рамки и согласовывая каждый чих по месяцу. Потому что вы же много платите провайдеру, зачем вас отпускать?
Логика провайдера
Всё довольно просто: заказчик жил у них много лет всей инфраструктурой и если переживёт даунтайм, то проживёт и дальше много лет. И всё время будет платить. Поэтому надо его максимально сохранить. Поэтому нужно вставлять ему палки в колёса до конца переезда. Куда он денется? Ну да, немного компенсировать неудобства ещё в рамках SLA или сделать символическую скидочку.
Логика заказчика
Заказчик, мягко говоря, не понял юмора. Точнее, он-то всё сразу понял и обратился к нам, чтобы перенести всю инфраструктуру как можно скорее. А затем делать уже две площадки после того, как этот кризис закончится.
Наша задача — вытащить все данные и развернуть всё то же самое в нашем облаке, лежащем в двух отказоустойчивых распределенных дата-центрах, сертифицированных Аптаймом. Рутинная процедура, три дня на всё, если нет редких ОС, например, или аппаратных ключей. Редких ОС, аппаратных ключей, старых СХД и тяжёлых серверов-молотилок нет. Просто 5 Тб данных.
С этим-то и начались проблемы.
Проблемы
В SLA провайдера был обозначен срок реакции — 3 дня. В последний час срока SLA на все наши запросы приходил ответ в духе незабвенной бангладешской поддержки с уточнением какой-нибудь мелочи. Затем — снова 2 дня и 23 часа.
Скорость интернета была до 50 Мбит/с (это с учётом, что заказчик утилизирует этот канал минимум наполовину вживую в продакшене и есть более-менее нормальная часть полосы только глубокой ночью). Расширять пропускную способность канала провайдер отказывался даже за дополнительные деньги.
Остаётся две недели.
«Шах и мат», — наверное, подумал их админ.
«А вот хрен тебе», — решили мы.
Даблтейк
Есть такая штука — Carbonite (бывший Даблтейк), предназначенная для асинхронных репликаций. У него есть расширение Carbonite Move, предназначенное для переезда. То есть лицензия только на один раз — пока всё не смигрируешь.
Ставится эта штука на уровне ОС, после чего начинает наблюдать за активностью записи. Задача агента с копируемой машины — отдавать в канал данные и следить за тем, что пишется нового после начала синхронизации. Когда первый здоровенный кусок данных будет передан на целевую инфраструктуру, на уровне ОС будет пригашен весь остальной софт и Move выделит и отправит разницу между тем, что было на начало копирования, и тем, что было записано, пока копирование шло.
Даунтайм на получение разницы за неделю совсем небольшой, около часа, плюс ещё час на работы по инициированию новой инфраструктуры. Итого прописали четыре, но уложились куда быстрее. Четыре часа ночью они могли себе позволить. Восемь — уже нет.
Почему неделя? Потому что именно столько мы тащили данные с агентов — с учётом, что канал был нищенски мал.
Дальше — штатное развёртывание и подъём, быстрые тесты, сутки продакшена, а потом заказчик полностью останавливает виртуальные машины на площадке нашего оппонента.
Для провайдера это был сюрприз, потому что, когда мы перестали им писать, они, видимо, решили, что всё, победа у них в кармане.
Что это за софт?
Вот страница ПО.
На главной написано про околонулевой даунтайм, и это так, когда изменений за время копирования было мало. То есть когда есть возможность переносить системы по одной или канал широкий. У нас было не так.
С помощью этой штуки можно тестировать новые площадки до запуска их в продакшен (лицензия позволяет) либо с помощью другого решения пакета просто настроить репликацию в режиме Active-Passive.
Простое управление через консоль:
Копируется всё, не нужны коннекторы — просто Даблтейк выносит с машин всё чуть ли не посекторально (точнее, единицами логики хранилища, фиксируют они именно факты удачной записи и их координаты). Канал в процессе защищается, и, что именно льётся, никому не видно.
Что не получилось перенести
Не всё можно взять по сценарию выше. Была одна нагруженная виртуальная машина (по процессору под 100 процентов), там крутилась горячая база данных. И когда мы поставили агента, он начал отжирать мощность и начался импакт на работу базы. По ночам нагрузка на базу была меньше, но база была очень большая, а окно — маленькое. Мы поняли, что придётся очень долго терпеть и в итоге копированием по ночам просто не успеем смигрировать.
Сделали бекап виртуальной машины, привезли его физически на свою площадку на диске и залили в облако. Развернулись из бекапа, накатили апдейто-разницу стандартными средствами MS SQL. Всё. Звучит просто, но надо было сделать это быстро и с первого раза.
Так что удачных вам переездов.
Ссылки
- Физические переезды и их чёртовы особенности.
- Disaster Recovery и риски.
- Моя почта — RSayfutdinov@croc.ru.
Комментарии (48)
Nizametdinov
24.05.2018 10:33А затем делать уже две площадки после того, как этот кризис закончится.
Надеюсь догадаются делать вторую площадку у третьего провайдера :)
shifttstas
24.05.2018 10:35А зачем пользоваться такими хостерами?
Возьмите Amazon или Google Cloud там точно не будет такого. Если пугает перспектива прихода РКН — сервер за 5€ в Москве для проксирования запросов.
shifttstas
24.05.2018 10:41+1Опционально вместо прокси в РФ, логичнее даже взять в Белоруси, на них ркн не распростроняется
RenatS Автор
24.05.2018 11:03Проксирование запросов – это костыль, который для компании такого калибра неприемлем.
Есть формальные требования хранить персональные данные в России как минимум и недавние блокировки Amazon и Google как максимум.achekalin
24.05.2018 12:11+1Сам так не делаю, но, формально, если держать копию данных в России (на слабой, store-only, машине), а основной сервер на Амазоне, то «формальные требования хранить персональные данные в России» не нарушаются. Это мило обсуждалось в треде про блокировки РКН, когда выяснилось, что после их начала где-то встали кассы, и еще что-то случилось, чего бы не произошло, будь сервера не на Амазоне (читай — не снаружи России).
Вот проксирование запросов — это да, это просто сделает работу медленнее.
А вообще (руки важнее, чем география), ПД потерять и в России можно, и на Амазоне надежно сохранить.JekaMas
24.05.2018 20:13+1Делали так. Наши юристы общались с органами — такие решение их устроило полностью. Лишь бы в РФ была копия данных.
lobzanoff
25.05.2018 15:12Это лишний раз доказывает, зачем и кому таковое хранение было нужно — и уж точно не сохранность ПД была целью, а лишь доступность их для органов.
achekalin
24.05.2018 11:04Если там подсуетятся, смогут не только кофе и сыры с бабанами «производить» на половину России, но и трафик гнать!
willyd
24.05.2018 10:57Мне почему-то кажется, что завязка этой драмы была намного сложнее, чем тут описано. Учитывая, что клиенты были предупреждены за полгода, скорее всего предполагался переезд по частям, клиентам поднимали сеть на втором уровне между ДЦ и предлагали составить расписание заранее, чтобы не было аврала в последние недели перед переездом. Данный заказчик, как и большая часть остальных, решил, что сможет все сделать в последний месяц и очнулся слишком поздно.
Вины с провайдера услуг это никак не снимает, клиент — это клиент, и задерживать сроки, когда он понял, что просрал все полимеры, и ищет для себя выход — не вариант, даже учитывая, что ты его потеряешь.
AWS и GCP, скорее всего не подходят из-за персональных данных. Да и по цене, они не всегда будут дешевле в первом приближении.shifttstas
24.05.2018 12:47Закон о перс данных не запрещает их хранить ещё где-то а не только в рф
Evengard
24.05.2018 21:03А интересно, можно ли хранить скажем ежедневно создаваемый бэкап на территории России дабы соответствовать этому требованию? Или нужны "лайвовые" данные?
shifttstas
24.05.2018 22:13В требований нет, если хочется 1:1 соответствовать закону — я бы поставил или дохлую реплику БД или же HDFS/CEPH
CherryPah
24.05.2018 21:13За 5 баксов проксимального разве что телеграмм(запрещенный в РФ) можно. В статье было что то про высоконагруженную бд, хватит вам канала/трафика за эти деньги для таких целей? А если нужен постоянно толстый канал и высокое латенси до бд?
shifttstas
24.05.2018 22:14Прокси будет пересылать только html/api, вся логика — в другой стране. Работать будет аналогично Cloudflare / nginx proxy
achekalin
24.05.2018 11:02Сделали бекап виртуальной машины, привезли его физически на свою площадку на диске и залили в облако.
Так ведь на площадку не пускали, как на диск вы забрали бекап ВМ? Или вы его по каналу в 50 Мб вытягивали (половине от него), но в это что-то не верится.
Интрига, в общем!RenatS Автор
24.05.2018 11:14Нам повезло, что заказчик имел копию при себе. Естественно, у нее был некоторый срок давности, но основной объем данных был актуальный. А через канал накатили разницу средствами БД.
achekalin
24.05.2018 11:18Да, тогде никакой интриги, никакого чуда. Впрочем, и хорошо: чудеса при переезде чреваты.
REPISOT
24.05.2018 11:17утилизирует этот канал
На русском это будет «использует»achekalin
24.05.2018 11:24Можно и так было сказать (я не автор поста). Но загрузку канала часто называют именно утилизацией (в % к общей пропускной, скажем), а вот «использованием» — как-то не встречалось.
Язык, конечно, штука гибкая, но какие-то слова больше прижились, пусть даже это не особо изящные кальки.
Wernisag
24.05.2018 17:11+1УТИЛИЗИ?РОВАТЬ
Употребить [-реблять] с пользой (перерабатывая, используя каким-н. образом).
Толковый словарь русского языкаREPISOT
24.05.2018 20:25+3приведу окончание из вашего источника: «например, утилизировать отходы производства»
Просто использовать что-то по назначению, например, витую пару, чтобы передавать данные) это одно, а использовать испорченную витую пару (перерабатывая) чтобы получить из нее медь (с пользой) — это и есть утилизация.
achekalin
24.05.2018 11:27Ждем в тред техдира исходного провайдера, с его рассказом, какой заказчик был геморойщик, и как они ему полгода жизни отдали, а он взял, и обманом свалил — и к кому! #шутка
willyd
24.05.2018 11:57Лучше распишите, с чего все началось. Я думаю, что история будет поучительна в том как планировать. А то у вас получилось, что провайдер просто бездарь и негодяй, а клиент — ясно солнышко. Как я написал выше, мне почему-то кажется, что клиент затянул с планированием переезда, а потом в самый напряженный период сказал, что переезжает к другим. Со стороны прибыли для провайдера вопрос в приоритете в таком случае как бы ясен.
К данному провайдеру и хостерам вообще отношения не имею, от слова совсем.qw1
24.05.2018 23:17клиент затянул с планированием переезда, а потом в самый напряженный период сказал, что переезжает к другим
И что, это даёт провайдеру право динамить клиента с тех. поддержкой и расширением канала?willyd
25.05.2018 11:39Я это не писал. Если действительно дело было, как описано, без всяких объяснений и попыток договорится, то тогда все понятно. Но вся история смотрится как-то нелепо, вы не находите? Причем изложена она конкурентом, который уводил клиента. Да и задача этой статьи больше в пиаре софта, чем в передаче истины. Как на самом деле было дело никто не узнает.
qw1
25.05.2018 16:05Вот это как нужно было понять:
Со стороны прибыли для провайдера вопрос в приоритете в таком случае как бы ясен
Я это понял — раз клиент всё равно уходит, можно его обслуживать с низким приоритетом.willyd
25.05.2018 16:55Именно так.
Если бы у меня был страшный аврал, я бы мог отложить этого клиента на свободное время в конце. И скорее всего, тоже бы отказал ему в расширении канала, поскольку данные под конец срока переливали все. Я бы, конечно, объяснил клиенту ситуацию, и убедил, что у него все будет хорошо, но не сейчас. Все бы зависело от реальной ситуации.
Как себя вел провайдер мы не заем. Как себя вел клиент мы не знаем. Судить обо всем этом достаточно тяжело.
К примеру. У меня сейчас чем-то похожая ситуация, взял проект без должного ТЗ, на время пока у меня простой. Все данные по ТЗ приходится выдирать клещами, из-за этого он практически не продвигается. Со следующей недели у меня будет много работы от основного заказчика, и этот проект даже при идеальном ТЗ будет продвигаться очень медленно. И меня будут делать виноватым, и рассказывать, что я подвел со сроками, сорвал проект и т.д. и т.п.qw1
25.05.2018 18:58И что, это даёт провайдеру право динамить клиента
Я это не писал.
этот проект даже при идеальном ТЗ будет продвигаться очень медленно
Теперь написали. Стало понятно, это изначально подразумевалось как нечто в порядке вещей.
В принципе, почему нет. Всем сразу не угодишь.
staticlab
24.05.2018 13:32Представьте: вы CIO. Бюджета на аварийную дублирующую площадку у вас нет. Старого оборудования тоже нет. Бизнес связан с предоставлением медицинских услуг, здесь каждый лишний час промедления стоит дорого: один день простоя грозит финансовыми и имиджевыми потерями, равными годовой прибыли, два часа — начнут страдать клиенты.
То есть бизнес не понимал, что простой мог возникнуть даже не от планового даунтайма провайдера, но и от аварии? Неплохой риск-менеджмент.
Ztare
24.05.2018 14:14Риск-менеджмент по-русски.
1) Бюджета на… дублирующую площадку… нет
2) один день простоя… потерями… годовой прибыли
3) ждем полгода о предупрежденной миграции ничего не делаем
4)…
5) провайдер плохой
Хотя провайдер тоже мутный, обе стороны виноваты. Весь бизнес завязан на онлайн — на резервирование похрен.staticlab
24.05.2018 15:42+16) тратим кучу денег и нервов на экстренную миграцию
Хотя провайдер тоже мутный, обе стороны виноваты.
Мы не знаем наверняка, каким образом компания выбрала именно этого провайдера ;)
inkvizitor68sl
24.05.2018 18:57+1Вы бы побыли хостером в РФ =)
Сидишь такой в М9 на аренде, а тебе «мы через неделю вам стойки на другой этаж повезем, даунтайм сутки, делайте что хотите». А к стойкам — аплинки (перенос которых в сутки не укладывается), ИБП, полки и куча всего.
Единственный вариант — покупать землю и строить ДЦ самому. И то — экскаваторщики обязательно умудрятся окопать весь участок по периметру и порвать все аплинки. А не купишь землю — тебя арендатор выпнет. Ещё и одолжение сделает — за целых 2 месяца предупредит.
RenatS Автор
24.05.2018 17:00+1Бизнес как раз-таки понимал, что время восстановления из бэкапа удовлетворяет требованиям показателя RTO. А вот обещанный трехдневный даунтайм бизнес не выдержал бы.
willyd
24.05.2018 17:34Я понимаю, что статья маркетинговая, попиарить карбонит. Но все же.
Бюджета на аварийную дублирующую площадку у вас нет.
Ок. Тут уже описали, что бывают случаи, когда прибыль не позволяет.
Бизнес связан с предоставлением медицинских услуг, здесь каждый лишний час промедления стоит дорого: один день простоя грозит финансовыми и имиджевыми потерями, равными годовой прибыли, два часа — начнут страдать клиенты.
Это как так? Нет прибыли на то, чтобы организовать дублирование критической инфраструктуры. Хотя ее простой влечет за собой упущенную прибыль, большую прибыль, и репутационные риски.
Бизнес как раз-таки понимал, что время восстановления из бэкапа удовлетворяет требованиям показателя RTO. А вот обещанный трехдневный даунтайм бизнес не выдержал бы.
А тут вообще рукалицо! Было полгода, в течении которых можно было:
1. Связаться с провайдером и договорится о поэтапном ночном переносе серверов на новую площадку.
2. Арендовать дополнительную площадку в облаке и развернуть там резервную инфраструктуру.
3. Купить оборудование и развернуть на новой площадке провайдера или у другого провайдера. Сколько там того оборудования, если объем данных был 5ТБ? Даже если у них использовались тонкие клиенты, в чем я сомневаюсь, та максимум 10 стареньких серверов, которые спокойно могли переехать на 3-4 новых.
В любом случае, резервная инфраструктура пригодится, если все так как описано в статье.
Так что, скорее всего, клиент стоит провайдера, если он на самом деле такой, как вы его описали.
uanet
24.05.2018 16:23+1У меня был опыт почудесатее: о переезде не предупреждали. Совсем. Это в США. Бац — всё выключилось, «надолго». Потом включилось. Поддержка реселлера поморозилась — но в итоге честно написали «мы не можем достучаться до хостера, спасайся, кто может». Тут каналам начало плохеть — я чуть раньше слил бОльшую часть, но потом бэкапиться кинулись все :). Этот цирк с неизвестностью был 3 дня! Потом оказалось — возили сервера между датацентрами (и это ещё продолжалось чуток времени), частями и криво настроив сеть (из мира — видим сервер 1 и сервер 2, но сервера друг друга — не видят), и, возможно, разбирая на части — тут понимаешь, что от потери 3 из 4 дисков спасёт только зеркало, RAIDZ2 не вынес такого :).
А бизнес бывает с низкими прибылями — и таки дублировать инфраструктуру может быть не по карману. Это ж не просто «купить железо» — это и неплохо бы переписать софт, и расходы на содрежание железа… И или «авось» или услуга вырастет в цене и ты проиграешь конкуренту с «авось». Вот и выбирайте — «прибыль здесь и сейчас/вложение в разработку сервиса», или «развиваться не за что», или «отдел маркетинга должен напрячься».
Короче, Интернет — эта такая вещь, в которой нужно готовиться к падению атомной бомбы в твой датацентр. Или материально — строя инфраструктуру, или морально — приняв грядущие проблемы как данность.
hamnsk
24.05.2018 18:09-5сдается мне статья полный пиздешь, потому что денег на резерв у нас нет, но два часа простоя это год работы и риски, за год там что 500 рублей прибыль? или 5000? и нах такой бизнес где нет прибыли? хотя 5 ТБ данных, это бизнес должен быть очень крупным и приносить очень много бабосов, я помню огромную бд где было 1000 доков в минуту как раз для сиквела от мелкомягких там база была 250 гигов, не 5 тб, раз там 5 тб, там что все журналы транзакций хранились? или транзакшен лог не транкейтили? вобщем если так технически подойти то много не стыковок и похоже на пиздаболию. так долго переезжал караван, да у него были косяки при переезде, да тачки везли ночью и у них был даунтайм, но!!! они давали на время тачки всем клиентам в новом дц, и единственный гемор был только с дедиками тупо их переключить и потом данные смигрировать, облако вообще безшовно переключилось, а тут речь о виртуалках, кто мешал их смигрировать? в общем тупая рекламе этой софтины под винду, да еще приправленная пиздежом
willyd
24.05.2018 18:16хотя 5 ТБ данных
5ТБ всего, как я понял. Это могут быть какие-то данные томографов, УЗИ и т.д.
CherryPah
24.05.2018 21:20Пока что меня смущает какое то мутное SLA с трёхдневной реакцией на инцидент. Сейчас даже у любого физика саппорт домашнего интернета зачастую работает 24/7, а тут цод, в нем не то что саппорт, в нем физический доступ должен быть априори заложен
RenatS Автор
25.05.2018 13:36В SLA есть приоритизация заявок. Обращения с наименьшим severity действительно имеют срок реакции «в течение трёх дней». А физический доступ провайдер не предоставляет заказчикам из тех соображений, что оборудование принадлежит провайдеру. Это нормальная практика для поставщиков услуг IaaS.
Gasaraki
27.05.2018 00:05В который раз убеждаюсь мысли что в облака надо идти с очень серьезной подготовкой к рискам. На тех же дедиках с установленной виртуализацией проблемы просто не было бы — арендуется во втором цоде сервер(а), внутри гипервизоров ставишь виртуальные комутаторы, строишь внутренние L2 туннели, собираешь кластер (зависит от системы гипервизоров), настраиваешь шейпинг на виртуальных коммутаторах, настраиваешь проброс в dmz, далее запускаешь живую миграцию. На время переезда конечно из-за скорости интернет канала возможна просадка производительности, но прерывания сервиса не будет. Во время переезда настраиваешь ttl dns'ов на 60 секунд, затем после переезда меняешь A запись(до этого времени будет работать проброс на коммутаторе через l2 туннель первого провайдера). После этого отказываешься от старого провайдера.
И в современных реалиях на дедиках надо брать ssd, они кстати и нагрузку на проц снимают довольно существенно при нагруженной базе и переезды становятся быстрее.
zCooler
Перенеси бы прошлый провайдер этого клиента в первую очередь с минимальным даунтаймом всячески помогая клиенту, лояльность клиента выросла бы значительно, и они остались бы довольны сервисом еще надолго.