Adobe Experience Manager con MongoDB aem-with-mongodb

Questo articolo mira a migliorare la conoscenza dei compiti e delle considerazioni necessarie per implementare correttamente AEM (Adobe Experience Manager) con MongoDB.

Per ulteriori informazioni relative alla distribuzione, consultare la sezione Distribuzione e manutenzione della documentazione.

Quando usare MongoDB con AEM when-to-use-mongodb-with-aem

MongoDB viene generalmente utilizzato per supportare le distribuzioni di authoring AEM in cui è soddisfatto uno dei seguenti criteri:

I criteri di cui sopra si applicano solo alle istanze di authoring e non alle istanze di pubblicazione che devono essere tutte basate su TarMK. Il numero di utenti si riferisce agli utenti autenticati, poiché le istanze di authoring non consentono l’accesso non autenticato.

Se i criteri non sono soddisfatti, si consiglia una distribuzione TarMK attiva/in standby per gestire la disponibilità. Generalmente, MongoDB deve essere considerato in situazioni in cui i requisiti di scalabilità sono più di quanto si possa ottenere con un singolo componente hardware.

Distribuzione minima MongoDB per AEM minimal-mongodb-deployment-for-aem

Di seguito è riportata una distribuzione minima per AEM su MongoDB. Per semplicità, sono stati generalizzati la terminazione SSL e i componenti proxy HTTP. È costituito da un singolo set di repliche MongoDB, con un primario e due secondari.

Una distribuzione minima richiede tre mongod istanze configurate come set di repliche. Un'istanza è selezionata come primaria mentre le altre istanze sono secondarie, con la selezione gestita da mongod. A ogni istanza è associato un disco locale. Il cluster è in grado di supportare il carico, pertanto si consiglia un throughput minimo di 12 MB al secondo con più di 3000 operazioni di I/O al secondo (IOPS).

Gli autori AEM sono connessi alle istanze mongod e ogni autore AEM si connette a tutte e tre le istanze mongod. Le scritture vengono inviate al primario e le letture possono essere lette da una qualsiasi delle istanze. Il traffico viene distribuito in base al carico da un Dispatcher a una qualsiasi delle istanze di authoring AEM attive. L'archivio dati di Oak è un FileDataStore e il monitoraggio MongoDB è fornito da MMS o da MongoDB Ops Manager a seconda della posizione della distribuzione. Il monitoraggio del sistema operativo e dei registri è fornito da soluzioni di terze parti come Splunk o Ganglia.

In questa distribuzione, tutti i componenti sono necessari per una corretta implementazione. Qualsiasi componente mancante lascia l’implementazione non funzionante.

Sistemi operativi operating-systems

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

Ambienti environments

Gli ambienti virtualizzati sono supportati a condizione che vi sia una buona comunicazione tra i diversi team tecnici che eseguono il progetto. Questo supporto 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, le istanze devono essere fornite con capacità di I/O e coerenza sufficienti per supportare le istanze MongoDB. In caso contrario, i processi MongoDB e l’archivio Oak funzionano in modo inaffidabile ed errato.

Negli ambienti virtualizzati, MongoDB richiede specifiche configurazioni I/O e VM per garantire che il motore di storage di MongoDB non sia paralizzato da criteri di allocazione delle risorse VMWare. Un’implementazione di successo assicura che non vi siano barriere tra i vari team e che tutti siano iscritti per fornire le prestazioni richieste.

Considerazioni sull'hardware hardware-considerations

Archiviazione storage

Per ottenere il throughput di lettura e scrittura per ottenere prestazioni ottimali senza la necessità di scalabilità orizzontale prematura, MongoDB richiede in genere storage SSD o storage con prestazioni equivalenti a SSD.

RAM ram

Le versioni 2.6 e 3.0 di MongoDB che utilizzano il motore di archiviazione MMAP richiedono che il working set del database e i relativi indici si inseriscano nella RAM.

Una RAM insufficiente determina una riduzione significativa delle prestazioni. Le dimensioni del working set e del database dipendono fortemente dall'applicazione. Anche se alcune stime possono essere fatte, il modo più affidabile per determinare la quantità di RAM necessaria è quello di creare l'applicazione AEM e testarla.

Per facilitare il processo di test di carico, è possibile supporre il seguente rapporto tra il working set e la dimensione totale del database:

Questi rapporti indicano che per le implementazioni SSD sono necessari 200 GB di RAM per un database da 2 TB.

Mentre le stesse limitazioni si applicano al motore di storage WiredTiger in MongoDB 3.0, la correlazione tra il working set, la RAM e gli errori di pagina non è così forte. WiredTiger non utilizza la mappatura della memoria allo stesso modo del motore di archiviazione MMAP.

Archivio dati data-store

A causa delle limitazioni del working set MongoDB, si consiglia di mantenere l’archivio dati indipendente da MongoDB. Nella maggior parte degli ambienti, deve essere utilizzato un FileDataStore che utilizza un NAS disponibile per tutte le istanze AEM. Per le situazioni in cui viene utilizzato Amazon Web Services, è disponibile anche un S3 DataStore. Se per qualsiasi motivo l’archivio dati viene mantenuto all’interno di MongoDB, la dimensione dell’archivio dati deve essere aggiunta alla dimensione totale del database e i calcoli del working set devono essere adeguati di conseguenza. Questo dimensionamento può significare il provisioning di più RAM per mantenere le prestazioni senza errori di pagina.

Monitoraggio monitoring

Il monitoraggio è essenziale per il successo dell'attuazione del progetto. Con sufficienti conoscenze, è possibile eseguire AEM su MongoDB senza monitoraggio. Tuttavia, tale conoscenza si trova normalmente in ingegneri specializzati per ogni sezione della distribuzione.

Questa conoscenza specializzata coinvolge in genere un ingegnere R&D che lavora sul core Apache Oak e uno specialista MongoDB.

Senza il monitoraggio a tutti i livelli, per diagnosticare i problemi è necessaria una conoscenza dettagliata della base di codice. Grazie al monitoraggio e a una guida adeguata sulle principali statistiche, i team addetti all’attuazione possono reagire in modo appropriato alle anomalie.

Sebbene sia possibile utilizzare strumenti della riga di comando per ottenere un'istantanea rapida del funzionamento di un cluster, è quasi impossibile eseguire questa operazione in tempo reale su molti host. Gli strumenti della riga di comando raramente forniscono informazioni storiche oltre pochi minuti e non consentono mai correlazioni incrociate tra diversi tipi di metriche. Un breve periodo di sincronizzazione mongod in background lento richiede un notevole sforzo manuale per la correlazione con un'attesa di I/O o livelli di scrittura eccessivi a una risorsa di archiviazione condivisa da una macchina virtuale apparentemente non connessa.

MongoDB Cloud Manager mongodb-cloud-manager

MongoDB Cloud Manager è un servizio gratuito offerto da MongoDB che consente il monitoraggio e la gestione delle istanze di MongoDB. Fornisce una panoramica 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 possa raggiungere il server di monitoraggio Cloud Manager.

Richiede un agente installato sull’istanza di MongoDB che si connette al server di monitoraggio. Esistono tre livelli dell’agente:

Sebbene l'utilizzo di Cloud Manager per l'automazione della manutenzione di un cluster MongoDB semplifichi molte delle attività di routine, non è necessario e non viene utilizzato per il backup. Tuttavia, nella scelta di un Cloud Manager da monitorare, è necessario eseguire un monitoraggio.

Per ulteriori informazioni su MongoDB Cloud Manager, consulta la documentazione di MongoDB.

Gestione operazioni MongoDB mongodb-ops-manager

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 comunica allo stesso modo di Cloud Manager con i server gestiti. Se i criteri di sicurezza non consentono l'utilizzo di un agente di monitoraggio, utilizzare MongoDB Ops Manager.

Monitoraggio del sistema operativo operating-system-monitoring

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 della gamma e dei dettagli delle informazioni richieste che vanno oltre le metriche di base dello stato di salute 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 e i socket nello stato FIN_WAIT2.

Aggregazione registro log-aggregation

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

Elenchi di controllo checklists

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

Rete network

Configurazione AEM aem-configuration

Configurazione archivio nodi node-store-configuration

Le istanze dell’AEM devono essere configurate per utilizzare l’AEM con MongoMK. La base dell’implementazione di MongoMK nell’AEM è l’archivio dei nodi dei documenti.

Per ulteriori informazioni su come configurare gli archivi nodi, vedere Configurazione degli archivi nodi e degli archivi dati in AEM.

Di seguito è riportato un esempio di configurazione dell’archivio dei nodi di documento per una distribuzione minima di MongoDB:

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

#Name of MongoDB database to use
db=aem

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

cache=2048
blobCacheSize=1024

Dove:

Configurazione archivio dati data-store-configuration

L’archivio dati viene utilizzato per memorizzare file di dimensioni superiori a una soglia. Al di sotto di tale soglia, i file vengono memorizzati come proprietà all'interno dell'archivio dei nodi dei documenti. Se si utilizza MongoBlobStore, in MongoDB viene creata una raccolta dedicata in cui memorizzare i BLOB. Questa raccolta contribuisce al working set dell'istanza mongod e richiede che mongod disponga di più RAM per evitare problemi di prestazioni. Per questo motivo, la configurazione consigliata è quella di evitare MongoBlobStore per le distribuzioni di produzione e utilizzare FileDataStore supportato da un NAS condiviso tra tutte le istanze 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 prossimità della dimensione del blocco del disco. In questo modo il file system viene utilizzato in modo efficiente e molti documenti di piccole dimensioni non contribuiscono in modo eccessivo al working set dell'istanza mongod.

Di seguito è riportata una configurazione tipica dell’archivio dati per un’implementazione 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:

Disattivazione del suggerimento query disabling-the-query-hint

Si consiglia di disabilitare l'hint di query inviato con tutte le query aggiungendo la proprietà -Doak.mongo.disableIndexHint=true quando si avvia AEM. In questo modo MongoDB calcola l’indice più appropriato da utilizzare in base alle statistiche interne.

Se l’hint query non è disabilitato, qualsiasi ottimizzazione delle prestazioni degli indici non ha alcun impatto sulle prestazioni dell’AEM.

Abilita cache persistente per MongoMK enable-persistent-cache-for-mongomk

Si consiglia di abilitare una configurazione della cache persistente per le distribuzioni MongoDB, per 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 mongodb-operating-system-optimizations

Supporto del sistema operativo operating-system-support

MongoDB 2.6 utilizza un motore di storage mappato alla 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’evitare o eliminare le operazioni di I/O lente, spesso denominate errori di pagina. Questi problemi sono errori di pagina che si applicano in particolare al processo mongod. Non confondere questo con gli errori di pagina del sistema operativo.

Per un funzionamento rapido, 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 working set. Se il working set è più grande della RAM disponibile, MongoDB deve inserire tali dati dal disco sostenendo un costo di I/O, eliminando altri dati già in memoria. Se lo sfratto causa il ricaricamento dei dati dal disco, dominano gli errori di pagina e le prestazioni peggiorano. Se il working set è dinamico e variabile, vengono generati più errori di pagina per supportare le operazioni.

MongoDB viene eseguito su diversi sistemi operativi, tra cui una vasta gamma di versioni Linux®, Windows e macOS. Per ulteriori dettagli, vedere https://docs.mongodb.com/manual/installation/#supported-platforms. A seconda della scelta del sistema operativo, MongoDB ha diversi consigli a livello di sistema operativo. Sono disponibili documenti all'indirizzo https://docs.mongodb.com/manual/administration/production-checklist-operations/#operating-system-configuration e riepilogati qui per comodità.

Linux® linux

Windows windows

WiredTiger wiredtiger

A partire da MongoDB 3.2 il motore di archiviazione predefinito per MongoDB è il motore di archiviazione WiredTiger. Questo motore offre alcune funzionalità solide e scalabili che lo rendono molto più adatto per tutti i carichi di lavoro generali del database. Le sezioni seguenti descrivono queste funzioni.

Concorrenza a livello di documento document-level-concurrency

WiredTiger utilizza il controllo della concorrenza a livello di documento per le operazioni di scrittura. Di conseguenza, più client possono modificare contemporaneamente diversi documenti di una raccolta.

Per la maggior parte delle operazioni di lettura e scrittura, WiredTiger utilizza il controllo ottimistico della concorrenza. WiredTiger utilizza solo blocchi intento a livello globale, di database e di raccolta. Quando il motore di archiviazione rileva i conflitti tra due operazioni, una di esse genera un conflitto di scrittura che causa un nuovo tentativo trasparente di MongoDB di eseguire l’operazione. Alcune operazioni globali, in genere di breve durata che coinvolgono più database, richiedono ancora un blocco globale a livello di istanza.

Alcune altre operazioni, ad esempio l'eliminazione di una raccolta, richiedono ancora un blocco esclusivo del database.

Snapshot e punti di controllo snapshots-and-checkpoints

WiredTiger utilizza MultiVersion Concurrency Control (MVCC). All'inizio di un'operazione, WiredTiger fornisce un'istantanea point-in-time dei dati della transazione. Uno snapshot presenta una visualizzazione coerente dei dati in memoria.

Durante la scrittura su disco, WiredTiger scrive tutti i dati di una copia istantanea su disco in modo coerente in tutti i file di dati. I dati now- durable fungono da punto di controllo nei file di dati. Il punto di controllo assicura la coerenza dei file di dati fino all’ultimo punto di controllo incluso. In altre parole, i punti di controllo possono fungere da punti di ripristino.

MongoDB configura WiredTiger per creare punti di controllo (ovvero, scrivere i dati delle copie istantanee su disco) a intervalli di 60 secondi o 2 GB di dati del diario.

Durante la scrittura di un nuovo punto di controllo, il punto di controllo precedente è ancora valido. Di conseguenza, anche se MongoDB termina o riscontra un errore durante la scrittura di un nuovo punto di controllo, al riavvio MongoDB può ripristinarsi dall’ultimo punto di controllo valido.

Il nuovo punto di controllo diventa accessibile e permanente quando la tabella dei metadati di WiredTiger viene aggiornata atomicamente per fare riferimento al nuovo punto di controllo. Quando il nuovo punto di controllo è accessibile, WiredTiger libera le pagine dai punti di controllo precedenti.

Utilizzando WiredTiger, anche senza journaling, MongoDB può eseguire il ripristino dall'ultimo checkpoint; tuttavia, per recuperare le modifiche apportate dopo l'ultimo checkpoint, eseguire con journaling.

Diario journal

WiredTiger utilizza una combinazione di accesso con transazione write-ahead e checkpoint per garantire la durata dei dati.

Il journal WiredTiger mantiene tutte le modifiche apportate ai dati tra i punti di controllo. Se MongoDB esce tra punti di controllo, utilizza il giornale di registrazione per riprodurre tutti i dati modificati dall’ultimo punto di controllo. Per informazioni sulla frequenza con cui MongoDB scrive i dati del diario su disco, vedere Processo di inserimento nel diario.

Il journal WiredTiger è compresso utilizzando la libreria di compressione snappy. Per specificare un algoritmo di compressione alternativo o nessuna compressione, utilizzare l'impostazione storage.wiredTiger.engineConfig.journalCompressor.

Vedi Inserimento nel diario con WiredTiger.

Compressione compression

Con WiredTiger, MongoDB supporta la compressione per tutte le raccolte e gli indici. La compressione riduce al minimo l'utilizzo dello storage a scapito della CPU aggiuntiva.

Per impostazione predefinita, WiredTiger utilizza la compressione dei blocchi con la libreria di compressione snappy per tutte le raccolte e la compressione dei prefissi per tutti gli indici.

Per le raccolte, è disponibile anche la compressione dei blocchi 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 prefix, utilizzare l'impostazione storage.wiredTiger.indexConfig.prefixCompression.

Le impostazioni di compressione sono configurabili anche per singola raccolta e per indice durante la creazione di raccolte e indici. Vedere Specificare le opzioni del motore di archiviazione e 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 journal WiredTiger è compresso per impostazione predefinita. Per informazioni sulla compressione del journal, vedere Journal.

Utilizzo della memoria memory-use

Con WiredTiger, MongoDB utilizza sia la cache interna di WiredTiger che la cache del file system.

A partire dalla versione 3.4, la cache interna di WiredTiger, per impostazione predefinita, utilizza il valore maggiore tra:

Per impostazione predefinita, WiredTiger utilizza la compressione dei blocchi Snappy per tutti gli insiemi e la compressione dei prefissi per tutti gli indici. I valori predefiniti di compressione sono configurabili a livello globale e possono essere impostati anche per singola raccolta e per singolo indice durante la creazione della raccolta e dell’indice.

Per i dati nella cache interna di WiredTiger vengono utilizzate diverse rappresentazioni rispetto al formato su disco:

Gli indici caricati nella cache interna di WiredTiger hanno una rappresentazione dei dati diversa rispetto al formato su disco, ma possono comunque sfruttare la compressione dei prefissi dell'indice per ridurre l'utilizzo della RAM.

La compressione dei prefissi di indice deduplica i prefissi comuni dai campi indicizzati.

I dati di raccolta nella cache interna di WiredTiger non sono compressi e utilizzano una rappresentazione diversa dal formato su disco. La compressione a blocchi può consentire un notevole risparmio di spazio su disco, ma i dati devono essere decompressi per poter essere manipolati dal server.

Tramite la cache del file system, MongoDB utilizza automaticamente tutta la memoria libera che non viene utilizzata dalla cache di WiredTiger o da altri processi.

Per regolare le dimensioni della cache interna di WiredTiger, vedere storage.wiredTiger.engineConfig.cacheSizeGB e —wiredTigerCacheSizeGB. Evitare di aumentare le dimensioni della cache interna di WiredTiger oltre il valore predefinito.

NUMA numa

NUMA (Non-Uniform Memory Access) consente a un kernel di gestire il modo in cui la memoria viene mappata ai core del processore. Anche se questo processo tenta di rendere più veloce l'accesso alla memoria per i core, garantendo che siano in grado di accedere ai dati richiesti, NUMA interferisce con MMAP introducendo una latenza aggiuntiva, in quanto non è possibile prevedere le letture. Di conseguenza, NUMA deve essere disabilitato per il processo mongod su tutti i sistemi operativi compatibili.

In sostanza, in un'architettura NUMA la memoria è connessa alle CPU e le CPU sono collegate a un bus. In un SMP o in un'architettura UMA, la memoria è connessa al bus e condivisa dalle CPU. Quando un thread alloca memoria su una CPU NUMA, viene allocato in base a un criterio. L'impostazione predefinita consiste nell'allocare memoria collegata alla CPU locale del thread a meno che non vi sia spazio libero, nel qual caso utilizza memoria da una CPU libera a un costo maggiore. Una volta allocata, la memoria non si sposta tra le CPU. L’allocazione viene eseguita da un criterio ereditato dal thread padre, che in ultima analisi è il thread che ha avviato il processo.

In molti database che vedono il computer come un'architettura di memoria uniforme e multicore, questo scenario fa sì che la CPU iniziale si riempia prima e la CPU secondaria si riempia in seguito. È particolarmente vero se un thread centrale è responsabile dell'allocazione dei buffer di memoria. La soluzione consiste nel modificare il criterio NUMA del thread principale utilizzato per avviare il processo mongod eseguendo il comando seguente:

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

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

Problemi NUMA numa-issues

Se il processo mongod viene avviato da un percorso diverso da quello della cartella /etc/init.d, è probabile che non sia stato avviato con il criterio NUMA corretto. A seconda del criterio predefinito, possono verificarsi problemi. Il motivo è che i vari programmi di installazione di Linux® Package Manager per MongoDB installano anche un servizio con file di configurazione in /etc/init.d che eseguono il passaggio descritto sopra. Se si installa ed esegue MongoDB direttamente da un archivio ( .tar.gz), è necessario eseguire manualmente monGod nel processo numactl.

Il processo MongoDB si comporta in modo diverso in base a diversi criteri di allocazione:

Alcuni criteri potrebbero causare l'assegnazione di meno di tutta la RAM disponibile al processo mongod. A differenza di MySQL, MongoDB evita attivamente il paging a livello di sistema operativo e pertanto il processo mongod potrebbe ottenere meno memoria che sembra disponibile.

Scambio swapping

A causa dell'utilizzo intensivo della memoria dei database, è necessario disabilitare lo scambio a livello di sistema operativo. Il processo MongoDB evita lo scambio per progettazione.

File system remoti remote-filesystems

I file system remoti come NFS non sono consigliati per i file di dati interni di MongoDB (i file di database di processo mongood), perché introducono troppa latenza. Non confondere con il file system condiviso richiesto per l'archiviazione di Oak Blob (FileDataStore), dove si consiglia NFS.

Leggi tutto read-ahead

Sintonizza Leggi in avanti in modo che, quando si esegue il paging di una pagina mediante una lettura casuale, dal disco non vengano letti blocchi non necessari. Ciò significa un consumo inutile di larghezza di banda di I/O.

Requisiti Linux® linux-requirements

Versioni minime del kernel minimum-kernel-versions

Impostazioni consigliate per i dischi di database recommended-settings-for-database-disks

Disattiva atime

È consigliabile disattivare atime per i dischi che contengono i database.

Impostare l'utilità di pianificazione dischi NOOP

Effettua le seguenti operazioni:

Innanzitutto, controllare il modulo di pianificazione I/O impostato eseguendo il comando seguente:

cat /sys/block/sdg/queue/scheduler

Se la risposta è noop, non è necessario eseguire altre operazioni.

Se NOOP non è il modulo di pianificazione I/O configurato, è possibile modificarlo eseguendo:

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

Regola il valore di read-ahead

È consigliabile utilizzare il valore 32 per i dischi in cui vengono eseguiti i database MongoDB. Questo valore ammonta a 16 KB. Puoi impostarlo eseguendo le seguenti operazioni:

sudo blockdev --setra <value> <device>

Abilita NTP enable-ntp

Verificare che NTP sia installato e in esecuzione nel computer che ospita i database MongoDB. Ad esempio, puoi installarlo utilizzando Gestione pacchetti yum su un computer CentOS:

sudo yum install ntp

Dopo aver installato e avviato correttamente il daemon NTP, è possibile verificare la differenza di tempo del server nel file di deriva.

Disattiva pagine grandi trasparenti disable-transparent-huge-pages

Red Hat® Linux® utilizza un algoritmo di gestione della memoria chiamato Transparent Huge Pages (THP). È consigliabile disattivarla se si utilizza il sistema operativo per i carichi di lavoro del database.

Puoi disattivarla seguendo la procedura seguente:

Disattiva NUMA disable-numa

Nella maggior parte delle installazioni in cui è abilitato NUMA, il daemon MongoDB lo disabilita automaticamente se viene eseguito come servizio dalla cartella /etc/init.d.

In caso contrario, è possibile disattivare NUMA a livello di processo. Per disattivarla, eseguire i comandi seguenti:

numactl --interleave=all <path_to_process>

Dove <path_to_process> è il percorso del processo mondio.

Quindi, disabilita il recupero delle zone eseguendo:

echo 0 > /proc/sys/vm/zone_reclaim_mode

Modifica le impostazioni massime per il processo mondio tweak-the-ulimit-settings-for-the-mongod-process

Linux® consente un controllo configurabile sull'allocazione delle risorse tramite il comando ulimit. Questa configurazione può essere eseguita su un utente o in base al singolo processo.

