RAID 10 คืออะไร ทำไมผู้ให้บริการ VPS ถึงเลือกใช้

RAID 10 คืออะไร และเหตุใดผู้ให้บริการ VPS จึงเลือกใช้งาน

RAID 10 คือรูปแบบการจัดเก็บข้อมูลที่ผู้ให้บริการ VPS ส่วนใหญ่เลือกใช้สำหรับไดรฟ์ NVMe (non-volatile memory express) แบบเสมือน โดยระบบจะทำการทำสำเนา (mirror) ข้อมูลทุกไดรฟ์ไปยังไดรฟ์คู่หู จากนั้นจึงกระจายข้อมูล (stripe) ข้ามคู่ที่ทำสำเนาไว้ หากไดรฟ์หนึ่งตัวเสียหาย อาร์เรย์จะยังคงทำงานต่อไปได้ และการซ่อมแซมจะใช้วิธีคัดลอกข้อมูลโดยตรงจากไดรฟ์คู่หูที่ยังทำงานอยู่ แทนที่จะต้องคำนวณใหม่โดยการอ่านข้อมูลจากไดรฟ์ทุกตัวในชุด

RAID ย่อมาจาก redundant array of independent disks ซึ่งมีหน้าที่เพียงอย่างเดียวคือ ทำให้เครื่องเซิร์ฟเวอร์ยังคงให้บริการได้ในขณะที่ดิสก์ตัวหนึ่งเสียหายหรือกำลังถูกเปลี่ยน หน้าที่นี้คือความพร้อมใช้งาน (availability) แต่ความพร้อมใช้งานไม่ใช่ความปลอดภัยของข้อมูล

RAID จะทำสำเนาการเขียนข้อมูลของคุณ rm -rf /srv คือการเขียนข้อมูล ทั้งสองส่วนของ mirror จะลบไดเรกทอรีทิ้งในเสี้ยววินาทีเดียวกัน และอาร์เรย์จะยังคงรายงานสถานะว่าปกติหลังจากนั้น

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

ระดับของ RAID ที่ผู้ซื้อบริการโฮสติ้งพบเจอจริง: 1, 5, 6 และ 10

หน้าแสดงแผนบริการมักระบุตัวเลขเพียงอย่างเดียว ตัวเลขนี้ตอบคำถามสองข้อคือ: ไดรฟ์เสียได้กี่ลูก และการเขียนข้อมูลแต่ละครั้งมีต้นทุนอย่างไร

RAID 1 คือการทำมิเรอร์ (mirror) ไดรฟ์สองลูกจะเก็บข้อมูลบล็อกที่เหมือนกันทุกประการ การเขียนข้อมูลทุกครั้งจะส่งไปยังทั้งสองลูก และการอ่านข้อมูลสามารถทำได้จากไดรฟ์ลูกใดก็ได้ หากไดรฟ์เสียหนึ่งลูก ข้อมูลจะไม่สูญหาย และความจุที่ใช้งานได้จริงจะเหลือครึ่งหนึ่งของความจุรวม เนื่องจากไม่มีการคำนวณ parity ทำให้เส้นทางการเขียนข้อมูลสั้น

RAID 5 คือการทำ striping โดยมีบล็อก parity หนึ่งบล็อกต่อหนึ่ง stripe หากมีไดรฟ์ n ลูก คุณจะได้ความจุเท่ากับ n-1 ลูก และอาร์เรย์จะรองรับความเสียหายได้เพียงหนึ่งลูกเท่านั้น Parity จะไม่ถูกเก็บไว้ที่ไดรฟ์ใดไดรฟ์หนึ่งโดยเฉพาะ แต่จะหมุนเวียนไปทั่วทุกไดรฟ์ ดังนั้นทุกไดรฟ์จึงเก็บทั้งข้อมูลและ parity

RAID 6 เพิ่มบล็อก parity ชุดที่สองที่เป็นอิสระต่อกัน เข้าไปในแต่ละ stripe โดยปกติจะเขียนแทนด้วย P และ Q ซึ่งช่วยให้ระบบรองรับความเสียหายของไดรฟ์พร้อมกันได้ถึงสองลูก เรื่องนี้สำคัญกว่าที่คิด เพราะความเสียหายลูกที่สองมักเกิดขึ้นระหว่างการซ่อมแซมความเสียหายลูกแรก

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

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

