Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

동일한 VM에서 Apstra 업그레이드(인플레이스)

참고:

현재 위치에서 업그레이드하는 경우 보안 취약성 업데이트를 포함하여 Ubuntu Linux OS 수정 사항을 받지 못합니다. 이러한 업데이트를 받으려면 새 VM에서 업그레이드해야 합니다. 대신 현재 위치에서 업그레이드하려면 계속 읽으십시오.

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

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

  1. 업그레이드 경로를 참조하여 지원되는 버전으로 업그레이드 하고 있는지 확인합니다. (Apstra GUI의 플랫폼 > 정보로 이동하여 현재 Apstra 버전을 찾을 수 있습니다. Apstra 버전 4.2.1부터 Apstra 버전은 GUI의 왼쪽 탐색 메뉴에서도 주니퍼 Apstra 로고 아래에 표시됩니다.)
  2. 기본적으로 Apstra 업그레이드는 추가 Docker 서브넷 172.18.0.1/16을 생성합니다. 네트워크의 다른 곳에서 이 서브넷을 사용하는 경우 Apstra 업그레이드가 실패할 수 있습니다. 이에 해당하는 경우, Docker 네트워크 및 Apstra 업그레이드에서 다른 서브넷을 사용하는 방법을 참조하십시오.
  3. 관리자로 Apstra 서버에 로그인합니다(예: Apstra 서버 IP 주소가 10.28.105.3인 경우 명령은 다음과 같습니다). ssh admin@10.28.105.3
  4. VM에 두 가지 버전의 Apstra 소프트웨어를 동시에 저장할 수 있는 충분한 메모리가 있는지 확인합니다. 명령을 free -h 실행하여 메모리 사용률이 50% 미만인지 확인합니다.
  5. 사용률이 50%를 초과하면 Apstra 서버를 정상적으로 종료하고 리소스를 추가한 다음 Apstra 서버를 다시 시작합니다.
  6. 명령을 service aos status 실행하여 서버가 활성 상태이고 문제가 없는지 확인합니다.
  7. 데이터 플레인에 영향을 미칠 수 있는 구성 렌더링 변경 사항은 새로운 Apstra 버전 릴리스 노트를 확인하십시오. 필요에 따라 구성을 업데이트합니다.
  8. 각 청사진을 검토하여 모든 서비스 구성이 성공했는지 확인합니다. 필요한 경우 청사진에서 디바이스를 배포 해제하고 제거하여 보류 중이거나 실패한 서비스 구성을 해결합니다.
  9. 프로브 이상에 대한 각 청사진을 검토하고 가능한 한 많이 해결합니다. 나머지 변칙을 기록해 둡니다.
  10. 적격 디바이스 및 NOS 버전을 참조하여 NOS 버전이 새 Apstra 버전에서 적격한지 확인하십시오. 필요에 따라 지원되는 버전 중 하나로 업그레이드하거나 다운그레이드합니다.
  11. Junos 디바이스를 사용 중이고 Apstra 버전 4.2.1로 업그레이드하는 경우, 기본 구성에는 필수 mgmt_junos VRF입니다. 자세한 내용은 주니퍼 지원 기술 자료 문서 KB77094를 참조하십시오.
    주의:

    원래 구성에 VRF가 mgmt_junos 포함되어 있지 않으면 배포가 실패합니다.

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

    업그레이드된 Apstra 서버에는 시간 보이저 수정 버전이 포함되어 있지 않으므로 과거 상태로 되돌려야 하는 경우 이 백업이 필요합니다. 이전 상태는 레퍼런스 설계와의 긴밀한 결합으로 인해 포함되지 않으며, Apstra 버전 간에 변경될 수 있습니다.

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

