על אחסון וגדילה – חלק שני

בפוסט הקודם הסברתי בכלליות לגבי אחסון שקיים ב-Enterprise/Corporate ומהו ההבדל הכללי בין Scale Up ל-Scale Out. בפוסט זה אסביר יותר לגבי סוגי אחסון של Scale Out, פתרונות קניינים, קוד פתוח ועוד.

לפני שאתחיל להסביר לגבי Scale Out, אני רוצה לענות על שאלה שנשאלתי בכמה הזדמנויות: האם פתרון Scale Out מתאים לכולם או לרובם? האם זה יכול להחליף פתרון אחסון שיש כיום לרוב החברות?

התשובה אינה יכולה להסתכם ב"כן" או "לא". אם לדוגמא יש לך 10 שרתים פיזיים שמריצים נניח 100 מכונות VM ויש לך אחסון כלשהו (בין אם זה של Oracle, NetApp, EMC ואחרים) – אז התשובה היא "לא" – פתרון Scale Out לא יתאים לך מכיוון שמדובר בהגדלה והוספה של לפחות 4-5 שרתים פיזיים וערימות של דיסקים קשיחים מסוגים שונים. עלות של דבר כזה תעקוף בקלילות עלות של אחסון זהה למה שיש לך כיום כך שלא תרוויח מזה הרבה. במקרים כאלו אם אתה רוצה להחליף את האחסון הנוכחי באחסון מבוסס קוד פתוח לדוגמא – עדיף שתסתכל על פתרון מבוסס ZFS לדוגמא.

היכן זה כן יכול להתאים? במקומות שיש צורך בדברים כמו:

  1. הרצה של אלפי מכונות וירטואליות מבוססות KVM או XEN (כמובן גם Open Stack)
  2. מקומות שיש כמויות קבצים עצומות (עשרות מיליונים ומעלה) עם המון משתמשים שניגשים
  3. חוות HPC
  4. ארכיבאות ענקית
  5. פתרונות Cold Storage (נתונים שהגישה אליהם היא נדירה אך כמות המידע היא ענקית ונמדדת ב-Petabytes, Exabytes ומעלה)
  6. שידורים (Streaming)

תעשיות שצריכות פתרון Scale Out לדוגמא:

  1. חברות ביטוח
  2. שימוש בסימולטורים שונים במגוון תחומים
  3. חברות שרוצות לעבד נתונים כמו גז, נפט, מים וכו'
  4. מחקר גנום
  5. בנקים
  6. ועוד

מה נותן לנו Scale Out? גישה שונה לאחסון/שימוש במידע. אין יותר שרת X שממנו אנו ניגשים לקבל את המידע. ליתר דיוק יש לנו "שרת X" אבל הוא לא ממש שרת, הוא משמש יותר כ-Gateway שמצוין על ידי שם host שעבורנו יהיה קל יותר לפנות, אך מה שחשוב לזכור הוא שאיננו פונים לשרת שמאחסן את הנתונים. אם יהיו לנו 100 שרתים פיזיים שמריצים את אותו פתרון אחסון שהוא בנוי ב-Scale Out, אין לנו צורך לפנות לאחד מהשרתים. ה-Gateway כבר יפנה למי שצריך.

מבחינת האחסון עצמו, בניגוד לשיטה של Scale Up – כתיבת הנתונים וגישה אליהם אינה מבוצעת דרך שרת אחת. הנתונים נקראים ונכתבים במספר שרתים כך שהנתונים שאתה כותב יכתבו במספר שרתים (וברוב המקרים הם גם יכתבו במקביל לעוד שרתים לצורך רפליקציה) והם גם יקראו ממספר שרתים, כך שבסופו של דבר אם תקרא קובץ ZIP גדול, תקבל חלקים ממנו ממספר שרתים שונים דרך אותו Gateway בצורה מסודרת.

