Как организовать резервное копирование виртуальных машин с общими дисками?

Владимир Пилипчук, вы не правы. ABR не работает на уровне файлов.
Агенты, установленные на VM, делают снимки дисков на уровне блоков (попутно сбрасывая кэш ОС и приложений, чтобы данные были консистентны).

Не вижу плюсов в использовании Veeam - cнапшоты тоже будут нагружать диски VM, которые расположены на общем хранилище, и получим тот же эффект при одновременной пиковой нагрузке на хранилище.

t_q_l: Возможно я ошибаюсь, но на сколько помню ABR работает с данными на уровне VMDK (агент для этого и ставится), а не на уровне LUN c VMFS. А это принципиально разный подход к работе с данными. Да, у Veeam есть отдельные инструменты для правильной работы с СУБД, Active Directory, Exchange и т.д., но это необходимо для сохранения целостности этих данных и гранулярного восстановления ввиду архитектурных особенностей этих продуктов, но это только косвенно связано с тем КАК ИМЕННО бэкапятся виртуальные машины.
Могу сказать лишь, что скорость резервирования и удобство управления планами резервирования и восстановления значительно выше по сравнению с ABR 10.
Сейчас VMware, например, обновила список своих продуктов значительно расширив инструментарий для нативного резервирования, в том числе и vSphere SRM, который я на данный момент тестирую для реализации катастрофо-устойчивого ЦОД. Тоже вариант. Все упирается в адекватность стоимости того или иного решения целям проекта.
Почитал сейчас про ABR 10 - как и говорил, поддержка vStorage появилась тольок в 11 версии и доработалась до вменяемого состояния в новой Acronis Backup 11.5 d в которой есть нормальный CBR. Но это из маркетинговых статей, сам я ни 11 ни 11,5 не использовал. В десятой версии максимальная интеграция была на уровне VMFS через API, а это не уровень LUN, это уровень FS. И о работе с блоками тут не может быть и речи.
Я не спорю с Вами, я лишь пытаюсь сказать, что реализация резервирования на уровнях FS и выше крайне не производительна при большом количестве виртуальных машин, особенно с разделяемыми образами виртуальных дисков (а именно это вы заявили в вопросе и заголовке, но в иллюстрации картинка несколько иная, описывающая обшие распределенные хранилища для VM). Обобшая эти два кейса я делаю вывод о том, что деградация производительности процесса резервирования связана именно с поддержкой акронисом VMFS. Возможно в новых версиях ABR функционал расширили, но и тут работа с храниличем заявлена через SAN, а не через гипервизор, который является довольно узким местом при вашей топологии (на сколько я могу ее "телепатировать")

Владимир Пилипчук: Владимир, спасибо за развёрнутый ответ.

Я извиняюсь - уточнил версию Acronis Backup & Recovery (ABR) - используется версия 11.5, а не 10.

Попытаюсь вернуть вопрос в нужное русло. Я готов изменить и методы резервного копирования, возможно даже и продукт (хотя на него потрачены деньги, и не хочется их терять). Но я пока не вижу ответа на свой вопрос - как оптимально построить план резервного копирования на общих дисках? Хоть на уровне LUN, хоть на уровне FS проблема никуда не исчезает - снэпшоты и их копирование влияет на производительность диска, на котором несколько машин.

t_q_l: Можете описать топологию более детально, для понимания как у вас организована виртуализация и резервирование? Попытаюсь проанализировать и дать ответ.

Владимир Пилипчук, уточнил схему (см. мой ответ ниже)

Я правильно понимаю, что вы "шарите" один и тот-же VMDK между разными VM?

Владимир Пилипчук: Нет.
На каждом LUN несколько vmdk-файлов, которые являются дисками разных виртуальных машин.

t_q_l: еще несколько уточняющих вопросов:
1 - на чем построена SAN? iSCSI/FC/FCoE/SAS (ну и про JumboFrame спрошу, если вдруг FCoE или iSCSI)
2 - Вы используете кластерное решение vmware c HA, или несколько Standalone ESXi с подключением каждого гипервизора к каждому хранилищу?
3 - Уточните редакцию ABR 11.5 (в связи с этим https://forum.acronis.com/forum/68696)
4 - Хранилища, на которые бэкапите подключениы к SAN как блочные устройства или выступают в роли SMB/FTP ресурсов, подключениых к ABR (которая так-же развернута как VM) в качестве централизованных хранилищ (опубликованных через собственный Samba/FTP-server или на одной из VM)?

Владимир Пилипчук:
1. FC.
2. Лезвия в вlade-шасси с двумя FC-cвитчами, к которым подключены СХД.
3. ABR 11.5 39029. Shared vmdk не используются. RDM диски не используются.
4. ABR-крутится на standalone сервере, к которому по iSCSI подключены диски с СХД (не задействованные в виртуалзации).

t_q_l: Вы не ответили - у вас HA-кластер с vCenter или нет? Хранилища подключены в vStorage или нет?

Владимир Пилипчук: HA-кластеров нет. Не знаю, что значит подключены в vStorage (не хватает компетенций ответить)

Если я все правильно понял отностительно вашей топологии, то...
Видите-ли, vStorage - это набор нативных технологий vmware, появившихся в vSphere 5 для работы с VMFS томами и данными на них, в частности это VMware vStorage API for Data Protection (VADP) и vStorage API for Array Integration (VAAI), а так же другие "плюшки", не интересные нам в разрезе вопроса.
Эти API используются, в основном, сторонними продуктами, обеспечивающими резервирование виртуальных машин. Эти технологии позволяют производить манипуляции с данными на уровне SAN без загрузки сети передачи данных LAN, что повышает производиельность, снижает влияние процессов резервирования и т.п.
Ну а теперь позволю себе предположить следующее:
Упомятый нами ABR 11.5 поддерживает все эти API ТОЛЬКО ПРИ РАБОТЕ с Высокодоступными (HA - high availability) кластерами под упрвлением vCenter Server 5.1 и выше, в иных конфигурациях ни Сервер ни Агенты Acronis Backup не используют эти API, и работают не на уровне SAN, а на уровне VMFS и выше, а так-же используют LAN для передачи данных в Хранилище резервных копий (это из документации к Acronis и vSphere).
В итоге, при бэкапе Акронисом, мы упираемся в пропускную способность Ethernet интерфейса конкретного ESXi сервера c MTU 1500 и блокировками данных внутри VMFS.

При вашей ситуации и топологии я бы попробовал, для начала, включить, выключенный по умолчанию VAAI в настройках гипервизора (Configuration -> Advanced Settings -> DataMover и установить DataMover.HardwareAccelerationMove = 1). Однако проверьте совместимость вашего хранилища с vSphere. В противном случае вы можете получить еще большую деградацию производительности, а то и вовсе потерять хранилища в гипервизорах.
Если все нормально, то вы получите прирост скорости при работе гипервизовров с томами и данными, такими как создание, копирование, перемещение и резайзинг VMDK, создание и консолидация снапшотов и т.п.
Вторым этапом я бы всетаки собрал гипервизоры под управление vCenter Server. Это даст возможность централизовать управление хранилищами, что в свою очередь позволить использовать VADP. Возможно этого будет достаточно для ABR и у вас заработает блочная передача на уровне SAN.
Ну и третий этап - это на выбор, или меняйте топологию, или собирайте кластер, или меняйте ПО.

t_q_l: И еще забыл сказать важную веСЧ - если я прав, то для сохранения консистентности данных скорость передачи будет выравнена по самому медленному потоку (то есть цепочки - самый медленный сторадж+самый медленный LAN-порт), во избежание переполнения и сброса буферов, при многопоточной передаче.