Adobe Experience Manager mit MongoDB aem-with-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 when-to-use-mongodb-with-aem

MongoDB wird normalerweise zur Unterstützung von AEM-Authoring-Bereitstellungen verwendet, wenn eines der folgenden Kriterien erfüllt ist:

Die oben genannten Kriterien gelten nur für die Authoring-Instanzen und nicht für Publishing-Instanzen, 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.

Minimale MongoDB-Bereitstellung für AEM minimal-mongodb-deployment-for-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 das 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 operating-systems

Eine Aufstellung der unterstützten Betriebssysteme für AEM 6 finden Sie auf der Seite Technische Anforderungen.

Umgebungen environments

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 I/O-Kapazität der MongoDB-Instanzen, die vom 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 hardware-considerations

Speicherung storage

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 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:

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.

Datenspeicher data-store

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 monitoring

Ü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

MongoDB Cloud Manager ist ein kostenloser Dienst von MongoDB, der die Überwachung und Verwaltung von MongoDB-Instanzen ermöglicht. Es 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:

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. Bei der Wahl von Cloud Manager zur Überwachung ist jedoch eine Überwachung erforderlich.

Weitere Informationen zu MongoDB Cloud Manager finden Sie in der MongoDB-Dokumentation.

MongoDB Ops Manager 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 operating-system-monitoring

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, Lastdurchschnitt 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 log-aggregation

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 checklists

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 network

AEM-Konfiguration aem-configuration

Knotenspeicherkonfiguration node-store-configuration

Die AEM-Instanzen müssen für die Verwendung von AEM mit MongoMK konfiguriert werden. Die Grundlage der MongoMK-Implementierung in AEM ist der Knotenspeicher „Dokument“.

Weitere Informationen zum Konfigurieren von Knotenspeichern finden Sie unter Konfigurieren von Knotenspeichern und Datenspeichern in AEM.

Nachfolgend finden Sie ein Beispiel für die Konfiguration des Knotenspeichers für eine minimale MongoDB-Bereitstellung:

# org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
#MongoDB server details
mongodburi=mongodb://aem:aempassword@mongodbserver1.customer.com:27000,mongodbserver2.customer.com:27000

#Name of MongoDB database to use
db=aem

#Store binaries in custom BlobStore for example, FileDataStore
customBlobStore=true

cache=2048
blobCacheSize=1024

Dabei gilt:

Datenspeicherkonfiguration data-store-configuration

Der Datenspeicher dient zum Speichern von Dateien mit einer Größe, die größer als ein Schwellenwert ist. Unter diesem Schwellenwert werden Dateien als Eigenschaften im Knotenspeicher „Dokument“ gespeichert. Wenn der MongoBlobStore verwendet wird, wird in MongoDB eine dedizierte Sammlung zum Speichern der Blobs erstellt. Diese Sammlung trägt zum Workingset der mongod-Instanz bei und setzt einen größeren Arbeitsspeicher für die mongod-Instanz voraus, um Leistungsprobleme zu vermeiden. Daher wird für Konfigurationen empfohlen, in Produktionsbereitstellungen auf MongoBlobStore zu verzichten und einen FileDataStore einzusetzen, der von einem von allen AEM-Instanzen genutzten NAS gestützt wird. Da der Cache auf Betriebssystemebene bei der Verwaltung von Dateien effizient ist, sollte die Mindestgröße einer Datei auf dem Datenträger auf die Blockgröße der Festplatte eingestellt werden. Dadurch wird sichergestellt, dass das Dateisystem effizient verwendet wird und viele kleine Dokumente nicht übermäßig zum Workingset der mongod-Instanz beitragen.

Es folgt ein Beispiel einer typischen Datenspeicherkonfiguration für eine minimale AEM-Bereitstellung mit MongoDB:

# org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config
# The minimum size of an object that should be stored in this data store.
minRecordLength=4096
path=/datastore
maxCachedBinarySize=4096
cacheSizeInMB=128

Dabei gilt:

Deaktivieren des Abfragehinweises disabling-the-query-hint

Es wird empfohlen, den mit allen Abfragen gesendeten Abfragehinweis zu deaktivieren, indem Sie die Eigenschaft -Doak.mongo.disableIndexHint=true beim Starten von AEM hinzufügen. Dadurch wird sichergestellt, dass MongoDB anhand interner Statistiken den am besten geeigneten Index berechnet.

