Быстрое внедрение ERP Комплексные услуги
от 1С:Центр ERP!
Управление доставкой Для торговых и курьерских компаний!
1C:ЭДО Узнайте о всех преимуществах электронного документооборота!
Переход на «1С:ЗУП ред. 3» Фирма «1С» прекращает поддержку «1С:ЗУП 2.5»!
Аренда сервера 1С
в облаке
Работайте в 1С удаленно с экономией до 70%!

Одним из направлений деятельности компании 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 - Высокий уровень сжатия



На основании тестов мы сделали некоторые выводы:

  1. Система Veeam очень удобна в использовании для сети, построенной на гипервизорах. Очень полезна возможность применять внутреннюю дедупликацию для виртуальных машин, что позволяет значительно уменьшить объём резервных копий кластерных ролей.
  2. Наиболее хорошо сжимаются файлы баз данных – до 18-22%, хуже всего – файловые данные – 77-78%, виртуальная машина с файлами ОС сжалась до 57-64%
  3. Разница между применением оптимального и высокого уровня сжатия составила от 1,5 % на сервере с файлами до 16% на сервере с базой данных. На сервере с пустой ОС разница составила примерно 10%
  4. Корреляция между степенью сжатия и кол-вом IOPs на backup-сервере или носителем виртуальных машин не наблюдалась. В одних тестах количество IOPs было выше при высокой степени сжатия, в других при низкой и отличалось не значительно. Аналогичная ситуация в сопоставлении степени сжатия и загрузки процессора на backup-сервере.
  5. Корреляция между степенью сжатия и загрузкой процессора на носителе виртуальных машин наблюдалась - при всех тестах загрузка процессора была выше, если использовалась более высокая степень сжатия. Разница в разных тестах составляла от 3 до 13 %.
  6. При анализе загруженности CPU и жестких дисков при использовании Reverse incremental backup и Incremental backup также не было выявлено закономерности. В разных тестах то один то другой метод использовал больше ресурсов. В боевых условиях мы решили использовать Reverse incremental backup – так как в этом случае последний бэкап всегда полный и его удобнее восстанавливать.


EFSOL

Системная интеграция. Консалтинг

ИТ-обслуживание

обязательные поля
* Антиробот:
Введите ответ

ИТ-обслуживание

Все поля формы выделенные значком * обязательны к заполнению
* Антиробот:
Введите ответ
Поделиться:

У вас конкретная задача? Свяжитесь с нами прямо сейчас!


Обратный звонок RedConnect