核心群組移轉考量

第 6 版及更高版本中提供了高可用性管理程式及核心群組功能。本主題討論當您從不包含此功能的產品版本(例如 5.1 版)進行移轉時,可能會對移轉造成影響的核心群組配置及拓蹼考量。

閱讀這篇文章之前,您應該先瞭解下列主題中包含的基本核心群組概念:
  • 高可用性管理程式
  • 使用高可用性管理程式的時機
  • 核心群組
  • 核心群組傳輸
  • 核心群組協調程式
  • 核心群組管理考量
  • 核心群組調整大小考量

由於在從不具備高可用性管理程式的產品版本,移轉至具有高可用性管理程式的產品版本之前,您的環境可能需要執行特殊的規劃和移轉活動,因此您應該知道下列問題的答案:

與預設核心群組相關的移轉活動

移轉程序期間自動執行的核心群組相關活動,相對來說簡單直接。從 5.x 版環境移轉至 7.0 版環境時,下列動作會依指示順序執行:
  1. 將部署管理程式移轉至 7.0 版。
  2. 在移轉程序期間,會建立 7.0 版部署管理程式設定檔及一個稱為 DefaultCoreGroup 的核心群組。
  3. 將新的部署管理程式程序新增到 DefaultCoreGroup。
  4. 將 5.x 版節點逐一移轉至 7.0 版。在移轉每一個節點時,正在移轉的節點上的節點代理程式和應用程式伺服器會新增到 DefaultCoreGroup 中。

移轉完成時,5.x 版 Cell 中的所有處理程序,都會成為 7.0 版 DefaultCoreGroup 的成員。由於 DefaultCoreGroup 是使用所有設定的預設值配置的,因此移轉程序不會配置偏好的協調伺服器,且不會在多個伺服器之間分割協調程式。移轉程序也不會建立新的高可用性原則,並且不會針對任何自訂內容配置置換提供這些原則。

核心群組拓蹼規劃

對於大部分的 5.x 版拓蹼而言,預設移轉會產生合適、可用的 7.0 版核心群組拓蹼。在某些情況下,可能需要對拓蹼進行少量的變更,例如,設定非預設傳輸或配置核心群組以進行抄寫。如果 5.x 版 Cell 大到需要 7.0 版拓蹼中具有多個核心群組,則應該在啟動移轉程序之前進行更仔細的規劃,以避免在變更核心群組配置時,發生應用程式中斷的情形。

將大型 5.x 版 Cell 移轉至 7.0 版(需要多個核心群組)可能是一項複雜的作業。當 7.0 版拓蹼需要多個核心群組時,您有多個選項,可以選擇如何及何時將 Cell 分割至多個核心群組中。您使用的方法應該根據一些因素,例如:Cell 中的處理程序數目,並且要求應用程式持續保持可用。例如,雖然一般建議核心群組中包含大約 50 個成員,但實際限制要稍微高於 50。對於在高階機器(具有大量記憶體的大型 CPU)上安裝了少量應用程式的拓蹼來說,您可能可以擁有最多 200 個成員的核心群組。如果 Cell 中有 150 個處理程序,且應用程式可用性沒有問題,則可以選擇僅將整個 Cell 移轉至 7.0 版,然後建立其他核心群組。如果應用程式可用性是個問題,您應該在移轉程序期間建立其他核心群組,這樣在移轉程序完成時,即無須停止並重新啟動核心群組成員。

核心群組大小
最重要的規劃考量是核心群組的大小。 依預設,每個 Cell 通常會有一個核心群組。由於核心群組無法調整到較大的大小,因此如果您的 5.x 版 Cell 很大,您可能需要針對 7.0 版拓蹼建立其他核心群組。如果有多個核心群組需要互相通訊,您可能也需要設定核心群組橋接器。
核心群組傳輸
如果變更了核心群組傳輸配置,則必須重新啟動所有核心群組成員之後,變更才會生效。因此需要進行規劃,將變更傳輸所造成的影響減至最低程度。如果您變更了 DefaultCoreGroup 的傳輸,最好在移轉「部署管理程式」之後立即進行變更,因為此時只有「部署管理程式」需要重新啟動。如果您建立其他核心群組,則須在建立新的核心群組時,正確配置傳輸。
自訂內容配置置換
透過「自訂內容」置換可以變更許多核心群組配置參數。在「資訊中心」其他文章的本節內記載了可用的自訂內容置換。

