Domino 集群跨數據中心互訪故障

北京 藍鵬

月初OA 系統運維人員接到大量故障問題申報單，內容主要集中在部分兼職領導和大批整合子、分公司用戶在使用系統審批公文時，響應速度緩慢甚至長時間無響應。

該問題不僅影響了領導的日常公文審批，還阻礙了系統在集團內部推廣的速度和質量。OA 系統運維部門一直在平臺和應用層面分析問題，但始終未果，遂求助網絡運維團隊，希望在網絡和基礎設施層面協助排查。

平臺架構及業務邏輯說明

該OA 系統部署在Domino 集群平臺上，通過與4A、Portal 系統的集成，實現了SSO（單點登錄），其部署架構如圖1 所示。

用戶接入及訪問流程如下：

（1）用戶打開企業門戶點擊登錄按鈕。

（2）門戶判斷用戶未登錄，將用戶重定向至4A 系統進行身份驗證。

（3）用戶輸入用戶名、密碼通過身份驗證并獲取Token。

（4）用戶攜帶Token 訪問門戶應用中心，點擊OA 圖標進行連接。

（5）OA 連接為Web 反向代理（緩存）服務器；其會將用戶請求的URL 代理轉發到OA 平臺入口服務器前端的LB 虛擬IP。

圖1 OA 系統部署架構圖

（6）LB 根據會話保持、負載均衡算法，將請求分發到3 臺入口服務器之一。

（7）入口服務器驗證用戶Token 有效性并根據從MDM 同步的組織機構信息，將用戶重定向到為該用戶所分配的固定后端服務器。同時，還會生成平臺內部的用戶標識符，供后續使用，后續用戶對系統的訪問均會攜帶該內部標識符。

根據背景所述，兼職領導及整合公司用戶完成登錄后會被分配到圖1 下方的app21-36 的服務器之一。用戶需要提交審批流程時會通過平臺內部總線調用圖1 上方的Common Workflow Server獲取通用工作流信息。

而這2 組服務器分別部署在生產中心及災備中心，其部署架構及數據包轉發路徑如圖2 所示。

圖2 部署架構及數據包轉發路徑

圖3 數據采集點位置

故障分析流程

在與OA 系統運維同事交流后，得知圖1 右上角所示 的APP01-20 與Common Workflow Server 均部署在生產中心，未發生過類似的故障。遂將故障原因聚焦于APP21-36 服務器跨數據中心訪問Common Server 上。

1.初步分析

通過網管軟件查看月內數據中心間互訪流量統計，峰值僅有500-600Mbps，遠小于數據中心間互聯的4*10 Gbps 鏈路的承載能力。

另外，使用災備中心的服務器ping 生產中心服務器時延很小也沒有丟包（包括故障發生時）。

2.數據采集

（1）應用基礎信息收集

根據初步分析結果可判定鏈路質量、互聯帶寬無問題。后續將使用模擬訪問，結合業務路徑關鍵節點抓包方式進一步分析。在抓取數據前對Domino 集群的內部通信機制做了簡單了解,Domino 應用程序及數據庫均是以*.NSF( Notes Storage Format)格式存在的，集群成員之間通過基于TCP 協議端口號為1352 的Lotus Domino RPC進行通信。

當用戶訪問“/indishare/office.nsf/(frame)/normal?open&app=”URL 時，實際上就是訪問domino 平臺中分配給該用戶服務器的某個應用程序或數據庫，當訪問的nsf 文件存放在集群中的其他服務器上，該服務器需要通過TCP 1352 端口對后端服務器進行訪問。

（2）數據采集點選擇

基于基礎信息收集結果，選擇數據源、宿服務器，災備中心（生產中心）防火墻進出端口，數據中心間互聯鏈路端口作為數據采集點。數據采集點如圖3 箭頭指示位置。由于訪問路徑上除三層交換設備外，災備中心出口及生產中心服務器前端均部署了防火墻，從數據轉發邏輯角度出發，穿越防火墻的TCP 1352 端口流量應是重點關注對象。

圖4 查看災備中心防火墻，存在的相應會話表項

（3）數據采集方法

在 源（Linux）、宿（Windows）服務器上通過自帶的TCPdump 及安裝的Wireshark 工具抓取流量，其他采集點采用交換機端口鏡像方式將采集點端口流量鏡像到抓包端口。

為縮小數據抓取范圍、減小鏡像流量對抓包主機（圖3中的設備鏡像抓包點都是核心節點間互聯的萬兆或萬兆聚合端口，而連接抓包主機的端口為千兆端口）沖擊，在抓取數據時應配合正則表達式僅抓取源、宿主機TCP 1352 端口的通信流量。

例如，Linux 主機上的TCPdump 配置“tcpdump-i ens34 host x.x.184.128 and x.x.146.152 and tcp dst port 1352-vv-w./test.cap”，該過濾規則將相應原始數據包保存到test.cap 文件中；Wireshark 的抓包設置中也做類似過濾規則設置。

（4）數據抓取過程

在源主機184.128 利用測試頁面獲取常用審批語信息，該過程就是通過與公共流程服務器146.152 在TCP 1352 端口上建立的連接，訪問cyspy.nsf 數據庫（文件），模擬OA 平臺跨數據中心訪問。

