GoLive

Senaste uppdatering: 2023-12-05

Under den här delen av resan får du lära dig att planera och utföra migreringen när både koden och innehållet är klara att flyttas över till AEM as a Cloud Service. Du får också lära dig vilka metoder och begränsningar som är bäst när du utför migreringen.

Story hittills

I de föregående faserna av resan:

  • Du lärde dig att komma igång med övergången till AEM as a Cloud Service i Komma igång sida.
  • Fastställd om distributionen är klar att flyttas till molnet genom att läsa Beredskapsfas
  • Bekanta dig med verktygen och processen som gör koden och innehållet molnklart med Implementeringsfas.

Syfte

Det här dokumentet hjälper dig att förstå hur du utför migreringen till AEM as a Cloud Service när du känner till de tidigare stegen under resan. Du lär dig hur du utför den inledande produktionsmigreringen och de bästa arbetssätten att följa när du migrerar till AEM as a Cloud Service.

Inledande produktionsmigrering

Innan du kan utföra produktionsmigreringen följer du stegen för implementering och korrektur av migrering i Strategi för innehållsmigrering och tidslinje i Implementeringsfas.

  • Starta migreringen från produktionen baserat på den erfarenhet du fick under den AEM as a Cloud Service migreringen av scenen som utfördes på kloner:

    • Författare/Författare
    • Publish-Publish

  • Validera det innehåll som är inkapslat i både den AEM as a Cloud Service författaren och publiceringsnivån.

  • Instruera innehållsredigeringsteamet att undvika att flytta innehåll på både källa och mål tills det är fullständigt

  • Nytt innehåll kan läggas till, redigeras eller tas bort, men du kan inte flytta det. Detta gäller både källa och mål.

  • Spela in tid för fullständig extrahering och förtäring för att få en uppskattning av framtida tidslinjer för migrering uppifrån och ned.

  • Skapa en migreringsplanering för både författare och publicering.

Inkrementella överkanter

Efter den första migreringen från produktionen måste du utföra stegvisa översikter för att se till att ditt innehåll är uppdaterat på molninstansen. Därför rekommenderar vi att du följer dessa bästa metoder:

  • Samla in data om mängden innehåll. Exempel: per en vecka, två veckor eller en månad.
  • Se till att planera de översta bilderna på ett sådant sätt att du undviker mer än 48 timmars extrahering och förtäring av innehåll. Detta rekommenderas så att de översta delarna av innehållet får plats i en heltalsram.
  • Planera antalet toppavhopp och använd dessa uppskattningar för att planera runt Go-Live-datumet.

Identifiera tidslinjer för att migrera kod och innehåll för frysning

Som tidigare nämnts måste du schemalägga en frysperiod för kod och innehåll. Använd följande frågor för att planera frysningsperioden:

  • Hur länge måste jag frysa innehållsredigeringsaktiviteterna?
  • Hur länge ska jag be mitt leveransteam sluta lägga till nya funktioner?

Som svar på den första frågan bör du fundera över hur lång tid det har tagit att genomföra testkörningar i icke-produktionsmiljöer. För att svara på den andra frågan behöver du ha ett nära samarbete mellan teamet som lägger till nya funktioner och teamet som omfaktoriserar koden. Målet är att se till att all kod som läggs till i den befintliga distributionen också läggs till, testas och distribueras till molntjänstgrenen. Vanligtvis innebär det att mängden fryst kod är lägre.

Dessutom måste ni planera för en frysning av innehållet när den slutliga innehållstillägget är schemalagd.

Bästa praxis

När du planerar eller utför migreringen bör du tänka på följande riktlinjer:

  • Migrera från författare till författare och publicera till publicera
  • Begär en produktionskloning som kan användas för att:
    • Hämta databasstatistik
    • Bevis på migrationsverksamhet
    • Förbered migreringsplanen
    • Identifiera krav på frysning av innehåll
    • Identifiera alla uppgraderingsbehov i produktionen vid migrering från produktionen

Metodtips för verktyget Innehållsöverföring

Se till att du kör innehållsmigreringen i produktion i stället för en klon när du publicerar. Ett bra sätt är att använda AZCopy för den initiala migreringen och kör sedan extraheringar uppifrån ofta (t.o.m. dagligen) för att extrahera mindre bitar och undvika långvarig belastning på AEM.

När du utför produktionsmigreringen bör du undvika att köra verktyget Innehållsöverföring från en klon eftersom:

  • Om en kund kräver att innehållsversioner migreras under en översta migrering migreras inte versionerna när innehållsöverföringsverktyget körs från en klon. Även om klonen ofta återskapas från en live-författare återställs de kontrollpunkter som används av verktyget Innehållsöverföring för att beräkna deltarna varje gång en klon skapas.
  • Eftersom en klon inte kan uppdateras som helhet måste ACL-frågepaketet användas för att paketera och installera det innehåll som läggs till eller redigeras från produktion till kloning. Problemet med den här metoden är att allt borttaget innehåll i källinstansen aldrig kommer till klonen om det inte tas bort manuellt från både källan och klonen. Detta introducerar möjligheten att det borttagna innehållet i produktionen inte tas bort på klonen och AEM as a Cloud Service.

