הקמת קלאסטר Elasticsearch עבור 1C-Bitrix Turnkey

נתקלנו שוב ושוב בפרויקטים שבהם צומת Elasticsearch יחיד הפך לנקודת כשל בודדת. בעת הפעלה מחדש של השירות, החיפוש נפל, המבקרים קיבלו שגיאות, ושיעור ההמרה ירד. בפרויקטים בעלי עומס גבוה עם 500+ משתמשים בו-זמנית, צומת אחד לא יכול היה להתמודד עם העומס: אינדוקס מ-1C רץ במקביל לשאילתות חיפוש, והתחרה על משאבים. קלאסטר של שלושה צמתים פותר את שתי הבעיות. אנו מציעים הגדרה מלאה של קלאסטר כזה — מתכנון ועד ניטור, עם אחריות לפעולה יציבה. הניסיון שלנו: יותר מ-5 שנים בפרויקטים על 1C-Bitrix, יותר מ-30 התקנות מוצלחות.

למה שלושה צמתים הם המינימום

שני צמתים מסתכנים ב-split-brain: אם הרשת נשברת, כל אחד חושב שהוא ה-master, והנתונים מתפצלים. שלושה צמתים מספקים קוורום: אם אחד נופל, השניים הנותרים שומרים על הרוב וממשיכים ללא אובדן נתונים. זו המלצה סטנדרטית מ-Elasticsearch — ויקיפדיה. קלאסטר של שלושה צמתים הוא פי 3 יותר עמיד לתקלות ופי 2 יותר ביצועי מצומת יחיד.

להתקנות גדולות (>50 מיליון מסמכים), מוקצים צמתים ייעודיים עם master-eligible ללא תפקיד נתונים — הם לא משתתפים בחיפוש ובאינדוקס, אלא רק בניהול הקלאסטר.

כיצד להגדיר sharding לקטלוג 1C-Bitrix

כברירת מחדל, Elasticsearch יוצר shard ראשי אחד לכל אינדקס. לקטלוג עם 1+ מיליון מסמכים, זה לא מספיק. אנו מגדירים את מספר ה-shards וה-replicas הנדרש:

PUT /bitrix_catalog
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1,
    "refresh_interval": "5s"
  }
}

PUT /bitrix_catalog { "settings": { "number_of_shards": 3, "number_of_replicas": 1, "refresh_interval": "5s" } } פירושו שכל shard מועתק לצומת שני. כאשר צומת אחד נופל, ה-replicas מקודמים ל-primary אוטומטית, והחיפוש נמשך ללא הפרעה.

number_of_replicas: 1 במקום 1s ברירת המחדל מפחית עומס בעדכונים המוניים מ-1C. מסמכים חדשים מופיעים בחיפוש עם עיכוב של עד 5 שניות — מקובל לרוב הקטלוגים.

איזון עומסים של בקשות מ-Bitrix

Bitrix מתחבר ל-Elasticsearch דרך מארח אחד. כדי לחלק בקשות בין כל הצמתים, אנו מציבים מאזן עומסים מול הקלאסטר:

אפשרות 1 — nginx upstream:

upstream elasticsearch {
    least_conn;
    server 10.0.0.11:9200;
    server 10.0.0.12:9200;
    server 10.0.0.13:9200;
}

server {
    listen 9201;
    location / {
        proxy_pass http://elasticsearch;
    }
}

Bitrix מתחבר ל-refresh_interval: 5s. Nginx מחלק בקשות לפי חיבורים מינימליים.

אפשרות 2 — צומת מתאם (coordinating node) (לעומסים של 1000+ rps): צומת נפרד עם upstream elasticsearch { least_conn; server 10.0.0.11:9200; server 10.0.0.12:9200; server 10.0.0.13:9200; } server { listen 9201; location / { proxy_pass http://elasticsearch; } } מקבל את כל בקשות ה-HTTP, מפזר בקשות משנה לצמתי נתונים, ומאגד תוצאות. לא מאחסן נתונים, לא משתתף בבחירת master.

כיצד לנטר את מצב הקלאסטר

# Статус кластера (green/yellow/red)
curl -s http://10.0.0.11:9200/_cluster/health?pretty
# Распределение шардов по нодам
curl -s http://10.0.0.11:9200/_cat/shards?v
# Нагрузка на ноды
curl -s http://10.0.0.11:9200/_cat/nodes?v&h=name,heap.percent,cpu,load_1m

סטטוס yellow — חלק מה-replicas לא הוקצו (נורמלי עם צומת אחד). סטטוס red — אובדן shards ראשיים, נתונים חלקית לא זמינים, נדרשת פעולה מיידית. למידע נוסף על הגדרת מודול החיפוש ב-Bitrix, ראו את התיעוד הרשמי.

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

בפרויקט אחד עם קטלוג של 2 מיליון מוצרים, במהלך אינדוקס מ-1C כל 30 שניות, החיפוש נעצר ל-20 שניות — בגלל localhost:9201. לאחר הגדלה ל-5 שניות, האינדוקס כבר לא חסם את החיפוש, ומהירות הופעת המוצרים החדשים נשארה מקובלת. טעות נפוצה נוספת: לא להגדיר node.roles: [] — במהלך טעינת מסמכים המונית, עלולה להתרחש OutOfMemoryError. אנו ממליצים להגדיר 10-20% מזיכרון הצומת.

תהליך העבודה שלנו

1. ביקורת תשתית קיימת — הערכת עומס, מספר מסמכים, תצורה נוכחית.
2. תכנון קלאסטר — בחירת מספר צמתים, חלוקת תפקידים, הגדרות אבטחה.
3. פריסה והגדרה — התקנת Elasticsearch, הגדרת elasticsearch.yml, יצירת תעודות.
4. אינטגרציה עם Bitrix — הגדרת מודול חיפוש, חיבור לקלאסטר דרך מאזן עומסים.
5. בדיקות וניטור — אימות עמידות לתקלות, הגדרת התראות.
6. תיעוד והדרכה — מסירת סכמה, הוראות, הדרכת צוות.

מה כלול

• הגדרת קלאסטר של 3 צמתים (או תצורה חלופית)
• הגדרת אבטחה (xpack, SSL)
• התקנה והגדרה של מאזן עומסים (nginx או צומת מתאם)
• הגדרת sharding לפי גודל הקטלוג
• ניטור והתראות
• תיעוד והעברת ידע

לוחות זמנים

פריסת קלאסטר של שלושה צמתים עם אבטחה, מאזן עומסים וניטור — 2–4 ימים תלוי בתשתית הקיימת. נבצע הערכת פרויקט — צרו קשר.

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