החל ה"מרדף" אחר החלפת הדיסקים קשיחים שלכם

כמעט בכל חברה גדולה בארץ יש שרתים ואם נסתכל בשרתים – ברוב המקרים נמצא דיסקים קשיחים מכניים. הם לא מהירים כמו דיסקים SSD, אבל הם "סוסי עבודה" שעושים עבודה טובה. אני די בטוח שהיו למנמר"ים או אנשי IT הצעות להחליף את הדיסקים האלו ב-SSD ובוודאי בחלק מהמקרים הדיסקים המכניים הוחלפו ב-SSD, אבל בד"כ חברות לא ממהרות להחליף – בגלל המחיר. אחרי הכל, מחיר ממוצע של SSD ל-Enterprise עולה הרבה יותר מאשר דיסק מכני SAS או NL-SAS ל-Enterprise.

מי שקורא את הפוסטים בבלוג זה, אולי קרא את הפוסט הזה שכתבתי על סוגי SSD וגם כתבתי על סוג שבבי NAND חדש עם תאי QLC (כלומר ניתן לכתוב 4 ביטים בתא אחד, בניגוד ל-SLC שבו ניתן לכתוב רק ביט אחד, אבל בהשוואה ל-QLC הוא הרבה יותר מהיר בכתיבה). החסרון הגדול של QLC זו הכתיבה האיטית ולכן דיסקים SSD מבוססי QLC NAND Flash לא מיועדים להתחרות מול SSD רגיל.

הם מיועדים להתחרות בדיסקים הקשיחים שיש לכם בשרתים.

הבה נודה על האמת: דיסקים מכניים בגודל 2.5" לא התקדמו כמעט בשנים האחרונות. ברוב המקרים הדיסק הכי גדול ל-2.5" ל-Enterprise הוא בגודל 2 טרהבייט (יש כמובן גם 5 טרהבייט אם כי הם אינם מיועדים ל-Enterprise ובכל מקרה לא בטוח הם יוכלו להיכנס לשרת שלכם אם השרת הוא של HP לדוגמא – המערכת פשוט תקפיץ הודעה שזה לא נתמך והיא לא תציג התראות מדיסק כזה). המהירות שלהם אינה גבוהה (בין 200-270 מגהבייט ב-Sequencial Read).

חברת Micron, בשיתוף פעולה עם אינטל, הציגו אתמול את ה-SSD מבוסס QLC הראשון שלהם. עדיין אין הרבה פרטים ציבוריים עליו ובאתר Toms Hardware כתבו כמה מילים לגביו.

טכנית, הדיסקים הללו, כפי שציינתי לעיל, מיועדים להיות "באמצע" – בין כוננים מכניים ל-SSD שכולם מכירים ל-Enterprise. הכתיבה שלו לא מהירה בהשוואה לשום SSD שקיים בשוק (כן, גם בהשוואה ל-SSD שעולה 1000 שקל בחנות מחשבים), אולם מהירות הקריאה שלו היא כמו מהירות קריאה של SSD ל-Enterprise, כלומר אתם תקבלו מהירות של 550 מגהבייט לשניה (שוב, ב-Sequencial Read, ב-Random התוצאה תהיה מעט שונה ואם משתמשים ב-Queue Depth התוצאות יהיו לא רעות .. הייתי מרחיב אבל יש אמברגו עד לסתיו הקרוב).

הגדלים של הדיסקים הללו יהיו שונים מגדלים של דיסקים מכניים. ה-5210 ION יהיה זמין בגדלים החל מ-2 טרהבייט ועד 8 טרהבייט (אני מעגל את המספרים), כך שתיאורתית דיסקים כאלו יכולים להחליף גם דיסקים מכניים בגודל 3.5" (ניתן לאכסן תיאורתית בשרת בגודל 1U עם 10 כניסות דיסקים – כמעט 80 טרהבייט של DATA).

