בקר RAID חומרתי: היכן אובדת אמינות הדיסקים
בקר RAID חומרתי נועד לשמש כרשת ביטחון: דיסק יוצא מכלל פעולה — המערך ממשיך לעבוד, השירות לא מבחין. בפועל, כשל דיסק בשרת הוא ממש לא התרחיש הנפוץ ביותר של השבתה. לעתים קרובות הרבה יותר התשתית נופלת במקום שבו הבקר מוגדר "כברירת מחדל" ואף אחד לא בדק מה בדיוק הוא עושה עם הנתונים.
הידרדרות מערך RAID מתפתחת מבלי שמבחינים בה. דיסק אחד נושר, המערך עובר למצב degraded, אבל השירות מגיב כרגיל — והאות נשאר ללא התייחסות. הכשל הבא, כבר בדיסק השני, הופך את ההידרדרות לאובדן נתונים: ה-rebuild לא מספיק בזמן, וחלון השחזור תלוי במדיניות ובעומס, ולא ברצון של התורן.
קטגוריה נפרדת היא שגיאות מטמון הבקר: write-back מופעל ללא הגנת מתח הופך כשל מתח לטרנזקציות שאבדו, וסוללה או קבל-על שאיבדו קיבולת משנים בשקט את התנהגות הכתיבה.
מדיניות הכתיבה של RAID — זה המקום שבו לרוב מתפצלות הציפיות והמציאות. בקר עם write-back מאיץ כתיבה, אבל דורש מטמון תקין; עם write-through בטוח יותר, אבל איטי יותר. אם המדיניות לא תואמה עם פרופיל העומס ולא נבדקה לאחר החלפת ציוד, השרת עלול לעבוד שנים במצב שאף אחד לא בחר בו במודע.
המחיר של הכשלים האלה — לא "חוסר יציבות" מופשט, אלא שעות השבתה ושחזור מגיבוי במקום שבו היה מספיק החלפה חמה של דיסק. לכן אמינות המערך נקבעת לא לפי דגם הבקר, אלא לפי האופן שבו מוגדרים המטמון, המדיניות והניטור. נפרט כיצד זה נסגר בפועל.
מה נותנת הגדרה נכונה של בקר RAID חומרתי
רמות RAID: בחירה לפי פרופיל עומס
רמת המערך קובעת גם את עמידות הכשל וגם את מחיר הדיסקים. RAID 10 סובל אובדן דיסק אחד בכל זוג מראה ומעניק גידול ליניארי בקריאה — מתאים לבסיסי נתונים ווירטואליזציה, שבהם חשובות פעולות כתיבה.
RAID 6 שורד כשל של שני דיסקים בו-זמנית, אך משלם על כך בכפילות זוגיות: הכתיבה איטית יותר, והבנייה מחדש לאחר החלפת דיסק נמשכת זמן רב יותר. RAID 5 על כוננים גדולים הוא כיום מסוכן: חלון הפגיעות בזמן השחזור נמדד בשעות, וכשל שני בתקופה זו מפיל את המערך.
מטמון עם סוללה ומדיניות כתיבה
מטמון הבקר עם סוללת גיבוי (BBU) — אינו אופציה, אלא תנאי לעבודה תקינה. עם סוללה תקינה, מדיניות הכתיבה עוברת למצב כתיבה דרך המטמון: האישור מגיע לאחר קיבוע בזיכרון מוגן, ולא על הדיסק. זה מסיר סוג של כשל שבו בעת הפסקת חשמל אובדים נתונים שכבר אושרו לאפליקציה. ללא סוללה הבקר נאלץ לעבוד במצב עקיפת מטמון — ביצועי הכתיבה צונחים פי כמה.
זמן שחזור המערך
מהירות הבנייה מחדש נקבעת על ידי עדיפות rebuild וגודל הדיסק. אם להגדיר את העדיפות למקסימום, המערך ייבנה מהר יותר, אך עומס העבודה יירד. פשרה סבירה — עדיפות דינמית: הבקר מקצה לבנייה מחדש רוחב פס פנוי ומפחית אותו בשיאים. בפועל זה מקצר את חלון הפגיעות משעות רבות ליחידות, בלי להפיל את השירות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| RAID 10 | בסיסי נתונים, וירטואליזציה, כתיבה אינטנסיבית | מחצית מהקיבולת הולכת למראות |
| RAID 6 | ארכיונים, מאגרי קבצים | כתיבה איטית, בנייה מחדש ארוכה |
| RAID 5 | רק דיסקים קטנים, נתונים לא קריטיים | סיכון לכשל שני בזמן שחזור |
| מטמון עם BBU | כל עומס עם כתיבה | יש להחליף סוללה לפי שחיקה |
הגדרה וניטור מצב המערך מתבצעים דרך MegaCli — הוא מספק את מצב הסוללה, התקדמות הבנייה מחדש ואירועי הבקר בצורה קריאה למכונה, מה שמאפשר לתפוס דעיכה לפני כשל.
כיצד אנו מגדירים בקר RAID: שלבי העבודה
הגדרת בקר RAID חומרתי היא לא "להפעיל מראה בקושחה", אלא רצף של החלטות, שכל אחת מהן קובעת בהמשך את התנהגות השרת תחת עומס ובמקרה של כשל בדיסק.
אנו מתחילים בביקורת של תצורת ה-RAID: בודקים אילו דיסקים מותקנים פיזית, כיצד הם מחוברים לבקר, במצב מה סוללת המטמון (BBU/CacheVault), אילו מערכים כבר נבנו וכיצד מחולקים הכרכים הלוגיים.
לעתים קרובות מתברר שחלק מהדיסקים פועלים במצב JBOD, המטמון מושבת בגלל סוללה שהתרוקנה, ורמת המערך נבחרה "בעין" — אלו הן הסיבות הנסתרות לירידות בביצועי פעולות הדיסק.
בהמשך מתכננים את סכימת המערך בהתאם למשימה: היכן נדרש RAID 10 לשם מהירות כתיבה, היכן מספיק RAID 6 לשם קיבולת, איזה גודל stripe להגדיר בהתאם לפרופיל העומס, האם להשאיר רזרבה חמה (hot spare) וכיצד להגדיר את מדיניות ה-rebuild. בנפרד אנו קובעים מה עושים עם המטמון: write-back עם הגנת סוללה או write-through, אם אין סוללה.
- ביקורת התצורה הנוכחית — מלאי של הדיסקים, הבקר, מצב סוללת המטמון, המערכים הקיימים ורמת הקושחה.
- תכנון סכימת המערך — בחירת רמת RAID, גודל ה-stripe, מדיניות המטמון וקיומה של רזרבה חמה בהתאם לעומס מסוים.
- הגדרת השרת — יצירת מערכים וכרכים לוגיים, חלוקה, העברת נתונים או התקנה נקייה.
- בדיקת RAID — בדיקה על סטנד: סימולציה של כשל בדיסק, מדידת מהירות ה-rebuild, בקרה שהמערך נבנה והנתונים אינם הולכים לאיבוד.
- בדיקת עומס — הרצת פרופיל פעולות אמיתי, כדי לוודא שהרמה והמטמון שנבחרו מספקים את הביצועים הנדרשים.
- מסירת תיעוד — סכימת המערכים, פרמטרי הבקר, סדר החלפת הדיסק והוראות לניטור המצב.
- תמיכה שוטפת — מגדירים התראות על דרדור המערך ומצב הסוללה, כדי שכשל בדיסק לא יהפוך להפתעה.
השלב המרכזי הוא בדיקת RAID על סטנד לפני הכניסה לשימוש. אנו שולפים בכוונה דיסק ובודקים כיצד המערך מתנהג: כמה זמן נמשך ה-rebuild, האם הביצועים צונחים לרמה בלתיacceptable, האם הרזרבה החמה פועלת כראוי. זה זול יותר מאשר לתפוס דרדור של המערך בפרודקשן ברגע הכי לא מתאים.
במה שונה RAID חומרתי מ-RAID תוכנתי?
RAID חומרתי הוא בקר נפרד עם מעבד משלו, מטמון ומודול סוללה, שלוקח על עצמו את פעולות הקלט/פלט ומעביר למערכת ההפעלה כרך לוגי מוכן. RAID תוכנתי נבנה באמצעי מערכת ההפעלה מדיסקים רגילים: חישוב זוגיות ושיקוף מבוצעים על ידי המעבד המרכזי, והמטמון הוא הזיכרון המערכתי. ההבדל מתבטא לא ב"מהירות הדיסקים", אלא במקום שבו בדיוק מתבזבז המשאב ומה קורה בעת כשל.
בכתיבה במערכים עם זוגיות, הבקר החומרתי מחזיק מטמון עם הגנת סוללה: האישור מגיע מהחוצץ הבלתי-נדיף, והנתונים נכתבים לדיסקים מאוחר יותר, במקבץ. מערך תוכנתי נאלץ либо להמתין לכתיבה פיזית, либо להשתמש ביומן משלו, וכל בלוק זוגיות מחושב על ידי ה-CPU.
בעומס משולב — בסיס נתונים, וירטואליזציה, אחסון קבצים — זה נראה בהשהיית התגובה ובכמה ליבות נשארות ליישום.
האמינות נקבעת לא על ידי "חומרתיות" כשלעצמה, אלא על ידי ההתנהגות בעת כשלים. הבקר יודע לבצע החלפה חמה, בנייה מחדש ברקע, patrol read והעברת מערך לשרת אחר כולו; מטמון עם סוללה שורד אובדן מתח ללא אובדן כתיבות מאושרות.
מערך תוכנתי תלוי ב-bootloader ובשלמות מערכת ההפעלה: אם המערכת לא עלתה, קשה יותר להרכיב ולבדוק את המערך, והשחזור דורש עבודה ידנית עם כלי עזר.
RAID תוכנתי אינו "רע" — הוא מספיק במקומות שבהם העומס סדרתי ודרישות ההשהיה רכות: שרת קבצים מחלקתי, אחסון גיבוי, סביבת פיתוח. הוא אינו דורש כרטיס נפרד, עובר יחד עם הדיסקים בין מכונות מאותו סוג ושקוף לניטור.
השוואת RAID במקרה זה מצטמצמת למחיר הכשל: אם השבתה בזמן בנייה מחדש מקובלת, ויש ליבות מעבד עם עודף — מערך תוכנתי סוגר את המשימה.
הבחירה נקבעת על ידי שלוש שאלות: איזה חלק מהפעולות הוא כתיבה, האם יש דרישות להשהיית תגובה, ומה יקרה בעת כשל של השרת כולו. התשובות לשאלות אלו הן הגבול בין RAID חומרתי ל-RAID תוכנתי — ומכאן זה כבר עניין של תצורה מסוימת.
מקרה בוחן: שחזור מערך לאחר כשל בבקר
שרת באתר הלקוח פעל מספר שנים ללא תקלות, עד שהבקר החל לאבד דיסק אחד אחרי השני: תחילה המערך עבר למצב מנוון, ולאחר מכן הקושחה הפסיקה להגיב לבקשות שירות.
פורמלית הנתונים היו במקומם, אך כל אתחול מחדש мог להסתיים בסט דיסקים בלתי קריא — ועל צומת זה החזיקו שירות קבצים ומסד נתונים חשבונאי.
מה היה לפני ההתערבות
מערך של שישה דיסקים בתצורה עם זוגיות, כונן אחד במצב כשל, והשני — עם מספר גדל והולך של סקטורים שהוקצו מחדש. גיבוי נלקח פעם ביום, חלון השחזור ממנו — כשמונה שעות, וזאת מבלי לקחת בחשבון השוואה ידנית. הבקר עצמו כבר לא אפשר לייצא את תצורת המערך: כלי השירות ראה אותו כמכשיר בלתי מזוהה.
מה עשינו
בשלב הראשון נלקח דימוי מלא של כל דיסק לכוננים נפרדים — כדי שכל פעולה עתידית תתבצע על עותקים, ולא על המקוריים. לאחר מכן הועברו המטא-נתונים של המערך: סדר הדיסקים, גודל הפס, סוג הזוגיות וההיסט של אזור השירות שוחזרו מתוך יומני הבקר והסימונים על הכוננים עצמם. הבקר החדש קיבל את התצורה, המערך הורכב במצב שחזור, והזוגיות חושבה מחדש על הדיסק המוחלף.
מה היה בסוף
| מדד | לפני | אחרי |
|---|---|---|
| זמינות השירות | השבתה עקב הכשל | חלון מתוכנן להחלפה |
| זמן שחזור | כשמונה שעות מהעותק | חישוב מחדש של הזוגיות ללא עצירת השירות |
| שלמות הנתונים | בספק בכל אתחול מחדש | אושרה בבדיקת סכומי ביקורת |
| מרווח כשלים | דיסק אחד | סט מלא של תקינים |
בנפרד הוגדר ניטור מצב הכוננים והבקר: סקירה כל כמה דקות, התראה כבר בסקטורים הראשונים שהוקצו מחדש, ולא כאשר הדיסק כבר נפל. זהו סוג המשימות שבו MegaRAID ופלטפורמות דומות מספקות יומן אירועים הניתן לייצוא — דווקא לפיו הצלחנו לשחזר את תצורת המערך המקורית, ולא להרכיב אותה מחדש מאפס.
תאימות, מיגרציה וחזרה לאחור: מה מבררים לפני ההתחלה
לפני ההתחלה תמיד בודקים שלושה דברים: תאימות RAID לחומרה הנוכחית, תרחיש מיגרציית הנתונים ותוכנית חזרה לאחור.
בפועל, לרוב עולה אי-תאימות של קושחת הבקר עם לוח האם או ה-backplane — בקר RAID חומרתי שמתאים לכאורה מסרב לאתחל את הדיסקים, והשרת נכנס להשבתה בשלב שבו הנתונים כבר הועברו חלקית. לכן בודקים תאימות RAID לפי מטריצת היצרן לפני הרכישה, ולא אחריה.
מיגרציה של נתונים היא מקור הסיכון השני. אם המערך כבר נבנה על פתרון תוכנה או על בקר של יצרן אחר, העברה ישירה של הדיסקים לא תעבוד: המטא-נתונים אינם תואמים.
אז בונים תוכנית דרך אחסון ביניים — יוצרים תמונת מצב, בונים מערך חדש, מחזירים את הנתונים ומשווים ערכי בדיקה (checksums) לכל כרך.
מה אם אחרי המעבר למערך החדש משהו ישתבש?
את תוכנית החזרה לאחור מתעדים בכתב לפני תחילת העבודה: שומרים את תצורת הבקר המקורית, לא מפרקים את המערך הישן עד לאימות מוכח של הנתונים על החדש, ומשאירים אמצעי אתחול עם המחיצות הקודמות. החזרה לאחור אורכת דקות — מחזירים את האתחול חזרה, והמערך עולה במצבו המקורי.
מה עם הגישות לשרת? יש צורך בפרטי התחברות לבקר, גישה לקונסולת הניהול וגישה פיזית לארון, אם יידרש החלפת סוללה או חיבור מחדש של כבלים. בלי זה לא ניתן לבצע חלק מהפעולות מרחוק.
מה ייכלל בתיעוד ה-RAID? תרשים המערך עם הרמות ופריסת הדיסקים, פרמטרי הבקר, סדר החלפת כונן שכשל והוראות שחזור לאחר תקלה — כדי שהצוות שלכם יוכל לפעול בלעדינו.
בסיום אתם מקבלים:
- תרשים המערך שנבנה עם הרמות ו-hot-spare;
- תצורת הבקר בפורמט הניתן לייצוא;
- תוכנית חזרה לאחור עם פקודות שלב-אחר-שלב;
- נוהל החלפת דיסק ובנייה מחדש של המערך;
- רשימת בדיקה לאחר המסירה;
- מטריצת תאימות לחומרה שלכם;
- יומן מיגרציה עם ערכי בדיקה.
תארו את המשימה — החומרה הנוכחית, נפח הנתונים, דרישות הזמינות. נחזור עם הערכה ותוכנית עבודה.