보통 RAID를 구성, LUN할당 후 Windows GUI상으로 파티션을 만들고 포맷을 하여 SQL Server의 데이터 또는 로그 파일 등을 위치하여 사용한다.
하지만 이렇게 GUI로 파티션을 설정 하면, 파티션 시작 위치와 RAID Stripe Size가 일치 하지 않아서 아래의 그림과 같은 모습이 된다.
이렇게 되면 특정 하나의 블록을 읽거나 쓰기를 위해서 두 개의 디스크에 요청을 할 수 도 있다.
이러한 문제를 해결하기 위해서 물리적 파티션 위치를 IO블럭의 배수로 파티션의 시작위치를 설정 하여 파티션을 만들어 사용한다면 이러한 문제가 해결 될 수 있다.
이런 문제는 단일 디스크, RAID 1 과 같은 Stripe 되지 않은 환경에는 영향을 받지 않을 것이다.
RAID10으로 많은 디스크로 LUN을 할당 하였다면 이러한 문제로 인해 보다 성능 저하가 발생할 가능성이 크기에, 두 가지 경우를 가지고 테스트 후 서비스에 적용을 할 수 있을 것이다.
12장 RAID10으로 구성된 DAS에서 SQLIO로 테스트를 하였으며 기존 파티션 보다 대략 10%정도의 성능이 향상된 것을 확인 하였다.
보다 자세한 내용은 아래의 테스트 결과를 참조하길 바란다.
<기본 Data Block layout>
<Sector Alignment>
<구성 방법>
트랙당 64개의 섹터를 관리하는 실제 디스크에서 Windows는 항상 64번째 섹터에서 시작하는 파티션을 만들기 때문에 실제 기본 디스크와 맞춤이 틀리게 됩니다.
디스크 맞춤을 정확하게 하려면 디스크 파티션 도구인 Diskpart.exe를 사용합니다.
Diskpart.exe는 MBR(마스터 부트 레코드)에서 시작 오프셋을 명시적으로 설정할 수 있도록 Microsoft가 Windows Server 2003 서비스 팩 1 지원 도구에 제공한 유틸리티입니다.
시작 오프셋을 설정하면 맞춤을 추적하고 디스크 성능을 향상시킬 수 있습니다.
-
맞추려는 디스크가 이미 비어 있을(원시 상태) 경우 3단계를 진행합니다. 디스크에 데이터가 들어 있을 경우 진행하기 전에 먼저 디스크를 백업합니다.
-
디스크의 모든 파티션을 삭제합니다.
-
명령 프롬프트를 열고 Diskpart.exe를 실행합니다.
-
Diskpart 명령 프롬프트에서 List Disk를 입력하고 Enter 키를 누릅니다. 맞추려는 디스크가 목록에 나타나지 않을 경우 디스크가 있는지 확인하고 디스크 관리 스냅인을 사용하여 액세스할 수 있는지 확인합니다.
-
Diskpart 명령 프롬프트에서 Select Disk X를 입력합니다. 여기서 X는 List Disk 명령 출력에 표시되는 디스크 번호를 나타냅니다. Diskpart는 디스크 X가 선택된 디스크임을 나타내는 메시지를 반환해야 합니다.
-
Diskpart 명령 프롬프트에서 Create Partition Primary Align=X를 입력합니다. 여기서 X는 저장소 공급업체의 권장 사항에 따라 32 또는 64이 됩니다. 저장소 공급업체의 구체적인 권장 사항이 없으면 64를 사용하는 것이 좋습니다.
-
디스크 관리자에서 포맷함.
참조 :
http://support.microsoft.com/?id=300415
http://technet.microsoft.com/ko-kr/library/aa995867.aspx
위와 같이 파티션을 설정하였다면, 정상적으로 파티션이 만들어졌는지 확인이 필요하다. 여기서는 확인 하는 두 가지 방법을 소개한다.
-
MSINFO32정보(MSINFO32의 파티션 시작 오프셋정보를 확인한다.)
<Default> < Sector Alignment>
-
WMI를 이용하여 확인(아래의 내용을 VBS파일로 생성 후 실행)
모든 설정이 끝났다, 얼마나 차이가 있는지 SQLIO라는 도구로 테스트를 진행하였다.
먼저 간단히 결론부터 알아보면, 응답속도는 기존과 거의 비슷하나, 대략 10%정도의 IO양이 증가 된 것을 확인 하였다.
sqlio -kR -s60 -frandom -o8 -b8 -LS -F"C:\Program Files\SQLIO\param.txt"
|
|
|
Default |
Sector Alignment |
|
테스트1 |
IOs/sec |
3226.29 |
3646.51 |
|
MBs/sec |
25.2 |
28.48 | |
|
테스트2 |
IOs/sec |
3234.74 |
3702.91 |
|
MBs/sec |
25.27 |
28.92 | |
|
테스트3 |
IOs/sec |
3230.41 |
3716.44 |
|
MBs/sec |
25.23 |
29.03 |
송 혁, SQL Server MVP
sqler.pe.kr
nexondbteam.tistory.com
댓글을 달아 주세요
안보갑 2007.12.31 13:38 신고 댓글주소 수정/삭제 댓글쓰기
예전 IO 테스트툴 말고 iosim을 이용해서 결과 다시한번 봤으면 싶은데요~ 이전 테스트 프로그램 자체의 신뢰도가 떨어지니... 다시 해보고 알려주세요~
안보갑 2007.12.31 13:39 신고 댓글주소 수정/삭제 댓글쓰기
만약 iosim으로 했을때에도 결과가 그러하다면 시스템인프라팀이나 네트워크관리팀에도 전달해서 사용하도록해야 할 듯 하네요~