[Redundancy] 03. 웹 서버 다중화 - DNS 라운드로빈, IPVS를 이용한 로드밸런서
카테고리: REDUNDANCY
태그: redundancy linux
03-1. DNS 라운드로빈
DNS 이용해서 하나의 서비스에 여러 대의 서버를 분산시키는 방법으로, DNS 서버는 동일한 이름으로 여러 레코드를 등록시키면 질의할 때마다 다른 결과를 반환하며, 이 동작을 이용함으로써 여러 대의 서버에 처리를 분산시킬 수 있다.
■ DNS 라운드로빈의 문제점
| 문제점 | 설명 |
|---|---|
| 서버의 수만큼 글로벌 주소가 필요 | 수많은 서버로 부하분산하기 위해서는 IP주소를 많이 얻을 수 있는 서비스(회선)를 이용할 필요가 있다. |
| 균등하게 분산되는 것은 아님 | 모바일 사이트 등에서 문제가 되는 경우가 있다, 스마트폰으로부터의 접속은 캐리어 게이트웨이라고 하는 프록시 서버를 경유하는데, 프록시 서버에서는 이름변환 결과가 일정시간 동안 캐싱되므로 같은 프록시 서버를 경유하는 접속은 항상 같은 서버로 전달된다. 따라서, 균등하게 접속이 분산되지 않고 특정 서버에만 처리가 집중할 가능성이 있으며, 또한 PC에서도 DNS 질의 결과를 캐싱하기 때문에 균등하게 부하분산되지 않는다. DNS 레코드의 TTL을 짧게 설정함으로써 어느정도 개선할 수는 있지만, 반드시 TTL에 따라 캐시를 해제하는 것은 아니므로 주의할 필요가 있다. |
| 서버가 다운돼도 감지하지 못함 | DNS 서버는 웹 서버의 부하나 접속수 등의 상황에 따라 질의결과를 제어할 수가 없다 즉, 서버가 어떤 원인으로 다운되더라도 이를 검출하지 못 하고 계속 부하분산을 한다. 이로 인해 다운된 서버로 분산된 유저는 에러 페이지를 접하게 되며, DNS 라운드로빈은 어디까지나 부하분산하기 위한 방법이지 다중화하는 방법은 아니므로 다른 소프트웨어와 조합해서 헬스체크나 장애극복을 마련할 필요가 있다. |
■ DNS 라운드로빈과 로드밸런서의 차이
로드밸런서는 하나의 IP 주소에 대해 요청을 복수의 서버로 분산할 수 있고, DNS 라운드로빈에서는 웹 서버마다 다른 글로벌 주소를 할당할 필요가 있었지만 로드밸런서를 이용하면 글로벌 주소를 절약할 수 있다 또한, 다중화 적업에서는 DNS 라운드로빈에서는 서버측면에서 연구해서 구성을 해야하지만, 로드밸런서에서는 그럴 필요가 없다.
| 차이 | 설명 |
|---|---|
| 동작 | 로드밸런서는 서비스용 글로벌 주소를 가진 가상적인 서버(이하 가상서버)로서 동작한다 그리하여 클라이언트로부터 전송되어 온 요청을 실제 웹 서버(이하 리얼서버)로 중계함으로써 마치 자신이 웹 서버인 것처럼 작동한다. |
| 기능 | 로드밸런서는 여러 대의 리얼서버 중에 한 대를 선택해서 처리를 중계하며, 이 때 헬스체크가 실패하는 서버는 선택되지 않고 반드시 헬스체크가 성공한 서버를 선택한다 따라서 특정 서버 한 대가 정지해 있더라도 정상적으로 가동하고 있는 서버가 있는 한 서비스가 정지하지 않는다. |
03-2. IPVS(IP Virtaul Server) - 리눅스로 로드밸런서 구성
■ LVS(Linux Virtual Server)
클러스터링 기술을 사용하여 리눅스 환경에서 확장성 있고 가용성 높은 시스템 만드는 것을 목표로 하고 있는 프로젝트로 LVS 프로젝트의 성과물 중 하나로 리눅스 로드밸런서를 위한 IPVS가 있으며, 로드밸런서에 불가결한 부하분산 기능을 실현한다.
■ IPVS(IP Virtual Server)
리눅스는 특별한 소프트웨어를 설치하지 않아도 라우터로서 이용할 수 있으며 또한, 방화벽으로서도 충분히 실제 운용 가능한 패킷 필터링 기능 등 강력한 네트워크 기능을 내장하고 있고, 그 중 IPVS 라는 부하분산 기능을 제공하는 모듈도 포함하고 있다.
IPVS는 Netfilter Framework 기반으로 구현된 리눅스 커널 레벨에서 동작하는 L4 로드밸런싱 도구로 패킷을 효과적으로 추적하고 라우트하기 위해 IPVS는 리눅스 커널에 IPVS 테이블을 생성하여 해당 테이블 목록에 따라 특정 End Point로 설정된 스케줄링 알고리즘을 사용해서 부하분산을 수행한다.
로드밸런서에는 크게 L4 스위치, L7 스위치 두 종류가 있으며 기능은 다음과 같다.
| 종류 | 설명 |
|---|---|
| L4 스위치 | 트랜스포트 계층까지의 정보를 분석하므로 IP 주소나 Port 번호에 따라 분산 대상 서버를 지정할 수 있다. |
| L7 스위치 | 애플리케이션 계층까지의 정보를 분석하므로 Client로부터 요청된 URL에 따라 분산대상 서버를 지정할 수 있다. |
■ IPVS의 스케줄링 알고르즘
| 종류 | 설명 |
|---|---|
| rr(round-robin) | 리얼 서버를 처음부터 차례로 선택하여 모든 서버로 균등하게 처리가 분산된다. |
| wrr(weighted round-robin) | rr과 같지만 가중치를 가미해서 분산비율을 변경한다. 가중치가 큰 쪽을 빈번히 선택되므로 처리능력이 높은 서버는 가중치를 높게 설정하는 것이 좋다. |
| lc(least-connection) | 접속수가 가장 적은 서버를 선택한다. 어떤 알고리즘을 사용하면 좋을지 모를 경우에 사용해도 좋다. |
| wlc(weighted least-connection) | lc와 같지만 가중치를 가미해서 분산비율을 변경한다. 구체적으로는 『(접속수+1)/가중치』가 최소가 되는 서버를 선택, 고성능 서버는 가중치를 크게 하는 것이 좋다. |
| sed(shortest expected delay) | 가장 응답속도가 빠른 서버를 선택한다. 서버와의 응답시간을 계측하는 것이 아닌 ESTABLISHED 상태인 접속수가 적은 서버를 선택한다. wlc와 동일한 동작하지만 wlc에서는 ESTABLISHED 이외의 상태인 접속수를 더하는 점이 다르다. |
| nq(naver queue) | sed와 동일한 알고리즘이지만 active 접속수가 0인 서버를 최우선으로 선택한다. |
| sh(source hashing) | 소스 IP주소로부터 해시값을 계산해서 분산대상 리얼서버를 선택한다. |
| dh(destination hashing) | 목적지 IP주소로부터 해시값을 계산해서 분산대상 리얼서버를 선택한다. |
| lblc(locality-based least-connection) | 접속수가 가중치로 지정한 값을 넘기 전까지는 동일한 서버를 선택한다. 모든 서버의 접속수가 가중치로 지정한 값을 넘을 경우, 마지막에 선택된 서버가 계속 선택된다. |
| lblcr(lblc replication) | lblc와 동일하며 접속수가 가중치로 지정한 값을 넘고 있을 경우는 접속수가 가장 적은 서버로 선택된다. |
■ IPVS - DR(Direct Routing)
DR 방식은 리얼 서버와 로드밸런서가 가상 IP 주소를 공유해야 한다. 로드밸런서와 리얼 서버는 네트워크 인터페이스에 가상 IP가 설정돼 있어야 하며, 이 인터페이스를 이용해 로드밸런서는 요청 패킷을 받아들이고 스케줄링에 의해 선택된 리얼 서버로 직접 라우팅한다.
▶ 동작 방식 및 주요 특징
| 동작 순서 | 설명 |
|---|---|
| ① | 먼저 클라이언트가 가상 IP로 서비스 요청을 하면 로드밸런서는 리얼 서버 가운데 하나를 스케줄링한다. |
| ② | 선택된 서버로 직접 라우팅해 클라이언트의 요청을 리얼 서버로 전달한다. |
| ③ | 리얼 서버는 요청 사항을 처리한 후, 로도밸런서르 거치지 않고 클라이언트로 직접 응답한다. |
| ④ | 각 리얼 서버는 로드밸런서와 같은 가상 IP를 공유하고 있기때문에, 로드밸런서를 거치지 않고 클라이언트로 직접 응답할 수 있다. |
| 주요 특징 | 설명 |
|---|---|
| 병목 현상 감소 | NAT에 비해 로드 밸런서에서 병목 현상이 적게 나타납니다. (패킷을 클라이언트와 실제 서버 간에 직접 라우팅하는 방식으로 동작하기 때문이다.) |
| 클라이언트-서버 직접 통신 | 클라이언트와 실제 서버 간에 패킷 통신이 직접 이루어지므로 로드 밸런서의 처리 부하가 줄어들며, 이로 인해 더 빠른 응답 시간과 높은 처리량을 달성할 수 있다. |
| ☆리얼 서버와 로드밸런서가 가상 IP 주소를 공유 | 가상 IP 주소를 로드 밸런서와 리얼 서버가 공유해야 한다. 이는 리얼 서버의 클라이언트에 대한 응답이 로드밸런서를 거치지 않고 바로 클라이언트에게 전달되도록 하기 위해서이다. (클라이언트의 요청은 로드 밸런서를 통해 실제 서버로 전달되지만, 응답은 실제 서버가 바로 클라이언트로 전송됩니다. 이로써 네트워크 지연이 감소하고 응답 시간이 최적화된다.) |
| ☆ARP 문제 해결 필요 | 리얼 서버와 로드 밸런서가 같은 가상 IP 주소를 공유하기 때문에, 클라이언트가 로드 밸런서의 IP 주소를 대상으로 ARP 요청을 보내지만, 응답은 리얼 서버에서 직접 전달되기 때문에 발생합니다. 이 경우 클라이언트는 응답을 받지 못하거나, 잘못된 MAC 주소를 받아서 통신이 실패할 수 있습니다. 따라서 ARP(Address Resolution Protocol) 문제를 해결하기 위해 추가적인 설정이 필요합니다. |
▶ ARP Flux 문제
동일한 서브넷에 있는 두 개의 인터페이스를 가진 호스트가 동일한 서브넷의 인터페이스에 대한 ARP 요청을 동일한 서브넷의 모든 NIC에서 응답할 때 발생하는 문제를 말한다.
예를 들자면 호스트(A), eth0(A.A.A10) / 호스트(B), eth0(A.A.A.20), eth1(A.A.A.30)가 있고, 호스트(A)와 호스트(B) 사이에서 통신할 때 방화벽 등의 이유로 호스트(B)의 eth1 인터페이스를 거쳐야 한다고 가정할 때 호스트(A)에서 호스트(B)의 eth1 인터페이스로의 트래픽이 eth0 인터페이스에서 대신 처리된다.
▶ ARP Flux 문제 해결
Dispatcher(로드 밸런서)와 Real Server 모두 VIP를 가지고 있기 때문에, 클라이언트가 VIP의 MAC 주소를 묻는 ARP 요청을 전송했을 때 Dispatcher(로드 밸런서)와 Real Server 모두 응답하게 되면 클라이언트는 이들 중 특정 서버의 MAC 주소를 해당 VIP에 해당하는 MAC 주소로 기억하고는 이 서버에게만 모든 서비스 요청을 전송한다.
결국 부하분산을 더 이상 제공할 수 없으며, 임의의 클라이언트가 어떤 서버로부터 서비스를 제공받는지 관리할 수 없다. 이를 해결하기 위해 클라이언트가 ARP 요청을 전송했을 때 Dispatcher(로드 밸런서)만이 이에 응답하고, Real Server는 모두 ARP 요청을 무시해야 한다.
■ IPVS을 이용해 DR(Direct Routing) 구성하기 (CentOS Stream 8 기준)
▶ Dispatcher 서버 (로드밸런서 역학 서버)
클라이언트로부터 서비스 요청 패킷을 받아 미리 설정된 스케줄링 방식으로 리얼 서버에게 부하를 분산하는 역할을 수행
(1) 【 VIP 설정 】
# VIP는 외부 클라이언트에게 서비스를 제공하기 위해 사용될 IP 주소
ifconfig ens32:0 <Virtual_IP> netmask 255.255.255.0 up
(2) 【 Packet Forwarding 활성화 】
# 로드밸런서는 클라이언트로부터 전송된 요청 메시지를 Real Server로 전달해야 하므로, 반드시 Packet Forwarding 기능을 활성화 해야 한다.
echo 1 > /proc/sys/net/ipv4/ip_forward
(3) 【 ipvsadm 설치 및 서비스 등록】
yum -y install ipvsadm
# WEB 서비스 등록
ipvsadm -A -t <Virtula IP>:80 -s rr
# 사용법
ipvsadm <옵션>
| 옵션 | 설명 |
|---|---|
-A, --add-service |
새로운 가상 서비스를 추가합니다. |
-C, --clear |
모든 가상 서비스와 가상 서버를 삭제합니다. |
-D, --delete-service |
특정 가상 서비스를 삭제합니다. |
-E, --edit-service |
가상 서비스의 속성을 편집합니다. |
-a, --add-server |
가상 서비스에 새로운 가상 서버를 추가합니다. |
-d, --delete-server |
가상 서비스에서 가상 서버를 삭제합니다. |
-e, --edit-server |
가상 서비스의 가상 서버 속성을 편집합니다. |
-L, --list |
현재 설정된 IPVS 정보를 나열합니다. |
-R, --restore |
설정 파일에서 IPVS 정보를 복원합니다. |
-S, --save |
현재 IPVS 정보를 설정 파일에 저장합니다. |
-l, --list-services |
현재 설정된 가상 서비스 목록을 나열합니다. |
-n, --numeric |
호스트 이름과 포트 번호를 숫자로 표시합니다. |
-r, --list-servers |
특정 가상 서비스에 대한 가상 서버 목록을 나열합니다. |
-t, --set |
설정을 변경하거나 기본값을 설정합니다. |
-W, --wait |
명령이 완료될 때까지 대기합니다. |
-w, --weight |
가상 서버의 가중치를 설정합니다. |
-g, --gatewaying |
가상 서버의 라우팅 방식을 설정합니다.(Direct Routing) |
-m, --masquerading |
IPVS 패킷 마스커레이딩을 설정합니다.(NAT) |
▶ Real 서버 설정
(1) 【 VIP 설정 】
# Real Server는 고유의 IP 주소인 RIP(Real Server IP)를 갖고 있으며, Dispatcher는 RIP 주소를 기반으로 서비스 요청을 분산시킨다.
# DR 방식의 특성상 Client의 요청은 Real Server에서 클라이언트로 직접 전달되므로 Real Server는 VIP 주소도 함께 갖고 있어야 한다.
ifconfig lo:0 <Virtual IP> netmask 255.255.255.255 up
(2) 【 Routing Table 설정 】
# lo:0 장치에 VIP를 설정했으므로, 목적지가 VIP인 요청 메시지를 lo:0 장치로 전달해야 한다.
route add -host <Virtual IP> dev lo:0
(3) 【 ARP 응답 무시 설정 】
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
# "ifconfig ens32:0 <Virtual IP> netmask 255.255.255.255 up"를 통해서 가상 인터페이스를 생성했을 경우
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
▶ Dispatcher 서버 설정 - Real Server를 Virtual Service에 등록
(1) 【 Dispatcher를 Real Server로서 등록하기 】
# Dispatcher가 Real Server로서 Virtual Service를 제공하기 위해서는 Client로부터 요청 메시지를 Local host로 전송할 수 있도록 등록해야 함
ipvsadm -a -t <Virtual IP>:80 -r <Real IP> -g
(2) 설정 확인
ipvsadm -Ln
▶ 결과 확인
# Dispatcher Node
[root@dlp ~]# ifconfig
ens32: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.219.134 netmask 255.255.255.0 broadcast 192.168.219.255
ens32:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.219.100 netmask 255.255.255.0 broadcast 192.168.219.255
[root@dlp ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.219.100:80 rr
-> 192.168.219.135:80 Route 1 3 2
-> 192.168.219.136:80 Route 1 3 2
# Real Server
[root@node01 ~]# ifconfig
ens32: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.219.135 netmask 255.255.255.0 broadcast 192.168.219.255
lo:0: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 192.168.219.100 netmask 255.255.255.255
loop txqueuelen 1000 (Local Loopback)
[root@node02 ~]# ifconfig
ens32: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.219.136 netmask 255.255.255.0 broadcast 192.168.219.255
lo:0: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 192.168.219.100 netmask 255.255.255.255
loop txqueuelen 1000 (Local Loopback)
■ IPVS을 이용해 NAT 구성하기 (CentOS Stream 8 기준)
NAT 방식은 패킷 내의 IP 주소를 변경해 부하분산을 수행하는 방법
▶ 동작 방식
| 순서 | 설명 |
|---|---|
| ① | 클라이언트에게는 Dispatcher의 도메인 네임 또는 IP가 알려져 있고, 클라이언트가 이 알려진 도메인 네임이나 IP를 사용해 Dispatcher에게 서비스 요청 패킷을 전송한다. |
| ② | 또한 Dispatcher는 N개의 Real Server 중 하나를 정해진 스케줄링 방법에 의해 선택한 후 패킷 내의 목적지 주소를 해당 서버의 IP로 다시 작성한다. |
| ③ | Real Server는 클라이언트의 요청을 처리한 후, Dispatcher에게 응답을 돌려주고 이때 Dispatcher Node는 실제 응답의 발신자 주소를 다시 자신의 IP로 변경한 후 클라이언트에 서비스를 제공한다. |
▶ Dispatcher 서버 설정
(1) 【 VIP 설정 】
ifconfig eth0:1 <Virtual IP> netmask 255.255.255.0 up
(2) 【 Packet Forwarding 활성화 】
echo 1 > /proc/sys/net/ipv4/ip_forward
(3) 【 Virtual Service 등록 (ipvsadm 설정) 】
ipvsadm -A -t <Virtula IP>:80 -s rr
(4) 【 Real 서버를 Virtual Service에 등록 】
ipvsadm -a -t <Virtual IP>:80 -r <Real IP>:80 -m
(5) 설정 확인
ipvsadm -Ln
▶ 결과 확인
# Dispatcher Node
[root@dlp ~]# ifconfig
ens32: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.219.134 netmask 255.255.255.0 broadcast 192.168.219.255
ens32:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.219.100 netmask 255.255.255.0 broadcast 192.168.219.255
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.56.100 netmask 255.255.255.0 broadcast 192.168.56.255
[root@dlp ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.219.100:80 rr
-> 192.168.56.135:80 Masq 1 1 0
-> 192.168.56.136:80 Masq 1 1 1
# Real Server
[root@node01 ~]# ifconfig
ens32: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.56.135 netmask 255.255.255.0 broadcast 192.168.56.255
[root@node02 ~]# ifconfig
ens32: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.56.136 netmask 255.255.255.0 broadcast 192.168.56.255
댓글 남기기