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)에서 실행되는 하나 이상의 SPUS(Services Processing Units)가 있습니다. 모든 플로우 기반 서비스는 SPU에서 실행됩니다. 다른 SRX 시리즈 디바이스는 플로우 기반 포우링 프로세스가 있습니다. 플로우는 디바이스를 통해 패킷을 전송합니다.

SPU 모니터링 이해

SPU 모니터링은 SPUS와 중앙 지점(CP)의 상태 추적 각 SPC의 섀시 매니저는 SPUS와 중앙 지점을 모니터링하고 매니지드 섀시를 통해 하트비트도 라우팅 엔진 있습니다. 이 계층 모니터링 시스템에서는 섀시가 하드웨어 장애 감지의 중심이 됩니다. SPU 모니터링은 기본적으로 활성화됩니다.

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

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

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

  • 단일 장애가 발생하면 중복 그룹 x 보조 노드로의 장애가 발생합니다. 실패한 노드의 모든 I IC 및 SPC가 재시작하고 보조 노드로 리던던시 그룹 x가 실패했습니다. 보조 노드로의 장애오버는 사용자의 개입 없이도 자동으로 실행됩니다. 장애가 발생(이전) 기본 노드에 장애가 발생하면 장애가 복구된 경우, 장애 복구는 중복 그룹 x에 대한 사전 구성에 따라 결정됩니다. SPU 탐지에 대한 간격은 30초입니다.

SPC SRX5400, SRX5600 SRX5800 섀시 매니저의 라우팅 엔진 모니터링합니다. 섀시 매니저는 매초마다 하트비트 메시지를 라우팅 엔진 섀시에 전송합니다. 섀시 라우팅 엔진 하트비트 손실을 감지하면 전체 SPC에 대한 전원 주기가 시작됩니다. 특정 기간 내에 여러 복구에 장애가 발생하면 해당 라우팅 엔진 SPC가 전원을 끄어 전체 시스템에 영향을 주지 않습니다.

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

다음 목록은 섀시 클러스터 모드에서 SPC를 SRX5400, SRX5600 및 SRX5800 디바이스에 삽입할 수 있는 한계에 대해 설명하고 있습니다.

  • 섀시 클러스터는 SPC 삽입 절차 이전과 진행 중 활성화/패시브 모드에 있어야 합니다.

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

  • 중앙 포인트 슬롯보다 높은 슬롯에 새로운 SPC를 삽입해야 합니다.

    새 SPC가 삽입된 이후에는 기존 콤보 중앙 지점을 전체 중앙 지점으로 변경할 수 없습니다.

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

    SPC는 핫 삽입할 수 없습니다. SPC를 삽입하기 전에 디바이스를 오프라인으로 전환해야 합니다. SPC를 삽입한 후 디바이스를 재부팅해야 합니다.

  • 사용자는 터널에 고정하기 위해 SPU 및 IKE(Internet Key Exchange) 지정할 수 없습니다.

  • 새 SPC가 삽입된 후 기존 터널은 새 SPC의 프로세싱 기능을 사용하여 새 SPC에 재분산할 수 없습니다.

플로우 모니터링 이해

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

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

플로우 프로세스에 장애가 발생하면 중복 그룹 x 보조 노드로 장애가 발생합니다. 보조 노드로의 장애오버는 사용자의 개입 없이도 자동으로 실행됩니다. 장애가 발생(이전) 기본 노드에 장애가 발생하면 장애가 복구된 경우, 장애 복구는 중복 그룹 x에 대한 사전 구성에 따라 결정됩니다.

SPC와 로컬 노드의 플로우 모니터링 장애가 발생하면 데이터 플레인 중복 그룹 RG1+가 양호한 상태의 다른 노드로 장애가 발생합니다. 그러나 컨트롤 플레인 RG0은 장애가 발생하기 전과 동일한 노드에서 기본 상태로 남아 있습니다.

냉 동기화 모니터링 이해

SPUS 시작 또는 플로우의 데이터 플레인 런타임 객체(RTOS)를 동기화하는 프로세스는 콜드 동기화(cold sync)라고 불리며, 모든 RTOS가 동기화되면 콜드 싱크 프로세스가 완료된 후, 노드상에서 SPU 또는 플로우가 필요한 경우 기본 노드에 대한 인계를 완료할 수 있습니다. 모든 SPUS의 콜드 동기화 상태를 모니터링하거나 노드에서 플로우하는 프로세스를 콜드 동기화 모니터링이라고 합니다. 사전 예방적이면, 콜드 싱크(cold-sync) 모니터링을 통해 SP에 대한 콜드 동기화 프로세스가 완료되거나 노드상에서 플로우될 때까지 노드가 기본 역할을 넘나 들 수 없습니다. 기본적으로 콜드 싱크 모니터링이 활성화됩니다.

노드가 재부팅되거나 SPUS 또는 플로우가 장애로부터 백업될 때 모든 중복 그룹에 대한 우선 순위 1+는 0입니다. SPU 또는 플로우가 나타면 미러 SPU로 콜드 동기화 프로세스를 시작하거나 다른 노드에서 플로우를 처리합니다.

