1C-Bitrix clustering: אשכול סובלני תקלות במפתח אחד

1C-Bitrix אשכול: אשכול סובלני תקלות במפתח אחד

תארו לעצמכם: חנות המסחר האלקטרוני שלכם על Bitrix קורסת ביום מבצעים — השרת מתחלף, הדפים נטענים תוך 30 שניות, המנהלים מאבדים הזמנות. אפילו שרת יחיד חזק נתקל במגבלות CPU ו-I/O באלפי בקשות בו-זמנית. לצורך הרחבת חנות מסחר אלקטרוני על Bitrix, אנו רואים לעיתים קרובות תמונה כזו אצל לקוחות שמגיעים ל-10,000 מבקרים ביום. הפתרון היחיד הוא הרחבה אופקית: הוספת צמתי אינטרנט במקום שדרוג שרת אחד. רשמית, פונקציה זו זמינה החל מהמהדורה "עסק קטן". עבור Bitrix זה לא רק כפתור "אשכול" — צריך לפתור שלוש משימות מפתח: סשנים, מטמון ואחסון קבצים. הניסיון שלנו של 10 שנים בפיתוח על Bitrix ויותר מ-100 פרויקטי הרחבה מראה: ללא ארכיטקטורה נכונה, תבזבזו שבועות על ניפוי באגים, והתוצאה לא תיתן גידול בביצועים.

שלוש נקודות תורפה שצריך לפתור

איך להגדיר סשנים ב-Redis עבור Bitrix?

Bitrix תומך באופן טבעי באחסון סשנים ב-Redis. התצורה ב-/bitrix/.settings.php:

'session' => [ 'value' => [ 'mode' => 'default', 'handlers' => [ 'general' => [ 'type' => 'redis', 'host' => '127.0.0.1', 'port' => 6379, 'serializer' => \Redis::SERIALIZER_PHP, ], ], ], ], 

לזמינות גבוהה אנו משתמשים ב-Redis Sentinel — כך שבמקרה של תקלת מאסטר, הסשנים לא אובדים. התצורה דומה, פשוט ציינו 'session' => [ 'value' => [ 'mode' => 'default', 'handlers' => [ 'general' => [ 'type' => 'redis', 'host' => '127.0.0.1', 'port' => 6379, 'serializer' => \Redis::SERIALIZER_PHP, ], ], ], ], ו-sentinels. חשוב: התקינו את הרחבת PHP master_name. אנו מעדיפים Redis על פני Memcached בשל פעולות אטומיות ופרסיסטנטיות מובנית. בפרויקט אחד, סשנים ב-Redis הצילו 20,000 עגלות מאובדן בעת מעבר בין מאזני עומס.

העברת מטמון Bitrix ל-Redis

מטמון מנוהל (redis ו-/bitrix/cache/) עדיף לאחסן ב-Redis. זה מאיץ קריאה ומבטל חוסר סנכרון בין צמתים.

'cache' => [
    'value' => [
        'type' => 'redis',
        'redis' => [
            'host' => '127.0.0.1',
            'port' => 6379,
            'serializer' => \Redis::SERIALIZER_IGBINARY,
        ],
    ],
],

הרחבת /bitrix/managed_cache/ דוחסת נתונים בכ-40% מהר יותר מאשר סריאליזציית PHP. עבור מטמון HTML של דפים (לדוגמה, 'cache' => [ 'value' => [ 'type' => 'redis', 'redis' => [ 'host' => '127.0.0.1', 'port' => 6379, 'serializer' => \Redis::SERIALIZER_IGBINARY, ], ], ], ) Redis אינו יעיל בשל גודל האובייקטים — שמרו דפים כאלה ברמת nginx proxy_cache או השאירו אותם על NFS.

למה חשובה שכפול MySQL?

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

'connections' => [
    'value' => [
        'default' => [
            'className' => '\\Bitrix\\Main\\DB\\MysqlConnection',
            'host' => 'mysql-master',
            'database' => 'bitrix',
            'login' => 'bitrix',
            'password' => 'secret',
        ],
        'slave' => [
            'className' => '\\Bitrix\\Main\\DB\\MysqlConnection',
            'host' => 'mysql-slave',
            'database' => 'bitrix',
            'login' => 'bitrix_ro',
            'password' => 'secret_ro',
        ],
    ],
],

