Onderhoudstaken vóór upgrade pre-upgrade-maintenance-tasks

Voordat u begint met de upgrade, is het belangrijk dat u de volgende onderhoudstaken uitvoert om ervoor te zorgen dat het systeem klaar is en kan worden teruggedraaid als zich problemen voordoen:

Zorgen voor voldoende schijfruimte ensure-sufficient-disk-space

Bij het uitvoeren van de upgrade moet, naast de activiteiten voor het bijwerken van de inhoud en code, een migratie naar de opslagplaats worden uitgevoerd. De migratie zal een exemplaar van de bewaarplaats in het nieuwe formaat van de Tar van het Segment tot stand brengen. Hierdoor hebt u voldoende schijfruimte nodig om een tweede, mogelijk grotere versie van uw opslagplaats te behouden.

Volledige back-up AEM fully-back-up-aem

Er moet een volledige back-up van AEM worden gemaakt voordat de upgrade wordt gestart. Maak indien van toepassing een back-up van de opslagplaats, de installatie van de toepassing, de datastore en de Mongo-exemplaren. Zie voor meer informatie over het maken van back-ups en het herstellen van een AEM Back-up en herstel.

Back-up maken van wijzigingen in /etc backup-changes-etc

Het verbeteringsproces doet een goede baan om bestaande inhoud en configuraties van onder te handhaven en samen te voegen /apps en /libs paden in de repository. Voor wijzigingen in de /etc De weg, met inbegrip van de configuraties van de Hub van de Context, is het vaak noodzakelijk om deze veranderingen na de verbetering opnieuw toe te passen. Tijdens de upgrade wordt een reservekopie gemaakt van alle wijzigingen die niet kunnen worden samengevoegd /varWij raden u aan handmatig een back-up van deze wijzigingen te maken voordat u de upgrade start.

Het bestand quickstart.properties genereren generate-quickstart-properties

Wanneer AEM wordt gestart vanuit het jar-bestand, wordt een quickstart.properties bestand wordt gegenereerd onder crx-quickstart/conf. Als AEM in het verleden alleen is gestart met het beginscript, is dit bestand niet aanwezig en mislukt de upgrade. Controleer of dit bestand bestaat en start AEM opnieuw vanaf het jar-bestand als dit niet aanwezig is.

Werkstroom- en controlelogbestanden leegmaken configureren configure-wf-audit-purging

De WorkflowPurgeTask en com.day.cq.audit.impl.AuditLogMaintenanceTask de taken vereisen afzonderlijke configuraties OSGi en zullen niet zonder hen werken. Als ze tijdens de uitvoering van een pre-upgrade-taak mislukken, is het ontbreken van configuraties de meest waarschijnlijke reden. Daarom zorg ervoor om configuraties OSGi voor deze taken toe te voegen of hen volledig te verwijderen uit de lijst van pre-verbeteringstaken als u niet wenst om hen in werking te stellen. Documentatie voor het configureren van taken voor het zuiveren van werkstromen vindt u op Workflowinstanties beheren en de configuratie van de de onderhoudstaak van het controlelogboek kan worden gevonden bij Onderhoud controlelogbestand in AEM 6.

Voor werkstroom- en controlelogboekzuivering op CQ 5.6 en controle logpuring op AEM 6.0, zie Werkstroom en controleknooppunten wissen.

De taken vóór de upgrade installeren, configureren en uitvoeren install-configure-run-pre-upgrade-tasks

Vanwege de mate van aanpassing die AEM toestaat, passen omgevingen gewoonlijk niet op dezelfde manier upgrades uit. Dit maakt het tot stand brengen van een gestandaardiseerde procedure voor verbeteringen een moeilijk proces.

In vorige versies was het ook moeilijk voor AEM upgrades die waren gestopt of die niet veilig zijn hervat. Dit leidde tot situaties waarin het opnieuw opstarten van de volledige upgradeprocedure noodzakelijk was of waarin defecte upgrades werden uitgevoerd zonder dat dit tot waarschuwingen leidde.

Om deze problemen aan te pakken, heeft Adobe het upgradeproces verschillende verbeteringen aangebracht, waardoor het robuuster en gebruiksvriendelijker wordt. De onderhoudstaken die vóór de upgrade moesten worden uitgevoerd, worden geoptimaliseerd en geautomatiseerd. Ook zijn er ná de upgrade-rapporten toegevoegd, zodat het proces volledig kan worden onderzocht in de hoop dat eventuele problemen gemakkelijker kunnen worden gevonden.

De preupgrade onderhoudstaken worden momenteel verspreid over verschillende interfaces die gedeeltelijk of volledig manueel worden uitgevoerd. De pre-verbeterings onderhoudsoptimalisering die in AEM 6.3 wordt geïntroduceerd laat een verenigde manier toe om deze taken teweeg te brengen en hun resultaat op bestelling te kunnen inspecteren.

Alle taken die zijn opgenomen in de optimaliseringsstap vóór de upgrade zijn compatibel met alle versies vanaf AEM 6.0.

Procedure voor instellen how-to-set-it-up

In AEM 6.3 en later worden de optimalisatietaken voor het onderhoud van de upgrade opgenomen in de snelstartjar. Als u een upgrade uitvoert vanaf een oudere versie van AEM 6, worden deze beschikbaar gesteld via afzonderlijke pakketten die u kunt downloaden van Package Manager.

U vindt de pakketten op de volgende locaties:

Hoe wordt het gebruikt how-to-use-it

