NClab

안녕하세요, 오늘은 LVS  부하 분산 방법 중 DR을 설정하는 법에 대해 알아보겠습니다.

1. LVS 설정

1.1. VIP 및 DIP 설정

LVS에서는 크게 DIP (Director IP)와 VIP (Virtual IP)를 설정해야 한다. 여기에서 DIP는 LVS가 고유하게 가질 IP 주소로서, NIC의 기본 IP 주소가 된다. 반면 VIP는 외부 Clients에게 서비스를 제공하기 위해 사용될 인터페이스 IP 주소 (즉, 외부 Clients가 접속할 IP 주소)로서, Aliasing을 통해 설정할 수 있으며, 부하를 상호 분산할 Real Server도 이 VIP를 반드시 가져야 한다.

따라서, 우선 VIP가 123.234.1.101 이고, DIP가 123.234.1.102 이라고 가정할 때,

># ifconfig eth0 123.234.1.102 netmask 255.255.255.0 up
># ifconfig eth0:1 123.234.1.101 netmask 255.255.255.0 up

위와 같이, ifconfig 명령을 이용하여 VIP와 DIP를 각각 설정한 다음, ifconfig로 설정사항을 확인한다. 단, 이미 eth0에 DIP가 설정되어 있는 경우가 대부분이므로, 이 단계에서는 VIP 만을 설정해도 된다.

1.2. Packet Forwarding 활성화

Dispatcher는 Client로부터 전송된 요청 메시지를 Real Server로 전달해야 하므로, 반드시 Packet Forwarding 기능이 활성화되어 있어야 한다. 이는 proc의 ip_forward의 값을 1로 설정함으로써 가능하다.

># echo 1 >/proc/sys/net/ipv4/ip_forward

1.3. Virtual Service 등록 (IPVSADM 설정)

># ipvsadm -A -t 123.234.1.101:80 -s rr

2. Real Server 설정

2.1. ARP Problem 해결 : ARP Hidden

패킷 전달 방식에 있어 NAT를 제외한 TUN 및 DR 방식은 모두 ARP Flux Problem을 해결해야 한다. 기본적으로 Dispatcher Node와 Real Server 모두 VIP를 갖고 있기 때문에, 클라이언트가 VIP의 MAC 주소를 묻는 ARP Request를 전송했을 때 Dispatcher와 Real Server 모두 이에 응답하게 되면 클라이언트는 이들 중 특정 서버의 MAC 주소를 해당 VIP에 해당하는 MAC 주소로 기억(ARP Caching)하고는 이 서버에게만 모든 서비스 요청 메시지를 전송한다. 결국 부하 분산을 더 이상 제공할 수 없으며, 임의의 클라이언트가 어떤 서버로부터 서비스를 제공받는지 관리할 수 없다.

결국 이를 해결하기 위해서는 클라이언트가 ARP 요청 메시지를 전송했을 때 Dispatcher만이 이에 응답하고, Real Server는 모두 ARP 요청 메시지를 무시해야 한다. 여기에서는 가장 간단한 ARP Hidden 방식을 소개한다.

일반적으로 Real Server에 VIP는 lo 장치에 Aliasing으로 설정되기 때문에, lo 장치와 다른 모든 인터페이스에 대해 ARP를 무시하도록 설정한다.

># echo 1 >/proc/sys/net/ipv4/conf/lo/arp_ignore
># echo 2 >/proc/sys/net/ipv4/conf/lo/arp_announce
># echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignore
># echo 2 >/proc/sys/net/ipv4/conf/all/arp_announce

 
2.2. VIP 및 RIP 설정

Real Server는 고유의 IP 주소인 RIP (Real Server IP)를 갖고 있으며, Dispatcher는 RIP 주소를 기반으로 서비스 요청을 분산시킨다. 다만, Direct Routing 방식의 특성상 처리된 클라이언트의 요청은 Real Server에서 클라이언트로 직접 전달되므로(NAT 방식에서 Dispatcher를 거치는 것과는 달리), Real Server는 VIP 주소도 함께 lo 장치로서 갖고 있어야 한다. 따라서, 우선 VIP가 123.234.1.101 이고, RIP가 123.234.1.111 이라고 가정할 때,

># ifconfig eth0 123.234.1.111 netmask 255.255.255.0 up
># ifconfig lo:0 123.234.1.101 netmask 255.255.255.255 up
># ifconfig

