หลายครั้งในอาชีพการงานของฉัน ตอนนี้ฉันเจอชุด mdadm RAID (RAID1+0, 5, 6 และอื่นๆ) ในสภาพแวดล้อมต่างๆ (เช่น กล่อง CentOS/Debian, Synology/QNAP NASes) ซึ่งดูเหมือนจะไม่สามารถจัดการกับดิสก์ที่ล้มเหลวได้ นั่นคือดิสก์ที่ยังไม่ตายทั้งหมด แต่มีเซกเตอร์เสียนับหมื่นและไม่สามารถจัดการ I/O ได้ แต่ยังไม่ตายทั้งหมด มันยังใช้งานได้อยู่ บันทึกเคอร์เนลโดยทั่วไปเต็มไปด้วยข้อผิดพลาด UNC
บางครั้ง SMART จะระบุว่าดิสก์ล้มเหลว ในบางครั้งจะไม่มีอาการอื่นใดนอกจาก I/O ช้า
I/O ที่ช้าทำให้ทั้งระบบค้าง การเชื่อมต่อผ่าน ssh จะใช้เวลาตลอดไป webGUI (ถ้าเป็น NAS) จะหยุดทำงานตามปกติ การรันคำสั่งผ่าน ssh จะใช้เวลาตลอดไปเช่นกัน นั่นคือจนกว่าฉันจะตัดการเชื่อมต่อ / ตั้งใจ "ล้มเหลว" ของดิสก์ออกจากอาร์เรย์ จากนั้นสิ่งต่างๆ จะกลับไปเป็น "ปกติ" ซึ่งเป็นเรื่องปกติที่สามารถทำได้กับอาร์เรย์ที่เสื่อมคุณภาพ
ฉันแค่สงสัยว่าถ้าดิสก์ใช้เวลานานมากในการอ่าน/เขียน ทำไมไม่ลองเคาะมันออกจากอาร์เรย์ วางข้อความในบันทึกแล้วดำเนินการต่อ ดูเหมือนว่าจะทำให้ทั้งระบบต้องหยุดทำงานเพราะดิสก์หนึ่งตัวค่อนข้างที่จะขันได้ ทำให้หนึ่งในประโยชน์หลัก ๆ ของการใช้ RAID เป็นโมฆะ (ความทนทานต่อข้อผิดพลาด - ความสามารถในการทำงานต่อไปหากดิสก์ล้มเหลว) ฉันเข้าใจได้ว่าในสถานการณ์ที่มีดิสก์เดียว (เช่น ระบบของคุณมีดิสก์ SATA เดียวที่เชื่อมต่ออยู่ และไม่สามารถดำเนินการอ่าน/เขียนได้อย่างถูกต้อง) นี่เป็นหายนะ แต่ในชุด RAID (โดยเฉพาะ "บุคลิกภาพ" ที่ทนต่อข้อผิดพลาด) ไม่เพียงแต่ดูน่ารำคาญเท่านั้นแต่ยังขัดกับสามัญสำนึกด้วย
มีเหตุผลที่ดีหรือไม่ที่พฤติกรรมเริ่มต้นของ mdadm คือการทำให้กล่องพิการโดยทั่วไปจนกว่าจะมีคนรีโมทเข้ามาและแก้ไขด้วยตนเอง
โดยทั่วไป จุดประสงค์ของก การโจมตีขึ้นอยู่กับระดับ Raid ที่เลือก ให้ความสมดุลที่แตกต่างกันระหว่างเป้าหมายหลัก ความซ้ำซ้อนของข้อมูล, ความพร้อมใช้งาน, ประสิทธิภาพ และ ความจุ.
ตามข้อกำหนดเฉพาะก็คือ ความรับผิดชอบของเจ้าของพื้นที่จัดเก็บ เพื่อตัดสินใจว่าความสมดุลของปัจจัยต่างๆ นั้นเหมาะสมสำหรับวัตถุประสงค์ที่กำหนด เพื่อสร้าง ก เชื่อถือได้ สารละลาย.
งานของโซลูชัน Raid ที่เลือก (ในกรณีนี้เราพูดถึงซอฟต์แวร์ คุณนาย) คือการปกป้องข้อมูลเป็นอันดับแรกและสำคัญที่สุด ด้วยเหตุนี้ จึงเป็นที่ชัดเจนว่าไม่ใช่หน้าที่ของโซลูชันการโจมตีที่จะถ่วงน้ำหนักความต่อเนื่องทางธุรกิจมากกว่าความสมบูรณ์ของข้อมูล
กล่าวอีกนัยหนึ่ง: งานของ mdadm คือการหลีกเลี่ยงการจู่โจมที่ล้มเหลว ตราบใดที่ "ดิสก์พฤติกรรมประหลาด" ยังไม่พัง มันยังคงมีส่วนช่วยในการจู่โจม
เหตุใดจึงไม่เพียงแค่เคาะดิสก์ที่มีพฤติกรรมแปลก ๆ ออกจากอาร์เรย์ วางข้อความในบันทึกและดำเนินการต่อ เนื่องจากการทำเช่นนั้นจะเพิ่มความเสี่ยงในการสูญเสียข้อมูล
ฉันหมายความว่าคุณพูดถูก จากมุมมองทางธุรกิจ ดูเหมือนว่าจะเป็นทางออกที่ดีกว่าในการดำเนินการต่ออย่างไรก็ตาม ในความเป็นจริง ข้อความที่ทิ้งลงในบันทึกอาจยังคงตรวจไม่พบ ดังนั้นสถานะที่ลดลงของการจู่โจมจึงยังคงตรวจไม่พบ ในเวลาต่อมา ในที่สุดดิสก์อื่นในการโจมตีเดียวกันก็ล้มเหลว ส่งผลให้ข้อมูลที่จัดเก็บในการโจมตีล้มเหลวหายไปในที่สุด
นอกจากนั้น: เป็นการยากที่จะระบุว่าอะไรคือ "ดิสก์ที่มีพฤติกรรมแปลกประหลาด" แสดงเป็นอย่างอื่น: อะไรคือพฤติกรรมการทำงานที่ยอมรับได้ของดิสก์เดี่ยวที่ดำเนินการภายในอาร์เรย์ของดิสก์
พวกเราบางคนอาจตอบว่า "ดิสก์แสดงข้อผิดพลาดบางอย่าง" คนอื่นอาจตอบว่า: "ตราบใดที่สามารถแก้ไขข้อผิดพลาดได้ ทุกอย่างก็ปกติดี" คนอื่นอาจตอบว่า: "ตราบใดที่ดิสก์ตอบรับคำสั่งทั้งหมดในเวลาที่กำหนด ทุกอย่างก็ปกติดี" คนอื่นพูดว่า "ในกรณีที่อุณหภูมิของดิสก์แตกต่างกันมากกว่า 5°C เมื่อเทียบกับอุณหภูมิเฉลี่ยของดิสก์ทั้งหมดภายในอาร์เรย์เดียวกัน" อีกคำตอบหนึ่งอาจเป็น "ตราบใดที่สครับไม่พบข้อผิดพลาด" หรือ "ตราบใดที่ SMART ไม่แสดงข้อผิดพลาด"
สิ่งที่เขียนไม่ยาวและไม่ใช่รายการที่สมบูรณ์
ประเด็นก็คือ คำจำกัดความของ "พฤติกรรมที่ยอมรับได้ของดิสก์" เป็นเรื่องของการตีความ ดังนั้นจึงเป็นความรับผิดชอบของเจ้าของพื้นที่เก็บข้อมูลด้วย ไม่ใช่สิ่งที่ mdadm ควรจะตัดสินใจด้วยตัวเอง
ปัญหาสำคัญคือ ดิสก์ไดร์ฟ SATA ที่ล้มเหลวในบางครั้งอาจหยุดบัสทั้งหมดในช่วงระยะเวลาของขั้นตอนการกู้คืนข้อผิดพลาดภายใน ด้วยเหตุนี้จึงควรใช้ เปิดใช้งาน TLER ไดรฟ์ในอาร์เรย์ RAID เท่านั้น (และควรเป็นรุ่นระดับองค์กร)
ไดรฟ์ SAS ประสบปัญหานี้น้อยลง แต่ก็ไม่ได้ปราศจากปัญหานี้เช่นกัน
นอกเหนือจากที่กล่าวไว้ ฉันต้องการเพิ่มเงินของฉัน แต่สิ่งนี้เป็นการพิจารณาที่สำคัญ
อะไร การขับ เมื่อเซกเตอร์อ่านช้า?
น่าจะเป็นไดรฟ์ที่ออกแบบมาเพื่อใช้งานคนเดียว e. กรัม ไดรฟ์ "เดสก์ท็อป" ทั่วไป ให้สันนิษฐานไว้ก่อนว่าไม่มีวิธีอื่นในการดึงข้อมูลที่จัดเก็บไว้ในเซกเตอร์เสียนั้น พวกเขาจะพยายามดึงข้อมูลโดยเสียค่าใช้จ่ายทั้งหมด ทำซ้ำครั้งแล้วครั้งเล่าเป็นระยะเวลานาน แน่นอนว่าพวกเขาจะทำเครื่องหมายว่าเซกเตอร์นั้นล้มเหลวด้วย ดังนั้นพวกเขาจะแมปใหม่อีกครั้งในครั้งต่อไปที่คุณเขียน แต่คุณต้องเขียนเพื่อสิ่งนั้น จนกว่าคุณจะเขียนใหม่ พวกเขาจะสำลักทุกครั้งที่คุณอ่านจากสถานที่นั้น ในการตั้งค่า RAID หมายความว่าสำหรับ RAID ไดรฟ์ยังคงใช้งานได้และไม่มีเหตุผลที่จะต้องยกเลิก แต่สำหรับแอปพลิเคชัน อาร์เรย์จะช้าลงจนรวบรวมข้อมูลได้
ในทางกลับกัน ไดรฟ์ "องค์กร" โดยเฉพาะไดรฟ์ "แบรนด์" มักจะคิดว่าไดรฟ์เหล่านี้ใช้ในการตั้งค่า RAID เสมอ ตัวควบคุม "แบรนด์" เห็นไดรฟ์ "แบรนด์" จริง ๆ แล้วอาจจะด้วยซ้ำ แจ้ง เฟิร์มแวร์ของพวกเขาเกี่ยวกับการมีอยู่ของ RAID ดังนั้นไดรฟ์จะหยุดทำงานก่อนกำหนดและรายงานข้อผิดพลาด I/O แม้ว่าจะสามารถพยายามอีกหลายครั้งและอ่านเซกเตอร์ได้ จากนั้นคอนโทรลเลอร์จะมีโอกาสตอบกลับเร็วขึ้น ทำมิเรอร์การอ่านคำสั่งไปยังไดรฟ์พี่น้อง (และไล่อันที่เสียออกจากอาร์เรย์) เมื่อคุณดึงออกและสำรวจ/ทดสอบไดรฟ์ที่เตะอย่างละเอียด คุณจะไม่พบปัญหาใดๆ ที่ชัดเจน – เป็นเพียงการชะลอตัวลงชั่วขณะและนั่นก็เพียงพอแล้วที่จะหยุดใช้งาน ตามตรรกะของคอนโทรลเลอร์
ฉันเดาว่านี่อาจจะเป็น เพียง ความแตกต่างระหว่างไดรฟ์ "เดสก์ท็อป" กับ "แบรนด์"/"องค์กร" NL-SAS และ SATA นี่อาจเป็นเหตุผลว่าทำไมคุณถึงจ่ายเพิ่มขึ้นสามเท่าเมื่อคุณซื้อไดรฟ์ "HPE" ซึ่งผลิตโดย Toshiba จริง ๆ เมื่อเทียบกับการซื้อไดรฟ์ที่มีตราสินค้า "Toshiba"
อย่างไรก็ตาม ไดร์ฟบางไดร์ฟรองรับการควบคุมทั่วไปบางประการ มันถูกเรียกว่า SCT ERC ซึ่งใช้สำหรับ การควบคุมการกู้คืนข้อผิดพลาดในการขนส่งคำสั่ง SMART. นี่คือลักษณะที่ปรากฏ สมาร์ทคอนโทรล:
ไม่รองรับ
# smartctl --all /dev/sda
=== จุดเริ่มต้นของการอ่านข้อมูลสมาร์ทส่วน ===
ความสามารถของ SCT: (0x3037) รองรับสถานะ SCT
รองรับการควบคุมคุณสมบัติ SCT
รองรับตารางข้อมูล SCT
ได้รับการสนับสนุน
=== จุดเริ่มต้นของการอ่านข้อมูลสมาร์ทส่วน ===
...
ความสามารถของ SCT: (0x003d) รองรับสถานะ SCT
รองรับการควบคุมการกู้คืนข้อผิดพลาด SCT
รองรับการควบคุมคุณสมบัติ SCT
รองรับตารางข้อมูล SCT
หากคุณโชคดี คุณสามารถควบคุมฟีเจอร์นี้ได้ด้วย สมาร์ทคอนโทรล. คุณสามารถเรียกดูหรือตั้งค่าการหมดเวลาได้ 2 ครั้ง ระยะเวลาที่จะพยายามอ่านซ้ำ และระยะเวลาที่จะพยายามเขียนซ้ำ:
# smartctl -l ssterc /dev/sda
การควบคุมการกู้คืนข้อผิดพลาด SCT:
อ่าน: 70 (7.0 วินาที)
เขียน: 70 (7.0 วินาที)
# smartctl -l ssterc /dev/sde
การควบคุมการกู้คืนข้อผิดพลาด SCT:
อ่าน: ปิดการใช้งาน
เขียน: ปิดการใช้งาน
# smartctl -l ssterc /dev/sdd
คำเตือน: อุปกรณ์ไม่รองรับคำสั่ง SCT Error Recovery Control
smartctl -l scterc,120,60 /dev/sde
ซึ่งหมายความว่า: 120 ในสิบของวินาทีเพื่อลองอ่านใหม่ 60 ในสิบวินาทีเพื่อลองเขียนใหม่ ศูนย์หมายถึง "ลองใหม่จนกว่าคุณจะตาย" ไดรฟ์ที่แตกต่างกันมีการตั้งค่าเริ่มต้นที่แตกต่างกันสำหรับสิ่งนี้
ดังนั้น หากคุณใช้ไดรฟ์ "รุ่น RAID" เพียงอย่างเดียว ควรตั้งค่าการหมดเวลาของ ERC เป็นศูนย์ มิฉะนั้นคุณอาจสูญเสียข้อมูล ในทางกลับกัน หากคุณใช้ไดรฟ์ใน RAID คุณควรตั้งค่าที่ไม่ใช่ศูนย์ในระดับต่ำที่เหมาะสม
ที่มาโดย amarao @ Habrahabr ในภาษารัสเซีย.
ป.ล. และหมายเหตุเกี่ยวกับ SAS ใช้ เอสดีปาร์มรองรับการควบคุมมากกว่านี้
ฉันเคยมีสถานการณ์ที่ดิสก์ใช้งานไม่ได้ แต่ได้นำคอนโทรลเลอร์ออกไปในทางใดทางหนึ่ง
ในอดีต สิ่งนี้เกิดขึ้นได้กับ PATA ซึ่งไดรฟ์หลักและไดรฟ์สเลฟอยู่บนสายเคเบิลเส้นเดียวกัน และไดรฟ์หนึ่งเสียอาจรบกวนการเข้าถึงไดรฟ์อื่นที่ยังใช้งานได้ดี การถอดไดร์ฟเสียออกอาจทำให้สามารถเข้าถึงไดร์ฟที่เหลือได้อีกครั้ง หรืออาจต้องใช้วงจรพลังงาน แต่การจู่โจมอาจลดลงและการกู้คืนอาจเริ่มต้นขึ้น
SATA มีความเสี่ยงน้อยกว่า แต่ก็ยังเป็นไปได้ที่คอนโทรลเลอร์จะได้รับผลกระทบ จากประสบการณ์ของฉันในการจู่โจมซอฟต์แวร์ มีอวัยวะภายในที่เต็มไปด้วยเลือดจำนวนมากที่ถูกเปิดเผยซึ่งจะถูกซ่อนไว้โดยผู้ควบคุมการโจมตีที่คลั่งไคล้โดยเฉพาะ
ฉันไม่เคยประสบปัญหานี้กับ SAS หรือ NVME แต่ SAS มักจะหมายถึงตัวควบคุมการโจมตีด้วยฮาร์ดแวร์ที่มีความฉลาดในการจัดการดิสก์มากกว่าภายใน
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
