Главная Exchange/UC, Без рубрики, Новое Exchange 2010 DAG: Процесс выбора оптимальной реплики базы.
  • Exchange 2010 DAG: Процесс выбора оптимальной реплики базы.

    logoТе, кто работают с Exchange 2010 должны знать, что обеспечение высокой доступности баз данных почтовых ящиков реализуется технологией DAG. (database availability group) Суть технологии в создании двух и более реплик одной базы на разных Mailbox серверах. В случае падения диска или сервера, одна из оставшихся реплик становится активной и продолжает обслуживать клиентов. Причем количество реплик может достигать 16 штук. Все это понятно и несложно, а меня волнует немного другой вопрос. Как осуществляется выбор реплики которая должна стать активной в случае падения диска или сервера? Если у нас 3-16 реплик, как понять какая из реплик станет активной?

    Exchange Server 2010 содержит новый компонент Active Manager в задачу которого  входит отработка отказов и выбор лучшей реплики. Active Manager работает на всех серверах почтовых ящиков. Задача “Active Manager” выбрать с одной стороны рабочую реплику, с другой наиболее актуальную по отношению к упавшей, дабы избежать или минимизировать потерю информации.

    1. Active Manager обнаруживает сбой и  запускает алгоритм выбора оптимальной копии (BCS).

    2. Строится список всех  всех реплик  упавшей базы.

    3. Из списка выбрасываются те реплики, доступ к которым не удалось подключиться. (например недоступны сервера, несущие реплику)

    4. Из списка выбрасываются реплики расположенные на серверах с параметром  “DatabaseCopyAutoActivationPolicy” запрещающим активацию. Этот параметр  задается на уровне сервера и определяет разрешена ли  автоматическая активация копий базы данных почтовых ящиков на конкретном Mailbox сервере. По-умолчанию установлен в “Unrestricted”, но может иметь и значение “Blocked” при котором  автоматическая активация баз данных на выбранных сервере невозможна.

    Capture1

    5. Список реплик сортируется по  значению "Сopy queue length ". Это количество не скопированных транзакционных логов. Расчет выполняется на основе параметра “LastLogInspected” указывающем время обработки последнего полученного транзакционного лога.

    Capture2

    6. Список реплик сортируется  по параметру "ActivationPreference" в качестве вторичного ключа. Копия с минимальным значением ActivationPreference имеет наивысший приоритет в списке. ActivationPreference — это значение устанавливаемое администратором, которое равно или больше 1, где 1 означает самый высокий приоритет. Номер позиции не может быть больше числа копий базы данных почтовых ящиков. Т.е такой “попугай”, которым администратор может сказать, что Реплика А более приоритетна чем Реплика  B.

    Capture3

    7. Отбираются реплики находящиеся  в одном из следующих состояний “Healthy, DisconnectedAndHealthy”, “DisconnectedAndResynchronizing”, “SeedingSource”.

    Healthy (исправно) Копия базы данных почтовых ящиков успешно копирует и проигрывает транзакционные логи, или она уже успешно скопировала и преобразовала все доступные транзакционные логи.

    DisconnectedAndHealthy (отключено и исправно) Копия базы данных почтовых ящиков больше не синхронизируется с  активной копией базы данных, но во время потери подключения она находилась в исправном состоянии. Такое состояние может быть получено при сбоях сети между репликами  базы данных.
     

    DisconnectedAndResynchronizing (отключение и повторная синхронизация) Копия базы данных почтовых ящиков больше не синхронизируется с активной копией базы данных, но во время потери подключения она находилась в состоянии повторной синхронизации. Такое состояние так же может быть получено при сбоях сети между репликами базы данных.
     

    SeedingSource (источник заполнения) Копия базы данных почтовых ящиков используется как источник для актуализации других баз данных.

    Active Manager  идет по списку и ищет реплику с индексом базы в состоянии "Health " и c параметром  "copy queue length" меньше 10, а "replay queue length" меньше 50. Если такую реплику находит то выполняет ее монтирование и процесс выбора копии останавливается.

    Copy Queue Length – это количество транзакционных логов, которые должны быть скопированы на сервер для актуализации конкретной реплики базы.

    Replay Queue Length – это количество транзакционных логов, которые необходимо проиграть для актуализации конкретной реплики базы.

    Индекс  в состоянии "Health " означает, что база уже проиндексирована.

     

    8. Active Manager идет по списку и ищет реплику с индексом базы в состоянии "Crawling" c параметром "copy queue length" меньше 10, а "replay queue length" меньше 50. Если находит монтирует. Индекс в состоянии "Crawling" означает, что база индексируется в данный момент.  Естественно индексирование операция “дорогая” с точки зрения ресурсов, поэтому вначале ищутся базы с готовым индексом.

     

    9. Active Manager идет по списку и ищет реплику с индексом базы в состоянии "Health " c параметром  "replay queue length" меньше 50. Если такую реплику находит то выполняет ее монтирование и процесс выбора копии останавливается.

    10. Active Manager идет по списку и ищет реплику с индексом базы в состоянии "Crawling" c параметром "replay queue length" меньше 50. Если такую реплику находит то выполняет ее монтирование и процесс выбора копии останавливается.

    11. Active Manager идет по списку и ищет реплику с любым статусом индекса базы и параметром "replay queue length" меньше 50. Если такую реплику находит то выполняет ее монтирование и процесс выбора копии останавливается.

    12. Active Manager идет по списку и ищет реплику с индексом базы в состоянии "Health " c параметром "copy queue length" меньше 10. Если такую реплику находит то выполняет ее монтирование и процесс выбора копии останавливается.

    13. Active Manager идет по списку и ищет реплику с индексом базы в состоянии "Crawling" c параметром "copy queue length" меньше 10. Если такую реплику находит то выполняет ее монтирование и процесс выбора копии останавливается.

    14. Active Manager идет по списку и ищет любую реплику с индексом базы в состоянии "Health”. Если такую реплику находит то выполняет ее монтирование и процесс выбора копии останавливается.

    15. Active Manager идет по списку и ищет любую реплику с индексом базы в состоянии "Crawling”. Если такую реплику находит то выполняет ее монтирование и процесс выбора копии останавливается.

    Если ни одна копия базы данных не отвечает набору условий, Active Manager пытается активировать любую копию базы данных в состоянии Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing или SeedingSource . Если такой копии не удается найти, автоматическая активация копии базы данных невозможна.

    Capture4Для разминки мозгов откройте крупно изображение выше и ответьте на вопрос: “Какая из трех реплик изображенных на картинке будет выбрана службой Active Manager для монтирования?”. Конспект делал для себя, если найдете ошибку, дайте знать в комментариях.

    MCT/MVP Илья Рудь

