SSISO Community

시소당

BEA Weblogic JMS 및 JTA 마이그레이션 프로세스 안내

BEA Weblogic JMS 및 JTA 마이그레이션 프로세스 안내

by Kathiravan Sengodan
2004/05/27

1. 소개

이 문서에서는 WebLogic Server 마이그레이션 과정에 대해 자세히 설명하고 과정의 중요한 각 단계에 대해 스크린 샷과 함께 세부적인 지침을 제공함으로써 수동 마이그레이션 과정을 직접 수행하는 WebLogic Server 관리자를 위한 자습서 역할을 합니다. 또한 WebLogic Server NodeManager의 도움으로 JMX를 사용하여 마이그레이션 과정을 프로그래밍 방식으로 수행하는 방법에 대한 설명과 예제를 제공합니다.
이 문서와 관련된 저자의 파일을 다운로드 하십시오.


2. 범위

이 문서는 JMS 및 JTA 서비스 마이그레이션과 관련된 마이그레이션 과정에 대해 자세히 설명합니다. 다른 서비스의 마이그레이션 과정은 이 문서에서 다루지 않습니다.

3. 용어 및 정의

용어 정의
마이그레이션 가능한 서비스 서비스와 관련된 데이터를 손실하지 않고 하나의 WebLogic Server 인스턴스에서 다른 인스턴스로 마이그레이션할 수 있는 서비스입니다.
대상 다양한 J2EE 하위 시스템 서비스를 호스트하고 컨테이너 역할을 할 수 있는 WebLogic Server의 관리 엔티티입니다.
클러스터 대상 하나의 엔티티처럼 행동하기 위해 클러스터링으로 서로 연결된 하나 이상의 서버입니다. JNDI 등과 같이 공통 리소스를 복제 및 공유함으로써 클러스터 서비스를 제공합니다.
서버 대상 단일 WebLogic Server 인스턴스입니다.
마이그레이션 가능한 대상 지정된 시간에 하나의 서버만 활성화되고, 하나 이상의 후보 서버가 포함된 가상 대상입니다.
후보 서버* 마이그레이션 과정에서 사용자 기본 설정 서버에 대한 대기 서버 역할을 수행할 수 있는 서버 목록입니다.
사용자 기본 설정 서버 배포된 J2EE 서비스를 호스트하고 있는 현재 활성 서버입니다.
소스 서버 서비스를 "마이그레이션하는" 서버 인스턴스입니다.
대상 서버 서비스가 "마이그레이션되는" 서버 인스턴스입니다.
JMS Java Messaging Service
JTA Java Transaction Service
JDBC Java Data Base Connectivity
JMX Java Management eXtensions
SAN Storage Area Network
TLOG 트랜잭션 로그
*마이그레이션 가능한 대상과 동일한 클러스터에 속하도록 제한된 서버 목록입니다.

4. WebLogic Server 마이그레이션 및 관련 인프라스트럭처

JMS 및 JTA Transaction Recovery Service와 같은 특정 WebLogic Server 서비스는 지정된 시간에 특정 클러스터 노드에서 실행되는 서비스의 활성 인스턴스가 하나뿐이라는 가정 하에 설계되었습니다. 이러한 유형의 서비스는 한번에 하나의 서버 인스턴스만 활성 상태로 유지되기 때문에 "고정된" 서비스라고 합니다.

관리자는 WebLogic Server를 사용하여 서버 실패에 대한 조치나 정기적인 유지 관리 작업의 일환으로 이러한 고정된 서비스를 하나의 서버 인스턴스에서 클러스터의 다른 인스턴스로 마이그레이션할 수 있습니다. 이러한 기능은 호스트 서버에 오류가 발생할 경우 중복 서버에서 서비스를 신속하게 재시작할 수 있기 때문에 클러스터에서 고정된 서비스의 가용성을 향상시켜 줍니다.

참고: 현재 WebLogic Server는 고정된 서비스에 대해 자동 마이그레이션(장애 조치)을 지원하지 않습니다. 프로그래밍 방식의 마이그레이션 수행에 대해 문서화되지 않은 방법에 대해서는 본 문서의 5.2.5 단원을 참조하십시오.

현재 마이그레이션은 JMS 서버 및 JTA Transaction Recovery Service에 대해서만 지원됩니다. 이 문서에서는 이러한 서비스를 마이그레이션 가능한 서비스라고 합니다.

JMS 서버는 JTA Transaction Recovery Service와는 별도로 마이그레이션될 수 있습니다. 하지만 JTA Transaction Recovery Service는 다른 하위 시스템 서비스의 트랜잭션을 제어하기 때문에 일반적으로 다른 하위 시스템 서비스와 함께 마이그레이션됩니다. 따라서 하위 시스템 서비스의 마이그레이션 전후에도 트랜잭션 무결성이 유지될 수 있습니다.

WebLogic Server 마이그레이션 인프라스트럭처는 아래의 설명과 같이 다양한 서버 컴포넌트 및 도구로 구성됩니다.

마이그레이션 가능한 대상

기본적으로 WebLogic Server는 JTA Transaction Recovery Service 또는 JMS 서버를 동일한 클러스터 내의 다른 WebLogic Server 인스턴스로 마이그레이션할 수 있습니다. 고정된 서비스를 잠재적으로 호스트할 수 있는 서버 목록을 클러스터에 선택적으로 구성할 수 있습니다. 이 서버 목록을 마이그레이션 가능한 대상이라고 하며, 이 목록은 서비스를 마이그레이션할 수 있는 대상 서버를 제어합니다.

