Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

섀시 클러스터 중복 그룹 장애 조치

RG(Redundancy Group)는 클러스터의 두 노드에 있는 객체 모음을 포함 및 관리하여 고가용성을 제공합니다. 각 중복 그룹은 독립적인 장애 조치 단위의 역할을 하며 한 때 하나의 노드에만 해당됩니다. 자세한 내용은 다음 항목을 참조하십시오.

Understanding Chassis Cluster Redundancy Group Failover

섀시 클러스터 는 시스템의 전반적인 안정성 및 생산성을 높이기 위해 고가용성을 촉진하는 많은 고효율 장애 조치 메커니즘을 채용하고 있습니다.

중복 그룹은 그룹으로 장애가 발생하는 객체의 모음입니다. 각 리던던시 그룹이 객체 세트(물리적 인터페이스)를 모니터링하고 모니터링하는 각 객체에는 가중치가 할당됩니다. 각 중복 그룹에는 초기 임계값이 있습니다 255. 모니터링된 객체에 장애가 발생하면 객체의 가중치가 중복 그룹의 임계값 값에서 빼습니다. 임계값이 0에 도달하면 중복 그룹은 다른 노드로 장애가 발생합니다. 그 결과, 중복 그룹과 연관된 모든 객체는 장애가 발생했습니다. 라우팅 프로토콜의 Graceful Restart를 통해 SRX 시리즈 디바이스는 장애 조치가 진행되는 동안 트래픽 중단을 최소화할 수 있습니다.

짧은 간격으로 중복 그룹의 백-백(back-to-back) 장애가 발생하면 클러스터가 예측할 수 없는 동작을 유발할 수 있습니다. 예측할 수 없는 동작을 방지하기 위해 장애 조치 간의 차단 시간을 구성합니다. 장애 조치 시, 중복 그룹의 이전 기본 노드는 보조 홀드(secondary-hold) 상태로 이동하고 홀드 다운 간격이 만료될 때까지 보조 홀드(secondary-hold) 상태로 머무를 수 있습니다. 홀드 다운 간격이 만료되면 이전 기본 노드가 보조 상태로 이동됩니다.

홀드 다운 간격을 구성하면 후-후 장애가 홀드 다운 간격 동안 발생하는 것을 방지합니다.

홀드 다운 간격은 수동 장애 복구뿐만 아니라 장애 모니터링과 관련된 자동 장애 복구에 영향을 미치게 됩니다.

중복 그룹에 대한 기본 감쇠 시간은 300초(5분)로 명령문을 통해 최대 1800초 hold-down-interval 까지 구성할 수 있습니다. 많은 수의 라우트 또는 논리적 인터페이스를 사용하는 구성의 경우, 기본 간격 또는 사용자 구성 간격으로는 충분하지 않을 수 있습니다. 이러한 경우 시스템은 장애 조치가 실행될 때까지 60초에 달하는 자동 감퇴 시간을 연장합니다.

중복 그룹 x (1부터 128까지의 중복 그룹)은 기본 감쇠 시간을 1초로 설정하고, 거리는 0~1800초입니다.

SRX 시리즈 디바이스에서 섀시 클러스터 장애 조치 성능은 보다 논리적인 인터페이스로 확장할 수 있도록 최적화되었습니다. 이전에는 중복 그룹 장애가 발생하면 GARP(gratuitous arp)가 각 논리적 인터페이스에서 실행되는 Juniper Services Redundancy Protocol(jsrpd 라우팅 엔진) 프로세스가 전송되어 트래픽을 해당 노드로 스티 어링합니다. 논리적 인터페이스 확장을 통해 라우팅 엔진 체크포인트가 지고 GARP는 SPU(Services Processing Unit)에서 직접 전송됩니다.

Preemptive Failover Delay Timer

중복 그룹은 한 노드의 기본 상태(활성)에 있으며 주어진 시간 내 다른 노드의 보조 상태(백업)에 있습니다.