每次新增、移除或變更「自訂內容」置換時,都必須重新啟動所有核心群組成員,使變更生效。因此需要進行規劃,將變更「自訂內容」所造成的影響減至最低程度。如果因變更了 DefaultCoreGroup 而必須變更「自訂內容」,則最好在移轉「部署管理程式」之後,立即進行變更。如果您建立其他核心群組,則須在建立新的核心群組時,變更「自訂內容」。

核心群組協調程式
配置偏好的協調伺服器是最佳作法。由於 HA 管理程式可以動態重新讀取,並套用核心群組協調程式配置變更,因此不需要重新啟動所有核心群組成員,使變更生效

範例:大型的 Cell 移轉

下列範例說明幾個經過考慮的處理程序,當您規劃和執行從大型 5.x 版 Cell 移轉至 7.0 版時(需要多個核心群組),您應該完成這些處理程序。基於這個範例的目的,假設您的 5.x 版 Cell 具有下列拓蹼性質:

  • 該 Cell 包含 8 個節點,分別命名為 Node1、Node2、Node3、…及 Node8,但不包括部署管理程式節點。
  • 該 Cell 包含 10 個叢集,分別命名為 Cluster1、Cluster2、Cluster3、…、Cluster10。
  • 叢集 Cluster1 到 Cluster9 分別包含 32 個應用程式伺服器。 這些叢集的叢集成員會平均分散於所有節點之間,每個節點有 4 個應用程式伺服器
  • Cluster10 包含 28 個應用程式伺服器。Node1 上沒有任何屬於 Cluster10 的應用程式伺服器。Cluster10 的應用程式伺服器平均分散於節點 Node2 到 Node8,每一個節點包含 4 個應用程式伺服器。
  • 這個 Cell 中總共有 316 個應用程式伺服器、8 個節點代理程式和一個部署管理程式。
  • 每一個叢集都部署了一個使用 EJB 的應用程式,而且這些應用程式可以彼此通訊。因此,工作量管理 (WLM) 遞送資訊,必須在 Cell 中的任何位置都可用。
  • 移轉期間,應用程式必須持續保持可用。
  • 執行移轉需要幾天或幾週的時間。

規劃 7.0 版核心群組拓蹼時,首先要考慮的是這個 Cell 包含 325 個處理程序,並且要求應用程式持續保持可用。這些因素不容許我們只是移轉整個 Cell,然後重新配置核心群組。移轉程序中,您必須將 Cell 中所包含的處理程序分散於多個核心群組中。

決定將 5.x 版 Cell 處理程序分散於新的核心群組的方式時,請確定每一個核心群組都符合下列核心群組規則:

  • 每一個核心群組都必須包含至少一個管理處理程序。由於此範例中的 Cell 有 9 個管理處理程序(8 個節點代理程式和這個部署管理程式),因此這個拓蹼中,最多可以有 9 個核心群組。
  • 叢集的所有成員都必須是相同核心群組的成員。
  • 每一個核心群組中所包含的處理程序數目不能超出建議的大小(大約 50 個成員)。
此範例遵循下列規則:
  • 其中至少有一個核心群組必須包含兩個叢集,由於最多只能將 Cell 分割成 9 個核心群組,但5.x 版 Cell 中有 10 個叢集。
  • 所有包含多個叢集的核心群組都會有 50 個以上的成員,因為每個叢集都包含 28 或 32 個應用程式伺服器。

雖然至少有一個核心群組的成員數目會超出建議限制,但是成員數目並不會超出實際限制,應該不會產生問題。

