Dieser Artikel vermittelt vertiefende Kenntnisse zu Aufgaben und Aspekten, die für eine erfolgreiche Bereitstellung von Adobe Experience Manager mit MongoDB erforderlich sind.
Weitere bereitstellungsbezogene Informationen finden Sie im Abschnitt Bereitstellen und Verwalten der Dokumentation.
MongoDB wird typischerweise zur Unterstützung von AEM-Autorbereitstellungen eingesetzt, die eines der folgenden Kriterien erfüllen:
Die oben genannten Kriterien gelten nur für Autoreninstanzen und nicht für Veröffentlichungsinstanzen, die allesamt TarMK-basiert sein sollten. Die Anzahl der Benutzer bezieht sich auf authentifizierte Benutzer, da Autoreninstanzen ausschließlich 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 dann in Erwägung gezogen werden, wenn sich die Skalierungsanforderungen nicht mit einer einzelnen Hardwarekomponente erfüllen lassen.
Weitere Informationen zur Dimensionierung von Autoreninstanzen und Definition gleichzeitiger Benutzer finden Sie in den Richtlinien zur Hardwaredimensionierung.
Unten ist eine minimale Bereitstellung für AEM auf MongoDB abgebildet. Zur Vereinfachung wurden die SSL-Beendigungs- und HTTP-Proxykomponenten 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 3 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. Damit der Cluster die Last bewältigen kann, wird ein Mindestdurchsatz von 12 MB/s mit mehr als 3.000 IOPS (I/O Operations per Second) empfohlen.
Die AEM-Autoren sind mit den mongod
-Instanzen verbunden, wobei jeweils eine Verbindung zu allen drei mongod
-Instanzen besteht. Schreibvorgänge werden an das primäre Replikat gesendet und Lesevorgänge können von allen Instanzen verarbeitet werden. Der Traffic wird lastabhängig von einem Dispatcher auf eine der aktiven AEM-Autoreninstanzen verteilt. Der Oak-Datenspeicher ist ein FileDataStore
und die MongoDB-Überwachung erfolgt je nach Bereitstellungsort über MMS oder MongoDB Ops Manager. Die Betriebssystemebene und Protokolle können über Drittanbieterlösungen wie Splunk oder Ganglia überwacht werden.
Bei dieser Bereitstellung sind alle Komponenten für eine erfolgreiche Implementierung erforderlich. Fehlt nur eine Komponente, ist die Implementierung nicht funktionsfähig.
Eine Aufstellung der unterstützten Betriebssysteme für AEM 6 finden Sie auf der Seite Technische Anforderungen.
Virtualisierte Umgebungen werden unterstützt, sofern eine gute Kommunikation zwischen den verschiedenen, für das Projekt verantwortlichen technischen Teams vorhanden ist. Hierzu gehören das Team, das für die Ausführung von AEM verantwortlich ist, das Team, das für das Betriebssystem zuständig ist, und das Team, das die virtualisierte Infrastruktur verwaltet.
Es gibt spezifische Anforderungen in Bezug auf die I/O-Kapazität der MongoDB-Instanzen, um die sich das Team, das die virtualisierte Umgebung verwaltet, kümmern muss. Wenn das Projekt auf eine Cloudbereitstellung wie Amazon Web Services zurückgreift, müssen die Instanzen zur Unterstützung der MongoDB-Instanzen mit ausreichend I/O-Kapazität und -Konsistenz bereitgestellt werden. Andernfalls arbeiten die MongoDB-Prozesse und das Oak-Repository unzuverlässig und nicht einwandfrei.
In virtualisierten Umgebungen erfordert MongoDB bestimmte I/O- und VM-Konfigurationen, um sicherzustellen, dass das MongoDB-Speichermodul nicht von den VMware-Richtlinien zur Ressourcenzuweisung gelähmt wird. Eine erfolgreiche Implementierung sorgt dafür, dass es keine Barrieren zwischen den verschiedenen Teams gibt und dass sich alle für das Erreichen der erforderlichen Leistung einsetzen.
Um den Lese- und Schreibdurchsatz für eine optimale Leistung zu erreichen, ohne hierzu auf eine vorzeitige horizontale Skalierung angewiesen zu sein, setzt MongoDB im Allgemeinen SSD-Speicher oder Speicher mit einer SSD-ähnlichen Leistung voraus.
Die MongoDB-Versionen 2.6 und 3.0, die das MMAP-Speichermodul verwenden, erfordern, dass das Workingset der Datenbank und der zugehörigen Indizes zum RAM passt.
Unzureichender RAM führt zu einer deutlichen Leistungsminderung. Die Größe des Workingsets und der Datenbank hängt stark von der Anwendung ab. Zwar sind gewisse Schätzungen möglich, dennoch lässt sich die erforderliche RAM-Menge am zuverlässigsten bestimmen, indem Sie die AEM-Anwendung erstellen und einen Auslastungstest durchführen.
Für den Auslastungstest kann das folgende Verhältnis zwischen Workingset und Gesamtdatengröße angenommen werden:
Dies bedeutet, dass im Falle von SSD-Bereitstellungen für eine 2 TB große Datenbank 200 GB RAM erforderlich sind.
Obwohl dieselben Beschränkungen für das WiredTiger-Speichermodul in MongoDB 3.0 gelten, ist die Korrelation zwischen Workingset, RAM und Seitenfehlern nicht so stark, da das WiredTiger- und das MMAP-Speichermodul Speicherzuordnungen auf unterschiedliche Art und Weise verwenden.
Adobe empfiehlt das WiredTiger-Speichermodul für AEM 6.1-Bereitstellungen mit MongoDB 3.0.
Aufgrund der Beschränkungen des MongoDB-Workingsets 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 dennoch in MongoDB verwaltet wird, sollten die Größe des Datenspeichers zur Datenbankgesamtgröße hinzugerechnet und die Workingset-Berechnungen entsprechend angepasst werden. Dies bedeutet unter Umständen, dass deutlich mehr RAM bereitgestellt werden muss, um eine Leistung ohne Seitenfehler sicherzustellen.
Die Überwachung ist für eine erfolgreiche Implementierung des Projekts von entscheidender Bedeutung. Bei Vorhandensein ausreichender Kenntnisse ist es durchaus möglich, AEM ohne Überwachung auf MongoDB auszuführen. Über diese Kenntnisse verfügen im Normalfall Techniker, die sich auf diesen Bereich der Bereitstellung spezialisiert haben.
Typischerweise werden ein F&E-Techniker, der am Apache Oak-Core arbeitet, sowie ein MongoDB-Spezialist einbezogen.
Ohne Überwachung auf allen Ebenen sind detaillierte Kenntnisse der Codebasis erforderlich, um Probleme diagnostizieren zu können. Sofern eine Überwachung stattfindet und geeignete Anleitungen in Bezug auf die wichtigsten Statistiken erfolgen, sind die Implementierungsteams in der Lage, angemessen auf Anomalien zu reagieren.
Zwar kann mit Befehlszeilentools ein schneller Überblick über die Funktionsweise eines Clusters erlangt werden, aber in Echtzeit und über mehrere Hosts hinweg ist ein solcher Vorgang praktisch unmöglich. Befehlszeilentools liefern nur selten historische Daten, die länger als ein paar Minuten zurückliegen, und erlauben nie eine Korrelation zwischen verschieden 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 ist ein kostenloser Dienst von MongoDB zur Überwachung und Verwaltung von MongoDB-Instanzen. Er bietet eine Echtzeitansicht der Leistung und Integrität von MongoDB-Clustern. Zudem können Sie mit diesem Dienst cloud- und privat gehostete Instanzen verwalten, 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 Agentenebenen:
mongod
-Instanz überwachen kannObwohl sich durch die Verwendung von Cloud Manager zur Wartungsautomatisierung eines MongoDB-Clusters viele der routinemäßigen Aufgaben vereinfachen, müssen Sie den Dienst weder hierfür noch für die Durchführung von Sicherungen einsetzen. 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 entspricht als Software MongoDB Cloud Manager. Im Anschluss an die Registrierung kann Ops Manager heruntergeladen und lokal in einem privaten Datenzentrum oder auf einem beliebigen Laptop oder Desktoprechner installiert werden. Zum Speichern von Daten wird eine lokale MongoDB-Datenbank verwendet; die Kommunikation funktioniert genauso wie zwischen Cloud Manager und verwalteten Servern. Im Falle von Sicherheitsrichtlinien, die die Nutzung eines Überwachungsagenten untersagen, sollten Sie MongoDB Ops Manager verwenden.
Eine Überwachung auf Betriebssystemebene ist erforderlich, um einen AEM-MongoDB-Cluster auszuführen.
Ganglia ist ein gutes Beispiel für ein solches System. Dieses Tool gibt einen Überblick über das Spektrum und die Details der erforderlichen Informationen, die über grundlegende Integritätsmetriken wie CPU, durchschnittliche Auslastung und freier Festplattenspeicher hinausgehen. Zur Problemdiagnose sind Informationen auf geringerer Ebene wie Entropiepool-Level, I/O-Wartezeiten der CPU, Sockets im FIN_WAIT2-Status erforderlich.
Bei einem Cluster mehrerer Server gehört die zentrale Aggregation von Protokollen, auch als Log-Aggregation bezeichnet, zu den Anforderungen eines Produktionssystems. Software wie Splunk unterstützt die Log-Aggregation und ermöglicht es Teams, Verhaltensmuster der Anwendung zu analysieren, ohne Protokolle manuell zu sammeln.
In diesem Abschnitt werden die verschiedenen Schritte behandelt, die Sie ausführen sollten, um sicherzustellen, dass Ihre AEM- und MongoDB-Bereitstellungen ordnungsgemäß eingerichtet sind, bevor Sie ein Projekt implementieren.
Die AEM-Instanzen müssen zum Verwenden von AEM mit MongoMK konfiguriert sein. Die Basis 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.
Es folgt das Beispiel der Konfiguration eines Knotenspeichers „Dokument“ 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 e.g. FileDataStore
customBlobStore=true
cache=2048
blobCacheSize=1024
Dabei gilt:
mongodburi
Der MongoDB-Server, zu dem AEM eine Verbindung herstellen muss. Verbindungen werden zu allen bekannten Mitgliedern der standardmäßigen Replikatgruppe hergestellt. Wenn MongoDB Cloud Manager verwendet wird, ist die Serversicherheit aktiviert. Die Verbindungszeichenfolge muss daher einen geeigneten Benutzernamen und ein passendes Kennwort enthalten. Nicht-Enterprise-Versionen von MongoDB unterstützen ausschließlich die Authentifizierung per Benutzername und Kennwort. Weitere Informationen zur Syntax der Verbindungszeichenfolge finden Sie in der Dokumentation.
db
Der Name der Datenbank. Der Standardwert für AEM lautet
aem-author
.
customBlobStore
Wenn Binärdateien im Zuge der Bereitstellung in der Datenbank gespeichert werden, werden sie Teil des Workingsets. Aus diesem Grund sollten Binärdateien nicht in MongoDB gespeichert werden. Stattdessen werden alternative Datenspeicher empfohlen, z. B. ein
FileSystem
-Datenspeicher in einem NAS.
cache
Die Cachegröße in Megabyte. Dieser Wert ist verteilt über diverse Cache-Speicher im
DocumentNodeStore
. Die Standardgröße ist 256 MB. Allerdings profitiert die Oak-Leseleistung von einem größeren Cache.
blobCacheSize
Häufig verwendete Blobs können von AEM im Cache gespeichert werden. So wird vermieden, dass sie erneut aus dem Datenspeicher abgerufen werden. Dies wirkt sich deutlich auf die Leistung aus, insbesondere beim Speichern von Blobs in der MongoDB-Datenbank. Alle dateisystembasierten Datenspeicher profitieren von einem Datenträgercache auf Betriebssystemebene.
Der Datenspeicher dient zum Speichern von Dateien, die größer sind als der Schwellenwert. Unterhalb dieses Schwellenwerts 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 eine höhere RAM-Menge 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 eine effiziente Verwaltung von Dateien ermöglicht, sollte die Mindestgröße einer Datei auf der Festplatte auf einen Wert eingestellt werden, der der Blockgröße der Festplatte nahekommt. So kann das Dateisystem effizient verwendet werden und das Workingset der mongod
-Instanz wird nicht durch eine große Anzahl kleiner Dokumente übermäßig belastet.
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:
minRecordLength
Größe in Byte. Kleinere oder diesem Wert entsprechende Binärdateien werden im Knotenspeicher „Dokument“ gespeichert. Anstelle der ID des Blobs wird der Inhalt der Binärdatei gespeichert. Bei Binärdateien, die größer sind als dieser Wert, wird die ID der Binärdatei als Eigenschaft des Dokuments in der Knotensammlung gespeichert und der Hauptteil der Binärdatei wird gespeichert im
FileDataStore
auf der Festplatte. 4096 Byte entspricht einer typischen Dateisystem-Blockgröße.
path
Der Pfad zum Stamm des Datenspeichers. Bei einer MongoMK-Bereitstellung muss es sich hier um ein freigegebenes Dateisystem handeln, das für alle AEM-Instanzen verfügbar ist. Normalerweise wird ein Network Attached Storage(NAS)-Server verwendet. Bei Cloud-Implementierungen wie Amazon Web Services ist der
S3DataFileStore
ebenfalls verfügbar.
cacheSizeInMB
Die Gesamtgröße des Binärdatencache in Megabyte. Damit werden Binärdateien im Cache gespeichert, deren Wert unterhalb der
Einstellung maxCacheBinarySize
liegt.
maxCachedBinarySize
Die maximale Größe in Byte der im Binärdatencache gespeicherten Binärdatei. Im Falle eines dateisystembasierten Datenspeichers sollten keine hohen Werten für den Datenspeichercache verwendet werden, da die Binärdateien bereits vom Betriebssystem im Cache gespeichert wurden.
Es wird empfohlen, den mit allen Abfragen gesendeten Abfragehinweis zu deaktivieren, indem Sie die Eigenschaft
-Doak.mongo.disableIndexHint=true
beim AEM-Start hinzufügen. Auf diese Weise führt MongoDB basierend auf internen Statistiken eine Berechnung für den am besten geeigneten Index durch.
Wenn die Abfragehinweise nicht deaktiviert werden, bleibt jedwede AEM-Leistungsoptimierung ohne Wirkung.
Es wird empfohlen, eine Konfiguration mit persistentem Cache für MongoDB-Bereitstellungen zu aktivieren, um die Geschwindigkeit für Umgebungen mit höherer I/O-Leseleitung zu maximieren. Weitere Informationen finden Sie in der Jackrabbit Oak-Dokumentation.
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 hängt davon ab, dass langsame I/O-Vorgänge, häufig auch als Seitenfehler bezeichnet, vermieden oder beseitigt werden. Hierbei handelt es sich um Seitenfehler, die insbesondere den mongod
-Prozess betreffen. Sie sind nicht zu verwechseln mit Seitenfehlern auf Betriebssystemebene.
Für einen schnellen Betrieb sollte die MongoDB-Datenbank nur auf die Daten zugreifen, die bereits im RAM vorhanden sind. Die Daten, auf die die Datenbank zugreifen muss, bestehen aus Indizes und Daten. Diese Sammlung von Indizes und Daten wird als Workingset (oder Arbeitsseiten) bezeichnet. Wenn das Workingset größer ist als der verfügbare RAM, muss MongoDB diese Daten von der Festplatte einlagern (Paging), was zu einer höheren Anzahl von I/O-Operationen führt. Außerdem werden andere bereits im Arbeitsspeicher vorhandene Daten entfernt. Wenn Daten aufgrund dieses Entfernvorgangs erneut von der Festplatte geladen werden müssen, überwiegen Seitenfehler und die Leistung nimmt ab. Bei einem dynamischen und variablen Workingset tritt bei Supportvorgängen eine größere Anzahl von Seitenfehlern auf.
MongoDB ist für diverse Betriebssysteme verfügbar, darunter eine Vielzahl von Linux-Varianten, Windows und Mac OS. Weitere Einzelheiten finden Sie unter https://docs.mongodb.com/manual/installation/#supported-platforms. Für MongoDB bestehen für die verschiedenen Betriebssysteme unterschiedliche Empfehlungen auf Systemebene. Diese sind unter https://docs.mongodb.com/manual/administration/production-checklist-operations/#operating-system-configuration dokumentiert und werden hier lediglich zusammengefasst.
Schalten Sie THP (Transparent Huge Pages) und die Defragmentierung ab. Weitere Informationen finden Sie unter Transparent Huge Pages Settings.
Ändern Sie die Einstellungen für readahead auf den Geräten, auf denen Ihre Datenbankdateien gespeichert werden, damit sie zu Ihren Anforderungen passen.
Deaktivieren Sie das Tool Tuned, wenn Sie RHEL 7/CentOS 7 in einer virtuellen Umgebung ausführen.
Wenn RHEL 7/CentOS 7 in einer virtuellen Umgebung ausgeführt wird, ruft das Tuned-Tool automatisch ein aus dem Leistungsdurchsatz abgeleitetes Leistungsprofil auf, das für die readahead-Einstellungen automatisch 4 MB festlegt. Dies kann sich negativ auf die Leistung auswirken.
Verwenden Sie für SSD-Laufwerke den Noop Scheduler oder den Deadline Scheduler.
Verwenden Sie für virtualisierte Laufwerke in Gast-VMs den Noop Scheduler.
Deaktivieren Sie NUMA oder legen Sie für vm.zone_reclaim_mode „0“ fest und führen Sie mongod-Instanzen mit Node Interleaving aus. Siehe: MongoDB and NUMA Hardware.
Passen Sie die ulimit-Werte Ihrer Hardware für Ihre Anforderungen an. Falls mehrere mongod- oder mongos-Instanzen unter demselben Benutzer ausgeführt werden, erhöhen Sie die ulimit-Werte entsprechend. Siehe: UNIX ulimit Settings.
Verwenden Sie die Option „noatime“ für den Einhängepunkt dbPath.
Konfigurieren Sie für Ihre Umgebung ausreichende Werte für Datei-Handles (fs.file-max), Kernel-PID-Limit (kernel.pid_max) und die maximalen Threads pro Prozess (kernel.threads-max). Für große Systeme bilden die folgenden Werte einen guten Ausgangspunkt:
Stellen Sie sicher, dass für Ihr System der Auslagerungsspeicher konfiguriert ist. Detaillierte Informationen zu den Größenanforderungen finden Sie in der Dokumentation zu Ihrem Betriebssystem.
Stellen Sie sicher, dass der Standardwert des Systems für TCP-Keepalive richtig festgelegt ist. Der Wert „300“ bietet häufig eine bessere Performance für Replikatsätze und freigegebene Cluster. Siehe: Does TCP keepalive time affect MongoDB Deployments? in den häufig gestellten Fragen.
Ab MongoDB 3.2 ist WiredTiger das standardmäßige Speichermodul für MongoDB. Dieses Modul bietet einige robuste und skalierbare Funktionen, durch die es für allgemeine Datenbank-Workloads deutlich besser geeignet ist. Diese Funktionen werden in den folgenden Abschnitten beschrieben.
WiredTiger steuert die Parallelität von Schreibvorgängen auf Dokumentebene. So können mehrere Clients gleichzeitig verschiedene Dokumente einer Sammlung ändern.
Für die meisten Lese- und Schreibvorgänge nutzt WiredTiger vollständige Parallelität. WiredTiger sperrt ausschließlich mit beabsichtigten Sperren auf der globalen, Datenbank- und Sammlungsebene. Wenn das Speichermodul Konflikte zwischen zwei Vorgängen erkennt, kommt es bei einem der Vorgänge zu einem Schreibkonflikt. MongoDB versucht dann, den Vorgang transparent erneut auszuführen. Für einige globale Vorgänge, in der Regel kurzlebige Vorgänge, die mehrere Datenbanken betreffen, ist weiterhin eine globale „instanzenweite“ Sperre erforderlich.
Für einige andere Vorgänge, wie das Löschen einer Sammlung, ist weiterhin eine exklusive Datenbanksperrung erforderlich.
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. Dieser Checkpoint stellt sicher, dass die Datendateien bis einschließlich zum letzten Checkpoint konsistent sind. Checkpoints können daher als Wiederherstellungspunkte genutzt werden.
MongoDB konfiguriert WiredTiger dahingehend, dass Checkpoints (d. h. das Schreiben des Snapshots auf die Festplatte) in Intervallen von 60 Sekunden oder für jeweils 2 Gigabyte Journaldaten erstellt werden.
Während ein neuer Checkpoint geschrieben wird, 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 permanent, sobald die Metadatentabelle von WiredTiger automatisch aktualisiert wurde und auf den neuen Checkpoint verweist. 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.
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, wird das Journal genutzt, um alle seit dem letzten Checkpoint geänderten Daten wiederzugeben. Informationen zur Frequenz, in der MongoDB die Journaldaten auf die Festplatte schreibt, finden Sie unter Journaling Process.
Das WiredTiger-Journal wird mit der Datenkomprimierungsbibliothek snappy komprimiert. Einen anderen Komprimierungsalgorithmus oder keine Komprimierung können Sie mit der Einstellung storage.wiredTiger.engineConfig.journalCompressor festlegen.
Weitere Informationen finden Sie unter Journaling with WiredTiger.
Die minimale Größe der Protokolldatensätze für WiredTiger beläuft sich auf 128 Byte. Wenn ein Protokolldatensatz 128 oder weniger Byte groß ist, führt WiredTiger keine Komprimierung des Datensatzes durch.
Sie können das Journal deaktivieren, indem Sie für storage.journal.enabled „false“ festlegen. So können Sie den Mehraufwand für die Pflege des Journals verringern.
Wenn für Standalone-Instanzen kein Journal verwendet wird, bedeutet dies, dass Sie einige Datenänderungen verlieren, falls MongoDB zwischen Checkpoints unerwartet beendet wird. Für Mitglieder von Replikatsätzen kann der Replikationsprozess gegebenenfalls eine ausreichend garantierte Dauerhaftigkeit sicherstellen.
Mit WiredTiger unterstützt MongoDB eine 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. Einen anderen Komprimierungsalgorithmus oder keine Komprimierung können Sie mit der Einstellung storage.wiredTiger.collectionConfig.blockCompressor festlegen.
Die Präfixkomprimierung für Indizes können Sie mit der Einstellung storage.wiredTiger.indexConfig.prefixCompression deaktivieren.
Komprimierungseinstellungen können auch während des Erstellens einer Sammlung oder eines Index für die jeweilige Sammlung oder den Index konfiguriert werden. Weitere Informationen finden Sie unter Specify Storage Engine Options und im Beitrag zur storageEngine-Option von db.collection.createIndex().
Für die meisten Workloads stellen die standardmäßigen Komprimierungseinstellungen einen Ausgleich zwischen Speichereffizienz und Verarbeitungsanforderungen her.
Auch das WiredTiger-Journal wird standardmäßig komprimiert. Weitere Informationen zur Journalkomprimierung finden Sie unter Journal.
Mit 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 für alle Sammlungen die Snappy-Blockkomprimierung und für alle Indizes die Präfixkomprimierung. 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:
Die in den internen Cache von WiredTiger geladenen Indizes haben eine andere Datendarstellung als das On-Disk-Format, nutzen jedoch weiterhin die Indexpräfixkomprimierung, um die RAM-Verwendung zu reduzieren.
Bei der Indexpräfixkomprimierung werden häufige Präfixe der indizierten Felder dedupliziert.
Sammlungsdaten sind im internen Cache von WiredTiger unkomprimiert und verwenden eine andere Darstellung als das On-Disk-Format. Die Blockkomprimierung kann signifikante On-Disk-Speichereinsparungen bewirken, die Daten müssen jedoch unkomprimiert sein, damit der Server damit arbeiten kann.
Über den Dateisystemcache verwendet MongoDB automatisch den gesamten freien Speicher, der nicht vom WiredTiger-Cache oder von anderen Prozessen verwendet wird.
Informationen zum Anpassen der Größe des internen WiredTiger-Caches finden Sie unter storage.wiredTiger.engineConfig.cacheSizeGB und –wiredTigerCacheSizeGB. Legen Sie für die Größe des internen WiredTiger-Caches möglichst keinen Wert über dem Standardwert fest.
Über NUMA (Non-Uniform Memory Access) kann ein Kernel bestimmen, wie Speicher den Prozessorkernen zugeordnet wird. Obwohl hiermit der Speicherzugriff für Kerne beschleunigt und deren Zugriff auf die erforderlichen Daten sichergestellt werden soll, verursacht NUMA einen MMAP-Konflikt. Wie? Durch die zusätzlich entstehende Latenz, denn Lesevorgänge können nicht vorhergesagt werden. Aus diesem Grund muss NUMA für den mongod
-Prozess auf allen Betriebssystemen mit diesen Funktionen deaktiviert werden.
Kurz gesagt: In einer NUMA-Architektur ist der Speicher mit CPUs verbunden und die CPUs mit einem Bus. In einer SMP- oder UMA-Architektur ist der Speicher mit dem Bus verbunden und wird von den CPUs gemeinsam genutzt. Wenn ein Thread Speicher einer NUMA-CPU zuordnet, geschieht dies gemäß einer Richtlinie. 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 Zuordnung 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, in denen der Rechner als Multicore-Uniform-Speicherarchitektur angesehen wird, führt dies dazu, dass zunächst die anfängliche CPU aufgefüllt wird und später die sekundäre CPU. Dies gilt insbesondere dann, wenn Speicherpuffer über einen zentralen Thread zugeordnet werden. Zur Lösung muss die NUMA-Richtlinie des Haupt-Threads geändert werden, mit dem der mongod
-Prozess gestartet wird.
Dies kann durch Ausführen des folgenden Befehls erreicht werden:
numactl --interleaved=all <mongod> -f config
Diese Richtlinie ordnet Speicher mittels Roundrobin-Methode über alle CPU-Knoten hinweg zu und stellt sicher, dass eine gleichmäßige Verteilung über alle Knoten erfolgt. Sie bietet keinen hochperformanten Speicherzugriff wie Systeme mit mehreren CPU-Hardwarekomponenten. 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.
Wenn der mongod
-Prozess über ein anderes Verzeichnis als /etc/init.d
gestartet wird, ist davon auszugehen, dass der Start nicht mit der richtigen NUMA-Richtlinie erfolgt. 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
.targz) installieren und ausführen, müssen Sie mongod unter dem Prozess numactl
manuell ausführen.
Weitere Informationen zu den verfügbaren NUMA-Richtlinien finden Sie in der numactl-Dokumentation.
Das Verhalten des MongoDB-Prozesses variiert abhängig von der jeweiligen Zuordnungsrichtlinie:
-membind=<nodes>
Die Zuordnung erfolgt nur auf den aufgeführten Knoten. Mongod ordnet keinen Speicher auf aufgeführten Knoten zu und nutzt möglicherweise nicht sämtlichen verfügbaren Speicher.
-cpunodebind=<nodes>
Die Ausführung erfolgt nur auf den Knoten. Mongod wird nur auf den aufgeführten Knoten ausgeführt und nutzt nur den auf diesen Knoten verfügbaren Speicher.
-physcpubind=<nodes>
Die Ausführung erfolgt nur auf den genannten CPUs (Kernen). Mongod wird nur auf den aufgeführten CPUs ausgeführt und nutzt nur den auf diesen CPUs verfügbaren Speicher.
--localalloc
Speicher wird immer auf dem aktuellen Knoten zugewiesen, aber es werden alle Knoten verwendet, auf denen der Thread ausgeführt wird. Wenn ein Thread die Zuordnung ausführt, wird nur der Speicher verwendet, der der CPU zur Verfügung steht.
--preferred=<node>
Zwar wird die Zuordnung zu einem bestimmten Knoten vorgezogen, es wird aber auf einen anderen Knoten zurückgegriffen, wenn der bevorzugte Knoten voll ist. Ein Knoten kann mittels relativer Notation definiert werden. Außerdem werden die Threads auf allen Knoten ausgeführt.
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.
Aufgrund der speicherintensiven Natur von Datenbanken muss das Swapping auf Betriebssystemebene deaktiviert werden. Der MongoDB-Prozess vermeidet Swapping per Design.
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 (Vorauslesen) muss so angepasst werden, dass nicht benötigte Blöcke beim Paging einer Seite im Zusammenhang mit einem zufälligen Lesevorgang nicht von der Festplatte gelesen werden, was zu einem unnötigen Verbrauch von I/O-Brandbreite führt.
2.6.23 für ext4
-Dateisysteme
2.6.25 für xfs
-Dateisysteme
Deaktivieren von „atime“
Es wird empfohlen, atime
für die Festplatten mit den Datenbanken zu deaktivieren.
Festlegen des NOOP-Festplatten-Schedulers
Gehen Sie dazu wie folgt vor:
Überprüfen Sie zuerst, welcher I/O-Scheduler aktuell festgelegt ist. Dies kann durch Ausführen des folgenden Befehls erreicht werden:
cat /sys/block/sdg/queue/scheduler
Erhalten Sie noop
als Antwort, sind keine weiteren Maßnahmen erforderlich.
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 Read-Ahead-Werts
Es wird ein Wert von 32 für die Festplatten empfohlen, von denen MongoDB-Datenbanken ausgeführt werden. Dies entspricht 16 Kilobyte. Sie können den Wert wie folgt festlegen:
sudo blockdev --setra <value> <device>
Stellen Sie sicher, dass NTP auf dem Rechner installiert und aktiv ist, auf dem die MongoDB-Datenbank gehostet wird. 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.
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:
Öffnen Sie die Datei /etc/grub.conf
in einem beliebigen Texteditor.
Fügen Sie der Datei „grub.conf“ die folgende Zeile hinzu:
transparent_hugepage=never
Überprüfen Sie abschließend, ob die Einstellung wirksam geworden ist, indem Sie Folgendes ausführen:
cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
Wenn THP deaktiviert ist, sollte die Ausgabe des oben stehenden Befehls wie folgt sein:
always madvise [never]
Weitere Informationen zu THP finden Sie in diesem Artikel.
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.
Sollte dies nicht der Fall sein, können Sie NUMA prozessweise 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
Linux ermöglicht mit dem Befehl ulimit
eine konfigurierbare Steuerung der Ressourcenzuweisung. Dies kann auf Benutzenden- oder Prozessbasis geschehen.
Sie sollten „ulimit“ für den mongod-Prozess gemäß den MongoDB-empfohlenen ulimit-Einstellungen konfigurieren.
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.
mongoperf
wurde als Indikator für die MongoDB-Leistung auf der Plattform, auf der MongoDB ausgeführt wird, entwickelt. Daher sollten die Ergebnisse nicht als definitiver Wert für die Leistung eines Produktionssystems angesehen werden.
Um genauere Leistungsergebnisse zu erhalten, können Sie ergänzende Tests mit dem Linux-Tool fio
durchführen.
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.
Überprüfen Sie während der Tests die I/O-Nutzungsstatistik für die fraglichen virtuellen Maschinen in Ihrem zur Betriebssystemüberwachung eingesetzten System. Wenn für die I/O-Lesevorgänge ein Testergebnis von unter 100 % ausgegeben wird, liegt womöglich ein Problem bei der virtuellen Maschine vor.
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 und ca. 3.000 IOPS erreichen, bei geringer Variation zwischen der Anzahl der Threads.
Wenn Sie virtualisierte Umgebungen mithilfe von VMware ESX verwalten und bereitstellen, müssen Sie für MongoDB über die ESX-Konsole die folgenden Einstellungen vornehmen:
Deaktivieren Sie Memory-Ballooning.
Führen Sie eine Vorabzuweisung und Reservierung von Speicher für die virtuellen Maschinen durch, die die MongoDB-Datenbanken hosten sollen.
Weisen Sie dem mongod
-Prozess über Storage I/O Control genügend I/O-Kapazität zu.
Garantieren Sie den MongoDB-Hostmaschinen CPU-Ressourcen, indem Sie die Option für die CPU-Reservierung einstellen.
Ziehen Sie die Verwendung von Paravirtual-I/O-Treibern in Betracht. Weitere Informationen dazu finden Sie in diesem Knowledgebase-Artikel.
Informationen zum Einrichten von MongoDB mit Amazon Web Services finden Sie im Artikel Configure AWS Integration (Konfigurieren der AWS-Integration) auf der MongoDB-Website.
Tipps zum Sichern der Datenbankkonfiguration vor der Bereitstellung finden Sie in diesem Blogpost zum Thema Sichere MongoDB-Bereitstellung.
Auf dem Betriebssystem, das den Dispatcher hostet, muss die Apache-HTTPD-Version 2.4 oder höher ausgeführt werden, damit es den Anforderungen der MongoDB-Bereitstellung gerecht wird.
Stellen Sie zudem sicher, dass alle Bibliotheken im Build auf dem aktuellen Stand sind, um Auswirkungen auf die Sicherheit zu minimieren.
Eine typische Dispatcherkonfiguration verarbeitet das 10- bis 20-Fache des Anforderungsdurchsatzes einer AEM-Einzelinstanz.
Da der Dispatcher hauptsächlich ohne Status ist, ist eine horizontale Skalierung problemlos möglich. Bei manchen Bereitstellungen müssen Autoren am Zugriff auf bestimmte Ressourcen gehindert werden. Daher wird ausdrücklich die Verwendung eines Dispatchers bei Autoreninstanzen empfohlen.
Wird AEM ohne Dispatcher ausgeführt, müssen SSL-Beendigung und 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. Hierdurch soll sichergestellt werden, dass Inhaltsaktualisierungen eine minimale Latenz aufweisen.
Weitere Informationen zur entsprechenden Konfiguration finden Sie in der Dispatcherdokumentation.
Sticky-Verbindungen stellen sicher, dass personalisierte Seiten und Sitzungsdaten für einen Benutzer in derselben AEM-Instanz erstellt werden. Diese Daten werden in der Instanz gespeichert, sodass nachfolgende Anforderungen dieses Benutzers auf dieselbe Instanz zurückgreifen.
Es wird empfohlen, Sticky-Verbindungen für alle Inner-Layer-Routinganforderungen an AEM-Instanzen zu aktivieren, damit spätere Anforderungen nach Möglichkeit dieselbe AEM-Instanz erreichen. Hierdurch wird Latenz minimiert, die sich andernfalls zeigt, wenn Inhalt zwischen Instanzen aktualisiert wird.
Standardmäßig besitzt Inhalt, der von einem AEM-Dispatcher gesendet wird, Last-Modified- und ETag-Header, ohne Angabe eines Ablaufzeitpunkts für den Inhalt. Zwar wird auf diese Weise sichergestellt, dass die Benutzeroberfläche immer die neueste Ressourcenversion erhält, allerdings bedeutet dies auch, dass der Browser einen GET-Vorgang durchführt, um zu überprüfen, ob die Ressource geändert wurde. Dies kann zu mehreren Anforderungen führen, auf die abhängig von der Seitenladezeit die HTTP-Antwort 304 (Nicht geändert) erfolgt. Bei Ressourcen, die bekanntermaßen nicht ablaufen, wird durch Festlegen eines Expires-Headers sowie Entfernen der Last-Modified- und ETag-Header der Inhalt im Cache gespeichert. Außerdem werden erst dann wieder weitere Aktualisierungsanforderungen gestellt, wenn das Datum im Expires-Header erfüllt wird.
Wird diese Methode verwendet, steht jedoch keine sinnvolle Möglichkeit zur Verfügung, um ein Ablaufen der Ressource im Browser zu bewirken, bevor der Expires-Header abgelaufen ist. Um diese Situation zu mildern, kann HtmlClientLibraryManager so konfiguriert werden, dass unveränderliche URLs für Clientbibliotheken verwendet werden.
Diese URLs ändern sich auf keinen Fall. Wenn sich der in der URL enthaltene Hauptteil der Ressource ändert, werden diese Änderungen automatisch in der URL widergespiegelt. So ist sichergestellt, dass der Browser die richtige Ressourcenversion anfordert.
Im Rahmen der Standardkonfiguration wird HtmlClientLibraryManager ein Selektor hinzugefügt. Als Selektor wird die Ressource im Cache des Dispatchers mit intaktem Selektor gespeichert. Mit diesem Selektor kann ebenfalls ein korrektes Ablaufverhalten sichergestellt werden. Der Standardselektor folgt dem Muster lc-.*?-lc
. Die folgenden Apache-HTTPD-Konfigurationsrichtlinien stellen sicher, dass alle Anforderungen, die diesem Muster entsprechen, unter Berücksichtigung einer angemessenen Ablaufzeit erledigt 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.*/)"
Wenn Inhalt ohne Inhaltstyp (Content-Type) gesendet wird, versuchen viele Browser, den Inhaltstyp zu erraten, indem die ersten Byte des Inhalts gelesen werden. Dies wird als „Sniffing“ bezeichnet. Sniffing verursacht eine Sicherheitsschwachstelle, da Benutzer, die in das Repository schreiben können, womöglich schädlichen Inhalt ohne Inhaltstyp hochladen.
Daher wird empfohlen, den Header no-sniff
zu den Ressourcen hinzuzufügen, die vom Dispatcher abgewickelt werden. Allerdings speichert der Dispatcher keine Header im Cache. Dies bedeutet, dass der Inhaltstyp von Inhalten des lokalen Dateisystems anhand der Erweiterung ermittelt wird und nicht über den ursprünglichen Content-Type-Header des entsprechenden AEM-Ursprungsservers.
Die Option „nosniff“ kann sicher aktiviert werden, wenn bekannt ist, dass die Webanwendung niemals im Cache gespeicherte Ressourcen ohne Dateityp bereitstellt.
Die Option „nosniff“ kann einschließend aktiviert werden:
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
Die standardmäßigen Dispatchereinstellungen ermöglichen das Öffnen einer Inhaltssicherheitsrichtlinie (Content Security Policy, CSP). Hierdurch kann eine Seite Ressourcen von allen Domains gemäß den Standardrichtlinien der Browser-Sandbox laden.
Das Laden von Ressourcen ist dann einzuschränken, wenn vermieden werden soll, dass in die JavaScript-Engine Code von nicht vertrauenswürdigen oder nicht überprüften Fremdservern geladen wird.
CPS ermöglicht die Feinabstimmung von Richtlinien. In einer komplexen Anwendung müssen die CSP-Header jedoch mit Vorsicht entwickelt werden, da zu strenge Richtlinien die Benutzeroberfläche teilweise beschädigen können.
Weitere Informationen zur Funktionsweise finden Sie auf der OWASP-Seite zum Thema Inhaltssicherheitsrichtlinie.
Weitere Informationen zur Dimensionierung finden Sie in den Richtlinien zur Hardwaredimensionierung.
Allgemeine Informationen zur MongoDB-Leistung finden Sie unter Analysieren der MongoDB-Leistung.
Die gleichzeitige Verwendung mehrerer AEM-Instanzen mit einer Datenbank wird zwar von MongoMK unterstützt, gleichzeitige Installationen allerdings nicht.
Um dieses Problem zu umgehen, führen Sie zuerst die Installation mit nur einer Instanz aus und fügen Sie dann nach deren Abschluss weitere hinzu.
Wenn AEM auf einer MongoMK-Persistenz-Manager-Bereitstellung ausgeführt wird, sind Seitennamen auf 150 Zeichen beschränkt.
Weitere Informationen zu den bekannten Einschränkungen und Schwellenwerten von MongoDB finden Sie in der MongoDB-Dokumentation.