새 VM에서 Apstra 업그레이드(VM-VM)

1단계: 업그레이드 전 유효성 검사

업그레이드 경로를 참조하여 지원되는 버전으로 업그레이드하고 있는지 확인합니다. Apstra GUI에서 현재 Apstra 버전을 찾으려면 왼쪽 탐색 메뉴의 왼쪽 상단 모서리에서 주니퍼 Apstra 로고 아래를 확인하십시오.
Apstra 서버에 관리자로 로그인합니다(예: Apstra 서버 IP 주소가 10.28.105.3인 경우 명령은 임ssh admin@10.28.105.3).

명령을 service aos status 실행하여 서버가 활성 상태이고 문제가 없는지 확인합니다.

데이터 플레인에 영향을 줄 수 있는 구성 렌더링 변경 사항에 대해서는 새로운 Apstra 버전 릴리스 노트를 확인하십시오.
각 청사진을 검토하여 모든 서비스 구성이 SUCCEEDED 상태인지 확인합니다. 필요한 경우 블루프린트에서 디바이스를 배포 취소하고 제거하여 보류 중이거나 실패한 서비스 구성을 해결합니다.
프로브 이상에 대한 각 청사진을 검토하고 가능한 한 많이 해결합니다. 남아 있는 이상 징후를 기록해 둡니다.
디바이스 모델 및 NOS 버전이 새로운 Apstra 버전에서 검증되었는지 확인하려면 Apstra 사용자 가이드(> 디바이스 > 적격 디바이스 및 NOS 버전 참조)를 참조하십시오. 필요에 따라 지원되는 버전 중 하나로 업그레이드하거나 다운그레이드합니다.
Junos 디바이스를 사용하는 경우 기본 구성에 필수 mgmt_junos 요소가 포함되어야 합니다 VRF입니다. 자세한 내용은 주니퍼 지원 기술 자료 문서 KB77094를 참조하십시오.

주의:

기본 구성에 VRF가 mgmt_junos 포함되어 있지 않으면 구축이 실패합니다.
디바이스 AAA 구성을 제거합니다. 디바이스를 업그레이드하는 동안 SSH 액세스를 위해 구성된 디바이스 에이전트 자격 증명이 필요합니다.
방화벽을 구성하는 데 사용되는 모든 구성 항목을 제거합니다. 디바이스에서 FW의 라우팅 엔진 필터를 사용하는 경우 새 컨트롤러 및 작업자 VM의 IP 주소를 포함하도록 업데이트해야 합니다.
디바이스 시스템 에이전트를 업그레이드하려면 Apstra가 에이전트 생성 시 구성된 자격 증명을 사용하여 모든 디바이스에 SSH를 제공할 수 있어야 합니다. Apstra GUI에서 이를 확인하려면 디바이스 > 매니지드 디바이스로 이동하여 확인할 디바이스의 확인란을 선택한 다음 에이전트 메뉴에서 확인 버튼을 클릭합니다. 모든 작업의 상태가 SUCCESS인지 확인합니다. 검사 작업이 실패하면 Apstra 업그레이드를 진행하기 전에 문제를 해결하십시오.
루트 사용자로 명령을 sudo aos_backup 실행하여 Apstra 서버를 백업합니다.
주의:

업그레이드된 Apstra 서버에는 Time Voyager 개정판이 포함되어 있지 않으므로 과거 상태로 되돌려야 하는 경우 이 백업이 필요합니다. Apstra 버전 간에 변경될 수 있는 레퍼런스 설계와의 긴밀한 결합으로 인해 이전 상태는 포함되지 않습니다.
백업 파일을 /var/lib/aos/snapshot/<shapshot_name> 외부 위치로 복사합니다.
새 VM에 Apstra 서버에 필요한 서버 리소스가 있는지 확인합니다.

2단계: 새 Apstra 서버 배포

메모:

이전 Apstra 서버에서 파일을 사용자 정의 /etc/aos/aos.conf 한 경우(예: 다른 네트워크 인터페이스를 사용하도록 필드를 업데이트 metadb 한 경우) 새 Apstra 서버 VM의 동일한 파일에 변경 사항을 다시 적용해야 합니다. 자동으로 마이그레이션되지 않습니다.