클러스터에 마이그레이션 가능한 대상 서버 정의
예를 들어, 다음 그림은 클러스터가 두 개인 WebLogic Server 도메인 구성을 보여줍니다. 클러스터 1에는 WebLogic Server 인스턴스 MS1, MS2 및 MS3이 구성되어 있습니다. 클러스터 2에는 WebLogic Server 인스턴스 MS4, MS5, MS6 및 MS7이 구성되어 있습니다. ManagedServer1(MS1)에는 마이그레이션 후보 서버로 ManagedServer2(MS2)가 있고, ManagedServer2(MS2)에는 마이그레이션 후보 서버로 ManagedServer1(MS1)이 있습니다.

1
그림 1. 일반적인 WebLogic 도메인 구성

위 예제에서 관리자는 고정된 JMS 서버가 마이그레이션 가능한 대상인 ManagedServer1(MS1) 또는 ManagedServer2(MS2)에 배포되는 경우 고정된 JMS 서버를 마이그레이션할 수 있습니다. 예를 들어 관리자가 JMSServer의 마이그레이션을 수행하려는 경우, 관리자는 JMSServer의 대상을 "ManagedServer1(migratable)" 또는 "ManagedServer2(migratable)"로 지정해야 합니다.

WebLogic Server를 사용하면 JTA Transaction Recovery Service 및 JMS 서버에 대해 개별적으로 마이그레이션 가능한 대상을 만들 수 있습니다. 이렇게 하면 필요한 경우 각 서비스가 클러스터의 서로 다른 WebLogic Server 인스턴스에서 항상 실행되도록 할 수 있습니다. 반대로, 서비스가 클러스터의 동일한 서버에 함께 배치되도록 하려면 JTA 및 JMS 쌍방에 대해 마이그레이션 가능한 대상으로 동일한 서버를 구성할 수 있습니다.

마이그레이션 도구
WebLogic Server는 이러한 서비스의 수동 마이그레이션만 수행할 수 있는 인프라스트럭처와 기능을 제공합니다. 즉, WebLogic 관리자가 서비스를 한 서버 인스턴스에서 다른 서버 인스턴스로 성공적으로 마이그레이션하려면 과정을 수동으로 실행해야 합니다.

관리자는 WebLogic Administration Console이나 명령줄 인터페이스 유틸리티를 사용하여 마이그레이션 과정을 수행할 수 있습니다. 이에 대해서는 이 자습서의 후반부에서 설명합니다.

4.1 마이그레이션 사전 요구 사항

WebLogic Server에는 서비스 마이그레이션을 지원하기 위해 하위 시스템 구성과 관련된 특정 제약 조건과 선행 조건이 있습니다. 이러한 제약 조건은 하위 시스템별로 다르며 고객의 엔터프라이즈 애플리케이션 아키텍처에 따라서도 달라집니다.

4.1.1 WebLogic Server 수준 선행 조건

마이그레이션 가능한 대상의 제한된 후보 서버는 모두 동일한 클러스터에 속해야 합니다.

4.1.2 JMS 하위 시스템 수준 선행 조건

JMS 저장소는 소스 서버 및 대상 서버가 모두 액세스할 수 있도록 구성해야 합니다. 애플리케이션이 JDBC 기반 저장소(JMSJDBCStore)를 사용하는 경우, DataSource 및 ConnectionPool과 같이 해당 데이터베이스 인스턴스에 대한 JDBC 연결 정보를 양쪽 서버에서 사용할 수 있어야 합니다.

애플리케이션이 파일 기반 저장소(JMSFileStore)를 사용하는 경우에는 SAN(Storage Area Network) 또는 듀얼 포트 SCSI 디스크를 사용하는 것이 좋습니다.

4.1.3 JTA 하위 시스템 수준 선행 조건

JMS 저장소와 마찬가지로 JTA TLOG 파일은 마이그레이션 과정에 관련된 소스 서버 및 대상 서버 양쪽에서 액세스할 수 있도록 구성해야 합니다.

경고: JTA Transaction Recovery Service는 소스 서버 인스턴스가 다운된 경우에만 마이그레이션될 수 있습니다.

4.1.4 서버의 실행 상태 및 마이그레이션 지원

1
표 2. 서버 상태 및 마이그레이션

4.2 마이그레이션 사후 절차

4.2.1 현재 활성 호스트를 사용할 수 없는 경우의 마이그레이션

손상되었거나 관리 서버에서 사용할 수 없는 서버 인스턴스에서 서비스를 마이그레이션할 경우에는 특별히 고려해야 할 사항이 있습니다. 마이그레이션을 수행할 때 관리 서버가 이전의 활성 서비스 호스트에 연결할 수 없으면 관리 서버의 로컬 구성 정보는 해당 호스트가 더 이상 서비스의 활성 호스트가 아니라는 사실을 반영하기 위해 업데이트되지 않습니다. 이 경우 다시 시작하기 전에 연결할 수 없는 관리 서버의 로컬 구성 캐시를 삭제해야 합니다. 그러면 시작 시 이미 다른 관리 서버로 마이그레이션된 서비스를 이전의 활성 호스트가 다시 활성화하지 않도록 할 수 있습니다.

자세한 내용은 http://e-docs.bea.com/wls/docs81/cluster/setup.html에서 "현재 활성 호스트를 사용할 수 없는 경우의 마이그레이션"을 참조하십시오.

5. 마이그레이션 과정 자습서

이 단원에서는 실제 마이그레이션 과정을 단계별로 설명하면서 과정 도중 사용되는 다양한 유틸리티 및 도구에 대한 스크린 샷도 함께 제공합니다. 이 과정은 Windows 2000에 설치된 WebLogic Server 릴리스 7.0(서비스 팩 5)을 사용하여 설명합니다. WebLogic Server 릴리스 8.1에 대해서도 이와 동일한 과정을 적용할 수 있습니다. 이 단원의 내용은 Windows 환경에 익숙한 사용자 위주로 설명되어 있습니다. 또한 마이그레이션 과정은 2 노드 클러스터와 전용 관리 서버가 있는 간단한 WebLogic Server 도메인을 중심으로 설명합니다. WebLogic Server 인스턴스의 이름은 "ManagedServer1"과 "ManagedServer2"입니다.

