-
DAG
(新組件)
鎖定
DAG(Database Availability Group)即數據庫可用性組,是內置在 Microsoft Exchange Server 中的郵箱服務器高可用性和站點恢復框架的基本組件。 DAG 是一組郵箱服務器(最多可包含 16 個郵箱服務器),其中承載了一組數據庫,可提供從影響單個服務器或數據庫的故障中自動執行數據庫級恢復的功能。
可用性組在Exchange 2010中的數據庫,LCR、SCC、CCR以及SCR等概念不復存在。LCR和SCC功能已經從Exchange Server產品中刪除。
- 中文名
- 數據庫可用性組
- 外文名
- Database Availability Group
- 簡 稱
- DAG
目錄
DAG基本簡介
DAG 是郵箱數據庫複製、數據庫和服務器切換和故障轉移以及名為“活動管理器”的內部組件的邊界。運行於每個郵箱服務器上的活動管理器,在 DAG 中管理切換和故障轉移。
[1]
DAG 中的任何服務器可以承載來自 DAG 中任何其他服務器的郵箱數據庫副本。將服務器添加到 DAG 後,此服務器與 DAG 中的其他服務器協同工作,提供從影響郵箱數據庫的故障(如磁盤、服務器或網絡故障)中自動執行恢復的功能。
CCR與SCR合併,並已發展成為一個更加統一的高可用性架構,這其中,DAG成為基本的組成部分。也就是説,不論是部署本地級還是站點級的高可用性和災難可恢復解決方案,都要用到DAG。
在Exchange 2010中,保護郵箱數據庫的唯一方法也是使用DAG。DAG的主要組成部分是一種稱為主動管理器(Active Manager)的新組件。Exchange 2007及早期版本中的Exchange羣集資源DLL(exres.dll)和相關的羣集服務資源,如今已被取代。現在,Exchange 2010使用主動管理器來管理DAG中郵箱服務器間的數據交換和故障切換。主動管理器運行在給定的DAG中的所有郵箱服務器上,它有兩個角色:主要主動管理器(Primary Active Manager,PAM)和備用主動管理器(Standby Active Manager,SAM)。
[1]
DAG仲裁模式
每個 DAG 下均有一個 Windows 故障轉移羣集。故障轉移集羣使用仲裁概念,即利用投票者的共識來確保一次只有一部分羣集成員(這可以指所有成員或大部分成員)在運行。仲裁併不是 Exchange Server的新概念。Exchange 早期版本中的高可用性郵箱服務器同樣使用故障轉移羣集及其仲裁概念。仲裁代表一個成員和資源的共享視圖,仲裁一詞也用於描述代表在所有羣集成員間共享的羣集中的配置的物理數據。因此,所有 DAG 都要求其基礎故障轉移羣集具有仲裁。如果羣集丟失仲裁,則所有 DAG 操作都將終止,DAG 中託管的所有裝入數據庫都將卸除。在這種情況下,需要管理員干預以更正仲裁問題並恢復 DAG 操作。
仲裁對於確保一致性,充當用於避免分區的關係斷開裁判,以及確保羣集響應能力而言非常重要:
- 確保一致性:Windows 故障轉移羣集的主要要求是,每個成員始終具有與其他成員一致的羣集視圖。羣集配置單元充當了與羣集相關的所有配置信息的權威性存儲庫。如果 DAG 成員無法本地加載羣集配置單元,則羣集服務將不會啓動,因為無法保證成員始終與該羣集中其他成員保持一致這一要求。
- 確保響應能力:為了確保響應能力,仲裁模型確保在羣集運行時,分佈式系統的足夠多的成員處於運行狀態且 communicative,並且至少有一個羣集的當前狀態副本可以保證。無需額外時間來為成員建立通信,或確定特定副本是否得到保證。
具有偶數個成員的 DAG 使用故障轉移羣集的節點和文件共享多數仲裁模式,該模式採用外部見證服務器充當關係斷開裁判。在此仲裁模式中,每個 DAG 成員都將獲得一票。此外,還將使用見證服務器向某個 DAG 成員提供一份權重投票(例如,獲得兩投票而不是一份)。默認情況下,羣集仲裁數據存儲在每個 DAG 成員的系統磁盤中,並且在這些磁盤間保持一致。但是,仲裁數據的副本並不存儲在見證服務器上。見證服務器上的一個文件用於記錄哪個成員擁有最新的數據副本,但見證服務器沒有羣集仲裁數據的副本。在此模式中,大多數的投票者(DAG 成員加上見證服務器)必須工作正常並且能夠相互通信以保留仲裁權。如果大多數投票者不能相互通信,則 DAG 基礎羣集將失去仲裁權,並且 DAG 需要管理員干預才能恢復正常工作。
具有奇數個成員的 DAG 使用故障轉移羣集的節點多數仲裁模式。在此模式中,每個成員將獲得一票,且每個成員的本地系統磁盤用於存儲羣集仲裁數據。如果 DAG 配置發生更改,此更改將反映在不同磁盤上。僅當更改發生在一半(向下舍入)加一數目的成員的磁盤上,該更改才會被視為已提交併永久保存。例如,在五個成員的 DAG 中,更改必須發生在二加一個成員上,即共三個成員上。
仲裁要求大多數投票者能夠相互通信。請考慮具有四個成員的 DAG。因為此 DAG 具有偶數個成員,所以使用外部見證服務器向其中一個羣集成員提供第五個決定性投票。為了保留大多數投票者(進而保留仲裁權),至少必須有三個投票者能夠相互通信。任何時候,在不中斷服務以及數據訪問的前提下,最多有兩個投票者可以處於脱機狀態。如果有三個或更多個投票者脱機,DAG 將失去仲裁權,且服務和數據訪問將中斷,直至問題解決。
DAG特點
對Windows故障轉移羣集的有限依賴:
DAG僅使用了Windows故障轉移羣集組件提供的有限的一部分羣集功能。DAG使用羣集數據庫、羣集心跳(Cluster heartbeat)及文件共享見證(File Share Witness,FSW)功能。在Exchange 2007及早期版本中,Exchange是一個由Windows故障轉移羣集操作的應用程序。而在Exchange 2010中,情況發生了變化,Windows故障轉移羣集註冊時所創建的Exchange羣集資源DLL及所有羣集資源,已從Exchange 2010代碼中移除。
增量部署:
DAG仍使用Windows故障轉移羣集組件(如羣集數據庫、心跳和文件共享見證功能),因此需要Windows Server 2008 SP2版或R2企業版環境,以便能夠對DAG中的Exchange 2010郵箱服務器進行配置。但Exchange 2010支持增量部署方式,也就是説不需要在安裝Exchange 2010之前形成羣集。用户可以安裝Exchange 2010郵箱服務器,然後創建一個DAG並在必要時將數據庫和服務器添加到其中。
與其他Exchange角色共存:
使用CCR時,用户不能在郵箱服務器(羣集節點)上安裝受CCR保護的Exchange服務器。使用DAG時,DAG中的郵箱服務器還可以安裝其他Exchange角色。這個特點對於小型組織非常有利。這是因為受DAG保護的郵箱服務器可以與其他Exchange角色並存。這也意味着用户可以使用兩台機器作為專用Exchange服務器,以提供一個完全的冗餘解決方案。當然,這需要配置文件共享見證,這一點在用户環境中很容易實現。文件共享見證不需要運行相同版本的Windows,只要運行Windows Server 2003或更高版本即可。另外一點需要注意的是:如果用户使用兩台Exchange 2010服務器,並且希望得到一個完全的冗餘解決方案,則必須使用基於負載均衡解決方案的外部硬件或軟件,以便提供客户端訪問服務。
完全通過Exchange工具管理:
在Exchange 2007中使用CCR時,必須使用Exchange和羣集管理組合工具來配置和管理CCR羣集。在Exchange 2010中使用DAG時,不必使用羣集管理工具進行任何初始配置和管理,企業內部的Exchange管理員也不再需要有羣集管理的經驗。
數據庫級的複製:
為了支持DAG的新功能,Exchange 2010數據庫已遷移到組織級,而不是Exchange 2007或早期版本的服務器級。Exchange 2010中不存在存儲組的概念。現在,每個數據庫都有一個日誌流與數據庫相關聯。CCR的一個缺點是:如果主動節點的一個數據庫出現故障,羣集郵箱服務器上現有的所有活動數據庫的故障都將轉移到被動CCR節點。如果這個節點上的用户有郵箱存儲於各自的羣集郵箱服務器(Cluster Mailbox Server,CMS),他們都將受到影響。
每個DAG支持多達16個成員:
同Exchange 2007相比,Exchange 2010可以支持更多的郵箱數據庫,用户最多可以添加16個郵箱服務器到一個DAG,並可能保存16個郵箱數據庫副本。因此,Exchange 2010企業版支持的郵箱數據庫最高限額已從50個上調至100個。但標準版目前仍然只支持每個郵箱服務器最多5個數據庫。
切換/故障轉移較以前更為快速:
有賴於Exchange 2010 DAG的改進,現在,郵箱數據庫副本間的切換/故障轉移更為快速。同Exchange 2007下采用CCR動輒就需要數分鐘相比,目前所用時間往往在30稱之內。此外,由於Outlook MAPI客户端連接客户端訪問服務器的RPC客户端訪問服務,因此最終用户很少會注意到切換或故障轉移的發生。
3個以上數據庫副本時無需備份:
當一個郵箱數據庫擁有3個或更多副本時,程序設計為無需用户備份。也就是説當依次循環登錄受DAG保護的郵箱數據庫時,不再需要執行備份操作。
支持位於不同活動目錄站點的DAG成員:
與CCR羣集節點不同,DAG成員服務器可以位於不同的活動目錄站點。但是應當注意,不能把受同一個DAG保護的郵箱服務器放置在活動目錄森林的不同域內。
通過TCP傳送日誌:
在Exchange2007中,Microsoft Exchange複製服務通過服務器消息塊將日誌文件複製到被動數據庫副本(LCR)、被動羣集節點(CCR)或SCR目標,這就意味着用户需要打開CCR羣集節點(通常是在部署多站點CCR羣集時)與SCR源或SCR目標之間防火牆的445端口。利用Exchange 2010 DAG,異步複製技術不再依賴服務器管理塊。Exchange 2010使用TCP / IP協議進行日誌文件複製和播種(注:播種,即Seed。在 CCR 環境中安裝被動節點時,每個存儲組及其數據庫都將從主動節點複製到被動節點,該操作稱為播種),甚至可以指定端口用於日誌文件複製。默認情況下,DAG使用64327端口,當然,也可另外指定其他端口。
日誌文件壓縮:
利用Exchange 2010 DAG,在一個DAG內的一個或多個網絡間播種或複製時可以啓用壓縮功能。這是DAG本身的特性,而不是DAG網絡的特性。默認設置為InterSubnetOnly,進行網絡加密屬性設置時也使用相同的值。
日誌文件加密:
Exchange 2010 DAG增加了對加密的支持,而在Exchange 2007中,除非已配置IPsec,否則日誌文件將通過一個非加密通道複製。具體地説, DAG使用Windows Server 2008的加密功能,也就是説,DAG使用每個郵箱服務器成員之間的Kerberos身份驗證。網絡加密是對DAG本身而言的,而不是針對DAG網絡。DAG網絡加密屬性選項有:禁用(不使用網絡加密),啓用(網絡加密用於DAG中所有網絡的播種和複製),InterSubnetOnly(默認設置,網絡加密用於同一子網內的DAG網絡),以及SeedOnly(網絡加密用於DAG中所有網絡的播種)。
副本最多允許滯後14天:
Exchange 2007 SP1的備用連續複製引入了滯後數據庫副本的概念。有了這項功能,用户可以指定在重播已複製到 SCR 目標計算機的日誌文件之前,Microsoft Exchange 複製服務應等待的時間。用户還可以使用另一個參數截斷滯後時間 (Truncation Lag Time),用於指定在截斷已複製到 SCR 目標計算機並已重播到數據庫副本的日誌文件之前,Microsoft Exchange 複製服務應等待的時間。利用這兩個選項,我們可以指定一個長達7天的時間差距。而通過Exchange 2010 DAG,用户可以指定最多14天的截斷滯後時間。
從數據庫副本播種:
與Exchange 2007中的CCR不同,現在,用户可以通過指定一個數據庫副本作為源數據庫來執行播種。這就意味着,現有郵箱數據庫的播種或重播操作不再對活動數據庫副本產生影響。
公用文件夾數據庫不受DAG保護:
與Exchange 2007的CCR不同,用户不能使用DAG保護公用文件夾數據庫,而必須使用傳統的公共文件夾的複製機制對其加以保護。但在這方面也做了一些改進:如果公用文件夾存儲於DAG成員服務器上,Exchange 組織中只有一個公用文件夾存儲的限制被取消。
改進的傳輸轉儲程序:
傳輸轉儲程序也有所改進,甚至受損數據庫在位於不同活動目錄站點的數據庫副本間進行故障轉移時,信息都可以重新遞送。除此之外,當所有信息都被複制到數據庫副本時,它們將從傳輸轉儲程序中被刪除。
DAG配置
1、 創建數據庫可用性組;
2、 添加數據庫可用性組成員;
3、 新建郵箱數據庫
4、 添加郵箱數據庫副本
DAG創建 DAG
DAG 創建方法是在Exchange 管理中心 (EAC) 中使用"新建數據庫可用性組"嚮導,或在 Exchange 命令行管理程序中運行New-DatabaseAvailabilityGroupcmdlet。
[2]
創建 DAG 時,請提供 DAG 名稱、可選見證服務器和見證目錄設置。此外,還可以為 DAG 分配一個或多個 IP 地址,方法為使用靜態IP地址,或使用動態主機配置協議 (DHCP) 為 DAG 自動分配必要的 IP 地址。 可以使用_DatabaseAvailabilityGroupIpAddresses_參數將 IP 地址手動分配給 DAG。如果省略此參數,DAG 會嘗試使用網絡中的 DHCP服務器來獲取 IP 地址。
如果要創建將包含運行 Windows Server 2012 R2 的郵箱服務器的 DAG,則還可以選擇不使用羣集管理訪問點來創建 DAG。在這種情況下,羣集在 Active Directory 中將不會有羣集名稱對象 (CNO),羣集核心資源組也不會包含網絡名稱資源或 IP 地址資源。
創建 DAG 時,將在 Active Directory中創建一個空對象,以代表具有指定名稱且對象類為msExchMDBAvailabilityGroup的 DAG。
Dag 使用 Windows Server 2008 R2 或更高版本中的 Windows 故障轉移羣集技術的子集,如羣集檢測信號、羣集網絡和羣集數據庫(用於存儲更改或可以快速更改的數據,例如數據庫狀態從活動更改為被動或反向,或從已安裝到已卸除或反向。因此,只能在包含 Windows 故障轉移羣集的受支持的 Windows 版本上安裝的 Exchange 郵箱服務器上創建 Dag。
DAG見證服務器和見證目錄
創建 DAG 時,需要為 DAG 指定一個不超過 15 個字符且在Active Directory 林中唯一的名稱。此外,每個 DAG 都會配置有見證服務器和見證目錄。僅當 DAG 中成員數為偶數時,才使用見證服務器及其目錄,且只能用於仲裁目的。無需提前創建見證目錄。Exchange 會在見證服務器上自動創建並保護見證目錄。見證目錄不得用於除 DAG 見證服務器之外的其他任何目的。
[2]
見證服務器的要求如下:
- 見證服務器不能是 DAG 的成員。
- 見證服務器必須與 DAG 位於同一個 Active Directory 林中。
- 見證服務器必須運行 Windows Server 2008 或更高版本。
- 單個服務器可以充當多個 DAG 的見證。但是,每個 DAG 都需要其自己的見證目錄。
無論將哪個服務器用作見證服務器,如果在預期的見證服務器上啓用了 Windows 防火牆,必須為文件和打印機共享啓用 Windows 防火牆例外。見證服務器使用 SMB 端口 445。
DAG見證服務器放置注意事項
DAG 的見證服務器放置將取決於業務需求和組織的可用選項。Exchange 現在包含對在 Exchange 2010 中不建議或無法使用的新 DAG 配置選項的支持。這些選項包括使用第三個位置,如第三個數據中心、分支機構或 Microsoft Azure虛擬網絡。
下表列出了不同部署方案中見證服務器放置的常規建議。
部署方案 | 推薦 |
---|---|
在單個數據中心部署單個 DAG | 查找相同數據中心中的見證服務器作為 DAG 成員 |
在兩個數據中心部署單個 DAG;沒有其他可用位置 | 在 Microsoft Azure 虛擬網絡上查找見證服務器來啓用自動數據中心故障轉移,或 在主數據中心查找見證服務器 |
在單個數據中心部署多個 DAG | 查找相同數據中心中的見證服務器作為 DAG 成員。其他選項包括: ·對多個 Dag 使用相同的見證服務器 ·使用 DAG 成員充當不同 DAG 的見證服務器 |
在兩個數據中心中部署多個 DAG | 在 Microsoft Azure 虛擬網絡上查找見證服務器來啓用自動數據中心故障轉移,或 在數據中心查找視為每個 DAG 的主服務器的見證服務器。其他選項包括: ·對多個 Dag 使用相同的見證服務器 ·使用 DAG 成員充當不同 DAG 的見證服務器 |
在兩個以上數據中心部署單個或多個 DAG | 在此配置中,見證服務器應位於您希望大多數仲裁投票位於其中的數據中心。 |
在兩個數據中心內部署 DAG 後,現在可以使用第三個位置來承載見證服務器。如果組織具有帶有網絡基礎結構的第三個位置,且該網絡基礎結構與影響部署了 DAG 的兩個數據中心的網絡故障分離開來,則可以在此第三個位置部署 DAG 的見證服務器,從而將 DAG 配置為可以自動將數據庫故障轉移到其他數據中心,以響應數據中心級別的故障事件。如果您的組織只有兩個物理位置,則可以使用 Microsoft Azure 虛擬網絡作為放置見證服務器的第三個位置。
DAG測試
在完成上面的配置後就可以使用OWA對配置的數據庫可用性組進行測試。測試的方法:
1、 將郵箱服務器MAIL或MAIL2關機,例如將郵箱服務器MAIL關機
2、 使用在MAIL郵箱服務器中創建數據庫的用户。
3、 用户登錄,查看是否可以訪問自己的數據。
DAG管理説明
數據庫可用性組 (DAG) 是一組(最多 16 台)Microsoft Exchange Server 2010 郵箱服務器,提供從數據庫、服務器或網絡故障中自動執行數據庫級恢復的功能。DAG 使用連續複製和 Windows 故障轉移羣集技術的子集以提供高可用性和站點恢復。DAG 中的郵箱服務器相互進行故障監視。郵箱服務器添加到 DAG 後,它會與 DAG 中的其他服務器協同工作,提供從數據庫故障中自動執行數據庫級恢復的功能。
[3]
DAG操作
創建 DAG 時,DAG 最初是空的,並且會在 Active Directory 中創建一個目錄對象以代表 DAG。目錄對象用於存儲 DAG 的相關信息,比如服務器成員身份信息。將第一個服務器添加到 DAG 時,將為 DAG 自動創建故障轉移羣集。此外,還將啓動監視服務器的網絡或故障的基礎結構。然後,使用故障轉移羣集檢測信號機制和羣集數據庫來跟蹤和管理有關 DAG 可能快速更改的信息,比如數據庫裝入狀態、複製狀態和最後裝入位置。
- 參考資料
-
- 1. 數據庫可用性組 .Microsoft官網[引用日期2019-10-06]
- 2. 管理數據庫可用性組 .Microsoft官網[引用日期2019-10-06]
- 3. 配置數據庫可用性組屬性 .Microsoft 官網[引用日期2019-10-06]