הגירה של קסנדרה ל-Kubernetes: תכונות ופתרונות

אנו נתקלים בקביעות במסד הנתונים של Apache Cassandra ובצורך להפעיל אותו בתוך תשתית מבוססת Kubernetes. בחומר זה, נשתף את החזון שלנו לגבי השלבים הדרושים, הקריטריונים והפתרונות הקיימים (כולל סקירה של מפעילים) להעברה של Cassandra ל-K8s.

"מי שיכול לשלוט באישה יכול גם לשלוט במדינה"

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

• קסנדרה כתובה בג'אווה.
• הטופולוגיה של קסנדרה כוללת מספר רמות:
  • Node - מופע אחד של Cassandra פרוס;
  • Rack היא קבוצה של מופעי Cassandra, המאוחדים על ידי מאפיין כלשהו, ​​הממוקמים באותו מרכז נתונים;
  • Datacenter - אוסף של כל הקבוצות של מופעי Cassandra הממוקמים במרכז נתונים אחד;
  • Cluster הוא אוסף של כל מרכזי הנתונים.
• קסנדרה משתמשת בכתובת IP כדי לזהות צומת.
• כדי להאיץ את פעולות הכתיבה והקריאה, Cassandra מאחסנת חלק מהנתונים ב-RAM.

עכשיו - למעבר הפוטנציאלי בפועל לקוברנטס.

רשימת בדיקה להעברה

אם כבר מדברים על ההגירה של קסנדרה ל- Kubernetes, אנו מקווים שעם המעבר היא תהפוך נוחה יותר לניהול. מה יידרש בשביל זה, מה יעזור בזה?

1. אחסון נתונים

כפי שכבר הובהר, קסנדה אוגרת חלק מהנתונים ב-RAM - in מזכר. אבל יש עוד חלק מהנתונים שנשמר בדיסק - בטופס SSTable. לנתונים אלו מתווספת ישות יומן התחייבות - רשומות של כל העסקאות, שנשמרות גם בדיסק.

כתוב דיאגרמת עסקאות בקסנדרה

ב-Kubernetes, אנו יכולים להשתמש ב-PersistentVolume לאחסון נתונים. הודות למנגנונים מוכחים, העבודה עם נתונים ב- Kubernetes הופכת קלה יותר מדי שנה.

אנו נקצה נפח מתמשך משלנו לכל תרמיל קסנדרה

חשוב לציין שקסנדרה עצמה מרמזת על שכפול נתונים, ומציעה מנגנונים מובנים לכך. לכן, אם אתה בונה אשכול Cassandra ממספר רב של צמתים, אז אין צורך להשתמש במערכות מבוזרות כמו Ceph או GlusterFS לאחסון נתונים. במקרה זה, זה יהיה הגיוני לאחסן נתונים בדיסק המארח באמצעות דיסקים קבועים מקומיים או הרכבה hostPath.

שאלה נוספת היא אם אתה רוצה ליצור סביבה נפרדת למפתחים עבור כל ענף תכונה. במקרה זה, הגישה הנכונה תהיה להעלות צומת קסנדרה אחד ולאחסן את הנתונים באחסון מבוזר, כלומר. ה-Ceph ו-GlusterFS שהוזכרו יהיו האפשרויות שלך. אז המפתח יהיה בטוח שהוא לא יאבד נתוני בדיקה גם אם אחד מצמתי האשכולות של Kuberntes יאבד.

2. ניטור

הבחירה הבלתי מעורערת כמעט להטמעת ניטור ב- Kubernetes היא Prometheus (דיברנו על זה בפירוט ב דוח קשור). איך קסנדרה מסתדרת עם יצואניות מדדים עבור פרומתאוס? ומה עוד יותר חשוב, עם לוחות מחוונים תואמים לגרפאנה?

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

יש רק שני יצואנים: jmx_exporter и cassandra_exporter.

