2013년 8월 31일 토요일

Diskless Server for linux

노하드 서버 설정하기



서버로 사용할 컴퓨터에 리눅스 를 잘 설치 하셨으면 이제 세팅을 할 차례 입니다..

서버에 세팅할것은



1. DHCP 서버 -- 클라이언트에 IP 어드레스를 할당해 주는 역활

2. TFTP 서버 -- 클라이언트에 윈도우 이미지를 전송 해주는 역활

3. ISCSI 서버 -- 하드가 없는 클라이언트에 네트웍으로 하드디스크를 연결해주는 역활

4. BTRFS 화일 시스템-- NTFS , FAT32 등의 화일 시스템의 한 종류입니다.. 이 화일 시

스템은 스냅샷 이라는 기능을 이용해 -- 이해 하기 쉽게 순간복구, 순간백업을 한다고보시

면 됩니다..



우분투는 root 계정이 잠겨있기 때문에 root 계정과 암호를 생성해야합니다.
설치시에 입력했던 계정으로 로그인하시고

sudo passwd root
입력후에 패스워드 설정하고 로그인하면 root 로 로그인 가능합니다.



1. 네트웍 설정

- 서버의 IP 어드레스를 설정 합니다..



/etc/network/interface 파일을 편집 합니다.. ( vi 편집기 사용하시면 됩니다. )



auto eth0
iface eth0 inet static
address 192.168.0.3 # 이컴의 ip 어드레스 입니다.
netmask 255.255.255.0
gateway 192.168.0.1 # 공유기 ip
dns-nameservers 192.168.0.1 # 공유기 ip 또는 dns 서버 주소


위와 같이 입력 하시면 인터넷이 연결 되었습니다..

연결이 잘 되었는지 확인해 봅니다.

아래와 같이 죽 숫자가 나오면 인터넷 연결 된겁니다..


root# ping yahoo.com
64bytes from ir1.fpvip.ne1.yahoo.com (98.138.253.109) : icmp_req=1 tt1=48 time = 247 ms
64bytes from ir1.fpvip.ne1.yahoo.com (98.138.253.109) : icmp_req=1 tt1=48 time = 247 ms
64bytes from ir1.fpvip.ne1.yahoo.com (98.138.253.109) : icmp_req=1 tt1=48 time = 247 ms
64bytes from ir1.fpvip.ne1.yahoo.com (98.138.253.109) : icmp_req=1 tt1=48 time = 247 ms


# 안나오면 틀린부분 있나 잘 살펴보시고 재시작 해보세요...



2. 서버 프로그램 인스톨



우분투는 인터넷에 연결되어 있으면 필요한 프로그램을 설치하기가 쉽습니다..



# DHCP 서버 프로그램 설치




root:/#apt-get install isc-dhcp-server



#TFTP 서버 프로그램 설치


root:/#apt-get install xinetd
root:/#apt-get install tftpd



#BTRFS-TOOLS 설치


root:/#apt-get install btrfs-tools



#iscsi 서버 설치


root:/#apt-get install iscsitarget



3. ISCSI 볼륨 만들기



- 위의 프로그램이 전부 인스톨 되어 있으면 프로그램 세팅에 들어갑니다..

ISCSI TARGET 설정으로 하드가 없는 클라이언트에 하드 디스크를 볼륨을 만들어 줍니다..



!! 여기서 잠깐 보통 네트웍 드라이브와 이 ISCSI 디스크 볼륨이 다른것은 컴퓨터 끼리 하드를 공유하면

내컴퓨터에서 보면 하드디스크 C, D 와는 다르게 아이콘이 네트웍 연결로 표시가 되지만

ISCSI 로 연결된 하드 디스크는 C, D 와 동일한 볼륨 아이콘 모양도 똑같이 표시가 됩니다..

컴퓨터에 하드가 연결된것 처럼 사용합니다..



- 처음에 리눅스 인스톨할때 100GB BTRFS 파일 시스템으로 /iscsi 로 마운트 해서 만들 었습니다.


root:/# mkdir /iscsi/image ----> image 폴더 생성
root:/# chmod 755 /iscsi/image ----> image 권한 설정
root:/# btrfsctl -S win7 /iscsi/image ----->image 폴더에win7 서브 볼륨 생성 -- 이곳에 win7 이미지 넣을 예정
root:/# chmod 755 /iscsi/image/win7 ------>win7 권한 설정



- 볼륨 이미지 생성


root:/# dd if=/dev/zero of=/iscsi/image/win7/win7.img bs=1048576 count=50000

위의 명령은 50기가를 빈 공간으로 이미지를 win7.img 를 만듭니다.. 쉽게 윈도우7 을 설치할 빈공간 50 기가를

만드는것 입니다. 그럼 win7.img 라는 파일이 하드 디스크가 된다고 보시면 됩니다.



- 약간의 시간이 지나면 끝납니다..



그럼 ISCSI 서버 환경 파일을 수정 합니다..

/etc/default/iscsitarget 파일을 수정 합니다.


ISCSITARGET_ENABLE=true ----- > true 로 수정하시고 저장하시면 됩니다.

/etc/iet/ietd.conf 파일의 마지막에 다음을 추가 합니다.


Target iqn.2013-06.test.com:client1 -----> iscsi target 이름
Lun 0 Path=/iscsi/image/win7/win7.img,Type=fileio ------> target 이미지 path

Alias client1 --> 별명 생략가능
MaxConnecions 1 ------> 연결 생략가능


apt-get install iscsitarget-dkms 이거를 설치를 해줘야 정상적으로 작동된다.