ב-Scale Out השרידות היא מעל לכל, כך שאם נופל שרת עם כמות דיסקים, שרתים אחרים מיד יקחו את תפקידו ואם השרת שנפל מוכרז כ-Out (ולא שמישהו ניתק לרגע כבל רשת) – השרתים ידעו לאחר מספר רגעים לארגן את המידע בעצמם מבלי שתצטרך "לאמר" להם לבצע. אותו דבר עם דיסקים קשיחים -כל עוד יש רפליקציה (שזו חובה) – תוכל להחליף דיסק תקול (או כמה דיסקים, בהתאם לכמות הרפליקציות) והמערכת תדע להסתדר גם בלעדי הדיסק/ים התקול/ים.

מבחינת תעבורת מידע בין שרתי האחסון (שנקראים Nodes) – תצטרך להשקיע. רוחב של 1 ג'יגהביט לא יספק את התעבורה למאות שרתים פיזיים (ובמקרים רבים גם לא לעשות) ולכן מומלץ להתחיל עם 10 ג'יגהביט, ולבחור פתרון באחת מהדרכים הבאות:

  1. פתרון מבוסס Ethernet – תוכל לבחור בין 10/25/40 ג'יגהביט
  2. פתרון מבוסס Infiniband – עם פתרון זה גם תוכל להגיע ל-100 ג'יגהביט, אבל תצטרך להשקיע לא מעט במתגים וכרטיסים, ומתגים מנוהלים ב-Infiniband ממש אינם זולים.

באחסון הרגיל שאנו מכירים, אנחנו מחלקים את סוגי האחסון ל-2: קבצים ו"בלוקים" (לשם פוסט זה נקרא לזה פשוט LUN). מערכות אחסון סטנדרטיות שומרות את הקבצים ומאפשרות גישה אליהם דרך SMB/CIFS או NFS (יש כמובן שיטות נוספות אך לא אתייחס אליהן כרגע). ה"בלוקים" לעומת זאת בד"כ ייוצאו דרך האחסון לדברים כמו ESXi או Hyper-V (או כל פתרון וירטואליזציה אחר) דרך פרוטוקול iSCSI.

באחסון Scale Out לעומת זאת, יש 3 סוגים:

  1. אחסון "תמונות" – מדובר באחסון קבצים סטטיים, קבצים שלא ישונו בשרת האחסון וההרשאות לגישה לקבצים הן קטנות ופשוטות. השם שקולע במדויק הוא שרות של אמזון – ה-S3 שלהם, זה בדיוק זה.
  2. אחסון "בלוקים" – אחסון "שטחים" שמהם המערכת תייצא החוצה Block Device, בדיוק כמו שמערכת iSCSI מייצאת החוצה. אתה מתחבר ל-Block Device ומפרמט אותו לפי הצרכים שלך ב-Client. מבחינת מערכת האחסון עצמה, אין לה מושג ירוק מה תאכסן באותו בלוק, כך שאם תפרמט את זה ל-NTFS או VMFS או EXT4 או XFS – האחסון לא יהיה מודע לכך.
  3. אחסון קבצים סטנדרטי – בדיוק כמו באחסון רגיל שאנחנו מכירים, כאן מתאחסנים קבצים עם גישה דרך CIFS/SMB או NFS וכו'.

מבחינת פתרונות Scale Out, ישנם פתרונות קנייניים מכל יצרניות האחסון, החל מ-EMC עם Isilon, דרך IBM עם XIV, ממשיכים ב-NetApp (סידרת FAS8000 ומעלה), ויש עוד כמה. האם הם טובים? כן, אם כי לכל אחד מהם יש חסרונות ויתרונות (בקשו מאנשי המכירות של IBM לדוגמא לשלוח לכם את המצגות הפנימיות שלהם על חסרונות של מוצרים מתחרים, תתפלאו כמה הם "חפרו" לעומק המוצרים האחרים כדי לגלות כל פיפס וכל פאק רציני בכל מיני עומסים) – אבל החסרון הגדול של כולם הוא המחיר. הוא מטורף וזה יכול להגיע למצבים שגם חברות מאוד מבוססות לא חותמות כל כך מהר על הזמנת הפתרון.

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

