애플리케이션 파일을 각 서버로 배포하고 애플리케이션 서비스를 위한 사전 작업을 진행한다. 이 작업이 성공한 후에 애플리케이션을 서비스할 수 있는 상태로 만든다.

이 작업과정을 DAS에서는 2단계로 나누어서 처리한다. 모든 deploy 명령은 DAS를 통하고 DAS에서는 대상이 되는 서버로 다시 명령을 내린다. 사용자가 Deploy 요청을 할 때 대상으로 설정한 모든 서버에 대한 Deploy 성공을 보장할 수 있어야 사용자가 내린 deploy 명령이 성공했다고 볼 수 있다. 따라서 애플리케이션을 Distribute, Start 두 단계로 나누어서 진행하고 1단계에서 실패하면 deploy 명령은 실패한 것이고 모든 서버에서 undeploy된다.

이러한 두 단계를 하나의 deploy 명령이 아닌 각각 distribute 명령, start 명령으로 나누어서 수행할 수도 있다.

1단계 (Distribute 단계)

대상이 되는 서버나 클러스터로 애플리케이션을 distribute하고 검증한다. 이 단계를 JEUS에서는 애플리케이션 Distribute 단계라고 한다. 이 단계에서는 애플리케이션 파일을 각 서버에 배포하고, 애플리케이션이 서비스될 수 있도록 사전준비 작업과 검증 작업을 수행한다.

실제 Distribute 단계의 작업이 모두 성공하면 서비스를 하기 위한 모든 작업은 끝난 상태이다. EJB 모듈의 경우는 서비스 포트가 열리고 웹 모듈의 경우는 웹 리스너와 웹 모듈의 컨텍스트가 연결된다. 하지만 애플리케이션의 상태는 서비스될 수 없는 DISTRIBUTED 상태이다.

애플리케이션이 DISTRIBUTED 상태일 때 애플리케이션에 서비스를 요청하면 웹 모듈의 경우는 "503 Service Unavailable"이 발생하고, EJB 모듈의 경우는 "Bean이 존재하지 않는다"는 exception이 발생한다.

[2012.05.07 15:28:35][1] [t-1] [JNDI.Context-0073] exception occurred during JNDI operation
<<__Exception__>>
javax.naming.NamingException: javax.ejb.EJBException: java.rmi.RemoteException: EJB object is not read at 
jeus.ejb.client.BusinessObjectFactory.getObjectInstance(BusinessObjectFactory.
java:89)
  at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
  at jeus.jndi.JNSContext.lookupInternal(JNSContext.java:594)
  at jeus.jndi.JNSContext.lookup(JNSContext.java:549)
  at jeus.jndi.JNSContext.lookup(JNSContext.java:538)
  at jeus.jndi.JEUSFailoverContext.lookup(JEUSFailoverContext.java:314)
  at javax.naming.InitialContext.lookup(InitialContext.java:392)
  at test.HelloTest.testHelloBean(HelloTest.java:29)
  ......
Caused by: java.rmi.RemoteException: EJB object is not ready at 
jeus.ejb.container.RemoteInvocationManagerImpl.beforeInvoke(RemoteInvocationManagerImpl.
java:72
  at jeus.ejb.baseimpl.RemoteInvokerServer.preInvoke(RemoteInvokerServer.java:118)
  at jeus.ejb.baseimpl.RemoteInvokerServer.invoke(RemoteInvokerServer.java:97)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.
java:25)
  at java.lang.reflect.Method.invoke(Method.java:597)
  at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
  at sun.rmi.transport.Transport$1.run(Transport.java:159)
  at java.security.AccessController.doPrivileged(Native Method)
  at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
  at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
  at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.
java:790)
  at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
  at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.
java:886)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
  at java.lang.Thread.run(Thread.java:662)

[그림 1.1] 웹 모듈이 DISTRIBUTED 상태일 때 요청을 한 경우 발생하는 에러

사용자가 Deploy 대상으로 설정한 모든 서버와 클러스터로 Distribute 작업이 성공해야 전체 성공이 될 수 있다. 하나라도 실패한 서버가 있다면 사용자가 내린 deploy 명령은 실패하고 성공한 서버에는 undeploy 명령이 보내지면서 이 단계에서 했던 작업을 모두 rollback한다. Deploy 대상으로 설정한 서버 중 일부 서버가 fail 또는 shutdown된 상태라면 이 또한 Deploy 실패이다. 이 경우 사용자가 Deploy 대상에서 해당 서버를 제외하고 deploy 명령을 다시 시도해야 한다.

