about NetApp

Дедупликация данных, то есть удаление из данных повторяющихся блоков с целью уменьшения объемов хранения, есть довольно горячая тема на сегодня.
Недавно начавшаяся “титаномахия” между NetApp и EMC, двумя крупнейшими по размерам производителями систем хранения с дедупликацией, за обладание третьим игроком этого рынка, компанией Data Domain, по очереди получающей от NetApp и EMC все повышающиеся по цене предложения о покупке, показывает интерес индустрии к теме.

Что же такое дедупликация, или, как она называлась раньше у NetApp, ASIS - Advanced Single Instance Store?

Не секрет, что хранимая информация часто многократно и ненамеренно “дублируется”. Речь даже не о том, что пользовательские “домашние папки” сотрудников отдела продаж хранят во множестве экземпляров текущий прайс компании, а регулярно проносящиеся по организации рассылки пользователями друг другу какого-нибудь очередного “прикольного” “вирусного” видео на ютубе, или свежего “топа бездны” заполняют ящики MS Exchange. С такими “файловыми” дублированиями уже умели бороться довольно давно, и разными способами, хоть и по прежнему не слишком успешно.

Однако есть другие варианты, наиболее просто демонстрируемый и широко распространенный сегодня - содержимое виртуальных машин. Если у вас есть пять виртуальных машин на базе Windows, то у вас есть, скорее всего, пять полностью идентичных инсталляций Windows, минимум на 2-3 гигабайта каждая, отличающихся на момент их создания, грубо говоря, только “именем компьютера” и IP-адресом, лежащих отдельно друг от друга на дисках, и занимающих свои 2-3 гигабайта.
Однако, так как это содержимое хранится внутри файла “виртуальных дисков”, то обычными методами мы никак не сможем устранить это дублирование. Ведь файлы этих виртуальных дисков все же не идентичны (на какие-то единицы процентов).
Аналогичный пример - базы данных. Если у нас для записи базы данных для полутора тысяч сотрудников указано “не женат/не замужем”, равно как и наоборот, или, например, в поле “город” указано “Москва”, а предусмотренное архитектурой базы BLOB-поле для хранения фотографии у 90% пустое, то это также будет дублированием.

Может быть просто обидно, хранить на дорогостоящих SAS и FC дисках многократно повторяющиеся, и по сути не нужные, не несущие информацию, избыточные блоки данных. Мы сохранили уникальный блок - все. Нужно его содержимое - берите его там, зачем копировать его по диску в сотнях и тысячах копий!
Так дело обстоит с точки зрения банальной логики.
Мы победили на файловом уровне, с помощью разных средств, рассылальщиков “башорга” по конторе, но с дублированием множества копий идентичных данных в виртуальных машинах справиться гораздо сложнее.

Несколькими постами ранее я рассказывал о том, что при хранении информации на дисках NetApp используется “нестандартный” сектор, 512 байт обычного сектора дополнены 8 байтами специальных “контрольных сумм”, позволяющих контролировать нарушение целостности информации при их передаче.
Однако кроме этого NetApp использует их довольно остроумным способом и в процессе нахождения и устранения дубликатов данных.

Одна из основных задач в процессе дедупликации - нахождение идентичных блоков данных.
Для того, чтобы не устраивать сравнение “всех со всеми”, пока не найдешь дубликат, это очень долго и дорого в плане использования памяти и процессора, обычно используется способ вычисления так наываемой “хэш-функции”.

“Хэш-функция” это некая формула, по которой можно получить более или менее уникальный “фингерпринт”, “цифровой отпечаток пальца”, некое число, уникальное для данного сочетания байт. Сравнивать такие числа гораздо проще, чем содержимое файлов, от которых они взяты.
Простейший вариант хэш-функции, это так называемая “контрольная сумма”. У нас есть набор чисел-байт, давайте просуммируем их, и на выходе получим некое число, зависящее от значения тех, кого мы просуммировали. Проблема использования простейшей контрольной суммы очевидна.
Сумма 5+3+2 дает 10. Но и сумма 4+4+2 дает тоже 10.
Это называется “хэш-коллизия”, ситуация, когда разные по содержимому блоки дают идентичный результат хэш-функции. Чем это чревато - нетрудно сообразить. Основываясь только на результате хэша мы можем ошибочно удалить вовсе не идентичные по содержимому данные.

Решение в общем-то очевидно. На самом деле никто не пользуется примитивной контрольной суммой, я ее привел просто в качестве примера, иллюстрирующего проблему.
Для вычисления хэш-функции используются различные математические алгоритмы, более устойчивые к хэш-коллизии, наиболее известны, например, CRC32 или MD5.
Более устойчивые - да, но не абсолютно.
Устроит ли вас результат, что “ваши данные скорее всего, с высокой степенью вероятности, не будут ошибочно удалены”? По видимому - нет.

