Implementazioni consigliate

Nota

Questa pagina fa riferimento alle topologie consigliate per AEM. Per ulteriori informazioni sulle funzionalità di clustering e su come configurarle, consulta la documentazione diApache Sling Discovery API.

I microkernel agiscono come persistence manager nella AEM 6.4. La scelta di uno per soddisfare le esigenze dipende dallo scopo dell'istanza e dal tipo di distribuzione che si sta considerando.

Gli esempi riportati di seguito indicano gli usi consigliati nelle impostazioni di AEM più comuni.

Scenari di distribuzione

Istanza TarMK singola

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

Si tratta della distribuzione predefinita per le istanze di creazione.

chlimage_1-15

I vantaggi:

  • Semplici
  • Manutenzione semplice
  • Buona prestazione

Gli svantaggi:

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

TarMK Cold Standby

Un'istanza TarMK agisce come istanza principale. 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é il repository 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.

chlimage_1-16

I vantaggi:

  • Semplicità
  • Manutenzione
  • Spettacolo
  • Failover

Gli svantaggi:

  • Non scalabile oltre i limiti della capacità del server
  • Un server è inattivo nella maggior parte dei casi
  • Il failover non è automatico. Deve essere rilevato esternamente prima che il sistema di failover possa avviare la trasmissione delle richieste.
Nota

Per ulteriori informazioni su come configurare AEM con TarMK Cold Standby, consultate questo articolo.

Nota

La distribuzione di Cold Standby in questo esempio TarMK richiede che sia le istanze primarie che quelle in standby siano autorizzate separatamente, in quanto è presente una replica costante del server di failover. Per ulteriori informazioni sulle licenze, consultare i Termini generali di licenza delAdobe.

Agriturismo TarMK

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

La sincronizzazione dei repository viene fornita con il fatto che il server di creazione pubblica lo stesso contenuto per ogni membro della farm. For more information, see Replication.

Per AEM Communities, il contenuto generato dall'utente (UGC) non viene mai replicato. Per supportare UGC su una farm TarMK, consulta considerazioni per AEM Communities.

Questa è la distribuzione predefinita per gli ambienti di pubblicazione.

chlimage_1-17

I vantaggi:

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

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

Questo approccio implica l'accesso di più istanze Oak a un set di repliche MongoDB all'interno di un singolo centro dati, in effetti la creazione di un cluster 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.

chlimage_1-18

I vantaggi:

  • Possibilità di ridimensionare in orizzontale con nuove istanze di autori AEM
  • Elevata disponibilità, ridondanza e failover automatizzato del livello dati

Gli svantaggi:

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

Cluster Oak con failover MongoMK tra più datacenter

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

oakclustermongofailover2datacenters

I vantaggi:

  • Possibilità di ridimensionare in orizzontale con nuove istanze di autori AEM
  • Elevata disponibilità, ridondanza e failover automatizzato del livello dati (incluse le interruzioni del data center)
Nota

Nel diagramma precedente, AEM Server 3 e AEM Server 4 sono presentati con uno stato inattivo che assume una latenza di rete tra i server AEM in Data Center 2 e il nodo principale MongoDB in Data Center 1 che è superiore ai requisiti documentati qui. Se la latenza massima è compatibile con i requisiti, ad esempio mediante l'uso di aree di disponibilità, i server AEM in Data Center 2 possono essere attivi anche, creando un cluster AEM attivo tra più datacenter.

Nota

Per ulteriori informazioni sui concetti architettonici MongoDB descritti in questa sezione, vedere Replica MongoDB.

Microkernel: quale utilizzare

La regola di base che deve essere presa in considerazione nella scelta tra i due micro kernel disponibili è che TarMK è progettato per le prestazioni, mentre MongoMK è utilizzato per la scalabilità.

Potete utilizzare queste matrici decisionali per stabilire quale sia il tipo di distribuzione migliore adatto ai vostri requisiti.

Adobe consiglia vivamente a TarMK di essere la tecnologia di persistenza predefinita utilizzata dai clienti in tutti gli scenari di distribuzione, sia per le istanze AEM Author che Publish, fatta eccezione per i casi d’uso indicati di seguito.

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