Iscsi target 재시작


root:/# service iscsitarget restart

에러 없이 ok 나오면 정상적으로 이미지를 생성한것이고 틀리면 위를 다시한번 살펴 보세요





4. 클라이언트가 연결할 DHCP, TFTP, gPXE 설정



- 클라이언트가 서버에 연결하여 부팅 할수 있도록 하는 과정 입니다..

- 하드 디스크 없이 부팅을 하기 위해 네트웍 부팅을 할수 있도록 준비를 합니다..




http://rom-o-matic.net/gpxe/gpxe-1.0.1/contrib/rom-o-matic/






에 접속 해서 undionly.kpxe 를 다운로드 합니다.. -- 다운로드 하기 힘드시면 아래 첨부화일 받으세요



- dhcp 설정 클라이언트가 서버에 연결되어 자동으로 IP 를 할당 받고 하드 없이 네트웍으로 부팅이 가능하도록

설정을 합니다.



subnet 192.168.0.0 netmask 255.255.255.0 {
range dynamic-bootp 192.168.0.100 192.168.0.200;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;

}
host client1 {
hardware ethernet 00:00:00:00:00:00; ------> 클라이언트의 맥어드레스
fixed-address 192.168.0.10; -------> 위의 클라이언트에 아이피 등록
if exists user-class and option user-class = "gPXE" {
filename "";
option root-path "iscsi:192.168.0.3::::iqn.2013-06.test.com:client1"; -- > 서버주소와 iscsi target 이름
} else {
filename "undionly.kpxe";
}
}




위에서 중요한것은 클라이언트의 맥어드레스 입니다..

클라이언트의 CMOS SETUP 에 들어가 랜카드로 부팅이 가능하도록 Boot from LAN Enable

바꾸고 부팅순서도 NETWORK 1 번으로 바꾸고 부팅을 하면





위에 00:---- 죽 있조 그거 를 입력 하시면 됩니다 모든컴은 모두 맥어드레스가 다릅니다..

-TFTP 설정


/etc/xinetd.d/tftp 파일 편집

service tftp
{
disable = no --- >
이것만 yes no 로 하시면 될듯
socket_type = dgram
protocol = udp
wait = yes
user = nobody
server = /usr/sbin/in.tftpd

server_args = -s /tftpboot
}


#############################

아까 다운받은파일 gpxe-1.0.1-undionly.kpxe
/tftpboot 폴더로 복사하여 이름을 undionly.kpxe 로 바꾸어 놓습니다.


DHCP 서버 재시작


root:/#service isc-dhcp-server restart

위의 모든 설정이 잘 끝났으면 ok 가 나옵니다. 그럼 서버는 준비 끝 입니다..

그럼 클라이언트와 서버를 연결하면 되는데 .. 이것도 쉽게 접근 하겠습니다..

우선 하드를 한개 준비하여 100G 라고 보고 50 으로 둘로 나눠 앞에 윈도우 7 을 설치 합니다..

자동으로 패치를 해보자

이번에는 게임을 자동으로 패치하고 패치된 내용을 한번에 전 피씨에 일괄적용 하거나 선택 적으로
적용할수 있는 방법에 대해 알려 드립니다..
1. 게임패치

    게임 패치는 클라이언트 피씨 한대를 게임 패치 또는 기타 작업용 피씨로 별도로 빼어서
    작업을 하는 방식이 좋을것 같습니다. 뭔가 수정을 한다거나, 추가를 한다거나 하면
    일괄적으로 100 여대의 컴퓨터가 있다고 가정하면 한번에 패치 / 수정 이 가능 하니까요!!

  -- 게임 패치는 피카툴이나 게토의 게임 패치 기능을 사용합니다.. 다른 패치툴도 가능합니다..
     
  
-- 지난번  처음 만들어 놓은 원본 이미지가 /iscsi/image/win7 입니다.. 이것의 클론들이 /iscsi/image/pc1 ~
      입니다.. 여기서 우리는 새로운 패치 클론을 한개 만들어 놓습니다.. 또한 원하면 패치 1, 패치 2 이렇게
      여러개 만들수 있습니다.. 패치를 적용했는데 문제가 생기면 이전 패치된 내용으로 되돌리기쉽기 때문
     입니다..
 root:iscsi/image/# btrfsctl -s win7-patch1 win7        
   - 그럼 win7-patch1 이란 클론이 만들어 집니다..
 /etc/iet/ietd.conf 에 다음 내용을 추가해 줍니다..
