はじめに
このドキュメントでは、隠しCLIコマンドrepairqueueの使用方法とこのコマンドがCisco Eメールセキュリティアプライアンス(ESA)のCLIから発行された場合に発生するアクションについて説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- ESAワークキューを介したシステムのキャパシティ、システムのモニタリング、システムの健全性、およびメッセージの全体的な処理。
- ESA全体の管理。
注：詳細については、ESAユーザガイドまたはESA GUIのオンラインヘルプを参照してください。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- ESA、AsyncOS 11.0.0-264以降を実行するすべてのハードウェアおよび仮想アプライアンス
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
問題
repairqueueコマンドを実行する理由：
- ワークキューがマウントされていないことを示すエラー。これは通常、不適切な電源の再投入後またはアプライアンスのリブート後にキューが破損した場合に発生します。
- 既知の不具合では、回避策としてこれが必要です(CSCuw22284 - hermesのクラッシュまたは不適切なシャットダウン後に電子メールキューが破損するなど)。
- アプリケーション障害（「gcq.py」を参照する障害やキュー管理サブシステム）。
- Status Detailまたはworkqueue > rateが負の数を報告しています。
- StatusまたはStatus Detailで、バウンスプロファイルより古い「最も古いメッセージ」がレポートされます。デフォルト値は3日です。bounceconfig > editの順に選択して、デフォルトプロファイルを確認できます。「Please enter the maximum number of seconds of message may stay in the queue before being hard bounced」という行を探します。この行は、デフォルトでは259200秒（3日）です。これには、.cpq.queue、.euq.queue、.cpq.release.hostなどの仮想配信ドメイン、.<宛先>.queueは含まれません。
repairqueueコマンドを実行しない理由：
- キューの修復を実行する理由として、ワークキューの処理の遅延は有効ではありません。管理者は、低速のワークキュー処理をキューの破損と混同することがよくあります。ワークキューの遅れは通常、システムリソースのサービス過剰使用による同じメッセージの繰り返し処理に起因します。このような繰り返される処理シナリオは、単にrepairqueueを実行して修復するものではないことがよくあります。処理中にメッセージが「ハング」するサービスのトラブルシューティングをさらに進める必要があります。
コマンドrepairqueueの使用
CLIコマンドrepairqueueを実行しても、すべてのワークキューの問題または破損が修復されるとは限りません。このユーティリティは、ワークキューを修復するためにベストエフォートを実行します。
警告: ESA管理者は、アクティブメッセージがワークキューから失われる可能性があることに注意する必要があります。
repairqueueを実行する場合、最初のプロセス実行では、続行して修復を実行するために一度許可を求めるプロンプトが表示されます。
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.
注：仮想ESAでは、次の出力を無視します。既知の不具合(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」
修復プロセスが完了すると、ワークキューは修復されますが、アプライアンスは以前のワークキューの古いチェックポイントを保持します。workqueue処理のための新しいチェックポイントの書き込みを再開するには、repairqueueを再度実行し、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
確認
リペアキューが完了したら、次の各操作を実行して、ワークキューがオンラインに戻ってアプライアンスでメールが処理されていることを確認します。
- CLIからstatus detailコマンドを実行するか、GUIからMonitor > System Statusを実行して、システムステータスを確認します。アプライアンスにはOnlineのシステムステータスが反映されている必要があります。
- アプライアンスのメールログを確認し、メールが期待どおりに処理されていることを確認します。 これは、CLIからtail mail_logsコマンドを実行して実行できます。
- CLIからworkqueueコマンドを実行し、デフォルトレートの10秒でRateオプションを選択します。アプライアンスがメールの受信または送信を処理している限り、10秒ごとのレートは「受信/送信」の比率に相当します。処理待ちのワークキューが大きいアプライアンスでは、ワークキューを空にして通常の処理を再開するのに時間がかかる場合があります。
FAQ
ESAが11.0.0-264以降を実行していない場合はどうすればいいですか。
隠しCLIコマンドrepairqueueオプションが付いていない、古いバージョンのAsyncOSを実行しているアプライアンスを使用しているお客様は、シスコサポートエンジニアによる支援を得るためにサポートケースをオープンする必要があります。 サポートトンネルがオープンされ、シスコサポートがアプライアンスにアクセスして修復キュープロセスを実行するために使用できる必要があります。 アクティブなサポートケースをオープンするには、シスコサポートにお問い合わせください。
ワークキューの「破損」はメールの損失を意味しますか。
ほとんどの場合、破損はメールの損失と同じではありません。メッセージ処理に関連するメタデータがアプライアンス上にないため、キューが破損しています。これは、キューとレポート、メッセージトラッキングなどの間のブックキーピング処理です。repairqueueを実行すると、ESAメタデータが再構築され、サービスと処理の間の誤った報告が消去されます。
ワークキューの破損に対する影響はありますか。
statusコマンドの「Oldest Message」で示されるように、ESAは破損したキューで長時間実行でき、ほとんどのメッセージは正常に処理されますが、アプライアンスの反応が遅く見える場合や特定のメッセージが決してクリアされない場合があります。これは、bounceconfigで許可されるべきものより大幅に古いメッセージです。AsyncOSが実際に破損したキューで再起動された場合、そのキューはマウントできる場合とできない場合があります。この破損は少し前に発生した可能性があり、アプライアンスが再起動されるまでは問題ないように見えますが、再起動した時点でキューをマウントできません。
キューの破損の原因
「キューの破損」の最も一般的な原因は次の2つです。
- アプライアンスの予期しないリブート。電源の中断や電源ボタンの押し続けにより、不適切なシャットダウンが発生し、その時点でバックエンドプロセスが何を行っているかに応じて、キューが破損する可能性があります。アプライアンスが復旧してキューが破損した状態に戻る場合や、再起動時にキューをマウントできない場合があります。これが当てはまる場合、ESA管理者は、CLIからstatusを実行したときに「queue not mounted」アラートまたは「daemon not responding」あるいはその両方を確認できます。
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
- アプライアンスによるアウトオブバウンドRAM使用率。 これは、リスナーやメールフローポリシーの設定ミスが原因である可能性が高く、通常は許可される着信接続や着信拒否が多すぎます。最大着信接続数については、listenerconfigを確認することをお勧めします。シスコでは、300に設定することを推奨しています。
修復スクリプトの完了にはどのくらいの時間がかかりますか？
ワークキューの修復には、ESAの状態やアクティブなワークキューで現在処理中のメッセージの数によっては、10秒から数時間かかる場合があります。破損時にフルキューを使用するローエンドのアプライアンスでのワークキューの修復には、数時間かかる場合があります。
リペアキューを実行できない場合や完了できない場合はどうなりますか。
特定の状況（アプライアンスでのオーバーフルキューなど）では、リペアキューを完了できません。4時間が経過してもrepairqueueが完了しない場合、キューは修復不可能である可能性が高く、唯一の手段は、隠しコマンドresetqueueを実行して新しいキューを作成することです。詳細な問題については、シスコサポートに連絡してアクティブなサポートケースをオープンし、シスコサポートによるサポートを受けてください。
関連情報
フィードバック