השפעת כשלים בתשתית על שבר ב- Amazon OpenSearch Service

השפעת כשלים בתשתית על שבר ב- Amazon OpenSearch Service

צומת המקור: 1783553

שירות חיפוש פתוח של אמזון הוא שירות מנוהל המקל על אבטחה, פריסה ותפעול של OpenSearch ושל אשכולות Elasticsearch מדור קודם בקנה מידה גדול בענן AWS. Amazon OpenSearch Service מספק את כל המשאבים עבור האשכול שלך, משיק אותו ומזהה ומחליף באופן אוטומטי צמתים כושלים, ומפחית את התקורה של תשתיות בניהול עצמי. השירות מקל עליך לבצע ניתוחי יומנים אינטראקטיביים, ניטור יישומים בזמן אמת, חיפושי אתרים ועוד על ידי הצעת הגרסאות העדכניות ביותר של OpenSearch, תמיכה ב-19 גרסאות של Elasticsearch (גרסאות 1.5 עד 7.10), ויכולות הדמיה המופעלות על ידי OpenSearch Dashboards ו-Kibana (גרסאות 1.5 עד 7.10).

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

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

האתגר

אומרים שדומיין של Amazon OpenSearch Service הוא "מאוזן" כאשר מספר הצמתים מתחלק באופן שווה על פני אזורי זמינות מוגדרים, והמספר הכולל של הרסיסים מחולק באופן שווה על פני כל הצמתים הזמינים ללא ריכוז של רסיסים של כל אינדקס אחד על אף אחד. צוֹמֶת. כמו כן, ל-OpenSearch יש מאפיין שנקרא "Zone Awareness" שכאשר הוא מופעל, מבטיח שהשבר הראשי והעותק המתאים לו מוקצים באזורי זמינות שונים. אם יש לך יותר מעותק אחד של נתונים, ריבוי אזורי זמינות מספק סובלנות וזמינות לתקלות טובות יותר. במקרה, התחום גדל או מוקטן בתוך או במהלך כשל של צמתים, OpenSearch מפיץ מחדש באופן אוטומטי את הרסיסים בין צמתים זמינים תוך ציות לכללי ההקצאה המבוססים על מודעות לאזור.

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

לדוגמה, אם צומת אחד באשכול של שלושה צמתים יורד, OpenSearch מפיץ מחדש את הרסיסים שלא הוקצו, כפי שמוצג בתרשים הבא. כאן "P" מייצג עותק רסיס ראשי, ואילו "R" מייצג עותק רפליק.

התנהגות זו של התחום יכולה להיות מוסברת בשני חלקים - במהלך כשל ובמהלך התאוששות.

בזמן כישלון

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

כשל אזור מוחלט

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

  • כאשר הרסיסים של האזור המושפע מוקצים מחדש לאזורים בריאים, הם מפעילים שחזורי רסיסים שיכולים להגדיל את זמן ההשהיה מכיוון שהוא צורך מחזורי CPU נוספים ורוחב פס רשת.
  • עבור הגדרת n-AZ, n-copy, (n>1), אזורי הזמינות השורדים n-1 מוקצים עם עותק הרסיס ה-n, דבר שעלול להיות לא רצוי מכיוון שהוא עלול לגרום לעיוות בהפצת הרסיסים, מה שעלול לגרום גם ל תעבורה לא מאוזנת על פני צמתים. צמתים אלה עלולים לקבל עומס יתר, מה שמוביל לכשלים נוספים.

כשל אזור חלקי

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

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

התאוששות

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

מה משתנה

כדי לשפר את הטיפול הכולל בכשלים ולמזער את ההשפעה של כישלון על בריאות וביצועי הדומיין, Amazon OpenSearch Service מבצע את השינויים הבאים:

  • מודעות אזור כפויה: ל-OpenSearch יש תצורת איזון רסיסים קיימת שנקראת מודעות כפויה המשמשת להגדרת אזורי הזמינות אליהם יש להקצות רסיסים. לדוגמה, אם יש לך תכונת מודעות שנקראת אזור ותגדיר צמתים ב zone1 ו zone2, אתה יכול להשתמש במודעות כפויה כדי למנוע מ-OpenSearch להקצות העתקים אם רק אזור אחד זמין:
