Авамар: Концепції управління потенціалом та навчання

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

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

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

Завдання цієї статті:
  • Узагальнити типи даних, які зберігаються у розділах /data*.
  • Введіть поняття «ємність операційної системи» і порівняйте його з поняттям «ємність користувача» (іноді її називають «ємністю GSAN»).
  • Поясніть, чому Avamar не слід запускати близько до ліміту можливостей користувача.
  • Перерахуйте фактори, які впливають на накладні витрати на контрольні точки.
  • Опишіть, як контролювати використання розділів даних.
  • Опишіть симптоми, які виникають, якщо продуктивність операційної системи виходить з-під контролю.
  • Назвіть типові причини виникнення MSG_ERR_DISKFULL повідомлення.
  • Окресліть методи відновлення, які використовуються там, де висока продуктивність операційної системи впливає на нормальну роботу системи.
  • Опишіть симптоми, які виникають, якщо Місткість користувача перевищує обмеження потужності користувача.
  • Обговоріть, як відновитися після ситуації з високою продуктивністю користувачів.
У цій статті передбачається, що читач знайомий з розділом «Управління потенціалом» у Посібнику з найкращих операційних практик Avamar. Посібники, що стосуються вашого операційного середовища, знаходяться в розділі Як знайти документацію Avamar на сайті підтримки Dell. Поширеними проблемами, які впливають або є симптомами занадто високої «ємності операційної системи», є:
  • Перевірка контрольних точок (HFS Check) не проходить.
  • Збір сміття не запускається, і звіти з MSG_ERR_DISKFULL.
  • Помилки створення контрольних точок.
Загальними симптомами, які тісно пов'язані з занадто високою «здатністю користувача», є:
  • Резервне копіювання не працює.
  • Вхідні завдання реплікації зазнають невдачі.
  • Інтерфейс адміністратора показує систему в режимі «Адміністратор» під час вікна резервного копіювання.

Cause

Дивіться розділ Роздільна здатність.

Resolution

Як зберігаються дані в сітці Avamar?

Управління ємністю Avamar стосується даних, які знаходяться в розділах /data* всіх вузлів даних Avamar. Вона складається з:
  • Дедупліковані дані резервного копіювання
  • Дані про паритет RAIN
  • Накладні дані контрольно-пропускних пунктів
Як парність RAIN, так і дані контрольних точок є рівнями резервування, доступними для Avamar на додаток до RAID та реплікації.

Вільне місце в розділах даних також потрібне для коректного виконання завдань обслуговування,

таких як збір сміття та асинхронна обробка смуг.Нижче наведено графічне представлення фізичного простору зберігання, доступного в розділах даних на вузлах зберігання Avamar. Розбивка ємності Avamar


Як зберігаються дані в розділах даних?

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

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

Якщо будь-який з розділів даних займає більше 85% всього простору, збір сміття не може запуститися.

Маркер 100% місткості користувача (обмеження лише для читання) вказує на те, що для зберігання дедуплікованих даних доступно до 65% загального простору в розділі даних. Простір під цим маркером 100% можливостей користувача еквівалентний значенню використання сервера, яке відображається в інтерфейсі адміністратора. Якщо обсяг дедуплікованих даних, які зберігаються на будь-якому розділі даних на будь-якому вузлі, досягає 65%, то система Avamar стає доступною тільки для читання і відмовляється від подальшого резервного копіювання даних.

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


Чому систему Avamar не можна запускати близько до ліміту «Можливості користувача».

Взаємозв'язок між високою «пропускною спроможністю користувача» та накладними витратами на контрольні точки є таким, що в міру того, як система стає все більш заповненою, навіть невелике збільшення резервних даних може спричинити значне збільшення накладних витрат на контрольні точки. Повне обговорення того, чому це так, виходить за рамки цієї статті, однак важливо пам'ятати:
  • Чим ближче система Avamar до 100% потужності користувача, тим менша ємність операційної системи доступна для накладних витрат на контрольні точки.
