Show Menu
ARGOMENTI×

AEM con MongoDB

Questo articolo mira a migliorare le conoscenze sulle attività e sulle considerazioni necessarie per distribuire correttamente Adobe Experience Manager con MongoDB.
Per ulteriori informazioni sulla distribuzione, consulta la sezione Implementazione e manutenzione della documentazione.

Quando utilizzare MongoDB con AEM

MongoDB viene in genere utilizzato per supportare le distribuzioni di autori AEM in cui è soddisfatto uno dei seguenti criteri:
  • più di 1000 utenti unici al giorno;
  • Più di 100 utenti simultanei;
  • elevati volumi di modifiche di pagina;
  • Rollout o attivazioni di grandi dimensioni.
I criteri indicati sopra sono solo per le istanze di creazione e non per le istanze di pubblicazione basate su TarMK. Il numero di utenti si riferisce agli utenti autenticati, in quanto le istanze di autore non consentono l'accesso non autenticato.
Se i criteri non sono soddisfatti, si consiglia di installare TarMK attivo/in standby per risolvere il problema della disponibilità. In generale, MongoDB dovrebbe essere considerato in situazioni in cui i requisiti di scala sono più di quanto si possa ottenere con un singolo elemento hardware.
Ulteriori informazioni sul ridimensionamento delle istanze dell'autore e sulla definizione degli utenti simultanei sono disponibili nelle Linee guida sul ridimensionamento hardware.

Implementazione MongoDB minima per AEM

Di seguito è riportata una distribuzione minima per AEM su MongoDB. Per semplicità, la terminazione SSL e i componenti proxy HTTP sono stati generalizzati. È costituito da un singolo set di repliche MongoDB, con un elemento primario e due secondari.
Una distribuzione minima richiede 3 mongod istanze configurate come set di replica. Un'istanza verrà selezionata come primaria, mentre le altre istanze saranno secondarie, mentre le elezioni saranno gestite da mongod . Associato a ogni istanza è un disco locale. Affinché il cluster supporti il carico, si consiglia una quantità minima di 12 MB/s con più di 3000 operazioni di I/O al secondo (IOPS).
Gli autori AEM sono connessi alle mongod istanze, con ogni autore di AEM che si collega a tutte e tre mongod le istanze. Le scritture vengono inviate al modulo principale e le letture possono essere lette da una qualsiasi delle istanze. Il traffico viene distribuito in base al caricamento di un dispatcher in una delle istanze di creazione di AEM attive. L'archivio dati OAK è un archivio FileDataStore e il monitoraggio MongoDB è fornito da MMS o da MongoDB Ops Manager a seconda della posizione della distribuzione. Il monitoraggio a livello di sistema operativo e di log è fornito da soluzioni di terze parti come Splunk o Ganglia.
In questa implementazione, tutti i componenti sono necessari per una corretta implementazione. Eventuali componenti mancanti non funzioneranno più.

Sistemi operativi

Per un elenco dei sistemi operativi supportati per AEM 6, consultate la pagina Requisiti tecnici.

Ambienti

Gli ambienti virtualizzati sono supportati a condizione che vi sia una buona comunicazione tra i diversi team tecnici che eseguono il progetto. Questo include il team che esegue AEM, il team proprietario del sistema operativo e il team che gestisce l'infrastruttura virtualizzata.
Esistono requisiti specifici relativi alla capacità di I/O delle istanze MongoDB che devono essere gestiti dal team che gestisce l'ambiente virtualizzato. Se il progetto utilizza una distribuzione cloud, come Amazon Web Services, sarà necessario eseguire il provisioning delle istanze con capacità di I/O e coerenza sufficienti per supportare le istanze MongoDB. In caso contrario, i processi MongoDB e l'archivio Oak saranno eseguiti in modo inaffidabile e irregolare.
Negli ambienti virtualizzati MongoDB richiederà configurazioni di I/O e VM specifiche per garantire che il motore di storage di MongoDB non sia criptato dalle politiche di allocazione delle risorse VMWare. Un'implementazione di successo garantirà che non ci siano barriere tra i vari team e che tutti siano registrati per fornire le prestazioni richieste.

Considerazioni hardware

Archiviazione

Al fine di ottenere il throughput di lettura e scrittura per ottenere prestazioni migliori senza la necessità di scalare in orizzontale prematuro, MongoDB in genere richiede storage o SSD con prestazioni equivalenti a SSD.

RAM

Le versioni 2.6 e 3.0 di MongoDB che utilizzano il motore di storage MMAP richiedono che il set di lavoro del database e i relativi indici si inseriscano nella RAM.
Una quantità insufficiente di RAM ridurrà notevolmente le prestazioni. Le dimensioni del set di lavoro e del database dipendono fortemente dall'applicazione. Sebbene sia possibile effettuare alcune stime, il modo più affidabile per determinare la quantità di RAM richiesta è la creazione dell’applicazione AEM e il test del carico.
Per facilitare il processo di test del carico, si può ipotizzare il seguente rapporto tra il set di lavoro e la dimensione totale del database:
  • 1:10 per lo storage SSD
  • 1:3 per lo storage su disco rigido
Ciò significa che, nel caso delle installazioni SSD, per un database da 2 TB sarà necessario 200 GB di RAM.
Anche se le stesse limitazioni si applicano al motore di storage WiredTiger in MongoDB 3.0, la correlazione tra il set di lavoro, RAM e errori di pagina non è così forte come WiredTiger non utilizza la mappatura della memoria nello stesso modo in cui il motore di storage MMAP.
Adobe consiglia di utilizzare il motore di storage WiredTiger per le distribuzioni AEM 6.1 che utilizzano MongoDB 3.0.

Data Store

