Comments 32
это ПО крайне просто разворачивать, и без какого-либо дополнительного тюнинга
Настройки Compession Level и Storage Optimization в тестовых заданиях у вас остались по умолчанию?
Вероятнее всего, отказ связан с потерей Write-back кэша массива из-за его горячего отключения
Простите, то есть кэш на запись есть. а его батарейной защиты нет?
Упала виртуальная машина, причем, из-за отвала SAN-диска, чем тут батарейка поможет?
Кстати, у DellEMC для DD VE есть готовые конфигурации на базе сервера R730 c локальными HDD. Выглядит интересно. Дюже любопытно было бы у видеть тест производительности по сравнению с железным DD в одинаковой конфигурации по дискам.
Есть еще IBM ProtectTIER, но он, похоже, «скорее мертв, чем жив». А виртуальной его версии IBM так и не сподобилась сделать.
Смущает во всей этой дедупликационной идеологии РК один момент (если я все правильно понимаю): получается, что мы целиком и полностью зависим от самого первого бекапа. Если его по какой-то причине профукали, то никаких бекапов по сути больше нет. Это так? Есть ли в таких дедупликаторах возможность делать независимые «настоящие» фулл-бекапы, скажем, по требованию?
А вариант отдельно стоящей и доступной по NFS СХД Netapp c инлайн-дедупом и компрессией стоит рассматривать как альтернативу DD/StoreOnce?
Кажется, вы перепутали инкрементальный бэкап с дедупликацией. Дедупликация никак не влияет на содержимое бэкапа — это лишь способ его хранения.
По поводу НетАпп-а тоже было бы интересно посмотреть сравнение — очень они хвалят свою дедупликацию.
По поводу НетАпп-а тоже было бы интересно посмотреть сравнение — очень они хвалят свою дедупликацию.
Не бекап — работающие виртуальные машины на All-Flash'е NetApp'овском. Но для примера пойдёт, думаю.
Datastore Cluster : *****_AFF
Capacity (GB) : 9600
Used Space (GB) : 27816,58
Provisioned Space (GB) : 28130,67
Provisioned / Capacity ratio : 2,93
Storage Overcommit (%) : 193,03
Вот правильные цифры:
По поводу НетАпп-а тоже было бы интересно посмотреть сравнение — очень они хвалят свою дедупликацию.
Не бекап - работающие виртуальные машины на All-Flash'е NetApp'овском. Но для примера пойдёт, думаю.
Datastore Cluster : *****_AFF
Capacity (GB) : 4802
Used Space (GB) : 27816,58
Provisioned Space (GB) : 28130,67
Provisioned / Capacity ratio : 5,85
Storage Overcommit (%) : 585,81
Дюже любопытно было бы у видеть тест производительности по сравнению с железным DD в одинаковой конфигурации по дискам.
Я бы не отказался, но пока моё сотрудничество с Dell/EMC не очень перспективно, к сожалению.
Есть еще IBM ProtectTIER, но он, похоже, «скорее мертв, чем жив».
Я пока вообще не очень представляю перспективы IBM. Watson — да, ПО вокруг него — да, что то иное — под вопросом.
зависим от самого первого бекапа
Если мы говорим с точки зрения ПО для РК, то да, если мы говорим с точки зрения хранения блоков данных на таких массивах, то в них имеются технологии, отвечающие за целостность данных (блоков) и тут можно не переживать. С точки зрения ПО для РК — никто не запрещает делать постоянно фульники, с учётом как раз Catalyst/DDboost — это очень эффективно, т.к. передадутся и запишутся только уникальные блоки. Да, такая процедура РК будет проходить дольше, чем инкрементные, но и надёжность выше.
А вариант отдельно стоящей и доступной по NFS СХД Netapp c инлайн-дедупом и компрессией стоит рассматривать как альтернативу DD/StoreOnce?
Я бы не стал этого делать по двум причинам — скорее всего нетап окажется дороже, тк нужен минимум FAS серии, во-вторых уровень инлайн-дедупа и компрессии там будет ниже (1:2-1:3 по нашим наблюдениям).
По методике тестирования — в случае с терминальными серверами после четвертого инкрементального бэкапа Data Domain сделал очистку — это несколько искажает результаты, тем более, что у HPE он не работал. Не принципиально на таких объемах, но все же.
К разговору про остальные решения на рынке:
Quantum DXi V-Series это как раз и есть виртуальная версия их аппаратного решения DXi. Было бы интересно увидеть их в сравнении, хотя скорее всего значения дедупликации будут примерно теми же.
Есть еще FalconStor VTL (есть в виде виртуальной машины), Hitachi Protection Platform (вроде нет в виде виртуальной машины).
Quantum DXi V-Series
Каюсь, моя ошибка. Спасибо за уточнение.
Есть еще одно интересное GRID решение NEC HYDRAstor, которое также имеет виртуальную версию HS VA и свой протокол с дедупликацией на стороне источника UEIO.
Хотелось понять — при разном подходе к задаче, какой коэффициент дедупликации я получу на одинаковод наборе данных (дедуплицировал 350 гб образов виртуальных машин в первом тесте, и 220 гб дистрибутивов (ISO-файлы)).
На обоих наборах данных я получал похожие цифры (разница была 3-5%, не более. Но HP StoreOnce VSA сжимал чуть чуть лучше).
Первый набор (виртуалки) у меня сжался в 7,5 раз. Второй (ISO) — в 2,5 раза.
Вообще дедупликацию от Microsoft хорошо использовать для долгосрочного (от полугода) хранения хорошо дедуплицируемых данных. Например — оба описанных набора данных я храню в VHDX-файлах, внутри которых отработала дедупликация.
Пример скрипта, который делает такое, тут:
How-to-store-183-GB-of-VMs-in-a-16-GB-file-using-PowerShell
В случае необходимости — на сервере монтирую VHDX файл, шарю каталог — и мне становятся доступны мои данные. Плюс раз в полгода можно файл обновить и снова дедуплицировать.
Проще на NAS с дедупом и компрессией по NFS бакапить.
Дедупить на источнике умеет любой вменяемый софт резервного копирования. Причем тут NAS?
Но это не означает что backup агенты нужно везде рассовывать. По хорошему NAS тоже должен уметь жать и дедупить.
Либо мы говорим просто по совершенно разные объёма РК, раз вас устраивает NAS.
В курсе, как работает HPE catalyst, и Data Domain Boost.
Сделать Scalable NAS давно не проблема.
На своём веку я видел в ЦОД десятки заброшенных backup appliance, в том числе DD, без купленных подписок, с старым ПО как дерьмо мамонта.
Меня малость настораживает, зачем облачный провайдер с остервенением тащит в свой ЦОД проприетарщину? Кто будет оплачивать банкет? Госсектор, российский true bloody enterprise?
Сделать Scalable NAS давно не проблема.
Никто и не говорил, что это проблема — выгода в этом какая? Чего можно добиться с его помощью?
На своём веку я видел в ЦОД десятки заброшенных backup appliance, в том числе DD, без купленных подписок, с старым ПО как дерьмо мамонта.
Мне кажется, что не только заброшенных backup appliance удалось повидать, но это не имеет никакого отношению к ПО или железу и его эффективности/стоимость/etc., а лишь к его эксплуататорам.
Меня малость настораживает, зачем облачный провайдер с остервенением тащит в свой ЦОД проприетарщину?
Всем срочно перейти на open source и супермикру? :)
Жим лёжа: сравниваем HPE StoreOnce и EMC Data Domain