В этом посте я хотел бы рассмотреть подход к резервному копированию данных на Система хранения Серия NetApp Ф.
А.
С.
.
Архитектура резервного копирования
ВАФЛ
И начну издалека – со снимков.Технология Snapshot была впервые изобретена (и запатентована) в 1993 году компанией NetApp, и само слово Snapshot является ее торговой маркой.
Технология моментальных снимков логически вытекает из механизмов файловой структуры.
ВАФЛ .
Почему WAFL не является файловой системой глянь сюда.
Это факт ВАФЛ всегда записывает новые данные "в новое место" и просто перемещает указатель на содержимое новых данных в новое место, при этом старые данные не удаляются, эти блоки данных, на которые нет указателей, считаются освобожденными для новых записей .
Благодаря функции постоянной записи в новом месте механизм моментальных снимков был легко интегрирован в ВАФЛ , поэтому такие снимки называются перенаправлением при записи (RoW).
Подробнее о ВАФЛ .
Внутренняя структура WAFL
Снимки
В связи с тем, что снапшоты представляют собой копии инодов (ссылок) на блоки данных, а не сами данные, и система никогда не записывает в старое место, снапшоты в системах NetApp совершенно не влияют на производительность.ВАФЛ .
КОРОВА
Через некоторое время функционал «локальных снимков» оказался востребован и другими производителями оборудования, поэтому была изобретена технология снимков.КОРОВА .
Отличие этой технологии заключается главным образом в том, что все остальные файловые системы и блочные устройства, как правило, не имели встроенного механизма записи «в новое место», т.е.
старые блоки данных фактически перезаписываются при их перезаписано: исходные данные перезаписываются, а на их месте записываются новые данные.
А чтобы предотвратить повреждение снимка после такой перезаписи, предусмотрена выделенная область для безопасного хранения снимков.
Так, в случае перезаписи блоков данных в файловой системе, принадлежащих снимку, такой блок сначала копируется в пространство, отведенное для снимков, а на их место записываются новые данные.
Чем больше таких снимков, тем больше дополнительных паразитных операций, тем больше нагрузка на файловую систему или блочное устройство, а как следствие на всю дисковую подсистему и, возможно, всю Система хранения .
В связи с этим большинство производителей Система хранения и ПО, как правило, есть рекомендации иметь не более 1-5 снимков.
А для высоконагруженных приложений вообще рекомендуется не делать снапшоты или удалять единственную необходимую резервную копию, как только она больше не нужна.
Подходы к резервному копированию
Существует два подхода к резервному копированию: «чисто программный» и «Аппаратный помощник».Разница между ними заключается в том, на каком уровне будет выполнен снимок: на уровне хоста (программного обеспечения) или на уровне Система хранения (Ассистент HW).
«Программные» снимки выполняются «на уровне хоста» и в момент копирования данных из снапшота хост может испытывать нагрузку на дисковую подсистему, Процессор и сетевые интерфейсы.
Как правило, такие снимки стараются выполнять в непиковое время.
Снимки программного обеспечения также могут использовать стратегию КОРОВА , который часто реализуется на уровне файловой системы или какой-либо файловой структуры, которой можно управлять из Операционные системы сам хост. Примером этого может быть ext3cow , БТРФС , ВхФС , ЛВМ , Снимки VMware и так далее.
Снимки в Система хранения часто предоставляют базовые функции резервного копирования.
И, несмотря на недостаток КОРОВА , при использовании со снимками Hardware Assistant на уровне Система хранения , с этим можно как-то жить, только загрузка Система хранения , а не весь хост на момент выполнения резервного копирования, а затем сразу удалить снимок, чтобы он не загружался Система хранения .
Итак, вот оно.
Все относительно.
Поскольку у NetApp нет проблем с производительностью из-за снимков, снимки стали основой парадигмы резервного копирования для Система хранения ряд Ф.
А.
С.
.
Потому что Ф.
А.
С.
системы могут хранить до 255 снимков на том, мы можем восстановиться гораздо быстрее, если наши данные локальны.
Ведь очень удобно и быстро восстанавливаться, если восстанавливаемые данные расположены локально, и восстановление — это не копирование данных, а просто перезапись указателей на «старое место».
Стоит отметить, что другие производители в теории возможное количество снимков может достигать тысяч , но прочитав эксплуатационную документацию можно убедиться в том, что использовать КОРОВА Снимки на высоконагруженных системах не рекомендуются.
.
Разница в подходе
Так в чем же разница между подходами NetApp и других производителей, которые также используют снапшоты в качестве основы для резервного копирования? NetApp серьезно использует локальные снимки как часть своей стратегии резервного копирования и восстановления, а также для репликации, в то время как другие поставщики не могут себе этого позволить из-за снижения производительности.Это вносит существенные изменения в архитектуру резервного копирования.
Резервное копирование приложений и отказоустойчивых резервных копий
Снимки, сделанные «сами по себе», обеспечивают восстановление Crash Consistent, т.е.при откате к такому моментальному снимку, который когда-то был сделан, эффект будет такой, как если бы вы нажали кнопку Reset на сервере со своим приложением и загрузились.
Для обеспечения согласованного резервного копирования приложений требуется совместимость.
Система хранения с приложением, чтобы оно правильно подготовило данные перед созданием моментального снимка.
Взаимодействие между Система хранения и приложение может быть предоставлено с использованием агентов, установленных на том же хосте, где находится само приложение.
Существует целый ряд программного обеспечения для резервного копирования, которое может взаимодействовать с широким спектром приложений (SAP, Oracle DB, ESXi, Hyper-V, MS SQL, Exchange, Sharepoint), которые поддерживают аппаратные снимки в системах NetApp. Ф.
А.
С.
:
- Veeam Резервное копирование и репликация
- CommVault Симпана
- NetApp SnapManager/SnapCenter. О SnapManager для Oracle для SAN сетях можно почитать в соответствующей статье
- НетАпп SnapProtect .
- NetApp SnapCreator (бесплатная структура)
- Symantec NetBackup
- Symantec BackupExec
- Синхронная сортировка
- Акронис
Защита от катастроф
Для обеспечения физической отказоустойчивости существует множество механизмов, снижающих вероятность сбоя локального резервного копирования — РИАД , дублирование компонентов, дублирование путей и т. д. Почему бы не использовать уже имеющуюся аппаратную отказоустойчивость? Другими словами, снимки — это резервные копии, защищающие от логических ошибок данных, случайного удаления, повреждения информации вирусом и т. д. Снимки не защищают от физического выхода из строя самого устройства.Система хранения .
«Тонкая» репликация
Для защиты от физического уничтожения (пожар, наводнение, землетрясение, конфискация) данные все равно необходимо выполнить резервное копирование на резервную площадку.Стандартный подход к резервному копированию заключается в том, что весь объем данных будет перенесен на удаленную площадку.
Чуть позже пришла в голову идея сжимать эти данные.
Стоит отметить, что механизм сжатия (и извлечения) данных требует значительных ресурсов.
Процессор .
Дальше переносите только инкременты, чуть позже придумали обратные инкрементные бэкапы (чтобы не тратить время на сбор инкрементов в полный бэкап в момент восстановления), а для надежности периодически переносить полный набор данных.
И здесь тоже на помощь приходят снимки.
Их можно сравнить с обратными инкрементальными резервными копиями, создание которых не требует много времени.
Именно так системы NetApp первый раз передают полный набор данных, а затем всегда только снимок (приращение) в удаленную систему, увеличивая скорость резервного копирования и восстановления.
Попутно можно включить сжатие передаваемых данных.
Копирование управления данными
Использование одних и тех же данных для нескольких задач, таких как тестирование резервных копий с помощью клонирования и т. д., начало набирать популярность и называется управлением данными копирования (CDM).На «непродуктивном» сайте из клона также удобно производить каталогизацию, проверку резервных копий и тестирование и разработка на основе тонких клонов зарезервированные данные.
Парадигма резервного копирования
Таким образом, парадигма резервного копирования в Система хранения НетАпп Ф.А.
С.
состоит из набора подходов к:
- Удаление согласованных снимков, хранящихся в течение длительного времени, локально на одном и том же компьютере.
Система хранения и удаленно
- Тонкая репликация для архивирования/резервного копирования и восстановления
- «Тонкое клонирование» для тестирования
Восстановление с удаленной площадки происходит гораздо быстрее, используя снимки для передачи только «разницы» между данными, а не полной копии.
А локальные снимки в случае логического повреждения данных позволяют сократить окно восстановления до пары секунд. 
Пожалуйста, присылайте сообщения об ошибках в тексте на адрес ВЕЧЕРА .
Замечания и дополнения, пожалуйста, оставляйте в комментариях.
Теги: #Хранение данных #ИТ-инфраструктура #Резервное копирование #Хранение данных #Система хранения #Восстановление данных #Аварийное восстановление #netapp #CoW #replication #rto #netapp fas #snapshot #CDM #дедупликация #тонкое обеспечение #wafl #RPO #Data Ontap # снимки #d2d #d2d2t #D2D2T #ROW #каталог #Управление копированием данных
-
Как Стать Лучшим Блогом В Своей Нише
19 Oct, 24 -
Поиск Облачных Задач. Лекция В Яндексе
19 Oct, 24 -
Слава Людям! Убейте Всех Роботов!
19 Oct, 24 -
Служба Дистанционного Обучения
19 Oct, 24 -
Драма Из «Собачьего Зала»
19 Oct, 24