Linux เป็นกรณีพิเศษที่ควรทราบ raid10 ของเคอร์เนลเป็นรูปแบบการทำงานเดี่ยวแทนที่จะเป็นสองเลเยอร์ซ้อนกัน จึงสามารถทำงานบนจำนวนไดรฟ์ที่เป็นเลขคี่ได้ และมีเลย์เอาต์ (near, far, offset) ที่การตั้งค่าแบบซ้อนกันไม่สามารถทำได้ นี่คือเหตุผลที่บรรทัดสถานะบนเครื่อง Linux แสดงเป็น 2 near-copies แทนที่จะระบุชื่ออาร์เรย์สองชุด

[
  {
    "label": "RAID 1 (four mirrored pairs)",
    "usable_tb": 4,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 4
  },
  {
    "label": "RAID 5",
    "usable_tb": 7,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 1
  },
  {
    "label": "RAID 6",
    "usable_tb": 6,
    "worst_case_drives_lost": 2,
    "best_case_drives_lost": 2
  },
  {
    "label": "RAID 10",
    "usable_tb": 4,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 4
  }
]

ไดรฟ์ขนาด 1 TB จำนวนแปดลูก จะให้พื้นที่ใช้งานได้ 7 TB ภายใต้ RAID 5 และ 4 TB ภายใต้ RAID 10 ช่องว่างของความจุนี้คือเงินจริง และเป็นเหตุผลว่าทำไมจึงมีการเสนอให้ใช้ parity อยู่เสมอ RAID 6 รองรับความเสียหายได้ 2 ลูกในรูปแบบใดก็ได้ ส่วน RAID 10 รับประกันความเสียหายได้เพียง 1 ลูกเท่านั้น เนื่องจากความเสียหายลูกที่สองที่อันตรายที่สุดคือลูกที่เกิดขึ้นกับไดรฟ์คู่ของลูกที่เสียไปก่อนหน้า อย่างไรก็ตาม มันสามารถรองรับความเสียหายได้สูงสุดถึง 4 ลูกหากไม่มีความเสียหายสองลูกใดที่อยู่ในคู่เดียวกัน ซึ่งนั่นเป็นเรื่องของโชคมากกว่าคุณสมบัติในการออกแบบ

ต้นทุนของแต่ละระดับในการเขียนข้อมูลแต่ละครั้ง

การเขียนข้อมูลลงใน mirror คือการเขียน 2 ครั้ง โดยส่งคำสั่งไปยังสมาชิกทั้งสองตัวพร้อมกัน การเขียนลงใน parity stripe จะใช้การทำงานมากกว่า เนื่องจากบล็อก parity ของ stripe นั้นจะไม่ถูกต้องอีกต่อไปและต้องถูกคำนวณใหม่

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