중복 그룹의 두 노드에서 예비 동작을 활성화하고 중복 그룹 내 각 노드에 우선 순위 값을 지정할 수 있습니다. 우선 순위가 높은 중복 그룹의 노드는 먼저 그룹의 주 노드로 지정됩니다. 다른 노드는 처음에는 중복 그룹의 보조 노드로 지정됩니다.

중복 그룹이 노드의 상태를 기본 및 보조 노드로 교체하면 노드의 후속 상태 스왑이 첫 번째 상태 스왑 후에 다시 발생하게 될 가능성이 있습니다. 이와 같은 상태의 급격한 변화로 기본 및 보조 시스템이 플래핑(flapping)됩니다.

Junos OS Release 17.4R1 시작으로, 섀시 클러스터의 SRX 시리즈 디바이스에 장애 조치 지연 시간이 발생하여 예비 장애 발생 시 보조 노드와 주 노드 간의 중복 그룹 상태 플래핑을 제한합니다.

플래핑을 방지하기 위해 다음과 같은 매개 변수를 구성할 수 있습니다.

  • 예비 지연 – 예비 지연 시간은 보조 상태의 중복 그룹이 기본 상태로 전환하기 전에 예비 장애가 발생하여 기본 상태가 다운될 때 대기하는 시간입니다. 이 지연 시간(delay timer)은 구성된 기간(1~21,600초)의 즉각적인 장애개시를 지연시킵니다.

  • 예비 제한– 사전 제한은 구성된 예비 기간 동안(1~50 사이의) preemption 의 수를 제한합니다(중복 그룹에 대해 활성화된 경우).

  • 예비 제한이 적용되는 기간(1~1440초) 즉, 중복 그룹에 대해 사전 설정이 실행될 때 구성된 예비 장애 조치의 수가 적용됩니다.

300초 동안 예비 기간을 50초로 구성한 다음 시나리오를 생각해 보겠습니다.

preemptive limit이 50으로 구성된 경우, 카운트는 0에서 시작하여 첫 번째 예비 장애 조치(preemptive failover)와 함께 증가합니다. 이 프로세스는 수가 구성된 예비 제한(50개)에 도달할 때까지 계속됩니다. 즉, 예비 기간이 만료되기 전입니다. Preemptive Limit (50)을 초과하는 경우, 예비 장애 복구가 다시 발생하도록 사전 카운트를 수동으로 재설정해야 합니다.

예비 기간을 300초로 구성하고, 첫 번째 예비 장애 복구와 현재 장애 복구 간의 시간 차이가 이미 300초를 초과하고 50초(prempmptive limit)에 도달하지 않은 경우, 예비 기간이 재설정됩니다. 리셋 후 마지막 장애 복구는 새로운 예비 기간의 첫 번째 예비 장애 복구로 간주하며 프로세스가 다시 시작됩니다.

예비 지연은 장애 조치 제한에 독립적으로 구성할 수 있습니다. Preemptive Delay Timer를 구성하는 것은 기존의 예비 동작을 변경하지 않습니다.

이와 같은 향상을 통해 관리자는 장애 조치 지연을 도입할 수 있으며, 이는 장애 조치의 수를 줄이고, 중복 그룹 내에서 활성/대기 플래핑(flapping)을 줄이기 때문에 보다 안정적인 네트워크 상태를 구축할 수 있습니다.

기본 상태에서 보조 상태로의 전환에 대한 이해 및 예비 지연

노드 0의 일차인 중복 그룹이 장애 조치가 실시되는 동안 보조 상태로의 예비 전환을 준비할 수 있는 다음 예가 있습니다. 우선 순위는 각 노드에 할당됩니다 preemptive . 노드에 대한 옵션도 활성화됩니다.

그림 1 은 예비 지연 시간(preemptive delay timer)이 구성될 때 기본 상태에서 보조 상태로 전환하는 단계의 시퀀스를 설명하고 있습니다.

