[[125412]]

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

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

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

編寫故障切換算法時要留意的問題

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

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

1. 閏年日期

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

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

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

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

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

為了解2的平方根，你先讓算法從1.4這個初始近似值開始處理。你設(shè)定了一個很小的值，算法應(yīng)該會向該值收斂。達到這個值后，算法給出近似的答案：1.41421（正如預(yù)期）。這時候，算法停止運行；它很穩(wěn)定，因為它釋放了資源，供其他計算任務(wù)使用。

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

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

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

3. 虛擬機管理程序失效

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

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

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

結(jié)束語

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

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