업그레이드 위치

Apstra 서버를 업그레이드하려면 Apstra OS 관리자 사용자 권한과 Apstra 관리자 사용자 그룹 권한이 필요합니다.

업그레이드 전 검증(사전 준비)

지원되는 버전으로 업그레이드 중임을 확인합니다.
관리자로 Apstra 서버에 로그인합니다(예: Apstra 서버 IP 주소가 10.28.105.3인 경우 명령은 )ssh admin@10.28.105.3.
메모리 사용률이 50% 미만인지 확인하여 VM에 Apstra 소프트웨어의 두 버전을 동시에 탑재할 수 있는 충분한 메모리가 있는지 확인합니다. 명령을 free -h 실행하여 리소스를 확인합니다.
활용률이 > 50%인 경우 Apstra 서버를 Graceful Shutdown하고 리소스를 추가한 다음 Apstra 서버를 다시 시작합니다.

명령을 service aos status 실행하여 서버가 활성화되어 있고 아무런 문제가 없는지 확인합니다.

각 청사진을 검토하여 모든 서비스 구성이 성공했는지 확인합니다. 필요한 경우 블루프린트에서 디바이스를 구축하고 제거하여 보류 중이거나 실패한 서비스 구성을 해결합니다.
각 청사진을 검토하여 이상 징후를 조사하고 가능한 한 많이 해결합니다. 남은 이상 징후를 기록합니다.
자격을 갖춘 디바이스 및 NOS를 참조하여 디바이스의 NOS 버전이 새 Apstra 버전에서 자격을 갖추고 있는지 확인합니다. 필요에 따라 지원되는 버전 중 하나로 업그레이드 또는 다운그레이드할 수 있습니다.
모든 디바이스 AAA 구성을 제거합니다. 디바이스 업그레이드 중에는 SSH 액세스에 구성된 디바이스 에이전트 자격 증명이 필요합니다.
방화벽을 구성하는 데 사용되는 모든 구성을 제거합니다. 디바이스에서 FW의 라우팅 엔진 필터를 사용하는 경우 새 컨트롤러 및 작업자 VM의 IP 주소를 포함하도록 업데이트해야 합니다.
모든 디바이스(디바이스 > 에이전트)에 대해 Apstra System "확인" 작업을 실행하고 모든 작업 상태가 성공인지 확인합니다.

참고:
디바이스 시스템 에이전트를 업그레이드하려면 Apstra 소프트웨어는 디바이스 시스템 에이전트를 생성할 때 사용된 구성된 자격 증명을 사용하여 모든 디바이스에 SSH를 적용해야 합니다. 이러한 자격 증명을 사용하여 SSH를 확인하려면 모든 디바이스에 대해 Apstra System "확인" 작업을 실행하는 것이 좋습니다. 점검 작업이 실패하면 Apstra 업그레이드를 진행하기 전에 문제를 해결하십시오.

루트 사용자로서 명령을 sudo aos_backup 실행하여 Apstra 서버를 백업합니다.

참고:

에서 /var/lib/aos/snapshot/<shapshot_name> 외부 위치로 백업 파일을 복사합니다.

새로운 Apstra Server 구축(인플레이스)

Juniper 지원 다운로드(aos_4.0.1-1045.run.gz예: )에서 플랫폼용 Apstra 설치자 패키지를 다운로드하고 Apstra 서버로 전송합니다.

Apstra 설치 관리자 패키지의 지퍼를 해제합니다.

Apstra 클러스터(오프박스 에이전트, IBA 프로브)를 사용하는 경우 설치 관리자 패키지를 작업자 노드에도 다운로드하십시오. 나중에 작업자 노드를 업그레이드합니다.
관리자로 Apstra 서버에 로그인합니다.

명령을 실행합니다sudo bash aos_<aos_version>.run. 여기서 <aos_version> 은(는) 실행 파일의 버전입니다. 예를 들어, 버전이 4.0.1-1045 인 경우 아래와 같이 명령이 표시됩니다sudo bash aos_4.0.1-1045.run.

