RAID לעסקים: איך ממשיכים לעבוד גם כשכונן קורס

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

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

[מיקום מומלץ לתמונה]
נושא התמונה: מגירת כוננים בשרת או ב-NAS עם נורית אדומה על כונן אחד שכשל, ושאר הכוננים ירוקים.
תיאור התמונה: תקריב על מערך כוננים שבו כונן אחד מסומן ככשל בעוד המערכת ממשיכה לעבוד, להמחשת רעיון היתירות.
טקסט ALT מוצע: מערך כוננים בשרת עם כונן כושל אחד בעוד שאר הכוננים ממשיכים לפעול — RAID לעסקים

איך RAID באמת עובד: פסים, שיקוף וזוגיות

כל רמות ה-RAID נבנות משילוב של שלושה מנגנונים בסיסיים. הבנה שלהם היא כל מה שצריך כדי לקרוא נכון את הרמות עצמן.

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

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

זוגיות (Parity) היא הפתרון החכם באמצע. במקום לשכפל את כל המידע, הבקר מחשב מידע שחזור (checksum) באמצעות פעולת XOR ומפזר אותו על פני הכוננים. אם כונן אחד נופל, אפשר לשחזר את תוכנו על ידי חישוב חוזר מהמידע ומהזוגיות שנשארו. זה חוסך מקום דרמטית — אבל גובה מחיר בכתיבה: כל כתיבה מחייבת מחזור "קרא–שנה–כתוב" (Read-Modify-Write) שבו הבקר קורא את המידע הקיים, מחשב זוגיות חדשה, וכותב את שניהם בחזרה. זה מה שנקרא "קנס הכתיבה" של מערכי זוגיות.

רמות ה-RAID הנפוצות בעסקים

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

RAID 1 — שיקוף של שני כוננים. פשוט, אמין, ומהיר לשחזר. הקיבולת השמישה היא חצי מהגולמית (עותק אחד מתוך שניים), ביצועי הקריאה משתפרים כי אפשר לקרוא משני הכוננים במקביל, אבל הכתיבה נעשית לשניהם. זו הבחירה הטבעית לשרת קטן או לזוג כוננים במערכת קריטית שבה הפשטות חשובה יותר מהקיבולת.

RAID 5 — פסים עם זוגיות מבוזרת, שלושה כוננים לפחות. הרמה הנפוצה ביותר היסטורית, כי היא מציעה איזון טוב: מתוך n כוננים, הקיבולת השמישה היא n מינוס אחד, והמערך שורד כשל של כונן אחד. הקריאה מהירה; הכתיבה סובלת מקנס הזוגיות. הבעיה — שנרחיב עליה בהמשך — מתחילה כשהכוננים גדולים.

RAID 6 — כמו RAID 5 אבל עם זוגיות כפולה, ארבעה כוננים לפחות. הוא כותב שני בלוקי זוגיות במקום אחד, ולכן שורד כשל של שני כוננים בו-זמנית. הקיבולת השמישה היא n מינוס שניים, והכתיבה איטית יותר מ-RAID 5 בגלל החישוב הכפול. זו הרמה שהפכה לברירת המחדל למערכי כוננים מכניים גדולים, מסיבה מאוד ספציפית שקשורה לשחזור.

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

[מיקום מומלץ לתמונה]
נושא התמונה: דיאגרמה סכמטית שמשווה RAID 0, 1, 5, 6 ו-10 — פיזור בלוקים, שיקוף ובלוקי זוגיות.
תיאור התמונה: תרשים המחשה של אופן פיזור המידע בכל רמת RAID, עם צבע נפרד לבלוקי הזוגיות.
טקסט ALT מוצע: דיאגרמת השוואה בין רמות RAID 0 1 5 6 10 — פסים, שיקוף וזוגיות

השוואת רמות RAID

רמה	מנגנון	מינימום כוננים	קיבולת שמישה	עמידות בכשל	מתאים ל
RAID 0	פסים	2	100% (n)	אין	מידע זמני שאפשר לייצר מחדש
RAID 1	שיקוף	2	50% (n/2)	כונן אחד	שרת קטן, זוג כוננים במערכת קריטית
RAID 5	פסים + זוגיות בודדת	3	n−1	כונן אחד	איזון קיבולת/הגנה, כוננים קטנים או SSD
RAID 6	פסים + זוגיות כפולה	4	n−2	שני כוננים	מערכי כוננים מכניים גדולים
RAID 10	שיקוף + פסים	4	50% (n/2)	כונן אחד מכל זוג	בסיסי נתונים, עומסי כתיבה כבדים

