Rekommenderade distributioner recommended-deployments
MicroKernels fungerar som persistencehanterare i AEM 6.4. Vilken som passar dina behov beror på syftet med instansen och vilken distributionstyp du överväger.
Exemplen nedan är avsedda att vara en indikation på vad som rekommenderas i de vanligaste AEM.
Distributionsscenarier deployment-scenarios
Single tarMK-instans single-tarmk-instance
I det här scenariot körs en enda tarMK-instans på en enda server.
Det här är standarddistributionen för författarinstanser.
Fördelarna:
- Enkel
- Smidigt underhåll
- Bra prestanda
Nackdelar:
- Kan inte skalas utanför serverkapacitetens gränser
- Ingen failover-kapacitet
StjärtMK i kallt vänteläge tarmk-cold-standby
En tarMK-instans fungerar som primär instans. Databasen från den primära databasen replikeras till ett standby-failover-system.
Kylstandbyfunktionen kan också användas som säkerhetskopia eftersom hela databasen hela tiden replikeras till redundansservern. Redundansservern körs i kallt vänteläge, vilket innebär att det bara är HttpReceiver för instansen som körs.
Fördelarna:
- Enkelt
- Underhållbarhet
- Prestanda
- Redundans
Nackdelar:
- Kan inte skalas utanför serverkapacitetens gränser
- En server är inaktiv för det mesta
- Redundansväxlingen är inte automatisk. Den måste identifieras externt innan redundanssystemet kan börja skicka begäranden.
TARMK Farm tarmk-farm
Flera Oak-instanser körs var och en med en tarMK-instans. TarmMK-databaserna är oberoende och måste synkroniseras.
Att synkronisera databaserna tillhandahålls med det faktum att författarservern publicerar samma innehåll till varje gruppmedlem. Mer information finns i Replikering.
För AEM Communities replikeras aldrig användargenererat innehåll (UGC). Information om stöd för UGC på en tarMK-grupp finns i överväganden för AEM Communities.
Det här är standarddistributionen för publiceringsmiljöer.
Fördelarna:
- Prestanda
- Skalbarhet för läsåtkomst
- Redundans
Oak Cluster med MongoMK Failover för hög tillgänglighet i ett och samma datacenter oak-cluster-with-mongomk-failover-for-high-availability-in-a-single-datacenter
Detta innebär att flera Oak-instanser får åtkomst till en MongoDB-replikuppsättning i ett enda datacenter, vilket skapar ett aktivt kluster för AEM. Replikuppsättningar i MongoDB används för hög tillgänglighet och redundans i händelse av maskinvaru- eller nätverksfel.
Fördelarna:
- Skala vågrätt med nya AEM
- Hög tillgänglighet, redundans och automatiserad failover av datalager
Nackdelar:
- Prestanda kan vara lägre än med tarMK för vissa scenarier
Oak Cluster med MongoMK Failover över flera datacenter oak-cluster-with-mongomk-failover-across-multiple-datacenters
Detta innebär att flera Oak-instanser använder en MongoDB-replikuppsättning över flera datacenter, vilket skapar ett aktivt kluster för AEM. Med flera datacenter ger MongoDB-replikering samma höga tillgänglighet och redundans, men nu även möjligheten att hantera ett datacenteravbrott.
Fördelarna:
- Skala vågrätt med nya AEM
- Hög tillgänglighet, redundans och automatiserad failover för datalager (inklusive datacenteravbrott)
Mikrokärnor: som ska användas microkernels-which-one-to-use
Den grundläggande regel som måste beaktas när man väljer mellan de två tillgängliga mikrokärnor är att tarMK är utformad för prestanda, medan MongoMK används för skalbarhet.
Du kan använda de här beslutsmatriserna för att fastställa vilken typ av distribution som passar dina behov bäst.
Adobe rekommenderar starkt att TjärMK är standardbeständighetstekniken som används av kunder i alla distributionsscenarier, både för AEM Author- och Publish-instanserna, utom i de fall som beskrivs nedan.
Undantag för att välja AEM MongoMK över tarMK för författarinstanser exceptions-for-choosing-aem-mongomk-over-tarmk-on-author-instances
Den främsta anledningen till att du väljer MongoMK-beständighetsbackend framför tarMK är att skalförändra instanserna vågrätt. Det innebär att två eller flera aktiva författarinstanser alltid körs och att MongoDB används som beständigt lagringssystem. Behovet av att köra mer än en författarinstans beror i allmänhet på att processorn och minneskapaciteten på en enda server, som stöder alla samtidiga redigeringsaktiviteter, inte längre är hållbara.
Det är nästan omöjligt att förutsäga exakt vilken samtidighetsmodell som kommer att bli när en ny webbplats publiceras. Adobe rekommenderar därför att du överväger följande kriterier när du utvärderar om du ska använda MongoMK och två eller flera Author active-noder:
- Antal namngivna användare anslutna under en dag: i tusental eller mer.
- Antal samtidiga användare: i hundratals eller fler.
- Volym för tillgångsinmatningar per dag: på hundratusentals eller fler.
- Antal sidredigeringar per dag: i hundratusentals eller fler (inklusive automatiserade uppdateringar via Multi Site Manager eller nyhetsfeed-frågor till exempel).
- Antal sökningar per dag: på tiotusentals eller fler.
En minimidistribution med MongoDB omfattar vanligtvis följande topologi:
- En MongoDB-replikuppsättning bestående av en primär nod, två sekundära noder där var och en av MongoDB-instanserna körs i en tillgänglighetszon med en latens på mindre än 15 millisekunder över varje nod.
- Ett kluster med författarinstanser med en ledarnod, en icke-ledarnod och båda är aktiva samtidigt, där var och en av författarinstanserna körs i varje datacentral, där den primära och sekundära instansen MongoDB körs.
Vi rekommenderar dessutom att du konfigurerar datalagret i ett delat filsystem eller i Amazon S3 så att resurserna eller binärfilerna inte lagras i MongoDB. Detta ger optimala prestanda i driftsättningen.
En av de extra fördelarna med att distribuera en MongoDB-replikuppsättning med ett kluster med två eller flera författarinstanser är att ha ett automatiskt återställningsscenario med minimalt driftstopp om en författarinstans, MongoDB-replikering eller ett fullständigt datacenterfel uppstår. Valet av MongoMK framför tarMK bör dock inte enbart styras av återhämtningskravet, eftersom tarMK också kan tillhandahålla en minimalt låg driftstoppslösning med en kontrollerad failover-mekanism.
Om ovanstående kriterier inte förväntas vara uppfyllda under de första 18 månaderna av driftsättningen bör du först distribuera AEM med hjälp av tarMK, sedan utvärdera konfigurationen vid ett senare tillfälle när ovanstående villkor är uppfyllda och slutligen avgöra om du ska stanna kvar på tarMK eller migrera till MongoMK.
Undantag för att välja AEM MongoMK över tarMK för publiceringsinstanser exceptions-for-choosing-aem-mongomk-over-tarmk-on-publish-instances
Vi rekommenderar inte att du distribuerar MongoMK för publiceringsinstanser. Distributionsskiktet distribueras nästan alltid som en grupp fullständigt oberoende publiceringsinstanser som kör tarMK, som synkroniseras genom att replikera innehåll från författarinstanserna. Denna"delade ingenting"-arkitektur, som är rätt för publiceringsinstanserna, gör att publiceringsnivån kan skalas vågrätt på ett linjärt sätt. Servergruppstopologin ger också fördelen att använda uppdateringar eller uppgraderingar för att publicera instanser rullande, så att inga ändringar i publiceringsnivån kräver några driftavbrott.
Detta gäller inte AEM Communities som använder MongoMK-kluster på publiceringsnivån när det finns fler än en utgivare. Om du väljer JSRP (se Community-innehåll) skulle ett MongoMK-kluster vara lämpligt, precis som alla publiceringssidkluster, oavsett vilken MK som valts, till exempel MongoDB eller RDB.
Förutsättningar och Recommendations när AEM distribueras med MongoMK prerequisites-and-recommendations-when-deploying-aem-with-mongomk
En uppsättning förutsättningar och rekommendationer är tillgängliga om du överväger en MongoMK-distribution för AEM:
Obligatoriska krav för MongoDB-distributioner:
- MongoDB:s driftsättningsarkitektur och storlek måste ingå i projektimplementeringen med hjälp av Adobe Consulting eller MongoDB-arkitekter som är bekanta med AEM.
- MongoDB-expertis måste finnas i partner- eller kundteamet för att man ska kunna behålla och underhålla en befintlig eller ny MongoDB-miljö.
- Du kan välja att driftsätta den kommersiella versionen eller versionen med öppen källkod av MongoDB (AEM stöder båda), men du måste köpa ett MongoDB Maintenance and Support-avtal direkt från MongoDB Inc.
- De övergripande arkitekturerna och infrastrukturerna för AEM och MongoDB bör vara väl definierade och validerade av en Adobe AEM Architect.
- Du måste granska supportmodellen för AEM distributioner som innehåller MongoDB.
Starka rekommendationer för MongoDB-distributioner:
- Läs MongoDB för Adobe Experience Manager artikel;
- Granska MongoDB-produktionen checklista;
- Delta i en certifieringsklass på MongoDB som är tillgänglig online här.
Överväganden för AEM Communities considerations-for-aem-communities
För platser som ska distribueras AEM Communitiesrekommenderas att välj en distribution optimerad för hantering av UGC som publicerats av communitymedlemmar från publiceringsmiljön.
Genom att använda en gemensam lagringsplatsbehöver inte UGC replikeras mellan författaren och andra publiceringsinstanser för att få en konsekvent vy över UGC.
Nedan finns en uppsättning beslutsmatriser som kan hjälpa dig att välja den bästa typen av beständighet för din distribution:
Välja distributionstyp för författarinstanser choosing-the-deployment-type-for-author-instances
Välja distributionstyp för publiceringsinstanser choosing-the-deployment-type-for-publish-instances