Deploy 대상이 클러스터라면 클러스터 멤버 중 일부 서버가 fail 또는 shutdown된 상태이더라도 Distribute는 성공할 수 있다. 이런 서버들을 제외한 다른 모든 서버에서 Distribute 작업이 성공한다면 이 애플리케이션은 Distribute 성공이다.

2단계 (Start 단계)

대상이 되는 서버나 클러스터에는 이미 애플리케이션이 distribute된 상태일 때 애플리케이션이 서비스될 수 있도록 start시켜준다. 이 단계에서는 애플리케이션을 서비스될 수 있는 상태로 만들어주는 간단한 작업을 수행한다. 이 단계를 JEUS에서는 애플리케이션 Start 단계라고 한다.

Start 단계에서는 Distribute 단계에서와는 다르게 대상이 되는 서버나 클러스터 중에서 하나의 서버에서라도 Start 작업이 성공하면 전체 성공으로 간주한다. Distribute 작업을 마치면서 이미 애플리케이션의 검증 작업이 완료되었고, 이미 애플리케이션을 서비스할 수 있는 모든 준비가 갖춰진 것이기 때문이다.

Start 작업이 실패했다는 것은 서버가 잠시 장애상태라고 추정할 수 있다. 이는 서버가 정상화되면 Start 작업이 성공해서 애플리케이션을 서비스할 수 있다는 것을 의미이기도 하다. Start 작업에 실패한 서버는 DAS에서 별도의 Thread로 5초 간격으로 10번 재시도한다.

재시도도 실패하면 서버가 복구되지 않은 것이므로 수동으로 서버를 복구해야 한다. 서버가 복구된 후에 애플리케이션에 대해 start 명령을 다시 수행하면 애플리케이션 Start 작업을 실패했던 서버에서 start 명령이 정상적으로 수행된다.

JEUS 7에서부터는 도메인에서 애플리케이션을 관리하기 위해 애플리케이션을 식별할 수 있는 ID를 애플리케이션마다 발급하여 사용하고 있다. 애플리케이션 ID는 도메인에서 애플리케이션을 관리하기 위해 필요한 이름이다. 또한 애플리케이션을 구별할 수 있는 식별자이기 때문에 도메인에서 유일해야 한다.

애플리케이션을 install할 때 ID를 설정할 수 있다. install 명령을 수행할 때 애플리케이션에 ID를 설정하지 않은 경우에는 애플리케이션 파일 이름으로 ID를 만들어서 사용한다. 예를 들어 examples.ear을 install할 때 ID를 설정하지 않았다면 애플리케이션 ID는 'examples_ear'이 된다. ID로는 알파벳이나 숫자를 사용할 것을 권장한다.

애플리케이션 ID는 deploy/undeploy 등 애플리케이션 제어 명령이나 조회 명령을 할 때 설정해야 한다. 도메인에 별도의 저장소(repository)를 설정하고 해당 위치에 애플리케이션 파일을 위치시킨 경우는 애플리케이션 파일 이름을 그대로 ID로 사용한다.

DAS에서 애플리케이션 파일을 전송받으면 도메인 디렉터리 하위에 존재하는 애플리케이션 INSTALL_HOME에 ID로 디렉터리를 생성하고 그 하위에 애플리케이션 파일을 위치시킨다.

애플리케이션을 install하면 다음의 디렉터리가 생성된다. INSTALL_HOME 디렉터리에 대한 자세한 설명은 절 1.1.4. “도메인 INSTALL_HOME 디렉터리”를 참고한다.

INSTALL_HOME/<APPLICATION_ID>/<APPLICATION_FILE>

서버에서도 애플리케이션 파일을 전송받을 때나 압축을 풀 때 DEPLOYED 디렉터리 하위에 APPLICATION_ID를 최상위 디렉터리로 두고 그 하위에 파일을 위치시키고 압축을 푼다.

도메인에서는 애플리케이션에 대한 명령을 주관하기 때문에 도메인에서 보여지는 애플리케이션 상태는 target 서버 전체를 총괄하는 상태를 나타낸다. 서버에서는 실제 애플리케이션을 deploy하고 서비스하는 주체이기 때문에 애플리케이션이 어떤 상태인지를 나타낸다.