מה קורה בשנייה שכונן קורס: כונן חם ותהליך השחזור

נניח RAID 5 עם ארבעה כוננים, ואחד מהם מת בשתיים בלילה. מה קורה? המערך עובר למצב "מנוון" (degraded). המערכת ממשיכה לעבוד — המשתמשים אולי לא ירגישו כלום — כי הבקר משחזר בזמן אמת כל בקשת קריאה לכונן שנפל, על ידי חישוב XOR מהכוננים ששרדו. זה בדיוק מה ש-RAID נועד לעשות: להחזיק את העסק באוויר תוך כדי הכשל.

כאן נכנס הכונן החם (Hot Spare). זהו כונן נוסף שיושב במערכת במצב המתנה, ללא תפקיד — עד שכונן חבר במערך נופל. אז הבקר מגייס אותו אוטומטית, בלי התערבות אדם, ומתחיל לבנות עליו מחדש את תוכן הכונן שכשל. בבקרי Dell PERC, למשל, אפשר להגדיר כונן חם "גלובלי" שישרת כל מערך יתיר בשרת, או "ייעודי" שמשויך למערך לוגי מסוים. חשוב לדעת שהכונן החם לא עובד לבד כברירת מחדל — צריך להקצות אותו במפורש; כונן פנוי שסתם יושב בשרת לא ייכנס אוטומטית לשחזור.

תהליך השחזור עצמו — ה-rebuild — הוא קריאה של כל המידע מכל הכוננים ששרדו, חישוב מחדש של מה שהיה על הכונן שנפל, וכתיבה של התוצאה לכונן החדש. וכאן מתחיל החלק שמעטים מדברים עליו.

חלון השחזור: הרגע המסוכן ביותר

ברגע שכונן נופל ב-RAID 5, המערך מאבד את כל היתירות שלו עד שהשחזור מסתיים. בחלון הזה — שיכול להימשך שעות ארוכות או ימים — למערך יש אפס עמידות בכשל נוסף. כשל של כונן שני, או אפילו שגיאת קריאה בלתי ניתנת לשחזור (URE) על סקטור בודד באחד הכוננים ששרדו, מספיקים כדי לאבד את כל המערך.

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

הבעיה הזו החמירה דרמטית עם גודל הכוננים, לא בגלל תכנון RAID אלא בגלל הקיבולת. שחזור כונן של 4TB עשוי לקחת יממה; שחזור של 20TB במהירויות טיפוסיות של NAS לעסק קטן — שבו קריאה וכתיבה של משתמשים ממשיכות במקביל — יכול להימשך כמה ימים, ובמהלכם המערך חשוף. ככל שנפח הקריאה הכולל גדל, כך גדל הסיכוי הסטטיסטי לפגוש URE במהלך השחזור. חשוב לסייג: קצב ה-URE הוא מפרט סטטיסטי של היצרן, לא סף מובטח — כונן עשוי לפגוש שגיאה הרבה לפני כן, או אף פעם לא. אבל הכיוון ברור, וזו בדיוק הסיבה ש-RAID 6 (שני כוננים כושלים) או RAID 10 הפכו להמלצה הרווחת לכוננים מכניים מעל 4TB: הם מספקים שכבת הגנה שנייה בדיוק בחלון הזה. ראוי לציין ש-SSD-ים עוקפים חלק גדול מהבעיה — קצב ה-URE שלהם טוב בסדרי גודל, מה שהופך RAID 5 על SSD לבטוח משמעותית מ-RAID 5 על כוננים מכניים גדולים.

[מיקום מומלץ לתמונה]
נושא התמונה: מסך ניהול מערך המציג תהליך rebuild בהתקדמות, עם אחוז השלמה ומצב "מנוון".
תיאור התמונה: ממשק בקר RAID עם פס התקדמות שחזור, להמחשת חלון הזמן שבו המערך חשוף.
טקסט ALT מוצע: מסך שחזור RAID בתהליך rebuild עם פס התקדמות — חלון החשיפה של המערך

