כמה מילים על פתרון סטורג' (קוד פתוח) משולב

לא מעט חברות מחזיקות ברעיון שפתרון אחסון (Storage) צריך להיות פתרון קנייני בצורת כמה חלקים (כולל "ראש") ומדפים של דיסקים. בשנים האחרונות יותר ויותר חברות מאמצות גם את רעיון ה-Hyper Converge – ערימה של שרתים שנותנים אחד לשני (והחוצה) את כל השרותים ביחד – רשת, דיסק, מחשוב, ובמקרים של Open Stack – שרותים נוספים.

הבעיה בד"כ היא במחשבה או בתכנון מעבר. אם לדוגמא יש לכם פתרון וירטואליזציה של VMWare ותרצו ליישם את VSAN, ההשקעה תהיה גבוהה. על כל שרת ממוצע תצטרכו לשלם 5000$ וזה עוד לפני הדיסקים והתצורה היחודית שיש צורך ב-VSAN (על כל 2 דיסקים מכניים או SSD בינוניים, דיסק SSD מהיר או Mixed Intense או ביחד). במקרים אחרים יש פתרונות HyperConverged כמו Nutanix, Simplivity וכו' שבסופו של דבר מחייבות אותך לרכוש כמעט הכל מחדש (אם כי כמובן אפשר במקרים מסויימים להשמיש שרתים שונים, תלוי מה ה"גיל" שלהם).

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

גם במקרים של פתרון קוד סגור או קוד פתוח, נצטרך דבר ראשון להעיף מבט על השרתים שיש לנו. רוב השרתים שמריצים פתרון וירטואליזציה כלשהי, אנחנו נראה שרוב התושבות בשרתים – פנויים (וכמובן שיצרני השרתים מנצלים זאת על מנת לתת פתרון Backplane חלקי, כך שגם אם תרצה למלא 24 דיסקים 2.5" בשרת, לא תוכל אלא אם תרכוש עוד 2 backplanes עם החיבורים. בד"כ ה-backplane שאתה מקבל בשרת יכול לחבר מקסימום 8 דיסקים), כלומר שמבחינת השקעה בברזלים אם נרצה פתרון סטורג' מבוזר, נצטרך לרכוש פתרונות backplane לשרתים, וכמובן דיסקים מכניים, SSD (מסוגים שונים – read intense או mixed Intese – תלוי בתקציב ובמה שאתם רוצים לעשות). נקודה נוספת שנצטרך לקחת בחשבון זו הרחבת זכרון. אין צורך "להשתולל", בד"כ לפתרון SDS נצטרך 16 או 32 ג'יגהבייט זכרון. הנקודה האחרונה שיכולה להיות קצת יקרה היא רשת – אנחנו נצטרך בכל מכונה חיבור של 10 ג'יגהביט לתקשורת פנימית בין ה-VM שמריצים את פתרון ה-SDS.

את פתרון ה-SDS נריץ כ-VM בתוך כל מכונה, אולם אנחנו צריכים קודם כל להחליט איפה בעצם לאכסן את הנתונים, באלו דיסקים. דיסקים בגודל 2.5" לדוגמא יהיו קצת בעייתיים כי כמות ה-DATA שאפשר לאכסן בהם היא לא גדולה אך המחיר הוא די גבוה. אם לדוגמא נדמיין שאנחנו מכניסים 20 דיסקים של 1 טרה בגודל 2.5", ועוד 2 דיסקים SSD שישמשו כ-Cache, אז נקבל "ברוטו" 20 ג'יגהבייט. אולם אם נחליף את הפאנל הקדמי (כולל הלוח המוצמד) לגירסת LFF (כלומר Large Form Factor), אז נוכל להכניס 12 דיסקים של 4 טרהבייט, אז נקבל "ברוטו" 48 טרהבייט ומחירי הדיסקים הללו יהיו יותר זולים מ-20 דיסקים של 2.5" (בד"כ נוכל להכניס 2 דיסקים SSD ל-Cache מאחורי השרת). מבחינת הוירטואליזיציה, אין לנו צורך להתקין אותה (בגירסת vSphere) על הדיסקים המקומיים, 2 כרטיסוני מיקרו SD יוכלו לעשות את העבודה. (בין כה כמות הכתיבה אליהן מאוד קטנה ואם כרטיס נופל, כרטיס שני "לוקח פיקוד") כך שאנחנו יכולים בסופו של דבר להצמיד את כרטיס ה-RAID ל-VM עצמו ולקבל מקסימום ביצועים.

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

