Tagged: 리눅스

Nginx KeepAlive

Nginx 에서 KeepAlive 관련된 설정은 다음과 같이 세가지이다.

  • keepalive_disable
  • keepalive_timeout
  • keepalive_requests

먼저, Keepalive 는 HTTP 와 TCP 상에서 구현되어 있다. HTTP 의 경우에는 1.0 버전과 1.1 버전이 존재하는데, 1.0 버전에서는 KeepAlive 는 존재하지 않으며 1.1 에서는 연결시에 기본으로 KeepAlive 가 활성화 된다.

HTTP 는 “Connetionless” 방법을 취한다. 웹 컨텐츠를 전송 받기 위해서 서버에 연결을 한 후에 데이터를 전송받는다. 그리고는 연결을 바로 끊게 된다. 하지만 웹이라는게 HTML, Javascript, CSS, Image 파일등으로 수백개로 이루어진 상태에서 수백의 컨텐츠를 전송하기위해서 연결을 수백번을 한다면 비 효율적일 것이다. 그래서 한번의 연결로 수십개의 컨텐츠를 전송하도록 해주는것이 KeepAlive 이다.

그렇다면 의문이 들 것이다. KeepAlive 를 켜주기만할 것이지 왜 timout, request 와같은 설정이 필요한 것일까?

답은 네트워크 상황이 좋지 않을때에 나타난다. 만약 KeepAlive 연결이 된상태에서 데이터 전송에 문제가 생겼을 경우 또는 Client 에서 데이터 전송을 하지 않을 경우에 이 연결된 접속은 어떻게 해야 할까? Server 접속 자원은 무한정이 아니기에 이러한 접속을 계속 유지되는 것은 Server 에 막대한 손실을 발생시키고 이는 곧 접속 장애로 이어진다.

그래서 접속이 이루어진 후에 컨텐츠를 전송받은후에 얼마간 또 다시 컨텐츠 전송 요청이 없다면 Server 가 접속을 차단시키도록 해야하는데 이것이바로 keepalive_timeout 이다. 다시말해 처음 접속이 이루어지고 컨텐츠를 한번 전송한 이후에 타이머를 실행시켜서 timeout 시간까지 Client 가 컨텐츠 요청이 없다면 Server는 접속을 차단하게 된다.

keepalive_request 는 Server 에 접속이 이루어진 이후에 컨텐츠를 요청한 갯수를 계산하고 이값을 넘으면 접속을 차단하는 것이다.

이렇게 접속이 차단되면 다음 번 컨텐츠 요청을 위해선느 새로운 접속이 이루어져야 한다.

그렇다면, Nginx 에서는 어떻게 이것을 다룰까? 이를 위해서는 먼저 Nginx 를 debug 모드가 활성화 되도록 컴파일 설치해야 한다.

그리고 다음과 같이 error_log 에 debug 를 활성화 해줍니다.

keepalive_timeout  설정을 5초로 해줍니다.

이렇게해서 nginx 를 실행하고 error.log 파일을 보면 nginx 가 처리하는 과정을 상세히 볼 수 가 있다.

이와 더불어 HTTP 연결 테스트는 Telnet 을 이용하면 된다. 테스트는 다음과 같이 진행하면 된다.

마지막에 “Connection close by foreign host.” 메시지는 5초동안 아무런 요청이 없으면 나타나는데 이는 keepalive_timeout 설정된 값과 같다. 만일 5초가 지나기 전에 또 한번에 데이터 요청을 Server 에 보낸다면 keepalive_timeout 은 reset 되고 전송이 끝난후에 다시 타이머가  흐르기 시작한다.

이는 keepalive_timout 에 대해서 데이터 전송이 끝난 후에 다시 데이터 전송 요청때까지의 갭타임을 의미하기도 한다. 그 사이에 데이터 전송 요청이 없다면 Server 가 접속을 차단하게 된다.

위 실험에서 Nginx는 과연 어떻게 처리했을까? 로그에는 아주 많은 정보가 표시되는데, 전송이 모두 끝난후에 다음과 같은 로그가 보인다.

Nginx 에서 timout 관련 설정은 거의 대부분 내부적으로 timer 로 처리 된다. Nginx 의 I/O Multiplexer 는 epoll 이기 때문에 내부적으로 epoll_wait 에 timer 가 전달되어 처리되는 구조다.