Wenn der Abfragehinweis nicht deaktiviert ist, hat eine Leistungsoptimierung von Indizes keine Auswirkungen auf die Leistung von AEM.

Aktivieren des persistenten Cache für MongoMK enable-persistent-cache-for-mongomk

Es wird empfohlen, eine persistente Cache-Konfiguration für MongoDB-Bereitstellungen zu aktivieren, um die Geschwindigkeit für Umgebungen mit hoher I/O-Leseleistung zu maximieren. Weitere Informationen finden Sie in der Jackrabbit Oak-Dokumentation.

MongoDB-Betriebssystemoptimierungen mongodb-operating-system-optimizations

Betriebssystemunterstützung operating-system-support

MongoDB 2.6 nutzt ein Speichermodul mit Speicherzuordnung, das auf einige Aspekte der Verwaltung der Betriebssystemebene zwischen RAM und Datenträger empfindlich reagiert. Die Abfrage- und Leseleistung der MongoDB-Instanz beruht darauf, langsame I/O-Vorgänge, die häufig als Seitenfehler bezeichnet werden, zu vermeiden oder zu beseitigen. Bei diesen Problemen handelt es sich um Seitenfehler, die insbesondere für den Prozess mongod gelten. Verwechseln Sie sie nicht mit Seitenfehlern auf Betriebssystemebene.

Für einen schnellen Betrieb sollte die MongoDB-Datenbank nur auf Daten zugreifen, die sich bereits im RAM befinden. Die Daten, auf die sie zugreifen muss, bestehen aus Indizes und Daten. Diese Sammlung von Indizes und Daten wird als Arbeitssatz bezeichnet. Wenn der Arbeitssatz größer als der verfügbare RAM ist, muss MongoDB diese Daten von der Festplatte auslagern, was I/O-Kosten verursacht, und andere Daten, die bereits im Speicher sind, entfernen. Wenn die Entfernung dazu führt, dass Daten von der Festplatte neu geladen werden, dominieren Seitenfehler und die Leistung sinkt. Bei einem dynamischen und variablen Arbeitssatz tritt bei Support-Vorgängen eine größere Anzahl von Seitenfehlern auf.

MongoDB läuft auf verschiedenen Betriebssystemen, einschließlich einer Vielzahl von Linux®-Versionen, Windows und macOS. Siehe https://docs.mongodb.com/manual/installation/#supported-platforms für weitere Details. Je nach Wahl Ihres Betriebssystems bietet MongoDB verschiedene Empfehlungen auf Betriebssystemebene. Diese sind unter https://docs.mongodb.com/manual/administration/production-checklist-operations/#operating-system-configuration dokumentiert und werden hier lediglich zusammengefasst.

Linux® linux

Windows windows

WiredTiger wiredtiger

Ab MongoDB 3.2 ist WiredTiger die standardmäßige Speicher-Engine für MongoDB. Diese Engine bietet einige robuste und skalierbare Funktionen, wodurch sie für allgemeine Datenbank-Workloads deutlich besser geeignet ist. Die folgenden Abschnitte beschreiben diese Funktionen.

Parallelität auf Dokumentebene document-level-concurrency

WiredTiger verwendet die Parallelitätssteuerung auf Dokumentebene für Schreibvorgänge. Dadurch können mehrere Clients verschiedene Dokumente einer Sammlung gleichzeitig ändern.

Für die meisten Lese- und Schreibvorgänge verwendet WiredTiger eine optimistische Parallelitätssteuerung. WiredTiger verwendet nur Absichtssperren auf globaler, Datenbank- und Sammlungsebene. Wenn die Speicher-Engine Konflikte zwischen zwei Vorgängen erkennt, kommt es zu einem Schreibkonflikt, der dazu führt, dass MongoDB diesen Vorgang transparent erneut versucht. Einige globale Vorgänge, normalerweise kurzlebige Vorgänge mit mehreren Datenbanken, erfordern weiterhin eine globale „instanzübergreifende“ Sperre.

Für einige andere Vorgänge wie das Ablegen einer Sammlung ist weiterhin eine exklusive Datenbanksperre erforderlich.

Snapshots und Checkpoints snapshots-and-checkpoints