도메인에서의 애플리케이션 상태

다음은 도메인에서의 애플리케이션 Lifecycle을 보여주는 그림으로 DAS에서의 애플리케이션 상태의 진행과정이다.

INSTALLED → DISTRIBUTING → DISTRIBUTED → STARTING → RUNNING

[그림 1.2] 도메인에서의 애플리케이션 Lifecycle

다음은 각 상태에 대한 자세한 설명이다.

서버에서의 애플리케이션 상태

다음은 서버에서의 애플리케이션 Lifecycle을 보여주는 그림으로 서버에서의 애플리케이션 상태의 진행과정이다.

DISTRIBUTING → DISTRIBUTED → STARTING → RUNNING

[그림 1.3] 서버에서의 애플리케이션 Lifecycle

다음은 각 상태에 대한 설명이다.

애플리케이션을 deploy할 때 사용되는 디렉터리 구조는 다음과 같다.

도메인 INSTALL_HOME 디렉터리

애플리케이션이 도메인에 install되면 APPLICATION_INSTALL_HOME에 위치하게 된다.

[그림 1.4] 도메인의 INSTALL_HOME 디렉터리

도메인에서 관리하는 애플리케이션 저장소

도메인에 추가한 애플리케이션 저장소(repository)는 다음과 같은 구조로 구성한다.

[그림 1.5] 도메인에 추가한 애플리케이션 저장소 디렉터리

애플리케이션 저장소에는 디렉터리 형태의 애플리케이션과 Archive 형태의 애플리케이션이 모두 저장된다. 이 경우 애플리케이션 ID는 사용자가 부여할 수 없고 항상 파일 이름을 사용하게 된다. 사용자는 애플리케이션 저장소를 추가하고 삭제할 수 있다. 추가 및 삭제 방법에 대해서는 “1.5.1. 애플리케이션 저장소 추가/삭제/조회”를 참고한다.

Deploy 이미지 디렉터리

서버에 애플리케이션을 deploy할 때 DAS로부터 애플리케이션을 전송받아서 다음의 경로에 위치시킨다.

SERVER_HOME/.workspace/deployed

이 위치를 DEPLOYED_HOME이라고 한다. DEPLOYED_HOME에 애플리케이션 ID로 디렉터리를 생성하고 전송받은 애플리케이션 파일을 하위에 위치시킨다.

또한 Deploy를 진행하면서 archive된 애플리케이션의 경우 파일의 압축을 푼다. 이를 애플리케이션의 Deploy 이미지 디렉터리라고 한다. 애플리케이션의 압축을 푸는 디렉터리는 애플리케이션 파일 이름을 변경해서 사용한다. myApp.ear의 경우 압축을 푸는 이미지 디렉터리는 'myApp_ear___'이 된다.

ear 애플리케이션일 경우는 ear 이미지 디렉터리 하위에 모듈의 압축을 푼다. 모듈의 압축을 푸는 디렉터리 이름은 ear의 압축을 푼 디렉터리를 생성한 규칙과 동일하게 ejb.jar인 경우는 'ejb_jar'가 된다.

[그림 1.6] 서버에 deploy된 ear 애플리케이션의 이미지 디렉터리

애플리케이션의 gen 디렉터리

애플리케이션이 서버에 deploy되면서 서비스에 필요한 파일들을 생성하는 경우가 있다.

EJB 애플리케이션과 웹 애플리케이션의 경우 파일 생성이 필요하다. 이 파일들을 DEPLOYED_HOME에 '_generated_'라는 디렉터리 하위에 생성한다. '_generated_' 디렉터리 하위에 애플리케이션 ID로 디렉터리를 생성하여 각 애플리케이션마다 개별적인 generated 디렉터리를 갖게된다. 이 디렉터리를 애플리케이션의 gen 디렉터리라고 한다.

[그림 1.7] 서버에 deploy된 ear 애플리케이션 gen 디렉터리

각 애플리케이션의 gen 디렉터리에는 다음와 같은 파일이 생성된다.

Deploy를 할 때는 어떤 서버에서 서비스할 것인지를 대상(target)을 명확히 해야 한다. Deploy 대상이 될 수 있는 것은 서버와 클러스터이다. 웹 모듈의 경우 특정 호스트로만 서비스하려면 추가적으로 가상 호스트를 설정하여 deploy할 수 있다.

