통합 ISSU 이해

라우터의 통합 ISSU 프로세스

명령을 사용하면 request system software in-service-upgrade 다음 프로세스가 발생합니다.

아래 그림 1 부터 그림 6 까지:

• 실선은 라우팅 엔진과 패킷 전달 엔진 간의 고속 내부 링크를 나타냅니다.

• 점선은 패킷 전달 엔진과 라우팅 엔진의 섀시 프로세스(섀시) 간에 교환되는 메시지를 나타냅니다.

• RE0m 및 RE1b는 각각 기본 및 백업 라우팅 엔진을 나타냅니다.

• 확인 표시는 디바이스가 새 버전의 소프트웨어를 실행 중임을 나타냅니다.

참고:

통합 ISSU는 디바이스의 현재 릴리스보다 앞서 최대 3개의 주요 릴리스만 업그레이드할 수 있습니다. 디바이스에서 현재 릴리스보다 3개 이상 앞서 릴리스로 업그레이드하려면 디바이스가 대상 릴리스의 3개 주요 릴리스 내에 있을 때까지 통합 ISSU 프로세스를 사용하여 디바이스를 하나 이상의 중간 릴리스로 업그레이드합니다.

참고:

다음 프로세스는 TX Matrix 라우터 및 TX Matrix Plus 라우터를 제외하고 지원되는 모든 라우팅 플랫폼에 적용됩니다. 대부분의 라우터에서 패킷 전달 엔진은 FPC(Flexible PIC Concentrator)에 상주합니다. 그러나 M120 라우터에서는 FEB(Forwarding Engine Board)가 패킷 전달 엔진의 기능을 대체합니다. 그림과 단계에서 M120 라우터를 고려할 때 패킷 전달 엔진을 FPC로 간주할 수 있습니다. M120 라우터의 추가 단계로, FPC와 PIC가 업그레이드된 후 FEB가 업그레이드됩니다.

1. 기본 라우팅 엔진은 라우터 구성을 검증하여 새 소프트웨어 버전을 사용할 때 커밋할 수 있는지 확인합니다.

   다음에 대한 검사가 수행됩니다.

   • 디스크 공간은 두 라우팅 엔진의 /var 파일 시스템에 사용할 수 있습니다.

   • 구성은 통합 ISSU에 의해 지원됩니다.

   • PIC는 통합 ISSU에 의해 지원됩니다.

   • GRES(Graceful Routing Engine) 전환이 활성화됩니다.

   • Nonstop Active 라우팅이 활성화되어 있습니다.

   이러한 검사는 명령을 입력할 request system software validate in-service-upgrade 때 수행되는 검사와 동일합니다. 라우팅 엔진 중 하나에서 사용 가능한 디스크 공간이 충분하지 않은 경우 통합 ISSU 프로세스가 실패하고 오류 메시지가 반환됩니다. 그러나 지원되지 않는 PIC는 통합 ISSU를 방해하지 않습니다. 지원되지 않는 PIC가 있는 경우, 시스템은 업그레이드 중에 이러한 PIC가 다시 시작된다는 경고를 발행합니다. 마찬가지로 지원되지 않는 프로토콜이 구성되어 있는 경우 업그레이드 중에 지원되지 않는 프로토콜에 대해 패킷 손실이 발생할 수 있다는 경고가 표시됩니다.

   참고:

   Junos OS 릴리스 24.1R1부터 기본 라우팅 엔진은 INDB가 충돌했는지 확인하기 위한 검사도 실행합니다. INDB 충돌이 감지되면 통합 ISSU 프로세스가 취소됩니다.

2. 그림 1: 통합 ISSU를 시작하기 전의 디바이스 상태

3. 검증에 성공하면 관리 프로세스가 백업 라우팅 엔진에 새 소프트웨어 이미지를 설치(복사)합니다.

4. 백업 라우팅 엔진이 재부팅됩니다.

5. 백업 라우팅 엔진이 재부팅되고 새 소프트웨어를 실행한 후, 커널 상태 동기화 프로세스(ksyncd)는 기본 라우팅 엔진의 구성 파일과 커널 상태를 동기화(복사)합니다.

   그림 2: 백업 라우팅 엔진 업그레이드 후의 디바이스 상태

6. 구성 파일과 커널 상태가 백업 라우팅 엔진에 동기화된 후, 기본 라우팅 엔진의 섀시 프로세스(섀시)는 통합 ISSU를 위한 다른 소프트웨어 프로세스를 준비합니다. 섀시 프로세스는 다양한 소프트웨어 프로세스(예: rpd, apsd, bfdd 등)에 통합 ISSU에 대해 알리고 응답을 기다립니다. 모든 프로세스가 준비되면 섀시 프로세스는 라우터에 설치된 FPC에 ISSU_PREPARE 메시지를 보냅니다. 명령을 사용하여 통합 ISSU 프로세스 메시지를 표시할 수 있습니다 show log messages .