그리고 각각의 timeout 들은 내부적으로 처리하는 handler 가 존재해 처리된다. 각각의 handler 들은 timer 를 체크하고 close_connection 을 호출하는 방식으로 접속을 차단하도록 구현되어 있다.

“http keepalive handler” 는 ngx_http_request.c 에 구현되어 있다.

 

[번역]레디스 슬레이브에서 “놓쳐버린” 키들.

이 문서는 다음의 글을 번역한 것입니다.

레디스 슬레이브에서 “놓쳐버린” 키들.

만약 당신이 레디스(Redis)에서 만료중인 키를(expiring key)(“임시적인 키”로 알려진) 사용하고 있다면, 당신은 레디스 마스터에서 새로운 슬레이브(Slave)를 붙였을때에 놀랄 수도 있습니다. 슬레이브에서 키 갯수(key count)가 마스터에서 키 갯수보다 약 25%정도 낮을 것입니다. 이것은 임시적인 키(volatile key)가 아주 많다면 특별하게도 정상적인 것입니다.

Redis Master-Slave

레디스 슬레이브가 키를 놓쳐버린 걸까? 단순하게 데이터를 잃어버린 걸까? 결론부터 말하자면 “아니오” 입니다. 그러나, 왜그런지 이해하길 희망하면서, 레디스 슬레이브가 어떠한 데이터도 잃어버리지도 않았는데도 더 적은 키 갯수를 보고합니다. 이것은 두가지 세세한 구현으로부터 발생됩니다: 어떻게 레디스는 키를 만료시키고 어떻게 레디스 마스터는 새로운 슬레이브에게 데이터셋(dataset)을 보내는지하는 것

어떻게 레디스는 임시적인 키들을 만료시킬까?

레디스는 임시적인 키들(volatile keys)을 만료로 지정한 순간에 메모리로부터 삭제를 하지 않습니다. 대신에, 그들은 두가지 방법중에 하나로 삭제를 합니다.

  1. 레디스 클라이언트가 키에 읽고 쓰기 연산을 수행할때에, 레디스 서버는 첫번재로 키가 존재하고 만료 시간을 가지고 있는지를 체크 합니다. 만약 키가 존재하고 만료시간이 지난 키라면 레디스는 즉시 명령어를 처리하기 전에 메모리로부터 키를 삭제합니다.
  2. 접근이 더 이상 없는 키의 경우 메모리에 임시적인 키가 영구적으로 남아있는 것을 방지하기 위해서 레디스는 만료 키를 위해서 단순한 패시브 알고리즘을 사용합니다: 매 10ms, 100개의 랜덤으로 임시적인 키들을 추출하고 즉각 만료가 지난 모든 키들을 삭제처리합니다. 만약 25% 혹은 그 이상의 키들이 삭제되었다면, 레디스는 즉각 다른 100개의 키를 추출하고 같은 일을 반복합니다.

위의 두번째 방법은 매우 중요한데, 키의 25% 이상이 이미 만료된 임시적인 키(메모리에서 아직 삭제가 되지 않은) 될 수 있다는 것을 의미한다. 레디스는 삭제되때까지 INFO 에 “keys”와 “expires”에 이러한 키들을 계속 포함시킬 것입니다.

어떻게 레디스는 새로운 슬레이브에 데이터셋을 보낼까?

레디스 슬레이브가 레디스 마스터에 붙었을때에, 마스터 서버는 그들의 데이터셋의 RDB 스냅샷을 생성하고 그것을 슬레이브로 보냅니다. 이때 레디스는 RDB 스냅샷을 생성할때에 아직 메모리에 남아있다 할지라도 이미 만료시간이 지난 키들은 포함하지 않습니다.

그래서, 왜 나의 슬레이브의 키 갯수는 마스터의 키 갯수보다 적을까?

슬레이브가 마스터 인스턴스에 붙으면, 슬레이브는 메모리에서 삭제되지는 않았지만 만료된 임시적인 키들을 포함하지 않은 데이터셋을 받습니다. 그리고 25% 이상의 키는 메모리에서 아직 삭제되지 않았지만 만료된 키일 수 있기 때문에 슬레이브는 마스터의 25% 이상 더 적은 키를 보여줄 것입니다. 덧붙여서, 이것은 모든 키가 없어져서 RDB 백업으로 레디스 서버를 복구할때에도 똑같은 일이 벌어집니다.

