Tôi nên định cấu hình mảng RAID của ổ SSD trên Máy chủ SQL của mình như thế nào?

14

Tôi đang xây dựng Máy chủ SQL với RAM 48 GB, 1 CPU và 8 ổ SSD SATA III (6 GB / giây) (128 GB rất quan trọng) và bộ điều khiển LSI MegaRAID (SAS 9265-8i). Tôi hy vọng tải công việc điển hình chủ yếu là đọc. Sẽ có một số giai đoạn hoạt động ghi nặng hơn (dữ liệu hàng giờ đồng bộ với nhà cung cấp dữ liệu của bên thứ 3 - sao lưu hàng đêm), nhưng tôi nghi ngờ tỷ lệ đọc / ghi thông thường là khoảng 90% đọc / 10% ghi.

Tùy chọn 1:
Ổ đĩa logic C: - RAID 1 (2 ổ đĩa vật lý) -
Ổ đĩa logic hệ điều hành D: - RAID 10 (6 ổ đĩa vật lý) - Tệp DB / log / tempdb / sao lưu?

HOẶC LÀ

Tùy chọn 2:
Ổ đĩa logic C: - RAID 1 (2 ổ đĩa vật lý) -
Ổ đĩa logic hệ điều hành D: - RAID 1 (2 ổ đĩa vật lý) - Tệp Db
Ổ đĩa logic E: - RAID 1 (2 ổ đĩa vật lý) - tệp nhật ký / sao lưu?
Ổ đĩa logic F: - RAID 1 (2 ổ đĩa vật lý) - tempdb

HOẶC LÀ

Lựa chọn 3:
gợi ý khác?

Tôi nghĩ tùy chọn 1 sẽ cho tôi hiệu suất tốt hơn, vì tất cả hoạt động DB sẽ bị sọc trên 3 ổ đĩa (và được nhân đôi trên 3 ổ còn lại trong mảng), mặc dù tùy chọn 2 dường như bắt chước trí tuệ thông thường (dường như áp dụng nhiều hơn cho cơ học ổ đĩa hơn SSD). Nó có vẻ như Stack Overflow đã đi với phương án 1 .

Tôi đoán với SSD, có ổn không khi đặt mọi thứ vào một ổ đĩa logic duy nhất vì máy chủ của bạn có thể bị hạn chế nhiều CPU hơn thay vì I / O bị hạn chế tại thời điểm đó?

Một câu hỏi khác mà tôi có là tôi nên đặt các bản sao lưu hàng đêm ở đâu? Chúng tôi không muốn các bản sao lưu làm chậm phần còn lại của máy chủ SQL và tôi đoán việc viết các bản sao lưu cùng vị trí với nhật ký là một cách thực hành tốt vì hành vi đọc / ghi trong cả hai trường hợp đó là ghi tuần tự.

sql-server configuration

— Robbie
nguồn

Tôi đã từng có niềm tin rằng có lợi cho phân phối logic, nhưng sau một số nghiên cứu khá rộng rãi (Michael vẫn có thể có một số trong đó), chúng tôi đã đi đến kết luận rằng phân phối logic @ mức mục tiêu không cải thiện hiệu suất. Vì vậy, nếu chúng ta đang nói về đĩa vật lý (quay) và bạn muốn 8 tệp dữ liệu để tận dụng mối quan hệ cốt lõi, thì chúng không phải là 8 tệp trên một ổ đĩa logic (trên cùng một đĩa vật lý) hoặc nếu bạn cắt 8 phân vùng logic cho 8 tệp đó (trên cùng một đĩa vật lý). Tôi nghĩ bạn sẽ thấy nó tương tự một cách hợp lý khi cắt SSD của bạn

— Eric Higgins

9

Sự khôn ngoan thông thường về RAID không áp dụng tốt cho SSD. Họ không thực sự cần phân chia (RAID0). Họ dễ bị thất bại bởi thiết kế, nhưng RAID-1 thường không phải là câu trả lời đúng cho SSD vì hai lý do: a) là lãng phí, nửa công suất của mảng SSD (và họ là đắt tiền) và 2) SSD đặc điểm thất bại dẫn về phía cả hai ổ đĩa trong gương đều thất bại trong khoảng thời gian rất gần (nghĩa là các lỗi tương quan) và do đó làm cho toàn bộ mảng trở nên vô dụng. Xem RAID khác biệt: Xem xét lại RAID về độ tin cậy của SSD để thảo luận dài hơn. Một số đã khuyến nghị sử dụng Raid-6 cho SSD.

Ngoài ra, sự khôn ngoan thông thường của bố cục tệp SQL Server không áp dụng cho SSD. Tôi khuyên bạn nên xem SQL trên SSD: Hot and Crazy Love và xem qua các liên kết điểm chuẩn trong câu trả lời này .

