Windows 디스크 시간 초과 및 Exchange Server 2010

최초 문서 게시일: 2011년 11월 17일 목요일

몇 달 전에 Bruce Langworthy가 Windows 디스크 시간 초과 값을 설정하기 위한 몇 가지 새로운 권장 사항과 관련하여 유용한 정보를 제공하는 문서(https://blogs.msdn.com/b/san/archive/2011/08/15/the-windows-disk-timeout-value-understanding-why-this-should-be-set-to-a-small-value.aspx(영문일 수 있음))를 작성한 바 있습니다.

저는 Bruce의 이 게시물을 보면서 Exchange와 관련해 I/O 문제를 해결하는 방법을 고려해 보게 되었습니다. 해당 문서를 확인하지 않으신 분들을 위해 내용을 잠시 설명하자면, 기본 디스크 시간 초과 값인 60초는 Windows에서 60초 동안 I/O 중단을 보고하지 않으며 8분 동안 I/O를 다시 시도하지 않음을 의미합니다. 그런데 중단된 I/O를 다시 시도할 때까지 기다리는 8분이라는 시간이 너무 길기 때문에, Microsoft에서는 Windows 디스크 시간 초과 설정을 저장소 아키텍처에 맞는 값으로 변경하도록 권장하는 새로운 지침을 공개했습니다.

이와 관련하여 제가 Exchange에 대해 생각해 본 점은 "이 디스크 시간 초과 동작이 Exchange DAG 배포에 주는 영향"이라는 간단한 사항입니다. 좀 더 구체적으로는 "새로운 권장 사항에 따라 Exchange 서버에서 Windows 디스크 시간 초과 값을 낮춰야 하는지 아니면 그대로 유지해야 하는지 여부"입니다.

이 사항을 파악하기 위해 ESE 개발자 몇 분의 의견을 들어 본 결과 다음과 같은 정보를 얻을 수 있었습니다.

• Windows 디스크 시간 초과 값은 기본적으로 이벤트 로깅 및 I/O 다시 시도에 사용됩니다.
• Exchange Server 2010 이전 버전의 Exchange에서는 저속 I/O에 대해 이벤트 로그에서 보고하는 것 외에는 아무런 조치를 취하지 않았습니다.
• Exchange Server 2010 RTM에는 저속 I/O의 영향을 받는 페이지에 대한 선점형 페이지 패치(새 페이지 덮어쓰기) 기능이 도입되었습니다.
• I/O 중단이 DAG 노드의 활성 데이터베이스에 영향을 주는 경우 I/O 중단을 처리하고 서버에서 오류를 발생(버그를 확인)시키는 지능적 기능이 포함된 최초의 Exchange 버전은 Exchange Server 2010 SP1입니다.

이러한 정보를 토대로, 디스크 시간 초과 설정과 관련하여 작업을 수행하려면 먼저 Exchange Server 2010 SP1에 도입된 지능적 기능 및 이 기능이 디스크 시간 초과와 상호 작용하는 방식에 대해 파악해야 한다는 판단을 내렸습니다.

I/O 중단에 대한 Exchange Server 2010 SP1의 Extensible Storage Engine 복구 기능

Exchange Server 2010 SP1에서는 I/O 중단을 처리하는 방법과 관련하여 크게 개선된 몇 가지 기능이 도입되었습니다. 이러한 개선 기능에 대한 자세한 설명은 TechNet 문서 https://technet.microsoft.com/ko-kr/library/ff625233.aspx에 다음과 같이 나와 있습니다:

“Exchange 2010 SP1에는 특정 상황(구체적으로는 I/O 중단)이 발생하면 기본 제공 Windows 버그 확인 동작을 사용하는 새로운 복구 논리가 포함되어 있습니다. SP1에서는 ESE(Extensible Storage Engine)가 업데이트되어 I/O 중단을 탐지하고 해결 조치를 취하여 서버를 자동으로 복구합니다. ESE는 I/O가 지정된 기간 동안 대기되었는지를 탐지하는 I/O 감시 스레드를 유지 관리합니다. 기본적으로 데이터베이스의 I/O가 1분보다 오랫동안 대기되면 ESE는 이벤트를 기록하며, 데이터베이스의 I/O가 4분보다 오래 대기되면 특정 오류 이벤트를 기록합니다(가능한 경우). ESE 이벤트 507, 508, 509 또는 510은 I/O 중단의 특성에 따라 기록될 수도 있고 기록되지 않을 수도 있습니다. 문제의 특성에 따라 OS 볼륨 또는 이벤트 로그에 쓰는 기능이 영향을 받는 경우에는 이벤트가 기록되지 않습니다. 이벤트가 기록되는 경우 Microsoft Exchange Replication Service(MSExchangeRepl.exe)에서는 해당 조건을 탐지하고 wininit.exe 프로세스를 종료함으로써 의도적으로 Windows 버그 확인을 수행합니다."

이 설명과 관련하여 개발자들과 몇 차례의 논의를 진행하고 ESE 코드를 검색한 후에, 해당 동작을 보다 쉽게 이해할 수 있도록 아래와 같은 표를 작성했습니다. 이전 버전 Exchange 관련 내용도 참조를 위해 포함되어 있습니다.

참고: Exchange 팀 소속의 ESE 개발자인 Alexandre Costa와 Brett Shirley에게 깊은 감사의 인사를 전합니다. 이 두 분을 비롯한 개발자 여러분들 덕분에 아래 표의 정보를 확인할 수 있었습니다. 감사합니다.

참고: 진행 중 I/O는 아직 정상적으로 완료되지 않은 저속 I/O 작업입니다. 완료된 I/O는 완료는 되었지만 30초보다 오래 걸린 저속 I/O를 나타냅니다. Exchange Server 2010 이전 버전에는 저속 진행 중 I/O 탐지 개념이 없었으며 I/O 완료 시에만 보고가 한 번 수행되었습니다.

새로운 동작을 변경하는 방법

대부분의 동작과 마찬가지로, 여기서 설명하는 새로운 동작 역시 반드시 필요한 경우가 아니면 변경하지 않는 것이 좋습니다. 그러나 I/O 중단 동작에 대해 새로운 Extensible Storage Engine 복구 기능을 수정해야 하는 경우에는 몇 가지 레지스트리 키/Active Directory 특성을 사용할 수 있습니다. 이러한 키와 특성에 대한 설명은 여기에서 확인할 수 있습니다.

결론

이 문서의 앞부분에서도 언급했듯이, 이 문서를 작성한 이유는 여기(영문일 수 있음)에 나와 있는 권장 사항에 따라 Exchange DAG 서버 노드에 대한 Windows 디스크 TimeOutValue를 줄여야 하는지를 평가하기 위한 것이었습니다.

Exchange 팀 소속의 Exchange 및 I/O 전문가인 Matt Gossage의 설명에 따르면, 디스크 시간 초과의 용도 중 하나는 호스트의 과도한 버스 재설정 방지입니다. I/O가 Windows 디스크 TimeOutValue에 도달하는 경우의 부작용 중 주목해야 하는 점은 disk.sys 드라이버에서 버스 재설정을 실행한다는 것인데, 이 재설정은 응답하지 않는 LUN뿐 아니라 서버의 모든 LUN에 영향을 줍니다.

이러한 동작은 Exchange 2010 및 JBOD 저장소에서 가장 흔하게 나타납니다. RAID 솔루션이 배포되어 있고 디스크 컨트롤러가 다른 디스크에서 데이터를 읽거나 패리티에서 데이터를 다시 계산하여 잘못된 블록 읽기를 처리할 수 있다면 I/O가 지연되기는 하지만 그 정도는 크지 않습니다. JBOD를 사용하는 경우에는 데이터 블록 복사본이 하나뿐이므로 잘못된 블록으로 인해 디스크의 데이터 읽기 시도를 기다리는 중 I/O가 중단될 수 있습니다. 이 경우 JBOD 배포에서는 디스크 TimeOutValue를 줄여서는 안 되며, JBOD 디스크 스핀들 중 하나에 오류가 발생하면 과도한 버스 재설정의 영향을 줄이기 위해 디스크 TimeOutValue 값을 높여야 할 수도 있습니다.

아래 표에는 Exchange Server 2010 사서함 역할을 실행하는 서버에 대해 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue를 설정하기 위한 권장 지침이 나와 있습니다.

Neil Johnson
UK MCS 선임 컨설턴트

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Windows Disk Timeouts and Exchange Server 2010을 참조하십시오.