2단계: 새 Apstra 서버 구축

  1. 주니퍼 지원 다운로드(예: aos_server_4.1.2-269)에서 플랫폼에 맞는 Apstra 설치 프로그램 패키지를 다운로드하여 Apstra 서버로 전송합니다.
  2. Apstra 설치 프로그램 패키지의 압축을 풉니다.
  3. Apstra 클러스터(오프박스 에이전트, IBA 프로브)를 사용하는 경우 작업자 노드에도 설치 프로그램 패키지를 다운로드합니다. 이후 단계에서 작업자 노드를 업그레이드합니다.
  4. Apstra 서버에 admin으로 로그인합니다.
  5. sudo bash aos_<aos_version>.run 명령을 실행합니다. 여기서 <aos_version> 는 실행 파일의 버전입니다. 예를 들어 버전이 인 4.0.1-1045 경우 명령은 sudo bash aos_4.1.1-287.run 아래와 같습니다.
    이 명령을 실행할 때 이전 Apstra 버전이 감지되면 스크립트는 새 설치 모드 대신 업그레이드 모드로 들어갑니다. 새 Docker 컨테이너는 이전 버전의 Docker 컨테이너 옆에 설치됩니다. 스크립트는 이전 버전에서 데이터를 가져와 새 버전의 Apstra SysDB로 마이그레이션합니다.

    업그레이드 스크립트는 업그레이드 중에 구성 변경 사항을 수신할 패브릭 내 디바이스의 요약 보기를 제공합니다. Apstra 버전 4.1.2부터는 계속하기 전에 릴리스 노트업그레이드 경로 문서를 읽어 보라는 경고가 화면에 나타납니다. 릴리스 노트에는 Apstra 버전 4.1.2부터 구성 렌더링 변경에 대한 카테고리가 포함되어 있습니다. 구성 렌더링 변경 사항은 각 변경 사항이 네트워크에 미치는 영향을 설명하는 상단에 명확하게 문서화되어 있습니다.

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

  6. 요약을 검토한 후 를 입력하여 q 요약을 종료합니다. AOS 업그레이드: 대화형 메뉴가 나타나며, 여기에서 각 디바이스의 정확한 구성 변경 사항을 검토할 수 있습니다. 구성 요소(configlet)를 사용하는 경우 업그레이드에 의해 푸시된 새 구성이 기존 구성 요소(configlet)와 충돌하지 않는지 확인합니다.
    주의:

    새로운 Apstra 릴리스의 Apstra 참조 설계는 구성 요소(configlet)를 무효화하는 방식으로 변경되었을 수 있습니다. 예기치 않은 결과를 방지하려면 구성이 새로 렌더링된 구성과 충돌하지 않는지 확인합니다. 구성단을 업데이트해야 하는 경우 업그레이드를 종료하고 구성자를 업데이트한 다음 업그레이드를 다시 실행합니다.

  7. 보류 중인 변경 내용을 검토한 후 업그레이드를 계속하려면 을 입력합니다c. 이전 Apstra 버전이 삭제되고 새 Apstra 버전이 서버에서 활성화됩니다. 업그레이드가 완료되면 Apstra GUI의 플랫폼 > 정보로 이동하여 버전을 확인합니다.
    주의:

    Apstra 서버 업그레이드는 중단이 심한 프로세스입니다. 현재 위치(동일한 VM)로 업그레이드하고 이 시점부터 업그레이드를 계속하는 경우 업그레이드를 롤백할 수 없습니다. 이전 버전으로 돌아가는 유일한 방법은 이전 버전으로 새 VM을 다시 설치하고 이전에 만든 백업에서 데이터베이스를 복원하는 것입니다. 백업을 했죠?

  8. 업그레이드를 중지하려면 을 입력하여 q 프로세스를 중단합니다. 이 시점에서 종료하고 나중에 업그레이드하기로 결정한 경우 프로세스를 처음부터 시작해야 합니다.
  9. Apstra 클러스터를 사용하는 경우 작업자 노드와 Apstra 컨트롤러의 연결이 끊기고 FAILED 상태로 변경됩니다. 이 상태는 작업자 노드에 있는 오프박스 에이전트 및 IBA 프로브 컨테이너를 사용할 수 없음을 의미합니다. 하지만 오프박스 에이전트에서 관리하는 디바이스는 계속 작동합니다. 이후 단계에서 에이전트를 업그레이드한 후 Apstra 클러스터의 작업자 노드를 업그레이드하면 에이전트 및/또는 프로브를 사용할 수 있게 됩니다.

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

Apstra 서버 업그레이드를 시작하면 운영 모드가 자동으로 일반 에서 유지 보수 로 변경됩니다. 업그레이드를 완료한 후에는 수동으로 모드를 다시 보통으로 변경해야 합니다.

  1. Apstra GUI의 왼쪽 탐색 메뉴에서 플랫폼 > Apstra 클러스터 > 클러스터 관리로 이동합니다.
  2. Change Operation Mode(작동 모드 변경) 버튼을 클릭하고 Normal(일반)을 선택한 다음 Update(업데이트)를 클릭합니다. 모드를 일반으로 변경하면 구성된 모든 오프박스 에이전트가 활성화되지만 모든 온박스 에이전트의 업그레이드를 시작해야 합니다(다음 섹션에서).

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

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

    아직 업그레이드 중이므로 에이전트가 연결되지 않습니다. 업그레이드가 완료되면 에이전트가 서버에 다시 연결되고 다시 온라인 상태가 됩니다. 블루프린트 대시보드에서 스파인과 리프에 대한 활동성 이상도 해결됩니다.

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

주의:

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

  1. 사용자 관리자로 Apstra GUI에 로그인합니다.
  2. 왼쪽 탐색 메뉴에서 디바이스 > 시스템 에이전트 > 에이전트로 이동하여 업그레이드할 디바이스를 선택합니다(Apstra 버전 4.0.1부터 한 번에 최대 100개 디바이스). 여러 온박스 에이전트를 동시에 업그레이드할 수 있지만 디바이스 업그레이드 순서가 중요합니다.
    • 먼저 슈퍼스파인에 대한 에이전트를 업그레이드합니다.
    • 스파인에 대한 에이전트를 두 번째로 업그레이드합니다.
    • 리프에 대한 에이전트를 세 번째로 업그레이드합니다.
  3. Install(설치) 버튼을 클릭하여 설치 프로세스를 시작합니다. 작업 상태가 IN PROGRESS로 변경됩니다. 상담원이 이전 버전의 Apstra 소프트웨어를 사용하는 경우 자동으로 새 버전으로 업그레이드됩니다. 그런 다음 서버에 연결하고 보류 중인 구성 변경 사항을 디바이스에 푸시합니다. 원격 분석도 다시 시작되고 작업 상태가 SUCCESS로 변경됩니다.
  4. 블루프린트 대시보드의 활동성(Liveness) 섹션에서 디바이스 이상이 없는지 확인합니다.
    참고:

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

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

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

  1. Apstra 서버에 Apstra 설치 프로그램 패키지를 다운로드할 때 작업자 노드에 다운로드하지 않았다면 지금 다운로드하십시오.
  2. 각 Apstra 작업자 노드에서 명령을 실행합니다sudo bash aos_<aos_version>.run. 여기서 <aos_version> 는 실행 파일의 버전입니다. 예를 들어, 버전이 인 경우 명령은 sudo bash aos_4.1.1-287.run (옵션 없음)입니다4.1.1-287. 이 파일은 컨트롤러를 업그레이드하는 데 사용한 것과 동일한 파일입니다. 작업자 노드를 업그레이드하는 동안 프롬프트가 표시되지 않습니다.

다음 단계:

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