Avamar: Різниця між «Використанням серверів» і фізичним споживанням простору на вузлах даних

Обсяг простору, зайнятого у фізичних розділах даних вузла зберігання Avamar, є високим, тоді як показник «використання сервера» відносно низький.

Приклад:
Сервер Avamar повідомляє, що займає 9,2% доступного місця для резервних даних:

Розділи даних Avamar показують більший обсяг простору:

Причина цього полягає в тому, що значення Avamar 'Server utilization' не розраховується відповідно до обсягу простору, зайнятого у фізичних розділах.

Фізичне "/data" розділи містять смуги, які по суті є контейнерами для резервного копіювання даних.

Значення використання сервера Avamar (також відоме як споживацька ємність, або «GSAN» ємність) вимірюється відповідно до того, наскільки заповнені ці смужкові контейнери.

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

Це залишається правдою навіть якщо велика кількість резервних даних видаляється і значення «використання сервера» падає.

Це навмисна і нормальна поведінка.

Додаткова інформація:
На новоствореній сітці Авамар, /data Розділи містять лише кілька смуг (контейнери даних). І «Використання сервера», і простір, зайнятий у /data Розділи повідомляють про низькі значення.

З часом, коли смуги заповнюються резервними даними, нові смуги створюються в /data розділи. Використання простору /data Перегородки піднімаються. Це триває, доки сітка не досягне заздалегідь визначених «безпечних» меж, встановлених сервером Avamar і MCS.

За замовчуванням площа місця в розділах даних, яку займають stripe-контейнери, становить 65%. Іноді значення може змінюватися, наприклад, коли сітка:

• Застосовується індивідуальні обмеження через ліцензійні обмеження (ліміти нижчі)
• Налаштований із шифруванням у стані спокою (ліміти нижчі)
• Було налаштовано з налаштованими обмеженнями місткості метаданих (ліміти трохи вищі)

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

Нижче наведено графіку, що це ілюструє:

100%   "---------------------" <-- 100% /data partition capacity
       " Reserved for        "
       " maintenance         "
       " activity overhead   "
       "                     "
       "                     "
65%    "---------------------" <-- 100% Server Utilization value
       " Commonality         "     (visible in the Admin GUI)
       " factored data       "     
       " & RAIN parity       "     
       " data                "     
       "                     "
       "                     "
       "                     "
       "                     "
0%     "---------------------"

Поведінка ОС та серверів Avamar детальніше розглядається у наступній статті: Avamar: Концепції управління ємністю та навчання

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

У певних сценаріях, коли параметри метаданих були «налаштовані» технічною підтримкою, відсоток простору, зайнятого 'cur' на сітці Avamar, може перевищувати 65%.

Інші моменти, на які варто звернути увагу:
RAIN/Дані паритету:
Наступна стаття пояснює, чому використання сервера завжди включатиме використання простору смужок паритету навіть після видалення всіх резервних копій: Avamar показує завантаження до ~30% навіть після видалення всіх резервних копій і збору сміття