[
  {
    "label": "RAID 1 (2 drives)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  },
  {
    "label": "RAID 5 (8 drives)",
    "write_ops_per_host_write": 4,
    "drives_read_to_rebuild": 7
  },
  {
    "label": "RAID 6 (8 drives)",
    "write_ops_per_host_write": 6,
    "drives_read_to_rebuild": 7
  },
  {
    "label": "RAID 10 (8 drives)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  }
]

การเขียนแบบสุ่มขนาดเล็กมีต้นทุนเท่ากับ 6 การดำเนินการของอุปกรณ์บน RAID 6 และ 2 บน RAID 10 ตัวเลขเหล่านี้ยังต่ำกว่าความเป็นจริงเมื่อเทียบกับความแตกต่างของ latency การเขียนแบบ mirror สองครั้งจะเกิดขึ้นแบบขนาน ดังนั้น guest จะต้องรอการทำงานที่ช้ากว่าระหว่างสองตัวนั้น ส่วนเส้นทางของ parity จะมีการอ่านที่ต้องเสร็จสิ้นก่อนจึงจะคำนวณ parity ใหม่ได้ ดังนั้น guest จะต้องรอการอ่านแล้วตามด้วยการเขียนทีละขั้นตอน บนโฮสต์ที่มีภาระงานสูง การอ่านนั้นจะต้องต่อคิวอยู่หลัง I/O ของผู้อื่นทั้งหมด

มีข้อยกเว้นที่สำคัญประการหนึ่ง คือการเขียนที่มีขนาดใหญ่พอที่จะเติมเต็มทั้ง stripe จะไม่จำเป็นต้องใช้ข้อมูลเดิม เนื่องจากทุกบล็อกใน stripe กำลังถูกแทนที่ Parity จะถูกคำนวณจากสิ่งที่อยู่ในหน่วยความจำอยู่แล้ว และต้นทุนจะลดลงเหลือเพียงการเขียนเพิ่มอีกหนึ่งครั้ง นี่คือเหตุผลที่ RAID 5 ดูเหมือนจะทำงานได้ดีในการทดสอบแบบ sequential แต่กลับทำงานได้แย่ภายใต้ภาระงานแบบผสมที่มีการเขียนขนาดเล็กจากผู้ใช้หลายราย ควรทดสอบรูปแบบการใช้งานจริงของคุณ: การทำ benchmarking ดิสก์ VPS อย่างถูกต้อง หมายถึงการทดสอบ I/O แบบสุ่มที่ระดับ queue depth ที่สมจริง ไม่ใช่การทดสอบด้วย dd ขนาดใหญ่เพียงรายการเดียว

เหตุผลที่การสร้างข้อมูลใหม่ (rebuild) เป็นขั้นตอนที่อันตราย

การสร้างข้อมูลใหม่ในระบบ parity ต้องกู้คืนข้อมูลจากไดรฟ์ที่เสียหายโดยอาศัยข้อมูลจากไดรฟ์ที่เหลือทั้งหมด ดังนั้นระบบจึงต้องอ่านข้อมูลจากไดรฟ์ที่ยังทำงานอยู่ทั้งหมด 7 ตั้งแต่บล็อกแรกจนถึงบล็อกสุดท้าย ในขณะที่การสร้างข้อมูลใหม่ของ RAID 10 จะอ่านข้อมูลเพียง 1 เท่านั้น คืออ่านจากไดรฟ์คู่กระจก (mirror partner) ของไดรฟ์ที่เสียเพียงตัวเดียว โดยไม่ต้องยุ่งกับไดรฟ์อื่น

ผลกระทบที่ตามมามี 2 ประการ ประการแรกคือเรื่องของเวลา เนื่องจากความเร็วในการสร้างข้อมูลใหม่ถูกจำกัดด้วยไดรฟ์ที่ทำงานช้าที่สุดในกลุ่ม รวมถึงภาระจากการคำนวณ parity ประการที่สองคือเรื่องของโหลด (load) ไดรฟ์ทุกตัวใน parity set จะต้องทำงานหนักตลอดช่วงเวลาดังกล่าว ส่งผลให้ guest ทุกตัวบนโหนดนั้นพบกับค่า latency ที่สูงขึ้นจนกว่ากระบวนการจะเสร็จสิ้น ในขณะที่ RAID 10 จะมีเพียงคู่เดียวที่ทำงานหนัก ส่วนคู่ที่เหลือยังคงให้บริการได้ด้วยความเร็วปกติ

นอกจากนี้ยังมีความเสี่ยงด้านความถูกต้องของข้อมูลในช่วงเวลาเดียวกัน อาร์เรย์ RAID 5 ที่มีไดรฟ์เสีย 1 ตัวจะไม่มีความซ้ำซ้อนเหลืออยู่เลย ดังนั้นหากพบ sector ที่อ่านไม่ได้บนไดรฟ์ที่เหลืออยู่ ข้อมูลนั้นจะไม่สามารถกู้คืนได้ การสร้างข้อมูลใหม่คือการดำเนินการเพียงอย่างเดียวที่ต้องอ่านทุก sector รวมถึง sector ที่ไม่มีการเข้าถึงมานานเป็นปี ข้อมูลจาก datasheet ระบุว่าฮาร์ดดิสก์ทั่วไปมีโอกาสเกิดข้อผิดพลาดในการอ่านที่กู้คืนไม่ได้ (unrecoverable read error) อยู่ที่ประมาณ 1 ครั้งต่อทุกๆ 10^14 บิตที่อ่าน ในขณะที่ NVMe ระดับองค์กรจะอยู่ที่ 1 ครั้งต่อ 10^17 บิตหรือดีกว่านั้น แม้ตัวเลขเหล่านี้จะเป็นค่าจากผู้ผลิตมากกว่าการวัดผลจริง แต่สัดส่วนดังกล่าวอธิบายได้ว่าทำไมคำเตือนเก่าที่ว่าการสร้าง RAID 5 ใหม่มักจะล้มเหลว จึงถูกเขียนขึ้นสำหรับฮาร์ดดิสก์แบบจานหมุนขนาดใหญ่ และทำไมความเสี่ยงนี้จึงลดลงมากใน NVMe อย่างไรก็ตาม ข้อโต้แย้งเรื่องภาระของระบบ (load) ยังคงเป็นจริงสำหรับสื่อบันทึกข้อมูลทุกประเภท

ให้ค้นหาข้อผิดพลาดที่แฝงอยู่ก่อนที่กระบวนการสร้างข้อมูลใหม่จะตรวจพบ โดยการทำ scrubbing ทั้ง Debian และ Ubuntu มีการตั้งค่า scrub เป็นระยะสำหรับ md arrays ซึ่งกลไกจะแตกต่างกันไปตามรุ่น ดังนั้นให้ตรวจสอบว่าระบบของคุณใช้แบบใด แล้วจึงสั่งรันการตรวจสอบด้วยตนเอง

systemctl list-timers --all | grep -i mdcheck
ls -l /etc/cron.d/mdadm
echo check | sudo tee /sys/block/md0/md/sync_action
cat /sys/block/md0/md/mismatch_cnt

sync_action จะกลับไปเป็น idle เมื่อการตรวจสอบเสร็จสิ้น และ mismatch_cnt ควรแสดงค่าเป็น 0 หากพบตัวเลขที่มากกว่าศูนย์บน mirror แสดงว่าข้อมูลทั้งสองฝั่งไม่ตรงกันและ kernel ไม่สามารถระบุได้ว่าฝั่งใดถูกต้อง เนื่องจากไม่มีการเก็บ checksum ไว้ในสำเนาทั้งสองชุด ความไม่ตรงกันบางอย่างอาจไม่มีอันตราย โดยมักเกิดจาก swap partition เนื่องจาก kernel อาจเขียนหน้าข้อมูล (page) ที่มีการเปลี่ยนแปลงอยู่เบื้องหลัง หากพบจำนวนที่เพิ่มขึ้นเรื่อยๆ บน data array นั่นคือสัญญาณว่าควรเปลี่ยนไดรฟ์นั้นได้แล้ว

เหตุผลที่ผู้ให้บริการ VPS เลือกใช้ RAID 10 เป็นมาตรฐานสำหรับ NVMe

โหนด Hypervisor ไม่ได้รันเพียงแค่เวิร์กโหลดเดียว แต่รัน Guest หลายสิบรายการที่ไม่เกี่ยวข้องกัน โดย I/O ของแต่ละรายการจะเข้ามาแบบสลับกันเป็นกระแสของการเขียนขนาดเล็กที่ไม่มีความต่อเนื่องกัน (locality) นี่คือรูปแบบการทำงานที่วงจรการอ่าน-แก้ไข-เขียน (read-modify-write) ของ parity สร้างภาระต้นทุนสูงที่สุด และเป็นรูปแบบที่โหนดที่ใช้งานร่วมกันต้องเผชิญตลอดเวลา

เมื่อพิจารณาถึงพฤติกรรมการกู้คืนข้อมูล (rebuild) การตัดสินใจเลือกจึงชัดเจนขึ้น ไดรฟ์ที่ล้มเหลวในโหนดที่ใช้ parity จะทำให้ Guest ทุกตัวบนเครื่องทำงานช้าลงเป็นเวลาหลายชั่วโมง ในขณะที่ไดรฟ์ที่ล้มเหลวในโหนด RAID 10 จะส่งผลกระทบต่อเพียงคู่กระจก (mirror) คู่เดียวเท่านั้น และการคัดลอกข้อมูลจะทำงานแบบลำดับด้วยความเร็วสูงสุดของไดรฟ์ ผู้ให้บริการขายความหน่วง (latency) ที่ต้องไม่พุ่งสูงขึ้น จึงเลือกแลกด้วยความจุ โดยยอมเสียพื้นที่ NVMe ดิบครึ่งหนึ่งไปกับการทำ mirror

ขนาดของไดรฟ์ก็เป็นปัจจัยผลักดันในทิศทางเดียวกัน ยิ่งไดรฟ์มีขนาดใหญ่ขึ้น ระยะเวลาในการกู้คืนข้อมูลก็นานขึ้น และในระบบ parity ช่วงเวลาดังกล่าวนี่เองที่ทุกอย่างจะทำงานช้าลงและไม่มีการป้องกันข้อมูล นี่เป็นเหตุผลเดียวกันกับที่การติดตั้ง ZFS สำหรับงานเวอร์ชวลไลเซชันเลือกใช้ pool ของ vdev แบบ mirror แทนการใช้ raidz ขนาดใหญ่ เพราะการทำ resilver ของ mirror จะคัดลอกเฉพาะบล็อกที่มีการใช้งานจริงบนคู่ไดรฟ์นั้นเท่านั้น

ไม่มีสิ่งใดที่ทำให้ RAID 10 เป็นตัวเลือกที่ถูกต้องในทุกสถานการณ์ เป้าหมายสำหรับการสำรองข้อมูล (backup target) มักมีการเขียนแบบลำดับยาวๆ และมีการอ่านน้อยครั้ง ดังนั้น RAID 6 จึงเป็นตัวเลือกที่คุ้มค่ากว่า เพราะสามารถรองรับความล้มเหลวได้ถึงสองไดรฟ์และคืนพื้นที่ความจุส่วนใหญ่กลับมาได้ เวิร์กโหลดจะเป็นตัวกำหนด ไม่ใช่จำนวนไดรฟ์ สำหรับแผนที่คุณกำลังเลือกในปัจจุบัน สื่อจัดเก็บข้อมูลมักมีความสำคัญมากกว่ารูปแบบการจัดวางข้อมูลที่อยู่ด้านบน และ การเปลี่ยนจาก SATA SSD ไปเป็น NVMe นั้นสร้างความแตกต่างได้มากกว่าความแตกต่างของ RAID ใดๆ บนสื่อทั้งสองประเภท

วิธีอ่านค่า /proc/mdstat

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

cat /proc/mdstat
sudo mdadm --detail /dev/md0
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS

RAID 10 แบบสี่ไดรฟ์ที่ทำงานปกติจะแสดงผลลัพธ์ใกล้เคียงกับตัวอย่างนี้

Personalities : [raid1] [raid10]
md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2] nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 0/30 pages [0KB], 65536KB chunk

unused devices: <none>

ทุกส่วนของข้อมูลนั้นมีความหมาย

• Personalities แสดงรายการ md modules ที่ kernel กำลังใช้งานอยู่ การที่ raid10 ปรากฏขึ้นหมายความว่ามีโค้ดพร้อมใช้งานเท่านั้น ไม่ได้บ่งบอกถึงสถานะอื่น
• md0 : active raid10 คืออุปกรณ์อาร์เรย์ สถานะ และระดับของ RAID
• ชื่อที่ตามหลังคือสมาชิกของอาร์เรย์ ตัวเลขในวงเล็บเหลี่ยมคือดัชนีของอุปกรณ์ใน metadata ของอาร์เรย์ ไม่ใช่ตำแหน่งบนบรรทัดและไม่ใช่สล็อตที่ติดตั้งเสมอไป
• หลังจากเปลี่ยนไดรฟ์ สมาชิกใหม่มักจะมีดัชนีสูงกว่าสล็อตที่มันเข้าไปแทนที่ ดังนั้น nvme4n1p3[4] อาจจะไปอยู่ในสล็อต 2 ได้ mdadm --detail จะแสดงสล็อตจริงในคอลัมน์ RaidDevice ดังนั้นให้ใช้ค่านี้เมื่อความแตกต่างมีความสำคัญ
• (F) หลังชื่อสมาชิกหมายถึงเกิดข้อผิดพลาด (faulty) ส่วน (S) หมายถึงสแปร์ (spare): คือมีอยู่แต่ไม่ได้ใช้งาน รอให้มีบางอย่างล้มเหลว
• 3906764800 blocks super 1.2 คือขนาดที่ใช้งานได้ในหน่วยบล็อกละ 1 KiB ตามด้วยรูปแบบ metadata
• 512K chunks 2 near-copies คือขนาด chunk ของ stripe และรูปแบบของ RAID 10 ซึ่งในที่นี้จะเก็บข้อมูลสำรองสองชุดไว้ติดกัน
• [4/4] คือจำนวนสมาชิกที่อาร์เรย์คาดหวัง ตามด้วยจำนวนที่กำลังซิงค์อยู่จริง
• [UUUU] คือตัวอักษรหนึ่งตัวต่อหนึ่งสล็อต เรียงตามลำดับสล็อต U คือสล็อตที่ทำงานปกติและซิงค์อยู่ _ คือสล็อตที่ไม่มีอุปกรณ์ทำงานอยู่
• bitmap: คือ write intent bitmap ซึ่งบันทึกว่าส่วนใดของข้อมูลที่กำลังถูกเขียน เพื่อที่ว่าหากสมาชิกตัวใดหลุดไปและกลับเข้ามาใหม่ ระบบจะซิงค์เฉพาะส่วนนั้นแทนที่จะซิงค์ทั้งไดรฟ์

ความหมายของ [4/3] และ [UU_U] เมื่อเกิดปัญหา

อาร์เรย์ที่อยู่ในสถานะ degraded จะแสดงผลดังนี้

md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2](F) nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]

ให้อ่านวงเล็บทั้งสองคู่พร้อมกัน [4/3] บอกว่าหนึ่งในสี่สล็อตไม่ได้ทำงาน [UU_U] บอกว่าสล็อตไหนที่เสีย เนื่องจากขีดล่าง (underscore) อยู่ในตำแหน่งที่สามและสล็อตเริ่มนับจากศูนย์ ดังนั้นสล็อต 2 จึงใช้งานไม่ได้ แฟล็ก (F) จะระบุชื่ออุปกรณ์เฉพาะในขณะที่ไดรฟ์ที่เสียยังคงเชื่อมต่ออยู่ หากคุณถอดมันออกจากเครื่อง ชื่อนั้นจะหายไปจากบรรทัด แต่ขีดล่างจะยังคงอยู่

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

grep -i mailaddr /etc/mdadm/mdadm.conf
sudo mdadm --monitor --scan --oneshot --test
systemctl list-units --all | grep -i md

แพ็กเกจ mdadm จะติดตั้ง daemon สำหรับตรวจสอบที่อ่านค่า MAILADDR จาก /etc/mdadm/mdadm.conf และเนื่องจากชื่อ unit มีการเปลี่ยนแปลงระหว่างรุ่น ให้ค้นหาด้วยคำสั่งล่าสุดแทนการเดา การรัน --test จะส่งข้อความหนึ่งฉบับต่อหนึ่งอาร์เรย์ทันที หากกล่องจดหมายว่างเปล่าหลังจากรันคำสั่ง แสดงว่าเส้นทางการส่งอีเมลมีปัญหา ซึ่งหมายความว่าข้อความแจ้งเตือนที่คุณต้องการจะสูญหายไปในลักษณะเดียวกัน

