Парадигма резервного копіювання NetApp

У цьому пості я хотелбы розглянути підхід до резервного копіювання даних на СГД NetApp серії FAS.


Архітектура резервного копіювання

WAFL


І почну я здалеку — зі снепшотов. Технологія снепшотов вперше була винайдена (і запатентована) в 1993 році компанією NetApp. Технологія снепшотирования логічно виникала з механізмів роботи файлової структури WAFL. Чому WAFL не файлова система дивіться тут. Справа в тому, що WAFL завжди пише нові дані «нове місце» і просто переставляє покажчик на вміст нових даних в нове місце, а старі дані не видаляються, ці блоки даних, на які немає покажчиків, вважаються высвобожденными для нових записів. Завдяки цій особливості запису, «завжди в нове місце», механізм снепшотирования був легко інтегрований в WAFL, з-за чого такі снепшоты називають Redirect on Write (RoW).


Внутрішнє пристрій WAFL

Snapshots


Завдяки тому, що снепшоты це копії инодов (посилань) на блоки даних, а не самих даних, а система ніколи не пише в старе місце, снепшоты в системах NetApp взагалі не впливають на продуктивність WAFL.


COW


Через час функціонал «локальних миттєвих копій виявився затребуваний іншими виробниками обладнання, так була винайдена технологія снепшотирования COW. Відмінність цієї технології полягає в основному в тому, що всі інші файлові системи, як правило, не володіли вбудованим механізмом запису «в нове місце», тобто старі блоки даних в момент їх перезапису реально перезаписуються: оригінальні дані затираються, а на їх місце записуються нові дані. І щоб запобігти пошкодженню снепшота після такої перезапису передбачається виділення для безпечного зберігання снепшотов. Так у випадку перезапису блоків даних у файловій системі, які відносяться до снепшоту, такий блок спочатку копіюється в зарезервоване для снепшотов простір, а на їх місце записуються нові дані. Чим більше таких снепшотов тим більше додаткових паразитичних операцій, тим більше навантаження на файлову систему, а як наслідок всю дискову підсистему і можливо, всю СГД.
У зв'язку з чим у більшості виробників СГД і програмного забезпечення, як правило є рекомендації мати не більше 1-5 снепшотов. А на високонавантажених додатках взагалі не рекомендується мати снепшотов або видаляти той єдиний необхідний для бекапа, відразу ж як тільки він перестане бути потрібними.


Підходи до резервного копіювання


Є два підходи в резервному копироровании: «чисто софтверний» і «Hardware Assistant». Відмінність між двома полягає в тому, на якому рівні буде виконаний снепшот: на рівні хоста (софтверний) або на рівні СГД (HW Assistant).

Снепшоты СГД часто є базовим функціоналам для резервного копіювання. І не дивлячись на брак COW, застосуванні з Hardware Assistant снепшотами на рівні СГД, з цим можна абияк жити, навантажуючи лише СГД, а не весь хост в момент виконання резервної копії, а потім відразу ж видаляти снепшот щоб той не навантажував СГД.

Так ось. Все пізнається в порівнянні.
Так як у NetApp немає проблем з продуктивністю через снепшотов, снепшоты стали основою для парадигми резервного копіювання для СГД серії FAS. Так як ми можемо зберігати до 255 снепшотов на вольюм, ми можемо відновлюватися набагато швидше, якщо наші дані знаходяться локально. Адже дуже зручно і швидко можна відновитися якщо дані для відновлення знаходяться локально, а відновлення це не копіювання даних, а лише перезапис покажчиків в «старе місце». Варто відзначити, що в інших виробників теоретично можливу кількість снепшотов може досягати тисяч, але вчитавшись у документацію щодо експлуатації можна впевнитися, що COW снепшоты на високонавантажених системах не рекомендується.

Відмінність у підходах


Так в чому ж відмінність між підходами NetApp та іншими виробниками, які також використовують снепшоты як основу для резервного копіювання? NetApp серйозно використовує локальні снепшоты, як частина стратегії резервного копіювання і відновлення, а також для реплікації, в той час як інші виробники не можуть собі цього дозволити через накладних витрат у вигляді погіршення продуктивності.


Application & Crash Consistent Backups


Снепшоты зняті «самі по собі» забезпечують Crash Послідовне відновлення, тобто відкотившись на такий колись знятий снепшот, ефект буде, як якщо б ви натиснули кнопку Reset на сервері з вашим додатком і завантажилися. Для того, щоб забезпечити Application Consistent Backup, необхідно взаємодію СГД з додатком, щоб воно належним чином підготувало дані перед снепшотом. Взаємодія між СГД і додатком може бути забезпечено за допомогою агентів встановлених на той самий хост, де живе сам додаток.


Існує цілий ряд ПО для резервного копіювання, яка вміє взаємодіяти з великим набором додатків (SAP, Oracle DB, ESXi, Hyper-V, MS SQL, Exchange, Sharepoint), що підтримують HW Snapshoots на системах NetApp FAS:


Захист від катастрофи


Для забезпечення фізичної відмовостійкості, існує безліч механізмів, які зменшують ймовірність виходу з ладу локального бекапу — RIAD, дублювання компонент, дублювання шляхів і т. д. Чому б не задіяти апаратну відмовостійкість яка вже присутня? Іншими словами снепшоты це бекапи захищають від логічної помилки даних, від випадкового видалення, псування інформації вірусом і т. д. Снепшоты не защиащают від фізичного виходу з ладу самої СГД.

«Тонка» реплікація

Для захисту від фізичного знищення (пожежа, повінь, землетрус, конфіскація) дані все-одно потрібно резервувати на запасну майданчик. Стандартний підхід резервного копіювання полягає в тому, що повний обсяг даних буде переданий на віддалену майданчик. Трохи пізніше придумали стискати ці дані. Варто відзначити, що механізм компресії (і витяги) даних вимагає значних витрат ресурсів CPU. Потім передавати тільки инкременты, ще трохи пізніше придумали зворотні инкрементальные бекапи (щоб не витрачати час на збір инкрементов в повний бекап в момент відновлення), а для надійності періодично передавати повний набір даних.


І тут теж приходять на допомогу снепшоты. Їх можна порівняти із зворотними инкриментальными бекапами не потребують тривалого часу на їх створення. Так системи NetApp перший раз передають повний набір даних, а потім завжди, тільки снепшот (інкремент) на віддалену систему, збільшуючи швидкість виконання резервного копіювання і відновлення. Попутно є можливість включити стиснення передаваемыех даних.


Каталогізація і Тестування резервних копій


На «продуктивному» сайті також зручно виконувати катологизацию, перевірку бекапів, а також тестування та розробку на базі клонів зарезервованих даних.


Парадигма резервного копіювання


Таким чином парадигма резервного копіювання СГД NetApp FAS складається з сукупностей підходів до:
  • Зняттю консистентних снепшотов довгостроково зберігаються, як локально на тій же СГД, так і віддалено
  • «Тонка реплікація» для архівування/резервного копіювання і відновлення
  • «Тонке клонування» для тестування


Перераховане дозволяє не мати проблем з продуктивністю, більш швидко і консистентним знімати (зменшити вікно резервного копіювання) і копіювати дані (а як наслідок мати можливість знімати резервні копії частіше) без припинення в обслуговуванні навіть у робочий час. Відновлення з віддаленої майданчика виконується набагато швидше, за допомогою снепшотов передаючи тільки «різницю» між даними, а не повну копію. А локальні снепшоты у випадку логічного ушкодження даних, дозволяють зменшити вікно відновлення до пари секунд.



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

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

0 коментарів

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