ESA에서 Repairqueue 명령을 사용하여 WorkQueue 문제 해결

소개

이 문서에서는 Cisco ESA(Email Security Appliance)에서 숨겨진 CLI 명령 repairqueue의 사용 및 대기열 복구를 검증하는 방법에 대해 설명합니다.

문제

repairqueue 명령을 실행하는 이유:

• 작업 대기열이 마운트되지 않았음을 나타내는 동안 오류가 발생했습니다. 이는 일반적으로 부적절한 전원 주기 또는 어플라이언스 재부팅 후 대기열이 손상될 때 발생합니다.
• 알려진 결함의 해결 방법으로 이 명령이 필요할 수 있습니다(예: Cisco 버그 ID CSCuw2284 - 메일 처리 서비스 크래시 또는 부적절한 종료 후 이메일 큐가 손상됨).
• 애플리케이션 결함(예: gcq.py 또는 대기열 관리 하위 시스템 참조)
• Status Detail 또는 workqueue > rate report 음수.

• Status(상태) 또는 Status Detail(상태 세부사항)은 구성된 반송 프로필 임계값을 초과하는 Oldest Message(가장 오래된 메시지) 값을 보고합니다.

  • 기본 임계값: 259200초(3일)
  • 임계값을 확인하려면 bounceconfig > edit를 입력한 다음 Default profile을 선택합니다. 회선을 찾습니다. 메시지가 하드 반송되기 전에 대기열에 머물 수 있는 최대 시간(초)을 입력하십시오.

repairqueue 명령을 실행하지 않는 이유:

• 작업 대기열 처리 속도가 느리면 큐 복구를 실행할 수 없습니다. 관리자는 느린 작업 대기열 처리와 대기열 손상을 혼동하는 경우가 많습니다. 느린 작업 대기열은 일반적으로 서비스가 시스템 리소스를 과도하게 활용하기 때문에 동일한 메시지 또는 여러 메시지를 반복적으로 처리했기 때문입니다. 이러한 반복 처리 시나리오는 단순히 repairqueue를 실행하여 복구되지 않는 경우가 많습니다. 영향을 받는 서비스에 대한 추가 트러블슈팅이 필요합니다.

환경

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

• ESA, AsyncOS 11.0.0-264 이상을 실행하는 모든 하드웨어 및 가상 어플라이언스

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 라이브 네트워크에서 계속하기 전에 각 명령의 잠재적 영향을 확인합니다.

Cisco에서는 다음 항목에 대한 지식을 권장합니다.

• 시스템 용량, 시스템 모니터링, 시스템 상태 및 ESA 작업 대기열을 통한 전반적인 메시지 처리
• 전반적인 ESA 관리.

참고: 자세한 내용은 ESA 사용 설명서 또는 ESA GUI 온라인 도움말을 참조하십시오.

해결

CLI 명령 repairqueue는 모든 작업 대기열 문제 또는 손상을 복구하지 않습니다. 유틸리티가 작업 대기열의 최선형 복구를 시도합니다.

1. 실행 상태 세부 정보를 확인하고 작업 대기열에 음수 값 또는 대기열 마운트 문제와 같이 Issue에 이미 설명된 증상이 표시되는지 확인합니다.
2. workqueue를 실행하고 Rate(속도) 옵션을 선택합니다. 보고된 요금이 트리거 조건을 지원하는지 확인합니다.
3. 상태 또는 상태 세부사항에서 가장 오래된 메시지 값을 구성된 반송 프로필 임계값과 비교합니다. 값이 임계값을 초과할 경우 복구 절차를 계속 진행합니다.

경고: repairqueue를 실행하면 작업 대기열의 활성 메시지가 손실될 수 있습니다.

4. repairqueue를 실행합니다. 첫 번째 프로세스에서는 복구를 진행하고 실행하기 위해 권한 프롬프트를 한 번 실행합니다.

   esa.example.com> repairqueue
   
   Do you want to repair or clean the queue?
   1. Repair.
   2. Clean.
   [1]> 1
   
   The mail flow will be stopped throughout 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
   ...
   <<>>
   ...
   done
   Repair succeeded
   Starting Hermes
   Hermes Started
   
   Log into the system and verify the status of the system.

   참고: 가상 ESA에서 "Waiting for the queue to mount: /dev/ipmi0 또는 /dev/ipmi/0 또는 /dev/ipmidev/0에서 디바이스를 열 수 없습니다. 알려진 결함 Cisco 버그 ID CSCuz28415에 문서화된 해당 파일 또는 디렉토리가 없습니다.

5. 복구 프로세스가 완료되고 작업 대기열이 복구되면 어플라이언스는 이전 작업 대기열의 이전 체크포인트를 유지합니다. 작업 대기열 처리를 위해 새 검사점 쓰기를 다시 시작하려면 repairqueue를 다시 실행하고 Clean 명령을 입력합니다.

   esa.example.com> repairqueue
   
   Do you want to repair or clean the queue?
   1. Repair.
   2. Clean.
   [1]> 2
   
   The mail flow will be stopped throughout the repair/cleanup process
   WARNING:
   There is a backup found this may be the only backup.
   This will 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