由於此範例中的應用程式需要 Cell 所包含的每一個叢集的 WLM 遞送資訊,因此您必須設定核心群組橋接器,以便在所有核心群組之間啟用通訊。(如果您不熟悉如何設定核心群組橋接器,請參閱核心群組橋接器主題。)適用於這個範例的核心群組橋接器拓蹼包括:

  • 每一個核心群組一個核心群組存取點。每一個存取點都包含針對該核心群組提供橋接器介面的處理程序集。 橋接器介面是實際和其他核心群組中的處理程序通訊的處理程序。
  • 每一個存取點有兩個橋接器介面,以避免核心群組橋接器發生單點故障。這兩個橋接器介面會放置在不同節點上,以進一步確保持續保持可用。

    選取作為橋接器介面的處理程序時,請記住,橋接器介面需要額外的記憶體及 CPU 循環。一般而言,由於在正常作業期間,節點代理程式的工作量低於應用程式伺服器或部署管理程式的工作量,因此節點代理程式是適合作為橋接器介面的處理程序。

    不過在此範例中,只有 8 個節點代理程式可作為橋接器介面。由於此拓蹼需要每一個存取點有兩個橋接器介面,因此如果您只將節點代理程式當成橋接器介面使用,則您將限制為使用 4 個存取點,以便只能使用 4 個核心群組。因此,在啟動移轉程序之前,您可能想要建立 8 個獨立式伺服器,專門作為橋接器介面,而不管理應用程式。 然後,每一個存取點可以包含一個節點代理程式和一個獨立式的橋接器介面伺服器。此設定會為您提供總計 8 個存取點和 8 個核心群組。

  • 包含所有存取點的單一核心群組存取點群組。單一核心群組存取點群組會確定所有橋接器介面處理程序都能直接通訊。這些橋接器介面形成一個完全連接的網眼。

    替代拓蹼是使用多個存取點群組,以產生鏈結拓蹼。在鏈結拓蹼中,通訊資料沿著鏈中的中間橋接器介面,從一個橋接器介面轉送到另一個橋接器介面。

由於確定了核心群組橋接器介面的設定,您現在可以決定如何將 10 個叢集、8 個節點代理程式、8 個獨立的橋接器介面伺服器及這個部署管理程式分散在 8 個核心群組中。您想要儘可能地將程序均勻分散在 8 個核心群組中。下列拓蹼是一個很好的例子,它說明如何均勻地分散 5.x 版 Cell 所包含的處理程序:

  • 第一個核心群組 DefaultCoreGroup 包含部署管理程式、Node1 中的節點代理程式、Node2 中的橋接器伺服器以及 Cluster1。
  • 核心群組 2 包含 Node2 中的節點代理程式、Node3 中的橋接器伺服器及 Cluster2
  • 核心群組 3 包含 Node3 中的節點代理程式、Node4 中的橋接器伺服器及 Cluster3

在此範例中,不需要變更預設傳輸。

由於此範例未指出您需要每一個核心群組有多個協調程式,因此您可以將協調程式設定保持為預設值 1。不過,您可能想要讓每一個核心群組中所包含的獨立式橋接器介面伺服器,成為這個核心群組的偏好協調伺服器。這個指定方式一開始將協調程式所需的工作量,與執行應用程式的叢集應用程式伺服器分隔開來。

您的移轉計劃

在檢閱上述範例,並針對要移轉的 Cell 進行初步規劃程序之後,如果您決定預設移轉流程不適合目標 7.0 版拓蹼,現在可以為實際移轉程序制訂計劃或導覽圖。 這個計劃應包含從 5.x 版移轉至 7.0 版時,與核心群組相關之所有額外的必要步驟,以及下列問題的回答:

何時會建立新的核心群組?
最好是在部署管理程式移轉完成之後,立即建立新的核心群組。建立新的核心群組時,您應該配置先前所提及的自訂內容。您可以使用管理主控台或 createCoreGroupwsadmin 指令來建立新的核心群組。不過,您必須使用管理主控台來配置自訂內容。
移轉節點時需要執行什麼動作?
在移轉每一個節點時,您應該:
  • 建立新的獨立式應用程式伺服器,使其成為其中一個核心群組橋接器介面。
  • 調整節點上所有處理程序中的傳輸緩衝區大小。最好使用 Script 來執行此動作。
  • 調整節點代理程式和獨立式伺服器上的資料堆大小,並為這些處理程序開啟詳細記憶體回收監視。
您必須完成所有這些變更之後,才能重新啟動移轉的節點。您可以使用管理主控台來完成這些作業,然後執行手動同步化節點配置,再重新啟動節點代理程式和應用程式伺服器。
何時及如何將處理程序移至新的核心群組?
依預設,移轉程序會將所有處理程序放置在名稱為 DefaultCoreGroup 的核心群組中。在某個時間點,這個核心群組中所包含的成員數目會超出大小限制,您必須將程序重新配送給其他核心群組。您必須瞭解的重點,是必須在處理程序停止之後,才能移動它們。如果需要應用程式持續保持可用,您必須仔細規劃將處理程序移至不同核心群組的順序。

您可以利用管理主控台或 moveServerToCoreGroupwsadmin 指令來移動部署管理程式、節點代理程式和獨立式應用程式伺服器。

