ניסיון תפעול של CEPH

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

הערה: מגיבים זיהו שגיאות חמורות בחלק מההנחות הדורשות עדכון של המאמר כולו.

אסטרטגיית CEPH

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

בואו ניקח בחשבון את המקרה הפשוט ביותר עם שני דיסקים זהים. מהם אתה יכול להרכיב RAID 1 או אשכול עם N=2 - התוצאה תהיה זהה. אם יש שלושה דיסקים והם בגדלים שונים, אז קל להרכיב אשכול עם N=2: חלק מהנתונים יהיו על דיסקים 1 ו-2, חלק על דיסקים 1 ו-3 וחלק יהיו על דיסקים 2 ו-3. על 5 ו-5, בעוד RAID לא (אתה יכול להרכיב RAID כזה, אבל זה יהיה סטייה). אם יש אפילו יותר דיסקים, אז אפשר ליצור RAID 3; ל-CEPH יש אנלוגי - erasure_code, שסותר את המושגים המוקדמים של המפתחים, ולכן אינו נחשב. RAID XNUMX מניח שיש מספר קטן של כוננים, כולם במצב טוב. אם אחד נכשל, האחרים חייבים להחזיק מעמד עד שהדיסק יוחלף והנתונים ישוחזרו אליו. CEPH, עם N>=XNUMX, מעודד שימוש בדיסקים ישנים, בפרט, אם אתה שומר מספר דיסקים טובים לאחסון עותק אחד של נתונים, ומאחסן את שניים או שלושה העותקים הנותרים על מספר רב של דיסקים ישנים, אז המידע יהיה בטוח, שכן לעת עתה דיסקים חדשים חיים - אין בעיות, ואם אחד מהם נשבר, אז כשל בו-זמני של שלושה דיסקים עם חיי שירות של יותר מחמש שנים, רצוי משרתים שונים, הוא סביר ביותר מִקרֶה.

יש עדינות בהפצת העותקים. כברירת מחדל, ההנחה היא שהנתונים מחולקים ליותר (~100 לדיסק) קבוצות הפצה של PG, שכל אחת מהן משוכפלת על כמה דיסקים. נניח K=6, N=2, אז אם כל שני דיסקים נכשלים, מובטח שהנתונים יאבדו, שכן לפי תורת ההסתברות, יהיה לפחות PG אחד שיהיה ממוקם על שני הדיסקים הללו. ואובדן קבוצה אחת הופך את כל הנתונים במאגר ללא זמין. אם הדיסקים מחולקים לשלושה זוגות ומותר לאחסן נתונים רק על דיסקים בתוך זוג אחד, אז הפצה כזו עמידה גם בפני כשל של כל דיסק אחד, אבל אם שני דיסקים נכשלים, ההסתברות לאובדן נתונים אינה 100%, אבל רק 3/15, וגם במקרה של כשל שלושה דיסקים - רק 12/20. לפיכך, אנטרופיה בהפצת נתונים אינה תורמת לסובלנות תקלות. שימו לב גם שלשרת קבצים, זיכרון RAM פנוי מגביר משמעותית את מהירות התגובה. ככל שיותר זיכרון בכל צומת, וככל שיותר זיכרון בכל הצמתים, כך זה יהיה מהיר יותר. זהו ללא ספק יתרון של אשכול על פני שרת בודד, ועוד יותר מכך, NAS חומרה, שבו מובנית כמות קטנה מאוד של זיכרון.

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

יישום אשכול

לצורך הניסוי, ניקח מחשב שהוצא משימוש Intel DQ57TM + Intel core i3 540 + 16 GB של זיכרון RAM. נארגן ארבעה דיסקים של 2 TB למשהו כמו RAID10, לאחר בדיקה מוצלחת נוסיף צומת שני ואותו מספר דיסקים.

