LENA
Toggle Dark/Light modeToggle Dark/Light mode
  1. LENA Docs
  2. /
  3. Documentation
  4. /
  5. 1.3.1
  6. /
  7. 1.3.1.6
  8. /
  9. User Guide
User Guide

1. Overview

1.1. LENA는 무엇입니까?

LENA는 Enterprise 환경에서 JAVA J2EE Web Application을 서비스하는데 필요한 모든 구성 요소가 포함된 웹 미들웨어 솔루션이다.

LENA는 실질적인 웹 서비스를 제공하는 Server 제품들과 이를 통합적으로 관리하기 위한 Web UI 기반의 Manager Console로 이루어져있다. 사용자는 Manager Console을 통해 Server 설치부터 Parameter 설정 및 각 제품간 연동 등을 손쉽게 수행할 수 있으며, LENA만의 사용자 친화적인 UX/UI 설계로 웹 미들웨어 솔루션 사용에 익숙하지 않은 사용자라도 빠르게 사용법을 습득하여 웹 미들웨어 관련 지식을 갖출 수 있다.

LENA는 데이터 센터/클라우드 환경에서 웹 미들웨어 운영자들로부터 다년간의 운영 노하우를 집약하여 다양한 편의 기능을 제공한다. 이와 함께 대규모 트랜잭션 안정적으로 처리하고 서비스 장애를 최소화 할 수 있도록 고가용성, 내결함성을 보완한 Clustering, 장애 진단/대응 기능을 제공한다.

다음 절은 LENA의 특징들에 대해 더 상세히 설명한다.

1.2. LENA 특징

Enterprise 요건 제공

LENA Web Application Server EE (J2EE Edition)는 Enterprise Web Application을 실행시키는데 필요한 EJB, JTA/XA, JMS, JAX-WS 등 J2EE Spec을 지원한다. 또한 타사 WAS에 비해 기동성능, Application Deploy성능의 향상을 이루었고, CPU/Memory 등 자원 사용 효율성 역시 향상되었다. 고가용성을 위해 필수인 Session Clustering을 위해 Session Server를 Enterprise Edition에서 기본으로 제공한다.

Opensource 호환성 보장

LENA Web Server, LENA WAS는 Opensource Base로 구현되어 완벽한 Opensource 호환성을 보장한다. Opensource 기반으로 작성된 Web Application이 별도의 수정 없이 LENA에 적용되므로 전환 Effort를 대폭 절감할 수 있다. 또한 Library 및 설정 관련하여 표준 기술을 사용하므로 Vendor 종속성을 해결하여 사용자의 IT Ownership을 강화할 수 있다.

지능형 장애 진단/대응 및 서비스 추적

Thread Pool Full / Hang / Out of memory 등 대표적인 장애 상황들에 대해 사전 정의된 Rule 기반으로 진단을 수행하여 적절한 조치를 수행할 수 있다. 실시간으로 수집되는 Monitoring 데이터를 기반으로 분석하여 Server가 실제 장애로 이어지기 전에 Fake Page 우회 혹은 강제 재기동 등을 통해 장애 상황을 방지하거나 장애로 이어지더라도 장애 시간을 최소화할 수 있다. 이와 동시에 관련된 Dump와 Report를 제공하여 원인 분석을 수행할 수 있게 한다.

Multi-Server 관리 및 Centralized Operation

여러 LENA Web Server와 LENA WAS를 하나의 Cluster로 묶을 수 있어 Single Operation으로 여러 Server를 동시에 제어할 수 있다. 일관적인 설정 동기화와 함께 Graceful Restart혹은 Rolling Restart를 통해 안정적인 반영이 가능하다. 또한 Cluster로 묶이지 않은 Server들에 대해서도 Multi Control을 지원한다.

운영 관점의 차별화 기능 제공

웹 미들웨어 솔루션을 운영하기에 편리한 다양한 편의 기능을 제공한다. Template 기반의 간단하고 빠른 Server설치와 Server 복제 기능을 이용하여 원하는 구성 Set을 짧은 시간 안에 구축이 가능하다. Topology View를 통해 Server 모듈 간 구성 및 연동 정보를 한눈에 확인할 수 있어 가시성을 향상할 수 있다. Dashboard를 통해 운영 중인 시스템의 Event와 성능 현황 등을 확인할 수 있다. 그 밖에 Multi Account 관리를 통해 메뉴/자원의 접근 권한 설정이 가능하며, 운영자 Action Tracing, 설정 변경 정보 History 추적 및 Restore 기능을 제공한다.

1.3. LENA 구성 요소 및 주요 개념

LENA는 Binary Package를 통해 제공이 되며 그 안에 필요한 모든 구성 요소를 포함하고 있다. 구성 요소는 크게 두 범주로 나누어진다.

  • LENA를 운영 관리하기 위한 Management Module로 LENA Manager Console과 LENA Node Agent가 포함된다.

  • 실질적인 Web Service를 담당하는 Server Module로 LENA Web Server, LENA WAS(Web Application Server), LENA Session Server를 포함된다.

다음은 각 구성 요소 별 상세 설명과 함께 이에 따른 주요 개념을 다룬다.

1.3.1. Management Module

LENA Manager

LENA Manager는 Web UI를 통해 LENA의 모든 자원/기능을 설정 및 제어할 수 있도록 설계된 Web Application이다. LENA Package에 준비된 스크립트를 통해 설치 및 기동할 수 있다. LENA Manager를 통해 Server 설치/관리를 수행하려면 Node Agent 및 Advertiser와의 연동을 구성해야 한다.

다음은 LENA Manager에서 제공하는 대표적인 기능과 개념에 대해 설명한다. 아래에 설명되지 않은 상세 사항들에 대해서는 “운영자가이드”를 참조한다.

  • Dashboard
    LENA Node, Server의 자원 현황과 Event 확인

  • Server
    LENA Node의 등록, Web Server, WAS, Session Server 를 설치, 설정 관리 및 기동/중지 제어

    • System
      LENA Node, Server가 관리되는 최소 단위. 하나의 System하위에는 여러 Node를 등록할 수 있으나, 하나의 Node는 여러 System에 중복 등록이 불가하다.

    • Node
      Node Agent와 1:1로 대응되는 개념. Manager에서 원격지에 있는 Server에 명령을 수행하기 위해선 Node Agent를 통해야 한다.

  • Cluster
    Multi-Server 관리. 하나의 System 내의 Server들에 대해서만 Cluster 구성이 가능하며, 하나의 Server는 여러 Cluster에 속할 수 없다.

    • Server Cluster
      여러 LENA Web Server, WAS를 하나의 묶음으로 관리할 수 있다. 설정 동기화, 통합 재 기동 등의 다양한 편의 기능 제공.

  • Resource
    LENA에서 제공하는 Module이 아니지만 LENA Server와 밀접하게 연동되는 자원에 대해 명세를 정의함으로써 Resource로 사용한다. Resource는 LENA WAS별로 Local 설정할 수 있지만, Resource 메뉴를 통해 Global 설정하여 WAS에서 공통 Import하는 방식을 통해 중복된 작업을 피할 수 있다.

    • Database
      DBMS의 IP, Port, Driver 등 물리적 명세를 정의. 하나의 DBMS와 1:1로 대응된다.

    • Datasource
      DB Connection Pool을 LENA WAS에서 구성하기 위해 JNDI Name, Url, User ID/Password등을 지정한다. 하나의Database하위에 여러 Datasource를 구성할 수 있다.

    • Application
      LENA WAS를 통해 실행할 Application의 위치와 Context Path를 지정한다.

  • Topology
    LENA Manager상에 설치되고 연동 구성되어 있는 LENA Web Server, LENA WAS, LENA Session Server 등의 구성 현황을 Topology Diagram 형식으로 표현한다. 이 기능을 통해 Server의 간단한 설치와 기동/중지 제어도 가능하다.

  • Diagnostics
    LENA Node와 Server에 대한 자원 모니터링과 그에 연계된 다양한 기능 탑재.

LENA Node Agent

LENA Node Agent는 LENA Manager에 Node를 등록할 때 Node와 1:1로 대응되며 LENA Package에 기본적으로 설치되어 있으며 준비된 스크립트를 통해 기동할 수 있다. 주요 역할은 LENA Manager를 통해 Node 하위의 Server에 명령을 수행할 때 Node Agent가 이를 담당하며 모니터링 및 상태 데이터를 LENA Manager로 전송하는 기능도 수행한다. 물리 서버 당 1개의 Node Agent를 설치하는 것이 기본이지만, 필요에 따라 여러 개의 Node Agent를 구성할 수 있다. LENA Web Server, LENA WAS, LENA Session Server는 LENA Node 하위에 구성되며, LENA Node는 하나의 System 하위에 구성된다.

1.3.2. Server Module

LENA Web Server

LENA Web Server는 정적 컨텐츠를 전송할 수 있으며 LENA WAS와 Reverse Proxy 형태로 연동하여 LENA WAS가 제공하는 Web Application 서비스의 front-end 역할을 수행한다. 그 외 선택적으로 다양한 추가 기능을 이용할 수 있는데, Domain/URI 기반 분기 및 Load Balancing 기능과 보안 레이어(SSL)를 제공하는 것이 대표적이다.

LENA WAS (Web Application Server)

LENA WAS는 Java Web Application을 실행하여 Web Application 서비스를 제공한다. DB Connection Pool을 이용하기 위한 Datasource 연동 기능과 Session Clustering을 이용하기 위한 Session Server 연동 기능을 포함하고 있다. 다음은 LENA WAS의 두 가지 Type을 설명한다.

  • LENA WAS SE (Standard Edition)
    Java Class 파일을 처리하기 위한 Servlet Engine과 JSP 파일을 처리하기 위한 JSP Engine으로만 구성되어 있으며 WAR Type의 Web Application만 실행할 수 있다. LENA WAS EE에 비해 상대적으로 가볍고 빠르다는 장점이 있다.

  • LENA WAS EE (Enterprise Edition)
    LENA WAS SE가 제공하는 Engine 외에도 EJB Engine, JMS Engine 등 J2EE Spec을 지원하며, WAR/EJB/EAR Type의 Application을 실행할 수 있다. 또한 2 Phase Commit을 위한 XA Datasource를 지원한다.

LENA WAS는 내부적으로 Advertiser Module을 탑재하고 있으며 이는 LENA WAS의 JVM 내부 모니터링 결과를 JMX를 통해 수집하여 LENA Manager로 전달한다.

LENA Session Server

LENA Session Server는 여러 LENA WAS 간의 Session을 공유하여 WAS 다중화를 통한 고 가용성을 보장하기 위해 제공된다. LENA Enterprise Edition을 사용할 경우 기본으로 제공되며 2개의 LENA Session Server를 Active-Active Clustering (양방향 Active-Standby)을 통해 Session Clustering을 구성할 수 있다. LENA Session Server를 사용하기 위해 Application에서 별도의 설정을 할 필요가 없이 LENA Manager에서 간단한 설정만으로 구현이 가능하다.

단, Session-clustering을 하기 위해선 HTTP Session에 저장되는 모든 객체는 직렬화(Serializable)되어야한다.

1.4. LENA 작동방식

Manager에 등록된 Node에는 Node Agent, Application Server에는 Advertiser가 설치되어 있다.

운영자는 Manager의 UI를 통해 각 Node Agent에 Server에 대한 제어요청(예: Start, Stop, Reload, Dump, 설정변경 등)을 보내고, Node Agent가 이를 수신하여 제어를 실행한다.

Node Agent, Advertiser는 주기적으로 모니터링 데이터를 Manager로 전송하고, 운영자는 Monitoring Dashboard와 같은 Manager의 UI를 통해서 각 서버의 자원 현황을 확인할 수 있다. Session Server의 경우 자기 자신의 모니터링 데이터를 직접 Manager에 전달한다.

overview2 mechanism
Figure 1. LENA Mechanism
Table 1. LENA 구성 요소 별 설명
구성요소설명

Manager

Agent를 통한 Server제어와 모니터링 기능 제공

Repository

Manager 운영을 위한 File/DB 탑재

Node

Node Agent를 탑재. Node하위에 Server Module이 설치됨

Node Agent

- Server 설치/복제/패치
- Server 기동/중지 제어
- Server 설정 관리
- Node, Web Server, WAS, Session Server 상태 정보
- Node, Web Server 자원 모니터링 데이터 제공

Advertiser

WAS 자원 모니터링 데이터 제공

WAS

Java Web Application 서비스 제공

Web Server

WAS와 Reverse Proxy 형태로 연동하여 Web 서비스의 Front-end 역할

Session Server

- WAS와 Session Clustering 연동하여 고가용성 구현
- Session Server 모니터링 데이터 제공

1.5. Edition 별 제공 Spec

LENA 는 Application Server 의 기능 제공 범위에 따라 Standard와 Enterprise Edition으로 구분된다. Standard Edition이 Web Application 중심의 Spec을 지원하는 반면, Enterprise Edition은 JTA, JMS, EJB등 J2EE Spec을 지원하며 Session Clustering을 제공한다. 각 Edition별 제공되는 기능 또는 스펙은 아래와 같다.

Table 2. Edition별 제공 기능과 스펙
기능/Spec (LENA-Manager 기준)StandardEnterprise

Server

Web Server

●

●

WAS (SE)

●

●

WAS (EE)

-

●

Session Server

-

●

Resource

Database

●

●

DataSource (일반)

●

●

DataSource (XA)

-

●

JTA

-

●

JMS

-

●

Application (WAR)

●

●

Application (EJB, EAR)

-

●

Cluster

-

●

Topology

●

●

Security

●

●

Diagnostics

Monitoring

●

●

진단/대응

-

●

Patch

●

●

(범례 : ● 제공됨, - 제공되지 않음)

2. Log In/Out

Manager에 로그인과 로그아웃하는 기능을 제공한다.

2.1. Log In

common login
Figure 2. Manager 접속화면

로그인 페이지 하단 좌측에는 설치된 버전이, 우측에는 기술지원 연락처가 기술되어 있다.

로그인 시도시, 7번 이상의 비밀번호 오류가 발생하는 경우 해당 계정으로 로그인을 할 수 없다. 이런 경우 console을 통해 패스워드를 초기화 해야한다. (자세한 내용은 Appendix에서 'Manager 의 admin 패스워드 초기화' 항목을 참고한다.)

2.2. Log Out

Manager 상단 우측의 문 아이콘 을 이용하여 로그아웃을 할 수 있다.

2.3. Theme 변경

Manager 상단 우측의 수레바퀴 아이콘 메뉴의 Dark Theme 메뉴를 통해 테마를 설정 할 수 있다. 라이트 모드와 다크 모드 두 가지 중에 선택이 가능하다.

3. Dashboard

Manager에서 관리되는 시스템 별 구성 정보, 자원 모니터링, 이벤트, 라이센스 등의 정보를 요약하여 제공한다.

dashboard overview
Figure 3. Dashboard

화면 좌측의 시스템 목록에는 로그인 한 사용자에게 권한이 있는 시스템 목록이 제공된다. All은 권한이 있는 모든 시스템의 정보를 통합하여 보여준다.

Table 3. Dashboard 항목
항목설명비고

INVENTORY

Node

System 에 포함된 Node의 수

범례: Node의 타입 별 갯수

  • Web type : Web Server를 설치 할 수 있는 노드 수

  • WAS type : WAS, Session Server를 설치 할 수 있는 노드 수

Server

System에 포함된 Server 타입 별 갯수

Node Status

System에 포함된 Node의 자원(CPU, Memory, DISK) 사용률 상태

범례

  • High / Middle / Low

  • Not working : 정지 상태의 Node(Agent) 갯수

Server Status

System에 포함된 Server의 자원 사용률 상태

  • Web : CPU, Memory, Thread 체크

  • WAS : Heap Memory, Thread Pool 체크

  • Session : Heap Memory 체크

범례

  • High / Middle / Low

  • Not working : 정지 또는 Hang 상태인 서버의 갯수

SERVER CLUSTER

Server Cluster

server cluster 수

Member

server cluster에 속해 있는 타입별 서버 총 수

CHECK

Modified Server

System에 포함된 Server중 재기동이 필요한 서버 존재여부

Out of Cluster Sync

sync가 필요한 Server Cluster 존재여부

Diagnostic Report

진단 프로세스 수행 후 발행된 레포트 갯수

EVENT

Error

System에 포함된 Server에서 발생된 Error 갯수

Stuck Thread

System에 포함된 Server에서 발생된 Stuck Thread 갯수

OOM

System에 포함된 Server에서 발생된 Out Of Memory 갯수

Full GC

System에 포함된 Server에서 발생된 Full GC 갯수

RESOURCE

DB Resource

RESOURCE메뉴에서 등록되어 관리되는 Database와 Datasource 수

Datasource의 범례

  • Used : WAS에서 사용 중인 Datasource 수

  • Not Used : WAS에서 미사용 중인 Datasource 수

LICENSE

License Status

노드들의 라이선스 상태 (Trial 라이선스의 유효일 수 또는 상용라이선스의 유효일 수(종료일자기준 15일 전 부터) 표시)

4. Server

Node 및 WAS, Web Server, Session Server를 관리하기 위한 화면을 제공한다.

특정 System 내의 Node 및 각 Server별 개수를 확인하고, 실시간으로 Node 및 Server 상태를 통합적으로 관리 할 수 있다.

4.1. System

System은 다수의 Server를 가지는 논리적인 그룹이다. "DefaultSystem"을 기본적으로 제공하며 사용자는 System을 생성, 수정, 삭제 할 수 있다.

4.1.1. 목록

System 목록은 화면 좌측에 트리 형태로 제공된다.

server 1 system
Figure 4. System List

4.1.2. 등록

  1. 등록(+) 버튼 을 클릭하여 목록에 "Create System" 을 생성한다.

  2. 생성할 시스템 명을 입력한 후 엔터키를 입력한다.

  3. OK 버튼 을 클릭하여 저장한다.

현재 로그인한 사용자의 권한이 해당 System에 매핑된다. 즉, 로그인한 사용자와 동일한 권한을 가진 사용자에게만 해당 System이 조회된다. (Node, Server, Resource 동일하게 적용됨)

4.1.3. 수정

  1. 수정할 System을 선택한다.

  2. 수정(연필) 버튼 을 클릭하여 선택한 System의 이름을 변경한 후 엔터키를 입력한다.

  3. OK 버튼 을 클릭하여 저장한다.

4.1.4. 삭제

  1. 삭제할 System을 선택한다.

  2. 삭제(-) 버튼 을 클릭한다.

  3. OK 버튼 을 클릭하여 저장한다.

하위에 Node가 존재하는 System은 삭제할 수 없다. 즉, 빈 System만 삭제 가능하다.

4.2. Node

Node는 다수의 WAS, Web Server, Session Server를 가지는 물리적인 Server이다.

4.2.1. 목록

Node List를 통하여 각 Node를 관리할 수 있다.

server 2 node
Figure 5. Node List

Node의 속성은 아래와 같다.

Table 4. Node 속성
항목(*는 필수값)설명비고

Status

Node의 현재상태

아래와 같은 상태를 제공함

  • Started(v)

  • Stop(ㅁ)

Name(*)

Node의 이름

Type(*)

Node의 Type

다음과 같은 타입을 제공함

  • All: 모든 종류의 Server 설치가능

  • Application: WAS와 Session Server 설치가능

  • Web: WEB Server 설치가능

Address(*)

Node의 IP주소

Port(*)

Node Agent의 Port번호

Default : 16800(Node Type이 All 또는 Application인 경우), 16900(Node Type이 Web인 경우)

Manager Address(*)

Manager IP 주소

+ 아이콘

Register 버튼 또는 수정(연필) 버튼 을 클릭하여 선택된 Node정보가 변경 중임을 표시

- 아이콘

삭제(휴지통) 버튼 을 클릭하여 선택된 Node정보가 삭제됨을 표시

Action(…​) 버튼 을 클릭하면 JAVA Home 설정과 Start/Stop을 수행할 수 있는 메뉴 제공

4.2.2. Install

  1. Install 버튼 을 클릭하여 Node정보 등록을 준비한다.

  2. Node의 속성 값을 입력한다.

  3. Save 버튼 을 클릭하여 저장한다.

Table 5. Install 시 설정하는 속성
항목(*는 필수값)설명비고

Node Type

Node의 Type

다음과 같은 타입을 제공함

  • Application: WAS와 Session Server 설치가능

  • Web: WEB Server 설치가능

Node Name(*)

Node의 이름

Node Address(*)

Node의 IP주소

Node Port(*)

Node Agent의 Port번호

Default : 16800(Node Type이 All 또는 Application인 경우), 16900(Node Type이 Web인 경우)

User(*)

Node 실행 사용자 계정

Node Type이 Application인 경우, root 계정으로 실행 할 수 없음. Node Type이 Web인 경우 Web Server의 Port를 1024이하를 사용해야하는 경우에만 root 사용.

Password(*)

Node 실행 사용자 계정 비밀번호

SSH Port

해당 Server에 접속할 SSH 포트

LENA Home

Node Agent가 설치 될 위치

JAVA Installation

Java 설치 여부

JAVA Home

설치된 JAVA 경로

Install 기능은 Linux 환경에서만 지원한다.

4.2.3. Register

  1. Register 버튼 을 클릭하여 Node정보를 등록 가능한 상태로 변경한다.

  2. Node의 Name, Type, Address, Port, Manager Address(기본값이 제공됨) 속성을 입력한다.

  3. Save 버튼 을 클릭하여 저장한다.

  • Manager IP는 Node의 host IP로 자동 입력된다.

  • 네트워크 구성에 따라 자동 입력된 IP가 실제 네트워크 IP와 다른 경우가 발생할 수 있다.

  • 이때는 Manager IP를 수정하여 입력해야 한다.

4.2.4. 수정

  1. 수정(연필) 버튼 을 클릭하여 Node정보를 수정 가능한 상태로 변경한다.

  2. Node의 속성을 수정한다.

  3. Save 버튼 을 클릭하여 저장한다.

  • 포트 정책이나 방화벽 정책 변경 등에 의해 Node의 Address나 Port를 변경해야 하는 경우, agent.conf의 설정정보를 수정 후 Node Agent를 재기동한다.

  • 이 때 변경된 정보를 Manager에서도 알 수 있도록 Node의 Address와 Port정보를 수정하여 입력한다.

수정된 정보를 저장할 때 'Occured Read Timeout' 메세지가 발생하면 아래의 경우를 확인한다.

  • Node Agent가 아닌 다른 곳에서 포트를 사용하는 경우

  • Node Agent가 Hang이 걸린 경우

  • Network 문제가 있는 경우

4.2.5. 삭제

  1. 휴지통 버튼 을 클릭하여 Node정보를 삭제 가능한 상태로 변경한다.

  2. Save 버튼 을 클릭하여 저장한다.

Node 하위에 Server가 등록되어 있는 경우 해당 Node를 삭제할 수 없다.

Uninstall은 Linux 환경에서만 지원되고, 삭제할 노드를 한 개만 선택한 경우 가능하다.

4.2.6. Start

정지 상태인 노드를 기동 시킬 수 있다.

  1. Node목록에서 해당 Node의 맨 우측 컬럼에 있는 …​ 버튼 을 선택시 제공되는 Start 메뉴를 선택하면 팝업창이 나타난다.

  2. User, Password, SSH Port번호를 입력 후 Start 버튼 을 누른다.

4.2.7. Stop

기동 상태인 노드를 정지 시킬 수 있다.

  1. Node목록에서 해당 Node의 맨 우측 컬럼에 있는 …​ 버튼 을 선택시 제공되는 Stop 메뉴를 선택하면 팝업창이 나타난다.

  2. User, Password, SSH Port번호를 입력 후 Stop 버튼 을 누른다.

4.2.8. Change Java Home

Node와 Node에 설치된 Server들의 JAVA Home 경로를 수정할 수 있다.

  1. JAVA Home Path를 수정한다.

    • Node Java Home Path : Node Java Home Path를 편집한다.

    • Server Java Home Path : 선택한 서버들의 JAVA Home 경로를 편집한다. (Web Node에서는 지원하지 않음)

  2. Save 버튼 을 누른다.

4.3. WAS

WAS를 관리하기 위한 화면을 제공한다. Node에 설치한 Server의 등록, 수정, 삭제를 수행하며, 그 외 Server의 설치, 제거 및 복제를 할 수 있다.

4.3.1. 목록

WAS List를 통하여 각 WAS를 관리할 수 있다.

server 3 application server
Figure 6. Web Application Server List

WAS의 속성은 아래와 같다.

Table 6. WAS 속성
항목(*는 필수값)설명비고

Status

Server의 상태

아래와 같은 상태를 제공함

  • Started(v)

  • Stop(ㅁ)

  • Error(!)

Name(*)

Server의 이름

Address

Server의 IP주소

Server ID

Server의 ID

Type

Server의 유형

다음과 같은 타입을 제공함

  • Standard

  • Enterprise/EE

  • Enterprise/SE

HTTP Port

HTTP 포트번호

AJP Port

AJP 포트번호

Server의 시작 및 종료

+ 아이콘

Register 버튼 또는 수정(연필) 버튼 을 클릭하여 선택된 권한 정보가 변경 중임을 표시

- 아이콘

삭제(휴지통) 버튼 을 클릭하여 선택된 권한 정보가 삭제됨을 표시

Action(…​) 버튼 을 클릭하면 Forced Stop과 Forced Restart를 수행할 수 있는 메뉴 제공

4.3.2. Install

  1. Install 버튼 을 클릭하여 Server의 설치를 준비한다.

  2. Server Type, Server ID 등을 입력한다.

  3. Save 버튼 을 클릭하여 저장한다.

  • Node에 실제 설치되어 있는 Server와 Manager에서 관리하는 Server의 정보에는 차이가 있을 수 있다. (console기반 설치 시)

  • Server ID 중복 오류가 발생하는 경우, Register 기능을 이용하여 설치된 Server 정보를 추가로 확인해야 한다.

4.3.3. Clone

  1. Clone 버튼 을 클릭하여 Server의 복제를 준비한다.

  2. Node List에서 복제할 Server를 선택한다. 이때 Clone Server ID, Clone Service Port가 자동으로 입력된다.

  3. Clone Server ID와 Service Port를 원하는 값으로 수정한다.

    (Include External Source는 다른 노드로 서버를 복제하는 경우 사용가능하며, 복제할 서버에 배포되어 있는 어플리케이션 파일도 함께 복제하는지 여부를 설정한다.)

  4. Save 버튼 을 클릭하여 저장한다.

  • Node에 실제 설치되어 있는 Server와 Manager에서 관리하는 Server의 정보에는 차이가 있을 수 있다. (console기반 설치 시)

  • Server ID 중복 오류가 발생하는 경우, register 기능을 이용하여 기존에 설치된 Server 정보를 추가로 확인해야 한다.

4.3.4. Register

  1. Register 버튼 을 클릭한다.

  2. 등록하려는 Server를 선택한다.

  3. Save 버튼 을 클릭하여 저장한다.

System > Application Server List Tab에서도 설치가 가능하다. 단, Node List에서 설치할 Node를 선택해야 한다.

4.3.5. 수정

  1. 수정(연필) 버튼 을 클릭하여 Server정보를 수정 가능한 상태로 변경한다.

  2. Server의 속성을 수정한다.

  3. Save 버튼 을 클릭하여 저장한다.

4.3.6. 삭제

  1. 삭제(휴지통) 버튼 을 클릭하여 Server 정보를 삭제 가능한 상태로 변경한다.

  2. Save 버튼 을 클릭한다.

  3. OK 버튼 을 누르면 삭제 유형을 선택하는 창이 출력된다.

    • Unregister : Manager DB에서만 해당 Server 정보를 삭제하고 물리적인 Server engine은 유지 (추후 Register 버튼 을 통해 다시 등록 가능)

    • Uninstall : Manager DB에서 해당 Server 정보를 삭제하고 물리적인 Server engine도 삭제

  1. Uninstall 선택시, 로그 디렉토리 삭제여부를 묻는 창이 출력된다.

WAS를 삭제할 경우 서비스 제어(ADMIN > Security > Rule Applying 메뉴)의 적용 대상 목록에서 해당 Server는 삭제된다.

Server Cluster에 묶여있는 서버는 삭제할 수 없다.

ADMIN > Preference > Manager Environment 메뉴의 Manager Configuration 영역에서 use Server Delete Protection 값을 true로 설정하는 경우 Manager에서 서버가 uninstall되는 것을 방지 할 수 있다.

4.3.7. Start/Stop

Single Start/Stop

  1. Stop 버튼 을 클릭하여 Server를 종료한다.

  2. Start 버튼 을 클릭하여 Server를 시작한다.

  • Server를 중지시 WAS 가 서비스중인 모든 작업이 끝난 후 종료된다.

  • General 탭의 Shutdown Timeout 시간 이후에도 작업이 끝나지 않은경우 강제로 중지된다.

Server를 시작하면 로그파일을 볼 수 있는 팝업이 실행된다. 팝업을 통해 Server의 정상 기동 여부를 확인할 수 있다.

시작 가능한 상태일 경우에만 Start 버튼 이 활성화 된다.

Multi Start/Stop

  1. 시작 혹은 종료하고자 하는 복수개의 Server를 선택한다.

  2. Server 목록 하단의 Multi Action 버튼 을 클릭한다.

  3. 팝업창에서 Action Type을 선택 후 Action 버튼 을 클릭하여 복수개의 Server에 대한 시작 혹은 종료 작업을 수행한다.

팝업 화면에서 Start / Stop 명령 이후에는 팝업을 닫더라도 요청한 명령이 중지되지 않는다.
Forced Stop/Restart

  1. Server 목록 가장 우측의 추가 기능(…​) 버튼 을 클릭한다.

  2. 강제 종료 혹은 강제 재시작을 수행한다.

강제 중지, 재시작을 수행하면 현재 서비스중인 모든 작업이 즉시 중지되므로 주의해야한다.

4.3.8. 설정 정보 관리

Server의 설정 정보를 변경하는 기능을 제공한다. Server 목록에서 변경하려는 Server 명을 선택한다. Standard Edition의 경우 General, Session, Logging, Web Config, Environment, Properties, Config Tree, History탭을 제공하며, 설정 정보 수정 시 백업을 하여 복원이 가능하다. Enterprise Edition는 Container 탭을 추가적으로 제공한다.

Server 설정을 변경할 경우 수정된 사항의 반영을 위하여 Server의 재기동이 필요하다

General

Server의 일반적인 설정 정보를 관리한다. Port정보, Connector정보, Stuck Thread 관련 설정을 수정 및 저장 할 수 있다.

설정 정보의 상세내용은 아래와 같다.

  1. Server Info

Server의 주요 설정 값을 나타낸다.

Table 7. 주요 설정
항목(*는 필수값)설명비고

HTTP Port(*)

HTTP 포트번호

AJP Port

AJP 포트번호

HTTP 포트번호 - 71 (자동계산)

HTTPS Port

HTTPS 포트번호

HTTP 포트번호 + 363 (자동계산)

Shutdown Port

Shutdown 명령 문자열을 받기 위한 포트

HTTP 포트번호 - 75 (자동계산)

Install Path

Server 설치 경로

Java Home Path

Java Home 경로

Minimum Heap Size(m)(*)

WAS에 설정할 최소 Heap 사이즈(Megabyte)

Default : 512

Maximum Heap Size(m)(*)

WAS에 설정할 최대 Heap 사이즈(Megabyte)

Default : 512

Application Base

Application의 Base 디렉토리

Server가 stop 상태이거나, appBase에 deploy이된 Application이 없을 경우에만 수정이 가능하다.

JvmRoute

Server의 Unique한 Identifier

System Property에 설정되어 있는 값을 우선함.

없을 경우 server.xml의 값을 사용

(Hostname + Port의 조합으로 생성됨)

Auto Deploy

어플리케이션 변경 시 자동 Deploy 여부

Default : false

Application별 DocBase에 war 파일을 재 업로드 할 경우 감지됨

Deploy On Startup

WAS 기동 시 Application Deploy 여부

Default : true

Shutdown Timeout

Server 종료 시 실행중인 작업이 존재할 경우 대기하는 시간(초)

Default : 86400

  1. Connector

Server에서 사용하는 Connector 설정 값을 나타낸다.

Table 8. 주요 설정
항목(*는 필수값)설명기본값

Protocol Type

프로토콜 유형

HTTP/1.1, AJP/1.3

port

포트번호

redirect Port

Redirect 포트

HTTPS Port와 동일

connection Timeout

커넥션 타임아웃(ms)

HTTP : 20000,

AJP : 60000

URIEncoding

URI byte를 변환하기 위한 Character Encoding

UTF-8

server

Http Response에 대한 Server Header를 재정의하여 Server 정보 노출을 방지

Server

maxThreads

Connector가 생성할 수 있는 최대 Thread 수

256

minSpareThreads

Connector생성시 확보하는 최소 Thread 수

10

maxQueueSize

Request Queue 의 최대길이

Integer.MAX_VALUE

packetSize

AJP packet 크기

8192

enableLookups

DNS LookUp 사용여부. 사용하지 않을 시 성능에 유리하다

false

compression

HTTP message Body 압축여부(off, on:Text만, force:전체)

off

tcpNoDelay

TCP 패킷을 Delay 없이 전송

true

  1. Stuck Thread

Stuck Thread의 설정값을 나타낸다.

Table 9. 주요 설정
항목(*는 필수값)설명비고

Threshold(s)

Stuck Thread를 식별하기 위한 최소 시간(s)

Interrupt Thread Threshold

Stuck Thread를 중단하기 위한 최소 시간(s)

Stuck Thread 판별 이후 n초 뒤 종료시키려면 "Threshold+n"값 입력

  1. Service Point

Endpoint Address의 설정값을 나타낸다.

Table 10. 주요 설정
항목(*는 필수값)설명비고

Endpoint Address

WAS의 대표 서비스 도메인 주소

Session

Session Cluster 기능을 사용할지 여부를 설정한다.

  1. Embedded Session Server 모드

    WAS에 Session Server 모듈을 Embedded하여 동작하는 경우 선택한다. Mode 항목에서 Embedded Session Server Mode를 선택하게 되면, Server 관리 화면에서 Session Server 리스트에 Embedded Type으로 표시된다.

Table 11. 주요 설정
항목(*는 필수값)설명기본값

Embedded Host

해당 WAS를 의미

자기 자신의 IP (변경불가)

Embedded Port

해당 WAS에서 사용할 Embedded Session Server 용 port 정보

Secondary Server Host

Slave Server 호스트 IP

Secondary Server Port

Slave Server Port

Multi Login Control

이중 로그인 방지여부

false (true인 경우 아래 3가지 항목이 제공)

Logout Page (Multi Login)

이중 로그인시 먼저 로그인한 사용자의 세션 종료 후 제공할 화면

Logout Message (Multi Login)

이중 로그인시 먼저 로그인한 사용자의 세션 종류 후 보여줄 메세지

Excepted Page for Multi Check

이중 로그인 체크 예외 URL

  1. Client 모드

    별도의 Session Server를 연결하여 동작하는 방식이다. Mode 항목에서 Client Mode를 선택한다.

    Client 모드에서 Primary Server와 Secondary Server 설정 시 사전에 Session Server가 구성되어 있어야한다.

Table 12. 주요 설정
항목(*는 필수값)설명기본값

Primary Server Host

Primary Session Server 호스트

Enter manually 선택시 시스템 외부의 세션서버 설정이 가능

Primary Server Port

Primary Session Server 포트

Secondary Server Host

Secondary Session Server 호스트

PrimaryServer와 연결이 끊어진 경우에만 사용

Enter manually 선택시 시스템 외부의 세션서버 설정이 가능

Secondary Server Port

Secondary Session Server 포트

PrimaryServer와 연결이 끊어진 경우에만 사용

External Stored Session

Session객체를 로컬 WAS에 저장하지 않고 Session Server에 저장

false

Share session in applications

Multi Application간 Session객체를 공유

Client Mode에서만 설정가능

false

Multi Login Control

이중 로그인 방지여부

false (true인 경우 아래 3가지 항목이 제공)

Logout Page (Multi Login)

이중 로그인시 먼저 로그인한 사용자의 세션 종료 후 제공할 화면

Logout Message (Multi Login)

이중 로그인시 먼저 로그인한 사용자의 세션 종류 후 보여줄 메세지

Excepted Page for Multi Check

이중 로그인 체크 예외 URL

Session 기능은 Enterprise Edition에서 제공되는 기능이다.

Logging

Server의 Logging 설정 정보를 관리한다.

  1. Log Home

Table 13. 주요 설정
항목(*는 필수값)설명비고

Log Home(*)

Log Home 경로

default 선택시 서버설치디렉토리 하위 logs 폴더로 설정, custom 선택시 Log Home Prefix항목에서 로그디렉토리 홈 경로 입력가능

Retention Days(*)

로그 최대 보관 일수

Default : 0(무제한)

  1. Access Log

Request에 대한 Access 로그의 설정값을 나타낸다.

Table 14. 주요 설정
항목(*는 필수값)설명비고

Directory

Log 디렉토리

