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

Мета цієї статті — описати, що відбувається під час резервного копіювання Avamar, зосередившись на тому, щоб допомогти читачеві зрозуміти поведінку продуктивності резервного копіювання.

Ця стаття є доповненням до наступних статей:

• Авамар: Усунення несправностей, пов'язаних із низькою продуктивністю резервного копіювання
• Авамар: Налаштування резервного копіювання для швидкого завершення

Що відбувається під час резервного копіювання Avamar?

Процес

резервного копіювання avtar:1) Завантажує файли файлу та хеш-кешу в пам'ять

2017-06-09 23:00:25 avtar Info <5586>: Loading cache files from C:\Program Files\avs\var
2017-06-09 23:00:25 avtar Info <8650>: Opening filename cache file 'C:\Program Files\avs\var\f_cache2.dat'
2017-06-09 23:00:25 avtar Info <5573>: - Loaded filename cache file (6,532,792 bytes)
2017-06-09 23:00:26 avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\p_cache.dat'
2017-06-09 23:00:28 avtar Info <5573>: - Loaded hash cache file (402,653,728 bytes)
2017-06-09 23:01:01 avtar Info <6426>: Done loading cache files

2) Створює знімки VSS (на Windows):

2017-06-09 23:04:32 avtar Info <19008>: Obtaining available VSS providers
2017-06-09 23:04:32 avtar Info <8776>: Freezing volumes now...
2017-06-09 23:04:32 avtar Info <8780>: Creating the shadow copy set (DoSnapshotSet) ... 
2017-06-09 23:14:33 avtar Info <8781>: Shadow copy set successfully created.
2017-06-09 23:14:34 avtar Info <6074>: VSS snapshot set creation successful

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

Для отримання більш детальної інформації дивіться Avamar: Що відбувається, коли avtar читає файл на етапі сканування файлів.

4) Порівняйте обчислені хеші з хешами в кеші

локального клієнта Avtar шукає хеш файлу в кеші файлів. Він перевіряє, чи він новий, чи не був він змінений з моменту попереднього резервного копіювання.

Якщо пошук кешу файлів успішний, файл існує і залишається незмінним.

Якщо пошук не вдається, це означає, що файл новий або змінений. Його необхідно прочитати і обробити.

Щоб дізнатися більше, перегляньте статтю Клієнт Avamar - Що має змінитися, перш ніж avtar вважатиме файл зміненим?

5) Обробляти нові та змінені файли

Для будь-якого нового або зміненого файлу avtar повинен:

• Прочитати весь файл
• Розбийте його на частини різного розміру
• Стиснення кожного фрагмента
• Обчислити хеш для кожного фрагмента

6) Перевірте, чи відсутні хеші на сервері Avamar.

Avtar надсилає дані про будь-які відсутні хеші через мережу на сервер Avamar, щоб перевірити, чи вони вже існують. Вони відомі як запити 'ispresent'

.7) Дані записуються на сервер Avamar (і, якщо це доречно, на домен даних). 

Більш детальну інформацію про робочий процес дивіться у Avtarprocess.pdf, що додається.


Огляд резервної копії Avamar з точки зору продуктивності:

Беручи наведені вище етапи, ми розділили їх на «фази», які мають найбільший вплив на продуктивність резервного копіювання:

Фаза 0. Створюйте знімки VSS.

Служба тіньового копіювання томів (VSS) створює знімки томів, визначених у вихідному наборі даних. Програми можуть продовжувати запис на том під час виконання резервного копіювання.
Avamar створює резервну копію «замороженого» знімка тому лише для читання, а не тому, який можна записати. Це гарантує, що він має послідовний набір даних для резервного копіювання.

Знімки VSS займають лічені секунди. Якщо у клієнта виникають проблеми з VSS, це затримка або перешкоджає продовженню резервного копіювання.

Етап 1. Фаза сканування файлів. Процес avtar оцінює всі файли в цільовому наборі

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

