ansle: Использование Dynamics CRM на NLB кластере

[Blog bot]

Источник: http://slepitsky.ru/blog/2008/11/27/...-nlb-klastere/
==============

Достаточно часто встречается задача обеспечить отказоустойчивую работу системы. И, если для базы данных применяется SQL кластер, то для обеспечения безотказной работы самого CRM сервера необходимо использовать т.н. NLB кластеры. Их особенность в том, что они могут обеспечить как балансировку нагрузки (когда запросы распределяются между различными серверами), так и отказоустойчивость. При этом, возможно управлять как нагрузка распределяется по серверам.
Благодаря статье установка CRM на кластер является достаточно простым делом. Но, как говорится, есть нюансы, из-за которых пришлось два дня разбираться с системой.
Пример (чисто для развлекательных целей ):
Есть NLB кластер, состоящий из 2-х серверов. Настройки NLB кластера такие, что все запросы обрабатываются ServerA (есть особенности стороннего ПО, что привело к желанию работать именно так). Все работает (пока). Теперь выполняем на ServerA команду iisreset. Что происходит? Если в момент рестарта пользователь зайдет на виртуальное имя кластера, то он обратится к ServerB. После успешного завершения выполнения команды все запросы опять будут поступать на ServerA. В моей системе в этом месте возникал сбой. Система выдавала ошибку 500 (а, если покопаться в логах, то и 401).

Что-то было неправильно с аутентификацией. Стал разбираться. Включил Kerberos логи:

476.568> Kerb-Warn: KerbVerifyPacSignature contacting domain (null) for user xxxxxxx
476.568> Kerb-Error: KDC failed to verify PAC signature: 0xc00002f5. d:\nt\ds\security\protocols\kerberos\client2\krbtoken.cxx, line 837
476.568> Kerb-Error: Pac signature did not verify: domain (null), status c00002f5
476.568> Kerb-Error: Failed to create token from ticket: 0xc00002f5. d:\nt\ds\security\protocols\kerberos\client2\ctxtapi.cxx, line 3889

Сразу стал грешить на SPN (ServicePrincipalName). Оказалось не зря. Нужно, чтобы на учетную запись, под которой работает CRM пул (и CRM Async service) были зарегистрированы следующие SPN:

HOST/VirtualName
HOST/VirtualName.FQDN
HTTP/VirtualName
HTTP/VirtualName.FQDN
HTTP/ServerA
HTTP/ServerA.FQDN
HTTP/ServerB
HTTP/ServerB.FQDN

И не больше! У меня было зарегистрировано еще 4 SPN (HOST для серверов-узлов кластера) что вызывало дублирование SPN (т.к. эти же SPN автоматически регистрируются для учетных записей самих серверов)

Чем редактировать AD? Можно утилитой SetSPN, можно консолью ADSIEdit - кому как удобней.

Ну все - завтра грядет маленький короткий отпуск. Питер ждет!

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



Источник: http://slepitsky.ru/blog/2008/11/27/...-nlb-klastere/