這是每個工程師的噩夢：雲服務提供商突然中斷，導致系統故障。產品故障，憤怒的客戶抱怨服務停止。這可能會嚴重影響企業的聲譽，並質疑產品的可靠性。
AWS首席技術官Wernervogels談到了故障設計架構。他說，無論你或你的雲供應商在數據中心運營方面有多好，總有一天數據中心會中斷。
即使是最大的。最成功的公司也會成為失敗的受害者——Facebook。Slack和AWS最近就是一個例子。雖然並不是所有的停機都是雲造成的，但AWS最近的一個例子已經證明是可行的。主動業務連續性(BCp)和災難恢複(DR)計劃，以及每個計劃的操作手冊。
雖然BCp和災難恢複通常分為一類，但業務連續性往往低於災難恢複。BCp通常是指典型的雲中斷，DR是指因惡意行為或其他破壞性事件而完全破壞所有數據的情況。對於BCp計劃，數據和服務器的多個副本通常就足夠了，災難恢複計劃需要更多的備份和協議。
另一個需要確定的重要方面是恢複點目標(RpO)和恢複時間目標(RTO)。RTO是指企業在災難中恢複時能夠承受的斷開連接時間。RpO是指在不損害企業聲譽或違反服務水平協議(SLA)的情況下，在災難中可能丟失的數據量(如24小時)。
由於這些重要因素已經確定，如何保護您的組織在另一個雲中斷或任何其他可能的問題時?以下是在最壞情況發生後准備和恢複服務的一些步驟。
創建多可用區域部署。
BCp是最簡單的。最常見的結構是在同一區域至少使用兩個可用區域(AZ)。例如，在AWS上，每個區域光纖和低延遲連接，每個區域由三個AZ組成。這可以保持服務的正常運行，以便在AZ出現故障時繼續為客戶提供服務攜號轉用儲值卡2021。
需要注意的是，這種結構可能涉及到設計階段需要考慮的內部成本。
單個AZ用於多區域部署。
在這種情況下，您將在兩個不同區域的AZ上實現應用程序和數據庫。這樣你就可以在一個區域停機時提供服務。
這兩個AZ可以通過以下方式部署:
每個地區將使用負載平衡器或DNS(域名系統)為50%的工作負載提供服務。
主區域將為大部分或全部流量提供服務，第二區域將在出現故障時為用戶提供服務。如果您選擇此路線，您可能需要自動執行故障切換任務。
使用多AZ和多區域部署。
最近一次AWS故障發生在北弗吉尼亞州(US-East-1)。由於網絡的影響，它影響了整個地區。如果您的所有基本工作負荷都在該地區運行，您的服務將不可避免地受到影響。這意味著在該地區的AWS服務恢複之前，你所有的服務都將暫停——你把所有的雞蛋放在一個籃子裏!這是一種罕見的情況。網絡故障會影響多個AZ。
在這種情況下，最好的保護措施是在不同的位置運行不同的工作負荷和備份，以便您可以繼續為不同地區的客戶提供服務。
當然，運營區域越多，環境就越複雜，雲賬單就越貴。因此，考慮到你的產品實際上有多重要，在哪裏建立業務應該有策略。您將需要額外的努力，以確保您的產品能夠在所有情況下發揮作用，以確保盡可能多的區域多樣化。
精選文章：
