本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
高可用性不是災難復原
可用性和災難復原都依賴一些相同的最佳實務,例如監控故障、部署到多個位置,以及自動容錯移轉。不過,可用性著重於工作負載的元件,而災難復原著重於整個工作負載的分散副本。災難復原與可用性有不同的目標,可測量符合災難之較大規模事件後的復原時間。您應該先確保您的工作負載符合可用性目標,因為高度可用的架構可讓您在發生可用性影響事件時滿足客戶的需求。您的災難復原策略需要與可用性不同的方法,專注於將離散系統部署到多個位置,以便您可以在必要時容錯移轉整個工作負載。
您必須在災難復原規劃中考慮工作負載的可用性,因為這會影響您採取的方法。在一個可用區域中的單一 Amazon EC2 執行個體上執行的工作負載沒有高可用性。如果本機洪水問題影響該可用區域,則此案例需要容錯移轉至另一個可用區域,以符合 DR 目標。將此案例與部署的高可用性工作負載進行比較,多站台作用中/作用中,其中工作負載部署在多個作用中區域,且所有區域都在提供生產流量。在這種情況下,即使不太可能發生的大規模災難導致區域無法使用,DR 策略是透過將所有流量路由到其餘區域來完成。
您處理資料的方式在可用性和災難復原之間也不同。請考慮持續複寫到另一個網站的儲存解決方案,以實現高可用性 (例如多站台、主動/主動工作負載)。如果主要儲存裝置上的檔案遭到刪除或損毀,這些破壞性變更可以複寫到次要儲存裝置。在這種情況下,即使高可用性,在資料刪除或損毀時容錯移轉的能力仍會受到影響。相反地,在 point-in-time備份。