등록된 지원 사용자로서 주니퍼 지원 다운로드(for example, aos_server_5.0.0-63)에서 Apstra VM 이미지를 다운로드하여 새 Apstra 서버로 전송합니다.
새 IP 주소(동일하거나 새로운 FQDN을 사용할 수 있음)로 새 Apstra VM 이미지를 설치 및 구성합니다.
Apstra 클러스터(오프박스 에이전트, IBA 프로브)를 사용 중이고 작업자 VM을 재사용하려는 경우 를 실행하여 sudo bash aos_<aos_version>.run새 소프트웨어를 설치합니다. 새 작업자 VM을 사용하는 경우 이 단계를 건너뜁니다.

메모:
모든 VM 교체의 예: 컨트롤러 1개와 작업자 노드 2개가 있고 이를 모두 새 VM으로 업그레이드하려는 경우 새 Apstra 버전으로 VM 3개를 생성하고 그 중 하나를 컨트롤러로 지정합니다.
새 Apstra 서버에 이전 Apstra 서버에 대한 SSH 액세스 권한이 있는지 확인합니다.
새 Apstra 서버가 시스템 에이전트에 연결할 수 있는지 확인합니다. (필수 구성 포트를 참조하십시오.)
새 Apstra 서버가 해당 외부 시스템(예: NTP, DNS, vSphere 서버, LDAP/TACACs+ 서버 등)에 연결할 수 있는지 확인합니다.

3단계: 상태 가져오기

주의:

새 VM 가져오기를 시작한 후 이전 Apstra 서버에 API/GUI 쓰기 작업을 수행하면 해당 변경 사항이 새 Apstra 서버에 복사되지 않습니다.

새 Apstra 서버에 사용자 admin으로 로그인합니다.
sudo aos_import_state 명령을 실행하여 이전 서버에서 SysDB를 가져오고, 필요한 번역을 적용하고, 구성을 가져옵니다. 해당하는 경우 다음 인수를 포함합니다.
- --ip-address <old-apstra-server-ip>
관리자 사용자 이름을 입력합니다.
- --username <admin-username>
- 새 작업자 노드 IP 주소가 있는 Apstra 클러스터의 경우 다음을 포함합니다. --cluster-node-address-mapping <old-node-ip> <new-node-ip>
- 기존 Apstra 서버를 유지하려면 명령에 인수 --disable-original-apstra-server {prompt,disable,keep} 를 keep 추가합니다.
  
  예를 들어: --disable-original-apstra-server keep
- 실제 업그레이드를 실행하지 않고 업그레이드 전제 조건 검사를 실행하려면 다음을 사용합니다.--dry-run-connectivity-validation
- 연결 유효성 검사를 확인하지 않으려면 다음을 포함합니다. --skip-connectivity-validation
- 이전 Apstra 버전의 SSH 자격 증명이 새 Apstra 버전의 요구 사항만큼 엄격하지 않은 경우 데이터베이스를 새 Apstra 버전으로 가져올 때 명령에 인수 aos_import_state 를 추가해야 --override-cluster-node-credentials 합니다. 그렇지 않으면 업그레이드가 실패합니다.
- 구성된 관리 VRF 없이 Junos 디바이스가 있을 때 실패 없는 업그레이드 프로세스를 수행하려면 인수를 --skip-junos-mgmt-vrf-check 추가합니다.
예제 명령: 동일한 작업자 노드가 있는 단일 VM 또는 Apstra 클러스터
예제 명령: 새 작업자 노드가 있는 Apstra 클러스터
위의 10.28.105.4 예에서 및 10.28.105.7 은(는) 이전 작업자 노드 IP 주소이고, 10.28.105.6 은(는 10.28.105.8 ) 새 작업자 노드 IP 주소입니다.
데이터베이스를 가져오려면 루트가 필요하므로 원격 Apstra VM에 대한 SSH 암호와 루트 암호를 입력하라는 메시지가 표시됩니다.

메모:
Apstra 클러스터를 업그레이드할 때 이전 컨트롤러, 이전 작업자 및 새 작업자의 SSH 암호가 동일해야 합니다. 그렇지 않으면 업그레이드가 인증에 실패합니다. 위의 예에서 '원격 AOS VM에 대한 SSH 암호'에 입력한 암호는 원격 컨트롤러, 이전 작업자 및 새 작업자 VM에 사용됩니다(AOS-27351).