그림 1: 기본 상태에서 예비 상태(Preemptive Delay Transition from Primary State to Secondary State with Preemptive Delay)를 통해 보조 상태로 전환
  1. preemptive 옵션이 구성되면 기본 상태의 노드가 보조 상태로 사전 전환할 준비가 되어 있으며 보조 상태의 노드가 기본 상태의 노드보다 우선 순위가 높은 경우 예비 지연이 구성된 경우 기본 상태의 노드가 기본 사전 보존 상태로 전환됩니다. 예비 지연이 구성되지 않은 경우 보조 상태로 즉각적인 전환이 발생합니다.

  2. 노드는 기본 사전 보존 상태로 상태는 예비 지연 시간 시간(preempmptive delay timer)이 만료될 때까지 대기합니다. preemptive delay timer를 검사하고 타임러가 만료될 때까지 전환이 보존됩니다. 기본 노드는 시간 시간이 만료될 때까지 기본 사전 보존 상태로 유지된 후 보조 상태로 전환합니다.

  3. 노드는 기본 사전 상태(primary-preempt-hold) 상태에서 보조 홀드(secondary-hold) 상태로 전환된 다음 보조 상태로 전환됩니다.

  4. 노드는 기본 시간(1초) 또는 구성된 시간(최소 300초)에 대해 보조 홀드 상태로 유지된 다음, 노드가 보조 상태로 전환됩니다.

섀시 클러스터 설정에 비정상적인 플랩이 있는 경우 링크와 모니터링 타임을 검사하여 올바르게 설정되어 있는지 확인해야 합니다. 높은 지연 시간의 네트워크에서 시간을 설정하여 오율을 방지할 때 신중을 기하십시오.

Preemptive Delay Timer 구성

이 주제는 섀시 클러스터에서 SRX 시리즈 디바이스에서 지연 시간을 구성하는 방법에 대해 설명하고 있습니다. 백-후 중복 그룹 장애 조치가 너무 빠르게 발생하면 섀시 클러스터가 예측할 수 없는 동작을 유발할 수 있습니다. 지연 시간(delay timer) 및 장애오버 속도 제한(failover rate limit)을 구성하면 구성된 기간 동안 즉각적인 장애오버가 지연됩니다.

예비 지연 시간(preemptive delay timer) 및 중복 그룹 장애 조치 간의 장애 조치 제한(failover rate limit)을 구성하기 위해 다음을 제공합니다.

  1. 중복 그룹에 대해 사전 장애 조치(failover)를 활성화합니다.

    1-21,600초 간의 지연 시간(delay timer)을 설정할 수 있습니다. 기본값은 1초입니다.

  2. 예비 장애 조치에 대한 한도 설정

    1~50초 사이의 최대 예비 장애 발생 횟수와 1~1440초 간의 제한 적용 기간을 설정할 수 있습니다.

다음 예제에서는 예비 지연 시간(preemptive delay timer)을 300초로, 예비(prempmptive) 기간을 600초 동안 10으로 설정하는 것입니다. 즉, 이 구성은 즉각적인 장애 조치가 300초 동안 지연되고 600초 동안 최대 10회의 예비 장애 발생이 제한됩니다.

이 명령을 clear chassis clusters preempt-count 사용하여 모든 중복 그룹에 대해 사전 대응되는 장애 조치(failover counter)를 지우는 방법을 사용할 수 있습니다. 사전 제한이 구성된 경우 카운터는 첫 번째 예비 장애 조치(preempmptive failover)에서 시작하고 수가 감소합니다. 이 프로세스는 타임러가 만료되기 전에 카운트가 0에 도달할 때까지 계속됩니다. 이 명령을 사용하여 사전 준비된 장애 복구 카운터를 지우고 다시 재설정하여 다시 시작할 수 있습니다.

Understanding Chassis Cluster Redundancy Group Manual Failover

수동으로 중복 그룹 x (1에서 128로 번호가 매기는 중복 그룹)를 시작할 수 있습니다. 수동 장애 조치는 장애 복귀 이벤트가 발생할 때까지 적용됩니다.

