圓桌會議：使用 VMware SRM 和 NetApp 為 Microsoft 應用程式進行災難恢復

2010 年 2 月發行的 Tech OnTap 電子報是以有關使用 VMware®、NetApp® 和 Cisco 技術虛擬 Microsoft 應用程式的文章作為號召。為了後續追蹤這篇文章，這次特別邀請了 VMware 公司的 Wen Yu 與 NetApp 公司的 Larry Touchette，一起深入探討 Microsoft® 應用程式的災難恢復詳細資訊，以及瞭解在 VMware 與 NetApp 環境中為何 DR 使用率偏高的原因。

探討一：人們對於在 Microsoft 應用程式環境中廣泛使用線上災難恢復似乎有所猶豫。您認為構成這種情形的因素為何？

Wen Yu (VMware) 說：『在 VMware，我們一般會發現有三個主要原因。第一個原因是執行災難恢復 (DR) 所需的成本，這或許是最重要的原因。您不僅需要第二套設施—您還需要一些額外的伺服器、網路設備，以及兩倍的儲存空間。不論您是使用實體或虛擬伺服器，這些成本都相當高。』

第二個原因是執行 DR 的相關複雜度一直很高 (尤其是在實體伺服器環境中)，而當您嘗試執行橫跨多個應用程式的 DR 時，情況更是如此。結果便是您會混合使用各式各樣的產品和技術來完成這項工作。而其中許多產品還會要求兩者具有幾乎完全一致的組態，但這會使成本增加。

最後，對許多人而言，達到適當 RPO 所需的網路頻寬可能會是一種限制。很多使用 Windows® 的企業可能沒有進行複寫所需的頻寬，而且遲遲不敢投資進行複寫所需的頻寬。

NetApp、Cisco 和 VMware 所建立的聯合解決方案解決了其中許多的問題。

Larry Touchette (NetApp) 說：『在此進一步闡述 Wen 的最後一個看法，NetApp 和 VMware 大幅降低了 DR 的成本與複雜度，因此您得以部署一個涵蓋了更多應用程式 (有需要時可以涵蓋整個 VMware 環境) 的解決方案。有些我們共同的客戶已經能夠以在主要 VMware 儲存裝置上使用 NetApp 重複資料刪除技術所省下的金錢，來補貼或甚至完全支付 DR 環境所需的儲存裝置。任何閱讀過 Tech OnTap 電子報的人早已完全瞭解 NetApp 重複資料刪除技術的功能與 VMware 結合時的優勢。』[TOT 編輯表示本文是深入瞭解 VMware DR 與 NetApp 重複資料刪除技術的一個好開端。]

就節省頻寬而言，NetApp SnapMirror® 技術與 NetApp 重複資料刪除技術搭配使用時，只會複寫獨特的區塊，所以非常節省頻寬使用率。NetApp 最近在 Data ONTAP® 中加入 SnapMirror 壓縮功能以加快 WAN 的速度，根據資料的壓縮性而定，此壓縮功能最多可將頻寬使用率減少 70%，因而在頻寬有限的環境中效果甚至更好。[TOT 編輯的話：如需 SnapMirror 壓縮的詳細資訊，請參閱前期 Tech OnTap 文章。]

在具 VMware 與 NetApp 方案的環境中，DR 被採用的機會相當高。我認為是上述這些因素造就了較高的使用率。

探討二：為何會有人選擇在 VMware 與 NetApp DR 組態中使用 VMware Site Recovery Manager (SRM)？

Wen 說：『在虛擬化應用程式伺服器的 DR 中，最關鍵的部分就是在 DR 站台上執行連接、編制、重新設定及啟動虛擬機器所需的步驟。手動執行這些工作可能很複雜而且容易出錯，尤其是在您必須依序啟動 VM 的時候。當然，您可以撰寫指令碼，試著自動執行 DR 程序，並處理這些問題，但這些指令碼的執行，成本往往很高而且難以維護。』

Site Recovery Manager 簡化了整個 DR 程序的管理工作，包含瀏覽與組態設定、容錯移轉及 DR 測試。您在 SRM 組態的規劃階段中建立的恢復計劃，可讓您預先設定整個計劃。此軟體中內建的瀏覽功能，以及與 vCenter 的緊密整合加快了這個程序。

當產生計劃後，使用者即可自動執行該計劃，期間只需要使用者偶而介入操作。SRM 能夠以正確順序執行所有必要性步驟，並以正確順序啟動虛擬機器。例如，可以先啟動支援 Active Directory® (AD) 與 DNS 伺服器等基礎結構的虛擬機器，接著啟動資料庫伺服器、應用程式伺服器，然後再啟動 Web 伺服器。

