חומרה – עמוד 7 – הבלוג של חץ ביז

שינויים בעולם ה-IT בחברות

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

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

יחד עם זאת, יצא לי בכמה פעמים לשוחח עם מספר מנמר"ים, CTO ומנהלי מחלקות IT. השיחה בד"כ נסובה על דברים שהם מחפשים במועמד הבא לאייש משרה בתחום ה-IT, ושמתי לב לכמה דברים מעניינים שאני רוצה לשתף עמכם:

הדרישות גדלו: אם פעם היו מחפשים אצל המועמד ידע ב-Windows, ידע התחלתי-בינוני בלינוקס, ידע ב-VMWare ואולי קצת ידע ב-Networking, הפעם רוצים שהמועמד יהיה בעל נסיון בתחומים שהם אינם IT כל כך: תדע Jenkins, GitLab, Code bucket – ולא מדובר על ידע של התקנת הכלי (כמה זמן לוקח להתקין Jenkins? דקות ספורות, לא כולל plugins שאינם רשמיים וכו') – אלא גם כתיבת Pipelines, ידע בניהול גרסאות ב-GIT, ידע ב-Docker, ידע ב-Kubernetes, ידע בהגדרות עננים ציבוריים (AWS, Azure ולפעמים גם GCP). לא שמעתי על הרבה שרוצים ידע ב-Terraform אבל אני מניח שאת זה הם משאירים לאיש DEVOPS (כן, Devops זה מתודות, אבל לך תתקן אנשים).
משכורות – אתה הולך לרכוש דירה? הולך להרחיב את המשפחה? הולכת להיות לך הוצאה גדולה? כדאי שתעזוב את תחום ה-IT לטובת תחומים אחרים יותר רווחיים. המספרים ששמעתי נעים בין 13-20K ברוטו. טוב לצעירים, פחות טוב לנשואים, אבות לילדים וכו' וכו'.
Kubernetes, Helm, Terraform, Ansible, AWS, Azure – ורצוי גם ידע ב-Python, אלו הדרישות שדורשים מאנשי Devops, חוץ מידע בכלי CI/CD. שימו לב: בסטארטאפים מצפים מכם שתלמדו הרבה יותר ממה שציינתי – ומהר. כלי נוסף שחברות עדיין לא ממש גילו ויש מצב שירצו להריץ אותו – נקרא KOPS. ממליץ לכם להכיר אותו.
שכר לאנשי Devops: משום מה במקומות רבים חושבים שהשכר של איש Devops אמור להיות שכר כמו של איש IT. עצתי לכם: תדעו למכור את עצמכם ולהתמקח. עם כל הכבוד לתחום ה-IT, איש Devops צריך לדעת הרבה יותר וללמוד מהר דברים חדשים, התחום מתקדם במהירות מטורפת!
אל "תינעלו" על ענן ציבורי מסוים! ידוע לי שבחברות גדולות רבות פשוט "מתים" על Azure, אבל בשוק יש המון חברות (ובמיוחד סטארטאפים) שמשתמשים ב-AWS ו-GCP ועדיף לכם להכיר את כולם. כל ספקי הענן הציבורי מציעים כמות קרדיטים חינמית בתור התחלה אבל זה לא תמיד מספיק (תזכרו: הקרדיטים הראשוניים הם לזמן קצוב בלבד של חצי שנה או שנה). לכן אני ממליץ: תתנחמדו לאנשי מכירות של ספקי הענן הציבורי ותבקשו בנימוס קרדיטים. טיפ קטן: אני ממליץ ללמוד את הנושאים דרך Linux Academy (למרות השם שלהם, הם מלמדים גם על דברים שאינם לינוקס) ולהשתמש ב-Lab שלהם, אתם תקבלו מספר מכונות וירטואליות חינמיות שפועלות במשך זמן קצוב.
קראו בין השורות לגבי משרות. בלא מעט מקרים באתרים כמו Alljobs ניתן לקרוא את המפרט של נושאים שהחברה רוצה שהמועמד ידע ויכיר, אבל לפעמים אפשר לראות שהחברה בעצם מחפשת איש Devops שיהיה גם איש IT ואם אפשר – שיכין קפה לפעמים. ממשרות כאלו אין הרבה לאן להתקדם, חפשו דברים שמתאימים לכם, לא להיות כלבויניקים.
הנה משהו מעניין ששמעתי ולא מאדם אחד: אין לכם נסיון (חוץ ממה שהתנסיתם בבית)? אל תבקשו לעבוד בחינם. אתם יכולים לדבר על משכורת התחלתית כלשהי שתעלה לאחר תקופה מסויימת/דיון שכר וכו' – והכי חשוב, להיות כן: אם אין לך נסיון מספק, תאמר זאת ותאמר שאתה מוכן בשביל זה להסתפק במשכורת כלשהי (עדיף לא לציין מספר). תנסו לתחמן, יש סיכוי גדול שיתפסו זאת ולא יזמנו אתכם להמשך תהליך.

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

כמה מילים על ענני צעצוע

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

חלפו מספר שנים מאז אותה תקופה, והתחרות נהייתה הרבה יותר רצינית – מחו"ל. חברות כמו Linode, Digital Ocean ואחרות הציעו חבילות במחיר מפתה ולשוק הזה נכנסה בשנים האחרונות אמזון עם חבילות Lightsail שהוצעו במחירים המתחרים באותם ספקי Hosting. כאן בישראל לעומת זאת, נסגרו מספר ספקי Hosting ונכנסו ספקים גדולים – רוב ספקי התקשורת וה-Hosting הגדולים בארץ – שהחלו להציע "ענן" ללקוחות פרטיים ועסקים. במקביל, בשנתיים האחרונות ספקי CDN החלו "לגלות" את ישראל והם הקימו כאן נקודות Edge כך שלקוחות ישראלים יוכלו להנות ממהירות גלישה מקומית (לאתרים שמשתמשים באותן רשתות CDN).

בעסקים כמו בעסקים, אף חברה לא תציע שרותי ענן אם אין לה הכנסות כמו שהיא מצפה או שפתרון ענן לא נותן לה את מה שהיא מצפה (לדוגמא: "ענן" כ-Loss leader כשהכסף הרציני מגיע מהשכרת שרותים שהחברה מספקת לאותם לקוחות ענן). איך חברות עננים מקומיות מרוויחות מהשכרת מכונות VM? פשוט: חוסר ידע של לקוחות. מישהו מקצועי שמבין טוב בלינוקס לדוגמא שיודע להריץ מספר אפליקציות Benchmark, היה מסתכל על המספרים ומיד מבטל את העיסקה תוך שעה-שעתיים, אך מכיוון ש-99% מאותם לקוחות לא מבינים איך אפילו להריץ Benchmark, הם שוכרים תוך מחשבה שהם מקבלים יתרונות של ענן כמו משאבים חזקים, שרידות, גדילה וכו'.

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

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

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

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

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

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

פרויקט נימבוס – מחשוב הענן הממשלתי

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

anan

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

אחד הדברים הבולטים לטובה במסמך הוא התייחסות למחשוב ענן כמו שספקי הענן הציבורי מציגים ומוכרים ולא כל מיני "ענני צעצוע" שכל מיני חברות בארץ מציעות/מוכרות. התנאים עצמם ישר פוסלים את אותם "ענני צעצוע" בכך שיש דרישות שלספקים בארץ אין אותם, הן מבחינת הכנסות והן מבחינת Availability Zones (שמשום מה במסמך הם נקראים "Domains"), מיקומים גיאוגרפים וכו' ואף אחד מהספקים בארץ גם לא מציע 500+ שרותים שונים באותו ענן.
אני שמח לראות שבמשרד האוצר מחפשים שהזוכה יקים בעצם Region אחד ובתוכו Availability Zones אולם לעניות דעתי, חשוב שבמשרד יתעקשו על כך שה-AZ יהיו במרחק רב אחד מהשני.
נקודה שלדעתי חסרה במסמך וחשוב שתצוין (ושהמשרד יעמוד על כך) – שה-AZ יהיה מחובר בחיבורי תקשורת מספקי אינטרנט שונים ולא מספק יחיד. רק לפני חודשים ספורים אלפי אתרים נותקו מהאינטרנט עקב "תקלת תקשורת" של ספק אינטרנט מרכזי. האם משרד האוצר רוצה לחוות חוויה כזו?
אם המתמודדים הם בעצם ספקי הענן הציבורי, מומלץ לבקש לדעתי במסמכי המכרז כי הספק הזוכה ייבא וישתמש בציוד שלהם ולא בציוד COTS. הציוד של ספקי הענן שונה לחלוטין מציוד שחברות רוכשות החל ברמת המעבדים, זכרונות, לוחות, אחסון, תשתיות תקשורת וכו' ויש סיבה טובה לכך – ביצועים הרבה יותר גבוהים.
בבקשה, בבקשה – בלי Azure Stack. כתבתי כאן מדוע לא.
נקודה נוספת שאולי כדאי שמשרד האוצר יחשוב לגביה – שה-AZ יהיו מחוץ ל-Data Centers של ספקי האינטרנט שונים במיקומים כמו הגליל ובאר שבע לדוגמא. בחירה במקומות כאלו יכולה לייצר באופן ישיר מספר מקומות עבודה ובאופן עקיף לאורך זמן – יותר ויותר חברות שיעבדו במקומות אלו.

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

מיקרוסופט – Azure
אמזון – AWS
גוגל – GCP
אורקל – Oracle Cloud
IBM Cloud

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

יש משהו אחד שקצת לא מסתדר לי עם המכרז והפרויקט עצמו. כן, זה בהחלט דבר טוב שמשרד האוצר עושה צעדים להקים פה Region, אבל הבעיה הגדולה ביותר קשורה לשיטות העבודה והפיתוח במשרדי הממשלה השונים ושוחחתי בעבר עם לא מעט עובדים במשרדים הממשלתיים על כך: צריך לשנות מקצה לקצה את כל מתודות העבודה. להתחיל לעבוד מול GIT, לשלב CI/CD, אוטומציה, להוריד כמה שיותר את העבודה עם מכונות וירטואליות ולהתחיל לעבוד מול קונטיינרים ומול שרות/פלטפורמה כמו Kubernetes/OpenShift, לעבוד במתודה של Scale Out, להשתמש ב-Object Storage, להתחיל לעבוד במתודות Serverless אולי, ועוד ועוד – וכל אלו הם דברים שונים ממה שהמשרדים משתמשים כיום. אם משרד האוצר הולך לשלם על Region עם מספר AZ ושיטות העבודה ישארו השיטות הישנות, אז ניצול ה-Region יהיה אחוזים בודדים בלבד, ובכך יווצר בזבוז כספים משווע (ומה לעשות, לא מדובר פה בתשלום חד פעמי אלא חודשי), ולכן אני תוהה אם משרד האוצר מוכן כבר עכשיו לתכנן מהלך הדרגתי לעבור למתודות העבודה החדשות.

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

מעבדי EPYC דור שני – סקירה

אני רוצה לפתוח את הפוסט עם סיפור קצר "מאחורי הקלעים".

תכננתי זמן רב לכתוב את הפוסט הזה ולשחרר אותו היום (לאחר שהסתיים האמברגו אתמול) על המעבדים החדשים של AMD לשרתים, מעבדי EPYC דור שני (סידרה 7002) ולהשוות אותם למעבדים הנוכחיים של אינטל שמגיעים עם עד 56 ליבות במעבד. מהנדסי אינטל עשו עבודה מצויינת והמעבדים עם 40 או 56 ליבות יכולים לתת "פייט" מצוין למעבדי EPYC דור שני של AMD, אבל קרה מה שקורה לפעמים בחברות גדולות – בהנהלה באינטל "נפתח התאבון" והם החליטו שמעבדים בסידרה 92XX יהיו שונים פיזית ממעבדי Xeon Scalable האחרים. אם תיקחו מעבד כזה ותהפכו אותו, לא תמצאו פינים או ריבועי זהב קטנטנים. אתם תמצאו כדורים או מה שנקרא בשפה המקצועית BGA (כלומר Ball Grid Array), ובמילים אחרות – המעבדים הללו חייבים להיות מולחמים ללוח אם. בנוסף, אינטל החליטו שיצרן המעוניין לרכוש מעבדים כאלו ומעוניין לשלב אותם בשרתים – יצטרך גם לרכוש מאינטל עוד כמה שבבים והם מחוייבים להיות מוטמעים בשרתים ומה לעשות – אותם שבבים מתחרים בדיוק במה שהיצרנים מוכרים מבחינת ניהול – iDrac, iLO וכו'.

כך שכיום – גם אם יש לכם כסף, מערכות X86 הכוללים מעבדים עם יותר מ-28 ליבות – לא תוכלו לרכוש כי אף יצרן לא מוכן לתנאים הללו. באינטל הבינו את השגיאה הפטאלית רק לפני מס' חודשים והיא תתוקן ב-2020 עם המשפחה החדשה Ice Lake AP.

בקיצור – AMD צריכים לשלוח פרחים ואולי עוגה עם שלט גדול של "תודה" לאינטל.

המעבדים החדשים של AMD – סידרה 7002 הם מעבדים שרבים מאוד בתעשיות השונות חיכו להם. מעבדי EPYC דור ראשון (סידרה 7001) היוו כניסה מחדש של AMD לתחום השרתים לאחר ש-AMD שחררה לפני יותר מעשור את מעבדי ה-Opteron שהיו מאכזבים בכל תחום למעט המחיר ואינטל לא היו צריכים להתאמץ יותר מדי בכדי לכבוש 99% מהשוק מאז 2006. ל-AMD לא היו שום פתרונות עם שהם פיתחו את ארכיטקטורת ZEN וגם כש-AMD הוציאו את ה-EPYC דור ראשון, לאותם מעבדים היה יתרון בהרצת מכונות וירטואליות, פתרונות VDI וקונטיינרים, אבל כשזה מגיע להרצת אפליקציות גדולות ופלטפורמות פיתוח על כל המעבדים בשרת (ללא וירטואליזציה) – אינטל ניצחה מבחינת ביצועים כמעט בכל קטגוריה.

בדור שני של ארכיטקטורת ZEN, ה-ZEN-2, הפיקו ב-AMD לקחים רבים ובאותה הזדמנות החליטו לשנות הכל. ה-EPYC סידרה 7002 זו ארכיטקטורה שונה לחלוטין מהדור הראשון, לא רק בתוספות ש-AMD הוסיפו, אלא גם בתכנון עצמו. בדור הראשון של EPYC היו בעצם 4 מעבדים שיצרו תצורת NUMA שהצריכו הגדרות וכיוונונים שונים על מנת לקבל ביצועים טובים וגם אז – היה Latency לא קטן עקב התצורה. בדור השני לעומת זאת, ישנו Chiplet מרכזי גדול (כפי שאתם יכולים לראות בתמונה לעיל) שאחראי לכל ה-I/O וכל שבבי הליבות "מדברים" דרכו בלבד, מה שחוסך בצורה ניכרת את ה-Latency. ככלל, תצורת המעבדים הללו (כמו גם מעבדי ה-Ryzen ש-AMD שחררו ומעבדי ה-Threadripper שישוחררו כנראה בחודש הבא) היא תצורה חדשה ושונה לחלוטין ממה שאינטל מתכננים ומייצרים מעבדים – וזה גם הכיוון שאינטל יעברו אליו במהלך השנה שנתיים הקרובות. חברה קטנה כמו AMD מקדימה את אינטל הענקית. כמה מרענן לראות זאת.

כפי שכתבתי, יצרניות רבות של שרתים, ספקי הענן הציבורי, יצרנים תעשייתיים של ציוד לשרתים וכו' חיכו ל-EPYC החדש מהסיבה הפשוטה שסוף סוף אפשר להתחיל מאפס עם טכנולוגיות יותר מתקדמות ממה שאינטל מציעה. עם 128 נתיבי PCIe אפשר לבנות דברים מדהימים ללא צורך ברכיבי מיתוג סופר-יקרים ליצרן (שמגלגל זאת כמובן ללקוח הסופי), אפשר להשתמש בזכרון יותר מהיר (3200 מגהרץ), אפשר לקבל תקשורת יותר מהירה כי כמעט כל תושבות ה-PCIe הם PCIe 4.0 עם רוחב פס של 16 ג'יגהבייט לשניה (כפול מ-PCIe 3.0), אפשר להכניס הרבה יותר דיסקים SSD NVME (לנובו בהחלט "משתוללים" בקטע הזה עם השרתים מבוססי EPYC שהם מציעים החל משבוע הבא. צפו בוידאו הזה), יש מעבדים עם עד 64 ליבות, יש זכרון מסמון בגודל 256 מגהבייט, ועוד ועוד. מי שרוצה את "רשימת המכולת" מוזמן לעיין בפוסט הארוך ש-STH שחררו כאן.

להלן טבלה שמראה את ההבדלים בין הדור השני של Xeon Scalable מבית אינטל ל-EPYC דור שני מבית AMD:

אחת השאלות שכמובן מיד עולה היא: איך הביצועים? וכאן AMD מפתיעה. ברוב מוחלט של המבחנים מעבדי ה-EPYC פשוט עוקפים את המעבדים בקצה הגבוה (28 ליבות) של אינטל עם 50-90% ביצועים יותר מהירים, גם כשלאינטל יש יתרון כמו AVX512 – מעבדי EPYC עוקפים זאת (ע"י שימוש ברוחב פס כפול לתעבורת פקודות) ובמילים אחרים – לא חשוב מה ה-Work Load שאתה צריך להריץ, אם אתה חושב לרכוש ברזלים חדשים או לקחת Instances אצל ספק ענן ציבורי – כדאי מאוד להסתכל על מכונות המכילות את מעבדי EPYC החדשים. אגב, מיקרוסופט וגוגל הכריזו כי ניתן כבר מהיום לשכור Instances מבוססי EPYC דור שני. באמזון אם הבנתי נכון, זה יוצע בחודש הבא.

ומה בנוגע למחיר?

ובכן, בקצה הגבוה של מעבדי אינטל מהסידרה 9200 (כן, אלו שאי אפשר לרכוש כרגע מהיצרנים הפופולריים) אינטל דורשת לבלב, ריאה או משכנתא קטנה. מעבד בקצה הכי גבוה – Xeon 9282 עם 56 ליבות, מתחיל במחיר של $25000 (המחיר כמובן הוא לא מחיר ללקוח סופי, אלא ליצרן שרתים, אז המספר יעלה). לעומת זאת, המעבד בקצה הכי גבוה של AMD, ה-EPYC 7742 עם 64 ליבות עולה פחות משליש – ב-AMD מסתפקים ב-$6950.

ככלל, המשוואה ש-AMD מציעה היא פשוטה: תחליט כמה ליבות פר מעבד אתה צריך במעבדים של המתחרים. יש לך מספר? יפה. תוסיף בערך 100-150$ ותקבל כמות ליבות כפולה ובאותה הזדמנות יש מצב שלא תצטרך שרת עם 2 מעבדים אם אתה רוכש מעבד מבוסס EPYC דור שני.

יתרון גדול נוסף ללקוח הסופי הוא מבחינת רישוי. AMD מציעה לך מעבדים עם עד 64 ליבות ואם אתה משתמש בוירטואליזציה של VMWare, אז אתה חוסך 50% פר שרת במחיר הרישוי.

מבחינת זמינות שרתים לרכישה, אלו השרתים הזמינים כיום ובקרוב. חשוב לשים לב אלו מעבדים אתם בוחרים, המעבדים החדשים מתחילים במספר 77 ומסתיימים ב-2. לדוגמא: 7742.

HPE – מציעים את ה-DL325, DL385 ו-Apollo 35. את השרתים הללו ניתן לרכוש כבר כיום עם מעבדי EPYC דור ראשון או שני (יש תאימות אחורה). HPE הכריזו כי במהלך 2019-2020 הם יוציאו עוד 9 דגמים של שרתים מבוססי EPYC דור שני. השרתים המוצעים כיום הם עם PCIe 3.0 ולא עם PCIe 4.0.
DELL מציעים את שרתי R7425, R7415, R6415. את כל השרתים הללו ניתן לרכוש עם מעבדים דור קודם או נוכחי. בחודש ספטמבר DELL יציגו שרתים חדשים ובמהלך השנה הבאה יוצגו עוד 6 שרתים מבוססי EPYC דור שני.
LENOVO מציעים את SR635 ו-SR655. לנובו הם היחידים שמציעים החל משבוע הבא שרתים עם לוח אם שתוכנן מאפס למעבדי דור EPYC דור שני. גם לנובו יציעו החל מתחילת הבאה עוד מספר דגמי שרתים מבוססי EPYC דור שני.
Supermicro – החברה מציעה כרגע 4 שרתים דור 12 (H12) שניתן לראות כאן (נכון לכתיבת שורות אלו יש להם כמה בעיות באתר) כאשר Supermicro דוחפת יותר לכיוון ה-Twin (כלומר 2 שרתים במארז 2U).
Gigabyte – החברה החליטה להוציא לא פחות מ-13 שרתים מבוססי EPYC דור שני (די מדהים, בהתחשב שבדור הקודם של EPYC היו לחברה .. רק 2 שרתים להציע). אתם יכולים לראות את הרשימה כולה כאן.
TYAN (יש להם נציג בארץ?) – מציגים 6 שרתים ו-2 לוחות אם (לבנייה ואינטגרציה). הרשימה – כאן.
ASUS – בעת כתיבת שורות אלו, החברה הכריזה על שרתים חדשים (E10) ולוחות אם מבוססי EPYC דור שני. האתר עצמו עדיין לא מכיל את רשימת השרתים, סביר להניח שזה יעודכן היום או מחר.

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

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

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

הראשון – מבחן ביצועים VMMark של VMWare:

השני – קונטיינרים (מבוססי Docker):

קצת על שדרוג מכונות תעשיתיות

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

אבל כשזה מגיע למכונות יצור, לא מומלץ ממש לבצע את הדברים לעיל.

בין אם מדובר במחשב שנמצא במפעל שמפעיל רובוט/ים, בין אם מדובר בכספומט ובין אם מדובר בכל מערכת סגורה ללקוח שרכש את המערכת – אותו מחשב לא נבנה עבור שדרוג. אני לא מכיר שום יצרן מכונות שיענה לך במייל "סבבה, שדרג ל-Windows 10, אין בעיה" וזאת מהסיבה הפשוטה שברוב מוחלט של המקרים, מותקנות במערכת ההפעלה שבמחשב מספר אפליקציות ומספר דרייברים (תלוי בציוד שאליו מחובר המחשב) שניבנו עבור אותה מערכת הפעלה ישנה ומה שהותקן כלל לא נוסה על מערכת הפעלה חדשה. יותר מכך, במקרים רבים הדרייברים של הציודים המחוברים במחשב לא יעבדו ב-Windows 10 (תצורת הדרייברים שונה מהותית בין Windows XP/7 לבין WIndows 8/10).

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

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

הרצה של המערכת הישנה כ-VM בתוך המחשב התעשייתי שיריץ Windows 10: רעיון נחמד אבל בעייתי במיוחד אם המחשב מחובר עם כרטיסים שונים לרובוטים. מה לעשות, Windows לא מאפשר מיפוי של כרטיסים אל מערכת הפעלה וירטואלית (תאשימו את מיקרוסופט, בלינוקס זה דווקא עובד) וגם אם תנסו להתקין לינוקס עם VM של מערכת ההפעלה החדשה, זה לא אומר שזה יעבוד כי מעבדים ישנים אינם כוללים תמיכה של VT-D, מה שאומר שברגע שתפעילו את ה-VM, המכונה הפיזית תאפס את עצמה (אין תקשורת DMA טובה).
התקנה של Windows 10 והרצה במצב Compatibility: גם זה רעיון נחמד, אבל לא בטוח שהציוד במחשב נתמך בכלל ב-Windows 10 (נסו את זה עם כרטיסי MOXA ישנים לדוגמא או עם כרטיסי FPGA מלפני 2005, ותקללו כל רגע שהחלטתם להכניס את הראש לצרה הזו), מה גם שבאותו רגע שתעשו זאת – יש מצב שאתם מבטלים את חוזה האחריות והתמיכה מצד היצרן.
העברת כרטיסים מהמחשב שהוא חלק ממכונת היצור לשרת והרצת VM תחת ESXI: גם זה רעיון נחמד, אבל ברגע שתפעילו את ה-VM, יש מצב שהשרת או יתקע או יתאפס לגמרי (הכרטיסים לא יודעים לתמוך ב-IOMMU ומכיוון ש-VM מנסה לאפס את הכרטיס ב-Boot, הכרטיס או יסרב ואז יכול להתבצע Reset או פשוט להתקע).

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

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

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

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

על שני פרויקטים מוצלחים – ולקחים

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

באותם פרויקטים שהקמתי, היו מספר רב של שרתים שהריצו מערכת DB שהיא Scale Out ובחלק מהשרתים רצות אפליקציות שונות שמשתמשות ב-DB כדי להעביר פנימה והחוצה נתונים לשם ניתוח. בנוסף רצו מכונות VM שונות לתשתית שנתנו שרותים שונים על מערכות הפעלה שונות.

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

מיישם הפרויקט – צריך להשתתף בפרויקט עוד בשלבים המוקדמים: במקרים רבים מתבצעת התקשרות עם איש מקצוע להקמת תשתית/פתרון אחרי שנבחרה חומרה שתריץ את הדברים. ההחלטות לגבי החומרה מתקבלות ע"י האיש המקצועי בחברה או שמוגשות המלצות ע"י אנשי השיווק של יצרן החומרה ואז אחד הקודקודים בחברה מחליט אם לרכוש או לא ומה לשנות (פקטור של מחיר וכו'). אני מבין את התהליך, אולם לעיתים יש דברים שניתן לשנות מבלי להרים את תקרת המחיר – שנותנים ביצועים יותר גבוהים או שרידות גבוהה, ולכן כדאי לשכור את האיש מקצוע לפני קבלת ההחלטות לגבי הברזלים.
תוכנות בקוד פתוח מסחרי או רגיל: אחת הנקודות שחשוב לתת עליה את הדעת עוד בשלב החישובים הכספיים, היא ההחלטה אם במערכת החדשה יוטמע פתרון מבוסס קוד פתוח חינמי שמורידים מהאינטרנט, או שרוכשים פתרון קוד פתוח עם תמיכה מסחרית מיצרן התוכנה. דוגמאות לכך לא חסר: OpenStack, Ceph, GlusterFS, RHV ועוד ועוד. אפשר כמובן להוריד מהאינטרנט ולהתקין בלי לשלם שקל, אולם מה קורה כאשר המערכת הזו תהיה פרודקשן ויש תקלה באפליקציה המרכזית? במקרים כמו OpenStack או Ceph לדוגמא, כמות האנשים בארץ שיכולים "לחטט" בקוד ולתקן באגים מאוד קטנה וללא תמיכה מסחרית רשמית – מערכת פרודקשן כזו יכולה להיות מושבתת למשך ימים, ולכן אם מדובר במערכת פרודקשן שתיצור הכנסות – מומלץ לבחור בדרך המסחרית. זה יותר יקר מבחינה כספית – אבל זה נותן שקט ומענה לבעיות בטווח הארוך.
כמה שפחות תלויות: לא משנה מי הפרילאנסר או החברה שמקימה עבורכם את הפתרון, חשוב לכלול כמות שעות מסויימת שתוקדש לתיעוד והדרכה של הצוות בחברה, ובמיוחד Troubleshooting. אם לדוגמא המערכת מנותקת מהאינטרנט ויש תקלה, הצוות בחברה (בהינתן הידע) יכול לטפל בתקלה הרבה יותר מהר מאשר פתיחת טיקט, המתנה, ולאחר מכן עבודה בשיטה של copy/paste מהטיקט למכונות.
חיבור אינטרנט למערכת: לא מעט לקוחות מבקשים להקים מערכת שבמצב פרודקשן תהיה מנותקת לחלוטין מהאינטרנט. זהו דבר מובן ומקובל, אבל עדיין חשוב לבנות חיבור אינטרנט (ישיר או עקיף, ע"י הקמת Proxy או VPN לדוגמא) לעדכונים ותיקונים חשובים. ראיתי לא מעט מקרים בהם אנשים הורידו קבצי RPM וחשבו שהם יוכלו להתקין אותם ישירות בפרודקשן מדיסק און קי, ואז הם ראו דרישה מהמערכת לערימת קבצי RPM נוספים כתלויות. על מנת לאבטח את המערכת, חיבור כזה צריך להיות מופעל ידנית כמובן כך שלא ניתן להיכנס אוטומטית מרחוק.
דאגו ל-Gateway: נניח שיש לי 50 שרתים, כולם תחת אותו Class של כתובות (נניח 24/). מטבע הדברים יספיק שרת DNS פנימי פשוט כדי שהמכונות יכולות לשוחח בינן לבין עצמן ואין צורך בשום Gateway, אבל הבעיה מתחילה בכך שאם נניח מכונות 3,8,10,14,30 צריכות עכשיו להתחבר לאינטרנט להוריד דברים מסוימים (ואין Proxy), בלי Gateway זה יהיה בעייתי, ולכן מומלץ שאפילו ה-Switch המקומי ישמש כ-Gateway מקומי.
לוח זמנים – בחיים ניתן לשלוט על דברים רבים, אך יש דברים שאין עליהם שליטה. פרויקט אמור להימסר ללקוח בעוד חודשיים אך עדין לא מצאו איש מקצוע בתחום מסוים. יש צורך בהחלפת רכיב מסוים בכל השרתים. יש צורך בשינוי דחוף בארכיטקטורה. הלקוח לא מרוצה מהביצועים – קחו טווח זמן יותר ארוך ממה שאתם חושבים שתצטרכו.

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

האם ה-Nvidia Grid עדיין רלוונטי?

כל מי שמתכנן וכל מי שהתחיל לעבוד עם מכונות וירטואליות בתצורת VDI בוודאי שמע ומכיר את ה-Grid של nvidia. פתרון ה-Grid מבוסס על מספר חלקים כמו ה-GPU, שרת רשיונות וכמובן חלקים נוספים הקשורים לפתרון ה-VDI עצמו בשרת וב-Client.

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

הבעיה קשורה יותר לכסף. בעבר הרחוק היית רוכש את פתרון התוכנה, את כרטיסי ה-GPU, מגדיר את הדברים ומתחיל לתת לעובדים שלך לעבוד, אבל כיום הדברים כרוכים בתשלום חודשי, והדברים מגיעים לכך שבחישובים של תשלום ל-3 שנים לדוגמא, עדיף לרכוש את הפתרונות של AMD המתחרה. שם אין תשלום חודשי והביצועים אינם פוחתים בהשוואה למה ש-nvidia נותנת, כולל פתרונות הדורשים OpenGL או DirectX 11/12 לעבודה, ויש תמיכה מלאה בפרוטוקולי Client של VMWare, של Citrix ושל מיקרוסופט.

אחד הנושאים שעולים לאחרונה בכל הקשור ל-Virtual GPU/Grid ותמיכה – קשור ל-AI ו-Deep learning. יותר ויותר חברות גדולות מגלות פלטפורמות כמו Tensor Flow או Caffe ומעוניינים לרתום את תשתית ה-Grid שלהם לשימוש עם אותם פלטפורמות.

טכנית – זה בחלט אפשרי. אם לדוגמא עובדים עם CUDA – אז אין שום בעיה להריץ/לאמן/לקמפל קוד גם על מעבד גרפי סופר פשוט שקיים במחשב נייד, ובוודאי שעל Virtual GPU אם הוא קיים על מכונות וירטואליות. האם זה יעבוד? כן.

אבל מבחינת ביצועים – כל כרטיסי ה-GPU מסידרה K,M,P במשפחת ה-GRID או Tesla או Quadro לא יתנו ביצועים גבוהים, במיוחד אם משתמשים בכרטיסים אלו לצרכי VDI – או אז במקרים כאלו המכונה מקבלת רק חלק קטן מה-GPU והביצועים .. בהתאם. כרטיסי Tesla או Quadro מסידרה V או T הרבה יותר מתאימים ליישומים אלו, אולם אם מדובר בכמות עבודה רצינית שאינה חד פעמית, אני ממליץ לנטוש מערכת GRID ולרכוש שרתים שיכולים להכיל מספר כרטיסי GPU ואז למפות מספר כרטיסים למכונה וירטואלית או מיפוי 1:1 בין GPU למכונה וירטואלית. יש כמובן גם אפשרות לרכוש כרטיסי RTX אולם כרטיסים אלו אינם מתאימים כל כך לשרתים הואיל והאיוורור שלהם הוא מהצד (Blower) ובמקרים רבים השרתים אינם בנויים לאיוורור כרטיסי GPU מהצד אלא מאחור.

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

לסיכום: אם אצלכם בחברה חושבים להשתמש/לפתח בתחומי ה-AI או ה-Deep Learning, כדאי לחשוב על הנקודות שצוינו בפוסט זה. פתרונות ישנים לא תמיד מתאימים ולמרות הפתרונות של Nvidia – היא אינה השחקן היחיד בשוק ואין צורך לוותר על תאימות פלטפורמות כדי לעבוד לכרטיסי GPU אחרים או ל-OpenCL.

עמדה: מחשבי מק ושימושיות בחברות

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

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

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

כשזה מגיע למחשבי דסקטופ, יש לאפל מחשב 2 מחשבים (ה-iMac ו-iMac Pro) שניתנים לשדרוג הן מבחינת זכרון, מעבד, ואחסון. במחשבים אלו האחסון שליף כך שבמקרה ומחשב צריך החלפה של לוח אם לדוגמא, אין שום בעיה להוציא את זוג ה-SSD הקנייני שבמחשב ולהחליף לוח אם, ומחשבים אלו לעניות דעתי מומלצים יותר לרכישה מאשר אחיהם הלאפטופים הואיל וניתן בכל זמן לשדרג אותם. לאפל יש גם את ה-Mac Mini אך למעט הזכרון לא ניתן לשדרג מאומה, כך שכמו אחיו הלאפטופים, אם ישנה בעיה באחסון, יש צורך בהחלפה של כל לוח האם כולל הבעיה של המידע שקיים במחשב. אפל בחורף תוציא את ה-Mac Pro שיהיה אחד המחשבים היחידים של אפל שבו ניתן יהיה לשדרג סוף סוף הכל, כולל הכנסת כרטיסי PCIe של חברות שונות.

אחת התהיות שעולות עקב "לחץ מלמטה" היא התהיה האם כדאי להחליף את שלל המחשבים הניידים בחברה למחשבי Macbook Air או Macbook Pro. מבחינת ניהול מרכזי, קיימים מספר כלים לנהל מחשבים אלו יחד עם מחשבי PC אחרים בצורה מרוכזת, ומבחינת מערכת הפעלה Mac OS היא מערכת הפעלה מעולה ויציבה (לא רק עבור גרפיקאים ואנשי מדיה אלא גם למפתחים), אולם חשוב לזכור כי הבעיה המרכזית היא שכל מחשב נייד ל-Enterprise שתעמיד למבחן מול כל מחשב נייד של אפל – המחשב הנייד שאינו מחברת אפל יוכל להיות משודרג הן מבחינת זכרון והן מבחינת אחסון, וזהו יתרון ענק כאשר מסתכלים לטווח של שנה שנתיים לאחר רכישה שבהן עולות דרישות של יותר זכרון ויותר שטח אחסון. אחרי הכל, אף אחד לא רוצה לגרור את עצמו עם מחשב נייד ועם SSD חיצוני לכל מקום כי נגמר המקום בדיסק SSD הפנימי..

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

תכירו את rCUDA

כל מי שעובד/מפתח AI, או Deep Learning או מבצע Training למודלים שונים בתחומים הנ"ל, מכיר את העובדה הפשוטה והידועה: אם אתה רוצה ביצועים, אתה חייב GPU טוב באותה מכונה שאתה מריץ עליה את הקוד. לא חשוב כמה חזק השרת שאתה מריץ עליו את הקוד, אם תריץ את הקוד על ה-CPU – הביצועים יהיו גרועים (אינטל חולקת על כך ומציעה את מעבדי ה-Cascade Lake AP לשם כך, רק שהביצועים של אותם מעבדים בלינוקס נכון להרגע – הם לא משהו לרוץ לספר לחבר'ה. יש טלאי שמתקן זאת שיצא לפני מס' ימים, אבל יקח כמה חודשים עד שהפצות הלינוקס יכניסו אותו ל-Kernel שלהם).

מי שמכיר את עניין ה-Training, מודע בוודאי לסיטואציה שגם אם יש לכם שרת מפלצת עם 4,8 או אפילו 10 כרטיסי GPU – אם הוא עמוס מבחינת עבודה על GPU אבל לא עמוס מבחינת CPU – אתה לא יכול "לגייס" מכונות אחרות שיש להן כרטיסי GPU והן לא עמוסות כרגע.

וכאן מגיעה תוכנת rCUDA לסייע.

תוכנת rCUDA מאפשרת לעשות משהו חדש: לבצע הידור או אימון (Training) במכונה מרוחקת (גם כשהקוד נמצא מקומית) עם כרטיס GPU אחד, עם מספר כרטיסי GPU באותה מכונה, או בשיטת ביזור של ניצול מספר מכונות שיש להן כרטיסי GPU. כך לדוגמא אם יש לך קוד על המכונה שלך ויש 4 שרתים כשבכל אחד מהם יש 2 כרטיסי GPU – תוכל להשתמש בכל ארבעת השרתים לבצע את הקימפול/אימון ללא שינויי קוד. אתה כמובן תוכל להריץ את הקוד או את האימון גם אם ישנם דגמים שונים של כרטיסי GPU (כל עוד מדובר בכרטיסים של nVidia מהדורות האחרונים – Pascal ומעלה).

השיטה שבה rCUDA עובדת היא שיטת Client/Server: בכל מכונה שיש בה כרטיסי GPU רץ Daemon שמקבל את הנתונים מהמכונות המרוחקות ומזין אותו אל ה-GPU פנימה והחוצה דרך הרשת, כך שבמקום המצב הרגיל שכל התוכנה נמצאת ב-RAM וקבצי האימון נמצאים על דיסקים מקומיים (לדוגמא) – פה הכל עובר דרך הרשת המקומית וה-Daemon מקבל את המידע דרך הרשת, מזין ל-GPU ומוציא את המידע בחזרה למי ששלח אותו. בצד ה-Client ישנם קבצים בינאריים שדואגים לעניין הקבלה והשליחה, כך שהכל נעשה בצורה שקופה ובד"כ מצריך רק הגדרות של מספר Variables ואפליקציה קטנה ב-Client וב-Server.

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

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

בשביל להריץ את כל הדבר הזה, יש צורך ברשת מהירה. כמה מהירה? לפחות Infiniband או תקשורת Ethernet של 50 ג'יגהביט ומעלה. במידה וכל הקוד רץ על ה-GPU בלבד וכל תוכן ה-Training נמצא ב-NFS/iSCSI לדוגמא – יהיה אפשר לדעתי לרדת לתקשורת במהירות 10 ג'יגהביט, אך תקשורת במהירות 1 ג'יגהביט – תזחל.
מבחינת הרצת קוד – אפשר להריץ קוד שמשתמש ב-CUDA עד גירסה 9.0 (תמיכה לגירסה 10.1 תהיה בתחילת שנה הבאה) ואפשר להשתמש גם ב-CuDNN, TensorFlow, Caffe וכו'.
התוכנה אינה מבוססת קוד פתוח ומה שמקבלים זה קבצים בינאריים בלבד.
בשלב זה התוכנה אינה עולה כסף אך יש צורך בהרשמה על מנת לקבל רשיון. בעתיד, יכול להיות שהתוכנה תעלה כסף.
שינוי שיטת העבודה (ממקומית ל-רשת) יכול לגרום למצב שתצטרכו שדרוג או רכישת סטורג' על מנת לאחסן את כל ה-DATA, הואיל והכל צריך לעבור דרך הרשת, והעברת DATA ל-Training מתחנת עבודה לשרת זה דבר איטי מאוד.
האפליקציה (rCUDA) עם השרותים – רצים רק על לינוקס.

לסיכום: rCUDA יכול לסייע רבות כשרוצים להשתמש במשאבי GPU שונים בצורה מרוכזת, גם כשהם לא נמצאים בשרת פיזי אחד. יחד עם כך, יש צורך להיערך בהתאם ולקחת בחשבון שאין את התמיכה לגירסת CUDA האחרונה ויכול להיות שחלק אחר מהאפליקציות לא יעבדו (כמו שימוש ב-API של הדרייברים של ה-GPU), כך שאם זה מעניין אתכם, מומלץ לעשות PoC לפני שמשקיעים בתשתית.

להלן וידאו עם הדגמה:

כמה מילים על Azure Stack וספקי אינטרנט

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

בישראל החלה חברת Med One להציע שרותים המבוססים על Azure Stack ואני מאמין שהמתחרים בארץ כבר במחשבות או בדרך לרכוש ולהציע את השרותים הללו. חשוב לי להדגיש – הפוסט הזה אינו בא "לקטול" ספק ISP זה או אחר אלא לתת דגש לגבי פתרון Azure Stack (אם יש איזו חברה בארץ שהולכת להכניס את ה-Outposts של אמזון – אשמח אם היא תוכל ליצור עימי קשר).

קצת על Azure Stack: מיקרוסופט פיתחה מערכת שהיא "מיני Azure". מיני בכל מובן: מעט מהשרותים שתמצא בענן של Azure תמצא אותם כאן, התמחור שונה בהשוואה להשכרה קלאסית של מכונות VM/קונטיינרים/אחסון בלוק/אחסון אובייקטים וכמובן – תעבורה. על כל פיפס אתה צריך לשלם – כמו בענן של Azure, גם ב-Azure Stack (כן, גם אם רכשתם בעצמכם את ה-Azure Stack לחברה שלכם, אגב).

מערכת Azure Stack בנויה לשימוש ב-2 אופנים: Connected ו-Disconnected, כאשר ב-Connected אתם יכולים להעביר את התשתית הוירטואלית/מכונות/קונטיינרים/אחסון לענן האמיתי של Azure ובמצב Disconnected – האינטרנט מנותק, והכל רץ מקומית בארונות של ספק ה-Azure Stack שלכם (או אצלכם מקומית אם רכשתם את המערכת).

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

החסרונות של Azure Stack לעומת היתרונות – גדולים:

הסיבה המרכזית שחברות עוברות לענן – זה ה-Scaling שאותו לא מקבלים באותה צורה ובאותו גדול בהשוואה לענן עצמו. כנ"ל לגבי שרידות – לכל ספק ענן ציבורי יש Zones ויש Regions ואפשר להקים שרידות נפלאה. איזו שרידות תקים ב-Azure Stack? בין שרתים שהכל מקומית? אנשים שוכחים בכל פעם את התקלות שיש פה לכל מיני ISP שמשביתות אלפי לקוחות במכה אחת, ובענן ציבורי אפשר לבנות מערכת שגם תעמוד ברעידות אדמה, זה לא כזה מסובך.
ביצועים – עם Azure Stack אנחנו חוזרים שוב למודל ה-Enterprise מבחינת ציוד, וזאת בניגוד מוחלט למה שיש בענן ציבורי: באף ענן ציבורי אין שרתי מותג, אין דיסקים Enterprise, אין מתגים של מותג מסוים – הכל בניה "מקומית", החל מרמת המעבד והזכרון וכלה באוורור, ובעברית: מכונת VM שרצה בענן תרוץ יותר לאט על השרתים הקנייניים שמריצים את Azure Stack כי גם המעבד וגם הזכרון שונים (ספקי ענן רוכשים גרסאות Custom של מעבדים וזכרונות הרבה יותר מהירים ממה שיש בשרתים הרגילים).
מחירים: בניגוד למצב רגיל שאתה לוקח מספק Hosting כלשהו מכונת VM נניח עם 4 ליבות, 8 ג'יגה זכרון, 40 ג'יגה דיסק ותעבורה של 5 מגהביט והכל כלול במחיר אחד – כאן הכל שונה, אתה משלם על כל פיפס בנפרד. נתראה בחשבונית החודשית (וכן – התכוונתי ל-Azure Stack. מיקרוסופט מכתיבה זאת).
שרותים – הבסיסיים נמצאים + עוד כמה שרותים. השאר? עדיין נמצאים רק בענן הציבורי.
תאימות API בין ריצה ב-Azure Stack ל-Azure הרגיל – חלקית בלבד. תצטרכו לעשות לא מעט פליק פלאק כדי להעביר דברים מהענן מקומית וההיפך.

מיקרוסופט מנסה כבר שנתיים למכור את ה-Azure Stack ואין לה הרבה הצלחה עם זה. היא גם מוציאה את Azure Stack HCI שמנסה להתחרות בפתרונות מקומיים (vSAN, Nutantix, Simplivity) שהיתרון היחיד שלו – זה אינטגרציה עם Azure. זה יכול להיות מעניין אולי עבור חלק מהחברות, רק שכדאי לקחת בחשבון שלהגדיר את הדברים שם – אתם תתלשו שערות מהראש.

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