Underhållsaktiviteter före uppgradering

Innan du påbörjar uppgraderingen är det viktigt att du följer dessa underhållsåtgärder för att vara säker på att systemet är klart och kan återställas om det skulle uppstå problem:

Se till att det finns tillräckligt med diskutrymme

När du utför uppgraderingen måste du utföra en databasmigrering, förutom innehålls- och koduppgraderingsaktiviteterna. Migreringen skapar en kopia av databasen i det nya segmenttjärformatet. Därför behöver du tillräckligt med diskutrymme för att behålla en andra, eventuellt större, version av databasen.

Helt säkerhetskopiera AEM

AEM bör säkerhetskopieras fullständigt innan uppgraderingen påbörjas. Säkerhetskopiera databasen, programinstallationen, datalagret och Mongo-instanserna om tillämpligt. Mer information om säkerhetskopiering och återställning av en AEM finns i Säkerhetskopiera och återställ.

Säkerhetskopiera ändringar i /etc

Uppgraderingsprocessen gör det bra att underhålla och sammanfoga befintligt innehåll och befintliga konfigurationer från sökvägarna /apps och /libs i databasen. För ändringar som görs i sökvägen /etc, inklusive konfigurationer för kontextnav, är det ofta nödvändigt att tillämpa ändringarna igen efter uppgraderingen. Även om uppgraderingen kommer att göra en säkerhetskopia av alla ändringar som den inte kan sammanfogas under /var, rekommenderar vi att du säkerhetskopierar dessa ändringar manuellt innan du påbörjar uppgraderingen.

Generera filen quickstart.properties

När du startar AEM från jar-filen skapas en quickstart.properties-fil under crx-quickstart/conf. Om AEM bara har startats med det tidigare startskriptet kommer den här filen inte att finnas och uppgraderingen misslyckas. Kontrollera om filen finns och starta om AEM från filen jar om den inte finns.

Konfigurera rensning av arbetsflöde och granskningslogg

Aktiviteterna WorkflowPurgeTask och com.day.cq.audit.impl.AuditLogMaintenanceTask kräver separata OSGi-konfigurationer och fungerar inte utan dem. Om de inte fungerar när en uppgift körs före uppgraderingen är det mest troligt att konfigurationer saknas. Se därför till att du lägger till OSGi-konfigurationer för dessa uppgifter eller tar bort dem helt och hållet från listan över uppgifter som ska optimeras före uppgraderingen om du inte vill köra dem. Dokumentation om hur du konfigurerar rensningsaktiviteter för arbetsflöden finns på Administering Workflow Instances och konfiguration av underhållsaktiviteter för granskningslogg finns på Revision Log Maintenance i AEM 6.

Mer information om rensning av arbetsflödes- och granskningslogg på CQ 5.6 samt rensning av granskningslogg på AEM 6.0 finns i Rensa arbetsflödes- och granskningsnoder.

Installera, konfigurera och kör föruppgraderingsaktiviteter

På grund av den nivå av anpassning som AEM tillåter, följer miljöer vanligtvis inte ett enhetligt sätt att utföra uppgraderingar. Detta gör det svårt att skapa en standardiserad uppgraderingsprocedur.

I tidigare versioner var det också svårt för AEM uppgraderingar som stoppats eller som inte återställts på ett säkert sätt. Detta ledde till situationer där det var nödvändigt att starta om hela uppgraderingsförfarandet eller där felaktiga uppgraderingar utfördes utan att några varningar utlöstes.

För att åtgärda dessa problem har Adobe lagt till flera förbättringar i uppgraderingsprocessen, vilket gör den mer flexibel och användarvänlig. Underhållsuppgifter före uppgradering som tidigare skulle utföras manuellt optimeras och automatiseras. Rapporter efter uppgraderingen har lagts till så att processen kan granskas i sin helhet i hopp om att problemen blir enklare.

Underhållsuppgifter före uppgradering sprids för närvarande över olika gränssnitt som delvis eller helt utförs manuellt. Den underhållsoptimering före uppgradering som introducerades i AEM 6.3 möjliggör ett enhetligt sätt att utlösa dessa uppgifter och kunna inspektera deras resultat vid behov.

Alla uppgifter som ingår i det föruppgraderade optimeringssteget är kompatibla med alla versioner från och med AEM 6.0.

Konfigurera

I AEM 6.3 och senare finns underhållsoptimeringen i snabbstartsbehållaren. Om du uppgraderar från en äldre version av AEM 6 görs de tillgängliga via separata paket som du kan hämta från pakethanteraren.

Paketen finns på följande platser:

Så här använder du den

PreUpgradeTasksMBean OSGI-komponenten levereras förkonfigurerad med en lista över underhållsåtgärder som kan köras alla samtidigt. Du kan konfigurera uppgifterna genom att följa proceduren nedan:

  1. Gå till webbkonsolen genom att gå till https://serveraddress:serverport/system/console/configMgr

  2. Sök efter "föruppgraderingsuppgifter" och klicka sedan på den första matchande komponenten. Komponentens fullständiga namn är com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl

  3. Ändra listan över underhållsaktiviteter som behöver köras enligt nedan:

    1487758925984

