אשכול Elasticsearch 200 TB+

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

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

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

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

דרישות

דרישות המערכת נוסחו כך:

• Graylog היה אמור לשמש כ-frontend. מכיוון שלחברה כבר היה ניסיון בשימוש במוצר זה, המתכנתים והבודקים ידעו זאת, הוא היה מוכר ונוח להם.
• נפח נתונים: בממוצע 50-80 אלף הודעות בשנייה, אבל אם משהו נשבר, אז התעבורה לא מוגבלת בשום דבר, היא יכולה להיות 2-3 מיליון שורות בשנייה
• לאחר שדנו עם לקוחות בדרישות למהירות עיבוד שאילתות החיפוש, הבנו שהדפוס האופייני לשימוש במערכת כזו הוא זה: אנשים מחפשים יומנים של האפליקציה שלהם ביומיים האחרונים ואינם רוצים לחכות יותר מ- שנייה לתוצאה של שאילתה מנוסחת.
• המנהלים התעקשו שהמערכת תהיה ניתנת להרחבה בקלות במידת הצורך, מבלי לדרוש מהם להעמיק כיצד היא פועלת.
• כך שמשימת התחזוקה היחידה שמערכות אלו דורשות מעת לעת היא שינוי חומרה כלשהי.
• בנוסף, לאודנוקלסניקי יש מסורת טכנית מצוינת: כל שירות שאנו משיקים חייב לשרוד תקלה במרכז הנתונים (פתאומית, לא מתוכננת ולחלוטין בכל עת).

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

יום רביעי

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

ארבעת מרכזי הנתונים הללו מכילים כ-18 אלף מקורות יומנים שונים - חומרה, קונטיינרים, מכונות וירטואליות.

תכונה חשובה: האשכול מתחיל במכולות פודמן לא על מכונות פיזיות, אלא על מוצר ענן משלו one-cloud. למכולות מובטחות 2 ליבות, בדומה ל-2.0Ghz v4, עם אפשרות למחזר את שאר הליבות אם הן לא פעילות.

במילים אחרות:

טופולוגיה

בתחילה ראיתי את הצורה הכללית של הפתרון כדלקמן:

• 3-4 VIP עומדים מאחורי רשומת A של דומיין Graylog, זו הכתובת שאליה נשלחים היומנים.
• כל VIP הוא מאזן LVS.
• אחריו, היומנים עוברים לסוללת Graylog, חלק מהנתונים הם בפורמט GELF, חלק בפורמט syslog.
• ואז כל זה נכתב בקבוצות גדולות לסוללה של רכזי Elasticsearch.
• והם, בתורם, שולחים בקשות כתיבה וקריאה לצמתי הנתונים הרלוונטיים.

טרמינולוגיה

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

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

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

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

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

גריילוג
זה משהו כמו מיזוג של Kibana עם Logstash בערימת ELK. Graylog משלב גם ממשק משתמש וגם צינור לעיבוד יומנים. מתחת למכסה המנוע, Graylog מנהל את Kafka ו- Zookeeper, המספקים קישוריות ל- Graylog כמקבץ. Graylog יכול לאחסן יומנים במטמון (Kafka) במקרה של Elasticsearch אינו זמין ולחזור על בקשות קריאה וכתיבה לא מוצלחות, לקבץ ולסמן יומנים בהתאם לכללים שצוינו. כמו Logstash, ל- Graylog יש פונקציונליות לשינוי שורות לפני כתיבתן ל- Elasticsearch.

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

חזותית זה נראה בערך כך:

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

מדדים

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

בתרשים למעלה, זוהי הרמה הנמוכה ביותר: צמתי נתונים של Elasticsearch.

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

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

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

תחילה קבענו את זמן האחסון כ-30 יום.

ניתן לייצג את התפלגות הרסיסים באופן גרפי באופן הבא:

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

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

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

מרווח סיבובי אינדקס זה נובע מהסיבות הבאות:

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

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

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

כתוצאה מכך גילינו שבממוצע רסיס שוקל כ-20 גיגה-בייט, ויש 1 רסיסים לאינדקס. בהתאם לכך, אם נסובב אותם פעם ב-360 שעות, אז יש לנו 48 מהם. כל אינדקס מכיל נתונים למשך יומיים.

מעגלי כתיבה וקריאה של נתונים

בואו להבין איך הנתונים נרשמים במערכת זו.

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

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

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

לאחר מכן יומן העסקאות משוכפל ל-replica-shard, שנמצא במרכז נתונים אחר.

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

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

כל המערכת הזו מעבדת בממוצע שאילתות חיפוש במשך 48 השעות האחרונות ב-300-400 אלפיות השנייה, למעט שאילתות עם תו כללי מוביל.

פרחים עם Elasticsearch: הגדרת Java

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

החלק הראשון של הבעיות שהתגלו היה קשור לאופן שבו Java מוגדרת מראש כברירת מחדל ב-Elasticsearch.

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

התברר כי מיזוג אינדקס לוקן מתרחש מחוץ לירך. ומכולות מוגבלות בהחלט מבחינת המשאבים הנצרכים. רק heap יכול להתאים למשאבים אלה (ערך heap.size היה שווה בערך ל-RAM), וחלק מהפעולות מחוץ לערמה קרסו עם שגיאת הקצאת זיכרון אם מסיבה כלשהי הן לא התאימו ל-~500MB שנותרו לפני הגבול.

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

בעיה שניה
4-5 ימים לאחר השקת האשכול, שמנו לב שצמתי נתונים החלו ליפול מעת לעת מתוך האשכול ולהיכנס אליו לאחר 10-20 שניות.

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

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

הפתרון היה כדלקמן: הגבלנו את היכולת של ג'אווה להשתמש בחלק הארי של הזיכרון מחוץ לערמה עבור פעולות אלו. הגבלנו אותו ל-16 גיגה-בייט (-XX:MaxDirectMemorySize=16g), מה שמבטיח ש-GC מפורש נקרא לעתים קרובות הרבה יותר ומעובד הרבה יותר מהר, ובכך כבר לא מערער את היציבות של האשכול.

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

כאשר הגדרנו את העבודה עם אינדקסים, בחרנו mmapfs to להפחית את זמן החיפוש על רסיסים טריים עם פילוח נהדר. זו הייתה טעות לא קטנה, כי כשמשתמשים ב-mmapfs הקובץ ממופה ל-RAM, ואז אנחנו עובדים עם הקובץ הממפה. בגלל זה, מסתבר שכאשר ה-GC מנסה לעצור שרשורים באפליקציה, אנחנו הולכים ל-safepoint להרבה מאוד זמן, ובדרך אליה, האפליקציה מפסיקה להגיב לבקשות של המאסטר לגבי האם היא חיה. . בהתאם לכך, המאסטר מאמין שהצומת אינו קיים יותר באשכול. לאחר מכן, לאחר 5-10 שניות, אוסף האשפה עובד, הצומת מתעורר לחיים, נכנס שוב לאשכול ומתחיל באתחול רסיסים. הכל הרגיש מאוד כמו "ההפקה שמגיעה לנו" ולא התאים לשום דבר רציני.

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

בעיה רביעית
ואז הייתה עוד בעיה מאוד מעניינת שטיפלנו בה במשך זמן שיא. תפסנו אותו במשך 2-3 חודשים כי התבנית שלו הייתה בלתי מובנת לחלוטין.

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

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

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

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

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

כאן הסתיימו הבעיות עם Java והתחילו בעיות רוחב הפס.

"Berries" עם Elasticsearch: תפוקה

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

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

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

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

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

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

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

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

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

תמונת הקריאה מתחילה להיראות כך:

המעבר לאלגוריתם זה איפשר לשפר משמעותית את זמן השאילתה באותם רגעים שבהם הייתה לנו זרימה גדולה של יומנים לכתוב.

לבסוף, הבעיה העיקרית הייתה הסרה ללא כאבים של מרכז הנתונים.

מה שרצינו מהאשכול מיד לאחר איבוד הקשר עם DC אחד:

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

כפי שהתברר, רצינו משהו כזה:

וקיבלנו את הדברים הבאים:

איך זה קרה?

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

