[리눅스]LVS(Linux Virtual Server)에 대하여

0066. LVS에 대하여

Linux Virtual Server 자습서

Horms (Simon Horman) – horms@valinux.co.jp

VA Linux Systems Japan 주식 회사 – www.valinux.co.jp

2003 년 7 월 (2004 년 3 월 개정)

http://www.ultramonkey.org/

요약

Linux Virtual Server (LVS) 프로젝트는 레이어 4 스위칭을 이용하여 Web 서버나 메일 서버와 같은 네트워크 서비스의 부하 분산을 가능하게합니다. 이것은 매우 빠른 속도로 이러한 서비스는 수만에서 수십만의 동시 접속에까지 확장해 서비스를 제공할 수 있습니다. 이 연습의 목적은 LVS의 다양한 기능을 이용하여 인터넷 서비스 부하 분산을하는 방법과 heartbeat 및 keepalived 같은 도구를 사용하여 고가용성을 실현하는 방법을 보여줍니다. 또한 고가 용성 환경에서 활성 연결을 유지하거나 활성 피드백을 활용하여 부하를보다 효과적으로 분산시킬 등 최근 개발 테마가있는 고급 항목도 다룹니다.

시작하기

Linux Virtual Server (LVS) 프로젝트는 Linux 커널 레이어 4 스위칭을 구현합니다. 이것은 TCP와 UDP 세션 부하를 여러 실제 서버에 분산 수 있습니다. 즉, 인터넷 서비스를 하나 이상의 호스트로 확장할 수 있도록합니다. 이것은 전자 메일에서 X Window System까지 대부분의 서비스에서 사용할 수 있지만, World Wide Web에 HTTP 및 HTTPS 트래픽을 이용하는 것이 가장 일반적이라고 생각됩니다.

LVS 자체는 Linux에서 작동하지만, 모두가 사용하는 OS에 관계없이 최종 사용자가 실제 서버에 대한 연결을 균형있게 조정할 수 있습니다. 연결이 TCP 또는 UDP 중 하나를 사용하기만하면 LVS를 사용할 수 있습니다.

LVS는 매우 고성능, 최대 10 만 개의 동시 연결을 처리할 수 있습니다. 포화 100M 비트 ethernet 링크를 저렴한 상용 하드웨어를 사용하여 쉽게 부하 분산시킬 수 있습니다. 또한보다 고성능 상용 하드웨어를 사용하면 포화 1G 비트 이상의 링크를 부하 분산시킬 수 있습니다.

LVS의 기본

이 섹션에서는 LVS의 구조, LVS를 구해서 설치하는 방법, 주요 동작 모드의 설정 방법 등 기본적인 정보를 제공합니다. 이 정보에서 TCP와 UDP 서비스의 부하를 분산하도록 LVS를 설정할 수 있습니다.

용어

Linux Director : Linux와 LVS가 설치된 호스트. 최종 사용자의 패킷을 받아 실제 서버로 전송한다.

최종 사용자 : 연결의 기점이되는 호스트.

실제 서버 : 연결 종점이되는 호스트. Apache 등 어떤 데몬을 실행하고있다.

단일 호스트가 위의 중 여러 역할을 동시에 할 수있다.

가상 IP 주소 (VIP) : Linux Director가 취급하는 서비스에 할당된 IP 주소입니다.

실제 IP 주소 (RIP) : 실제 서버의 IP 주소입니다.

레이어 4 스위칭

그림 1 : LVS NAT

레이어 4 스위치는 들어오는 TCP / IP 연결 및 UDP / IP 데이터 그램을 실제 서버에 다중화하는 방식으로 작동합니다. 패킷은 Linux Director를 대신해서 어떤 실제 서버로 전송 여부를 결정합니다. 이것이 결정되면 동일한 연결의 나머지 패킷이 동일한 실제 서버에 보내집니다. 이렇게 연결의 무결성이 유지됩니다.

패킷 전송

Linux Virtual Server는 NAT (Network Address Translation), IP-IP 캡슐화 (터널링), 직접 라우팅 세 가지 방식으로 패킷을 전송할 수 있습니다.

NAT (Network Address Translation) : 원본 / 대상 포트, 패킷의 주소를 조작하는 방법입니다. 이것이 가장 일반적으로 사용되는 것이 IP 마스 커 레이드입니다. IP 마스 커 레이드는 RFC 1918 [2] 사설 네트워크에서 인터넷에 액세스할 수 있도록하는 데 자주 사용되는 방법입니다. 레이어 4 스위칭에서는 최종 사용자가 패킷을 받으면 대상 포트와 IP 주소가 선택된 실제 서버 것에 다시 작성됩니다. 회신 패킷 Linux Director를 지날 때 매핑이 해제되므로 최종 사용자는 예상대로 소스로부터 응답을받을 수 있습니다.
직접 라우팅 : 최종 사용자의 패킷을 직접 실제 서버로 전송하는 방법입니다. IP 패킷은 변경되지 않기 때문에 실제 서버가 가상 서버의 IP 주소에 대한 트래픽을 허용하도록 설정해야합니다. 이를 위해서는 더미 인터페이스를 사용하거나 가상 서버의 IP 주소로 트래픽을 로컬 포트​​로 리디렉션 패킷 필터링합니다. 실제 서버는 사용자에게 직접 응답을 보낼 수 있습니다. 즉, Linux Director를 리턴 경로에 상주할 수 없습니다.
IP-IP 캡슐화 (터널링) : 해당 IP 주소로 패킷을 동일한 네트워 크나 다른 네트워크에있는 다른 주소로 리디렉션할 수 있도록합니다. 레이어 4 스위치에서는이 동작을 직접 라우팅과 유사하지만 패킷을 전송할 때 그냥 ethernet 프레임을 조작하는 것이 아니라, IP 패킷에 캡슐 화하는 점이 다릅니다. 터널링의 주요 장점은 실제 서버가 다른 네트워크에있어도 상관 없다는 것입니다.
그림 2 : LVS 직접 라우팅