전체 마이그레이션 과정은 아래와 같이 논리적 활동 그룹에 따라 5개 부분으로 나눠서 설명됩니다.

1부. 마이그레이션 가능한 대상 구성
2부. 마이그레이션 과정과 관련된 JMS 구성
3부. WebLogic Administration Console을 사용한 마이그레이션 과정
4부. 명령줄 유틸리티를 사용한 마이그레이션 과정
5부. JMX를 사용한 프로그래밍 방식의 마이그레이션 과정

5.1 1부. 마이그레이션 가능한 대상 구성

이 단계는 전체 서비스 마이그레이션 과정 중에서 첫 번째의 주요 단계로서 매우 중요합니다. 관리자는 WebLogic Server 인스턴스를 만든 후, JMS 서버의 대상을 지정하거나 JTA Transaction Recovery Service 마이그레이션을 활성화하기 전 아무 때나 이 단계를 수행해야 합니다.

WebLogic 도메인의 모든 WebLogic Server 인스턴스는 기본적으로 마이그레이션 가능한 대상으로 취급됩니다. 이 문서의 처음에서 정의한 바와 같이 마이그레이션 가능한 대상이란 하나 이상의 후보 서버가 있고 이 중 하나는 활성 서버로 취급되는 가상 대상을 말합니다.

기본적으로, 모든 물리적 Weblogic Server 인스턴스가 생성되어 "X"로 이름이 지정되었다면, 두 개의 구성 엔티티도 함께 생성되며 이름도 "X(migratable)"로 지정됩니다. 이러한 두 개의 구성 엔티티에는 활성(사용자 기본 설정) 서버와 동일한 서버 인스턴스 "X"가 포함되며 "후보 서버"는 포함되지 않습니다.

마이그레이션 가능한 "X(migratable)" 중 하나의 인스턴스는 구성 계층에서 WebLogic Server 인스턴스와 동일하게 취급됩니다. 이 인스턴스는 WebLogic Server 인스턴스(도메인이 부모가 됨)와 동일한 수준을 유지하며, JMS 서버의 대상을 지정하는 데에도 사용됩니다. 또한 이러한 마이그레이션 가능한 인스턴스 중 나머지 인스턴스는 서버 인스턴스의 요소로 취급되며(따라서 WebLogic Server 인스턴스가 부모가 됨), JTA 마이그레이션을 활성화하는 데 사용됩니다. 따라서 마이그레이션 가능한 대상을 구성하는 작업은 단순히 선택한 WebLogic Server 인스턴스에 후보 서버 목록을 추가하는 것을 의미합니다. 다른 관리 작업과 마찬가지로 이 단계에서도 관리 콘솔을 사용합니다.

WebLogic Server 인스턴스인 JMS 마이그레이션 가능한 대상에 후보 서버를 추가하려면 그림 1과 같이 해당 서버의 Control 탭으로 이동해야 합니다.

1
그림 1. Managed Server1 Control 탭

참고: WebLogic Server Administration Console이 관리 서버(여기에서는 AdminServer)에 연결된 경우, 도메인의 다른 모든 서버 인스턴스가 실행 상태인지 여부에 상관 없이 전체 도메인 정보를 관리할 수 있습니다.

5.1.1 JMS 마이그레이션 가능한 대상 구성

이 문서의 예제에는 동일한 클러스터에 속하는 WebLogic Server 인스턴스가 두 개 있습니다. 이 두 ManagedServer1과 ManagedServer2는 서로에 대해 후보 서버가 될 수 있습니다.

"ManagedServer1(migratable target)"에 후보 서버를 추가하려면 그림 2에서와 같이 ManagedServer1의 Migration Config 탭으로 이동해야 합니다.

1
그림 2. ManagedServer1 - Control->Migration Config(JMS용)

그림에서 알 수 있듯이 사용 가능한 모든 WebLogic Server 인스턴스 이름이 Available 제목 아래에 표시되고 후보 서버는 Chosen 제목 아래에 표시됩니다. 이 예에서는 아직 아무것도 선택하지 않았기 때문에 Chosen 목록이 비어 있습니다.

다음 단계로, WebLogic Server 인스턴스의 Available 목록에서 후보 서버를 선택합니다. 이렇게 하려면 왼쪽에서 서버 이름(여기에서는 ManagedServer1 및 ManagedServer2)을 선택(강조 표시)하고 오른쪽 화살표 단추를 클릭합니다. 콘솔 화면이 그림 3과 같이 표시됩니다.

1
그림 3. ManagedServer1 - Control->Migration Config(JMS용)

이때, Chosen 후보 서버 목록에서 WebLogic Server 인스턴스를 제거하려면 원하는 서버 이름을 강조 표시하고 왼쪽 화살표 단추를 클릭하면 됩니다.

후보 서버를 결정했으면 Apply 단추를 클릭하여 "ManagedServer1(migratable)"의 후보 목록을 만듭니다. 그러면 ManagedServer1의 마이그레이션 가능한 대상이 유효한 후보 서버 목록과 함께 생성되고 마이그레이션 가능한 서비스의 호스트 역할을 수행할 준비가 됩니다.

참고: "ManagedServer1(migratable)"라는 이름이 의미하는 것과는 달리, ManagedServer1과 ManagedServer2가 모두 후보 서버로 설정되어 있습니다. 마이그레이션을 효율적으로 수행하려면 후보 서버 목록에 최소한 두 개 이상의 WebLogic Server 인스턴스가 있어야 합니다.

5.1.2 JTA 마이그레이션 가능한 대상 구성