A causa delle limitazioni del set di lavoro MongoDB, si consiglia vivamente di mantenere l'archivio dati indipendente da MongoDB. Nella maggior parte degli ambienti è necessario utilizzare un FileDataStore NAS disponibile per tutte le istanze di AEM. Per le situazioni in cui vengono utilizzati i servizi Web Amazon, è disponibile anche un S3 DataStore . Se per qualsiasi motivo l'archivio dati viene mantenuto all'interno di MongoDB, la dimensione del datastore deve essere aggiunta alla dimensione totale del database e i calcoli del set di lavoro devono essere corretti in modo appropriato. Ciò può significare il provisioning di molta più RAM per mantenere le prestazioni senza errori di pagina.

Monitoraggio

Il monitoraggio è essenziale per la riuscita attuazione del progetto. Pur essendo sufficientemente consapevole del fatto che è possibile eseguire AEM su MongoDB senza alcun monitoraggio, tale conoscenza si trova normalmente in tecnici specializzati per ciascuna sezione della distribuzione.
Questo richiede in genere un ingegnere R&S che lavora su Apache Oak Core e uno specialista MongoDB.
Senza monitoraggio a tutti i livelli, per diagnosticare i problemi sarà necessario conoscere in modo dettagliato la base di codice. Grazie al monitoraggio e all'adeguata guida sulle principali statistiche, i team di implementazione saranno in grado di reagire adeguatamente alle anomalie.
Anche se è possibile utilizzare gli strumenti della riga di comando per ottenere una rapida istantanea del funzionamento di un cluster, farlo in tempo reale su molti host è quasi impossibile. Gli strumenti della riga di comando forniscono raramente informazioni storiche oltre pochi minuti e non consentono mai la correlazione tra diversi tipi di metriche. Un breve periodo di mongod sincronizzazione in background lenta richiede un notevole sforzo manuale per correlarsi a I/O Wait o a livelli di scrittura eccessivi a una risorsa di memorizzazione condivisa da una macchina virtuale apparentemente non connessa.

MongoDB Cloud Manager

MongoDB Cloud Manager è un servizio gratuito offerto da MongoDB che consente il monitoraggio e la gestione delle istanze MongoDB. Fornisce una visualizzazione delle prestazioni e dello stato del cluster MongoDB in tempo reale. Gestisce sia le istanze cloud che quelle ospitate privatamente, a condizione che l'istanza raggiunga il server di monitoraggio di Cloud Manager.
Richiede un agente installato nell'istanza MongoDB che si connette al server di monitoraggio. Esistono 3 livelli di agente:
  • Un agente di automazione in grado di automatizzare completamente tutto sul server MongoDB,
  • Un agente di monitoraggio in grado di monitorare l' mongod istanza,
  • Agente di backup in grado di eseguire backup pianificati dei dati.
Anche se l'utilizzo di Cloud Manager per l'automazione della manutenzione di un cluster MongoDB semplifica molte delle attività di routine, non è richiesto e non lo è nemmeno per il backup. Quando si sceglie Cloud Manager per il monitoraggio, il monitoraggio è comunque necessario.
Per ulteriori informazioni su MongoDB Cloud Manager, consulta la documentazione MongoDB.

Gestione opzioni MongoDB

MongoDB Ops Manager è lo stesso software di MongoDB Cloud Manager. Una volta registrato, Ops Manager può essere scaricato e installato localmente in un centro dati privato o su qualsiasi altro computer portatile o desktop. Utilizza un database MongoDB locale per memorizzare i dati e comunicare esattamente come Cloud Manager con i server gestiti. Se si dispone di criteri di sicurezza che vietano l'utilizzo di un agente di monitoraggio, è necessario utilizzare Gestione opzioni MongoDB.

Monitoraggio del sistema operativo

Per eseguire un cluster AEM MongoDB è necessario il monitoraggio a livello di sistema operativo.
Ganglia è un buon esempio di tale sistema e fornisce un'immagine sulla gamma e il dettaglio delle informazioni necessarie che va oltre le metriche di salute di base come CPU, media del carico e spazio libero su disco. Per diagnosticare i problemi, sono necessarie informazioni di livello inferiore come i livelli del pool di entropia, l'attesa I/O della CPU, i socket nello stato FIN_WAIT2.

Aggregazione log

Con un cluster di più server, l'aggregazione centrale del registro è un requisito per un sistema di produzione. Software come Splunk supporta l'aggregazione dei log e consente ai team di analizzare i pattern di comportamento dell'applicazione senza dover raccogliere manualmente i log.

Elenchi di controllo

Questa sezione descrive i vari passaggi da seguire per garantire che le distribuzioni AEM e MongoDB siano configurate correttamente prima di implementare il progetto.

Rete

  1. Innanzitutto, accertatevi che tutti gli host dispongano di una voce DNS
  2. Tutti gli host devono essere risolvibili dalla voce DNS di tutti gli altri host router
  3. Tutti gli host MongoDB sono eseguibili in modo instradabile da tutti gli altri host MongoDB nello stesso cluster
  4. Gli host MongoDB possono indirizzare i pacchetti a MongoDB Cloud Manager e agli altri server di monitoraggio
  5. I server AEM possono indirizzare i pacchetti a tutti i server MongoDB
  6. La latenza del pacchetto tra qualsiasi server AEM e qualsiasi server MongoDB è inferiore a due millisecondi, senza perdita di pacchetti e con una distribuzione standard di almeno un millisecondo.
  7. Assicurati che tra un server AEM e un server MongoDB non siano presenti più di due hop
  8. Non ci sono più di due hop tra due server MongoDB
  9. Non esistono router superiori a OSI di livello 3 tra i server core (MongoDB, AEM o qualsiasi combinazione).
  10. Se viene utilizzato il trunking VLAN o qualsiasi altro tipo di tunneling di rete, deve essere conforme ai controlli di latenza del pacchetto.

Configurazione AEM

Configurazione archivio nodi

