Comments 32
это ПО крайне просто разворачивать, и без какого-либо дополнительного тюнинга
Настройки Compession Level и Storage Optimization в тестовых заданиях у вас остались по умолчанию?
Вероятнее всего, отказ связан с потерей Write-back кэша массива из-за его горячего отключения
Простите, то есть кэш на запись есть. а его батарейной защиты нет?
Батарейки в массиве конечно же есть. Честно сказать — расследования, что именно привело к отказу виртуалки никто не проводил, да и суть была не в этом, а в том, что бы понять — какими средствами можно защитить данную систему от выхода из строя.
Упала виртуальная машина, причем, из-за отвала SAN-диска, чем тут батарейка поможет?
Юзаем DD2200, есть там DD VTL
Спасибо за интересный пост.
Кстати, у DellEMC для DD VE есть готовые конфигурации на базе сервера R730 c локальными HDD. Выглядит интересно. Дюже любопытно было бы у видеть тест производительности по сравнению с железным DD в одинаковой конфигурации по дискам.
Есть еще IBM ProtectTIER, но он, похоже, «скорее мертв, чем жив». А виртуальной его версии IBM так и не сподобилась сделать.
Смущает во всей этой дедупликационной идеологии РК один момент (если я все правильно понимаю): получается, что мы целиком и полностью зависим от самого первого бекапа. Если его по какой-то причине профукали, то никаких бекапов по сути больше нет. Это так? Есть ли в таких дедупликаторах возможность делать независимые «настоящие» фулл-бекапы, скажем, по требованию?
А вариант отдельно стоящей и доступной по NFS СХД Netapp c инлайн-дедупом и компрессией стоит рассматривать как альтернативу DD/StoreOnce?
Кстати, у 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
не думаю, что есть смысл сравнивать All-Flash Netapp с данными продуктами. Тут уместнее брать аналогичную поделку от Нетаппа — Altavault
Дюже любопытно было бы у видеть тест производительности по сравнению с железным DD в одинаковой конфигурации по дискам.
Я бы не отказался, но пока моё сотрудничество с Dell/EMC не очень перспективно, к сожалению.
Есть еще IBM ProtectTIER, но он, похоже, «скорее мертв, чем жив».
Я пока вообще не очень представляю перспективы IBM. Watson — да, ПО вокруг него — да, что то иное — под вопросом.
зависим от самого первого бекапа
Если мы говорим с точки зрения ПО для РК, то да, если мы говорим с точки зрения хранения блоков данных на таких массивах, то в них имеются технологии, отвечающие за целостность данных (блоков) и тут можно не переживать. С точки зрения ПО для РК — никто не запрещает делать постоянно фульники, с учётом как раз Catalyst/DDboost — это очень эффективно, т.к. передадутся и запишутся только уникальные блоки. Да, такая процедура РК будет проходить дольше, чем инкрементные, но и надёжность выше.
А вариант отдельно стоящей и доступной по NFS СХД Netapp c инлайн-дедупом и компрессией стоит рассматривать как альтернативу DD/StoreOnce?
Я бы не стал этого делать по двум причинам — скорее всего нетап окажется дороже, тк нужен минимум FAS серии, во-вторых уровень инлайн-дедупа и компрессии там будет ниже (1:2-1:3 по нашим наблюдениям).
Интересная статья, особенно, полезно, на мой взгляд, было включение в сравнение встроенной дедупликацию средствами самого Veeam. Это хорошая фича для небольших объемов, но результаты на практике показывают, что специализированные устройства (или их виртуальные версии), как Store Once или Data Domain все же работают существенно эффективнее.
По методике тестирования — в случае с терминальными серверами после четвертого инкрементального бэкапа Data Domain сделал очистку — это несколько искажает результаты, тем более, что у HPE он не работал. Не принципиально на таких объемах, но все же.
К разговору про остальные решения на рынке:
Quantum DXi V-Series это как раз и есть виртуальная версия их аппаратного решения DXi. Было бы интересно увидеть их в сравнении, хотя скорее всего значения дедупликации будут примерно теми же.
Есть еще FalconStor VTL (есть в виде виртуальной машины), Hitachi Protection Platform (вроде нет в виде виртуальной машины).
По методике тестирования — в случае с терминальными серверами после четвертого инкрементального бэкапа Data Domain сделал очистку — это несколько искажает результаты, тем более, что у HPE он не работал. Не принципиально на таких объемах, но все же.
К разговору про остальные решения на рынке:
Quantum DXi V-Series это как раз и есть виртуальная версия их аппаратного решения DXi. Было бы интересно увидеть их в сравнении, хотя скорее всего значения дедупликации будут примерно теми же.
Есть еще FalconStor VTL (есть в виде виртуальной машины), Hitachi Protection Platform (вроде нет в виде виртуальной машины).
Quantum DXi V-Series
Каюсь, моя ошибка. Спасибо за уточнение.
Про остальные решения:
Есть еще одно интересное GRID решение NEC HYDRAstor, которое также имеет виртуальную версию HS VA и свой протокол с дедупликацией на стороне источника UEIO.
Есть еще одно интересное GRID решение NEC HYDRAstor, которое также имеет виртуальную версию HS VA и свой протокол с дедупликацией на стороне источника UEIO.
Примерно полгода назад сравнивал Online-дедупликацию HP StoreOnce Virtual Appliance и Offline-дедупликацию на Windows Server 2012 R2.
Хотелось понять — при разном подходе к задаче, какой коэффициент дедупликации я получу на одинаковод наборе данных (дедуплицировал 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 файл, шарю каталог — и мне становятся доступны мои данные. Плюс раз в полгода можно файл обновить и снова дедуплицировать.
Хотелось понять — при разном подходе к задаче, какой коэффициент дедупликации я получу на одинаковод наборе данных (дедуплицировал 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 бакапить.
Объяснять про разницу source и target депупликации и влияние их на загрузку канала нужно?
Дедупить на источнике умеет любой вменяемый софт резервного копирования. Причем тут NAS?
Но это не означает что backup агенты нужно везде рассовывать. По хорошему NAS тоже должен уметь жать и дедупить.
Такое ощущение, что вы или не читали статью или не поняли весь смысл таких вещей, как Data Domain, StoreOnce и иже с ними. То, что ПО для РК делает хуже, чем специалиализированные средства — статья показывает наглядно. Да и нет ничего хорошего в том, что у вас одни и те же данные дедупятся и жмутся несколько раз разными средствами.
Либо мы говорим просто по совершенно разные объёма РК, раз вас устраивает 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 и супермикру? :)
Sign up to leave a comment.
Жим лёжа: сравниваем HPE StoreOnce и EMC Data Domain