Junos Node Slicing 업그레이드
Junos Node Slicing 업그레이드에는 JDM(Juniper Device Manager), GNF(Guest Network Functions) 및 BSYS(Base System)의 업그레이드가 포함됩니다.
Junos Node Slicing 업그레이드
Junos Node Slicing은 세 가지 유형의 소프트웨어 구성 요소로 구성됩니다.
-
JDM(Juniper Device Manager) 패키지
-
게스트 네트워크 기능(GNF)을 위한 Junos OS 이미지
-
기본 시스템용 Junos OS 패키지(BSYS)
허용된 소프트웨어 버전 범위 내에 있는 한 이러한 각 구성 요소를 독립적으로 업그레이드할 수 있습니다(자세한 내용은 다중 버전 소프트웨어 상호 운용성 개요 참조). 모두 함께 업그레이드할 수도 있습니다.
-
업그레이드 프로세스를 시작하기 전에 참조를 위해 JDM, GNF VM 및 BSYS 구성을 저장합니다.
-
라인 카드에서 BIOS 업그레이드를 실행하려면 Junos 노드 슬라이싱 구성을 비활성화하여 라우터가 독립형 모드인지 확인해야 합니다.
- 외부 서버 모델에 대한 JDM 업그레이드
- Podman 기반 배포를 지원하도록 JDM 업그레이드(23.2R1)
- 섀시 내 모델을 위한 JDM 업그레이드
- GNF 및 BSYS 업그레이드
- WRL 9 기반 VM 호스트를 지원하도록 JDM 업그레이드 - 섀시 내 모델
외부 서버 모델에 대한 JDM 업그레이드
-
두 서버 모두에서 다음 작업을 수행하여 JDM을 업그레이드합니다.
-
새 JDM 패키지(RPM 또는 Ubuntu)를 호스트의 디렉터리(예: / var/tmp)에 복사합니다.
-
다음 명령을 사용하여 JDM을 중지합니다.
root@Linux server0#
jdm stop
Stopping JDM -
업그레이드 명령을 실행하여 JDM 패키지를 업그레이드합니다.
JDM RHEL 패키지를 업그레이드하는 경우 다음 명령을 사용합니다.
root@Linux server0#
rpm -U package_name.rpm --force
JDM Ubuntu 패키지를 업그레이드하는 경우 다음 명령을 사용합니다.
root@Linux server0#
dpkg -i package.deb
참고:-
JDM 업그레이드는 실행 중인 GNF에 영향을 주지 않습니다.
-
JDM을 업그레이드하기 전에 두 JDM 배포가 동기화되어 있는지 확인하십시오. 이는 다음을 의미합니다.
-
지정된 GNF에서 실행되는 Junos는 두 서버 모두에서 동일한 SMBIOS 버전을 지원해야 합니다.
-
업그레이드하기 전에 모든 GNF가 두 서버에 모두 존재하는지 확인하십시오.
-
-
두 JDM 서버를 모두 업그레이드한 후 새 GNF를 구성하기 전에 실행해야
commit synchronize
합니다. server1에서 새 GNF를 실행하고commit synchronize
생성하지 않으면 나중에 server0에서 server1로 수행할 수commit synchronize
없습니다. -
두 JDM을 모두 업그레이드해야 합니다.
참고 항목:
-
-
Podman 기반 배포를 지원하도록 JDM 업그레이드(23.2R1)
Junos OS 릴리스 23.2R1부터 외부 서버 기반 Junos 노드 슬라이싱은 Pod Manager 도구(podman)를 사용하여 JDM(Juniper Device Manager) 구축을 지원합니다. RHEL(Red Hat® Enterprise Linux®) 9 이상 버전을 실행하는 서버만 podman을 지원합니다.
23.2R1 이전의 Junos 릴리스에서는 외부 서버 기반 Junos 노드 슬라이싱이 RHEL 7.3을 지원했으며, 이는 JDM을 구축하기 위해 libvirt의 lxc 드라이버(libvirt-lxc)를 제공했습니다.
JDM 업그레이드 중에 JDM 구성을 백업해야 하는 경우 먼저 디바이스에 Junos 버전 23.1R1 이상을 설치해야 합니다. JDM 구성(request system save state path
및 )을 백업 및 request system restore state path
복원하는 명령은 Junos 버전 23.1R1 이상에서만 사용할 수 있기 때문입니다.
libvirt-lxc 기반 JDM을 podman 기반 버전으로 업그레이드하려면 두 서버 모두에서 아래 단계를 수행합니다.
-
두 서버에서 JDM에 의해 생성된 임의의 MAC 접두사가 동일한지 확인합니다.
user@jdm>
show system random-mac-prefix all-servers
-
JDM 구성을 /host/tmp/ 폴더에 백업합니다.
user@jdm>
request system save state path /host/tmp/jdm-backup.tgz
Backup Done at:[/host/tmp/jdm-backup.tgz]이 단계는 JDM 구성 및 random-mac-prefix 값을 백업합니다. MAC 접두사는 비면허 게스트 네트워크 기능(GNF)과 연관된 MAC 주소의 일부를 구성합니다.
-
각 서버에서 JDM을 제거합니다. 자세한 내용은 Junos 노드 슬라이싱 관리를 참조하십시오.
-
호스트 OS를 RHEL 9로 업그레이드합니다.
-
podman 기반 JDM을 설치합니다. 이것은 일반적인 설치 프로세스입니다. JDM을 설치하려면 RHEL(외부 서버 모델)을 실행하는 x86 서버에 JDM RPM 패키지 설치에 제공된 단계를 사용합니다.
-
JDM 백업을 복원합니다.
user@jdm>
request system restore state path /host/tmp/jdm-backup.tgz
Backup Restored from:[/host/tmp/jdm-backup.tgz] -
두 서버에서 위의 단계를 수행한 후 두 서버에서 JDM에 의해 생성된 임의의 MAC 접두사가 동일한지 확인합니다.
user@jdm>
show system random-mac-prefix all-servers
JDM을 libvirt-lxc 기반 버전에서 podman 기반 버전으로 업그레이드하기 전에는 GNF를 백업할 수 없습니다. JDM을 업그레이드한 후 GNF를 새로 구성해야 합니다.
섀시 내 모델을 위한 JDM 업그레이드
-
두 라우팅 엔진의 BSYS 인스턴스에서 다음 작업을 수행하여 JDM을 업그레이드합니다.
-
새 JDM RPM 패키지를 디렉터리(예: / var/tmp)에 복사합니다.
-
다음 명령을 실행하여 JDM을 중지합니다.
root@router>
request vmhost jdm stop
-
다음 예제에 표시된 명령을 사용하여 섀시 내 Junos 노드 슬라이싱을 위한 JDM RPM 패키지를 설치합니다.
root@router>
request vmhost jdm add jns-jdm-vmhost-18.3-20180930.0.x86_64.rpm
참고:JDM 업그레이드는 실행 중인 GNF에 영향을 주지 않습니다.
-
섀시 내 모델에 맞게 JDM을 업그레이드하기 위해 기존 JDM 소프트웨어를 제거할 필요가 없습니다. 기존 JDM을 제거하면 게스트 네트워크 기능(GNF)에 영향을 미칠 수 있습니다.
GNF 및 BSYS 업그레이드
GNF 및 BSYS 패키지는 독립형 MX 시리즈 라우터에서 Junos OS를 업그레이드하는 것과 동일한 방식으로 업그레이드할 수 있습니다.
업그레이드를 수행할 때 모든 GNF가 온라인 상태인지 확인합니다. 이는 GNF 및 BSYS 업그레이드 프로세스 모두 다중 버전 검사(이 가이드의 뒷부분에서 설명)를 트리거하고, 모든 GNF는 다중 버전 확인 단계에서 온라인 상태여야 하며, 실패하면 업그레이드가 종료되기 때문입니다. GNF가 종료된 상태로 유지되는 경우 BSYS CLI에서 구성을 비활성화해야 하며, 이 경우 특정 GNF에 대한 멀티버전 검사를 건너뜁니다.
force
JDM CLI 명령을 request virtual-network-functions vnf-name add-image new-image-name force
사용하여 기존 GNF 이미지를 새 이미지로 덮어쓸 수 있는 옵션도 사용할 수 있습니다. 이는 GNF 이미지가 부팅되지 않는 드문 상황에서 유용할 수 있습니다. 예를 들어, Ctrl-C를 눌러 진행 중이던 이전 add-image
작업을 갑자기 종료한 경우 옵션을 사용하여 force
정리를 수행할 수도 있습니다(예: request virtual-network-functions vnf-name delete-image image-name force
).
WRL 9 기반 VM 호스트를 지원하도록 JDM 업그레이드 - 섀시 내 모델
라우팅 엔진에서 Junos OS 19.3R1 이상을 실행하려면 JDM을 19.3R1 이상으로 업그레이드해야 합니다.
19.3R1 이전에 릴리스된 Junos OS 버전은 WRL6 버전의 VM 호스트 소프트웨어를 사용합니다. Junos OS 19.3R1은 WRL9 버전의 VM 호스트 소프트웨어를 제공합니다. VM 호스트 버전을 확인하려면 BSYS VM에서 Junos CLI 명령을 show vmhost version
사용합니다.
다음 단계를 사용하여 JDM을 업그레이드합니다.
-
각 GNF에서 라우팅 엔진 1(re1)에서 실행되는 백업 GNF에 기본 역할을 할당합니다.
root@router>
request chassis routing-engine master switch no-confirm
-
re0에서 먼저 JDM에서 GNF를 중지한 다음 BSYS에서 JDM 자체를 중지합니다.
root@jdm>
request virtual-network-functions stop gnf-name
root@router>request vmhost jdm stop
-
re0 VM 호스트 버전이 Junos OS 19.3R1 이상인지 확인합니다. VM 호스트 버전을 확인하려면 Junos CLI 명령을
show vmhost version
사용합니다.다음 Junos CLI를 사용하여 VM 호스트 소프트웨어를 업그레이드할 수 있습니다.
root@router>
request vmhost software add package-name
root@router>request vmhost reboot
자세한 내용은 VM 호스트의 설치, 업그레이드, 백업 및 복구를 참조하세요.
-
재부팅 후 re0이 백업되면 새 JDM RPM 패키지(19.3R1 이상)를 디렉토리(예: /var/tmp)에 복사합니다.
-
re0에 새 JDM RPM 패키지를 설치한 다음 JDM을 시작합니다.
root@router>
request vmhost jdm add package-name
root@router>request vmhost jdm start
re0의 GNF는 이 단계 후에 자동으로 시작됩니다.
-
라우팅 엔진 1(r1)에서 1단계부터 5단계까지 반복합니다.
-
request server authenticate-peer-server
두 라우팅 엔진의 JDM에서 명령을 실행합니다.user@jdm>
request server authenticate-peer-server
-
re0 JDM에서 구성한
set system commit synchronize
다음 적용합니다commit
.user@jdm#
set system commit synchronize
user@jdm#commit synchronize
JDM 소프트웨어 버전 19.3R1은 Junos OS 버전 19.3R1 뿐만 아니라 19.3R1 이전의 Junos OS 버전에서도 실행할 수 있습니다.
또한보십시오
외부 서버 모델에 대한 JDM 다운그레이드
단일 서버 기반 Junos 노드 슬라이싱 설정에 설치된 JDM(Juniper Device Manager)은 다운그레이드할 수 없습니다.
다음 단계를 사용하여 JDM을 다운그레이드합니다.
섀시 내 모델에 대한 JDM 다운그레이드
단일 라우팅 엔진 기반 Junos 노드 슬라이싱 설정에 설치된 JDM(Juniper Device Manager)은 다운그레이드할 수 없습니다.
다음 단계를 사용하여 JDM을 다운그레이드합니다.
이제 JDM은 Junos OS 버전 18.3R1과 함께 제공됩니다.
통합 ISSU 지원
Junos Node Slicing은 또한 통합된 ISSU(In-Service Software Upgrade)를 지원하므로 컨트롤 플레인에서 중단 없이 트래픽 중단을 최소화하면서 두 개의 서로 다른 Junos OS 버전 간에 업그레이드할 수 있습니다. BSYS와 GNF에서 별도로 통합 ISSU를 수행할 수 있습니다. 또한 다른 GNF에 영향을 주지 않고 각 GNF에서 독립적으로 통합 ISSU를 실행할 수 있습니다. 통합 ISSU 프로세스 이해도 참조하십시오.
-
멀티버전 소프트웨어 지원 제한(예: 버전 편차 제한)은 통합 ISSU 업그레이드에도 적용됩니다.
- Junos OS 릴리스 21.4R1부터 SLC(서브 라인 카드)를 갖춘 MPC11E는 제로 패킷 손실 모드에서 ISSU를 지원합니다. 이전 버전의 Junos OS를 실행 중인 경우, SLC가 있는 Junos 노드 슬라이싱 설정에서 ISSU를 수행하려고 시도하지 마십시오.
멀티버전 소프트웨어 상호 운용성 관리
Junos Node Slicing은 멀티버전 소프트웨어 상호 운용성을 지원합니다. 그러나 소프트웨어 버전 간에 비호환성이 있는 경우 소프트웨어 업그레이드 프로세스 중 또는 GNF 또는 FRU가 온라인 상태가 될 때 경고 메시지가 나타납니다. 사소한 비호환성이 발생하면 이를 수락하고 계속 진행할 수 있습니다. 중대한 비호환성이 있는 경우 프로세스를 종료하거나 옵션을 사용하여 force
비호환성을 수락하고 계속 진행해야 합니다.
vmhost 소프트웨어 업그레이드 force
의 경우 옵션을 사용할 수 없습니다. 따라서 GNF가 오프라인 상태이거나 설치 중인 소프트웨어와 호환되지 않아 멀티버전 검사가 종료되는 경우 소프트웨어 업그레이드 중에 해당 GNF를 비활성화한 다음 업그레이드가 끝나면 다시 활성화해야 합니다.
다음은 소프트웨어 업그레이드 중에 비호환성이 감지될 경우 나타나는 샘플 메시지입니다.
Sample alert message indicating a minor incompatibility:
user@router> request system software add /var/tmp/junos-install-mx-x86-64-17.4-20170703_dev_common.0.tgz
Starting Multiversion compatibility checks for package /var/tmp/junos-install-mx-x86-64-17.4-20170703_dev_common.0.tgz
Starting compatibility checks...
--------------------------------------------------------------------------------
System Anomalies:
--------------------------------------------------------------------------------
Ano-ID ACTION MESSAGE
--------------------------------------------------------------------------------
100 WARN <sample system incompatibility 1>
Accept incompatibility? [yes,no] (no) yes
103 WARN <sample system incompatibility 2>
Accept incompatibility? [yes,no] (no) yes
--------------------------------------------------------------------------------
CFG Anomalies for: set snmp interface
--------------------------------------------------------------------------------
FRU-ID Ano-ID ACTION MESSAGE
--------------------------------------------------------------------------------
NONE 102 WARN <sample config incompatibility 1>
Accept incompatibility? [yes,no] (no) yes
NONE 105 WARN <sample config incompatibility 2>
Accept incompatibility? [yes,no] (no) yes
--------------------------------------------------------------------------------
FRU Anomalies:
--------------------------------------------------------------------------------
FRU-ID Ano-ID ACTION MESSAGE
--------------------------------------------------------------------------------
0xaa0b 100 WARN <sample FRU incompatibility 1>
Accept incompatibility? [yes,no] (no) yes
0xbb0b 101 WARN <sample FRU incompatibility 2>
Accept incompatibility? [yes,no] (no) yes
Compatibility Checks done... OK
NOTICE: Validating configuration against junos-install-mx-x86-64-17.4-20170703_dev_common.0.tgz.
NOTICE: Use the 'no-validate' option to skip this if desired.
Verified junos-install-mx-x86-64-17.4-20170703_dev_common.0 signed by PackageDevelopmentEc_2017 method ECDSA256+SHA256
Sample alert message indicating a major incompatibility:
user@router> request system software add /var/tmp/junos-install-mx-x86-64-17.4I20170713_0718.tgz
Starting Multiversion compatibility checks for package /var/tmp/junos-install-mx-x86-64-17.4I20170713_0718.tgz
Starting compatibility checks...
--------------------------------------------------------------------------------
System Anomalies:
--------------------------------------------------------------------------------
Ano-ID ACTION MESSAGE
--------------------------------------------------------------------------------
1677721600 ABORT <sample system incompatibility 1>
error: Junos-Node-Slicing multi-version checks returned abort for package /var/tmp/junos-install-mx-x86-64-17.4I20170713_0718.tgz
Sample output showing how to use the 'force' option to proceed with an upgrade:
user@router> request system software add /var/tmp/junos-install-mx-x86-64-17.4I20170713_0718.tgz force
NOTICE: Validating configuration against junos-install-mx-x86-64-17.4I20170713_0718.tgz.
NOTICE: Use the 'no-validate' option to skip this if desired.
Verified junos-install-mx-x86-64-17.4I20170713_0718 signed by PackageDevelopmentEc_2017 method ECDSA256+SHA256
Verified manifest signed by PackageDevelopmentEc_2017 method ECDSA256+SHA256
Checking PIC combinations
Adding junos-x86-64-17.4I20170713_0718...
소프트웨어 비호환성 경보 보기
GNF 또는 BSYS의 소프트웨어 업데이트 후 GNF와 BSYS 간에 소프트웨어 비호환성이 존재하는 경우 섀시 알람으로 발생합니다. 명령을 사용하여 비호환성 알람 정보를 볼 수 있습니다 show chassis alarms
. 명령을 사용하여 비호환성에 대한 세부 정보를 추가로 볼 수 있습니다 show system anomalies
. 자세한 내용은 소프트웨어 버전 간 비호환성 보기를 참조하십시오.
BSYS에서 업그레이드가 수행되더라도 경보는 GNF에만 나타납니다. 다음과 같은 유형의 알람이 발생할 수 있습니다.
System Noncompatibility with BSYS(BSYS와의 시스템 비호환성) - 이것은 주요 경보입니다. BSYS와 GNF 소프트웨어 버전 간의 비호환성으로 인해 GNF가 오프라인 상태가 될 때 나타납니다.
BSYS와의 기능 비호환성 - 이것은 사소한 경보입니다. 이는 BSYS와 GNF 소프트웨어 버전 간에 약간의 비호환성이 있음을 나타냅니다. 이로 인해 GNF가 오프라인으로 전환되지는 않습니다.
소프트웨어 버전 간 비호환성 보기
BSYS에서 소프트웨어 비호환성을 보려면 다음 예와 같이 CLI를 사용합니다.
user@router> show system anomalies gnf-id 4 system
GNF에서 소프트웨어 비호환성을 보려면 다음 예와 같이 CLI를 사용합니다.
user@router> show system anomalies system
CLI에 표시된 대로 BSYS의 비호환성을 보는 동안 GNF ID를 지정해야 합니다.
앞의 예제에서는 시스템 수준의 비호환성을 보여 줍니다.
fru
또는 옵션을 사용하여 FRU 또는config
기능 수준 비호환성을 볼 수 있습니다.
외부 서버 다시 시작
하드웨어 또는 호스트 OS 업그레이드 및 장애 격리와 같은 서버 유지 보수 활동을 하려면 Junos 노드 슬라이싱에 사용되는 외부 서버를 다시 시작해야 할 수 있습니다. 다음 절차에 따라 서버를 다시 시작합니다.
서버 재부팅 후 JDM 및 구성된 GNF가 자동으로 실행되기 시작합니다.
서버를 교체하는 경우 운영 서버 쌍의 하드웨어 구성이 계속 유사하거나 동일한지 확인하십시오. 교체 중에 서버 쌍이 일시적으로 유사하지 않게 되는 경우(서버를 순차적으로 교체하는 경우일 수 있음) 이 기간 동안 GRES 및 NSR을 비활성화하고 두 서버가 다시 한 번 유사한 경우에만 다시 활성화하는 것이 좋습니다.
외부 서버에서 호스트 OS 업데이트
외부 서버에서 호스트 OS를 업데이트하기 전에 먼저 외부 서버 다시 시작에 설명된 대로 해당 서버에서 GNF 및 JDM을 중지해야 합니다.
호스트 OS 업데이트 후 Intel X710 NIC를 사용하는 경우 사용 중인 X710 NIC 드라이버의 버전이 x86 서버용 Intel X710 NIC 드라이버 업데이트에 설명된 대로 계속 최신 버전인지 확인합니다.
호스트 OS에 보안 업데이트 적용
호스트 OS에는 때때로 보안 업데이트가 필요합니다. 이 섹션에서는 Red Hat(RHEL) OS를 사용하여 호스트 OS에 보안 업데이트를 적용하는 단계를 중점적으로 설명합니다.
Junos Node Slicing은 RHEL 9를 지원합니다.
호스트 OS를 업데이트하기 전에 Red Hat 서브스크립션 관리자가 버전 9로 설정되어 있고 Red Hat 서브스크립션 서비스에 EUS(Extended Update Support)가 포함되어 있는지 확인합니다.
명령을 subscription-manager release --show
사용하여 릴리스가 9로 설정되었는지 확인할 수 있습니다. 그렇지 않은 경우 명령을 subscription-manager release --set=9
사용하여 릴리스를 9로 설정할 수 있습니다.
Red Hat 서브스크립션 관리자가 버전 9로 설정되어 있는지 확인해야 합니다.
Red Hat의 확장 업데이트 지원을 통해 지정된 릴리스 내에서 패치 및 보안 업데이트를 적용할 수 있습니다. RHEL의 확장 업데이트 지원의 허용된 사용은 RHEL 지원 계약의 기능이며 이 섹션의 범위를 벗어납니다. 명령을 subscription-manager repos --list | grep rhel-7-server-eus-rpms
사용하여 RHEL 구독에 EUS(Extended Update Support)가 포함되어 있는지 확인할 수 있습니다 . EUS 지원은 기본적으로 사용하도록 설정되지 않습니다. 명령을 사용하여 EUS를 subscription-manager repos --enable rhel-7-server-eus-rpms
활성화할 수 있습니다.
호스트 OS 보안 업데이트를 적용하는 단계
호스트 OS에 보안 업데이트를 적용하려면 외부 x86 서버를 다시 부팅해야 할 수 있습니다. 외부 서버에서 호스트 OS 업데이트 주제를 참조하십시오.
호스트 OS 보안 업데이트가 새 커널 버전을 가져올 수도 있습니다. 호스트 OS 커널을 업데이트하면 Intel i40e 드라이버를 덮어써서 i40e 드라이버 최소 버전 요구 사항을 충족하지 않는 버전을 가져올 수도 있습니다. 그렇다면 최소 요구 사항을 충족하도록 i40e 드라이버를 업데이트해야 합니다. 자세한 내용은 x86 서버용 Intel X710 NIC 드라이버 업데이트를 참조하세요.
외부 x86 서버를 재부팅하기 전에 해당 서버에서 모든 GNF VM 및 JDM을 중지해야 합니다. 두 개의 외부 x86 서버가 있으므로 한 번에 하나의 서버를 업데이트하여 GNF 전달을 방해하지 않고 호스트 OS 보안 업데이트를 수행할 수 있습니다. 영향을 받는 서버에서 기본 라우팅 엔진을 이동하려면 GRES/NSR 기본 라우팅 엔진 전환이 필요합니다.
여기서는 각 GNF가 외부 x86 server1에서 실행되는 각 GNF re1
에 대한 백업 라우팅 엔진으로 라우팅 엔진 1(re1
)의 기본 동작으로 시작합니다.
모든 구성을 백업합니다.
호스트 OS 보안 업데이트 전에 외부 x86 서버에서 호스트 OS 커널 및 패키지 버전 보기를 수집합니다. 또한 i40e 드라이버와 Intel X710 펌웨어가 최소 요구 사항(버전: 2.4.10 및 버전: 18.5.17)을 충족하는지 확인합니다.
user@server#
cat /etc/redhat-release
user@server#uname -r
user@server#uname -a
user@server#rpm -q kernel
user@server#ethtool -i p3p1
-
RedHat Subscription Manager가 RHEL 9로 설정되어 있고 EUS 리포지토리가 활성화되어 있는지 확인합니다.
[user@server ~]#
subscription-manager version
[user@server ~]#subscription-manager repos --list | grep rhel-7-server-eus-rpms
모든 GNF가 에서
server0
기본 RE를 사용하고 있는지 확인합니다. 백업 라우팅 엔진이 켜져 있습니다re1
server1
. 먼저 백업 라우팅 엔진이 포함된 서버에서 호스트 OS 보안 업데이트를 수행합니다.user@router>
show chassis routing-engine
모든 GNF에서 이 명령을 실행하여 모든 GNF가 server0에 기본 라우팅 엔진을 가지고 있는지 확인합니다.
에 대한 요청을 통해서만 JDM CLI에서 모든 GNF VM을 중지합니다. 에는 모든 GNF에
stop
server1
대한 백업 라우팅 엔진이 포함되어 있습니다.server1
옵션을all-servers
사용하지 마십시오. 예제:user@jdm>
request virtual-network-functions gnf-a stop server 1
user@jdm>request virtual-network-functions gnf-b stop server 1
호스트 OS의 영향을 받는 서버에서 JDM을 중지합니다.
user@server#
jdm status
user@server#jdm stop
yum
보안 업데이트를 수행하고 서버를 다시 부팅합니다.user@server#
yum -y update -security
root@server#shutdown -r now
i40e 드라이버를 다시 로드하거나 컴파일합니다. 드라이버 업데이트에 대한 지침은 인텔 지원 페이지를 참조하십시오.
이제 에 대한
server1
호스트 OS 보안 업데이트가 완료되었습니다. GNF VM은 서버 재부팅 시 시작됩니다.보안 업데이트가 완료되면 서버가 재부팅되고 GNF가 백업된 후 다른 서버에서 이 작업을 반복합니다.
Ubuntu 컨테이너에 보안 패치 적용
JDM(Juniper Device Manager)의 기반이 되는 Ubuntu 컨테이너는 보안 패치를 수시로 적용해야 합니다.
JDM은 인터넷에 연결할 수 있어야 하며 JDM이 구성되어 있어야 name-server
합니다. 다음 JDM CLI 구성 명령문을 적용하여 다음을 지정합니다.name-server
root@jdm# set system name-server address
JDM의 Ubuntu 컨테이너 구성 요소에 보안 업데이트를 적용하려면 다음 단계를 사용합니다.