업그레이드 전 유지 관리 작업 pre-upgrade-maintenance-tasks

업그레이드를 시작하기 전에 다음 유지 관리 작업을 수행하여 시스템이 준비되고 문제가 발생할 경우 롤백할 수 있도록 하는 것이 중요합니다.

충분한 디스크 공간 확인 ensure-sufficient-disk-space

업그레이드를 실행할 때 컨텐츠 및 코드 업그레이드 활동 외에도 저장소 마이그레이션을 수행해야 합니다. 마이그레이션은 새로운 Segment Tar 형식으로 저장소의 복사본을 만듭니다. 따라서 두 번째, 어쩌면 더 큰 버전의 리포지토리를 유지하려면 디스크 공간이 필요합니다.

AEM 전체 백업 fully-back-up-aem

AEM은 업그레이드를 시작하기 전에 완전히 백업해야 합니다. 해당하는 경우 저장소, 애플리케이션 설치, 데이터 저장소 및 Mongo 인스턴스를 백업하십시오. AEM 인스턴스 백업 및 복원에 대한 자세한 내용은 백업 및 복원.

/etc에 변경 내용 백업 backup-changes-etc

업그레이드 프로세스는 의 /apps 및 /libs 저장소의 경로입니다. 에 대한 변경 사항 /etc Context Hub 구성을 포함한 경로는 업그레이드 후 이러한 변경 사항을 다시 적용해야 하는 경우가 많습니다. 업그레이드는 병합할 수 없는 변경 내용의 백업 복사본을 만듭니다. /var를 설정하는 것이 좋습니다. 업그레이드를 시작하기 전에 이러한 변경 사항을 수동으로 백업하는 것이 좋습니다.

quickstart.properties 파일 생성 generate-quickstart-properties

jar 파일에서 AEM을 시작할 때 quickstart.properties 파일은 crx-quickstart/conf. AEM이 이전에 시작 스크립트로만 시작된 경우 이 파일이 존재하지 않으며 업그레이드가 실패합니다. 이 파일이 있는지 확인하고 jar 파일이 없으면 jar 파일에서 AEM을 다시 시작하십시오.

워크플로우 및 감사 로그 삭제 구성 configure-wf-audit-purging

다음 WorkflowPurgeTask 및 com.day.cq.audit.impl.AuditLogMaintenanceTask 작업은 별도의 OSGi 구성이 필요하며 작업이 없으면 작동하지 않습니다. 업그레이드 전 작업 실행 중에 오류가 발생하면 구성이 누락될 가능성이 높습니다. 따라서 이러한 작업에 대한 OSGi 구성을 추가하거나 업그레이드 전 최적화 작업 목록에서 모두 제거하지 않으려면 해당 작업을 모두 제거해야 합니다. 워크플로우 삭제 작업 구성에 대한 설명서는 워크플로우 인스턴스 관리 및 감사 로그 유지 관리 작업 구성은 AEM 6의 감사 로그 유지 관리.

AEM 6.0에서 감사 로그 삭제뿐만 아니라 CQ 5.6에서 워크플로우 및 감사 로그 삭제에 대해서는 를 참조하십시오 워크플로우 및 감사 노드 제거.

업그레이드 전 작업 설치, 구성 및 실행 install-configure-run-pre-upgrade-tasks

AEM에서 허용하는 사용자 지정 수준 때문에 일반적으로 환경은 업그레이드를 수행하는 동일한 방법을 준수하지 않습니다. 따라서 업그레이드 절차가 까다롭도록 표준화된 절차가 생성됩니다.

이전 버전에서는 AEM 업그레이드가 중지되었거나 안전하게 다시 시작되지 않은 경우도 있었습니다. 이로 인해 전체 업그레이드 절차를 다시 시작해야 하거나 경고를 트리거하지 않고 결함이 있는 업그레이드를 수행한 상황이 발생했습니다.