예를 들어, 노드 0에서 노드 1로의 중복 그룹 1 장애 조치가 수동으로 수행된다고 가정해 보겠습니다. 그런 다음, 중복 그룹 1이 실패를 모니터링하는 인터페이스가 실패하여 새로운 기본 중복 그룹의 임계값 값을 0으로 삭제합니다. 이 이벤트는 장애 조치(failback) 이벤트로 간주될 수 있으며 시스템은 제어를 원래의 중복 그룹으로 반환합니다.

또한 중복 그룹 0을 위해 기본 노드를 변경하려는 경우 중복 그룹 0 장애 조치도 수동으로 시작할 수 있습니다. 중복 그룹 0에 대한 사전 설정을 활성화할 수 없습니다.

중복 그룹 구성에 사전 준비를 추가하면 그룹 우선 순위가 높은 디바이스가 주된 것으로 장애 오버를 시작할 수 있습니다. 기본적으로 사전 준비는 비활성화됩니다. 사전 설정에 대한 자세한 내용은 사전(섀시 클러스터) 를 참조하십시오.

중복 그룹 0에 대한 수동 장애 조치가 있는 경우 기본 상태의 노드가 보조 홀드(secondary-hold) 상태로 전환됩니다. 노드는 기본 또는 구성된 시간(최소 300초)에 대해 보조 홀드 상태로 유지된 다음 보조 상태로 전환됩니다.

한 노드가 보조 홀드(secondary-hold) 상태인 경우, 다른 노드가 재부팅되거나 제어 링크 연결 또는 패브릭 링크 연결이 해당 노드로 손실된 경우의 상태 전환이 다음과 같이 설명됩니다.

  • 케이스 재부팅—보조 홀드 상태의 노드가 기본 상태로 전환됩니다. 다른 노드는 정해진(비활성화)됩니다.

  • 제어 링크 장애 사례—보조 홀드(secondary-hold) 상태의 노드는 비호환 상태로 전환된 다음 비활성화된 상태로 전환됩니다. 다른 노드가 기본 상태로 전환됩니다.

  • 패브릭 링크 장애 사례—보조 홀드(secondary-hold) 상태의 노드는 비호환 상태로 직접 전환됩니다.

    릴리스 Junos OS 릴리스 12.1X46-D20 Junos OS 릴리스 17.3R1 패브릭 모니터링이 기본적으로 활성화됩니다. 이를 통해 노드는 패브릭 링크 장애 발생 시 비호환 상태로 직접 전환됩니다.

    릴리스 Junos OS 릴리스 12.1X47-D10 Junos OS 릴리스 17.3R1 패브릭 모니터링이 기본적으로 활성화됩니다. 이를 통해 노드는 패브릭 링크 장애 발생 시 비호환 상태로 직접 전환됩니다.

ISSU(In-Service Software Upgrade)에는 여기에서 설명된 전환이 일어날 수 없다는 사실에 유의하십시오. 10.주니퍼 네트웍스 릴리스가 보조 홀드(secondary-hold) 상태를 해석하지 못하기 때문에 다른(기본) 노드가 보조 상태로 직접 전환됩니다. ISSU를 시작하는 동안, 노드 중 하나에 대기 상태의 중복 그룹이 하나 이상 있는 경우, 수동 장애 조치(failovers)를 통해 모든 중복 그룹이 하나의 노드에서 기본 노드가 되기 전에 해당 노드가 보조 상태로 이동할 때까지 기다려야 합니다.

중복 그룹 0 수동 장애 조치의 사용에 신중하고 신중을 기하십시오. 리던던시 그룹 0 장애 조치는 라우팅 엔진 스페일오버를 의미하며, 이 경우 기본 노드에서 실행되는 모든 프로세스가 사살되고 새로운 기본 라우팅 엔진. 이러한 장애 조치는 라우팅 상태와 같은 상태가 손실되고 시스템 이윤이 발생하여 성능이 저하될 수 있습니다.

