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



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

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

А теперь добивающий аккорд: переезд вам по факту осложняют, ставя в рамки и согласовывая каждый чих по месяцу. Потому что вы же много платите провайдеру, зачем вас отпускать?

Логика провайдера


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

Логика заказчика


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

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

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

Проблемы


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

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

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

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

Даблтейк


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

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

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

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

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

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

Что это за софт?


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

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

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



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

Что не получилось перенести


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

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

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

Ссылки


Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (48):

  1. zCooler
    /#11370180 / +1

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

  2. Nizametdinov
    /#11370224

    А затем делать уже две площадки после того, как этот кризис закончится.
    Надеюсь догадаются делать вторую площадку у третьего провайдера :)

  3. shifttstas
    /#11370228

    А зачем пользоваться такими хостерами?


    Возьмите Amazon или Google Cloud там точно не будет такого. Если пугает перспектива прихода РКН — сервер за 5€ в Москве для проксирования запросов.

    • shifttstas
      /#11370238 / +1

      Опционально вместо прокси в РФ, логичнее даже взять в Белоруси, на них ркн не распростроняется

      • RenatS
        /#11370298

        Проксирование запросов – это костыль, который для компании такого калибра неприемлем.
        Есть формальные требования хранить персональные данные в России как минимум и недавние блокировки Amazon и Google как максимум.

        • achekalin
          /#11370466 / +1

          Сам так не делаю, но, формально, если держать копию данных в России (на слабой, store-only, машине), а основной сервер на Амазоне, то «формальные требования хранить персональные данные в России» не нарушаются. Это мило обсуждалось в треде про блокировки РКН, когда выяснилось, что после их начала где-то встали кассы, и еще что-то случилось, чего бы не произошло, будь сервера не на Амазоне (читай — не снаружи России).

          Вот проксирование запросов — это да, это просто сделает работу медленнее.

          А вообще (руки важнее, чем география), ПД потерять и в России можно, и на Амазоне надежно сохранить.

          • JekaMas
            /#11371266 / +1

            Делали так. Наши юристы общались с органами — такие решение их устроило полностью. Лишь бы в РФ была копия данных.

            • lobzanoff
              /#11372260

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

        • shifttstas
          /#11370552

          Это не костыль это разновидность load balancing

      • achekalin
        /#11370300

        Если там подсуетятся, смогут не только кофе и сыры с бабанами «производить» на половину России, но и трафик гнать!

    • willyd
      /#11370272

      Мне почему-то кажется, что завязка этой драмы была намного сложнее, чем тут описано. Учитывая, что клиенты были предупреждены за полгода, скорее всего предполагался переезд по частям, клиентам поднимали сеть на втором уровне между ДЦ и предлагали составить расписание заранее, чтобы не было аврала в последние недели перед переездом. Данный заказчик, как и большая часть остальных, решил, что сможет все сделать в последний месяц и очнулся слишком поздно.
      Вины с провайдера услуг это никак не снимает, клиент — это клиент, и задерживать сроки, когда он понял, что просрал все полимеры, и ищет для себя выход — не вариант, даже учитывая, что ты его потеряешь.
      AWS и GCP, скорее всего не подходят из-за персональных данных. Да и по цене, они не всегда будут дешевле в первом приближении.

      • shifttstas
        /#11370548

        Закон о перс данных не запрещает их хранить ещё где-то а не только в рф

        • Evengard
          /#11371320

          А интересно, можно ли хранить скажем ежедневно создаваемый бэкап на территории России дабы соответствовать этому требованию? Или нужны "лайвовые" данные?

          • shifttstas
            /#11371372

            В требований нет, если хочется 1:1 соответствовать закону — я бы поставил или дохлую реплику БД или же HDFS/CEPH

    • CherryPah
      /#11371328

      За 5 баксов проксимального разве что телеграмм(запрещенный в РФ) можно. В статье было что то про высоконагруженную бд, хватит вам канала/трафика за эти деньги для таких целей? А если нужен постоянно толстый канал и высокое латенси до бд?

      • shifttstas
        /#11371374

        Прокси будет пересылать только html/api, вся логика — в другой стране. Работать будет аналогично Cloudflare / nginx proxy

  4. achekalin
    /#11370296

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


    Так ведь на площадку не пускали, как на диск вы забрали бекап ВМ? Или вы его по каналу в 50 Мб вытягивали (половине от него), но в это что-то не верится.

    Интрига, в общем!

    • RenatS
      /#11370328

      Нам повезло, что заказчик имел копию при себе. Естественно, у нее был некоторый срок давности, но основной объем данных был актуальный. А через канал накатили разницу средствами БД.

      • achekalin
        /#11370340

        Да, тогде никакой интриги, никакого чуда. Впрочем, и хорошо: чудеса при переезде чреваты.

    • MockBeard
      /#11370346

      настало время офигительных историй )))
      upd: интриги не получилось

  5. achekalin
    /#11370336

    del

  6. REPISOT
    /#11370338

    утилизирует этот канал

    На русском это будет «использует»

    • achekalin
      /#11370356

      Можно и так было сказать (я не автор поста). Но загрузку канала часто называют именно утилизацией (в % к общей пропускной, скажем), а вот «использованием» — как-то не встречалось.
      Язык, конечно, штука гибкая, но какие-то слова больше прижились, пусть даже это не особо изящные кальки.

    • Wernisag
      /#11371074 / +1

      УТИЛИЗИ?РОВАТЬ

      Употребить [-реблять] с пользой (перерабатывая, используя каким-н. образом).
      Толковый словарь русского языка

      • REPISOT
        /#11371284 / +3

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

    • MacIn
      /#11371348 / +1

      Верно, стоит это занести в словарь странных англицизмов, рядом с «дигитальный» и «продавать экспертизу».

      • JC_IIB
        /#11371352 / +1

        с «дигитальный»


        «диджитал» же. Все, кому не лень, это слово лепят, оно нынче модное… ах, простите, оно нынче — «в тренде»!

  7. achekalin
    /#11370360

    Ждем в тред техдира исходного провайдера, с его рассказом, какой заказчик был геморойщик, и как они ему полгода жизни отдали, а он взял, и обманом свалил — и к кому! #шутка

    • willyd
      /#11370428

      Лучше распишите, с чего все началось. Я думаю, что история будет поучительна в том как планировать. А то у вас получилось, что провайдер просто бездарь и негодяй, а клиент — ясно солнышко. Как я написал выше, мне почему-то кажется, что клиент затянул с планированием переезда, а потом в самый напряженный период сказал, что переезжает к другим. Со стороны прибыли для провайдера вопрос в приоритете в таком случае как бы ясен.
      К данному провайдеру и хостерам вообще отношения не имею, от слова совсем.

      • qw1
        /#11371426

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

        • willyd
          /#11371866

          Я это не писал. Если действительно дело было, как описано, без всяких объяснений и попыток договорится, то тогда все понятно. Но вся история смотрится как-то нелепо, вы не находите? Причем изложена она конкурентом, который уводил клиента. Да и задача этой статьи больше в пиаре софта, чем в передаче истины. Как на самом деле было дело никто не узнает.

          • qw1
            /#11372334

            Вот это как нужно было понять:

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

            • willyd
              /#11372396

              Именно так.
              Если бы у меня был страшный аврал, я бы мог отложить этого клиента на свободное время в конце. И скорее всего, тоже бы отказал ему в расширении канала, поскольку данные под конец срока переливали все. Я бы, конечно, объяснил клиенту ситуацию, и убедил, что у него все будет хорошо, но не сейчас. Все бы зависело от реальной ситуации.
              Как себя вел провайдер мы не заем. Как себя вел клиент мы не знаем. Судить обо всем этом достаточно тяжело.
              К примеру. У меня сейчас чем-то похожая ситуация, взял проект без должного ТЗ, на время пока у меня простой. Все данные по ТЗ приходится выдирать клещами, из-за этого он практически не продвигается. Со следующей недели у меня будет много работы от основного заказчика, и этот проект даже при идеальном ТЗ будет продвигаться очень медленно. И меня будут делать виноватым, и рассказывать, что я подвел со сроками, сорвал проект и т.д. и т.п.

              • qw1
                /#11372576

                И что, это даёт провайдеру право динамить клиента
                Я это не писал.
                этот проект даже при идеальном ТЗ будет продвигаться очень медленно
                Теперь написали. Стало понятно, это изначально подразумевалось как нечто в порядке вещей.

                В принципе, почему нет. Всем сразу не угодишь.

  8. JC_IIB
    /#11370366

    Интересно, а кто-нибудь из неотпускавшего провайдера эту статью прочел? :)

  9. staticlab
    /#11370630

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

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

    • Ztare
      /#11370716

      Риск-менеджмент по-русски.
      1) Бюджета на… дублирующую площадку… нет
      2) один день простоя… потерями… годовой прибыли
      3) ждем полгода о предупрежденной миграции ничего не делаем
      4)…
      5) провайдер плохой

      Хотя провайдер тоже мутный, обе стороны виноваты. Весь бизнес завязан на онлайн — на резервирование похрен.

      • staticlab
        /#11370888 / +1

        6) тратим кучу денег и нервов на экстренную миграцию


        Хотя провайдер тоже мутный, обе стороны виноваты.

        Мы не знаем наверняка, каким образом компания выбрала именно этого провайдера ;)

      • inkvizitor68sl
        /#11371212 / +1

        Вы бы побыли хостером в РФ =)
        Сидишь такой в М9 на аренде, а тебе «мы через неделю вам стойки на другой этаж повезем, даунтайм сутки, делайте что хотите». А к стойкам — аплинки (перенос которых в сутки не укладывается), ИБП, полки и куча всего.

        Единственный вариант — покупать землю и строить ДЦ самому. И то — экскаваторщики обязательно умудрятся окопать весь участок по периметру и порвать все аплинки. А не купишь землю — тебя арендатор выпнет. Ещё и одолжение сделает — за целых 2 месяца предупредит.

    • RenatS
      /#11371038 / +1

      Бизнес как раз-таки понимал, что время восстановления из бэкапа удовлетворяет требованиям показателя RTO. А вот обещанный трехдневный даунтайм бизнес не выдержал бы.

      • willyd
        /#11371114

        Я понимаю, что статья маркетинговая, попиарить карбонит. Но все же.

        Бюджета на аварийную дублирующую площадку у вас нет.

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

        Это как так? Нет прибыли на то, чтобы организовать дублирование критической инфраструктуры. Хотя ее простой влечет за собой упущенную прибыль, большую прибыль, и репутационные риски.
        Бизнес как раз-таки понимал, что время восстановления из бэкапа удовлетворяет требованиям показателя RTO. А вот обещанный трехдневный даунтайм бизнес не выдержал бы.

        А тут вообще рукалицо! Было полгода, в течении которых можно было:
        1. Связаться с провайдером и договорится о поэтапном ночном переносе серверов на новую площадку.
        2. Арендовать дополнительную площадку в облаке и развернуть там резервную инфраструктуру.
        3. Купить оборудование и развернуть на новой площадке провайдера или у другого провайдера. Сколько там того оборудования, если объем данных был 5ТБ? Даже если у них использовались тонкие клиенты, в чем я сомневаюсь, та максимум 10 стареньких серверов, которые спокойно могли переехать на 3-4 новых.
        В любом случае, резервная инфраструктура пригодится, если все так как описано в статье.
        Так что, скорее всего, клиент стоит провайдера, если он на самом деле такой, как вы его описали.

  10. ExplosiveZ
    /#11370708

    Не ожидал от КРОК такой унылой рекламы carbonite.

  11. uanet
    /#11370978 / +1

    У меня был опыт почудесатее: о переезде не предупреждали. Совсем. Это в США. Бац — всё выключилось, «надолго». Потом включилось. Поддержка реселлера поморозилась — но в итоге честно написали «мы не можем достучаться до хостера, спасайся, кто может». Тут каналам начало плохеть — я чуть раньше слил бОльшую часть, но потом бэкапиться кинулись все :). Этот цирк с неизвестностью был 3 дня! Потом оказалось — возили сервера между датацентрами (и это ещё продолжалось чуток времени), частями и криво настроив сеть (из мира — видим сервер 1 и сервер 2, но сервера друг друга — не видят), и, возможно, разбирая на части — тут понимаешь, что от потери 3 из 4 дисков спасёт только зеркало, RAIDZ2 не вынес такого :).
    А бизнес бывает с низкими прибылями — и таки дублировать инфраструктуру может быть не по карману. Это ж не просто «купить железо» — это и неплохо бы переписать софт, и расходы на содрежание железа… И или «авось» или услуга вырастет в цене и ты проиграешь конкуренту с «авось». Вот и выбирайте — «прибыль здесь и сейчас/вложение в разработку сервиса», или «развиваться не за что», или «отдел маркетинга должен напрячься».
    Короче, Интернет — эта такая вещь, в которой нужно готовиться к падению атомной бомбы в твой датацентр. Или материально — строя инфраструктуру, или морально — приняв грядущие проблемы как данность.

  12. hamnsk
    /#11371168 / -5

    сдается мне статья полный пиздешь, потому что денег на резерв у нас нет, но два часа простоя это год работы и риски, за год там что 500 рублей прибыль? или 5000? и нах такой бизнес где нет прибыли? хотя 5 ТБ данных, это бизнес должен быть очень крупным и приносить очень много бабосов, я помню огромную бд где было 1000 доков в минуту как раз для сиквела от мелкомягких там база была 250 гигов, не 5 тб, раз там 5 тб, там что все журналы транзакций хранились? или транзакшен лог не транкейтили? вобщем если так технически подойти то много не стыковок и похоже на пиздаболию. так долго переезжал караван, да у него были косяки при переезде, да тачки везли ночью и у них был даунтайм, но!!! они давали на время тачки всем клиентам в новом дц, и единственный гемор был только с дедиками тупо их переключить и потом данные смигрировать, облако вообще безшовно переключилось, а тут речь о виртуалках, кто мешал их смигрировать? в общем тупая рекламе этой софтины под винду, да еще приправленная пиздежом

    • willyd
      /#11371180

      хотя 5 ТБ данных

      5ТБ всего, как я понял. Это могут быть какие-то данные томографов, УЗИ и т.д.

  13. CherryPah
    /#11371334

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

    • RenatS
      /#11372078

      В SLA есть приоритизация заявок. Обращения с наименьшим severity действительно имеют срок реакции «в течение трёх дней». А физический доступ провайдер не предоставляет заказчикам из тех соображений, что оборудование принадлежит провайдеру. Это нормальная практика для поставщиков услуг IaaS.

  14. Gasaraki
    /#11373484

    В который раз убеждаюсь мысли что в облака надо идти с очень серьезной подготовкой к рискам. На тех же дедиках с установленной виртуализацией проблемы просто не было бы — арендуется во втором цоде сервер(а), внутри гипервизоров ставишь виртуальные комутаторы, строишь внутренние L2 туннели, собираешь кластер (зависит от системы гипервизоров), настраиваешь шейпинг на виртуальных коммутаторах, настраиваешь проброс в dmz, далее запускаешь живую миграцию. На время переезда конечно из-за скорости интернет канала возможна просадка производительности, но прерывания сервиса не будет. Во время переезда настраиваешь ttl dns'ов на 60 секунд, затем после переезда меняешь A запись(до этого времени будет работать проброс на коммутаторе через l2 туннель первого провайдера). После этого отказываешься от старого провайдера.

    И в современных реалиях на дедиках надо брать ssd, они кстати и нагрузку на проц снимают довольно существенно при нагруженной базе и переезды становятся быстрее.