절대경로 또는 $CATALINA_BASE의 상대경로로 지정할 수 있음

Pattern

Logging field의 Layout

Prefix

Log 파일의 prefix

Suffix

Log 파일의 suffix

  1. Handler

Handler 설정 정보의 상세내용은 아래와 같다.

Table 15. 주요 설정
항목(*는 필수값)설명비고

Name(*)

Handler의 클래스명

Type

Handler의 유형

ConsoleHandler와 FileHandler 선택 가능

Level

Handler의 로그레벨

Filter

java.util.logging.Filter의 구현체

Formatter

java.util.logging.Formatter의 구현체

Default : java.util.logging.SimpleFormatter

Encoding

Handler의 Character Encoding

Root

Root Logger여부

  1. Logger

Logger 설정 정보의 상세 내용은 아래와 같다.

Table 16. 주요 설정
항목(*는 필수값)설명비고

Name(*)

Logger 이름 지정

Level(*)

Logger의 로그레벨

Handler(*)

Logger가 어떠한 Handler를 사용할지 선택

ConsoleHandler가 기본 선택

Server의 로그설정 파일은 $CATALINA_HOME($CATALINA_BASE)/conf/logging.properties 이다.

Web Config

Global web.xml의 설정을 관리하는 화면을 제공한다. 필요 항목을 수정한 후 Save 버튼 을 클릭하여 저장한다.

설정 정보의 상세내용은 아래와 같다.

  1. Default Servlet

Table 17. 주요 설정
항목(*는 필수값)설명기본값

Listings

Welcome파일이 없을 때, Directory Listing을 허용할지 여부

false

Input

Input buffer size in bytes

2048

Output

Output buffer size in bytes

2048

Readonly

PUT, DELETE 등의 HTTP메소드를 허용하지 않음

true

FileEncoding

File Encoding

platform default

ShowServerInfo

Directory Listing이 허용되어 있을 때 Server 정보를 표시할지 여부

true

LoadOnStartup

WAS 기동 시 Servlet 로딩 순서 지정

1 (음수: disable / 0: 가장 마지막)

  1. JSP Engine

Table 18. 주요 설정
항목(*는 필수값)설명기본값

CheckInterval

Development가 false일 때 jsp의 변경을 검사하여 재컴파일할지 확인하는 주기(s)

0 (0: 비활성화 / 양수: 해당 주기로 활성화)

Development

Development 여부. Development가 true인 경우에는 modificationTestInterval 값을 주기로 하여 변경을 검사함

true (0: 매 access마다 점검)

GenStringAsCharArray

String생성을 Char Array로 할지 여부

false

ModificationTestInterval

Development가 true일 경우에 동작하는 jsp 변경 검사 주기

4

TrimSpaces

응답에서 쓸데 없는 whitespace를 제거하여 응답바이트를 줄임

false

JavaEncoding

Java소스를 generate할때의 Encoding

UTF8

LoadOnStartup

WAS 기동 시 Servlet 로딩 순서 지정

3

  1. JSP Page Encoding

Table 19. 주요 설정
항목(*는 필수값)설명비고

URL Pattern

Page Encoding을 적용할 JSP Page의 URL Pattern

Page Encoding

적용할 Page Encoding을 지정

  1. Session

Table 20. 주요 설정
항목(*는 필수값)설명비고

SessionTimeout

세션 타임아웃 시간(분)

Default : 30

  1. Welcome File List

Table 21. 주요 설정
항목(*는 필수값)설명비고

File(*)

Directory index로 호출할 경우에 service할 파일을 순서대로 지정함

Environment

JVM 옵션, Start Shell의 설정과 System Properties(Enterprise Edition인 경우만 제공)를 관리하는 화면을 제공한다. 파일 에디터를 통해 수정한 후 Save 버튼 을 클릭하여 저장한다.

  • JVM Setting ($CATALINA_HOME/bin/setenv.sh): Server 실행을 위한 JVM 옵션

  • Custom Settings ($CATALINA_HOME/bin/customenv.sh): 사용자 커스텀 환경변수 설정

  • Start Shell ($CATALINA_HOME/env.sh): Server 시작을 위한 Shell Script

JVM_ROUTE 값은 여기서 직접 수정하지 않고, General 탭의 Server Info 영역에 있는 JvmRoute 항목의 불러오기 버튼 을 사용하여 수정한다. 여기서 직접 수정할 경우 Manager DB의 정보가 Update되지 않아 DB값 불일치가 발생한다.

  • System.properties($CATALINA_HOME/conf/system.properties) (이 항목은 Enterprise Edition에서만 확인할 수 있다)

  • Catalina.properties ($CATALINA_HOME/conf/catalina.properties): Server의 Catalina 설정

$CATALINA_HOME은 WAS의 기본 설치 디렉토리이다. $CATALINA_BASE는 본래 하나의 WAS에 복수개의 Instance를 사용하고자 할 때 디렉토리를 생성하여 Instance별로 지정하여 사용되지만 LENA에서는 WAS와 Instance가 1:1 관계라 $CATALINA_HOME이 곧 $CATALINA_BASE로 사용된다.

기본적으로 설정을 수정할 수 없도록 Disable 되어 있지만, 수정하고 싶은 경우 ADMIN > Manager Environment > Manager Configuration 항목에서 설정 버튼 을 클릭해 아래 설정을 false 로 변경한다.

server.environment.envshell.readonly=false
Properties

Server의 System Properties 와 System Environments를 확인하는 화면을 제공한다. System Properties 중 Key Properties 를 별도로 제공하여 Server경로, JAVA버전 등의 주요 정보를 확인할 수 있다. Server가 기동된 상태에서만 정보를 확인할 수 있다.

Container

Enterprise Edition의 경우 EJB Container의 설정 변경 기능을 제공한다. container설정 없이 Server를 기동하면 EJB에서 필요한 container가 default 설정으로 생성된다. default설정 외에 변경이 필요한 설정이 있을 경우에는 container를 생성하여 설정을 변경해야 한다.

  1. 기본 설정

Table 22. 기본 설정
항목(*는 필수값)설명비고

ID(*)

Container의 식별자

Type(*)

Container의 유형

  1. CMP_ENTITY 설정

Table 23. CMP_ENTITY 설정
항목(*는 필수값)설명비고

CmpEngineFactory

Factory 클래스 명

Default : org.apache.openejb.core.cmp.jpa.JpaCmpEngineFactory

  1. BMP_ENTITY 설정

Table 24. BMP_ENTITY 설정
항목(*는 필수값)설명비고

PoolSize

Bean pool의 크기 지정

Default : 10

  1. STATELESS 설정

Table 25. STATELESS 설정
항목(*는 필수값)설명비고

AccessTimeOut

호출간 대기시간 (Specifies the time to wait between invocations)

Default : 0 (means no timeout)

MaxSize

Bean pool의 최대 개수

Default : 10

MinSize

Bean pool의 최소 개수

Default : 0

StrictPooling

Pool이 최대치에 도달했을 때 동작방식 지정. StrictPooling은 pool size를 늘리지 않고 기다림

Default : true

MaxAge

Pool에서 제거되기까지의 최대 시간(h)

Default : 0

ReplaceAged

MaxAge에 도달했을 때 Replace할지 여부

Default : true

ReplaceFlushed

pool에서 Flush될 때 Replace할지 여부

Default : false

MaxAgeOffset

MaxAge 사용량

Default : -1

IdleTimeout

인스턴스가 pool에서 idle상태로 있을 수 있는 최대 시간(m)

Default : 0

GarbageCollection

풀을 줄이기 위한 메커니즘으로 garbage collection을 허용할지 여부

Default : false

SweepInterval

컨테이너가 풀을 정리하고 만료된 instance들을 제거하는 주기(m)

Default : 5

CallbackThreads

Thread Pool 사이즈. 이 값은 컨테이너에 배포되어 있는 모든 Bean들에게 공유됨

Default : 5

CloseTimeout

풀이 닫히고 PostConstruct 메소드가 호출될때까지 기다리는 최대 시간(m)

Default : 5

  1. SINGLETON 설정

Table 26. SINGLETON 설정
항목(*는 필수값)설명비고

AccessTimeOut

호출간 대기시간

(Specifies the time to wait between invocations)

Default : 0 (means no timeout)

  1. STATEFUL 설정

Table 27. STATEFUL 설정
항목(*는 필수값)설명비고

AccessTimeOut

호출간 대기시간 (Specifies the time to wait between invocations)

Default : 0 (means no timeout)

Cache

Stateful 빈 인스턴스를 관리할 cache

Default : org.apache.openejb.core.stateful.SimpleCache

Passivator

Passivator클래스 지정

Default : org.apache.openejb.core.stateful.SimplePassivator

TimeOut

호출간 대기시간

(Specifies the time to wait between invocations)

Default : 20

Frequency

빈 캐쉬가 idle상태인 빈들을 확인하는 주기(s)

Default : 60

Capacity

Stateful SessionBean 컨테이너에 대한 bean pool의 크기

Default : 1000

BulkPassivate

한번에 passivate할 instance의 개수

Default : 100

  1. MESSAGE 설정

Table 28. MESSAGE 설정
항목(*는 필수값)설명비고

ResourceAdapter

Resource Adapter 지정

Default : Default JMS Resource Adapter

MessageListenerInterface

MessageListener 지정

Default : Javax.jms.MessageListener

ActivationSpecClass

Activation Spec Class 지정

Default : org.apache.activemq.ra.ActiveMQActivationSpec

InstanceLimit

Instance 최대 개수

Default : 10

Audit

WAS에서 발생한 이벤트로 수집/관리하는 기능이다.

수집된 이벤트 정보는 이벤트 대시보드에서 확인할 수 있다. 이벤트 대시보드 관련 내용은 Event Dashboard를 참고한다.

총 네 가지 타입의 Detection Rule을 설정해 이벤트를 수집할 수 있다.

Table 29. OOM Detection Rule
항목설명비고

Enable

Out Of Memory Error 발생을 감지한다

Default : true

Table 30. Stuck Thread Detection Rule
항목설명비고

Enable

Stuck Thread 발생을 감지한다

Default : false

LenaStuckThreadDetectionValve 는 server.xml 내에 기본적으로 설정되어 있으며, LenaStuckThreadDetectionValve 관련 설정은 SERVER > Server 선택 > General 탭 화면의 Stuck Thread 항목에서 할 수 있다.

사용자 요청의 처리 시간이 Threshold 설정 값을 초과한 경우 이벤트가 발생되어 Manager로 전송된다.

Table 31. Full GC Detection Rule
항목설명비고

Enable

Full GC 발생을 감지한다

Default : false

Table 32. Exception Detection Rule
항목설명비고

Enable

Out Of Memory Error 발생을 감지한다

Default : false

Exception Class Pattern

감지할 Exception 패턴을 지정한다. 해당 패턴의 Exception을 상속한 Exception도 검출한다. 최대 10개까지 지정 가능하며, * 패턴은 사용할 수 없다. ex) abc.dbc.ExampleException

Exclude Exception Class Pattern

감지에서 제외할 Exception 패턴을 지정한다. 최대 10개까지 지정 가능하며, * 패턴은 사용할 수 없다. ex) abc.dbc.ExampleException

Enable Full Stack

Exception이 여러 Cause를 가지고 있을 때, 요약 정보가 아닌 내용 전체를 표시할 지 여부

Default : true

Full Stack Max Line

Exception Stack Trace에서 표현할 Line 수. 각 Cause by 별로 설정한 수 만큼의 Line이 수집된다. 너무 큰 수로 지정하면 수집 및 저장관리에 부하가 발생할 수 있다

Default : 3

검출이 가능한 Exception 클래스는 Java 자체적인 라이브러리에 포함된 Exception이 아닌, Application이나 Framework의 Exception이다. 너무 많은 량의 이벤트가 발생하지 않도록 Exception 패턴을 정의해야 한다.

Audit 기능은 Enterprise Edition에서 제공되는 기능이다.

Config Tree

WAS의 설치경로 하위의 /conf 폴더 하위 설정 파일들을 파일편집기를 통해 관리 할 수 있다.

Node Agent를 실행하는 사용자가 WAS 설정 정보 파일의 접근 권한이 있어야 수정이 가능하다. 접근 권한이 없을 경우 파일 Write 권한이 없어 편집 할 수 없다는 메시지가 출력 된다.

History

설정 정보의 백업 및 복원 기능을 제공한다. 설정 정보를 수정하여 저장하면 유형별로 History를 관리한다. 수정 일시와 설정 파일 Type을 입력하여 검색한다.

보기(돋보기) 버튼 을 클릭하여 선택한 파일의 정보를 볼 수 있으며, Restore 버튼 을 클릭하여 해당 설정 파일로 복원할 수 있다.

4.3.9. Resource 관리

Server메뉴 하위의 Resources메뉴를 선택하면 해당 Server에 관련된 Resource정보를 관리할 수 있는 화면이 표시된다. 기본적으로 DataSource, JMS, JTA Resource에 대한 정보를 관리할 수 있다. (JMS, JTA Resource는 Enterprise Server일 경우에만 지원)

WAS에 Resource 를 설정하는 방법은 다음과 같다.

  • 추가 : New 버튼 을 클릭하여 Resource를 추가한다. (Datasource, JMS 가능)

  • 삭제 : Delete 버튼 을 클릭하여 Resource를 삭제한다. (Datasource, JMS 가능)

  • 가져오기 : Import 버튼 을 클릭하여 RESOURCE 메뉴에서 등록된 Resource를 가져온다. (Datasource, JMS, JTA 가능)

DataSource

WAS의 Application이 사용할 수 있는 JNDI DataSource를 관리하는 기능을 제공한다. JNDI를 설정하여 Server에서 실행되는 모든 Application이 공유하여 사용할 수 있으며, 각각의 Application에 JNDI 설정을 하여 사용할 수도 있다. Enterprise Edition의 경우 JTA를 지원하여 속성이 추가된다.

Server DataSource 설정

Server에서 실행되는 모든 Application이 공유하는 DataSource를 설정한다. Server에서 사용 가능한 DataSource의 목록을 조회할 수 있으며, DataSource의 등록, 수정, 삭제가 가능하다.

DataSource의 상태를 체크하기 위한 접속테스트도 수행할 수 있다.

DataSource의 속성은 아래와 같다. 최초 화면에서 보이지 않는 속성은 Expand all 버튼 을 클릭하면 표시된다.

Table 33. DataSource 속성
항목(*는 필수값)설명비고

Scope(*)

DataSource를 사용할 범위

다음과 같은 스코프를 제공함

  • Context: 모든 Application이 공유하도록 Datasource 정보가 공통 context 영역에 설정된다.

  • Global: GlobalNamingResource영역에 Datasource 정보가 설정되고, 어플리케이션 개별적으로 DataSource Link List에서 설정하여 사용한다.

  • Global+ResourceLink: GlobalNamingResource 영역에 Datasource정보가 설정되고 Datasource 링크는 공통 context영역에 설정된다.

JNDI Name(*)

Global DataSource의 JNDI명

Databases

공통으로 사용할 데이터소스의 정보를 설정

Resource Name

Databases의 이름

Address(Host/Port)

공통으로 사용할 아이피와 포트

DriverClassName

JDBC Driver 클래스명

URL(*)

JDBC URL

Username(*)

접속 사용자명

Password(*)

접속 패스워드

encryption을 체크할 경우 패스워드를 암호화하여 저장한다. 보안을 위해 암호화하는 것을 권장한다.

Encryption Level

인증 정보에 대한 암호화 범위 지정

Default : Password only

DefaultAutoCommit

Pool에서 생성된 Connection들의 자동 Commit 상태

Default : JDBC driver의 기본값

AutoReconnection

TestOnBorrow와 TestOnWhileIdle의 값을 설정할 때 사용.

true/false에 따라 두 값도 동일하게 설정됨.

User Definded 선택시 두 값을 사용자가 직접 설정 가능

InitialSize

Pool의 초기 Connection 수

Default : 10

MaxActive

Pool의 최대 Connection 수

Default : 100

MinIdle

최소 Idle Connection 수

Default : 10

MaxIdle

최대 Idle Connection 수

Default : 100

MaxWait

Pool에 가용한 Connection이 없을 경우 대기하는 최대시간(ms)

Default : 30000

MinEvictableIdleTimeMillis

해당 시간 이상 idle 상태로 Pool에 존재한 Connection은 제거 대상이 됨 (ms)

Default : 60000 (60s)

(XaDataSource = true로 설정하였을 시 1800000 (30m))

ValidationQuery

Connection 유효성 검증 쿼리

Default : null

ValidationInterval

Connection 유효성 검증 주기(ms)

Default : 3000

TestOnBorrow

Pool에서 커넥션을 꺼내기 전에 validationQuery에 설정된 쿼리문을 수행하여 커넥션의 유효여부 확인

Default : default

TestOnReturn

Pool에 커넥션을 반납하기 전에 validationQuery에 설정된 쿼리문을 수행하여 커넥션의 유효여부 확인

Default : default

TestWhileIdle

Idle 상태의 커넥션에 대해 validationQuery에 설정된 쿼리문을 수행하여 커넥션의 유효여부 확인

Default : default

LogValidationErrors

validation query 수행 후 오류 발생 시 오류 출력 여부

Default : default(false)

TimeBetweenEvictionRunsMillis

사용되지 않은 Connection을 추출하는 Thread 실행주기(ms)

Default : 5000

RemoveAbandoned

Connection 유실 검출 여부

Default : default

RemoveAbandonedTimeout

유실Connection을 판단하기 위한 Timeout 값(s)

Default : 60

LogAbandoned

Connection 유실 처리시 로깅여부

Default : default

AbandonWhenPercentageFull

Connection pool이 설정한 점유율을 초과해야지만 abandon을 수행함

Default : 0

JdbcInterceptors

유연하고 플러그 가능한 인터셉터를 사용하여 사용자 정의 기능을 추가할 수 있음

QueryTimeout 설정시 QueryTimeoutInterceptor(queryTimeout=시간(초)) 입력

Default 값이 true 또는 false가 아닌 default 인 경우, JDBC Driver의 기본값이 사용된다.

Enterprise Edition의 추가 속성은 아래와 같다.

Table 34. Enterprise Edition 추가 속성
항목(*는 필수값)설명비고

JtaManaged

JTA 사용여부

Default : false

XaDataSource

XA 사용여부

Default : false

  • XADataSource설정은 JTA가 설정되어야만 사용할 수 있으며, XADataSource를 설정하게 되면 validationInterval, logValidationErrors, abandonWhenPercentageFull 속성을 사용할 수 없다.

  • DataSource를 Context 범위로 설정하면 모든 Application이 공유한다.

  • EnterpriseServer에서 DataSource를 Context 범위로도 설정할 수 있으나, EJB에서는 Lookup이 불가능하다. EnterpriseServer에서는 Global + ResourceLink 범위로 설정하는 것을 권장한다.

  • Password 암호화 알고리즘은 AES를 사용하고 있다. 암호화를 위한 키 값은 Manager LENA Home 하위 /conf/repository/manager.conf 파일과 각 WAS Home 하위 /conf/advertiser.conf 내에서 “datasource.key=키값”으로 관리한다.

  1. Databases

URL 설정 시 공통을 사용할 정보를 Databases를 만들어 등록한다.

추가(+) 버튼 을 클릭하면 팝업창이 생성된다.

  1. Databases를 구분할 Resource Name을 입력한다.

  2. 자동으로 채워진 DriverClassName 을 확인한다. 변경할 필요가 있을 경우 변경한다.

  3. Address(아이피 및 포트)를 입력한 후 저장한다.

  1. JDBC driver Upload

Manager를 통해 JDBC Driver library를 upload 할 수 있다.

DataSource 상세 정보 하위의 Upload 버튼 을 클릭하면 아래와 같이 upload를 위한 화면이 출력된다.

  1. Search버튼을 통해 upload 할 파일을 선택한다. Upload 할 파일은 JDBC Driver library 이므로 JAR 형식의 파일만 선택할 수 있다.

  2. Upload 버튼을 클릭하면 선택한 파일이 target 디렉토리로 upload 된다.

  3. JDBC Driver 파일이 upload되는 경로는 ${SERVER_HOME}/lib/datasource이다.

  1. Connection Test

DataSource 상세 화면에서 Connection Test 버튼 을 클릭하면 설정된 DataSource에 대한 연결 테스트를 수행할 수 있다. 정상적으로 연결이 된 경우 "JDBC Connection is successfully tested" 라는 문구가 출력된다.

만약 "Driver Class[클래스명] does not exist." 라는 오류 문구가 출력될 경우, 해당 driver class가 정상적으로 업로드 되어 있으며 이에 대한 classpath가 설정되어 있는지 확인한다.

classpath는 WAS 상세 > Environment > JVM Settings 내에 추가한다.

설정 예
CLASSPATH="$\{CLASSPATH}:$\{CATALINA_HOME}/lib/datasource/ojdbc6.jar"
JMS

Enterprise Edition의 경우 JMS관련 Resource를 정의할 수 있다. Active MQ Resource Adapter, JMS Connection Factory, Queue, Topic설정을 각각 추가, 수정, 삭제할 수 있다.

Table 35. 주요 설정
항목(*는 필수값)설명비고

ID(*)

Resource의 식별자

Type(*)

Resource의 유형

다음과 같은 타입을 제공함

  • ActiveMQResourceAdapter

  • JMSConnectionFactory

  • Queue

  • Topic

  1. Active MQ Resource Adapter 설정

Table 36. 주요 설정
항목(*는 필수값)설명비고

BrokerXmlConfig

Broker 설정

Default : broker:(tcp://localhost:61616)?useJmx=false

ServerUrl

Broker 주소

Default : vm://localhost?waitForStart=20000&async=true

DataSource

Datasource for persistence messages

StartupTimeout

Startup 최대 대기시간(s)

Default : 10

  1. JMS Connection Factory 설정

Table 37. 주요 설정
항목(*는 필수값)설명비고

ResourceAdapter

사용할 Resource Adapter 지정

TransactionSupport

Global Transaction 여부 지정

다음과 같은 타입을 제공함

  • XA

  • LOCAL

  • NONE

PoolMaxSize

ActiveMQ broker에 연결되는 물리적인 커넥션의 최대 개수

Default : 10

PoolMinSize

ActiveMQ broker에 연결되는 물리적인 커넥션의 최소 개수

Default : 0

ConnectionMaxWaitTimeout

커넥션 최대 대기시간

Default : 5 Seconds

ConnectionMaxIdleTimeout

반납되기전 최대 idle시간

Default : 15 Minutes

  1. Queue 설정

Table 38. 주요 설정
항목(*는 필수값)설명비고

Destination

Queue의 이름 지정

Table 39. 주요 설정
항목(*는 필수값)설명비고

Destination

Topic의 이름 지정

JMS 기능은 Enterprise Edition에서 제공되는 기능으로 되는 기능으로 Enterprise 버전의 WAS(lena-enterprise-[버전].tar.gz)를 설치 시 사용 가능하다.

JTA

Enterprise Edition의 경우 Transaction Manager의 설정 변경 기능을 제공한다.

Transaction Manager의 설정을 기본 설정으로 사용하려면 Managed Type을 Auto로 선택한다. (설치 시 default)

Transaction Manager의 설정을 변경하고자 한다면 User Defined를 선택한다. (User Defined를 선택시 Recovery 옵션은 default로 "No"가 선택된다)

  1. 주요 설정

Table 40. 주요 설정
항목(*는 필수값)설명비고

Managed Type

User Defined Transaction Manager 여부 선택

Default : Auto

ID(*)

Transaction Manager의 이름

Default Timeout

Timeout 지정

Default : 10 minutes

Recovery

Transaction 오류 시 복원여부 설정

True를 선택한 경우 Logging 설정이 열림

  1. Transaction Recovery Logging Option

Table 41. Transaction 오류 시 복구를 위한 로깅 설정
항목(*는 필수값)설명비고

Directory

로그파일을 생성할 디렉토리 위치

Default : txlog

File Name

로그 파일 명

Default : howl

File Extension

로그 파일의 확장자

Default : log

Max Log Files

생성되는 로그파일의 최대 개수

Default : 2

Max Block Per File

파일당 최대 블록 수

Default : -1

Buffer Size

버퍼사이즈(kb)

Default : 32

Max Buffers

버퍼의 최대값

Default : 0

Min Buffers

버퍼의 최소값

Default : 4

Adler32 Checksum

Adler32 Checksum, Checksum Enabled 설정이 모두 "Yes"인 경우 Adler32 알고리즘을 사용하여 checksum을 계산

Default : Yes

Checksum Enabled

Buffer의 Contents를 Disk에 기록 전 체크

Default : Yes

Threads Waiting

대기하는 스레드의 최대 갯수

Default : -1

Flush SleepTime

ForceManager의 총 sleep 시간

Default : 50 Milliseconds

JTA 기능은 Enterprise Edition에서 제공되는 기능으로 되는 기능으로 Enterprise 버전의 WAS(lena-enterprise-[버전].tar.gz)를 설치 시 사용 가능하다.

4.3.10. Application 배포

목록

화면 상단의 SERVER 메뉴를 선택하여 Server 현황을 조회한다. 좌측 메뉴에서 배포할 Server의 Application을 선택한다. 배포가 완료된 Application의 목록을 조회하는 화면을 제공한다.

Application 목록의 항목은 아래와 같다.

Table 42. Application List 항목
항목설명비고

Type

배포할 Application의 형태

Enterprise WAS Type 인 경우만 다음과 같은 타입을 제공함

  • EJB

  • EAR

  • WAR

Base Name

Base 명

Context Path

Context 경로

DocBase

Application의 위치

Status

Application 상태

아래와 같은 상태를 제공함

  • Started(v)

  • Stop(ㅁ)

  • Error(!)

Action 버튼

아래와 같은 기능을 제공함

  • Undeploy(휴지통) 버튼

  • Application Start 버튼

  • Application Stop 버튼

  • Application Reload 버튼

View 버튼

아래와 같은 기능을 제공함

  • web.xml View(문서) 버튼

Deploy

Application 을 배포하기 위한 속성은 아래와 같다.

Table 43. Application 배포 속성
항목(*는 필수값)설명비고

Application Type

배포할 Application의 형태

Enterprise WAS Type 인 경우만 다음과 같은 타입을 제공함

  • EJB

  • EAR

  • WAR

Context Path(*)

Context 경로

unpackWAR

WAR파일을 전개하고 나서 실행할 것인지의 여부.

값이 false인 경우, WAR 파일의 압축을 풀지 않고 배포

Default : true

DocBase(*)

Application의 위치

Upload 선택(파일) 버튼 을 통해 파일을 업로드 할 수 있음

Application Upload

별도의 배포 시스템이 없는 경우 Manager를 통해 application을 upload 할 수 있다.

  1. 서버를 선택한 후 Applications 를 선택하여 Application 화면으로 이동한다.

  2. Applications 화면 하단의 Application Deploy 영역에서, DocBase 항목 우측 끝에 있는 Upload 선택(파일) 버튼 을 클릭하면 파일시스템 화면이 출력된다.

  3. upload 할 target 디렉토리(Server 쪽 Host)를 선택한다.

  4. Upload 버튼 을 클릭하면 application 파일을 선택할 수 있는 팝업이 생성된다.

  5. 배포할 application 파일을 선택하고 Upload 버튼 을 클릭하면 선택한 파일이 target 디렉토리로 upload 된다.

Import

Import 버튼 을 클릭하여, [Resource] 메뉴에서 등록한 Application 정보를 가져와 배포할 수 있다.

설정 정보 관리

Application 목록조회 화면에서 Application Name을 선택하면 Application 설정 관리화면을 조회할 수 있다. Application Descriptor 와 DataSource에 대한 설정 및 관리 기능을 제공한다.

Application 설정 변경은 선택한 Server에서만 가능하다.

Application Settings

Application Descriptor에 설정된 정보를 관리한다.

뒤로가기(←) 버튼 을 클릭하여 Application 목록화면으로 돌아갈 수 있다. Expand all 버튼 을 클릭하여 Context의 추가적인 속성을 설정할 수 있다.

DocBase와 ContextPath는 수정할 수 없으며, 속성의 자세한 정보는 아래와 같다. 최초 화면에서 보이지 않는 속성은 Expand all 버튼 을 클릭해 확인할 수 있다.

Table 44. Application Setting
항목(*는 필수값)설명비고

DocBase(*)

Application의 Document Base

Context Path(*)

Context 경로

unpackWAR

WAR파일을 전개하고 나서 실행할 것인지의 여부.

값이 false인 경우, WAR 파일의 압축은 풀리지 않고, 웹 애플리케이션은 단지 압축된 채로 재배치

Default : true

reloadable

Application 변경 시(Class File) 재 반영 여부

privileged

Container Servlet의 사용 여부

cookies

session identifier 통신에 cookie 사용 여부

useHttpOnly

client side에서 스크립트를 활용하여 session ID로의 접근 차단 여부

sessionCookieDomain

설정했을 경우 웹 어플리케이션에서 설정된 모든 도메인을 덮어씀. 설정하지 않을 경우 웹 어플리케이션에 의해 구분된 domain이 사용됨

sessionCookieName

설정하면 해당 이름으로 모든 세션 쿠키가 생성됨

Default : JSESSIONID

sessionCookiePath

설정할 경우 웹 어플리케이션은 해당 경로를 사용

useNaming

J2EE 플랫폼을 위한 JNDI InitialContext를 사용하기 위해 설정

Default : true

Add Attribute 버튼 을 사용하여 속성 값을 추가할 수 있다.

DataSource Link List

Global DataSource를 Application에서 사용할 수 있도록 설정 기능을 제공한다.

DataSource 링크 관리의 속성은 아래와 같다.

Table 45. DataSource 링크 관리 속성
항목(*는 필수값)설명

Name(*)

Application에서 사용할 JNDI 이름

JNDI Name(*)

Global DataSource의 JNDI이름

UserName

DataSource 접속 사용자 명

URL

JDBC URL

Description

DataSource에 대한 설명

+ 아이콘

New 버튼, 수정(연필) 버튼 을 클릭하여 선택된 DataSource정보가 변경 중임을 표시

- 아이콘

삭제(휴지통) 버튼 을 클릭하여 선택된 DataSource 정보가 삭제됨을 표시

New 버튼 을 클릭하면 신규 설정을 추가할 수 있고, Save 버튼 을 클릭하면 변경된 설정이 저장된다.

WAS에 설정된 Datasource 중 Scope가 Global 또는 Global + ResourceLink로 되어있는 Datasource가 신규 설정시 JNDI Name의 선택항목으로 나온다.

4.4. Web Server

Web Server를 관리하기 위한 화면을 제공한다. Node에 설치한 Web Server의 등록, 수정, 삭제가 가능하며, 시작과 종료를 수행할 수 있다.

4.4.1. 목록

Web Server List를 통하여 각 Web Server를 관리할 수 있다.

server 4 web server

Web Server의 속성은 아래와 같다.

Table 46. Web Server 속성
항목(*는 필수값)설명비고

Status

Server의 상태

아래와 같은 상태를 제공함

* Started(v) * Stop(ㅁ) * Error(!)

Name(*)

Server의 이름

Address

Server의 IP주소

Server ID

Server의 ID

HTTP Port

HTTP 포트번호

HTTPS Port

HTTPS 포트번호

SSL

Shell 실행시 SSL 기반의 패스워드 사용여부

Web Server에 SSL 관련 설정을 해야함

Server의 시작 및 종료

+ 아이콘

Register 버튼 또는 - 버튼 을 클릭하여 선택된 Server 정보가 변경 중임을 표시

- 아이콘

삭제(휴지통) 버튼 을 클릭하여 선택된 Server정보가 삭제됨을 표시

Action(…​) 버튼 을 클릭하면 Forced Stop과 Forced Restart를 수행할 수 있는 메뉴 제공

4.4.2. Install

  1. Install 버튼 을 클릭하여 Server의 설치를 준비한다.

  2. Server ID와 Service Port를 입력한다.

  3. Save 버튼 을 클릭하여 저장한다.

Node에 실제 설치되어 있는 Server와 Manager에서 관리하는 Server의 정보에는 차이가 있을 수 있다. (console기반 설치 시)

Server ID 중복 오류가 발생하는 경우, Register 기능을 이용하여 설치된 Server 정보를 추가로 확인해야 한다.

4.4.3. Clone

  1. Clone 버튼 을 클릭하여 Web Server의 복제를 준비한다.

  2. Node List를 선택하여 복제할 Server를 선택한다.

  3. Clone Server ID와 Service Port를 입력한다.

    (Include External Source는 다른 노드로 서버를 복제하는 경우 사용가능하며, 복제할 서버의 Document Root 디렉토리에 있는 파일도 함께 복제하는지 여부를 설정한다.)

  4. Save 버튼 을 클릭하여 저장한다.

Node에 실제 설치되어 있는 Server와 Manager에서 관리하는 Server의 정보에는 차이가 있을 수 있다. (console기반 설치 시)

Server ID 중복 오류가 발생하는 경우, Register 기능을 이용하여 설치된 Server 정보를 추가로 확인해야 한다.

4.4.4. Register

  1. Register 버튼 을 클릭한다.

  2. 등록하려는 Server를 선택한다.

  3. Save 버튼 을 클릭하여 저장한다.

4.4.5. 수정

  1. 수정(연필) 버튼 을 클릭하여 Server 정보를 수정 가능한 상태로 변경한다.

  2. Server의 속성을 수정한다.

  3. Save 버튼 을 클릭하여 저장한다.

4.4.6. 삭제

  1. 삭제(휴지통) 버튼 을 클릭하여 Server정보를 삭제 가능한 상태로 변경한다.

  2. Save 버튼 을 클릭한다.

  3. OK 버튼 을 누르면 삭제 유형을 선택하는 창이 출력된다.

    • Unregister : Manager DB에서만 해당 Server 정보를 삭제하고 물리적인 Server engine은 유지 (추후 Register 버튼 을 통해 다시 등록 가능)

    • Uninstall : Manager DB에서 해당 Server 정보를 삭제하고 물리적인 Server engine도 삭제

  1. Uninstall 선택시, 로그 디렉토리 삭제여부를 묻는 창이 출력된다.

Server Cluster에 묶여있는 서버는 삭제할 수 없다.

ADMIN > Preference > Manager Environment 메뉴의 Manager Configuration 영역에서 use Server Delete Protection 값을 true로 설정하는 경우 Manager에서 서버가 uninstall되는 것을 방지 할 수 있다.

4.4.7. Start/Stop

Single Start/Stop

  1. Stop 버튼 을 클릭하여 Server를 종료한다.

  2. Start 버튼 을 클릭하여 Server를 시작한다.

Server를 중지시 General 탭의 Stop Mode 에 따라 종료 방식이 달라진다.

Stop : 기본 종료 옵션으로 현재 서비스중인 작업을 보장하지 않는다.
Graceful Stop : 현재 서비스중인 작업을 완료한 후 종료한다. (Window 에서는 서비스 보장하지 않음)

시작 가능한 상태일 경우에만 Start 버튼 이 활성화 된다.

Multi Server Start/Stop

  1. 시작 혹은 종료하고자 하는 복수개의 Server를 선택한다.

  2. Server 목록 하단의 Multi Action 버튼 을 클릭한다.

  3. 팝업창에서 Action Type을 선택 후 Action 버튼 을 클릭하여 복수개의 Server에 대한 시작 혹은 종료 작업을 수행한다.

Forced Stop/Restart

  1. Server 목록 가장 우측의 …​ 버튼 을 클릭한다.

  2. 강제 종료 혹은 강제 재시작을 수행한다.

4.4.8. 설정 정보 관리

Web Server의 설정 정보를 변경하는 기능을 제공한다. Web Server 목록에서 Server를 선택하면 설정 정보를 관리하는 화면으로 이동한다.

General

Web Server의 일반적인 설정 값과 Connection, Process 정보를 편집할 수 있다.

Web Server의 설정 정보는 저장 시 설정 파일에 대한 Validation을 수행하게 되어 있으며, 설정 파일 오류로 인한 Server 기동 장애가 발생을 최소화하고 있다.

설정 파일 오류 시 파일이 저장되지 않고 오류 메시지가 출력된다

오류 메시지 예
AH00526: Syntax error on line 253 … Argument for 'Require all' must be 'granted' or 'denied'

설정 정보의 상세 내용은 다음과 같다.

  1. Server Info (env.sh과 /conf/httpd.conf 파일 관리)

Table 47. Server Info
항목(*는 필수값)설명비고

HTTP Port(*)

HTTP Port

HTTPS Port(*)

HTTPS Port

Staging HTTP Port

Staging 모드로 기동 시 사용하는 서비스 포트

Graceful restart 시에 이용됨

LENA는 기본 nostage 모드

Staging HTTPS Port

Staging 모드로 기동 시 사용하는 HTTPS 포트

Graceful restart 시에 이용됨

LENA는 기본 nostage 모드

Install Path

Server 설치 경로

Document Root(*)

Web Server에서 제공하는 문서들이 저장되어 있는 기본 폴더 경로

Welcome Page

웹사이트의 초기페이지 문서로 어떤 파일을 사용할 것인지 정의

Stop Mode

WEB 서버 종료시 참조하는 옵션

Stop : 기본 종료 옵션으로 현재 서비스중인 작업을 보장하지 않는다.

Graceful Stop : 현재 서비스중인 작업을 완료한 후 종료한다. (Window 에서는 서비스 보장하지 않음)

Directory/Path

어떤 서비스와 기능을 허용/거부 할지를 설정할 웹 문서들이 있는 디렉토리 경로

Directory/Options

지정한 디렉토리 이하의 모든 파일과 디렉토리들에 적용할 접근 제어 설정

Indexes : welcome page를 찾을 수 없을 때, Document Root 하위의 파일 목록을 보여주는 것을 방지

FollowSymLinks : Document Root 하위에 기존의 웹문서 이외의 파일시스템에 심볼릭링크로 접근 하는 것을 방지

Directory

/AllowOverride

Document Root 하위 디렉토리 별 리소스 접근 제어 설정 파일 (일반적으로 AccessFileName : .htaccess)에 대하여 어떤 지시자 사용을 허가할 것인지 설정

다음과 같은 유형이 존재함

* None : 어떠한 지시자도 허용하지 않음 * All : 모든 지시자 사용가능 * AuthConfig : 사용자 인증 지시자 허용 * FileInfo : 문서 유형 제어 지시자 허용 * Indexes : 디렉토리 Indexing 제어 지시자 허용 * Limit : 호스트 접근 제어 지시자 허용

Directory/Require

인증된 사용자가 허가된 Action을 수행하는지 검증

  1. Connection Info (/conf/extra/httpd-default.conf 파일 관리)

Table 48. Connection Info
항목(*는 필수값)설명비고

Timeout(*)

클라이언트와 Server간에 연결 후 일정 시간 동안 아무 이벤트가 발생하지 않았을 때 Server가 기다리다가 연결을 끊을 시간(s)

Default : 60

KeepAlive(*)

특정 한 프로세스가 특정 사용자의 요청작업을 계속해서 처리할지 여부

Default : On

MaxKeepAliveRequests(*)

KeepAlive가 On일 때 유효한 값으로 하나의 프로세스가 특정 사용자의 요청을 지정한 횟수만큼 처리

이 값을 넘어서면 해당 프로세스는 죽고 다른 프로세스가 요청을 처리함

Default : 100

KeepAliveTimeout(*)

KeepAlive가 On 일 때 유효한 값으로 설정한 시간 동안 요청이 없으면 연결을 끊기 위해 타임아웃 시킴(s)

Default : 5

RequestReadTimeout(*)

사용자로부터 request header와 body를 받기 위해 기다리는 시간

설정된 시간 안에 받지 못하면 408 REQUEST TIME OUT 에러를 보냄

Default : header=20-40,MinRate=500 body=20,MinRate=500

  1. Process Info (/conf/extra/httpd-mpm.conf 파일 관리)

Table 49. Process Info
항목(*는 필수값)설명비고

StartServers(*)

Web Server 기동 시 초기화 되는 Server 프로세스 수

Default : 2

ServerLimit(*)

MaxClients가 생성할 수 있는 최대 프로세스 값

Default : 8

ThreadLimit(*)

ThreadsPerChild의 설정 가능한 최대 값

Default : 128

MinSpareThreads(*)

Idle 상태에서 Idle Thread 개수가 이 값보다 적을 때 Thread가 이 값까지 늘어나 유지

Default : 128

MaxSpareThreads(*)

Idle 상태에서 Idle Thread 개수가 이 값보다 많을 때 Thread가 이 값까지 줄어들어 유지

Default : 256

ThreadsPerChild(*)

각각의 자식 프로세스가 생성하는 Thread 수

Default : 128

MaxRequestWorkers(*)

전체 자식 프로세스가 생성할 수 있는 최대 Thread 수

Default : 1024

MaxConnectionPerChild(*)

자식 프로세스가 서비스 할 수 있는 최대 요청 수. 이 값만큼 요청을 처리한 후 종료한다.

Default : 0 (0: 제한없음)

Web Server 가 mpm event 방식을 사용할 수 있는 환경인 경우 Process Info 설정을 간편하게 할 수 있는 기능을 제공한다.

server 4 web server process info

Web Server 의 Process Info 설정 시 우측 상단의 Auto Calculation 을 체크하면 기본 제공되는 설정 값 유효성 검사 외에 간편 자동계산 기능이 제공된다.

규칙유효성 검사자동 계산

StartServer ≤ ServerLimit

●

-

ThreadsPerChild ≤ ThreadLimit

●

-

ThreadsPerChild + MinSpareThreads ≤ MaxSpareTheads

●

ThreadsPerChild 변경 시 MinSpareThreads, MaxSpareThreads 자동 계산

ServerLimit × ThreadLimit ≤ MaxRequestWorkers

●

ServerLimit, ThreadLimit 변경 시 MaxRequestWorkers 자동 계산

  1. Pagespeed Info

Table 50. Pagespeed Info
항목(*는 필수값)설명비고

Enabled(*)

mod_pagespeed를 적용하여 Web Server가 제공하는 Resource에 대한 최적화를 수행하여 사이트 속도를 높일지 여부

Default : off

다음과 같은 옵션을 제공함

  • on : Resource들에 대해 최적화 허용

  • off : 추가적인 최적화를 중지하나, 기존에 최적화 되어있는 Resource들에 대한 접근 허용

  • unplugged : 최적화 중지 및 접근 불허

RewriteLevel(*)

모듈이 rewrite할 필터의 Level 설정

Default : default(CoreFilters)

다음과 같은 옵션을 제공함

  • CoreFilters : 사전에 대부분의 웹사이트에서 안전하다고 생각하는 필터가 포함되어있음

  • OptimizeForBandwidth : 안전성을 강화하며, Pagespeed를 인식하지 못하는 사이트에서 사용하기 적합

  • PassThrough : 필터를 전부 수동으로 입력

FileCachePath(*)

Caching 될 File들이 저장되는 디렉토리의 경로

LogDirPath(*)

Log를 기록할 디렉토리의 경로

EnableFilters

사용할 필터들의 목록

DisableFilters

사용하지 않을 필터들의 목록

Allow URI

rewrite를 허용할 Resource들의 와일드카드(*)를 포함한 URI

예) /.js