เมื่อมีการสร้างข้อมูลใหม่ (rebuild) หลังจากเปลี่ยนไดรฟ์ บรรทัดแสดงความคืบหน้าจะปรากฏขึ้นใต้อาร์เรย์

md0 : active raid10 nvme4n1p3[4] nvme3n1p3[3] nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]
      [==>..................]  recovery = 12.4% (242012928/1953382400) finish=63.1min speed=452000K/sec

recovery คือการ rebuild ลงบนไดรฟ์ที่เปลี่ยนใหม่ resync คือการตรวจสอบความถูกต้องรอบแรกของอาร์เรย์ที่เพิ่งสร้างขึ้น check คือการ scrub ที่คุณสั่งรันข้างต้น คู่ตัวเลขในวงเล็บคือความคืบหน้าในหน่วยบล็อกละ 1 KiB เทียบกับขนาดรวมของอุปกรณ์ และ finish คือเวลาที่ kernel คาดการณ์ไว้ตามความเร็วปัจจุบัน ความเร็วนี้ถูกจำกัดด้วย /proc/sys/dev/raid/speed_limit_min และ speed_limit_max ซึ่งการจำกัดนี้มีไว้เพื่อให้การ rebuild ไม่แย่งทรัพยากร I/O ของระบบหลัก

