[[125412]]

云服務(wù)停運(yùn)事件果真發(fā)生時(shí)，通常會(huì)激活故障切換機(jī)制，以便從運(yùn)行不暢的服務(wù)器切換到正常運(yùn)行的服務(wù)器。那樣，云服務(wù)在故障切換過(guò)程中可以正常運(yùn)行，不會(huì)帶來(lái)任何破壞或干擾。

不過(guò)，故障切換算法并不總是絲毫沒(méi)有任何問(wèn)題。比如說(shuō)，算法并不總是事先告訴你有沒(méi)有足夠的資源讓算法運(yùn)行。一旦計(jì)算資源在故障切換過(guò)程中耗盡，最終結(jié)果就是云服務(wù)停運(yùn)（比如亞馬遜服務(wù)停運(yùn)）。

在停運(yùn)期間，平臺(tái)即服務(wù)（PaaS）開(kāi)發(fā)人員和軟件即服務(wù)（SaaS）用戶(hù)大聲喊著無(wú)法按時(shí)完成工作。為了迫切希望讓云服務(wù)盡快恢復(fù)正常，他們會(huì)不斷打電話(huà)給信息即服務(wù)（IaaS）提供商的技術(shù)支持部門(mén)。最終，IaaS提供商解決問(wèn)題。

編寫(xiě)故障切換算法時(shí)要留意的問(wèn)題

如果你遇到了云服務(wù)停運(yùn)事件，對(duì)IaaS提供商的故障切換算法又不滿(mǎn)意，那你可以決定編寫(xiě)自定義的故障切換算法。你需要在不同的場(chǎng)景下測(cè)試算法，確保算法運(yùn)行起來(lái)無(wú)誤。一旦所有測(cè)試返回了正面的結(jié)果，你應(yīng)該征得IaaS提供商的同意：要是提供商的故障切換算法失效，可以在下一輪云服務(wù)停運(yùn)時(shí)在生產(chǎn)環(huán)境中激活算法。

你在編寫(xiě)故障切換算法時(shí)，需要避免以下三大陷阱。

1. 閏年日期

上一個(gè)閏年日期是2012年2月29日。有人忘了檢查微軟Azure中頒發(fā)安全證書(shū)的那臺(tái)服務(wù)器是否能識(shí)別這個(gè)日期。一旦時(shí)鐘滴答滴答地報(bào)出那個(gè)日期的頭幾分鐘，一個(gè)虛擬機(jī)無(wú)法啟動(dòng)。管理員想找到并解決這個(gè)問(wèn)題并非易事。

下一個(gè)閏年是2016年2月29日，所以你有的是大把時(shí)間來(lái)避免同樣的不幸事故。你應(yīng)該在PaaS上測(cè)試幾種閏年識(shí)別算法；這可以幫助你確保安全證書(shū)會(huì)識(shí)別閏年日期。

2. 不穩(wěn)定的數(shù)值算法

你發(fā)現(xiàn)自己編寫(xiě)的一種數(shù)值算法不穩(wěn)定，可惜發(fā)現(xiàn)得太晚。該算法引起了耗費(fèi)計(jì)算機(jī)資源的無(wú)限循環(huán)。由于可供使用的資源越來(lái)越少，云服務(wù)性能越來(lái)越低下。等到一點(diǎn)資源都沒(méi)剩下時(shí)，云服務(wù)就停止運(yùn)行。

下面這個(gè)簡(jiǎn)單的場(chǎng)景可以幫助你更清楚地了解數(shù)值算法會(huì)如何變得不穩(wěn)定。

為了解2的平方根，你先讓算法從1.4這個(gè)初始近似值開(kāi)始處理。你設(shè)定了一個(gè)很小的值，算法應(yīng)該會(huì)向該值收斂。達(dá)到這個(gè)值后，算法給出近似的答案：1.41421（正如預(yù)期）。這時(shí)候，算法停止運(yùn)行；它很穩(wěn)定，因?yàn)樗尫帕速Y源，供其他計(jì)算任務(wù)使用。

你在新算法中建立略有不同的邏輯。你從1.42、而不是1.4這個(gè)初始近似值開(kāi)始處理。你發(fā)現(xiàn)，結(jié)果并不向預(yù)期的值收斂――它與***個(gè)數(shù)值算法得到的近似答案偏差很大。

答案越來(lái)越長(zhǎng)。該算法繼續(xù)陷入無(wú)限循環(huán)，不斷消耗資源。等到一點(diǎn)資源都沒(méi)剩下時(shí)，算法才停止運(yùn)行，這表明它不穩(wěn)定。

為了避免這個(gè)陷阱，你需要事先做好功課，確定該算法能不能向預(yù)期的值收斂。

3. 虛擬機(jī)管理程序失效

所有PaaS（無(wú)論開(kāi)源還是閉源）都位于在IaaS下面的虛擬機(jī)之上。所有虛擬機(jī)的創(chuàng)建和運(yùn)行由虛擬機(jī)管理程序統(tǒng)一負(fù)責(zé)。物理服務(wù)器能托管運(yùn)行多少個(gè)虛擬機(jī)，取決于物理服務(wù)器的能力/容量。

一旦虛擬機(jī)管理程序失效，所有虛擬機(jī)停止運(yùn)行。導(dǎo)致失效的一個(gè)根源是，IaaS基礎(chǔ)設(shè)施專(zhuān)業(yè)公司無(wú)法確定一臺(tái)物理服務(wù)器能托管運(yùn)行多少個(gè)虛擬機(jī)。提供商未能精確核實(shí)服務(wù)器的能力/容量。他試圖添加超出這臺(tái)物理服務(wù)器資源極限范圍的虛擬機(jī)。如果極限范圍是頂多2個(gè)虛擬機(jī)，提供商又添加一個(gè)虛擬機(jī)，那么物理服務(wù)器托管的所有虛擬機(jī)就會(huì)停止運(yùn)行。

為了避免這個(gè)陷阱，你需要弄清楚一臺(tái)物理服務(wù)器能托管運(yùn)行多少個(gè)新的虛擬機(jī)。將弄清楚的結(jié)果與IaaS提供商或IaaS基礎(chǔ)設(shè)施專(zhuān)業(yè)公司對(duì)比一下。確保你備份了所有虛擬機(jī)，這是一項(xiàng)日常任務(wù)。

結(jié)束語(yǔ)

別一味依賴(lài)IaaS提供商的故障切換算法。你可以編寫(xiě)自己的故障切換算法，不過(guò)記得在你運(yùn)行這些算法之前事先征得IaaS提供商的同意。

英文原文鏈接：http://www.techrepublic.com/article/three-pitfalls-to-avoid-when-creating-failover-algorithms-on-a-paas/