כאשר עוברים לארכיטקטורה מבוזרת גיאוגרפית, רבים נתקלים באתגר שקבוצת Cassandra הפועלת במרכז נתונים יחיד אינה יכולה עוד לעמוד בדרישות העומס או הסובלנות לתקלות. אנו מסייעים בהקמת תצורה מרובת מרכזי נתונים במפתח פתרון מלא — היא יכולה לעמוד באובדן של מרכז נתונים שלם ללא אובדן נתונים או השבתה. הניסיון שלנו: 5+ שנים, מעל 30 פרויקטים עם Cassandra מרובת מרכזי נתונים. במהלך זמן זה, צברנו מתודולוגיות המונעות טעויות נפוצות: בחירה שגויה של snitch, צמתי seed שגויים, ורמות עקביות לא אופטימליות. אנו נעריך את הפרויקט שלך ונציע ארכיטקטורה המותאמת לדרישות RPO ו-RTO שלך.
Cassandra מרובת מרכזי נתונים אינה רק "הצבת צמתים בשני מיקומים." זהו תחום נפרד: בחירת snitch, אסטרטגיית שכפול, עקביות שאילתות, טיפול במחיצות רשת בין מרכזי נתונים. ללא הבנה של משפט CAP בהקשר של Cassandra, קבוצה מרובת מרכזי נתונים הופכת למכונה לייצור תורי hint ונתונים מיושנים. להלן, אנו מפרקים את ההיבטים המרכזיים של תצורה מרובת מרכזי נתונים.
כיצד להבטיח יתירות גיאוגרפית?
עבור מרכז נתונים יחיד, נעשה שימוש ב-SimpleStrategy. עבור תצורה מרובת מרכזי נתונים, רק NetworkTopologyStrategy. היא מאפשרת להגדיר גורמי שכפול שונים עבור כל מרכז נתונים:
CREATE KEYSPACE app_data WITH REPLICATION = { 'class': 'NetworkTopologyStrategy', 'DC1': 3, 'DC2': 3 }; RF=3 בכל מרכז נתונים פירושו: הקבוצה תשרוד אובדן מלא של מרכז נתונים אחד ללא אובדן נתונים. עם DC1 באמסטרדם ו-DC2 בפרנקפורט — זו יתירות גיאוגרפית אמיתית. השווה: שימוש ב-CREATE KEYSPACE app_data WITH REPLICATION = { 'class': 'NetworkTopologyStrategy', 'DC1': 3, 'DC2': 3 }; , אובדן מרכז נתונים אחד יגרום לאובדן כל הנתונים בו.
איזה Snitch לבחור לייצור?
Cassandra חייבת לדעת באיזה מרכז נתונים ומדף כל צומת נמצא. זו העבודה של ה-snitch. SimpleStrategy היא הבחירה הסטנדרטית לייצור. כל צומת קורא את GossipingPropertyFileSnitch:
dc=DC1 rack=RACK1 ב-/etc/cassandra/cassandra-rackdc.properties על כל הצמתים, ציין את אותו שם קבוצה ו-seeds משני מרכזי הנתונים:
---
cluster_name: 'global-cluster'
endpoint_snitch: GossipingPropertyFileSnitch
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: "10.0.1.10,10.0.1.11,10.1.1.10,10.1.1.11"
---ה-seeds חייבים להיות בשני מרכזי הנתונים — זה חשוב לאתחול צמתים חדשים ולשחזור לאחר split-brain.
למה לבחור ב-LOCAL_QUORUM?
כאן מתחילות ההחלטות הארכיטקטוניות האמיתיות. dc=DC1 rack=RACK1 מתחשב ב-quorum מכל הרפליקות בכל מרכזי הנתונים. עם RF=3 בשני מרכזי נתונים (6 רפליקות בסך הכל) — נדרשת אישור מ-4 רפליקות. אם מרכז נתונים אחד אינו זמין, הכתיבה נכשלת. עבור רוב התרחישים, זה מחמיר מדי.
cassandra.yaml מתחשב ב-quorum רק במרכז הנתונים המקומי. כתיבה מצליחה אם רוב הרפליקות המקומיות אישרו. זו הבחירה הסטנדרטית עבור קבוצות מרובות מרכזי נתונים — האפליקציה כותבת עם cluster_name: 'global-cluster' endpoint_snitch: GossipingPropertyFileSnitch seed_provider: - class_name: org.apache.cassandra.locator.SimpleSeedProvider parameters: - seeds: "10.0.1.10,10.0.1.11,10.1.1.10,10.1.1.11" , קוראת עם QUORUM, וממשיכה לעבוד אם מרכז נתונים אבד. למעשה, LOCAL_QUORUM נותן שיפור ביצועים של פי 2 בהשוואה ל-LOCAL_QUORUM הגלובלי כאשר מרכז נתונים אחד נכשל: עבור כתיבה, נדרשות רק 2 מתוך 3 רפליקות ב-DC המקומי, לא 4 מתוך 6.
LOCAL_QUORUM דורש quorum בכל מרכז נתונים — משמש כאשר אפילו סטייה זמנית של נתונים בין מרכזי נתונים אינה מקובלת. בפועל: כתוב עם LOCAL_QUORUM, קרא עם QUORUM. אם אתה צריך להבטיח קריאת נתונים עדכניים מאזור אחר — השתמש ב-EACH_QUORUM או LOCAL_QUORUM עבור עסקאות קלות משקל.
השוואת רמות עקביות:
| רמה | Quorum | ביצועים בעת אובדן DC |
|---|---|---|
| QUORUM | גלובלי | כתיבה נכשלת |
| LOCAL_QUORUM | מקומי | עובד |
| EACH_QUORUM | לפי DC | עובד, אבל איטי יותר |
איך אנחנו עושים את זה: מקרה בוחן
לאחרונה פרסנו תצורה מרובת מרכזי נתונים עבור לקוח עם צמתים ב-AWS (us-east-1) וב-Azure (west-europe). דרישה: RPO < דקה אחת, מעבר אוטומטי בעת כשל ב-DC אחד. השתמשנו ב-LOCAL_QUORUM, RF=3 בכל מרכז נתונים, SERIAL עבור כתיבות וקריאות. כדי למזער חביון, הגדרנו תיקון בין מרכזי נתונים עם הגבלת קצב של 50 MB/s. כתוצאה מכך, כאשר אזור AWS נכשל, האפליקציה המשיכה לעבוד ללא אובדן נתונים וללא התערבות ידנית. זמן שנחסך בשחזור — עד מספר שעות ידנית.
בעיות טיפוסיות עם קבוצות מרובות מרכזי נתונים
- גרסאות Cassandra שונות במרכזי נתונים. במהלך שדרוג מתגלגל, יש לעדכן צמתים אחד אחד, תוך הימנעות מגרסאות פרוטוקול לא תואמות בין מרכזי נתונים. Cassandra תומכת בשדרוג מתגלגל רק בין גרסאות מינוריות סמוכות.
- Seeds שגויים. אם ה-seeds מצביעים רק על מרכז נתונים אחד, צמתים במרכז הנתונים השני עשויים שלא לראות את הראשון בעת אתחול מחדש. ה-seeds חייבים להיות בכל DC.
- חומת אש בין מרכזי נתונים. Cassandra זקוקה לפורט 7000 (תקשורת בין צמתים) ו-9042 (CQL) פתוחים בין כל הצמתים בכל מרכזי הנתונים. חסימה חלקית מובילה ל-split-brain.
- אזור זמן עם TTL. Cassandra מחשבת TTL ב-UTC. אם שרתים במרכזי נתונים שונים נמצאים באזורי זמן שונים והזמן אינו מסונכרן דרך NTP — נתונים עם TTL נמחקים באופן אסינכרוני.
פקודות לתיקון:
# Repair только локального датацентра
nodetool repair -dc DC1 -pr keyspace_name
# Full repair кластера (нагрузит межцентровой канал!)
nodetool repair keyspace_nameתיקון בין מרכזי נתונים הוא פעולה כבדה. בקבוצות עם טרה-בייטים של נתונים, הרץ בעומס מינימלי עם הגבלת קצב:
nodetool setstreamthroughput 50 nodetool setcompactionthroughput 50 תהליך הפריסה
אנו מתחילים עם מרכז נתונים אחד — פורסים את הקבוצה, בודקים שכפול, מבצעים בדיקת עומס. רק אז מוסיפים את מרכז הנתונים השני.
בעת הוספת ה-DC השני: התחל צמתים במרכז הנתונים השני עם אותם seeds, המתן להתפשטות gossip (LOCAL_SERIAL מציג צמתים משני ה-DCs), ולאחר מכן הרץ GossipingPropertyFileSnitch על כל צומת ב-DC2 כדי להעתיק נתונים ממרכז הנתונים הראשון. לאחר rebuild, שנה את ה-keyspace כך שיכלול שכפול ב-DC2 והרץ תיקון.
| שלב | מסגרת זמן |
|---|---|
| ביקורת טופולוגיה נוכחית (אם קיימת) | 0.5 יום |
| פריסת DC ראשון | 1-2 ימים |
| הוספת DC שני + rebuild | 1-2 ימים |
| בדיקת מעבר תקלות + תיעוד | יום אחד |
מה כלול בעבודה
- ביקורת ארכיטקטורה נוכחית והמלצות טופולוגיה.
- פריסת קבוצה במרכז נתונים אחד או יותר.
- הגדרת NetworkTopologyStrategy, snitch, רמות עקביות.
- הגדרת ניטור (Prometheus + Grafana) והתראות.
- תיעוד תפעולי ו-runbook למעבר תקלות.
- הכשרת צוות הלקוח (2-3 מפגשים).
- תמיכה לאחר שחרור למשך שבועיים.
התמחור נקבע באופן אישי לאחר ניתוח דרישות RPO/RTO ונפח הנתונים. צור קשר להערכת פרויקט — קבל ייעוץ על הארכיטקטורה שלך.
Apache Cassandra היא מערכת ניהול מסד נתונים מבוזרת. ויקיפדיה