לניתוב שקוף של שאילתות אנו משתמשים ב-ProxySQL או ב-Connection Resolver מותאם אישית. זה מפחית עומס על המאסטר ומגדיל את רוחב הפס.

בחירת אחסון קבצים

NFS — פתרון פשוט ל-2-3 צמתים: מתחבר מהר ובעל זמן השהיה נמוך, אך זו נקודת כשל יחידה ללא שכפול. GlusterFS מורכב יותר בהגדרה, אך משכפל נתונים בין צמתים ומבטל SPOF. אחסון תואם S3 (לדוגמה, MinIO) גמיש ואינו דורש שרתים פיזיים, אך זמן ההשהיה גבוה יותר ונדרש מודול bitrix:page.polycore. עבור סביבת ייצור, אנו משתמשים לרוב ב-GlusterFS — הוא כבר הציל לא מעט פרויקטים מהשבתה. דוגמה לחיבור NFS:

mount -t nfs nfs-server:/srv/bitrix-shared /var/www/bitrix/upload 

הגדרת מאזן עומסים

דוגמה לתצורת nginx עם least_conn ובדיקת תקינות

upstream bitrix_backend {
    least_conn;
    server web-node-1:80 weight=1 max_fails=3 fail_timeout=30s;
    server web-node-2:80 weight=1 max_fails=3 fail_timeout=30s;
    server web-node-3:80 weight=1 max_fails=3 fail_timeout=30s;
    keepalive 32;
}

server {
    listen 443 ssl;
    location / {
        proxy_pass http://bitrix_backend;
        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_connect_timeout 5s;
        proxy_read_timeout 60s;
    }
}

עם אחסון נכון של סשנים ב-Redis, אין צורך בסשנים דביקים — כל צומת יכול לטפל בכל בקשה. יוצא דופן: העלאת קבצים בחלקים; לשם כך ניתן להפעיל דביקות לפי IP או להשתמש ב-endpoint נפרד להעלאה.

תהליך העבודה

1. ביקורת — ניתוח הארכיטקטורה הנוכחית, העומס, נקודות התורפה.
2. תכנון — בחירת סכמה: Redis, אחסון, מאזן עומסים, שכפול.
3. הגדרת Redis — סשנים ומטמון, בדיקת סובלנות תקלות.
4. הגדרת אחסון קבצים — NFS או GlusterFS, סנכרון קוד (git/rsync/Ansible).
5. הגדרת מאזן עומסים — nginx upstream, בדיקת תקינות, סיום SSL.
6. שכפול MySQL — Master-Slave + ProxySQL.
7. בדיקות — מבחני עומס, בדיקת התנהגות בעת ניתוק צומת.
8. תיעוד והדרכה — העברת סכמה והוראות.

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

• סכמת ארכיטקטורת אשכול וקבצי תצורה.
• Redis מוגדר (סשנים + מטמון) עם גיבוי דרך Sentinel.
• אחסון קבצים משותף (NFS או GlusterFS) עם חיבור אוטומטי.
• מאזן עומסים nginx עם בדיקת תקינות וסיום SSL.
• שכפול MySQL עם ProxySQL לחלוקת שאילתות.
• בדיקות עומס ודוח ביצועים.
• תיעוד תפעולי וסכמת שחזור לאחר תקלות.
• הדרכת הצוות שלכם בפעולות בסיסיות.
• תמיכה לאחר עלייה לאוויר למשך חודש אחד.

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

הגדרה בסיסית (2 צמתים, Redis, NFS, איזון עומסים) אורכת 2–3 שבועות. סכמת ייצור עם GlusterFS, Redis Sentinel, ניטור ואוטומציה אורכת 4–6 שבועות. העלות מחושבת באופן אישי לאחר ביקורת. החיסכון מוויתור על שדרוגי שרתים יקרים יכול להגיע ל-60%. הפחתת עלויות תשתית השרתים עד 40% בהשוואה לפתרון מונוליטי. הזמינו ביקורת לפרויקט שלכם — המהנדסים שלנו יעריכו את אפשרות ההרחבה תוך יומיים. קבלו ייעוץ לבחירת סכמת האשכול האופטימלית.