클러스터링(Clustering) 은 소프트웨어, 하드웨어, 데이터 이중화 도입이 필요한 어떤 서비스에 대해 고가용성(High Availability) 구현을 위한 가장 일반적인 기술이다. 실패한 클러스터링 소프트웨어에서는 즉각적으로 관리자 개입이 필요없이 대기(standby) 시스템에 애플리케이션이 시작된다. 소프트웨어 이중화의 타입에 따라서 고가용성이 제공되어질 클러스터들은 다음과 같은 설정들로 구성되어질 수 있다.
Cold Standby: 보조 노드는 다른 동일한 기존 시스템의 백업처럼 동작 한다. 이 보조 노드는 처음으로 기존 노드가 고장이 발생했을때만 설치되어지고 구성되어진다. 그리고 나서, 기존 노드가 실패할때에 보조 노도는 켜지고 마지막으로 실패된 컨포넌트가 시작되기 이전 데이터로 복구되어진다. 기존 시스템의 데이터는 스토리지 시스템으로 백업되어질 수 있고 필요할때마다 보조 시스템으로 복구되어질 수 있다. 이것은 일반적으로 몇 시간의 복구 시간을 제공 한다.
Warm Standby: 소프트웨어 컨포넌트는 보조 노드에 설치되어지고 활용되어진다. 보조 노드는 켜지고 운영된다. 기존 노드가 실패할때에 이러한 소프트웨어 컨포넌트들은 보조 노드에서 시작되어진다. 이 과장은 일반적으로 클러스터 매니저를 사용해 자동화된다. 데이터는 정기적으로 공유 디스크나 디스크 기반 리플레케이션을 사용해 보조 노드 시스템에 미러(mirror) 된다. 이것은 일반적으로 몇분의 복구 시간을 제공한다.
Hot Standby: 소프트웨어 컨포넌트들은 기존 노드와 보조 노드 양쪽 모두에 설치되어지고 활용되어 진다. 보조 시스템의 소프트웨어 컨포넌트들은 켜져 있지만 데이터를 처리하거나 요청을 처리하지 않는다. 데이터는 거의 실시간으로 미러(mirror) 되고 양쪽 시스템은 동일한 데이터를 갖는다. 데이터 리플리케이션은 전형적으로 소프트웨어의 기능을 통해서 이루어진다. 이것은 일반적으로 몇초의 복구 시간을 제공한다.
Active-Active (Load Balanced): 이 방법에서는 기본과 보조 시스템들은 Active 이고 병령로 요청을 처리중이다. 데이터 리플레케이션은 소프트웨어 기능을 통해서 행해지고 양방향이 될 수 있다. 이것은 일반적으로 순간적 복구 시간을 제공 한다.
snmpd 는 시스템의 자원들에 대해서 SNMP 프로토콜을 통해서 볼 수 있는 기능을 제공 한다. 그런데, 알고 싶은 자원들에 대한 목록들을 조회하기 위해 MIB 값들이 할당되어 있으며 자주 사용되는 운영체제, 라우터, 스위치 같은 장비들에 대한 MIB 값들을 미리 할당되어 전 세계적으로 표준으로 재정해 사용하고 있다.
그런데, 표준으로 재정된 MIB 값외에 사용자가 필요한 자원들을 조회하기 위한 MIB 값을 등록해야 하는데 이때 사용하는 것이 SNMP Extend 를 사용하면 된다.
SNMP Extend 는 ‘.1.3.6.1.4.1.2021.8.10’ 같은 MIB 에 조회하고자하는 값들을 등록하면 된다.
HyperText Transfer Protocol 은 인터넷 미디어를 전송하기 위한 규약이다. 인터넷 미디어라는 단어를 쓰기는 했지만, 요즘에는 인터넷을 통해서 못하는게 없을 정도로 인터넷 미디어를 규정하는 매체의 경계는 없다. 따라서 “인터넷 미디어를 전송하기 위한 규약”은 구시대적인 정의이며 차라리 “인터넷을 이용한 웹을 사용할 경우에 쓰이게되는 규약” 정도가 더 잘 맞는듯 하다.
HyperText 는 텍스트를 가지는 노드사이에 지역적인 링크(이걸 HyperLink라 한다)를 사용하는 구조적 텍스트를 말한다. 쉽게 말해서 웹사이트에서 링크를 클릭하면서 텍스트를 불러오는 텍스트 구조를 말하는 것이다.
History
Tim Berners-Lee
1989년 CERN (유럽 입자 물리학 연구소) 에 근무하던 Tim Berners-Lee 는 각국에서 온 연구원들과 수많은 논문들을 컴퓨터를 이용해 공유할 방법을 궁리하고 있었다. 박사들의 논문들은 간단한 텍스트와 수식이 전부였는데, 이것을 컴퓨터로 표현하기 위한 손쉬운 방법을 궁리했는데, 그건 프로그래머 수준의 교육을 받은자가 아닌 어떤 규칙성만 알면 손쉽게 만들수 있도록 하는데 초점이 있었다.
여러가지 가능성을 연구하던중에 마크업(MarkUp) 언어로 간단한 규칙만으로 논문들을 공유할 수 있도록 HTML 을 만들어낸다.
문제는 주석이였다. 각종 논문에는 글의 중간중간에 어려운 단어의 해석을 위해서 주석을 붙이곤 했고 논문에 뒷부분에는 참고문헌들을 나열하여 추가적으로 필요한 자료들을 찾아보도록 되어 있었다.
어떻게하면 이러한 수많은 정보들을 손쉽게 접근할 수 있을까라는 생각 끝에 HyperLink 라는 개념이 나오고 이러한 HyperLink 를 포함하는 구조적인 텍스트로서 HTML 이 만들어졌으며 이를 전송하기위한 프로토콜로서 HTTP 를 만들어낸다.
Tim Berners-Lee 는 HTML, HTTP, 그리고 이것을 이용할 오늘날의 웹 브라우저를 만들어냈다. 그것도 1990년대 일이였으며 이렇게해서 제작한 것을 CERN 연구소에서 1991년 8월 6일날 첫번째 웹 문서가 온라인에 게재된다. 이때 이용한 HTTP 의 버전이 바로 0.9 버전이다.
그가 만든 HTML, HTTP 웹 브라우저는 로열티도 없는 무료였으며 많은 회사들이 이에 관심을 가지고 웹(web)의 발전에 기여하도록 만든다. 이러한 그의 노력은 World Wide Web 이라는 단어를 세상에 알리는 계기가 되면서 1994년에 W3C (World Wide Web Consortium) 이 창립되게 이른다.
HTTP 버전.
1991년 HTTP 0.9
1996년 HTTP 1.0
1999년 HTTP 1.1
HTTP 특징.
HTTP 의 가장 큰 특징은 다음과 같다.
클라이언트(Client) 로부터 요청이 있어야만 한다.
모든 필요한 HyperText 를 서버가 클라이언트로 전송이 끝나면 서버와의 연결은 해제된다.
HTTP 은 클라이언트가 서버로 연결을 이루고 필요한 HyperText 를 전송받고 연결을 해제하는 세가지 방법으로 동작한다. 필요한 HyperText 를 다 전송하고 나면 연결을 해제한다는 것, 즉 연결지향이 아닌 비연결지향이라고 해서 “Connectionless Protocol” 이라고도 한다.
클라이언트가 서버로 연결을 요청해야만 무언가를 할 수 있다는 것도 중요한데, 이는 서버가 클라이언트를 먼저 연결 요청을 할 수 없다는 것이다.
또, HTTP 는 TV 방송처럼 서버에서 동작하는 것을 보기위한 TV 같은 것이 아니라 서버에서 필요한 자원들을 전부 다운로드 받아서 클라이언트의 웹 브라우저에서 플레이를 해주는 것이다.
따라서 웹(Web)이라는 것은 HTTP 는 서버로부터 HTML 을 구성하는 자원들을 모두 클라이언트에 모두 가지고 와서 클라이언트가 웹 브라우저를 이용해서 보여주는 것이다.
HTTP 구조.
HTTP 는 HTML 을 전송하기 위한 프로토콜이다. 이것을 만들었을 당시에 대상이 연구 논문이였다는 점을 감안하면 최대한 단순한 구조로 만들어져있다는 건 놀라운 일이 아니다.
HTTP 는 Header 와 Body 로 구분되어진다.
Structure of a request message.(http://www.icodeguru.com/dotnet/core.c.sharp.and.dot.net/0131472275/ch17lev1sec1.html)
Header 에는 메소드(Method), URI, HTTP 프로토콜과 버전을 비롯한 각종 정보들을 포함하고 Body 에는 클라이언트가 서버에 요청할 내용이 들어간다. 메소드가 GET 일 경우에 QueryString 의 경우가 바로 Body 다.
HTTP 구조에서 Header 들어가는 내용은 HTTP 버전별로 차이가 있다. 주요한 차이는 다음과 같다.
분류
HTTP 1.0
HTTP 1.1
Pragma
지원
미지원
Cache-Control
미지원
지원
Transfer-Encoding
미지원
지원
Content-Language
미지원
지원
Connection
미지원
지원
Accept
미지원
지원
Accept-Charset
미지원
지원
Accept-Encoding
미지원
지원
Accept-Language
미지원
지원
Host
미지원
지원
GET
지원
지원
POST
지원
지원
HEAD
지원
지원
OPTIONS
미지원
지원
PUT
미지원
지원
DELETE
미지원
지원
TRACE
미지원
지원
HTTP 1.0 과 HTTP 1.1 이 가장 큰 차이점이라면 바로 Connection 헤더이며 이 값이 Keep-Alive 를 지원 여부이다. HTTP 1.1 은 Keep-Alive 를 지원해 다수 접속의 요청과 연결을 줄이고 한번의 연결로 다수의 데이터를 전송받을 수 있게 해준다.
이러한 HTTP 는 웹을 보여주는 웹 브라우저와 서버간의 통신이며 기본적으로 메타데이터를, 이는 텍스트 데이터여서 사람이 눈으로 읽을 수 있다, 주고받는 것이여서 이것을 캡쳐해서 볼 수 있다.
HTTP 통신 들여다 보기.
HTTP 통신은 웹 브라우저와 서버간의 통신으로 이를 들여다 볼 수 있다. 여기서는 Telnet 을 통해서 서버에 요청을 보내고 받아보는 방법을 소개한다.
이것은 브라우저가 해야하는 것을 Telnet 이 대신하는 것이라고 보면 되며 실제 웹 브라워져와 서버와의 통신이 어떻게 이루어지는지를 극명하게 보여주는 실제 예라 할 수 있다.
먼저 Telnet 을 이용해서 서버에 다음과 같이 접속을 한다.
telnet linux.systemv.pe.kr 80
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
]# telnet linux.systemv.pe.kr 80
Trying127.0.0.1...
Connected tolinux.systemv.pe.kr.
Escape character is'^]'.
GET/index.htmlHTTP/1.1<--직접입력
Host:linux.systemv.pe.kr<--직접입력
Connection:Keep-Alive<--직접입력
<--Enter쳐준다.
HTTP/1.1200OK
Server:nginx/1.4.2
Date:Sat,07Mar201515:56:37GMT
Content-Type:text/html
Content-Length:612
Last-Modified:Fri,06Mar201514:12:38GMT
Connection:keep-alive
ETag:"54f9b5d6-264"
Accept-Ranges:bytes
<!DOCTYPEhtml>
<html>
<head>
<title>Welcometonginx!</title>
<style>
body {
width:35em;
margin:0auto;
font-family:Tahoma,Verdana,Arial,sans-serif;
}
</style>
</head>
<body>
<h1>Welcome tonginx!</h1>
<p>Ifyou see thispage,the nginx web server issuccessfully installed and
working.Further configuration isrequired.</p>
<p>Foronline documentation andsupport please refer to
<ahref="http://nginx.org/">nginx.org</a>.<br/>
Commercial support isavailable at
<ahref="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you forusing nginx.</em></p>
</body>
</html>
Connection closed by foreign host.
linux.systemv.pe.kr 를 했지만 아무 웹 사이트나 상관이 없다. 중요한 것은 “직접입력”,”Enter 쳐준다” 같이 직접 해준 것이다. 이 부분이 바로 웹 브라우져가 웹 서버에 요청을 하는 아주 간단한 방법이다. 위 방법에는 body 가 없다. 그런데도 서버로의 요청이 전달되고 응답도 정상으로 나온다.
응답은 정확하게 Header 와 Body 로 나뉘어 나온다. 주목해야 하는 것은 바로 Header 이다.
HTTP response
1
2
3
4
5
6
7
8
9
HTTP/1.1200OK
Server:nginx/1.4.2
Date:Sat,07Mar201515:56:37GMT
Content-Type:text/html
Content-Length:612
Last-Modified:Fri,06Mar201514:12:38GMT
Connection:keep-alive
ETag:"54f9b5d6-264"
Accept-Ranges:bytes
응답 Header 는 HTTP 버전과 함께 HTTP 응답 코드로부터 시작한다. 그리고 응답하는 컨텐츠가 어떤 타입인지, 텍스트 인지 그림파일인지 아니면 바이너리 파일인지등, 을 명시하고 있으며 body 의 길이도 보여주고 있으며 현재 연결 상태가 어떤것인지도 나타내고 있다.
Telnet 말고 다른 툴들도 있는데, 여기서 몇개를 소개한다.
Internet Explorer 11 개발자 도구
Windows 운영체제에서 가장 많이 사용하는 Internet Explorer 11 에는 개발자 도구라는 것이 있다. 정확하게는 웹 개발자 도구인데, 단축키 F12 이며 이것을 누르면 브라우져 아래에서 창이 올라온다.
IE11의 개발자 도구
여기에서 “네트워크” 메뉴를 클릭하면 위 화면과 같은 상태가 된다. 이제 왼쪽에 초록색 플레이 단추를 누르고 주소창에 웹 사이트 주소를 입력해서 엔터를 쳐보자.
IE11 개발자도구 네트워크 요약
그러면 위와 같이 웹 브라우저가 입력한 웹 사이트로부터 내려받은 웹 컨텐츠들에 대한 정보와함께 보여준다. 내려받은 웹 컨텐츠의 정보로는 유형, 받은 용량, 받는데 걸린 시간등이다.
이제 위 내려받은 컨텐츠중에 하나를 클릭하고 왼쪽에 ‘자세히’를 클릭하면 아래와 같이 HTTP 정보가 나온다.
IE11 개발자도구 네트워크 상세 정보
아주 보기 편하도록 각각 필요한 정보들을 분류하고 내용들을 잘 보여준다. 이쯤되면 유료 소프트웨어 못지 않다.
Safari
Safari 웹 브라우저에서도 IE11 과 같은 툴을 제공한다. Safari 를 실행하고 “웹 속성보기”혹은 마우스 오른쪽 버튼을 클릭해 요소검사를 실행하면 아래쪽에 IE11 과같이 창이 올라온다.
Safari HTTP 보기
여기서 왼쪽에 “타임라인” 클릭하고 페이지를 다시 한번 릴로드 하거나 주소창에 웹 사이트 주소를 입력하고 엔터를 친다. 그러면 타임라인에 시간들이 그려지고 왼쪽에 컨텐츠들이 나오며 그것을 클릭하고 오른쪽에 “리소스” 를 클릭하면 이 컨텐츠의 상세한 정보가 나오면서 HTTP 이 내용을 볼 수 있다.
FireFox
FireFox 웹 브라우저에도 “요소검사” 를 통해서 각 웹 컨텐츠별로 HTTP 의 내용을 아래와 같이 살펴볼 수 있다. “네트워크” 탭을 클릭한 후에 주소창에 웹 사이트 주소를 입력해 엔터를 치면 왼쪽에 웹 사이트의 컨텐츠들이 표시되며 클릭을하면 HTTP의 상세한 정보를 보여준다.
Firefox HTTP 분석
Fiddler
Fiddler 는 Web Debugger 이며 독립된 소프트웨어 이다. 무료여서 누구나 사용할 수 있다. 설치를한 후에 실행을 하면 곧바로 HTTP 들을 캡쳐하기 시작하며 어떤 웹 브라우져를 사용하던지간에 HTTP를 캡쳐해준다.
Fiddler
전송된 컨텐츠에 대해서 매우 상세한 정보를 보여주는 전문적인 툴이다.
HTTP 프로토콜이 무엇인지부터해서 이것을 눈으로 직접확인해 볼수 있는 방법까지 간단하게 살펴봤다. 위 내용이 전부가 아니며 아주 기초적인 내용에 불과할 뿐이라는 사실을 상기할 필요가 있다. HTTP 는 아주 간단하지만 위에서 기술한 것보다 훨씬 다양하고 체계적인 내용들이 다수 포함되어 있다.
웹 개발자이거나 웹 서버를 다루는 사람이라면 이러한 툴들을 가까이하는 것이 좋다. 주로 보안 쿠키를 검사하거나 보이지 않은 헤더의 변조가능성등을 살펴봐야하는 때에는 이러한 방법들이 기초적인 추적의 실마리를 제공할 수도 있다.
아주 접속이 많은 웹 서버를 운영하던중에 다음과 같은 종류의 메시지를 접하는 경우가 종종 있다.
웹 서버 메시지.
Shell
1
Too many open files(24)
너무나 많은 파일을 열었다는 건데, 도대체 무슨 파일을 열었다는건지 서비스하는 웹 페이지의 파일 개수도 많지도 않은데 말이다.
이 문서는 이러한 의문을 가지는 사람들 위한 것이다.
모든게 파일!
리눅스 시스템은 모든것이 파일이다. 장치도 파일이다. 그 유명한 /dev/ 디렉토리에 있는 팡리들이 바로 장치들이다. 저 파일들에게 cat 명령어로 데이터를 던져주면 그것을 알아먹는 장치는 동작하게 된다.
또, 리눅스에서 프로그램의 실행은 혼자 동작하는 것이 아니다. C 프로그램을 해본사람이라면 라이브러리(Library) 개념을 알고 있을 텐데 프로그램이 동작할때에는 이러한 라이브러리 파일도 함께 로딩(Loading)된다. 예를들어 sshd 라는 명령어가 어떤 라이브러리들고 로딩되는지는 다음과 같이 알수 있다.
Shell
1
lsof-csshd
sshd 가 실행중인데, 현재 이 프로그램은 아주 많은 파일들을 사용하고 있다. 프로그램 실행을 위한 라이브러리 파일뿐만 아니라 sshd 설정파일들도 눈에 보인다.
그런데, 리눅스 시스템에서 각 프로그램에게 64개 이상의 파일을 사용하지 못하도록 설정되어 있다면 어떻게 될까? 그것이 바로 위에서 만나게 되는 메시지이다.
리눅스 시스템 자원 제어하기.
리눅스 시스템은 위에서 설명한 것처럼 열어야할 파일 개수뿐만아니라 다양한 자원들에게 대해서 제어를 할 수 있도록 해놨다. 이를 위해서 ulimit 라는 명령어를 제공하고 이를 통해서 각각의 자원들을 제어할 수 있다.
/etc/security/limis.conf
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# - core - limits the core file size (KB)
# - data - max data size (KB)
# - fsize - maximum filesize (KB)
# - memlock - max locked-in-memory address space (KB)
# - nofile - max number of open file descriptors
# - rss - max resident set size (KB)
# - stack - max stack size (KB)
# - cpu - max CPU time (MIN)
# - nproc - max number of processes
# - as - address space limit (KB)
# - maxlogins - max number of logins for this user
# - maxsyslogins - max number of logins on the system
# - priority - the priority to run user process with
# - locks - max number of file locks the user can hold
# - sigpending - max number of pending signals
# - msgqueue - max memory used by POSIX message queues (bytes)
# - nice - max nice priority allowed to raise to values: [-20, 19]
# - rtprio - max realtime priority
위에 나열한 것처럼 cpu, login, file open, file size 등 다양한 것에 대해서 제한(limit)을 둘 수 있다.
또, 각각의 제한은 리눅스 시스템 계정 사용자별, 그룹별, 프로세스별로 줄 수 있다. 그렇다면 현재 로그인한 상태에서 제한은 다음과 같이 확인이 가능하다.
ulimit -a
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
core filesize(blocks,-c)0
data seg size(kbytes,-d)unlimited
scheduling priority(-e)0
filesize(blocks,-f)unlimited
pending signals(-i)14848
max locked memory(kbytes,-l)64
max memory size(kbytes,-m)unlimited
open files(-n)1024
pipe size(512bytes,-p)8
POSIX message queues(bytes,-q)819200
real-timepriority(-r)0
stack size(kbytes,-s)10240
cpu time(seconds,-t)unlimited
max user processes(-u)14848
virtual memory(kbytes,-v)unlimited
filelocks(-x)unlimited
만일 슈퍼 유저(혹은 root 유저) 라면 다른 사용자의 제한도 다음과 같이 확인할 수 있다.
Shell
1
su-linux-c'ulimit -a'-s'/bin/bash'
Soft and Hard Limit
시스템 리소스 제한에는 Soft Limit 와 Hard Limit 가 있다. Hard Limit 는 Soft Limit 의 최대임계치로서 이 제한에 걸리면 곧바로 문제가 된다. 하지만 Soft Limit 는 최대 임계치는 아니여서 이것을 벗어나더라도 Hard Limit 까지는 문제가 없다. 대신에 Soft Limit 를 벗어났을때에 메일을 보낸다든지 경고 메시지를 내보내는등 조만간에 최대 임계치에 도달할 수 있다는 것을 미리 알려줄 수 있다.
사용자별, 자원별 제한
사용자별, 자원별로 제한을 둘 수 있다. 이는 /etc/security/limits.conf 파일에 명시하면 사용자별, 자원별로 제한이 된다. 파일을 열어보면 자원별은 item 으로 부르고 있는데 제한을 두고 싶은 시스템 자원에 대한 지시어를 찾아서 적으면 된다.
예를들어 systemv 사용자에 대해 최대 파일 열기 디스크립터 개수를 제한고 싶다면 다음과 같이 해주면 된다.
Apache
1
2
systemvsoftnofile500000
systemvhardnofile500000
이 내용을 적은 이후부터 systemv 로 시스템에 로그인 하는 사용자는 바로 적용이 되고 이 사용자 계정으로 실해되는 데몬 프로그램은 재시작을 해주면 바로 적용된다.
각 프로세스당 자원에 대한 제한을 알고 싶다면 PID 를 알아낸뒤에 다음과 같이 해주면 된다.
먼저, 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 모드가 활성화 되도록 컴파일 설치해야 한다.
Nginx debug 모드 활성화
Shell
1
2
3
./configure--with-debug
make
makeinstall
그리고 다음과 같이 error_log 에 debug 를 활성화 해줍니다.
Nginx error_log debug 설정
Apache
1
error_loglogs/error.logdebug;
keepalive_timeout 설정을 5초로 해줍니다.
nginx keepalive_timeout 설정
Apache
1
keepalive_timeout5;
이렇게해서 nginx 를 실행하고 error.log 파일을 보면 nginx 가 처리하는 과정을 상세히 볼 수 가 있다.
이와 더불어 HTTP 연결 테스트는 Telnet 을 이용하면 된다. 테스트는 다음과 같이 진행하면 된다.
telnet localhost 80
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
]# telnet localhost 80
Trying127.0.0.1...
Connected tolocalhost.
Escape character is'^]'.
GET/index.htmlHTTP/1.1<--직접입력
Host:localhost<--직접입력
Connection:Keep-Alive<--직접입력
<--Enter쳐준다.
HTTP/1.1200OK
Server:nginx/1.4.2
Date:Sat,07Mar201515:56:37GMT
Content-Type:text/html
Content-Length:612
Last-Modified:Fri,06Mar201514:12:38GMT
Connection:keep-alive
ETag:"54f9b5d6-264"
Accept-Ranges:bytes
<!DOCTYPEhtml>
<html>
<head>
<title>Welcometonginx!</title>
<style>
body {
width:35em;
margin:0auto;
font-family:Tahoma,Verdana,Arial,sans-serif;
}
</style>
</head>
<body>
<h1>Welcome tonginx!</h1>
<p>Ifyou see thispage,the nginx web server issuccessfully installed and
working.Further configuration isrequired.</p>
<p>Foronline documentation andsupport please refer to
<ahref="http://nginx.org/">nginx.org</a>.<br/>
Commercial support isavailable at
<ahref="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you forusing nginx.</em></p>
</body>
</html>
Connection closed by foreign host.<---이메시지가나올때까지정확하게5초가걸리는데이는keepalive_timeout값이다.
마지막에 “Connection close by foreign host.” 메시지는 5초동안 아무런 요청이 없으면 나타나는데 이는 keepalive_timeout 설정된 값과 같다. 만일 5초가 지나기 전에 또 한번에 데이터 요청을 Server 에 보낸다면 keepalive_timeout 은 reset 되고 전송이 끝난후에 다시 타이머가 흐르기 시작한다.
이는 keepalive_timout 에 대해서 데이터 전송이 끝난 후에 다시 데이터 전송 요청때까지의 갭타임을 의미하기도 한다. 그 사이에 데이터 전송 요청이 없다면 Server 가 접속을 차단하게 된다.
위 실험에서 Nginx는 과연 어떻게 처리했을까? 로그에는 아주 많은 정보가 표시되는데, 전송이 모두 끝난후에 다음과 같은 로그가 보인다.
카산드라(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 를 다운받아 다음과 같이 압축을 해제합니다.
jdk 7 update 75 설치
Shell
1
2
3
tar xvzf jdk-7u75-linux-x64.tar.gz-C/opt
cd/opt
ln-sjdk1.7.0_75jdk
카산드라(Cassandra) 2.1.2 설치
카산드라(Cassandra) 는 리눅스의 슈퍼유저인 root 로 실행할 필요가 없습니다. 카산드라(Cassandra) 를 운영하기 위한 시스템 계정을 만들고 그 시스템 계정으로 운영하면 됩니다.
사실 Tomcat 을 다운받아 압축을 해제하면 엔진부분과 인스턴스부분이 함께 들어 있기 때문에 별 구별이 안되는 측면이 있지만 엄밀히 따지면 위와같이 구분을 할 수 있습니다.
사실 Tomcat 엔진은 아무것도 아닙니다. Tomcat 엔진은 실제로 단독으로 구동되지 않습니다. Tomcat 엔진의 역활은 자바 소프트웨어를 실행시켜주는 역활만 담당합니다. 여기서 자바 소프트웨어라는 것이 바로 Tomcat 인스턴스 입니다.
Tomcat 엔진이 자바 소프트웨어를 실행시킨다는 말은 결국에는 JVM 이 작동하는 것입니다. 따라서 Tomcat 인스턴스는 JVM 이 구동된다는 것이며 Multi Instance 는 여러개의 Tomcat JVM 을 구동한다는 것을 의미 합니다.
Tomcat 구동
Tomcat 이 구동될때에는 시스템 환경변수에 의존 합니다. bin/startup.sh 스크립트는 Tomcat 을 구동되도록하는 스크립트인데, 이 스크립트는 환경변수를 세팅하고 catalina.sh 스크립트를 호출하는 역활을 합니다. 실제 실행하면 환경변수내용을 볼수 있습니다.
Tomcat 구동.
Shell
1
2
3
4
5
6
7
]# ./startup.sh
Using CATALINA_BASE:/opt/apache-tomcat-7.0.57
Using CATALINA_HOME:/opt/apache-tomcat-7.0.57
Using CATALINA_TMPDIR:/opt/apache-tomcat-7.0.57/temp
Using JRE_HOME:/usr
Using CLASSPATH:/opt/apache-tomcat-7.0.57/bin/bootstrap.jar:/opt/apache-tomcat-7.0.57/bin/tomcat-juli.jar
Tomcat started.
먼저, 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 엔진 설치
Shell
1
cp-aapache-tomcat-7.0.57/opt/tomcat-7
Tomcat Instance 를 위한 시스템 계정을 생성해 줍니다. 계정을 생성할때는 먼저 시스템 그룹을 생성하고 Tomcat 시스템 계정은 전부 이 시스템 그룹에 등록하는 방법으로 생성 합니다.
Tomcat Instance 를 위한 시스템 계정 생성
Shell
1
2
3
4
groupadd tomcat
useradd-gtomcat-s/usr/sbin/nologin instance1
useradd-gtomcat-s/usr/sbin/nologin instance2
useradd-gtomcat-s/usr/sbin/nologin instance3
그리고 다음과 같이 Tomcat Instance 관련 파일들을 전부 복사해 줍니다.
Tomcat Instance 파일 복사 및 디렉토리 생성.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# instance1
cp-aconf/home/instance1
cp-awebapps/home/instance1
mkdir/home/instance1/logs
mkdir/home/instance1/work
chown instance1:tomcat-R/home/instance1
# instance2
cp-aconf/home/instance2
cp-awebapps/home/instance2
mkdir/home/instance2/logs
mkdir/home/instance2/work
chown instance2:tomcat-R/home/instance2
# instance3
cp-aconf/home/instance3
cp-awebapps/home/instance3
mkdir/home/instance3/logs
mkdir/home/instance3/work
chown instance3:tomcat-R/home/instance3
각각의 Tomcat Instance 는 각각의 자바 웹 애플리케이션들이기 때문에 서로 가진 설정들에서 포트(port)를 변경해줍니다. Tomcat 의 포트는 다음과 같은 것들이 있습니다.
Shutdown port: 이 포트는 톰캣을 셧다운하는데 사용되어 집니다. shutdown.sh 스크립트가 호출되면 이 포트로 시그널(Signal)을 보냅니다. 이 포트는 Tomcat 자바 프로세스로 리스닝되고 있습니다. 만약 시그널을 받으면, 프로세스는 종료됩니다.
Connector port: 이 포트는 외부 클라이언트에게 애플리케이션을 보여주기위한 실제적인 포트 입니다.
Ajp port: 이 포트는 웹 서버가 Tomcat 과 커뮤니케이션을 위해서 사용되어 집니다. 또, 이 포트는 로드 밸런스 서버를 세팅할때에도 사용되어 집니다.
Redirect port: SSL 접속 요청이 들어올경우에 Catalina 는 자동적으로 이 포트로 redirect 합니다.
각각의 Tomcat Instance 는 위에서 나열한 포트들이 중복되지 않도록 설정해 줍니다. 이 설정은 각 인스턴스의 server.xml 파일에 정의되어 있습니다.
