Domino 集群跨數(shù)據(jù)中心互訪故障

北京 藍鵬

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

該問題不僅影響了領(lǐng)導(dǎo)的日常公文審批，還阻礙了系統(tǒng)在集團內(nèi)部推廣的速度和質(zhì)量。OA 系統(tǒng)運維部門一直在平臺和應(yīng)用層面分析問題，但始終未果，遂求助網(wǎng)絡(luò)運維團隊，希望在網(wǎng)絡(luò)和基礎(chǔ)設(shè)施層面協(xié)助排查。

平臺架構(gòu)及業(yè)務(wù)邏輯說明

該OA 系統(tǒng)部署在Domino 集群平臺上，通過與4A、Portal 系統(tǒng)的集成，實現(xiàn)了SSO（單點登錄），其部署架構(gòu)如圖1 所示。

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

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

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

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

（4）用戶攜帶Token 訪問門戶應(yīng)用中心，點擊OA 圖標(biāo)進行連接。

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

圖1 OA 系統(tǒng)部署架構(gòu)圖

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

（7）入口服務(wù)器驗證用戶Token 有效性并根據(jù)從MDM 同步的組織機構(gòu)信息，將用戶重定向到為該用戶所分配的固定后端服務(wù)器。同時，還會生成平臺內(nèi)部的用戶標(biāo)識符，供后續(xù)使用，后續(xù)用戶對系統(tǒng)的訪問均會攜帶該內(nèi)部標(biāo)識符。

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

而這2 組服務(wù)器分別部署在生產(chǎn)中心及災(zāi)備中心，其部署架構(gòu)及數(shù)據(jù)包轉(zhuǎn)發(fā)路徑如圖2 所示。

圖2 部署架構(gòu)及數(shù)據(jù)包轉(zhuǎn)發(fā)路徑

圖3 數(shù)據(jù)采集點位置

故障分析流程

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

1.初步分析

通過網(wǎng)管軟件查看月內(nèi)數(shù)據(jù)中心間互訪流量統(tǒng)計，峰值僅有500-600Mbps，遠小于數(shù)據(jù)中心間互聯(lián)的4*10 Gbps 鏈路的承載能力。

另外，使用災(zāi)備中心的服務(wù)器ping 生產(chǎn)中心服務(wù)器時延很小也沒有丟包（包括故障發(fā)生時）。

2.數(shù)據(jù)采集

（1）應(yīng)用基礎(chǔ)信息收集

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

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

（2）數(shù)據(jù)采集點選擇

基于基礎(chǔ)信息收集結(jié)果，選擇數(shù)據(jù)源、宿服務(wù)器，災(zāi)備中心（生產(chǎn)中心）防火墻進出端口，數(shù)據(jù)中心間互聯(lián)鏈路端口作為數(shù)據(jù)采集點。數(shù)據(jù)采集點如圖3 箭頭指示位置。由于訪問路徑上除三層交換設(shè)備外，災(zāi)備中心出口及生產(chǎn)中心服務(wù)器前端均部署了防火墻，從數(shù)據(jù)轉(zhuǎn)發(fā)邏輯角度出發(fā)，穿越防火墻的TCP 1352 端口流量應(yīng)是重點關(guān)注對象。

圖4 查看災(zāi)備中心防火墻，存在的相應(yīng)會話表項

（3）數(shù)據(jù)采集方法

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

為縮小數(shù)據(jù)抓取范圍、減小鏡像流量對抓包主機（圖3中的設(shè)備鏡像抓包點都是核心節(jié)點間互聯(lián)的萬兆或萬兆聚合端口，而連接抓包主機的端口為千兆端口）沖擊，在抓取數(shù)據(jù)時應(yīng)配合正則表達式僅抓取源、宿主機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”，該過濾規(guī)則將相應(yīng)原始數(shù)據(jù)包保存到test.cap 文件中；Wireshark 的抓包設(shè)置中也做類似過濾規(guī)則設(shè)置。

（4）數(shù)據(jù)抓取過程

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

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

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

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

同時，查看災(zāi)備中心防火墻，存在如圖4 所示的相應(yīng)會話表項。

結(jié)合抓包結(jié)果及防火墻表項，可判斷發(fā)生數(shù)據(jù)庫打開錯誤時，184.128 訪問146.152 的cyspy.nsf 文請求未得到響應(yīng)，主機TCP 協(xié)議棧按照指數(shù)退避算法進行了重傳，當(dāng)?shù)竭_最大重傳次數(shù)后切斷了TCP 連接。核心交換機、防火墻均正常轉(zhuǎn)發(fā)了原始及后續(xù)重傳數(shù)據(jù)。

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

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

圖5 在4 號采集點采集的數(shù)據(jù)

圖6 抓包結(jié)果

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

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

而源主機抓取到的數(shù)據(jù)除了上面2 條流以外，還有2條引發(fā)故障的數(shù)據(jù)流，

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

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

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

3.問題分析定位

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

這就意味著開始建立的端到端TCP 連接可能會長期處于空閑狀態(tài)，并在后續(xù)的資源調(diào)度中復(fù)用。由于平臺本身并沒有?；顧C制，端到端的連接?；钔耆唤o了TCP 協(xié)議層，該時間較長，超過了防火墻會話表超時時間（本例中防火墻預(yù)定義的TCP 協(xié)議會話表項超時時間為tcp protocol timeout:600(s)）。防火墻依據(jù)會話表項做轉(zhuǎn)發(fā)決策，對于長時間沒有流量轉(zhuǎn)發(fā)，表項計時器得不到刷新，超時后將被被清除，后續(xù)接收的流量需重新建立會話表項。

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

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

故障處理

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

1.生產(chǎn)中心防火墻相應(yīng)會話表項

2.災(zāi)備中心防火墻相應(yīng)會話表項

總結(jié)

對防火墻配置調(diào)整后的一周時間內(nèi)，OA 系統(tǒng)訪問正常，關(guān)鍵用戶回訪結(jié)果反饋良好。同時，持續(xù)監(jiān)控防火墻系統(tǒng)資源占用率也保持在正常范圍，至此故障得到了徹底排除。