Le istanze AEM devono essere configurate per l’utilizzo di AEM con MongoMK. La base dell’implementazione MongoMK in AEM è Document Node Store.
Per ulteriori informazioni sulla configurazione degli archivi di nodi, consulta Configurazione di store di nodi e di archivi dati in AEM .
Di seguito è riportato un esempio di configurazione Document Node Store per una distribuzione MongoDB minima:
# 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

Dove:
  • mongodburi Server MongoDB a cui AEM deve connettersi. Vengono effettuate connessioni a tutti i membri noti del set di repliche predefinito. Se viene utilizzato MongoDB Cloud Manager, la protezione del server è abilitata. Di conseguenza, la stringa di connessione deve contenere un nome utente e una password appropriati. Le versioni non aziendali di MongoDB supportano solo l'autenticazione tramite nome utente e password. Per ulteriori informazioni sulla sintassi della stringa di connessione, consultare la documentazione .
  • db Nome del database. Il valore predefinito per AEM è aem-author .
  • customBlobStore Se la distribuzione memorizza i binari nel database, questi faranno parte del set di lavoro. Per questo motivo si consiglia di non memorizzare i file binari all'interno di MongoDB, eseguendo un datastore alternativo come un FileSystem datastore su un NAS.
  • cache Dimensione della cache in MB. Questo viene distribuito tra diverse cache utilizzate nel DocumentNodeStore . Il valore predefinito è 256 MB. Tuttavia, le prestazioni di lettura Oak trarranno vantaggio da una cache più grande.
  • blobCacheSize I BLOB utilizzati di frequente possono essere memorizzati nella cache da AEM per evitare che vengano recuperati dall’archivio dati. Questo avrà un impatto maggiore sulle prestazioni, soprattutto quando si memorizzano i BLOB nel database MongoDB. Tutti gli archivi dati basati su file system trarranno vantaggio dalla cache del disco a livello di sistema operativo.

Configurazione archivio dati

L'archivio dati viene utilizzato per archiviare file di dimensioni superiori a una soglia. Al di sotto di tale soglia, i file vengono memorizzati come proprietà nell'archivio dei nodi del documento. Se MongoBlobStore viene utilizzato, viene creata una raccolta dedicata in MongoDB per memorizzare i BLOB. Questa raccolta contribuisce al set di lavoro dell' mongod istanza e richiederà mongod una quantità maggiore di RAM per evitare problemi di prestazioni. Per questo motivo, la configurazione consigliata è quella di evitare l'utilizzo MongoBlobStore per le distribuzioni di produzione e l'utilizzo del FileDataStore backup su un NAS condiviso tra tutte le istanze di AEM. Poiché la cache a livello di sistema operativo è efficiente nella gestione dei file, la dimensione minima di un file su disco deve essere impostata in modo da avvicinare la dimensione del blocco del disco in modo che il file system sia utilizzato in modo efficiente e molti piccoli documenti non contribuiscono eccessivamente al set di lavoro dell' mongod istanza.
Di seguito è riportata una tipica configurazione dell'archivio dati per una distribuzione AEM minima con 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

Dove:
  • minRecordLength Dimensioni in byte. I file binari di dimensioni inferiori o uguali a queste vengono memorizzati nell'archivio dei nodi del documento. Invece di memorizzare l'ID del BLOB, viene memorizzato il contenuto del file binario. Per i file binari di dimensioni maggiori di queste, l'ID del binario viene memorizzato come proprietà del documento nell'insieme di nodi e il corpo del binario viene memorizzato nel FileDataStore disco. 4096 byte è una dimensione di blocco tipica del file system.
  • path Percorso della directory principale dell'archivio dati. Per una distribuzione MongoMK, questo deve essere un file system condiviso disponibile per tutte le istanze AEM. In genere viene utilizzato un server NAS (Network Attached Storage). Per distribuzioni cloud come Amazon Web Services, S3DataFileStore è disponibile anche.
  • cacheSizeInMB La dimensione totale della cache binaria in Megabyte. Viene utilizzato per memorizzare nella cache i file binari in un valore inferiore all’ maxCacheBinarySize impostazione.
  • maxCachedBinarySize La dimensione massima in byte di un binario memorizzato nella cache binaria. Se si utilizza un archivio dati basato su file system, si consiglia di non utilizzare valori elevati per la cache dell'archivio dati in quanto i file binari sono già memorizzati nella cache dal sistema operativo.

Disattivazione del suggerimento query

Si consiglia di disabilitare il suggerimento query inviato con tutte le query aggiungendo la proprietà
-Doak.mongo.disableIndexHint=true
all’avvio di AEM. In questo modo, MongoDB calcolerà sull'indice più appropriato da utilizzare sulla base di statistiche interne.
Se l'hint di query non è disabilitato, qualsiasi ottimizzazione delle prestazioni degli indici non avrà alcun impatto sulle prestazioni di AEM.

Abilita cache persistente per MongoMK

Si consiglia di abilitare una configurazione cache persistente per le distribuzioni MongoDB, al fine di massimizzare la velocità per gli ambienti con elevate prestazioni di lettura I/O. Per ulteriori dettagli, consulta la documentazione di Jackrabbit Oak.

Ottimizzazioni del sistema operativo MongoDB

Supporto del sistema operativo

