Verwendung der Kommando-Reparaturwarteschlange

Einleitung

Dieses Dokument beschreibt die Verwendung der ausgeblendeten CLI-Befehl-Reparaturwarteschlange 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, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Systemkapazität, Systemüberwachung, Systemstatus und Gesamtverarbeitung von Meldungen über die ESA-Arbeitswarteschlange.
• Gesamtverwaltung der ESA.

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

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• ESA, alle Hardware und virtuellen Appliances mit AsyncOS 11.0.0-264 oder höher

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.

Problem

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

• Fehler beim Angeben, dass die Arbeitswarteschlange nicht bereitgestellt ist. Dies ist in der Regel das Ergebnis einer fehlerhaften Warteschlangenkonfiguration nach einem unzulässigen Aus- und Einschalten oder Neustart der Appliance.
• Bekannter Fehler erfordert dies als Problemumgehung (z. B. CSCuw2284 - E-Mail-Warteschlange beschädigt nach Hermes-Absturz oder unsachgemäßem Herunterfahren).
• Anwendungsfehler, z. B. "gcq.py" oder das Warteschlangenverwaltungs-Subsystem.
• Statusdetails oder workqueue > rate melden negative Zahlen.
• Status- oder Statusdetail-Berichte "Älteste Nachricht", die älter als Ihr Bounce-Profil sind. Der Standardwert hierfür ist 3 Tage. Sie können dies über bounceconfig > edit überprüfen und das Standardprofil auswählen. Sie suchen nach der Zeile "Please enter the maximum number of seconds a message may stay in the queue before being hard bounced" (Geben Sie die maximale Anzahl der Sekunden ein, die eine Nachricht in der Warteschlange verbleiben darf, bevor sie per Hard-Bounce zurückgesendet wird), die standardmäßig 259200 Sekunden oder 3 Tage beträgt. Dies schließt die virtuellen Zustellungsdomänen, die.<destination>.queue, wie die.cpq.queue, die.euq.queue und die.cpq.release.host, aus.

Gründe, warum Sie den Befehl repairqueue NICHT ausführen sollten:

• Die langsame Verarbeitung der Arbeitswarteschlange ist kein gültiger Grund für die Durchführung einer Warteschlangenreparatur. Administratoren verwechseln die langsame Verarbeitung von Arbeitswarteschlangen häufig mit einer fehlerhaften Warteschlange. Eine langsame Arbeitswarteschlange resultiert in der Regel aus der wiederholten Verarbeitung derselben Nachricht(en) aufgrund einer Service-Überlastung der Systemressourcen. Häufig sind diese wiederholten Verarbeitungsszenarien keine Dinge, die durch einfaches Ausführen der Reparaturwarteschlange repariert werden. Es ist eine weitere Fehlerbehebung für die Dienste erforderlich, an denen während der Verarbeitung eine Nachricht "aufgehängt" wird.

Verwendung der Kommando-Reparaturwarteschlange

Durch das Ausführen des CLI-Befehls repairqueue werden möglicherweise nicht alle Probleme oder Beschädigungen in der Arbeitswarteschlange behoben. Dieses Dienstprogramm bemüht sich nach Kräften, die Arbeitswarteschlange zu reparieren.

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

Wenn die Reparaturwarteschlange ausgeführt wird, fordert der erste Prozesslauf einmal die Berechtigung zum Fortfahren und Ausführen der Reparatur an:

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, bekannter Fehler (CSCuz28415): "Waiting for the queue to mount: Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory"

Nach Abschluss des Reparaturvorgangs wird die Arbeitswarteschlange repariert. Die Appliance behält jedoch einen alten Prüfpunkt der vorherigen Arbeitswarteschlange bei. Um mit dem Schreiben eines neuen Prüfpunkts für die Arbeitswarteschlangen-Verarbeitung fortzufahren, führen Sie die Reparaturwarteschlange erneut aus, und geben Sie den Befehl 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üfung

Sobald die Reparaturwarteschlange abgeschlossen ist, führen Sie die folgenden Schritte aus, um zu überprüfen, ob die Arbeitswarteschlange wieder online ist und die Appliance E-Mails verarbeitet:

1. Überprüfen Sie den Systemstatus, indem Sie den Befehl status detail in der CLI oder Monitor > System Status in der GUI ausführen. Die Appliance sollte den Systemstatus Online aufweisen.  
2. Überprüfen Sie die Mail-Protokolle auf der Appliance, um sicherzustellen, dass die Mail wie erwartet verarbeitet wird.  Dies kann über die CLI durch Ausführen des Befehls tail mail_logs erreicht werden.
3. Führen Sie den Befehl workqueue aus der CLI aus, und wählen Sie die Option Rate mit der Standardgeschwindigkeit von 10 Sekunden aus. Solange die Appliance eingehende und/oder ausgehende E-Mails verarbeitet, sollte die Rate für alle 10 Sekunden für das Verhältnis "Ein/Aus" ziemlich gleich sein. Appliances mit einer großen ausstehenden Verarbeitungswarteschlange können einige Zeit benötigen, um die Arbeitswarteschlange zu leeren und die normale Verarbeitung wieder aufzunehmen.

Häufig gestellte Fragen

Was geschieht, wenn meine ESA nicht 11.0.0-264 oder neuer läuft?

