Information Technology WEBlog

IP 알리아싱

리눅스 커널 2.0 을 컴파일 해보면 network aliasing 과 ip aliasing을 지정하는 부분이 나온다. 여기 그 용도를 적는다.

1. IP Aliasing의 개념

IP aliasing이란 한개의 인터페이스에 두개 이상의 어드레스를 지정하는걸 말한다. 예를들어 eth0란 랜카드에 두개의 IP 어드레스를 지정하므로서 둘중 어느 어드레스로도 접근을 허용하는걸 말한다. 이때 두개의 주소가 같은 네트워크에 속하면 IP Aliasing이고 다른 네트워크에 속하면 Network Aliasing이다.

2. IP aliasing의 응용범위

1) 버츄얼웹(웹호스팅)

웹서버를 운영하는데는 꿰 많은 비용이 든다. 피시로 구축하더라도 하드웨어 비용만 약 500만원에 인터넷 전용선 사용료가 월 50-60만원 든다. 거기에 운영인력도 필요하다. 따라서 단순히 홈페이지만 구축하고자하면 ISP들이 제공하는 웹호스팅을 이용하면된다. 웹호스팅을 이용하면 월 몇만원 정도의 비용만 지불하면 홈페이지를 운영할수 있다.(제작비는 별도) 즉 ISP들이 자신의 호스트에 업체의 웹서버를 운영해주고 월 사용료를 받는걸 웹호스팅이라한다.

웹 호스팅을 할때 필요한게 바로 버츄얼웹 기법으로서 www.abc.co.kr 과 www.def.co.kr 두개의 홈페이지가 한대의 컴퓨터에서 운영되는걸 말한다. 두 홈페이지는 서로 독립적으로 구성되며 도메인네임도 다르므로 외부에서는 두 홈페이지가 같은 컴퓨터에 있다는걸 알수가 없다. (두개만 가능한게 아니라 다수가 가능하다)

버츄얼웹을 만들때 필요한게 network aliasing 또는 ip aliasing이다. 물론 여기에 서로 다른 도메인 네임에서 서로 다른 홈페이지가 뜨도록 해주는 웹서버 프로그램의 지원도 필요하다. Apache 웹서버 프로그램의 httpd.conf에보면 virtual web을 설정하는 부분이 있다.
아래가 그 예이다.

<VirtualHost kil.nungkul.co.kr>
ServerAdmin nungkul7@nungkul.co.kr
DocumentRoot /home/kil/web
ServerName kil.nungkul.co.kr
ErrorLog logs-kil/error_log
TransferLog logs-kil/access_log
</VirtualHost>

2) 버츄얼 랜(Virtual LAN)

하나의 물리적 랜에 두개의 논리적 랜이 존재하는걸 버츄얼랜이라부른다. 즉 랜은 하나지만 네트웍 어드레스가 서로 다른 두 그룹의 컴퓨터들이 동시에 연결돼 있을 경우 두 컴퓨터 그룹은 별개의 랜을 이루고 있으므로 서로 독립한 네트웍으로 작동한다. 물론 라우터가 있거나 어느 한 컴퓨터에 랜카드가 두개 꼽혀 있어 두개의 랜을 연결해 주고 있다면 이는 두개의 물리적 랜이지 한개의 랜이 아니다.

예를들어 회사의 랜이 라우터를 통해 인터넷과 연결돼 있고 인터넷 어드레스가 203.234.216.XXX라고 하자. 이때 회사 랜에 연결된 리눅스 피시 어드레스를 192.168.1.1로 지정하면 회사 랜에 있는 다른 피시들은 네트웍어드레스(203.234.234.0)가 리눅스의 네트웍 어드레스(192.168.1.0)와 다르므로 리눅스로 login할수 없다. 만약 어느 피시가 리눅스로 login 하려면 그 피시의 주소를 192.168.1.X로 바꾸어야한다.

이 경우 회사의 물리적 랜 한개에 두개의 논리적 랜(203.234.216.0 과 192.168.1.0)이 존재한다. 이를 버츄얼 랜이라 부른다. 만약 이 랜에 연결된 리눅스에 두 그룹에 있는 피시가 모두 login할수 있도록 해주려면 이때 바로 IP aliasing을 리눅스의 랜카드에 적용하면 된다. 즉 리눅스 랜카드에 192.168.1.1 외에 203.234.216.1 어드레스를 IP aliasing을 이용해 부여하면 두 논리적 랜에 속한 모든 피시들은 리눅스에 login할수 있다.
이기법은 회사의 보안용으로도 응용이 가능하다. 즉 회사 내부랜 전용 호스트를 인터넷에서 접근이 불가능하게 만드는데 이 기법이 사용될수 있다.