MongoDB 2.6 utilizza un motore di storage mappato sulla memoria che è sensibile ad alcuni aspetti della gestione a livello di sistema operativo tra RAM e disco. Le prestazioni di query e lettura dell'istanza MongoDB si basano sull'eliminazione o l'eliminazione di operazioni di I/O lente, spesso denominate errori di pagina. Si tratta di errori di pagina che si applicano in particolare al mongod processo. Non devono essere confusi con errori di pagina a livello di sistema operativo.
Per un funzionamento veloce, il database MongoDB dovrebbe accedere solo ai dati già presenti nella RAM. I dati a cui deve accedere sono costituiti da indici e dati. Questa raccolta di indici e dati è denominata set di lavoro. Se il set di lavoro è più grande della RAM disponibile MongoDB deve inserire i dati da un disco con un costo di I/O, eliminando altri dati già in memoria. Se lo sfratto causa il ricaricamento dei dati da guasti della pagina del disco, le prestazioni risulteranno compromesse. Se il set di lavoro è dinamico e variabile, per supportare le operazioni vengono generati più errori di pagina.
MongoDB viene eseguito su un certo numero di sistemi operativi, tra cui un'ampia varietà di versioni Linux, Windows e Mac OS. Per ulteriori dettagli, consultate https://docs.mongodb.com/manual/installation/#supported-platforms . A seconda della scelta del sistema operativo, MongoDB ha raccomandazioni a livello di sistema operativo diverse. Sono documentati all'indirizzo https://docs.mongodb.com/manual/administration/production-checklist-operations/#operating-system-configuration e qui riassunti per comodità.

Linux

  • Disattivare gli hugepage trasparenti e sganciare. Per ulteriori informazioni, consulta Impostazioni per pagine grandi trasparenti.
  • Regolare le impostazioni readahead sui dispositivi in cui sono memorizzati i file del database in base alle esigenze.
    • Per il motore di memorizzazione MMAPv1, se il set di lavoro è più grande della RAM disponibile e il pattern di accesso al documento è casuale, è consigliabile abbassare il valore di lettura a 32 o 16. Valutare diverse impostazioni per trovare un valore ottimale che massimizzi la memoria residente e riduca il numero di errori di pagina.
    • Per il motore di storage WiredTiger, impostare readahead su 0, indipendentemente dal tipo di supporto di storage (filatura, SSD, ecc.). In generale, utilizzare l'impostazione di lettura consigliata a meno che i test non mostrino un vantaggio misurabile, ripetibile e affidabile con un valore di lettura superiore. Il supporto Professional di MongoDB può fornire consigli e indicazioni sulle configurazioni di lettura diverse da zero.
  • Se in un ambiente virtuale è in esecuzione RHEL 7/CentOS 7, disattivate lo strumento sintonizzato.
  • Quando RHEL 7 / CentOS 7 viene eseguito in un ambiente virtuale, lo strumento sintonizzato richiama automaticamente un profilo di prestazioni derivato dal throughput delle prestazioni, che imposta automaticamente le impostazioni di lettura a 4 MB. Ciò può avere un impatto negativo sulle prestazioni.
  • Utilizzare i programmi di pianificazione dei dischi noop o di scadenza per le unità SSD.
  • Utilizzare il pianificatore di dischi noop per le unità virtualizzate nelle VM guest.
  • Disattiva NUMA o imposta vm.zone_reclamate_mode su 0 ed esegui le istanze mondodio con l'interfoliazione dei nodi. Vedere: Per ulteriori informazioni, MongoDB e NUMA Hardware .
  • Regolare i valori limite sull'hardware in base alle esigenze d'uso. Se più istanze mondodio o mongos sono in esecuzione sotto lo stesso utente, ridimensionate i valori di limite di conseguenza. Vedere: Impostazioni di UNIX per ulteriori informazioni.
  • Utilizzare il tempo di attesa per il punto di montaggio dbPath .
  • Configurate handle di file sufficienti (fs.file-max), limite di kernel pid (kernel.pid_max) e massimo di thread per processo (kernel.thread-max) per la distribuzione. Per i sistemi di grandi dimensioni, i seguenti valori forniscono un buon punto di partenza:
    • fs.file-max valore di 98000,
    • kernel.pid_max valore di 64000,
    • andkernel.thread-max valore di 64000
  • Verificare che nel sistema sia configurato lo spazio di scambio. Per informazioni sul ridimensionamento appropriato, consultate la documentazione del sistema operativo in uso.
  • Verificare che il server TCP predefinito del sistema sia impostato correttamente. Un valore di 300 offre spesso prestazioni migliori per i set di repliche e i cluster condivisi. Vedere: Il tempo di conservazione TCP influisce sulle implementazioni MongoDB? per ulteriori informazioni, consulta le Domande frequenti.

Windows

  • Considerate la possibilità di disattivare gli aggiornamenti NTFS dell'"ultima ora di accesso". Questo è analogo alla disattivazione del tempo su sistemi simili a Unix.

WiredTiger

A partire da MongoDB 3.2 il motore di storage predefinito per MongoDB è il motore di storage WiredTiger. Questo motore fornisce una serie di funzioni robuste e scalabili che lo rendono molto più adatto per tutti i carichi di lavoro generali del database. Le sezioni seguenti descrivono queste funzioni.

Condivisa a livello di documento

WiredTiger utilizza il controllo della concorrenza a livello di documento per le operazioni di scrittura. Di conseguenza, più client possono modificare allo stesso tempo diversi documenti di una raccolta.
Per la maggior parte delle operazioni di lettura e scrittura, WiredTiger utilizza un controllo della concorrenza ottimistico. WiredTiger utilizza solo i blocchi di intento a livello globale, di database e di raccolta. Quando il motore di storage rileva i conflitti tra due operazioni, si verificherà un conflitto in scrittura che causerebbe un nuovo tentativo in modo trasparente da parte di MongoDB.Alcune operazioni globali, in genere di breve durata che coinvolgono più database, richiedono ancora un blocco globale "a livello di istanza".
Alcune altre operazioni, come il rilascio di una raccolta, richiedono ancora un blocco esclusivo del database.

Snapshot e checkpoint

