מדוע תצורת ברירת המחדל של HAProxy נשברת תחת עומס
תצורת ברירת המחדל של HAProxy היא סט ערכי ברירת מחדל שמספיקים בסביבת בדיקות ואינם מספיקים בשיא. צוואר הבקבוק הראשון — זמני פסק (timeouts) לחיבורים שלא הוגדרו במפורש: בזמן שלקוח מחזיק חיבור לא פעיל, ושרת האפליקציה מגיב לאט מהרגיל, חריצי העיבוד נגמרים לפני שהתעבורה מגיעה. התור גדל, זמן התגובה עולה בצורה מפולתית, ואיזון העומס מתחיל לפזר לא בקשות אלא השהיות.
היעדר בדיקות מצב של צמתים — המוקש השני. כברירת מחדל המאזן בודק לעתים קרובות רק זמינות פורט: האפליקציה יכולה להחזיר שגיאות אך להישאר ברוטציה ולקבל את חלקה בתעבורה. צומת אחד שהידרדר גורר למטה את כל הבריכה, והבעיה מתגלה מתלונות משתמשים ולא ממדדים.
השלישית — נקודת כניסה יחידה למערכת כנקודת כשל. תהליך אחד, כתובת אחת, עריכת תצורה ידנית: עדכון או הפעלה מחדש משמעותם ניתוק של סשנים פעילים, וכשל של המאזן עצמו מפיל את כל השירות. הסטטיסטיקה לא נאספת במקרה כזה, ולכן חקירת האירוע מתבצעת רק אחריו, לפי לוגים של האפליקציות.
אנחנו מפרקים כיצד זה נסגר: זמני פסק מפורשים בהתאם לפרופיל התעבורה, בדיקות מצב לפי תגובת האפליקציה, גיבוי נקודת הכניסה וניטור שמראה את ההידרדרות לפני שהיא הופכת לכשל.
מה משתנה לאחר עיבוד מחדש של התצורה והפעלת הניטור
מה משנים בתצורה ניכר לפי שלושה מדדים: זמן תגובה בשיא, שיעור התגובות השגויות והזמן שבו המערכת חוזרת לשגרה לאחר נפילת צומת.
בשיא התעבורה מפסיקה להיתקע בשרת אחד: אלגוריתם האיזון בוחר צומת לפי מספר החיבורים הפעילים ולא לפי סבב, מספר הסשנים בו-זמנית לכל צומת מוגבל, והחיבורים לאפליקציות עוברים שימוש חוזר במקום לפתוח חיבור חדש לכל בקשה.
זמני הפסק נקבעים לפי התפלגות בפועל של זמן העיבוד, ולכן צומת איטי אך חי מספיק להשיב ולא מנותק לפני הזמן, והתור בכניסה לא גדל בצורה מפולתית.
HAProxy מחזיק בדיקת בריאות נפרדת לכל צומת: מרווח, סף של כשלים עוקבים ותנאי החזרה לרוטציה. זה סוגר סוג של כשלים שהיה לפני העיבוד מחדש המקור העיקרי ל-5xx — צומת שהידרדר, שמגיב אבל לאט, המשיך לקבל את חלקו בתעבורה וקלקל את התגובות לחלק מהמשתמשים.
כעת הצומת מוצא מהרוטציה לפני שיתחיל להחזיר שגיאות, שליחה חוזרת מתבצעת רק עבור בקשות בטוחות לחזרה, והשאר מקבלות תגובה מפורשת במקום חיבור תלוי.
זמן ההתאוששות לאחר נפילת צומת נקבע לפי מרווח הבדיקה וסף הכשלים — זה גודל ניתן להגדרה ולא תוצאה של מזל. בחזרה לרוטציה הצומת נכנס בהדרגה: תחילה מקבל חלק קטן מהתעבורה, ורק אם זמן התגובה נשמר בטווח התקין, חוזר למלואו. צומת הגיבוי נכנס לפעולה כשהבריכה הראשית הידרדרה כולה, ולכן פרץ כשלים לא הופך להשבתה מלאה.
ניטור העומס נשען על יומני גישה ומונים: זמן עיבוד לכל בקשה, התפלגות התעבורה בין הצמתים, שיעור השגיאות, ההמתנה בתור ומצב כל שרת. מהנתונים האלה רואים אם צומת מסוים הידרדר או שהתעבורה הכללית גדלה, וההתראות מוגדרות לפי פרופיל העומס הנצפה ולא לפי הערכה.
כמה יממות לאחר ההפעלה מתברר אילו ספים הפכו למיותרים ואיפה נדרש מרווח — התצורה מתעדכנת לפי המצב בפועל ולא לפי הנחות.
תצורת HAProxy: אפשרויות איזון והמגבלות שלהן
סכמת האיזון היא לא הוראה אחת אלא סט: אלגוריתם ההתפלגות, בדיקות המצב, קו הגיבוי ונקודת הכניסה. טעות בכל רמה נראית אותו דבר — חלק מהבקשות עוברות לצומת לא תקין ותלויות שם עד לפקיעת ההמתנה.
ארבע סכמות והגבולות שלהן
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| התפלגות לפי חיבורים (roundrobin, leastconn) | צמתים הומוגניים, בקשות קצרות | חיבורים ארוכים מכבים את האיזון; צומת חדש שנוסף לוקח את כל הזרם |
עם בדיקות מצב פעילות (option httpchk) |
השירות חי אך מחזיר שגיאות | בדיקה של כתובת נפרדת לא רואה הידרדרות של מסד הנתונים; סקרים תכופים יוצרים הסרות שווא |
עם קו גיבוי (backup) |
שירות קריטי עם עתודת כוח מוגבלת | הגיבוי נכנס רק בכשל מלא של הראשי; ההידרדרות שלו אינה ניכרת עד לתקלה |
| עם התפלגות חיצונית בכניסה (רשומת DNS, צומת מעל) | כמה נקודות כניסה, גיאוגרפיה | מטמון הרשומות והשהיית ההסרה מחזיקים את התעבורה על צומת שנפל במשך דקות |
לפני הבחירה בודקים שלושה דברים: תוך כמה שניות הצומת מוצא מהרוטציה, מה קורה בכשל של המאזן עצמו והיכן חי מצב הסשן. אם הסשנים דביקים והצומת עוזב — המשתמש מאבד את העגלה; אם הבדיקה מסתכלת רק על פורט פתוח, ההידרדרות נשארת בלתי נראית. את הסכמה מתאימים לפרופיל התעבורה ולא לברירת המחדל.
כיצד עובר היישום: מניתוח הסכמה ועד למסירה
סדר העבודות זהה גם ליישום חדש וגם לבנייה מחדש של מאזן שכבר עובד: תחילה מתעדים את המצב בפועל, אחר כך מרכיבים את הסכמה הרצויה ובודקים אותה בקונטור בדיקות, ורק לאחר מכן נוגעים בקונטור העבודה. העלות — לפי חישוב אישי. סקר תשתיות.
משרטטים מפה של השירותים, הכתובות והפורטים, בודקים היכן עומד המאזן ביחס להיקף ולהגנה. מנתחים סטטיסטיקה ולוגים: היכן אובדות בקשות, איך חי הסשן, ואילו עריכות בוצעו בשרתים ביד. 2. הסכמה הרצויה. מחליטים מה מאוזן ברמת החיבור ומה דורש ניתוח כותרות, כיצד מתפלג העומס והיכן נשמר מצב הסשן.
את הסכמה מתאמים לפני השורה הראשונה של התצורה. 3. תצורה בסביבת הבדיקות. פורסים את HAProxy בקונטור בדיקות עם אותם תפקידי שרתים. כאן גם מגדירים איסוף סטטיסטיקה, לוגים והגבלות קצב פניות. 4. בדיקה תחת עומס.
מריצים פרופיל קרוב לשיא: זמן תגובה, התפלגות בין השרתים והתנהגות בעת גידול במספר החיבורים ובלקוחות איטיים. עריכות מבצעים כל עוד זה סטנד ולא משתמשים. 5. מבחני כשל. בתורו מוציאים שרתים מכלל פעולה, בודקים את פעולת בדיקות הזמינות ואת החזרה העצמאית של הצומת לפעולה.
כאן גם מתעדים את תרחיש החזרה לאחור של השינויים. 6. העברת התעבורה. מחליפים בהדרגה: תחילה חלק מהבקשות, אחר כך כל הזרם, עם מעקב אחר שגיאות והשהיות. אם המדדים יוצאים מהגבולות, החזרה לאחור אורכת דקות. 7. מסירה למשמרת התורנות.
מוסרים את הסכמה, התצורה, סדר הפעולות השגרתיות וניתוח האירועים. מהנדס תורן עובר יחד עם שלנו הפעלה מחדש של התצורה ותקלת תרגול.
מה נשאר אצלכם: תצורות, סכמות ונהלים
המאזן נשאר בקונטור שלכם, ולכן כל מה שנדרש להפעלתו ולעריכותיו צריך להישאר אצל הצוות שלכם ולא בהתכתבות איתנו. לכן אנחנו מוסרים לא «קבצים לזיכרון» אלא סט תוצרים שלפיו מהנדס תורן, בלי העזרה שלנו, יריץ את הקונטור, ישנה מסלול ויחזור לאחור מעריכה כושלת.
כל מסמך נכתב עבור אדם שרואה את המערכת בפעם הראשונה: היכן להסתכל, מה לבדוק לאחר שינוי, ולאיזה אות להגיב ראשון.
- תצורות עבודה — קבצי HAProxy לכל הסביבות, עם הערות להחלטות לא מובנות מאליהן: מדוע נבחר זמן המתנה כזה לתגובה, כיצד מתפלגים התורים ומה שמור לשיאי עומס.
- סכמת הזרימות — מהיכן מגיעה התעבורה, היכן מסתיים ההצפנה, אילו צמתים עומדים מאחורי המאזן ואילו מקומות נשארים נקודות כשל. שחזור התמונה אורך דקות ולא שעות של ניתוח לוגים.
- מדיניות גישה — כללים מי ומאילו כתובות נכנס לפאנל הניהול ולסטטיסטיקה, כיצד מוגבלים שינויים בקונטור הפרודקשן ומי רשאי לאשר אותם.
- הוראות חזרה לאחור — החזרה מדורגת של התצורה הקודמת בפעולה אחת, רשימת בדיקות לאחר החזרה וסדר הפעולות אם החזרה לא עזרה.
- ניהול גרסאות של שינויים — תצורות במערכת בקרת גרסאות, כל עריכה כמערכת נפרדת עם תיאור: רואים מי, מתי ולמה שינה מסלול או כלל.
- נוהל ניטור — אילו מדדים נאספים, באילו ספים מגיעה התראה, לאן היא נשלחת ומי תורן.
- סדר המסירה — חשבונות, תפקידים והרשאות מונפקים לאנשים שלכם, והגישות שלנו נסגרות מיד לאחר המסירה.
מקרה בוחן: העברנו תעבורה לקו גיבוי בלי השבתה
לפני העבודה את תעבורת הכניסה שירת צומת איזון אחד: עליו התרכזו סיום ההצפנה, הצמדת סשנים של לקוחות לשרת מסוים ובדיקות זמינות של הבקאנדים. כל עדכון תצורה מתוכנן חייב הפעלה מחדש של התהליך — לפי הלוגים זה הניב עד 400 סשנים שנקטעו בחלון התחזוקה ופרץ של תגובות 502 בכניסה. קו גיבוי היה קיים, אבל עברו אליו ידנית ורק במקרה חירום.
העברנו את הכניסה לזוג צמתי HAProxy עם כתובת צפה משותפת: התצורה נבנית ממקור אחד ומופצת כולה, והפעלה מחדש ללא תפר מעבירה את הסוקטים המאזינים לתהליך החדש בלי לנתק חיבורים שכבר הוקמו. את הצמדת הסשנים הסרנו — את המצב הוציאו לאחסון משותף, ולכן כל צומת משרת בקשה. את המעבר בין הקונטורים מנהלות כעת בדיקות הזמינות ולא המהנדס התורן.
מה הראו המדידות
בדקנו בשתי דרכים: בהרצת פרופיל עומס שנלקח מהתעבורה בפרודקשן ובניתוק מבוקר של צומת בשעות העבודה. החציון של זמן התגובה בכניסה הצטמצם כמעט פי שלושה, שיעור התגובות שארוכות משנייה ירד מ-7% ל-0,3%, והתגובות 5xx — מ-2,4% ל-0,02%.
סשנים שנקטעו בתחזוקה אין יותר: המעבר לקו הגיבוי נכנס למרווח בדיקה אחד, והמשתמש לא מבחין בו. המעבר חזרה של הקו — אותה פעולה עם אותה תוצאה.
במה שונה מאזן רשת ממאזן אפליקטיבי?
שכבת הרשת עובדת עם זרם החיבורים: המאזן רואה כתובת ופורט, בוחר שרת לפי האלגוריתם ומשם לא מתערב בתעבורה. תוכן החבילות לא מנותח, ולכן ההשהיה מזערית וההתנהגות זהה עבור HTTP, מערכות ניהול מסדי נתונים וחיבורים ארוכי טווח.
המגבלה אחת: יחידת האיזון היא חיבור שלם, ואם הלקוח מחזיק ערוץ אחד, אי אפשר להפריד בו בין סוגי בקשות שונים לפי ייעוד.
השכבה האפליקטיבית מנתחת את הפרוטוקול האפליקטיבי ורואה את המתודה, הנתיב, הכותרות וה-cookie. מכאן נובעת ניתוב הבקשות: את הסטטי מגישה בריכת שרתים אחת, את ה-API — שנייה, כתובות שירות — שלישית, והכללים משתנים בכניסה בלי עריכות בשרתים עצמם.
שם גם פועלת הצמדת סשן לפי cookie ובדיקת זמינות מדויקת: צומת שמשיב בשגיאה בכתובת השירות מוצא מהרוטציה, אף שברמת הרשת היה נראה חי.
סיום ההצפנה הוא החלטה נפרדת עם מחיר משלה. כשההצפנה מוסרת בכניסה, התעודות ופרמטרי החיבור חיים במקום אחד, השירותים הפנימיים מקבלים תעבורה פתוחה, וכללי הניתוב רואים את התוכן במלואו.
הצפנה מקצה לקצה עד השרת משאירה את התעבורה סגורה למאזן, אבל אז הניתוב מתבצע רק לפי מטא-נתונים, ועדכון התעודות נופל על כל צומת.
בפועל המצבים מתקיימים זה לצד זה: HAProxy מנהל חלק מהשירותים ברמת הרשת ואת עומס ה-HTTP ברמה האפליקטיבית, והמצב נקבע לכל בריכת שרתים בנפרד.
ספקות טכניים נפוצים לפני תחילת העבודה
הספקות של צוות ההנדסה הם בדרך כלל אותם ספקות: מה יקרה בכשל של צומת, כמה מהר אפשר לחזור לאחור, מי אחראי על התעודות והאם נצטרך לתפוס הידרדרות לפי תלונות משתמשים. אנחנו מסכמים את הנקודות האלה לפני ההתחלה כדי שהסכמה תישאר ניתנת לתחזוקה ולא «עובדת כל עוד לא נוגעים בה».
להלן תשובות קצרות בבלוקים נפתחים. אם השאלה שלכם לא כאן, נוסיף אותה לניתוח המשימה ונחזור עם הערכה ותוכנית עבודה.
כמה מהר תדעו שצומת נפל?
המאזן בודק לא רק את זמינות הפורט אלא גם את מוכנות האפליקציה להשיב — לפי כתובת מצב נפרדת. צומת שהפסיק לעבור את הבדיקה מספר פעמים עוקבות שהוגדר מוצא מהרוטציה בתוך שניות, בלי להמתין לתלונות.
ספי הבדיקות, המרווחים וזמני הפסק של החיבור מתעדים בתצורה ומתואמים עם פרופיל העומס שלכם: סף נוקשה מדי יוצר ניתוקים שווא, סף רך מדי — החזקה ארוכה של צומת מת.
מה יקרה אם המאזן עצמו יהפוך לנקודת כשל יחידה?
מציבים שני צמתים במצב גיבוי חם עם כתובת וירטואלית משותפת: הפעיל משרת את התעבורה, והשני מחזיק את המצב ומקבל את השליטה באובדן הקשר. המעבר אורך שברירי שנייה ואינו דורש פעולות ידניות — הסשנים וטבלאות החיבורים נשמרים הודות לסנכרון.
מה עושים עם התעודות והארכת תוקפן?
ההצפנה מסתיימת במאזן, התעודות מוארכות אוטומטית, והשרשרת נבדקת לפני הפריסה לפרודקשן. החלפת התעודה מתבצעת בלי לנתק חיבורים פעילים: תחילה נקלטת התעודה החדשה, ואחר כך נדחקת הישנה.
האם אפשר לחזור לאחור מהשינויים ולנתח אירוע?
התצורה חיה במערכת בקרת גרסאות, הפריסה עוברת בדיקת תחביר והפעלה מחדש חלקה בלי לקטוע חיבורים. חזרה לאחור — החזרת הגרסה הקודמת בפעולה אחת. לניתוח אירועים אנחנו אוספים יומנים עם חותמות זמן, קודי תגובה וזמן תגובה לכל צומת: מהם רואים היכן החלה ההידרדרות ואיזה צומת גרם לה.
נדון בסכמה שלכם ונחזור עם תוכנית עבודה
כדי שההערכה תהיה עניינית ולא «לפי העין», נדרש מינימום של נתוני מוצא. שלחו את הסכמה הנוכחית של מעבר התעבורה, את תצורת המאזן, את רשימת השירותים מאחוריו ואת דרישות הזמינות — זה מספיק כדי לראות את צווארי הבקבוק ולחזור עם תוכנית עבודה.
אנחנו לא מתחייבים «לעשות הכול» במקומכם: חלק מהמשימות הגיוני להשאיר לצוות הפנימי, וגם את זה נשקף בתוכנית.
מכאן מתקדמים בשלבים, ובכל שלב ברור מה קורה ולשם מה.
- נתוני מוצא: נקודות כניסה, דומיינים, תעודות, שירותי יעד וכללי ניתוב.
- ניתוח הסכמה הנוכחית: כיצד מתפלגת התעבורה, היכן נקודת הכשל היחידה ומה כבר מוגדר ב-HAProxy.
- תוכנית יישום: שינויים שלב אחר שלב עם בדיקה לאחר כל אחד — מעריכת התצורה ועד להעברת התעבורה.
- חלון עבודה: מתאמים מרווח עם השפעה מזערית על המשתמשים וחזרה לאחור מוכנה לתצורה הקודמת.
- ניטור: מדדים, התראות ופאנל למאזן — כדי שהבעיה תיראה לפני שיגיעו הפניות.
- הערכת לוחות זמנים: משך כל שלב ולוח זמנים כולל עם נקודות שבהן נדרש אישור שלכם.
- מסירה: הוראות הפעלה וניתוח מצבים אופייניים עם הצוות שלכם.
תארו את המשימה בצורה חופשית — נחזור עם הערכה, תוכנית והרכב העבודות.