SAN ที่มีไดรฟ์ SSD สองตัวหรือ HDD ที่ล้าสมัยจำนวนมาก

บริษัท ของฉันกำลังพยายามหาประเภทของ SAN ที่จะซื้อ นี่เป็นเฉพาะสำหรับเซิร์ฟเวอร์ฐานข้อมูลที่กำลังถูก จำกัด IO (ที่เก็บข้อมูลเป็น DAS ในขณะนี้ แต่เรากำลัง จำกัด ขีด จำกัด ของเซิร์ฟเวอร์เดียวและเราต้องการเพิ่มการทำคลัสเตอร์ด้วย)

เราต้องการวิธีแก้ปัญหาที่จะผลิตในระยะยาวประมาณ 3,000 IOPS การดำเนินการฐานข้อมูลส่วนใหญ่ของเราเป็นการอ่าน / เขียนขนาดเล็ก จากการพูดคุยกับวิศวกรของ HP และคนอื่น ๆ ออนไลน์ HP P2000 กับ 24 SAS HD's ในการกำหนดค่า RAID 10 จะส่งมอบความเร็วที่สั้นเพียงประมาณ $ 20K เพิ่มตัวควบคุมและรายการอื่น ๆ เพื่อสร้าง SAN ทำให้เราอยู่ในช่วงงบประมาณสูงสุดที่ $ 30K

แต่ออนไลน์ฉันเห็นว่า SAS SSD หลายตัวมอบความเร็ว 80,000 IOPS + สิ่งนี้เป็นจริงที่คาดหวังหรือไม่ ถ้าเป็นเช่นนั้นจะเป็นจริงหรือไม่ที่จะได้รับ P2000 หรือระดับรายการที่คล้ายกันและโยน SSD บางส่วนเข้าไปในนั้น ฐานข้อมูลของเรามีขนาดเล็กเพียงสองสาม TB ทั้งหมด หากเราทำสิ่งนี้เราจะมีเงินเหลือเพื่อซื้อ SAN ตัวที่สองสำหรับการทำมิเรอร์ / การเฟลโอเวอร์ซึ่งดูเหมือนว่าจะรอบคอบ

ฉันสามารถพูดเฉพาะของสิ่งที่คุณกำลังพยายามทำให้สำเร็จ สุจริตฉันจะไม่พิจารณา HP P2000 / MSA2000 ระดับเริ่มต้นสำหรับจุดประสงค์ของคุณ

อุปกรณ์เหล่านี้มีข้อ จำกัด มากมายและจากมุมมองของชุดคุณลักษณะ SAN ไม่มีอะไรมากไปกว่ากล่องดิสก์ ไม่มีการจัดระดับ, ไม่มีการแคชอัจฉริยะ, สูงสุด 16 ดิสก์ในกลุ่มดิสก์เสมือน , ความสามารถของ IOPS ต่ำ, รองรับ SSD ที่ไม่ดี (โดยเฉพาะในหน่วยที่คุณเลือก)

คุณจะต้องก้าวเข้าสู่HP MSA2040เพื่อดูประสิทธิภาพการทำงานหรือการสนับสนุนอย่างเป็นทางการกับ SSD นอกจากนี้คุณต้องการใช้ iSCSI จริงหรือไม่

DAS อาจเป็นตัวเลือกที่ดีที่สุดของคุณหากคุณสามารถทนต่อการจัดเก็บในตัวเครื่อง พื้นที่เก็บข้อมูลแฟลช PCIe จะอยู่ในงบประมาณของคุณ แต่จะต้องมีการวางแผนความจุอย่างรอบคอบ

คุณสามารถอธิบายรายละเอียดของเซิร์ฟเวอร์จริงของคุณได้หรือไม่? ทำ / รุ่น ฯลฯ

หากการทำคลัสเตอร์เป็นสิ่งที่ต้องมีอีกตัวเลือกหนึ่งคือการทำหน่วย HP MSA2040 แต่ใช้หน่วย SAS แทน iSCSI ค่าใช้จ่ายน้อยกว่ารุ่นอื่น ๆ ช่วยให้คุณสามารถเชื่อมต่อเซิร์ฟเวอร์ 4-8 แห่งมีความหน่วงแฝงและปริมาณงานพิมพ์ที่ยอดเยี่ยมและยังสามารถรองรับ SSD ได้ แม้จะเป็นรุ่น Fiber หรือ iSCSI ยูนิตนี้จะให้ความยืดหยุ่นมากกว่าแบบที่คุณเชื่อมโยง

