HAProxy + Keepalived: הגדרת מאזן עומסים סובלני לתקלות

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

היכולות שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

HAProxy + Keepalived: בניית מאזן עומסים סובלני לתקלות

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

מצב טיפוסי: אתה מריץ מיקרוסרביסים על פני מספר שרתים, אך כל מאזן עומסים נותר נקודת כשל יחידה. קריסה אחת ברמת הרשת — וכל היישום הופך לבלתי זמין. הפתרון הוא צרור של HAProxy 2.8+ ו-Keepalived 2.2+ עם VRRP: הראשון מאזן תעבורה, השני מחזיק כתובת IP וירטואלית ומעביר אותה אוטומטית לצומת גיבוי אם הפעיל נכשל. ארכיטקטורה זו נותנת זמן מעבר של 1-3 שניות וחיסכון של עד 70% בהשוואה למאזני עומסים בענן בעומסים יציבים החל מ-10,000 בקשות בשנייה. לדוגמה, פרויקט עם 10,000 בקשות בשנייה חוסך $5,000 בשנה. לקוח אחר עם 50,000 בקשות בשנייה חסך $24,000 בשנה הראשונה.

צוות מהנדסי DevOps מוסמכים שלנו עם ניסיון של 10+ שנים השלים למעלה מ-50 פרויקטים של הגדרת תכניות כאלה. אנו מקימים את כל המערכת: שני שרתים פיזיים או וירטואליים עם HAProxy, Keepalived וסנכרון מצב. הלקוח תמיד ניגש ל-VIP, אשר שוכן על הצומת הבריא. במאמר זה אראה את התצורה שבה אנו משתמשים בייצור — עם תזמונים אמיתיים, בדיקות בריאות ושכפול סשנים.

כיצד VRRP מבטיח מעבר תקלות

Keepalived משתמש בפרוטוקול VRRP. לפי RFC 5798, הצומת הפעיל (MASTER) שולח הודעות multicast במרווח של weight (ברירת מחדל שנייה אחת). צומת הגיבוי (BACKUP) מאזין להודעות אלה. אם BACKUP לא מקבל אותן במשך שלושה מרווחים, הוא עובר ל-MASTER ותופס את ה-IP הווירטואלי באמצעות סקריפטים של notify. זמן המעבר הוא כ-1-3 שניות. זה מספיק עבור רוב היישומים.

הפרמטר vrrp_script chk_haproxy ב-peers haproxy_peers peer haproxy1 10.0.0.1:1024 peer haproxy2 10.0.0.2:1024 backend app_servers balance roundrobin stick-table type ip size 200k expire 30m peers haproxy_peers stick on src מאפשר שינויי עדיפות דינמיים. אם HAProxy על ה-MASTER מת, הסקריפט מפחית את העדיפות ב-30 (משקל -30), ו-BACKUP הופך ל-MASTER גם אם maxconn 50000 לא הופעל. זה מונע מצב שבו HAProxy מת אך ה-VIP נשאר עליו.

מדוע HAProxy Peers קריטיים לסשנים דביקים

אם אתה משתמש באפיניות סשן (סשנים דביקים), טבלת הסשנים מאוחסנת מקומית על כל צומת. כאשר הצומת הפעיל נכשל, הטבלה אובדת, וכל הלקוחות מופנים לשרתים חדשים — סשנים נשברים. HAProxy Peers משכפל stick-tables בין צמתים באמצעות UDP בזמן אמת.

דוגמה לתצורת peers:

peers haproxy_peers
    peer haproxy1 10.0.0.1:1024
    peer haproxy2 10.0.0.2:1024

backend app_servers
    balance roundrobin
    stick-table type ip size 200k expire 30m peers haproxy_peers
    stick on src

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

תצורה וניואנסים

הגדרת HAProxy תחת עומס דורשת התחשבות בפרמטרים רבים. לדוגמה, httpchk GET /healthz — הגבול של חיבורים בו-זמניים; חריגה ממנו תפיל חיבורים חדשים. אנו ממליצים להשתמש ב-global_defs { router_id haproxy1 enable_script_security } vrrp_script chk_haproxy { script "killall -0 haproxy" interval 2 weight -30 } vrrp_instance VI_HAPROXY { state MASTER interface ens3 virtual_router_id 60 priority 200 advert_int 1 authentication { auth_type PASS auth_pass hapassword } virtual_ipaddress { 10.0.1.100/24 dev ens3 label ens3:vip } track_script { chk_haproxy } notify_master "/etc/keepalived/haproxy-master.sh" notify_backup "/etc/keepalived/haproxy-backup.sh" } בציפייה ל-200 OK כדי להחריג שרתים שנכשלים בבדיקות בריאות.

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

