מדיניות ILM של Elasticsearch: hot-warm-cold ומחיקה

Elasticsearch ILM לא מוגדר: מה נשבר בקלאסטר

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

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

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

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

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

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

אחרי הטמעת ILM הקלאסטר מפסיק להיות מזבלה אחידה של אינדקסים. נתונים טריים נכתבים לשכבת ה-hot עם דיסקים מהירים, אחרי שלב ה-rollover Elasticsearch מעביר אותם ל-warm, ואחר כך ל-cold — עם אריזה צפופה של סגמנטים.

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

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

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

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

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

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

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

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

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

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

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

החבילה בסיום: מדיניות, תבניות, נהלים

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

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

מקרה בוחן: איך פרקנו עומס מהקלאסטר והקטנו את נפח האחסון

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

מה היה לפני

הניתוח הראה: אינדקסי Elasticsearch נכתבו לפי ימים בלי מעבר בין שלבים, כל השארדים חיו על צמתי hot, והרפליקה תפסה מקום כמו השארד הראשי. rollover לא היה: את הישנים מחק התורן ידנית, ומיזוג סגמנטים הופעל רק אחרי תקלה, כשהחיפוש הידרדר. זמן החיפוש על 90 יום — עד 8 שניות, חלק הנתונים בשכבת ה-cold — אפס, התערבויות ידניות — 9–12 בחודש.

מה עשינו

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

מטריקות אחרי

• זמן חיפוש על 90 יום: 8 שניות → 600–800 מ"ש.
• חלק הנתונים בשכבת ה-cold: 0 → 71% מהנפח.
• נפח האחסון: דחיסה בתוספת מחיקה לפי גיל קיצרו פי שלושה, צמיחת המרשם נעצרה.
• התערבויות ידניות של התורן: 9–12 → 0 בחודש.

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

במה שונה Elasticsearch ILM ממחיקה ידנית של אינדקסים?

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

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

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

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

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

שאלות טכניות נפוצות על מדיניות מחזור חיים

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

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

מה לעשות אם המחיקה כבר פעלה?

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

עד כמה החיפוש איטי יותר בשכבת ה-cold?

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

האם נדרשות שכבות בקלאסטר קטן?

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

איך בוחרים תקופות שמירה?

מהתוספת היומית ומהדרישות לנתונים: מחשבים את הנפח ליום, כופלים בתקופה ומשווים למקום הפנוי. את התקופות קובעים לפי שלבים — חלק ה-hot קצר יותר, ה-warm וה-cold ארוכים יותר, ומחיקה בסוף.

נדון במשימה: איך להגדיר מחזור חיים לזרימת הנתונים שלכם

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

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

מה כדאי לשלוח כדי שהאומדן יהיה ענייני:

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

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

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