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

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)?

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

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

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

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

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

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, а не через гипервизор, который является довольно узким местом при вашей топологии (на сколько я могу ее "телепатировать")

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

А чем сейчас пользуетесь для резервирования?

Почему перестает отвечать IP-адрес на BVI?

Выяснилась интересная деталь о которой я не знал.
Данный BVI является tunnel source для туннельного-интерфейса. И на этом туннельном интерфейсе навешана QOS через nhrp, и в этом проблема: для вирткальных интерфейсов в IOS 15.* очень сильно ограничены размеры буферов, из расчета, что нагрузка на таком интерфейсе не будет превышать 1Mbit/sec.
Как тольок снял QOS и перезапустил сбриджеваные интерфейсы - все сразу заработало.

Почему перестает отвечать IP-адрес на BVI?

На маршрутизаторе много интерфейсов, но заметил другую ситуацию - при перезагрузке роутера сабжевый интерфейс оживает на некоторое время, сразу после загрузки, и пингуется, но не долго - пакетов 7-10, и потом снова пропадает. Соответсвенно в ARP попадают MAC шлюза (снаружи) и MAC пингующего узла в подсети. На arping интерфейс отвечает всегда. Картина рисуется такая, что L2 есть всегда, но L3 пропадает почти сразу после загрузки роутера.
Вот такая вот незадача...

Почему перестает отвечать IP-адрес на BVI?

Пинга нет ни откуда, только локальный пинг (с самого маршрутизатора). Ни с интерфейса наружу, ни снаружи на интерфейс.

При пинге интерфейса снаружи - хост недоступен. При пинге с роутера наружу через этот интерфейс - то же самое. С остальных интерфейсов все доступно.

Cisco 3925 / IOS 154.1

Резервный канал через PBR. Как быть с публикуемыми сервисами?

Есть более интересное решение на основе ДНС. Разворачиваем внутри организации два NS-сервера для нашей зоны, каждый NS доступен только через свой канал и не доступен через другой. NS имеют разные А-записи для одной зоны, которые для одних и тех же хостов выдают разные ip-адреса в зависимости от канала, на котором висит конкретный NS.

Это делается через view и одним сервером. А вот с делегированием намаетесь, так как файлы зон должны быть всегда одинаковыми (версии, хост, TTL-ы и т.д.). Болшее веселье Вас ждет с почтой. При RR у вас всегда будет меняться ответ и вы будете попадать сначала в GL а потом в BL, а некоторые, типа Google или Mail.ru могут и забанить напроч… так что я бы подумал хорошенько.

В любом случае, если Вы хотите управлять входящим траффиком — либо делать балансер на резервированном оборудовании, либо БГП — иначе никак.

Резервный канал через PBR. Как быть с публикуемыми сервисами?

Если говорить о BGP, то нужно покупать оборудование, сейчас есть только одна железка с BGP, естественно такой вариант не подходит

Простите, если нарушаю Ваш «фэн-шуй», но я хочу понять — что за оборудование Вы хотите для BGP? Два сервера c Quagga — довольно бюджетно. А если на *BSD — то еще и CARP (аналог HSRP) бесплатно получите.

Резервный канал через PBR. Как быть с публикуемыми сервисами?

У решения с DDNS есть один большой недостаток — многие провайдеры, как это не прискорбно, особенно в частном секторе, зачастую принудительно кэшируют DNS ответы на время, значительно превышающее TTL, нагло нарушая стандарты. А на претензии отвечают нечно в духе — «Обеспечивайте отказоустойчивость сервиса, а коли такой нищеброд — то и не суйся со своими сайтами».
Лично сталкивался с этим. И что самое отвратительное — большая часть трафика теряется именно по этой причине. тут уже невольно задумываешься о решениях более фундаментальных, чем DNS.

Резервный канал через PBR. Как быть с публикуемыми сервисами?

Да, rapidspacerocket, Вы все правильно понимаете.
По поводу BGP и железок… Ну, BGP не обязательно держать на кошках. Можно использовать Quagga например.

Использование IP-адреса Dialer-а внутри сети. Возможно ли?

merlin-vrn, спасибо вам огромное за ликбез. Я и правда плохо понимаю как работате PPPoE, о чем сообщил в вопросе. Теперь я понимаю что так делать нельзя.

Использование IP-адреса Dialer-а внутри сети. Возможно ли?

Ну, этот как запасной вариант (не желательный).
Провайдер домовой, жадный, доп. адрес только с новым подключением дает… а подсети, как выяснилось, отдавать не умеет.

Но хотелось бы получить именно тот, который отдает DHCP на роутер.
проверил — можно забрать, только вот шлюз… тут основная проблема…

Использование IP-адреса Dialer-а внутри сети. Возможно ли?

В идеале, хочется «конвертировать» PPPoE в FastEthernet (подать внутрь отдельным VLAN, как угодно), чтобы не поднимать PPPoE сессий на «конспиративном» оборудовании. а просто прописать IP на интерфейсе.

Выбрать железку уровня доступа?

Да, возможно 49хх тоже подойдет, но стоимость такой инфраструктуры на много дороже.
Я до сих пор не знаю для чего эта сеть, но из описания предполагаю что сеть офисная и я исходил из расчета функционал/стоимость.
Объективно, на доступе, суммарный траффик, в единицу времени, редко достигает значений даже 2-3Gbit на свитч. Поэтому магистрального транка до ядра в 4Gbit (LACP) более чем достаточно, а так-же скорость коммутации при агрегации линков немного выше чем по одному порту (у сиско точно. Проверено).

Если бюджет позволяет и нагрузка действительно будет близкая к 10G до ядра, то я бы рекомендовал на ядро Cat 6500 10G модулями, а на AL новые 3560 в конфигурации с восходящими 10G
В этом случае шина между коммуторами доступа гарантированно будет иметь потолок в 10G и с минимальной задержкой.

А если бюджет ограничен, то я бы добавил третий стой распределения на тех-же 3560. Это будет немного дороже первоначальной конфигурации, но на много дешевле ядра на 65хх и доступе на 3560.

Тут нужно понять потребности и разработать архитектуру. Тогда придет понимание архитектуры, а следовательно и понимание того, на ЧЕМ ее реализовавать. Ведь потом возможны изменения конфигурации, что может потребовать пересмотра архитектуры. Поэтому все нужно спланировать заренее.

Выбрать железку уровня доступа?

Но должен сказать, что коммутаторы очень производительные и надежные. ЭР-ТЕЛЕКОМ на них агрегацию делает.
Но для AL мульти-сервисной сети я бы все-же рекомендовал сиську. Столь же функциональный коммутатор от DLINK стоит не на много дешевле.

Выбрать железку уровня доступа?

Не плохая железяка. Ставим такие на временные объекты.
В гуях из полезного — встроеный LAN-тестер + проверка кабеля на разрыв. Показывает довольно точно — погрешность менее 1 метра.
Настроить коммутатор через гуй — это квест. Очень много настроек и большая вложенность меню, которая постоянно схлопывается. Не все настройки портов доступны. CLI куда нагляденее и функциональнее (прости меня, КО).

Выбрать железку уровня доступа?

Нет гуев там

Выбрать железку уровня доступа?

Cat 3750 — вполне хороший ядерный коммутатор. есть поддержка машрутизации и туннелирования. Есть и более новые и дорогие модели, но производительности 37хх Вам хватит, на 480 портов точно.
Рекомендую взять три таких железяки и собрать в Stack кольцом.

У меня на предприятии 3 3750 ведут 30 коммутаторов по 48 портов. Полет нормальный (правда на клиента мы отдаем 100 мегабит, а игабитные порты только серверам.)