使用重啟大招之前的思索

故障現象

周六休息時，突然接到實驗室同事報障電話，說就在剛才斷電10分鐘來電后，OpenLAB系統無法連接。機房服務器有UPS供電，怎么會出現這樣的情況呢？趕到現場查看，機房里整套系統7臺服務器從電源、硬盤和網絡指示燈看均運行正常，登錄一臺服務器表面上看也沒有問題，只是用戶在辦公室通過遠程桌面打開OpenLAB軟件時，一直顯示連接中（如圖1）。在機房AIC服務器上打開OpenLAB軟件，仍然是同樣的情況。也就是說，所有用戶都無法正常啟動該軟件。

系統介紹

由于是周末只有個別用戶加班，所以影響還算小，可以有時間來仔細檢測問題原因。只是從同事那兒接手該系統兩年來，沒有遇到過類似情況，平日也就是每兩周把所有服務器重啟一次，協助廠家工程師安裝過增加的系統，因一臺反應慢更換過服務器，還有就是每月一次的通過SSR系統備份和每周用BE備份試驗數據。

圖1 OpenLAB軟件啟動一直連接中

OpenLAB CDS網絡化色譜工作站系統是安捷倫公司基于微軟.NET技術，擁有三層體系結構，由OpenLAB OLSS服務器、Agilent AIC和瘦客戶端三層組成。OLSS服務器負責提供系統的安全管理、許可審核、審計追蹤、儀器狀態管理以及數據存儲等功能。Agilent Instrument Controller（以下簡稱AIC）作為系統的中間層，負責提供數據的采集、儀器的反控、數據的緩存以及上傳等工作。客戶端使用遠程桌面服務虛擬客戶端模式，利用微軟的RDS虛擬技術，可以實現客戶端的零安裝。全套系統操作系統均是Windows Server 2008 R2英文版，曾聽同事講過幾次系統的大概結構：用戶通過TS終端服務器的遠程桌面方式去操作控制AIC服務器所連接的儀器，用戶登錄遠程桌面是通過端服務器的本地驗證，OpenLAB軟件登錄驗證是通過OLSS服務器進行的，最后將儀器生成數據存入ECM服務器。

排錯與測試

首先通過Ping命令確認了服務器間通訊正常；其次查看服務器日志，在下午2：34TS服務器有錯誤日志“The Terminal Server security layer detected an error in the protocol stream and has disconnected the client. Client IP：192.168.219.55.”，也就是當天來電后加班同事的連接，其他時段還有大量類似報錯；在下午2：24AIC服務器有兩條錯誤日志“The Terminal Server security layer detected an error in the protocol stream and has disconnected the client. Client IP：192.168.17.10.”也就是在停電時AIC終端服務安全層檢測到TS服務器在協議流中有錯誤而斷開了連接，同時儀器驅動也報了兩條錯誤日志“Disconnecting because a System.Net.WebException was caught when sending a command； The request was aborted： The operation has timed out.”，但是這條日志該服務器在其他時間段也大量出現過，用戶那邊未曾報告出現什么問題。

由于周末廠商直接售后服務的工程不方便聯系，于是撥打了安捷倫售后服務電話，服務人員得知是OpenLAB ChemStation的網絡版時，說這種情況涉及到網絡方面的原因，沒有網絡工程師值班而無法解答，建議重啟服務器系統試試。咨詢結果和預期的一樣，使用服務器重啟大招。旁邊實驗室的同事說這樣的問題是第二次出現了，上次也是停電后發生的，那次他以為是我們IT人員在處理服務器上午有問題也未反饋，下午就正常了（而我們什么都沒做）。這就很奇怪了，很想探研一下什么原因導致的發生這樣的問題。

圖2 軟件啟動報錯提示

圖3 OLSS服務器netstat顯示端口連接a

圖4 OLSS服務器netstat顯示端口連接b

再回到AIC服務器上，發現OpenLAB程序有報錯了如圖2，大概意思是程序在已配置的3分鐘內未獲得OLSS服務器6577端口回應，運行中分配的時間已部分超時，可能是該運行服務仍然在進行中或者是未能發出一個應答信息，請考慮增加運行超時設置并確保客戶端可以訪問該服務。

有了錯誤提示，就多一些處理問題的線索，通過telnet服務器OLSS端口6577是通的，為什么端口是正常能連接而程序卻無法連接呢？登錄OLSS服務器netstat查看端口連接情況，顯示很慢很多，有大量TS服務器到OLSS服務器6577端口的連接（如圖3）。難道是端口異常繁忙導致無法給程序響應？可是現在周末沒幾個用戶，而且平日也從來沒有出現這種現象啊。

把TS服務器重啟一下再看是什么現象，因為重啟TS對數據沒有任何影響，比直接重啟OLSS服務器影響小。后又想，直接把TS服務器的網線撥掉也能驗證剛才的想法。