일부 Junos OS x릴리스에서는 중복 그룹의 경우 우선 순위 0이 있는 노드에서 수동 장애 해제를 할 수 있습니다. 이 명령을 show chassis cluster status 사용하여 수동 장애가 발생하기 전에 중복 그룹 노드 우선 순위를 검사하는 것이 좋습니다. 그러나 Junos OS 릴리스에서 12.1X44-D25, 12.1X45-D20, 12.1X46-D10 및 12.1X47-D10 이후에는 수동 장애 조치에 대한 준비 준비 확인 메커니즘이 보다 제한적으로 향상되어 0 우선 순위가 있는 중복 그룹의 노드로 수동 장애오버를 설정할 수 없습니다. 이 개선 사항으로 인해 0 우선 순위 노드로 장애가 발생하여 트래픽이 예기치 않게 드롭되는 것을 방지할 수 있습니다. 이로 인해 트래픽을 수용할 수 없습니다.

섀시 클러스터 수동 중복 그룹 장애 조치 실행

이 명령으로 수동으로 장애 조치(failover)를 시작할 수 request 있습니다. 수동 장애 조치는 255개 멤버에 대한 중복 그룹의 우선 순위를 한 발 더 가중합니다.

중복 그룹 0 수동 장애 조치의 사용에 신중하고 신중을 기하십시오. 리던던시 그룹 0 장애 조치는 라우팅 엔진(re) 장애 조치(failover)를 의미하며, 이 경우 기본 노드에서 실행되는 모든 프로세스가 사살되고 새로운 기본 라우팅 엔진(RE)에 스패닝됩니다. 이러한 장애 조치는 라우팅 상태와 같은 상태가 손실되고 시스템 이윤이 발생하여 성능이 저하될 수 있습니다.

전원 코드를 분분하고 전원 버튼을 누르고 섀시 클러스터 중복 그룹 장애 조치가 실행될 경우 동작이 예측 불가능하게 될 수 있습니다.

중복 그룹 x (1부터 128까지의 중복 그룹)의 경우 우선 순위가 0인 노드에서 수동 장애 조치가 가능합니다. 수동 장애 발생 전에 중복 그룹 노드 우선 순위를 검사하는 것이 좋습니다.

이 명령을 show 사용하여 클러스터의 노드 상태를 표시합니다.

이 명령의 출력은 노드 0이 기본 노드를 나타냅니다.

이 명령을 request 사용하여 장애 조치 실행 및 Node 1 기본:

이 명령을 show 사용하여 클러스터에 있는 노드의 새로운 상태를 표시합니다.

이 명령에 대한 출력은 노드 1이 이제 기본 상태고 노드 0이 보조 홀드(secondary-hold) 상태인 것으로 표시됩니다. 5분 후 노드 0이 보조 상태로 전환됩니다.

이 명령을 사용하여 중복 그룹에 대한 장애 복구를 재설정할 수 request 있습니다. 이러한 변화는 클러스터 전반으로 전파됩니다.

5분 간격이 만료될 때까지 백-백(back-to-back) 장애 발생을 트리거할 수 없습니다.

이 명령을 show 사용하여 클러스터에 있는 노드의 새로운 상태를 표시합니다.

이 명령에 대한 출력은 백-백(back-to-back) 장애가 두 노드에 대해 발생하지 않았다는 표시를 보여줍니다.

수동 장애 조치(failover)를 수행한 후, 또 reset failover 다른 장애 조치(failover)를 요청하기 전에 명령을 실행해야 합니다.

기본 노드에 장애가 발생하고 백업하면 기본 노드의 선임은 정규 기준(우선 순위 및 사전 준비)을 기준으로 수행됩니다.

예: 백-백(back-to-back) 중복 그룹 장애 발생을 막는 시간으로 섀시 클러스터 구성

이 예에서는 섀시 클러스터에 대한 백-후 중복 그룹 장애 조치 간의 감쇠 시간을 구성하는 방법을 보여줍니다. 백-후 중복 그룹 장애 조치가 너무 빠르게 발생하면 섀시 클러스터가 예측할 수 없는 동작을 유발할 수 있습니다.

