none
"Split brain" в Exchange 2010 SP3 CU17 DAG кластере RRS feed

  • Вопрос

  • Здравствуйте.

    Описание проблемы ниже.
    Это похоже на split brain, но указанных в статье eventid нет.
    https://blogs.technet.microsoft.com/askcore/2012/02/24/whats-going-on-with-my-cluster/
    На будущее - про DAC прочитал, возможно это решит проблему
    https://blogs.technet.microsoft.com/rmilne/2013/12/04/dac-and-should-i-enable-dac-for-dag-in-a-single-ad-site/

    Как без потерь почты в базах данных вывести кластер из этого состояния?
    Возможность миграции ящиков не проверяли еще, есть вероятность что не заработает, по крайней мере создать базу в этом кластере не получилось, он извне в нерабочем состоянии.


    Дано (Exchange 2010 SP3 CU17):

    обычный fs witness mbx кластер о двух нодах, виртуализация vmware
    вечером начинается практически одновременный бэкап, со снапшотами, vss, через Veeam на уровне ВМ.
    нода 2 от этого дела сошла с ума, и судя по логам примерила на себя cluster ip
    с постоянными алертами о duplicate cluster ip, потому что адрес конечно же законно сидел на ноде 1

    Следствие:
    с утра кластер был в очень интересном состоянии.
    каждая нода думала что она одна и вполне рабочая.
    в консоли и gui - все базы были в mount!!! на обоих серверах.
    и на обоих серверах был кластер IP активен.

    Трагедия:
    после последовательной перезагрузки нод 2, 1, кластер в норме. в процессе перезагрузки почтовые базы данных были в статусе dismount. т.е. какое-то время HT действительно не мог дослать письма в базы.
    Как итог - натурально из ящиков исчезли письма ДО начала перезагрузки, с какого-то момента, возможно с начала аварии.
    Логи циркулярные, все уже в базах.
    В дампстерах пусто. Причем письма явно были в базах, сотрудники это подтвердили, а в messagetracking явно видна доставка в базу.

    Вопрос:
    Я такое первый раз вижу, как это объяснить? 
    Как между базами решается конфликт на актуальность отдельных сообщений??

    Помимо журналирования на уровне базы - какие еще варианты не попасть так и не потерять дельту от момента последнего бэкапа?

    31 октября 2018 г. 18:07

Ответы

  • Не ко мне вопрос, к сожалению.
    Есть какие-то варианты вывести кластер из этого состояния?

    Как определить, какая из двух активных нод действительно сломана?
    Размер edb идентичен.
    Логи циркулярные, на одной 8000 логов со вчера, на другой 250.

    Во-первых, из какого такого состояния кластер надо выводить? Вы же пишете, что сейчас кластер у вас в норме. Что касается потерянных сообщений, то они, скорее всего, потеряны навсегда: вероятно их доставка шла в ту копию базы, которая после решения проблемы стала пассивной и синхронизовалась по этому поводу с активной копией, с потерей этих сообщений.

    Почему это произошло? Мне это видится таким образом. Из практического опыта: при создании снимка VM для бэкапа VMWare может "подморозить" ВМ на время больше минуты. Чего вполне достаточно для того, чтобы второй узел кластера посчитал эту ВМ неработоспособной и забрал на себя первичную группу вместе с кластерным IP, в результате чего копия Active Manager на нем стала активной и смонтировала на нем копии баз как активные. А после окончания заморозки первый узел, ничего не зная о ней, так и продолжал считать себя активным - владельцем имени и IP кластера (первичной группы ресурсов), местом размещения активной копии Active Manager и активных копий баз. А вот почему это состояние сохранилось долго - это мне не понятно.

    Какую из активных копий считать правильной? Скорее всего - никакую: доставка сообщений идет непредсказуемо в разные копии (по выбору HT), и, скорее всего, та или иная часть сообщений будет потеряна. Можно, конечно, попытаться остановить службу транспорта, проанализировать Message Tracking на предмет куда делалась доставка и выбрать "лучшую" копию. Но, скорее всего, приоритетность восстановления работоспособности сервиса вам не позволит терять время на это.

    Что делать? Не копировать виртуальные серверы Exchange с помощью Veaam, никогда. DAC, если я правильно понял причину, в вашем случае не поможет - этот механизм срабатывает в момент запуска сервера/службы хранилища, и, а у вас служба хранилища вместе с сервером продолжала работу - только небольшой перерыв был.


    Слава России!



    3 ноября 2018 г. 7:33

Все ответы

  • Евгений, а можно уточнить зачем делается бэкап Exchange на уровне ВМ? Какой в этом смысл?
    1 ноября 2018 г. 5:40
  • Не ко мне вопрос, к сожалению.
    Есть какие-то варианты вывести кластер из этого состояния?

    Как определить, какая из двух активных нод действительно сломана?
    Размер edb идентичен.
    Логи циркулярные, на одной 8000 логов со вчера, на другой 250.
    1 ноября 2018 г. 5:45
  • День добрый.

    Что делать? Включить DAC mode.

    Exchange Best Practices: Datacenter Activation Coordination Mode

    Split Brain Syndrom: DAG switching between nodes

    Потом из оставшегося off line востанавливать DB и mailbox.


    MCITP, MCSE. Regards, Oleg

    2 ноября 2018 г. 17:51
    Модератор
  • Не ко мне вопрос, к сожалению.
    Есть какие-то варианты вывести кластер из этого состояния?

    Как определить, какая из двух активных нод действительно сломана?
    Размер edb идентичен.
    Логи циркулярные, на одной 8000 логов со вчера, на другой 250.

    Во-первых, из какого такого состояния кластер надо выводить? Вы же пишете, что сейчас кластер у вас в норме. Что касается потерянных сообщений, то они, скорее всего, потеряны навсегда: вероятно их доставка шла в ту копию базы, которая после решения проблемы стала пассивной и синхронизовалась по этому поводу с активной копией, с потерей этих сообщений.

    Почему это произошло? Мне это видится таким образом. Из практического опыта: при создании снимка VM для бэкапа VMWare может "подморозить" ВМ на время больше минуты. Чего вполне достаточно для того, чтобы второй узел кластера посчитал эту ВМ неработоспособной и забрал на себя первичную группу вместе с кластерным IP, в результате чего копия Active Manager на нем стала активной и смонтировала на нем копии баз как активные. А после окончания заморозки первый узел, ничего не зная о ней, так и продолжал считать себя активным - владельцем имени и IP кластера (первичной группы ресурсов), местом размещения активной копии Active Manager и активных копий баз. А вот почему это состояние сохранилось долго - это мне не понятно.

    Какую из активных копий считать правильной? Скорее всего - никакую: доставка сообщений идет непредсказуемо в разные копии (по выбору HT), и, скорее всего, та или иная часть сообщений будет потеряна. Можно, конечно, попытаться остановить службу транспорта, проанализировать Message Tracking на предмет куда делалась доставка и выбрать "лучшую" копию. Но, скорее всего, приоритетность восстановления работоспособности сервиса вам не позволит терять время на это.

    Что делать? Не копировать виртуальные серверы Exchange с помощью Veaam, никогда. DAC, если я правильно понял причину, в вашем случае не поможет - этот механизм срабатывает в момент запуска сервера/службы хранилища, и, а у вас служба хранилища вместе с сервером продолжала работу - только небольшой перерыв был.


    Слава России!



    3 ноября 2018 г. 7:33