Avamar. Концепции и обучение по управлению емкостью

Сведения о проблемах управления емкостью, связанных с устройствами Data Domain, см. в разделе «Освобождение пространства в заполненной системе Data Domain» руководства по интеграции Avamar и системы Data Domain.

Актуальные руководства для вашей операционной среды можно найти здесь: Как найти документацию по Avamar на сайте поддержки Dell.

• Подвести итоги по типам данных, которые хранятся в разделах /data*.
• Введите понятие «емкость операционной системы (ОС)» и сравните его с понятием «емкость пользователя» (иногда называемое «GSAN Вместительность.")
• Объяснить, почему Avamar не следует запускать на пределе емкости пользователя.
• Перечислить факторы, влияющие на издержки контрольной точки.
• Описать отслеживание использования разделов данных.
• Описать признаки, возникающие, если емкость операционной системы выходит из-под контроля.
• Перечислить типичные причины появления сообщения MSG_ERR_DISKFULL .
• Описать методы восстановления, используемые в тех случаях, когда высокая емкость операционной системы влияет на нормальную работу системы.
• Описать признаки, которые возникают, если емкость пользователя превышает предел емкости пользователя.
• Обсудить, как восстановить работу в случае высокой емкости пользователя.

Предполагается, что читатель знаком с разделом «Управление емкостью» в руководстве по передовым практикам работы Avamar.

Руководства, относящиеся к вашей операционной среде, можно найти здесь: Как найти документацию по Avamar на сайте поддержки Dell.

Распространенные проблемы, которые влияют на высокую емкость ОС или являются ее симптомами:

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

• Резервное копирование завершается сбоем.
• Входящие задания репликации завершаются сбоем.
• Интерфейс администратора отображает систему в режиме «администратора» во время резервного копирования

В этой статье представлены основные понятия, связанные с Avamar Capacity Management Concepts and Training.

Как хранятся данные в сети Grid Avamar?

Управление емкостью Avamar относится к данным, расположенным в разделах /data* всех узлов данных Avamar.

• дедуплицированные данные резервного копирования;
• данные четности RAIN;
• данные об издержках контрольных точек.

Данные четности RAIN и данные о контрольной точке — это уровни избыточности, доступные в Avamar в дополнение к RAID и репликации.

Кроме того, для правильного выполнения задач обслуживания, таких как сборка мусора (GC) и асинхронная обработка полос данных, также требуется свободное пространство в разделах данных.

Ниже приведено графическое представление физического пространства для хранения данных, доступного в разделах данных на узлах хранения Avamar.

Как хранятся данные в разделах данных?

На приведенной выше схеме показано простое представление того, как используется пространство в разделах данных.

Значение 100% слева определяется как общий объем физического пространства, доступного операционной системе в разделах данных.

• Маркер 100% User Capacity (ограничение только для чтения) указывает, что для хранения дедуплицированных данных доступно до 65% от общего пространства в разделе данных.
• Пространство ниже этого маркера 100% емкости пользователя эквивалентно значению коэффициента использования сервера, которое отображается в интерфейсе администратора.

Если объем дедуплицированных данных, хранящихся в любом разделе данных на любом узле, достигает 65%, Avamar становится доступен только для чтения и отклоняет дальнейшие данные резервного копирования.

Исходя из вышесказанного, можно понять, что в пользовательском интерфейсе администратора Avamar пользователь видит пространство, занимаемое резервными копиями, но не видит пространство, занимаемое в разделах данных операционной системы.

Почему систему Avamar не следует запускать на пределе «емкости пользователя»?

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

Полное обсуждение того, почему это так, выходит за рамки этой статьи, однако важно помнить: Чемближе система Avamar к 100% пользовательской емкости, тем меньше ресурсов операционной системы доступно для издержек контрольных точек.

В полной системе, согласно приведенной выше схеме, издержки на контрольных точках ограничены 20% от общего объема пространства операционной системы в разделах данных.

• Система должна иметь низкую скорость изменения данных за день (не более 1%).
• Емкость должна находиться в стабильном состоянии (как описано в разделе «Управление емкостью» руководства по передовым практикам эксплуатации Avamar). Актуальные руководства для вашей операционной среды можно найти здесь: Как найти документацию по Avamar на сайте поддержки Dell.
• Задачи обслуживания должны выполняться ежедневно.

Если какое-либо из этих утверждений не выполняется, можно ожидать постепенного увеличения или внезапного скачка издержек контрольной точки, что приведет к серьезным проблемам в работе.

Факторы, влияющие на издержки контрольной точки

• Асинхронное сжатие полос (включено по умолчанию)
• Количество контрольных точек, сохраненных в системе
• Проверка контрольных точек не выполняется ежедневно.
• Насколько пусты полосы при повторном использовании сервером Avamar Server (становится более серьезной проблемой при высоких уровнях использования сервера)
• Скорость изменения ежедневного резервного копирования

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

Отслеживание использования разделов данных

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

avmaint nodelist | grep fs-percent        

Пример выходных данных:

fs-percent-full="7.8"
fs-percent-full="6.3"
fs-percent-full="6.4"
fs-percent-full="6.4"
fs-percent-full="7.6"
fs-percent-full="6.2"
fs-percent-full="6.1"
fs-percent-full="6.6"
fs-percent-full="7.8"
fs-percent-full="6.4"
fs-percent-full="6.5"
fs-percent-full="6.8"

• • Эти выходные данные дают истинное значение коэффициента использования емкости операционной системы.
  • В сети Grid, где узлы данных используют пул файлов, команда Linux df не имеет смысла, так как полосы предварительно выделены в пуле файлов, и многие из них могут не использоваться.

Что произойдет, если использование емкости операционной системы выйдет из-под контроля?

С точки зрения пользователя, первый признак того, что использование разделов данных вышло из-под контроля, возникает, когда оно превышает 89%.

Сборка мусора больше не запускается и завершается сбоем с ошибкой MSG_ERR_DISKFULL .

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

Эта интерпретация неверна, однако пользователь обычно проверяет значение использования сервера в пользовательском интерфейсе администратора Avamar и находит его приемлемым, например 60%.

Пользователь может попытаться удалить резервные копии из интерфейса управления резервным копированием пользовательского интерфейса Avamar. Даже если бы уровень пользовательской емкости был высоким, удаление резервных копий не улучшило бы ситуацию, поскольку сборка мусора не может запуститься и удалить просроченные блоки данных из системы.

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

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

Почему появляется сообщение MSG_ERR_DISKFULL?

• Проверка контрольных точек (hfscheck) неоднократно завершался сбоем.
• В hfscheck Сбой имеет множество возможных основных причин (внезапная отмена, сбой программного обеспечения и т. д.).
• В системе недостаточно места, и она имеет высокую скорость ежедневного изменения данных.
• Системе требуется больше узлов данных для обработки скорости изменения данных и хранения данных.
• Система настроена на резервное копирование большего количества данных или клиентов, чем предусмотрено.
• Хранится слишком много контрольных точек (по умолчанию Avamar хранит две контрольные точки, одна из которых проверена).
• Системный администратор создал лишние контрольные точки.
• Обслуживание было проведено недавно, но хранение контрольных точек по умолчанию не было восстановлено.

Для устранения этой проблемы см. следующую статью MSG_ERR_DISKFULL Сценарий: Avamar. Задачи обслуживания завершаются сбоем с MSG_ERR_DISKFULL из-за того, что емкость одного или нескольких разделов данных операционной системы превышает 89%

Действия по исследованию и устранению высокой емкости операционной системы:

1. Определите, когда последний hfscheck Закончил. Для этого используйте либо интерфейс Avamar Administrator, либо командную строку в Avamar Utility Node.

• В пользовательском интерфейсе Java Administrator Avamar:
  • Перейдите на > вкладку «Server Checkpoint Management»
  • Проверьте последние дату и время, указанные в столбце Checkpoint Validation. Это должно произойти в течение последних 24 часов.

-- или --

• С помощью командной строки Avamar Utility Node:
  • Выполните команду: cplist.

admin@utilitynode:~/>: cplist

cp.20110114111419 Fri Jan 14 11:14:19 2011   valid rol ---  nodes   3/3 stripes   1131
cp.20110114194457 Fri Jan 14 19:44:57 2011   valid --- ---  nodes   3/3 stripes   1131

• • • • Самая последняя проверенная контрольная точка, указанная здесь, датирована 14 января 11:14.
      • Он идентифицируется флагом сразу после маркера 'valid'.
      • В зависимости от типов проверок контрольных точек, заданных в системе, флаг может быть rol или hfs.
      • Это пример rol (перекатывающийся) hfscheck.

Если результаты показывают, что последняя проверка контрольной точки завершилась раньше 24 часов, выясните причину. Это может быть связано с тем, что HFScheck не запустился или произошел сбой.

2. Убедитесь, что HFScheck В случае сбоя:

На узле Avamar Utility Node запустите команду status.dpn и найдите строку, которая начинается с "Last hfscheck».

Например:

Last hfscheck: finished Sat Jan 15, 11:07:17 2011 after 06m 41s >> checked 528 of 528 stripes (OK)

Запишите, когда она была завершена и какое было состояние (в строке выше отображается состояние «OK»).

Если hfscheck Задания не выполняются, это должно быть немедленно расследовано.

Если hfscheck не выполнялся в последнее время, убедитесь, что планировщик обслуживания включен, выполнив команду «dpnctl status maint» в узле Avamar Utility Node: .

admin@utilitynode:~/>: dpnctl status maint

Identity added: /home/admin/.ssh/dpnid (/home/admin/.ssh/admin_key)
dpnctl: INFO: Maintenance windows scheduler status: enabled.

• Если планировщик окон обслуживания не работает, отключен или приостановлен, включите его с помощью команды: dpnctl start maint
• При необходимости возьмите новую контрольную точку и запустите hfscheckили дождитесь завершения следующего запланированного окна обслуживания.

После того, как hfscheck Если операция завершится успешно (после устранения проблем или перезапуска планировщика обслуживания), самая старая контрольная точка будет «откатываться», а емкость операционной системы должна значительно уменьшиться.

• Если емкость операционной системы по-прежнему слишком велика, а сборка мусора продолжает завершаться сбоем с помощью команды MSG_ERR_DISKFULL , а затем обратитесь за помощью в службу технической поддержки Dell.
• В противном случае, если емкость операционной системы достаточно низкая для выполнения чистки памяти, то необходимо снизить «емкость пользователя» и уменьшить значение коэффициента «использования сервера».

Действия по уменьшению высокой емкости пользователя

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

1. Обеспечьте ежедневную чистку памяти и убедитесь, что она не прерывается резервным копированием.

Это самый важный момент, так как даже в системе адекватного размера быстро возникает высокая пользовательская емкость, если сборка мусора не выполняется регулярно или ненадежно.

Как показано ранее, убедитесь, что окно обслуживания включено, и используйте capacity.sh и sched.sh Сценарии для проверки того, что сборка мусора выполняется и удаляет данные.

До Avamar v7.x резервное копирование не могло выполняться во время окна «ограничения» сборки мусора.

Функция Hash Referenced Bit Maps, появившаяся в Avamar v7.x, позволяет выполнять резервное копирование во время обслуживания GC. Эта функция требует, чтобы эти «карты» имели не менее 5 минут «тихого» времени в день, в течение которых не запускаются резервные копии, чтобы их можно было сбросить.

Сведения об этой функции можно получить по ссылке на статью Avamar: Начиная с Avamar v7, чистка памяти сообщает о «skipped-hashes», которые невозможно очистить из-за «Hash Referenced Bit Maps», когда данные используются.

2. Остановите добавление новых клиентов в сеть Grid.

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

Если есть другая сеть Avamar, которая работает на более низком уровне использования сервера, рассмотрите возможность добавления новых клиентов в эту сеть вместо сервера, который заполняется.

3. Узнайте, какие клиенты занимают больше всего пространства в хранилище.

Для решения проблемы с емкостью определите, какие клиенты отвечают за добавление наибольшего объема данных в систему Avamar.

Переменная capacity.sh Сценарий (запускаемый из командной строки Avamar Utility Node) также можно использовать для определения клиентов с самой высокой частотой изменений.

См. Avamar. Управление емкостью с помощью capacity.sh скрипт для получения дополнительной информации о том, как использовать capacity.sh Сценарий.

Часто оказывается, что самые ресурсоемкие клиенты — это те, которые выполняют резервное копирование баз данных SQL или серверов электронной почты, поэтому на них следует обратить особое внимание.

4. Произведите повторную оценку политик хранения.

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

Если система достаточно старая для того, чтобы начать истекать срок действия самых длительных резервных копий, то после уменьшения политик хранения следует ожидать увеличения объема данных, удаляемых каждый день сборщиком мусора. Отслеживайте эту тенденцию с помощью capacity.sh.

Если система Avamar еще не устарела и у резервных копий не начал истекать срок хранения, может потребоваться изменение политик хранения, чтобы началось истечение срока хранения старых резервных копий.

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

5. Перенесите клиентов в альтернативную систему Avamar.

Если доступна другая система Avamar, рассмотрите возможность переноса крупных клиентов или клиентов с высокой скоростью изменения с более используемых на менее используемые системы с помощью интерфейса Avamar Client Manager.

6. Удалите старые резервные копии.

Если уровень пользовательской емкости высокий (>90%), может потребоваться истечение срока действия старых резервных копий через интерфейс управления резервным копированием или при необходимости modify-snapups . 

Пользователи Dell могут получить доступ к содержимому, перейдя по ссылке на статью Avamar: Управление емкостью — Как массово удалить или завершить срок действия резервных копий с помощью кнопки «modify-snapups" инструмент

Удаление резервных копий не приводит к немедленному снижению коэффициента использования сервера. Но оно позволит чистке памяти начать удаление данных при следующем выполнении чистки памяти. Удаление старых резервных копий — это временное решение проблемы. Резервные копии будут заменены в ближайшие дни. При удалении резервных копий необходимо также настроить политики хранения.

7. Отслеживайте изменение данных с помощью capacity.sh.

После удаления резервных копий и изменения политик хранения внимательно отслеживайте объем измененных данных в системе с помощью команды capacity.sh Сценарий. Значение «удаленных» данных должно увеличиться, а значение «Чистое изменение» должно стать отрицательным. В конечном итоге по мере удаления избыточных данных из системы значение «Removed» возвращается к нормальному уровню. Продолжайте следить за значением «Removed».

Если чистое значение изменения не стало отрицательным, проверьте журнал сборки мусора, чтобы узнать, как долго выполняется сборка мусора и какой объем работы она выполняет в течение окна обслуживания.

См . Avamar. Управление емкостью с помощью capacity.sh script для получения дополнительной информации о том, как использовать capacity.sh Сценарий.

8. Расширьте систему Avamar.

Высокая загрузка сети Avamar часто обусловлена естественным и ожидаемым ростом объема данных. Для продолжения производственного резервного копирования необходимо освободить больше места.

• Сетки для одного узла и Avamar Virtual Edition (AVE)

  • Их невозможно расширить. Закажите вторую, более объемную систему Avamar и отправьте запрос в Dell Professional Services для выполнения переноса с меньшей системы на более крупную.
    • Профессиональные услуги можно получить через ведущего специалиста Dell.
  • Новая система может быть одноузловой, AVE или многоузловой системой, если она предоставляет больше пространства для хранения, чем исходная.
• Сетки с несколькими узлами:

  • Эти системы могут быть расширены до 16 узлов данных.
    • Для получения дополнительных сведений обратитесь к менеджеру по работе с клиентами Dell (обычные каналы поддержки не добавляют узлы, поэтому не следует открывать сервисную заявку для запроса этой работы).
• Интегрируйте Data Domain.
  • Интеграция системы Data Domain в качестве внутреннего устройства хранения данных — полезный способ расширения емкости, доступной для клиентов, выполняющих резервное копирование в Avamar.
    • Обсудите варианты с менеджером по работе с заказчиками Dell.

Полезные инструменты

• status.dpn
• capacity.sh
• Avalanche
• DPN Summary Report
• replcnt.sh
• Avamar Client Manager

• Постарайтесь предотвратить увеличение значения коэффициента использования сервера Avamar (емкости пользователя) выше 80%.
• Низкая емкость пользователя обеспечивает отказоустойчивость при неожиданных изменениях объема добавляемых данных и может защитить систему от выхода из строя в случае непредвиденных сбоев или кратковременных проблем с задачами обслуживания.
• Система Avamar, в которой емкость пользователя превышает 80%, требует более тщательного наблюдения со стороны системного администратора, чтобы обеспечить выполнение задач обслуживания и не допустить, чтобы система стала доступна только для чтения.