7. 각 FPC의 패킷 전달 엔진은 상태를 저장하고 백업 라우팅 엔진에서 새 소프트웨어 이미지를 다운로드합니다. 그런 다음 각 패킷 전달 엔진은 섀시 프로세스에 ISSU_READY 메시지를 보냅니다.

   그림 3: 하나의 패킷 전달 엔진이 새 소프트웨어를 다운로드한 후의 디바이스 상태

8. 패킷 전달 엔진으로부터 ISSU_READY 메시지를 수신한 섀시 프로세스는 패킷 전달 엔진이 상주하는 FPC에 ISSU_REBOOT 메시지를 보냅니다. FPC는 새 소프트웨어 이미지로 재부팅됩니다. FPC가 재부팅된 후 패킷 전달 엔진은 FPC 상태를 복원하고 새 소프트웨어를 실행하는 백업 라우팅 엔진과 고속 내부 링크가 설정됩니다. 섀시 프로세스 링크도 기본 라우팅 엔진으로 재설정됩니다.

   참고:

   통합 ISSU 중에 발생하는 패킷 전달 엔진 재부팅은 매우 짧은 다운타임을 갖도록 설계되었습니다.

9. 모든 패킷 포워딩 엔진이 기본 라우팅 엔진의 섀시 프로세스를 사용하여 READY 메시지를 전송한 후에는 라우팅 엔진 전환을 위해 다른 소프트웨어 프로세스가 준비됩니다. 이 시점에서 시스템을 전환할 준비가 되었습니다.

   그림 4: 라우팅 엔진 전환 전의 디바이스 상태
   참고:

   M120 라우터의 경우 이 시점에서 FEB가 업그레이드됩니다. 모든 FEB가 업그레이드되면 시스템은 전환할 준비가 된 것입니다.

10. 라우팅 엔진 전환이 발생하고 백업이었던 라우팅 엔진(re1)이 이제 기본 라우팅 엔진이 됩니다.

    그림 5: 라우팅 엔진 전환 후의 디바이스 상태

11. 이제 새 백업 라우팅 엔진이 새 소프트웨어 이미지로 업그레이드됩니다. (명령에서 옵션을 지정한 no-old-master-upgrade 경우 이 단계를 건너뜁니다 request system software in-service-upgrade .)

    그림 6: 통합 ISSU 완료 후의 디바이스 상태

12. 백업 라우팅 엔진이 성공적으로 업그레이드되면 통합 ISSU가 완료됩니다.

TX Matrix 라우터의 통합 ISSU 프로세스

이 섹션에서는 TX Matrix 라우터와 LCC(Connected Line-Card Chassis) 역할을 하는 라우터에서 발생하는 프로세스에 대해 설명합니다.

참고:

라우팅 매트릭스는 TX Matrix 라우터와 1개에서 4개까지의 T640 라우터로 구성된 다중 섀시 아키텍처입니다. 사용자 인터페이스의 관점에서 라우팅 매트릭스는 단일 라우터로 나타납니다. TX Matrix 라우터는 라우팅 매트릭스의 모든 T640 라우터를 제어합니다.

각 라우터에는 이중 라우팅 엔진이 있습니다.

TX Matrix 라우터에서 request system software in-service-upgrade 명령을 사용하면 다음 프로세스가 발생합니다.

1. TX Matrix 라우터(글로벌 기본)의 기본 라우팅 엔진에 대한 관리 프로세스(mgd)는 현재 구성을 확인합니다.

   다음에 대한 검사가 수행됩니다.

   • 디스크 공간은 모든 라우팅 엔진의 /var 파일 시스템에 사용할 수 있습니다.

   • 구성은 통합 ISSU에 의해 지원됩니다.

   • PIC는 통합 ISSU에 의해 지원됩니다.

   • GRES(Graceful Routing Engine) 전환이 활성화됩니다.

   • Nonstop Active 라우팅이 활성화되어 있습니다.

2. 구성을 성공적으로 검증한 후 관리 프로세스는 TX Matrix 라우터 및 T640 라우터의 백업 라우팅 엔진에 새 이미지를 복사합니다.

3. 백업 라우팅 엔진의 커널 동기화 프로세스(ksyncd)는 백업 라우팅 엔진의 커널을 기본 라우팅 엔진의 커널과 동기화합니다.