กฎง่ายๆที่ฉันใช้สำหรับดิสก์ IO คือ:

• 75 IOP ต่อแกนหมุนสำหรับ SATA

• 150 IOP ต่อแกนหมุนสำหรับ FC / SAS

• 1500 IOP ต่อแกนหมุนสำหรับ SSD

เช่นเดียวกับ IOPs ต่ออาร์เรย์ยังพิจารณา IOPs ต่อเทราไบต์ ไม่ใช่เรื่องแปลกที่จะจบลงด้วยอัตราส่วน IOP ที่แย่มากต่อ TB หากทำ SATA + RAID6 สิ่งนี้อาจฟังดูไม่มากนัก แต่คุณมักจะพบกับบางคนที่มองหา 'พื้นที่ว่าง' บนอาเรย์และต้องการใช้งาน เป็นเรื่องปกติที่ผู้คนจะซื้อกิ๊กและไม่สนใจไอโอปส์เมื่อความจริงตรงกันข้ามในระบบองค์กรส่วนใหญ่

จากนั้นเพิ่มค่าใช้จ่ายในการเขียนบทลงโทษสำหรับ RAID:

• 2 สำหรับ RAID1, RAID1 + 0
• 4 สำหรับ RAID5 (หรือ 4)
• 6 สำหรับ RAID6

การลงโทษการเขียนสามารถบรรเทาบางส่วนให้กับแคชการเขียนขนาดใหญ่ที่ดีและในสถานการณ์ที่เหมาะสม หากคุณมีการเขียนตามลำดับ IO (เช่นบันทึกฐานข้อมูล) คุณสามารถลดบทลงโทษการเขียนเหล่านั้นบน RAID 5 และ 6 ได้อย่างมาก หากคุณสามารถเขียนแถบเต็ม (เช่นหนึ่งบล็อกต่อแกนหมุน) คุณไม่จำเป็นต้องอ่านเพื่อคำนวณพาริตี

สมมติว่าเป็นชุด 8 +2 RAID 6 ในการทำงานปกติสำหรับ IO เขียนเดียวคุณต้อง:

• อ่านบล็อก 'อัพเดต'
• อ่านบล็อกพาริตีแรก
• อ่านบล็อกพาริตีที่สอง
• คำนวณความเท่าเทียมกันใหม่
• เขียนทั้งหมด 3 (6 IOs)

ด้วยการเขียนเต็มแถบแคช - เช่น 'ชิ้น' ต่อเนื่อง 8 ขนาดของ RAID RAID คุณสามารถคำนวณพาริตีบนล็อตทั้งหมดโดยไม่จำเป็นต้องอ่าน ดังนั้นคุณต้องการเพียง 10 การเขียน - หนึ่งต่อข้อมูลและสองความเท่าเทียมกัน

สิ่งนี้ทำให้คุณเขียนบทลงโทษ 1.2

คุณต้องจำไว้ว่าการเขียน IO นั้นง่ายต่อการแคช - คุณไม่จำเป็นต้องเอามันลงในดิสก์ทันที มันทำงานภายใต้ข้อ จำกัด ของซอฟต์ไทม์ - ตราบใดที่การเขียนที่เข้ามาโดยเฉลี่ยของคุณไม่เกินความเร็วแกนหมุนมันจะสามารถทำงานที่ 'ความเร็วแคช'

อ่าน IO ในทางกลับกันทำให้เกิดข้อ จำกัด ในช่วงเวลาที่ยากลำบาก - คุณไม่สามารถอ่านจนจบจนกว่าจะมีการดึงข้อมูล อัลกอริธึมการแคชการอ่านและการโหลดแคชมีความสำคัญในจุดนั้น - รูปแบบการอ่านที่คาดการณ์ได้ (เช่นเรียงลำดับตามที่คุณได้รับจากการสำรองข้อมูล) สามารถคาดการณ์และดึงข้อมูลล่วงหน้าได้ แต่รูปแบบการอ่านแบบสุ่มไม่สามารถทำได้

สำหรับฐานข้อมูลโดยทั่วไปฉันแนะนำให้คุณสมมติว่า:

• 'ฐานข้อมูล' ของคุณ IO ส่วนใหญ่อ่านแบบสุ่ม (เช่นไม่ดีสำหรับการเข้าถึงแบบสุ่ม) หากคุณสามารถจ่ายค่าใช้จ่ายได้ RAID1 + 0 นั้นดีเพราะดิสก์ที่มิเรอร์จะให้แหล่งที่มาของการอ่านสองแหล่ง

