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

1단계: 업그레이드 전 검증

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

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

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

주의:

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

업그레이드된 Apstra 서버는 시간 여행 수정을 제외합니다. 이전 상태로 되돌리려면 이 백업이 필요합니다. Apstra 버전 간 레퍼런스 설계의 변경으로 인해 이전 상태를 사용할 수 없음
백업 /var/lib/aos/snapshot/<shapshot_name> 파일을 외부 위치로 복사합니다.
새 VM에 Apstra 서버에 필요한 서버 리소스가 있는지 확인합니다.

2단계: 새로운 Apstra 서버 구축

참고:

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

등록된 지원 사용자로서 Apstra VM 이미지를 다운로드 하고 새 Apstra 서버로 전송합니다.
새 IP 주소로 새 Apstra VM 이미지를 설치하고 구성합니다(동일하거나 새로운 FQDN을 사용할 수 있음).
오프박스 에이전트 및 IBA 프로브와 함께 Apstra 클러스터를 사용하는 경우 작업자 VMsudo bash aos_<aos_version>.run을 재사용하고 . 새 작업자 VM의 경우 이 단계를 건너뜁니다.

참고:
모든 VM을 교체하려면 업데이트된 Apstra 버전으로 새 VM 3개를 만듭니다. 하나는 컨트롤러로 지정하고 나머지는 작업자 노드로 지정합니다.
새 Apstra 서버에 대해 다음을 확인합니다.
- 이전 Apstra 서버에 대한 SSH 액세스.
- 시스템 에이전트에 대한 연결( 필수 통신 포트 참조).
- NTP, DNS, vSphere 서버 및 LDAP/TACACS+ 서버와 같은 외부 시스템에 액세스합니다.

3단계: 상태 가져오기

참고:

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

새 Apstra 서버에 사용자 관리자로 로그인합니다.
명령을 실행 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}유지하려면 . 예를 들면 다음과 같습니다. --disable-original-apstra-server keep
- 를 사용하여 --dry-run-connectivity-validation업그레이드하지 않고 업그레이드 전제 조건 검사를 실행합니다.
- 연결 검증 i를 건 --skip-connectivity-validation너뜁니다.
- 이전 Apstra 버전의 SSH 자격 증명이 새 버전보다 덜 엄격한 경우 업그레이드 실패를 방지하기 위해 데이터베이스 가져오기 중에 명령에 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에 적용됩니다. 업그레이드 후 변경하는 경우 Apstra GUI(Platform > Apstra Cluster > Nodes)에서 작업자 VM의 SSH 암호를 업데이트합니다.

참고:
청사진 및 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 업그레이드 요약에는 슈퍼스파인, 스파인, 리프, 리프 페어 및 액세스 스위치와 같은 디바이스 역할별 스파인별 정보가 표시됩니다. 전체 구성 대신 증분 구성이 적용된 경우 변경 사항에 대한 자세한 내용이 표시됩니다.
AOS 업그레이드: 대화형 메뉴를 사용하면 각 디바이스의 구성 변경 사항을 검토할 수 있습니다. 업그레이드의 새 구성이 기존 구성 요소와 충돌하지 않는지 확인합니다.
주의:

새로운 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: 대시보드에서 사용하지 않는 위젯을 제거합니다.
--iba-remove-probe-and-stage-tags: 프로브 및 스테이지에서 태그를 제거합니다.
--iba-number-non-unique-probe-labels: 고유하지 않은 프로브 레이블에 일련 번호를 추가합니다.
--iba-number-non-unique-dashboard-labels: 고유하지 않은 대시보드 레이블에 일련 번호를 추가합니다.
--iba-disable-probe-with-evpn-host-flap-count-service: evpn-host-flap-count 서비스를 사용하여 사전 정의되지 않은 프로브를 비활성화합니다.
--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 간 Apstra 업그레이드 중에는 5단계에서 이전 IP를 재사용하지 않는 한 Apstra IP 주소가 변경됩니다.

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

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

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

Apstra 서버 업그레이드를 시작하면 모드가 표준 에서 유지 관리 로 자동으로 전환됩니다. 유지 보수 모드는 오프박스 에이전트가 온라인으로 전환되는 것을 차단하고, 구성 푸시를 중지하며, 텔레메트리 풀을 중지합니다. 이전 버전으로 되돌리려면 새 서버를 종료합니다. 업그레이드를 완료하려면 모드를 다시 표준으로 전환합니다.

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

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

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

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

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

다중 상태 청사진(특히 5단계)을 실행하는 경우 에이전트를 단계적으로 업그레이드하십시오.

먼저 슈퍼스파인을 업그레이드합니다.
다음으로 스파인을 업그레이드합니다.
마지막으로 리프를 업그레이드합니다.

이 순서는 경로 헌팅 문제를 최소화합니다. 라우팅은 일시적으로 리프에서 스파인으로, 다시 다른 리프로, 그리고 다른 스파인으로 이동할 수 있습니다. 단계적 업그레이드는 이러한 위험을 줄입니다.

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

작업 상태가 진행 중으로 변경됩니다. 에이전트가 이전 버전의 Apstra 소프트웨어를 사용하는 경우 자동으로 새 버전으로 업그레이드됩니다. 그런 다음 서버에 연결하고 보류 중인 구성 변경 사항을 디바이스에 푸시합니다. 텔레메트리도 다시 시작되고 작업 상태가 SUCCESS로 변경됩니다.
블루프린트 대시보드의 Liveness 섹션에서 디바이스 이상이 없는지 확인합니다.

참고:
에이전트 업그레이드 후 이전 Apstra 버전으로 롤백하려면 이전 Apstra 버전으로 새 VM을 빌드하고 구성을 새 VM으로 복원합니다. 도움이 필요하면 주니퍼 기술 지원에 문의하십시오.

9단계: 기존 Apstra 서버 종료

이전 Apstra 서버를 종료하려면 다음 단계를 따르십시오.

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

다음 단계:

새 Apstra 버전과 호환되지 않는 경우 디바이스 NOS 버전을 적격 버전으로 업그레이드하십시오. 자세한 내용은 주니퍼 Apstra 사용자 가이드 를 참조하십시오.

이 페이지의 내용