지정된 WebLogic Server 인스턴스에 대해 JTA 마이그레이션을 활성화하려면 마이그레이션 가능한 대상에 후보 서버를 추가해야 합니다. JTA Migration Config 탭/페이지에서 이러한 작업을 수행할 수 있습니다. 이 과정은 5.1.1 단원에서 이미 설명한 JMS 마이그레이션 가능한 대상 구성과 비슷합니다.

이 단계에서 사용된 config.xml 파일은 부록 1에서 제공됩니다.

5.2 2부. JMS 하위 시스템 구성

5.2.1 JMS 저장소 구성

4.1.2 단원과 4.1.3 단원에서 설명한 바와 같이 마이그레이션을 지원하기 위해 JMS 영구 저장소 구성에 적용되는 특수한 요구 사항이 있습니다. 요구 사항이란 마이그레이션 가능한 대상의 모든 후보 서버가 해당 저장소에 액세스할 수 있도록 이 저장소를 구성해야 한다는 것입니다.

이 자습서에서는 JMSFileStore가 영구 메시징에 사용되므로 파일 저장소 디렉토리는 그림 4와 같이 c:\myfilestore에 MyJMSFileStore라는 이름으로 공유 디스크 드라이브에 생성됩니다.

1
그림 4. JMS 파일 저장소 구성

참고: 실제 제작 환경에서는 뛰어난 신뢰성 및 성능을 제공할 수 있는 SAN 기반 디스크 어레이 또는 듀얼 포트 SCSI 디스크를 사용하는 것이 좋습니다.

5.2.2 JMS 서버 구성

앞에서도 언급한 바와 같이 JMSServer를 마이그레이션에 참여할 수 있도록 구성해야 합니다. 두 가지 중요한 구성 단계는 "저장소 선택"과 "대상 지정"입니다.

5.2.2.1 JMS 서버용 저장소 선택

JMSServer가 영구 메시징 및/또는 메시지 페이징을 지원하도록 구성된 경우 5.2.1 단원에서 언급한 대로 "JMS 서버 마이그레이션"을 지원하도록 특별히 구성된 저장소를 선택해야 합니다. 따라서 이 자습서에서 MyJMSServerMyJMSFileStore를 영구 저장소로 사용하도록 구성되어 있으며, 이 저장소는 그림 5와 같이 공유 디스크에 있습니다.

1
그림 5. JMSServer 구성 및 JMSFileStore와 연결

마이그레이션하기 위한 JMSServer 구성의 두 번째 단계는 "대상 지정"입니다. JMSServer는 WebLogic Server 인스턴스나 마이그레이션 가능한 대상으로 지정될 수 있는 배포 가능한 엔티티입니다. 마이그레이션 가능한 대상의 현재 활성 서버가 마이그레이션되는 경우, "마이그레이션 가능한 대상"으로 지정된 JMSServer만 대상 서버로 마이그레이션됩니다. 마이그레이션 가능한 대상을 지정하려면 Targets 탭과 Migratable Target 탭을 차례로 클릭한 다음, 그림 6과 같이 드롭다운 목록에서 항목을 선택해야 합니다.

1
그림 6. 사용할 수 있는 마이그레이션 가능한 대상 목록

이 자습서에서는 그림 7과 같이 마이그레이션 가능한 대상인 ManagedServer1(migratable)이 JMSServer MyJMSServer에 대한 배포 대상으로 선택됩니다.

1
그림 7. 마이그레이션 가능한 대상 선택

5.3 3부. Administration Console을 사용한 마이그레이션 과정

5.3.1 JMS 마이그레이션 과정

앞에서 설명한 바와 같이 수동 마이그레이션 과정은 관리 콘솔이나 명령줄 유틸리티를 사용하여 수행할 수 있습니다.

표 2에서와 같이 소스 서버나 대상 서버가 실행 상태에 있지 않아도 JMS 마이그레이션 과정을 실행할 수 있습니다. 따라서 예제에서는 "관리 서버"만 실행 상태이며, 소스 서버(ManagedServer1) 및 대상 서버(ManagedServer2)는 실행 상태가 아닙니다.

아래의 그림 8과 같이 소스 서버(ManagedServer1)의 Control Migrate 탭으로 이동하십시오.

1
그림 8. ManagedServer1 - Migrate 탭(JMS용)

이제 Destination Server 목록 상자를 클릭하여, 가능한 모든 대상 서버를 확인할 수 있습니다. 후보 서버로 구성된 서버는 단지 두 개뿐이므로, 지정된 시간 중에는 항상 한 서버는 Current Server로 취급되고 나머지 다른 서버는 Destination Server로 취급됩니다.

"Migrate" 단추를 클릭하면 마이그레이션 과정이 시작되고 그림 9와 같이 상태 화면에 진행 상태가 표시됩니다.

1
그림 9. JMS 마이그레이션 진행 중

JMS 마이그레이션 과정 도중 서버는 대상 서버의 상태가 실행 중인지를 확인합니다. 이 경우와 같이 대상 서버가 "실행 중이 아닌" 상태라면, 그림 10과 같이 이러한 상황을 알리는 경고 메시지가 표시됩니다.

1
그림 10. 대상 서버가 다운되었을 때의 경고 메시지

이때, "Continue" 단추를 클릭하면 마이그레이션 과정을 계속할 수 있습니다. 그림 11에서 13은 JMS 서버 마이그레이션 과정의 여러 단계를 보여줍니다.

1
그림 11. 대상 서버가 다운되었을 때의 경고 메시지

1
그림 12. 마이그레이션 상태 - 진행 중

1
그림 13. JMS 마이그레이션 상태 - 완료

5.3.2 JTA 복구 서비스 마이그레이션 과정

소스 서버가 다운되었거나 대상 서버가 가동 중인 경우 JTA 마이그레이션에 콘솔을 사용하십시오. 이 과정은 JMS 서버 마이그레이션 과정과 비슷하며 그림 14에서 18과 같이 나타납니다.

1
그림 14. JTA 마이그레이션용 ManagedServer1 - Control 탭