Disallow URI

rewrite를 허용하지 않을 와일드카드(*)를 포함한 URI

설정을 변경할 경우 수정된 사항의 반영을 위하여 Server의 재기동이 필요하다.

Connector

Web Server의 Connector정보와 Load Balancer정보를 편집할 수 있다. Connector Info 영역의 정보는 Web Server 내에 설정된 Load Balancer의 기본 설정 값을, Load Balancer영역은 Web Server와 WAS를 연계하는 정보를 관리한다.

설정 정보의 상세 내용은 다음과 같다.

  1. Connector Info (/conf/extra/httpd-jk.conf와 /conf/extra/workers.properties 파일 관리)

Table 51. Connector Info
항목(*는 필수값)설명비고

Type(*)

Web Server와 WAS가 통신할 때 사용하는 프로토콜

ajp 13

Load Balancing Factor(*)

WAS의 부하 분산 지수. 즉, 작업량 할당 비율

Default : 1

Socket Timeout(*)

JK와 WAS 간에 응답 대기 시간(TCP socket 내부적인 상태에 대한 timeout을 의미, s)

Default : 300

Socket Connect Timeout(*)

JK와 WAS 간의 socket 연결 대기시간

Default : 5000

Socket Keepalive(*)

Web Server와 WAS 간에 방화벽이 있는 경우 inactive 상태인 connection은 버리게 되어 있는데 OS에 keep alive 메시지를 보내서 방화벽이 inactive connection을 잘라버리는 것을 막을지 여부 설정

Default : true

Connect Timeout(*)

JK와 WAS 간에 연결이 완료된 후, ajp13 프로토콜에서의 cping request에 대한 cpong respond 대기 시간(ms)

Default : 10000

Connection Pool Size(*)

JK와 WAS 간에 커넥션을 cache하는 크기

Default : 128

Connection Pool Min Size(*)

JK와 WAS 간에 커넥션을 cache하는 최소 크기

Default : 32

Connection Pool Timeout(*)

Connection pool에서socket을 close 하기까지 open된 socket을 유지하는 시간

WAS에서 connectionTimeout 설정과 같이 설정해야 함

Log Level(*)

에러 로그 파일의 기록 내용을 얼마나 자세히 기록할지 지정

Default : error

Log Format(*)

로그 파일에 어떤 포맷으로 로그를 남길지 설정

Status(*)

Server 상태 모니터링 설정값 셋팅 여부

Enable 선택시 Status Url과 Allow IP를 설정할 수 있음

Default : Enable

Status Url(*)

Server 상태 모니터링 URL

Default : /jk-status/

Status Allow IP(*)

Server 상태 모니터링 URL에 접근 가능한 IP

Default : 127.0.0.1

  1. Load Balancer Info

(/conf/extra/workers.propertes, /conf/extra/uriworkermap/uriworkermap_\{Virtual Host ID}.properties, /conf/extra/vhost/\{Virtual Host ID}.conf 파일 관리)

Table 52. Load Balancer Info
항목(*는 필수값)설명비고

LB ID(*)

Load Balancer명

Sticky Session

Session ID를 기반으로 라우팅을 지원할지 여부

Default : true

Status Enabled

Server 상태 모니터링 사용여부

동일 Virtual Host에 적용된 Load Balancer에 대해서는 일괄 적용됨

Default : N

Virtual Host ID(*)

Load Balancer를 적용할 Virtual Host ID

Virtual Host 탭을 통해 관리됨

Session Cookie

Session Cookie Name을 변경하고자 할 경우 설정 (WAS에서 Session Cookie Name 변경시 같이 변경해줘야 함)

Default: JSESSIONID

URI Patterns(*)

Web server로 들어온 요청들에 대해 URI패턴을 검사하여 WAS로 전달하는 uri mapping을 정의

Method(*)

Load Balancer 가 부하를 분산하기 적절한 worker를 판별하는데 사용할 메서드

다음과 같은 타입을 제공함

  • R[equest] : 요청수가 가장 적은 worker 선택. (Default)

  • S[ession] : 연결된 세션이 가장 적은 worker 선택

  • N[ext] : S[ession]과 비슷하지만 더 적은 수의 session을 분산해야 하는 경우 선택

  • T[raffic] : JK와 AJP커넥터 사이에 네트워크 트래픽이 가장 작은 worker 선택

  • B[usyness] : 요청 수를 기반으로 가장 부하가 적은 worker 선택 

Redirect

해당 worker가 error 상태일 때 받은 요청을 대신 처리할 failover worker를 설정

Default : Round Robin

LB Factor

작업량 할당 비율. 해당 worker가 얼마나 많은 일을 할지 정의 (5로 설정할 경우 1로 설정한 다른 worker보다 5배 더 많은 request를 받음)

URI Pattern 정보는 /conf/extra/uriworkermap/uriworkermap_\{Virtual Host ID}.properties 파일에 관리된다.

WAS List의 [+] 버튼을 통해 Load Balancer와 연계되는 WAS를 추가할 수 있으며, 추가된 WAS의 ⓧ 버튼을 통해 해당 WAS를 제외할 수 있다.

연계 WAS 정보는 /conf/extra/workers.properties 파일에 관리된다.

설정을 변경할 경우 수정된 사항의 반영을 위하여 Server의 재기동이 필요하다

Virtual Host

Web Server의 Virtual Host 정보를 등록/수정/삭제할 수 있다.

New 버튼, Delete 버튼 을 통해 Virtual Host를 등록/삭제할 수 있다.

1개 이상의 Load Balancer를 적용한 Virtual Host는 삭제할 수 없다. 만약 해당 Virtual Host를 삭제하려면, 먼저 Connector 탭을 통해 Load Balancer의 Virtual Host ID를 다른 Virtual Host ID로 변경해야 한다.

SSL Enabled와 Rewrite Enabled를 체크한 경우 아래와 같이 상세 항목 영역이 추가로 출력된다.

설정 정보의 상세 내용은 다음과 같다.

(/conf/extra/vhost/\{Virtual Host ID}.conf, /conf/extra/rewrite/rewrite_\{Virtual Host ID}.conf, /conf/extra/ssl/ssl_\{Virtual Host ID}.conf 파일 관리)

Table 53. Virtual Host 설정 정보
항목(*는 필수값)설명비고

Virtual Host ID(*)

Virtual Host 이름

Port(*)

해당 가상호스트가 사용하는 HTTP Port

DocumentRoot(*)

해당 가상호스트의 홈페이지 디렉토리 위치

Server의 DocumentRoot 변수인 ${DOC_ROOT}를 활용하여 동일하게 혹은, 그 하위로 지정가능

ServerName(*)

해당 가상호스트의 도메인 명

ServerAlias

해당 가상호스트가 사용하는 ServerAlias

와일드카드 문자 포함 가능(*.example.com)

ErrorLog(*)

해당 가상호스트의 웹 에러로그 파일 위치

CustomLog(*)

해당 가상호스트의 웹 로그파일 위치

Directory/Path

DocumentRoot에서 지정한 경로

Directory/Options

지정한 디렉토리 이하의 모든 파일과 디렉토리들에 적용할 접근 제어 설정

-Indexes는 welcome page를 찾을 수 없을 때, Document Root 하위의 파일 목록을 보여주는 것을 방지

-FollowSymLinks는 Document Root 하위에 기존의 웹문서 이외의 파일시스템에 심볼릭링크로 접근 하는 것을 방지

Directory/AllowOverride

Document Root 하위 디렉토리 별 리소스 접근 제어 설정파일 (일반적으로 AccessFileName : .htaccess)에 대하여 어떤 지시자 사용을 허가할 것인지 설정

다음과 같은 유형을 제공함

  • None : 어떠한 지시자도 허용하지 않음

  • All : 모든 지시자 사용가능

  • AuthConfig : 사용자 인증 지시자 허용

  • FileInfo : 문서 유형 제어 지시자 허용

  • Indexes : 디렉토리 Indexing 제어 지시자 허용

  • Limit : 호스트 접근 제어 지시자 허용

Directory/Require

인증된 사용자가 허가된 Action을 수행하는지 검증

Rewirte Enabled

Rewrite사용여부

Rewirte Conf

Rewrite관련 상세 설정. 지정한 Rewrite Condition에 따라 Rewrite Rule에 설정한 rule대로 rewrite함

Proxy Enabled

Proxy 사용여부

conf/extra/proxy 디렉토리에 설정파일이 위치한다. 필요한경우 ProxyPreserveHost 를 셋업하면 요청의 host 명을 유지할 수 있다. default 값은 off 이며 필요한 경우 on 한다. (ex: application 에서 redirect 사용 시)

Proxy Pass Match

backend와 연동하기 위한 정규식 패턴과 Target 서비스 도메인주소

DNS Lookup Interval

DNS Lookup 주기(s)

Default: 10

SSL Enabled

SSL 사용여부

SSLPort(*)

HTTPS Port

SSLCertificateFile(*)

SSL 인증서 경로

SSLCertificateKeyFile(*)

SSL인증서 Key파일 경로

SSLCertificateChainFile

File of PEM-encoded Server CA Certificate

SSLCACertificateFile

ROOT인증서 경로

Https Redirect Enabled

Http→Https Redirect 사용여부

SSL Log Separation

SSL Log 설정 분리 사용여부

SSLErrorLog

SSL Error Log 설정

SSLCustomLog

SSL Custom Log 설정

설정을 변경할 경우 수정된 사항의 반영을 위하여 Server의 재기동이 필요하다

Logging

Web Server의 로그설정 정보를 편집할 수 있다.

설정 정보의 상세 내용은 다음과 같다.

  1. Log Home

Table 54. Log Home
항목(*는 필수값)설명비고

Log Home(*)

Log Home 경로

default 선택시 서버설치디렉토리 하위 logs 폴더로 설정, custom 선택시 Log Home Prefix항목에서 로그디렉토리 홈 경로 입력가능

Retention Days(*)

로그 최대 보관 일수

Default : 0(무제한)

  1. Error Log

Web server가 진단정보와 request를 처리하는 도중에 발생한 오류를 기록할 때 사용된다. Server가 시작하거나 동작하는데 문제가 발생시 여기에 설정된 위치의 파일을 먼저 확인한다.

Table 55. Error Log
항목(*는 필수값)설명비고

Location(*)

Web server의 에러로그파일 위치를 지정

Log Level(*)

에러로그파일의 기록내용을 얼마나 자세하게 기록할 지 지정

  1. Custom Log

로그파일 이름과 형식을 설정한다. 환경변수를 사용하여 request의 특징에 따라 선택적으로 로그를 남길 수 있다.

Table 56. Custom Log
항목(*는 필수값)설명비고

Location(File|Pipe)(*)

File: 에러로그 파일 위치

Pipe: 파이프 문자 "|" 뒤에 로그 정보를 표준 입력으로 받을 프로그램 경로

Format|Nickname(*)

로그파일에 기록할 내용

Log Format으로 정의한 nickname을 쓰거나 직접 로그 포맷을 작성

Env

Server의 환경 변수 유무에 따라 로그를 기록할지 여부 작성

예를 들어, 영어권 사용자의 요청과 비영어권 사용자의 요청을 다른 로그파일에 기록하고 싶은 경우 다음과 같이 설정할 수 있다.

설정 예
Location Format Env

logs/english_log common english

logs/non_english_log common !english

  1. Log Format

로그파일에 사용할 형식을 설정한다.

Table 57. Log Format
항목(*는 필수값)설명비고

Format(*)

로그파일에 어떤 포맷으로 로그를 남길지 설정

Nickname(*)

CustomLog에서 사용할 로그포맷 명

  1. Log Format with logio

Table 58. Log Format with logio
항목(*는 필수값)설명비고

Format(*)

로그파일에 어떤 포맷으로 로그를 남길지 설정

%I와 %O 변수를 사용해 request와 head를 포함하여 보내고 받는 byte 측정이 가능

Nickname(*)

CustomLog에서 사용할 로그포맷 명

combinedio는 mod_logio_module이 로드되어 있어야 함

  1. Env

Request의 조건에 따라 환경변수를 설정할 때 사용한다.

Table 59. Env
항목(*는 필수값)설명비고

Attribute(*)

HTTP 요청 헤더(ex: Host, User-Agent, Referer, Accept-Language), 요청 속성 중 하나(Remote_Host, Remote_Addr, Server_Addr, Request_Method, Request_Protocol, Request_RUI) 또는 요청과 연관된 환경 변수 이름

Regex(*)

Perl 호환 정규식

Env-variable[=value](*)

설정할 변수명과 설정값(optional)

Varname, !varname 또는 varname=value

Case

Env-variable에 대소문자 구분할지 여부

With case : 대소문자 구분

No case : 대수문자 구분없음

설정을 변경할 경우 수정된 사항의 반영을 위하여 Server의 재기동이 필요하다

Environment

JVM 옵션, Start Shell의 설정 등을 관리하는 화면을 제공한다. 파일 에디터를 통해 수정한 후 Save 버튼 을 클릭하여 저장한다.

  • Custom Settings ($CATALINA_HOME/bin/customenv.sh): 사용자 커스텀 환경변수 설정

  • Start Shell ($CATALINA_HOME/env.sh) - Server 시작을 위한 Shell Script

기본적으로 설정을 수정할 수 없도록 되어 있다. 수정하고 싶은 경우 ADMIN > Manager Environment > Manager Configuration 항목에서 설정 버튼 을 클릭해 아래 설정을 false 로 변경한다.

server.environment.envshell.readonly=false
Config Tree

Web Server의 ${SERVER_HOME}/conf 디렉토리 하위 설정파일들을 파일편집기를 통해 관리 할 수 있다.

Node Agent를 실행하는 사용자가 Web Server 설정 정보 파일의 접근 권한이 있어야 수정이 가능하다. 접근 권한이 없을 경우 파일 Write 권한이 없어 편집 할 수 없다는 메시지가 출력 된다.

History

설정 정보의 백업 및 복원 기능을 제공한다. 설정 정보를 수정하여 저장하면 History를 관리한다. 수정 일시를 입력하여 검색한다.

보기(돋보기) 버튼 을 클릭하여 선택한 파일의 정보를 볼 수 있으며, Restore 버튼 을 클릭하여 해당 설정파일로 복원할 수 있다.

4.5. Session Server

Session Server를 관리하기 위한 화면을 제공한다. Node에 설치한 Session Server의 등록, 수정, 삭제가 가능하며, 시작과 종료 Shell을 실행할 수 있다.

4.5.1. 목록

Session Server List를 통하여 각 WAS를 관리할 수 있다.

server 5 session server
Figure 7. Session Server List

Session Server의 속성은 아래와 같다.

Table 60. Session Server 속성
항목(*는 필수값)설명비고

Status

Session Server의 상태

아래와 같은 상태를 제공함

* Started(v) * Stop(ㅁ) * Error(!)

Name(*)

Session Server의 이름

Address

Session Server의 IP주소

Server ID

Server의 ID

Port

Service 포트번호

Server Type

Session Server의 유형

  • Standalone

  • Embedded

Start/Stop

Server의 시작 및 종료

+ 아이콘

+Register 버튼 또는 연필 버튼 을 클릭하여 선택된 Server 정보가 변경 중임을 표시

- 아이콘

삭제(휴지통) 버튼 을 클릭하여 선택된 Server 정보가 삭제됨을 표시

Action(…​) 버튼 을 클릭하면 Restart를 수행할 수 있는 메뉴 제공

Session Server는 Enterprise Edition에서 제공되는 기능으로 되는 기능으로 Enterprise 버전의 WAS(lena-enterprise-[버전].tar.gz)를 설치 시 사용 가능하다.

4.5.2. Install

  1. Install 버튼 을 클릭한다.

  2. Server ID와 Service Port, Mirror Server IP/Port를 입력한다.

  3. Save 버튼 을 클릭하여 저장한다.

Node에 실제 설치되어 있는 Server와 Manager에서 관리하는 Server의 정보에는 차이가 있을 수 있다. (console기반 설치 시)

Server ID 중복 오류가 발생하는 경우, Register 기능을 이용하여 이전에 설치된 Server 정보를 확인한다.

4.5.3. Register

  1. Register 버튼 을 클릭한다.

  2. 등록할 Server를 클릭한다.

  3. Save 버튼 을 클릭하여 저장한다.

4.5.4. 수정

  1. 수정(연필) 버튼 을 클릭하여 Server 정보를 수정 가능한 상태로 변경한다.

  2. Server의 속성을 수정한다.

  3. Save 버튼 을 클릭하여 저장한다.

4.5.5. 삭제

  1. 삭제(휴지통) 버튼 을 클릭하여 Server 정보를 삭제 가능한 상태로 변경한다.

  2. Save 버튼 을 클릭한다.

  3. OK 버튼 을 누르면 삭제 유형을 선택하는 창이 출력된다.

    • Unregister : Manager DB에서만 해당 Server 정보를 삭제하고 물리적인 Server engine은 유지 (추후 Register 버튼 을 통해 다시 등록 가능)

    • Uninstall : Manager DB에서 해당 Server 정보를 삭제하고 물리적인 Server engine도 삭제

  1. Uninstall 선택시, 로그 디렉토리 삭제여부를 묻는 창이 출력된다.

ADMIN > Preference > Manager Environment 메뉴의 Manager Configuration 영역에서 use Server Delete Protection 값을 true로 설정하는 경우 Manager에서 서버가 uninstall되는 것을 방지 할 수 있다.

4.5.6. Start/Stop

  1. Stop 버튼 을 클릭하여 Server를 종료한다.

  2. Start 버튼 을 클릭하여 Server를 시작한다.

시작 가능한 상태일 경우에만 Start 버튼 이 활성화 된다.

4.5.7. 설정 정보 관리

General

Server의 설정 정보를 변경하는 기능을 제공한다. Session Server 목록에서 Server를 선택하면 설정 정보를 관리하는 화면으로 이동한다.

환경설정에서 변경 가능한 속성은 아래와 같다.

  1. Configuration

Table 61. Configuration
항목(*는 필수값)설명비고

Primary Host(*)

Server의 Service Host(IP)

Primary Port(*)

Server의 Service Port

Mirror Server Host(*)

Pair Server의 Host(IP)

Mirror Serror Port(*)

Pair Server의 Service Port

Share session in applications

Multi Applications 간 Session 공유 여부 설정.

WAS에서도 이 항목을 동일한 값으로 처리해야 적용됨.

standalone에서만 가능함.

Session Timeout Sec

Session server의 session expired time 설정.

standalone에서만 가능함.

  1. Connected WAS List

Refresh 버튼 을 클릭하면 리스트를 갱신해준다.

Table 62. Connected WAS List
항목(*는 필수값)설명비고

Server Name

WAS의 Name

Host

WAS가 설치된 Host명

  1. Status (Session Server의 상태 정보 제공)

Refresh 버튼 을 클릭하면 리스트를 갱신해준다.

Table 63. Status
항목(*는 필수값)설명

Session Count

현재 Session 개수

Logout Count

Logout 요청으로 Logout 된 Session 수

Session Max Count

Session 저장 최대 개수

Session Timeout

Session timeout 시간(ms)

Request Getnew Logout

WAS에서 전달된 GET_FRESH Request에 대한 Logout 응답 횟수

Data From Nodes

WAS에서 전달된 Session 개수

Request Getnew Nodata

WAS에서 전달된 GET_FRESH Request에 대한 NODATA 응답 횟수

Request Getnew

WAS에서 GET_SESSION Request했을 때 늘어난 횟수

Pid

Session이 standalone일 경우 프로세스 ID

Request Getfresh Data

WAS에서 GET_FRESH Request 가 왔을 때 해당 Session이 있는 경우 횟수

Request Getfresh Logout

WAS에서 GET_FRESH Request가 왔을 때 해당 Session이 Logout 된 횟수

Session Recv Lost

Session receive가 유실된 개수

Logout From Nodes

다른 was에서 logout 된 횟수

Session Expired

Session Time Out 시간으로 Expired 된 Session 수

Request Getfresh Nodata

WAS 에서 GET_FRESH_SESSION request했는데 데이터가 없을 경우 늘어난 횟수

Data From Secondary

Slave server에서 온 Data 개수

Request Getfresh

WAS에서 GET_FRESH Request 요청 횟수

Logout From Secondary

Slave Server에서 Logout Request가 전달 된 횟수

Req Lost

Request 유실 개수

Resp Lost

Response Queue의 사이즈 이상으로 Response 가 수신되어 손실된 Response 개수

Request Getfresh Secondary

Slave Server에서 GET_FRESH Request 요청 횟수

Request Getfresh Not New

WAS에서 전달된GET_FRESH Request에 대한 NOT_NEW Response 횟수

Request Getnew Secondary

Slave Server에서 GET_SESSION request했을 때 늘어난 횟수

Logging

Session Server의 로그설정 정보를 편집할 수 있다.

설정 정보의 상세 내용은 다음과 같다.

  1. Log Home

Table 64. Log Home
항목(*는 필수값)설명비고

Log Home(*)

Log Home 경로

default 선택시 서버설치디렉토리 하위 logs 폴더로 설정, custom 선택시 Log Home Prefix항목에서 로그디렉토리 홈 경로 입력가능

Retention Days(*)

로그 최대 보관 일수

Default : 0(무제한)

Environment

Start Shell의 설정을 관리하는 화면을 제공한다. 파일 에디터를 통해 수정한 후 Save 버튼 을 클릭하여 저장한다.

  • Start Shell ($CATALINA_HOME/env.sh) - Server 시작을 위한 Shell Script

기본적으로 설정을 수정할 수 없도록 Disable 되어 있지만, 수정하고 싶은 경우 ADMIN > Manager Environment > Manager Configuration 항목에서 설정 버튼 을 클릭해 아래 설정을 false 로 변경한다.

server.environment.envshell.readonly=false

5. Cluster

5.1. Server Cluster

Server Cluster는 동일한 서비스 제공을 위해 동일한 구성으로 구동되는 Application Server와 Web Server의 묶음이다.

server cluster overview
Figure 8. Server Cluster 화면

5.1.1. Server Cluster 목록

매니저에 등록된 Server Cluster 목록은 좌측메뉴에서 Server Cluster를 선택하면 확인 할 수 있다.

Server Cluster List 테이블에서 제공되는 속성은 아래와 같다.

Table 65. Server Cluster 속성
항목설명비고

Select

삭제를 위한 콤보박스

Server Cluster Name

Cluster 명

Servers

Server Cluster를 구성하는 각 Server별 개수

  1. Application Server

  2. Web Servers

5.1.2. Server Cluster 생성

Server Cluster 생성에서는 Server Cluster를 구성할 Application Server 목록과 Web Server 목록을 선택한다.

  1. Server Cluster Group을 선택하고 Server Cluster 목록 하단의 +New 버튼 을 클릭하면 신규 등록 화면이 출력된다.

  2. Server Cluster의 기본 정보를 입력한다.

    • Server Cluster Name: Server Cluster명을 입력한다.

    • Application Server Type: Server Cluster의 멤버로 사용될 Application의 Type을 선택한다. Standard와 Enterprise 두가지 유형이 있다.

    • Enable Scaling: Auto Scaling기능 사용여부를 선택한다. 이 옵션은 server cluster 생성 후에는 변경 할 수 없다.(이 기능은 Container Edition에서만 지원하며, 사용하기 위해선 manager.conf에서 scaling.enable를 true로 설정한다.)

    • Description: Server Cluster와 관련하여 필요한 설명들을 입력한다.

  1. 선택한 Application Server Type에 해당하는 서버 목록이 아래 Application server in server cluster 영역에 조회된다. Selectable Servers 에서 원하는 서버를 클릭 후 >> 버튼 을 눌러 Selected Servers 영역으로 옮긴다. Web servers in server cluster 영역에서 마찬가지로 Selectable Servers에서 원하는 서버를 클릭 후 >> 버튼 을 눌러 Selected Servers 영역으로 옮긴다.

하나의 Server는 하나의 Server Cluster에만 지정할 수 있으므로, 다른 Server Cluster에 매핑되지 않은 Application Server와 Web Server만 Selectable Servers 목록에 조회된다.

  1. V Save 버튼 을 클릭하여 저장한다.

  2. 좌측 트리에 입력한 server cluster명의 메뉴가 추가되었음을 확인할 수 있다.

5.1.3. Server Cluster 삭제

  1. 좌측 Server Cluster 트리메뉴에서 Server Cluster Group을 선택한다.

  2. Server Cluster List에서 삭제할 Server Cluster의 Select 컬럼의 체크박스를 선택한다.

  3. - Delete 버튼 을 클릭하여 삭제한다.

5.1.4. Server Cluster 상세

Overview

좌측 메뉴 또는 Server Cluster Group 상세에서 Server Cluster를 선택하면 Server Cluster에 대한 Overview 화면이 출력된다.

Server Cluster 상세 영역의 항목 및 버튼이 제공하는 기능은 아래와 같다.

Table 66. Server Cluster 상세 영역의 항목 및 버튼
항목 또는 버튼명기능

Server Cluster Name

Server Cluster 명

Application Server Type

Server Cluster에 구성되어 있는 Application Server 유형(변경 불가)

Server Config Synchronization Policy

Server Cluster 동기화 수행(Sync 버튼 선택) 중 오류 발생시 처리 정책

Server Config Synchronization Policy의 option은 아래와 같다. (기본값 : Force)

  1. Stop : 설정 동기화 중 오류 발생 시 즉시 중지

  2. Rollback : 설정 동기화 중 오류 발생 시 전체 rollback

  3. Force : 설정 동기화 중 오류 발생 시 해당 Server를 건너뛰고 다음 수행

Enable Scaling

Server Cluster의 Auto Scaling 기능 사용여부(변경 불가)

Description

Server Cluster에 대한 설명

Compare 버튼

Server Cluster 내 Application Server와 Web Server, Session Server의 동기화 상태를 비교한다.

Server 유형별 비교 항목은 아래와 같으며, 이는 아래 Server 목록 영역 각각의 컬럼에 출력된다.

Server Config, Application, Resource 및 Session 비교는 각 Server 유형별 Master Server를 기준으로 한다.

Application Server

  • Server Config : Application Server 설정 정보 동일 여부

  • Application : 각 Application Server에 deploy된 Application이 동일 여부

  • Resource : Resource 설정 동일 여부

  • Session : Session Clustering을 위한 Session Server 설정 동일 여부

Web Server

  • Server Config : Web Server 설정 정보 동일 여부

  • Connect to WAS : Server Cluster 내 모든 Application Server와 연계되어 있는지 여부

Sync 버튼

Server Cluster 내 Application Server의 Server Config, Application, Resource, Session 정보를 동기화한다.

Server Cluster 내 Web Server의 Server Config와 WAS 연계 정보를 동기화한다.

Snapshot 버튼

동기화된 Server Cluster에 대해 현재 상태를 Snapshot으로 저장한다. 생성된 Snapshot은 Snapshot 탭에서 확인할 수 있다.

Snapshot에는 Application Source도 포함된다. 따라서 과도하게 Snapshot을 생성하면 시스템 디스크 용량을 많이 차지할 수 있으므로 꼭 필요한 경우에만 생성하고 불필요한 Snapshot은 Snapshot 탭을 통해 삭제해야 한다.

Graceful Restart 버튼

Server Cluster 내 Web Server와 Application Server를 순차적으로 재기동한다. Graceful Stop을 수행하므로 처리 중인 service가 모두 종료된 후 Server가 stop 된다.

처리 순서는 아래와 같다. ()로 표현된 절차는 생략 가능하다.

  1. Web Server Stop

  2. Application Stop

  3. (Application Source 업로드)

  4. Application Server Start

  5. (별도 port로 테스트를 위해 Web Server를 staging port로 Start)

  6. Web Server Start

V Save 버튼

변경된 Server Cluster 상세 설정 내용을 저장한다.

동기화 상태 조회

Server Cluster의 동기화 상태는 Compare 버튼 을 선택하여 비교 후 그 결과를 각 Server 목록의 아래 컬럼을 통해 확인할 수 있다.

동일 또는 유효한 상태인 경우 상태가 초록색 원 아이콘 으로 출력된다.

Server의 상태가 동일하지 않을 경우 붉은색 원 아이콘 으로 나타나며, 해당 아이콘을 클릭하면 별도의 팝업창이 출력되어 Server별 상세 정보를 확인할 수 있다.

