Pull to refresh
0

Snapshots — «фото на память (дисковую;)»

Reading time 8 min
Views 28K
image

Всегда странно представлять себе времена, когда чего-то не было. Сложно сегодня представить себе, как мы жили без персональных компьютеров, без интернета, без торрентов, mp3, или без электрокопировальных аппаратов, в просторечии «ксероксов». Тем не менее всегда были времена, когда что-то привычное нам еще не существовало. Также обстояло дело и с понятием «снэпшота данных». Но сперва — что же такое «снэпшот»?

"Снэпшот" (дословно — «фотография», «моментальный снимок», здесь и далее под этим словом мы будем понимать конкретно, не уточняя, «снэпшот данных») это моментальная копия состояния данных в системе хранения, или программе, зафиксированная на определенный момент времени. Это может быть моментальное состояние содержимого файла, базы данных, или файловой системы (как частного случая «базы данных»).
В применении к системам хранения данных этот термин появился вместе с первыми системами хранения NetApp и был, на тот момент первой и главной их «фичей».


Ранее я уже рассказывал о внутренней файловой структуре WAFL, придуманной основателями NetApp для своего продукта, и о том, каким образом она работает. Интересующихся техническими деталями отошлю к прекрасной авторской публикации, которая сейчас переведена на русский язык. Именно эта, несколько необычная, на первый взгляд, по принципам работы, файловая структура сделала возможной реализацию концепции снэпшотов — мгновенных копий состояния данных, хранимых на дисках такой системы.

Как я уже рассказывал в статье про WAFL, основной принцип ее работы состоит в том, что однажды записанные на диск данные, в дальнейшем, не изменяются. Данные (например файл) можно на WAFL либо записать (целиком), либо стереть (целиком). В случае же необходимости изменения его содержимого эти изменения «дописываются» в свободное место дискового пространства, после чего на блоки с записанным содержимым изменений переставляется указатель содержимого файла (старый блок содержимого помечается как свободный, или не помечается, если на него ссылается более одного файла, или он использован в снэпшоте). Следовательно, для того, чтобы сохранить текущее состояние данных, при таком алгоритме работы записи, все что нам нужно, это сохранить «корневой inode» на данный момент времени.

image

Inode, напомню, это блок данных, определяющий содержимое файла. Он может ссылаться либо прямо на конкретные блоки, либо, для больших файлов, на промежуточные inodes, образуя «дерево» от «корня», единственного на всю файловую систему тома, так называемого «корневого» inode.
Таким образом, создав копию ровно одного блока, корневого inode данной файловой системы, мы получим, обратившись к нему, вместо текущего «корня», «псевдо-файловую систему», хранящую без изменений (read-only) все данные на момент времени, когда мы скопировали этот inode. Ведь, как вы помните, однажды записанные блоки данных файлов в дальнейшем не изменяются.

image

Каким же образом это выглядит на практике?
Для упрощения рассказа я буду рассматривать NAS-вариант работы NetApp, хотя, как вы знаете, аналогичным образом тот же самый сторадж может работать и как SAN-устройство.

