הקמת קלאסטר 1C-Bitrix: איזון עומסים, שכפול, סנכרון

אתם משיקים קמפיין פרסום, אתר ה-1C-Bitrix שלכם מקבל יותר מ-3000 מבקרים בו-זמנית, והשרת קורס. MySQL מגיע ל-100% שימוש במעבד, המטמון מתרוקן כל שתי שניות, והמשתמשים רואים 502 Bad Gateway. נשמע מוכר? הפתרון הטיפוסי הוא אשכול אינטרנט של שלושה צמתים עם איזון עומסים ושכפול מסד נתונים. הגדרה נכונה של אשכול כזה יכולה להתמודד עם עד 10,000 מבקרים, ועלויות התפעול יורדות ב-30-50% בזכות עותקים זולים. לדוגמה, BitrixVM Enterprise עולה $199 לחודש לכל צומת, אבל אשכול של 3 צמתים מפחית את עלויות האירוח החודשיות מ-$500 ל-$250. הגדרנו 50+ אשכולות עם רקורד מוכח ואנחנו יודעים היכן נמצאות המלכודות.

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

מה כולל מודול אשכול האינטרנט

המודול cluster (BitrixVM Enterprise או רישיון נפרד) כולל:

• ניהול צמתים — רישום שרתים, ניטור זמינות.
• איזון עומסים — ניתוב בקשות בין צמתים.
• סנכרון מטמון — ביטול בכל הצמתים דרך Memcached משותף, שהוא מהיר פי 10 ממטמון מבוסס קבצים ומפחית את זמן טעינת הדף ב-40%.
• שכפול קבצים — סנכרון של upload/ בין שרתים.
• שכפול מסד נתונים — הגדרת פיצול קריאה/כתיבה עבור MySQL, הפחתת עומס השרת הראשי ב-60-80%.

תיעוד רשמי של 1C-Bitrix: "מודול האשכול מאפשר לשלב מספר שרתים לאשכול לצורך סובלנות תקלות והרחבה."

כיצד להפעיל ולהגדיר צמתים?

המודול מותקן על כל צומת אך מנוהל דרך לוח ניהול אחד. הוספת צומת דרך API:

\Bitrix\Main\Loader::includeModule('cluster');
$result = \Bitrix\Cluster�ode::add([
    'NAME' => 'web-02',
    'HOST' => '10.0.0.12',
    'PORT' => 443,
    'HTTPS' => 'Y',
    'STATUS' => 'ACTIVE',
    'SORT' => 100,
]);
if ($result->isSuccess()) {
    echo 'Нода добавлена: ' . $result->getId();
}

פיצול קריאה/כתיבה עבור מסד הנתונים

החלק החשוב ביותר באשכול עבור עומס גבוה הוא הפניית שאילתות SELECT לעותקים ושאילתות INSERT/UPDATE/DELETE לשרת הראשי. זה מפחית את עומס השרת הראשי ב-60-80% עם יחס קריאה/כתיבה טיפוסי של 10:1. עם פיצול מוגדר כראוי, זמני התגובה יורדים ב-50%.

ב-\Bitrix\Main\Loader::includeModule('cluster'); $result = \Bitrix\Cluster\Node::add([ 'NAME' => 'web-02', 'HOST' => '10.0.0.12', 'PORT' => 443, 'HTTPS' => 'Y', 'STATUS' => 'ACTIVE', 'SORT' => 100, ]); if ($result->isSuccess()) { echo 'Нода добавлена: ' . $result->getId(); } :

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

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

סנכרון קבצים: מודול מובנה מול lsyncd

המודול המובנה מסנכרן קבצים בין צמתים דרך בקשות HTTP לסוכנים. כאשר קובץ מועלה על node-1, המודול מעתיק אותו אוטומטית ל-node-2 ול-node-3. כדי להגן על הסוכן, הגבילו גישת IP ב-Nginx: .settings.php.

חלופה היא inotify + rsync דרך lsyncd. זה מהיר ואמין יותר עבור נפחים גדולים. דוגמת קונפיגורציית lsyncd:

sync {
  default.rsync,
  source = "/var/www/bitrix/upload",
  target = "web-02:/var/www/bitrix/upload",
  delay = 1,
  rsync = {
    compress = false,
    owner = true,
    perms = true,
  }
}

למה לאחסן סשנים ב-Memcached?

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

דוגמת קונפיגורציית PHP עבור Memcached:

session.save_handler = memcached session.save_path = "10.0.0.30:11211,10.0.0.31:11211" 

השוואת מאזני עומסים עבור אשכול אינטרנט של 1C-Bitrix

כיצד לוודא פעולת אשכול?

השתמשו בסקריפט shell לבדיקת מצב הצמתים וניקוי מטמון:

# Проверка статуса нод
curl http://admin:[email protected]/bitrix/admin/cluster_nodes.php?ajax=Y
# Очистка кэша на всех нодах
php -r "\Bitrix\Main\Loader::includeModule('cluster'); \Bitrix\Cluster\Cache::clearAll(); echo 'Cache cleared';"

מדריך הגדרת אשכול אינטרנט שלב אחר שלב

1. התקינו BitrixVM Enterprise על כל צומת.
2. הגדירו שכפול MySQL: master-slave.
3. בלוח הניהול של Bitrix, הוסיפו צמתים דרך מודול האשכול.
4. הגדירו פיצול קריאה/כתיבה ב-'connections' => [ 'value' => [ 'default' => [ 'className' => '\Bitrix\Main\DB\MysqlConnection', 'host' => 'db-master:3306', 'database' => 'bitrix', 'login' => 'bitrix', 'password' => 'secret', ], 'slave' => [ 'className' => '\Bitrix\Main\DB\MysqlConnection', 'host' => 'db-replica:3306', 'database' => 'bitrix', 'login' => 'bitrix_ro', 'password' => 'secret_ro', ], ], ], .
5. בחרו שיטת סנכרון קבצים: מובנית או lsyncd.
6. העבירו סשנים ל-Memcached או Redis.
7. הגדירו את מאזן העומסים (nginx, haproxy, או ענן LB).
8. ודאו פונקציונליות דרך allow 10.0.0.0/24; deny all;.

טעויות הגדרה טיפוסיות

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

עבור פרויקט בינוני (עד 5000 מבקרים), 2-3 צמתים מספיקים. עבור עומס גבוה (מעל 10,000), נדרשים 5+ צמתים עם חלוקת מסד נתונים.

למדו עוד על המושג אשכולות בויקיפדיה.

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