WiredTiger utilizza MultiVersion Concurrency Control (MVCC). All’inizio di un’operazione, WiredTiger fornisce uno snapshot point-in-time dei dati alla transazione. Un'istantanea presenta una visualizzazione coerente dei dati presenti nella memoria.
Durante la scrittura su disco, WiredTiger scrive su disco tutti i dati di un'istantanea in modo coerente in tutti i file di dati. I dati ora durevoli fungono da punto di controllo nei file di dati. Il punto di controllo assicura che i file di dati siano coerenti fino all'ultimo punto di controllo incluso; i checkpoint possono quindi fungere da punti di ripristino.
MongoDB configura WiredTiger per la creazione di checkpoint (ovvero per la scrittura dei dati dello snapshot su disco) a intervalli di 60 secondi o 2 gigabyte di dati del giornale.
Durante la scrittura di un nuovo checkpoint, il checkpoint precedente è ancora valido. Di conseguenza, anche se MongoDB termina o rileva un errore durante la scrittura di un nuovo checkpoint, al riavvio MongoDB può recuperare dall'ultimo checkpoint valido.
Il nuovo punto di controllo diventa accessibile e permanente quando la tabella di metadati di WiredTiger viene aggiornata in modo atomico per fare riferimento al nuovo punto di controllo. Una volta accessibile il nuovo checkpoint, WiredTiger libera le pagine dai vecchi checkpoint.
Utilizzando WiredTiger, anche senza la registrazione , MongoDB può recuperare dall'ultimo checkpoint; tuttavia, per recuperare le modifiche apportate dopo l'ultimo checkpoint, eseguire con journal .

Diario

WiredTiger utilizza un log delle transazioni di scrittura in combinazione con checkpoint per garantire la durata dei dati.
Il giornale WiredTiger persiste tutte le modifiche ai dati tra i checkpoint. Se MongoDB esce tra i checkpoint, utilizza il giornale di registrazione per riprodurre tutti i dati modificati dall'ultimo checkpoint. Per informazioni sulla frequenza con cui MongoDB scrive i dati del giornale su disco, vedere Processo di registrazione.
Il giornale di registrazione WiredTiger viene compresso utilizzando la libreria di compressione snapshot . Per specificare un algoritmo di compressione alternativo o nessuna compressione, utilizzare l'impostazione storage.wiredTiger.EngineConfig.journalCompressor .
Per ulteriori informazioni, vedi: Viaggio con WiredTiger .
La dimensione minima del record del registro per WiredTiger è di 128 byte. Se un record di registro è di almeno 128 byte, WiredTiger non comprime tale record.
È possibile disattivare la registrazione impostando storage.journal.enabled su false, che può ridurre il sovraccarico di manutenzione della scrittura contabile.
Per le istanze standalone , non utilizzare il journal significa che si perderanno alcune modifiche di dati quando MongoDB esce inaspettatamente tra i checkpoint. Per i membri dei set di replica, il processo di replica potrebbe fornire sufficienti garanzie di durata.

Compressione

Con WiredTiger, MongoDB supporta la compressione per tutte le raccolte e gli indici. La compressione riduce al minimo l'utilizzo dello storage a spese della CPU aggiuntiva.
Per impostazione predefinita, WiredTiger utilizza la compressione dei blocchi con la libreria di compressione snapshot per tutte le raccolte e la compressione dei prefisso per tutti gli indici.
Per le raccolte, è disponibile anche la compressione blocco con zlib . Per specificare un algoritmo di compressione alternativo o nessuna compressione, utilizzare l'impostazione storage.wiredTiger.collectionConfig.blockCompressor .
Per gli indici, per disabilitare la compressione #term-prefix-compressiondel prefisso, utilizzate l’impostazione storage.wiredTiger.indexConfig.prefixCompression .
Le impostazioni di compressione sono configurabili anche per ogni raccolta e per indice durante la creazione di raccolte e indici. Consultate Specificare le opzioni del motore di memorizzazione e l'opzione db.collection.createIndex() storageEngine .
Per la maggior parte dei carichi di lavoro, le impostazioni di compressione predefinite bilanciano l'efficienza dello storage e i requisiti di elaborazione.
Anche il giornale di registrazione WiredTiger è compresso per impostazione predefinita. Per informazioni sulla compressione delle scritture contabili, vedere Scritture contabili .

Utilizzo memoria

Con WiredTiger, MongoDB utilizza sia la cache interna WiredTiger che la cache del file system.
A partire dalla versione 3.4, la cache interna WiredTiger, per impostazione predefinita, utilizza la dimensione maggiore di:
  • 50% di RAM meno 1 GB, o
  • 256 MB
Per impostazione predefinita, WiredTiger utilizza la compressione Snappy block per tutte le raccolte e la compressione del prefisso per tutti gli indici. I valori predefiniti di compressione sono configurabili a livello globale e possono essere impostati anche a livello di raccolta e indice durante la creazione di raccolte e indici.
Diverse rappresentazioni vengono utilizzate per i dati nella cache interna WiredTiger rispetto al formato su disco:
  • I dati nella cache del file system sono gli stessi del formato su disco, inclusi i vantaggi di qualsiasi compressione per i file di dati. La cache del file system viene utilizzata dal sistema operativo per ridurre l'I/O del disco.
Gli indici caricati nella cache interna di WiredTiger presentano una rappresentazione dati diversa rispetto al formato su disco, ma possono comunque sfruttare la compressione dei prefisso indice per ridurre l'utilizzo della RAM.
La compressione del prefisso dell'indice deduplica i prefissi comuni dai campi indicizzati.
I dati della raccolta nella cache interna di WiredTiger non sono compressi e utilizzano una rappresentazione diversa dal formato su disco. La compressione a blocchi consente di risparmiare notevolmente sullo storage su disco, ma i dati devono essere non compressi per essere manipolati dal server.
Tramite la cache del file system, MongoDB utilizza automaticamente tutta la memoria libera non utilizzata dalla cache WiredTiger o da altri processi.
Per regolare la dimensione della cache interna WiredTiger, vedi storage.wiredTiger.EngineConfig.cacheSizeGB e —wiredTigerCacheSizeGB . Evitare di aumentare la dimensione della cache interna WiredTiger al di sopra del valore predefinito.

