Avamar. В паре репликации наблюдаются разные уровни использования емкости. Порядок выявления причин.

Поводы и вероятные причины различий между значениями «использования сервера»:

Различия логического или физического характера между сетями:

• Разное количество узлов данных в исходной и целевой сетях.
• Разные конфигурации дисков в узлах данных каждой сети.
• Достаточно сбалансированное распределение полос между узлами данных в каждой системе (с точностью до 2%).
• Требования к хранилищу и четности в разных версиях Avamar различаются. Значение уровня использования может различаться, если отличаются версии программного обеспечения исходной и целевой системы.
• Уровень диска только для чтения в Avamar Server в двух сетях может отличаться.   
• Одна сеть может быть настроена для четности RAIN, а другая — нет.

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

• Резервные копии, реплицированные в целевую систему, могут иметь иную политику хранения, по сравнению с исходной системой. Для получения дополнительной информации детально рассмотрите флаг expiredelta. Или реплицированные резервные копии могут быть настроены только на определенный временной диапазон. Например, на последние 4 недели резервного копирования из источника.
• Репликацию можно настроить таким образом, чтобы реплицировать только подмножество клиентов из исходной системы в целевую систему. Проверьте, используются ли настройки включения или исключения.
• Клиенты и связанные с ними резервные копии могли быть удалены из исходной системы. Удаление клиента или резервных копий в исходной системе не приводит к удалению этих же резервных копий из целевой системы. Резервные копии остаются в целевой системе до истечения срока, заданного в настройках хранения.
• Политики хранения резервных копий или клиентов можно изменить в исходной системе. Изменение политик хранения влияет только на новые резервные копии. Новые резервные копии реплицируются на целевую систему, при этом на них распространяется обновленная политика хранения. На резервные копии, уже существующие в целевой системе, продолжает распространяться политика хранения, примененная к ним во время репликации.

Предыдущая операция по управлению емкостью.

• У заказчиков нередко складывается ситуация, когда одна из систем пары репликации Avamar приближается к пределу емкости, в связи с чем они предпринимают действия по сокращению используемой емкости. Следует учитывать, что пара репликации Avamar состоит из двух независимо управляемых систем. Если какие-либо действия выполняются на одной системе, то аналогичные действия должны выполняться и на другой. 
• При удалении резервных копий или сокращении времени их хранения в исходной системе также необходимо внести аналогичные изменения и в целевой системе. Оптимальный способ такого управления емкостью — сценарий modify-snapups. Его можно запустить на обоих серверах Avamar Server с одинаковыми параметрами изменения или удаления резервных копий.  

Отличающаяся структура полос (например, в одной системе больше полос четности).

• Будучи независимыми, две системы Avamar могут иметь разную структуру полос данных. В многоузловых системах могут наблюдаться различия из-за того, что в них используются полосы четности для защиты данных. В зависимости от истории использования емкости две многоузловые системы могут содержать одинаковые резервные копии, но в одной из них может присутствовать большее количество полос четности, чем в другой.
• Как и в случае с обычными полосами, после создания в системе всегда остается полоса четности. При этом в отличие от обычных полос, она всегда занимает фиксированный объем пространства на Avamar Server. Это происходит, даже если полосы безопасности группы четности не содержат данных. Чистка памяти не влияет на это поведение.
• Целевая система репликации косвенно защищена от серьезных проблем с емкостью в исходной системе репликации. Однако такая ситуация может возникнуть на любой из машин, если на одной из них не осуществляется должное управление емкостью.
• Похожая статья: Avamar выводит коэффициент использования примерно до 30% даже после удаления всех резервных копий и очистки памяти

Резервные копии по-прежнему находятся в MC_DELETED.

• Один из редких сценариев, о котором следует помнить, — это когда клиент удален в исходной системе, но его резервные копии сохраняются. Это может привести к тому, что коэффициент использования исходной системы будет выше, чем использование целевой системы, в которой ожидается естественное истечение срока хранения резервных копий. Такое поведение можно проверить с помощью сценария dump_root_hres.rb с параметром backupcompare.

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

• Если система выполняет репликацию *только в одном направлении*, проверьте целевую систему на отсутствие клиентов за пределами /REPLICATE и MC_SYSTEM.

Другие модели поведения:

• Задачи репликации могут завершаться ненадежно. Данные, отправляемые в целевую систему, могут «отставать» от исходной системы на несколько дней.
• Обе системы содержат одинаковый объем дедуплицированных данных, но объем издержек четности для каждой из них различается. Это происходит при следующем сценарии. 
  • Исходная система Avamar почти заполнена. 
  • Многие резервные копии удаляются из исходной системы для снижения ее уровня емкости. 
  • Затем репликация дедуплицированных данных выполняется из исходной системы в целевую. 
  • Объем дедуплицированных данных в обеих системах одинаковый.
  • Исходная система изначально хранит больший объем издержек на реализацию четности, чем целевая система.
• При репликации физические полосы из исходной в целевую сеть Grid не копируются. Вместо этого целевая сеть может самостоятельно определять, где хранятся остатки и фрагменты данных.
• Иногда целевые системы Avamar могут хранить данные более эффективно, чем исходная сеть, в которой изначально выполняется резервное копирование данных.

Изучите среду репликации.