Kunden mit Appliances, auf denen ältere Versionen von AsyncOS ausgeführt werden und die nicht über die Befehlszeilenoption Reparaturwarteschlange mit ausgeblendeter CLI verfügen, sollten ein Support-Ticket erstellen, um von einem Cisco Support-Techniker Unterstützung zu erhalten.  Ein Support-Tunnel muss geöffnet und für den Cisco Support verfügbar sein, um auf die Appliance zuzugreifen und den Reparaturwarteschlangen-Prozess auszuführen.  Wenden Sie sich an den Cisco Support, um ein aktives Support-Ticket zu erstellen.

Bedeutet die Arbeitswarteschlange ''Korruption'' einen E-Mail-Verlust?

In den meisten Fällen ist Korruption nicht gleichbedeutend mit E-Mail-Verlust. Die Warteschlange ist aufgrund von Metadaten, die sich auf die Nachrichtenverarbeitung beziehen und nicht mehr auf der Appliance vorhanden sind, beschädigt. Dies ist eine buchhalterische Verarbeitung zwischen Warteschlange und Berichterstellung, Nachrichtenverfolgung usw. Durch das Ausführen der Reparaturwarteschlange werden die ESA-Metadaten wiederhergestellt, und alle fehlerhaften Meldungen zwischen den Services und der Verarbeitung werden bereinigt.

Gibt es Auswirkungen auf die Beschädigung von Arbeitswarteschlangen?

Die ESA kann möglicherweise für eine lange Zeit auf einer beschädigten Warteschlange ausgeführt werden, und die meisten Nachrichten können fehlerfrei verarbeitet werden, aber die Appliance kann träge erscheinen, oder bestimmte Nachrichten werden nie gelöscht, wie durch die "älteste Nachricht" im Status-Befehl angegeben wird - wesentlich älter als die Bounce-Konfiguration zulassen sollte. Wenn AsyncOS tatsächlich mit einer beschädigten Warteschlange neu gestartet wird, kann die Warteschlange möglicherweise nicht bereitgestellt werden. Die Beschädigung kann vor einiger Zeit aufgetreten sein und scheint bis zum Neustart der Appliance in Ordnung zu sein. An diesem Punkt kann die Warteschlange nicht bereitgestellt werden.

Was verursacht eine Beschädigung der Warteschlange?

Die zwei häufigsten Ursachen für 'Warteschlangenbeschädigung' sind:

1. Unerwartete Neustarts der Appliance. Stromunterbrechungen oder das Herunterhalten des Betriebsschalters führen zu einem unzulässigen Herunterfahren und können die Warteschlange beschädigen, je nachdem, welche Backend-Prozesse zu diesem Zeitpunkt ausgeführt wurden. Die Appliance kann sich erholen, und die Warteschlange ist möglicherweise beschädigt oder kann beim Neustart nicht gemountet werden. Wenn dies der Fall ist, erhalten ESA-Administratoren beim Ausführen des Status über die CLI Warnmeldungen wie "queue not mounted" und/oder "daemon not response".
   
   

   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 wird wahrscheinlich durch eine fehlerhafte Konfiguration des Listeners und/oder der Mail Flow-Richtlinien verursacht, die in der Regel bei zu vielen zulässigen eingehenden Verbindungen/Injektionen auftritt. Cisco empfiehlt, die Konfiguration Ihres Listeners auf die maximale Anzahl eingehender Verbindungen zu überprüfen. Cisco empfiehlt, diesen Wert auf 300 einzustellen.

Wie viel Zeit sollte das Reparaturskript in Anspruch nehmen?

Die Reparatur der Arbeitswarteschlange kann zwischen 10 Sekunden und mehreren Stunden dauern, je nach Zustand der ESA und der Anzahl der Nachrichten, die derzeit über eine aktive Arbeitswarteschlange verarbeitet werden. Eine Reparatur der Arbeitswarteschlange auf einer einfachen Appliance mit vollen Warteschlangen zum Zeitpunkt der Beschädigung kann mehrere Stunden dauern.

Was passiert, wenn die Reparaturwarteschlange nicht ausgeführt werden kann oder nicht vollständig ist?

In bestimmten Situationen (z. B. bei einer übervollen Warteschlange auf einer Appliance) kann die Reparaturwarteschlange nicht abgeschlossen werden. Wenn die Reparaturwarteschlange nach 4 Stunden nicht fertig gestellt wird, ist die Warteschlange höchstwahrscheinlich nicht reparierbar, und der einzige Rückgriff besteht darin, eine neue Warteschlange zu erstellen, indem der ausgeblendete CLI-Befehl resetqueue ausgeführt wird. Bei Problemen mit erweiterten Funktionen wenden Sie sich an den Cisco Support, um ein aktives Support-Ticket zu erstellen, und lassen Sie sich von einem Cisco Support-Mitarbeiter beraten.

Zugehörige Informationen

• Cisco Email Security Appliance - Benutzerhandbücher
• Cisco Email Security Appliance - Befehlsreferenzen
• Verwendung des Befehls Rücksetzwarteschlange
• In welcher Reihenfolge wird die Verarbeitung in der Arbeitswarteschlange durchgeführt? Was ist die Arbeitswarteschlangen-Pipeline?
• Technischer Support und Dokumentation für Cisco Systeme