Комментарии

  1. Илья, а это случайно не Скота Шноля доклад в очень кратком изложении :-).

    Спасибо за статьб на русском. Напищите еще про то, как переключать PAM.

  2. Это два часа чтения справки CHM по Exchange и попытка сделать так, чтобы было алгоритмично и понятно. Со Скотом Шноля увы не знаком.

  3. В продолжение темы выбора оптимальной копии базы и PAM. http://technet.microsoft.com/ru-ru/library/dd776123.aspx
    Опирайтесь на первоисточники, так как изминенния вносимые обновлниями, могут повлиять на работоспособность системы.

  4. У первоисточников есть один большой недостаток – когда их пишут, не ставят задачу “что бы было понятно”.

  5. Перевод статьи technet. Но можно же и больше. Поскольку, есть в этой статье один нюансик. Связан он с работой алгоритма в SP1, когда в качестве первичного ключа (для сортировки результата) используется ActivationPreferense (при mount dial = lossless). Этот момент очень скользкий в этой статье и, наверное, самый непонятный. Вы его, видимо, при переводе и чтении, не смогли понять и просто забили (наверно знаний и опыта работы с Exchange не хватает). Второе, что хотелось бы отметить: вы не указали причины работы алгоритмы. То есть. Зачем он так делает? Материал по Exchange не такой уж и трудный, чтобы делать такие предположения. Поэтому статью оцениваю на троечку.

  6. @2 “Со Скотом Шноля увы не знаком.”

    http://www.techdays.ru/videos/3936.html

  7. Это алгоритм для Exchange Server 2010 RTM. В Service Pack 1 изменен пункт 5: “При использовании значения Lossless Active Manager сортирует итоговый список в порядке возрастания, используя в качестве первичного ключа значение параметра ActivationPreference”.

    http://technet.microsoft.com/ru-ru/library/dd776123.aspx

    Прикольно, как они переводят RTM: “В окончательной первоначальной версии (RTM) …” 🙂