李 琦
(中國郵政集團(tuán)公司湖南省信息技術(shù)局,長沙 410007)
隨著郵政信息化建設(shè)的逐步深入,應(yīng)用系統(tǒng)的集約化不斷提高,系統(tǒng)大集中是大勢所趨,地市中心機(jī)房的數(shù)據(jù)庫和服務(wù)器數(shù)量日趨減少,而我省中心機(jī)房的數(shù)據(jù)庫和集群服務(wù)器數(shù)量越來越多,如何對大集中后的應(yīng)用系統(tǒng)進(jìn)行有效的運維已成為企業(yè)信息化發(fā)展的一個重大課題。面對日益龐大的數(shù)據(jù)庫和服務(wù)器的維護(hù)工作,我省中心機(jī)房運維人員基本還是采用傳統(tǒng)的手工巡檢方式進(jìn)行設(shè)備和系統(tǒng)巡查,需要人工或腳本進(jìn)行單機(jī)獨立巡檢與分析,每天需要手工處理很多重復(fù)性工作,運維工作中的數(shù)據(jù)記錄分散,預(yù)警信息獲取不及時,導(dǎo)致運維人員工作量大,工作效率低,并且無法實時和直觀的監(jiān)控到集群服務(wù)器的運行狀況,也使得系統(tǒng)運行風(fēng)險大增。
由于我省中心機(jī)房目前對眾多的應(yīng)用系統(tǒng)和數(shù)據(jù)庫的運維主要是采用豎井式的應(yīng)用運維模式,往往是1-2名系統(tǒng)工程師熟悉某一專業(yè)的系統(tǒng),碰到故障形成只有那一兩名工程師能解決問題或者臨時找不到人而其他人則有力無處使的情況,由于大量的系統(tǒng)是7*24小時運行方式,有些重要系統(tǒng)的安全運行指標(biāo)非常高,宕機(jī)恢復(fù)時間超過20分鐘即屬于重大事故,硬件故障,我們可以采用冗余和雙機(jī)熱備這樣的機(jī)制保障,但是對于數(shù)據(jù)庫以及性能下降這樣造成的軟宕機(jī)故障,對數(shù)據(jù)庫運行性能的參數(shù)進(jìn)行動態(tài)監(jiān)控并及時預(yù)警,就成為機(jī)房數(shù)據(jù)庫運維工作的必須。要實現(xiàn)這個目標(biāo),首先需要解決兩個問題:(1)是一是如何單點集中監(jiān)控數(shù)據(jù)庫。(2)是如何在移動端接受監(jiān)控信息。
得益于移動互聯(lián)網(wǎng)應(yīng)用技術(shù)在郵政行業(yè)內(nèi)的快速發(fā)展,微信已發(fā)展成為我省郵政企業(yè)眾多業(yè)務(wù)領(lǐng)域的最受歡迎的移動應(yīng)用工具。目前我省微信客戶群已經(jīng)擁有超過300萬個活躍用戶,微信因信任度高、傳播快,可以隨時互動,我省郵政企業(yè)員工很多日常通知,正逐漸由短信向微信轉(zhuǎn)變。所以我們的課題就選擇采用了微信這一渠道,以微信企業(yè)號接受監(jiān)控信息的方式實現(xiàn)向系統(tǒng)管理員和相關(guān)運維人員發(fā)送預(yù)警信息。
經(jīng)過我們多次全面深入的調(diào)研與嘗試,確立了以O(shè)EMCC(Oracle Enterprise Manager Cloud Control)實現(xiàn)數(shù)據(jù)庫集中監(jiān)控。通過在一臺機(jī)器上部署OEMCC 的OMS(Oracle Management Server)端,在需要監(jiān)控的各數(shù)據(jù)庫服務(wù)器上部署OMA(Oracle Management Agent)端。通過OMA 將各實例的信息注冊至OMS,實現(xiàn)OMS 端捕獲各實例的告警信息、操作系統(tǒng)信息、硬件資源及性能信息等。通過CCC(Cloud Control Console)端即可將OMS 上捕獲到的信息展示在WEB 頁面上并實現(xiàn)管理。通過Python 爬蟲腳本及微信企業(yè)號信息推送腳本即可實現(xiàn)在手機(jī)端自動接受監(jiān)控信息。具體架構(gòu)如圖1。
具體實現(xiàn)上,分別在對應(yīng)的數(shù)據(jù)庫服務(wù)器上通過部署OEMCC 12C 的OMS、OMA、CCC 端,實現(xiàn)單點對多數(shù)據(jù)庫的監(jiān)控;同時編寫Python 爬蟲腳本及微信企業(yè)號信息推送腳本,將CCC 端上的告警信息爬取下來推送至微信企業(yè)號??紤]監(jiān)控服務(wù)器的高可靠性,我們部署了OEMCC 集群,包括OMR 的集群和OMS 的集群,其中OMR 的集群就是對應(yīng)Oracle 12.1.0.2 RAC;OMS 的集群配置Active-Active 模式,并配合SLB 實現(xiàn)負(fù)載均衡。
圖1 邏輯架構(gòu)圖
同時,為了對各數(shù)據(jù)庫的備份進(jìn)行統(tǒng)一管理,構(gòu)建了機(jī)房集中的數(shù)據(jù)湖,將各系統(tǒng)的備份統(tǒng)一部署腳本,RMAN 備份腳本集中部署。實現(xiàn)辦法是在OMS 機(jī)器上安裝不同版本的Oracle 形成一個單機(jī)catalog 庫群,實現(xiàn)了單機(jī)部署RMAN 腳本集中管理不同版本的Oracle 數(shù)據(jù)庫備份。
為了實時監(jiān)控RMAN 的備份情況,我們編寫了sh 腳本,分析RMAN 備份產(chǎn)生的日志,實時查看受監(jiān)控各系統(tǒng)的數(shù)據(jù)庫備份的執(zhí)行情況,匯總當(dāng)前應(yīng)備份的數(shù)據(jù)庫實例個數(shù),已完成數(shù)據(jù)庫實例數(shù),備份失敗的數(shù)據(jù)庫實例個數(shù),記錄每個備份任務(wù)的實際時長,備份記錄的大小,用以后續(xù)分析數(shù)據(jù)庫的運行效率和系統(tǒng)健壯程度。當(dāng)備份異常時通過Python 腳本將異常信息推送至微信企業(yè)號相關(guān)技術(shù)人員,以便及時處理。
對于經(jīng)常晚間定時處理的跑批服務(wù),也通過將跑批程序日志表集中監(jiān)控進(jìn)行了動態(tài)及時監(jiān)控。我們編寫了Python 腳本實時監(jiān)控各應(yīng)用系統(tǒng)跑批程序日志表并部署在OMS 機(jī)器上,當(dāng)有跑批程序日志出現(xiàn)異常記錄時,將表中異常記錄信息實時推送至微信企業(yè)號相關(guān)技術(shù)人員。
圖2 手機(jī)端實時收到報警信息
在運維技術(shù)人員的手機(jī)端收到的報警信息如圖2所示:如圖2所示,兩臺受監(jiān)控主機(jī)上根目錄文件系統(tǒng)可用空間分別只有5.83%和,10.57%了,低于預(yù)設(shè)的告警區(qū)間,所以系統(tǒng)自動報警,需要相關(guān)技術(shù)人員及時處理。
相對于生產(chǎn)網(wǎng)來說,辦公網(wǎng)雖然安全級別不是最高,但是也不能直接與互聯(lián)網(wǎng)(外網(wǎng))直連,暴露在互聯(lián)網(wǎng)下,所以根據(jù)機(jī)房實際情況,我們按下圖3模式構(gòu)建了機(jī)房的DMZ 區(qū)(DMZ 通常是駐留于專用網(wǎng)絡(luò)和公共網(wǎng)絡(luò)之間的一個子網(wǎng),從公共網(wǎng)絡(luò)的連接到DMZ 設(shè)備終止,這些服務(wù)器也經(jīng)常被相對安全的專用網(wǎng)絡(luò)設(shè)備訪問。),使用一個有3個接口的防火墻去創(chuàng)建隔離區(qū),每個隔離區(qū)成為這個防火墻接口的一員。防火墻提供區(qū)與區(qū)之間的隔離。這種機(jī)制提供了許多關(guān)于DMZ 安全的控制。用以隔離辦公網(wǎng)與互聯(lián)網(wǎng),對訪問進(jìn)行控制,我們將部分用于提供對外服務(wù)的服務(wù)器主機(jī)劃分到一個特定的子網(wǎng)—DMZ 內(nèi),在DMZ 的主機(jī)能與同處DMZ 內(nèi)的主機(jī)和外部網(wǎng)絡(luò)的主機(jī)通信,而同辦公網(wǎng)內(nèi)的主機(jī)通信會被受到限制。這使DMZ 的主機(jī)能被辦公網(wǎng)網(wǎng)絡(luò)和外部網(wǎng)絡(luò)所訪問,而辦公網(wǎng)網(wǎng)絡(luò)又能避免外部網(wǎng)絡(luò)所得知。
圖3 防火墻隔離DMZ區(qū)和辦公網(wǎng)
DMZ 區(qū)的隔離策略如下:
(1)辦公網(wǎng)(內(nèi)網(wǎng))可以訪問互聯(lián)網(wǎng)(外網(wǎng))。辦公網(wǎng)(內(nèi)網(wǎng))的用戶訪問外網(wǎng)時,防火墻會對源地址進(jìn)行轉(zhuǎn)換。
(2)辦公網(wǎng)可以訪問DMZ 區(qū)。方便工作人員從辦公網(wǎng)使用和管理DMZ 區(qū)的服務(wù)器。
(3)互聯(lián)網(wǎng)不能訪問辦公網(wǎng)。有助于對辦公網(wǎng)的資源進(jìn)行保護(hù)。
(4)互聯(lián)網(wǎng)可以訪問DMZ 區(qū)。某些需要從互聯(lián)網(wǎng)登陸的服務(wù),就可以專門部署在DMZ 區(qū)。這樣可以集中網(wǎng)絡(luò)安全設(shè)施和設(shè)備對DMZ 區(qū)加強保護(hù)。
(5)DMZ 區(qū)不能訪問辦公網(wǎng)。為了有效隔離外網(wǎng)直接訪問辦公網(wǎng)。當(dāng)有入侵者攻陷DMZ 區(qū)時,這樣可以阻止入侵者進(jìn)一步攻入辦公網(wǎng)。
(6)DMZ 區(qū)不能訪問互聯(lián)網(wǎng)。通過這樣設(shè)計和部署的一整套方案,現(xiàn)在我們省中心機(jī)房實現(xiàn)了:多系統(tǒng)數(shù)據(jù)庫的移動集中監(jiān)控、RMAN 備份集中管理、應(yīng)用系統(tǒng)跑批程序日志表集中監(jiān)控。目前主要管理的目標(biāo)包括2套ASM、2套RAC 集群、12個Oracle 數(shù)據(jù)庫實例、一個MySQL 庫、12臺服務(wù)器,共計29個監(jiān)控目標(biāo)。在2018年的運行中,共計成功發(fā)送報警信息84條,應(yīng)急處理信息4條,有效的支持了我省中心機(jī)房全年無故障運行。同時,這套方案的實施,極大的減少了機(jī)房運維人員工作量,也使得我們數(shù)據(jù)庫的DBA 能參與到更多的數(shù)據(jù)庫管理或軟件開發(fā)任務(wù)中去,既減少了運維成本投入,又提高了軟件開發(fā)效率。未來機(jī)房運維,其中最重要和關(guān)鍵的就是應(yīng)用系統(tǒng)和數(shù)據(jù)庫的運維,所以,該方案的成功實施最重要的意義是,為我們后續(xù)繼續(xù)深入探索機(jī)房的遠(yuǎn)程智能云監(jiān)控模式打下了良好的基礎(chǔ)。