ฉันจะกำหนดค่าอาร์เรย์ RAID ของไดรฟ์ SSD บน SQL Server ได้อย่างไร

14

ฉันกำลังสร้าง SQL Server ที่มี RAM 48 GB, 1 CPU, & 8 SATA III (6GB / s) ไดรฟ์ SSD (128 GB Crucial m4) และคอนโทรลเลอร์ LSI MegaRAID (SAS 9265-8i) ฉันคาดว่างานโหลดทั่วไปส่วนใหญ่จะอ่าน จะมีบางช่วงของกิจกรรมการเขียนที่หนักกว่า (ซิงค์ข้อมูลรายชั่วโมงกับผู้ให้บริการข้อมูลบุคคลที่สาม - การสำรองข้อมูลทุกคืน) แต่ฉันสงสัยว่าอัตราส่วนการอ่าน / เขียนทั่วไปประมาณ 90% อ่าน / 10% เขียน

ตัวเลือกที่ 1:
ไดรฟ์แบบลอจิคัล C: - RAID 1 (ไดรฟ์ทางกายภาพ 2 ตัว) -
ไดรฟ์แบบลอจิคัลของระบบปฏิบัติการD: - RAID 10 (6 ไดรฟ์ทางกายภาพ) - ไฟล์ฐานข้อมูล / บันทึก / tempdb / สำรอง

หรือ

ตัวเลือกที่ 2:
Logical Drive C: - RAID 1 (ไดรฟ์ทางกายภาพ 2 ตัว) - OS
Logical Drive D: - RAID 1 (ไดรฟ์ทางกายภาพ 2 ตัว) - ไฟล์ Db
Logical Drive E: - RAID 1 (ไดรฟ์กายภาพ 2 ตัว) - ล็อกไฟล์ / สำรอง
Logical Drive F: - RAID 1 (ฟิสิคัลไดรฟ์ 2 ตัว) - tempdb

หรือ

ตัวเลือก 3:
คำแนะนำอื่น ๆ ?

ฉันตัวเลือกที่ 1 คิดจะให้ฉันประสิทธิภาพที่ดีขึ้นเนื่องจากกิจกรรม DB ทั้งหมดจะได้รับลายข้าม 3 ไดรฟ์ (และสะท้อนไปทั่วอีก 3 ในอาร์เรย์) แม้ว่าทางเลือกที่ 2 ดูเหมือนว่าจะเลียนแบบภูมิปัญญาดั้งเดิม (ซึ่งดูเหมือนจะมากขึ้นในการใช้เครื่องจักรกล ไดรฟ์กว่า SSD) ดูเหมือนว่ากองมากเกินได้หายไปพร้อมกับตัวเลือกที่ 1

ฉันเดาด้วย SSD แล้วก็โอเคที่จะวางทุกอย่างไว้ในไดรฟ์แบบลอจิคัลเดียวเนื่องจากเซิร์ฟเวอร์ของคุณอาจมีข้อ จำกัด ของ CPU มากกว่าข้อ จำกัด ของ I / O ในตอนนั้น?

คำถามอื่นที่ฉันมีคือฉันควรสำรองข้อมูลทุกคืนที่ไหน? เราไม่ต้องการให้แบ็กอัพชะลอตัวส่วนที่เหลือของเซิร์ฟเวอร์ SQL และฉันเดาว่าการเขียนแบ็คอัพในตำแหน่งเดียวกับบันทึกเป็นวิธีปฏิบัติที่ดีเพราะพฤติกรรมการอ่าน / เขียนในทั้งสองกรณีนั้นเป็นลำดับการเขียน

sql-server configuration

— ร็อบบี้
แหล่งที่มา

ฉันเคยเชื่อว่ามีประโยชน์ต่อการกระจายเชิงตรรกะ แต่หลังจากการวิจัยที่ค่อนข้างครอบคลุม (Michael อาจยังมีอยู่บ้าง) เราได้ข้อสรุปว่าการกระจายเชิงตรรกะ@ ระดับเป้าหมายไม่ได้ปรับปรุงประสิทธิภาพ ดังนั้นถ้าเรากำลังพูดถึงดิสก์ (หมุน) และคุณต้องการไฟล์ข้อมูล 8 ไฟล์เพื่อใช้ประโยชน์จากความสัมพันธ์หลักมันไม่สำคัญว่ามันเป็น 8 ไฟล์ในโลจิคัลวอลุ่มเดียว (บนฟิสิคัลดิสก์เดียวกัน) หรือถ้า คุณตัดโลจิคัลพาร์ติชัน 8 ไฟล์สำหรับ 8 ไฟล์เหล่านั้น (บนฟิสิคัลดิสก์เดียวกัน) ฉันคิดว่าคุณจะพบว่ามันคล้ายกันกับการลด SSD ของคุณ

— Eric Higgins

9

ภูมิปัญญาดั้งเดิมเกี่ยวกับ RAID นั้นใช้ไม่ได้กับ SSD พวกเขาไม่ต้องการการสตริป (RAID0) พวกเขามีแนวโน้มที่จะล้มเหลวโดยการออกแบบ แต่ RAID-1 มักจะไม่ใช่คำตอบที่ถูกต้องสำหรับ SSD ด้วยเหตุผลสองประการ: a) สิ้นเปลืองลดความจุของอาร์เรย์ SSD (และมีราคาแพง) และ 2) ลักษณะความล้มเหลวของ SSD ไปทางไดรฟ์ทั้งสองในกระจกเงาเพื่อให้เกิดความล้มเหลวในช่วงเวลาที่ใกล้เคียงกันมาก (เช่นความล้มเหลวที่สัมพันธ์กัน) และทำให้อาร์เรย์ทั้งหมดไม่มีประโยชน์ ดูดิฟเฟอเรนเชียล RAID: คิดทบทวน RAID สำหรับ SSD ความน่าเชื่อถือสำหรับการอภิปรายที่ยาวขึ้น บางคนแนะนำให้ใช้Raid-6สำหรับ SSD

