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

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

업그레이드 경로를 참조하여 지원되는 버전으로 업그레이드하고 있는지 확인합니다. (Apstra GUI의 플랫폼 > 정보로 이동하여 현재 Apstra 버전을 찾을 수 있습니다. Apstra 버전 4.2.1부터 Apstra 버전은 GUI의 왼쪽 탐색 메뉴에서도 주니퍼 Apstra 로고 아래에 표시됩니다.)
관리자로 Apstra 서버에 로그인합니다(예: Apstra 서버 IP 주소가 10.28.105.3인 경우 명령은 다음과 같습니다). ssh admin@10.28.105.3

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

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

주의:

원래 구성에 VRF가 mgmt_junos 포함되어 있지 않으면 배포가 실패합니다.
디바이스 AAA 구성을 제거합니다. 디바이스를 업그레이드하는 동안 SSH 액세스를 위해 구성된 디바이스 에이전트 자격 증명이 필요합니다.
방화벽을 구성하는 데 사용된 모든 구성을 제거합니다. 디바이스에서 FW의 라우팅 엔진 필터를 사용하는 경우 새 컨트롤러 및 작업자 VM의 IP 주소를 포함하도록 업데이트해야 합니다.
디바이스 시스템 에이전트를 업그레이드하려면 Apstra가 에이전트 생성 시 구성된 자격 증명을 사용하여 모든 디바이스에 SSH를 제공할 수 있어야 합니다. Apstra GUI에서 이를 확인하려면 Devices > Agents로 이동하여 확인할 디바이스의 확인란을 선택한 다음 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의 동일한 파일에 변경 사항을 다시 적용해야 합니다. 자동으로 마이그레이션되지 않습니다.

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

메모:
모든 VM 교체의 예: 컨트롤러와 2개의 작업자 노드가 있고 이들 모두를 새 VM으로 업그레이드하려는 경우 새로운 Apstra 버전으로 3개의 VM을 생성하고 그 중 하나를 컨트롤러로 지정합니다.
새 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>
- 실제 업그레이드를 실행하지 않고 업그레이드 전제 조건 검사를 실행하려면 다음을 사용합니다.--dry-run-connectivity-validation
- 연결 유효성 검사를 확인하지 않으려면 다음을 포함합니다. --skip-connectivity-validation
- 이전 Apstra 버전의 SSH 자격 증명이 새 Apstra 버전의 요구 사항만큼 엄격하지 않은 경우 데이터베이스를 새 Apstra 버전으로 가져올 때 명령에 인수 aos_import_state 를 추가해야 --override-cluster-node-credentials 합니다. 그렇지 않으면 업그레이드가 실패합니다.
예제 명령: 동일한 작업자 노드가 있는 단일 VM 또는 Apstra 클러스터
예제 명령: 새 작업자 노드가 있는 Apstra 클러스터
위의 예에서 및 10.28.105.7 은(는) 10.28.105.4 이전 작업자 노드 IP 주소이고, 은(는10.28.105.8) 10.28.105.6 새 작업자 노드 IP 주소입니다.
Root는 데이터베이스를 임포트하는 데 필요하므로 원격 Apstra VM에 대한 SSH 비밀번호와 루트 비밀번호를 입력하라는 메시지가 표시됩니다.

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

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

메모:
청사진 크기와 Apstra 서버 VM 리소스에 따라 가져오기를 완료하는 데 걸리는 시간이 결정됩니다. 데이터베이스 가져오기가 기본값을 초과하면 작업이 '시간 초과'될 수 있습니다. (Apstra 4.1.2의 기본값은 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 버전 4.1.2부터는 계속하기 전에 릴리스 노트 및 업그레이드 경로 문서를 읽어 보라는 경고가 화면에 나타납니다. 릴리스 노트에는 Apstra 버전 4.1.2부터 구성 렌더링 변경에 대한 카테고리가 포함되어 있습니다. 구성 렌더링 변경 사항은 각 변경 사항이 네트워크에 미치는 영향을 설명하는 상단에 명확하게 문서화되어 있습니다.
Apstra 버전 4.0.1부터 Apstra 업그레이드 요약 에는 디바이스 역할(예: 슈퍼스파인, 스파인, 리프, 리프 페어, 액세스 스위치)별로 구분된 정보가 표시됩니다. 전체 구성 대신 증분 구성을 적용한 경우 변경 사항에 대한 자세한 정보가 표시됩니다.
요약을 검토한 후 를 입력하여 q 요약을 종료합니다. AOS 업그레이드: 대화형 메뉴가 나타나며, 여기에서 각 디바이스의 정확한 구성 변경 사항을 검토할 수 있습니다. 구성 요소(configlet)를 사용하는 경우 업그레이드에 의해 푸시된 새 구성이 기존 구성 요소(configlet)와 충돌하지 않는지 확인합니다.
주의:

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

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

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

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

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

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

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

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

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

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

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

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

다중 상태 청사진, 특히 5단계를 실행하는 경우 에이전트를 단계별로 업그레이드하는 것이 좋습니다(먼저 슈퍼스파인을 업그레이드한 다음 스파인, 리프를 차례로 업그레이드). 경로 헌팅 때문에 이 순서를 사용하는 것이 좋습니다. 모든 것을 스파인으로 라우팅하거나 스파인에서 슈퍼스파인으로 라우팅하는 대신, 리프에서 스파인으로 일시적으로 다른 리프로 다시 내려갔다가 다시 다른 스파인으로 돌아가는 라우팅이 가능합니다. 이러한 일이 발생할 가능성을 최소화하려면 장치를 단계별로 업그레이드하는 것이 좋습니다.

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

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

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

7단계: 오래된 Apstra 서버 종료

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

다음 단계:

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

이 페이지의 내용