De PreUpgradeTasksMBean De component OSGI komt vooraf gevormd met een lijst van pre-verbeterings onderhoudstaken die allen in één keer kunnen worden in werking gesteld. U kunt de taken vormen door de hieronder procedure te volgen:

De takenlijst is afhankelijk van de uitvoeringsmodus die wordt gebruikt om de instantie te starten. Hieronder volgt een beschrijving van de uitvoeringsmodus waarvoor elke onderhoudstaak is ontworpen.

Standaardconfiguratie van de health checks vóór de upgrade default-configuration-of-the-pre-upgrade-health-checks

De PreUpgradeTasksMBeanImpl De component OSGI wordt vooraf geconfigureerd met een lijst van labels voor de health check die vóór de upgrade moeten worden uitgevoerd wanneer de component runAllPreUpgradeHealthChecks methode wordt aangeroepen:

De lijst kan worden bewerkt. U kunt de plus gebruiken (+) en minus (-) naast de tags om meer aangepaste tags toe te voegen of om de standaardtags te verwijderen.

MBean-methoden

De beheerde boonfunctionaliteit kan worden betreden gebruikend JMX-console.

U kunt tot MBeans toegang hebben door:

Hieronder volgt een lijst met alle beschikbare methoden die PreUpgradeTasksMBeanImpl wordt getoond:

Aangepaste aanmeldingsmodules uitschakelen disable-custom-login-modules

De manier van aanpassen LoginModules zijn geconfigureerd voor verificatie op het niveau van de gegevensopslagruimte is fundamenteel gewijzigd in Apache Oak.

In AEM versies die de configuratie gebruiken CRX2 werd geplaatst in repository.xml bestand, terwijl vanaf AEM 6 dit gebeurt in de service Configuratie van Apache Felix JAAS via de webconsole.

Daarom moeten bestaande configuraties na de upgrade worden uitgeschakeld en opnieuw worden gemaakt voor Apache Oak.

Om de douanemodules onbruikbaar te maken die in de configuratie JAAS van repository.xml, moet u de configuratie wijzigen om van gebrek gebruik te maken LoginModule, zoals in dit voorbeeld:

<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>

Updates verwijderen uit de map /install remove-updates-install-directory

Verwijder om het even welke de dienstpakken, eigenschapspakken of hotfixes die door crx-quickstart/install op het lokale bestandssysteem. Hierdoor wordt voorkomen dat oude hotfixes en servicepacks onbedoeld boven op de nieuwe AEM worden geïnstalleerd nadat de update is voltooid.

Koude stand-byinstanties stoppen stop-tarmk-coldstandby-instance

Als u TarMK koude stand-by gebruikt, moet u eventuele koude stand-byinstanties stoppen. Deze zullen een efficiënte manier waarborgen om online terug te komen in het geval van kwesties in de verbetering. Nadat de verbetering met succes heeft voltooid, zullen de koude standby instanties van de promotieprimaire instanties moeten worden herbouwd.

Aangepaste geplande taken uitschakelen disable-custom-scheduled-jobs

Schakel geplande OSGi-taken uit die in uw toepassingscode zijn opgenomen.

Offline revisie opschonen uitvoeren execute-offline-revision-cleanup

Als u TarMK gebruikt, moet u de optie Offline revisie opschonen uitvoeren voordat u de upgrade uitvoert. Hierdoor worden de migratie naar de opslagplaats en de daarop volgende upgradetaken veel sneller uitgevoerd en wordt ervoor gezorgd dat Online revisie-opschoning met succes kan worden uitgevoerd nadat de upgrade is voltooid. Voor informatie over het uitvoeren van Offline de Opruiming van de Revisie, zie Offline revisie opschonen uitvoeren.

Verzameling van afval uit datastore uitvoeren execute-datastore-garbage-collection

Na het runnen van revisie schoonmaakbeurt op CRX3 instanties, zou u de Inzameling van het huisvuil van de Datastore moeten in werking stellen om het even welke niet referenced vlekken in de gegevensopslag te verwijderen. Zie de documentatie over Opruimverzameling gegevensopslag.

Gebruikers verwijderen die de upgrade mogelijk kunnen blokkeren delete-users-that-might-hinder-the-upgrade

Er zijn uitzonderlijke gevallen wanneer de de dienstgebruikers in een oudere AEM versies zouden kunnen uiteindelijk verkeerd geëtiketteerd worden als regelmatige gebruikers.

Als dit gebeurt, zal de verbetering met een bericht als dit ontbreken:

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.

Om dit probleem te verhelpen, moet u het volgende doen:

Om dit probleem te verhelpen, moet u het volgende doen:

Upgrade het databaseschema indien nodig upgrade-the-database-schema-if-needed

Gewoonlijk zorgt de onderliggende Apache Oak-stapel AEM voor persistentie ervoor dat het databaseschema indien nodig wordt bijgewerkt.

Er kunnen zich echter gevallen voordoen wanneer het schema niet automatisch kan worden bijgewerkt. Dit zijn meestal hoge beveiligingsomgevingen waarin de database wordt uitgevoerd onder een gebruiker met zeer beperkte bevoegdheden. Als dit gebeurt, blijft AEM het oude schema gebruiken.

Om dit te verhinderen, moet u het schema bevorderen door de hieronder procedure te volgen:

Logbestanden roteren rotate-log-files

We raden u aan uw huidige logbestanden te archiveren voordat u begint met de upgrade. Hierdoor kunt u logbestanden tijdens en na de upgrade gemakkelijker controleren en scannen om eventuele problemen op te sporen en op te lossen.