Target iqn.2013-06.test.com:patch          ----->   패치용 컴
            Lun 0 Path=/iscsi/image/win7-patch1/win7.img, type=fileio   
 /etc/dhcp/dhcpd.conf 파일 아래에 수정를 합니다.
 subnet 192.168.0.0 netmask 255.255.255.0 {
range dynamic-bootp 192.168.0.100 192.168.0.200;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;

}
host pc1 {
  hardware ethernet 00:05:05:01:01:01:01;    ------> 패치용 PC   맥어드레스
  fixed-address 192.168.0.100;             -------> 패치용 PC 가 사용할 IP 
  option host name "pc1";
  if exists user-class and option user-class = "gPXE" {
     filename "";
     option root-path "iscsi:192.168.0.3::::iqn.2013-06.test.com:patch";   -- > 패치 PC 가 사용할 ISCSI  target 이름
} else {
     filename "undionly.kpxe";

  -- 위와 같이 내용을 추가 수정해 주면 패치용 컴퓨터를 사용할 수 있습니다..
  -- 그럼 피카툴즈(기타다른패치로 한대의 패치용 컴퓨터를 패치해 주면 됩니다..
  -- 또한 문제가 있거나 특정 레지스트리를 수정해야 할때 수정해주면 됩니다..

2. 패치 / 또는 수정된 내용 모든 피씨 또는 개별 피씨에 적용하기

  -- 우선 사용중인 클라이언트의 복제된 내용을 변경하려면 기존에 사용하던 이미지를 삭제하고
     새로 바뀐 내용으로 변경을 시켜 줘야 합니다.. 문제는 사용중인 피씨의 이미지를 변경하면
      아주 잠깐이지만 연결이 끊기게 됩니다..  -- 이점 주의 하시길 바랍니다.. --

root:/# cat /proc/net/iet/volume         --- 우선 iscsi 볼륨이 구성된 내용을 출력

tid:5 name:iqn.2013-06.test.com:patch
                 lun:0 state:0 iotype:fileio iomode:wt blocks:500000000 blocksize:512 ........
tid:4 name:iqn.2013-06.test.com:pc4
                 lun:0 state:0 iotype:fileio iomode:wt blocks:500000000 blocksize:512 ........
tid:3 name:iqn.2013-06.test.com:pc3
                 lun:0 state:0 iotype:fileio iomode:wt blocks:500000000 blocksize:512 ........
tid:2 name:iqn.2013-06.test.com:pc2
                 lun:0 state:0 iotype:fileio iomode:wt blocks:500000000 blocksize:512 ........
tid:1 name:iqn.2013-06.test.com:pc1
                 lun:0 state:0 iotype:fileio iomode:wt blocks:500000000 blocksize:512 ........

위의 볼륨을 출력하면 위와 비슷한 내용이 출력이 됩니다.. /etc/iet/ietd.conf 에서 순서대로
tid 번호가 붙어있는 것을 볼수 있습니다.. 여기서 tid 번호를 잘 보시면 됩니다.. pc1 이미지가 tdi 1 
으로 되어 있습니다..
위의 번호는 ietd.conf 순서가 바뀌면 번호가 달라 집니다.. 위의 명령으로 몇번에 몇번 이미지인가
보시면 됩니다..
 root:/# ietadm --op delete --tid=1 --lun=0   --  pc1  iscsi 이미지 연결이 끊어집니다.
root:/# btrfs subvolume delete /iscsi/image/pc1   - pc1 번 클론 이미지를 삭제합니다.
root:/# btrfs subvolume snapshot /iscsi/image/win7-patch1/iscsi/image/pc1  -- 패치된 이미지를 pc1 로 클론합니다.
root:/# ietadm --op new --tid=1 --lun=0 --params Path=/iscsi/image/pc1/win7.img  --클론된 이미지를 iscsi 연결

위의 4 단계를 거쳐야 패치된 이미지를 새로운 이미지로 변경하여 사용할 수 있습니다..
저렇게 일일이 쓰려면 힘이 듭니다.. 여기서 조금 쉽게 가보도록 하겠습니다..
 root:/#mkdir manage                       --- manage 폴더를 만듭니다.
root:/#chmod 755 manage               --- 권한을 설정해 줍니다.
root:/#cd manage                              --- manage 폴더로 들어갑니다
root:/#vi pc1.sh                                      --- 편집기로 pc1 파일을 편집합니다.

ietadm --op delete --tid=1 --lun=0 
btrfs subvolume delete /iscsi/image/pc1             
btrfs subvolume snapshot /iscsi/image/win7-patch1/iscsi/image/pc1  
ietadm --op new --tid=1 --lun=0 --params Path=/iscsi/image/pc1/win7.img 
 :w 저장 하고 나옵니다.
root:/#chmod 755 pc1.sh                       --- 파일에 권한 설정

이렇게 실행 파일을 한개 만들어 주면 실행하면 위의 4 가지 명령이 죽~~ 실행이 됩니다..
그럼 1 번 피씨가 패치된 내용으로 바뀌겠죠.. 여기서 아까도 말씀드렸지만 1 번 피씨가 사용
하고 있는 도중에 명령을 실행하면 약간 멈춤 증상이 있으니.. 되도록이면 사용 안할때나
게임을 하지 않고 좀 쉬고 있을때 하면 1 초면 작업 끝납니다..

root:/#/manage/pc1.sh                -- 이렇게 실행 하시면 1 번 피씨 패치 실행
이제 2 ~ 100 번 때 까지
root:manage/#cp pc1.sh pc2.sh        --- pc1.sh  pc2.sh 로 복사
root:manage/#vi pc2.sh                     --- pc2.sh 를 편집

ietadm --op delete --tid=2 --lun=0                              ----- tid 번호 수정
btrfs subvolume delete /iscsi/image/pc2                    ----- pc2 로 수정             
btrfs subvolume snapshot /iscsi/image/win7-patch1 /iscsi/image/pc2     --pc2 로 수정
ietadm --op new --tid=2 --lun=0 --params Path=/iscsi/image/pc2/win7.img    --- tid 2, pc2 수정

이렇게 100 번대 까지 죽 만들어 놓고 하나씩 실행할 수도 있고
root:manage/#vi all.sh
/manage/pc1.sh
/manage/pc2.sh
/manage/pc3.sh
...
/manage/pc100.sh

all.sh 를 만들어 전체 피씨를 패치 할 수 있습니다..
자 이렇게 이번 내용을 보시면 패치나 수정이 쉽게 될수 있다는것을 아실겁니다..
여러분은 약간의 수정을 하셔서 사용 하시면 되구요..
그럼 패치가 완료되면 자동으로 적용된 패치를 스냅샷을 만들어 볼까요?

3. 예약 작업기능으로 패치 완료된 스냅샷을 자동으로 실행 해보자

리눅스에 예약 작업 기능을 이용 스케쥴을 짜서 원하는 시간에 원하는 명령을 실행
할수 있는 기능을 활용하여 패치가 끝날쯤 작업을 자동으로 실행 하면 됩니다.
기본 형식은
00 00 00 00 0 /manage/pc1.sh     
첫번째 00 은  0~59
두번째 00 은 시간 0~23 시간
세번째 00 은 날자 1~31 
네번째 00 은  1~12 
다섯번째 00 은 요일 0 (일요일 ) 1(월요일)~ 6(토요일) 0~6 요일
여섯번째 는 명령
인수를 * 으로 표시하면 매번 이라는 뜻 입니다.
30 * * * * /manage/pc1.sh  ----- > 이렇게 되면 매시간 30 분 마다 /manag/pc1.sh 를 실행한다/
 -위의것은 1시30 , 2시30 분 3시30 분 .. 결국 1시간 마다 실행되는것 입니다.-
*/40 * * * * /manage/pc1.sh   ----> 40 분 마다 실행 -- 위것과 다릅니다..
 - 이것은 숫자 앞에 */ 를 붙이면 뒤의 숫자 만큼 반복입니다.. 즉 40 분 마다 실행 -
30 1 * * 3 /manage/pc1.sh  ----- > 이렇게 되면 매주 수요일 새벽 1 30 분마다 실행


그럼 직접 입력을 해봅시다.
root:manage/#crontab –e      -- > 편집기 실행
# edit ……등등
# … 아래에 넣으면 됩니다.
# m h dom mon dow command
#30 1 * * 3 /manage/pc1.sh
30 1 * * 3 /manage/all.sh  ----- > 이렇게 되면 매주 수요일 새벽 1 30 분마다 실행
게임 패치별 시간에 따라 전게임 패치 하게 패치 서버 해놓구 끝나는 시간이 에 맞추어
예약 실행을 걸어 놓으면 패치가 끝남과 동시에 클론을 자동 생성하면 모든 사용자 분들이
패치 완료된 게임을 사용할 수 있습니다..
어떤가요.. 일일이 한대씩 패치하면 그 시간만큼 전기세도 나올테고.. 이렇게 하드 디스크 없이
사용하시면 좋습니다..

위의 명령을 처음 실행시 편집기를 어떤 것을 사용할것이냐 묻습니다.. vi 편집기 를 선택하시면
좋습니다..( 수정도 편합니다. )

예약 기능 실행하기
/etc/init.d/cron start


그래도 이정도면 충분히 피씨방 / 전산실 에서 응용하실수 있을것으로 생각됩니다..

다음편은 무정지 보조 서버를 만드는것을 해볼텐데요.. 좀 시간이 걸릴것 같습니다..

지금까지의 내용은 제가 직접 만들어서 사용해본 내용입니다.. 보조 서버도 직접 작업을

해서 동작에 이상 없는지 확인후 올리도록 하겠습니다. ^^
노하드 보조 서버 만들기
보조 서버는 주서버가 동작을 중지하는경우 ( 전원이 나갔다거나갑자기 다운되어 멈추었을 경우)
보조 서버가 자동으로 동작하여 주서버의 기능을 대신하는 것 입니다..  365 일 무정지 서비스

 

중요한 원리부터 알려드리자면
위의 그림에서 주서버와 보조 서버 사이에 VIP 라고 하는 것은 가상 IP 입니다..이제부터 모든
PC 는 가상 IP 로 연결을 합니다.. 그러면 우선 주서버로 자동으로 연결이 됩니다..
서버 사이의 심장은 심장박동 프로그램 ( Heartbeat ) 을 서로 주고 받고 해서 죽었는지 살았는지
체크를 합니다.. 그래서 만약 주서버가 죽으면 VIP 로 연결을 하면 자동으로 보조 서버로 연결이
됩니다.

그럼 보조 서버를 만들어 보겠습니다..

첫번째 주서버와 동일하게 프로그램을 세팅합니다..
IP 만 다르게 설정을 하시면 됩니다.. 위의 그림에서 처럼

두번째 주서버에 설치된 윈도우 이미지를 복사 합니다..
-       여기서 중요한문제 BTRFS 스냅샷은 동일 컴퓨터의 같은 폴더내에서 가능합니다.
-       보조서버로 스냅샷 복사를 하면 원래 이미지 용량으로 스냅샷이미지가 아닌 원래의
이미지 크기많큼 복사가 됩니다..( 스냅샷 이미지가 아닙니다. – 다른곳으로 넘어갈때는 )
따라서 1 초가 아닌 1 시간 정도의 시간이 걸립니다.. 용량 크기많큼 시간도 변합니다.
보조 서버로 넘어온 이미지로 다시 스냅샷을 만듭니다.
그외 주서버의 설정을 그대로 하시면 됩니다..

서버 Heartbeat 설치 및 설정
그럼 서버에 서로 동작중인지 감시를 하며 VIP 할당을 받는 프로그램 을 설치 및 설정을 합니다.

둘다 프로그램 설치를 합니다.
주 서 버 # apt-get install heartbeat
보조서버 # apt-get install heartbeat

설정을 합니다.
우선 각자 아이피 설정 상태를 확인합니다.
( ip 는 예제이니 각자에 맞는 ip 로 설정하시면됩니다.)
주 서버 # cat /etc/network/interfaces
auto eth0
iface eth0 inet static

        address 1.1.1.2
        netmask 255.255.255.0
        gateway 1.1.1.1
        broadcast 1.1.1.255   

보조 서버 # cat /etc/network/interfaces
auto eth0
iface eth0 inet static

        address 1.1.1.3
        netmask 255.255.255.0
        gateway 1.1.1.1
        broadcast 1.1.1.255   

위에서 잘보셔야 할것이 eth0 입니다랜카드 번호 입니다.. 랜카드가 여러장이면 eth0, eth1
계속 숫자가 붙습니다.
 /etc/hosts 파일을 확인후 서버 이름을 등록해줍니다둘다 똑같이 해줍니다.
아래 cat 명령은 파일을 보는것이고 vi 편집기를 사용 하셔서 추가 하시면 됩니다.
주 서 버 : # cat /etc/hosts
보조서버 : # cat /etc/hosts
127.0.0.1         localhost
1.1.1.2           server1
1.1.1.3           server2


3. heartbeat 설정 파일을 편집합니다.
 /etc/ha.d/ 폴더에 authkeys , ha.cf, haresources 가 있는지 봅니다.. 없을경우
/usr/share/doc/heartbeat 문서를 압축을 풀면 heartbeat 폴더에 위의 파일이 있습니다.
주 서 버 : cd /usr/share/doc
주 서 버 : gzip –d heartbeat
주 서 버 : cd heartbeat

첫번째 /etc/ha.d/ 폴더의 authkeys 파일을 편집합니다..
auth 2
2 sha1 HI!
파일 안의 # 표시를 지워 주시거나 없으면 입력해 주시면 됩니다.
주 서 버 : chmod 600 /etc/hd.d/authkeys
편집된 파일의 권한을 변경시켜 줍니다.
두번째 /etc/ha.d/ 폴더의 ha.cf 파일을 편집합니다.
debufile /var/log/ha-debug
logfile /var/log/ha-log
keepalive 1    -- 1 초마다 서로 살아 있는지 체크   
deadtime 3    -- 3 초동안 신호 안오면 죽었다고 판단
initdead 3     -- 서버 시작후 대기 시간
udpport 694   –- 신호 포트
bcast eth0     -- 신호를 주고 받을 랜카드
node server1   -- 마스터 서버
node server2   -- 슬레이브 서버 ( 순서가 중요합니다위의것이 마스터 아래는 보조 )

세번째 /etc/ha.d/ 폴더의 haresources 설정
server1 IPaddr::1.1.1.1/24/eth0 isc-dhcp-server
위의 설정을 보시면 처음에 설명한 VIP 번호와 어떤 서비스를 주고 받느냐 하는것입니다.
노하드 시스템을 하시면 DHCP 기능이 우선이기 때문에 위와 같이 하시면 됩니다.

 네번째 설정이 완료된 파일을 보조서버의 /etc/ha.d 폴더로 위의 3 개 파일을
복사해 넣으시면 됩니다.

 다섯번째 /etc/dhcp/dhcpd.conf 파일의 iscsi 연결 부분의 ip 를 수정 합니다..
Option root-path “iscsi:1.1.1.2:::iqn.pc.com:pc1”;

Option root-path “iscsi:1.1.1.1:::iqn.pc.com:pc1”;
위와 같이 새로 설정된 가상 ip 로 변경을 해주셔야 서버가 죽어서 보조로 연결이 되어도
이상 없이 사용 할 수 있습니다.

여섯번째 dhcp 서버를 서버 시작시 자동으로 실행하지 않도록 서비스 삭제
주 서 버 : /usr/sbin/update-rc.d –f isc-dhcp-server remove
보조서버 : /usr/sbin/update-rc.d –f isc-dhcp-server remove
위의 명령으로 서버에서 dhcp 기능을 부팅시 실행하지않고 주서버가 실행을 하다 장애시
보조서버로 넘겨서 실행할 때 dhcp 기능도 살아나서 동작을 하게 됩니다.. 주서버 기능복구시
보조 서버가 죽고 주서버로 다시 넘어옵니다..
그럼 서비스를 실행합니다.
주 서 버 : service heartbeat start
보조서버 : service heartbeat start

그럼 확인해 볼까요
주 서 버 : # ifconfig
eth0      Link encap:Ethernet  HWaddr 00:00:00:00:00
          inet addr:1.1.1.2  Bcast:1.1.1.255  Mask:255.255.255.0
          inet6 addr: fe80::208:9fff:feda:3aa8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:643007 errors:0 dropped:0 overruns:0 frame:0
          TX packets:994252 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:477995747 (477.9 MB)  TX bytes:1236079843 (1.2 GB)

eth0:0    Link encap:Ethernet  HWaddr 00:00:00:00:00
          inet addr:1.1.1.1  Bcast:1.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:14720 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14720 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2299839 (2.2 MB)  TX bytes:2299839 (2.2 MB)

위에 보시면 eth0:0 이 생겨 있고 IP 주소가 1.1.1.1 가상 아이피가 생겨 있습니다..
저 가상 IP 주소로 접속이 됩니다..
보조 서버에서 실행해 보시면 eth0:0 이 없을겁니다..
그럼 주서버 랜선을 확 빼보세요
그리고 보조 서버에서 보면
보조서 버 : # ifconfig
eth0      Link encap:Ethernet  HWaddr 00:00:00:00:00
          inet addr:1.1.1.3  Bcast:1.1.1.255  Mask:255.255.255.0
          inet6 addr: fe80::208:9fff:feda:3aa8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:643007 errors:0 dropped:0 overruns:0 frame:0
          TX packets:994252 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:477995747 (477.9 MB)  TX bytes:1236079843 (1.2 GB)

eth0:0    Link encap:Ethernet  HWaddr 00:00:00:00:00
          inet addr:1.1.1.1  Bcast:1.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:14720 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14720 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2299839 (2.2 MB)  TX bytes:2299839 (2.2 MB)

보조서버에 eth0:0 이 생기면서 ip 가 넘어 오게됩니다.. 그러면 앞으로 접속될 컴퓨터나
기존에 연결되었던 컴퓨터도 전부 이쪽으로 연결이 됩니다..
테스트 해보세요.. 무하드로 연결되어 사용할 때 주서버 랜선을 확 빼면..
계속 사용할 수 있습니다.. 물론 약간의 딜레이가 생길수 있으나 다운된다거나 하지는 않습니다.
제가 몇번의 테스트를 했기 때문에 해보시면 됩니다. ^^
서버간의 동기화
서버간의 동기화는 주서버와 보조서버간의 윈도우 이미지 가 동일해야 한다는 것 입니다..
주서버는 윈도우 업데이트가 되거나해 내용이 많이 변경이 되었고 보조서버는 처음 설치
상태로 패치가 되어 있지 않은 상태라면 갑자기 주서버가 죽었을 경우 보조서버로 연결이되면

클라이언트는 오류를 내뿜고 제대로 쓸수가 없게 됩니다.. 그럼 보조서버가 있으나 마나한 존재가 됩니다..
그래서 주서버와 보조서버의 이미지를 최소 하루에 한번씩 같게 만들어 줍니다.
문제는 서버간에는 스냅샷 기능이 되지 않습니다.. 해서 전송을 하면 실제 100G 면 용량 그대로
전송이 됩니다.. 그러면 1 시간 정도 소요가 되겠죠 그리고 전송하는데 트래픽이 발생해서 다른
사람들이 접속이 느려지게 됩니다.. 그래서 사용이 적은 시간대에 동기화를 시켜 줍니다..
이 방법은 주서버와 보조서버가 70 대 미만 사용처에서 보조서버가 항시 대기중으로 있는경우에
해당이 됩니다.. 서버 두개가 동시에 동작되는 경우는 이렇게 동작시킬수가 없습니다.. ^^

 

우선 동기화 프로그램을 설치하여 세팅을 하겠습니다..
프로그램 설치 / 주서버 / 보조서버 둘다 설치 합니다.
# apt-get install rsync

/etc/default/rsync 파일을 수정합니다.
# vi /etc/default/rsync
RSYNC_ENABLE=true


보통 주서버에서 프로그램을 실행 하지만 조금이라도 주서버에 영향을 주지 않도록
보조 서버에서 정해진 시간에 끌어 오도록 합니다..
보조 서버에서 실행을 합니다.
# rsync –avz –delete root@1.1.1.1:/btrfs/sync/win.img /btrfs/sync/

위의 내용은 주서버의 ip 1.1.1.1 이고 가져올 파일 서버쪽 /btrfs/sync/win.img 를 보조서버인
/btrfs/sync 폴더로 가져오는 것 입니다..

주서버와 보조서버의 내용이 같지만 이미지는 다르기 때문에 지난번 주서버의 스케쥴 기능중
패치서버 내용은 보조서버에 삭제 하시고 위의 명령을 sync.sh 파일에 넣어 스크립트 파일을
만들어서 보조서버의 스케쥴은
#crontab -e

순간복구 스케쥴도 보조서버는 1 번만 합니다.. 동기화 된후 1 번만 실행하도록 합니다.
시에 패치서버가 패치를 끝내면 주서버가 win0  sync 같이 만들도록 합니다
주서버에서 아래 와 같이 patch.sh 파일을 편집해서 완료이미지 만들 때 sync 이미지도 같이
만들어 주면 됩니다Sync 이미지와 패치 완료된 이미지는 iscsi 로 연결할 필요 없습니다
#btrfsctl –s win-0 patch
#btrfsctl –s sync patch


아래와 같이 보조서버의 스케쥴은 5 시에 패치가 끝나면 주서버에서 sync 이미지를 가져 옵니다
그리도 전체 복구를 한번 하게 됩니다그러면 언제라도 주서버에 문제가 생기면
보조서버가 바로 대응을 하게 됩니다.^^
* 5 * * * /manage/sync.sh
30 6 * * * * /manage/all.sh

다음번 내용은 100 여대 이상일경우 서버 두대가 동시에 가동되는 경우 세팅과 동기화에 대해
올려볼까 합니다. ^^








2013년 6월 1일 토요일

IIS(Windows 7) + PHP + MySQL 설치

IIS는 윈도우즈 7 프로페셔널 버전 이상부터 설치가 가능하며
제어판 -> 프로그램추가삭제 -> IIS설치

 
다음과 같이 설치 한다. 이 외에 다른 설치파일은 Windows Platforms를 통해 설치를 한다. 다운로드 경로는 다음과 같음. http://www.microsoft.com/web/downloads/platform.aspx
 
플랫폼을 설치 후에 검색을 하여 PHP 5.XX 과 MYSQL 5.1 Version을 설치를 한다. IIS와 PHP간의 모듈은 모두 자동으로 올라가기 때문에 따로 수동으로 설정해야하는 부분이 없다.
 
IIS+PHP+Mysql 설치는 이것으로 모두 완료.
 
데이터베이스 관리를 위해 Navicat 프로그램을 설치를 한다.
 
 
Xenforo 데이터베이스를 생성하고 후에 Xenforo 인스톨시에 데이터베이스 이름을 물어볼때 xenforo 라고 입력한다.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


2012년 9월 12일 수요일

리눅스 Run level 이란?

이번에는 리눅스의 런 레벨에 대해 알아 보겠습니다. 우선 Run level이 무엇인지부터 알아야겠죠?
런레벨(Run level)이란, 시스템 관리의 용이함을 위하여 서비스의 실행을 단계별로 구분하여 적용하는 것을 말합니다.

런레벨은 0부터 6번까지 있는데요. 한번 알아보겠습니다.

# 0 - halt (DO NOT set initdefault to this)
시스템 종료를 의미합니다. 즉, 런레벨 0으로 변경하라는 명령을 내리면 시스템을 종료하는 것이죠.
# 1 - Single user mode
시스템 복원모드라고도 하며, 기본적으로 관리자 권한 쉘을 얻게 됩니다.
주로, 파일시스템을 점검하거나 관리자 암호를 변경할 때 사용합니다.
# 2 - Multiuser mode, without NFS (The same as 3, if you do ot have networking)
NFS(Network File System)을 지원하지 않는 다중 사용자 모드입니다.
네트워크를 사용하지 않는 텍스트 유저모드라고 할 수 있죠.
# 3 - Full muliuser mode
일반적인 쉘 기반의 인터페이스를 가진 다중 사용자 모드입니다.
쉽게 말하면 그래픽 유저 모드가 아닌 '텍스트 유저 모드'입니다.
# 4 - unused
4번은 쓰이지 않습니다. 기본적으로는 사용되지 않지만, 임의로 정의해서 사용할 수 있는 레벨입니다.
# 5 - X11기본적으로는 level 3과 같습니다. 다른 점은 '그래픽 유저 모드' 라는것!!!
# 6 - reboot (DO NOT set initdefault to this)
시스템 재부팅을 의미합니다. 런레벨 6으로 변경하라는 명령을 내리면 시스템을 재부팅 하죠.



주로 사용하게 되는 것은 0, 3, 5, 6 을 많이 씁니다. 이 런레벨의 변경은 root 사용자의 경우만 가능합니다. 즉, 터미널 창에서 관리자 모드로 들어가 gedit /etc/inittab을 입력하면 런레벨을 바꿔줄 수 있습니다. 한번 해볼까요?




터미널 창을 켜고, 관리자 모드로 들어갑니다. gedit /etc/inittab 명령어를 입력해주세요.




그럼 아래와 같은 창이 켜지죠. 위에서 봤던 runlevel에 안내가 나옵니다.




그리고 그 간단한 안내 아래에서..! 런레벨을 바꿔줄 수 있습니다.
한번 텍스트 유저 모드로 바꿔볼까요? 블록한 부분을 봐주세요 :)




5를 3으로 바꿔주고 빨간색 네모로 강조한 '저장' 버튼 클릭하면 끝! 입니다 :)




그럼 이제 시스템을 다시 시작해볼까요? 아래 화면과 같이 텍스트 모드로 시작되는 것을 볼 수 있습니다. :)