클러스터에서 유일한 노드인 경우 새 노드가 클러스터에 연결될 때까지 모든 중복 그룹의 우선 순위가 1+에 머무를 수 있습니다. 우선 순위가 0이면 디바이스는 여전히 인터페이스를 통해 트래픽을 수신하고 전송할 수 있습니다. 우선 순위 0은 장애 발생 시 장애가 발생하면 장애가 없다는 의미입니다. 새 노드가 클러스터에 연결하면 모든 SPUS 또는 플로우가 시작될 때 미러 SPUS 또는 기존 노드의 플로우와 함께 콜드 동기화 프로세스를 시작할 수 있습니다.

이미 업 업된 노드의 SPU 또는 플로우가 SPU의 콜드 싱크 요청을 감지하거나 피어 노드의 플로우를 감지하면 시스템에 메시지를 게시하여 콜드 동기화 프로세스가 완료되었음을 나타냈다. SP 또는 새로 조인된 노드의 플로우가 유사한 메시지를 게시합니다. 그러나 이 메시지는 모든RT를 학습하고 콜드 동기화가 완료된 후에만 게시합니다. 모든 SP 또는 플로우로부터 완료 메시지를 수신할 때 인터페이스와 같이 모니터링되는 구성 요소에 대한 다른 장애가 없는 경우 중복 그룹의 우선 순위 1+가 각 노드에서 구성된 우선 순위로 이동됩니다. 이러한 조치는 1+ 그룹이 중복을 위한 기존 기본 노드가 항상 구성된 우선 순위로 이동하도록 보장합니다. 클러스터에 참여하는 노드는 나중에 모든 SPUS 또는 플로우가 콜드 동기화 프로세스를 완료한 후에 구성된 우선 순위로 이동합니다. 이러한 조치를 통해 새로 추가된 노드가 주 역할을 넘기기 전에 모든RTOS를 지원할 수 있습니다.

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

섀시 SRX5600 또는 SRX5800 서비스 게이트웨이 클러스터에 있는 경우 디바이스의SPC2 또는 SPC3로 서비스 프로세싱 카드(SPC)를 교체할 때 모든 중복 그룹에서 한 노드로 장애가 발생해야 합니다.

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

이 시나리오에서는 다음과 같은 이벤트가 진행됩니다.

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

  • Node 1이 실행된 후 클러스터에 다시 연결하면 Node 1의 SPUS 수가 기본 노드인 Node 0의 SPUS 수보다 더 많이 발생합니다. 이제 한 노드(노드 0)에는 여전히 구 SPC가, 다른 노드에는 새 SPC2가 있습니다. SPC2는 카드당 4개의 SPUS를, 구형 SPC에는 카드당 2개의 SPUS가 있습니다.

    콜드 싱크 프로세스는 노드 0 총 SPU 번호를 기반으로 합니다. Node 0 SPUS에 해당하는 Node 1의 SPUS가 콜드 동기화를 완료하면 Node 1이 콜드 동기화 완료를 선언합니다. Node 1의 추가 SPUS에는 해당 노드 0 SPUS가 존재하지 못하기 때문에 동기화할 필요가 없습니다. 노드 0에서 노드 1로의 장애오버는 그 어떤 문제도 발생하지 않습니다.

    SPU 모니터링 기능은 모든 SPPU를 모니터링하고 SPU에 장애가 발생하면 보고서를 보고합니다.

    예를 들어 두 노드 모두 원래 2개 기존 SPC를 사용 중이면 두 SPC를 노드 1에서 SPC2로 대체한 것으로 가정할 수 있습니다. 이제 Node 0에는 4개 SPUS, Node 1에는 8개 SPUS가 있습니다. SPU 모니터링 기능은 Node 0의 4개 SPUS와 Node 1의 SPUS 8개에 대한 모니터링 기능을 제공합니다. 이들 8개 SP SP 중 노드 1에서 장애가 발생하면 SPU 모니터링은 여전히 sPU 장애가 Juniper jsrpd(Juniper Services Redundancy Protocol) 프로세스에 보고합니다. jsrpd 프로세스는 섀시 클러스터링을 제어합니다.

  • 노드 1이 장애오버 준비가 되면 모든 중복 그룹 장애 조치(failover)를 노드 1로 수동으로 시작할 수 있습니다. Node 0은 종료하여 SPC를 SPC2로 대체합니다. 대체 후에 Node 0 및 Node 1이 정확히 동일한 하드웨어 설정이 있을 것입니다.

일단 Node 0이 실행되고 클러스터에 재 연결하면 시스템은 표준 섀시 클러스터로 작동하게 됩니다.

Junos OS Release 15.1X49-D120 섀시 클러스터의 SRX 시리즈 디바이스에서 콜드 싱크 프로세스가 계속 진행 중인 경우, 제어 링크가 다운된 경우 노드가 보조 상태를 기본 상태로 전환하기 전에 지연(30초)이 예상됩니다.