WiredTiger nutzt MultiVersion Concurrency Control (MVCC). Beim Start eines Vorgangs erstellt WiredTiger eine Momentaufnahme (Point-in-Time-Snapshot) der Daten für die Transaktion. Ein Snapshot enthält eine konsistente Darstellung der In-Memory-Daten.

Beim Schreiben auf die Festplatte schreibt WiredTiger alle in einem Snapshot enthaltenen Daten konsistent über alle Datendateien auf die Festplatte. Die jetzt permanenten Daten dienen als Checkpoint in den Datendateien. Der Checkpoint stellt sicher, dass die Datendateien bis einschließlich zum letzten Checkpoint konsistent sind. Das heißt, Checkpoints können als Wiederherstellungspunkte dienen.

MongoDB konfiguriert WiredTiger so, dass Checkpoints (d. h. das Schreiben des Snapshots auf die Festplatte) in Intervallen von 60 Sekunden oder für jeweils 2 GB Journaldaten erstellt werden.

Während des Schreibens eines neuen Checkpoints ist der vorherige Checkpoint weiterhin gültig. Daher kann MongoDB den letzten gültigen Checkpoint nach einem Neustart auch dann wiederherstellen, wenn es während des Schreibens des neuen Checkpoints zu einem Fehler oder einem Absturz kommt.

Der neue Checkpoint wird verfügbar und dauerhaft, wenn die Metadatentabelle von WiredTiger automatisch aktualisiert wird, um auf den neuen Checkpoint zu verweisen. Sobald der neue Checkpoint verfügbar ist, gibt WiredTiger die Seiten des alten Checkpoints frei.

Wenn WiredTiger ohne Journal verwendet wird, kann MongoDB den letzten Checkpoint wiederherstellen. Um jedoch die Änderungen wiederherzustellen, die nach dem letzten Checkpoint durchgeführt wurden, müssen Sie mit Journal arbeiten.

Journal journal

WiredTiger verwendet ein Write-Ahead-Transaktionsprotokoll in Kombination mit Checkpoints, um die Dauerhaftigkeit der Daten sicherzustellen.

Das WiredTiger-Journal speichert dauerhaft alle zwischen Checkpoints durchgeführten Datenänderungen. Wenn MongoDB zwischen Checkpoints beendet wird, verwendet es das Journal, um alle seit dem letzten Checkpoint geänderten Daten wiederzugeben. Informationen zur Häufigkeit, mit der MongoDB die Journaldaten auf die Festplatte schreibt, finden Sie unter Journalprozess.

Das WiredTiger-Journal wird mit der Datenkomprimierungsbibliothek snappy komprimiert. Verwenden Sie zum Angeben eines alternativen Komprimierungsalgorithmus oder keiner Komprimierung die Einstellung storage.wiredTiger.engineConfig.journalCompressor.

Siehe Journaling mit WiredTiger.

Komprimierung compression

Mit WiredTiger unterstützt MongoDB die Komprimierung für alle Sammlungen und Indizes. Die Komprimierung minimiert die Speichernutzung zulasten der CPU-Nutzung.

WiredTiger nutzt standardmäßig die Blockkomprimierung der snappy-Komprimierungsbibliothek für alle Sammlungen und die Präfixkomprimierung für alle Indizes.

Für Sammlungen ist auch eine Blockkomprimierung mit zlib verfügbar. Verwenden Sie zum Angeben eines alternativen Komprimierungsalgorithmus oder keiner Komprimierung die Einstellung storage.wiredTiger.collectionConfig.blockCompressor.

Die Präfixkomprimierung für Indizes können Sie mit der Einstellung storage.wiredTiger.indexConfig.prefixCompression deaktivieren.

Die Komprimierungseinstellungen können während der Sammlung- und Indexerstellung auch pro Sammlung und Index konfiguriert werden. Siehe Festlegen der Speicher-Engine-Optionen und db.collection.createIndex() storageEngine-Option.

Für die meisten Arbeitslasten bieten die Standardkomprimierungseinstellungen ein ausgewogenes Verhältnis zwischen Speichereffizienz und Verarbeitungsanforderungen.

Das WiredTiger-Journal wird ebenfalls standardmäßig komprimiert. Informationen zur Journalkomprimierung finden Sie unter Journal.

Speichernutzung memory-use

Bei WiredTiger verwendet MongoDB sowohl den internen Cache von WiredTiger als auch den Dateisystemcache.

