업그레이드 프로시저

노트

대부분의 AEM 업그레이드가 제대로 수행되므로 업그레이드 시 작성자 계층에 대한 다운타임이 필요합니다. 이러한 모범 사례를 따르면 게시 계층 다운타임을 최소화하거나 제거할 수 있습니다.

AEM 환경을 업그레이드할 때 작성자와 최종 사용자 모두의 가동 중단을 최소화하려면 작성자 환경 또는 게시 환경 업그레이드 접근 방식의 차이점을 고려해야 합니다. 이 페이지에서는 현재 AEM 6.x 버전에서 실행 중인 AEM 토폴로지를 업그레이드하는 고급 절차에 대해 설명합니다. Mongo 및 TarMK 기반 배포뿐만 아니라 작성자 및 게시 계층 간에 프로세스가 다르므로 각 계층 및 마이크로커널은 별도의 섹션에 나열되었습니다. 배포를 실행할 때 먼저 작성자 환경을 업그레이드하고 성공을 결정한 다음 게시 환경으로 진행하는 것이 좋습니다.

TarMK 작성자 계층

토폴로지 시작 중

이 섹션의 가정된 토폴로지는 콜드 대기가 있는 TarMK에서 실행 중인 작성자 서버로 구성됩니다. 작성자 서버에서 TarMK 게시 팜으로 복제가 발생합니다. 여기에 표시되지 않지만 이 접근 방식은 오프로딩을 사용하는 배포에 활용할 수도 있습니다. 작성자 인스턴스에서 복제 에이전트를 비활성화한 후 다시 활성화하기 전에 새 버전에서 오프로딩 인스턴스를 업그레이드하거나 다시 빌드해야 합니다.

tarmk_starting_topology

업그레이드 준비

upgrade-preparation-author

  1. 콘텐츠 작성 중지

  2. 대기 인스턴스 중지

  3. 작성자의 복제 에이전트 비활성화

  4. 실행 업그레이드 전 유지 관리 작업.

업그레이드 실행

execute_upgrade

  1. 실행 즉석 업그레이드

  2. Dispatcher 모듈 업데이트 필요한 경우

  3. QA가 업그레이드를 확인합니다

  4. 작성자 인스턴스를 종료합니다.

성공하면

if_succeeded

  1. 업그레이드된 인스턴스를 복사하여 새 콜드 대기 모드 만들기

  2. 작성자 인스턴스 시작

  3. 대기 인스턴스를 시작합니다.

실패한 경우(롤백)

롤백

  1. 콜드 대기 인스턴스를 새 기본 인스턴스로 시작

  2. 콜드 대기 모드에서 작성자 환경을 다시 빌드합니다.

MongoMK 작성자 클러스터

토폴로지 시작 중

이 섹션의 가정된 토폴로지는 두 개 이상의 MongoMK 데이터베이스에서 지원하는 두 개 이상의 AEM 작성자 인스턴스가 있는 MongoMK 작성자 클러스터로 구성됩니다. 모든 작성자 인스턴스는 데이터 저장소를 공유합니다. 이 단계는 S3 및 파일 데이터 저장소 모두에 적용되어야 합니다. 작성자 서버에서 TarMK 게시 팜으로 복제가 수행됩니다.

몽고토폴로지

업그레이드 준비

mongo-upgrade_prep

  1. 콘텐츠 작성 중지
  2. 백업을 위해 데이터 저장소 복제
  3. AEM 작성자 인스턴스 1개를 제외한 모든 인스턴스, 기본 작성자 중지
  4. 주 Mongo 인스턴스인 복제본 세트에서 MongoDB 노드를 제외한 모든 노드 제거
  5. 업데이트 DocumentNodeStoreService.cfg 단일 멤버 복제본 세트를 반영하도록 주 작성자의 파일
  6. 기본 작성자를 다시 시작하여 제대로 다시 시작되는지 확인합니다.
  7. 기본 작성자의 복제 에이전트 비활성화
  8. 실행 업그레이드 전 유지 관리 작업 기본 작성자 인스턴스에서
  9. 필요한 경우 기본 Mongo 인스턴스의 MongoDB를 WiredTiger가 있는 버전 3.2로 업그레이드합니다.

