主要主機與叢集管理 (AppFabric 1.1 快取)

Microsoft AppFabric 1.1 for Windows Server 快取叢集是一個動態伺服器群組，群組中的伺服器共同運作，為您的應用程式資料提供單一邏輯快取。 若要達到此一目的，就無法避免在協調快取主機之間的叢集作業時產生一些額外負荷。 叢集管理角色負責管理快取主機，最終管理快取叢集。

有兩個主要選項可執行快取叢集管理角色。 第一個選項是由特定的快取主機來執行此角色，稱為主要主機。 這也稱為「載入」。 第二個選項是由 SQL Server 主機來執行此角色。 這也稱為「卸載」，因為責任已卸載至 SQL Server，而非快取叢集本身。

若您將快取叢集設定資料儲存在共用的網路資料夾 (XML) 中，您必須針對主要主機管理使用載入。 請注意主要主機執行的快取任務與未指定為主要主機的其他快取主機相同，但是前者還要負責與其他主要主機一起執行叢集管理角色。

在 Windows Server AppFabric 1.0 中，在 SQL Server 中儲存其設定資料的快取叢集預設，是用來將快取叢集管理角色卸載至 SQL Server。 這已在 AppFabric 1.1 中變更。 新快取叢集的預設是永遠使用載入主要主機來管理快取叢集。 這樣會改善快取叢集的可用性，因為無論該儲存區為 XML 檔案或 SQL Server，設定儲存區都無法使用的情況下，快取叢集可保持部分功能。 請注意，檢查或變更快取叢集的設定在此期間無法使用。

注意

若您升級現有的 AppFabric 1.0 快取叢集為 AppFabric 1.1，則升級不會變更快取叢集管理行為。 若升級的快取叢集使用卸載且您希望加以變更，您會需要使用 Windows PowerShell 命令來重新建立快取叢集。 如需相關資訊和範例，請參閱 自動化安裝套件 (AppFabric 1.1 快取)。 若要更方便地重新建立叢集，您可以使用 Export-CacheClusterConfig 與 Import-CacheClusterConfig 命令。 不過，您必須確定 leadHostManagement 屬性設為 "true"。 如需詳細資訊，請參閱主要主機與叢集管理 (AppFabric 1.1 快取)。

您還是可以卸載所有的快取叢集管理責任給 SQL Server。 首先，您必須以 New-CacheCluster 命令手動建立快取叢集，並設定 Offloading 參數為 "true"。 其他需求為 Provider 必須是 SQL Server (System.Data.SqlClient)。

下表顯示您安裝時的選擇與叢集管理選項的相關性。 如需選擇適合之組態選項的詳細資訊，請參閱叢集組態儲存選項。

叢集組態儲存類型	叢集組態儲存位置	叢集管理
XML 檔案	共用的網路資料夾	主要主機
SQL Server 資料庫	SQL Server	SQL Server 或主要主機 (預設值)
自訂提供者	自訂儲存區	主要主機

叢集管理角色任務

有兩個主要的組態設定可決定叢集在涉及叢集管理時的功能：

• leadHostManagement：這個叢集等級設定決定誰要執行叢集管理角色。 如果為 True，會由主要主機執行叢集管理角色。 如果您選擇將叢集組態設定儲存在共用的網路資料夾中，此設定的唯一有效值是 True。 False 表示將由 SQL Server 或自訂提供者執行叢集管理角色。 使用 SQL Server 或自訂提供者來儲存叢集組態設定時，可將此設定設為 True，讓主要主機執行叢集管理角色。

• leadHost：當由主要主機執行叢集管理角色時，這個快取主機等級設定決定哪些快取主機將成為主要主機。 即使將由 SQL Server 執行叢集管理角色，安裝程式也會指定主要主機，以防您稍後變更 leadHostManagement 設定。

如需變更這些設定的詳細資訊，請參閱設定叢集管理角色與主要主機指定 (AppFabric 1.1)。

當主要主機執行叢集管理角色時

如果 leadHostManagement 與 leadHost 設定為 true，系統會提升快取主機等級以增加它在叢集內的職責，並將它指定為主要主機。 除了與快取資料相關的一般快取主機操作之外，主要主機也會與其他主要主機共同管理叢集操作。

