高可用性矩陣-->見下圖:
郵箱服務器高可用性目標: 數據可用性-->保護郵箱數據免于失敗和損壞
????????????????????????????? 服務可用性-->提高群集實效轉移操作? 簡化群集管理? 支持地理分散的群集? 支持低成本大郵箱(GB+)
???????????????????????????? 使用戶可以基于業務需要更好的選擇容錯方案
??????????????????????????? 提高解決方案的可用性
?????????????????????????? 使用解決方案可以使用低成本存儲硬件
連續復制介紹: 數據停用后的恢復是昂貴的-->從備份中恢復非常花時間? 會丟失大部分數據
???????????????? 保留數據的一個拷貝-->必須是最新的
??????????????? 兩個配置-->本機有數據的一個拷貝? 其它機器上也有數據的一個拷貝? 見下圖:
連續復制原理: 創建數據的一個拷貝?
???????????????? 原來的數據改變時,給拷貝應用同樣的改變-->不必重新復制所有數據
??????????????? 提供了及時更新的拷貝
ESE日志: 日志文件是數據庫變動列表-->物理變化都會記到日志中
??????????? 用于崩潰時數據恢復
?????????? 基本技術是工業標準
記錄數據庫更新-->見下圖:
執行復制: 創建一個數據庫備份? 當日志記錄創建后,在復本應用日志中的改變? 見下圖:
LCR/CCR 基本架構: Exchange 存儲正常運行?
??????????????????????? 復制服務保持數據庫的一個最新復本-->復制和重放日志記錄
?????????????????????? 群集服務提供CCR失效轉移-->保留同樣的網絡身份(對客戶端透明)
????????????????????? LCR的失效轉移是手動的-->恢復--存儲組復制任務
ESE 日志文件: 每個存儲組會分配一個數字(第一個是00)
????????????????? 每個日志文件會產生一個數字,從1開始
????????????????? Exx.log(e.g. E00.log)是當前日志文件
????????????????? 一個完整的Exx.log會用它產生的數字重命名
???????????????? 樣例日志文件-->E0000000001.log? E0000000002.log? E00.log(當前日志文件)
??????????????? 當Exx.log寫滿時-->E0000000001.log? E0000000002.log? E00.log重命名為E0000000003.log? 新的E00.log被創建
日志詳細信息: 記錄的變動是物理的,不是邏輯的-->提交一個信息實際上是很多底層的物理操作
????????????????? 先寫日志-->數據庫頁面在內存中被改變? 日志寫入磁盤? 數據庫頁面寫入磁盤
???????????????? 變動是累積在一起的
日志復制: 推模式
??????????? Exchange Server 正常創建日志文件
?????????? 日志文件被復制服務復制-->Exxnnnnnnnn.log文件在產生時被復制
????????? Exx.log在控制轉移/失效轉移時復制-->若未復制,會丟失數據
日志驗證: 日志文件復制到檢查目錄
??????????? Checksum和簽名被驗證-->Checksum錯誤時,日志文件會重新復制? 若日志文件無法復制,需要重新播種(ReSeed)?
?????????? 日志文件被檢查后會被復制到日志目錄
日志重放: 應用日志中的變動到數據庫中?
??????????? 特別的恢復模式-->不同于'eseutil /r'? 撤銷階段被忽略
?????????? 如果可能,日志文件批量重放-->提升性能?
獲取存儲組復制狀態: LastLogCopyNotified-->在源目錄最新產生的日志
???????????????????????? LastLogCopied-->復制服務復制的最新日志? 復制到檢查目錄
??????????????????????? LastLogInspected-->檢查過的最新日志? 移動到日志目錄
?????????????????????? LastLogReplayed-->重放到數據庫復本的最新日志
????????????????????? 可通過"性能"監控到
CCR失效轉移: 群集服務監控資源-->失敗偵測不是實時的
???????????????? IP地址或者網絡名資源錯誤時導致失效轉移
??????????????? Exchange服務錯誤或者超時時不會失效轉移-->重啟服務
?????????????? 數據庫失敗不會失效轉移-->不要因為1個數據庫失敗而移動49個數據庫
CCR文件共享: 復制服務遠程運行,但需要訪問日志文件????
???????????????? 主動節點上創建共享
??????????????? 對'Exchange Servers'組可讀
?????????????? 'Exchange Servers'組授權R/O訪問權限-->僅CCR服務器
單服務器數據可用性: 問題: 數據損失要恢復很昂貴? 大量數據丟失? 復制需要集成合作伙伴產品
???????????????????????? LCR主要特性: 單機-->每個存儲組
????????????????????????????????????????? 兩個復本,重放
???????????????????????????????????????? 一個數據中心
??????????????????????????????????????? 容易配置
本地連續復制: 其它需求和操作-->每個存儲組手動激活? 資源開銷? 配置范圍? 備份選項? 降低備份TCO? 配置限制
???????????????? 獲益-->分鐘時間即可恢復? 無損失恢復? 降低恢復開銷? 支持大郵箱
群集連續復制: 兩節點群集?
????????????????? 兩個拷貝
????????????????? 群集-->自動恢復
????????????????? 全冗余
????????????????? 重放
???????????????? 1或2個數據中心? 見下圖:
CCR優勢: 快速恢復? 沒有單點故障? 硬件選型更靈活? 簡化存儲要求? 簡化部署? 改進管理體驗??
Exchange Server傳統群集: Exchange Server 2003-->共享存儲? 郵箱數據只有一個拷貝? 8節點群集? 2節點主動/主動模式
????????????????????????????????? Exchange Server 2007(單一副本群集)-->共享存儲? 僅郵箱? 8節點群集? 取消2節點主動/主動模式??? 見下圖:
單一副本群集: 缺少全冗余? 部署和維護復雜? 費用? 恢復時間視備份技術而不同? 兩個數據中心解決方案需要合作伙伴技術
Exchange Server 2007高可用性: 提供單點和群集解決方案? 降低部署和維護費用? 啟用高可用性選項給更多的用戶? 提高解決方案操作性? 支持低成本的大郵箱(1GB+)
Exchange Server 2007 災難恢復新特性: 操作系統-->Windows Server 2003 SP1 or later? 目前不支持Longhorn Server? 支持x64,不支持IA-64?
?????????????????????????????????????????????????? 數據庫-->未改變基本架構? Page Size 4K-->8K? No more.STM file? 2 billion log files-->E0012345678.log?? 更佳的顆粒,更快啟動: 50 SGs,each with 1-5 Databases? Maximum 50 Databases per server?
????????????????????????????????????????????????? 基于腳本的管理-->腳本API: 創建恢復存儲組? 重新連接刪除的郵箱? 抽取或者合并恢復存儲組郵箱
????????????????????????????????????????????????? 更佳的彈性-->日志文件ECC? 日志恢復前驗證
???????????????????????????????????????????????? 數據庫備份和恢復-->傳統流式備份? 增強VSS恢復? 從副本VSS備份?
災難恢復最佳實踐: 使用連續復制-->Exchange 2007含有異步日志傳送技術,可使用該技術在另一磁盤集上或另一臺服務器上創建和維護生產存儲組的副本。
????????????????????? 使用已刪除項目的保留時間-->通過保留已刪除的項目,可以從Microsoft Outlook客戶端還原單個項目或整個文件夾,而無需管理員干預。
???????????????????? 使用已刪除郵箱的保留時間-->通過保留已刪除的郵箱,可以使用Exchange管理控制臺還原已刪除的郵箱,而無需通過備份進行還原。
??????????????????? 主動監視服務器-->應對災難的最佳方法之一是在發生災難之前進行預防。通過監視服務器,在問題惡化之前解決問題。
?????????????????? 在多個郵箱數據庫中分布用戶-->通過將用戶分布到更多的郵箱數據庫中,可以降低單個數據庫丟失產生的影響,并且在需要還原時可以更快地還原。
本文轉自 葉俊生 51CTO博客，原文鏈接:http://blog.51cto.com/yejunsheng/161350
——1.5 小結和練習)