NUMA

Accesso alla memoria non uniforme (NUMA) consente a un kernel di gestire la mappatura della memoria ai core del processore. Anche se questo tenta di rendere l'accesso alla memoria più veloce per i core garantendo che siano in grado di accedere ai dati richiesti, NUMA interferisce con MMAP introducendo una latenza aggiuntiva, in quanto le letture non possono essere previste. Per questo motivo, NUMA deve essere disabilitato per il mongod processo su tutti i sistemi operativi che hanno la capacità.
In sostanza, in un'architettura NUMA la memoria è collegata alle CPU e le CPU sono collegate a un bus. In un'architettura SMP o UMA, la memoria è collegata al bus e condivisa dalle CPU. Quando un thread alloca memoria su una CPU NUMA, lo assegna in base a un criterio. L'impostazione predefinita prevede l'allocazione di memoria collegata alla CPU locale del thread, a meno che non sia disponibile alcuna connessione, e a questo punto utilizza la memoria di una CPU gratuita a costi più elevati. Una volta allocata, la memoria non si sposta tra le CPU. L'allocazione viene eseguita da un criterio ereditato dal thread padre, che in definitiva è il thread che ha avviato il processo.
In molti database che vedono la macchina come un'architettura di memoria uniforme multi-core, questo porta alla CPU iniziale ottenere pieno prima e il riempimento della CPU secondaria più tardi, soprattutto se un thread centrale è responsabile per l'allocazione dei buffer di memoria. La soluzione consiste nel modificare il criterio NUMA del thread principale utilizzato per avviare il mongod processo.
Questa operazione può essere eseguita eseguendo il comando seguente:
numactl --interleaved=all <mongod> -f config

Questo criterio consente di allocare la memoria in un round robin su tutti i nodi della CPU, garantendo una distribuzione uniforme su tutti i nodi. Non genera l'accesso alla memoria con le prestazioni più elevate, come nei sistemi con più hardware CPU. Circa la metà delle operazioni di memoria sarà più lenta e oltre il bus, ma non mongod è stato scritto per raggiungere NUMA in modo ottimale, quindi è un compromesso ragionevole.

Problemi NUMA

Se il mongod processo viene avviato da un percorso diverso dalla /etc/init.d cartella, è probabile che non verrà avviato con il criterio NUMA corretto. A seconda del criterio predefinito, possono sorgere problemi. Questo perché i vari programmi di installazione di Linux Package Manager per MongoDB installano anche un servizio con file di configurazione che si trovano in /etc/init.d cui vengono eseguiti i passaggi descritti in precedenza. Se si installa ed esegue MongoDB direttamente da un archivio ( .tar.gz ), sarà necessario eseguire manualmente mondio nel numactl processo.
Per ulteriori informazioni sui criteri NUMA disponibili, consulta la documentazione numactlnumerica.
Il processo MongoDB si comporterà in modo diverso in base ai diversi criteri di allocazione:
  • -membind=<nodes> Allocate solo sui nodi elencati. Mondio non allocerà memoria sui nodi elencati e potrebbe non utilizzare tutta la memoria disponibile.
  • -cpunodebind=<nodes> Viene eseguito solo sui nodi. Mondio verrà eseguito solo sui nodi specificati e utilizzerà solo la memoria disponibile su tali nodi.
  • -physcpubind=<nodes> Vengono eseguite solo su CPU (core) elencate. Mondio verrà eseguito solo sulle CPU elencate e utilizzerà solo la memoria disponibile su tali CPU.
  • --localalloc allocare sempre memoria sul nodo corrente, ma utilizzare tutti i nodi su cui viene eseguito il thread. Se un thread esegue l'allocazione, verrà utilizzata solo la memoria disponibile per tale CPU.
  • --preferred=<node> Preferisce l'allocazione a un nodo, ma torna ad altri se il nodo preferito è pieno. È possibile utilizzare una notazione relativa per definire un nodo. Inoltre, i thread vengono eseguiti su tutti i nodi.
Alcuni dei criteri possono comportare che al mongod processo venga assegnata meno di tutta la RAM disponibile. A differenza di MySQL, MongoDB evita attivamente il paging a livello di sistema operativo, e di conseguenza il mongod processo potrebbe ottenere meno memoria disponibile.

Scambio

A causa della natura intensiva di memoria dei database, lo scambio a livello di sistema operativo deve essere disattivato. Il processo MongoDB eviterà lo scambio per progettazione.

File system remoti

File system remoti come NFS non sono consigliati per i file di dati interni di MongoDB (i file di database di processo di mondio), perché introducono troppa latenza. Questo non deve essere confuso con il file system condiviso richiesto per l'archiviazione di Oak Blob (FileDataStore), dove si consiglia NFS.

Leggi

La lettura deve essere regolata in modo che quando una pagina viene inserita in una pagina utilizzando una lettura casuale, i blocchi non necessari non vengono letti dal disco, con conseguente consumo non necessario di larghezza di banda I/O.

Requisiti Linux

Versioni minime del kernel

  • 2.6.23 per i ext4 file system
  • 2.6.25 per i xfs file system

Abilita NTP

Verificare che nel computer in cui sono installati i database MongoDB sia installato e in esecuzione NTP. Ad esempio, potete installarlo utilizzando il gestore yum del pacchetto su un computer CentOS:
sudo yum install ntp

Dopo che il demone NTP è stato installato e ha avuto esito positivo, è possibile controllare il file di deriva per l'offset temporale del server.

Disattiva pagine grandi trasparenti

