Introduzione
In questo documento viene descritto l'uso del comando repairqueue nascosto dalla CLI e le azioni che si verificano quando il comando viene emesso dalla CLI di un Cisco Email Security Appliance (ESA).
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- Capacità del sistema, monitoraggio del sistema, stato del sistema ed elaborazione complessiva dei messaggi attraverso la coda di lavoro ESA.
- Amministrazione generale dell'ESA.
Nota: per ulteriori informazioni consultare il manuale dell'utente ESA o la guida in linea fornita dall'interfaccia dell'ESA.
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
- ESA, tutti i dispositivi hardware e virtuali con AsyncOS 11.0.0-264 o versioni successive
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Problema
Motivi per eseguire il comando repairqueue:
- Errore durante l'avvio del montaggio della coda di lavoro. In genere ciò è dovuto al danneggiamento della coda dopo un ciclo di alimentazione non corretto o al riavvio dell'accessorio.
- Un difetto noto richiede questa soluzione (ad esempio, CSCuw2284 - La coda e-mail si danneggia dopo l'arresto anomalo di Hermes o di un altro dispositivo).
- Errori dell'applicazione, ad esempio quelli che fanno riferimento a "gcq.py" o al sottosistema di gestione delle code.
- Dettaglio stato o coda di lavoro > tasso riportano numeri negativi.
- Stato o Dettagli stato riporta "Messaggio meno recente" più vecchio del profilo di rimbalzo. Il valore predefinito è 3 giorni. È possibile eseguire la verifica da bounceconfig > edit e scegliere il profilo di default. Verrà cercata la riga "Immettere il numero massimo di secondi durante i quali un messaggio può rimanere in coda prima di essere bloccato definitivamente", che per impostazione predefinita è 259200 secondi o 3 giorni. In questo modo vengono esclusi i domini di recapito virtuali, ovvero.<destination>.queue, ad esempio the.cpq.queue, the.euq.queue e the.cpq.release.host.
Motivi per NON eseguire il comando repairqueue:
- La lentezza dell'elaborazione della coda di lavoro non è un motivo valido per eseguire un ripristino della coda. Gli amministratori spesso confondono l'elaborazione lenta delle code di lavoro con il danneggiamento delle code. Una coda di lavoro lenta è in genere dovuta alla ripetizione dell'elaborazione degli stessi messaggi a causa di un sovrautilizzo delle risorse di sistema da parte del servizio. Spesso questi scenari di elaborazione ripetuti non sono cose che vengono riparate semplicemente eseguendo repairqueue. È necessaria un'ulteriore risoluzione dei problemi dei servizi per cui un messaggio risulterebbe "bloccato" durante l'elaborazione.
Uso del comando repairqueue
L'esecuzione del comando CLI repairqueue potrebbe non risolvere tutti i problemi o i danneggiamenti della coda di lavoro. Questa utilità consente di ripristinare la coda di lavoro nel miglior modo possibile.
Avviso: gli amministratori ESA dovrebbero prendere nota della possibilità di perdere i messaggi attivi da una coda di lavoro.
Quando si esegue repairqueue, la prima esecuzione del processo richiederà l'autorizzazione una volta per procedere ed eseguire il ripristino:
myesa.local> repairqueue
Do you want to repair or clean the queue?
1. Repair.
2. Clean.
[1]> 1
The mail flow will be stopped through out the repair/cleanup process
WARNING:
This utility does a best effort to repair the queue.
Not all queues corruptions can be repaired.
Are you sure you want to proceed? [N]> y
Checking generation checksum files
...
<<<SNIP FOR BREVITY>>>
...
done
Repair succeeded
Starting Hermes
Hermes Started
Log into the system and verify the status of the system.
Nota: su un'ESA virtuale, ignorare il seguente output, difetto noto (CSCuz28415): "In attesa del montaggio della coda: Impossibile aprire il dispositivo in /dev/ipmi0 o /dev/ipmi/0 o /dev/ipmidev/0: File o directory non esistente"
Una volta completato il processo di riparazione, la coda di lavoro verrà riparata, tuttavia l'accessorio manterrà un vecchio checkpoint della coda di lavoro precedente. Per riprendere la scrittura di un nuovo checkpoint per l'elaborazione della coda di lavoro, eseguire di nuovo il comando repairqueue ed eseguire il comando Clean:
myesa.local> repairqueue
Do you want to repair or clean the queue?
1. Repair.
2. Clean.
[1]> 2
The mail flow will be stopped through out the repair/cleanup process
WARNING:
There is a backup found this may be the only backup.
This will to remove the old queue.
Are you sure you want to proceed? [N]> y
Double confirmation. Are you sure you want to proceed? [N]> y
Removing old queue
Cleanup finished
Verifica
Una volta completata la coda di ripristino, eseguire ognuna delle operazioni seguenti per verificare che la coda di lavoro sia di nuovo in linea e che l'accessorio stia elaborando la posta:
- Verificare lo stato del sistema eseguendo il comando status detail dalla CLI o Monitorare > Stato del sistema dalla GUI. L'accessorio deve indicare lo stato del sistema Online.
- Esaminare i log di posta sull'accessorio per verificare che la posta venga elaborata come previsto. A tale scopo, è possibile eseguire il comando tail mail_logs dalla CLI.
- Eseguire il comando workqueue dalla CLI, scegliendo l'opzione Rate (Velocità) con una velocità predefinita di 10 secondi. Finché l'accessorio elabora la posta in entrata e/o in uscita, la velocità di 10 secondi dovrebbe essere abbastanza uguale per il rapporto "In/Out". Gli accessori con una coda di lavoro di elaborazione in sospeso di grandi dimensioni possono impiegare del tempo per svuotare la coda di lavoro e riprendere l'elaborazione normale.
Domande frequenti
Cosa succede se l'ESA non funziona a partire dalla versione 11.0.0-264?
I clienti che dispongono di appliance con versioni precedenti di AsyncOS senza l'opzione di comando repairqueue hidden CLI devono aprire una richiesta di assistenza per ricevere l'assistenza di un tecnico del supporto Cisco. Affinché il supporto Cisco possa accedere all'accessorio ed eseguire il processo di riparazione, è necessario aprire e rendere disponibile un tunnel di supporto. Contattare il supporto Cisco per aprire una richiesta di assistenza attiva.
La coda di lavoro ''danneggiata'' indica una perdita di posta?
Nella maggior parte dei casi, la corruzione non equivale alla perdita di posta. La coda è danneggiata a causa di metadati correlati all'elaborazione di messaggi non più presenti sull'accessorio. Si tratta di un'elaborazione di conservazione dei registri tra la coda e il report, la verifica dei messaggi e così via. L'esecuzione di repairqueue consentirà di ricostruire i metadati ESA e di eliminare eventuali segnalazioni errate tra i servizi e l'elaborazione.
Ci sono ripercussioni sul danneggiamento delle code di lavoro?
L'ESA può funzionare a lungo su una coda corrotta e la maggior parte dei messaggi può essere elaborata correttamente, ma l'accessorio può apparire lento o alcuni messaggi possono non essere cancellati, come indicato dal "Messaggio più vecchio" nel comando status — molto più vecchio di quanto bounceconfig dovrebbe consentire. Quando AsyncOS viene effettivamente riavviato con una coda danneggiata, la coda potrebbe essere o non essere in grado di eseguire il montaggio. Il danneggiamento potrebbe essersi verificato qualche tempo fa e sembra che sia corretto finché l'accessorio non viene riavviato, nel qual caso non è in grado di montare la coda.
Cause del danneggiamento della coda
Le due cause più comuni di 'danneggiamento della coda' sono:
- Riavvii imprevisti dell'accessorio. Le interruzioni dell'alimentazione o la pressione del pulsante di alimentazione determinano uno spegnimento non corretto e possono danneggiare la coda, a seconda dell'operazione eseguita dai processi back-end in quel momento. L'accessorio potrebbe essere ripristinato e la coda potrebbe essere danneggiata oppure potrebbe non essere possibile montare la coda al riavvio. Se questo è vero, gli amministratori ESA vedranno gli allarmi "queue not mounted" e/o "daemon not responding" quando lo stato di esecuzione dalla CLI.
myesa.local> status
Enter "status detail" for more information.
Couldn't obtain mail stats - my.esa: The daemon is not responding.
myesa.local> status
Enter "status detail" for more information.
Couldn't obtain mail stats - the queue is not mounted
- Utilizzo della RAM fuori banda da parte dell'accessorio. Questo problema è probabilmente causato da una configurazione errata dei criteri del listener e/o del flusso di posta, in genere rilevata con un numero eccessivo di connessioni in ingresso consentite. Cisco consiglia di verificare il valore listenerconfig per il numero massimo di connessioni in entrata. Cisco consiglia di impostare questo valore su 300.
Tempo necessario per il completamento dello script di ripristino
Il ripristino della coda di lavoro può richiedere da 10 secondi a diverse ore, a seconda dello stato dell'ESA e del numero di messaggi che stanno elaborando attraverso una coda di lavoro attiva. La riparazione di una coda di lavoro su un accessorio di fascia bassa con code complete al momento del danneggiamento potrebbe richiedere diverse ore.
Cosa succede se la coda di ripristino non può essere eseguita o non viene completata?
In alcune situazioni (ad esempio, la coda di un accessorio è troppo piena) la coda di ripristino non potrà essere completata. se la coda di ripristino non viene completata dopo 4 ore, è molto probabile che non possa essere ripristinata e l'unico modo per farlo è creare una nuova coda eseguendo il comando nascosto resetqueue della CLI. Per problemi avanzati, contattare il supporto Cisco per aprire una richiesta di assistenza attiva e ricevere assistenza dal supporto Cisco.
Informazioni correlate
Feedback