Biztalk üzerinde oluşabilecek MSDTC ve RPC hataları
Merhaba arkadaşlar,
BizTalk konfigürasyonu esnasında, BizTalk grubunu açarken veya yeni bir BizTalk host eklemeye çalışırken MSDTC ile ilgili hatalarla karşılaşabiliriz. Bu hatalardan bazıları aşağıdaki gibi olabilir:
Grup konfigürasyonu esnasında, konfigürasyon logundan alınan bir hata:
2012-12-24 16:55:18:0925 [ERR] WMI WMI error description is generated: Exception of type 'System.EnterpriseServices.TransactionProxyException' was thrown.
Bu hataya ilgili makalede değinilmekte. Yada yeni host eklerken alınan bir hata:
Yukarıda görünen MSDTC hataları ile Biztalk'un birden fazla server üzerine kurulduğu dağınık kurulumlarda karşılabilirsiniz. Bu hatalar can sıkıcı olabilir ve MSDTC iletişimi ile ilgili birşeylerin ters gittiğini gösterirler. MSDTC, BizTalk sunucusunun SQL sunucusuna erişirken sıklıkla kullandığı bir iletişim protokolüdür. Bu yazımda bu tip problemler ile karşılaşıldığında, öncelikle hangi ayarların kontrol edileceği ve sorunun giderilemediği durumda analiz için hangi yöntemlerin kullanılabileceğine değineceğim. Öncelikle şunu belirtmek istiyorum: Dağınık bir Biztalk kurulumunda kullanılacak Biztalk kullanıcıları ve grupları lokal olmak yerine Domain üzerinde tanımlanmalıdırlar. Bu makalede belirtildiği gibi desteklenen yöntem budur. Sonrasında MSDTC ile ilgili bir problemimiz var ise eğer aşağıdaki adımları takip edebiliriz. Bu adımlara tek tek değineceğim:
1. Local DTC ayarları doğru şekilde yapılmış mı? Firewall varsa port range belirtilmiş mi?
2. Öncelikle host isimleri doğru olarak resolve ediliyor mu? Biztalk ve SQL sunucuları birbirlerine ping atabiliyorlar mı?
3. Karşılıklı RPC iletişimine başlamak için 135 portu iki taraf içinde açıkmı? 135 port’u üzerinden Telnet çalıştırabiliyor muyuz?
4. DTC Ping ve DTC Tester ‘dan herhangi bir hata kodu alıyor muyuz?
5. Karşılıklı alacağımız network trace’lerde RPC EPM (End point mapper) aracılığı ile DTC server’dan bir port alabiliyor muyuz?
6. Eğer bundan da bir sonuç alamıyorsak MSDTC trace’i açabiliriz.
Herşeyden önce yapılması gereken, Local DTC (Distributed Transaction Coordinator) ayarlarının tüm dağınık sunucular üzerinden doğru şekilde yapılıp yapılmadığının kontrol edilmesidir. Bu ayarlar “Component Services” (dcomcnfg.exe) çalıştırıldığında soldaki görünümdeki “Computers”->”My Computer”->”Distributed Transaction Coordinator” klasörü altında “Local DTC” öğesine sağ tıklanıp “properties dediğimizde “Security” sekmesi altındadır. Konfigürasyonun aşağıda görüdüğü gibi olması gerekir:
Bu ayarlardan emin olduktan sonra eğer server’lar firewall arkasında ise firewall üzerinden belirli bir port aralığını kullanıma açarak MSDTC ‘yi bu aralığı kullanması için zorlayabilirsiniz. Her halukarda iletişimin başlayacağı 135 numaralı portun açık olması gerekmektedir.Bu ayarı yapmak için Component Configuration ("dmcomcnfg.exe") ekranında soldaki görünümdeki “Computers”->”My Computer” öğesine sağ tıklayıp “properties” diyoruz. Sonrasında “Default protocols” sekmesi altında, “connection-oriented TCP/IP” yi seçerek “properties” tuşuna tıklıyoruz. Bu ekranda aşağıdaki gibi “Add” diyerek port marjinini belirleyebilmekteyiz. Bu değişikliklerin tüm serverlar üzerinde yapılması gerekiyor. Ve değişikliklerin active olması için server’lar yeniden başlatılmalı.
Bu noktada DTC için gereken ayarları yapmış olduk. Bu adımlar ile ilgili daha detaylı bilgiyi bu makalede bulabilirsiniz. Peki, bu ayarları yapmanıza rağmen hala sorunlarla mı karşılaşıyorsunuz? Bu durumda problemin kaynağını saptamak için yapabileceğimiz adımlara geçebiliriz.
Öncelikle Biztalk server ve SQL server arasında sunucu isminden IP adresine yapılan çözümleme doğru şekilde yapılıyor mu, bunu öğrenmeye çalışabiliriz. Bunun için her iki server üzerinde “ipconfig”, “ping” , “nslookup” gibi komutları karşılıklı çalıştırıp iki server’ın birbirlerine erişimi var mı görmeliyiz.
c:\>ping mertSQL
Pinging mertSQL.microsoft.com [2001:4898:0:fff:0:5efe:10.165.2
6.82] with 32 bytes of data:
Reply from 2001:4898:0:fff:0:5efe:10.165.236.82: time=5ms
...
c:\>nslookup mertSQL
Server: ist-me-dc-40.microsoft.com
Address: 10.165.236.23
Name: mertSQL.microsoft.com
Addresses: 2001:4898:ff:fff:ff:5ffe:10.165.236.82
10.165.236.82
..
c:\>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection 4:
Connection-specific DNS Suffix . :microsoft.com
Link-local IPv6 Address . . . . . : fe80::2..
IPv4 Address. . . . . . . . . . . : 10.165.236.91
Subnet Mask . . . . . . . . . . . : 255.255.254.0
Default Gateway . . . . . . . . . : 10.165.236.1
...
Bu komutlar sıklıkla kullanılan komutlar olduğu için pek üzerinde durmayacağım. Eğer isim çözümlenmesinde bir problem yoksa, RPC iletişiminin başlaması için gerekli olan 135 portunun her iki taraftan da açık olup olmadığını öğrenmemiz gerekir. Bunun için ise SQL ve Biztalk sunucusu üzerinde diğer sunucuya 135 portundan telnet isteği göndermeyi deneyebiliriz:
C:\>telnet mertozSQL 135
Connecting To mertoz-3...
...
Her iki serverda da telnet üzerinden diğer server’a bağlantı kurulabiliyor olmalı. Eğer bu aşamada da sorun yoksa DTCPing ve DTCTester gibi tooları kullanarak RPC iletişiminde bir problem varmı bunlar saptanabilir.
DTCPing tool’u ile iki server arasında RPC iletişiminde bir sorun var mı bunu saptayabiliriz. Tool’u kullanmak için iki sunucu (Biztalk ve SQL) üzerinde aynı anda çalıştırıp, sonrasında her iki yönde sırası ile sunucu isimlerini girerek teste devam edebiliriz:
DTCPing eğer RPC protokolünde, isim çözümlemede yada herhangi bir başka noktada sorun mevcutsa bunu bize, örneğin; aşağıdaki gibi raporlayacaktır:
Problem:fail to invoke remote RPC method Error(0x6BA) at dtcping.cpp @303
-->RPC pinging exception -->1722(The RPC server is unavailable.)
RPC test failed
DTCPing ile ilgili daha detaylı bilgi edinmek , oluşacak problem tipleri ile ilgili bilgi edinmek isterseniz “Distributed Services Destek ekibinin” bu makalesini inceleyebilirsiniz. DTCPing’den de anlamlı bir hata çıkaramıyorsanız yada RPC iletişimi konusunda DTCPing “Success” mesajı veriyorsa şansınızı bir de DTCTester programı ile deneyebilirsiniz. DTCTester, sadece RPC iletişimini test etmekle kalmaz, bir transaction içerisinde SQL Sunucusunda geçici bir veritabanı tablosuna ekleme işlemi gerçekleştirip , ilgili “transaction” ı “commit” eder. Bu tool’u kullanmak için öncelikle “Data Sources (ODBC)” toolu ile (Start->Run->odbcad32.exe altından açabilirsiniz) bir data source tanımlamalıyız.
Sonrasında aşağıdaki gibi bu Data Source ismini ve kullanıcı ve Password’u vererek DTC ile ilgili test yapabiliyoruz.
C:\DTCTester>dtctester.exe mertoz-3Sql microsoft\mertozturk XXXXX
Executed: dtctester.exe
DSN: mertoz-3Sql
User Name: middleeast\a-meoztu
Password: XXXXX
tablename= #dtc1067
Creating Temp Table for Testing: #dtc1067
Warning: No Columns in Result Set From Executing: 'create table #dtc1067 (ival int)'
Initializing DTC
Beginning DTC Transaction
Enlisting Connection in Transaction
Error:
SQLSTATE=37000,Native error=8501,msg='[Microsoft][ODBC SQL Server Driver][SQL Server]MSDTC on server 'MERTOZ-3' is unavailable.'
Error:
SQLSTATE=24000,Native error=0,msg=[Microsoft][ODBC SQL Server Driver]Invalid cursor state
Typical Errors in DTC Output When
a. Firewall Has Ports Closed
-OR-
b. Bad WINS/DNS entries
-OR-
c. Misconfigured network
-OR-
d. Misconfigured SQL Server machine that has multiple netcards.
Aborting DTC Transaction
Releasing DTC Interface Pointers
Successfully Released pTransaction Pointer.
DTCTester kullanırken aşağıdaki portların açık olup olmadığınıda kontrol etmenizde fayda var:
135 -> RPC End point Mapper
1433 -> TCP IP üzerinden TDS SQL portu
1434 -> SQL 2000 Integrated Security
Ve son olarak MSDTC için ayırdığınız portlar.
DTCPing ve DTCTester uygulamalarından da sonuç alamıyorsanız, bu durumda her iki sunucu üzerinden karşılıklı “network trace” toplayabilir yahut DTC Trace’lerini iki taraflı olarak açabilirsiniz. Biraz detaya giriyor olacağım ama; “Network trace” lerini aldıktan sonra nasıl yorumlayacağınızla ilgili öncül bilgi vermek istiyorum:
Aşağıdaki örnekte Biztalk sunucundan SQL Sunucusuna yapılan bir isteği ele alalım. “Network Trace” aldıktan sonra öncelikle 135 numaralı porttan akan trafiği filtrelemeliyiz (tcp.port == 135) . Bu port MSDTC istemcisinin sunucuya yapılan ilk istekte kullandığı port numarasıdır. Bu port üzerinden yapılan iletişim sonrasında bir sonraki aşamada kullanılacak olan port bilgisi belirlenmektedir. Aşağıda öncelikle, TCP üzerinden yapılan 3 yönlü el sıkışma (“3 way hand shake”), daha sonra Bind işlemleri ve son olarak 2 tane RPC (“Remote Procedure Call”) EPM(“End Point Mapper”) protokol paketi görmeliyiz. Son pakette aşağıdaki gibi bir sonraki aşamada kullanılacak IP adresi ve Port istemciye bildiriliyor:
No. Time Delta Source Destination Protocol Length Info
11 2012-11-11 11:37:08.294322 0.000000 10.131.191.145 10.131.101.40 TCP 66 54267 > 135 [SYN] Seq=146951548 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
12 2012-11-11 11:37:08.295489 0.001167 10.131.101.40 10.131.191.145 TCP 66 135 > 54267 [SYN, ACK] Seq=532652788 Ack=146951549 Win=8192 Len=0 MSS=1380 WS=256 SACK_PERM=1
13 2012-11-11 11:37:08.295547 0.000058 10.131.191.145 10.131.101.40 TCP 54 54267 > 135 [ACK] Seq=146951549 Ack=532652789 Win=66048 Len=0
14 2012-11-11 11:37:08.353376 0.057829 10.131.191.145 10.131.101.40 DCERPC 170 Bind: call_id: 2 Fragment: Single, 2 context items: EPMv4 V3.0 (32bit NDR), EPMv4 V3.0 (bind time feature negotiation)
15 2012-11-11 11:37:08.354367 0.000991 10.131.101.40 10.131.191.145 DCERPC 138 Bind_ack: call_id: 2 Fragment: Single, max_xmit: 5840 max_recv: 5840, 2 results: Acceptance, Negotiate ACK
16 2012-11-11 11:37:08.354579 0.000212 10.131.191.145 10.131.101.40 EPM 210 Map request, 32bit NDR
17 2012-11-11 11:37:08.355031 0.000452 10.131.101.40 10.131.191.145 EPM 206 Map response, 32bit NDR
Floor 1 UUID: 75687379-aaaa-44f6-9512-080ac70f8ad9 Version 1.0
Floor 4 TCP Port:51531 à Server port
Floor 5 IP:10.131.101.40 à Server IP
IP adresi ve port belirlendikten sonra bu sefer bu portu filtrelemeliyiz. Çünkü iletişim bu port üzerinden devam edecek. (tcp.port == 51531). Bu sefer EPM paketleri görmeyeceğiz fakat tekrar RPC üzerinden bind işleminin yapıldığını görüyor olacağız:
No. Time Delta Source Destination Protocol Length Info
18 2012-11-11 11:37:08.356234 0.000000 10.131.191.145 10.131.101.40 TCP 66 54268 > 51531 [SYN] Seq=3370610530 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
19 2012-11-11 11:37:08.357326 0.001092 10.131.101.40 10.131.191.145 TCP 66 51531 > 54268 [SYN, ACK] Seq=403224645 Ack=3370610531 Win=8192 Len=0 MSS=1380 WS=256 SACK_PERM=1
20 2012-11-11 11:37:08.357378 0.000052 10.131.191.145 10.131.101.40 TCP 54 54268 > 51531 [ACK] Seq=3370610531 Ack=403224646 Win=66048 Len=0
21 2012-11-11 11:37:08.357466 0.000088 10.131.191.145 10.131.101.40 DCERPC 170 Bind: call_id: 2 Fragment: Single, 2 context items: 75687379-aaaa-44f6-9512-080ac70f8ad9 V1.0 (32bit NDR), 75687379-aaaa-44f6-9512-080ac70f8ad9 V1.0 (bind time feature negotiation)
22 2012-11-11 11:37:08.364683 0.007217 10.131.101.40 10.131.191.145 DCERPC 138 Bind_ack: call_id: 2 Fragment: Single, max_xmit: 5840 max_recv: 5840, 2 results: Acceptance, Negotiate ACK
23 2012-11-11 11:37:08.364905 0.000222 10.131.191.145 10.131.101.40 DCERPC 134 Request: call_id: 2 Fragment: Single opnum: 0 ctx_id: 0 75687379-aaaa-44f6-9512-080ac70f8ad9 V1
“Network Trace’lerinde yukarıda belirttiğim gibi bir akış görüyorsanız MSDTC RPC protokolünü düzgün bir şekilde işletmektedir diyebiliriz. RPC iletişimi hakkında destekleyici olması açısından bu blog'u da inceleyebilirsiniz.
Son olarak MSDTC problemlerinde daha da detaya inmek isterseniz MSDTC trace alarak devam edebilirsiniz. Vista işletim sistemi ile birlikte MSDTC trace yapısı da değişikliğe uğradı ve trace'ler formatlanmadan okunabilir şekilde alınabilmeye başlandı. Bunun için registry'de bir takım değişiklikler yapmak gerekiyor. Detayı bu makalede bulabilirsiniz. Bu makalede belirtilen değişiklieri hızlıca yapabilmeniz için aşağıda eklemiş olduğum VistaTracingMSDTC.rar dosyasında iki adet registry dosyası mevcut. Bu pakette "MSDTC Connection Manager", "MSDTC Trasnaction Manager - XATM" ve "MSDTC ETW" trace providerlarını herşeyi trace etmeleri için ayarlayacak (TRACE_EVERYTHING = 0xFF) registry import dosyası ve tüm provider'ları kapatacak registry Export dosyası bulunmakta. Bu konfigürasyon'u import etmeden önce "C:\traces " isimli klasörü yaratmanız gerekli. Tabiki klasör ismini de değiştirebilirsiniz.
MSDTCTraceVista_ON.reg -> Trace alınmasını başlatmak için
MSDTCTraceVista_OFF.reg -> Trace alınmasını durdurmak için.
Trace'lerin alınmaya başlaması için önce MSDTC servisini durdurup (net stop msdtc) sonra tekrar başlatmalıyız (net start msdtc). Trace alındıktan sonra herhangi bir formatlamaya gerek kalmadan trace dosyalarını inceleyip, hata detayını görmeye çalışabilirsiniz.
Peki Vista öncesi sistemler için nasıl trace alırız? Trace seviyesi gine "Component Services" (dcomcnfg.exe) ekranında, soldaki görünümdeki “Computers”->”My Computer”->”Distributed Transaction Coordinator” klasörü altında “Local DTC” öğesine sağ tıklanıp “properties dediğimizde “Tracing” sekmesi altındadır. (Vista da bu şekilde)
Burada Trace seviyesini belirleyip, Msdtc servisini yeniden başlattığımız zaman, "trace" dosyaları "c:\windows\system32\msdtc\trace" klasörü içerisinde görebilirsiniz. Fakat bu dosyalar okunabilir formata çevrilmelidir (önceki methodun aksine). Bu çevirim işlemi için aynı klasör içerisinde bulunuan msdtcvtr , batch dosyası kullanılmaktadır. Çevirim işlemi aşağıdaki komutla yapılabilir.
<msdtcvtr –tracelog <NameofTheDtcTrace.log> –o OutPutFile
Son olarak bu çevirim işlemi için, Platform SDK kurulumu ile gelen traceFmt.exe dosyasına da ihtiyacınız olacak. Bu trace metodu ile ilgili daha detaylı bilgi için bu makaleyi inceleyebilirsiniz.
Teşekkürler,
Mert Öztürk