Adobe Experience Manager mit MongoDB
Dieser Artikel soll das Wissen über Aufgaben und Überlegungen verbessern, die für die erfolgreiche Bereitstellung von AEM (Adobe Experience Manager) mit MongoDB erforderlich sind.
Weitere Informationen zur Bereitstellung finden Sie im Abschnitt Bereitstellung und Wartung der Dokumentation.
Wann MongoDB mit AEM verwendet werden sollte
MongoDB wird normalerweise zur Unterstützung von AEM-Authoring-Bereitstellungen verwendet, wenn eines der folgenden Kriterien erfüllt ist:
- mehr als 1000 Unique Users pro Tag;
- mehr als 100 gleichzeitige Benutzerinnen und Benutzer;
- hohe Anzahl von Seitenbearbeitungen;
- große Rollouts oder Aktivierungen.
Die oben genannten Kriterien gelten nur für die Autoreninstanzen und nicht für Veröffentlichungsinstanzen, die alle auf TarMK basieren sollten. Die Anzahl der Benutzer bzw. Benutzerinnen bezieht sich auf authentifizierte Benutzer bzw. Benutzerinnen, da Authoring-Instanzen keinen nicht-authentifizierten Zugriff zulassen.
Werden die Kriterien nicht erfüllt, wird zwecks Verfügbarkeit eine aktive TarMK-Bereitstellung bzw. eine Standby-TarMK-Bereitstellung empfohlen. Im Allgemeinen sollte MongoDB in Situationen berücksichtigt werden, in denen die Skalierungsanforderungen größer sind, als mit einem einzelnen Hardware-Element erzielt werden kann.
HINWEISMinimale MongoDB-Bereitstellung für AEM
Nachfolgend wird eine minimale Bereitstellung für AEM auf MongoDB aufgeführt. Zur Vereinfachung wurden SSL-Terminierung und HTTP-Proxy-Komponenten verallgemeinert. Die Bereitstellung besteht aus einer einzigen MongoDB-Replikatgruppe mit einem primären Replikat und zwei sekundären Replikaten.
Eine minimale Bereitstellung setzt voraus, dass mongod-Instanzen als Replikatgruppe konfiguriert sind. Eine Instanz wird als primäres Replikat gewählt, die beiden anderen sind sekundäre Replikate; die Wahl wird von mongod verwaltet. Angebunden an jede Instanz ist eine lokale Festplatte. So kann der Cluster die Auslastung unterstützen. Es wird ein Mindestdurchsatz von 12 MB pro Sekunde mit mehr als 3000 I/O Operations per Second (IOPS) empfohlen.
Die AEM-Autoren sind mit den mongod-Instanzen verbunden, wobei jeweils eine Verbindung zu allen drei mongod-Instanzen besteht. Schreibvorgänge werden an die primäre Instanz gesendet und Lesevorgänge können von jeder der Instanzen gelesen werden. Der Traffic wird basierend auf dem Laden durch einen Dispatcher an eine der aktiven AEM-Authoring-Instanzen verteilt. Der Oak-Datenspeicher ist ein FileDataStore und die MongoDB-Überwachung erfolgt je nach Bereitstellungsort über MMS oder MongoDB Ops Manager. Die Betriebssystemebene und die Protokollüberwachung werden von Drittanbieterlösungen wie Splunk oder Ganglia bereitgestellt.
In dieser Bereitstellung sind alle Komponenten für eine erfolgreiche Implementierung erforderlich. Jede fehlende Komponente macht die Implementierung funktionsunfähig.
Betriebssysteme
Eine Aufstellung der unterstützten Betriebssysteme für AEM 6 finden Sie auf der Seite Technische Anforderungen.
Umgebungen
Virtualisierte Umgebungen werden unterstützt, sofern eine gute Kommunikation zwischen den verschiedenen technischen Teams besteht, die das Projekt durchführen. Zu diesem Support gehören das Team, das AEM führt, das Team, das Eigentümer des Betriebssystems ist, und das Team, das die virtualisierte Infrastruktur verwaltet.
Es gibt spezifische Anforderungen an die E/A-Kapazität der MongoDB-Instanzen, die von dem Team verwaltet werden müssen, das die virtualisierte Umgebung verwaltet. Wenn das Projekt eine Cloud-Implementierung wie Amazon Web Services verwendet, müssen Instanzen mit ausreichender I/O-Kapazität und Konsistenz bereitgestellt werden, um die MongoDB-Instanzen zu unterstützen. Andernfalls ist die Leistung der MongoDB-Prozesse und des Oak-Repositorys unzuverlässig und unregelmäßig.
In virtualisierten Umgebungen erfordert MongoDB spezifische I/O- und VM-Konfigurationen, um sicherzustellen, dass die Speichermodul-Engine von MongoDB nicht durch VMware-Richtlinien zur Ressourcenzuordnung beeinträchtigt wird. Eine erfolgreiche Implementierung stellt sicher, dass es keine Hindernisse zwischen den verschiedenen Teams gibt und alle am gleichen Strang ziehen, um die erforderliche Leistung zu liefern.
Hardware-Überlegungen
Speicherung
Um den Lese- und Schreibdurchsatz für optimale Leistung ohne vorzeitige horizontale Skalierung zu erreichen, benötigt MongoDB im Allgemeinen SSD-Speicher oder Speicher mit einer SSD-gleichwertigen Leistung.
RAM
MongoDB-Versionen 2.6 und 3.0, die die MMAP-Speicher-Engine verwenden, erfordern, dass der Arbeitssatz der Datenbank und deren Indizes in den Arbeitsspeicher passen.
Unzureichender Arbeitsspeicher führt zu einer deutlichen Leistungsminderung. Die Größe des Workflows und der Datenbank hängt stark von der Anwendung ab. Während einige Schätzungen vorgenommen werden können, ist die zuverlässigste Methode, den erforderlichen Arbeitsspeicher zu bestimmen, die AEM-Anwendung zu erstellen und Lasttests durchzuführen.
Um den Lasttestvorgang zu unterstützen, kann das folgende Verhältnis zwischen dem Arbeitssatz und der gesamten Datenbankgröße angenommen werden:
- 1:10 für SSD-Speicher
- 1:3 für Festplattenspeicher
Diese Verhältnisse bedeuten, dass für SSD-Bereitstellungen 200 GB RAM für eine 2 TB große Datenbank erforderlich sind.
Die gleichen Einschränkungen gelten für das WiredTiger-Speichermodul in MongoDB 3.0, aber die Korrelation zwischen Arbeitsset, RAM und Seitenfehlern ist nicht so stark. WiredTiger verwendet die Speicherzuordnung nicht auf die gleiche Weise wie die MMAP-Speicher-Engine.
HINWEISDatenspeicher
Aufgrund der Beschränkungen des MongoDB-Arbeitssets wird empfohlen, den Datenspeicher unabhängig von MongoDB zu verwalten. In den meisten Umgebungen sollte ein für alle AEM-Instanzen verfügbarer FileDataStore mit einem NAS verwendet werden. Wird Amazon Web Services genutzt, steht auch ein S3 DataStore zur Verfügung. Wenn der Datenspeicher aus irgendeinem Grund innerhalb von MongoDB verwaltet wird, sollte die Größe des Datenspeichers der gesamten Datenbankgröße hinzugefügt und die Arbeitsset-Berechnungen entsprechend angepasst werden. Diese Größenanpassung kann bedeuten, dass mehr Arbeitsspeicher bereitgestellt wird, um die Leistung ohne Seitenfehler zu gewährleisten.
Überwachung
Überwachung ist für eine erfolgreiche Umsetzung des Projekts von entscheidender Bedeutung. Mit ausreichendem Wissen ist es möglich, AEM auf MongoDB ohne Überwachung auszuführen. Diese Kenntnisse sind jedoch normalerweise bei Technikerpersonal vorhanden, das auf jeden Abschnitt des Einsatzes spezialisiert ist.
Für dieses Wissen ist in der Regel eine Ingenieurin oder ein Ingenieur aus der F&E von Apache Oak Core und eine Spezialistin oder ein Spezialist für MongoDB erforderlich.
Ohne Überwachung auf allen Ebenen sind detaillierte Kenntnisse der Codebasis erforderlich, um Probleme zu diagnostizieren. Durch die vorhandene Überwachung und geeignete Anleitungen zu den wichtigsten Statistiken können Implementierungsteams angemessen auf Anomalien reagieren.
Es ist zwar möglich, Befehlszeilen-Tools zu verwenden, um einen schnellen Überblick über den Betrieb eines Clusters zu erhalten, doch ist es fast unmöglich, dies in Echtzeit über viele Hosts hinweg durchzuführen. Befehlszeilen-Tools geben nur selten historische Informationen nach einigen Minuten zurück und ermöglichen nie eine Kreuzkorrelation zwischen verschiedenen Metriktypen. Ein kurzer Zeitraum langsamer mongod-Hintergrundsynchronisierungen bedeutet zusätzlichen manuellen Aufwand, um I/O-Wartezeiten oder übermäßige Write-Level mit einer freigegebenen Speicherressource von einer scheinbar nicht verbundenen virtuellen Maschine in Beziehung zu setzen.
MongoDB Cloud Manager
MongoDB Cloud Manager ist ein kostenloser Dienst von MongoDB, der die Überwachung und Verwaltung von MongoDB-Instanzen ermöglicht. Er bietet einen Überblick über die Leistung und den Zustand des MongoDB-Clusters in Echtzeit. Es verwaltet sowohl Cloud- als auch privat gehostete Instanzen, sofern die Instanz den Cloud Manager-Überwachungsserver erreichen kann.
Voraussetzung ist die Installation eines Agenten auf der MongoDB-Instanz, der mit dem Überwachungsserver verbunden ist. Es gibt drei Ebenen des Agenten:
- Ein Automatisierungsagent, der alles auf dem MongoDB-Server vollständig automatisieren kann
- Einen Überwachungsagenten, der die
mongod-Instanz überwachen kann - Ein Backup-Agent, der geplante Sicherungen der Daten durchführen kann.
Obwohl die Verwendung von Cloud Manager zur Wartungsautomatisierung eines MongoDB-Clusters viele der Routineaufgaben vereinfacht, ist dies nicht erforderlich und wird auch nicht für Backups verwendet. Wenn Sie sich bei der Überwachung für Cloud Manager entscheiden, ist jedoch eine Überwachung erforderlich.
Weitere Informationen zu MongoDB Cloud Manager finden Sie in der MongoDB-Dokumentation.
MongoDB Ops Manager
MongoDB Ops Manager ist dieselbe Software wie MongoDB Cloud Manager. Nach der Registrierung kann Ops Manager lokal in einem privaten Rechenzentrum oder auf einem anderen Laptop oder Desktop-Computer heruntergeladen und installiert werden. Es verwendet eine lokale MongoDB-Datenbank, um Daten zu speichern und auf dieselbe Weise wie Cloud Manager mit den verwalteten Servern zu kommunizieren. Wenn Sie Sicherheitsrichtlinien haben, die einen Überwachungsagenten verbieten, sollte MongoDB Ops Manager verwendet werden.
Betriebssystemüberwachung
Zum Ausführen eines AEM MongoDB-Clusters ist eine Überwachung auf Betriebssystemebene erforderlich.
Ganglia ist ein gutes Beispiel für ein solches System und liefert ein Bild über die Bandbreite und Details der benötigten Informationen, die über grundlegende Zustandsdaten wie CPU, durchschnittliche Auslastung und freien Speicherplatz hinausgehen. Um Probleme zu diagnostizieren, sind niedrigere Informationen wie Entropy-Pool-Ebenen, CPU-I/O-Wartezeit und Sockets im FIN_WAIT2-Status erforderlich.
Protokollaggregation
Bei einem Cluster aus mehreren Servern ist die zentrale Protokollaggregation eine Voraussetzung für ein Produktionssystem. Software wie Splunk unterstützt die Protokollierung und ermöglicht es Teams, die Verhaltensmuster der Anwendung zu analysieren, ohne die Protokolle manuell erfassen zu müssen.
Checklisten
In diesem Abschnitt werden die verschiedenen Schritte beschrieben, die Sie unternehmen sollten, um sicherzustellen, dass Ihre AEM- und MongoDB-Bereitstellungen vor der Implementierung Ihres Projekts ordnungsgemäß eingerichtet sind.
Netzwerk
- Stellen Sie zunächst sicher, dass alle Hosts einen DNS-Eintrag haben.
- Alle Hosts sollten durch ihren DNS-Eintrag von allen anderen routbaren Hosts aufgelöst werden können
- Alle MongoDB-Hosts sind von allen anderen MongoDB-Hosts im selben Cluster routbar
- MongoDB-Hosts können Pakete an MongoDB Cloud Manager und die anderen Überwachungs-Server weiterleiten
- AEM Server können Pakete an alle MongoDB-Server weiterleiten
- Die Paketlatenz zwischen einem beliebigen AEM-Server und einem MongoDB-Server ist kleiner als zwei Millisekunden, ohne Paketverlust und mit einer Standardverteilung von einer Millisekunde oder weniger.
- Stellen Sie sicher, dass zwischen einem AEM- und einem MongoDB-Server nicht mehr als zwei Hops vorhanden sind.
- Zwischen zwei MongoDB-Servern gibt es nicht mehr als zwei Hops.
- Es gibt keine Router, die höher sind als OSI Level 3 zwischen Kern-Servern (MongoDB oder AEM oder einer Kombination).
- Wenn VLAN-Trunking oder eine Netzwerktunnelung verwendet wird, muss dies den Paketlatenzprüfungen entsprechen.