Блог компании КРОК Облачные сервисы
IT-инфраструктура
Виртуализация
Комментарии 49
+14
Перенеси бы прошлый провайдер этого клиента в первую очередь с минимальным даунтаймом всячески помогая клиенту, лояльность клиента выросла бы значительно, и они остались бы довольны сервисом еще надолго.
+1
А затем делать уже две площадки после того, как этот кризис закончится.
Надеюсь догадаются делать вторую площадку у третьего провайдера :)
-2

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


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

0

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

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

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

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

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

+2

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

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

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

0

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

0

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

+2
>один день простоя грозит финансовыми и имиджевыми потерями, равными годовой прибыли
>Бюджета на аварийную дублирующую площадку у вас нет

Завязка помоему вообще из пальца высосана.
0

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

0

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

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


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

Интрига, в общем!
0
Нам повезло, что заказчик имел копию при себе. Естественно, у нее был некоторый срок давности, но основной объем данных был актуальный. А через канал накатили разницу средствами БД.
0
Да, тогде никакой интриги, никакого чуда. Впрочем, и хорошо: чудеса при переезде чреваты.
+2
настало время офигительных историй )))
upd: интриги не получилось
-5
утилизирует этот канал

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


«диджитал» же. Все, кому не лень, это слово лепят, оно нынче модное… ах, простите, оно нынче — «в тренде»!
+7
Ждем в тред техдира исходного провайдера, с его рассказом, какой заказчик был геморойщик, и как они ему полгода жизни отдали, а он взял, и обманом свалил — и к кому! #шутка
0
Лучше распишите, с чего все началось. Я думаю, что история будет поучительна в том как планировать. А то у вас получилось, что провайдер просто бездарь и негодяй, а клиент — ясно солнышко. Как я написал выше, мне почему-то кажется, что клиент затянул с планированием переезда, а потом в самый напряженный период сказал, что переезжает к другим. Со стороны прибыли для провайдера вопрос в приоритете в таком случае как бы ясен.
К данному провайдеру и хостерам вообще отношения не имею, от слова совсем.
0
клиент затянул с планированием переезда, а потом в самый напряженный период сказал, что переезжает к другим
И что, это даёт провайдеру право динамить клиента с тех. поддержкой и расширением канала?
0
Я это не писал. Если действительно дело было, как описано, без всяких объяснений и попыток договорится, то тогда все понятно. Но вся история смотрится как-то нелепо, вы не находите? Причем изложена она конкурентом, который уводил клиента. Да и задача этой статьи больше в пиаре софта, чем в передаче истины. Как на самом деле было дело никто не узнает.
0
Вот это как нужно было понять:
Со стороны прибыли для провайдера вопрос в приоритете в таком случае как бы ясен
Я это понял — раз клиент всё равно уходит, можно его обслуживать с низким приоритетом.
+1
Именно так.
Если бы у меня был страшный аврал, я бы мог отложить этого клиента на свободное время в конце. И скорее всего, тоже бы отказал ему в расширении канала, поскольку данные под конец срока переливали все. Я бы, конечно, объяснил клиенту ситуацию, и убедил, что у него все будет хорошо, но не сейчас. Все бы зависело от реальной ситуации.
Как себя вел провайдер мы не заем. Как себя вел клиент мы не знаем. Судить обо всем этом достаточно тяжело.
К примеру. У меня сейчас чем-то похожая ситуация, взял проект без должного ТЗ, на время пока у меня простой. Все данные по ТЗ приходится выдирать клещами, из-за этого он практически не продвигается. Со следующей недели у меня будет много работы от основного заказчика, и этот проект даже при идеальном ТЗ будет продвигаться очень медленно. И меня будут делать виноватым, и рассказывать, что я подвел со сроками, сорвал проект и т.д. и т.п.
0
И что, это даёт провайдеру право динамить клиента
Я это не писал.
этот проект даже при идеальном ТЗ будет продвигаться очень медленно
Теперь написали. Стало понятно, это изначально подразумевалось как нечто в порядке вещей.

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

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

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

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

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


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

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

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

Единственный вариант — покупать землю и строить ДЦ самому. И то — экскаваторщики обязательно умудрятся окопать весь участок по периметру и порвать все аплинки. А не купишь землю — тебя арендатор выпнет. Ещё и одолжение сделает — за целых 2 месяца предупредит.
+1
Бизнес как раз-таки понимал, что время восстановления из бэкапа удовлетворяет требованиям показателя RTO. А вот обещанный трехдневный даунтайм бизнес не выдержал бы.
0
Я понимаю, что статья маркетинговая, попиарить карбонит. Но все же.
Бюджета на аварийную дублирующую площадку у вас нет.

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

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

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

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

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

0
В SLA есть приоритизация заявок. Обращения с наименьшим severity действительно имеют срок реакции «в течение трёх дней». А физический доступ провайдер не предоставляет заказчикам из тех соображений, что оборудование принадлежит провайдеру. Это нормальная практика для поставщиков услуг IaaS.
+1
В который раз убеждаюсь мысли что в облака надо идти с очень серьезной подготовкой к рискам. На тех же дедиках с установленной виртуализацией проблемы просто не было бы — арендуется во втором цоде сервер(а), внутри гипервизоров ставишь виртуальные комутаторы, строишь внутренние L2 туннели, собираешь кластер (зависит от системы гипервизоров), настраиваешь шейпинг на виртуальных коммутаторах, настраиваешь проброс в dmz, далее запускаешь живую миграцию. На время переезда конечно из-за скорости интернет канала возможна просадка производительности, но прерывания сервиса не будет. Во время переезда настраиваешь ttl dns'ов на 60 секунд, затем после переезда меняешь A запись(до этого времени будет работать проброс на коммутаторе через l2 туннель первого провайдера). После этого отказываешься от старого провайдера.

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