當主要主機失敗時

為了讓快取叢集維持可用，大部分的主要主機都必須維持可用。 與大型叢集相比，這樣做對於小型叢集來說風險較高，原因是小型叢集能夠承受的伺服器失敗 (會造成叢集自行關閉) 數較少。

注意

當主要主機執行叢集管理角色時，如果絕大多數的主要主機失敗，整個快取叢集就會關閉。

例如，考慮下圖顯示的快取叢集 (由六部伺服器所組成)。 在此範例中，主要主機會執行叢集管理角色，且有兩部快取主機被指定為主要主機。

如果叢集內的任一部一般快取主機失敗，叢集仍可持續執行。 非主要主機上的資料會遺失 (假設未啟用高可用性)，但是叢集的其餘部分仍可繼續提供服務及儲存資料。 事實上，如果叢集遺失所有未指定為主要主機的四部快取主機，該叢集仍可持續運作。

只要其中一部主要主機失敗，整個快取叢集就會自行關閉，原因是仍在執行的主要主機已不再佔大多數。 為了避免發生此問題，您可以指定額外的主要主機。

指定額外的主要主機

您可以在安裝後指定其他主要主機。 但是，請務必考慮到，指定太多主要主機也會產生問題：

• 大部分的主要主機一定要處於可用狀態，快取叢集才能持續執行。 將越多主機指定為主要主機，叢集維持運作狀態時能夠承受的伺服器失敗數就越少。

• 在小型叢集內，只要一兩部主要主機失敗，就會造成叢集失敗，所以建議您指定較多的主要主機。

• 在大型叢集內，只要五到七部主要主機，就應該足以確保含有 50 台快取伺服器的叢集維持可回應狀態。

如需有關變更主要主機指定的詳細資訊，請參閱設定叢集管理角色與主要主機指定 (AppFabric 1.1)。

Microsoft AppFabric 1.1 for Windows Server 中的變更

若要增加快取叢集的可用性，AppFabric 1.1 已變更用來指定預設主要主機的處理程序。AppFabric 1.1 會自動設定新增至快取叢集當做主要主機 (上限為 7 部主要主機) 的每個快取主機。 您仍然可以使用 Set-CacheHostConfig 命令，並將 IsLeadHost 參數設為 "true"，來指定其他主要主機。 您也可以將 IsLeadHost 設為 "false"，從主要主機移除快取主機。

當 SQL Server 執行叢集管理角色時

當用已啟用的卸載建立快取叢集時，leadHostManagement 設定為 false。 在這種情況下，無論 leadHost 的設定為何，每部快取主機都只會執行其本身與快取資料相關的一般非主要主機職責。 用於儲存叢集組態設定的 SQL Server 執行個體也會用來執行叢集管理角色。

發生伺服器失敗時

在由 SQL Server 執行叢集管理角色 (卸載) 時，為了讓叢集維持可用，必須有一或多部快取主機能夠存取 SQL Server 資料庫。

例如，考慮下圖顯示的快取叢集 (由六部伺服器所組成)。

在此範例中，SQL Server 正在執行叢集管理角色，而所有六部快取主機都可以將其資源用於提供資料供快取用戶端存取。

如果叢集內的任一部快取主機失敗，則伺服器上的資料會遺失 (假設未啟用高可用性)，但是叢集仍可持續執行。 快取用戶端仍可使用其他快取主機上的資料。 事實上，在此案例中，叢集中的六部快取主機有五部失敗時，叢集仍可持續運作。

如果 SQL Server 失敗，整個叢集會在幾分鐘內關閉。 為了避免發生此問題，我們強烈建議您使用 Microsoft Windows Server 2008 容錯移轉叢集 (https://go.microsoft.com/fwlink/?LinkId=130692) (可能為英文網頁) 來主控「叢集化」資料庫資源做為快取叢集組態儲存位置與叢集管理角色。

另請參閱

概念

AppFabric 快取功能實體架構圖 (AppFabric 1.1 快取)
AppFabric 快取功能邏輯架構圖 (AppFabric 1.1 快取)

  2012-03-05