資料庫可用性群組 (DAG)

  • 發行項

適用於：Exchange Server 2013

瞭解 Exchange Server 2013 中的 Exchange DAG。 本文討論資料庫可用性群組 (DAG) 生命週期，以及使用 DAG 來取得高可用性和站台回復性。

資料庫可用性群組 (DAG) 是內建在 Microsoft Exchange Server 2013 中的信箱伺服器高可用性與站台回復性架構的基礎元件。 DAG 是一組多達 16 個信箱伺服器的群組，可主控資料庫集，並提供從影響個別伺服器或資料庫的失敗中自動進行資料庫層級復原的功能。

DAG 是信箱資料庫複寫、資料庫和伺服器切換和容錯移轉的界限，以及稱為 Active Manager的內部元件。 在每個信箱伺服器上執行的 Active Manager 負責管理 DAG 內的轉換和容錯移轉。 如需 Active Manager 的相關資訊，請參閱 Active Manager。

DAG 中的任何伺服器都可以主控來自 DAG 中任何其他伺服器的信箱資料庫副本。 將伺服器新增至 DAG 後，它即可與 DAG 中其他的伺服器搭配使用，而能夠在影響信箱資料庫的失敗狀況下自動復原 (例如磁碟、伺服器或網路故障)。

資料庫可用性群組 (DAG) 生命週期

DAG 會利用 累加式部署的概念，這是在安裝 Exchange 之後，為所有信箱伺服器和資料庫部署服務和資料可用性的能力。 當您部署 Exchange 2013 信箱伺服器之後，可以建立 DAG、將信箱伺服器新增至 DAG，然後在 DAG 成員之間複寫信箱資料庫。

注意事項

如果伺服器和解決方案符合 Exchange 2013 系統需求 和 Exchange 2013 虛擬化中所設定的需求，則支援建立包含實體信箱伺服器和虛擬化信箱伺服器組合的 DAG。 與所有 Exchange 高可用性組態相同，您必須確定已適當地調整 DAG 中的所有信箱伺服器，以處理排定及未排定中斷期間的必要工作量。

DAG 是使用 New-DatabaseAvailabilityGroup Cmdlet 所建立。 DAG 一開始會在 Active Directory 中建立為空白物件。 此目錄物件可用來儲存 DAG 的相關資訊，例如伺服器成員資格資訊和一些 DAG 組態設定。 當您新增第一個伺服器到 DAG 時，就會自動為 DAG 建立容錯移轉叢集。 此容錯移轉叢集僅供 DAG 使用，而且該叢集必須供 DAG 專用。 不支援使用該叢集供所有其他目的之用。

除了要建立的容錯移轉叢集之外，也會起始監視伺服器網路或伺服器失敗的基礎結構。 然後使用容錯移轉叢集活動訊號機制和叢集資料庫來追蹤和管理可能快速變更的 DAG 資訊，例如資料庫裝載狀態、複寫狀態和最後裝載位置。

建立期間會為每個 DAG 指定一個唯一名稱，並指派一個或多個靜態 IP 位址，或設定為使用動態主機設定通訊協定 (DHCP)，或是在沒有叢集管理存取點的情況下建立。 在 Windows Server 2012 R2 Standard 或 Datacenter 版本上，只有在執行 Exchange 2013 Service Pack 1 或更新版本的伺服器上，才能建立沒有管理存取點的 DAG。 沒有叢集管理存取點的 DAG 具有下列特性：

  • 叢集/DAG 未被指派任何 IP 位址，因此，叢集核心資源群組中沒有 IP 位址資源。
  • 叢集未被指派任何網路名稱，因此，叢集核心資源群組中沒有網路名稱資源。
  • 叢集/DAG 的名稱未登錄在 DNS 中，因此無法在網路上進行解析。
  • 未在 Active Directory 中建立叢集名稱物件 (CNO)。
  • 無法使用容錯移轉叢集管理工具來管理叢集。 它必須使用 Windows PowerShell 進行管理，而且必須對個別叢集成員執行 PowerShell Cmdlet。

此範例顯示如何使用命令介面建立擁有三部伺服器且具有叢集管理存取點的 DAG。 其中兩部伺服器 (EX1 和 EX2) 位於同一個子網路 (10.0.0.0)，而第三部伺服器 (EX3) 位於另一個子網路 (192.168.0.0)。

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

建立沒有叢集管理存取點之 DAG 的命令非常類似：

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress])::None
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

