섀시 클러스터에서 글로벌 수준 개체 모니터링

기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인할 수 있습니다.

플랫폼별 모니터링 개체 동작(Platform-Specific Monitoring Objects Behavior) 섹션에서 플랫폼과 관련된 참고 사항을 검토하십시오.

글로벌 수준의 개체와 이중화 그룹에 특정한 개체를 포함하여 섀시 클러스터로 구성된 디바이스로 작업할 때 모니터링할 다양한 유형의 개체가 있습니다. 이 섹션에서는 전역 수준 개체의 모니터링에 대해 설명합니다.

SPU 모니터링 이해

SPU 모니터링은 SPU 및 중심점(CP)의 상태를 추적합니다. 각 SPC의 섀시 관리자는 SPU와 중앙 지점을 모니터링하고 섀시된 라우팅 엔진으로 하트비트를 유지합니다. 이 계층적 모니터링 시스템에서 섀시는 하드웨어 장애 감지의 중심입니다. SPU 모니터링은 기본적으로 활성화됩니다.

노드에서 지속적인 SPU 및 중앙 지점 장애는 치명적인 패킷 포워딩 엔진(PFE) 장애로 간주됩니다. 이 경우, 중복 그룹 x 의 우선 순위를 0으로 줄임으로써 노드의 PFE가 클러스터에서 비활성화됩니다.

중앙 지점 오류는 보조 노드에 대한 장애 조치(failover)를 트리거합니다. 모든 SPC와 모든 I/O 카드(IOC)를 포함하는 장애 노드의 PFE가 자동으로 재시작됩니다. 보조 중앙 지점도 실패한 경우 기본 디바이스가 없기 때문에 클러스터를 실행할 수 없습니다. 데이터 플레인(중복 그룹 x)만 장애 조치됩니다.
장애가 발생한 단일 SPU는 중복 그룹 x 를 보조 노드로 페일오버합니다. 장애가 발생한 노드의 모든 IOC 및 SPC가 재시작되고 중복 그룹 x 가 보조 노드로 장애 조치됩니다. 보조 노드로의 장애 조치(failover)는 사용자 개입 없이 자동으로 수행됩니다. 실패한(이전) 기본 노드에 실패한 구성 요소가 복원된 경우, 장애 복구는 중복 그룹 x에 대한 선점 구성에 따라 결정됩니다. 데드 SPU 감지 간격은 30초입니다.

이 이벤트는 새로운 현장 교체 장치(FRU)가 필요함을 나타내는 알람을 트리거합니다.

플로우 모니터링 이해하기

플로우 모니터링은 플로우 프로세스의 상태를 추적합니다. 플로우 모니터링은 기본적으로 활성화됩니다.

노드에서 지속적인 flowd 장애는 치명적인 패킷 포워딩 엔진(PFE) 장애로 간주됩니다. 이 경우, 중복 그룹 x 의 우선 순위를 0으로 줄임으로써 노드의 PFE가 클러스터에서 비활성화됩니다.

flowd 프로세스에 실패하면 중복 그룹 x 가 보조 노드로 페일오버됩니다. 보조 노드로의 장애 조치(failover)는 사용자 개입 없이 자동으로 수행됩니다. 실패한(이전) 기본 노드에 실패한 구성 요소가 복원된 경우, 장애 복구는 중복 그룹 x에 대한 선점 구성에 따라 결정됩니다.

로컬 노드에서 SPC 및 플로우 모니터링이 실패하는 동안 데이터 플레인 이중화 그룹 RG1+는 양호한 상태의 다른 노드로 장애 조치됩니다. 그러나 컨트롤 플레인 RG0은 페일오버되지 않고 장애 전과 동일한 노드에서 기본으로 유지됩니다.

콜드 싱크 모니터링 이해

SPU 또는 flowd 시작 시 데이터 플레인 런타임 객체(RTO)를 동기화하는 프로세스를 콜드 싱크라고 합니다. 모든 RTO가 동기화되면 콜드 싱크 프로세스가 완료되고 필요한 경우 노드의 SPU 또는 플로우가 기본 노드를 대신할 준비가 됩니다. 노드에서 플로우된 모든 SPU의 콜드 싱크 상태를 모니터링하는 프로세스를 콜드 싱크 모니터링이라고 합니다. 선점이 활성화되면 콜드 싱크 모니터링은 SPU에 대한 콜드 싱크 프로세스가 완료되거나 노드에서 플로우될 때까지 노드가 기본 역할을 맡는 것을 방지합니다. 콜드 싱크 모니터링은 기본적으로 활성화되어 있습니다.

노드가 재부팅되거나 SPU 또는 플로우가 실패에서 다시 돌아올 때, 모든 중복 그룹 1+ 의 우선 순위는 0입니다. SPU 또는 flowd가 작동하면 다른 노드에서 미러 SPU 또는 flowd를 사용하여 콜드 싱크 프로세스를 시작하려고 합니다.