Red Hat Linux utilizza un algoritmo di gestione della memoria denominato Transparent Huge Pages (THP). Si consiglia di disattivarlo se si utilizza il sistema operativo per i carichi di lavoro del database.
Potete disattivarlo seguendo la procedura seguente:
  1. Aprite il /etc/grub.conf file nell’editor di testo desiderato.
  2. Aggiungete la riga seguente al file grub.conf:
    transparent_hugepage=never
    
    
  3. Infine, verificare se l'impostazione ha avuto effetto eseguendo:
    cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
    
    
    Se THP è disattivato, l'output del comando precedente deve essere:
    always madvise [never]
    
    
Per ulteriori informazioni su Pagine grandi trasparenti, consulta questo articolo .

Disattiva NUMA

Nella maggior parte delle installazioni in cui è attivato NUMA, il demone MongoDB lo disattiverà automaticamente se viene eseguito come servizio dalla /etc/init.d cartella.
In caso contrario, è possibile disabilitare NUMA a livello di processo. Per disattivarlo, eseguite i seguenti comandi:
numactl --interleave=all <path_to_process>

Dov <path_to_process> 'è il cammino verso il processo mondodio.
Quindi disattivate il recupero della zona eseguendo:
echo 0 > /proc/sys/vm/zone_reclaim_mode

Regolare le impostazioni dell'icona per il processo di mondio

Linux consente il controllo configurabile sull'allocazione delle risorse tramite il ulimit comando. Questa operazione può essere eseguita su un utente o su base di processo.
Si consiglia di configurare il limite minimo per il processo di mondio in base alle impostazioni di errore consigliate di MongoDB.

Test prestazioni I/O MongoDB

MongoDB fornisce uno strumento denominato mongoperf che è progettato per testare le prestazioni di I/O. Si consiglia di utilizzarlo per testare le prestazioni di tutte le istanze MongoDB che costituiscono l'infrastruttura.
Per informazioni su come utilizzare mongoperf , consulta la documentazione MongoDB.
Si noti che mongoperf è progettato per essere un indicatore delle prestazioni MongoDB sulla piattaforma su cui viene eseguito. Per questo motivo, i risultati non devono essere considerati definitivi per l'esecuzione di un sistema di produzione.
Per risultati di prestazioni più precisi, è possibile eseguire test complementari con lo strumento fio Linux.
Verificare le prestazioni di lettura sulle macchine virtuali che compongono la distribuzione
Dopo aver installato lo strumento, passate alla directory del database MongoDB per eseguire i test. Quindi, avviate il primo test eseguendo mongoperf la configurazione seguente:
echo "{nThreads:32,fileSizeMB:1000,r:true}" | mongoperf

L'output desiderato dovrebbe raggiungere fino a due gigabyte al secondo (2 GB/s) e 500.000 IOPS in esecuzione a 32 thread per tutte le istanze MongoDB.
Eseguite un secondo test, questa volta utilizzando file mappati sulla memoria, impostando il mmf:true parametro:
echo "{nThreads:32,fileSizeMB:1000,r:true,mmf:true}" | mongoperf

L'output del secondo test dovrebbe essere notevolmente superiore al primo, indicando le prestazioni di trasferimento della memoria.
Durante l'esecuzione dei test, controllare le statistiche sull'uso dell'I/O per le macchine virtuali in questione nel sistema di monitoraggio del sistema operativo in uso. Se indicano valori inferiori al 100% per le letture di I/O, potrebbe verificarsi un problema con la macchina virtuale.
Verificare le prestazioni di scrittura dell'istanza MongoDB primaria
Quindi, controllare le prestazioni di scrittura I/O dell'istanza MongoDB primaria eseguendo mongoperf dalla directory del database MongoDB con le stesse impostazioni:
echo "{nThreads:32,fileSizeMB:1000,w:true}" | mongoperf

L'output desiderato dovrebbe essere di 12 megabyte al secondo e raggiungere circa 3000 IOPS, con lieve variazione tra il numero di thread.

Passaggi per ambienti virtualizzati

VMWare

Se si utilizza WMWare ESX per gestire e implementare gli ambienti virtualizzati, assicurarsi di eseguire le seguenti impostazioni dalla console ESX per poter disporre del funzionamento MongoDB:
  1. Disattivazione del bilanciamento della memoria
  2. Preallocare e riservare memoria per le macchine virtuali che ospiteranno i database MongoDB
  3. Utilizzare il controllo I/O dello storage per allocare un numero sufficiente di I/O al mongod processo.
  4. Garantire le risorse CPU dei computer che ospitano MongoDB impostando la prenotazione CPU
  5. Considerare l'utilizzo di driver di I/O ParaVirtual. Per ulteriori informazioni su come eseguire questa operazione, consultate questo articolo della knowledgebase.

Amazon Web Services

Per la documentazione su come configurare MongoDB con Amazon Web Services, consultate l'articolo Configurare l'integrazione AWS nel sito Web MongoDB.

Protezione di MongoDB prima della distribuzione

Consulta questo post sulla distribuzione sicura di MongoDB per consigli su come proteggere la configurazione dei database prima della distribuzione.

Dispatcher

Scelta del sistema operativo per il dispatcher

Per distribuire correttamente la distribuzione MongoDB, il sistema operativo che ospiterà il dispatcher deve eseguire Apache httpd versione 2.4 o successiva.
Inoltre, accertatevi che tutte le librerie utilizzate nella build siano aggiornate al fine di ridurre al minimo le implicazioni di sicurezza.

Dispatcher Configuration

