none
Репликация баз Exchange 2013 RRS feed

  • Вопрос

  • Доброго дня.

    Коллеги, хотелось бы послушать Ваши мысли.

    С недавнего времени столкнулся с проблемой.

    2 виртуальных сервера Exchnage 2013 на 2012R2, собраны в dag.Все сервера в одной сети (на серверах одна сетевая карточка для репликации БД и подключения клиентов), все в  одном ЦОДе.

    Периодически стала останавливаться  репликация баз  почтовых ящиков. 

    В ECP, c разделе с БД вижу следующие: 

    db01\ha-ex-01
    Пассивный Сбой и приостановка
    Длина очереди копирования: 4
    Состояние индекса содержимого: Приостановлено

    После возобновления репликации, данная ошибка повторяется рандомно через 1-2 дня. При попытке переключить БД на другой сервер, ломаются индексы БД. Помогает переиндексация БД. Обновлений не ставилось,в железе не чего не менялось, топология сети такая же как и была до появления ошибки. В логах не чего криминального не нашел. Кроме: 

    BlockMode replication for database 'db01' failed to initialize with the passive copy on 'ha-ex-01' : A timeout occurred while communicating with server 'ha-ex-01'. Error: "A connection could not be completed within 15 seconds."

    Но по поиску данной ошибки у людей лечится переиндексацией базы, мне же не помогло. 


    • Изменено Sharley2 25 ноября 2019 г. 9:57
    25 ноября 2019 г. 9:54

Ответы

  • Похоже на таймаут при обращении к диску с БД. Для дальнейшей диагностики:

    1. Посмотрите, было ли в это время что-то интересное на другом сервере DAG?

    2. Посмотрите в журнале событий Системы виртуального сервера, не было ли зафиксировано  каких-то ошибок с дисковой подсистемой в это время?

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

    4. Копия БД на ha-ex-01 в момент возникновения проблемы была активной или пассивной? Если она была активной, то БД успешно переехала на другой сервер, или как?

    5. Что за физический диск, на котором находится БД: LUN, отдаваемый с хранилки через SAN (и как именно - по FC или iSCSI), SATA/SAS или ещё что; проброшен ли диск в виртуалку напрямую или же на нем находится виртуальный диск? Если диск находится на хранилке SAN - не было ли там какой-то необычной нагрузки (мало ли что - например, база SQL, например, в это время бэкапилась)? А если это виртуальный диск - не делался ли в этот момент бэкап хоста?

    6. Ну, и эту самую Detailed Error интересно было бы увидеть: код ошибки часто бывает самой ценной информацией.


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

    26 ноября 2019 г. 3:34
  • Я бы, для начала, CU на серверах выровнял, чтобы чудес не было. Потому как имеющаяся у вас пара CU9-SP1(AKA CU4) имеет большую разбежку между версиями (больше года), и поэтому вряд ли тестировалась изготовителем на совместную работу.

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

    26 ноября 2019 г. 13:46