또한 각 Server 목록에서 Server Name을 클릭하면 해당 Server 상세 화면으로 이동할 수 있다.

  • Application Server의 Server Config 상세

    설정 파일의 비교 결과가 출력된다. 팝업창에서 파일 명 옆에 있는 Detail 항목의 돋보기 버튼 을 클릭하면 Master서버와 비교하여 현재 설정 파일의 비교결과(최종 수정일자, 설정 파일 내용)를 상세하게 볼 수 있다.

  • Application Server의 Application 상세

    Application의 Deploy 상태 비교 결과가 출력된다.

  • Application Server의 Resource 상세

    Application Server의 Resource 비교 결과가 출력된다.

  • Application Server의 Session 상세

    Application Server의 Session 설정 비교 결과가 출력된다. 팝업창에는 Master Server에 설정된 세션 정보를 제공한다.

  • Web Server의 Server Config

    설정 파일의 비교 결과가 출력된다. 팝업창에서 파일 명 옆에 있는 Detail 항목의 돋보기 버튼 을 클릭하면 Master서버와 비교하여 현재 설정 파일의 비교결과(최종 수정일자, 설정 파일 내용)를 상세하게 볼 수 있다.

  • Web Server의 Connect to WAS

    해당 Web Server가 Server Cluster에 속한 모든 Application Server에만 연계되어 있을 때 초록색 원 아이콘 상태로 출력되며 그 외의 경우에는 붉은색 원 아이콘 으로 표시된다. 붉은색 원 아이콘 을 클릭하면 별도의 팝업창이 출력되어 상세 정보를 확인할 수 있다.

    팝업창에는 Web Server에 연계되어 있는 Application Server가 모두 Server Cluster에 등록된 Server인지에 대한 상세 정보를 출력한다((Web Server Status). 또한 Server Cluster에 등록된 모든 Application Server가 해당 Web Server에 연계되어 있는지에 대한 상세 정보를 출력한다.(Application Server Status)

상태 동기화 수행

Server Cluster의 동기화 수행은 [.button]#Sync 버튼#을 선택하여 진행 한다. 그 결과는 각 Server 목록의 아래 컬럼을 통해 확인할 수 있다.

Graceful Restart

Graceful Restart 기능은 처리중인 업무의 처리 종료를 보장하면서 Server Cluster 내 모든 서버에 대한 재기동을 수행할 때 사용된다. 수행시 아래와 같은 절차를 통해 수행된다. (Server Cluster 내 모든 서버에 적용됨)

  1. Graceful Restart 시작 전

    Start Process 버튼을 클릭하면 Graceful Restart 작업이 시작된다.

  2. Web Server Stop 단계

    Web Server에 대한 Stop을 수행한다. 수행 중인 Thread가 모두 종료된 후 Web Server가 Stop된다.

  3. Application Server Stop 단계

    Application Server에 대한 Stop을 수행한다. 본 단계는 모든 Web Server가 종료된 후 활성화된다.

  4. 소스 배포 (생략 가능) 단계

    Application Server에 대한 소스 배포(업로드)를 수행한다. 별도의 배포 시스템이 있는 경우 이 단계는 생략 가능하다.

  5. Application Server Start 단계

    Application Server에 대한 Start를 수행한다. 기동 로그를 함께 조회할 수 있다.

  6. Web Server를 Staging mode로 Start (생략 가능) 단계

    Web Server를 Staging mode로 Start 한다. (본 단계는 생략 가능하다.) 이를 통해 일반 사용자에게 open 하기 전, 운영과 동일한 환경에서 staging port로 업무에 대한 테스트를 수행할 수 있다.

  7. Web Server Start 단계

    Web Server를 Staging mode로 Start 한다. (본 단계는 생략 가능하다.) 이를 통해 일반 사용자에게 open 하기 전, 운영과 동일한 환경에서 staging port로 업무에 대한 테스트를 수행할 수 있다.

  8. Graceful Restart 완료

Application Server

Server Cluster 내 Application Server의 목록 및 동기화 대상 정보를 관리하는 탭이다.

탭 상단의 서버 목록에 대한 상세 정보는 Overview와 동일하다.

동기화 대상 항목
서버 설정 파일 관리

Config 버튼 을 선택하면 제공되는 팝업창을 통해 Application Server의 Master Server 선택, 동기화할 설정파일 지정 및 JDBC Driver 동기화 여부를 설정할 수 있다.

  • Master Server

    Server Cluster내 Application Server 중 Master Server를 지정한다.

  • Server Configs for Synchronization

    Server Cluster 내의 Application Server에서 동일한 내용으로 유지할 파일 목록이다. Server Cluster 생성시 기본적인 파일 목록이 등록되어 있으며 프로젝트 사정에 맞게 파일을 추가/삭제할 수 있다. 파일의 경로는 Application Server의 Home 하위의 상대 경로이다.

  • Sync JDBC Drivers

    Manager Repository 경로/lib/datasource/폴더 하위 모든 jar파일을 동기화대상에 포함할지 여부를 선택한다.

JDBC Driver는 Runtime시 Jar파일 교체에 따른 오류를 방지하기 위해 Sync 대상 서버에 해당 JDBC Driver가 없을 경우에만 동기화 된다.

Application 관리

Application Server 목록에서 서버를 선택시 하단의 Application 탭을 통해 선택된 서버의 Application 상세 정보를 확인 할 수 있다. 제공되는 화면과 기능은 Application에서 기술한 내용과 동일하다. 따라서 기능에 대한 상세 설명은 본 장에서는 생략한다.

Resource 관리

Application Server 목록에서 서버를 선택시 하단의 DataSource, JMS, JTA 탭을 통해 선택된 서버의 DataSource, JMS, JTA의 상세 정보를 확인 할 수 있다.

제공되는 화면과 기능은 Datasource, JMS, JTA에서 기술한 내용과 동일하다. 따라서 기능에 대한 상세 설명은 본 장에서는 생략한다.

Session 관리

Application Server 목록에서 서버를 선택시 하단의 Session 탭을 통해 선택된 서버의 Session 상세 정보를 확인 할 수 있다.

제공되는 화면과 기능은 Session에서 기술한 내용과 동일하다. 따라서 기능에 대한 상세 설명은 본 장에서는 생략한다.

Application Server 목록 관리

Clone 버튼, Join 버튼 또는 Unjoin 버튼 을 사용하여 Application Server를 Server Cluster에 포함 또는 제외시킬 수 있다.

  • Clone

    Clone 버튼 을 클릭하면 Master서버와 동일한 설정을 가진 새로운 서버를 설치후 Server Cluster에 등록할 수 있다.

Table 67. Clone 팝업창 항목 설명
항목명기능

Post Processing Options

  • Cloned Server Start: Clone후 서버 기동 여부 체크

  • All Web Server Sync: Clone후 web서버와 연동 동기화

  • All Web Server Graceful Restart : Clone후 Web서버 재기동 여부

Node List

복제할 서버를 설치할 노드

Server ID / Clone Service Port

복제할 Server의 ID와 Service Port 입력

Include External Source

복제하려는 서버의 application 소스가 서버 외부에 있는데 이 소스까지 복제하려는 경우 Y 선택

  • Join

    Join 버튼 을 클릭하면 이미 생성한 Application Server 중 등록 가능한 Server를 Server Cluster에 추가한다.

  • Unjoin

    Unjoin 버튼 을 클릭하면 Cluster에 등록된 Server를 Cluster목록에서 제거한다.

Application Server 동기화 및 비교

  • Compare

    Compare 버튼 을 클릭하면 Server Cluster 내 Application Server의 동기화 상태를 비교한다.

  • Sync

    Sync 버튼 을 클릭하면 Server Cluster 내 Application Server의 Server Config, Application, Resource, Session 설정을 동기화한다.

Rolling Restart

Rolling Restart는 Server Cluster내에서 Application Server들을 순차적으로 재기동 할 때 사용한다.

재기동할 서버를 대상으로 수행하는 기능이므로 정지된 서버는 제외한다. 서버 목록에서 대상 서버들을 선택한 후 Rolling Restart 버튼 을 클릭하면 Rolling Restart팝업창이 제공된다.

팝업창에서 사용자는 Rolling Restart 시작 전 Execution option 영역에서 서버와 서버 사이의 기동 시작 Interval과 Force Stop 여부를 설정 할 수 있다. Rolling Restart 영역에서는 선택된 서버들이 순차적으로 재기동을 수행하는 상태를 확인할 수 있다.

팝업창의 Action 항목에는 Force Restart 버튼 과 Next 버튼 이 제공된다.

Table 68. Rolling Restart 팝업창 항목 설명
Node서버가 설치된 노드명

Server

서버명

Server Status

서버의 현재 기동상태

Stop Status

서버 정지 작업 상태

Start Status

서버 기동 작업 상태

Action

재기동 중인 서버의 경우 Force Restart 버튼 과 Next 버튼 이 제공된다.

Interval

서버에 남아있는 처리 시간. Execution Option 영역의 Interval에 설정된 값에서 시작하여 0까지 내려간 후 다음 서버의 재기동을 수행한다.

Elapsed time

재기동 처리 시간

Table 69. Rolling Restart 팝업창 버튼 설명
버튼명기능

Start

팝업창에 보여지는 대상서버의 재기동을 시작한다. 테이블의 위에서부터 순차적으로 진행된다.

Pause

재기동작업을 일시 중지한다. 중지 / 기동을 수행중인 경우 수행중인 명령이 중단되지는 않으며, 다음 작업은 대기하게 된다.

Resume

재기동작업을 재개한다. Pause 전 완료한 작업 이후부터 시작된다.

Force Restart

중지가 정상적을 되지 않는경우 본 버튼을 통해 강제 중지후 기동할 수 있다. 재기동 수행중인 서버가 중지 완료될때까지만 화면에 보여진다.

Next

현재 재기동중인 서버의 작업이 완료되기 전, 다음 서버의 재기동작업을 바로 진행하고 싶은경우 Next 버튼을 통해 다음 서버의 재기동을 수행할 수 있다. Next 를 수행해도 앞 서버들의 재기동 작업은 계속 수행된다.

Web Server

Server Cluster 내 Web Server의 목록 및 동기화 대상 정보를 관리하는 탭이다.

탭 상단의 서버 목록에 대한 상세 정보는 Overview와 동일하다.

동기화 대상 항목
서버 설정 파일 관리

Config 버튼 을 선택하면 제공되는 팝업창을 통해 Web Server의 Master Server 선택, 동기화 할 설정파일목록을 설정할 수 있다.

  • Master Server :

    Server Cluster내 Web Server 중 Master Server를 지정한다.

  • Server Configs for Synchronization :

    Server Cluster 내의 Web Server에서 동일한 내용으로 유지할 파일 목록이다. Server Cluster 생성시 기본적인 파일 목록이 등록되어 있으며 프로젝트 사정에 맞게 파일을 추가/삭제할 수 있다. 파일의 경로는 Web Server의 Home 하위의 상대 경로이다.

Connector

Web Server의 상세 connector정보들을 확인 및 수정 할 수 있다.

Web Server 목록에서 서버를 선택시 하단의 Connector 탭을 통해 선택된 서버의 Connector 상세 정보를 확인 할 수 있다. 제공되는 화면과 기능은 Connector에서 기술한 내용과 동일하다. 따라서 기능에 대한 상세 설명은 본 장에서는 생략한다.

Web Server 목록 관리

Clone 버튼, Join 버튼 또는 Unjoin 버튼 을 사용하여 Web Server를 Server Cluster에 포함 또는 제외시킬 수 있다.

  • Clone

    Clone 버튼 을 클릭하면 Master서버와 동일한 설정을 가진 새로운 서버를 설치후 Server Cluster에 등록할 수 있다.

Table 70. Clone 팝업창 항목 설명
항목명기능

Post Processing Options

  • Cloned Server Start: Clone후 서버 기동 여부 체크

Node List

복제할 서버를 설치할 노드

Server ID / Clone Service Port

복제할 Server의 ID와 Service Port 입력

Include External Source

복제하려는 서버의 소스가 서버 외부에 있는데 이 소스까지 복제하려는 경우 Y 선택

  • Join

    Join 버튼 을 클릭하면 이미 생성한 Web Server 중 등록 가능한 Server를 Server Cluster에 추가한다.

  • Unjoin

    Unjoin 버튼 을 클릭하면 Cluster에 등록된 Server를 Cluster목록에서 제거한다.

Web Server 동기화 및 비교

  • Compare

    Compare 버튼 을 클릭하면 Server Cluster 내 Web Server의 동기화 상태를 비교한다.

  • Sync

    Sync 버튼 을 클릭하면 Server Cluster 내 Web Server의 Server Config, Connect was를 동기화한다.

Rolling Restart

Rolling Restart는 Server Cluster내에서 Web Server들을 순차적으로 재기동 할 때 사용한다.

재기동할 서버를 대상으로 수행하는 기능이므로 정지된 서버는 제외한다. 서버 목록에서 대상 서버들을 선택한 후 Rolling Restart 버튼 을 클릭하면 Rolling Restart팝업창이 제공된다.

팝업창에서 사용자는 Rolling Restart 시작 전 Execution option 영역에서 서버와 서버 사이의 기동 시작 Interval과 Force Stop 여부를 설정 할 수 있다. Rolling Restart 영역에서는 선택된 서버들이 순차적으로 재기동을 수행하는 상태를 확인할 수 있다.

Table 71. Rolling Restart 팝업창 항목 설명
Node서버가 설치된 노드명

Server

서버명

Server Status

서버의 현재 기동상태

Stop Status

서버 정지 작업 상태

Start Status

서버 기동 작업 상태

Action

재기동 중인 서버의 경우 Force Restart 버튼 과 Skip 버튼 이 제공된다.

Interval

서버에 남아있는 처리 시간. Execution Option 영역의 Interval에 설정된 값에서 시작하여 0까지 내려간 후 다음 서버의 재기동을 수행한다.

Elapsed time

재기동 처리 시간

Snapshot

Overview Tab의 Snapshot 버튼을 클릭하면 Snapshot 생성을 위한 창이 출력되며 OK 버튼을 클릭하면 Server Cluster의 Snapshot이 생성된다.

Snapshot은 Server Cluster가 동기화 상태인 경우에만 생성할 수 있다.

Snapshot 탭을 통해 Snapshot 목록을 관리하는 화면을 제공한다. 일자를 입력 받아 Snapshot 이력을 조회한다. Snapshot이력에 대한 자세한 사항을 조회 할 수 있으며, 원하는 시점으로 복원하는 기능도 제공한다.

Snapshot 목록의 Detail 항목에 있는 목록 버튼 을 클릭하면 해당 snapshot에 대한 상세정보를 조회할 수 있다.

Snapshot 정보는 각 server별로 관리하므로 특정 Snapshot 생성 이후 Cluster에 추가된 server는 해당 Snapshot으로의 복원 대상에서 제외된다. (이 경우 Snapshot 복원 후 다시 Sync를 수행해야 모든 server가 동일한 구성을 가질 수 있다.) 또한 Snapshot 이후 Cluster에서 특정 server가 삭제되면 해당 server의 Snapshot 정보는 모두 삭제된다. Snapshot을 만들 때 소스코드는 Snapshot에 복사 되지 않으며 복사되는 설정파일은 기본설정파일 과 application설정파일, enterprise.xml 까지만 Snapshot에 포함된다.

Snapshot을 생성할 경우 디스크 용량에 부하를 줄 수 있으므로 주의하여 생성한다. 또한 생성된 Snapshot은 자동으로 삭제되지 않고 사용자가 직접 삭제해야 한다. 따라서 불필요한 Snapshot을 적절한 시기에 삭제하는 것을 권장한다.

5.1.5. Scaling

Server Cluster 생성시 Enable Scaling 옵션을 True로 선택하면 CSP 또는 Cloud 플랫폼이 제공하는 Auto-Scaling(Infra Scaling)에 따른 서비스 Scaling을 지원한다. 이 기능은 VM의 OS가 Linux이고, VM Instance 생성시 Init-Script (예 : AWS EC2의 UserData)가 제공되는 환경에서만 지원된다.

Cloud환경에서 Scaleing 은 일반적으로 다음과 같은 절차로 수행된다.

  1. VM Image 생성 (LENA Node, LENA Server 및 Application 등이 포함된 Image)

  2. VM Init-Script 작성

  3. LENA Manager에 Scaling Policy 설정

  4. 사전 설정한 Scaling Trigger 조건 (Resource 임계치 조건) 발생시 VM Auto-Scaling Out 수행 (CSP, Cloud 플랫폼 영역)

  5. VM Scale-Out시 Cloud Init-Script에 따라 LENA Node Agent 및 Server의 등록, 설정동기화, License 발급 수행 (LENA 영역)

  6. Resource 임계치가 정상화되면 VM Scale-in 수행 (CSP, Cloud 플랫폼 영역)

  7. VM Scale-in 후, Node Agent Alive 체크 실패가 LENA Manager에 설정된 횟수 만큼 발생하면, 해당 Node 및 Server를 LENA Manager에서 제거 (LENA 영역)

다음에서는 위의 절차중 LENA의 Scaling 지원영역과 관련된 Scaling Policy 설정 , VM Init-Script 관련 부분, LENA Node Agent / Server의 등록과 관련된 내용에 대해서 설명한다.

Scaling 기능은 Infra Scaling시 실행되는 Init-Script내에서 필요 환경변수 설정하고 LENA Scaling 실행 명령인 scale.sh 호출함으로서 Scale-Out이 실행된다. Manager에 설정된 Rule에 따라 Node Agent 통신 불가 인식 시 또는 VM 소멸시 stop-agent.sh을 옵션 설정하여 명시적으로 호출할 시 Scale-In이 실행된다.

  • Scale Out

Scale Out은 환경변수 설정하고 scale.sh을 호출함으로써 수행된다. AWS를 예를들면 AutoScaling그룹의 시작 템플릿에서 UserData에 해당 Script를 작성하여 실행한다. 미리 Manager에 Scaling License가 배포되어 있어야 Scaling License를 다운받아 서버가 정상 기동할 수 있다.

  • Init-Script Init-Script에는 필요한 환경변수를 설정하고, scale.sh을 호출하는 절차가 작성된다. Scale Out 관련 scale.sh에서 참조하는 환경 변수는 다음과 같다.

Table 72. scale.sh 참조 환경변수
환경변수설명

LENA_MANAGER_ADDRESS

  • 필수 옵션으로, Node, Server에 대한 Scaling 처리를 수행할 LENA Manager의 서비스 주소로 형식은 {IP주소}:(HttpPort} 이다.

  • 이 환경변수로 이중화된 Manager에 대한 Fail-Over 설정을 할 수 있다. Manager 주소를 쉼표(",")로 구분하였을 경우 첫번째 Manager에 접속이 실패하면 두번째 Manager에 접속을 시도한다. 지정된 시간(기본 10분)동안 Manager와의 접속이 성공할때 까지 과정을 반복적으로 수행한다.

JAVA_HOME

  • Node Agent 및 Server에서 사용할 Java의 설치 위치 이다.

LENA_CLUSTER_NAME

  • Server Cluster 명, Scale된 Server가 등록될 대상 Server Cluster의 이름 이다. 현재 존재하는 Server Cluster명을 기입해야만 정상적으로 Scaling이 수행된다.

LENA_USER, LENA_GROUP

  • Node Agent 및 Server를 기동할 OS 사용자 및 그룹

LENA_WAS_SCALING

  • WAS 서버의 Scaling 수행 여부

LENA_WAS_HOME

  • WAS 서버의 설치 위치

LENA_WAS_AGENT_PORT

  • WAS 서버의 Node Agent 서비스 포트

LENA_WEB_SCALING

  • Web 서버의 Scaling 실행 여부

LENA_WEB_HOME

  • Web 서버의 설치 위치

LENA_WEB_AGENT_PORT

  • Web 서버의 Node Agent 서비스 포트

LENA_WEB_OPENSSL_VER

  • OS에 설치된 OpenSSL의 Version으로, Web서버 기동을 위해 필요하다.

  • 지원되는 버전은 1.0.1, 1.0.2 , 1.1.1 이고, 기본 값은 1.0.2 이다.

LENA_IMAGE_TYPE

  • VM Image의 유형으로 LENA 패키지만 설치된 'base’와 Server까지 설치된 'golden' 가 있다. 'base’는 Scaling Mode 중 'clone’에 대응되며, 'golden’은 Scaling Mode중 'sync' / 'nosync’에 대응된다.

WAS_CONFIG_DATA

  • 개별 WAS의 설정정보로 Json 형식으로 정의된다. Session Cluster 정보, Datasource 정보를 설정할 수 있고, 이는 실제 구성된 Server의 설정정보를 변경한다.

환경 변수 적용 및 scale.sh 호출 예시 (Init-Script)
export LENA_MANAGER_ADDRESS=10.200.30.213:7700,10.200.30.214:7700
export LENA_CLUSTER_NAME=cust-g3r
export LENA_USER=lena
export LENA_GROUP=lena

export LENA_WAS_SCALING=Y
export LENA_WAS_HOME=/engn001/lena/1.5.0
export LENA_WAS_AGENT_PORT=16800

export LENA_WEB_SCALING=Y
export LENA_WEB_HOME=/engn001/lenaw/1.5.0
export LENA_WEB_AGENT_PORT=16900
export LENA_WEB_OPENSSL_VER=1.0.2

export LENA_IMAGE_TYPE=base

export WAS_CONFIG_DATA='[
     {
         "server_id": "comm_core_was-8980",
         "session_cluster": {
             "primary_port": "5480",
             "secondary_port": "5480"
         },
         "datasource": [
             {
                 "jndi_name": "jdbc/petclinic",
                 "url": "jdbc:mysql://10.200.30.7:63306/petclinic"
             }
         ]
     }
 ]'

if [ "$LENA_WAS_SCALING" = "Y" ]; then $LENA_WAS_HOME/bin/scale.sh; fi
if [ "$LENA_WEB_SCALING" = "Y" ]; then $LENA_WEB_HOME/bin/scale.sh; fi

  • Scale-in

Scale-in은 Scale-Out과정을 통해 등록된 Node와 Server를 해지하는 과정으로 1) Manager의 Scheduler에 의한 Node Agent로 부터 응답이 없는 Node와 해당 Node에 설치된 Server를 자동으로 등록해지하거나 또는 2) Option을 추가한 stop-agent.sh을 직접 호출하여 명시적으로 실행할 수 있다. stop-agent.sh의 옵션 정보는 다음과 같다.

Table 73. stop-agent.sh의 옵션 정보
옵션설명

-ur${Manager Address(IP:Port)}

  • 필수 옵션, Node 또는 Server를 등록해지 (Ur egister)한다.

  • 입력 파라미터는 Manager의 주소로 형식은 ${IP주소}:${HttpPort} 이다.

  • 이 옵션은 Manager에 대한 Fail-Over 처리가 가능하다. Manager 주소를 쉼표(",")로 구분하였을 경우 첫번째 Manager에 접속을 실패하면 두번째 Manager에 접속을 시도한다.

-f

  • 강제 등록해지 여부, 선택사항

  • -f 옵션이 설정되었을 경우 Server Cluster에서 등록해지 된다.

-rt ${time - milliseconds}

  • "Retry Time" , Optional

  • 해당시간 만큼 Retry한다. Retry 주기는 3초, 기본 Retry Time은 10초임

옵션 사용 예시
# Manager에서 Node / Server 정보를 모두 제거 한다.
# Manager License 사용량 산정에서 해당 서버의 사용량이 중지된다.
stop-agent.sh -ur 10.80.44.55:78700 -f
Scaling Overview

Scaling 탭을 선택하면 제공되는 화면 상단의 테이블은 Node 타입 별 현재 Scaling 현황을 보여준다.

  • Initial Node : 현재 Server Cluster에 포함되어 있는 노드 수

  • Scaled Node : Scaling 정책에 따라 생성된 노드 수

  • Today Event : 오늘 하루 Scaling 이벤트 발생 횟수

  • Latest Event : 최근에 발생된 Scaling 이벤트 발생시간

Policy

Scaling시 적용되는 Naming Rule과 같은 정책 정보를 정의 할 수 있다.

Common Policy

  • System : Scaling 적용 시스템 명

  • Sync Button Enabled : Server Cluster 기능의 Sync버튼 활성화 여부

  • Scaling Mode : Server Scaling 유형

    • nosync : Node와 Server를 등록하고 Cluster에 등록한다.

    • sync : Node와 Server를 등록하고 Cluster에 등록 후 Cluster Config 기반 Sync 수행, Scaling 되는 신규 Server에 대해서만 Sync를 수행한다.

    • clone : Node를 등록하고 Cluster에 등록 후 Master Server를 복제(Clone)하여 Server를 설치하고 Cluster에 등록 및 Web/WAS Sync 수행

  • Web-WAS Connection Scope : Web-WAS 연계 방식

    • none (Using Proxy) : 별도의 Web-WAS 연계를 수행하지 않음

    • JK Mesh - Cluster Servers : Cluster내 서버간의 연계를 수행, Web의 경우 신규등록되는 Web서버와 Cluster내 Server들을 연계, WAS의 경우 신규등록되는 WAS 서버와 Cluster내 Web서버와의 연계, nosync Mode일때는 Web서버에 설정된 LoadBalancer를 동기화 하지않고 LoadBalancer별로 Cluster내 WAS를 연계함으로서 Blue-Green 배포방식을 지원

    • JK Mesh - Servers on same machine : 동일 VM 내에 있는 Web-WAS 만을 대상으로 연계 수행

WAS Node

  • Node Naming Rule : WAS 노드 명명 규칙

  • Server Naming Rule : WAS 명명 규칙

  • Wait For WAS Start Up : WAS가 Scale-Out되었을 때 기동대기 여부이다. 'Y’인 경우 기동된 후 다음 절차 (예 : WEB 서버 재기동)를 수행한다.

  • Wait Time for WAS Start Up : 최대 WAS 기동대기 시간. Wait For WAS Start Up이 'Y’일 경우에도 해당 시간이 지나면 다음 절차를 수행한다.

WEB Node

  • Node Naming Rule : WEB 노드 명명 규칙

  • Server Naming Rule : Web 서버 명명 규칙

명명규칙에서 사용되는 Convention(예약어)은 다음과 같다.

  • #{IP} : 각 단위가 '-'로 구분된 Node 또는 Server IP 주소

  • #{IP[4]} : Node 또는 Server의 IP 주소 중 4번째 숫자

  • #{PORT} : Node Agent 또는 Server의 HTTP 서비스 주소

  • #{MASTER_NAME} : Master Server의 이름

  • #{HOSTNAME} : Node 또는 Server가 설치된 VM의 Host명

  • #{HOSTNAME[R4]} : VM Host명의 오른쪽 끝 4자리

해당 항목의 정보를 저장 후 Save 버튼 을 눌러 저장한다.

WAS Scaling Template / Web Scaling Template

Sync모드 Scaling시에 동기화되는 파일 목록과 내용을 조회할 수 있다. 보여지는 File 목록들은 해당 Server Cluster의 Master Server로 부터 Manual 방식으로 복사 하여 생성된다. 화면의 Create 버튼 을 누르면 수동으로 파일이 생성된다. 돋보기 버튼 을 눌러 파일의 상세내용을 조회할 수 있고, 현재 Master Server의 설정파일과 비교한 결과를 확인할 수 있다.

History

날짜 및 시간을 기준으로 Scaling 이벤트의 history를 조회할 수 있다. Scaling이 발생한 날짜를 선택하고 시간을 입력한 후 Search 버튼 을 눌러 해당 시간에 발행한 Scaling Event를 조회한다.

Scaling 기능은 Enterprise Edition에서만 제공되는 기능이다.

6. Resource

6.1. Database

좌측 메뉴에서 Database를 선택하면 Database Resource 목록이 조회된다.

resource database
Figure 9. Database 목록 조회 화면

6.1.1. Database 등록

  1. Database Resource 목록에서 New 버튼 을 클릭하면 신규 등록 화면이 출력된다.

  2. 입력 항목을 입력한다.

    • Resource Name을 입력한다.

    • DriverClassName을 확인 후 원하는 벤더의 드라이버를 선택한다.

    • Address(host/Port) 정보를 입력한다.

  3. Save 버튼 을 클릭해 저장한다.

6.1.2. Database 수정

  1. Database Resource 목록에서 수정하려는 Database Resource의 체크박스를 선택한다.

  2. Database Resource의 항목을 수정한 후 저장한다.

내용이 수정될 경우 해당 Database Resource에 연결된 DataSoruce Resource및 WAS의 설정에 전파되므로, 해당 Database Resource 하위에 연결된 DataSoruce Resource가 존재할 경우 입력창이 기본적으로 Disable 된다. Edit 버튼 을 클릭하면 수정할 수 있다.

6.2. DataSource

좌측 메뉴에서 DataSource를 선택하면 DataSource Resource 목록이 조회된다.

resource datasource
Figure 10. DataSource 목록 조회 화면

6.2.1. DataSource 등록

  1. DataSource Resource 목록에서 New 버튼 을 클릭하면 신규 등록 화면이 출력된다.

  2. Resource Name 필드에 논리적인 이름을 입력한다.

  3. Server Type을 설정한다. Server Type은 Standard, Enterprise 중에 선택하여야 하며, 이 후 같은 Type의 서버에서만 Import하여 사용할 수 있다.

  4. DataSource의 상세 설정을 한다(<Server DataSource 설정>>의 상세 항목 설명 참고)

  5. Upload 버튼 을 클릭하여 해당 DataSource의 Driver를 Manager서버에 등록한다. 미리 등록된 Driver는 운영자가 Server에 Import하는 시점에 해당 Server로 전송된다.

  6. Save 버튼 버튼을 클릭하여 저장한다.

Manager에 업로드 된 JDBC Driver는, 운영자가 Server에 해당 DataSource Resource를 Import하는 시점에 해당 Server로 전송된다. 전송된 JDBC Driver는 {서버홈경로}/lib/datasource 디렉토리에 위치하며 Classpath에 자동으로 등록된다.

6.2.2. DataSource 수정

  1. DataSource Resource 목록에서 수정하고자 하는 행을 선택하면 DataSource Resource 수정 화면이 표시된다.

  2. 변경하고자 하는 설정을 변경한다.

  3. Save 버튼 을 클릭하여 저장한다.

resource datasource detail
Figure 11. DataSource 상세 정보 화면

DataSource Resource 정보를 수정한 후 저장하면 해당 DataSource Resource가 사용되는 Server에 변경된 설정이 전파된다. 설정이 전파된 Server를 재기동하면 해당 설정이 적용된다.

Standard Type으로 설정한 DataSource Resource를 Standard 서버에 Import 한 후에 Server Type을 Enterprise로 변경할 수 없다.

Classpath 등록 후 DataSource Resource 삭제 시, Classpath는 삭제되지 않음에 유의해야 한다.

6.2.3. DataSource 삭제

  1. DataSource Resource 목록에서 삭제할 DataSource Resource의 체크박스를 선택한다.

  2. Delete 버튼 을 클릭하여 삭제한다.

Server 또는 Application에서 Import하여 Registered Server 또는 Registered Application이 존재하는 경우, 해당 DataSource Resource는 삭제할 수 없다.

6.2.4. JDBC Driver Upload

  1. DataSource Resource 등록 혹은 수정 화면에서 Upload 버튼 을 클릭하면 Driver File을 Upload 할 수 있는 화면이 출력된다.

  2. 파일선택 버튼 을 클릭하여 Local PC에서 upload 하고자 하는 Driver File을 선택한다.

  3. Upload 버튼 을 클릭하여 Manager로 Driver File을 Upload한다.

6.2.5. DataSource Import

생성한 DataSource Resource를 Import해서 사용하고 있는 Server 목록(Scope가 Context, Global, Global + Link인 경우) 또는 Application목록(Scope가 Application인 경우)은 DataSource Resource 상세 조회 시 하단 영역에 표시된다.

DataSource 상세 화면에서 DataSource Import 하기

Scope가 Context, Global, Global + Link인 DataSource Resource는 자신을 Import하는 Server를 등록할 수 있다.

  1. DataSource 관리 화면에서 특정 DataSource Resource를 선택하여 상세 정보 화면으로 이동한다.

  2. Edit Server List 버튼 을 클릭하면 Server를 등록 관리 할 수 있는 창이 출력된다.

  3. 해당 DataSource를 Import 할 Server를 지정해 우측 영역으로 이동시킨다.

  4. Save 버튼 을 클릭하면 해당 Server에 DataSource Resource가 Import 된다.

Import된 DataSource Resource를 Server에서 삭제하려면, 대상 Server를 좌측 영역으로 이동시킨 후 Save 버튼 을 클릭한다.

개별 Server에서 DataSource Import 하기

  1. LENA Manager 상단의 Servers 메뉴를 선택한다.

  2. 좌측에서 개별 Web Application Server > Resources > DataSource 탭을 클릭하면, 해당 Server의 DataSource Resource 목록 조회 및 DataSource Resource 추가를 할 수 있는 화면이 출력된다.

  3. Import 버튼 을 클릭하면 팝업 창에 미리 정의된 DataSource Resource 목록이 조회된다.

  4. Import 하고자 하는 DataSource Resource를 선택한다.

  5. OK 버튼 을 클릭하여 해당 DataSource Resource를 Import 한다.

DataSource Resource를 Import 하게 되면 해당 DataSource Resource와 Server 간의 연결정보가 내부적으로 생성된다. 이 연결 정보를 기반으로 DataSource Resource 수정 시점에 설정 변경 사항이 해당 Server에 전달된다. 연결 정보는 Resource > DataSource 화면에서 조회할 수 있다.

Standard Server에서는 Enterprise Type의 DataSource Resource를 Import 할 수 없다.(목록에 표시되지 않음)

Import한 DataSource Resource 설정은 Server 설정에서 편집할 수 없다.(설정 정보는 볼 수 있지만 수정 불가) 설정을 변경하고자 한다면 Resource > DataSource 화면으로 이동하여 변경한다.

6.3. JTA

좌측 메뉴에서 JTA를 선택하면 JTA Resource 목록이 조회된다.

resource jta
Figure 12. JTA 목록 조회 화면

6.3.1. JTA 등록

  1. JTA 목록에서 New 버튼 을 클릭하면 신규 등록 화면이 출력된다.

  2. 설정하고자 하는 값을 입력한다.(상세 설정 값은 "4.3.7 Server 설정 정보 관리" 참고)

  3. Save 버튼 을 클릭하여 저장한다.

6.3.2. JTA 수정

  1. JMS Resource 목록에서 수정하고자 하는 행을 선택하면 수정 화면이 표시된다.

  2. 변경하고자 설정을 입력한다.

  3. Save 버튼 을 클릭하여 저장한다.

resource jta detail
Figure 13. JTA 상세 정보 화면

JTA Resource 정보를 수정한 후 저장하게 되면 해당 JTA Resource가 사용되는 Server에 변경된 설정이 전파된다. 설정이 전파된 Server는 재기동하게 되면 해당 설정이 적용된다.

6.3.3. JTA 삭제

  1. JTA 목록에서 삭제할 JTA Resource의 체크박스를 선택한다.

  2. Delete 버튼 을 클릭하여 삭제한다.

Server에서 import하여 Registered Server가 존재하는 경우 해당 JTA Resource를 삭제할 수 없다.

6.3.4. JTA Import

생성한 JTA Resource를 Import해서 사용하고 있는 Server 목록은 JTA Resource 상세 조회 시 하단 영역에 표시된다.

JTA 상세 화면에서 JTA Import 하기

JTA 상세 화면에서 자신을 Import해서 사용하고 있는 Server 목록을 수정할 수 있다.

  1. JMS 관리 화면에서 특정 JTA Resource를 선택하여 상세 정보 화면으로 이동한다.

  2. Edit Server List 버튼 을 클릭하면 Server를 등록 관리할 수 있는 창이 출력된다.

  3. 해당 JMS를 Import 할 Server를 지정해 우측 영역으로 이동시킨다.

  4. Save 버튼 을 클릭하면 해당 Server에 JMS Resource가 Import 된다.

Import된 JTA Resource를 Server에서 삭제하려면, 대상 Server를 좌측 영역으로 이동시킨 후 Save 버튼 을 클릭한다.

개별 Server에서 JTA Import 하기

  1. LENA Manager 상단의 Servers 메뉴를 선택한다.

  2. 좌측에서 개별 Web Application Server > Resources > JTA 탭을 클릭하면, 해당 Server의 JTA Resource 목록 조회 및 JTA Resource 추가를 할 수 있는 화면이 출력된다.

  3. Import 버튼 을 클릭하면 팝업 창에 미리 정의된 JTA Resource 목록이 조회된다.

  4. Import 하고자 하는 JTA Resource를 선택한다.

  5. OK 버튼 을 클릭하여 해당 JTA Resource를 Import 한다.

JTA Resource를 Import 하게 되면 해당 JTA Resource와 Server 간의 연결정보가 내부적으로 생성된다. 이 연결 정보를 기반으로 JTA Resource 수정 시점에 설정 변경 사항이 해당 Server에 전달된다. 연결 정보는 Resource > JTA 화면에서 조회할 수 있다.

Import한 JTA Resource 설정은 Server 설정에서 편집할 수 없다.(설정 정보는 볼 수 있지만 수정 불가) 설정을 변경하고자 한다면 Resource > JTA 화면으로 이동하여 변경한다.

6.4. JMS

좌측 메뉴에서 JMS를 선택하면 JMS Resource 목록이 조회된다.

resource jms
Figure 14. JMS 목록 조회 화면

6.4.1. JMS 등록

  1. JMS 목록에서 New 버튼 을 클릭하면 신규 등록 화면이 출력된다.

  2. 등록할 JMS Resource의 유형을 선택하면 하단에 선택한 유형에 맞게 설정 정보가 표시된다.

  3. 설정하고자 하는 값을 입력한다.(상세 설정 값은 "4.3.7 Server 설정 정보 관리" 참고)

  4. Save 버튼 을 클릭하여 저장한다.

6.4.2. JMS 수정

  1. JMS Resource 목록에서 수정하고자 하는 행을 선택하면 수정 화면이 표시된다.

  2. 변경하고자 설정을 입력한다.

  3. Save 버튼 을 클릭하여 저장한다.

resource jms detail
Figure 15. JMS 상세 정보 화면

JMS Resource 정보를 수정한 후 저장하게 되면 해당 JMS Resource 가 사용되는 Server 에 변경된 설정이 전파된다. 설정이 전파된 Server는 재기동하게 되면 해당 설정이 적용된다.

6.4.3. JMS 삭제

  1. JMS 목록에서 삭제할 JMS Resource의 체크박스를 선택한다.

  2. Delete 버튼 을 클릭하여 삭제한다.

Server에서 import하여 Registered Server가 존재하는 경우 해당 JMS Resource를 삭제할 수 없다.

6.4.4. JMS Import

생성한 JMS Resource를 Import해서 사용하고 있는 Server 목록은 JMS Resource 상세 조회 시 하단 영역에 표시된다.

JMS 상세 화면에서 JMS Import 하기

JMS 상세 화면에서 자신을 Import해서 사용하고 있는 Server 목록을 수정할 수 있다.

  1. JMS 관리 화면에서 특정 JMS Resource를 선택하여 상세 정보 화면으로 이동한다.

  2. Edit Server List 버튼 을 클릭하면 Server를 등록 관리 할 수 있는 창이 출력된다.

  3. 해당 JMS를 Import 할 Server를 지정해 우측 영역으로 이동시킨다.

  4. Save 버튼 을 클릭하면 해당 Server에 JMS Resource가 Import 된다.

Import된 JMS Resource를 Server에서 삭제하려면, 대상 Server를 좌측 영역으로 이동시킨 후 Save 버튼 을 클릭한다.