執行測試的能力是另一大好處。在不中斷正常運轉作業和正進行中複寫作業的情況下，大多數 DR 解決方案幾乎都無法進行測試。SRM 與 NetApp 讓執行 DR 測試變得更為簡單且更有效率。例如，您必須建立一個隔離的測試網路 (如此一來，您公司網路上的每一個 VM 就不會不慎有兩個作用中的執行個體)。SRM 會自動執行此程序，讓您的測試保持隔離狀態。

Larry 說：『使用 NetApp FlexClone® 技術搭配 SRM DR 測試時，您可以顯示 DR 站台並在其中執行測試，而不需使用大量額外的儲存空間，也不需中斷站台之間的正在進行的複寫作業或主要站台上的作業。讓您可以輕鬆執行測試來驗證 DR，而不會影響製作站台或議定的 SLA。』

有些複寫解決方案需要兩倍的容量才能在 DR 站台建立儲存複本，以便在您執行測試時繼續進行複寫工作。這浪費了許多的時間，並縮短您可以維持測試環境的時間或可以執行測試的頻率。使用 FlexClone 可大幅減少所需的儲存空間量，並加快處理程序。

 

圖 1) 使用 FlexClone 進行 DR 測試時所增加的儲存需求。

探討三：對於想部署採用 VMware SRM 和 NetApp 儲存技術的 DR 解決方案的人而言，需考量哪些重要事項？

Wen 說：『從 SRM 的觀點來看，需要考量的事項有很多。首先，每個站台上都要有 VMware vCenter 伺服器及 Microsoft SQL Server，用來儲存 SRM 資料庫與執行 ESX 支援版本的伺服器。

您必須透過可靠的 IP 網路連接主要與恢復站台，而恢復站台也應該與主要站台一樣可以存取相同的公用與私人網路。最後同樣重要的是，恢復站台應具備最新的 Active Directory 與 DNS 伺服器。』

就站台之間的實際複寫而論，SRM 倚賴儲存技術 (在此實際案例中是以 NetApp 系統為首) 來執行複寫。執行第 1 層應用程式的客戶可以設定 SnapMirror 進行同步複寫，進而達到零 RPO 的境界。除了複寫以外，維護 OS 與應用程式層級的一致性也同樣重要。

Larry 說：『NetApp 使用許多元件來為 VM 本身與 Microsoft 應用程式 (Exchange、SQL Server 和 SharePoint Server) 提供一致性的複寫工作。VM 與應用程式的主要考量在於只定期複寫資料並不足夠，而是必須處於可以重新啟動每一個元件的應用程式能呈現一致性的狀態。我們已在前期技術報告中詳述完整方法。Wen 已檢閱過這份技術報告，確定其中的 VMware 資訊正確無誤。』

VM 位於 VMFS (FC 或 iSCSI LUN) 或 NFS 共用資料存放區中。NetApp SnapManager for Virtual Infrastructure 為 VM 資料提供一致的 Snapshot™ 副本與複寫作業。

其中有個關鍵設計元素就是我們將應用程式資料存放在實體模式的 RDM LUN (iSCSI 或 FC)，使其與 VM 資料存放區分開。如此一來，我們即可使用產品的 NetApp SnapManager 套件，建立適用於每個應用程式的一致恢復點，而且我們還可以建立不同的恢復點數目，讓每個應用程式有不同的複寫排程來適應不同的 RPO。

 

圖 2) 複寫架構。

探討四：我們做了許多努力，以便能夠產生多個可用來重新啟動應用程式的恢復點。您是否可以再多告訴讀者一些資訊？

Larry 答：『適用於 SQL Server、Exchange 和 SharePoint 的 NetApp SnapManager 產品能夠建立與驗證複寫至恢復站台的多個恢復點，進而增加其靈活度。SnapManager 應用程式會建立完整備份 (經驗證為應用程式提供一致性的備份)，加上更多頻繁備份 (僅包含在兩次完整備份之間發生的遞增變更記錄)。這些遞增備份也稱為頻繁恢復點 (FRP) 備份。調整 FRP 備份之間的時間，便能彈性針對每一個應用程式個別設定所要的 RPO。』