1
그림 15. JTA 마이그레이션 진행 중

1
그림 16. 소스 서버가 다운되었음을 알리는 경고

1
그림 17. JTA 마이그레이션 진행 중

1
그림 18. JTA 마이그레이션 완료

5.4 4부. 명령줄 유틸리티를 사용한 마이그레이션 과정

관리 콘솔 외에 WebLogic Server는 관리 작업을 수행할 수 있는 명령줄 인터페이스를 제공합니다. 이 유틸리티의 이름은 weblogic.Admin이며, 이 유틸리티를 호출하는 일반적인 명령줄 구문은 다음과 같습니다.

구문
java weblogic.Admin [-url URL] -username username
[-password password] COMMAND arguments

인수
여러 WebLogic Server 명령에서 다음과 같은 인수가 필요합니다.

인수 정의
URL 다음 중 하나를 지정하십시오.
도메인의 관리 서버에 대한 수신 주소. 이 주소는 관리 서버의 보안 컨텍스트 내에서 명령을 실행하기 때문에 대부분의 경우 이 URL을 사용하는 것이 좋습니다.
명령의 대상인 WebLogic Server의 수신 주소. 관리 서버에 액세스할 수 없는 상태에서 관리되는 서버를 대상으로 지정할 경우에는 이 URL을 사용하십시오..
형식은 hostname:port입니다. 기본값은 localhost:7001입니다.
참고: 관리 포트를 지정하려면 Creating and Configuring WebLogic Server Domains guide(WebLogic Server 도메인 생성 및 구성 안내서)의 "도메인 전체의 관리 포트 구성"에 설명된 대로, 시스템 관리자가 도메인의 모든 서버 인스턴스에 대해 관리 포트를 설정했는지 확인해야 합니다.
Username -URL 인수에 지정한 서버에서 요청을 완료하는 데 필요한 권한이 있는 사용자 이름입니다.
시스템 관리 작업의 권한에 대한 내용은 시스템 관리 작업 보호를 참조하십시오.
Password 사용자 이름과 관련된 암호입니다.
-password 인수를 지정하지 않으면 weblogic.Admin이 암호를 입력하라는 메시지를 표시합니다. PATH 환경 변수에 WL_HOME\server\bin이 지정된 경우 weblogic.Admin은 암호가 표준 출력으로 에코되지 않도록 방지하는 일련의 WebLogic Server 라이브러리를 사용합니다. 환경 변수 설정에 대한 자세한 내용은 Classpath 설정을 참조하십시오.
COMMAND WebLogic Administration 명령의 이름. 뒤에 적합한 인수가 나옵니다. 사용자가 마이그레이션 작업을 수행할 수 있는 "MIGRATE"도 이러한 명령 중 하나로, 이에 대해서는 아래에서 설명합니다.
arguments 실행 중에 COMMAND의 동작을 제어하는 인수입니다.


참고: 관리 클라이언트가 서버에 연결할 수 없는 경우 모든 명령의 종료 코드는 "1"입니다.

표 2. WebLogic Admin 명령줄 파라미터 정의

MIGRATE 명령과 인수에 대한 자세한 설명은 다음과 같습니다.
MIGRATE
- JMS 서비스 및/또는 JTA Transaction Recovery Service를 서버 클러스터 내의 대상 서버로 마이그레이션합니다.
구문
java weblogic.Admin [-url URL] \
-username username \
-password password \
MIGRATE -jta \
-migratabletarget (migratabletarget_name|servername) \
-destination servername \
[-sourcedown] \
[-destinationdown]

인수 정의
-jta 마이그레이션이 JTA 서비스의 마이그레이션임을 지정합니다.
-migratabletarget 서비스가 마이그레이션할 소스 서버를 식별하는 구성 파일의 이름을 지정합니다. 각 서버에 대해 WebLogic Server는 마이그레이션 가능한 대상을 자동으로 만듭니다. 대상 이름은 JTA용 JMSServername의 경우 "(servername)_migratable"로 지정됩니다.
이 마이그레이션 가능한 대상은 JMS 서비스 및 JTA Transaction Recovery Service에 대한 기본 설정 서버를 지정하는 구성 엔티티입니다.
-destination 서비스가 마이그레이션될 대상 서버의 이름입니다.
-sourcedown 소스 서버를 다운 상태로 지정합니다.
경고: 이 스위치는 아주 조심해서 사용해야 합니다. 소스 서버가 실제로는 다운이 아니지만 네트워크 문제로 인해 단지 사용할 수 없는 상태인 경우, 서비스는 소스 서버에서 제거되지 않은 채 대상 서버에서 활성화되기 때문에 동일 서비스에 대해 동시에 두 개의 버전이 실행되게 됩니다. 이렇게 되면 트랜잭션 로그나 JMS 메시지가 손상될 수 있습니다.
-destinationdown 대상 서버를 다운 상태로 지정합니다. 실행 중이 아닌 서버로 마이그레이션된 JMS 서비스는 손실됩니다. 실행 중이 아닌 서버로 JTA Transaction Recovery Service를 마이그레이션하면, 대상 서버는 실행 중이 아닌 서버가 시작될 때 복구 서비스로 취급합니다.


표 3. WebLogic Admin MIGRATE 명령 파라미터 정의

예제
다음 예제에서 JMS 서비스는 myserver2에서 myserver3으로 마이그레이션됩니다.


java weblogic.Admin \
-url AdminHost:7001 \
-username adminuser \
-password adminpassword \
MIGRATE \
-migratabletarget myserver2(migratable) \
-destination myserver3



다음 예제에서는 JTA Transaction Recovery Service가 JMS 서비스와 함께(있을 경우) myserver2에서 myserver3으로 마이그레이션됩니다.


java weblogic.Admin \
-url AdminHost:7001 \
-username adminuser \
-password adminpassword \
MIGRATE -jta \
-migratabletarget myserver2(migratable) \
-destination myserver3 \
-sourcedown


