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

發行項
07/23/2012

최초 문서 게시일: 2012년 6월 27일 수요일

이 문서 시리즈의 1부에서는 E2K7_IndexRebuildAnalyzer.ps1 스크립트(영문일 수 있음)에 대해 설명했습니다. 이 문서에서는 Anatoly Girko와 제가 개발한 검색 다시 작성 프레임워크에 대해 설명합니다. 이 프레임워크는 원래 내부 운영 직원들이 콘텐츠 인덱스 다시 작성을 수행할 때 사용할 수 있는 포괄적인 유효성 검사 단계 및 진행률 표시기 집합을 제공하기 위해 설계되었습니다.

1단계: 다시 작성 전 통계 수집

이 문서에서 설명하는 환경에서는 Exchange 사서함 데이터베이스 콘텐츠 인덱스 파일을 다시 작성하기로 결정할 때마다 운영자가 먼저 해당하는 저장소의 다시 작성 전 통계를 계산합니다. 이러한 통계는 항상 문서 작성용으로 CSV에 기록되며 최종적으로는 기록 데이터 컬렉션 집합에 삽입됩니다. 그러나 이전 게시물에서 설명한 것처럼 -CSVFile 매개 변수는 원하는 경우에만 사용하면 됩니다. -CSVFile 매개 변수를 전달하지 않으면 출력은 셸 콘솔 창에 기록됩니다. 가독성을 높이려면 콘솔의 Screen Buffer Size Width(화면 버퍼 크기 너비) 및 Window Size Width(창 크기 너비) 를 모두 조정하여 출력되는 여러 헤더 및 메트릭이 모두 포함되도록 해야 합니다. 이렇게 하면 콘솔 세션의 값을 보다 쉽게 읽을 수 있습니다. 그런 후에는 일반적으로 -AutoSize (-a) 매개 변수를 사용하여 Format-Table (ft) 에 출력을 "파이핑"합니다.

예제

콘솔 예제 :

.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 | ft -a

출력 :

CSV 예제:

.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 -CSVFile c:\ericnor\NA-1ERICNOR-1_PreRebuild.csv

출력 :

다음으로는 사전 통계를 기록 데이터 컬렉션과 비교하고 평균 다시 작성 완료 예상 시간을 계산합니다. 이때 사서함 데이터베이스가 위치한 지역과 해당하는 최종 사용자 사서함을 고려합니다. 저장소의 위치와 예상 완료 시간을 기준으로 하여 해당 저장소에 대한 사용자 작업이 최소인 날짜와 시간으로 다시 작성 작업을 예약합니다 .

2단계: 해당하는 사서함 데이터베이스의 콘텐츠 인덱스 다시 설정

다음으로 환경의 운영자가 전체 텍스트 인덱스 카탈로그를 다시 작성하는 방법에 설명되어 있는 기술 중 하나를 사용하여 사서함 데이터베이스의 콘텐츠 인덱스를 다시 설정합니다.

아래 예제에서는 환경 내 두 사서함 데이터베이스에 대해 콘텐츠 인덱스 파일을 다시 설정합니다. 이 두 저장소는 NA1-ERICNOR-1 클러스터된 사서함 서버에서 사서함 수, EDB 파일 크기 및 전체 데이터베이스 항목 수의 값이 가장 큰 저장소이기도 합니다.

콘텐츠 인덱스 파일 다시 설정:

3단계: Search Indexer에서 전체 크롤링이 필요한 것으로 검색되었는지 확인

기존 콘텐츠 인덱싱 파일이 파일 시스템에서 제거된 후 Microsoft Exchange Search Indexer 서비스가 다시 시작되고 나면 MonitorAndUpdateMDBList 스레드가 콘텐츠 인덱싱용으로 설정된 사서함 서버의 모든 사서함 데이터베이스에 대해 콘텐츠 인덱스의 현재 상태를 확인합니다. MonitorAndUpdateMDBList 스레드는 각 사서함 데이터베이스의 콘텐츠 인덱스 상태 를 확인한 후에 각 사서함 데이터베이스의 상태 값을 메모리에 저장합니다. 콘텐츠 인덱스 상태 값이 "New"인 경우 Microsoft Search Indexer 서비스 가 콘텐츠 인덱스 파일을 정상 상태로 설정하기 위해 완전한 전체 크롤링 이 필요하다고 결정한 것입니다. 여기서 "정상"이란 저장소 알림을 통해 인덱스가 최신 상태로 유지되는 지점입니다. 그러면 Exchange Search Indexer 서비스가 해당하는 사서함 데이터베이스에 대해 전체 크롤링 작업을 시작합니다.

