מהו RAID 10 ואיך הוא עובד בשרתי VPS?

מהו RAID 10 ומדוע ספקי VPS משתמשים בו

RAID 10 הוא מבנה האחסון הנפוץ ביותר אצל ספקי VPS המשתמשים בכונני NVMe (non-volatile memory express) וירטואליים. המערך משכפל כל כונן לכונן תואם, ולאחר מכן מבצע striping לנתונים על פני זוגות משוכפלים אלו. כונן אחד יכול להיכשל מבלי שהמערך יפסיק לעבוד, והתיקון מתבצע באמצעות העתקה פשוטה מהכונן התואם שנותר, במקום חישוב מחדש הדורש קריאה מכל שאר הכוננים בסט.

המונח RAID מייצג redundant array of independent disks. תפקידו היחיד הוא להבטיח שהמכונה תמשיך לספק שירות בזמן שכונן מושבת או מוחלף. תפקיד זה הוא זמינות (availability), וזמינות אינה שווה לבטיחות נתונים.

RAID משכפל את פעולות הכתיבה שלכם. rm -rf /srv היא פעולת כתיבה. שני חלקי המראה מוחקים את הספרייה באותה מילי-שנייה, והמערך מדווח על עצמו כתקין גם לאחר מכן.

שמרו על משפט זה. שאר הדף סוקר אילו כשלים כל רמה מסוגלת לשרוד ומה העלות של כל אחת מהן בכל פעולת כתיבה. הסעיפים האחרונים כוללים את הפקודות לקריאת מצב המערך במכונה שבבעלותכם, ואת סוג הכשל ש־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 הוא פיצול של שיקופים. כוננים משוקפים בזוגות, והנתונים מופצים על פני הזוגות. הקיבולת הזמינה היא חצי מהסך הגולמי, בדומה ל-RAID 1, עם היתרון של מקביליות הפיצול מעל.

ניתן לראות זאת כתוב גם כ-RAID 1+0, שזהו התיאור המדויק: שיקוף תחילה, ואז פיצול על פני השיקופים. RAID 0+1 הוא הסדר ההפוך: פיצול תחילה ואז שיקוף של שני ה-stripes. הוא פחות מומלץ, כיוון שכשל של כונן אחד מוציא stripe שלם משירות, והתיקון מחייב העתקה של כל הצד השני.

