SQL Server에서 SSD 드라이브의 RAID 배열을 어떻게 구성해야합니까?

14

48GB RAM, 1 CPU 및 8 SATA III (6GB / s) SSD 드라이브 (128GB Crucial m4) 및 LSI MegaRAID 컨트롤러 (SAS 9265-8i)가있는 SQL Server를 구축하고 있습니다. 나는 전형적인 작업 부하가 대부분 읽기를 기대합니다. 약간의 쓰기 작업이 많을 수 있지만 (제 3 자 데이터 제공 업체와의 시간별 데이터 동기화-야간 백업) 일반적인 읽기 / 쓰기 비율이 약 90 % 읽기 / 10 % 쓰기 인 것 같습니다.

옵션 1 :
논리 드라이브 C :-RAID 1 (2 개의 물리 드라이브)-OS
논리 드라이브 D :-RAID 10 (6 개의 물리 드라이브)-DB 파일 / 로그 / tempdb / 백업?

또는

옵션 2 :
논리 드라이브 C :-RAID 1 (2 물리 드라이브)-OS
논리 드라이브 D :-RAID 1 (2 물리 드라이브)-Db 파일
논리 드라이브 E :-RAID 1 (2 물리 드라이브)-로그 파일 / 백업?
논리 드라이브 F :-RAID 1 (2 개의 물리 드라이브)-tempdb

또는

옵션 3 :
다른 제안?

옵션 2는 모방에 보이더라도 나는 모든 DB 활동이 3 개 드라이브에 스트라이핑 (및 배열에 다른 3의 미러) 될 수 있기 때문에, 나에게 더 나은 성능을 줄 것이다 옵션 1을 생각하고 일반 통념 기계에 더 많은 적용이 나타납니다 ( SSD보다 드라이브). 옵션 1 과 함께 스택 오버플로가 발생한 것 같습니다 .

SSD를 사용하면 서버가 I / O가 제한되는 대신 CPU가 더 제한되어 있기 때문에 모든 것을 단일 논리 드라이브에 넣는 것이 좋습니다.

내가 가지고있는 또 다른 질문은 야간 백업을 어디에 배치해야합니까? 우리는 백업이 나머지 SQL Server의 속도를 늦추기를 원하지 않으며 두 경우 모두 읽기 / 쓰기 동작이 순차적 쓰기이므로 로그와 동일한 위치에 백업을 작성하는 것이 좋습니다.

sql-server configuration

— 로비
소스

한 번 논리적 분배에 이점이 있다고 믿었지만, 상당히 광범위한 연구 (마이클에는 여전히 일부가있을 수 있음) 후에 대상 레벨의 논리적 분배가 성능을 향상시키지 않는다는 결론에 도달했습니다 . 따라서 물리적 (회전하는) 디스크에 대해 이야기하고 코어 선호도를 활용하기 위해 8 개의 데이터 파일을 원한다면 단일 논리적 볼륨 (동일한 물리적 디스크에있는)에 8 개의 파일이 있는지 또는 8 개의 파일에 대해 8 개의 논리 파티션을 잘라냅니다 (동일한 물리 디스크에 있음). 논리적으로 SSD를 자르는 것과 비슷하다고 생각합니다

— Eric Higgins

9

RAID에 대한 기존의 지혜는 SSD에 잘 적용되지 않습니다. 실제로 스트라이핑 (RAID0)이 필요하지 않습니다. 그들은에 의해 설계 실패하는 경향이 있지만, RAID-1은 일반적으로 두 가지 이유 SSD에 대한 정답되지 않습니다 : A)가 낭비, 반 SSD를 배열의 용량 (그들은 이다 비싼), 2) SSD의 장애 특성 리드 미러의 두 드라이브를 향하여 매우 가까운 간격 (예 : 상관 된 장애)으로 장애가 발생하여 전체 어레이를 쓸모 없게 만듭니다. 더 자세한 내용은 차등 RAID : SSD 안정성을 위해 RAID 재검토를 참조하십시오 . 일부는 SSD에 Raid-6 을 사용하도록 권장했습니다 .

또한 기존 SQL Server 파일 레이아웃 개념은 SSD에 적용되지 않습니다. SSD : Hot and Crazy Love에서 SQL을보고이 답변 의 벤치 마크 링크를 살펴 보는 것이 좋습니다 .

— 레무스 루사 누
소스

