Déploiements recommandés recommended-deployments
Les micronoyaux fonctionnent comme des gestionnaires de persistance dans AEM 6.2. 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 visent à indiquer les utilisations recommandées dans les configurations d’AEM les plus courantes.
Scénarios de déploiement deployment-scenarios
Instance TarMK unique single-tarmk-instance
Dans ce scénario, une seule instance TarMK s’exécute sur un seul serveur.
Il s’agit du déploiement par défaut pour les environnements de création.
Les avantages :
- Simple
- Maintenance aisée
- Bonne performance
Les inconvénients :
- Non évolutif au-delà des limites de la capacité du serveur
- Aucune capacité de basculement
TarMK Cold Standby tarmk-cold-standby
Une instance TarMK agit comme l’instance principale. Le référentiel de l’instance principale est répliqué 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 constamment répliqué sur le serveur de basculement. Le serveur de basculement s’exécute en mode Cold Standby, ce qui signifie que seul le récepteur HttpReceiver de l’instance est en cours d’exécution.
Les avantages :
- Simplicité
- Maintenabilité
- Performance
- Basculement
Les inconvénients :
- Non évolutif au-delà des limites de la capacité du serveur
- La plupart du temps, un serveur est inactif.
- 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.
Batterie TarMK tarmk-farm
Plusieurs instances Oak s’exécutent chacune avec une instance TarMK. Les référentiels TarMK sont indépendants et doivent être synchronisés.
Le fait que le serveur de création publie le même contenu à chaque personne membre de la batterie assure la synchronisation des référentiels. Pour plus d’informations, voir Réplication.
Pour AEM Communities, le contenu créé par l’utilisateur ou l’utilisatrice (UGC) n’est jamais 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 :
- Performance
- Évolutivité pour l’accès en lecture
- Basculement
Cluster Oak avec basculement MongoMK pour une haute disponibilité dans un seul centre de données oak-cluster-with-mongomk-failover-for-high-availability-in-a-single-datacenter
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 jeux de Secondaires de MongoDB sont utilisés pour fournir une haute disponibilité et une redondance en cas de panne matérielle ou réseau.
Les avantages :
- Possibilité d’effectuer une mise à l’échelle horizontale avec de nouvelles instances de création AEM
- Haute disponibilité, redondance et basculement automatisé de la couche de données
Les inconvénients :
- Les performances peuvent être inférieures à celles de TarMK pour certains scénarios.
Cluster Oak avec basculement MongoMK sur plusieurs centres de données oak-cluster-with-mongomk-failover-across-multiple-datacenters
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é d’effectuer une mise à l’échelle horizontale avec de nouvelles instances de création AEM
- Haute disponibilité, redondance et basculement automatisé de la couche de données (y compris les pannes de centre de données)
Microkernels : lequel utiliser microkernels-which-one-to-use
Le principe de base à ne pas oublier lorsque vous choisissez entre les deux microkernels disponibles est que TarMK est conçu pour les performances, tandis que MongoMK est utilisé pour son évolutivité.
Vous pouvez utiliser ces tableaux de décision pour déterminer le type de déploiement le plus adapté à vos besoins.
Adobe recommande vivement aux clientes et clients d’utiliser TarMK comme technologie de persistance par défaut dans tous les scénarios de déploiement, pour les instances de création et de publication AEM, sauf dans les cas d’utilisation précisés ci-dessous.
Exceptions au choix d’AEM MongoMK plutôt que de TarMK sur les instances de création exceptions-for-choosing-aem-mongomk-over-tarmk-on-author-instances
La principale raison pour laquelle choisir le serveur principal de persistance MongoMK plutôt que TarMK est de mettre les instances à l’échelle horizontale. Cela implique de disposer d’au moins deux instances de création actives s’exécutant en permanence et d’utiliser MongoDB comme système de stockage de persistance. La nécessité d’exécuter plusieurs instances de création est due au fait que la capacité du processeur et de la mémoire d’un seul serveur, prenant en charge toutes les activités de création simultanées, n’est plus suffisante.
Il est presque impossible de prédire quel sera le modèle exact de simultanéité une fois qu’un nouveau site sera mis en ligne. Par conséquent, Adobe recommande de tenir compte des critères suivants au moment d’évaluer s’il faut utiliser MongoMK et deux nœuds actifs de création ou plus :
- Nombre d’utilisateurs nommés connectés au cours de la journée : des milliers ou plus.
- Nombre d’utilisateurs simultanés : des centaines ou plus.
- Volume d’assimilation de ressources par jour : des centaines de milliers, voire plus.
- 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).
- Volume de recherches par jour : des dizaines de milliers, voire plus.
Un déploiement minimal avec MongoDB implique généralement 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 de création avec un nœud leader et un nœud non-leader, les deux étant actifs à tout moment, chacune des instances de création étant exécutée dans chacun des centres de données, où les instances principales et secondaires de MongoDB s’exécutent.
En outre, il est vivement recommandé de configurer le magasin de données sur un système de fichiers 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 dans le cadre du déploiement.
L’un des avantages supplémentaires du déploiement d’un ensemble de réplications MongoDB avec un cluster d’au moins deux instances de création est de disposer d’un scénario de récupération automatisée avec un temps d’arrêt minimal en cas d’échec des instances de création, de la réplication MongoDB ou d’un centre de données complet. Néanmoins, le choix de MongoMK plutôt que de TarMK ne doit pas être uniquement motivé par les exigences de récupération, car TarMK peut également fournir une solution de temps d’arrêt minimal avec un mécanisme de basculement contrôlé.
Si les critères ci-dessus ne doivent pas être satisfaits au cours des 18 premiers mois du déploiement, nous vous recommandons de commencer par déployer AEM à l’aide de TarMK, puis de réévaluer votre configuration à une date ultérieure lorsque les critères ci-dessus s’appliquent, et enfin de déterminer s’il faut rester sur TarMK ou migrer vers MongoMK.
Exceptions au choix d’AEM MongoMK par rapport à TarMK sur les instances de publication exceptions-for-choosing-aem-mongomk-over-tarmk-on-publish-instances
Il n’est pas recommandé de déployer MongoMK pour les instances de publication. Le niveau publication du déploiement est presque toujours déployé en tant que batterie d’instances de publication entièrement indépendantes exécutant TarMK, qui sont synchronisées en répliquant le contenu des instances de création. Cette architecture « shared nothing » (sans partage), propre aux instances de publication, permet au déploiement du niveau publication de se dimensionner horizontalement de manière linéaire. La topologie de batterie offre également l’avantage d’appliquer une mise à jour ou une mise à niveau aux instances de publication de manière progressive, de sorte que toute modification au niveau publication ne nécessite aucun temps d’arrêt.
Cela ne s’applique pas à AEM Communities qui utilise des clusters MongoMK sur le niveau publication lorsqu’il y a plusieurs éditeurs ou éditrices. 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 prerequisites-and-recommendations-when-deploying-aem-with-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 :
- L’architecture et le dimensionnement du déploiement MongoDB doivent faire partie de la mise en œuvre du projet avec l’aide des architectes MongoDB ou des services de conseil Adobe qui connaissent bien AEM ;
- L’équipe partenaire ou celle du client ou de la cliente doit disposer de l’expertise MongoDB nécessaire pour être en mesure de maintenir et de gérer un environnement MongoDB existant ou nouveau ;
- Vous pouvez choisir de déployer la version commerciale ou open source de MongoDB (AEM prend en charge les deux), mais vous devez souscrire un contrat de maintenance et de support MongoDB directement auprès de MongoDB Inc ;
- Les architectures et infrastructures globales d'AEM et de MongoDB doivent être bien définies et validées par un ou une architecte d'AEM Adobe ;
- Examinez le modèle de prise en charge des déploiements d’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.
Considérations relatives à AEM Communities considerations-for-aem-communities
Pour les sites qui prévoient de déployer AEM Communities, il est recommandé de choisir un déploiement optimisé pour la gestion du contenu créé par l’utilisatreur ou l’utilisatrice (UGC) publié par les membres de la communauté de l’environnement de publication.
En utilisant un magasin commun, le contenu généré par l’utilisateur ou l’utilisatrice n’a pas besoin d’être répliqué entre l’instance de création et les autres instances de publication pour obtenir une vue cohérente de celui-ci.
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 choosing-the-deployment-type-for-author-instances
Choix du type de déploiement pour les instances de publication choosing-the-deployment-type-for-publish-instances