개별 Server에서 JMS Import 하기

  1. LENA Manager 상단의 Servers 메뉴를 선택한다.

  2. 좌측에서 개별 Web Application Server > Resources > JMS 탭을 클릭하면, 해당 Server의 JMS Resource 목록 조회 및 JMS Resource 추가를 할 수 있는 화면이 출력된다.

  3. Import 버튼 을 클릭하면 팝업 창에 미리 정의된 JMS Resource 목록이 조회된다.

  4. Import 하고자 하는 JMS Resource를 선택한다.

  5. OK 버튼 을 클릭하여 해당 JMS Resource를 Import 한다.

JMS Resource를 Import 하게 되면 해당 JMS Resource와 Server 간의 연결정보가 내부적으로 생성된다. 이 연결 정보를 기반으로 JMS Resource 수정 시점에 설정 변경 사항이 해당 Server에 전달된다. 연결 정보는 Resource > JMS 화면에서 조회할 수 있다.

Import한 JMS Resource 설정은 Server 설정에서 편집할 수 없다.(설정 정보는 볼 수 있지만 수정 불가) 설정을 변경하고자 한다면 Resource > JMS 화면으로 이동하여 변경한다.

6.5. Application

좌측 메뉴에서 Application를 선택하면 Application Resource 목록이 조회된다.

resource application
Figure 16. Application 목록 조회 화면

6.5.1. Application 등록

  1. Application 목록에서 New 버튼 을 클릭하면 신규 등록 화면이 출력된다.

  2. 설정하고자 하는 값을 입력한다.

    • Application Type이 WAR일 경우에는 추가로 설정할 수 있는 항목이 표시된다.(상세 설정 값은 Application Settings 참고)

  3. Save 버튼 을 클릭하여 저장한다.

6.5.2. Application 수정

  1. Application Resource 목록에서 수정하고자 하는 행을 선택하면 수정 화면이 표시된다.

  2. 변경하고자 설정을 입력한다.

  3. Save 버튼 을 클릭하여 저장한다.

resource application detail
Figure 17. Application 상세 정보 화면

Application Resource 정보를 수정한 후 저장하게 되면 해당 Resource가 사용되는 Server에 변경된 설정이 전파된다. 설정이 전파된 Server는 재기동하게 되면 해당 설정이 적용된다.

6.5.3. Application 삭제

  1. Application 목록에서 삭제할 Application Resource의 체크박스를 선택한다.

  2. Delete 버튼 을 클릭하여 삭제한다.

Server에서 import하여 Registered Server가 존재하는 경우 해당 Application Resource를 삭제할 수 없다.

6.5.4. Application Upload

  1. Application Resource 등록 혹은 수정 화면에서 Upload 버튼 을 클릭하면 Application File을 Upload 할 수 있는 화면이 출력된다.

  2. 파일선택 버튼 을 클릭하여 Local PC에서 upload 하고자 하는 Application File을 선택한다.

  3. Upload 버튼 을 클릭하여 Manager로 Application File을 Upload한다.

Application Import

생성한 Application Resource를 Import해서 사용하고 있는 Server 목록은, Application Resource 상세 조회 하단 영역에 표시된다.

Application 상세 화면에서 Application Import 하기

Application 상세 화면에서 자신을 Import해서 사용하고 있는 Server 목록을 수정할 수 있다.

  1. Application 관리 화면에서 특정 Application Resource를 선택하여 상세 정보 화면으로 이동한다.

  2. Edit Server List 버튼 을 클릭하면 Server를 등록 관리할 수 있는 창이 출력된다.

  3. 해당 Application를 Import 할 Server를 지정해 우측 영역으로 이동시킨다.

  4. Save 버튼 을 클릭하면 해당 Server에 Application Resource가 Import 된다.

Import된 Application Resource를 Server에서 삭제하려면, 대상 Server를 좌측 영역으로 이동시킨 후 Save 버튼 을 클릭한다.

개별 Server에서 Application Import 하기

  1. LENA Manager 상단의 Servers 메뉴를 선택한다.

  2. 좌측에서 개별 Web Application Server > Applications 메뉴를 클릭하면, 해당 Server의 Application Resource 목록 조회 및 Application Resource 추가를 할 수 있는 화면이 출력된다.

  3. Import 버튼 을 클릭하면 팝업 창에 미리 정의된 Application Resource 목록이 조회된다.

  4. Import 하고자 하는 Application Resource를 선택한다.

  5. OK 버튼 을 클릭하여 해당 Application Resource를 Import 한다.

Application Resource를 Import 하게 되면 해당 Application Resource와 Server간의 연결정보가 내부적으로 생성된다. 이 연결 정보를 기반으로 Application Resource 수정 시점에 설정 변경 사항이 해당 Server에 전달된다. 연결 정보는 Resource > Application 화면에서 조회할 수 있다.

Import한 Application Resource 설정은 Server 설정에서 편집할 수 없다.(설정 정보는 볼 수 있지만 수정 불가) 설정을 변경하고자 한다면 Resource > Application 화면으로 이동하여 변경한다.

7. Diagnostics

7.1. Monitoring Dashboard

7.1.1. 현황 요약

Monitoring Dashboard 화면은 하단에 3개의 탭을 제공하고 있고 선택된 탭에 따라 상단에 제공되는 요약정보가 변경된다.

탭 별로 제공되는 정보는 다음과 같다.

Node 탭

등록된 Node별 Server 모니터링 정보 제공

Server Cluster 탭

Server Cluster 그룹별로 등록된 Server 모니터링 정보 제공

Service Cluster 탭

Service Cluster 그룹별로 등록된 Container 모니터링 정보 제공

각 정보의 조회 주기를 설정할 수 있으며, WAS의 경우 Function 컬럼에 있는 팝업 버튼 을 클릭하면 상세 모니터링 화면으로 이동할 수 있다.

Monitoring Dashboard 화면은 다음과 같다.

diagnostics monitoring dashboard node tab
Figure 18. Monitoring Dashboard의 Node 탭 화면
diagnostics monitoring dashboard cluster tab
Figure 19. Monitoring Dashboard의 Server Cluster 탭 화면
monitoring serviceCluster
Figure 20. Monitoring Dashboard의 Service Cluster 탭 화면

Service Cluster 탭은 Container Edition에서 제공되는 기능이다.

Monitoring Dashboard 화면에서 사용된 속성들은 아래와 같다. 사용률 형태로 제공하는 정보의 색상은 Status Range 속성을 이용해 변경할 수 있다. (이 장의 하위 절인 모니터링 기본 설정 참고)

Table 74. Node 상태
항목설명비고

CPU

Node의CPU 사용률

Default 설정값은 60% 미만일 경우 Low, 80% 이상일 경우 High이다.

Memory

Node의 Memory 사용률

Default 설정값은 60% 미만일 경우 Low, 80% 이상일 경우 High이다.

Disk

Node의 Disk 사용률

Engine이 설치된 Disk 사용률로써 Default 설정값은 60% 미만일 경우 Low, 80% 이상일 경우 High이다.

Table 75. Application Server 상태
항목설명비고

Status

Server 기동여부, 진단결과발행여부(구급차 아이콘) 및 자동대응수행여부(방패 아이콘)

Unknown 상태는 Node Agent를 통해 서버의 상태를 가져올 수 없는 경우에 표시됨

Server Name

Server 이름

Heap Memory

Application Server에서 사용되는 Heap Memory 사용률

Thread Pool

Application Server가 Pool로 관리하는 Request Thread 사용률을 Connector(Ajp, Http) 별로 표시

DataSource

Application Server가 Pool로 관리하는 Datasource Connection 사용률

Session Clustering

Application Server에 설정된 Session Server의 정보 및 기동여부

붉은색은 정지상태, 초록색은 기동상태, 검은색은 시스템외부에 존재하는 서버를 의미

Table 76. Web Server 상태
항목설명비고

Status

Server 기동여부

Unknown 상태는 Node Agent를 통해 서버의 상태를 가져올 수 없는 경우에 표시됨

Server Name

Server 이름

CPU

Web Server 프로세스의 CPU 사용률

Memory

Web Server 프로세스의 Memory 사용률

Thread

Web Server의 Thread 수 (Active / Max)

Connected WAS

Web Server와 연결된 WAS 정보 및 기동여부

붉은색은 정지상태, 초록색은 기동상태, 검은색은 시스템외부에 존재하는 서버를 의미

Table 77. Session Server 상태
항목설명비고

Status

Server 기동여부

Unknown 상태는 Node Agent를 통해 서버의 상태를 가져올 수 없는 경우에 표시됨

Server Name

Server 이름

Heap

Session Server에서 사용되는 Heap Memory 사용률

Session Count

Active 상태인 Session 비율

Mirror Server

Mirror Server의 정보 및 기동여부

붉은색은 정지상태, 초록색은 기동상태, 검은색은 시스템외부에 존재하는 서버를 의미

각 서버를 즉시 제어할 수 있는 기능을 다음과 같이 함께 제공된다.

Table 78. Application Server 제어 기능
항목설명비고

Thread Dump

Thread Dump 생성

왼쪽 버튼(Server Snapshot(dump)) > Dump List 메뉴 선택 > Dump 파일 다운로드 가능

Active Service Dump

Active Service Dump 생성

왼쪽 버튼(Server Snapshot(dump)) > Dump List 메뉴 선택 > Dump 파일 다운로드 가능

Heap Dump

Heap Dump 생성

왼쪽 버튼(Server Snapshot(dump)) > Dump List 메뉴 선택 > Dump 파일 다운로드 가능

Forced Stop

서버 강제 종료

대기 시간 없이 즉시 강제 종료

Forced Restart

서버 강제 재시작

대기 시간 없이 즉시 강제 재시작

All Diagnostics Disable

해당 서버에 적용된 진단/대응 기능을 모두 Disable 처리

diagnostics current status dump
Figure 21. Dump 창

Heap Dump, Thread Dump, Active Service Dump를 생성하고 다운로드 할 수 있다. 일반적으로 Dump는 서버에서 Out Of Memory등의 오류, Thread Pool의 과다 사용, 서비스 지연 등이 발생한 경우 원인 파악을 위해 생성한다.

생성하려는 Dump 타입에 따라 Thread Dump 버튼 , Active Service Dump 버튼 , Heap Dump 버튼 을 클릭해 Dump를 생성한다. 생성된 Dump는 Web Application Server가 존재하는 Host내 저장되는데, Thread Dump는 {log_home}/logs/tdump, Active Service Dump는 {log_home}/logs/sdump, HeapDump 파일은 Dump파일은 {log_home}/logs/hdump 경로에 저장된다.

Delete 버튼 을 클릭하여 Dump 파일을 삭제할 수 있다. Download 버튼 을 클릭해 Dump 파일을 다운로드 할 수 있으며, 다운 로드 시 해당 Dump 파일이 시스템 현황 Dump 파일과 함께 zip 형태로 다운로드 된다.

Dump 관리 화면의 항목은 다음과 같다.

Table 79. Dump 화면 항목
항목설명비고

File Name

생성된 파일 이름

날짜를 포함한 문자열로 자동 생성된다

Size

생성된 파일의 사이즈

Status

Dump 수행 시점의 System 및 Server의 상태

Dump 생성 시점의 시스템의 CPU, Memory 정보 및 Web Application Server의 주요 리소스 사용량 정보도 Dump 생성 시 함께 생성한다.

View 버튼 을 클릭하여 생성된 Status 값을 확인할 수 있다

Table 80. Web Server제어 기능
항목설명비고

Forced Stop

서버 강제 종료

대기 시간 없이 즉시 강제 종료

Graceful Stop

서버 Graceful 종료

Monitoring 정보가 표시되지 않는다면 등록된 Node/Server가 실제로 존재하는지, Node/Server와 통신이 잘 되는 상태인지 체크한다.

7.1.2. 현황 모니터링 상세

Monitoring Dashboard에서 Function 컬럼에 있는 가운데 버튼(View Detail Chart) 을 선택하면 상세한 Thread, Memory, 서비스 정보를 모니터링할 수 있다.

System 창

Web Application Server의 Memory, Thread, Service 정보를 확인할 수 있다.

diagnostics current status system
Figure 22. System 탭
Memory Chart

실시간 Memory 사용량 정보가 표시된다. 제공하는 정보로는 GC Time(Garbage Collection 소요 시간), GC Count, Heap Used(Total Memory - Free Memory), Total Memory(서버에서 사용중인 총 메모리)가 있다. 차트의 붉은 점선은 사용 가능한 최대 Heap Memory를 의미한다. 따라서 차트에서 Heap Memory 사용량이 일반적인 GC패턴이 아닌 긴 시간동안 연속적으로 붉은 점선에 근접할 경우 유의해야 한다.

Request Thread의 최대값은 Server 메뉴에서 해당 Web Application Server의 maxThreads 속성을 통해 변경할 수 있다.

Thread Chart

Web Application Server가 사용자의 요청을 처리하기 위해 Pool 로 관리하고 있는 Request Thread 사용 현황을 볼 수 있는 Line Chart이다. 차트의 붉은 점선은 사용할 수 있는 Request Thread의 최대치를 의미한다. 때문에 차트에서 Request Thread 수가 붉은 점선에 근접할 경우 유의해야 한다.

Request Thread의 최대값은 Server 메뉴에서 해당 Web Application Server의 maxThreads 속성을 통해 변경할 수 있다.

Thread List

Web Application Server의 모든 Thread를 확인할 수 있다. 출력된 Thread 이름이나 Thread 상태를 기준으로 필터링 할 수 있다. Thread List의 항목은 아래와 같다.

Table 81. Thread List 항목
항목설명비고

Thread ID

고유 Thread ID

Name

Thread 이름

Stat

Thread 상태

총 세 가지의 상태가 존재함

  • RUNNABLE: 가용 Thread

  • WAITING: 다른Thread의 특정 Action 을 수행하기 위해 대기 중인 Thread

  • TIMED_WAITING: 명시된 대기시간이 있는 Thread

CPU

지정된 Thread에 대한 CPU 사용시간

Tx Id

트랜잭션 ID

Elapsed

Thread가 수행되는데 걸린 시간

Service Name

Thread가 수행한 서비스 이름

+ 버튼 을 눌러 다음과 같은 상세 정보를 확인할 수 있다.

Table 82. Thread 상세 정보 항목
항목설명비고

threadId

고유 Thread ID

threadName

Thread 이름

State

Thread 상태

총 세 가지의 상태가 존재함

  • RUNNABLE: 가용 Thread

  • WAITING: 다른Thread의 특정 Action 을 수행하기 위해 대기 중인 Thread

  • TIMED_WAITING: 명시된 대기시간이 있는 Thread

threadCpuTime

현재 Thread를 포함한 모든 Thread의 CPU 시간

threadUserTime

현재 Thread의 CPU 시간

blockedCount

Block된 합계

blockedTime

Block된 누적 경과시간

waitedCount

대기한 Thread의 합계

waitedTime

대기한 Thread의 누적 경과시간

lockOwnerId

lock된 Object를 소유한 Thread의 ID

lockName

lock된 Object이름

lockOwnerName

lock된 Object를 소유한 Thread의 이름

stackTrace

stackTrace

Active Service List

서비스 정보 및 해당 서비스를 처리하고 있는 Thread 정보를 확인할 수 있다. 해당 정보 내 항목은 Thread List 항목과 유사하며, 다음과 같은 추가 항목이 존재한다.

Table 83. Active Service List 항목
항목설명비고

Sql

현재 수행 중인 SQL문

DataSource 창

Application Server에 설정된 DataSource 정보를 확인할 수 있다.

diagnostics current status datasource
Figure 23. DataSource 탭 화면
DataSource Chart

Active Connection 수와 Idle Connection 수가 Chart에 실시간으로 표시된다. 차트의 붉은 점선은 설정된 최대 Connection 수를 의미한다. Active Connections가 붉은 점선에 근접할 경우 유의해야 한다. 콤보박스에서 DataSource를 선택하여 다른 DataSource를 모니터링 할 수 있다.

최대 Connection 수는 DataSource 정보 등록화면의 maxConnection 속성을 통해 변경할 수 있다.

DataSource Information

지정한 Datasource의 설정 정보를 확인할 수 있다.

7.1.3. 모니터링 설정

DIAGNOSTICS > Policy > Common Rule Setting 메뉴에서 모니터링 기본 설정을 할 수 있다. 설정 항목은 다음과 같다.

Table 84. 모니터링 관련 기본 설정 항목
항목설명기본값

Status Range

Monitoring Dashboard 에서 Resource의 Low, Middle, High 기준을 설정한다.

60% 미만일 경우 Low, 60% 이상일 경우 Middle, 80% 이상일 경우 High를 의미한다

Diagnostics Interval

진단 주기를 설정한다.

10000(ms)

Dump Limit

각 서버의 Dump(Thread/ActiveService/Heap) 디렉토리 별 Dump 개수 제한(0은 무제한을 의미)

200(개)

7.2. Analysis Dashboard

Analysis Dashboard에서 시스템 단위로 실시간 장애 분석 현황 정보를 제공한다. 제공하는 정보 제공 유형은 아래와 같다.

  • Performance Map

  • Analysis Summary

  • Instance Map

diagnostics analysis dashboard
Figure 24. Analysis Dashboard

7.2.1. Performance Map

Analysis Dashboard의 좌측 상단에 보이는 Performance Map은 "Thread & Elapsed", "Thread", "Elapsed" 기준으로 시스템의 상태 정보를 각각 제공한다. 각 시스템은 Chart상에서 색깔을 가진 원으로 표시된다. 시스템의 상태 별 색상은 다음과 같다.

  • Normal: 녹색

  • Anomaly: 주황색(진단 결과로 Anomaly 상황이 검출됨)

  • Fault: 붉은색(진단 결과로 Fault 상황이 검출됨)

Chart에서 X축과 Y축의 의미는 다음과 같다.

Table 85. Performance Map Chart의 X, Y축 의미
항목설명비고

Thread & Elapsed Chart

X축: 시스템 내 Web Application Server의 평균 Thread 사용률

Y 축: 시스템 내 Web Application Server에서 수행되는 서비스의 평균 응답시간

Thread Chart

X축: 10분 동안의 Time Line

Y 축: 시스템 내 Web Application Server의 평균 Thread 사용률

Elapsed Chart

X축: 10분 동안의 Time Line

Y 축: 시스템 내 Web Application Server에서 수행되는 서비스의 평균 응답시간

Chart 상단에 표시되는 System 상태 요약 정보는 다음과 같다.

Table 86. System 상태 요약 정보 항목
항목설명비고

Normal

정상 System의 수

Slow

응답 시간이 오래 걸리는 System의 수

Heavy

Thread pool사용량이 많은 System의 수

Slow & Heavy

Slow하고 Heavy한 System의 수

Chart 하단의 슬라이드 바를 조작해 이전 상태 정보를 볼 수 있으며, 이전 10분 아이콘, 다음 10분 아이콘, 일시 정지 아이콘, 재생 아이콘, 현재 시간 이동 아이콘 을 클릭해 시간을 이동할 수 있다. Dashboard에 처음 진입하면 전체 시스템이 표시되며, Chart 내에서 표시되는 시스템이나 범례를 클릭해서 특정 시스템만 선택해 볼 수 있다. 다시 전체 시스템 전체를 보려면 우측 상단의 All System 아이콘 을 클릭한다.

시스템 아이콘 위에서 마우스 우클릭을 하면 다음과 같은 기능을 수행할 수 있다.

Table 87. 시스템 아이콘에서 우클릭 시 사용 가능한 기능
항목설명비고

Topology View

Topology View 화면으로 이동

Service Analysis

System Detail 팝업 창 표시

Monitoring

Monitoring Dashboard 화면으로 이동

Statistics

Statistics 화면으로 이동

시스템 우클릭 기능 중에 Service Analysis 클릭 시 표시되는 팝업 창은 다음과 같다. WEB, WAS, SESSION 서버의 현재 상태가 좌측에 표시된다. 우측에는 Transaction Heat Map Chart를 볼 수 있으며, 영역을 드래그 하면 상세 정보를 확인할 수 있다.

diagnostics analysis system detail
Figure 25. System Detail 화면

Transaction 정보는 LENA Dashboard에서 Service Trace 기능을 통해 수집했던 경우에만 남는다.

다음은 Transaction Heat Map Chart내의 원하는 영역을 드래그 한 후 표시되는 Transaction 목록에서 특정 Transaction을 선택했을 때 볼 수 있는 상세 정보 화면이다.

diagnostics analysis system detail xlog
Figure 26. Transaction 상세 정보 화면

상세 정보는 CLIENT(사용자 브라우저 관련), WEB(LENA WEB Server 관련), WAS(LENA WEB Application Server 관련) 측면의 데이터로 구성된다. 각 유형 별 정보에서 볼 수 있는 항목은 다음과 같다.

Table 88. CLIENT 관련 데이터의 항목
항목설명비고

domain lookup time

브라우저가 서버와 접속하기 위한 domain lookup 시간

connection time

브라우저가 서버와 connection 을 맺는 시간

server response time

브라우저가 서버에 요청을 하고 응답을 받은 전체 시간

rendering time

브라우저의 화면 rendering 시간

total complete time

브라우저에서 처리되는 전체 시간

error resource(line)

스크립트 에러 발생 시, 에러가 발생한 라인

error content

스크립트 에러 발생 시, 발생한 에러 내용

Table 89. WEB 관련 데이터의 항목
항목설명비고

elapsed time

WEB에서 처리 수행 시간

WAS 관련 데이터의 항목

  • 기본 정보

Table 90. 기본정보
항목설명비고

objName

요청을 처리한 서버 명

endtime

요청 처리 완료 시간

elapsed

요청 처리 수행 시간

service

요청 서비스 명

ipaddr

호출한 아이피 정보

cpu

CPU 사용 시간

sqlCount

수행된 쿼리 수

sqlTime

쿼리 수행 시간

  • 프로파일 정보

Table 91. 프로파일 정보
항목설명비고

#

프로파일 단계 순서를 나타내는 인덱스

p#

내부 단계인 경우 자신이 속한 부모 인덱스

TIME

해당 단계가 시작된 시간

T-GAP

현재 단계의 시작 시간과 이전 단계의 시작 시간의 차이

CPU

CPU 사용 시간

CONTENTS

각 단계의 내용

CLIENT 와 WEB 관련 정보는 E2E 기능이 ON되어 있어야 수집된다. 부하량을 최소화 하기 위해 기본적으로 OFF되어 있다.

프로파일 정보는 WAS에서 프로파일 설정이 ON되어 있어야 수집된다. 부하량을 최소화 하기 위해 기본적으로 OFF되어 있다.

7.2.2. Analysis Summary

현재 검출된 진단 결과 건수, 오늘 발생한 전체 진단 결과 건수, 지난 날(Default: 1일 전) 발생한 진단 결과 건수의 요약 정보를 보여준다.

Table 92. 분석 요약 정보 항목
항목설명비고

ANOMALY

Fault 상태는 아니지만 주의 깊게 봐야 하는 진단 결과 건수

FAULT

Fault 상태로 진단된 결과 건수

Recent Events는 가장 최근에 발생한 진단 결과를 보여주며, 해당 항목을 클릭하면 Report 정보를 확인할 수 있다.

7.2.3. Instance Map

Performance Map에서 특정 시스템을 선택하면, 화면 하단에서 시스템 내 서버 정보 및 진단 결과를 보여주는 Time Line Chart를 볼 수 있다. 서버는 상태에 따라 다른 색으로 표시되며, 특정 서버를 토글 해 우측 Time Line Chart에서 보이거나 안보이게 할 수 있다. 진단 후 Anomaly나 Fault 상황이 검출되면 Time Line에 주황색(Anomaly 상황)이나 붉은색(Fault)으로 표시되는데, 해당 영역을 더블 클릭하면 Report를 확인할 수 있다.

7.3. Event Dashboard

Event Dashboard를 통해 WAS에서 발생한 이벤트 현황 정보를 제공한다.

이벤트 정보는 WAS에서 생성되어 UDP로 Manager에 전달된다. WAS가 전송한 이벤트 정보는 Manager의 DB에 일정 기간(3달) 동안 보관되며, 해당 이벤트의 상세 SQL 및 Exception Trace 정보는 데이터 크기가 크므로 7일간만 보관된다.

7.3.1. Event 종류

다음과 같이 4가지 종류의 이벤트가 존재한다.

  • WAS의 Out Of Memory Error 발생 이벤트

  • WAS의 Full GC 발생 이벤트

  • WAS의 Stuck Thread 발생 이벤트

  • WAS의 Exception 발생 이벤트

WAS Exception 이벤트는 아래 두 가지 상황에서 생성되어 Manager로 전송된다.

  • 사용자 요청에 대해 Servlet의 service 메서드 바깥까지 Exception 이 Throw 되는 경우

  • 사용자가 설정한 타입의 Exception이 발생한 경우

7.3.2. Event Dashboard를 통한 Event 관리

LENA Manager 의 Event Dashboard에서 수집된 Event를 관리할 수 있다.

diagnostics event dashboard
Figure 27. Event Dashboard

이벤트 발생 추세를 일자 별 라인 차트로 확인할 수 있다. 모든 System 대상으로 볼 수 있으며 특정 System이나 Server 등을 지정해 조회할 수 있다. 달력 버튼 을 클릭해 날자를 변경할 수 있다.

이벤트 목록의 항목은 다음과 같다.

Table 93. Event List 항목
항목설명비고

Event Level

이벤트 수준

다음 유형이 존재함. 4가지 이벤트는 기본적으로 WARNING이며 변경할 수 있음.

  • INFO

  • WARNING(DEFAULT)

  • ERROR

  • CRITICAL

Event Type

이벤트 유형

다음 유형이 존재함

  • OUT-OF-MEMORY

  • FULL-GC

  • STUCK-THREAD

  • ERROR

Target Name

대상 서버 이름

WAS 이름 또는 Service Cluster 이름

System Name

시스템 이름

Message

이벤트 메시지

Error 이벤트는 발생한 Exception 명을, Stuck Thread 이벤트는 Stuck Thread가 발생했음을 알리는 메시지를 남김

Event Date

이벤트 발생 시각

( 삭제 버튼 )

이벤트 삭제 시 선택하는 버튼

개별 이벤트 행을 클릭하면 아래와 같은 Event 상세 정보를 확인할 수 있다.

diagnostics event detail
Figure 28. Event 상세 정보 화면

Event 상세 정보의 공통 항목은 다음과 같다.

Table 94. Event 상세 정보의 공통 항목(Event Common Info)
항목설명비고

Event Level

이벤트 수준

다음 유형이 존재함.

  • WARNING

  • INFO

  • ERROR

  • CRITICAL

Event Type

이벤트 유형

다음 유형이 존재함

  • OUT-OF-MEMORY

  • FULL-GC

  • STUCK-THREAD

  • ERROR

Target Name

대상 서버 이름

WAS 이름 또는 Service Cluster 이름

Target Type

대상 서버 유형

다음 유형이 존재함

  • WAS

  • SERVICE-CLUSTER

System Name

시스템 이름

Event Date

이벤트 발생 시각

Event 별로 서로 다른 상세 정보 항목은 다음과 같다.

Table 95. Out Of Memory 이벤트 상세 정보 항목(Event Detail Info)
항목설명비고

Heap Dump File Name

Out Of Memory Error 발생 시 자동 생성된 Heap Dump 파일 이름

Table 96. Full GC 이벤트 상세 정보 항목(Event Detail Info)
항목설명비고

Full GC Start Time

Full GC 시작 시각

Full GC End Time

Full GC 종료 시각

Previous Full GC Start Time

바로 직전 Full GC 시작 시각

Previous Full GC End Time

바로 직전 Full GC 종료 시각

Memory Usage Before Full GC (MB)

Full GC 수행 전 메모리 사용량

Memory Usage After Full GC (MB)

Full GC 수행 후 메모리 사용량

Table 97. Stuck Thread 이벤트 상세 정보 항목(Event Detail Info)
항목설명비고

Service

서비스 URL

Http Query

서비스 URL의 get 파라미터

post 데이터는 보이지 않음

get 파라미터 키는 표시되지만 값은 Masking 처리되어 표시됨

Threshold(ms)

LenaStuckThreadDetectionValve에 설정한 임계값

Active Time(ms)

Stuck Thread 감지 시점의 해당 서비스 처리 시간

Stack Trace

Stuck Thread 감지 시점의 Stack Trace

Table 98. Error 이벤트 상세 정보 항목(Event Detail Info)
항목설명비고

Service

서비스 URL

Http Query

서비스 URL의 get 파라미터

post 데이터는 보이지 않음

get 파라미터 키는 표시되지만 값은 Masking 처리되어 표시됨

Remote Addr

Client 리모트 주소

Custom Info

사용자 정의 코드 정보

사용자가 커스텀 Servlet Filter를 사용해 지정한 Key, Value

Exception Trace

발생한 Exception의 Trace

7.4. 통계

7.4.1. 연간 진단/대응 통계

DIAGNOSTICS > Statistics > Statistics 메뉴에서 서버 별 연간 진단 결과를 차트를 통해 제공한다.

diagnostics statistics
Figure 29. Statistics 화면

위 화면에서 다음과 같은 내용을 확인할 수 있다.

  • Diagnostics Calendar

    • 한 칸이 하루를 의미하며, 연간 통계 차트의 일자에 Mouse Over를 하면 해당 일자에 발생한 진단 횟수를 확인할 수 있다.

  • Daily Diagnostics Detail

    • Diagnostics Calendar에서 특정 일자를 클릭하면, 화면 하단에 선택한 일자의 시간대 별 진단 발생 그래프가 표시 된다.

7.4.2. 리포트

진단 및 대응 기능이 수행되면 Report가 자동으로 생성된다. Report는 7일간 보관되며 오래된 Report는 자동으로 삭제된다.

진단/대응 리포트 목록

DAIGNOSTICS > Statistics > Statistics 화면에서 특정 서버를 선택한 후, Report List 버튼 을 클릭하면 진단/대응 리포트 목록 화면을 볼 수 있다. 진단/대응 리포트 목록 화면은 아래와 같다.

diagnostics report list
Figure 30. 진단/대응 리포트 목록 화면

View 버튼 을 선택하여 Report를 확인할 수 있다.

리포트 공통 정보

Report의 내용은 진단 결과에 따라 다르게 표시되지만, 다음과 같은 공통 정보를 가진다.

diagnostics report
Figure 31. 진단/대응 리포트 화면

위와 같이 이상 현상이 지속된 기간 내에 검출된 진단 결과간의 인과 관계를 도식화해 제공하며, 화면 하단에는 각 진단 결과가 어느 시간대에 생성됐는지 보여준다.

Anomaly 상황은 진단/대응 Rule에 설정한 설정 내용의 일부만 충족된 상황을 의미하며 주황색으로 표시되고, Fault 상황은 진단/대응 Rule에 설정한 설정 내용의 모두를 만족한 상황을 의미하며 붉은색으로 표시된다.

리포트 상세 정보

Report 하단의 Time Line에서, 특정 시간대의 특정 진단 유형을 클릭하면 다음과 같이 상세 정보를 확인할 수 있다.

diagnostics report detail
Figure 32. 진단/대응 리포트 상세 정보

Report 상세 정보의 항목은 다음과 같다.

Table 99. Report 상세 정보 항목
항목설명비고

Root Cause

원인이 되는 진단 항목

해당 진단 결과를 야기한 원인이 되는 진단 항목을 의미하며, 만약 해당 진단 결과의 원인이 되는 다른 진단 항목이 존재한다면 다른 진단 항목이 표시됨

Analysis Rule

진단/대응 Rule에 설정된 임계

Fault Analysis Raw Data

진단 근거가 되는 Back Data

Pre-Action for Fault Tolerance

수행된 Action 및 Dump 파일 명

Recommended Solution

조치 가능한 해결책

진단/대응 유형 별 Back Data 항목은 다음과 같다.

Request Full 진단 Report의 Back Data는, 가장 많이 호출된 5개의 서비스 정보이다.

Table 100. Request Full 진단 Report의 Back Data 항목
항목설명비고

Service Name

서비스 이름

Requested Count

해당 서비스 요청 수

Avg. Elapsed Time

해당 서비스 평균 응답 시간

Max Elapsed Time

해당 서비스 중에서 가장 오래 수행된 서비스의 응답 시간

Min Elapsed Time

해당 서비스 중에서 가장 짧게 수행된 서비스의 응답 시간

대량 DB Data 요청 진단 Report의 Back Data는, 대량 DB Data 요청을 가장 많이 한 5개의 서비스 정보이다.

Table 101. 대량 DB Data 요청 진단 Report의 Back Data 항목
항목설명비고

Service Name

서비스 이름

Count

해당 서비스 요청 수

Blocked Count

Block된 DB 데이터 조회 건수

DB Conn Full 진단 Report의 Back Data는, 과다 점유된 DataSource Connection Pool 정보이다.

Table 102. DB Conn Full 진단 Report의 Back Data 항목
항목설명비고

DataSource Name

DataSource 이름

DB Connection Pool Usage Rate

DB Connection Pool 사용률

Long Transaction 진단 Report의 Back Data는, 진단 대상 서비스 중에서 가장 오래 걸린 5개의 서비스이다.

Table 103. Long Transaction 진단 Report의 Back Data 항목
항목설명비고

Service Name

서비스 이름

Requested Count

해당 서비스 요청 수

Avg. Elapsed Time

해당 서비스 평균 응답 시간

Max Elapsed Time

해당 서비스 중에서 가장 오래 수행된 서비스의 응답 시간

Min Elapsed Time

해당 서비스 중에서 가장 짧게 수행된 서비스의 응답 시간

Peak Control 진단 Report의 Back Data는, 진단 대상 서비스 중에서 가장 오래 걸린 5개의 서비스이다.

Table 104. Peak Control 진단 Report의 Back Data 항목
항목설명비고

Service Name

서비스 이름

Requested Count

해당 서비스 요청 수

Avg. Elapsed Time

해당 서비스 평균 응답 시간

Max Elapsed Time

해당 서비스 중에서 가장 오래 수행된 서비스의 응답 시간

Min Elapsed Time

해당 서비스 중에서 가장 짧게 수행된 서비스의 응답 시간

OOM 진단 Report의 Back Data는, OOM 발생 여부 및 메모리 사용 정보이다.

Table 105. OOM 진단 Report의 Back Data 항목
항목설명비고

OOM Occurred

OOM 발생 여부

Heap Usage Rate

Heap Memory 사용률

Full GC Count

Full GC 발생 횟수

Memory Leak

Memory Leak 발생 여부

Heap Dump

Heap Dump가 생성된 경우 파일 이름

Hang 진단 Report의 Back Data는, 서버 상태 및 시스템 리소스 정보이다.

Table 106. Hang 진단 Report의 Back Data 항목
항목설명비고

Node CPU Rate

Node Agent가 측정한 시스템의 CPU 사용률

Node Memory Rate

Node Agent가 측정한 시스템의 Memory 사용률

Process CPU Rate

서버의 CPU 사용률

Full GC Count

서버의 Full GC 횟수

7.4.3. 알림

진단/대응을 통해 Report가 생성되면, 다음과 같이 LENA Manager 우측 상단의 종 아이콘 을 통해 확인 가능하다.

diagnostics alert
Figure 33. 진단/대응 결과 알림

알림 내용을 선택하면 생성된 Report를 바로 확인할 수 있으며, 알림 내용을 확인하고 더 이상 표시하지 않기를 원한다면 x 버튼 을 클릭한다. 알림이 많은 경우 Manager 우측 상단의 종 아이콘 을 선택한 후 Notifications 화면에서 일괄적으로 확인을 할 수 있다.

diagnostics alert list
Figure 34. 진단/대응 결과 알림 목록 일괄 확인

Home 아이콘 을 클릭하면 선택한 알림에 대한 진단 이력 화면으로 이동한다. V 아이콘 을 클릭하는 것은 선택한 알림을 확인했다는 것을 의미하며, 이렇게 클릭한 알림은 Manager 우측 상단의 종 아이콘 에 더이상 표시되지 않는다.

Notifications 화면에서는 1개월 이내의 지난 알림에 대한 이력을 확인할 수 있다. 1개월이 지난 데이터는 자동으로 삭제된다.

7.5. 진단 및 대응

진단 및 대응 기능을 사용하면, 장애 가능성 사전에 진단하고 적절한 대응을 자동으로 수행하여 Server 안정성을 높일 수 있다.

  • 진단 기능은 Rule기반으로 Server의 장애 가능성(또는 장애 상황)을 자동으로 판단하는 기능이다.

  • 대응 기능은 진단 결과를 기반으로 적절한 Server 제어를 통해 장애 상황를 이겨내고 안정적인 서비스를 할 수 있도록 지원하는 기능이다.