撥掉服務器實驗網段的網線，在OLSS服務器上仍然能看到到6577端口的連接，不同的是從TS服務器從計算機名變成了IP地址（如圖4）。再把另一根用于連接辦公網的網線也撥掉，用戶正是通過這根網線從辦公室來連接TS服務器的。奇怪的是，在OLSS服務器上到從TS到6577端口的連接仍然存在，而且不停增加，這是哪里出了問題呢？

查看了OLSS服務器上的日志，只有一個網卡網絡連接在下午2：24有斷開的警告記錄“Broadcom BCM5709C：The network link is down.Check to make sure the network cable is properly connected”，也就是停電那會兒，應該是機房這臺交換機未接入UPS電源所致，而且在每兩周重啟服務器也會有這么一條日志。

把顯示器鍵盤鼠標再次切到AIC服務器上運行OpenLAB程序，這次沒有顯示一直在連接的狀態，而是馬上報出錯誤提示“Connection to Shared Service failed”（如圖5）。這是問題測試檢查有進展的標志，說明之前程序啟動時一直處于連接狀態確實和TS服務器大量連接到OLSS服務器的6577端口有關，導致其無法及時響應OpenLAB程序的連接。

綜合分析覺得，問題是出在OLSS服務器，可是這個服務器在停電那十多分鐘都是正常在運行，怎么回出現這么奇怪的問題呢？更奇怪的是上次停電出現的類似故障居然自動恢復了。難道真得用重啟OLSS服務器的大招嗎？

看著AIC上面程序啟動時報的錯誤提示，忽然想到就重啟下安捷倫的相關服務看行不行。立即運行“services.msc”，找到一個和錯誤提示類似的服務“Agilent OpenLAB Shared Services”，重啟服務很順利地完成（如圖6）。再次去AIC上運行OpenLAB程序，很快出現了熟悉的登錄界面。讓實驗室的同事登錄進去查一下加班運行的儀器情況，很遺憾儀器沒有配UPS斷電就停止運行了，上午所做的幾個分析試驗得全部重來。

圖5 OenLAB軟件啟動直接報錯

圖6 軟件報錯相關服務

圖7 OpenLAB軟件正常啟動界面

將剛才斷開的TS兩條網線按標記順序接上，實驗人員就可以正常從辦公室連計算機接到遠程桌面操作儀器了（如圖7）。

最后將上述處理截圖發郵件給直接聯系的廠商售后工程師，請教出現此問題的更深層次原因，從而避免此類故障給公司造成工作上的損失。還沒等到廠商回復的故障原因，不到一周時間又接到供電局通知，說周五 12：30 到 14：00“將有兩次短時停電，每次3到5秒”，這次試驗室的同事和我們商量決定，在4臺AIC服務器所連的儀器上做個測試樣，以確認更具體的情況。就這幾秒的停電真讓信息系統受不了，結果是只有一臺AIC服務器上的分析測試運行正常，這下得深入分析對比一下各服務器Windows日志和網絡連接問題了。

遠程登錄AIC，發現有兩臺有非正常關機的提示，也就是說這兩臺服務器在幾秒的斷電過程中自動重啟了。仔細想想這兩臺是后來添加的，當時電源插線板孔位不夠就再串接了一個，串接時可能接到市電的電源插座上了，平常沒感覺，這幾次斷電才知道錯誤了。由于之前接服務器的網絡未作詳細標識，網絡機柜又裝著6臺交換機，實在不方便找出某個服務器接哪臺交換機幾號端口，還好都是可配置的H3C交換機，用筆記本電腦連接控制口執行“dis mac-add”將端口對應學習到的MAC地址表復制下來，再比較各服務器網卡的物理地址，終于找到網絡連接的端口。有4臺服務器Windows日志里在停電時出現了網絡連接斷開的警告記錄，均連接到第一臺交換機上，說明此交換機也沒有接入UPS電源，和同事確認這臺機器后來為了測試整個系統反應慢的問題，而增加的全千兆交換機，沒有接入UPS電源。

找到問題根源，處理就好辦了，同時也發現前幾次OLSS服務器上的“Agilent OpenLAB Shared Services”服務異常是其網絡連接斷開所致。

經驗總結

如果我們直接重啟服務器當然也能把問題解決，但那樣做并不能讓我們找到問題的更進一步原因，而當某些情形不容我們去慢慢分析時，重啟服務器確實也是有效的常用大招。經過此番探研，下次再出現類似問題，我們不必使用重啟服務器的大招，也能精準快速解決問題，經驗就此積累。通過對此次問題的深入排查，也暴露了我們在后期更新維護過程中不規范作業，機房服務器和交換機本應接UPS電源系統居然出了差錯，每次遇到停電，大家都還想當然地認為機房里設備都有接入UPS電源呢。