Зеркалирование Базы данных в Dynamics AX

«Знакома» ли служба AOS с зеркалом? Если да, что испытывает пользователь при аварийном переключении? Это два вопроса, которые я недавно получил от клиентов, которые планировали свое решение с отказоустойчивой БД.

Когда дело доходит до высоконадежной БД в Dynamics AX, кластер SQL – это наиболее часто используемая технология. В большинстве случаев, когда я видел зеркалирование БД, это использовалось обычно как решение для аварийного восстановления, чтобы обеспечить свежую копию БД во внешнем расположении, где установлена вся среда (SQL Server, AOS и т.п.) и она готова к использованию в случае отключения первичного дата центра.

Зеркалирование БД с автоматическим аварийным переключением не подходит под эту ситуацию. Вам потребуется реальный человек, принимающий решение в случае отказа перейти на другую среду в другом месторасположении. Однако вопрос от клиента был в том, чтобы использовать зеркалирование БД в кластере SQL, где службы AOS остаются те же, а только БД переходит с одного сервера на другой путем зеркалирования. В этом случае автоматическое аварийное переключение определенно было бы полезным.

Будет ли AOS подключен к БД после аварийного переключения на зеркальную БД, как это происходит в случае переключения кластера SQL. Или необходимо сделать изменения в конфигурации сервера Dynamics AX и перезапустить AOS, чтобы подключить его после переключения? После небольших поисков я понял, что документации как это работает явно недостаточно. Так что я решил, неплохо бы установить и проверить. И вот что я сделал.

Тестовая Конфигурация

Моей отправной точкой для тестирования была полностью рабочая цельная среда Dynamics AX на виртуальной машине. Вот информация по версиям ключевых компонентов:

• Windows Server 2008 R2
• SQL Server 2008 SP2
• Dynamics AX 2009 SP1 RU6

1. Далее я установил второй экземпляр SQL на тот же сервер для размещения зеркальной БД. Я назвал этот экземпляр MIR. Важно, чтобы обе SQL были точно одинаковой версии.
2. Перед установкой зеркалирования БД между двумя экземплярами нужно переключить модель восстановления для БД AX на «Полная».
3. Выполните полное резервирование БД AX и восстановите на вновь установленном экземпляре сервера SQL MIR. Должна быть развернута полная резервная копия, так что журналы транзакций по-прежнему могут фиксироваться. Поэтому нужно воспользоваться восстановлением с опцией NO RECOVERY (без восстановления)
4. После того, как на SQL MIR БД будет развернута, нужно создать логин SQL сервера для AOS. Этот логин должен быть одинаковый на обоих серверах SQL, чтобы AOS мог подключиться к любому настроенному как основному. В большинстве случаев это вероятно будет учетная запись доменной службы. В моем случае я просто воспользовался NT AUTHORITY\NETWORK SERVICE. Логины прописаны на уровне сервера SQL, так что они не переходят вместе с восстановлением БД или через процесс зеркалирования. Поэтому придется сделать это вручную.
5. Настройте зеркалирование между двумя БД. При этом я воспользовался опцией «защищенный без автоматического перехода».
6. Подождите, пока БД полностью не синхронизируются.
7. Запустите или перезапустите AOS, чтобы инициировать подключение к основной БД после окончания настройки зеркалирования.
8. Запустите сессию клиента AX и проверьте, что клиент работает при подключении к основной БД.
9. Вручную инициируйте переключение так, чтобы теперь зеркальная БД стала основной, а основная БД стала зеркалом.

Результаты Теста / Заключения:

1. Переключение с основной БД на зеркальную занимает около 40 секунд. Я считал переключение завершенным, когда монитор зеркалирования БД показал, что основная и зеркальная БД снова синхронизированы.
2. Сессия клиента AX, которую я оставил запущенной во время переключения, перестала отвечать и вывела сообщение в инфолог, что БД не доступна. Клиент был в таком состоянии около 50 секунд пока не восстановился, и я не смог продолжить снова работать. Не потребовалось никакого вмешательства, только немного терпения. Я переключался туда и обратно три раза. Переключения были довольно постоянны.
3. Если сервис AOS остановлен при активном зеркалировании, сервис запустится снова только, если SQL сервер выступает в качестве основного, как прописано в утилите для настройки AX Server. Информация о подключении (основное/зеркальное) доступна только AOS через SQL сервер и кэшируется, когда сервис AOS онлайн. Из-за того, что зеркала – недоступны, AOS может достать эту информацию только с основного. Это нужно держать в уме при рассмотрении этого решения.
4. Важно отметить, что это все сделано на простой виртуальной машине с ограниченными ресурсами, а также, что не было запущено ни одной транзакции во время тестирования. Цель этого теста – оценить функциональность, а не замерить масштабируемость решения или определить время аварийного переключения в реальных условиях.
5. Автоматическое переключение с сервером-свидетелем прямо здесь не проверяли, но разумно предположить, что со стороны Dynamics AX вряд ли будут какие либо отличия в результатах. AOS не в курсе и поэтому ему все равно как стартовало аварийного переключение (вручную или автоматически)
6. По результатам этого теста зеркалирование БД – определенно жизнеспособный вариант для БД Dynamics AX с высокой отказоустойчивостью.
   

Ссылки:

Синхронное зеркалирование БД (защищенный режим)): http://msdn.microsoft.com/en-us/library/ms179344.aspx КАК: Подготовить зеркальную БД для зеркалирования: http://msdn.microsoft.com/en-us/library/ms189047.aspx

КАК: Настроить сессию зеркалирования БД: http://msdn.microsoft.com/en-us/library/ms188712.aspx

КАК: Вручную переключить на сессию зеркалирования БД: http://msdn.microsoft.com/en-us/library/ms186348.aspx

Переподключение к сессии зеркалирования БД: http://msdn.microsoft.com/en-us/library/ms366199.aspx

Рассмотрение производительности и лучших примеров зеркалирования БД: http://technet.microsoft.com/en-us/library/cc917681.aspx