התקנת לינוקס. ההפצה דורשת יכולת התאמה אישית ויציבה. Debian ו-Suse עומדות בדרישות. ל-Suse יש מתקין גמיש יותר המאפשר לך להשבית כל חבילה; לצערי, לא הצלחתי להבין אילו מהם ניתן לזרוק מבלי לפגוע במערכת. התקן את דביאן באמצעות debootstrap buster. אפשרות ה-min-base מתקינה מערכת שבורה שאין בה דרייברים. ההבדל בגודל לעומת הגרסה המלאה לא כל כך גדול עד כדי להפריע. מכיוון שהעבודה מתבצעת על מחשב פיזי, אני רוצה לצלם תמונות, כמו במכונות וירטואליות. אפשרות זו מסופקת על ידי LVM או btrfs (או xfs, או zfs - ההבדל אינו גדול). צילומי LVM אינם נקודה חזקה. התקן btrfs. ומטען האתחול נמצא ב-MBR. אין טעם לעמוס דיסק של 50 מגה-בייט עם מחיצת FAT כאשר ניתן לדחוף אותו לאזור טבלת מחיצות של 1 מגה-בייט ולהקצות את כל השטח למערכת. תפס 700 מגה בדיסק. אני לא זוכר כמה יש בהתקנת SUSE הבסיסית, אני חושב שזה בערך 1.1 או 1.4 GB.

התקן את CEPH. אנו מתעלמים מגרסה 12 במאגר דביאן ומתחברים ישירות מאתר 15.2.3. אנו עוקבים אחר ההוראות מהסעיף "התקן את CEPH באופן ידני" עם האזהרות הבאות:

• לפני חיבור המאגר, עליך להתקין תעודות gnupg wget ca
• לאחר חיבור המאגר, אך לפני התקנת האשכול, התקנת חבילות מושמטת: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
• בעת התקנת CEPH, מסיבות לא ידועות, הוא ינסה להתקין את lvm2. באופן עקרוני, זה לא חבל, אבל ההתקנה נכשלת, אז גם CEPH לא תתקין.

  התיקון הזה עזר:

  cat << EOF >> /var/lib/dpkg/status
  Package: lvm2
  Status: install ok installed
  Priority: important
  Section: admin
  Installed-Size: 0
  Maintainer: Debian Adduser Developers <[email protected]>
  Architecture: all
  Multi-Arch: foreign
  Version: 113.118
  Description: No-install
  EOF
  

סקירת אשכול

ceph-osd - אחראי על אחסון נתונים בדיסק. עבור כל דיסק מופעל שירות רשת שמקבל ומבצע בקשות לקריאה או כתיבה לאובייקטים. שתי מחיצות נוצרות בדיסק. אחד מהם מכיל מידע על האשכול, מספר הדיסק והמפתחות לאשכול. מידע זה של 1KB נוצר פעם אחת בעת הוספת דיסק ומעולם לא הבחין בשינוי. למחיצה השנייה אין מערכת קבצים והיא מאחסנת נתונים בינאריים של CEPH. התקנה אוטומטית בגרסאות קודמות יצרה מחיצת xfs של 100MB עבור מידע שירות. המרתי את הדיסק ל-MBR והקצתי רק 16MB - השירות לא מתלונן. אני חושב שאפשר להחליף את xfs ב-ext ללא בעיות. מחיצה זו מותקנת ב-/var/lib/…, שם השירות קורא מידע על ה-OSD וגם מוצא הפניה להתקן הבלוק שבו מאוחסנים הנתונים הבינאריים. תיאורטית, אתה יכול מיד למקם קבצי עזר ב-/var/lib/…, ולהקצות את כל הדיסק לנתונים. בעת יצירת OSD באמצעות ceph-deploy, נוצר אוטומטית כלל לטעינת המחיצה ב-/var/lib/…, ולמשתמש ceph מוקצות גם זכויות לקרוא את התקן החסימה הרצוי. אם אתה מתקין ידנית, עליך לעשות זאת בעצמך; התיעוד לא אומר זאת. כמו כן, רצוי לציין את פרמטר היעד של זיכרון osd כדי שיהיה מספיק זיכרון פיזי.

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