4. 글로벌 백업 라우팅 엔진이 새로운 소프트웨어로 업그레이드됩니다. 다음으로 글로벌 백업 라우팅 엔진이 재부팅됩니다. 그런 다음 글로벌 백업 라우팅 엔진은 글로벌 기본 라우팅 엔진의 구성 및 커널 상태를 동기화합니다.

5. LCC 백업 라우팅 엔진이 업그레이드되고 재부팅됩니다. 그런 다음 LCC 백업 라우팅 엔진이 업그레이드된 글로벌 백업 라우팅 엔진과 연결되어 구성과 커널 상태를 동기화합니다.

6. 통합 ISSU 제어는 관리 프로세스에서 섀시 프로세스(섀시)로 이동합니다. 섀시 프로세스는 다양한 소프트웨어 프로세스(예: rpd, apsd, bfdd 등)에 통합 ISSU에 대해 알리고 응답을 기다립니다.

7. 프로세스가 통합 ISSU에 대한 준비가 되었음을 나타내는 소프트웨어 프로세스로부터 메시지를 수신한 후, 글로벌 기본 라우팅 엔진의 섀시 프로세스는 라우팅 노드의 섀시 프로세스로 메시지를 전송하여 통합 ISSU를 시작합니다.

8. 라우팅 노드의 섀시 프로세스는 FPC 및 지능형 PIC와 같은 현장 교체 장치(FRU)에 ISSU_PREPARE 메시지를 보냅니다.

9. ISSU_PREPARE 메시지를 수신한 후 패킷 전달 엔진은 현재 상태 정보를 저장하고 백업 라우팅 엔진에서 새 소프트웨어 이미지를 다운로드합니다. 그런 다음 각 패킷 전달 엔진은 ISSU_READY 메시지를 섀시 프로세스로 보냅니다. 명령을 사용하여 통합 ISSU 프로세스 메시지를 표시할 수 있습니다 show log messages .

10. 패킷 전달 엔진에서 ISSU_READY 메시지를 수신한 섀시 프로세스는 FRU에 ISSU_REBOOT 메시지를 보냅니다. 업그레이드가 진행되는 동안 FRU는 라우팅 노드의 섀시 프로세스에 ISSU_IN_PROGRESS 메시지를 계속 보냅니다. 각 라우팅 노드의 섀시 프로세스는 글로벌 기본 라우팅 엔진의 섀시 프로세스로 ISSU_IN_PROGRESS 메시지를 보냅니다.

    참고:

    통합 ISSU 중에 발생하는 패킷 전달 엔진 재부팅은 매우 짧은 다운타임을 갖도록 설계되었습니다.

11. 통합 ISSU 재부팅 후 패킷 전달 엔진은 저장된 상태 정보를 복원하고 라우팅 노드에 다시 연결합니다. 각 라우팅 노드의 섀시 프로세스는 글로벌 기본 라우팅 엔진의 섀시 프로세스로 ISSU_READY 메시지를 보냅니다. 라우팅 노드의 섀시 프로세스에서 CM_MSG_READY 메시지는 통합 ISSU가 FRU에서 완료되었음을 나타냅니다.

12. 통합 ISSU 제어는 글로벌 기본 라우팅 엔진의 관리 프로세스로 다시 이동합니다.

13. 관리 프로세스는 기본 라우팅 엔진에서 라우팅 엔진 전환을 시작합니다.

14. 라우팅 엔진 전환은 TX Matrix 라우터 및 T640 라우터에서 발생합니다.

15. 전환 후 FRU는 새로운 기본 라우팅 엔진에 연결됩니다. 그런 다음 T640 라우터 FRU의 섀시 관리자 및 패킷 전달 엔진 관리자가 T640 라우터의 새로운 기본 라우팅 엔진에 연결됩니다.

16. 글로벌 기본 라우팅 엔진의 관리 프로세스는 T640 라우터의 기존 기본 라우팅 엔진에서 업그레이드 프로세스를 시작합니다. (명령에서 옵션을 지정한 no-old-master-upgrade 경우 이 단계를 건너뜁니다 request system software in-service-upgrade .)

17. 이전에 T640 라우터의 기본이었던 라우팅 엔진이 업그레이드된 후, 관리 프로세스는 TX Matrix 라우터에서 이전에 글로벌 기본이었던 라우팅 엔진의 업그레이드를 시작합니다.

18. 성공적인 통합 ISSU 후 명령에 옵션을 지정하면 reboot TX Matrix 라우터와 T640 라우터가 재부팅됩니다 request system software in-service-upgrade .