共用方式為

高可用性 (AppFabric 1.1 快取)

  • 發行項

啟用高可用性之後，系統會在其他快取主機上維護每個已快取物件或區域的複本。快取叢集會管理這些複本的維護作業，並在主要複本無法使用時提供這些複本給您的應用程式。您不需要修改可進行快取的應用程式的任何程式碼，就可以使用此高可用性功能。下圖顯示啟用高可用性功能之後，系統如何將物件與區域的複本儲存在其他主機上。

"Velocity" 高可用性概觀

高可用性組態

高可用性是在叢集組態設定的快取等級設定。因為它是快取屬性，您可以在首次建立快取時使用 New-Cache 命令並將 Secondaries 參數設定為 1 以啟用此功能。這樣可通知快取管理 Windows PowerShell Cmdlet 您想要為每個已快取的物件或區域建立複本。若將 Secondaries 參數設定為 0，表示要停用高可用性功能。根據預設值，當您建立新的快取時會停用高可用性選項。如需有關編輯快取組態設定的詳細資訊，請參閱使用 Windows PowerShell 來編輯快取組態設定。

Microsoft AppFabric 1.1 for Windows Server 快取 能的高可用性功能要求快取叢集中的所有節點都必須執行 Windows Server 2008 或 Windows Server 2008 R2 Enterprise Edition 或更高的版本。請確認所有高可用性快取節點都是在支援的作業系統上執行。如需有關支援之作業系統的詳細資訊，請參閱 AppFabric 安裝指南 (https://go.microsoft.com/fwlink/?LinkId=169172) 中的＜軟體需求＞一節。

次要複本儲存區

快取叢集會選擇要用來儲存物件與區域之次要複本的位置。就像 AppFabric 會將已快取的物件分散到叢集中的所有快取主機上，它也會將那些物件的次要複本分散到叢集中的所有快取主機上。

如何維持一致性

不論是否已啟用高可用性，可進行快取的應用程式都會認為已快取物件只有主要複本存在。Add、Put 與 Remove 方法呼叫都會先在主要物件所在的快取主機上初始化。在初始化呼叫來快取維護主要物件或區域的主機後，會根據是否啟用高可性而產生不同的動作。

若已啟用高可用性，則系統必須採取額外的步驟通知維護次要複本的主機即將發生變更。接著，物件之主要複本所在的快取主機會等候來自其他主機的通知，再向用戶端回覆操作已完成。

如需範例，請參閱下圖中的快取主機 A 與快取主機 B。當快取主機 A 收到要求時，它會開始處理要求，並通知快取主機 B 已發生變更。接著，快取主機 B 會將通知傳送回快取主機 A。當快取主機 A 收到通知時，它會完成變更，並將通知傳回給可進行快取的應用程式。此程序可確保物件或區域之次要複本的狀態總是與主要複本相同。此程序稱為稱為「強式一致性」。

"Velocity" 高可用性一致性

效能考量

因為維護物件或區域之次要複本的快取主機必須偵測主要複本是否有變更，可進行快取的應用程式的寫入操作效能會稍微變差。請注意，此效能衝擊不會影響讀取已快取之項目的效能。您也必須考量當維護物件之主要複本的快取主機無法使用時，重新將物件放入快取所需的時間。

當快取主機失敗時會發生什麼事

若快取主機失敗 (假設仍有足夠的快取主機可讓叢集繼續執行)，可進行快取的應用程式並不會察覺到任何變更。快取叢集會將對於物件的要求重新路由到維護該物件之次要複本的快取主機。在該叢集中，所有主要物件的次要複本接著都會被提升為新的主要物件。接著，那些新主要物件的次要複本會被分散到叢集中的其他快取主機。失敗之快取主機上的次要物件會被新的次要物件取代，並分散到叢集中的快取主機。此程序也適用於「區域」。

若要使用高可用性功能協助確保快取主機失敗時應用程式不受影響，請至少新增三部快取主機做為快取叢集的成員。這是因為強式一致性需求要求在支援高可用性的快取環境中，至少必須有兩份已快取物件或區域的複本。為維護兩份快取或區域的複本，支援高可用性的快取需要至少兩部快取主機才能運作。

例如，假設您已經在具有三部伺服器的快取叢集中建立名為 HACache 的高可用性快取，如下表所示。假設已設定為使用 SQL Server 來執行快取管理角色 (因此此範例不需要考慮主要主機可能失敗的問題)。

時間 快取主機 1 快取主機 2 快取主機 3 HACache (已啟用高可用性的具名快取)

T1

執行中

執行中

執行中

可供使用

T2

執行中

執行中

已停止

可供使用

T3

執行中

已停止

已停止

無法使用

在 T1，當有三部快取主機可用時，兩份已快取之物件或區域的複本可儲存在三部可用伺服器的其中一部。在 T2，有一部快取伺服器失敗，HACache 仍可供使用，因為仍有兩部快取主機可用來儲存兩份已快取之物件或區域的複本。在 T3，當第二部快取主機失敗時，HACache 會變成無法使用。這是因為已經沒有其他快取主機可用來儲存已快取之物件或區域的次要複本。

其他高可用性建議

若要最佳化已快取之資料的可用性，請考量下列建議：

  • 採用大量的快取主機。

  • 將分散式快取系統部署在防火牆內，並將所有伺服器成員加入相同網域，包括快取用戶端、主要資料來源伺服器，以及主控叢集組態儲存位置的伺服器。

  • 使用 SQL Server 或自訂提供者來儲存快取叢集組態設定

  • 盡量不要進行需要停止叢集的組態變更。可能的話，請重新建立具名快取，而不要停止整個快取叢集以變更叢集組態設定。

  • 重新啟動伺服器之前，一律使用 Stop-CacheHost 命令來停止快取服務。使用主要主機來執行叢集管理角色時，若停止快取服務的動作導致整個快取叢集將自己關機 (因為沒有大部分的執行中主要主機)，Stop-CacheHost Cmdlet 將不會成功。

另請參閱

概念

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

  2012-03-05