cluster.routing.allocation.awareness.attributes: zone
cluster.routing.allocation.awareness.force.zone.values: zone1,zone2

עם תצורה לדוגמה זו, אם אתה מתחיל שני צמתים עם node.attr.zone מכוון ל zone1 וליצור אינדקס עם חמישה רסיסים ועותק אחד, OpenSearch יוצר את האינדקס ומקצה את חמשת הרסיסים הראשיים אך ללא העתקים. העתקים מוקצים רק פעם אחת עם צמתים node.attr.zone מכוון ל zone2 זמינים.

Amazon OpenSearch Service ישתמש בתצורת המודעות הכפויה בדומיינים של Multi-AZ כדי להבטיח שרסיסים מוקצים רק לפי כללי המודעות לאזור. זה ימנע את העלייה הפתאומית בעומס על הצמתים של אזורי הזמינות הבריאים.

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

הערות שכל שלא הוקצה יְסוֹדִי העתקה עדיין תהיה מותרת בצומת העמוס כדי למנוע מהאשכול כל אובדן נתונים קרוב.

באופן דומה, כדי לטפל בבעיית השחזור הידנית (כמתואר בסעיף השחזור לעיל), Amazon OpenSearch Service מבצע שינויים גם ברכיב קנה המידה הפנימי שלו. עם השינויים החדשים יותר, Amazon OpenSearch Service לא ישיק צמתים באזורי הזמינות הנותרים גם כאשר הוא עובר את תרחיש הכשל שתואר קודם לכן.

הדמיית ההתנהגות הנוכחית והחדשה

לדוגמה, דומיין של Amazon OpenSearch Service מוגדר עם 3-AZ, 6 צמתי נתונים, 12 רסיסים ראשיים ו-24 רסיסי העתק. הדומיין מסופק על פני AZ-1, AZ-2 ו-AZ-3, עם שני צמתים בכל אחד מהאזורים.

הקצאת רסיסים נוכחית:
מספר כולל של רסיסים: 12 ראשוני + 24 העתקים = ​​36 רסיסים
מספר אזורי זמינות: 3
מספר רסיסים לאזור (המודעות לאזור נכונה): 36/3 = 12
מספר צמתים לכל אזור זמינות: 2
מספר רסיסים לצומת: 12/2 = 6

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

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


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


באופן דומה, במקרה שכל הצמתים ב-AZ-3 אובדים, או שה-AZ-3 נפגם, Amazon OpenSearch Service מעלה את הצמתים האבודים באזור הזמינות הנותר וגם מפיץ מחדש את הרסיסים בצמתים. עם זאת, לאחר השינויים החדשים, Amazon OpenSearch Service לא יקצה צמתים לאזור הנותר או ינסה להקצות מחדש רסיסים אבודים לאזור הנותר. Amazon OpenSearch Service ימתין עד שהשחזור יקרה ושהדומיין יחזור לתצורה המקורית לאחר השחזור.

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


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

מה אתה יכול לצפות

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

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

עדכן את תוכנת השירות של דומיין Amazon OpenSearch Service שלך ​​כדי להחיל את השינויים החדשים האלה על הדומיין שלך. פרטים נוספים על תהליך עדכון תוכנת השירות נמצאים ב- תיעוד שירות חיפוש פתוח של אמזון.

סיכום

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

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


על המחברים

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

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

שוריה דוטה ביזוואז הוא מהנדס תוכנה שעובד על AWS OpenSearch בשירותי האינטרנט של אמזון. הוא נלהב לבנות מערכות מבוזרות עמידות במיוחד.

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

רנג'ית רמאצ'נדרה הוא מנהל הנדסה שעובד על Amazon OpenSearch Service בשירותי האינטרנט של Amazon.

ג'ון הנדלר הוא ארכיטקט פתרונות ראשי בכיר, המתמחה בטכנולוגיות חיפוש AWS - Amazon CloudSearch ושירות Amazon OpenSearch. מבוסס בפאלו אלטו, הוא עוזר למגוון רחב של לקוחות לפרוס את עומסי העבודה של ניתוח החיפוש והיומן שלהם בצורה נכונה ומתפקדת היטב.

בול זמן:

עוד מ AWS Big Data