Il motivo principale per scegliere la persistenza MongoMK al di sopra di TarMK è quello di ridimensionare le istanze orizzontalmente. Ciò significa che due o più istanze di autori attive sono sempre in esecuzione e che utilizzano MongoDB come sistema di storage persistente. La necessità di eseguire più di un'istanza di 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à il modello di concorrenza esatto dopo che un nuovo sito sarà attivo. Pertanto, 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 invii 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ù.
Nota

Il giorno duro può essere utilizzato per valutare le prestazioni dell'applicazione del cliente nel contesto della configurazione hardware implementata. Ulteriori informazioni su questo strumento sono disponibili qui.

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 su ciascun nodo;
  • Un cluster di istanze di autori con un nodo leader, un nodo non leader e entrambi attivi in ogni momento, con ciascuna istanza di autore in esecuzione in ciascuno dei centri dati, in cui sono in esecuzione le istanze principali e secondarie di MongoDB.

Inoltre, si consiglia vivamente di configurare il datastore su un file system condiviso o Amazon S3, in modo che le risorse o i file binari non vengano memorizzati in MongoDB. Ciò garantirà prestazioni ottimali all'interno della distribuzione.

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

Se i criteri di cui sopra non sono previsti durante i primi diciotto mesi di implementazione, si consiglia di distribuire AEM utilizzando TarMK, quindi rivalutare la configurazione in una data successiva quando si applicano i criteri di cui sopra, e infine determinare se rimanere su TarMK o migrare a MongoMK.

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

Non è consigliabile distribuire le istanze MongoMK per la pubblicazione. Il livello di pubblicazione della distribuzione viene quasi sempre distribuito come farm di istanze di pubblicazione completamente indipendenti con TarMK, che vengono mantenute sincronizzate replicando il contenuto dalle istanze dell’autore. Questa architettura "shared no" (nulla condiviso), propria delle istanze di pubblicazione, consente la distribuzione del livello di pubblicazione in scala orizzontale in modo lineare. La topologia della farm offre inoltre il vantaggio di applicare qualsiasi aggiornamento o aggiornamento alle istanze pubblicate su base continuativa, in modo che qualsiasi modifica al livello di pubblicazione non richieda tempi di inattività.

Ciò non si applica a AEM Communities che utilizza cluster MongoMK sul livello di pubblicazione ogni volta che vi sono più di un editore. Se si sceglie JSRP (vedere Archiviazione dei contenuticommunity), sarà appropriato un cluster MongoMK, come qualsiasi altro cluster lato pubblicazione a prescindere dalla MK scelta, ad esempio MongoDB o RDB.

Prerequisiti e Recommendations per la distribuzione di AEM con MongoMK

Se state valutando una distribuzione MongoMK per AEM, è disponibile un set di prerequisiti e raccomandazioni:

Prerequisiti obbligatori per le distribuzioni MongoDB:

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

Consigli forti per le distribuzioni MongoDB:

  • Consulta l' articoloMongoDB per Adobe Experience Manager;
  • Esaminare la checklistdi produzione MongoDB;
  • Partecipa a un corso di certificazione su MongoDB disponibile qui.
Nota

Per tutte le domande aggiuntive su queste linee guida, prerequisiti e raccomandazioni, contatta Assistenzaclienti di Adobe.

Considerazioni per AEM Communities

Per i siti che prevedono di distribuire AEM Communities, si consiglia di scegliere una distribuzione ottimizzata per la gestione di UGC pubblicati dai membri della community dall'ambiente di pubblicazione.

Utilizzando uno store 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 di persistenza migliore per la distribuzione:

Scelta del tipo di distribuzione per le istanze di creazione

chlimage_1-19

Scelta del tipo di distribuzione per le istanze di pubblicazione

chlimage_1-20

Nota

MongoDB è un software di terze parti e non è incluso nel pacchetto di licenze AEM. Per ulteriori informazioni, vedere la pagina relativa ai criteri di licenza MongoDB.

Per ottenere il massimo dalla distribuzione AEM, Adobe consiglia di concedere in licenza la versione Enterprise di MongoDB per poter beneficiare del supporto professionale.

La licenza include un set di repliche standard, composto da una delle istanze primarie e due secondarie che possono essere utilizzate per l'autore o per le distribuzioni di pubblicazione.

Se si desidera eseguire sia l'autore che la pubblicazione su MongoDB, è necessario acquistare due licenze separate.

Per ulteriori informazioni, vedere la pagina MongoDB per Adobe Experience Manager.

In questa pagina