[[125412]]

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

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

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

編寫故障切換算法時(shí)要留意的問題

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

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

1. 閏年日期

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

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

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

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

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

為了解2的平方根，你先讓算法從1.4這個(gè)初始近似值開始處理。你設(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è)初始近似值開始處理。你發(fā)現(xiàn)，結(jié)果并不向預(yù)期的值收斂――它與***個(gè)數(shù)值算法得到的近似答案偏差很大。

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

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

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

所有PaaS（無論開源還是閉源）都位于在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è)施專業(yè)公司無法確定一臺(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è)施專業(yè)公司對(duì)比一下。確保你備份了所有虛擬機(jī)，這是一項(xiàng)日常任務(wù)。

結(jié)束語

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

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