Для клієнта з обертовими дисками в конфігурації RAID 5 типовою є продуктивність сканування файлів ~1 мільйон файлів на годину. Це варіюється від 300 000 до 3 мільйонів на годину. Це залежить від клієнтського середовища та характеристик даних, що резервуються.

Починаючи з версії 7.3, клієнти Linux, які створюють резервні копії в Data Domain, можуть скористатися перевагами функції Linux Fast Incremental (LFI). Це дозволяє уникнути сканування всього набору даних щоразу, коли виконується резервне копіювання.

Критичні ресурси: продуктивність диска, на якому зберігаються дані резервної копії, випадковий

пошук.Етап 2. Avtar зчитує змінені файли, а потім фрагментує, стискає та хешує дані.

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

Файли в резервних копіях бази даних часто великі і, як правило, змінюються щодня. Більшу частину свого часу Avtar проводить у цій фазі. Найкраще використовувати офіційні плагіни бази даних Avamar, щоб забезпечити ефективну обробку бази даних, використовуючи функцію інкрементного резервного копіювання, журнали транзакцій тощо.

Типова продуктивність обробки файлів становить близько 100 ГБ на годину, але може варіюватися до 300 ГБ на годину. Це залежить від навколишнього середовища.

Критичні ресурси: Клієнтський диск і центральний процесор

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

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

Для наборів даних файлової системи очікуйте, що ~0-3% файлів змінюватимуться щодня.

Avtar повинен 'stat()' кожного файлу, який змінюється, виконуючи дві операції введення-виведення, одну для перевірки атрибутів файлу, іншу для атрибутів безпеки.

Щоб досягти еталонної швидкості сканування на рівні ~1 мільйона файлів на годину для резервного копіювання файлової системи, avtar потребує приблизно двох мільйонів операцій пошуку на годину або 600 операцій пошуку на секунду.

Наприклад: Якщо частота змін у резервній копії становить 3%, то 97 зі 100 файлів потребують двох операцій пошуку дисків, щоб визначити, чи змінилися вони. Решта три, які змінилися, повинні бути відскановані, фрагментовані, стиснуті та хешовані.

Це враховує лише етап сканування файлів і не враховує ресурси введення-виведення, необхідні для обробки будь-яких змінених файлів.
Чим більше даних у змінених файлах, тим більше роботи потрібно для завершення резервного копіювання.

Етап 3. Перевірка існування хешів на сервері

AvamarФази #1 і #2 створюють хеші, які вказують на елементи резервної копії. Ці елементи можуть бути унікальними фрагментами файлів, файловими системами або цілими резервними копіями.

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

Порівняння хешів між клієнтом і сервером Avamar зазвичай відбувається швидко. Вони не повинні обмежувати резервну копію, якщо сервер Avamar є;

• Здоровий
• При регулярних навантаженнях
• Розташування в тому ж сегменті локальної мережі, що й клієнт

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

Критичні ресурси: Час відгуку мережі та випадкова продуктивність вузла даних Avamar.

Випадковим чином шукають продуктивність фізичної шкали Авамара з кількістю та розміром вузлів даних. Системи AVE працюють гірше, порівняно з системою з одним вузлом.

Етап 4. Надсилання нового фрагмента через мережу на сервер Avamar або домен

данихКоли клієнт надсилає на сервер новий, унікальний фрагмент (розміром до 64 КБ), продуктивність залежить насамперед від пропускної здатності мережі. В основному це стосується клієнтів на базі WAN, які щодня генерують велику кількість змінених даних. Це також може вплинути на тих, хто працює через перевантажені мережеві канали. 

Нижче наведені схеми, що показують потік даних, куди клієнт відправляє дані в систему Avamar і в інтегровану систему Avamar - Data Domain.






Критичні ресурси: Пропускна здатність мережі між клієнтом і сервером

Фаза 5. Дані, записані на сервер Avamar або Data Domain

Резервні копії даних повинні бути записані на сервер Avamar або систему Data Domain.

Критичні ресурси: Продуктивність запису на диск сервера Avamar і загальне завантаження.