진단 대상 유형은 다음과 같다.

  • Request Pool의 과다 사용(Reqeust Full)

    • 과도한 서비스 요청으로 Server의 가용한 Request Thread가 모두 소진되면, 서비스 요청이 지연되거나 서비스 불가 상태에 빠질 수 있다. Request Thread 사용량 기반으로 과도한 서비스 요청 여부를 파악하고, 자동으로 해당 요청을 임시 페이지로 우회시켜 Server를 안정적인 상태로 유지한다.

  • 대량 DB Data 요청(Bulk DB Data Request)

    • 서비스가 대량 DB 데이터를 처리하는 경우, 메모리를 과도하게 사용하면서 OOM 현상, 잦은 Full GC에 의한 서버 Hang 현상 등이 발생할 수 있다. 서비스의 대량 DB 데이터 요청 여부를 파악하고, 해당 서비스를 강제로 종료시켜 Server를 안정적인 상태로 유지한다.

  • DB Connection Pool의 과다 사용(Db Conn Full)

    • DB 처리 시간 지연, WAS-DB간 네트워크 지연, DB Lock 등에 의해 DB Connection이 과도하게 점유된 경우, 서비스는 가용 DB Connection을 할당 받을 때까지 지연된다. DB Connection 할당을 기다리는 서비스들이 누적되어 Request Thread Pool을 과도하게 점유하게 되면, 서비스 불능 상태까지 발생할 수 있다. 특정 DataSource의 DB Connection이 모두 소진된 경우, 할당 대기 시간을 짧게 줄이는 방법을 통해 장애를 격리함으로써 Server를 안정적인 상태로 유지한다.

  • 수행 시간이 긴 서비스(Long Transaction)

    • 일시적인 네트워크, 연계시스템 문제 등으로 서비스가 지연되거나 수행시간이 원래 긴 서비스가 존재하는 경우, 해당 서비스들이 Server의 가용한 Request Thread를 과도하게 점유하여 다른 서비스 수행에 지장을 줄 수 있다. 오래 걸리는 서비스들의 Request Thread 사용률을 제한하여 다른 서비스들의 QoS를 보장한다.

  • 서버 동작 불능(Hang)

    • Server가 동장 불능 상태인 Hang 상태가 되면 Server에서 수행되는 모든 작업이 중단되는 것은 물론 Server가 설치된 시스템 전체에 영향을 줄 수도 있다. Hang 상태가 검출되면 즉시 재기동해 Server의 장애 상황을 해소하고 시스템 전체 장애 발생을 방지한다.

  • Out of Memory 에러 발생(OOM)

    • 서비스 로직의 오류 또는 과도한 Memory 사용에 의해 Out of Memory(OOM) 에러가 발생할 수 있다. OOM이 발생하면 Server의 정상적인 동작을 보장할 수 없으므로, OOM 발생 여부를 빠르게 파악하여 신속히 자동으로 재기동함으로써 Server 장애 상황을 극복한다.

  • 사용자 폭주(Peak Control)

    • Server의 처리 한계를 넘는 많은 사용자의 요청이 존재하는 경우, 서비스 지연 또는 불능 상태가 될 수 있다. 만약 사용자 요청이 특정 서비스에만 몰린다면 순서대로 진입하도록 요청을 제어하여 안정적인 서비스를 제공하면서도 사용자의 이탈을 막을 수 있다. 또한 다른 서비스 QoS도 보장할 수 있다.

7.5.1. 진단/대응 Rule 설정

DIAGNOSTICS > Policy > Diagnostics Rule Setting 메뉴에서 진단/대응 Rule을 설정할 수 있다.

diagnostics current status diagnostics rule setting
Figure 35. Diagnostics Rule Setting 화면

진단/대응 유형 별로 Tab으로 구성되어 있으며, 기본적인 Default Rule 이 제공된다. New 버튼 을 클릭해 신규 Rule을 생성하거나, 기존의 Rule을 선택해 수정 및 삭제를 할 수 있다.

각 진단 항목별로 다음과 같이 두 개의 Default Rule이 제공된다.

  • 진단 후 Report만 생성하는 Rule

  • 진단 후 Report 및 Dump를 생성하는 Rule(Action은 Disable되어 제공됨)

진단 유형 별 Rule 설정 항목을 다음과 같다.

Table 107. Request Full 진단 Rule
항목설명기본값

Rule Name

Rule 이름

Request Pool(%)

Request Pool 사용률 임계

100

Report

Report 생성여부(항상 Enable)

Enable

Dump

이상으로 판단되면 생성할 Dump 유형

  • Thread: Thread Dump

  • Service: Active Service Dump

Enable

Server Control

이상으로 판단되면 수행할 Action

  • NONE: 수행 안함

  • FAKE-PAGE: 임시 페이지로 요청을 우회(우회 페이지 지정 가능)

NONE

Table 108. 대량 DB Data 요청 진단 Rule
항목설명기본값

Rule Name

Rule 이름

RS Count

서비스 내에서 요청한 DB Data 건수 임계

10000

Exceptional URI

진단에서 제외할 서비스 URI

Report

Report 생성여부(항상 Enable)

Enable

Dump

이상으로 판단되면 생성할 Dump 유형

  • Thread: Thread Dump

  • Service: Active Service Dump

Enable

Server Control

이상으로 판단되면 수행할 Action

  • NONE: 수행 안함

  • THROW-EXCEPTION: Exception을 발생시켜 서비스를 강제로 종료

NONE

Table 109. DB Conn Full 진단 Rule
항목설명기본값

Rule Name

Rule 이름

DB Connection Pool(%)

DB Connection Pool 사용량 임계

100

Report

Report 생성여부(항상 Enable)

Enable

Dump

이상으로 판단되면 생성할 Dump 유형

  • Thread: Thread Dump

  • Service: Active Service Dump

Enable

Server Control

이상으로 판단되면 수행할 Action

  • NONE: 수행 안함

  • DB-CONN-CONTROL: Datasource Connection 할당 대기 시간 동적 변경(대기 시간 설정 가능)

NONE

Table 110. Long Transaction 진단 Rule
항목설명기본값

Rule Name

Rule 이름

Elapsed Time(s)

진단 대상 서비스 수행 시간 임계

300

Service Allow Rate(%)

진단 대상 서비스에게 허용할 Request Thread 사용률 임계

50

Target URI

대상 서비스 URI

Report

Report 생성여부(항상 Enable)

Enable

Dump

이상으로 판단되면 생성할 Dump 유형

  • Thread: Thread Dump

  • Service: Active Service Dump

Enable

Server Control

이상으로 판단되면 수행할 Action

  • NONE: 수행 안함

  • SERVICE-CONTROL: 임시 페이지로 요청을 우회(우회 페이지 지정 가능)

NONE

Table 111. Hang 진단 Rule
항목설명기본값

Rule Name

Rule 명

Timeout(ms)

서버에 Health Check 시도 후, 응답 대기 시간 임계

3000(ms)

Retry Count

서버에 Health Check 실패 시, 재시도 횟수

3

FullGC Duration(s)

Full GC 횟수를 체크할 시간 간격

60

FullGC Count

Full GC 횟수

2

Report

Report 생성여부(항상 Enable)

Enable

Dump

이상으로 판단되면 생성할 Dump 유형

  • Thread: Thread Dump

Enable

Server Control

이상으로 판단되면 수행할 Action

  • NONE: 수행 안함

  • SHUTDOWN: 서버 종료

  • RESTART: 서버 재시작

NONE

Hang 진단 설정 항목간의 관계는 다음과 같다.

  • Fault 조건 : 서버 Hang에 의해 Health Check 시도 후 Timeout(s) 만큼 응답 없는 상황이 Retry Count 만큼 반복되면 Fault 상황으로 판단하여 Action을 수행함

  • Anomaly 조건 : FullGC Duration(s) 간격 내 FullGC Count 만큼 Full GC 발생 횟수가 많다면 Anomaly 상황으로 판단하여 Action 없이 Waning 리포트만 생성함

Table 112. OOM 진단 Rule
항목설명기본값

Rule Name

Rule 이름

OUT OF MEMORY

OOM 발생 여부(Fault 상황으로 판단함)

별도 설정 없이 발생 여부 검출

Memory Leak

Memory Leak 발생 여부(Anomaly 상황으로 판단함)

별도 설정 없이 발생 여부 검출

Report

Report 생성여부(항상 Enable)

Enable

Dump

이상으로 판단되면 생성할 Dump 유형

  • Thread: Thread Dump

  • Service: Active Service Dump

Enable

Server Control

이상으로 판단되면 수행할 Action

  • NONE: 수행 안함

  • SHUTDOWN: 서버 종료

  • RESTART: 서버 재시작

NONE

Table 113. Peak Control 진단 Rule
항목설명기본값

Rule Name

Rule 이름

Target URI

Peak Control 대상 서비스 URI

Service Allow Rate(%)

진단 대상 서비스에게 허용할 Request Thread 사용률 임계

50

Release Rate(%)

이상 상황 해제 조건이 되는 Request Thread 사용률 임계

10

Report

Report 생성여부(항상 Enable)

Enable

Dump

이상으로 판단되면 생성할 Dump 유형

  • Thread: Thread Dump

  • Service: Active Service Dump

Enable

Server Control

이상으로 판단되면 수행할 Action

  • NONE: 수행 안함

  • PEAK-CONTROL: 임시 페이지로 요청을 우회(우회 페이지 지정 가능)

NONE

7.5.2. Server Rule 설정

DIAGNOSTICS > Policy > Server Rule Setting 메뉴에서 진단/대응 Rule을 Server에 Mapping하고 Enable/Disable 할 수 있다.

최초에는 아무 진단 Rule도 Mapping되어 있지 않으므로, Enable/Disable 기능을 수행하기 전에 진단/대응 Rule을 먼저 Mapping해야 한다. 각 서버의 행을 클릭하여 다음과 같이 서버에 진단/대응 Rule을 Mapping 할 수 있다.

diagnostics current status server rule mapping
Figure 36. 진단 Rule Mapping 화면

진단/대응 Rule이 Mapping된 이후에는 다음과 같이 Server Rule Setting 화면에서 Rule을 Enable/Disable 할 수 있다.

diagnostics current status server rule setting
Figure 37. Server Rule Setting 화면

Peak Control 진단 Rule만 DIAGNOSTICS > Policy > Peak Control Rule Setting 메뉴에서 설정한다.

7.6. Trace

Trace는 장애 진단을 위해 해당 Request가 LENA Server 간 이동 경로 및 시간을 기록해 원인을 진단 할 수 있게 해준다. LEAN 에서 제공하는 Trace유형은 아래와 같다.

  • Session Trace

  • Event Trace

DIAGNOSTICS > Trace 메뉴의 하위 메뉴를 통해 여러 기능을 사용할 수 있다.

7.6.1. Session Trace

Session 의 Trace 정보(어느 Server에 해당 Session이 존재하는지)를 확인할 수 있다. Session을 찾기 위해서는 Cluster된 Session Server가 기동중이어야 한다.

diagnostics session trace
Figure 38. Session Trace 화면

조회 결과 항목은 다음과 같다.

Table 114. Session Trace 조회 결과 항목
항목설명비고

Server Type

Server의 유형

Session Server: LENA Session Server

LENA Server: LENA Application Server

Server Name

Server 이름

Session Server인 경우, 검색 대상 Server가 Primary이고 검색 대상 서버의 Slave Server가 Secondary 이다

Create Time

Session 생성 시각

Last Update Time

Session이 마지막으로 수정된 시각

Last Access Time

Server에 해당 Session을 마지막으로 호출한 시각

Attribute

Session Attribute

Context

Session의 Application Context

7.6.2. Event Trace

장애로 판단되는 이벤트가 발생되었을 때, 해당 Request의 Trace 정보를 확인 할 수 있다.

diagnostics event trace
Figure 39. Event Trace 화면

Trace 정보는 일주일 동안만 보관된다. 이벤트가 발생한 날짜는 검색 조건의 Trace Date에 표시 된다. 검색 결과에서 Status 항목은 발생한 이벤트의 중요도를 의미한다.

Table 115. Event Trace 검색 결과 항목
항목설명비고

Trace Time

이벤트가 발생한 Request의 처리 종료 시각

WEB서버의 종료 시각

UID

Request를 호출한 User ID. 한 User가 각각 다른 브라우저를 사용 할 경우 UID는 다르게 처리 됨.

WEB

Request를 처리한 WEB Server

 

WAS

Request를 처리한 WAS

 

Event

발생한 Event

 

SESSION ID

해당 Request의 Session ID

 

Detail

상세정보를 확인할 수 있는 버튼

검색 결과의 Detail의 상세 조회 버튼 을 누르면 상세 정보를 확인할 수 있다. 각 항목은 다음과 같다.

Table 116. Event Trace 정보의 상세 정보 항목
항목설명비고

Trace Time

이벤트가 발생한 Request의 처리 종료 시각

WEB서버의 종료 시각

UID

Request를 호출한 User ID. 한 User가 각각 다른 브라우저를 사용 할 경우 UID는 다르게 처리 됨.

WEB

Request를 처리한 WEB Server

WAS

Request를 처리한 WAS

Event

발생한 Event

JVMRoute

Request를 처리한 WAS의 JVMRoute 값

SESSION ID

해당 Request의 SESSION ID

Session Server

Request를 처리한 Session Server

연결된 WAS의 Primary/Secondary Session Server로 표기됨

URL

Request의 URL

Trace되는 이벤트는 아래와 같다.(Event Code는 Log 파일을 보면 확인할 수 있다. 화면에서는 코드를 문장으로 풀이해 보여준다.)

Table 117. Trace되는 이벤트 코드 및 설명
Event Code설명비고

sywz

Session ID와 JVMRoute 정보가 다름.(WAS 장애로 Failover가 되었을 경우 발생 할 수 있음.)

Session ID does not match with JVMRoute.

wxso

WAS에 Session정보 없으나 Session Server Session정보 있음.(WAS 장애로 Failover가 되었을 경우 발생 할 수 있음.)

Session does not exist in Application Server.

wosx

WAS에 Session정보가 있으나 Session Server에 Session정보 없음.(Session Server 두 대를 재 기동 했을 경우 발생 할 수 있음.)

Session does not exist in Session Server.

wxsx

WAS에 Session정보 없고, Session Server에 Session정보 없음.(Session Server 두 대 모두 중지 시킨 경우 발생 할 수 있음)

Session does not exist in any Server.

woxx

WAS에 Session 정보가 있으나, Primary & Secondary session server와 연결 끊김.(Session Server 두 대 모두 중지 시킨 경우 발생 할 수 있음)

Session Server does not respond.

wxxx

WAS에 Session 정보가 없고, Primary & Secondary session server와 연결 끊김.(WAS에 해당 Session이 Timeout 및 Session Server 두 대 모두 중지 시킨 경우 발생 할 수 있음)

Session Server does not respond.

sywz 이벤트와 wxso 이벤트가 한 Request에서 중복 발생되는 경우, 하나의 검색 결과에 두 이벤트가 모두 표시 된다.

7.6.3. Trace Setting

다음은 Event/Time Trace 설정을 하는 화면이다.

diagnostics trace setting
Figure 40. Trace Setting 화면

Trace 설정 항목은 아래와 같다.

Table 118. Trace Setting 항목
항목설명비고

Trace On/Off

Trace 여부

재기동 없이 적용된다

Type

UDP: Trace 생성 조건이 되면, UDP로 Manager에 Trace 정보를 전송

LOG: Trace 생성 조건이 되면, Log로 Trace 정보 저장

ALL: Trace 생성 조건이 되면, UDP와 LOG 기능을 모두 사용

Data

EVENT: Event가 발생한 경우 Trace 기록

UID: 해당 UID인 Request만을 Trace로 기록

UID

입력된 UID인 Request만 Trace로 기록

8. Topology

각 시스템의 구성현황을 한눈에 알아볼 수 있으며, 설치 및 설정기능을 제공하고, 자원 모니터링 및 기동/중지 제어를 할 수 있다.

topology overview
Figure 41. Topolopgy 화면

8.1. 화면 구성

System 영역, 토폴로지 영역, 자원 모니터링 영역, 서비스 트레이싱 영역으로 구분된다.

  • System 영역

    등록된 System 리스트를 카드 형태로 제공한다.

    카드 내의 시스템 명 좌측의 아이콘은 시스템의 상태를 의미하는데 상태를 표시하는 기준은 시스템을 구성하는 Resource와 진단 결과에 따라 3단계로 나뉘어 나타낸다.

    • 파란색 원 아이콘 : 시스템을 구성하는 모든 서버의 자원 사용량이 Low, 진단 프로세스가 수행되지 않은 상태

    • 주황색 원 아이콘 : 시스템을 구성하는 모든 서버의 자원 사용량이 Middle 이하 또는 진단 프로세스 수행 결과가 Abnormal 상태

    • 붉은색 원 아이콘 : 시스템을 구성하는 일부 서버의 자원 사용량이 High 인 경우 또는 진단 프로세스 수행 결과가 Fault 상태

      시스템 명 하단의 시계 아이콘 은 시스템 내의 WAS들의 평균 응답시간을 의미하고, 사용자 아이콘 은 현재 사용자 수(최근 5분 동안) / 오늘 전체 사용자 수를 의미한다.

      자원사용량의 Low, Middle, High에 대한 기준은 DIAGNOSTICS > Policy > Common Rule Setting > Dashboard 항목에서 변경 할 수 있다.

  • 토폴로지 영역

    시스템 별 노드와 서버 Instance 구성현황을 토폴로지 차트로 보여준다. 각 Node에 설치한 WEB, WAS, Session Server를 설치 및 실행, clustering 을 할 수 있고, 서버 상태 정보를 확인 할 수 있다. 뿐만 아니라 WEB Server-WAS 간 ,WAS-Session Server, WAS-Datasource간에 연동을 설정할 수 있다.

  • 자원 모니터링 영역

    Node와 Server의 CPU, Memory 등 상세 자원 모니터링 정보를 제공한다.

  • Service Tracing 영역

    특정 Client IP와 요청 Service Pattern을 기준으로 서비스를 트레이싱하여 Request 수, 평균 응답시간, 서비스 응답 error 수를 확인 할 수 있다.

시스템목록 우측에 있는 설정 버튼 을 통해 다음의 사항을 변경 할 수 있다.

Chart

  • Refresh Interval : 토폴로지 영역의 데이터 조회 주기

  • Refresh Topology Chart : 토폴로지 영역의 차트 그리는 메타데이터 정합성 검증 및 복원

System List

  • System 목록에 보여줄 System 선택 및 순서 변경

Elements

  • Show Endpoint : Endpoint 영역 표시 여부 설정

  • Show Edge Info : Edge에 상세정보 표시 여부 설정

  • Show Server Name : Server명 표시 여부 설정

Transparency

  • Node : 토폴로지 영역의 Node 투명도를 설정

  • Edge : 토폴로지 영역의 Edge 투명도를 설정

8.2. 토폴로지 영역 상세

토폴로지에서 뷰 모드에 따라 정보를 구분하여 보여준다.

  • View All : 전체 정보를 보여준다.

  • Low : 서버의 자원 사용량이 Low 인 인스턴스만 구분하여 보여준다.

  • Middle : 서버의 자원 사용량이 Middle 인 인스턴스만 구분하여 보여준다.

  • High : 서버의 자원 사용량이 High 인 인스턴스만 구분하여 보여준다.

  • Stop/unknown : 중지된 인스턴스만 구분하여 보여준다.

또 Cluster로 단위로 인스턴스들을 활성화하여 보여준다.

진단기능이 설정되어 있는 WAS의 경우, 자원사용량을 체크하기 이전에 서버상태의 진단 결과가 Abnormal 또는 Fault 인지를 우선적으로 확인한다. 해당 상태로 판단되는 경우에는 High 상태로 표시해준다.

8.2.1. Control [Edit: OFF]

E2E (End to End)관점하에 Client부터 Database까지 상세한 모니터링 정보 및 제어 기능을 제공한다.

topology control edit off
Figure 42. Topolopgy Control [Edit: OFF]
CLIENT 영역

Client는 사용자를 말하며, 사용자가 Web서버에 요청을 주고 받는 브라우저 화면 Rendering 시간 및 Script error 내용을 확인 할 수 있다.

WEB 영역