가상 서비스

Linux Director는 가상 서비스는 IP 주소와 포트 및 프로토콜 또는 방화벽 마크 정의됩니다. 가상 서비스에는 옵션 지속성 시간을 연결할 수 있습니다. 이것이 설정되고 제한 시간이 경과하기 전에 동일한 IP 주소에서 연결을 수신하면 연결이 원래 연결과 동일한 실제 서버로 전송됩니다.

IP 주소와 포트 및 프로토콜 : 가상 서버는 다음과 같이 지정합니다.
IP 주소 : 최종 사용자가 서비스에 액세스하는 데 사용하는 IP 주소
포트 : 최종 사용자의 연결 포트
프로토콜 : UDP 또는 TCP
방화벽 마크 : 패킷은 ipchains 또는 iptables를 사용하여 32 비트 부호없는 값으로 표시됩니다. Linux Virtual Server는이 마크를 이용하여 가상 서비스로 발송 전달된 패킷을 나열하고 적절하게 라우팅합니다. 이것은 동일한 실제 서버에서 운영하는 IP 기반 가상 서비스가 대량으로 필요하거나 다른 포트 사이에 지속성을 그룹화할 때 유용합니다. 예를 들어 특정 최종 사용자가 HTTP 및 HTTPS에서 동일한 실제 서버에 전송되도록하고 싶은 경우 등입니다.
예약

가상 서비스는 들어오는 연결을 실제 서버에 할당하는 데 사용되는 스케줄링 알고리즘이 할당됩니다. LVS는 스케줄러가 다른 커널 모듈로 구현되어 있습니다. 따라서 LVS 코드를 변경하지 않고도 새로운 스케줄러를 구현할 수 있습니다.

스케줄링 알고리즘은 용도에 따라 여러 가지가 있습니다. 가장 간단한 것은 라운드 로빈과 최소 연결입니다. 라운드 로빈은 각 실제 서버에 순차적으로 연결을 할당합니다. 최소 연결은 가장 연결이 적은 실제 서버에 연결을 할당합니다. 모두 간단한 구조로 작동합니다. 이 스케줄러는 부하에 따라 할당하는 변종도 이러한에서는 실제 서버 부하에 비례하여 연결을 할당합니다. 보다 스펙이 높은 실제 서버에 부하를 많이 설정 해두면 더 많은 연결을 할당하는 구조입니다.

특별한 용도에 대응한 더욱 복잡한 스케줄링 알고리즘도 있습니다. 예를 들어, 같은 IP 주소 요청이 동일한 실제 서버에 전송되도록하는 것은 투명한 프록시로드 균형 조정 LVS를 사용할 때 유용합니다.

LVS 설치

SuSE 등 일부 배포판은 LVS가 컴파일된 커널을 제공합니다. 이 경우 필요한 작업이 제공되고있다 ipvsadm 패키지를 설치하는 것입니다. 본고의 집필 시점에서는 Ultra Monkey은 Debian Sid (불안정 버전), Woody (안정 / 3.0), 그리고 Red Hat 7.3 및 8.0용으로 빌드된 패키지를 준비하고 있습니다. 이러한 패키지를 구해서 설치에 대한 자세한 정보는 www.ultramonkey.org를 참조하십시오. 나중에 소스에서 LVS를 설치하는 방법을 설명합니다. 이것은 LVS의 구조를 이해하는데도 도움이됩니다.

이전 버전의 LVS는 Linux 2.2 시리즈 커널에서 실행했습니다. 이 구현은 커널 소스에 많은 패치를해야했습니다. 따라서 각 버전의 LVS는 커널 버전에 밀접하게 관련이있는 것입니다. 2.4 커널의 일부인 netfilter 패킷 필터링 아키텍처 [4], LVS를 일련의 커널 모듈로 거의 단독으로 구현하는 것이 가능합니다. 이 결과, LVS가 개별 커널 릴리즈에 고정되어 버리는 일이 없습니다. LVS는 커널에 직접 컴파 일할 수 있지만, 여기에서는보다 쉽고 유연한, LVS를 모듈로 사용하는 방법을 다룹니다.

커널 받기 및 압축 풀기
모든 경우에 가장 쉬운 방법은 신선한 커널을 사용하는 것입니다. 이것은 www.kernel.org에서 구할 수 있습니다. 이 예제에서 사용하는 것은 2.4.20 커널입니다.다음 명령을 실행하여 커널을 linux-2.4.20 디렉토리에 압축을 풉니다.

tar-jxvf linux-2.4.20.tar.bz2
LVS 받기 및 압축 풀기
LVS는 www.linuxvirtualserver.org에서 구할 수 있습니다. 이 예제에서는 1.0.9을 사용합니다. 다음 명령을 실행하여 ipvs-1.0.9 디렉토리에 압축을 풉니다.

tar-zxvf ipvs-1.0.9.tar.gz
LVS 패치를 커널에 적용
LVS 모듈을 컴파일하려면, 2 개의 작은 커널 패치가 필요합니다. 이 패치를 적용하려면 다음 명령을 사용합니다.

cd linux-2.4.20 /
patch-pq <.. / ipvs-1.0.9/linuxkernel_ksyms_c.diff
patch-pq <.. / ipvs-1.0.9/linuxnet_netsyms_c.diff
인터페이스를 숨길 수 있도록 3 번째 패치를 적용합니다. 숨어 인터페이스는 ARP 요청에 응답하지 않고, LVS 직접 라우팅과 함께 실제 서버에서 사용됩니다.

patch-pq <.. / ipvs-1.0.9/contrib/patches/hidden-2.4.20pre10-1.diff
커널 구성
먼저 트리가 깨끗하다 확인합니다.