— Remus Rusanu
nguồn

Điểm hay, với RAID 10, có lẽ tôi dễ bị tổn thương hơn trước những thất bại tương quan. Cảm ơn các liên kết RAID khác biệt.

— Robbie

8

Cách tiếp cận tiêu chuẩn để tách các mẫu IO ngẫu nhiên cho dữ liệu khỏi chuỗi nhật ký đơn giản là không áp dụng trên SSD, vì vậy tôi chọn tùy chọn 1 của mình một cách cẩn thận:

Sao lưu PHẢI vào một máy riêng biệt. Có rất ít điểm trong việc có các bản sao lưu mà bạn không thể truy cập trong trường hợp máy chủ bốc khói.
Có một số giá trị trong việc tách các ổ đĩa dữ liệu và nhật ký sao cho sự thất bại của mảng dữ liệu sẽ cho phép bạn thực hiện một bản sao lưu nhật ký.
Hãy chú ý rằng bạn không có một phụ tùng nóng.
Hãy chú ý rằng bạn có ổ đĩa mức tiêu dùng. Đừng cho rằng họ sẽ đáng tin cậy như các doanh nghiệp tương đương với nhiều chi phí.
Xem SQL thú vị và rất nhiều thông tin trên SSD: Hot and Crazy Love của Brent Ozar.

Vấn đề tách nhật ký khỏi dữ liệu sử dụng SSD là vấn đề RPO (mục tiêu điểm khôi phục) cho hệ thống, thay vì hiệu suất. Nếu RPO được xác định theo phút, hãy đi với một mảng được chia sẻ và thực hiện sao lưu nhật ký sau mỗi [RPO] phút. Nếu RPO được xác định bằng giây, hãy đi với các mảng riêng biệt.

Thành thật mà nói, nếu RPO chặt chẽ, tôi sẽ giữ SSD cho mảng dữ liệu và sử dụng một cặp spinners đáng tin cậy (doanh nghiệp) được nhân đôi cho nhật ký.

— Mark Storey-Smith
nguồn

Các bản sao lưu cũng được sao chép vào một máy riêng biệt. Chúng được tạo trên máy cục bộ để tôi có thể sử dụng So sánh SQL / So sánh dữ liệu và hoàn nguyên các thay đổi trong trường hợp hồi quy / lỗi người dùng.

— Robbie

Ngoài ra, RPO được xác định bằng phút (tôi nghĩ ngay cả trong 10 phút sẽ được chấp nhận để kịch bản của tôi hoàn toàn trung thực). Hot & Crazy Love bài không có tôi suy nghĩ về những thất bại tương quan. Theo kinh nghiệm hạn chế của tôi, tôi đã gặp nhiều lỗi bo mạch chủ hơn và tổng số lỗi hệ thống (cung cấp năng lượng / tăng đột biến mọi thứ) sau đó dẫn đến sự cố, vì vậy tôi vẫn đang cố gắng xác định mức độ hoang tưởng / phòng ngừa hiệu quả nhất về chi phí.

— Robbie

1

Bạn nên đi với tùy chọn 2 như sau:

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

Bằng cách tách dữ liệu của bạn và các chỉ mục của bạn thành 2 tệp dữ liệu khác nhau được lưu trữ trong 2 ổ đĩa logic vật lý khác nhau, bạn sẽ có được sự gia tăng lớn trong đĩa io đơn giản vì khi bạn truy vấn, bạn sẽ có một đĩa quay cho dữ liệu bảng của mình và một ổ đĩa khác quay cho chỉ số của bạn cùng một lúc.

Cũng để lại tempdb khỏi các bản sao lưu của bạn vì có rất nhiều thứ xảy ra trong đó. Đừng trộn lẫn các bản sao lưu và tệp dữ liệu của bạn. mặc dù các bản sao lưu không được thực hiện hàng ngày, nhưng khi chúng xảy ra, chúng ảnh hưởng rất lớn đến IO của bạn. dựa trên doanh nghiệp và việc sử dụng cơ sở dữ liệu của bạn, một số người hoặc rất nhiều người có thể khiếu nại trong thời gian sao lưu.

Hi vọng điêu nay co ich

— Nicolas de Fontenay
nguồn

6

Vô lý. Đây là SSD, không phải spinners.

— Mark Storey-Smith

không vô nghĩa ngay cả với sdd có một số hiệu suất đạt được theo cách đó, mặc dù không nhiều.

— Nicolas de Fontenay

2

Ngay cả với người quay, việc tách dữ liệu khỏi các chỉ mục không có giá trị cho đến khi bạn chơi trong lãnh thổ SQLCAT. Trường hợp để tách tempdb cũng không bao giờ được cắt rõ ràng và rất hiếm khi áp dụng với một số lượng nhỏ đĩa như vậy.

— Mark Storey-Smith