이러한 문제를 해결하기 위해 Adobe은 업그레이드 프로세스에 몇 가지 개선 사항을 추가하여 보다 탄력적이고 사용자 친화적으로 만듭니다. 수동으로 수행해야 했던 사전 업그레이드 유지 관리 작업은 최적화 및 자동화되어 있습니다. 또한 업그레이드 후 보고서가 추가되어 모든 문제가 보다 쉽게 해결되기를 희망하면서 프로세스를 완전히 검토할 수 있습니다.

업그레이드 전 유지 관리 작업은 현재 일부 또는 완전히 수동으로 수행되는 다양한 인터페이스에 분산되어 있습니다. AEM 6.3에 도입된 사전 업그레이드 유지 관리 최적화를 사용하면 이러한 작업을 트리거하고 필요 시 결과를 검사할 수 있습니다.

업그레이드 전 최적화 단계에 포함된 모든 작업은 AEM 6.0 버전의 모든 버전과 호환됩니다.

설정 방법 how-to-set-it-up

AEM 6.3 이상에서는 업그레이드 전 유지 관리 최적화 작업이 quickstart jar에 포함됩니다. 이전 버전의 AEM 6에서 업그레이드하는 경우 패키지 관리자에서 다운로드할 수 있는 별도의 패키지를 통해 사용할 수 있습니다.

패키지는 다음 위치에서 찾을 수 있습니다.

사용 방법 how-to-use-it

다음 PreUpgradeTasksMBean OSGI 구성 요소에는 한 번에 모두 실행할 수 있는 업그레이드 전 유지 관리 작업 목록이 사전 구성되어 있습니다. 아래 절차에 따라 작업을 구성할 수 있습니다.

작업 목록은 인스턴스를 시작하는 데 사용 중인 실행 모드에 따라 다릅니다. 다음은 각 유지 관리 작업이 설계된 실행 모드에 대한 설명입니다.

업그레이드 전 상태 확인의 기본 구성 default-configuration-of-the-pre-upgrade-health-checks

다음 PreUpgradeTasksMBeanImpl OSGI 구성 요소는 runAllPreUpgradeHealthChecks 메서드가 호출됩니다.

목록을 편집할 수 있습니다. 플러스를 이용하시면 됩니다 (+) 및 빼기 (-) 태그 옆에 있는 버튼을 클릭하여 사용자 지정 태그를 추가하거나 기본 태그를 제거합니다.

MBean 메서드

관리 Bean 기능은 JMX 콘솔.

다음 방법으로 MBeans에 액세스할 수 있습니다.

아래는 PreUpgradeTasksMBeanImpl 노출은 다음과 같습니다.

사용자 지정 로그인 모듈 비활성화 disable-custom-login-modules

사용자 지정 방법 LoginModules 는 Apache Oak에서 저장소 수준에서 인증을 위해 구성되었습니다.

AEM 버전에서 CRX2 구성을 사용한 는 repository.xml 파일(AEM 6 이상)에서는 웹 콘솔을 통해 Apache Felix JAAS Configuration Factory 서비스에서 수행합니다.

따라서 업그레이드 후 Apache Oak에 대해 기존 구성을 비활성화하고 다시 만들어야 합니다.

JAAS 구성에 정의된 사용자 지정 모듈을 비활성화하려면 repository.xml을 지정하는 경우 구성을 수정하여 기본값을 사용해야 합니다 LoginModule와 같습니다.

<Security >
             ....
          <!--
                 Use LoginModule authenticating against repository itself
                 -->
                 <LoginModule class = "com.day.crx.core.CRXLoginModule" >
                     <param name = "anonymousId" value = "anonymous" />
                     <param name = "adminId" value ="admin" />
                     <param name = "disableNTLMAuth" value = "true" />
                     <param name = "tokenExpiration" value = "43200000" />
                     <!-- param name="trust_credentials_attribute" value="d5b9167e95dad6e7d3b5d6fa8df48af8"/
                -->
                 </LoginModule >
         </ Security>