移動叢集應用程式伺服器更複雜些。在一般情況下,您可以使用管理主控台或 moveServerToCoreGroupwsadmin 指令來移動叢集。不過在移轉程序期間,由於您要移動的叢集可能同時具有 7.0 版和 5.x 版成員,而 5.x 版叢集成員還不是任何核心群組的成員,因此一般指令會失效。如果要將混合式叢集移至新的核心群組,您必須使用具有選用 checkConfig 參數的 moveClusterToCoreGroup wsadmin 指令。

例如,假設 Cluster0 具有叢集成員 A、B、C 和 D。成員 A 在已移轉至 7.0 版的節點上,且為 DefaultCoreGroup 的成員,而 B、C 和 D 仍在 5.x 版節點上。如果要將 Cluster0 移到核心群組 CG1,請使用下列指令:
$AdminTask moveClusterToCoreGroup {-source CoreGroup1 –target CG1
     –clusterName Cluster0 –checkConfig false}

移轉叢集應用程式伺服器時,移轉公用程式會判斷其他叢集成員是否已經移轉,且會自動將移轉成員與相同叢集中已移轉的其他成員放置在相同的核心群組中。

在前面的範例中,成員 A 已移到核心群組 CG1。移轉包含 B、C 和 D 的節點時,移轉作業會將這些叢集成員放置在 CG1 而不是 DefaultCoreGroup 中。因此,您必須僅針對每一個叢集執行一次 moveClusterToCoreGroup 指令。

何時需要配置核心群組橋接器?
將處理程序移至多個核心群組之前,您必須配置核心群組橋接器,並讓它們執行。這表示您要在 7.0 版目標拓蹼中當成橋接器介面使用的處理程序,在您最初需要時可能無法使用,因為尚未從 5.0 版節點移轉過來。因此,如果要確保應用程式能持續保持可用,您必須在移轉程序中,將某些叢集應用程式伺服器配置為暫時的橋接器介面。將所有處理程序都移轉至 7.0 版之後,您可以調整核心群組橋接器配置,以符合所需要的 7.0 版拓蹼。

其他規劃考量

如果目標 7.0 版配置需要多個核心群組橋接器,請使用 IBM_CS_WIRE_FORMAT_VERSION 核心群組自訂內容來實作調整大小的改進功能。

此外,如果所有核心群組都橋接在一起,且彼此傳遞共用資訊,則在核心群組成員之間共用的資料量,可能會比正常情況大許多。因此,您應該使用下列設定來增加核心群組記憶體設定,以便更有效地傳送資料:

  • 將 IBM_CS_DATASTACK_MEG 設為 100
  • 將所有處理程序中的傳輸緩衝區大小設為 100。

針對您要作為橋接器介面的任何節點代理程式或應用程式伺服器,以及要作為協調程式的任何獨立式伺服器,您也應該考慮調整如 JVM 資料堆大小之類的因素。建議從將資料堆大小增加 512 MB 開始。另外,也可以為這些處理程序開啟詳細記憶體回收監視,以便隨著時間調整這些資料堆大小。

可能的移轉流程

有一些移轉流程可以讓您成功實作移轉作業。下列流程假定有一個共同起始點;亦即已完成部署管理程式移轉,而且已建立核心群組,但是還沒執行進一步的動作。

移轉流程 1
在這個流程中,我們會嚴格遵守規則。這個流程因幾個原因而無法滿足需求。在移轉每一個節點時,會需要移動叢集。這需要先停止所有叢集成員。這可能導致應用程式無法使用。此外,每一個步驟中都需要重新配置橋接器。
  • 移轉 Node1。DefaultCoreGroup 包含部署管理程式和 Node1 中的所有處理程序。由於 DefaultCoreGroup 包含的成員數目小於 50,所以不需要其他動作。
  • 移轉 Node2。現在,DefaultCoreGroup 包含的處理程序數目超過建議的處理程序數目。藉由將一半叢集和 Node2 中的節點代理程式移至 CoreGroup2 中,平衡 2 個核心群組中的處理程序。由於現在使用多個核心群組,因此我們必須配置核心群組橋接器。在節點 Node1 和 Node2 上建立橋接器介面伺服器。配置核心群組橋接器,將兩個核心群組橋接在一起。
  • 移轉 Node3。透過將 DefaultCoreGroup 和 CoreGroup2 中的部分叢集移至 CoreGroup3,平衡 3 個核心群組中的處理程序。將 Node3 的節點代理程式移至 CoreGroup3。在 Node3 上建立橋接器介面伺服器。重新配置核心群組橋接器,將全部三個核心群組橋接在一起。
  • 繼續移轉節點,直到移轉完成為止。在移轉每一個節點時,可能需要對核心群組橋接器進行一些重新平衡及重新配置。
