אנו נתקלים באופן קבוע במסד הנתונים של אפאצ'י קסנדרה ובצורך להפעילו בתוך תשתית מבוססת קוברנטס. במאמר זה, נשתף את החזון שלנו לגבי השלבים, הקריטריונים והפתרונות הקיימים (כולל סקירה כללית של אופרטורים) הנדרשים להעברת קסנדרה ל-K8s.
"מי שיכול לנהל אישה יכול גם לנהל את המדינה"
מי זאת קסנדרה? זוהי מערכת אחסון מבוזרת שנועדה לנהל כמויות גדולות של נתונים, תוך מתן זמינות גבוהה ללא נקודת כשל אחת. הפרויקט כמעט ולא זקוק להקדמה ארוכה, לכן אציג רק את התכונות העיקריות של קסנדרה שיהיו רלוונטיות בהקשר של מאמר ספציפי:
- קסנדרה כתובה בשפת ג'אווה.
- טופולוגיית קסנדרה כוללת מספר רמות:
- Node - מופע אחד של קסנדרה שנפרס;
- Rack הוא קבוצה של מופעי קסנדרה, מאוחדים על ידי תכונה כלשהי, הממוקמים במרכז נתונים אחד;
- מרכז נתונים - אוסף של כל קבוצות מופעי קסנדרה הממוקמים במרכז נתונים אחד;
- Cluster הוא אוסף של כל מרכזי הנתונים.
- קסנדרה משתמשת בכתובת IP כדי לזהות צומת.
- כדי להאיץ את פעולות הכתיבה והקריאה, קסנדרה מאחסנת חלק מהנתונים ב-RAM.
עכשיו, למעבר הפוטנציאלי בפועל לקוברנטס.
רשימת בדיקה להעברה
כשמדברים על העברת קסנדרה לקובנרטס, אנו מקווים שהמעבר יקל על הניהול. מה יידרש לשם כך, מה יעזור בכך?
1. אחסון נתונים
כפי שכבר צוין, קסנדה מאחסנת חלק מהנתונים ב-RAM - ב- ממטבלאבל יש חלק נוסף של הנתונים שנשמר בדיסק - בצורה טבלת SSTהישות מתווספת לנתונים אלה יומן התחייבויות — רישומים של כל העסקאות, אשר נשמרים גם הם בדיסק.
קסנדרה כותבת תוכנית עסקאות
ב-Kubernetes, אנו יכולים להשתמש ב-PersistentVolume לאחסון נתונים. הודות למנגנונים מוכחים, עבודה עם נתונים ב-Kubernetes הופכת לקלה יותר משנה לשנה.
נקדיש את PersistentVolume שלנו לכל פוד של קסנדרה.
חשוב לציין שקסנדרה עצמה מרמזת על שכפול נתונים, ומציעה מנגנונים מובנים לכך. לכן, אם אתם מרכיבים אשכול קסנדרה ממספר רב של צמתים, אין צורך להשתמש במערכות מבוזרות כמו Ceph או GlusterFS לאחסון נתונים. במקרה זה, יהיה הגיוני לאחסן נתונים בדיסק הצומת באמצעות או הרכבה hostPath.
שאלה נוספת היא האם אתם רוצים ליצור סביבה נפרדת למפתחים עבור כל ענף תכונות. במקרה זה, הגישה הנכונה תהיה להעלות צומת קסנדרה אחד ולאחסן נתונים באחסון מבוזר, כלומר ה-Ceph וה-GlusterFS שהוזכרו יהפכו לאפשרות שלכם. אז המפתח יוכל להיות בטוח שהוא לא יאבד נתוני בדיקה גם אם אחד מצמתי אשכול קוברנטס יאבד.
2. ניטור
פרומתאוס היא הבחירה כמעט בלתי מעורערת ליישום ניטור ב-Kubernetes. (דיברנו על כך בפירוט ב )איך קסנדרה מתפקדת עם ייצוא מדדים עבור פרומתאוס? ומה שחשוב עוד יותר, עם לוחות המחוונים המתאימים עבור גרפנה?
דוגמה להופעת גרפים ב-Grafana עבור קסנדרה
יש רק שני יצואנים: и .
בחרנו לעצמנו את הראשון בגלל:
- JMX Export צומח ומתפתח, בעוד ש-Cassandra Export לא הצליח להשיג את תמיכת הקהילה הנדרשת. Cassandra Export עדיין לא תומך ברוב הגרסאות של Cassandra.
- ניתן להריץ אותו כ-javaagent על ידי הוספת דגל
-javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180. - יש משהו בשבילו , שאינו תואם ל-Cassandra Export.
3. בחירת פרימיטיבים של Kubernetes
בהתאם למבנה של אשכול קסנדרה לעיל, בואו ננסה לתרגם את כל מה שמתואר שם לטרמינולוגיה של קוברנט:
- צומת קסנדרה → פוד
- קסנדרה ראק → StatefulSet
- מרכז נתונים קסנדרה → מאגר מ-StatefulSets
- צביר קסנדרה → ???
מסתבר שחסרה ישות נוספת שתנהל את כל אשכול קסנדרה בבת אחת. אבל אם משהו חסר, נוכל ליצור אותו! ב-Kubernetes, לשם כך נועד המנגנון להגדרת המשאבים שלך - .
הכרזה על משאבים נוספים עבור יומני רישום והתראות
אבל המשאב המותאם אישית עצמו לא אומר כלום: אחרי הכל, הוא דורש בקרייתכן שתצטרך לפנות לעזרה. ...
4. זיהוי תרמילים
בנקודה לעיל, הסכמנו שצומת קסנדרה אחד יהיה שווה לפוד אחד בקוברנטס. אבל כתובות ה-IP של הפודים יהיו שונות בכל פעם. וזיהוי הצומת בקאסנדרה מתרחש על סמך כתובת ה-IP... מסתבר שאחרי כל מחיקת פוד, אשכול קסנדרה יוסיף לעצמו צומת חדש.
יש דרך מוצא, ולא רק אחת:
- אנו יכולים לשמור רשומות לפי מזהי מארח (UUIDs המזהים באופן ייחודי מופעי קסנדרה) או לפי כתובות IP ולאחסן את הכל במבנים/טבלאות. לשיטה זו שני חסרונות עיקריים:
- סיכון לתנאי מרוץ כאשר שני צמתים קורסים בו זמנית. לאחר ההתאוששות, צמתי קסנדרה יבקשו בו זמנית כתובת IP מהטבלה ויתחרו על אותו משאב.
- אם צומת קסנדרה מאבד את הנתונים שלו, לא נוכל עוד לזהות אותו.
- הפתרון השני נראה קצת מסובך, אבל בכל זאת: אנחנו יכולים ליצור שירות עם ClusterIP עבור כל צומת קסנדרה. הבעיות במימוש זה הן:
- אם יש הרבה צמתים באשכול קסנדרה, נצטרך ליצור הרבה שירותים.
- תכונת ClusterIP מיושמת דרך iptables. זו יכולה להיות בעיה אם יש לך אשכול קסנדרה גדול (1000... או אפילו 100?). למרות זאת מסוגל לפתור את הבעיה הזו.
- הפתרון השלישי הוא להשתמש ברשת צמתים עבור צמתי קסנדרה במקום ברשת פודים ייעודית על ידי הפעלת ההגדרה
hostNetwork: trueשיטה זו מטילה מגבלות מסוימות:- כדי להחליף צמתים. יש צורך שלצומת החדש תהיה אותה כתובת IP כמו הקודמת (בענן כמו AWS, GCP זה כמעט בלתי אפשרי לעשות);
- באמצעות רשת של צמתי אשכול, אנו מתחילים להתחרות על משאבי רשת. לכן, יהיה בעייתי לפרוס יותר מפוד אחד עם קסנדרה על צומת אשכול אחד.
5. גיבויים
אנחנו רוצים לשמור את הגרסה המלאה של הנתונים של צומת קסנדרה אחד לפי לוח זמנים. Kubernetes מספקת אפשרות נוחה באמצעות , אבל כאן קסנדרה עצמה שמה לנו את הגלגל.
הרשו לי להזכיר לכם שקסנדרה מאחסנת נתונים מסוימים בזיכרון. כדי לבצע גיבוי מלא, אתם זקוקים לנתונים מהזיכרון (ממטבלאות) העברה לדיסק (טבלאות SST). בנקודה זו, צומת קסנדרה מפסיק לקבל חיבורים, ונסגר לחלוטין מהאשכול.
לאחר מכן, מתבצע גיבוי (תמונת מצב) והסכימה נשמרת (מרווח מקשים). ואז מתברר שגיבוי פשוט לא נותן לנו כלום: אנחנו צריכים לשמור את מזהי הנתונים שעליהם היה אחראי צומת קסנדרה - אלה טוקנים מיוחדים.
הפצת אסימונים כדי לזהות על אילו נתונים אחראים צמתי קסנדרה
ניתן למצוא דוגמה לסקריפט לגיבוי של קסנדרה של גוגל בקובנרטס בכתובת הרגע היחיד שהסקריפט לא לוקח בחשבון הוא איפוס הנתונים לצומת לפני צילום תמונה. כלומר, הגיבוי מתבצע לא עבור המצב הנוכחי, אלא עבור המצב מעט קודם לכן. אבל זה עוזר לא להוציא את הצומת מכלל פעולה, מה שנראה הגיוני מאוד.
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 לגיבוי מצומת קסנדרה אחד
פתרונות מוכנים מראש עבור קסנדרה ב-Kubernetes
מה משמש כיום לפריסת קסנדרה בקוברנטס ואיזה מהם מתאים ביותר לדרישות הנתונות?
1. פתרונות מבוססי תרשימים של StatefulSet או Helm
שימוש בפונקציונליות הבסיסית של StatefulSets להפעלת אשכול קסנדרה הוא אפשרות טובה. באמצעות תרשים Helm ותבניות Go, ניתן לספק למשתמש ממשק גמיש לפריסת קסנדרה.
זה בדרך כלל עובד מצוין... עד שמשהו בלתי צפוי קורה, כמו צומת שקורס. כלי Kubernetes סטנדרטיים פשוט לא יכולים להתמודד עם כל המוזרויות האלה. זה גם מוגבל מאוד במידת הרחבתו עבור מקרי שימוש מורכבים יותר: החלפת צומת, גיבויים, שחזורים, ניטור וכו'.
נציגים:
- ;
- .
שני הגרפים טובים באותה מידה, אך סובלים מהבעיות שתוארו לעיל.
2. פתרונות המבוססים על אופרטור Kubernetes
אפשרויות אלו מעניינות יותר משום שהן מספקות יכולות ניהול אשכולות נרחבות. לתכנון אופרטור קסנדרה, כמו גם כל מסד נתונים אחר, תבנית טובה היא Sidecar <-> Controller <-> CRD:
סכימת ניהול הצמתים באופרטור קסנדרה מעוצב היטב
בואו נבחן את המפעילים הקיימים.
1. אופרטור קסנדרה מאינסטקלסטר
- מוכנות: אלפא
- רישיון: Apache 2.0
- מיושם ב: ג'אווה
זהו פרויקט מבטיח באמת ומתפתח באופן פעיל מחברה המציעה פריסות קסנדרה מנוהלות. הוא, כפי שתואר לעיל, משתמש במכולה צדדית שמקבלת פקודות דרך HTTP. הוא כתוב ב-Java, כך שלפעמים חסרה לו פונקציונליות מתקדמת יותר של ספריית client-go. כמו כן, המפעיל אינו תומך ב-Racks שונים עבור מרכז נתונים אחד.
עם זאת, למפעיל יש יתרונות כגון תמיכה בניטור, ניהול אשכול ברמה גבוהה באמצעות CRD, ואפילו תיעוד על ביצוע גיבויים.
2. נווט מאת ג'טסטאק
- מוכנות: אלפא
- רישיון: Apache 2.0
- מיושם ב: גולאנג
אופרטור שנועד לפריסת DB-as-a-Service. תומך כיום בשני בסיסי נתונים: Elasticsearch ו-Cassandra. יש לו פתרונות מעניינים כמו בקרת גישה לבסיסי נתונים דרך RBAC (לשם כך נוצר navigator-apiserver נפרד). פרויקט מעניין שכדאי לבחון אותו מקרוב, אך ה-commit האחרון בוצע לפני שנה וחצי, מה שמפחית בבירור את הפוטנציאל שלו.
3. קסנדרה-אופרטור מאת vgkowski
- מוכנות: אלפא
- רישיון: Apache 2.0
- מיושם ב: גולאנג
זה לא נחשב "ברצינות" מכיוון שההעברה האחרונה למאגר הייתה לפני יותר משנה. הפיתוח של האופרטור ננטש: הגרסה האחרונה של Kubernetes שהוכרזה כנתמכת היא 1.9.
4. קסנדרה-אופרטור מאת Rook
- מוכנות: אלפא
- רישיון: Apache 2.0
- מיושם ב: גולאנג
אופרטור שהפיתוח שלו לא מתקדם מהר כפי שהיינו רוצים. יש לו מבנה CRD מתוכנן היטב לניהול אשכולות, פותר את הבעיה עם זיהוי צמתים באמצעות שירות עם ClusterIP (אותו "פריצה")... אבל זה הכל בינתיים. אין כרגע ניטור או גיבויים מוכנים מראש (אגב, אנחנו בעד ניטור). נקודה מעניינת היא שניתן גם לפרוס את ScyllaDB באמצעות אופרטור זה.
הערה: השתמשנו במפעיל זה עם שינויים קלים באחד הפרויקטים שלנו. לא נצפו בעיות עם המפעיל במהלך כל תקופת ההפעלה (כ-4 חודשי עבודה).
5. CassKop מאת Orange
- מוכנות: אלפא
- רישיון: Apache 2.0
- מיושם ב: גולאנג
האופרטור הצעיר ביותר ברשימה: ה-commit הראשון בוצע ב-23 במאי 2019. יש לו כבר מספר רב של תכונות מהרשימה שלנו במאגר שלו, עליהן תוכלו לקרוא עוד במאגר הפרויקטים. האופרטור בנוי על בסיס ה-operator-sdk הפופולרי. תומך בניטור "מחוץ לקופסה". ההבדל העיקרי מאופרטורים אחרים הוא השימוש ב- , מיושם בפייתון ומשמש לתקשורת בין צמתי קסנדרה.
ממצאים
מספר הגישות והאפשרויות האפשריות להעברת קסנדרה לקוברנטס מדבר בעד עצמו: הנושא מבוקש.
בשלב זה, אתם יכולים לנסות משהו מהאמור לעיל על אחריותכם בלבד: אף אחד מהמפתחים לא מבטיח 100% פעולה של הפתרון שלו בסביבת ייצור. אבל כבר עכשיו מוצרים רבים נראים מבטיחים מספיק כדי לנסות להשתמש בהם בעמדות פיתוח.
אני חושב שהאישה הזאת על הספינה תהיה שימושית בעתיד!
נ.ב.
קרא גם בבלוג שלנו:
- «";
- «";
- «";
- «".
מקור: www.habr.com