למה?

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

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

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

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

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

זה נראה בערך כך:

לאחר גרסה 6.4.0, שבה תוקן הבאג הנורא הזה, צמתי נתונים הפסיקו להרוג את המאסטר. אבל זה לא הפך אותו ל"חכם יותר". כלומר: כאשר אנו מוציאים 2, 3 או 10 (כל מספר מלבד אחד) צמתים נתונים, המאסטר מקבל הודעה ראשונה שאומרת שצומת A עזב, ומנסה לומר לצומת B, צומת C על כך, לצומת D.

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

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

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

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

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

כתוצאה מכך הגענו להחלטה הבאה:

• יש לנו 360 צמתי נתונים עם דיסקים של 700 גיגה-בייט.
• 60 רכזים לניתוב תעבורה דרך אותם צמתי נתונים.
• 40 מאסטרים שהשארנו כסוג של מורשת מאז גרסאות לפני 6.4.0 - כדי לשרוד את נסיגת מרכז הנתונים, היינו מוכנים נפשית לאבד מספר מכונות על מנת להבטיח לנו מניין מאסטרים גם ב התרחיש הגרוע ביותר
• כל ניסיון לשלב תפקידים במיכל אחד נתקל בעובדה שבמוקדם או במאוחר הצומת ישבר בעומס.
• האשכול כולו משתמש ב-heap.size של 31 גיגה-בייט: כל הניסיונות להקטין את הגודל הביאו להרג של כמה צמתים בשאילתות חיפוש כבדות עם התו הכללי המוביל או השגת מפסק החשמל ב- Elasticsearch עצמו.
• בנוסף, כדי להבטיח ביצועי חיפוש, ניסינו להקטין את מספר האובייקטים באשכול כמה שיותר, על מנת לעבד כמה שפחות אירועים בצוואר הבקבוק שקיבלנו במאסטר.

סוף סוף לגבי ניטור

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

• כל צומת נתונים מדווח לענן שלנו שהוא קיים, ויש עליו רסיסים כאלה ואחרים. כאשר אנו מכבים משהו איפשהו, האשכול מדווח לאחר 2-3 שניות שבמרכז A כיבנו את הצמתים 2, 3 ו-4 - זה אומר שבמרכזי נתונים אחרים אנחנו בשום פנים ואופן לא נוכל לכבות את אותם צמתים שיש עליהם רק רסיס אחד שמאלה.
• כשאנחנו יודעים את אופי ההתנהגות של המאסטר, אנחנו מסתכלים בזהירות רבה על מספר המשימות הממתינות. מכיוון שגם משימה אחת שנתקעה, אם היא לא תסתיים בזמן, תיאורטית במצב חירום כלשהו יכולה להפוך לסיבה שבגללה, למשל, קידום של רסיסי העתק בפריימריז לא עובד, וזו הסיבה שהאינדקס יפסיק לעבוד.
• אנחנו גם בוחנים מקרוב את עיכובי אוספי האשפה, כי כבר נתקלנו בקשיים גדולים עם זה במהלך האופטימיזציה.
• דוחה בשרשור כדי להבין מראש היכן צוואר הבקבוק.
• ובכן, מדדים סטנדרטיים כגון heap, RAM ו-I/O.

בעת בניית ניטור, עליך לקחת בחשבון את התכונות של Thread Pool ב- Elasticsearch. תיעוד Elasticsearch מתאר אפשרויות תצורה וערכי ברירת מחדל לחיפוש ואינדקס, אך שותק לחלוטין בנוגע ל-thread_pool.management.שרשורים אלו מעבדים, בפרט, שאילתות כמו _cat/shards ודומות אחרות, שנוחות לשימוש בעת כתיבת ניטור. ככל שהאשכול גדול יותר, כך מבוצעות יותר בקשות מסוג זה ליחידת זמן, וה-thread_pool.management הנ"ל לא רק שאינו מוצג בתיעוד הרשמי, אלא גם מוגבל כברירת מחדל ל-5 שרשורים, אשר נפטרים מהר מאוד, לאחר אשר ניטור מפסיק לפעול כראוי.

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

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

מקור: www.habr.com