הגדרת מכסות דיסק למשתמשים בשרת Linux

מכסות דיסק: כיצד תהליך אחד ממלא את השרת

מכסות דיסק הן לא «היגיינה», אלא הגנה מפני סוג מסוים של תקלות.

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

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

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

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

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

מה נותן הגבלת מקום: השפעות מדידות

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

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

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

אפשרויות מכסות דיסק: השוואת מצבים וגבולות

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

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

סדר ההטמעה: מביקורת ועד מסירת הנהלים

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

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

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

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

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

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

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

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

מה מקבלים בסוף: קונפיגורציות, תרשימים ונהלים

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

• קונפיגורציות מכסות: אפשרויות ה-mount usrquota, grpquota או prjquota, ערכי המגבלה הרכה והקשיחה, סף נפרד לפי inodes — כקטעים מוכנים לקבצי ההגדרות שלכם.
• תרשים פריסת הנתונים: מה הועבר לכרך נפרד, היכן תיקיות הבית, היכן קבצים זמניים של בנייה ולוגים, איזו מגבלה חלה על כל מחיצה.
• טבלת מגבלות לפי תפקידים וקבוצות: כמה הוקצה למפתחים, לחשבונות שירות, לסוכני בנייה ולמאגר הגיבויים — ובמה מנומק כל סף.
• נהלי תחזוקה: באיזו תדירות מופק דוח התפוסה, כיצד מתואם שינוי המגבלה, ובאיזה שיעור מילוי של הכרך מופעלת ההרחבה.
• הוראות לתורנוֹנים: טיפול צעד אחר צעד ב«נגמר המקום במחיצה» — כיצד לאתר תוך דקות את הצרכן, להעלות זמנית את הסף ולהחזיר את הערך חזרה.
• דוח תפוסה: ייצוא לפי משתמשים וקבוצות עם דירוג הצרכנים והדינמיקה, באותו סקריפט שפועל לפי לוח זמנים.
• ערכת סקריפטים ומשימות: הפעלת מכסות, הפקת דוח, התראה בחריגה מהסף הרך — במערכת בקרת גרסאות, עם היסטוריית שינויים.
• סדר נסיגה לאחור: כיצד להסיר את המגבלות בלי לאבד נתונים ומה לבדוק ביומנים אם לאחר הפעלת המכסות השירות לא עלה.

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

מקרה בוחן: כיצד עצרנו גידול בלתי מבוקר של המחיצה

באחד הפרויקטים עם בק-אנד בעומס גבוה, מחיצת השורש ו-/var עברו בקביעות את ה-90%: לוגים של אפליקציות לא עברו רוטציה, תיקיות הבנייה הצטברו ארטיפקטים, ועותקי דיבאג של בסיסי נתונים שקעו ב-/tmp.

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

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

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

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

מה לעשות אם המחיצה כבר מלאה והשירותים לא עולים

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

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

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

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

ספקות טכניים לפני תחילת העבודה

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

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

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

האם זה תואם לגיבוי?

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

מה עם שירותי מערכת וחריגים?

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

אפשר לסגת לאחור אם המדיניות מפריעה לעבודה?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

מה כדאי לספר או לשלוח:

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

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