Uppgiftslistan varierar beroende på vilket körningsläge som används för att starta instansen. Nedan visas en beskrivning av det körläge som varje underhållsåtgärd är avsedd för.

Uppgift Körningsläge Anteckningar
TarIndexMergeTask crx2
DataStoreGarbageCollectionTask crx2 Jag kommer att springa mark och svepa. För delade datalager tar du bort det här steget och kör
manuellt eller korrekt förbered instanser innan du kör.
ConsistencyCheckTask crx2
WorkflowPurgeTask crx2/crx3 Du måste konfigurera OSGi för rensningskonfiguration för arbetsflöde för Adobe Granite innan du kör.
GenerateBundlesListFileTask crx2/crx3
RevisionCleanupTask crx3 Om du använder TjäraMK-instanser AEM 6.0 till 6.2 ska du manuellt köra Revision Cleanup offline i stället.
com.day.cq.audit.impl.AuditLogMaintenanceTask crx3 Du måste konfigurera OSGi-konfigurationen för rensning av granskningslogg innan du kör.
FÖRSIKTIGHET

DataStoreGarbageCollectionTask anropar en DataStore-skräpinsamlingsåtgärd med markerings- och svepfasen om en sådan används. För distributioner som använder ett delat datalager måste du antingen konfigurera om det eller konfigurera om det eller förbereda instansen för att undvika att objekt som refereras av en annan instans tas bort. Detta kan kräva att markeringsfasen körs manuellt på alla instanser innan den här föruppgraderingsaktiviteten aktiveras.

Standardkonfiguration för hälsokontroller före uppgradering

PreUpgradeTasksMBeanImpl OSGI-komponenten levereras förkonfigurerad med en lista över hälsokontrollstaggar som ska köras före uppgradering när metoden runAllPreUpgradeHealthChecks anropas:

  • system - den tagg som används av hälsokontroller för granitunderhåll

  • föruppgradering - det här är en anpassad tagg som kan läggas till i alla hälsokontroller som du kan ställa in att köra före en uppgradering

Listan kan redigeras. Du kan använda plus-(+) och minusknapparna (-) förutom taggarna om du vill lägga till fler anpassade taggar, eller ta bort standardknapparna.

MBean-metoder

Du kan komma åt funktionen för hanterade bönor med hjälp av JMX-konsolen.

Du kan komma åt MBeans genom att:

  1. Gå till JMX-konsolen på https://serveraddress:serverport/system/console/jmx

  2. Sök efter PreUpgradeTasks och klicka på resultatet

  3. Välj en metod i avsnittet Åtgärder och välj Anropa i följande fönster.

Nedan visas en lista med alla tillgängliga metoder som visas av PreUpgradeTasksMBeanImpl:

Metodnamn Typ Beskrivning
getAvailablePreUpgradeTasksNames() INFO Visar en lista med tillgängliga namn på underhållsaktiviteter före uppgradering.
getAvailablePreUpgradeHealthChecksTagNames() INFORMATION Visar en lista med taggar för hälsokontroller som är före uppgraderingen.
runAllPreUpgradeTasks() ÅTGÄRD Kör alla underhållsaktiviteter som är före uppgraderingen i listan.
runPreUpgradeTask(preUpgradeTaskName) ÅTGÄRD Kör underhållsaktiviteten före uppgradering med det namn som anges som parameter.
isRunAllPreUpgradeTaskRunning() ACTION_INFO Kontrollerar om runAllPreUpgradeTasksmaintenance-aktiviteten körs.
getAnyPreUpgradeTaskRunning() ACTION_INFO Kontrollerar om någon underhållsaktivitet som körs före uppgraderingen körs och
returnerar en matris som innehåller namnen på de aktiviteter som körs.
getPreUpgradeTaskLastRunTime(preUpgradeTaskName) ÅTGÄRD Visar den exakta körningstiden för underhållsaktiviteten före uppgradering med det namn som anges som parameter.
getPreUpgradeTaskLastRunState(preUpgradeTaskName) ÅTGÄRD Visar det senaste körningstillståndet för underhållsaktiviteten före uppgradering med det namn som anges som parameter.
runAllPreUpgradeHealthChecks(shutDownOnSuccess) ÅTGÄRD

Kör alla hälsokontroller som är före uppgraderingen och sparar deras status i en fil med namnet preUpgradeHCStatus.properties som finns i sökvägen till försäljningsstartsidan. Om parametern shutDownOnSuccess är inställd på true stängs AEM av, men bara om alla hälsokontroller som är före uppgraderingen har statusen OK.

Egenskapsfilen används som ett villkor för framtida uppgraderingar
och uppgraderingsprocessen stoppas om hälsokontrollen
före uppgraderingen misslyckades. Om du vill ignorera resultatet av föruppgraderingen
-hälsokontrollerna och starta uppgraderingen ändå, kan du ta bort filen.

detectUsageOfUnavailableAPI(aemVersion) ÅTGÄRD Visar alla importerade paket som inte längre kommer att uppfyllas när du uppgraderar till den angivna AEM.
AEM måste anges
som parameter.
OBSERVERA