전체 크롤링 작업이 실제로 시작되는 시간은 응용 프로그램 이벤트 로그에 이벤트 ID 109로 표시됩니다.

시스템에서 모든 전체 크롤링 작업이 시작되었는지를 확인하기 위해 작업을 수행하는 운영자는 해당 콘텐츠 인덱스가 위의 2단계 에서 다시 설정된 각 사서함 데이터베이스에 대해 이벤트 ID 109가 있는지를 확인합니다 .

예제

이전 예제에 나왔던 것처럼 ResetSearchIndex 스크립트를 사용하여 NA1-ERICNOR-1-DB1 및 NA1-ERICNOR-1-DB18에 대한 콘텐츠 인덱스 파일을 다시 설정했습니다. Microsoft Exchange Search Indexer 서비스에서 전체 크롤링 작업을 시작했는지 확인하려면 사서함 서버의 각 사서함 데이터베이스에 대해 고유한 이벤트 ID 109가 있는지 확인해야 합니다.예를 들면 다음과 같습니다.

이벤트 유형: 정보
이벤트 원본: MSExchange Search Indexer
이벤트 범주: 일반
이벤트 ID: 109
날짜: 2012/5/10
시간: 오후 2:22:19
컴퓨터: NA1-ERICNOR-1-A
설명: 새 검색 인덱스가 만들어졌으며 사서함 데이터베이스 NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1(GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129)에 대해 전체 크롤링이 수행됩니다.

이벤트 유형: 정보
이벤트 원본: MSExchange Search Indexer
이벤트 범주: 일반
이벤트 ID: 109
날짜: 2012/5/10
시간: 오후 2:22:20
컴퓨터: NA1-ERICNOR-1-A
설명: 새 검색 인덱스가 만들어졌으며 사서함 데이터베이스 NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18(GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16)에 대해 전체 크롤링이 수행됩니다.

참고 : 이벤트 로그를 직접 확인하는 대신 간편하게 Get-EventLog(영문일 수 있음) cmdlet을 사용하여 시작 이벤트를 CSV에 쓸 수 있습니다. 예를 들면 다음과 같습니다.

Get-EventLog "Application" | Where-Object {$_.EventID -eq 109} | Select-Object EventID,TimeGenerated,Message | Export-CSV -NoTypeInformation -Path c:\Search_StartEvents.csv

4단계: Search Indexer 진행률 및 완료 확인

이벤트 ID 109 유무를 통해 전체 크롤링 작업이 시작되었는지를 확인한 후에 운영자는 시스템 모니터 를 통해 전체 다시 작성 진행률을 모니터링합니다. 구체적으로는 다음과 같은 개체 및 카운터를 모니터링합니다.

MSExchange Search Indexer\Number of Databases Being Crawled
MSExchange Search Indexer\Number of Indexed Databases Being Kept Up-to-Date by Notifications
MSExchange Search Indices\<크롤링 중인 DB 인스턴스>\Full Crawl Mode Status
MSExchange Search Indices\<크롤링 중인 DB 인스턴스>\Document Indexing Rate
MSExchange Search Indices\<크롤링 중인 DB 인스턴스>\Number of Mailboxes Left to Crawl
MSExchange Search Indices\<크롤링 중인 DB 인스턴스>\Number of Recently Moved Mailboxes Being Crawled
MSExchange Search Indices\<크롤링 중인 DB 인스턴스>\Number of Outstanding Batches
MSExchange Search Indices\<크롤링 중인 DB 인스턴스>\Throttling Delay Value

