הגדרת שכפול בין-אשכולות של Elasticsearch

דמיינו שיש לכם שני מרכזי נתונים באזורים שונים, ואתם צריכים שחיפוש יעבוד עם זמן השהיה מינימלי מכל מיקום. או שאתם בונים התאוששות מאסון עם RTO של פחות מדקה ו-RPO של 30 שניות. שכפול בין-אשכולות (CCR) ב-Elasticsearch אינו גיבוי או מעבר failover "מוכן מהקופסה", אלא שכפול פעיל חד-כיווני: כל השינויים באינדקס המוביל משוכפלים אוטומטית באינדקס העוקב באשכול מרוחק. אנו מגדירים CCR מוכן לשימוש: מביקורת ועד תיעוד והדרכה. יותר מ-50 פרויקטים של Elasticsearch ב-5 שנים מאפשרים לנו להבטיח תוצאות.

למה יש צורך בשכפול בין-אשכולות (CCR)?

CCR פותר שלושה תרחישים: פיזור גיאוגרפי של חיפוש (קריאה מהאשכול הקרוב ביותר), התאוששות מאסון עם מעבר failover אוטומטי, והרחבת קריאה (הורדת עומס מהמוביל). בניגוד ל-snapshot/restore, פער השכפול הוא שניות, לא דקות. החיסכון ביישום CCR יכול להגיע ל-70% בעלויות תפעוליות בהשוואה לשחזור ידני. הלקוחות שלנו חוסכים עד 80% מזמן ההגדרה בזכות תצורות מוכנות.

איך CCR עובד פנימית?

האינדקס העוקב באשכול היעד קורא כל הזמן פעולות מה-translog של האינדקס המוביל דרך API ייעודי. זה לא snapshot—שינויים משוכפלים בזמן כמעט אמיתי (הפער הוא בדרך כלל 2-5 שניות, תלוי ברשת). דרישות: שני האשכולות באותה גרסה ראשית (עם כמה חריגים לגרסאות משניות) ורישיון Basic ומעלה (Basic מספיק מ-Elasticsearch 7.8+). המדריך הרשמי של Elasticsearch מתאר זאת בפירוט.

השלב הראשון הוא הגדרת האשכול המרוחק באשכול העוקב:

PUT _cluster/settings
{
  "persistent": {
    "cluster.remote.leader-cluster.seeds": [
      "es-master-01.leader.internal:9300",
      "es-master-02.leader.internal:9300",
      "es-master-03.leader.internal:9300"
    ],
    "cluster.remote.leader-cluster.transport.ping_schedule": "30s"
  }
}

בדקו קישוריות. אם PUT _cluster/settings { "persistent": { "cluster.remote.leader-cluster.seeds": [ "es-master-01.leader.internal:9300", "es-master-02.leader.internal:9300", "es-master-03.leader.internal:9300" ], "cluster.remote.leader-cluster.transport.ping_schedule": "30s" } } , תוכלו ליצור אינדקס עוקב.

איך ליצור אינדקס עוקב ו-Auto-Follow?

לאינדקס בודד:

PUT /follower-logs-000001/_ccr/follow
{
  "remote_cluster": "leader-cluster",
  "leader_index": "logs-000001",
  "settings": {
    "index.number_of_replicas": 1
  },
  "max_read_request_operation_count": 5120,
  "max_outstanding_read_requests": 12,
  "max_read_request_size": "32mb",
  "max_write_request_operation_count": 5120,
  "max_write_buffer_count": 512,
  "max_retry_delay": "500ms",
  "read_poll_timeout": "1m"
}

לשכפול אוטומטי של כל האינדקסים החדשים התואמים לתבנית—Auto-follow pattern:

PUT /_ccr/auto_follow/logs-pattern
{
  "remote_cluster": "leader-cluster",
  "leader_index_patterns": ["logs-*"],
  "follow_index_pattern": "{{leader_index}}",
  "settings": {
    "index.number_of_replicas": 1
  }
}

עם auto-follow, כל אינדקס חדש באשכול המוביל התואם לתבנית מקבל אוטומטית אינדקס עוקב באשכול היעד. זה קריטי בשימוש ב-ILM rollover—ללא auto-follow תצטרכו ליצור ידנית אינדקס עוקב לכל אינדקס חדש אחרי rollover.

