IT運(yùn)維技術(shù)討論之三：如何滿足運(yùn)維不間斷服務(wù)的需求

dengbao2001

歡迎大家就此話題發(fā)表意見，謝謝！踴躍參與話題者，就有機(jī)會(huì)獲得《24小時(shí)365天不間斷服務(wù)：服務(wù)器/基礎(chǔ)設(shè)施核心技術(shù)》

to407

General_715 發(fā)表于 2015-01-20 18:31

3.你的工作環(huán)境發(fā)生因冗余或者高可用導(dǎo)致的事故嗎？你是如何防止該類事故的再次發(fā)生？
   一次一臺(tái)oracle服務(wù)器因?yàn)槌绦騜ug，導(dǎo)致大量的復(fù)制進(jìn)程，最后導(dǎo)致服務(wù)器hang住，oracle用的是rac做高可用，這時(shí)另一臺(tái)oracle服務(wù)器在等待出問題的這臺(tái)機(jī)器的實(shí)例關(guān)閉之后，才能完成實(shí)例再構(gòu)成，而出問題的oracle一直在hang住了，后來是通過IBM的遠(yuǎn)程控制IMM重啟了服務(wù)器，才恢復(fù)。
.

像這種問題， 一個(gè)節(jié)點(diǎn)hang不應(yīng)該導(dǎo)致其他的節(jié)點(diǎn)出問題， 只需要將問題節(jié)點(diǎn)手動(dòng)剔除 （重啟）就行了。11.2以后的oracle會(huì)自動(dòng)的對(duì)hang做一些kill的處理。 也會(huì)嘗試重啟節(jié)點(diǎn)。  當(dāng)然兩個(gè)節(jié)點(diǎn)的RAC還是會(huì)有些問題的， 因?yàn)橐恍゜ug，重啟一臺(tái)機(jī)器的時(shí)候，很大的可能性 另外一臺(tái)也會(huì)掛掉。

---

to407

dengbao2001 發(fā)表于 2015-01-16 10:32
Oracle級(jí)別不知道RAC能不能做到？

反正Windows Cluster是不行的

RAC這么看。

比如4個(gè)節(jié)點(diǎn)的RAC，掛了一個(gè)， 業(yè)務(wù)基本上是不會(huì)受影響的，頂多性能在短期內(nèi)會(huì)有波動(dòng)。

當(dāng)然4個(gè)RAC所在的機(jī)房突然斷電了，這就是另一回事了。

RAC 我們講是用來做 high availability的。  不是做maximum availability的。  差別就在這里。

如果我們整套R(shí)AC出問題了怎么辦？   那就在業(yè)務(wù)之上繼續(xù)做HA， 用Dataguard+RAC.  這可以保證當(dāng)RAC出問題時(shí)候的快速failover ,做到zero downtime。

再往外 還有 Remote/Extended RAC,    還有GoldenGate， 那就是Disaster  Recover 級(jí)別的了。

這個(gè)講不到底， 只要愿意燒錢。。。

to407

1.就你工作的的本身，談?wù)勀闶欠裥枰�冗余和高可用�?br /> 因?yàn)橐�保存客戶的�?shù)據(jù)， 這是必須的。 硬件級(jí)別的HA，存儲(chǔ)RAID，RAC CLUSTER。
數(shù)據(jù)庫層次，RAC基本上都要配ASM的Normal/High redundancy.


2.如果需要冗余或者高可用，你是如何實(shí)現(xiàn)的？使用商業(yè)解決方案？還是開源解決方案？
商業(yè)的解決方案， ORACLE RAC／Dataguard/ GoldenGate.

3.你的工作環(huán)境發(fā)生因冗余或者高可用導(dǎo)致的事故嗎？你是如何防止該類事故的再次發(fā)生？

我們阻止不了這樣的情況發(fā)生。

比如下面的問題
http://tech.163.com/13/0709/12/93BE7M3Q000915BD.html

