AWS現在可以讓實例從多種錯誤中恢復了，但這并不會代替真正的云彈性應用設計。
AWS EC2實例現在可以經由CloudWatch從某些錯誤狀況中恢復，但這個功能并不能完全替代云彈性應用架構。
自動恢復允許用戶在Amazon Web Service（AWS）的CloudWatch監測服務中設定臨界值。如果操作系統在Amazon那方出了問題，例如底層的硬件故障，系統斷電，網絡連接斷開或物理機的軟件問題等，實例將會原封不動的依照它的實例識別碼，IP地址，彈性塊存儲（EBS）附件和其他設定細節來自動恢復。
自動恢復暫時只適用于美東（維吉尼亞）區域的C3，C4，M3，R3和T2線的實例，雖然在AWS官方博客的一個帖子有提到將會很快在更多區域提供這個服務。實例必須要在一個虛擬私有云（VPC）之內運行并附加在一個EBS卷上才能使用自動恢復的功能。使用自動恢復功能的用戶將依照CloudWatch的價格表來收費，但對于恢復過程中使用的EC2或EBS資源是不收費的。
這個概念對于AWS一貫強調的，在應用中而不是在基礎架構層面建立云彈性的說法難免有點背道而馳，但它不會成為一個完全將應用彈性抹殺掉的捷徑，根據Glenn Grant，一家位于波士頓的云咨詢和管理服務供應商，G2 技術集團公司的CEO表示。
G2 技術集團也提供了類似的功能，通過其針對AWS的管理服務，包括監控軟件來檢查AWS云的健康度，并在必要時重啟實例。
“我認為這個功能對于過程的自動化很有幫助，”他說道。“但是，我們需要評估一下，才能完全了解它的檢查方式和臨界點，這樣才不會在不必要的時候重啟實例。”
比如，Grant想知道網絡流量很大會不會被誤判成連接的完全斷開，或者一個DoS攻擊的情景是否會導致某個實例不斷重啟。但自動恢復裝有自適應調節的控制器來確保同一實例不會被不停的恢復。
一些業界觀察者會提出一個問題：為什么Amazon沒有早點提供這個功能？“我一直很好奇為什么他們沒在幾年前就做這件事，”Carl Brooks，一名位于波士頓的451 Group的分析師說道。“我猜那是因為他們曾經這樣來告訴客戶要‘自己動手，豐衣足食’。”
總是會有這樣的風險，用戶會默認將這個功能當作一種“快捷”的圍繞恰當彈性的應用架構的方式，但這些問題和做法大家已經司空見慣了，Brooks說道。
另外也有一部分人則質疑自動恢復強制使用EBS的必要性。
“如果某個EBS卷在恢復的過程中損壞了怎么辦？”一名位于馬薩諸塞州Cambridge的Forrester Research的分析師James Staten說道。AWS拒絕對這個問題發表公開評論。
不論如何，當那些技術水平沒那么高的新顧客群采用云計算時，這種功能將很有必要，根據Staten的說法。云技術采納的第一波用戶大多數是那些很樂意編寫自動化的基礎架構恢復功能腳本或將其融入到應用中的DevOps族群，但最新的一代用戶可能不具備這種程度的云計算專業或運營經驗，他說道。
AWS的幾個競爭者都已經提供類似的恢復功能了。Google經由他們的管理VM服務來管理Google計算引擎虛擬機的可用性，進而鞏固了他們的應用引擎平臺即服務，Rackspace的云服務器是由支持人員來監測并確保他們的可用性。VMware的vCloud Air Service也會在主機故障發生時提供VMware的Live Migration功能。微軟的Azure則有服務治愈功能，可以自動偵測有問題的節點并將虛擬機移動至新的主機上。
原文鏈接：http://www.searchcloudcomputing.com.cn/showcontent_87717.htm
京公網安備 11010502049343號