*. 참고

192.168.1.0 네트웍 주소는 RFC(Request For Comment)에서 내부 랜 전용으로 할당한 주소이다. 따라서 라우터에는 이 주소를 외부로 라우팅하면 안된다.

3. IP aliasing 셋업

아래는 본인의 리눅스 피시에 IP aliasing을 구현한 예이다. 이 피시에는 랜카드를 두개 꼽았고 두번째 랜카드(eth1)에 IP aliasing을 구현하였다.

eth0의 IP 주소는 192.168.1.1
eth1은 150.1.254.1
eth1:0은 150.1.254.254 이다.

여기서 eth1:0이 바로 IP aliasing으로 부여한 주소이다. 이 경우는 eth1에 부여한 두개의 주소가 같은 네트웍에 속하므로 network aliasing이 아니고 IP aliasing이다. 아래에 IP aliasing을 구현하기위한 ifconfig와 route 명령 예이다.

(본인은 debian을 사용하므로 /etc/init.d/network 파일임)

*. ifconfig 명령 전에 커널을 컴파일해서 network aliasing과 ip aliasing을 넣어야한다.

#! /bin/sh
# localhost
ifconfig lo 127.0.0.1
route add -net 127.0.0.0
#
# ethernet 1
#
IPADDR=150.1.254.1
NETMASK=255.255.0.0
NETWORK=150.1.0.0
BROADCAST=255.255.255.255
GATEWAY=150.1.1.1
ifconfig eth1 ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST}
route add -net ${NETWORK}
route add default gw ${GATEWAY} metric 1
#
# ethernet 0
#
ifconfig eth0 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
route add -net 192.168.1.0
#
# ethernet-1 ip alias
#
ifconfig eth1:0 150.1.254.254 netmask 255.255.0.0 broadcast 150.1.255.255
route add -host 150.1.254.254 dev eth1:0
#





아래는 이 명령으로 ip aliasing을 구현했을때의 ifconfig와 netstat -nr 명령 출력 결과이다 
 
churlsu:~> ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Bcast:127.255.255.255  Mask:255.0.0.0
          UP BROADCAST LOOPBACK RUNNING  MTU:3584  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0
          TX packets:0 errors:0 dropped:0 overruns:0
 
eth0      Link encap:10Mbps Ethernet  HWaddr 00:60:8C:EC:78:1B
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0
          TX packets:0 errors:0 dropped:0 overruns:0
          Interrupt:10 Base address:0x300
 
eth1      Link encap:10Mbps Ethernet  HWaddr 00:A0:24:EA:95:B2
          inet addr:150.1.254.1  Bcast:150.1.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:804 errors:0 dropped:0 overruns:0
          TX packets:82 errors:0 dropped:0 overruns:0
          Interrupt:5 Base address:0x210
 
eth1:0    Link encap:10Mbps Ethernet  HWaddr 00:A0:24:EA:95:B2
          inet addr:150.1.254.254  Bcast:150.1.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0
          TX packets:0 errors:0 dropped:0 overruns:0
 
churlsu:~> netstat -nr
 
Kernel IP routing table
Destination     Gateway   Genmask         Flags   MSS Window  irtt Iface
150.1.254.254   0.0.0.0   255.255.255.255 UH     1500 0          0 eth1:0
192.168.1.0     0.0.0.0   255.255.255.0   U      1500 0          0 eth0
150.1.0.0       0.0.0.0   255.255.0.0     U      1500 0          0 eth1
127.0.0.0       0.0.0.0   255.0.0.0       U      3584 0          0 lo
0.0.0.0         150.1.1.1 0.0.0.0         UG     1500 0          0 eth1
churlsu:~>

이제 설정이 모두 끝났으면, heartbeat을 실행한다.

[portos@smurfland ~]$ sudo /etc/init.d/heartbeat start
[portos@smurfland ~]$

smurfland.snu.ac.kr과 linux-smp 모두에서 위와 같이 heartbeat을 실행시킨다.
이제 smurfland.snu.ac.kr과 linux-smp는 크로스 케이블을 통하여 heartbeat을 주고 받는다.

