Déploiements recommandés

Les micronoyaux fonctionnent comme des gestionnaires de persistance dans AEM 6.4. Le choix d’un micronoyau adapté à vos besoins dépend de l’objectif de votre instance et du type de déploiement que vous envisagez.

Les exemples ci-dessous ont pour objectif de vous donner une indication des utilisations recommandées pour les configurations d’AEM les plus courantes.

Scénarios de déploiement

Instance TarMK unique

Dans ce cas, une instance TarMK unique s’exécute sur un serveur unique.

Il s’agit du déploiement par défaut des instances d’auteur.

Les avantages :

• Maintenance simple
• et facile
• Bonne performance

Les inconvénients :

• N’est pas adaptable au-delà des limites de la capacité du serveur
• Aucune capacité de basculement

TarMK Cold Standby

Une instance TarMK agit en tant qu’instance principale. Le référentiel du de l’instance principale est bien reproduit vers un système de basculement de secours.

Le mécanisme Cold Standby peut également être utilisé comme sauvegarde, car le référentiel complet est reproduit constamment vers le serveur de basculement. Le serveur de basculement s’exécute en mode Cold Standby, ce qui signifie que seul le récepteur HTTP de l’instance est en cours d’exécution.

Les avantages :

• Simplicité
• Maintenabilité
• Performance
• Basculement

Les inconvénients :

• Non adaptable au-delà des limites de la capacité du serveur
• Un serveur est inactif la plupart du temps
• Le basculement n’est pas automatique. Il doit être détecté en externe avant que le système de basculement puisse commencer à traiter les requêtes.

La ferme TarMK

Plusieurs instances Oak s’exécutent chacun avec une instance TarMK. Les référentiels TarMK sont indépendants et doivent être synchronisés.

En plus de la synchronisation des référentiels, le serveur de l’auteur publie le même contenu à chaque membre de la ferme. Pour plus d’informations, voir Réplication.

Pour AEM Communities, le contenu généré par l’utilisateur (CGU) n’est jamais été répliqué. Pour toutes questions concernant la prise en charge du contenu créé par l’utilisateur dans une ferme TarMK, reportez-vous à la section Remarques relatives à AEM Communities.

Il s’agit du déploiement par défaut pour les environnements de publication.

Les avantages :

• Performances
• Évolutivité pour l’accès en lecture
• Basculement

Le cluster Oak avec le basculement MongoMK pour un haut niveau de disponibilité dans un seul data center

Cette approche implique que plusieurs instances Oak accèdent à un ensemble de réplications MongoDB dans un data center, créant ainsi un cluster actif-actif pour l’environnement de création AEM. Les ensembles de réplications de MongoDB sont utilisés pour fournir un haut niveau de disponibilité et de redondance en cas de panne de matériel ou de réseau.

Les avantages :

• Possibilité de mise à l’échelle horizontale avec de nouvelles instances d’auteur AEM
• Haut niveau de disponibilité et de redondance, et basculement automatisé de la couche de données

Les inconvénients :

• Les performances risquent d’être réduites par rapport à TarMK dans certains scénarios

Le cluster Oak avec basculement MongoMK via plusieurs data centers

Cette approche implique que plusieurs instances Oak accèdent à un ensemble de réplications MongoDB défini sur plusieurs data centers, créant ainsi un cluster actif-actif pour l’environnement de création AEM. Avec plusieurs centres de données, la réplication MongoDB fournit le même niveau élevé de disponibilité et de redondance, mais inclut désormais la capacité de gérer une éventuelle panne de courant du centre de données.

Les avantages :

• Possibilité de mise à l’échelle horizontale avec de nouvelles instances d’auteur AEM
• Haut niveau de disponibilité et de redondance, et basculement automatisé de la couche de données (y compris les pannes de courant du data center)

Quel micronoyau utiliser ?

Le principe de base devant être pris en compte lorsque vous choisissez entre les deux micronoyaux disponibles est que TarMK est conçu pour la performance, alors que MongoMK est privilégié pour son évolutivité.

Vous pouvez utiliser ces matrices décisionnelles afin de déterminer le type de déploiement le plus adapté à vos besoins.

Adobe recommande vivement d’utiliser TarMK en tant que technologie de persistance par défaut dans tous les scénarios de déploiement, aussi bien pour l’auteur que pour les instances de publication AEM, sauf dans les cas d’utilisation décrits ci-dessous.

Cas d’exceptions pour le choix d’AEM MongoMK plutôt que TarMK sur les instances d’auteur

La raison principale pour choisir la persistance MongoMK plutôt que TarMK est sa capacité à faire évoluer les instances horizontalement. Cela permet d’avoir au moins deux instances d’auteur actives s’exécutant à tout moment et d’utiliser MongoDB en tant que système de stockage de persistance. La nécessité d’exécuter plus d’une instance d’auteur découle en général du fait que la capacité du processeur et de la mémoire d’un serveur unique, prenant en charge toutes les activités de création simultanées, n’est plus suffisante.

Il est pratiquement impossible de prévoir quel sera le modèle exact de concurrence après le lancement du nouveau site. Par conséquent, Adobe vous recommande de tenir compte des critères suivants lorsque vous considérez d’utiliser MongoMK et au moins deux nœuds actifs d’auteur :