Redis 운영에 필요한 잡지식들.

Redis 는 In memory 기반으로 동작하기 때문에 메모리 관리가 매우 중요한데, 먼저 리눅스에 메모리 관리를 Redis 운영에 적합하도록 설정하는 것이 좋다.

먼저 Redis 는 Swap 을 사용하지 않고 물리 메모리 내에서만 운영하는 환경이다.

가상 메모리 overcommit 에 대해서 2 로 설정하는 것이 좋다. 2로 설정하게 되면 리눅스가 사용가능한 메모리는 다음과 같이 계산한다.

예를들어 32GB 물리 메모리를 가지고 있고 overcommit_ratio 가 50%라면  16GB 물리 메모리만 사용하게 된다. 그래서 overcommit_ratio 를 99% 로 설정을하면 모든 메모리를 사용하게 된다.

swappiness 는 0 ~ 100 사이에 값을 가진다. 0에 가까우면 메모리의 dirty page 가 있다고 하더라도 최대한 swap 을 하지 않지만 100에 가까우면 조금만 dirty page 가 있으면 swap 을 한다. Redis 를 물리 메모리만 사용하게끔 하고 싶다면 swappiness 를 0 으로 하는게 좋다.

Redis 의 save 옵션&&maxmemory-policy

Redis 는 메모리의 내용을 디스크로 보관하도록 하는 옵션이 여럿 있다. 그중에 save 옵션이 존재하는데, 다음과 같다.

위 두 조건중에 하나만 만족되도 Redis 는 메모리에 내용을 디스크에 쓰게된다. 만약, Redis 를 운영하는동안 위 조건을 하나도 만족하지 못한다면 디스크로 전혀 쓰는 행위가 발생하지 않게되고 maxmemory 에 닫게 되는 상황에서 maxmemory-policy 가 volatie-lru 로 되어 있다면 다음과 같은 상황에 직면하게 된다.

위 오류는 랜덤으로 key-value 를 생성해서 무한 set 을 돌린 결과 이다. maxmemory 는 512MB 였는데, expire 되는 key 가 하나도 없어 메모리는 항상 차게되어 있고 결국에는 더 이상 사용할 메모리가 없자 오류가 난 것이다.

이는 프로그램 운영 상으로도 매우 심각한 문제가 된다. Redis 는 ‘evicted_keys’ 가 존재하는데 보통은 메모리 부족현상으로 발생되는 거라고 생각한다. 그래서 메모리가 부족하면 evicted_key 만 나오고 프로그램은 예외가 발생하지 않을 거라고 생각한다.

evicted_keys 도 증가했지만 예외상황을 맞을수도 있다.

그렇다면 maxmemory-plicy 가 allkeys-lru 되어 있다면 어떻게 될까? 결론부터말하면 프로그램은 예외를 발생할 확률이 줄어든다. 예외를 발생시킬 수도 있지만 안될 확률이 높다. 프로그램은 잘동작하는 것처럼 보이지만 Redis 는 evicted 를 발생시키고 있다. 따라서 evicted_key 가 증가하는 현상이 보인다면 maxmemory 값을 늘려주는게 좋다.

bgsave 는 slave 와 접속을 차단한다. replication 은 SYNC 는 BGSAVE 를 발생시킨다.

먼저, 구분되어야 할게 있다. Master<->Slave 간의 replication 상태에서 데이터는 전송되지 않는다. 무슨 말이냐하면 Master 발생되는 명령어들을 그대로 Slave 에 던지는 방법이다. “set myhello ‘Hello'” 라는 명령어를 Master 에서 했다면 Slave 도 똑같은 명령어가 전달되지 데이터가 전달되지 않는다.

용어의 차이일 수 있는데, SYNC 시에는  slave 에게 데이터를 전송하기에 앞서 disk 에 rdb  파일을 생성한다. replication.c 에 다음과 같은 내용을 볼 수 있다.

rdb 파일은 백그라운드 프로세스를 생성시키고 rdb_filename 파일에 저장한다. 문제는 이러한 일이 벌어지는 동안에 접속은 차단된다.

closeListeningSockets 함수는 TCP/IP 접속 소켓을 닫게 된다.

