Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

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

SRX5000 라인에는 SPC(Services Processing Card)에서 실행되는 하나 이상의 SPU(Services Processing Units)가 있습니다. 모든 플로우 기반 서비스는 SPU에서 실행됩니다. 다른 SRX 시리즈 방화벽에는 디바이스를 통해 패킷을 전달하는 flowd 기반 전달 프로세스가 있습니다.

SPU 모니터링 이해하기

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

SPU 모니터링은 SRX4600 및 SRX5000 라인 디바이스에서 지원됩니다.

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

  • 중앙점 장애는 보조 노드로의 페일오버를 트리거합니다. 모든 SPC와 모든 I/O 카드(IOC)를 포함하는 장애가 발생한 노드의 PFE가 자동으로 재시작됩니다. 보조 중앙 지점도 실패한 경우 기본 디바이스가 없기 때문에 클러스터가 작동할 수 없습니다. 데이터 플레인(중복 그룹 x)만 페일오버됩니다.

  • 장애가 발생한 단일 SPU로 인해 중복 그룹 x 가 보조 노드로 페일오버됩니다. 장애가 발생한 노드의 모든 IOC 및 SPC가 다시 시작되고 이중화 그룹 x 가 보조 노드로 장애 조치됩니다. 보조 노드에 대한 페일오버는 사용자 개입 없이 자동으로 수행됩니다. 장애가 발생한(이전) 기본 노드에 장애가 발생한 구성 요소가 복원되면 중복 그룹 x에 대한 선점 구성에 의해 장애 복구가 결정됩니다. 데드 SPU 탐지 간격은 30초입니다.

SRX5400, SRX5600 및 SRX5800 SPC에서 라우팅 엔진은 섀시 관리자의 상태를 모니터링합니다. 섀시 관리자는 매초 섀시 라우팅 엔진에 하트비트 메시지를 보냅니다. 라우팅 엔진 섀시가 하트비트 손실을 감지하면 전체 SPC에 대한 전원 사이클을 시작합니다. 특정 기간 내에 여러 복구가 실패하면 라우팅 엔진은 SPC의 전원을 꺼서 전체 시스템에 영향을 미치지 않도록 합니다.

이 이벤트는 새 FRU(현장 교체 장치)가 필요함을 나타내는 경보를 트리거합니다.

다음 목록에는 섀시 클러스터 모드에서 SRX5400, SRX5600 및 SRX5800 디바이스에 SPC를 삽입하기 위한 제한 사항이 설명되어 있습니다.

  • 섀시 클러스터는 SPC 삽입 절차 전과 도중에 액티브/패시브 모드에 있어야 합니다.

  • 서로 다른 수의 SPC를 두 개의 서로 다른 노드에 삽입할 수 없습니다.

  • 중앙 지점 슬롯보다 높은 슬롯에 새 SPC를 삽입해야 합니다.

    새 SPC를 삽입한 후에는 기존 콤보 중심점을 전체 중심점으로 변경할 수 없습니다.

  • SPC 삽입 절차 중에는 IKE 및 IPsec 구성을 수정할 수 없습니다.

    SPC는 핫 삽입이 불가능합니다. SPC를 삽입하기 전에 장치를 오프라인으로 전환해야 합니다. SPC를 삽입한 후 디바이스를 재부팅해야 합니다.

  • 사용자는 터널을 고정하기 위해 SPU와 IKE(Internet Key Exchange) 인스턴스를 지정할 수 없습니다.

  • 새 SPC가 삽입된 후 기존 터널은 새 SPC의 처리 기능을 사용할 수 없으며 새 SPC에 재배포할 수 없습니다.

플로우 모니터링 이해

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

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

실패한 플로우 프로세스로 인해 중복 그룹 x 가 보조 노드로 페일오버됩니다. 보조 노드에 대한 페일오버는 사용자 개입 없이 자동으로 수행됩니다. 장애가 발생한(이전) 기본 노드에 장애가 발생한 구성 요소가 복원되면 중복 그룹 x에 대한 선점 구성에 의해 장애 복구가 결정됩니다.

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

콜드 싱크 모니터링 이해

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

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

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

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

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

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

SRX5400 디바이스의 경우 SPC2 및 SPC3이 지원됩니다.

이 시나리오에서는 다음과 같은 이벤트가 발생합니다.

  • SPC2가 노드(예: 노드 1, 보조 노드)에 설치되면 SPC2를 설치할 수 있도록 노드 1이 종료됩니다.

  • 노드 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) 프로세스에 SPU 장애가 있다고 보고합니다. jsrpd 프로세스는 섀시 클러스터링을 제어합니다.

  • 노드 1이 페일오버할 준비가 되면 노드 1에 대한 모든 중복 그룹 페일오버를 수동으로 시작할 수 있습니다. 노드 0은 SPC를 SPC2로 교체하기 위해 종료됩니다. 교체 후 노드 0과 노드 1은 정확히 동일한 하드웨어 설정을 갖게 됩니다.

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

Junos OS 릴리스 15.1X49-D120부터 섀시 클러스터의 SRX 시리즈 방화벽에서 콜드 싱크 프로세스가 여전히 진행 중이고 제어 링크가 다운되면 노드가 보조 상태에서 기본 상태로 전환되기 전에 지연(30초)이 예상됩니다.