核心群組調整大小考量
高可用性管理程式耗用的系統資源(例如 CPU 及記憶體)數量,並不是隨著核心群組大小的增加而按線性增加。例如,高可用性管理程式所使用的「視圖同步化通訊協定」需要大量的這些資源,以便在核心群組成員之間維持緊密的連結。因此,大型核心群組所耗用的資源量可能會非常大。
- 正在執行的應用程式數。
- 正在執行的應用程式類型。
- 所使用的高可用性管理程式服務。
在設定核心群組可調整性時,您必須確定:
- 將 Cell 中所有的處理程序正確分散至適當大小的核心群組中。正確分散這些處理程序可限制「視圖同步化通訊協定」耗用的資源數量。
- 正確配置給定的核心群組中的所有處理程序,以支援在核心群組中使用的高可用性服務。
即使系統能正常運作,也要考慮實作下列其中一或多種可調整性技術,以便在大型 Cell 中調整高可用性管理程式。以下是兩種最基本的技術:
- 如果不需要高可用性管理程式,則予以停用。
- 將處理程序分散至多個核心群組,並在需要時使用核心群組橋接器來連接核心群組。
調整核心群組大小
- 第一個也是最重要的層面,是對一組使用中的核心群組成員建立「視圖同步化通訊協定」。 此活動通常稱為視圖變更。
- 第二個層面是高可用性管理程式在背景中定期排程執行探索和失敗偵測作業。
- 第三個層面是其他產品元件在使用高可用性管理程式所提供的服務時,所造成的資源用量。
- 視圖變更
每當「視圖同步化通訊協定」偵測到作用中的核心群組成員發生變更時,即會建立新的視圖。一般而言,每當核心群組成員啟動或停止時,就會發生視圖變更。當核心群組成員啟動時,它會開啟與其他所有正在執行的核心群組成員之間的連線。當其中一個核心群組成員停止時,其他核心群組成員會偵測到它們與已停止成員之間的連線已關閉。在任一種情況下,「視圖同步化通訊協定」都需要反映此變更。針對新啟動的成員,「視圖同步化通訊協定」必須建立一個包含新成員的視圖。針對已停止的成員,「視圖同步化通訊協定」必須為繼續存在的核心群組成員建立新的視圖,用於排除已停止的成員。
建立新視圖是一項重要活動,但它會使用許多系統資源,如果是大型核心群組更是如此。- 正在執行的每一個核心群組成員必須將它的現行狀態(包括它在現行視圖中已傳送或接收之訊息的相關資訊)告訴其他核心群組成員。
- 必須在所有收件者都收到在給定視圖中傳送的所有訊息並進行確認之後,才能安裝新視圖。在正常操作情況下,不會立即確認接收到的這些訊息。如果要準時完成視圖變更範圍內的訊息,必須主動確認並重新傳輸。
- 所有核心群組成員都必須傳送與他們的現行狀態相關的資料,例如,傳送給他們可主動通訊的一組其他核心群組成員。
隨著作用中成員數目的增加,安裝新視圖時,會需要暫時非線性大量增加高可用性管理程式的 CPU 使用量。當有 50 個其他核心群組成員時,新增或移除單一成員所需要的成本,比在只有 20 個其他核心群組成員時,新增或移除單一成員明顯高出許多。
安裝新視圖時,也會在使用高可用性管理程式的產品元件中觸發狀態變更。例如,您可能需要更新遞送表,以反映已啟動或已停止的成員,或可能需要對新成員重新啟動單態服務。
安裝新視圖最後的結果,是造成 CPU 使用量瞬間突然大幅增加。如果核心群組大小變得太大,則會在視圖變更範圍,使得網路計時狀況惡化。 這些情況通常會導致在嘗試安裝新視圖期間發生失敗。如果要從這種失敗回復也需要大量 CPU。 如果沒有足夠的 CPU 可用或發生分頁時,失敗數量會快速倍增。
- 背景作業
高可用性管理程式會定期執行許多背景作業,例如,檢查它所管理的高可用性單態服務的性能。這些背景作業大部分會耗用很少的 CPU。不過,定期排程的探索通訊協定和「失敗偵測通訊協定」是例外。
「探索通訊協定」會嘗試在目前未連接的核心群組成員(包括未執行的處理程序)之間建立通訊。 若為包含 N 個核心群組成員的給定核心群組(其中有 M 個核心群組成員目前正在執行),在每一個探索期間大約會產生 M x (N – M) 個探索訊息。因此,建立許多從未啟動的處理程序會對「探索通訊協定」的 CPU 使用量造成負面影響。
同樣地,當「失敗偵測通訊協定」執行時,每個核心群組成員都會將活動訊號,傳送至其與其他核心群組成員建立的所有連線。針對 M 個作用中成員,則會傳送 M x (M-1) 個活動訊號訊息。如果需要主動進行失敗偵測,核心群組大小可能會對核心群組成員之間的活動訊號所耗用的 CPU 使用量產生負面影響。
核心群組越小,越能對這兩種通訊協定所耗用的 CPU 使用量產生正面影響。例如,如果核心群組包含 100 個作用中成員,則在每一個失敗偵測期間內,將傳送 9900 個活動訊號訊息。如果您將這個包含 100 名成員的核心群組,分成 5 個各包含 20 名成員的核心群組,此訊息數量將大幅減少為 1900 個。
- 外部使用
- 其他產品元件(如工作量管理 (WLM))及隨需應變配置會使用高可用性管理程式所提供的服務(例如,即時伺服器狀態交換)來維護遞送資訊。這些元件耗用的 CPU 使用量的總數會鏈結至核心群組大小。例如,使用即時伺服器狀態交換來建置高可用性遞送資訊,會鏈結至核心群組大小。
將處理程序分散於多個核心群組
- 對於沒有使用高可用性管理程式所提供服務的處理程序,您可以停用高可用性管理程式。
- 您可以將核心群組大小保持很小。
限制高可用性管理程式的 CPU 使用量的關鍵,就是限制核心群組大小。使用多個較小的核心群組,比使用一個大型核心群組更好。如果您有大型的 Cell,則應該建立多個核心群組。
在決定您環境適用的核心群組大小時,用來執行產品的硬體也是一個考量因素。
您應該將較大的核心群分割成多個較小的核心群組。如果分割之後取得的核心群組需要共用遞送資訊,您可以使用核心群組橋接器將核心群組橋接起來。
核心群組大小
- 當您將 IBM_CS_WIRE_FORMAT_VERSION 核心群組自訂內容設為值 6.1.0 時,即可改善核心群組內部的通訊協定。只有 6.1 版及更新版本才提供了這些改良功能。
- 當您將 IBM_CS_HAM_PROTOCOL_VERSION 核心群組自訂內容設為值 6.0.2.31 時,您可以在記憶體使用率及核心群組橋接器的失效接手性質方面獲得大幅改善。
- 您可以調整傳輸記憶體設定。有兩個記憶體或緩衝區大小設定與核心群組傳輸相關聯。
針對最多包含 50 個成員的小型核心群組,這些設定的預設值已經足夠。若為包含 50 個以上成員的核心群組,這些設定的值必須大於預設值。註: 增加這些傳輸記憶體設定的值,不會直接轉換成高可用性管理程式使用更多的靜態配置記憶體或長期記憶體。
- 最多包含 100 個成員的核心群組應該可以正常運作,不會發生任何問題。
- 包含 100 個以上成員的核心群組在許多拓蹼中應該可以正常運作,不會發生任何問題。建議核心群組的成員數目不要超過 200 個。
根據所使用的應用程式混合及服務來調整個別的核心群組
可能需要根據核心群組成員使用的應用程式混合及高可用性服務,來進一步調整個別的核心群組。
- 如果「探索通訊協定」和「失敗偵測通訊協定」的執行頻率預設值不適用,請調整這些設定值。
- 將核心群組協調程式配置為針對特定處理程序或一組處理程序執行。
- 如果協調程式處理程序所耗用的資源很多,則可以在多個實例之間分配協調程式。
- 配置可供分散式和一致性服務 (DCS),以及可靠的多重播送傳訊 (RMM) 元件使用的記憶體數量,以便在偵測到壅塞時傳送網路訊息。在某些情況下,即使沒有使用記憶體至記憶體抄寫,也可能發生壅塞。
調整暫時埠範圍
核心群組使用的 Socket 數量通常不是主要的考量因素。 每一個核心群組成員都必須與該核心群組中的其他每一個成員建立連線。因此,由於每一個連線需要兩個 Socket,連線的兩端各一個,因此連線數目會呈指數(n 平方)成長。由於通常都會包含多部機器,因此您一般無須關心核心群組所使用的 Socket 數量。不過,如果您在一部機器上執行的核心群組成員數量異常龐大,則可能需要調整與暫時埠範圍相關的作業系統參數。大部分作業系統在暫時埠範圍都有不同的預設行為。