Что же делать? Снова очевидно - усложнять алгоритм, снижая вероятность коллизии.
Однако, возникает проблема накладных расходов. Вычисление сложного алгоритма есть довольно непростая и ресурсоемкая задача. А если учесть, что мы должны проделывать ее для каждого записываемого на систему хранения блока без исключения? Процессорные ресурсы сейчас дешевы, но не настолько же.

??менно это является причиной того, что массивно-дедуплицирующие системы, например такие, как система типа CAS (Content-addressable Storage) EMC Centera, очень, ОЧЕНЬ медленные на запись.

NetApp, представив в 2007 году свое решение той задачи, предсказуемо пошел своим путем.
Как я уже упоминал, системы NetApp хранят результат CRC, это сравнительно простой в вычислении и “недорогой”, но недостаточно устойчивый к коллизиям алгоритм вычисления, для каждого 512-байтного блока. Этот CRC достается нам, по сути, бесплатно, он в принципе уже есть на дисках, хотим мы этого, или нет, пользуемся им, или нет.
Но использовать только его для определения дубликатов нельзя.

Файловая структура WAFL, лежащая “в основе” всех систем хранения NetApp использует блок данных размером 4KB, то есть 8 таких секторов.
CRC от этих 8 секторов дают нам некий более или менее уникальный fingerprint такого блока.
Эти фингерпринты сводятся в массив внутренней “базы”, по которой производится поиск идентичных фингерпринтов. Как вычисление несложного хэша, так и поиск по значениям такого хэша, это, в принципе, не слишком сложная и ресурсоемкая задача, тем более, что, как я написал выше, значительная часть задачи уже и так решена, так как CRC у нас уже есть для всех секторов “бай дизайн”, изначально, по умолчанию.
??дентичные фингерпринты являются основанием предполагать идентичность соответствующих им блоков.
Обратите внимание, не “означают идентичность”, для этого алгоритм слишком прост.

Теперь, сократив количество подлежащих анализу блоков в сотни и тысячи раз, и обнаружив “достойных кандидатов”, мы проводим обычное побайтовое собеседование сравнение этих 4KB блоков, и вот если мы в результате этого сравнения обнаруживаем полную идентичность - вот тогда мы и удаляем, то есть вероятность неправомерного удаления в результате “хэш-коллизии” полностью устранена, но при этом, за счет такого двухстадийного процесса, мы обошлись без использования сложного и ресурсоемкого “устойчивого к коллизиям хэша”.

Однако у такого метода есть существенная особенность - он не может быть проведен online, в момент собственно записи данных. Это в чистом виде offline-алгоритм. Сперва данные записываются, потом генерируются fingerprint-ы, потом проходит поиск, выявляются кандидаты на дедупликацию, проводится побайтное сравнение дупликатов и принимается решение.

Однако “чистый offline” процесса дедупликации дает нам пренебрежимо малое влияние процесса на производительность системы. Конечно многое зависит от мощности системы, характера данных, и так далее, но чаще всего пользователи сообщают о влиянии на производительность от включенной дедупликации в 0% для чтения, и в районе 5-7% при записи, то есть, во многих случаях, пренебрежимо малых величинах.
В результате, системы NetApp могут использовать дедупликацию на ролях так называемых Primary storages, то есть основных, “боевых” системах хранения, а не только на хранилищах бэкапов, DR-реплик и резервных, ненагруженных системах.
Хотя применение дедупликации на primary storages и требует соблюдения рада оговорок, оно, как показывает практика прошедших пары лет, вполне работоспособно и широко применяется сегодня. ?? уж точно дедупликация пригодна для разнообразных secondary storages, таких как D2D Backup, реплики данных и резервные системы.

Так как NetApp принял в свое время решение отдавать лицензию на Dedupe бесплатно, на сегоднящний день количество систем хранения со включенным и работающим Deduplication, по отчету техсаппорта компании, получающего эту информацию, превышает на начало года число 37 тысяч систем.
Это подавляюще преимущественное положение на рынке дедупликации на сегодня.

Q: Насколько эффективна дедупликация для хранимых данных?
А: NetApp сделал специальный эмпирический калькулятор, с помошью которого можно приблизительно оценить результат для разных типов данных.
http://www.dedupecalc.com/