위와 같이, ifconfig 명령을 이용하여 VIP와 RIP를 각각 설정한 다음, ifconfig로 설정사항을 확인한다. 단, 이미 eth0에 RIP가 설정되어 있는 경우가 대부분이므로, 이 단계에서는 VIP 만을 설정해도 된다.

2.3. Routing Table 설정

lo:0 장치에 VIP를 설정했으므로, Destination이 VIP인 요청 메시지를 lo:0 장치로 전달해야 한다. 그런 다음에는 이를 Real Server의 커널에 의해 처리된다.

># route add -host 123.234.1.101 dev lo:0

 

3. Real Server를 Virtual Service에 등록 (on Dispatcher Node)

3.1. Real Server를 등록하기

일반적인 Real Server를 Virtual Service에 등록하는 방식도 위와 동일하다. 다만 local host 대신 RIP를 입력하는 것만 차이가 있다.

># ipvsadm -a -t 123.234.1.101:80 -r 123.234.1.111 -g

 

4. Virtual Service 상태 모니터링

이상과 같이 Virtual Service에 Real Server가 등록된 이후에는 즉시 VIP를 통한 서비스 제공이 가능하다. 이때 Dispatcher Node에서 주기적으로 서비스 상태(# of Active Connection and # of Inactive Connection)를 계속해서 모니터링하고 싶은 경우 watch 명령을 이용한다.

># watch n -1 ipvsadm -Ln

안녕하세요, 오늘은 개발자에게 없어선 안될 프로그램!ㅋㅋ

시너지의 설정에 대해 알아보겠습니다.

시너지는 소프트웨어적으로 여러대의  PC의 키보드/마우스를 공유시켜주는 프로그램이 되겠습니다.

일단,

윈도우용 시너지 파일을 받아 설치합니다.

최신 사이트 기준으로 http://synergy-foss.org/pm/projects/synergy/tabs/download

접속하여 각자의 PC의 OS에 맞추어 설치합니다.(우리는 윈도우기준으로 파일을 받아 설치하구요-)


이제 모니터의 위치에 따라 윈도우 피씨를 오른쪽으로 쓸것인지~ 리눅스를 왼쪽으로 쓸것인지~ 방향을 정해주게 됩니다. 이정돈 알아서 하시고~ PASS

그다음 초기페이지로 돌아오시구요, start 버튼을 누르셔서 클라이언트의 접속을 기다리게 합니다


다음은 Client(리눅스) 쪽 설정입니다.

리눅스에서는 synergy를 패키지로 제공하기에,

> yum install synergy

 로 간단하게 설치할 수 있습니다.

그 다음 synergyc 본인IP 를 입력하시면

바로 서버로 접속할 수 있습니다.

이로써 시너지의 기본설정을 모두 마쳤습니다.




PS1. 키보드와 마우스를 제공하는 PC가 Windows 방화벽을 사용 중이라면 아래와 같이 접속하려는 PC에서 에러가 발생할 수 있습니다.


이렇게 "connect to server : address not found for: ****" 에러가 발생한다면 키보드와 마우스를 제공하는 PC의 Windows 방화벽에서 "파일 및 프린터 공유"를 체크하시고 적용하십시오.

안녕하세요, 오늘은 프로젝트 관련하여 LVS 구축에 대한 이론적인 부분을 기술하도록 하겠습니다.


1. LVS 구축  

가상서버를 구성하는 방안에는 그 방식에 따라 크게 3가지 다른 방법으로 구성할 수가 있습니다. NAT 를 이용하는 방법, IP터널링을 이용하는 방법, 다이렉트 라우팅을 이용하는 방법으로 각각의 장단점을 간단히 알아보도록 하겠습니다.

1). NAT 를 이용하는 방법

NAT(Network Address Translation) 방식은 패킷 내의 IP 주소를 변경해 부하 분산을 수행하는 방법입니다. 먼저 클라이언트에게는 로드 밸런서(Load Balancer)의 도메인 네임 또는 IP가 알려져 있습니다. 클라이언트가 이 알려진 도메인 네임이나 IP를 사용해 로드 밸런서에게 서비스 요청 패킷을 전송합니다. 또한 로드 밸런서는 n개의 서버 가운데 하나를 정해진 스케줄링 방법에 의해 선택한 후 패킷 내의 목적지 주소를 해당 서버의 IP로 다시 작성합니다. 리얼 서버는 클라이언트의 요청을 처리한 후, 로드 밸런서에게 응답을 돌려줍니다. 이때 로드 밸런서는 실제 응답의 발신지 주소를 다시 자신의 IP로 변경한 후 클라이언트에 서비스를 제공합니다.   

