איזון עומסים 1C-Bitrix: HAProxy, nginx, מקרים

שני שרתי Bitrix ללא מאזן עומסים

חמישה שרתי Bitrix פועלים, אך האתר מאט בזמני שיא — שרת אחד מטפל ב-80% מהבקשות בעוד השאר יושבים בטלים. ללא Front-End יחיד, חלוקת העומס אינה אחידה, וכשל בשרת בודד מפיל את כל האתר. אנו מגדירים איזון עומסים במפתח מלא: בחירת האלגוריתם, הגדרת בדיקות בריאות, אינטגרציה עם שרת ה-push והפאנל הניהולי. התוצאה היא פעילות יציבה בעומסי שיא וחיסכון בעלויות תשתית של עד 30%.

לדוגמה, עבור חנות מקוונת עם קטלוג של 500,000 מוצרים, הגדרנו HAProxy — זמן התגובה ירד ב-40%, ומספר ההזמנות שאבדו ירד לאפס. עבור פורטל חדשות עם 10,000 משתמשים בו-זמנית, השתמשנו ב-nginx upstream ושילשנו את התפוקה.

מדוע איזון עומסים הוא קריטי עבור Bitrix

ללא איזון עומסים, שרת אחד הופך לעמוס בעוד אחר יושב בטל. בזמני שיא (מבצעים, קידומים), הדבר גורם לזמן קצוב שחולף (timeouts) ולהזמנות שאבדו. מאזן עומסים מחלק בקשות באופן שווה, מגדיל את התפוקה פי 2–3, ומבטיח סובלנות לתקלות: אם צומת אחד נופל, השאר ממשיכים לפעול. בנוסף, האיזון מפחית את העומס על מסד הנתונים באמצעות שמירה במטמון (caching) בכל צומת.

איזה מאזן עומסים לבחור: HAProxy או nginx?

HAProxy הוא מאזן עומסים ייעודי ברמת L4/L7. הוא מטפל בעד 100,000 בקשות בשנייה — פי שניים מ-nginx upstream. HAProxy מספק סטטיסטיקות מפורטות (סטטוסים, תורים) ובדיקות HTTP מותאמות אישית. nginx upstream הוא חלק משרת ה-web, פשוט יותר בתצורה אך פחות גמיש. לפי התיעוד הרשמי של HAProxy, עבור אשכולות של 3 צמתים או יותר, מומלץ להשתמש ב-HAProxy. עבור 2–3 שרתים ומשימות פשוטות, nginx מספיק.

השוואת אלגוריתמי איזון עומסים עבור Bitrix

תצורת HAProxy עבור Bitrix

# /etc/haproxy/haproxy.cfg
global
    maxconn 50000
    log /dev/log local0
    tune.ssl.default-dh-param 2048

defaults
    mode http
    timeout connect 5s
    timeout client 60s
    timeout server 60s
    option http-server-close
    option forwardfor
    log global

# Фронтенд: принимаем HTTPS
frontend bitrix_https
    bind *:443 ssl crt /etc/ssl/site.pem
    http-request set-header X-Forwarded-Proto https
    http-request set-header X-Real-IP %[src]

    # Административный раздел — на выделенный бэкенд
    acl is_admin path_beg /bitrix/admin
    use_backend bitrix_admin if is_admin

    # Push-сервер — отдельный бэкенд с долгими соединениями
    acl is_push path_beg /bitrix/pub
    use_backend bitrix_push if is_push

    default_backend bitrix_web

# Основной бэкенд — веб-ноды
backend bitrix_web
    balance leastconn
    option httpchk GET /bitrix/admin/cluster_check.php
    http-check expect status 200
    server web-01 10.0.0.11:80 check inter 5s rise 2 fall 3 weight 100
    server web-02 10.0.0.12:80 check inter 5s rise 2 fall 3 weight 100
    server web-03 10.0.0.13:80 check inter 5s rise 2 fall 3 weight 100

# Административная панель — только на мастер-ноду
backend bitrix_admin
    server web-01 10.0.0.11:80 check

# Push-сервер
backend bitrix_push
    timeout server 3600s
    server push-01 10.0.0.14:8893 check