6. CLI에서 status detail 명령을 실행하거나 GUI에서 Monitor > System Status를 선택합니다. 시스템 상태가 Online(온라인)인지 확인합니다.
7. 메일 로그를 검토하여 메일 처리를 확인합니다. CLI에서 tail mail_logs 명령을 실행합니다.
8. workqueue 명령을 실행하고 Rate(속도) 옵션(기본값 10초)을 선택합니다. 수신 및 발신 비율이 현재 메일 흐름에 적합한지 확인합니다. 작업 대기열에 큰 백로그가 있는 경우 드레이닝하는 데 시간이 걸릴 수 있습니다.

원인

작업 대기열 손상의 일반적인 원인은 다음과 같습니다.

1. 예기치 않은 재부팅 또는 부적절한 종료(예: 정전) 이때 실행 중인 백엔드 프로세스에 따라 큐가 손상되거나 재부팅 후 마운트에 실패할 수 있습니다. 이 경우 CLI는 다음과 같은 오류를 보고할 수 있습니다.

   esa.example.com> status
   
   Enter "status detail" for more information.
   
   Couldn't obtain mail stats - my.esa: The daemon is not responding.

   esa.example.com> status
   
   Enter "status detail" for more information.
   
   Couldn't obtain mail stats - the queue is not mounted

2. 과도한 메모리(RAM) 사용률. 이는 일반적으로 너무 많은 인바운드 연결 또는 삽입을 허용하는 리스너 또는 메일 플로우 정책 설정과 관련됩니다. listenerconfig를 검토하고 최대 인바운드 연결 값이 구축에 적합한지 확인합니다.

FAQ

ESA에서 11.0.0-264 이상을 실행하고 있지 않으면 어떻게 합니까?

repairqueue hidden CLI 명령 옵션이 없는 이전 버전의 AsyncOS를 실행하는 어플라이언스가 있는 사용자는 Cisco 지원 엔지니어가 절차를 지원하도록 지원 케이스를 열 수 있습니다. Cisco Support에서 어플라이언스에 액세스하고 repairqueue 명령을 실행하려면 지원 터널을 열고 사용할 수 있어야 합니다. 활성 지원 사례를 열려면 Cisco 지원에 문의하십시오.

작업 대기열 손상은 메일 손실을 의미합니까?

대부분의 경우 부패는 메일 손실과 같지 않습니다. 더 이상 어플라이언스에 없는 메시지 처리와 관련된 메타데이터로 인해 큐가 손상되었습니다. 대기열, 보고 및 메시지 추적 간의 처리를 위한 기록 보존입니다. repairqueue를 실행하면 ESA 메타데이터가 리빌드되고 서비스와 처리 간의 잘못된 보고가 정리됩니다.

작업 대기열 손상에 대한 영향이 있습니까?

ESA는 손상된 대기열에서 오랫동안 실행될 수 있으며 대부분의 메시지는 계속 처리됩니다. 그러나 status 명령에서 Oldest Message 값(bounceconfig 임계값보다 크게 오래됨)으로 표시된 것처럼 어플라이언스가 느리게 표시되거나 일부 메시지가 지워지지 않을 수 있습니다. 손상된 대기열로 AsyncOS를 다시 시작하면 대기열을 마운트하지 못할 수 있습니다. 이 손상은 더 일찍 발생할 수 있으며 어플라이언스가 다시 시작될 때까지 발견되지 않을 수 있으며, 이 때 대기열이 마운트되지 않습니다.

복구 스크립트를 완료하는 데 얼마나 걸릴 수 있습니까?

ESA의 상태 및 활성 작업 대기열을 통해 현재 처리 중인 메시지 수에 따라 작업 대기열을 복구하는 데 10초에서 몇 시간이 걸릴 수 있습니다. 손상된 시점에 대기열이 가득 찬 로우엔드 어플라이언스의 작업 대기열 수리는 몇 시간이 걸릴 수 있습니다.

Repairqueue를 실행할 수 없거나 완료할 수 없는 경우 어떻게 됩니까?

특정 상황(예: 어플라이언스의 오버풀 대기열)에서 repairqueue를 완료할 수 없습니다. repairqueue가 4시간 후에 완료되지 않으면, 해당 대기열은 대부분 복구할 수 없으며 새 대기열을 작성할 수밖에 없습니다. 이러한 고급 문제에 대해서는 Cisco 지원에 문의하여 활성 지원 케이스를 열고 Cisco 지원 지원을 받으십시오.

관련 콘텐츠

• Cisco Email Security Appliance 최종 사용자 가이드
• Cisco Email Security Appliance 명령 참조
• 작업 대기열의 처리 순서는 어떻게 됩니까? 작업 대기열 파이프라인은 무엇입니까?
• 기술 지원 및 문서 − Cisco Systems

개정 이력

개정	게시 날짜	의견
2.0	02-Oct-2026	재인증
1.0	10-Aug-2017	최초 릴리스