5.4.1 JMS 마이그레이션 과정

명령줄 마이그레이션 과정의 첫 번째 단계는 환경을 설정하는 것입니다. 이 작업은 아래와 같이 구성 마법사에서 생성되는 "setenv.cmd" 스크립트를 사용하여 수행할 수 있습니다.


C:\wls700sp5\user_projects\mydomain>setenv.cmd


환경을 설정한 다음에는 아래와 같이 JMS 마이그레이션에 대해 명령줄 유틸리티를 호출할 수 있습니다. 이때, 마이그레이션하려는 JMSServer는 마이그레이션 가능한 대상인 "ManagedServer1(migratable)"의 일부인 "ManagedServer2" 서버에서 이미 실행 중인 것으로 간주한다는 점을 유의하십시오.


C:\wls700sp5\user_projects\mydomain>java weblogic.Admin -url t3://localhost:9001 -username wls_admin 
-password wls_admin MIGRATE -migratabletarget "ManagedServer1 (migratable)" -destination ManagedServer1 
-destinationdown


JMSServer를 ManagedServer2에서 ManagedServer1로 성공적으로 마이그레이션하면 다음 메시지가 표시됩니다.


Started attempt to migrate service(s) for ManagedServer1 (migratable) to destination server ManagedServer1 …"
Migration succeeded.
Ok


5.5 5부. JMX를 사용한 프로그래밍 방식의 마이그레이션 과정

면책: 이 과정은 어디에도 문서화되어 있지 않으며 어떠한 지원이나 보증도 제공되지 않습니다. 여기에 설명된 솔루션의 완성도 및/또는 정확성에 대해 저자 또는 BEA는 어떠한 책임도 지지 않습니다. 여기에 설명된 과정에서는 잘못된 시나리오를 감지하고 JMS 및 JTA 하위 시스템 서비스의 마이그레이션을 프로그래밍 방식으로 수행하는 데 사용할 수 있는 기술을 보여줍니다. 또한 이 과정은 향후 WebLogic Server 릴리스에서 변경될 수 있습니다.

일부 경우에 사용자는 실패 감지 시 하나의 클러스터 노드에서 다른 노드로 JMS 서비스에 대한 자동 장애 조치(마이그레이션)를 수행하기를 원할 수 있습니다. 그러면 마이그레이션 과정에서 관리자가 수동으로 개입할 수 있는 여지가 크게 줄어듭니다.

수동 마이그레이션 과정과 마찬가지로 프로그래밍 방식의 마이그레이션 과정에도 몇 가지 선행 조건이 있습니다.

(자동) 프로그래밍 방식의 마이그레이션 과정의 첫 번째 단계이자 선행 조건은 JMSServer 런타임 상태를 확인하여 JMS 하위 시스템의 실패를 발견하는 것입니다.

두 번째 단계는 서버 라이프사이클 하위 시스템 절차와 함께 WebLogic NodeManager를 사용하여 후보(소스 및/또는 대상) 서버를 프로그래밍 방식으로 시작하고 종료하는 방법을 갖는 것입니다. NodeManager는 WebLogic Server와 관계 없이 실행될 수 있는 독립 실행형 "에이전트" 프로세스입니다. 단일 NodeManager 인스턴스/프로세스를 사용하면 해당 시스템에서 하나 이상의 WebLogic Server 인스턴스를 제어하고 모니터링할 수 있습니다. NodeManager를 시작하기 위한 명령줄 구문은 아래와 같습니다.

1
그림 19. NodeManager 명령줄 구문

JMX를 사용하여 실패 및 마이그레이션을 처리할 JMSServer 상태 찾기

WebLogic Server는 하위 시스템에 대한 다양한 런타임 통계를 포함하는 모든 하위 시스템에 대한 JMX 런타임 MBean을 제공합니다.

JMS 하위 시스템의 런타임 MBean에는 지정된 WebLogic Server 인스턴스의 JMS 하위 시스템에 대한 전반적인 런타임 상태는 물론 총 활성 연결 수, 총 JMS 서버 수와 같은 JMS 하위 시스템에 관한 중요한 통계 정보가 포함되어 있습니다.

마찬가지로, JTA 하위 시스템의 런타임 MBean에는 JTA 하위 시스템의 런타임 상태는 물론 총 활성 트랜잭션 수, 다양한 이유로 인해 롤백된 총 트랜잭션 수와 같은 JTA 하위 시스템에 관한 중요한 통계 정보가 포함되어 있습니다.

사용자는 JMS 및 JTA 하위 시스템의 JMX 런타임 MBean을 사용하여 실패를 감지하고 적합한 조치를 취할 수 있습니다.

이 단원에서는 JMX를 사용하여 JMS 및 JTA 하위 시스템의 런타임 상태를 감지하고 이러한 하위 시스템 서비스를 프로그래밍 방식으로 마이그레이션하여 서버 다운타임을 방지하거나 줄일 수 있는 방법을 예제 코드와 함께 설명합니다.

예제 코드

목록 1. AutomaticMigration.java

이것은 서버 상태를 모니터링하고 상태가 좋지 않을 때 마이그레이션을 수행하는 주요 프로그램입니다.

목록 2. HealthMonitor.java

이 프로그램은 JMX 런타임 MBean을 사용하여 JMS 및 JTA 하위 시스템 상태를 찾아서 보고합니다.

목록 3. MigrationHelper.java

이 프로그램은 JMS 및/또는 JTA 하위 시스템의 실제 마이그레이션 과정을 수행합니다.


//-----------------------------------------------------------------------------//
// Listing 1. AutomaticMigration
//-----------------------------------------------------------------------------//

