Одним из направлений деятельности компании EFSOL является предоставление в аренду виртуальных серверов в комплекте с лицензионным ПО и технической поддержкой (SaaS). Поддержка предоставляется по такому принципу - клиент может комфортно пользоваться услугой и не думать о таких вещах, как резервные копии, мониторинг ИТ-систем, регламентные операции. Особое внимание мы уделяем резервному копированию данных наших клиентов.
Изначально для резервного копирования разных типов данных использовались разные инструменты:
- Для баз данных – встроенные скрипты
- Для файлов – скрипты на базе 7-zip
- Для образов операционной системы – Acronis True Image
Такой подход имел ряд минусов:
- Большие трудозатраты на настройку резервного копирования - нужно было настроить три разных инструмента.
- Долгое время восстановления резервной копии. Восстановление происходило в три этапа – сначала восстанавливался образ диска, далее разворачивались актуальные файловые данные и базы данных.
- Не было централизованного мониторинга - невозможно было отслеживать ошибки и проблемы резервных копий всех объектов на единой консоли.
Так как количество виртуальных серверов со временем росло, созрела необходимость использования серьезного инструмента корпоративного уровня, который бы позволял осуществлять резервные копии всех виртуальных машин целиком и сразу их разворачивать в случае необходимости. Сразу стоит отметить, что резервное копирование баз данных встроенными механизмами SQL мы решили оставить и использовать параллельно – для большей надежности и гибкости.
В своём выборе мы остановились на системе Veeam, так как она удовлетворяла всем требованиям (см. схему на рисунке 1).
Рисунок 1. Схема работы системы резервного копирования на базе Veeam
Описание среды тестирования, цели тестирования
Для проверки системы резервного копирования, мы собрали тестовый стенд (см. Таблица 1 и Таблица 2).
| ВМ | ЦП | Оперативная память | Дисковое хранилище | Тип дисков, RAID | ОС |
| Носитель Hyper-V | Intel Xeon E5-2670 | 256 GB | 745 GB |
2*Intel SSD S3610 Series 800GB, RAID 1
|
Windows Server 2012 R2 Datacenter |
| Backup-сервер | Intel Xeon E3-1231v3 | 16 GB | 35,9 TB |
6*SATA 10TB 3.5" WD Gold SATA, RAID 6
|
Debian Linux |
Таблица 1. Параметры тестовой среды
| ВМ | Кол-во ядер ЦП | Оперативная память | Общий объем дисков | Занятое дисковое пространство | ОС |
| Сервер с ОС | 2 | 2 GB | 50 GB | 11,9 GB | Windows Server 2012 R2 STD |
| Файловый сервер | 2 | 2 GB | 200 GB | 119 GB |
Windows Server 2012 R2 STD
|
| Сервер СУБД MS SQL 2014 STD | 4 | 4 GB | 350 GB | 139 GB | Windows Server 2012 R2 STD |
Таблица 2. Параметры виртуальных машин
Помимо знакомства с продуктом Veeam также было решено выполнить тесты, которые дали бы ответы на такие вопросы:
- Насколько хорошо система сжимает информацию при резервном копировании в зависимости от типа данных и от типа сжатия?
- Какой метод резервного копирования выбрать: incremental backup или reverse incremental backup?
- Как тип сжатия влияет на использование ресурсов сервера резервных копий и носителя виртуальных машин?
- Насколько приемлемо использовать максимальный тип сжатия?
Во время сравнительных тестов время создания резервных копий не фиксировалось.
Обнаруженные проблемы и их решение
Во время тестирования всплыла интересная проблема: Veeam начал выдавать ошибки при выполнении задания одной из виртуальных машин. Оказалось, что это известный баг, который возникает тогда, когда VHD виртуальной машины был до этого сжат. Лечится это расширением VHD на минимальный объём: например, VHD был сжат на 100 ГБ и чтобы не было ошибки его нужно расширить хотя бы на 1 ГБ.
Полезные функции
Из функций, которые актуальны для структуры, построенной на виртуальных машинах, хотелось бы отметить per-VM backUP. Эта функция позволяет при резервном копировании объединять виртуальные машины в группы и применять внутри этих групп дедупликацию – т.е. блоки, которые присутствуют в нескольких виртуальных машинах, не дублируются.
Очень актуально, когда несколько машин используют один и тот же подключенный VHD – например, при создании кластерных ролей. По умолчанию данный общий диск копируется на всех машинах, в которых он присутствует. При включенной функции per-VM backUP данный раздел копируется только один раз. По умолчанию данная функция отключена. Если просто применить функцию на группе серверов с одинаковой ОС, все равно наблюдается ощутимая экономия места, поскольку серверы имеют много одинаковых блоков.
Результаты тестирования
Серверная операционная система
|
Тип теста |
iops чтения на носителе |
iops записи на носителе |
CPU на носителе Windows, % |
Загрузка сети, MБ/с |
iops записи на сервере резервного копирования |
CPU на сервере резервного копирования, linux |
% сжатия |
|
Active Full backup |
26 |
52 |
39 |
112 |
140 |
0.47 |
64 |
|
Incremental backup |
28 |
84 |
37 |
125 |
175 |
0,25 |
64 |
|
Synthetic Full Backup |
32 |
74 |
40 |
120 |
150 |
0,3 |
64 |
Таблица 3. Серверная ОС. Incremental backup - Оптимальный уровень сжатия
|
Active Full backup |
33 |
80 |
52 |
112 |
180 |
0,54 |
57 |
|
Incremental backup |
29 |
70 |
49 |
110 |
182 |
0,51 |
57 |
|
Syntactic Full Backup |
35 |
78 |
47 |
112 |
181 |
0,49 |
57 |
Таблица 4. Серверная ОС. Incremental backup - Высокий уровень сжатия
|
Active Full backup |
25 |
53 |
38 |
121 |
148 |
0,4 |
64 |
|
Reverse incremental backup |
32 |
88 |
38 |
123 |
190 |
0,4 |
64 |
Таблица 5. Серверная ОС. Reverse incremental backup - Оптимальный уровень сжатия
|
Active Full backup |
28 |
60 |
56 |
112 |
140 |
0,25 |
57 |
|
Reverse incremental backup |
33 |
58 |
49 |
111 |
180 |
0,3 |
57 |
Таблица 6. Серверная ОС. Reverse incremental backup - Высокий уровень сжатия
Файловый сервер
|
Тип теста |
iops чтения на носителе |
iops записи на носителе |
CPU на носителе Windows, % |
Загрузка сети, MБ/с |
iops записи на сервере резервного копирования |
CPU на сервере резервного копирования, linux |
% сжатия |
|
Active Full backup |
47 |
65 |
18 |
111 |
242 |
0,95 |
78 |
|
Incremental backup |
48 |
61 |
20 |
112 |
255 |
0,85 |
78 |
|
Synthetic Full Backup |
44 |
105 |
19 |
111 |
240 |
0,75 |
78 |
Таблица 7. Файловый сервер. Incremental backup - Оптимальный уровень сжатия
|
Active Full backup |
48 |
67 |
22 |
111 |
250 |
0,93 |
77 |
|
Incremental backup |
46 |
76 |
26 |
109 |
250 |
0,7 |
77 |
|
Syntactic Full Backup |
49 |
67 |
23 |
111 |
262 |
0,8 |
77 |
Таблица 8. Файловый сервер. Incremental backup - Высокий уровень сжатия
|
Active Full backup |
53 |
58 |
20 |
110 |
272 |
0,8 |
78 |
|
Reverse incremental backup |
49 |
99 |
19 |
111 |
245 |
1,26 |
78 |
Таблица 9. Файловый сервер. Reverse incremental backup - Оптимальный уровень сжатия
|
Active Full backup |
48 |
59 |
23 |
112 |
253 |
1 |
77 |
|
Reverse incremental backup |
51 |
99 |
23 |
110 |
255 |
1,18 |
77 |
Таблица 10. Файловый сервер. Reverse incremental backup - Высокий уровень сжатия
Сервер баз данных MSSQL
|
Тип теста |
iops чтения на носителе |
iops записи на носителе |
CPU на носителе Windows, % |
Загрузка сети, MБ/с |
iops записи на сервере резервного копирования |
CPU на сервере резервного копирования, linux |
% сжатия |
|
Active Full backup |
57 |
99 |
60 |
90 |
215 |
0,45 |
22 |
|
Incremental backup |
58 |
96 |
61 |
90 |
200 |
0,5 |
22 |
|
Synthetic Full Backup |
59 |
76 |
59 |
90 |
235 |
0,58 |
22 |
Таблица 11. Сервер баз данных. Incremental backup - Оптимальный уровень сжатия
|
Active Full backup |
59 |
80 |
66 |
80 |
205 |
0,6 |
18 |
|
Incremental backup |
57 |
74 |
68 |
80 |
180 |
0,73 |
18 |
|
Syntactic Full Backup |
60 |
108 |
69 |
80 |
262 |
0,6 |
18 |
Таблица 12. Сервер баз данных. Incremental backup - Высокий уровень сжатия
|
Active Full backup |
59 |
70 |
56 |
90 |
220 |
0,56 |
22 |
|
Reverse incremental backup |
60 |
76 |
60 |
90 |
190 |
0,52 |
22 |
Таблица 13. Сервер баз данных. Reverse incremental backup - Оптимальный уровень сжатия
|
Active Full backup |
66 |
67 |
66 |
80 |
205 |
0,59 |
18 |
|
Reverse incremental backup |
62 |
64 |
66 |
80 |
180 |
0,43 |
18 |
Таблица 14. Сервер баз данных. Reverse incremental backup - Высокий уровень сжатия
На основании тестов мы сделали некоторые выводы:
- Система Veeam очень удобна в использовании для сети, построенной на гипервизорах. Очень полезна возможность применять внутреннюю дедупликацию для виртуальных машин, что позволяет значительно уменьшить объём резервных копий кластерных ролей.
- Наиболее хорошо сжимаются файлы баз данных – до 18-22%, хуже всего – файловые данные – 77-78%, виртуальная машина с файлами ОС сжалась до 57-64%
- Разница между применением оптимального и высокого уровня сжатия составила от 1,5 % на сервере с файлами до 16% на сервере с базой данных. На сервере с пустой ОС разница составила примерно 10%
- Корреляция между степенью сжатия и кол-вом IOPs на backup-сервере или носителем виртуальных машин не наблюдалась. В одних тестах количество IOPs было выше при высокой степени сжатия, в других при низкой и отличалось не значительно. Аналогичная ситуация в сопоставлении степени сжатия и загрузки процессора на backup-сервере.
- Корреляция между степенью сжатия и загрузкой процессора на носителе виртуальных машин наблюдалась - при всех тестах загрузка процессора была выше, если использовалась более высокая степень сжатия. Разница в разных тестах составляла от 3 до 13 %.
- При анализе загруженности CPU и жестких дисков при использовании Reverse incremental backup и Incremental backup также не было выявлено закономерности. В разных тестах то один то другой метод использовал больше ресурсов. В боевых условиях мы решили использовать Reverse incremental backup – так как в этом случае последний бэкап всегда полный и его удобнее восстанавливать.
EFSOL