SnapProtect: Архітектура резервного копіювання на системах NetApp FAS

У цій статті я розгляну як архітектура SnapProtect практикує життя "парадигму резервного копіювання NetApp", використовуючи передові технології і переваги систем зберігання, серії FAS. ЗА SnapProtect (SP) призначене для управління життєвим циклом резервних копій, архівацією і відновленням даних для всієї інфраструктури, розташованої на СГД NetApp FAS. SP забезпечує зв'язність з додатками, консистентним при знятті резервної копії, управління реплікацією/архівацією між сховищами, каталогізацією, відновлення даних у разі необхідності, перевіркою резервних копій, а також інші функції.

SnapProtect складається з наступних основних компонентів:

  • Сервер з SnapProtect Management Server (CommServe license), для відмовостійкості застосовується кластеризація (на рівні додатку + кластеризація БД)
  • Сервери з інстальованим MediaAgent'ами.
  • Агенти iDataAgent (iDA). Встановлюються на хости для інтеграції з ОС, файловими системами, програмами та іншими компонентами хостової ОС.
  • SP взаємодіє з сховищем NetApp через Oncommand Unified Manager.


Існують такі iDA агенти:
  • VSA — Для VMWare і Hyper-V
  • для Oracle під Windows/Unix/Linux (В тому числі з RAC)
  • для Exchange (у тому числі з DAG)
  • для MS SQL
  • для SnarePoint
  • Qsnap Driver для файлових систем Win/Unix
  • NAS NDMP iDA
  • DB2 Unix/Linux
  • Lotus Domino на Windows
  • Active Directory iDA


Консистентним, як було сказано раніше виконується за засобом агента iDA встановленого на хості перед зняттям hardware-assistant SnapShot на стороні сховища.
Реплікація (консистентних) снепшотов між стореджами може бути виконана за допомогою SnapMirror або SnapVault.
Заливка даних з основної або резервної системи на стрічкову бібліотеку виконується через медіа агент для SAN NAS даних. Також для NAS можна виконувати заливання даних безпосередньо з сховища NetApp на стрічкову бібліотеку засобом протоколу NDMP і SMtape, на жаль, у цьому випадку не підтримується каталогізація даних.
Катологизация виконується як пост-процес за допомогою примапливания клонованих (технологія FlexClone) снепшотов з сховища NetApp.

Відновлення даних може бути виконано як з віддаленого сховища, локального, так і з стрічкової бібліотеки.
Є кілька способів (можна навіть сказати шляхів) відновлення, в залежності від типу даних, типу відновлення і розміщення цих даних.
Так для відновлення всього вольюма або qtree з снепшота на локальному сховищі може бути задіяна технологія миттєвого відновлення засобами сховища з снепшота — SnapRestore. При аналогічному відновленні але з віддаленої системи, потрібно виконати «зворотний реплікацію» за допомогою технології SnapMirror або SnapRestore. Копіювати можна не тільки самі останні дані, але і один з снепшотов розташований на віддаленому сховищі.
При необхідності «гранулярного відновлення», внутренеяя логіка виглядає як клонування снепшота видаленою або основної системи до медіа агенту перенесення необхідних об'єктів з медіа агента необхідних хост. Відновлення з стрічкової бібліотеки відбувається аналогічним чином — через медіа агент на хост.

Технології необхідні на сховищах:
Таким чином підсумовуючи можна сказати, що на основному сайті обов'язково повинні бути присутніми технології FlexClone, SnapRestore, одна з ліцензій реплікації (SnapVault/SnapMirror) і власне сам SnapProtect.

На резервному сховище, відповідно необхідно наявність FlexClone якщо каталогізація буде виконуватися там. Якщо за схемою резервного копіювання/відновлення потрібно мати можливість швидкого відновлення вольюма з снепшота на віддаленому сховищі, то на такому сховищі необхідно наявність технології SnapRestore. Так як ми реплицируем дані з основної системи на віддалену, то також на віддаленій системі необхідна підтримка технології реплікації (SnapVault/SnapMirror). До всього іншого потрібна підтримка самого SnapProtect.

Як результат NetApp жорстко регламентує додаткові ліцензії на основної та резервної СГД:


Гранулярное відновлення.
Під гранулярностью відновлення розуміється можливість відновлення не цілого місяць/вольюма з даними, а окремих об'єктів або файлів, що знаходиться на місяці. Наприклад, для віртуальної інфраструктури таким об'єктом може бути віртуальна машина, файл віртуальної машини, vDisk або окремі файли всередині віртуальної машини. Для Баз даних таким об'єктом може бути окремий інстанси бази. Для Exchange це може бути окремий поштову скриньку або окремий лист і т. д.

SAN + Грануляный бекап і відновлення
У випадку з застосуванням SAN архітектури з додатками потребують гранулярного відновлення, таких як Exchange, Oracle, MS SQL та інших, необхідно дані таких додатків розміщувати на окремому виділеному місяці. У разі застосування віртуалізації з такими додатками діє те ж правило: необхідно розміщувати дані від цих додатків на окремо виділеному RDM диску. Самі ж місяця на боці системи зберігання повинні, кожен, лежати в окремому вольюме. Приміром, у разі віртуалізації з БД Oracle і використанням SAN мережі, необхідно виділити під кожен тип даних БД окремий лун, підключений у вигляді RDM, точно з такими ж правилами, як якщо б замість SnapProtect ми використовували SnapManager. Тобто логіка розбиття та розміщення дисків для SnapProtect буде така ж як і для SnapManager, тут діють одні і ті ж правила. Адже і технології консистентного зняття hardware-assistant снепшотов в обох випадках схожі, якщо не сказати ідентичні.
Докладніше розглянути цей приклад можна в моїй статті «SnapManager for Oracle & SAN мережа» на хабре.


Повідомлення щодо помилок у тексті прошу направляти в ЛС.
Зауваження і доповнення навпроти прошу в коментарі

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.