WEB 영역에서는 설치된 WEB Node 와 WEB 서버 정보를 제공하고 서버의 제어 할 수있다.

  • 구성정보

    Web Node는 Web 서버가 설치되는 영역으로 노드 별 서버 설치 현황을 확인 할 수 있다.

  • 모니터링 정보

    Web Node에서는 기본적으로 CPU, Memory, Disk 상태 정보를 제공한다.

    Web Server에 마우스를 갖다 대면 팝업 형태로 서버의 CPU, Memory, Thread 상태 정보를 제공한다.

    Web Node와 Server를 선택하면 토폴로지 영역 우측에 있는 자원 모니터링 영역에 각각의 실시간 상세 모니터링 정보가 제공된다.

    • Node : CPU, Memory, Disc, Network와 기본 정보

    • Server : CPU, Memory, Thread, QoS와 기본 정보

  • 제어 기능

    Server에 대해 크게 3가지 제어 기능을 제공한다.

    1. Server Control : Start, Stop, Service Control

      Service Control은 무중단 적시배포 기능을 제공한다. 이것은 오류 서비스 발생시 이를 수정한 소스를 WAS에 긴급 배포하고 이 WAS를 호출 할 Web 서버(적시서버)를 구성한 후 오류가 발생된 서비스를 요청 받은 Web 서버들이 적시서버로 서비스를 포워딩하여 서비스가 정상적으로 제공되게 하는 방식이다.

      이 기능을 사용하려면 Web Server에서 LSC모듈이 사용되도록 설정이 되어 있어야 한다.(httpd-lsc.conf 파일에서 LscEnable을 On으로 변경 후 서버를 재기동한다.)

      제어시간, 제어조건(Header, Cookie, URL) 및 요청을 forwarding 할 서버(http://IP:Port)를 정의 후 저장하면 정의 된 내용에 따라 실시간으로 들어오는 요청을 해당 서버로 연결하여 서버 재기동 없이 서비스를 제공한다.

    2. Move to : Configuration

    3. Cluster : Compare, Sync, Snapshot, Graceful Restart

APPLICATION 영역

APPLICATION 영역에서는 설치된 WAS Node 와 WAS 정보를 제공하고 서버의 제어 할 수있다.

  • 구성정보

    WAS Node는 WAS가 설치되는 영역으로 노드 별 서버 설치 현황을 확인 할 수 있다.

  • 모니터링 정보

    WAS Node에서는 기본적으로 CPU, Memory, Disk 상태 정보를 제공한다.

    WAS Server에 마우스를 갖다 대면 팝업 형태로 서버의 CPU, Thread, Heap 상태 정보를 제공한다.

    WAS Node와 Server를 선택하면 토폴로지 영역 우측에 있는 자원 모니터링 영역에 각각의 실시간 상세 모니터링 정보가 제공된다.

    • Node : CPU, Memory, Disc, Network와 기본 정보

    • Server : Warning, CPU, Memory, Thread, QoS와 기본 정보

  • 제어 기능

    Server에 대해 크게 4가지 제어 기능을 제공한다.

    1. Server Control : Start, Stop, Forced Stop

    2. Manual Check : Thread Dump, Active Service Dump, Heap Dump

    3. Move to : Configuration, Monitoring

    4. Cluster : Compare, Sync, Snapshot, Graceful Restart

SESSION 영역

SESSION 영역에서는 설치된 Session Node 와 Session 서버 정보를 제공하고 서버의 제어 할 수있다.

  • 구성정보

    Session Node는 Session 서버가 설치되는 영역으로 노드 별 서버 설치 현황을 확인 할 수 있다.

  • 모니터링 정보

    Session Node에서는 기본적으로 CPU, Memory, Disk 상태 정보를 제공한다.

    Session Server에 마우스를 갖다 대면 팝업 형태로 서버의 CPU, Session Count, Heap 상태 정보를 제공한다.

    Session Node와 Server를 선택하면 토폴로지 영역 우측에 있는 자원 모니터링 영역에 각각의 실시간 상세 모니터링 정보가 제공된다.

    • Node : CPU, Memory, Disc, Network와 기본 정보

    • Server : CPU, Memory, Session Count와 기본 정보

  • 제어 기능

    Server에 대해 크게 2가지 제어 기능을 제공한다.

    1. Server Control : Start, Stop

    2. Move to : Configuration

DB 영역

DB 영역에서는 WAS와 연결된 Database 정보를 제공한다. Database는 RESOURCE 메뉴에서 등록되어 있어야 한다. 노드는 다른 영역과의 동일하게 표현하기 위해 가상의 노드로 표현하고 있다. 각 DB에 대한 모니터링 정보나 제어 기능은 제공하지 않는다.

Edge 정보

연결선은 각 인스턴스 간, 또는 인스턴스와 Database간의 연결을 의미하며, 서버 평균 응답시간 및 연결된 Connection 수를 나타낸다.

  • Client-WEB : Connection 수(Client 브라우저 렌더링 평균 완료 시간(ms)/Web Server 평균응답시간(ms))

  • WEB-APPLICATION : Active Connection 수(WAS 평균응답시간(ms))

  • APPLICATION-DB : Active Datasource 사용률 (%)

End to End 모니터링기능은 기본적으로 off상태로 설정되어 있다.

따라서 Client-WEB, WEB-APPLICATION 사이의 브라우저 렌더링 평균응답시간 또는 Server의 평균응답시간을 보기 위해서는 다음의 순서대로 설정을 해주어야한다.

  1. manager.conf 파일에서 diagnostics.e2e.enable=true 로 설정

  2. web server의 httpd.conf 파일에서 httpd-eum.conf 파일주석 해제

    <IfDefine MOD_EUM>
  #LENA E2E Monitoring Extension settings
  Include ${INSTALL_PATH}/conf/extra/httpd-eum.conf <-- 이부분 주석 해제
</IfDefine>

  3. web server의 eum/eum.properties파일에서 agent_enable값을 true로 수정

단, 이 기능은 window OS에서는 지원하지 않는다.

8.2.2. Control [Edit: ON]

토폴로지 영역 우측상단에 Edit 버튼 을 선택하면 편집모드로 전환된다. 여기에서는 시스템 내의 노드와 인스턴스 설치 기능을 제공한다.

topology control edit on
Figure 43. Topolopgy Control [Edit: ON]
Node

노드의 설치/수정/삭제 동작 방식은 node와 동일하다. 따라서 이 장에서는 사용 방식만 설명한다.

  • 설치

    1. Node 버튼 을 선택 후 설치하고자 하는 영역 위에 마우스를 클릭한다.

    2. 화면 우측의 설치 요소 상세정보 영역에 해당 정보를 입력한다.

    3. Save 버튼 을 선택한다.

  • 수정

    1. 변경하고자 하는 노드를 선택한다.

    2. 화면 우측의 설치 요소 상세정보 영역에 해당 정보를 변경한다.

    3. Save 버튼 을 선택한다.

  • 삭제

    1. 삭제하고자 하는 노드를 선택한다.

    2. 우클릭 버튼을 누르면 Hide, Unregister, Uninstall 메뉴 중 원하는 기능을 선택한다.

      노드 삭제시 노드 안에 설치된 서버는 한대도 없어야 한다.

Instance

서버의 설치/수정/삭제 동작 방식은 server와 동일하다. 따라서 이 장에서는 사용 방식만 설명한다.

  • 설치

    1. Instance 버튼 을 선택 후 설치하고자 하는 영역의 노드 위에 마우스를 클릭한다.

    2. 화면 우측의 설치 요소 상세정보 영역에 해당 정보를 입력한다.

    3. Save 버튼 을 선택한다.

      서버가 하나도 설치되어 있지 않은 노드 목록은 각 영역의 아래에 회색바탕 위에 있는 사각버튼으로 제공된다. 빈 노드에 서버를 설치하고 싶은 경우 해당 노드버튼을 더블클릭한다.

  • 수정

    1. 변경하고자 하는 서버를 선택한다.

    2. 화면 우측의 설치 요소 상세정보 영역에 해당 정보를 변경한다.

    3. Save 버튼 을 선택한다.

  • 삭제

    1. 삭제하고자 하는 서버를 선택한다.

    2. 우클릭 버튼을 누르면 Unregister, Delete 메뉴 중 원하는 기능을 선택한다.

Edge

Edge는 서버와 서버의 연결을 의미하며 WEB-APPLICATION, APPLICATION-SESSION, APPLICATION-DB 영역 안의 서버들을 연결 할 수 있다.

  • 연결

    1. Edge 버튼 을 선택 후 연결하고자 하는 시작서버 선택 후 드래그하여 도착서버와 연결한다.

    2. 화면 우측의 설치 요소 상세정보 영역에 해당 정보를 입력한다.

    3. Save 버튼 을 선택한다.

      APPLICATION-SESSION 간에 연결하는 경우, 실선은 Primary Server, 점선은 Secondary Server를 의미한다.

  • 연결 정보 변경

    1. 변경하고자 하는 edge를 선택한다.

    2. 화면 우측의 설치 요소 상세정보 영역에 해당 정보를 변경한다.

    3. Save 버튼 을 선택한다.

  • 연결 해제

    1. 삭제하고자 하는 edge를 선택한다.

    2. 우클릭 버튼의 메뉴인 Delete 버튼을 선택한다.

Cluster

CLUSTER 메뉴에서 제공하는 Server Cluster기능을 설정 할 수 있다.

  • 생성

    1. Cluster 버튼 을 선택한다.

    2. 화면 우측의 설치 요소 상세정보 영역에 해당 정보를 입력한다.

    3. Save 버튼 을 선택한다.

  • 변경

    1. Cluster 버튼 옆 select 박스에서 변경하고자 하는 server cluster를 선택한다.

    2. 화면 우측의 설치 요소 상세정보 영역에 해당 정보를 변경한다.

    3. Save 버튼 을 선택한다.

  • 삭제

    1. Cluster 버튼 옆 select 박스에서 변경하고자 하는 server cluster를 선택한다.

    2. 화면 우측의 설치 요소 상세정보 영역의 Delete 버튼 을 선택한다.

8.3. 서비스 트레이싱 영역 상세

특정 서버의 IP 혹은 Service Pattern을 입력 후 Start 버튼 을 선택하면 입력한 정보를 기준으로 서비스를 트레이싱하여 Request 수, error를 확인 할 수 있다. 트레이싱 하는 동안 서비스 트레이싱 영역 우측에 Xlog 정보도 제공하므로 필요에 따라 xlog를 선택하여 상세한 정보를 확인할 수 있다.

서비스 트레이싱 기능을 사용하기 위해서는 다음의 순서대로 설정을 해주어야 한다.

  1. manager.conf 파일에서 diagnostics.e2e.enable=true 로 설정

  2. tracing 대상 Web server의 httpd.conf 파일에서 httpd-eum.conf 파일주석 해제

    <IfDefine MOD_EUM>
  #LENA E2E Monitoring Extension settings
  Include ${INSTALL_PATH}/conf/extra/httpd-eum.conf <-- 이부분 주석 해제
</IfDefine>

  3. tracing 대상 Web server의 eum/eum.properties파일에서 agent_enable값을 true로 수정

  4. tracing 대상 WAS의 advertiser.conf파일에서 enable.send.profile.info값을 true로 수정

단, 이 기능은 window OS에서는 지원하지 않는다.

9. Admin

9.1. IAM

Manager의 사용자 관리 및 사용자 별 메뉴 권한 관리 기능을 제공한다.

9.1.1. Users (사용자 관리)

사용자 목록

ADMIN > Users 메뉴에서 Manager 사용자의 생성, 수정, 삭제 기능을 제공한다.

admin users
Figure 44. Users 화면

사용자 관리의 속성은 아래와 같다.

Table 119. 사용자 관리 속성
항목(*는 필수값)설명비고

Use ID(*)

사용자 식별자

User Name(*)

사용자 이름

Password(*)

사용자 비밀번호

비밀번호는 특수문자, 숫자, 영문자 혼합의 최소 8자 이상이어야 한다

Updater

사용자 데이터 수정 및 생성자

Last Update

사용자 데이터 수정 및 생성일자

+ 아이콘

New 버튼, 수정 버튼 을 클릭하여 선택된 권한 정보가 변경 중임을 표시

- 아이콘

삭제 버튼 을 클릭하여 선택된 권한 정보가 삭제됨을 표시

기본적으로 관리자 권한을 가진 계정을 두 개 제공한다.(비상용) 제공되는 계정 외에 사용자를 추가하여 사용하기를 권장한다.

사용자 등록

  1. New 버튼 을 클릭하여 신규 사용자 등록을 준비한다.

  2. 사용자 ID, 사용자 명, 사용자 패스워드를 입력한다.

    • 사용자 패스워드는 암호화되어 저장된다.

    • 패스워드는 글자수가8~20자, 영어 대소문자, 숫자, 특수문자(!@#$%^*+=-) 조합으로 작성한다.

  3. Save 버튼 을 클릭하여 사용자 정보를 저장한다.

  • Password 암호화는 해쉬 알고리즘(SHA-512)을 사용한다.

사용자 수정

  1. 수정할 사용자를 선택한다.

  2. 수정 버튼 을 클릭하여 사용자명, 사용자 패스워드를 변경한다.

    • 사용자 패스워드는 암호화되어 저장된다.

  3. Save 버튼 을 클릭하여 사용자 정보를 저장한다.

  • Manager 에 로그인시 7 번 이상 실패하면 해당아이디는 잠김 상태가 되어 사용할 수가 없다.

  • 잠김 상태를 해제하기 위해서는 사용자 관리 화면에서 해당 아이디의 패스워드를 수정해주어야 한다.

  • 패스워드 수정을 위해 Manager 에 로그인 한 계정이 없는 경우에는, $LENA_HOME/bin/reset-manager-pw.sh 를 실행하여 패스워드를 수정할 수 있다.

사용자 삭제

  1. 삭제할 사용자를 선택한다.

  2. 삭제 버튼 을 클릭하여 사용자를 삭제 가능한 상태로 변경한다.

  3. Save 버튼 을 클릭하여 사용자 정보를 저장한다.

사용자가 1명 남은 경우는 삭제할 수 없다.

9.1.2. Auths (권한관리)

Manager는 메뉴 별 권한 관리를 위해 권한 그룹을 생성해야 한다. ADMIN > Auths 메뉴를 통해 권한 그룹을 생성, 수정, 삭제할 수 있다.

권한 목록
admin auths
Figure 45. Auths 화면

권한 관리의 속성은 아래와 같다.

Table 120. 권한 관리 속성
항목(*는 필수값)설명비고

Auth ID(*)

권한 식별자

Auth Name(*)

권한 이름

Description

등록된 권한에 대한 설명

Updater

권한 데이터 수정 및 생성자

Last Update

권한 데이터 수정 및 생성일자

+ 아이콘

New 버튼, 수정 버튼 을 클릭하여 선택된 권한 정보가 변경 중임을 표시

- 아이콘

삭제 버튼 을 클릭하여 선택된 권한 정보가 삭제됨을 표시

권한 생성

  1. New 버튼 을 클릭하여 신규권한 등록을 준비한다.

  2. 권한 ID, 권한 명, 권한 설명을 입력한다.

  3. Save 버튼 을 클릭하여 권한 정보를 저장한다

권한 수정

  1. 수정할 권한을 선택한다.

  2. 수정 버튼 을 클릭하여 권한 명, 권한 설명을 변경 한다.

  3. Save 버튼 을 클릭하여 권한 정보를 저장한다.

권한 삭제

  1. 삭제할 권한을 선택한다.

  2. 삭제 버튼 을 클릭하여 권한을 삭제 가능한 상태로 변경한다.

  3. Save 버튼 을 클릭하여 권한 정보를 저장한다.

9.1.3. User-Auth Mapping (사용자 권한 관리)

Manager 사용자는 메뉴 사용 권한 획득을 위해 최소한 1개의 그룹에 소속되어 있어야 한다. 관리자는 권한 그룹을 선택하여 사용자를 배속시킬 수 있다. "권한 관리" 화면을 통해 등록한 권한 중 하나를 선택하고 여러 셔플 버튼을 사용하여 사용자의 권한을 제어한다.

사용자 권한 조회
admin user auth mapping
Figure 46. User-Auth Mapping 화면

사용자 권한 관리의 속성은 아래와 같다.

Table 121. 사용자 권한 관리의 속성
항목설명비고

권한 명 선택

"권한 관리" 화면을 통해 등록한 권한 리스트로 구성된 콤보박스

ID

사용자 식별자

Name

사용자 이름

사용자 권한 맵핑

  1. 사용자를 배속시킬 권한을 선택한다.

    • 권한 선택 시 선택 가능 사용자와 선택된 사용자가 화면에 출력된다.

  2. 선택 가능 사용자를 선택한다.

  3. 사용자를 배속 시키거나 제외 시킨다.

    • 단일 우측 셔플 버튼 을 클릭하여 선택한 사용자를 배속시킨다.

    • 전체 우측 셔플 버튼 을 클릭하여 모든 사용자를 배속시킨다.

    • 단일 좌측 셔플 버튼 을 클릭하여 선택한 사용자를 제외시킨다.

    • 전체 좌측 셔플 버튼 을 클릭하여 모든 사용자를 제외시킨다.

  4. Save 버튼 을 클릭하여 사용자 권한 관리 정보를 저장한다.

9.1.4. Menu-Auth Mapping (메뉴 권한 관리)

LENA Manager에서 생성한 권한 별로 접근 가능한 메뉴를 설정할 수 있다. 권한 선택을 통해 생성한 권한 중 메뉴를 설정할 하나의 권한을 선택한다. LENA Manager에 등록된 모든 메뉴를 보여주는 메뉴 목록 중 접근 제어를 설정할 메뉴를 선택하고 메뉴권한을 설정한다.

메뉴 권한 조회
admin menu auth mapping
Figure 47. Menu-Auth Mapping 화면

메뉴 권한 관리의 속성은 아래와 같다.

Table 122. 메뉴 권한 관리의 속성
항목설명비고

권한 명 선택

"권한관리" 화면을 통해 등록한 권한 리스트로 구성된 콤보박스

Menu Name

LENA Manager에 등록된 메뉴 중 좌측 메뉴 목록에서 선택한 메뉴 이름

Auth

선택한 권한의 메뉴접근가능여부 표시

Default "N"

"SERVER", "CLUSTER", "RESOURCE" 메뉴의 하위 화면에서 Node, Server, Server Cluster, Resource 을 추가할 경우 자동으로 "메뉴 권한 관리" 화면의 메뉴 목록에 추가한 항목이 조회된다.

따라서 신규 메뉴를 추가하고 싶을 경우 "SERVER", "CLUSTER", "RESOURCE" 하위 화면에서 각 항목을 등록 및 생성하면 된다.

Server에 대한 권한을 변경해야 할 경우 아래 메뉴에 동일하게 권한을 반영해야 한다.

  • "SERVER" 하위의 해당 Server

  • "CLUSTER" 하위의 해당 Server

만약 이를 지키지 않고, Server Cluster 하위의 일부 Server 메뉴에 대해 다음과 같이 권한을 설정할 경우를 고려해보자.(예시, 권장사항 아님)

  • "SERVER" 하위의 해당 Server : 권한 있음

  • "CLUSTER" 하위의 해당 Server : 권한 없음

이 경우 메뉴 및 Server Cluster, Server 권한은 아래와 같이 표현된다.

  • Server Cluster를 구성하는 Server 개수 : "CLUSTER" 하위 Server 권한 기준으로 권한이 있는 Server 개수

  • Server Cluster의 하위 메뉴 : "CLUSTER" 하위 Server의 메뉴 권한 기준으로 권한이 있는 Server만 보임

  • Server Cluster의 Overview, Application Server, Web Server 탭에서의 Server 목록 : Server Cluster의 구성 정보를 나타내야 하므로, "CLUSTER" 하위 권한과 무관하게 모든 Server 목록 조회

  • Server Cluster의 Overview, Application Server, Web Server 탭에서의 Server 상세 링크 : 개별 Server에 대한 접근이므로, "SERVER" 메뉴 하위의 Server 권한이 없는 Server에 대한 접근을 막음

메뉴 권한 맵핑

  1. 권한을 설정할 메뉴를 선택한다.

    • 권한 선택 시 메뉴에 대한 권한까지 조회된다.

  2. 메뉴 목록에서 권한을 설정할 메뉴를 선택한다.

    • 메뉴 선택 시 메뉴 권한 목록에 메뉴 권한이 표시된다

  3. 권한 변경이 필요할 경우 Y 혹은 N을 선택한다.

  4. Save 버튼 을 클릭하여 메뉴 권한 정보를 저장한다.

9.2. License

Manager를 통해 각 Node별 현재 적용된 라이선스를 조회하고 갱신할 수 있는 기능을 제공한다.

9.2.1. License 목록

License화면을 열면 Node별로 현재 적용된 License의 목록을 조회할 수 있다.

License의 상태는 Status 항목을 살펴보면 확인 할 수 있다.

admin license
Figure 48. License의 목록 화면

9.2.2. License 상세

License의 목록을 클릭하면 License의 상세 정보를 확인할 수 있다.

상세 정보 항목은 아래와 같다.

Table 123. License의 상세 정보 항목
항목설명비고

Node Name

Node 명

Type

라이선스 구분

Trial, Standard

Customer Name

구매 고객사 명

System Name

설치된 시스템 명

Issue No

라이선스 발행번호

Issue Date

라이선스 발행일자

License Term

라이선스 허용 기간

Engine Path

LENA Engine 설치 경로

IP Address

Node의 IP 주소

Hardware ID

H/W를 인식하는 ID

MAC Address 또는 Host명

Contract CPU Core Limit

계약된 최대 Core 개수

CPU Core Limit

실제 측정된 Core 개수

Contract Instance Limit

계약된 최대 Instance개수

Instance Limit

실제 측정된 Instance 개수

Status

라이선스 유효성 여부

라이선스의 만료기간 15일 전부터 알림메세지를 제공한다. 알림메세지는 Manager 우측 상단의 종 아이콘 에서 확인 할 수 있다.

9.2.3. License 업로드 / 복구

업로드

노드목록에서 신규 License 를 적용하고자 하는 노드를 선택하고 목록 하단의 Upload 버튼 을 사용한다. 해당 버튼을 클릭하면 License 업로드 팝업창이 열리는데 이 창에서 발급받은 License 파일을 찾아 업로드 하면 선택한 노드들에 License가 적용된다.

복구

노드목록에서 License 를 복구하고자 하는 노드를 선택하고 목록 하단의 Restore 버튼 을 사용한다. 해당 버튼을 클릭하면 백업해 두었던 파일로 License가 복구된다.

9.2.4. License 관련 시스템 현황 체크

License 목록조회 화면에서 Node를 선택하고 Check System Info 버튼 을 클릭하면, License 발급에 필요한 시스템 현황을 확인할 수 있다.

admin license system info ui
Figure 49. System Information

CLI환경에서도 각 Node별 License 현황을 조회하기 위한 Shell Script를 제공한다. Shell 파일은 ${LENA_HOME}/bin/check-license.sh 이다. 이 Script를 실행한 결과의 사례는 아래와 같다.

check-license.sh 실행 예
[bin]$ ./check-license.sh
****************************************************************************
[System Information]
  Hostname : solweb2
  HostAddress : 127.0.0.1
  Hardware ID : 52:54:00:E9:AC:A1 ( 52:54:00:E9:AC:A1 )
  Engine Path(LENA_HOME) : /engn001/lena/dev
  Node UUID : e46da220-db50-3854-84a0-7b61e1b6e7cd
  CPU Core : 4
  HyperThreading : DISABLED
  Current Date : 20180705

[License Information]
  License Status : true [License is valid.]
  ISSUE_NO : 201807041532438300001
  TYPE : Standard
  CUSTOMER_NAME : LG
  SYSTEM_NAME : CNS
  SYSTEM_TYPE : PROD
  HARDWARE_ID : 52:54:00:E9:AC:A1
  LENA_HOME : /engn001/lena/dev
  CONTRACT_CPU_CORE_LIMIT : 8
  CPU_CORE_LIMIT : 8
  CONTRACT_INSTANCE_LIMIT : 8
  INSTANCE_LIMIT : 8
  START_DATE : 20180501
  END_DATE : 20190531
  LICENSE_KEY :
H2VaDEE9fjFlvHBRsQeGXasYT5l4tBc6ebayNIdtVZ5/lj4/EM0mYf38karMTKgcLLmPMMFa8BOEFt5zRfBc/IiOxlmDgy
j0+iq30ABfJoyAhY3nWBVJhBy7h0U3hzJWr1hyCuZMFAHquL4dinwWAqmJeL+jntJKFufD38vdF2YwKEoRNH9dGQnqXZHO
U8wQZmN4UHk5YB5/O6YIUfFNGU3wyzjfKCfF9Golu9zQAsSZ358ptjC/TBUy+ccvLa75H32XPxiNSSxytn0hGFbcVc61kv
zi7YMNUgnuEyDEQ/dhFKxJ17ijUQBZj5xbFQ9qUTzL1QKGLl+cbYVsr6kvZg==
****************************************************************************

출력되는 항목은 앞 절에서의 설명과 동일하며, License 발급에 필요한 기본정보를 출력하므로 License 발급 요청 시에 활용된다.

출력 항목 중 "HyperThreading" 은 HyperThreading 사용여부를 체크하는 것으로, HyperThreading 사용 시 물리 Core의 2배수로 Core수를 산정한다.

9.2.5. Host기반 License 체크 설정

License는 계약에 따라 Mac Address 또는 Host명으로 발급대상 H/W를 체크한다. 기본 설정은 Mac Address 기준이므로, Host명 기준으로 License 체크를 실행하기 위해서는 Linux/Unix OS를 기준으로 ${LENA_HOME}/bin에 위치한 start-agent.sh, check-license.sh파일과 각 Application Server의 setenv.sh 파일을 열어서 다음과 같이 수정한다.

start-agent.sh 파일 설정 (변수 $JAVA_OPT에 추가)
JAVA_OPTS="$\{JAVA_OPTS} -Dlicense.check-type=hostname"
check-license.sh 파일 설정 (다음 항목 주석 해제)
_JAVA_OPTS="$\{_JAVA_OPTS} -Dlicense.check-type=hostname"
각 Application Server의 setenv.sh 파일 설정 (다음 항목 주석 해제)
CATALINA_OPTS=" $\{CATALINA_OPTS} -Dlicense.check-type=hostname"

9.2.6. 시간 정보 조회

라이선스 목록에서 시간정보를 조회하고 싶은 노드를 선택 후, Check Time Info 버튼 을 클릭하면 선택한 노드들에 대한 시간과 타임존 의 정보를 확인 할 수 있다.

9.3. License(Scaling)

Manager를 통해 현재 적용된 Manager License를 조회하고 갱신할 수 있는 기능을 제공한다.

9.3.1. Manager License

Manager License의 상태, 사용량, 사용기간을 확인할 수 있다. Upload Manager License 버튼 을 통해 License 파일을 업로드할 수 있다. 업로드된 License 는 Scale-out 시 VM 으로 전송되어 서버 기동시 인증역할을 수행한다.

9.3.2. License 목록

Node별로 현재 적용된 License의 목록을 조회할 수 있다. License의 상태는 Status 항목을 보면 확인할 수 있다.

admin license
Figure 50. License의 목록 화면

9.3.3. License 상세

License의 목록을 클릭하면 License의 상세 정보를 확인할 수 있다.

상세 정보 항목은 아래와 같다.

Table 124. License의 상세 정보 항목
항목설명비고

Node Name

Node 명

Type

라이선스 구분

Trial, Enterprise, Standard, Developer

Customer Name

구매 고객사 명

System Name

설치된 시스템 명

Issue No

라이선스 발행번호

Issue Date

라이선스 발행일자

License Term

라이선스 허용 기간

Engine Path

LENA Engine 설치 경로

IP Address

Node의 IP 주소

Hardware ID

H/W를 인식하는 ID

MAC Address 또는 Host명

Contract CPU Core Limit

계약된 최대 Core 개수

CPU Core Limit

실제 측정된 Core 개수

Contract Instance Limit

계약된 최대 Instance개수

Instance Limit

실제 측정된 Instance 개수

Status

라이선스 유효성 여부

9.3.4. License 업로드 / 복구

업로드

노드목록에서 신규 License 를 적용하고자 하는 노드를 선택하고 목록 하단의 Upload 버튼 을 사용한다. 해당 버튼을 클릭하면 License 업로드 팝업창이 열리는데 이 창에서 발급받은 License 파일을 찾아 업로드 하면 선택한 노드들에 License가 적용된다.

복구

노드목록에서 License 를 복구하고자 하는 노드를 선택하고 목록 하단의 Restore 버튼 을 사용한다. 해당 버튼을 클릭하면 백업해 두었던 파일로 License가 복구된다.

9.3.5. License 관련 시스템 현황 체크

License 목록조회 화면에서 Node를 선택하고 Check System Info 버튼 을 클릭하면, License 발급에 필요한 시스템 현황을 확인할 수 있다.

admin license system info ui
Figure 51. System Information

CLI환경에서도 각 Node별 License 현황을 조회하기 위한 Shell Script를 제공한다. Shell 파일은 ${LENA_HOME}/bin/check-license.sh (Windows 버전의 경우 check-license.bat)이다. 이 Script를 실행한 결과의 사례는 아래와 같다.

check-license.sh 실행 예
[bin]$ ./check-license.sh
****************************************************************************
[System Information]
  Hostname : solweb2
  HostAddress : 127.0.0.1
  Hardware ID : 52:54:00:E9:AC:A1 ( 52:54:00:E9:AC:A1 )
  Engine Path(LENA_HOME) : /engn001/lena/1.3
  Node UUID : e46da220-db50-3854-84a0-7b61e1b6e7cd
  CPU Core : 4
  HyperThreading : DISABLED
  Current Date : 20180705

[License Information]
  License Status : true [License is valid.]
  ISSUE_NO : 201807041532438300001
  TYPE : Enterprise
  CUSTOMER_NAME : LG
  SYSTEM_NAME : CNS
  SYSTEM_TYPE : PROD
  HARDWARE_ID : 52:54:00:E9:AC:A1
  LENA_HOME : /engn001/lena/1.3
  CONTRACT_CPU_CORE_LIMIT : 8
  CPU_CORE_LIMIT : 8
  CONTRACT_INSTANCE_LIMIT : 8
  INSTANCE_LIMIT : 8
  START_DATE : 20180501
  END_DATE : 20190531
  LICENSE_KEY :
H2VaDEE9fjFlvHBRsQeGXasYT5l4tBc6ebayNIdtVZ5/lj4/EM0mYf38karMTKgcLLmPMMFa8BOEFt5zRfBc/IiOxlmDgy
j0+iq30ABfJoyAhY3nWBVJhBy7h0U3hzJWr1hyCuZMFAHquL4dinwWAqmJeL+jntJKFufD38vdF2YwKEoRNH9dGQnqXZHO
U8wQZmN4UHk5YB5/O6YIUfFNGU3wyzjfKCfF9Golu9zQAsSZ358ptjC/TBUy+ccvLa75H32XPxiNSSxytn0hGFbcVc61kv
zi7YMNUgnuEyDEQ/dhFKxJ17ijUQBZj5xbFQ9qUTzL1QKGLl+cbYVsr6kvZg==
****************************************************************************

출력되는 항목은 앞 절에서의 설명과 동일하며, License 발급에 필요한 기본정보를 출력하므로 License 발급 요청 시에 활용된다.

출력 항목 중 "HyperThreading" 은 HyperThreading 사용여부를 체크하는 것으로, HyperThreading 사용 시 물리 Core의 2배수로 Core수를 산정한다.

9.3.6. Host기반 License 체크 설정

License는 계약에 따라 Mac Address 또는 Host명으로 발급대상 H/W를 체크한다. 기본 설정은 Mac Address 기준이므로, Host명 기준으로 License 체크를 실행하기 위해서는 Linux/Unix OS를 기준으로 ${LENA_HOME}/bin에 위치한 start-agent.sh, check-license.sh파일과 각 Application Server의 setenv.sh 파일을 열어서 다음과 같이 수정한다.

start-agent.sh 파일 설정 (변수 $JAVA_OPT에 추가)
JAVA_OPTS="$\{JAVA_OPTS} -Dlicense.check-type=hostname"
check-license.sh 파일 설정 (다음 항목 주석 해제)
_JAVA_OPTS="$\{_JAVA_OPTS} -Dlicense.check-type=hostname"
각 Application Server의 setenv.sh 파일 설정 (다음 항목 주석 해제)
CATALINA_OPTS=" $\{CATALINA_OPTS} -Dlicense.check-type=hostname"

9.3.7. 시간 정보 조회

라이선스 목록에서 시간정보를 조회하고 싶은 노드를 선택 후, Check Time Info 버튼 을 클릭하면 선택한 노드들에 대한 시간과 타임존 의 정보를 확인 할 수 있다.

9.4. Security (서비스 제어)

Application Server에 IP또는 URL기반으로 사용자 요청을 제한하는 기능이다.

9.4.1. Rule Setting (Rule 설정)

특정 IP나 URL에서 요청을 제어하고 싶은 경우 화면을 통해 신규 Rule을 설정한다. 신규 Rule 설정 및 Rule 삭제의 편의성을 제공하기 위해 검색기능을 제공한다. 전체 Application에 적용되는 Server속성은 에러페이지로 처리할 수 있다

admin service control rule setting
Figure 52. Rule Setting 화면

Rule 목록의 Use 컬럼은 해당 Rule이 Application Server에 적용되어 있는지 여부를 나타낸다.

Rule 추가 시 설정 가능한 속성은 아래와 같다.

Table 125. Rule 추가 시 설정 가능한 속성
항목(*는 필수값)설명비고

Rule Name(*)

추가하는 Rule의 이름

Description

추가하는 Rule에 대한 설명

Rule Type

제어할 단위

IP, URL

Allow IP(*)

허가할 요청 IP

정규식 형태로 입력 가능

Deny IP(*)

거부할 요청 IP

정규식 형태로 입력 가능

Control Time(*)

Rule을 적용할 시간단위

Error Message(html)(*)

제어로 인해 Filtering된 요청에 대한 출력할 에러 페이지

제어유형이 "IP with DateTime"인 Rule에 Proxy Server로 중계되는 Application Server 를 적용한다면, Proxy Server의 보안적 특성으로 인해 User IP를 구할 수 없어 Rule 적용이 되지 않을 수 있다.

생성된 Rule 중 적용된 Rule은 삭제 할 수 없다.

9.4.2. Rule Applying (Rule 적용)

추가된 Rule 중 하나를 선택하여 Application Server에 적용한다. 적용 편의성을 위해 Rule유형, 적용단위, Rule명에 대한 검색기능을 제공한다.

Rule 목록에서 하나를 선택하여 Rule 적용에서 셔플 버튼들을 이용하여 적용 대상을 선택하고, On/Off 버튼 을 클릭하여 적용 및 저장한다. 적용 대상에서 제외를 하고 싶을 경우에도 셔플 버튼들을 이용하여 제외시킨다.

admin service control rule applying
Figure 53. Rule Applying 화면

Rule 현황 및 적용 화면에서 사용되는 속성들은 Rule설정 화면과 유사하며 아래의 속성들은 추가적인 속성들이다.

Table 126. 추가적인 속성
항목설명비고

Node Name

등록된 Node group 하위의 Node 명

Server Name

등록된 Node하위의 Server 명

선택한 Rule에 신규 대상이 추가될 경우 적용 단위에 따라 server.xml 혹은 context.xml 에 추가되고, 적용된 대상에서 제외할 경우 위의 설정 파일에 추가된 Rule 설정이 삭제된다.

9.4.3. Service Control Log (Rule 적용결과 조회)

Rule이 적용된 항목들에 대한 처리 결과가 목록으로 출력된다. 처리 결과 확인의 편의성을 위해 Rule유형, 적용단위, Rule명, 로그시간에 대한 검색기능을 제공한다.

admin service control log
Figure 54. Service Control Log 화면

처리 목록에서 사용되는 속성들은 아래와 같다.

Table 127. 로그 정보의 항목
항목설명비고

Controlled Date

Rule설정이 적용된 요청의 처리시간

Remote Address

처리된 원격지 주소

Request URL

처리된 요청의 URL

HTTP Method

처리된 요청의 HTTP Method

Rule 명

요청을 처리하는데 적용된 Rule 이름

Rule 이력의 경우 Manager의 /conf/manager.conf 설정파일 내 access filter log 취합 Listener 사용여부를 true로 설정해야 한다. Log의 경우 각 서버의 logs 폴더 내 access_filter.log."날짜".txt 파일에 기록되며 주기적으로 Manager 가 각 server 의 log 를 취합하여 Database 에 저장한다. (이때 취합된 Log 는 access_filter_log."날짜".txt.gathered 파일에 backup된다) Database에 취합된 Log는 처리목록 화면에서 확인 가능하다.

manager.conf 내 설정 파일 항목의 설정 예는 아래와 같다.

#access filter log 취합 리스너 사용여부 및 동작주기(초) default는 false, 60
accessfilter.listener=false
accessfilter.interval=60

9.5. Patch

설치된 LENA에 대한 기능 개선 및 버그 수정을 위한 패치를 제공한다.

Patch는 압축파일 형태로 제공되며, 독립적으로 동작하는 Java프로세스로 동작한다.

Patch 기능은 CLI 및 Management UI를 통하여 실행이 가능하며, 패치 시 서비스에 문제가 발생하는 경우 Restore 기능을 통하여 원복 할 수 있다.

패치 순서는 다음과 같다.

  1. 패치파일 업로드

  2. Manager 패치 적용

  3. Node 패치 적용

  4. 서버(Application Server, Session Server) 패치 적용

  5. 패치 Commit

복구 순서는 다음과 같다.

  1. 서버 패치 복구

  2. Node 패치 복구

  3. Manager 패치 복구

  4. 복구 Commit

CLI로 패치하는 방식은 Appendix를 참고한다.

9.5.1. Overview

패치파일의 업로드 기능을 제공하며, Manager와 각 Node별 Node Agent의 패치 반영상태 정보를 조회한다.

Patch 파일 업로드

Patch Info 영역에서는 매니저에 업로드 된 패치파일 중, 최상위 버전의 상세정보를 표시한다.

Table 128. Patch Info 항목
항목설명비고

Patch File Ver.

패치파일의 버전 정보

Release Date

패치파일의 배포 일자

Patch Note

상세(노트) 버튼 을 눌러 상세한 패치노트 내용을 조회한다.

패치노트 팝업표시

패치파일을 업로드하는 과정은 다음과 같다.

  1. 업로드 버튼 을 클릭한다.

  2. 패치 가능 상태인지를 확인 후 정상이면 패치파일 업로드를 위한 팝업을 띄운다

    패치 가능 상태 조건

    1. Manager에 등록된 Node가 모두 기동상태여야한다.

    2. patch가 commit상태여야 한다.

    3. manager 기준으로 node와 server가 모두 같은 버전이어야 한다.

    4. manager에 등록되지 않은 서버가 존재하지 않는다.

      1. unregister된 서버존재시 manager에 등록

      2. 노드엔진 하위 servers폴더에 서버가 존재시 해당 폴더 삭제

  3. 업로드 할 패치파일을 선택하면 자동으로 업로드가 실행된다.

    업로드 가능한 파일은 zip과 tar.gz이며 이외의 파일을 업로드 할 경우 에러메시지가 출력된다.

Manager Patch

Manager Info 영역에서는 Manager의 패치상태를 표시하고, Manager의 패치 및 복구를 실행할 수 있다.

화면에 표시되는 각 항목에 대한 설명은 아래와 같다.

Table 129. Manager Info 항목
항목설명비고

Patch Status

Manager의 패치 적용 상태

  • 해 아이콘 : Manager가 최신패치를 적용한(up to date) 상태

  • 구름 아이콘 : Manager가 최신 패치를 적용하지 않은(patch available) 상태

Current Ver.

Manager의 현재 버전

Patch Ver.

Patch 버전

History

Patch history를 조회하는 버튼

Handwork 작업이 필요시, 상세(노트) 버튼 은 붉은색으로 표시된다.

Manager Info화면의 History 항목에 표시된 상세(노트) 버튼 을 클릭하면 팝업창을 통해 패치 실행 이력을 확인할 수 있다.

화면에 표시되는 각 항목에 대한 설명은 아래와 같다.

Table 130. History 항목
항목설명비고

Action

패치/복원 이력을 표시

Patch Ver.

패치/복원을 수행한 패치파일의 버전

Pervious Ver.

패치/복원을 적용하기 이전의 서버버전

Timestamp

패치/복원을 적용한 시간

Log/Handwork

상세(노트) 버튼 선택시 실행 결과 로그를 제공한다.

수작업(스페너) 버튼 선택시 Handwork(추가적으로 필요한 수작업) 내용을 제공한다. Handwork 작업 필요시 해당 버튼은 붉은색으로 표시된다.

Patch

Manager Info 하단에 있는 Patch 버튼 을 클릭하면 최신 패치를 적용한다.

Handwork에 기술된 내용 패치실행 후 필요한 수작업이므로, 기술된 내용을 실행하여 반영하여야 한다. Handwork 작업 후 팝업창 하단의 체크박스를 해제하면 Manager Patch Info화면의 Handwork 버튼이 흰색으로 변경된다.

Manager 패치를 적용하면 Node와 Server의 패치 적용 후 Commit 버튼 을 누르기 전까지 Node의 설치/등록, Server의 설치/등록/복제 등의 기능을 수행 할 수 없다.

패치 후 반드시 브라우저 캐시를 삭제하여야 패치버전의 Manager를 사용할 수 있다.

Restore

Manager Info 하단에 있는 Restore 버튼 을 클릭하면 패치 이전 버전으로 복구된다.

복구는 Manager에 등록된 모든 노드의 패치 상태가 Patch Available 인 경우에 수행한다.

Commit

Manager, Node, Server의 모든 패치를 적용 후 Commit버튼을 눌러 확정한다. 확정 이후에는 이전버전으로 되돌릴 수 없다.

Node Patch

Node Patch Status 영역은 매니저에 등록된 node에 대해서, 최신패치가 적용된 서버의 개수와 패치가 적용되지 않은 서버의 개수를 종합해서 보여준다.

화면에 표시되는 각 항목에 대한 설명은 아래와 같다

Table 131. Node Patch Status 항목
항목설명비고

Status

node의 패치 적용 상태

  • 해 아이콘 : 모든 서버가 최신패치를 적용한(up to date) 상태

  • 구름 아이콘 : Node Agent가 최신 패치를 적용하지 않은(patch available) 상태

  • 반구 아이콘 : Node Agent는 최신 패치를 적용하였으나, Node 에 설치된 Server에는 최신 패치가 적용되지 않은 상태

  • 느낌표 아이콘 : Node agent가 lena-manager와 호환이 되지 않는 상태.

Node name

node명

Address

node의 IP

Node Version

Node의 현재 버전

History

Patch history를 조회하는 버튼

Handwork 작업이 필요시, 상세(노트) 버튼 은 붉은색으로 표시된다.

WAS

Web Application Server의 패치상태 정보

  • Up To Date : 최신패치가 적용된 서버의 개수

  • Patch Available : 최신패치가 적용되지 않은 서버의 개수

Session Server

Session Server의 패치상태 정보

  • Up To Date : 최신패치가 적용된 서버의 개수

  • Patch Available : 최신패치가 적용되지 않은 서버의 개수

Node Patch 버튼 을 클릭하면 제공되는 팝업창에서 Node 선택 후 해당 Node에 대한 패치 또는 복구를 진행 할 수 있다.

Window OS 환경에 설치되어 있는 Node는 Manager가 아닌 CLI를 통해 패치를 수행한다.

Server Cluster Patch Status

Server Cluster 별 Patch 현황을 표시한다.

화면에 표시되는 각 항목에 대한 설명은 다음과 같다.

Table 132. Server Cluster Patch Status 항목
항목설명비고

Status

cluster의 패치 적용 상태

  • 해 아이콘 : 모든 서버가 최신패치를 적용한(up to date) 상태

  • 구름 아이콘 : 일부 서버가 최신 패치를 적용하지 않은(patch available) 상태

Cluster Group

cluster그룹명

Cluster Name

cluster이름

LENA Patch

Application Server의 패치상태 정보

  • Up To Date : 최신패치가 적용된 서버의 개수

  • Patch available : 최신패치가 적용되지 않은 서버의 개수

9.5.2. WAS

Node/Cluster에 포함된 Application Server에 대해서, 매니저에 업로드 된 최신 패치파일로 패치를 진행하며, 문제발생시 패치 적용 바로 전의 상태로 복원할 수 있는 기능을 제공한다.

목록

패치를 적용할 서버를 그룹별 조건(node단위, cluster 단위)으로 검색한다.

Table 133. Application Server Patch Status 항목
항목설명비고

Patch Status

Application Server의 패치 적용 상태

  • 해 아이콘 : 최신패치가 적용된(up to date) 상태

  • 구름 아이콘 : 최신패치를 적용할 수 있는(patch available) 상태

Node

Application Server가 설치되어있는 Node명

Name

Application Server 이름

Type

Application 서버 타입

  • Standard : Application Server Standard Edition

  • Enterprise : Application Server Enterprise Edition

IP

Application Server가 설치된 Node의 IP

HTTP Port

Application Server의 HTTP Connector port

AJP Port

Application Server의 AJP Connector port

Start/Stop

Application Server의 기동 및 중지 실행

Current Ver.

Application Server의 현재 설치된 버전정보

Patch Ver.

패치를 적용할 버전정보. 최신패치가 적용 된 상태일 경우 ‘N/A’로 표시된다.

매니저에 upload된 최신 패치버전

History

Server에 적용한 patch/restore의 이력정보조회

Node Agent process kill 등의 이유로 동작이 정상적이지 않을 경우는, 해당 node의 Server 정보는 조회되지 않는다.

Patch

  1. 패치적용 전 서버의 중지상태를 확인하고(Start 버튼 활성화된 상태), 중지상태가 아닐 경우 Stop 버튼 을 클릭하여 서버를 중지시킨다.

  2. 패치를 적용할 서버의 체크박스를 체크한다.(복수 체크 가능)

  3. Patch 버튼 을 클릭하여 패치를 진행한다. 이때 로그 팝업이 뜨게 되며 패치종료 후 수작업을 진행해야 할 사항이 있을 경우 Handwork 컬럼에 수작업(스페너) 버튼 이 붉은색으로 표기된다.

  4. 로그 팝업을 닫으면 서버의 patch status 상태가 해 아이콘 으로 변경되고, current ver., patch ver.에는 각각 적용한 현재패치버전과 N/A가 표시된다.

  5. Validation

    1. 서버가 기동상태일 때는 패치 적용 불가

    2. 이미 최신 패치가 적용된 서버에 다시 패치를 적용 불가

서버에 패치적용 시 해당 Node에 패치를 처음 적용할 경우, 내부적으로 해당 Node의 패치를 먼저 진행 한 뒤에 서버패치를 진행하게 된다.

Restore

  1. 복구적용 전 서버의 중지상태를 확인하고(Start 버튼 활성화된 상태), 중지상태가 아닐 경우 Stop 버튼 을 클릭하여 서버를 중지시킨다.

  2. 복원을 적용할 서버의 체크박스를 체크한다.(복수 체크 가능)

  3. Restore 버튼 을 클릭하여 복구를 진행한다. 이때 로그 팝업이 뜨게 된다.

  4. 로그 팝업을 닫으면 서버의 patch status 상태가 구름 아이콘 으로 변경되고, current ver., patch ver.에는 각각 이전 버전과 패치파일버전이 표시된다.

  5. Validation

    1. 서버가 기동상태일 때 복원을 적용 불가

    2. 복원을 한 뒤에, 다시 복원은 불가(매니저를 통한 복원은 1단계만 지원한다.)

서버에 복원 진행 후 Node에 패치가 적용된 서버가 하나도 없을 경우, 내부적으로 해당 Node의 복원도 함께 진행한다.

이력조회

상세(노트) 버튼 을 클릭하여 패치/복원에 대한 이력을 가장 최근의 이력부터 5개를 조회한다.

Table 134. History 항목
항목설명비고

Action

패치/복원 이력을 표시

Patch Ver.

패치/복원을 수행한 패치파일의 버전

Previous Ver.

패치/복원을 적용하기 이전의 서버버전

Timestamp

패치/복원을 적용한 시간

Log/Handwork

상세(노트) 버튼 선택시 실행 결과 로그를 제공한다.

수작업(스페너) 버튼 선택시 Handwork(추가적으로 필요한 수작업) 내용을 제공한다. Handwork 작업 필요시 해당 버튼은 붉은색으로 표시된다.

9.5.3. Session Server

Session Server들에 대해서, 매니저에 업로드 된 최신 패치파일로 패치를 진행하며, 문제발생시 패치 적용 바로 전의 상태로 복원할 수 있는 기능을 제공한다.

목록

패치를 적용할 서버를 그룹별 조건(node단위)으로 검색한다.

Table 135. Session Server Patch Status 항목
항목설명비고

Patch Status

Session Server의 패치 적용 상태

  • 해 아이콘 : 최신패치가 적용된(up to date) 상태

  • 구름 아이콘 : 최신패치를 적용할 수 있는(patch available) 상태

Node

Session Server가 설치되어있는 Node명

Name

Session Server 이름

Type

Session 서버 타입

Port

Session Server의 port

Start/Stop

Session Server의 기동 및 중지 실행

Current Ver.

Session Server의 현재 설치된 버전정보

Patch Ver.

패치를 적용할 버전정보. 최신패치가 적용 된 상태일 경우 ‘N/A’로 표시된다.

매니저에 upload된 최신 패치버전

History

Server에 적용한 patch/restore의 이력정보조회

Node Agent process kill 등의 이유로 동작이 정상적이지 않을 경우는, 해당 node의 Server 정보는 조회되지 않는다.

Patch

  1. 패치적용 전 서버의 중지상태를 확인하고(Start 버튼 활성화된 상태), 중지상태가 아닐 경우 Stop 버튼 을 클릭하여 서버를 중지시킨다.

  2. 패치를 적용할 서버의 체크박스를 체크한다.(복수 체크 가능)

  3. Patch 버튼 을 클릭하여 패치를 진행한다. 이때 로그 팝업이 뜨게 되며 패치종료 후 수작업을 진행해야 할 사항이 있을 경우 Handwork 컬럼에 수작업(스페너) 버튼 이 붉은색으로 표기된다.

  4. 로그 팝업을 닫으면 서버의 patch status 상태가 해 아이콘 으로 변경되고, current ver., patch ver.에는 각각 적용한 현재패치버전과 N/A가 표시된다.

  5. Validation

    1. 서버가 기동상태일 때는 패치 적용 불가

    2. 이미 최신 패치가 적용된 서버에 다시 패치를 적용 불가

서버에 패치적용 시 해당 Node에 패치를 처음 적용할 경우, 내부적으로 해당 Node의 패치를 먼저 진행 한 뒤에 서버패치를 진행하게 된다.

Restore

  1. 복구적용 전 서버의 중지상태를 확인하고(Start 버튼 활성화된 상태), 중지상태가 아닐 경우 Stop 버튼 을 클릭하여 서버를 중지시킨다.

  2. 복원을 적용할 서버의 체크박스를 체크한다.(복수 체크 가능)

  3. Restore 버튼 을 클릭하여 복구를 진행한다. 이때 로그 팝업이 뜨게 된다.

  4. 로그 팝업을 닫으면 서버의 patch status 상태가 구름 아이콘 으로 변경되고, current ver., patch ver.에는 각각 이전 버전과 패치파일버전이 표시된다.

  5. Validation

    1. 서버가 기동상태일 때 복원을 적용 불가

    2. 복원을 한 뒤에, 다시 복원은 불가(매니저를 통한 복원은 1단계만 지원한다.)

서버에 복원 진행 후 Node에 패치가 적용된 서버가 하나도 없을 경우, 내부적으로 해당 Node의 복원도 함께 진행한다.

이력조회

상세(노트) 버튼 을 클릭하여 패치/복원에 대한 이력을 가장 최근의 이력부터 5개를 조회한다.

Table 136. History 항목
항목설명비고

Action

패치/복원 이력을 표시

Patch Ver.

패치/복원을 수행한 패치파일의 버전

Previous Ver.

패치/복원을 적용하기 이전의 서버버전

Timestamp

패치/복원을 적용한 시간

Log/Handwork

상세(노트) 버튼 선택시 실행 결과 로그를 제공한다.

수작업(스페너) 버튼 선택시 Handwork(추가적으로 필요한 수작업) 내용을 제공한다. Handwork 작업 필요시 해당 버튼은 붉은색으로 표시된다.

9.6. Preferences

9.6.1. Action Trace

Manager를 통해 각 사용자가 수행하는 추가/수정/삭제 작업의 수행 이력은 로그로 남는다. Action Trace에서는 이러한 수행이력을 조회/추적하는 기능을 제공한다.

admin action trace
Figure 55. Action Trace 화면
이력 조회

조회 조건을 입력 후 클릭하면 이력을 조회할 수 있다. 목록 중 하나를 선택하면 상세정보도 확인할 수 있다.

조회 화면에 표기되는 항목은 아래와 같다.

Table 137. 이력 상세 정보 항목
항목설명비고

Trace Date

Action을 수행한 시간

Status

Action 수행 결과

성공 : Success, 실패 : Fail

Client IP

Action을 수행한 사용자의 IP 주소

User ID

Action을 수행한 사용자 ID

Action

수행한 활동(Action) 명

Method

Action에 사용된 Method 이름

Request

LENA Manager Http Request URL

Input

Http Request Input 파라미터

위 항목 중 "Input" 은 Request 파라미터를 그대로 저장하기 때문에, Server ID, Node ID, Server Cluster ID가 데이터 관리용 Key값 (일련번호, 캡쳐화면에서 "serverID=31"로 표시된 부분)으로 보여진다. 해당 Server/Node/Cluster의 상세정보를 조회하기 위해서는 "Action Trace Detail" 정보 하단에 있는 "Search ID" 기능을 활용한다. 이 기능의 입출력 항목은 아래와 같다.

Table 138. Search ID 기능의 입출력 항목
항목설명비고

ID

  • 좌측 Combo : serverId / nodeId / serverCluster Id 중 택일

  • 우측 : Input 에 있는 ID 값을 입력

입력항목

Data

검색된 Server/Node/Cluster 정보

출력항목

9.6.2. Documentation

LENA 소개자료와 매뉴얼을 다운로드 받을 수 있다.

9.6.3. Manager Environment

Manager 환경 설정을 위한 정보를 제공한다.

Manager Environment

Manager 환경 설정 정보 중 env-manager.sh/bat에 저장하는 정보를 제공한다.

  • Manager Allow IPs : Manager에 접근 가능한 IP항목을 설정한다.

  • Java Home Path : Manager에서 사용하는 java home 경로를 설정한다.

Manager Configuration

Manager 환경 설정 정보 중 manager.conf에 저장하는 정보를 제공한다.

기본적으로 제공하는 2가지 항목을 제공한다.

  • use JMX for Server Status : JMX를 통해 서버 상태 정보를 조회할지 여부(default : false)

  • use Server Delete Protection : Manager에서 서버 삭제 기능 사용금지 여부(default : false)

화면 우측의 설정 버튼 을 클릭하면 상세 정보를 확인 및 변경 할 수 있다.

Table 139. JMX for Server Status: true 사용시 WAS Status 표시

Status

Status 명

설명

server 3 application server status green

Started

WAS 및 Application 모두 정상 기동 상태

server 3 application server status yellow

Started(Warning)

WAS 정상 기동, Application 일부(또는 전체) 기동 안 된 상태

server 3 application server status stopped

Stopped

WAS 중지 상태

server 3 application server status error

Error

WAS Status 확인 불가 상태

Metadata Refresh

Topology 메뉴에서 시스템 별 구성정보를 topology 차트로 그리기 위해 사용되는 메타데이터의 정합성 검증 및 복원 기능을 수행한다.

Reset manager address of all registered nodes

Manager에 등록된 노드들에게 변경된 Manager Address를 일괄적으로 변경시켜주는 기능을 제공한다.

9.6.4. Manager HA

Manager 이중화에 대한 설정을 관리하고, 이중화 상태에 대한 현황조회를 할 수 있다.

Manager 이중화는 Primary와 Secondary로 구분되어 기동된 LENA Manager간의 Database와 주요 파일들을 동기화 함으로써 Prmary Manager가 비가동시 임시적으로 Secondary Manager 가 Primary의 서비스를 대행하는 기능이다.

Secondary Manager가 대행하는 서비스의 기능은 다음 두가지 이다.

  • Server Cluster - Scaling 서비스

  • Service Cluster - Server Template 및 License 다운로드

Manager 이중화를 위해서는 각 Manager의 역할에 따라 환경설정 파일인 'env-manager.sh' 파일의 다음 부분을 수정하여 기동하여야 한다.

LENA Manager 환경변수 파일 (env-manager.sh) 설정
CATALINA_OPTS=" ${CATALINA_OPTS} -Dspring.profiles.active=ha-none"

위 파일에서 설정되는 spring.profiles 프로퍼티의 값은 다음 3가지 설정이 가능하며, 잘못 기입되었을 경우 Manager가 정상기동 되지 않는다.

  • ha-none : 기본 값으로, 이중화를 하지 않는 단독 실행형 Manager

  • ha-primary : 이중화시 Primary Manager 역할 수행

  • ha-secondary : 이중화시 Secondary Manager 역할 수행

Local Manager

현재의 Manager 정보를 제공한다. Manager의 역할에 관계없이, 현재의 관리화면을 제공하는 Manager 자신을 Local Manager, 원격지 Manager를 Remote Manager라 칭한다.

Table 140. Local Manager 정보 항목
항목설명비고

Status

Server의 상태로, 항상 Active 상태이다.

Start Time

Local Manager 시작시간

HA Mode

Primary 또는 Secondary 여부

HA Pairing Config

  • Local Manager에 설정된 Remote Manager의 연결정보가 실제 Remote Manager의 정보와 일치하는지 표기한다. 비교하는 항목은 주소, Http/Udp 서비스포트, DB 서비스 포트이다.

  • Pairing 설정 정보가 정상일때 초록색 ○ 아이콘, 비정상일때 붉은색 X 아이콘, Remote와의 연결 불가 일때 붉은색 ! 아이콘 이 표기된다.

Remote Manager

원격지 Manager의 정보를 제공한다.

Table 141. Remote Manager 정보 항목
항목설명비고

Status

Server의 상태로, 정상적으로 연결되어 있을 경우 Active 로 표기되며, 연결되어 있지 않을 경우 InActive로 표기된다.

Start Time

Remote Manager 시작시간

HA Mode

Primary 또는 Secondary 여부

HA Pairing Config

  • Remote Manager에 설정된 Remote Manager의 연결정보가 실제 Local Manager의 정보와 일치하는지 표기한다. 비교하는 항목은 주소, Http/Udp 서비스포트, DB 서비스 포트이다.

  • Pairing 설정 정보가 정상일때 초록색 ○ 아이콘, 비정상일때 붉은색 X 아이콘, Remote와의 연결 불가 일때 붉은색 ! 아이콘 이 표기된다.

Address

Remote Manager의 주소로 연결정보를 설정할때 사용된다.

Http Port

Remote Manager의 Http 서비스 Port로 연결정보를 설정할때 사용한다.

Connection Test 버튼 을 눌러 Remote Manager의 Address와 Http Port를 이용하여 실제 Connection이 가능한지 테스트를 할 수 있다.

Primary Manager와 Secondary Manager는 Pairing을 통해 상호 동기화를 위한 정보를 설정할 수 있다. Sync Settings 버튼 을 눌러 Remote Manager와 설정정보를 동기화 하는 Paring을 수행할 수 있다.

Latest Sync Status

이중화된 Manager간 Database 및 File 동기화 최신 이력을 조회할 수 있다.

Table 142. Latest Sync Status 정보 항목
항목설명비고

Type

Database 또는 File

Status

정상일때 초록색 ○ 아이콘, 오류 발생시 붉은색 X 아이콘, Remote와의 연결 불가 일때 붉은색 ! 아이콘 이 표기된다.

Time

동기화 시도 시간

Result

동기화 성공여부

Message

동기화 수행시 생성된 결과 메시지

목록 버튼

목록 버튼 을 눌러 이전 동기화 이력을 조회 할 수 있다. 이력은 총 10개 까지 표기되며, Manager 기동 후의 이력만 표기되고, Remote Manager에서 발생한 동기화 정보는 정상 연결시에만 표기된다.

10. Appendix

10.1. LENA 시스템 요구사항

LENA를 설치하고 사용하기 위한 최소 요구사항은 다음과 같다.

구분JVMCPUMemoryDiskSupport OS비고

기본 설치 패키지

JDK 1.8 이상

2 Core 이상

4 GB 이상

root를 제외한 용량 10GB 이상

Linux (centos7 이상) 또는 Windows 7이상

각 구성요소 설치 파일 제공

10.2. Manager 지원 브라우저

Manager의 기능을 사용할 수 있는 브라우저로는 Chrome/Edge(버전 70 이상), Firefox(버전 62 이상) 이 있다. IE의 경우 일부기능이 정상적으로 동작하지 않기 때문에 다른 브라우저를 사용하기를 권장한다. 브라우저 권장 최소 사이즈는 1680*900 이다.

10.3. 지원 Spec별 버전

SpecificationVersion비고

Java Development Kit (JDK)

1.8~

Java Servlet

3.1

Java Server Pages (JSP)

2.3

Expression Language (EL)

2.2

JavaServer Pages Standard Tag Library (JSTL)

1.2

Enterprise JavaBeans (EJB)

3.2

Java Message Service (JMS)

1.1

Java Transaction API (JTA)

1.2

Java API for RESTful Services (JAX-RS)

2.0

Java API for XML Web Services (JAX-WS)

2.2

10.4. Manager DB파일 백업

Manager의 내부데이터 관리를 위한 HSQL DB의 파일은 주기적으로(1일) 백업파일을 생성하고 있다. 생성위치는 ${LENA_HOME}/repository/backup/lena-manager/script 이다.

기본적으로 30일 이전 백업정보는 삭제하도록 되어 있는데 보관기간을 변경하고 싶은 경우, ${LENA_HOME}/conf 폴더 하위에 manager.conf 파일을 열고, dbbackup.size=보관기간 을 입력 후 Manager를 재 기동하면 보관기간을 변경할 수 있다.

10.5. Manager 의 내부이력 삭제

Manager가 내부적으로 남기는 이력은 주기적으로 삭제하도록 스케쥴링이 되어 있다. 삭제하는 정보는 Action Trace 이력과 Server History 이력이다.

기본적으로 Action Trace이력은 30일까지만 보관하고, Server History 이력은 90일까지 보관하고 있다. 이 보관기간을 변경하고 싶은 경우 ${LENA_HOME}/conf 폴더 하위에 manager.conf 파일을 열고, actiontrace.size=보관기간, serverhistory.size=보관기간을 입력 후 Manager를 재 기동하면 보관기간을 변경할 수 있다.

10.6. Manager 의 admin 패스워드 초기화

Manager의 admin사용자 패스워드를 분실하거나 비밀번호 오류횟수가 초과하였을 경우에는 console를 통하여 패스워드를 초기화해야 한다.

  1. Manager가 설치된 장비에 console(telnet or ssh)로 접속한다.

  2. $LENA_HOME/bin/reset_manager_pw.sh 파일을 실행한다.

  3. 패스워드를 초기화 할 user인 admin을 입력한다.

  4. 초기화할 패스워드를 입력한다. 단, 패스워드는 8자리이상, 알파벳/숫자/특수문자의 조합으로 입력한다. 패스워드는 보안을 위해 console에 표시되지 않는다.

[bin]$ ./reset-manager-pw.sh

 *******************************
* LENA Server Install ! *
 *******************************

+-------------------------------------------------------------------------------
| 1. USER_ID is the user id to reset
| ex : admin
| 2. NEW_PASSWORD is the password to change
| - password rule #1 : more than 8 length
| - password rule #2 : inclusion of one or more alphabet characters
| - password rule #3 : inclusion of one or more numerical digits
| - password rule #4 : inclusion of one or more special characters
+-------------------------------------------------------------------------------

Input USER_ID for installation. (q:quit)
administrator

Input NEW_PASSWORD for installation. (q:quit)

The password has been changed successfully.

Execution is completed.!!

10.7. LENA 설치 권장 OS파라미터(CentOS기준)

LENA 설치 시 OS파라미터는 max user processes 값을 8192 이상으로 설정하는 것을 권장한다.

parameter권장값기본값

max user processes

8192

1024

open files

8192

1024

CentOS기준으로 max user processes 설정은 다음과 같이 ‘ulimit –a’ 명령어를 실행하여 확인을 할 수 있다.

$ ulimit -a +
core file size          (blocks, -c) 0 +
data seg size           (kbytes, -d) unlimited +
scheduling priority             (-e) 0 +
file size               (blocks, -f) 8192 +
pending signals                 (-i) 14891 +
max locked memory       (kbytes, -l) 64 +
max memory size         (kbytes, -m) unlimited +
open files                      (-n) 1024 +
pipe size            (512 bytes, -p) 8 +
POSIX message queues     (bytes, -q) 819200 +
real-time priority              (-r) 0 +
stack size              (kbytes, -s) 10240 +
cpu time               (seconds, -t) unlimited +
*max user processes              (-u) 1024* +
virtual memory          (kbytes, -v) unlimited +
file locks                      (-x) unlimited

CentOS를 기준으로 명령어 ‘ulimit –u’와 ‘ulimit –n’로 프로세스 수와 오픈파일 개수를 설정할 수 있다. 위 변경사항을 영구적으로 반영하기 위해서는 각 유저의 profile (.profile, .bash_profile)에 ulimit 실행명령을 추가하거나, 강제 설정할 수 있다 (CentOS 기준).

*$ cat $HOME/.bash_profile*

*.. (생략)*

*ulimit -u 8192*

*ulimit -n 8192*

또 다른 설정 방법으로는 /etc/security/limits.conf (CentOS 기준) 파일을 열어서 프로세스 최대수(nproc)와 오픈파일 최대수(nofile)를 설정한다.

*$ cat /etc/security/limits.conf*

*.. (생략)*

** soft nproc 8192*

** hard nproc 8192*

** soft nofile 8192*

** hard nofile 8192*

10.8. LENA 주기적으로 증가하는 파일

항목경로삭제주기월 예상 증가량비고

Manager정기점검로깅

LENA_HOME/repository/monitoringDB/maintenance

6개월

10MB

서버 6대 기준의 예상 증가량
자동삭제

Manager모니터링, 진단리포트

LENA_HOME/repository/monitoringDB/{yyyyMMdd}

7일

N/A

자동삭제

Manager진단통계

LENA_HOME/repository/monitoringDB/statistics

영구

1MB 이하

　

ManagerDB백업파일

LENA_HOME/repository/backup/database

30일

100MB 이하

자동삭제

Manager로그

LENA_HOME/logs/lena-manager

30일

100MB 이하

자동삭제

Agent로그

LENA_HOME/logs/lena-agent

30일

N/A

자동삭제

Installer로그

LENA_HOME/logs/lena-installer

영구

1MB 이하

　

Patch적용파일

LENA_HOME/etc/patch

영구

N/A

패치시에만 생성됨
패치완료후 삭제가능

Patch백업파일

LENA_HOME/etc/backup/lena-patcher

영구

N/A

패치시 생성됨
패치완료후 삭제가능

Patch로그

LENA_HOME/logs/lena-patcher

영구

N/A

패치시 생성됨
패치완료후 삭제가능

서버인스턴스로그

서버인스턴스설치경로
LENA_HOME/servers/server_id/logs

영구

부하에 따라 판단

경로변경가능

서버인스턴스 히스토리

서버인스턴스설치경로
LENA_HOME/servers/server_id/history

영구

N/A

Manager를 통해 서버설정 변경시에 설정파일 변경분만 생성

서버인스턴스 스냅샷

서버인스턴스설치경로
LENA_HOME/servers/server_id/snapshot

영구

N/A

Manager를 통해 Cluster Snapshot을 생성하는 경우만 생성

WAS 덤프파일

LENA_HOME/repository/monitoringDB/dump

영구

N/A

Manager를 통해 WAS 덤프를 수행하는 경우에만 생성

10.9. Patch CLI (Command Line Interface)

Patch는 설치된 LENA에 대한 기능 개선 및 버그 수정을 위해 제공되는 기능이다. 압축파일 형태로 제공되며, 독립적으로 동작하는 Java프로세스로 동작한다.

Management UI를 통해 실행하는 방법은 patch 에서 제공한다. 여기에서는 CLI를 통해 패치 및 복원하는 방법에 대해 설명한다.

10.9.1. 패치파일 업로드 및 압축해제

전달받은 패치파일을 LENA가 설치된 서버로 FTP등을 이용하여 개별적으로 업로드 한다.

업로드 한 파일은 아래와 같은 위치에 압축을 해제하고 버전명으로 디렉토리의 명칭을 변경한다.Manager를 통하여 업로드하면 자동으로 해당 경로에 압축이 해제된다.

노드/서버 패치파일 경로: /engn001/lena/1.3.1/etc/patch/{패치버전}
Manager 패치파일 경우: /engn001/lena/1.3.1/repository/patch/{패치버전}

10.9.2. Patch

Node Patch

patch.sh를 실행하여 Node를 패치한다.

<패치파일압축해제경로>/bin/patch.sh lena-node

Node 패치과정에서 Node는 재기동 된다.

[bin]$ ./patch.sh lena-node

*******************************
* LENA Server Patch ! *
*******************************

2018-05-28 14:06:43:915 [INFO] Patch started to lena-node
2018-05-28 14:06:47:075 [INFO] Stopping node-agent
...
2018-05-28 14:06:52:595 [INFO] Starting node-agent
2018-05-28 14:06:52:748 [INFO] Patch completed to lena-node

 ========================= Execution Result ========================
MESSAGE : Patch succeeded
RESULT : Success
PATCH_HISTORY_ID : patch-20180528140643905
PATCH_TARGET : lena-node
PATCH_VERSION : 1.3.1.6
 ===================================================================
patch is completed.!!
Manager Patch

patch.sh를 실행하여 Manager를 패치한다.

manager 패치
<패치파일압축해제경로>/bin/patch.sh lena-manager

Manager 패치과정에서 Manager는 재기동 된다.

[bin]$ ./patch.sh lena-manager

*******************************
* LENA Server Patch ! *
*******************************

2018-05-28 14:05:32:752 [INFO] Patch started to manager
2018-05-28 14:05:36:032 [INFO] Stopping manager
...
2018-05-28 14:05:46:062 [INFO] Starting manager
2018-05-28 14:05:47:066 [INFO] Patch completed to manager

 ========================= Execution Result ========================
MESSAGE : Patch succeeded
RESULT : Success
PATCH_HISTORY_ID : patch-20180528140532668
PATCH_TARGET : lena-manager
PATCH_VERSION : 1.3.1.6
 ===================================================================

patch is completed.!!
Server Patch

patch.sh를 실행하여 개별적인 서버를 패치한다.

node가 설치된 서버에서 실행하여야 하고, LENA 서버 설치 유형별로 별도로 실행한다. 서버 패치를 위해서는 노드패치가 선행되어야 한다.

WAS standard type 패치
<패치파일압축해제경로>/bin/patch.sh lena-se
WAS enterprise type 패치
<패치파일압축해제경로>/bin/patch.sh lena-ee
Session Server 패치
<패치파일압축해제경로>/bin/patch.sh lena-session
Table 143. patch.sh의 입력 인수 및 입력 항목
항목설명비고

PATCH_TARGET

패치 타겟 (patch.sh의 인수로 입력)

lena-node

lena-manager

lena-se

lena-ee

lena-session

SERVER_ID

패치 타겟에 해당하는 서버 ID

lena-node, lena-manager 패치에는 불필요

[bin]$ ./patch.sh lena-ee

*******************************
* LENA Server Patch ! *
*******************************

2018-05-28 14:17:18:840 [INFO] Patch started to lena-se

Input SERVER_ID for execution. (q:quit)
wasEE_9100
...
2018-05-28 14:17:26:820 [INFO] Saving patch history
2018-05-28 14:17:26:842 [INFO] Patch completed to lena-se

 ========================= Execution Result ========================
MESSAGE : Patch succeeded
RESULT : Success
PATCH_HISTORY_ID : patch-20180528141639064
PATCH_TARGET : lena-ee
PATCH_VERSION : 1.3.1.6
 ===================================================================

patch is completed.!!

10.9.3. History

history.sh를 실행하여 패치 이력을 확인한다. 기본이력은 원복된 이력은 제외하고 보여주며, 전체이력은 모든 이력을 보여준다.

기본이력
<패치파일압축해제경로>/bin/history.sh
전체이력
<패치파일압축해제경로>/bin/history.sh all
[bin]$ ./history.sh

*******************************
* LENA Server Patch ! *
*******************************

LENA Patch History
1 lena-node / patch-20180528140643905
- action : PATCH
- id : patch-20180528140643905
- target : lena-node
- serverId : lena-node
- oldVersion : 1.3.1.0
- patchVersion : 1.3.1.6
- backupRoot:
/engn001/lena/1.2/etc/backup/lena-patcher/backup-20180528140643903
- timestamp : 20180528140643905
- restored : false
- handwork-status : NO_WORK

2 lena-manager / patch-20180528140532668
- action : PATCH
- id : patch-20180528140532668
- target : lena-manager
- serverId : lena-manager
- oldVersion : 1.3.1.0
- patchVersion : 1.3.1.6
- backupRoot:
/engn001/lena/1.2/etc/backup/lena-patcher/backup-20180528140532666
- timestamp : 20180528140532668
- restored : false
- handwork-status : NEED_WORK
- start of handwork-detail
...
- end of handwork-detail

3 lena-ee / patch-20180528141639064
- action : PATCH
- id : patch-20180528141639064
- target : lena-ee
- serverId : wasEE_9100
- oldVersion : 1.3.1.0
- patchVersion : 1.3.1.6
- backupRoot:
/engn001/lena/1.2/etc/backup/lena-patcher/backup-20180528141639062
- timestamp : 20180528141639064
- restored : false
- handwork-status : NO_WORK

history is completed.!!

10.9.4. Restore

restore.sh를 실행하여 적용한 패치에 대한 원복을 진행한다. (패치 적용 문제 발생 시)

Restore를 실행하면 패치 시점에 변경된 파일을 변경이전 상태로 복원한다.

<패치파일압축해제경로>/bin/restore.sh <PATCH_HISTORY_ID>

(PATCH_HISTORY_ID는 ./ history.sh 로 조회되는 id 값이다.)
[bin]$ ./restore.sh patch-20180423130610713

*******************************
* LENA Server Patch ! *
*******************************

2018-05-28 14:40:05:404 [INFO] Restore started to lena-ee
...
2018-05-28 14:40:05:532 [INFO] Restore completed to lena-ee

 ========================= Execution Result ========================
MESSAGE : Restore succeeded
RESULT : Success
 ===================================================================

restore is completed.!!

10.9.5. Version 확인

version.sh를 실행하여 현재 설치된 서버에 대한 패치상태를 확인할 수 있다.

<패치파일압축해제경로>/bin/version.sh
[bin]$ ./version.sh

*******************************
* LENA Server Patch ! *
*******************************

LENA Patch Information
1. Base Information
- Version : 1.3.1.6 (Up to date)
- LENA_HOME : /engn001/lena/1.3.1

2. lena-manager
2.1 - id : lena-manager / version : 1.3.1.6 (Up to date)

3. lena-se
3.1 - id : wasSE_9100 / version : 1.3.1.6 (Up to date)
3.2 - id : wasSE_9200 / version : 1.3.1.6 (Up to date)

4. lena-ee
4.1 - id : wasEE_9300 / version : 1.3.1.0 (Patch available to 1.3.1.6)
4.2 - id : wasEE_9400 / version : 1.3.1.0 (Patch available to 1.3.1.6)

5. lena-session
5.1 - id : session_5000 / version : 1.3.1.0 (Patch available to 1.3.1.6)
5.2 - id : session_5500 / version : 1.3.1.0 (Patch available to 1.3.1.6)

version is completed.!!

10.10. Session Server 상세

Application Server의 Session Clustering은 별도의 Session Server를 설치하여 Session을 공유해 Clustering 한다. Session Server는 별도 VM위에서 작동하는 Standalone 모드와 Application Server에 Session Server 모듈을 탑재한 Embedded 모드가 있다.

10.10.1. Session Server Standalone 모드

image
설치

설치방법은 “3.5.2. Install" 항목을 참조한다.

기동/중지 및 기동여부 확인

기동/중지 및 기동여부 확인은 "3.5.6 Start/Stop” 에서 확인한다.

환경설정

Session Server가 설치된 위치를 ${ZODIAC_HOME}이라 칭한다. Session Server는 LENA home 하위 /servers 폴더에 위치한다.

환경설정 정보는 ${ZODIAC_HOME}/session.conf 에 관리한다. 환경설정으로 변경 가능한 설정 항목은 아래와 같다.

항목설명

server_id

server ID

server_name

server Name

primary_port

해당 Session Server의 TCP listening port

session_max_count

최대 HTTP세션수

server_recv_queue_size

Secondary Server나 Application Server로부터 수신한 Session 정보 처리 요청 (최신 정보 변경 / 신규등록, Logout처리) Queue size

server_req_queue_size

타 Server로부터 수신한 Session정보 요청 (Session정보 요청, 최신 정보 확인 등)을 담는 Queue size

resp_queue_size

타 Server가 요청한 Session 정보에 대한 응답을 담는 Queue size

send_queue_size

타 Server로 전송할 Session 정보를 담는 Queue size

keep_alive_time

Application Server와 Session Server 간의 TCP연결을 유지하기 위해 더미 메세지를 보내는 간격, so_timeout보다 작아야 한다. 각 Application Server 의 설정과 일치시키는 것이 좋다.

so_timeout

Application Server와의 연결에서 read timeout

thread_request_handler

request Queue 에 쌓은 데이터 처리하는 Thread 개수.

thread_data_handler

receive Queue 에 쌓은 데이터 처리하는 Thread 개수.

debug_clustering

Debug용 Log를 남길지 여부

enable_auto_was_sync

true로 설정 했을때, 장애 등으로 재 연결된 WAS에 Sync 요청을 보내 WAS의 Session 데이터를 Sync 한다.

enable_auto_peer_sync

(장애 등으로) 재 연결된 Secondary Session Server에 Sync 요청을 보내 Slave Session Server의 Session 데이터를 Sync 할지 여부

server_expire_sec

서버에서 HTTP세션 정보를 expire 시키는 시간 (Session Timeout)

0인 경우, Application에서 설정한 session의 timeout 시간을 사용

server_expire_check_sec

Session Timeout 체크 주기. (단위 : 초)

secondary_host

Secondary 세션서버의 주소

secondary_port

Secondary 세션서버의 주소

enable_ready_after_sync

Secondary Server와 Session 데이터를 동기화를 수행한 후에, 연결된 WAS에 Clustering 서비스 제공 가능 상태(Ready)로 전송할지 여부 (true는 동기화 후 ready 상태 전송)

wait_server_ready_timeout

해당 시간 이 될 때까지 ready상태(Session Clustering서비스 제공가능 상태) 가 안되면 자동으로 ready 상태를 만들어준다.

server_ready_time

기동 시 Secondary Server와의 연결 대기 시간 (해당 값 * 100 ms).

max_logoutset

최대 로그아웃 된 HTTP 세션 수

enable_auto_logout_sync

true 인 경우, session entry 정보를 sync 할 때, logout 정보도 같이 sync 한다. (sticky가 아닌 round-robin일 경우 필요하다)

로그

로그는 ${LENA_HOME}/logs/session-server/lena-[Session Server Name]_[YYYYMMDD].log 로 남는다. 로그를 확인하고자 한다면 ${ZODIAC_HOME}/log.sh 파일을 실행시켜 확인 할 수도 있다.

[session_5002]$ ./log.sh

5월 09, 2018 02:55:50 오후 [ZODIAC] TCP listen 5002
5월 09, 2018 02:55:54 오후 [ZODIAC] ACCEPT NODE(Tomcat) /127.0.0.1:33138
5월 09, 2018 02:55:55 오후 [ZODIAC] SERVER_READY, no peer, time=5000
5월 09, 2018 02:59:57 오후 [ZODIAC] Zodiac Stop
5월 09, 2018 03:00:00 오후 [ZODIAC] Zodiac Session Server 1.3.0 20160420
5월 09, 2018 03:00:01 오후 [ZODIAC] TCP listen 5002
5월 09, 2018 03:00:01 오후 [ZODIAC] ACCEPT NODE(Tomcat) /127.0.0.1:33359
5월 09, 2018 03:00:03 오후 [ZODIAC] ACCEPT SERVER /127.0.0.1:46818
5월 09, 2018 03:00:04 오후 [ZODIAC] SYNC[session_5002] recv bulk
sessions : #0 recv bulk logout sessions : #0 recv bulk dupInfo : #0 2ms
5월 09, 2018 03:00:04 오후 [ZODIAC] SERVER_READY sync is done
5월 09, 2018 03:00:05 오후 [ZODIAC] TCP Primary name=session_5002
/127.0.0.1:5002
5월 09, 2018 03:00:05 오후 [ZODIAC] SYNC start 127.0.0.1:5002
5월 09, 2018 03:00:05 오후 [ZODIAC] SYNC Send bulk sessions send to
127.0.0.1:5002 #0 and logout session send : 0 and dupInfo send : 0
Console

Zodiac Session Server는 JMX를 통해 Session Server 정보 조회 및 Application Server Sync 명령을 수행 할 수 있다. ${ZODIAC_HOME} 의 console.sh 파일을 실행시켜 Zodiac Session Server의 JMX 기능을 사용한다.

[session_5002]$ ./console.sh

 =====zodiac session server JMX Console=====

 ------------------------------------------------------------

- Usage: ./console.sh <COMMAND> -
- <COMMAND> is one of the following: -
- 1. was_list -
- 2. status -
- 3. was_serverq -
- 4. was_sync -
-    It needs WAS ID -
-    example: ./console.sh was_sync <was id> -
- 5. search -
-    It needs SESSION ID. -
-    example: ./console.sh search <session id> -

 ------------------------------------------------------------

다음은 console.sh의 명령어에 대한 설명이다.

  • Application Server List

    현재 Session Server에 연결된 Application Server List를 보여준다.

    Shell명령어 console.sh was_list 를 실행하면 된다.

    [session_5002]$ ./console.sh was_list

 =====zodiac session server JMX Console=====

RUN OPERATION: getServerInfo

RESULT:server=\{addr:/127.0.0.1:54001,name:wasEE7_29100,
info:\{server_name=wasEE7_29100,pid=24915,hostname=solwas4,jvmName=bde0fbb29e8100285,context=/jpetstoreJTA;ROOT;/lena;/EPS;/HelloWorldWeb,type=INSTANCE}}server=
\{addr:/127.0.0.1:33912,name:wasEE3_29100,
info:\{server_name=wasEE3_29100,pid=10607,hostname=solmanager,jvmName=2b2451dd049f00285,context=/jpetstoreJDBC;ROOT;/jpetstore3,type=INSTANCE}}

  • Session Server Status

    현재 Session Server의 상태 값을 보여준다.

    Shell명령어 console.sh status 를 실행하면 된다.

    [session_5002]$ ./console.sh status

 =====zodiac session server JMX Console=====

RUN OPERATION:

getStatusString\{request_getfresh_logout:0,session_count:0,req_lost:0,request_
getfresh_not_new:0,request_getfresh_nodata:0,request_getnew_secondary:0,session_expired:0,request_getnew_logout:0,session_timeout:1800,request_getnew_nodata:0,session_max_count:2000000
,logout_from_nodes:0,pid:32705,session_recv_lost:0,logout_from_secondary:0,request_getfresh_secondary:0,request_getfresh:0,request_getnew:0,logout_count:0,data_from_nodes:0,resp_lost:0,request_getfresh_data:0,data_from_secondary:0}

  • Session Server ServerQ Status

    Zodiac Session Server의 ServerQ 상태를 보여준다. ServerQ는 Session Server에 연결된 Application Server의 접속을 관리하는 모듈이다. 여기서 보여주는 데이터는 Application Server 에서 보내는 Session 정보(data)와 Request 정보(Request)를 담는 Queue 정보이다.

    Shell명령어 console.sh was_serverq 를 실행하면 된다.

    [session_5002]$ ./console.sh was_serverq

=====zodiac session server JMX Console=====

PRINT ATTRIBUTEdataQ.size: 0requestQ.size: 0dataQ.overCnt:
0requestQ.overCnt: 0

  • Session Id Search

    입력한 Session ID와 일치하는 Session을 가지고 있는 Application Server List 를 보여준다.

    Shell명령어 console.sh search [Session ID] 를 실행하면 된다.

    [session_5002]$ ./console.sh search
B38E30BDE5223BAA0221B9479AF3DDAF.6ef7931859a200285 +
 =====zodiac session server JMX Console=====

RUN OPERATION: search

RESULT:\{'AE4_29100'=\{lastAccessTime='2018-05-24
15:55:48.503',context='ROOT',attributeNames=[sessiontest.counter,
ARGO_DUPLICATION_STATUS],lastUpdateTime='2018-05-24
15:55:48.501',addr='/127.0.0.1:44568',id=B38E30BDE5223BAA0221B9479AF3DDAF.6ef7931859a200285,createTime='2018-05-24
15:55:43.241'}}

  • Application Server Session Sync

    Application Server의 Session 정보를 Session Server로 sync하는 경우 실행한다.

    Shell명령어 console.sh was_sync [Application Server jvmName(was_list에서 jvmName으로 출력되는 값)] 를 실행하면 된다.

    [session_5002]$ [session_5002]$ ./console.sh was_list

 =====zodiac session server JMX Console=====

RUN OPERATION: getServerInfo

RESULT:server=\{addr:/127.0.0.1:54001,name:wasEE7_29100,
info:\{server_name=wasEE7_29100,pid=24915,hostname=solwas4,jvmName=bde0fbb29e8100285,context=/jpetstoreJTA;ROOT;/lena;/EPS;/HelloWorldWeb,type=INSTANCE}}server=
\{addr:/127.0.0.1:33912,name:wasEE3_29100,
info:\{server_name=wasEE3_29100,pid=10607,hostname=solmanager,jvmName=2b2451dd049f00285,context=/jpetstoreJDBC;ROOT;/jpetstore3,type=INSTANCE}}}
    [session_5002]$ ./console.sh was_sync bde0fbb29e8100285

 =====zodiac session server JMX Console=====

RUN OPERATION: serverSyncsync complete
Session Server failover

Session Server는 Primary/Secondary로 구성되어있고, 실시간으로 Session 정보를 동기화 한다. Application Server는 Primary/Secondary Session Server와 접속을 유지하고 있기 때문에 Primary Session Server 장애가 생겼을 경우, 장애 감지 시점 이후부터 Secondary Session Server로 Failover 된다.

image

10.10.2. Session Server Embedded 모드

Session Server Embedded 모드는, Application Server 내에 Session Server Module을 내장하는 방식이다.

image
환경 설정

Embedded 모드로 Session Server 설정을 하려면 Manager의 Application Server 설정 화면에서 설정하거나 ${LENA_HOME}/servers/[ApplicationServer명]/conf/session.conf 를 수정한다.

image

화면에 표시되는 항목에 대한 설명은 아래와 같다.

항목설명비고

Mode

Embedded 또는 Standalone Session Server의 Client 모드 선택

Embedded Host

Session Cluster의 Primary서버의 노드명 과 서버명

Embedded Port

Session Cluster의 Primary서버의 서비스 포트

Secondary Server Host

Session Cluster의 Secondary 서버의 노드명 과 서버명

Secondary Server Port

Session Cluster의 Secondary 서버의 서비스 포트

Multi Login Control

다중 로그인 체크 여부

false

Logout Page (Multi Login)

다중 로그인시 먼저 로그인 한 사용자에게 표시되는 로그아웃 결과 페이지

Logout Message (Multi Login)

다중 로그인시 로그아웃 결과 메시지, ajax Client에게 JSON 타입으로 제공됨

Expected Page for Multi Check

Manager 에서는 설정할 수 있는 설정 값은 정해져 있다. 기본적으로 default 설정을 따르도록 한다.

아래는 session.conf 파일로 변경 가능한 환경설정 값이다.

항목설명기본값

enable_clustering

Session clustering 할지 여부. False면 Session Server에서 session을 find하지 않는다.

TRUE

debug_clustering

debug 할지 여부

FALSE

primary_host

Primary Session Server의 주소

Embedded 모드인 경우에는 Embedded Host 값

127.0.0.1

primary_port

Primary Session Server의 port

Embedded 모드인 경우에는 Embedded Port 값

5005

secondary_host

Secondary Session Server의 주소,
Application Server와 Primary Session Server의 연결이 끊어진 경우에만 사용된다.

Embedded 모드인 경우에는 Slave Server Host 값

127.0.0.1

secondary_port

Secondary Session Server의 port,
Application Server와 Primary Session Server의 연결이 끊어진 경우에만 사용

Embedded 모드인 경우에는 Slave Server Port 값

5006

recv_queue_size

타 Server로부터 수신한 Session 정보 처리 요청 (최신 정보 변경 / 신규등록, Logout처리) Queue size

512

req_queue_size

타 Server로부터 수신한 Session정보 요청 (Session정보 요청, 최신 정보 확인 등) Queue size

512

resp_queue_size

타 Server로부터 수신한 Session 정보 요청에 대한 응답을 담는 Queue size

512

send_queue_size

타 Server로 전송할 Session 정보를 담는 Queue size

512

keep_alive_time

Application Server와 Session Server 간의 TCP연결을 유지하기 위해 더미 메세지를 보내는 간격, so_timeout보다 작아야 한다.

3000

so_timeout

Session Server와의 연결에서 read timeout

8000

tcp_open_try_interval

Session Server에 연결이 끊어진 경우 재 연결 시도를 위한 간격

5000

find_timeout

Application Server에서 트랜잭션이 세션을 검색할 때 서버 응답을 기다리는 시간 이 시간 동안 서버가 응답이 없으면 Application Server은 해당 세션을 서버가 가지고 있지 않은 것으로 간주한다

500

wait_server_ready_cnt

Server와 통신연결은 되었으나, Server 상태가 ready가 아닌 경우 최대 설정 초만큼 기다린다. -1인 경우 무한대로 기다린다.

-1

server_embedded

session server 모듈을 embedded 할지 여부. True면 session server 모듈을 embedded 한다.

false

max_logoutset

로그아웃된 HTTP 세션을 보관하는 set 크기

20000

check.duplication.login

중복 로그인 체크 여부

false

주1) 타 Server : 연결된 Session Server 또는 Cluster된 Application Server