☰

IPvsadm이 WLC 스케줄러에서 균등하게 균형을 유지하지 않습니다.

tag-icon • tag-icon linux ubuntu-10.04 lvs ldirectord
IPvsadm이 WLC 스케줄러에서 균등하게 균형을 유지하지 않습니다.

어떤 이유로 wlc 또는 lc 스케줄러를 사용할 때 ipvsadm은 실제 서버 간의 연결 균형을 동일하게 유지하지 못하는 것 같습니다. 하나의 실제 서버는 요청으로 인해 완전히 망가지는 반면 다른 서버는 상대적으로 적은 수의 연결을 수신합니다.

내 ldirectord.cf 파일은 다음과 같습니다.

quiescent     = yes
autoreload    = yes
checktimeout  = 10
checkinterval = 10

# *.example.com http
virtual = 192.0.2.111:http
    real = 10.10.10.1:http  ipip    10
    real = 10.10.10.2:http  ipip    10
    real = 10.10.10.3:http  ipip    10
    real = 10.10.10.4:http  ipip    10
    real = 10.10.10.5:http  ipip    10
    scheduler = lc
    protocol = tcp
    service = http
    checktype = negotiate
    request = "/lb"
    receive = "Up and running"
    virtualhost = "site.com"
    fallback = 127.0.0.1:http

문제의 원인일 수 있다고 생각되는 이상한 점은(하지만 확실하지는 않습니다) ipvsadm이 활성 연결을 제대로 추적하지 않는 것 같고 모두 비활성 연결로 표시된다는 것입니다.

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn    
TCP  192.0.2.111:http lc
  -> 10.10.10.1:http              Tunnel  10     0          10        
  -> 10.10.10.2:http              Tunnel  10     0          18        
  -> 10.10.10.3:http              Tunnel  10     0          3         
  -> 10.10.10.4:http              Tunnel  10     0          10        
  -> 10.10.10.5:http              Tunnel  10     0          5

그렇게 하면 ipvsadm -Lnc많은 연결이 표시되지만 ESTABLISHED 및 FIN_WAIT 상태에서만 가능합니다.

나는 이전에 Gentoo 기반 로드 밸런서에서 ldirectord를 사용하고 있었고 Ubuntu 10.4 LTS로 이동한 이후로 activeconn은 정확했습니다. 뭔가 다른 것 같습니다.

# ipvsadm -v
ipvsadm v1.25 2008/5/15 (compiled with popt and IPVS v1.2.1)

그렇다면 ipvsadm이 활성 연결을 제대로 추적하지 않아 로드 밸런싱이 잘못 작동하는 것인가요? 그렇다면 다시 제대로 작동하도록 하려면 어떻게 해야 합니까?

편집하다:상황이 더 이상해집니다 cat /proc/net/ip_vs. 올바른 활성 연결이 있는 것처럼 보이면 다음과 같습니다.

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP  C000026F:0050 rr 
  -> 0AB42453:0050      Tunnel  10     1          24        
  -> 0AB4321D:0050      Tunnel  10     0          23        
  -> 0AB426B2:0050      Tunnel  10     2          25        
  -> 0AB4244C:0050      Tunnel  10     2          22        
  -> 0AB42024:0050      Tunnel  10     2          23

답변1

lc(최소 연결)를 사용하면 모든 서버의 연결 수가 동일한 경우 항상 목록의 첫 번째 서버에 새 연결을 제공합니다. 이는 활용도가 매우 낮고 가끔 연결만 있는 경우 해당 연결은 항상 목록의 첫 번째 호스트로 이동함을 의미할 수 있습니다.

답변2

내가 가장 좋아하는 것은 wrr(Weigthed Round Robin)입니다. DR 접근 방식(직접 라우팅)을 사용하고 있다고 가정하는 것이 맞습니까?

이 경우 RS(실제 서버)의 응답은 LB를 통하지 않고 클라이언트로 직접 전달되므로 ipvsadm은 연결을 확인하지 않습니다.

답변3

연결 수로 판단하면 문제가 되지 않을 수 있지만 실제 서버 중 하나가 다른 서버보다 응답 속도가 느린 경우 최소 연결로 고르지 못한 분포가 발생할 수 있으며, 그러면 다른 서버보다 시간당 더 적은 수의 새 연결이 처리됩니다. 연결이 더 빨리 쌓입니다.

답변4

David의 명령 출력은 그가 일반적으로 DR의 변형으로 설정되는 터널 모드(IPIP)를 사용하고 있음을 나타냅니다. 그의 설정을 더 잘 이해하려면 라우팅 테이블이나 다이어그램을 확인해야 합니다.

그러나 LVS의 연결 추적은 TCP FIN 패킷을 볼 수 없기 때문에 혼란스러울 수 있다는 데 동의합니다.

ipvsadm에는 만료된 연결을 더 빨리 시간 초과하는 몇 가지 설정이 있습니다. 예를 들어 다음 명령은 1시간 후에 비활성 연결 시간을 초과합니다.

/sbin/ipvsadm --set 3600 120 300

클라이언트의 소스를 다시 확인해야 합니다. LVS의 기본 동작은 클라이언트 IP를 통해 지속적인 연결을 수행하는 것입니다. 따라서 동일한 테스트 클라이언트 IP에서 wget 또는 ab를 사용하여 스트레스 테스트를 수행하면 모든 연결이 동일한 실제 서버로 전송됩니다.

하프록시보다 지능적인 로드 밸런서이지만 완전히 투명하게 작동하려면 패킷의 반환 경로에 있어야 합니다.

관련 정보