Підводні камені резервного копіювання і відновлення дедуплицированных даних в сценарії disaster recovery



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


Попередня стаття знаходиться тут: Підводні камені резервного копіювання в гібридних системах зберігання.

Введення
Раз дедуплицированные дані займають менше місця на дисках, то логічно припустити, що резервне копіювання і відновлення повинні займати менше часу. Дійсно, чому б не бэкапить/відновлювати дедуплицированные дані одразу в компактному дедуплицированном вигляді? Адже в цьому випадку:

  • бекап поміщаються тільки унікальні дані.
  • Не треба редуплицировать (регидрировать) дані на продуктивній системі.
  • Не треба назад дедуплицировать дані на СРК.
  • І навпаки, відновити можна лише ті унікальні дані, які необхідні для реконструкції. Нічого зайвого.
Але якщо розглянути ситуацію уважніше, то виявляється, що не все так просто, прямий шлях не завжди ефективний. Хоча б тому, що у СГД загального призначення та СГД резервного копіювання використовується різна дедупликация.

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


Принцип дедуплікаціі.

У випадку з продуктивними даними, дедупликация призначена не тільки і не стільки для зменшення місця на дисках, скільки для підвищення швидкості доступу до даних за рахунок їх більш щільного розміщення на швидких носіях. Крім того, дедуплицированные дані зручні для кешування.

Один дедуплицированный блок кеш-пам'яті, на верхньому рівні багаторівневого зберігання, або просто розміщений на флеші, може відповідати десяткам чи навіть сотням ідентичних блоків даних, які раніше займали місце на фізичних дисках та мали абсолютно різні адреси, а тому не могли бути ефективно кешованими.

Сьогодні дедупликация на СГД загального призначення буває дуже ефективна і вигідна. Наприклад:

  • На флеш-системи (All-Flash Array), можна покласти істотно більше логічних даних, ніж зазвичай дозволяє їх «сира» ємність.
  • При використанні гібридних систем дедупликация допомагає виділити «гарячі» блоки даних, оскільки при цьому зберігаються лише унікальні дані. І чим вище дедупликация, тим більше звернень до одним і тим же блокам, а отже — вище ефективність багаторівневого зберігання.

Ефективність рішення задачі зберігання за допомогою поєднання дедуплікаціі і тиеринга. У кожному варіанті досягається рівна продуктивність і ємність.

Дедупликация у СГД резервного копіювання
Спочатку дедупликация отримала широке поширення саме в цих системах. Завдяки тому, що однотипні блоки даних копіюються на СРК десятки, а то і сотні разів, то за рахунок виключення надмірності можна досягти суттєвої економії місця. В свій час це стало причиною «наступу» на стрічкові системи дискових бібліотек для резервного копіювання з дедупликацией. Диск сильно потіснив стрічки, тому що вартість зберігання резервних копій на дисках стала дуже конкурентоспроможною.


Перевага дедуплицированного бекапа на диски.

У підсумку, навіть такі прихильники стрічок, як Quantum, стали розвивати у себе дискові бібліотеки з дедупликацией.

Яка дедупликация краще?
Таким чином, в світі зберігання зараз є два різних способу дедуплікаціі – у резервному копіюванні і в системах загального призначення. Технології у них різні — з періодичним та фіксованим блоком відповідно.

Відмінність двох методів дедуплікаціі.

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

Дедупликация зі змінним блоком може краще розпізнавати повтори в потоці даних, але для цього їй потрібно більше ресурсів процесора. До того ж, вона малопридатна для надання блочного або багатопотокового доступу до даних. Це пов'язано зі структурою зберігання дедуплицированной інформації: якщо говорити спрощено, то вона теж зберігається змінними блоками.

Зі своїми завданнями обидва методи допомагають відмінно справлятися, але з невластивими завданнями все йде набагато гірше.

Давайте розглянемо ситуацію, що виникає на стику взаємодії цих двох технологій.

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

Наприклад, фізично зберігається 10 Тб продуктивних дедуплицированных даних з сумарним коефіцієнтом 5:1. Тоді в процесі резервного копіювання відбувається наступне:

  • Копіюється не 10, а повністю 50 Тб.
  • Продуктивної системі, в якій зберігаються вихідні дані, доведеться виконати роботу за регідрації («редуплікації») даних у зворотну сторону. У той же час вона повинна забезпечувати роботу продуктивних додатків і потік даних резервного копіювання. Тобто три одночасних важких процесу, навантажувальних системні шини вводу-виводу, кеш-пам'ять і процесорні ядра обох систем зберігання.
  • Цільової системи резервного копіювання доведеться назад дедуплицировать дані.
З точки зору використання процесорних ресурсів — це можна порівняти з одночасним натисканням на газ і гальмо. Виникає питання — чи можна це якось оптимізувати?

Проблема відновлення дедуплицированных даних
При відновленні даних на тома з включеною дедупликацией доведеться весь процес повторити у зворотній бік. Далеко не у всіх системах зберігання даний процес працює «на льоту», а в багатьох рішеннях використовується принцип «post process». Тобто дані спочатку записуються на фізичні диски (нехай навіть на флеш) як є, потім аналізуються, порівнюються блоки даних, виявляються дублікати, і тільки потім проводиться очищення.