결국 BGSAVE 가 발생하는동안 slave 접속은 차단된다. 그리고 다시 접속이 이루어지면 Full Sync 가 발생된다. 정리를하면 현재 Replication 이 된 상태라면 Sync 를 위해서 rdb  덤프는 발생되지 않는다. 하지만 새롭게 Replication 이 맺어지면 그때에는 Master 가 rdb 덤프를 하고 그리고 나서 데이터를 전송하게 된다. 실제로 새로운 Replication 이 맺어지면 파일 덤프가 다음과 같이 발생한다.

temp-5594.rdb 임시파일을 생성하고 나서 rdb_filename 으로 변경한다. Replication 상태에서 rdb 검프는 SYNC 에만 발생한다.

그런데, Redis 는 slave 가 잠시동안 접속이 차단될때에 Full Sync 가 발생하지 않도록 repl-backlog-size 에 복제를 위한 데이터를 저장해둔다. 주의해야할 것은 이 크기는 메모리 크기를 말하는 것으로 디스크에 데이터를 저장하지 않는다.

여기서 또 짚고 넘어가야할 것은 repl-backlog-size 가 작아서 runtime 으로 크기를 변경해주면 기존의 데이터는 다 지워지고 새로운 크기의 backlog 가 할당되는 방식을 취한다.

 

Redis 를 운영할때에 Master-Slave 로 운영한다면 모든 것을 메모리로만 운영할 수는 없다. Slave 로 Replication 을 할때마다 BGSAVE 가 발생하고 이는 일시적으로 Slave 와의 접속을 차단하기 때문이다. Slave 와의 접속이 차단된 후에 다시 연결이 되었을 경우에 Full Sync 가 발생할 수 있다.

diskless 를 통한 slave sync

이는 사실상 트릭같다. disk sync 은 Master 가 bgsave 로 메모리에 데이터를 점프한 후에 그것을 slave 로 전송하는 방법이다. bgsave 가 작동하게 되면 slave 와의 연결은 잠정적으로 끊어지게 된다.

하지만 disklee sync 는 bgsave 가 동작하지 않으며 Master 가 아닌 Slave 가 Master 로부터 메모리의 내용을 전송받아 덤프 파일을 생성한 후에 이것을 메모리에 올리는 방식이다. Master 로부터 Slave 가 데이터를 전송받을때, Master 는 “redis-rdb-to-slaves *:6379” 프로세스가 생성돼 전송을 담당한다. Slave 에서는 전송된 데이터를 파일로 저장하기위해서 별도의 프로세스는 작동하지 않는다.

Master의 메모리 내용을 Slave 가 덤프 받는 방식이 diskless sync 이며 수십기가의 메모리 내용을 전송해야하기 때문에 네트워크 상태가 좋아야 한다.

tomcat jmx 소스

JMX 소스

 

Redis 설치하기

redis

 

Redis 는 Key-Value 로 데이터를 저장하는 NoSQL 서버 입니다. In Memory 기반으로 동작하기 때문에 빠른 응답속도를 보입니다.

이 문서는 Redis 설치에 관한 문서 입니다.

다운로드

의존성 패키지 설치

CentOS 의 경우에는 다음과 같이 설치를 해줍니다.

Ubuntu 의 경우에는 다음과 같이 설치를 해줍니다.

컴파일

설치

설치는 PREFIX 를 인자로 줘서 설치 디렉토리 위치를 지정해줄 수 있습니다.

Redis 의 설치는 오로지 실행파일들만 복사해 줍니다.

설정

Redis 는 설치 후에 각종 설정을 할 수 있도록 스크립트를 지원 합니다. 이 스크립트를 사용하면 각종 설정파일들을 복사해 줍니다. 이 스크립트는 utils 디렉토리에 존재 합니다.

자세히 보면 initscript 까지 설정을 해주고 실행까지 해줍니다. 설정파일 하나하나 복사해줄 이유가 없습니다.

 

JMX 로 Tomcat 모니터링 하기.

tomcat

톰캣(Tomcat)은 JEE의 Web Container 의 구현에 입니다. 흔히 WAS 서버라고 하죠. 많은 기능이 있지만 이번에는 JMX를 설정하고 이를 이용해서 Tomcat 을 모니터링 해보겠습니다.

JMX는 Java Management eXtension 으로 자바 서비스들을 관리하고 모니터링하기위한 API를 제공하는 기능을 포함하는 기술입니다. Tomcat 오 자바 서비스의 일종임으로 JMX를 이용할 수 있습니다.