업그레이드 실행

mongo-execution

  1. 실행 즉석 업그레이드 기본 작성자
  2. Dispatcher 또는 웹 모듈 업데이트 필요한 경우
  3. QA가 업그레이드를 확인합니다

성공하면

몽고제

  1. 업그레이드된 Mongo 인스턴스에 연결된 새 6.5 작성자 인스턴스 만들기

  2. 클러스터에서 제거된 MongoDB 노드를 다시 빌드합니다

  3. 업데이트 DocumentNodeStoreService.cfg 전체 복제본 세트를 반영하는 파일

  4. 작성자 인스턴스를 한 번에 하나씩 다시 시작합니다

  5. 복제된 데이터 저장소를 제거합니다.

실패한 경우(롤백)

mongo-rollback

  1. 보조 작성자 인스턴스를 다시 구성하여 복제된 데이터 저장소에 연결합니다

  2. 업그레이드된 작성자 기본 인스턴스 종료

  3. 업그레이드된 Mongo 기본 인스턴스를 종료합니다.

  4. 두 번째 Mongo 인스턴스 중 하나를 새 기본 인스턴스로 시작

  5. 구성 DocumentNodeStoreService.cfg 아직 업그레이드되지 않은 Mongo 인스턴스의 복제본 세트를 지정하는 보조 작성자 인스턴스의 파일

  6. 보조 작성자 인스턴스 시작

  7. 업그레이드된 작성자 인스턴스, Mongo 노드 및 데이터 저장소를 정리합니다.

TarMK 게시 팜

TarMK 게시 팜

이 섹션의 가정된 토폴로지는 두 개의 TarMK 게시 인스턴스로 구성되며, 앞에는 로드 밸런서가 있습니다. 작성자 서버에서 TarMK 게시 팜으로 복제가 발생합니다.

tarmk-pub-farmv5

업그레이드 실행

upgrade-publish2

  1. 로드 밸런서에서 Publish 2 인스턴스에 대한 트래픽 중지
  2. 실행 업그레이드 전 유지 관리 게시 2
  3. 실행 즉석 업그레이드 게시 2
  4. Dispatcher 또는 웹 모듈 업데이트 필요한 경우
  5. Dispatcher 캐시 플러시
  6. QA가 방화벽 뒤의 Dispatcher를 통해 게시 2의 유효성을 검사합니다
  7. 게시 2 종료
  8. Publish 2 인스턴스 복사
  9. 게시 시작 2

성공하면

upgrade-publish1

  1. 게시할 트래픽 활성화 2
  2. 게시 1에 대한 트래픽 중지
  3. Publish 1 인스턴스 중지
  4. Publish 1 인스턴스를 Publish 2의 사본으로 바꾸기
  5. Dispatcher 또는 웹 모듈 업데이트 필요한 경우
  6. 게시 1에 대한 Dispatcher 캐시 플러시
  7. 게시 시작 1
  8. QA가 방화벽 뒤의 Dispatcher를 통해 게시 1을 확인합니다.

실패한 경우(롤백)

pub_rollback

  1. Publish 1의 복사본 만들기
  2. Publish 2 인스턴스를 Publish 1의 사본으로 바꾸기
  3. 게시 2에 대한 Dispatcher 캐시 플러시
  4. 게시 시작 2
  5. QA가 방화벽 뒤의 Dispatcher를 통해 게시 2의 유효성을 검사합니다
  6. 게시할 트래픽 활성화 2

최종 업그레이드 단계

  1. 게시할 트래픽 활성화 1
  2. QA는 공개 URL에서 최종 유효성 검사를 수행합니다
  3. 작성자 환경에서 복제 에이전트 활성화
  4. 콘텐츠 작성 다시 시작
  5. 수행 업그레이드 후 확인.

final

이 페이지에서는