Keepalived: מדוע כשל של צומת אחד מפיל את השירות
תרשים טיפוסי נראה בדרך כלל עמיד בפני כשלים: האפליקציה פרוסה במספר עותקים, מסד הנתונים משוכפל, למענה הוקצו משאבים. אבל הכניסה לשירות — מאזן העומסים, ה-proxy ההפוך או השער — מוצמדת לצומת אחד, והוא עצמו הופך לנקודת כשל יחידה. כל היתירות שמאחוריו מתאפסת בנפילה הראשונה.
מה שנשבר במקרה כזה אינו האפליקציה, אלא הכתובת. הצומת נופל בגלל חשמל, ליבה או עדכון כושל — ונקודת הכניסה שדרכה עוברים הלקוחות מפסיקה להגיב. רשומת ה-DNS לא מתחלפת באופן מיידי: זמן החיים של הרשומה ומטמוני ה-resolvers מפריעים, והעברת תעבורה ידנית אורכת דקות ונעשית בלילה לפי נוהל.
זמן ההשבתה בעת כשל של צומת נמדד בעשרות דקות: אצל המשתמשים — שגיאות ופסקי זמן, ואצל המשמרת התורנית — ניתוח תקלה ותיקון תצורה תחת לחץ.
המחיר של תרשים כזה אינו רק בשעות אי-הזמינות. כל החלפה ידנית היא סיכון לטעות: צומת לא נכון, נתיב שנשכח, סשנים שאבדו. כל עוד התרחיש הידני נשאר היחיד, עמידות השירות בפני כשלים נשענת על המהירות של התורן, ולא על הארכיטקטורה.
בואו נפרק איך סוגרים את זה. Keepalived מחזיק כתובת צפה על זוג צמתים בפרוטוקול VRRP, בודק את מצבם באמצעות סקריפטים ומעביר תעבורה בלי מעורבות אדם — עם זמן החלפה צפוי וללא תיקונים ידניים בלילה.
מה נותנת עמידות בפני כשלים: אפקט מדיד
האפקט של עמידות בפני כשלים נמדד בשלושה גדלים: כמה זמן השירות אינו זמין בעת כשל של צומת, איזה חלק מהתקלות בכלל מגיע למשתמש, והאם אפשר לתחזק שרתים בלי לעצור את העבודה.
החלפה אוטומטית במקום התערבות ידנית
בעבר, צומת שנפל הבחין בו התורן — לפי התראת ניטור, ולעיתים לפי תלונה. עד שהוא התחבר והעביר את הכתובת בידיים, השירות שכב עשרות דקות, וכל דקת השבתה נפלה על שעות העבודה. את ההחלפה מבצע Keepalived: הצומת המשני תופס את הכתובת בתוך שניות, בלי אדם בלופ.
זמן ההתאוששות של השירות מצטמצם מעשרות דקות ל-1-3 שניות, והתורן לומד על האירוע מהיומן כשהשירות כבר מקבל תעבורה.
סוג הכשל "צומת אינו זמין" יוצא מהסטטיסטיקה
כל עוד צומת אחד מאותחל מחדש או מתוקן, השני מחזיק את התעבורה — כשל חומרה מפסיק להיות כשל שירות. חשוב מה בודקים כדי לוודא שהשירות חי: תגובה ברמת הרשת מאשרת שהמכונה דולקת, אבל לא שהאפליקציה מגיבה. בדיקה באמצעות בקשה לאפליקציה מסננת צמתים שהם פורמלית חיים אבל מחזירים שגיאות.
כשל מלא של השירות דורש אז נפילה בו-זמנית של כל הצמתים, כלומר סיבה משותפת — רשת, חשמל או מהדורה כושלת. הזמינות של השירות עולה לא "בממוצע", אלא בזכות היעלמות של סוג שלם של תקלות.
עבודות מתוכננות ללא השבתה
התחזוקה מתבצעת צומת אחר צומת: מוציאים אותו מעיבוד התעבורה, מעדכנים, מחזירים לפעולה, ואז עוברים לבא בתור. הזמינות לא צונחת במהלכה, אין צורך לתאם חלון לילה או למהר — העבודות עוברות לשעות נוחות.
תרשים כזה משתלם גם בפעולות נדירות: החלפת חומרה או שינוי תצורה כבר לא הופכים להשבתה מתוכננת עבור המשתמשים.
מצבי העבודה של Keepalived: השוואת אפשרויות
את תרשים היתירות בוחרים לפני ההגדרה: ממנו תלויים סדרי העדיפויות של הצמתים, מספר הכתובות הווירטואליות, ואיך האשכול יתנהג כששרת שיצא מכלל פעולה חוזר לפעולה. VRRP מתיר כמה פריסות עבודה, וההבדל ביניהן הוא בכמה צמתים באמת נושאים בעומס ובכמה צפויה ההחלפה.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| צומת פעיל וצומת משני | שירות אחד, ניתוח תקלות פשוט, פשוט שהמענה יהיה במצב המתנה | הצומת המשני עומד מושבת; לאחר התאוששות הצומת הראשי הכתובת תחזור אליו רק אם החזרת הבעלות מותרת |
| צמתים שווי זכויות עם סדרי עדיפויות שונים | זוג שרתים שבו חשוב להחזיר את הכתובת במהירות לצומת הרגיל | סדר העדיפויות נקבע סטטית — בהוספת צומת שלישי מחשבים את התרשים ידנית |
| פיצול כתובות וירטואליות בין צמתים | כמה שירותים, צריך להעסיק את שני השרתים | כל צומת הופך לראשי עבור קבוצת הכתובות שלו: תצורות ובדיקות זמינות פי שניים |
בכל מצב, כשירות הצומת נקבע לא רק לפי חילופי מנות שירות אלא גם לפי בדיקת הזמינות של האפליקציה. סקריפט בדיקה מוריד את סדר העדיפויות של הצומת אם השירות אינו מגיב — הכתובת הווירטואלית עוברת לשרת חי. בלעדיו Keepalived ממשיך להחזיק את הכתובת במקום שבו התהליך כבר נפל, וההחלפה לא מתרחשת.
שלבי ההטמעה של אשכול עמיד בפני כשלים
העבודות מתנהלות מהמיפוי ועד למסירה: קודם מתעדים מה באמת פועל בלופ, אחר כך מתכננים תרשים עם מענה לכל שירות קריטי, ורק לאחר מכן נוגעים בצמתים החיים. סדר כזה שולל מצב שבו מפעילים עמידות בפני כשלים על שירותים שתלויות הרשת שלהם לא מוכנות ליתירות.
- ביקורת תשתית — אוספים מפה של צמתים, מקטעי רשת ושירותים, מסמנים נקודות כשל יחידות וקשרים שישרדו העברת כתובת וירטואלית ואלו שלא.
- תרשים יתירות — מגדירים זוגות צמתים ותפקידים, מקצים סדרי עדיפויות ב-Keepalived, בוחרים מצב החזרת התפקיד ומרווחי הכרזות VRRP, כדי שההחלפה לא תופעל בגלל הבהובים קצרים ברשת.
- תצורה ובדיקות זמינות — כותבים תצורה וסקריפטים שמעריכים את מצב השירות עצמו, ולא רק את חיות המארח: אחרת צומת עם אפליקציה שנפלה ימשיך להחזיק בכתובת הווירטואלית.
- בדיקת החלפה בסביבת בדיקה — משחזרים כשלים: עצירת ה-daemon, ניתוק קישור, אתחול צומת, קפיאה של השירות. מודדים את הזמן שבו המענה תופס את הכתובת, ומוודאים שסשנים ותורים לא הולכים לאיבוד.
- הוצאה ללופ הייצור — מפעילים מקטע אחד בכל פעם עם חלון תצפית, שומרים את גרסת התצורה הקודמת לחזרה מהירה ועוקבים אחרי מצב טבלאות ההתקנים השכנים.
- מסירת נהלים — מוסרים את תרשים הכתובות, התצורות, תרחישי ההחלפה הידנית וסדר הפעולות של התורן בעת פיצול צמתים, כדי שצוות התפעול ינהל את האשכול בלעדינו.
תצורות, תרשימים ונהלי החלפה
החלק ההנדסי של השירות לא מסתיים בהרצת השירות, אלא בחבילת מסמכים שלפיה אפשר לנהל את האשכול בלעדינו. אנחנו מוסרים ללקוח את תצורות Keepalived, את תרשים הרשת ואת הנהלים — כך המשמרת התורנית מבינה מה קורה, ומהנדס חדש נכנס לפרויקט בתוך שעות ולא שבועות.
- תצורת האשכול: הקבצים של שני ה-nodes עם התפקידים "ראשי/משני", מזהה הנתב הווירטואלי, סדרי העדיפויות ומרווחי ההכרזה — עם הערות שמסבירות מדוע זה הוגדר בדיוק כך.
- תרשים הרשת: כתובות הצמתים והכתובת הווירטואלית, תת-הרשתות, שמות הממשקים, נקודות הכשל וטבלת סדרי העדיפויות — על דף אחד, ולא מורכב מחתיכות.
- בדיקות חיות השירות: סקריפטים, פרמטרי הפעלה, ספי הפעלה וההתנהגות בעת דעיכת הצומת ובעת כשל מלא שלו.
- נוהל החלפה: התרחיש השגרתי, תרחיש החירום, החלפה ידנית והחזרת התפקיד חזרה — עם ציון מי מקבל את ההחלטה.
- הוראות לתורן: פעולות שלב אחר שלב בעת אובדן הכתובת הווירטואלית, הסרת המצב, איסוף לוגים וקריטריונים מתי לקרוא לנו.
- הגדרת ניטור: מדדי מצב הצמתים, התראות על החלפת תפקיד ובדיקת זמינות חיצונית של השירות — כדי לראות את הכשל לפני שהמשתמשים מתקשרים.
- פרוטוקול מבחני קבלה: תרחישי הכשל שהרצנו, וזמן ההתאוששות בכל אחד מהם — כהוכחה שההחלפה עובדת.
בסעיף נפרד נכלל צ'ק-ליסט השינויים: איך לערוך את התצורה בלי להוציא את שני ה-nodes מכלל פעולה בפעולה אחת.
מקרה בוחן: החלפה בלי אובדן תעבורה בלופ הייצור
לופ הייצור של השירות נשען על שני צמתים: נקודת הכניסה חיה על שרת אחד, והשני עמד כמענה חם. בעת כשל של הצומת הפעיל הרימו את הכתובת הווירטואלית ידנית — המהנדס התורן קיבל התראה, התחבר לשרת והגדיר מחדש את הכתובת, בעוד הלקוחות רואים שגיאות.
נקודת ההתחלה: מדידות לפני ההטמעה
תחילה תיעדנו את המצב ההתחלתי — ניתחנו את סטטיסטיקת התקלות ושחזרנו כשל בסביבת בדיקה עם הגדרות הייצור. מדדנו שלושה גדלים: זמן ההחלפה, שיעור החיבורים שאבדו ומספר ההתערבויות הידניות.
סביבת הבדיקה נתנה את אותם מספרים כמו לופ הייצור: 8–14 דקות להחלפה, עד 6% חיבורים שנקטעו, 4–6 קריאות לילה למהנדס בחודש.
מה שינינו ומה קיבלנו
על שני הצמתים התקנו Keepalived במצב VRRP: הכתובת הווירטואלית מוצמדת לצומת הפעיל, והמשני עוקב אחרי האותות ותופס את הכתובת כשהם נעלמים. סדרי העדיפויות הוגדרו כך שההחזרה לאחר התאוששות תהיה נשלטת — בלי "משיכות" תעבורה הלוך ושוב.
בנפרד הוספנו בדיקת בריאות של האפליקציה: אם השירות חי אבל לא מגיב, הכתובת עוברת בלי להמתין לכשל חומרה.
במבחני הקבלה ההחלפה עמדה ב-1–2 שניות, שיעור החיבורים שאבדו ירד לשברי אחוזים, וההתערבויות הידניות במשמרת נעלמו. בלופ הייצור הרצנו תחילה כשל של כל צומת בנפרד, ואחר כך — כשל של שניהם עם החזרה לפעולה.
במה Keepalived שונה ממנהל אשכול
Keepalived הוא daemon של פרוטוקול VRRP: הוא מחזיק כתובת וירטואלית על הצומת הפעיל ומעביר אותה לצומת המשני כשהראשי הפסיק להגיב. בדיקות הזמינות מוגדרות לפי השירות הספציפי — בדיקת פורט TCP, תגובת HTTP או קיום התהליך.
כל עוד הבדיקה עוברת, הכתובת נשארת על הצומת הנוכחי; הפסיקה לעבור — הכתובת עוברת לצומת המשני, והלקוחות ממשיכים לעבוד באותה כתובת בלי עריכת קונפיגים.
מנהל אשכול פועל ברמה אחרת. הוא מנהל משאבים: מפעיל ועוצר שירותים בסדר מוגדר, מחבר דיסקים משותפים, עוקב אחרי קוורום ומבודד צומת שאיבד קשר עם האחרים. יתירות כתובת היא עבורו רק אחד המשאבים, ולא המשימה העיקרית.
מכאן גם קריטריון הבחירה. אם האפליקציה כבר יודעת לשכפל את עצמה ועולה באופן עצמאי, והקריטי הוא רק אחד — שהתעבורה תעבור לצומת חי — די ביתירות כתובת ובבדיקות זמינות.
אם צריך מחזור חיים נשלט — להעלות את מסד הנתונים, להמתין לסנכרון, לחבר דיסק משותף ורק אז לפתוח את הכתובת — בלי מנהל אשכול אי אפשר להסתדר.
בפועל לא מעמידים אותם זה מול זה. ה-daemon של VRRP אחראי על הכתובת ועל פיזור התעבורה, ומנהל האשכול — על המשאבים; החיבור ביניהם נותן מעבר תעבורה מהיר וסדר הפעלה תקין של השירותים לאחר ההחלפה.
לכן בשלב בחירת הכלי אנחנו מסתכלים על האפליקציה עצמה: כמה מצבים יש לה, האם נדרש קוורום, האם יש דיסק משותף והאם סדר ההפעלה הקפדני הכרחי. מהתשובות תלוי אם נסתפק ב-daemon VRRP אחד או שנבנה אשכול מלא עם ניהול משאבים.
בדיקות זמינות, השהיות ופיצול רשת
בדיקת הזמינות של השירות ב-Keepalived היא לא פינג לכתובת, אלא בדיקה של השירות עצמו: סקריפט מקומי פונה לפורט שלו או שולח בקשת ניסיון, ולפי התגובה מחליט אם הצומת חי. כל עוד הבדיקה עוברת, הצומת מחזיק בכתובת; בכשל — מסיר אותה ומוסר לשותף.
את סף ההפעלה והמרווח בוחרים כך שעיכוב בודד של האפליקציה לא יגרום להחלפה, אחרת הכתובת "תקפוץ" סתם כך.
שני צמתים פעילים מופיעים במקום שבו מנות השירות הולכות לאיבוד בכיוון אחד: כל אחד חושב שהשותף מת ותופס את הכתובת לעצמו. ההגנה — סדרי עדיפויות, אישור חיבור חובה לפני תפיסת הכתובת ופיצול רשת: חילופי השירות עוברים במקטע נפרד או במשלוח כתובתי, ולא בשידור רחב דרך תעבורת הייצור.
מה קורה לחיבורים שכבר פתוחים בעת ההחלפה?
מצב החיבורים חי על הצומת ולא עובר יחד עם הכתובת. הלקוח חווה תקלה קצרה וחוזר על הבקשה, ולכן מתכננים את ההחלפה במקום שבו החזרות בטוחות: פעולות אידמפוטנטיות, מאזן עומסים עם טבלת מצבים משותפת. עבור סשנים ארוכים מתארים מראש כניסה מחודשת של המשתמש.
איך מבטיחים שלא יהיו שני צמתים פעילים?
סדרי עדיפויות לבדם לא מספיקים: צומת עם משקל גבוה צריך גם להשתכנע שהשותף באמת לא קיים. לכן מוסיפים השהיית הפעלה אחרי עלייה, בדיקת קישוריות וערוץ נפרד למנות השירות. במקטעים מפוצלים זו הדרך היחידה להבדיל בין אובדן קשר לכשל של צומת.
כמה מהר הצומת חוזר לפעולה?
הצומת עולה מעצמו, אבל לא תופס את הכתובת מיד — קודם הבדיקות צריכות להתייצב, ואחר כך ממתינים בהשהיה כדי שהשירות לא יזוז. החזרה לפי סדר העדיפויות אפשר לדחות לחלון עבודות או לבטל: אז התפקיד נשאר בידי הצומת הפעיל הנוכחי, והמשוחזר עובד כמענה.
נדון במשימה: הטמעת Keepalived ללופ שלכם
השיחה הראשונה היא ניתוח של הלופ שלכם, ולא מצגת. מבררים כמה צמתים משתתפים בזוג עמיד בפני כשלים, אילו שירותים מחזיקים בכתובת הווירטואלית, איך מתפזרת התעבורה והאם יש מאזן עומסים מעל. בנפרד מדברים על חלונות לשינויים: האם אפשר לאתחל צמתים בשעות היום, והאם יש גישה לניהול הרשת וליומנים.
כדי שההערכה תהיה עניינית, נדרשים מכם נתוני פתיחה: תרשים הרשת, רשימת השירותים מאחורי הכתובת הווירטואלית, דרישות לזמן ההחלפה ומצב התחזוקה. אם אין תיעוד — נבנה את התמונה בשיחה עם המהנדסים שלכם.
לאחר הניתוח נשלח:
- תרשים הלופ עם נקודות הכשל המסומנות והמקום שבו נכנס Keepalived;
- תוכנית הטמעה לפי שלבים, עם חלונות עבודה וסדר החזרה לאחור;
- הרכב העבודות: הגדרת VRRP, בדיקות זמינות של השירותים, סקריפטי החלפה;
- רשימת השינויים בתצורות ומה יידרש מצדכם;
- תרחישי בדיקה: איך נוודא שהצומת אכן תופס את הכתובת;
- תפקידים ונקודות תיאום במהלך העבודות;
- הערכה לפי שלבים — עומס העבודה והתלויות, בלי הצמדות לתאריכים בלוח השנה.
תארו את המשימה בשתי פסקאות — נחזור עם הערכה ותוכנית הטמעה ללופ שלכם.