톰캣(Tomcat)의 경우에 아쉽게도 기본 배포본에 이를 위한 라이브러리가 포함되어 있지않아 이 기능을 이용하기 위해서는 톰캣용 JMX 라이브러리를 다운받고 톰캣을 재시작 해줘야 합니다.

이 파일을 톰캣(Tomcat) 라이브러리 디렉토리인 lib 에 넣어줍니다.

그리고 톰캣(Tomcat)시작 스크립트에 다음과 같이 JMX 파라메터를 넣어줍니다.

여기서 주의해야할 것은 ‘192.168.96.6’ IP주소는 실제 톰캣(Tomcat)서버가 동작하는 서버의 IP주소로 바꿔야 한다는 것입니다.

그리고 다음과 같이 server.xml 파일에서 Server 섹션에 JMX 설정을 해줍니다.

이렇게 한다음에 톰캣(Tomcat)을 재시작해주면 됩니다.

JMX 는 위 server.xml 설정에서 정의한 두가지 포트를 사용합니다. 여기서는 9180, 9181이 그렇습니다. 리눅스, 윈도우즈 서버라면 반드시 방화벽에서 위 포트를 허용하는 것을 잊지 말아야 합니다.

이제 자바가 설치된 컴퓨터에서 jconsole 을 실행해서 ‘JMX서버아이피주소:9180’ 으로 접속을 시도합니다.(설정에서 인증을 빼버렸기 때문에 아이디/패스워드를 입력할 필요가 없습니다.)

jconsole접속을 완료하면 다음과 같이 192.168.96.6 에서 동작하는 톰캣(Tomcat)서버를 모니터링하고 관리할 수 있게 됩니다.

JMX

Cassandra 2.1.2 설치하기.

Cassandra 로고

 

카산드라(Cassandra)는 분산 데이터 스토리지 시스템 입니다. 아파치 재단에서 오픈소스로 만들어 배포하고 있고, 자바기반으로 제작되었습니다. peer to peer 프로토콜을 이용한 고가용성이 구현되어 있습니다.

이 문서는 카산드라(Cassandra) 2.1.2 에 싱글(Single) 노드를 위한 설치에 대한 것입니다. 설치환경은 CentOS 입니다.

jdk 7 update 75

카산드라(Cassandra) 2.1.2 는 jdk 7 update 75 버전 이상을 필요로 합니다. 만일 idk 버전 이하를 사용한다면 시작스크립트에서 오류를 내며 작동하지 않습니다. Oracle 홈페이지에서 jdk 7 update 75 를 다운받아 다음과 같이 압축을 해제합니다.

카산드라(Cassandra) 2.1.2 설치

카산드라(Cassandra) 는 리눅스의 슈퍼유저인 root 로 실행할 필요가 없습니다. 카산드라(Cassandra) 를 운영하기 위한 시스템 계정을 만들고 그 시스템 계정으로 운영하면 됩니다.

카산드라(Cassandra) 2.1.2 는 홈페이지에서 다운로드 받을 수 있습니다.

다운로드: 카산드라(Cassandra) 2.1.2

설치는 별도의 진행이 필요 없이 압축을 해제하면 됩니다.

이제 카산드라(Cassandra) 에서 사용할 디렉토리를 생성해야 합니다. 필요한 디렉토리는 다음과 같습니다.

  • data_file_directories: /home/cassandra/data
  • commitlog_directory: /home/cassandra/commitlog
  • saved_caches_directory: /home/cassandra/saved_caches

카산드라(Cassandra) 에서 위 디렉토리를 설정하기 위해서 설정파일을 편집해 줍니다.

시작 스크립트

jdk 7 update 75 에 대해 시스템 java 설정을 해주면 별도로 필요가 없지만 카산드라(Cassandra) 에서만 쓰게 하기위해서는 시작스크립트를 작성하고 jdk 7 update 75 를 인식시켜줘야 합니다.

top 사용시 command 매칭된것만 보기.

top 은 리눅스에서 아주 유용한 시스템 모니터링 툴 입니다. 매우 많은 옵션도 제공하는데, 그중에서 프로세스의 명령어와 매칭되는 것만 보여주기도 한다. -c 옵션이 그것인데, 다음과 같이 pgrep 과 조합해서 사용할 수 있다.

 

Tomcat Multi Instance 설정하기

Tomcat 7 서버는 Multi Instance 라는 기능을 가지고 있습니다. 하나의 엔진에 다수의 Instance 를 구동하게하는 것을 말합니다.

