about NetApp

Одной из важных особенностей и ”интересностей” систем хранения Network Appliance является примененная в них технология снэпшотов (snapshots).

Ранее я уже писал о том, что сама технология снэпшотов в системах хранения данных была изобретена в NetApp и само слово является trademark компании, именно потому конкуренты вынуждены придумывать разнообразные собственные названия для подобных технологий, таких как PowerSnap (EMC), QuickShadow (HDS) и так далее.

Какие же технологии создания снэпшотов существуют?

Full Clone (или “Split-Mirror”)
Наиболее простое и “лобовое” решение. Мы резервируем место, равное по объему тому LUN, для которого мы хотим выполнить snapshot. При необходимости иметь несколько снэпшотов место пропорционально увеличивается.
По команде на создание снэпшота контроллер системы хранения по внутренней магистрали данных начинает быстро копировать содержимое LUN в зарезервированную область. Либо же постоянно поддерживает “зеркало” (”mirror”), а в момент “создания снэпшота” репликация основного раздела в “зеркало” останавливается (”split”)
Плюсы: наш snapshot это полная физическая копия LUN-а. На этом плюсы исчерпываются и начинаются минусы.
Минусы: Непроизводительные потери места на диске на зарезервированный под снэпшоты объем. Снэпшот не мгновенен (в случае full clone), либо удваивает количество операций записи в случае split-mirror. Время его создания зависит от объемов LUN-а (а также загрузки контроллера системы хранения). Процесс копирования сильно нагружает контроллер и приводит к значительному падению производительности системы хранения на время создания снэпшота.

Copy-on-Write (или Point-in-Time)
Попыткой решить основные проблемы снэпшота типа Full Clone явился снэпшот типа Copy-on-write. Основная идея его была такова: Если главная проблема в том, чтобы одномоментно копировать большой объем данных, то давайте будем копировать только изменяемые блоки, оставляя неизменные на своих прежних местах. При этом исходные блоки будут копироваться туда только тогда, когда прикладная система захочет их изменить. ?? вместо полной копии мы получим инкрементальную. В пул свободных блоков, зарезервированных под снэпшот, попадут только измененные в LUN-е блоки. Таким образом текущий LUN есть тот LUN как он есть, а в снэпшоте этого LUN ссылки на измененные блоки будут заменены на ссылки в пул снэпшота, на неизмененные версии блоков, скопированные туда перед их изменением.
Copy-on-Write - “Копирование-при-записи”
Плюсы: гораздо экономнее расходуется место. Нет необходимости сразу резервировать полный объем LUN-а. Один пул может обслуживать все LUN-ы системы хранения, расходуясь по мере накопления изменений.
Минусы: Кажда операция записи в случае использования copy-on-write превращается в три. Сперва прочитать исходный блок, затем перенести (записать) его в пул, и, наконец, записать блок, который мы изначально хотели записать.
То есть каждая операция записи становится операциями “чтение-запись-запись”. С соответствующим влиянием на общую производительность системы хранения.

Какое же решение использует NetApp?
Третье.
Тут следует вспомнить тот факт, что в основании системы хранения лежит собственная внутренняя файловая система NetApp под названием WAFL - Write Anywhere File Layout.
Одной из ее особенностей является то, что файловая система устроена так, что никогда не перезаписывает блоки, единожды записанные на диск, до полного удаления файла, лишь дописывая его и изменяя указатели на актуальную “таблицу размещения файлов”.

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

Ситуация в каком-то смысле обратная технологии copy-on-write, в отличие от нее мы не переносим исходное содержимое блоков “в сторону”, перезаписывая его затем. Мы наоборот, производим “перезапись” путем записи нового блока “в сторону”, оставляя прежний блок на месте, а затем просто переставляем на новый блок указатель в “актуальной” “таблице размещения файлов” (на самом деле “таблице inodes”, поскольку Data ONTAP и WAFL несет в основе своей близкую к unix-подобной схему организации файловой системы).

Что это нам дает?
Во первых количество снапшотов становится практически неограниченным. В настоящий момент количество снэпшотов на том равно 255, количество томов - 500 (на контроллер). Отсюда легко видно, что общее количество снэпшотов, которые теоретически можно использовать на системе хранения NetApp равно 127000. Это значительно выше обычного числа в 8-14 снэпшотов на систему для большинства конкурентов.
Второй момент заключается в том, что снэпшоты не ухудшают параметры системы хранения при своем создании и использовании. ??менно это ухудшение вызывает необходимость ограничить количество снэпшотов на систему хранения в случае снэпшотов вида copy-on-write.
Третий момент - снэпшоты занимают на диске ровно то место, которое равно по объему изменениям между снэпшотами. То есть не объем LUN-а и даже не объем зарезервированного pool-а. А просто объем изменений. Нет изменений - место не занимается. Точка.
Ну и наконец немаловажный факт - снэпшоты в системах хранения NetApp есть всегда и при этом бесплатны. Они просто есть. Это такое же свойство файловой системы WAFL и OS Data ONTAP как, например, hardlinks и softlinks в линуксной Ext2FS. ??ми можно не пользоваться, но они все равно есть.

Дополнительных денег стоят как правило какие-то дополнительные функции для использования снэпшотов, например SnapRestore для восстановления тома целиком, SnapManager - ПО для использования функциональности snapshots с прикладной задачей, такой как Exchange, Oracle или MS SQL или SnapDrive - ПО для управления, создания и использования снэпшотов непосредственно с хост-сервера Windows или UNIX/Linux. О практическом использовании снэпшотов в дополнительных программных продуктах, использующих возможности снэпшотов в системе ханения NetApp, и о том, что эти продукты дают на практике я еще подробнее напишу отдельным постом.

 Еще почитать:

File System Design for an NFS  File Server Appliance 
Dave Hitz, James Lau, & Michael Malcolm | Network Appliance | TR 3002

BEST PRACTICES GUIDE FOR DATA PROTECTION WITH FILERS RUNNING FCP
Nick Wilhelm-Olsen, Brett Cooper | October 1, 2002 | TR3202

Oracle9i for UNIX:  Backup and Recovery Using a NetApp Filer in a SAN Environment
Richard Jooss | Brian Casper | 04/2004 | TR 3210

Guidelines for Using Snapshot Storage Systems for Oracle Databases
Nabil Osorio and Bill Lee, Oracle Corporation October 2001