Configurazione dei controlli di integrità conservati per lo standby a freddo di AEM TarMK
Questo articolo spiega come configurare Keepalived in un ambiente Adobe Experience Manager (AEM) TarMK Cold Standby per garantire che solo l’istanza Autore primaria riceva il traffico utente, impedendo al nodo in standby di servire le richieste prima della promozione manuale.
Descrizione description
Nelle distribuzioni di AEM Author che utilizzano lo standby a freddo di TarMK, l’opzione Keepalived viene spesso utilizzata per gestire un IP virtuale (VIP) che indirizza il traffico al nodo attivo. Per impostazione predefinita, molte configurazioni utilizzano un semplice controllo della porta (ad esempio, la verifica dell’ascolto della porta 8443) come controllo dello stato per l’assegnazione di VIP. Tuttavia, questo approccio può comportare che il nodo in standby sia considerato sano e idoneo a ricevere traffico, anche se non è promosso a primario. Questo può causare l’instradamento del traffico utente o API al nodo in standby, che non è supportato finché non viene esplicitamente promosso.
Ambiente
- Autore Adobe Experience Manager (AEM) con standby a freddo TarMK
- Un’istanza Autore primaria e un’istanza Autore in standby a freddo
- Conservata gestione di un IP virtuale (VIP) per il bilanciamento del carico
Sintomi
- Si osserva traffico API o utente che raggiunge il nodo in standby prima che venga promosso al livello primario
- Non vengono registrati messaggi di errore specifici, ma il traffico viene indirizzato al nodo in standby in modo imprevisto
Causa
Un controllo dello stato basato solo sulla disponibilità della porta (ad esempio la porta 8443) non distingue tra i ruoli primario e standby. Questo consente al nodo in standby di essere idoneo per il traffico VIP e di ricezione, che non è supportato nelle topologie TarMK Cold Standby.
Risoluzione resolution
Per risolvere il problema, segui i passaggi seguenti:
-
Verifica la configurazione corrente del controllo di integrità conservato. Se si controlla solo la porta 8443 (ad esempio, utilizzando un comando come
/usr/bin/nc -w 3 -zv localhost 8443), non è sufficiente determinare il ruolo del nodo. -
Sostituisci il controllo della porta con uno script di controllo dello stato personalizzato che convalida se il nodo è in esecuzione come istanza Autore primaria. Ad esempio, è possibile utilizzare un file di marcatore o un altro indicatore affidabile presente solo sul nodo principale.
-
Esempio di script di verifica stato personalizzato (utilizzando un file di marcatore):
bash #!/bin/bash if [ -f /opt/aem/is_primary ] ; then exit 0 else exit 1 fiVerificare che il file del marcatore (ad esempio:
/opt/aem/is_primary) esista solo sul nodo primario. Rimuovi o crea questo file come parte del processo di promozione manuale. -
Aggiorna la configurazione con conservazione per utilizzare questo script personalizzato come controllo dello stato per l’idoneità di VIP.
-
Durante il normale funzionamento, accertarsi che lo script di controllo dello stato restituisca il risultato positivo solo sul nodo principale. Il nodo di standby non deve superare il controllo di integrità finché non viene promosso.
-
Per la promozione manuale:
- Quando è necessario il failover, arrestare AEM sul nodo principale corrente.
- Promuovi il nodo in standby a primario aggiornandone la configurazione e creando il file di marcatore (ad esempio:
touch /opt/aem/is_primary). - Avvia AEM sul nuovo nodo principale.
- Lo script di verifica stato verrà completato correttamente, consentendo a Keepalived di annunciare il VIP sul nuovo primario.
- Ricreare o riconfigurare il nodo in standby in base alle esigenze per garantire un’elevata disponibilità continua.
- Verifica che solo il nodo principale attivo annunci VIP e riceva il traffico utente testando l’accesso tramite VIP dopo la promozione.