服務(wù)項目:網(wǎng)站建設(shè)、仿站、程序開發(fā)、APP開發(fā)設(shè)計、移動網(wǎng)站開發(fā)設(shè)計、企業(yè)網(wǎng)站設(shè)計、電子商務(wù)網(wǎng)站開發(fā)、網(wǎng)站維護、網(wǎng)站推廣、UX/UI 、HTML5、CSS3、JS / Jquery ...
四川???萍加邢薰?></a></div>
                    <div   id=四川???萍加邢薰? title=
四川???萍加邢薰?(開發(fā)設(shè)計官網(wǎng))TEL : 15308000360 / QQ : 38585404

您的位置:首頁 > 技術(shù)經(jīng)驗 > 網(wǎng)站運維 > 正文

消除小型 Web 站點單點故障(Single Point of Failure)
技術(shù)支持服務(wù)電話:15308000360 【7x24提供運維服務(wù),解決各類系統(tǒng)/軟硬件疑難技術(shù)問題】

說起單點故障(Single Point of Failure,SPOF),倒是可以想起電影 《2012》中,一把焊槍把齒輪卡住,從而導(dǎo)致整個艙門無法關(guān)閉,進而整個引擎無法發(fā)動。這是個有點生動的例子–如此龐大的一個系統(tǒng),居然因為一把小小的焊槍而險些毀于一旦。投入巨大人力物力生產(chǎn)的救命方舟居然做不到高可用(High availability),這是致命的事情。

大腦對與人來說,就是一個單點,大腦損壞,人也完蛋;手是不是單點? 一只沒了,另一只還能日常生活,從這個角度來說,不是單點。消除單點的最常見的做法:增加冗余。比如,人有兩只手。其次,層次化。當然,分層的目的是便于隔離問題。電影 《2012》 中的這個問題,不知道誰是總架構(gòu)師,看起來,隔離做得不太夠 :)

一般來說,只要系統(tǒng)能夠比較清楚的分出層次來,要消除單點故障還是有章可循的事情。比如,一個網(wǎng)站,從基礎(chǔ)的硬件層,到操作系統(tǒng)層,到數(shù)據(jù)庫層,到應(yīng)用程序?qū)?,再到網(wǎng)絡(luò)層,都有可能產(chǎn)生單點故障。如果要有效的消除單點故障,最重要的一點是設(shè)計的時候要盡量避免引入單點,而隨著架構(gòu)的變化,定期審查系統(tǒng)潛在單點也是有必要的。

有人或許會問,假設(shè)一個起步中的站點,只有一臺服務(wù)器,什么東西都在一個盒子里,到底要怎么做呢? 這里的建議是先拋開主板、CPU 、內(nèi)存這些,首先必須考慮硬盤(存儲層)的問題,如果機器只有一塊硬盤,即使你備份計劃再完善(不要說你的備份也是備份在這塊硬盤上的),還是建議你起碼再弄一塊。做鏡像,讓出錯的概率降低,這是劃算的投入,當然消除單點,成本幾乎不可避免的要增加。如果硬盤多,或者有其他備份機制,可選的方法就更多,別刻舟求劍。

第二個要考慮網(wǎng)卡與網(wǎng)線的單點問題。先說網(wǎng)線,如果要問一個系統(tǒng)里面最容易物理損壞的是哪個組件,答案恐怕非網(wǎng)線莫屬,對于網(wǎng)線這樣多數(shù)時候因為距離需要定制的東西,總是購買成品還是有成本的,從我觀察到的情況來看,各個 IDC 的網(wǎng)線使用手工制作的比例不小,這個質(zhì)量幾乎很難控制,一根線,兩個水晶頭,哪一個出問題都不能正常傳輸。怎么辦? 想辦法提升網(wǎng)線整體質(zhì)量還是弄兩根網(wǎng)線放在那里? 解決辦法早都有了,網(wǎng)卡綁定 (NIC bonding)一個很簡單很通用的辦法(refer),但是問題是并非很多人在用。多數(shù) PC 服務(wù)器應(yīng)該都是配置了多塊網(wǎng)卡,如果是自己攢服務(wù)器,記得網(wǎng)卡多一塊成本沒多大,但是用處會有很多。如果耐著性子看到這里,先別急著去 Google,還有問題呢,兩根網(wǎng)線如何接到上行交換機,什么樣的交換機支持綁定,如何確定綁定是真正生效的? 答案是,嘗試一下。