У повній системі, як ми бачимо на діаграмі вище, накладні витрати на контрольну точку обмежені 20% від загального простору операційної системи в розділах даних.

Для того, щоб система Avamar надійно працювала на високих рівнях "User Capacity", вона повинна відповідати наступним критеріям: Якщо будь-яке з цих тверджень перетвориться з істинного на хибне, можна очікувати, що накладні витрати на контрольні точки поступово зростуть або раптово зростуть і спричинять серйозні операційні проблеми.


Фактори, що впливають на накладні витрати на контрольно-пропускні пункти:

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


Як контролювати використання розділів даних:

Правильним способом моніторингу використання розділу даних операційної системи є використання наступної команди Avamar з вузла утиліти Avamar.

Наприклад:


admin@utilitynode:~/>: avmaint nodelist | grep fs-percent
        fs-percent-full="7.8"
        fs-percent-full="6.3"
        fs-percent-full="6.4"
        fs-percent-full="6.4"
        fs-percent-full="7.6"
        fs-percent-full="6.2"
        fs-percent-full="6.1"
        fs-percent-full="6.6"
        fs-percent-full="7.8"
        fs-percent-full="6.4"
        fs-percent-full="6.5"
        fs-percent-full="6.8"
Цей вихід дає вам справжнє уявлення про використання ємності операційної системи. У сітці, де вузли даних використовують пул файлів, Linux df не має сенсу, оскільки страйпи попередньо розміщені у пулі файлів, і багато з них можуть не використовуватися.


Що станеться, якщо використання ємності операційної системи вийде з-під контролю?

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

Збирання сміття більше не може запускатися і завершується помилкою з MSG_ERR_DISKFULL повідомлення про помилку.

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

Таке тлумачення не є правильним, однак, користувач зазвичай перевіряє значення використання сервера в інтерфейсі адміністратора Avamar і знаходить значення прийнятним, наприклад 60%.

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


Що спричиняє MSG_ERR_DISKFULL повідомлення?

Найтиповіша причина – занадто висока КПП над головою. Типовими причинами високих КПП можуть бути:
  • Валідація контрольних точок (HFScheck) неодноразово виходила з ладу.
  • HFScheck Збій має багато можливих першопричин (різке скасування, збій програмного забезпечення тощо).
  • Система працює занадто переповнена і має високу щоденну швидкість зміни даних.
  • Системі потрібно більше вузлів даних, щоб обробляти швидкість зміни даних і зберігати дані.
  • Система налаштована на резервне копіювання більшої кількості даних або клієнтів, ніж було потрібно.
  • Зберігається занадто багато контрольних точок (Avamar типово зберігає дві контрольні точки, одна з яких була перевірена).
  • Системний адміністратор створив зайві контрольні точки.
  • Нещодавно було проведено технічне обслуговування, але стандартні КПП не були відновлені.
Перегляньте наступну статтю, щоб допомогти вирішити цю проблему MSR_ERR_DISKFULL situation: Avamar maintenance tasks fail with "MSG_ERR_DISKFULL" due to data partition operating system capacity >89%.


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

  1. Коли закінчилася остання перевірка HFScheck
Для цього скористайтеся або адміністратором Avamar, або командним рядком на вузлі утиліти Avamar. У Avamar Administrator перейдіть на вкладку Server > Checkpoint Management.
Перевірте останню дату й час, зазначені в стовпці «Перевірка контрольної точки». Це мало статися протягом останніх 24 годин.
Або
за допомогою командного рядка Avamar Utility Node запустіть команду cplist.
 
Нижче наведено приклад виведення. Останній валідований пункт пропуску, який тут вказаний, датований 14 січня, 11:14. Ми можемо ідентифікувати його за прапорцем безпосередньо після маркера 'valid'. Залежно від типів перевірок HFS, встановлених у системі, прапорцем може бути rol або hfs. Тут у нас рол (rolling HFScheck).
admin@utilitynode:~/>: cplist
cp.20110114111419 Fri Jan 14 11:14:19 2011   valid rol ---  nodes   3/3 stripes   1131
cp.20110114194457 Fri Jan 14 19:44:57 2011   valid --- ---  nodes   3/3 stripes   1131
 
