클러스터 페일오버 매개 변수 구성
섀시 클러스터의 SRX 시리즈 디바이스는 하트비트 전송을 사용하여 제어 링크의 "상태"를 결정합니다. 놓친 심장 박동의 수가 구성된 임계값에 도달하면 시스템은 실패 조건이 존재하는지 여부를 평가합니다. 자세한 내용은 다음 주제를 참조하십시오.
섀시 클러스터 제어 링크 하트비트, 장애 및 복구 이해하기
섀시 클러스터 제어 링크 하트비트 이해하기
섀시 클러스터를 구성할 때 하트비트 임계값 및 하트비트 간격을 지정합니다.
시스템은 기본적으로 제어 링크의 상태를 모니터링합니다.
SRX5600 및 SRX5800 라인에서 지원되는 이중 제어 링크의 경우, Juniper 서비스 중복 프로토콜 프로세스(jsrpd)는 두 제어 링크 모두에서 제어 하트비트 메시지를 송수신합니다. 제어 링크 중 하나에서 심장 박동이 수신되는 한, Junos OS 다른 노드가 살아 있는 것으로 간주합니다.
옵션 및 heartbeat-interval
옵션의 heartbeat-threshold
제품은 페일오버가 트리거되기 전에 대기 시간을 정의합니다. 이러한 옵션의 기본 값은 3초의 대기 시간을 생성합니다. 5의 심장 박동 임계값과 1,000 밀리초의 하트 비트 간격은 5 초의 대기 시간을 제공합니다. 하트비트 임계값을 4로 설정하고 하트비트 간격을 1250밀리초로 설정하면 5초의 대기 시간이 생성됩니다.
섀시 클러스터 환경에서 1,000개 이상의 논리적 인터페이스를 사용하는 경우, 클러스터 하트비트 타이머를 기본값인 3초에서 증분하는 것이 좋습니다. SRX5400, SRX5600 또는 SRX5800 디바이스와 같은 SRX4600 최대 용량에서 페일오버 전에 구성된 시간을 최소 5초로 늘리는 것이 좋습니다.
섀시 클러스터 제어 링크 실패 및 복구 이해하기
제어 링크가 실패하면 Junos OS 보조 노드의 작동 상태를 180초 카운트다운에 사용할 수 없는 상태로 변경합니다. 또한 180초 동안 패브릭 링크가 실패하면 Junos OS 보조 노드를 기본으로 변경합니다. 그렇지 않으면 180초 후에 보조 노드 상태가 비활성화로 변경됩니다.
제어 링크가 끊어지면 시스템 로그 메시지가 생성됩니다.
제어 링크 실패는 하트비트 가 여전히 패브릭 링크를 통해 수신되는 동안 제어 링크에 대한 하트 비트를 수신하지 않는 것으로 정의됩니다.
합법적인 제어 링크 실패의 경우, 중복 그룹 0은 현재 기본 노드의 기본, 비활성 중복 그룹 x 가 활성화되고 보조 노드가 비활성화된 상태로 들어가는 노드에서 기본으로 유지됩니다.
보조 노드가 비활성화되면 관리 포트에 로그인하고 진단을 실행할 수 있습니다.
합법적인 제어 링크 실패가 발생했는지 확인하기 위해 시스템은 제어 링크와 패브릭 링크 모두에서 전송되는 중복 라이브라인 신호에 의존합니다.
시스템은 주기적으로 패브릭 링크를 통해 프로브를 전송하고 제어 링크를 통해 하트비트 신호를 전송합니다. 프로브와 하트비트 신호는 공통 시퀀스 번호를 공유하여 고유한 시간 이벤트에 매핑합니다. Junos OS 다음 두 가지 조건이 존재하는 경우 합법적인 제어 링크 실패를 식별합니다.
심장 박동의 임계값 수를 잃었습니다.
누락된 하트비트 신호에 해당하는 시퀀스 번호가 있는 적어도 하나의 프로브가 패브릭 링크에서 수신되었습니다.
제어 링크가 실패하면 180초 카운트다운이 시작되고 보조 노드 상태가 부적격합니다. 180초 카운트다운이 0에 도달하기 전에 패브릭 링크가 실패하면 두 링크의 손실이 다른 노드가 중단되었음을 나타내기 위해 두 링크의 손실이 시스템으로 해석되기 때문에 보조 노드가 기본이 됩니다. 제어 및 패브릭 링크가 동시에 손실되므로 노드가 더 이상 상태를 동기화하거나 우선순위를 비교하지 않으므로 두 노드 모두 일시적으로 기본이 될 수 있으며 이는 안정적인 운영 상태가 아닙니다. 그러나 제어 링크가 재설정되면 우선 순위 값이 높은 노드가 자동으로 기본이 되고 다른 노드가 보조 노드가 되고 클러스터가 정상 작동으로 돌아갑니다.
합법적인 제어 링크 실패가 발생하면 다음 조건이 적용됩니다.
이중화 그룹 0은 현재 기본 노드에서 기본으로 유지되며(따라서 라우팅 엔진 활성 상태로 유지), 노드의 모든 중복 그룹 x 가 기본이 됩니다.
시스템이 어떤 라우팅 엔진 기본인지 결정할 수 없는 경우, 중복 그룹 0에 대한 높은 우선 순위 값을 가진 노드가 기본이며 라우팅 엔진 활성화됩니다. (중복 그룹 0에 대한 문을 구성할 때 각 노드에
redundancy-group
대한 우선 순위를 구성합니다.)시스템은 보조 노드를 비활성화합니다.
비활성화된 모드에서 디바이스를 복구하려면 디바이스를 재부팅해야 합니다. 비활성화된 노드를 재부팅하면 노드는 동적 상태를 기본 노드와 동기화합니다.
보조 노드가 비활성화되어 있는 동안 구성을 변경한 경우, 노드를 재부팅한 후 커밋 명령을 실행하여 구성을 동기화합니다. 구성을 변경하지 않은 경우, 구성 파일은 기본 노드의 파일과 동기화된 상태로 유지됩니다.
중복 그룹 0에 대한 선점 기능을 활성화할 수 없습니다. 중복 그룹 0의 기본 노드를 변경하려면 수동 페일오버를 수행해야 합니다.
이중 제어 링크(SRX5600 및 SRX5800 디바이스에서 지원)를 사용할 때 다음 조건을 유의하십시오.
제어 링크 실패 시 호스트 인바운드 또는 아웃바운드 트래픽은 최대 3초 동안 영향을 받을 수 있습니다. 예를 들어, 중복 그룹 0이 노드 0에서 기본이며 노드 1의 네트워크 인터페이스 포트를 통해 라우팅 엔진 대한 Telnet 세션이 있는 경우를 고려하십시오. 현재 활성 제어 링크가 실패하면 이 실패가 감지될 때까지 Telnet 세션이 3초 동안 패킷을 잃게 됩니다.
커밋 프로세스가 두 노드에서 실행되는 동안 발생하는 제어 링크 실패는 커밋 실패로 이어질 수 있습니다. 이 상황에서 3초 후에 커밋 명령을 다시 실행합니다.
SRX5600 및 SRX5800 디바이스의 경우, 이중 제어 링크에는 섀시 클러스터의 각 노드에 두 번째 라우팅 엔진 필요합니다.
문을 설정하여 제어 링크 복구가 시스템에 의해 자동으로 수행되도록 지정할 수 있습니다 control-link-recovery
. 이 경우 시스템이 제어 링크가 정상인지 확인하면 비활성화된 노드에서 자동 재부팅이 발생합니다. 비활성화된 노드가 재부팅되면 노드가 클러스터에 다시 조인됩니다.
예: 섀시 클러스터 제어 링크 복구 구성
이 예는 제어 링크가 장애에서 복구된 후 시스템이 자동으로 인계할 수 있는 제어 링크 복구를 활성화하는 방법을 보여줍니다.
요구 사항
시작하기 전에 다음을 수행합니다.
섀시 클러스터 제어 링크를 이해합니다. 섀시 클러스터 컨트롤 플레인 및 컨트롤 링크 이해를 참조하십시오.
섀시 클러스터 이중 제어 링크를 이해합니다. 섀시 클러스터 이중 제어 링크 이해를 참조하십시오.
섀시 클러스터에 이중 제어 링크를 연결합니다. 섀시 클러스터의 SRX 시리즈 방화벽에 대한 듀얼 컨트롤 링크 연결을 참조하십시오.
개요
시스템이 제어 링크 복구를 자동으로 수행하도록 설정할 수 있습니다. 제어 링크가 복구된 후 시스템은 다음 작업을 수행합니다.
컨트롤 링크에서 최소 3개의 연속 심장 박동을 수신하는지 또는 이중 제어 링크(SRX5600 및 SRX5800 디바이스만 해당)의 경우 제어 링크 중 하나에서 수신하는지 여부를 확인합니다. 이는 제어 링크가 플래핑되지 않고 정상이 되도록 하기 위한 것입니다.
제어 링크가 정상 상태인지 확인하면 제어 링크에 장애가 발생할 때 노드 상태(부적격 또는 비활성화)와 관계없이 시스템이 자동 재부팅을 수행합니다. 노드가 재부팅되면 클러스터에 다시 연결됩니다. 수작업으로 개입할 필요가 없습니다.
이 예에서는 섀시 클러스터 제어 링크 복구를 활성화합니다.
구성
절차
단계별 절차
섀시 클러스터 제어 링크 복구를 활성화하려면,
제어 링크 복구를 활성화합니다.
{primary:node0}[edit] user@host# set chassis cluster control-link-recovery
디바이스 구성이 완료되면 구성을 커밋합니다.
{primary:node0}[edit] user@host# commit