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

北京 藍(lán)鵬

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

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

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

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

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

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

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

（3）用戶輸入用戶名、密碼通過(guò)身份驗(yàn)證并獲取Token。

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

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

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

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

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

根據(jù)背景所述，兼職領(lǐng)導(dǎo)及整合公司用戶完成登錄后會(huì)被分配到圖1 下方的app21-36 的服務(wù)器之一。用戶需要提交審批流程時(shí)會(huì)通過(guò)平臺(tái)內(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ù)采集點(diǎn)位置

故障分析流程

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

1.初步分析

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

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

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

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

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

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

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

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

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

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

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

為縮小數(shù)據(jù)抓取范圍、減小鏡像流量對(duì)抓包主機(jī)（圖3中的設(shè)備鏡像抓包點(diǎn)都是核心節(jié)點(diǎn)間互聯(lián)的萬(wàn)兆或萬(wàn)兆聚合端口，而連接抓包主機(jī)的端口為千兆端口）沖擊，在抓取數(shù)據(jù)時(shí)應(yīng)配合正則表達(dá)式僅抓取源、宿主機(jī)TCP 1352 端口的通信流量。

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

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

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

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

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

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

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

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

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

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

圖5 在4 號(hào)采集點(diǎn)采集的數(shù)據(jù)

圖6 抓包結(jié)果

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

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

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

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

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

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

3.問題分析定位

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

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

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

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

故障處理

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

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

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

總結(jié)

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