서버

서버는 애플리케이션을 서비스하는 최소 단위이기 때문에 Deploy의 대상이 될 수 있다.

여러 서버를 대상으로 deploy 명령을 한 경우 지정한 서버 중 하나 이상의 서버에서 Deploy에 실패하거나 하나 이상의 서버가 다운되어 있는 경우 Distribute 단계에서 실패한다. 이 경우 Deploy에 실패한 서버에 성공할 수 있도록 적절한 조치를 취한 후 다시 deploy 명령을 수행해야 한다.

또는 실패한 서버를 Deploy 대상에서 제외하고 다시 deploy 명령을 수행하면 Deploy는 성공할 것이다. 만약 서버가 STANDBY 상태이거나 SUSPENDED 상태라면 사용자가 이 서버를 대상으로 deploy 명령을 해도 서버가 서비스될 수 없는 상태이기 때문에 애플리케이션을 start하지 않는다.

Distribute 작업까지만 진행하고 서버가 다시 start 또는 resume되어서 서비스할 수 있는 RUNNING 상태가 되었을 때 해당 애플리케이션을 start한다. 서버 상태에 대한 자세한 설명은 “JEUS Server 안내서”의 “3.1.1. Managed Server의 Lifecycle”을 참고한다.

사용자가 서버에 deploy 명령이 아닌 distribute 명령만 수행한 경우에 애플리케이션은 서비스되지 않는다. 서버가 재부팅된 경우에도 이 상태는 유지되어야 한다. 따라서 DAS에서는 애플리케이션의 상태를 INSTALL_HOME 하위에 ".deployInfo.ser"라는 파일에 기록했다가 서버가 부팅할 때 애플리케이션에 대한 상태를 알려주어서 사용자가 이전에 한 작업을 계속 유지할 수 있도록 해준다.

클러스터

클러스터에 속한 서버에는 서버를 대상으로 deploy할 수 없고 오직 클러스터만 대상으로 deploy할 수 있다. 클러스터를 대상으로 deploy한 경우 클러스터 멤버에 속한 서버 중 하나의 서버에서라도 Distribute가 실패하면 클러스터 Deploy는 실패한다.

하지만 서버 리스트를 대상으로 설정하고 deploy하는 경우와는 달리, 클러스터를 대상으로 deploy하는 경우는 클러스터 멤버 중 일부 서버가 Alive 상태가 아니더라도 Deploy에 성공할 수 있다. 클러스터 멤버 중 Alive 서버 모두에 deploy를 성공하면 클러스터 Deploy는 성공한다.

Deploy를 수행할 때 fail되었거나 RUNNING 상태가 아닌 서버의 경우도 failback되거나 재기동되었을 때 해당 애플리케이션은 deploy되어야 한다. 만약 서버가 Boot-time Deploy를 실패한다면 Deploy 성공을 보장해주기 위해 노력하는 것은 DAS의 역할이다.

DAS에서는 재시도를 통해 Boot-time Deploy에 실패한 클러스터 멤버에 대해서도 최대한 보장해줄 수 있도록 하고 있다. 5분 간격으로 5번의 재시도를 하고, 이것이 모두 실패하면 JEUS에서 복구할 수 있는 오류가 아니기 때문에 사용자가 원인을 찾아 해결할 수 있도록 DAS에서는 더 이상 Deploy를 보장해줄 수 없다는 것을 알려준다. deploy할 때 RUNNING 상태가 아니었던 서버뿐만 아니라 클러스터에 동적으로 추가된 서버도 마찬가지로 Boot-time Deploy를 실패한 경우 DAS에서 위와 같은 방법으로 Deploy를 보장해주고 있다.

DAS에서 클러스터 멤버로의 정해진 Deploy 재시도 작업이 모두 실패한 경우 다음과 같은 메시지를 출력해서 서버에서 에러를 직접 해결할 수 있도록 알려준다.

Deployment reattempts of the application[examples] failed 5 times. 
No more deployment attempts will be made. solve the problem for deploying application.

클러스터 멤버인데 애플리케이션 대상이 서버로 되어 있는 경우는 deploy하지 않는다. 사용자에게 해당 애플리케이션을 undeploy나 remove-application-target 명령을 수행할 수 있도록 다음과 같은 WARNING 메시지만 출력한다.

