Кластер высокой готовности RabbitMQ с двумя узлами периодически прерывается с заданиями резервного копирования Veeam

Среда состоит из двух виртуальных машин 2012R2, работающих под управлением RabbitMQ с высокой доступностью (ha-all) в своих очередях. Я использую Veeam для создания резервных копий моментальных снимков, которые отправляются за пределы сайта в рамках политики DR.

Я вижу периодические сбои кластера, когда происходит резервное копирование Veeam. Когда кластер ломается, это приводит к регистрации событий Mnesia или иногда к полному отключению одного узла. Я полагаю, что проблема заключается в том, как Veeam переворачивает виртуальную машину, когда она на короткое время останавливает виртуальную машину, а затем продолжает работу. Когда происходит этот всплеск, оба Узла видят, что другой исчезает, и вторичный агент немедленно превращается в мастера. С двумя мастерами, бегущими, как только они видят друг друга (буквально через несколько секунд), они прикладывают головы, и кластер ломается.

Я читаю о net_ticktime здесь и реализовали 300 секунд, думая, что это поможет сделать кластер более устойчивым к коротким сигналам Veeam, но, похоже, это не помогло. Когда один узел видит, что другой исчезает, вторичное устройство немедленно продвигается к овладению и, похоже, не использует net_ticktime установка.

Пример Mnesia error:

Mnesia('rabbit@Node01'): ** ERROR ** mnesia_event got {inconsistent_database, running_partitioned_network, 'rabbit@Node02'}

Кто-нибудь еще испытывал это или что-то подобное? Существуют ли дополнительные параметры конфигурации с RabbitMQ или Erlang, которые могут помочь сделать кластер более устойчивым к небольшим скачкам потери соединения между узлами?