הקאץ' הקריטי: RAID הוא לא גיבוי

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

מחיקה בטעות? RAID משכפל את המחיקה מיד לכל הכוננים, לפני שהספקת להבין מה קרה. כופר (ransomware)? כשהוא מצפין את המידע, RAID משכפל בנאמנות את הגרסה המוצפנת לכל הכוננים — ולמעשה מאיץ את הנזק. שחיתות מידע ברמת אפליקציה, שדרוג כושל, כשל של בקר ה-RAID עצמו (שהוא נקודת כשל יחידה שיכולה להפיל את כל המערך על אף שכל הכוננים תקינים), שריפה, הצפה או גניבה — מכל אלה RAID לא מגן. הכלל פשוט: RAID משכפל הכול, מיד, כולל את מה שלא רצית שישוכפל.

ההבחנה המדויקת: RAID נותן זמינות — הישארות באוויר דרך כשל חומרה. גיבוי נותן יכולת שחזור — חזרה לעותק נקי ומוקדם יותר אחרי שהמידע נמחק, נפגם או הוצפן. אלה שתי בעיות שונות, ופתרון אחד לא מחליף את השני. הסתמכות על RAID לבדו יוצרת תחושת ביטחון מדומה. עסק מוגן באמת מפעיל את שניהם: RAID לזמינות, ולצידו גיבוי אמיתי — רצוי לפי עיקרון 3-2-1 (שלושה עותקים, על שני סוגי מדיה, אחד מחוץ לאתר), עם עותק אחד מבודד או בלתי-משתנה (immutable) שכופר לא יכול להצפין.

מי צריך איזו רמה — ומי יכול לוותר

ההחלטה נגזרת משלוש שאלות: כמה ביצועים אתה צריך, כמה עמידות בכשל, וכמה קיבולת אתה מוכן להקריב תמורתן. לשרת קבצים או NAS עם כוננים מכניים גדולים בעסק קטן-בינוני — RAID 6 עם כונן חם הוא בדרך כלל האיזון הנכון, כי הוא מכסה את חלון השחזור המסוכן. לבסיס נתונים או ליישום שכותב הרבה ודורש ביצועים — RAID 10, למרות מחיר הקיבולת. RAID 5 עדיין הגיוני עם כוננים קטנים יחסית או עם מערכי SSD. RAID 0 כמעט אף פעם לא מתאים למידע ייצור. וזוג כוננים בודד במערכת קריטית — RAID 1 פשוט ואמין.

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

רוצים שמישהו יאפיין נכון את מערך האחסון שלכם — רמת RAID, כונן חם, וניטור שבאמת מתריע, לצד תוכנית גיבוי שמשלימה אותו? ל-MDS מחשבים כמעט 30 שנה של הקמת תשתיות אחסון לארגונים בישראל, ואנחנו מעבדת שירות מורשית Lenovo בצפון. נשמח לעבור אתכם על התצורה הקיימת או לתכנן חדשה שמתאימה לעומס ולסיכון האמיתי של העסק — לא יותר ולא פחות ממה שצריך. חייגו 04-8211416, כתבו ל-mds@mds.co.il, או קפצו לדרך השלום 9 בנשר.

שאלות ותשובות

אם יש לי RAID, אני עדיין צריך גיבוי?
כן, בהחלט. RAID מגן מפני כשל כונן בלבד. מחיקה בטעות, כופר, שחיתות מידע או כשל בקר — מכל אלה רק גיבוי נפרד (רצוי עם עותק מבודד מחוץ לאתר) יציל אותך.

מה ההבדל המעשי בין RAID 5 ל-RAID 6?
RAID 5 שורד כשל של כונן אחד; RAID 6 שורד כשל של שניים בו-זמנית. ההבדל קריטי דווקא בזמן השחזור, כשהמערך חשוף — לכן RAID 6 הפך להמלצה הרווחת לכוננים מכניים גדולים.

כמה זמן לוקח שחזור אחרי כשל כונן?
תלוי בגודל הכונן, בעומס ובבקר. שחזור של 4TB עשוי לקחת יממה; כונן של 20TB ב-NAS עסקי עמוס יכול להימשך כמה ימים — וכל אותו זמן המערך חשוף לכשל נוסף.

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