WARNING: The server[server1] is part of the cluster[cluster1], so this application[exampes] can only be deployed to the cluster. 
Deploy again this application to the cluster target.

deploy 명령으로 이런 문제는 발생할 수 없다. 클러스터 멤버인 서버를 별개의 서버 target으로 deploy를 시도하는 경우에는 deploy 명령이 수행되지 않는다. 이런 문제가 발생할 수 있는 경우는 xml을 수동으로 수정한 경우이다. 이는 JEUS에서 금지하고 있는 사항이기 때문에 전적으로 사용자의 잘못으로 간주한다. JEUS에서는 이로 인해 발생하는 오류들에 대해서는 책임지지 않는다.

서비스되고 있는 독립된 서버를 클러스터 멤버로 동적 추가한 경우는 서버에서 이미 서비스되고 있는 애플리케이션을 undeploy하고 애플리케이션 대상에서도 이 서버를 삭제한다. 또한 클러스터를 대상으로 deploy해야 하는 애플리케이션들도 동적으로 deploy시켜주고 있다. 이미 서버를 대상으로 deploy되어서 서비스하고 있는 애플리케이션이기는 하지만 클러스터에 추가하고 새로운 서비스를 하겠다는 사용자의 의도이기 때문에 애플리케이션을 undeploy하고 새로운 애플리케이션을 deploy해도 무방하다.

클러스터에 동적으로 새로운 멤버를 추가하는 것이 가능하기 때문에 애플리케이션에 대한 처리도 자동으로 해주고 있다. 하지만 이렇게 single 서버와 클러스터를 이미 별도로 구성해서 서비스하다가 싱글 서버를 클러스터의 멤버로 동적추가하는 경우는 자주 사용하지 않고, 사용자 의도이긴하나 서버에서 이미 진행 중인 서비스에 문제가 될 수도 있다. 따라서 클러스터를 확장하는 경우에는 새로운 서버를 추가하고 이 서버를 클러스터의 멤버로 추가하는 것을 권장한다.

가상 호스트(Virtual Host)

웹 엔진에서는 가상 호스트를 이용해 웹 컨텍스트를 특정 호스트에서 서비스할 수 있도록 하고 있다. 가상 호스트는 단독으로 지정할 수 없고 대상이 되는 서버 또는 대상이 되는 클러스터와 함께 지정할 수 있다. 대상이 되는 가상 호스트 없이 deploy할 경우에는 기본 가상 호스트에 deploy된다.

가상 호스트에 대한 자세한 내용은 “JEUS Web Engine 안내서”의 “제5장 가상 호스트”를 참고한다. deploy 명령에 자세한 설명은 “4.3.3. 애플리케이션 Deploy”를 참고한다.

Run-time Deploy는 서버가 기동되어 있는 상태에서 애플리케이션 또는 모듈을 deploy하는 것이다. JEUS의 툴인 WebAdmin과 콘솔 툴을 이용해서 DAS에 접속하여 Run-time Deploy를 할 수 있다.

JEUS 7에서는 Run-time Deploy를 수행하면 영구 Deploy가 된다. 영구 Deploy는 deploy나 distribute 명령을 통해 애플리케이션이 Distribute에 성공하면 domain.xml에 그 내용이 저장되면서 DAS나 MS가 재부팅해도 해당 애플리케이션의 Deploy 정보를 설정 파일에서 읽어 Boot-time Deploy될 수 있도록 애플리케이션 정보를 유지해주는 것을 의미한다.

Deploy는 DAS를 통해서만 가능하기 때문에 domain.xml에 애플리케이션 정보를 쓰는 주체도 오로지 DAS뿐이다. MS에서는 Boot-time에 DAS로부터 설정을 받고 해당 설정에 등록된 애플리케이션 파일을 다운로드받아 XML 파일의 정보를 바탕으로 Boot-time Deploy를 진행할 수 있다.

Run-time Deploy의 명령 방법에 대한 자세한 내용은 “4.3.3. 애플리케이션 Deploy”를 참고한다.

Boot-time Deploy는 MS가 부팅할 때 domain.xml에 등록된 애플리케이션을 deploy하는 것을 의미한다. JEUS 7부터는 영구 deploy를 기본으로 하면서 최초 deploy 명령은 이전에 한 번 deploy된 이력이 있는 애플리케이션들의 서버가 부팅할 때 deploy된다.

DEPENDENT 상태에서의 Boot-time Deploy