這種問題很難保證不發(fā)現(xiàn)， 測試環(huán)境和生產(chǎn)環(huán)境永遠(yuǎn)是不一致的。  我們能做的就是盡量按照流程，總結(jié)經(jīng)驗(yàn)。。

很多問題也是技術(shù)之外的， 比如這個(gè)鏈接里提到的災(zāi)備。 我想，災(zāi)備肯定是有的。 但是切換災(zāi)備是很需要勇氣的，不應(yīng)該太過批評(píng)。

比如Oracle DataGuard, 有 switch over 和failover 的功能。 但是 failover 從來都是不輕易主動(dòng)使用的。  因?yàn)橐坏┺D(zhuǎn)過去， 原來的一套系統(tǒng)就全部沒用了。 如果沒切換成功， 那就等著戰(zhàn)后重建吧。。。

dengbao2001

to407 發(fā)表于 2015-01-26 14:38
1.就你工作的的本身，談?wù)勀闶欠裥枰�冗余和高可用�?br /> 因?yàn)橐�保存客戶的�?shù)據(jù)， 這是必須的。 硬件級(jí)別的HA ...

感謝你的分享～

General_715

to407 發(fā)表于 2015-01-26 14:22
像這種問題， 一個(gè)節(jié)點(diǎn)hang不應(yīng)該導(dǎo)致其他的節(jié)點(diǎn)出問題， 只需要將問題節(jié)點(diǎn)手動(dòng)剔除 （重啟）就行了。1 ...

多謝指教。
當(dāng)時(shí)就是重啟有問題的服務(wù)器之后，恢復(fù)了。因?yàn)槭沁h(yuǎn)程連接，在找IMM登錄密碼的時(shí)候費(fèi)了點(diǎn)時(shí)間。
如果是3個(gè)節(jié)點(diǎn)的話，也是還得需要重啟吧?

to407

回復(fù) 126# General_715


    看你的oracle版本， 如果是11.2以后的版本就比較完善了，  哪個(gè)節(jié)點(diǎn)出問題 就被會(huì)踢出去/重啟。  如果是12c的話 會(huì)在重啟節(jié)點(diǎn)之前嘗試重啟stack

    至于兩個(gè)節(jié)點(diǎn)的情況，原則上是保留 節(jié)點(diǎn)號(hào)比較小的， 如第一個(gè)節(jié)點(diǎn)， 那么 出問題的時(shí)候， 會(huì)存在極端情況，就是好的節(jié)點(diǎn)被重啟了。。。。當(dāng)然是比較舊的版本的問題。

CJHP1314

架構(gòu)很重要，只要每層的設(shè)計(jì)都有健康檢查機(jī)制，有問題能自動(dòng)摘除，我覺得對(duì)于一般的網(wǎng)站應(yīng)該就足夠了，比如外層是LB，里面的節(jié)點(diǎn)是nginx，LB對(duì)nginx的80做檢查，nginx  通過upstrem  對(duì)下游的服務(wù)做檢查，每一次自動(dòng)判斷，摘取。

General_715

to407 發(fā)表于 2015-01-26 22:24
回復(fù) 126# General_715

多謝指教。
您說的出問題的節(jié)點(diǎn)被踢出去/重啟  這個(gè)重啟是不是必須手動(dòng)重啟。我當(dāng)時(shí)遇到問題的時(shí)候 就是手動(dòng)重啟服務(wù)器之后 節(jié)點(diǎn)才被踢出去 重啟之前 一直是hang住的

to407

回復(fù) 129# General_715


    我指的節(jié)點(diǎn)被踢出集群，指的是 該節(jié)點(diǎn) 的ohasd/crsd 進(jìn)程棧 被嘗試停下重新再起。  如果失敗， 該節(jié)點(diǎn)會(huì)被 echo"b">/proc/sysrq-trigger 強(qiáng)制重啟。

    當(dāng)然這個(gè)邏輯要oracle版本 >11.2才可以， oracle10 的時(shí)候沒有這么完善，11.2的時(shí)候不會(huì)嘗試停棧，會(huì)強(qiáng)制重啟os