Come eseguire AEM con TarMK Cold Standby

Introduzione

La capacità di standby a freddo del Tar Micro Kernel consente a una o più istanze AEM di standby di collegarsi a un'istanza primaria. Il processo di sincronizzazione è un modo solo, il che significa che viene eseguito solo dalle istanze primarie a quelle in standby.

Lo scopo delle istanze standby è quello di garantire una copia live dei dati del repository principale e garantire un interruttore rapido senza perdita di dati nel caso in cui il master non sia disponibile per qualsiasi motivo.

Il contenuto viene sincronizzato in modo lineare tra l'istanza principale e le istanze in standby senza che sia necessario verificare l'integrità del file o del repository. A causa di questa progettazione, le istanze in standby sono copie esatte dell'istanza principale e non possono aiutare a mitigare le incongruenze sulle istanze primarie.

NOTA

La funzione Cold Standby è studiata per proteggere gli scenari in cui è richiesta un'elevata disponibilità nelle istanze author. Per le situazioni in cui è richiesta un'elevata disponibilità su istanze publish che utilizzano il kernel Tar Micro, Adobe consiglia di utilizzare una farm di pubblicazione.

Per informazioni su ulteriori distribuzioni disponibili, consultate la pagina Implementazioni consigliate.

Come funziona

Nell'istanza AEM principale, viene aperta una porta TCP che sta ascoltando i messaggi in arrivo. Attualmente, ci sono due tipi di messaggi che gli schiavi invieranno al padrone:

  • un messaggio che richiede l'ID segmento dell'intestazione corrente
  • un messaggio che richiede i dati del segmento con un ID specificato

La modalità standby richiede periodicamente l’ID del segmento dell’intestazione corrente del primario. Se il segmento è localmente sconosciuto, verrà recuperato. Se è già presente, i segmenti vengono confrontati e, se necessario, anche i segmenti a cui viene fatto riferimento.

NOTA

Le istanze in standby non ricevono alcun tipo di richieste, perché sono in esecuzione in modalità solo sincronizzazione. L'unica sezione disponibile in un'istanza in standby è la console Web, per facilitare la configurazione del bundle e dei servizi.

Una tipica implementazione TarMK Cold Standby:

chlimage_1-86

Altre caratteristiche

Robustezza

Il flusso di dati è progettato per rilevare e gestire automaticamente i problemi di connessione e di rete. Tutti i pacchetti vengono forniti con checksum e non appena si verificano problemi con la connessione o i pacchetti danneggiati, vengono attivati i meccanismi di ritentamento.

Spettacolo

Abilitare TarMK Cold Standby sull'istanza principale non ha quasi alcun impatto misurabile sulle prestazioni. Il consumo aggiuntivo della CPU è molto basso e l'I/O del disco rigido e della rete non deve generare problemi di prestazioni.

Durante il processo di sincronizzazione, in standby è possibile che la CPU venga utilizzata a un livello elevato. Poiché la procedura non è multithread, non può essere accelerata utilizzando più core. Se non si modificano o si trasferiscono dati, non ci sarà alcuna attività misurabile. La velocità di connessione varia a seconda dell'hardware e dell'ambiente di rete, ma non dipende dalle dimensioni dell'archivio o dall'utilizzo di SSL. Tenete presente questo aspetto quando stimate il tempo necessario per una sincronizzazione iniziale o quando nel frattempo molti dati sono stati modificati sul nodo principale.

Sicurezza

Presupponendo che tutte le istanze vengano eseguite nella stessa area di protezione Intranet, il rischio di violazione della sicurezza viene notevolmente ridotto. Tuttavia, potete aggiungere un ulteriore livello di protezione abilitando le connessioni SSL tra gli slave e il master. In questo modo si riduce la possibilità che i dati siano compromessi da un uomo in mezzo.