이 명령을 실행하면 이전 Apstra 버전이 감지되면 스크립트는 새로운 설치 모드 대신 업그레이드 모드로 들어갑니다. 새 Docker 컨테이너는 이전 버전의 Docker 컨테이너 옆에 설치됩니다. 스크립트는 이전 버전에서 데이터를 가져와 새 버전의 Apstra SysDB로 마이그레이션합니다.

업그레이드의 일부로 디바이스에 푸시될 구성 변경에 대한 요약이 표시됩니다.

Apstra 버전 4.0.1부터 Apstra 업그레이드 요약 은 디바이스 역할(예: 슈퍼스파인, 스파인, 리프, 리프 페어 및 액세스 스위치)으로 구분된 정보를 보여줍니다. 전체 구성 대신 점진적 구성이 적용된 경우 변경 사항에 대한 자세한 정보가 표시됩니다.

요약을 검토한 후 을(를) 입력 q 하여 요약을 종료합니다. AOS 업그레이드: 대화형 메뉴는 추가 정보에 액세스하고 업그레이드를 계속하거나 종료할 수 있는 곳에 표시됩니다.
주의:

새로운 Apstra 릴리스의 Apstra 참조 설계는 구성을 무효화하는 방식으로 변경되었을 수 있습니다. 예기치 않은 결과를 방지하려면 새롭게 렌더링된 구성과 구성이 충돌하지 않는지 확인합니다. 구성을 업데이트해야 하는 경우 업그레이드를 종료하고 구성을 업데이트한 다음 업그레이드를 다시 실행합니다.
보류 중인 변경 사항을 검토한 후 업그레이드를 계속하려면 을 입력하십시오c. 이전 Apstra 버전은 삭제되고 새 Apstra 버전이 서버에서 활성화됩니다. 업그레이드가 완료되면 Apstra GUI의 플랫폼 > 정보로 이동하여 버전을 확인합니다.

주의:

Apstra 서버 업그레이드는 획기적인 프로세스입니다. 인플레이스(동일한 VM)를 업그레이드하고 이 시점부터 업그레이드를 계속하면 업그레이드를 롤백할 수 없습니다. 이전 버전으로 돌아가는 유일한 방법은 새 VM을 이전 버전으로 다시 설치하고 이전에 만든 백업에서 데이터베이스를 복원하는 것입니다.
업그레이드를 중단하려면 을(를) 입력 q 하여 프로세스를 중단하십시오. 이 시점에서 종료하고 나중에 업그레이드를 결정한 경우, 시작부터 프로세스를 시작해야 합니다.
Apstra 클러스터를 사용하는 경우 작업자 노드가 Apstra 컨트롤러에서 연결을 끊고 FAILED 상태로 변경됩니다. 이 상태는 오프박스 에이전트와 작업자 노드에 있는 IBA 프로브 컨테이너를 사용할 수 없음을 의미합니다. 오프박스 에이전트가 관리하는 디바이스는 여전히 서비스 상태를 유지합니다. 나중에 에이전트를 업그레이드하면 Apstra 클러스터의 작업자 노드를 업그레이드하고 에이전트 및/또는 프로브를 사용할 수 있게 됩니다.

작동 모드를 정상으로 변경(인플레이스)

Apstra 서버 업그레이드를 시작할 때 작동 모드가 표준 에서 유지 보수 로 자동으로 변경됩니다. 업그레이드를 완료한 후에는 모드를 표준으로 수동으로 변경해야 합니다.

Apstra GUI의 왼쪽 탐색 메뉴에서 플랫폼 > Apstra cluster > 클러스터 관리로 이동합니다.
작업 모드 변경 단추를 클릭하고 정상을 선택한 다음 업데이트를 클릭합니다. 모드를 표준으로 변경할 때 구성된 모든 오프박스 에이전트가 활성화되지만, (다음 섹션에서) 모든 온박스 에이전트의 업그레이드를 시작해야 합니다.

또한 모든 페이지의 왼쪽 아래 섹션에서 Cluster Management 페이지에 액세스할 수 있습니다. 여기에서도 색상에 따라 플랫폼 상태 가시성을 지속적으로 확보할 수 있습니다.