• Запишите полное имя хоста исходной сети Avamar.
• Изучите конфигурацию репликации в затронутых системах, чтобы понять, какие системы и куда реплицируют данные. 
  • Если среда является чем-то более сложным, чем репликация с одного сервера Avamar Server на другой, может быть полезным нарисовать схему среды.
• Если исходная система интегрируется с Data Domain (DD), узнайте, связана ли проблема заказчика с резервным копированием, реплицируемым между устройствами DD.
• Запишите полное имя хоста целевой сети Avamar и всех связанных с ней устройств DD, которые получают реплицированные резервные копии.

Проверьте общее состояние и функциональность сети.

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

Насколько серьезна разница в емкости?

• Заказчик должен предоставить снимок экрана, на котором будет видно, какие именно данные, отображаемые на экране, позволяют предположить наличие разницы в использовании емкости между исходной и целевой системами.
• Если разница в емкости составляет менее 5%, то повода для беспокойства нет.
• Проверьте пользовательский интерфейс Avamar Administrator, чтобы понять уровни емкости сервера Avamar и (если система Data Domain интегрирована) емкости метаданных.
• Не забывайте, как работает отображение емкости пользовательского интерфейса (обсуждается в разделе На панели управления пользовательским интерфейсом Avamar в версии 7.2 и более поздних вместо использования Avamar отображается использование метаданных).
• Выполните следующую команду в обеих системах. Значение использования сервера показывает общее значение уровней емкости сервера Avamar (но не Data Domain).

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
• Проверьте и сравните параметры конфигурации сервера 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» в примечаниях с ограниченным доступом.  

Убедитесь, что репликации выполняются успешно.

• Убедитесь, что все задачи репликации из исходной системы в целевую систему выполнены успешно. Если это не так, возможно, еще есть данные, которые нужно реплицировать из исходной системы в целевую.  

Проверьте конфигурацию репликации.

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

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

--expiredelta

--retention-types

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

Проверьте коэффициент получения, внесения и обработки данных и удаления данных в обеих системах.

• Выполните файл proactive_check.pl с параметром --capacity в обеих системах и сравните коэффициенты получения, внесения и обработки данных в исходной и целевой системах.
• Если целевая система является исключительно целевой системой и получает ВСЕ резервные копии из исходной системы, ее коэффициент получения, внесения и обработки данных должен точно соответствовать аналогичному коэффициенту исходной системы.
• Столбцы NEW или DDR NEW в Avamar показывают, сколько новых данных добавляется в эти системы.
• Также обратите пристальное внимание на столбцы «removed», «min» и «pass», чтобы понять методику чистки памяти в обеих системах.
• Эта информация дает четкое представление о том, что происходит в обеих системах.
• Дополнительные сведения об интерпретации выходных данных см. в разделеAvamar. Как управлять емкостью с помощью сценария capacity.sh  

Создайте дамп списка резервных копий, существующих в каждой системе.

• Сценарий dump_root_hashes.rb — это утилита, которая помогает сравнить различия между резервными копиями, сохраняемыми в исходной и целевой системах Avamar. Этот процесс выполняется даже в том случае, если резервные копии размещаются в хранилище Data Domain.   
• См. Avamar. Avamar. Как использовать сценарий dump_root_hashes.rb для создания списка клиентов и резервных копий для получения информации о скачивании утилиты и сценариях использования, включая сравнение контента двух систем Avamar.
  • Запустите инструмент. Проверьте наличие несоответствий в количестве резервных копий на всех клиентах. Обратите особое внимание на расхождения в +/-2.  
• Как обсуждалось в разделе «Причины», асимметричное управление емкостью приводит к различиям между двумя системами. Просмотрите результаты проверки, чтобы определить, возможен ли такой сценарий.
• Дополнительные действия.
  • Проверьте наличие в целевой системе данных из нереплицированных резервных копий.
  • Проверьте наличие в исходной системе данных, которые не были реплицированы в целевую систему.  

Проверьте различия в структуре полос (например, больше полос четности в одной системе).

• Будучи независимыми, две системы Avamar могут иметь различные структуры полос. В многоузловых системах могут наблюдаться различия из-за того, что в них используются полосы четности для защиты данных. В зависимости от истории использования емкости две многоузловые системы могут содержать одинаковые резервные копии, но в одной из них может присутствовать большее количество полос четности, чем в другой.  
• Как и в случае с обычными полосами, после создания полосы четности сохраняются в системе. В отличие от обычных полос, они всегда занимают фиксированный объем памяти в системе Avamar, даже если их полосы безопасности в группе четности не содержат данных. Чистка памяти не влияет на это поведение.
• Целевая система репликации косвенно защищена от серьезных проблем с емкостью в исходной системе репликации. Однако такая ситуация может возникнуть на любой из машин, если на одной из них не осуществляется должное управление емкостью.
• Похожая статья:  Avamar выводит коэффициент использования примерно до 30% даже после удаления всех резервных копий и очистки памяти  

Резервные копии по-прежнему находятся в MC_DELETED.

• Один из редких сценариев, о котором следует помнить, — это когда клиент удален в исходной системе, но его резервные копии сохраняются. Это приведет к тому, что коэффициент использования исходной системы будет выше, чем использование целевой системы, в которой ожидается естественное истечение срока хранения резервных копий. Такое поведение можно проверить с помощью сценария dump_root_hres.rb с параметром backupcompare.