Tomcat 7 용어 정리

Tomcat Multi Instance 설정하기 전에 용어를 설명하겠습니다. Tomcat 은 엔진과 인스턴스(Intance) 로 나뉩니다. 이는 디렉토리별로 구분이 가능한데, 엔진부분과 인스턴스 부분의 디렉토리는 다음과 같습니다.

  • Tomcat Engine 부분: bin, lib
  • Tomcat Instance 부분: conf, logs, temp, work, webapps

사실 Tomcat 을 다운받아 압축을 해제하면 엔진부분과 인스턴스부분이 함께 들어 있기 때문에 별 구별이 안되는 측면이 있지만 엄밀히 따지면 위와같이 구분을 할 수 있습니다.

사실 Tomcat 엔진은 아무것도 아닙니다. Tomcat 엔진은 실제로 단독으로 구동되지 않습니다. Tomcat 엔진의 역활은 자바 소프트웨어를 실행시켜주는 역활만 담당합니다. 여기서 자바 소프트웨어라는 것이 바로 Tomcat 인스턴스 입니다.

Tomcat 엔진이 자바 소프트웨어를 실행시킨다는 말은 결국에는 JVM 이 작동하는 것입니다. 따라서 Tomcat 인스턴스는 JVM 이 구동된다는 것이며 Multi Instance 는 여러개의 Tomcat JVM 을 구동한다는 것을 의미 합니다.

Tomcat 구동

Tomcat  이 구동될때에는 시스템 환경변수에 의존 합니다.  bin/startup.sh 스크립트는 Tomcat 을 구동되도록하는 스크립트인데, 이 스크립트는 환경변수를 세팅하고 catalina.sh 스크립트를 호출하는 역활을 합니다. 실제 실행하면 환경변수내용을 볼수 있습니다.

먼저, Tomcat 엔진은 CATALINA_HOME 환경변수만 세팅합니다. 이는 Tomcat 엔진의 기본 디렉토리를 정의하는 것으로 Tomcat 의 바이너리 파일과 라이브러리가 어디에 있는지를 지정해 주는 것입니다.

CATALINA_BASE 는 Tomcat 인스턴스의 설정과 웹애플리케이션의 루트(Root) 디렉토리를 정의 합니다. CATALINA_BASE 가 Tomcat  인스턴스에 대한 환경변수이기 때문에 Tomcat 인스턴스 디렉토리인 conf, logs, temp, work, webapps 에 대한 디렉토리를 정의하는 것과 같습니다. 이는 다시 말해서 Tomcat 에서 실행시킬 자바 웹 소프트웨어의 루트 디렉토리를 지정하는 것이다라고 말 수 있습니다.

그렇다면 CTALINA_BASE 를 다르게하면 하나의 Tomcat 엔진에서 여러개의 인스턴스를 구동할 수 있다는 것이 됩니다.

Multi Instance 만들기

이 포스트에서는 다음과 같이 해보도록 하겠습니다.

  • Tomcat Engine : /opt/tomcat-7
  • Tomcat Instance: 리눅스의 시스템 계정을 만들고 자바 웹 애플리케이션 디렉토리 생성.

먼저 Tomcat Engine 을 설치해줍니다.

Tomcat Instance 를 위한 시스템 계정을 생성해 줍니다. 계정을 생성할때는 먼저 시스템 그룹을 생성하고 Tomcat 시스템 계정은 전부 이 시스템 그룹에 등록하는 방법으로 생성 합니다.

그리고 다음과 같이 Tomcat Instance 관련 파일들을 전부 복사해 줍니다.

각각의 Tomcat Instance 는 각각의 자바 웹 애플리케이션들이기 때문에 서로 가진 설정들에서 포트(port)를 변경해줍니다. Tomcat 의 포트는 다음과 같은 것들이 있습니다.

  • Shutdown port: 이 포트는 톰캣을 셧다운하는데 사용되어 집니다. shutdown.sh 스크립트가 호출되면 이 포트로 시그널(Signal)을 보냅니다. 이 포트는 Tomcat 자바 프로세스로 리스닝되고 있습니다. 만약 시그널을 받으면, 프로세스는 종료됩니다.
  • Connector port: 이 포트는 외부 클라이언트에게 애플리케이션을 보여주기위한 실제적인 포트 입니다.
  • Ajp port: 이 포트는 웹 서버가 Tomcat 과 커뮤니케이션을 위해서 사용되어 집니다. 또, 이 포트는 로드 밸런스 서버를 세팅할때에도 사용되어 집니다.
  • Redirect port: SSL 접속 요청이 들어올경우에 Catalina 는 자동적으로 이 포트로 redirect 합니다.