תצורת Keepalived על MASTER:

global_defs {
  router_id haproxy1
  enable_script_security
}

vrrp_script chk_haproxy {
  script "killall -0 haproxy"
  interval 2
  weight -30
}

vrrp_instance VI_HAPROXY {
  state MASTER
  interface ens3
  virtual_router_id 60
  priority 200
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass hapassword
  }
  virtual_ipaddress {
    10.0.1.100/24 dev ens3 label ens3:vip
  }
  track_script {
    chk_haproxy
  }
  notify_master "/etc/keepalived/haproxy-master.sh"
  notify_backup "/etc/keepalived/haproxy-backup.sh"
}

על BACKUP — אותם פרמטרים אך state BACKUP ו-priority 100. סקריפטים של notify מפעילים את HAProxy אם הוא לא רץ. לאמינות מקסימלית, אנו משתמשים ב-keepalived -D ומקימים ניטור באמצעות Prometheus + Alertmanager.

השוואה: HAProxy+Keepalived מול מאזני עומסים בענן

קריטריון HAProxy+Keepalived (on-prem) מאזן עומסים בענן (AWS/GCP)
עלות בעומסים גבוהים קבועה (אחסון + רישיון) תשלום לפי תעבורה + לפי שעה
חביון (p99) < 10 µs (bare-metal) 50-200 µs (וירטואליזציה)
שליטה מלאה (configs, גרסאות) מוגבלת (API, קונסולה)
מעבר תקלות 1-3 שניות 5-30 שניות (תלוי ב-DNS/Anycast)

החיסכון הזה אינו תיאורטי: אחד הלקוחות שלנו הפחית עלויות ב-65%, וחסך $12,000 בשנה לאחר מעבר מ-AWS NLB ל-HAProxy+Keepalived מקומי.

שלבי התחלה מהירים

  1. התקן HAProxy 2.8 מהמאגר הרשמי.
  2. הגדר /etc/haproxy/haproxy.cfg עם האפשרויות לעיל.
  3. התקן Keepalived 2.2 מ-EPEL.
  4. הגדר /etc/keepalived/keepalived.conf כפי שמוצג.
  5. הפעל והתחל את שני השירותים.
  6. בדוק מעבר תקלות על ידי עצירת HAProxy על ה-master.

רשימת בדיקה לאימות תצורה

  • ודא ש-HAProxy maxconn מוגדר לפחות לשיא הצפוי של מספר החיבורים.
  • אמת בדיקת בריאות: httpchk GET /healthz מחזיר 200.
  • הגדר slowstart 30s עבור backends כדי למנוע עומס יתר בהתאוששות.
  • הגדר vrrp_script chk_haproxy עם משקל -30 לעדיפות דינמית.
  • הפעל HAProxy Peers לשכפול stick-table.
  • בדוק מעבר תקלות: עצור HAProxy על MASTER, מדוד את זמן המעבר.

מה כלול בעבודה

  1. ביקורת תשתית. ניתוח תעבורה נוכחית, דרישות ביצועים, זיהוי צווארי בקבוק.
  2. עיצוב ארכיטקטורה. בחירת אלגוריתם איזון, הגדרת בדיקות בריאות ספציפיות ליישום שלך, חישוב פרמטרי Keepalived.
  3. יישום. התקנה והגדרה של HAProxy (כולל סיום SSL, HTTP/2, slowstart), הגדרת Keepalived עם VRRP וסקריפטים של notify, שילוב HAProxy Peers לסשנים דביקים.
  4. בדיקת מעבר תקלות. סימולציה של תקלות: עצירת HAProxy, הפסקת רשת, קריסת צומת. אימות זמן מעבר ושלמות סשנים.
  5. תיעוד והדרכה. מסירת דיאגרמת רשת, configs, runbook למהנדס תורן. הדרכה בניהול וניטור (stats endpoint, socat).

הערכות זמנים

משימה משך
HAProxy + Keepalived, תכנית בסיסית יום אחד
סיום SSL + בדיקות בריאות + peers 1-2 ימים
בדיקת מעבר תקלות + תיעוד +0.5 יום

העלות של הקמה turnkey מתחילה מ-$720–1k (כ-$1,000), מאושרת לאחר ביקורת. המהנדסים המוסמכים שלנו עם עשר שנות ניסיון מבטיחים SLA של 99.9% עבור מאזן העומסים. החיסכון בתשתית מגיע עד 70% בהשוואה לפתרונות ענן בעומס יציב.

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