Ceph RGW: מדוע אחסון S3 ארגוני מדרדר
תרחיש קלאסי: אשכול Ceph RGW פועל, אחסון תואם S3 מחזיר אובייקטים, וכעבור מספר שבועות זמני ההשהיה של פעולות קריאה וכתיבה גדלים פי כמה.
הסיבה כמעט תמיד אינה ב"חומרה", אלא באופן שבו הנתונים מפוזרים והמאגרים (pools) מוגדרים: חלק מהצמתים עמוסים עד הקצה, חלקם אינם מנוצלים, והלקוחות מתלוננים על פסקי זמן בעת העלאת גיבויים ולוגים.
הדרדרות של שער האובייקטים (object gateway) לעיתים רחוקות מגיעה בפתאומיות — היא מצטברת.
חוסר איזון של נתונים בין הצמתים נוצר בגלל מספר placement groups לא מוצלח ומשקולות התקנים שהוגדרו "בעין"; בעת הוספת דיסקים חדשים זה רק מחמיר, מכיוון שהחלוקה מחדש מתבצעת לאט ומתחרה על קלט-פלט דיסק עם בקשות העבודה.
סיפור נפרד הוא ביטול מפתחות גישה: אם המדיניות וחשבונות המשתמש נוצרים ידנית, רוטציית מפתחות הופכת להשבתה של שירותים שעדיין פועלים עם פרטי גישה ישנים.
כשל טיפוסי נוסף — מצב אינדוקס דליים וגדלי אובייקטים שנבחרו באופן שגוי. אובייקטים קטנים פוגעים במספר הפעולות, גדולים — בתפוקה (throughput), ובלי הפרדת מאגרים לנתונים ולאינדקס השער מתחיל "להיחנק" דווקא בשיאי העומס. לכך מתווסף גם היעדר מגבלות על דליים: שירות אחד עם כתיבה אגרסיבית דוחק את האחרים.
אנו מפרקים כיצד זה נסגר: פריסת placement groups ומשקולות צמתים, מאגרים נפרדים לנתונים ולאינדקסים, מדיניות מחזור חיים ורוטציית מפתחות גישה מנוהלת.
מה נותן Ceph RGW מוגדר: מצבים ואפקט
Ceph RGW מוגדר מפסיק להיות "עוד S3" והופך לשכבת אחסון מנוהלת עם מאפיינים צפויים. להלן — מה בדיוק משתנה ובאילו מספרים זה נראה.
מצבי הצבת אובייקטים
הבחירה בין שכפול ל-erasure coding קובעת גם את עלות האחסון וגם את פרופיל ההשהיות. שכפול עם שלוש עותקים נותן תגובה לקריאה במילישניות בודדות וחזרה מיידית, אך תופס פי שלושה יותר מקום.
Erasure coding עם פרופיל k+m מפחית את עלויות הנלוות של האחסון פי כמה, אולם מוסיף השהיה לשחזור מקטעים. בפועל, דליים חמים מוחזקים על שכפול, וארכיון — על מאגרי erasure.
מדיניות גישה
מדיניות ברמת הדלי והקידומת מסירה ניהול ידני של הרשאות. במקום הנפקת מפתחות "לכולם" מוגדרות תפקידים עם הגבלה לפי פעולות ותקופות חיים — שיעור התקריות בגלל הרשאות עודפות יורד, וסבב מפתחות הופך לפעולה מתוכננת ולא לבהלה.
עמידות לתקלות ומחלקת כשל
כאשר כלל CRUSH מוגדר כראוי, יציאת צומת מכלל פעולה אינה מביאה לירידת ביצועי קריאה: הנתונים מופצים מחדש על הדיסקים הנותרים מבלי לעצור את השירות. זה מבטל מחלקת כשל שלמה — "שרת אחד נפל, האחסון קרס" — ומקצר את זמן השחזור לריבאלנס ברקע.
זמן תגובה
מטמון מטא-נתונים והעברת אינדקס הדליים למדיה מהירה מקצרים את זמן התגובה לרישום ולפעולות עם אובייקטים פי כמה בעומס מקבילי גבוה. פעולות ידניות — העברת דליים, עריכת מדיניות, ניקוי — עוברות לקונפיגורציות דקלרטיביות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| שכפול 3x | נתונים חמים, השהיה נמוכה | צריכת מקום גבוהה |
| Erasure coding | ארכיונים, נפחים גדולים | השהיה לשחזור |
| היברידי לפי מאגרים | עומס מעורב | הגדרת כללים מורכבת יותר |
Ceph
כיצד אנו מיישמים Ceph RGW: שלבי עבודה הנדסית
יישום Ceph RGW אינו מתחיל בהתקנת חבילות, אלא בביקורת תשתית: בוחנים את מאגרי הדיסקים הקיימים, את טופולוגיית הרשתות, את נקודות הכשל הנוכחיות ואת פרופיל העומס — כמה פעולות בשנייה, מה גודל האובייקטים, מה שיעור הקבצים הקטנים לעומת הגדולים.
מכך נגזרת סכמת הפריסה: מספר צמתי האחסון, פריסת היומנים, גודל המאגרים ומדיניות השכפול בין אזורי זמינות. את השער מגדירים מעל אשכול קיים, כדי לא לבנות מחדש את מערכת האחסון לאחר העלייה לאוויר.
- ביקורת תשתית. אוספים מפה של שרתים, רשתות ומערכות אחסון, מודדים את העומס הנוכחי ואת נקודות הצמיחה. התוצר — הבנה כמה צמתים נדרשים והיכן צווארי הבקבוק.
- סכמת פריסה. מתכננים את טופולוגיית האשכול והמאגרים, קובעים מדיניות שכפול וכללי פריסת נתונים בין אזורי כשל.
- הכנת צמתים. פורסים את צמתי האחסון, מגדירים רשת אחסון בנפרד מרשת הלקוחות, בודקים סנכרון זמן ויומני דיסקים.
- הגדרת השער. מרימים את RGW, יוצרים משתמשים ומפתחות גישה, מגדירים דליי אחסון, מכסות ומדיניות מחזור חיים של אובייקטים.
- בדיקת עמידות בכשלים. מדמים כשל של צומת ושל דיסק, בודקים שחזור נתונים והתנהגות השער תחת עומס — איזון עומסים, מגבלות חיבורים, מטמון.
- חיבור לקוחות. מעבירים את היישומים לגישה תואמת S3, בודקים תאימות עם הכלים הקיימים ומעבירים את הנתונים.
- מסירת תיעוד. מוסרים סכמות, קונפיגורציות, נהלי תחזוקה ומקיימים הדרכה לצוות הלקוח.
כל שלב מסתיים בתוצאה ניתנת לבדיקה, ולא בדוח. לאחר המסירה נשארים לצוות קונפיגורציות עובדות, סכמת פריסה ונוהל שחזור — התחזוקה והפיתוח של מערכת האחסון אינם תלויים בנו. תארו את המשימה — נחזור עם הערכה ותוכנית עבור התצורה שלכם.
במה שונה Ceph RGW משער S3 קלאסי?
שער S3 קלאסי הוא חזית מעל אחסון קיים: הוא מקבל בקשות S3 ומפזר אובייקטים בין כרכים שהוקצו מראש או מערך. Ceph RGW בנוי אחרת: שירות ה-S3 עצמו הוא רק אחד מהממשקים לאחסון מבוזר אחיד, שבו הנתונים, המטא-נתונים והמיקום שלהם מנוהלים על ידי האשכול כיחידה אחת. מכאן גם ההבדל בהתנהגות תחת עומס.
בסכמה ריכוזית, הסקיילינג הולך "כלפי מעלה": מוסיפים דיסקים למערך, מרחיבים כרכים, מעבירים נתונים. כל צעד כזה הוא עצירה מתוכננת או מיגרציה, והתקרה נקבעת על ידי הבקר ורוחב הפס של צומת אחת.
באחסון מבוזר, הקיבולת ותפוקת ההעברה גדלות "לרוחב": צומת חדשה מוכנסת לאשכול, והנתונים מופצים מחדש אוטומטית על פניה ללא השבתה. כשל של דיסק או צומת אינו מפיל את השירות — העתקים וקודי יתירות כבר נמצאים על צמתים אחרים, והשחזור מתבצע ברקע.
דווקא ארכיטקטורת האחסון קובעת את עלות הבעלות. הגישה הריכוזית דורשת מדפי דיסקים יקרים ורזרבה לשיא, שעומדת ללא שימוש בימים רגילים.
אחסון מבוזר נבנה משרתים סטנדרטיים, והיתירות נקבעת על ידי מדיניות: לנתונים חמים — מספר העתקים, לארכיוניים — קודי יתירות שנותנים אותה רמת עמידות בפני כשלים בנפח קטן יותר. הוצאות האחסון מפסיקות לגדול באופן לינארי יחד עם הנתונים.
עבור האפליקציות אין הבדל בפרוטוקול: אותו S3 API, אותם מפתחות גישה, אותן מדיניות. מה שמשתנה הוא ההתנהגות תחת כשלים ומחיר הצמיחה. שער ריכוזי נתקל בתקרת הצומת ודורש הפצה מחדש ידנית; Ceph RGW מתרחב על ידי הוספת צמתים ושורד כשל חומרה ללא התערבות ידנית.
לכן הבחירה אינה בשאלה "איזה S3 נוח יותר", אלא בשאלה אם אתם מוכנים לתקרת סקיילינג ולמיגרציות ידניות או רוצים לצמוח באופן צפוי.
מקרה בוחן: כיצד תיקנו חוסר איזון בנתונים ב-Ceph RGW
צוות פנה אלינו עם אשכול Ceph RGW שעבד, אך הנתונים התפרסו בצורה לא אחידה: שניים מתוך שישה צמתים החזיקו כמעט מחצית מהאובייקטים, והשאר עמדו ללא שימוש. כל עוד העומס גדל, הדבר לא בלט לעין — אך כאשר צומת עמוס נכשל, השחזור נמשך שעות, וחלק מהבקשות ל-buckets נכשלו עקב חריגה מזמן ההמתנה.
מה הראו המדדים לפני
לקחנו את המצב דרך ceph osd df tree ו-radosgw-admin bucket stats: פיזור מילוי הדיסקים בין הצמתים הגיע עד 40%, ומספר קבוצות המיקום על הדיסקים differed פי כמה.
הסיבה התבררה כמשולבת — ה-pool נוצר עם מספר קטן של קבוצות מיקום, ומשקולות הדיסקים במפת CRUSH נותרו בברירת מחדל, אף שקיבולת הצמתים הייתה שונה.
מה שינינו
בנינו מחדש את מפת CRUSH עם משקולות אמיתיות בהתאם לקיבולת של כל דיסק, וחילקנו מחדש את קבוצות המיקום. עבור ה-buckets הפעלנו שרדינג של האינדקס, כדי שהעומס על המטא-נתונים לא יידבק לצומת אחד.
בנפרד הגדרנו מדיניות שחזור: הגבלנו את קצב המילוי החוזר, כדי שה-rebuild לא יאכל את כל רוחב הפס של בקשות העבודה.
מה השתנה
| מדד | לפני | אחרי |
|---|---|---|
| פיזור מילוי הצמתים | עד 40% | בטווח של 5% |
| שחזור לאחר כשל צומת | שעות | עשרות דקות |
| יציבות התגובה תחת עומס | ירידות | גרף אחיד |
הפיזור התאזן, כשל של צומת הפסיק להיות אירוע של חצי יום, והתגובה הפסיקה "לנשום" בשיאים. עבדנו על Ceph — אחסון אובייקטים מבוזר, שבו אחידות הפריסה קובעת ישירות גם את מהירות השחזור וגם את צפיות התגובה.
אם ה-RGW שלכם כבר בפרודקשן ויש חשד לחוסר איזון — הציגו את הפלט של ceph osd df tree, נדון במשימה ונחזור עם תוכנית איזון.
ספקות לפני הטמעת Ceph RGW: תאימות וחזרה לאחור
התאימות ליישומים קיימים נסגרת ברמת S3 API: לקוחות שעובדים עם S3 מתחברים ל-RGW ללא שינויים בקוד — די להחליף את ה-endpoint ומפתחות הגישה.
עבור יישומי legacy שיודעים לעבוד רק עם פרוטוקולי קבצים, אנו מקימים שער NFS או SMB מעל אותו אחסון, ומפרידים הרשאות גישה באמצעות מדיניות דלי (bucket policies) ותפקידים, כך שהיישום רואה בדיוק את הקידומת (prefix) שלו.
העברת הנתונים מתבצעת ללא עצירת השירות: אנו מפעילים שכפול (replication) בין האחסון הישן לחדש, מעתיקים אובייקטים במנות, מאמתים סכומי בקרה (checksums), ורק לאחר שהפער מתאפס אנו מעבירים את התעבורה.
חזרה לאחור מתוכננת מראש — תצורת RGW וכללי הניתוב נשמרים במערכת בקרת גרסאות, ולכן החזרה למצב הקודם מתבצעת בפעולה אחת, והמתאר הישן נשאר פעיל עד לאישור היציבות.
מה יקרה אם לאחר ההעברה תתגלה בעיה בגישה?
הרשאות הגישה והמדיניות מנוהלות בגרסאות יחד עם התצורה, ולכן החזרה לאחור מחזירה גם את ההרשאות וגם את הניתוב למצב הקודם. את האחסון הישן אנו מחזיקים במצב קריאה בלבד עד שנוודא שכל הלקוחות פועלים כשורה — חלון זה הוא הביטוח מפני הפתעות.
מה אם היישום משתמש בהרחבות S3 לא סטנדרטיות? אנו מריצים את התרחישים שלו על מתאר בדיקה לפני ההעברה ומתעדים רשימת קריאות לא תואמות — בדרך כלל סוגרים אותן באמצעות הגדרה או שכבת ביניים דקה.
כיצד להתמודד עם נפח נתונים גדול? ההעתקה מתבצעת בזרמים מקבילים עם הגבלת עומס על הערוץ, ולכן ההעברה אינה מפריעה לתעבורה השוטפת.
בסיום הלקוח מקבל:
- תצורות מוכנות של RGW ושערי גישה;
- תרשים פריסה ושכפול נתונים;
- מדיניות הרשאות ותפקידים ליישומים;
- תוכנית העברה עם שלבים ונקודות חזרה לאחור;
- הוראות תפעול ופעולות שגרתיות;
- תיעוד לניטור ותגובה לתקלות.
תארו את המשימה שלכם ואת מתאר האחסון הנוכחי — נחזור עם הערכת תאימות ותוכנית מעבר.
לוחות זמנים להטמעת Ceph RGW: שלבים ואבני דרך
לוחות הזמנים אינם תלויים בנפח החומרה, אלא במספר האינטגרציות: ככל שיש יותר צרכני S3 ומעגלים חיצוניים, כך ארוכים יותר התיאומים והבדיקות. להלן אבני דרך לאשכול בקנה מידה בינוני, הנפרס מאפס תחת עומס ארגוני.
השלבים מתבצעים בחפיפה חלקית: התכנון מתחיל לפני סיום הסקר, והכנת ההעברה — במקביל להגדרת RGW. לכן סכום שורות הטבלה אינו שווה לתקופה הקלנדרית של הפרויקט.
את משך הזמן מאריכים ביותר ההעברה והתיאומים בצד הצרכנים: העברת יישומים לנקודת קצה חדשה מחייבת את השתתפותם וחלון תחזוקה. אם הנתונים מועטים או שהאחסון נבנה מאפס ללא העברה, התקופה הכוללת מתקצרת בכמחצית.
אבני הדרך מתחדדות לאחר הסקר — לפי מספר הצרכנים בפועל, נפח הנתונים ודרישות לזמינות. תארו את המשימה: נחזור עם הערכה ותוכנית המותאמת למעגל שלכם.
תאימות Ceph RGW לתשתית קיימת
Ceph RGW מממש ממשקים תואמי S3 ו-Swift, ולכן שכבת היישומים בדרך כלל אינה דורשת כתיבה מחדש: יישומים שעובדים עם S3 דרך ספריות סטנדרטיות מתחברים ל-RGW באמצעות החלפת endpoint ומפתחות גישה. להלן — עם מה האינטגרציה עוברת ללא התאמות, והיכן יש לקבוע מגבלות בשלב הפריסה.
אינטגרציה עם האחסון הנוכחי. אם בתשתית כבר פרוס Ceph, RGW עולה כשירות נפרד מעל המאגרים הקיימים — הנתונים וה-OSD אינם נבנים מחדש. עבור סביבות ללא Ceph, הפריסה מתחילה מהאשכול, וזהו שלב נפרד עם תכנון עמידות לתקלות.
מגבלות בעת הפריסה. RGW רגיש להשהיות בין השער לאשכול: בעת הצבה באתרים שונים ללא מטמון מקומי זמן התגובה גדל. מאזן עומסים לפני השערים הכרחי לפיזור העומס, וסיום TLS מוגדר בנפרד. שכפול multi-site דורש תצורה עקבית של אזורים ואינו סובל אי-התאמות בהגדרות.
Ceph — בודקים תאימות על סטנד שעושה שימוש חוזר בסביבה שלכם, לפני העברת נתוני העבודה.