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 upgraden van de inhoud en code, een migratie naar de opslagplaats worden uitgevoerd. Tijdens de migratie wordt een kopie van de opslagplaats gemaakt in de nieuwe indeling Segment Tar. 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. Voor meer informatie bij het steunen van en het herstellen van een AEM instantie, zie Steun en herstel.
Back-up maken van wijzigingen in /etc backup-changes-etc
Het upgradeproces biedt een goede manier om bestaande inhoud en configuraties te onderhouden en samen te voegen vanuit de paden onder /apps
en /libs
in de opslagplaats. Voor veranderingen die aan de /etc
weg, met inbegrip van de configuraties van de Hub van de Context worden aangebracht, is het vaak noodzakelijk om deze veranderingen na de verbetering opnieuw toe te passen. Terwijl de upgrade een reservekopie maakt van alle wijzigingen die niet kunnen worden samengevoegd onder /var
, raadt de Adobe u aan om vóór het starten van de upgrade handmatig een back-up van deze wijzigingen te maken.
Het bestand quickstart.properties genereren generate-quickstart-properties
Wanneer AEM wordt gestart vanuit het jar-bestand, wordt een quickstart.properties
-bestand gegenereerd onder crx-quickstart/conf
. Als AEM in het verleden alleen met het beginscript is gestart, 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
taken vereisen afzonderlijke configuraties OSGi en kunnen 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. De documentatie voor het vormen werkschemazuiveringstaken kan bij het Beheer de Instanties van het Werkschemaen de configuratie van de de onderhoudstaak van het controlelogboek kunnen bij het Onderhoud van het Logboek van de Controle in AEM 6worden gevonden.
Voor werkschema en controlelogboek het zuiveren op CQ 5.6 en controlelogboek het zuiveren op AEM 6.0, zie {het werkschema van 0} zuiveren en controleknopen 🔗.
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. Als zodanig is het moeilijk om een gestandaardiseerde procedure voor upgrades in te voeren.
In vorige versies was het ook moeilijk voor AEM upgrades die zijn 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 kwesties te behandelen, heeft de Adobe verscheidene verhogingen aan het verbeteringsproces toegevoegd, die het veerkrachtiger en gebruikersvriendelijker maken. 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.
Onderhoudstaken vóór de upgrade worden momenteel verspreid over verschillende interfaces die gedeeltelijk of volledig handmatig 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.
Hoe wordt het gebruikt how-to-use-it
De PreUpgradeTasksMBean
component OSGI wordt vooraf geconfigureerd met een lijst van pre-upgrade onderhoudstaken die allemaal tegelijk kunnen worden uitgevoerd. U kunt de taken vormen door de hieronder procedure te volgen:
-
Ga naar de Console van het Web door aan https://serveraddress:serverport/system/console/configMgr te doorbladeren
-
Onderzoek naar "preupgradetasks", dan klik de eerste passende component. De volledige naam van de component is
com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl
-
Wijzig de lijst met onderhoudstaken die moet worden uitgevoerd zoals hieronder wordt weergegeven:
De takenlijst verschilt afhankelijk van de uitvoeringsmodus die wordt gebruikt om de instantie te starten. Hieronder volgt een beschrijving van de uitvoeringsmodus waarvoor elke onderhoudstaak is ontworpen.
DataStoreGarbageCollectionTask
roept een verrichting van de Inzameling van het Schuin van de Datastore met het teken en de slagfase indien gebruikt. Voor plaatsingen die een gedeelde datastore gebruiken, zorg ervoor of het behoorlijk opnieuw vormt of de instantie voorbereidt om schrapping van punten te vermijden die door een andere instantie van verwijzingen worden voorzien. Voor dit proces kan het nodig zijn de markeringsfase handmatig op alle instanties uit te voeren voordat deze pre-upgradetaak wordt geactiveerd.Standaardconfiguratie van de health checks vóór de upgrade default-configuration-of-the-pre-upgrade-health-checks
De PreUpgradeTasksMBeanImpl
OSGI-component wordt vooraf geconfigureerd met een lijst met tags die voorafgaand aan de upgrade moeten worden uitgevoerd wanneer de runAllPreUpgradeHealthChecks
-methode wordt aangeroepen:
-
systeem - de markering die door de granietcontroles van de onderhoudsgezondheid wordt gebruikt
-
pre-verbetering - een douanetag die aan alle gezondheidscontroles kon worden toegevoegd die u kunt plaatsen om vóór een verbetering te lopen
De lijst kan worden bewerkt. U kunt de plus (+) gebruiken en minus (-) behalve de markeringen om meer douanetags toe te voegen, of standaarddegenen te verwijderen.
MBean Methods
De beheerde boonfunctionaliteit kan worden betreden gebruikend de Console JMX.
U kunt tot MBeans toegang hebben door:
-
Ga naar de Console JMX in https://serveraddress:serverport/system/console/jmx
-
Onderzoek naar PreUpgradeTasks en klik het resultaat
-
Selecteer om het even welke methode van de sectie van Verrichtingen en selecteer aanhalen in het volgende venster.
Hieronder vindt u een lijst met alle beschikbare methoden die door de PreUpgradeTasksMBeanImpl
worden beschreven:
- De JMX-console
- Een externe toepassing die verbinding maakt met JMX
- cURL
Aangepaste aanmeldingsmodules uitschakelen disable-custom-login-modules
De manier waarop Aangepast LoginModules
wordt geconfigureerd voor verificatie op het niveau van de opslagplaats is fundamenteel gewijzigd in Apache Oak.
In AEM versies die CRX2-configuratie gebruikten, is het bestand repository.xml
geplaatst, en vanaf AEM 6 gebeurt dit 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.
Als u de aangepaste modules die zijn gedefinieerd in de JAAS-configuratie van repository.xml
wilt uitschakelen, moet u de configuratie bewerken om de standaardwaarde LoginModule
te gebruiken, zoals in het volgende 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>
LoginModule
configuratie in AEM 6, zie Vormend LDAP met AEM 6.Updates verwijderen uit de map /install remove-updates-install-directory
Verwijder alle servicepacks, functiepakketten of hotfixes die via de map crx-quickstart/install
in het lokale bestandssysteem zijn geïmplementeerd. 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. Dit garandeert een efficiënte manier om online terug te keren als er problemen zijn in de upgrade. Nadat de verbetering met succes heeft voltooid, moeten de koude standby instanties van de promotieprimaire instanties 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 functie 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 bij het in werking stellen van de Opruiming van de Off-line Revisie, zie het Uitvoeren van de Opruiming van de Offline Revisie.
Verzameling van afval uit datastore uitvoeren execute-datastore-garbage-collection
Nadat u de revisie hebt opgeschoond op CRX3-instanties, moet u de afvalverzameling van de datastore uitvoeren om eventuele niet-gerefereerde balken in de gegevensopslag te verwijderen. Voor instructies, zie de documentatie op de Inzameling van het huisvuil van de Opslag van Gegevens.
Upgrade het databaseschema indien nodig upgrade-the-database-schema-if-needed
Gewoonlijk zorgt de onderliggende Apache Oak-stack die AEM gebruikt voor persistentie ervoor dat het databaseschema wordt bijgewerkt, indien nodig.
Er kunnen zich echter gevallen voordoen wanneer het schema niet automatisch kan worden bijgewerkt. Dergelijke gevallen zijn meestal omgevingen met hoge beveiliging waarin de database wordt uitgevoerd onder een gebruiker met beperkte rechten. Als een dergelijke situatie voorkomt, blijft AEM het oude schema gebruiken.
Om zulk een scenario te verhinderen te gebeuren, bevorder het schema door het volgende te doen:
-
Sluit de AEM instantie die moet worden bijgewerkt.
-
Upgrade het databaseschema. Raadpleeg de documentatie bij het databasetype om te zien welke gereedschappen nodig zijn om het resultaat te bereiken.
Voor meer informatie over hoe Oak schemaverbeteringen behandelt, zie deze pagina op de website Apache.
-
Ga verder met het upgraden van AEM.
Gebruikers verwijderen die de upgrade mogelijk kunnen blokkeren delete-users-that-might-hinder-the-upgrade
- U voert een upgrade uit vanaf AEM oudere versies dan AEM 6.3
- Tijdens de upgrade worden de hieronder vermelde fouten aangetroffen.
In uitzonderlijke gevallen kunnen servicegebruikers in een oudere versie van AEM niet correct zijn gecodeerd als normale gebruikers.
Als een dergelijke situatie gebeurt, ontbreekt de verbetering met een bericht als het volgende:
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.
U kunt dit probleem omzeilen door het volgende te doen:
-
De instantie loskoppelen van het productieverkeer
-
Maak een back-up van een of meer gebruikers die het probleem veroorzaken. U kunt deze taak uitvoeren via Package Manager. Voor meer informatie, zie hoe te met Pakketten werken.
-
Verwijder een of meer gebruikers die het probleem veroorzaken. Hieronder volgt een lijst met gebruikers die mogelijk onder deze categorie vallen:
dynamic-media-replication
communities-ugc-writer
communities-utility-reader
communities-user-admin
oauthservice
sling-scripting
Logbestanden roteren rotate-log-files
Adobe raadt u aan uw huidige logbestanden te archiveren voordat u begint met de upgrade. Zo kunt u logbestanden tijdens en na de upgrade gemakkelijker controleren en scannen om eventuele problemen op te sporen en op te lossen.