NGS提出實施災難恢復量化的解決方案設計方法

      實施災難恢復 (DR) 解決方案需要做出明智的選擇。NetApp Global Services (NGS) 提出了一種量化的解決方案設計方法。 
  
      作者簡介 
  
      John Fullbright是NetApp的專業服務顧問，是 Exchange 領域的常駐專家。2006 年 4 月，John榮獲微軟最有價值專家 (MVP)獎。加盟 NetApp 之前，John 是微軟全球解決方案支持中心的一名快速響應工程師。作為微軟快速現場服務團隊的成員，John 經常被委派去解決微軟重要客戶遇到的難題。 
  
      實施災難恢復(DR)解決方案需要做出明智的選擇。NetApp Global Services (NGS) 提出了一種量化的解決方案設計方法。借助這種方法，全球客戶可以了解與不同方法有關的權衡點，從而做出明智的決策。 
  
      例如，美國一家大型保險公司最近發現，在24小時的時間間隔內完成磁帶備份越來越難。于是，該公司聘請 NetApp Global Services幫助為Microsoft Exchange環境設計和實施災難恢復解決方案，該公司的Exchange的環境如下所述： 
  
      一家主要子公司距離總部大約1000英里； 
  
      Exchange 裝機量多達30000個(每個站點15000個)； 
  
      Exchange 數據傳輸速率高達14TB(每個站點的數據傳輸速率是 7TB)； 
  
      光纖通道SAN基礎設施； 
  
      站點之間采用OC3連接。 
  
      本文著重介紹了影響項目的三個權衡點，以及該客戶選擇了哪種方式。 
  
      第一個權衡點 
  
      如果發生站點災難，目標是高可用性，還是不間斷的備份和恢復，抑或是遠程恢復？ 
  
      基本上可以通過兩種方法實現在線數據保護：復制(鏡像)和磁盤到磁盤備份。 
  
      通過復制，可以將數據集完全復制到另外一個存儲系統上，該存儲系統既可以在本地站點，也可以在其他站點。如果發生站點災難時的目標是確保立即恢復高可用性或遠程重新啟動操作，這種方法是最佳解決方案。這種方法不能取代備份，這是因為如果某些內容從鏡像的一方消失，那么在下一輪復制時，這些內容也會從鏡像的另一方消失。距離是一項關鍵因素，雖然可以在遠距離內實現異步復制，但是如果站點之間的距離超過80公里，那么在站點間同步鏡像數據便會受到技術上的限制。 
  
      通過功能強大的輔助磁盤，磁盤到磁盤備份和存檔方法既可作為容易出現故障的磁帶系統的補充，也可以取而代之。數據通過網絡備份到遠程位置。一旦發生災難，可以從此處恢復數據。與復制不同的是，主機不能直接連接到輔助存儲設備。相反，有了對數據集進行反復更改的歷史記錄，您可以及時地從任意點恢復數據。 
  
      在這種情況下，公司IT團隊決定使用綜合方法。實施遠程災難恢復是重中之重。該公司擁有兩個大型站點，相距 1000英里左右，具備相當出色的網絡帶寬連接能力。因此，可以毫不猶豫地決定使用NetApp鏡像軟件，以指定的時間間隔異步復制站點之間的Exchange日志文件和數據庫。此外，IT團隊選擇使用NetApp SnapVault軟件遷移到磁盤- 磁盤-磁帶的環境，從而解決了現有的磁帶備份問題。
 
      第二個權衡點 
  
      如果無法實現數學方法計算的結果，能否增加網絡帶寬或者可以接受損失多少數據量？ 
  
      為了調整DR基礎設施的規模，必須確定發生更改的數據量。因此，每天必須對其進行復制或備份。確定更改量之后，下一步就是計算出發生災難時可以負擔得起的最大丟失數據量。如果將更改量除以復制時間間隔，可以估算每個時間間隔內必須傳輸的數據量。此時需要進行權衡。如果使用數學方法得出的結果對您不利，則必須增加網絡帶寬或考慮更長的恢復點目標(RPO)，這可能導致更多數據丟失。 
  
      考察完各個組織的要求之后，該團隊建立了一個間隔為五分鐘的RPO。鑒于周期很短，我們必須在計算日志更改量時考慮峰值。具體方法是，使用在五分鐘的時間間隔內進程store.exe的每秒平均寫入次數的perfmon采樣來創建數據集。據該團隊估計，每24小時更改量大約是 200GB。如果復制時間間隔為五分鐘，則表示每隔五分鐘就要復制 700MB 左右的數據(200GB/天÷288復制周期/天)。根據其他網絡流量，峰值流量可能已經超過可用的OC3網絡(155 Mbps 或大約19MB/秒)。 
  
      IT團隊只接受五分鐘的RPO目標也不想升級網絡基礎設施。NGS 發現，對于首先寫入日志然后從日志寫入數據庫的任何事務處理應用程序，更改量由分散的兩部分組成。新數據首先寫入日志文件，然后寫入數據庫。因此，一半的更改量 (100GB) 將來自日志文件。 
  
      1.通過每五分鐘只復制日志，該公司在將寬帶需求減半的同時仍實現五分鐘的 RPO 目標。 
  
      Exchange 數據庫每隔 4 小時便復制一次。峰值流量不會超過13MB。這樣，不僅為日志文件提供了高級數據保護，而且將負載更加均勻地平攤到全天，從而有助于降低對網絡和主存儲設備的影響。 
  
      這種方法可能存在著一個缺點，即恢復時間與重放這些日志有關。測試完該過程之后，NGS 確定重放日志只使恢復時間增加五分鐘左右。隨著時間不斷擴大，帶寬使用范圍和削減整體帶寬需求所具有的優點遠遠勝過這種方法帶來的影響。 
  
      2.隨時控制I/O速率，確保決不會超過網絡容量。 
  
      通過兩種 NetApp 產品，NGS幫助客戶進一步減小復制和備份流量的影響，可以對SnapVault和SnapMirror(r) 進行調節，使它們不超過指定的I/O速率。并非所有的DR 應用程序都支持這種功能。但是，如有可能最好設置閾值，以便活動中出現的異常峰值不會導致意外的結果。 
  
      第三個權衡點 
  
      可以承受多長的停機時間？ 
  
      下一步是確定發生災難時恢復運行所需的時間。這是恢復時間目標(RTO)。RPO比較簡單，但RTO可能比較復雜，這是因為必須要考慮恢復運行所要采取的所有步驟。 
  
      為了建立實際的RTO，NGS與該公司的IT團隊通力協作，記錄與Exchange恢復聯機有關的所有內容，包括斷開復制鏈接，使復制LUN可讀/寫；將所有LUN連接到同級站點上的主機；啟動Exchange服務；重放日志；評估完所有必要步驟(包括進行必要的基礎設施更改、啟動 Exchange和重放數小時的日志文件)之后，客戶建立了為期4小時的RTO，規定Exchange數據庫的復制時間間隔不超過4個小時。 
  
      最終結果是構建多層存儲體系結構。通過與NGS的通力合作，該IT團隊在滿足原來預算要求的同時，得以構建一個提供能夠多級保護并從路由故障和站點災難恢復的基礎結構： 
  
      為了實現快速恢復，主存儲設備上最多保存每卷的30個Snapshot副本(相當于五天時間)和48個日志副本(相當于4個小時)。使用SnapVault的磁盤到磁盤備份承擔了主服務器和存儲設備上中斷的磁帶備份工作。此后，數據可以備份到磁帶，而不會影響主存儲設備或Exchange的運行。使用SnapMirror的遠程復制可以針對站點災難提供保護。在NetApp存儲設備上保存250多個Snapshot副本，不會影響性能。對于基Copy-on-Write(根據寫入的數據進行備份)的解決方案，情況并不完全是這樣。