NAT에 의한 가상 서버의 장점은 실제 서버가 TCP/IP를 지원하는 어떠한 운영체제에서도 운용될 수 있다는 것입니다. 실제 서버는 사적 인터넷 주소체제(private Internet addresses)를 사용할 수 있고 단지 부하 분산기(load balancer)만 하나의 IP 주소가 필요합니다.  

단점은 확장성에 제한이 있다는 것입니다. 서버의 노드수가 수십개로 증가될 경우 병목이 발생할수 있습니다. 왜냐하면 패킷이 들어오고 나갈때마다 부하분산서버에서 패킷을 변경해야하기 때문입니다. 즉 항상 부하분산서버(Director)를 통과합니다. 로드 밸런서는 리얼 서버로 오가는 모든 패킷의 주소를 재작성해야 하므로 병목현상이 발생할 수 있습니다. 따라서 클러스터를 구성할 수 있는 서버의 개수에 제한을 받습니다. 이외에도 로드 밸런서가 다운될 경우 전체 서비스가 중단되는 문제가 발생합니다. 이를 방지하기 위해 일반적으로 ‘백업 로드 밸런서’를 두지만, 평상시는 이 고가의 서버를 사용하지 않으므로 낭비 요소가 됩니다. 방식은 하드웨어나 어플라이언스 형태로 제공되는 경우가 많으며, 대표적인 NAT 방식으로는 레이어4 스위치(OSI 7 계층 모델 가운데 4번 계층인 전송 계층에서 이뤄지는 스위칭 기법을 지원하는 네트워크 장비), 시스코의 로컬 디렉터, LVS(Linux Virtual Server)-NAT 방식 등이 있습니다.

 

 
<Figure 1. NAT 방식>

 

2). IP터널링을 이용하는 방법

IP터널링 방식에서는 NAT방식과는 다르게 부하분산서버는 들어오는 요청에 대해서 뒷단의 서버들(Real Server)에게 패킷을 전달하는 역할만 수행을 합니다. 뒷단의 서버들은 받은 요청에 대해서 다시 부하분산서버로 패킷을 주는 NAT방식과는 다르게 직접 그 요청의 처리를 수행하기 때문에 병목현상이 없어지게 됩니다. 이러한 IP터널링 방식을 설정하기 위해서는 Director 뿐만 아니라 Real Server에서 역시 IP터널링을 지원하도록 설정을 해주어야 합니다.

 

<Figure 2. IP Tunneling 방식>

3). 다이렉트 라우팅을 이용하는 방법

 

다이렉트 라우팅은 리얼 서버와 로드 밸런서가 가상 IP 주소를 공유합니다. 로드 밸런서와 리얼 서버는 네트워크 인터페이스에 가상 IP가 설정돼 있어야 하며, 이 인터페이스를 이용해 로드 밸런서는 요청 패킷을 받아들이고 스케줄링에 의해 선택된 리얼 서버로 직접 라우팅 합니다.

먼저 클라이언트가 가상 IP로 서비스 요청을 하면 로드 밸런서는 리얼 서버 가운데 하나를 스케줄링합니다. 그리고 선택된 서버로 직접 라우팅해 클라이언트의 요청을 리얼 서버로 전달합니다. 리얼 서버는 요청 사항을 처리한 후, 로드 밸런서를 거치지 않고 클라이언트로 직접 응답을 합니다. 각 리얼 서버는 로드 밸런서와 같은 가상 IP를 공유하고 있기 때문에, 로드 밸런서를 거치지 않고 클라이언트로 직접 응답할 수 있습니다.

이 방식은 로드 밸런서에서 병목현상이 NAT보다 적게 나타납니다. 로드 밸런서의 시스템 환경에 따라 차이가 있겠지만, 이론적으로는 100여 개의 서버를 클러스터로 구성할 수 있다고 합니다. 현재 대부분의 운영체제가 가상 IP 설정을 지원하므로 리얼 서버로 사용함에 있어 운영체제에 큰 제한을 받지 않습니다. 하지만 로드 밸런서뿐만 아니라 리얼 서버도 각각의 리얼 IP를 가지고 있어야 합니다. 그리고 NAT와 마찬가지로 백업 서버를 둬야 하는 부담이 있습니다. 특히 리눅스를 리얼 서버로 사용하는 경우 ARP 문제를 해결하기 위해 커널을 수정해 주어야 하는 경우가 있습니다. 참고로 다이렉트 라우팅 방식을 이용한 제품은 Resonate와 터보 클러스터, LVS-DR 등이 있습니다.

 

 

  <Figure 3. Direct Routing 방식>