นอกจากนี้ภูมิปัญญาดั้งเดิมของรูปแบบไฟล์ SQL Server ไม่ได้ใช้กับ SSD ฉันอยากจะแนะนำให้คุณดูSQL บน SSD: Hot and Crazy Loveและไปที่ลิงก์มาตรฐานในคำตอบนี้

— Remus Rusanu
แหล่งที่มา

จุดดีด้วย RAID 10 ฉันอาจเสี่ยงต่อความล้มเหลวที่สัมพันธ์กันมากขึ้น ขอบคุณสำหรับลิงค์ Differential RAID

— Robbie

8

วิธีการมาตรฐานในการแยกรูปแบบ IO แบบสุ่มสำหรับข้อมูลจากลำดับของบันทึกนั้นไม่ได้ใช้กับ SSD ดังนั้นฉันจะเลือกตัวเลือกที่ 1 ด้วยคำเตือน:

การสำรองข้อมูลต้องเป็นเครื่องที่แยกต่างหาก มีจุดเล็กน้อยในการมีการสำรองข้อมูลที่คุณไม่สามารถเข้าถึงได้ในกรณีที่เซิร์ฟเวอร์เกิดขึ้นเป็นควัน
มีค่าบางอย่างในการแยกข้อมูลและไดรฟ์ล็อกซึ่งความล้มเหลวของอาเรย์ข้อมูลจะช่วยให้คุณสามารถสำรองข้อมูลบันทึกได้
ระวังให้ดีว่าคุณไม่มีเวลาว่าง
ระวังให้ดีว่าคุณมีระดับผู้บริโภคเป็นตัวขับเคลื่อน อย่าคิดว่าพวกเขาจะมีความน่าเชื่อถือเท่ากับองค์กรเทียบเท่ากับหลาย ๆ ค่าใช้จ่าย
ดูSQL ที่ให้ความบันเทิงและให้ข้อมูลอย่างมากเกี่ยวกับ SSD: Hot and Crazy Loveโดย Brent Ozar

ปัญหาของการแยกบันทึกจากข้อมูลที่ใช้ SSD นั้นเป็นเรื่องของ RPO (วัตถุประสงค์ของจุดกู้คืน) สำหรับระบบมากกว่าประสิทธิภาพ หาก RPO ถูกกำหนดในไม่กี่นาทีให้ไปกับหนึ่งแถวลำดับที่ใช้ร่วมกันและทำการสำรองข้อมูลบันทึกทุก ๆ [RPO] นาที หาก RPO ถูกกำหนดในไม่กี่วินาทีไปกับอาร์เรย์ที่แยกต่างหาก

ความจริงแล้วถ้า RPO แน่นฉันจะเก็บ SSD ไว้สำหรับอาร์เรย์ข้อมูลและใช้สปินเนอร์ที่น่าเชื่อถือ (ราคาแพง) คู่ที่เชื่อถือได้สำหรับบันทึก

— Mark Storey-Smith
แหล่งที่มา

การสำรองข้อมูลที่มียังคัดลอกไปยังเครื่องแยกต่างหาก พวกเขาถูกสร้างขึ้นบนเครื่องท้องถิ่นเพื่อให้ฉันสามารถใช้ SQL Compare / Data Compare และย้อนกลับการเปลี่ยนแปลงในกรณีที่เกิดข้อผิดพลาดการถดถอย / ผู้ใช้

— Robbie

นอกจากนี้ RPO ยังกำหนดไว้ในไม่กี่นาที (ฉันคิดว่าแม้ในช่วง 10 นาทีจะยอมรับได้ว่าสถานการณ์ของฉันจะซื่อสัตย์อย่างสมบูรณ์) โพสต์ Hot & Crazy Loveทำให้ฉันคิดถึงความล้มเหลวที่สัมพันธ์กัน จากประสบการณ์ที่ จำกัด ของฉันฉันพบความผิดพลาดของเมนบอร์ดมากกว่า & ความล้มเหลวของระบบทั้งหมด (แหล่งจ่ายไฟ / ไฟกระชากทอดทุกอย่าง) จากนั้นขับล้มเหลวดังนั้นฉันจึงยังคงพยายามกำหนดระดับความหวาดระแวง / การป้องกันที่คุ้มค่าที่สุด

— Robbie

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 อย่างมาก ขึ้นอยู่กับธุรกิจและการใช้งานฐานข้อมูลของคุณบางคนหรือคนจำนวนมากอาจบ่นในช่วงเวลาสำรอง

หวังว่านี่จะช่วยได้

— Nicolas de Fontenay
แหล่งที่มา

6

เรื่องไร้สาระ นี่คือ SSD ไม่ใช่สปินเนอร์

— Mark Storey-Smith

ไม่ไร้สาระแม้จะมี sdd มีจำนวนของประสิทธิภาพที่มาถึงแม้ว่าจะไม่มาก

— Nicolas de Fontenay

2

ถึงแม้จะมีสปินเนอร์การแยกข้อมูลจากดัชนีก็ไม่มีค่าจนกว่าคุณจะเล่นในพื้นที่ SQLCAT กรณีสำหรับการแยก tempdb ก็ไม่เคยถูกตัดอย่างชัดเจนและไม่ค่อยมีผลกับดิสก์จำนวนเล็กน้อย

— Mark Storey-Smith