• 'log' IO ส่วนใหญ่ของคุณเป็นการเขียนตามลำดับ (เช่นดีสำหรับการแคชและตรงกันข้ามกับสิ่งที่ DBA จำนวนมากจะแนะนำคุณอาจต้องการ RAID50 มากกว่า RAID10)

อัตราส่วนของทั้งสองนั้นยากที่จะพูดยาก ขึ้นอยู่กับสิ่งที่ฐานข้อมูลทำ

เนื่องจากการสุ่มอ่าน IO เป็นกรณีที่เลวร้ายที่สุดสำหรับการแคชจึงเป็นสิ่งที่ SSD เข้ามาเป็นของตัวเอง - ผู้ผลิตจำนวนมากไม่ต้องกังวลกับการแคช SSD เพราะความเร็วใกล้เคียงกัน ดังนั้นโดยเฉพาะอย่างยิ่งสำหรับสิ่งต่าง ๆ เช่นฐานข้อมูลอุณหภูมิและดัชนี SSD ให้ผลตอบแทนการลงทุนที่ดี

การวิเคราะห์ของคุณค่อนข้างถูกต้อง

ใช้ HDD สองสามตัวสำหรับ GB จำนวนมากและ HDD จำนวนมากถึงไม่กี่ IOPS
ใช้ SSD สองสามตัวสำหรับ IOP จำนวนมากและ SSD จำนวนมากสำหรับไม่กี่ GB

สิ่งใดที่สำคัญสำหรับคุณ Space เป็นตัวขับเคลื่อนต้นทุนขนาดใหญ่สำหรับโซลูชัน SSD เนื่องจากราคาต่อ GB สูงกว่ามาก หากคุณกำลังพูดถึงฐานข้อมูล 200GB ที่ต้องการ 4K IOPs SSD หนึ่งคู่จะพาคุณไปที่นั่น หรือดิสก์ไดรฟ์ 24K จำนวน 15K ทำให้คุณมีพื้นที่เก็บข้อมูลจำนวนมาก

จำนวน IOps ที่คุณจะได้รับจาก SSD นั้นแตกต่างกันมากตามโครงสร้างการจัดเก็บ (ewwhite จะอธิบายอย่างละเอียด) แต่ก็สมเหตุสมผลที่จะรับความเร็วเหล่านั้น โดยเฉพาะอย่างยิ่งกับ Raid10 ที่ไม่มีการคำนวณความเท่าเทียมกัน

ฉันเพิ่งสร้างเซิร์ฟเวอร์จัดเก็บข้อมูลคู่หนึ่งสำหรับนายจ้างของฉันโดยใช้แชสซีของ Dell C2100 ใช้ FreeBSD 10.1 โดยมีไดรฟ์ SATA องค์กร "SE" ขนาด 12TB 2200 7200rpm ของ Western Digital ไดรฟ์อยู่ในพูล ZFS เดียวซึ่งประกอบด้วยอุปกรณ์เสมือน 6-drive RAIDZ-2 สอง (vdevs) ที่ติดกับพูลเป็นคู่ของ Intel DC S3500 SSDs ซึ่งมี supercap ป้องกันการสูญเสียพลังงานพวกมันถูกใช้เป็นทั้ง SLOG และ L2ARC โหลดการทดสอบเซิร์ฟเวอร์นี้ผ่าน iSCSI ฉันสามารถกด 7500-8200 IOPS ได้ ค่าใช้จ่ายทั้งหมดของเรารวมถึงฮาร์ดไดรฟ์อยู่ที่ประมาณ $ 2700 ต่อเซิร์ฟเวอร์

ในช่วงเวลาที่ระบบที่ใช้ BSD เหล่านี้ทำงานหนึ่งในหน่วย HP MSA2012i SAN ของเราได้พบกับข้อผิดพลาดของตัวควบคุมสองตัวและหน่วย MSA2012i อื่น ๆ ของเราเสียหายปริมาณ NTFS ขนาดใหญ่ซึ่งต้องใช้เวลา 12 ชั่วโมงในการซ่อมแซม

Dell และ HP ขายฮาร์ดแวร์ 10% ให้คุณและสัญญาการสนับสนุน 90% ที่คุณจะไม่สามารถใช้ประโยชน์ได้