Verwendung des Befehls "Reparatur"

Einführung

Dieses Dokument beschreibt die Verwendung der versteckten CLI-Befehlsreparaturwarteschlange und die Aktionen, die bei der Ausgabe des Befehls über die CLI einer Cisco Email Security Appliance (ESA) ausgeführt werden.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• Systemkapazität, Systemüberwachung, Systemzustand und Gesamtverarbeitung von Nachrichten über die ESA-Workload-Warteschlange.
• Allgemeine ESA-Verwaltung.

Hinweis: Weitere Informationen finden Sie im ESA-Benutzerhandbuch oder in der Online-Hilfe der ESA-GUI.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• ESA, alle Hardware und virtuellen Appliances mit AsyncOS 11.0.0-264 oder neuer

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Problem

Gründe für die Ausführung des Befehls reparaturwarteschlange:

• Fehler, der angibt, dass die Workqueue nicht bereitgestellt wird. Dies ist in der Regel das Ergebnis einer fehlerhaften Warteschlange nach dem unsachgemäßen Ein- und Ausschalten oder Neustart der Appliance.
• Ein bekannter Fehler erfordert dies als Problemumgehung (z. B. CSCuw2284 - Die E-Mail-Warteschlange beschädigt nach dem Absturz des Hermes oder einem ungeeigneten Herunterfahren).
• Anwendungsfehler, z. B. die Verweise auf "gcq.py" oder das Warteschlangenmanagement-Subsystem.
• Status Detail oder Workqueue > rate melden negative Zahlen.
• Status- oder Statusangaben melden "Älteste Nachricht", die älter als Ihr Bounce-Profil ist. Der Standardwert hierfür ist 3 Tage. Sie können bounceconfig > bearb überprüfen und das Standardprofil auswählen. Sie suchen nach der Zeile "Geben Sie die maximale Anzahl von Sekunden ein, die eine Nachricht möglicherweise in der Warteschlange verbleibt, bevor sie per Hard-Bounce zurückgesendet wird", die standardmäßig 259200 Sekunden oder 3 Tage beträgt. Dies schließt die virtuellen Bereitstellungsdomänen, die Warteschlange.<destination>.queue, wie z. B. die Warteschlange.cpq.queue, die.euq.queue, die Datei.cpq.release.host aus.

Gründe, den Befehl reparaturwarteschlange NICHT auszuführen:

• Die langsame Verarbeitung von Workloads ist kein gültiger Grund, eine Warteschlangenreparatur auszuführen. Administratoren verwechseln die langsame Verarbeitung von Workloads häufig mit der Beschädigung von Warteschlangen. Eine langsame Warteschlange ist in der Regel darauf zurückzuführen, dass dieselbe(n) Nachricht(en) wiederholt verarbeitet wird (werden), da Systemressourcen überlastet werden. Häufig handelt es sich bei diesen wiederholten Verarbeitungsszenarien nicht um Dinge, die durch das Ausführen einer Reparaturwarteschlange repariert werden. Es ist eine weitere Fehlerbehebung für die Services erforderlich, bei denen während der Verarbeitung eine Meldung "hängen" würde.

Verwendung des Befehls "Reparatur"

Durch das Ausführen des CLI-Befehls reparieren Sie die Warteschlange möglicherweise nicht alle Workqueue-Probleme oder -Beschädigungen. Dieses Dienstprogramm bemüht sich nach besten Kräften, die Workqueue zu reparieren.

Warnung: ESA-Administratoren sollten beachten, dass die Möglichkeit besteht, aktive Nachrichten aus einer Workload-Warteschlange zu verlieren.

Bei der Ausführung der Reparaturwarteschlange fordert der erste Prozesslauf einmal die Genehmigung zum Fortsetzen und Ausführen der Reparatur auf:

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.

Hinweis: Ignorieren Sie auf einer virtuellen ESA die folgende Ausgabe, den bekannten Fehler (CSCuz28415): "Warten auf die Einhängung der Warteschlange: Gerät konnte unter /dev/ipmi0 oder /dev/ipmi/0 oder /dev/ipmidev/0 nicht geöffnet werden: Keine solche Datei oder ein solches Verzeichnis"

Nach Abschluss des Reparaturprozesses wird die Warteschlange repariert, die Appliance behält jedoch einen alten Prüfpunkt der vorherigen Workload-Warteschlange bei. Um mit dem Schreiben eines neuen Prüfpunkts für die Verarbeitung von Workloads fortzufahren, führen Sie die Reparaturwarteschlange erneut aus, und geben Sie den Befehl Clean (Bereinigen) aus:

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

Überprüfen

Wenn die Reparaturwarteschlange abgeschlossen ist, führen Sie bitte jeden der folgenden Schritte aus, um zu überprüfen, ob die Warteschlange wieder online ist und die Appliance E-Mail verarbeitet:

1. Überprüfen Sie den Systemstatus, indem Sie in der CLI den Befehl status detail oder Monitor > System Status aus der GUI ausführen.  Die Appliance sollte den Systemstatus Online wiedergeben.  
2. Überprüfen Sie die E-Mail-Protokolle auf der Appliance, um sicherzustellen, dass die E-Mail-Verarbeitung wie erwartet erfolgt.  Dies kann über die CLI mithilfe des Befehls tail mail_logs erreicht werden.
3. Führen Sie den Befehl Workqueue über die CLI aus, und wählen Sie die Rate-Option mit der Standardrate von 10 Sekunden aus. Solange die Appliance E-Mails ein- und/oder aussendet, sollte die Rate pro 10 Sekunden für das Verhältnis "Ein/Aus" ziemlich gleich sein. Appliances mit einer großen Warteschlange für die ausstehende Verarbeitung können einige Zeit in Anspruch nehmen, um die Warteschlange zu leeren und die normale Verarbeitung wieder aufzunehmen.