make mrproper
그러면 커널을 구성하고 있습니다. make menuconfig, make xconfig, make config 등 다양한 방법이 있지만 어느 방법이든 최소한 다음 옵션을 포함하여 netfilter 지원하도록 컴파일하도록주의하십시오. 이 옵션은 가능한 모듈로 빌드하는 것이 좋습니다.

Networking options —>
Network packet filtering (replaces ipchains)
<m> IP : tunnelling
IP : Netfilter Configuration —>
<m> Connection tracking (required for masq / NAT)
<m> FTP protocol support
<m> IP tables support (required for filtering / masq / NAT)
<m> Packet filtering
<m> REJECT target support
<m> Full NAT
<m> MASQUERADE target support
<m> REDIRECT target support
<m> NAT of local connections (READ HELP) (NEW)
<m> Packet mangling
<m> MARK target support
<m> LOG target support
커널 빌드와 설치
커널을 다시 구성했으면 빌드 종속성을 다시 구축해야합니다.

make dep
이것이 끝나면 다음 명령을 사용하여 커널과 모듈을 빌드합니다.

make bzImage modules
빌드된 모듈과 커널을 설치하려면 다음 명령을 실행합니다. 이렇게하면 / lib/modules/2.4.20 / 모듈이 설치된 / boot/vmlinuz-2.4.20 커널이 설치됩니다.

make install modules_install
부트 로더 업데이​​트
부트 로더 grub을 사용하는 경우 / etc / grub.conf에 새 항목을 추가할 필요가 있습니다.여기서는 / boot 파티션을 / dev/hda3는 것을 전제로 설명합니다. / etc / grub.conf의 기존 항목을 참고하십시오.

title 2.4.20 LVS
root (hd0, 0)
kernel / vmlinuz-2.4.20 ro root = / dev/hda3
부트 로더가 lilo의 경우 / etc / lilo.conf에 새 항목을 추가합니다. 여기서는 루트 파티션이 / dev/hda2 것을 전제로 설명합니다. / etc / lilo.conf에있는 기존 항목을 참고하십시오.

image = / boot/vmlinuz-2.4.20

label = 2.4.20-lvs
read-only
root = / dev/hda2
/ etc / lilo.conf가 업데이트되면 lilo를 실행합니다.

lilo
Added Linux-LVS *
Added Linux
Added LinuxOLD
시스템을 다시 시작합니다.
부트 로더 프롬프트에서 새로 만든 커널이 부팅되는지 확인합니다.

LVS 빌드 및 설치
LVS를 구축하기위한 명령은 ipvs-1.0.9/ipvs / 디렉토리에서 실행합니다. 빌드 및 설치에 사용하는 명령은 다음과 같습니다. 커널을 빌드한 / kernel/source/linux-2.4.20를 루트 디렉토리로 사용하십시오.

make KERNELSOURCE = / kernel/source/linux-2.4.20 all
make KERNELSOURCE = / kernel/source/linux-2.4.20 modules_install
Ipvsadm 빌드 및 설치
Ipvsadm는 LVS 설정하는 데 사용하는 사용자 공간 도구입니다. 소스 ipvs-1.0.9/ipvs/ipvsadm / 디렉토리에 있습니다. 빌드 및 설치하려면 다음 명령을 사용합니다.

make all
make install
LVS NAT

LVS NAT는 LVS 설정 아마 가장 간단한 방법입니다. 실제 서버에서 패킷을 Linux Director가 수신 대상 IP 주소가 실제 서버의 것으로 다시 작성됩니다. 실제 서버의 응답 패킷의 원본 IP 주소는 실제 서버 것에서 VIP의 것으로 바뀝니다.

그림 3 : LVS NAT의 예

Linux Director

IP 전달 기능을 활성화합니다. 이것은 다음 줄을 / etc / sysctl.conf에 추가하여 sysctl-p를 실행하여합니다.
net.ipv4.ip_forward = 1
eth0 : 0 172.17.60.201를 설정합니다. 이것은 시스템의 네트워크 설정의 일부로하는 것이 가장 좋지만, 수동 수도 있습니다.
ifconfig eth0 : 0 172.17.60.201 netmask 255.255.0.0 broadcast 172.17.255.255
LVS 설정
ipvsadm-A-t 172.17.60.201:80
ipvsadm-a-t 172.17.60.201:80-r 192.168.6.4:80-m
ipvsadm-a-t 172.17.60.201:80-r 192.168.6.5:80-m
실제 서버

회신 패킷 Linux Director를 통해 라우팅되어 있는지 확인하십시오. 일반적으로 서버 네트워크의 VIP를 기본 게이트웨이 설정하여 수행합니다.
원하는대로 데몬이 포트 80을 수신하고 최종 사용자의 연결을 처리할 수 있는지 확인하십시오.
테스트 및 디버깅

테스트 서버 네트워크 외부에서 172.17.60.201:80에 연결합니다.

Linux Director와 실제 서버에서 패킷 추적 도구를 실행하면 디버깅에 매우 유용합니다.연결 경로를 추적하고 모든 단계에서 패킷이 사라지고 있는지 판단하면 설정에 대한 많은 문제를 해결할 수 있습니다. 여기에서는 예로 Tcpdump를 사용하는 방법을 소개하지만, 다양한 OS를위한 여러 가지 도구가 존재합니다.

다음 추적은 최종 사용자 10.2.3.4가 VIP 172.17.60.201 연결을 시작하고이 연결을 실제 서버 192.168.6.5로 전송됩니다. Linux Director가 패킷을 받아 실제 서버로 전송하고 그 반대를하고있는 것을 알 수 있습니다. 실제 서버에 전송된 패킷이 원본 주소로 최종 사용자의 IP 주소를 가지고있는 것에 주목하십시오. Linux Director 변경하는 것은 패킷의 대상 IP 주소입니다. 마찬가지로 실제 서버의 응답에 대상으로 최종 사용자의 주소가 지정되어 있습니다. Linux Director 회신 패킷의 원본 IP 주소만을 VIP되도록 다시 작성합니다.

