주니퍼 네트웍스 라우터의 고가용성 기능 이해하기
Junos 운영체제(Junos OS)를 실행하는 주니퍼 네트웍스 라우팅 플랫폼의 경우, 고가용성 이란 패킷 기반 통신에 대한 이중화 및 안정성을 제공하는 하드웨어 및 소프트웨어 구성 요소를 의미합니다. 이 항목에서는 다음과 같은 고가용성 기능에 대해 간략하게 설명합니다.
라우팅 엔진 이중화
중복 라우팅 엔진은 동일한 라우팅 플랫폼에 설치되는 두 개의 라우팅 엔진입니다. 하나는 기본으로 작동하고, 다른 하나는 기본 라우팅 엔진에 장애가 발생할 경우 백업으로 대기합니다. 이중 라우팅 엔진을 사용하는 라우팅 플랫폼에서는 네트워크 리컨버전스가 단일 라우팅 엔진을 사용하는 라우팅 플랫폼보다 더 빠르게 이루어집니다.
그레이스풀 라우팅 엔진 스위치오버
GRES(Graceful 라우팅 엔진 Switchover)는 이중화된 라우팅 엔진이 장착된 라우팅 플랫폼에서 라우팅 엔진 하나가 실패하더라도 패킷을 계속 전달할 수 있도록 해줍니다. 그레이스풀 라우팅 엔진 스위치오버는 인터페이스 및 커널 정보를 보존합니다. 트래픽이 중단되지 않습니다. 그러나 그레이스풀 라우팅 엔진 스위치오버는 컨트롤 플레인을 보존하지 않습니다. 인접 라우터는 라우터가 재시작되었음을 감지하고 개별 라우팅 프로토콜 사양에 규정된 방식으로 이벤트에 대응합니다.
전환 중 라우팅을 보존하려면 그레이스풀 라우팅 엔진 스위치오버를 그레이스풀 재시작(Graceful Restart) 프로토콜 확장 또는 무중단 액티브 라우팅과 결합해야 합니다. 자세한 내용은 GR(Graceful 라우팅 엔진 Switchover ) 및 NSR(Nonstop Active Routing) 개념 이해하기를 참조하세요.
NSR을 사용하는 GRES의 경우 T 시리즈 라우터, TX Matrix 라우터, TX Matrix Plus 라우터에서 컨트롤 플레인이 보존되며, 패킷 포워딩 엔진당 트래픽 회선 속도의 75%가 GRES가 진행되는 동안 중단되지 않습니다.
논스톱 브리징
논스톱 브리징을 통해 중복 라우팅 엔진이 장착된 MX 시리즈 5G 유니버설 라우팅 플랫폼이 L2CP(Layer 2 Control Protocol) 정보를 손실하지 않고 기본 라우팅 엔진에서 백업 라우팅 엔진으로 전환할 수 있습니다. 논스톱 브리징은 그레이스풀 라우팅 엔진 스위치오버와 동일한 인프라를 사용하여 인터페이스 및 커널 정보를 보존합니다. 그러나 논스톱 브리징은 백업 라우팅 엔진에서 레이어 2 제어 프로토콜 프로세스(l2cpd)를 실행하여 L2CP 정보도 저장합니다.
논스톱 브리징을 사용하려면 먼저 Graceful 라우팅 엔진 전환을 활성화해야 합니다.
논스톱 브리징은 다음 레이어 2 제어 프로토콜에 지원됩니다.
스패닝 트리 프로토콜(STP)
RSTP(Rapid Spanning Tree Protocol)
다중 스패닝 트리 프로토콜(MSTP)
VLAN 스패닝 트리 프로토콜(VSTP)
자세한 내용은 Nonstop Bridging Concepts를 참조하십시오.
NSR(Nonstop Active Routing)
NSR(Nonstop Active Routing)은 중복 라우팅 엔진이 있는 라우팅 플랫폼이 피어 노드에 변경 사항이 발생했음을 알리지 않고 기본 라우팅 엔진에서 백업 라우팅 엔진으로 전환할 수 있도록 합니다. NSR(Nonstop Active Routing)은 그레이스풀 라우팅 엔진 스위치오버와 동일한 인프라를 사용하여 인터페이스 및 커널 정보를 보존합니다. 그러나 논스톱 액티브 라우팅은 두 라우팅 엔진에서 라우팅 프로토콜 프로세스(rpd)를 실행하여 라우팅 정보 및 프로토콜 세션을 보존합니다. 또한 nonstop active routing은 커널에서 유지되는 TCP 연결을 보존합니다.
NSR(Nonstop Active Routing)을 사용하려면 그레이스풀 라우팅 엔진 스위치오버도 구성해야 합니다.
NSR( Nonstop Active Routing)이 지원하는 프로토콜 및 기능 목록은 NSR(Nonstop Active Routing) 프로토콜 및 기능 지원을 참조하십시오.
무중단 활성 라우팅에 대한 자세한 내용은 무중단 활성 라우팅 개념을 참조하십시오.
그레이스풀 리스타트(Graceful Restart)
라우팅 프로토콜에서 서비스가 중단되면 영향을 받는 라우터가 이웃 라우터와의 인접성을 다시 계산하고, 라우팅 테이블 항목을 복원하고, 기타 프로토콜 관련 정보를 업데이트해야 합니다. 라우터를 보호되지 않은 상태로 재시작하면 포워딩 지연, 경로 플래핑, 프로토콜 재컨버전스로 인한 대기 시간이 발생하고 패킷 손실이 발생할 수 있습니다. 이 상황을 완화하기 위해 Graceful Restart는 라우팅 프로토콜에 확장을 제공합니다. 이러한 프로토콜 확장은 라우터에 대해 재시작 및 도우미라는 두 가지 역할을 정의합니다. 확장은 재시작 중인 라우터에 대해 인접 라우터에 신호를 보내고 GR(Graceful Restart) 대기 간격 동안 인접 라우터가 상태 변경을 네트워크로 전파하는 것을 방지합니다. Graceful Restart의 주요 이점은 중단 없는 패킷 포워딩과 모든 라우팅 프로토콜 업데이트의 일시적 억제입니다. Graceful Restart를 통해 라우터는 네트워크의 나머지 부분에서 숨겨진 중간 컨버전스 상태를 통과할 수 있습니다.
라우터가 Graceful Restart를 실행 중이고 라우터가 Protocol Liveness 메시지(Hello) 전송 및 응답을 중단하면 인접성은 Graceful Restart를 가정하고 타이머를 실행하여 재시작 라우터를 모니터링하기 시작합니다. 이 간격 동안 도우미 라우터는 재시작 중이라고 가정하는 라우터에 대한 인접성 변경을 처리하지 않고 네트워크의 나머지 부분과 함께 활성 라우팅을 계속합니다. 도우미 라우터는 라우터가 재시작하는 동안 마지막으로 보존된 라우팅 상태를 기반으로 상태 저장 전달을 계속할 수 있다고 가정합니다.
라우터가 실제로 재시작 중이고 모든 헬퍼 라우터에서 graceful timer 기간이 만료되기 전에 백업된 경우, 헬퍼 라우터는 라우터에 라우팅 테이블, 토폴로지 테이블 또는 레이블 테이블(프로토콜에 따라 다름)을 제공하고, graceful 기간을 종료하고, 정상 네트워크 라우팅으로 돌아갑니다.
모든 헬퍼 라우터에서 graceful timer 기간이 만료되기 전에 라우터가 헬퍼 라우터와의 협상을 완료하지 않으면, 헬퍼 라우터는 라우터의 상태 변경을 처리하고 라우팅 업데이트를 전송하여 네트워크 전반에 걸쳐 컨버전스가 발생합니다. 도우미 라우터가 라우터에서 링크 실패를 감지하면, 토폴로지 변경으로 인해 도우미 라우터가 graceful 대기 기간을 종료하고 라우팅 업데이트를 전송하여 네트워크 컨버전스가 발생합니다.
라우터의 Graceful Restart를 활성화하려면 글로벌 [edit routing-options] 또는 [edit routing-instances instance-name routing-options] 계층 수준에서 문을 포함 graceful-restart 해야 합니다. 필요에 따라 개별 프로토콜 수준에서 전역 설정을 수정할 수 있습니다. 라우팅 세션이 시작될 때, Graceful Restart로 구성된 라우터는 Graceful Restart를 겪을 때 이를 지원하기 위해 해당 이웃과 협상해야 합니다. 이웃 라우터는 협상을 수락하고 이웃 라우터에서 Graceful Restart를 구성할 필요 없이 Helper 모드를 지원합니다.
graceful 대기 상태에 있는 도우미 라우터의 라우팅 엔진 전환 이벤트로 인해 라우터는 대기 상태를 삭제하고 인접성의 상태 변경을 네트워크에 전파합니다.
Graceful Restart는 다음 프로토콜 및 애플리케이션에 지원됩니다.
BGP(Border
ES-IS
IS-IS
OSPF/OSPFv3
PIM Sparse 모드
찢기/찢기
다음을 포함한 MPLS 관련 프로토콜:
LDP(Label Distribution Protocol)
리소스 예약 프로토콜(RSVP)
CCC (Circuit cross-connect)
TCC (Transational cross-connect)
레이어 2 및 레이어 3 VPN(Virtual Private Network)
자세한 내용은 Graceful Restart 개념을 참조하십시오.
Nonstop Active Routing vs. Graceful Restart
NSR(Nonstop Active Routing)과 Graceful Restart는 고가용성을 유지하는 두 가지 방법입니다. Graceful Restart는 라우터를 다시 시작해야 합니다. Graceful Restart를 진행 중인 라우터는 라우팅 프로토콜 정보를 복원하기 위해 해당 이웃(또는 도우미)에 의존합니다. 재시작은 헬퍼에게 대기 간격을 종료하고 재시작 라우터에 라우팅 정보를 제공하도록 신호를 보내는 메커니즘입니다 자세한 내용은 Graceful Restart 개념을 참조하십시오.
반대로, 무중단 활성 라우팅은 라우터 재시작을 수반하지 않습니다. 기본 및 백업 라우팅 엔진 모두 라우팅 프로토콜 프로세스(rpd)를 실행하고 이웃과 업데이트를 교환합니다. 하나의 라우팅 엔진에 장애가 발생하면 라우터는 단순히 활성 라우팅 엔진으로 전환하여 이웃과 라우팅 정보를 교환합니다. 이러한 기능 차이로 인해 논스톱 라우팅과 Graceful Restart는 상호 배타적입니다. 라우터가 GR(Graceful Restart) 라우터로 구성된 경우 NSR(Nonstop Active Routing)을 사용할 수 없습니다. 모든 계층 수준에서 명령문을 포함하고 nonstop-routing 계층 수준에서 명령문을 [edit routing-options] 포함 graceful-restart 하고 구성을 커밋하려고 시도하면 커밋 요청이 실패합니다. 자세한 내용은 NSR(Nonstop Active Routing Concepts)을 참조하세요.
라우팅 엔진 전환의 효과
라우팅 엔진 전환의 효과 는 고가용성 기능이 활성화되지 않은 경우와 그레이스풀 라우팅 엔진 스위치오버, 그레이스풀 재시작, 무중단 활성 라우팅 기능이 활성화된 경우 라우팅 엔진 스위치오버의 효과를 설명합니다.
VRRP (VRRP)
VRRP(Virtual Router Redundancy Protocol)는 LAN의 호스트가 LAN의 중복 라우팅 플랫폼(기본 및 백업 페어)을 사용할 수 있도록 하며, 호스트에서 단일 기본 경로의 정적 구성만 필요합니다.
VRRP 라우팅 플랫폼 쌍은 호스트에서 구성된 기본 경로에 해당하는 IP 주소를 공유합니다. VRRP 라우팅 플랫폼 중 하나는 기본(활성)이고 나머지는 백업입니다. 기본에 장애가 발생하면 백업 라우터 또는 스위치 중 하나가 새로운 기본 라우터가 됩니다.
VRRP는 관리 용이성과 네트워크 처리량 및 안정성 측면에서 다음과 같은 장점이 있습니다.
가상 기본 라우팅 플랫폼을 제공합니다.
LAN의 트래픽을 단일 장애 지점 없이 라우팅할 수 있습니다.
가상 백업 라우터는 장애가 발생한 기본 라우터를 대신할 수 있습니다.
몇 초 안에.
최소 VRRP 트래픽.
호스트와의 상호 작용 없이.
VRRP를 실행하는 디바이스는 기본 및 백업 라우터를 동적으로 선택합니다. 또한 1에서 255까지의 우선 순위를 사용하여 기본 및 백업 라우터를 강제로 할당할 수 있으며, 255가 가장 높은 우선 순위입니다.
VRRP 작업에서, 기본 기본 라우터는 정기적으로 백업 라우터에 광고를 전송합니다(기본 1초). 백업 라우터가 설정된 기간 동안 광고를 수신하지 않으면 다음으로 높은 우선 순위를 가진 백업 라우터가 기본으로 인계되어 패킷을 전송하기 시작합니다.
Junos OS 릴리스 13.2부터 VRRP NSR(Nonstop Active Routing)은 또는 [edit logical system logical-system-name routing-options] 계층 수준에서 문을 [edit routing-options] 구성할 nonstop-routing 때만 활성화됩니다.
자세한 내용은 VRRP 이해를 참조하십시오.
통합 ISSU
통합 ISSU(in-service software upgrade)를 사용하면 컨트롤 플레인의 중단 없이 트래픽 중단을 최소화하면서 서로 다른 두 개의 Junos OS 릴리스 간에 업그레이드할 수 있습니다. 통합 ISSU는 듀얼 라우팅 엔진 플랫폼에서만 지원됩니다. 또한 GRES(Graceful 라우팅 엔진 Switchover) 및 NSR(Nonstop Active Routing)을 활성화해야 합니다.
통합 ISSU를 사용하면 네트워크 다운타임을 없애고 운영 비용을 절감하며 더 높은 수준의 서비스를 제공할 수 있습니다. 자세한 내용은 Unified In-Service Software Upgrade 시작하기를 참조하십시오.
Virtual Chassis를 사용한 MX 시리즈 라우터의 섀시 간 이중화
섀시 간 중복 은 여러 지역에 위치한 장비를 포괄할 수 있는 고가용성 기능으로, 연결된 가입자를 눈에 띄게 방해하거나 서비스 프로바이더의 네트워크 관리 부담을 증가시키지 않으면서 네트워크 중단을 방지하고 액세스 링크 장애, 업링크 장애 및 대규모 섀시 장애로부터 라우터를 보호합니다. 우선 순위가 높은 음성 및 비디오 트래픽이 네트워크에서 전송됨에 따라 섀시 간 중복은 광대역 서비스 라우터, 광대역 네트워크 게이트웨이 및 광대역 원격 액세스 서버와 같은 광대역 가입자 관리 장비에 스테이트풀 중복을 제공하기 위한 요구 사항이 되었습니다. 섀시 간 이중화 지원을 통해 서비스 프로바이더는 엄격한 SLA(서비스 수준 계약)를 이행하고 계획되지 않은 네트워크 중단을 방지하여 고객의 요구를 더 잘 충족할 수 있습니다.
MX 시리즈 5G 유니버설 라우팅 플랫폼에 스테이트풀 섀시 간 이중화 솔루션을 제공하기 위해 Virtual Chassis를 구성할 수 있습니다. Virtual Chassis 구성은 두 개의 MX 시리즈 라우터를 단일 네트워크 요소로 관리할 수 있는 논리적 시스템으로 상호 연결합니다. Virtual Chassis의 구성원 라우터는 기본 라우터 ( 프로토콜 기본이라고도 함) 및 백업 라우터 ( 프로토콜 백업이라고도 함)로 지정됩니다. 구성원 라우터는 Trio MPC/MIC(Modular Port Concentrator/Modular Interface Card) 인터페이스에서 구성한 전용 Virtual Chassis 포트를 통해 상호 연결됩니다.
MX 시리즈 Virtual Chassis는 IS-IS를 기반으로 하는 전용 제어 프로토콜인 VCCP(Virtual Chassis Control Protocol)에 의해 관리됩니다. VCCP는 Virtual Chassis 포트 인터페이스에서 실행되며 Virtual Chassis 토폴로지 구축, Virtual Chassis 기본 라우터 선택, Virtual Chassis 내 트래픽을 라우팅하기 위한 섀시 간 라우팅 테이블 설정을 담당합니다.
Junos OS 릴리스 11.2부터 Virtual Chassis 구성은 Trio MPC/MIC 인터페이스와 듀얼 라우팅 엔진을 갖춘 MX240, MX480 및 MX960 유니버설 라우팅 플랫폼에서 지원됩니다. 또한 GRES(Graceful 라우팅 엔진 Switchover) 및 NSR(Nonstop Active Routing)은 Virtual Chassis의 두 멤버 라우터에서 모두 활성화되어야 합니다.
ACX7000 시리즈의 플랫폼별 고가용성 동작
ACX7000 디바이스 시리즈의 하드웨어 아키텍처는 PTX 및 MX 시리즈 디바이스와 다릅니다. PTX 및 MX 시리즈 디바이스에서 FPC는 데이터 경로 PFE와 WAN 페이싱 포트(PIC/MIC)를 모두 호스팅합니다. PTX 및 MX 시리즈 디바이스에서 각 FPC는 FPC 구성 요소를 관리하기 위한 CPU 컴퓨팅 리소스를 포함하도록 설계되었습니다.
ACX7000 디바이스 시리즈에서 FEB(포워딩 엔진 보드) FRU에는 PFE 컴플렉스만 포함되고 라우팅 엔진에는 CPU 컴퓨팅 컴플렉스가 포함됩니다. 라우팅 엔진 FRU는 라우팅 엔진 및 라인 카드 애플리케이션을 모두 실행합니다.
다음 표에는 ACX7000 디바이스 시리즈에서 지원되는 고가용성 특성 및 기능이 나와 있습니다.
| 고가용성 특성 및 기능 |
ACX7509 |
ACX7348 |
|---|---|---|
| 컨트롤 플레인(RE) 이중화 |
예 |
예 |
| 데이터 플레인(PFE) 이중화 |
예 |
아니요 |
| GRES+GR |
예 |
예 |
| GRES+NSR |
예 |
예 |
ACX7348에서 라우팅 엔진 전환 중에 현재 플로우를 변경하거나 새 플로우를 도입하면 전환이 완료될 때까지 컨버전스가 발생하지 않습니다. 전환 중 토폴로지 변경은 전환 후에만 적용됩니다. 전환 중에 트래픽 손실 및 경미한 통계 손실이 예상됩니다.
GRES는 Junos Evolved 운영 체제에서 기본적으로 활성화되며 비활성화할 수 없습니다
전환 중에 라우팅을 유지하려면 GRES를 다음 중 하나와 결합해야 합니다.
- GR(Graceful Restart) 프로토콜 확장
- NSR(Nonstop Active Routing) 및 NSB(Nonstop Bridging)
디바이스ACX7348 전환 라우팅 엔진중에 BNG(Broadband 네트워크 게이트웨이), VXLAN, sFlow, J-Flow, 포트 미러링과 같은 기능에 속하는 구성이 감지되면 데이터 경로가 재설정되고 트래픽 리컨버전스가 표시됩니다.
기본 라우팅 엔진에서 switchover 명령을 실행하기 전에 백업 라우팅 엔진에서 show system switchover 명령을 사용하여 백업 라우팅 엔진의 상태를 확인합니다. 전환 상태가 준비되면 전환 명령을 실행합니다.
백업 라우팅 엔진이 준비되지 않은 경우에도 switchover 명령을 실행할 수 있습니다. 이 경우, 라우팅 엔진은 기본 라우팅 엔진으로 전환하며(백업이 준비되지 않았더라도) 시스템 동작은 불확정입니다.
라우팅 엔진 전환으로 인해 전환 시간 동안 통계 회계 손실이 발생합니다.
ACX7509는 다음 표에 설명된 대로 라우팅 엔진 중복성을 지원합니다.
| 시스템 구성 |
중복성 |
|---|---|
| 단일 RE / 단일 FEB |
해당 사항 없음. 시스템이 비이중화 모드에서 작동합니다. |
| 듀얼 RE / 듀얼 FEB |
지원 |
| 듀얼 RE / 싱글 FEB |
지원되지 않습니다. 시스템이 비이중화 모드에서 작동합니다. |
| 싱글 RE / 듀얼 FEB |
지원되지 않습니다. 시스템이 비이중화 모드에서 작동합니다. |
타이밍 프로토콜은 고가용성을 지원하지 않습니다. 따라서 타이밍 애플리케이션은 활성 기본 라우팅 엔진에서만 실행되며 백업 라우팅 엔진에서는 실행되지 않습니다. 타이밍 애플리케이션은 라우팅 엔진 전환 시 다시 시작됩니다. 라우팅 엔진 전환 중에 graceful 또는 non-graceful RE 스위치오버, PTP, GM 및 SYNCE는 잠금을 잃고 상자는 FREERUN 상태로 이동합니다. 하드웨어 내의 PTP 패킷 경로가 끊어집니다. 모든 다운스트림 디바이스가 네트워크의 대체 기본 디바이스로 전환됩니다. 대체 기본이 없으면 모든 다운스트림 디바이스가 HOLDOVER 상태로 전환됩니다.
ACX7348 디바이스에서 기본 라우팅 엔진의 Online/Offline 버튼을 누르면 백업 라우팅 엔진으로의 전환이 정상적으로 이루어집니다. 라우팅 엔진 LED가 꺼진 후 라우팅 엔진 카드를 안전하게 제거할 수 있습니다. 백업 라우팅 엔진의 온라인/오프라인 버튼을 눌러도 기본 라우팅 엔진에는 아무런 영향을 미치지 않습니다.