애플리케이션 서버를 중지하는 대신 MVS™ 콘솔 수정
명령을 사용하여 해당 애플리케이션 서버에 대한 리스너를 일시정지하고,
애플리케이션 업데이트를 수행한 후 리스너를 재개할 수 있습니다. 이 기술을 사용하는 경우 애플리케이션 업데이트를 수행하기 위해 서버를 중지한 후
시작할 필요가 없습니다.
시작하기 전에
업데이트가 필요한 클러스터 멤버를 호스트하고 있는 애플리케이션 서버를 판별하십시오.
이 태스크 정보
업데이트를 수동으로 제어하려는 고가용성 애플리케이션이 있지만
영향을 받는 서버를 중지하지 않으려는 경우 MVS 수정 명령을 사용하여 이들 각 서버에 대한 리스너를 일시정지한 후 애플리케이션을
업데이트할 수 있습니다.
유의: MODIFY server,PAUSELISTENERS 명령이 실행되면 제어기가 IIOP(ORB_TCP_SECURE 및 ORB_TCP_LISTENER)를 제외한 모든 포트에서
청취하지 못하게 됩니다. IIOP의 경우에는 이 modify 명령이 실행되면 디먼이 IIOP 전송 채널로 요청이 전송되지 않도록 합니다. 그러나 Bean 캐싱과 같은 캐싱을
수행하는 클라이언트 애플리케이션을 실행 중인 경우에는 이러한 애플리케이션의 요청을 열린 IIOP 포트로 직접 전송할 수 있습니다. 이러한 상황은
서버 시작 프로세스에서 IIOP 리스너가 일찍 시작되기 때문에 발생하며 이 때문에 이 modify 명령이 실행되기 전에 IIOP 포트가 열릴 수 있습니다.
고가용성 환경에서 리스너를 일시정지하고
수동으로 애플리케이션 롤아웃을 제어하려면 다음을 수행하십시오.
참고:
프로시저
- 셀에 있는 모든 노드 사이의 모든 양식의 자동 동기화를
사용 불가능하게 하고 변경사항을 저장하십시오. 다음 프로세스 중 하나를 수행하여 이 단계를 완료하십시오.
- 관리 콘솔에서:
- node_agent_name > 파일 동기화 서비스를 클릭하십시오.
- 자동 동기화 및 동기화 시작 옵션을 선택 취소하십시오.
- 노드에서 변경사항 동기화 옵션을 선택하십시오.
- 저장을 클릭하십시오.
- wsadmin 스크립트를 사용하여 다음 명령을 지정한 후 영향을 받는
모든 노드 에이전트를 다시 시작하십시오.
set node NODE
set na_id [$AdminConfig getid /Node:$node/Server:nodeagent/]
set syncServ [$AdminConfig list ConfigSynchronizationService $na_id]
$AdminConfig modify $syncServ {{autoSynchEnabled false}}
$AdminConfig modify $syncServ {{synchOnServerStartup false}}
$AdminConfig save
set nodeSync [$AdminControl completeObjectName type=NodeSync,node=$node,*]
$AdminControl invoke $nodeSync sync
참고: 프로덕션 환경의
경우 항상 자동 동기화를 사용 불가능하게 하여 노드 에이전트를
실행하는 것이 좋습니다. 그러나 시작 동기화의 경우에는 노드 에이전트가 정지될 때 발생하는 구성 업데이트 사항을 획득할 수 있도록
노드 에이전트에 대해 사용 가능한 것이 좋습니다. 애플리케이션 업데이트 프로세스 동안 자동 재시작 관리자를 통하거나 자동화를
통해 노드 에이전트를 수동으로 다시 시작하지 않도록 할 수 있는 경우 시작 동기화를 사용 가능한 상태로 유지할 수 있습니다.
- 배치 관리자 서버의 마스터 구성 저장소에 있는
애플리케이션을 업데이트하십시오. 다음 프로세스 중 하나를 수행하여 이 단계를 완료하십시오.
- 관리 콘솔에서:
- 을 클릭하십시오.
- 업데이트하려는 애플리케이션을 선택하십시오.
- 애플리케이션 업데이트 프로세스를 완료하십시오.
- 마스터 구성에 변경사항을 저장하십시오.노드에서 변경사항
동기화 옵션을 선택하지 마십시오.
- wsadmin 스크립트를 사용하여 다음 명령을 발행하십시오.
set app_loc /path/to/app
set app_options {application options ie: -appname app}
set options [list -update] lappend options $app_options
$AdminApp install $app_loc $options
$AdminConfig save
이 시점에서 마스터 구성에
애플리케이션의 업데이트된 버전(다음 그림의 App v2)을 갖습니다.
그러나 애플리케이션의 원래 버전(다음 그림의 App v1)이
여전히 LPAR1 및 LPAR2에 클러스터 멤버를 갖는 클러스터에서
실행 중입니다.
그림 1. 애플리케이션 업데이트
설치.
이 그림은 고가용성 환경에서 애플리케이션
업데이트의 첫 번째 단계를 보여줍니다. 
- LPAR1의 애플리케이션 서버 리스너를 일시정지하고 수동으로
노드를 애플리케이션의 업데이트된 버전에 동기화하십시오. 리스너를
일시정지한 후 현재 서버에 지정된 모든 작업 항목이 완료하기를
기다린 후 MVS 콘솔에서 다음 명령을 발행하십시오.
MODIFY short_server_name,PAUSELISTENERS
예를
들어 일시정지하려는 서버에 대한 축약 이름이 BBOS001인 경우 다음
명령을 발행하십시오.
MODIFY BBOS001,PAUSELISTENERS
- 노드를 동기화하십시오. 다음 프로세스 중 하나를 수행하여 이 단계를 완료하십시오.
다음 그림에서 보는 것처럼, 애플리케이션의 업데이트된 버전(App v2)이
이제 LPAR1의 노드에 상주합니다.
그림 2. LPAR1의 노드 업데이트.
이 그림은
두 개의 LPAR을 갖는 고가용성 환경에서 애플리케이션 업데이트의 첫 번째
단계를 보여줍니다. 
- LPAR1의 애플리케이션 서버 리스너를 재개하십시오. MVS 콘솔에서 다음 명령을 발행하십시오.
MODIFY short_server_name,RESUMELISTENERS
예를
들어 일시정지하려는 서버에 대한 축약 이름이 BBOS001인 경우 다음
명령을 발행하십시오.
MODIFY BBOS001,RESUMELISTENERS
- LPAR1에서 실행 중인 애플리케이션의 새 버전을 사용하여
클러스터의 다른 LPAR에서 앞의 세 단계를 반복하여 애플리케이션의
새 버전으로 업데이트하십시오. 다음 그림에서는 두 LPAR
클러스터에서 사용자 구성의 모습을 보여 줍니다.
그림 3. LPAR2의 노드 업데이트.
이 그림은
고가용성 환경에서 애플리케이션 업데이트의 두 번째 단계를
보여줍니다. 
결과
새 버전의 애플리케이션이 클러스터의 모든 LPAR에서
실행 중일 때 애플리케이션 업데이트 프로세스가 완료됩니다.