תכירו: Red Hat Storage One

חברת Red Hat הכריזה אתמול על פתרון חדש לסטורג' לחברות שנקרא Red Hat Storage One. הפתרון עצמו הוא די פשוט: אתה קובע פרמטרים מסויימים, אנחנו אומרים לך איזו מערכת יכולה לתת לך את מה שאתה רוצה ומוכרים לך אותה אין צורך ברכישת רשיונות נוספים. אתה רוכש בעצם מחברת Red Hat – ברזל מוכן. הקץ להתקנות ו-1001 קונפיגורציות וכך זה נראה (לחצו להגדלה):

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

אז רד-האט מוציאים את Red Hat Storage One כפתרון סטורג'. זהו הפתרון הראשון ובהמשך יהיו פתרונות נוספים שלא מבוססים על GlusterFS אלא גם על Ceph, וכאן בד"כ נמצאת הבעיה בד"כ – לדעת את ההבדלים בין GlusterFS ל-Ceph ומה מתאים למה (ולא, הם לא מתאימים לכל הצרכים).

בוא נסתכל לשם הדוגמא בכל סטורג' קנייני בינוני. סביר להניח שאותו פתרון סטורג' יתן לך את כל מה שתרצה. רוצה להקים LUN ל-iSCSI? אהלן. שיתוף קבצים? שלם רשיון ויש לך CIFS. רוצה NFS? שוב, רשיון – ויש לך את זה. רוצה snapshots? אולי clones? זה בפנים. רוצה לגבות את הסטורג'? תצטרך תוכנה יעודית – אבל זה אפשרי. רוצה Cluster לסטורג'? זה אפשרי, תכין צ'ק שמן :).

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

  • גישת קבצים – CIFS או NFS – מערכת GlusterFS בנויה כולה על גישת קבצים ואת זה היא יודעת לעשות בצורה מהירה (במיוחד אם הכנסת כרטיס PCIe ל-Nodes עם 3DXpoint של אינטל). צריך Cluster של CIFS או NFS שגם יכול לגדול? GlusterFS הוא הפתרון. אם תנסו את Ceph ל-CIFS או NFS, תקבל בערך 50% פחות בביצועים מהסיבה הפשוטה ש-Ceph עובד מבפנים על Object Store וכך הוא מאחסן הכל, כך שכל גישה לקובץ מצריכה מהמערכת "להרכיב" את הקובץ מאובייקטים ולהגיש אותו, ולפני כן על ה-Client לברר דרך אחד משרתי ה-MDS איפה בכלל הקובץ נמצא, איזה Node זמין וכו', כך שאם אנחנו צריכים להעתיק 1000 קבצים – עשו את זה לקראת היציאה מהעבודה באותו יום, זה יקח זמן.
  • Block Storage. בסטורג' קנייני עניין ה-iSCSI ו-LUN מבוצע בד"כ ברמת חומרה + שימוש ב-NVRAM, כך שהביצועים מאוד גבוהים. ב-GlusterFS זה אפשרי, אבל הביצועים לא יהיו גבוהים כי המערכת לא מכוונת לעשות את זה (אבל למי שמתעקש – זה אפשרי אך עדיין תצטרך באמצע מכונה "מתווכת"). ב-Ceph לעומת זאת גישת Block Storage היא אפשרית בהחלט וזה עובד מעולה, במיוחד אם משתמשים במערכת OpenStack למכונות וירטואליות וקונטיינרים (או Swift). מצד שני יש תמיכה ב-iSCSI אבל שוב, יש צורך ש-2 מכונות (בשביל HA) שיבצעו המרה מ-Raw Block Device ל-iSCSI החוצה.
  • סטורג' לקונטיינרים או Object Store – כאן Ceph מנצח מבלי להתאמץ אפילו. הבסיס העיקרי של Ceph לכל הקבצים הם אחסון אובייקטים, כך שאם החברה רוצה להקים אחסון מדמה S3 כחלק מפתרון ל-OpenStack – אז Ceph נותן פתרון מעולה. גם כאן ל-GlusterFS יש פתרון אבל אם רוצים משהו גדול או ענק לאחסן מיליוני אובייקטים – Ceph עדיף.
  • פתרון Hyper Converge המשלב את הסטורג' יחד עם מכונות וירטואליות. כאן התשובה פשוטה: GlusterFS. מערכות Ceph צריכות להיות מוקמות על שרתים פיזיים נפרדים (שזה מה שהם יעשו בלבד) ו-Ceph אינו פתרון Hyper Converge (וכן, בדקתי, זה הזכיר לי את מהירות טעינות משחקים מקלטות בקומודור 64…).

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

כתיבת תגובה

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

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