일반 업그레이드 고려사항

vSRX 업그레이드를 수행하기 전에 다음 고려사항에 유의하십시오.

vSRX 버전을 업그레이드할 때 네트워크 연결이 일시적으로 중단될 수 있습니다. 중단을 피하려면 잠재적인 네트워크 작동 중단을 지원하는 유지보수 기간 중에 업그레이드를 수행하십시오. 업그레이드가 완료될 때까지 장애 복구를 사용할 수 없으며, 완료되는 데 몇 시간이 걸릴 수 있습니다. 고가용성(HA) 환경의 경우 vSRX 구성 설정이 마이그레이션되지만 업그레이드 전에 설정을 내보내는 것이 좋습니다.
독립형 환경의 경우 이전 구성은 복원되지 않으므로 구성을 내보낸 후 가져와야 합니다. 자세한 정보는 vSRX 구성 가져오기 및 내보내기를 참조하십시오.
HA vSRX에서 다시 로드에 성공하려면 프로비저닝된 vSRX 게이트웨이의 루트 비밀번호가 vSRX 포털에 정의된 루트 비밀번호와 일치해야 합니다. 또한 vSRX 사설 IP에 대한 루트 SSH 로그인을 사용으로 설정해야 합니다.

게이트웨이를 프로비저닝할 때 포털에서 비밀번호를 정의했습니다. 이 비밀번호가 현재 게이트웨이 비밀번호와 일치하지 않을 수 있습니다. 프로비저닝 후 비밀번호가 변경된 경우에는 SSH를 사용하여 vSRX 게이트웨이에 연결한 후 일치하도록 루트 비밀번호를 변경하십시오. 비밀번호 불일치가 있으면 준비 확인에 실패합니다.
OS 다시 로드 중에 vSRX 구성을 수정하지 마십시오. 업그레이드 프로세스는 프로세스 시작 시 현재 vSRX 클러스터 구성의 스냅샷을 캡처합니다. 그러므로 업그레이드 프로세스 중에 vSRX 구성을 수정하면 실패 또는 예측 불가능한 결과가 발생할 수 있습니다. 예를 들어 vSRX 노드 중 하나 또는 둘 다를 수정하려고 시도하는 자동화된 소프트웨어 에이전트가 있습니다. 구성이 변경되면 OS 다시 로드 프로세스가 손상될 수 있습니다. 또한 롤백이 시작되면 이러한 구성 변경사항이 유지되지 않습니다.

HA 클러스터에서 OS 다시 로드 업그레이드를 수행하기 전에 show chassis cluster status 명령을 명령하십시오. 노드들은 클러스터로 구성되어야 하며, 그중 하나는 주 노드로, 다른 하나는 보조 노드로 지정되어야 합니다. monitor failures가 없는지 확인하십시오. 업그레이드 전에 클러스터 상태가 양호하지 않으면 업그레이드가 실패하여 트래픽 중단이 장기화될 수 있습니다.

정상 클러스터 예:

 root@asloma-19-10g-ha1-vsrx-vSRX-Node0> show chassis cluster status
 Monitor Failure codes:
   CS  Cold Sync monitoring        FL  Fabric Connection monitoring
   GR  GRES monitoring             HW  Hardware monitoring
   IF  Interface monitoring        IP  IP monitoring
   LB  Loopback monitoring         MB  Mbuf monitoring
   NH  Nexthop monitoring          NP  NPC monitoring
   SP  SPU monitoring              SM  Schedule monitoring
   CF  Config Sync monitoring      RE  Relinquish monitoring
   IS  IRQ storm

 Cluster ID: 2
 Node   Priority Status               Preempt Manual   Monitor-failures

 Redundancy group: 0 , Failover count: 1
 node0  100      primary              no      no       None
 node1  1        secondary            no      no       None

 Redundancy group: 1 , Failover count: 1
 node0  100      primary              no      no       None
 node1  1        secondary            no      no       None

 {primary:node0}

모니터 장애가 있는 비정상 클러스터 예:

  root@asloma-tc11-15-10g-pubpriv-ha1-vsrx-vSRX-Node1> show chassis cluster status
  Monitor Failure codes:
    CS  Cold Sync monitoring        FL  Fabric Connection monitoring
    GR  GRES monitoring             HW  Hardware monitoring
    IF  Interface monitoring        IP  IP monitoring
    LB  Loopback monitoring         MB  Mbuf monitoring
    NH  Nexthop monitoring          NP  NPC monitoring
    SP  SPU monitoring              SM  Schedule monitoring
    CF  Config Sync monitoring
  Cluster ID: 3
  Node   Priority Status         Preempt Manual   Monitor-failures

  Redundancy group: 0 , Failover count: 1
  node0  0        lost           n/a     n/a      n/a
  node1  1        primary        no      no       None

  Redundancy group: 1 , Failover count: 1
  node0  0        lost           n/a     n/a      n/a
  node1  0        primary        no      no       CS

  {primary:node1}