כעת, כל מה שנותן לעשות זה לחבר את הדברים. בכל מכונה נקים VM עם הפצת לינוקס כלשהי (GlusterFS קיים לכל הפצת לינוקס שתרצו), להגדיר אם אנחנו מעוניינים בשכפול והפצת קבצים (אפשר לראות את האפשרויות כאן, פוסט מורחב על הנושא יהיה בקרוב) ומאותו פתרון SDS נוכל להגדיר שיתופים איך שנרצה: CIFS, NFS, iSCSI ועוד. כך נוכל להנות גם מפתרון SDS יציב, שיכול לעמוד במצב ששרת או 2 נופלים (תלוי איך הוגדר GlusterFS, בד"כ הגדרות ברירת מחדל יתנו HA כך שאם מכונה נופלת, השניה לוקחת פיקוד), גם נוכל להרחיב את הפתרון בהמשך (הוספת דיסקים, JBOD, מכונות נוספות) והכי חשוב – נוכל להנות מפתרון שנותן גם ביצועים מהירים וגם התחזוקה עצמה תהיה די מינימלית.

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

פתרון GlusterFS – היכן הוא מתאים לכם?

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

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

נתחיל בהצהרה די פשוטה: למרות שטכנית ניתן לבנות את GlusterFS כפתרון שיכול לתת "פייט" רציני לכל פתרון אחסון Scale Up מסחרי, לא תמצאו אותי מחר אץ רץ לחברות תקשורת, בנקים וכו' וממליץ להם בחום לזרוק את פתרון האחסון שלהם לטובת GlusterFS, בדיוק כמו שפתרון VSAN של VMWare אינו פתרון להחליף סטורג' רציני עתיר משאבים. אלו 2 דברים שונים לחלוטין.

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

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

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

סיטואציה ראשונה
כאחד שנותן שרותי תמיכה ל-vSphere לגרסאותיו השונות, יש לי מילים חמות לאמר על VSAN. זהו פתרון אמין מאוד עם שרידות גבוהה מאוד ללא צורך בסטורג'. עם VSAN אפשר להגדיר פונקציות שונות כמו פונקציית שרידות מאוד גבוהה כך שמתוך קבוצה של 3 שרתים פיזיים, 2 נכבים, אפשר להגדיר ש-VM קריטי עדיין ישרוד.
הבעיה המרכזית עם VSAN אינה טכנית, אלא בעיה כספית. במחיר של $2500 לרשיון פר מעבד, על קבוצה של 3 שרתים פיזיים, אנחנו מדברים על 15,000$ וזה לא כולל את הרשיון היעודי של vSphere ולא כולל תמיכה של 3 שנים (שזה עוד 15,000$) ועוד לא הגענו בכלל למחירי הדיסקים – במיוחד שעם VSAN חובה ללכת בתצורת קבוצות של 2+1 (כלומר 2 דיסקים מכניים ו-1 SSD אם כי אפשר ללכת בתצורה היותר יקרה של 3 SSD ונוסיף לכך שאתה צריך שרתים מהדור האחרון או לפניו כדי להריץ את כל הדברים. מחיר כזה, לדעתי, אינו מוצדק עבור Dev, stage, testing, POC וכו'. במחיר כזה חברות כבר יחשבו על קניית אחסון יעודי.

במקום זה, אנחנו יכולים לקחת 3 מכונות שדווקא אינן חדשות (כל עוד בקר הדיסקים שלהם תומך ב-6 ג'יגהביט SATA/SAS, אם זה תומך רק ב-SATA 2.0, אז אפשר להכניס כרטיס בקר צד ג') כמו דור 7 של HP, דור 11 של DELL, דור 3 של LENOVO, ולמלא אותן בדיסקים. ניקח דוגמא: 10 דיסקים SATA של WD RED PRO (מחיר של 319$ באמזון פר דיסק, המחיר קצת יותר יקר אצל המפיץ בארץ) או WD GOLD Enterprise בגודל 10 טרה שעולה $361 פר דיסק, או Seagate מסידרת EXOS ל-Enterprise בגודל 10 טרהבייט שגם עולה $360. סה"כ עד כה – בערך $3600 (פר שרת). נוסיף עוד 2 דיסקים SSD – אם מחפשים זול וטוב, אז 2 דיסקים מה-850 PRO של סמסונג יוכלים לעבוד טוב (סה"כ 418$)ואם המכונה היא 2U, אז 2 כרטיסי SSD PCIE מסוג אינטל 900P 280GB AIC בתצורת PCIE (סה"כ 780$) יכולים לתת Cache די רציני למכונה.

ניקח את הבקר (ואת כרטיסי ה-PCIE) ונצמיד את כולם למכונת VM, נצמיד לה 32 ג'יגהבייט זכרון ו-4 ליבות, ועליה נרים GlusterFS (אם אתם מעוניינים בדחיסה, Dedup ושאר תפנוקים – יש צורך להקים עליה ZFS ועל זה GlusterFS), נחבר את המכונות ברשת פרטית וברשת "ציבורית") (כלומר 2 כרטיסי רשת וירטואלית פר VM של GlusterFS) והרי לנו תחליף ל-VSAN שיכול לתת לנו iSCSI, CIFS, NFS, אחסון אובייקטים (Object Storage) ועוד ועוד. בשביל ביצועים ושרידות נצטרך עוד מכונה כזו (עדיף עוד 2) – ויש לנו אחסון עם שרידות חזקה וביצועים גבוהים, ובו זמנית אפשר להריץ על השרתים עוד מכונות VM, ואת כל זה נעשה דרך ה-vSphere, כך שמבחינת עלות – שילמנו רק על החומרה ולא הפכנו את השרתים היעודיים לסטורג' בלבד (כך שלא נצטרך לבזבז שרתים). מבחינת גיבוי – זה VM ואפשר לגבות בכל תוכנה שמשתמשים בחברה (רק שחשוב לזכור לא לגבות את כל ה-VM שמריצים GlusterFS אלא רק אחד, חבל לשמור את הנתונים באותו גיבוי 3 פעמים).

סיטואציה שניה – אפליקציות
קונטיינרים הם ה"שוס" בשנתיים האחרונות ורבים מעבירים חלק מהמערכות לרוץ בקונטיינרים, שזה מעולה, אבל בחלק מהמקרים עדיין מעדיפים להריץ אפליקציות מסויימות בהכפלה וכו', לדוגמא MySQL על 2-3 מכונות VM, שרתי Front ו-Back על מספר מכונות VM ועוד. בכל המקרים הללו, באותם שרתים ניתן להקים GlusterFS כ-VM כמו שתיארתי לעיל (עם פחות דיסקים, רק חשוב שיהיה לפחות SSD אחד שישמש כ-Cache) ואז ה-DATA של האפליקציה (לדוגמא עם MySQL התיקיה var/lib/mysql/) תשב ב-GlusterFS (איך עושים? עוקבים אחרי ההוראות כאן), ה-WWW של שרת ה-Web ישב ב-GlusterFS וכו' וכו'. יהיו מספר שינויים קטנים שצריך לבצע (אולי להשתמש ב-HAProxy), וכך נוכל לקבל שרידות רצינית ומהירות משופרת בהרבה מכיוון שכל שרת אפליקציות יכול לקבל נתונים משרת GlusterFS קרוב וסינכרון הנתונים הוא מיידי – מבלי להשקיע כספים רבים.

סיטואציה שלישית – קונטיינרים/Kubernetes/Openshift
קונטיינרים רצים בד"כ על שרתי VM וקבצי ה-YAML, קבצי קונפיגורציות יושבים על דיסקים מקומיים אך ניתן להגדיר את ה-VM שירוצו על דיסקים וירטואליים שה-vSphere יקבל מ-GlusterFS דרך NFS או iSCSI. בנוסף, ניתן להגדיר Volumes עבור ה-Pods שישתמשו ב-GlusterFS (גם Kubernetes וגם אפליקציות שמריצות את Kubernetes כמנוע כמו Rancher, OpenShift וכו' תומכים ב-GlusterFS החל מ-Kubernetes 1.5). ואנחנו יכולים להשתמש לדוגמא ב-Volume מסויים במספר Pods במקביל, ועם GlusterFS ניתן לוותר על הרצת קבצי YAML/JSON ליצור את ה-Volumes ולגשת ישר ל-Volume Claim, המערכת תיצור את ה-Volume אוטומטית.

סיטואציה רביעית – בענן
מכיוון של-GlusterFS לא אכפת מה נמצא מתחתיו (דיסק מסכן, EBS וכו'), אפשר להקים את GlusterFS גם בענן. כל מה שאנחנו נצטרך הם מספר Instances (מומלץ 3 ומעלה לפרודקשן, 2 לטסטים) ולאותם Instances (שישמשו כ-Nodes) נחבר 2-3 אחסוני EBS ונתקין את GlusterFS ומשם אנחנו יכולים להשתמש ב-GlusterFS כפתרון אחסון לצרכים שלנו.

סיטואציה חמישית – קרוב רחוק
הקמה של GlusterFS זה דבר טוב ועוזר, אולם לפעמים אנחנו צריכים את הנתונים בחוץ, בחוות שרתים אחרת בארץ או בחו"ל. לשם כך, החל מ-GlusterFS 3.8 ומעלה ניתן להריץ Geo Replication לסנכרן בין מספר Volumes (בשיטת Master/Slave), ואפשר גם לספק צרכים "מופרעים" כאלו:

סיטואציה 6 – פתרון אחסון ל-VDI
הקמת VDI למאות עובדים זה פרויקט מורכב עם עלויות אסטרונומיות. (בימים אלו אני מנסה בבית להקים פתרון VDI עם דגש על מחירים נמוכים, ברגע שאצליח, אפרסם פוסט על כך). יש צורך לשלם למיקרוסופט, ל-VMWare וכמובן כל נציג מכירות יאמר לך – All Flash Array, כך שאם תרצה פתרון VDI טוב, תחשוב על כך סכום של 7 ספרות.

האם GlusterFS יכול לחסוך כאן במחיר? התשובה היא בהחלט. נתחיל בגירסה הזולה: זוכרים שהמלצתי על השרתים הישנים להרצת GlusterFS? אנחנו נשתמש בכאלו בגודל 2U עם פאנל קידמי של כונני 2.5 אינטש כך שאפשר יהיה להכניס בין 16 ל-24 דיסקים 2.5". לתוכם נכניס דיסקים 850 PRO של סמסונג בגודל שתבחרו, יש עד 2 טרהבייט (יש לוודא שהבקר דיסקים תומך במצב JBOD ושהוא תומך ב-SATA-3, אם לא – יש צורך בבקר אחר) ונכניס את הדיסקים הנ"ל למגירות ונצטרך לרכוש או אינטל 900P בגודל 480 ג'יגה או 2 כרטיסי אינטל 900P בגודל 280 ג'יגה, הכל לפי התקציב (עם 2 כרטיסים השרידות הרבה יותר גבוהה). על כל שרת כזה נקים ZFS עם Hot Spare ל-2 דיסקים SSD. כל ה-RAID יוגדר דרך ה-ZFS (כלומר RAIDZ לפי תצורה שמחליטים) ועל זה נקים את GlusterFS. את החיבור בין השרתים נחבר ב-10 ג'יגהביט (נחושת, SFF, FC – החלטה שלכם) ואת הזכרון נמלא ב-ECC 3 8500R (שהוא פחות מהיר אבל המהירות אינה ממש חשובה כשהשרת משמש Node ל-Gluster, הזכרון משמש בראש וראשונה כ-Cache ב-ZFS) עד המקסימום. המחיר לא כזה יקר: 2000 שקל (תלוי מהיכן אתם קונים) ל-192 ג'יגהבייט זכרון. נצטרך 3 מכונות. שימו לב: בשרת כזה נרוץ "על הברזל" ללא וירטואליזציה כלל ונוכל לגבות אותו כמו כל תחנת לינוקס (אם כי צריך לגבות רק אחד מהם, לא את שלושתם).

אם יש לכם כמה וכמה שרתים ישנים, אפשר לפצל את כמות הדיסקים לפי כמות השרתים הישנים שלכם (לדוגמא – 6 דיסקים בשרת 1U) ובכך לקבל ביצועים יותר גבוהים הואיל ולא מדובר בסיטואציית Active/Passive אלא עבודת קריאה/כתיבה מקבילית לכל המכונות.

אם מצד שני יש תקציב – אפשר לרכוש 3 שרתים כשהפאנל הקדמי שלהם הוא NVME ונרכוש דיסקים NVME U.2 – גם סמסונג וגם אינטל מוכרים דיסקים מעולים, והעלות משתנה לפי גודל הדיסק והפירמה שקונים ממנה. מבחינת רשת, תצטרכו לחשוב איך לחבר את הכל מכיוון שברוטו, תעבורת הקריאה מגיעה בין 40-60 ג'יגהבייט לשניה. אפשרי לצמד מס' כרטיסי רשת 10 ג'יגהביט או לרכוש כרטיסים ו-Switch של 40 ג'יגהביט (מלאנוקס, אינטל וכו' ישמחו למכור לכם). עם ההצעה הזו, המחיר שתצטרכו לשלם בהשוואה לפתרון אחסון מבוסס AFA (כלומר All Flash Array) יהיה נמוך יותר ב-50-70% מפתרון קופסא, וגם יש לכם שרידות יותר גבוהה.

בכל שאר הפרמטרים (וירטואליזציה, רשיונות וכו') – הכל נשאר אותו דבר.

ומה עם תמיכה? רד האט מוכרת את פתרון ה-GlusterFS כמוצר (Red Hat Gluster Storage) עם תמיכה מסביב לשעון.

לסיכום: GlusterFS יכול לשמש לדברים רבים ולחסוך כספים רבים עם ביצועים גבוהים (פי 2 מ-Ceph פר קריאת בלוק) ושרידות חזקה ולתת מענה לצרכים שונים. אפשר להגדיר GlusterFS מדבר פשוט כמו דיסקים וירטואליים ועד שילוב של ZFS עם ערימות של דיסקים ולקבל מהירויות גבוהות מאוד.

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

אחד מול השני: Ceph מול GlusterFS

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

2 הפתרונות שבגינן יש בלבול רב הם GlusterFS מול Ceph. למרות ש-2 הפתרונות הם פתרונות Scale Up, יש שוני גדול ביניהם שכדאי להכיר לפני שחושבים לאמץ פתרון זה או אחר.

נתחיל ב-Ceph. מערכת Ceph היא מערכת "חייתית" שהמטרה שלה אחת היא: לתת ביצועים מקסימליים לחברות שמוכנות להשקיע בתשתית. באופן עקרוני, מערכת Ceph שולטת במכונות האחסון בדברים מ-א' ועד ת' – הן שולטות על הדיסקים, המערכת שולטת לאן כל דבר יכתב ואיך יכתב ומהיכן צריך לשחזר ואיך לשחזר במקרה שקם צורך להתקין מכונה אחרת במקום אחת שהלכה, ובגלל זה חישוב האחסון הוא מעט שונה: על כל ג'יגהבייט שתרצה לאחסן, תצטרך בדיסקים מקום של 3 ג'יגהבייט לערך (יותר בכיוון 2.4) ומכונה אחת אינה מספיקה, יש צורך ב-3 מכונות (כאשר כל מכונה היא בעצם שרת 2 או 3U מלאה בדיסקים מכניים וחלק SSD) עם הרבה זכרון, רוחב פס של 40 ג'יגהביט (המינימום הוא 10 ג'יגהביט) ועם מעבדים חזקים, כך שכל דרישה להגדיל כמות אחסון או מענה מבחינת מהירות ורשת ללקוחות – מצריך הוספה של מכונות (במדריך ההטמעה של SuSE לדוגמא יש "רשימת קניות" מה הדרישות חומרה פר Node).

מי שיציץ בלינק יחשוב בוודאי שזה נשמע מוגזם מבחינת דרישות חומרה, וכאן בדיוק העניין: זהו פתרון שאינו מתאים לחברות קטנות ובינוניות. זה פתרון שיכול להתאים לבנקים, קופות חולים, חברות ביטוח, חברות פיננסיות גדולות שיש להן המון DATA ואותם נתונים אמורים להיות זמינים בכל דקה, 24/7/365 ועם Latency מאוד נמוך. האם הן כבר אצות רצות להטמיע? התשובה היא "עדיין לא". מנמר"ים, מנהלי IT ו-CTO רבים צריכים בשביל זה "להחליף דיסקט", וכשאני שומע מהם שהם מחפשים פתרון שיהיה Active/Active או Active/Passive אז אני מבין שהם עדיין לא ממש "נכנסו לראש" של Scale Out.

ולמי שמתעניין במחיר – לא חשוב כמה Nodes יהיו במערכת כזו, היא תמיד תהיה יותר זולה ממערכות Scale Out של היצרניות סטורג' הוותיקות ויחד עם זאת הן יכולות לתת ביצועים ופונקציונאליות בדיוק כמו הפתרון הסגור.

עם GlusterFS המצב שונה לחלוטין. נתחיל בכך שאם ב-Ceph כל השרת 2U/3U מיועד לשימוש הסטורג', ב-GlusterFS המצב הפוך. אם לדוגמא אתם מריצים vSphere/ESXi, אז אתם בוודאי מכירים את העניין שאפשר לעשות boot ל-ESXi מ-Disk on key או PXE ואין צורך בדיסק קשיח מקומי להתקנת ה-OS, אז אפשר על אותה מכונה להקים ESXI, להקים VM עם נניח 16 ג'יגהבייט זכרון, ולמפות אל ה-VM את כרטיס ה-RAID עם הדיסקים. ונצטרך להגדיר גם 2 חיבורי רשת פיזיים (האחד לקבל שרותים מה-Gluster והשני לחבר את כל המכונות שישתתפו ב-GlusterFS). לא צריך שרת חדש נוצץ מהניילונים, גם שרת R610/R710 דור 11 של DELL, שרתי HP G7, שרתי X3550/3650 M2 של לנובו/IBM יתאימו למטה (כל עוד הבקר תומך ב-SATA במהירות 6 ג'יגהביט), אפשר למלא דיסקים פשוטים (WD RED PRO ואחרים שנותנים מהירות 7200 RPM) ואולי 1-2 דיסקים SSD בחיבור SATA. שאר משאבי המערכת ישומשו טובת הרצת אפליקציות אחרות, מכונות וירטואליות, קונטיינרים (בפוסט קרוב אדגים איך Gluster FS יכול לעזור ל-Kubernetes בכך שתצטרך מעתה לבקש רק Volume Claim מבלי ליצור Volume, המערכת תיצור אוטומטית וניתן לגשת לאותו Volume ממספר קונטיינרים במקביל) וכו'.

גם כאן, כמות המכונות המשתתפות ביצירת Volume יכולה להיות מינימום 2 אך עדיף ברוב המקרים להתחיל עם 3, רק שכאן אם אתם רוצים להישאר עם 3 ולהוסיף דיסקים לדוגמא, חברו JBOD עם הדיסקים, צרו מהדיסקים דבר שנקרא Brick, והוסיפו אותו ל-Volume קיים. זה יספיק. מבחינת File system, ל-Gluster FS זה כלל לא משנה. תקים ZFS על הדיסקים ועל זה תריץ GlusterFS? אין בעיה. תרצה לפרמט עם בקר ה-RAID שלך את כל הדיסקים לאיזה RAID מסוים ועל זה להריץ GlusteFS? אין שום בעיה. גם כמות הדיסקים אינה ממש משנה, ואפשר אפילו להתחיל בדיסק יחיד (לא כל כך מומלץ אלא אם זה דיסק וירטואלי).

עכשיו החלק היותר מעניין: החלק הכי קריטי בבחירת מערכת זה החלק של השרותים. איזה שרותים אפשר לקבל עם הפתרון? גם עם Ceph וגם עם Gluster FS, אתה יכול לקבל את אותם פתרונות. רוצה iSCSI MP? יש. NFS כולל גירסה 4.1 או PNFS? יש. רוצה Object Store? יש. שרידות במקרה ששרת פיזי נופל? יש. מחפש Deduplication? ב-Gluster FS ניתן לקבל זאת כשמפרמטים את הדיסקים עם מערכת ZFS ובדרך גם ניתן לקבל דחיסה. (ב-Ceph כרגע אין את זה). מה עם Caching ו-Erasure Coding? יש ב-Ceph ויש גם ב-Gluster FS, וכן, לשתיהם יש גם ממשק WEB.

מה עם שרות ותמיכה? לגבי Ceph – גם SuSE ישראל וגם רד-האט ישראל (דרך הנציגים שלהם בארץ) מוכרים חבילה מסחרית ותמיכה מסביב לשעון של Ceph (ב-Suse זה נקרא SuSE enterprise storage 5, ב-רד-האט זה נקרא Red Hat Ceph Storage) עם תמיכה מסביב לשעון. כשזה מגיע ל-Gluster, רד-האט מוכרת את Red Hat Gluster Storage. אני ממליץ לשים לב לנקודה עקרונית: לא מומלץ להתקין את התוכנות אם אתם לא קונים ואין לכם מישהו שיתמוך לכם בתוכנה. נכון, Gluster FS לוקח חצי שעה להקים, אבל כשהתקלות מתחילות, אם אין ידע, זה כאב ראש (במיוחד ב-Ceph).

לסיכום: למי שמחפש פתרון סטורג' Scale Out, אלו 2 פתרונות טובים עם "גב" מאחוריהם. הפתרון של Gluster הוא טוב והוא יכול לתמוך גם בפטהבייט בלי שום בעיה והוא יכול להתאים לכל גוף שמחפש לעצמו פתרון אחסון חזק עם שרידות מעולה. הפתרון של Ceph לעומת זאת הוא פתרון "מפלצת" שנועד בראש ובראשונה לשרת אלפי, עשרות אלפי ומאות אלפי לקוחות בו זמנית ובנוסף, 2 הפתרונות נותנים לכם חופש מוחלט בבחירת הציודים שישמשו לאותו פתרון סטורג', כך שאין צורך יותר לשלם אלפי שקלים נוספים פר דיסק בגלל .. מדבקה (וכן, אני עומד מאחורי ההצהרה הזו). פתרון Active/Passive או Active/Active זה אחלה, אבל פתרון עם 3 מכונות נותן שרידות הרבה יותר טובה וגם נהנים ממהירות הביצועים.

כמה מילים על GlusterFS

קשה לדמיין היום חברות ללא פתרונות Storage. יש חברות שקונות את הפתרונות של היצרנים הגדולים כמו IBM/NetApp/EMC או פתרונות בינוניים של Dell ו-HPE וכמובן פתרונות אחרים כמו Kaminario ועוד.

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

במקרים כאלו יש בד"כ יש סוגי פתרונות גנריים:

  • רכישת קופסת NAS מחברות כמו QNAP, Synology ואחרות. עם קופסאות כאלו, ההגדרות הן פשוטות, המערכת תשלח לך התראות אם יש בעיה, ולאחר שהגדרת את הדברים כל מה שנותר לעשות זה להגדיר למשתמשים חיבור לאותו NAS. החסרון בשיטה זו הוא שאם הקופסא קורסת מסיבה כלשהי (זכרון, רשת, לוח אם, ספק כח) – אותה קבוצת משתמשים תהיה מושבתת עד לתיקון הקופסא.
  • הסבת שרת ישן בכך שנכניס לו דיסקים ונחבר לבקר RAID מקומי, מכניסים זכרון, ומקימים שרות File Storage כלשהו בהתאם לפרוטוקולים שאנו רוצים (NFS, CIFS, iSCSI וכו'). זהו פתרון שמצריך ידע בלינוקס שעובד בד"כ לא רע. החסרון – אם אין לכם ידע בלינוקס, תצטרכו מישהו שמבין ולשלם לו בנפרד ובנוסף – גם כאן, אם יש בעיית חומרה (שאינה דיסק) – המערכת מושבתת עד שהיא תתוקן.

אז מה עושים שצריכים שרידות או שרוצים לגדול?

חברות כמו QNAP ו-Synology ישמחו למכור לכם קופסאות שרתים בגודל 2U (בד"כ) בצמד כך שתוכלו לעבוד במצב Cluster אקטיבי/פאסיבי או אקטיבי/אקטיבי תמורת אי אלו אלפי דולרים נוספים. בפתרון השני שתיארתי לעיל אפשר לעבוד עם פתרונות כמו DRBD ו-PaceMaker/Corosync על מנת לקבל את אותה תוצאה כמו הפתרון המסחרי, אבל הבעיה הגדולה ב-2 הפתרונות היא שלא ניתן לגדול מבחינת הוספת עוד שרתים, כלומר אפשר לעשות Scale Up (הוספת JBOD, דיסקים, זכרון, ואולי גם להוסיף כרטיס רשת או מעבד, תלוי במכונה), אך לא ניתן לבצע Scale Out – כלומר לגדול ממצב של 2 מכונות למצב של 3, 4 ומעלה כאשר כולן משתתפות באותה משימה.

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

מערכת GlusterFS, בניגוד למערכות כמו CePH אינה מתערבת ב-File System שלך. רוצה לבנות שרת עם כרטיס RAID וכמות דיסקים ב-RAID-5/RAID-6/RAID-10/RAID-1 וכו'? אין שום בעיה. תגדיר, תפרמט, תבצע Mount וזהו. רוצה לעבוד עם ZFS? תכין Pool ו-DataSets שיהיה להם Mount Point וזהו. מערכת ה-GlusterFS רוצה את ה-Mount point כנקודת התחלה. מה קורה מתחת? לא מעניין אותה.

עם GlusterFS, החל מהרגע שיש לנו Mount Points, מאותו רגע ה-Mount Points בשבילה זה דיסק קשיח שב-GlusterFS נקרא "Brick" (לבנה), ועם ה"לבנים" הללו אנחנו בונים Volume, וכאן אנחנו צריכים להחליט איך אנו בונים Volume בהתאם לכמות המכונות. האם אנו רוצים רק רפליקציה בין 2 מכונות או שאנחנו רוצים משהו שיפיץ את הנתונים בשרתי הקבצים השונים (מעל 3)? יש 9 אפשרויות לכך וניתן לקרוא עליהם כאן.

אחרי שיצרנו את ה-Volume (תמיד ניתן להגדיל אותו ולהוסיף Bricks נוספים) אנחנו צריכים להחליט דרך איזה פרוטוקול אנו משתפים את הנתונים החוצה, כמו NFS, CIFS, iSCSI, S3 ועוד, ואנחנו משתמשים בכלים השונים שתומכים באותם פרוטוקולים כדי לשתף את ה-Volume. זהו אותו Volume ש-GlusterFS מנהל עבורנו כך שכל דבר שנכתוב או נקרא – קיים בכל השרתים לפי הגדרות ה-Volume שהגדרנו. מבחינת הכלים שמממשים את הפרוטוקולים, אין להם מושג ירוק מה זה GlusterFS.

ומה עם שרידות? אנחנו נשתמש ב-PaceMaker/Corosync שיתנו לנו את השרידות, נוכל להוסיף כתובת IP שנותנת לנו גישה לאחת המכונות ב-Round Robin וכשהשרת שפנינו אליו נופל, המשתמשים "יוזזו" למכונה אחרת. אנחנו גם נוכל להשתמש ב-Round Robin ב-DNS (או דרך Load Balancer אם יש לכם) כך שכל ה-Clients ימשיכו לקבל את אותו שרות, גם אם שרת כלשהו מהחבורה נופל.

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

בוידאו קליפ הבא אני מסביר בקצרה על GlusterFS וכן מדגים אותה על 2 שרתי לינוקס + מכונת לינוקס שמשמשת כ-Client.

https://www.youtube.com/watch?v=0yo2nJcF9N8