Potete inoltre specificare le istanze in standby consentite per la connessione limitando l'indirizzo IP delle richieste in arrivo. In questo modo si dovrebbe garantire che nessuno nella Intranet possa copiare il repository.

NOTA

Si consiglia di aggiungere un sistema di bilanciamento del carico tra il dispatcher e i server che fanno parte della configurazione di Coldy Standby. Il sistema di bilanciamento del carico deve essere configurato in modo da indirizzare il traffico degli utenti solo all'istanza primario, in modo da garantire la coerenza e impedire che il contenuto venga copiato sull'istanza standby con metodi diversi dal meccanismo di standby a freddo.

Creazione di una configurazione AEM TarMK Cold Standby

ATTENZIONE

Il PID per l'archivio nodi Segmento e il servizio di store Standby è stato modificato in AEM 6.3 rispetto alle versioni precedenti, come segue:

  • da org.apache.jackrabbit.oak.plugins.segment.standby.store.StandbyStoreService a org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService
  • da org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService a org.apache.jackrabbit.oak.segment.SegmentNodeStoreService

Accertatevi di apportare le modifiche necessarie alla configurazione per riflettere questa modifica.

Per creare una configurazione TarMK in standby freddo, è innanzitutto necessario creare le istanze in standby eseguendo una copia del file system dell'intera cartella di installazione del primario in una nuova posizione. È quindi possibile avviare ogni istanza con una modalità di esecuzione che ne specifica il ruolo ( primary o standby).

Di seguito è riportata la procedura da seguire per creare una configurazione con un’istanza master e un’istanza standby:

  1. Installare AEM.

  2. Arrestate l’istanza e copiate la cartella di installazione nel percorso in cui verrà eseguita l’istanza in standby freddo. Anche se eseguite da computer diversi, accertatevi di assegnare a ciascuna cartella un nome descrittivo (come aem-primario o aem-standby) per distinguere tra le istanze.

  3. Andate alla cartella di installazione dell’istanza principale e:

    1. Controllare ed eliminare eventuali configurazioni OSGi precedenti che si possono avere in aem-primary/crx-quickstart/install
    2. Creare una cartella denominata install.primary in aem-primary/crx-quickstart/install
    3. Crea le configurazioni necessarie per l'archivio nodi e l'archivio dati preferiti in aem-primary/crx-quickstart/install/install.primary
    4. Create un file denominato org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config nella stessa posizione e configuratelo di conseguenza. Per ulteriori informazioni sulle opzioni di configurazione, vedere Configurazione.
    5. Se si utilizza un'istanza AEM TarMK con un archivio dati esterno, creare una cartella denominata crx3 in aem-primary/crx-quickstart/install denominata crx3
    6. Posizionare il file di configurazione dell'archivio dati nella cartella crx3.

    Se, ad esempio, state eseguendo un'istanza AEM TarMK con un archivio dati file esterno, avete bisogno dei seguenti file di configurazione:

    • aem-primary/crx-quickstart/install/install.primary/org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
    • aem-primary/crx-quickstart/install/install.primary/org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config
    • aem-primary/crx-quickstart/install/crx3/org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

    Di seguito sono riportate configurazioni di esempio per l'istanza principale:

    Esempio di org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config

    org.apache.sling.installer.configuration.persist=B"false"
    customBlobStore=B"true"
    standby=B"false"
    

    Esempio di org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config

    org.apache.sling.installer.configuration.persist=B"false"
    mode="primary"
    port=I"8023"
    

    Esempio di org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

    org.apache.sling.installer.configuration.persist=B"false"
    path="./crx-quickstart/repository/datastore"
    minRecordLength=I"16384"
    
  4. Avviate la modalità principale accertandovi di specificare la modalità di esecuzione principale:

    java -jar quickstart.jar -r primary,crx3,crx3tar
    
  5. Create un nuovo logger di registrazione Apache Sling per il pacchetto org.apache.jackrabbit.oak.segment. Impostate il livello di registro su "Debug" e indirizzate l'output del registro su un file di registro separato, ad esempio /logs/tarmk-coldstandby.log. Per ulteriori informazioni, vedere Registrazione.

  6. Andate alla posizione dell'istanza standby e avviatela eseguendo il jar.

  7. Create la stessa configurazione di registrazione utilizzata per il file principale. Quindi, arrestate l'istanza.

  8. Quindi, preparare l'istanza standby. A tal fine, è possibile eseguire gli stessi passaggi dell'istanza principale:

    1. Eliminate eventuali file presenti in aem-standby/crx-quickstart/install.

    2. Creare una nuova cartella denominata install.standby in aem-standby/crx-quickstart/install

    3. Create due file di configurazione denominati:

      • org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
      • org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config
    4. Creare una nuova cartella denominata crx3 in aem-standby/crx-quickstart/install

    5. Creare la configurazione dell'archivio dati e posizionarla in aem-standby/crx-quickstart/install/crx3. Ad esempio, il file da creare è:

      • org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config
    6. Modificate i file e create le configurazioni necessarie.

    Di seguito sono riportati alcuni file di configurazione di esempio per una tipica istanza in standby:

    Esempio di org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config

    org.apache.sling.installer.configuration.persist=B"false"
    name="Oak-Tar"
    service.ranking=I"100"
    standby=B"true"
    customBlobStore=B"true"
    

    Esempio di org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config

    org.apache.sling.installer.configuration.persist=B"false"
    mode="standby"
    primary.host="127.0.0.1"
    port=I"8023"
    secure=B"false"
    interval=I"5"
    standby.autoclean=B"true"
    

    Esempio di org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

    org.apache.sling.installer.configuration.persist=B"false"
    path="./crx-quickstart/repository/datastore"
    minRecordLength=I"16384"
    
  9. Avviare l'istanza standby utilizzando la modalità di esecuzione standby:

    java -jar quickstart.jar -r standby,crx3,crx3tar
    

Il servizio può essere configurato anche tramite la console Web tramite:

  1. Passate alla console Web all'indirizzo: https://serveraddress:serverport/system/console/configMgr
  2. Alla ricerca di un servizio denominato Apache Jackrabbit Oak Segment Tar Cold Standby Service e fare doppio clic su di esso per modificare le impostazioni.
  3. Salvataggio delle impostazioni e riavvio delle istanze in modo da rendere effettive le nuove impostazioni.
NOTA

È possibile controllare il ruolo di un'istanza in qualsiasi momento controllando la presenza delle modalità di esecuzione primario o standby nella console Web delle impostazioni di Sling.

A tale scopo, andare alla riga http://localhost:4502/system/console/status-slingsettings e controllare la riga "Run Modes".

Prima sincronizzazione

Dopo il completamento del preparato e l'avvio dello standby per la prima volta, si verificherà un traffico di rete pesante tra i casi in quanto lo standby raggiunge il primo. Potete consultare i registri per osservare lo stato della sincronizzazione.

In standby tarmk-coldstandby.log, sono disponibili le seguenti voci:

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.standby.store.StandbyStore trying to read segment ec1f739c-0e3c-41b8-be2e-5417efc05266

    *DEBUG* [nioEventLoopGroup-3-1] org.apache.jackrabbit.oak.segment.standby.codec.SegmentDecoder received type 1 with id ec1f739c-0e3c-41b8-be2e-5417efc05266 and size 262144

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.standby.store.StandbyStore got segment ec1f739c-0e3c-41b8-be2e-5417efc05266 with size 262144

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.file.TarWriter Writing segment ec1f739c-0e3c-41b8-be2e-5417efc05266 to /mnt/crx/author/crx-quickstart/repository/segmentstore/data00016a.tar

Nel error.log dello standby è visibile una voce come questa:

*INFO* [FelixStartLevel] org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService started standby sync with 10.20.30.40:8023 at 5 sec.

Nel frammento di registro sopra, 10.20.30.40 è l'indirizzo IP del primario.

In primario tarmk-coldstandby.log sono disponibili le seguenti voci:

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.store.CommunicationObserver got message ‘s.d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd’ from client c7a7ce9b-1e16-488a-976e-627100ddd8cd

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.server.StandbyServerHandler request segment id d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.server.StandbyServerHandler sending segment d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd to /10.20.30.40:34998

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.store.CommunicationObserver did send segment with 262144 bytes to client c7a7ce9b-1e16-488a-976e-627100ddd8cd

In questo caso, il "client" menzionato nel registro è l'istanza standby.

Una volta che queste voci non compaiono più nel registro, è possibile supporre che il processo di sincronizzazione sia completo.

Anche se le voci sopra riportate mostrano che il meccanismo di polling funziona correttamente, è spesso utile capire se vi sono dati che vengono sincronizzati durante il polling. Per eseguire questa operazione, cercare le voci seguenti:

*DEBUG* [defaultEventExecutorGroup-156-1] org.apache.jackrabbit.oak.segment.file.TarWriter Writing segment 3a03fafc-d1f9-4a8f-a67a-d0849d5a36d5 to /<<CQROOTDIRECTORY>>/crx-quickstart/repository/segmentstore/data00014a.tar

Inoltre, quando si esegue con un FileDataStore non condiviso, messaggi come quelli riportati di seguito confermeranno che i file binari vengono trasmessi correttamente:

*DEBUG* [nioEventLoopGroup-228-1] org.apache.jackrabbit.oak.segment.standby.codec.ReplyDecoder received blob with id eb26faeaca7f6f5b636f0ececc592f1fd97ea1a9#169102 and size 169102

Configurazione

Per il servizio Cold Standby sono disponibili le seguenti impostazioni OSGi:

  • Configurazione persistente: se abilitata, questa opzione memorizzerà la configurazione nell’archivio invece dei tradizionali file di configurazione OSGi. Si consiglia di mantenere disattivata questa impostazione sui sistemi di produzione in modo che la configurazione primaria non venga estratta dallo standby.

  • Modalità (mode): questa opzione consente di scegliere la modalità di esecuzione dell’istanza.

  • Porta (porta): la porta da utilizzare per la comunicazione. Il valore predefinito è 8023.

  • Host principale (primary.host): - l'host dell'istanza principale. Questa impostazione è applicabile solo per lo standby.

  • Intervallo di sincronizzazione (interval): - questa impostazione determina l'intervallo tra la richiesta di sincronizzazione ed è applicabile solo per l'istanza standby.

  • Intervalli IP consentiti (primary.allowed-client-ip-ranges): - gli intervalli IP da cui il principale consentirà le connessioni.

  • Protetto (secure): Abilita crittografia SSL. Per poter utilizzare questa impostazione, è necessario che sia attivata in tutte le istanze.

  • Timeout lettura standby (standby.readtimeout): timeout per le richieste inviate dall'istanza standby, in millisecondi. L'impostazione di timeout consigliata è 43200000. In genere si consiglia di impostare il timeout su un valore di almeno 12 ore.

  • Pulizia automatica standby (standby.autoclean): chiama il metodo di pulizia se la dimensione dello store aumenta in un ciclo di sincronizzazione.

NOTA

Si consiglia vivamente che il principale e lo standby abbiano ID di repository diversi per renderli identificabili separatamente per servizi come Offloading.

Il modo migliore per assicurarsi che questo sia coperto è eliminando il file sling.id sullo standby e riavviando l'istanza.

Procedure di failover

Nel caso in cui l'istanza principale non riesca per qualsiasi motivo, potete impostare una delle istanze in standby per assumere il ruolo di primario modificando la modalità di esecuzione iniziale come descritto di seguito:

NOTA

È inoltre necessario modificare i file di configurazione in modo che corrispondano alle impostazioni utilizzate per l'istanza principale.

  1. Accedete alla posizione in cui è installata l'istanza standby e arrestatela.

  2. Se con la configurazione è configurato un sistema di bilanciamento del carico, a questo punto è possibile rimuovere il sistema primario dalla configurazione del sistema di bilanciamento del carico.

  3. Eseguire il backup della cartella crx-quickstart dalla cartella di installazione in standby. Può essere utilizzato come punto di partenza per la configurazione di un nuovo standby.

  4. Riavviate l'istanza utilizzando la modalità di esecuzione primary:

    java -jar quickstart.jar -r primary,crx3,crx3tar
    
  5. Aggiungete il nuovo elemento primario al sistema di bilanciamento del carico.

  6. Creare e avviare una nuova istanza in standby. Per ulteriori informazioni, vedere la procedura riportata sopra in Creazione di un AEM TarMK Cold Standby Setup.

Applicazione delle correzioni rapide a una configurazione in standby fredda

Il modo consigliato per applicare hotfix a una configurazione a freddo stanby è installarli nell'istanza principale e poi clonarli in una nuova istanza a freddo standby con gli hotfix installati.

A tal fine, effettuate le seguenti operazioni:

  1. Arrestate il processo di sincronizzazione sull'istanza in standby a freddo accedendo alla console JMX e utilizzando org.apache.jackrabbit.oak: Stato ("Standby") fagiolo. Per ulteriori informazioni su come eseguire questa operazione, vedere la sezione relativa al Monitoraggio.
  2. Arrestare l'istanza in standby a freddo.
  3. Installate l'hotfix nell'istanza principale. Per ulteriori dettagli su come installare un hotfix, vedere Come lavorare con i pacchetti.
  4. Verificate i problemi dell'istanza dopo l'installazione.
  5. Rimuovere l'istanza in standby freddo eliminando la cartella di installazione.
  6. Arrestate l'istanza principale e duplicatela eseguendo una copia del file system dell'intera cartella di installazione nella posizione dello standby freddo.
  7. Riconfigurare il clone appena creato per fungere da istanza in standby a freddo. Per ulteriori dettagli, vedere Creazione di un'impostazione AEM TarMK Cold Standby.
  8. Avviate sia l'istanza di standby principale che quella fredda.

Monitoraggio

La funzione espone le informazioni utilizzando JMX o MBeans. In questo modo è possibile controllare lo stato corrente dello standby e del master utilizzando la console JMX. Le informazioni si trovano in un MBean di type org.apache.jackrabbit.oak:type="Standby"denominato Status.

Standby

Osservando un'istanza in standby si espone un nodo. L’ID è in genere un UUID generico.

Questo nodo ha cinque attributi di sola lettura:

  • Running: valore booleano che indica se il processo di sincronizzazione è in esecuzione o meno.
  • Mode: Client: seguito dall’UUID utilizzato per identificare l’istanza. Questo UUUID verrà modificato ogni volta che la configurazione viene aggiornata.
  • Status: una rappresentazione testuale dello stato corrente (come running o stopped).
  • FailedRequests:il numero di errori consecutivi.
  • SecondsSinceLastSuccess: il numero di secondi dall'ultima comunicazione con il server riuscita. Se la comunicazione non è riuscita, viene visualizzata -1.

Sono inoltre disponibili tre metodi di fatturazione:

  • start(): avvia il processo di sincronizzazione.
  • stop(): interrompe il processo di sincronizzazione.
  • cleanup(): esegue l'operazione di pulizia in standby.

Principale

Osservando il primario vengono esposte alcune informazioni generali tramite un MBean il cui valore ID è il numero di porta utilizzato dal servizio di standby TarMK (per impostazione predefinita 8023). La maggior parte dei metodi e degli attributi sono gli stessi della modalità standby, ma alcuni sono diversi:

  • Mode: mostra sempre il valore primary.

È inoltre possibile recuperare informazioni per un massimo di 10 client (istanze in standby) collegati al master. L'ID MBean è l'UUID dell'istanza. Non esistono metodi fatturabili per questi MBeans, ma alcuni attributi di sola lettura molto utili:

  • Name: l'ID del client.
  • LastSeenTimestamp: la marca temporale dell'ultima richiesta in una rappresentazione testuale.
  • LastRequest: l'ultima richiesta del client.
  • RemoteAddress: l'indirizzo IP del client.
  • RemotePort: la porta utilizzata dal client per l'ultima richiesta.
  • TransferredSegments: il numero totale di segmenti trasferiti a questo client.
  • TransferredSegmentBytes:il numero totale di byte trasferiti a questo client.

Manutenzione archivio in standby a freddo

Pulizia revisioni

ATTENZIONE

Non eseguire la pulizia revisioni offline in standby. Non è necessario e non ridurrà la dimensione del segmento store.

NOTA

Se si esegue Pulizia revisioni online sull'istanza principale, la procedura manuale riportata di seguito non è necessaria. Inoltre, se si utilizza la funzione di pulizia revisioni online, l'operazione cleanup () nell'istanza standby verrà eseguita automaticamente.

Adobe raccomanda di eseguire regolarmente la manutenzione per evitare un'eccessiva crescita del repository nel tempo. Per eseguire manualmente la manutenzione del repository in standby a freddo, procedere come segue:

  1. Arrestate il processo di standby sull'istanza standby accedendo alla console JMX e utilizzando il org.apache.jackrabbit.oak: Stato ("Standby") fagiolo. Per ulteriori informazioni su come eseguire questa operazione, vedere la sezione precedente su Monitoring.

  2. Arrestate l'istanza AEM principale.

  3. Eseguire lo strumento di compattazione quercia sull'istanza principale. Per ulteriori dettagli, vedere Gestione dell'archivio.

  4. Avviate l’istanza principale.

  5. Avviare il processo di standby sull'istanza standby utilizzando lo stesso fagiolo JMX come descritto nel primo passaggio.

  6. Controllate i registri e attendete il completamento della sincronizzazione. È possibile che in questo momento si verifichi una crescita sostanziale nel repository stand-by.

  7. Eseguire l'operazione cleanup() sull'istanza standby, utilizzando lo stesso fagiolo JMX come descritto nel primo passaggio.

Potrebbe essere necessario più tempo del solito per completare la sincronizzazione con l'istanza standby, in quanto la compattazione offline riscrive efficacemente la cronologia del repository, rendendo così più veloce il calcolo delle modifiche nei repository. Si noti inoltre che una volta completato il processo, le dimensioni del repository sullo standby saranno più o meno uguali a quelle del repository sul principale.

In alternativa, il repository principale può essere copiato in standby manualmente dopo aver eseguito la compattazione sul primario, in pratica ricreando lo standby ogni volta che la compattazione viene eseguita.

Archivio dati raccolta oggetti inattivi

È importante eseguire il processo di garbage collection sulle istanze del datastore del file di volta in volta, altrimenti i file binari eliminati rimarranno nel file system, fino a riempire l'unità. Per eseguire la raccolta dei rifiuti, attenetevi alla procedura seguente:

  1. Eseguire la manutenzione del repository in standby a freddo come descritto nella sezione sopra.

  2. Dopo il completamento del processo di manutenzione e il riavvio delle istanze:

    • Sul primario, eseguire la raccolta dei rifiuti dell'archivio dati tramite il fagiolo JMX corrispondente come descritto in questo articolo.
    • In standby, la raccolta dei rifiuti nell'archivio dati è disponibile solo tramite BlobGarbageCollection MBean - startBlobGC(). Il file RepositoryManagement MBean non è disponibile in standby.
    NOTA

    Se non si utilizza un archivio dati condiviso, la raccolta dei rifiuti deve essere eseguita prima sul computer principale e poi sullo standby.

In questa pagina

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free