다시 그래픽 유저 모드로 돌아가고 싶을 때는, init 명령어를 이용하시면 됩니다. 이렇게요. :)
inittab이나 init 명령어 처럼 런레벨을 변경하는 것은
오직 관리자 모드에서만 가능하므로 su - 부터 입력해주셔야합니다.




그럼 명령어 입력하기 무섭게 그래픽 유저 모드로 넘어가지요.






명령어 init단순히 런레벨을 변경해서 부팅하는 명령어이기 때문에
시스템 종료후, 이대로 다시 부팅하게 되면 텍스트 유저 모드로 부팅하게 됩니다.

다시 그래픽 유저 모드로 바꿔주려면,
 로그인하셔서 아까처럼 터미널 창에서 관리자 모드로 바꿔주고 gedit /etc/inittab 입력후
inittab창에서 id:3:initdefault → id:5:initdefault 로 바꿔주시면 됩니다. :)

2012년 9월 5일 수요일

DHCP General Operation and Client Finite State Machine

DHCP General Operation and Client Finite State Machine
Dynamic address allocation is probably the most important new capability introduced by DHCP. In the last section I discussed in detail the significance of the change from IP address ownership to IP address leasing. I also provided a high-level look of the activities involved in leasing, by providing an overview of the DHCP lease “life cycle”.
An overview of this sort is useful to get a general handle on how leases work, but to really understand the mechanics of DHCP address assignment and client/server communication, we need more detail on how the devices behave and what messages they send. One tool often employed by networking engineers to describe a protocol is a theoretical model called a finite state machine (FSM). In this technique, the protocol's specific behavior is illustrated by showing the different states a device can be in, what possible transitions exist from one state to another, what events cause transitions to occur, and what actions are performed in response to an event. The TCP operational overview contains more general background information on finite state machines.
The DHCP standard uses an FSM to describe the lease life cycle from the perspective of a DHCP client. The client begins in an initial INIT state where it has no lease, and then transitions through various states as it acquires, renews, rebinds and/or releases its IP address. The FSM also indicates what message exchanges occurs between the server and client at various stages.
Some people think finite state machines are a little “dense” and hard to understand, and I can see why. You can skip this topic of course, but I think the FSM provides a useful way of illustrating in a comprehensive way most of the behavior of a DHCP client. Table 188 describes each of the DHCP client states, and summarizes the messages sent and received by the client in each, as well as showing the state transitions that occur in response. The FSM’s states, events and transitions are easier to envision in Figure 262, which also incorporates a color coding scheme so you can see which states are associated with each of the main DHCP processes.

