快速溫變試驗箱分布式系統(tǒng)的可靠性指的是什么?
快速溫變濕熱試驗箱 技術(shù)規(guī)格:
型 號 |
SES-225 |
SES-408 |
SES-800 |
SES-1000 |
SES-1500 |
內(nèi)箱尺寸 (W x D x H cm) |
50×60×75 |
60×80×85 |
80×100×100 |
100×100×100 |
100×100×150 |
外箱尺寸 ( W x D x H cm) |
115×125×160 |
125×145×170 |
145×195×185 |
155×225×195 |
250×125×190 |
承載重量 |
20kg |
30kg |
30kg |
50kg |
75KG |
溫度速率 |
等均溫/平均溫5℃/min、10℃/min、15℃/min、20℃/min。 |
||||
溫度范圍 |
-70℃~﹢180℃ |
||||
溫度均勻度 |
≤2℃ |
||||
溫度波動度 |
±0.5℃ |
||||
溫度偏差 |
±2℃ |
||||
溫變范圍 |
-40℃/-55℃~+125℃(高溫至少+85℃以上) |
||||
濕度范圍 |
20%~98% |
||||
濕度偏差 |
±3%(>75%RH), ±5%(≤75%RH) |
||||
腳輪 |
4個(外形尺寸不含腳輪)腳輪增高50~120mm |
||||
觀察窗 |
450×450mm帶加熱裝置防止冷凝和結(jié)霜 |
||||
測試孔 |
φ100mm位于箱體右側(cè)(人面朝大門) |
||||
照明燈 |
35W/12V |
||||
節(jié)能調(diào)節(jié)方式 |
冷端PID調(diào)節(jié)方式(即加熱不制冷,制冷不加熱),比平衡調(diào)溫方式節(jié)能40% |
||||
加熱方式 |
鎳鉻合金電熱絲(3重超溫保護(hù)) |
||||
制冷機(jī) |
德國原裝進(jìn)口品牌壓縮機(jī) |
||||
制冷劑 |
環(huán)保制冷劑R404a / R23(臭氧耗損指數(shù)均為0) |
||||
冷卻方式 |
水冷(水溫7℃~28℃,水壓0.1~0.3Mpa),以便確保降溫性能 |
||||
控制器 |
7寸彩色觸摸屏控制器 |
||||
運(yùn)行方式 |
程式運(yùn)行+定值運(yùn)行 |
||||
傳感器 |
PT100 |
||||
通訊功能 |
RS485 標(biāo)配USB |
||||
曲線記錄功能 |
觸摸屏自動記錄 |
||||
電源 |
380V±10%/50HZ,三相四線+地線(3P+N+G) |
人們對于一個東西是否可靠,都有一個直觀的想法。人們對可靠軟件的典型期望包括:
?應(yīng)用程序表現(xiàn)出用戶所期望的功能。
?允許用戶犯錯,允許用戶以出乎意料的方式使用軟件。
?在預(yù)期的負(fù)載和數(shù)據(jù)量下,性能滿足要求。
?系統(tǒng)能防止未經(jīng)授權(quán)的訪問和濫用。
如果所有這些在一起意味著“正確工作”,那么可以把可靠性粗略理解為“即使出現(xiàn)問題,也能繼續(xù)正確工作”。
造成錯誤的原因叫做故障(fault),能預(yù)料并應(yīng)對故障的系統(tǒng)特性可稱為容錯(fault-tolerant)或韌性(resilient)?!叭蒎e”一詞可能會產(chǎn)生誤導(dǎo),因為它暗示著系統(tǒng)可以容忍所有可能的錯誤,但在實際中這是不可能的。比方說,如果整個地球(及其上的所有服務(wù)器)都被黑洞吞噬了,想要容忍這種錯誤,需要把網(wǎng)絡(luò)托管到太空中——這種預(yù)算能不能批準(zhǔn)就祝你好運(yùn)了。所以在討論容錯時,只有談?wù)撎囟愋偷腻e誤才有意義。
注意故障(fault)不同于失效(failure)。故障通常定義為系統(tǒng)的一部分狀態(tài)偏離其標(biāo)準(zhǔn),而失效則是系統(tǒng)作為一個整體停止向用戶提供服務(wù)。故障的概率不可能降到零,因此*好設(shè)計容錯機(jī)制以防因故障而導(dǎo)致失效。本書中我們將介紹幾種用不可靠的部件構(gòu)建可靠系統(tǒng)的技術(shù)。
反直覺的是,在這類容錯系統(tǒng)中,通過故意觸發(fā)來提高故障率是有意義的,例如:在沒有警告的情況下隨機(jī)地殺死單個進(jìn)程。許多高危漏洞實際上是由糟糕的錯誤處理導(dǎo)致的,因此我們可以通過故意引發(fā)故障來確保容錯機(jī)制不斷運(yùn)行并接受考驗,從而提高故障自然發(fā)生時系統(tǒng)能正確處理的信心。Netflix公司的Chaos Monkey 就是這種方法的一個例子。
盡管比起阻止錯誤(prevent error),我們通常更傾向于容忍錯誤。但也有預(yù)防勝于**的情況(比如不存在**方法時)。**問題就屬于這種情況。例如,如果攻擊者破壞了系統(tǒng),并獲取了敏感數(shù)據(jù),這種事是撤銷不了的。但本書主要討論的是可以恢復(fù)的故障種類,正如下面幾節(jié)所述。
硬件故障
當(dāng)想到系統(tǒng)失效的原因時,硬件故障(hardware faults)總會**個進(jìn)入腦海。硬盤崩潰、內(nèi)存出錯、機(jī)房斷電、有人拔錯網(wǎng)線……任何與大型數(shù)據(jù)中心打過交道的人都會告訴你:一旦你擁有很多機(jī)器,這些事情總會發(fā)生!
據(jù)報道稱,硬盤的平均無故障時間(MTTF, mean time to failure)約為10到50年。因此從數(shù)學(xué)期望上講,在擁有10000個磁盤的存儲集群上,平均每天會有1個磁盤出故障。
為了減少系統(tǒng)的故障率,**反應(yīng)通常都是增加單個硬件的冗余度,例如:磁盤可以組建RAID,服務(wù)器可能有雙路電源和熱插拔CPU,數(shù)據(jù)中心可能有電池和柴油發(fā)電機(jī)作為后備電源,某個組件掛掉時冗余組件可以立刻接管。這種方法雖然不能完全防止由硬件問題導(dǎo)致的系統(tǒng)失效,但它簡單易懂,通常也足以讓機(jī)器不間斷運(yùn)行很多年。
直到*近,硬件冗余對于大多數(shù)應(yīng)用來說已經(jīng)足夠了,它使單臺機(jī)器完全失效變得相當(dāng)罕見。只要你能快速地把備份恢復(fù)到新機(jī)器上,故障停機(jī)時間對大多數(shù)應(yīng)用而言都算不上災(zāi)難性的。只有少量高可用性至關(guān)重要的應(yīng)用才會要求有多套硬件冗余。
但是隨著數(shù)據(jù)量和應(yīng)用計算需求的增加,越來越多的應(yīng)用開始大量使用機(jī)器,這會相應(yīng)地增加硬件故障率。此外在一些云平臺(如亞馬遜網(wǎng)絡(luò)服務(wù)(AWS, Amazon Web Services))中,虛擬機(jī)實例不可用卻沒有任何警告也是很常見的,因為云平臺的設(shè)計就是優(yōu)先考慮靈活性(flexibility)和彈性(elasticity),而不是單機(jī)可靠性。
如果在硬件冗余的基礎(chǔ)上進(jìn)一步引入軟件容錯機(jī)制,那么系統(tǒng)在容忍整個(單臺)機(jī)器故障的道路上就更進(jìn)一步了。這樣的系統(tǒng)也有運(yùn)維上的便利,例如:如果需要重啟機(jī)器(例如應(yīng)用操作系統(tǒng)**補(bǔ)?。?,單服務(wù)器系統(tǒng)就需要計劃停機(jī)。而允許機(jī)器失效的系統(tǒng)則可以一次修復(fù)一個節(jié)點,無需整個系統(tǒng)停機(jī)。
軟件錯誤
我們通常認(rèn)為硬件故障是隨機(jī)的、相互獨立的:一臺機(jī)器的磁盤失效并不意味著另一臺機(jī)器的磁盤也會失效。大量硬件組件不可能同時發(fā)生故障,除非它們存在比較弱的相關(guān)性(同樣的原因?qū)е玛P(guān)聯(lián)性錯誤,例如服務(wù)器機(jī)架的溫度)。
另一類錯誤是內(nèi)部的系統(tǒng)性錯誤(systematic error)。這類錯誤難以預(yù)料,而且因為是跨節(jié)點相關(guān)的,所以比起不相關(guān)的硬件故障往往可能造成更多的系統(tǒng)失效。例子包括:
?接受特定的錯誤輸入,便導(dǎo)致所有應(yīng)用服務(wù)器實例崩潰的BUG。例如2012年6月30日的閏秒,由于Linux內(nèi)核中的一個錯誤,許多應(yīng)用同時掛掉了。
?失控進(jìn)程會占用一些共享資源,包括CPU時間、內(nèi)存、磁盤空間或網(wǎng)絡(luò)帶寬。
?系統(tǒng)依賴的服務(wù)變慢,沒有響應(yīng),或者開始返回錯誤的響應(yīng)。
?級聯(lián)故障,一個組件中的小故障觸發(fā)另一個組件中的故障,進(jìn)而觸發(fā)更多的故障。
導(dǎo)致這類軟件故障的BUG通常會潛伏很長時間,直到被異常情況觸發(fā)為止。這種情況意味著軟件對其環(huán)境做出了某種假設(shè)——雖然這種假設(shè)通常來說是正確的,但由于某種原因*后不再成立了。
雖然軟件中的系統(tǒng)性故障沒有速效藥,但我們還是有很多小辦法,例如:仔細(xì)考慮系統(tǒng)中的假設(shè)和交互;徹底的測試;進(jìn)程隔離;允許進(jìn)程崩潰并重啟;測量、監(jiān)控并分析生產(chǎn)環(huán)境中的系統(tǒng)行為。如果系統(tǒng)能夠提供一些保證(例如在一個消息隊列中,進(jìn)入與發(fā)出的消息數(shù)量相等),那么系統(tǒng)就可以在運(yùn)行時不斷自檢,并在出現(xiàn)差異(discrepancy)時報警。
人為錯誤
設(shè)計并構(gòu)建了軟件系統(tǒng)的工程師是人類,維持系統(tǒng)運(yùn)行的運(yùn)維也是人類。即使他們懷有*大的善意,人類也是不可靠的。舉個例子,一項關(guān)于大型互聯(lián)網(wǎng)服務(wù)的研究發(fā)現(xiàn),運(yùn)維配置錯誤是導(dǎo)致服務(wù)中斷的首要原因,而硬件故障(服務(wù)器或網(wǎng)絡(luò))僅導(dǎo)致了10-25%的服務(wù)中斷。
盡管人類不可靠,但怎么做才能讓系統(tǒng)變得可靠?*好的系統(tǒng)會組合使用以下幾種辦法:
?以*小化犯錯機(jī)會的方式設(shè)計系統(tǒng)。例如,精心設(shè)計的抽象、API和管理后臺使做對事情更容易,搞砸事情更困難。但如果接口限制太多,人們就會忽略它們的好處而想辦法繞開。很難正確把握這種微妙的平衡。
?將人們*容易犯錯的地方與可能導(dǎo)致失效的地方解耦(decouple)。特別是提供一個功能齊全的非生產(chǎn)環(huán)境沙箱(sandbox),使人們可以在不影響真實用戶的情況下,使用真實數(shù)據(jù)**地探索和實驗。
?在各個層次進(jìn)行徹底的測試,從單元測試、全系統(tǒng)集成測試到手動測試。自動化測試易于理解,已經(jīng)被廣泛使用,特別適合用來覆蓋正常情況中少見的邊緣場景(corner case)。
?允許從人為錯誤中簡單快速地恢復(fù),以*大限度地減少失效情況帶來的影響。 例如,快速回滾配置變更,分批發(fā)布新代碼(以便任何意外錯誤只影響一小部分用戶),并提供數(shù)據(jù)重算工具(以備舊的計算出錯)。
?配置詳細(xì)和明確的監(jiān)控,比如性能指標(biāo)和錯誤率。 在其他工程學(xué)科中這指的是遙測(telemetry)。 (一旦火箭離開了地面,遙測技術(shù)對于跟蹤發(fā)生的事情和理解失敗是至關(guān)重要的。)監(jiān)控可以向我們發(fā)出預(yù)警信號,并允許我們檢查是否有任何地方違反了假設(shè)和約束。當(dāng)出現(xiàn)問題時,指標(biāo)數(shù)據(jù)對于問題診斷是非常寶貴的。
?良好的管理實踐與充分的培訓(xùn)——一個復(fù)雜而重要的方面,但超出了本書的范圍。
可靠性有多重要?
可靠性不僅僅是針對核電站和空中交通管制軟件而言,我們也期望更多平凡的應(yīng)用能可靠地運(yùn)行。商務(wù)應(yīng)用中的錯誤會導(dǎo)致生產(chǎn)力損失(也許數(shù)據(jù)報告不完整還會有法律風(fēng)險),而電商網(wǎng)站的中斷則可能會導(dǎo)致收入和聲譽(yù)的巨大損失。
即使在“非關(guān)鍵”應(yīng)用中,我們也對用戶負(fù)有責(zé)任。試想一位家長把所有的照片和孩子的視頻儲存在你的照片應(yīng)用里。如果數(shù)據(jù)庫突然損壞,他們會感覺如何?他們可能會知道如何從備份恢復(fù)嗎?
在某些情況下,我們可能會選擇犧牲可靠性來降低開發(fā)成本(例如為未經(jīng)證實的市場開發(fā)產(chǎn)品原型)或運(yùn)營成本(例如利潤率極低的服務(wù)),但我們偷工減料時,應(yīng)該清楚意識到自己在做什么。