Процессы освобождения пространства Avamar — Часть 1. Сбор мусора

Эта статья является первой в серии, в которой описано, как Avamar повторно перерабатывает пространство как в GSAN, так и на жестких дисках.

• Процессы освобождения пространства Avamar — Часть 1. Сбор мусора 
• Процессы освобождения пространства Avamar — Часть 2. Хруст 
• Процессы освобождения пространства Avamar — Часть 3.  Удаление процесса контрольной точки (RMCP) 

Текущая реализация чистки памяти была представлена вместе с версией Avamar 7.0, и ее конструкция оставалась в значительной степени неизменной.

Что делает сбор мусора?

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

Оно работает на каталоге cur и освобождает пространство в GSAN, удаляя фрагменты данных, на которые больше не ссылается какая-либо резервная копия:

• «Данные» определяются, если их можно найти в индексе.
• Данные ссылаются, если они существуют в рамках резервного копирования (то есть хэш присутствует в системе учета пользователей, составных полосах или элементах каталогов).

Пространство, освобождленное при сборе мусора, нельзя повторно использовать до тех пор, пока не будет выполнена ошибка . Процесс crunching выполняется сразу после завершения ежедневной запланированной чистки памяти. См. процессы освобождения пространства Avamar, часть 2. Извлечение компонентов.


Когда выполняется сбор мусора?

• Планировщик технического обслуживания или, в частности, сбор мусора отключен. Выходные данные status.dpn могут подтвердить это.
• Емкость операционной системы выше значения disknogc (от 86% до 89%).
  • См. сбой задач обслуживания Avamar MSG_ERR_DISKFULL из-за емкости ОС на разделы >данных 85%
• Проблемы синхронизации времени между узлами Avamar.
  • См. статью Avamar « Код симптома 4202: сбой сбора мусора с ошибкой MSG_ERR_BADTIMESYNC 
• Чередуются индексные полосы.
  • См. раздел Avamar « Сбой чистки мусора при MSG_ERR_TRYAGAINLATER
• Биты, на которые ссылались хэш-карты, не могут сбросить.
  • См. Avamar v7 и более поздние версии: сообщение «skipped-hashes» для чистки памяти, которое не может быть очищено из-за «хэшированных ссылаемых битовых карт», когда данные используются

Как работает сбор мусора

Шаг 1. Создание таблицы справочного количества (TORC):

Чистка памяти считывает записи в системе учета пользователей, композитных страйпах и элементах каталогов для создания таблицы справочного количества (TORC).
В TORC сбор мусора записывает все хэш-коды в системе и сколько раз на каждый хэш ссылается.

Шаг 2. Чтение индексов:
После завершения toRC каждый узел загружает подмножество отдельных полос индекса в память. Количество считываемых полос определяется параметром gccount . Для каждого хэша, определенного в индексе, сбор мусора ищет хэш в TORC, чтобы проверить, ссылались ли на него.

• Если хэш существует как в индексе, так и в TORC, ничего не делать. Каждый хэш в TORC имеет число ссылок не менее 1, поэтому хэш определяется и ссылывается.
• Если хэш существует в индексе, но не в TORC, хэш определяется, но не ссылается, поэтому его можно удалить.

Примечание.: Если хэш существовал в TORC, но не в индексе, это будет ошибка целостности данных (хэш, который используется, но не определен).  Это приводит к сбою hfscheck.

Шаг 3. Удалите хэш-хэш без логических выводов:
Как мы уже отмечалось ранее, хэш-коды, которые не используются для ссылки, не являются частью какой-либо резервной копии, поэтому их можно безопасно удалить из Avamar. Для этого выполните сбор мусора:

1. Удаляет запись в индексе.
2. Нулевая запись для хэша в дескрипторе «Заголовок фрагмента» (CHD). ChD определяет, где находятся отдельные фрагменты внутри контейнера страйпа.

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

Шаг 4. Обновите TORC.
Если фрагмент, который был удален из чистки памяти, был составным, необходимо обновить TORC.
Если вернуться к шагу 1, количество ссылок в TORC включает ссылки, выполнимые композитными полосами, которые содержат составные фрагменты.
Поскольку композитный фрагмент был удален, мы можем прибавить число ссылок в TORC по одному для любых хэшах, на которые ссылается этот композитный фрагмент.
Чистка памяти делает это, считывая в гипотетической организации, чтобы узнать, какие хэш-коды она ссылается, а затем обновить TORC.

Шаг 5. Прочитайте следующий набор индексов:
Чистка памяти выгружает предыдущий набор индексных полос из памяти, а затем загружает новый набор.
Шаги 2, 3 и 4 повторяются для этих новых страйпов индексов.
После того как все полосы индекса прочитаются, все фрагменты данных (известные как «атомарные» фрагменты) в TORC, который имеет 0 ссылок (с помощью шага 4), удаляются.

Шаг 6. Запустите новый пароль:
После того как все индексы прочитались, чистка «мусора» начинает новый пароль.
Все индексные полосы повторно считываться, и теперь данные, на которые больше не ссылались, благодаря нашим предыдущим пропускам.

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

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

Ручная чистка мусора

Микроуправляемая система сервера Avamar не должна требоваться. Планировщик предназначен для автоматизации выполнения задач обслуживания. Если емкость Avamar высока, см. Руководство по передовым практикам работы Avamar и Avamar: Концепции и обучение по управлению емкостью.

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

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