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. Dessutom får du lära dig vad som är bästa praxis och kända begränsningar 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 får lära dig att utföra den inledande produktionsmigreringen samt de bästa arbetssätten att följa när du migrerar till AEM as a Cloud Service.
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. Till exempel: 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 redigeringsaktiviteterna?
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 omstrukturerar koden. Målet bör vara att se till att all kod som läggs till i den befintliga distributionen också läggs till, testas och distribueras till molntjänstgrenen. I allmänhet innebär detta att mängden fryst kod blir lägre.
Dessutom måste du planera för en frysning av innehållet när den slutliga innehållsuppdateringen ä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 ska användas 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 belastningen på AEM när innehållsmigreringen utförs
Kom ihåg att belastningen på AEM blir större under extraheringsfasen. Du bör vara medveten om att
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
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.
Observera att de bästa sätten för DevOps för AEM innebär att koden går från utveckling till produktionsmiljö medan innehållet går ned från produktionsmiljöer.
För att vara säker på att DNS-rensningen inte kommer att orsaka oväntade problem är det bäst att skapa en testunderdomän för att ansluta din produktionsinstans till innan du publicerar och göra en omgång av UAT-testning. Om din domän är example.com kan du skapa en subdomain test.example.com och använda den i produktionen. Under UAT-testningen av domänen ska du söka efter saker som rätt länkomdirigering, cachelagring och dispatcherkonfigurationer.