Adobe Experience Manager avec MongoDB
Cet article vise à améliorer les connaissances sur les tâches et les considérations nécessaires pour déployer AEM (Adobe Experience Manager) avec MongoDB.
Pour plus d’informations sur le déploiement, consultez la section Déploiement et maintenance de la documentation.
Quand utiliser MongoDB avec AEM
MongoDB est généralement utilisé pour la prise en charge des déploiements d’instances de création d’AEM lorsque l’un des critères suivants est satisfait :
- plus de 1 000 utilisateurs et utilisatrices uniques par jour ;
- plus de 100 utilisateurs et utilisatrices simultanés ;
- nombre élevé de modifications de page ;
- activations ou déploiements volumineux.
Les critères ci-dessus sont réservés aux instances de création et non aux instances de publication, qui doivent toutes être basées sur TarMK. Le nombre d’utilisateurs et utilisatrices fait référence aux personnes authentifiées, puisque les instances de création n’autorisent pas d’accès non authentifié.
Si les critères ne sont pas remplis, un déploiement TarMK actif/de secours est recommandé pour répondre à la disponibilité. En règle générale, MongoDB doit être pris en compte dans les situations où les exigences de mise à l’échelle sont supérieures à ce qui peut être réalisé avec un seul élément matériel.
REMARQUEDéploiement minimal de MongoDB pour AEM
Vous trouverez ci-dessous un déploiement minimal pour AEM sur MongoDB. Pour plus de simplicité, les composants de terminaison SSL et de proxy HTTP ont été généralisés. Le déploiement se compose d’un seul jeu de réplicas MongoDB, dont un principal et deux secondaires.
Un déploiement minimal nécessite trois instances mongod configurées en tant qu’ensemble de répliques. Une seule instance est choisie comme principale, les autres étant secondaires. Le choix est géré par mongod. Un disque local est associé à chaque instance. Pour que le cluster puisse supporter la charge, un débit minimal de 12 Mo par seconde avec plus de 3 000 opérations d’E/S par seconde (IOPS) est recommandé.
Les auteurs AEM sont connectés aux instances mongod, chaque auteur AEM se connectant aux trois instances mongod. Les écritures sont envoyées à l’instance principale et les lectures peuvent être lues depuis n’importe quelle instance. Le trafic est distribué en fonction de la charge par un Dispatcher sur l’une des principales instances de création d’AEM. Le magasin de données Oak est un FileDataStore. La surveillance de MongoDB est assurée par MMS ou MongoDB Ops Manager en fonction de l’emplacement du déploiement. Le niveau du système d’exploitation et la surveillance des journaux sont fournis par des solutions tierces telles que Splunk ou Ganglia.
Dans ce déploiement, tous les composants sont requis pour réussir l’implémentation. Tout composant manquant rend l’implémentation non fonctionnelle.
Systèmes d’exploitation
Pour obtenir la liste des systèmes d’exploitation pris en charge par AEM 6, consultez la page Exigences techniques.
Environnements
Les environnements virtualisés sont pris en charge à condition que la communication soit bonne entre les différentes équipes techniques qui gèrent le projet. Cette prise en charge inclut l’équipe qui exécute AEM, l’équipe propriétaire du système d’exploitation et l’équipe gérant l’infrastructure virtualisée.
Les exigences particulières relatives à la capacité d’E/S des instances de MongoDB doivent être traitées par l’équipe gérant l’environnement virtualisé. Si le projet utilise un déploiement dans le cloud, tel qu’Amazon Web Services, les instances devront être configurées avec une capacité d’E/S et une cohérence suffisantes pour prendre en charge les instances de MongoDB. Dans le cas contraire, les processus de MongoDB et le référentiel Oak s’exécutent de manière non fiable et erratique.
Dans les environnements virtualisés, MongoDB nécessite des configurations d’E/S et de machine virtuelle spécifiques pour s’assurer que le moteur de stockage de MongoDB n’est pas paralysé par des politiques d’allocation de ressources VMWare. Une implémentation réussie garantit qu’il n’existe aucun obstacle entre les différentes équipes et que toutes sont connectées pour offrir les performances requises.
Considérations matérielles
Stockage
Pour obtenir un débit de lecture et d’écriture optimal sans avoir à effectuer de mise à l’échelle horizontale prématurée, MongoDB a généralement besoin d’un stockage SSD ou d’un stockage avec des performances équivalentes au SSD.
Mémoire RAM
Les versions 2.6 et 3.0 de MongoDB qui utilisent le moteur de stockage MMAP nécessitent que le jeu de travail de la base de données et ses index correspondent à la mémoire RAM.
Une mémoire RAM insuffisante entraîne une dégradation importante des performances. La taille du jeu de travail et celle de la base de données dépendent largement de l’application. Bien que certaines estimations puissent être faites, le moyen le plus fiable de déterminer la quantité de RAM requise est de créer l’application AEM et de la tester en termes de charge.
Pour faciliter le processus de test de charge, le ratio suivant entre le jeu de travail et la taille totale de la base de données peut être supposé :
- 1:10 pour un stockage sur SSD
- 1:3 pour un stockage sur disque dur
Ces ratios signifient que, pour les déploiements sur SSD, 200 Go de RAM sont nécessaires pour une base de données de 2 To.
Bien que les mêmes limites s’appliquent au moteur de stockage WiredTiger dans MongoDB 3.0, la corrélation entre le jeu de travail, la RAM et les erreurs de page n’est pas si forte. WiredTiger n’utilise pas le mappage de mémoire de la même manière que le moteur de stockage MMAP.
REMARQUEMagasin de données
En raison des limitations du jeu de travail MongoDB, il est recommandé que le magasin de données soit indépendant de MongoDB. Dans la plupart des environnements, un FileDataStore utilisant un NAS disponible pour toutes les instances AEM doit être utilisé. Pour les cas où Amazon Web Services est utilisé, il existe également un S3 DataStore. Si, pour une raison quelconque, le magasin de données est conservé dans MongoDB, sa taille doit être ajoutée à la taille totale de la base de données et les calculs du jeu de travail doivent être ajustés en conséquence. Ce dimensionnement peut impliquer d’allouer plus de RAM pour maintenir les performances sans erreurs de page.
Surveillance
La surveillance est essentielle pour une implémentation réussie du projet. Avec suffisamment de connaissances, il est possible d’exécuter AEM sur MongoDB sans surveillance. Toutefois, les personnes possédant ces connaissances sont habituellement des ingénieures et des ingénieurs spécialisés dans chaque section du déploiement.
Ces connaissances spécialisées impliquent généralement un ingénieur ou une ingénieure en R&D travaillant sur Apache Oak Core et une personne spécialisée sur MongoDB.
Sans surveillance à tous les niveaux, une connaissance approfondie de la base de code est nécessaire pour identifier les problèmes. Avec une surveillance en place et des conseils adaptés sur les principales statistiques, les équipes d’implémentation peuvent réagir de manière appropriée aux anomalies.
Bien qu’il soit possible d’utiliser des outils de ligne de commande pour obtenir un instantané rapide du fonctionnement d’un cluster, il s’avère presque impossible de le faire en temps réel sur de nombreux hôtes. Les outils de ligne de commande donnent rarement des informations d’historique au-delà de quelques minutes et ne permettent jamais la corrélation croisée entre différents types de mesures. Une brève période de synchronisation mongod en arrière-plan lente nécessite un effort manuel important pour corréler l’attente d’E/S ou des niveaux d’écriture excessifs à une ressource de stockage partagée d’une machine virtuelle apparemment non connectée.
MongoDB Cloud Manager
MongoDB Cloud Manager est un service gratuit offert par MongoDB qui permet la surveillance et la gestion des instances de MongoDB. Il offre une visibilité en temps réel sur les performances et l’intégrité du cluster MongoDB. Il gère à la fois les instances hébergées dans le cloud et de manière privée, à condition que l’instance puisse atteindre le serveur de surveillance de Cloud Manager.
Il nécessite l’installation d’un agent sur l’instance MongoDB qui se connecte au serveur de surveillance. Il existe trois niveaux d’agent :
- Un agent d’automatisation qui peut entièrement automatiser tout ce qui se trouve sur le serveur MongoDB.
- Un agent de surveillance qui peut surveiller l’instance
mongod. - Un agent de sauvegarde qui peut effectuer des sauvegardes planifiées des données.
Bien que l’utilisation de Cloud Manager pour l’automatisation de la maintenance d’un cluster MongoDB simplifie la plupart des tâches de routine, il n’est pas requis et son utilisation pour la sauvegarde ne l’est pas non plus. En choisissant Cloud Manager pour la surveillance, la surveillance est toutefois requise.
Pour plus d’informations sur MongoDB Cloud Manager, consultez la documentation de MongoDB.
MongoDB Ops Manager
MongoDB Ops Manager est le même logiciel que MongoDB Cloud Manager. Une fois enregistré, Ops Manager peut être téléchargé et installé localement dans un centre de données privé ou sur tout autre PC portable ou de bureau. Il utilise une base de données MongoDB locale pour stocker les données et communique de la même manière que Cloud Manager avec les serveurs gérés. Si vous avez des politiques de sécurité qui interdisent un agent de surveillance, il faut utiliser MongoDB Ops Manager.