2. 가상 서버 스케쥴링 알고리즘 

리눅스 가상서버에서 사용하는 스케쥴링 알고리즘을 설명합니다. 

1) Round-Robin Scheduling (라운드 로빈 스케쥴링)

말그대로 라운드-로빈 방식을 이용해 네트웍 연결을 서로 다른 서버에 연결하는 것을 말합니다. 이 경우 실제서버의 연결 갯수나 반응 시간 등은 고려를 하지 않습니다. 그렇지만 약간의 차이가 있습니다. 라운드 로빈 DNS는 단일한 도메인을 서로 다른 IP로 해석을 하지만, 스케쥴링의 기초는 호스트 기반이며 캐싱때문에 알고리즘을 효율적으로 사용하기 힘듭니다. 그래서 실제 서버사이에 동적인 부하 불균형이 심각해 질수 있습니다. 가상 서버의 스케쥴링 기초는 네트웍 기반이며 라운드 로빈 DNS 에 비해 훨씬 더 훌륭합니다.

2) Weighted Round-Robin Scheduling (가중치기반 라운드 로빈 스케쥴링)

가중치기반 라운드 로빈 스케쥴링은 실제 서버에 서로 다른 처리 용량을 지정할 수 있습니다. 각 서버에 가중치를 부여할 수 있으며, 여기서 지정한 정수값을 통해 처리 용량을 정합니다. 기본 가중치는 1입니다.

가중치가 있는 라운드 로빈 스케쥴링을 사용하면 실제 서버에서 네트웍 접속을 셀 필요가 없고 동적 스케쥴링 알고리즘보다 스케쥴링의 과부하가 적으므로 더 많은 실제 서버를 운영할 수 있습니다. 그러나 요청에 대한 부하가 매우 많을 경우 실제 서버사이에 동적인 부하 불균형 상태가 생길 수 있습니다.

  3) Least-Connection Scheduling (최소 접속 스케쥴링) 

최소 접속 스케쥴링은 가장 접속이 적은 서버로 요청을 직접 연결하는 방식을 말합니다. 각 서버에서 동적으로 실제 접속한 숫자를 세어야하므로 동적인 스케쥴링 알고리즘중의 하나입니다. 비슷한 성능의 서버로 구성된 가상 서버는 아주 큰 요구가 한 서버로만 집중되지 않기 때문에, 접속부하가 매우 큰 경우에도 아주 효과적으로 분산을 합니다.

가장 빠른 서버에서 더 많은 네트웍 접속을 처리할 수 있습니다. 그러므로 다양한 처리 용랑을 지닌 서버로 구성했을 경우에도 훌륭하게 작동 한다는 것을 한눈에 알 수 있을 것입니다. 그렇지만 실제로는 TCP의 TIME_WAIT 상태 때문에 아주 좋은 성능을 낼 수는 없습니다.

4) Weighted Least-Connection Scheduling (가중치 기반 최소 접속 스케쥴링)

가중치 기반 최소 접속 스케쥴링은 최소 접속 스케쥴링의 한 부분으로서 각각의 실제 서버에 성능 가중치를 부여할 수 있습니다. 언제라도 가중치가 높은 서버에서 더 많은 요청을 받을 수 있습니다. 가상 서버의 관리자는 각각의 실제 서버에 가중치를 부여할 수 있습니다. 가중치의 비율인 실제 접속자수에 따라 네트웍 접속이 할당됩니다. 기본 가중치는 1입니다.

가중치가 있는 최소 접속 스케줄링 알고리즘은 최소 접속 스케쥴링 알고리즘에 비해 부가적인 배분작업이 필요합니다. 서버들이 같은 처리 용량을 가졌을때는 작업 할당의 간접비용을 최소화 하기위해 최소 접속 스케쥴링과 가중치가 있는 최소 접속 스케쥴링 알고리즘 둘 다 사용할 수 있습니다.

 


참고 : http://hakkoo.net/zeroboard/zboard.php?id=study&page=6&sn1=&divpage=1&category=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=desc&no=419&PHPSESSID=34ad0df0e6670171141d75494595ea57