ויש את Ceph.

בעקרון, Ceph מכוונת להיות One Stop Solution אם אתה מחפש פתרון Scale Out. בזמן שפתרונות מבוססי קוד פתוח כמו Luster יכולים לתת לך פתרונות כמו Block Device, Images, FS – החסרון של Lustre זה שהכל עובר דרך שרת פיזי אחד, מה שאומר שתקבל "צוואר בקבוק" תוך זמן קצר, וכנ"ל גם iRODs עם אותה בעיה. אם נדבר על HDFS לדוגמא – הוא מעולה לאחסון קבצים אבל צוואר הבקבוק בו קשור ל-NameNode. לסיום Gluster לא מאפשר Block Device או FS (אם כי פונקציונאליות זו אפשרית עם plugins).

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

Ceph

בחלק התחתון יש לנו את RADOS (ר"ת של Reliable, Autonomous, Distributed, Object Store) והוא החלק האחראי על אחסון הנתונים עצמם. מעליו יש לנו "גישות" שונות לנתונים:

  • גישת ה-APP, הגישה שמתאימה למפתחים: אתה יכול לגשת במספר שפות פיתווח שונות דרך ספריה שנקראית librados אל הקבצים (יש כמובן גם Authentication שלא כל אחד יוכל לגשת). זהו פתרון מעולה אם החברה מפתחת את הכל בעצמה או שהיא רוצה להתממשק עם ממשק משלה ל-Ceph.
  • גישת ה-RADOSGW – זו גישה שתואמת הן את S3 של אמזון והן ל-Swift של Open Stack, כך שאם יש לך קוד שניגש ל-S3, תצטרך שינויים מינוריים כדי לגשת לנתונים.
  • גישת RBD – בגישה זו אתה יכול ליצור ולקבל גישה אל Block Device, כאשר ה-Block Device הוא בעצם מורכב מאובייקטים שפזורים על פני ה-Nodes השונים באשכול Ceph. דרייברים קיימים כיום ללינוקס, ל-KVM ול-XEN, דרייבר ל-Hyper-V יצא בחודשים הקרובים ואחריו דרייבר ל-ESXi.
    ניתן גם לחבר Block Device לשרת לינוקס אחר, ומאותו שרת לינוקס לייצא את הבלוק כ-iSCSI או לפרמט את הבלוק ולהגיש אותו דרך SAMBA או NFS (דרך Ganesha)
  • גישת Client – מאפשרת לך להשתמש ב-CephFS כשרת קבצים לכל דבר ועניין, כאשר ה-FS יכול להיות XFS, BTRFS או EXT4. הלינוקס קרנל תומך בכך עוד מגירסאות 2.6.32 ומעלה.

אחד הדברים שצריך להפנים עם Ceph (וחלק מהפתרונות Scale Out שמבוססים בקוד פתוח) הוא שאין צורך ב-RAID יותר. אתה יכול להשתמש כמובן ב-RAID איזה שתרצה אבל אתה פשוט תפחית ביצועים למערכת כי היא בנויה מההתחלה להפיץ את החלקים השונים בין ה-Nodes. יש מקרים ש-RAID כן יכול לסייע לך כמו RAID-0 לשם Cache בין מספר כונני SSD. (כן, RAID-0 הוא לא לשם שרידות, אבל בין כה Cache אינו שורד).

Ceph, כמו ZFS, מפריד בין ה-Data ל-MetaData. כך לדוגמא אם יש לי תמונת נוף, אז התמונה עצמה היא ה-DATA אולם שם הקובץ, הרשאות גישה, היכן הוא מאוחסן ועוד פרמטרים – הם Meta Data והם נשמרים ב-Journal, רק שבניגוד למערכת לינוקס רגילה, מומלץ את ה-Journal לשמור על פרטישן בכונן SSD להאצת ביצועים (בדיוק כמו ב-ZFS את ה-SLOG מומלץ לשמור על SSD). בניגוד ל-ZFS שכותב קודם כל את ה-Meta Data והטרנזאקציה עצמה ל-SLOG ובכך מונע בעיה שבמקרה של הפסקת חשמל יאבדו הנתונים – עם Ceph מומלץ שבקר הדיסקים שלך יהיה עם סוללת גיבוי.

הגישה לדיסקים ב-Ceph נעשית ע"י Daemon מיוחד שנקרא OSD (או Object Store Daemon), זהו תהליך שרץ על כל דיסק. בעקרון, Ceph מפרמט כל דיסק שמוכנס אליו בברירת המחדל ל-XFS (אך אפשר להגדיר זאת ל-EXT4 או BTRFS) כפי שתוכלו לראות בתמונה הבאה:

osd

וכך נראים ערימה של שרתים שמחוברים עם הדיסקים שלהם בתמונה הבאה:

nodes

רואים את ה-M למעלה? ה-M מייצר את ה-Monitor, זהו עוד Daemon שלא רץ על כל השרתים והוא צריך לרוץ רק במספר קטן וחייב להיות במספר אי זוגי. תפקיד ה-Monitor הוא לוודא שהשרתים רצים בצורה תקינה ואם שרת לא רץ, אז מתקיים "תהליך הצבעה" בין המוניטורים כדי להחליט אם שרת נופל – מי השרת שיחליף את השרת הנופל.

mds

אחד הדברים ש-Ceph אימץ מתוך NFS-4 הוא רעיון ה-MDS (כלומר MetaData Server). גם הוא, כמו Monitor, רץ רק מספר קטן של פעמים (ולא בכל ה-Nodes), ותפקידו הוא בעצם להצביע היכן נמצאים האובייקטים ומה צריך להגיע ל-Clients. הוא לא מעביר את הקבצים עצמם ל-Clients כך שהוא תמיד פנוי לקבל פניות כדי להצביע היכן נמצאים קבצים. אם משתמשים ב-Ceph ולא משתמשים ב-CephFS אז אין צורך ב-MDS.

איך Ceph כותב קבצים אם הם מחולקים ל-Nodes שונים? ב-Ceph יש מושג שנקרא CRUSH (ר"ת Controlled, Scalable, Decentralized Placement of Replicated Data). הנה תמונה שמבהירה מעט יותר:

crush

אז CRUSH הוא אלגוריתם שלוקח בחשבון כל מיני פרמטרים ובהתאם – מאחסן חלקים של הקובץ בצוורה שווה בין ה-Nodes ב-Cluster. הוא עושה את החישוב בצורה מאוד מהירה. CRUSH (בסיוע ה-Monitor ו-OSD) יודע גם לטפל בבעיה אם נופל שרת או דיסק, הוא ידע מהיכן לקחת את הנתונים ולהיכן לשכפל.

נקודה חשובה שיש ל-Ceph זה שכל ה-Block Devices שהוא יוצר הם Thin Provisioned, כך שאם יש לך מאסטר אחד וממנו אתה רוצה להרים כמה מאות או אלפי VM ומהר, תוכל לעשות זאת ללא צורך בעשרות ומאות שכפולים. רק ה-Delta של השינויים עצמם יכתבו. כנ"ל לגבי Snapshots – ניתן ליצור Snapshots ו-Incremental Snapshots (כן, כמו ZFS). בכל הקשור לכתיבה, גם כאן, כמו ZFS, מערכת Ceph מבצעת Copy on Write, וכן, כמו ב-ZFS גם ב-Ceph יש Scrub (לבדיקת שלמות הנתונים על הדיסקים).

מכיוון ש-Ceph תהיה ממומשת במערכים גדולים של מאות ואלפי דיסקים, ישנה בעיה של מהירות כתיבה. אחרי הכל, אף גוף שפוי (אוקיי, רובם..) לא יסכים להכניס רק SSD, צריכים שתהיה גישה מהירה יותר וכאן Ceph שוב מעתיק מ-ZFS, רק שהוא לוקח את זה 10 צעדים קדימה ומאפשר לך דבר שנקרא Cache Tier. אתה יכול להגדיר לכל Pool היכן תשתמש בדיסקים מהירים (כמו SSD) לכתיבה מהירה, היכן הכתיבה תהיה איטית ועוד. תוכלו לקרוא על כך בהרחבה כאן.

כפי שאתם יכולים לנחש, Ceph זו חתיכת מערכת אחסון שמנסה לענות על כל הצרכים לחברות שצריכות אחסונים שונים ובצורות שונות. היא יכולה להחליף לדוגמא אחסון של Hadoop, אם החברה מריצה Open Stack אז היא יכולה לתת פתרון גם ל-Object Storage וגם Block לשרתים הוירטואליים, וגם לתת שרותי FS (אם כי כדאי לזכור שהחלק הזה עדיין בשלבי QA).

עד כאן הכל טוב ויפה, אבל אני מניח ש-3 שאלות צצות למנהלי תחומי IT:

  • האם יש GUI לכל הדבר הזה? התשובה, גם כאן, אינה בדיוק פשוטה. כן, יש GUI שיועד יותר לסטטיסטיקות (ונקרא Calamari), כמו מה מצב ה-IOPS שלך, כמה השתמשת והיכן, פילוחים שונים, מצבי דיסקים ועוד. לא, אם צריך לעשות תחזוקה לדברים – צריכים את זה לבצע דרך ה-Shell בלינוקס. וידאו של אותו GUI בסוף פוסט זה.
  • מי החברה שעומדת מאחורי זה? מי נותן תמיכה? (טוב נו, חוץ מהעסק שלי 🙂 ) – התשובה היא שרד-האט מוכרת כיום את Ceph ו-רד-האט ישראל משתתפת בפיתוח Ceph. (ד"ש חם ליהודה שדה מ-רד-האט ישראל).
  • מה עם תמיכה מלאה ב-Hyper-V ו-ESXi? בחודשים הקרובים תהיה תמיכה מלאה ל-2 המוצרים.

ולסיום, וידאו הכולל הדגמה של Ceph וה-GUI:

Comments

comments

תגובה אחת בנושא “על אחסון וגדילה – חלק שני”

  1. מתוך שלושה ישומים של isilon שפגשתי בשנה האחרונה. שניים היו (לראית המשתמשים והמתחזקים), אכזבה רבתי מבחינת ביצועים ושימושיות.
    האכזבה, לדעתי כמשקיף מהצד, לא הייתה תוצאה של טכנולוגיה שאינה בשלה בלבד. גורם מרכזי היה הנסיון ליישם scale-out לסביבה שלא הייתה מוכנה לכך.
    את אותו סוג של אכזבה ראיתי גם בשימוש חברות ב-Amazon.
    המאפיין העיקרי של כל הסביבות הללו היה בשימוש ב-NFS לניהול מליוני קבצים קטנים. זהו אתגר לא פשוט גם בפתרונות שמרניים של scale-up, אך פתרונות scale-out מוסיפים שכבות תקשורת וניהול שיכולים לפגוע בתפעול ובבצועים בצורה משמעותית.
    הלקח שלי הוא שנחוץ שינוי תפיסה בצד לקוחות התכנה על מנת ליישם פתרונות מסוג זה. זהו שינוי בכלים ובהרגלי העבודה שאינו פשוט. כלי כמו Git (לצורך הדוגמה) מניח קיום מערכת קבצים היררכית קלסית (כמו דיסק או NFS) שמוקצית דרך fstab או שווה ערך.
    רק כאשר הכלי יוכל לעבוד מול מערכות איכסון כמו S3 (בין אם משינוי קוד פנימי או מספריות מתאימות במערכת ההפעלה) ניתן יהיה לראות את התועלת האמיתית של ה-Scale-out.

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *