In Adobe Experience Manager (AEM), i dati binari possono essere memorizzati indipendentemente dai nodi di contenuto. I dati binari vengono memorizzati in un archivio dati, mentre i nodi di contenuto sono memorizzati in un archivio nodi.
È possibile configurare sia gli archivi di dati che gli archivi dei nodi utilizzando la configurazione OSGi. A ogni configurazione OSGi viene fatto riferimento utilizzando un identificatore permanente (PID).
Per configurare sia l'archivio nodi che l'archivio dati, esegui questi passaggi:
Copia il file JAR AEM quickstart nella relativa directory di installazione.
Crea una cartella crx-quickstart/install
nella directory di installazione.
Per prima cosa, configura l'archivio nodi creando un file di configurazione con il nome dell'opzione dell'archivio nodi che desideri utilizzare nella directory crx-quickstart/install
.
Ad esempio, l'archivio dei nodi Document (che è la base per AEM'implementazione MongoMK) utilizza il file org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
.
Modifica il file e imposta le opzioni di configurazione.
Crea un file di configurazione con il PID dell’archivio dati che desideri utilizzare. Modifica il file per impostare le opzioni di configurazione.
Per le opzioni di configurazione, consulta Configurazioni archivio nodi e Configurazioni archivio dati .
Inizia AEM.
Le versioni più recenti di Oak utilizzano un nuovo schema e formato di denominazione per i file di configurazione OSGi. Il nuovo schema di denominazione richiede che il file di configurazione sia denominato .config e che il nuovo formato richieda la digitazione di valori ed è documentato qui.
Se esegui l’aggiornamento da una versione precedente di Oak, assicurati di eseguire prima un backup della cartella crx-quickstart/install
. Dopo l'aggiornamento, ripristina il contenuto della cartella nell'installazione aggiornata e modifica l'estensione dei file di configurazione da .cfg a .config.
Se leggi questo articolo in preparazione di un aggiornamento da un'installazione di AEM 5.x, assicurati di consultare prima la documentazione upgrade .
L’archivio dei nodi del segmento è la base dell’implementazione TarMK di Adobe in AEM6. Utilizza il org.apache.jackrabbit.oak.segment.SegmentNodeStoreService
PID per la configurazione.
Il PID per l’archivio dei nodi di segmento è stato modificato da org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService in previous versions
di AEM 6 a org.apache.jackrabbit.oak.segment.SegmentNodeStoreService
in AEM 6.3. Assicurati di effettuare le regolazioni di configurazione necessarie per riflettere questa modifica.
Puoi configurare le seguenti opzioni:
repository.home
: Percorso della home del repository in cui vengono archiviati i dati relativi al repository. Per impostazione predefinita, i file dei segmenti sono memorizzati nella directory crx-quickstart/segmentstore
.
tarmk.size
: Dimensione massima di un segmento in MB. Il massimo predefinito è 256 MB.
customBlobStore
: Valore booleano che indica l'utilizzo di un archivio dati personalizzato. Il valore predefinito è true per AEM 6.3 e versioni successive. Prima di AEM 6.3, il valore predefinito era false.
Di seguito è riportato un file di esempio org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
:
#Path to repo
repository.home="crx-quickstart/repository"
#Max segment size
tarmk.size=I"256"
#Custom data store
customBlobStore=B"true"
L'archivio dei nodi del documento è la base dell'implementazione AEM MongoMK. Utilizza il org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService
PID. Sono disponibili le seguenti opzioni di configurazione:
mongouri
: Il 🔗 MongoURIrichiesto per connettersi al database Mongo. Il valore predefinito è mongodb://localhost:27017
db
: Nome del database Mongo. Il valore predefinito è Oak . Tuttavia, le nuove installazioni di AEM 6 utilizzano aem-author come nome predefinito del database.
cache
: Dimensione della cache in MB. Questa viene distribuita tra le varie cache utilizzate in DocumentNodeStore. Il valore predefinito è 256
.
changesSize
: Dimensioni in MB della raccolta limitata utilizzata in Mongo per memorizzare nella cache l'output diff. Il valore predefinito è 256
.
customBlobStore
: Valore booleano che indica che verrà utilizzato un archivio dati personalizzato. Il valore predefinito è false
.
Di seguito è riportato un file di esempio org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
:
#Mongo server details
mongouri="mongodb://localhost:27017"
#Name of Mongo database to use
db="aem-author"
#Store binaries in custom BlobStore
customBlobStore=B"false"
Quando si gestisce un numero elevato di binari, si consiglia di utilizzare un archivio dati esterno al posto degli archivi nodi predefiniti per massimizzare le prestazioni.
Ad esempio, se il progetto richiede un numero elevato di risorse multimediali, memorizzarle nel File o nell’archivio dati S3 consente di accedervi più rapidamente che archiviarle direttamente all’interno di un MongoDB.
Il File Data Store offre prestazioni migliori rispetto a MongoDB, e le operazioni di backup e ripristino Mongo sono anche più lente con un gran numero di risorse.
Di seguito sono descritti i dettagli sui diversi archivi di dati e configurazioni.
Per abilitare gli archivi dati personalizzati, è necessario assicurarsi che customBlobStore
sia impostato su true
nel rispettivo file di configurazione Node Store (archivio nodi segmento o archivio nodi documento).
Implementazione di FileDataStore presente in Jackrabbit 2. Fornisce un modo per memorizzare i dati binari come file normali sul file system. Utilizza il PID org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore
.
Sono disponibili le seguenti opzioni di configurazione:
repository.home
: Percorso della home dell'archivio in cui vengono archiviati vari dati relativi all'archivio. Per impostazione predefinita, i file binari vengono memorizzati nella directory crx-quickstart/repository/datastore
.
path
: Percorso della directory in cui vengono archiviati i file. Se specificato, ha la precedenza sul valore repository.home
.
minRecordLength
: Dimensione minima in byte di un file archiviato nell'archivio dati. Il contenuto binario inferiore a questo valore viene allineato.
Quando si utilizza un NAS per memorizzare gli archivi di dati dei file condivisi, assicurarsi di utilizzare solo dispositivi con prestazioni elevate per evitare problemi di prestazioni.
AEM può essere configurato per memorizzare i dati in Amazon Simple Storage Service (S3). Utilizza il org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config
PID per la configurazione.
Per abilitare la funzionalità dell'archivio dati S3, è necessario scaricare e installare un feature pack contenente il connettore S3 Datastore. Vai al Adobe Repository e scarica l'ultima versione dalle versioni 1.8.x del feature pack (ad esempio, com.adobe.granite.oak.s3connector-1.8.0.zip). Inoltre, è necessario scaricare e installare l'ultimo service pack AEM come elencato nella pagina AEM Note sulla versione 6.4 Service Pack .
Quando si utilizza AEM 6.4 con TarMK, i binari vengono memorizzati per impostazione predefinita nel FileDataStore
. Per utilizzare TarMK con il Datastore S3, è necessario avviare AEM utilizzando la modalità runmode crx3tar-nofds
, ad esempio:
java -jar aem6.4.jar -r crx3tar-nofds
Una volta scaricato, è possibile installare e configurare il S3 Connector come segue:
Estrarre il contenuto del file zip del feature pack in una cartella temporanea.
Passa alla cartella temporanea e passa al seguente percorso:
jcr_root/libs/system/install
Copia tutti i contenuti dalla posizione precedente in <aem-install>/crx-quickstart/install.
Se AEM è già configurato per lavorare con l'archivio Tar o MongoDB, rimuovi eventuali file di configurazione esistenti dalla cartella aem-install/crx-quickstart/install
prima di procedere. I file da rimuovere sono:
For MongoMK: org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
For TarMK: org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
Torna alla posizione temporanea in cui è stato estratto il pacchetto di funzionalità e copia il contenuto della cartella seguente:
jcr_root/libs/system/config
a
<aem-install>/crx-quickstart/install
Assicurati di copiare solo i file di configurazione necessari per la configurazione corrente. Per un archivio dati dedicato e una configurazione dell'archivio dati condivisa, copia il file org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config
.
In una configurazione cluster, esegui i passaggi sopra descritti su tutti i nodi del cluster uno per uno. Inoltre, assicurati di utilizzare le stesse impostazioni S3 per tutti i nodi.
Modifica il file e aggiungi le opzioni di configurazione richieste dalla configurazione.
Inizia AEM.
Per effettuare l’aggiornamento a una nuova versione del connettore S3 1.8.x (ad esempio, da 1.8.0 a 1.8.1), effettua le seguenti operazioni:
Interrompi l'istanza AEM.
Passa a <aem-install>/crx-quickstart/install/15
nella cartella di installazione di AEM ed effettua un backup del relativo contenuto.
Dopo il backup, elimina la vecchia versione del S3 Connector e le sue dipendenze eliminando tutti i file jar nella cartella <aem-install>/crx-quickstart/install/15
, ad esempio:
I nomi dei file sopra riportati sono utilizzati solo a scopo illustrativo e non sono definitivi.
Scarica la versione più recente del pacchetto di funzioni 1.8.x dal Adobe Repository.
Decomprimi il contenuto in una cartella separata, quindi passa a jcr_root/libs/system/install/15
.
Copia i file jar in <aem-install>/crx-quickstart/install/15 nella cartella di installazione AEM.
Avvia AEM e controlla la funzionalità del connettore.
Puoi utilizzare il file di configurazione con le seguenti opzioni:
accessKey: Chiave di accesso AWS.
secretKey: Chiave di accesso segreto AWS. Nota: in alternativa, i ruoli IAM possono essere utilizzati per l'autenticazione. Se utilizzi i ruoli IAM, non è più necessario specificare i valori accessKey
e secretKey
.
s3Bucket: Nome del bucket.
s3Region: La regione del bucket.
percorso: Percorso dell'archivio dati. Il valore predefinito è <AEM cartella di installazione>/repository/datastore
minRecordLength: Dimensione minima di un oggetto che deve essere memorizzato nell'archivio dati. Il valore minimo/predefinito è 16 KB.
maxCachedBinarySize: I binari con dimensioni inferiori o uguali a queste dimensioni verranno memorizzati nella cache di memoria. La dimensione è espressa in byte. Il valore predefinito è 17408 (17 KB).
cacheSize: Dimensione della cache. Il valore è specificato in byte. Il valore predefinito è 64 GB.
segreto: Da utilizzare solo se si utilizza la replica binaryless per l'impostazione di un archivio dati condiviso.
stagingSplitPercentage: Percentuale di dimensioni della cache configurate da utilizzare per i caricamenti asincroni di staging. Il valore predefinito è 10.
uploadThreads: Il numero di thread di caricamento utilizzati per i caricamenti asincroni. Il valore predefinito è 10.
stagingPurgeInterval: Intervallo in secondi per lo svuotamento dei caricamenti completati dalla cache di staging. Il valore predefinito è 300 secondi (5 minuti).
stagingRetryInterval: Intervallo dei tentativi in secondi per caricamenti non riusciti. Il valore predefinito è 600 secondi (10 minuti).
Standard USA | us-standard |
Stati Uniti d'America | us-west-2 |
US West (California del nord) | us-west-1 |
UE (Irlanda) |
EU |
Asia Pacifico (Singapore) |
ap-southeast-1 |
Asia Pacifico (Sydney) |
ap-southeast-2 |
Asia Pacifico (Tokyo) | ap-northeast-1 |
Sud America (San Paolo) |
sa-east-1 |
Memorizzazione in cache del DataStore
Le implementazioni di DataStore di S3DataStore
, CachingFileDataStore
e AzureDataStore
supportano il caching dei file system locali. L'implementazione CachingFileDataStore
è utile quando DataStore è su NFS (Network File System).
Quando si esegue l’aggiornamento da un’implementazione precedente della cache (prima di Oak 1.6), c’è una differenza nella struttura della directory della cache del file system locale. Nella vecchia struttura della cache sia i file scaricati che quelli caricati sono stati messi direttamente sotto il percorso della cache. La nuova struttura separa i download e i caricamenti e li memorizza in due directory denominate upload
e download
nel percorso della cache. Il processo di aggiornamento dovrebbe essere senza soluzione di continuità e tutti i caricamenti in sospeso dovrebbero essere pianificati per il caricamento e tutti i file precedentemente scaricati nella cache verranno inseriti nella cache al momento dell'inizializzazione.
Puoi anche aggiornare la cache offline utilizzando il comando datastorecacheupgrade
di oak-run. Per informazioni dettagliate su come eseguire il comando, controllare readme per il modulo oak-run.
La cache ha un limite di dimensioni e può essere configurata utilizzando il parametro cacheSize.
Download
La cache locale verrà controllata per individuare il record del file/BLOB richiesto prima di accedervi dal DataStore. Quando la cache supera il limite configurato (vedi il parametro cacheSize
) durante l’aggiunta di un file nella cache, alcuni dei file verranno sfrattati per recuperare spazio.
Caricamento asincrono
La cache supporta caricamenti asincroni in DataStore. I file vengono memorizzati localmente, nella cache (nel file system) e inizia un processo asincrono per caricare il file. Il numero di caricamenti asincroni è limitato dalle dimensioni della cache di staging. La dimensione della cache di staging viene configurata utilizzando il parametro stagingSplitPercentage
. Questo parametro definisce la percentuale di dimensione della cache da utilizzare per la cache di staging. Inoltre, la percentuale di cache disponibile per i download è calcolata come (100 - stagingSplitPercentage
) *cacheSize
.
I caricamenti asincroni sono multithread e il numero di thread è configurato utilizzando il parametro uploadThreads
.
I file vengono spostati nella cache di download principale al termine dei caricamenti. Quando la dimensione della cache di staging supera il limite, i file vengono caricati in modo sincrono nel DataStore fino a quando i caricamenti asincroni precedenti non sono completi e lo spazio è nuovamente disponibile nella cache di staging. I file caricati vengono rimossi dall’area di gestione temporanea da un processo periodico il cui intervallo è configurato dal parametro stagingPurgeInterval
.
I caricamenti non riusciti (ad esempio a causa di un’interruzione della rete) vengono messi in una coda di nuovi tentativi e riprovati periodicamente. L'intervallo di tentativi è configurato utilizzando il parametro stagingRetryInterval parameter
.
Per configurare la replica binaryless con S3, sono necessari i seguenti passaggi:
Installa le istanze di authoring e pubblicazione e assicurati che siano avviate correttamente.
Vai alle impostazioni dell'agente di replica, aprendo una pagina su http://localhost:4502/etc/replication/agents.author/publish.html.
Premere il pulsante Modifica nella sezione Impostazioni.
Cambia l'opzione del tipo Serialization in Binary less.
Aggiungi il parametro " binaryless
= true
" nell'URI di trasporto. Dopo la modifica, l’uri deve essere simile al seguente:
http://localhost:4503/bin/receive?sling:authRequestLogin=1&binaryless=true
Riavvia tutte le istanze di authoring e pubblicazione per rendere effettive le modifiche.
Estrai CQ quickstart utilizzando il seguente comando:
java -jar cq-quickstart.jar -unpack
Dopo AEM scompattato, crea una cartella all'interno della directory di installazione crx-quickstart/install.
Crea questi due file all'interno della cartella crx-quickstart
:
Dopo aver creato i file, aggiungi le opzioni di configurazione necessarie.
Installa i due bundle necessari per l'archivio dati S3 come spiegato sopra.
Assicurati che MongoDB sia installato e che sia in esecuzione un'istanza di mongod
.
Inizia AEM con il seguente comando:
java -Xmx1024m -XX:MaxPermSize=256M -jar cq-quickstart.jar -r crx3,crx3mongo
Ripetere i passaggi da 1 a 4 per la seconda istanza AEM.
Avvia la seconda istanza AEM.
Innanzitutto, crea il file di configurazione dell’archivio dati su ogni istanza necessaria per condividere l’archivio dati:
FileDataStore
, crea un file denominato org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config
e inseriscilo nella cartella <aem-install>/crx-quickstart/install
.rg.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config
nella cartella <aem-install>/crx-quickstart/install
come indicato sopra.Modifica i file di configurazione dell'archivio dati in ogni istanza in modo che puntino allo stesso archivio dati. Per ulteriori informazioni, consulta questo articolo.
Se l’istanza è stata clonata da un server esistente, devi rimuovere la clusterId
della nuova istanza utilizzando lo strumento oak-run più recente mentre l’archivio è offline. Il comando da eseguire è:
java -jar oak-run.jar resetclusterid < repository path | Mongo URI >
Se è configurato un archivio dei nodi di segmento, è necessario specificare il percorso del repository. Per impostazione predefinita, il percorso è <aem-install-folder>/crx-quickstart/repository/segmentstore.
Se è configurato un archivio dei nodi del documento, è possibile utilizzare un URI della stringa di connessione Mongo.
Lo strumento Oak-run può essere scaricato da questo percorso:
https://mvnrepository.com/artifact/org.apache.jackrabbit/oak-run/
Tieni presente che è necessario utilizzare diverse versioni dello strumento a seconda della versione Oak utilizzata con l’installazione di AEM. Prima di utilizzare lo strumento, controlla l’elenco dei requisiti di versione riportato di seguito:
Infine, convalida la configurazione. A questo scopo, è necessario cercare un file univoco aggiunto all’archivio dati da ogni archivio che lo condivide. Il formato dei file è repository-[UUID]
, dove l’UUID è un identificatore univoco di ciascun archivio.
Pertanto, una configurazione corretta deve contenere tutti i file univoci quanti sono gli archivi che condividono l'archivio dati.
I file vengono memorizzati in modo diverso, a seconda dell'archivio dati:
FileDataStore
i file vengono creati nel percorso principale della cartella dell'archivio dati.S3DataStore
i file vengono creati nel bucket S3 configurato sotto la cartella META
.AEM può essere configurato per memorizzare i dati nel servizio di archiviazione di Microsoft Azure. Utilizza il org.apache.jackrabbit.oak.plugins.blob.datastore.AzureDataStore.config
PID per la configurazione.
Per abilitare la funzionalità dell’archivio dati di Azure, è necessario scaricare e installare un pacchetto di funzioni contenente il connettore di Azure. Vai al Adobe Repository e scarica l'ultima versione dalle versioni 1.6.x del feature pack (ad esempio, com.adobe.granite.oak.azureblobconnector-1.6.3.zip).
Quando si utilizza AEM 6.4 con TarMK, i binari verranno memorizzati per impostazione predefinita nel FileDataStore. Per utilizzare TarMK con Azure DataStore, è necessario avviare AEM utilizzando la modalità di esecuzione crx3tar-nofds
, ad esempio:
java -jar aem6.4.jar -r crx3tar-nofds
Una volta scaricato, puoi installare e configurare il connettore di Azure come segue:
Estrarre il contenuto del file zip del feature pack in una cartella temporanea.
Vai alla cartella temporanea e copia il contenuto di jcr_root/libs/system/install
nella cartella <aem-install>crx-quickstart/install
.
Se AEM è già configurato per lavorare con l'archivio Tar o MongoDB, rimuovi eventuali file di configurazione esistenti dalla cartella /crx-quickstart/install
prima di procedere. I file da rimuovere sono:
ForMongoMK:
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
Per TarMK:
org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
Torna alla posizione temporanea in cui è stato estratto il feature pack e copia il contenuto di jcr_root/libs/system/config
nella cartella <aem-install>/crx-quickstart/install
.
Modifica il file di configurazione e aggiungi le opzioni di configurazione richieste dalla configurazione.
Inizia AEM.
Puoi utilizzare il file di configurazione con le seguenti opzioni:
azureSas="": Nella versione 1.6.3 del connettore è stato aggiunto il supporto per la firma di accesso condiviso (SAS) di Azure. Se nel file di configurazione sono presenti sia le credenziali SAS che di archiviazione, SAS ha priorità. Per ulteriori informazioni su SAS, consultare la documentazione ufficiale. Assicurati che il carattere '=' sia preceduto da '='.
azureBlobEndpoint="": Endpoint BLOB di Azure. Ad esempio, https://<storage-account>.blob.core.windows.net.
accessKey="": Nome dell'account di archiviazione. Per ulteriori dettagli sulle credenziali di autenticazione di Microsoft Azure, consulta la documentazione ufficiale.
secretKey="": Chiave di accesso allo storage. Assicurati che il carattere '=' sia preceduto da '='.
container="": Nome del contenitore di archiviazione BLOB di Microsoft Azure. Il contenitore è un raggruppamento di un set di BLOB. Per ulteriori informazioni, consulta la documentazione ufficiale.
maxConnections="": Numero simultaneo di richieste simultanee per operazione. Il valore predefinito è 1.
maxErrorRetry="": Numero di tentativi per richiesta. Il valore predefinito è 3.
socketTimeout="": Intervallo di timeout, in millisecondi, utilizzato per la richiesta. Il valore predefinito è 5 minuti.
Oltre alle impostazioni di cui sopra, è possibile configurare anche le seguenti impostazioni:
<aem-install>/repository/datastore.
Tutte le impostazioni devono essere inserite tra virgolette, ad esempio:
accessKey="ASDASDERFAERAER"
secretKey="28932hfjlkwdo8fufsdfas\=\="
Il processo di raccolta degli oggetti inattivi dell'archivio dati viene utilizzato per rimuovere tutti i file non utilizzati nell'archivio dati, liberando così spazio prezioso sul disco nel processo.
Puoi eseguire la raccolta degli oggetti inattivi dell'archivio dati:
Andando alla console JMX all'indirizzo https://<serveraddress:port>/system/console/jmx
Ricerca di RepositoryManagement. Una volta trovato il MBean di Repository Manager, fai clic su di esso per visualizzare le opzioni disponibili.
Scorri fino alla fine della pagina e fai clic sul collegamento startDataStoreGC(boolean markOnly) .
Nella finestra di dialogo seguente, immetti false
per il parametro markOnly
, quindi fai clic su Invoke:
Il parametro markOnly
indica se la fase di sweep della raccolta degli oggetti inattivi verrà eseguita o meno.
Quando si esegue la raccolta oggetti inattivi in una configurazione dell’archivio dati in cluster o condiviso (con Mongo o Segment Tar), il registro potrebbe visualizzare avvisi sull’impossibilità di eliminare determinati ID BLOB. Questo accade perché gli ID BLOB eliminati in una precedente raccolta oggetti inattivi vengono erroneamente referenziati da altri nodi cluster o condivisi che non hanno informazioni sulle eliminazioni degli ID. Di conseguenza, quando si esegue la raccolta oggetti inattivi, viene registrato un avviso quando si tenta di eliminare un ID già eliminato nell’ultima esecuzione. Questo comportamento non influisce sulle prestazioni o sulle funzionalità.
Con le versioni più recenti di AEM, la raccolta degli oggetti inattivi dell'archivio dati può essere eseguita anche sugli archivi di dati condivisi da più di un archivio. Per poter eseguire la raccolta degli oggetti inattivi dell'archivio dati in un archivio dati condiviso, procedi come segue:
Assicurati che tutte le attività di manutenzione configurate per la raccolta oggetti inattivi dell'archivio dati siano disabilitate su tutte le istanze dell'archivio che condividono l'archivio dati.
Esegui i passaggi indicati in Raccolta rifiuti binari singolarmente su tutte le istanze dell'archivio che condividono l'archivio dati. Tuttavia, assicurati di inserire true
per il parametro markOnly
prima di fare clic sul pulsante Invoke :
Dopo aver completato la procedura di cui sopra su tutte le istanze, esegui di nuovo la raccolta oggetti inattivi dell'archivio dati da any delle istanze:
false
per il parametro markOnly
.In questo modo verranno raccolti tutti i file trovati utilizzando la fase di contrassegno utilizzata in precedenza ed eliminati gli altri file non utilizzati dall'archivio dati.