IBM Cloud 계정에 동일한 팟(Pod)의 여러 vSRX 게이트웨이 인스턴스가 있는 경우 한 번에 하나의 게이트웨이만 업그레이드되도록 하십시오. 한 번에 둘 이상의 vSRX를 업그레이드하면 IP가 충돌하고 업그레이드 프로세스가 손상되며 실패할 가능성이 있습니다.
HA 클러스터를 침입 탐지 정책(IDP) 및 시그니처 데이터베이스를 사용하도록 구성한 경우, 업그레이드를 완료한 후 시그니처 데이터베이스를 업데이트하는 것이 좋습니다. 데이터베이스가 오래되었을 수 있기 때문입니다. 온라인 및 오프라인 데이터베이스 업데이트에 대한 자세한 내용은 다음을 참조하십시오. [삽입 위치]에서의 침입 탐지 및 방지 IBM Cloud
업그레이드 과정에서는 업그레이드 대상인 가상 머신( VM )에 로컬로 저장된 vSRX 인증서를 백업하거나 복원하지 않습니다. 업그레이드 과정에서는 기존 VM 파일을 삭제하고 새로운 파일을 생성하며, 이 새로운 파일이 JunOS 파일 시스템을 대체합니다. 예를 들어, IKE_POLICY_CERT 와 같은 로컬 인증서는 업그레이드 전에 백업되고 완료 후에 수동으로 복원되어야 합니다.

set security ike policy MY_VPN_IKE_POLICY certificate local-certificate IKE_POLICY_CERT

Ubuntu 하이퍼바이저 업그레이드 시 고려 사항

vSRX 는 Ubuntu 하이퍼바이저 상에서 VM 로 실행됩니다. 일반적으로 이 하이퍼바이저 운영 체제는 vSRX 업데이트의 일환으로 다시 로드됩니다. 하지만 커널 업데이트, 보안 패치 또는 취약점 수정 등을 적용하는 경우처럼, vSRX 가상 머신 자체를 업그레이드하지 않고 Ubuntu 하이퍼바이저만 유지보수해야 할 때도 있습니다.

이러한 경우, 일반적으로 표준 apt update 명령만으로도 충분하지만, 반드시 유의해야 할 몇 가지 중요한 사항이 있습니다. Ubuntu 하이퍼바이저만 업그레이드하는 것은 일반적으로 안전한 유지 관리 작업으로 간주되며, 실행 중인 vSRX 가상 머신에 미치는 영향을 최소화하면서 수행할 수 있습니다. 표준 사용자 공간 라이브러리와 유틸리티를 포함한 대부분의 패키지 업데이트는 게스트 시스템( VM )의 작동을 중단할 필요가 없습니다.

그러나 관리자는 진행하기 전에 업그레이드에 포함된 패키지를 꼼꼼히 검토해야 합니다. 특정 업데이트는 하이퍼바이저를 재부팅할 때까지 실행 중인 가상 머신의 안정성이나 연결 상태에 영향을 줄 수 있습니다.

다음과 같은 유형의 업데이트에는 각별한 주의가 필요합니다:

커널 패키지
systemd 그리고 udev 업데이트
libvirt 패키지
nftables, 브리지 또는 기타 가상화 네트워킹 구성 요소와 같은 네트워킹 관련 패키지
qemu 그리고 kvm 패키지 업데이트

경우에 따라 가상 머신을 가동한 상태에서 가상화 또는 네트워크 관련 패키지를 업그레이드하면, 하이퍼바이저 노드를 재시작할 때까지 VM 네트워킹 성능이 저하되거나 인터페이스가 응답하지 않거나 libvirt 상태가 일관되지 않게 될 수 있습니다. Ubuntu 하이퍼바이저를 재시작하면 대개 정상 작동 상태로 복구됩니다.

하이퍼바이저에서 리소스 할당( apt upgrade )을 수행할 때는 다음 권장 사항을 고려하십시오

업데이트를 적용하기 전에 보류 중인 패키지를 확인하십시오.
커널, libvirt 또는 네트워킹 구성 요소가 업그레이드되는 경우 유지보수 시간을 예약하십시오.
필요할 경우 하이퍼바이저 재부팅을 계획하십시오.
가능한 한 여러 HA 노드에 대해 동시에 유지보수 작업을 수행하지 마십시오.

예:

apt update
apt list --upgradable
apt upgrade