1. Nombre d’utilisateurs nommés connectés au cours de la journée : des milliers ou plus.
2. Nombre d’utilisateurs simultanés : des centaines ou plus.
3. Volume d’assimilation de ressources par jour : des centaines de milliers, voire plus.
4. Volume de modifications de pages par jour : des centaines de milliers (y compris les mises à jour automatisées via le Multi-site Manager ou des assimilations de flux d’actualité, par exemple).
5. Volume de recherches par jour : des dizaines de milliers, voire plus.

Un déploiement minimal avec MongoDB implique en général la topologie suivante :

• Un ensemble de réplications MongoDB composé d’un nœud principal, de deux nœuds secondaires avec chacune des instances MongoDB s’exécutant dans une zone de disponibilité avec une latence de moins de 15 millisecondes entre chaque nœud ;
• Un cluster d’instances d’auteur avec un nœud principal, un nœud secondaire, tous les deux actifs à tout moment, chaque instances d’auteur s’exécutant dans chacun des data centers, les instances MongoDB primaires et secondaires étant exécutées.

En outre, il est fortement recommandé de configurer la banque de données sur un système de fichier partagé ou Amazon S3, de sorte que les ressources ou les fichiers binaires ne soient pas stockés dans MongoDB. Cela garantit des performances optimales pendant le déploiement.

Un des autres avantages du déploiement d’un ensemble de réplications MongoDB avec un cluster de deux instances d’auteur ou plus est d’avoir un scénario de restauration automatisé avec un temps d’interruption minimal en cas de panne des instances d’auteur, de la réplication de MongoDB ou du data center. Toutefois, le choix de MongoMK plutôt que de TarMK ne doit pas être uniquement motivé par les conditions de restauration, car TarMK peut également fournir une solution de temps d’interruption minimal avec un mécanisme de basculement contrôlé.

Si vous ne pensez pas rencontrer les conditions ci-dessus lors des dix-huit premiers mois du déploiement, il est recommandé de d’abord déployer AEM à l’aide de TarMK, puis de réévaluer votre configuration ultérieurement lorsque les conditions ci-dessus s’appliquent, pour finalement déterminer si vous devez continuer d’utiliser TarMK ou passer à MongoMK.

Cas d’exceptions pour le choix d’AEM MongoMK plutôt que TarMK sur les instances de publication

Il n’est pas recommandé de déployer MongoMK pour les instances de publication. Le niveau de publication du déploiement est presque toujours déployé en tant que ferme ou instances de plublication exécutant TarMK, synchronisées en répliquant le contenu des instances d’auteur. Cette architecture de « non partage », adaptée aux instances de publication, permet au déploiement du niveau de publication d’évoluer horizontalement d’une manière linéaire. La topologie de ferme permet également d’appliquer toute mise à jour ou mise à niveau vers des instances de publication au fur et à mesure, de sorte que les modifications au niveau de la publication ne nécessitent pas de temps d’interruption.

Ceci ne s’applique pas à AEM Communities, qui utilise les clusters MongoMK sur le niveau de publication lorsqu’il y a plus d’un éditeur. Si vous choisissez JSRP (consultez la section Stockage du de contenu de la communauté), un cluster MongoMK est approprié, comme le serait tout cluster côté publication, quel que soit le MK sélectionné, comme MongoDB ou RDB.

Conditions préalables et recommandations de déploiement d’AEM avec MongoMK

Certaines conditions préalables et des recommandations sont disponibles si vous envisagez un déploiement MongoMK pour AEM :

Conditions préalables obligatoires pour les déploiements de MongoDB :

1. L’architecture et le dimensionnement du déploiement de MongoDB doivent faire partie de l’exécution du projet avec l’aide des architectes d’Adobe Consulting ou de MongoDB, familiarisés avec AEM ;
2. L’expertise de MongoDB doit être représenté au sein de l’équipe partenaire ou du service client en vue d’assurer le maintien d’un environnement MongoDB nouveau ou existant ;
3. Vous pouvez choisir de déployer la version commerciale ou Open Source de MongoDB (AEM prend en charge les deux), mais vous devez souscrire au contrat de maintenance et d’assistance directement auprès de MongoDB Inc ;
4. Les architectures et infrastructures d’ensemble d’AEM et de MongoDB doivent être correctement configurées et validées par un architecte Adobe AEM ;
5. Vous devez passer en revue le modèle de prise en charge des déploiements AEM qui incluent MongoDB.

Recommandations essentielles pour les déploiements de MongoDB :

• Consultez l’article sur MongoDB pour Adobe Experience Manager ;
• Passez en revue la liste de contrôle d’exploitation MongoDB ;
• Participez à une formation en ligne sur MongoDB ici.

Remarques pour AEM Communities

Pour les sites qui prévoient de déployer AEM Communities, il est recommandé de choisir un déploiement optimisé pour gérer le contenu publié par des membres de la communauté de l’environnement de publication.

En utilisant un entrepôt commun, le contenu généré par l’utilisateur n’a plus besoin d’être répliqué entre les instances d’auteur et de publication pour obtenir une vue cohérente d’ensemble.

Vous trouverez ci-dessous un ensemble de matrices décisionnelles pour vous aider à choisir le meilleur type de persistance pour votre déploiement :

Choix du type de déploiement pour les instances d’auteur

Choix du type de déploiement pour les instances de publication

Ressources Business.Adobe.com

Ecommerce Integrations Automated Onboarding Style System Cms Cloud Customer Communications Asset Collections