업그레이드 확인 후 및 문제 해결

업그레이드 후 검사

즉석 업그레이드 다음에 업그레이드를 완료하기 위해 다음 활동을 실행해야 합니다. AEM이 6.5 jar로 시작되었으며 업그레이드된 코드 베이스가 배포되었다고 가정합니다.

업그레이드 성공 로그 확인

upgrade.log

이전에는 인스턴스의 업그레이드 후 상태를 검사하려면 다양한 로그 파일, 저장소의 일부 및 시작 패드를 자세히 검사해야 했습니다. 업그레이드 후 보고서를 생성하면 라이브하기 전에 결함이 있는 업그레이드를 감지할 수 있습니다.

이 기능의 주요 목적은 업그레이드의 성공을 검증하는 데 필요한 여러 엔드포인트에서 수동 해석 또는 복잡한 구문 분석 로직에 대한 필요성을 줄이는 것입니다. 이 솔루션은 업데이트가 성공하거나 실패한 경우에 대응하도록 외부 자동화 시스템에 대한 모호한 정보를 제공하기 위해 마련되었습니다.

보다 구체적으로 다음을 보장합니다.

  • 업그레이드 프레임워크로 감지된 업그레이드 실패가 하나의 업그레이드 보고서에 집중될 수 있습니다.
  • 업그레이드 보고서에는 필요한 수동 개입에 대한 지표가 포함되어 있습니다.

이를 위해 로그가 upgrade.log 파일에서 생성되는 방식을 변경했습니다.

다음은 업그레이드 중 오류가 발생하지 않는 샘플 보고서입니다.

1487887443006

다음은 업그레이드 프로세스 동안 설치되지 않은 번들을 보여주는 샘플 보고서입니다.

1487887532730

error.log

대상 버전 jar를 사용하여 AEM을 시작하는 동안 또는 시작하는 동안 error.log를 신중하게 검토해야 합니다. 경고나 오류는 검토해야 한다. 일반적으로 로그를 시작할 때 문제를 찾는 것이 가장 좋습니다. 나중에 로그에서 발생하는 오류는 사실 파일에서 초기에 호출된 루트 문제의 부작용이 될 수 있습니다. 반복되는 오류 및 경고가 발생하는 경우 업그레이드에 대한 문제 분석을 참조하십시오.

OSGi 번들 확인

OSGi 콘솔 /system/console/bundles으로 이동하여 번들이 시작되지 않았는지 확인합니다. 번들이 설치된 상태에 있으면 error.log에서 루트 문제를 확인합니다.

Oak 버전 확인

업그레이드 후 Oak 버전이 1.10.2​로 업데이트되었음을 확인할 수 있습니다. Oak 버전을 확인하려면 OSGi 콘솔로 이동하고 Oak 번들과 연결된 버전을 확인합니다.Oak Core, Oak Commons, Oak Segment Tar.

Inspect PreUpgradeBackup 폴더

업그레이드 동안 AEM에서는 사용자 지정을 백업하고 /var/upgrade/PreUpgradeBackup/<time-stamp-of-upgrade> 아래에 저장합니다. CRXDE Lite에서 이 폴더를 보려면 CRXDE Lite을(를) 일시적으로 활성화해야 할 수 있습니다.

타임스탬프가 있는 폴더에는 COMPLETED 값을 가진 mergeStatus 속성이 있어야 합니다. to-process 폴더는 비어 있어야 하며 overwrite 노드는 업그레이드 중에 덮어쓴 노드를 나타냅니다. fluites 노드 아래의 콘텐트는 업그레이드 중 안전하게 병합할 수 없는 콘텐트를 나타냅니다. 구현이 하위 노드(업그레이드된 코드 패키지에 의해 아직 설치되지 않음)에 종속되어 있는 경우 수동으로 병합해야 합니다.

스테이지 또는 프로덕션 환경에서 이 연습 후 CRXDE Lite을 비활성화합니다.

페이지의 초기 유효성 검사

AEM의 여러 페이지에 대해 초기 유효성 검사를 수행합니다. 작성 환경을 업그레이드하는 경우 시작 페이지 및 시작 페이지( /aem/start.html, /libs/cq/core/content/welcome.html)가 열립니다. 작성자 및 게시 환경 모두에서 몇 개의 애플리케이션 페이지를 열고 올바르게 렌더링되는 연기 테스트를 엽니다. 문제가 발생하면 error.log에 문의하여 문제를 해결하십시오.

AEM 서비스 팩 적용

관련 AEM 6.5 서비스 팩을 출시한 경우 적용하십시오.

AEM 기능 마이그레이션