בחרנו את הראשון לעצמנו כי:

1. JMX Exporter גדל ומתפתח, בעוד Cassandra Exporter לא הצליחה לקבל מספיק תמיכה קהילתית. Cassandra Exporter עדיין לא תומך ברוב הגרסאות של Cassandra.
2. אתה יכול להפעיל אותו כ-javaagent על ידי הוספת דגל -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
3. יש אחד בשבילו לוח מחוונים מתאים, שאינו תואם עם Cassandra Exporter.

3. בחירת הפרימיטיבים של Kubernetes

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

• Cassandra Node → Pod
• Cassandra Rack → StatefulSet
• Cassandra Datacenter → בריכה מ-StatefulSets
• אשכול קסנדרה → ???

מסתבר שחסרה איזו ישות נוספת שתנהל את כל אשכול קסנדרה בבת אחת. אבל אם משהו לא קיים, נוכל ליצור אותו! ל-Kubernetes יש מנגנון להגדרת משאבים משלה למטרה זו - הגדרות משאבים מותאמות אישית.

הצהרת משאבים נוספים עבור יומנים והתראות

אבל משאב מותאם אישית עצמו לא אומר כלום: אחרי הכל, זה דורש בקר. ייתכן שתצטרך לבקש עזרה מפעיל Kubernetes...

4. זיהוי תרמילים

בפסקה לעיל, הסכמנו שצומת קסנדרה אחד ישתווה לפוד אחד ב-Kubernetes. אבל כתובות ה-IP של הפודים יהיו שונות בכל פעם. והזיהוי של צומת בקסנדרה מבוסס על כתובת ה-IP... מסתבר שאחרי כל הסרה של פוד, אשכול הקסנדרה יוסיף צומת חדש.

יש דרך לצאת, ולא רק אחת:

1. אנחנו יכולים לשמור רשומות לפי מזהי מארח (UUIDs המזהים באופן ייחודי מופעים של Cassandra) או לפי כתובות IP ולאחסן את הכל במבנים/טבלאות מסוימות. לשיטה שני חסרונות עיקריים:
   • הסיכון להתרחשות מצב גזע אם שני צמתים נופלים בבת אחת. לאחר העלייה, צמתי קסנדרה יבקשו במקביל כתובת IP מהטבלה ויתחרו על אותו משאב.
   • אם צומת קסנדרה איבדה את הנתונים שלו, לא נוכל עוד לזהות אותו.
2. הפתרון השני נראה כמו פריצה קטנה, אבל בכל זאת: אנחנו יכולים ליצור שירות עם ClusterIP עבור כל צומת Cassandra. בעיות ביישום זה:
   • אם יש הרבה צמתים באשכול Cassandra, נצטרך ליצור הרבה שירותים.
   • תכונת ClusterIP מיושמת באמצעות iptables. זה יכול להפוך לבעיה אם לאשכול הקסנדרה יש הרבה (1000... או אפילו 100?) צמתים. למרות ש איזון על בסיס IPVS יכול לפתור את הבעיה הזו.
3. הפתרון השלישי הוא להשתמש ברשת של צמתים עבור צמתי קסנדרה במקום ברשת ייעודית של פודים על ידי הפעלת ההגדרה hostNetwork: true. שיטה זו מטילה הגבלות מסוימות:
   • כדי להחליף יחידות. זה הכרחי שלצומת החדש תהיה אותה כתובת IP כמו הקודמת (בעננים כמו AWS, GCP זה כמעט בלתי אפשרי לעשות זאת);
   • באמצעות רשת של צמתי אשכול, אנו מתחילים להתחרות על משאבי רשת. לכן, הצבת יותר מתרמיל אחד עם Cassandra על צומת אשכול אחד תהיה בעייתית.

5. גיבויים