Каждый том на системе хранения NetApp является отдельной файловой системой. На каждой файловой системе можно создать до 254 снэпшотов ее состояния, по методике, описанной выше.
Все созданные снэпшоты автоматически доступны через директорию /.snapshot (или /~snapshot) в корне тома. Зайдя туда, мы увидим имена созданных снэпшотов (они могут носить либо «собственное имя», например "/lets_fix_this_small_bug…oh_shit!..", будучи созданными вручную, либо, если создаются по расписанию, будут располагаться в поддиректориях hourly.0(1,2,3…), daily.0(1,2,3) и так далее.

image

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

image

Причем это даже выглядит несколько странно, на первый взгляд.
Допустим, что у вас есть том, размером 1TB, на котором лежит файл базы данных, размером 750GB. Для этого тома вы создаете снэпшоты каждый час по расписанию. Войдя в /.snapshot вы увидите в ней поддиректории /hourly.0, /hourly.1, и так далее, причем в каждой из них будет лежать «файл размером 750GB». При этом на собственно томе, емкостью 1TB, на котором как бы и лежат эти 24 (каждый час) копии базы по 750 гиг размером каждая, еще будет гигабайт 200 свободного места.
При этом любой из этих 24 «файлов» мы можем скопировать в резервную копию на внешнее хранилище, смонтировать как независимый read-only и использовать (читать) эти данные, как если бы это была реальная база данных, восстановить из нее данные, скопировав ее на место «активной», например в случае «все сломали, надо откатится на состояние час назад», и так далее.

Где же все это хранится?
Дело в том, что все эти «файлы», это просто ссылки на одни и те же блоки неизмененных данных. Место же на диске занимают только изменения, между снятыми снэпшотами. Допустим, что за сутки мы наменяли в этой базе блоков на 50 гигабайт. Тогда занятое место на дисках, в томе размером 1TB, на котором лежит файл базы на 750GB, и снэпшоты каждый час, будет 1TB — 750GB файл — 50GB изменений = 200GB свободно.
Если изменений за час между двумя снэпшотами (hourly.0 и hourly.1) получилось на 1% объема базы, то hourly.1 займет 7,5GB места на диске, указывая своими inodes на измененные, по сравнению с предыдущим снэпшотом, блоки. Все же остальные inodes по прежнему будут ссылаться на прежние, неизмененные блоки.

Чем удобно использование снэпшотов?
Простейший пример я уже привел. Допустим мы, или наши пользователи, «все сломали». Это может быть база данных, или же, допустим, экселевский файл, в котором, случайно, грохнули не те данные, успели записать, а потом обнаружили это, а восстановить надо срочно, «или нас всех убьют». Но мы знаем, что час (два, три, сутки, неделю, месяц назад, все зависит от частоты и регулярности снэпшотов) нужный нам файл был исправен.
Мы (это может сделать, кстати, даже сам пользователь) просто заходим в папку /.snapshots и вытаскиваем оттуда простым копированием нужный нам файл, на нужный момент времени, час, два, сутки, и так далее назад.
Либо, если у нас есть специальная лицензия SnapRestore, одной командой из консоли стораджа, «откатываем» состояние тома на нужный момент времени целиком (что удобно, если нужно восстановить не отдельный одиночный файл, а содержимое всего тома, в целом).

Таким образом, снэпшоты это, для пользователя, очень оперативная резервная копия, доступная тут же, на этом же сторадже. Кстати, в случае использования Windows XP или 7, вы будете видеть файлы в снэпшоте в панели «Previous versions» свойства файла или папки, NetApp интегрируется в этот механизм Windows как VSS-provider.

image

Теперь рассмотрим более сложный вариант. Допустим, мы эксплуатируем большую, ответственную, mission-critical SQL-базу данных предприятия.
Разумеется, каждый вечер, эта база данных бэкапится на ленту, для создания резервной копии.
База большая, и резервная копия копируется на ленту примерно час.
«Ничто не предвещало беды», но однажды, посреди рабочего дня, допустим в 3 часа дня, база необратимо портится.

Какие действия предпринимает сисадмин, для того, чтобы базу восстановить?
Мы считываем резервную копию по состоянию на конец прошлого рабочего дня (читаться она будет, допустим, столько же, сколько писалась — час), а затем нам следует «накатить» на нее redo-log-и, от момента создания бэкапа, вечером, и до момента, предшествующего сбою, то есть до 3 часов следующего дня. Этот «накат» часто довольно объемен, и также занимает какое-то время, ведь операции в SQL происходят не мгновенно. Допустим, через 30 минут, после окончания считывания бэкапа, база восстановлена в рабочем состоянии на момент предшествующий сбою, и мы готовы продолжать работу. Итого — 1:30.

В случае использования снэпшотов дела будут происходить следующим образом. У нас также делается ежедневная копия на ленту для обеспечения безопасности хранения, например на случай полного выхода из строя системы хранения, но у нас хранилище живо, повреждены только данные на нем. Мы знаем, что час назад база была жива и здорова. Мы восстанавливаем базу по состоянию на 2 часа дня, и так как снэпшот создается и восстанавливается практически мгновенно, то это занимает не час, а всего несколько секунд, и накатываем на нее redo-logs, но не со вчерашнего вечера, как в предыдущем случае, а всего за один час, с 2 часов, то есть момента создания снэпшота, до момента аварии, в 3 часа дня. Это занимает также не полчаса, а всего несколько минут.
Итог: спустя несколько минут, а не полтора часа, как обычно, наша база вновь в рабочем состоянии.

Очевидные преимущества использования снэпшотов привели к тому, что, на сегодня, практически все производители систем хранения предлагают для своих систем ту или иную реализацию «снэпшотов» как идеи.
Однако, как мы помним, «не все йогурты одинаково полезны».

В чем же принципиальное отличие «настоящих снэпшотов» (Название Snapshots (tm) для систем хранения это зарегистрированная торговая марка NetApp) от всех остальных, «контрафактных копий». ;)