將 EX1 新增至 DAG 時，會建立 DAG1 的叢集。 在叢集建立期間， Add-DatabaseAvailabilityGroupServer 指令程式會擷取為 DAG 設定的 IP 位址，並忽略在 EX1 上發現但不符合任何子網路的位址。 在上面的第一個範例中，會以 10.0.0.5 的 IP 位址來建立 DAG1 叢集，並忽略 192.168.0.5 的 IP 位址。 在上述第二個範例中， DatabaseAvailabilityGroupIPAddresses 參數的值會指示工作為沒有系統管理存取點的 DAG 建立容錯移轉叢集。 因此，會使用核心叢集資源群組中的 IP 位址或網路名稱資源來建立叢集。

接著新增 EX2，並由 Add-DatabaseAvailabilityGroupServer 指令程式再次擷取為 DAG 設定的 IP 位址。 EX2 與 EX1 位於相同的子網路上，因此叢集的 IP 位址不會有任何變更。

接著再新增 EX3，而 Add-DatabaseAvailabilityGroupServer 指令程式也會再次擷取為 DAG 設定的 IP 位址。 由於 EX3 上有符合 192.168.0.5 的子網路，因此會將 192.168.0.5 位址當成 IP 位址資源新增至叢集群組。 此外，還會針對每個 IP 位址資源自動設定網路名稱資源的 OR 相依性。 當叢集核心資源群組移至 EX3 時，叢集就會使用 192.168.0.5 的位址。

針對具有叢集管理存取點的 DAG，當網路名稱資源連線時，Windows 容錯移轉叢集會將叢集的 IP 位址註冊到網域名稱系統 (DNS)。 此外，將 EX1 新增至叢集時，會在 Active Directory 中建立叢集名稱物件 (CNO)。 叢集的網路名稱、IP 位址和 CNO 不會用於 DAG 函數。 系統管理員和使用者不需要處理或連線到叢集/DAG 名稱或 IP 位址 (不論原因為何)。 某些協力廠商應用程式會連線到叢集系統管理存取點以執行管理工作，例如備份或監視。 如果您未使用任何需要叢集系統管理存取點的協力廠商應用程式，而且您的 DAG 在 Windows Server 2012 R2 上執行 Exchange 2013 SP1 或更新版本，則建議您建立沒有系統管理存取點的 DAG。 這樣可簡化 DAG 組態、不需要一個或多個 IP 位址，以及降低 DAG 的攻擊面。

DAG 也設定為使用見證伺服器和見證目錄。 見證伺服器與見證目錄可由系統自動設定，或是由系統管理員手動設定。 在上面的範例中，是手動將 EX4 (不是 DAG 成員，未來也不會是 DAG 成員的伺服器) 設定為 DAG 的見證伺服器。

根據預設，DAG 主要是使用內建的連續複寫功能，在 DAG 中的伺服器之間複寫信箱資料庫。 如果您使用支援 Exchange 2013 中協力廠商複寫 API 的協力廠商資料複寫，則必須使用 New-DatabaseAvailabilityGroup Cmdlet 搭配 ThirdPartyReplication 參數，在協力廠商複寫模式中建立 DAG。 此模式一經啟用，就不能停用。

DAG 建立完畢後，就可以將信箱伺服器新增至 DAG。 新增第一台伺服器至 DAG 時，會形成叢集以供 DAG 使用。 DAG 會運用 Windows 容錯移轉叢集技術，例如叢集活動訊號、叢集網路與叢集資料庫 (用於儲存變更的資料，例如資料庫從主動到被動的狀態變更，或是從裝載到卸載的狀態變更，反之亦然)。 隨著其他伺服器陸續新增至 DAG，這些伺服器每一部都會加入至基礎叢集，Exchange 會自動調整叢集的仲裁模型，並新增至 Active Directory 中的 DAG 物件。

在將信箱伺服器新增到 DAG 之後，您可以設定各種 DAG 的內容，例如是否在 DAG 內的資料庫複寫作業中使用網路加密或網路壓縮。 您也可以設定 DAG 網路，並建立額外的 DAG 網路。

將成員新增至 DAG 並設定好 DAG 之後，每一台伺服器上的主動信箱資料庫，就可以複寫到其他 DAG 成員上。 建立好信箱資料庫副本之後，您可以使用各種內建的監視工具，來監視副本的健康狀況與狀態。 此外，您也可以執行資料庫與伺服器轉換。

如需建立 DAG、管理 DAG 成員資格、設定 DAG 內容、建立與監視信箱資料庫副本，以及執行轉換等相關資訊，請參閱管理高可用性和站台恢復。

資料庫可用性群組 (DAG) 仲裁模型

