클러스터 장애 조치(failover) 매개 변수 구성
섀시 클러스터의 SRX 시리즈 디바이스는 하트비트 전송을 사용하여 제어 링크의 "상태"를 확인합니다. 누락된 하트비트 수가 구성된 임계값에 도달한 경우, 시스템은 실패 조건의 존재 여부를 평가합니다. 자세한 내용은 다음 항목을 참조하세요.
섀시 클러스터 제어 링크 하트비트, 실패 및 복구 이해
섀시 클러스터 제어 링크 하트비트 이해하기
섀시 클러스터를 구성할 때 하트비트 임계값과 하트비트 간격을 지정합니다.
시스템은 기본적으로 제어 링크의 상태를 모니터링합니다.
SRX5600 및 SRX5800 라인에서 지원되는 이중 제어 링크의 경우, 주니퍼 서비스 중복 프로토콜 프로세스(jsrpd)는 두 제어 링크 모두에서 제어 하트비트 메시지를 송수신합니다. 제어 링크 중 하나에서 하트비트가 수신되는 한, Junos OS는 다른 노드가 활성 상태인 것으로 간주합니다.
옵션과 heartbeat-interval 옵션의 heartbeat-threshold 곱은 장애 조치가 트리거되기 전의 대기 시간을 정의합니다. 이러한 옵션의 기본값은 3초의 대기 시간을 생성합니다. heartbeat-threshold가 5이고 heartbeat-interval이 1000밀리초이면 대기 시간은 5초가 됩니다. heartbeat-threshold를 4로 설정하고 heartbeat-interval을 1250밀리초로 설정하면 대기 시간도 5초가 됩니다.
섀시 클러스터 환경에서 1000개 이상의 논리적 인터페이스를 사용하는 경우 클러스터 하트비트 타이머를 기본값인 3초에서 늘리는 것이 좋습니다. SRX4600, SRX5400, SRX5600 또는 SRX5800 방화벽의 최대 용량에서 페일오버 전에 구성된 시간을 5초 이상으로 늘리는 것이 좋습니다.
섀시 클러스터 제어 링크 장애 및 복구 이해
제어 링크가 실패하면 Junos OS는 보조 노드의 작동 상태를 180초 카운트다운에 부적격으로 변경합니다. 180초 동안 패브릭 링크도 실패하면 Junos OS는 보조 노드를 기본 노드로 변경합니다. 그렇지 않으면 180초 후에 보조 노드 상태가 비활성화됨으로 변경됩니다.
제어 링크가 다운되면 시스템 로그 메시지가 생성됩니다.
제어 링크 장애는 패브릭 링크를 통해 하트비트가 계속 수신되는 동안 제어 링크를 통해 하트비트를 수신하지 않는 것으로 정의됩니다.
적법한 제어 링크 실패의 경우, 중복 그룹 0은 현재 기본 노드인 노드에서 기본 상태로 유지되고, 기본 노드의 비활성 중복 그룹 x 는 활성화되며, 보조 노드는 비활성화 상태로 들어갑니다.
보조 노드가 비활성화된 경우에도 관리 포트에 로그인하여 진단을 실행할 수 있습니다.
시스템은 합법적인 제어 링크 장애가 발생했는지 확인하기 위해 제어 링크와 패브릭 링크 모두를 통해 전송되는 중복 활력 신호에 의존합니다.
시스템은 주기적으로 패브릭 링크를 통해 프로브를 전송하고 제어 링크를 통해 하트비트 신호를 전송합니다. 프로브와 하트비트 신호는 고유한 시간 이벤트에 매핑되는 공통 시퀀스 번호를 공유합니다. Junos OS는 다음 두 가지 조건이 존재하는 경우 합법적인 제어 링크 실패를 식별합니다.
하트비트의 임계값 수가 손실되었습니다.
누락된 하트비트 신호의 시퀀스 번호에 해당하는 하나 이상의 프로브가 패브릭 링크에서 수신되었습니다.
제어 링크가 실패하면 180초 카운트다운이 시작되고 보조 노드 상태는 부적격입니다. 180초 카운트다운이 0에 도달하기 전에 패브릭 링크가 실패하면, 두 링크의 손실이 다른 노드가 죽었음을 나타내기 위해 시스템에 의해 해석되기 때문에 보조 노드가 기본 노드가 됩니다. 제어 링크와 패브릭 링크가 동시에 손실되면 노드가 더 이상 상태를 동기화하거나 우선 순위를 비교하지 않으므로 두 노드 모두 일시적으로 기본 노드가 될 수 있으며 이는 안정적인 운영 상태가 아닙니다. 그러나 제어 링크가 다시 설정되면 우선 순위 값이 더 높은 노드가 자동으로 기본 노드가 되고 다른 노드는 보조 노드가 되며 클러스터는 정상 작동으로 돌아갑니다.
합법적인 제어 링크 장애가 발생하면 다음 조건이 적용됩니다.
중복 그룹 0은 현재 기본인 노드에서 기본으로 유지되고(따라서 라우팅 엔진이 활성 상태로 유지됨), 노드의 모든 중복 그룹 x 가 기본이 됩니다.
시스템이 어떤 라우팅 엔진이 기본인지 결정할 수 없는 경우, 중복 그룹 0에 대한 우선 순위 값이 더 높은 노드가 기본이고 해당 라우팅 엔진이 활성화됩니다. (중복 그룹 0에 대한 명령문을 구성할 때 각 노드의
redundancy-group우선 순위를 구성합니다.)시스템이 보조 노드를 비활성화합니다.
비활성화된 모드에서 장치를 복구하려면 장치를 재부팅해야 합니다. 비활성화된 노드를 재부팅하면 노드의 동적 상태가 기본 노드와 동기화됩니다.
보조 노드가 비활성화되어 있는 동안 구성을 변경하면 노드 재부팅 후 commit 명령을 실행하여 구성을 동기화합니다. 구성을 변경하지 않은 경우 구성 파일은 기본 노드의 구성 파일과 동기화된 상태로 유지됩니다.
중복 그룹 0에 대한 선점을 활성화할 수 없습니다. 중복 그룹 0의 기본 노드를 변경하려면 수동 페일오버를 수행해야 합니다.
이중 제어 링크(SRX5600 및 SRX5800 디바이스에서 지원)를 사용할 때는 다음 조건에 유의하십시오.
호스트 인바운드 또는 아웃바운드 트래픽은 제어 링크 장애 시 최대 3초 동안 영향을 받을 수 있습니다. 예를 들어, 중복 그룹 0이 노드 0에서 기본이고 노드 1의 네트워크 인터페이스 포트를 통해 라우팅 엔진에 대한 텔넷 세션이 있는 경우를 생각해 보십시오. 현재 활성 제어 링크가 실패하면 이 실패가 감지될 때까지 텔넷 세션에서 3초 동안 패킷이 손실됩니다.
커밋 프로세스가 두 노드에서 실행되는 동안 발생하는 제어 링크 실패는 커밋 실패로 이어질 수 있습니다. 이 경우 3초 후에 commit 명령을 다시 실행합니다.
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