Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

2.3. keepalived 스케줄링 개요

Keepalived를 사용하면 지원되는 다양한 스케줄링 알고리즘으로 인해 실제 서버에서 트래픽을 분산할 때 상당한 유연성을 제공합니다. 로드 밸런싱은 DNS의 계층적 특성과 클라이언트 머신의 캐싱으로 인해 부하 분산이 발생할 수 있는 Round-Robin DNS 와 같이 유연성이 떨어집니다. 또한, LVS 라우터에서 사용하는 하위 수준 필터링은 네트워크 패킷 수준에서의 분산 로드로 인해 컴퓨팅 오버헤드가 최소화되고 확장성을 높이기 때문에 애플리케이션 수준 요청 전달보다 이점이 있습니다.
할당된 가중치를 사용하면 개별 시스템에 임의의 우선 순위를 지정할 수 있습니다. 이러한 형태의 스케줄링을 사용하면 다양한 하드웨어 및 소프트웨어 조합을 사용하여 실제 서버 그룹을 생성할 수 있으며 활성 라우터는 각 실제 서버를 균등하게 로드할 수 있습니다.
Keepalived의 스케줄링 메커니즘은 IP 가상 서버 또는 IP VS 모듈이라는 커널 패치 컬렉션에서 제공합니다. 이러한 모듈을 사용하면 단일 IP 주소에서 여러 서버에서 원활하게 작동하도록 설계된 계층4(L 4) 전송 계층 전환이 가능합니다.
패킷을 실제 서버로 효율적으로 추적하고 라우팅하기 위해 IPVS는 커널에서 IPVS 테이블을 빌드합니다. 이 테이블은 활성 LVS 라우터에서 가상 서버 주소로 요청을 리디렉션하고 풀의 실제 서버에서 반환하는 데 사용됩니다.

2.3.1. keepalived Scheduling 알고리즘