MS는 부팅할 때 DAS로부터 domain.xml을 전송받아온다. 이 설정 파일에 등록된 애플리케이션이 있으면 애플리케이션의 대상을 보고 자신의 서버에 deploy해야 할 애플리케이션인지를 판단하여 Deploy를 진행한다. 이때 각 애플리케이션마다 Deploy 작업을 진행하는 것이 아니라 모든 애플리케이션에 대한 Distribute 작업을 먼저 진행하고, 모든 애플리케이션의 distribute가 성공한 경우에 애플리케이션 Start 작업을 진행한다.

Boot-time에 서버에서 진행하는 Distribute 작업은 Run-time에 서버에서 진행하는 Distribute 작업과 크게 다르지 않다. 먼저 애플리케이션 파일을 DAS로부터 전송받는다. 만약 서버에서 이전에 전송받아놓은 파일이 존재한다면 서버에 캐시된 애플리케이션 파일과 DAS에 install된 애플리케이션 파일의 시간을 비교하여 파일 전송 여부를 결정한다. 그 후에 애플리케이션 파일의 압축을 풀고 클래스를 로딩하고 애플리케이션이 서비스될 수 있는 환경을 구성하는 Distribute 작업을 진행한다.

서버를 부팅할 때 하나의 애플리케이션이라도 distribute에 실패하면 서버의 상태는 STANDBY 상태가 되고 그 시점에서 부팅이 멈추게 된다. 이 상황에서 start-server 명령을 수행하면 distribute에 실패한 애플리케이션들을 다시 distribute하고 Boot-time과 마찬가지로 모든 애플리케이션이 distribute에 성공해야 다음 작업인 애플리케이션 Start 작업이 진행된다. 이때도 Distribute 작업에 실패한 애플리케이션이 있다면 서버는 또 다시 STANDBY 상태에 머무르게 된다.

전체 애플리케이션에 대한 Distribute 작업이 성공하지 않았음에도 서버를 RUNNING 상태로 만들어 서비스하려면 다음의 명령을 수행한다.

[DAS]domain1.adminServer>start-server -force server1

start-server 명령에 -force 옵션을 주고 수행하면 현재 Distribute 작업이 성공한 애플리케이션에 대해서만 Start 작업을 수행하고 서버를 서비스 가능한 상태로 만들 수 있다. 이때 서버의 상태는 RUNNING이 된다.

Boot-time Deploy할 때 distribute가 완료된 시점에서 MS는 DAS로부터 해당 애플리케이션이 start를 수행할 수 있는 상태인지를 확인한다.

DAS에서의 애플리케이션 상태가 DEPLOYED, RUNNING 상태인 애플리케이션에 대해서만 Start 작업을 수행할 수 있다. 만약 DAS로부터 애플리케이션의 상태를 얻어오는 작업이 실패했다면 서버는 애플리케이션 Start 작업을 진행하지 않는다. 이때 서버는 부팅을 중단하고 STADNBY 상태에 머무르게 된다.

DAS에서의 애플리케이션 상태에 상관없이 애플리케이션을 start하여 서비스가 가능하려면, distribute에 실패한 애플리케이션이 있을 때와 마찬가지로 start-server 명령에 -force 옵션을 주고 수행하여 서버를 RUNNING 상태로 만들어 서비스 가능하도록 할 수 있다.

서버가 SUSPENDED 상태에서 애플리케이션이 stop, start된 경우에도 마찬가지로 서버가 다시 resume이 되서 RUNNING 상태가 되었을 때 애플리케이션의 바뀐 상태를 잘 유지해줄 수 있도록 해야 한다. 이때는 DAS로부터 애플리케이션의 상태를 다시 받아오지는 않는다. SUSPENDED 상태이더라도 DAS로부터 애플리케이션 stop, start 명령은 받을 수 있기 때문에 실제 애플리케이션이 MS에서 명령을 수행할 수 없는 상태이더라도 DAS로부터 온 start, stop 작업을 기억했다가 서버가 다시 resume이 되는 순간 애플리케이션의 상태를 유지해줄 수 있도록 하고 있다.

INDEPENDENT 상태에서의 Boot-time Deploy

