lvs 클러스터, NAT 모드 및 DR 모드, keepalive

원리: 먼저 로드 밸런서는 고객의 요청 패킷을 수신하면 스케줄링 알고리즘을 기반으로 어느 백엔드 실제 서버(RS)에 요청을 보낼지 결정합니다.
그런 다음 로드 밸런서는 클라이언트가 보낸 요청 패킷의 대상 IP 주소와 포트를 백엔드 실제 서버의 IP 주소(RIP)로 변경합니다.
실제 서버는 요청에 응답한 후 기본 경로를 확인하고 응답 데이터 패킷을 로드 밸런서로 보냅니다.
패킷의 소스 주소를 가상 주소(VIP)로 변경하고 클라이언트로 다시 보냅니다.

장점: 클러스터의 서버는 로드 밸런서에 합법적인 IP 주소가 있는 한 TCP/IP를 지원하는 모든 운영 체제를 사용할 수 있습니다.

단점: 확장성이 제한됩니다. 서버 노드가 너무 많이 커지면 모든 요청과 응답이 로드 밸런서를 통과해야 하기 때문에
따라서 로드 밸런서는 전체 시스템의 병목 현상이 됩니다.

주소 번역이 특징

주소 변환: 내부 네트워크 - 외부 네트워크, 소스 IP 주소는 SNAT로 변환됩니다.

외부망-내부망은 목적지 IP 주소 DNAT로 변환

lvs 도구

ipvsadmlvs 클러스터 설정 및 관리 도구

-A는 가상 서버 VIP를 추가합니다.

-D 가상 서버 주소 삭제

-s는 로드 밸런싱 스케줄링 알고리즘을 지정합니다.

-a 실제 서버를 추가합니다.

-d 실제 서버 삭제

-t는 VIP 주소와 포트를 지정합니다.

-r은 rip의 주소와 포트를 지정합니다.

-m NAT 모드 사용

-g DR 모드 사용

-i 터널 모드 사용

-w 가중치를 설정합니다

-p 60 60초 동안 연결을 유지합니다. 연결 유지 시간을 설정합니다.

-l 목록 보기

-n 디지털 디스플레이

연산

설문조사 rr

가중 폴링 wrr

최소 연결 lc

가중 최소 링크 wlc

실험

데이터 흐름

nginx 1 RS1 192.168.233.20

nginx2 RS2 192.168.233.30

test1 스케줄러 ens33 192.168.233.10 ens36 12.0.0.1

test2 클라이언트 12.0.0.10

단계

1. 스케줄러 구성 (test1 192.168.233.10)

yum -y ipvsadm* -y를 설치하세요

Ens33 구성

systemctl 네트워크 재시작

Ens36 구성

cd /etc/sysconfig/network-scripts/

cp ifcfg-ens33 ifcfg-ens36

vim ifcfg-ens36

systemctl 네트워크 재시작

2. RS 구성(nginx1 및 nginx2)

nginx1 구성 192.168.233.20 게이트웨이 수정

systemctl 네트워크 재시작

nginx2 구성 192.168.233.30 게이트웨이 수정

systemctl 네트워크 재시작

vim /usr/local/nginx/html/index.html

방문한 페이지의 내용 수정

접속이 연결되어 있는지 확인하세요

3. 주소변환 (test1 192.168.233.10)

iptables -t nat -vnL nat 테이블에 정책이 있는지 확인합니다.

iptables -t nat -A POSTROUTING -s 192.168.233.0/24 -o ens36 -j SNAT --to 12.0.0.1

192.168.233.0/24의 장치 주소가 12.0.0.1로 변환됩니다.

ipvsadm -C는 원래 정책을 지웁니다.

ipvsadm -A -t 12.0.0.1:80 -s rr VIP 주소 및 포트 지정

먼저 가상 서버의 VIP, IP, 포트를 추가한 후 실제 서버를 추가하세요.

ipvsadm -a -t 12.0.0.1:80 -r 192.168.233.20:80 -m

-실제 서버 추가

-t는 VIP 주소를 지정합니다

-r은 실제 서버의 주소와 포트를 지정합니다.

-m 모드를 nat 모드로 지정합니다.