והשאלה הכי חשובה לפני שחושבים לרכוש דבר כזה בעתיד: לאיזה עומסי עבודה זה מתאים? ובכן, התשובה היא במובהק לעבודות Read Intensive. זה לא מיועד לאכסן שרת SQL או נתונים של שרת SQL, זה לא מיועד לשמש כדיסקים לוקאליים עבור הרצת מכונות VM. זה מיועד יותר לאחסן תוכן סטטי, כך שאם אתם מריצים פורטל ארגוני גדול בחברה לדוגמא, דיסק כזה יכול לאחסן את התכנים עבור הפורטל (בנוסף לדיסק רגיל שיאחסן את השרת ה-Web ו/או ה-Application Server). חשוב לזכור: כמות הכתיבה/מחיקה על כל תא היא מוגבלת (בסביבות ה-1000 פעם, אבל בד"כ בקר ה-SSD עושה עבודה חכמה שלא תגיעו לזה)

חברת מיקרון היתה הראשונה להכריז על QLC, ותהיו בטוחים שבמהלך החודש הקרוב כל השאר יכריזו, כי כולם עבדו על יצור שבבים עם QLC: סמסונג, טושיבה, סאנדיסק/WD, אינטל (עם מיקרון), וגם SK Hynix. הרכישה תתאפשר החל מסביבות אוקטובר-נובמבר בשנה זו.

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

כמה מילים על ZFS (לשנת 2018)

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

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

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

להלן צילום מסך מ-vSphere client בגירסה 5.5, כאשר מגדירים LUN חדש ובוחרים את ה-Block Size (לחצו להגדלה):

טעות מאוד נפוצה של עובדי IT היא להגדיר את גודל הבלוקים בגודל 8 מגהבייט מבלי להתייחס לתוכן שישב באותו Datastore. אם לדוגמא ישבו בו קבצים רבים קטנים (בגדלים של מאות קילובייט או מגהבייטים בודדים) אז מדובר בכך שהגישה לקבצים תהיה יותר איטית בהשוואה לדוגמא בבחירה בגודל של 1 או 2 מגהבייט והאיטיות תורגש במיוחד כה-Datastore גדול מאוד בעת כתיבה וכמובן שמדובר בבזבוז מקום.

במקרה לעיל, לא חשוב איזה Storage יש לך, מהרגע שהגדרת iSCSI LUN בסטורג', לסטורג' אין מושג ירוק מה אתה הולך לעשות איתו. מבחינתו זה Block ולך תשבור את הראש מה לעשות ואיך להגדיר ואיך לעשות אופטימיזציה לו ב-Initiator שלך.

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

אבל מה קורה אם אנחנו רוצים לבנות פתרון סטורג' משלנו ואנחנו מעוניינים לעשות לו אופטימיזציה ולא להיות "שבויים" באיזה פתרון שלא מאפשר לנו להגדיר דברים לעומק? אם אנחנו בונים עם לינוקס מערכת כזו עם File System כמו XFS או EXT4, מאותו הרגע שחילקנו את הדיסק עם או בלי LVM, ואנחנו מפרמטים את כל מערך ה-RAID בזמן ההתקנה, אז כבר אי אפשר לשנות את גודל הבלוקים. ב-XFS לדוגמא, ברירת המחדל היא להגדיר בלוקים בגודל 4K כל בלוק, אבל אם אנחנו הולכים לאחסן רק קבצים שרובם בגודל מס' ג'יגהבייטים, אנחנו נפסיד מהירות.

לעומת זאת ב-ZFS, גם אחרי ששייכנו את כל הדיסקים ל-Pool מסויים, אנחנו תמיד יכולים להגדיר את גודל הבלוקים (ב-ZFS זה נקרא record size) גם אחרי יצירת ה-Pool ויצירת Dataset (חשוב כמובן לשים לב שאם יצרנו Dataset ואנחנו מגדירים לו record size חדש, רק הקבצים החדשים יקבלו את גודל ה-record size החדש, לא הקבצים הישנים) כפי שניתן לראות לדוגמא כאן. (אגב, זה דבר שמאוד עוזר עם MySQL לדוגמא, אתם מוזמנים להציץ כאן)

נקודה נוספת וחשובה היא כמובן הדיסקים. ישנם עדיין מקרים רבים שיש שרתים פיזיים שמריצים אפליקציות מסויימות על דיסקים מקומיים עם כרטיס RAID הכולל זכרון Cache וסוללה, אך עם הדיסקים החדשים שיש כיום שמחירם יורד כל הזמן, יהיו לא מעט חברות שישמחו לקנות דיסקים בגודל 6,8,10,12 או אפילו 14 טרה בייט ויחברו אותם לבקר ה-RAID וכך הם יקבלו כמות אחסון מכובדת, אך יש בעיה מרכזית אחת: כל דיסק מעל גודל 4 או 6 טרהבייט שנדפק ומוחלף, יאיט אוטומטית את הביצועים של כל מערך הדיסקים לזמן רב (זה יכול לקחת ימים או במקרים של דיסקים גדולים כמו 10,12,14 טרהבייט – אפילו שבועות!) מהסיבה הפשוטה שבקר דיסקים הוא דבר די טיפש, הוא יודע לקרוא בלוקים, אבל הוא לא יודע מה יש בבלוקים, כך שבקר ה-RAID מבצע rebuild, הוא יעתיק את כל הבלוקים, גם אם 60% מהדיסק הוא בכלל ריק! לעומת זאת ב-ZFS אם נדפק דיסק והחלפנו אותו, מערכת ה-ZFS תשחזר (מה שנקרא: resilver) רק את הקטעים שלא קיימים בדיסק החדש, כך שה-rebuild יהיה הרבה יותר קצר והמערכת תשוב לאיתנה במהירות הרבה יותר גבוהה מאשר בתהליך rebuild של כרטיס RAID.

חסרונות נוסף שקיימים ל-XFS ול-EXT4 הם לדוגמא:

  • אין בדיקת קבצים מתמשכת. ב-ZFS לכל קובץ יש checksum כך ש-ZFS יודע בדיוק אם מה שהוא קרא תקין או לא ואם לא הוא יטפל בבעיה אוטומטית בכך שהוא יעביר את הנתונים למקום אחר (בערך כמו שבקר SSD טוב עושה) ול-ZFS ישנו גם תהליך scrubbing שעובר אחת לכמה ימים על כל הקבצים בדיסקים לבדוק זאת ולטפל בתקלות באופן אוטומטי. ב-XFS וב-EXT4 יש לך Journal שיכול לעזור בקריסת המכונה, אך זהו פתרון שאינו מספק על מנת לשמור על הנתונים.
  • ב-EXT4 וב-XFS אין מנגנונים לניצול משאבי המכונה מבחינת זכרון. כן, ללינוקס יש שימוש מתוחכם בזכרון החופשי לשם Cache מסוגים שונים, אבל ב-ZFS יש את ARC שלוקח כברירת מחדל מחצית מהזכרון של המערכת להאצת ביצועי דיסק בכך שהוא משתמש באותו זכרון שהוא "גזר" בהתחלה, וכידוע – זכרון RAM הוא הדבר הכי מהיר שיש, יותר מכל SSD שקיים בשוק.
  • שימוש מושכל ב-SSD וב-NVME: עם מערכת כמו bcache או fastcache (לאלו שאוהבים לחיות על הקצה) יכול להיות פתרון די טוב על מנת להאיץ ביצועים של דיסקים מכניים, אך ב-ZFS יש לך 3 מנגנונים שמטפלים בכך:
    • מנגנון ה-ARC (שמשתמש כברירת במחצית הזכרון של המכונה לשם CACHE מהיר)
    • מנגנון ה-ZIL (להאצת ביצועים וטרנזאקציות של קבצים קטנים ורישומי הפניות להיכן קבצים נכתבים, אפשר לקרוא על כך כאן)
    • מנגנון ה-L2ARC – כאן בד"כ יהיה SSD מהיר ששומר עותקים של קבצים שניגשים אליהם בתכיפות גבוהה.
  • מערכת ZDB – לכל File system יש כלים משלו (tune2fs ל-EXT3/EXT4 לדוגמא או ערימת הכלים הזו ל-XFS), אבל ZDB לוקח את זה כמה צעדים קדימה – לבדיקה האם יש Cache אופטימלי, לבדיקה של ביצועים פר דיסק, בדיקות והגדרות ל-B-TREE (כן, ZFS שומר את הקבצים ב-B-Tree) ועוד המון דברים. ZDB הוא ה"אולר השוויצרי" ל-ZFS ועבודה איתו יכולה לתת ביצועים שעוקפים מרחוק כל File System לינוקסי.

יחד עם זאת ל-ZFS יש עדיין חסרונות (שיטופלו בשנה הקרובה):

  • הוספת דיסקים: לא, אתה לא יכול להוסיף עוד דיסק אחד אלא 2 ומעלה. גם החלפת דיסקים קיימים בדיסקים יותר גדולים היא לא בדיוק פיקניק כרגע (אבל זה אפשרי). במהלך 2019 יתווסף קוד להוספה דיסקים – אפילו דיסק בודד כמעט מבלי שנצטרך להתמודד עם איטיות של פריסת DATA מחדש (יועתקו מספר בלוקים בודדים וזהו).
  • עבודה עם SSD – אחד החלקים היותר נחמדים ב-SSD זו פקודת trimfs שאומרת ל-SSD לבצע פקודת TRIM ב-SSD. ב-ZFS יש תמיכה ל-Trim אך היא אינה אוטומטית בגירסת ZFS ללינוקס. יש Pull request שיכול לעבוד ברוב המקרים בגירסה הנוכחית היציבה של ZFS ללינוקס, ובגירסת ה-Master זה עובד בצורה טובה. אני מאמין שבחודשים הקרובים זה יוכנס פנימה.

לסיכום: אפשר להקים שרת ZFS תוך דקות ספורות על מכונה חדשה. יוצרים pool עם תצורת RAIDZ רצויה, מחלקים דיסק SSD ל-2 פרטישנים (אחד log ואחד cache, ככלל עדיף 2 SSD שיעבדו כ-Mirror), מצמידים אותם ל-pool ויאללה – יש מערכת ZFS עובדת. העניין הוא שאם אתה רוצה ביצועים מעולים, תצטרך להשקיע זמן בהגדרות דברים לפי מה שרוצים להריץ ומה ה-ZFS צריך לשרת (ואני ממליץ את הספר הזה ל-ZFS על לינוקס, או את הספרון הזה). האם ZFS הוא פתרון חלופי לסטורג' סגור – במקרים מסויימים כן ובמקרים מסויימים לא (תלוי בדרישות ובצרכים), אבל הוא מאוד מתאים אם חברה מחליטה להקים סטורג' קטן והיא מוכנה להשקיע את שעות העבודה כדי לבצע אופטימיזציה וזה לוקח זמן (לפי הידע של מי שמבצע זאת), זה לא משהו שנעשה בחצי יום, וצריך לעיתים להקים מערכת שלמה כדי להגדיר לבדוק את הביצועים.

תכירו את Redfish

אני רוצה להכיר לכם את Redfish. בעקרון, Redfish זה API סטנדרטי לנהל כמעט כל דבר בתחום ה-IT, החל מ-SDDC (כלומר Software Defined Data Center) וכלה בשרתים, שרותים, מתגים ובקיצור כמעט כל דבר שניתן להתחבר אליו. Redfish משתמש בסטנדרטים קיימים (REST API, web services ופלט כ-JSON) על מנת לעשות את החיים הרבה יותר קלים למחלקת ה-IT בחברה.

אחד הדברים שצריך לדעת על Redfish שזה משהו ענק שמשתתפים בו כל המי ומי בתחומי הברזלים לדוגמא. לפוסט הזה, אני מעוניין להתרכז בתחום ה-OOB (שזה אומר כל ה-iDRAC/IMM/ILO/IMC למיניהם).

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

ועכשיו אשאל שאלה: כמה זמן יקח מהרגע שהשרתים יורדים מהמשאית עד שהם פועלים עם ה-OS/וירטואליזציה שבחרתם? אני מאמין שזה לא עניין של שעות, זה יהיה מינימום עניין של ימים עד שבועות. אחרי הכל, במקרים רבים יש צורך להכניס כרטיסים שונים לשרת, אולי לשנות את תצורת הזכרון, להתקין OS, להגדיר את ה-UEFI/BIOS, לחבר למתגים, להגדיר כתובות IP, VLAN וכו', , להגדיר RAID, לפרמט דיסקים, ועוד כמה וכמה דברים.

כשמדובר על כמות של 1-3 שרתים, זה לא כזה ביג דיל, אבל אם מדובר על פרויקט חדש והגיעו 20 שרתים.. אתם יכולים לדמיין את הכאב ראש.

וכאן החלק של ה-OOB ב-Redfish יכול לסייע לנו מאוד, כך שלאחר שהכנסנו את הכרטיסים וחיברנו את כבלי הרשת והחשמל, הדבר היחיד שנצטרך להגדיר זה את כתובת ה-IP ב-OOB שלנו ולוודא שיש PING ל-OOB. כל מה שנותר לנו לעשות פיזית זה להכניס את השרת לארון. את השאר נעשה מבחוץ.

איך? עם ה-API של Redfish. כאן לדוגמא תוכלו למצוא עבור שרתי Dell סקריפטים הן ב-Python או ב-PowerShell על מנת להשתמש עם ה-Redfish בחיבור ל-iDRAC לעשות כמעט הכל, החל מהגדרת UEFI/BIOS, שדרוגי קושחה, הגדרות iDRAC, הגדרות RAID ושלל ירקות נוספים.

הכל טוב, רק שיש בעיה אחת קטנה: יש לי 20 שרתים להקים, להתחיל לשנות כל פעם סקריפטים? לכתוב סקריפט wrapper שמריץ את הסקריפטים שניתנים באותו אתר? זה חתיכת כאב ראש.

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

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

לסיכום: Redfish נותן סוף סוף דרך "לדבר" בצורה מאובטחת עם הציודים שלכם דרך סקריפטים שונים שניתנים לשימוש באוטומציה. אפשר גם להגדיר כך הגדרות שונות וגם לקרוא לדוגמא מה-OOB את התקלות האחרונות מה-Log. אם נחכים להשתמש גם ב-PXE (אני דווקא ממליץ על IPXE במקום PXE, הוא הרבה יותר מהיר כי הוא עובד ב-HTTP ולא TFTP כך שניתן לעבוד מהר ובמקביל) נוכל גם להתקין בצורה אוטומטית תוך שימוש בכלים כמו kickstart או preseed להתקין מערכות הפעלה שונות בתצורה מינימלית ואת השאר לעשות עם Ansible (כן, כולל Windows, אסביר בפוסט הבא) ובכך לחתוך את הזמן להקמת השרתים בעשרות אחוזים וגם התחזוקה תהיה הרבה יותר מהירה ואוטומטית.

להלן וידאו הדגמה של Dell מכנס Red Hat Summit האחרון שנערך לפני ימים ספורים:

על Ceph ועל HCI – סיבוב בדיקה נוסף

כתבתי כאן בעבר על סוגי סטורג' מבוסס קוד פתוח וניסיתי לענות על השאלה האם הם מתאימים לפתרונות HCI (כלומר Hyper Converege Infrastructure). התשובה שלי לגבי Ceph היתה בפשטות: לא.

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

אינטל לאחרונה החליטה להוכיח לעולם שדווקא Ceph יכול בהחלט להיות פתרון סטורג' טוב ל-HCI, ובכנס Red Hat Summit האחרון נציגי אינטל הדגימו זאת. להלן הוידאו עם המספרים:

כפי שאתם יכולים לראות, Ceph יכול לרוץ כפתרון HCI, רק שהעניין הוא המחיר שתצטרכו לשלם. כך נראה המפרט שאינטל השתמשה להדגמה:

והדברים שתצטרכו:

  • כוננים קשיחים מכניים? החוצה.
  • מעבדים – כרטיסי ה-XPoint של אינטל לא יעבדו (לא Boot ולא נעליים, הכרטיסים מצריכים UEFI 2.3.1 מהשנה וחצי האחרונות) על מעבדי E5 מדור 4 ומטה, תצטרכו שרתים חדשים מבוססי Xeon SP כך שגם את השרתים תצטרכו להחליף.
  • כונני SSD 3D של אינטל – זולים, הם לא. המחיר בשוק הוא בערך 3,500$ פר דיסק (וכן, הם צריכים PCIe 3.1, כך שגם שם אתם צריכים להתקין אותם בשרת חדש), כלומר ההדגמה של אינטל עולה רק מבחינת דיסקים 14,000$. (הדגם שהוצג בתצוגה הוא דגם ישן, כיום מוכרים את ה-P4600).
  • ליבות והרבה – המעבד שאינטל הדגימו (ושייכו אליו הרבה ליבות עם CPU Affinity) הוא Xeon SP Platifum 8176 עם 28 ליבות. מחירו בשוק (מעבד בלבד): 8500$.
  • זכרון – כן, ה-384 ג'יגה אמנם אינו מינימלי אבל הוא די באמצע, כך שלרדת מהכמות הזו תפגע בביצועים.
  • כרטיסי רשת במהירות 25 ג'יגה – כמובן שתצטרכו סוויצ' תואם, אתם יכולים לנחש את המחיר.

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

אחד ההבדלים הגדולים ביותר בין פרילאנסר יועץ מקצועי לבין מישהו שעושה Reselling או אנשי שיווק או אנשי Presale – הוא לא רק הכרת השוק ומה שחברות רבות מריצות, אלא גם הבנה וידע מה להציע ללקוחות. אם לדוגמא אתם לקוחות פוטנציאליים של "חץ ביז" ואתם מזמינים אותי לייעץ לכם לגבי פתרון סטורג' והמחיר שאני נוקב הוא לשם הדוגמא: 50,000$ על קופסא אחת, אני מאמין שאתם תאמרו "תודה ושלום" בנימוס ותלכו לקנות לכם סטורג' קנייני שסביר להניח שיעלה פחות. אחרי הכל, עם כל הכבוד לקוד פתוח, אינכם מחפשים לשרוף כספים ללא הצדקה.

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

הסברים על SSD למשתמשים ביתיים ובחברות

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

כל מי שמשתמש במחשבים בצורה רצינית ומבין בנושא בוודאי מכיר ושמע על SSD, הכוננים האלקטרוניים ששומרים את המידע על שבבי NAND (כלומר: Flash). היתרון העצום שלהם על כוננים מכניים הוא כמובן מהירות הגישה: פי 2-20 בהשוואה לכל כונן דיסקים מכניים.

הבעיה מגיעה לכך שכמעוניינים לקנות כונן SSD, ההיצע בשוק ענק, הטקסט השיווקי מטעה בלא מעט מקרים, ואפשר להוסיף על כך כל מיני הצהרות של אנשים טכניים שהיו נכונים לפני 6-9 שנים אך לחלוטין לא נכונים כיום (כן, קרה לי כבר פעם שמישהו מאוד בכיר טען בישיבה כי כונני ה-SSD לא יחזיקו מעמד 5 שנים. יש לי 4 כונני SSD בשרת ZFS שמחזיקים כבר 6 שנים של SanDisk בלי שגיאה אחת והם דווקא מהסוג הכי פשוט שיש!).

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

ניקח כונן SSD, ונפתח אותו. כך הוא נראה בצידו העליון:

כך נראה הכונן. בחלקו השמאלי יושבים מספר שבבי NAND שעליהם יאוחסן המידע. השבב עם ה-M (של חברת Marvell) הוא בעצם ה"מוח" של כונן ה-SSD. הוא הבקר שמצד אחד "מדבר" עם המחשב (החיבורים מימין) ומצד שני הוא האחראי לפריסת הנתונים על שבבי ה-NAND, תחזוקת הנתונים, טיפול בשגיאות, קריאה, כתיבה וכו'. במקרים רבים יש עוד שבב או יותר שמשמשים כזכרון חוצץ (Buffer) אשר מקבלים את הנתונים מבחוץ (אם לדוגמא אנחנו מעתיקים קובץ מבחוץ אל תוך ה-SSD) והבקר כבר דואג לקבל את הנתונים מהזכרון החוצץ ולפרוס אותם אל שבבי ה-NAND. יש עוד פעולות כמו Garbage Collection ו-TRIM שלא ניכנס אליהם אבל הם דברים מאוד חשובים לאורך חיי ה-SSD.

נעבור מכאן לשבבי ה-NAND. אלו השבבים שבהם מאוחסנים הנתונים שלנו. בתוך כל שבב כזה נמצאים מיליוני תאים שמאחסנים את הנתונים והגישה אליהם נעשית דרך הפינים מתחת לשבב. ישנם מספר סוגי תאים (SLC, MLC, TLC, QLC) פרי פיתוח של השנים האחרונות וההבדל ביניהם הוא בעצם כמות הנתונים שאפשר לאכסן פר תא. SLC לדוגמא זה Single Level Cell, כלומר בכל תא אפשר לאחסן נתון אחד וה-SSD הראשונים היו בנויים מ-SLC, כך שהם היו מהירים מצד אחד, אך כמות המידע שהיה אפשר לאחסן – היתה קטנה. MLC הגיע לאחר מכן ולמרות ש-M זה Multi, כמות הנתונים שהיה אפשרי לאחסן היתה בעצם 2 נתונים בתא. (מדוע לא קראו לזה פשוט DLC ש-D הוא Dual, אין לי מושג ירוק). אחרי MLC הגיע TLC (שנמצא ברוב כונני ה-SSD בשוק היום לסקטורים שאינם שרתים) ששם אפשר לאחסן 3 תאים והאחרון (QLC) יכול לאחסן כמות נכבדה של 4 נתונים בתא אחד.

אחת הבעיות הכי מאתגרות בתחום ה-SSD ו-NAND היתה בעצם האפשרות לאחסן כמות גדולה (אני מדבר על תקופת ה-SLC ו-MLC). יש גבול לגודל שבב שאפשר לייצר (ככל שהשבב יותר גדול, הסיכוי לתקלות בו יותר גבוה, בגלל זה מעבדים ו-GPU הם יקרים), ולכן סמסונג (ולאחר מכן חברות אחרות) החלו לעבוד על טכנולוגיה חדשה – במקום ליצור תאים יותר ויותר קטנים על מנת להכניס נתונים רבים – לבנות לגובה, וזה מה שנקרא 3D. בהתחלה סמסונג יצאה עם שבב שיש בו בעצם 32 "שכבות" ולאחר מכן 64 שכבות וכרגע הם מתחילים לייצר 96 שכבות ועובדים על 128 שכבות, כאשר בין כל השכבות יש מעין "מוטות" ותקשורת בין השכבות והבקר כמובן יכול לגשת לכל השבבים ולכל השכבות.

עכשיו שיש כמות רצינית של תאים פר שבב, ניתן לעשות מאות ג'יגהבייט וטרהבייטים, אבל ישנה בעיה אחרת: זוכרים את ה-SLC/MLC/TLC/QLC? הזמן שלוקח לכתוב לאותם תאים הוא יותר ארוך ככל שמתקדמים מ-SLC ל-MLC, מ-MLC ל-TLC, ומ-TLC ל-QLC (כאשר QLC יהיה די איטי אך יותר מהיר מכונן מכני), ולכן ה-Buffer יכול לסייע ובעצם "להחביא" את האיטיות כאשר הכתיבה בפועל תיעשה בתוך ה-SSD ברקע (בעקרון, כונן SSD הוא הרבה יותר חכם מאשר כונן דיסקים מכני. כונן SSD הוא מחשב שלם בפני עצמו הכולל מעבד, זכרון וכו').

