마이그레이션 고려사항
WebSphere® Application Server 버전 9.0로의 마이그레이션 프로세스를 시작하기 전에 유의해야 할 몇 가지 고려사항이 있습니다.

이 기사는 프로파일 구성 마이그레이션에 대한 기사입니다. 애플리케이션을 최신 버전으로 마이그레이션하려면 WebSphere Application Server 마이그레이션 툴킷을 사용하십시오. 자세한 정보는 WASdev의 마이그레이션 툴킷을 참조하십시오.
sptcfgz/OS의 고려사항
z/OS®용 애플리케이션 서버를 마이그레이션하기 전에 다음을 고려하십시오.- 마이그레이션 프로세스는 일반적으로 애플리케이션 서버가 정의한
변수나 사용자 정의 변수의 값을
전달합니다. 하지만 값이 전달되지 않는 몇 가지 특수 변수가
있습니다. 이 값은 다음과 같습니다.
- WAS_INSTALL_ROOT
- USER_INSTALL_ROOT
- WAS_PRODUCT_ROOT
- WAS_LIBS_DIR
- WAS_PROPS_DIR
- WAS_TEMP_DIR
- APP_INSTALL_ROOT
- DRIVER_PATH
- WAS_INSTALL_LIBRARY
- JAVA_HOME
- DEPLOY_TOOL_ROOT
- CONNECTOR_INSTALL_ROOT
- TRANLOG_ROOT
- MQJMS_LIB_ROOT
- WAS_ETC_DIR
- WEMPS_USER_ROOT
- MQ_INSTALL_ROOT
- WAS_DAEMON_ONLY_ICU_DATA
- WAS_DAEMON_ONLY_CONFIG_ROOT
- WAS_DAEMON_primordial_root
- WAS_DAEMON_daemon_was_env_file
이들 변수의 값은 마이그레이션이 프로파일을 작성할 때 프로파일 템플리트에서 선택됩니다. 이 변수의 사용자 정의 값을 정의한 경우에는 마이그레이션 중인 애플리케이션 서버 릴리스에서 이 값이 유지되지 않습니다. 이들 변수는 프로파일 속성인 애플리케이션 서버 특성이기 때문에 마이그레이션되지 않습니다. 기본값 이외의 항목으로 이 값을 대체하려면 제품 설치, 프로파일 작성, 마이그레이션 프로세스 밖에서 값을 변경해야 합니다.문제점 방지: 특히 APP_INSTALL_ROOT 변수에 유의하십시오. APP_INSTALL_ROOT에 직접 정의한 사용자 정의 위치가 있어도 마이그레이션 프로세스는 기본적으로 다음 위치에 애플리케이션을 설치합니다.
gotcha${USER_INSTALL_ROOT}/installedApps
마이그레이션 프로세스에서 기본값이 아닌 애플리케이션 설치 위치를 사용하려면 하려면 다음을 수행하십시오.- zMMT의 애플리케이션 설치 디렉토리 필드에 위치를 지정하십시오.
- 마이그레이션 중 애플리케이션을 마이그레이션하고 이전 애플리케이션 설치 디렉토리 사용 옵션을 선택하여 설치 경로를 다시 입력할 필요 없이 그대로 사용하도록 하십시오. 이전 릴리스의 설치 경로에 변수 참조가 있는 경우 애플리케이션 서버가 마이그레이션 값을 사용하여 이 변수를 분석합니다.
- WebSphere Application Server
버전 9.0를 z/OS 운영 체제에
설치한 후 전체 WebSphere Application Server, Network Deployment
셀 구성을 빌드하고 기존 셀이나 노드를 마이그레이션하려 시도하기 전에
이 구성이 제대로 작동하는지 확인하고자 할 수
있습니다.
이 프로세스는 시스템의 모든 필수 전제조건을 충족시키고 새 제품 레벨을 지원합니다.
- 마이그레이션을 수행하기 전에 WebSphere Application Server
버전 9.0에서
더 이상 사용되지 않는 항목을 평가하십시오.
자세한 정보는 더 이상 사용되지 않는, 안정화, 대체된, 제거된 기능을 참조하십시오.
- WebSphere Application Server 버전 7.0 이상에서 버전 9.0으로 마이그레이션하려면 먼저 애플리케이션 하위 영역 ID를 키 링에 연결하고 키 링에 연관된 WebSphereCA 인증서가 있는지 확인하십시오. 그렇지 않으면 글로벌 보안이 켜졌을 때 보안 오류가 발생합니다.
- 고가용성 관리자와 코어 그룹 기능이
WebSphere Application Server
버전 7.0 이상에
포함되어 있습니다.
버전 7.0 이상에서 버전 9.0으로의 마이그레이션에 영향을 미칠 수 있는 코어 그룹 구성 및 토폴로지 고려사항은 코어 그룹 마이그레이션 고려사항을 참조하십시오.
- 버전 6.1 이전의 IIOP(Internet Inter-ORB Protocol) 클라이언트 실행을 계획 중이며 이 클라이언트가 동일한 논리 파티션(LPAR)의 버전 9.0 서버와 상호 작용하는 경우 버전 9.0 디먼의 디먼 프로시저 라이브러리가 이전 릴리스의 SBBOLD2 및 SBBOLPA 라이브러리를 STEPLIB에 포함해야 합니다.
- 마이그레이션 지원의 경우 소스와 대상 WebSphere Application Server 구성이 모두
LPAR에 있어야 합니다.
따라서 기존 구성을 다른 z/OS LPAR로 마이그레이션할 수 없습니다. WebSphere Application Server 버전 9.0 마이그레이션 유틸리티를 사용하여 z/OS 이외의 운영 체제로 또는 이 운영 체제로부터 마이그레이션할 수 없습니다.
- Sysplex 환경이나 운영 체제에 있는 셀을 마이그레이션하는 경우
고유 마이그레이션 문제가 발생하지 않습니다. 노드 레벨에서
마이그레이션하며, 마이그레이션 중인 노드의 플랫폼을 기반으로 제공되는
도구를 사용합니다.
혼합 플랫폼 셀 설정에 대한 정보는 WebSphere for z/OS -- 이기종 셀 백서를 참조하십시오.
- z/OS
운영 체제의 WebSphere Application Server에서는
제품의 분산 및 i5/OS™ 버전에서
지원되는 WASPreUpgrade, WASPostUpgrade,
manageprofiles 명령행 도구가 지원되지
않습니다.
z/OS 마이그레이션 관리 도구나 zmmt 명령을 사용하여 마이그레이션 작업을 생성한 후 생성된 지시사항에 따라 해당 작업을 제출해야 합니다.
- 버전 9.0로 마이그레이션하는
중 시스템에 필요한 스토리지 크기는 환경에 따라
다릅니다.
- 마이그레이션 정의를 생성할 때 파일 시스템 크기가 z/OS 마이그레이션 관리 도구나 zmmt 명령에 지정된 실린더의 1차 할당 값을 통해 제공됩니다. 또한 이 파일 시스템은 사용자가 지정하는 2차 할당에 기초하여 자동으로 확장 가능합니다. 마이그레이션 도구를 통해 이러한 할당에 제공된 기본값이면 일반적으로 구성 데이터에 충분합니다.
- 마이그레이션 백업 디렉토리에는 상당한 양의 임시 영역이 필요합니다. 필요한 정확한 양은 몇 가지 요소에 따라 다르지만 100실린더 정도면 대부분의 상황(필요한 경우 추적 포함)에서 충분합니다. 임시 디렉토리에 사용 가능한 공간이 확실하지 않으면 z/OS 마이그레이션 관리 도구나 zmmt 명령의 옵션을 사용하여 보다 많은 영역의 사용자 정의 위치로 임시 디렉토리를 이동하고 임시 파일 시스템을 마운트하십시오. 적합한 임시 영역을 확보하지 못하면 마이그레이션 프로세스가 중도에 종료될 수 있습니다.
- IBM® SDK, Java™ Technology Edition, 버전 8은 WebSphere Application Server
버전 9.0의 기본 SDK 버전입니다. .
문제점 방지: 모든 노드가 버전 9.0으로 마이그레이션된 경우가 아니면 SDK, Java Technology Edition, 버전 8을 사용으로 설정하지 마십시오. gotcha
자세한 정보는 API 및 스펙 마이그레이션을 참조하십시오.
- 여러 노드가 있는 셀을 마이그레이션하는 경우 애플리케이션은 모든 노드가 마이그레이션될 때까지 가장 낮은 Java SDK 레벨을 유지해야 합니다.
- 마이그레이션 기사는 WebSphere Application Server
버전 9.0가
WebSphere Application Server의 이전 버전과
공존해야 하는 환경에 설치되고 있다고
가정합니다. 공존 사용을 계획하는 동안 다음 항목을 고려하십시오.
- WebSphere Application Server
버전 9.0에 필요한 레벨로 전제조건을
업데이트하십시오.
WebSphere Application Server의 이전 버전은 더 높은 전제조건 레벨에서 계속하여 실행됩니다.
- WebSphere Application Server
버전 9.0 설치에 충돌이
없도록 포트가 정의되었는지
검토하십시오.
특히, WebSphere Application Server 버전 7.0 이상과 공존하도록 설치할 때는 두 버전의 기본 디먼 포트 정의가 서로 동일합니다.
기본 포트 정보에 대해서는 기본 포트 지정을 참조하십시오.
자세한 정보는 공존 애플리케이션 서버 실행의 내용을 참조하십시오.
- WebSphere Application Server
버전 9.0에 필요한 레벨로 전제조건을
업데이트하십시오.
- 혼합 릴리스 셀을 계획하는 경우에는 다음 정보를
고려하십시오.
- 셀에 있는 노드 중 일부를 WebSphere Application Server
버전 9.0로 업그레이드하고
나머지는 이전 릴리스 레벨로 둘 수
있습니다. 이는 일정 기간 동안 이전 릴리스 레벨의 서버와
동일한 셀에 있는 새 릴리스를 실행 중인 서버를 관리할 수 있음을
의미합니다.
이러한 혼합 릴리스 환경에서는 이전 릴리스 레벨의 서버에 수행 가능한 작업에 대한 몇 가지 제한사항이 있을 수 있습니다. 세부사항은 애플리케이션 서버 작성을 참조하십시오. 클러스터와 클러스터 멤버 작성에 관한 제한사항도 있을 수 있습니다. 세부사항은 클러스터 작성을 참조하십시오.
- 셀에 있는 노드 중 일부를 WebSphere Application Server
버전 9.0로 업그레이드하고
나머지는 이전 릴리스 레벨로 둘 수
있습니다. 이는 일정 기간 동안 이전 릴리스 레벨의 서버와
동일한 셀에 있는 새 릴리스를 실행 중인 서버를 관리할 수 있음을
의미합니다.
- WebSphere Application Server
버전 9.0 마이그레이션은
HTTP 전송을 채널 프레임워크 웹 컨테이너 전송 체인으로
변환합니다. WebSphere Application Server 버전 9.0 전송 지원에 대한 자세한 정보는 다음 정보를 참조하십시오.
- 전송 체인 구성
- HTTP 전송 채널 설정
- 전송 체인
- 구성 파일 시스템 전략을 개발할 때 유지보수 고려사항을
포함시키십시오.
z/OS 마이그레이션 관리 도구에서 제품 파일 시스템 경로의 기본값을 사용하여 WebSphere Application Server, Network Deployment 환경을 구성하는 경우 모든 노드가 직접 제품 파일 시스템의 마운트 지점을 가리킵니다. 이 구성은 손상되지 않는 방식의 롤링 유지보수를 거의 불가능하게 합니다. 이 방식으로 셀을 구성한 경우 제품 파일 시스템에 서비스를 적용하면 모든 노드에 동시에 영향이 미칩니다. 이 방식으로 다중 셀을 구성한 경우 제품 파일 시스템에 서비스를 적용하면 모든 셀에 동시에 영향이 미칩니다.
각 노드의 구성 파일 시스템과 제품 파일 시스템의 실제 마운트 지점 사이의 "중간 기호 링크"로 참조될 항목을 지정할 수 있습니다. 이 전략은 WebSphere Application Server for z/OS V5 - 테스트, 프로덕션, 유지보수 계획 백서에 설명되어 있습니다.
이 문제 및 적용 중인 관계에 대한 자세한 정보는 Washington Systems Center Sample WebSphere for z/OS ND Configuration 백서를 참조하십시오. 기존 구성 HFS(Hierarchical File System)를 업데이트하여 중간 기호 링크를 사용할 수 있는 유틸리티를 확보하여 사용하는 방법에 관한 정보는 WebSphere for z/OS: 기존 구성 HFS를 업데이트하여 중간 기호 링크 사용 지시사항을 참조하십시오.
- 마이그레이션 도구는 이전 버전 구성의 백업 사본을 포함한
마이그레이션 백업 디렉토리를 작성합니다. 이 디렉토리에
사용 가능한 공간은 적어도 이전 버전의 구성 디렉토리와 애플리케이션 크기에
마이그레이션의 일괄처리 작업 출력 크기를 더한
값이어야 합니다.
일반적으로 마이그레이션의 일괄처리 작업 출력 크기는 추적을 사용하지 않으면 매우 작습니다. 추적 출력 크기는 추적을 사용하도록 설정한 마이그레이션 파트에 따라 다릅니다. WASPostUpgrade 마이그레이션 단계의 추적 생성자 크기가 가장 큽니다. 보통 이 단계의 추적 출력 크기는 대략 30MB입니다.
- WebSphere Application Server
버전 9.0에서는
DB2® for zOS 로컬 JDBC 제공자(RRS)가 지원되지
않습니다.
마이그레이션할 버전 7.0 이상 구성에서 zOS용 DB2 로컬 JDBC 제공자(RRS)를 사용하는 경우 버전 9.0 에 마이그레이션하기 전 또는 직후에 DB2 Universal JDBC 드라이버 제공자를 사용하도록 구성을 변경해야 합니다. 버전 9.0 마이그레이션 도구는 제공자를 마이그레이션하지 않습니다.
마이그레이션할 버전에 DB2 for zOS 로컬 JDBC 제공자(RRS)를 사용하며 버전 9.0로 마이그레이션하기 전에 DB2 Universal JDBC 드라이버 제공자를 사용하도록 구성을 변경하지 않으면 다음 이벤트가 발생합니다.- 마이그레이션 도구를 실행할 때 다음 메시지가
수신됩니다.
MIGR0442W: Not migrating DB2 for zOS Local JDBC Provider (RRS) jdbc provider. Manually create a DB2 Universal Driver provider as a replacement. See DB2 documentation for further details.
- 마이그레이션 후 DB2 액세스가 차단되고 다음
런타임 메시지가 수신됩니다.
DSRA8213W: JDBC provider, DB2 for zOS Local JDBC Provider (RRS), is no longer supported by WebSphere Application Server. Applications should use DB2 Universal JDBC Driver Provider Type 2.
DB2 Universal JDBC 드라이버 제공자를 사용하도록 구성을 변경해야 하는 경우 다음 태스크 중 하나를 완료하여 변경할 수 있습니다.- 버전 9.0으로 마이그레이션하기 전에 DB2 Universal JDBC 드라이버 제공자를 사용하도록
버전 7.0 이상 구성을 변경하십시오.
변경하면 버전 9.0 마이그레이션 도구가 DB2 Universal JDBC 드라이버 제공자에 대한 마이그레이션을 처리하며 마이그레이션 후 활동이 필요하지 않습니다.
다음 중 하나를 수행하십시오.- DB2 Universal JDBC 드라이버 제공자를 사용하도록 수동으로 구성을 변경하십시오.
- 버전 7.0 이상에서 마이그레이션하는
중이면 z/OS에서
DB2용 JDBC 마이그레이션 유틸리티를
사용하여 zOS용 DB2 로컬 JDBC 제공자(RRS)에서 DB2 Universal JDBC 드라이버
제공자로 마이그레이션하십시오.
이 도구는 DB2 for zOS 로컬 JDBC 제공자(RRS)에서 DB2 Universal JDBC 드라이버 제공자로 한 번에 한 노드씩 마이그레이션하는 스크립트입니다. 도구와 함께 제공된 백서에는 도구를 실행하여 구성을 마이그레이션하기 전에 DB2 Universal JDBC 드라이버를 구성하는 방법과 설치 방법이 설명되어 있습니다.
- 버전 9.0로 마이그레이션 후
다음 중 하나를 수행하십시오.
- DB2 Universal JDBC 드라이버 제공자를 사용하도록 수동으로 구성을 변경하십시오.
- z/OS에서
DB2용
JDBC 마이그레이션 유틸리티를 사용하여
DB2
for zOS 로컬 JDBC 제공자(RRS)에서
DB2
Universal JDBC 드라이버 제공자로 마이그레이션하십시오.
이 도구는 DB2 for zOS 로컬 JDBC 제공자(RRS)에서 DB2 Universal JDBC 드라이버 제공자로 한 번에 한 노드씩 마이그레이션하는 스크립트입니다.
- 마이그레이션 도구를 실행할 때 다음 메시지가
수신됩니다.
- z/OS 운영 체제에서 실행하는 WebSphere Application Server 버전 9.0로 기본 애플리케이션 서버를 마이그레이션하고 나면 관리 및 사용자 애플리케이션은 이전 릴리스에서처럼 가상 호스트 default_host 아래에 계속해서 정의됩니다. 하지만 마이그레이션된 배치 관리자는 버전 6.1에 소개된 가상 호스트 admin_host 아래에 정의됩니다.
- 분리된 데이터 저장소(특히 SIB 및 Apache Derby 데이터베이스의 트랜잭션 로그와 같은 비공유 저장소)를 사용하고 있으며
이전 릴리스로부터 마이그레이션하는 경우에는 기존 데이터베이스와 트랜잭션 로그가 저장됩니다.
이러한 로컬 데이터 저장소에
매우 중요한 정보가 저장되어 있으면 마이그레이션을 시도하기 전에
이 저장소와 상호작용하는 모든 서버를 안전하게 종료해야 합니다.
이 서버는 마이그레이션이 정상적으로 완료되거나
롤백될 때까지 오프라인
상태여야 합니다.
마이그레이션이 완료되었거나 이전 버전으로 롤백한 후 이러한 분리된 데이터 저장소와 상호작용하는 서버를 다시 시작할 수 있습니다.
- Apache Derby 데이터베이스를 마이그레이션하기 전에 Apache Derby 데이터베이스를 사용 중인 애플리케이션을 호스트하는 애플리케이션 서버를 반드시 닫으십시오. 그렇지 않으면 Apache Derby 마이그레이션이 실패합니다.
- 마이그레이션 보안 도메인에 관련된 다음 규칙에
유의해야 합니다.
- 셀 레벨 범위의 보안 도메인이 있는 배치 관리자를 마이그레이션하는
마이그레이션 도구는 다음 조치를 취합니다.
- 마이그레이션은 아직 존재하지 않는 경우 PassThroughToGlobalSecurity라는 새 구성에 도메인을 작성합니다.
- 마이그레이션은 이전 구성에 존재한 모든 클러스터에 대해
클러스터 맵핑을 새 구성에 추가합니다.
- 마이그레이션 이전에 버전 9.0
배치 관리자 구성에만 있던 클러스터는 PassThroughToGlobalSecurity에 대한 맵핑이
변경되지 않습니다.
- 버전 9.0 클러스터의 맵핑이 마이그레이션 전에 있었으면 마이그레이션 후에도 여전히 존재합니다.
- 버전 9.0 클러스터의 맵핑이 마이그레이션 전에 존재하지 않은 경우에는 마이그레이션 후에도 여전히 존재하지 않습니다.
- 마이그레이션 이전에 이전 구성과 버전 9.0 구성에 모두 클러스터가 있으면 새 구성의 클러스터가 PassThroughToGlobalSecurity 도메인에 추가되어 이전 릴리스의 클러스터처럼 작동합니다.
- 마이그레이션 이전에 버전 9.0
배치 관리자 구성에만 있던 클러스터는 PassThroughToGlobalSecurity에 대한 맵핑이
변경되지 않습니다.
- 마이그레이션은 마이그레이션된 버전 6.1.x 구성에 존재하는 버스의
버스 맵핑을 추가합니다.
버스 맵핑은 클러스터 맵핑과 동일한 규칙에 따라 업데이트됩니다.
- 관리 서버(배치 관리자)는 PassThroughToGlobalSecurity 도메인에 추가되지 않습니다.
- 셀 레벨 범위의 보안 도메인이 있는 연합 노드를 마이그레이션하는 경우
마이그레이션 도구는 다음 조치를 취합니다.
- 마이그레이션은 아직 존재하지 않는 경우 PassThroughToGlobalSecurity라는 새 구성에 도메인을 작성합니다.
- 마이그레이션은 이전 노드 구성의 모든 비클러스터 서버에 대한
서버 레벨 맵핑을 PassThroughToGlobalSecurity 도메인에 추가합니다.
- 클러스터의 일부로 마이그레이션 중인 노드의 서버는 배치 관리자
마이그레이션 중 클러스터 맵핑을 통해 처리되기 때문에
PassThroughToGlobalSecurity 도메인의 항목을
수신하지 않습니다.
해당 맵핑을 제거한 경우 마이그레이션이 이 동작을 유지합니다.
- 관리 서버(노드 에이전트)는 PassThroughToGlobalSecurity 도메인에 추가되지 않습니다.
- 클러스터의 일부로 마이그레이션 중인 노드의 서버는 배치 관리자
마이그레이션 중 클러스터 맵핑을 통해 처리되기 때문에
PassThroughToGlobalSecurity 도메인의 항목을
수신하지 않습니다.
자세한 정보는 다중 보안 도메인의 "혼합 버전 환경의 보안 도메인" 섹션을 참조하십시오.
- 셀 레벨 범위의 보안 도메인이 있는 배치 관리자를 마이그레이션하는
마이그레이션 도구는 다음 조치를 취합니다.
- WebSphere Application Server의 이전 버전에서 java.security 파일을 업데이트한 경우 V8WAS_HOME/properties/java.security에 위치한 마이그레이션된 java.security 파일에 업데이트가 있는지 확인하십시오.
- 마이그레이션 도구를 사용하여 WebSphere Application Server
버전 9.0로 마이그레이션한 후
마이그레이션 도구를 통해 자동으로 수행되지 않은 몇 가지 조치를
수행해야 할 수 있습니다.
- WebSphere Application Server
버전 7.0 이상에서
사용되었을 수 있는 LTPA(Lightweight Third-Party Authentication) 보안 설정을 검토하고
버전 9.0 보안이 적절히 설정되었는지 확인하십시오.
자세한 정보는 LTPA(Lightweight Third-Party Authentication)를 참조하십시오.
- 필요에 따라 WebSphere Application Server
버전 9.0에서 마이그레이션된
서버를 시작하기 전에 새 SAF(System Authorization Facility)
프로파일을 작성하십시오. 버전 6.1에서부터는 특정 보안 기능이 SAF 프로파일을 사용하여 제어됩니다.
- 버전 7.0 이상에서는
신뢰 애플리케이션 사용 설정이 이전 릴리스에서와 같이 내부
WebSphere 변수가 아닌 SAF 보안 프로파일로 제어됩니다.
WebSphere Application Server 런타임에 애플리케이션 코드 대신 특정 권한 조작을 허용하는 신뢰 애플리케이션 사용 옵션은 LocalOS 레지스트리나 SAF 권한을 사용하는 모든 서버에 필요합니다.
- 버전 7.0 이상에서는
OS 스레드에 동기화 허용 기능(애플리케이션이 서버 ID가 아닌
운영 체제 ID를 사용하여 자원에 액세스하도록 허용함)이
SAF 보안 프로파일 및 com.ibm.websphere.security.SyncToOSThread 변수로
제어됩니다.
이 구현을 통해 관리자와 시스템 보안 관리자가 모두 기능의 사용 여부를 결정할 수 있습니다. 이 구현은 애플리케이션이 예상할 수 있는 ID에 대한 제한사항도 허용합니다.
WebSphere Application Server의 이전 버전에서 마이그레이션하며 이 기능이 필요하면 필수 SAF 프로파일을 작성해야 합니다. 이 프로파일이 없고 제대로 설정되지 않은 경우에는 LocalOS 사용자 레지스트리나 SAF 권한을 사용하는 셀이 버전 9.0에서 시작될 때 실패합니다.
보안 시스템에 RACF®(Resource Access Control Facility)를 사용하는 경우 다음 지시사항을 사용하십시오. 다른 SAF 호환 보안 시스템을 사용하면 보안 시스템 벤더에 문의하여 적절한 정보를 얻으십시오.- MVS™(Multiple
Virtual Storage) 시스템 로그를 확인하거나 관리 콘솔을 사용하여
신뢰 애플리케이션 사용이 서버에 사용되는지 여부를
판별하십시오.
시작 로그에서 control_region_security_enable_trusted_applications를 찾으십시오. 이 값이 1로 설정되면 신뢰 애플리케이션 사용이 사용됩니다. 이 옵션이 사용되는 경우 다음 SAF 프로파일을 작성하여 애플리케이션 서버 제어 영역 사용자 ID에 READ 액세스 권한을 부여하십시오.
BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name
다음 RACF 명령을 사용하여 이 조치를 완료하십시오.RDEFINE FACILITY BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name UACC(NONE) PERMIT FACILITY BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name ID(controller_userid) ACCESS(READ) SETROPTS RACLIST(FACILITY) REFRESH
cluster_name SAF 기능 프로파일은 클러스터되지 않은 서버의 클러스터 상태 전이 이름으로 대체됩니다. 셀의 모든 서버에 신뢰 애플리케이션 사용을 사용하려면 클러스터 이름을 와일드카드(*)로 바꾸십시오.
자세한 정보는 System Authorization Facility 클래스 및 프로파일을 참조하십시오.
- MVS(Multiple
Virtual Storage) 시스템 로그를 확인하거나 관리 콘솔을 사용하여
OS 스레드로 동기화 허용이 서버에 사용되는지 여부를 판별하십시오.
이 옵션이 사용되면 다음 SAF 프로파일을 작성하여 애플리케이션 서버 제어 영역 사용자 ID에 READ 또는 CONTROL 액세스 권한을 부여하십시오.
다음 예제는 이 조치를 완료하기 위해 사용할 수 있는 RACF 명령을 포함합니다.BBO.SYNC.cell_shortname.cluster_transition_name
RDEFINE FACILITY BBO.SYNC.cell_shortname.cluster_transition_name UACC(NONE) PERMIT FACILITY BBO.SYNC.cell_shortname.cluster_transition_name ID(controller_userid) ACCESS(CONTROL) SETROPTS RACLIST(FACILITY) REFRESH
클러스터 이름은 클러스터되지 않은 서버의 클러스터 상태 전이 이름으로 대체됩니다. 셀의 모든 서버에 OS 스레드로 동기화 허용을 사용하려면 클러스터 이름을 와일드카드(*)로 바꾸십시오.
중요사항:- 애플리케이션 서버 제어 영역 사용자 ID에 제어 영역 READ 액세스를
허용하면 SAF SURROGAT 프로파일에 기초하여 스레드 ID를
변경할 수 있는 사용자 ID가 제한됩니다.
제어기 사용자 ID에 BBO.SYNC 프로파일에 대한 READ 액세스 권한이 있고 com.ibm.websphere.security.SyncToOSThread 변수가 true로 설정되면 애플리케이션이 OS 스레드로 동기화를 요청할 수도 있습니다. 애플리케이션은 호출자나 역할 관련 사용자의 ID로 자원에 액세스한다고 가정할 수 있습니다. 하지만 하위가 다른 애플리케이션 ID로 실행하려면 하위에 SURROGAT 프로파일 BBO.SYNC.application_userid에 대한 READ 액세스 권한이 필요합니다.
- 제어 영역 CONTROL 액세스 권한을 애플리케이션 서버 제어 영역
사용자 ID에 부여하면 OS 스레드로 동기화를 요청하는
사용자 ID로 스레드 ID가 전환됩니다.
제어기 사용자 ID에 BBO.SYNC 프로파일에 대한 CONTROL 액세스 권한이 있고 com.ibm.websphere.security.SyncToOSThread 변수가 true로 설정되면 애플리케이션이 OS 스레드로 동기화를 요청할 수도 있습니다. 애플리케이션은 호출자나 역할 관련 사용자의 ID로 자원에 액세스한다고 가정할 수 있습니다. SURROGAT 프로파일은 선택되지 않습니다.
자세한 정보는 OS 스레드와 애플리케이션 동기화 허용됨을 참조하십시오.
- 애플리케이션 서버 제어 영역 사용자 ID에 제어 영역 READ 액세스를
허용하면 SAF SURROGAT 프로파일에 기초하여 스레드 ID를
변경할 수 있는 사용자 ID가 제한됩니다.
- 버전 7.0 이상에서는
신뢰 애플리케이션 사용 설정이 이전 릴리스에서와 같이 내부
WebSphere 변수가 아닌 SAF 보안 프로파일로 제어됩니다.
- 역할 기반 권한 부여에 SAF EJBROLE 프로파일을 사용하는 경우에는 버전 6.1에서 도입된 두 가지 관리 역할(배치자 및 관리 보안 관리자)에 대한 EJBROLE 프로파일을 작성하십시오.
- JVM(Java
Virtual Machine) 설정을 검토하여 개선된 시작 성능을 위한 최소 50의
힙 크기를 사용 중인지 확인하십시오.
자세한 정보는 문서에서 "JVM(Java Virtual Machine) 설정" 항목을 읽어보십시오.
이전에 더 작은 힙 크기를 사용한 경우 기본 힙 크기 50을 사용할 수 있습니다.
- 자동 Apache Derby 데이터베이스 마이그레이션 결과를 확인한 후 도구를
통해 자동으로 마이그레이션되지 않은 Apache Derby 데이터베이스를
수동으로 마이그레이션하십시오.
자세한 정보는 Apache Derby 데이터베이스 마이그레이션을 참조하십시오.
- 동일한 논리 파티션(LPAR)에 여러 노드 에이전트가 있으면 마이그레이션 작업을 실행한 후 IPC_CONNECTOR_ADDRESS 포트 충돌이 발생할 수 있습니다. 충돌하는 포트를 재구성하십시오.
- TLS(Transport Layer Security)를 통해
SIP(Session Initiation Protocol) URI(Uniform Resource Identifier)에
요청을 보내려 시도하는 애플리케이션이 있는 경우
WebSphere Application Server 버전 6.1과
버전 9.0 간의 동작 차이점에
유의해야 합니다.
버전 6.1에서 SIP 애플리케이션이 TLS를 통해 SIP URI로 요청을 보낼 때 요청 URI 체계가 "sip"에서 "sips"로 변경됩니다. 버전 9.0에서는 체계가 변경되지 않습니다.
요청 URI에 "sip" 체계와 "tls" 전송 매개변수가 포함된 SIP 요청을 애플리케이션이 보내려 시도할 때 이 차이점이 보입니다. 예를 들어, 버전 6.1의 애플리케이션이 다음 요청 URI의 요청을 작성하고
네트워크로 이 요청을 보내면 SIP 컨테이너는 다음 요청 URI와 같이 되도록 체계와 전송 매개변수를 모두 변경합니다.sip:alice@atlanta.com;transport=tls
버전 9.0에서는 SIP 컨테이너가 체계를 변경하지 않습니다.sips:alice@atlanta.com;transport=tcp
버전 6.1 애플리케이션 서버를 버전 9.0로 마이그레이션한 후 이전 동작을 보유하려면 애플리케이션 코드를 변경하십시오. 애플리케이션은 "sips" URI를 보내려면 메시지를 보내기 위해 요청하기 전에 이 방식으로 URI를 작성해야 합니다. "sips" URI의 경우 버전 6.1에서도 동작이 동일합니다.
- WebSphere Application Server
버전 7.0 이상에서
사용되었을 수 있는 LTPA(Lightweight Third-Party Authentication) 보안 설정을 검토하고
버전 9.0 보안이 적절히 설정되었는지 확인하십시오.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-zos&topic=cmig_pre
파일 이름:cmig_pre.html