업그레이드 후 작업자 VM의 SSH 암호를 변경하는 경우 Apstra GUI(플랫폼 > Apstra 클러스터 > 노드)에서도 작업자의 암호를 업데이트해야 합니다.

메모:
청사진 및 Apstra 서버 VM 리소스의 크기에 따라 가져오기를 완료하는 데 걸리는 시간이 결정됩니다. 데이터베이스 가져오기가 기본값(40분 또는 2400초)을 초과하면 작업이 '시간 초과'될 수 있습니다. 이 경우 명령을 사용하여 AOS_UPGRADE_DOCKER_EXEC_TIMEOUT 시간 제한 값을 높일 수 있습니다.

예를 들어 다음 명령은 시간 제한 이전의 시간을 2시간(7200초)으로 늘립니다.
admin@aos-server:~$ sudo AOS_UPGRADE_DOCKER_EXEC_TIMEOUT=7200 aos_import_state --ip-address 10.10.10.10 --username admin

업그레이드 스크립트는 업그레이드 중에 구성 변경을 수신할 패브릭 내 디바이스의 요약 보기를 제공합니다. 계속하기 전에 릴리스 노트 및 업그레이드 경로 문서를 읽어 보도록 권장하는 경고 메시지가 화면에 나타납니다. 릴리스 정보에는 구성 렌더링 변경 사항에 대한 범주가 포함되어 있습니다. 구성 렌더링 변경 사항은 상단에 명확하게 문서화되어 각 변경 사항이 네트워크에 미치는 영향을 설명합니다.
Apstra 업그레이드 요약에는 디바이스 역할(예: 슈퍼스파인, 스파인, 리프, 리프 페어, 액세스 스위치)별로 구분된 정보가 표시됩니다. 전체 구성 대신 증분 구성이 적용된 경우 변경 사항에 대한 자세한 내용이 표시됩니다.
요약을 검토한 후 을(를) 입력하여 q 요약을 종료합니다. AOS 업그레이드:각 디바이스의 정확한 컨피그레이션 변경 사항을 검토할 수 있는 대화형 메뉴가 나타납니다. configlet을 사용하는 경우 업그레이드에 의해 푸시된 새 구성이 기존 configlet과 충돌하지 않는지 확인합니다.
주의:

새로운 Apstra 릴리스의 Apstra 레퍼런스 설계는 구성 요소(Configlet)를 무효화하는 방식으로 변경되었을 수 있습니다. 예기치 않은 결과를 방지하려면 구성이 새로 렌더링된 구성과 충돌하지 않는지 확인합니다. 구성 집합(configlet)을 업데이트해야 하는 경우 업그레이드를 종료하고 구성 집합(configlet)을 업데이트한 다음 업그레이드를 다시 실행합니다.
보류 중인 변경 내용을 검토한 후 업그레이드를 계속하려면 을 입력합니다c.
업그레이드를 중지하려면 을(를) 입력하여 q 프로세스를 중단합니다. 이 시점에서 종료하고 나중에 업그레이드하기로 결정한 경우 프로세스를 처음부터 시작해야 합니다.

메모:
Apstra 업그레이드가 실패한 경우(또는 다른 오작동의 경우) 새 Apstra 서버를 정상적으로 종료하고 이전 Apstra 서버를 다시 시작하여 작업을 계속할 수 있습니다.

4단계: 인텐트 기반 분석의 상태 가져오기

메모:

Apstra 5.0.0부터는 더 이상 프로브 및 단계에 태그를 할당하거나 텔레메트리 서비스를 지원하지 evpn-host-flap-count 않습니다.

인텐트 기반 분석을 위한 위젯 또는 프로브를 제거하거나 비활성화하려면 명령에 다음 인수를 sudo aos_import_state 추가합니다.