אנחנו רוצים לשמור גרסה מלאה של נתוני צומת קסנדרה בודדת בלוח זמנים. Kubernetes מספק תכונה נוחה באמצעות CronJob, אבל כאן קסנדרה עצמה שמה חישור בגלגלים שלנו.

הרשו לי להזכיר לכם שקסנדרה מאחסנת חלק מהנתונים בזיכרון. כדי לבצע גיבוי מלא, אתה צריך נתונים מהזיכרון (Memtables) העבר לדיסק (SSTables). בשלב זה, צומת הקסנדרה מפסיק לקבל חיבורים, ונכבה לחלוטין מהאשכול.

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

הפצת אסימונים כדי לזהות לאילו נתונים אחראים צמתי קסנדרה

סקריפט דוגמה ללקיחת גיבוי Cassandra מגוגל ב-Kubernetes ניתן למצוא בכתובת קישור זה. הנקודה היחידה שהסקריפט לא לוקח בחשבון היא איפוס נתונים לצומת לפני צילום תמונת המצב. כלומר, הגיבוי מתבצע לא עבור המצב הנוכחי, אלא עבור מצב קצת קודם. אבל זה עוזר לא להוציא את הצומת מפעולה, מה שנראה הגיוני מאוד.

set -eu

if [[ -z "$1" ]]; then
  info "Please provide a keyspace"
  exit 1
fi

KEYSPACE="$1"

result=$(nodetool snapshot "${KEYSPACE}")

if [[ $? -ne 0 ]]; then
  echo "Error while making snapshot"
  exit 1
fi

timestamp=$(echo "$result" | awk '/Snapshot directory: / { print $3 }')

mkdir -p /tmp/backup

for path in $(find "/var/lib/cassandra/data/${KEYSPACE}" -name $timestamp); do
  table=$(echo "${path}" | awk -F "[/-]" '{print $7}')
  mkdir /tmp/backup/$table
  mv $path /tmp/backup/$table
done


tar -zcf /tmp/backup.tar.gz -C /tmp/backup .

nodetool clearsnapshot "${KEYSPACE}"

דוגמה ל-bash script ללקיחת גיבוי מצומת Cassandra אחד

פתרונות מוכנים לקסנדרה בקוברנטס

מה משמש כרגע לפריסת Cassandra ב- Kubernetes ואיזה מבין אלה מתאים ביותר לדרישות הנתונות?

1. פתרונות המבוססים על תרשימי StatefulSet או Helm

שימוש בפונקציות הבסיסיות של StatefulSets להפעלת אשכול Cassandra היא אפשרות טובה. באמצעות תבניות ה-Helm ותבניות Go, תוכל לספק למשתמש ממשק גמיש לפריסת Cassandra.

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

נציגים:

• תרשים ממאגר Helm הראשי;
• תרשים מ-bitnami.

שני התרשימים טובים באותה מידה, אך כפופים לבעיות שתוארו לעיל.

2. פתרונות מבוססי Kubernetes Operator

אפשרויות כאלה מעניינות יותר מכיוון שהן מספקות הזדמנויות רבות לניהול האשכול. לעיצוב אופרטור Cassandra, כמו כל מסד נתונים אחר, דפוס טוב נראה כמו Sidecar <-> Controller <-> CRD:

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

בואו נסתכל על מפעילים קיימים.

1. מפעיל קסנדרה מ-instaclustr

• GitHub
• מוכנות: אלפא
• רישיון: Apache 2.0
• מיושם ב: Java

זהו אכן פרויקט מאוד מבטיח ומתפתח באופן פעיל מחברה המציעה פריסות מנוהלות של Cassandra. זה, כפי שתואר לעיל, משתמש במיכל צדדי המקבל פקודות באמצעות HTTP. כתוב ב-Java, לפעמים אין לו את הפונקציונליות המתקדמת יותר של ספריית ה-client-go. כמו כן, המפעיל אינו תומך ב-Racks שונים עבור Datacenter אחד.

אבל למפעיל יש יתרונות כמו תמיכה בניטור, ניהול אשכולות ברמה גבוהה באמצעות CRD, ואפילו תיעוד לביצוע גיבויים.

2. ניווט מבית Jetstack

• GitHub
• מוכנות: אלפא
• רישיון: Apache 2.0
• מיושם ב: גולנג

הצהרה שנועדה לפרוס את DB-as-a-Service. כרגע תומך בשני מסדי נתונים: Elasticsearch ו- Cassandra. יש לו פתרונות מעניינים כמו בקרת גישה למסד נתונים באמצעות RBAC (בשביל זה יש לו שרת נווט נפרד משלו). פרויקט מעניין שכדאי להסתכל עליו יותר מקרוב, אבל ההתחייבות האחרונה בוצעה לפני שנה וחצי, מה שמפחית בבירור את הפוטנציאל שלו.

3. קסנדרה-מפעיל מאת vgkowski

• GitHub
• מוכנות: אלפא
• רישיון: Apache 2.0
• מיושם ב: גולנג

הם לא שקלו את זה "ברצינות", מכיוון שההתחייבות האחרונה למאגר הייתה לפני יותר משנה. פיתוח המפעיל נזנח: הגרסה האחרונה של Kubernetes שדווחה כנתמכת היא 1.9.

4. קסנדרה-מפעיל של רוק

• GitHub
• מוכנות: אלפא
• רישיון: Apache 2.0
• מיושם ב: גולנג

מפעיל שהפיתוח שלו לא מתקדם מהר כמו שהיינו רוצים. יש לו מבנה CRD מחושב היטב לניהול אשכולות, פותר את הבעיה של זיהוי צמתים באמצעות Service עם ClusterIP (אותו "האק")... אבל זה הכל לעת עתה. כרגע אין ניטור או גיבויים מחוץ לקופסה (אגב, אנחנו לניטור לקחו את זה בעצמנו). נקודה מעניינת היא שאתה יכול גם לפרוס את ScyllaDB באמצעות אופרטור זה.

הערה: השתמשנו במפעיל זה עם שינויים קלים באחד מהפרויקטים שלנו. לא הבחינו בבעיות בעבודת המפעיל במהלך כל תקופת הפעילות (~4 חודשי הפעלה).

5. CassKop מבית Orange

• GitHub
• מוכנות: אלפא
• רישיון: Apache 2.0
• מיושם ב: גולנג

המפעיל הצעיר ביותר ברשימה: ההתחייבות הראשונה בוצעה ב-23 במאי 2019. כבר עכשיו יש לו בארסנל שלו מספר רב של תכונות מהרשימה שלנו, פרטים נוספים עליהן ניתן למצוא במאגר הפרויקטים. המפעיל בנוי על בסיס המפעיל-sdk הפופולרי. תומך בניטור מחוץ לקופסה. ההבדל העיקרי ממפעילים אחרים הוא השימוש תוסף CassKop, מיושם ב-Python ומשמש לתקשורת בין צמתי קסנדרה.

ממצאים

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

בשלב זה, אתה יכול לנסות כל אחד מהדברים לעיל על סכנתך ובסיכון שלך: אף אחד מהמפתחים לא מבטיח 100% פעולה של הפתרון שלו בסביבת ייצור. אבל כבר עכשיו מוצרים רבים נראים מבטיחים לנסות להשתמש בהם בספסלי פיתוח.

אני חושב שבעתיד האישה הזו על הספינה תהיה שימושית!

נ.ב.

קרא גם בבלוג שלנו:

• «העברה חלקה של MongoDB ל-Kubernetes";
• «העברה חלקה של RabbitMQ ל-Kubernetes";
• «מסדי נתונים ו-Kubernetes (סקירה ודוח וידאו)";
• «טיפים וטריקים של K8s: האצת אתחול עבור מסדי נתונים גדולים".

מקור: www.habr.com