각각의 Tomcat Instance 는 위에서 나열한 포트들이 중복되지 않도록 설정해 줍니다. 이 설정은 각 인스턴스의 server.xml 파일에 정의되어 있습니다.

start.sh, shutdown.sh

각각의 인스턴스들에 대해서 start.sh, shutdown.sh 를 다음과 같이 만들어 줍니다.

‘INSTANCE_OWNER’ 환경변수에 인스턴스 계정명을 알맞게 넣고 작성해주면 됩니다.

그리고 이 스크립트를 실행하면 각각의 인스턴스들이 실행이 됩니다.

Tomcat 7 구조

이 문서는 Tomcat 7  구조 (Architecture) 에 관한 것입니다. 많은 부분을 “Apache Tomcat 7 More about the Cat” 을 참고 했습니다.

Tomcat 7 의 구조는 계층적 구조를 보이며 계층적으로 상속관계에 있습니다. 이를 다이어그램으로 표시하면 다음과 같습니다.

Tomcat Architecture
출처: http://www.ntu.edu.sg/home/ehchua/programming/howto/Tomcat_More.html

이 구조는 Tomcat 의 설정 파일에서도 그대로 나타납니다.

Tomcat 7 디렉토리 구조.

  • bin: Tomcat 의 바이너리 및 스크립트들.
  • conf: 모든 webapp 에 적용되는 글로벌 설정들.
  • lib: 모든 webapp 에서 활용가능한 JAR-file 들. 기본적으로 servlet-api.jar(Servlet), jasper.jar(JSP), jasper-el.jar(EL).
  • logs: 서버 로그 파일들이 있는 디렉토리. Catalina.{yyyy-mm-dd}}.log 는 엔진의 로그이며 localhost.{yyyy-mm-dd}.log 는 호스트 로그.
  • webapps: 디폴트 webapp
  • work: Tomcat 의 java 소스를 컴파일한 class 파일들을 모아놓은 디렉토리.
  • temp: 임시 파일들을  위한 디렉토리.

여기서 중요한 디렉토리는 conf 디렉토리로 Tomcat 의 운영과 webapp 에 영향을 주는 파일들로 총 7개가 있습니다.

  • catalina.policy : 이 파일은 Tomcat 7 에 대한 보안정책권한(Security Policy Permissions)들을 기술해 놓은 것입니다. 이것은 JVM 에 의해서 웹 애플리케이션에 강제적으로 보안정첵권한을 적용 합니다.
  • catalina.properties: 이 파일은 서버가 시작될때에 스캔되어질 필요가 있는 공유할 서버 정의, 공유할 로더, JARs를 가지고 있습니다.
  • server.xml: Tomcat 에서 매우 중요한 파일중 하나인데 서버의 IP 주소, 포트, 버추얼 호스트, 컨텍스트, 패스등과 같은 매우 중요한 정보를 가지고 있습니다.
  • tomcat-users.xml: 이 파일은 인증, 권한부여, 롤기반 정의에 사용될 수 있습니다. 인증을 위한 users/passwords/roles 의 데이터베이스나 컨테이너 관리 보안을 위해 사용되어집니다. 사용자를 추가/삭제나 존재하는 사용자에게 롤을 할당/비할당하기 위해서 이 파일을 편집하면 됩니다.
  • logging.properties: 이름에서 짐작했듯이, Tomcat 인스턴스의 로딩 속성들을 정의할 수 있습니다.
  • web.xml: 이것은 Tomcat 인스턴스에 의해서 로드되어 모든 웹 애플리케이션에 적용되어지는 기본 값들을 정의합니다. 만약 웹 애플리케이션이 자신만의 deployment 디스크립터를 가지고 있다며, 이 컨텐츠는 항상 기본 스크립터에 의해서 정의되어진 설정값을 오버라이드(override) 합니다.
  • context.xml: 이 파일의 내용들은 모든 애플리케이션에 로드됩니다. 세션 퍼시스턴스, Comet 접속 트래킹과 같은 파라메터 설정들을 할 수 있습니다.