Seit Version 3.4 verwendet der interne Cache von WiredTiger standardmäßig eine der beiden folgenden Größen:

WiredTiger verwendet standardmäßig die Snappy-Blockkomprimierung für alle Sammlungen und die Präfixkomprimierung für alle Indizes. Die Standardwerte für die Komprimierung sind auf globaler Ebene konfigurierbar, können aber auch während des Erstellens einer Sammlung oder eines Index für die jeweilige Sammlung oder den Index konfiguriert werden.

Für Daten im internen WiredTiger-Cache werden andere Darstellungen verwendet als für das On-Disk-Format:

Indizes, die im internen Cache von WiredTiger geladen werden, weisen eine andere Datendarstellung auf als das On-Disk-Format, können aber dennoch die Indexpräfixkomprimierung nutzen, um die RAM-Nutzung zu reduzieren.

Die Indexpräfixkomprimierung dedupliziert allgemeine Präfixe aus indizierten Feldern.

Sammlungsdaten im internen Cache von WiredTiger sind unkomprimiert und verwenden eine andere Darstellung als das On-Disk-Format. Die Blockkomprimierung kann erhebliche Speichereinsparungen auf der Festplatte ermöglichen, doch müssen die Daten unkomprimiert werden, damit sie vom Server bearbeitet werden können.

Über den Dateisystemcache verwendet MongoDB automatisch alle freien Speicher, die nicht vom WiredTiger-Cache oder anderen Prozessen verwendet werden.

Informationen zum Anpassen der Größe des internen WiredTiger-Cache finden Sie unter storage.wiredTiger.engineConfig.cacheSizeGB und —wiredTigerCacheSizeGB. Vermeiden Sie es, den internen Cache von WiredTiger über seinen Standardwert hinaus zu erhöhen.

NUMA numa

NUMA (Non-Uniform Memory Access) ermöglicht es einem Kernel zu verwalten, wie Speicher den Prozessorkernen zugeordnet wird. Obwohl dieser Prozess versucht, den Speicherzugriff für die Kerne zu beschleunigen, um sicherzustellen, dass sie auf die benötigten Daten zugreifen können, beeinträchtigt NUMA MMAP und führt zusätzliche Latenzzeiten ein, da Lesevorgänge nicht vorhergesagt werden können. Daher muss NUMA für den mongod-Prozess auf allen fähigen Betriebssystemen deaktiviert werden.

Im Wesentlichen ist in einer NUMA-Architektur der Speicher mit den CPUs verbunden und die CPUs sind mit einem Bus verbunden. In einer SMP- oder UMA-Architektur ist der Speicher mit dem Bus verbunden und wird von den CPUs gemeinsam genutzt. Wenn ein Thread Speicher auf einer NUMA-CPU zuweist, wird er gemäß einer Richtlinie zugewiesen. Standardmäßig wird Speicher zugeordnet, der an die lokale CPU des Threads angebunden ist, es sei denn, es ist keine freie vorhanden. In einem solchen Fall wird dann Speicher von einer freien CPU verwendet, allerdings mit höherem Aufwand. Nach der Zuweisung wechselt der Speicher nicht mehr zwischen den CPUs. Die Zuordnung erfolgt anhand einer Richtlinie, die vom übergeordneten Thread vererbt wird. Letztendlich ist dies der Thread, über den der Prozess gestartet wurde.

In vielen Datenbanken, die den Computer als eine mehrfache, einheitliche Speicherarchitektur betrachten, führt dieses Szenario dazu, dass die anfängliche CPU zuerst voll wird und die sekundäre CPU erst später gefüllt wird. Dies gilt insbesondere dann, wenn ein zentraler Thread für die Zuordnung von Speicherpuffern verantwortlich ist. Zur Lösung muss mithilfe des folgenden Befehls die NUMA-Richtlinie des Haupt-Threads geändert werden, mit dem der mongod-Prozess gestartet wird:

numactl --interleaved=all <mongod> -f config

Diese Richtlinie ordnet Speicher in einem Rundlaufverfahren über alle CPU-Knoten zu, wodurch eine gleichmäßige Verteilung über alle Knoten gewährleistet ist. Sie erzeugt nicht den leistungsfähigsten Speicherzugriff, wie in Systemen mit Mehrfach-CPU-Hardware. Ungefähr die Hälfte der Speichervorgänge erfolgt langsamer und über den Bus, aber mongod ist nicht auf eine optimale NUMA-Nutzung ausgelegt. Daher handelt es sich um einen vernünftigen Kompromiss.