點擊測試連接按鈕后，在各采集點同步抓取數據，待故障復現時停止點擊與數據抓取。故障發生時，OA 平臺日志顯示數據庫打開超時錯誤。

查看源主機184.128 上抓取的同目的主機146.152 TCP 1352 端口通信且TCP 載荷中包含cyspy.nsf 關鍵字的原始數據包。

打開在采集點2、3 抓取的相應數據包，通過seq=2227669018（已在wireshark 中關閉了相對序列號選項）過濾出與源端一致的數據。

同時，查看災備中心防火墻，存在如圖4 所示的相應會話表項。

結合抓包結果及防火墻表項，可判斷發生數據庫打開錯誤時，184.128 訪問146.152 的cyspy.nsf 文請求未得到響應，主機TCP 協議棧按照指數退避算法進行了重傳，當到達最大重傳次數后切斷了TCP 連接。核心交換機、防火墻均正常轉發了原始及后續重傳數據。

另外，從數據樣本的特點看，交互的TCP 流量PUSH 位均置位，數據往返時延很小。說明目的系統的響應速度很快，基本排除了由于大量PUSH 置位的數據需要快速從TCP 接收緩沖區提交至應用層處理，造成系統繁忙無法處理的情況。目的主機保存的原始抓包數據沒有發現故障時的相應原始、重傳數據包，生產中心防火墻上也沒有相應的會話表項。

初步判斷可能是生產中心防火墻將流量異常丟棄，導致了數據丟失，給用戶造成了查詢長時間無響應的感覺。后續又抓取了多個數據樣本，在某次故障發生時4號采集點采集的數據，如圖5所示。

圖5 在4 號采集點采集的數據

圖6 抓包結果

從圖中的重傳數據的源、目MAC 地址判斷，交換機將源端184.28 的重傳包發給了防火墻，源MAC 為交換機接口(04:00)，目的MAC 為防火墻VRRP 虛地址(01：f7)，數據走向與交換機的路由表一至。說明在故障發生時原始數據及重傳數據交換機均交付給了防火墻。

另一次故障發生時在5 號抓包點抓取的數據，與源主機抓取數據比對，自開始測試至故障發生時，交換機側僅有2 條TCP 流，分別為28:40700 →152:1352 與 28:58007 →152:1352。

而源主機抓取到的數據除了上面2 條流以外，還有2條引發故障的數據流，

由于5 號抓包點抓取的數據為交換機發給防火墻untrust 接口的流量，及從trust 接口接收到的流量，正常情況應該是一致的。

但從如圖6 所示的抓包結果看交換機發送給防火墻的seq=245273368 的TCP數據包后續未抓取到，且從該包的payload 看剛好是“cyspy.csf”，說明防火墻丟棄了數據，并沒有交付給目的主機。

綜合上述抓包結果，引發故障的TCP 連接應為點擊測試前，平臺就已經建立且沒有釋放的歷史連接。后續抓取的TCP keepalive 消息也證明了該點，客戶端與服務器建立TCP 連接后，由于客戶端長時間（操作系統相關，通常默認為2-3 個小時）空閑，服務端會啟動keepalive探測機制，在客戶端無響應后，切斷了連接。

3.問題分析定位

根據上述的多次抓包結果可知，Domino 集群中前端服務器與公共流程服務器通過TCP 1352 端口建立連接后，將依據資源池調度算法，將對后端公共服務器數據庫的訪問，分配到不同公共服務器或不同的TCP 連接上。

這就意味著開始建立的端到端TCP 連接可能會長期處于空閑狀態，并在后續的資源調度中復用。由于平臺本身并沒有保活機制，端到端的連接保活完全交給了TCP 協議層，該時間較長，超過了防火墻會話表超時時間（本例中防火墻預定義的TCP 協議會話表項超時時間為tcp protocol timeout:600(s)）。防火墻依據會話表項做轉發決策，對于長時間沒有流量轉發，表項計時器得不到刷新，超時后將被被清除，后續接收的流量需重新建立會話表項。

但對狀態檢測防火墻而言，只有收到syn flag 置位的TCP 數據包才會依據安全策略放行、并創建相應會話表項，正常轉發數據。就本例而言引發故障的TCP 數據段和重傳數據段都僅包含ack flag，當防火墻收到該數據包時，因不存在相應會話表項，根據狀態檢測機制即使安全策略允許放行流量，防火墻也不會創建會話表項、轉發數據包，而是按照丟棄處理。

最終，目的端收不到原始數據及重傳數據，無法將數據交付給源端。對應用層而言，由于長時間無法從數據庫中獲取數據，就會出現無響應或卡死的現象。

故障處理

得出上述分析結論后，遂對生產、災備中心防火墻相應會話表超時時間進行了調整（自定義184.0/25 網段訪問 146.128/25 網段的TCP 1352 端口的會話表超時時間為3 小時），可通過查看相應會話表項，確定長連接計時器是否生效。例如：

1.生產中心防火墻相應會話表項

2.災備中心防火墻相應會話表項

總結

對防火墻配置調整后的一周時間內，OA 系統訪問正常，關鍵用戶回訪結果反饋良好。同時，持續監控防火墻系統資源占用率也保持在正常范圍，至此故障得到了徹底排除。