Все ответы

  • Без дополнительной информации вам помочь сложно.

    Журнал событий надо смотреть, прежде всего - Приложение (журнал событий Windows), во вторую очередь - журналы событий в папке Журналы служб и приложений/Microsoft/Exchange


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

    25 ноября 2019 г. 11:17
  • Добрый день! 

    Логи ниже. Но судя по ним понятно одно, что в какой то момент все становится плохо, однако что вызывает такое поведение мне не понятно.

    По ресурсам, у сервера большой запас, сторонние ПО которое могло как то влиять на работу отключено, либо удалено. 

    Если произвести переиндексацию БД, то проблема может не возникать 1-3 дней. Размер БД 16 Гб.

    1) BlockMode replication for database 'db01' failed to initialize with the passive copy on 'ha-ex-01' : A timeout occurred while communicating with server 'ha-ex-01'. Error: "A connection could not be completed within 15 seconds

    2) WorkflowLaunchReason: На '26.11.2019 6:03:04' в копии базы данных хранилища сервера Exchange 'db01' на этом сервере произошла ошибка конфигурации. Возможно, проблема вызвана сбоем в хранилище. Дополнительные сведения об этой ошибке см. в других событиях хранилища и "ExchangeStoreDb" в журнале событий на сервере. Служба восстановлена благодаря успешному переходу на другой ресурс.

    ExchangeStoreDB

    3) В "11/26/2019 6:47:46 AM" истекло время ожидания для копии базы данных хранилища Exchange "db01" на этом сервере при регулярной проверки состояния. Сбой попытки отработки отказа. Дополнительные сведения об этом сбое см. в журнале событий на сервере для других событий хранилища и "ExchangeStoreDb".4)На '11/26/2019 6:03:03 AM' копия базы данных 'db01' на этом сервере была неожиданно отключена. В результате перехода на другой ресурс была возвращена ошибка "Couldn't perform the database failover. Database: db01. Error: Microsoft.Exchange.Cluster.Replay.AmDbActionWrapperException: An Active Manager operation failed. Error: The database action failed. Error: An error occurred while trying to select a database copy for possible activation. Error: The database 'db01' was not mounted because errors occurred either while validating database copies for possible activation, or while attempting to activate another copy. Detailed error(s): 

    26 ноября 2019 г. 2:12
  • Похоже на таймаут при обращении к диску с БД. Для дальнейшей диагностики:

    1. Посмотрите, было ли в это время что-то интересное на другом сервере DAG?

    2. Посмотрите в журнале событий Системы виртуального сервера, не было ли зафиксировано  каких-то ошибок с дисковой подсистемой в это время?

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

    4. Копия БД на ha-ex-01 в момент возникновения проблемы была активной или пассивной? Если она была активной, то БД успешно переехала на другой сервер, или как?

    5. Что за физический диск, на котором находится БД: LUN, отдаваемый с хранилки через SAN (и как именно - по FC или iSCSI), SATA/SAS или ещё что; проброшен ли диск в виртуалку напрямую или же на нем находится виртуальный диск? Если диск находится на хранилке SAN - не было ли там какой-то необычной нагрузки (мало ли что - например, база SQL, например, в это время бэкапилась)? А если это виртуальный диск - не делался ли в этот момент бэкап хоста?

    6. Ну, и эту самую Detailed Error интересно было бы увидеть: код ошибки часто бывает самой ценной информацией.


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

    26 ноября 2019 г. 3:34
  • 1) Согласен, очень похоже на проблемы с дисковой подсистемой, это первое на что я подумал.

    Что бы исключить вариант с аппаратной проблемой сервера, перенес обе виртуалки, на 2 новых сервера на новых дисках 15К в RAID6. 

    Диски подключены локально. На каждом сервера по 2 диска - один для ОС, второй под БД.

    2) Обе БД всегда активны на ha-ex-01, т.к при попытке переключиться на ha-ex-02 сразу же ломаются полнотекстовые индексы, и БД не может корректно смонтироваться. 

    3) Проблема возникает рандомно, в любое время, днем бэкапы не снимаются. Перенес всю схему в тестовую среду, все находится на одном сервере. Сервера простаивают 100% всего времени, но и там эта ошибка повторяется.Поэтому, думаю что проблему с железом  можно исключить.

    4) В  Detailed Error говорится все тоже: 

    Ошибка на первой ноде (Она мастер, все базы активны на ней)

     Database copy 'db01 is in a Failed state on server 'ha-ex-02'. Reason: На '26.11.2019 6:03:04' в копии базы данных хранилища сервера Exchange 'db01' на этом сервере произошла ошибка конфигурации. Возможно, проблема вызвана сбоем в хранилище. Дополнительные сведения об этой ошибке см. в других событиях хранилища и "ExchangeStoreDb" в журнале событий на сервере. Служба восстановлена благодаря успешному переходу на другой ресурс.
    . If you need to activate this database copy, you can use the Move-ActiveMailboxDatabase cmdlet with the -SkipHealthChecks parameter to forcibly activate the database copy.

    Node1

    Node2

    Из различий между серверами, это версии CU. 

    node1- Version 15.0 ‎(Build 1104.5)‎

    node2 - Version 15.0 ‎(Build 847.32)‎

    Ну и думаю как вариант, создать новую БД и переместить пользователей в нее. Сначала на тесте проверю, потом на проде.

     
    26 ноября 2019 г. 9:41
  • Я бы, для начала, CU на серверах выровнял, чтобы чудес не было. Потому как имеющаяся у вас пара CU9-SP1(AKA CU4) имеет большую разбежку между версиями (больше года), и поэтому вряд ли тестировалась изготовителем на совместную работу.

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

    26 ноября 2019 г. 13:46
  • Согласен, это выполнить нужно. Но в том то и загвоздка. При обновлении сервер будет не доступен, а это означает простой сервиса, который я не могу себе позволить. А при переключении на slave ноду, все ломается.Таким вот это хозяйство досталось. 
    27 ноября 2019 г. 1:16