Si consiglia di configurare ulimit per il processo monGod in base alle Impostazioni ulimit consigliate di MongoDB.

Test prestazioni I/O MongoDB test-mongodb-i-o-performance

MongoDB fornisce uno strumento denominato mongoperf progettato per testare le prestazioni di I/O. È consigliabile utilizzarlo per testare le prestazioni di tutte le istanze MongoDB che compongono la tua infrastruttura.

Per informazioni su come utilizzare mongoperf, consulta la documentazione di MongoDB.

Verifica le prestazioni di lettura nelle macchine virtuali che compongono la distribuzione

Dopo aver installato lo strumento, passa alla directory del database MongoDB per eseguire i test. Quindi, avviare il primo test eseguendo mongoperf con questa configurazione:

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

L’output desiderato deve raggiungere un massimo di due gigabyte al secondo (2 GB/s) e 500.000 IOPS in esecuzione a 32 thread per tutte le istanze MongoDB.

Eseguire un secondo test, questa volta utilizzando file mappati in memoria, impostando il parametro mmf:true:

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

L'output del secondo test deve essere considerevolmente superiore al primo, indicando le prestazioni di trasferimento della memoria.

Verifica le prestazioni di scrittura dell'istanza MongoDB primaria

Verificare quindi le prestazioni di scrittura I/O dell'istanza MongoDB principale 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 poche variazioni tra il numero di thread.

Passaggi per gli ambienti virtualizzati steps-for-virtualised-environments

VMWare vmware

Se si utilizza WMWare ESX per gestire e implementare gli ambienti virtualizzati, assicurarsi di eseguire le seguenti impostazioni dalla console ESX per supportare l'operazione MongoDB:

Amazon Web Services amazon-web-services

Per la documentazione sulla configurazione di MongoDB con Amazon Web Services, consulta l'articolo Configurare l'integrazione di AWS sul sito Web MongoDB.

Protezione di MongoDB prima dell’implementazione securing-mongodb-before-deployment

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

Dispatcher dispatcher

Scelta del sistema operativo per Dispatcher choosing-the-operating-system-for-the-dispatcher

Per gestire correttamente la distribuzione di MongoDB, il sistema operativo che ospita il Dispatcher deve eseguire Apache httpd versione 2.4 o successiva.

Inoltre, assicurati che tutte le librerie utilizzate nella build siano aggiornate per ridurre al minimo le implicazioni di sicurezza.

Configurazione Dispatcher dispatcher-configuration

Una tipica configurazione di Dispatcher fornisce da dieci a 20 volte di più del throughput di richiesta di una singola istanza AEM.

Poiché il Dispatcher è senza stato, può scalare orizzontalmente con facilità. In alcune distribuzioni, agli autori deve essere limitato l’accesso a determinate risorse. È consigliabile utilizzare un Dispatcher con le istanze di authoring.

L’esecuzione dell’AEM senza Dispatcher richiede la terminazione SSL e il bilanciamento del carico da parte di un’altra applicazione. È necessario perché le sessioni devono avere affinità con l’istanza AEM sulla quale vengono create, un concetto noto come connessioni permanenti. Il motivo è garantire che gli aggiornamenti al contenuto mostrino una latenza minima.

Per ulteriori informazioni su come configurarlo, consulta la documentazione di Dispatcher.

Configurazione aggiuntiva additional-configuration

Connessioni permanenti sticky-connections

Le connessioni permanenti garantiscono che le pagine personalizzate e i dati di sessione di un utente siano tutti composti nella stessa istanza dell’AEM. Questi dati vengono memorizzati nell’istanza, quindi le richieste successive dello stesso utente tornano alla stessa istanza.

Si consiglia di abilitare le connessioni permanenti per tutti i livelli interni che instradano le richieste alle istanze AEM, incoraggiando le richieste successive a raggiungere la stessa istanza AEM. In questo modo è possibile ridurre al minimo la latenza, che in caso di aggiornamento del contenuto tra istanze si nota in altro modo.

Scadenza lunga long-expires