Table 188: DHCP Client Finite State Machine
State
State Description
Event and Transition
INIT
This is the initialization state, where a client begins the process of acquiring a lease. It also returns here when a lease ends, or when a lease negotiation fails.
Client Sends DHCPDISCOVER: The client creates a DHCPDISCOVER message and broadcasts it to try to find a DHCP server. It transitions to the SELECTING state.
SELECTING
The client is waiting to receive DHCPOFFER messages from one or more DHCP servers, so it can choose one.
Client Receives Offers, Selects Preferred Offer, Sends DHCPREQUEST: The client chooses one of the offers it has been sent, and broadcasts a DHCPREQUEST message to tell DHCP servers what its choice was. It transitions to the REQUESTING state.
REQUESTING
The client is waiting to hear back from the server to which it sent its request.
Client Receives DHCPACK, Successfully Checks That IP Address Is Free: The client receives a DHCPACK message from its chosen server, confirming that it can have the lease that was offered. It checks to ensure that address is not already used, and assuming it is not, records the parameters the server sent it, sets the lease timers T1 and T2, and transitions to the BOUND state.
Client Receives DHCPACK, But IP Address Is In Use: The client receives a DHCPACK message from its chosen server, confirming that it can have the lease that was offered. However, it checks and finds the address already in use. It sends a DHCPDECLINE message back to the server, and returns to the INIT state.
Client Receives DHCPNAK: The client receives a DHCPNAK message from its chosen server, which means the server has withdrawn its offer. The client returns to the INIT state.
INIT-REBOOT
When a client that already has a valid lease starts up after a power-down or reboot, it starts here instead of the INIT state.
Client Sends DHCPREQUEST: The client sends a DHCPREQUEST message to attempt to verify its lease and re-obtain its configuration parameters. It then transitions to the REBOOTING state to wait for a response.
REBOOTING
A client that has rebooted with an assigned address is waiting for a confirming reply from a server.
Client Receives DHCPACK, Successfully Checks That IP Address Is Free: The client receives a DHCPACK message from the server that has its lease information, confirming that the lease is still valid. To be safe, the client checks anyway to ensure that the address is not already in use by some other device. Assuming it is not, the client records the parameters the server sent it and transitions to the BOUND state.
Client Receives DHCPACK, But IP Address Is In Use: The client receives a DHCPACK message from the server that had its lease, confirming that the lease is still valid. However, the client checks and finds that while the client was offline, some other device has grabbed its leased IP address. The client sends a DHCPDECLINE message back to the server, and returns to the INIT state to obtain a new lease.
Client Receives DHCPNAK: The client receives a DHCPNAK message from a server. This tells it that its current lease is no longer valid; for example, the client may have moved to a new network where it can no longer use the address in its present lease. The client returns to the INIT state.
BOUND
Client has a valid lease and is in its normal operating state.
Renewal Timer (T1) Expires: The client transitions to the RENEWING state.
Client Terminates Lease, Sends DHCPRELEASE: The client decides to terminate the lease (due to user command, for example.) It sends a DHCPRELEASE message and returns to the INIT state.
RENEWING
Client is trying to renew its lease. It regularly sends DHCPREQUEST messages with the server that gave it its current lease specified, and waits for a reply.
Client Receives DHCPACK: The client receives a DHCPACK reply to its DHCPREQUEST. Its lease is renewed, it restarts the T1 and T2 timers, and returns to the BOUND state.
Client Receives DHCPNAK: The server has refused to renew the client's lease. The client goes to the INIT state to get a new lease.
Rebinding Timer (T2) Expires: While attempting to renew its lease, the T2 timer expires, indicating that the renewal period has ended. The client transitions to the REBINDING state.
REBINDING
The client has failed to renew its lease with the server that originally granted it, and now seeks a lease extension with any server that can hear it. It periodically sends DHCPREQUEST messages with no server specified until it gets a reply or the lease ends.
Client Receives DHCPACK: Some server on the network has renewed the client's lease. The client binds to the new server granting the lease, restarts the T1 and T2 timers, and returns to the BOUND state.
Client Receives DHCPNAK: A server on the network is specifically telling the client it needs to restart the leasing process. This may be the case if a new server is willing to grant the client a lease, but only with terms different than the client’s current lease. The client goes to the INIT state.
Lease Expires: The client receives no reply prior to the expiration of the lease. It goes back to the INIT state.


Figure 262: DHCP Client Finite State Machine
This diagram shows the finite state machine used by DHCP clients. The colored background areas show the transitions taken by a DHCP client as it moves through the four primary DHCP processes: allocation, reallocation, renewal and rebinding.


This is just a summary of the finite state machine, and does not show every possible event and transition, since it is complex enough already. For example, if a client that received two offers in the SELECTING state receives a DHCPNAK from its chosen server in the REQUESTING state, it may choose to send a new DHCPREQUEST to its “second choice” instead of starting over from scratch. Also, the client must have logic that lets it “time out” if it receives no reply to sent messages in various states, such as not receiving any offers in the SELECTING state. The next few topics discuss these matters in more detail.
Note also that the DHCP standard does not describe the DHCP server's behavior in the form of a finite state machine, only the client's. Here too, there is more information on what exactly DHCP servers do in the pages that follow.
I should also point out explicitly that this finite state machine applies to dynamically-allocated clients; that is, ones with conventional leases. A device configured using “automatic” allocation will go through the same basic allocation process, but does not need to renew its lease. The process for manual allocation is somewhat different.

Reference from http://www.tcpipguide.com/free/t_DHCPGeneralOperationandClientFiniteStateMachine.htm