# /etc/haproxy/haproxy.cfg global maxconn 50000 log /dev/log local0 tune.ssl.default-dh-param 2048 defaults mode http timeout connect 5s timeout client 60s timeout server 60s option http-server-close option forwardfor log global # Фронтенд: принимаем HTTPS frontend bitrix_https bind *:443 ssl crt /etc/ssl/site.pem http-request set-header X-Forwarded-Proto https http-request set-header X-Real-IP %[src] # Административный раздел — на выделенный бэкенд acl is_admin path_beg /bitrix/admin use_backend bitrix_admin if is_admin # Push-сервер — отдельный бэкенд с долгими соединениями acl is_push path_beg /bitrix/pub use_backend bitrix_push if is_push default_backend bitrix_web # Основной бэкенд — веб-ноды backend bitrix_web balance leastconn option httpchk GET /bitrix/admin/cluster_check.php http-check expect status 200 server web-01 10.0.0.11:80 check inter 5s rise 2 fall 3 weight 100 server web-02 10.0.0.12:80 check inter 5s rise 2 fall 3 weight 100 server web-03 10.0.0.13:80 check inter 5s rise 2 fall 3 weight 100 # Административная панель — только на мастер-ноду backend bitrix_admin server web-01 10.0.0.11:80 check # Push-сервер backend bitrix_push timeout server 3600s server push-01 10.0.0.14:8893 check — בקשות נשלחות בתור-תור. עבור Bitrix עם זמני תגובה משתנים, זה עדיף על balance roundrobin. הפרמטרים leastconn — צומת נחשב חי לאחר שתי בדיקות מוצלחות, ומת לאחר שלושה כשלונות.

nginx upstream כחלופה

upstream bitrix_backends {
    round_robin;
    server 10.0.0.11:80 weight=1 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:80 weight=1 max_fails=3 fail_timeout=30s;
    keepalive 32;
}

server {
    listen 443 ssl;
    location / {
        proxy_pass http://bitrix_backends;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        client_max_body_size 256m;
        proxy_read_timeout 120s;
    }
}

rise 2 fall 3 — חיבורים קבועים בין nginx ל-backend. ללא keepalive, כל בקשה פותחת חיבור TCP חדש ל-PHP-FPM — תקורה מיותרת.

כיצד להגדיר בדיקות בריאות עבור Bitrix?

בדיקת בריאות היא בקשת HTTP המאמתת ש-backend חי. עבור Bitrix אנו משתמשים בסקריפט upstream bitrix_backends { round_robin; server 10.0.0.11:80 weight=1 max_fails=3 fail_timeout=30s; server 10.0.0.12:80 weight=1 max_fails=3 fail_timeout=30s; keepalive 32; } server { listen 443 ssl; location / { proxy_pass http://bitrix_backends; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; client_max_body_size 256m; proxy_read_timeout 120s; } } , שמחזיר 200. HAProxy מוגדר כך:

option httpchk GET /bitrix/admin/cluster_check.php http-check expect status 200 

מרווח בדיקה — כל 5 שניות. לאחר שתי בדיקות מוצלחות הצומת מתאושש, לאחר שלושה כשלונות הוא עובר למצב DOWN. אנו ממליצים גם לבדוק את הפורטים של PHP-FPM ו-MySQL לניטור מלא.

פרוקסי להעלאת קבצים

העלאת קבצים גדולים (מחירים של 100+ MB, סרטונים) דרך המאזן דורשת תצורה:

proxy_request_buffering off; proxy_max_temp_file_size 0; client_max_body_size 512m; proxy_read_timeout 600s; 

ללא keepalive 32, nginx מאגר את כל הקובץ המועלה בזיכרון — עבור קובץ של 512 MB ו-10 העלאות במקביל, מדובר ב-5 GB של זיכרון RAM רק עבור מאגרים.

העברת ה-IP האמיתי ל-Bitrix

Bitrix משתמש ב-IP של המשתמש עבור סשנים והגבלות. ללא תצורה, הוא רואה את ה-IP של המאזן. ב-/bitrix/admin/cluster_check.php הוסיפו:

if (!empty($_SERVER['HTTP_X_REAL_IP'])) { $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_REAL_IP']; } 

HAProxy מעביר את ה-IP האמיתי דרך option httpchk GET /bitrix/admin/cluster_check.php http-check expect status 200 , ו-nginx דרך proxy_request_buffering off; proxy_max_temp_file_size 0; client_max_body_size 512m; proxy_read_timeout 600s; . אנו מסנכרנים את הגדרות המאזן ואת init.php.

מה כלול בהתקנת איזון העומסים

• ביקורת על הארכיטקטורה והעומס הנוכחיים
• בחירת מאזן ואלגוריתם לפי המשימות
• תצורת שרתים (HAProxy/nginx, בדיקות בריאות, keepalived)
• תצורת העברת IP אמיתי וסשנים
• אופטימיזציה של העלאת קבצים ומאגרים
• אינטגרציה עם שרת push והפאנל הניהולי
• בדיקות תחת עומס שיא
• תיעוד הסכימה והפרמטרים
• הדרכה לצוות הניהול
• 30 ימי תמיכה לאחר ההשקה

הניסיון והערבויות שלנו

למעלה מעשור של הגדרת אשכולות 1C-Bitrix. יותר מ-500 פרויקטים מיושמים — מחנויות קטנות ועד קטלוגים גדולים עם מיליוני מוצרים. אנו מבטיחים פעילות יציבה של האשכול ומספקים תמיכה לאחר היישום. קבלו ייעוץ מהנדס וביקורת מפורטת על הארכיטקטורה הנוכחית שלכם. בצעו הזמנה — והאתר שלכם יתמודד עם כל גלי תנועה.