대시보드에서 사용되지 않는 위젯을 제거하려면 인수를 --iba-remove-unused widgets 추가합니다.
Apstra 5.0.0부터는 더 이상 프로브와 단계에 태그를 할당하지 않습니다. 프로브 및 단계에서 태그를 제거하려면 인수를 --iba-remove-probe-and-stage-tags 추가합니다.
고유하지 않은 프로브 레이블에 일련 번호를 추가하려면 인수를 --iba-number-non-unique-probe-labels 추가합니다.
고유하지 않은 대시보드 레이블에 일련 번호를 추가하려면 인수를 --iba-number-non-unique-dashboard-labels 추가합니다.
Apstra 5.0.0부터는 이 evpn-host-flap-count 서비스가 더 이상 지원되지 않습니다. 이 서비스를 사용하는 사전 정의되지 않은 프로브를 비활성화하려면 인수를 --iba-disable-probe-with-evpn-host-flap-count-service 추가합니다.
대시보드 레이블과 해당 위젯 레이블에서 선행 및/또는 후행 공백을 제거하려면 인수를 --iba-strip-dashboard-labels-widget-labels 추가합니다.
프로브 레이블과 해당 프로세서 이름에서 선행 및/또는 후행 공백을 제거하려면 인수를 --iba-strip-probe-labels-processor-names 추가합니다.

5단계: 이전 VM의 IP 주소 유지(선택 사항)

이전 VM의 IP 주소를 유지하려면 작동 모드를 변경하고 디바이스의 에이전트를 업그레이드하기 전에 다음 추가 단계를 수행해야 합니다.

이전 VM을 종료하거나 IP 주소를 다른 주소로 변경하여 IP 주소를 해제합니다. 이는 중복된 IP 주소 문제를 방지하는 데 필요합니다.
CLI에서 새 VM의 Apstra 대화형 메뉴로 이동합니다.
네트워크를 클릭하여 IP 주소를 업데이트하고 다른 매개변수를 확인합니다.
새 IP 주소를 적용하려면 종료하기 전에 동일한 메뉴에서 또는 메뉴를 종료한 후 CLI에서 네트워크 서비스를 다시 시작합니다.

6단계: Apstra 업그레이드 후 플로우 구성에서 Apstra IP 수정(원래 IP를 재사용하지 않는 경우)

VM-to-VM으로 Apstra를 업그레이드하는 동안 5단계에서 이전 IP를 재사용하지 않는 한 Apstra IP 주소가 변경됩니다.

IP 주소가 변경되면 다음과 같이 Apstra Flow 구성 요소를 업데이트하여 새 IP를 캡처합니다.

SSH를 통해 Apstra Flow CLI에 연결합니다(기본 자격 증명은 apstra/apstra).
을(를) 엽니다/etc/juniper/flowcoll.yml.
EF_JUNIPER_APSTRA_API_ADDRESS 필드를 새 IP 주소로 수정합니다.
실행 sudo systemctl restart flowcoll.service.

7단계: 작동 모드를 정상으로 변경

Apstra 서버 업그레이드를 시작하면 운영 모드가 Normal(일반 )에서 Maintenance(유지보수 )로 자동 변경됩니다. 유지 관리 모드는 오프박스 에이전트가 조기에 온라인 상태가 되는 것을 방지합니다. 구성이 푸시되지 않고 텔레메트리가 풀링되지 않습니다. 이 시점에서 업그레이드하지 않고 이전 Apstra 버전을 계속 사용하기로 결정한 경우 새 Apstra 서버를 종료하면 됩니다. 업그레이드를 완료하기로 결정한 경우 모드를 다시 표준으로 변경합니다.

Apstra GUI에 로그인합니다.
보류 중인 서비스 구성 변경 내용을 보려면 청사진의 대시보드로 이동하고 보류 중을 클릭하여 영향을 받는 디바이스를 확인합니다.
왼쪽 탐색 메뉴에서 Platform > Apstra Cluster > Cluster Management로 이동합니다.
Change Operation Mode(작동 모드 변경) 버튼을 클릭하고 Normal(일반)을 선택한 다음 Update(업데이트)를 클릭합니다. 컨트롤러 또는 작업자 VM에 있는 모든 오프박스 에이전트는 자동으로 온라인 상태가 되어 디바이스를 다시 연결하고 보류 중인 구성 변경 내용을 푸시합니다. 잠시 후 대시보드의 일시적인 이상이 해결되고 서비스 구성 섹션에 작업이 성공한 것으로 표시됩니다.

