У нас возникла проблема на одном из узлов нашей производственной базы данных, из-за которой он переключился на другой. Это вызвало кратковременный сбой во время работы службы. Однако этого временного сбоя было достаточно, чтобы вызвать сбой некоторых серверов AOS (т.е. службы все еще отображались как работающие, но мы не могли подключиться к ним через AX, пока не перезапустили службы AOS).
NB: файлы наших приложений также размещены в нашем кластере SQL (на отдельном диске), идея заключается в том, что вместо того, чтобы полагаться на один общий ресурс для хранения этих файлов, у нас есть файлы в кластеризованном общем ресурсе, так что если сервер (узел ) размещение файлов не выполняется, они все еще могут быть доступны. Я указываю на это, поскольку причиной проблемы могла быть кратковременная потеря связи с этими файлами, а не /, а также потеря соединения с БД. Мы играли с идеей о том, чтобы каждый сервер AOS содержал копию файлов приложения локально (т.е. чтобы, если один AOS выйдет из строя, мы потеряем только этот; другие не затронуты потерей его копии файлов приложения) , но ряд консультантов посоветовал этого не делать, цитируя передовой опыт MS.
Однако похоже, что временный сбой подключения должен вызвать такую проблему; Я ожидал, что ошибка будет просто обнаружена, и AX попытается повторно подключиться к этим ресурсам, пока соединение не будет восстановлено.
Кто-нибудь знает об исправлении этой проблемы? Кто-нибудь еще имел эту проблему и разработал обходной путь?
Заранее спасибо.
К вашему сведению: мы решили проблему, разместив копии файлов приложения на каждом AOS. Рекомендации против этого сводились к модулю (Конструктору продуктов), требующему общего доступа к файлам. Однако этот модуль нами не использовался, поэтому было безопасно хранить отдельную копию для каждого AOS. После внесения изменений у нас не было связанных проблем, и наша архитектура стала более надежной. Единственный недостаток - копирование файлов приложения при развертывании занимает еще пару минут; что не ужасно.