/install 디렉토리에서 업데이트 제거 remove-updates-install-directory

를 통해 배포된 서비스 팩, 기능 팩 또는 핫픽스를 제거합니다. crx-quickstart/install 로컬 파일 시스템의 디렉토리입니다. 이렇게 하면 업데이트가 완료된 후 새 AEM 버전 위에 이전 핫픽스 및 서비스 팩을 실수로 설치하지 못합니다.

콜드 대기 인스턴스 정지 stop-tarmk-coldstandby-instance

TarMK 콜드 대기기를 사용하는 경우, 콜드 대기 인스턴스를 중지합니다. 이는 업그레이드 시 문제가 발생할 경우 온라인으로 돌아가는 효율적인 방법을 보장합니다. 업그레이드가 성공적으로 완료되면 업그레이드된 기본 인스턴스에서 콜드 대기 인스턴스를 다시 빌드해야 합니다.

사용자 지정 예약 작업 비활성화 disable-custom-scheduled-jobs

애플리케이션 코드에 포함된 모든 OSGi 예약 작업을 비활성화합니다.

오프라인 개정 정리 실행 execute-offline-revision-cleanup

TarMK를 사용하는 경우 업그레이드하기 전에 오프라인 개정 정리를 실행해야 합니다. 이렇게 하면 저장소 마이그레이션 단계 및 후속 업그레이드 작업이 훨씬 더 빨리 실행되며 업그레이드가 완료된 후 온라인 개정 정리를 성공적으로 실행할 수 있도록 할 수 있습니다. 오프라인 개정 정리 실행에 대한 자세한 내용은 오프라인 개정 정리 수행.

데이터 저장소 가비지 수집 실행 execute-datastore-garbage-collection

CRX3 인스턴스에서 개정 정리를 실행한 후 데이터 저장소 가비지 수집을 실행하여 데이터 저장소에서 참조되지 않은 BLOB을 제거해야 합니다. 지침은 데이터 저장소 가비지 수집.

업그레이드를 방해할 수 있는 사용자 삭제 delete-users-that-might-hinder-the-upgrade

서비스 사용자가 이전 AEM 버전에서 일반 사용자로 잘못 태그가 지정된 경우 예외적인 경우가 있습니다.

이러한 경우 다음과 같은 메시지가 표시되면서 업그레이드가 실패합니다.

ERROR [Apache Sling Repository Startup Thread] com.adobe.granite.repository.impl.SlingRepositoryManager Exception in a SlingRepositoryInitializer, SlingRepository service registration aborted
java.lang.RuntimeException: Unable to create service user [communities-utility-reader]:java.lang.RuntimeException: Existing user communities-utility-reader is not a service user.

이 문제를 해결하려면 다음을 수행하십시오.

이 문제를 해결하려면 다음을 수행하십시오.

필요한 경우 데이터베이스 스키마 업그레이드 upgrade-the-database-schema-if-needed

일반적으로 지속성을 위해 사용하는 기본 Apache Oak 스택 AEM은 필요한 경우 데이터베이스 스키마를 업그레이드하도록 처리합니다.

그러나 스키마를 자동으로 업그레이드할 수 없을 때 사례가 발생할 수 있습니다. 이러한 환경은 데이터베이스가 매우 제한된 개인 정보 보호 환경에서 실행되는 높은 보안 환경입니다. 이렇게 되면 AEM에서는 이전 스키마를 계속 사용합니다.

이러한 문제가 발생하지 않도록 하려면 아래 절차에 따라 스키마를 업그레이드해야 합니다.

로그 파일 회전 rotate-log-files

업그레이드를 시작하기 전에 현재 로그 파일을 보관하는 것이 좋습니다. 이렇게 하면 업그레이드 도중 및 업그레이드 후에 로그 파일을 보다 쉽게 모니터링 및 스캔하여 발생할 수 있는 모든 문제를 식별하고 해결할 수 있습니다.