Якщо результати показують, що остання перевірена контрольна точка старіша за 24 години, з'ясуйте причину. Це може бути пов'язано або з тим, що HFScheck не запустився, або з помилкою.
  1. Перевірте, чи запустився HFScheck, чи він не спрацював.
На вузлі утиліти Avamar запустіть status.dpn і знайдіть рядок, який містить Last hfscheck.

Наприклад:
Last hfscheck: finished Sat Jan 15, 11:07:17 2011 after 06m 41s >> checked 528 of 528 stripes (OK)
Запишіть, коли він закінчився і який був статус (у рядку вище статус відображається як "ОК").
 
Примітка: Скрипт sched.sh також можна використовувати, щоб визначити, коли HFScheck востаннє запускався і чи був він успішним.
 
Завдання HFScheck зазнали невдачі, це слід негайно розслідувати.
 
Якщо HFScheck останнім часом не запускався, перевірте, чи включені завдання обслуговування за допомогою інтерфейсу командного рядка на вузлі утиліти Avamar, введіть статус dpnctl.
admin@utilitynode:~/>: dpnctl status
Identity added: /home/admin/.ssh/dpnid (/home/admin/.ssh/dpnid)
dpnctl: INFO: gsan status: ready
dpnctl: INFO: MCS status: up.
dpnctl: INFO: EMS status: up.
dpnctl: INFO: Backup scheduler status: up.
dpnctl: INFO: dtlt status: up.
dpnctl: INFO: Maintenance windows scheduler status: enabled.
dpnctl: INFO: Maintenance cron jobs status: enabled.
dpnctl: INFO: Unattended startup status: disabled.

Якщо планувальник вікон обслуговування 'disabled', увімкніть його командою dpnctl start maint.

Після того, як HFScheck успішно завершиться і найстаріша контрольна точка буде «знята» з системи, пропускна здатність операційної системи повинна значно зменшитися.

Якщо пропускна здатність операційної системи все ще занадто висока, а збір сміття продовжує збій із повідомленням MSG_ERR_DISKFULL, можливо, знадобиться допомога служби підтримки Dell.

В іншому випадку, якщо пропускна здатність операційної системи досить низька, щоб дозволити збір сміття, то попрацюйте над зниженням «Ємності користувача» і зменшіть показник «використання сервера».

 


Дії, спрямовані на зменшення продуктивності користувачів:

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

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

Як було показано раніше, переконайтеся, що вікно обслуговування ввімкнено, і за допомогою скриптів capacity.sh та sched.sh перевірте, чи запущено збирання сміття, що воно видаляє дані.

До Avamar v7.x резервне копіювання не могло запускатися під час вікна "обмеження" збору сміття.

Функція Hash Referenced Bit Maps, представлена разом з функцією Avamar v7.x, дозволяє створювати резервні копії під час обслуговування збору сміття. Ця функція вимагає, щоб ці «карти» мали принаймні 5 хвилин «тихого» часу на день, протягом якого не запускаються резервні копії, щоб їх можна було скинути.

Доступ до матеріалів про цю функцію можна отримати за посиланням на статтю Avamar: Починаючи з Avamar v7, Garbage Collection повідомляє про "пропущені хеші", які не можуть бути очищені через "Hash Referenced Bit Maps" під час використання даних.

  1. Припиніть додавати нових клієнтів до сітки.

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

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

  1. Дізнайтеся, які клієнти споживають найбільше місця для зберігання.

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

Скрипт capacity.sh (запускається з командного рядка Avamar Utility Node) також може бути використаний для визначення клієнтів, які мають найвищу частоту змін.

