הגדרת קלאסטר Bitrix24 On-Premise: זמינות גבוהה, איזון עומסים ואופטימיזציית ביצועים

כאשר שרת אחד כבר לא מספיק — וזה קורה ב-150–200 משתמשים בו-זמנית או כשמסד הנתונים גדל מעבר ל-50 ג"ב — עולה השאלה של הרחבה אופקית.

אנחנו, מהנדסי Bitrix מוסמכים עם 7 שנות ניסיון, לאחר שהקמנו למעלה מ-50 קלאסטרים למגזר הארגוני (מ-3 עד 12 צמתים), מגדירים קלאסטר Bitrix24 On-Premise במפתח מלא: מביקורת התשתית הנוכחית ועד פריסת קלאסטר מוכן לייצור עם אחריות לאפס זמן השבתה. האחריות שלנו: הקלאסטר מתמודד עם עומסי שיא ללא פגיעה בביצועים, וזמן התגובה אינו עולה על 300 אלפיות השנייה עם 500 משתמשים בו-זמנית. ארכיטקטורת שרת יחיד היא סיכון. כשל שרת, התחממות מסד נתונים, אובדן סשנים — כל אלה עוצרים את פעילות הפורטל. קלאסטרינג מבטל סיכונים אלה: כשל של כל רכיב אינו משפיע על הזמינות, והביצועים גדלים באופן ליניארי. אנו משתמשים רק ברכיבים מוכחים — HAProxy, GlusterFS, Redis Sentinel — ומקימים ניטור מבוסס Prometheus ו-Grafana.

למה קלאסטרינג? בעיות וארכיטקטורה

• נקודת כשל יחידה (SPOF) — כשל של כל צומת אינו משפיע על הזמינות.
• עומס יתר על מסד הנתונים — פיצול master-slave מפחית את עומס הכתיבה בעד 40%.
• אובדן סשנים בעת מעבר בין צמתים — סשנים דביקים ואחסון Redis משותף.

קלאסטר ייצור טיפוסי מורכב מהרכיבים הבאים:

[Load Balancer: nginx/HAProxy]
|
┌────┴────┐
[Web 1] [Web 2] ← Серверы приложений (PHP/nginx)
└────┬────┘
|
[Shared Storage: NFS/GlusterFS] ← Общий диск для файлов
|
┌────┴────┐
[DB Master] ← [DB Replica] ← MySQL/MariaDB репликация
|
[Redis Sentinel/Cluster] ← Кэш и сессии

ללא אחסון קבצים משותף, קלאסטר לא עובד: אם משתמש העלה קובץ ל-Web 1, והבקשה הבאה מגיעה ל-Web 2, הקובץ נעלם. NFS היא האפשרות הפשוטה ביותר, GlusterFS הוא חסין תקלות. אנו משתמשים ב-GlusterFS לאחסון משותף מכיוון שהוא מספק שכפול וזמינות גבוהה. החלופה היא NFS עם יתירות DRBD.

שלבי הגדרה עיקריים

כיצד להגדיר מאזן עומסים לסשנים דביקים?

הגדרה נכונה של מאזן העומסים היא קריטית לפעולה יציבה של הקלאסטר. nginx עם ip_hash עובד עבור רשתות משרדיות שבהן כתובות ה-IP של המשתמשים יציבות. עבור משתמשים ניידים, HAProxy עם התמדת קובצי Cookie עדיף — הוא לא מאבד סשנים בעת שינוי IP. המודול nginx_sticky_module הוא פשרה אך דורש בניית nginx עם המודול. HAProxy מספק את האמינות והגמישות הגבוהות ביותר בשקלול שרתי backend.

backend bitrix24_backend
    balance roundrobin
    cookie SERVERID insert indirect nocache
    server web1 10.0.1.10:443 check cookie web1
    server web2 10.0.1.11:443 check cookie web2

הגדרת שכפול MySQL

שכפול Master-Slave לשאילתות קריאה. הגדרה על ה-master וה-replica:

-- На мастере: создать пользователя репликации
CREATE USER 'replicator'@'db-replica' IDENTIFIED BY 'strong_password';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'db-replica';