ipvsadm -ln 보기

ipvsadm-저장 저장

ipvsadm -D -t 192.168.233.10:80 정책 삭제

ipvsadm -d -r 192.168.233.20: -t 12.0.0.1:80 노드 서버 삭제

5. 라우팅 및 포워딩 기능 활성화

vim /etc/sysctl.conf

넷.ipv4.ip_포워드=1

4. 클라이언트(test2 12.0.0.10)

test2의 IP 주소 및 게이트웨이 수정

실험 결과

가중 폴링

DR 모드

개념

다이렉트 라우팅 모드입니다

NAT 모드: 스케줄러는 전체 LVS 클러스터에서 가장 중요합니다. NAT 모드에서는 요청 수신, 로드 밸런싱 알고리즘에 따라 트래픽 전달 및 클라이언트에 응답 전송을 담당합니다.

DR 모드: 스케줄러는 여전히 요청 수신을 담당하고 로드 밸런싱 알고리즘에 따라 트래픽을 RS로 전달하며 응답은 RS에서 클라이언트로 직접 전송됩니다.

직접 라우팅(Direct Routing): 레이어 2 전달 모드로, 레이어 2는 데이터 패킷의 소스 IP와 대상 IP를 수정하지 않고 소스 MAC 주소와 대상 MAC 주소를 기반으로 데이터 프레임을 전달합니다. 데이터 패킷의 MAC 주소를 기반으로 전달합니다.

DR 모드에서 LVS는 가상 IP 주소도 유지하며 모든 요청은 레이어 2 전달이 사용되므로 클라이언트의 요청이 스케줄러에 도달하면 로드 밸런싱 알고리즘과 VIP 서버에 따라 RS가 선택됩니다. 대상 mac은 RS의 mac 주소가 됩니다. RS는 요청을 처리한 후 스케줄러를 거치지 않고 메시지에 포함된 클라이언트의 소스 mac 주소에 따라 클라이언트에 직접 응답을 보낼 수 있습니다.

원리: 먼저 로드 밸런서는 고객의 요청 패킷을 수신하면 스케줄링 알고리즘을 기반으로 어느 백엔드 실제 서버(RS)에 요청을 보낼지 결정합니다.
그런 다음 로드 밸런서는 클라이언트가 보낸 요청 패킷의 대상 MAC 주소를 백엔드 실제 서버의 MAC 주소(R-MAC)로 변경합니다.
실제 서버는 요청에 응답한 후 기본 경로를 확인하고 로드밸런서를 거치지 않고 클라이언트에 직접 응답 패킷을 보냅니다.

장점: 로드 밸런서는 백엔드 노드 서버에 요청 패킷을 배포하는 역할만 담당하는 반면 RS는 응답 패킷을 사용자에게 직접 보냅니다.
따라서 로드 밸런서를 통한 대량의 데이터 흐름이 줄어듭니다. 로드 밸런서는 더 이상 시스템의 병목 현상이 아니며 엄청난 양의 요청을 처리할 수 있습니다.

단점: 로드밸런서와 실제 서버 RS 모두 동일한 물리적 네트워크 세그먼트에 연결된 네트워크 카드가 있어야 하며 동일한 LAN 환경에 있어야 합니다.

데이터 흐름 다이어그램

질문:

1.VIP 주소 충돌

이유: 스케줄러가 VIP로 구성되어 있고 RS도 VIP 주소로 구성되어 있습니다. VIP 주소 충돌은 스케줄러와 RS가 모두 동일한 네트워크 세그먼트에 있기 때문에 ARP 통신 장애를 유발합니다. 전체 LAN을 통해 브로드캐스트되므로 모든 장치가 이를 수신합니다.

이 머신의 물리적 IP 주소만 응답하도록 lo의 루프백 응답을 차단하는 방법입니다.

해결책: 커널 매개변수를 수정하십시오.arp_ignore=1

시스템의 물리적 IP 주소만 ARP 요청에 응답하고 lo 루프백 인터페이스는 ARP 요청에 응답하지 않습니다.

2. 메시지가 반환되면 VIP 주소가 그대로 유지됩니다. 클라이언트는 어떻게 응답을 받을 수 있나요?

