วิธีปฏิบัติมาตรฐานในการแยกไฟล์บันทึกและข้อมูลเพื่อแยกดิสก์ออกจากระบบปฏิบัติการ (tempdb, แบ็กอัพและสลับไฟล์ด้วย) ตรรกะนี้ยังคงสมเหตุสมผลเมื่อไดรฟ์ของคุณใช้ SAN ทั้งหมดและ LUNS ของคุณไม่ได้แกะสลักดิสก์ - พวกเขาเป็นเพียงส่วนหนึ่งของจำนวน x ไดรฟ์ใน SAN และ LUN เป็นเพียงการจัดสรรพื้นที่
คำตอบ:
บันทึกและไดรฟ์ข้อมูลมีรูปแบบการเข้าถึงข้อมูลที่แตกต่างกันซึ่งขัดแย้งกัน (อย่างน้อยก็ในทางทฤษฎี) เมื่อพวกเขาแชร์ไดรฟ์
บันทึกการเขียน
การเข้าถึงบันทึกประกอบด้วยการเขียนเรียงลำดับขนาดเล็กจำนวนมาก ค่อนข้างง่ายบันทึก DB เป็นบัฟเฟอร์แหวนที่มีรายการคำสั่งในการเขียนรายการข้อมูลออกไปยังตำแหน่งเฉพาะบนดิสก์ รูปแบบการเข้าถึงประกอบด้วยการเขียนเรียงลำดับขนาดเล็กจำนวนมากซึ่งต้องรับประกันว่าจะเสร็จสมบูรณ์ - ดังนั้นจึงถูกเขียนลงดิสก์
ตามหลักแล้วบันทึกควรอยู่ในความเงียบ (เช่นไม่ได้แบ่งปันกับสิ่งอื่น) โวลุ่ม RAID-1 หรือ RAID-10 คุณสามารถดูกระบวนการในขณะที่ DBMS หลักเขียนรายการบันทึกและเธรดตัวอ่านบันทึกอย่างน้อยหนึ่งเธรดที่ใช้บันทึกและเขียนการเปลี่ยนแปลงออกไปยังดิสก์ข้อมูล (ในทางปฏิบัติกระบวนการถูกปรับให้เหมาะสมเพื่อให้การเขียนข้อมูลถูกเขียน ออกไปทันทีที่เป็นไปได้) หากมีปริมาณการใช้งานอื่น ๆ บนดิสก์บันทึกหัวจะถูกย้ายไปรอบ ๆ โดยการเข้าถึงอื่น ๆ เหล่านี้และการเขียนบันทึกตามลำดับกลายเป็นการสุ่มเขียนบันทึก สิ่งเหล่านี้ช้ากว่ามากดังนั้นดิสก์บันทึกที่ไม่ว่างสามารถสร้างฮอตสปอตซึ่งทำหน้าที่เป็นคอขวดในระบบทั้งหมด
Data Writes
(อัปเดต) บันทึกการเขียนจะต้องส่งไปยังดิสก์ (เรียกว่าสื่อที่มั่นคง) เพื่อให้การทำธุรกรรมมีความถูกต้องและมีสิทธิ์ในการส่ง หนึ่งสามารถดูเหตุผลนี้เป็นรายการบันทึกการเขียนและใช้เป็นคำแนะนำในการเขียนหน้าข้อมูลออกไปยังดิสก์โดยกระบวนการไม่ตรงกัน ในทางปฏิบัติแล้วการเขียนหน้าดิสก์จะถูกจัดทำขึ้นจริงและถูกบัฟเฟอร์ในเวลาที่มีการสร้างรายการบันทึก แต่ไม่จำเป็นต้องเขียนทันทีเพื่อให้การทำธุรกรรมเกิดขึ้น บัฟเฟอร์ดิสก์ถูกเขียนลงในสื่อที่มีเสถียรภาพ (ดิสก์) โดยกระบวนการ Lazy Writer (ขอบคุณ Paul Randal สำหรับการชี้จุดนี้) ซึ่งบทความ Technet นี้กล่าวถึงรายละเอียดเพิ่มเติมเล็กน้อย
นี่เป็นรูปแบบการเข้าถึงที่สุ่มมากดังนั้นการแชร์ฟิสิคัลดิสก์เดียวกันกับไฟล์บันทึกจึงสามารถสร้างคอขวดเทียมในประสิทธิภาพของระบบ รายการบันทึกจะต้องเขียนสำหรับการทำธุรกรรมที่จะกระทำการเพื่อให้มีการสุ่มพยายามชะลอกระบวนการนี้ (สุ่ม I / O เป็นมากช้ากว่าบันทึกลำดับ I / O) จะเปิดล็อกจาก sequenital ลงในอุปกรณ์ที่เข้าถึงโดยสุ่ม สิ่งนี้จะสร้างคอขวดของประสิทธิภาพที่ร้ายแรงในระบบไม่ว่างและควรหลีกเลี่ยง เช่นเดียวกับเมื่อแบ่งปันพื้นที่ชั่วคราวที่มีปริมาณการบันทึก
บทบาทของการแคช
ตัวควบคุม SAN มักจะมีแคช RAM ขนาดใหญ่ซึ่งสามารถรองรับปริมาณการใช้งานการเข้าถึงแบบสุ่มในระดับหนึ่ง อย่างไรก็ตามสำหรับความสมบูรณ์ของทรานแซคชันมันเป็นที่พึงปรารถนาที่จะมีการเขียนดิสก์จาก DBMS รับประกันว่าจะเสร็จสมบูรณ์ เมื่อคอนโทรลเลอร์ถูกตั้งค่าให้ใช้การแคชการเขียนกลับบล็อกสกปรกจะถูกแคชและการรายงาน I / O จะถูกรายงานว่าเสร็จสมบูรณ์ไปยังโฮสต์
สิ่งนี้สามารถทำให้ปัญหาการช่วงชิงเป็นจำนวนมากได้อย่างราบรื่นเนื่องจากแคชสามารถดูดซับ I / O จำนวนมากที่จะออกไปที่ดิสก์ทางกายภาพ นอกจากนี้ยังสามารถปรับความเท่าเทียมกันในการอ่านและเขียนสำหรับ RAID-5 ซึ่งลดผลกระทบต่อประสิทธิภาพการทำงานที่โวลุ่ม RAID-5 มี
นี่คือลักษณะที่ขับเคลื่อน 'ให้ SAN จัดการกับมัน' โรงเรียนแห่งความคิดโดยที่มุมมองนี้มีข้อ จำกัด บางประการ:
แคชการเขียนกลับยังคงมีโหมดความล้มเหลวที่อาจสูญเสียข้อมูลและคอนโทรลเลอร์ได้ทำหน้าที่เป็น DBMS โดยบอกว่ามีการเขียนบล็อกลงดิสก์ในความเป็นจริง ด้วยเหตุนี้คุณอาจไม่ต้องการใช้แคชการเขียนกลับสำหรับแอปพลิเคชันการทำธุรกรรมโดยเฉพาะอย่างยิ่งสิ่งที่เก็บข้อมูลภารกิจสำคัญหรือข้อมูลทางการเงินซึ่งปัญหาความสมบูรณ์ของข้อมูลอาจมีผลกระทบร้ายแรงต่อธุรกิจ
SQL Server (โดยเฉพาะ) ใช้ I / O ในโหมดที่แฟล็ก (เรียกว่า FUA หรือ Forced Update Access) บังคับให้เขียนทางกายภาพไปยังดิสก์ก่อนที่การโทรจะส่งกลับ ไมโครซอฟท์มีโปรแกรมการรับรองและหลาย SAN ผู้จำหน่ายฮาร์ดแวร์การผลิตที่ได้รับเกียรตินิยมความหมายเหล่านี้ (ต้องการสรุปที่นี่ ) ในกรณีนี้ไม่มีจำนวนแคชที่จะเพิ่มประสิทธิภาพการเขียนดิสก์ซึ่งหมายความว่าปริมาณการใช้งานบันทึกจะฟาดถ้ามันนั่งอยู่บนปริมาณที่ใช้ร่วมกันไม่ว่าง
หากแอปพลิเคชั่นสร้างปริมาณการใช้งานดิสก์จำนวนมากชุดการทำงานอาจล้นแคชซึ่งจะทำให้เกิดปัญหาการเขียน
หาก SAN ถูกแชร์กับแอปพลิเคชั่นอื่น ๆ (โดยเฉพาะอย่างยิ่งในดิสก์โวลุ่มเดียวกัน) การรับส่งข้อมูลจากแอปพลิเคชันอื่นสามารถสร้างคอขวดบันทึกได้
แอปพลิเคชั่นบางตัว (เช่นคลังข้อมูล) สร้างสไปค์โหลดขนาดใหญ่ชั่วคราวซึ่งทำให้พวกมันต่อต้านโซเชียลบน SAN ได้ค่อนข้างมาก
แม้กระทั่งบนโวลุ่มบันทึกแยก SAN ขนาดใหญ่ก็ยังแนะนำให้ใช้ คุณอาจไม่ต้องกังวลกับเลย์เอาต์ในแอพพลิเคชั่นที่ใช้งานเบา ในแอปพลิเคชันขนาดใหญ่จริง ๆ คุณอาจได้รับประโยชน์จากคอนโทรลเลอร์ SAN หลายตัว Oracle เผยแพร่ชุดของโครงร่างคลังข้อมูลกรณีศึกษาที่การกำหนดค่าขนาดใหญ่บางส่วนเกี่ยวข้องกับคอนโทรลเลอร์หลายตัว
รับผิดชอบต่อการแสดงในที่ที่เป็นของมัน
สำหรับบางสิ่งที่มีปริมาณมากหรือประสิทธิภาพอาจทำให้เกิดปัญหาให้ทีม SAN รับผิดชอบต่อประสิทธิภาพของแอปพลิเคชัน หากพวกเขาจะเพิกเฉยต่อคำแนะนำของคุณสำหรับการกำหนดค่าจากนั้นตรวจสอบให้แน่ใจว่าการจัดการตระหนักถึงเรื่องนี้และความรับผิดชอบต่อประสิทธิภาพของระบบอยู่ในสถานที่ที่เหมาะสม โดยเฉพาะอย่างยิ่งให้สร้างแนวทางที่ยอมรับได้สำหรับสถิติประสิทธิภาพของคีย์ DB เช่น I / O waits หรือรอ latch หน้าหรือแอปพลิเคชัน I / O SLA ที่ยอมรับได้
โปรดทราบว่าการมีความรับผิดชอบในการแยกการแสดงข้ามหลายทีมจะสร้างแรงจูงใจให้ใช้นิ้วชี้และส่งเงินให้ทีมอื่น นี่คือรูปแบบการต่อต้านการจัดการที่เป็นที่รู้จักและสูตรสำหรับปัญหาที่ลากออกมาเป็นเดือนหรือเป็นปีโดยที่ไม่ได้รับการแก้ไข ตามหลักแล้วควรมีสถาปนิกเดียวที่มีสิทธิ์ในการระบุการเปลี่ยนแปลงการกำหนดค่าแอปพลิเคชันฐานข้อมูลและ SAN
นอกจากนี้เกณฑ์มาตรฐานระบบภายใต้การโหลด หากคุณสามารถจัดเรียงได้เซิร์ฟเวอร์มือสองและอาร์เรย์ที่แนบโดยตรงสามารถซื้อได้ค่อนข้างถูกบน Ebay หากคุณตั้งค่ากล่องเช่นนี้ด้วยหนึ่งหรือสองอาร์เรย์ดิสก์คุณสามารถ frig ด้วยการกำหนดค่าดิสก์ทางกายภาพและวัดผลกระทบต่อประสิทธิภาพ
ตัวอย่างเช่นฉันได้ทำการเปรียบเทียบระหว่างแอปพลิเคชันที่ทำงานบน SAN ขนาดใหญ่ (IBM Shark) และกล่องสองซ็อกเก็ตที่มีอาร์เรย์ U320 แนบโดยตรง ในกรณีนี้ฮาร์ดแวร์มูลค่า 3,000 ปอนด์ที่ซื้อจาก ebay มีประสิทธิภาพสูงกว่า SAN ระดับไฮเอนด์ 1 ล้านปอนด์โดยใช้สองตัว - บนโฮสต์ที่มี CPU และการกำหนดค่าหน่วยความจำเทียบเท่าโดยประมาณ
จากเหตุการณ์เฉพาะนี้อาจเป็นเรื่องที่ถกเถียงกันอยู่ว่าการมีเรื่องแบบนี้เป็นวิธีที่ดีมากในการทำให้ผู้ดูแลระบบ SAN ซื่อสัตย์
ฉันสมมติว่าแท็ก Equallogic และเนื้อหาของคำขอหมายความว่าคุณกำลังคิดเกี่ยวกับ Equallogic SAN สิ่งที่ตามมานั้นเกี่ยวกับ Equallogic โดยเฉพาะและไม่สามารถใช้กับ SAN ประเภทอื่นได้
ด้วย Equallogic arrays ไม่สามารถระบุดิสก์เฉพาะที่ใช้กับไดรฟ์ได้อย่างแม่นยำเท่าที่พวกเขาสามารถทำได้ด้วยพูดว่า EMC Clariion arrays ดังนั้นวิธีการจึงต้องแตกต่างกันเล็กน้อย
สถาปัตยกรรม Equallogic นั้นอัตโนมัติและมีพลวัตมาก Building Block พื้นฐานของมันคือยูนิตอาร์เรย์ที่ไม่ใช่ RAID pack \ groups ภายในอาร์เรย์ดังที่เห็นใน SAN อื่น ๆ แต่ละอาร์เรย์มีการกำหนดค่าทั้งหมดสำหรับ RAID 5, 6, 10 หรือ 50 แม้ว่านี่จะไม่ได้หมายความว่ามีกลุ่ม RAID เพียงกลุ่มเดียวต่ออาเรย์เท่านั้นคุณไม่เคยตัดสินใจหรือโต้ตอบกับพวกเขาในระดับนั้น คุณใส่อาร์เรย์ลงในกลุ่มการเก็บข้อมูลและกลุ่มของคุณนั้นจะอยู่ในกลุ่มการจัดเก็บข้อมูล กลุ่มการจัดเก็บข้อมูลมีที่อยู่ IP ของ cluster \ virtual ที่คุณใช้เป็นเป้าหมาย iSCSI Discovery สำหรับไดรฟ์ข้อมูลทั้งหมดในกลุ่มนั้น - ซอฟต์แวร์การจัดการกลุ่ม EQL และโฮสต์ MPIO สแต็กจะจัดการกับการแก้ไขระดับ IP ที่จำเป็นสำหรับเส้นทางจริงไปยังพอร์ตที่เหมาะสมที่สุด แต่ละอาร์เรย์เมื่อร้องขอกลุ่มข้อมูล แต่เป็นสิ่งที่คุณมีความสามารถเพียงเล็กน้อยหรือไม่มีเลยในการควบคุม
ปริมาณการจัดเก็บถูกกำหนดจากพื้นที่ว่างทั้งหมดในแต่ละพูล ไดรฟ์ข้อมูลทั้งหมดภายในพูลจะถูกกระจายไปทั่วอาร์เรย์ทั้งหมดในพูลนั้น (มีอาร์เรย์แยกกันสูงสุด 4 อาร์เรย์) เพื่อกระจายเครือข่าย IO ในจำนวนรวมของอินเทอร์เฟซเครือข่ายทั้งหมด (2-4 ต่อ Eql อาร์เรย์ขึ้นอยู่กับรุ่น) และ IO ข้ามตัวควบคุมให้ได้มากที่สุด ซอฟต์แวร์การจัดการ Equallogic จะตรวจสอบประสิทธิภาพของไดรฟ์ข้อมูล \ อาเรย์เมื่อเวลาผ่านไปและปรับการกระจายบล็อกในอาร์เรย์สมาชิกแบบไดนามิก โดยทั่วไปถ้าคุณไม่ทราบว่าคุณกำลังทำอะไรคุณควรใส่อาร์เรย์ทั้งหมดลงในพูลเดียวและปล่อยให้มันทำอย่างนั้นอย่าลืมเพื่อให้แน่ใจว่าคุณกำหนดค่าดิสก์ความเร็วสูง (SAS 10k \ 15k) ด้วย RAID 10 ความเร็วปานกลางด้วย RAID 50 หรือ 5 เพื่อให้แน่ใจว่ากระบวนการปรับให้เหมาะสมเลือกไดรฟ์ประสิทธิภาพสูงจริง
ในการประมาณคร่าวๆคุณจะมีประมาณ 2,500-5,000 IOPs ต่ออาร์เรย์ PS ขึ้นอยู่กับประเภทของไดรฟ์และประเภท RAID หากคุณมี IOP รวมเพียงพอกระบวนการการจัดการอัตโนมัติควรให้ประสิทธิภาพที่ดีในที่สุดแม้ว่าคุณจะเพียงแค่รวบรวมวอลุ่มทั้งหมดไว้ในพูลเดียว
อย่างไรก็ตามหากคุณต้องการรับประกันว่าบันทึกฐานข้อมูลที่เก็บชั่วคราวเทมเพลตระบบปฏิบัติการ ฯลฯ จะแยกออกจากกันคุณสามารถทำบางสิ่งได้ ประการแรกคุณสามารถกำหนดค่ากำหนด RAID สำหรับไดรฟ์ข้อมูลซึ่งจะรับประกันได้ว่าโวลุ่มนั้นจะถูกจัดเก็บเฉพาะในอาร์เรย์ของประเภท RAID นั้น (หากมีอยู่ในพูลที่มีโวลุ่มอยู่) ประการที่สองคุณสามารถกำหนดพูลหน่วยเก็บข้อมูลแบบทำเป็นชั้นที่มีเฉพาะอาร์เรย์ที่ส่งมอบประสิทธิภาพการทำงานที่คุณต้องการสำหรับระดับชั้นนั้นแล้วกระจายปริมาณของคุณไปยังกลุ่มที่เหมาะสม คำเตือนด้านสุขภาพที่มาพร้อมกับวิธีการนี้คือโดยทั่วไปคุณจะต้องใช้อาร์เรย์จำนวนมากเพื่อให้ได้ประสิทธิภาพโดยรวมที่ดีขึ้นซึ่งอาจมีความสำคัญน้อยกว่าคุณมากกว่าการรับประกันประสิทธิภาพในปริมาณที่สำคัญของคุณ ทางเลือก. สถาปัตยกรรมอ้างอิงของ Dell สำหรับ Oracle DB ใช้พูลเดียวที่มีอาร์เรย์ RAID 10 2 อันสำหรับ Data, Voting disk และ OCR และพูลแยกต่างหากที่มีอาร์เรย์ RAID 5 เดียวสำหรับ Flash Recovery Area
ในทุกจุดของ Equallogic คุณควรถามตัวคุณเองว่าการตัดสินใจที่คุณดำเนินการเกี่ยวกับการแบ่งพาร์ติชั่นนั้นจะให้ประสิทธิภาพโดยรวมที่ดีขึ้นสำหรับโวลุ่มของคุณในแง่ของเน็ตเวิร์กอินเตอร์เฟส, แกนหมุนดิสก์และคอนโทรลเลอร์ หากคุณไม่สามารถตอบได้ให้เลือกจำนวนขั้นต่ำของพูลและปล่อยให้จัดการกับรายละเอียดหรือรับผู้เชี่ยวชาญ Equallogic ในการออกแบบจริง หากคุณมีเพียงหนึ่งอาเรย์ก็ไม่มีอะไรที่คุณสามารถทำได้ในแง่ของการแยกโวลุ่ม
เราจัดเก็บ DBs ของเราไว้ในกล่อง SAN เดี่ยว แต่ด้วยข้อมูลแยกบันทึกและสำรอง LUNs แต่ละกลุ่มดิสก์ที่แตกต่างกันจัดทำเป็นชั้นโดยความเร็ว - มีบันทึกของเราบน RAID 10 15Krpm LUNs ข้อมูลบน RAID 1 10 / 15krpm LUNs 5 7.2krpm LUNs นอกจากนี้เรายังนำเสนอบันทึกและข้อมูลผ่านตัวควบคุมที่แตกต่างกันใน SAN เดียวกัน
เป็นคำถามที่ดีมาก!
ก่อนอื่นให้ดูที่การถกเถียงเรื่อง"Steel Cage BlogMatch"ของ Brent Ozar ในประเด็นนี้
ที่ บริษัท ของเราสำหรับเซิร์ฟเวอร์ส่วนใหญ่เราใส่ Data และบันทึกไว้ในไดรฟ์ SAN เดียวกันและปล่อยให้ทีม SAN เพื่อให้แน่ใจว่าทุกอย่างทำงานได้ถูกต้อง
ฉันเริ่มคิดว่านี่ไม่ใช่กลยุทธ์ที่ดีที่สุดโดยเฉพาะอย่างยิ่งสำหรับเซิร์ฟเวอร์ที่มีปริมาณมากขึ้น ปัญหาพื้นฐานคือฉันไม่มีทางพิสูจน์ได้ว่าทีม SAN กำลังทำอะไรมากกว่าการตบไดรฟ์เข้าด้วยกันสำหรับพื้นที่ที่เราต้องการ เราไม่เรียกใช้เกณฑ์เปรียบเทียบ IO กับไดรฟ์ SAN จากด้านข้างของเราหรืออะไรเราแค่คิดว่าพวกเขากำลัง "ทำงานของพวกเขา" (การปรับประสิทธิภาพและพื้นที่) ซึ่งอาจจะไร้เดียงสา
ความคิดอื่น ๆ ของฉันคือประเภทของการเข้าถึงข้อมูลและบันทึกที่ต้องการนั้นแตกต่างกัน ฉันจะพยายามหาบทความที่ฉันอ่านเมื่อเร็ว ๆ นี้ซึ่งกำลังพูดถึงว่าไดรฟ์สองประเภทที่แตกต่างกันนั้นควรได้รับการปรับให้เหมาะสมในรูปแบบที่แตกต่างกันมากอย่างไร (ฉันคิดว่า .)
ในระยะสั้นใช่คุณจะสร้างปริมาณที่แยกต่างหากสำหรับไฟล์ข้อมูล SQL Server, ไฟล์บันทึกและข้อมูล TempDB และไฟล์บันทึก
เมื่อคุณติดแท็กคำถามของคุณด้วย Equallogic โปรดอ่านคู่มือสถาปัตยกรรมอ้างอิงของ Dellฟรี: การปรับใช้Microsoft® SQL Server®ด้วย Dell ™ EqualLogic ™ PS5000 Series Storage Arrays (จำเป็นต้องลงทะเบียน) ก่อนที่จะออกแบบโซลูชันของคุณ บ่อยครั้งที่คุณจะพบว่าคำแนะนำเกี่ยวกับการกำหนดค่าที่เฉพาะเจาะจงสามารถแตกต่างกันอย่างมีนัยสำคัญจากคำแนะนำทั่วไป
ฉันจะเห็นด้วยกับ BradC (+1) ในแง่ของประสิทธิภาพ โดยทั่วไป SAN ที่ดีจะมี I / O ดิบมากกว่าที่คุณคาดไว้
มันเป็นความคิดที่ดีที่จะแยกแบ็คอัพของคุณออกจากระบบถ่ายทอดสดของคุณ (เห็นได้ชัดว่าฉันรู้ แต่ถ้าฉันมี£ 1 ทุกครั้งที่ฉันเห็นสิ่งนี้ ... )
นอกจากนี้ยังแนะนำให้เก็บ tempdb ให้ห่างจากไฟล์บันทึกขอแนะนำ เต็นท์คนที่แต่งตัวประหลาดของ SAN จะหันมามองคุณเมื่อคุณเริ่มต้องการ "ถังที่แตกต่าง" (ศัพท์ทางเทคนิค) สำหรับบันทึกข้อมูลและอุณหภูมิ แต่ถ้าคุณบอกพวกเขามันจะทำให้คุณสามารถวัดปริมาณข้อมูลที่แตกต่างกันของ IO ไปในแต่ละพื้นที่และ ให้พวกเขาแสดงกราฟประสิทธิภาพที่เป็นแฟนซีของพวกเขา!
เพียงตรวจสอบสองครั้ง / สองครั้งว่าคนที่แต่งตัวประหลาด SAN ได้ตั้งค่าที่เหมาะสมสำหรับคุณ หากคุณต้องการ RAID 10 ให้ยืนยัน (ฉันทำ) แม้ว่าพวกเขาจะคอยบอกว่า RAID 5 ของพวกเขาไม่มีประสิทธิภาพ
(สำหรับการดำเนินงาน "ตามไฟล์" RAID 5 นั้นใช้ได้สำหรับการเขียนที่เข้มข้นทันทีที่คุณเติมบัฟเฟอร์การเขียนของคุณจนเต็ม!
ระวังการผสมคำศัพท์ทั้งหมดที่นี่ด้วย ..
โดยทั่วไปและพื้นฐานมาก:
คุณสามารถมีหลายวอลุ่มในอาเรย์เดียวกันซึ่งเป็นสิ่งที่ต้องจดจำเมื่อคุณทำการปรับแต่งคุณภาพสูงที่กล่าวถึงในหัวข้อนี้
กุญแจสำคัญคือสิ่งที่คนอื่นพูดถึง (อย่าลืม) แยกข้อมูล / บันทึก / สำรองข้อมูลในแกนไดรฟ์ที่แตกต่างกันไม่ใช่แค่แยกโวลุ่ม
แก้ไข: และ Helvick ด้านบนให้คำตอบที่ดีเกี่ยวกับ Equallogic SAN!