운영자는 MSExchangeSearchIndexer 개체를 검토하여 서버에서 최신 상태인 콘텐츠 인덱스 및 현재 크롤링되는 중인 콘텐츠 인덱스의 수를 쉽게 확인할 수 있습니다. 사서함 서버가 완전히 최신 상태이면 "Number of Databases Being Crawled" 카운터의 값은 항상 0이고 "Number of Indexed Databases Being Kept Up-to-Date by Notifications" 카운터의 값은 서버에서 콘텐츠 인덱싱용으로 설정된 사서함 데이터베이스의 수와 같습니다.

제가 작업을 수행한 환경의 경우 메일 서버에 총 18개의 사서함 데이터베이스가 있었으며 그 중 2개에 대해 현재 전체 크롤링 이 진행되고 있었습니다. 따라서 아래에 나와 있는 것처럼 "Number of Databases Being Crawled"의 값은 2이고 Number of Indexed Databases Being Kept Up-to-Date by Notifications의 값은 16입니다.

개별 사서함 데이터베이스의 전체 크롤링 이 완료되면 시스템 모니터의 여러 개체 카운터가 특정 방식으로 변경됩니다.

MSExchange Search Indexer 수준:

"Number of Databases Being Crawled" 카운터의 값이 1 감소합니다.
"Number of Indexed Databases Being Kept Up-to-Date by Notification" 카운터의 값이 1 증가합니다.

사서함 데이터베이스 인덱스 수준:

특정 데이터베이스에 대한 "Full Crawl Mode Status"가 0으로 감소합니다. 이는 MonitorAndUpdateMDBList 모니터 스레드가 확인한 Content Index Health상태의 새로운 값을 반영합니다.
"Number of Mailboxes Left to Crawl"의 값은 0이 됩니다.
그 자체로는 전체 크롤링 다시 작성 작업과 구체적인 관계가 없지만 "Number of Recently Moved Mailboxes Being Crawled" 카운터의 값 역시 각 인덱스에 대해 0이어야 합니다. 대상이 콘텐츠 인덱싱용으로 설정되어 Exchange 사서함이 Exchange 사서함 데이터베이스 간에 정상적으로 이동되면 대상 데이터베이스의 검색 알림이 일시적으로 중단됩니다. Exchange Search Indexer 서비스 에서 알림을 일시적으로 중단하는 이유는 마스터 인덱스를 완전히 최신 상태로 설정하기 위해 최근 이동된 사서함의 일회성 크롤링을 수행하기 위해서입니다. 일회성 크롤링이 완료되면 저장소 알림이 다시 시작됩니다. 여기서 중요한 점은, 전체 크롤링 이 기술적으로는 완료되었지만 콘텐츠 인덱스 다시 작성과 동시에 사서함을 이동하는 경우 일회성 크롤링이 수행될 수 있다는 것입니다. 이 카운터의 값이 0이면 사서함 데이터베이스에 대해 수행되는 모든 크롤링 작업이 완전히 완료된 것이므로 그와 같이 확인해야 합니다.

모든 콘텐츠 인덱스가 완전히 최신 상태인 Exchange 서버에서 각 카운터의 값은 다음과 같습니다.

"MSExchange Search Indexer\Number of Databases Being Crawled"의 값은 0입니다.
"MSExchange Search Indexer\Number of Indexed Databases Being Kept Up-to-Date by Notifications"의 값은 사서함 서버에서 인덱싱용으로 설정된 사서함 데이터베이스의 수입니다.
사서함 서버의 각 Exchange 사서함 데이터베이스 인스턴스에 대한 "Full Crawl Mode Status"의 값은 0입니다.
사서함 서버의 각 Exchange 사서함 데이터베이스 인스턴스에 대한 "Number of Mailboxes Left to Crawl"의 값은 0입니다.
사서함 서버의 각 Exchange 사서함 데이터베이스 인스턴스에 대한 "Number of Recently Moved Mailboxes Being Crawled"의 값은 0입니다.

이 예제에서는 이러한 모든 값이 True이므로 인덱스가 정상적으로 다시 작성되었으며 콘텐츠 인덱스 측면에서 서버가 완전히 정상 상태 인 것으로 간주할 수 있습니다.

