Exchange 콘텐츠 인덱스 다시 작성 기준 설정(1부)

최초 문서 게시일: 2012년 6월 26일 화요일

대부분의 Exchange 관리자들이 Exchange 콘텐츠 인덱싱 과 관련하여 의심되는 문제를 해결할 때 대개 가장 먼저 수행하는 작업은 해당하는 사서함 데이터베이스의 콘텐츠 인덱스 파일을 수동으로 또는 \Exchange Server\Scripts 디렉터리에 있는 ResetSearchIndex.ps1 스크립트를 사용하여 다시 작성하는 것입니다. 개인적으로 수 년간 많은 Exchange 관리자와 함께 작업을 해 왔는데, 이러한 관리자들은 매년 여러 시기에 또는 마이그레이션 프로젝트와 같은 특정 프로젝트 내의 다양한 중요 시점에 도달하면 검색 인덱스를 미리 다시 작성해 놓곤 했습니다.

그러나 인덱스를 다시 설정하는 이유에 관계없이 대부분의 관리자는 해당하는 경우가 발생하거나 요청을 받는 경우 이 프로세스의 전체 소요 시간을 현실적으로 예측하지 못합니다. 이러한 시간을 정확하게 예측하지 못하는 경우의 부정적인 결과는 조직마다 다릅니다. 최종 사용자 생산성 저하와 지원 센터로 전달되는 문제 수 증가를 이유로 근무일 중에는 사용자가 서버 사이트 인덱스를 사용하지 못하도록 하는 IT 부서도 있습니다. 운영 측면에서 볼 때 다시 작성 시간을 예측하지 못하는 경우 Exchange 관리자가 다시 작성 프로세스 자체 내에서 발생할 수 있는 문제에 대한 알림을 받지 못할 수도 있습니다. 어떤 이유에서든 프로세스 소요 시간을 적절하게 파악하는 것은 중요합니다.

솔직히 현재 사용 가능한 Exchange 콘텐츠 인덱스를 다시 작성하는 데 걸리는 시간 또는 목표 시간에 대한 정보는 거의 없다고 해도 과언이 아닙니다. 표면상의 이유는 실제 다시 작성 시간이 항상 변하기 때문이지만, 실제로는 다양한 요인이 다시 작성 속도와 완료 시간에 영향을 줍니다. 그 중에서도 중요한 요인은 다음과 같습니다.

• Exchange 사서함 데이터베이스가 홈으로 지정된 최종 사용자 사서함의 총 수 변동
• Exchange 사서함 데이터베이스에 포함된 사서함 크기 변동
• Exchange 사서함 데이터베이스가 홈으로 지정된 사용자 사서함 간의 항목 수 변동
• 동시 다시 작성을 수행할 때 Exchange 사서함 데이터베이스 간의 항목 수 변동
• Exchange 사서함 데이터베이스 내의 항목 크기 변동
• Exchange 사서함 데이터베이스 내의 메일 첨부 파일 수와 크기 변동
• Exchange 사서함 서버에서 사용하도록 설정된 IFilter(다양한 파일 형식을 인덱싱할 수 있도록 함)의 유형과 수
• 크롤링을 수행하는 사서함 서버의 전반적인 시스템 리소스 사용률(예: 제한)
• 기타

Microsoft에서는 회사 내 구현과 다양한 Office-365 오퍼링에서 모두 저와 동료인 Anatoly Girko가 개발한 검색 다시 작성 프레임워크 를 활용합니다. 이 프레임워크는 원래 내부 운영 직원들이 콘텐츠 인덱스 다시 작성을 수행할 때 사용할 수 있는 포괄적인 유효성 검사 단계와 진행률 표시기 집합을 제공하기 위해 설계되었습니다. 이러한 기술은 정상적인 완료를 위해 전체 다시 작성 프로세스의 여러 중요 시점에서 사용됩니다.

