Avamar. Поведение и теория производительности резервного копирования

Цель этой статьи — описать, что происходит во время резервного копирования Avamar, с акцентом на помощь читателю в понимании поведения производительности резервного копирования.

Эта статья является дополнением к следующим статьям:

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

Что происходит во время резервного копирования Avamar?

Процесс резервного копирования avtar :

1) Загружает файлы файла и хеш-кэша в память

2017-06-09 23:00:25 avtar Info <5586>: Loading cache files from C:\Program Files\avs\var
2017-06-09 23:00:25 avtar Info <8650>: Opening filename cache file 'C:\Program Files\avs\var\f_cache2.dat'
2017-06-09 23:00:25 avtar Info <5573>: - Loaded filename cache file (6,532,792 bytes)
2017-06-09 23:00:26 avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\p_cache.dat'
2017-06-09 23:00:28 avtar Info <5573>: - Loaded hash cache file (402,653,728 bytes)
2017-06-09 23:01:01 avtar Info <6426>: Done loading cache files

2) Создает моментальные снимки VSS (в Windows):

2017-06-09 23:04:32 avtar Info <19008>: Obtaining available VSS providers
2017-06-09 23:04:32 avtar Info <8776>: Freezing volumes now...
2017-06-09 23:04:32 avtar Info <8780>: Creating the shadow copy set (DoSnapshotSet) ... 
2017-06-09 23:14:33 avtar Info <8781>: Shadow copy set successfully created.
2017-06-09 23:14:34 avtar Info <6074>: VSS snapshot set creation successful

3) Обходит все файлы, определенные набором данных Для всех файлов в исходном наборе
данных avtar берет полный путь и объединяет его с метаданными, подобными статистике, чтобы вычислить хэш для уникальной идентификации файла.

Дополнительные сведения см. в разделе Avamar. Что происходит, когда avtar считывает файл на этапе сканирования файла.

4) Сравните вычисленные хеши с теми, которые находятся в локальных клиентских кэшах

Avtar ищет хэш файла в файловом кэше. Проверяется, является ли он новым или был ли он изменен с момента предыдущего резервного копирования.

Если поиск в кэше файлов выполнен успешно, файл существует и не изменяется.

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

Дополнительные сведения см. в разделе Клиент Avamar — что должно измениться, прежде чем avtar сочтет файл измененным?

5) Обработка новых и измененных файлов

Для любого нового или измененного файла avtar должен:

• Чтение всего файла
• Разбейте его на фрагменты разного размера
• Сжатие каждого фрагмента
• Вычисляем хэш для каждого фрагмента

6) Проверьте, нет ли отсутствующих хэшей на сервере Avamar.

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

«присутствует».7) Данные записываются в Avamar Server (и, при необходимости, в Data Domain). 

Более подробную информацию о рабочем процессе см. в прилагаемом Avtarprocess.pdf.


Обзор резервного копирования Avamar с точки зрения производительности.

Пройдя описанные выше этапы, мы разделили их на «фазы», которые оказывают наибольшее влияние на производительность резервного копирования:

Фаза 0. Создание моментальных снимков VSS.

Служба теневого копирования томов (VSS) создает моментальные снимки томов, указанных в исходном наборе данных. Приложения могут продолжать запись в том, пока выполняется резервное копирование.
Avamar выполняет резервное копирование «замороженного» моментального снимка тома, доступного только для чтения, а не тома с возможностью записи. Это гарантирует наличие согласованного набора данных для резервного копирования.

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

Этап 1. Этап сканирования файлов. Процесс avtar статистирует все файлы в целевом наборе

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

Для клиента с вращающимися дисками в конфигурации RAID 5 производительность сканирования файлов составляет ~1 миллион файлов в час. Это варьируется от 300 000 до 3 миллионов в час. Это зависит от клиентской среды и характеристик данных, для которых выполняется резервное копирование.

Начиная с версии 7.3, клиенты Linux, выполняющие резервное копирование в Data Domain, могут воспользоваться преимуществами функции Linux Fast Incremental (LFI). Это позволяет избежать сканирования всего набора данных при каждом выполнении резервного копирования.

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

Этап 2. Avtar считывает измененные файлы, а затем фрагментирует, сжимает и хэширует данные.

На этом этапе выполняется большое количество вычислений. Для каждого измененного или нового файла avtar разбивает его на небольшие фрагменты. Он сжимает каждый фрагмент и вычисляет хэш в качестве «отпечатка пальца» для идентификации блока.

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

Стандартная производительность обработки файлов составляет около 100 Гбайт/ч, но может варьироваться до 300 Гбайт в час. Это зависит от среды.

Критически важные ресурсы: Клиентский диск и ЦП

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

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

Для наборов данных файловой системы следует ожидать, что ~0–3% файлов будут изменяться ежедневно.

Avtar должен 'stat()' для каждого файла, который изменяется, выполняя две операции ввода-вывода, одна для проверки атрибутов файла, другая для атрибутов безопасности.

Чтобы достичь эталонной скорости сканирования ~1 млн файлов в час для резервных копий файловой системы, avtar требуется около двух миллионов операций поиска в час, или 600 операций поиска в секунду.

Пример. Если резервная копия имеет коэффициент изменения 3%, то для 97 из 100 файлов требуются две операции поиска на диске, чтобы определить, были ли они изменены. Оставшиеся три, которые изменились, должны быть отсканированы, разбиты на фрагменты, сжаты и хэшированы.

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

Этап 3. Проверка наличия хэшей на Avamar Server

Фазы #1 и #2 создают хеши, указывающие на элементы резервной копии. Этими элементами могут быть уникальные фрагменты файлов, файловые системы или целые резервные копии.

Хэши записываются в файлы кэша клиента и сравниваются с хэшами, имеющимися на сервере Avamar, для проверки необходимости добавления новых данных. Это верно независимо от того, является ли целевой системой хранения Avamar Server или Data Domain.

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

• Здорового
• При обычных уровнях нагрузки
• Находится в том же сегменте локальной сети, что и клиент

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

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

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

Этап 4. Отправка нового фрагмента по сети на сервер Avamar или в Data Domain

Когда клиент отправляет на сервер новый уникальный фрагмент (размером до 64 Кбайт), производительность в основном зависит от пропускной способности сети. В основном это касается клиентов на базе WAN, которые генерируют большой объем измененных данных каждый день. Это также может повлиять на те, кто работает по перегруженным сетевым каналам. 

Ниже приведены схемы, показывающие поток данных, в котором клиент отправляет данные в систему Avamar и в интегрированную систему Avamar - Data Domain.






Критически важные ресурсы: Пропускная способность сети между клиентом и сервером

Этап 5. Данные, записанные на сервер Avamar или Data Domain

Данные резервного копирования необходимо записать в Avamar Server или систему Data Domain.

Критически важные ресурсы: Производительность записи на диск и общая нагрузка сервера Avamar.