Ceph-mon - שירות זה מאחסן מפה של האשכול. הוא כולל מידע על כל ה-OSDs, אלגוריתם להפצת PGs ב-OSDs והכי חשוב, מידע על כל האובייקטים (הפרטים של המנגנון הזה לא ברורים לי: יש ספרייה /var/lib/ceph/mon/…/ store.db, הוא מכיל קובץ גדול הוא 26MB, ובאשכול של 105K אובייקטים, מסתבר שזה קצת יותר מ-256 בתים לאובייקט - אני חושב שהמוניטור מאחסן רשימה של כל האובייקטים וה-PGs שבהם הם ממוקמים). נזק לספרייה זו מביא לאובדן כל הנתונים באשכול. מכאן הוסקה המסקנה ש-CRUSH מראה כיצד PGs ממוקמים ב-OSD, וכיצד אובייקטים ממוקמים על PGs - הם מאוחסנים באופן מרכזי בתוך מסד הנתונים, לא משנה עד כמה המפתחים נמנעים ממילה זו. כתוצאה מכך, ראשית, איננו יכולים להתקין את המערכת על כונן הבזק במצב RO, מכיוון שמסד הנתונים מוקלט כל הזמן, יש צורך בדיסק נוסף עבור אלה (בקושי יותר מ- 1 GB), שנית, יש צורך ב- העתק בזמן אמת את הבסיס הזה. אם יש מספר מוניטורים, אז סבילות תקלות מובטחת אוטומטית, אבל במקרה שלנו יש רק מוניטור אחד, מקסימום שניים. ישנו הליך תיאורטי לשחזור צג המבוסס על נתוני OSD, פניתי אליו שלוש פעמים מסיבות שונות, ושלוש פעמים לא היו הודעות שגיאה, כמו גם לא נתונים. למרבה הצער, המנגנון הזה לא עובד. או שנפעיל מחיצה מיניאטורית על ה-OSD ונרכיב RAID לאחסון מסד הנתונים, מה שבוודאי ישפיע לרעה על הביצועים, או שנקצה לפחות שתי מדיות פיזיות אמינות, רצוי USB, כדי לא לתפוס פורטים.

rados-gw - מייצא אחסון אובייקטים באמצעות פרוטוקול S3 וכדומה. יוצר בריכות רבות, לא ברור מדוע. לא התנסיתי הרבה.

ceph-mgr - בעת התקנת שירות זה, מופעלים מספר מודולים. אחד מהם הוא קנה מידה אוטומטי שלא ניתן להשבית. הוא שואף לשמור על הכמות הנכונה של PG/OSD. אם אתה רוצה לשלוט על היחס באופן ידני, אתה יכול לבטל את קנה המידה עבור כל מאגר, אבל במקרה זה המודול קורס עם חלוקה ב-0, ומצב האשכול הופך ל- ERROR. המודול כתוב ב-Python, ואם אתה מציין את השורה הדרושה בו, זה מוביל לביטול שלו. עצלן מכדי לזכור את הפרטים.

רשימת מקורות בשימוש:

התקנה של CEPH
התאוששות מכשל מוחלט בצג

רשימות תסריט:

התקנת המערכת באמצעות debootstrap

blkdev=sdb1
mkfs.btrfs -f /dev/$blkdev
mount /dev/$blkdev /mnt
cd /mnt
for i in {@,@var,@home}; do btrfs subvolume create $i; done
mkdir snapshot @/{var,home}
for i in {var,home}; do mount -o bind @${i} @/$i; done
debootstrap buster @ http://deb.debian.org/debian; echo $?
for i in {dev,proc,sys}; do mount -o bind /$i @/$i; done
cp /etc/bash.bashrc @/etc/

chroot /mnt/@ /bin/bash
echo rbd1 > /etc/hostname
passwd
uuid=`blkid | grep $blkdev | cut -d """ -f 2`
cat << EOF > /etc/fstab
UUID=$uuid / btrfs noatime,nodiratime,subvol=@ 0 1
UUID=$uuid /var btrfs noatime,nodiratime,subvol=@var 0 2
UUID=$uuid /home btrfs noatime,nodiratime,subvol=@home 0 2
EOF
cat << EOF >> /var/lib/dpkg/status
Package: lvm2
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers <[email protected]>
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install

Package: sudo
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers <[email protected]>
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install
EOF

exit
grub-install --boot-directory=@/boot/ /dev/$blkdev
init 6