Optimera inläsningen på AEM när innehållsmigreringen utförs

Kom ihåg att belastningen på AEM är större under extraheringsfasen. Tänk på följande:

  • Innehållsöverföringsverktyget är en extern Java-process som använder en JVM-heap på 4 GB
  • Icke-AzCopy-versionen hämtar binärfiler, lagrar dem på ett temporärt utrymme på AEM, förbrukar disk-I/O och överför dem sedan till Azure-behållaren som förbrukar nätverksbandbredd
  • AzCopy överför blobbar direkt från blobbarkivet till Azure-behållaren som sparar disk-I/O och nätverksbandbredd. AzCopy-versionen använder fortfarande disk- och nätverksbandbredd för att extrahera och överföra data från segmentlagret till Azure-behållaren
  • Processen med verktyget Innehållsöverföring är ljusare på systemresurserna under överföringsfasen, eftersom det bara strömmar matningsloggar och det inte finns mycket belastning på källinstansen vad gäller disk-I/O eller nätverksbandbredd.

Kända begränsningar

Ta hänsyn till att hela intaget misslyckas om någon av följande begränsningar påträffas som en del av den extraherade migreringsuppsättningen:

  • En JCR-nod med ett namn som är längre än 150 tecken
  • En JCR-nod som är större än 16 MB
  • Alla användare/grupper med rep:AuthorizableID som redan finns på AEM as a Cloud Service
  • Om en resurs som extraheras och hämtas flyttas till en annan sökväg, antingen på källan eller på målet, före nästa iteration av migreringen.

Resurshälsa

Jämfört med avsnittet ovanför intaget inte misslyckas på grund av följande problem med tillgångar. Vi rekommenderar dock att du vidtar lämpliga åtgärder i följande situationer:

  • Alla resurser som har den ursprungliga återgivningen saknas
  • Alla mappar som saknas jcr:content nod.

Båda ovanstående poster identifieras och rapporteras i Best Practice Analyzer rapport.

GoLive Checklist

Granska den här listan över aktiviteter för att säkerställa att du utför en smidig och lyckad migrering.

  • Köra en produktionsprocess från början till slut med funktions- och gränssnittstestning för att säkerställa en alltid aktuell AEM produktupplevelse. Se följande resurser.
  • Migrera innehåll till produktion och se till att det finns en relevant delmängd tillgänglig på testningen.
    • DevOps bästa praxis för AEM innebär att koden går från utveckling till produktionsmiljö medan innehållet rör sig från produktionsmiljöer.
  • Schemalägg en frysperiod för kod och innehåll.
  • Utför den slutliga innehållsuppsättningen.
  • Validera dispatcherkonfigurationer.
    • Använd en lokal dispatchervaliderare som gör det lättare att konfigurera, validera och simulera avsändaren lokalt
    • Granska konfigurationen av det virtuella värdsystemet noggrant.
      • Den enklaste (och standardlösningen) är att inkludera ServerAlias * i din virtuella värdfil i /dispatcher/src/conf.d/available_vhostsfolder.
        • Detta gör att värdaliasen som används av produktfunktionstester, invalidering av dispatchercache och kloner kan fungera.
      • Om ServerAlias * är inte acceptabelt, åtminstone följande ServerAlias poster måste tillåtas utöver dina anpassade domäner:
        • localhost
        • *.local
        • publish*.adobeaemcloud.net
        • publish*.adobeaemcloud.com
  • Konfigurera CDN, SSL och DNS.
    • Om du använder ditt eget CDN anger du en supportanmälan för att konfigurera lämplig routning.
    • Om du inte använder ytterligare ett CDN hanterar du SSL och DNS enligt följande dokumentation:
    • Kom ihåg att validera TTL-inställningen för din DNS-post.
      • TTL är den tid som en DNS-post finns kvar i ett cacheminne innan servern tillfrågas om en uppdatering.
      • Om du har en mycket hög TTL tar det längre tid att sprida uppdateringar till DNS-posten.
  • Kör prestanda- och säkerhetstester som uppfyller dina affärskrav och mål.
  • Klipp ut och se till att den faktiska publiceringen utförs utan någon ny driftsättning eller uppdatering av innehållet.
  • Skapa meddelandeprofiler för Admin Console. Se Meddelandeprofiler

Du kan alltid referera till listan om du behöver kalibrera om dina uppgifter när du utför migreringen.

What's Next

När du förstår hur du utför migreringen till AEM as a Cloud Service kan du kontrollera Post-Go-Live sida för att få instansen att löpa smidigt.

Föregående sida
Next page

På denna sida