每個 DAG 之下都有一個 Windows 容錯移轉叢集。 容錯移轉叢集使用仲裁的概念，其使用投票人的合意以確保一次僅有一子集的叢集成員 (可指所有成員或多數成員) 在作用中。 仲裁並不是 Exchange 2013 的新概念。 舊版 Exchange 中高可用性的信箱伺服器也會使用容錯移轉叢集和它的仲裁概念。 仲裁代表成員共同的觀點與資源，而仲裁一詞也用於說明代表叢集內組態的實體資料，此為所有叢集成員之間所共有。 因此，所有 DAG 皆要求其基礎容錯移轉叢集具有仲裁。 如果叢集失去了仲裁，所有 DAG 作業會終止，所有已安裝且由 DAG 主控的資料庫將會卸載。 在此情況下，將需要系統管理員介入，以修正仲裁問題與恢復 DAG 作業。

對於確保一致性、作為避免分割的平局決勝者，以及確保叢集回應能力來說，仲裁都是非常重要的概念：

  • 確保一致性：Windows 容錯移轉叢集的主要需求是每個成員一律具有與其他成員一致的叢集檢視。 叢集登錄區是所有與叢集相關之組態資訊的最終存放庫。 如果叢集登錄區無法在 DAG 成員上從本機載入，叢集服務就不會啟動，因為無法保證該成員符合具有與其他成員一致之叢集檢視的需求。

  • 做為綁定符：仲裁見證資源會在具有偶數成員的 DAG 中使用，以避免腦部分離案例，並確保 DAG 中只有一個成員集合被視為官方。 當仲裁需要見證伺服器時，任何能夠與見證伺服器通訊的 DAG 成員都可以對見證伺服器的 witness.log 檔案加上伺服器訊息區塊 (SMB) 鎖定。 鎖定見證伺服器的 DAG 成員 (稱為 鎖定節 點) 保留額外的投票以供仲裁之用。 與鎖定節點連絡的 DAG 成員屬於多數且會維護仲裁。 無法連絡鎖定節點的任何 DAG 成員則屬於少數，因此會遺失仲裁。

  • 確保回應性：為了確保回應性，仲裁模型可確保每當叢集執行時，分散式系統有足夠的成員可運作且可溝通，而且至少可以保證叢集目前狀態的一個複本。 您不需要花費任何額外的時間讓成員開始通訊，或者判斷特定的複本是否一定存在。

具有複數成員的 DAG 會使用容錯移轉叢集的「節點與檔案共用多數」仲裁模式，而這個模式會運用外部見證伺服器作為平局決勝者。 在這種仲裁模式中，每個 DAG 成員都會獲得一票。 此外，會使用見證伺服器提供一個 DAG 成員加權過的選票 (例如，取得兩票而非一票)。 依預設，叢集仲裁資料會儲存在 DAG 每個成員的系統磁碟上，而且在這些磁碟之間保持一致。 不過，仲裁資料的副本不會儲存在見證伺服器上。 見證伺服器中的檔案會用於追蹤具有最新資料副本的成員，但見證伺服器並不會具有叢集仲裁資料的副本。 在這種模式下，多數的投票者 (DAG 成員加上見證伺服器) 必須運作正常且能夠彼此通訊，才能維護仲裁。 如果多數投票者無法彼此通訊，DAG 的基礎叢集會遺失仲裁，而且 DAG 必須讓系統管理員介入恢復運作。

具有奇數成員的 DAG 會使用容錯移轉叢集的「節點多數」仲裁模式。 在這個模式下，每個成員都會取得一票，而且每個成員的本機系統磁碟都可用來儲存叢集仲裁資料。 如果 DAG 的組態有所變更，則該變更會反映到不同的磁碟上。 只有在對半數 (向下捨去) 再加一個成員的磁碟進行變更後，才會將該項變更視為已認可且成為持續性。 例如，在有五個成員的 DAG 中，必須在二加一個成員 (也就是總共三個成員) 上進行變更。

仲裁要求多數投票者必須能夠彼此通訊。 假設某個 DAG 擁有四個成員。 因為這個 DAG 具有偶數的成員，所以它會使用外部見證伺服器來提供一名叢集成員第五票，也就是平局決勝的一票。 為了維持多數投票者 (並因而達成仲裁)，至少要有三個投票者必須能夠彼此通訊。 不論任何時候，最多可以有兩個投票者離線，而不致於造成服務和資料存取中斷。 如果有三個或更多投票者離線，DAG 便會遺失仲裁，而且直到您解決問題之前，服務和資料的存取都會中斷。

使用資料庫可用性群組 (DAG) 來取得高可用性

為方便說明 DAG 如何為您的信箱資料庫提供高可用性，我們假設下例範例使用含五台成員的 DAG。 DAG 如下圖所示。

資料庫可用性群組 (DAG) 。