IPVS 테이블이 사용하는 구조는 관리자가 지정된 가상 서버에 대해 선택하는 스케줄링 알고리즘에 따라 다릅니다. 클러스터 가능한 서비스 유형 및 이러한 서비스 예약 방법을 최대한 유연하게 지원하기 위해 Keepalived는 아래에 나열된 다음 스케줄링 알고리즘을 지원합니다.
round-Robin Scheduling
실제 서버 풀 주위에 각 요청을 순차적으로 배포합니다. 이 알고리즘을 사용하면 모든 실제 서버가 용량 또는 로드와 관계없이 동일하게 처리됩니다. 이 스케줄링 모델은 라운드 로빈 DNS와 유사하지만 호스트 기반이 아닌 네트워크 연결 기반이므로 더 세분화됩니다. 로드 밸런서 라운드 로빈 스케줄링은 캐시된 DNS 쿼리로 인한 불균형이 발생하지 않습니다.
가중치가 Round-Robin Scheduling
각 요청을 실제 서버 풀에 순차적으로 배포하지만 용량이 큰 서버에 더 많은 작업을 제공합니다. 용량은 사용자가 할당한 가중치 요인으로 표시되므로 동적 로드 정보에 의해 상향 또는 아래로 조정됩니다.
풀의 실제 서버 용량에 상당한 차이가 있는 경우 가중치가 지정된 라운드 로빈 스케줄링을 선택하는 것이 좋습니다. 그러나 요청 부하가 크게 달라지면 가중치가 많은 서버가 요청 공유보다 더 많이 응답할 수 있습니다.
least-Connection
활성 연결이 더 적은 실제 서버에 더 많은 요청을 배포합니다. IPVS 테이블을 통해 실제 서버에 대한 실시간 연결을 추적하므로 최소 연결은 동적 스케줄링 알고리즘의 유형이므로 요청 로드에 높은 수준의 변형이 있는 경우 더 나은 선택이 가능합니다. 각 멤버 노드에 거의 동일한 용량이 있는 실제 서버 풀에 가장 적합합니다. 서버 그룹에 다른 기능이 있는 경우 weighted least-connection 스케줄링을 더 잘 선택할 수 있습니다.
가중치 Least-Connections
용량을 기준으로 활성 연결이 적은 서버에 더 많은 요청을 배포합니다. 용량은 사용자가 할당한 가중치로 표시되므로 동적 로드 정보에 의해 상향 또는 아래로 조정됩니다. 가중치를 추가하면 실제 서버 풀에 다양한 용량의 하드웨어가 포함된 경우 이 알고리즘이 이상적입니다.
locality-Based Least-Connection Scheduling
대상 IP에 비해 활성 연결이 적은 서버에 더 많은 요청을 배포합니다. 이 알고리즘은 프록시 캐시 서버 클러스터에서 사용하도록 설계되었습니다. 서버가 용량을 초과하고 부하에 서버가 있는 경우가 아니면 IP 주소의 IP 주소를 해당 주소의 서버로 라우팅합니다. 이 경우 로드가 가장 적은 실제 서버에 IP 주소를 할당합니다.
복제 일정을 사용한 지역 기반 Least-Connection 스케줄링
대상 IP에 비해 활성 연결이 적은 서버에 더 많은 요청을 배포합니다. 이 알고리즘은 프록시 캐시 서버 클러스터에서 사용하도록 설계되었습니다. 대상 IP 주소를 실제 서버 노드의 하위 집합에 매핑하여 로컬 기반 Least-Connection 스케줄링과 다릅니다. 그런 다음 요청은 이 하위 집합에서 연결 수가 가장 낮은 서버로 라우팅됩니다. 대상 IP의 모든 노드가 용량을 초과하는 경우 실제 서버의 전체 풀에서 해당 대상 IP의 실제 서버 하위 집합에 가장 적은 실제 서버를 추가하여 해당 대상 IP 주소에 대한 새 서버를 복제합니다. 그런 다음 가장 로드된 노드가 실제 서버 하위 집합에서 삭제되어 초과 복제를 방지합니다.
대상 해시 스케줄링
정적 해시 테이블에서 대상 IP를 확인하여 실제 서버 풀에 요청을 배포합니다. 이 알고리즘은 프록시 캐시 서버 클러스터에서 사용하도록 설계되었습니다.
소스 해시 스케줄링
정적 해시 테이블에서 소스 IP를 조회하여 실제 서버 풀에 요청을 배포합니다. 이 알고리즘은 여러 방화벽이 있는 LVS 라우터를 위해 설계되었습니다.
Expected Delay
지정된 서버의 연결 수를 할당된 가중치로 나눈 연결 수에 따라 지연이 예상되는 서버에 연결 요청을 배포합니다.
never Queue
처음 찾고 연결하는 2가지 스케줄러로, 유휴 상태이거나 연결이 없는 서버에 연결 요청을 보냅니다. 유휴 서버가 없는 경우 스케줄러는 Shortest Expected Delay 와 동일한 방식으로 지연이 가장 적은 서버로 기본 설정됩니다.

2.3.2. 서버 Weight 및 스케줄링

로드 밸런서 관리자는 실제 서버 풀의 각 노드에 가중치 를 할당할 수 있습니다. 이 가중치는 임의의 가중치 인식 스케줄링 알고리즘(예: 가중치 최소 연결)에 영향을 미치는 정수 값이며, LVS 라우터가 다른 기능을 사용하여 하드웨어를 균등하게 로드하는 데 도움이 됩니다.
가중치는 서로 상대적인 비율로 작동합니다. 예를 들어 하나의 실제 서버에 가중치가 1이고 다른 서버의 가중치가 5인 경우 가중치가 5인 서버는 다른 서버가 얻는 1개의 연결에 대해 5개의 연결을 가져옵니다. 실제 서버 가중치의 기본값은 1입니다.
실제 서버 풀의 다양한 하드웨어 구성에 가중치를 추가하면 클러스터를 보다 효율적으로 분산하는 데 도움이 될 수 있지만 실제 서버가 실제 서버 풀에 도입되고 가상 서버가 가중치 최소 연결을 사용하여 예약될 때 일시적인 불균형이 발생할 수 있습니다. 예를 들어 실제 서버 풀에 세 개의 서버가 있다고 가정합니다. 서버 A 및 B의 가중치는 1이고 세 번째 서버 C의 가중치는 2입니다. 어떤 이유로든 서버 C가 다운되면 서버 A 및 B는 중단된 로드를 균등하게 분산합니다. 그러나 서버 C가 다시 온라인 상태가 되면 LVS 라우터에는 0개의 연결이 있고 서버 A 및 B와 대조될 때까지 들어오는 모든 요청이 있는 서버를 플러딩합니다.