Ошибка распределенной транзакции в Windows Server 2008
У меня проблема с новой настройкой сервера. Распределенные транзакции, запущенные сервером приложений на новый сервер, не выполняются, но они отлично работают с существующим сервером базы данных. Мне нужна помощь в определении причины проблемы.
По разным причинам на новом сервере не установлены последние версии Windows или SQL Server.
Настроить
СЕРВЕР ПРИЛОЖЕНИЙ
- ОС: Windows Server 2008 R2
- Имя NetBIOS: WEB-02
- Настроен для связи с несколькими серверами баз данных, некоторые локальные, некоторые удаленные.
- Порты DCOM ограничены диапазоном 5000-5020 для связи через брандмауэр с удаленными серверами.
- Брандмауэр Windows включен
- DTC Свойства
- Доступ к сети DTC проверен
- Разрешить удаленных клиентов, Разрешить удаленное администрирование снят
- Менеджер транзакций
- Флажок Разрешить входящий, Разрешить исходящий
- Аутентификация не требуется
- Включить транзакции XA не проверено
- Включить SNA LU 6.2 Транзакции проверены
НОВАЯ БАЗА ДАННЫХ
- ОС: Windows Server 2008
- Имя NetBIOS: DB-06
- SQL Server 2005
- Нет ограничений на порты DCOM
- Брандмауэр Windows отключен
- DTC Свойства
- Доступ к сети DTC проверен
- Не разрешать удаленные клиенты,
- Разрешить удаленное администрирование проверено
- Менеджер транзакций
- Флажок Разрешить входящий, Разрешить исходящий
- Аутентификация не требуется
- Включить транзакции XA не проверено
- "Включить транзакции SNA LU 6.2" не существует
СУЩЕСТВУЮЩИЙ БАЗА ДАННЫХ
- ОС: Windows Server 2003 R2
- Имя NetBIOS: DB-04
- SQL Server 2005
- Нет ограничений на порты DCOM
- Брандмауэр Windows отключен
- DTC Свойства
- Доступ к сети DTC проверен
- Не разрешать удаленные клиенты,
- Разрешить удаленное администрирование проверено
- Менеджер транзакций
- Флажок Разрешить входящий, Разрешить исходящий
- Аутентификация не требуется
- Включить транзакции XA не проверено
- "Включить транзакции SNA LU 6.2" не существует
Все три сервера являются частью одного домена и находятся в одной подсети. Между ними находится только коммутатор 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 доступных портов.
1 ответ
После того, как 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