tcpdump-n-i any port 80
12:40:40.965499 10.2.3.4.34802> 172.17.60.201.80 :
S 2555236140:2555236140 (0) win 5840
<mss 1460,sackOK,timestamp 16690997 0,nop,wscale 0>
12:40:40.967645 10.2.3.4.34802> 192.168.6.5.80 :
S 2555236140:2555236140 (0) win 5840
<mss 1460,sackOK,timestamp 16690997 0,nop,wscale 0>
12:40:40.966976 192.168.6.5.80> 10.2.3.4.34802 :
S 2733565972:2733565972 (0) ack 2555236141 win 5792
<mss 1460,sackOK,timestamp 128711091 16690997,nop,wscale 0> (DF)
12:40:40.968653 172.17.60.201.80> 10.2.3.4.34802 :
S 2733565972:2733565972 (0) ack 2555236141 win 5792
<mss 1460,sackOK,timestamp 128711091 16690997,nop,wscale 0> (DF)
12:40:40.971241 10.2.3.4.34802> 172.17.60.201.80 :
. ack 1 win 5840 <nop,nop,timestamp 16690998 128711091>
12:40:40.971387 10.2.3.4.34802> 192.168.6.5.80 :
. ack 1 win 5840 <nop,nop,timestamp 16690998 128711091>
ctrl-c
활성 연결 수를 표시하려면 ipvsadm-L-n을 사용합니다.

ipvsadm-L-n
IP Virtual Server version 1.0.9 (size = 4096)
Prot LocalAddress : Port Scheduler Flags
-> RemoteAddress : Port Forward Weight ActiveConn InActConn
TCP 172.17.60.201:80 rr
-> 192.168.6.5:80 Masq 1 7 3
-> 192.168.6.4:80 Masq 1 8 4
ipvsadm-L-stats는 초당 전송 및 수신되는 패킷의 수와 바이트 수를 표시합니다.

ipvsadm-L-n – stats
IP Virtual Server version 1.0.9 (size = 4096)
Prot LocalAddress : Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress : Port
TCP 172.17.60.201:80 114 1716 1153 193740 112940
-> 192.168.6.5:80 57 821 567 9464 2 55842
-> 192.168.6.4:80 57 895 586 9909 8 57098
ipvsadm-L-rate는 송수신되는 패킷의 수를 표시합니다.

ipvsadm-L-n – rate
IP Virtual Server version 1.0.9 (size = 4096)
Prot LocalAddress : Port CPS InPPS OutPPS InBPS OutBPS
-> RemoteAddress : Port
TCP 172.17.60.201:80 56 275 275 1873 9 41283
-> 192.168.6.5:80 28 137 137 9344 20634
-> 192.168.6.4:80 28 138 137 9395 20649
ipvsadm-L-zero는 모든 통계 값을 제로로합니다.

LVS 직접 라우팅

그림 4 : LVS 직접 라우팅 예제

LVS 직접 라우팅은 패킷을 변경하지 않고 실제 서버의 MAC 주소로 전달하는 방식으로 작동합니다. 패킷이 변경되지 않기 때문에, VIP 향하는 트래픽을 받아 실제 서버를 설정해야합니다. 이것은 숨겨진 인터페이스를 사용하여 구현되는 것이 일반적입니다.

Linux Director는 들어오는 패킷을 변경하지 않기 때문에, 응답 패킷이 Linux Director를 거칠 필요가 없습니다. 이 덕분에 더 높은 처리량을 제공합니다. 또한 회신 패킷 Linux Director를 통하지 않고 직접 최종 사용자에게 보내지기 때문에 동일한 로컬 네트워크의 최종 사용자에게 서비스의 부하를 분산하는 것이 쉽습니다.

Linux Director

IP 전달 기능을 활성화합니다. 이것은 다음 줄을 / etc / sysctl.conf에 추가하여 sysctl-p를 실행합니다.
net.ipv4.ip_forward = 1
eth0 : 0 172.17.60.201를 설정합니다. 이것은 시스템의 네트워크 설정의 일부로하는 것이 가장 좋지만, 수동 수도 있습니다.
ifconfig eth0 : 0 172.17.60.201 netmask 255.255.0.0 broadcast 172.17.255.255
LVS 설정
ipvsadm-A-t 172.17.60.201:80
ipvsadm-a-t 172.17.60.201:80-r 172.17.60.199:80-g
ipvsadm-a-t 172.17.60.201:80-r 172.17.60.200:80-g
실제 서버는 응답 패킷을 직접 사용자에게 보낼 수 있습니다. Linux Director가 패킷을 변경할 필요가 없습니다. 즉, Linux Director가 실제 서버의 게이트웨이되지 않아도됩니다.
그러나 경우에 따라서는 (Linux Director는 정말 실제 서버의 네트워크 게이트웨 이인 경우) 실제 서버에서 응답 패킷을 Linux Director를 통해 라우팅하는 것이 바람직하다 수 있습니다. 이러한 패킷의 소스 주소는 VIP입니다. 그러나이 VIP는 Linux Director 인터페이스에 속해 있기 때문에, Linux Director는 패킷이 위조되고있는 것으로 간주하고이를 무시하고 버립니다.

이 문제를 해결하는 방법은 여러 가지가 있습니다. 가장 좋은 방법은 Julian Anastasov 제공 커널 패치를 적용하는 것입니다. 이 패치는 인터페이스별로 패킷 삭제 동작을 무효로 할 수있다 proc 항목을 추가합니다. 이 패치는 http://www.ssi.bg/ ~ ja / # lvsgw에서 구할 수 있습니다.

