Questa pagina fa riferimento alle topologie consigliate per l’AEM. Per ulteriori informazioni sulle funzionalità di clustering e su come configurarle, vedere Documentazione API di individuazione Apache Sling.
I microKernel fungono da gestori di persistenza a partire da AEM 6.2. La scelta di un tipo di implementazione adatto alle tue esigenze dipende dallo scopo dell’istanza e dal tipo di implementazione che stai prendendo in considerazione.
Gli esempi seguenti sono intesi come un’indicazione degli usi raccomandati nelle configurazioni 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 funge da istanza primaria. L'archivio dal sistema primario viene replicato in un sistema di failover in standby.
Il meccanismo di standby a freddo può essere utilizzato anche come backup perché l'intero repository viene costantemente replicato sul server di failover. Il server di failover è in esecuzione in modalità standby a freddo, il che significa che solo HttpReceiver dell'istanza è in esecuzione.
I vantaggi:
Gli svantaggi:
Per ulteriori informazioni su come configurare l’AEM con TarMK Cold Standby, consulta questo articolo.
La distribuzione in standby a freddo in questo esempio di TarMK richiede che le istanze principale e in standby siano concesse in licenza separatamente, in quanto esiste una replica costante sul server di failover. Per ulteriori informazioni sulle licenze, consultare Adobe Condizioni generali di licenza.
Più istanze Oak vengono eseguite ciascuna con un’istanza TarMK. Gli archivi TarMK sono indipendenti e devono essere sincronizzati.
Mantenendo sincronizzati gli archivi, il server di authoring pubblica lo stesso contenuto per ogni membro della farm. Per ulteriori informazioni, consulta Replica.
Per AEM Communities, i contenuti generati dagli utenti (UGC, User Generated Content) non vengono mai replicati. Per il supporto del linguaggio UGC in una farm TarMK, consulta considerazioni per AEM Communities.
Questa è la distribuzione predefinita per gli ambienti di pubblicazione.
I vantaggi:
Questo approccio implica che più istanze Oak accedano a un set di repliche MongoDB all’interno di un singolo data center, creando in effetti un cluster attivo-attivo per l’ambiente di authoring dell’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 che più istanze Oak accedano a un set di repliche MongoDB in più data center, creando in effetti un cluster attivo-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 possibilità di gestire un'interruzione del data center.
I vantaggi:
Nel diagramma precedente, il server AEM 3 e il server AEM 4 sono presentati con uno stato inattivo presupponendo una latenza di rete tra i server AEM nel centro dati 2 e il nodo primario MongoDB nel centro dati 1 superiore ai requisiti documentati qui. Se la latenza massima è compatibile con i requisiti, ad esempio mediante l'uso di zone di disponibilità, anche i server AEM nel centro dati 2 possono essere attivi, creando un cluster AEM attivo-attivo in più centri dati.
Per ulteriori informazioni sui concetti architetturali di MongoDB descritti in questa sezione, vedi Replica MongoDB.
La regola di base che deve essere presa in considerazione quando si sceglie tra i due micro kernel disponibili è che TarMK è progettato per le prestazioni, mentre MongoMK è utilizzato per la scalabilità.
Puoi utilizzare queste matrici di decisione per stabilire quale sia il tipo di distribuzione più adatto alle tue esigenze.
L’Adobe consiglia vivamente di utilizzare TarMK come tecnologia di persistenza predefinita, utilizzata dai clienti in tutti gli scenari di implementazione, sia per le istanze AEM Author che per quelle Publish, ad eccezione dei casi di utilizzo descritti di seguito.
Il motivo principale per scegliere il back-end di persistenza MongoMK su TarMK è quello di scalare le istanze orizzontalmente. Ciò significa avere due o più istanze di authoring attive in esecuzione in qualsiasi momento e utilizzare MongoDB come sistema di storage di persistenza. La necessità di eseguire più di un’istanza di authoring deriva in genere dal fatto che la capacità di CPU e di memoria di un singolo server, che supporta tutte le attività di authoring simultanee, non è più sostenibile.
È quasi impossibile prevedere quale sarà il modello di concorrenza esatto dopo la pubblicazione di un nuovo sito. Pertanto, Adobe consiglia di considerare i seguenti criteri quando si valuta se utilizzare MongoMK e due o più nodi attivi dell’istanza di authoring:
È possibile utilizzare Dough Day 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 implica in genere la seguente topologia:
Inoltre, si consiglia vivamente di configurare l’archivio dati su un file system condiviso o su Amazon S3, in modo che le risorse o i dati binari non vengano memorizzati in MongoDB. In questo modo verranno garantite prestazioni ottimali all'interno dell'implementazione.
Uno dei vantaggi aggiuntivi della distribuzione di un set di repliche MongoDB con un cluster di due o più istanze di authoring è uno scenario di ripristino automatizzato con tempi di inattività minimi in caso di istanze di authoring, replica MongoDB o errore completo del centro dati. Tuttavia, la scelta di MongoMK rispetto a TarMK non dovrebbe essere esclusivamente guidata dai requisiti di ripristino, in quanto TarMK può anche fornire una soluzione di downtime minima con un meccanismo di failover controllato.
Se non si prevede che i criteri di cui sopra siano soddisfatti durante i primi diciotto mesi di implementazione, si consiglia prima di implementare l’AEM utilizzando TarMK, quindi di rivalutare la configurazione in un secondo momento, quando i criteri di cui sopra saranno applicabili, 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 in cui viene eseguito TarMK, che vengono mantenute sincronizzate replicando il contenuto dalle istanze di authoring. Questa architettura "senza elementi condivisi", propria delle istanze di pubblicazione, consente la distribuzione del livello di pubblicazione in scala orizzontale in modo lineare. La topologia farm offre inoltre il vantaggio di applicare qualsiasi aggiornamento o aggiornamento alle istanze di pubblicazione su base continua, in modo tale che eventuali modifiche al livello di pubblicazione non richiedano tempi di inattività.
Questo non si applica ad AEM Communities che utilizza cluster MongoMK sul livello di pubblicazione ogni volta che è presente più di un editore. Se si sceglie JSRP (vedere Archiviazione contenuti community), sarebbe appropriato un cluster MongoMK, come qualsiasi cluster lato pubblicazione indipendentemente dalla MK scelta, ad esempio MongoDB o RDB.
È disponibile una serie di prerequisiti e raccomandazioni se stai prendendo in considerazione una distribuzione MongoMK per AEM:
Prerequisiti obbligatori per le distribuzioni MongoDB:
Raccomandazioni valide per le implementazioni MongoDB:
Per ulteriori domande su queste linee guida, prerequisiti e raccomandazioni, contatta Assistenza clienti Adobe.
Per i siti che prevedono di distribuire AEM Communities, si consiglia di scegli una distribuzione ottimizzato per la gestione di contenuti generati dagli utenti appartenenti alla community e pubblicati nell’ambiente di pubblicazione.
Utilizzando un archivio comune, non è necessario replicare UGC tra l’istanza di authoring e altre istanze di pubblicazione per ottenere una visualizzazione coerente di 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 Criteri di licenza MongoDB pagina.
Per ottenere il massimo dalla distribuzione AEM, l’Adobe consiglia di concedere in licenza la versione Enterprise di MongoDB per beneficiare di un supporto professionale.
La licenza include un set di repliche standard, composto da una istanza principale e due istanze secondarie che possono essere utilizzate per le distribuzioni di authoring o pubblicazione.
Se desideri eseguire sia l’authoring che la pubblicazione su MongoDB, è necessario acquistare due licenze separate.
Per ulteriori informazioni, vedere Pagina MongoDB per Adobe Experience Manager.