이 프레임워크가 발전해 감에 따라, 모든 다시 작성 작업에 대한 처리량 메트릭 기록을 추적 및 저장하는 데 사용할 수 있는 기능을 더 추가하기로 결정했습니다. 이러한 데이터 컬렉션이 확장되고 후속 추세 데이터가 생성되면 지정된 다시 작성 작업의 소요 시간을 훨씬 더 적절하고 정확하게 예측할 수 있음을 확인할 수 있었습니다. 그리고 궁극적으로는 이를 통해 운영 팀이 최종 사용자 고객층의 작업 중단을 최소화할 수 있도록 다시 작성을 예약할 시기를 적절하게 결정할 수 있었습니다. 이 프레임워크는 시작 당시부터 Microsoft에서 지원하는 다양한 환경 내의 수많은 콘텐츠 인덱스에 대한 다시 작성 작업을 감독하는 데 사용되어 왔습니다.

이 문서 시리즈에서는 관심이 있는 독자들이 필요한 경우 유사한 방법을 환경에 적용할 수 있도록 이 " 다시 작성 프레임워크 "를 소개하고자 합니다. 이 프로세스를 지원하기 위해 작성한 도구 집합을 비롯하여 각 프레임워크 단계에 대해 자세한 설명이 제공됩니다. 이 문서 시리즈의 끝 부분에서는 내부에서 확인된 콘텐츠 인덱싱 다시 작성 통계 및 현재까지의 결론이 상세하게 나와 있는 일련의 그래프와 표가 제공됩니다. 이전에 이 영역에서 통계를 추적한 적이 없는 고객의 경우 이 내용을 참조하면 유용할 것입니다. 이를 통해 작업 환경의 Exchange 콘텐츠 인덱스 다시 작성 시간을 보다 적절하게 예측할 수 있을 것입니다. 그와 관련하여 한 가지 짚고 넘어갈 점은, 모든 Exchange 환경은 고유하기 때문에 실제 다시 작성 메트릭은 Microsoft에서 확인하여 이 문서 시리즈에서 소개하는 다시 작성 속도와 크게 다를 수도 있다는 것입니다.

상세한 설명을 시작하기 전에 또 한 가지 참고 사항을 언급하자면, 이 문서 시리즈는 문제 해결 가이드가 아니라는 것입니다. 즉, 여기서는 직접 문제 해결 과정을 수행하여 문제에 대한 대응으로 또는 사전에 다시 작성을 수행하기로 결정했다고 가정합니다. 이 문서 시리즈에서 제공되는 모든 예제는 Exchange 2007을 중심으로 합니다. 2010 버전에 비해 2007에서 인덱스를 다시 작성할 가능성이 훨씬 크기 때문입니다. 2007과는 달리 2010에는 정상 상태의 중복 원본에서 콘텐츠 인덱스를 다시 시드하는 기능이 있으므로 다중 복사본 아키텍처에서는 전체 인덱스 다시 작성을 수행해야 하는 필요성이 거의 없습니다. 향후 몇 주간 Anatoly와 저는 Exchange 2010 버전 Content Index Rebuild Analyzer 스크립트의 사용법에 해당하는 예제가 누적되면 해당 스크립트 참조를 제공하는 보완 게시물을 공개할 예정입니다.

Index Rebuild Analyzer 스크립트

Microsoft 내부에서 콘텐츠 인덱스를 다시 작성할 때 기본적으로 사용하는 도구 집합은 IndexRebuildAnalyzer 스크립트입니다. 이 스크립트는 Anatoly와 제가 콘텐츠 인덱스 다시 작성 기준 설정 전용으로 작성한 것입니다. 앞에서도 언급했듯이, 이 스크립트에는 Exchange 2007 버전과 Exchange 2010 버전의 두 가지 버전이 있습니다. 통계를 올바르게 계산하려면 항상 인덱스를 다시 작성할 Exchange 사서함 데이터베이스 버전에 해당하는 스크립트를 사용하십시오. IndexRebuildAnalyzer 스크립트는 연산자로 전달되는 연산 모드에 따라 두 가지 유형의 메트릭을 생성하는데, 내부적으로는 이러한 메트릭을 "다시 작성 전 메트릭"과 "다시 작성 후 메트릭"으로 지칭하고 있습니다 . 모든 속성은 아래의 스크립트 참조 섹션에 설명되어 있습니다 .