Häufig gestellte Fragen

Was ist, wenn meine ESA nicht ab Version 11.0.0-264 betrieben wird?

Kunden mit Appliances, auf denen ältere Versionen von AsyncOS ausgeführt werden, die nicht über die Befehlsoption für die Reparaturwarteschlange für versteckte CLI verfügen, sollten ein Support-Ticket erstellen, um Unterstützung durch einen Cisco Support-Techniker zu erhalten.  Für den Zugriff auf die Appliance und die Ausführung des Reparaturwarteschlangen-Prozesses muss ein Support-Tunnel geöffnet und zur Verfügung gestellt werden.  Wenden Sie sich an den Cisco Support, um ein aktives Support-Ticket zu erstellen.

Bedeutet die Workqueue ''Korruption' einen Mail-Verlust?

In den meisten Fällen entspricht Korruption nicht dem Verlust von E-Mails. Die Warteschlange ist aufgrund von Metadaten zur Verarbeitung von Nachrichten, die sich nicht mehr auf der Appliance befinden, beschädigt. Hierbei handelt es sich um eine Buchungsverarbeitung zwischen Warteschlange und Berichterstellung, Nachrichtenverfolgung usw. Beim Ausführen der Reparaturwarteschlange werden die ESA-Meta-Daten neu erstellt und alle fehlerhaften Meldungen zwischen Services und Verarbeitung beseitigt.

Gibt es Auswirkungen auf die Beschädigung von Workloads?

Die ESA kann möglicherweise lange in einer beschädigten Warteschlange ausgeführt werden, und die meisten Nachrichten können fehlerfrei verarbeitet werden. Die Appliance kann jedoch als träge erscheinen, oder bestimmte Meldungen werden niemals gelöscht, wie im Status-Befehl "Älteste Nachricht" angegeben. Dies ist deutlich älter als die bounceconfig sollte dies zulassen. Wenn AsyncOS mit einer beschädigten Warteschlange neu gestartet wird, kann die Warteschlange möglicherweise bereitgestellt werden. Die Beschädigung kann vor einiger Zeit aufgetreten sein und scheint bis zum Neustart der Appliance in Ordnung zu sein. Ab diesem Zeitpunkt kann die Warteschlange nicht bereitgestellt werden.

Was führt zur Beschädigung von Warteschlangen?

Die beiden häufigsten Ursachen für "Warteschlangenbeschädigung" sind:

1. Unerwartete Neustarts der Appliance. Stromausfälle oder das Halten des Betriebsschalters führen zu einem unsachgemäßen Herunterfahren und können die Warteschlange beschädigen, je nachdem, welche Backend-Prozesse zu dieser Zeit ausgeführt wurden. Die Appliance kann sich möglicherweise wiederherstellen, und die Warteschlange kann beschädigt wiederhergestellt werden, oder die Warteschlange kann beim Neustart nicht mehr bereitgestellt werden. Wenn dies der Fall ist, werden für ESA-Administratoren Warnmeldungen mit dem Status "queue not mounted" (Nicht bereitgestellte Warteschlange) und/oder "Daemon reagiert nicht" angezeigt, wenn der Status von der CLI ausgeführt wird.
   
   

   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

2. Ausgehende RAM-Nutzung durch die Appliance  Dies ist höchstwahrscheinlich auf eine falsche Konfiguration der Listener- und/oder Mail-Flow-Richtlinien zurückzuführen, die in der Regel bei zu vielen zulässigen eingehenden Verbindungen/Injektionen auftritt. Cisco empfiehlt, Ihre listenerconfig auf maximale eingehende Verbindungen zu überprüfen. Cisco empfiehlt, die Einstellung auf 300 zu setzen.

Wie lange soll das Reparaturskript vergehen?

Die Reparatur der Workqueue kann je nach Zustand der ESA zwischen 10 Sekunden und mehreren Stunden dauern, und wie viele Nachrichten derzeit über eine aktive Workqueue verarbeitet werden. Eine Reparatur der Workqueue-Workloads für eine Appliance der unteren Leistungsklasse mit vollständigen Warteschlangen zum Zeitpunkt der Beschädigung könnte mehrere Stunden dauern.

Was passiert, wenn die Reparaturwarteschlange nicht ausgeführt werden kann oder nicht abgeschlossen wird?

In bestimmten Situationen (z. B. übervollständige Warteschlange auf einer Appliance) kann die Reparaturwarteschlange nicht abgeschlossen werden. Wenn die Reparaturwarteschlange nach 4 Stunden nicht abgeschlossen wird, ist die Warteschlange höchstwahrscheinlich nicht reparierbar, und es besteht der einzige Rückgriff darauf, eine neue Warteschlange zu erstellen, indem der ausgeblendete CLI-Befehl Resetqueue ausgeführt wird. Bei komplexen Problemen wenden Sie sich bitte an den Cisco Support, um ein aktives Support-Ticket zu erstellen, und lassen Sie sich von der Unterstützung durch den Cisco Support beraten.

Zugehörige Informationen

• Cisco Email Security Appliance - Benutzerhandbücher
• Cisco Email Security Appliance-Befehlsreferenzen
• Verwendung des Befehls Zurücksetzen
• Wie sieht die Reihenfolge der Verarbeitung in der Arbeitswarteschlange aus? Was ist die Pipeline für Arbeitswarteschlangen?
• Technischer Support und Dokumentation - Cisco Systems