참고:
이 기능은 주니퍼 Apstra 기술 미리 보기 기능으로 분류되었습니다. 이러한 기능은 "있는 그대로"이며 자발적 사용입니다. Juniper Support는 이러한 기능을 사용할 때 고객이 경험하는 문제를 해결하고 지원 사례를 대신하여 버그 보고서를 생성합니다. 그러나 Juniper Tech Preview 기능에 대한 포괄적인 지원 서비스는 제공하지 못할 수 있습니다.

자세한 내용은 주니퍼 Apstra 기술 미리 보기 페이지를 참조하거나 Juniper 지원부에 문의하십시오.

왼쪽 탐색 메뉴의 아래쪽에서 점 중 하나를 클릭한 다음 작업 모드 를 클릭하여 클러스터 관리로 이동합니다. 작업 모드 변경 단추를 클릭하고 정상을 선택한 다음 업데이트를 클릭합니다.

업그레이드가 진행 중이기 때문에 에이전트가 연결되지 않습니다. 업그레이드가 완료되면 에이전트가 서버에 다시 연결하고 다시 온라인에 연결됩니다. 청사진 대시보드 에서 스파인과 리프의 Liveness 이상 징후도 해결됩니다.

온박스 에이전트 업그레이드(인플레이스)

디바이스는 여전히 오래된 Apstra 서버에 연결되어 있습니다. (매니지드 디바이스 > 참조). 에이전트를 업그레이드할 때 디바이스는 이전 Apstra 서버에서 연결을 끊고 새 Apstra 서버에 연결됩니다.

주의:

에이전트 업그레이드를 시작할 때 이전 버전으로 롤백할 수 없습니다. 이전 버전으로 돌아가는 유일한 방법은 새 VM을 이전 버전으로 다시 설치하고 이전에 만든 백업에서 데이터베이스를 복원하는 것입니다.

사용자 관리자로 Apstra GUI에 로그인합니다.
왼쪽 탐색 메뉴에서 디바이스 > 시스템 에이전트 > 에이전트로 이동하여 업그레이드할 디바이스를 선택합니다(Apstra 버전 4.0.1 현재 한 번에 최대 100개의 디바이스). 여러 온박스 에이전트를 동시에 업그레이드할 수 있지만 디바이스 업그레이드 순서가 중요합니다.
- 슈퍼스핀을 위한 업그레이드 에이전트가 먼저 됩니다.
- 스파인을 위한 에이전트를 두 번째로 업그레이드합니다.
- 리프 3에 대한 에이전트를 업그레이드합니다.
설치 단추를 클릭하여 설치 프로세스를 시작합니다. 작업 상태는 진행 중입니다. 에이전트가 이전 버전의 Apstra 소프트웨어를 사용하는 경우 자동으로 새 버전으로 업그레이드됩니다. 그런 다음 서버에 연결하고 보류 중인 구성 변경 사항을 디바이스에 푸시합니다. 텔레메트리도 재개되고 작업 상태가 성공으로 바뀝니다.
블루프린트 대시보드의 Liveness 섹션에서 디바이스 이상 징후가 없는지 확인합니다.

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

작업자 노드 업그레이드(Apstra 클러스터만 해당)

오프박스 에이전트 및/또는 IBA 프로브의 경우 Apstra 클러스터를 사용하는 경우 이미 업그레이드한 컨트롤러 노드와 작업자 노드를 업그레이드해야 합니다.

Apstra 서버로 다운로드할 때 Apstra 설치자 패키지를 작업자 노드로 다운로드하지 않았다면 지금 바로 수행합니다.

각 Apstra 작업자 노드에서 명령을 실행 sudo bash aos_<aos_version>.run 합니다. 여기서 <aos_version> 은(는) 실행 파일의 버전입니다. 예를 들어, 버전이 명령 sudo bash aos_4.0.1-1045.run 인 4.0.1-1045 경우(옵션 없음) 컨트롤러를 업그레이드하는 데 사용한 파일과 동일한 파일입니다. 작업자 노드 업그레이드 중에는 프롬프트가 없습니다.