이 스크립트는 기본적으로 콘텐츠 인덱스 다시 작성 작업을 추적하는 데 사용되지만, Exchange 관리자 는 " 사전 모드 "에서 이 스크립트를 사용하여 다양한 사서함 중심 용도(예: 전체 조직의 "사서함 수", "데이터베이스의 항목 수", "평균 메시지 크기" 등)에 대한 특정 PIT(지정 시간) 통계를 계산합니다. 예를 들어 비즈니스 요구 사항이나 필요에 따라 이 도구를 정기적으로 사용해야 하는 경우에는 이 스크립트가 사용자 추세 분석을 위한 추가 자료 및 기능을 제공할 수 있습니다.

스크립트 실행 전에 PowerShell 세션에서 -Help 매개 변수를 전달하면 E2K7_IndexRebuildAnalyzer.ps1 script(영문일 수 있음) 매개 변수와 사용법 예제를 확인할 수 있습니다.

아래 표에 각 매개 변수에 대한 내용이 간략하게 나와 있습니다.

데이터베이스 메트릭 헤더

다시 작성 전

위에 정의되어 있는 것처럼 스크립트의 "작동 모드"는 -PostRebuild 스위치 유무에 따라 결정됩니다. 다시 작성 전 메트릭을 생성하려는 경우에는 -PostRebuild 스위치를 사용하지 않습니다. 스크립트를 사전 모드에서 인스턴스화하면 다음 헤더가 해당 메트릭과 함께 제공됩니다.

다시 작성 후( -PostRebuild 매개 변수 사용)

-PostRebuild 스위치를 사용하는 경우 IndexRebuildAnalyzer는 콘텐츠 인덱스 다시 작성 작업에 대한 처리량 메트릭을 계산합니다. 이를 위해 응용 프로그램 이벤트 로그 를 구문 분석하여 사서함 서버의 각 사서함 데이터베이스에 대해 이벤트 ID 109로 표시되는 다시 작성 시작 시간과 이벤트 ID 110으로 표시되는 다시 작성 완료 시간을 모두 가져옵니다. 다시 작성 후 메트릭을 올바르게 계산하려면 해당하는 콘텐츠 인덱스가 다시 설정된 각 사서함 데이터베이스에 대해 전체 이벤트 ID 쌍이 이벤트 뷰어 에 있어야 합니다. 이벤트 ID 쌍을 사용할 수 없는 경우에는 스크립트가 통계를 계산할 수 없으며 "NoEventsFound" 문자열이 반환됩니다. 이 문자열이 반환되는 가장 일반적인 이유는 다음과 같습니다.

• 지정된 데이터베이스 또는 데이터베이스 집합에 대한 콘텐츠 인덱스 다시 작성 작업이 완료되지 않았습니다.
• 응용 프로그램 이벤트 로그 가 줄 바꿈되었거나 지워졌습니다. 이를 방지하려면 최대 로그 크기 값을 허용되는 가장 큰 값으로 설정하는 것이 좋습니다.
• "NoEventsFound"가 보고되는 사서함 데이터베이스의 경우 콘텐츠 인덱스가 최근에 다시 설정되지 않아 이벤트 로그에 이벤트 ID 쌍이 없는 것입니다. -CSVFile 옵션과 Excel을 사용하면 이러한 문자열을 결과 집합에서 쉽게 필터링하여 제외할 수 있습니다. 프레임워크의 5단계 를 필터링하는 방법 및 예제는 이후에 설명하겠습니다.

스크립트 실행을 위해 -PostRebuild 스위치를 전달할 때마다 모든 "다시 작성 전" 헤더 및 메트릭도 계산됩니다. -PostRebuild 스위치를 사용하는 경우 다음과 같은 헤더 및 메트릭이 추가로 포함됩니다.

결론

Exchange 2007 Index Rebuild Analyzer 스크립트는 여기(영문일 수 있음)서 다운로드할 수 있습니다.

이 문서 시리즈의 2부에서는 검색 다시 작성 프레임워크에 대해 설명하고 3부에서는 Microsoft 내에서 확인된 결과에 대해 설명할 예정입니다.

Eric Norberg
서비스 엔지니어
Office 365 전담

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Establishing Exchange Content Index Rebuild Baselines – Part 1을 참조하십시오.