Принципиальное отличие, позволяющее реализовать снэпшоты так, как это было описано мной выше — устройство WAFL, которое, как я уже рассказывал, не позволяет изменять уже записанные данные. Такая модель позволяет реализовать снэпшоты легко и просто. Но все обстоит хуже, если структура записи традиционна. При этом нам придется сперва, до начала использования, выделить зарезервированное пространство блоков, заранее отняв его у данных, затем, при каждом изменении блока на диске, копировать его содержимое в специальный зарезервированный пул, затем изменять его содержимое на его прежнем месте, затем изменять метаданные, указывающие на старое содержимое, для снэпшота.

Эта технология носит название Copy-on-Write (COW), и широко применяется в системах хранения других производителей, в их реализации снэпшотов.
Как вы видите из описания выше, даже само наличие включенного механизма снэпшотов для тома превращает одну операцию записи для системы хранения в три (чтение исходного содержимого, запись исходного содержимого на новое место, запись измененного содержимого на старое место).
Результат не заставляет себя ждать. Использование COW-snapshots резко ухудшает производительность системы хранения его использующего. Это разительный контраст с системами NetApp, в которых снэпшоты вообще никак не влияют на производительность, ведь никакого копирования при записи в них не происходит, все данные остаются на своих местах.
(демонстрация результатов производительности на тесте SPC-1)

image

Следствием такого неприятного поведения при использовании COW-snapshots является рекомендация вендоров свести использование таких «неправильных снэпшотов» к минимуму, или не использовать их вовсе на primary-системах, предъявляющих повышенные требования к производительности.
Однако системы NetApp такой проблемой не страдают и никаких ограничений на использование снэпшотов не предъявляют.

Кроме этого, часто (по той же причине) общее количество снэпшотов на таких системах ограничено всего парой десятков максимум, отмечу, для контраста, что на системах NetApp можно использовать до 254 снэпшотов на каждый том, что, при общем количестве томов, допустимых систему, равного 500, достигает теоретического максимума в 127 тысяч.
Это позволяет, при использовании классической «ротации» резервных копий, хранить в 254 снэпшотах резервные копии данных тома до года включительно.

Также немаловажной является возможность создавать «по настоящему мгновенные» копии данных, причем независимо от размера «копируемых» данных. Хоть базу на 100MB, хоть на 100TB, снэпшот с нее будет всегда создан мгновенно. Например, мы можем создать «резервную копию» не «за час», а «за секунду», а затем, уже не нагружая нашей задачей реальную боевую базу, потихоньку копировать на резервное хранилище содержимое такого снэпшота.

Практика показывает, что люди, попробовавшие простоту и удобство использования снэпшотов, очень скоро уже просто не представляют себе жизни без них, считая это «само собой разумеющейся» возможностью любой системы хранения. Попробуйте и вы.
Напомню, что взять на тестирование систему хранения NetApp можно у любого партнера, список которых можно посмотреть на российской странице вебсайта NetApp.
www.netapp.com/ru/how-to-buy/resellers/distributor-ru.html
www.netapp.com/ru/how-to-buy/resellers/platinum-ru.html
www.netapp.com/ru/how-to-buy/resellers/gold-ru.html

PS: На традиционном «фото для привлечения внимания» в заголовке — задняя часть контроллера самой младшей модели NetApp — FAS2020. Самой младшей, но, тем не менее, обладающей всеми возможностями хранилищ NetApp, в том числе и работой со снэпшотами.
На фото, слева направо — два порта FC 4Gb/s, порт последовательной консоли, порт out-of-band микроконтроллера удаленного администрирования, и два порта Gigabit Ethernet.

PPS: А еще можно было бы написать на этой неделе про 5 место NetApp в Fortune's list Best Plaсes to Work, вон Intel стррашно гордится аж 51-м местом (из ста), но мне показалось, что все эти радости пиар-отдела Хабру не очень интересны, поэтому упомяну об этом «бегущей строкой» в самом конце. Да, пятое место в сотне лучших работодателей США, и пятнадцатое (выше Google (30) и Apple (20), кстати) по списку сайта Glassdoor, оценивающего компании не «снаружи», как Fortune, а изнутри, анонимными голосами самих работников. «Пустячок, а приятно».
Tags:
Hubs:
+28
Comments 66
Comments Comments 66

Articles

Information

Website
www.netapp.com
Registered
Founded
Employees
1,001–5,000 employees
Location
Россия