public class AutomaticMigration 
{
  public static void main(String[] args) {
  
    if (args.length < 8) {
      System.out.println(
       "Usage: AutomaticMigration <admin url><source server> " +
                                  "<username> <password> " +
                                  "<destination server> " +
                                  " <source up><dest up> " +
                                  " <migrate jta>");
      System.exit(1);
    }
    
    String  adminurl                    = args[0];
    String  sourceServerName    = args[1];
    String  username                    = args[2];
    String  password                    = args[3];
    String  destination         = args[4];
    boolean sourceup            = new Boolean(args[5]).booleanValue();
    boolean destup              = new Boolean(args[6]).booleanValue();
    boolean migrateJTA          = new Boolean(args[7]).booleanValue();

    HealthMonitor hm            = null;

    try {
      hm = new HealthMonitor(sourceServerName, /* server name */
                             adminurl,         /* url */
                             username,         /* username */
                             password          /* password */
                            );
    } catch(Exception e) {
      System.out.println("Error creating HealthMonitor, " + e.getMessage());
      System.exit(1);
    }
    while (hm.checkHealth()) {
      try {
        Thread.sleep(5000);
      } catch (InterruptedException ignore) {}
      Thread.yield();
    }
    // prepare for migration
    String mtName = sourceServerName + " (migratable)";
    try {
      MigrationHelper.migrate(adminurl,    /* admin url */
                              username,    /* admin username */
                              password,    /* admin password */
                              mtName,      /* migratable target */
                              destination, /* destination server */
                              sourceup,    /* source server up */
                              destup,      /* destination server up */
                              migrateJTA   /* migrate JTA */
                             );
    } catch (Exception e) {
       e.printStackTrace();
       System.out.println("Migration failed" + e);
    }
   
  }
}    


목록 1. AutomaticMigration.java


//-----------------------------------------------------------------------------//
// Listing 2. HealthMonitor
//-----------------------------------------------------------------------------//

import java.util.Hashtable;
import java.util.Date;

import java.net.URL;
import java.net.HttpURLConnection;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

import javax.management.InstanceNotFoundException;

import weblogic.management.MBeanHome;
import weblogic.management.configuration.ServerMBean;
import weblogic.management.runtime.JMSRuntimeMBean;
import weblogic.management.runtime.JTARuntimeMBean;

import weblogic.health.HealthState;

public class HealthMonitor 
{

  private String         serverName;
  private String         adminurl;
  private String         username;
  private String         password;
  private InitialContext adminIC;  // admin server initial context
  private MBeanHome      adminMH;  // admin server mbean home
  private InitialContext ic;       // managed server mbean home
  private MBeanHome      mh;       // managed server mbean home

  private boolean            debug  = false;
  private ServerMBean        server = null;
  private JTARuntimeMBean    jta    = null;
  private JMSRuntimeMBean    jms    = null;

  public HealthMonitor(
    String serverName,
    String adminurl,
    String username,
    String password
  ) throws Exception {

    this.serverName = serverName;
    this.adminurl   = adminurl;
    this.username   = username;
    this.password   = password;

    try {
      this.ic = getInitialContext(adminurl, username, password);
    } catch(NamingException ne) {
      System.out.println(
        "Cannot get Initial Context with " + adminurl + "\n" + ne);
      throw new Exception(ne.getMessage());
    }
    try {
      this.adminMH = (MBeanHome)ic.lookup(MBeanHome.ADMIN_JNDI_NAME);   
    } catch(NamingException ne) {
      System.out.println("Admin MBean Home could not be found\n" + ne);
      throw new Exception(ne.getMessage());
    }

    try {
      this.server = (ServerMBean) adminMH.getMBean(serverName, "Server");
    } catch(InstanceNotFoundException infe) {
      System.out.println("JMSRuntimeMBean could not be found\n" + infe);
      throw new Exception(infe.getMessage());
    }

    try {
      String managedURL = new String("t3://"+
                                     server.getListenAddress()+":"+
                                     server.getListenPort());
      this.adminIC = getInitialContext(managedURL, username, password);
    } catch(NamingException ne) {
      System.out.println(
        "Cannot get Initial Context with " + adminurl + "\n" + ne);
      throw new Exception(ne.getMessage());
    }

    try {
      mh = (MBeanHome)ic.lookup(MBeanHome.JNDI_NAME+"."+serverName);   
    } catch(NamingException ne) {
      System.out.println("Admin MBean Home could not be found\n" + ne);
      throw new Exception(ne.getMessage());
    }

    try {
      jms = (JMSRuntimeMBean) mh.getRuntimeMBean(serverName+".jms", "JMSRuntime");
    } catch(InstanceNotFoundException infe) {
      System.out.println("JMSRuntimeMBean could not be found\n" + infe);
      throw new Exception(infe.getMessage());
    }
    try {
      jta = (JTARuntimeMBean) mh.getRuntimeMBean("JTARuntime", "JTARuntime");
    } catch(InstanceNotFoundException infe) {
      System.out.println("JTARuntimeMBean could not be found\n" + infe);
      throw new Exception(infe.getMessage());
    }
  }

  public boolean checkHealth() {
    HealthState jmshs = jms.getHealthState();
    HealthState jtahs = jta.getHealthState();

    boolean isJMSOk    = (jmshs.getState() == HealthState.HEALTH_OK); 
    boolean isJTAOk    = (jtahs.getState() == HealthState.HEALTH_OK); 

    System.out.println("JMS Health is checked on " + serverName + 
                       " @ " + new Date(System.currentTimeMillis()) + 
                       ", and the health " + jmshs);
    System.out.println("JTA Health is checked on " + serverName + 
                       " @ " + new Date(System.currentTimeMillis()) + 
                       ", and the health " + jtahs);

    if (isJMSOk && isJTAOk) {
      return true;
    } else { 
      return false;
    }
  }
    private InitialContext getInitialContext(
    String ur,
    String user,
    String pwd
  ) throws NamingException {

    Hashtable env = new Hashtable();

    env.put(Context.PROVIDER_URL, ur);
    env.put(Context.INITIAL_CONTEXT_FACTORY, 
            "weblogic.jndi.WLInitialContextFactory");
    env.put(Context.SECURITY_PRINCIPAL, user);
    env.put(Context.SECURITY_CREDENTIALS, pwd);

    return new InitialContext(env);
  }
}



