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

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

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

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

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

주의:

원래 구성에 VRF가 mgmt_junos 포함되어 있지 않으면 구축이 실패합니다.
Devive 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을 사용할 수 있음).
새 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 OS를 실행해야 합니다. 동일한 버전은 이전 작업자 노드가 새 작업자 노드에 1:1로 매핑되도록 합니다.
- 이전 Apstra 서버를 유지하려면 명령에 인수를 추가합니다keep.--disable-original-apstra-server {prompt,disable,keep}
  
  예를 들면 다음과 같습니다. --disable-original-apstra-server keep
- 실제 업그레이드를 실행하지 않고 업그레이드 전제 조건 검사를 실행하려면 다음을 사용합니다.--dry-run-precondition
- 연결 유효성 검사를 확인하지 않으려면 다음을 포함하십시오. --skip-connectivity-validation
- 이전 Apstra 버전의 SSH 자격 증명이 새 Apstra 버전의 요구 사항만큼 엄격하지 않은 경우 데이터베이스를 새 Apstra 버전으로 가져올 때 명령에 aos_import_state 인수를 추가 --override-cluster-node-credentials 해야 합니다. 그렇지 않으면 업그레이드가 실패합니다.
명령 예: 동일한 작업자 노드를 사용하는 단일 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 릴리스 정보 및 업그레이드 경로 문서를 읽어보라는 경고가 화면에 표시됩니다. 릴리스 노트에는 구성 렌더링 변경에 대한 범주가 포함되어 있습니다. 구성 렌더링 변경 사항은 각 변경 사항이 네트워크에 미치는 영향을 설명하는 상단에 명확하게 문서화되어 있습니다.
Apstra 업그레이드 요약은 디바이스 역할(예: 슈퍼스파인, 스파인, 리프, 리프 페어 및 액세스 스위치)별로 구분된 정보를 표시합니다. 전체 구성 대신 증분 구성이 적용된 경우 변경 사항에 대한 자세한 내용이 표시됩니다.
요약을 검토한 후 Enter 키를 눌러 q 요약을 종료합니다. AOS 업그레이드: 대화형 메뉴가 나타나며 각 디바이스의 정확한 구성 변경 사항을 검토할 수 있습니다. 구성 요소(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 간 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 버전을 계속 사용하기로 결정했다면 새 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 서버 IP/FQDN을 사용하도록 DNS 항목을 업데이트합니다.
Apstra 서버에 프록시를 사용하는 경우 새 Apstra 서버를 가리키는지 확인합니다.
기존 Apstra 서버를 정상적으로 종료합니다.

종료를 확인하면 명령이 자동으로 실행됩니다 service aos stop .
Apstra 클러스터를 업그레이드할 때 작업자 노드를 새 VM으로 교체한 경우 이전 작업자 VM을 종료합니다.

다음 단계:

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

이 페이지의 내용