AEM의 여러 기능을 사용하려면 업그레이드 후 추가 단계가 필요합니다. AEM 6.5에서 이러한 기능을 마이그레이션하기 위한 전체 목록과 단계는 코드 및 사용자 지정 업그레이드 페이지에서 확인할 수 있습니다.

예약된 유지 관리 구성 확인

데이터 저장소 가비지 컬렉션 사용

파일 데이터 저장소를 사용하는 경우 데이터 저장소 가비지 수집 작업이 활성화되고 주별 유지 관리 목록에 추가되어 있는지 확인합니다. 지침은 여기에 요약되어 있습니다.

노트

이는 S3 사용자 지정 데이터 저장소 설치 또는 공유 데이터 저장소를 사용할 때는 권장되지 않습니다.

온라인 개정 정리 사용

MongoMK 또는 새로운 TarMK 세그먼트 형식을 사용하는 경우 개정 정리 작업이 활성화되고 일별 유지 관리 목록에 추가되도록 하십시오. 지침은 여기에 요약되어 있습니다.

테스트 계획 실행

테스트 프로시저 섹션 아래에 정의된 업그레이드 코드 및 사용자 지정에 대해 자세한 테스트 계획을 실행합니다.

복제 에이전트 사용

게시 환경이 완전히 업그레이드되고 검증되면 작성 환경에서 복제 에이전트를 활성화합니다. 에이전트가 각 게시 인스턴스에 연결할 수 있는지 확인합니다. 이벤트 순서에 대한 자세한 내용은 업그레이드 프로시저를 참조하십시오.

사용자 지정 예약 작업 사용

코드 베이스의 일부로 예약된 모든 작업은 이 시점에서 활성화할 수 있습니다.

업그레이드관련 문제 분석

이 섹션에는 AEM 6.3으로의 업그레이드 절차에 따라 발생할 수 있는 몇 가지 문제 시나리오가 포함되어 있습니다.

이러한 시나리오는 업그레이드와 관련된 문제의 근본 원인을 추적하는 데 도움이 되며 프로젝트 또는 제품별 문제를 식별하는 데 도움이 됩니다.

저장소 마이그레이션 실패

CRX2에서 Oak로의 데이터 마이그레이션은 CQ 5.4를 기반으로 하는 소스 인스턴스로 시작하는 모든 시나리오에 대해 실행할 수 있어야 합니다. repository.xml의 준비를 포함하는 이 문서의 업그레이드 지침을 정확히 따르고, JAAS를 통해 사용자 정의 인증기가 시작되지 않고 인스턴스가 마이그레이션을 시작하기 전에 불일치를 확인했는지 확인하십시오.

마이그레이션이 여전히 실패할 경우 upgrade.log을(를) 검사하여 근본 원인을 파악할 수 있습니다. 문제가 아직 알려지지 않은 경우 고객 지원에 알려주십시오.

업그레이드가을(를) 실행하지 않았습니다.

준비 단계를 시작하기 전에 java -jar aem-quickstart.jar 명령을 사용하여 먼저 source 인스턴스를 실행하여 실행해야 합니다. quickstart.properties 파일이 제대로 생성되는지 확인하려면 이 작업이 필요합니다. 없는 경우 업그레이드가 작동하지 않습니다. 또는 소스 인스턴스의 설치 폴더에서 crx-quickstart/conf 아래에서 파일이 있는지 여부를 확인할 수 있습니다. 또한 업그레이드를 시작하기 위해 AEM을 시작할 때 java -jar aem-quickstart.jar 명령을 사용하여 실행해야 합니다. 시작 스크립트에서 시작하는 것은 업그레이드 모드에서 AEM을 시작하지 않습니다.

패키지 및 번들이을(를) 업데이트하지 못했습니다.

업그레이드 중에 패키지가 설치되지 않은 경우 패키지에 포함된 번들 중 하나만 업데이트되지는 않습니다. 이 문제 카테고리는 일반적으로 데이터 저장소 구성이 잘못되어 발생합니다. 또한 error.log에 ERRORWARN 메시지로 나타납니다. 대부분의 경우 기본 로그인이 작동하지 않을 수 있으므로 구성 문제를 검사하고 찾기 위해 CRXDE를 직접 사용할 수 있습니다.

일부 AEM 번들이 활성 상태로 전환되지 않습니다.

번들이 시작되지 않을 경우 충족되지 않은 종속성을 확인해야 합니다.

이 문제가 있는 경우, 번들 업그레이드가 아닌 것으로 유도되는 실패한 패키지 설치를 기반으로 합니다. 이 경우 새로운 버전에 호환되지 않는 것으로 간주됩니다. 이 문제를 해결하는 방법에 대한 자세한 내용은 위의 패키지 및 번들 업데이트 실패​를 참조하십시오.