Per impostazione predefinita, il contenuto inviato da un Dispatcher AEM ha le intestazioni Last-Modified ed Etag, senza alcuna indicazione della scadenza del contenuto. Questo flusso garantisce che l’interfaccia utente riceva sempre la versione più recente della risorsa. Significa anche che il browser esegue un’operazione di GET per verificare se la risorsa è stata modificata. Di conseguenza, può causare più richieste alle quali la risposta HTTP è 304 (Non modificata), a seconda del caricamento della pagina. Per le risorse che non scadono, l’impostazione di un’intestazione Scadenza e la rimozione delle intestazioni Last-Modified e ETag causano la memorizzazione in cache del contenuto. Inoltre, non vengono effettuate ulteriori richieste di aggiornamento fino alla data specificata nell’intestazione Scade.

Tuttavia, l’utilizzo di questo metodo significa che non esiste un modo ragionevole per causare la scadenza della risorsa nel browser prima della scadenza dell’intestazione Scade. Per attenuare questo flusso di lavoro, HtmlClientLibraryManager può essere configurato in modo da utilizzare URL immutabili per le librerie client.

Questi URL non subiranno modifiche. Quando il corpo della risorsa contenuta nell’URL cambia, le modifiche si riflettono nell’URL e garantiscono 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 di Dispatcher con il selettore intatto. Anche questo selettore può essere utilizzato per garantire il corretto comportamento di scadenza. Il selettore predefinito segue il pattern lc-.*?-lc. Le seguenti direttive di configurazione di Apache httpd garantiscono che tutte le richieste che corrispondono a tale modello vengano soddisfatte con un tempo di scadenza appropriato.

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.*/)"

Nessuna sniffatura no-sniff

Se il contenuto viene inviato senza alcun tipo di contenuto, molti browser tentano di indovinare il tipo di contenuto leggendo i primi byte. Questo metodo è chiamato "sniffing". Lo sniffing apre una vulnerabilità di sicurezza in quanto gli utenti in grado di scrivere nell’archivio potrebbero caricare contenuti dannosi senza alcun tipo di contenuto.

Per questo motivo, è consigliabile aggiungere un'intestazione no-sniff alle risorse fornite da Dispatcher. Tuttavia, Dispatcher non memorizza in cache le intestazioni. Di conseguenza, significa che qualsiasi contenuto fornito dal file system locale ha il suo tipo di contenuto determinato dalla sua estensione, piuttosto che utilizzare l’intestazione content-type originale dal suo server AEM di origine.

Nessun sniff può essere abilitato in modo sicuro se è noto che l’applicazione web non distribuisce mai le risorse memorizzate in cache senza un tipo di file.

È possibile abilitare No Sniff inclusivamente:

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

Può anche essere abilitato in modo selettivo:

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 content-security-policy

Le impostazioni predefinite di Dispatcher consentono di aprire Criteri sulla sicurezza dei contenuti, noti anche come CSP. Queste impostazioni consentono a una pagina di caricare risorse da tutti i domini soggetti ai criteri predefiniti della sandbox del browser.

È consigliabile limitare il luogo in cui le risorse possono essere caricate da per evitare di caricare codice nel motore di JavaScript da server esterni non attendibili o non verificati.

I CSP consentono di perfezionare i criteri. 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.

Ridimensionamento sizing

Per ulteriori informazioni sul dimensionamento, vedere le linee guida per il dimensionamento hardware.

Ottimizzazione delle prestazioni di MongoDB mongodb-performance-optimization

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

Limitazioni note known-limitations

Installazioni simultanee concurrent-installations

Sebbene l’uso simultaneo di più istanze AEM con un singolo database sia supportato da MongoMK, le installazioni simultanee non lo sono.

Per risolvere il problema, assicurarsi di eseguire prima l'installazione con un singolo membro e aggiungere gli altri dopo che l'installazione del primo è stata completata.

Lunghezza nome pagina page-name-length

Se l'AEM è in esecuzione in una distribuzione di Gestione persistenza MongoMK, i nomi di pagina sono limitati a 150 caratteri.