또한 모든 페이지의 왼쪽 하단 섹션에서 클러스터 관리 페이지에 액세스할 수 있습니다. 여기에서 색상을 기반으로 지속적인 플랫폼 상태 가시성을 확보할 수 있습니다.

왼쪽 탐색 메뉴 하단에서 점 중 하나를 클릭한 다음 작동 모드를 클릭하여 클러스터 관리로 이동합니다. Change Operation Mode(작동 모드 변경 ) 버튼을 클릭하고 Normal(일반)을 선택한 다음 Update(업데이트)를 클릭합니다.

8단계: 온박스 에이전트 업그레이드

Apstra 서버와 온박스 에이전트는 동일한 Apstra 버전을 실행해야 합니다. 버전이 다르면 에이전트가 Apstra 서버에 연결되지 않습니다.

다중 상태 블루프린트, 특히 5단계 블루프린트를 실행하는 경우 에이전트를 단계적으로 업그레이드하는 것이 좋습니다. 먼저 슈퍼스핀, 스파인, 리프 순으로 업그레이드합니다. 경로 헌팅을 위해 이 순서를 사용하는 것이 좋습니다. 모든 것을 스파인으로, 또는 스파인에서 슈퍼스파인으로 라우팅하는 대신, 라우팅이 일시적으로 리프에서 스파인으로 다시 다른 리프로 이동하고 다시 다른 스파인으로 돌아갈 수 있습니다. 이러한 일이 발생할 가능성을 최소화하려면 장치를 단계적으로 업그레이드하는 것이 좋습니다.

Apstra GUI에 사용자 관리자로 로그인합니다.
왼쪽 탐색 메뉴에서 디바이스 > 매니지드 디바이스로 이동하고 업그레이드할 디바이스(한 번에 최대 100개 디바이스)의 확인란을 선택합니다. 여러 온박스 에이전트를 동시에 업그레이드할 수 있지만 디바이스 업그레이드 순서가 중요합니다.
- 먼저 슈퍼스파인용 에이전트를 업그레이드합니다.
- 두 번째로 스파인용 에이전트를 업그레이드합니다.
- 리프용 에이전트 업그레이드 세 번째.
하나 이상의 디바이스를 선택하면 디바이스 및 에이전트 메뉴가 테이블 위에 나타납니다.
설치 버튼을 클릭하여 설치 프로세스를 시작합니다.

작업 상태가 IN PROGRESS로 변경됩니다. 에이전트가 이전 버전의 Apstra 소프트웨어를 사용하는 경우 자동으로 새 버전으로 업그레이드됩니다. 그런 다음 서버에 연결하고 보류 중인 구성 변경 사항을 디바이스에 푸시합니다. 또한 원격 분석이 다시 시작되고 작업 상태가 성공으로 변경됩니다.
블루프린트 대시보드의 활동성 섹션에서 디바이스 이상이 없는지 확인합니다.

메모:
에이전트 업그레이드를 시작한 후 이전 Apstra 버전으로 롤백해야 하는 경우 이전 Apstra 버전으로 새 VM을 빌드하고 해당 VM에 구성을 복원해야 합니다. 도움이 필요하면 주니퍼 기술 지원에 문의하십시오.

9단계: 기존 Apstra 서버 종료

구성에 따라 새 Apstra 서버 IP/FQDN을 사용하도록 DNS 항목을 업데이트합니다.
Apstra 서버에 프록시를 사용하는 경우 프록시가 새 Apstra 서버를 가리키는지 확인합니다.
기존 Apstra 서버를 정상적으로 종료합니다. 이전 Apstra 서버를 종료할지 묻는 메시지가 표시됩니다. '예service aos stop'라고 응답하면 이전 Apstra 서버를 종료하라는 명령이 자동으로 실행됩니다.
Apstra 클러스터를 업그레이드하고 작업자 노드를 새 VM으로 교체한 경우 이전 작업자 VM도 종료합니다.

다음 단계:

디바이스의 NOS 버전이 새로운 Apstra 버전에서 검증되지 않은 경우 적격 버전으로 업그레이드하십시오. (자세한 내용은 주니퍼 Apstra 사용자 가이드를 참조하십시오.)

이 페이지 내용