내용 목차
본 장에서는 JEUS 서버의 2가지 운영 모드와 구성 요소 및 그 구성 요소가 제공하는 서비스에 대해서 설명한다.
JEUS 서버는 2가지 모드로 기동될 수 있다. 한 가지 모드는 여러 서버들을 관리하여 운영하는 도메인 관리 모드이고, 나머지 하나는 클라우드 환경에서 단 하나의 서버만을 운영하는 클라우드 서버는 모드이다.
클라우드 환경에서는 도메인(Domain) 관리와 같은 중앙 관리 기능이 필요하지 않을 수 있다. 이런 경우 JEUS 8.5는 단독 서버로 기동 및 운영할 수 있다.
클라우드 서버는 하나의 서버로 모든 동작을 보장해주기 때문에 DAS와 MS의 기능을 포함하고 있다. 하나 이상의 클라우드 서버를 기동하여 관리하려면 전적으로 사용자가 여러 서버들간의 관리를 해야 한다. 예로 특정 애플리케이션을 모든 클라우드 서버들에 배치하려면 사용자가 개별 서버에 애플리케이션을 배치해야 한다.
클라우드 서버는 도메인 관리 모드에 비해 다음의 제약 사항들이 있다.
서버 클러스터링 기능과 클러스터링 관련 커맨드, 옵션 등을 지원하지 않는다.
세션 서버는 DOMAIN_WIDE 클러스터 모드만 지원한다.
클라우드 서버는 리눅스 계열만 지원한다.
클라우드 서버 모드로 운영하기 위해서는 각 클라우드 벤더에 맞게 환경을 맞춰줘야 하며, 이에 대한 자세한 내용은 “JEUS 설치 및 시작하기”의 “Appendix C. Cloud 환경설정”을 참고한다.
클라우드 서버는 startCloudServer 스크립트로 기동할 수 있다.
여러 개의 서버를 같은 도메인(Domain)으로 묶어 도메인 관리 서버를 통해 중앙에서 관리할 수 있다.
클라우드 서버 기동하는 방법과 도메인에 대한 자세한 내용은 "JEUS Domain 안내서"를 참고한다.
다음은 JEUS의 주요 구성요소이다.
도메인은 서버와 클러스터를 관리하는 그룹을 의미한다. 도메인은 Domain Administration Server(이하 DAS)와 Managed Server(이하 MS)로 구성된다. 도메인에 대한 자세한 내용은 "JEUS Domain 안내서"를 참고한다.
Domain Administration Server(DAS)
DAS는 도메인에서 하나만 존재하는 도메인 관리 서버이다. 도메인 전체의 설정과 애플리케이션을 관리한다. 또한, 도메인에 속한 여러 Managed Server(MS)를 관리하고 제어한다. 클라우드 서버는 모드일 경우에는 자신만을 관리한다.
다음은 DAS의 주요 서비스이다.
JEUS WebAdmin(이하 WebAdmin) 서비스
동적 설정 반영 서비스
도메인 애플리케이션 관리 서비스
도메인 데이터소스 관리 서비스
클러스터 관리 서비스
MS는 도메인에서 하나 이상 존재할 수 있는 구성 요소이다. 사용자가 deploy하는 애플리케이션을 서비스하고, 이러한 애플리케이션이 필요로 하는 서비스를 제공한다.
다음은 MS의 주요 서비스이다.
EJB, WEB, JMS 엔진 서비스
JNDI 서비스
Management 서비스
보안 서비스
HTTP 세션 클러스터링 서비스
트랜잭션 서비스
데이터베이스(이하 DB) 또는 엔터프라이즈 정보 시스템(EIS : Enterprise Information System) 연결 서비스
Scheduler 서비스 등의 다양한 서비스
도메인 구성에 대한 자세한 내용은 “JEUS Domain 안내서”의 “2.2. 도메인 구성”을 참고한다.
Domain Administration Server(DAS)는 도메인을 관리하는 서버이다. 도메인에서 오직 하나만 존재한다. DAS의 역할은 도메인 설정을 관리하고, 도메인에서 서비스되는 애플리케이션을 관리 및 제어한다. 또한 도메인에 속하는 MS를 관리한다.
DAS 개념에 대한 자세한 설명은 “JEUS Domain 안내서”의 “1.3.1. Domain Administration Server(DAS)”를 참고한다.
다음은 DAS에서만 사용할 수 있는 주요 서비스이다. 도메인 단위로 관리되어야 하는 서비스들이기 때문에 DAS에서만 실행된다. 사용자가 아래의 서비스들을 사용하기 위해서는 DAS와 연결된 콘솔 툴(jeusadmin)이나 WebAdmin을 이용해야 한다.
WebAdmin은 도메인을 관리하기 위한 웹 기반의 관리 콘솔이다. 사용자들은 WebAdmin을 통해서 좀 더 편리하게 서버와 애플리케이션 관리하고 제어할 수 있다.
WebAdmin은 웹 애플리케이션의 형태로 DAS에 deploy된다. WebAdmin이 deploy를 완료하지 않았다고 하더라도 DAS는 기동을 완료하고 jeusadmin을 통한 제어나 서비스가 가능하다.
WebAdmin에 대한 자세한 내용은 "JEUS WebAdmin 안내서"를 참고한다.
DAS에서는 동적 설정 반영 서비스를 통해 도메인의 설정이 도메인에 존재하는 모든 서버에서 동일하게 유지될 수 있도록 관리한다. 도메인의 설정을 변경하는 작업은 모두 DAS를 통해서만 가능하다.
WebAdmin이나 콘솔 툴을 통해서 명령을 내릴 수 있다. 도메인의 모든 설정 변경은 동적 설정 반영 서비스로부터 Lock을 가져와야 한다. 설정 변경을 완료한 후에 Activate하면 도메인에 설정이 적용된다. 이때 동적 반영이 가능한 항목은 운영 중인 서버를 재기동하지 않고도 변경한 설정을 서버에 적용할 수 있고, 동적 반영이 불가능한 항목은 운영 중인 서버를 재기동해야 적용된다. 이것이 동적 설정 반영 서비스의 역할이다.
도메인에서 설정 변경을 관장하는 서비스에 대한 자세한 내용은 “JEUS Domain 안내서”의 “제3장 도메인 설정변경”을 참고한다.
DAS에서는 애플리케이션 관리 서비스를 통해 도메인에서 서비스될 모든 애플리케이션을 관리한다. MS에서 애플리케이션을 서비스하기 위해서는 먼저 도메인에 애플리케이션을 등록해야 한다. 그 후에 이 애플리케이션을 서비스할 대상을 Target으로 설정하고 DAS로 애플리케이션 deploy 명령을 실행한다. 도메인 애플리케이션 관리 서비스에서는 DAS에서의 애플리케이션 상태와 MS에서의 애플리케이션 상태가 동일하게 유지될 수 있도록 한다. 또한 DAS에서 애플리케이션 파일이 변경되었다면 MS에서도 파일을 재전송받아 동기화될 수 있도록 한다.
도메인에서 애플리케이션의 관리 방법에 대한 자세한 내용은 “JEUS Applications & Deployment 안내서”의 “제1장 도메인 환경에서 애플리케이션 관리”를 참고한다.
DAS에서는 데이터소스 관리 서비스를 통해 도메인에 등록된 모든 데이터소스를 관리한다. MS에서 데이터소스를 사용하기 위해서는 도메인에 등록된 데이터소스를 지정해야 한다. 도메인에서 데이터소스를 등록하고 관리하는 방법에 대한 자세한 내용은 “제6장 DB Connection Pool과 JDBC”를 참고한다.
DAS에서는 클러스터 관리 서비스를 통해 도메인에 존재하는 클러스터를 관리한다. 클러스터는 동일한 서비스를 수행하는 여러 개의 서버들의 집합으로 서비스 부하 분산(Load Balancing)과 장애 상황에서의 Failover 기능을 제공한다. 클러스터에 대한 자세한 내용은 “JEUS Domain 안내서”의 “제5장 JEUS 클러스터링”을 참고한다.
DAS도 MS와 같은 애플리케이션 서비스를 할 수 있기 때문에 MS에서 실행되는 모든 서비스들을 수행할 수 있다. 규모가 작은 운영계이거나 개발계의 경우처럼 하나의 서버만 띄워도 서비스가 가능한 상황에서는 DAS에서도 MS와 같은 애플리케이션 서비스를 할 수도 있다. MS의 서비스에 대한 자세한 설명은 “1.2.2. Managed Server(MS)”를 참고한다.
DAS에서 MS의 역할을 할 수는 있지만 이를 권장하지는 않는다. 개발계나 규모가 아주 작은 운영계의 경우에는 도메인에 DAS 하나만 존재하더라도 서비스에 무리가 없을 수 있지만, 대부분의 경우 DAS는 관리의 역할만 할 수 있도록 두고 애플리케이션 서비스를 하는 MS를 별도로 두는 것이 일반적이다.
Managed Server(MS)는 실제 애플리케이션을 서비스하기 위한 엔진들과 여러 서비스들을 관장하는 서버 인스턴스를 의미한다. MS는 도메인에 여러 개 존재할 수 있다. MS의 주요 역할은 사용자가 deploy하는 애플리케이션을 서비스하고, 애플리케이션이 필요로 하는 리소스나 서비스를 제공하는 것이다.
다음은 MS의 주요 서비스에 대한 설명이다.
MS의 대표적인 서비스로 Servlet, EJB 컴포넌트를 관리하는 엔진(Engine)과 Jakarta Messaging (구 Java Message Service, JMS)를 제공하는 엔진 서비스가 있다. 엔진 서비스에 대한 자세한 내용은 절 1.2.2. “엔진(Engine) 서비스”를 참고한다.
JNDI 서비스는 Java SE에서 정의한 JNDI 표준의 매커니즘을 제공하는 것으로 JEUS에 등록된 다양한 객체들을 정해진 이름으로 찾아서 사용할 수 있는 방법을 제공한다.
JEUS 서버에서는 이러한 서비스를 제공하는 개체를 JNDI Naming Server라고 부른다. 클러스터링 환경에서는 각각의 MS에서 동작하는 JNDI Naming Server 간에 서로 정보를 교환하면서 마치 하나의 JNDI Naming Server가 있는 것처럼 동작한다. JNDI 서비스에 관한 자세한 내용은 “제4장 JNDI Naming Server”를 참고한다.
Management 서비스는 Java Management Extensions(JMX)를 통해 서비스, 컴포넌트, 애플리케이션을 관리 및 모니터링하는 서비스이다.
JMX에 기술된 JMX Remote API Connector(RMI Connector/JMXMP Connector), HTML 어댑터, SNMP 어댑터와 같은 관리 객체를 JEUS Manager에 설정하고, 이를 통해 JEUS의 관리 및 모니터링 정보에 접속하는 방법을 제공한다. Management 서비스의 설정 및 각 관리 객체에 대한 자세한 내용은 "JEUS JMX 안내서"를 참고한다.
보안 서비스는 애플리케이션 및 내부 컴포넌트의 보안 요청에 대한 응답 및 각종 인증 작업을 수행한다.
보안 서비스에 관련된 자세한 내용은 "JEUS Security 안내서"를 참고한다.
HTTP 세션 클러스터링 서비스는 서블릿 엔진들 사이에 HTTP 세션이 유지될 수 있도록 하는 서비스이다.
JEUS는 분산식 HTTP 세션 클러스터링을 지원한다. 해당 서비스로 인해 서블릿 엔진에 대한 장애에도 HTTP 세션은 유지된다. 분산식 HTTP 세션 클러스터링은 서버를 운영할 때 HTTP 세션에 대한 메모리의 부담이 적은 효율적인 분산 방식이다. JEUS에서 제공하는 HTTP 세션 클러스터링 서비스에 관한 자세한 설명은 “JEUS 세션 관리 안내서”의 “제2장 세션 서버”를 참고한다.
위에 설명한 서비스는 클러스터링에 참여한 경우 자동으로 제공되는 서비스이다. 클러스터링에 참여하지 않은 경우에 도메인에 존재하는 모든 서버에서 세션의 유지를 제공하는 제한된 서비스가 있다. 하지만 이 서비스에는 표현된대로 제한사항이 존재한다. 자세한 설명은 “JEUS 세션 관리 안내서”의 “2.6.2. 도메인 와이드 세션 클러스터 모드”을 참고한다.
EJB 2.x의 경우 원격 클라이언트에서 EJB를 호출하기 위해서는 기본적으로 RMI Stub Class를 필요로 하게 된다. 이때 원격 클라이언트에 RMI Stub Class를 미리 패키징하지 않더라도 Class FTP 서비스를 통해서 필요한 클래스들을 전송받아서 사용할 수 있다.
만약 Class FTP 서비스를 사용하지 않는다면 RMI Stub Class는 원격 클라이언트의 클래스 패스(classpath)에 있어야 한다. 이에 대한 예제는 “JEUS EJB 안내서”의 “제11장 EJB 클라이언트”를 참고한다.
실제로 클래스 파일을 전송하는 프로토콜은 FTP 프로토콜이 아니라 HTTP 프로토콜을 사용한다.
EJB 3.x는 Dynamic Proxy 방식을 사용하기 때문에 이 서비스를 사용하지 않는다. EJB 2.x도 기본적으로는 Dynamic Proxy 방식을 사용하고 설정을 통해 RMI Stub 방식을 사용할 수 있다.
Scheduler는 사용자가 미리 지정한 시간에 특정 작업들을 실행시킨다. Scheduler 서비스에 대한 자세한 정보는 "JEUS Scheduler 안내서"를 참고한다.
서버에서 발생하는 이벤트와 에러를 파일로 기록한다. JEUS에서 Java Logging Technology에서 지원하는 로거의 레벨이나 핸들러 등을 설정할 수 있다. Logging 서비스에 관한 자세한 내용은 “제8장 Logging”을 참고한다.
서버에서는 애플리케이션이 JDBC Connection Pool을 통해서 DB에 접근할 수 있도록 지원한다. 이에 관한 자세한 내용은 “제6장 DB Connection Pool과 JDBC”를 참고한다.
서버에서는 트랜잭션 매니저를 통해서 애플리케이션이 트랜잭션을 사용할 수 있도록 지원한다. 트랜잭션 매니저에 관한 설명은 “제7장 트랜잭션 매니저”를 참고한다.
서버에서는 애플리케이션에 여러 가지 종류의 외부 리소스에 대한 연결을 제공한다.
외부 리소스에 대한 연결 정보는 사용자가 직접 추가할 수 있으며 JNDI Naming Server에 등록되어 애플리케이션에서 JNDI Lookup Operation을 통해 이용할 수 있다. 외부 리소스는 도메인에 설정되지만 도메인에 속한 모든 서버에서 이 서비스를 이용하게 되므로 서버의 서비스로 분류된다.
클러스터링 환경일 경우에는 JNDI Naming Server를 통해서 클러스터에 속한 모든 서버가 같은 리소스 정보를 공유해서 사용하게 된다. 리소스 설정에 관련된 내용은 “제5장 External Resource”를 참고한다.
엔터프라이즈 정보 시스템(EIS) 연결 서비스
애플리케이션이 deploy된 JCA 리소스 어댑터나 외부 리소스 등록 정보를 통해서 EIS에 접근할 수 있다. JCA 리소스 어댑터에 관한 자세한 내용은 "JEUS JCA 안내서"를 참고한다.
엔진은 Jakarta EE에서 정의한 EJB 컨테이너, 웹 컨테이너와 매핑되는 개념으로 사용자가 deploy한 컴포넌트를 관리하고 서비스하는 역할을 한다. 엔진은 서버에 포함되는 서비스이며, 사용자가 설정하지 않아도 서버가 부팅할 때 항상 기본 설정으로 실행된다.
서버가 운영 중에 WebAdmin이나 콘솔 툴을 통해 엔진 설정을 변경할 수 있다. 각 엔진에서 제공하는 기본 설정과 동적 변경 가능한 설정에 대해서는 각 엔진의 매뉴얼을 참고한다.
서버에서 제공하는 서비스 엔진은 다음과 같이 3가지 종류가 있다.
엔진 | 설명 |
---|---|
EJB 엔진 | EJB 컴포넌트를 관리하고 실행하는 EJB 컨테이너 역할을 한다. 이에 대한 자세한 사항은 "JEUS EJB 안내서"를 참고한다. |
웹 엔진 | 웹 컨테이너라고 할 수 있으며, 웹 클라이언트 또는 웹 서버로부터 요청을 받아서 사용자가 deploy한 Servlet(또는 JSP, JSF)을 통해 동적인 웹 컨텐츠를 생성한다. 이에 대한 자세한 사항은 "JEUS Web Engine 안내서"를 참고한다. |
JMS 엔진 | Jakarta Messaging(구 Java Message Service, JMS)를 제공한다. 이에 대한 자세한 사항은 "JEUS MQ 안내서"를 참고한다. |
JEUS 6까지는 엔진 컨테이너에 엔진 설정이 없으면 엔진이 실행되지 않아서 애플리케이션이 서비스될 수 없었다. 웹 엔진을 설정하지 않은 경우에 웹 애플리케이션을 서비스하려면 엔진을 추가하고 JEUS를 재기동해야만 했다. 하지만 JEUS 7부터는 MS를 부팅하면 기본 설정으로 엔진이 실행되어 있는 상태이기 때문에 사용자가 설정하지 않았다고 하더라도 어떤 타입의 애플리케이션이든 deploy하여 서비스 가능하다.
INDEPENDENT 모드는 MS가 DAS의 관리 없이 부팅되어 운영되고 있는 모드를 의미한다. 즉, 부팅할 때 DAS의 URL 정보가 없거나 DAS가 장애상황인 경우에 발생한다.
MS를 시작시킬 때는 항상 DAS의 URL 정보를 옵션으로 주어야 한다. Launcher는 서버를 실행할 때 설정한 URL 정보로 DAS의 URL을 알 수 있기 때문에 이 정보가 없는 경우에는 DAS로부터 설정을 받아올 수가 없다.
서버의 머신에 설정 파일이 존재한다고 하더라도 이전에 사용하던 파일이기 때문에 DAS와 동기화가 맞지 않을 가능성이 높다. 따라서 항상 서버를 부팅할 때는 DAS의 URL을 주어야 한다.
DAS URL을 주지 않아도 되는 경우는 DAS와 MS가 같은 머신에 존재하여 도메인 설정 파일을 전송받지 않아도 밖에 없다. DAS가 장애상황이 아닌데 URL을 주지 않은 경우에는 서버는 INDEPENDENT 상태라고 인식하겠지만, MS에 그룹 관리 서비스가 시작되고 난 후에는 DAS와 통신이 되어 다시 DEPENDENT 모드로 복구될 것이다.
INDEPENDENT 상태는 URL을 주지 않은 상황보다 DAS가 장애상황인 경우에 많이 발생할 것이다. MS를 기동할 때 DAS가 장애상황이었다면 MS의 Launcher는 설정을 받아오는 작업도 실패할 것이다. DAS가 failback되어 INDEPENDENT 상태로 부팅된 MS가 DEPENDENT 모드로 복구되면 DAS로부터 설정 동기화를 하고 Deploy에 실패한 애플리케이션을 다시 deploy한다.
DAS가 복구되어 설정 동기화를 한다고 하더라도, 동적으로 반영되지 않는 설정이 변경된 경우나 이미 deploy되어 서비스되고 있는 애플리케이션이 변경되었다면 MS를 재기동해야 한다.
다음은 MS가 INDEPENDENT 상태로 부팅했을 때의 로그이다.
JEUS_HOME/bin$ ./startManagedServer -domain domain1 -server server1 -u administrator -p adminadmin -dasurl localhost:9736 *************************************************************** - JEUS Home : /home/admin/JEUS8/ - Added Java Option : - Java Vendor : Sun *************************************************************** =============== JEUS LICENSE INFORMATION ================ === VERSION : JEUS 8.5 (8.5.0.0-b266015) === EDITION: Enterprise (Trial License) === NOTICE: This license restricts the number of allowed clients. === Max. Number of Clients: 5 ========================================================== [2016.08.23 22:41:15][0] [launcher-1] [Launcher-0052] Receiving the configuration failed. Attempting to start as INDEPENDENT. <<__Exception__>> java.io.IOException: Connection failed. host:localhost, port:9736, virtual id:FileTransfer at jeus.net.SocketProxy.getConnection(SocketProxy.java:67) at jeus.net.SocketProxy.getConnection(SocketProxy.java:23) at jeus.server.filetransfer.ConfigurationSynchronizer.connect(ConfigurationSynchronizer.java:123) at jeus.server.filetransfer.ConfigurationSynchronizer.connect(ConfigurationSynchronizer.java:106) at jeus.server.filetransfer.ConfigurationSynchronizer.checkConnection(ConfigurationSynchronizer.java:148) at jeus.server.filetransfer.ConfigurationSynchronizer.downloadConfigFileFromDAS(ConfigurationSynchronizer.java:187) at jeus.launcher.ManagedServerLauncher.receiveConfigurationFromDas(ManagedServerLauncher.java:174) at jeus.launcher.ManagedServerLauncher.updateXmls(ManagedServerLauncher.java:57) at jeus.launcher.ManagedServerLauncher.readDescriptor(ManagedServerLauncher.java:39) at jeus.launcher.Launcher.start(Launcher.java:102) at jeus.launcher.ManagedServerLauncher.main(ManagedServerLauncher.java:35) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at jeus.server.Bootstrapper.callMainMethod(Bootstrapper.java:586) at jeus.server.Bootstrapper.callMain(Bootstrapper.java:593) at jeus.server.Bootstrapper.main(Bootstrapper.java:149) at jeus.server.ManagedServerLauncherBootstrapper.main(ManagedServerLauncherBootstrapper.java:10) <<__Exception__>> [2016.08.23 22:41:16][0] [launcher-1] [Launcher-0054] Starting the server using the local configuration. ... [2016.08.23 22:41:21][0] [server1-1] [SERVER-0249] Successfully started the server INDEPENDENTLY [2016.08.23 22:41:21][2] [server1-1] [SERVER-0248] The JEUS server is RUNNING. [2016.08.23 22:41:21][2] [server1-1] [SERVER-0401] The elapsed time to start: 4079ms. [2016.08.23 22:41:21][2] [launcher-10] [Launcher-0034] The server[server1] initialization completed successfully[pid : 16748]. [2016.08.23 22:41:21][0] [launcher-1] [Launcher-0040] Successfully started the server. The server state is now RUNNING. JEUS_HOME/bin$
그 후에 DAS가 정상상황이 되었다면 MS는 다시 설정을 동기화하고, deploy에 실패한 애플리케이션이 있었다면 다시 deploy를 수행할 것이다.
[2016.08.23 22:52:32][2] [server1-15] [Domain-0101] Domain Administration Server recovered. server1 is communicating with the domain administration server. [2016.08.23 22:52:32][2] [server1-15] [SERVER-0201] Successfully connected to the Domain Administration Server(localhost:9736). [2016.08.23 22:52:33][2] [server1-15] [SERVER-0308] Resynchronized the configuration with Domain Administration Server.
본 절에서는 JEUS에서 지원하는 Isolated Class Loader에 대해서 설명한다.
JEUS 5 이하 버전에서는 Shared Class Loader(이하 Shared) 방식을 기본적으로 사용하기 때문에 하위 호환성을 위해 그 방식을 계속 제공한다. 하지만 Shared 방식을 사용하는 것을 권장하지 않기 때문에 아무런 설정을 하지 않으면 기본적으로 Isolated 방식을 사용하게 된다. 본 안내서에는 Shared Class Loader에 대한 설명은 하지 않는다.
JEUS는 애플리케이션 간에 클래스가 중복되어 발생하는 문제를 방지하기 위해 애플리케이션마다 서로 다른 클래스 로더(Class Loader)를 사용한다. 이를 Isolated Class Loader(이하 Isolated)라고 하는데, Java EE 표준은 이 방식을 기본으로 사용할 것을 권장하고 있으며 JEUS도 그 권고를 따르고 있다.
다음은 Isolated의 계층 구조이다.
이 구조에서는 각 애플리케이션의 웹 모듈의 클래스 로더가 해당 애플리케이션의 EJB 클래스 로더의 하위에 존재한다. 그리고 한 애플리케이션의 클래스 로더는 다른 애플리케이션의 클래스 로더에 클래스를 요청하지 않는다. Jakarta EE 표준은 애플리케이션이 다른 애플리케이션의 인터페이스를 필요로 하는 경우 그 인터페이스들을 같이 패키징하도록 규정하고 있으므로 다른 애플리케이션의 클래스 로더를 참조할 수 없다.
클래스를 공유해서 사용하지 않기 때문에 한 애플리케이션을 다시 deploy할 때 다른 애플리케이션도 같이 다시 deploy할 필요가 없어진다. 이 클래스 로더 구조를 제대로 사용하기 위해서는 결국 연관된 애플리케이션 간에 EAR로 묶어서 하나의 애플리케이션으로 만드는 작업이 필요하다.
서버는 DOMAIN_HOME 하위에 각자 자신의 디렉터리를 갖는다. DOMAIN_HOME 하위에 servers 디렉터리에는 도메인에 속한 서버들의 디렉터리가 존재한다. 각 서버별로 DOMAIN_HOME/servers 하위에 서버 이름으로 디렉터리를 생성하고, 자신의 서버만의 공간에 운영 중에 필요한 정보나 서버 시작을 위해 필요한 정보 등을 저장한다. 이를 SERVER_HOME이라고 한다.
SERVER_HOME의 디렉터리 구조는 다음과 같다.
JEUS가 사용하는 서버별 공간으로 사용자가 변경해서는 안 된다.
다음은 하위 디렉터리에 대한 설명이다.
디렉터리 | 설명 |
---|---|
deployed | 서버에 deploy된 애플리케이션의 압축을 푼 이미지 파일과 deploy할 때 생성되는 파일이 위치한다. 이 디렉터리 하위에는 애플리케이션 ID로 디렉터리가 생기고 DAS로부터 받아 온 애플리케이션 파일이 저장된다. 애플리케이션이 archive된 경우 애플리케이션 ID 하위에 압축을 푼다(deploy image). deployed 디렉터리 하위에 '_generated_'라는 디렉터리가 생성되고 애플리케이션을 deploy할 때 생성되는 파일들이 위치한다. 디렉터리 하위에 애플리케이션 ID로 디렉터리를 생성하고 deploy 시점에 필요한 파일을 생성한다. |
ejbtimerdb | EJB 엔진의 타이머 서비스에서 DB 설정이 없는 경우 내부적으로 파일 기반의 DB인 JEUS에 내장된 Apache derby를 사용하기 위한 디렉터리이다. 타이머 서비스에 대한 자세한 설명은 “JEUS EJB 안내서”의 “제10장 EJB Timer Service”를 참고한다. |
session | 분산식 세션 서버에서 사용하는 파일 DB가 위치한다. 분산식 세션 서버에서는 passivation된 세션과 primary 세션 서버에서 전송한 백업 세션들을 이 파일 DB에 저장한다. 자세한 설명은 “JEUS 세션 관리 안내서”의 “제2장 세션 서버”를 참고한다. |
tmlog | 트랜잭션 복구를 위해 남기는 트랜잭션 로그가 남는 디렉터리이다. "_serverName_LOCATION_type_port_ipaddress_virtualport 이름"으로 하위 디렉터리가 생성된다. 생성되는 디렉터리 이름에 type과 virtualhost에는 다음의 값이 설정된다.
자세한 내용은 “7.5.2. 복구 관련 로그 파일”을 참고한다. |
tmp | 서버 운영 중에 임시로 저장할 파일이 있을 때 사용하는 디렉터리로 사용자가 특별히 접근할 일은 없다. |
서버의 시작/종료 스크립트를 포함하고 있다. JEUS_HOME/bin의 스크립트와 동일한 기능을 수행하지만 도메인 이름과 서버 이름을 설정할 필요가 없다.
DAS일 경우에 startDomainAdminServer/stopserver, MS일 경우에 startManagedServer/stopserver가 존재한다.
서버에 적용하고 싶은 애플리케이션 라이브러리가 위치한다.
DOMAIN_HOME/lib/application에 존재하는 도메인 범위의 라이브러리와 충돌될 경우 이 디렉터리에 존재하는 파일이 적용된다. 도메인의 애플리케이션 라이브러리와 충돌되었다는 경고 메시지를 남기고 도메인 범위의 라이브러리는 이 서버에서 무시된다. lib/application에 대한 자세한 설명은 “JEUS Applications & Deployment 안내서”의 “3.3.1. lib/application 디렉터리”를 참고한다.
서버의 Launcher 로그, 서버 로그, 액세스 로그 파일이 저장된다. 각 로그 파일은 로테이션 룰에 따라 "로그 이름_날짜.log00000"으로 생성된다. 00000은 1부터 99999까지의 숫자를 다섯자리로 표현한 것으로 logging에 대한 자세한 내용은 “제8장 Logging”을 참고한다.
노드 매니저(Node Manager)에서 필요한 설정 정보와 로그가 저장되는 디렉터리이다. 자세한 내용은 "JEUS Node Manager 안내서"를 참고한다.
JEUS 7부터 DAS와 MS는 모두 Launcher를 통해서 기동된다. 스크립트를 통해서 서버를 시작시키거나 DAS를 통해서 MS를 시작시킬 때 모두 Launcher 프로세스를 실행한다. Launcher에서는 서버를 띄우기 위한 준비 작업과 실제 서버를 기동하는 작업을 수행한다.
Launcher의 역할은 크게 2가지가 있다.
DAS 또는 외부 저장소로부터 도메인 설정 파일을 받아오는 작업
서버를 기동시켜주는 작업
Launcher는 먼저 DAS 또는 외부 저장소로부터 도메인의 설정 파일들을 받아온다. 대상이 되는 파일은 domain.xml과 security 설정 파일이다. 설정 파일을 받아오는 작업이 완료되면 Launcher에서는 받아온 설정 파일을 기반으로 서버 JVM을 기동한다. 서버를 기동할 때는 설정 파일에서 시작시킬 서버에 설정되어져 있는 JVM 옵션이나 클래스 패스를 읽어서 서버 JVM을 생성할 때 옵션으로 설정한다.
만약 Launcher 프로세스에서 설정을 받아오는 작업을 실패한 경우 머신에 캐시되어 있는 도메인 설정 파일이 존재할 경우 이 파일을 기반으로 서버 JVM을 기동시킬 것이다. Launcher에서 설정을 받아오는 작업도 실패하고, 머신에도 캐시해놓은 설정 파일이 존재하지 않는다면 서버는 부팅될 수 없다.
Launcher 프로세스는 위의 2가지 역할 외에도 서버 부팅 로그의 logging 역할을 한다.
서버가 부팅하면서 발생한 로그는 Launcher 로그에도 logging이 된다. Launcher 프로세스는 서버 JVM을 기동시키고 서버의 부팅 작업이 모두 완료될 때까지 대기하면서 서버를 부팅할 때 발생한 로그를 logging한다. 만약 서버가 로거를 초기화하기 전에 부팅에 실패했다면 Launcher 로그에서 부팅 실패 원인을 확인할 수 있다.
일반적으로 Launcher 프로세스는 서버의 JVM을 기동하고 해당 서버의 부팅이 완료됨을 확인하면 종료된다. Launcher를 통해 기동된 서버 프로세스는 백그라운드로 수행된다는 것에 유의해야 한다. 또한 서버 프로세스는 Launcher 프로세스의 자식 프로세스로 기동되기 때문에 백그라운드 프로세스로 생성되기 때문에 서버 프로세스는 자신의 콘솔 화면을 갖지 못한다.
따라서 서버의 로그를 콘솔 화면으로 출력하고 싶다면 서버를 실행할 때 -verbose 옵션을 추가해야 한다. -verbose 옵션이 존재하면 Launcher 프로세스는 서버가 종료될 때까지 종료되지 않고 서버의 로그를 화면에 출력하는 역할을 하게 된다. Launcher 로그에 대한 자세한 내용은 “8.2.2. Launcher 로거”를 참고한다.