null

Методика тестирования Exchange DAG из двух узлов

16 января 2017 0 Maxim Zhukov

Предисловие

Конфигурация Exchange DAG стала де-факто стандартом при построении инфраструктуры почтового сервиса на решении Microsoft. В современных версиях Exchange "накликать" базы данных в конфигурацию DAG не занимает много времени, но для многих из ИТ-персонала, к сожалению, остается неясным поведение систем и почтового сервиса при тех или иных типовых возможных сценариях нештатного поведения системы (обслуживание, обрыв канала итд...). По этой причине, а так же по причине необходимости проверки корректности функционирования почтового сервиса и получения информации по времени отработки DAG(восстановление после сбоя) в конкретной инфраструктуре требуется проведение тестирования.

Информации в общем доступе по существующим практикам/методикам/способам тестирования стабильности и поведения баз данных в DAG найти не удалось, по этой причине разрабатывать описание тестовых сценариев пришлось самостоятельно. Предложенная методика является универсальной и масштабируемой для тех случаев, когда конфигурация DAG содержит большее количество узлов/датацентров. 

Предложенная методика указана для DAG распределенного в двух датацентрах. 

Описание окружения

1. SRVEXDB1 – Exchange 2016 DB+CAS server Primary Datacenter
2. SRVEXDB2– Exchange 2016 DB+CAS server Secondary Datacenter
3. SRVEXWN  - Withness SMB share in Primary Datacenter.
4. DB1 – mailbox database, primary SRVEXDB1 
5. DB2 – mailbox database, primary SRVEXDB2
6. CAS servers: Primary – SRVEXDB1
7. CAS servers: Secondary – SRVEXDB2

 

Методика тестирования

Приведенные сценарии с описанием шагов используемых при тестировании покрывают наиболее веротные случаи возможные в инфраструктуре. В случае, если конфигурация Вашего DAG более или менее сложная, часть сценариев можно не использовать а часть шагов легко изменяются в соответствии с реалиями инфраструктуры.

Использование изложенной методики позволяет:

  1. Проверить функционирование отказоустойчивости почтового сервиса на уровне баз данных почтовых ящиков при типовых сценариях.
  2. Выявить план действий и составить сопутствующие артефакты-инструкции для дальнейшего обслуживания почтового сервиса такие как "сценарий обновления","failover сценарий".
  3. Проверить возможность корректного восстановления.
  4. Произвести тестирование/обучение обслуживающего системы персонала.
  5. Выявить время требуемое для восстановления после сбоя RTO.

1. Сценарий планового обслуживания систем

Сопутствующие действия: составление сценария обновлений систем

  1. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  2. Проверка состояния компонент Test-ReplicationHealth
  3. Перевод SRVEXDB1  в maintenance mode StartDagServerMaintenance.ps1
  4. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  5. Проверка состояния компонент Test-ReplicationHealth
  6. Проверка доступности почтового ящиков через owa на каждом из доступных CAS серверов и через MAPI.
  7. Перезагрузка SRVEXDB1 
  8. Возвращение состояния SRVEXDB1  (п.3)  StopDagServerMaintenance.ps1
  9. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  10. Проверка состояния компонент Test-ReplicationHealth
  11. Перевод SRVEXDB2 в maintenance mode StartDagServerMaintenance.ps1
  12. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  13. Проверка состояния компонент Test-ReplicationHealth
  14. Проверка доступности почтового ящиков через owa на каждом из доступных CAS серверов и через MAPI. 
  15. Перезагрузка SRVEXDB2
  16. Возвращение состояния SRVEXDB2 (п.11)   StopDagServerMaintenance.ps1
  17. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  18. Проверка состояния компонент Test-ReplicationHealth
  19. Проверка доступности почтового ящиков через owa на каждом из доступных CAS серверов и через MAPI.

2. Сценарий обрыва канала связи между датацентрами

Ожидаемый результат при наступлении инцидента — автоматическая миграция копий баз данных с SRVEXDB1 активных ранее на SRVEXDB2
Сопутствующие действия: составление failover сценация
 
  1. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  2. Проверка состояния компонент Test-ReplicationHealth
  3. Открытие почтового ящика в DB2 через owa на каждом из доступных CAS серверов и через MAPI
  4. Отключение интерфейса на уровне гипервизора на SRVEXDB2 в Secondary Datacenter
  5. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus на обоих узлах почтового сервиса
  6. Проверка доступности почтового ящика из п.3 через owa на каждом из доступных CAS серверов и через MAPI.
  7. Перезагрузка SRVEXDB1.
  8. Проверка состояния  баз данных Get-MailboxDatabaseCopyStatus
  9. Восстановление связи между узлами (возвращение рабочего состояния п.4)
  10. Проверка состояния  баз данных Get-MailboxDatabaseCopyStatus
    В случае отсутствия восстановления состояния использовать Update-MailboxDatabaseCopy и Resume-MailboxDatabaseCopy
  11. Проверка доступности почтового ящика из п.3 через owa на каждом из доступных CAS серверов и через MAPI.

