![](https://habrastorage.org/files/761/f21/85a/761f2185a25a4f7c90b477cd14cf1143.png)
Предыстория
Когда два года назад мы выпускали Veeam Backup & Replication 6.0, одним из самых важных нововведений была масштабируемость: благодаря распределенной архитектуре на базе специально выделенных «прокси-серверов» (серверов, которые непосредственно выполняют задания резервного копирования по перемещению данных) и распределению нагрузки между ними, продукт получил возможность обслуживать инфраструктуры практически любых размеров.
Причин для создания новой архитектуры было несколько, и, соответственно, ею решалось сразу несколько задач:
- Обеспечить масштабируемость до инфраструктур любых размеров — для этого можно создать нужное количество “прокси-серверов” (серверов, которые выполняют задания резервного копирования), между которыми можно оптимально распределять рабочую нагрузку.
- Повысить надёжность процесса резервного копирования и исключить проблему «единой точки отказа». Даже если один прокси-сервер упадет, задачу за него завершит другой.
- Уменьшить нагрузку, которую операции резервного копирования оказывают на производственную инфраструктуру – благодаря использованию описанного в настоящей статье механизма.
- Снять головную боль «Как же оптимально составить расписание для нескольких заданий?» – теперь можно настроить их параллельное выполнение.
- Автоматически следить за свободным местом на хранилище и заблаговременно предупреждать о приближении порогового значения
При каждом выполнении задачи резервного копирования виртуальной машины Veeam Backup & Replication выбирает оптимальный прокси-сервер, ориентируясь на его территориальное положение в сети и его текущую нагрузку.
Veeam Backup & Replication v7
В вышедшей в прошлом году текущей версии продукта мы усовершенствовали алгоритм распределения нагрузки, внедрив новую функциональность — параллельную обработку данных. Диски одной виртуальной машины теперь могли бэкапиться одновременно с использованием нескольких прокси-серверов.
Для каждого виртуального диска VMware выбирается оптимальный прокси-сервер, исходя из возможных способов доступа к данным (перечислены далее в порядке убывания приоритета):
- Direct SAN (прямой доступ к данным по сети хранения данных, не затрагивает хосты производственной сети)
- Hot Аdd (прямой доступ к системе хранения данных через стек ввода-вывода ESXi)
- Network Block Device — данные виртуальной машины передаются по сети с использованием управляющего интерфейса ESXi
При настройке прокси-сервера для платформы VMware можно самостоятельно выбрать наиболее подходящий режим доступа к данным, а также определить список хранилищ, с которыми прокси может работать. А можно указать, что способ передачи данных должен выбираться автоматически, исходя из конфигурации прокси сервера.
Здесь же можно указать максимальное количество задач, которые данный прокси-сервер сможет обрабатывать одновременно.
![](https://habrastorage.org/files/51d/762/4f8/51d7624f81c84bb9bae8cc366b1e0283.png)
При распределении новых задач резервного копирования учитывается текущая нагрузка на прокси-сервере, а также упомянутый выше показатель – максимальное количество задач, которые могут на нем выполняться. Это помогает избежать перегрузки инфраструктуры в целом. В версии 7 мы также переработали алгоритм сжатия данных, чтобы уменьшить загрузку процессора – в результате повысилась работоспособность прокси-сервера.
Большинство заказчиков успешно использовали автоматические настройки распределения нагрузки, однако были и те, у кого из-за множества заданий прокси-серверов и, соответственно, из-за слишком интенсивной нагрузки на производственные системы хранения данных, возникали проблемы с доступностью СХД. Особенно переживали заказчики, которым требовалось поддерживать круглосуточную работу бизнес-приложений: эти самые приложения во время создания резервной копии могли внезапно перестать отвечать по сети, а по некоторым даже приходили оповещения об ошибках от систем мониторинга. Проблема крылась в недостаточной производительности при операциях чтения/записи: ведь при резервном копировании эти операции могут выполняться весьма интенсивно, а если при этом еще и какие-либо виртуальные машины выполняют свои операции чтения/записи, — жди неприятностей.
Сначала мы пошли по пути наименьшего сопротивления и просто-напросто решили задавать ограничения для хранилищ – в одном из ранних патчей для версии 7 можно было использовать параметр «Одновременная обработка не более чем Х задач» (“No more than x tasks per datastore at a time”). Однако возник резонный вопрос – а что, если администратор баз данных развернет новый SQL сервер на нашем хранилище со столь тщательно выверенными настройками, — и все предельные значения внезапно окажутся превышены? С другой стороны, если чересчур осторожничать при установке ограничения на число обрабатываемых задач, можно не уложиться в отведенное окно резервного копирования. В общем, недостатки такого подхода налицо: в динамичных, постоянно меняющихся виртуальных инфраструктурах постоянно перенастраивать пороговые значения вручную не годится.
Что будет нового в версии 8
В версии 8, которая выйдет в начале 4 квартала этого года, мы представляем новую возможность – автоматический контроль за интенсивностью операций чтения/записи СХД – Backup I/O Control (в настоящее время нами ожидается патент на алгоритм этой функциональности). Для пользователя этот функционал будет доступен как набор настроек, с помощью которых можно задать предельно допустимые значения длительности задержки обмена данными для хранилища (datastore latency). Эта функциональность поддерживается как для платформы VMware, так и для Hyper-V.
Значения, которые вы устанавливаете, можно считать своеобразным соглашением об уровне обслуживания для вашей системы хранения данных.
![](https://habrastorage.org/files/c6e/4b3/33c/c6e4b333c1644631af9f4b2a76bbf8f2.png)
Новый подход очень прост и требует задания всего двух параметров (значения указываются в миллисекундах).
- “Stop assigning new tasks to datastore at:” теперь при выборе прокси-сервера для обработки виртуального диска будет учитываться время задержки при обращении к диску для операций ввода-вывода (IOPS latency). Если хранилище слишком загружено (время задержки равно или превышает указанное значение), то задание резервного копирования не будет запущено до момента, пока этот показатель не уменьшится (т.е. пока нагрузка на хранилище не снизится).
- “Throttle I/O of existing tasks at:” применяется, если задание резервного копирования уже запущено, и в процессе его выполнения возникла задержка при обращении к диску, вызванная внешней нагрузкой. Например, если на виртуальной машине запустится сервисный процесс SQL сервера, который будет использовать то же хранилище, что и задание резервного копирования, то это задание автоматически ограничит собственную интенсивность обращений к диску, пока показатель времени задержки не снизится до указанного значения. Возможно, это несколько увеличит время выполнения задания, но зато отрицательно не повлияет на работу приложений.
Пример использования этих настроек иллюстрирует следующий график:
![](https://habrastorage.org/files/b99/cf9/54f/b99cf954fa2840518fd5fd005d373c5c.png)
Зеленым цветом показана задержка при операциях чтения – мы видим, что при использовании настроек автоматического контроля (на графике – это область между метками Enabled и Disabled) этот показатель снижается до 20 мс и ниже, а если настройки автоматического контроля отключены (на графике — область слева от метки Enabled и справа от метки Disabled), значение ползет вверх.
В Veeam Backup & Replication 8 пользователи получают доступ к различным возможностям автоматического контроля интенсивности операций чтения/записи в зависимости от редакции. Так, в редакции Enterprise эти настройки задаются на уровне сервера резервного копирования. Значения, выставленные по умолчанию, мы сознательно задали не очень высокими, поскольку ориентировались на фактические данные от заказчиков, использующих наши решения для мониторинга инфраструктуры. Именно такие значения задают пользователи в реальных инфраструктурах, настраивая оповещения типа «предупреждение» и «сообщение об ошибке». Разумеется, вы можете изменить значения по умолчанию на значения, актуальные именно для вашей инфраструктуры.
В редакции Enterprise + настройки автоматического контроля можно задавать для каждого хранилища в отдельности (здесь они уже не являются глобальными). Это позволяет настроить индивидуальные значения в зависимости от загруженности или критичности того или иного хранилища. Например, для задач разработки и тестирования время задержки (отклика) можно увеличить.
![](https://habrastorage.org/files/e83/514/fc6/e83514fc6eda4f64bcc2438340e4cb27.png)
Подводя итог
В новой версии Veeam Backup & Replication v8 мы выпустим функционал автоматического контроля интенсивности операций чтения/записи хранилища, что позволит пользователям оптимальным образом настроить процесс резервного копирования с точки зрения степени нагрузки на хранилища производственной сети и избежать перебоев в работе сетевых приложений и сервисов.
Дополнительные ссылки
1. "Veeam Backup & Replication v8: Veeam Explorer for Active Directory и Veeam Explorer for Microsoft SQL Server"
2. "Поддержка аппаратных снапшотов СХД NetApp в Veeam Backup & Replication v8"
3. Сайт с обзором функциональных возможностей новой версии Veeam Backup & Replication Suite v8
4. "Интеграция Veeam Availability Suite v8 и EMC Data Domain Boost"
5. "Storage I/O Control (SIOC) and Veeam" (статья базы знаний, англ. яз.)