클러스터의 유일한 노드인 경우 새 노드가 클러스터에 가입할 때까지 모든 중복 그룹 1+ 의 우선 순위는 0으로 유지됩니다. 우선 순위가 0이더라도 디바이스는 여전히 인터페이스를 통해 트래픽을 송수신할 수 있습니다. 우선 순위 0은 오류 발생 시 장애 조치(failover)할 수 없음을 의미합니다. 새로운 노드가 클러스터에 가입하면 모든 SPU 또는 플로우가 등장할 때 기존 노드의 미러 SPU 또는 플로우와 콜드 싱크 프로세스를 시작합니다.

이미 작동 중인 노드의 SPU 또는 flowd가 SPU 또는 피어 노드의 flowd에서 콜드 싱크 요청을 감지하면 콜드 싱크 프로세스가 완료되었음을 나타내는 메시지를 시스템에 게시합니다. 새로 참가한 노드의 SPU 또는 flowd도 유사한 메시지를 게시합니다. 그러나 모든 RTO가 학습되고 콜드 동기화가 완료된 후에만 이 메시지를 게시합니다. 모든 SPU 또는 플로우에서 완료 메시지를 수신하면, 인터페이스와 같은 모니터링되는 구성 요소에 다른 장애가 없는 경우 중복 그룹 1+ 의 우선 순위는 각 노드에서 구성된 우선 순위로 이동합니다. 이 작업을 수행하면 중복 1+ 그룹에 대한 기존 기본 노드가 항상 구성된 우선 순위로 먼저 이동합니다. 클러스터에 참여하는 노드는 나중에 모든 SPU 또는 flowd가 콜드 싱크 프로세스를 완료한 후에만 구성된 우선 순위로 이동합니다. 이 작업은 새로 추가된 노드가 기본 역할을 인수하기 전에 모든 RTO와 함께 준비되도록 보장합니다.

SPU 교체 또는 확장을 통한 콜드 싱크 모니터링 이해

SRX5600 또는 SRX5800 방화벽이 섀시 클러스터의 일부인 경우 SPC(Services Processing Card)를 디바이스의 SPC2 또는 SPC3으로 교체할 때 모든 중복 그룹을 하나의 노드로 페일오버해야 합니다.

이 시나리오 중에 다음 이벤트가 발생합니다.

SPC2가 노드(예: 보조 노드인 노드 1)에 설치되면 노드 1이 종료되어 SPC2가 설치될 수 있습니다.
노드 1의 전원이 켜지고 클러스터에 다시 합류하면 노드 1의 SPU 수는 기본 노드인 노드 0의 SPU 수보다 많아집니다. 이제 한 노드(노드 0)에는 여전히 이전 SPC가 있고 다른 노드에는 새 SPC2가 있습니다. SPC2는 카드당 4개의 SPU를 갖고 있으며, 구형 SPC는 카드당 2개의 SPU를 가지고 있습니다.

콜드 싱크 프로세스는 노드 0의 총 SPU 수를 기반으로 합니다. 노드 0 SPU에 해당하는 노드 1의 SPU가 콜드 싱크를 완료하면 노드 1은 콜드 싱크 완료를 선언합니다. 노드 1의 추가 SPU에는 해당 노드 0 SPU가 없으므로 동기화할 것이 없으며 노드 0에서 노드 1로의 페일오버는 문제를 일으키지 않습니다.

SPU 모니터링 기능은 모든 SPU를 모니터링하고 SPU 장애가 있으면 보고합니다.

예를 들어, 두 노드에 원래 2개의 기존 SPC가 있고 노드 1에서 두 SPC를 모두 SPC2로 교체했다고 가정합니다. 이제 노드 0에 4개의 SPU와 노드 1에 8개의 SPU가 있습니다. SPU 모니터링 기능은 노드 0에서 4개의 SPU와 노드 1에서 8개의 SPU를 모니터링합니다. 노드 1에서 8개의 SPU 중 하나라도 장애가 발생한 경우, SPU 모니터링은 여전히 JSRPD(Juniper Services Redundancy Protocol) 프로세스에 SPU 장애가 있다고 보고합니다. jsrpd 프로세스는 섀시 클러스터링을 제어합니다.
노드 1이 페일오버 준비가 되면 노드 1에 대한 모든 중복 그룹 페일오버를 수동으로 시작할 수 있습니다. 노드 0은 SPC2로 교체하기 위해 종료됩니다. 교체 후 노드 0과 노드 1은 정확히 동일한 하드웨어 설정을 갖게 됩니다.

노드 0의 전원이 켜지고 클러스터에 다시 가입하면 시스템은 일반 섀시 클러스터로 작동합니다.