3. Сценарий выхода из строя сервера из Secondary Datacenter SRVEXDB2

Ожидаемый результат при наступлении инцидента —  автоматическая миграция копий баз данных с SRVEXDB1 активных ранее на SRVEXDB2
Сопутствующие действия: составление failover сценация, сценария обновлений систем
 
  1. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  2. Проверка состояния компонент Test-ReplicationHealth
  3. Создание резервной копии системы SRVEXDB2
  4. Открытие почтового ящика в DB2  через owa на каждом из доступных CAS серверов и через MAPI.
  5. Выполнение unexpected Shutdown на уровне гипервизора на SRVEXDB2 в Secondary Datacenter
  6. Проверка состояния Get-DatabaseAvailabilityGroupNetwork
  7. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus 
  8. Проверка доступности почтового ящика из п.3 через owa на каждом из доступных CAS серверов и через MAPI.
  9. Включение системы SRVEXDB2(возвращение рабочего состояния п. 5)
  10. Проверка состояния  баз данных Get-MailboxDatabaseCopyStatus.
  11. В случае отсутствия восстановления состояния использовать Update-MailboxDatabaseCopy и Resume-MailboxDatabaseCopy
  12. Ожидание автоматического превода активной копии базы данных DB2 на SRVEXDB2
  13. Проверка доступности почтового ящика из п.4 через owa на каждом из доступных CAS серверов и через MAPI.

4. Сценарий выхода из строя сервера из Primary Datacenter SRVEXDB1

Ожидаемый результат при наступлении инцидента —  автоматическая миграция копий баз данных с SRVEXDB2 активных ранее на SRVEXDB1
Сопутствующие действия: составление failover сценария, сценария обновлений систем
 
  1. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  2. Проверка состояния компонент Test-ReplicationHealth
  3. Создание резервной копии системы SRVEXDB1
  4. Открытие почтового ящика в DB1 через owa на каждом из доступных CAS серверов и через MAPI. 
  5. Выполнение unexpected Shutdown на уровне гипервизора на SRVEXDB1 в Primary Datacenter
  6. Проверка состояния Get-DatabaseAvailabilityGroupNetwork
  7. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus 
  8. Проверка доступности почтового ящика из п.3 через SRVEXDB2. 
  9. Включение системы SRVEXDB2(возвращение рабочего состояния п.5)
  10. Проверка состояния  баз данных Get-MailboxDatabaseCopyStatus
  11. В случае отсутствия восстановления состояния использовать Update-MailboxDatabaseCopy и Resume-MailboxDatabaseCopy
  12. Перевод активной копии базы данных DB1 на SRVEXDB1
  13. Проверка доступности почтового ящика из п.3 через owa на каждом из доступных CAS серверов и через MAPI. 

5. Сценарий выхода Primary Datacenter площадки из строя (не доступность сервера SRVEXDB1 п.3. и withness)

Ожидаемый результат при наступлении инцидента — не активность не активных баз данных на SRVEXDB2
Требуемые действия для восстановления работоспособности — ручная активация копий баз данных на SRVEXDB2
Сопутствующие действия: составление failover сценация
 
  1. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  2. Проверка состояния компонент Test-ReplicationHealth
  3. Создание резервной копии системы SRVEXDB1(проверка наличия актуальной резервной копии)
  4. Подготовка к настройке на firewall windows на SRVEXWN правила запрета всех подключений с SRVEXDB2 и подготовка к отключению SRVEXDB1
  5. Единовременное выполнение действий из п.4.
  6. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  7. Проверка состояния компонент Test-ReplicationHealth
  8. Проверка состояния Get-DatabaseAvailabilityGroupNetwork
  9. Проверка withness Get-DatabaseAvailabilityGroup
  10. Выполнение Restore-DatabaseAvailabilityGroup на  SRVEXDB2
  11. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  12. Проверка доступности почтовых ящиков через owa на каждом из доступных CAS серверов и через MAPI.
  13. Включение системы SRVEXDB1(возвращение рабочего состояния п.5)
  14. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus на SRVEXDB1
  15. Проверка состояния компонент Test-ReplicationHealth  SRVEXDB1
  16. Проверка состояния Get-DatabaseAvailabilityGroupNetwork  SRVEXDB1
  17. Отключение на firewall windows на SRVEXWN правила запрета всех подключений с SRVEXDB2  (возвращение рабочего состояния п.5)
  18. Проверка состояния Get-DatabaseAvailabilityGroupNetwork

6. Сценарий недоступности Withness и перезагрузки почтовых серверов 

