קטגוריה: וירטואליזציה

קונסולידציה – השלב השני שלא מבצעים

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

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

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

ניקח דוגמא: לפנינו 4 ארונות 42U, הם עמוסים ב-40 שרתי 1U בכל ארון (כן, אני משער שבמציאות כמות השרתים פר ארון היא מופחתת הואיל וחלק מהשרתים הם 2U, בחלקם יושבים מדפים של סטורג', סוויצ'ים וכו'). אני מאמין שבכל שרת יש 2 מעבדים שכל אחד מהם הוא 4 או 6 ליבות.

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

  • כמות החשמל שמנוצלת פר ארון היא בערך 12 קילוואט שעה.
  • סביר להניח שפרוסים 40 רשיונות VMWARE Enterprise PLUS רק בארון הזה.

אז איך ניתן לפתור את בעיות הרשיונות או קיצוץ תקציב ה-Datacenter?

התשובה ל-2 בעיות אלו קשורה לפתרון קונסולידציה. קחו לדוגמא ארון עם 40 שרתים – את אותו ארון ניתן להעיף ממנו 34-36 שרתים החוצה וזאת מבלי שצריך לוותר על מכונות VM אחת! נכפיל ב-4 ארונות ונקבל שאנחנו יכולים להגיע למצב שבארון אחד נאחסן 24 שרתים ונקבל את אותם ביצועים וממצב של שימוש של כמעט 50 קוט"ש, נוכל לצמצם זאת ל-5 קוט"ש לערך, חסכון של 90% בחשמל!

גם מבחינת רשיונות VMWare נוכל לקצץ מ-160 רשיונות ל.. 24 רשיונות, יותר מ-75% חסכון מבלי לוותר על שום פונקציונאליות!.

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

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

[stextbox id='info' caption='גילוי נאות']פוסט זה מדבר על שרות בתשלום שניתן ללקוחות[/stextbox]

להטמיע סטורג' בקוד פתוח או לא? מה השיקולים?

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

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

מכאן נעבור לצד הטכני: האם מערכות סטורג' בקוד פתוח יכולות להוות תחרות מול סטורג' קנייני מבחינה טכנולוגית? התשובה: כן. האם הן יכולות לתת את 3 השרותים העיקריים שחברות מחפשות (CIFS/SMB, NFS, iSCSI)? בחלק המקרים. האם הן יכולות לגדול (Scale Out)? גם – בחלק מהמקרים. על מנת לפשט דברים, יצרתי טבלה פשוטה עם 3 המתמודדים הידועים בקוד פתוח, מה הם מסוגלים לתת ומה לא.

סוג מערכת NFS iSCSI CIFS/SMB Scale Out Scale Up
ZFS 2✔ 1✔ ✔ 3✔
GlusterFS ✔ ✔ 4✔
Ceph ✔ ✔ ✔ ✔

1 תמיכת iSCSI ב-ZFS על לינוקס עבור VMWare כולל תמיכת VAAI מחייבת Kernel 4.4 ומעלה.
2 תמיכת NFS ב-ZFS על לינוקס תלויה בגירסת הפצת הלינוקס
3 ניתן לעבוד עם ZFS בלינוקס כ-Cluster בשימוש כלים כמו Sanoid או PaceMaker.
4 למרות שניתן לעבוד עם GlusterFS ב-2 שרתים – הדבר אינו מומלץ מעבר לרמת POC.

אלו המערכות העיקריות. לכל מערכת יש מספר גרסאות מסחריות (למעט GlusterFS). מערכת כמו ZFS ניתן לרכוש מערכת עם "ברזלים" ישירות מ-Oracle או ניתן להתקין FreeNAS, או להקים על שרת לינוקס עם הפצת Debian לדוגמא. תוכנת Ceph ניתנת לרכישה מ-רד-האט או מ-SuSE.

כשזה מגיע לתמיכה/תחזוקה – הדברים שונים בהתאם לגודל העסק/חברה:

  • לעסק קטן שמחפש סטורג' ואולי סטורג' עם שרת ב-Standby (כלומר Active/Passive – כ-Scale Up) הייתי ממליץ לבחור פתרון מבוסס ZFS. אם הלקוח מחפש פתרון Scale Out של כמה טרהבייט, אז אמליץ על GlusterFS וחוזה תמיכה עם אינטגרטור.
  • לעסקים בינוניים וגדולים, אם העסק מחפש פתרון מבוסס קוד פתוח ב-Scale Up, הייתי ממליץ על ZFS ופתרון Scale Out מבוסס Gluster. אם החברה מחפשת פתרון Scale Out בגדלים של Petabyte, אני ממליץ על Ceph. במקרים של GlusterFS ו-Ceph אני ממליץ לחברה לרכוש את התוכנה מהיצרן כולל תמיכה, כך שהאינטגרטור יתן תמיכה ואם יש עדיין בעיה – ניתן לפנות ליצרן התוכנה כך שבכל מקרה החברה מכוסה מבחינת תקלות תוכנה.
  • לחברות גדולות המחפשות פתרון סטורג' גדול מבחינת כמות DATA (שוב, פטהבייטים ומעלה) – אני ממליץ על ישיבה ויעוץ לגבי הפתרון מכיוון שבכל מקרה הפתרון הוא יקר ויש צורך לשמוע את 2 הצדדים (פתרון קנייני ופתרון מבוסס קוד פתוח).

בכל אחד מהסוגי לקוחות, הפתרונות המוצעים כוללים פתרון שרידות כך שלמעט תקלות חומרה או הפסקת חשמל, המערכת אמורה לשרוד נפילה אם יש תקלת תוכנה בסטורג' עצמו. אגב, בהזדמנות זו אני רוצה להדגיש: כאשר אתם קונים פתרון סטורג' שהוא Scale Up מ-NetApp או Dell/EMC, פתרון השרידות שלו הוא חלקי: זה שיש בקר RAID כפול, 2 מעבדים – תקלות כמו בעיית זכרון (ECC יכול לתקן תקלות עד גבול מסויים), או בעיה בלוח האם ב"ראש" – הסטורג' יפול, וכדאי לקחת זאת בחשבון כשרוכשים פתרון.

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

על Spectre/Meltdown ועל יצרניות סטורג'

הערה: הפוסט הבא נכתב כטור דעה אישית בלבד ואינו בא "לתקוף מתחרים"

כולנו שמענו על הצרות עם Meltdown ו-Spectre. בחברות מסויימות מיהרו להטמיע עדכוני BIOS/UEFI רק כדי לראות מערכות שבאופן רנדומלי מבצעות Cold Reboot ללא השארת עקבות והצהרות מצד היצרנים לא להתקין את העדכונים האחרונים ואם הם הותקנו – יש לבצע Rollback.

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

תסלחו לי, אבל מדובר לדעתי האישית בחתיכת בולש*ט!

אני רוצה להפנות את תשומת לבכם למכשיר שאולי אתם מחזיקים כרגע ביד, או שנמצא על שולחנכם או בכיסכם: הסמארטפון שלכם. לא חשוב אם יש לכם אייפון או מכשיר מבוסס אנדרואיד של יצרן גדול וידוע. המכשיר שלכם יודע לבצע Boot והרצת דברים חתומים ומאושרים בלבד. במכשירי אנדרואיד של יצרנים כמו סמסונג, גוגל, LG, מוטורולה לדוגמא, אם תרצה לפרוץ את המכשיר ולשים לו ROM אחר, לא תוכל לעשות זאת אלא רק אם תבצע unlock למכשיר וברגע שתבצע – כל הנתונים האישיים שלך ימחקו מהמכשיר כולל שירים ווידאו שרכשת. באייפון אין בכלל אפשרות כזו. במידה ותנסה להתקין באנדרואיד תוכנה חיצונית שהורדת כקובץ APK, המכשיר לא יתן לך לעשות זאת אלא אם תלך להגדרות ותאפשר לו התקנה ממקורות חיצוניים (ואז תקבל חלונית אזהרה). באייפון זה יותר הדוק בכך שאינך יכול להתקין תוכנות חיצוניות שלא מהחנות ותצטרך לבצע jailbreak ולהתקין מס' תוכנות נוספות כדי לפרוץ את המכשיר. אך כמו שכולנו יודעים, גם לאנדרואיד וגם לאייפון היו (ויש) נוזקות, פריצות ועוד דברים אחרים, לא חשוב כמה המכשיר סגור, עדיין ניתן לפרוץ אותו כולל במערכות הפעלה החדשות וגם לאחר עדכונים, תמיד מישהו ימצא דרך לפרוץ.

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

כיום, מה שבד"כ רואים בפריצות למערכות, זה שמנסים לפרוץ אל השרתים ומכיוון שלשרתים אין גישה לכל מה שנמצא על ה-Storage, אפשר לגשת דרך השרת רק לחלק מהמידע. עכשיו תנסו לחשוב על פורצים מתוחכמים וממומנים. תחשבו על חברות מתחרות שיש ברשותן מאות מילונים/מיליארדי דולרים, תחשבו על מדינות כמו סין ורוסיה שמחזיקות צבא של פורצים ושהן מעוניינות במידע שלך. גם באותם גופים קוראים חדשות והם קוראים שיצרניות ה-Storage מתחמקות והן לא הולכות לבצע עדכוני Meltdown/Spectre. עכשיו אותם פורצים פשוט צריכים לשנות אסטרטגיה: עכשיו הם צריכים בעצם לפרוץ לתחנת עבודה שמריצה Windows או מק או לינוקס ומשם לפרוץ לממשק ווב או לקונסולה (CLI) של ה-Storage, להעלות משהו כמו busybox ואז להשתמש ב-חורים Spectre/Meltdown כדי לקבל מידע סודי/פנימי/חסוי. (הנה משהו שאולי יכול לעזור לכם: בדקו אם יש לכם ACL שנותן גישה לממשק רק למכונות מסויימות בחברה).

מדוע החברות Storage עושות זאת? אני יכול רק לנחש: אם הם יתקינו את הטלאים נגד Spectre/Meltdown – תהיה ללקוחות הנחתה רצינית מאוד בביצועים. כמה? אני יכול להמר בסביבות ה-5-40% תלוי כמובן כמה ה-Storage חדש או ישן. את הלקוחות לא יעניין שהחור קשור למעבדים של אינטל, הם יפנו אצבע מאשימה ליצרני ה-Storage ויצרניות ה-Storage יצטרכו להחליף לוח עם כמעט כל החומרה (למעט כרטיסים וספקי כח..) והמחיר לדבר כזה הוא אסטרונומי מבחינתם.

לסיכום: האם הטיעון של יצרני ה-Storage יחזיק משהו? אני בספק. לחברה הראשונה שיפרצו ותהיה הוכחה שהפורצים חדרו דרך הממשקים והשתמשו ב-Spectre/Meltdown, תהיה לדעתי גל תביעות נגד היצרנים. תזכרו: כלקוחות, ממש לא מעניין אתכם איזה מעבדים ואיזה ציוד נמצא על לוח האם של ה-Storage, אתם רוצים ביצועים נטו, וגם אם יהיה שם מעבדים של ARM זה לא ממש יעניין אתכם.

מה ההבדל האמיתי בין SSD רגיל ל-SSD ל-Enterprise?

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

הרשו לי להציג לכם את ה"יורש" של הסמסונג 850 PRO  שיצא שלשום – אחד מכונני ה-SSD שהצליח במשך 3 שנים להתעלות מעל רוב כונני ה-SSD הביתיים מבחינת ביצועים. זהו הסמסונג 860 PRO. מבחינת ביצועים הן מבדיקות והן "על הנייר" – זו חיה: 560 מגהבייט לשניה בקריאה ו-530 מגהבייט לשניה בכתיבה (זהו כונן בחיבור SATA). מבחינת IOPS יש לו בהחלט מה להתגאות: 100000 בקריאה, 90000 בכתיבה, ואורך החיים שלו – אתם יכולים לכתוב עליו ולמחוק – עד 4800 טרהבייט בכל משך ימי חייו. שום דיסק מכני לא נותן דבר כזה כמובן. מחיר: $238 לחצי טרהבייט.

והנה ה"אח הבכור" – ה-960 PRO בגירסת M.2 NVME. הביצועים? 3.5 ג'יגהבייט קריאה, 1.9 ג'יגהבייט כתיבה. IOPS? טוב ששאלתם: 440000 בקריאה, 360,000 בכתיבה. המחיר: $300 לחצי טרהבייט. אפשר לכתוב עליו באורך חייו כ-400 טרהבייט. (כן, ה-860 מחזיק הרבה יותר).

תכירו את ה-SSD החדש ביותר של אינטל (כתבתי עליו בעבר) – ה-900P. הוא יקר יותר ($628 לגירסה של 480 ג'יגהבייט), הוא יותר איטי בגישה לנתונים (2.5 ג'יגה בקריאה, 2 ג'יגה בכתיבה) אבל כשזה מגיע ל-IOPS, הוא בועט בכולם: 550,000 בקריאה, 500,000 בכתיבה.

אז מי מהם מתאים לחברות ומי לא מתאים לבית? ומדוע ההבדלים?

נתחיל ב-900P (הוא "האח הקטן" של ה-DC P4800X). נניח שאתה רוצה SSD מהיר לבית, אתה עורך וידאו נניח או מוכן לשפוך סכומים רציניים על המחשב למשחקים שלך. הכסף לא ממש משנה לך. האם כדאי לקנות אותו? התשובה היא לא. אם נעמיד את ה-900P במבחן מול ה-960 PRO או ה-860 PRO, שתיהם ינצחו אותו בקלות, כלומר אתה יכול לחסוך 300 דולר ולקבל SSD שיתאים לך לבית.

עכשיו נלך לחברה. נניח שאנחנו מקימים Storage משלנו, נניח שאנחנו מקימים שרת SQL כלשהו (לא חשוב אם זה מיקרוסופט, אורקל או PostgreSQL או MySQL) או שרת אפליקציה שאמור לתת שרות למחשבים רבים או משתמשים רבים. כאן דווקא ה-900P יתן ביצועים הרבה יותר גבוהים בהשוואה ל-2 ה-SSD של סמסונג, הם "יחנקו" מהר מאוד.

ה-SSD ל-Enterprise בעקרון בנוי לתת שרות לכמה שיותר משתמשים/מחשבים/תחנות, כמה שיותר Clients, בשעה שה-2 השניים בנויים לתת שרותים לכמה שפחות, כלומר למחשב אחד, לכמה אפליקציות שרצות במקביל במחשב הביתי/תחנת עבודה. במילים אחרות – אם לא מעמיסים על דיסק SSD ל-Enterprise אתם תקבלו ביצועים רחוקים מאוד ממה שמוצהר ע"י היצרן.

פרסמתי כאן בתחילת השנה פוסט על SSD ל-Enterprise והוא רלוונטי בדיוק לפוסט זה. בפוסט הקודם הזכרתי את ה-QD (ה-Queue Depth) שצריך אותו כדי לתת שרותים לכמה שיותר Clients וזה בדיוק מה ש-SSD ל-Enterprise מצטיין בו ו-SSD לבית גרוע בו. ניקח לדוגמא את ה-960 PRO, אם תסתכלו בסקירה זו תיראו שברגע שמתחילים להעמיס עליו, הביצועים צונחים דרמטית.

עכשיו נשארנו עם בעיה אחת: נניח ואנחנו רוצים ביצועים מאוד גבוהים לשרתים עם דיסקים מקומיים (כן, לאלו שמריצים vSphere עם דיסקים מקומיים לדוגמא) אבל המחיר מפחיד. ה-DC P4800X לדוגמא בגירסה צנועה של 375 ג'יגהבייט עולה $1700 (המחיר קצת יקר באמזון, המחיר הרשמי הוא $1520) וגירסת ה-750 ג'יגהבייט עולה מחיר "צנוע" של $3,653. במחיר כזה, גם חברות גדולות מתחילות לחשוב פעמיים אם לקנות במחיר כזה.

מה ניתן לעשות? ישנן מס' אפשרויות:

  • לקנות כמה קטנים. אפשר לדוגמא לרכוש 2 כרטיסי 900P (אגב, אם השרתים שלכם חדשים, אז ניתן לקנות את ה-900P בגירסת U.2 שנכנסת מקדימה) ולחבר אותם ב-RAID-0 ולהגדיר אותם כ-Cache. זה מתאים למצבים שאנחנו רוצים להריץ את השרת כשרת קבצים או כשרת NFS/SAMBA ואליו נחבר לדוגמא שרתי vSphere.
  • אם אנחנו רוצים להריץ שרת SQL או שרת אפליקציה כבד, נוסיף דיסק SSD כלשהו למערכת, עליו נתקין את מערכת ההפעלה והאפליקציות אך ה-DATA ישב ב-RAID-0 (מתוך הנחה שיש לכם גיבוי יומי!) כ"כונן" נפרד.
  • נבחר כונני Enterprise יותר זולים. לאינטל יש את ה-750 שישן קצת (מ-2015) אבל נותן ביצועים יותר טובים, יש את ה-P4600 ו-4700, שהם מעולים. חברות גדולות, כמובן, לא קונות כוננים ישירות מאינטל או סמסונג, ולכן מומלץ לחברות אלו לבדוק מיצרן השרת שלהם אלו דיסקים ניתן לקנות (לא מומלץ לקנות עם חיבור SAS, לכולן יש פאנל קדמי לחיבור דיסקים SSD בחיבור U.2 או SATA).

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

על פריצת ה-Spectre V2

בפעם הקודמת כתבתי כאן על הפריצות Meltdown ו-Spectre, על תיקונים ועל ביצועים. הפעם אני מעוניין להתעכב על Spectre גירסה 2 (V2), ומה קורה עם זה.. למעוניינים: פריצת Meltdown כבר תוקנה, ה-Spectre V1 גם (פחות או יותר) אבל Spectre V2 מתגלה כבעיה עקשנית..

והאצבעות מופנות הפעם ל… אינטל. (היתה בעיה עם מעבדי AMD, היא כבר טופלה [כולל במעדי Epyc ו-Threadripper]).

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

את הפירצה בגירסה 2 של Spectre אפשר לסכם בפשטות כך: מריצים VM בוירטואליזציה כלשהי? (באמת שלא חשוב מה פתרון הוירטואליזציה, כולם משתמשים ב-VT-X, VT-D במעבדי אינטל) אז מאותו VM ניתן להגיע למכונות VM אחרות ול-HOST עצמו. מריצים קונטיינרים? אז מהקונטיינר ניתן להגיע אל ה-HOST עצמו וב-2 המקרים מספיק קוד זדוני די קטן כדי להשתמש בפירצה. מספיק חמור?

בניגוד למקרים אחרים, בכדי לטפל ב-Spectre V2 צריך עדכון מיקרוקוד ישירות למעבד וכאן הדברים מתחילים להיות טיפה יותר מורכבים: כשזה מגיע ללינוקס ול-VMWare (נו טוב, VMWare בחלקן מכיל תואמות ברמת ה-Host ללינוקס ברמה של ABI) – אז עדכון המיקרוקוד מגיע מיצרן הפצת הלינוקס או מ-VMWare, כך שלא צריך לפנות ליצרן החומרה כדי לקבל את העדכונים. בעקרון, לינוקס קורא אמנם את הגדרות ה-UEFI/BIOS אבל לא מתייחס לכל ההגדרות ברצינות (מפתחי Kernel ותיקים בלינוקס די מזלזלים במימושי ה-UEFI/BIOS, בהצדקה מסויימת).

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

אינטל שחררה עדכוני מיקרוקוד ויצרניות הפצת הלינוקס הכניסו אותו לעדכוני הפצת לינוקס, וגם VMWare הכניסה את העדכון (דרך ה-VUM), אלא שאז התגלתה הפדיחה של אינטל. כנראה שאינטל לא ביצעה מספיק ניסויים ובדיקות על מעבדי E5/E7 V3, V4 וחלק מהחברות שעדכנו את המיקרוקוד קיבלו "הפתעה" לא נעימה – אתה מפעיל את המכונה, מתחיל לבצע עבודות ולפתע – המחשב מבצע לעצמו Reset. אין לוגים, אין כלום. נסו לדמיין את זה על שרת שמריץ ESXI או איזה שרת DB כבד שפתאום מנתקים לו את החשמל.

כתוצאה מכך, VMWare, RedHat ואחרים החליטו לבצע Rollback וכנ"ל גם יצרני שרתים ששחררו עדכוני מיקרוקוד דרך מערכות העדכונים שלהם ל-Windows. במכונות לינוקס כשבודקים את עניין המיקרוקוד לאחר עדכונים מיום שלישי, זה נראה כך (ב-CentOS 7 וב-RHEL 7) כשבודקים את ה-Changelog. אני מאמין ששאר הפצות הלינוקס גם חזרו אחורה.

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

שימו לב: ההבדל העיקרי בין עדכונים מיצרן השרת לבין עדכוני לינוקס/VMWare בכל הקשור למיקרוקוד, הוא שבמערכות לינוקס/VMWare, עדכוני המיקרוקוד חלים על המערכת זמנית, אחר ה-Boot ואילו עדכוני המיקרוקוד של יצרן השרתים שנמצאים בחבילת ה-BIOS/UEFI הם קבועים. זה לא כל כך משנה בלינוקס וב-VMware אולם בהחלט משנים ברמה של מערכות מבוססות Windows.

אז מה עושים כרגע? לא ניתן לעשות יותר מדי דברים עד שיצא עדכון חדש. בשלב זה אם תיפנו ל-Red Hat (ואתם לא לקוח גדול כמו בנק או חברת Fortune 500) אז תופנו בנימוס ליצרן השרת שיטפל בכם (ויצרן השרת יפנה בנימוס ל-Red Hat כי עם כל הכבוד, תמיכת הלינוקס של יצרני השרתים היא לא בדיוק רמה גבוהה..) ואם תפנו בנימוס לאינטל, היא תפנה אותך ליצרן מערכת ההפעלה שלך ואם מערכת ההפעלה שלך היא Windows אתה תופנה בנימוס ל.. יצרן המכונה שלך. כיף!!

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

לסיכום: כרגע, לא ניתן לעשות הרבה זולת המתנה לאינטל שישחררו עדכון מיקרוקוד יותר יציב שנבדק על מעבדים ישנים יותר. אם יש לכם מערכות סריקה (IPS ושאר קיצורי שמות) – אני מאמין שהם הוציאו עדכוני חתימות לגלות אם מישהו מנסה להזריק לכם קוד שמשתמש ב-Spectre (אבל אני לא בטוח כמה זה יתפוס, אפשר להשתמש בפירצה הזו גם עם קוד JS פשוט ובמקרים רבים ניתן פשוט לבצע code obfuscation ["ערפול קוד"], במיוחד כשיש לכם מערכות חשופות לאינטרנט).

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

הבאג הקריטי במעבדי אינטל – עדכונים

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

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

בפעם שעברה דיברתי על הנחתה בביצועים בין 5 ל-30%, וכאן יש לעדכן: זה תלוי במעבדים בשרתים. מעבדים עד 5 שנים אחורה. מעבדים כמו Xeon E3/E5/E7 V3 ומעלה יש בתוכם פונקציונאליות שעוזרת למגר את הנחתת הביצועים כך שלא תהיה הנחתה משמעותית בביצועים, אולי אחוזים בודדים.

במעבדים היותר ישנים (שרתים כמו DELL דור 11 ומטה, HPE דור 7 ומטה, לנובו/IBM דור M3 ומטה) עדיין יורגשו הנחתות בביצועים במקרים מסויימים. המקרה הכי נפוץ שמצאתי הוא שכשמריצים שרתים כאלו כ-Hypervisor (כמו Hyper-V או ESXi) ומריצים את המכונות דרך Datastore שעובד על דיסקים מקומיים. מכיוון שלשרתים אלו אין אפשרות להיות משודרגים למעבדים מדור 3 ו-4 (טוב, למעט SuperMicro ששם אתה יכול להחליף לוח אם, בנוסף למעבדים, ובנוסף גם זכרון..) – האפשרויות שישנם הינן:

  • להקים מכונת VM שמחוברת לבקר דיסקים ולהריץ עליה מערכת שרות קבצים NFS/iSCSI.
  • להקים פתרון כמו שתיארתי לעיל אבל בתצורה פיזית.
  • לקנות פתרון סטורג' כלשהו.

(אם אתם בין כה מתכננים לגרוט או למכור או להיפטר משרתים כאלו, צרו עימי קשר)

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

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

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

לסיכום: מכיוון שרוב החברות הגדולות כבר לא מחזיקות בשרתים ישנים – אז הבעיה אינה כל כך חמורה בכל הקשור ל-Meltdown. בנוגע ל-Spectre בגירסה הראשונה, העדכון לא מוריד ביצועים (והתיקונים לגירסה השניה יעשו הן ע"י יצרניות מערכות הפעלה והן ע"י יצרניות אפליקציות). עדיין נשארו בעיות בכל הקשור ל-Spectre על טלפונים מבוססי אנדרואיד ועדכונים יצאו ע"י יצרני הטלפונים (ואם יש לכם מכשירים ישנים, אולי כדאי להחליף להם ROM למשהו כמו LineageOS). מבחינת ספקי ענן – כולם משתמשים בציוד די חדיש וכולם מעדכנים את כל השרתים שלהם, יכול להיות שתקבלו הודעה מנומסת מהן לעשות Reboot ל-Instances שלכם. מבחינת מחשבי Desktop, לאפטופים – ההנחתה בביצועים כמעט ולא קיימת. מה שהכי חשוב – יש לעדכן את כל השרתים ולבצע לאחר מכן Reboot לאותם שרתים.

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

קצת על בנקים, מודרניזציה ותשובות למר איל מוסקל

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

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

אז נתחיל עם ה-Mainframe. רבים מהקוראים בוודאי חושבים שמדובר על טכנולוגיה עתיקה וישנהאך אין הדבר כך. נכון, IBM שומרת בקנאות פנאטית על תאימות כמה דורות אחורה, אבל מערכות Mainframe מתעדכנות מבחינת חומרה נון-סטופ ומבחינת ביצועים, מעבד כמו ה-Power9 "מרביץ" למעבדים כמו Xeon-SP בכל מובן שתבחרו. בנוסף, אחד היתרונות הגדולים של מערכות Mainframe הוא תחזוקת חומרה. בשרתים רגילים, אנחנו יכולים להחליף דיסק קשיח מבלי לכבות את השרת או ספק כח, ב-Mainframe אתה יכול להחליף כמעט הכל – מעבדים, כרטיסי PCIE, זכרונות בזמן שהמערכת פעילה והיציבות של המערכת היא אחד הדברים ש-IBM בהחלט יכולים להתגאות בו. זה פשוט לא נופל.

בעבר רוב האפליקציות שנכתבו ל-Mainframe אכן היו ב-COBOL ויש חלק לא קטן מהקוד שעדיין רץ ב-COBOL, אבל בשנים האחרונות בנקים שיש להם Mainframe החלו להשתמש בפונקציונאליות חדשה ש-IBM הכניסו: להריץ מכונות Linux כ-VM על ה-Mainframe בצורה טבעית (ללא אמולציה של X86) עם ביצועים מאוד מהירים בעזרת כרטיסים יעודיים עם מעבדי Power8 (ובזמן האחרון Power9) שמיועדים להריץ Linux. כך הבנקים נהנים מ-2 יתרונות גדולים: אפליקציות Linux שרצות באופן טבעי על Mainframe ובנוסף מערכת ה-Mainframe יציבה מאין כמוה.

לגבי שפת COBOL – נכון, היא שפת תכנות עתיקה (משנות ה-50) אולם היא עברה עדכונים רבים וסטנדרט ה-COBOL גם עבר עדכונים וכיום הסטנדרט ב-COBOL הוא ISO/IEC 1989:2014 – כלומר יש בהחלט עדכונים לשפה. נכון, היא שונה משפות כמו Python, Go, Perl וכו' אך מצד שני היא לא כזו קשה ללימוד, זו שפה שיותר מבוססת על השפה האנגלית.

אחד הדברים שמר מוסקל לא מתייחס אליהם הוא נושא פרויקטים שהבנקים (כל הבנקים) מבצעים: שכתוב מחדש של קוד COBOL ישן ל-Java מודרני. אף בנק לא מעוניין "להיתקע" עם מערכת ישנה שאין לה אף אחד שיתחזק אותה, ולכן מבוצעים הפרויקטים הנ"ל, ובבנקים נכנסים יותר ויותר לעבודה עם כלים סטדנרטיים כמו GIT, יש גם Jenkins שיודע להתחבר ל-zOS (מערכת ההפעלה העדכנית של ה-Mainframe של IBM) וגירסת Docker Enterprise Edition 17.06 יודעת להתחבר למערכות System Z (ה-Mainframe) להריץ קונטיינרים על Linux שרץ ב-Mainframe.

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

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

ונקודה אחרונה מבחינה טכנית: למיטב ידיעתי, כל בנק בישראל החל "לפזול" לכיוון קונטיינרים כפתרון Scale Out כדי לעמוד בעומסים שונים, כך שמצד אחד הבנק "מגייר" אפליקציות מ-COBOL ומצד שני הבנק בודק טכנולוגיות קונטיינרים שונות. כיום, אם בנק ישאל "חץ, האם לעבור לקונטיינרים לפרודקשן?" תשובתי תהיה: "בשלב זה, התשובה היא לא" מכיוון שלדעתי בנקים יצטרכו פתרונות קונטיינרים יותר מאובטחים כמו Clear Containers של אינטל וטכנולוגיה זו היא צעירה ועדיין לא בוגרת מספיק כדי לזרוק אותה לפרודקשן.

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

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

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

אחד מול השני: 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 מכונות נותן שרידות הרבה יותר טובה וגם נהנים ממהירות הביצועים.

כמה מילים על לימוד-מכונה ועל GPU ועננים

עדכונים לפוסט – בסופו.

בשנים האחרונות, תחום ה"לימוד מכונה"/"לימוד עמוק"/"AI" ושלל שמות נוספים (ותוסיפו לכך טונות של Hype) קיבלו תאוצה מאוד חזקה. כיום התחום "חם" מאוד ואלו שמכירים את התחום נחטפים, וחברות כמו אמזון וגוגל מציעות משכורות מאוד מפתות (כמה מפתות? 50K ומעלה לחודש, בשקלים כמובן, ויש גם מענק חתימת-חוזה, תלוי כמה אתה מכיר, וכמה אתה מנוסה). סטארט אפים לנושאים אלו צצים כמו פטריות לאחר הגשם וכמובן שחברות הענן הציבורי הזדרזו להוציא שרותים שמציעים תחומים אלו בקלות מופלאה – תכניס את ה-DATA, הנה API קל לשימוש ובהצלחה.

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

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

  • אתה בונה את התוכנה (או משתמש בשילוב של Tensorflow, Caffe2 ושאר ספריות) ו"מסביר" לתוכנה מה אתה בעצם רוצה לעשות.
  • אתה מכניס את הנתונים שאתה רוצה לעבד.
  • אתה מכוון שוב ושוב ושוב ו"מאמן" את האלגוריתמים שהתוכנה תכיר את הנתונים ותתן תוצאות שאתה רוצה שתתן – עד לתוצאות שאתה רוצה.

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

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

זה – במבט על מגבוה בערך מה שקורה.

הבעיה מתחילה כשמקימים את החלק הראשון בענן. כיום, ברוב המקרים מומלץ לעשות את הדברים על GPU הואיל והוא מכיל אמנם "ליבות טיפשות" שמסוגלות לעשות רק דברים פשוטים, אבל יש אלפי ליבות פר GPU ולכן העיבוד יהיה הרבה יותר זריז מאשר לבצע אותו על CPU. הבעיה מתחילה בכך שאינך מקבל מקבל GPU יעודי עבור המכונה/מכונות שלך אלא רק חלק ממנו. כמה? אף ספק לא אומר, אבל אני יכול להמר על 1/8 או יותר נמוך (1/16, תלוי כמה GPU יש במכונה, תלוי כמה VM רצים עליה ושאר פרמטרים).

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

חברות גדולות שעוסקות בתחומים הללו כבר למדו שבכל מה שקשור לאימון, עדיף לעשות זאת In house ולא לסמוך על עננים, ומכיוון שהן חברות גדולות, הן יכולות להרשות לעצמן לרכוש מכונה כמו ה-DGX-1 של nVidia. כמה עולה המכונה הזו? 130,000 דולר, סכום שאין להרבה סטראטאפים או חברות קטנות או בינוניות. בשרת זה ישנם 8 כרטיסי Tesla מבוססי Volta (הארכיטקטורה החדשה של nVidia) שכוללים ליבות יעודיות ל-Tensor והרבה ליבות שמיועדות ל-CUDA. בנוסף, הכרטיסים מחוברים ביניהם עם NVLink שנותן מהירות מדהימה של 200 ג'יגהבייט לשניה פר כרטיס. בקיצור – מפלצת יעודית ל-AI/DL/ML. (אפשר ללחוץ על התמונה על מנת לקבל את הפרטים).

לאחרונה חברת nVidia הבינה שאותם חברות קטנות ובינוניות מעוניינות גם בפתרון. הם לא מחפשים לקנות DGX-1 והם מעדיפות פתרון יותר זול אך חזק. כרטיסים גרפיים כמו GTX 1080TI או אפילו Titan Xp הם טובים, אך המהירות עדיין אינה מספיקה.

לכן nVidia הוציאה בימים האחרונים את הכרטיס מימין. תכירו – זה ה-Titan V, ה"אח הקטן" של Tesla V100. מדובר על כרטיס עם אותו GPU כמו אחיו הגדול, אך יש לו 12 ג'יגהבייט זכרון (ב-Tesla יש 16), אין אפשרות לשרשר אותו עם Titan V אחרים (ואין SLI) ויש עוד מס' הבדלים – טבלת השוואה ניתן לראות כאן. אגב, אם אתם רוכשים כרטיס כזה, שדרגו ל-CUDA 9.1 שידע לתמוך בכל הפונקציות של הכרטיס.

מחיר הכרטיס (לא כולל מסים ומכס) – 3000$. יקר בהרבה מכל כרטיס אחר שמיועד ללקוחות פרטיים, אבל עדיין זול בהרבה בהשוואה ל-Tesla V100 (שאותו בין כה לא תוכלו להכניס לרוב השרתים). עם כרטיס כזה, אני יכול להבטיח לכם שהביצועים שלו יהיו גבוהים בהרבה מכל Instance עם GPU שתרימו בענן. (ניתן כמובן להרים מס' מכונות VM בשרתים מקומיים ולכל מכונה להצמיד GPU כזה בשיטת GPU Passthrough, כדאי לשאול את יצרן השרת לגבי התמיכה ב-Passthrough ולגבי IOMMU).

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

השלב השני לעומת זאת, עדיף לבצע אותו בענן, מכיוון שהתהליך ה-Evaluation של המידע שנכנס מהלקוח הוא הרבה יותר קצר ולכן גם חלק מ-GPU יכול להספיק לכך, מה עוד שבענן הרבה יותר קל לעשות Scale Out ולשרת בכך יותר ויותר לקוחות.

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

עדכון 17/12/17: קיבלתי פניה לגבי מידע שגוי שאני מפרסם בפוסט זה ולכן אני רואה צורך להבהיר: אינני אומר ששום ענן ציבורי לא נותן תשתית מואצת GPU (במקרה של אמזון ומיקרוסופט – Tesla ובמקרה של גוגל – TPU). כולם נותנים שרות SAAS כזה או אחר ל-ML/DL מואצים, אבל זהו שרות SAAS. למי שמחפש פתרון VM או קונטיינרים נטו שבהם הוא יכול להשתמש בפשטות ב-tensorflow-gpu עם PIP ועם הקוד שלו – זה כרגע למיטב ידיעתי והבנתי – לא קיים.