실제 서버

위의 패치를 커널에 적용하지 않는 경우 응답 패킷이 Linux Director를 통해 라우팅되지 않았는지 확인합니다.
최종 사용자의 연결을 처리하는 데몬이 포트 80에서 수신을하고 있는지 확인합니다.
루프백 인터페이스에 172.17.60.201를 설정합니다. 이것은 시스템의 네트워크 설정의 일부로하는 것이 가장 좋지만, 수동 수도 있습니다. Linux에서 다음 명령을 사용하여합니다.
ifconfig lo : 0 172.17.60.201 netmask 255.255.255.255
172.17.60.201이 속한 네트워크의 실제 서브넷 마스크 관계없이 네트 마스크는 255.255.255.255이어야합니다. 이것은 루프백 인터페이스는 넷마 스크가 포함하는 모든 주소가 인터페이스에 바인딩되어 있기 때문입니다. 일반적인 경우는 127.0.0.1 네트 마스크 255.0.0.0로 설정된 루프백 인터페이스가 127.0.0.0 / 8 모든 트래픽을 허용하는 것입니다. 따라서 여기에서는 lo : 0 만 172.17.60.201로 향하는 패킷을받을 수 있도록하고 싶기 때문에, 네트 마스크가 255.255.255.255 여야가 있습니다.

루프백을 숨깁니다. Linux 실제 서버에서 루프백 인터페이스를 숨기고, VIP의 ARP 요청에 응답하지 않도록해야합니다. 이것은 "LVS 설치"섹션에서 소개한 숨어 인터페이스 패치를 적용하여 수 있습니다. 패치를 사용하려면 다음 행을 / etc / sysctl.conf에 추가하고 sysctl-p를 실행합니다.
# 숨겨진 장치를 활성화하는
net.ipv4.conf.all.hidden = 1
# 루프백 인터페이스 숨기기
net.ipv4.conf.lo.hidden = 1
테스트 및 디버깅

테스트는 모든 네트워크에서 172.17.60.201:80에 연결하여 수행할 수 있습니다.

디버깅은 LVS NAT와 마찬가지로 ipvadm 및 패킷 추적을 사용하여 수행할 수 있습니다.그러나 패킷이 전송될 때, 주소 변환이되지 않는 것에 주의해주세요. 또한 회신 패킷이 LVS에 의해 처리되지 않는 경우에도주의가 필요합니다. 실제 서버에서 최종 사용자에게 직접 전송됩니다. 따라서 송신 패킷과 바이트는 제로가됩니다.

LVS 터널

그림 5 : LVS 터널 예 : LVS 직접 라우팅 예제와 동일한 토폴로지

LVS 터널링은 직접 라우팅과 거의 같은 구조입니다. 주요 차이점은 단순히 새로운 ethernet 프레임을 보내는 것이 아니라 IP 캡슐화된 IP를 사용하여 패킷이 실제 서버에 전송되는 것입니다. 이 최대의 장점은 실제 서버가 Linux Director는 다른 네트워크에있어도 상관 없다는 것입니다.

Linux Director

IP 전달 기능을 활성화합니다. 이것은 다음 줄을 / etc / sysctl.conf에 추가하여 sysctl-p를 실행합니다.
net.ipv4.ip_forward = 1
eth0 : 0 172.17.60.201를 설정합니다. 이 경우에도 시스템의 네트워크 설정의 일부로하는 것이 가장 좋지만, 수동 수도 있습니다.
ifconfig eth0 : 0 172.17.60.201 netmask 255.255.0.0 broadcast 172.17.255.255
LVS 설정
ipvsadm-A-t 172.17.60.201:80
ipvsadm-a-t 172.17.60.201:80-r 172.17.60.199:80-i
ipvsadm-a-t 172.17.60.201:80-r 172.17.60.200:80-i
Linux Director를 실제 서버의 게이트웨이 라우터로 사용하려면 (그 필요는 없지만), 커널에 패치를 적용하는 방법을 "직접 라우팅"섹션에서 확인하십시오.
실제 서버

"직접 라우팅 '섹션에서 소개 패치를 커널에 적용하지 않는 경우 응답 패킷이 Linux Director를 통해 라우팅되지 않았는지 확인합니다.

원하는 데몬이 포트 80에서 실행되고 최종 사용자의 연결을 받아들일 수 있는지 확인하십시오.
tunl0에 172.17.60.201를 설정합니다. 이 경우에도 시스템의 네트워크 설정의 일부로하는 것이 가장 좋지만, 수동 수도 있습니다.
ifconfig tunl0 172.17.60.201 netmask 255.255.255.255
포워딩을 사용하여 루프백을 숨깁니다. 이것은 / etc / sysctl.conf에 다음 줄을 추가하고 sysctl-p를 실행하여 수행할 수 있습니다.
net.ipv4.ip_forward = 1
# 숨겨진 장치를 활성화하는
net.ipv4.conf.all.hidden = 1
# tunl0 인터페이스 숨기기
net.ipv4.conf.tunl0.hidden = 1
테스트 및 디버깅

테스트는 모든 네트워크에서 172.17.60.201:80에 연결하여 수행할 수 있습니다. 디버깅 LVS 직접 라우팅과 비슷합니다.

고가 용성

LVS는 네트워크 서비스의 부하 분산을 효율적으로하기위한 방법입니다. 일반적으로 여러 서버 (최종 사용자보고) 하나의 서버인 것처럼 작동하는 것을 의미합니다. 불행히도, 시스템의 서버의 수가 증가하면 증가할수록, 그 중 하나에 오류가 일어날 가능성도 높아집니다. 따라서 높은 가용성을 실현하는 기술을 이용하여 1 대의 서버에 장애가 발생해도 가상 서비스가 유지되도록하는 것이 중요합니다.

