טיפים וטריקים לעבודה עם Ceph בפרויקטים עמוסים

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

• הגירה של נתונים מ-Ceph הישן לחדש עם שימוש חלקי בשרתים קודמים באשכול החדש;
• פתרון לבעיה של הקצאת שטח דיסק ב-Ceph.

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

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

הקדמה לגבי OSD

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

קודם כל, יש לומר שכל אשכול ה-Ceph מורכב מהרבה OSDs. ככל שיש יותר, כך נפח הנתונים הפנוי ב-Ceph גדול יותר. מכאן קל להבין פונקציית OSD הראשית: הוא מאחסן נתוני אובייקט Ceph במערכות הקבצים של כל צמתי האשכולות ומספק גישה לרשת אליו (לקריאה, כתיבה ובקשות אחרות).

באותה רמה, פרמטרי שכפול נקבעים על-ידי העתקת אובייקטים בין OSDs שונים. וכאן ניתן להיתקל בבעיות שונות, שהפתרונות להן יידונו להלן.

תיק מס' 1. הסר בבטחה את OSD מאשכול Ceph מבלי לאבד נתונים

הצורך בהסרת ה-OSD עלול להיגרם כתוצאה מהסרת השרת מהאשכול – למשל החלפתו בשרת אחר – וזה מה שקרה לנו, מה שגרם לכתיבת מאמר זה. לפיכך, המטרה הסופית של מניפולציה היא לחלץ את כל ה-OSDs וה-mons בשרת נתון כך שניתן יהיה לעצור אותה.

מטעמי נוחות וכדי להימנע ממצב שבו בזמן ביצוע פקודות אנו עושים טעות בציון ה-OSD הנדרש, נגדיר משתנה נפרד שערכו יהיה מספר ה-OSD שיימחק. בואו נתקשר אליה ${ID} - כאן ולמטה, משתנה כזה מחליף את מספר ה-OSD איתו אנו עובדים.

בואו נסתכל על המצב לפני תחילת העבודה:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

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

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

... וכן הלאה עד אפס.

נדרש איזון חלקכדי לא לאבד נתונים. זה נכון במיוחד אם ה-OSD מכיל כמות גדולה של נתונים. כדי לוודא שאחרי ביצוע הפקודות reweight הכל הלך טוב, אתה יכול להשלים את זה ceph -s או בחלון מסוף נפרד ceph -w על מנת לצפות בשינויים בזמן אמת.

כאשר ה-OSD "מרוקן", אתה יכול להמשיך בפעולה הרגילה להסרתו. לשם כך, העבר את ה-OSD הרצוי למדינה down:

ceph osd down osd.${ID}

בואו "נמשוך" את ה-OSD מהאשכול:

ceph osd out osd.${ID}

בואו נעצור את שירות ה-OSD ונבטל את הטעינה של המחיצה שלו ב-FS:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

הסר את OSD מ מפת CRUSH:

ceph osd crush remove osd.${ID}

בואו נמחק את משתמש ה-OSD:

ceph auth del osd.${ID}

ולבסוף, בואו נסיר את ה-OSD עצמו:

ceph osd rm osd.${ID}

שים לב: אם אתה משתמש בגרסת Ceph Luminous ומעלה, ניתן לצמצם את שלבי הסרת ה-OSD לעיל לשתי פקודות:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

אם, לאחר השלמת השלבים המתוארים לעיל, אתה מפעיל את הפקודה ceph osd tree, אז זה צריך להיות ברור שבשרת שבו בוצעה העבודה אין עוד קובצי OSD שעבורם בוצעו הפעולות לעיל:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

לאורך הדרך, שימו לב שמצבו של אשכול ה-Ceph ילך HEALTH_WARN, ונראה גם ירידה במספר ה-OSDs ובכמות השטח הפנוי בדיסק.

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

אם לא נותרו עוד קובצי OSD בשרת זה, אז לאחר הסרתם עליך לא לכלול את השרת ממפת ה-OSD hv-2על ידי הפעלת הפקודה הבאה:

ceph osd crush rm hv-2

