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

1. Overview

1.1. LENA는 무엇입니까?

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

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

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

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

1.2. LENA 특징

고효율 특성

LENA Web Application Server는 타사 WAS에 비해 기동성능, Application Deploy성능의 향상을 이루었고, CPU/Memory 등 자원 사용 효율성이 향상되었다.

Open Source 호환성 보장

LENA Web Server, LENA WAS는 Open Source Base로 구현되어 완벽한 Open Source 호환성을 보장한다. Open Source 기반으로 작성된 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는 내부적으로 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 Server : 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

Exception

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

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 설치가능

Engine No.

Node의 엔진 넘버

Engine No.는 LENA의 엔진 넘버를 의미하며 WAS의 Java Spec버전 별로 다르다.

  • EN7: Java EE 6 / Servlet 3.0 지원

  • EN8: Java EE 7 / Servlet 3.1 지원

  • EN9: Java EE 8 / Servlet 4.0 지원

  • EN10: Jakarta EE 10 / Servlet 6.0 지원

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의 유형

다음과 같은 타입을 제공함

  • Enterprise/SE

Engine No.

Server의 엔진 넘버

Engine No.는 LENA의 엔진 넘버를 의미하며 WAS의 Java Spec버전 별로 다르다.

  • EN7: Java EE 6 / Servlet 3.0 지원

  • EN8: Java EE 7 / Servlet 3.1 지원

  • EN9: Java EE 8 / Servlet 4.0 지원

  • EN10: Jakarta EE 10 / Servlet 6.0 지원

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 정보를 추가로 확인해야 한다.

  • WAS서버의 원격 복제시에는 Node의 Engine No.가 같아야 WAS서버를 Clone할 수 있다.

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 버튼 을 누르면 삭제 유형을 선택하는 창이 출력된다.

    • Deregister : 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 명을 선택한다. General, Session, Logging, Web Config, Environment, Properties, Audit, Config Tree, History, TunA 탭을 제공하며, 설정 정보 수정 시 백업을 하여 복원이 가능하다.

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(MB)(*)

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

Default : 2048

Maximum Heap Size(MB)(*)

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

Default : 2048

AppBase

Application의 Base 디렉토리

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

Jvm Route

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(s)

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

Default : 86400

  1. Connector

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

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

Protocol

프로토콜 유형

HTTP/1.1, AJP/1.3

port

포트번호

Redirect Port

Redirect 포트

HTTPS Port와 동일

Connection Timeout(ms)

커넥션 타임아웃(ms)

HTTP : 20000,

AJP : 60000

URI Encoding

URI byte를 변환하기 위한 Character Encoding

UTF-8

Server

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

Server

Max Threads

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

256

Min Spare Threads

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

10

Max Queue Size

Request Queue 의 최대길이

Integer.MAX_VALUE

Packet Size

AJP packet 크기

8192

Enable Lookups

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

false

Compression

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

off

Tcp No Delay

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 Endpoint

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

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

Service Endpoint Address

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

Session

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

  1. Embedded Session Server 모드

    WAS에 Session Server 모듈을 Embedded하여 동작하는 경우 선택한다. Session Server Mode 항목에서 Embedded 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 when Multi Login check(Multi Login)

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

Logout Message when Multi Login check(Multi Login)

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

Excepted Page When Multi Login Check(Multi Login)

이중 로그인 체크 예외 URL

  1. Standalone 모드

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

    Standalone 모드에서 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객체를 공유

Standalone Mode에서만 설정가능

false

Multi Login Control

이중 로그인 방지여부

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

Logout Page when Multi Login check(Multi Login)

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

Logout Message when Multi Login check(Multi Login)

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

Excepted Page When Multi Login Check(Multi Login)

이중 로그인 체크 예외 URL

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

Logging

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

  1. Log Home

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

Log Home(*)

Log Home 경로

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

Retention Days(*)

로그 최대 보관 일수

Default : 0(무제한)

  1. Access Log

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

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

Logging Directory

Log 디렉토리

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

Pattern

Logging field의 Layout

Prefix

Log 파일의 prefix

Suffix

Log 파일의 suffix

  1. Handler List

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 Handler

Root Logger여부

  1. Logger List

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. 주요 설정
항목(*는 필수값)설명기본값

Directory Listing

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

false

Readonly

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

true

Input Buffer Size

Input buffer size in bytes

2048

Output Buffer Size

Output buffer size in bytes

2048

File Encoding

File Encoding

platform default

Show Server Info

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

true

Load On Startup(*)

WAS 기동 시 Servlet 로딩 순서 지정

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

  1. JSP Engine

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

Check Interval(s)

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

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

Development

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

true

Generate String As Character Array

String생성을 Char Array로 할지 여부

false

Modification Test Interval(s)

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

4 (0일 경우: 매 access마다 점검)

Trim Spaces

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

false

Java Encoding

Java소스를 generate할때의 Encoding

UTF8

Load On Startup(*)

WAS 기동 시 Servlet 로딩 순서 지정

3

  1. JSP Page Encoding

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

URL Pattern

Page Encoding을 적용할 JSP Page의 URL Pattern

JSP Page Encoding

적용할 Page Encoding을 지정

  1. Session

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

Session Timeout(m)

세션 타임아웃 시간(분)

Default : 30

  1. Welcome File List

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

File(*)

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

Environment

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

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

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

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

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

  • 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가 기동된 상태에서만 정보를 확인할 수 있다.

Audit

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

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

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

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

Enable

Out Of Memory Error 발생을 감지한다

Default : true

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

Enable

Stuck Thread 발생을 감지한다

Default : false

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

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

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

Enable

Full GC 발생을 감지한다

Default : false

Table 25. 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

Max Line of Stack’s Cause

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

Default : 3

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

Config Tree

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

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

History

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

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

4.3.9. Resource 관리

Server메뉴 하위의 Resources메뉴를 선택하면 해당 Server에 관련된 Resource정보를 관리할 수 있는 화면이 표시된다. DataSource에 대한 정보를 관리할 수 있다.

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 설정을 하여 사용할 수도 있다.

  1. Server DataSource 설정

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

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

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

Table 26. 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)(*)

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

Driver Class Name(*)

JDBC Driver 클래스명

URL(*)

JDBC URL

User Name(*)

접속 사용자명

Password(*)

접속 패스워드

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

Encryption Level

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

Default : Password only

DefaultAutoCommit

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

Default : JDBC driver의 기본값

Auto Reconnection

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

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(ms)

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

Default : 30000

MinEvictableIdleTimeMillis(ms)

해당 시간 이상 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(ms)

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

Default : 5000

RemoveAbandoned

Connection 유실 검출 여부

Default : default

RemoveAbandonedTimeout(s)

유실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의 기본값이 사용된다.

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

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

  • Password 암호화 알고리즘은 AES를 사용하고 있다. 암호화를 위한 키 값은 Manager LENA Home 하위 /repository/conf/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"

4.3.10. Application 배포

목록

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

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

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

Type

배포할 Application의 형태

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 28. Application 배포 속성
항목(*는 필수값)설명비고

Application Type

배포할 Application의 형태

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 29. 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로의 접근 차단 여부

session Cookie Domain

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

session Cookie Name

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

Default : JSESSIONID

session Cookie Path

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

useNaming

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

Default : true

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

DataSource Link List

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

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

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

Name(*)

Application에서 사용할 JNDI 이름

JNDI Name(*)

Global DataSource의 JNDI이름

User Name

DataSource 접속 사용자 명

URL

JDBC URL

Description

DataSource에 대한 설명

+ 아이콘

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

- 아이콘

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

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

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

4.4. WebA Server

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

4.4.1. 목록

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

server 4 web server

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

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

Status

Server의 상태

아래와 같은 상태를 제공함

  • Started(v)

  • Stop(ㅁ)

  • Error(!)

Name(*)

Server의 이름

Address

Server의 IP주소

Server ID

Server의 ID

Engine

Node의 Engine 타입

  • EN-A

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 버튼 을 누르면 삭제 유형을 선택하는 창이 출력된다.

    • Deregister : 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 32. 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 Server 종료시 참조하는 옵션

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

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

Directory/Path

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

Directory/Options

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

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

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

Directory/Allow Override

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

다음과 같은 유형이 존재함

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

Directory/Require

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

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

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

Timeout(s)(*)

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

Default : 60

Keep Alive(*)

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

Default : On

Max Keep Alive Requests(*)

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

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

Default : 100

Keep Alive Timeout(s)(*)

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

Default : 5

Request Read Timeout(s)(*)

사용자로부터 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 34. Process Info
항목(*는 필수값)설명비고

Start Servers(*)

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

Default : 2

Server Limit(*)

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

Default : 8

Threads Per Child(*)

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

Default : 128

Thread Limit(*)

ThreadsPerChild의 설정 가능한 최대 값

Default : 128

Min Spare Threads(*)

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

Default : 128

Max Spare Threads(*)

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

Default : 256

Max Request Workers(*)

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

Default : 1024

Max Connection Per Child(*)

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

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 35. Pagespeed Info
항목(*는 필수값)설명비고

Enabled(*)

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

Default : off

다음과 같은 옵션을 제공함

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

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

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

Rewrite Level(*)

모듈이 rewrite할 필터의 Level 설정

Default : default(CoreFilters)

다음과 같은 옵션을 제공함

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

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

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

File Cache Path(*)

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

LogDirPath(*)

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

Enable Filters

사용할 필터들의 목록

Disable Filters

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

Allow URI

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

예) /.js

Disallow URI

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

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

Connector

Web Server와 WAS를 연계하기 위한 정보를 관리한다.
Connector 페이지는 연계 방식에 따라 JK와 Proxy 탭으로 나누어져 있으며, 각 탭에서 모듈에 따른 Connector 설정 정보를 편집할 수 있다.

JK

JK(mod_jk)를 사용할 때의 설정 정보를 편집한다.

server 4 web server jk

JK 탭의 설정은 위 화면과 같이 Connector Info, Load Balancer, URI Pattern Group의 세 가지 영역으로 나누어져 있다.

  1. Connector Info
    JK의 기본 설정 값을 관리한다.

server 4 web server jk connector info
Table 36. Connector Info (JK)
항목(*는 필수값)설명비고

Type(*)

Web Server와 WAS가 통신할 때 사용하는 프로토콜이다.
(ajp12, ajp13, ajp14, jni, lb 그리고 status 중 하나를 사용할 수 있으나 ajp13, lb, status를 권장한다.)

Default: ajp13

Load Balancing Factor(*)

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

Default: 1

Request Read Timeout(s)(*)

JK와 원격 호스트 간의 통신 채널에 사용되는 Timeout(초)이다. 지정된 시간 초과 내에 원격 호스트가 응답하지 않으면 JK가 오류를 발생시키고 다시 시도한다.
0(기본값)으로 설정하면 JK는 모든 소켓 작업에서 계속 응답을 기다린다.

Default: 300

Socket Connect Timeout(s)(*)

JK와 원격 호스트 간 소켓 연결을 구성하는 데에 걸리는 시간(초)의 임계치를 의미한다. 지정된 시간 내에 소켓 연결을 구성하지 못하면 JK가 오류를 발생시키고 재연결을 시도한다.

Default: 5

Socket Keep Alive(*)

Web Server와 WAS 사이에 방화벽이 존재하는 경우 비활성화 된 연결을 버리도록 되어있으나, 이 속성이 TRUE일 때에는 운영 체제에 KEEP_ALIVE 메시지를 보내도록 함으로써 방화벽이 비활성화 된 연결을 끊지 못하도록 한다.

Default: TRUE

Connect Timeout(*)

connectTimeout: JK와 WAS 간 연결이 완료된 후, ajp13 프로토콜에서 cping request에 대한 cpong respond 대기 시간(s)을 의미한다.

Default: 10

Connection Pool Size(*)

JK와 WAS 간 커넥션 풀로 유지 관리되는 커넥션 개수를 의미한다.