Una tipica configurazione del dispatcher consente una velocità di trasmissione di richieste da dieci a venti volte superiore a una singola istanza di AEM.
Poiché il dispatcher è principalmente senza stato, può essere ridimensionato orizzontalmente con facilità. In alcune distribuzioni, agli autori deve essere imposto un limite per l’accesso a determinate risorse. È quindi consigliabile utilizzare un dispatcher con le istanze dell'autore.
L'esecuzione di AEM senza dispatcher richiederà la terminazione SSL e il bilanciamento del carico da parte di un'altra applicazione. Questo è richiesto perché le sessioni devono avere l’affinità con l’istanza di AEM in cui sono state create, un concetto noto come connessioni permanenti. Lo scopo è garantire che gli aggiornamenti al contenuto presentino una latenza minima.
Per ulteriori informazioni sulla configurazione, consulta la documentazione del dispatcher.

Configurazione aggiuntiva

Connessioni permanenti

Le connessioni permanenti garantiscono che le pagine personalizzate e i dati delle sessioni per un utente siano tutti composti sulla stessa istanza di AEM. Questi dati vengono memorizzati nell'istanza, pertanto le richieste successive dello stesso utente torneranno alla stessa istanza.
Si consiglia di abilitare le connessioni fissi per tutte le richieste di routing dei livelli interni alle istanze AEM, incoraggiando le richieste successive a raggiungere la stessa istanza di AEM. Questo consente di ridurre la latenza che altrimenti risulta evidente quando il contenuto viene aggiornato tra le istanze.

Scadenza lunga

Per impostazione predefinita, il contenuto inviato da un dispatcher AEM presenta intestazioni Last-Modified ed Etag, senza alcuna indicazione della scadenza del contenuto. Anche se questo assicura che l'interfaccia utente ottenga sempre la versione più recente della risorsa, significa anche che il browser eseguirà un'operazione GET per verificare se la risorsa è cambiata. Ciò potrebbe causare più richieste alle quali la risposta HTTP è 304 (Non modificata), a seconda del caricamento della pagina. Per le risorse notoriamente non in scadenza, l’impostazione di un’intestazione Scadute e la rimozione delle intestazioni Last-Modified e ETag causeranno la memorizzazione del contenuto nella cache e non verranno effettuate ulteriori richieste di aggiornamento fino a quando non verrà soddisfatta la data nell’intestazione Expires.
Tuttavia, se si utilizza questo metodo non esiste alcun modo ragionevole per far scadere la risorsa nel browser prima della scadenza dell’intestazione Scade. Per ovviare a questo problema, è possibile configurare HtmlClientLibraryManager in modo da utilizzare URL immutabili per le librerie client.
Tali URL non verranno modificati. Quando il corpo della risorsa contenuta nell’URL cambia, le modifiche verranno automaticamente applicate all’URL, in modo che il browser richieda la versione corretta della risorsa.
La configurazione predefinita aggiunge un selettore a HtmlClientLibraryManager. Essendo un selettore, la risorsa viene memorizzata nella cache del dispatcher con il selettore intatto. Questo selettore può essere utilizzato anche per garantire il corretto comportamento di scadenza. Il selettore predefinito segue il lc-.*?-lc pattern. Le seguenti direttive di configurazione Apache httpd garantiranno che tutte le richieste che corrispondono a tale pattern vengano servite con un tempo di scadenza adeguato.
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.*/)"

Nessun serpente

Se il contenuto viene inviato senza alcun tipo di contenuto, molti browser tentano di indovinare il tipo di contenuto leggendo i primi byte del contenuto. Questo si chiama "sniffing". La navigazione consente di aprire una vulnerabilità di sicurezza in quanto gli utenti in grado di scrivere nell’archivio possono caricare contenuti dannosi senza alcun tipo di contenuto.
Per questo motivo è consigliabile aggiungere un' no-sniff intestazione alle risorse servite dal dispatcher. Tuttavia, il dispatcher non memorizza le intestazioni nella cache. Ciò significa che qualsiasi contenuto distribuito dal file system locale avrà il proprio tipo di contenuto determinato dall’estensione, anziché utilizzare l’intestazione del tipo di contenuto originale dal server AEM di origine.
Non è possibile abilitare alcun sniff se l'applicazione Web non distribuisce mai risorse nella cache senza un tipo di file.
È possibile abilitare Nessuna stringa inclusiva:
Header set X-Content-Type-Options "nosniff"

Può anche essere attivato selettivamente:
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

Informativa sulla sicurezza dei contenuti

Le impostazioni predefinite del dispatcher consentono l'apertura dei criteri di protezione dei contenuti, noti anche come CSP. Questo consente a una pagina di caricare risorse da tutti i domini soggetti ai criteri predefiniti della sandbox del browser.
È consigliabile limitare la posizione in cui è possibile caricare le risorse per evitare di caricare il codice nel motore javascript da server esterni non attendibili o non verificati.
La CSP consente di regolare accuratamente le politiche. Tuttavia, in un'applicazione complessa le intestazioni CSP devono essere sviluppate con cautela in quanto i criteri troppo restrittivi possono interrompere parti dell'interfaccia utente.
Per ulteriori informazioni su come funziona, consultate la pagina OWASP sui criteri di protezione dei contenuti.

Ridimensionamento

Per ulteriori informazioni sul ridimensionamento, consultate le linee guida sul ridimensionamento dell' hardware.

Ottimizzazione delle prestazioni MongoDB

Per informazioni generiche sulle prestazioni di MongoDB, vedere Analisi delle prestazioni di MongoDB.

Limitazioni note

Installazioni simultanee

Anche se l’utilizzo simultaneo di più istanze AEM con un singolo database è supportato da MongoMK, le installazioni simultanee non lo sono.
Per risolvere il problema, accertatevi di eseguire prima l'installazione con un singolo membro e di aggiungere gli altri al termine della prima installazione.

Lunghezza nome pagina

If AEM is running on a MongoMK persistence manager deployment, page names are limited to 150 characters.
Fare riferimento alla documentazione MongoDB per conoscere le limitazioni e le soglie note di MongoDB stesso.