Présentation de la plateforme AEM
- Rubriques :
- Deploying
Créé pour :
- Developer
La plateforme AEM dans AEM 6 est basée sur Apache Jackrabbit Oak.
Apache Jackrabbit Oak vise à implémenter un référentiel de contenu hiérarchique évolutif et performant pour l’utiliser comme fondation des sites web modernes de classe mondiale et d’autres applications de contenu exigeantes.
Il succède à Jackrabbit 2 et il est utilisé par AEM 6 comme structure par défaut pour son référentiel de contenu, CRX.
Principes et objectifs de conception
Oak met en oeuvre les JSR-283 (JCR 2.0) spécification. Ses principaux objectifs de conception sont les suivants :
- Meilleure prise en charge des référentiels volumineux
- Plusieurs noeuds de cluster répartis pour une haute disponibilité
- Meilleures performances
- Prise en charge de nombreux nœuds enfants et de niveaux de contrôle d’accès
Concept de l’architecture
Stockage
Le but de la couche de stockage est :
- Mise en oeuvre d’un modèle d’arborescence
- Rendre possible l’alimentation du stockage
- Fournir un mécanisme de mise en grappe
Oak Core
Oak Core ajoute plusieurs calques à la couche de stockage :
- Contrôles de niveau d’accès
- Recherche et indexation
- Observation
Oak JCR
L’objectif principal du JCR Oak est de transformer la sémantique JCR en opérations arborescentes. Il est aussi chargé des éléments suivants :
- Mise en oeuvre de l’API JCR
- Contenir des commit hooks qui implémentent des contraintes JCR
En outre, les implémentations non Java sont désormais possibles et font partie du concept Oak JCR.
Présentation du stockage
La couche de stockage Oak fournit une couche d’abstraction pour le stockage réel du contenu.
Actuellement, il existe deux implémentations du stockage disponibles dans AEM 6 : le stockage tar et le stockage MongoDB.
Stockage tar
Le stockage Tar utilise des fichiers tar. Il stocke le contenu sous la forme de différents types d’enregistrements dans des segments plus volumineux. Les journaux sont utilisés pour effectuer le suivi de l’état le plus récent du référentiel.
Il existe plusieurs principes de conception clés sur lesquels il a été construit :
- Segments non modifiables
Le contenu est stocké dans les segments avec une taille pouvant aller jusqu’à 256 Ko. Ils sont inaltérables, ce qui permet de mettre en cache les segments utilisés fréquemment et de réduire les erreurs système susceptibles de compromettre le référentiel.
Chaque segment est identifié par un identifiant unique (UUID) et contient un sous-ensemble continu de l’arborescence de contenu. En outre, les segments peuvent référencer d’autres contenus. Chaque segment conserve une liste des UUID des autres segments référencés.
- Localité
Les enregistrements associés tels qu’un noeud et ses enfants immédiats sont généralement stockés dans le même segment. Cela permet de rechercher le référentiel très rapidement et d’éviter la plupart des pertes de cache pour les clients standard qui accèdent à plusieurs noeuds associés par session.
- Compacité
La mise en forme des enregistrements est optimisée pour la taille afin de réduire les coûts d’E/S et d’intégrer le plus de contenu possible dans les caches.
Stockage Mongo
Le stockage MongoDB exploite MongoDB pour le partage et la mise en grappe. L’arborescence du référentiel est conservée dans une base de données MongoDB où chaque noeud est un document distinct.
Il a plusieurs particularités :
- Révisions
Pour chaque mise à jour (validation) du contenu, une nouvelle révision est créée. Une révision est essentiellement une chaîne composée de trois éléments :
- Horodatage dérivé de l’heure système de la machine sur laquelle il a été généré.
- Un compteur pour distinguer les révisions créées avec le même horodatage
- ID de noeud de la grappe dans lequel la révision a été créée
- Branches
Les branches sont prises en charge, ce qui permet au client d’organiser plusieurs modifications et de les rendre visibles avec un seul appel de fusion.
- Documents précédents
Le stockage MongoDB ajoute des données à un document à chaque modification. Cependant, elle supprime uniquement les données si un nettoyage est explicitement déclenché. Les anciennes données sont déplacées lorsqu’un certain seuil est atteint. Les documents précédents ne contiennent que des données non modifiables, ce qui signifie qu’ils ne contiennent que des révisions validées et fusionnées.
- Métadonnées du noeud de cluster
Les données relatives aux noeuds de cluster principaux et inactifs sont conservées dans la base de données afin de faciliter les opérations de cluster.
Une configuration en cluster AEM typique avec un stockage MongoDB :
Qu'est-ce qui diffère de Jackrabbit 2 ?
Oak étant conçu pour être rétrocompatible avec la norme JCR 1.0, il n’y aura pratiquement aucune modification au niveau de l’utilisateur. Cependant, il existe des différences notables que vous devez prendre en compte lors de la configuration d’une AEM basée sur Oak :
- Oak ne crée pas automatiquement d’index. Pour cette raison, les index personnalisés doivent être créés si nécessaire.
- Contrairement à Jackrabbit 2 où les sessions reflètent toujours le dernier état du référentiel, avec Oak, une session reflète une vue stable du référentiel à partir du moment où la session a été acquise. Cela est dû au modèle MVCC sur lequel Oak est basé.
- Les frères de même nom (SNS) ne sont pas pris en charge dans Oak.
Autre documentation liée aux plateformes
Pour plus d'informations sur la plateforme AEM, consultez également les articles ci-dessous :
Experience Manager
- Guide de l’utilisateur du déploiement
- Présentation de la plateforme AEM
- Déploiement d’AEM
- Déploiement et maintenance
- Déploiements recommandés
- Installation du serveur d’applications
- Installation autonome personnalisée
- Début et arrêt d’AEM à partir de la ligne de commande
- Configuration des magasins de nœuds et des entrepôts de données dans AEM 6
- Nettoyage de révision
- Exécuter AEM avec TarMK Cold Standby
- Prise en charge RDBMS dans AEM 6.4
- Requêtes et indexation Oak
- Indexation par l’intermédiaire du fichier Jar d’Oak-run
- Indexation du fichier Oak-run.jar – Scénarios d’utilisation
- Dépannage des index Oak
- Souscription à la collecte de statistiques d’utilisation agrégées
- Résolution des problèmes
- Configuration d’AEM
- Concepts de configuration de base
- Journalisation
- Configuration d’OSGi
- Paramètres de configuration OSGi
- Modes d’exécution
- Console web
- Réplication
- Réplication à l’aide du SSL mutuel
- Résolution des problèmes liés à la réplication
- Expiration des objets statiques
- Purge de version
- Contrôle et maintien de votre instance AEM
- Tâches de déchargement
- Connexion unique
- Mappage de ressource
- Activation du HTTP via SSL
- Vérifications transversales et contrôles de cohérence
- Instructions de performance
- Optimisation des performances
- Guide de performances des ressources
- Articles sur la procédure de configuration
- Suppression des sites de Geometrixx
- Configuration de la console web
- Mettre à niveau vers AEM 6.4
- Mettre à niveau vers AEM 6.4
- Planification de la mise à niveau
- Évaluation de la complexité de la mise à niveau à l’aide de l’outil de détection des motifs
- Compatibilité ascendante dans AEM 6.4
- Procédure de mise à niveau
- Utilisation de la réindexation hors ligne pour réduire les temps d’arrêt pendant une mise à niveau
- Effectuer une mise à niveau statique
- Migration différée du contenu
- Utilisation de l’outil de migration CRX2Oak
- Tâches de maintenance avant la mise à niveau
- Vérifications et dépannage après une mise à niveau
- Mise à niveau des formulaires de recherche personnalisée
- Mises à niveau possibles
- Mise à niveau du code et des personnalisations
- Procédure de mise à niveau pour les installations de serveur d’applications
- Liste des lots obsolètes désinstallés après la mise à niveau
- Restructuration des référentiels
- Restructuration des référentiels dans AEM 6.4
- Restructuration des référentiels dans AEM 6.4
- Restructuration des référentiels dans AEM 6.4
- Restructuration des référentiels d’Assets dans AEM 6.4
- Restructuration des référentiels Dynamic Media dans AEM 6.4
- Restructuration des référentiels de Forms dans AEM 6.4
- Restructuration des référentiels e-Commerce dans AEM 6.4
- Restructurer les référentiels pour AEM Communities dans la version 6.4
- eCommerce
- Bonnes pratiques