nginx + keepalived 부하 균형 (2)

대상: 고가 용
'고가 용성' (High Availability) 은 일반적으로 하나의 시스템 이 전문 적 인 설 계 를 거 쳐 휴업 시간 을 줄 이 고 서비스의 높 은 가용성 을 유지 하 는 것 을 묘사한다.
고가 용성 설 계 를 통 해 시스템 의 평균 무고 장 시간 (MTTF) 을 높 일 수 있다. 중요 한 시스템 이나 시스템 에서 중요 한 노드 에 대해 고가 용성 설 계 를 통 해 시스템 의 평균 무고 장 시간 이 기대 하 는 요구 에 도달 하도록 확보 해 야 한다.
앞의 NginX 부하 균형 방안 에 서 는 keepalived 를 사용 하여 NginX 노드 의 높 은 사용 가능 성 을 실현 하지만 그것 은 높 은 사용 가능 한 디자인 의 작업 방식 일 뿐이다.일반적으로 사용 가능 한 디자인 중의 여러 개의 불필요 한 설 비 는 다음 과 같은 세 가지 작업 방식 을 사용 할 수 있다.
마스터 방식 (비대 칭 방식) 호스트 작업, 준비 기 는 모니터링 준비 상황 에 있 습 니 다.호스트 가 다운 되 었 을 때 호스트 의 모든 작업 을 준비 하고 호스트 가 정상 으로 돌아 오 면 사용자 의 설정 에 따라 자동 또는 수 동 으로 서 비 스 를 호스트 로 전환 하여 실행 합 니 다. 데이터 의 일치 성 은 공유 저장 시스템 을 통 해 해결 합 니 다.
듀 플 렉 스 듀 플 렉 스 방식 (상호 지원) 두 호스트 는 동시에 각자 의 서비스 업 무 를 실행 하고 상황 을 모니터링 한다. 한 호스트 가 다운 되 었 을 때 다른 호스트 는 즉시 그의 모든 업 무 를 인수 하고 업무 의 실시 간 을 확보 하 며 서비스 시스템 의 관건 적 인 데 이 터 를 공유 저장 시스템 에 저장한다.
클 러 스 터 작업 방식 (다 중 서버 상호 준비 방식) 여러 대의 호스트 가 함께 작업 하고 각각 하나 또는 몇 개의 서 비 스 를 실행 하 며 각각 서비스 에 하나 이상 의 예비 호스트 를 정의 합 니 다. 특정한 호스트 가 고장 났 을 때 그 위 에서 실행 되 는 서 비 스 는 다른 호스트 에 의 해 연 결 될 수 있 습 니 다.
분명히 주종 방식 이 가장 간단 하지만 자원 낭비 상황 이 존재 한다.이중 작업 방식 은 자원 을 충분히 이용 할 수 있 지만 배치 가 비교적 복잡 하 므 로 두 노드 간 에 심장 박동 검 측 을 해 야 한다.클 러 스 터 작업 방식 과 듀 플 렉 스 방식 은 본질 적 인 차이 가 없 지만 복잡 도가 급 격 히 증가 해 건강 상태 가 많이 방송 되 는 것 외 에 뇌 파열, 중재, 정족 수 등 도 고려 해 야 한다.
본 고 는 쌍방 이 서로 준비 한 작업 방식 만 을 토론 한다.
keepalived 프로필
keepalived 는 LVS 의 확장 프로젝트 로 처음에는 LVS 부하 스케줄 러 의 단일 고장 문 제 를 해결 하기 위해 서 였 으 나 적용 성 이 강하 고 설정 이 간결 하 며 많은 다른 장소 에 도 사용 되 었 다. 예 를 들 어 NginX 부하 균형 이 높 은 사용 가능 한 디자인 이다.
keepalived 의 디자인 은 다음 과 같다.
WatchDog: checkers 와 vrrp 프로 세 스 모니터링 Checkers: 서버 건강 상태 검사 (healthchecking).사용자 정의 건강 검진 스 크 립 트 를 작성 할 수 있 습 니 다.
VRRP STACK: 건강 검진 이 실 패 했 을 때 (서 비 스 를 사용 할 수 없 음) 노드 에서 전환 합 니 다.VRRP (Virtual Router Redundancy Protocol, 가상 공유 기 중복 프로 토 콜) 의 그룹 방송 을 사용 하여 이 루어 집 니 다. IPVS wrappers: ipvs 규칙 을 생 성 합 니 다. LVS 에 만 사 용 됩 니 다. Netlink Reflector: vrpp 의 vip 주 소 를 설정 합 니 다. keepalived 는 노드 마다 같은 VRRP 인 스 턴 스 (vrrp instance) 를 설정 하고 MASTER 또는 BACKUP 상 태 를 지정 할 수 있 습 니 다.
Checkers 가 본 노드 의 서비스 가 사용 되 지 않 음 을 감 측 했 을 때 본 컴퓨터 의 VRRP 인 스 턴 스 를 정지 시 키 고 다른 노드 의 VRRP STACK 에 VRRP 인 스 턴 스 를 연결 하여 대외 적 으로 서 비 스 를 계속 사용 할 수 있 도록 합 니 다.
쌍방 향 상호 준비 방식 의 실현
keepalived 가 메 인 업 무 를 실현 하 는 자 료 는 곳곳에 있 습 니 다. 저 에 게 도 NginX 메 인 체제 의 예 가 있 습 니 다. 여 기 는 더 이상 반복 되 지 않 습 니 다.
사실 조금 만 머리 를 쓰 면 주 비 를 바탕 으로 쌍방 이 서로 준비 하고 심지어 군집 하 는 작업 방식 을 실현 할 수 있다. 왜냐하면 두 가지 전제 가 있 기 때문이다.
keepalived 는 노드 의 개 수 를 제한 하지 않 고 2 개 만 가능 합 니 다.
keepalived 는 노드 마다 하나의 VRRP 인 스 턴 스 만 있 을 수 있 습 니 다 그렇다면 쌍방 이 서로 준비 하 는 실현 원 리 는 다음 과 같다.
각 노드 에 두 개의 VRRP 인 스 턴 스 설정 두 개의 인 스 턴 스 는 각각 한 노드 를 위주 로 하고 다른 노드 를 준비 합 니 다 (BACKUP) DNS 폴 링 과 같은 외부 체 제 를 통 해 두 개의 VRRP 인 스 턴 스 를 동시에 대외 적 으로 서 비 스 를 제공 합 니 다 .
인 스 턴 스 설정
keepalived 의 프로필 /etc/keepalived/keepalived.conf 에는 3 부분 이 포함 되 어 있 습 니 다.
global defs: 전역 설정 vrrp instance: vrrp 인 스 턴 스, 가상 경로 그룹 을 정의 합 니 다.
virtual server: LVS 가상 서버 정의 이 안 에는 vrrp 인 스 턴 스 의 설정 만 예 로 들 수 있 습 니 다.
노드 1

