코어 그룹 마이그레이션 고려사항
고가용성 관리자와 코어 그룹 기능은 버전 6 이상에서 제공됩니다. 이 주제에서는 버전 5.1과 같이 이 기능이 없는 제품 버전에서 마이그레이션할 경우 마이그레이션에 영향을 미치는 코어 그룹 구성과 토폴로지 고려사항에 대해 설명합니다.
- 고가용성 관리자
- 고가용성 관리자 사용 시기
- 코어 그룹
- 코어 그룹 전송
- 코어 그룹 조정자
- 코어 그룹 관리 고려사항
- 코어 그룹 스케일링 고려사항
사용자 환경에 특수 계획과 마이그레이션 활동이 필요할 수 있으므로 고가용성 관리자가 없는 제품 버전에서 고가용성 관리자가 있는 제품 버전으로 마이그레이션하기 전에 다음 질문에 대한 답을 알아야 합니다.
- 버전 7.0으로 완전히 마이그레이션된 후 셀에 적합한 코어 그룹 구성과 토폴로지는 무엇입니까?
- 혼합 환경의 경우 버전 5.x 셀이 메모리 대 메모리 복제를 사용하도록 구성되었습니까? 그런 경우 복제 환경을 마이그레이션하는 방법은 무엇입니까? 마이그레이션 프로세스 중에 복제는 어떤 영향을 받습니까?
- 버전 5.x 셀에서 사용되는 JMS 제공자는 무엇입니까(해당되는 경우)?
- 버전 7.0 셀에서 사용되는 JMS 제공자는 무엇입니까(해당되는 경우)?
- 버전 7.0 기본 IBM® 메시징 제공자를 버전 7.0 셀에서 사용할 경우 메시징 제공자를 고가용성으로 구성해야 합니까?
- 버전 7.0 셀에서 트랜잭션 로그 복구를 구성해야 합니까?
기본 코어 그룹 관련 마이그레이션 활동
- 배치 관리자가 버전 7.0으로 마이그레이션됩니다.
- 마이그레이션 프로세스 중에 버전 7.0 배치 관리자 프로파일과 DefaultCoreGroup이라는 코어 그룹이 작성됩니다.
- 새 배치 관리자 프로세스가 DefaultCoreGroup에 추가됩니다.
- 버전 5.x 노드가 버전 7.0으로 차례로 마이그레이션됩니다. 각 노드가 마이그레이션되면 마이그레이션 중인 노드의 노드 에이전트와 애플리케이션 서버가 DefaultCoreGroup에 추가됩니다.
마이그레이션이 완료되면 버전 5.x 셀의 모든 프로세스가 버전 7.0 DefaultCoreGroup의 멤버가 됩니다. DefaultCoreGroup은 모든 설정의 기본값으로 구성되므로 마이그레이션 프로세스에서 선호되는 조정자 서버를 구성하지 않고 복수 서버에서 조정자를 파티션하지 않습니다. 또한 마이그레이션 프로세스에서는 새 고가용성 정책을 작성하지 않으며 사용자 정의 특성 구성 대체를 제공하지 않습니다.
코어 그룹 토폴로지 계획
대부분의 버전 5.x 토폴로지에서는 기본 마이그레이션을 통해 적절하고 작업 가능한 버전 7.0 코어 그룹 토폴로지를 얻습니다. 일부 경우 기본값이 아닌 전송을 설정하거나 복제할 수 있도록 코어 그룹을 구성하는 등 토폴로지를 약간 변경해야 할 수도 있습니다. 버전 5.x 셀이 버전 7.0 토폴로지에 여러 개의 코어 그룹이 필요할 만큼 충분히 큰 경우에는 코어 그룹 구성을 변경할 때 애플리케이션이 중단되지 않도록 마이그레이션 프로세스를 시작하기 전에 추가 계획을 완료해야 합니다.
대형 버전 5.x 셀을 여러 개의 코어 그룹이 필요한 버전 7.0으로 마이그레이션하는 것은 복잡한 태스크입니다. 버전 7.0 토폴로지에 복수 코어 그룹이 필요한 경우 셀을 복수 코어 그룹으로 파티션하는 방법과 시기와 관련된 여러 옵션이 있습니다. 사용할 접근 방식은 셀의 프로세스 수, 지속적인 애플리케이션 가용성 관련 요구사항 등의 요소를 기반으로 결정해야 합니다. 예를 들어, 일반적으로는 코어 그룹에서 약 50개의 멤버를 유지하도록 권장되지만 실제 한계는 50보다 큽니다. 고급 시스템(메모리가 많은 대형 CPU)에 적은 수의 애플리케이션이 설치된 토폴로지의 경우 코어 그룹에 최대 200개의 멤버가 있을 수도 있습니다. 셀에 150개의 프로세스가 있고 애플리케이션 가용성은 문제가 되지 않는 경우 간단히 전체 셀을 버전 7.0으로 마이그레이션한 후 추가 코어 그룹을 작성하는 옵션도 있습니다. 애플리케이션 가용성이 문제가 되는 경우에는 마이그레이션 프로세스가 완료된 후 코어 그룹 멤버를 중지하고 다시 시작하지 않아도 되도록 마이그레이션 프로세스 중에 추가 코어 그룹을 작성해야 합니다.
- 코어 그룹 크기
- 가장 중요한 계획 고려사항은 코어 그룹의 크기입니다. 기본적으로 대개 셀당 하나의 코어 그룹이 있습니다. 코어 그룹은 큰 크기로 스케일이 조정되지 않으므로 버전 5.x 셀이 큰 경우 버전 7.0 토폴로지에 사용할 추가 코어 그룹을 작성할 수 있습니다. 또한 이와 같은 여러 코어 그룹이 서로 통신해야 하는 경우에는 코어 그룹 브릿지를 설정해야 합니다.
- 코어 그룹 전송
- 코어 그룹 전송 구성이 변경되면 변경사항이 적용되기 전에 모든 코어 그룹 멤버를 다시 시작해야 합니다. 따라서 전송 변경의 영향을 최소화하려면 계획이 필요합니다. DefaultCoreGroup의 전송이 변경되는 경우 가장 좋은 변경 시간은 배치 관리자 마이그레이션 직후입니다. 해당 시점에서는 배치 관리자만 다시 시작하면 되기 때문입니다. 다른 코어 그룹이 작성되는 경우에는 새 코어 그룹이 작성될 때 전송이 올바로 구성되어야 합니다.
- 사용자 정의 특성 구성 대체
- 사용자 정의 특성 대체를 통해 여러 코어 그룹 구성 매개변수를
변경할 수 있습니다. 사용 가능한 사용자 정의 특성 대체에 대해서는
이 섹션의 다른 Information Center 문서에 설명되어 있습니다.
사용자 정의 특성 대체가 추가, 제거 또는 변경될 때마다 변경사항을 적용하려면 모든 코어 그룹 멤버를 다시 시작해야 합니다. 그러므로 사용자 정의 특성 변경의 영향을 최소화하려면 계획이 필요합니다. DefaultCoreGroup이 변경되어 사용자 정의 특성을 변경해야 하는 경우 가장 좋은 변경 시간은 배치 관리자 마이그레이션 직후입니다. 다른 코어 그룹이 작성되는 경우에는 새 코어 그룹을 작성할 때 사용자 정의 특성을 변경해야 합니다.
- 코어 그룹 조정자
- 기본 조정자 서버를 구성하는 것은 우수 사례입니다. HA 관리자가 동적으로 코어 그룹 조정자 구성 변경사항을 다시 읽고 적용할 수 있으므로 이 변경사항을 적용하기 위해 모든 코어 그룹 멤버를 다시 시작할 필요가 없습니다.
예: 대형 셀 마이그레이션
다음 예제에서는 대형 버전 5.x 셀을 여러 개의 코어 그룹이 필요한 버전 7.0으로 마이그레이션하는 것을 계획하고 실행할 때 수행해야 하는 계획된 프로세스의 일부에 대해 설명합니다. 이 예제에서는 버전 5.x 셀에 다음과 같은 토폴로지 특성이 있다고 가정합니다.
- 셀에 Node1, Node2, Node3, ..., Node8이라는 여덟 개의 노드가 있고 배치 관리자 노드는 포함되어 있지 않습니다.
- 셀에 Cluster1, Cluster2, Cluster3, ..., Cluster10이라는 열 개의 클러스터가 있습니다.
- Cluster1에서 Cluster9까지의 각 클러스터에는 32개의 애플리케이션 서버가 있습니다. 이 클러스터의 클러스터 멤버는 모든 노드에서 노드당 네 개의 애플리케이션 서버가 대칭으로 분배됩니다.
- Cluster10에는 28개의 애플리케이션 서버가 있습니다. Cluster10의 Node1에는 애플리케이션 서버가 없습니다. Cluster10의 애플리케이션 서버는 노드 Node2에서 Node8까지 노드당 네 개의 애플리케이션 서버가 대칭으로 분배됩니다.
- 셀에 총 316개의 애플리케이션 서버, 8개의 노드 에이전트, 하나의 배치 관리자가 있습니다.
- 각 클러스터에는 EJB를 사용하는 애플리케이션이 배치되어 있고 이들 애플리케이션은 서로 통신할 수 있습니다. 따라서 작업 로드 관리(WLM) 라우징 정보를 셀 내부 어디에서나 사용할 수 있어야 합니다.
- 마이그레이션 중에 애플리케이션을 지속적으로 사용할 수 있어야 합니다.
- 마이그레이션은 특정 기간(일 또는 주)에 수행됩니다.
버전 7.0 코어 그룹 토폴로지 계획에서 고려할 첫 번째 사항은 이 셀에 325개의 프로세스가 있다는 것과 애플리케이션의 지속적인 가용성이 요구사항이라는 점입니다. 이러한 요소 때문에 단순히 전체 셀을 마이그레이션한 후 코어 그룹을 다시 구성할 수 없습니다. 마이그레이션 프로세스 중에 셀에 포함된 프로세스를 여러 코어 그룹에 분배해야 합니다.
V5.x 셀 프로세스를 새 코어 그룹에 분배할 방법을 결정할 때에는 각 코어 그룹이 다음과 같은 코어 그룹 규칙을 준수하는지 확인하십시오.
- 각 코어 그룹에 최소한 하나의 관리 프로세스가 있어야 합니다. 이 예제의 셀에는 9개의 관리 프로세스, 8개의 노드 에이전트, 하나의 배치 관리자가 있으므로 이 토폴로지에서 가능한 최대 코어 그룹 수는 9개입니다.
- 클러스터의 모든 멤버는 동일한 코어 그룹의 멤버가어야 합니다.
- 각 코어 그룹에 포함된 프로세스의 수는 권장 크기(약 50개의 멤버)를 초과하면 안 됩니다.
- 셀을 최대 9개의 코어 그룹으로만 분할할 수 있고 V5.x 셀에 10개의 클러스터가 있으므로 최소한 하나의 코어 그룹에 두 개의 클러스터가 있어야 합니다.
- 각 클러스터에 28개 또는 32개의 애플리케이션 서버가 있으므로 복수 클러스터가 있는 코어 그룹에는 50개가 넘는 멤버가 있습니다.
최소한 하나의 코어 그룹에 있는 멤버 수가 권장 한계를 초과하지만 멤버 수는 실제 한계 이내에 있으므로 문제가 발생하지 않습니다.
이 예제의 애플리케이션에는 셀에 있는 각 클러스터의 WLM 라우팅 정보가 필요하므로 모든 코어 그룹 간에 통신할 수 있도록 코어 그룹 브릿지를 설정해야 합니다. (코어 그룹 브릿지 설정 방법을 잘 모르는 경우에는 코어 그룹 브릿지 주제를 참조하십시오.) 이 예제에 적합한 코어 그룹 브릿지 토폴로지는 다음을 포함합니다.
- 각 코어 그룹의 코어 그룹 액세스 지점. 각 액세스 지점에는 코어 그룹의 브릿지 인터페이스를 제공하는 프로세스 세트가 있습니다. 브릿지 인터페이스는 다른 코어 그룹의 프로세스와 실제로 통신하는 프로세스입니다.
- 코어 그룹 브릿지를 SPOF(Single Point Of Failure)로 제거하기 위해
각 액세스 지점에 있는 2개의 브릿지 인터페이스. 이 2개의 브릿지 인터페이스는
지속적인 가용성을 확보하기 위해 다른 노드에도 배치됩니다.
브릿지 인터페이스 기능을 수행할 프로세스를 선택할 때 브릿지 인터페이스에 추가 메모리와 CPU 사이클이 필요하다는 점을 유념하십시오. 일반 조작 중에는 노드 에이전트의 워크로드가 애플리케이션 서버 또는 배치 관리자의 워크로드보다 낮으므로 일반적으로 노드 에이전트는 브릿지 인터페이스로 사용하기 좋은 프로세스입니다.
그러나 이 예제에서는 8개의 노드 에이전트만 브릿지 인터페이스 기능을 수행할 수 있습니다. 토폴로지에서 액세스 지점당 2개의 브릿지 인터페이스가 필요하므로 노드 에이전트만 브릿지 인터페이스로 사용하는 경우 액세스 지점이 4개로 제한되어 코어 그룹도 4개로 제한됩니다. 그러므로 마이그레이션 프로세스를 시작하기 전에 브릿지 인터페이스 기능을 수행하고 애플리케이션을 호스팅하지 않는 8개의 독립형 서버를 작성할 수 있습니다. 그러면 각 액세스 지점에 하나의 노드 에이전트와 하나의 독립형 브릿지 인터페이스 서버가 포함됩니다. 이와 같이 설정하면 총 8개의 액세스 지점과 8개의 코어 그룹이 제공됩니다.
- 모든 액세스 지점이 포함된 하나의 코어 그룹 액세스 지점
그룹. 코어 그룹 액세스 지점 그룹이 하나이면 모든 브릿지 인터페이스
프로세스에서 직접 통신할 수 있습니다. 이와 같은 브릿지 인터페이스는 완전히 연결된
그물망 구조를 형성합니다.
대체 토폴로지에서는 체인 토폴로지를 형성하는 복수 액세스 지점 그룹을 사용합니다. 체인 토폴로지에서는 체인을 따라 중간 브릿지 인터페이스를 통해 하나의 브릿지 인터페이스에서 다른 브릿지 인터페이스로 통신이 전달됩니다.
이제 코어 그룹 브릿지 인터페이스의 설정을 결정했으므로 10개의 클러스터, 8개의 노드 에이전트, 8개의 독립형 브릿지 인터페이스 서버, 배치 관리자를 9개의 코어 그룹에 분배할 방법을 결정할 수 있습니다. 8개의 코어 그룹에 가능한 한 균등하게 프로세스를 분배할 수 있습니다. 다음 토폴로지는 V5.x 셀에 포함된 프로세스를 균등하게 분배하는 방법의 좋은 예입니다.
- 첫 번째 코어 그룹인 DefaultCoreGroup에 배치 관리자, Node1의 노드 에이전트, Node2의 브릿지 서버, Cluster1이 있습니다.
- 코어 그룹 2에는 Node2의 노드 에이전트, Node3의 브릿지 서버, Cluster2가 있습니다.
- 코어 그룹 3에는 Node3의 노드 에이전트, Node4의 브릿지 서버, Cluster3이 있습니다.
이 예제의 기본 전송은 변경할 필요가 없습니다.
이 예제에서는 코어 그룹당 둘 이상의 조정자가 필요한 것으로 표시하지 않으므로 조정자 설정을 기본값인 1로 둘 수 있습니다. 그러나 각 코어 그룹에 포함되어 있는 독립형 브릿지 인터페이스 서버를 해당 코어 그룹의 선호되는 조정자 서버로 설정할 수 있습니다. 이와 같이 지정하면 처음에는 애플리케이션을 실행 중인 클러스터된 애플리케이션 서버에서 조정자가 필요한 워크로드가 발생하지 않습니다.
내 마이그레이션 계획
앞의 예제를 검토하고 마이그레이션 중인 셀의 초기 계획 프로세스를 완료한 후 기본 마이그레이션 플로우가 대상 버전 7.0 토폴로지에 적합하지 않은 것으로 판단되는 경우 실제 마이그레이션 프로세스의 계획 또는 로드맵을 개발해야 합니다. 이 계획에는 버전 5.x에서 버전 7.0으로 마이그레이션하는 데 필요한 모든 추가 코어 그룹 관련 단계와 다음 질문에 대한 답이 포함되어야 합니다.
- 새 코어 그룹을 작성할 시기는 언제입니까?
- 새 코어 그룹을 작성할 최상의 시기는 배치 관리자 마이그레이션이 완료된 직후입니다. 새 코어 그룹 작성 시 이전에 언급한 사용자 정의 특성을 구성해야 합니다. 관리 콘솔을 사용하거나 createCoreGroup wsadmin 명령을 사용하여 새 코어 그룹을 작성할 수 있습니다. 그러나 사용자 정의 특성을 구성하려면 관리 콘솔을 사용해야 합니다.
- 노드를 마이그레이션할 때 수행해야 하는 조치는 무엇입니까?
- 각 노드를 마이그레이션할 때 다음을 수행해야 합니다.
- 코어 그룹 브릿지 인터페이스 중 하나가 될 새 독립형 애플리케이션 서버를 작성하십시오.
- 노드의 모든 프로세스에서 전송 버퍼 크기를 조정하십시오. 이 조치를 수행할 최상의 옵션은 스크립트입니다.
- 노드 에이전트와 독립형 서버의 힙 크기를 조정하고 해당 프로세스의 상세 GC를 설정하십시오.
- 프로세스를 새 코어 그룹으로 이동하는 시기와 방법은 무엇입니까?
- 기본적으로 마이그레이션 프로세스에서는 모든 프로세스를 DefaultCoreGroup이라는
코어 그룹에 배치합니다. 이 코어 그룹에 포함된 멤버 수가
크기 한계를 초과하는 시점이 되면 프로세스를 다른 코어 그룹에
재분배해야 합니다. 프로세스를 이동하기 전에 프로세스를
중지해야 하는 점을 유념하십시오. 지속적인 애플리케이션 가용성이
필요한 경우 프로세스를 다른 코어 그룹으로 이동할 순서를
주의 깊게 계획해야 합니다.
관리 콘솔 또는 moveServerToCoreGroup wsadmin 명령을 사용하여 배치 관리자, 노드 에이전트, 독립형 애플리케이션 서버를 이동할 수 있습니다.
클러스터된 애플리케이션 서버를 이동하는 것은 더 복잡합니다. 일반적인 상황에서는 관리 콘솔 또는 moveServerToCoreGroup wsadmin 명령을 사용하여 클러스터를 이동할 수 있습니다. 그러나 마이그레이션 프로세스 중에는 이동할 클러스터에 버전 7.0 멤버와 버전 5.x 멤버가 모두 있고 버전 5.x 클러스터 멤버는 아직 코어 그룹의 멤버가 아니므로 일반 명령은 실패합니다. 혼합 클러스터를 새 코어 그룹으로 이동하려면 moveClusterToCoreGroup wsadmin 명령을 선택적 checkConfig 매개변수와 함께 사용해야 합니다.
예를 들어, 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가 포함된 노드가 마이그레이션되는 경우 마이그레이션에서 해당 클러스터 멤버를 DefaultCoreGroup 대신 CG1에 배치합니다. 그러므로 moveClusterToCoreGroup 명령을 클러스터마다 한 번만 실행해야 합니다.
- 코어 그룹 브릿지를 구성해야 하는 시기는 언제입니까?
- 프로세스를 여러 코어 그룹으로 이동할 때 코어 그룹 브릿지가 구성되어 실행 중이어야 합니다. 이는 버전 7.0 대상 토폴로지에서 브릿지 인터페이스로 사용하려는 프로세스가 버전 5.x 노드에서 마이그레이션되지 않아 초기에 이들 프로세스가 필요할 때 이를 사용할 수 없을 수도 있음을 의미합니다. 따라서 애플리케이션의 지속적인 가용성을 보장하려면 마이그레이션이 계속되는 동안 임시 브릿지 인터페이스로 사용할 일부 클러스터된 애플리케이션 서버를 구성해야 합니다. 모든 프로세스가 버전 7.0으로 마이그레이션된 후에는 원하는 버전 7.0 토폴로지와 일치하도록 코어 그룹 브릿지 구성을 조정할 수 있습니다.
기타 계획 고려사항
대상 버전 7.0 구성에 여러 코어 그룹 브릿지가 필요한 경우 IBM_CS_WIRE_FORMAT_VERSION 코어 그룹 사용자 정의 특성을 사용하여 스케일링 향상을 구현하십시오.
또한 모든 코어 그룹이 브릿지로 연결되고 서로 공유 정보를 라우팅하는 경우 코어 그룹 멤버 간에 공유되는 데이터의 양이 보통의 경우보다 훨씬 많아질 수 있습니다. 따라서 보다 효율적으로 데이터를 전송하려면 다음 설정을 사용하여 코어 그룹 메모리 설정을 늘려야 합니다.
- IBM_CS_DATASTACK_MEG를 100으로 설정하십시오.
- 모든 프로세스의 전송 버퍼 크기를 100으로 설정하십시오.
조정자로 사용 중인 독립형 서버, 브릿지 인터페이스로 사용 중인 애플리케이션 서버 또는 노드 에이전트의 JVM 힙 크기와 같은 요소를 조정할 수도 있습니다. 힙 크기를 512MB 늘리는 것으로 시작할 것을 권장합니다. 또한 시간 경과에 따라 이 힙 크기를 세밀하게 튜닝할 수 있도록 해당 프로세스의 상세 GC 모니터링을 설정할 수 있습니다.
가능한 마이그레이션 플로우
마이그레이션을 완료하기 위해 구현할 수 있는 여러 마이그레이션 플로우가 있습니다. 다음 플로우에서는 배치 관리자 마이그레이션이 완료되고 코어 그룹이 작성되었으나 추가 조치는 수행되지 않는 공통적인 시작점을 가정합니다.
- 마이그레이션 플로우 1
- 이 플로우에서는 다음 규칙을 엄격하게 준수합니다. 이 플로우는 여러 가지
이유로 만족스럽지 않습니다. 각 노드가 마이그레이션될 때 클러스터를 이동해야
합니다. 이를 수행하려면 모든 클러스터 멤버를 중지해야 합니다. 이로 인해 애플리케이션을
사용하지 못할 수 있습니다. 또한 각 단계에서 브릿지를 재구성해야
합니다.
- Node1을 마이그레이션하십시오. DefaultCoreGroup에 배치 관리자와 Node1의 모든 프로세스가 포함되어 있습니다. DefaultCoreGroup에 50개 미만의 멤버가 있으므로 추가 조치는 필요하지 않습니다.
- Node2를 마이그레이션하십시오. 이제 DefaultCoreGroup에 권장되는 수보다 많은 프로세스가 있습니다. Node2의 노드 에이전트와 클러스터의 반을 CoreGroup2로 이동하여 2개의 코어 그룹에서 프로세스의 균형을 맞추십시오. 이제 여러 개의 코어 그룹을 사용 중이므로 코어 그룹 브릿지를 구성해야 합니다. Node1과 Node2 노드에 브릿지 인터페이스 서버를 작성하십시오. 두 개의 코어 그룹을 브릿지로 연결하도록 코어 그룹 브릿지를 구성하십시오.
- Node3을 마이그레이션하십시오. DefaultCoreGroup과 CoreGroup2의 클러스터 일부를 CoreGroup3으로 이동하여 3개의 코어 그룹에서 프로세스 균형을 맞추십시오. Node3의 노드 에이전트를 CoreGroup3으로 이동하십시오. Node3에서 브릿지 인터페이스 서버를 작성하십시오. 3개의 코어 그룹을 모두 브릿지로 연결하도록 코어 그룹 브릿지를 재구성하십시오.
- 마이그레이션이 완료될 때까지 계속 노드를 마이그레이션하십시오. 각 노드를 마이그레이션할 때 코어 그룹 브릿지를 일부 다시 균형 조정하고 재구성해야 할 수도 있습니다.
- 마이그레이션 플로우 2
- 이 플로우에서는 임시로 규칙을 변경합니다. 다른 코어 그룹으로 이동하기 위해
실행 중인 애플리케이션 서버를 중지할 필요가 없으므로 이 플로우에서 더 좋은
결과를 얻을 수 있습니다. 마이그레이션이 진행되는 동안 일부 코어
그룹에는 일정 기간 동안 관리 프로세스가 없습니다. 이는 엄밀히
말하면 규칙 위반이지만 마이그레이션이 진행되는 동안
코어 그룹 구성이 변경되지 않는 한 허용됩니다.
- Node1을 마이그레이션하십시오. Node1에는 Cluster10을 제외한 모든 클러스터의 멤버가 있습니다.
- 모든 가능한 클러스터를 최종 대상 토폴로지에서 식별된 코어 그룹으로 이동하십시오. 배치 관리자, Node1의 노드 에이전트, Cluster1은 이미 DefaultCoreGroup에 있으므로 이에 대한 추가 조치는 필요 없습니다. Cluster2를 CoreGroup2로, Cluster3을 CoreGroup3으로 이동하는 식으로 계속 이동하십시오. Node1의 브릿지 서버를 작성하여 CoreGroup2에 배치하십시오.
- 8개의 모든 코어 그룹을 브릿지로 연결하도록 코어 그룹 브릿지를 구성하십시오. 간단히 작업할 수 있도록 각 액세스 지점에서 사용할 단일 브릿지 인터페이스를 임시로 구성합니다. (이렇게 하면 마이그레이션이 진행되는 동안 SPOF(Single Point of Failure)가 생성됩니다.) 최종 토폴로지의 대부분의 브릿지 인터페이스는 여전히 버전 5.x에 있으므로 8개 중 6개의 코어 그룹에서 애플리케이션 서버를 임시 브릿지 인터페이스로 사용해야 합니다. 이를 위해서는 선택된 애플리케이션 서버의 힙 크기를 임시로 늘려야 할 수도 있습니다.
- Node2를 마이그레이션하십시오. 마이그레이션하면 Node2의 클러스터된 애플리케이션 서버가 자동으로 올바른 코어 그룹으로 이동됩니다. Cluster10의 Node1에는 애플리케이션 서버가 없으므로 수동으로 Cluster10을 CoreGroup8로 이동하십시오. Node2의 노드 에이전트를 CoreGroup2로 이동하십시오. Node2에 브릿지 서버를 작성하십시오. 선택적으로 두 개의 노드에 로드를 분산시킬 수 있게 임시 브릿지 인터페이스 서버의 일부가 Node2에 있도록 코어 그룹 브릿지를 재구성하십시오.
- 모든 노드가 마이그레이션될 때까지 동일한 패턴을 사용하여 노드를 계속 마이그레이션하십시오.
- 모든 노드가 마이그레이션되면 기본 조정자 서버를 구성하십시오. 최종 대상 토폴로지와 일치하도록 브릿지 인터페이스를 재구성하십시오(각 액세스 지점에 2개의 브릿지 인터페이스 서버). 임시 브릿지 인터페이스의 기능을 수행하는 서버를 중지한 후 다시 시작하십시오. 새 브릿지 인터페이스 서버를 다시 시작하십시오.
- 마이그레이션 플로우 3
- 이 플로우는 플로우 2의 변형입니다. 즉, 이 플로우는 플로우 2를
약간 변경한 것입니다. 이 플로우의 장점은 1개 대신 3개의 노드에 초기
브릿지 로드가 분산되는 점입니다. 단점은 초기에 코어 그룹에 클러스터를
재분배하는 작업이 Node3 마이그레이션 이후에 발생한다는 점입니다. 이로 인해
이동이 발생하려면 Node1과 Node2 노드에서 실행 중인 서버를 중지해야
합니다. 이는 애플리케이션 가용성에 영향을 미칩니다.
- Node1을 마이그레이션하십시오. 이 단계가 완료되면 DefaultCoreGroup에 38개의 프로세스가 있으며 이는 한계 범위 내의 수입니다.
- Node2를 마이그레이션하십시오. 이 단계가 완료되면 DefaultCoreGroup에 79개의 프로세스가 있습니다. 이 수는 권장 크기보다 크지만 실제 한계 범위 내의 수입니다.
- Node3을 마이그레이션하십시오. 모든 클러스터를 최종 토폴로지에서 식별된 코어 그룹으로 이동하십시오. Cluster2를 CoreGroup2로, Cluster3을 CoreGroup3으로 이동하는 식으로 계속 이동하십시오. 3개의 노드 에이전트를 올바른 코어 그룹으로 이동하십시오. 3개의 브릿지 인터페이스 서버를 작성하여 올바른 코어 그룹으로 이동하십시오.
- 아직 지정된 브릿지 인터페이스가 없는 코어 그룹의 임시 브릿지로 사용될 클러스터된 애플리케이션 서버를 선택하십시오. 이 서버의 힙 크기를 임시로 조정하십시오. 8개의 모든 코어 그룹을 브릿지로 연결하도록 코어 그룹 브릿지를 구성하십시오.
- 모든 노드가 마이그레이션될 때까지 계속 노드를 마이그레이션하십시오.
- 모든 노드가 마이그레이션되면 선호하는 조정자를 구성하십시오. 최종 대상 토폴로지와 일치하도록 브릿지 인터페이스를 재구성하십시오. 필요에 따라 프로세스를 중지한 후 다시 시작하십시오.