Авамар: Пара, що реплікується, показує різні рівні використання потужності. Як з'ясувати причини.

Причини та можливі причини відмінностей між значеннями "використання сервера":

Логічні або фізичні відмінності між сітками:

• Різна кількість вузлів даних на вихідній та цільовій сітках.
• Вузли даних кожної сітки мають різну конфігурацію дисків.
• Адекватно збалансований розподіл страйпів між вузлами даних у кожній системі (з точністю до 2%)
• Вимоги до пам'яті та паритету відрізняються в різних версіях Avamar. Різниця у використанні може спостерігатися, якщо вихідна та цільова версії програмного забезпечення відрізняються.
• Рівень диска сервера Avamar може відрізнятися між двома сітками.   
• Одна сітка може бути налаштована на парність RAIN, а інша — ні.

Конфігурація реплікації:

• Резервні копії, скопійовані в цільову систему, можуть мати іншу політику збереження порівняно з вихідним кодом. Перегляньте прапорець expiredelta для отримання додаткової інформації. Крім того, репліковані резервні копії можуть охоплювати лише певний проміжок часу. Наприклад, останні 4 тижні резервних копій із джерела.
• Реплікація може бути налаштована на реплікацію лише підмножини клієнтів із вихідної системи до цільової системи. Перевірте, чи використовуються налаштування "включити" або "виключити".
• Клієнти та пов'язані з ними резервні копії могли бути видалені з вихідної системи. Видалення клієнта або резервних копій у джерелі не призводить до видалення тих самих резервних копій із цільової системи. Резервні копії залишаються на цільовому рівні, доки не закінчиться термін їх дії відповідно до налаштувань зберігання.
• Політики збереження можуть бути змінені для резервних копій або клієнтів у вихідній системі. Зміна політики збереження стосується лише нових резервних копій. Нові резервні копії реплікуються до цільового та відповідають оновленій політиці збереження. Резервні копії, які вже існують на об'єкті, зберігають політику збереження, яка застосовувалася до них під час їх реплікації.

Попередня діяльність з управління потенціалом:

• Нерідко клієнти помічають, що одна з парних систем реплікації Avamar наближається до потужності, а потім діють, щоб зменшити ємність. Пам'ятайте - пара реплікації Avamar складається з двох незалежно керованих систем. Якщо дії здійснюються на одній системі, вони повинні здійснюватися і на іншій. 
• Якщо резервні копії видаляються або зменшуються залишки у вихідній системі, необхідно внести ідентичні зміни до цільової системи. Найкращим способом керування потужностями у такий спосіб є скрипт modify-snapups. Це може бути запущено на обох серверах Avamar з однаковими параметрами модифікації або видалення резервних копій.  

Різна структура страйпів (наприклад, більше парних смуг на одній системі):

• Будучи незалежними, дві системи Avamar можуть мати різну структуру смуг. Багатовузлові системи можуть демонструвати відмінності через використання смуг парності для захисту даних. Залежно від історії пропускної здатності, дві багатовузлові системи містять однакові резервні копії, але одна може мати більшу кількість смуг парності, ніж інша.
• Як і звичайні смуги, після створення смуга парності завжди залишається в системі. На відміну від звичайних смуг, він завжди займає фіксовану кількість місця на сервері Avamar. Це так, навіть якщо безпечні смуги групи парності не містять даних. Збір сміття ніяк не впливає на таку поведінку.
• Цільова система реплікації опосередковано захищена від серйозних проблем з ємністю джерела реплікації. Однак ситуація може виникнути на будь-якій машині, якщо одна з них погано управляється з точки зору потужності.
• Стаття по темі: Avamar показує до ~30% використання навіть після того, як усі резервні копії були видалені, а сміття зібрано

Резервні копії, які все ще знаходяться в MC_DELETED:

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

Дані про цільову систему з нереплікованих резервних копій:

• Якщо система реплікується лише в одному напрямку*, перевірте на цілі, чи немає клієнтів поза /REPLICATE та MC_SYSTEM.

Інша поведінка:

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

Зрозумійте середовище реплікації:

• Зверніть увагу на повне ім'я хоста вихідної сітки Avamar.
• Вивчіть конфігурацію реплікації уражених систем, щоб зрозуміти, які системи які дані реплікують і куди. 
  • Може допомогти намалювати схему середовища, якщо це щось складніше, ніж реплікація з одного сервера Avamar на інший.
• Якщо джерело інтегрується з Data Domain (DD), дізнайтеся, чи стосується клієнта резервне копіювання, відтворене між пристроями DD.
• Запишіть повне ім'я хоста цільової сітки Avamar і будь-яких пов'язаних пристроїв DD, які отримують репліковані резервні копії.

Перевірте загальний стан і стан мережі:

• Запустіть скрипт проактивної перевірки на обох сітках і отримайте копію hc_results.txt та перегляду, щоб зрозуміти загальну ситуацію з системою. 

Наскільки серйозним є перепад потужностей?

• Клієнт повинен надати скріншот, на якому показано, на що він дивиться, що змушує його повірити, що існує різниця в споживанні потужності між джерелом і цільовим показником.
• Ми б не вважали приводом для тривоги, якщо різниця в ємності менше 5%.
• Перевірте інтерфейс адміністратора Avamar, щоб зрозуміти рівні потужності сервера Avamar і (якщо інтегровано домен даних) ємність метаданих.
• Зверніть увагу на те, як працює відображення ємності інтерфейсу користувача (обговорено на інформаційній панелі Avamar UI у версії 7.2 і пізніших показує використання метаданих замість використання Avamar).
• Виконайте наступну команду в обох системах. Значення використання сервера дає загальне значення рівнів пропускної спроможності сервера Avamar (але не домену даних):

admin@utility:~/>: mccli server show-prop | grep "utilization"

Server utilization               3.7%

Перевірте, чи однакове обладнання на обох сітках:

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

admin@utility:~/>: mccli server show-prop | grep "Capacity\|capacity\|nodes"

Total capacity                   23.3 TB
Capacity used                    858.5 GB
Number of nodes                  3

• Цей вихід дозволяє легко визначити кількість і розмір вузлів в системі. Вони становлять (23,3 / 3 = ~ 7,8 ТБ). 
• Кількість і розмір розділів жорсткого диска на кожному вузлі повинні це підтверджувати.

admin@utility:~/>: mapall 'df -h' | grep data

(0.0) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.2 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   54G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   53G  1.8T   3% /data04
/dev/sde1       1.9T   52G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
(0.1) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.3 'df -h'
/dev/sda3       1.8T   56G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   52G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   53G  1.8T   3% /data06
(0.2) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.4 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06

• Маючи цю інформацію, перевірте наступне:

Перевірте версію та конфігурацію програмного забезпечення:

• Використовуючи вихідні дані команди status.dpn, порівняйте версію Avamar, запущену в кожній системі.
• Для багатовузлових систем переконайтеся, що обидві налаштовані з парністю RAIN за Avamar - Як визначити, чи є сервер RAIN чи Non-RAIN
• Перевірте та порівняйте параметри конфігурації сервера Avamar, пов'язані з продуктивністю двох систем. Наприклад:

admin@utility:~/>: avmaint config --ava | grep -i "capacity\|disk"

  disknocreate="90"
  disknocp="96"
  disknogc="85"
  disknoflush="94"
  diskwarning="50"
  diskreadonly="65"
  disknormaldelta="2"
  freespaceunbalancedisk0="20"
  diskfull="30"
  diskfulldelta="5"
  balancelocaldisks="false"

Перевірте балансування смуги:

