התראת AWS על מנהרה אחת: מתי היא באמת חשובה

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

מה ההתראה למעשה מדדה

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

קראו טלמטרייה לכל מנהרה במקום את המצב הכולל של החיבור. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' מחזיר סטטוס והודעה לכל מנהרה, וזו הראיה שעליה מתבססת ההתראה.

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

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

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

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

מה עמית גיבוי אינו מוכיח

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

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

התאימו את השינוי לרדיוס ההשפעה שלו

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

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

הוכיחו את החלופה לפני שתזדקקו לה

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

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