Distribuzioni consigliate recommended-deployments

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 indicano gli usi consigliati nelle configurazioni di AEM più comuni.

Scenari di distribuzione deployment-scenarios

Singola istanza TarMK single-tarmk-instance

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

Distribuzione predefinita per le istanze di authoring.

I vantaggi:

Gli svantaggi:

Standby a freddo TarMK tarmk-cold-standby

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:

Farm TarMK tarmk-farm

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, vedere Replica.

Distribuzione predefinita per gli ambienti di pubblicazione.

I vantaggi:

Cluster Oak con failover MongoMK per un'elevata disponibilità in un singolo centro dati oak-cluster-with-mongomk-failover-for-high-availability-in-a-single-datacenter

Questo approccio implica che più istanze Oak accedono 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 AEM. I set di replica in MongoDB vengono utilizzati per fornire elevata disponibilità e ridondanza in caso di errore hardware o di rete.

I vantaggi:

Gli svantaggi:

Cluster Oak con failover MongoMK in più centri dati oak-cluster-with-mongomk-failover-across-multiple-datacenters

Questo approccio implica che più istanze di Oak accedono 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:

Microkernel: quale usare microkernels-which-one-to-use

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.

Adobe consiglia vivamente di utilizzare TarMK come tecnologia di persistenza predefinita utilizzata dai clienti in tutti gli scenari di implementazione, sia per le istanze Author che Publish di AEM, tranne nei casi di utilizzo descritti di seguito.

Eccezioni per la scelta di AEM MongoMK rispetto a TarMK nelle istanze di authoring exceptions-for-choosing-aem-mongomk-over-tarmk-on-author-instances

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:

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 presenza 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 18 mesi di implementazione, si consiglia prima di implementare 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.

Eccezioni per la scelta di AEM MongoMK rispetto a TarMK nelle istanze di pubblicazione exceptions-for-choosing-aem-mongomk-over-tarmk-on-publish-instances

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

Prerequisiti e raccomandazioni per l’implementazione di AEM con MongoMK prerequisites-and-recommendations-when-deploying-aem-with-mongomk

È disponibile una serie di prerequisiti e raccomandazioni se stai valutando una distribuzione MongoMK per AEM:

Prerequisiti obbligatori per le distribuzioni MongoDB:

Consigli efficaci per le distribuzioni MongoDB: