มีวิธีการป้องกัน SSD จากความเสียหายเนื่องจากการสูญเสียพลังงานหรือไม่?

เรามีกลุ่มผู้ใช้ปลายทางที่ติดตั้ง Linux, เว็บเซิร์ฟเวอร์ในพื้นที่และติดตั้ง PostgreSQL เรากำลังรับรายงานภาคสนามของเครื่องที่มีปัญหาและเมื่อตรวจสอบดูเหมือนว่าไฟฟ้าดับและตอนนี้มีบางอย่างผิดปกติกับดิสก์

ฉันสันนิษฐานว่าปัญหาจะเกิดขึ้นกับฐานข้อมูลที่เสียหายหรือไฟล์ที่มีการเปลี่ยนแปลงเมื่อเร็ว ๆ นี้มีสัญญาณรบกวน แต่มีรายงานแปลก ๆ อื่น ๆ

• ไฟล์ที่มีสิทธิ์ที่ไม่ถูกต้อง
• ไฟล์ที่กลายเป็นไดเร็กทอรี (ตัวอย่างเช่นindex.phpตอนนี้เป็นไดเร็กทอรี)
• ไดเรกทอรีที่เป็นไฟล์
• ไฟล์ที่มีข้อมูลที่มีสัญญาณรบกวน

มีปัญหาเกี่ยวกับฐานข้อมูลที่ได้รับความเสียหาย แต่นั่นเป็นสิ่งที่ฉันคาดหวัง สิ่งที่ฉันประหลาดใจมากขึ้นคือปัญหาพื้นฐานของระบบไฟล์ - ตัวอย่างเช่นการอนุญาตหรือการเปลี่ยนไฟล์เป็นไดเรกทอรี ปัญหายังเกิดขึ้นในไฟล์ที่ไม่ได้เปลี่ยนเมื่อเร็ว ๆ นี้ (ตัวอย่างเช่นรหัสซอฟต์แวร์และการกำหนดค่า)

นี่เป็น "ปกติ" สำหรับความเสียหายของ SSD หรือไม่ เดิมเราคิดว่ามันเกิดขึ้นกับ SSD ราคาถูกบางตัว แต่เรามีสิ่งนี้เกิดขึ้นกับแบรนด์เนม (ระดับผู้บริโภค)

FWIW เราไม่ได้ทำ autofsck ในการบูตที่ไม่สะอาด (ไม่รู้ว่าทำไม - ฉันใหม่) เรามีการติดตั้ง UPS ในบางสถานที่ แต่บางครั้งก็ไม่ได้ทำอย่างถูกต้อง ฯลฯ สิ่งนี้ควรได้รับการแก้ไข แต่ถึงอย่างนั้นคนก็สามารถปิดเครื่องได้อย่างไม่สะอาด ฯลฯ - ดังนั้นจึงไม่ใช่เรื่องโง่ ระบบไฟล์คือ ext4

คำถาม: มีอะไรที่เราสามารถทำได้เพื่อบรรเทาปัญหาในระดับระบบหรือไม่?

ฉันพบบทความบางบทความที่อ้างถึงการปิดแคชของฮาร์ดแวร์หรือติดตั้งไดรฟ์ในโหมดซิงค์ แต่ฉันไม่แน่ใจว่าจะช่วยได้ในกรณีนี้หรือไม่ ฉันยังอ่านข้อมูลอ้างอิงเกี่ยวกับการติดตั้งระบบไฟล์ในโหมดอ่านอย่างเดียว เราทำไม่ได้เพราะเราต้องเขียน แต่เราสามารถสร้างพาร์ติชันแบบอ่านอย่างเดียวสำหรับรหัสและการกำหนดค่าหากสิ่งนั้นจะช่วยได้

นี่คือตัวอย่างของไดรฟ์sudo hdparm -i /dev/sda1:

Model=KINGSTON RBU-SMS151S364GG, FwRev=S9FM02.5, SerialNo=<deleted>
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=125045424
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio3 pio4
DMA modes:  mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7

เมื่อสูญเสียพลังงานในทันทีทันใด MLC / TLC / QLC SSD มีสองโหมดความล้มเหลว:

• พวกเขาสูญเสียการเขียนบนเที่ยวบินและใน DRAM เท่านั้น
• พวกเขาสามารถทำลาย data-at-rest ที่เก็บไว้ในหน้าล่างของเซลล์ NAND ที่ถูกโปรแกรม

เงื่อนไขความล้มเหลวแรกเห็นได้ชัด: หากไม่มีการป้องกันไฟข้อมูลใด ๆ ที่ไม่ได้อยู่ในที่จัดเก็บข้อมูลที่มีเสถียรภาพ (เช่น: ตัว NAND เอง) แต่ในแคชระเหย (DRAM) เท่านั้นจะหายไป สิ่งเดียวกันนี้เกิดขึ้นกับดิสก์เชิงกลแบบคลาสสิก (และเพียงอย่างเดียวสามารถสร้างความหายนะให้กับระบบไฟล์

เงื่อนไขความล้มเหลวที่สองคือ MLC + SSD เรื่อง: เมื่อ reprogramming บิตหน้าสูงสำหรับการจัดเก็บข้อมูลใหม่การสูญเสียพลังงานที่ไม่คาดคิดสามารถทำลาย / เปลี่ยนแปลงบิตต่ำกว่า (เช่น: ข้อมูลมุ่งมั่นก่อนหน้า) เช่นกัน

ทางออกเดียวที่ชัดเจนและชัดเจนที่สุดคือการรวมแคช DRAM ที่ป้องกันการสูญเสียพลังงาน อย่างไรก็ตามสิ่งนี้เพิ่มค่าใช้จ่ายในการขับเคลื่อน / ราคา โดยทั่วไปแล้วไดรฟ์สำหรับผู้บริโภคจะไม่มีแคชที่ป้องกันการสูญเสียพลังงาน ค่อนข้างพวกเขาใช้อาร์เรย์ของโซลูชั่นที่ประหยัดมากขึ้นเป็น:

• แคชการเขียนที่ได้รับการป้องกันบางส่วน (เช่น: Crucial M500 / M550 / M600 +);
• NAND เปลี่ยนแปลงเจอร์นัล (เช่น: ไดรฟ์ Samsung, ดูแอตทริบิวต์ SMART PoR);
• ภูมิภาค SLC / หลอกพิเศษ SLC NAND เพื่อดูดซับการเขียนใหม่โดยไม่มีข้อมูลก่อนหน้านี้ที่มีความเสี่ยง (เช่น: Sandisk, Samsung, ฯลฯ )

กลับไปที่คำถามของคุณ: ไดรฟ์ Kingstone ของคุณนั้นราคาถูกมากโดยใช้คอนโทรลเลอร์ที่ไม่ได้รับการระบุและโดยทั่วไปก็ไม่มีสเป็คสาธารณะ ไม่แปลกใจเลยที่การสูญเสียพลังงานอย่างฉับพลันทำให้ข้อมูลก่อนหน้านี้เสียหาย น่าเสียดายที่การปิดใช้งานแคช DRAM ของดิสก์ (ด้วยการสูญเสียประสิทธิภาพของคำสั่ง) จะไม่แก้ปัญหาของคุณเนื่องจากข้อมูลก่อนหน้า (เช่น data-at-rest) สามารถและจะเสียหายจากการสูญเสียพลังงานที่ไม่ได้ตรวจพบ หากพวกเขาอยู่บนพื้นฐานของตัวควบคุม Sandforce เก่าแม้แต่อิฐไดรฟ์ทั้งหมดสามารถคาดหวังภายใต้สถานการณ์ "ขวา"

ฉันขอแนะนำอย่างยิ่งให้คุณตรวจสอบ UPS ของคุณและในช่วงกลางเดือนนี้เพื่อแทนที่ไดรฟ์สำหรับผู้สูงอายุเหล่านี้

บันทึกล่าสุดเกี่ยวกับ PostgreSQL และฐานข้อมูล Linux อื่น ๆ : พวกเขาจะไม่ปิดใช้งานแคชของดิสก์และไม่ควรตรวจสอบให้ทำเช่นนั้น แต่พวกเขาจะออก fsyncs / FUAs เป็นระยะ / จำเป็นเพื่อส่งมอบข้อมูลสำคัญไปยังที่จัดเก็บข้อมูลที่มีเสถียรภาพ นี่คือวิธีที่ควรทำสิ่งต่าง ๆ เว้นแต่มีเหตุผลที่น่าสนใจมาก (เช่น: ไดรฟ์ที่อยู่เกี่ยวกับ ATA FLUSHES / FUAs)

แก้ไข:ถ้าเป็นไปได้ให้พิจารณาย้ายระบบไฟล์ไปยัง checksumming เป็น ZFS หรือ BTRFS อย่างน้อยที่สุดพิจารณา XFS ซึ่งมีการตรวจสอบวารสารและเมื่อเร็ว ๆ นี้แม้การตรวจสอบข้อมูลเมตา หากคุณถูกบังคับให้ใช้ EXT4 ให้ลองเปิดใช้งาน fsck อัตโนมัติเมื่อเริ่มต้น (fsck.ext4 นั้นดีมากในการซ่อมแซมความเสียหาย)

ใช่. อย่ารับ SSD ราคาถูกสุด - สิ่งใดก็ตามที่อยู่นอกตลาดผู้บริโภคระดับล่างมีตัวเก็บประจุและการป้องกันการสูญเสียพลังงานอย่างสมบูรณ์ Amd ไม่ต้องเสียค่าใช้จ่ายมากนัก

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

สิ่งแปลก ๆ ทุกประเภทสามารถเกิดขึ้นกับไฟล์ได้หากการเขียนในเที่ยวบินหายไป ลำดับความสำคัญของระบบไฟล์คือการรักษาความสอดคล้องของข้อมูลเมตาของพวกเขาพวกเขาอาจไม่ให้การรับประกันแบบเดียวกันกับข้อมูลของคุณ ในคำอื่น ๆfsckจะไม่รับประกันในการกู้คืนข้อมูลของคุณ หน้าที่ของมันคือการให้ระบบไฟล์ที่จะเมานต์แก่คุณ

ดังนั้นพลังงาน ติดตั้งกำหนดค่าและทดสอบว่า UPS จะปิดระบบอย่างสง่างาม สิ่งนี้อนุญาตให้แคชระบบไฟล์และไดรฟ์สามารถเขียนเองได้

และความทนทานของการเขียนลงดิสก์ อ่านPostgreSQL บทน่าเชื่อถือ ใช้diskchecker.plสคริปต์ที่เชื่อมโยงอยู่ที่นั่นเพื่อทำการทดสอบการชนและตรวจสอบว่า SSD กำลังโกหกหรือไม่ถ้าการเขียนมีการจัดเก็บแบบไม่ลบเลือน หากมีการสูญเสียให้พิจารณาเปลี่ยนด้วย SSD ที่ทราบว่ามีการป้องกันการสูญเสียพลังงาน

แก้ไข: คุณเพิ่มรายละเอียดที่เปิดใช้งานแคชการเขียน คุณสามารถลองปิดการใช้งานนั้น: hdparm -W0 /dev/sdaหรือคำสั่งที่เหมาะสมสำหรับอาร์เรย์ฮาร์ดแวร์ อ้างอิง: คู่มือ RHEL บริหารการจัดเก็บข้อมูล

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

ในที่สุดบรรทัดสุดท้ายของการป้องกัน ทำการทดสอบการกู้คืนเพื่อให้แน่ใจว่าคุณสามารถรับใบสมัครและฐานข้อมูลของคุณไปยังจุดที่ต้องการ สิ่งนี้มีประโยชน์สำหรับการสูญเสียข้อมูลทุกประเภทไม่ใช่เพียงแค่ไฟฟ้าดับ