עכשיו שאנחנו מבינים באופן עקרוני מהו SSD ומה הם התאים שבתוכו, נכיר את סוגי ה-SSD. יש מס' סוגים, אך נתרכז ב-2 סוגים, ה"קופסא" וה"מקל".

נתחיל ב"קופסא" – אלו בד"כ כונני ה-SSD שאנחנו מכירים ללאפטופים ושיכולים כמובן להיות מחוברים לתחנות עבודה, דסקטופים וכו'. כל כונני ה-SSD הם בגודל אחיד של 2.5" (יש גם 3.5" אך הם מיועדים לסקטור השרתים והם עולים עשרות אלפי דולרים) והחיבור שלהם הוא חיבור SATA רגיל בדיוק כמו חיבור דיסק קשיח מכני (לאלו שיש להם מחשב ישן דסקטופ, ניתן לרכוש כמובן בזול מתאם בין 3.5" ל-2.5" ב-eBay ובאתרים אחרים, ובחלק מהמוצרים היצרן מוסיף מתכת להתאמה, כמו חברת Kingston). אין צורך בדרייברים על מנת לקבל פעילות של כונן ה-SSD (אך יכול להיות שתצטרכו תוכנה מסויימת, עליה אדבר בהמשך). דיסק SSD כזה הוא דבר מעולה לאלו שיש להם מחשבים ניידים עם דיסקים מכניים והם מעוניינים להשביח את המחשב הנייד שלהם. ישנן מספר תוכנות חינמיות שיכולות להעביר את הנתונים מהדיסק המכני לדיסק SSD (לשם כך תצטרכו לרכוש מתאם USB ל-SATA על מנת לחבר את כונן ה-SSD בחוץ ולהשתמש בתוכנה להעביר את הנתונים ורק לאחר מכן להעביר את ה-SSD לתוך המחשב הנייד).

חוץ מגירסת ה"קופסא" יש לנו את גירסת ה"מקל" – אלו בעצם כונני SSD בתצורה שמתברגת על לוח האם של המחשב (ושל מחשבים ניידים חדשים, בחלק מהמקרים). מדובר ב"מקל" ברוחב 22 מ"מ ובאורך 80 מ"מ (יש גם גירסה של 110 מ"מ) שאותו אנחנו מחברים לחיבור מיוחד ומבריגים. החיבור נראה כך:

כפי שאתם יכולים לראות: ישנם "חורים" היכן שנמצאים הפינים של ה"מקל" והם מאוד חשובים. בכרטיסים עם 2 חורים, ה"מקל" הוא בעצם SSD בחיבור SATA, כלומר המהירות שלו תהיה בדיוק כמו קופסת SSD בחיבור SATA והיתרון היחיד שלו הוא בעצם שהוא לא תופס מקום פיזי במחשב מקדימה. לעומת זאת, אם יש חור אחד, אז מדובר במקל NVME SSD שהוא מהיר פי 4-6 מכונן SSD SATA (ולפיכך הוא גם עולה יותר).

עוד סוג חיבור שיש הוא חיבור ה-U.2, הוא מופיע בריבוע הכחול בתמונה:

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

עכשיו שאנחנו מכירים גם את החיבורים וסוגי ה-SSD, נשאלת השאלה: איזה לרכוש? והתשובה, כצפוי, קצת מפותלת..

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

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

  • סמסונג – המלכה בשוק. דגמים של ה-960 וה-970, ה-PRO או EVO (ה-PRO יותר מהיר)
  • אינטל – ה-900P או ה-905P בסידרת ה-Optane. שימו לב שהם יקרים מאוד אך ה-905P הוא ה-SSD הכי מהיר שיש כיום בשוק נכון לשעת כתיבת שורות אלו. שימו לב – הפתרונות של אינטל יעבדו רק אם יש לכם מעבדי AMD Ryzen או i7/i5/i3 מהדור השביעי (Kaby Lake) או דור שמיני (Coffee Lake).
  • Western Digital – סידרת ה-Blue או Black בגירסת M.2 NVME.

אלו שלא מומלצים – אני בד"כ לא פוסל SSD כי כמעט תמיד יש סקטורים שזה יכול להתאים להם גם אם הם לא מהירים כל כך, אך במקרה של אינטל, סידרת ה-Optane Memory Series – בגדלים 16,32,64 ג'יגהבייט אני ממליץ לא לרכוש. הם מבחינה טכנית פשוט זבל וכל דיסק SSD מכל יצרן יתן ביצועים הרבה יותר גבוהים עם הפרשי מחירים זעומים.

אז בחרנו SSD ואנחנו מכניסים אותו למחשב. לפרמט ולהשתמש? כמעט. כלל חשוב הוא לא לפרמט את הדיסק לניצול 100% ממנו אלא רק 90%. הסיבה לכך פשוטה: במסגרת התהליכים שבקר ה-SSD מבצע, הוא בודק תאים לבדוק שהנתונים תקינים וכשהוא נתקל בנתונים שיש סיכוי שתהיה בעיה איתם בקריאה/כתיבה, הוא מעבר אוטומטית את הנתונים לחלק שלא פירמטנו והוא מסמן את המקום שממנו הוא העתיק כמקום לא שמיש, כך שאנחנו אולי מפסידים חלק מהמקום בדיסק, אך מצד שני אנחנו מאריכים את אורך חיי הדיסק, וזה שווה את המחיר.

האם כדאי לוותר על הדיסק המכני? התשובה שלי: לא. דיסק מכני הוא מצד אחד זול ומצד שני יכול להכיל הרבה יותר מידע מאשר SSD (סתם לידיעה, סמסונג 850 EVO בגודל 4 טרהבייט יעלה לכם בחו"ל 1500-1700 דולר). בד"כ יצרן ה-SSD יציע תוכנה יחד עם ה-SSD שתעביר את ה-Windows ל-SSD וידע לנטר את הדיסקים כך שנתונים שהקריאה שלהם שכיחה יועברו ל-SSD והנתונים שבקושי קוראים אותם ישארו בדיסק המכני. לאינטל יש תוכנה כמו RST שעושה זאת ול-AMD יש הסכם עם חברת Enmotus למכור תוכנה ב-20$ שנקראת FuzeDrive (היא אמנם מצריכה התקנה של Windows על ה-SSD מחדש, אבל היא עושה עבודה הרבה יותר רצינית מה-RST של אינטל), ויש כמובן תוכנות צד ג' בשוק ל-Windows (חלקן חינמיות). למשתמשי Linux – אם אתם משתמשים ב-LVM במחשב שלכם, אז ה-LVM יכול לקבל כונן או ווליום או Partition כ-Cache ואפשר כמובן להשתמש בדברים כמו bcache כדי לקבל את אותה תוצאה.

דברים נוספים שכדאי לדעת:

  • מעתיקים קבצים של כמה ג'יגהבייט כל אחד? אל תצפו לכתיבה מהירה לאורך כל ההעתקה ברוב כונני ה-SSD (למעט ה-900P/905P וה-970 PRO). הסיבה? הזכרון החוצץ (Buffer) מתמלא ומתחיל לכתוב את הנתונים לשבבי ה-NAND וברגע שאין זכרון פנוי, הכתיבה נהיית איטית.
  • עובדים בפוטושופ ופתחתם קובץ עם מאות שכבות? אם זה לא SSD מהמהירים – יכול להיות שזה יהיה איטי במעט. זיכרו: דיסקים SSD זולים הם טובים בהעברת נתונים רציפה כאשר מדובר בהעברת קובץ גדול, אולם כשיש לו עוד 200 קבצים נוספים, הוא יהיה איטי.
  • מחירים: מחירי ה-SSD יורדים אבל לאט. אם מחירי הדגמים שציינתי לעיל יקרים, אתם מוזמנים להתסכל דור אחד אחורה או לקרוא כל מיני אתרים שמציינים מיקומים שונים לכונני SSD ומחירים.
  • אחריות – כיום כמעט כל יצרני ה-SSD נותנים מינימום 3 שנות אחריות, אינטל וסמסונג בד"כ נותנים 5 שנות אחריות ולדגמים מסויימים אפילו 10 שנות אחריות. חשוב לכל ה-Corporate.
  • משתמשי לינוקס ובחירת File System – אין ממש הבדל. כיום גם XFS, EXT4, BTRFS תומכים בפרמטר mount או עם פקודת fstrim. מערכת ZFS לעומת זאת תתמוך בגירסה 0.8 בפונקציונאליות הזו (אם כי קיימים טלאים שאפשר להשתמש בהם).
  • קונים גירסה M.2 והולכים לגרום למחשב "להזיע"? חפשו ברשת קירור טרמי ל-M.2. אחד החסרונות של M.2 (בחלק מהמקרים) הוא כשה"מקל" חם מאוד – הביצועים יורדים על מנת לשמור עליו. הפתרון הזה לדוגמא, הוא פתרון טוב.

ומה העתיד? אינטל דוחפת חזק את פתרון ה-XPoint שלה שהוא כרגע המהיר ביותר בשוק (אבל גם היקר ביותר – ה-905P שלהם בגירסת ה-600 ג'יגהבייט עולה 1220$ והוא יותר מהיר מגירסת ה-Enterprise שלהם!) אבל סמסונג לא נמצאת מרחוק עם ה-Z-SSD שלהם שמציע ביצועי קריאה יותר מהירים מכל דבר אחר בשוק (ביצועי כתיבה, לא משהו בדור הנוכחי).
סביר להניח שבשנה הבאה נראה SSD מבוסס QLC (שזה 4 נתונים נכתבים/נקראים בכל תא). החסרון הענק שלו הוא מהירות הכתיבה שתהיה די "זוחלת" (בהשוואה ל-SSD אחרים), אבל מצד שני נוכל לרכוש SSD כאלו בגדלים של 4 ו-8 טרהבייט במחיר שלא מגיע לאלפי דולרים ובכך נוכל להחליף כוננים מכניים ב-SSD.

לסיכום: כונני SSD נותנים ביצועים הרבה יותר מהירים מכונני דיסקים מכניים, אבל הם גם "חיות" שונות וכדאי לשים לב להבדלים. השוק מוצף ב-SSD שונים ולכן כדאי לבצע מחקר קטן לפני ששולפים את כרטיסי האשראי. כדאי לשים לב להוראות יצרן לדברים כמו לא לפרמט SSD ל-100% ואם מדובר ב"מקל" M.2 לגבי עניין החום.

על בעיה X ופתרון Y

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

לקוח פוטנציאלי: היי חץ, יש לנו NetApp ואנחנו רוצים לדעת, יש פתרון מבוסס קוד פתוח שיכול להחליף?
חץ בן חמו: אולי.

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

  • מה הפונקציונאליות שהוא מחפש
  • מה הפונקציונאליות שמאוד חשובה לו, ומה הפונקציונאליות שבשבילו זה יהיה "נחמד" אם קיים אך אותה פונקציונאליות אינה קריטית.
  • האם הוא מחפש פתרון Scale Up או Scale Out
  • האם הוא מחפש פתרון שישולב כ-Hyper Converge או שהוא מחפש פתרון של ברזלים נפרדים
  • ויש עוד לא מעט שאלות…

ההבדלים ביני (וכמובן אחרים), כיועץ ואינטגרטור בלתי תלוי (כלומר אחד שהוא אינו בעצם Reseller של ברזלים ממותגים) הם דברים חשובים כגון:

  • אינטגריטי – אם מישהו יבוא אליי ויבקש לדוגמא פתרון סטורג' Scale Out והדבר הכי חשוב לו זה iSCSI לדוגמא, אז אני אומר לו בפשטות שכרגע אין פתרון Scale Out בקוד פתוח (גם כמוצר מסחרי) שיש לו פתרון iSCSI ל-Scale Out בצורה טובה והוא יצטרך פתרון קנייני.
  • על מה הפתרון אמור לענות? לקוח רוצה X על מנת לפתור את בעיית Y. נעזוב לרגע את X, ונשמע מהלקוח מהו אותו Y. אין ספק, דרישותיו של הלקוח הן חשובות, אולם ברגע שמספרים לי מהו אותו Y, אז ניתן להעלות מספר פתרונות שיכולים לענות על Y וגם להתחשב בצרכי הלקוח.
    לדוגמא: ללקוח יש 20 מכונות VM שמשמשות לפיתוח והלקוח רוצה פתרון סטורג' עבורם Scale Up. במקרה כזה אני יכול להציע לדוגמא פתרונות מבוססים ZFS, בין אם כקוד פתוח נטו או מוצרים מסחריים ובהצעה שאגיש לו יוסבר מדוע הפתרון הזה טוב ויוצעו ללקוח מספר פתרונות מבוססים ZFS, כך שבסופו של דבר ה-Y הם אותם 20 מכונות VM וה-X יהיה פתרון מבוסס ZFS.

וכאן בעצם מגיעה השאלה המרכזית שלי…

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

תכירו: 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…).

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

על עסקים קטנים ומעבר לעננים. כדאי?

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

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

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

אתן דוגמא: אתם קוראים את הבלוג הזה, שהוא חלק ממספר בלוגים שעבדכם הנאמן כותב. כל הבלוגים רוצים בשרת וירטואלי עצמאי שהיה נמצא בחברת Digital Ocean ועתה הוא נמצא באמזון תחת Amazon Lightsail. האתר עצמו, וה-Database שלו ושרת ה-Web – כולם מותקנים על שרת וירטואלי יחיד שעולה לי בחודש 40$. זה מה שאני משלם בכל חודש, בין אם נכנסו 3 גולשים או 2000 גולשים ביום, מכיוון שכמות ה-DATA היוצאת מהשרת אינה עוברת את כמות ה-DATA המוקצית עבורי בחבילה. יש חבילות כמובן יקרות יותר ויש זולות יותר, בהתאם לצרכי הלקוח והחברות המציעות שרותים אלו ושאני יכול להמליץ עליהן (כולל Amazon Lightsail שהזכרתי לעיל) הן Digital Ocean ו-Linode ויש כמובן חברות נוספות בהתאם להמלצות שאתם יכולים לקבל מאחרים אולם אלו ההצעות הפופולריות ורציניות.

כמובן שגם ספקי הענן הציבורי מציעים מוצרים כמו קונטיינרים, מכונות וירטואליות וכו', אולם שם התעריפים שונים מההצעות לעיל. לדוגמא: אם באמזון ניקח מכונה ב-EC2 (לא בחבילת ה-Lightsail) כמו המכונה שיש לי, המחיר יהיה $43.63 עד לתעבורה של 100 ג'יגהבייט, אולם אם מחר אפרסם פוסט שיהפך לויראלי, אני אגיע בקלות גם לתשלום של 50-100$ לחודש. אם נבנה ב-Google Cloud את אותו מפרט של מכונה (מכונה מבוססת לינוקס, 2 ליבות, 4 ג'יגהביייט זכרון, 40 ג'יגה דיסק SSD ו-100 ג'יגהבייט תעבורה החוצה) נגיע ל-$61.22. ב-Azure אותה חבילה תעלה לנו $48.42. כך יוצא שהלקוח משלם יותר על פחות. (אגב, ב-Azure תצטרכו לשלם יותר כי הדיסק מוגדר "זמני", ודיסק מבוסס רשת עולה יותר). הערה: המחירים יכולים להיות אצל חלק מהספקים זולים יותר – אם אתם משלמים מראש שנה או שנתיים.

יש כמובן את ההצעה של קונטיינרים, שהם מעין "מיני" מכונות וירטואליות, אך גם כאן אין ממש בשורה. אם ניקח לדוגמא את ההצעה של Azure, אז רק לשם שימוש בשרות (AKS) תצטרכו לשלם $87.60 ועל כל קונטיינר (תצטרכו מינימום אחד) תצטרכו לשלם בנוסף, כך שההצעה כבר מההתחלה אינה משתלמת לאותם עסקים קטנים.

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

שלח לחמך על פני המים

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

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

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

אישית נתקלתי ב-2 המצבים, גם כאשר חברות יצרו עמי קשר לשאול אולי אני מכיר מישהו שיכול לעשות עבודה X וכן.. גם לי קרה שהיו לי מס' חודשים שלא היתה עבודה. לכן ניסיתי לחשוב על פתרון כלשהו שמצד אחד פרילאנסרים יוכלו לרשום את עצמם ופרטיהם בתוך טופס Google Form ומצד שני את הפלט אוכל להעביר לכל מיני חברות שמחפשות מדי פעם פרילאנסרים וכך יווצרו כל מיני "שידוכים" בין דורשי עבודה לקבלני עבודות לפרילאנסרים. נוסיף את העובדה שגוגל די "מחבב" (מבחינת מיקומים) את הבלוג הזה, כך ש-2 הצדדים יכולים להרוויח מכך (אני בכל מקרה לא מחפש להרוויח כספים מכך, אבל לא אתנגד לפיתה עם שווארמה 🙂 ).

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

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

תודה,
חץ בן חמו
[email protected]

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

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

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