NUMA-Probleme numa-issues

Wenn der mongod-Prozess über einen anderen Speicherort als vom Ordner /etc/init.d gestartet wird, ist davon auszugehen, dass der Start nicht mit der richtigen NUMA-Richtlinie erfolgt ist. Je nach Standardrichtlinie können Probleme entstehen. Dies liegt daran, dass die verschiedenen Linux® Package Manager-Installer für MongoDB auch einen Dienst installieren, dessen Konfigurationsdateien sich in /etc/init.d befinden und die oben beschriebenen Schritte ausführen. Wenn Sie MongoDB direkt aus einem Archiv (.tar.gz) installieren und ausführen, müssen Sie mongod unter dem Prozess numactl manuell ausführen.

Das Verhalten des MongoDB-Prozesses kann abhängig von der jeweiligen Zuordnungsrichtlinie variieren:

Einige der Richtlinien können einen geringeren Wert als die für den mongod-Prozess verfügbare RAM-Gesamtmenge zur Folge haben. Im Gegensatz zu MySQL vermeidet MongoDB aktiv das Paging auf Betriebssystemebene, sodass der mongod-Prozess ggf. weniger Speicher erhält als verfügbar angezeigt wird.

Austausch swapping

Aufgrund der speicherintensiven Natur von Datenbanken muss der Austausch auf Betriebssystemebene deaktiviert werden. Der MongoDB-Prozess vermeidet das Austauschen von vornherein.

Remote-Dateisysteme remote-filesystems

Remote-Dateisysteme wie NFS werden für die internen Datendateien von MongoDB (die Datenbankdateien des mongod-Prozesses) nicht empfohlen, weil sie zu viel Latenz verursachen. Dies ist nicht mit dem freigegebenen Dateisystem zu verwechseln, das zum Speichern von Oak-Blobs (FileDataStore) erforderlich ist. Dafür wird NFS empfohlen.

Read-Ahead read-ahead

Passen Sie „Weiterlesen“ an, damit unnötige Blöcke nicht von der Festplatte gelesen werden, wenn eine Seite mit einem zufälligen Lesevorgang eingebunden wird. Solche Ergebnisse bedeuten einen unnötigen Verbrauch von I/O-Bandbreite.

Linux®-Anforderungen linux-requirements

Minimale Kernelversionen minimum-kernel-versions

Empfohlene Einstellungen für Datenbank-Festplatten recommended-settings-for-database-disks

Deaktivieren von atime

Es wird empfohlen, atime für die Festplatten mit den Datenbanken zu deaktivieren.

NOOP-Festplatten-Planung einstellen

Gehen Sie folgendermaßen vor:

Überprüfen Sie zunächst die I/O-Planung, die durch Ausführen des folgenden Befehls eingestellt wird:

cat /sys/block/sdg/queue/scheduler

Wenn die Antwort noop lautet, gibt es nichts mehr, was Sie tun müssen.

Ist NOOP nicht als I/O-Scheduler eingerichtet, können Sie dies durch Ausführen von Folgendem ändern:

echo noop > /sys/block/sdg/queue/scheduler

Anpassen des Werts für „Weiterlesen“

Es wird empfohlen, für die Festplatten, auf denen MongoDB-Datenbanken ausgeführt werden, den Wert 32 zu verwenden. Dieser Wert beträgt 16 KB. Sie können ihn wie folgt festlegen:

sudo blockdev --setra <value> <device>

NTP aktivieren enable-ntp

Vergewissern Sie sich, dass NTP auf dem Computer installiert ist, auf dem die MongoDB-Datenbanken gehostet werden. Beispielsweise können Sie NTP über Yum Package Manager auf einem CentOS-Rechner installieren:

sudo yum install ntp

Nachdem der NTP-Daemon installiert und erfolgreich gestartet wurde, können Sie die Drift-Datei auf den Zeitversatz Ihres Servers überprüfen.

Transparent Huge Pages deaktivieren disable-transparent-huge-pages

Red Hat® Linux® nutzt einen Speicherverwaltungsalgorithmus mit der Bezeichnung THP (Transparent Huge Pages). Es wird empfohlen, diesen zu deaktivieren, wenn Sie das Betriebssystem für Datenbank-Workloads einsetzen.