Linux מהווה מקרה מיוחד שכדאי להכיר. ה-raid10 של ה-kernel הוא ישות אחת ולא שתי שכבות מוערמות, לכן הוא רץ על מספר אי-זוגי של כוננים ויש לו פריסות (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 היא שתי פעולות כתיבה, המבוצעות בו-זמנית לשני החברים. כתיבה ל-parity stripe דורשת עבודה רבה יותר, כיוון שבלוק ה-parity עבור אותו stripe אינו מעודכן עוד ויש לחשב אותו מחדש.

הבקר אינו יכול לחשב את ה-parity מתוך הבלוק החדש בלבד. הוא זקוק תחילה לבלוק הנתונים הישן ולבלוק ה-parity הישן. לכן, כתיבה אקראית אחת קטנה ב-RAID 5 הופכת ל-read, read, write, write. ב-RAID 6 יש syndrome שני לתחזוקה, ולכן אותה כתיבה הופכת ל-read, read, read, write, write, write.

[
  {
    "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 כולל פעולת read שחייבת להסתיים לפני שניתן לחשב את ה-parity החדש, לכן ה-guest ממתין ל-read ולאחריו ל-write, בזה אחר זה. במארח עמוס, ה-read הזה עומד בתור מאחורי ה-I/O של כל השאר.

ישנו חריג חשוב. כתיבה גדולה מספיק כדי למלא stripe שלם אינה זקוקה לנתונים ישנים, כיוון שכל בלוק ב-stripe מוחלף. ה-parity מחושב ממה שכבר נמצא בזיכרון, והעלות יורדת לכדי כתיבה נוספת אחת בלבד. זו הסיבה ש-RAID 5 נראה תקין ב-benchmark סדרתי אך מתנהג בצורה גרועה תחת עומס מעורב של כתיבות קטנות מצד דיירים רבים. בדקו את התבנית שאתם מריצים בפועל: ביצוע benchmark תקין לדיסק של VPS משמעו I/O אקראי בעומק תור ריאלי, ולא dd אחד גדול.

מדוע תהליך הבנייה מחדש (rebuild) הוא החלק המסוכן

בנייה מחדש של מערך parity דורשת שחזור של הכונן החסר מתוך כל שאר הכוננים, ולכן המערכת קוראת את 7 הכוננים ששרדו, מהבלוק הראשון ועד האחרון. בנייה מחדש של RAID 10 קוראת את 1: רק את הכונן התאום של הכונן התקול, ולא שום דבר אחר.

מכאן נובעים שני סוגי עלויות. הראשונה היא זמן, כיוון שהבנייה מחדש מוגבלת על ידי הכונן האיטי ביותר ששרד ועל ידי חישובי ה־parity הנוספים. השנייה היא עומס. כל כונן במערך parity עסוק לאורך כל משך הפעולה, ולכן כל לקוח (guest) באותו צומת יחווה שיהוי (latency) גבוה יותר עד לסיום התהליך. ב־RAID 10, רק זוג אחד עסוק בעוד שאר הזוגות ממשיכים לעבוד במהירותם הרגילה.

באותו חלון זמן קיים גם סיכון לשלמות הנתונים. מערך RAID 5 עם כונן אחד תקול נותר ללא יתירות, ולכן סקטור בלתי קריא בכל אחד מהכוננים ששרדו הופך לבלתי ניתן לשחזור. בנייה מחדש היא הפעולה היחידה שקוראת כל סקטור, כולל כאלו שלא ניגשו אליהם במשך שנה. נתוני היצרן הרשמיים מציבים כונן קשיח צרכני על שגיאת קריאה בלתי ניתנת לשחזור אחת לכל 10^14 ביטים שנקראו, וכונן NVMe ארגוני על אחת לכל 10^17 או טוב מכך. אלו מפרטי יצרן ולא מדידות בפועל, אך היחס מסביר מדוע האזהרה הישנה לפיה בנייה מחדש של RAID 5 תיכשל נכתבה על כוננים מסתובבים גדולים, ומדוע היא פחות רלוונטית ב־NVMe. טיעון העומס, לעומת זאת, תקף לכל סוג מדיה.

אתרו שגיאות סמויות לפני שהבנייה מחדש תעשה זאת, באמצעות פעולת scrubbing. ב־Debian וב־Ubuntu מוגדרת מראש פעולת scrub תקופתית עבור מערכי md, אך המנגנון משתנה בין גרסאות, לכן בדקו באיזה מנגנון אתם משתמשים והפעילו סריקה ידנית.

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 מעיד על כך ששני החצאים אינם מסונכרנים והקרנל אינו יכול לקבוע מי מהם צודק, כיוון שאף עותק אינו נושא checksum. חלק מהאי-התאמות הללו אינן מזיקות, ומחיצות swap הן המקור הנפוץ לכך: הקרנל עשוי לכתוב דף זיכרון שמשתנה מתחתיו. מספר עולה במערך נתונים הוא סימן לכונן שיש להחליף.

מדוע ספקי VPS מתקננים על RAID 10 עבור NVMe

צומת Hypervisor אינו מריץ עומס עבודה יחיד. הוא מריץ עשרות אורחים שאינם קשורים זה לזה, וה־I/O שלהם מגיע משולב כזרם של כתיבות קטנות ללא לוקאליות ביניהן. זהו בדיוק הדפוס שבו מחזור ה־read-modify-write של זוגיות (parity) עולה ביוקר, וזהו הדפוס שקיים בצומת משותף לאורך כל היום.

הוסיפו לכך את התנהגות השחזור (rebuild), והבחירה הופכת למובנת מאליה. כונן תקול בצומת מבוסס זוגיות מאט כל אורח בשרת למשך שעות. כונן תקול בצומת RAID 10 מאט רק זוג אחד, וההעתקה מתבצעת באופן סדרתי במהירות הכונן. ספקים מוכרים שיהוי (latency) שאינו מזנק, לכן הם קונים אותו באמצעות קיבולת: מחצית מנפח ה־NVMe הגולמי מוקצה לשיקוף (mirror).

גדלי הכוננים דוחפים לאותו כיוון. ככל שהכוננים גדלים, חלון השחזור מתארך, ובמערך זוגיות זהו החלון שבו הכל איטי ושום דבר אינו מוגן. זו אותה סיבה שפריסות ZFS עבור וירטואליזציה משתמשות במאגרים של vdevs משוקפים במקום ב-raidz רחב: פעולת resilver של מראה מעתיקה רק את הבלוקים שנמצאים בשימוש בפועל, על זוג אחד בלבד.

שום דבר מזה לא הופך את RAID 10 לנכון בכל מקום. יעד גיבוי נכתב ברצפים ארוכים ונקרא לעיתים רחוקות, לכן 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 שהקרנל הפעיל טען. הופעת raid10 שם מציינת שהקוד זמין, ותו לא.
• md0 : active raid10 הוא התקן המערך, מצבו, ורמת ה-RAID שלו.
• השמות המופיעים לאחר מכן הם החברים במערך. המספר בסוגריים מרובעים הוא האינדקס של ההתקן במטא-דאטה של המערך, לא המיקום שלו בשורה ולא תמיד ה-slot שלו.
• לאחר החלפת כונן, החבר החדש בדרך כלל שומר על אינדקס גבוה יותר מה-slot שהוא ממלא, לכן nvme4n1p3[4] יכול לשבת ב-slot 2. הפקודה mdadm --detail מדפיסה את ה-slot האמיתי בעמודה RaidDevice, לכן השתמשו בה כאשר ההבדל משמעותי.
• (F) אחרי חבר במערך מציין שהוא תקול. (S) מציין שהוא spare: קיים, לא פעיל, וממתין לכשל כלשהו.
• 3906764800 blocks super 1.2 הוא הגודל הזמין בבלוקים של 1 KiB, ולאחריו פורמט המטא-דאטה.
• 512K chunks 2 near-copies הוא גודל ה-chunk של ה-stripe ומבנה ה-RAID 10, אשר במקרה זה שומר שני עותקים של כל בלוק זה לצד זה.
• [4/4] הוא מספר החברים שהמערך מצפה לו, ולאחריו מספר החברים שמסונכרנים כרגע.
• [UUUU] הוא תו אחד לכל slot, לפי סדר ה-slots. U הוא slot תקין ומסונכרן. _ הוא slot שבו שום דבר לא עובד.
• 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] מציין שאחד מתוך ארבעה slots אינו תורם למערך. [UU_U] מציין איזה מהם, כיוון שקו התחתון הוא התו השלישי וה-slots ממוספרים מאפס, לכן slot 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 הוא הערכת הקרנל לפי המהירות הנוכחית. המהירות מוגבלת על ידי /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

החלפת כונן במערך שבבעלותכם מורכבת מארבע פקודות, והאחרונה שבהן היא הבדיקה.

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

רוב המערכות האורחות אינן יכולות לראות את ה-RAID של המארח, וזהו תכנון מכוון. ה-hypervisor מספק לך דיסק וירטואלי אחד. השאלה אם הדיסק הזה נגזר מתוך pool של RAID 10 על כונני NVMe או שהוא יושב על כונן בודד היא מאפיין של המארח, והיא אינה מופיעה בתוך המערכת האורחת שלך.

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

systemd-detect-virt מדפיס kvm במערכת אורחת מסוג KVM, סוג מכולה כמו lxc במכולה, ו-none על חומרה חשופה (bare metal). במערכת אורחת מסוג KVM תראה בדרך כלל vda או sda בודד ב-lsblk, ולא תראה מערכי דיסקים ב-/proc/mdstat, כיוון שאין כאלה בתוך המערכת האורחת.

ב-VPS מבוסס מכולות, הקריאה אינה מהימנה. מכולות חולקות את ה-kernel של המארח וחלקים מ-/proc אינם מבודדים ב-namespaces, לכן מה שאתה קורא שם עשוי לתאר את המארח ולא את החלק שלך בו. אל תתייחס לשום דבר מזה כאל עובדה לגבי האחסון שלך. שאל את הספק מהו המבנה, וקבל את התשובה בכתב אם הדבר חשוב לך.

מה שאתה יכול לבדוק מבפנים הוא את ההתנהגות של הדיסק שקיבלת. בדיקה האם דיסק ה-VPS שלך הוא באמת NVMe מכסה את הפקודות שמדווחות על נתונים ממשיים, ו-מה באמת כולל VPS מבוסס SSD מכסה את מה שהתווית בדף התוכנית טוענת.

האם כדאי להריץ RAID בתוך ה-VPS שלכם?

בדרך כלל לא, והסיבה לכך היא תחומי כשל (failure domains). אם תחברו שני כוננים (volumes) ל-VPS אחד ותבצעו ביניהם שיקוף (mirroring) באמצעות mdadm, ייתכן ששני הכוננים יאוחסנו על אותו מערך פיזי, באותו צומת, ומאחורי אותו ספק כוח. אתם תכפילו את עלות כל פעולת כתיבה עבור יתירות שכבר הייתה קיימת, ועדיין תאבדו את שני העותקים במקרה של כשל בודד ומשמעותי.

פעולה זו כדאית רק כאשר ספק השירות מתעד שהכוננים נמצאים בתחומי כשל נפרדים, או כאשר אתם עובדים על שרת ייעודי עם כוננים שניתן להצביע עליהם ישירות. אחרת, המאמץ מושקע טוב יותר בביצוע גיבויים שיוצאים אל מחוץ למכונה.

ממה RAID אינו מגן עליכם

RAID מכסה תרחיש אחד בלבד: כונן שמפסיק לעבוד כראוי. כל פעולה להלן נחשבת לכתיבה תקינה, ולכן המערך מבצע אותה על כל העותקים ומדווח על תקינותו.

• מחיקה. rm -rf בספרייה הלא נכונה, או סקריפט פריסה עם משתנה לא מוגדר בנתיב. המערך רואה פעולת כתיבה חוקית ומבצע אותה פעמיים.
• תוכנות כופר. הצפנה היא פעולת כתיבה. מערך תקין יאחסן את הגרסה המוצפנת בשני חלקי ה-mirror.
• יישום תקול. באג שכותב נתונים פגומים למסד הנתונים שלכם יכתוב את אותם נתונים פגומים גם לכונן היתיר.
• הצומת כולו. מארח שקורס, או חשבון שהושעה בטעות. מערך יכול להיות מושלם ובלתי נגיש בעת ובעונה אחת.
• אתם עצמכם, שבוע לאחר מכן. הקובץ שמחקתם ביום שני נעלם מכל הכוננים ביום שני. רק עותק שנלקח לפני כן יחזיר אותו.

Snapshot על אותו התקן אחסון אינם הפתרון. הם עוזרים נגד מחיקה, אך הם נעלמים יחד עם המערך שעליו הם נמצאים. התכונה שהופכת גיבוי לגיבוי היא היותו במקום אחר. גיבויים מוצפנים מחוץ לשרת באמצעות restic הם החצי השני של דף זה: המערך מאפשר לכם להמשיך לספק שירות גם כשכונן מת, ו-restic מחזיר את הנתונים שלכם כאשר הנזק נגרם כתוצאה מכתיבה שהמערך ביצע בשמחה.

FAQ

האם RAID 10 אומר שאיני זקוק לגיבויים?

לא. RAID 10 מגן מפני כונן שמפסיק לעבוד. הוא מבצע כל פעולת כתיבה תקינה על שני חלקי ה-mirror, לכן מחיקה או הרצה של תוכנת כופר מגיעות לכונן היתיר באותו רגע ממש. המערך מדווח על עצמו כתקין לאחר מכן, כיוון שמבחינתו שום דבר לא נכשל. אתם עדיין זקוקים לעותקים שנמצאים מחוץ למכונה, ואתם עדיין צריכים לשחזר אחד מהם מדי פעם כדי לוודא שהם עובדים.

מדוע ספקי VPS בוחרים ב-RAID 10 על פני RAID 5 או RAID 6?

שתי סיבות, שתיהן נוגעות לכתיבות אקראיות קטנות. כתיבת parity דורשת קריאה חוזרת של הנתונים הישנים וה-parity הישן לפני שניתן לחשב את ה-parity החדש, לכן כתיבה קטנה עולה 4 פעולות ב-RAID 5 ו-6 ב-RAID 6, לעומת 2 ב-mirror. בנייה מחדש (rebuild) של parity קוראת לאחר מכן כל כונן ששרד מתחילתו ועד סופו, מה שמאט כל אורח (guest) על ה-node למשך שעות, בעוד שבנייה מחדש של RAID 10 מעתיקה כונן אחד לכונן אחד ומשאירה את הזוגות האחרים ללא הפרעה. ספקים משלמים על כך בקיבולת: מחצית מה-NVMe הגולמי.

מה המשמעות של [U_] או [UU_U] בתוך /proc/mdstat?

כל תו מייצג חריץ (slot) במערך, לפי סדר החריצים, עם תו אחד לכל חריץ. U מציין שהחריץ מכיל חבר פעיל ומסונכרן. _ מציין שאין בחריץ שום דבר תקין. [U_] ב-mirror של שני כוננים אומר שהחריץ השני מושבת ואין יותר יתירות. קראו זאת יחד עם הזוג שלפניו, כאשר [4/3] אומר שהמערך מצפה לארבעה חברים ויש לו שלושה. סדר החריצים תואם לעמודת ה-RaidDevice של mdadm --detail, ולא לסדר שבו שמות ההתקנים מופיעים בשורה.

כמה כוננים יכול מערך RAID 10 לאבד?

אחד, בכל תבנית שהיא. מעבר לכך, זה תלוי היכן מתרחשים הכשלים. כל זוג mirror יכול לאבד אחד משני חבריו, לכן מערך של שמונה כוננים שורד עד ארבעה כשלים אם אף שניים מהם אינם חולקים זוג, והוא קורס בשני כשלים אם שניהם פוגעים באותו זוג. תכננו לפי המספר המובטח, שהוא אחד, והתייחסו לכל מה שמעבר לכך כמזל ולא כהגנה.

האם עלי לבצע mirror לשני כוננים בתוך ה-VPS שלי בעזרת mdadm?

בדרך כלל לא. שני כוננים שמחוברים ל-VPS אחד נמצאים לעיתים קרובות על אותו מערך פיזי באותו host, לכן ביצוע mirror להם מכפיל את העלות של כל כתיבה ואינו מגן מפני שום דבר שה-RAID של ה-host עצמו לא כיסה ממילא. כדאי לעשות זאת רק כאשר הספק מתעד שהכוננים יושבים ב-failure domains נפרדים. אחרת, השקיעו את המאמץ הזה בגיבויים שיוצאים מהמכונה.