요구 사항

시작하기 전에 다음을 할 수 있습니다.

개요

감쇠 시간은 중복 그룹에 대해 백-백(back-to-back) 장애 발생 간에 허용되는 최소 간격입니다. 이 간격은 인터페이스 모니터링 장애로 인한 수동 장애 복구 및 자동 장애 복구에 영향을 미치게 됩니다.

이 예에서는 백-백(back-to-back) 장애오버 간 허용되는 최소 간격을 420초로 설정하여 중복 그룹 0을 설정할 수 있습니다.

구성

절차

단계별 절차

백-후-백 중복 그룹 장애 조치 간의 감쇠 시간을 구성하기 위해 다음을 제공합니다.

  1. 중복 그룹에 대한 대담한 시간을 설정합니다.

  2. 디바이스 구성이 완료되면 구성을 커밋합니다.

섀시 클러스터 중복 그룹을 위한 SNMP 장애 조치 이해 그룹 장애 조치

섀시 클러스터링은 중복 그룹 장애가 발생하면 트리거되는 SNMP 트랩을 지원합니다.

트랩 메시지는 장애 조치의 문제를 해결하는 데 도움이 될 수 있습니다. 본 문서에는 다음 정보가 포함되어 있습니다.

  • 클러스터 ID 및 노드 ID

  • 장애가 발생해야 하는 이유

  • 장애 조치에 포함된 중복 그룹

  • 중복 그룹의 이전 상태 및 현재 상태

클러스터가 모든 즉각적으로 실행될 수 있는 상태(보유, 일차, 보조 보류, 보조, 자격 미지정, 비활성화)입니다. 다음과 같은 상태 전환을 위해 트랩이 생성됩니다(보유 상태의 전환만 트랩을 트리거하지는 않습니다).

  • 기본 <–> 보조

  • 기본 –> 보조 홀드

  • 보조 홀드 –> 보조

  • 보조 –> 자격이 없습니다.

  • 자격이 없는 –> 지원되지 않습니다.

  • 자격이 없는 –> 기본

  • 보조 –> 비활성화

인터페이스 모니터링, SPU 모니터링, 장애 및 수동 장애와 같은 이벤트로 인한 전환이 트리거될 수 있습니다.

진행 인터페이스가 트랩을 생성하는 노드의 노드와 다른 노드에 있는 경우 라우팅 엔진 링크 상에서 트랩이 포워드됩니다.

명령문을 설정하여 추적 로그를 생성할 수 traceoptions flag snmp 있습니다.

섀시 클러스터 장애 조치 확인

목적

섀시 클러스터의 장애 조치(failover) 상태를 표시합니다.

작업

이 CLI 명령어를 입력 show chassis cluster status 합니다.

섀시 클러스터 장애 조치 지우기

섀시 클러스터의 장애 조치(failover) 상태를 지우기 위해 다음 clear chassis cluster failover-count 명령어에서 명령을 CLI.

릴리스 내역 표
릴리스
설명
17.4R1
Junos OS Release 17.4R1 시작으로, 섀시 클러스터의 SRX 시리즈 디바이스에 장애 조치 지연 시간이 발생하여 예비 장애 발생 시 보조 노드와 주 노드 간의 중복 그룹 상태 플래핑을 제한합니다.
12.1X47-D10
릴리스 Junos OS 릴리스 12.1X47-D10 Junos OS 릴리스 17.3R1 패브릭 모니터링이 기본적으로 활성화됩니다. 이를 통해 노드는 패브릭 링크 장애 발생 시 비호환 상태로 직접 전환됩니다.
12.1X46-D20
릴리스 Junos OS 릴리스 12.1X46-D20 Junos OS 릴리스 17.3R1 패브릭 모니터링이 기본적으로 활성화됩니다. 이를 통해 노드는 패브릭 링크 장애 발생 시 비호환 상태로 직접 전환됩니다.