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 sezione Documentazione API per l'individuazione di Apache Sling.

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.

chlimage_1-15

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.

chlimage_1-16

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.
NOTA

Per ulteriori informazioni su come configurare AEM con lo standby a freddo TarMK, vedi questo articolo.

NOTA

La distribuzione in standby a freddo in questo esempio TarMK richiede che sia le istanze primarie che quelle in standby siano concesse in licenza separatamente, in quanto vi è una replica costante per il server di failover. Per ulteriori informazioni sulle licenze, consulta la Adobe Condizioni generali di licenza.

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.

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 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.

chlimage_1-18

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.

oakclustermongofailover2datacenter

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)
NOTA

Nel diagramma precedente, AEM Server 3 e AEM Server 4 vengono 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 tramite l'uso di aree di disponibilità, è possibile attivare anche i server AEM in Data Center 2, creando un cluster di AEM attivo-attivo su più datacenter.

NOTA

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

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ù.
NOTA

È possibile utilizzare un giorno difficile per valutare le prestazioni dell’applicazione del cliente nel contesto della configurazione hardware implementata. Sono disponibili ulteriori informazioni su questo strumento 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 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.
NOTA

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

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

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, consulta la sezione Criteri di licenza MongoDB pagina.

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

La licenza include un set di repliche standard, composto da una istanza primaria e due istanze secondarie che possono essere utilizzate per le distribuzioni di authoring o pubblicazione.

Se desideri eseguire sia l’autore che la pubblicazione su MongoDB, devono essere acquistate due licenze separate.

Per ulteriori informazioni, consulta la sezione Pagina MongoDB per Adobe Experience Manager.

In questa pagina