הסר mon מהשרת hv-2על ידי הפעלת הפקודה למטה בשרת אחר (כלומר, במקרה זה, על hv-1):

ceph-deploy mon destroy hv-2

לאחר מכן, תוכל לעצור את השרת ולהתחיל בפעולות עוקבות (פריסה מחדש וכו').

תיק מס' 2. חלוקת שטח הדיסק באשכול Ceph שכבר נוצר

אתחיל את הסיפור השני בהקדמה על PG (קבוצות מיקום). התפקיד העיקרי של PG ב-Ceph הוא בעיקר לצבור אובייקטי Ceph ולשכפל אותם עוד יותר ב-OSD. הנוסחה שבה אתה יכול לחשב את הכמות הנדרשת של PG נמצאת סעיף רלוונטי תיעוד Ceph. נושא זה נדון שם גם בדוגמאות ספציפיות.

אז: אחת הבעיות הנפוצות בעת שימוש ב-Ceph היא המספר הלא מאוזן של OSD ו-PG בין בריכות ב-Ceph.

ראשית, בגלל זה, עלול להיווצר מצב שבו מצוינים יותר מדי PGs במאגר קטן, שזה בעצם שימוש לא רציונלי בשטח דיסק באשכול. שנית, בפועל יש בעיה חמורה יותר: הצפת נתונים באחד מ-OSDs. זה כרוך במעבר הראשון של האשכול למדינה HEALTH_WARN, ואז HEALTH_ERR. הסיבה לכך היא ש-Ceph, בעת חישוב כמות הנתונים הזמינה (תוכל לגלות זאת על ידי MAX AVAIL בפלט הפקודה ceph df עבור כל מאגר בנפרד) מבוסס על כמות הנתונים הזמינים ב-OSD. אם אין מספיק מקום לפחות ב-OSD אחד, לא ניתן לכתוב נתונים נוספים עד שהנתונים יחולקו כראוי בין כל ה-OSDs.

ראוי להבהיר כי הבעיות הללו נקבעים במידה רבה בשלב תצורת אשכול Ceph. אחד הכלים שבהם אתה יכול להשתמש הוא Ceph PGCalc. בעזרתו, הכמות הנדרשת של PG מחושבת בבירור. עם זאת, אתה יכול לפנות אליו גם במצב שבו מקבץ ה-Ceph כבר מוגדר בצורה שגויה. כדאי להבהיר כאן שכחלק מעבודת התיקון סביר להניח שתצטרכו להפחית את מספר ה-PGs, ותכונה זו אינה זמינה בגרסאות ישנות יותר של Ceph (היא הופיעה רק בגרסה נאוטילוס).

אז בואו נדמיין את התמונה הבאה: לאשכול יש סטטוס HEALTH_WARN בגלל אחד מ-OSD שנגמר המקום. זה יצוין על ידי שגיאה HEALTH_WARN: 1 near full osd. להלן אלגוריתם ליציאה ממצב זה.

קודם כל, עליך להפיץ את הנתונים הזמינים בין שאר ה-OSDs. כבר ביצענו פעולה דומה במקרה הראשון, כאשר "ניקזנו" את הצומת - עם ההבדל היחיד שעכשיו נצטרך להפחית מעט reweight. לדוגמה, עד 0.95:

ceph osd reweight osd.${ID} 0.95

זה מפנה מקום בדיסק ב-OSD ומתקן את השגיאה ב-ceph health. עם זאת, כפי שכבר צוין, בעיה זו מתרחשת בעיקר עקב תצורה לא נכונה של Ceph בשלבים הראשוניים: חשוב מאוד לבצע קונפיגורציה מחדש כדי שהיא לא תופיע בעתיד.

במקרה הספציפי שלנו, הכל הסתכם ב:

• ערך גבוה מדי replication_count באחת הבריכות,
• יותר מדי PG בבריכה אחת ומעט מדי בבריכה אחרת.

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

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

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

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

ceph osd pool $pool_name set $replication_size

ולאחר השלמתו, אנו משנים את ערכי הפרמטרים pg_num и pgp_num כדלקמן:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

זה חשוב: עלינו לשנות את מספר ה-PGs ברצף בכל מאגר ולא לשנות את הערכים במאגרים אחרים עד שהאזהרות ייעלמו "יתירות נתונים מושפלת" и "מספר n של עמודים מושפלים".

אתה יכול גם לבדוק שהכל הלך כשורה באמצעות פלטי הפקודה ceph health detail и ceph -s.

תיק מס' 3. העברת מכונה וירטואלית מ-LVM ל-Ceph RBD

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

ניתן לפתור את הבעיה בדרכים שונות – למשל על ידי הגירה לשרת אחר (אם יש) או הוספת דיסקים חדשים לשרת. אבל לא תמיד ניתן לעשות זאת, כך שהמעבר מ-LVM ל-Ceph יכול להיות פתרון מצוין לבעיה זו. על ידי בחירה באפשרות זו, אנו גם מפשטים את המשך תהליך ההגירה בין שרתים, מכיוון שלא יהיה צורך להעביר אחסון מקומי מ-Hypervisor אחד למשנהו. הקאץ' היחיד הוא שתצטרך לעצור את ה-VM בזמן ביצוע העבודה.

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

נעבור לחלק המעשי. בדוגמה אנו משתמשים ב-virsh ובהתאם לכך, libvirt. ראשית, ודא שמאגר ה-Ceph אליו יועברו הנתונים מחובר ל-libvirt:

virsh pool-dumpxml $ceph_pool

תיאור הבריכה חייב להכיל נתוני חיבור ל-Ceph עם נתוני הרשאה.

השלב הבא הוא שתמונת LVM מומרת ל-Ceph RBD. זמן הביצוע תלוי בעיקר בגודל התמונה:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

לאחר ההמרה, תמונת LVM תישאר, שתהיה שימושית אם העברת ה-VM ל-RBD נכשלת ואתה צריך להחזיר את השינויים לאחור. כמו כן, כדי להיות מסוגל להחזיר שינויים במהירות, בואו נעשה גיבוי של קובץ התצורה של המחשב הווירטואלי:

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

... וערוך את המקור (vm_name.xml). בוא נמצא בלוק עם תיאור של הדיסק (מתחיל בשורה <disk type='file' device='disk'> ומסתיים ב </disk>) וצמצם אותו לצורה הבאה:

<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
  <secret type='ceph' uuid='sec-ret-uu-id'/>
 </auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
  <host name='10.0.0.1' port='6789'/>
  <host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/> 
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>

בואו נסתכל על כמה פרטים:

1. לפרוטוקול source מצוינת הכתובת לאחסון ב-Ceph RBD (זו הכתובת המציינת את שם בריכת ה-Ceph ותמונת ה-RBD, שנקבעה בשלב הראשון).
2. בבלוק secret הסוג מצוין ceph, כמו גם ה-UUID של הסוד להתחבר אליו. ניתן למצוא את ה-uuid שלו באמצעות הפקודה virsh secret-list.
3. בבלוק host כתובות לצגי Ceph מסומנות.

לאחר עריכת קובץ התצורה והשלמת המרת LVM ל-RBD, תוכל להחיל את קובץ התצורה ששונה ולהפעיל את המכונה הוירטואלית:

virsh define $vm_name.xml
virsh start $vm_name

זה הזמן לבדוק שהמכונה הוירטואלית התחילה כהלכה: ניתן לברר זאת, למשל, בחיבור אליה דרך SSH או דרך virsh.

אם המכונה הוירטואלית פועלת כהלכה ולא מצאת בעיות אחרות, תוכל למחוק את תמונת LVM שאינה בשימוש עוד:

lvremove main/$vm_image_name

מסקנה

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

נ.ב.

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

• «הידיים שלנו לא לשעמום: שחזור מקבץ ה-Rook ב-K8s";
• «לרוק או לא לרוק - זו השאלה";
• «Rook - מחסן נתונים "בשירות עצמי" עבור Kubernetes";
• «יצירת אחסון מתמשך עם הקצאה ב-Kubernetes על בסיס Ceph".

מקור: www.habr.com