הגדרת Hetzner Cloud Load Balancer כפתרון מלא תוך יום

הגדרת Hetzner Cloud Load Balancer: היכן נשברת העמידות בפני תקלות

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

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

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

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

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

אפקט מדיד: זמן התאוששות, השבתות, עמידות בפני תקלות

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

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

מה כדאי להשוות בדוח לאחר המסירה:

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

מצבי איזון ובדיקות מצב: מה ומתי מתאים

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

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

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

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

סדר היישום: מביקורת התצורה ועד מסירה לתפעול

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

1. ביקורת תשתית. אוספים את התצורה הנוכחית: אילו שירותים חשופים החוצה, כיצד מתחלקות הכתובות, היכן נמצאות התעודות וכיצד נבדקת כעת זמינות הצמתים. בנפרד רושמים נקודות כשל — צומת בודד ללא רזרבה, החלפות ידניות, היעדר בקרת מצב של שרתי האפליקציות.
2. תכנון תצורת האיזון. קובעים את מיקום מאזן העומסים ביחס לאזורים, הרכב קבוצות היעד, אלגוריתם הפיזור, מרווחי וספי בדיקות המצב, התנהגות בעת כשל צומת. כאן גם מחליטים היכן מעובדת תעבורה מאובטחת ואילו כללי הפניה נדרשים.
3. הכנת רשת והרשאות. רשתות פרטיות, כללי סינון, הרשאות מהנדסים ומערכות ניטור — את הכול סוגרים לפני שתעבורה מבצעית תתחיל לזרום.
4. הגדרת המתאר. מגדירים Hetzner Cloud Load Balancer, קבוצות יעד, בדיקות מצב, תעודות ותיעוד יומנים. התצורה נשמרת כקוד: שינוי עובר בדיקה ומבוטל בפעולה אחת.
5. בדיקה תחת עומס. מריצים תרחישים של גידול בחיבורים מקבילים, כשל של צומת אחד, ירידת ביצועי שירות ופרץ תעבורה. בודקים תוך כמה זמן הפיזור מתארגן מחדש וכיצד מתנהגים השיהויים.
6. העלאה לתפעול. מחליפים תעבורה בהדרגה, עם אפשרות לחזור לתצורה הקודמת. מדדי שיהוי ושגיאות נלקחים לפני ואחרי — כדי לראות את האפקט, לא לשער אותו.
7. מסירת תיעוד. מוסרים תצורה, הוראות תפעול וחזרה לאחור, תיאור התראות וסדר פעולות בעת כשל, כדי שהמהנדס של הלקוח יוכל לנתח אירוע בלעדינו.

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

תצורות, כללי בדיקות ותיעוד למסירה

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

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

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

איך היה לפני העבודה

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

התורן למד על הבעיה מתלונות, הרים חלופה ותיקן רשומות ידנית — 6-8 פעולות לאירוע ועד 20 דקות של ירידת ביצועים תחת עומס.

מה שינו

את נקודת הכניסה העברנו מ-DNS אל Hetzner Cloud Load Balancer, הצמתים הוכרזו בקבוצת יעד והוגדרו בדיקות בריאות לפי מטפל האפליקציה, לא לפי פורט פתוח. הסף — שתי בדיקות כושלות ברצף, הוצאת הצומת מהסבב לפני עצירת השירות, כדי שחיבורים פעילים יגיעו לסיומם. הוספנו תבנית לפריסת צומת חדש וחיבור אוטומטי שלו לקבוצה.

מה נהיה

• החלפה בעת כשל צומת — 12-15 שניות במקום 20 דקות וללא מעורבות אדם.
• שיעור הבקשות המוצלחות ברגע האירוע — 99.9% לעומת 96%; לא נותרו קטיעות של סשני משתמשים במעבר.
• פעולות ידניות של התורן לאירוע — אפס במקום 6-8: ההתראה מגיעה כשהסבב כבר בוצע.

מאזן עומסים בענן או שרת משל עצמכם עם איזון: מה לבחור

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

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

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

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

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

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

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

מה עם מגבלות החיבורים?

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

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

האם אפשר לעבור ללא השבתה?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

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