• Перевірте вихідні дані status.dpn і запишіть загальну кількість страйпів на кожному вузлі даних. Кількість смуг позначається в дужках (наприклад, onl:xxx). 
• Різниця між загальною кількістю страйпів на кожному вузлі даних має бути меншою за 2%.

Перевірте, чи правильно працює збір сміття в обох системах:

• Якщо збір сміття не працює послідовно та ефективно, він не видалить прострочені дані. Система повідомляє про більш високе використання потужності, ніж очікувалося. 
  • Перегляньте статтю GC Resolution Path у примітках з обмеженим доступом для отримання інформації.

Переконайтеся, що реплікація успішно завершена:

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

Перевірте конфігурацію реплікації:

• Перевірте конфігурацію реплікації (в інтерфейсі користувача, командному рядку або журналах) на наявність будь-якого з наступних прапорців:

--before
--after
--include
--exclude

--expiredelta

--retention-types

--retention-types=none,daily,weekly,monthly,yearly

Перевірте швидкість прийому та видалення даних в обох системах:

• Запустіть proactive_check.pl --capacity на обох системах і порівняйте швидкість поглинання як вихідної, так і цільової систем.
• Якщо ціль є суто цільовою системою і отримує ВСІ резервні копії з джерела, швидкість її прийому повинна точно відповідати швидкості прийому джерела.
• Стовпці Avamar NEW або DDR NEW показують, скільки нових даних додається до цих систем.
• Також зверніть пильну увагу на стовпчики «видалено», «хв» і «пройти», щоб зрозуміти поведінку збирання сміття в обох системах.
• Ця інформація дає чітке уявлення про те, що відбувається в обох системах.
• Щоб дізнатися більше про інтерпретацію виведених даних, перегляньте Avamar: Як керувати ємністю за допомогою capacity.sh скрипта

Скиньте список резервних копій, наявних у кожній системі:

• Скрипт dump_root_hashes.rb — це утиліта, яка допомагає порівняти різницю в резервних копіях, що зберігаються між джерелом Avamar і цільовою системою. Це навіть якщо резервні копії розміщені на сховищі Data Domain.   
• Дивіться Avamar: Авамар: Як використовувати скрипт dump_root_hashes.rb для створення списку клієнтів і резервних копій для отримання інформації про завантаження утиліти і варіантів використання, включаючи порівняння вмісту двох систем Avamar.
  • Запустіть інструмент. Перевірте, чи немає невідповідностей у підрахунках резервних копій на всіх клієнтах. Зверніть увагу на різницю +/-2).  
• Як обговорювалося в розділі «Причини», асиметричне управління потужностями призводить до відмінностей між двома системами. Перегляньте вихідні дані, щоб визначити, чи може це бути сценарієм.
• Також:
  • Перевірте ціль на наявність даних про цільову систему з нереплікованих резервних копій.
  • Перевірте джерело на наявність даних, які не були репліковані для цілі.

Перевірте, чи немає різних структур страйпів (наприклад, більше смуг парності в одній системі):

• Будучи незалежними, дві системи Avamar можуть мати різну структуру смуг. Багатовузлові системи можуть демонструвати відмінності через використання смуг парності для захисту даних. Залежно від історії пропускної здатності, дві багатовузлові системи містять однакові резервні копії, але одна може мати більшу кількість смуг парності, ніж інша.  
• Як і звичайні смуги, після створення смуга парності залишається в системі. На відміну від звичайних страйпів, вони завжди займають фіксовану кількість місця в Avamar, навіть якщо їх безпечні смуги групи парності не містять даних. Збір сміття ніяк не впливає на таку поведінку.
• Цільова система реплікації опосередковано захищена від серйозних проблем з ємністю джерела реплікації. Однак ситуація може виникнути на будь-якій машині, якщо одна з них погано управляється з точки зору потужності.
• Стаття по темі:  Avamar показує до ~30% використання навіть після того, як усі резервні копії були видалені, а сміття зібрано

Резервні копії, які все ще знаходяться в MC_DELETED:

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