Есть очень крупная сеть магазинов по России. Каждый магазин бэкапится на ленточную библиотеку (ниже на фото — ЗИП). Дальше они берут кассеты и везут их на машине в архив.
Устройства механические: они ломаются, выходят из строя, мы ездим чинить. Потом они сходят с расширенной гарантии, и это всех бесит.
В какой-то момент они устарели. Но бюджета было ровно на новую версию ленточной библиотеки. В этот момент заказчик появился у нас на пороге с энной суммой и спросил, можно ли что-то придумать в её рамках.
Мы было подумали про центральную инсталляцию одной большой железки, но ситуация осложнялась тем, что каналы от магазинов ограничены 5 Мбит/с (от самых дальних).
При изучении инфраструктуры оказалось, что в центральном офисе уже установлен Dell EMC Data Domain. Правда, для их офисных задач. И в офисе игрушкой давно и успешно пользуются. Они знают, как с ней работать, она совместима с их ПО бэкапа и прочно вписана в инфраструктуру. Теперь — уточнение задачи: есть магазины, ленты, деньги. Локально их надо хранить в магазине до трёх месяцев, дальше не в магазине данные должны быть доступны до 10 лет по ряду показателей. Это нужно по требованиям регулятора и внутренним политикам.
Есть пожелания не заморачиваться с лентами. Требований по скорости особо нет. Но очень хотелось бы минимизировать количество ручных операций админа и уменьшить вероятность невосстановления. С лентой это, увы, случается. Одна лента сломалась — копии хана, потому что избыточности нет.
Решили предложить рассмотреть альтернативы лент: перенос бэкапов в S3-совместимое хранилище. Понятное дело, можно встать в Амазон, MS-облако, к нам в публичное облако — куда угодно, где есть объектные хранилища с определёнными SLA. А можно взять и смонтировать прямо в офисе небольшое частное облако. Именно такое решение есть у Dell EMC: можно привезти железки в офис и получить инсталляцию облака. А Dell EMC — уже привычный вендор, поэтому вопросы интеграции сильно легче, чем во всех других случаях.
Плюс уже есть дата-домен, который может делать дедупликацию. А передача дедуплицированных данных на него позволяет очень сильно уменьшить трафик.
По просьбе заказчика сделали сравнительный анализ стоимости: Dell EMC на площадке, наше облако КРОК и MS.
Dell EMC ECS — большая закупка, там надо продлевать поддержку, размещать в серверной и ЦОДе. Мы рассматривали в горизонте 10 лет, и получалось дороже из-за того, что минимальная конфигурация сильно избыточна и потому стоит, как крыло от самолёта, а заплатить надо сразу плюс потом продлевать поддержку (за доллары, которые непонятно сколько будут стоить через 3–5–7 лет) и держать в уме даты end of sale и end of support. MS-хранилище с той же степенью резервирования дороже. Особенность нашего S3 — автоматически раскидывать данные на три географически разделённые площадки. У MS тариф на геораспределённость выше.
В итоге заказчик посмотрел и попросил пилот в нашем S3. Давайте, говорит, посмотрим, заработает ли. Потому что вендоры говорят: у нас поддержка Амазона, Ажура и Гугл.клауд, а заработает ли это решение с нами, никто не знает.
Смысл в том, чтобы класть «горячие» данные на хранилище, а потом сгружать старые копии с хранилища в облако в том же формате, что они лежат на хранилище.
Мы делали тестирование Dell EMC Data Domain. У них заявлено, что они могут перекладывать свои копии с себя на S3. Dell EMC DD заработал, их поддержка нам с огромным энтузиазмом помогла, потому что инженер на той стороне прям радовался этой задаче, говорил: классная история с Veeam!
Дальше мы столкнулись с тем, что у Dell ЕМC есть особенность: так сделано, что данные сначала складываются на 14 дней на железку и только потом могут быть выгружены в облако. Инженеры говорят, это зашито глубоко, и это логика разработчиков: эти два цикла хранения прописаны чуть ли не в хардкоде. Больше — можно, меньше — никак. Считается, что две недели — это время хранения, когда юзер хочет восстановиться.
Если данные уже перенесены в облако — мы их вернули обратно, из них восстановились, и они снова 14 дней лежат, прежде чем уехать.
Мы бы хотели поставить неделю, но вся королевская рать и вся конница не смогли нам помочь.
Результат — уложились в заданный бюджет без лент, учли все стоимости работ-поддержек и внедрили более надёжное решение с геораспределением. Ну и порадовали одного инженера на стороне вендора, который был счастлив, что в этом мире есть люди, которые умеют думать: это я сейчас про команду админов сети магазинов.
Устройства механические: они ломаются, выходят из строя, мы ездим чинить. Потом они сходят с расширенной гарантии, и это всех бесит.
В какой-то момент они устарели. Но бюджета было ровно на новую версию ленточной библиотеки. В этот момент заказчик появился у нас на пороге с энной суммой и спросил, можно ли что-то придумать в её рамках.
Мы было подумали про центральную инсталляцию одной большой железки, но ситуация осложнялась тем, что каналы от магазинов ограничены 5 Мбит/с (от самых дальних).
Нашёлся Data Domain
При изучении инфраструктуры оказалось, что в центральном офисе уже установлен Dell EMC Data Domain. Правда, для их офисных задач. И в офисе игрушкой давно и успешно пользуются. Они знают, как с ней работать, она совместима с их ПО бэкапа и прочно вписана в инфраструктуру. Теперь — уточнение задачи: есть магазины, ленты, деньги. Локально их надо хранить в магазине до трёх месяцев, дальше не в магазине данные должны быть доступны до 10 лет по ряду показателей. Это нужно по требованиям регулятора и внутренним политикам.
Есть пожелания не заморачиваться с лентами. Требований по скорости особо нет. Но очень хотелось бы минимизировать количество ручных операций админа и уменьшить вероятность невосстановления. С лентой это, увы, случается. Одна лента сломалась — копии хана, потому что избыточности нет.
Наш вариант
Решили предложить рассмотреть альтернативы лент: перенос бэкапов в S3-совместимое хранилище. Понятное дело, можно встать в Амазон, MS-облако, к нам в публичное облако — куда угодно, где есть объектные хранилища с определёнными SLA. А можно взять и смонтировать прямо в офисе небольшое частное облако. Именно такое решение есть у Dell EMC: можно привезти железки в офис и получить инсталляцию облака. А Dell EMC — уже привычный вендор, поэтому вопросы интеграции сильно легче, чем во всех других случаях.
Плюс уже есть дата-домен, который может делать дедупликацию. А передача дедуплицированных данных на него позволяет очень сильно уменьшить трафик.
По просьбе заказчика сделали сравнительный анализ стоимости: Dell EMC на площадке, наше облако КРОК и MS.
Dell EMC ECS — большая закупка, там надо продлевать поддержку, размещать в серверной и ЦОДе. Мы рассматривали в горизонте 10 лет, и получалось дороже из-за того, что минимальная конфигурация сильно избыточна и потому стоит, как крыло от самолёта, а заплатить надо сразу плюс потом продлевать поддержку (за доллары, которые непонятно сколько будут стоить через 3–5–7 лет) и держать в уме даты end of sale и end of support. MS-хранилище с той же степенью резервирования дороже. Особенность нашего S3 — автоматически раскидывать данные на три географически разделённые площадки. У MS тариф на геораспределённость выше.
В итоге заказчик посмотрел и попросил пилот в нашем S3. Давайте, говорит, посмотрим, заработает ли. Потому что вендоры говорят: у нас поддержка Амазона, Ажура и Гугл.клауд, а заработает ли это решение с нами, никто не знает.
Смысл в том, чтобы класть «горячие» данные на хранилище, а потом сгружать старые копии с хранилища в облако в том же формате, что они лежат на хранилище.
Мы делали тестирование Dell EMC Data Domain. У них заявлено, что они могут перекладывать свои копии с себя на S3. Dell EMC DD заработал, их поддержка нам с огромным энтузиазмом помогла, потому что инженер на той стороне прям радовался этой задаче, говорил: классная история с Veeam!
Дальше мы столкнулись с тем, что у Dell ЕМC есть особенность: так сделано, что данные сначала складываются на 14 дней на железку и только потом могут быть выгружены в облако. Инженеры говорят, это зашито глубоко, и это логика разработчиков: эти два цикла хранения прописаны чуть ли не в хардкоде. Больше — можно, меньше — никак. Считается, что две недели — это время хранения, когда юзер хочет восстановиться.
Если данные уже перенесены в облако — мы их вернули обратно, из них восстановились, и они снова 14 дней лежат, прежде чем уехать.
Мы бы хотели поставить неделю, но вся королевская рать и вся конница не смогли нам помочь.
Итог
- Veeam собирает бэкапы со всех объектов магазина и отдаёт в Data Domain, как обычно. Про S3 он ничегошеньки не знает.
- Инстансы Data Domain дедуплицируют трафик на местах и при необходимости могут передавать реплики в центральный офис.
- Cloud Tier встроен в дата-домен, она автоматически переносит данные в S3 в наших дата-центрах.
- Когда юзеру нужно что-то вытаскивать из бэкапа, он стучит в Veeam. Veeam стучит в свою систему записи, система записи стучит в свой «диск» (физический или S3) и достаёт копию. Всё довольно красиво интегрировано.
Результат — уложились в заданный бюджет без лент, учли все стоимости работ-поддержек и внедрили более надёжное решение с геораспределением. Ну и порадовали одного инженера на стороне вендора, который был счастлив, что в этом мире есть люди, которые умеют думать: это я сейчас про команду админов сети магазинов.
Ссылки
- Бэкапы заказчиков (2016)
- Бэкап в ЦОДе (2012)
- Моя почта для связи — EKorotkikh@croc.ru