移轉流程 2
在此流程中,我們會暫時放鬆規則。由於無需停止正在執行的應用程式伺服器,就能將它們移至另一個核心群組,因此這個流程可以產生更好的結果。移轉進行時,部分核心群組在某段時間內將不包含管理處理程序。這是規則的技術性違規,但只要在移轉進行期間,不要變更核心群組配置,即是可以接受的。
  • 移轉 Node1。Node1 包含除了 Cluster10 以外的所有叢集中的成員
  • 將所有可能的叢集移至在最終目標拓蹼中識別的核心群組。部署管理程式、Node1 的節點代理程式和 Cluster1 已在 DefaultCoreGroup 中,因此不需要對它們執行進一步的動作。將 Cluster2 移至 CoreGroup2,將 Cluster3 移至 CoreGroup3,依此類推。為 Node1 建立橋接器伺服器,並將它放置在 CoreGroup2 中。
  • 配置核心群組橋接器,將全部 8 個核心群組橋接在一起。為了簡單起見,我們將暫時為每一個存取點配置單一橋接器介面。(這會在移轉正在進行時建立單一失敗點)由於最終拓蹼中的大部分橋接器介面仍在 5.x 版上,因此您必須將應用程式伺服器當成 8 個核心群組其中 6 個的暫時橋接器介面。這可能需要暫時增加選取的應用程式伺服器的資料堆大小。
  • 移轉 Node2。移轉作業會自動將 Node2 的叢集應用程式伺服器移至適當的核心群組。由於 Node1 上沒有任何屬於 Cluster10 的應用程式伺服器,因此請手動將 Cluster10 移至 CoreGroup8。將 Node2 的節點代理程式移至 CoreGroup2。在 Node2 上建立橋接器伺服器。(選用)重新配置核心群組橋接器,使某些暫時的橋接器介面伺服器位於 Node2 上,以協助將負載分散在這兩個節點上。
  • 使用相同型樣繼續移轉節點,直到所有節點都移轉為止。
  • 移轉所有節點之後,請配置偏好的協調伺服器。 重新配置橋接器介面,以與最終目標拓蹼(每一個存取點中有兩個橋接器介面伺服器)相符。停止作為暫時的橋接器介面的伺服器,然後將其重新啟動。重新啟動新的橋接器介面伺服器。
移轉流程 3
此流程是移轉流程 2 的變異形式。依照說明,此流程是移轉流程 2 的變異形式。該流程的優點是初始橋接器負載會分散在三個節點,而不是一個節點上。缺點是在移轉 Node3 之後,會開始將叢集重新配送到核心群組。您必須停止在節點 Node1 和 Node2 上執行的伺服器,才能進行移動。這可能會影響應用程式的可用性。
  • 移轉 Node1。完成這個步驟之後,DefaultCoreGroup 將包含 38 個處理程序(未超出限制)。
  • 移轉 Node2。完成這個步驟之後,DefaultCoreGroup 將包含 79 個處理程序。這雖然大於建議大小,但仍在實際限制內。
  • 移轉 Node3。將所有叢集移至在最終拓蹼中識別的核心群組。將 Cluster2 移至 CoreGroup2,將 Cluster3 移至 CoreGroup3,依此類推。將三個節點代理程式移至適當的核心群組。建立三個橋接器介面伺服器,並將它們移至適當的核心群組。
  • 選取叢集應用程式伺服器來作為尚未包含所指定橋接器介面之核心群組的暫時橋接器。暫時調整這些伺服器上的資料堆大小。配置核心群組橋接器,將全部 8 個核心群組橋接在一起。
  • 繼續移轉節點,直到所有節點都移轉為止。
  • 移轉所有節點之後,請配置偏好的協調程式。重新配置橋接器介面,使其與最終目標拓蹼相符。根據需要停止並重新啟動處理程序。

指出主題類型的圖示 概念主題



時間戳記圖示 前次更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_ha_cgmigration
檔名:crun_ha_cgmigration.html