Implementazioni consigliate

I MicroKernel fungono da gestori di persistenza a partire da AEM 6.2. La scelta di uno per soddisfare le tue esigenze dipende dallo scopo della tua istanza e dal tipo di distribuzione che stai considerando.

Gli esempi seguenti sono intesi come un'indicazione degli usi raccomandati nelle impostazioni di AEM più comuni.

Scenari di distribuzione

Istanza singola TarMK

In questo scenario, una singola istanza TarMK viene eseguita su un singolo server.

Questa è la distribuzione predefinita per le istanze di authoring.

I vantaggi:

• Semplici
• Manutenzione semplice
• Buone prestazioni

Gli svantaggi:

• Non scalabile oltre i limiti di capacità del server
• Nessuna capacità di failover

Standby a freddo TarMK

Un'istanza TarMK agisce come istanza primaria. L'archivio dal primario viene replicato in un sistema di failover in standby.

Il meccanismo di standby a freddo può essere utilizzato anche come backup perché l'archivio completo viene costantemente replicato nel server di failover. Il server di failover è in esecuzione in modalità standby a freddo, il che significa che è in esecuzione solo l'HttpReceiver dell'istanza.

I vantaggi:

• Semplicità
• Manutenzione
• Spettacolo
• Failover

Gli svantaggi:

• Non scalabile oltre i limiti della capacità del server
• Un server è inattivo per la maggior parte del tempo
• Il failover non è automatico. Deve essere rilevato esternamente prima che il sistema di failover possa iniziare a servire le richieste.

Fattoria TarMK

Più istanze Oak vengono eseguite ciascuna con un'istanza TarMK. Gli archivi TarMK sono indipendenti e devono essere mantenuti sincronizzati.

Mantenere gli archivi sincronizzati viene fornito con il fatto che il server di authoring pubblica lo stesso contenuto su ogni membro della farm. Per ulteriori informazioni, consulta Replica.

Per AEM Communities, il contenuto generato dall’utente (UGC) non viene mai replicato. Per il supporto di UGC su un farm TarMK, vedi considerazioni per AEM Communities.

Questa è la distribuzione predefinita per gli ambienti di pubblicazione.

I vantaggi:

• Spettacolo
• Scalabilità per l'accesso in lettura
• Failover

Cluster Oak con failover MongoMK per un'elevata disponibilità in un singolo centro dati

Questo approccio implica l'accesso di più istanze Oak a un set di repliche MongoDB all'interno di un singolo data center, in effetti creando un cluster attivo-attivo per l'ambiente di authoring AEM. I set di replica in MongoDB vengono utilizzati per fornire elevata disponibilità e ridondanza in caso di guasto dell'hardware o della rete.

I vantaggi:

• Possibilità di scalare orizzontalmente con nuove istanze di authoring AEM
• Elevata disponibilità, ridondanza e failover automatizzato del livello dati

Gli svantaggi:

• Le prestazioni possono essere inferiori a quelle di TarMK per alcuni scenari

Cluster Oak con failover MongoMK in più centri dati

Questo approccio implica l'accesso di più istanze Oak a un set di repliche MongoDB su più data center, in effetti creando un cluster attivo-attivo per l'ambiente di authoring AEM. Con più data center, la replica MongoDB fornisce la stessa elevata disponibilità e ridondanza, ma ora include la possibilità di gestire un'interruzione del data center.

I vantaggi:

• Possibilità di scalare orizzontalmente con nuove istanze di authoring AEM
• Elevata disponibilità, ridondanza e failover automatizzato dei livelli dati (comprese le interruzioni dei centri dati)

Microcanali: quale utilizzare

La regola di base di cui tenere conto nella scelta tra i due micro kernel disponibili è che TarMK è progettato per le prestazioni, mentre MongoMK è utilizzato per la scalabilità.

Puoi utilizzare queste matrici decisionali per stabilire quale sia il tipo di distribuzione più adatto alle tue esigenze.

Adobe consiglia vivamente a TarMK di essere la tecnologia di persistenza predefinita utilizzata dai clienti in tutti gli scenari di implementazione, sia per le istanze di authoring e pubblicazione di AEM, eccetto nei casi d’uso descritti di seguito.

Eccezioni per la scelta AEM MongoMK su TarMK sulle istanze di authoring

La ragione principale per scegliere il backend di persistenza MongoMK su TarMK è la scalabilità orizzontale delle istanze. Ciò significa che due o più istanze di authoring attive vengono sempre in esecuzione e utilizzano MongoDB come sistema di storage di persistenza. La necessità di eseguire più di un'istanza dell'autore deriva generalmente dal fatto che la CPU e la capacità di memoria di un singolo server, che supportano tutte le attività di authoring simultanee, non sono più sostenibili.

È quasi impossibile prevedere quale sarà l'esatto modello di concorrenza dopo la pubblicazione di un nuovo sito. Pertanto, l'Adobe consiglia di considerare i seguenti criteri quando si valuta se utilizzare MongoMK e due o più nodi attivi Autore:

1. Numero di utenti denominati connessi in un giorno: in migliaia o più.
2. Numero di utenti simultanei: nelle centinaia o più.
3. Volume di ingestioni di risorse al giorno: a centinaia di migliaia o più.
4. Volume di modifiche alla pagina al giorno: in centinaia di migliaia o più (inclusi gli aggiornamenti automatizzati tramite Multi Site Manager o news feed, ad esempio).
5. Volume di ricerche al giorno: in decine di migliaia o più.

