JBoss EAP 7 (이하 EAP7)이 나온지도 몇개월이 되었고 (2016년 Q3)
아직 시장에 많이 풀리지는 않았고
패치도 열심히 올라오는 중임
이번에 바뀐 부분중에서 핵심(?)적이라고 할만한 부분을 말해보자면
서블릿 컨테이너를 전면 교체 하면서
요청을 받아들이는 Connector 부분과
WAS의 실질적인 요청처리 작업을 하는 Thread의 구조 및 Pooling 방법이 변경되었다
먼저 톰켓(tomcat)과 같이 설명을 하자면
EAP6까지는 Listener(Connector), Thread Pool, servlet 처리 부분을 Tomcat으로 처리해왔다
실제 tomcat 소스를 임포트 해서 개발했다고 보면 무방하다
그러다보니 tomcat tuning 포인트와 같이 생각하면 됬다.
대표적으로 Production에 적용한 tomcat 에서 기본적으로 검토해야하는
Pure java가 아닌 tomcat Native 를 사용하듯이 (APRConnector)
(BIO-blocking , NIO-non blocking JAVA Connector ,
APR-Apache Potable Runtime Native)
EAP에서는 이미 컴파일 된 Native Module을 제공하였고
Thread처리도 기본이 아니라 Executor thread Pool을 별도로 생성하여
tomcat 내부 Thread와 사용자 처리 Thread를 분리 하여 동작하도록 튜닝했다.
(안정성 개선 등)
EAP7에서는 tomcat의 이부분(서블릿컨테이너라도 통칭)을 걷어내고
경량 서블릿컨테이너인 언더토우(Undertow)로 변경되면서
서블릿 처리를 수행하는 컨테이너를 포함하여
앞서 말한 Connector 처리와 Thread Model이 변경되었다
이렇게 변경된 이유를 추측(!) 해보면
JVM의 Native 성능에 대한 신뢰가 어느정도 올라간것이 아닌가 하는 생각이다
기존에도 NIO(New IO)라고 해서 JAVA에서도 native 통신성능을 개선한 JAVA API를 제공하였으나
API 편의성이 그다지 좋지 못하고
그냥 추론에 성능이 그리 훌륭하지 못하고 안정성에 대한 신뢰 문제.... (가 있다는것이 아니라 C로 개발된 Native에 비하여) 등의 고민때문에
별도의 native module을 개발하여 제공하였다 ( 확장자 so 파일)
하지만 아무래도 별도의 모듈 개발에 필요한 공수도 감안하고
JVM의 NIO의 개선을 목적으로 XNIO (http://xnio.jboss.org/) 프로젝트가 진행되었고
이 Xnio를 기반으로 Undertow(http://undertow.io)가 개발되었으며
EAP7 에서는 이 부분을 신규로 적용한 것이다.
그럼 XNIO 기반의 Undetow를 적용함으로써 실제 좋아지는게 뭐냐?
니들끼리 바꿨다고 자축해봐야 나하고 뭔 상관이냐고....
라기 보다는
노가다 뛰는 엔지니어 입장에서 보면 다음과 같은 개선사항이 있다
1. Native 추가적인 설치가 필요없다
기본 Pure JAVA 기반의 WAS를 Native로 동작하게 하기 위해서는 별도의 Lib 모듈이 필요하며 tomcat의 경우 별도의 모듈 생성을 위하여 gcc를 사용하여 컴파일 하는 작업.....(아...구차나...안되면 골때리고...생성되도 운영시 문제발생시 해결방법이 없다)
JVM의 NIO를 기반으로 하는 XNIO를 사용하여 Connector 와 Buffer를 처리함으로써 JVM만 있으면 별도의 라이브러리가 필요없다.
설치가 단순해 진다.
2. Connector(Listener)의 단순화
EAP5를 구동하면 WAS 하나에 엄청나게 많은 Listen Port가 열렸다.
별별 다른 APP들과 충돌이 나고
포트 번호 하나 바꾸는데 진이 빠질 정도였던 환경에서
EAP6로 가면서 일부 최적화가 되었으나
tomcat Connector는 Multiplexer(MUX) 기능(1개 포트로 여러 프로토콜통신수행)을 구현할 수 없었기 때문에 어쩔 수 없이 다수의 Listen port가 사용되었다.
(예를 들어 관리용 Native Port 9999, EJB용, 기타 등등)
EAP7에서는 XNIO의 MUX기능을 사용할 수 있게 되었고 이를 통하여 Port를 통합함으로써 점유하는 Port 수를 획기적으로 줄였다
(관리용 Port 9999 하나로 EJB, JMX 등 여러 서비스를 동시 제공, HTTP 8080 포트하나로 HTTP2.0 프로토콜 동시제공)
3. Direct Buffer 사용
성능과 큰 관계가 있는 부분으로 기존에는 사용자 요청을 받으면 JVM 내부 Heap 영역의 일부를 Buffer로 지정하여 해당 영역에 저장하여 처리 하였으며 이 버퍼는 Blocking 모드로 동작했다(JVM의 내부는 무조건 Blocking Thread 모델이다...태생이 그렇다.
(Native 모듈설치한 WAS나 NIO 빼고)
EAP7 부터는 XNIO를 사용하여 JVM 외부 메모리 영역(Native Memory) 즉 Process의 메모리 영역에 접근할 수 있게 되어 non blocking으로 메모리에 저장함으로써 Buffer 처리 능력을 획기적으로 상승시킨다.
(솔까말 Native Module 설치한 WAS와는 비교하면 그놈이 그놈)
4. IO thread 별도로 추가됨
위에서 말한 MUX에 들어오는 요청은 기존에는 WAS Thread와 1:1 매칭 되는 구조였으나
이제 부터는 별도의 IO Thread가 Listener로 들어온 요청을 non blocking으로 읽어서 direct buffer에 저장하게 되므로 Rush 성 요청에 대한 대응능력이 개선됬을 것으로 보인다.
무슨말이냐...
요청이 엄청나게 밀려드는 웹사이트에서 JVM이 그러한 요청처리를 하기 위해서는 Kernel과 통신하여 요청을 처리해야 하고 이때 Blocking이 걸린다.
만약 JVM이 처리하는 속도 보다 요청이 더 빠르게 유입된다면
요청은 큐에 쌓이다가 결국 튕겨져 나가는 현상이 발생할 수 있다.
느린 (blocking thread) JVM Thread는 기존과 같이 working thread로 사용하지만
그 앞단에 Non blocking Thread를 별도로 두어서
들어오는 요청을 빠르게 수용할 수 있도록 변경함으로써
일단 들어오는 요청은 최대한 빨리 내부로 진입 시킬 수 있도록 개선되었다는 이야기.....
(아...씨바...머이리 복잡해.....)
이러한 구조는
대형 사이트에서 사용되던 상용 Product 에 이미 적용되곤 했던 검증된 구조로써
대표적으로 Iplanet Web Server(Sun One Web Server, Oracle iplanet webserver)에 적용되어
뛰어난 성능과 안정성을 자랑했다.
5. Worker(Working Thread Pool) 가 추가 되었다.
IO Thread가 단순히 요청을 빠르게 읽어들어 뒷단으로 저장하는 기능을 담당(Non Blocking)한다면
Working Thread는 실제 처리를 수행하는 (파싱하고..적달한 엔진으로 넘기고...대답하고)하는 역할(Blocking)을 수행한다.
기존의 Executor Thread Pool 이라고 불리던 Thread Pool이
Worker 라는 이름으로 변경되었다고 보면 된다.
사실 Thread Pool이야 원래 있던 내용이지만
이전까지 직접 config 파일을 열어서 추가하고
connector와 연결하는 작업을 해야 했던 터라
구조를 이해 하지 못하고 작업 해서는 잘 되지 않고
잘못넣으며 문제를 일으키기 십상...
이러한 부분을 CLI 및 GUI로 통합하여 구성 할 수 있도록 해서
Pool 관리가 월등히 편리해 졌다.
그럼 사용자 입장에서는 뭐가 좋아졌을까?
일단 성능이 좋아졌을 것으로 기대(?) 하고 있다.
본인이 직접 BMT를 해보지 못해서 딱 그렇다고 는 못하겠지만
EAP7이 안정화 되면 기존 버젼보다는 안정성 및 성능면에서 상당한 개선이 기대 된다.
뭐...WAS가 다 그놈이 그놈이지...
내가 운영하는 사이트가 최소한 동시접속이 수천~만 까지 되는것이 아니라면
솔직히 직업 운영할 능력 되면 tomcat도 좋고 Resin도 좋다 그 단순함의 미학....
하지만 아무래도 대용량 접속이 고려 되는 사이트이거나
자체적인 운영 능력이 낮은 조직라면
이제와서 WAS BMT 하자는건 너무 오바고
(올해 2017년이다.
WAS BMT가 웬 말이냐 이미 시장에서 검증된것 좀 믿어라...
김태희 예쁜걸 꼭 같이 살아봐야 알겠냐... 믿어라)
되도록 상용 WAS를 권하고 싶다.
.이상
2017년 1월 4일 수요일
2015년 9월 23일 수요일
JBoss Clustering Session 복제시 복제 기준
맨날 해깔려서 하는김에 정리해서 적어봄
1. 개요를 말하면....
공히 WAS 들은 Session Clustering 이라는 기능을 제공한다.
여러대의 WAS (Instance)가 하나의 서비스를 제공할때 각각의 WAS 에 로그인(**)한정보(Session)를 공유하여 일부 WAS가 정지되어도 로그인이 유지되는 기능이다.
** 엄밀히 로그인은 아니다. JSessionID 라는 WAS에서 생성해 주는 쿠키값으로 접속한 클라이언트의 세션을 유지하는 것으로 당신들이 ID/Password 를 입력하는 로그인 이라는 행위는 개발자가 개발해 놓은 기능이다.
상용 WAS 들 중에서 Enterprise 라는 단어가 붙어 있는 놈들과
Standard 버젼의 차이가 이거라고 보면 된다.
- 상용 제품군-
Web logic : Ent 와 Std 로 나뉜다.
JEUS : Ent 와 Std 로 나뉜다.
- 오픈소스(OSS)비지니스 제품군 - (오픈소스이기는 한데 돈내야 지원해준다)
JBoss EAP : Infinispan 기반으로 클러스터링 제공한다.
Resin : OSS 버젼과 Pro 버젼이 있으며 기본적으로 Clustering 기능이 있다. OSS 버젼은 Pure JAVA라 성능으로 따지만 Tomcat 이나 별반 차이도 없다.
- 오픈소스 제품군- (이건 기술지원 따위는 없다. 그냥 너님이 하는거다)
WildFly(구 JBoss AS) : Infinispan 이라는 Grid OSS 가 내부적으로 구현되어 있고 이기능올 클러스터링 제공
Tomcat : Clustering 기능이 최근에 추가 되어있다. 하지만 성능은 보장 못한다(않좋아...pure java 라넘 느려)
....
2. 근데 이거 꼭 써야해?
결론 부터 이야기하자... "아니다!"
세션을 유지한다는 것은 사용자 브라우져와 서버간의 접속이 유지되지 못하는 WEB의 특성상 (HTTP Protocol 은 stateless 라고 한다.)
한번 접속해서 화면 받아오면 상태(status)가 유실된다.
하지만 사용자의 상태가 유지되어야 로그인정보나 장바구니를 다시 볼 수 있기 때문에
이런 상태를 유지하는 것을 세션(Session)이라고 하며
이 세션을 유지하는 방법은 꼭 인프라(WAS) 에서 구현되어야 함은 아니다.
예를 들어 대규모 사이트의 경우 세션 정보를 WAS에서 복제하여 상태유지를 할 경우 세션을 모든 WAS가 동기화 하기위한 부하때문에 오히려 장애포인트가 되기도 한다. (Instance 여러개 + 사용자 대박!! 이면 WAS 지들끼리 세션 복사하다가 뻗어 버리기도 한다)
물론 JBoss 나 상용 WAS들은 이런 복제 Overhead 를 줄이기 위해서 몇몇 옵션등을 제공하기도 하므로 이런일로 고생하고 있다면 제품 지원팀에 문의해 보자.
(Sync 방식을 ASync 방식으로 바꾸거나, UDP 클러스터를 TCP로 바꾸거나 등등)
이러한 문제를 해결하기 위해서
WAS의 클러스터링 기능을 쓰지 않고
로그인처리시에 암호화된 세션정보를 사용자(브라우져)에 저장(쿠키)하도록 개발해서
세션을 유지 하기도 한다.
(사용자가 대박!인 글로벌 회사의 업무시스템 또는 대형 오픈마켓)
선택는 자유다.
단 팁을 준다면
2.1. 우리사용자가 졸라 많거나(동접 몇 만명 같이...) WAS 인스턴스가 너무 많아서 클러스터링을 하는게 부담스러운경우
(다수의 WAS를 Clustering 하는 경우 세션복제 Overhead 로 인하여 원래 1개 WAS 가 처리할 수 있는 능력이 감소한다)
상용 WAS 기준이라면
클러스터링 버젼(Enterprise)보다 Standard 버젼을 도입하고 세션을 쿠키로 유지하거나
그리드 솔루션이 있다(JBoss Data Grid, Oracle coherence, 국산도 있다 GTWorks )
쿠키를 쓰건 그리드솔루션을 사용하건 일단 개발자가 세션을 유지하기 위한 방법을 설계해야 하고 일부 세션 관리 코딩은 추가 되어야 한다.
개발자 학습비용 기준 : 코드기반으로 관리하려면 아키텍쳐 부터 설계필요
WAS Clustering < Grid Solution < 코드(Cookie) 기반
서버부하(Overhead) 기준 : Overhead 가 클수록 WAS 처리량은 낮아진다.
WAS Clustering > Grid Solution > 코드(Cookie) 기반
오픈소스기반이라면
여하간 Tomcat Clustering은 사용하지 말라
게시판 뒤져보면 알겠지만 아직 성능이나 안정성이나 그다지 좋다고 못하겠다.
JBoss EAP 자체의 Clustering 을 사용하거나 위에 말한 그리드 솔루션(JBoss Data Grid)을 같이 검토하도록 한다.
또 다른 방법으로 클러스터를 쪼개는 방법이 있다.
(나는 개인적으로 이 구조를 좋아하고 많이들 이렇게 한다...
근데...실제 운영해야하는 사람들이 WEB/WAS/HA등을 잘 모르면 맨날 장애를 일으킨다......
예를들어 공무원조직에 담당자는 그게뭔지 모른다...장애나면 사람부른다....사람도착할 때 까지 장애다.)
예를 들어 인스턴스가 8개라면 클러스터를 8개 통째로 묶는게 아니라
4개 + 4개 로 클러스터를 두개로 나누어 운영하도록 하고
사용자 트래픽을 웹에서 분산구조에서 제어해서 최대한 장애가 발생하지 않도록 한다.
WEB : 1,2 3,4
WAS : 1234 5678
위 구조에서 웹서버 1 또는 2로 들어온 사용자는 WAS1,2,3,4 로 접속이 되고 세션이 유지된다. 만약 was1,2,3,4 가 동시에 중지된다면 장애가 된다.
이러한 운영상의 논리적인 구조를 쪼개서 운영하는 경우 HA를 위하여 작업절차나 장애처리시 재구동 방법등을 세밀하게 조정하고 운영해야 한다.
(Ex, 배포후 재구동시 WAS를 1,2,3,4,5,6,7,8 순으로 재구동하지 말고 1,5,2,6,3,7,4,8 순으로 재구동 한다거나...)
2.2 걍걍 일반적인 업무 시스템 이라면
WAS의 Clustering 기능을 사용하도록 한다.
세션을 개발자가 코드상에서 생성하고 서버에 저장해서 유지를 한다는 일은......머리아프다....
기술적인 부하 문제가 없다면 Clustering 되는 제품간의 가격 비딩이 될 것이니...
알아서 하자.
3. JBoss EAP 에서 클러스터링 할 때 방법
아... 사실 Config를 하나하나 이야기 하려면 너무 많은 것을 설명해야 한다....
(UDP 냐 TCP 냐... 복제방식은 뭐냐...등등)
그냥 일단 클러스터링 되어 있다치고
개발자 입장에서 알아야할 세션 복제에 집중해서 적어본다.
일단 소스에서 /WAR_ROOT/WEB-INF/web.xml 파일안에 아래 볼드체가 있어야 동작한다.
두번째
세션 복제는 RMI 같이 네트워크 통신을 해서 복제 된다.
그래서 세션에 저장하는 모든 Object는 Serializable 해야 한다. (JAVA Spec)
이건 WAS 할아버지가 와도 지켜야 할 법칙이다. (제품 마다 다르다는 뻘소리 하지 말자)
복잡하게 세션 객체를 만들어 쓰는 개발자 라면 아래 같이 하자.
class UserSessionObj implements Serializable
{
}
UserSessionObj InstUserSessionObj = UserSessionObj();
InstUserSessionObj.setUDI = "이름";
....
session.setAttribute("SESSION_OBJ", InstUserSessionObj);
세번째
/WAR_ROOT/WEB-INF/jboss-web.xml 파일안에 이런게 있다.
없으면 만들어도 된다. 하지만 기본 값이 있으므로 클러스터링 부하로 인한 문제
또는 개발한 기능상 복제될 세션객체에 대한 제어가 필요하지 않다면 꼭 만들 필요는 없다.
아래 뻘건 글씨를 잘 보자, 일단 이게 기본값이다.
<jboss-web>
<context-root>/</context-root>
<replication-granularity>SESSION</replication-granularity>
<replication-field-batch-mode>true</replication-field-batch-mode>
.... 이거 말고도 잔뜩
</replication-config>
</jboss-web>
==========================================
웅??? 그게 뭐냐구???
메뉴얼 상에 글을 옮겨 보겠다.
SET: With this policy, the session is considered dirty only when an attribute is set in the session (i.e., HttpSession.setAttribute() is invoked.) If your application always writes changed values back into the session, this option will be most optimal in terms of performance. The downside of SET is that if an object is retrieved from the session and modified without being written back into the session, the session manager will not know the attribute is dirty and the change to that object may not be replicated.
>> 코드상에서 setAttribute()시 세션을 복제한다.
가장 클러스터링 부하가 낮다.
이렇게 해놓으면 값은 바뀌지만 복제가 안 될 수 있다.(코드 잘 짜면 그런 걱정 안해도 된다.)
세션에 저장되는 정보를 코드상에서 크게 컨트롤 하지 않는다면 부하를 줄이기 위해 사용해 볼 만 하다.
SET_AND_NON_PRIMITIVE_GET:(기본값) This policy is similar to the SET_AND_GET policy except that get operations that return attribute values with primitive types do not mark the attribute as dirty.
Primitive system types (i.e., String, Integer, Long, etc.) are immutable(수정불가능한), so there is no reason to mark an attribute with such a type as dirty just because it has been read.
If a get operation returns a value of a non-primitive type, the session manager has no simple way to know whether the object is mutable, so it assumes it is an marks the attribute as dirty.
This setting avoids the downside of SET while reducing the performance impact of SET_AND_GET. It is the default setting.
>> setAttribute()시 세션복제 + getAttribute()시 기본형(primitive type)들을 빼고 복제
(기본설정)
기본형(char,int,String, Integer**..등)는 재 할당은 가능하지만 할당된 값 자체를 변경할 수 없다. (이 객체들에는 set method가 없다) - 개발을 해보지 않으면 좀 해깔릴 수 있다. immutable 객체에 대한 내용을 인터넷에서 찾아볼 것을 권한다-
그래서 이 값들은 GET 하는 순간에는 변경이 일어나지 않았음을 보장할 수 있으므로 (대체한다는 것은 SET 을 수행했다는것을 의미하므로 이미 복제 되었다.)
GET할때 Primitive 형을 복제 대상으로 지정하지 않는다.
이 방식은 SET의 누락에 대한 위험(오류)성과
SET_AND_GET이 너무많은 데이터를 복제할 수 있는 위험(성능관련)을 적절하게 타협한 방식으로 기본값으로 적용되어 있다.
이 설정이 기본이고 보통 이설정으로 큰 문제 없이 사이트 들은 운영된다.
SET_AND_GET: With this policy, any attribute that is get or set will be marked as dirty. If an object is retrieved from the session and modified without being written back into the session, the change to that object will be replicated. The downside of SET_AND_GET is that it can have significant performance implications, since even reading immutable objects from the session (e.g., strings, numbers) will mark the read attributes as needing to be replicated.
>> setAttribute()시 세션복제 + Obj getAttribute()시 세션복제
세션에 속성으로 객체나 프리미티브정보를 최초생성 하거나 이 값에 접근할 때 여하간 복제한다.
SET 이나 SET_AND_NON_PRIMITIVE_GET 보다는 복제 부하가 크겠찌??? 그지??
ACCESS: This option causes the session to be marked as dirty whenever it is accessed. Since a the session is accessed during each HTTP request, it will be replicated with each request. The purpose of ACCESS is to ensure session last-access timestamps are kept in sync around the cluster.. Since with the other replication-trigger options the time stamp may not be updated in other clustering nodes because of no replication, the session in other nodes may expire before the active node if the HTTP request does not retrieve or modify any session attributes. When this option is set, the session timestamps will be synchronized throughout the cluster nodes. Note that use of this option can have a significant performance impact, so use it with caution. With the other replication-trigger options, if a session has gone 80% of its expiration interval without being replicated, as a safeguard its timestamp will be replicated no matter what. So, ACCESS is only useful in special circumstances where the above safeguard is considered inadequate.
>> HTTP 요청이 있으면 Session변경으로 간주하여 복제...여하간 무조건 복사
내 생각에 이거 하면 복제 트리거를 신경을 안써도 되니 간단해 보이지만 프로덕션환경에 적용하는 경우 그냥 사이트 무너진다고 보면 되겠다 (개인 홈페이지라면 상관없다)
.이상.
1. 개요를 말하면....
공히 WAS 들은 Session Clustering 이라는 기능을 제공한다.
여러대의 WAS (Instance)가 하나의 서비스를 제공할때 각각의 WAS 에 로그인(**)한정보(Session)를 공유하여 일부 WAS가 정지되어도 로그인이 유지되는 기능이다.
** 엄밀히 로그인은 아니다. JSessionID 라는 WAS에서 생성해 주는 쿠키값으로 접속한 클라이언트의 세션을 유지하는 것으로 당신들이 ID/Password 를 입력하는 로그인 이라는 행위는 개발자가 개발해 놓은 기능이다.
상용 WAS 들 중에서 Enterprise 라는 단어가 붙어 있는 놈들과
Standard 버젼의 차이가 이거라고 보면 된다.
- 상용 제품군-
Web logic : Ent 와 Std 로 나뉜다.
JEUS : Ent 와 Std 로 나뉜다.
- 오픈소스(OSS)비지니스 제품군 - (오픈소스이기는 한데 돈내야 지원해준다)
JBoss EAP : Infinispan 기반으로 클러스터링 제공한다.
Resin : OSS 버젼과 Pro 버젼이 있으며 기본적으로 Clustering 기능이 있다. OSS 버젼은 Pure JAVA라 성능으로 따지만 Tomcat 이나 별반 차이도 없다.
- 오픈소스 제품군- (이건 기술지원 따위는 없다. 그냥 너님이 하는거다)
WildFly(구 JBoss AS) : Infinispan 이라는 Grid OSS 가 내부적으로 구현되어 있고 이기능올 클러스터링 제공
Tomcat : Clustering 기능이 최근에 추가 되어있다. 하지만 성능은 보장 못한다(않좋아...pure java 라넘 느려)
....
2. 근데 이거 꼭 써야해?
결론 부터 이야기하자... "아니다!"
세션을 유지한다는 것은 사용자 브라우져와 서버간의 접속이 유지되지 못하는 WEB의 특성상 (HTTP Protocol 은 stateless 라고 한다.)
한번 접속해서 화면 받아오면 상태(status)가 유실된다.
하지만 사용자의 상태가 유지되어야 로그인정보나 장바구니를 다시 볼 수 있기 때문에
이런 상태를 유지하는 것을 세션(Session)이라고 하며
이 세션을 유지하는 방법은 꼭 인프라(WAS) 에서 구현되어야 함은 아니다.
예를 들어 대규모 사이트의 경우 세션 정보를 WAS에서 복제하여 상태유지를 할 경우 세션을 모든 WAS가 동기화 하기위한 부하때문에 오히려 장애포인트가 되기도 한다. (Instance 여러개 + 사용자 대박!! 이면 WAS 지들끼리 세션 복사하다가 뻗어 버리기도 한다)
물론 JBoss 나 상용 WAS들은 이런 복제 Overhead 를 줄이기 위해서 몇몇 옵션등을 제공하기도 하므로 이런일로 고생하고 있다면 제품 지원팀에 문의해 보자.
(Sync 방식을 ASync 방식으로 바꾸거나, UDP 클러스터를 TCP로 바꾸거나 등등)
이러한 문제를 해결하기 위해서
WAS의 클러스터링 기능을 쓰지 않고
로그인처리시에 암호화된 세션정보를 사용자(브라우져)에 저장(쿠키)하도록 개발해서
세션을 유지 하기도 한다.
(사용자가 대박!인 글로벌 회사의 업무시스템 또는 대형 오픈마켓)
선택는 자유다.
단 팁을 준다면
2.1. 우리사용자가 졸라 많거나(동접 몇 만명 같이...) WAS 인스턴스가 너무 많아서 클러스터링을 하는게 부담스러운경우
(다수의 WAS를 Clustering 하는 경우 세션복제 Overhead 로 인하여 원래 1개 WAS 가 처리할 수 있는 능력이 감소한다)
상용 WAS 기준이라면
클러스터링 버젼(Enterprise)보다 Standard 버젼을 도입하고 세션을 쿠키로 유지하거나
그리드 솔루션이 있다(JBoss Data Grid, Oracle coherence, 국산도 있다 GTWorks )
쿠키를 쓰건 그리드솔루션을 사용하건 일단 개발자가 세션을 유지하기 위한 방법을 설계해야 하고 일부 세션 관리 코딩은 추가 되어야 한다.
개발자 학습비용 기준 : 코드기반으로 관리하려면 아키텍쳐 부터 설계필요
WAS Clustering < Grid Solution < 코드(Cookie) 기반
서버부하(Overhead) 기준 : Overhead 가 클수록 WAS 처리량은 낮아진다.
WAS Clustering > Grid Solution > 코드(Cookie) 기반
오픈소스기반이라면
여하간 Tomcat Clustering은 사용하지 말라
게시판 뒤져보면 알겠지만 아직 성능이나 안정성이나 그다지 좋다고 못하겠다.
JBoss EAP 자체의 Clustering 을 사용하거나 위에 말한 그리드 솔루션(JBoss Data Grid)을 같이 검토하도록 한다.
또 다른 방법으로 클러스터를 쪼개는 방법이 있다.
(나는 개인적으로 이 구조를 좋아하고 많이들 이렇게 한다...
근데...실제 운영해야하는 사람들이 WEB/WAS/HA등을 잘 모르면 맨날 장애를 일으킨다......
예를들어 공무원조직에 담당자는 그게뭔지 모른다...장애나면 사람부른다....사람도착할 때 까지 장애다.)
예를 들어 인스턴스가 8개라면 클러스터를 8개 통째로 묶는게 아니라
4개 + 4개 로 클러스터를 두개로 나누어 운영하도록 하고
사용자 트래픽을 웹에서 분산구조에서 제어해서 최대한 장애가 발생하지 않도록 한다.
WEB : 1,2 3,4
WAS : 1234 5678
위 구조에서 웹서버 1 또는 2로 들어온 사용자는 WAS1,2,3,4 로 접속이 되고 세션이 유지된다. 만약 was1,2,3,4 가 동시에 중지된다면 장애가 된다.
이러한 운영상의 논리적인 구조를 쪼개서 운영하는 경우 HA를 위하여 작업절차나 장애처리시 재구동 방법등을 세밀하게 조정하고 운영해야 한다.
(Ex, 배포후 재구동시 WAS를 1,2,3,4,5,6,7,8 순으로 재구동하지 말고 1,5,2,6,3,7,4,8 순으로 재구동 한다거나...)
2.2 걍걍 일반적인 업무 시스템 이라면
WAS의 Clustering 기능을 사용하도록 한다.
세션을 개발자가 코드상에서 생성하고 서버에 저장해서 유지를 한다는 일은......머리아프다....
기술적인 부하 문제가 없다면 Clustering 되는 제품간의 가격 비딩이 될 것이니...
알아서 하자.
3. JBoss EAP 에서 클러스터링 할 때 방법
아... 사실 Config를 하나하나 이야기 하려면 너무 많은 것을 설명해야 한다....
(UDP 냐 TCP 냐... 복제방식은 뭐냐...등등)
그냥 일단 클러스터링 되어 있다치고
개발자 입장에서 알아야할 세션 복제에 집중해서 적어본다.
일단 소스에서 /WAR_ROOT/WEB-INF/web.xml 파일안에 아래 볼드체가 있어야 동작한다.
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
<session-config>
<session-timeout>30</session-timeout>
<tracking-mode>URL</tracking-mode>
</session-config>
<distributable></distributable>
</web-app>두번째
세션 복제는 RMI 같이 네트워크 통신을 해서 복제 된다.
그래서 세션에 저장하는 모든 Object는 Serializable 해야 한다. (JAVA Spec)
이건 WAS 할아버지가 와도 지켜야 할 법칙이다. (제품 마다 다르다는 뻘소리 하지 말자)
복잡하게 세션 객체를 만들어 쓰는 개발자 라면 아래 같이 하자.
class UserSessionObj implements Serializable
{
}
UserSessionObj InstUserSessionObj = UserSessionObj();
InstUserSessionObj.setUDI = "이름";
....
session.setAttribute("SESSION_OBJ", InstUserSessionObj);
세번째
/WAR_ROOT/WEB-INF/jboss-web.xml 파일안에 이런게 있다.
없으면 만들어도 된다. 하지만 기본 값이 있으므로 클러스터링 부하로 인한 문제
또는 개발한 기능상 복제될 세션객체에 대한 제어가 필요하지 않다면 꼭 만들 필요는 없다.
아래 뻘건 글씨를 잘 보자, 일단 이게 기본값이다.
<jboss-web>
<context-root>/</context-root>
<replication-config>
<replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger><replication-granularity>SESSION</replication-granularity>
<replication-field-batch-mode>true</replication-field-batch-mode>
.... 이거 말고도 잔뜩
</replication-config>
</jboss-web>
==========================================
웅??? 그게 뭐냐구???
메뉴얼 상에 글을 옮겨 보겠다.
SET: With this policy, the session is considered dirty only when an attribute is set in the session (i.e., HttpSession.setAttribute() is invoked.) If your application always writes changed values back into the session, this option will be most optimal in terms of performance. The downside of SET is that if an object is retrieved from the session and modified without being written back into the session, the session manager will not know the attribute is dirty and the change to that object may not be replicated.
>> 코드상에서 setAttribute()시 세션을 복제한다.
가장 클러스터링 부하가 낮다.
이렇게 해놓으면 값은 바뀌지만 복제가 안 될 수 있다.(코드 잘 짜면 그런 걱정 안해도 된다.)
세션에 저장되는 정보를 코드상에서 크게 컨트롤 하지 않는다면 부하를 줄이기 위해 사용해 볼 만 하다.
SET_AND_NON_PRIMITIVE_GET:(기본값) This policy is similar to the SET_AND_GET policy except that get operations that return attribute values with primitive types do not mark the attribute as dirty.
Primitive system types (i.e., String, Integer, Long, etc.) are immutable(수정불가능한), so there is no reason to mark an attribute with such a type as dirty just because it has been read.
If a get operation returns a value of a non-primitive type, the session manager has no simple way to know whether the object is mutable, so it assumes it is an marks the attribute as dirty.
This setting avoids the downside of SET while reducing the performance impact of SET_AND_GET. It is the default setting.
>> setAttribute()시 세션복제 + getAttribute()시 기본형(primitive type)들을 빼고 복제
(기본설정)
기본형(char,int,String, Integer**..등)는 재 할당은 가능하지만 할당된 값 자체를 변경할 수 없다. (이 객체들에는 set method가 없다) - 개발을 해보지 않으면 좀 해깔릴 수 있다. immutable 객체에 대한 내용을 인터넷에서 찾아볼 것을 권한다-
그래서 이 값들은 GET 하는 순간에는 변경이 일어나지 않았음을 보장할 수 있으므로 (대체한다는 것은 SET 을 수행했다는것을 의미하므로 이미 복제 되었다.)
GET할때 Primitive 형을 복제 대상으로 지정하지 않는다.
이 방식은 SET의 누락에 대한 위험(오류)성과
SET_AND_GET이 너무많은 데이터를 복제할 수 있는 위험(성능관련)을 적절하게 타협한 방식으로 기본값으로 적용되어 있다.
SET_AND_GET: With this policy, any attribute that is get or set will be marked as dirty. If an object is retrieved from the session and modified without being written back into the session, the change to that object will be replicated. The downside of SET_AND_GET is that it can have significant performance implications, since even reading immutable objects from the session (e.g., strings, numbers) will mark the read attributes as needing to be replicated.
>> setAttribute()시 세션복제 + Obj getAttribute()시 세션복제
세션에 속성으로 객체나 프리미티브정보를 최초생성 하거나 이 값에 접근할 때 여하간 복제한다.
SET 이나 SET_AND_NON_PRIMITIVE_GET 보다는 복제 부하가 크겠찌??? 그지??
ACCESS: This option causes the session to be marked as dirty whenever it is accessed. Since a the session is accessed during each HTTP request, it will be replicated with each request. The purpose of ACCESS is to ensure session last-access timestamps are kept in sync around the cluster.. Since with the other replication-trigger options the time stamp may not be updated in other clustering nodes because of no replication, the session in other nodes may expire before the active node if the HTTP request does not retrieve or modify any session attributes. When this option is set, the session timestamps will be synchronized throughout the cluster nodes. Note that use of this option can have a significant performance impact, so use it with caution. With the other replication-trigger options, if a session has gone 80% of its expiration interval without being replicated, as a safeguard its timestamp will be replicated no matter what. So, ACCESS is only useful in special circumstances where the above safeguard is considered inadequate.
>> HTTP 요청이 있으면 Session변경으로 간주하여 복제...여하간 무조건 복사
내 생각에 이거 하면 복제 트리거를 신경을 안써도 되니 간단해 보이지만 프로덕션환경에 적용하는 경우 그냥 사이트 무너진다고 보면 되겠다 (개인 홈페이지라면 상관없다)
.이상.
2014년 11월 26일 수요일
JBOSS EAP6,AS7 DB Pool 설정(귀차니즘 버젼)
아래에는 xml 파일을 직접 수정하여 등록하는 방법을 설명하며
GUI에서 등록시 좀더 편리하게 구성할 수 있다.... 하지만 안알랴줌...
GUI로 하는방법은 화면 스크린샷 떠야하고 첨부하고.... 포스팅 너무 귀찮음
너 님 알아서 잘 해보자
GUI에서 등록시 좀더 편리하게 구성할 수 있다.... 하지만 안알랴줌...
GUI로 하는방법은 화면 스크린샷 떠야하고 첨부하고.... 포스팅 너무 귀찮음
너 님 알아서 잘 해보자
1. 순서 와 overview
1.1 DB Driver 파일 등록 (jdbc driver Deploy) :
일반적으로 tomcat 이나 weblogic등을 사용할때 db driver (???.jar) 을 $HOME/lib 또는 $WAR_PATH/WEB-INF/lib 등에 넣어서 사용했을 거임
JBOSS 는 6.x 버젼부터 5.x의 극악한 구동시간을 개선하기 위해 모듈이라는 개념을 적용했는데...
이러한 사유로 기존처럼 jar 파일을 업로드할 경우 WAR 안에서 직접 사용은 가능하지만 WAS DB Pool에서는 해당 드라이버로 Pool을 생성할 수 없다능!
(5.x 버젼 ???DS 나 web.xml에 등록해서 사용하는 방법 은 사용은 가능하나 권장하는 방법은 아님.)
이러한 사유로 기존처럼 jar 파일을 업로드할 경우 WAR 안에서 직접 사용은 가능하지만 WAS DB Pool에서는 해당 드라이버로 Pool을 생성할 수 없다능!
(5.x 버젼 ???DS 나 web.xml에 등록해서 사용하는 방법 은 사용은 가능하나 권장하는 방법은 아님.)
권장방법은 일명 "디플로이"한다 라고 하는 방법으로 jdbc driver를 기존과 같이 그냥 classpath에 추가해 주는 방법이 아니라 "Deploy" 즉 WAS에 설치하는 방법으로 사용함
??? 그러면 여러개의 WAR 를 배포하는데 이때 같은 ORACLE DB 인데 Driver 버젼이 달라야 하는경우는???
걱정안해도 되는거임 WAS개발하는놈들 졸라 똑똑함 웬간한 개발자나 엔지니어들 제품 욕 그만하자 그놈들 똑똑함 ㅎㅎ
드라이버를 다른이름으로 여러개 등록 가능하다능
driver의 물리적인 위치로 예를 들면 아래같이 하면 됨
driver의 물리적인 위치로 예를 들면 아래같이 하면 됨
$EAP_HOME/module.ext/com/oracle9 (oracle 9용 드라이버 정보가 들어갈 폴더)
$EAP_HOME/module.ext/com/oracle11 (oracle 11용 드라이버 정보가 들어갈 폴더)
그리고나서 DB Pool을 생성할때 모듈과 매핑을 해주면 된다.......
...
(씨바...뭔가 논리적이긴 한데 드럽게 복잡해졌다.... -.-;;)
2014년 3월 13일 목요일
JBoss EAP6.2 Standalone Install
- 용어정의
- Instance = Server : WAS (Web Application Server)의 실질적인 서비스를 처리하는 Process
- 비용(총소유비용 TCO) : 도입을 위한 직접비용(CApex)외 변경,관리, 운영을 위한 관리비용 등(Opex) 통칭
- Domain : EAP 6 Domain 구성 기본자료 참고
- Standalone (독립실행형 서버, 이하 std)
- WAS의 관리상의 구성방법으로 구분하자면 아래와 같다
- Domain
- WAS Instance들을 관리상의 개념으로 묶어서 관리하는 구성(weblogic, webspher, JBoss EAP6 등이 Managed Domain 지원)
- Standalone
- WAS Instance를 각각 독립적으로 관리하는 구성 (일반적인 여타 tomcat, resin 등 OSS WAS)
- Domain
- recommend
- Domain Concept : 대용량 사이트에서 하나의 서비스에 다수의 Instance를 관리하는 곳, 또는 HA가 필요한 작은 서비스가 여러개 있어 전체 Instance가 많을때 Domain 형태가 권장됨
- 장점
- Web APP Deploy를 통합하여 관리하는 장점(한번의 Deploy, 타켓팅 추가로 WAS Instance에 반영가능)
- WAS Config의 형상관리 장점(한번의 수정으로 다수의 WAS에 적용, 물론 모든 속성이 다 되는것이 아니다. 일부)
- Logical한 구조를 형상화 했을때 관리적면에서 직관적임(장애, 서비스검토시 장점)
- HA 구성시 편의성
- 단점
- Std 보다 초기 구축에 노력이 더 필요함 (Domain 구조 설계, Domain Controller 구성, HostController 구성 등 엔지니어의 구축비용)
- Domain 관리 구조에 대한 이해가 필요(운영자의 초기 교육을 위한 비용)
- 추가 system resource 점유(std에 없는 관리를 위한 추가 process 구동필요, 운영상 영향이 있을 정도로 많지는 않음)
- Config가 공유되므로(WAS Booting시 Domain에서 Config를 참조하여 구동된다.) 잘못된 Config는 전체에 영향을 미칠 수 있다.
■ JBoss EAP6 초기 기동시 메모리 점유JVM옵션은 기본값 설정에서 RSS 기준
아래값은 절대 값이 아님. JVM 옵션에 따라 변동이 있을 수 있음
(예를들어 Xms와 Xmx를 동일하게 하는경우 설정된 값으로 RSS 소모됨)
Process Controller : 50M (큰 변동 없을듯???)
Domain Controller(MASTER) : 156M (관리대상 Slave가 많아지면 늘어날 수 있음)
Host Controller(SLAVE) : 139M (관리 Instance가 많아지면 늘어날 수 있음)
Instance : 417M (이놈은 서비스를 위해 지정한 대로 복불복임, 좌측 값은 설치시 만들어지는 sample instance의 점유값 임)top - 17:50:25 up 1 day, 7:47, 5 users, load average: 1.75, 0.54, 0.25
Tasks: 108 total, 1 running, 105 sleeping, 2 stopped, 0 zombie
Cpu(s): 62.9%us, 3.3%sy, 0.0%ni, 33.4%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1922488k total, 1626496k used, 295992k free, 56976k buffers
Swap: 835576k total, 1112k used, 834464k free, 291484k cachedPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11970 jboss 20 0 2392m 417m 16m S 1.7 22.3 0:10.29 /jboss/jdk/bin/java -D[Server:server-one] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1303m -Xmx1303m -server -Djbo
11997 jboss 20 0 2405m 353m 16m S 63.1 18.8 0:10.18 /jboss/jdk/bin/java -D[Server:server-two] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1303m -Xmx1303m -server -Djbo
10589 jboss 20 0 1137m 156m 15m S 0.3 8.4 0:16.15 /jboss/jdk/bin/java -D[Host Controller] -Dorg.jboss.boot.log.file=/jboss/domains/master/log/host-controller.log -D
11936 jboss 20 0 1098m 139m 14m S 0.3 7.4 0:05.40 /jboss/jdk/bin/java -D[Host Controller] -Dorg.jboss.boot.log.file=/jboss/domains/slave1/log/host-controller.log -D
10575 jboss 20 0 1098m 51m 9908 S 0.7 2.8 0:03.31 /jboss/jdk/bin/java -D[Process Controller] -server -Xms64m -Xmx128m -XX:MaxPermSize=256m -XX:+PrintGCTimeStamps -X
11922 jboss 20 0 1090m 50m 9952 S 0.7 2.7 0:00.85 /jboss/jdk/bin/java -D[Process Controller] -server -Xms64m -Xmx128m -XX:MaxPermSize=256m -Xss256k -XX:+PrintGCTime
- 장점
- Standalone concept : 개발장비, 검증장비, 적은 사용량을 가지는 단순한 사이트, 포털, 쇼핑몰과 같이 대량의 WAS를 Clustering(HA)없이 flat하게 펼칠 경우 오히려 단독형으로 구성하는 것이 관리상 권장될 수 있음
- 장점
- 초기 구성이 단순하여 노력비용이 상대적으로 낮음 (긴급 증설시 WAS 구성을 잘 정리해 놓는다면 빠르게 작업 가능)
- 잘못된 Config등(실수) 으로 인한 문제 발생시 장애 확산범위가 적음 (Config등이 다른 장비나 Instance와 독립적이므로 해당 장비에만 국한됨)
- Domain으로 구성하지 않더라도 HA등 구성가능함 (기존의 EAP5 이하 버젼에서 하던 방식으로 구성하면 됨)
- 단점
- 각각 서버에 대한 관리를 수행해야 하므로 운영시 관리비용이 상대적으로 높음(ex : 10개의 인스턴스는 10번의 작업필요, 1개 APP 10회 배포)
- 독립서버를 선호하는 고객사의 특징은 해당 서비스를 오래 운영하여 노하우 및 숙련도가 높은 경우이다.(쉽게말해 손가락이 빠른사람)
- 인력중심으로 운영되는 사이트의 경우 Std 형태를 선호할 수 있고
- 생산성을 중요시하는 사이트의 경우 Domain형태를 선호할 수 있다.
- 결국 정답이 없으므로 가이드는 하되 고객사 원하는 방향으로 진행한다. (Domain이냐 Std냐에 따라 안되지 않는다..다만 수족이 고생할 뿐)
- 숙련도에 따라 human fault 발생 위험이 존재하며 발생시 찾기가 쉽지 않다
- domain 역시 한번의 실수로 여러 서버에 장애를 유발시킬 위험은 상존한다. 다만 그만큼 찾기도 용의하다
- 독립서버에의 경우 실수한곳을 찾기 위한 시간이 숙련도에 따라 아주 작거나(장애아님으로 판단) 엄청나게 오래(장애로 판단)걸 릴 수 있다. 관리적으로 보았을때 어짜피 둘다 장애임
- 각각 서버에 대한 관리를 수행해야 하므로 운영시 관리비용이 상대적으로 높음(ex : 10개의 인스턴스는 10번의 작업필요, 1개 APP 10회 배포)
- 장점
- Domain Concept : 대용량 사이트에서 하나의 서비스에 다수의 Instance를 관리하는 곳, 또는 HA가 필요한 작은 서비스가 여러개 있어 전체 Instance가 많을때 Domain 형태가 권장됨
- WAS의 관리상의 구성방법으로 구분하자면 아래와 같다
- 설치준비
- EAP6 설치본 (StandAlone 용 별도 버젼이 있는것이 아니다. Domain 구성할때와 같은 바이너리를 사용하면 된다.)
- jboss ORG http://www.jboss.org/products/eap ) org에서도 EAP 버젼 다운로드 가능함, 로그인 필요
- Redhat https://access.redhat.com/site/downloads/ (파트너 사이트)
- StandAlone 용 스크립트 (rockplace 미들웨어컨설팅본부에 요청)
- JDK 1.6 또는 1.7 (http://www.oracle.com/technetwork/java/index.html)
- Web Server 연동시 (이 문서에서는 WAS구성만 진행함, WEB Connection은 별도 문서 작성예정)
- WebServer(EWS 또는 ApacheORG) (http://apache.org/)
- WebServer Connector (Redhat https://access.redhat.com/site/downloads/ )
- EAP6 설치본 (StandAlone 용 별도 버젼이 있는것이 아니다. Domain 구성할때와 같은 바이너리를 사용하면 된다.)
- 환경준비 (Domain 설치시 준비와 별반 차이 없음)
- /etc/hosts
- Loadbalance(web)/Cluster(was) 대상 서버가 많은경우 webserver/was 서버의 hosts에 등록하면 IP로 해깔리기 보다는 이름으로 지정하는것이 정책상 유리(고객사 선호도에 따라 다르므로 협의)
- 설치정보 제공 (고객사에 의사결정 요청)
- Basic
- Account
- jboss 계정 및 그룹
- 필요시 sudo 구성 관련 협의 (1024Port 이하로 서비스 할 경우 root로 구동해야 하나 정책상 sudo 적용이 필요한 경우)
- Web GUI Admin ID 및 Password
- PATH
- EAP 설치위치
- log 파일 위치
- Deploy Document 위치 (NAS Mount Point 등)
- Port 정보 (가이드 제공후 확인받음, 구성전에 해당 포트들에 대한 테스트는 지원인력의 역할)
- Web server
- http port
- ssl port
- WEB <-->WAS Proxy
- ajp port or httpd port or 연결을 위한 포트 정보
- WAS
JBoss는 기본 domain.xml에 정의된 서비스에 서버의 Off set 값을 더하여 서비스 Port가 결정됨
인터뷰 전에 기본 설정값을 정의하고 협의- http service
- Admin httpd service
- ajp port
- Multicast port
- 기타
- JMS 등 JBOSS External service(jboss에서는 subsystem이라고 부름) 사용시
- Web server
- Network
- /etc/hosts 등록확인 (필요시 요청, root제공시 직접 등록 등)
- Multicast 관련 (WAS Clustering 및 Web-WAS Proxy(mod_cluster) 구성시 필요
- UDP Multicast 사용가능 여부 (가이드 제공하여 확인받음)
- 고객이 모를 가능성 90%, WAS들이 같은 subnet 인지확인, 같은 subnet에 다른 Multicast사용 솔루션 존재 여부 등 인터뷰를 통하여 확인 필요
- Multicast 주소 확인(가이드 제공하여 확인받음
- UDP Multicast 사용가능 여부 (가이드 제공하여 확인받음)
- Layer4 LB가 있을 경우
- VIP 확인 (고객사 담당 또는 N/W 담당에게 확인)
- VIP를 통한 HTTP, HTTPS 서비스 LB 정책 등록 확인(정책 등록이 안되면 웹서버 설치하고 접속이 안되고....여하간 테스트가 번거로움)
- Web Server 구성 후 Server Local에서 telnet으로 확인 후 (80, 443 telnet test)
- VIP로 접속하여 정상 접속 확인 (Web Server Accesslog를 tail 해 놓으면 어느 서버로 들어오는지 확인가능)
- Firewall 정책확인
설치 후 테스트 진행시 접속이 안되서 웹페이지 확인이 안되거나 , DB 연결 테스트를 못하는 경우가 있음
되도록 사전에 확인하는것이 좋기는 하나 일일이 챙기기 힘들면 방문시 이야기해서 해결- External --> F/W --> WEB Zone : HTTP, HTTPS Port 정책 확인 (Web Zone 외부에서 Port TEST)
- WEB Zone --> F/W --> WAS Zone
- mod_jk, mod_Proxy 등은 TCP Port 접근 가능한지 여부 확인
- mod_cluster의 경우 Multicast인 경우 정책상 안될 가능성 높으므로 TCP로 LB할 방안 필요
- WAS Zone --> F/W --> DB Zone
- WAS 장비에서 DB 장비의 LISTENER의 접속 포트테스트
- Basic
- 설치정보 제공 (고객사에 의사결정 요청)
- /etc/hosts
- 설치순서
- JDK 설치
- 알아서 잘....
- EAP 압축해제 (/jboss/jboss-eap-6.2)
#unzip jboss-eap-6.2.0.zip - Domain 폴더 복사 ( 독립실행형 서버의 껍대기 만들기)
- WAS 정보를 구성할 폴더, 필요하면 협의해서 임의지정 (문서 작성시 임의로 domains 폴더에 아래쪽에 구성하기는 하나 임의 지정가능함)
#mkdir /jboss/domains - 설치본에 있는 Template 폴더(/jboss/jboss-eap-6.2/standalone)를 복사하여 필요한만큼 생성한다. (이 문서에서는 1개의 단독실행형 서버 구성까지만 다룬다.)
[jboss@kwonHost jboss-eap-6.2]$ pwd /jboss/jboss-eap-6.2 [jboss@kwonHost jboss-eap-6.2]$ cp -r ./standalone /jboss/domains/standalone1 [jboss@kwonHost jboss-eap-6.2]$ cp -r ./standalone /jboss/domains/standalone2 (필요한 만큼)
물리적인 장비와 가상화장비에서 WAS Instance의 갯수
물리적 장비와 가상화 장비의 차이는 결국 장비에 보유/할당 된 CPU Processor (processor는 CPU를 의미한다)의 갯수에 따른적정한 Process(WAS 구동시 ps 명령어로 확인되는)갯수에 대한 논의이다.과거 multi-core가 없던 시절 또는 Sun(Sparc), HP(PA-RISC), IBM(POWER) 등 RISC칩에서는 일반적으로 1Processor(CPU) 당 1Process(WAS Instance1개)가 정론 이였다.하지만 multi-core 기술이 발전하면서 의미가 복잡해 졌다. 아래와 같은 질문에 의견을 제시해본다.Q : CPU가 N개 입니다. WAS 인스턴스 몇 개나 띄워야 하나(또는 띄울수 있는가)기본적으로 대부분의 솔루션 Process의 구동은 물리적 CPU (Core, HT 논외) 당 1개의를 권장합니다.(WAS 역시 Java Process 이므로 동일함)하지만 이것은 Software 개발사 입장에서 러프하게(잘못되도 책임이 없을정도로....)잡은것이고운영자 입장에서는 이런 가이드를 그대로 따라했다가는 Over Sizing때문에 비용낭비가 발생합니다.하지만....사실 틀린말도 아니니 각자의 입장에서야 어쩔 수 없죠.... ^^;;멀티코어 기술이 발전하면 요즘은 1Core = 예전의 1CPU 로 생각하기때문에논리적으로 Processor(CPU) 2개 각 Processor 당 Core 4 인 1U 장비의 경우기본은 2개(엔지니어입장), Core를 감안하여 최대 8개(운영자입장) 까지 가능 하겠다고 말할 수 있습니다.하지만최대 Core수의 70% (8Core * 0.7 = 5.6) 인 6개 Process를 최대로 권장합니다.이렇게 권장하는 근거는 1CPU와 Dual Core CPU 간의 성능 향상은 CPU 연산으로는 2배 수가 맞으나Core의 증가로 인하여 core와 Memory 구간의 통신 bandwidth bottleneck(병목구간)이 증가합니다.(H/W적으로 지속적인 개선이 되고 있으나 장비에 따라 다르므로 software측인 WAS입장에서 정확한 수치는 제공하기 어렵다)이에 따라 일반적으로 전체 Core수 만큰 WAS Process를 구동하는것은 권장되지 않습니다. (장비의 성능에 따라 모니터링을 통하여 관리 되어야 할 문제)특히나 GC 성능을 향상 시키기 위해 병렬(Para) 또는 실시간(CMS) 등의 GC 알고리즘을 적용하면기본값은 OS상에서 확인되는 CPU 개수(=시스템의 Core개수)만큼의 Thread가 JVM 메모리 정리를 위하여 구동되므로(JVM Option으로 수동 조정가능)전체 Core 수의 70% 수준으로 WAS Process를 구동시킬 것을 권장합니다.Q : 2CPU 장비인 Dell 장비가 있다. CPU당 Core가 8개 짜리인데 인스턴스는 몇 개나 띄워야 하나위에서 말했듯이 8 * 2 = 16core16core * 0,7 = 11.2 으로 최대 11개정도가 가능하겠습니다. (메모리가 가능하다면...사실 이런 장비는 닥치고 가상화 하는겁니다.)튜닝 값에 절대 값은 없습니다. 운영상태를 모니터링해서 더 띄워도 됩니다만....역설적으로 더 구동해도 된다는것은 그만큼 트래픽이 적다는 의미 이므로차라리 서버수를 줄이는 통합 작업을 거치는 것이 좋은 방향일 수 있습니다.Q: Hyper-Threading(HT)을 켜면 CPU가 2배 많아진다.(보기에...) 그만큼 WAS를 더 띄워도 되나Hyper-Threading(이하 HT)는 로지컬하게 CPU로 들어오는 명령어를 CPU에 Mapping 하는것이 아니라가상의 Thread를(LWP : light-weight process 등으로 부름) CPU 같이 보이도록 하여 CPU를 최대한 활용하고자 하는 노력입니다.이러한 컨셉은 1개의 요청이 단순하다는 전제를 가집니다.일반 PC가 아닌 서버장비에서는 양적으로 엄청나게 많고... 복잡도 면에서 단순부터 복잡까지 다양한 형태의 작업이 수행됩니다.이로 인하여 CPU에서 작업을 처리하기 위한 요청이 많고 이는 잦은 Context Switching(이하 CTX)을 유발합니다.ctx는 1개의 CPU에 여러개의 작업이 순서대로 들어가 수행되기 위해 작업을 그때그때 교체하여 처리 하는것으로많아지면 전체적인 처리성능의 저하를 유발합니다. (EDPS 수업에서 CPU는 시분할 처리 방식이라고 했던 기억을 생각해 보시면....)예를 들어 내가 작업 세가지를 동시에 하는데 각 작업을 수행할때 책상을 정리해야 한다면몇개의 작업을 동시에 처리할때는 책상을 정리하는 시간이 큰 문제가 아니고 세가지를 순서대로 하는것 보다빨리 처리될 수 도 있겟지만 동시 작업량이 점점 늘어나 무한대로 진행하면결국 전체 작업시간에서 대부분을 책상을 정리하는 시간으로 소모하게 됩니다.(Over head라고 부르는)이러한 기본적인 상식선상에서WAS 장비에서 Hyper-Threading은 오히려 성능을 떨어트릴 수 있고일반적으로 Server 장비에서는 HT Off를 기본 권장하기도 합니다.(HT에 대한 지식수준에 따라 이 부분은 사람들 마다 다르게 생각합니다.... 결국은 고객사이트가 원하는대로 해주는게 진리)Q. 서버 가상화 환경에서 4Core를 할당한 VM에는 WAS를 몇개나 만들면 됩니까? (Production환경)기본은 위 연산과 동일하게 생각하면 됩니다.4 * 0.7 = 2.8 = 3개 이하로 운영하는겁니다.다만 가상화 장비에서 CPU를 Over Commit 하는등 Production에 어울리지 않게(?) 운영하고 있다면모니터링을 통해서 Bare-metal(물리적인 장비)의 CTX 값이나 CPU 상태를 보고 판단해야 합니다.예를들어32Core 장비에 WAS VM만 바쁘고 다른 VM이 다 놀고 있다면 전혀 이상이 없겠으나Load Avr이 50% 이상인 장비에서 WAS VM이 바쁘게 동작한다면 가상화 장비의 성능에 영향을 받을 수 있습니다.Software인 WAS입장에서 Physical 장비의 멀티코어, HT에 대한 가이드는 장비 특성에 너무 많이 의존적이라 사실 가이드를 하면 안됩니다.(약은 약사에게 병의 의사에게...를 기억합시다)거기다 가상화까지 해 놓는다면 이를 가이드 할 수 는 없습니다.다만 기준을 제시 할 수 있으나 절대적이지 않음을 주지시키면서 가이드를 제공해야 합니다......아.... 울 호갱님들이 내 사이트에 얼마나 들어올지일시킨 개발자가 짜놓은 APP 성능이 어떨지SQL이 얼마나 빨리 반응할지알!수!가! 없다!!대체 WAS가 얼마나 부하가 발생할지 사실 알게 무어냐!Open전 스트레스테스트와 모니터링만이 살길이다 - 구동 정지및 모니터링을 위한 쉡 스크립트를 복사하여 넣는다
스크립트에 실행권한 추가 및 복사
[jboss@kwonHost slave]$ pwd /jboss/EAP6_Standalone_Script [jboss@kwonHost slave]$ chmod +x ./*.sh [jboss@kwonHost slave]$ cp /jboss/EAP6_Standalone_Script/* /jboss/domains/standalone1
- 로그가 저장될 공간을 만들어준다. 폴더가 없으면 쌓이지 않는다. (스크립트 개선필요)
cd /jboss/domains/standalone1 mkdir -p ./log/controllerlog mkdir -p ./log/gclog mkdir -p ./log/nohup
- WAS 정보를 구성할 폴더, 필요하면 협의해서 임의지정 (문서 작성시 임의로 domains 폴더에 아래쪽에 구성하기는 하나 임의 지정가능함)
- Standalone(독립실행형) 서버 구성
- env.sh 수정
[jboss@kwonHost standalone1]$ cat env.sh
#!/bin/sh
DATE=`date +%Y%m%d%H%M%S`export JAVA_HOME=/jboss/jdk##### JBOSS Directory Setup #####
export JBOSS_HOME=/jboss/jboss-eap-6.2
export DOMAIN_BASE=/jboss/domains
export SERVER_NAME=standalone1
##### Configration File #####
#Standalone으로 구성하되 프로파일에 따라 지원이 다름
#standalone.xml : 지정하지 않으면 기본 적용되는 설정, HA나 추가 subsystem(JMS같은) 미포함
#standalone-ha.xml : Cluster 및 Loadbalance 을 포함하여 구동됨, subsystem 미포함 <== Cluster 구성시 보통 이거
#standalone-full.xml : HA는 미포함 sybsystem만 포함하여 구동
#standalone-full-ha.xml : subsystem과 HA를 모두 포함하여 구동됨export CONFIG_FILE=standalone-ha.xml
export HOST_NAME=standalone1
export NODE_NAME=$SERVER_NAMEexport PORT_OFFSET=10
export JBOSS_USER=jboss#WAS의 서비스 Port
##### Bind Address #####
export BIND_ADDR=0.0.0.0
export MGMT_ADDR=0.0.0.0
#export MGMT_ADDR=127.0.0.1#Cluster 구성시 필요한 Muticast 정보
#export MULTICAST_ADDR=230.1.0.1
#export JMS_MULTICAST_ADDR=231.7.0.1
#export MODCLUSTER_MULTICAST_ADDR=224.0.1.105
#Admin GUI 접속을 위한 정보(이 부분 검토해서 MGMT 부분하고 스크립트 통합 필요)
#export CONTROLLER_IP=$MGMT_ADDR
export CONTROLLER_IP=127.0.0.1
let CONTROLLER_PORT=9999+$PORT_OFFSET
export CONTROLLER_PORTexport LAUNCH_JBOSS_IN_BACKGROUND=trueexport LOG_HOME=$DOMAIN_BASE/$SERVER_NAME/log
#export LOG_HOME=/ctmsap_log##### JBoss System module and User module directory #####
export JBOSS_MODULEPATH=$JBOSS_HOME/modules:$JBOSS_HOME/modules.ext
# JVM Options : Server
export JAVA_OPTS="-server $JAVA_OPTS"# JVM Options : Memory
export JAVA_OPTS=" $JAVA_OPTS -Xms2048m -Xmx2048m -XX:MaxPermSize=256m"export JAVA_OPTS=" $JAVA_OPTS -XX:+PrintGCTimeStamps "
export JAVA_OPTS=" $JAVA_OPTS -XX:+PrintGCDetails "
export JAVA_OPTS=" $JAVA_OPTS -Xloggc:$LOG_HOME/gclog/gc_$DATE.log "
export JAVA_OPTS=" $JAVA_OPTS -XX:+UseParallelGC "
#export JAVA_OPTS=" $JAVA_OPTS -XX:+UseConcMarkSweepGC "
export JAVA_OPTS=" $JAVA_OPTS -XX:+ExplicitGCInvokesConcurrent "
export JAVA_OPTS=" $JAVA_OPTS -XX:-HeapDumpOnOutOfMemoryError "
export JAVA_OPTS=" $JAVA_OPTS -XX:HeapDumpPath=$LOG_HOME/gclog/java_pid.hprof"#JAVA_OPTS="$JAVA_OPTS -Djboss.jvmRoute=jvm1"# mod_cluster.jvmroute
#JAVA_OPTS="$JAVA_OPTS -Djboss.mod_cluster.jvmRoute=node1"# Linux Large Page Setting
#export JAVA_OPTS=" $JAVA_OPTS -XX:+UseLargePages "export JAVA_OPTS=" $JAVA_OPTS -verbose:gc"
export JAVA_OPTS=" $JAVA_OPTS -Xloggc:$LOG_HOME/gclog/gc.log"
export JAVA_OPTS=" $JAVA_OPTS -Djava.net.preferIPv4Stack=true"
export JAVA_OPTS=" $JAVA_OPTS -Dorg.jboss.resolver.warning=true"
export JAVA_OPTS=" $JAVA_OPTS -Dsun.rmi.dgc.client.gcInterval=3600000 "
export JAVA_OPTS=" $JAVA_OPTS -Dsun.rmi.dgc.server.gcInterval=3600000"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.modules.system.pkgs=org.jboss.byteman"
export JAVA_OPTS=" $JAVA_OPTS -Djava.awt.headless=true"export JAVA_OPTS=" $JAVA_OPTS -Djboss.server.base.dir=$DOMAIN_BASE/$SERVER_NAME"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.socket.binding.port-offset=$PORT_OFFSET"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.node.name=$NODE_NAME"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.bind.address.management=$MGMT_ADDR"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.bind.address=$BIND_ADDR"
#export JAVA_OPTS=" $JAVA_OPTS -Djboss.bind_addr=$MULTICAST_ADDR"
#export JAVA_OPTS=" $JAVA_OPTS -Djboss.default.jgroups.stack=tcp"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.default.multicast.address=$MULTICAST_ADDR"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.messaging.group.address=$JMS_MULTICAST_ADDR"
export JAVA_OPTS=" $JAVA_OPTS -Djboss.modcluster.multicast.address=$MODCLUSTER_MULTICAST_ADDR"export JAVA_OPTS=" $JAVA_OPTS -Dserver.mode=local"# Use log4j in application
export JAVA_OPTS=" $JAVA_OPTS -Dorg.jboss.as.logging.per-deployment=false "
export JAVA_OPTS=" $JAVA_OPTS -Djboss.server.log.dir=$LOG_HOME"echo "================================================"
echo "JBOSS_HOME=$JBOSS_HOME"
echo "DOMAIN_BASE=$DOMAIN_BASE"
echo "SERVER_NAME=$SERVER_NAME"
echo "CONFIG_FILE=$CONFIG_FILE"
echo "BIND_ADDR=$BIND_ADDR"
echo "PORT_OFFSET=$PORT_OFFSET"
echo "MULTICAST_ADDR=$MULTICAST_ADDR"
echo "CONTROLLER=$CONTROLLER_IP:$CONTROLLER_PORT"
echo "================================================"
- env.sh 수정
- Admin Console User 생성
- Standalone mode로 기동하면 Admin Console(GUI)가 Instance 상에서 기동된다.
- 계정을 아래와 같이 생성합니다.
#add-user.sh [id] [password]
!! Password가 너무 쉬운경우 생성안됨. 아래쪽 볼드체 부분이 출력되는지 꼭 확인할것 (8자이상 & 영문자 1개이상 & 특수문자1개이상 )[jboss@kwonHost standalone1]$ ./add-user.sh admin 123456a!
================================================
JBOSS_HOME=/jboss/jboss-eap-6.2
DOMAIN_BASE=/jboss/domains
SERVER_NAME=standalone1
CONFIG_FILE=standalone-ha.xml
BIND_ADDR=0.0.0.0
PORT_OFFSET=10
MULTICAST_ADDR=
CONTROLLER=127.0.0.1:10009
================================================
Added user 'admin' to file '/jboss/domains/standalone1/configuration/mgmt-users.properties'
Added user 'admin' to file '/jboss/jboss-eap-6.2/domain/configuration/mgmt-users.properties'
- 기동 스크립트 실행
/jboss/domains/standalone1/start.sh
[jboss@kwonHost standalone1]$ ./start.sh
================================================
JBOSS_HOME=/jboss/jboss-eap-6.2
DOMAIN_BASE=/jboss/domains
SERVER_NAME=standalone1
CONFIG_FILE=standalone-ha.xml
BIND_ADDR=0.0.0.0
PORT_OFFSET=10
MULTICAST_ADDR=
CONTROLLER=127.0.0.1:10009
================================================
-server -Xms256m -Xmx512m -XX:MaxPermSize=128m -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/jboss/domains/standalone1/log/gclog/gc_20140313013825.log -XX:+UseParallelGC -XX:+ExplicitGCInvokesConcurrent -XX:-HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/jboss/domains/standalone1/log/gclog/java_pid.hprof -verbose:gc -Xloggc:/jboss/domains/standalone1/log/gclog/gc.log -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djboss.server.base.dir=/jboss/domains/standalone1 -Djboss.socket.binding.port-offset=10 -Djboss.node.name=standalone1 -Djboss.bind.address.management=0.0.0.0 -Djboss.bind.address=0.0.0.0 -Djboss.default.multicast.address= -Djboss.messaging.group.address= -Djboss.modcluster.multicast.address= -Dserver.mode=local -Dorg.jboss.as.logging.per-deployment=false -Djboss.server.log.dir=/jboss/domains/standalone1/log
01:36:08,665 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://0.0.0.0:10000
01:36:08,665 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) started in 8681ms - Started 131 of 247 services (115 services are passive or on-demand)
01:38:17,163 INFO [org.apache.coyote.http11] (MSC service thread 1-1) JBWEB003075: Coyote HTTP/1.1 pausing on: http-/0.0.0.0:8090
01:38:17,164 INFO [org.apache.coyote.http11] (MSC service thread 1-1) JBWEB003077: Coyote HTTP/1.1 stopping on : http-/0.0.0.0:8090
01:38:17,281 INFO [org.apache.catalina.core] (MSC service thread 1-2) JBWEB001079: Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/] has not been started
01:38:17,270 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 54) MODCLUSTER000002: Initiating mod_cluster shutdown
01:38:17,287 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010409: Unbound data source [java:jboss/datasources/ExampleDS]
01:38:17,304 INFO [org.apache.coyote.ajp] (MSC service thread 1-2) JBWEB003048: Pausing Coyote AJP/1.3 on ajp-/0.0.0.0:8019
01:38:17,305 INFO [org.apache.coyote.ajp] (MSC service thread 1-2) JBWEB003051: Stopping Coyote AJP/1.3 on ajp-/0.0.0.0:8019
01:38:17,350 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) stopped in 160ms
nohup: redirecting stderr to stdout
01:38:26,531 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
01:38:27,096 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA-redhat-1
01:38:27,277 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) starting
01:38:27,287 DEBUG [org.jboss.as.config] (MSC service thread 1-2) Configured system properties:
SERVER = standalone1
[Standalone] =
file.encoding = UTF-8
file.encoding.pkg = sun.io
file.separator = /
java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
java.awt.headless = true
java.awt.printerjob = sun.print.PSPrinterJob
java.class.path = /jboss/jboss-eap-6.2/jboss-modules.jar
java.class.version = 50.0
java.endorsed.dirs = /jboss/jdk1.6.0_45/jre/lib/endorsed
java.ext.dirs = /jboss/jdk1.6.0_45/jre/lib/ext:/usr/java/packages/lib/ext
java.home = /jboss/jdk1.6.0_45/jre
java.io.tmpdir = /tmp
java.library.path = /jboss/jdk1.6.0_45/jre/lib/amd64/server:/jboss/jdk1.6.0_45/jre/lib/amd64:/jboss/jdk1.6.0_45/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
java.net.preferIPv4Stack = true
java.runtime.name = Java(TM) SE Runtime Environment
java.runtime.version = 1.6.0_45-b06
java.specification.name = Java Platform API Specification
java.specification.vendor = Sun Microsystems Inc.
java.specification.version = 1.6
java.util.logging.manager = org.jboss.logmanager.LogManager
java.vendor = Sun Microsystems Inc.
java.vendor.url = http://java.sun.com/
java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi
java.version = 1.6.0_45
java.vm.info = mixed mode
java.vm.name = Java HotSpot(TM) 64-Bit Server VM
java.vm.specification.name = Java Virtual Machine Specification
java.vm.specification.vendor = Sun Microsystems Inc.
java.vm.specification.version = 1.0
java.vm.vendor = Sun Microsystems Inc.
java.vm.version = 20.45-b01
javax.management.builder.initial = org.jboss.as.jmx.PluggableMBeanServerBuilder
javax.xml.datatype.DatatypeFactory = __redirected.__DatatypeFactory
javax.xml.parsers.DocumentBuilderFactory = __redirected.__DocumentBuilderFactory
javax.xml.parsers.SAXParserFactory = __redirected.__SAXParserFactory
javax.xml.stream.XMLEventFactory = __redirected.__XMLEventFactory
javax.xml.stream.XMLInputFactory = __redirected.__XMLInputFactory
javax.xml.stream.XMLOutputFactory = __redirected.__XMLOutputFactory
javax.xml.transform.TransformerFactory = __redirected.__TransformerFactory
javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema = __redirected.__SchemaFactory
javax.xml.xpath.XPathFactory:http://java.sun.com/jaxp/xpath/dom = __redirected.__XPathFactory
jboss.bind.address = 0.0.0.0
jboss.bind.address.management = 0.0.0.0
jboss.default.multicast.address =
jboss.home.dir = /jboss/jboss-eap-6.2
jboss.host.name = kwonhost
jboss.messaging.group.address =
jboss.modcluster.multicast.address =
jboss.modules.dir = /jboss/jboss-eap-6.2/modules
jboss.modules.system.pkgs = org.jboss.byteman
jboss.node.name = standalone1
jboss.qualified.host.name = kwonhost
jboss.server.base.dir = /jboss/domains/standalone1
jboss.server.config.dir = /jboss/domains/standalone1/configuration
jboss.server.data.dir = /jboss/domains/standalone1/data
jboss.server.deploy.dir = /jboss/domains/standalone1/data/content
jboss.server.log.dir = /jboss/domains/standalone1/log
jboss.server.name = kwonhost
jboss.server.persist.config = true
jboss.server.temp.dir = /jboss/domains/standalone1/tmp
jboss.socket.binding.port-offset = 10
line.separator =logging.configuration = file:/jboss/domains/standalone1/configuration/logging.properties
module.path = /jboss/jboss-eap-6.2/modules:/jboss/jboss-eap-6.2/modules.ext
org.apache.catalina.connector.URI_ENCODING = UTF-8
org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING = true
org.apache.coyote.ajp.DEFAULT_CONNECTION_TIMEOUT = 60000
org.apache.coyote.http11.DEFAULT_CONNECTION_TIMEOUT = 60000
org.apache.coyote.http11.Http11Protocol.MAX_HEADER_SIZE = 8192
org.jboss.as.logging.per-deployment = false
org.jboss.boot.log.file = /jboss/domains/standalone1/log/server.log
org.jboss.resolver.warning = true
org.xml.sax.driver = __redirected.__XMLReaderFactory
os.arch = amd64
os.name = Linux
os.version = 2.6.32-431.el6.x86_64
path.separator = :
server.mode = local
sun.arch.data.model = 64
sun.boot.class.path = /jboss/jdk1.6.0_45/jre/lib/resources.jar:/jboss/jdk1.6.0_45/jre/lib/rt.jar:/jboss/jdk1.6.0_45/jre/lib/sunrsasign.jar:/jboss/jdk1.6.0_45/jre/lib/jsse.jar:/jboss/jdk1.6.0_45/jre/lib/jce.jar:/jboss/jdk1.6.0_45/jre/lib/charsets.jar:/jboss/jdk1.6.0_45/jre/lib/modules/jdk.boot.jar:/jboss/jdk1.6.0_45/jre/classes
sun.boot.library.path = /jboss/jdk1.6.0_45/jre/lib/amd64
sun.cpu.endian = little
sun.cpu.isalist =
sun.io.unicode.encoding = UnicodeLittle
sun.java.command = /jboss/jboss-eap-6.2/jboss-modules.jar -mp /jboss/jboss-eap-6.2/modules:/jboss/jboss-eap-6.2/modules.ext -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -Djboss.home.dir=/jboss/jboss-eap-6.2 -Djboss.server.base.dir=/jboss/domains/standalone1 -DSERVER=standalone1 -P=/jboss/domains/standalone1/env.properties -c standalone-ha.xml
sun.java.launcher = SUN_STANDARD
sun.jnu.encoding = UTF-8
sun.management.compiler = HotSpot 64-Bit Tiered Compilers
sun.os.patch.level = unknown
sun.rmi.dgc.client.gcInterval = 3600000
sun.rmi.dgc.server.gcInterval = 3600000
user.country = KR
user.dir = /jboss/domains/standalone1
user.home = /jboss
user.language = ko
user.name = jboss
user.timezone = ROK
01:38:27,293 DEBUG [org.jboss.as.config] (MSC service thread 1-2) VM Arguments: -D[Standalone] -XX:+UseCompressedOops -Xms256m -Xmx512m -XX:MaxPermSize=128m -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/jboss/domains/standalone1/log/gclog/gc_20140313013825.log -XX:+UseParallelGC -XX:+ExplicitGCInvokesConcurrent -XX:-HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/jboss/domains/standalone1/log/gclog/java_pid.hprof -verbose:gc -Xloggc:/jboss/domains/standalone1/log/gclog/gc.log -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djboss.server.base.dir=/jboss/domains/standalone1 -Djboss.socket.binding.port-offset=10 -Djboss.node.name=standalone1 -Djboss.bind.address.management=0.0.0.0 -Djboss.bind.address=0.0.0.0 -Djboss.default.multicast.address= -Djboss.messaging.group.address= -Djboss.modcluster.multicast.address= -Dserver.mode=local -Dorg.jboss.as.logging.per-deployment=false -Djboss.server.log.dir=/jboss/domains/standalone1/log -Dorg.jboss.boot.log.file=/jboss/domains/standalone1/log/server.log -Dlogging.configuration=file:/jboss/domains/standalone1/configuration/logging.properties
01:38:29,941 INFO [org.xnio] (MSC service thread 1-1) XNIO Version 3.0.7.GA-redhat-1
01:38:29,960 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
01:38:29,962 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.0.7.GA-redhat-1
01:38:29,988 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 3.2.18.GA-redhat-1
01:38:30,037 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
("socket-binding-group" => "standard-sockets"),
("socket-binding" => "jgroups-mping")
]) - failure description: "JBAS014704: '' is an invalid value for parameter multicast-address. Values must have a minimum length of 1 characters"
01:38:30,042 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
("socket-binding-group" => "standard-sockets"),
("socket-binding" => "jgroups-udp")
]) - failure description: "JBAS014704: '' is an invalid value for parameter multicast-address. Values must have a minimum length of 1 characters"
01:38:30,094 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 31) JBAS010280: Activating Infinispan subsystem.
01:38:30,116 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 35) JBAS010260: Activating JGroups subsystem.
01:38:30,186 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 41) JBAS011800: Activating Naming Subsystem
01:38:30,169 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 38) JBAS012605: Activated the following JSF Implementations: [main, 1.2]
01:38:30,247 INFO [org.jboss.as.security] (ServerService Thread Pool -- 46) JBAS013171: Activating Security Subsystem
01:38:30,300 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 50) JBAS015537: Activating WebServices Extension
01:38:30,548 INFO [org.jboss.as.connector.logging] (MSC service thread 1-2) JBAS010408: Starting JCA Subsystem (IronJacamar 1.0.23.Final-redhat-1)
01:38:30,664 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 27) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
01:38:30,718 INFO [org.jboss.as.naming] (MSC service thread 1-2) JBAS011802: Starting Naming Service
01:38:30,722 INFO [org.jboss.as.security] (MSC service thread 1-1) JBAS013170: Current PicketBox version=4.0.19.SP2-redhat-1
01:38:30,980 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) JBAS015400: Bound mail session [java:jboss/mail/Default]
01:38:31,580 INFO [org.apache.coyote.ajp] (MSC service thread 1-1) JBWEB003046: Starting Coyote AJP/1.3 on ajp-/0.0.0.0:8019
01:38:31,573 INFO [org.apache.coyote.http11] (MSC service thread 1-2) JBWEB003001: Coyote HTTP/1.1 initializing on : http-/0.0.0.0:8090
01:38:31,598 INFO [org.apache.coyote.http11] (MSC service thread 1-2) JBWEB003000: Coyote HTTP/1.1 starting on: http-/0.0.0.0:8090
01:38:32,134 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 52) MODCLUSTER000001: Initializing mod_cluster ${project.version}
01:38:32,297 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 52) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
01:38:32,395 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 31) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
01:38:32,504 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 31) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
01:38:33,038 INFO [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.2.3.Final-redhat-1
01:38:33,397 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
01:38:33,755 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 0.0.0.0:10009
01:38:33,820 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) JBAS015012: Started FileSystemDeploymentService for directory /jboss/domains/standalone1/deployments
01:38:33,828 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 0.0.0.0:4457
01:38:34,177 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://0.0.0.0:10000/management
01:38:34,178 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://0.0.0.0:10000
01:38:34,182 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) started in 8244ms - Started 131 of 247 services (115 services are passive or on-demand) - 확인
- 웹 콘솔에 접속
- 서비스 포트에 접속
- JDK 설치
여기 까지 했다면
2014년 3월 12일 수요일
EAP6 Domain 구성으로 설치
- 용어정의 (이 문서를 볼때 참조)
- EAP : Enterprise Application Platform 라고 쓰고 제이보스 와스라고 한다.
- AP : EAP의 커뮤니티버젼 (지원 없음, 무료로 사용하는 버젼)
- EWS : Enterprise Web Server 라고 쓰고 제이보스 웹서버 라고 한다. 내부적으로 Apache + HA가 제거된 tomcat 과 Proxy Module이 공식적으로 제공된다.
- Master = DomainController = Admin Server : 도메인내의 slave들과 통신하면서 통합 관리함 (설치는 임의의 서버 한곳에 구성, 필요시 HA 구성 가능함)
- Slave = HostController : 서버 벌로 구성되며 상위 Master와 통신하며 하위 Server들을 관리한다. (Production의 경우 일반적으로 서버당 하나)
- server = Instance : 실제 WAS 서비스를 제공하는 Process
- proxy module : web Server에 인입된 사용자 요청을 WAS에 LoadBalance(LB) 하거나 WAS 장애시 Fail Over 하는 기능을 담당하는 모듈(mod_jk, mod_proxy, mod_cluster)을 통칭
- 설치준비
- EAP6 설치본
- jboss ORG http://www.jboss.org/products/eap ) org에서도 EAP 버젼 다운로드 가능함, 로그인 필요
- Redhat https://access.redhat.com/site/downloads/ (파트너사 사이트)
- Domain, Std 용 스크립트
- JDK 1.6 또는 1.7 (http://www.oracle.com/technetwork/java/index.html)
- 설치순서
- JDK 설치
- 알아서 잘....
- 알아서 잘....
- EAP 압축해제 (/jboss/jboss-eap-6.2)
#unzip jboss-eap-6.2.0.zip - 2.3 Domain 폴더 복사 (DomainController와 HostContoller 껍대기 만들기)
- 도메인 정보를 구성할 폴더, 필요하면 협의해서 임의지정
#mkdir /jboss/domains - 설치본에 있는 Template 폴더(/jboss/jboss-eap-6.2/domain)를 복사하여 필요한만큼 생성한다.
#cp -R /jboss/jboss-eap-6.2/domain /jboss/domains/master (Domain Controller이므로 Domain중 1개만 구성한다. HA가능)
#cp -R /jboss/jboss-eap-6.2/domain /jboss/domains/slave (HostController 는 서버당 1개씩 구성한다.) - 구동 정지및 모니터링을 위한 쉡 스크립트(rockplace 자체제작)를 복사하여 넣는다
스크립트에 실행권한 추가
#chmod +x /jboss/EAP6_Domain_Script/master/*
#chmod +x /jboss/EAP6_Domain_Script/slave/* - master 폴더의 스크립트 : domain Cotroller용으로 사전준비된 스크립트
slave 폴더의 스크립트 : Managed Server용으로 사전준비된 스크립트
stendalone 폴더의 스크립트 : Domain이 구성없이 단독 서버 구성용으로 사전준비된 스크립트
#cp /jboss/EAP6_Domain_Script/master/* /jboss/domain/master
#cp /jboss/EAP6_Domain_Script/slave/* /jboss/domains/slave - 로그가 저장될 공간을 만들어준다. 폴더가 없으면 쌓이지 않는다. (스크립트 개선필요)
cd /jboss/domains/master
mkdir -p ./log/controllerlog
mkdir -p ./log/gclog
- 도메인 정보를 구성할 폴더, 필요하면 협의해서 임의지정
- 2.4 Master(DomainController) 구성
- 2.4.1 Domain env.sh 수정
env.sh는 domain.xml 및 host-master.xml에 분산된 설정정보를 환경변수에 넣어주는 역할을 한다.
여기저기 흩어진 config를 하나의 환경변수에서 수정함으로써 관리편의를 높이기 위해서이다.
domain.xml에 정의 되어 있더라도 java -D 옵션으로 추가되는 env.sh의 정보가 우선순위가 높다.
ex : setenv.sh HOST_NAME 은 host-master.xml 의 <host name="master" xmlns="urn:jboss:domain:1.5"> 에서 name attr에 대응된다.
Jboss 기동시 환경변수를 지정하는곳이다. JDK 및 Master 또는 Slave Config 위치등을 지정한다.
/jboss/domains/master/env.sh
- 2.4.2 Admin 계정 생성 (Admin Console에 접속하기 전에 꼭 계정을 만들고 접속한다.)
- Console 접속용 Admin 계정을 생성한다. 복사해 넣은 관리 스크립트 중에서 add-user.sh를 사용하면된다.#add-user.sh [id] [password]
- !! Password가 너무 쉬운경우 생성안됨. 아래쪽 볼드체 부분이 출력되는지 꼭 확인할것
- MASTER(Domain Controller) 구동 및 접속확인
- /jboss/domains/master/start.sh 수행아래는 정상로그 출력
- 접속확인
http://192.168.56.101:9990/ (아래 로그인 창 안나오고 welcom 화면 나오면 계정이 없는것이므로 계정을 추가한다.) - 정상 로그인 화면
- 2.5 Slave 설정
- 2.5.1 slave env.sh 수정
/jboss/domains/slave/env.sh - DomainController(Master)의 env.sh와 거의 유사하나 조금다르다 볼드 부분주의
- 2.5.1 slave env.sh 수정
- JDK 설치
다 되었음
띄우고 Admin Console에서 서버들의 정보가 정상적으로 올라오는지 확인
아래 보면
Master(Domain Controller)
kwonhost(Host Controller) : 구성시 jboss.host.name 속성 (domains/master/configuration/host-master.xml 의 host Element) 이 없으면 OS $HOSTNAME을 들고 올라온다. 필요시 지정(스크립트에서 지정하도록 변경 예정임)
server-one(Instance) : 초기 제공되는 Config 파일에 sample로 등록되어 있는 Instance 삭제해도 무방하다
server-two(Instance) : 초기 제공되는 Config 파일에 sample로 등록되어 있는 Instance 삭제해도 무방하다
가 구성된 것을 확인할 수 있다.
끝.
피드 구독하기:
글 (Atom)