시스템 모니터를 통해 모든 콘텐츠 인덱스가 최신 상태임을 확인한 후 운영자는 응용 프로그램 이벤트 로그를 검토하여 이벤트 ID 110( 전체 크롤링 에 대한 Microsoft Exchange Search Indexer 완료 이벤트)의 유무를 확인합니다. 이벤트 ID 109와 마찬가지로, 전체 크롤링 이 완료된 각 사서함 데이터베이스에는 고유한 110 이벤트 항목이 있습니다.

이벤트 유형: 정보
이벤트 원본: MSExchange Search Indexer
이벤트 범주: 일반
이벤트 ID: 110
날짜: 2012/5/10
시간: 오후 5:39:47
컴퓨터: NA1-ERICNOR-1-A
설명: 사서함 데이터베이스 NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1(GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129)의 전체 크롤링(인덱싱)을 완료했습니다.

이벤트 유형: 정보
이벤트 원본: MSExchange Search Indexer
이벤트 범주: 일반
이벤트 ID: 110
날짜: 2012/5/10
시간: 오후 5:11:47
컴퓨터: NA1-ERICNOR-1-A
설명: 사서함 데이터베이스 NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18(GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16)의 전체 크롤링(인덱싱)을 완료했습니다.

참고 : 이벤트 로그를 직접 확인하는 대신 간편하게 Get-EventLog(영문일 수 있음) cmdlet을 사용하여 완료 이벤트를 CSV에 쓸 수 있습니다. 예를 들면 다음과 같습니다.

Get-EventLog "Application" | Where-Object {$_.EventID -eq 110} | Select-Object EventID,TimeGenerated,Message | Export-CSV -NoTypeInformation -Path c:\Search_CompletionEvents.csv

5단계: 다시 작성 후 메트릭 수집

5단계 에서는 운영자가 각 사서함 데이터베이스에 대해 전체 크롤링 완료를 확인했다고 가정합니다. 이 시점에서 운영자는 다시 작성 후 메트릭을 수집하여 크롤링을 수행한 각 사서함 데이터베이스에 대한 처리량 특성을 확인합니다.

이러한 메트릭을 수집하려면 -PostRebuild를 포함하여 E2K7_IndexRebuildAnalyzer 스크립트를 사용합니다.

위에서 설명한 것처럼 -PostRebuild는 응용 프로그램 이벤트 로그를 구문 분석하여 이벤트 ID 109 및 이벤트 ID 110의 유무를 확인합니다. 연속 클러스터 복제 의 경우 CCR 클러스터에 있는 각 노드의 응용 프로그램 이벤트 로그를 평가합니다. 스크립트는 이러한 이벤트 ID를 찾을 수 있으면 각 사서함 데이터베이스에 대해 전체 크롤링 을 완료하는 데 필요한 총 시간을 다양한 시간 단위로 계산합니다. 그런 후에 각 고유 다시 작성 작업의 처리량 특성을 운영자에게 반환합니다.

다시 한 번 강조하지만, 모든 사서함 데이터베이스에서 검색 인덱스를 다시 작성했는지 여부에 관계없이 사서함 서버의 모든 사서함 데이터베이스를 평가합니다. 또한 -CSVFile 옵션을 사용하지 않고 인스턴스화하는 경우 결과 집합이 콘솔 창에 출력됩니다. 다시 작성 후 통계를 계산할 때는 -CSVFile을 사용하는 것이 좋습니다. 그러면 Excel 사용 시 보고, 정렬, 필터링 및 피벗을 매우 쉽게 수행할 수 있습니다.

예제

.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 -PostRebuild -CSVFile c:\ericnor\NA1-ERICNOR-1_PostRebuild.csv