Зареєстровані користувачі Dell можуть отримати доступ до контенту за посиланням на статтю Avamar: Як керувати ємністю за допомогою сценарію capacity.sh для більш детальної інформації про те, як використовувати сценарій capacity.sh .

Часто можна побачити, що «найголоднішими» клієнтами є ті, хто створює резервні копії баз даних SQL або поштових серверів, тому зверніть на них особливу увагу.

  1. Переоцініть політику утримання.

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

Примітка: Рекомендовано встановити політику зберігання принаймні на 14 днів.
Якщо система достатньо стара, щоб почати закінчувати термін дії найдовших збережених резервних копій, то після скорочення політик зберігання ми очікуємо побачити збільшення обсягу даних, що видаляються щодня під час збору сміття. Слідкуйте за цією тенденцією за допомогою capacity.sh.

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

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

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

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

Якщо рівень потужності користувача є серйозним (>90%), може знадобитися завершення терміну дії старих резервних копій через інтерфейс керування резервними копіями або за допомогою інструмента змін. 

Користувачі Dell можуть отримати доступ до контенту за посиланням на статтю Avamar Capacity Management: Як масово видаляти або припиняти термін дії резервних копій за допомогою інструменту

"modify-snapups".Видалення резервних копій не відразу знижує рівень використання сервера. Що він робить, так це дозволяє збиранню сміття почати видаляти дані наступного разу, коли збір сміття запуститься. Видалення старих резервних копій є короткостроковим обхідним шляхом. Резервні копії будуть замінені найближчими днями. Якщо резервні копії видаляються, важливо також налаштувати політику збереження.

  1. Слідкуйте за зміною даних за допомогою capacity.sh.

Після того, як резервні копії були видалені, а політики збереження змінилися, уважно стежте за обсягом даних, що змінилися в системі за допомогою сценарію capacity.sh . Ви повинні помітити, що значення «видалених» даних збільшується, а значення «Чиста зміна» має стати від'ємним. Згодом, коли зайві дані видаляються з системи, значення «Видалено» починає повертатися до більш нормального рівня. Продовжуйте стежити за значенням «Видалено».

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

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

  1. Розширення системи Avamar

Часто високе використання системи Avamar пов'язане з природним та очікуваним зростанням даних. Необхідно звільнити більше місця для продовження резервного копіювання.

Як це можна зробити, залежить від типу системи Avamar.

  • Одновузлові системи та системи Avamar Virtual Edition (AVE)

Їх не можна розширювати. Замовте другу, більшу систему Avamar, і попросіть Dell Professional Services виконати міграцію системи з меншої системи в більшу. Професійні послуги можна отримати через менеджера по роботі з клієнтами Dell.

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

  • Багатовузлові системи

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

  • Інтеграція домену даних

Інтеграція системи Data Domain в якості серверного пристрою зберігання даних є корисним способом розширення ємності, доступної для клієнтів, які створюють резервні копії в Avamar. Обговоріть варіанти зі своїм менеджером по роботі з клієнтами Dell.

Additional Information

Корисні інструменти

  • status.dpn
  • capacity.sh
  • Лавина
  • Зведений звіт DPN
  • replcnt.sh
  • Менеджер по роботі з клієнтами Avamar


Практичні поради:

  • Намагайтеся, щоб значення використання сервера Avamar (потужності користувача) перевищувало 80%.
  • Менша місткість користувача забезпечує стійкість до несподіваних змін обсягу доданих даних і може захистити від непридатності системи в разі несподіваних збоїв або короткочасних проблем із завданнями обслуговування.
  • Система Avamar, що працює понад 80% потужності користувача, вимагає більш ретельного контролю з боку системного адміністратора, щоб переконатися, що завдання з обслуговування успішно виконані, а система не стає доступною лише для читання.

Affected Products

Avamar

Products

Avamar
Article Properties
Article Number: 000079977
Article Type: Solution
Last Modified: 07 Jun 2024
Version:  18
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.