ניהול אשכולות Elasticsearch ו-OpenSearch

ניהול Elasticsearch: היכן האשכול נשבר

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

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

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

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

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

מה נותן ניהול Elasticsearch בפועל

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

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

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

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

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

מצבי פריסה: אשכול עצמאי, ענן או היברידי

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

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

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

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

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

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

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

מדיניות גישה, סכמות אינדקסים ותיעוד

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

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

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

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

מה היה

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

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

מה עשינו

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

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

מה נהיה

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

מה לעשות אם האשכול כבר פרוס ואף אחד לא מתחזק אותו

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

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

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

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

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

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

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

ספקות טכניים: עונים לגופו של עניין

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

כיצד מופרדות הרשאות הגישה?

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

נוכל לתחזק את האשכול בעצמנו לאחר המסירה?

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

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

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

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

השיחה עצמה אורכת 40–60 דקות ומסתיימת לא במצגת, אלא בקונקרטיקה:

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

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

תארו את המשימה בשתיים-שלוש פסקאות או שלחו את מה שכבר יש על האשכול — נחזור עם הערכה ותוכנית.