제대로 동작하고 있는지 확인하기 위해서 다음과 같은 테스트를 하였다.
제 3의 기계(211.111.63.105)에서 ping을 하였다. 그리고 이 때 ping 패킷이 실제로 smurfland.snu.ac.kr과 linux-smp 중 어느 것으로 보내지는지를 확인하였다.

[dhkim@voyage ~]$ ping 211.111.63.148
[portos@smurfland ~]$ sudo tcpdump dst host 211.111.63.148
[portos@linux-smp ~]$ sudo tcpdump dst host 211.111.63.148

위와 같이 실험을 해 본 결과 ping 패킷이 smurfland.snu.ac.kr로 보내지고 있다는 것을 확인할 수 있었다.
이제 primary가 고장나는 상황을 만들기 위하여 smurfland.snu.ac.kr의 네트웍을 끊어버렸다.

[portos@smurfland ~]$ sudo /etc/rc.d/init.d/network stop

그러자 잠시 후에 linux-smp에서 ping 패킷을 받기 시작했다.
제 3의 기계에서는 smurfland.snu.ac.kr의 네트웍이 끊어지더라도 계속 ping에 대한 응답을 받을 수 있었다.

다시 smurfland.snu.ac.kr의 네트웍을 복구하고, heartbeat을 실행시켰다.

[portos@smurfland ~]$ sudo /etc/rc.d/init.d/network start
[portos@smurfland ~]$ sudo /etc/init.d/heartbeat start

그러자 잠시 후에 다시 smurfland.snu.ac.kr이 ping 패킷을 받기 시작했다.
이렇게 linux-smp가 동작 중임에도 불구하고, smurfland.snu.ac.kr이 ping 패킷을 받게 되는 것은 heartbeat이 새로 실행되면서, arp 브로드캐스팅을 하기 때문이다.

끝으로 이 글을 올려주신 서상원님에게 감사를 표합니다.

이제 가장 중요한 설정하기이다. 설정화일이 있어야 하는 디렉토리는
/etc/ha.d
이다. 설정해야 할 화일은 세 가지가 있는데, ha.cf, haresources, authkeys 이다.
각 화일의 골격은 hearbeat-0.4.9/doc/ 아래에 있으니, 이 화일들을 /etc/ha.d 로 복사하여 수정하는 것이 편리하다.

[portos@smurfland ~/heartbeat-0.4.9/doc]$ sudo cp ha.cf haresources authkeys /etc/ha.d/

각각의 설정화일은 내가 설정한 것을 참조하기 바란다. 이것들은 소스에 포함된 문서에서 말하는 설정 방법과 거의 비슷하다. 
옵션에 대한 자세한 설명은 설정화일의 주석을 참조하거나 소스를 직접 분석해 보기 바란다. (ha.cf, haresources, authkeys)
Warning: 두 개의 기계에 설정화일은 완전히 동일하다. 

테스트에 사용된 기계는 펜티엄 III 866MHz, 램 256M 인 조립 PC(smurfland.snu.ac.kr)와 IBM Netfinity 4500R SMP 기계(linux-smp)였다. smurfland.snu.ac.kr과 linux-smp는 모두 DNS에 등록되지 않은 호스트 이름이다.
조립 PC의 경우에 'uname -n'이라고 치면 smurfland.snu.ac.kr 이라고 나오고, SMP 기계의 경우에는 'uname -n'이라고 치면 linux-smp 라고 나온다.
소스에 포함된 문서에서 'uname -n'이라는 명령을 주어서 화면에 나오는 것만 ha.cf의 node 항목에 넣으라고 하였다. 실제로 'linux-smp.snu.ac.kr'이라고 입력하면 어떤 결과가 발생되는지 실험해 보지 않았다. 궁금한 사람들은 한번쯤 해 봐도 말리지는 않겠다. 

그림. 설정 도식도

211.111.63.146은 smurfland.snu.ac.kr 호스트의 eth0 에 할당된 IP이고, 211.111.63.147은 linux-smp 호스트의 eth0 에 할당된 IP이다.
그리고 192.168.14.2는 smurfland.snu.ac.kr 호스트의 eth1 에 할당된 IP이고, 192.168.14.1은 linux-smp 호스트의 eth1 에 할당된 IP이다.
smurfland.snu.ac.kr 과 linux-smp 는 eth1끼리 크로스 케이블로 직접 연결되어 있다. 
위의 설정에서 primary는 smurfland.snu.ac.kr이고, standby는 linux-smp이다.
211.111.63.148은 eth0에 IP aliasing 되어 있다.