해결책:arp_announce=2

시스템은 ARP 요청에 응답하기 위해 IP 패킷의 소스 주소를 사용하지 않고 물리적 인터페이스의 IP 주소를 직접 보냅니다.

DR 모드 구현

nginx1 RS (실제 IP) 192.168.233.20

nginx2 RS 192.168.233.30

192.168.233.100 비피에이

스케줄러 192.168.233.10

클라이언트 192.168.233.40

단계

1. 스케줄러 구성 (test1 192.168.233.10)

yum -y ipvsadm* -y를 설치하세요

가상 네트워크 카드 추가 ens33:0

스케줄러의 응답 매개변수 수정

vim /etc/sysctl.conf

넷.ipv4.ip_포워드=0
net.ipv4.conf.all.전송_리디렉션=0
net.ipv4.conf.기본값.전송_리디렉션=0
net.ipv4.conf.ens33.전송_리디렉션=0

시스템 설정 -p

정책 추가

cd /옵트

ipvsadm -A -t 192.168.233.100:80 -s rr

ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.20:80 -g

ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.30:80 -g

ipvsadm-save >/etc/sysconfig/ipvsadm

systemctl 재시작 ipvsadm

ipvsadm -ln

2. RS 구성(nginx1 및 nginx2) [두 번 모두 수정해야 함]

정적 페이지의 표시 콘텐츠 수정

vim /usr/local/nginx/html/index.html

systemctl nginx 재시작

루프백 주소 추가

cd /etc/sysconfig/network-scripts/

cp ifcfg-lo ifcfg-lo:0

vim ifcfg-lo:0

lo:0 인터페이스를 VIP로 추가

경로 추가 -호스트 192.168.233.100 dev lo:0

IP 주소를 192.168.233.100으로 설정하고 루프백 인터페이스에 lvs의 VIP로 추가합니다. 라우팅 모드를 통해 RS로 전달되므로 VIP가 실제 서버를 식별할 수 있습니다.

RS 실제 서버의 커널 응답 수정

vim /etc/sysctl.conf

net.ipv4.conf.lo.arp_ignore=1
net.ipv4.conf.lo.arp_announce=2
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

실험 결과

VIP 폴링 알고리즘 수정

정책 폴링의 가중치 수정

요약하다

로드 밸런싱을 위한 lvs와 nginx의 차이점

LVS는 커널 모드 IP + 포트를 사용하는 4계층 포워딩이며 4계층 프록시로만 사용할 수 있습니다.

nginx 4계층 프록시 또는 7계층 프록시

요약실험

lvs(DR 모드)+nginx+tomcat

LVS는 4계층 전달을 구현하고 nginx는 7계층 전달(동적)을 구현합니다. LVS의 VIP 주소에 액세스하면 동적 및 정적 분리가 가능합니다.

데이터 흐름 다이어그램

실험 단계

위의 DR 모드 실험을 기반으로 동적 및 정적 분리가 달성됩니다.

1. 톰캣 부분

1. tomcat1과 tomcat2에 각각 동적 페이지를 생성합니다.

<%@ 페이지 언어="java" 가져오기="java.util.*" 페이지 인코딩="UTF-8"%>
<html>
<head>
<title>JSP 테스트1 페이지</title>
</head>
<body>
<% out.println("동적 페이지 1, http://www.test1.com");%>
</body>
</html>

2. tomcat1 및 tomcat2에 각각 사이트를 추가합니다.

cd conf

vim 서버.xml

원본 사이트를 먼저 삭제하세요.

포트가 시작되었는지 확인

192.168.233.40:8080/index.jsp를 방문하세요.

2. nginx 부분

nginx2 및 nginx3 구성

cd /usr/local/nginx/conf/

cp nginx.conf nginx.conf.bak.2024.07.08

vim nginx.conf

업스트림 톰캣 {
서버 192.168.233.40:8080 가중치=1;
서버 192.168.233.50:8080 가중치=1;
}

