虛擬化實戰 容災設計之一設計方法

2021-09-04 15:05:52 字數 1852 閱讀 7528

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

深入了解商業需求

上圖列出了一些

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

yy需求2

ny參考:

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...