E2K7_IndexRebuildAnalyzer의 실행이 완료되면 CSV 파일을 검사할 수 있습니다. CSV를 검토하면 사서함 서버의 모든 Exchange 사서함 데이터베이스가 처리되었음을 확인할 수 있습니다. 대부분의 Exchange 사서함 데이터베이스에 대해서는 Search Indexer 이벤트 ID 쌍 조합을 찾을 수 없으므로 "NoEventsFound" 문자열이 반환됩니다. 예제 사례에서는 16개 사서함 데이터베이스에 대해 "NoEventsFound"가 보고되고 2개 사서함 데이터베이스에 대해서는 유효한 다시 작성 후 메트릭이 표시됩니다.

Excel 내에서 간단한 텍스트 기반 필터를 적용하여 이 결과 집합을 추가로 세분화할 수 있습니다. 다시 작성 후 열 머리글에 필터를 적용하고 다음과 같이 "NoEventFound" 문자열 선택을 취소하면 유효한 다시 작성 후 메트릭이 있는 데이터베이스만 표시됩니다.

예제 결과 집합에 이 필터를 적용하면 NA1-ERICNOR-1-DB1 및 NA1-ERICNOR-1-DB18, 즉 콘텐츠 인덱스가 다시 설정된 사서함 데이터베이스만 표시됩니다. 또한 다양한 다시 작성 후 헤더에 대해 유효한 값이 있으므로 다시 작성 후 메트릭을 올바르게 확인할 수 있습니다.

문자열 필터 적용 후:

6단계: Test-ExchangeSearch 확인

다시 작성 프레임워크의 6단계 에서는 사서함 데이터베이스가 홈으로 지정되어 있으며 해당 콘텐츠 인덱스가 다시 설정된 모든 사서함이 이제 유효한 검색 응답을 반환할 수 있는지를 확인합니다 . 이 작업을 수행하려면 Test-ExchangeSearch cmdlet 내에 포함되어 있는 핵심 기능을 사용하면 됩니다. 모든 사서함에서 cmdlet에 True 응답을 반환해야 최종 확인이 완료됩니다.

예제:

Get-Mailbox -Database NA1-ERICNOR-1\ NA1-ERICNOR-1-SG1\ NA1-ERICNOR-1-DB1 | Test-ExchangeSearch | ft -a

Get-Mailbox -Database NA1-ERICNOR-1\ NA1-ERICNOR-1-SG18\ NA1-ERICNOR-1-DB18 | Test-ExchangeSearch | ft -a

데이터베이스 내에 포함된 사서함의 수에 따라 이 프로세스는 완료하는 데 시간이 매우 오래 걸립니다. 또한 Test-ExchangeSearch를 사용하여 대량 작업을 수행할 때는 결과가 True인지 False인지에 관계없이 모든 사서함이 처리된 후에만 ResultFound 및 SearchTime 속성이 콘솔 창에 표시됩니다. 문서 작성용으로 모든 결과를 CSV에 저장하는 것이 효율적인 경우도 있습니다.

최종 사용자 사서함에서 Test-ExchangeSearch 테스트에 대해 False를 보고하는 경우는 일회성 문제로 간주되어 적절하게 처리됩니다.

7단계: 다시 작성 후 메트릭 분석

이 문서에서는 다양한 메트릭을 Excel 열에 표시되는 그대로 표시하는 대신 쉽게 읽을 수 있도록 표 형식으로 표시합니다. 위에서도 언급한 것처럼 NA1-ERICNOR-1 클러스터된 사서함 서버에는 콘텐츠 인덱스가 다시 작성된 Exchange 사서함 데이터베이스 2개(NA1-ERICNOR-1-DB1 및 NA1-ERICNOR-1-DB18)가 있습니다.

사서함 메트릭 다시 작성 후:

사서함 데이터베이스 다시 작성 메트릭:

다양한 다시 작성 메트릭 및 다시 작성 전 메트릭은 이후 다시 작성 작업을 위한 이전 평균 계산에 포함할 수 있도록 기록 데이터 컬렉션에 추가됩니다.

결론

이 게시물 시리즈의 두 번째 게시물에서는 검색 다시 작성 프레임워크의 각 단계에 대해 설명했습니다. 다음(최종) 게시물에서는 Microsoft 내부 배포에서 확인된 평균값을 제공합니다.

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

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

共用方式為