Avamar. Емкость операционной системы (ОС) (путь решения)

Как обрабатывать или устранять проблемы, связанные с емкостью ОС в Avamar.

Данная статья о пути решения предназначена для устранения проблем с емкостью ОС в Avamar.


Начальные понятия и понимание емкости ОС см. в учебной статье Avamar. Концепции управления ресурсами и обучение

Как кратко изложено в обучающей статье, для продолжения работы над остальной частью этой статьи потребуется разумное понимание следующих тем:

• Базовое понимание контрольных точек (cp), проверки контрольных точек (hfscheck)и сборка мусора (GC), а также важность каждого
• Разница между GSAN (также называется «Емкость пользователя» и «Емкость ОС»)
• данные об издержках контрольных точек.
• Если какой-либо из разделов данных занимает более 89% от общей емкости физической ОС, сборку мусора запустить не удастся.
• Чем ближе сеть Avamar к 100%-ной пользовательской емкости, тем меньше ресурсов ОС доступно для издержек контрольных точек.
• Факторы, влияющие на накладные расходы контрольных точек, включая асинхронный обработку, количество хранимых контрольных точек, HFSCheck важность проверки контрольных точек и так далее.
• Как найти уровни емкости ОС
• Основные действия для снижения нагрузки на емкость ОС

Часто проще всего рассматривать емкость ОС как размер GSAN data (в частности, пространство, выделенное для этих данных) и служебные данные, создаваемые контрольными точками Avamar. Чем больше количество контрольных точек и чем выше скорость изменений, тем выше издержки контрольных точек.

Высокая емкость ОС может негативно относиться к следующим последствиям:

• Сбой сборки памяти: Сбой GC с MSG_ERR_DISKFULL если емкость ОС превысит 89%
• Сбой резервного копирования или репликации: Резервное копирование или входящая репликация могут завершиться сбоем с MSG_ERR_STRIPECREATE, если емкость ОС превысит 90%. (Это необходимо только в том случае, если необходимо создать новую полосу данных. Если новый страйп не нужен, резервное копирование и репликация все равно могут успешно выполняться.)
• Ошибка контрольной точки: Если емкость ОС превышает 96%, возникает сбой контрольной точки с MSG_ERR_DISKFULL

Как видно из вышесказанного, емкость ОС часто является первым типом емкости Avamar, который необходимо решить, когда другие емкости Avamar также высоки. По крайней мере, сборка мусора не может быть запущена, когда емкость ОС достигает определенных уровней, даже если GSAN Или пользовательская емкость также высока.

Как правило, емкость ОС считается высокой, когда происходит сбой GC с MSG_ERR_DISKFULL если емкость ОС превышает 89%. Если емкость ОС составляет менее 89%, задания обслуживания не затрагиваются. 

Емкость ОС Avamar может увеличиться по любой комбинации следующих причин:

• Высокая скорость изменения данных резервного копирования, добавление «слишком много и слишком быстро»
• Высокий GSAN или «пользовательская емкость», которая оставляет меньше места для емкости ОС и иногда может даже привести к более высокой частоте изменений
• Не удалось успешно завершить контрольную точку, что приводит к состоянию «MSG_ERR_DISKFULL», как показано в выходных данных.
• Проверка контрольной точки (hfscheck) Произошел сбой или не выполнялся в последнее время, поэтому самые старые контрольные точки не могут быть отменены или удалены
• Контрольные точки не сменяются по другим причинам, в том числе из-за слишком высоких настроек хранения контрольных точек

Высокая емкость ОС на других разделах диска может быть вызвана различными причинами, включая неправильное размещение данных, слишком большие файлы журналов и т. д.

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

Если задания обслуживания, включая чистку памяти, завершаются сбоем из-за высокой емкости ОС Avamar, выполните следующие действия.

1. Соберите всю информацию о емкости Avamar, чтобы нарисовать картину ситуации: Avamar. Сбор информации, необходимой для поиска и устранения неисправностей с емкостью.

2. Затем проверьте, насколько высока емкость ОС и какие действия могут потребоваться. Из статьи о сборе данных его можно найти с помощью следующей команды: 

avmaint nodelist | egrep 'nodetag|fs-percent-full'

Принцип работы Avamar заключается в том, что показанное САМОЕ большое значение для fs-percent-full является ограничивающим фактором для текущей емкости ОС. В зависимости от типа узла, поколения и размера может различаться количество разделов данных, в которых хранятся данные резервных копий и контрольных точек. Как видно из операционной системы Linux, это могут быть диски или разделы, например «/data0*», где «*» может означать одну цифру. Количество секций данных зависит от типа узла, поколения оборудования и размера (и не может быть изменено).

