NAS ZFS ขนาด 71 TiB ที่ไดรฟ์ไม่เสียเลยตลอด 10 ปี
(louwrentius.com)- NAS ZFS ขนาด 71 TiB ที่สร้างจากไดรฟ์ HGST 4TB จำนวน 24 ลูก ถูกใช้งานมานานกว่า 10 ปีแล้ว โดยเมนบอร์ดและพาวเวอร์ซัพพลายถูกเปลี่ยนไปแล้ว แต่ยังไม่เคยมีไดรฟ์เสีย
- ตลอด 10 ปี ไดรฟ์มีเวลาทำงานสะสมเพียงประมาณ 6000 ชั่วโมง และวิธีเปิดเครื่องจากระยะไกลเฉพาะเมื่อจำเป็นช่วยลดค่าไฟได้มาก
- ใน HN มีความเห็นว่า ความน่าจะเป็นที่ไดรฟ์ 24 ลูกจะไม่เสียเลยตลอด 10 ปีนั้นสูงกว่าที่คิด จึงสรุปได้ยากว่าเป็นเพราะปิดเครื่องไว้บ่อย
- ZFS สามารถนำ pool กลับมาใช้งานได้โดยไม่มีปัญหาแม้หลังเปลี่ยนระบบปฏิบัติการ และการรัน zpool scrub ปีละไม่กี่ครั้งก็ไม่เคยพบ checksum error เลย
- เรื่องเสียงรบกวน เครือข่าย UPS การสำรองข้อมูล และแผนเปลี่ยนอุปกรณ์ ล้วนถูกบริหารด้วยการประนีประนอมระหว่าง พลังงาน·ต้นทุน·การยอมรับความเสี่ยง และในอนาคตความจุระดับเดียวกันอาจทำได้ด้วยไดรฟ์ 6~8 ลูกแบบ RAIDZ2
NAS ZFS ขนาด 71 TiB ที่อยู่รอดมานานกว่า 10 ปี
- NAS ZFS แบบ 4U ขนาด 71 TiB ที่ประกอบจากไดรฟ์ 4TB จำนวน 24 ลูก ยังคงถูกใช้งานต่อเนื่องมานานกว่า 10 ปี
- ระบบปัจจุบันใช้ เมนบอร์ด ตัวที่สองและ พาวเวอร์ซัพพลาย ตัวที่สอง
- ยังไม่เคยมีไดรฟ์เสียแม้แต่ครั้งเดียว
- ไดรฟ์ HGST ขนาด 4TB มีเวลาทำงานสะสมประมาณ 6000 ชั่วโมง ซึ่งเทียบเท่าเวลาทำงานราว 250 วันในช่วง 10 ปี
การจัดการพลังงานโดยเปิดเฉพาะเมื่อจำเป็น
- NAS โดยพื้นฐานจะปิดอยู่ และเปิดจากระยะไกลเฉพาะเมื่อจำเป็น
- ลำดับการเปิดเครื่องเป็นดังนี้
- ใช้สคริปต์เปิด ปลั๊กพ่วง IoT
- เมื่อ BMC(Baseboard Management Controller) บูตเสร็จแล้ว ใช้ IPMI เปิดตัวเครื่อง NAS
- ทางเลือกหนึ่งคือใช้ Wake-on-LAN ได้เช่นกัน
- เมื่อใช้งานเสร็จ จะใช้สคริปต์เล็ก ๆ ปิดเซิร์ฟเวอร์ รอสักสองสามวินาที แล้วจึงตัดไฟที่ผนัง
- หากปิดเฉพาะเซิร์ฟเวอร์แต่ยังจ่ายไฟให้เมนบอร์ดและ BMC จะกินไฟต่อเนื่องประมาณ 7W จึงหลีกเลี่ยงวิธีนี้
- บริการอื่น ๆ รันอยู่บน Raspberry Pi 4 หรือเซิร์ฟเวอร์ที่กินไฟขณะสแตนด์บายต่ำกว่ามาก จึงไม่จำเป็นต้องเปิด NAS เครื่องใหญ่ตลอดเวลา
- แรงจูงใจหลักคือ การลดค่าไฟ และประเมินว่าน่าจะดีต่ออายุการใช้งานของฮาร์ดไดรฟ์ด้วย
- อย่างไรก็ตาม ใน HN มีความเห็นว่าโอกาสที่ไดรฟ์ 24 ลูกจะไม่เสียเลยตลอด 10 ปีนั้นสูงกว่าที่คาด จึงสรุปได้ยากว่าผลลัพธ์นี้มาจากการตัดไฟขณะไม่ใช้งาน
- NAS เครื่องก่อนหน้าก็ใช้ไดรฟ์ Samsung Spinpoint F1 ขนาด 1TB จำนวน 20 ลูกอยู่ประมาณ 5 ปีโดยไม่มีไดรฟ์เสียเช่นกัน
ชิ้นส่วนที่มีปัญหาก่อนไดรฟ์
- ไดรฟ์ยังปกติดี แต่เมื่อไม่กี่ปีก่อนต้องเปลี่ยน เมนบอร์ด
- อาการเสียคือเข้า BIOS ไม่ได้ และบางครั้งบูตไม่สำเร็จ
- ลองแก้เบื้องต้น เช่น ถอดแบตเตอรี่ CMOS แล้ว แต่ไม่หาย
- มีเมนบอร์ดรุ่นเดียวกันขายบน Ebay ในราคาพอเหมาะ จึงเปลี่ยนได้โดยไม่มีปัญหาใหญ่
- เหตุผลที่ต้องใช้บอร์ดรุ่นเดียวกันคือเซิร์ฟเวอร์ใช้ สล็อต PCIe 4 ช่อง
- การ์ดที่ติดตั้งคือ HBA 3 ใบ และ NIC 10Gbit 1 ใบ
- พาวเวอร์ซัพพลายต้องรับสภาพที่ไดรฟ์ทั้งหมดสปินอัพพร้อมกันตอนบูต และดึงไฟประมาณ 600W เป็นเวลาหลายวินาที
- พาวเวอร์ซัพพลายมีพิกัด 750W และเท่าที่จำได้ ราง 12V ก็จ่ายไฟได้เพียงพอ แต่บางครั้งยังตัดไฟตอนบูต
การใช้งาน ZFS และผล scrub
- ZFS ทำงานได้โดยไม่มีปัญหามาหลายปี
- แม้เปลี่ยนระบบปฏิบัติการหลายครั้ง หลังติดตั้ง OS ใหม่ก็สามารถนำ pool เดิมกลับมาใช้งานได้โดยไม่มีปัญหา
- หากสร้างเซิร์ฟเวอร์สตอเรจเครื่องใหม่ ก็คิดว่าจะใช้ ZFS อีกครั้ง
- รัน zpool scrub ปีละไม่กี่ครั้ง
- scrub หนึ่งครั้งใช้เวลาประมาณ 20 ชั่วโมง จึงเสร็จ
- ระหว่าง scrub ใช้ไฟมาก จึงรันในวันที่ค่าไฟถูกภายใต้แผนค่าไฟแบบไดนามิก
- จนถึงตอนนี้ scrub ยังไม่เคยพบ checksum error เลย
- คาดว่าน่าจะอ่านข้อมูลรวมกันจากไดรฟ์ทั้งหมดเกิน 1 เพตะไบต์แล้ว แต่ไม่เคยเกิดสถานการณ์ที่ ZFS ต้องเข้ามาช่วยกู้คืน
ข้อผิดพลาดของไดรฟ์และ silent data corruption
- ความเสียหายของไดรฟ์แบ่งได้หลัก ๆ เป็นสองรูปแบบ
- ความเสียหายทั้งลูก ที่ตรวจไม่พบไดรฟ์เลย
- การอ่าน·เขียนล้มเหลวหรือมี bad sector
- รูปแบบที่สามคือ silent data corruption ซึ่งมองว่าพบน้อยมาก
- กรณีที่ดิสก์ไม่รู้ตัวว่ากำลังส่งข้อมูลที่เสียหายออกมา
- กรณีที่การเชื่อมต่อ SATA ตรวจไม่พบ checksum error
- เพราะมีการตรวจ checksum ในระดับต่ำอยู่มาก จึงมองว่าความเสี่ยงนี้น้อยมาก
- silent data corruption เป็นความเสี่ยงจริง แต่เป็นเรื่องที่ควรกังวลมากกว่าในสภาพแวดล้อมขนาดใหญ่อย่างดาต้าเซ็นเตอร์ มากกว่าสภาพแวดล้อมในบ้าน
- ZFS คุ้มค่าที่จะเรียนรู้สำหรับผู้ใช้ที่คุ้นเคยกับ Linux หรือ FreeBSD และไม่ได้เรียนยากมากนัก
การควบคุมพัดลมเพื่อ NAS ที่เงียบ
- NAS เครื่องนี้ถือว่าเงียบมากเมื่อเทียบกับ NAS ทั่วไป
- ในแชสซีมี พัดลม 12V จำนวน 3 ตัว ที่แข็งแรงสำหรับระบายความร้อนให้ช่องไดรฟ์ 24 ช่อง
- หากหมุนที่ความเร็วปกติจะเสียงดังมาก แต่ที่ RPM ต่ำจะค่อนข้างเงียบ และให้ลมเพียงพอในสถานการณ์ส่วนใหญ่
- อย่างไรก็ตาม การใช้ความเร็วต่ำอย่างเดียวทำให้อุณหภูมิไดรฟ์ค่อย ๆ สูงขึ้นระหว่างอ่าน·เขียน
- เมนบอร์ด Supermicro ที่ใช้สามารถควบคุมหัวต่อพัดลมทั้งหมดได้จาก Linux
- จึงสร้าง สคริปต์ ที่ปรับความเร็วพัดลมตามอุณหภูมิของไดรฟ์ที่ร้อนที่สุด
- ได้ถามในซับเรดดิตด้านคณิตศาสตร์หาอัลกอริทึมที่ทั้งเงียบและระบายความร้อนไดรฟ์ได้เหมาะสม และได้รับคำแนะนำให้ใช้ PID controller
- เขียนโค้ด PID controller ด้วย Python แล้วนำโค้ดตัวอย่างมาปรับพารามิเตอร์
- สคริปต์นี้ทำงานได้ดีมาหลายปี และรักษาอุณหภูมิไดรฟ์ไว้ ต่ำกว่า 40°C
- เนื่องจาก airflow พื้นฐานมีน้อย จึงต้องมีพัดลมเสริมเพื่อระบายความร้อนให้การ์ด PCIe 4 ใบ เช่น HBA และการ์ดเครือข่ายด้วย
การเปลี่ยนแปลงของโครงข่าย
- ช่วงแรกใช้คอนโทรลเลอร์เครือข่ายกิกะบิตแบบ quad-port และ network bonding
- การตั้งค่านี้ให้ความเร็วถ่ายโอนระหว่างหลายระบบได้ประมาณ 450MB/s
- ต่อมาต้องใช้สาย UTP มากเกินไป จึงเปลี่ยนไปใช้การ์ด Infiniband ราคาถูก
- ในการตั้งค่า Infiniband สามารถทำความเร็วระหว่างระบบได้ประมาณ 700MB/s
- เมื่อย้ายกลับจาก Ubuntu ไป Debian การ์ด Infiniband ก็ไม่ทำงานอีกต่อไป และแก้สาเหตุไม่ได้
- หลังจากนั้นซื้อการ์ด 10Gbit Ethernet มือสอง และใช้งานได้โดยไม่มีปัญหาจนถึงตอนนี้
UPS, การสำรองข้อมูล และการยอมรับความเสี่ยง
- ช่วงหนึ่งใช้ UPS ขนาดใหญ่เพื่อให้ปิดเครื่องอย่างถูกต้องเมื่อไฟดับ
- หลังพบว่า UPS เพิ่มการใช้ไฟมากกว่า 10W นอกเหนือจากไฟที่เซิร์ฟเวอร์ใช้ จึงถอดออก
- ตัดสินใจยอมรับความเสี่ยงที่จะเสียระบบจากปัญหาไฟฟ้า
- ข้อมูลที่สำคัญที่สุดถูกสำรองไว้สามชุด
- ข้อมูลจำนวนมากที่เก็บบนเซิร์ฟเวอร์ถูกมองว่าไม่สำคัญพอที่จะสำรอง
- การสูญเสียข้อมูลจากไดรฟ์เสียอาศัยฮาร์ดแวร์สำรองและ ZFS เป็นตัวป้องกัน
- หากการป้องกันนั้นไม่เพียงพอ ก็ยอมรับความสูญเสียภายใต้เงื่อนไขนี้ตลอดการใช้งาน 10 ปีที่ผ่านมา
รุ่นถัดไปที่ทำได้ด้วยชุดเล็กกว่า
- ปัจจุบันยังไม่มีแผนสตอเรจในอนาคตแยกต่างหาก
- เหตุผลที่สร้างเซิร์ฟเวอร์นี้ตั้งแต่แรกคือไม่อยากย้ายข้อมูลไปเรื่อย ๆ เพราะพื้นที่เก็บข้อมูลไม่พอ และตอนนี้ก็ยังมีพื้นที่เหลือพอ
- มี เมนบอร์ด, CPU, หน่วยความจำ, การ์ด HBA สำรอง จึงมีโอกาสสูงที่จะกู้ระบบกลับมาได้แม้เกิดความเสียหาย
- เนื่องจากความจุฮาร์ดไดรฟ์เพิ่มขึ้นมาก วันหนึ่งอาจเปลี่ยนแชสซี 24 เบย์เป็นฟอร์มแฟกเตอร์ที่เล็กลงได้
- พื้นที่จัดเก็บแบบมี redundancy ระดับเดียวกันสามารถสร้างได้ด้วย ฮาร์ดไดรฟ์ 6~8 ลูก และ RAIDZ2 หรือ redundancy ระดับ RAID 6
- ยังมองว่าสตอเรจมีราคาแพงอยู่
- ความเป็นไปได้อีกอย่างคือในอีกไม่กี่ปีข้างหน้า ระบบอาจเสียในที่สุด และเมื่อตัดสินใจไม่เปลี่ยนใหม่ งานอดิเรกด้านสตอเรจก็จะจบลง
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
สงสัยว่ามี รอบการเปลี่ยนไดรฟ์ หรือไม่
ไดรฟ์ 24 ตัวน่าจะเป็นรุ่นเดียวกันและมาจากล็อตเดียวกัน และระดับการสึกหรอก็น่าจะใกล้เคียงกัน ดังนั้นส่วนใหญ่อาจเสียในช่วงเวลาใกล้กัน และตัวที่เหลือก็อาจเสียตามระหว่างการสร้างใหม่เพราะโหลดที่เพิ่มขึ้น
สตอเรจที่เชื่อถือได้นั้นยุ่งยาก
แน่นอนว่าทั้งคู่เสียพร้อมกัน และต้องกู้คืนกันทั้งคืน
ถือว่าโชคดีมากจริง ๆ :D
แต่การสึกหรอของฮาร์ดแวร์คงไม่น่าจะสม่ำเสมอถึงขนาดนั้น
มันทำงานได้ดีจนไดรฟ์ตัวหนึ่งตาย แล้วระหว่าง rebuild ไดรฟ์ตัวที่สองก็ตายตาม
แน่นอนว่าไม่ใช่ ZFS ไม่มีการ scrub เป็นประจำ อัตราเสียของไดรฟ์ยุค 2000 ก็อาจต่างกัน และไม่ได้ปิดเครื่องตอนที่ไม่ได้ใช้ด้วย
ประเด็นหลักไม่ใช่สาเหตุที่แน่ชัด แต่คือ ความล้มเหลวที่มีความสัมพันธ์กัน ทั้งนี้ก็มีข้อแม้ทั่วไปว่าเป็นตัวอย่างเดียวจากคนสุ่ม ๆ บนอินเทอร์เน็ต
ส่วนที่บอกว่า “NAS ตัวนี้เงียบมากสำหรับ NAS” เป็นเพราะพัดลมรัศมีใหญ่สามารถเคลื่อนย้ายอากาศได้มากแม้รอบต่ำ และยังประหยัดพลังงานกว่ามากด้วย
Oxide Computer เคยอธิบายในงานพรีเซนต์ว่าทำไมจึงใช้ พัดลม 80mm โดยบอกว่าเพราะเงียบ และที่สำคัญกว่าคือกินไฟต่ำ
พวกเขาสังเกตว่าในเซิร์ฟเวอร์อื่น ๆ อาจใช้พลังงานถึง 25% ไปกับการขับพัดลม แต่ของพวกเขาอยู่ราว 1%
https://www.youtube.com/shorts/hTJYY_Y1H9Q
https://www.youtube.com/watch?v=4vVXClXVuzE
ถ้าไม่นับพัดลม 40mm ในเพาเวอร์ซัพพลาย Flex ATX ที่แทบหายไปแล้วก็ประมาณนั้น และสมัยนี้ 80mm ก็ถือว่าค่อนข้างหายาก มักจะเห็น 120mm หรือ 140mm มากกว่า
ผมเกลียด เสียงความถี่สูง ของพัดลม DC ขนาดเล็กรอบสูงแบบดั้งเดิมจริง ๆ
หวังว่าจะใช้วิธีที่ “ฉลาด” บางอย่างในการควบคุมความเร็วพัดลมด้วย ;-)
ผมเชื่อสนิทกับไอเดีย ย้ายปริมาณลมมากขึ้นด้วยความเร็วต่ำลง
เข้าใจว่าทำได้ยากในแชสซี 1U หรือ 2U
แต่ก็ดี แค่ลดเสียงพัดลมได้ก็น่าทึ่งแล้ว และทำให้สงสัยว่าทำไมก่อนหน้านี้ไม่มีใครคิดถึงสิ่งที่ดูเรียบง่ายแบบนี้
เคยได้ยินคำแนะนำที่ ตรงกันข้ามอย่างสิ้นเชิง ว่าควรปล่อยให้ไดรฟ์หมุนตลอดเพื่อลดการสึกหรอจากการเปิด-ปิดไฟ
ไม่รู้ว่าควรเชื่ออะไร แต่ชอบตรงที่เปิด ZFS NAS ทิ้งไว้แล้วสามารถรัน scrub เป็นประจำและตรวจสอบข้อมูลได้
เพิ่มเติมคือเคยรันระบบ 4 ไดรฟ์เป็นเวลา 10 ปี ระหว่างนั้นไดรฟ์เสีย 2 ครั้ง แต่เป็น WD Green ไม่ใช่เกรดองค์กร
การเปิดปิดไดรฟ์วันละครั้งสองครั้งต่างจากการ spin down ทุกไม่เกิน 15 นาที
ไดรฟ์ WD Green ไม่แนะนำให้ใช้กับ NAS ในอดีตมันมักจะ park หัวอ่าน/เขียนทุกไม่กี่วินาที ซึ่งถ้าเข้าถึงข้อมูลไม่บ่อยก็โอเค แต่ในเซิร์ฟเวอร์จะกลายเป็นการสึกหรอต่อเนื่องและอาจทำให้เสียก่อนเวลา
หัวอ่าน/เขียนแทบไม่สึกหรอขณะลอยอยู่เหนือ platter เมื่อปิดไฟ หัวจะตกลงบนชั้นพักหรือ landing zone ของ platter ทางกายภาพ และการลงจอดกับการยกตัวขึ้นทำให้หัวสึกหรอมากที่สุด
กรณีแย่ที่สุด แรงเสียดทานสถิตอาจทำให้หัวถูกดึงหลุดระหว่างยกตัวขึ้นได้
แบริ่งก็อยู่ได้นานกว่า และถ้าหยุดนิ่งนานเกินไปอาจติดค้างได้ มอเตอร์ไดรฟ์ก็เช่นกัน
กระแสกระชากตอนเปิดไฟ แม้จะเล็กแค่ไหนก็เป็นความเครียดทางไฟฟ้า
เหตุผลที่ควรปิดฮาร์ดดิสก์มีแค่ประหยัดไฟ ลดเสียง และขนย้ายเท่านั้น
แบบนั้นอาจทำให้เกิดการ spin up และ spin down หลายครั้งต่อวันได้ ดังนั้นข้ออ้างนี้จึงยากจะเชื่ออย่างสิ้นเชิง
แต่ผมไม่มีหลักฐานมารองรับเรื่องนี้
ถ้าเป็นแบบนั้น การปล่อยให้ดิสก์หมุนต่อเนื่องเพื่อไม่ให้เปิดปิดทุกไม่กี่นาทีอาจช่วยยืดอายุได้
แต่ถ้าเป็นโฮมแล็บ คุณอาจจ่ายค่าไฟแพงกว่าสิ่งที่ประหยัดได้จากค่าบำรุงรักษาดิสก์มาก
ผมมีไดรฟ์ความจุสูงหลายตัวสำหรับสื่อครอบครัว และอยากปกป้องมันด้วยความมั่นใจที่มากกว่าแค่ “ไดรฟ์ยังไม่เสีย”
การถกเถียงเรื่องระบบไฟล์แบบมี checksum มักวนอยู่กับ ZFS และ BTRFS แต่สงสัยว่ามีใครเคยใช้ bcachefs บ้างไหม
มันถูก upstream เข้า Linux kernel แล้ว และเท่าที่รู้รองรับ checksum ทั้งหมด ผู้เขียนก็ดูเหมือนจะจริงจังกับความรับผิดชอบของระบบไฟล์
มีใครที่นี่ใช้อยู่ไหม?
https://bcachefs.org/
ใช้เวลาประมาณ 1 สัปดาห์ก่อนที่ RAID ทั้งชุดจะ mount ไม่ขึ้นเพราะปัญหา journal คอนฟิกคือ HDD 8 ลูก, SSD 2 ลูกเป็น write cache, และ NVMe 2 ลูกเป็น read cache
ผู้เขียนตอบใน Reddit ภายในหนึ่งวัน และผมลองใช้แพตช์แก้ของเขาแล้ว แม้ต้อง compile Linux kernel แล้ว boot ด้วย kernel นั้น แต่ปัญหาก็ยังไม่หาย
หลังจากนั้นน่าเสียดายที่ไม่มีคำตอบ จึงรออยู่สองสามวันแล้วล้างทิ้ง กลับไปใช้ mdadm RAID ธรรมดา
แน่นอนว่าของสำคัญ backup ไว้ทั้งหมดแล้ว แต่ก็เสียข้อมูลบางส่วนที่ไม่สำคัญไป และทำให้นึกขึ้นได้อีกครั้งว่า ของล้ำหน้าสุดมักไม่เสถียร
อย่างไรก็ตาม ขั้นตอนตั้งค่าและฟีเจอร์ยอดเยี่ยมมาก แค่เพิ่มดิสก์แล้วระบุให้เป็น read/write cache ได้ก็ดีแล้ว
หลังจากมันสุกงอมขึ้นอีกไม่กี่ปี คงจะลองใหม่แน่นอน
[1] https://linuxiac.com/torvalds-expresses-regret-over-merging-...
[2] https://news.ycombinator.com/item?id=41407768
สำหรับข้อมูล production คงไม่อยากเสี่ยง แต่ถ้าเป็น homelab อาจพอได้
เพียงแต่ต้องถามตัวเองว่าถ้ามีอะไรผิดพลาด คุณยินดีจะใช้เวลากับมันมากแค่ไหน
ผมก็ใช้ ZFS มานานกว่า 15 ปี และเจอเรื่องสารพัดเพราะฮาร์ดแวร์แย่ ๆ แต่บนฮาร์ดแวร์ enterprise ดี ๆ มันทำงานได้ไร้ที่ติ
กำลังลองชุดที่เอา SSD ราว 2TiB วางไว้หน้าฮาร์ดดิสก์ขนาดใหญ่ราว 8TiB แล้วใช้ SSD เป็น cache
บน Ubuntu เคยเจอปัญหาจุกจิกกับชุด zsys + root ZFS ซึ่งตอนนี้กลายเป็น legacy ไปแล้ว แต่เป็นการตั้งค่าที่พบได้ทั่วไปและใช้กันแพร่หลายมาหลายปี จึงหาการสนับสนุนได้ง่าย
คงยังไม่ใช้ bcachefs จนกว่าจะมีอัตราการใช้งานและการสนับสนุนจากชุมชนในระดับใกล้เคียงกัน
ผมคิดว่า สภาพแวดล้อม ที่ไดรฟ์ทำงานอยู่สร้างความแตกต่างต่ออายุการใช้งานอย่างมหาศาล
สภาพแวดล้อมในบ้านมีความแปรปรวนมากกว่าศูนย์ข้อมูลหรือสำนักงานมาก การเปลี่ยนแปลงของอุณหภูมิและความชื้นก็เป็นโจทย์ใหญ่ แต่ที่น่าประหลาดใจคือฝุ่นปริมาณเล็กน้อยก็มีผลค่อนข้างชัดเจน
นานมาแล้วผมรัน array 8x500G บนเซิร์ฟเวอร์ Dell เก่า ๆ ในห้องใต้ดิน ไดรฟ์ทั้งหมดเป็น Seagate ใหม่ 7200RPM และอาจเป็นรุ่น “enterprise”
ตลอด 5 ปี ไดรฟ์เสียเฉลี่ยทุก 6 เดือน มี parity drive 2 ลูก เก็บ spare drive ไว้ และส่ง RMA ทุกครั้งที่เสีย
หลังจากย้ายบ้าน ผมมีห้องเฉพาะสำหรับแล็บ และด้วยคอนฟิกเดิม ในอีก 5 ปีถัดมากลับไม่มีไดรฟ์เสียเลย คาดอยู่แล้วว่าสภาพแวดล้อมใหม่จะดีกว่า แต่ก็แปลกใจที่สภาพแวดล้อมที่สะอาดและเสถียรกว่าช่วยได้มากขนาดนี้
ผมวาง NAS/file server ไว้ในสภาพแวดล้อมบ้านที่มีฝุ่นเยอะตลอด และตอนนี้ยังเห็นโลโก้ Synology สีเทาฟู ๆ อยู่ด้วยซ้ำ แต่ไม่เคยเจอแบบนั้น
ผมว่า generation นั้นมี ปัญหา firmware
ดูอัตราเสียรายปีได้ที่นี่: https://www.backblaze.com/blog/best-hard-drive-q4-2014/
สำหรับไดรฟ์ยุคนี้ที่ปิดผนึกและเติมฮีเลียม ถึงเดิมทีมันจะเคยเป็นปัญหา ตอนนี้ก็คงไม่ใช่ปัญหาใหญ่แล้ว
เกี่ยวกับประเด็นที่ว่า “ยอมรับความเสี่ยงที่จะสูญเสียระบบจากปัญหาไฟฟ้า” อีกความเสียหายที่พบได้น้อยมากซึ่ง UPS ช่วยป้องกันได้คือ ความไม่สมดุลทางไฟฟ้า
หากมีปัญหาไฟฟ้าระหว่างงานก่อสร้างใกล้ ๆ หรือฟ้าผ่าเสาไฟฟ้าใกล้บ้าน อาจเกิดสไปก์ทั้งทางขึ้นและทางลง และทั้งสองแบบอาจสร้างความเสียหายได้
ที่ทำงานแรกเมื่อราว 10 ปีก่อน มีเซิร์ฟเวอร์หลายเครื่องตายด้วยวิธีนั้น แต่ก็เป็นครั้งเดียวที่เคยได้ยินปัญหาแบบนั้น
ตามที่เข้าใจ UPS จะกันสไปก์แบบนั้นได้ด้วย และ UPS จะพังก่อนที่เซิร์ฟเวอร์จะเสียหาย
ฟ้าผ่าเข้าที่เสาอากาศทีวีของบ้านพ่อแม่โดยตรง และต่อผ่านสายโคแอกเชียลไปถึงแอมป์/ตัวแยกสัญญาณในตู้สื่อสาร
หลังจากนั้นไม่รู้เกิดอะไรขึ้น มันลามไปยังแผงแพตช์เครือข่ายที่อยู่ใกล้ ๆ แล้วเผาคอนโทรลเลอร์อีเทอร์เน็ตแบบมีสายทุกตัวที่ต่ออยู่กับเครือข่าย รวมถึงพอร์ตสวิตช์และตัวที่ฝังอยู่ใน AP ด้วย
ในสวิตช์เครือข่าย กระแสคงพยายามไหลลงกราวด์ เลยทำลายไปถึงชุดจ่ายไฟ
ยังเป็นปริศนาอยู่นิดหน่อยว่ามันข้ามจากสายโคแอกเชียลไป Cat5 ได้อย่างไร บางทีช่างไฟอาจวางสายขนานใกล้กันไว้ตรงไหนสักจุด
ต้องเดินเครือข่ายใหม่ทั้งหมด แต่โชคดีที่หน้างานไม่มีคอมพิวเตอร์แบบต่อสายอยู่ อุปกรณ์จัดเก็บข้อมูลก็คงรอดยากเหมือนกัน
APC 850VA ราคา 99 ดอลลาร์ที่ซื้อจาก Office Depot ไม่ได้ทำแบบนั้น มันแค่สลับจากไฟบ้านไปแบตเตอรี่อย่างรวดเร็วมากเท่านั้น ไม่ได้กรองไฟจริง ๆ
ถ้าซื้อของดีได้ ระยะยาวจะช่วยเพิ่มความน่าเชื่อถือของฮาร์ดแวร์ได้จริง ๆ ไฟสะอาดเป็นเรื่องดี
จากการกระจายตัวของอุปกรณ์ที่พัง อุปกรณ์ที่เสียหาย และอุปกรณ์ที่ดูเหมือนไม่เป็นไร เห็นได้ชัดว่าสาย ทองแดง ที่พา VDSL มาเป็นเส้นทางตรงมาก โมเด็มเชื่อมต่อกับอุปกรณ์อื่นทั้งหมดผ่านอีเทอร์เน็ต
วิธีแก้ที่ถูกต้องน่าจะเป็นการแปลงเป็นแสง ให้ผ่านช่วงไฟเบอร์ออปติกสักหน่อย แล้วค่อยแปลงกลับ ไฟฟ้ามีแนวโน้มจะเลือกทางอื่นมากกว่าผ่านแก้ว
แต่การเลือกสินค้าน่ารำคาญกว่าที่คิดไว้มาก และเพราะไม่ใช่คนสายเน็ตเวิร์ก พยายามแยกประเภทสินค้าอยู่ประมาณหนึ่งชั่วโมงแล้วก็ยอมแพ้
เลยใส่ Wi‑Fi bridge ไว้ระหว่างโมเด็ม VDSL กับอุปกรณ์ที่เหลือ หวังว่าพายุครั้งหน้าจะช่วยแยกโหมดความเสียหายนั้นออกไปได้
มีอาร์เรย์ ZFS ต่ออยู่กับโมเด็มเดียวกันด้วย ซึ่งรอดมาได้ แต่คิดว่าน่าจะโชคดี
ตอนนั้นไม่มีเซิร์ฟเวอร์ แต่ หลอดไฟ LED เสียทุกไม่กี่สัปดาห์จนหงุดหงิด เป็นอาคารเก่าจากยุค 60 และระบบไฟในห้องเราก็มีงานซ่อมชั่วคราวที่น่าสงสัยอยู่ด้วย
“ความลับ” ไม่ใช่การปิดเครื่อง แต่เป็นแค่ โชค
ผมใช้ไดรฟ์ HGST 4TB มานานกว่า 10 ปีแบบ 24/7 ไม่ใช่ 24 ลูกพอดี แต่เป็น 8 ลูก และเสีย 0 ลูก
ผมก็แค่โชคดีเหมือนกัน และมีเพื่อนที่ส่ง RMA ไดรฟ์รุ่นเดียวกันหลายครั้ง
สิ่งที่สงสัยที่สุดคือ ข้อมูลอะไรที่ต้องใช้ถึง 71TB ทั้งที่ปิดไว้ได้เกือบตลอดเวลา เป็นเซิร์ฟเวอร์เก็บแบ็กอัปหรือ?
เช่น แบริ่งอาจติดเมื่อเย็น
คนที่รู้สถิติดีคงคำนวณความน่าจะเป็นที่ทั้ง 24 ลูกจะรอดได้ โดยสมมติอัตราเสียต่อปีราว 1%
แถมไดรฟ์ 20 ลูกของ NAS เครื่องก่อนหน้าก็ไม่เคยเสีย ถ้าอย่างนั้น N=44 แล้วต้องโชคดีแค่ไหนกัน?
ใช้ในบ้าน และถ้าต้องการข้อมูล ปกติก็คัดลอกผ่าน 10Gbit ไปยังระบบที่กินไฟต่ำกว่ามาก แล้วปิด NAS ตัวนี้อีกครั้ง
เคยมีไดรฟ์บางรุ่นที่การเปิด‑ปิดไฟเป็นเรื่องเสี่ยง
ดังนั้นเห็นด้วยกับโมเดลนี้ แต่ไม่ควรสรุปว่าวิธีนี้ดีสำหรับทุกคนเสมอไป SSD บางรุ่นต้องได้รับไฟเป็นระยะ
ถ้าเป็นรอบการใช้งานของ NAS ก็น่าจะเข้าเงื่อนไขนั้น
น่าจะไม่เป็นไร และค่าไฟถูกกว่าชัดเจน ไดรฟ์ที่มีจาระบีส่วนเกินบนแกนหมุนเป็นกรณีพิเศษในยุคหนึ่ง
สงสัยว่า Backblaze มีโมเดลสถิติเรื่องการเปิด/ปิดไดรฟ์กับอายุการใช้งานหรือไม่ ฝั่งนั้นน่าจะอยู่ในพื้นที่ปัญหาที่เปิดเครื่องตลอดเวลา
แต่ในกรณีของผม ผมไม่ได้เปิด‑ปิดไฟไดรฟ์เหล่านี้บ่อย อย่างมากก็เดือนละไม่กี่ครั้ง
ผมบอกหรือพิสูจน์ไม่ได้ว่ามันไม่ใช่ความเสี่ยงใหญ่ แต่ผมเชื่อว่าไม่ใช่ และยอมรับความเสี่ยงนั้นมานานกว่า 15 ปีแล้ว
ต้องจำไว้ด้วยว่าฮาร์ดดิสก์มีตัวเลือกให้สปินดาวน์ตอนว่างงาน นั่นหมายความว่าฮาร์ดดิสก์รับการสปินอัปได้หลายครั้งต่อวัน
เขาใช้ฮาร์ดดิสก์ 3.5 นิ้วแบบภายในกับ USB dock เพื่อแบ็กอัปอุปกรณ์ Synology หลายเครื่อง และเวลานำไดรฟ์กลับมาเสียบ dock เพื่อกู้ไฟล์หรือแบ็กอัปเพิ่ม ราว 1 ใน 10 ครั้งจะรู้สึกว่า เปิดติดไม่ขึ้นอีก
ใช้ ฐานข้อมูล PostgreSQL ขนาดหลาย TB บน ZFS ในสภาพแวดล้อมโปรดักชันมาหลายปีแล้ว และจนถึงตอนนี้ยังไม่เจอปัญหาใด ๆ รวมถึงบิตพลิกด้วย
สำหรับคนที่สนใจ ได้บันทึกประสบการณ์ไว้ที่นี่:
https://lackofimagination.org/2022/04/our-experience-with-po...
เรื่องการตัดไฟเป็นครั้งคราวระหว่างบูต ควรดูว่าไดรฟ์ดึงพลังงานจาก ราง 5V ตอนเริ่มทำงาน
ไดรฟ์ที่คล้ายกันมักกินไฟสูงสุด 1.2A เมื่อรวมกับโหลดสูงสุดของราง 5V ที่ 25A (Seasonic Platinum 860W) ก็มีโอกาสสูงที่จะเกิดไฟล้มเหลวระหว่างบูตเมื่อไม่ใช้ staggered spinup