Eine Deaktivierung ist mithilfe der folgenden Vorgehensweise möglich:

Deaktivieren von NUMA disable-numa

In den meisten Installationen mit NUMA-Aktivierung wird NUMA automatisch vom MongoDB-Daemon deaktiviert, sofern die Ausführung als Dienst über den Ordner /etc/init.d erfolgt.

Wenn dies nicht der Fall ist, können Sie NUMA auf Prozessebene deaktivieren. Zum Deaktivieren führen Sie diese Befehle aus:

numactl --interleave=all <path_to_process>

<path_to_process> steht dabei für den Pfad zum mongod-Prozess.

Deaktivieren Sie dann den „zone_reclaim“-Modus, indem Sie Folgendes ausführen:

echo 0 > /proc/sys/vm/zone_reclaim_mode

Optimieren der ulimit-Einstellungen für den mongod-Prozess tweak-the-ulimit-settings-for-the-mongod-process

Linux® ermöglicht eine konfigurierbare Kontrolle über die Ressourcenzuweisung mithilfe des Befehls ulimit. Dies kann auf Benutzer- oder Prozessbasis geschehen.

Es wird empfohlen, „ulimit“ für den mongod-Prozess gemäß den MongoDB-empfohlenen ulimit-Einstellungen zu konfigurieren.

Testen der MongoDB-I/O-Leistung test-mongodb-i-o-performance

MongoDB bietet ein Tool namens mongoperf, das zum Testen der I/O-Leistung entwickelt wurde. Sie sollten damit die Leistung aller MongoDB-Instanzen in Ihrer Infrastruktur testen.

Informationen zum Verwenden von mongoperf finden Sie in der MongoDB-Dokumentation.

Testen der Leseleistung auf den virtuellen Maschinen einer Bereitstellung

Wechseln Sie nach der Installation des Tools in das MongoDB-Datenbankverzeichnis, um die Tests durchzuführen. Starten Sie dann den ersten Test, indem Sie mongoperf mit der folgenden Konfiguration ausführen:

echo "{nThreads:32,fileSizeMB:1000,r:true}" | mongoperf

Die gewünschte Ausgabe sollte bis zu zwei Gigabyte pro Sekunde (2 GB/s) sowie 500.000 IOPS bei 32 Threads für alle MongoDB-Instanzen erreichen.

Führen Sie einen zweiten Test durch (dieses Mal mit den speicherzugeordneten Dateien), indem Sie den Parameter mmf:true festlegen:

echo "{nThreads:32,fileSizeMB:1000,r:true,mmf:true}" | mongoperf

Die Ausgabe des zweiten Tests sollte deutlich höher sein als die erste und die Leistung in Bezug auf die Speicherübertragung angeben.

Testen der Schreibleistung der primären MongoDB-Instanz

Überprüfen Sie als Nächstes die I/O-Schreibleistung der primären MongoDB-Instanz, indem Sie mongoperf mit denselben Einstellungen über das MongoDB-Datenbankverzeichnis ausführen:

echo "{nThreads:32,fileSizeMB:1000,w:true}" | mongoperf

Die gewünschte Ausgabe sollte 12 MB pro Sekunde betragen und etwa 3000 IOPS erreichen, wobei die Anzahl der Threads nur geringfügig variiert.

Schritte für virtualisierte Umgebungen steps-for-virtualised-environments

VMware vmware

Wenn Sie virtualisierte Umgebungen mithilfe von VMware ESX verwalten und bereitstellen, müssen Sie für den MongoDB-Betrieb die folgenden Einstellungen über die ESX-Konsole vornehmen:

Amazon Web Services amazon-web-services

Informationen zum Einrichten von MongoDB mit Amazon Web Services finden Sie im Artikel Configure AWS Integration (Konfigurieren der AWS-Integration) auf der MongoDB-Website.

Sichern von MongoDB vor der Bereitstellung securing-mongodb-before-deployment

In diesem Beitrag über die sichere Bereitstellung von MongoDB finden Sie Hinweise, wie Sie die Konfiguration Ihrer Datenbanken vor der Bereitstellung sichern können.

Dispatcher dispatcher

Auswählen des Betriebssystems für den Dispatcher choosing-the-operating-system-for-the-dispatcher