3. Просмотрите количество найденных контрольных точек и срок их валидации с помощью команды:

cplist

cp.20290310080041 Mon Mar 10 08:00:41 2025   valid rol ---  nodes   4/4 stripes   5980
cp.20290310080649 Mon Mar 10 08:06:49 2025   valid --- ---  nodes   4/4 stripes   5980

4. Проверьте, не завершаются ли операции контрольных точек сбоем, с помощью команды «MSG_ERR_DISKFULL», выполнив следующую команду:

dumpmaintlogs --types=cp --days=4 | grep "\<430"

Если создание контрольных точек завершено успешно, появятся выходные данные, аналогичные следующим:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> completed checkpoint maintenance
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance

В случае сбоя из-за MSG_ERR_DISKFULL отображается следующий вывод:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance

6. Определите скорость изменений:

capacity.sh  

Пример результата:

  DATE     AVAMAR NEW     #BU    SCANNED       REMOVED     MINS PASS AVAMAR NET      CHG RATE
========== ============= ==== ============= =============  ==== ==== ============= ==========
2020-02-25       1066 mb    8     302746 mb       -641 mb     0   23        425 mb      0.35%
2020-02-26       1708 mb    8     303063 mb       -518 mb     0   23       1189 mb      0.56%
2020-02-27       3592 mb    8     304360 mb       -413 mb     0   23       3178 mb      1.18%
2020-02-28       1086 mb    8     304892 mb       -372 mb     0   23        713 mb      0.36%
2020-03-01       1002 mb    8     305007 mb      -7469 mb     0   25      -6467 mb      0.33%
2020-03-02        585 mb    7     197874 mb          0 mb     0    9        585 mb      0.30%
2020-03-03        348 mb    7     199305 mb          0 mb     0   10        348 mb      0.17%
2020-03-04        775 mb    7     198834 mb         -2 mb     0   10        773 mb      0.39%
2020-03-05        380 mb    4     196394 mb         -5 mb     0   10        375 mb      0.19%
2020-03-06       1068 mb    4     159960 mb          0 mb     0    9       1067 mb      0.67%
2020-03-07        443 mb    4     197132 mb        -18 mb     0   17        424 mb      0.23%
2020-03-08        348 mb    4     197231 mb        -48 mb     0   20        300 mb      0.18%
2020-03-09        370 mb    4     196506 mb          0 mb     0    9        370 mb      0.19%
2020-03-10        349 mb    4     197292 mb        -17 mb     0   20        332 mb      0.18%
2020-03-11        974 mb    2      77159 mb          0 mb     0    0        974 mb      1.26%
=============================================================================================
 14 DAY AVG       940 mb    5     222517 mb       -634 mb     0   15        306 mb      0.42%
 30 DAY AVG      1121 mb    5     195658 mb       -771 mb     0   14        349 mb      0.59%
 60 DAY AVG       994 mb    4     128657 mb      -1165 mb     0   17       -170 mb      0.98%

Top Change Rate Clients.  Total Data Added 14103mb

     NEW DATA % OF TOTAL CHGRATE TYPE CLIENT
============= ========== ======= ====
      6803 mb     48.24   0.91%  AVA /Windows/testing/Hyper-V/hyperv1
      3218 mb     22.82   0.61%  AVA /clients/exchange1
      2932 mb     20.80   0.44%  AVA /BMR/server1
       983 mb      6.97   0.10%  AVA /Windows/testing/SQL/sql1
        97 mb      0.69   1.13%  AVA /REPLICATE/grid2.company.com/MC_BACKUPS

Иногда, если повторяется высокая скорость изменений или ситуация «слишком много и слишком быстро», это можно смягчить, снизив общий GSAN или пользовательской емкости. При более низком GSAN емкости, немного больше места для накладных расходов на емкость ОС, а также приводит к меньшему количеству изменений контейнеров хранения данных. Для получения помощи в этом сценарии откройте сервисную заявку в службе поддержки Dell Technologies Avamar, в противном случае перейдите к шагу 7.

7. Проблемы с большой емкостью ОС на других разделах дисков имеют различные причины, но для решения этих проблем необходима техническая поддержка. Откройте сервисную заявку в службе поддержки Dell Technologies Avamar, в противном случае перейдите к шагу 7.

После определения емкости ОС GSAN емкость или другие емкости Avamar можно просмотреть. См . Поиск и устранение неисправностей, проблемы и вопросы по емкости Avamar — вся емкость (путь решения)