Ожидаемый результат при наступлении инцидента — неработоспособность баз данных на рабочем почтовом сервере.
Требуемые действия для восстановления работоспособности — ручная активация копий баз данных на рабочем почтовом сервере
Сопутствующие действия: составление failover сценация
 
  1. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  2. Проверка состояния компонент Test-ReplicationHealth
  3. Подготовка и активация на firewall windows на SRVEXWN правила запрета всех подключений с SRVEXDB2.
  4. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  5. Подготовка и активация на firewall windows на SRVEXWNправила запрета всех подключений с SRVEXDB1.
  6. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  7. Проверка доступности почтовых ящиков в DB1 и DB2 через owa на каждом из доступных CAS серверов и через MAPI. 
  8. Отключение на firewall windows на SRVEXWN правила запрета всех подключений с SRVEXDB2 и SRVEXDB1  (п.3).
  9. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  10. Единовременная ктивация на firewall windows на SRVEXWN правила запрета всех подключений с SRVEXDB2 и SRVEXDB1.
  11. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  12. Перезагрузка SRVEXDB2
  13. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  14. Выполнение  Restore-DatabaseAvailabilityGroup для DB2 на SRVEXDB1
  15. Проверка доступности почтовых ящиков в DB2 через owa на каждом из доступных CAS серверов и через MAPI. 
  16. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  17. Перезагрузка SRVEXDB1
  18. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  19. Выполнение  Restore-DatabaseAvailabilityGroup для DB1 и DB2 на SRVEXDB2
  20. Проверка доступности почтовых ящиков в DB1 через owa на каждом из доступных CAS серверов и через MAPI. 
  21. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  22. Отключение на firewall windows на SRVEXWN правила запрета всех подключений с SRVEXDB2 и SRVEXDB1 (возвращение рабочего состояния п.11)
  23. Активация базы данных почтовых ящиков DB2 на SRVEXDB2

7. Сценарий удаления/порчи файлов баз данных в состоянии passive при failover

Ожидаемый результат при наступлении инцидента — corrupt data, невозможность failover
Требуемые действия для восстановления работоспособности — повторная репликация, восстановление баз данных
  1. Создание резервной копии системы SRVEXDB1 и SRVEXDB2 (проверка наличия актуальной резервной копии)
  2. Переименование файла D:\DB1\DB1.edb в D:\DB1\DB1.edb.old на SRVEXDB2
  3. Активация базы данных почтовых ящиков DB1 на SRVEXDB2
  4. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  5. Проверка состояния компонент Test-ReplicationHealth
  6. Повторная репликация копии DB1 Update-MailboxDatabaseCopy. Учёт времени.
  7. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus
  8. Активация базы данных почтовых ящиков DB1 на SRVEXDB2
  9. Сохранение копии файла D:\DB2\DB2.edb на SRVEXDB1.Порча файла D:\DB2\DB2.edb на SRVEXDB1 дописыванием информации в середину файла.
  10. Активация базы данных почтовых ящиков DB2 на SRVEXDB1
  11. Проверка состояния баз данных Get-MailboxDatabaseCopyStatus

8. Восстановление базы данных средствами используемого средства резервного копирования и восстановления

1. Выполнить восстановление  средствами используемого средства резервного копирования и восстановления базы данных DB2 ( D:\DB2\DB2.edb на SRVEXDB1) после выполнения сценария 7.

Дополнительная информация по поводу проведения проверки доступности.

На шаге "Проверка доступности почтового ящика из п.3 через owa на каждом из доступных CAS серверов и через MAPI" рекомендую проверять доступность через MAPI через разные сайты и сегменты сети в которых работают клиенты. Если имеется интеграция почтового сервиса с иными сервисами (например, office, S4B, sharepoint итд...), необходима проверка интеграции клиента с данными сервисами (как пример "Проверка интеграции с SFB через UM."). Непосредственные действия и соответствующие CheckList формируются исходя из требуемого покрытия в конкретной компании для данного сервиса.
 

Используемые командлеты

  1. Restore-DatabaseAvailabilityGroup

  2. Test-ReplicationHealth

  3. Get-DatabaseAvailabilityGroup

  4. Get-DatabaseAvailabilityGroupNetwork

  5. Resume-MailboxDatabaseCopy

  6. Update-MailboxDatabaseCopy

  7. Get-MailboxDatabaseCopyStatus

  8. Remove-MailboxDatabaseCopy

  9. StopDagServerMaintenance.ps1

  10. StartDagServerMaintenance.ps1

Ещё мои статьи по диагностике, оптимизации и решению проблем с Exchange Server

 

Мы имеем широкий опыт по настройкам, обслуживанию, поддержке, оптимизации ИТ инфраструктуры .

В компетенциях нашей команды ТЮН-ИТ технологии Microsoft, Oracle, vmWare, Huawei, Citrix, Cisco, Astra Linux и много open source продуктов (Xen & KVM based гипервизоры, Nix системы, сетевые технологии). 

Обращайтесь к нам как со сложными вопросами ИТ: мы открыты как для больших, так и малых проектов.