MBean-metoderna kan anropas via:

  • JMX-konsolen
  • Alla externa program som ansluter till JMX
  • cURL

Inaktivera anpassade inloggningsmoduler

OBSERVERA

Det här steget krävs bara om du uppgraderar från en version av AEM 5. Den kan hoppas över helt och hållet för uppgraderingar från äldre AEM 6-versioner.

Det sätt som anpassade LoginModules konfigureras för autentisering på databasnivå har ändrats i Apache Oak.

I AEM versioner som använde CRX2-konfiguration placerades den i filen repository.xml, medan den från och med AEM 6 görs i Apache Felix JAAS Configuration Factory-tjänsten via webbkonsolen.

Alla befintliga konfigurationer måste därför inaktiveras och återskapas för Apache Oak efter uppgraderingen.

Om du vill inaktivera de anpassade moduler som definierats i JAAS-konfigurationen av repository.xml måste du ändra konfigurationen så att standardvärdet LoginModule används, som i det här exemplet:

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

Mer information finns i Autentisering med modulen för extern inloggning.

Ett exempel på LoginModule-konfiguration i AEM 6 finns i Konfigurera LDAP med AEM 6.

Ta bort uppdateringar från /install-katalogen

OBSERVERA

Ta endast bort paket från katalogen crx-quickstart/install när AEM stängts. Detta är ett av de sista stegen innan du startar uppgraderingsproceduren.

Ta bort alla Service Pack, funktionspaket eller snabbkorrigeringar som har distribuerats via katalogen crx-quickstart/install i det lokala filsystemet. Detta förhindrar oavsiktlig installation av gamla snabbkorrigeringar och servicepaket ovanpå den nya AEM när uppdateringen har slutförts.

Stoppa alla väntelägesförekomster i kallt läge

Om du använder kallstart för TjäraMK ska du stoppa alla kalliga standby-instanser. Detta garanterar ett effektivt sätt att komma tillbaka online om det uppstår problem i uppgraderingen. När uppgraderingen har slutförts måste alla instanser av kallstart återskapas från de uppgraderade primära instanserna.

Inaktivera anpassade schemalagda jobb

Inaktivera alla schemalagda OSGi-jobb som ingår i programkoden.

Kör rensning av offlineredigering

OBSERVERA

Detta steg är endast nödvändigt för TjärMK-installationer

Om du använder tarMK bör du köra Revision Cleanup offline innan du uppgraderar. Detta gör att migreringen av databasen och efterföljande uppgraderingsuppgifter går mycket snabbare och säkerställer att rensning av onlineändringar kan utföras korrekt när uppgraderingen har slutförts. Information om hur du kör rensning av offlineredigering finns i Utföra rensning av offlineredigering.

Kör skräpinsamling för datastore

OBSERVERA

Det här steget är bara nödvändigt för instanser som kör crx3

När du har kört revisionsrensning på CRX3-instanser bör du köra Datastore-skräpinsamlingen för att ta bort alla blobbar som inte refereras i datalagret. Instruktioner finns i dokumentationen om skräpinsamlingen för datalagret.

Uppgradera databasschemat om det behövs

Vanligtvis tar den underliggande Apache Oak-stacken AEM använder för beständighet hand om att uppgradera databasschemat vid behov.

Det kan dock inträffa när schemat inte kan uppgraderas automatiskt. Detta är oftast miljöer med hög säkerhet där databasen körs under en användare med mycket begränsade behörigheter. Om detta händer kommer AEM att fortsätta använda det gamla schemat.

För att förhindra att detta händer måste du uppgradera schemat genom att följa nedanstående procedur:

  1. Stäng den AEM som behöver uppgraderas.

  2. Uppgradera databasschemat. Läs dokumentationen om din databastyp för att se vilka verktyg du behöver för att uppnå detta.

    Mer information om hur Oak hanterar schemauppgraderingar finns på den här sidan på Apache-webbplatsen.

  3. Fortsätt med att uppgradera AEM.

Ta bort användare som kan tyda på uppgraderingen

OBSERVERA

Underhållsuppgifterna är bara nödvändiga om:

  • Du uppgraderar från AEM versioner som är äldre än AEM 6.3
  • Du stöter på något av de fel som nämns nedan under uppgraderingen.

Det finns exceptionella fall när tjänstanvändare kan få äldre AEM som felaktigt taggade som vanliga användare.

Om detta inträffar kommer uppgraderingen att misslyckas med ett meddelande som detta:

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.

Se till att du gör följande för att lösa problemet:

  1. Frigör instansen från produktionstrafiken

  2. Skapa en säkerhetskopia av de användare som orsakar problemet. Det kan du göra via Package Manager. Mer information finns i Arbeta med paket.

  3. Ta bort de användare som orsakar problemet. Nedan finns en lista över användare som kan ingå i den här kategorin:

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

Rotera loggfiler

Vi rekommenderar att du arkiverar dina aktuella loggfiler innan du påbörjar uppgraderingen. Detta gör det enklare att övervaka och söka igenom loggfilerna under och efter uppgraderingen för att identifiera och lösa eventuella problem som kan uppstå.

På denna sida