在容災設計中需要有個清晰的思路，能幫助我們既能考慮大局，又能照顧到細節。以商業需求為主導是必須的，而不是一上來就談某個產品的具體功能。我總結了以下三個步驟：
一
深入了解商業需求
上圖列出了一些
business parameters。摘自此文。
我們著重談其中的的幾個要素：
rto（
recovery time objective）
：災難發生後要求在該時間內能恢復應用。
理論上講當然容災方案支援
rto和rpo越小越好，但千萬不能因為單純追求最小值，而造成不必要高成本，也就是所說的overengineering。好的架構師應該從客戶角度著想，提供滿足需求的方案。
在和客戶溝通的時候，一定要打破沙鍋問到底，
rto和rpo的值是怎麼來的？很多時候會發現沒有人能說清楚。這就需要從應用上著手。比如有的應用自身已經實現了高可用性，比如mscluster， lvs等等，支援該應用的infrastructure不必過分考慮容災。很多時候hypervisor自己ha就能夠滿足了。
risk
從嚴重程度（
severity）和可能性（likehood）來考慮。比如金融機構對此要求非常高，我的乙個客戶是無法接受因為系統宕機而造成的巨大損失。所以他們對風險評估後要求zerorto和zero rpo。
二 考慮影響關鍵架構設計的因素（architecture decisions）
site:
local：有的容災方案在本地實施就能滿足客戶需求
dedicated dr sites：是否需要專門的drsite，是由公司的it戰略和持續發展來決定的。當然成本上的影響很大。
shared dr site：共享的dr site出了容災外，可能也有其他用處。
cloud based recovery：可以考慮雲服務商的容災方案。比如vmware混合雲（vchs）最近推出了專門針對容災的方案。
storagereplication
software：完全使用軟體實現資料同步，不依賴sanreplication。
san based：大多數高階儲存裝置自身支援sanbased的replication。如果有很特別的需要，也可以借助軟體來實現高階的sanreplication。比如emc recovery point.
資料中心之間的網路
dr dedicated：完全是為dr專有的
mpls：公用的。
根據頻寬和同步的資料量來衡量該容災方案是否能滿足
rto和rpo需要
三 評估適合的產品（
市場上的容災產品和方案非常多。我們需要問自己一系列的問題，列出需要滿足的
feature，然後再針對每個產品來評估各項指標。
方法一： 大概評估幾個大的方面
比如rto,
rpo,cost,f
lexibility,managability 等等。
方法二 ： 細緻評估產品1
產品2
需求1 y
y 需求
2 n
y 參考：
disaster prevention and recovery architecture from rmi
drbc design- disaster recovery and business continuity fundamentals
虛擬化實戰 容災設計之一設計方法
在容災設計中需要有個清晰的思路，能幫助我們既能考慮大局，又能照顧到細節。以商業需求為主導是必須的，而不是一上來就談某個產品的具體功能。我總結了以下三個步驟 一 深入了解商業需求 上圖列出了一些 business parameters。摘自此文。我們著重談其中的的幾個要素 rto recovery t...
虛擬化實戰 容災設計之一設計方法
在容災設計中需要有個清晰的思路，能幫助我們既能考慮大局，又能照顧到細節。以商業需求為主導是必須的，而不是一上來就談某個產品的具體功能。我總結了以下三個步驟 一 深入了解商業需求 上圖列出了一些 business parameters。摘自此文。我們著重談其中的的幾個要素 rto recovery t...
虛擬化實戰 容災設計之二VR vs SRM
從本文開始，我們將介紹一系列的關於容災的解決方案。先 應用的場景，然後再深入介紹技術架構。情景一 某小型公司的虛擬化環境中，在5臺esxi伺服器上執行100臺虛擬機器。採用nfs儲存。其中需要異地恢復的虛擬機器10臺。對於異地容災rpo的要求是30分鐘，rto是1小時。已經使用vspherestan...