Heartbeat

Heartbeat는 한 쌍의 Linux Director를 모니터링하는 데 사용되는 모든 시간에 반면에 VIP가 할당된 것을 보장합니다. 이것은 각 호스트가 정기적으로 heartbeat 메시지를 전송하여 작동합니다. 정해진 시간에 heartbeat 메시지가 수신되지 않으면 해당 호스트가 실패로 간주됩니다. 이 경우 리소스를 인계 수 있습니다. Heartbeat는 모듈식 설계가되어 있으며, 모든 리소스를 정의할 수 있습니다.

설명의 형편상 여기서는 IP 주소 리소스합니다. 페일오버가 발생하면 IP 주소 인계라는 방법으로 IP 주소를 검색합니다. 이것은 새로 활성화된 Linux Director가 gratuitous ARP 패킷을 VIP로 전송하여 수행됩니다. 네트워크의 모든 호스트는이 ARP 패킷을 받고 다음 패킷을 새 Linux Director의 VIP로 발송 보냅니다.

Heartbeat는 www.linux-ha.org에서 구할 수 있습니다. 제공되는 패키지를 사용하여 설치하거나 다음 명령을 사용하여 소스에서 빌드합니다.

. / ConfigureMe build
make
make install
예제 구성

그림 6 : Heartbeat 예제

/ etc / ha.d에있는 3 개의 파일을 사용하여 설정합니다.

ha.cf : 통신에 사용 인터페이스, 메시지 전송 빈도 로깅 위치 등 heartbeat의 기본 매개 변수를 설정합니다.

오라클의 공유 메모리는 커널 작업을 수반하지 않으며 프로세스 간의 데이터 복제 작업이 불필요 하기 때문에 , IPC(inter-Process Communication)를 위한 가장 빠른 방법을 선호 되고 있습니다.
오라클은 인스턴스 구조를 보면 SGA(System Global Area)와 백 그라운드 프로세스로 구성 되어 있습니다. 여기에서 SGA는 Shared Pool, Database Buffer Cache, Redo Log Buffer 등의 저장에 활용되므로 SGA 크기에 따라 오라클 성능이 크게 달라집니다.

그럼 오라클을 설치하기 전에 Linux에서 사용하는 커널 매개변수와 Shell Limit에 대해서 알아 보도록 하겠습니다.

1. Linux 커널 매개변수의 설정

다른 UNIX 시스템과 달리, Linux 운영체제에서는 시스템이 실행 중인 상태에서 대부분의 커널 매개변수를 수정할 수 있습니다. 커널 매개변수를 변경한 뒤에 시스템을 리부팅할 필요도 없습니다. Oracle Database 10g가 요구하는 커널 매개변수 설정할 수 있으나 시스템에 이미 커널 메게변수가 높은 수치로 설정 되어있을 경우에는 변경 하지 마시기 바랍니다.

[ 매개변수 - kernel.shmmax ] SHMMAX 매개변수는 공유 메모리 세그먼트의 최대 크기(바이트 단위)를 정의하는데 사용됩니다. 오라클 SGA 메모리로 구성되며, SHMMAX가 올바르게 설정되지 않을 경우 SGA의 크기가 제약될 수도 있습니다. 따라서 SGA의 크기보다 작지 않도록 SHMMAX를 설정합니다.
총 10GB의 메모리에서 오라클이 사용할 수 있는 최대 한도를 정의 하는 것을 의미 합니다.
먄약 SHMMAX 매개변수가 잘못 설정될 경우에는 아래와 같은 오라클 에러 메시지가 발생 됩니다.

ORA-27123: unable to attach to shared memory segment

기본적으로 SHMMAX 기본 값은 32MB 입니다. SGA로 사용하기에는 너무 적은 공간이기 때문에 적당한 크기로 변경 해야 합니다.
[2010-12-09 03:26:18]-[root@calmmass:/proc/sys/kernel]
# cat /proc/sys/kernel/shmmax |sed -e :a -e 's/\(.*[0-9]\)\([0-9]\{3\}\)/\1.\2/;ta'
33.554.432

[ 매개변수 - kernel.shmall ] SHMALL 커널 매개변수는 특정 시점에 시스템에서 사용 가능한 공유 메모리의 최대 크기(페이지 단위)를 설정하는데 사용됩니다. 따라서 이 매개변수는 최소한 아래 값보다 커야 합니다.
ceil(SHMAX/PAGE_SIZE)
우선 페이지 사이즈를 확인 해보겠습니다. Red Hat Linux의 페이지 사이즈는 기본적으로 4,096 바이트 입니다.
[2010-12-09 02:51:29]-[root@calmmass:~]
# getconf PAGESIZE |sed -e :a -e 's/\(.*[0-9]\)\([0-9]\{3\}\)/\1.\2/;ta'
4.096

SHMALL의 디폴트 사이즈는 아래와 같습니다. sed를 이용해서 3자리로 구분한 결과 2MB를 사용합니다.
# cat /proc/sys/kernel/shmall |sed -e :a -e 's/\(.*[0-9]\)\([0-9]\{3\}\)/\1.\2/;ta'
2.097.152

[ 매개변수 - kernel.shmmni ] SHMMNI는 공유 메모리 식별자의 개수를 의미 하며 권장 값은 100 이상 으로 설정하셔야 합니다. 아래와 같이 확인 하시기 바랍니다.
[2010-12-09 03:26:07]-[root@calmmass:/proc/sys/kernel]
# cat shmmni
4096

[ 매개변수 - kernel.sem ] 세마포어(Semaphore)란 공유 리소스의 사용 과정에서 프로세스(프로세스 내 쓰레드) 간의 동기화를 위해 사용되는 일종의 카운터(counter) 입니다. 애플리케이션의 세마포어를 이용하면, 운영 체제는 SET를 통해 세마포어를 지원하게 됩니다.
그럼 세마포어 설정 값을 먼저 확인 해보겠습니다.
[2010-12-09 03:39:32]-[root@calmmass:/proc/sys/kernel]
# ipcs -lm
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1

