הגדרת דרייברי Kubernetes CSI: Ceph, NFS, EBS, GCE PD

למה דרייברים של CSI ב-Kubernetes מאטים תחת עומס

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

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

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

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

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

מה נותן אחסון מנוהל: השפעה על זמנים וכשלים

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

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

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

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

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

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

אפשרויות חיבור אחסון: השוואת גישות

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

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

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

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

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

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

חבילת מסירה: תצורות, תרשימים, נהלים

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

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

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

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

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

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

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

מה לעשות אם בקלאסטר Kubernetes כבר פרוס אחסון

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

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

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

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

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

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

ספקות טכניים: עמידות לתקלות, עותקים, תאימות

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

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

איך לוודא שהנתונים לא נפגמו אחרי תקלה?

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

האם זה תואם לקלאסטר הנוכחי?

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

אפשר לחזור לאחסון הקודם?

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

נדון במשימה: נתאים מצב אחסון לעומס

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

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

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