Заморские купцы говаривали, что дедупликация может существенно сэкономить место, необходимое для хранения резервных копий. Что есть в заморских землях такие люди, кто годовую историю резервных копий умещает в том же объёме, что занят на рабочих серверах. Вроде как копируешь 10 Терабайт данных изо дня в день цельный год, а на устройстве хранения резервных копий те же 10 Терабайт и заняты. Брешут, наверное.
Однако, есть хороший способ проверить, как же данные многочисленных резервных копий конкретно наших серверов могут быть упакованы в хранилище с дедупликацией и компрессией. При этом не нужно разворачивать целую систему резервного копирования, а достаточно скачать одну маленькую (4 Мегабайта) утилиту, которая выдаст нам не только картину того, как можно пожать данные прямо сейчас, но и построит прогноз того, сколько памяти нам потребуется в будущем.
Для начала – качаем утилиту вот отсюда:
http://downloads.arcserve.com/tools/RPSPlanning/unsupported/DeduplicationPlanningTool/V1.0/ArcserveUDPDataStoreCapacityPlanningTool.zip
Хоть архив и небольшой, но утилита требовательная:
- для работы нужна 64-битная система Windows (желательно, серверная. У меня на Windows 7 отработала нормально, всё посчитала и нарисовала, но при выходе свалилась).
- каждые 100 Гигабайт сканированных данных могут потребовать при обработке статистики до 1 Гигабайта оперативной памяти на компьютере, где мы запускаем утилиту (это можно обойти, если использовать SSD вместо оперативной памяти).
- должны быть открыты порты 10000 и 135 (какие — не уточняется, предположу, что TCP)
- запускать её нужно из-под администратора
Если всё необходимое у нас есть, разворачиваем архив куда угодно и запускаем ArcserveDeduplicationAssessment.exe
Затем добавляем интересующие нас сервера в список обследуемых, нажав на кнопку “Add Node”:
После этого на указанный нами сервер будет удалённо установлена программа-пробник, которую можно увидеть в списке сервисов:
Кстати, по завершению работы с утилитой программу-пробник предложат удалить:
А пока запустим сбор статистики, нажав на кнопку “Scan Nodes”.
По умолчанию приоритет задачи сбора статистики выставлен в низкий уровень, уступая процессорное время более приоритетным задачам.
Это можно изменить, если сбор статистики слишком затягивается.
На экране отображается процент выполненных работ на каждом из исследуемых серверов:
По завершению сбора статистики переходим на закладку 2 и строим отчёт. Имеет смысл отметить галочками все даты, когда была собрана статистика. Это позволит увидеть данные в динамике:
Теперь на закладке 3 мы можем воспользоваться полученными данными и, поиграв параметрами, определить потребность в объёмах хранилища резервных копий и конфигурацию сервера хранения резервных копий Arcserve UDP.
На примере ниже мы видим следующее:
- Полные резервные копии двух исследуемых машин занимают 35,54 Гигабайта
- Мы хотим хранить историю из 31 резервной копии
- Каждая новая резервная копия отличается от предыдущей на 17%
- Размер блока данных при дедупликации выбираем 4 Килобайта
- Используем стандартную компрессию (без фанатизма, дли минимизации загрузки процессора)
На выходе получаем, что для хранения 31 резервной копии этих машин нам потребуется 76,85 Гигабайт памяти, что означает экономию в 94%:
(Также можно увидеть, какие требования будут к оперативной памяти сервера хранения резервных копий Arcserve UDP. В данном случае будет необходимо 1,19 Гб опративной памяти либо 0,06 Гб оперативной памяти в сочетании с 1,19Гб места на SSD-диске).
Нажав на “Show Details” увидим более подробную информацию.
Если мы делаем только полные резервные копии (“Full Always”), то дедупликация сократит их общий объём (1282,99 Гигабайт) на 91% до 118,90 Гигабайт.
Компрессия сократит этот объём ещё на 35%, то есть до 78,85 Гигабайт.
Если мы используем резервное копирование в режиме “Incremental Forever” (только инкрементные копии вслед за одной полной), то требуемое место для хранения резервных копий не изменится и также составит 78,85 Гигабайт. Просто нам придётся выполнить меньше вычислений для дедупликации, а следовательно, меньше будут загружены рабочие серверы:
Теперь посмотрим на закладку с графиками.
Выберем тип графика “Disk and Memory Usage Trend”.
Хорошо видно, что добавив к первой резервной копии в 35 Гигабайт вторую (тоже 35 Гигабайт), мы нуждаемся в 70 Гигабайтах памяти, как показано слева синим графиком.
Однако, если мы используем дедупликацию, потребности в памяти для резервных копий существенно сокращаются. Зелёный, оранжевый и фиолетовый графики показывают нам необходимые объёмы в зависимости от уровня компрессии, применяемой вместе с дедупликацией.
На правом графике видно, как растёт потребность в оперативной памяти (или оперативной памяти в сочетании с SSD-диском) на сервере хранения резервных копий Arcserve UDP.
Если мы выберем тип графика “Disk and Memory Usage”, то увидим, как влияет на потребность в памяти размер блока, применяемый при дедупликации. Видно, что увеличение размера блока несколько снижает эффективность дедупликации, но также уменьшает требования к быстрой памяти (оперативной или SSD) на сервере хранения резервных копий Arcserve UDP:
После выхода из программы данные статистики не удаляются, даже если вы удалите программы-пробники на рабочих серверах. Эти данные могут быть использованы в будущем для построения графиков, отображающих изменения в потребностях в памяти.
Описанная утилита включена в дистрибутив продукта Arcserve UDP, устанавливается вместе с ним в каталог “…\Program Files\Arcserve\Unified Data Protection\Engine\BIN\Tools\RPS Planning”, но может быть загружена и сама по себе, как указано выше.
Утилита не является поддерживаемым продуктом, то есть официально обратиться в техподдержку вы не сможете. Но это компенсируется её необычайной простотой и бесплатностью.
Больше узнать о продуктах Arcserve вы сможете, почитывая наш блог, и посетив ссылки, приведённые в правой колонке,
Комментарии (27)
Taciturn
16.06.2016 07:51Не хватает краткого описания преимуществ по сравнению со встроенной в ОС (начиная с Server 2012) дедупликацией.
MikhailMitroshin
16.06.2016 08:331. Принципиальное отличие в том, что встроенная в ОС дедупликация выполняется в офлайне.
То есть:
— Оставляйте свои данные, мы ими займёмся.
— А когда будут готовы?
— Мы вам позвоним.
Вы (а) не можете предсказать, когда занятое место на диске уменьшится, (б) успеет ли оно уменьшится к тому моменту, когда нужно будет делать следующую копию, следующую за следующей…, (в) не можете предсказать заранее, НАСКОЛЬКО уменьшится занятое место.
В то же время онлайн-дедупликация в Arcserve UDP сразу же выдаёт данные в дедуплицированном виде. Правда, цена за это — повышенные требования к быстрой памяти (оперативной или SSD), где должна помещаться вся таблица хэшей.
2. Дедупликация в Arcserve UDP производится на источнике, то есть ещё перед передачей по сети. Вы не только ужимаете полную копию на, например, 91%, но и сокращаете сетевой трафик на 91% (за вычетом служебных данных Ethernet/TCP/IP).
ibKpoxa
16.06.2016 11:39+1Дедупликация в Arcserve UDP производится на источнике, то есть ещё перед передачей по сети. Вы не только ужимаете полную копию на, например, 91%, но и сокращаете сетевой трафик на 91% (за вычетом служебных данных Ethernet/TCP/IP).
А если источник это прод, но дедупликация на нем может вызвать деградацию производительности основного сервиса. Какой у вас выход в данном случае?MikhailMitroshin
16.06.2016 12:39— Максимально использовать инкрементные копии. Проверку на повторяемость будут проходить не все блоки диска, а только те, что помечены, как изменённые.
— Если сервер виртуальный, то копировать его без установки агента (брать снапшот с гипервизора) и проводить дедупликацию на машине, установленной рядом.
— «Душить» скорость копирования (network throttling) встроенными средствами, «размазывая» нагрузку на процессор по времени.
Но необходимость в этом возникает нечасто. В реальной жизни инкрементные копии на уровне блоков могут проскакивать за считанные минуты глубокой ночью.
divanikus
16.06.2016 17:14Меня сильно смущает дедупликация в контексте резервного копирования. Фактически повредив один блок в результирующей копии мы потеряем их все. Как-то опасно…
MikhailMitroshin
16.06.2016 22:43Любая технология резервного копирования подразумевает, что должна проводиться периодическая проверка восстановимости. И дело не только в дедупликации.
Лично мне приходилось сталкиваться с такими двумя случаями:
1. Копирование на ленточный привод годами проходило без ошибок. Ленты подписывались и складывались в шкафчик. Когда возникла необходимость восстановить данные, оказалось что ленты пусты. Ни разу никто не проверил, действительно ли на лентах что-то записано или нет.
2. Снова лента. Долгое время проводилось ежедневное резервное копирование сервера с базой данных Oracle. Операционная система стояла на диске C:, база данных — на диске D:. Когда сервер рухнул, оказалось, что копировался только бесполезный диск C:, про диск D: забыли при создании задания на резервное копирование.
Что я хочу этим сказать? Если бы люди хоть раз провели бы тестовое восстановление, то ошибки всплыли бы.
Точно также и с дедупликацией. Если есть регламент проверки восстановимости, то можно положиться на такую систему.
Для пущей уверенности держать несколько серверов хранения резервных копий и периодически переливать хранилище на отчуждаемый носитель (магнитную ленту).
zapimir
А технические подробности по дедупликации можно?
К примеру фиксированные блоки или скользящие? Какой хэш используете для сравнения блоков?
MastaLomaster
del
MikhailMitroshin
Вы можете выбрать, какой размер блока использовать при дедупликации: 4,8,16 или 32 Килобайта. На последней картинке видно, как размер блока влияет на эффективность дедупликации и потребность в быстрой памяти (оперативной или SSD).
В предыдущих версиях программы резервного копирования Arcserve UDP по умолчанию предлагали использовать блок данных в 4 Килобайта. Теперь стали рекомендовать 16 Килобайт.
Используемый хэш — SHA1.
zapimir
Ну я имею ввиду блоки строго от начала файла идут или скользят по всему файлу, т.е. если в файл добавить в начало один байт, то будет замечено, что отличие всего в одном байте, а остальное дубликаты?
И насчет sha1, коллизии не попадались на больших объемах?
MikhailMitroshin
Образ диска разбивается на блоки условленного размера, и позиция этих блоков не меняется, то есть они не скользят. Это не мешает, однако, получать высокий процент дедупликации на реальных данных при минимальных вычислительных затратах.
А уж если бы коллизия SHA-1 кому-то попалась (необязательно нам), то такая новость сразу бы наводнила Интернет, и мы тут же увидели бы её на Хабре, да и во всяких википедиях тоже.
zapimir
Не, ну в интернете напишут, если эту коллизию можно относительно легко находить (хотя в принципе их можно находить, потому собственно все SSL сертификаты на sha2 переходят). Но это больше касается криптографической стойкости.
В случае дедупликации и инкрементального бэкапа (блочного) возможно случайное появление коллизий, так как понятное дело при «ужатии» 4-16 КБ блока до 20 байт так или иначе коллизии будут, попадутся они или нет зависит от везения в принципе. И в случае если будет коллизия в блоках, то «попортятся» файлы.
MikhailMitroshin
«Государь Гелон!
Есть люди, думающие, что число песчинок бесконечно. Я не говорю о песке в окрестности Сиракуз и других местах Сицилии, но о всём его количестве как в странах населённых, так и необитаемых.»
Архимед. Исчисление песчинок в пространстве равном шару неподвижных звёзд (Псаммит).
А, есть люди, которые считают, что 1/2^80 (вероятность коллизии SHA-1) – это обычное такое число, ничего особенного. И что встретить коллизию SHA-1 – обычное дело.
Сравнить же с этим числом можно (если не ошибаюсь) количество элементарных частиц в нашей галактике. А это куда больше, чем количество песчинок, подсчитанных Архимедом (2^80 против 10^63 – тысячи мириад чисел «восьмых»).
И вероятность коллизии меньше, чем вероятность того, что данные на жёстком диске случайно переманитятся, но CRC останется прежним! Представляете? Было «Я к вам пишу — чего же боле?» а стало «А теперь Горбатый! Я сказал – Горбатый!» только за счёт случайного перемагничивания.
Когда вероятность коллизии столь мала, что непонятно, увидим ли мы её когда-нибудь за всю историю существования человечества, то как-то трудно считать это ненадёжным решением. Возможно, серверы нашего тысячелетия расыпятся в прах, а коллизию мы так и не встретим. А может быть, натолкнёмся на коллизию уже завтра – со случайными величинами ни в чём быть уверенным нельзя.
В общем, всё зависит от вашего доверия/недоверия к тому, может ли возникнуть событие с ничтожно низкой вероятностью. И «ничтожно» — это куда меньше, чем найти две одинаковых песчинки не просто в окрестностях Сиракуз, но и во всей нашей галактике.
MikhailMitroshin
Или вот такое (мрачное) сопоставление.
В практикуме по страхованию жизни (легко ищется в интернете) можно прочитать, что вероятность прожить ещё один год для взрослого человека составляет около 0.99
Допустим, в вашем ИТ-департаменте работает 10 человек
Вероятность того, что в течение года все они дружно переплывут через реку Стикс, составляет
(1-0.99)^10 ~= 1/(2^7)^10 ~= 2^-70
То есть встретить коллизию SHA-1 вероятность гораздо меньше, чем всему департаменту ломануться на вечеринку к Одину.
Не кажется ли вам, что настолько маловероятное событие не заслуживает беспокойства о нём?
zapimir
Я же не спорю, что вероятность маленькая, только вот она не нулевая.
2^80 это не вероятность коллизии, это вероятная криптостойкость к различным атакам, которая в данном случае не важна (так как не рассматривается злонамеренная подделка блоков бэкапа), так что можно считать 2^160 вариантов. Но теперь посчитайте теоретическое количество вариаций блоков размером 4КБ или 16КБ. Для блока 4 КБ это 2^32768 и уже число 2^160 не выглядит таким большим.
Ок, допустим, а почему к примеру тогда не выбрали md5 у него вероятность тоже гораздо меньше «чем всему департаменту ломануться на вечеринку к Одину», а считается этот хэш быстрее и места в памяти меньше занимает, чем sha-1.
zapimir
Я это всё к чему, что зачастую используют комбинацию из двух хэшей, так как вероятность поймать коллизию на двух хэшах значительно ниже.
MikhailMitroshin
Боюсь, что мои знания слишком поверхностны, чтобы обсуждать эту тему так глубоко, выступая в то же время адвокатом целой индустрии, основанной на дедупликации.
Jump
Вы правы вероятность получить коллизию хэша очень маленькая, просто ничтожная
И о ней не стоит беспокоиться.
Никому.
Кроме разумеется тех, чей софт делает более миллиарда хэшей ежедневно.
Поэтому если вы не работаете с системами предназначенными для дедупликации террабайтов бэкапов и архивов, то вам боятся нечего.
MikhailMitroshin
1. Дедупликация в таком виде используется во многих продуктах известных производителей программного и аппаратного обеспечения. Не кажется ли Вам, что если бы коллизия хэшей имела бы коль сколько-нибудь серьёзную вероятность возникновения, давно бы появилась обоснованная критика этого метода со стороны серьёзных специалистов, а не только дискуссии на форумах?
2. В вконце концов, дедупликация — это инструмент, который вы можете использовать, а можете и не использовать. Всё зависит от вашей собственной оценки рисков. Вы когда-нибудь ездили на автомобиле? Вы знаете, что погибнуть в автокатастрофе отлична от нуля и вовсе не ничтожна? Например, в России вероятность погибнуть в ДТП в течение года составляет около 0.00019.
Но вы всё-равно ездите. Оцениваете риск, но удобства от езды на автомобиле перевешивают опасность.
Так же и при дедупликации. Разница только в том, что риск автомобильной аварии осязаем, а риск коллизии миллиарда хешей ежедневно — ничтожен.
3. Что значит «ничтожен»? Выше я уже приводил примеры крайне маловероятных событий, вероятность которых выше, чем вероятность возникновения коллизии.
Но известно ли Вам, что вероятность того, что ошибочно будет произведён пуск ядерной ракеты также отлична от нуля? Это Вас не беспокоит? Вы просто уверены, что вероятность такого события ничтожна, хотя последствия чудовищны. А ничтожна — это насколько мала? когда для Вас число будет столь малым, что не будет вызывать беспокойства? 2^-80 достаточна? А 2^-160? А какая достаточна? Давайте выберем такой размер хеша, который будет соответствовать Вашим понятиям ничтожной вероятности.
Просто до нас уже кто-то прикинул вероятность коллизии для SHA-1 и решил, что это весьма небольшая вероятность, позволяющая использовать основанную на ней дедупликацию в промышленных системах.
zapimir
Вы забыли такую вещь, как закон Мерфи или закон подлости: если какая-то гадость может случиться, то она обязательно случится :)
В случае с ядерными ракетами, пример не корректный, так как там не проверяют миллиард раз в день сработает защита или нет.
Я другой пример приведу, америкосовскую лотерею Powerball, вероятность выиграша в неё 1/2^28. Теперь прикинем какова вероятность, что выиграют 2 человека одновременно. Вероятности насколько помню умножаются (степени складываются), т.е. получается 1/2^56. А для трех человек 1/2^84 ничтожная вероятность по вашему, тем не менее в январе этого года 3 человека никак не связанные между собой сорвали джекпот в 1,5 млрд.
Ну почему насколько знаю многие системы с дедупликацией используют SHA-256, та же ZFS для дедупликации использует SHA-256 (хотя вроде для файловой системы лучше более быстрый хеш использовать).
Т.е. на вашей практике, еще на сталкивались с какими-то проблемами из-за sha-1 коллизий, насколько я понял.
MikhailMitroshin
| Т.е. на вашей практике, еще на сталкивались с какими-то проблемами из-за sha-1 коллизий, насколько я понял.
Верно, не сталкивались.
Тут бы мне тихо и мирно закончить дебаты, но всё-таки не могу оставить без комментариев некоторые Ваши утверждения:
1. «В случае с ядерными ракетами, пример не корректный, так как там не проверяют миллиард раз в день сработает защита или нет.»
Я не ставил задачу сравнить вероятности. Очень надеюсь, что они несравнимы. Я лишь хотел указать, что вероятность сбоя, в принципе, отлична от нуля, и нельзя безапелляционно утверждать, что если вероятность сбоя (или коллизии в нашем случае) отлична от нуля, то доверия такой системе нет.
2. По поволу лотереи Powerball.
Думаю, что в расчет вероятности выигрыша джекпота вкралась ошибка.
Действительно, вероятность совпадения выигрышных чисел ДЛЯ ОДНОГО КОНКРЕТНОГО ЧЕЛОВЕКА равна 1/2^28 ( точнее, говорят, 1 к 292 201 338).
Но если купили миллион билетов, то вероятность выигрыша для одного человека не изменится, а вот вероятность того, что джекпот в принципе случится, станет больше в миллион раз, то есть будет равна… 1/292
То есть вероятность того, что я, мой сосед и мой племянник (то есть конкретные три человека) выиграют джекпот, действительно супер-низкая: 1/2^84, как Вы и сказали.
Но то, что джекпот выиграют три ПРОИЗВОЛЬНЫХ человека из миллиона купивших билеты, всего лишь 1/292^3.
Если куплено больше билетов, то вероятность ещё выше.
zapimir
Интересно, как это у вас так получилось, миллион билетов снизили вероятность, а то что у вас в 35 ГБ данных 9 млн блоков по 4 КБ вероятность не снижают, а если бекапить несколько терабайт то там 500 млн блоков, а теперь посчитайте сколько всего блоков у пользователей вашей программы :) Собственно к этому я и вел, что в масштабах всех клиентов фирмы делающей систему дедупликации вполне можно поймать коллизии.
MikhailMitroshin
Конечно, Вы правы. В 500 миллионах блоков вероятность коллизии значительно выше, но всё равно остаётся в пределах допустимого риска по мнению производителя. Я попробую запросить расчётные значения у разработчиков.
zapimir
Ну можно призвать в тему polarowl и vMaria может расскажут какой хеш для дедупликации в Veeam используется, и ловили ли коллизии в хешах попроще.
polarowl
В VBR, насколько мне известно, MD5. Сведений о замеченных коллизиях лично ко мне пока не поступало :).
Насчет хешей и коллизий пару лет назад была аналогичная дискуссия (куда ж без этого) на форуме Veeam, резюме по сути то же, что привел и автор поста. Так что производители тут, можно сказать, солидарны :)
zapimir
cпасибо, за ответ :)
значит можно не увлекаться перфекционизмом :)