소개
이 문서에서는 숨겨진 CLI 명령 복구 대기열의 사용 및 Cisco ESA(Email Security Appliance)의 CLI에서 명령을 실행할 때 수행되는 작업에 대해 설명합니다.
사전 요구 사항
요구 사항
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
- 시스템 용량, 시스템 모니터링, 시스템 상태 및 ESA 작업 대기열을 통한 전반적인 메시지 처리
- 전반적인 ESA 관리.
참고: 자세한 내용은 ESA 사용 설명서 또는 ESA GUI의 온라인 도움말을 참조하십시오.
사용되는 구성 요소
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
- ESA, AsyncOS 11.0.0-264 이상을 실행하는 모든 하드웨어 및 가상 어플라이언스
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
문제
repairqueue 명령을 실행하는 이유:
- 작업 대기열이 마운트되지 않았음을 나타내는 동안 오류가 발생했습니다. 이는 일반적으로 어플라이언스의 부적절한 전력 주기 또는 재부팅 후 대기열 손상 결과입니다.
- 알려진 결함의 해결 방법으로 이 문제가 필요합니다(예: CSCuw22284 - Hermes 충돌 또는 부적절한 종료 후 이메일 대기열이 손상됨).
- "gcq.py"를 참조하거나 큐 관리 하위 시스템을 참조하는 애플리케이션 오류
- Status Detail 또는 workqueue > rate는 음수를 보고합니다.
- 상태 또는 상태 세부 정보는 바운스 프로필보다 오래된 "가장 오래된 메시지"를 보고합니다. 이에 대한 기본값은 3일입니다. bounceconfig > edit에서 확인하고 Default 프로필을 선택할 수 있습니다. "메시지가 하드 바운스되기 전에 대기열에 머물 수 있는 최대 시간(초)을 입력하십시오." 줄을 찾습니다. 기본값은 259200초 또는 3일입니다. 가상 전달 도메인, the.<destination>.queue(예: the.cpq.queue, the.euq.queue, the.cpq.release.host)는 제외됩니다.
repairqueue 명령을 실행하지 않는 이유:
- 작업 대기열 처리 속도가 느리면 큐 복구를 실행할 수 없습니다. 관리자는 느린 작업 대기열 처리를 대기열 손상으로 혼동하는 경우가 많습니다. 느린 작업 대기열은 일반적으로 시스템 리소스의 서비스 초과 사용률로 인해 동일한 메시지를 반복적으로 처리하는 데 기인합니다. 이러한 반복되는 처리 시나리오는 단순히 repairqueue를 실행하여 복구되지 않는 경우가 많습니다. 처리 중에 메시지가 "중지"될 서비스에 대한 추가 트러블슈팅이 필요합니다.
명령 repairqueue 사용
CLI 명령 repairqueue를 실행해도 모든 workqueue 문제 또는 손상이 복구되지는 않을 수 있습니다. 이 유틸리티는 작업 대기열을 복구하기 위해 최선의 노력을 다합니다.
경고: 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): "큐가 마운트되기를 기다리는 중: /dev/ipmi0 또는 /dev/ipmi/0 또는 /dev/ipmidev/0에서 장치를 열 수 없습니다. 해당 파일 또는 디렉터리가 없습니다."
복구 프로세스가 완료되면 작업 큐가 복구되지만 어플라이언스는 여전히 이전 작업 큐의 이전 체크포인트를 유지합니다. 작업 대기열 처리를 위해 새 검사점 작성을 재개하려면 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
다음을 확인합니다.
repairqueue가 완료되면 작업 큐가 다시 온라인 상태이고 어플라이언스가 메일을 처리 중인지 확인하려면 다음을 수행하십시오.
- CLI에서 status detail 명령을 실행하거나 GUI에서 Monitor > System Status를 실행하여 시스템 상태를 확인합니다. 어플라이언스는 시스템 상태를 Online으로 반영해야 합니다.
- 어플라이언스의 메일 로그를 검토하여 예상대로 메일 처리를 확인합니다. CLI에서 tail mail_logs 명령을 실행하여 이 작업을 수행할 수 있습니다.
- CLI에서 workqueue 명령을 실행하고 기본 속도 10초의 Rate 옵션을 선택합니다. 어플라이언스가 메일 수신 및/또는 메일 아웃을 처리하는 한, 각 10초의 속도는 "수신/발신" 비율과 상당히 같아야 합니다. 대기 중인 처리 작업 대기열이 큰 어플라이언스는 작업 대기열을 비우고 일반 처리를 재개하는 데 다소 시간이 걸릴 수 있습니다.
FAQ
ESA에서 11.0.0-264 이상을 실행하고 있지 않으면 어떻게 합니까?
이전 버전의 AsyncOS를 실행하는 어플라이언스에서 repairqueue hidden CLI 명령 옵션이 없는 고객은 지원 케이스를 열어 Cisco 지원 엔지니어의 지원을 받아야 합니다. Cisco Support에서 어플라이언스에 액세스하고 복구 대기열 프로세스를 실행하려면 지원 터널을 열고 사용할 수 있어야 합니다. 활성 지원 케이스를 열려면 Cisco 지원에 문의하십시오.
Workqueue가 ' 손상 ' 되면 메일이 손실됩니까?
대부분의 경우 부패는 메일 손실과 같지 않습니다. 더 이상 어플라이언스에 없는 메시지 처리와 관련된 메타 데이터로 인해 큐가 손상되었습니다. 대기열과 보고, 메시지 추적 등 간의 부기 처리입니다. repairqueue를 실행하면 ESA 메타데이터가 다시 작성되고 서비스와 처리 사이의 모든 잘못된 보고가 정리됩니다.
작업 대기열 손상에 대한 영향이 있습니까?
ESA는 손상된 대기열에서 오랫동안 실행될 수 있으며 대부분의 메시지가 정상적으로 처리될 수 있지만 어플라이언스가 느리게 나타날 수 있습니다. 또는 status 명령에서 "가장 오래된 메시지"로 표시된 것처럼 특정 메시지가 지워지지 않을 수 있습니다. bounceconfig가 허용해야 하는 것보다 훨씬 오래된 메시지입니다. 손상된 대기열을 사용하여 AsyncOS를 실제로 다시 시작하면 대기열을 마운트하거나 마운트하지 못할 수 있습니다. 손상이 오래전에 발생했을 수 있으며 어플라이언스를 다시 시작할 때까지 문제가 없는 것 같습니다. 이 시점에서는 큐를 마운트할 수 없습니다.
대기열 손상의 원인은?
'대기열 손상'의 가장 일반적인 두 가지 원인은 다음과 같습니다.
- 어플라이언스가 예기치 않게 재부팅됩니다. 전원 중단 또는 전원 단추를 누르면 종료가 제대로 수행되지 않으며, 당시 백엔드 프로세스가 어떤 작업을 수행했는지에 따라 큐가 손상될 수 있습니다. 어플라이언스가 복구되고 큐가 손상된 상태로 복구되거나 재부팅 시 큐를 마운트할 수 없습니다. 이 값이 true이면 ESA 관리자가 CLI에서 상태를 실행할 때 "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 사용입니다. 이는 대개 너무 많은 인바운드 연결/주입이 허용된 상태에서 나타나는 리스너 및/또는 메일 플로우 정책의 잘못된 컨피그레이션으로 인해 발생할 수 있습니다. Cisco에서는 listenerconfig에서 최대 인바운드 연결을 검토하는 것을 권장합니다. 이 값은 300으로 설정하는 것이 좋습니다.
복구 스크립트를 완료하는 데 얼마나 걸립니까?
ESA의 상태 및 활성 작업 대기열을 통해 현재 처리 중인 메시지 수에 따라 작업 대기열을 복구하는 데 10초에서 몇 시간이 걸릴 수 있습니다. 손상된 시점에 대기열이 가득 찬 로우엔드 어플라이언스의 작업 대기열 수리는 몇 시간이 걸릴 수 있습니다.
Repairqueue를 실행할 수 없거나 완료할 수 없는 경우 어떻게 됩니까?
특정 상황에서(예: 어플라이언스의 오버풀 대기열) 수리 대기열을 완료할 수 없습니다. 4시간 후에 repairqueue가 완료되지 않으면 대기열은 대부분 복구할 수 없으며, 유일한 방법은 숨겨진 CLI 명령 resetqueue를 실행하여 새 대기열을 만드는 것입니다. 고급 문제는 Cisco 지원에 문의하여 활성 지원 케이스를 열고 Cisco 지원 지원을 받으십시오.
관련 정보
피드백