좋은 점은 RAID 10을 사용하면 관련 오류에 더 취약 할 수 있습니다. Differential RAID 링크에 감사드립니다.

— 로비

8

순차적 로그에서 데이터에 대한 임의 IO 패턴을 분리하는 표준 접근 방식은 SSD에 적용되지 않으므로 다음과 같은 옵션 1을 선택합니다.

백업은 별도의 머신에 있어야합니다. 연기가 나는 서버의 경우에는 액세스 할 수없는 백업이 거의 없습니다.
데이터 배열의 장애로 인해 로그 백업을 수행 할 수 있도록 데이터와 로그 드라이브를 분리하는 데 약간의 가치가 있습니다.
핫 스페어가 없다는 점에 유의하십시오.
소비자 수준 드라이브가 있다는 점에 유의하십시오. 여러 비용으로 엔터프라이즈 급 제품만큼 신뢰할 수 있다고 가정하지 마십시오.
SSD에 관한 재미 있고 유익한 SQL : Brent Ozar의 Hot and Crazy Love 를보십시오.

SSD가 사용되는 데이터에서 로그를 분리하는 문제는 성능이 아니라 시스템의 RPO (복구 지점 목표) 문제입니다. RPO가 분 단위로 정의 된 경우 하나의 공유 어레이로 이동하여 [RPO] 분마다 로그 백업을 수행하십시오. RPO가 초 단위로 정의되면 별도의 배열로 이동하십시오.

솔직히 말해서 RPO가 타이트한 경우 데이터 어레 이용 SSD를 유지하고 로그에 고가의 (엔터프라이즈) 신뢰할 수있는 스피너를 미러링하여 사용합니다.

— 마크 층-스미스
소스

백업 도 별도의 머신에 복사됩니다. 로컬 컴퓨터에서 생성되므로 SQL 비교 / 데이터 비교를 사용하고 회귀 / 사용자 오류의 경우 변경 사항을 되돌릴 수 있습니다.

— Robbie

또한 RPO는 몇 분 안에 정의됩니다 (10 분 안에도 시나리오가 완전히 정직한 것으로 받아 들일 수 있다고 생각합니다). Hot & Crazy Love 게시물 은 관련 실패에 대해 생각하게합니다. 제한된 경험으로, 더 많은 마더 보드 오류 및 전체 시스템 오류 (전원 공급 장치 / 전원 서지가 모든 것을 튀김)를 겪은 후 드라이브 오류를 일으켰으므로 여전히 가장 비용 효과적인 편집증 / 예방 수준이 무엇인지 확인하려고합니다.

— 로비

1

다음과 같이 옵션 2를 사용해야합니다.

Logical Drive - RAID 1 (2 physical drives)
 1 partition C: OS
 2 partition D: backups / log files
Logical Drive E: - RAID 1 (2 physical drives) - DATA files
Logical Drive F: - RAID 1 (2 physical drives) - INDEX files
Logical Drive G: - RAID 1 (2 physical drives) - tempdb

데이터와 인덱스를 2 개의 다른 데이터 파일로 분리 한 다음 2 개의 서로 다른 물리적 논리 드라이브에 저장하면 쿼리 할 때 테이블 데이터와 디스크에 대해 하나의 디스크 회전이 발생하기 때문에 디스크 io가 크게 증가합니다. 동시에 인덱스를 회전시킵니다.

tempdb도 많은 일이 발생하기 때문에 백업과 분리하십시오. 백업과 데이터 파일을 섞지 마십시오. 매일 백업을 수행하지 않아도 백업이 수행되면 IO에 큰 타격을줍니다. 비즈니스 및 데이터베이스 사용에 따라 백업 시간 동안 일부 또는 많은 사람들이 불만을 표시 할 수 있습니다.

도움이 되었기를 바랍니다

— 니콜라스 데 폰테나이
소스

6

무의미한 말. 이들은 스피너가 아닌 SSD입니다.

— Mark Storey-Smith

sdd로도 말이되지는 않지만 그렇게 많은 성능은 그 정도에 도달했습니다.

— Nicolas de Fontenay 2014 년

2

스피너를 사용하더라도 SQLCAT 영역에서 플레이 할 때까지 인덱스에서 데이터를 분리하는 것은 가치가 없습니다. tempdb를 분리하는 경우도 명확하지 않으며 이러한 소수의 디스크에는 거의 적용되지 않습니다.

— Mark Storey-Smith