在上圖中，綠色資料庫是主動信箱資料庫副本，而藍色資料庫則是被動信箱資料庫副本。 在本範例中，資料庫副本不會鏡射到每一台伺服器上，而是平均分佈到多台伺服器上。 此舉可確保 DAG 中沒有兩台伺服器擁有相同的資料庫副本集合，因此可以提供給 DAG 更大的失敗恢復，包括當其他元件因為正常維護作業而無法使用的失敗情況。

假設下列案例中使用以上範例 DAG，來說明多台資料庫與伺服器失敗的回復性。

一開始，所有資料庫和伺服器都很健全。 您需要在 EX2 上安裝某些作業系統更新，因此讓伺服器進入維護模式。 這樣會使伺服器進行轉換作業，進而啟動另一部信箱伺服器上的 DB4 副本。 伺服器轉換會將所有的主動信箱資料庫副本從目前的伺服器移到 DAG 中一或多部其他信箱伺服器，以因應目前伺服器的排定中斷狀況。 在本範例中，EX2 (DB4) 上只有一台主動信箱伺服器，因此只能移動一個主動信箱資料庫副本。

資料庫可用性群組 (伺服器離線) DAG。

當您在 EX2 上執行維護作業時，EX3 會因災難性的硬體失敗而離線。 要離線之前，EX3 會裝載 DB2 的主動副本。 為了從失敗中復原，系統會自動於 30 秒內啟動裝載在 EX1 上的 DB2 副本。 如下圖所示。

具有伺服器離線和失敗伺服器的 DAG。

為 EX2 排定的維護完成後，讓系統上線並結束維護模式。 一旦 EX2 可用，其他 DAG 成員伺服器會收到通知，並自動將裝載在 EX2 上的 DB1、DB4 與 DB5 副本，與每一個資料庫上的主動副本同步處理。 如下圖所示。

具有還原伺服器的 DAG 會重新同步處理資料庫。

當您以新的元件來更換 EX3 中失敗的硬體元件之後，就可以讓 EX3 上線。 在 EX3 可以使用之後，其他 DAG 成員伺服器會收到通知，並自動讓 EX3 上主控的 DB2、DB3 和 DB4 副本，與每一個資料庫上的主動副本保持同步。 如下圖所示。

具有成員重新同步處理資料庫複本的 DAG。

使用資料庫可用性群組 (DAG) 來取得站台回復性

除了在資料中心裡提供高可用性之外，DAG 還可以延伸至一或多個資料中心，並透過組態為一或多個資料中心提供站台回復性。 在先前的範例圖表中，DAG 位於單一資料中心與單一 Active Directory 站台。 您可以使用增量部署將此 DAG 延伸至次要資料中心 (以及次要 Active Directory 站台)，方法是部署信箱伺服器與必要的支援資源 (亦即，一部或多部 Active Directory 伺服器，以及 DNS 服務)。 之後將信箱伺服器新增至 DAG，如下圖所示。

DAG 延伸至兩個 Active Directory 月臺。

在本範例中，Redmond 資料中心裡的每一個主動資料庫，會在 Dublin 資料中心裡的 EX6 上設定一個被動副本。 不過，還有其他許多 DAG 組態範例可提供站台回復性。 例如：

  • EX6 可以主控所有主動副本，或是混合主控主動與被動副本，而不是只主控被動資料庫副本。

  • 除了 EX6 之外，還可以將多個 DAG 成員部署在 Dublin 資料中心裡，以提供避免其他錯誤的保護。 這個組態也提供額外的容量，因此如果 Redmond 資料中心發生錯誤，Dublin 資料中心便可支援更大量的使用者人數。

使用多個資料庫可用性群組 (DAG) 來取得站台回復性

在上面的範例中，單一 DAG 遍佈多個資料中心，以便為其中一個或兩個資料中心提供站台回復性。 在您將 DAG 延伸至其上的每個資料中心都有使用中使用者人數的環境中，使用單一 DAG 提供站台回復性時，廣域網路 (WAN) 連線中會有單一失敗點。 這是因為仲裁要求多數投票者必須正在作用，而且能夠彼此通訊。

在前面的範例中，多數投票者是位於 Redmond 資料中心裡。 如果 Dublin 資料中心主控了主動信箱資料庫，而且具有本機使用者人數，WAN 中斷將會造成 Dublin 使用者的訊息服務中斷。 當 WAN 連線中斷時，只有 Redmond 資料中心的 DAG 成員會保留仲裁並繼續提供訊息服務。

在您需要提供站台回復性給多個資料中心，而每個資料中心都有使用中的使用者人數時，若要避免 WAN 變成單一失敗點，您應該部署多個 DAG，讓每個 DAG 在個別的資料中心裡都有多數投票者。 當發生 WAN 中斷狀況時，將會封鎖複寫功能，直到還原連線為止。 使用者將會有訊息服務，因為每個 DAG 都會繼續為其本機使用者人數提供服務。