אחסון Scale Out בקוד פתוח – פוסט עדכון

כתבתי בעבר לגבי Ceph ולגבי GlusterFS. בפוסט זה אנסה לענות לשאלה שחוזרת מדי פעם אצלי באימייל: במי מהם לבחור אם הולכים על Scale Out Storage?

בשביל לענות, נתחיל מההתחלה הפשוטה: רוב הארגונים רוכשים לעצמם סטורג' קנייני כלשהו שעובד בשיטת ה-Scale Up: רוצה יותר אחסון? תוסיף מדפי דיסקים, SSD, Cache וכו' וכו'. ברוב הארגונים לעומת זאת, כשחושבים לדוגמא על Cluster Storage במובן של 2-3 מכונות סטורג' נפרדות שמסונכרנות ביניהם – המחיר של הפתרון הקנייני מרתיע ואז מתחילים להישלח אימיילים ולחייג ליועצים שונים.

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

כיום, אני שמח לציין, שום ארגון רציני (כולל משרדי ממשלה, משרד הבטחון וכו') לא פוסל מלשמוע הצעות על SDS (כלומר Software Defined Storage) מבוסס קוד פתוח, במיוחד שיש לזה "אבא" בארץ כמו Red Hat או SuSE. בכל הארגונים שציינתי יש פתרונות של יצרני הפצות הלינוקס הנ"ל.

מבחינת תחרות, יש 2 פתרונות, וכל אחד מהם מיועד לשוק ולצרכים מסויימים. אף אחד מהם לא הולך "לסגור את הבאסטה" בקרוב. 2 הפתרונות הם Ceph מול GlusterFS. את Ceph אפשר לרכוש מ-Red Hat ו-SuSE, ואת Gluster מ-Red Hat (את שתיהם כמובן אפשר להוריד בחינם, אבל אני לא ממליץ במערכות פרודקשן קריטיות להריץ את הגרסאות קוד פתוח).

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

  • משרד האוצר פונה אליי בבקשה להקים SDS בגודל 4 פטהבייט שיאכסן ארכיב של מידע ישן: הודעות לעיתונות, גיבויים, מסמכי הצעות שונות ותוכן נוסף שכולו מורכב מקבצי אופיס ופורמטים אחרים. הגישה אל האחסון למשתמשים תהיה דרך SMB/CIFS בלבד עם הרשאות AD. אין גישת Web או שום דבר אחר. אחסון קבצים קלאסי.
    ההצעה שלי אליהם: GlusterFS.
    מדוע? GlusterFS מיועד לתת גישה לקבצים בלבד, בין אם דרך NFS או SMB/CIFS. קל להרחיב אותו (מוסיפים עוד ברזלים עם דיסקים, מחברים לסוויצ', מתקינים מערכת הפעלה, מריצים כמה סקריטפים ותוך שעות ספורות יש עוד כמה מאות טרהבייט זמינים) והרבה יותר קל לנהל אותו בהשוואה ל-Ceph.
  • ערוץ "כאן" פונה בבקשה להקים SDS בגודל 20 פטהבייט. בסטורג' הזה יאוחסן כל הסרטים, הסדרות, החדשות וכל מה שצולם עוד מימי הערוץ הראשון והטלויזיה החינוכית – והכל יהיה זמין דרך פורטל VOD לגולשים בארץ דרך נגן HTML5 יעודי והוידאו יוגש בזרימה או להורדה לתצוגה ב-Offline.
    ההצעה שלי אליהם: Ceph.
    מדוע? במערכת Ceph כל דבר שמאוחסן – מאוחסן כאובייקטים שבתוכם יאוחסנו הנתונים בפורמט שאנחנו רוצים. במקרה של "כאן" לדוגמא – כל קבצי הוידאו יאוחסנו כ-Object Storage וכל קליפ מקבל זיהוי יעודי משלו, מה שעוזר מאוד בגישה מהירה לקליפ ולהתחלת השידור שלו. כך, אגב, רוב חברות המדיה מאחסנות באמזון את קבצי הוידאו שלהם (ב-S3 ולא תחת File system עם איזה סטורג' כלשהו). ל-Ceph יש יתרון של Seek מהיר מאוד, והעברת מידע מהירה.
  • משרד הבטחון מקים מרכז מיחשוב חדש לאחד מהחילות. במרכז יהיו 200 שרתים פיזיים שיריצו וירטואליזציה כלשהי (נניח OpenStack או VMware) ומערכת Kubernetes או OpenShift. במשרד מעוניינים ב-SDS בגודל 30 פטהבייט עם אופציה לגדילה מהירה.
    ההצעה שלי אליהם: Ceph
    מדוע? כי Ceph יכול לאפשר ליצור Block Devices וירטואליים וגישת קבצים קלאסית (File System – CephFS) עם שרידות גבוהה. אם לדוגמא הם ישתמשו ב-OpenStack, הם יכולים ליצור דרך Ceph דבר שנקרא RBD (כלומר Raw Block Devices) ואם הם משתמשים ב-VMware – הם יכולים לקבל iSCSI כמו שהם רגילים אליו, ואם הם מעוניינים ב-NFS – אפשר ליצור ולייצא את זה מ-Ceph דרך ה-CephFS ואפשרי לתת להם גם שרותי PV ל-Kubernetes לדוגמא.
  • חברת "שופרסל" מעוניינת ב-SDS  בגודל 5 פטהבייט שיאכסן גיבויים, קבצים וכו'. הם מעוניינים שבחוות שרתים אחרת ישב SDS זהה עם סינכרון מתמשך בין ה-2.
    ההצעה שלי: GlusterFS
    מדוע? מכיוון שגם כאן מדובר בקבצים בלבד בשיטה המסורתית ו-GlusterFS כולל  בתוכו פונקציות לסינכרון מתמשך בתנאי תקשורת שונים מבלי להעמיס על התקשורת או להאיט את שרותי ה-File Server.

כפי שציינתי לעיל – הכל דמיוני לחלוטין, אבל אם חברה מסויימת רוצה שרותים – אהלן וסהלן. 🙂

נסכם את היתרונות והחסרונות של כל מערכת SDS:

  • ל-Ceph יש יתרון גדול בכך שזו מערכת רצינית לתת לך כל סוג של פורמט נתונים שאתה רוצה, בין אם מדובר ב-File Server קלאסי, Block Device, Object Storage ועוד. למערכת יש שרידות מצוינת (כך שאם נופל שרת Ceph – המערכת ממשיכה לעבוד כרגיל). ב-Ceph יש תמיכה ל-tiering, דחיסה, Dedup וכל הדברים שמוצאים ב-Scale Up.
  • ל-GlusterFS יש יתרון בכך שהיא מיועדת בדיוק לדברים הקלאסים של File Server (דרך CIFS/NFS) ותו לא. אפשר להקים אותה על ברזלים ישנים, היא תומכת גם ב-RAID חומרה או RAID תוכנה, היא לא דורשת המון משאבים (מבחינת CPU/זכרון) וממש לא אכפת לה מה ה-File System מתחתיה. ל-GlusterFS יש Load Balancing מובנה, כך שאם יש צורך ב-File Server שישרת מאות משתמשים ובגדלים של עשרות או מאות טרהבייט ומעלה – GlusterFS היא בחירה טובה ויחסית קלה יותר ללימוד בהשוואה ל-Ceph.

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

על דיסקים מכניים גדולים ו-RAID

מי שעוקב אחרי חדשות טכנולוגיות יכול למצוא אחת לכמה חודשים הכרזות של יצרני דיסקים שונים על דיסקים חדשים, לפעמים על שיטת קריאה/כתיבה חדשה. כך לדוגמא, חברת Showa Denko K. K. הכריזה כי היא סיימה לפתח ראש MAMR חדש לדיסקים קשיחים עבור חברת טושיבה, וטושיבה תוציא דיסקים קשיחים בגודל 18 טרה המבוססים על טכנולוגיה זו במשך השנה. צפו להכרזות דומות מצד שאר היצרנים.

כיום, בין אם יש לך שרת שאתה מכניס בו דיסקים קשיחים ומחבר אותו לבקר RAID כלשהו, ובין אם יש לך סטורג' קנייני – כל היצרנים ישמחו למכור לך דיסקים קשיחים גדולים – בין אם ישירות מיבואן יצרן הדיסקים ובין אם דרך החברה שרכשת ממנה את השרת או הסטורג'. רוצה מדף עם 12 דיסקים של 10 טרהבייט? בשמחה! תחתום פה ופה, תעביר כרטיס אשראי או תשלח צ'ק וטכנאי בדרך אליך להתקין את המדף לסטורג' ולהגדיר אותו. אין צורך לדאוג, גם הדיסקים הגדולים שנמכרים כיום נמכרים עם SAS Dual Port לחבר ל-2 כרטיסי RAID (אם אתה רוצה להכניס את זה לשרת, בסטורג' זה אוטומטי).

אבל האם זה שווה לרכוש את הדיסקים הללו? בכל זאת, אם קנינו מדף של 12 דיסקים בגודל 10 טרה, אנחנו נקבל ברוטו 120 טרהבייט, זה שקט להרבה זמן מבחינת אחסון פנוי!

בעבר כתבתי על הנושא והצרות עם זה, ועכשיו גם חברת Western Digital, אחת מחברות יצרני הדיסקים הגדולים – כותבת על כך (ואני ממליץ מאוד לקרוא את הפוסט!). הסיבה שהם כותבים היא כמובן כדי לדחוף 2 מוצרים שהם מוכרים. אני לעומת זאת כותב מהנקודה היותר פרקטית – של סכנה.

לשם פוסט זה, נניח ויש לנו את ה-12 דיסקים של 10 טרה, והם מורכבים בסטורג' או בשרת עצמאי עם 2 בקרי RAID (או אחד, זה לא ממש משנה מבחינת מהירות קבלת נתונים, ה-Dual Port ב-SAS הוא יותר לשרידות, אם כי במצב שהולך לך בקר, אני הייתי ממליץ לך להשבית את השרת עד שיגיע טכנאי עם חלק חלופי. אתה לא רוצה לסכן את ה-DATA שלך!). נניח שהגדרנו RAID, נניח 5 או 6 (במצב של 1 זה הרבה יותר מסוכן) או כל "RAID" בסטורג'.

עכשיו – נניח והלך דיסק קשיח. המנוע לא נדלק, או שדיסק עושה רעשים מוזרים כשאתם מתקרבים למדף/שרת ומקשיבים. נאמר שהפעלנו את האחריות וכבר תוך זמן קצר אנחנו שומעים זמזום אופנוע – השליח עם הדיסק החלופי הגיע. אנחנו מוציאים את הדיסק, מכניסים דיסק חדש – ויאללה, שיעשה Rebuild!

וכאן… מתחילות הבעיות והסיכונים צצים…

  • אם הדיסקים נמצאים בשרת והם מחוברים לבקר RAID (וזה לא חשוב איזה RAID הגדרתם, למעט כמובן 0 שאז הלך ה-DATA) – השחזור לא רק שיהיה איטי ויקח מספר ימים, אלא שאתם תסבלו מביצועים נמוכים מאוד באותם ימים הואיל וכל מערך ה-RAID צריך לעבוד בעצם כפול: גם לשרת את הצרכים שלכם, וגם לקרוא מהחלקים השונים של הדיסקים על מנת לכתוב את ה-DATA מחדש על הדיסק החלופי.
  • מכיוון שאתם מאמצים את המערכת – יש סיכוי שדיסק נוסף יפסיק לעבוד, הואיל והמערכת עובדת נון סטופ.
  • במקרים של שרת ו-RAID מבוסס בקר חומרה, הכתיבה היא "הכל" – גם אם היה לכם ב-RAID חומר בגודל 10 ג'יגהבייט, הוא יבצע Rebuild של 10 טרהבייט, מכיוון שבקר RAID הוא דבר די טיפש.
  • במקרים של סטורג' (או Software defined Storage) – שיטת ה-Rebuild תהיה שונה, וכמות ה-DATA שתיכתב על הדיסק תהיה כמו שאר הדיסקים באותו "RAID", כך אם יש חומר של 10 ג'יגה, יכתב 10 ג'יגה. ההבדל הגדול בין סטורג' לבין שרת עם בקר RAID חומרה – זה שהסטורג' יודע "להסתיר" את האיטיות עם דיסקים SSD, עם Flash Cache וטריקים אחרים, אבל עדיין – תורגש איטיות.

לכן, אם אתם מעוניינים לרכוש כמות דיסקים קשיחים גדולים ולבנות לעצמם NAS לדוגמא, כדאי להסתכל על ההמלצות הבאות:

  • חברו את הדיסקים ל-HBA ולא לבקר RAID (אפשר לרכוש בקרי LSI עם IT MODE או להחליף להם קושחה).
  • השתמשו בתוכנה כדי לבצע RAID. יש הרבה פתרונות – החל מ-FreeNAS, ZFS, XPEnology, או Storage Spaces של מיקרוסופט. הכל תלוי בהעדפה שלכם.
  • השתמשו ב-SSD שהוא Mixed Intensed או SSD שמתאים ל-Enterprise אם המהירות חשובה לכם. ההמלצה שלי היא ללכת על Optane 900P או DC P4800X (אם יש לכם את התקציב) של אינטל על מנת לקבל Latency מאוד נמוך וביצועים גבוהים מאוד (שימו לב – אם השרת אינו חדש, אז ה-Optane לא יוכל לבצע Boot ואם בשרת אין תושבות PCIe 3.0 – אז הוא לא יעבוד).
  • אם אתם משתמשים ב-ZFS, אל תשכחו להגדיר תהליך "קרצוף" (scrub) של הדיסקים לפחות אחת לשבוע (התהליך עובר על כל ה-DATA והיכן שהוא מוצע בעיות, הוא משכתב את ה-DATA למקום פנוי אחר, כך שהעבודה תהיה חלקה).
  • גיבויים, גיבויים, גיבויים – תוכנות גיבוי זה טוב, אבל snapshots ברמת האחסון הם יותר טובים והשחזור הרבה יותר מהיר. דאגו שתהיה מכונה אחרת עם מקום פנוי לקבל את ה-Snapshots.

ככלל, לא חשוב אם האחסון שלכם הוא NAS שבניתם או סטורג' שקניתם, אם כמות האחסון שלכם נעה בין מאות טרהבייט לפטהבייט – עדיף לעבור לפתרון Scale Out (וכשאני מדבר על Scale Out אני מדבר על מספר מכונות [גם נקראות Nodes]) המכילים את הדיסקים או JBOD המחוברים לאותן מכונות. פתרונות כאלו יודעים להתמודד גם עם מצבים שמספר דיסקים קשיחים מתקלקלים במקביל ומענה לדרישה מוגברת של תעבורת נתונים הלוך ושוב לשרתים/מהשרתים.

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

סטורג' לחברות גדולות

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

הערה 2: למעוניינים, כתבתי פוסט נוסף לגבי הסברים בין Scale Out ל-Scale Up והוא נמצא כאן (אתם יכולים ללחוץ על הלינק והוא יפתח ב-TAB חדש).

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

מחיפושים שהרצתי לאחרונה בגוגל ומשיחות שערכתי עם מספר אנשים, ישנם מספר גופים שפרסמו RFI או מכרזים לסטורג'ים או שהולכים להוציא מכרז במהלך השנה. אלו תהליכים איטיים ורציתי לנצל את ההזדמנות ולדבר על סוג סטורג' מעט שונה, ה-Scale Out Software Defined Storage.

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

  • קונטיינרים / Kubernetes – הקונטיינרים הנחמדים האלו תופסים מקום, ואם מבצעים Scale Out גדול כך שמריצים לדוגמא מאות קונטיינרים – יש צורך בכמות אחסון גדולה, לא רק לקונטיינר אלא גם ל-Volume שמוצמד לקונטיינר, וברוב המקרים יש לפחות Volume אחד פר קונטיינר שאותו אנחנו רוצים לשמור גם לאחר שהקונטיינר מת.
  • לוגים ותובנות – ככל שיש לנו יותר מכונות וירטואליות, יותר מערכות Orchestration כמו Kubernetes או OpenShift יהיו לנו המון לוגים. אנחנו צריכים את הלוגים שלהם ואנחנו צריכים מערכת ניתוח רצינית (כמו כל המערכות שמבוססות Elastic) והדבר הזה תופס טרהבייטים כמו כלום.
  • מערכות Big Data שונות – יותר ויותר גופים מתעניינים, ומערכות אלו אוכלות אחסון כאילו אין מחר.

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

פתרונות סטורג' מלפני 4 שנים ומעלה התאפיינו בכך שהם פתרונות Scale Up סגורים, אלו אותם פתרונות שעליהם נמצא לוגו היצרן על כל מכונה ועל כל קופסא. אלו פתרונות שיכולים לגדול מבחינת כמות אחסון ואולי לתת יותר IOPS, אבל המחירים שלהם מאוד יקרים. כמה המחיר משפיע? נאמר שראיתי גופים שרכשו סטורג' X שעובד טוב, אבל המקום הפנוי מתרוקן במהירות ולפעמים אחרי שנתיים כבר מחפשים איזה סטורג' "ביניים" להעביר אליו דברים על מנת להשאיר כמה שיותר מקום פנוי בסטורג' היקר. הסיבה לכך פשוטה: כל שדרוג סטורג' כזה הוא יקר מאוד ובלא מעט מקרים התוכן שרוצים לאחסן – שווה את מחיר השדרוג.

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

יש כמה דברים שכל גוף גדול שרוצה לרכוש סטורג' צריך:

  • תמיכה בפרוטוקולים ידועים (CIFS/NFS, iSCSI)
  • תמיכה בהאצת וירטואליזציה (VASA/VAAI)
  • תמיכה ב-Snapshots
  • מערכת ניהול מרוכזת
  • שרידות גבוהה
  • חלוקת עומסים בין החלקים השונים של המערכת
  • Tiering (מידע שמועבר מדיסקים SSD מהירים לדיסקים מכניים איטיים יותר וההיפך לפי הצורך)

עכשיו אוסיף עוד כמה דברים:

  • תמיכה ב-Kubernetes וב-Persistent Volumes
  • תמיכה ב-Object Storage (כמו S3)
  • תמיכה ב-Cinder (אחסון block)

עתה נעבור לפתרון סטורג' Scale Out שמבוסס על תוכנה (Software Defined)

בפתרון כזה אנחנו לא רוכשים ברזלים קנייניים של יצרן סטורג' כלשהו. במקום זה, אנחנו רוכשים (אחרי תהליך מכרז בו אנו מפרטים כמות סטורג' רצויה, כמות IOPS וכו' וכו') תוכנת סטורג' ומי שזכה מציין איזו חומרה צריך. כל יצרני התוכנה מבצעים Certify מול כל יצרני השרתים הפופולריים כך שלא תצטרכו לרכוש שרתים וציוד ממקור אחר שאין לו חוזה עמכם. החומרה עצמה מורכבת משרתים (לא צריך חזקים), דיסקים SSD ומכניים, כרטיסי רשת 50/100 ג'יגה, וסוויצ'. כל הציוד עצמו אנחנו רוכשים בדיוק מאותו ספק שזכה במכרז למכור שרתים לחברה, וממנו גם נקנה את הדיסקים, כרטיסי רשת ומהזוכה שמוכר לנו את הסוויצ'ים נרכוש 2 סוויצ'ים. לאחר הרכישה, ספק תוכנת הסטורג' יקים את התוכנה, יגדיר את מה שצריך להגדיר וכמובן יתן שרות במסגרת SLA וכל מה שיוגדר במכרז.

הערה: כל יצרני השרתים מוכרים גם פתרונות סטורג' Scale Out משלהם, רובם מצריכים רכישת הברזלים והמערכת מהם.

מדוע פתרון זה עדיף מפתרון סטורג' Scale Up כמו מה שיש ברוב החברות? מכמה סיבות:

  • תמיכה – יש לכם תמיכה מלאה מספק התוכנת סטורג', 24/7, כפי שהגדרתם בהסכם. בנוסף, אם ישנה תקלת חומרה, אתם פונים לאותו ספק שרתים שאתם רוכשים ממנו כל הזמן.
  • מחיר יותר זול – שדרוג דיסקים וזכרון בשרת הוא הרבה יותר זול משדרוג דיסקים בסטורג' קנייני.
  • גדילה יותר זולה – מחירי שרתים יורדים כל מספר חודשים, מה שקשה לאמר על מחירי סטורג' אם רוצים להוסיף מדפים, Flash Cache וכו', כך ניתן להוסיף שרתים, להגדיל את כמות ה-IOPS והמקום הפנוי בצורה יותר זולה.
  • שדרוג לפונקציונאליות נוספת – רוב יצרני ה-Software defined storage מוסיפים פונקציות בגרסאות מתקדמות, והספק יכול לדאוג לשדרוג מערכת קיימת. נסו לקבל פונקציונאליות נוספת משמעותית אחרי שקניתם סטורג' קנייני.
  • טכנולוגיות SSD יותר מתקדמות – סמסונג, אינטל, טושיבה, מיקרון, כולם עובדים על פיתוחים לדיסקים SSD יותר גדולים, מתקדמים, מהירים. כל יצרני השרתים ישמחו למכור לכם את הדיסקים הללו עם תמיכה ושרות מהיצרן שרתים שלכם ישירות. זה לא ממש קיים בסטורג' קנייני – מה שקניתם, זה מה יש (למעט דיסקים בגדלים שונים, אך לא טכנולוגיה שונה).
  • שרידות הרבה יותר גבוהה – כל תוכנת סטורג' מבוססת תוכנה יודעת לתת שרידות ברמת דיסקים או Nodes, כך שגם אם שרת נופל, המערכת ממשיכה לעבוד כרגיל ויש גם תוכנות שניתן איתן להגדיר שגם אם 2 שרתים נופלים – המערכת ממשיכה לעבוד.

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

מוקדש כחומר למחשבה. אם יש לכם שאלות, אתם תמיד מוזמנים ליצור קשר.

התקציב השנתי ורכישת ציוד

יש חברות שכבר הספיקו לתכנן את תקציב ה-IT לשנה הקרובה, יש כאלו שעדיין יושבים על המספרים. כמובן שאצל כל חברה הדברים שונים, יהיו כאלו שירצו בשנה הקרובה להחליף שרתים, להחליף סטורג', אולי לרכוש PC חדשים, לשדרג ל-SSD, לעבור לתקשורת פנימית יותר מהירה (10/40/50/100 ג'יגהביט), וכמובן שיש את כל עניין הפלטפורמות: לעבור לקונטיינרים, הטמעת CI/CD, להתחיל לעבוד בתצורת AGILE, לשכור אנשים/חברות ללמד את העובדים טכנולוגיות חדשות וכו'.

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

נתחיל בסטורג' SDS.

את עולם הסטורג' לקצה התחתון עד הבינוני ניתן לחלק ל-2: סטורג' קנייני (כזה שמגיע עם "ראש", מדפים), וסטורג' מבוסס תוכנה (SDS – כלומר Software Defined Storage). אם תשאלו את אנשי השיווק של הסטורג' הקנייני, תקבלו הילולים מכאן עד הודעה חדשה כמה הוא יציב, וכמה "לא כדאי" לרכוש SDS. המצב במציאות – די הפוך. בואו נאמר שאתם הולכים להוציא $50,000 על פתרון סטורג' ואתם מבקשים מכל העולם והחתול שלו הצעות מחיר לסטורג'. רוב ההצעות שתקבלו – הם SDS, גם אם הם לא יקראו כך בכותרת.

באופן עקרוני, סטורג' SDS מבוסס בעצם על חלקים COTS (כלומר Common Off The Shelf), כלומר שרת SDS אינו שונה מהותית מכל שרת שיש לכם בחדר/חוות שרתים שלכם. יש בו זכרון, מעבדים, בקר דיסקים, דיסקים קשיחים, וכרטיסי רשת. 2 הדברים ששונים בין סטורג' SDS לשרת רגיל הם בקר דיסקים (בחלק מהמקרים יש SAS Expander ו/או בקר RAID יותר יוקרתי הכולל תמיכה ל-SSD Caching) וכרטיסי רשת לחיבור מהיר (10/40/50 ג'יגה). הדבר העיקרי שהופך את השרת ל-סטורג', זו בעצם התוכנה שרצה עליו.

אחת השאלות הראשונות שאני נשאל לגבי פתרונות כאלו זה "האם יש תמיכה מהיצרן שרתים"? והתשובה בדרך כלל היא "כן", כלומר אם תבקשו מ-HP או DELL או LENOVO פתרון תוכנה של סטורג', הם ישמחו למכור לכם את התוכנה, עם או בלי שרת שלהם. היתרון הגדול בשיטה זו הוא שאם ציוד כלשהו בשרת נדפק, אתה נמצא תחת אחריות מלאה וטכנאי יגיע אליך תוך 4 שעות או ביום העסקים הבא (בהתאם לחוזה שרות שחתמת), ואם יש לך שאלות או תקלות עם תוכנת הסטורג', תוכל לקבל תמיכה מהיצרן שרתים או מיצרן התוכנה, כך שאתה מכוסה מכל צד. אפשר להשוות זאת לרכישת ברזלים + רשיונות של vSphere – אני לא מכיר מקרים שלקוח נשאר ללא מענה לתקלות אם הוא תחת אחריות של יצרן השרת והתוכנה.

מבחינת ביצועים – אחת השאלות שאני תמיד מקבל מצד כל מיני חברות שמתעניינות בסטורג' זה משהו בסגנון "אני צריך פתרון סטורג' עם X טרהבייט ועם כמות Y של IOPS רציפים". עם SDS אין בכלל את העניין הזה. רוצה X טרהבייט? תכניס כך וכך דיסקים ואם נגמר המקום, חבר JBOD בחיבור SAS-HD2. רוצה IOPS? תגדיל כמות זכרון ותוודא שיש לך SSD מהירים כמו P4800X או 905P של אינטל או Z-SSD של סמסונג (זה במקרה הקיצוני שצריכים IOPS גבוה בכל מחיר) או כל SSD שהוא Mixed והוא נמכר לך ע"י יצרן השרתים שלך. סמסונג, אינטל, מיקרון, טושיבה – כולם מייצרים כאלו.

שרידות – אחת הבעיות הקשורות במחיר – היא שרידות High Availability בסטורג' קנייני, כלומר כשצריכים "2 ראשים" לקבל שרידות. המחיר של ראש שני – יקר מאוד! לעומת זאת, בסטורג' SDS, מדובר בעצם על עוד שרת, רכישת JBOD לדיסקים וחיבור ה-JBOD ל-2 השרתים והפעלת פונקציית HA בתוכנת הסטורג'.

מה עם ביצועי רשת ב-SDS? שרת חזק יחיד עם כרטיסי רשת במהירות גבוהה, יתן ביצועים גבוהים ומענה לחיבור כל התשתית שצריך. מנסיון אישי על שרתים שהקמתי, הגעתי ל-250 ג'יגהביט תוך חיבור 150 שרתים, חלקם ב-NFS, חלקם ב-iSCSI וחלקם ב-CIFS (הייתי יכול להגיע ליותר אם היתה לי מכונה יותר חזקה ויותר כרטיסי רשת), כך שפתרון SDS יכול לעמוד בעומסים בלי שום בעיה.

מחירים ו"חופש": כשרוכשים סטורג' קנייני, אתה בעצם רוכש ברזל עם כמות X של דיסקים וכמות Y של פונקציונאליות. רוצה עוד פונקציונאליות? תשלם. רוצה להכניס דיסקים אחרים? ברוב המקרים יאמרו לך ש"אי אפשר". ב-SDS לעומת זאת, אתה יכול להתחיל היום עם דיסקים של 4 טרהבייט (נניח) ולעבור מחר ל-10 טרהבייט, ובד"כ הרשיון של התוכנה כולל את כל האפשרויות במחיר, רק שהמחיר משתנה לפי כמות האחסון בפתרון (אם כי יש תוכנות שכמות האחסון לא משנה את מחיר הרשיון), כך שעם SDS יש לך יותר חופש להחליט איך להשתדרג ומה לשדרג – אתה מזמין מיצרן השרתים את החומרה שאתה צריך, מרכיבים את החומרה, מפעילים את המכונה וממשיכים לעבוד.

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

עוד על SDS כתבתי כאן וכאן.

פוסט עדכני על קורסים בחברות

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

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

טכנית, אין לי שום בעיה להעביר קורס על לינוקס, על כלים שמשתמשים במתודות Devops (כמו GIT, Jenkins, קונטיינרים, וירטואליזציה, SDS ועוד), אבל להעביר קורס במשך יום יומיים לדוגמא על הכרת לינוקס (ויש לא מעט סוגי קורסים כאלו) – אני יכול להבטיח לכם שההשקעה (שהיא לא ממש קטנה במחיר) תרד לטמיון. מדוע? מכמה סיבות:

  • קורסים מסויימים מלמדים על כמה הפצות לינוקס במהלך הקורס. זו, לעניות דעתי, טעות. לי, אישית, כשאני לומד עדכון של הפצה שאני כבר מכיר, לוקח לי כמה שעות במשך כמה ימים ואילו הפצה חדשה לוקח לי יותר זמן ללמוד (מה לעשות, צריך גם להתפרנס, לא? 🙂 ). לעומת זאת, מישהו שהוא חדש בתחום  הלינוקס, יקח לו הרבה יותר זמן ללמוד, ולימוד הפצות שונות באמצע די מבטיח בלבול רציני. כבר ראיתי מישהו שדי חדש בלינוקס מתעקש במשך שעה לנסות להתקין חבילות תוכנה עם פקודת zypper (שקיימת להפצת SuSE) בשעה שהוא היה צריך להשתמש בפקודת yum (שקיימת בהפצות Red Hat ו-CentOS) ולכן קורס טוב לדעתי צריך להתמקד בהפצה עיקרית אחת.
  • שיטת לימוד של "נזמין את המדריך ליומיים שלוש" להדרכה, היא שיטה די בטוחה שהכסף שיושקע ילך לטמיון. לינוקס זה לא לימוד MCITP ורוב מוחלט של החומר הנלמד הם פקודות טקסטואליות שצריך לשנן, ולנסות. קורס יומיים? תהיה בטוח ש-90% מהחומר ישכח ע"י רוב התלמידים, ועל כך יכול להעיד המייל אצלי. יש צורך לפרוס את זה ליום או יומיים בשבוע לשעות ספורות.
  • רלוונטיות: מכיוון שהשוק פתוח וכל אחד יכול להציע קורסים כאוות נפשו, מגיעים אליי כל מיני שאלות אם אני יכול להעביר קורס על טכנולוגיה זו או אחרת. טכנית, אין לי בעיה להעביר, אבל התועלת לחברה חשובה לי לא פחות מכך וצריך לבדוק (כן, תחת NDA) היכן זה משתלב. כך לדוגמא פנו אליי בעבר להעביר קורס מעמיק ב-Docker. זה, לדוגמא, קורס שהתוכן שרלוונטי הוא אולי 10% כי בסופו של יום אם מתחילים לבנות בחברה קונטיינרים, משתמשים במערכת ניהול והרצת קונטיינרים כמו OpenShift או Kubernetes – כך שללמד איך לבנות קונטיינרים – כן, איך להריץ ואת החלקים הפנימיים ב-Docker – לא ממש, תשאירו את זה להדרכות על כלי הניהול.

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

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

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

לא מעט חברות מחזיקות ברעיון שפתרון אחסון (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, מכונות נוספות) והכי חשוב – נוכל להנות מפתרון שנותן גם ביצועים מהירים וגם התחזוקה עצמה תהיה די מינימלית.

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