Aanbevolen implementaties recommended-deployments
MicroKernels fungeren vanaf AEM 6.2 als persistentiemanagers. Het kiezen van één om uw behoeften te passen hangt van het doel van uw instantie en het plaatsingstype af u overweegt.
De volgende voorbeelden moeten een indicatie zijn van wat hun aanbevolen gebruik in de meest gebruikelijke AEM is.
Implementatiescenario's deployment-scenarios
Single TarMK-instantie single-tarmk-instance
In dit scenario, loopt één enkele instantie TarMK op één enkele server.
dit is de standaardplaatsing voor auteursinstanties.
De voordelen:
- eenvoudig
- Eenvoudig onderhoud
- Goede prestaties
De nadelen:
- Niet schaalbaar buiten de grenzen van de servercapaciteit
- Geen failover-capaciteit
TarMK Cold Standby tarmk-cold-standby
Eén TarMK-instantie fungeert als de primaire instantie. De opslagplaats van de primaire opslagplaats wordt gerepliceerd naar een stand-by failover-systeem.
Het koude reservemechanisme kan ook als steun worden gebruikt omdat de volledige bewaarplaats constant aan de failoverserver wordt herhaald. De failoverserver loopt op koude reservewijze, wat betekent dat slechts HttpReceiver van de instantie loopt.
De voordelen:
- Eenvoud
- Onderhoudsmogelijkheden
- Prestaties
- Failover
De nadelen:
- Niet schaalbaar buiten de grenzen van de servercapaciteit
- Eén server is meestal inactief
- De failover is niet automatisch. Het moet extern worden ontdekt alvorens het failoversysteem verzoeken kan beginnen te dienen.
TarMK Farm tarmk-farm
Meerdere Oak-instanties voeren elk uit met één TarMK-instantie. De TarMK-opslagplaatsen zijn onafhankelijk en moeten gesynchroniseerd blijven.
Het houden van de bewaarplaatsen in synchronisatie wordt voorzien van het feit dat de auteurserver de zelfde inhoud aan elk landbouwbedrijflid publiceert. Voor meer informatie, zie Replicatie.
Voor AEM Communities wordt door de gebruiker gegenereerde inhoud (UGC) nooit gerepliceerd. Voor het steunen van UGC op een Farm TarMK, zie overwegingen voor AEM Communities.
dit is de standaardplaatsing voor publiceer milieu's.
De voordelen:
- Prestaties
- Schaalbaarheid voor leestoegang
- Failover
Oak Cluster met MongoMK-failover voor hoge beschikbaarheid in één datacenter oak-cluster-with-mongomk-failover-for-high-availability-in-a-single-datacenter
Deze aanpak impliceert dat meerdere Oak-instanties toegang hebben tot een MongoDB-replica die is ingesteld binnen één datacenter. In feite wordt er een actief-actief cluster voor de AEM auteuromgeving gemaakt. Replicasets in MongoDB worden gebruikt om hoge beschikbaarheid en redundantie te bieden in het geval van een hardware- of netwerkstoring.
De voordelen:
- De mogelijkheid om horizontaal te schalen met nieuwe AEM auteur-instanties
- Hoge beschikbaarheid, overtolligheid, en geautomatiseerde failover van gegevenslaag
De nadelen:
- De prestaties kunnen lager zijn dan met TarMK voor sommige scenario's
Oak-cluster met MongoMK-failover over meerdere datacenters oak-cluster-with-mongomk-failover-across-multiple-datacenters
Deze aanpak impliceert dat meerdere Oak-instanties toegang hebben tot een MongoDB-replica die in meerdere datacenters is ingesteld. In feite wordt er een actief-actief cluster voor de AEM auteuromgeving gemaakt. Met meerdere datacenters biedt de replicatie van MongoDB dezelfde hoge beschikbaarheid en redundantie, maar nu ook de mogelijkheid om een storing in het datacenter te verwerken.
De voordelen:
- De mogelijkheid om horizontaal te schalen met nieuwe AEM auteur-instanties
- Hoge beschikbaarheid, overtolligheid, en geautomatiseerde failover van gegevenslaag (met inbegrip van gegevenscentrumstroomonderbrekingen)
Microkorrels: één voor gebruik microkernels-which-one-to-use
De basisregel waarmee rekening moet worden gehouden bij het kiezen tussen de twee beschikbare microkorrels is dat TarMK ontworpen is voor prestaties, terwijl MongoMK wordt gebruikt voor schaalbaarheid.
U kunt deze besluitmatrices gebruiken om te bepalen wat het beste type implementatie is dat aan uw vereisten is aangepast.
De Adobe adviseert hoogst TarMK om de standaardpersistentietechnologie te zijn die door klanten in alle plaatsingsscenario's, voor zowel de AEM Auteur als de instanties van Publish wordt gebruikt, behalve in de hieronder geschetste gebruiksgevallen.
Uitzonderingen voor het kiezen van AEM MongoMK in TarMK op authorinstanties exceptions-for-choosing-aem-mongomk-over-tarmk-on-author-instances
De primaire reden voor het kiezen van de MongoMK persistence backend over TarMK is de instanties horizontaal te schalen. Dit betekent dat er altijd twee of meer actieve auteur-instanties moeten worden uitgevoerd en dat MongoDB moet worden gebruikt als het opslagsysteem voor persistentie. De noodzaak om meer dan één auteurinstantie in werking te stellen vloeit over het algemeen voort uit het feit dat de cpu en geheugencapaciteit van één enkele server, die alle gezamenlijke auteursactiviteiten steunt, niet meer duurzaam is.
Het is bijna onmogelijk om te voorspellen wat het precieze gelijktijdige model zal zijn nadat een nieuwe site live gaat. Daarom adviseert de Adobe u de volgende criteria in overweging te nemen wanneer het evalueren of om MongoMK en twee of meer Actieve knopen van de Auteur te gebruiken:
- Aantal benoemde gebruikers verbonden in een dag: in de duizenden of meer.
- Aantal gelijktijdige gebruikers: in honderden of meer.
- Hoeveelheid ingenomen activa per dag: in honderdduizenden of meer.
- Volume van paginabewerkingen per dag: in honderdduizenden of meer (inclusief automatische updates via Meerdere Sitebeheer of inname van nieuwsberichten).
- Aantal zoekopdrachten per dag: in tienduizenden of meer.
Een minimumplaatsing met MongoDB zal typisch de volgende topologie impliceren:
- Een MongoDB-replicaset bestaande uit één primair knooppunt, twee secundaire knooppunten met elk van de MongoDB-instanties die in een beschikbaarheidszone met een latentie onder 15 milliseconden op elk knooppunt worden uitgevoerd;
- Een cluster van auteurinstanties met één leaderknoop, één niet-leaderknooppunt en beide actief op elk moment, met elk van de auteurinstanties die in elk van de datacenters worden uitgevoerd, waar de primaire en secundaire MongoDB-instanties worden uitgevoerd.
Daarnaast wordt het ten zeerste aanbevolen de datastore op een gedeeld bestandssysteem of Amazon S3 te configureren, zodat de elementen of binaire bestanden niet in MongoDB worden opgeslagen. Dit zorgt voor optimale prestaties binnen de implementatie.
Een van de extra voordelen van de implementatie van een MongoDB-replicaset met een cluster van twee of meer auteurinstanties is dat er een geautomatiseerd herstelscenario met minimale downtime bestaat als er auteurinstanties, MongoDB-replica of een volledige datacenterfout zijn. Niettemin zou de keuze van MongoMK over TarMK niet alleen door het terugwinningsvereiste moeten worden gedreven, aangezien TarMK ook een minimale downtime oplossing met een gecontroleerd failovermechanisme kan verstrekken.
Als de bovenstaande criteria naar verwachting niet tijdens de eerste 18 maanden van plaatsing zullen worden vervuld, wordt het aangemoedigd eerst AEM op te stellen gebruikend TarMK, dan uw configuratie op een recentere datum opnieuw te evalueren wanneer de bovengenoemde criteria van toepassing zijn, en definitief te bepalen of om op TarMK te blijven of aan MongoMK te migreren.
Uitzonderingen voor het kiezen van AEM MongoMK in plaats van TarMK in Publish-instanties exceptions-for-choosing-aem-mongomk-over-tarmk-on-publish-instances
Het wordt afgeraden MongoMK te implementeren voor publicatie-instanties. De publicatielaag van de plaatsing wordt bijna altijd opgesteld als landbouwbedrijf van volledig onafhankelijke publiceer instanties die TarMK in werking stellen, die in synchronisatie door inhoud van de auteursinstanties te herhalen worden gehouden. Deze "gedeelde niets"architectuur, behoorlijk aan de publiceer instanties, staat de plaatsing van toe publiceert rij om horizontaal op een lineaire manier te schrapen. De landbouwbedrijftopologie verstrekt ook het voordeel om het even welke update of verbetering toe te passen om instanties op een voortschrijdende basis te publiceren, zodat om het even welke verandering in publiceer rij geen onderbreking zal vereisen.
Dit is niet van toepassing op AEM Communities die MongoMK-clusters gebruikt op de publicatielijst als er meerdere uitgevers zijn. Als het kiezen van JSRP (zie Communautaire Opslag van de Inhoud), dan zou een cluster MongoMK aangewezen zijn, zoals om het even welke te publiceren zijcluster ongeacht MK gekozen, zoals MongoDB of RDB.
Vereisten en Recommendations bij de implementatie van AEM met MongoMK prerequisites-and-recommendations-when-deploying-aem-with-mongomk
Een reeks eerste vereisten en aanbevelingen is beschikbaar als u een plaatsing MongoMK voor AEM overweegt:
Verplichte eerste vereisten voor plaatsingen MongoDB:
- De mongoDB-implementatiearchitectuur en -grootte moeten deel uitmaken van de projectimplementatie met hulp van Adobe Consulting- of MongoDB-architecten die vertrouwd zijn met AEM;
- De deskundigheid MongoDB moet binnen de partner of het klantenteam aanwezig zijn om vertrouwen in het kunnen een bestaande of nieuwe milieu te kunnen handhaven MongoDB;
- U kunt ervoor kiezen om de commerciële of open-sourceversie van MongoDB te implementeren (AEM ondersteunt beide), maar u moet rechtstreeks een MongoDB-onderhouds- en ondersteuningscontract aanschaffen bij MongoDB Inc;
- De algemene AEM en MongoDB-architecturen en -infrastructuren moeten duidelijk gedefinieerd en gevalideerd worden door een Adobe AEM architect;
- Controleer het supportmodel voor AEM implementaties die MongoDB bevatten.
Sterke aanbevelingen voor plaatsingen MongoDB:
Overwegingen voor AEM Communities considerations-for-aem-communities
Voor plaatsen die van plan zijn om AEM Communitiesop te stellen, wordt het geadviseerd een plaatsingte kiezen die voor behandeling van UGC door communautaire leden van het publicatiemilieu wordt gepost.
Door a gemeenschappelijke opslagte gebruiken, te hoeven UGC niet tussen auteur worden herhaald en andere publiceer instanties om een verenigbare mening van UGC te verkrijgen.
Hieronder vindt u een reeks beslissingsmatrixen die u kunnen helpen bij het kiezen van het beste type persistentie voor uw implementatie:
Het implementatietype kiezen voor auteur-instanties choosing-the-deployment-type-for-author-instances
Het implementatietype kiezen voor publicatie-instanties choosing-the-deployment-type-for-publish-instances