vrrp_instance VI_1 { 
    state MASTER 
    interface eth0 
    virtual_router_id 51 
    priority 100 
    advert_int 1 
    authentication { 
        auth_type PASS 
        auth_pass password 
    } 
    virtual_ipaddress { 
        192.168.1.8 
    } 
} 
vrrp_instance VI_2 { 
    state BACKUP 
    interface eth0 
    virtual_router_id 52 
    priority 99 
    advert_int 1 
    authentication { 
        auth_type PASS 
        auth_pass password 
    } 
    virtual_ipaddress { 
        192.168.1.9 
    } 
}

노드 2

vrrp_instance VI_1 { 
    state BACKUP 
    interface eth0 
    virtual_router_id 51 
    priority 99 
    advert_int 1 
    authentication { 
        auth_type PASS 
        auth_pass password 
    } 
    virtual_ipaddress { 
        192.168.1.8                   
    } 
} 
vrrp_instance VI_2 { 
    state MASTER 
    interface eth0 
    virtual_router_id 52 
    priority 100 
    advert_int 1 
    authentication { 
        auth_type PASS 
        auth_pass password 
    } 
    virtual_ipaddress { 
        192.168.1.9                   
    } 
}

다음으로 이동:http://thinkinside.tk/2013/07/16/ha_keepalived.html