למה שילוב CCR עם ILM גורם לבעיות?

הבעיה הנפוצה ביותר בהגדרת CCR על גבי ILM היא ש-ILM באשכול המוביל מבצע rollover ו-shrink, ולאשכול העוקב אין זמן לשכפל נתונים לפני שהאינדקס עובר למצב warm/freeze. האינדקס העוקב אז "מפגר" ונתקע. הפתרון הוא להשתמש ב-connected: true לפני shrink במוביל, או להגדיר PUT /follower-logs-000001/_ccr/follow { "remote_cluster": "leader-cluster", "leader_index": "logs-000001", "settings": { "index.number_of_replicas": 1 }, "max_read_request_operation_count": 5120, "max_outstanding_read_requests": 12, "max_read_request_size": "32mb", "max_write_request_operation_count": 5120, "max_write_buffer_count": 512, "max_retry_delay": "500ms", "read_poll_timeout": "1m" } במדיניות ILM באשכול המוביל. לחלופין, שמרו על העוקב במצב "hot" זמן רב יותר על ידי החלת מדיניות ILM נפרדת רק על האשכול העוקב.

באשכול העוקב, האינדקס הוא לקריאה בלבד כברירת מחדל. לפני מעבר היישום לעוקב (במקרה של התאוששות מאסון), יש לקדם אותו לאינדקס רגיל:

POST /follower-logs-000001/_ccr/unfollow 

לאחר מכן, האינדקס הופך לאינדקס רגיל הניתן לכתיבה, אך השכפול מהמוביל נפסק.

איך לנטר שכפול?

GET /follower-logs-000001/_ccr/stats 

בדקו PUT /_ccr/auto_follow/logs-pattern { "remote_cluster": "leader-cluster", "leader_index_patterns": ["logs-*"], "follow_index_pattern": "{{leader_index}}", "settings": { "index.number_of_replicas": 1 } } לעומת CCR pause—ההפרש מראה את הפער בפעולות. אם הפער גדל, יש בעיית רשת או ביצועים בצומת העוקב. התראות Prometheus דרך wait_for_data_replication_timeout:

• POST /follower-logs-000001/_ccr/unfollow צריך לעלות כל הזמן (בדרך כלל > 100 פעולות/שנייה)
• GET /follower-logs-000001/_ccr/stats — השכפול נעצר

קשיים אופייניים בהגדרת CCR

CCR דורש ששני האשכולות יהיו נגישים דרך פורט התעבורה (9300). בענן, זה אומר VPN או VPC Peering בין אזורים—לא פשוט פתיחת פורט 443. זמן השהיה בין אשכולות משפיע ישירות על פער השכפול. במהלך שכפול ראשוני גדול (מאות GB), האינדקס העוקב עובר שלב שחזור דרך snapshot—זה איטי יותר משכפול טרנזקציונלי. יש לקחת זאת בחשבון בתכנון חלון הסנכרון הראשוני (בדרך כלל 1-2 שעות לכל 100 GB).

השוואת CCR לגישות אחרות

CCR עולה על snapshot/restore פי 10-100 ב-RTO ו-RPO, אך דורש רשת מוגדרת כראוי ושילוב ILM.

דרישות רשת ל-CCR

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

תהליך ולוח זמנים

הגדרת CCR מאפס בין שני אשכולות אורכת 2-3 ימים: הגדרת אשכול מרוחק, בדיקת רשת ו-TLS, יצירת תבניות auto-follow, שילוב עם ILM, בדיקת failover (קידום עוקב → מעבר תעבורה → חזרה לאחור). אם האשכול עדיין לא קיים, הוסיפו זמן לפריסתו (1-2 ימים).

העלות מחושבת באופן אישי לאחר ביקורת האשכולות הקיימים ודרישות RTO/RPO. צרו קשר לייעוץ—נשלח הצעה מסחרית תוך יום. פנו אלינו לקבלת הערכה שקופה לפרויקט שלכם. צרו קשר לדיון בפרטים.