Damit Ihre MongoDB-Bereitstellung ordnungsgemäß funktioniert, muss auf dem Betriebssystem, auf dem der Dispatcher läuft, Apache httpd Version 2.4 oder höher laufen.

Stellen Sie zudem sicher, dass alle Bibliotheken im Build auf dem aktuellen Stand sind, um Auswirkungen auf die Sicherheit zu minimieren.

Dispatcher-Konfiguration dispatcher-configuration

Eine typische Dispatcher-Konfiguration verarbeitet das zehn- bis 20-Fache des Anforderungsdurchsatzes einer AEM-Einzelinstanz.

Da der Dispatcher hauptsächlich ohne Status ist, kann er mit Leichtigkeit horizontal skaliert werden. In einigen Bereitstellungen müssen Autorinnen und Autoren am Zugriff auf bestimmte Ressourcen gehindert werden. Es wird empfohlen, einen Dispatcher mit den Authoring-Instanzen zu verwenden.

Wenn AEM ohne Dispatcher ausgeführt wird, müssen die SSL-Beendigung und der Lastenausgleich von einer anderen Anwendung durchgeführt werden. Dies ist erforderlich, weil Sitzungen eine Affinität gegenüber der AEM-Instanz aufweisen müssen, auf der sie erstellt wurden. Dieses Konzept ist auch als Sticky-Verbindung bekannt. Damit soll sichergestellt werden, dass die Aktualisierungen der Inhalte mit minimaler Latenz erfolgen.

Weitere Informationen zur entsprechenden Konfiguration finden Sie in der Dispatcherdokumentation.

Zusätzliche Konfiguration additional-configuration

Sticky-Verbindungen sticky-connections

Sticky-Verbindungen stellen sicher, dass personalisierte Seiten und Sitzungsdaten für einen Benutzer bzw. eine Benutzerin alle auf derselben Instanz von AEM erstellt werden. Diese Daten werden in der Instanz gespeichert, sodass nachfolgende Anforderungen desselben Benutzers bzw. Benutzerin an dieselbe Instanz zurückgegeben werden.

Es wird empfohlen, Sticky-Verbindungen für alle inneren Ebenen zu aktivieren, die Routing-Anfragen an die AEM-Instanzen weiterleiten, damit nachfolgende Anfragen dieselbe AEM-Instanz erreichen. Auf diese Weise wird die Latenz minimiert, die andernfalls beim Aktualisieren von Inhalten zwischen Instanzen erkennbar ist.

Langes Ablaufdatum long-expires

Standardmäßig werden Inhalte, die von einem AEM-Dispatcher gesendet werden, mit „Zuletzt geändert“ und „eTag“ versehen, ohne dass ein Hinweis auf den Ablauf des Inhalts erfolgt. Dadurch wird sichergestellt, dass die Benutzeroberfläche immer die neueste Version der Ressource erhält. Dies bedeutet auch, dass der Browser einen GET-Vorgang ausführt, um zu sehen, ob sich die Ressource geändert hat. Daher kann es je nach Seitenladezeit zu mehreren Anfragen kommen, auf die die HTTP-Antwort „304 (Nicht geändert)“ beträgt. Bei Ressourcen, die nicht ablaufen, wird der Inhalt zwischengespeichert, wenn Sie eine Ablaufdatum-Kopfzeile festlegen und die Kopfzeilen „Zuletzt geändert“ und „eTag“ entfernen. Und es werden keine weiteren Aktualisierungsanforderungen gestellt, bis das Datum in der Ablaufdatum-Kopfzeile erreicht ist.

Die Verwendung dieser Methode bedeutet jedoch, dass es keine vernünftige Möglichkeit gibt, die Ressource im Browser ablaufen zu lassen, bevor der Zeitraum für die Ablaufdatum-Kopfzeile abläuft. Um diesen Workflow zu umgehen, kann der HtmlClientLibraryManager so konfiguriert werden, dass unveränderliche URLs für Client-Bibliotheken verwendet werden.

Diese URLs werden garantiert nicht geändert. Wenn sich der Inhalt der in der URL enthaltenen Ressource ändert, werden die Änderungen in der URL wiedergegeben, sodass der Browser die richtige Version der Ressource anfordert.

