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 sono intesi come un’indicazione degli usi raccomandati nelle configurazioni 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.
Questa è la distribuzione predefinita per le istanze di authoring.
I vantaggi:
- Semplice
- Manutenzione semplice
- Buone prestazioni
Gli svantaggi:
- Non scalabile oltre i limiti della capacità del server
- Nessuna capacità di failover
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:
- Semplicità
- Manutenzione
- Prestazioni
- Failover
Gli svantaggi:
- Non scalabile oltre i limiti della capacità del server
- Un server è inattivo la maggior parte delle volte
- Il failover non è automatico. Deve essere rilevato esternamente prima che il sistema di failover possa iniziare a gestire le richieste.
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, 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:
- Prestazioni
- Scalabilità per l'accesso in lettura
- Failover
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 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 errore hardware o di rete.
I vantaggi:
- Possibilità di scalabilità orizzontale con le nuove istanze di creazione AEM
- Elevata disponibilità, ridondanza e failover automatizzato del livello dati
Gli svantaggi:
- Le prestazioni possono essere inferiori rispetto a TarMK per alcuni scenari
Cluster Oak con failover MongoMK in più centri dati oak-cluster-with-mongomk-failover-across-multiple-datacenters
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:
- Possibilità di scalabilità orizzontale con le nuove istanze di creazione AEM
- Elevata disponibilità, ridondanza e failover automatizzato del livello dati (comprese le interruzioni del centro dati)
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.
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 di creazione AEM che per quelle di pubblicazione, ad eccezione dei 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:
- Numero di utenti con nome connessi in un giorno: in migliaia o più.
- Numero di utenti simultanei: in centinaia o più.
- Volume di acquisizioni di risorse al giorno: in centinaia di migliaia o più.
- Volume giornaliero di modifiche di pagina: in centinaia di migliaia o più (inclusi aggiornamenti automatizzati tramite Multi Site Manager o acquisizioni di feed di notizie, ad esempio).
- Volume di ricerche al giorno: in decine di migliaia o più.
Una distribuzione minima con MongoDB implica in genere la seguente topologia:
- Un set di repliche MongoDB costituito 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 authoring con un nodo principale, un nodo non principale ed entrambi attivi in qualsiasi momento, con ciascuna delle istanze di authoring in esecuzione in ciascun centro dati, dove sono in esecuzione le istanze primarie e secondarie di MongoDB.
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, per prima cosa si consiglia 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.
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à.
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.
Prerequisiti e Recommendations per l’implementazione di AEM con MongoMK prerequisites-and-recommendations-when-deploying-aem-with-mongomk
È disponibile una serie di prerequisiti e raccomandazioni se stai prendendo in considerazione una distribuzione MongoMK per AEM:
Prerequisiti obbligatori per le distribuzioni MongoDB:
- L'architettura di installazione e il dimensionamento di MongoDB devono far parte dell'implementazione del progetto con l'aiuto di Adobe Consulting o architetti di MongoDB che hanno familiarità con l'AEM;
- Le competenze di MongoDB devono essere presenti all'interno del partner o del team del cliente per poter mantenere e mantenere un ambiente MongoDB esistente o nuovo;
- Puoi scegliere di distribuire la versione commerciale o open source di MongoDB (AEM supporta entrambe le versioni), ma devi acquistare un contratto di manutenzione e supporto MongoDB direttamente da MongoDB Inc;
- Nel complesso le architetture e le infrastrutture AEM e MongoDB dovrebbero essere ben definite e convalidate da un architetto Adobe dell'AEM;
- Rivedi il modello di supporto per le implementazioni AEM che includono MongoDB.
Raccomandazioni valide per le implementazioni MongoDB:
- Consulta MongoDB per Adobe Experience Manager articolo;
- Rivedi la produzione MongoDB elenco di controllo;
- Partecipa a un corso di certificazione su MongoDB disponibile online qui.
Considerazioni per AEM Communities considerations-for-aem-communities
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:
Scelta del tipo di distribuzione per le istanze di authoring choosing-the-deployment-type-for-author-instances
Scelta del tipo di distribuzione per le istanze di pubblicazione choosing-the-deployment-type-for-publish-instances
