雲數據-欲練神功必先寫文檔

當構建DR計劃時，第一步是查看用來交付IT服務的應用，而且決定災難發生時須要保護什麼。這意味着建立須要運行的應用和服務的清單。不少企業已經轉向虛擬化做爲其核心服務器的部署模型;可是，仍然須要考慮物理服務器。完善的雲數據恢復計劃應該包括以下：

用來交付基礎架構的物理和虛擬服務器。這些包括活動目錄(AD)服務器，DNS/DNCP服務器和應用。

• 用來交付應用的物理服務器。爲何還在物理服務器上交付服務，這須要有好一點的理由;這可能包括擴展和性能要求，或者使用自定義硬件和操做系統。可是，雲恢復服務可能可以幫助虛擬化其中一些組件。
• 用來交付應用的虛擬服務器。可能有幾十臺或者上百臺虛擬機用來實現應用。每臺都須要確認和記錄、查看存儲、內存和虛擬處理器需求。

最好提早肯定基礎架構服務器,由於當災難發生時這些系統須要第一時間恢復服務。能夠預配置在雲上運行的AD、DNS和DNCP服務，而且和它們的內部實例同步，讓DR流程更加容易，也可以更快實現。

要想讓雲上的DR可以成功工做，理解網絡配置相當重要。這意味着須要花時間理解網絡層的應用之間的相互依賴關係，包括安全和防火牆配置。雲數據恢復相關的問題有：

• 是否有應用或者服務器互相之間有延遲依賴?
• 是否有East-West防火牆規則來管理站內流量?
• 面向客戶的應用的外部帶寬需求是什麼?

肯定雲數據恢復需求

假定在災難事件發生時，每一個應用都須要當即恢復，這並不太實際。相反，應該基於一系列條件來區分應用的優先級，來決定須要多快，以及哪些同步系統和數據須要恢復運營。在決定恢復應用的服務等級時，可使用一些標準來進行度量：

• 恢復時間目標。它衡量在應序備份而且運行以前能夠容忍多長的下線時間;一般以分鐘或者小時計量。好比，零RTO表示徹底不能容忍掉線，而一小時的RTO意味着應用必須在DR發生的一小時內完成恢復。
• 恢復點目標。它衡量一旦應用再次運行時能夠容忍丟失多少數據。零RPO意味着全部數據都必須恢復到災難發生點，而24小時的RTO意味着恢復後數據或系統能夠過期24小時。
• 服務級別目標。SLO衡量總體應用的恢復狀況。好比，協議多是在四小時內恢復90%的應用。越嚴格的SLO要求越多的基礎架構支撐而且可能須要越多的人力才能達到，所以留有必定的靈活度有助於管理DR的費用。
• SLO 容許區分數據和應用的優先級。好比，一個在線信用卡處理系統要求零RPO和很是低的RTO。指望這樣的系統永遠也不會丟失信息是合理的。另外一種極端情 況是，負責報告的應用可能可以容忍24到48小時的數據過時時間，由於其數據是從其餘應用裏抽取出來的。其餘系統大多數處在這兩種極端狀況之間。

創建正確的雲數據恢復需求包括和應用程序的業務全部者溝通，由於他們瞭解其應用的重要程度。從經驗上看，業務全部者會認爲其全部應用都很重要——直到他們瞭解恢復所需的費用爲止。所以能夠告訴他們不一樣方案的費用評估。

服務級別的最後一點是：一些嚴格的需求，好比零PRO，基於雲的DR是沒法達成的，由於本地和雲位置之間會有延時。須要將這些應用排除在基於雲的DR以外，而且提供更多定製的DR產品。

DR服務會運行多久?

最後須要討論的是，服務會在公有云上運行多久。作這樣的決策依賴於發生的事件類型。並不是全部災難都會致使全部在線功能的崩潰。還會存在一些邊緣事件類型，好比：

• 服務器丟失。要麼是物理服務器，要麼是虛擬服務器主機。虛擬服務器的丟失可能很嚴重，但也可能不嚴重，應用程序須要轉而運行在DR模式。
• 多系統丟失。好比，若是共享存儲陣列出問題的話，可能會失去多個應用。
• 數據中心丟失。在最壞的狀況下，整個數據中心都丟失了，或者訪問不了。全部服務都須要運行在DR模式下。

有時候，服務須要移動幾個小時或者幾天。當整個站點都丟失時，需求多是運行DR服務幾周或者幾個月，直到重建了以前的設備。雲恢復服務會爲所使用的活動服務計費，所以在選擇DR服務時這是很重要的考覈點

更多Linux諮詢請查詢www.linuxprobe.com