Show Menu
ARGOMENTI×

Come eseguire AEM con TarMK Cold Standby

Introduzione

La capacità di standby a freddo di Tar Micro Kernel consente a una o più istanze AEM in standby di connettersi a un’istanza principale. 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 incoerenze sulle istanze primarie.
La funzione Cold Standby è studiata per proteggere gli scenari in cui è richiesta un'elevata disponibilità nelle istanze dell'autore . Per le situazioni in cui è richiesta un'elevata disponibilità nelle istanze di pubblicazione utilizzando il kernel Tar Micro, Adobe consiglia di utilizzare una farm di pubblicazione.
Per informazioni su ulteriori distribuzioni disponibili, consultate la pagina Implementazioni Implementazioni consigliate 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.
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:

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

Attivare TarMK Cold Standby sull'istanza primaria 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 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.
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 principale , al fine di 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

In AEM 6.3, il PID per l’archivio nodi Segmento e il servizio Store di standby è stato modificato 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 aem-primary/crx-quickstart/install
    2. Creare una cartella chiamata install.primary in aem-primary/crx-quickstart/install
    3. Crea le configurazioni richieste per l'archivio nodi e l'archivio dati preferiti in aem-primary/crx-quickstart/install/install.primary
    4. Create un file chiamato org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config nella stessa posizione e configuratelo di conseguenza. Per ulteriori informazioni sulle opzioni di configurazione, consulta Configurazione .
    5. Se utilizzi un’istanza AEM TarMK con un archivio dati esterno, crea una cartella denominata crx3 in aem-primary/crx-quickstart/install denominata crx3
    6. Posizionare il file di configurazione dell'archivio dati nella crx3 cartella.
    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 indicate l’output del registro su un file di registro separato, ad esempio /logs/tarmk-coldstandby.log . For more information, see Logging .
  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. Elimina tutti i file che potrebbero essere presenti in aem-standby/crx-quickstart/install .
    2. Creare una nuova cartella chiamata 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 chiamata crx3 in aem-standby/crx-quickstart/install
    5. Crea la configurazione dell'archivio dati e inseriscila 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.
È possibile controllare il ruolo di un'istanza in qualsiasi momento controllando la presenza delle modalità di esecuzione primarie o standby nella console Web delle impostazioni Sling.
A tal fine, andate a https://localhost:4502/system/console/status-slingsettings e verificate 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.
Nel file tarmk-coldstandby.log di standby 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 file 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 di cui sopra, 10.20.30.40 è l’indirizzo IP del primario.
Nel file principale tarmk-coldstandby.log , verranno visualizzati i seguenti elementi:
    *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 file non condiviso FileDataStore , 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 attivato, la configurazione verrà memorizzata nella directory archivio al posto 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.
  • mode Modalità ( ): verrà scelta la modalità di esecuzione dell'istanza.
  • ​Porta (porta): la porta da utilizzare per la comunicazione. Il valore predefinito è 8023 .
  • primary.host Host principale ( ): - l'host dell'istanza principale. Questa impostazione è applicabile solo per lo standby.
  • interval Intervallo di sincronizzazione ( ): - questa impostazione determina l'intervallo tra la richiesta di sincronizzazione ed è applicabile solo per l'istanza standby.
  • primary.allowed-client-ip-ranges Intervalli IP consentiti ( ): - gli intervalli IP da cui il principale consente le connessioni.
  • secure Protetto ( ): Abilita crittografia SSL. Per poter utilizzare questa impostazione, è necessario che sia attivata in tutte le istanze.
  • standby.readtimeout Timeout lettura standby ( ): Timeout per le richieste emesse 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.
  • standby.autoclean Pulizia automatica standby ( ): Chiama il metodo di pulizia se la dimensione dello store aumenta in un ciclo di sincronizzazione.
Si consiglia vivamente che il principale e lo standby abbiano ID repository diversi per renderli identificabili separatamente per servizi come Offloading. Il modo migliore per assicurarsi che questo è 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:
È 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 crx-quickstart cartella 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à primary di esecuzione:
    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, consulta la procedura descritta sopra su Creazione di un’impostazione AEM TarMK Cold Standby.

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 sul 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 utilizzare 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, consultate Creazione di una configurazione 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 potete controllare lo stato corrente dello standby e del master utilizzando la console Risorse di Monitoring Server tramite la console JMX JMX. Le informazioni si trovano in un MBean di type org.apache.jackrabbit.oak:type="Standby" nome 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. Verrà visualizzato -1 se non è stata effettuata alcuna comunicazione.
Esistono inoltre tre metodi fatturabili:
  • start(): avvia il processo di sincronizzazione.
  • stop(): interrompe il processo di sincronizzazione.
  • cleanup(): esegue l'operazione di pulizia in standby.
Primaria
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

Se si esegue Online Revision Cleanup sull'istanza principale, la procedura manuale presentata di seguito non è necessaria. Inoltre, se si utilizza la funzione di pulizia revisioni online, l' cleanup () operazione sull'istanza standby viene eseguita automaticamente.
Non eseguire la pulizia revisioni offline in standby. Non è necessario e non ridurrà la dimensione del segmento store.
Adobe consiglia di eseguire regolarmente operazioni di manutenzione per evitare un eccessivo aumento 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 org.apache.jackrabbit.oak: Fava di stato ("Standby") . Per ulteriori informazioni su come eseguire questa operazione, consulta la sezione precedente sul monitoraggio .
  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 standby.
  7. Eseguire l' cleanup() operazione 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 precedente .
  2. Al termine del processo di manutenzione e al riavvio delle istanze:
    • Sul lato principale, eseguite la raccolta dei rifiuti dell'archivio dati tramite il fagiolo JMX corrispondente come descritto in questo articolo .
    • In modalità standby, la raccolta dei rifiuti nell'archivio dati è disponibile solo tramite BlobGarbageCollection MBean - startBlobGC() . RepositoryManagement MBean non è disponibile nello standby.
    Se non si utilizza un archivio dati condiviso, la raccolta dei rifiuti deve essere eseguita prima sul computer principale e poi sullo standby.