apt -yq install --no-install-recommends linux-image-amd64 bash-completion ed btrfs-progs grub-pc iproute2 ssh  smartmontools ntfs-3g net-tools man
exit
grub-install --boot-directory=@/boot/ /dev/$blkdev
init 6

צור אשכול

apt -yq install --no-install-recommends gnupg wget ca-certificates
echo 'deb https://download.ceph.com/debian-octopus/ buster main' >> /etc/apt/sources.list
wget -q -O- 'https://download.ceph.com/keys/release.asc' | apt-key add -
apt update
apt -yq install --no-install-recommends ceph-common ceph-mon

echo 192.168.11.11 rbd1 >> /etc/hosts
uuid=`cat /proc/sys/kernel/random/uuid`
cat << EOF > /etc/ceph/ceph.conf
[global]
fsid = $uuid
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
mon allow pool delete = true
mon host = 192.168.11.11
mon initial members = rbd1
mon max pg per osd = 385
osd crush update on start = false
#osd memory target = 2147483648
osd memory target = 1610612736
osd scrub chunk min = 1
osd scrub chunk max = 2
osd scrub sleep = .2
osd pool default pg autoscale mode = off
osd pool default size = 1
osd pool default min size = 1
osd pool default pg num = 1
osd pool default pgp num = 1
[mon]
mgr initial modules = dashboard
EOF

ceph-authtool --create-keyring ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'
ceph-authtool --create-keyring ceph.client.admin.keyring --gen-key -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *' --cap mgr 'allow *'
cp ceph.client.admin.keyring /etc/ceph/
ceph-authtool --create-keyring bootstrap-osd.ceph.keyring --gen-key -n client.bootstrap-osd --cap mon 'profile bootstrap-osd' --cap mgr 'allow r'
cp bootstrap-osd.ceph.keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
ceph-authtool ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring
ceph-authtool ceph.mon.keyring --import-keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
monmaptool --create --add rbd1 192.168.11.11 --fsid $uuid monmap
rm -R /var/lib/ceph/mon/ceph-rbd1/*
ceph-mon --mkfs -i rbd1 --monmap monmap --keyring ceph.mon.keyring
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-mon@rbd1
systemctl start ceph-mon@rbd1
ceph mon enable-msgr2
ceph status

# dashboard

apt -yq install --no-install-recommends ceph-mgr ceph-mgr-dashboard python3-distutils python3-yaml
mkdir /var/lib/ceph/mgr/ceph-rbd1
ceph auth get-or-create mgr.rbd1 mon 'allow profile mgr' osd 'allow *' mds 'allow *' > /var/lib/ceph/mgr/ceph-rbd1/keyring
systemctl enable ceph-mgr@rbd1
systemctl start ceph-mgr@rbd1
ceph config set mgr mgr/dashboard/ssl false
ceph config set mgr mgr/dashboard/server_port 7000
ceph dashboard ac-user-create root 1111115 administrator
systemctl stop ceph-mgr@rbd1
systemctl start ceph-mgr@rbd1

הוספת OSD (חלק)

apt install ceph-osd

osdnum=`ceph osd create`
mkdir -p /var/lib/ceph/osd/ceph-$osdnum
mkfs -t xfs /dev/sda1
mount -t xfs /dev/sda1 /var/lib/ceph/osd/ceph-$osdnum
cd /var/lib/ceph/osd/ceph-$osdnum
ceph auth get-or-create osd.0 mon 'profile osd' mgr 'profile osd' osd 'allow *' > /var/lib/ceph/osd/ceph-$osdnum/keyring
ln -s /dev/disk/by-partuuid/d8cc3da6-02  block
ceph-osd -i $osdnum --mkfs
#chown ceph:ceph /dev/sd?2
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-osd@$osdnum
systemctl start ceph-osd@$osdnum

תקציר

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

אפשרויות לפעולה נוספת: נטוש את CEPH והשתמש ב-btrfs הרב-דיסק הבנאלי (או xfs, zfs), גלה מידע חדש על CEPH, שיאפשר לך להפעיל אותו בתנאים שצוינו, נסה לכתוב את האחסון שלך כקובץ מתקדם הַדְרָכָה.

מקור: www.habr.com