섀시 클러스터의 SRX 시리즈 방화벽에서 콜드 싱크 프로세스가 계속 진행 중이고 제어 링크가 다운된 경우 노드가 보조 상태에서 기본 상태로 전환되기까지 30초의 지연이 예상됩니다.

플랫폼별 모니터링 개체 동작

기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인할 수 있습니다.

다음 표를 사용하여 플랫폼의 플랫폼별 동작을 검토합니다.

플랫폼	다름
SRX 시리즈	SPC에서 SPU 모니터링을 지원하는 SRX5000 시리즈 방화벽의 경우, 라우팅 엔진 섀시 관리자의 상태를 모니터링합니다. 섀시 관리자는 매초 섀시된 라우팅 엔진에 하트비트를 보냅니다. 라우팅 엔진은 손실된 하트비트를 감지하면 SPC를 재시작합니다. 여러 번의 복구 실패 후 라우팅 엔진은 전체 시스템을 보호하기 위해 SPC의 전원을 끕니다. SRX5000 시리즈 방화벽에는 SPC 삽입에 대한 다음과 같은 제한 사항이 있습니다. 섀시 클러스터는 SPC 삽입 절차 전과 도중에 액티브/패시브 모드에 있어야 합니다. 두 개의 서로 다른 노드에 다른 수의 SPC를 삽입할 수 없습니다. 새 SPC는 중앙 지점 슬롯보다 높은 슬롯에 삽입해야 합니다. 새 SPC를 삽입한 후에는 기존 콤보 중심점을 전체 중심점으로 변경할 수 없습니다. SPC 삽입 절차 중에는 IKE 및 IPsec 구성을 수정할 수 없습니다. SPC는 핫 삽입이 불가능합니다. SPC를 삽입하기 전에 디바이스를 오프라인으로 전환해야 합니다. SPC를 삽입한 후 디바이스를 재부팅해야 합니다. 터널을 고정하기 위해 SPU 및 IKE 인스턴스를 지정할 수 없습니다. 새로운 SPC가 삽입된 후 기존 터널은 새 SPC의 처리 기능을 사용할 수 없으며 이를 새 SPC로 재분배할 수 없습니다. 하나 이상의 SPU가 있는 SRX5000 시리즈 방화벽은 SPC(Services Processing Card)에서 실행됩니다. 이러한 방화벽은 모든 플로우 기반 서비스에 SPU를 사용합니다. 다른 SRX 시리즈 방화벽은 플로우 기반 포워딩 프로세스인 플로우에 의존하여 패킷을 포워딩합니다.

플랫폼

다름

SRX 시리즈

SPC에서 SPU 모니터링을 지원하는 SRX5000 시리즈 방화벽의 경우, 라우팅 엔진 섀시 관리자의 상태를 모니터링합니다. 섀시 관리자는 매초 섀시된 라우팅 엔진에 하트비트를 보냅니다. 라우팅 엔진은 손실된 하트비트를 감지하면 SPC를 재시작합니다. 여러 번의 복구 실패 후 라우팅 엔진은 전체 시스템을 보호하기 위해 SPC의 전원을 끕니다.
SRX5000 시리즈 방화벽에는 SPC 삽입에 대한 다음과 같은 제한 사항이 있습니다.
- 섀시 클러스터는 SPC 삽입 절차 전과 도중에 액티브/패시브 모드에 있어야 합니다.
- 두 개의 서로 다른 노드에 다른 수의 SPC를 삽입할 수 없습니다.
- 새 SPC는 중앙 지점 슬롯보다 높은 슬롯에 삽입해야 합니다.
  
  새 SPC를 삽입한 후에는 기존 콤보 중심점을 전체 중심점으로 변경할 수 없습니다.
- SPC 삽입 절차 중에는 IKE 및 IPsec 구성을 수정할 수 없습니다.
  
  SPC는 핫 삽입이 불가능합니다. SPC를 삽입하기 전에 디바이스를 오프라인으로 전환해야 합니다. SPC를 삽입한 후 디바이스를 재부팅해야 합니다.
- 터널을 고정하기 위해 SPU 및 IKE 인스턴스를 지정할 수 없습니다.
- 새로운 SPC가 삽입된 후 기존 터널은 새 SPC의 처리 기능을 사용할 수 없으며 이를 새 SPC로 재분배할 수 없습니다.
하나 이상의 SPU가 있는 SRX5000 시리즈 방화벽은 SPC(Services Processing Card)에서 실행됩니다. 이러한 방화벽은 모든 플로우 기반 서비스에 SPU를 사용합니다. 다른 SRX 시리즈 방화벽은 플로우 기반 포워딩 프로세스인 플로우에 의존하여 패킷을 포워딩합니다.

이 페이지 내용