위치 ~ .*.jsp$ {
프록시_패스 http://tomcat;
프록시_세트_헤더 호스트 $호스트;
proxy_set_header X-실제 IP $원격_주소;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

그런 다음 systemctl이 nginx를 다시 시작합니다.

nginx1 프록시 구성

4계층 에이전트가 되어보세요

cd /usr/local/nginx/conf

vim nginx.conf

그런 다음 systemctl이 nginx를 다시 시작합니다.

실험 결과

192.168.100:81 정적 페이지 방문

192.168.233.100:82/index.jsp 동적 페이지를 방문하세요.

lvs의 세 가지 작업 모드

NAT DR TUN

장점: 주소 변환, 간단한 구성, 최고의 성능 WAN, 장거리 데이터 패킷 전달 가능

단점 성능 병목 현상 크로스 네트워크 세그먼트 전용 채널을 지원하지 않으며 VPN 개설 필요(비용이 발생함)

RS 요구 사항: 비물리적 인터페이스에 대한 ARP 응답은 비활성화되어야 합니다.

RS 수량 10~20개 100개 100개

인터뷰 질문들:

1. lvs의 세 가지 모드와 차이점을 간략하게 설명하세요.

위의 테이블

2. Keepalive에서 분할 브레인을 해결하는 방법

고가용성 HA 아키텍처

개념

스케줄러의 고가용성을 위한 vs 클러스터의 고가용성 아키텍처입니다.

vrp를 기반으로 메인 및 백업 스케줄러 구현

메인 스케줄러 및 백업 스케줄러(여러 장치)

메인 스케줄러가 정상적으로 작동하는 경우 백업은 완전히 중복 상태(대기)가 되어 클러스터 작업에 참여하지 않습니다. 기본 스케줄러가 실패한 경우에만 백업 서버가 기본 스케줄러의 작업을 맡습니다. 기본 스케줄러가 기능을 다시 시작하면 기본 스케줄러는 계속해서 클러스터의 입구 역할을 하고 대기 스케줄러는 계속 중복 상태로 유지되므로 반드시 우선순위에 따라 달라지지는 않습니다.

Keepalive는 vrp 프로토콜을 기반으로 lvs 고가용성 솔루션을 구현합니다.

1.멀티캐스트 주소

224.0.0.18은 멀티캐스트 주소를 기반으로 통신하고 기본 장치와 보조 장치 간에 메시지를 보냅니다.상대가 살아 있는지 판단

2. 우선순위에 따라 기본 위치와 보조 위치를 결정합니다.

3. 장애 조치(Failover), 기본 서버에 장애가 발생해도 백업 서버가 계속 작동합니다.주님께서 회복하셔서 대기중이십니다

4. 기본과 보조 사이의 전환은 VIP 주소의 전환입니다.

Keepalive는 LVS용으로 특별히 나타나지만 LVS 전용은 아닙니다.

핵심 모듈: 주요 프로세스의 시작 및 유지 관리와 전역 구성 파일 로드를 담당하는 keepalive의 핵심 모듈입니다.

vrrp 모듈: 주요 기능 모듈인 vrrp 프로토콜을 구현하는 모듈

체크 모듈: 상태 점검을 담당하며, 백그라운드에서 실제 서버의 상태도 확인할 수 있습니다.

연결 유지 실험

test1 192.168.233.10 주

test2 192.168.233.50 을(를) 연결

192.168.233.100 비피에이

nginx1 192.168.233.20

nginx2 192.168.233.30

클라이언트 192.168.233.40

실험 단계

1. 기본 작업과 보조 작업 모두 동일한 방식으로 수행되어야 합니다.

yum -y ipvsadm keepalived를 설치하세요

vim /etc/sysctl.conf

넷.ipv4.ip_포워드=0
net.ipv4.conf.all.전송_리디렉션=0
net.ipv4.conf.기본값.전송_리디렉션=0
net.ipv4.conf.ens33.전송_리디렉션=0

시스템 설정 -p

ipvsadm -C

ipvsadm -A -t 192.168.233.100:80 -s rr

ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.20:80 -g

ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.30:80 -g

ipvsadm-save >/etc/sysconfig/ipvsadm

systemctl 재시작 ipvsadm

ipvsadm -ln

주인

cd /etc/keepalive

vim keepalived.conf

기술나눔