הגדרת Btrfs לאחסון נתונים: תמונות מצב, RAID ושכפול

הגדרת Btrfs: היכן נשבר האחסון ומה בודקים

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

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

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

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

מה נותן אחסון מנוהל: תמונות מצב, שלמות, רפליקות

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

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

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

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

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

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

תמונות מצב, RAID ורפליקציה: השוואת גישות

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

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

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

כיצד עוברת הגדרת Btrfs: שלבי העבודה

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

1. ביקורת אחסון. פריסה נוכחית, מצב אמצעי האחסון, היסטוריית התמלאות, פרופיל קלט/פלט יומי. נראה מה ישרוד דרדור של דיסק ומה דורש שיקוף.
2. סכימת פריסה. מפזרים נתונים, יומנים, גיבויים ונקודות שחזור בין תת-כרכים, כך שתמונת מצב של מערך אחד לא תגרור את האחרים. פרופילים של נתונים ומטא-נתונים בוחרים בנפרד.
3. פריסה ומצבי טעינה. יוצרים מערכת קבצים, מפעילים דחיסה שקופה ובקרת שלמות, ואת אפשרויות הטעינה מתאימים לעומס.
4. תמונות מצב ולוח זמנים. תמונות אוטומטיות לפי טיימר עם מדיניות שמירה: כמה עותקים מחזיקים, מה עובר לארכיון, מה נמחק לפי מונה ולא לפי תאריך.
5. רפליקציה. העברה אינקרמנטלית של תת-כרכים לצומת שנייה עם בדיקת סיכומי ביקורת בצד המקבל והתנהגות ברורה בעת ניתוק ערוץ.
6. בדיקת תרחישי כשל. מריצים כשל של אמצעי אחסון, חוסר מקום, בלוק פגום ושחזור מתמונת מצב. בנפרד בודקים scrub של המערך.
7. מסירה לתפעול. סכימת פריסה, לוחות זמנים, אפשרויות טעינה וסדר שחזור. צוות התורנות לומד לקרוא את מצב האחסון לפני שמגיעה התראה.

תצורות, סכימות ונהלים: מה נשאר אצלכם

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

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

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

מקרה בוחן: שיעור הכשלים וזמן השחזור לפני ואחרי

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

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

מדדים לפני ואחרי: שיעור הכשלים שהביאו להשבתה — מ-40% לאפס בתקופת התצפית; זמן החזרת עדכון — מ-3–4 שעות עבודה ידנית לכמה דקות להחזרת תמונת מצב; שיעור השחזורים ללא אובדן נתונים — מ-60% ל-100%. בנפרד נעלם סוג של פגיעה «שקטה» בבלוקים: סיכומי ביקורת תופסים אותה בקריאה, ולא לפי תלונות משתמשים.

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

במה תמונת מצב שונה מרפליקה ומתי נדרש RAID

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

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

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

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

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

ספקות טכניים נפוצים לפני הטמעה

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

מה יקרה בעת כשל דיסק?

ב-RAID1 או RAID10 המערך ממשיך לעבוד במצב מדורדר, הכתיבה לא נעצרת, בלוקים פגומים מסומנים בסיכומי ביקורת. החלפת אמצעי האחסון והשחזור מתבצעים באופן מקוון. תבניות RAID5/6 לעומס כתיבה פעיל אינן מתוכננות.

בכמה יגדל נפח תמונות המצב?

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

כיצד נבדקת שלמות הנתונים?

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

כמה זמן תופסות העבודות?

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

נדון במשימה: תוכנית עבודה והערכה לפי הסכימה שלכם

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

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

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

תארו את המשימה וצרפו את מה שיש בהישג יד — נחזור עם הערכה ותוכנית.