在最近的測試中，大致上都相當順利(不管是X86 or X64版)，Win2008除了底層架構更為模組化，效能表現更加突出之外(這在UI上感受不到)，最明顯感受到的差異就是管理介面的改變，不過對於用習慣Vista Business的人來說，應該會比較容易上手(若是Vista Home Premium以下，則還是有相當的差異，就像WinXP vs. Win2003的差異一樣)。
廢話不多說，以下是最general的設定步驟（這些步驟會將安全性原則設定到最寬鬆的狀態，實際上還是應該經過測試，開放最小限度的安全設定即可）：
- 確認 AP Server 以及 DB Server 上的 Distributed Transaction Coordinator 服務都有開。
除了透過「系統管理工具」-->「服務」的 GUI 來啟動 DTC 服務之外，也可以在 command prompt 中用「net stop msdtc」和「net start msdtc」來啟動/停止 DTC 服務。
- 確認 AP Server 與 DB Server 間能互相以 NetBIOS / DNS 的方式來解析電腦名稱。
這裡的重點是一定要兩台 Server 間彼此互相都能解析，在 Win2008 上，預設會把 ping 所使用的 ICMP Protocol 關閉，可以在 command prompt 中執行「netsh firewall set icmpsetting 8」指令，或者從Firewall的Inbound Rules中，將「File and Printer Sharing (Echo Request – ICMPv4-In)」設定為Enabled。(參考資料)
- 調整關於 RPC 的安全性設定
DTC 必須使用RPC，因此需要設定相關的安全性設定。直接修改 Registry 的方式請參考這裡。
- 其他安全性設定（含允許網路 DTC）
(1)在Control Panel中，進入Component Services
(2)依序展開Computers > My Computer > Distributed Transaction Coordinator > Local DTC，檢視 Properties。參考下圖的設定。
(3)上途中在「Allow Inbound」和「Allow Outbound」下面的三個驗證選項，由於通常AP Server和DB Server會位於相同的Security Zone中，因此最寬鬆的設定是完全不要驗證，以免產生不必要的麻煩，相關安全性的問題應該在request進入AP Server前就處理好，或者在AP Server就把惡意的程式碼給擋下來，不要牽涉到DB Server。
根據實際經驗，如果 AP Server 和 DB Server 都位於相同的 AD Domain，那麼其實設定開啟驗證也不會有什麼問題。
最後一個「Enable XA Transactions」的選項就目前的情況也都可以不要允許，XA應該是另一套做 two-phase commit 的機制，不太熟 .... O.o
- Basic Windows Firewall Exception Program settings
(1)到Control Panel > Windows Firewall，點選左方的「Allow a program through Windows Firewall」連結，以設定 Exception Program:
(2)設定允許DTC和File and Printer Sharing（參考資料）:
- Advanced Windows Firewall Policy Settings
(1)在Control Panel > Administrative Tools 中，找到 Windows Firewall with Advanced Security:
![clip_image001[13]](http://lh3.ggpht.com/gooseegg123/SLv8wbzWEiI/AAAAAAAAADI/C-obM14cAqA/clip_image001%5B13%5D_thumb%5B3%5D.jpg?imgmax=800)
(2)展開「Inbound Rules」後，在中間的Rules詳細內容區塊中可以找到「Distributed Transaction Coordinator (RPC)」、「Distributed Transaction Coordinator (RPC-EPMAP)」、「Distributed Transaction Coordinator (TCP-In)」等規則，預設都是disabled的（灰色），把他們通通 Enable。
- 設定完畢之後，一定要利用DTC Tester來測試（更早以前還有一個DTC Ping工具，但是可能會產生false positive的結果，工具說通了，但實際就是不work），這個工具是利用ODBC來連線，在target DB Server上啟動一個分散式交易，建立一個temp table（只有一個欄位），然後塞入一筆亂數的資料，若是MSDTC有通的話，最後會要求你按一個鍵來commit transaction，如果看到志個訊息就表示「基本上」MSDTC的設定已經成功了！ (參考：如何使用 DTC Tester)
曾經公司有些SE到客戶端裝完機器，按照手冊設定好MSDTC之後，居然拿最基本的ping DNS和telnet來測試連線，然後反應說系統掛了，結果看exception的訊息很明顯就是MSDTC不通。總之重點就是，沒有用DTC tester這個工具來測試的話，一切都是假的，聽說還會有DTC Tester測試通過，但MSDTC還是無法正常運作的案例呢！（幸好我沒遇過）
好消息是微軟因為知道MSDTC這東西太難搞了，所以釋出一些測試工具，壞消息是這些工具在大部分的情況下只會吐出非常general的錯誤訊息（e.g. Invalid Cursor State），還有四個預設的安全性檢查建議，因此除非剛好看到非常明顯的錯誤訊息（例如MSDTC服務根本沒開），否則還是只能無奈的看著「Invalid Cursor State」，然後靠著Google瞎子摸象找解法了。
![clip_image001[13]](http://lh4.ggpht.com/gooseegg123/SLv8vcsz4wI/AAAAAAAAADE/NMPcxZwDKKU/s1600-h/clip_image001%5B13%5D%5B5%5D.jpg)
MSDTC這東西真的是很麻煩，常常發現出錯的時候，都會Google到新的scenario（OS Setting + MS Product + .NET Version + Firewall Setting + Registry Setting），可能出錯的狀況真的是有千百種，即使到了最新的LINQ or ADO.NET Entity Framework似乎也還是無法擺脫它（NHibernate / Spring 是怎麼弄的我就不清楚了）。
事實上，根據公司資深ASE的前輩的觀察，其實相當少的系統需要做到realtime的two-phase commit，大部分的系統做到near realtime就可以了，或者以Enterprise Application來講，配合DB Server的設定，可以做到高階主管(或者頂級尊爵客戶)看到的系統畫面是真的realtime，其他一般小職員或者普通user看到的系統畫面則是near realtime，delay個1分鐘其實都還不會怎樣的。（不過 ... 效能還是應該無所不用其極的盡量調校才對，效能好也是可以節能減碳的）在near realtime的情況下，可以用暫存table來自己處理two-phase commit，更可以精準的控制retry的機制，把critical的交易通通交給像MSDTC這樣的black box來處理，未必是最明智的作法。
Anyway，短期內還是必須要跟MSDTC這東西相處好一陣子，有空再把之前處理過的更詭異情況寫一下囉~~
沒有留言:
張貼留言