Порівняння In-line і Post-Process Dedupe.

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

Цей можливий сценарій відноситься не стільки до відновлення даних з бекапа (Data recovery), мінімізує ризики класу Data loss, скільки до відновлення після катастрофічно великої втрати даних (яка класифікується як катастрофа, тобто Disaster). Однак такий Disaster Recovery м'яко кажучи, не оптимальний.

Крім того, при катастрофічному збої зовсім не обов'язково відновлювати всі дані відразу. Досить почати лише з самих необхідних.

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

Навіщо тоді взагалі потрібен бекап, з якого у разі катастрофи можна відновитися лише з величезним трудом, і майже напевно не повністю? Адже існують вбудовані в продуктивну систему зберігання реплікацію (віддзеркалення, снэпшоты), які не чинять істотного впливу на продуктивність (наприклад, VNX Snapshots, XtremIO Snapshots). Відповідь на це питання буде все той же. Однак, будь-який нормальний інженер спробував би цю ситуацію якось оптимізувати та поліпшити.

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

Ось лише кілька прикладів:


<a href=»www.symantec.com/connect/forums/windows-server-2012-deduplication-and-backup-exec>Windows Server 2012 Deduplication and Backup Exec
Backup and Restore Considerations for Deduplicated Volumes
Backup and Restore of Data Deduplication-Enabled Volumes

Але це всього лише «латки» на рівні операційних систем та окремих ізольованих серверів. Вони не вирішують завдань на загальному апаратному рівні у СГД, де це дійсно складно зробити.

Справа в тому, що у СГД загального призначення і в системах резервного копіювання використовуються різні, спеціально розроблені алгоритми дедуплікаціі — з фіксованим і змінним блоками.

З іншого боку, далеко не завжди потрібно робити повне резервне копіювання, і значно рідше — повне відновлення. Зовсім не обов'язково піддавати дедуплікаціі і стиску всі продуктивні дані. Тим не менше, потрібно пам'ятати про нюанси. Тому, що катастрофічні втрати даних ніхто не відміняв. І для їх запобігання розроблені стандартні промислові рішення, які повинні бути передбачені регламентом. Так що якщо відновити дані з бекапа за нормальний час не вдається, то відповідальним людям це може коштувати кар'єри.



Давайте розглянемо, як найкращим чином підготуватися до подібної ситуації і уникнути неприємних сюрпризів.

Резервне копіювання

  • Використовуйте по можливості інкрементальний бекап і синтетичні повні (full synthetic) копії. У Networker, наприклад, ця можливість є, починаючи з версії 8.
  • Закладайте більше часу на повний бекап, враховуючи необхідність регідрації даних. Вибирайте час мінімальної утилізації процесорів системи. В ході бекапів краще поспостерігати за утилізацією процесорів продуктивної СГД. Краще, щоб вона не перевищувала 70% хоча б в середньому за період бекапа.
  • Осмислено застосовуйте дедупликацию. Якщо дані не дедуплицируются і не збирались, то навіщо витрачати процесорну потужність в ході бекапа? Якщо ж система дедуплицирует завжди, то вона повинна бути досить потужною, щоб впоратися з усією роботою.
  • Приймайте до уваги процесорну потужність, виділену для дедуплікаціі у СГД. Ця функція зустрічається навіть в системах початкового рівня, які не завжди справляються з одночасним виконанням всіх завдань.
Повне відновлення даних, Disaster Recovery

  • Підготуйте адекватний Disaster Recovery або Business Continuity Plan, враховує поведінку систем зберігання з дедупликацией. Багато вендори, включаючи EMC, а так само системні інтегратори, пропонують послуги такого планування, тому що в кожній організації є своя унікальна комбінація факторів, що впливають на процес відновлення роботи додатків
  • Якщо СГД загального призначення використовує механізм дедуплікаціі post-process, то я б рекомендував передбачити в ній буфер вільної ємності, на випадок відновлення з бекапа. Наприклад, розмір буфера можна прийняти як 20% від логічної ємності дедуплицированных даних. Намагайтеся хоча б в середньому підтримувати цей параметр.
  • Шукайте можливості архівувати старі дані, щоб вони не заважали швидкому відновленню. Навіть якщо дедупликация хороша і ефективна, не чекайте збою, після якого доведеться відновлювати з бекапа і повністю дедуплицировать тома у багато десятків Тб. Всі неоперативні/історичні дані краще перенести в онлайновий архів (наприклад, на основі Infoarchive).
  • Дедупликация даних «на льоту» у СГД загального призначення має перевагу перед post-process з точки зору швидкості. Вона може зіграти особливе значення при відновленні після катастрофічної втрати.
Такі мої деякі міркування щодо резервного копіювання і відновлення дедуплицированных даних. Буду радий почути тут ваші відгуки та думки з цього питання.

І, треба сказати, що тут ще не торкнуться один цікавий приватний випадок, що вимагає окремого розгляду. Так що продовження буде.
Денис Сєров

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

0 коментарів

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