然后是什么? 是跑多個數(shù)據(jù)庫,還是跑兩個 Web 服務(wù)器,一個不行用另一個頂? 對于單臺服務(wù)器,其它能消除單點的地方恐怕收效也不會特別大,現(xiàn)在少做無用功,或許要重點考慮如何備份,如何優(yōu)化,以及出現(xiàn)問題的時候如何做到快速恢復(fù)。有一個或許會引起爭議的建議是,除了 SSH 登錄之外,要不要留一個 Telnet 登錄的服務(wù)呢? 畢竟 SSH 服務(wù)器端守護進程不是百分百靠譜的事兒,如果 IDC 距離較遠,需要斟酌一下。好吧,網(wǎng)站有了一點發(fā)展,用戶量也增加了,感覺需要增加服務(wù)器了。再增加一臺服務(wù)器,抗風(fēng)險能力一下子加強了許多,畢竟一臺機器質(zhì)量再好,也有出錯的時候。現(xiàn)在,Web 服務(wù)器、DB 服務(wù)器可以考慮引入 HA 的方案,如果單臺服務(wù)能力夠,主備模式也不錯。隨著網(wǎng)站的發(fā)展,服務(wù)器數(shù)量繼續(xù)增加…

隨著服務(wù)器數(shù)量的增加,到了必須要自己購買網(wǎng)絡(luò)設(shè)備的時候了。同樣的設(shè)備,一買恐怕就要買雙份,原因無它–一臺總要出錯,哪怕是電源被拔錯–而這樣的情況實際上并不少見。如果預(yù)算不夠,那就再等等,但是要記住,定期審查,有可能的話,進行彌補總不會錯。

到現(xiàn)在,所有的服務(wù)器都還在一個 IDC 呢,IDC 本身也是個單點啊,服務(wù)器被黑怎么辦? 機房光線被施工工人挖斷怎么辦? 機房停電怎么辦? 找第二個機房吧?,F(xiàn)在選 IDC 首先要考慮什么? 中國特色的互聯(lián)網(wǎng)問題總要考慮吧,”南北互通”怎么樣…或許在選擇第一個機房的時候已經(jīng)遇到了類似的問題,或許現(xiàn)在正在受到這個問題的困擾。選好 IDC 之后,首先計劃一下數(shù)據(jù)如何備份過來,然后,網(wǎng)站的配置信息如何同步或備份過來(這是保證第一個 IDC 出了致命問題之后的最基本的恢復(fù)要求)。多個 IDC 之后不得不提上議程的要算 DNS 這個事兒了。你的 DNS 解析商靠譜么? 如果域名提供商遭受攻擊,對自己的網(wǎng)站影響能承受么?

更多的服務(wù)器,提供更多的應(yīng)用,更多的用戶,更多的收入… 接下來該怎么辦呢? 現(xiàn)在,您所面對的已經(jīng)不是一個小型 Web 站點了,可以不用看這篇文章了。

到現(xiàn)在,我還沒說人的問題,如果這些信息只有一個人知道,萬一這個人出了點事情怎么辦? 作為老板,還要考慮人的單點問題。

Updated: DNS 的健康程度檢查重要性應(yīng)該提升一些。如何檢查?有很多在線的工具可供使用,簡單直接。



上一篇:網(wǎng)站運維之道 關(guān)于可用性
下一篇:網(wǎng)站運維之道 之自動化管理

相關(guān)熱詞搜索:Arch SPOF