הגדרת אחסון מבוזר (Ceph/GlusterFS) לאשכולות

מדוע אחסון מבוזר Ceph מאבד מהירות ונתונים

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

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

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

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

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

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

מה נותן אחסון מכויל: מהירות ועמידות בתקלות

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

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

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

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

אפשרויות פריסת נתונים: רפליקציה, קודי יתירות, היברידי

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

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

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

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

סדר העבודות: ביקורת אשכול, סכימה, כיול, בדיקה, מסירה

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

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

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

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

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

מקרה בוחן: כיצד האשכול יצא מדגרדציה בזמן גידול בעומס

מצב פתיחה

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

מה שינו בסכימת הפריסה ובכללי השחזור

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

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

במה Ceph שונה מאחסון רשת קלאסי

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

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

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

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

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

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

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

אפשר לעבור בלי לעצור שירותים?

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

האם זה יתאים לציוד הקיים?

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

איך לעקוב אחרי המצב והאם צריך גיבויים?

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

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

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

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

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

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