Q: А как бы не приблизительные и эмпирические цифры узнать, а на моих конкретных данных?
A: У NetApp есть небольшая программка, которую можно запустить на том данных, она просчитает по нему fingerprint и сообщит ожидаемую эффективность дедупликации. Взять ее можно у партнера NetApp, так как она под определенными ограничениями, не просите ее у меня.
Партнеру скажите, что вам нужна программка SSET под Windows или Linux, он ее может скачать с партнерского раздела.

Q: Я запустил дедупликацию (или SSET) по тому данных, на котором у меня лежит сотня full backup моих данных, и я ожидал получить высокую степень эффективности на таких данных, ведь по сути это полностью одинаковые данные за небольшими изменениями, но получил результат заметно менее ожидаемого, почему так?
A: Дело в том, что для дедупликации важна абсолютная идентичность данных в пределах 4KB-блока. Если идентичные данные имеют по какой-то причине смещение между сравниваемыми блоками, хоть на байт (такое часто случается в форматах файлов резервного копирования), они уже будут считаться неидентичными для алгоритма дедупликации FAS, который не умеет обрабатывать смещение данных в блоках. Эта проблема решена в алгоритме дедупликации для систем VTL, лучше подходящих, и специально заточенных под бэкапы.
По этой причине, кстати, дедупликация FAS так эффективна для виртуальных дисков виртуальных машин, обычно виртуальные диски всегда идентично выровнены между собой, и границы блоков для них совпадают.

Q: Как можно получить лицензию для имеющейся системы?
A: Свяжитесь с ее продавцом, он закажет для вашей системы лицензию. Она бесплатна, но она нужна. Как правило для всех новых систем она поставляется по умолчанию, как iSCSI, например.

Q: Есть ли какие-то ограничения по использованию?
A1: Конечно есть :) Для полного понимания рекмендуется прочесть соответствующий Best Practices на сайте NetApp, а из FAQ-овых вопросов - обязательно посмотрите, какой лимит определен для вашей системы хранения. Он зависит от версии используемой Data ONTAP, и на момент написания этого текста, для 7.3.1 составляет 1TB для FAS2020 (самой младшей), 2TB для 2050 и 3020, 3TB для 3050, 4TB для 3040 и 3140, выше (3070, 3160, 6000) размер тома с включенной дедупликацией может быть равен максимальному размеру тома на системе хранения - 16TB. Это ограничение вызвано нежеланием перегружать возможным процессом не слишком большие объемы памяти и процессоров для этих систем, что могло бы вызвать заметное снижение рабочей производительности системы.
Если вы создали том больше, чем разрешено для данной OS и данного “железа”, то дедупликация не запустится. С другой стороны и ничего плохого тоже не произойдет :).
А2: Обратите также внимание, что дедупликация производится только для активной файловой системы. Если много блоков данных “заперто” в снэпшотах, то степень достигнутой дедупликации будет ниже, так как блоки данных в снэпшотах не обрабатываются. Возможно со временем эту проблему решат, но пока перед началом дедупликации рекомендуется удалять снэпшоты, провести дедупликацию, после чего снэпшоты можно снова брать и использовать.

Q: Велична в 2TB на том данных, подлежащих дедупликации, это объем записываемых в него данных?
A: Нет, это именно размер тома. Если у вас на системе ограничение 2TB на том с дедупликацией, и при этом вы пишете на него данные, которые могут быть дедуплицированы вдвое, то после записи 2TB и первого прохода процесса дедупликации, у вас освободится 1TB, который вы, в свою очередь, сможете записать после окончания этого процесса. Далее по этому записанному 1TB также пройдет дедупликация, и после ее окончания вы снова получите свободное место. Но первоначально объем записи равен размеру тома, не забывайте, что это именно оффлайновая дедупликация, даже если вы заливаете 2TB нулей, вы получите эффект только после его обработки.
Однако, если вы включили дедупликацию на томе большего размера, на котором есть всего 2TB и менее данных, то дедупликация просто не включится. Важен именно размер тома.

Q: Могу я вернуть “как было” если у меня что-то пойдет “не так”?
A: Конечно, можно как включить, так и выключить дедупликацию в любой момент, а также вернуть назад “дупликацию”, если почему-то что-то не устроит.

Где еще почитать поподробнее по-русски о технических аспектах:
RUS TR-3505 Deduplication for FAS and V-series Best Practices.pdf

–
UPD:
О том, как дедупликация влияет на производительность работы систем хранения NetApp можно прочитать здесь:
Дедупликация и производительность работы

–
UPD2: Кстати, знаете ли вы, что NetApp гарантирует экономию по меньшей мере 50% объема хранения в случае использования дедупликации для данных виртуальных сред (VMware ESX/vSphere, MS Hyper-V/Hyper-V R2, Citrix Xen)?
http://www.netapp-vi.eu/ru/