/dev/md0:
           Version : 1.2
     Creation Time : Tue Mar 10 09:14:22 2026
        Raid Level : raid10
        Array Size : 3906764800 (3.64 TiB 4.00 TB)
     Used Dev Size : 1953382400 (1.82 TiB 2.00 TB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

       Update Time : Wed Aug  5 11:02:41 2026
             State : clean, degraded, recovering
    Active Devices : 3
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 1

            Layout : near=2
        Chunk Size : 512K

    Rebuild Status : 12% complete

              Name : storage:0
            Events : 4184

    Number   Major   Minor   RaidDevice State
       0     259        3        0      active sync set-A   /dev/nvme0n1p3
       1     259        7        1      active sync set-B   /dev/nvme1n1p3
       4     259       11        2      spare rebuilding    /dev/nvme4n1p3
       3     259       15        3      active sync set-B   /dev/nvme3n1p3

การเปลี่ยนไดรฟ์ในอาร์เรย์ที่คุณเป็นเจ้าของใช้คำสั่ง 4 ขั้นตอน และคำสั่งสุดท้ายคือการตรวจสอบ

sudo mdadm --manage /dev/md0 --fail /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --remove /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --add /dev/nvme4n1p3
cat /proc/mdstat

บรรทัดการกู้คืน (recovery) ควรปรากฏขึ้นภายในหนึ่งหรือสองวินาที พาร์ทิชันที่นำมาเปลี่ยนต้องมีขนาดอย่างน้อยเท่ากับ Used Dev Size จาก mdadm --detail และพาร์ทิชันที่เล็กกว่าแม้เพียงเล็กน้อยจะถูกปฏิเสธด้วยข้อความในรูปแบบ not large enough to join array ให้แบ่งพาร์ทิชันไดรฟ์ใหม่ให้ตรงกับไดรฟ์เดิมก่อนที่คุณจะเพิ่มเข้าไปในอาร์เรย์

สิ่งที่คุณสามารถและไม่สามารถมองเห็นได้จากภายใน VPS

โดยส่วนใหญ่แล้ว Guest จะไม่สามารถมองเห็น RAID ของ Host ได้ ซึ่งเป็นไปตามการออกแบบ Hypervisor จะจัดสรร Virtual disk ให้คุณหนึ่งชุด ไม่ว่าดิสก์นั้นจะถูกแบ่งมาจาก RAID 10 pool ของ NVMe drive หรือวางอยู่บนไดรฟ์เพียงตัวเดียวก็ตาม สิ่งเหล่านี้ถือเป็นคุณสมบัติของ Host และจะไม่ปรากฏให้เห็นภายใน Guest ของคุณ

systemd-detect-virt
lsblk -d -o NAME,SIZE,ROTA,MODEL
cat /proc/mdstat

systemd-detect-virt จะแสดง kvm บน KVM guest, แสดงประเภท container เช่น lxc บน container และแสดง none บน bare metal สำหรับ KVM guest โดยปกติคุณจะเห็นเพียง vda หรือ sda เพียงชุดเดียวใน lsblk และไม่พบ array ใดๆ ใน /proc/mdstat เนื่องจากไม่มี array เหล่านั้นอยู่ภายใน Guest

สำหรับ VPS ที่ใช้เทคโนโลยี container ข้อมูลที่อ่านได้จะไม่น่าเชื่อถือ เนื่องจาก container ใช้ kernel ร่วมกับ Host และบางส่วนของ /proc ไม่ได้ถูกทำ namespaced ดังนั้นสิ่งที่คุณอ่านได้จากจุดนั้นอาจเป็นการอธิบายถึงตัว Host แทนที่จะเป็นส่วนแบ่งของคุณ อย่าถือว่าข้อมูลใดๆ เป็นข้อเท็จจริงเกี่ยวกับพื้นที่จัดเก็บข้อมูลของคุณเอง ให้สอบถามผู้ให้บริการเกี่ยวกับโครงสร้างการจัดเก็บข้อมูล และขอคำตอบเป็นลายลักษณ์อักษรหากข้อมูลนั้นมีความสำคัญต่อคุณ

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

คุณควรทำ RAID ภายใน VPS หรือไม่

โดยปกติแล้วไม่ควรทำ เนื่องจากปัญหาเรื่องขอบเขตความล้มเหลว (failure domains) หากคุณเชื่อมต่อ volume สองชุดเข้ากับ VPS เดียวกันแล้วทำ mirror ด้วย mdadm ทั้งสอง volume อาจถูกจัดเก็บอยู่บน physical array เดียวกัน บนโหนดเดียวกัน และใช้แหล่งจ่ายไฟเดียวกัน คุณจะต้องเสียค่าใช้จ่ายในการเขียนข้อมูลเพิ่มขึ้นเป็นสองเท่าเพื่อแลกกับความซ้ำซ้อนที่คุณมีอยู่แล้ว และคุณยังคงสูญเสียข้อมูลทั้งสองชุดหากเกิดความล้มเหลวในจุดเดียวที่สำคัญ

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

สิ่งที่ RAID ไม่สามารถปกป้องคุณได้

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

• การลบข้อมูล. rm -rf ในไดเรกทอรีที่ผิด หรือสคริปต์ deploy ที่มีตัวแปรไม่ได้กำหนดค่าใน path อาร์เรย์จะมองว่าเป็นการเขียนที่ถูกต้องและดำเนินการซ้ำสองครั้ง
• Ransomware. การเข้ารหัสคือการเขียนข้อมูล อาร์เรย์ที่ปกติจะจัดเก็บเวอร์ชันที่ถูกเข้ารหัสไว้ในทั้งสองฝั่งของ mirror
• แอปพลิเคชันที่ทำงานผิดพลาด. บั๊กที่เขียนข้อมูลขยะลงในฐานข้อมูลของคุณ จะเขียนข้อมูลขยะชุดเดียวกันลงในไดรฟ์สำรองด้วย
• โหนดทั้งหมด. โฮสต์ที่ล้มเหลว หรือบัญชีที่ถูกระงับโดยไม่ได้ตั้งใจ อาร์เรย์อาจอยู่ในสถานะสมบูรณ์แบบแต่ไม่สามารถเข้าถึงได้ในเวลาเดียวกัน
• ตัวคุณเองในอีกหนึ่งสัปดาห์ถัดมา. ไฟล์ที่คุณลบไปเมื่อวันจันทร์จะหายไปจากทุกไดรฟ์ตั้งแต่วันจันทร์นั้น มีเพียงสำเนาที่ทำไว้ก่อนหน้านั้นเท่านั้นที่จะนำข้อมูลกลับมาได้

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

FAQ

RAID 10 หมายความว่าฉันไม่จำเป็นต้องสำรองข้อมูลใช่หรือไม่?

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

ทำไมผู้ให้บริการ VPS ถึงเลือกใช้ RAID 10 แทน RAID 5 หรือ RAID 6?

มีสองเหตุผลหลัก ซึ่งเกี่ยวข้องกับการเขียนข้อมูลขนาดเล็กแบบสุ่ม การเขียนข้อมูลแบบ parity ต้องอ่านข้อมูลเดิมและค่า parity เดิมกลับมาก่อนจึงจะคำนวณค่า parity ใหม่ได้ ดังนั้นการเขียนข้อมูลขนาดเล็กหนึ่งครั้งจะใช้ 4 โอเปอเรชันบน RAID 5 และ 6 บน RAID 6 ในขณะที่การทำ mirror ใช้เพียง 2 เท่านั้น นอกจากนี้ การสร้างอาร์เรย์ใหม่ (rebuild) แบบ parity ต้องอ่านข้อมูลจากทุกไดรฟ์ที่เหลืออยู่ตั้งแต่ต้นจนจบ ซึ่งทำให้ guest ทุกตัวบนโหนดทำงานช้าลงเป็นเวลาหลายชั่วโมง ในขณะที่การ rebuild ของ RAID 10 เป็นเพียงการคัดลอกข้อมูลจากไดรฟ์หนึ่งไปยังอีกไดรฟ์หนึ่งโดยไม่กระทบต่อคู่ไดรฟ์อื่น ผู้ให้บริการยอมแลกสิ่งนี้ด้วยความจุที่หายไปครึ่งหนึ่งของ NVMe ดิบ

[U_] หรือ [UU_U] ใน /proc/mdstat หมายความว่าอย่างไร?

อักขระแต่ละตัวแทนช่อง (slot) ในอาร์เรย์ตามลำดับ โดยหนึ่งอักขระต่อหนึ่งช่อง U หมายความว่าช่องนั้นมีสมาชิกที่ทำงานปกติและซิงค์ข้อมูลอยู่ _ หมายความว่าช่องนั้นไม่มีอุปกรณ์ที่ทำงานได้ [U_] ในกรณีของ mirror สองไดรฟ์ หมายความว่าช่องที่สองหยุดทำงานและไม่มีความซ้ำซ้อนเหลืออยู่ ให้พิจารณาร่วมกับคู่ที่อยู่ข้างหน้า เช่น [4/3] ซึ่งระบุว่าอาร์เรย์คาดหวังสมาชิกสี่ตัวแต่มีอยู่สามตัว ลำดับของช่องจะตรงกับคอลัมน์ RaidDevice ของ mdadm --detail ไม่ใช่ลำดับที่ชื่ออุปกรณ์ปรากฏบนบรรทัด

อาร์เรย์ RAID 10 สามารถสูญเสียไดรฟ์ได้กี่ตัว?

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

ฉันควรทำ mirror สองโวลุ่มภายใน VPS ด้วย mdadm หรือไม่?

โดยปกติแล้วไม่ควร โวลุ่มสองตัวที่เชื่อมต่อกับ VPS เดียวกันมักจะอยู่บนอาร์เรย์ทางกายภาพเดียวกันบนโฮสต์เดียวกัน ดังนั้นการทำ mirror จะเพิ่มต้นทุนในการเขียนข้อมูลเป็นสองเท่าโดยไม่ได้ป้องกันความเสี่ยงใดๆ ที่ RAID ของโฮสต์ไม่ได้ครอบคลุมอยู่แล้ว การทำเช่นนี้จะคุ้มค่าก็ต่อเมื่อผู้ให้บริการระบุชัดเจนว่าโวลุ่มเหล่านั้นอยู่ในโดเมนความล้มเหลว (failure domain) ที่แยกจากกัน มิฉะนั้นควรนำทรัพยากรไปใช้กับการสำรองข้อมูลที่เก็บไว้นอกเครื่องจะดีกว่า