SEM 매개변수는 세마포어 최대값을 조정 가능하며 의미는 아래와 같습니다.
의미 : {배열당 최대 SEM 수}{최대SEM시스템넓이}{SEMOP호출당최대OP수}{최대배열수}
[2010-12-09 03:37:24]-[root@calmmass:/proc/sys/kernel]
# cat /proc/sys/kernel/sem |sed -e :a -e 's/\(.*[0-9]\)\([0-9]\{3\}\)/\1.\2/;ta'
250 32.000 32 128
1 2 3 4 (필드 라고 정의 하겠습니다.)
1 필드 값(250) : SEMMSL 매개변수는 세미포어 set 당 세마포어의 최대 개수를 정의합니다. 오라클을 예로 init[SID].ora 파일(pfile, spfile 동일)의 PROCESS 인스턴스 매개변수의 (전체 데이터베이스 중) 최대값에 10을 더한 값을 사용할 것을 권장하고 있습니다. 그래서 100이상의 값을 정의하는 것을 권장 합니다.

2 필드 값(32.000) : SEMMNI 매개변수는 전체 Linux 시스템의 세마포어 set의 개수를 정의 합니다. 오라클에서는 100이상의 값을 정의하는 것을 권장합니다.

3 필드 값(32) : SEMMNS 매개변수는 전체 Linux 시스템의 ("세마포어 set"이 아닌) 세마포어의 최대 개수를 정의 합니다. 오라클은 인스턴스 매개변수의 값을 모두 더한 뒤, 가장 큰 Processes값을 두 차례 더하고, 마지막으로 각 데이터베이스 별로 10을 더한 값을 SEMMNS를 설정하도록 권장 합니다.

4. 필드 값(128) : SEMOPM 매개변수는 semop 시스템 호출(system call) 별로 수행될 수 있는 세마포어 작업의 수를 설정하는데 사용됩니다.SEMOPM을 SEMMSL과 동일하게 설정하는 것을 권장합니다. 오라클에서는 100이상의 값으로 설정할 것을 권장 하고 있습니다.


[ 매개변수 - fs.file-max ] Red Hat Linux 서버를 구성하는 과정에서, 사용 가능한 파일 핸들(file handle)의 수가 충분한지 확인하는 것을 매우 중요합니다. 파일 핸들의 최대 개수 설정에 따라 Linux 시스템에서 동시에 오픈할 수 있는 파일의 수가 달라지게 됩니다.
오라클은 전체 시스템의 파일 핸들 수를 최소 65536개 이상으로 설정 할 것을 권장 하고 있습니다.
전체 시스템에서 사용 가능한 파일 핸들의 최대 값을 확인 해보겠습니다.
[2010-12-09 04:06:03]-[root@calmmass:/proc/sys/fs]
# cat /proc/sys/fs/file-max |sed -e :a -e 's/\(.*[0-9]\)\([0-9]\{3\}\)/\1.\2/;ta'
104.857

[ 매개변수 - net.Ipv4.Ip_local_port_range ] 이부분은 새 접속에서 사용할 수 있는 포트의 사용 가능 범위를 확장하는 의미를 가지고 있습니다.
시스템에서 사용하는 포트번호는 /etc/services 파일에 구성 되어있습니다.
[2010-12-09 04:06:24]-[root@calmmass:/proc/sys/fs]
# tail /etc/services
binkp 24554/udp # Binkley
asp 27374/tcp # Address Search Protocol
asp 27374/udp # Address Search Protocol
.. 생략 ..

매개변수의 값을 확인 해보겠습니다. 오라클은 1024 ~ 65000까지 허용하도록 권장 합니다.
[2010-12-09 04:14:10]-[root@calmmass:/proc/sys/net/ipv4]
# cat /proc/sys/net/ipv4/ip_local_port_range |sed -e :a -e 's/\(.*[0-9]\)\([0-9]\{3\}\)/\1.\2/;ta'
32.768 61.000

[ 매개변수 - net.core.rmem_default, net.core.rmem_max ] 일반적인 경우의 대용량 Serving을 위한 설정 합니다. 오라클은 기본적으로 대용량 데이터베이스를 기준으로 하기 때문에 기본 설정 된 값을 변경해야 합니다. 아래와 같은 경우에는 기본 설정 값입니다.
[2010-12-09 04:18:03]-[root@calmmass:/proc/sys/net/core]
# cat /proc/sys/net/core/rmem_default |sed -e :a -e 's/\(.*[0-9]\)\([0-9]\{3\}\)/\1.\2/;ta'
65.535
[2010-12-09 04:18:29]-[root@calmmass:/proc/sys/net/core]
# cat /proc/sys/net/core/rmem_max |sed -e :a -e 's/\(.*[0-9]\)\([0-9]\{3\}\)/\1.\2/;ta'
131.071

[ 매개변수 - net.core.wmem_default, net.core.wmem_max] 소켓 출력 큐의 기본 값과 최대 값을 조정하기 위한 매개변수 입니다. 일반적인 경우의 대용량 Serving을 위한 설정이므로 역시 rmem_default, rmem_max의 값과 동일하게 구성해는 것이 바랍직 합니다. 기본적으로 설정 되어있는 값을 확인 해보겠습니다.
# cat /proc/sys/net/core/wmem_default |sed -e :a -e 's/\(.*[0-9]\)\([0-9]\{3\}\)/\1.\2/;ta'
65.535
[2010-12-09 04:23:05]-[root@calmmass:/proc/sys/net/core]
# cat /proc/sys/net/core/wmem_max |sed -e :a -e 's/\(.*[0-9]\)\([0-9]\{3\}\)/\1.\2/;ta'
131.071