-- В my.cnf мастера
[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = bitrix24

-- В my.cnf реплики
[mysqld]
server-id = 2
relay_log = /var/log/mysql/mysql-relay-bin.log
read_only = 1

יש לומר ל-Bitrix24 במפורש ששאילתות קריאה צריכות לעבור ל-replica. הגדרה ב-[Load Balancer: nginx/HAProxy] | ┌────┴────┐ [Web 1] [Web 2] ← Серверы приложений (PHP/nginx) └────┬────┘ | [Shared Storage: NFS/GlusterFS] ← Общий диск для файлов | ┌────┴────┐ [DB Master] ← [DB Replica] ← MySQL/MariaDB репликация | [Redis Sentinel/Cluster] ← Кэш и сессии :

'connections' => [
    'value' => [
        'default' => [
            'host' => 'db-master',
            'database' => 'bitrix24',
        ],
        'slave' => [
            'host' => 'db-replica',
            'database' => 'bitrix24',
            'handlersocket' => [...],
        ],
    ],
],

חשוב לנטר את הפיגור בשכפול — קריטי לפעולה נכונה. פיגור מעל 30 שניות צריך להפעיל אזעקה.

למה יש צורך ב-Redis Cluster לסשנים?

סשנים של משתמשים חייבים להיות מאוחסנים ב-Redis משותף, לא בדיסק המקומי של כל צומת web:

// /bitrix/.settings.php — настройка Redis
'cache' => [
  'value' => [
    'type' => [
      'class_name' => '\Bitrix\Main\Data\CacheEngineRedis',
      'extension' => 'redis',
    ],
    'redis' => [
      'host' => 'redis-sentinel',
      'port' => 26379,
    ],
  ],
],
'session' => [
  'value' => [
    'mode' => 'redis',
    'redis' => [
      'host' => 'redis-sentinel',
      'port' => 26379,
    ],
  ],
],

Redis Sentinel במקום Redis יחיד — למעבר אוטומטי במקרה של כשל ב-master. Sentinel מבטיח זמינות של 99.9%, שהיא אמינה פי 10 מ-Redis יחיד. התיעוד הרשמי של 1C-Bitrix ממליץ להשתמש ב-Redis Sentinel לפורטלים קריטיים.

ניטור קלאסטר

קלאסטר ללא ניטור הוא קלאסטר שיתקלקל בערב שישי, ותגלו זאת מהמשתמשים, לא ממערכת ההתראות. בנוסף, אנו ממליצים להגדיר התראות ב-Telegram/Slack.

תהליך

1. ביקורת תשתית ועומסים נוכחיים (זיהוי צווארי בקבוק).
2. תכנון ארכיטקטורת הקלאסטר (מאזני עומסים, מסד נתונים, מטמון).
3. פריסת מאזני עומסים (nginx/HAProxy) עם סשנים דביקים.
4. הגדרת שכפול MySQL Master-Slave עם ניטור פיגור.
5. פריסת Redis Sentinel או Cluster לסשנים ומטמון.
6. ארגון אחסון משותף (GlusterFS/NFS).
7. הקמת ניטור (Prometheus + Grafana) עם ספים והתראות.
8. תיעוד תצורות ונהלי runbook.
9. הכשרת צוות התפעול שלכם לניהול הקלאסטר.
10. מתן תמיכה 24/7 בחודש הראשון לאחר העלייה לאוויר.

טעויות נפוצות וכיצד להימנע מהן

• סשנים דביקים לא הוגדרו — משתמשים מאבדים עגלות ונתוני התחברות. פתרון: השתמשו ב-HAProxy עם התמדת קובצי Cookie.
• פיגור בשכפול לא מנוטר — קריאת נתונים מיושנים. פתרון: נטר את הפיגור וחיבור מחדש אוטומטי.
• Redis ללא Sentinel — אם Redis נופל, כל הסשנים אובדים. פתרון: השתמשו ב-Sentinel או Cluster.
• מטמון משותף בין צמתים — בעיות invalidation. פתרון: המטמון המתויג של Bitrix24 עובד נכון רק עם Redis משותף.

מה כלול

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

לוחות זמנים ועלות

לוחות זמנים להקמת קלאסטר: מ-5 ימי עסקים לתצורה בסיסית (2 צמתי web, מסד נתונים master-slave, Redis) ועד 20 ימי עסקים לקלאסטר מלא עם ניטור ותיעוד. העלות נקבעת באופן אישי לאחר ביקורת, אך פרויקטים טיפוסיים נעים בין $5,000 ל-$15,000 בהתאם למורכבות. לפי התיעוד הרשמי של Bitrix, קלאסטרינג מפחית את זמן ההשבתה ב-99% בהשוואה להגדרות שרת יחיד. קבלו ייעוץ לגבי הרחבת Bitrix24 On-Premise.