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.
In questo scenario, una singola istanza TarMK viene eseguita su un singolo server.
Questa è la distribuzione predefinita per le istanze di authoring.
I vantaggi:
Gli svantaggi:
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:
Gli svantaggi:
Per ulteriori informazioni su come configurare AEM con lo standby a freddo TarMK, vedi questo articolo.
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.
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:
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:
Gli svantaggi:
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:
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.
Per ulteriori informazioni sui concetti architettonici MongoDB descritti in questa sezione, vedi Replica MongoDB.
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.
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:
È 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:
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.
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.
È disponibile un set di prerequisiti e consigli se stai prendendo in considerazione una distribuzione MongoMK per AEM:
Prerequisiti obbligatori per le distribuzioni MongoDB:
Raccomandazioni valide per le distribuzioni MongoDB:
Per tutte le domande aggiuntive su queste linee guida, prerequisiti e raccomandazioni, contatta Adobe Customer Care.
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:
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.