Onderhoudstaken vóór upgrade

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

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

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 Back-up en herstel voor meer informatie over het maken van back-ups en het herstellen van een AEM.

Back-up maken van wijzigingen in /etc

Het upgradeproces is een goede manier om bestaande inhoud en configuraties te onderhouden en samen te voegen vanuit de paden /apps en /libs in de repository. 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 verbetering een reservekopie van om het even welke veranderingen zal maken die het niet onder /var kan samenvoegen, adviseren wij manueel het steunen van deze veranderingen alvorens met de verbetering te beginnen.

Het bestand quickstart.properties genereren

Wanneer AEM wordt gestart vanuit het jar-bestand, wordt een quickstart.properties-bestand 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 controlelogbestand opschonen

De WorkflowPurgeTask en com.day.cq.audit.impl.AuditLogMaintenanceTask 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 controlelogonderhoudstaken vindt u op Onderhoud controlelogbestand in AEM 6.

Zie Werkstroom- en auditknooppunten wissen en controlelogboeken leegmaken op AEM 6.0 voor werkstroom- en controlelogboekzuivering op CQ 5.6.

De-taken vóór de upgrade installeren, configureren en uitvoeren

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.

Hoe stelt u in

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

De PreUpgradeTasksMBean 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:

  1. Ga naar de webconsole door naar https://serveraddress:serverport/system/console/configMgr te bladeren

  2. Zoek naar "preupgradetasks", dan klik op de eerste passende component. De volledige naam van de component is com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl

  3. Wijzig de lijst van onderhoudstaken die zoals hieronder getoond moeten lopen:

    1487758925984

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.

Taak Run-modus Opmerkingen
TarIndexMergeTask crx2
DataStoreGarbageCollectionTask crx2 Voert markering en vegen uit. Voor gedeelde datastores, verwijder deze stap en stel
manueel of behoorlijk voor instanties alvorens uit te voeren voor.
ConsistencyCheckTask crx2
WorkflowPurgeTask crx2/crx3 Moet de Adobe Granite Workflow zuivert Configuratie OSGi vormen alvorens te lopen.
GenerateBundlesListFileTask crx2/crx3
RevisionCleanupTask crx3 Voor instanties TarMK op AEM 6.0 tot 6.2, stel in plaats daarvan manueel Off-line de Correctie van de Revisie in werking.
com.day.cq.audit.impl.AuditLogMaintenanceTask crx3 Moet de configuratie vormen van OSGi van de Planner van de Woorden van het Logboek van de Controle alvorens te lopen.
LET OP

DataStoreGarbageCollectionTask Roept een verrichting van de Inzameling van het Afval Datastore met het teken en de slagfase indien gebruikt. Voor plaatsingen die een gedeelde datastore gebruiken zorg ervoor om of het opnieuw te vormen of behoorlijk of de instantie voor te bereiden om schrapping van punten te vermijden die door een andere instantie van verwijzingen worden voorzien. Hiervoor 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 upgrade

De PreUpgradeTasksMBeanImpl OSGI-component wordt vooraf geconfigureerd met een lijst met pre-upgrade health check-tags die moeten worden uitgevoerd wanneer de runAllPreUpgradeHealthChecks-methode wordt aangeroepen:

  • systeem - de tag die wordt gebruikt door de gezondheidscontroles van granietonderhoud

  • pre-upgrade - dit is een aangepaste tag die kan worden toegevoegd aan alle gezondheidscontroles die u kunt instellen om te worden uitgevoerd vóór een upgrade

De lijst kan worden bewerkt. U kunt de plus (+) en minus (-) knopen naast de markeringen gebruiken om meer douanetags toe te voegen, of de standaarddegenen te verwijderen.

MBean-methoden

De beheerde boonfunctionaliteit kan worden betreden gebruikend JMX Console.

U kunt tot MBeans toegang hebben door:

  1. Ga naar de JMX Console op https://serveraddress:serverport/system/console/jmx

  2. Zoek naar PreUpgradeTasks en klik het resultaat

  3. Selecteer een methode in de sectie Bewerkingen en selecteer Invoke in het volgende venster.

Hieronder volgt een lijst van alle beschikbare methodes die PreUpgradeTasksMBeanImpl blootstelt:

Naam methode Type Beschrijving
getAvailablePreUpgradeTasksNames() INFO Hiermee geeft u de lijst met beschikbare namen voor preupgradeonderhoudstaken weer.
getAvailablePreUpgradeHealthChecksTagNames() INFO Hiermee geeft u de lijst met labelnamen voor aan de upgrade voorafgaande gezondheidscontroles weer.
runAllPreUpgradeTasks() ACTIE Voert alle preupgradeonderhoudstaken in de lijst uit.
runPreUpgradeTask(preUpgradeTaskName) ACTIE Hiermee wordt de onderhoudstaak vóór de upgrade uitgevoerd met de naam die als parameter is opgegeven.
isRunAllPreUpgradeTaskRunning() ACTION_INFO Controleert of de runAllPreUpgradeTasksmaintenance taak momenteel loopt.
getAnyPreUpgradeTaskRunning() ACTION_INFO Controleert of een preupgrade-onderhoudstaak momenteel wordt uitgevoerd en
retourneert een array met de namen van taken die momenteel worden uitgevoerd.
getPreUpgradeTaskLastRunTime(preUpgradeTaskName) ACTIE Toont de nauwkeurige lopende tijd van de pre-verbeterings onderhoudstaak met de naam die als parameter wordt gegeven.
getPreUpgradeTaskLastRunState(preUpgradeTaskName) ACTIE Toont de laatste lopende staat van de pre-verbeterings onderhoudstaak met de naam die als parameter wordt gegeven.
runAllPreUpgradeHealthChecks(shutDownOnSuccess) ACTIE