목록 2. HealthMonitor.java


//-----------------------------------------------------------------------------//
// Listing 3. Migration Helper
//-----------------------------------------------------------------------------//
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.BufferedReader;

/**
 * This class forms the weblogic.Admin command line syntax for
 * MIGRATE command from the arguments and executes
 * java weblogic.Admin [-url URL] -username username -password password \
 *   MIGRATE -jta -migratabletarget (migratabletarget_name|servername) \
 *  -destination servername [-sourcedown] [-destinationdown]
 */

public class MigrationHelper {

  public static void migrate(String adminURL, String adminUsername,
                      String adminPassword, String migratableTargetName,
                      String destinationServerName, boolean sourceUp,
                      boolean destUp, boolean migrateJTA) throws Exception {

    // form the command line syntax for weblogic.Admin MIGRATE command
    StringBuffer sb = new StringBuffer();
    sb.append("java weblogic.Admin");
    sb.append(" -url " + adminURL);
    sb.append(" -username " + adminUsername);
    sb.append(" -password " + adminPassword);
    sb.append(" MIGRATE ");
    sb.append(" -migratabletarget " + migratableTargetName);
    sb.append(" -destination " + destinationServerName);
    if (!sourceUp) sb.append(" -sourcedown ");
    if (!destUp) sb.append(" -destinationdown ");
    if (migrateJTA) sb.append(" -jta ");

    Runtime runtime = Runtime.getRuntime();
    Process proc = runtime.exec(sb.toString());
 
   // put a BufferedReader on the weblogic.Admin output
    InputStream is = proc.getInputStream();
    InputStreamReader isr = new InputStreamReader(is);
    BufferedReader br = new BufferedReader(isr);
    // read the weblogic.Admin output
    String output;
    while ((output = br.readLine()) != null) {
      System.out.println(output);
    }

    // check for weblogic.Admin command execution failure
    try {
      if (proc.waitFor() != 0) {
        System.err.println("weblogic.Admin MIGRATE command exit value = " + proc.exitValue());
      }
    } catch (InterruptedException e) {
      System.err.println(e);
    }
  }
}


목록 3. MigrationHelper.java

6. 참조

1. WebLogic 설명서 - 클러스터의 장애 조치 및 복제 http://e-docs.bea.com/wls/docs81/cluster/failover.html#DefiningMigratableTargetServersinaCluster

7. 부록 1. S마이그레이션 가능한 대상이 구성되어 있는 Config.xml


<MigratableTarget Cluster="mycluster"
 ConstrainedCandidateServers="ManagedServer2,ManagedServer1"
 Name="ManagedServer1 (migratable)"
 Notes="This is a system generated default migratable target for a
 server. Do not delete manually." 
 UserPreferredServer="ManagedServer1"/>

<Server Cluster="mycluster" ExpectedToRun="false"
 ListenAddress="localhost" ListenPort="7001"
 Name="ManagedServer1" NativeIOEnabled="true"
 ServerVersion="7.0.5.0">
 <COM Name="ManagedServer1"/>
 <ExecuteQueue Name="default" ThreadCount="15"/>
 <IIOP Name="ManagedServer1"/>

 <JTAMigratableTarget Cluster="mycluster"
  ConstrainedCandidateServers="ManagedServer2,ManagedServer1"
  Name="ManagedServer1" UserPreferredServer="ManagedServer1"/>
 <TARecoveryService Name="ManagedServer1"/>

 <KernelDebug Name="ManagedServer1"/>
 <Log Name="ManagedServer1"/>
 <SSL Enabled="true" HostnameVerificationIgnored="true"
  ListenPort="7002" Name="ManagedServer1"
  ServerCertificateFileName="democert.pem"
  ServerPrivateKeyAlias="demokey"
  ServerPrivateKeyPassPhrase="{3DES}qmMR/wLVNPjGmnLz/kxKEg=="/>
 <ServerDebug Name="ManagedServer1"/>
 <ServerStart Name="ManagedServer1"/>
 <WebServer Name="ManagedServer1"/>
</Server>

<MigratableTarget Cluster="mycluster"
 Name="ManagedServer2 (migratable)"
 Notes="This is a system generated default migratable target for a
 server. Do not delete manually." 
 UserPreferredServer="ManagedServer2"/>

<Server Cluster="mycluster" ListenAddress="localhost"
 ListenPort="8001" Name="ManagedServer2" NativeIOEnabled="true"
 ServerVersion="7.0.5.0">
 <COM Name="ManagedServer2"/>
 <ExecuteQueue Name="default" ThreadCount="15"/>
 <IIOP Name="ManagedServer2"/>

 <JTAMigratableTarget Cluster="mycluster" Name="ManagedServer2"
  UserPreferredServer="ManagedServer2"/>
 <JTARecoveryService Name="ManagedServer2"/>

 <KernelDebug Name="ManagedServer2"/>
 <Log Name="ManagedServer2"/>
 <SSL Enabled="true" HostnameVerificationIgnored="true"
  ListenPort="8002" Name="ManagedServer2"
  ServerCertificateFileName="democert.pem"
  ServerPrivateKeyAlias="demokey"
  ServerPrivateKeyPassPhrase="{3DES}qmMR/wLVNPjGmnLz/kxKEg=="/>
 <ServerDebug Name="ManagedServer2"/>
 <ServerStart Name="ManagedServer2"/>
 <WebServer Name="ManagedServer2"/>
</Server>


1326 view

4.0 stars