Default: 128

Connection Pool Min Size(*)

JK와 WAS 간 커넥션 풀로 유지 관리되는 커넥션의 최소 개수를 의미한다.

Default: 32

Connection Pool Timeout(s)(*)

JK가 비활성화 된 소켓을 닫기 전에 유지해야 하는 시간(초)을 지정한다. 0으로 지정 시 소켓을 닫는 것을 비활성화 한다.

WAS의 connectionTimeout 옵션과 함께 사용한다.
Default: 20

Log Level(*)

로그 파일에 기록될 로그 수준을 지정한다.

Default: error

Log Format(*)

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

Default: "[%a %b %d %H:%M:%S %Y]"

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
    부하 분산을 위해 Load Balancer의 기본 설정 및 Worker를 관리한다.
    Load Balancer 영역에는 Overview 탭과 Configuration 탭이 존재하며, Overview 탭에서는 현재 생성되어 있는 Load Balancer의 전반적인 정보를 확인할 수 있고 Configuration 탭에서는 Load Balancer의 상세 내용을 구성할 수 있다.

server 4 web server jk lb overview
Table 37. Load Balancer Info - Overview (JK)
항목(*는 필수값)설명비고

Load Balancer ID

현재 생성되어 있는 Load Balancer의 ID이다.

Target Server

Load Balancer에 등록된 Worker의 기본 정보이다.
'Node Name/Server Name' 형식으로 출력된다.

URI Pattern Group ID

특정 URI Pattern에서 Load Balancer를 지정한 경우, 해당 URI Pattern이 속해있는 URI Pattern Group ID가 출력된다.

server 4 web server jk lb config
Table 38. Load Balancer Info - Configuration (JK)
항목(*는 필수값)설명비고

Load Balancer ID(*)

Load Balancer의 이름이다.

'lb_'라는 접두사가 추가된다.

Sticky Session(*)

Session ID를 기반으로 라우팅을 지원할 지에 대한 여부이다.

Method(*)

Load Balancer가 부하를 분산하기 적절한 Worker를 판별하는데 사용하는 방법을 지정한다.

* R[equest] : 요청수가 가장 적은 Worker를 선택한다. (Default)
* S[ession] : 연결된 세션이 가장 적은 Worker를 선택한다.
* N[ext] : S[ession]과 비슷하지만 더 적은 수의 Session을 분산해야 하는 경우 선택한다.
* T[raffic] : JK와 AJP커넥터 사이에 네트워크 트래픽이 가장 작은 Worker를 선택한다.
* B[usyness] : 요청 수를 기반으로 가장 부하가 적은 Worker를 선택한다.

Session Cookie

Session Cookie 이름을 변경하고자 하는 경우 설정한다.

Default: JSESSIONID

Worker는 Load Balancer Worker List 테이블의 Add Worker 버튼으로 추가한다.
Add Worker 버튼을 눌렀을 때 Worker를 추가할 수 있는 창이 화면에 출력되며, 사용자는 이 창에서 LENA Manager에서 관리하는 서버를 Worker를 선택할 수 있다. 추가된 Worker는 아래와 같은 정보를 통해 관리된다.

Table 39. Load Balancer Worker List
항목(*는 필수값)설명비고

Node Name

Worker가 가리키는 서버의 노드 이름이다.

Server Name

Worker가 가리키는 서버의 이름이다.

Server Type

Worker가 가리키는 서버의 유형이다.

값으로 Standard 또는 Enterprise가 출력 된다.

Redirect

해당 Worker가 오류 상태일 때, 이 Worker가 받은 요청을 대신 처리 할 Failover Worker를 설정한다.

Default: NONE

Load Balancing Factor

작업량 할당 비율으로, 해당 Worker가 다른 Worker들에 비해 얼마나 많은 일을 할 지 정의한다.

Default: 1

Route ID

Worker의 Route ID이다.

Order

Worker들 간의 순서를 변경할 수 있다.

  1. URI Pattern Group
    Web Server로 들어온 요청들에 대해 URI 패턴을 검사하여 WAS로 전달하는 URI Mapping을 정의한다.

server 4 web server jk uri pattern group
Table 40. URI Pattern Group (JK)
항목(*는 필수값)설명비고

URI Pattern Group ID(*)

URI 패턴을 그룹화하고 관리하는 데 사용되는 이름이다.
Virtual Host에서 사용하는 URI Pattern Group일 경우, ID 옆에 어느 Virtual Host에서 사용하고 있는 지에 대한 정보가 함께 출력된다.

Group 생성 시 'uri_'라는 접두사가 추가된다.

Mode

URI 패턴을 LENA Manager가 관리하는 형식으로 입력할 지, 사용자 임의로 입력할 지 지정한다. 본 항목에 따라 Patterns to be Included/Excluded 또는 URI Patterns로 입력하는 화면이 출력된다.
이미 저장된 패턴이 LENA Manager가 관리하는 방식이라면 Standard로, 사용자 임의 형식이라면 Manual로 자동 지정된다.

Standard: LENA Manager URI Rule에 따른 입력 방식
Manual: 사용자 임의 입력 방식

Patterns to be Included

WAS로 전달 할 URI 패턴을 입력한다. 우측 Select box를 통해 Load Balancer를 선택해야 저장할 수 있다. ⓧ버튼을 통해 패턴을 삭제할 수 있다.