Voert alle controles van de pre-verbeteringsgezondheid in werking en bewaart hun status in een dossier genoemd preUpgradeHCStatus.properties dat in de sling huisweg wordt gevestigd. Als de shutDownOnSuccess parameter aan true wordt geplaatst, zal de AEM instantie worden gesloten, maar slechts als alle pre-verbeteringscontroles een O.K. status hebben.

Het eigenschappenbestand wordt gebruikt als een voorwaarde voor een toekomstige upgrade
en het upgradeproces wordt gestopt als de uitvoering van de health check van vóór de upgrade
is mislukt. Als u het resultaat van de voorafgaande upgrade wilt negeren
gezondheidscontroles en de upgrade toch wilt starten, kunt u het bestand verwijderen.

detectUsageOfUnavailableAPI(aemVersion) ACTIE Hiermee worden alle geïmporteerde pakketten weergegeven waaraan niet meer wordt voldaan wanneer
de upgrade naar de opgegeven AEM uitvoert. De doel AEM versie moet
als parameter worden gegeven zijn.
OPMERKING

De methodes MBean kunnen worden aangehaald via:

  • De JMX-console
  • Een externe toepassing die verbinding maakt met JMX
  • cURL

Aangepaste aanmeldingsmodules uitschakelen

OPMERKING

Deze stap is alleen vereist als u een upgrade uitvoert vanaf een versie van AEM 5. Het kan volledig voor verbeteringen van oudere AEM 6 versies worden overgeslagen.

De manier waarop aangepaste LoginModules zijn geconfigureerd voor verificatie op het niveau van de opslagplaats is fundamenteel gewijzigd in Apache Oak.

In AEM versies die CRX2 configuratie gebruikten werd geplaatst in het repository.xml dossier, terwijl vanaf AEM 6 het in de dienst van de Fabriek van de Configuratie van Apache Felix JAAS via de Console van het Web wordt gedaan.

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 worden bepaald, moet u de configuratie wijzigen om gebrek LoginModule, zoals in dit voorbeeld te gebruiken:

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

Zie Verificatie met de externe aanmeldingsmodule voor meer informatie.

Voor een voorbeeld van LoginModule configuratie in AEM 6, zie Het Vormen LDAP met AEM 6.

Updates verwijderen uit de map /install

OPMERKING

Verwijder alleen pakketten uit de map crx-quickstart/install NA het afsluiten van de AEM. Dit zal één van de laatste stappen zijn alvorens de op zijn plaats verbeteringsprocedure te beginnen.

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

Een Cold Standby-instantie stoppen

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

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

Offline revisie opschonen uitvoeren

OPMERKING

Deze stap is alleen nodig voor TarMK-installaties

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 bij het runnen van de Off-line Opruiming van de Revisie, zie Het uitvoeren van de Off-line Opruiming van de Revisie.

Afvalophaling datastore uitvoeren

OPMERKING

Deze stap is alleen nodig voor instanties waarop crx3 wordt uitgevoerd

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. Voor instructies, zie de documentatie op de Inzameling van het huisvuil van de Opslag van Gegevens.

Upgrade het databaseschema indien nodig

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:

  1. Sluit de AEM instantie die moet worden bijgewerkt.

  2. Voer een upgrade uit op het databaseschema. Raadpleeg de documentatie bij het databasetype om te zien welke gereedschappen u nodig hebt om dit te bereiken.

    Zie deze pagina op de Apache-website voor meer informatie over de manier waarop het schema-upgrades door een eik worden afgehandeld.

  3. Ga verder met het upgraden van AEM.

Gebruikers verwijderen die de upgrade mogelijk verbergen

OPMERKING

Deze onderhoudstaak voorafgaand aan de upgrade is alleen nodig als:

  • U voert een upgrade uit vanaf AEM oudere versies dan AEM 6.3
  • Tijdens de upgrade worden de hieronder vermelde fouten aangetroffen.

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:

  1. De instantie loskoppelen van het productieverkeer

  2. Maak een back-up van de gebruiker(s) die het probleem heeft veroorzaakt. U kunt dit doen via Package Manager. Voor meer informatie, zie Hoe te met Pakketten werken.

  3. Verwijder de gebruiker(s) die het probleem heeft veroorzaakt. Hieronder volgt een lijst met gebruikers die mogelijk onder deze categorie vallen:

    1. dynamic-media-replication
    2. communities-ugc-writer
    3. communities-utility-reader
    4. communities-user-admin
    5. oauthservice
    6. sling-scripting

Logbestanden roteren

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.

Op deze pagina