storage volume snapshot что это
Снапшоты дисков
Снапшоты — это слепки состояния диска. Они хранят разницу между изменяющимися данными на диске виртуальной машины и состоянием диска на момент создания снапшота. Это позволяет копировать диски для создания клона виртуальной машины и изменения типа диска. Снапшот не является резервной копией диска виртуальной машины, так как хранится на том же оборудовании и требует доступности основного хранилища для выполнения любой операции.
Просмотр снапшотов
Просмотр снапшотов в панели управления
Для просмотра снапшотов в разделе Диски в проекте раскройте карточку диска и перейдите на вкладку Снапшоты. Отобразится список существующих снапшотов этого диска с именем и датой создания.
Просмотр снапшотов с помощью CLI
Для просмотра списка всех снапшотов:
Ответ будет выглядеть следующим образом:
Для просмотра снапшотов конкретного диска введите команду:
Для просмотра информации о снапшоте:
Ответ будет выглядеть следующим образом:
Создание снапшота
Снапшоты создаются только для сетевых дисков. Для локальных дисков снапшот создать нельзя.
Для диска можно создать только один снапшот – большое количество снапшотов замедляет работу диска.
Создание снапшота в панели управления
Чтобы создать снапшот в панели управления:
Примечание: также вы можете создать снапшот в разделе Серверы. Для этого на странице сервера на вкладке Сетевые диски в меню (⋮) нужного диска нажмите Создать снапшот.
Создание снапшота с помощью CLI
Для создания снапшота введите команду:
Изменение параметров снапшота
Для снапшотов доступно только изменение имени.
Изменение параметров снапшота в панели управления
Для изменения имени снапшота в панели управления:
Изменение параметров снапшота с помощью CLI
Для изменения имени снапшота введите:
Создание облачного сервера из снапшота
Чтобы быстро клонировать облачный сервер, можно создать новый сервер из снапшота. Для этого:
Удаление снапшотов
После выполнения операций со cнапшотом рекомендуется его удалить, чтобы была возможность создать новый снапшот, а также из-за того, что большое количество снапшотов замедляет работу диска.
Для долговременного хранения состояния диска создайте диск из снапшота.
Удаление снапшота в панели управления
Для удаления снапшота в панели управления:
Удалить все снапшоты одного диска одновременно можно двумя способами:
О технологии создания и использования Snapshot в системах хранения данных
Одно из основных преимуществ дисковых RAID массивов – надежность хранения данных. В первую очередь она обеспечивается на аппаратном уровне путем использования дополнительного диска (дисков) для записи контрольной информации, достаточной для восстановления данных при выходе в массиве из строя одного (при уровнях RAID 3 или 5) или даже нескольких (RAID 6, 6+) жестких дисков.
Кроме того, во внешних RAID массивах предусматриваются избыточные (допускающие замену в «горячем», т.е. без выключения питания, режиме) блоки питания и вентиляторы охлаждения. Возможна установка дополнительных батарей питания кэш-памяти, обеспечивающих защиту и хранение ее содержимого (информации, которая не успела записаться на жесткие диски массива) при аварийном отключении питания.
Кроме этого, в критичных к непрерывной работе областях применения современных систем хранения данных используется по 2 независимых RAID контроллера, дублирующих обработку данных. И все это с одной целью – обеспечить сохранность важных данных при любых аппаратных сбоях используемой системы хранения. Тем не менее, надо заметить, что 100% уверенность в сохранности данных может дать только дублирование систем хранения с соответствующей поддержкой со стороны используемого программного обеспечения.
Однако существуют опасности другого рода, от которых эти всевозможные аппаратные ухищрения не спасут: вирусы, сбои программ, да и просто человеческие ошибки, приводящие к потере данных. Наконец, не исключены стихийные бедствия, грозящие физическим уничтожением систем вместе со всей информацией. Единственная защита от таких ситуаций – резервное копирование данных (часто называемое бэкап – от английского backup). При этом резервные копии есть смысл сохранять исключительно на иных, чем источник копии, аппаратных устройствах. В идеале копия должна быть максимально удалена географически от оригинала, во избежание ее утери в случае серьезной техногенной катастрофы. Несмотря на простую, на первый взгляд, задачу – скопировать данные для их сохранности, решить ее технически грамотно позволит не всякое оборудование/программное обеспечение.
Идея снапшота довольно проста – по команде программы или человека данные как бы «замораживаются» и могут затем оставаться таковыми сколь угодно долго. В реальности программа или оборудование создают фактически виртуальный диск, на котором находятся не сами данные, а ссылки на них. Тем не менее, с точки зрения программ архивирования снапшот представляет собой полноценный диск с данными, который можно спокойно копировать, не боясь, что данные за время копирования будут изменены.
Попробуем кратко рассказать о том, как, собственно, работает механизм создания снапшотов. Для начала представим себе такую систему, в которой данные записываются параллельно и одновременно на два диска: основной и дублирующий. Такой вариант работы с данными часто называют «зеркалированием» данных.
Теперь представим себе, что в некоторый момент времени мы перестаем писать на дублирующий диск, а пишем только на основной. В результате в нашем распоряжении появляется резервная копия данных на вспомогательном диске, соответствующая времени прекращения записи на дублирующий диск. Это и есть Snapshot. Далее можно не торопясь создать копию содержимого дублирующего диска.
При таком подходе к созданию snapshot он уже не представляет собой физическую копию исходных данных, он представляет собой своеобразную логическую копию исходного тома. Разумеется, при этом он всегда сохраняет связь с исходным томом, а внешними серверами видится как отдельный том. При использовании технологии COW эта логическая копия исходных данных занимает меньший, чем сами данные, объем дискового пространства.
Более того, при начальном создании такого снапшота никакие данные вообще никуда не копируются (только создается копия каталога данных с указателями на места их хранения). Соответственно, этот процесс происходит практически мгновенно. И только когда данные изменяются в исходном томе, то их старое значение перемещается в зарезервированную для таких данных область. Когда же компьютер выдает запрос на чтение снапшота, то всегда извлекаются данные, «замороженные» в заданное время, вне зависимости от последующих операций различных приложений с этими данными. В случае необходимости восстановление данных из снапшота происходит с той же скоростью, что и архивирование, поскольку не измененные после «съемки» данные просто остаются на своих местах, а измененные данные копируются на свои старые места.
Достоинства столь простого способа создания снапшотов очевидны:
Во-первых, мы получаем копию практически мгновенно – копирование ссылок на данные (правильнее – каталога) занимает доли секунды.
Во-вторых, копируется весь каталог, включая ссылки на открытые файлы. Напомним, что файлы, открытые и заблокированные различными приложениями, скопировать стандартными средствами нельзя. Разумеется, далеко не факт, что при восстановлении данных удастся использовать заблокированные (незакрытые) файлы, но пусть лучше они будут, чем нет.
В-третьих, в данном варианте создание snapshot может быть реализовано аппаратно, силами RAID контроллера дискового массива. Это означает, что для компьютеров, подключенных к системе хранения, процесс создания снапшота будет незаметен, т.е. снижения производительности компьютеров не будет.
После того, как виртуальным томам или snapshot-томам назначены ID/LUNs (Logical Unit Number), компьютер видит каждый снапшот (если их несколько) как физический диск. Тем самым со снапшотами могут производиться те же действия, которые могут производиться и с обычными дисками.
К сожалению, не все так радужно в создании и применении снапшотов, как хотелось бы.
Основная проблема в том, что полученный snapshot фактически представляет собой копию данных весьма сомнительной полезности, поскольку мы как бы внезапно выключили компьютер и тем самым «заморозили» данные. Вполне возможно, что файлы, которые только начали создаваться, безвозвратно утеряны. Для файлов, содержимое которых должно быть измениться на диске, RAID контроллер не успел переписать все данные из своей кэш-памяти на диск и эти файлы вообще представляют собой абстрактный набор данных, что еще хуже просто потерянных данных.
Иными словами, снапшоты можно использовать, строго говоря, только в тех случаях, когда мы можем быть уверены в результате, т.е. целостности данных на момент «снимка». Самый простой вариант решения этой проблемы – завершить (остановить) работу всех приложений, использующих диск, снапшот с которого нам нужен, сделать «снимок», а затем снова запустить (возобновить работу) приложения.
Многие программы архивирования данных решают эту задачу довольно просто – на компьютер с приложением, данные которого надо периодически сохранять, ставится специальная программа, обычно называемая агентом, которая по специальной команде от программы архивирования «замораживает» данные в целостном состоянии. В качестве примера таких программ – Symantec Backup Exec, Computer Associates ARCserve® Backup.
Разумеется, такие агенты существуют только для конкретных программ и они не охватывают, да и не могут охватить все разнообразие применяемого программного обеспечения. Особенно это относится к не- Windows ОС, для которых таких агентов крайне мало. Именно поэтому программные агенты не являются панацеей и наилучшее соотношение затраты/результат дает применение совместно программного и аппаратного решения. Например, снапшот умеет создавать сама система хранения данных, но команду на создание система хранения получает от программы-агента, установленной на компьютере.
Поддержка снапшотов в системах хранения данных от компании Maxtronic
Сама по себе реализация snapshot в системах хранения от Maxtronic International выполнена по вышеописанной схеме – снапшот создается как каталог ссылок на исходные данные, а все перезаписываемые данные сбрасываются с помощью COW на диск со снапшотом.
Единственное существенное отличие в том, что вы можете дополнительно создать специальный COW-том, который не виден никому, но который может быть использован в том случае, если не хватает места на любом из снапшот-томов.
Перед созданием snapshot-копий для рабочего тома необходимо создать другой том (вторичный), связанный с рабочим томом (первичным), т.е. сформировать пару для Snapshot. Сами же snapshot-копии создаются на вторичном томе.
После того, как первоначальная snapshot копия создана, команды записи данных на первичный том вызовут выполнение операции “copy-on-write” (COW), т.е. копирование старых данных с первичного тома на вторичный перед записью новых данных на первичный том.
Snapshot-том (диск) – это виртуальный объект, который, как уже упоминалось выше, представляет собой ссылки на исходные данные. Когда необходимо чтение данных с Snapshot-тома, то данные берутся с первичного тома, если они не обновлялись, или с вторичного тома, если данные были изменены. Поскольку вторичный том хранит только отличающиеся данные, при начальной настройке Вы можете задавать размер вторичного тома в разы меньше, чем размер первичного тома. Однако не рекомендуется задавать размер вторичного тома менее 10 процентов от размера первичного тома, поскольку ссылки тоже занимают место, да и перезаписываемые данные требуют места для своего размещения. Пользователь может настроить службу оповещения системы хранения, потребовав сообщить ему об угрозе нехватки места под снапшоты. Конечно, учитывая дешевизну дисковой емкости, правильнее всего не экономить и создавать пары равного объема.
Первичному тому может соответствовать множество Snapshot-томов (копий), каждая для своего момента времени. При этом они будут храниться на единственном вторичном томе. На рисунке показаны соотношения первичного, вторичного томов, и Snapshot-томов. Заметим, что при наличии нескольких snapshot операция COW будет приводить к уменьшению быстродействия системы хранения. Поскольку снапшотов может быть много, то выполнение COW для разных снапшотов будет отнимать ресурсы системы хранения из-за разбросанности снапшотов по диску. Чем к большему количеству исходных данных для snapshot-томов будут запрашиваться обращения по записи в одно и то же время, тем больше будет снижаться быстродействие системы хранения от применения COW процедуры.
Процесс создания snapshot можно условно разделить на три этапа:
Этап 1: Проектирование (Планирование)
Наглядно эти этапы можно видеть на иллюстрациях ниже.
В данном примере мы использовали 3 диска. На 2 дисках по 750 GB будет создан RAID 0, а отдельный диск (JBOD) так таковым и останется. Для получения любой картинки в исходном разрешении просто щелкните на изображении.
Начало большого пути – исходное состояние
Создаем дисковую группу dg0 из двух дисков по 750 GB
Создаем логический диск dg0ld0
Назначаем lun0 ранее созданному dg0ld0 и мапируем lun0 на первый FC порт.
Этап 2: Конфигурация
Создаем логический диск jbod0, который затем будем использовать для хранения снапшотов.
Мы готовы к созданию пары томов – исходного в паре с томом под снапшот. Просто нажимаем кнопку S.VOL Pair
Создаем пару томов в связке из dg0ld0 и jbod0
Этап 3: Создание и использование Snapshot (Вручную или по сценарию)
При создании Snapshot для исходного тома, требуется:
Действия на этапах 1 и 2 выполняются только один раз, когда настраиваете систему хранения или когда создаете новый LUN. Они также могут выполняться при переконфигурировании системы хранения. Действие на этапе 3, очень вероятно, будет периодически повторяться, когда необходимо создать новый Snapshot.
И снова немного иллюстраций процесса:
Мы готовы к созданию снапшота
Нажимаем кнопку Create и создаем снапшот с именем svol0
Назначаем lun1 ранее созданному снапшоту svol0 и мапируем lun1 на первый FC порт.
Теперь с точки зрения внешнего мира у нас два диска – один оригинальный и один снапшот
Если вы опасаетесь, что места на снапшот томе может не хватить, то вы простым нажатием на кнопку S.COW VOL можете создать специальный невидимый внешнему миру том, который будет использоваться для хранения перезаписываемых данных для всех снапшотов
Все процедуры, описанные нами на этапе 3, выполнялись вручную. Разумеется, в реальной работе создание снапшота таким образом вряд ли будет нужно кому-либо. Поэтому правильнее всего применять процедуру создания снапшота по расписанию.
Достаточно скачать специальную программу для управления снапшотами и настроить планировщик задач Windows для запуска программы и тем самым создания/удаления снапшот в нужное время.
Например, для бэкапа данных Microsoft SQL Server можно применить такую последовательность действий:
Поддержка аппаратных снапшотов СХД NetApp в Veeam Backup & Replication v8
Одним из главных приоритетов современного резервного копирования, особенно в системах 24×7, является минимизация воздействия на производительность продуктивной сети. Хорошим вариантом решения, отвечающего этому приоритету, является создание дисковых снапшотов СХД на аппаратном уровне, так как оно не требуют вовлечения в этот процесс гипервизора, а алгоритм создания самих снапшотов оптимизирован разработчиками СХД на уровне аппаратуры.
NetApp — компания, относящаяся к лидерам на рынке СХД, обладает одной из самых передовых технологий в области дисковых снапшотов. Эта технология позволяет NetApp предоставлять пользователям своих СХД эффективную, экономичную по ресурсам хранения и, в общем случае, незначительно влияющую на производительность продуктивной системы технологию защиты данных от сбоев. Особая сила NetApp всегда заключалась в программной части СХД — операционной системе ONTAP, которая предлагает пользователям полнофункциональную платформу хранения данных, а также в технологии создания снапшотов, на которой базируются хорошо масштабируемые технологии защиты данных, такие как SnapMirror (репликация между NetApp СХД) и SnapVault (резервное копирование данных).
Производительность построения аппаратных снапшотов бывает разной — это зависит от разработчика СХД и конкретной модели устройства. Технология снапшотов от NetApp имеет стабильно высокую репутацию: она слабо нагружает СХД, создает небольшие по размеру снапшоты (что позволяет создавать их в большом количестве), и позволяет быстро восстанавливать систему. С помощью технологии SnapMirror снапшоты могут реплицироваться на резервную СХД, а также архивироваться с помощью технологии SnapVault.
Veeam Backup & Replication в своей работе применяет технологию “Резервное копирование из аппаратных снапшотов СХД”, которая была впервые представлена в прошлом году. Эта технология позволяет использовать аппаратный снимок диска в качестве источника данных для резервной копии (по сути вместо оригинальных данных), в результате чего не создается дополнительная нагрузка на исходную СХД, а пользователь получает все преимущества использования полновесного продукта для резервного копирования и восстановления после сбоев, такие как «гранулярное восстановление», «автоматическое тестирование целостности и восстановимости резервных копий», «виртуальная лаборатория», «архивирование на ленты» и другие. Теперь все эти преимущества доступны и для пользователей СХД NetApp.
Кроме того, поскольку пользователи NetApp часто используют свои СХД не только как блочное устройство, но и как NFS сервер, Veeam разработал свой NFS клиент, позволяющий выполнять резервное копирование с аппаратных снапшотов даже в тех случаях, когда виртуальные машины VMware запускаются с сетевых NFS папок, размещенных на СХД NetApp!
Следует особо отметить, что Veeam Backup for Storage Snapshots работает с СХД NetApp напрямую (а не через ESXi сервер), читая данные прямо из аппаратных снапшотов СХД, что значительно повышает быстродействие. Использование технологии CBT позволяет в разы (зависит от динамики изменения данных) снизить время сессии резервного копирования. Практически для пользователей это означает: уменьшение окна резервного копирования, минимизацию воздействия на инфраструктуру продуктивной сети и максимизацию RPO.
Одно из важнейших требований к процессу резервного копирования — быстрое восстановление. В случае сбоя, главное, что будет волновать пользователя — это скорость восстановления продуктивной системы, или RTO.
Для решения задачи по минимизации RTO в Veeam Backup & Replication уже несколько лет существует ряд технологий, включая патентованную Instant VM Recovery, которые позволяют выполнять быстрое восстановление отдельных файлов на дисках (поддерживается 17 файловых систем), виртуальных машин целиком, а также отдельных объектов виртуализованных приложений (таких как, например, электронные письма), с помощью семейства инструментов гранулярного восстановления Veeam Explorers или через технологию универсального восстановления Veeam U-AIR.
Veeam Backup and Replication может интегрироваться в существующую инфраструктуру защиты данных СХД NetApp без ее модификации, а затем использовать аппаратные снапшоты и данные SnapMirror и SnapVault как источники данных для восстановления данных (с помощью Veeam Explorer for Storage Snapshots). Интеграция выполняется просто — инфраструктура NetApp регистрируется в пользовательском интерфейсе Veeam Backup & Replication, после чего он собирает информацию о всех доступных точках восстановления среди доступных в системе аппаратных снапшотов СХД, а также данных SnapMirror и SnapVault.
Veeam Explorer for Storage Snapshots входит во все редакции Veeam Backup & Replication, включая Free Edition.
Совместно применение Veeam Backup & Replication и NetApp позволяет эффективно реализовать «правило резервного копирования 3-2-1» (3 копии данных, 2 физически разные среды хранения и 1 копия на внеофисном хранении) в рамках стратегии защиты данных от сбоев (см. рис. ниже).
Когда включена интеграция Veeam с NetApp, схема совместной работы продуктов следующая: Veeam Backup & Replication создает снапшот виртуальной машины, непротиворечивый на уровне приложений (т.е. созданный с применением технологии VSS). После этого создается аппаратный снапшот NetApp, из которого производится чтение данных, а затем создается новая резервная копия, которая сохраняется в репозитории резервных копий (например, на СХД или на ленточном накопителе).
Кроме описанного сценария, снапшот, созданный Veeam Backup & Replication, может быть использован как источник данных для NetApp SnapVault, что дает два преимущества — данные продуктивной сети читаются всего один раз и снапшот создается непротиворечивый на уровне приложений, а не диска (как в случае SnapVault без Veeam Backup & Replication).
Таким образом, совместная работа между Veeam Backup & Replication v8 и СХД NetApp может быть реализована несколькими путями, в результате чего достигается уникальное сочетание минимально возможных на практике RPO и RTO. Закрытое бета-тестирование версии Veeam Backup & Replication v8 уже началось. Версия предоставляется в индивидуальном порядке по обращению в отдел продаж, релиз запланирован на второе полугодие этого года. Подробнее об этом см. на сайте.
Snapshots — «фото на память (дисковую;)»
Всегда странно представлять себе времена, когда чего-то не было. Сложно сегодня представить себе, как мы жили без персональных компьютеров, без интернета, без торрентов, mp3, или без электрокопировальных аппаратов, в просторечии «ксероксов». Тем не менее всегда были времена, когда что-то привычное нам еще не существовало. Также обстояло дело и с понятием «снэпшота данных». Но сперва — что же такое «снэпшот»?
«Снэпшот» (дословно — «фотография», «моментальный снимок», здесь и далее под этим словом мы будем понимать конкретно, не уточняя, «снэпшот данных») это моментальная копия состояния данных в системе хранения, или программе, зафиксированная на определенный момент времени. Это может быть моментальное состояние содержимого файла, базы данных, или файловой системы (как частного случая «базы данных»).
В применении к системам хранения данных этот термин появился вместе с первыми системами хранения NetApp и был, на тот момент первой и главной их «фичей».
Ранее я уже рассказывал о внутренней файловой структуре WAFL, придуманной основателями NetApp для своего продукта, и о том, каким образом она работает. Интересующихся техническими деталями отошлю к прекрасной авторской публикации, которая сейчас переведена на русский язык. Именно эта, несколько необычная, на первый взгляд, по принципам работы, файловая структура сделала возможной реализацию концепции снэпшотов — мгновенных копий состояния данных, хранимых на дисках такой системы.
Как я уже рассказывал в статье про WAFL, основной принцип ее работы состоит в том, что однажды записанные на диск данные, в дальнейшем, не изменяются. Данные (например файл) можно на WAFL либо записать (целиком), либо стереть (целиком). В случае же необходимости изменения его содержимого эти изменения «дописываются» в свободное место дискового пространства, после чего на блоки с записанным содержимым изменений переставляется указатель содержимого файла (старый блок содержимого помечается как свободный, или не помечается, если на него ссылается более одного файла, или он использован в снэпшоте). Следовательно, для того, чтобы сохранить текущее состояние данных, при таком алгоритме работы записи, все что нам нужно, это сохранить «корневой inode» на данный момент времени.
Inode, напомню, это блок данных, определяющий содержимое файла. Он может ссылаться либо прямо на конкретные блоки, либо, для больших файлов, на промежуточные inodes, образуя «дерево» от «корня», единственного на всю файловую систему тома, так называемого «корневого» inode.
Таким образом, создав копию ровно одного блока, корневого inode данной файловой системы, мы получим, обратившись к нему, вместо текущего «корня», «псевдо-файловую систему», хранящую без изменений (read-only) все данные на момент времени, когда мы скопировали этот inode. Ведь, как вы помните, однажды записанные блоки данных файлов в дальнейшем не изменяются.
Каким же образом это выглядит на практике?
Для упрощения рассказа я буду рассматривать NAS-вариант работы NetApp, хотя, как вы знаете, аналогичным образом тот же самый сторадж может работать и как SAN-устройство.
Каждый том на системе хранения NetApp является отдельной файловой системой. На каждой файловой системе можно создать до 254 снэпшотов ее состояния, по методике, описанной выше.
Все созданные снэпшоты автоматически доступны через директорию /.snapshot (или /
snapshot) в корне тома. Зайдя туда, мы увидим имена созданных снэпшотов (они могут носить либо «собственное имя», например «/lets_fix_this_small_bug…oh_shit. «, будучи созданными вручную, либо, если создаются по расписанию, будут располагаться в поддиректориях hourly.0(1,2,3…), daily.0(1,2,3) и так далее.
Войдя в такую папку мы увидим полностью все содержимое нашего тома, со всеми файлами в нем, причем все файлы будут доступны на чтение, и читаться из них будет все то содержимое, которое было в них на момент взятия снэпшота.
Причем это даже выглядит несколько странно, на первый взгляд.
Допустим, что у вас есть том, размером 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.
Теперь рассмотрим более сложный вариант. Допустим, мы эксплуатируем большую, ответственную, mission-critical SQL-базу данных предприятия.
Разумеется, каждый вечер, эта база данных бэкапится на ленту, для создания резервной копии.
База большая, и резервная копия копируется на ленту примерно час.
«Ничто не предвещало беды», но однажды, посреди рабочего дня, допустим в 3 часа дня, база необратимо портится.
Какие действия предпринимает сисадмин, для того, чтобы базу восстановить?
Мы считываем резервную копию по состоянию на конец прошлого рабочего дня (читаться она будет, допустим, столько же, сколько писалась — час), а затем нам следует «накатить» на нее redo-log-и, от момента создания бэкапа, вечером, и до момента, предшествующего сбою, то есть до 3 часов следующего дня. Этот «накат» часто довольно объемен, и также занимает какое-то время, ведь операции в SQL происходят не мгновенно. Допустим, через 30 минут, после окончания считывания бэкапа, база восстановлена в рабочем состоянии на момент предшествующий сбою, и мы готовы продолжать работу. Итого — 1:30.
В случае использования снэпшотов дела будут происходить следующим образом. У нас также делается ежедневная копия на ленту для обеспечения безопасности хранения, например на случай полного выхода из строя системы хранения, но у нас хранилище живо, повреждены только данные на нем. Мы знаем, что час назад база была жива и здорова. Мы восстанавливаем базу по состоянию на 2 часа дня, и так как снэпшот создается и восстанавливается практически мгновенно, то это занимает не час, а всего несколько секунд, и накатываем на нее redo-logs, но не со вчерашнего вечера, как в предыдущем случае, а всего за один час, с 2 часов, то есть момента создания снэпшота, до момента аварии, в 3 часа дня. Это занимает также не полчаса, а всего несколько минут.
Итог: спустя несколько минут, а не полтора часа, как обычно, наша база вновь в рабочем состоянии.
Очевидные преимущества использования снэпшотов привели к тому, что, на сегодня, практически все производители систем хранения предлагают для своих систем ту или иную реализацию «снэпшотов» как идеи.
Однако, как мы помним, «не все йогурты одинаково полезны».
В чем же принципиальное отличие «настоящих снэпшотов» (Название Snapshots ™ для систем хранения это зарегистрированная торговая марка NetApp) от всех остальных, «контрафактных копий». 😉
Принципиальное отличие, позволяющее реализовать снэпшоты так, как это было описано мной выше — устройство WAFL, которое, как я уже рассказывал, не позволяет изменять уже записанные данные. Такая модель позволяет реализовать снэпшоты легко и просто. Но все обстоит хуже, если структура записи традиционна. При этом нам придется сперва, до начала использования, выделить зарезервированное пространство блоков, заранее отняв его у данных, затем, при каждом изменении блока на диске, копировать его содержимое в специальный зарезервированный пул, затем изменять его содержимое на его прежнем месте, затем изменять метаданные, указывающие на старое содержимое, для снэпшота.
Эта технология носит название Copy-on-Write (COW), и широко применяется в системах хранения других производителей, в их реализации снэпшотов.
Как вы видите из описания выше, даже само наличие включенного механизма снэпшотов для тома превращает одну операцию записи для системы хранения в три (чтение исходного содержимого, запись исходного содержимого на новое место, запись измененного содержимого на старое место).
Результат не заставляет себя ждать. Использование COW-snapshots резко ухудшает производительность системы хранения его использующего. Это разительный контраст с системами NetApp, в которых снэпшоты вообще никак не влияют на производительность, ведь никакого копирования при записи в них не происходит, все данные остаются на своих местах.
(демонстрация результатов производительности на тесте SPC-1)
Следствием такого неприятного поведения при использовании 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, а изнутри, анонимными голосами самих работников. «Пустячок, а приятно».