У меня проблема с настройкой нового сервера. Распределенные транзакции, запущенные сервером приложений на новый сервер, завершаются ошибкой, но они нормально работают с существующим сервером базы данных. Мне нужна помощь в определении причины проблемы.
По разным причинам на новом сервере не установлены последние версии Windows или SQL Server.
СЕРВЕР ПРИЛОЖЕНИЙ
НОВЫЙ СЕРВЕР БАЗ ДАННЫХ
СУЩЕСТВУЮЩИЙ СЕРВЕР БАЗЫ ДАННЫХ
Все три сервера являются частью одного домена и находятся в одной подсети. Между ними только коммутатор Ethernet, без маршрутизатора, аппаратного межсетевого экрана или устройства безопасности.
Приложение ASP.NET работает на сервере приложений и правильно работает при выполнении транзакции с существующим сервером базы данных (DB-04). При выполнении тех же действий с новым сервером базы данных (DB-06) он дает сбой и сообщает об ошибке: Communication with the underlying transaction manager has failed.
Мы уже сталкивались с этой ошибкой в этом приложении, и обычно это означает, что координатор распределенных транзакций настроен неправильно или мешает межсетевой экран. В прошлом я использовал DTCPing для поиска и исправления ошибок.
Однако на этот раз, хотя DTCPing не работает, я не могу определить причину проблемы, так как существующие и новые серверы баз данных настроены одинаково, за исключением версии ОС.
Следующее - из файла журнала DTCPing при запуске теста с сервера приложений (WEB-02) на новый сервер базы данных (DB-06). Обратите внимание, что я изменил IP-адреса и DNS-имена.
Из файла журнала на сервере приложений
10-14, 16:08:11.346-->Error(0x424) at clutil.cpp @256
10-14, 16:08:11.346-->-->OpenCluster
10-14, 16:08:11.346-->-->1060(The specified service does not exist as an installed service.)
++++++++++++++++++++++++++++++++++++++++++++++
DTCping 1.9 Report for WEB-02
++++++++++++++++++++++++++++++++++++++++++++++
Firewall Port Settings:
Port:5000-5020
RPC server is ready
++++++++++++Validating Remote Computer Name++++++++++++
10-14, 16:08:22.796-->Start DTC connection test
Name Resolution:
DB-06-->1.1.1.6-->s6.mydomain.com
10-14, 16:08:22.812-->Start RPC test (WEB-02-->DB-06)
RPC test failed
Из файла журнала на новом сервере базы данных
10-14, 16:07:46.128-->Error(0x424) at clutil.cpp @256
10-14, 16:07:46.128-->-->OpenCluster
10-14, 16:07:46.129-->-->1060(The specified service does not exist as an installed service.)
++++++++++++++++++++++++++++++++++++++++++++++
DTCping 1.9 Report for DB-06
++++++++++++++++++++++++++++++++++++++++++++++
RPC server is ready
10-14, 16:08:22.785-->RPC server:DB-06 received following information:
Network Name: DB-06
Source Port: 56535
Partner LOG: WEB-022872.log
Partner CID: 1ACD8780-9446-4E94-869D-6F1BDF787BBF
После нажатия кнопки PING на сервере базы данных в файл журнала добавляется следующее. В окне вывода есть пауза между вызовом метода RPC и его ошибкой, поэтому он не выполняется по истечении тайм-аута.
++++++++++++Validating Remote Computer Name++++++++++++
10-14, 16:13:18.924-->Start DTC connection test
Name Resolution:
Web-02-->1.1.1.2-->web-02.mydomain.com
10-14, 16:13:18.933-->Start RPC test (DB-06-->Web-02)
Problem:fail to invoke remote RPC method
Error(0x6D9) at dtcping.cpp @303
-->RPC pinging exception
-->1753(There are no more endpoints available from the endpoint mapper.)
RPC test failed
Как объяснено в Устранение неполадок MSDTC с помощью инструмента DTCPing в разделе «СООБЩЕНИЕ ОБ ОШИБКЕ 4 - больше нет конечных точек от сопоставителя конечных точек», на самом деле конечных точек для сопоставителя больше нет. Я бежал netstat -an на сервере приложений (с ограниченными портами) и использует только 10 из 20 доступных портов.
После привлечения Microsoft и проведения и анализа множества трассировок сети мы наконец-то обнаружили проблему. Сервер приложений был частью кластера балансировки сетевой нагрузки, и есть изъян в том, как реализация IPv6 в Windows Server 2008 R2 взаимодействует с компонентом балансировки сетевой нагрузки.
Поскольку серверы имели общедоступные IPv4-адреса, стек IPv6 автоматически создавал адрес «6to4». Это специальный адрес IPv6, который соответствует общедоступному адресу IPv4 машины. Это было сделано как для собственного адреса машины, так и для общего адреса кластера. Ошибка в том, что затем он зарегистрировал обе 6to4 адресов в DNS под своим своя название. Это отличается от того, как стек IPv4 работает на той же машине. В IPv4 IP-адрес кластера не регистрируется в DNS.
В результате, когда сервер приложений, подключенный к новому серверу базы данных, и сервер базы данных попытались выполнить обратную привязку к серверу приложений, он обнаружил, что для сервера приложений были адреса IPv6, и попытался подключиться, используя один из этих адресов. . Но поскольку он использовал адрес 6to4, соответствующий кластер IP-адрес, другой сервер в кластере получит соединение и, поскольку DTC включен этот сервер не ожидал обратной связи, это не удалось.
Существующий сервер базы данных, являющийся Windows Server 2003 R2, не использовал IPv6 и поэтому не столкнулся с проблемой.
В решение было отключить автоматическое создание адресов 6to4. Вы можете сделать это с помощью групповой политики или с помощью следующей командной строки:
netsh interface 6to4 set state disabled
Чтобы вернуть его обратно, вы должны выполнить следующую команду:
netsh interface 6to4 set state default
Чтобы увидеть текущие настройки, выполните следующую команду. В Windows 2008 R2 / Windows 7 и более поздних версиях также будет указано, вызван ли текущий параметр групповой политикой.
netsh interface 6to4 show state