【虛拟化實戰】容災設計之一設計方法 RPO（Recoverypoint objective）：災難發生後可以容忍資料的丢失的時間段。

作者：範軍 （Frank Fan） 新浪微網誌：@frankfan7  

在容災設計中需要有個清晰的思路，能幫助我們既能考慮大局，又能照顧到細節。以商業需求為主導是必須的，而不是一上來就談某個産品的具體功能。我總結了以下三個步驟：

一深入了解商業需求

<a target="_blank" href="http://blog.51cto.com/attachment/201309/085639974.png"></a>

我們着重談其中的的幾個要素：

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需要

三 評估适合的産品（Product Mapping）

市場上的容災産品和方案非常多。我們需要問自己一系列的問題，列出需要滿足的Feature，然後再針對每個産品來評估各項名額。

方法一： 大概評估幾個大的方面

<a></a>

方法二 ： 細緻評估

産品1

産品2

需求1

Y

需求2

N

參考：

<a href="http://www.continuityinsights.com/sites/continuityinsights.com/files/legacyfiles/B8_Ross.pdf">Disaster Prevention and Recovery  Architecture from RMI</a>

<a href="http://mylearn.vmware.com/MgrReg/courses.cfm?ui=www_edu&amp;a=one&amp;id_subject=20313">DRBC Design- Disaster Recovery and Business Continuity Fundamentals</a>

本文轉自frankfan751CTO部落格，原文連結：http://blog.51cto.com/frankfan/1288884 ，如需轉載請自行聯系原作者