서버가 INDEPENDENT 상태로 부팅된 경우는 DAS의 관리를 받지 않는다. 또한 DAS와 연결할 수 없는 상황이기 때문에 애플리케이션 파일 전송도 받을 수 없다. 따라서 Boot-time Deploy할 때에도 이전에 받아놓았던 애플리케이션 파일이 없거나 잘못되어 있다면 Deploy를 진행할 수 없다.

INDEPENDENT 상태로 서버를 부팅할 때는 애플리케이션 파일에 접근할 수 있는 경우에만 Deploy를 진행할 수 있다. 애플리케이션 파일을 접근할 수 있는 경우는 다음의 3가지 경우를 말한다.

위의 경우에 해당되지 않는다면 해당 애플리케이션은 deploy해야 할 애플리케이션 파일을 찾을 수 없기 때문에 Deploy에 실패한다. 이 경우에도 마찬가지로 서버는 STANDBY 상태가 되며 부팅을 멈추게 된다.

이때는 콘솔 툴을 통해 MS로 connect하여 local-start-server 명령을 통해 서버를 RUNNING 상태가 되도록 할 수 있다.

INDEPENDENT 상태로 서버를 띄울 때에는 DEPENDENT 상태와는 달리 DAS로부터 distribute만 진행해야 하는 애플리케이션 리스트를 받아올 수 없다. 따라서 distribute에 성공한 애플리케이션 모두를 start시켜 서비스가능한 상태로 만든다.

INDEPENDENT 상태로 부팅한 서버가 DAS와 연결되어 DEPENDENT 상태가 되면, 옵션에 따라 distribute에 실패한 애플리케이션들을 모두 distribute를 재시도한다. 실패했던 애플리케이션들이 모두 distribute에 성공하면 Boot-time Deploy할 때와 마찬가지로 DAS로부터 start해야 하는 애플리케이션 리스트를 받아와서 start시켜준다.

또한, distribute만 해야 하는 애플리케이션이 start되어서 서비스되고 있는 경우 이 애플리케이션은 stop시켜준다. 단, 서버가 부팅 중에 DAS가 failback되어 DEPENDENT 상태가 되었다면 위 작업을 별도로 진행하지는 않는다.

애플리케이션 파일의 동기화는 DAS의 주요 역할 중 하나이다. DAS와 MS 사이에 애플리케이션 파일이 동기화되는 경우는 크게 몇 가지가 있다.

DAS에서는 애플리케이션 파일의 동기화뿐만 아니라 애플리케이션의 도메인에서의 상태도 동기화한다.

Boot-time Deploy를 수행할 때 애플리케이션이 DAS에서 DISTRIBUTED 상태로 관리되고 있다면 DISTRIBUTED 상태까지만 만들어준다. 이 애플리케이션을 서비스하기 위해서는 사용자가 start-application 명령을 수행해야 한다.

뿐만 아니라 MS가 INDEPENDENT 상태였다가 DEPENDENT 상태로 변환된 경우 MS에서는 애플리케이션 파일뿐만 아니라 상태도 동기화해준다. DEPENDENT 상태가 된 애플리케이션은 DAS에서 관리하고 있는 애플리케이션의 상태에 따라 MS에서 서비스되고 있는 애플리케이션의 상태도 바뀌게 된다.

INDEPENDENT 상태의 MS에서는 모든 애플리케이션이 서비스될 수 있도록 RUNNING 상태로 만들었지만, DAS와 연결되어 DEPENDENT 상태가 된 후에는 DAS의 상태를 따른다.

DAS에서 애플리케이션이 DISTRIBUTED 상태였다면 MS의 애플리케이션도 중지하여 DISTRIBUTED 상태로 만든다. 또한 DAS에서 이미 undeploy한 애플리케이션이 MS에 존재한다면 이 또한 MS에서도 undeploy한다.

도메인에서는 DAS로 install된 애플리케이션을 한 곳에 모아 관리한다. 이 디렉터리에는 수동으로 애플리케이션을 위치시킬 수는 없다. 여러 저장소(repository)를 설정할 수 있고, 설정한 디렉터리는 모두 애플리케이션 저장소로 인식된다. 애플리케이션 저장소를 추가, 삭제하고 설정되어 있는 정보를 조회하려면 WebAdmin이나 콘솔 툴을 사용해야 한다.

도메인에 애플리케이션 저장소로 설정한 디렉터리에는 Java EE 애플리케이션을 위치시킬 수 있다. Archive 모듈뿐만 아니라 Exploded 모듈도 가능하다.