혹시 eth0와 eth1의 주소를 설정하는 방법을 모르는 사람이 있을지 모르겠다.
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-eth1
화일을 적당히 고친 후,

[portos@smurfland ~]$ sudo /etc/rc.d/init.d/network restart

라고 해주면 eth0와 eth1의 주소를 바꿀 수 있다. 

1. http://www.linux-ha.org/downlaod/에서 heartbeat의 소스를 다운받는다. 나는 버전 0.4.9를 다운받았다.
   
   
2. 압축을 푼다.

   [portos@smurfland ~]$ tar xzf heartbeat-0.4.9.tar.gz
   [portos@smurfland ~]$ 
   

3. 컴파일한다.

   [portos@smurfland ~]$ cd heartbeat-0.4.9
   [portos@smurfland ~/heartbeat-0.4.9]$ make
   [portos@smurfland ~/heartbeat-0.4.9]$
   

   'make rpm'을 하면 rpm으로 만들 수도 있다고 한다. 나는 개인적으로 rpm을 썩 좋아하지 않기 때문에 그냥 위와 같이 설치했다.
   
   그리고 C 라이브러리나 gcc 버전에 따라 컴파일이 잘 안 되는 경우도 있을지 모르겠다. 참고로 나는 레드햇리눅스를 기반으로 하는 와우리눅스 7.1을 사용하고 있으며, gcc 2.96, glibc 2.2.2, 커널은 2.4.5(이건 별로 상관이 없을 것 같지만...)를 사용하고 있다.
   나는 컴파일을 하다가 에러가 몇 가지 발생했다.
   heartbeat-0.4.9/stonith/expect.c 에서 CLK_TCK가 선언되지 않았다는 에러가 나왔는데, 이 화일에
   #include <time.h>
   를 추가로 인클루드하니까 이 문제가 해결되었다.
   heartbeat-0.4.9/heartbeat/hb_api.c 에서도 CLK_TCK가 선언되지 않았다는 에러가 발생했는데, 마찬가지로 이 화일에
   #include <time.h>
   를 추가로 인클루드하여서 문제를 해결했다.
   
   이런 에러가 모든 컴퓨터에서 발생한다고 생각되지는 않는다.
   
5. 
   
6. 설치한다.

   [portos@smurfland ~/heartbeat-0.4.9]$ sudo make install
   [portos@smurfland ~/heartbeat-0.4.9]$
   

   설치를 하면 다음과 같은 디렉토리 밑에 각종 화일들이 설치된다.

   /etc/ha.d
   /usr/lib/heartbeat
   /var/run/ppp.d
   /var/lib/heartbeat
   /etc/logrotate.d
   /usr/doc/heartbeat
   

이제 설치는 끝났다. 여기까지는 아주 쉽다.

heartbeat은 linux-ha 프로젝트에서 만든 툴이다. linux-ha 프로젝트의 목표는 리눅스 운영체제에 고가용성을 제공하는 것이다. 

인터넷 상에서 상용 서비스가 급속히 증가하고 있는데, 이런 것들은 중간에 중단되는 일이 없이 지속적으로 서비스를 제공하는 것이 중요하다. 이러한 특징을 고가용성이라고 하는데, 이러한 특징은 하드웨어나 소프트웨어를 중복되게 배치함으로써 가능하다. 

예를 들어 www.yahoo.com과 같은 회사는 http 서버가 잠시만 다운되어도 막대한 손실을 입을 수 있다. 이러한 회사는 http 서버를 2개(혹은 그 이상)를 둔다. 하나는 primary, 다른 하나는 standby이다. 평소에는 primary가 웹서버 역할을 하지만, primary가 고장이 나거나 갑자기 전원이 꺼지는 경우에는 standby가 primary 대신 웹서버의 역할을 한다. 이렇게 하면 외부에서 www.yahoo.com에 접속하는 사용자는 웹서버가 다운되었다는 사실을 전혀 알지 못 하고, 평소처럼 접속할 수 있다.

