r
Ох я про дедупликацию-то и забыл написать. Мне кажется, они пускают пыль в глаза, но я под впечатлением от факапов уже только обратил внимание вот на что:
Если бы они хотел сориентировать пользователя, то выдавали бы полезную статистику: - коэффициент сжатия, коэффициент дедупликации без учета дедупликации между снимками (поблочная дедупликация) и коэффициент экономии места из-за инкрементального характера хранения снимков. Вместо всего этого там одно число что-то тимпа 1/1000. Впечатляет, если не учитывать что в знаменатели есть полная логическая емкость всех снимков!
По факту, просто хранение снимками со сжатием в zfs экономичнее, чем их супердедупликация.
Я очень давно эксплуатирую zfs и задумываюсь об эффективности и проблемах механизмов в них. У меня уже сформировалось понимание "на кончиках пальцев". Так вот ответственно заявляю что люди просто "не умеют готовить" дедупликацию в zfs. Все упирается в сравнительно большой объем таблицы метаданных дедупликации (контрольных сумм). Я могу дать рабочий и прогнозируемый рецепт как включить дедупликаю в zfs так, чтобы она у вас работала хорошо и экономила деньги.
В крадце:
- у вас обязательно должен быть special vdev с самого начала существований пула, и на нем должно быть достаточно свободного места (более 5ГБ) после того как пул заполнится. Сложно заранее сказать сколько это, но его объем пропорционален количеству даннхз ДО дедупликации и примерно ~ 100ГБ на каждый 8ТБ данных ДО дедупликации
- таблицу дедупликации нужно вынести на несколкко dedup vdev их объем пропорционален объему данных после дедупликации и примерно эквивалентен 300ГБ на 8ТБ дедуплицированных данных
- производительность дедупликации будет примерно соответствовать 50-100Мбит на каждые vdev из SSD intel s3700 и примерно 500-100МБит (50-100Мбайт/сек) на каждый vdev из intel optane (200 000 iops) -и это уже не плохой вариант.
Я логически не вижу пути сделать дедупликацию с меньшим количеством обращений к таблице дедупликации. Отдельно надо обратить внимание, что при записи данных которые легко дедуплицируются, они проверяются чтением с основного пула и это тоже источник тормозов. Можно использовать контрольные суммы где вероятность коллизии мала (что-то типа возраста вселенной надо записывать туда данные чтобы столкнуться с коллизией хеша) или наоборот осознанно использовать маленькие хеши с включенной проверкой - что выбрать зависит от ваших задач.
И ещё. Дедуплицировать имеет смысл только виртуальные машины с 16К размером блока данных. По этому в винде надо на этапе инсталлции шаблона переформатировать диск.
Если бы они хотел сориентировать пользователя, то выдавали бы полезную статистику: - коэффициент сжатия, коэффициент дедупликации без учета дедупликации между снимками (поблочная дедупликация) и коэффициент экономии места из-за инкрементального характера хранения снимков. Вместо всего этого там одно число что-то тимпа 1/1000. Впечатляет, если не учитывать что в знаменатели есть полная логическая емкость всех снимков!
По факту, просто хранение снимками со сжатием в zfs экономичнее, чем их супердедупликация.
Я очень давно эксплуатирую zfs и задумываюсь об эффективности и проблемах механизмов в них. У меня уже сформировалось понимание "на кончиках пальцев". Так вот ответственно заявляю что люди просто "не умеют готовить" дедупликацию в zfs. Все упирается в сравнительно большой объем таблицы метаданных дедупликации (контрольных сумм). Я могу дать рабочий и прогнозируемый рецепт как включить дедупликаю в zfs так, чтобы она у вас работала хорошо и экономила деньги.
В крадце:
- у вас обязательно должен быть special vdev с самого начала существований пула, и на нем должно быть достаточно свободного места (более 5ГБ) после того как пул заполнится. Сложно заранее сказать сколько это, но его объем пропорционален количеству даннхз ДО дедупликации и примерно ~ 100ГБ на каждый 8ТБ данных ДО дедупликации
- таблицу дедупликации нужно вынести на несколкко dedup vdev их объем пропорционален объему данных после дедупликации и примерно эквивалентен 300ГБ на 8ТБ дедуплицированных данных
- производительность дедупликации будет примерно соответствовать 50-100Мбит на каждые vdev из SSD intel s3700 и примерно 500-100МБит (50-100Мбайт/сек) на каждый vdev из intel optane (200 000 iops) -и это уже не плохой вариант.
Я логически не вижу пути сделать дедупликацию с меньшим количеством обращений к таблице дедупликации. Отдельно надо обратить внимание, что при записи данных которые легко дедуплицируются, они проверяются чтением с основного пула и это тоже источник тормозов. Можно использовать контрольные суммы где вероятность коллизии мала (что-то типа возраста вселенной надо записывать туда данные чтобы столкнуться с коллизией хеша) или наоборот осознанно использовать маленькие хеши с включенной проверкой - что выбрать зависит от ваших задач.
И ещё. Дедуплицировать имеет смысл только виртуальные машины с 16К размером блока данных. По этому в винде надо на этапе инсталлции шаблона переформатировать диск.