Una distribuzione minima con MongoDB includerà in genere la seguente topologia:

• Un set di repliche MongoDB composto da un nodo primario, due nodi secondari con ciascuna delle istanze MongoDB in esecuzione in una zona di disponibilità con una latenza inferiore a 15 millisecondi in ciascun nodo;
• Un cluster di istanze di authoring con un nodo leader, un nodo non leader e entrambi attivi in ogni momento, con ciascuna delle istanze di authoring in esecuzione in ciascuno dei centri dati, dove le istanze principali e secondarie di MongoDB sono in esecuzione.

Inoltre, si consiglia vivamente di configurare l'archivio dati su un file system condiviso o Amazon S3, in modo che le risorse o i file binari non vengano memorizzati in MongoDB. Questo garantisce prestazioni ottimali nell’ambito dell’implementazione.

Uno dei vantaggi aggiuntivi dell'implementazione di un set di repliche MongoDB con un cluster di due o più istanze dell'autore consiste nell'avere uno scenario di ripristino automatico con tempi di inattività minimi in caso di istanze dell'autore, replica MongoDB o un errore completo del centro dati. Tuttavia, la scelta di MongoMK su TarMK non dovrebbe essere esclusivamente guidata dal requisito di ripristino, in quanto TarMK può anche fornire una soluzione di downtime minima con un meccanismo di failover controllato.

Se i criteri di cui sopra non devono essere soddisfatti durante i primi diciotto mesi di distribuzione, si consiglia di distribuire prima AEM utilizzando TarMK, quindi di rivalutare la configurazione in un secondo momento quando si applicano i criteri di cui sopra e infine di determinare se rimanere su TarMK o migrare a MongoMK.

Eccezioni per la scelta AEM MongoMK su TarMK su istanze di pubblicazione

Si sconsiglia di distribuire MongoMK per le istanze di pubblicazione. Il livello di pubblicazione della distribuzione viene quasi sempre distribuito come farm di istanze di pubblicazione completamente indipendenti che eseguono TarMK, che vengono mantenute in sincronia replicando il contenuto dalle istanze dell’autore. Questa architettura "shared nothing", propria delle istanze di pubblicazione, consente l'implementazione del livello di pubblicazione per scalare orizzontalmente in modo lineare. La topologia farm offre anche il vantaggio di applicare qualsiasi aggiornamento o aggiornamento per pubblicare le istanze su base continua, in modo che qualsiasi modifica al livello di pubblicazione non richieda tempi di inattività.

Questo non si applica ad AEM Communities che utilizza cluster MongoMK sul livello di pubblicazione ogni volta che vi sono più di un editore. Se scegli JSRP (vedi Archiviazione dei contenuti della community), allora un cluster MongoMK sarebbe appropriato, come qualsiasi cluster lato pubblicazione indipendentemente dal MK scelto, come MongoDB o RDB.

Prerequisiti e Recommendations durante la distribuzione di AEM con MongoMK

È disponibile un set di prerequisiti e consigli se stai prendendo in considerazione una distribuzione MongoMK per AEM:

Prerequisiti obbligatori per le distribuzioni MongoDB:

1. L'architettura e il dimensionamento dell'implementazione MongoDB devono far parte dell'implementazione del progetto con l'aiuto di architetti Adobe Consulting o MongoDB che hanno familiarità con AEM;
2. Le competenze MongoDB devono essere presenti all'interno del partner o del team di clienti per avere fiducia nell'essere in grado di sostenere e mantenere un ambiente MongoDB esistente o nuovo;
3. Puoi scegliere di distribuire la versione commerciale o open source di MongoDB (AEM supporta entrambi), ma devi acquistare un contratto di manutenzione e supporto MongoDB direttamente da MongoDB Inc;
4. Le architetture e le infrastrutture globali AEM e MongoDB dovrebbero essere ben definite e convalidate da un architetto AEM Adobe;
5. È necessario esaminare il modello di supporto per le distribuzioni AEM che includono MongoDB.

Raccomandazioni valide per le distribuzioni MongoDB:

• Consulta MongoDB per Adobe Experience Manager articolo;
• Esamina la produzione MongoDB elenco a discesa;
• Partecipa a una classe di certificazione su MongoDB disponibile online qui.

Considerazioni per AEM Communities

Per i siti che prevedono di distribuire AEM Communities, si consiglia di scegliere una distribuzione ottimizzato per la gestione di contenuti generati dagli utenti pubblicati da membri della community dall’ambiente di pubblicazione.

Utilizzando un negozio comune, non è necessario replicare UGC tra l’autore e altre istanze di pubblicazione per ottenere una visualizzazione coerente dell’UGC.

Di seguito è riportato un set di matrici decisionali che possono aiutarti a scegliere il tipo migliore di persistenza per la distribuzione:

Scelta del tipo di distribuzione per le istanze dell’autore

Scelta del tipo di distribuzione per le istanze di pubblicazione

Risorse Business.Adobe.com

Auto Text Summarization Embedded Charts Managed Cloud Dynamic Media Digital Asset Management Content Management System