Die Standardkonfiguration fügt dem HtmlClientLibraryManager einen Selektor hinzu. Als Selektor wird die Ressource im Dispatcher zwischengespeichert, wobei der Selektor intakt ist. Dieser Selektor kann auch verwendet werden, um das richtige Ablaufverhalten sicherzustellen. Der Standardselektor folgt dem Muster lc-.*?-lc. Die folgenden Apache-httpd-Konfigurationsanweisungen stellen sicher, dass alle Anforderungen, die diesem Muster entsprechen, mit einer angemessenen Ablaufzeit verarbeitet werden.

Header set Expires "Tue, 20 Jan 2037 04:20:42 GMT" "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header set Cache-Control "public, no-transform, max-age=267840000" "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header unset ETag "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header unset Last-Modified "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header unset Pragma "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"

No Sniff no-sniff

Wenn Inhalte ohne Inhaltstyp gesendet werden, versuchen viele Browser, den Inhaltstyp zu erraten, indem sie die ersten Bytes des Inhalts lesen. Diese Methode wird als „Sniffing“ bezeichnet. Sniffing eröffnet eine Sicherheitslücke, da Benutzer bzw. Benutzerinnen, die in das Repository schreiben können, möglicherweise schädliche Inhalte ohne Inhaltstyp hochladen können.

Daher wird empfohlen, die Kopfzeile no-sniff zu den Ressourcen hinzuzufügen, die vom Dispatcher abgewickelt werden. Allerdings speichert der Dispatcher keine Kopfzeilen im Cache. Daher bedeutet dies, dass jeder Inhalt, der aus dem lokalen Dateisystem bereitgestellt wird, seinen Inhaltstyp durch seine Erweiterung bestimmt, anstatt die ursprüngliche Inhaltstyp-Kopfzeile vom AEM-Ursprungsservers zu verwenden.

Die Option „No sniff“ kann sicher aktiviert werden, wenn bekannt ist, dass die Web-Applikation niemals zwischengespeicherten Ressourcen ohne Dateityp bereitstellt.

Sie können „No sniff“ einschließend aktivieren:

Header set X-Content-Type-Options "nosniff"

Sie kann aber auch selektiv aktiviert werden:

RewriteCond %{REQUEST_URI} \.(?:js|jsonp)$ [OR]
RewriteCond %{QUERY_STRING} (callback|jsonp|cb)=\w+
RewriteRule .* - [E=jsonp_request:1]
Header set X-Content-Type-Options "nosniff"  env=jsonp_request
Header setifempty Content-Type application/javascript env=jsonp_request

Inhaltssicherheitsrichtlinie content-security-policy

Die standardmäßigen Dispatcher-Einstellungen ermöglichen eine offene Inhaltssicherheitsrichtlinie, auch als CSP (Content Security Policy) bezeichnet. Diese Einstellungen ermöglichen es einer Seite, Ressourcen von allen Domains gemäß den Standardrichtlinien der Browser-Sandbox zu laden.

Es ist wünschenswert einzuschränken, von wo Ressourcen geladen werden können, um zu verhindern, dass Code von nicht vertrauenswürdigen oder nicht verifizierten fremden Servern in die JavaScript-Engine geladen wird.

CSP ermöglicht eine Feinabstimmung von Richtlinien. In einer komplexen Anwendung müssen CSP-Header jedoch mit Vorsicht entwickelt werden, da zu restriktive Richtlinien Teile der Benutzeroberfläche beschädigen können.

Dimensionierung sizing

Weitere Informationen zur Dimensionierung finden Sie unter Richtlinien zur Hardware-Dimensionierung.

MongoDB-Leistungsoptimierung mongodb-performance-optimization

Allgemeine Informationen zur MongoDB-Leistung finden Sie unter Analysieren der MongoDB-Leistung.

Bekannte Einschränkungen known-limitations

Gleichzeitige Installationen concurrent-installations

Die gleichzeitige Verwendung mehrerer AEM Instanzen mit einer einzigen Datenbank wird von MongoMK zwar unterstützt, parallele Installationen jedoch nicht.

Um dieses Problem zu umgehen, führen Sie zuerst die Installation mit nur einer Instanz aus und fügen Sie erst nach deren Abschluss weitere hinzu.

Länge des Seitennamens page-name-length

Wenn AEM auf einer MongoMK-Persistenz-Manager-Bereitstellung ausgeführt wird, sind Seitennamen auf 150 Zeichen beschränkt.