도메인에 등록된 애플리케이션 저장소(repository)에는 install-application/uninstall-application 명령을 통해서 애플리케이션 파일을 추가, 삭제하는 것은 불가능하다. 애플리케이션 파일을 수동으로 추가, 삭제하면 도메인에서 이를 자동으로 인식할 수 있다. 이렇게 위치시킨 애플리케이션은 도메인에서 INSTALLED 상태로 인식된다. 삭제된 애플리케이션 파일은 애플리케이션 정보에 나타나지 않고 더 이상 도메인에서 관리하지 않는다.

애플리케이션의 ID는 애플리케이션 파일 이름이기 때문에 deploy 명령을 할 때 파일 이름을 -id 옵션으로 지정한다.

애플리케이션 파일이 업데이트하려면 이 저장소의 파일을 수동으로 업데이트한다. 만약 애플리케이션을 deploy할 때 Auto Redeploy 주기를 설정했다면 DAS에서 파일의 변경 여부를 자동으로 감지하여 Auto Redeploy가 가능하다.

애플리케이션 저장소를 추가할 때 저장소에 존재하는 파일 이름이 이미 도메인에서 사용되고 있는 애플리케이션 ID라면 해당 애플리케이션은 도메인에서 인식되지 않고 다음과 같은 로그 메시지가 발생한다.

[2012.05.15 12:37:40.625][1] [adminServer-68] [Deploy-0005] WARNING: The application[myApp] already exists on /JEUS_HOME/.applications/myApp.ear. Change the file name of [/home/user1/apps/myApp].

중복된 애플리케이션 ID를 사용하는 경우 애플리케이션 정보 요청하거나 DAS를 시작하는 경우도 동일한 로그가 발생한다.

또한 추가하려는 애플리케이션 저장소에 유효한 애플리케이션이 존재하지 않는다면 다음과 같은 로그 메시지가 발생한다.

[2012.05.15 12:37:40.625][1] [adminServer-68] [Deploy-0062] WARNING: The repository(/home/user1/apps) does not contain any valid applications, but new applications can be added.

애플리케이션 저장소를 삭제할 때 저장소에 존재하는 파일이 도메인에 distribute되어 있거나 deploy되어 있다면 애플리케이션 저장소는 삭제되지만 애플리케이션이 도메인의 관리 대상에서 삭제되지는 않고 다음과 같은 로그 메시지가 발생한다.

[2012.05.15 12:44:04.328][1] [adminServer-93] [Deploy-0124] WARNING: The application[myApp] is RUNNING in repository[/home/user1/apps]. To remove this application from the domain, undeploy it.

WebAdmin 사용

다음은 WebAdmin을 사용해서 애플리케이션의 저장소를 추가하는 과정에 대한 설명이다.

콘솔 툴 사용

도메인에 애플리케이션 저장소를 추가하려면 add-application-repository 명령을 사용하고, 삭제하려면 remove-application-repository 명령을 사용한다. install할 때 설정하는 ID로 애플리케이션 관리 디렉터리 하위에 디렉터리를 생성하고 거기에 애플리케이션 Archive 파일을 위치시킨다.

다음은 콘솔 툴으로 애플리케이션 저장소를 추가, 삭제, 조회하는 예제이다.

[DAS]domain1.adminServer>add-application-repository /apps/test
Successfully performed the ADD operation for An application repository.
Check the results using "add-application-repository or list-application-repositories"

[DAS]domain1.adminServer>list-application-repositories
Application Repositories
================================================================================
+------------------------------------------------------------------------------+
|                        Path to Application Repository                        |
+------------------------------------------------------------------------------+
| /apps/test                                                                   |
+------------------------------------------------------------------------------+
================================================================================

[DAS]domain1.adminServer>remove-application-repository /apps/test
Successfully performed the REMOVE operation for An application repository.
Check the results using "remove-application-repository or list-application-repositories"

[DAS]domain1.adminServer>list-application-repositories
Application Repositories
================================================================================
+------------------------------------------------------------------------------+
|                        Path to Application Repository                        |
+------------------------------------------------------------------------------+
(No data available)
================================================================================

애플리케이션 저장소를 추가한 후에는 저장소에 존재하는 애플리케이션을 WebAdmin과 콘솔 툴로 deploy할 수 있다. 자세한 내용은 절 4.3.3.2. “콘솔 툴 사용”을 참고한다.