[ 커널 매개변수 반영 ]
이상으로 매개변수의 용도와 설정값을 확인 하는 방법을 실습 했습니다.
이번에는 커널 매개변수를 오라클 기준으로 변경해서 반영 해보도록 하겠습니다. 기본적으로는 위에 나와있는 설정 파일에 값을 변경 해도 되며, sysctl -w [매개변수명]=value 명령어를 이용 할 수 있습니다. 하지만 이번 문서에서는 리눅스의 장점을 살려 환경설정 파일로 매개변수를 반영 하겠습니다.

오라클(바로가기) 설치 메뉴얼에는 아래와 같이 설정 하길 권장합니다.
cat >> /etc/sysctl.conf <<EOF
kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
EOF
/sbin/sysctl -p

파라매터를 더 추가해보겠습니다. (강추 입니다.)
kernel.shmmax=536870912
kernel.shmmni=4096
kernel.shmall=2097152
kernel.sem=250 32000 100 128
fs.file-max=65536
net.ipv4.ip_local_port_range=1024 65000
net.core.rmem_default=262144
net.core.rmem_max=262144
net.core.wmem_default=262144
net.core.wmem_max=262144

2. Shell Limit 설정

오라클은 Linux 계정 별로 실행되는 프로세스와 열린 파일의 수를 제한하는 것을 권장합니다. 이를 위해, root 계정에서 아래 내용을 /etc/security/limits.conf 설정파일에 oracle10g 라는 특정 프로그램을 제어하는 방법을 설명 하겠습니다.

[참고] /lib/security/pam_limits.so 모듈이 사용할 설정 파일이 /etc/security/limits.conf 파일 입니다. 그중에서 각각 설정에 대해서 아래와 같이 정리 하였습니다.
domain : 제한을 할 대상으로써 사용자 이름이나 그룹 이름, 그리고 와일드 문자를 사용할 수 있습니다.
type : 강하게 제한할 것인지 아니면 어느 정도 여유를 줄 것인지 결정을 합니다.(soft, hard)
item : 제한을 할 항목입니다.
- core : core 파일 사이즈(KB)
- data : 최대 데이터 크기(KB)
- fsize : 최대 파일 사이즈(KB)
- memlock : 최대 locked-in-memory 주소 공간(KB)
- nofile : 한번에 열 수 있는 최대 파일 수
- rss : 최대 resident set size(KB)
- stack : 최대 스택 사이즈(KB)
- cpu : 최대 CPU 점유 시간(MIN)
- nproc : 최대 프로세스 개수
- as : 주소 공간 제한
- maxlogins : 동시 로그인 최대 수
- priority : 사용자 프로세스가 실행되는 우선 순위

[참고] ulimit를 이용하여 리소스를 제한하는 방법입니다. ulimit는 PAM과는 조금 다르게 root계정까지도 제한을 할 수 있습니다. 여기에서 제한에는 두가지 종류가 있습니다.
Soft Limit : 새로운 프로그램이 생성되면 디폴트로 적용되는 제한
Hard Limit : Soft Limit에서 최대 늘릴 수 있는 제한
단, Hard Limit는 root 유저에 의해 조정 가능하지만 무한히 늘리 수 없기 때문에 커널에서 해당 설정 값을 조정 후 늘릴 수 있습니다.


[ oracle10g soft nproc 2047 ] oracle10g 라는 프로그램이 처음 수행시 기본값으로 사용하는 프로세스는 최대 2047로 제한한다는 의미 입니다.
[ oracle10g hard nproc 16384 ] oracld10g 라는 프로그램이 수행시 사용하는 프로세스는 최대 16384로 제한 한다는 의미 입니다.
[ oracle10g soft nofile 1024 ] oracle10g 라는 프로그램이 처음 수행시 기본값으로 사용하는 파일은 최대 1024로 제한 한다는 의미입니다.
[ oracle10g hard nofile 65536 ] oracle10g 라는 프로그램이 수행시 사용하는 파일은 최대 65536으로 제한 한다는 의미 입니다.


[의문점] 어떤 방식으로 해야 이상적인 설정 일까요?
이상적인 설정은 실제로 oracle database가 가동 되고 나서 개수 제한으로 에러가 발생 하지 않게 하는 것이 가장 이상적인 설정이라고 볼 수 있습니다. 그래서 최대한 해당 프로세스의 개수가 어느정도인지 파일의 개수는 평균적으로 어느정도 사용하는지 파악후 설정 해주는것이 바람직합니다.

그럼 특정 프로그램이 사용하는 프로세스의 개수를 테스트 해보도록 하겠습니다.
[2010-12-09 05:38:43]-[root@calmmass:/proc/sys/net/core]
# lsof -p 3094 |wc -l
1370

열려있는 파일 개수 확인 하는 방법
[2010-12-09 05:39:01]-[root@calmmass:/proc/sys/net/core]
# sysctl -a |grep file
fs.file-max = 104857
fs.file-nr = 1995 472 104857

마지막으로 /etc/security/limits.conf 리소스 제한 설정파일에 oracle 설치시 필요한 설정 내역은 아래와 같습니다.
oracle10g soft nproc 2047
oracle10g hard nproc 16384
oracle10g soft nofile 1024
oracle10g hard nofile 65536

Oracle을 각 OS별 설치하면서 느낀 점은 위와 같은 설정 내역이 조금씩 다르다는 점입니다.
그렇다면 이러한 설정 내역을 모두 외우는 것은 무의미하고 어떤 작업에 의해서 설정을 해야 하는지를 먼저 파악하는 것이 우선이라고 생각 했습니다.
각 설정 파일의 역활과 오라클이 구동 되었을때 사용하는 용도를 보면 조금 접근하기기 편하지 않을까 생각 해봅니다.