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

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

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

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

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

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

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

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

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

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

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

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

За замовчуванням обсяг простору в розділах даних, що займають контейнери страйпу, становить 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 інтегрований з Data Domain:
На сітках Avamar, інтегрованих з Data Domain, резервні копії, надіслані до Data Domain, записують лише невелику кількість даних до Avamar. Це відомо як метадані. Метадані знаходяться у вигляді складених смуг і займають відносно мало місця в порівнянні з резервними копіями клієнтів, що зберігаються на Avamar.

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

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