업그레이드되지 않은 번들을 감지하려면 새 AEM 6.5 인스턴스의 번들 목록을 업그레이드된 인스턴스와 비교하는 것도 좋습니다. 이렇게 하면 error.log에서 검색할 항목의 범위가 더 가까워집니다.

활성 상태으로 전환되지 않는 사용자 지정 번들

사용자 지정 번들이 활성 상태로 전환되지 않는 경우 변경 API를 가져오지 않는 코드가 있을 수 있습니다. 이것은 종종 충족되지 않은 의존성으로 이어집니다.

제거된 API는 이전 릴리스 중 하나에서 더 이상 사용되지 않는 것으로 표시되어야 합니다. 이 사용 중단 알림에서 직접 코드 마이그레이션에 대한 지침을 찾을 수 있습니다. Adobe은 버전이 변경 사항을 나타낼 수 있도록 가능한 의미 버전 지정을 목표로 합니다.

또한 문제를 일으킨 변경이 절대적으로 필요한지 확인하고 그렇지 않은 경우 되돌릴 수도 있습니다. 또한 엄격한 의미 체계 버전 관리를 통해 패키지 내보내기의 버전 증가가 필요 이상으로 증가했는지 확인하십시오.

잘못된 플랫폼 UI

업그레이드 후 제대로 작동하지 않는 특정 UI 기능의 경우 먼저 인터페이스의 사용자 지정 오버레이를 확인해야 합니다. 일부 구조가 변경되었을 수 있으며 오버레이에 업데이트가 필요하거나 더 이상 사용되지 않습니다.

다음으로 클라이언트 라이브러리에 연결된 사용자 정의 추가 확장 프로그램으로 추적할 수 있는 Javascript 오류를 확인합니다. AEM 레이아웃에 문제를 일으킬 수 있는 사용자 지정 CSS에도 같은 내용이 적용될 수 있습니다.

마지막으로 Javascript에서 처리할 수 없는 구성 오류를 확인하십시오. 일반적으로 비활성화된 익스텐션이 부적절하게 있는 경우입니다.

사용자 정의 구성 요소, 템플릿 또는 UI 확장 기능

대부분의 경우 이러한 문제의 근본 원인은 시작되지 않은 번들 또는 구성 요소를 처음 사용할 때 발생하는 문제가 발생하는 유일한 차이와 함께 설치되지 않은 패키지와 동일합니다.

잘못된 사용자 지정 코드를 처리하는 방법은 연기 테스트를 먼저 수행하여 원인을 확인하는 것입니다. 찾은 경우 문서의 [링크] 섹션에서 권장 사항을 수정하는 방법을 확인합니다.

/etc에 사용자 지정 없음

/apps 업그레이드 /libs 를 통해 원활하게 처리할 수 있지만 업그레이드 /etc 후 변경 사항을 수동으로 복원해야 /var/upgrade/PreUpgradeBackup 할 수 있습니다. 수동으로 병합해야 하는 내용이 있는지 이 위치를 확인하십시오.

error.log 및 upgrade.log분석

대부분의 경우 문제의 원인을 찾기 위해 로그에 오류가 있는지 확인해야 합니다. 그러나 업그레이드 시 이전 번들이 제대로 업그레이드되지 않을 수 있으므로 종속성 문제를 모니터링해야 합니다.

이 작업을 수행하는 가장 좋은 방법은 해당 문제와 관련이 없다고 예상되는 모든 메시지를 제거하여 error.log를 제거하는 것입니다. grep와 같은 도구를 사용하여 다음을 수행할 수 있습니다.

grep -v UnrelatedErrorString

일부 오류 메시지는 즉시 설명되지 않을 수 있습니다. 이 경우 오류가 발생한 컨텍스트를 살펴보면 오류가 만들어진 위치를 이해하는 데에도 도움이 됩니다. 다음을 사용하여 오류를 분리할 수 있습니다.

  • grep -B 오류 앞에 행을 추가할 수 있습니다.

또는

  • grep -A 을 클릭합니다.

이 상태로 이어지는 유효한 사례가 있을 수 있고 응용 프로그램에서 실제 오류인지 확인할 수 없으므로 몇 가지 경우 WARN 메시지도 찾을 수 있습니다. 이 메시지들도 반드시 참조해 주십시오.

Adobe 지원 문의

이 페이지의 의견을 수렴하여 아직 문제가 남아 있는 경우 Adobe 지원 센터에 문의하십시오. 지원 엔지니어가 해당 케이스에 대해 최대한 많은 정보를 제공하려면 업그레이드의 upgrade.log 파일을 포함해야 합니다.

이 페이지에서는

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free