모든 문자를 허용하는 의미의 Asterisk(*)를 사용할 수 있으며 Hash(#), Equal(=)은 허용되지 않는다.

Patterns to be Excluded

WAS로 전달 하지 않을 URI 패턴을 입력한다. ⓧ버튼을 통해 패턴을 삭제할 수 있다.

모든 문자를 허용하는 의미의 Asterisk(*)를 사용할 수 있다.

URI Patterns

사용자 임의의 패턴을 입력할 시 사용한다.

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

Proxy

Proxy(mod_proxy)를 사용할 때의 설정 정보를 편집한다.

server 4 web server proxy

Proxy 탭의 설정은 Connector Info, Load Balancer, URI Pattern Group의 세 가지 영역으로 나누어져 있다.

  1. Connector Info
    Proxy의 기본 설정 값을 관리한다.

server 4 web server proxy connector info
Table 41. Connector Info (Proxy)
항목(*는 필수값)설명비고

Socket Connect Timeout(s)(*)

Apache httpd가 백엔드에 연결을 생성하는 것을 완료할때 까지 대기하는 시간(s)이다.

Default: 5

DNS Lookup Interval(s)(*)

DNS 조회 간격. 기능을 사용하지 않으려면 0으로 설정한다.

Default: 10

Request Read Timeout(s)(*)

Apache httpd가 백엔드에서 주고 받는 전송된 데이터를 기다리는 시간(초)이다.

Default: 300

Background ServerFault Check Interval(s)(*)

백엔드 서버와 연결된 Member가 오류 상태인 경우, 본 항목에 설정한 간격(초)으로 서버를 확인하고 서버가 정상 동작 하면 요청을 다시 전달한다. 기능을 사용하지 않으려면 0으로 설정한다.

Default: 10

ServerFault Retry Time(s)(*)

백엔드 서버와 연결된 Member가 오류 상태인 경우, Apache httpd timeout(초)이 만료될 때 까지 어떠한 요청도 해당 서버에 전달하지 않는다.

Background ServerFault Check Interval 항목이 0인 경우 수정 가능하다.
Default: 60

  1. Load Balancer
    부하 분산을 위해 Load Balancer의 기본 설정 및 Member를 관리한다.
    Load Balancer 영역에는 Overview 탭과 Configuration 탭이 존재하며, Overview 탭에서는 현재 생성되어 있는 Load Balancer의 전반적인 정보를 확인할 수 있고 Configuration 탭에서는 Load Balancer의 상세 내용을 구성할 수 있다.

server 4 web server proxy lb overview
Table 42. Load Balancer Info - Overview (Proxy)
항목(*는 필수값)설명비고

Load Balancer ID

현재 생성되어 있는 Load Balancer의 ID이다.

Target Server

Load Balancer에 등록된 Member의 기본 정보이다.
'Node Name/Server Name' 또는 'Address:Port' 형식으로 출력된다.

URI Pattern Group ID

특정 URI Pattern에서 Load Balancer를 지정한 경우, 해당 URI Pattern이 속해있는 URI Pattern Group ID가 출력된다.

server 4 web server proxy lb config
Table 43. Load Balancer Info - Configuration (Proxy)
항목(*는 필수값)설명비고

Load Balancer ID(*)

Load Balancer의 이름이다.

'lb_'라는 접두사가 추가된다.

Sticky Session(*)

Session ID를 기반으로 라우팅을 지원할 지에 대한 여부이다.

Method(*)

Load Balancer가 부하를 분산하기 적절한 Member를 판별하는데 사용하는 방법을 지정한다.

* R[equest] : 요청수가 가장 적은 Member를 선택한다. (Default)
* T[raffic] : 네트워크 트래픽이 가장 작은 Member를 선택한다.
* B[usyness] : 요청 수를 기반으로 가장 부하가 적은 Member를 선택한다.

Session Cookie

Session Cookie 이름을 변경하고자 하는 경우 설정한다.

Protocol Type(*)

Member의 프로토콜 타입을 지정한다. Member가 지정되어 있지 않은 경우에만 변경 가능하다.

Default: HTTP

SSL Enable

Proxy용 SSL/TLS 프로토콜 엔진을 사용한다.

이 옵션은 설정이 불가능하며 오직 Protocol 설정에 따라 동작한다.
Default: HTTP인 경우 Off, HTTPS인 경우 On

SSLProxyCheckPeerExpire

원격 서버 인증서가 만료되었는지 확인한다.

Default: On

SSLProxyCheckPeerCN

원격 서버 인증서의 CN 필드를 확인한다.

Default: Off

Member는 Load Balancer Member List 테이블의 Add Member 버튼으로 추가한다.
Add Member 버튼을 눌렀을 때 Member를 추가할 수 있는 창이 화면에 출력되며, 사용자는 이 창에서 LENA Manager에서 관리하는 서버를 Member로 선택하거나 직접 Member 정보를 입력하여 추가할 수 있다.

추가된 Member는 아래와 같은 정보를 통해 관리된다.

Table 44. Load Balancer Member List
항목(*는 필수값)설명비고

Target Server

Member가 가리키는 서버의 기본 정보이다.
LENA Manager에서 관리하는 Member인 경우 Node Name/Server Name의 형태로, LENA Manager가 관리하지 않는 Member인 경우 Address:Port의 형태로 출력된다.

Protocol Type

Member가 사용하는 프로토콜 유형이다.

Redirect

해당 Member가 오류 상태일 때, 이 Member가 받은 요청을 대신 처리 할 Failover Member를 설정한다.

Default: NONE

Load Balancing Factor

작업량 할당 비율으로, 해당 Member가 다른 Member들에 비해 얼마나 많은 일을 할 지 정의한다.

Default: 1

Route ID

Member의 Route ID이다.

Sticky Session을 사용하는 경우 필수로 입력해야 한다.

Order

Member들 간의 순서를 변경할 수 있다.

  1. URI Pattern Group
    Web Server로 들어온 요청들에 대해 URI 패턴을 검사하여 WAS로 전달하는 URI Mapping을 정의한다.

server 4 web server proxy uri standard
Table 45. URI Pattern Group (Proxy)
항목(*는 필수값)설명비고

URI Pattern Group ID(*)

URI 패턴을 그룹화하고 관리하는 데 사용되는 이름이다.
Virtual Host에서 사용하는 URI Pattern Group일 경우, ID 옆에 어느 Virtual Host에서 사용하고 있는 지에 대한 정보가 함께 출력된다.

Group 생성 시 'uri_'라는 접두사가 추가된다.

Mode

URI 패턴을 LENA Manager가 관리하는 형식으로 입력할 지, 사용자 임의로 입력할 지 지정한다. 본 항목에 따라 Patterns to be Included/Excluded 또는 URI Patterns로 입력하는 화면이 출력된다.
이미 저장된 패턴이 LENA Manager가 관리하는 방식이라면 Standard로, 사용자 임의 형식이라면 Manual로 자동 지정된다.

Standard: LENA Manager URI Rule에 따른 입력 방식
Manual: 사용자 임의 입력 방식

Patterns to be Included

WAS로 전달 할 URI 패턴을 입력한다. 우측 Select box를 통해 Load Balancer를 선택해야 저장할 수 있다. ⓧ버튼을 통해 패턴을 삭제할 수 있다.

모든 문자를 허용하는 의미의 Asterisk(*)를 사용할 수 있으며 Hash(#), Equal(=)은 허용되지 않는다.

Patterns to be Excluded

WAS로 전달 하지 않을 URI 패턴을 입력한다. ⓧ버튼을 통해 패턴을 삭제할 수 있다.

모든 문자를 허용하는 의미의 Asterisk(*)를 사용할 수 있다.

URI Patterns

사용자 임의의 패턴을 입력할 시 사용한다.

설정을 변경할 경우 수정된 사항의 반영을 위하여 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 46. Virtual Host Info 설정 정보
항목(*는 필수값)설명비고

Virtual Host ID(*)

Virtual Host 이름

Port(*)

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

Document Root(*)

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

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

Server Name(*)

가상호스트 식별 하는 도메인 명

Server Alias

가상호스트가 사용하는 ServerAlias

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

Custom Log(*)

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

Directory/Path

DocumentRoot에서 지정한 경로

Directory/Options

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

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

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

Directory/Allow Override

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

다음과 같은 유형을 제공함

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

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

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

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

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

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

Directory/Require

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

Connector Enable

가상 호스트 Connector 설정 여부

Connector Type/ID

가상 호스트 Connector 를 설정 하는 경우 Jk/Proxy 유형에 따라 선택

Connector Tab 에서 생성한 Connector 목록 표시.

Rewrite Enable

Rewrite 사용여부

Rewrite Config

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

SSL Enabled

SSL 사용여부

SSL Port(*)

HTTPS Port

SSL Certificate File(*)

SSL 인증서 경로

SSL Certificate Key File(*)

SSL인증서 Key파일 경로

SSL Certificate Chain File

File of PEM-encoded Server CA Certificate

SSL CA Certificate File

ROOT인증서 경로

Https Redirect Enabled

Http→Https Redirect 사용여부

SSL Log Separation

SSL Log 설정 분리 사용여부

SSL Custom Log(*)

SSL Custom Log 설정

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

Logging

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

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

  1. Log Home

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

Log Home(*)

Log Home 경로

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

Retention Days(*)

로그 최대 보관 일수

Default : 0(무제한)

  1. Error Log

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

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

Location(file/pipe)(*)

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

Log Level(*)

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

  1. Log Format

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

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

Format(*)

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

Nickname(*)

사용할 로그포맷의 명칭

  1. Log Format with logio

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

Format(*)

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

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

Nickname(*)

사용할 로그포맷의 명칭

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

  1. Log Env

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

Table 51. Log 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 name(*)

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

Varname, !varname 또는 varname=value

Case

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

With case : 대소문자 구분

No case : 대수문자 구분없음

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

Environment

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

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

  • Base Env ($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 버튼 을 클릭하여 해당 설정파일로 복원할 수 있다.

TunA

DIAGNOSTICS의 TunA APM 메뉴에서 설치 작업을 수행한 TunA Java Agent의 제어 및 개별 환경 설정 관리를 할 수 있다.

4.5. WebN Server

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

4.5.1. 목록

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

server 5 web server

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

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

Status

Server의 상태

아래와 같은 상태를 제공함

  • Started(v)

  • Stop(ㅁ)

  • Error(!)

Name(*)

Server의 이름

Address

Server의 IP주소

Server ID

Server의 ID

Engine

Node의 Engine 타입

  • EN-N

Protocol Type

프로토콜 타입

  • HTTP

  • HTTPS

  • TCP

  • UDP

Port

포트 번호

Server의 시작 및 종료

+ 아이콘

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

- 아이콘

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

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

4.5.2. Install

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

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

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

선택된 Protocol Type에 따라 Default Virtual Host와 base_port가 다르게 생성된다.

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

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

4.5.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.5.4. Register

  1. Register 버튼 을 클릭한다.

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

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

4.5.5. 수정

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

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

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

4.5.6. 삭제

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

  2. Save 버튼 을 클릭한다.

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

    • Deregister : 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.5.7. Start/Stop

Single Start/Stop

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

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

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

Multi Server Start/Stop

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

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

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

Forced Stop/Restart

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

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

4.5.8. 설정 정보 관리

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

General

WebN 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 (/var/common_value.env 파일 관리)

server 5 general serverInfo
Table 53. Server Info
항목(*는 필수값)설명비고

Install Path

Server 설치 경로

Base Port(*)

설치할때 설정한 Port Type 정보와 Port Number

Port Type은 변경 불가능, Port Number는 변경 가능

Welcome Page

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

Stop Mode

Server 중지 Mode

  • Stop

  • Graceful Stop

Directory Root Path

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

Disable Symbolic Links

Symbolic Link 미사용 여부

Default : on (사용 안함)

Diasble Auto Index

디렉터리 목록 출력을 활성화하거나 비활성화합니다.

Default : on (비활성화)

  1. Port Info (/var/tcp_port.env, /var/udp_port.env 파일 관리)

server 5 general portInfo
Table 54. TCP Port
항목(*는 필수값)설명비고

Port Alias(*)

포트의 Alias 를 설정한다.

Port Number

포트 번호를 지정한다.

Protocol Type

프로토콜 타입을 선택한다.

Virtual Host ID

해당 Port를 사용중인 Virtual Host ID를 표시한다.

특정 Virtual Host에서 해당 Port를 사용중이라면, Port Alias를 변경 할 수 없다.

TCP Protocol 전용 사용 포트 (Proxy(HTTP, HTTPS), Net Gateway(TCP))

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

Port Alias(*)

포트의 Alias 를 설정한다.

Port Number

포트 번호를 지정한다.

Protocol Type

프로토콜 타입을 선택한다.

Virtual Host ID

해당 Port를 사용중인 Virtual Host ID를 표시한다.

특정 Virtual Host에서 해당 Port를 사용중이라면, Port Alias를 변경 할 수 없다.

UDP Protocol 전용 사용 포트 (Net Gateway)

  1. Connection Info (/var/common_value.env 파일 관리 - 연관 파일 /conf/http/lenan-http.conf)

server 5 general connectionInfo
Table 56. Connection Info
항목(*는 필수값)설명비고

Send Timeout(*)

client로 응답을 전송하는데 설정된 timeout 시간이다. 전체 응답 전송 timeout 시간이 아니라 두개의 연속적인 쓰기 작업 사이의 timeout 시간이다. send_timeout에 지정한 시간안에 client가 아무것도 받지 못하면 connection은 닫힌다.

Default : 60

Keep Alive Timeout(s) (*)

서버와 커넥션이 계속 열린채로 유지하는데 설정한 timeout 시간이다.

Default : 5

Client Header Timeout(*)

request header 정보를 읽는 시간, 지정한 시간 안에 client가 헤더를 전송하지 않으면 요청은 408(Request Time-out)로 끝난다.

Default: 60

Client Body Timeout(*)

request body 정보를 읽는 시간, request body 전체 전송 timeout 시간이 아니라, 두개의 연속적인 읽기 작업 사이의 timeout 시간이다. client_body_timeout에 지정한 시간 안에 client가 아무것도 전송하지 않으면 요청은 408(Request Time-out)로 끝난다.

Default: 60

  1. Process Info (/var/common_value.env 파일 관리 - 연관 파일 /conf/lenan.conf)

server 5 general processInfo
Table 57. Process Info
항목(*는 필수값)설명비고

Worker Process(*)

worker 프로세스 수를 정의 합니다.

Default : 2

Worker Connection(*)

최대 동시 연결 수를 설정합니다.

최대 Request 허용 갯수 : worker_processes * worker_connections

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

Connector

Web Server와 WAS(Backend)를 연계하기 위한 정보를 관리한다.
Connector 페이지는 프토토콜에 따라 Proxy와 Net Gateway 탭으로 나누어져 있으며, 각 탭에서 모듈에 따른 Connector 설정 정보를 편집할 수 있다.

Proxy

Proxy(ngx_http_upstream_module)를 사용할 때의 설정 정보를 편집한다.

server 5 web server proxy

Proxy 탭의 설정은 위 화면과 같이 Connector Info, Load Balancer, URI Pattern Group의 세 가지 영역으로 나누어져 있다.

  1. Connector Info
    Proxy의 기본 설정 값을 관리한다.

server 5 web server proxy connector info
Table 58. Connector Info (Proxy)
항목(*는 필수값)설명비고

Proxy Read Timeout(*)

백엔드 서버로 부터 응답을 읽는데 설정한 timeout 시간이다. 전체 응답 전송 timeout 시간이 아니라 두 개의 연속적인 읽기 작업 사이의 timeout 시간이다. proxy_read_timeout에 지정한 시간 안에 백엔드 서버가 아무것도 전송하지 않으면 connection은 닫힌다.

Default: 300

Proxy Connect Timeout(*)

백엔드 서버와의 연결을 설정하기 위한 시간 제한을 정의합니다. 이 시간 제한은 일반적으로 75초를 초과할 수 없습니다.

Default: 5

Background ServerFault Check Interval(*)

백엔드 서버와 연결된 Member가 오류 상태인 경우, 본 항목에 설정한 간격(초)으로 서버를 확인하고 서버가 정상 동작 하면 요청을 다시 전달한다. 기능을 사용하지 않으려면 0으로 설정한다.

Default: 10

Server Fault Retry Time(*)

백엔드 서버와 연결된 Member가 오류 상태인 경우, timeout(초)이 만료될 때 까지 어떠한 요청도 해당 서버에 전달하지 않는다.

Default: 60

Health Check Interval(*)

백엔드 서버의 상태를 확인하기 위해 설정된 간격(초)으로 서버를 확인한다. 기능을 사용하지 않으려면 0으로 설정한다.

Default: 60

Background ServerFault Check Interval과 Health Check Interval을 0으로 저장 시
모든 LoadBalancer의 Auto Server Fault Recovery값이 off로 변경되며, 신규생성 값도 off로 고정된다.

  1. Load Balancer
    부하 분산을 위해 Load Balancer의 기본 설정 및 Member를 관리한다.
    Load Balancer 영역에는 Overview 탭과 Configuration 탭이 존재하며, Overview 탭에서는 현재 생성되어 있는 Load Balancer의 전반적인 정보를 확인할 수 있고 Configuration 탭에서는 Load Balancer의 상세 내용을 구성할 수 있다.

server 5 web server proxy lb overview
Table 59. Load Balancer Info - Overview (Proxy)
항목(*는 필수값)설명비고

Load Balancer ID

현재 생성되어 있는 Load Balancer의 ID이다.

Target Server

Load Balancer에 등록된 Worker의 기본 정보이다.
'Node Name/Server Name' 형식으로 출력된다.

Pattern

특정 URI Pattern에서 Load Balancer를 지정한 경우, 해당 URI Pattern이 속해있는 URI Pattern Group ID가 출력된다.

server 5 web server proxy lb config
Table 60. Load Balancer Info - Configuration (Proxy)
항목(*는 필수값)설명비고

Load Balancer ID(*)

Load Balancer의 이름이다.

'lb_'라는 접두사가 추가된다.

Method(*)

Load Balancer가 부하를 분산하기 적절한 Worker를 판별하는데 사용하는 방법을 지정한다.

  • Sticky Session : Session Cookie를 기반으로 라우팅

  • RoundRobin : 등록된 멤버의 순서대로 라우팅

  • IP Hash : Client의 IP를 기반으로 라우팅

  • Least Connection : 커넥션이 적은 쪽으로 라우팅

Session Cookie(*)

Session Cookie 이름을 변경하고자 하는 경우 설정한다.

Default: JSESSIONID

Timeout Retry

Session Cookie 이름을 변경하고자 하는 경우 설정한다.

Default:Off
On 셋팅 시 Gateway Timeout 발생 시 재 전송한다.

Auto Server Fault Recovery

fox Directive 사용여부

Default: On
Off 셋팅 시 Fail Check 관련하여 Health Check Interval값 대신 ServerFault Retry Time 값이 적용된다.

Member는 Load Balancer MemberList 테이블의 Add Member 버튼으로 추가한다.
Add Member버튼을 눌렀을 때 Member를 추가할 수 있는 창이 화면에 출력 되며, 사용자는 이 창에서 LENA Manager에서 관리하는 서버를 Member를 선택할 수 있다. 추가된 Member는 아래와 같은 정보를 통해 관리된다.

Table 61. Load Balancer Member List
항목(*는 필수값)설명비고

Target Server

Member가 가리키는 서버의 노드 이름과 서버의 이름이다.

Route ID

Member의 Route ID 이다

Weight

작업량 할당 비율으로, 해당 Worker가 다른 Worker들에 비해 얼마나 많은 일을 할 지 정의한다.

Default: 1

  1. URI Pattern Group
    Web Server로 들어온 요청들에 대해 URI 패턴을 검사하여 WAS로 전달하는 URI Mapping을 정의한다.

server 5 web server proxy uri pattern group
Table 62. URI Pattern Group (Proxy)
항목(*는 필수값)설명비고

URI Pattern Group ID(*)

URI 패턴을 그룹화하고 관리하는 데 사용되는 이름이다.
Virtual Host에서 사용하는 URI Pattern Group일 경우, ID 옆에 어느 Virtual Host에서 사용하고 있는 지에 대한 정보가 함께 출력된다.

Group 생성 시 'uri_'라는 접두사가 추가된다.

Mode

URI 패턴을 LENA Manager가 관리하는 형식으로 입력할 지, 사용자 임의로 입력할 지 지정한다. 본 항목에 따라 Patterns to be Included/Excluded 또는 URI Patterns로 입력하는 화면이 출력된다.
이미 저장된 패턴이 LENA Manager가 관리하는 방식이라면 Standard로, 사용자 임의 형식이라면 Manual로 자동 지정된다.

  • Standard: LENA Manager URI Rule에 따른 입력 방식

  • Manual: 사용자 임의 입력 방식

Patterns to be Included

WAS로 전달 할 URI 패턴을 입력한다. 우측 Select box를 통해 Load Balancer를 선택해야 저장할 수 있다. ⓧ버튼을 통해 패턴을 삭제할 수 있다.

모든 문자를 허용하는 의미의 Asterisk(*)를 사용할 수 있으며 Hash(#), Equal(=)은 허용되지 않는다.

Patterns to be Excluded

WAS로 전달 하지 않을 URI 패턴을 입력한다. ⓧ버튼을 통해 패턴을 삭제할 수 있다.

모든 문자를 허용하는 의미의 Asterisk(*)를 사용할 수 있다.

URI Patterns

사용자 임의의 패턴을 입력할 시 사용한다.

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

Net Gateway

Net Gateway(ngx_stream_upstream_module)를 사용할 때의 설정 정보를 편집한다.

server 5 web server stream

Net Gateway 탭의 설정은 Connector Info, Load Balancer 두 가지 영역으로 나누어져 있다.

  1. Connector Info
    Net Gateway의 기본 설정 값을 관리한다.

server 5 web server stream connector info
Table 63. Connector Info (Net Gateway)
항목(*는 필수값)설명비고

Proxy Timeout(s)(*)

클라이언트 또는 프록시 서버 연결에서 두 번의 연속적인 읽기 또는 쓰기 작업 사이의 시간 제한을 설정합니다. 이 시간 내에 데이터가 전송되지 않으면 연결이 닫힙니다.

Default: 5

Proxy Connect Timeout(s)(*)

프록시 서버와의 연결을 설정하기 위한 시간 초과를 정의합니다

Default: 10

ServerFault Retry Time(s)(*)

지정된 수의 서버 통신 실패 횟수가 발생하여 서버를 사용할 수 없다고 간주해야 하는 시간, 서버를 사용할 수 없는 것으로 간주되는 기간입니다.

Default: 60

  1. Load Balancer
    부하 분산을 위해 Load Balancer의 기본 설정 및 Member를 관리한다.
    Load Balancer 영역에는 Overview 탭과 Configuration 탭이 존재하며, Overview 탭에서는 현재 생성되어 있는 Load Balancer의 전반적인 정보를 확인할 수 있고 Configuration 탭에서는 Load Balancer의 상세 내용을 구성할 수 있다.

server 5 web server stream lb overview
Table 64. Load Balancer Info - Overview (Net Gateway)
항목(*는 필수값)설명비고

Load Balancer ID

현재 생성되어 있는 Load Balancer의 ID이다.

Target Server

Load Balancer에 등록된 Member의 기본 정보이다.
'Address:Port' 형식으로 출력된다.

server 5 web server stream lb config
Table 65. Load Balancer Info - Configuration (Net Gateway)
항목(*는 필수값)설명비고

Load Balancer ID(*)

Load Balancer의 이름이다.

'lb_'라는 접두사가 추가된다.

Method(*)

Load Balancer가 부하를 분산하기 적절한 Member를 판별하는데 사용하는 방법을 지정한다.

  • Round Robin : 등록된 멤버 리스트를 순차적으로 라우팅

  • IP Hash : Client IP를 기준으로 라우팅

  • Least Connection : Connection을 기준으로 적은 쪽으로 라우팅

Member는 Load Balancer Member List 테이블의 Add Upstream 버튼으로 추가한다.
Add Upstream 버튼을 눌렀을 때 Upstream을 추가할 수 있는 창이 화면에 출력 되며, 사용자는 이 창에서 직접 Upstream정보를 입력하여 추가할 수 있다.

추가된 Upstream은 아래와 같은 정보를 통해 관리된다.

Table 66. Load Balancer Member List
항목(*는 필수값)설명비고

IP or DNS

Upstream이 가리키는 서버의 기본 정보이다. 기본적으로 Address:Port의 형태로 출력된다.

DNS도 입력 가능하다.

Port

Upstream가 사용하는 포트 정보이다.

Weight

작업량 할당 비율로, 해당 Upstream이 다른 Upstream들에 비해 얼마나 많은 일을 할 지 정의한다.

Default: 1
작업량 할당이기 때문에 0 입력 불가 (default 1로 변경)

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

Virtual Host
Proxy

Proxy 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를 체크한 경우 아래와 같이 상세 항목 영역이 추가로 출력된다.

server 5 web server proxy vhost

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

(/conf/http/vhost/vhost_{Virtual Host ID}.conf , /conf/http/vhost/vhost.list , /conf/http/rewrite/rewrite_{Virtual Host ID}.conf , /sslcert/ssl_https_{Virtual Host ID}.encrypted 파일 관리)

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

Virtual Host ID(*)

Virtual Host 이름

IP(*)

해당 가상호스트가 사용할 프로토콜을 선택(HTTP, HTTPS)
해당 가상호스트가 사용하는 IP

Port(*)

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

SSL Enable

SSL 추가 사용 여부, 해당 가상호스트가 사용하는 HTTPS Port

체크할 경우, HTTPS 서비스 포트로 사용할 포트를 콤보 박스에서 사용 필요(사용할 포트 정보는 General 탭의 Port Info에서 TCP 포트로 미리 등록 해야함)

Server Name

가상호스트 식별 하는 도메인 명

Document base/Directory Root Path

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

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

Document base/Disable Symbolic Links

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

Document base/Disable Auto Index

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

Document base/Allowed Methods

지정한 http method에 대한 액세스 허용

Document base/Deny IP

지정된 네트워크 또는 주소에 대한 액세스 거부

Access Log/Alias

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

Access Log/Location

로그파일을 어떤 위치에 어떤 이름으로 남길지 설정

URI

Connector Proxy Tab에서 설정한 URI Pattern Group 선택

필수 선택 아님

Enable Rewrite

Rewrite 기능을 사용할 것인지 여부, 체크 하면 하단에 입력 창 생성

입력되는 내용은 별도의 파일로 생성, 저장

SSL/SSLCertificateFile

SSL 인증서 경로

SSL/SSLCertificateKeyFile

SSL 인증서 Key파일 경로

SSL/SSLPassword

SSL Password

password를 입력할 경우, 내부적으로 암호화를 통하여, 파일로 생성, 기동 시에 자동 참조

SSL/Use HTTPS Redirect

Http→Https Redirect 사용여부

Enable Custom

Custom Configuration 사용여부, 체크 하면 하단에 입력 창 생성

입력되는 내용은 별도의 파일로 생성, 저장

Net Gateway

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

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

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

server 5 web server stream vhost

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

(/conf/stream/vhost/vhost_{Virtual Host ID}.conf , /conf/stream/vhost/vhost.list 파일 관리)

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

Virtual Host ID(*)

Virtual Host 이름

IP(*)

해당 가상호스트가 사용할 프로토콜을 선택(HTTP, HTTPS)
해당 가상호스트가 사용하는 IP

Port(*)

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

Access Log/Alias

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

Access Log/Location

로그파일을 어떤 위치에 어떤 이름으로 남길지 설정

Load Balancer

Connector Net Gateway Tab에서 설정한 Load Balancer Group 선택

Logging

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

server 5 web server log

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

  1. Log Home

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

Log Home(*)

Log Home 경로

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

Retention Days(*)

로그 최대 보관 일수

Default : 0(무제한)

  1. Error Log

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

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

Location(file/pipe)(*)

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

Log Level(*)

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

  1. Log Format : Proxy

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

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

Alias(*)

사용할 로그포맷의 명칭

Format(*)

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

  1. Log Format : Net Gateway

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

Table 72. Log Format : Net Gateway
항목(*는 필수값)설명비고

Alias(*)

사용할 로그포맷의 명칭

Format(*)

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

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

Environment

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

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

  • Base Env ($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.6. Session Server

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

4.6.1. 목록

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

server 6 session server
Figure 7. Session Server List

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

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

Status

Session Server의 상태

아래와 같은 상태를 제공함

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

Name(*)

Session Server의 이름

Address

Session Server의 IP주소

Server ID

Server의 ID

Type

Session Server의 유형

  • Standalone

  • Embedded

Port

Service 포트번호

Start/Stop

Server의 시작 및 종료

+ 아이콘

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

- 아이콘

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

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

4.6.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.6.3. Register

  1. Register 버튼 을 클릭한다.

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

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

4.6.4. 수정

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

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

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

4.6.5. 삭제

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

  2. Save 버튼 을 클릭한다.

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

    • Deregister : 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.6.6. Start/Stop

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

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

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

4.6.7. 설정 정보 관리

General

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

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

  1. Configuration

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

Host(*)

Server의 Service Host(IP)

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(s)

Session server의 session expired time 설정.

standalone에서만 가능함.

  1. Connected WAS List

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

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

Server ID

WAS의 ID

Host

WAS가 설치된 Host명

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

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

Table 76. 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 유실 개수

Request Getfresh Secondary

Slave Server에서 GET_FRESH Request 요청 횟수

Resp Lost

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

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 77. Log Home
항목(*는 필수값)설명비고

Log Home(*)

Log Home 경로

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

Retention Days(*)

로그 최대 보관 일수

Default : 0(무제한)

Environment

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

  • Base Env ($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 78. Server Cluster 속성
항목설명비고

Select

삭제를 위한 체크박스

Server Cluster Name

Cluster 명

Servers

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

  1. WAS

  2. Web

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명을 입력한다.

    • WAS 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 목록에 조회된다.

  • Engine No.가 다른 WAS인스턴스를 하나의 Server Cluster로 구성할 수 없다.

  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 79. Server Cluster 상세 영역의 항목 및 버튼
항목 또는 버튼명기능

Server Cluster Name(*)

Server Cluster 명

WAS 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의 동기화 수행은 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 완료

WAS

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에서 기술한 내용과 동일하다. 따라서 기능에 대한 상세 설명은 본 장에서는 생략한다.

WAS 목록 관리

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

  • Clone

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

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

Post Processing Options

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

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

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

Node List

복제할 서버를 설치할 노드

Clone 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 81. Rolling Restart 팝업창 항목 설명
Node서버가 설치된 노드명

Server

서버명

Server Status

서버의 현재 기동상태

Stop Status

서버 정지 작업 상태

Start Status

서버 기동 작업 상태

Action

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

Interval

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

Elapsed time

재기동 처리 시간

Table 82. 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 83. 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를 동기화한다.

Web Server의 Sync 버튼을 클릭하면, Web Server 설정 동기화 및 Server Cluster 내에 포함되어 있는 모든 Web Server와 WAS를 Full Mesh 구조로 연동한다.
만일 Full Mesh 구조로의 변경 없이 설정만 동기화하려면, Web Server와 WAS 각각 Server Cluster를 구성하는 것을 권장한다.

Rolling Restart

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

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

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

Table 84. 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 생성을 위한 창이 출력되며 Save 버튼을 클릭하면 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을 적절한 시기에 삭제하는 것을 권장한다.

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 85. 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 86. 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 87. 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 88. Session Server 상태
항목설명비고

Status

Server 기동여부

Unknown 상태는 Node Agent를 통해 서버의 상태를 가져올 수 없는 경우에 표시됨

Server Name

Server 이름

Heap

Session Server에서 사용되는 Heap Memory 사용률

Session Count

Active 상태인 Session 비율

Mirror Server

Mirror Server의 정보 및 기동여부

붉은색은 정지상태, 초록색은 기동상태, 검은색은 시스템외부에 존재하는 서버를 의미

각 서버를 즉시 제어할 수 있는 기능을 다음과 같이 함께 제공된다.

Table 89. 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 90. Dump 화면 항목
항목설명비고

File Name

생성된 파일 이름

날짜를 포함한 문자열로 자동 생성된다

Size

생성된 파일의 사이즈

Status

Dump 수행 시점의 System 및 Server의 상태

Dump 생성 시점의 시스템의 CPU, Memory 정보 및 Web Application Server의 주요 리소스 사용량 정보도 Dump 생성 시 함께 생성한다.

View 버튼 을 클릭하여 생성된 Status 값을 확인할 수 있다

Table 91. 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 92. Thread List 항목
항목설명비고

Thread ID

고유 Thread ID

Name

Thread 이름

Stat

Thread 상태

총 세 가지의 상태가 존재함

  • RUNNABLE: 가용 Thread

  • WAITING: 다른Thread의 특정 Action 을 수행하기 위해 대기 중인 Thread

  • TIMED_WAITING: 명시된 대기시간이 있는 Thread

CPU

지정된 Thread에 대한 CPU 사용시간

Elapsed

Thread가 수행되는데 걸린 시간

Service Name

Thread가 수행한 서비스 이름

+ 버튼 을 눌러 다음과 같은 상세 정보를 확인할 수 있다.

Table 93. 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 94. 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 95. 모니터링 관련 기본 설정 항목
항목설명기본값

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 96. 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 97. System 상태 요약 정보 항목
항목설명비고

Normal

정상 System의 수

Slow

응답 시간이 오래 걸리는 System의 수

Heavy

Thread pool사용량이 많은 System의 수

Slow & Heavy

Slow하고 Heavy한 System의 수

Chart 하단의 슬라이드 바를 조작해 이전 상태 정보를 볼 수 있으며, 이전 10분 아이콘, 다음 10분 아이콘, 일시 정지 아이콘, 재생 아이콘, 현재 시간 이동 아이콘 을 클릭해 시간을 이동할 수 있다. Dashboard에 처음 진입하면 전체 시스템이 표시되며, Chart 내에서 표시되는 시스템이나 범례를 클릭해서 특정 시스템만 선택해 볼 수 있다. 다시 전체 시스템 전체를 보려면 우측 상단의 All System 아이콘 을 클릭한다.

시스템 아이콘 위에서 마우스 우클릭을 하면 다음과 같은 기능을 수행할 수 있다.

Table 98. 시스템 아이콘에서 우클릭 시 사용 가능한 기능
항목설명비고

Topology View

Topology View 화면으로 이동

Service Analysis

System Detail 팝업 창 표시

Monitoring

Monitoring Dashboard 화면으로 이동

Statistics

Statistics 화면으로 이동

시스템 우클릭 기능 중에 Service Analysis 클릭 시 표시되는 팝업 창은 다음과 같다. Web Server, WAS, Session Server의 현재 상태가 좌측에 표시된다. 우측에는 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 99. CLIENT 관련 데이터의 항목
항목설명비고

domain lookup time

브라우저가 서버와 접속하기 위한 domain lookup 시간

connection time

브라우저가 서버와 connection 을 맺는 시간

server response time

브라우저가 서버에 요청을 하고 응답을 받은 전체 시간

rendering time

브라우저의 화면 rendering 시간

total complete time

브라우저에서 처리되는 전체 시간

error resource(line)

스크립트 에러 발생 시, 에러가 발생한 라인

error content

스크립트 에러 발생 시, 발생한 에러 내용

Table 100. WEB 관련 데이터의 항목
항목설명비고

elapsed time

WEB에서 처리 수행 시간

WAS 관련 데이터의 항목

  • 기본 정보

Table 101. 기본정보
항목설명비고

objName

요청을 처리한 서버 명

endtime

요청 처리 완료 시간

elapsed

요청 처리 수행 시간

service

요청 서비스 명

ipaddr

호출한 아이피 정보

cpu

CPU 사용 시간

sqlCount

수행된 쿼리 수

sqlTime

쿼리 수행 시간

  • 프로파일 정보

Table 102. 프로파일 정보
항목설명비고

#

프로파일 단계 순서를 나타내는 인덱스

p#

내부 단계인 경우 자신이 속한 부모 인덱스

TIME

해당 단계가 시작된 시간

T-GAP

현재 단계의 시작 시간과 이전 단계의 시작 시간의 차이

CPU

CPU 사용 시간

CONTENTS

각 단계의 내용

CLIENT 와 WEB 관련 정보는 E2E 기능이 ON되어 있어야 수집된다. 부하량을 최소화 하기 위해 기본적으로 OFF되어 있다.

프로파일 정보는 WAS에서 프로파일 설정이 ON되어 있어야 수집된다. 부하량을 최소화 하기 위해 기본적으로 OFF되어 있다.

7.2.2. Analysis Summary

현재 검출된 진단 결과 건수, 오늘 발생한 전체 진단 결과 건수, 지난 날(Default: 1일 전) 발생한 진단 결과 건수의 요약 정보를 보여준다.

Table 103. 분석 요약 정보 항목
항목설명비고

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 104. 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 105. 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 106. Out Of Memory 이벤트 상세 정보 항목(Event Detail Info)
항목설명비고

Heap Dump File Name

Out Of Memory Error 발생 시 자동 생성된 Heap Dump 파일 이름

Table 107. 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 108. 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 109. 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 > Analysis > Diagnostics Trend 메뉴에서 서버 별 연간 진단 결과를 차트를 통해 제공한다.

diagnostics statistics
Figure 29. Statistics 화면

위 화면에서 다음과 같은 내용을 확인할 수 있다.

  • Diagnostics Calendar

    • 한 칸이 하루를 의미하며, 연간 통계 차트의 일자에 Mouse Over를 하면 해당 일자에 발생한 진단 횟수를 확인할 수 있다.

  • Daily Diagnostics Detail

    • Diagnostics Calendar에서 특정 일자를 클릭하면, 화면 하단에 선택한 일자의 시간대 별 진단 발생 그래프가 표시 된다.

7.4.2. 리포트

진단 및 대응 기능이 수행되면 Report가 자동으로 생성된다. Report는 7일간 보관되며 오래된 Report는 자동으로 삭제된다.

진단/대응 리포트 목록

DAIGNOSTICS > Analysis > Diagnostics Trend 화면에서 특정 서버를 선택한 후, 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 110. 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 111. 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 112. 대량 DB Data 요청 진단 Report의 Back Data 항목
항목설명비고

Service Name

서비스 이름

Count

해당 서비스 요청 수

Blocked Count

Block된 DB 데이터 조회 건수

DB Conn Full 진단 Report의 Back Data는, 과다 점유된 DataSource Connection Pool 정보이다.

Table 113. DB Conn Full 진단 Report의 Back Data 항목
항목설명비고

DataSource Name

DataSource 이름

DB Connection Pool Usage Rate

DB Connection Pool 사용률

Long Transaction 진단 Report의 Back Data는, 진단 대상 서비스 중에서 가장 오래 걸린 5개의 서비스이다.

Table 114. 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 115. Peak Control 진단 Report의 Back Data 항목
항목설명비고

Service Name

서비스 이름

Requested Count

해당 서비스 요청 수

Avg. Elapsed Time

해당 서비스 평균 응답 시간

Max Elapsed Time

해당 서비스 중에서 가장 오래 수행된 서비스의 응답 시간

Min Elapsed Time

해당 서비스 중에서 가장 짧게 수행된 서비스의 응답 시간

OOM 진단 Report의 Back Data는, OOM 발생 여부 및 메모리 사용 정보이다.

Table 116. 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 117. 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.4.4. Thread Dump Analysis

LENA Manager를 통해 생성된 Thread Dump를 분석하여 사용자가 이해하기 쉽게 보여준다.

사전 준비 사항으로 Server 혹은 Service-Cluster 내 Thread Dump 파일이 필요하다.

Report 생성
diagnostics dump report
Figure 35. Thread Dump Analysis 초기 화면

LENA Manager의 상단 'DIAGNOSTICS' 메뉴를 선택하고 좌측 Analysis 내 Thread Dump Analysis를 클릭한다.

diagnostics dump modal
Figure 36. 분석할 Thread Dump를 선택해 Report를 생성하는 모달 창

Create Report 버튼을 눌러 모달 창을 확인한다.

diagnostics dump success
Figure 37. Thread Dump 파일을 분석해 Report 생성에 성공한 화면

System Name, Target Type, Target Name을 순서 대로 선택하고 Search 버튼을 눌러 해당 Thread Dump 파일 목록을 확인한다.
분석할 Thread Dump 파일을 선택하고 Analyze 버튼을 눌러 Report를 생성한다.
생성한 Report의 경로는 아래와 같다.

  • (LENA-Manager 설치 경로)/repository/monitoringDB/report

(분석을 위해 3~5개의 Thread Dump 파일을 선택해야 한다.)

Overview
diagnostics dump overview
Figure 38. 분석한 Report 파일을 보여주는 화면

  1. Thread Change Thrend
    Thread Dump 파일 별 Thread의 상태(State) 변화 추이를 그래프로 확인할 수 있고 구체적인 개수를 테이블로 확인할 수 있다.

  2. Unchanged Thread State
    분석한 모든 Thread Dump 파일 내 상태가 변하지 않는 Thread의 개수를 파악하고 'More' 버튼을 클릭해 자세한 정보를 확인할 수 있다.

diagnostics dump threadInfo
Figure 39. 각 상태 별 Thread의 정보
Dump Detail
diagnostics dump dumpDetail
Figure 40. 분석한 Dump 파일 별 Thread 정보를 보여주는 화면

  1. Thread Dump List
    분석한 Thread Dump 목록

  2. Summary
    해당 Thread Dump의 Thread 상태 분포도

  3. Thread Group
    Rule 파일에 정의한 workerThread로 그룹핑한 Thread의 개수

    • Rule 파일 경로 : (LENA-Manager 설치 경로)/repository/conf/diagnostics/basic-parser.json

  4. Thread State
    해당 Thread Dump의 Thread 상태 개수, 'More' 버튼을 클릭해 자세한 정보를 확인할 수 있다.

diagnostics dump dumpDetailInfo
Figure 41. 선택한 Thread Dump 파일 내 상태 별 Thread 정보

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 42. Diagnostics Rule Setting 화면

진단/대응 유형 별로 Tab으로 구성되어 있으며, 기본적인 Default Rule 이 제공된다. New 버튼 을 클릭해 신규 Rule을 생성하거나, 기존의 Rule을 선택해 수정 및 삭제를 할 수 있다.

각 진단 항목별로 다음과 같이 두 개의 Default Rule이 제공된다.

  • 진단 후 Report만 생성하는 Rule

  • 진단 후 Report 및 Dump를 생성하는 Rule(Action은 Disable되어 제공됨)

진단 유형 별 Rule 설정 항목을 다음과 같다.

Table 118. 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 119. 대량 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 120. 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 121. 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 122. 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 123. 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 124. 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 43. 진단 Rule Mapping 화면

진단/대응 Rule이 Mapping된 이후에는 다음과 같이 Server Rule Setting 화면에서 Rule을 Enable/Disable 할 수 있다.

diagnostics current status server rule setting
Figure 44. 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 ID Search

Session 의 Trace 정보(어느 Server에 해당 Session이 존재하는지)를 확인할 수 있다. Session을 찾기 위해서는 Cluster된 Session Server가 기동중이어야 한다.

diagnostics session trace
Figure 45. Session Trace 화면

조회 결과 항목은 다음과 같다.

Table 125. 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 46. Event Trace 화면

Trace 정보는 일주일 동안만 보관된다. 이벤트가 발생한 날짜는 검색 조건의 Trace Date에 표시 된다. 검색 결과에서 Status 항목은 발생한 이벤트의 중요도를 의미한다.

Table 126. Event Trace 검색 결과 항목
항목설명비고

Trace Time

이벤트가 발생한 Request의 처리 종료 시각

Web Server의 종료 시각

UID

Request를 호출한 User ID. 한 User가 각각 다른 브라우저를 사용 할 경우 UID는 다르게 처리 됨.

WEB

Request를 처리한 Web Server

 

WAS

Request를 처리한 WAS

 

Event

발생한 Event

 

SESSION ID

해당 Request의 Session ID

 

Detail

상세정보를 확인할 수 있는 버튼

검색 결과의 Detail의 상세 조회 버튼 을 누르면 상세 정보를 확인할 수 있다. 각 항목은 다음과 같다.

Table 127. Event Trace 정보의 상세 정보 항목
항목설명비고

Trace Time

이벤트가 발생한 Request의 처리 종료 시각

Web Server의 종료 시각

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 128. 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 47. Trace Setting 화면

Trace 설정 항목은 아래와 같다.

Table 129. 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로 기록

7.7. TunA APM

TunA APM은 LENA와 TunA APM Tool을 쉽게 연동하여 사용자 애플리케이션의 성능을 편리하게 모니터링 할 수 있는 기능이다. LENA 1.3.2 버전을 기준으로 Linux/Unix OS 및 VM 설치 버전에서 사용할 수 있다.

DIAGNOSTICS > TunA APM 메뉴의 하위 메뉴를 통해 연동 및 환경 구성을 할 수 있다. TunA APM 메뉴의 구성은 아래와 같다.

  • Connection Management

  • Module Management

  • Install Management

  • Host Management

7.7.1. Connection Management

TunA 수집 서버 및 Web Server의 IP Address와 Port 정보를 관리한다.
유저가 입력한 IP Address와 Port 정보를 바탕으로, TunA 수집 서버에 연결이 가능한지 확인하는 테스트를 수행한다.

TunA 연결 정보 입력
diagnostics tuna connection 1
Figure 48. TunA 연결 정보 입력 화면
#항목설명

①

TunA Address

TunA 수집 서버의 IP Address를 입력한다.

②

TCP Port

TunA 수집 서버의 TCP Port를 입력한다.

③

TunA Web Address

TunA Web Server IP Address를 입력한다.

④

HTTP Port

TunA Web Server HTTP Port를 입력한다.

⑤

Save 버튼

유저가 입력한 ① ~ ④ 항목들에 대한 연결 테스트를 수행하고 정보를 LENA Manager에 저장한다.

TunA 연결이 성공적으로 완료되면 Save 버튼 대신 화면에 출력되며, 각 버튼을 통해 앞서 입력했던 TunA 연결 정보를 수정 및 삭제할 수 있다.

image
Figure 49. TunA 연결 정보 입력 후 Action 컬럼
#항목설명

①

Edit 버튼

TunA 연결 정보를 수정한다.

②

Delete 버튼

TunA 연결 정보를 삭제한다.

TunA 사용자 정보 입력
diagnostics tuna connection 2
Figure 50. TunA 사용자 정보 입력 화면
#항목설명

①

User ID

TunA에 생성할 계정을 입력한다. 입력한 계정에 Prefix로 'LENA_'가 붙는다.

  • 계정 이름 규칙 : 계정 이름은 영문자, 숫자, Dash(-), Underscore(_)를 이용하여 구성할 수 있다.

②

Check 버튼

입력된 계정이 올바른지, 이미 TunA에 등록된 계정인지 검증한다.
새로 TunA에 등록된 계정이면 User Type 컬럼에 Owner가, 이미 TunA에 등록된 계정이면 Guest가 출력된다.
이 검증을 마친 후에 System Group을 입력 또는 지정할 수 있다. System Group은 TunA v2.6.0부터 사용되는 개념으로, 모니터링 대상을 그룹으로 관리하기 위해 사용한다. System Group은 모니터링의 기본 단위이다.

diagnostics tuna connection 2 1
Figure 51. 신규 사용자의 TunA 시스템 그룹 입력 화면
#항목설명

①

User ID

사용자 정보에서 입력했던 ID이다.

②

User Type

유저의 타입은 Owner, Guest로 나누어지는데, 신규 사용자는 Owner로 출력된다. Owner 타입의 유저는 System Group을 목록을 생성, 삭제 그리고 변경할 수 있는 권한이 주어진다.

③

Default

기본으로 사용 할 System Group을 설정한다. 이곳에서 설정된 System Group은 Agent 설치 시 기본 System Group으로 설정된다.

④

Name

사용하고 싶은 System Group 이름을 기입한다.

  • System Group 이름 규칙 : System Group 이름은 영문자, 숫자, Dash(-), Underscore(_)를 이용하여 구성할 수 있다.

⑤

Add System Group

System Group을 추가한다.

⑥

Save

지정한 System Group 및 Default System Group 정보를 저장한다.

⑦

Cancel

현재의 저장되지 않은 정보를 취소하고 이전의 상태로 돌아간다.

diagnostics tuna connection 2 2
Figure 52. 기존 사용자의 TunA 시스템 그룹 입력 화면
#항목설명

①

User ID

사용자 정보에서 입력했던 ID이다.

②

User Type

유저의 타입은 Owner, Guest로 나누어지는데, 기 등록된 사용자는 Guest로 출력된다. Guest 타입의 유저는 Owner 타입의 유저와는 다르게 System Group을 목록을 생성, 삭제 그리고 변경할 수 있는 권한이 주어지지 않으며 Default System Group만 선택할 권한을 가진다.

③

Default

기본으로 사용 할 System Group을 설정한다. 이곳에서 설정된 System Group은 Agent 설치 시 기본 System Group으로 설정된다.

④

Name

기존에 등록되어 있는 유저와 연결된 System Group이다.

⑤

Save

지정한 Default System Group 정보를 저장한다.

⑥

Cancel

현재의 저장되지 않은 정보를 취소하고 이전의 상태로 돌아간다.

TunA 연결 확인
diagnostics tuna connection 3
Figure 53. Open TunA 버튼이 활성화 된 모습

TunA Connection Information과 TunA User Information을 통해 필요한 정보가 모두 입력되면 위 첨부된 화면과 같이 TunA와 연결되는 버튼을 사용할 수 있다.
버튼을 누르면 TunA 화면이 새 창으로 브라우저에 출력된다.

7.7.2. Module Management

TunA Agent 파일을 LENA Manager에 업로드하고 TunA Agent에 대한 환경 설정을 관리한다.
TunA 에서 제공되는 Agent 파일은 TunA Host Agent와 TunA Java Agent로 구성되어 있으며 각각 tar 압축 파일 형태로 제공되고 있다.

diagnostics tuna module 1
Figure 54. Agent Module Upload 버튼
#항목설명

①

Host Agent Upload 버튼

TunA Host Agent 파일을 업로드하기 위한 Upload File 다이얼로그를 연다. 파일을 다시 업로드 할 경우 기존에 업로드 되었던 파일을 덮어쓴다.

②

Java Agent Upload 버튼

TunA Java Agent 파일을 업로드하기 위한 Upload File 다이얼로그를 연다. 파일을 다시 업로드 할 경우 기존에 업로드 되었던 파일을 덮어쓴다.

diagnostics tuna module 2
Figure 55. Agent Module Upload 후의 화면
#항목설명

①

Last Updated

Agent 파일을 업로드한 시각이 표시된다.

②

Use Additional Config

각 Agent에 공통으로 지정할 설정 항목이 있다면 체크한다. 체크박스에 체크하면 본 항목 하단에 Additional Config 항목이 출력되며, 체크박스를 해제하면 Additional Config 항목이 출력되지 않는다.

③

Additional Config

Use Additional Config에 체크하면 활성화되는 텍스트박스로, 각 Agent에 공통으로 지정할 설정 항목을 작성한다. Install Management 단계에서 Agent 설치 시 본 텍스트박스에 작성된 내용이 환경 설정 파일에 포함되어 설치된다.

7.7.3. Install Management

TunA Host Agent와 TunA Java Agent를 설치할 대상 서버를 관리하고 Agent 파일을 서버에 Install한다.

diagnostics tuna install 1
Figure 56. Install Management 화면
#항목설명

①

Host List

TunA Host Agent 설치를 관리하는 목록이다. Host Agent를 설치 할 수 있는 목록과 Host Agent가 설치된 목록이 출력된다.

②

Add Host 버튼

Host List로 관리 될 목록을 조회 및 지정하기 위한 다이얼로그를 연다.

③

WAS List

TunA Java Agent 설치를 관리하는 목록이다. Java Agent를 설치 할 수 있는 목록과 Java Agent가 설치된 목록이 출력된다.

④

Add WAS 버튼

WAS List로 관리 될 목록을 조회 및 지정하기 위한 다이얼로그를 연다.

Install Management에서는 TunA Agent를 설치할 Host 또는 WAS를 먼저 선택하고 목록(Host List, WAS List)에 추가한다.

Host List의 추가 / 삭제 / 변경

TunA Host Agent는 Host 당 하나의 Agent를 설치할 수 있다. 따라서 Multi-node인 환경의 경우에는 특정 Node 하나를 선택하여 설치한다.
설치를 위해 Host List에 Host를 추가한다. Host List Table 하단의 Add Host 버튼을 클릭하여 진행한다.

diagnostics tuna install 1 dialog 1
Figure 57. Host 추가 다이얼로그 화면
#항목설명

①

Avaliable host list for TunA

Host Agent를 설치할 수 있는 Host 목록을 의미한다.
LENA Manager에 등록 또는 설치된 Node를 포함하는 Host만 확인 할 수 있다.

②

Action Checkbox

Host를 선택하기 위한 체크박스이다.

③

Node Selectbox

추가 / 삭제 / 변경 작업을 수행할 Node를 선택한다.

④

Action Status

Node Selectbox로 선택한 Node에서 어떤 기능이 수행될 지 표시된다. 표시되는 기능은 아래와 같다.

  • Add: Host의 Node를 지정하고 Host List에 추가한다.

  • Modify: 지정했던 Node를 다른 Node로 변경한다.

  • Remove: 해당 Node를 목록에서 삭제한다.

⑤

Save 버튼

선택 된 Node에 대해 지정한 Action을 수행한다.

WAS List의 추가 / 삭제

TunA Java Agent는 WAS 당 하나의 Agent를 설치할 수 있다. 설치를 위해 WAS List에 WAS를 추가한다. 이 작업은 WAS List 테이블 하단의 Add WAS 버튼을 눌러 진행한다.

diagnostics tuna install 1 dialog 2
Figure 58. WAS 추가 다이얼로그 화면
#항목설명

①

Available WAS list for TunA

WAS Agent를 설치할 수 있는 WAS 목록을 의미한다.
LENA Manager에 등록 또는 설치된 WAS만 확인 할 수 있다.

②

Action Checkbox

WAS를 선택하기 위한 체크박스이다.

③

Action Status

선택한 WAS에서 어떤 기능이 수행될 지 표시된다. 표시되는 기능은 아래와 같다.

  • Add: WAS를 WAS List에 추가한다.

  • Remove: 해당 WAS를 목록에서 지운다.

④

Save 버튼

선택 된 WAS에 대해 지정한 Action을 수행한다.

Agent 설치

TunA Agent를 설치하기 위해서는 아래 첨부된 화면과 같이 Host List, WAS List에 Agent가 설치 될 대상이 추가되어있어야 한다.

diagnostics tuna install 2
Figure 59. Host와 WAS가 설치 대상 목록에 추가된 Install Management 화면
#항목설명

①

Host List

TunA Host Agent 설치를 관리하는 목록이다. Host Agent를 설치 할 수 있는 목록과 Host Agent가 설치된 목록이 출력된다.

②

Install 버튼

Host에 TunA Host Agent를 설치한다. 설치가 정상적으로 완료되면 Agent가 설치된 시각이 출력된다.

③

WAS List

TunA Java Agent 설치를 관리하는 목록이다. Java Agent를 설치 할 수 있는 목록과 Java Agent가 설치된 목록이 출력된다.

④

Install 버튼

WAS에 TunA Java Agent를 설치한다. 설치가 정상적으로 완료되면 Agent가 설치된 시각이 출력된다.

7.7.4. Host Management

Install Management에서 설치 작업을 수행한 TunA Host Agent의 제어 및 개별 환경 설정 관리는 Host Management 에서 수행한다.

diagnostics tuna host 1
Figure 60. Host Management 화면
#항목설명

①

Host List

TunA Host Agent가 설치된 Host 목록을 출력한다.

②

Host Action 버튼

TunA Host Agent의 상태를 확인하고 제어를 수행하기 위한 다이얼로그를 연다.

③

Host Agent Status

TunA Host Agent의 상태를 표시한다. 표시될 수 있는 상태는 다음과 같다.

  • Started: TunA Host Agent가 기동된 상태이다.

  • Stopped: TunA Host Agent가 기동 중지상태이다.

④

Action 버튼

TunA Host Agent를 기동, 중지하거나 삭제한다. 삭제는 TunA Host Agent가 중지 상태일 때만 활성화된다.

⑤

System Group

Host Agent가 속할 System Group을 선택한다.

⑥

Configuration

Host Agent의 설정을 수정한다.

⑦

Save 버튼

수정된 Host Agent의 설정을 저장한다.

7.7.5. WAS에서의 TunA 설정

Install Management에서 설치 작업을 수행한 TunA Java Agent의 제어 및 개별 환경 설정 관리는 WAS 설정 관리 화면의 TunA 탭에서 수행한다.

diagnostics tuna was 1
Figure 61. WAS - TunA Tab 화면
#항목설명

①

TunA Tab

TunA Tab 화면에서는 TunA Java Agent를 관리한다. TunA Tab을 눌렀을 때 유저가 등록되지 않았거나 WAS에 TunA Java Agent가 설치되지 않으면 유저 등록 및 Agent 설치 요청 문구가 화면에 출력된다.

②

Enable TunA Checkbox

TunA Java Agent의 사용 여부를 체크한다. WAS 기동 시에 본 항목을 반영한다.

③

System Group

Java Agent가 속할 System Group을 선택한다.

④

Java Agent Config

TunA Java Agent의 설정을 확인하고 수정하는 기능을 제공한다.

⑤

Delete 버튼

TunA Java Agent를 삭제한다. WAS가 중지 상태일 때에만 활성화된다.

⑥

Save 버튼

TunA Java Agent 설정을 저장한다.

8. Topology

각 시스템의 구성현황을 한눈에 알아볼 수 있으며, 설치 및 설정기능을 제공하고, 자원 모니터링 및 기동/중지 제어를 할 수 있다.

topology overview
Figure 62. 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 Server, 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 63. Topolopgy Control [Edit: OFF]
CLIENT 영역

Client는 사용자를 말하며, 사용자가 Web Server에 요청을 주고 받는 브라우저 화면 Rendering 시간 및 Script error 내용을 확인 할 수 있다.

WEB 영역

WEB 영역에서는 설치된 Web Node 와 Web Server 정보를 제공하고 서버의 제어 할 수있다.

  • 구성정보

    Web Node는 Web Server가 설치되는 영역으로 노드 별 서버 설치 현황을 확인 할 수 있다.

  • 모니터링 정보

    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 Server(적시서버)를 구성한 후 오류가 발생된 서비스를 요청 받은 Web Server들이 적시서버로 서비스를 포워딩하여 서비스가 정상적으로 제공되게 하는 방식이다.

      이 기능을 사용하려면 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. Dump : 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 64. 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 65. Users 화면

사용자 관리의 속성은 아래와 같다.

Table 130. 사용자 관리 속성
항목(*는 필수값)설명비고

Use ID(*)

사용자 식별자

User Name(*)

사용자 이름

Password(*)

사용자 비밀번호

비밀번호는 특수문자, 숫자, 영문자 혼합의 최소 8자 이상이어야 한다

Change User ID

사용자 데이터 수정 및 생성자

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 66. Auths 화면

권한 관리의 속성은 아래와 같다.

Table 131. 권한 관리 속성
항목(*는 필수값)설명비고

Auth ID(*)

권한 식별자

Auth Name(*)

권한 이름

Description

등록된 권한에 대한 설명

Change User ID

권한 데이터 수정 및 생성자

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 67. User-Auth Mapping 화면

사용자 권한 관리의 속성은 아래와 같다.

Table 132. 사용자 권한 관리의 속성
항목설명비고

권한 명 선택

"권한 관리" 화면을 통해 등록한 권한 리스트로 구성된 콤보박스

ID

사용자 식별자

Name

사용자 이름

사용자 권한 맵핑

  1. 사용자를 배속시킬 권한을 선택한다.

    • 권한 선택 시 선택 가능 사용자와 선택된 사용자가 화면에 출력된다.

  2. 선택 가능 사용자를 선택한다.

  3. 사용자를 배속 시키거나 제외 시킨다.

    • 단일 우측 셔플 버튼 을 클릭하여 선택한 사용자를 배속시킨다.

    • 전체 우측 셔플 버튼 을 클릭하여 모든 사용자를 배속시킨다.

    • 단일 좌측 셔플 버튼 을 클릭하여 선택한 사용자를 제외시킨다.

    • 전체 좌측 셔플 버튼 을 클릭하여 모든 사용자를 제외시킨다.

  4. Save 버튼 을 클릭하여 사용자 권한 관리 정보를 저장한다.

9.1.4. Menu-Auth Mapping (메뉴 권한 관리)

LENA Manager에서 생성한 권한 별로 접근 가능한 메뉴를 설정할 수 있다. 권한 선택을 통해 생성한 권한 중 메뉴를 설정할 하나의 권한을 선택한다. LENA Manager에 등록된 모든 메뉴를 보여주는 메뉴 목록 중 접근 제어를 설정할 메뉴를 선택하고 메뉴권한을 설정한다.

메뉴 권한 조회
admin menu auth mapping
Figure 68. Menu-Auth Mapping 화면

메뉴 권한 관리의 속성은 아래와 같다.

Table 133. 메뉴 권한 관리의 속성
항목설명비고

권한 명 선택

"권한관리" 화면을 통해 등록한 권한 리스트로 구성된 콤보박스

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 69. License의 목록 화면

9.2.2. License 상세

License의 목록을 클릭하면 License의 상세 정보를 확인할 수 있다.

상세 정보 항목은 아래와 같다.

Table 134. License의 상세 정보 항목
항목설명비고

Node Name

Node 명

Type

라이선스 구분

Trial, Standard

Customer Name

구매 고객사 명

System Name

설치된 시스템 명

Issue No

라이선스 발행번호

Issue Date

라이선스 발행일자

License Term

라이선스 허용 기간

Lena Home

Lena Home 경로

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 70. 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
  Manager Address : 127.0.0.1:7700
  CPU Core : 4
  HyperThreading : DISABLED
  Current Date : 20180705

[License Information]
  License Status : true [License is valid.]
  Node Type : lena-enterprise
  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
  MANAGER_ADDRESS : UNLIMITED
  WEB_CONTRACT_CPUCOREDAY_LIMIT :
  WEB_CPUCOREDAY_LIMIT : N
  WAS_CONTRACT_CPUCOREDAY_LIMIT :
  WAS_CPUCOREDAY_LIMIT : N
  RE_ISSUEANCE :
  USE_POSTPAID :
  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_OPTS에 추가)
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. Security (서비스 제어)

Application Server에 IP또는 URL기반으로 사용자 요청을 제한하는 기능이다.

9.3.1. Rule Setting (Rule 설정)

특정 IP나 URL에서 요청을 제어하고 싶은 경우 화면을 통해 신규 Rule을 설정한다. 신규 Rule 설정 및 Rule 삭제의 편의성을 제공하기 위해 검색기능을 제공한다. 전체 Application에 적용되는 Server속성은 에러페이지로 처리할 수 있다

admin service control rule setting
Figure 71. Rule Setting 화면

Rule 목록의 Use 컬럼은 해당 Rule이 Application Server에 적용되어 있는지 여부를 나타낸다.

Rule 추가 시 설정 가능한 속성은 아래와 같다.

Table 135. 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.3.2. Rule Applying (Rule 적용)

추가된 Rule 중 하나를 선택하여 Application Server에 적용한다. 적용 편의성을 위해 Rule유형, 적용단위, Rule명에 대한 검색기능을 제공한다.

Rule 목록에서 하나를 선택하여 Rule 적용에서 셔플 버튼 들을 이용하여 적용 대상을 선택하고, On/Off 버튼 을 클릭하여 적용 및 저장한다. 적용 대상에서 제외를 하고 싶을 경우에도 셔플 버튼 들을 이용하여 제외시킨다.

admin service control rule applying
Figure 72. Rule Applying 화면

Rule 현황 및 적용 화면에서 사용되는 속성들은 Rule설정 화면과 유사하며 아래의 속성들은 추가적인 속성들이다.

Table 136. 추가적인 속성
항목설명비고

Node Name

등록된 System 하위의 Node 명

Server Name

등록된 Node 하위의 Server 명

선택한 Rule에 신규 대상이 추가될 경우 적용 단위에 따라 server.xml 혹은 context.xml 에 추가되고, 적용된 대상에서 제외할 경우 위의 설정 파일에 추가된 Rule 설정이 삭제된다.

9.3.3. Service Control Log (Rule 적용결과 조회)

Rule이 적용된 항목들에 대한 처리 결과가 목록으로 출력된다. 처리 결과 확인의 편의성을 위해 Rule유형, 적용단위, Rule명, 로그시간에 대한 검색기능을 제공한다.

admin service control log
Figure 73. Service Control Log 화면

처리 목록에서 사용되는 속성들은 아래와 같다.

Table 137. 로그 정보의 항목
항목설명비고

Controlled Date

Rule설정이 적용된 요청의 처리시간

Address

처리된 원격지 주소

Request URL

처리된 요청의 URL

HTTP Method

처리된 요청의 HTTP Method

Rule Name

요청을 처리하는데 적용된 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.4. 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.4.1. Overview

패치파일의 업로드 기능을 제공하며, Manager와 각 Node별 Node Agent의 패치 반영상태 정보를 조회한다.

Patch 파일 업로드

Patch Info 영역에서는 매니저에 업로드 된 패치파일 중, 최상위 버전의 상세정보를 표시한다.

Table 138. 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 139. 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 140. History 항목
항목설명비고

Action

패치/복원 이력을 표시

Patch Version

패치/복원을 수행한 패치파일의 버전

Pervious Version

패치/복원을 적용하기 이전의 서버버전

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 141. 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 Ver.

Node의 현재 버전

Node Hotfix.

Node의 Hotfix 버전

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 142. 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.4.2. WAS

Node/Cluster에 포함된 Application Server에 대해서, 매니저에 업로드 된 최신 패치파일로 패치를 진행하며, 문제발생시 패치 적용 바로 전의 상태로 복원할 수 있는 기능을 제공한다.

목록

패치를 적용할 서버를 그룹별 조건(node단위, cluster 단위)으로 검색한다.

Table 143. 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

Address

Application Server가 설치된 Node의 IP

HTTP Port

Application Server의 HTTP Connector port

AJP Port

Application Server의 AJP Connector port

Start/Stop

Application Server의 기동 및 중지 실행

Current Version

Application Server의 현재 설치된 버전정보

Hotfix

Hotfix 버전 정보

Patch Version

패치를 적용할 버전정보. 최신패치가 적용 된 상태일 경우 ‘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 144. History 항목
항목설명비고

Action

패치/복원 이력을 표시

Patch Version

패치/복원을 수행한 패치파일의 버전

Previous Version

패치/복원을 적용하기 이전의 서버버전

Timestamp

패치/복원을 적용한 시간

Log/Handwork

상세(노트) 버튼 선택시 실행 결과 로그를 제공한다.

수작업(스페너) 버튼 선택시 Handwork(추가적으로 필요한 수작업) 내용을 제공한다. Handwork 작업 필요시 해당 버튼은 붉은색으로 표시된다.

9.4.3. Session Server

Session Server들에 대해서, 매니저에 업로드 된 최신 패치파일로 패치를 진행하며, 문제발생시 패치 적용 바로 전의 상태로 복원할 수 있는 기능을 제공한다.

목록

패치를 적용할 서버를 그룹별 조건(node단위)으로 검색한다.

Table 145. Session Server Patch Status 항목
항목설명비고

Patch Status

Session Server의 패치 적용 상태

  • 해 아이콘 : 최신패치가 적용된(up to date) 상태

  • 구름 아이콘 : 최신패치를 적용할 수 있는(patch available) 상태

Node

Session Server가 설치되어있는 Node명

Name

Session Server 이름

Type

Session 서버 타입

Address

Session Server의 주소

Port

Session Server의 port

Start/Stop

Session Server의 기동 및 중지 실행

Current Version

Session Server의 현재 설치된 버전정보

Hotfix

Hotfix 버전 정보

Patch Version

패치를 적용할 버전정보. 최신패치가 적용 된 상태일 경우 ‘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 146. History 항목
항목설명비고

Action

패치/복원 이력을 표시

Patch Version

패치/복원을 수행한 패치파일의 버전

Previous Version

패치/복원을 적용하기 이전의 서버버전

Timestamp

패치/복원을 적용한 시간

Log/Handwork

상세(노트) 버튼 선택시 실행 결과 로그를 제공한다.

수작업(스페너) 버튼 선택시 Handwork(추가적으로 필요한 수작업) 내용을 제공한다. Handwork 작업 필요시 해당 버튼은 붉은색으로 표시된다.

9.5. Preferences

9.5.1. Action Trace

Manager를 통해 각 사용자가 수행하는 추가/수정/삭제 작업의 수행 이력은 로그로 남는다. Action Trace에서는 이러한 수행이력을 조회/추적하는 기능을 제공한다.

admin action trace
Figure 74. Action Trace 화면
이력 조회

조회 조건을 입력 후 클릭하면 이력을 조회할 수 있다. 목록 중 하나를 선택하면 상세정보도 확인할 수 있다.

조회 화면에 표기되는 항목은 아래와 같다.

Table 147. 이력 상세 정보 항목
항목설명비고

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 148. Search ID 기능의 입출력 항목
항목설명비고

ID

  • 좌측 Combo : serverId / nodeId / serverClusterId 중 택일

  • 우측 : Input 에 있는 ID 값을 입력

입력항목

Data

검색된 Server/Node/Cluster 정보

출력항목

9.5.2. Documentation

LENA 소개자료와 매뉴얼을 다운로드 받을 수 있다.

9.5.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)

Table 149. 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 확인 불가 상태

  • use Server Delete Protection : Manager에서 서버 삭제 기능 사용금지 여부(default : false)

화면 우측의 설정 버튼 을 클릭하면 상세 정보를 확인 및 변경 할 수 있다.

Metadata Refresh

Topology 메뉴에서 시스템 별 구성정보를 topology 차트로 그리기 위해 사용되는 메타데이터의 정합성 검증 및 복원 기능을 수행한다.

Reset manager address of all registered nodes

Manager에 등록된 노드들에게 변경된 Manager Address를 일괄적으로 변경시켜주는 기능을 제공한다.

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}/repository/conf 폴더 하위에 manager.conf 파일을 열고, dbbackup.size=보관기간 을 입력 후 Manager를 재 기동하면 보관기간을 변경할 수 있다.

10.5. Manager 의 내부이력 삭제

Manager가 내부적으로 남기는 이력은 주기적으로 삭제하도록 스케쥴링이 되어 있다. 삭제하는 정보는 Action Trace 이력과 Server History 이력이다.

기본적으로 Action Trace이력은 30일까지만 보관하고, Server History 이력은 90일까지 보관하고 있다. 이 보관기간을 변경하고 싶은 경우 ${LENA_HOME}/repository/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/etc/patch/{패치버전}
Manager 패치파일 경우: /engn001/lena/1.3/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.1
 ===================================================================
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.1
 ===================================================================

patch is completed.!!
Server Patch

patch.sh를 실행하여 개별적인 서버를 패치한다.

node가 설치된 서버에서 실행하여야 하고, LENA 서버 설치 유형별로 별도로 실행한다. 서버 패치를 위해서는 노드패치가 선행되어야 한다.

WAS standard type 패치
<패치파일압축해제경로>/bin/patch.sh lena-se
Session Server 패치
<패치파일압축해제경로>/bin/patch.sh lena-session
Table 150. 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.1
 ===================================================================

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.1
- 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.1
- 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.1
- 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.1 (Up to date)
- LENA_HOME : /engn001/lena/1.3.1

2. lena-manager
2.1 - id : lena-manager / version : 1.3.1.1 (Up to date)

3. lena-se
3.1 - id : wasSE_9100 / version : 1.3.1.1 (Up to date)
3.2 - id : wasSE_9200 / version : 1.3.1.1 (Up to date)

4. lena-ee
4.1 - id : wasEE_9300 / version : 1.3.1.0 (Patch available to 1.3.1.1)
4.2 - id : wasEE_9400 / version : 1.3.1.0 (Patch available to 1.3.1.1)

5. lena-session
5.1 - id : session_5000 / version : 1.3.1.0 (Patch available to 1.3.1.1)
5.2 - id : session_5500 / version : 1.3.1.0 (Patch available to 1.3.1.1)

version is completed.!!

10.10. DBCP 부가 기능

Database 연결 테스트를 통해 Application Server 를 제어하거나, DBCP 에서 수행되는 작업들의 로그를 생성한다.

환경변수나 JVM Option 으로 설정하며, JVM Option 설정을 우선한다.
(동일한 옵션이 환경변수와 JVM Option 으로 모두 설정된 경우 JVM Option 값을 따름)

윈도우 서비스에 Application Server 를 등록하여 사용하는 경우 JVM Option 으로만 설정가능

10.10.1. Application Server 제어

Application Server 기동시 Database 에 접속 불가하거나, pool 생성, validation 쿼리 실패 등의 이상상태가 감지되면 서버를 종료한다.

Table 151. DBCP 부가기능, Application Server 제어
환경변수JVM Option설명Default

SHUTDOWN_IF_DBCONN_FAIL

lena.shutdownIfDbConnFail

true 일 경우 Database 연결 / Pool 생성 실패 / validation 쿼리 실패 상황에 서버 종료

false

10.10.2. DBCP 로깅

Datasource 생성, Connection 생성, Validation 쿼리 수행, Borrow Connection, Return Connection 에 대한 로깅 / 상세 Stack Trace 로깅

환경변수JVM Option설명Default

DBCPLOG_ON

lena.dbcplogOn

true 일 경우 Datasource 생성, Connection 생성시 로깅

false

DBCPLOG_ON_DETAIL

lena.dbcplogOnDetail

true 일 경우 Validation 쿼리 수행, Borrow Connection, Return Connection 로깅 (DBCPLOG_ON 이 false 이면 작동하지 않음)

false

DBCPLOG_ON_STACKTRACE

lena.dbcplogOnStacktrace

true 일 경우 로그에 Stack Trace 정보를 추가한다.

false

DBCPLOG_MAX_TRACE

lena.dbcplogMaxTrace

로그에 출력할 Stack Trace 최대 갯수

5

DBCPLOG_EXC_DBCP_PACKAGE

lena.dbcplogExcDbcpPackage

Stack Trace 에서 dbcp 관련 package 정보 로깅 제외 여부

true

10.11. Manager 언어 설정 변경

LENA Manager 의 언어 설정을 변경 할 수 있다.

Table 152. LENA Manager 설정 가능 언어
언어Default

영문(US)

O

한글(KR)

10.11.1. 언어 설정 변경 방법

언어설정 변경 기능을 켜기위해 먼저 다음 메뉴로 진입한다.

ADMIN > Preference > Manager Environment
(기본 영문 설정 기준)

Manager Configuration 의 톱니바퀴 버튼을 클릭하여 세부 설정을 열어 다음과 같이 수정한다.

...
 9  # i18n On/off
10  lena.i18n.enable=true # false -> true
...

이제 Login Page 에서 언어설정을 변경할 수 있다. 로그인한 상태라면 로그아웃 하여 Login 페이지로 이동한다.

image

사용할 언어를 선택 한 뒤 로그인하면 변경 된 언어로 LENA Manager를 사용할 수 있다.

image

10.12. Session Server 상세

Application Server의 Session Clustering은 별도의 Session Server를 설치하여 Session을 공유해 Clustering 한다. Session Server는 별도 VM위에서 작동하는 Standalone 모드와 Application Server에 Session Server 모듈을 탑재한 Embedded 모드가 있다.

10.12.1. Session Server Standalone 모드

image
설치

설치방법은 Install 항목을 참조한다.

기동/중지 및 기동여부 확인

기동/중지 및 기동여부 확인은 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]$ ./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.12.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

화면에 표시되는 항목에 대한 설명은 아래와 같다.

항목설명비고

Session Server 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 when Multi Login check (Multi Login)

다중 로그인시 먼저 로그인 한 사용자에게 표시되는 로그아웃 결과 페이지

Logout Message when Multi Login check (Multi Login)

다중 로그인시 로그아웃 결과 메시지, ajax Client에게 JSON 타입으로 제공됨

Expected Page When Multi Login Check (Multi Login)

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