그렇다면 primary에 고장이 발생했다는 사실을 standby가 알 수 있어야만 primary를 대신해서 웹서비스를 할 수 있을 것이다. 이것은 어떻게 가능할까? 평소에 primary와 standby는 주기적으로 메세지를 교환한다. 이 메세지가 어느 시간 이상동안 도착하지 않으면 standby는 primary가 고장난 것으로 간주한다. 이 때 주고 받는 메세지를 heartbeat(심장 박동)이라고 한다. 위에서 이야기한 linux-ha 프로젝트에서 구현한 heartbeat이라는 툴은 이러한 메세지를 주고 받는 기능뿐만 아니라, 실제로 primary가 고장이 난 경우에 primary가 제공하던 서비스를 standby에서 제공할 수 있도록 하는 기능도 포함되어 있다.

- eht0 인터페이스를 거쳐가는 패킷 헤드를 확인 

tcpdump –i eth0 

- 캡쳐결과를 특정 파일로 저장하기 
tcpdump –i eth0 –w traffic.txt 

- 지정한 개수만큼만 캡쳐하기 
tcpdump –i eth0 –c 20 

- 특정호스트와 특정포트번호로 서비스되는 패킷 전체를 캡처하여 특정파일에 저장하기 
tcpdump –i eth0 –w traffic –s 1500 tcp port 22 and host 192.168.0.100 

저장한 파일을 텍스트포맷 확인하기 
tcpdump –r traffic.txt 

결과파일을 ASCII모드로 확인하기 

tcpdump –Xqnr traffic 

해당 디렉터리 이동후 ./실행파일명.sh

시스템 작업하던 직원이 java 관련 프로세스 종료를 kill -9 PID 를 하는 것을 보고 의아해서 물어보니 당연히 그렇게 하는 걸로 알고 있었다.

검색을 해 보니 거의 모든 블로그가 프로세스 종료를 -9 signal 로 처리하라고 되어 있어서 kill 명령의 의미 및 안전하게 프로세스 종료 하는 법을 정리해 본다.

kill 은 용도에 맞지 않게 이름이 지어진 명령어중의 하나이다. 주요 용도는 event 가 발생했음을 프로세스에게 알리는 것이다. signal 의 종류는 /usr/include/signal,h 에 정리되어 있다. (실제 선언부는 OS 의 종류에 따라 signal.h 에서 별도로 include 할 수도 있다)

Un*x 는 프로그램에서 signal 종류 별로 signal handler 를 지정할 수 있는데 유일하게 handler 를 지정할수 없는 시그널은 SIGKILL(9), SIGSTOP(19) 두 개의 시그널이다.

제대로 구현한 프로그램이라면 종료의 의미로 사용되는 signal (INT, HUP, TERM 등)을 받으면 resource 를 정리하는 cleanup 코드를 실행하고 종료하게 되어 있을 것이다.

프로세스 종료시 kill -9 PID 를 권장하는 않는건 제대로 signal handler 를 구현한 프로그램이라도 cleanup 작업을 하지 못하고 바로 종료되어 버릴수 있기 때문이다.

개인적으로 추천하는 방법은 먼저 kill -TERM PID 나 kill -HUP PID 같이 TERM(Termination) 나 HUP(Hangup) signal 을 날리는 것이다.

위의 signal을 날리면 제대로 된 프로그램은 보통 cleanup 코드를 수행하고 종료하게 구현되어 있다.

Java JRE 도 TERM 이면 깨끗하게 종료되니 tomcat 이나 기타 java 관련 프로그램 종료시 KILL(9)을 먼저 보내지 말고 두 세번 정도 TERM(15) 보내는 방법을 추천한다. (Linux의 service 명령어도 TERM 을 보내보고 안 죽으면 KILL 을 보내게 구현되어 있다)

여러개의 프로세스를 종료시킬 경우 다음과 같은 awk script 를 이용해서 종료할 수 있다.

httpd 를 종료할 경우 다음과 같이 수행하면 된다.

위의 script 를 두 세번 실행해 보고 종료가 되지 않는 process 가 있다면 SIGTERM 대신 SIGKILL 을 사용하면 된다.

모든 child process 까지 종료시키는 스크립트가 필요하다면 StackOverflow의 Best way to kill all child processes 쓰레드를 참조하자.

crontab 로그 확인

#cat /var/log/cron

crontab 설정 확인

#cat /var/spool/cron/root

#crontab -l