如果在恢復站台上的已恢復應用程式資料中偵測到任何問題，則個別的應用程式可以還原至任何先前的恢復點。如果應用程式已還原至先前的恢復點，則 SnapManager 即可向前恢復任何未認可的資料庫記錄，以預防遺失任何在容錯移轉後於恢復站台寫入的新資料。

SRM 可讓您將自訂命令嵌入恢復計劃中。我們使用此功能在恢復計劃中執行可設定 SnapDrive® 的命令，讓在 DR 站台上執行的 VM 能夠查看從生產站台複寫之備份的完整歷程記錄。針對有權存取 NetApp NOW™ (Web 版 NetApp) 站台的使用者，請參閱 KB56952 以獲得有關此程序的完整說明。

探討五：是否可以請您們其中一位說明 Active Directory 在 SRM 環境中的重要性？

Wen 說：『Microsoft 應用程式高度依賴 Active Directory 與 DNS 組態才能正常運作，所以您必須在恢復站台上予以正確設定。當您執行 DR 測試時，您還必須確定在隔離的測試網路上提供正確設定且最新的 Active Directory 伺服器。當您在發生錯誤後從恢復站台回復到主要站台時，您必須再次確定正確地處理 Active Directory/DNS 伺服器。如果沒能這麼做，則可能會發生更新序號 (USN) 回復問題與 Active Directory 資料庫損毀。請參閱 Microsoft 知識庫文章 875495 以獲得有關這些問題的完整說明。』

在恢復站台上確保 Active Directory 正確無誤的最簡單方式，就是在恢復站台上至少維持一部與主要站台同步處理的 Active Directory 伺服器。

若要進行 DR 測試，您必須在執行 DR 測試前複製此 AD 伺服器。複製完成以後，但在啟動 VM 之前，請確定所複製的 AD 伺服器僅連接至 DR 測試網路。在測試網路中啟動 AD VM 之後，必須根據 Microsoft 知識庫文章 255504 中所描述的程序，取得 Active Directory 樹狀中的 5 個 FSMO (彈性單一主機操作) 角色。

發生真正的容錯移轉時，不需要執行此複製程序，但仍需以手動方式取得 FSMO 角色。從任何災難恢復以後，但在錯誤後回復之前，您必須在原始站台上重建 Active Directory 服務。在該站台上恢復 AD 伺服器並強制這些伺服器與恢復站台上較新的 AD 伺服器重新同步處理，或建立新的 AD 伺服器，即可完成此作業。

如需上述所有動作的詳細說明，請參閱 Larry 先前所提到的 NetApp TR-3822。

探討六：最後，可否請兩位稍微談一下錯誤後回復至原始站台時的可行方法？

Wen 說：『如同我剛才的建議，第一個步驟就是在原始站台啟動並執行後，立即啟動 Active Directory。SRM 尚未提供完全自動化的反轉與錯誤後回復，但我們仍建議您使用 SRM 進行錯誤後回復，其做法是將軟體重新設定為以反向停止運作。』

Larry 說：『為了錯誤後回復，您必須同步處理恢復站台與原始站台之間的資料。SnapMirror 可很容易地就可反轉與重新同步處理。重新同步處理程序多少會取決於所發生的錯誤。如果原始儲存裝置並未在災難中毀壞，則 SnapMirror 只必須複寫差異部分，即在原始站台離線時所發生的變更。否則，需要完整的重新同步處理。當然，在任一種情況下，NetApp 重複資料刪除技術與 SnapMirror 壓縮技術都可降低 WAN 影響。重複資料刪除技術會消除擁有很多份相同的虛擬作業系統時所產生的重複資料，以減少 VMware 環境中的總資料量，而壓縮功能則會確保透過 WAN 傳輸的所有資料，使用盡可能最少的頻寬。』

我們希望上述從圓桌會議摘錄下來的資訊對您有所幫助，並很樂意收到您對於本文的意見看法。如需所討論到的主題的完整詳細資料，請參閱 TR-3822。

	Wen Yu 資深技術聯盟經理 VMware 公司 Wen 在 VMware 公司服務已超過五年，負責支援及推廣適用於持續可用度、災難恢復和桌面的虛擬化產品。他目前是基礎架構聯盟技術團隊 (Infrastructure Alliance Technology Team) 的成員。
	Larry Touchette 技術行銷工程師 NetApp 公司 Larry 已在 NetApp 公司服務九年的時間，負責支援、執行及設計 NetApp 儲存裝置與災難恢復解決方案。他目前是 NetApp 伺服器虛擬化技術行銷團隊 (NetApp Server Virtualization Technical Marketing Team) 的成員。