כשצריך תשתית של עננים ציבוריים – מקומית

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

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

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

גם גוגל החלה להציע פתרון משלה לאלו שרוצים תשתית ענן ציבורי אך מקומית ב-DC שלהם, אם כי הוא שונה מהמתחרים. אם אצל המתחרים השלב הראשון הוא רכישת/השכרת ברזלים, בגוגל פשוט ממליצים לך להשתמש בתשתית המקומית שלך או בתשתית הענן הציבורי שלהם או של אחרים ושם המוצר הוא Anthos. עם Anthos הלקוח מקבל את פלטפורמת הקונטיינרים של (Google Cloud (GKE לשימוש מקומי. זה לא בדיוק נשמע משהו מלהיב – אחרי הכל, לרוב החברות יש מאות ואלפי מכונות VM שהם לא רוצים/לא יכולים להמיר לקונטיינרים ולכן גוגל כוללים בחבילה גם את Anthos Migrate שמאפשר לך להעביר מכונות VM (בשלב זה מכונות מבוססות לינוקס בלבד) מ-VM ישירות לקונטיינר, כאשר המערכת של גוגל מנתחת את ה-VM, מקימה קונטיינרים, מזרימה אליהם את המידע ותוך רגעים ספורים אתה יכול להשתמש בקונטיינרים במקום במכונות ה-VM, גם כשהמכונות VM עדיין לא הועברו בשלמותם לפתרון של גוגל.

לגבי שאר ספקי הענן הציבורי:

  • ל-IBM יש Cloud Private שנותן לך בעצם Kubernetes עם שרותים נוספים של IBM שירוצו מקומית.
  • ל-Alibaba, Huawei, Baidu יש גם פתרונות מקומיים אבל אני בספק אם הלקוח הישראלי החשדן יסכים לשכור מהם שרותים שישבו מקומית.
  • Oracle מציעים את Oracle Cloud at customer – שכוללים את "רוב" השרותים שהם מציעים בענן (אחרי שנברתי בערימת מסמכים רוויי Buzzwords – קשה להבין מה הם בדיוק נותנים, מה עוד שהתיעוד שלהם לגבי ספקי ענן מתחרים לוקה בחסר ולכן לא מומלץ לסמוך על התיעוד שלהם).
  • VMware – נכון, VMWare היא אינה ספק ענן ציבורי, אבל עם מוצר כמו Tanzu אתה יכול להרים תשתית קונטיינרים/Kubernetes מקומית (PKS) ובעננים ציבוריים גדולים.

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

פרילאנסר – הממשלה רוצה אותך

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

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

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

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

  • קודם כל – Python ולא Paython.
  • עבודה עם Dot Net: אני ממליץ מאוד למינהל להתחיל בתכנון מעבר מ-Dot Net ל-Dot Net Core מהסיבה הפשוטה שקוד Dot Net Core יכול לרוץ גם על לינוקס, דבר שיעזור מאוד כשהקוד יצטרך לרוץ בענן הממשלתי. Dot Net Core מפותח ע"י מיקרוסופט ומיקרוסופט מספקת גם תיעוד כיצד לעבור מסביבה אחת לשניה.
  • פיתוח אפליקציות Mobile – אולי כדאי לחלק זאת לשתי סעיפים: iOS ו-Android. לא כל אחד שמפתח למערכת אחת, מומחה למערכת השניה.
  • סעיף "ארכיטקטורה" לא מובן לי. ב"ארכיקטורה" יש המון דברים הקשורים לתשתיות, אוטומציה, קונטיינרים, וירטואליזציה ועוד דברים רבים אחרים. האם המסמך יכול להכיל יותר פרטים?
  • הסבות בסיסי נתונים – על כך יש לי לאמר מספר דברים:
    • אני לא ממליץ ללכת על MySQL של אורקל אלא לעבור ל-MariaDB שכלול בתוך הפצת הלינוקס. למיטב ידיעתי, MariaDB מתפתח בקצב יותר מהיר וכולל תאימות לאחור ואין צורך לשלם עליו בנפרד.
    • ישנו פתרון RDBMS יותר רציני שנקרא PostgreSQL שגם נכלל בהפצות לינוקס (ונתמך ע"י רד-האט/SuSE בצורה רשמית) ויכול להיות שהוא יתאים יותר להסבה אליו מפתרונות DB אחרים.
    • הסבת נתונים מבסיסי נתונים כמו Oracle, MS-SQL, DB2, Adabas אל MySQL (או MariaDB) הם פרויקטים מסובכים וקשים. על מנת לעבור לדוגמא מ-MS-SQL ל-MySQL, יש מספר כלים ומתודות (כפי שניתן לראות כאן), אולם הקושי העיקרי הוא שינוי כל הקוד והלוגיקה באפליקציות שמשתמשות באותו DB. הרוב משתמשים ב-SQL כ"שפה" אבל לכל DB יש מימוש שונה. ב-DB אחרים כמו DB/2 ו-Adabas ההמרה תהיה הכי מורכבת.
    • אם אין בעיה של רשיונות, אפשר להתחיל להתעניין ב-SQL Server for Linux של מיקרוסופט (גירסת 2019 – זו הגירסה שיכולה לרוץ בקונטיינרים ובמערכות Kubernetes/Openshift).

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

  • איכות הקוד/מימוש הפרויקט: קבלת ממליצים ושיחה איתם לא תתן מידע שיכול להעיד על איכות הקוד של המתכנת או איכות ביצוע הפרויקט (מבחינה טכנית) ע"י המועמד. אם מישהו שוכר עצמאי לכתוב נניח אפליקציית שעון נוכחות, הדבר היחיד שמעניין את המזמין – הוא שהאפליקציה תעבוד ועדיף שיהיה גם תיעוד כלשהו לגבי תקלות. האם מזמין החברה יכול להעיד משהו על איכות הקוד של המפתח? לא. המקסימום שאפשר לקבל מידע מהממליץ, הם דברים "מסביב": האם המועמד ביצע את העבודה לשביעות רצון הלקוח, האם הוא עמד בלוח זמנים, האם הוא דאג "לסגור פינות", דברים כאלו, אבל שום דבר טכני שיכול להעיד על איכות הקוד, ולכן אני חושב שאולי כדאי להוסיף מבחן שהמועמד יצטרך לעמוד בו לכתוב קוד ושמישהו יבדוק את הקוד.
  • קוד הדוק ומאובטח: אנחנו נמצאים במדינה שמותקפת מבחינת סייבר מכל כיוון שתסתכל, ולא חשוב מה תשים "מקדימה" – אם הקוד גרוע מבחינת אבטחת מידע, יהיו דרכים לפרוץ למערכת. (לא צריך ללכת רחוק כדי להדגים – הנה מה שקרה עם מאגר נתוני האשראי רק לאחרונה), ולכן לעניות דעתי, אולי כדאי להוסיף מבחן או בדיקה של קוד מאובטח שיבדק ע"י מישהו שמבין ב-Code Auditing ושיתן ציון גבוה עבור קוד מאובטח.
  • Agile – זה שמישהו יודע לפתח זה טוב, אבל מה עם שימוש בכלים מודרניים? האם המפתח יודע להשתמש ב-GIT? האם הוא יודע לכתוב Pipeline ב-Jenkins לדוגמא? או Dockerfile (מאובטח) כדי להריץ את הקוד בקונטיינר? ומה שיותר חשוב – האם הוא יודע לכתוב Automated Tests בכדי לבדוק אוטומטית את הקוד שלו? גם לכך, לעניות דעתי, צריך לתת ציון.

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

כשאין נסיון מספק בתחום

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

כפרילאנסר – החיים מאוד דינמיים ומאוד תובעניים. ככל שאתה מכוון ליותר "גבוה" לפרויקטים והזדמנויות רווחיות – אתה צריך "להשיל" תחומים מסויימים בגלל שהשוק באותם תחומים מוצף בעצמאים שיהיו מוכנים לתת מחיר תחרותי מאוד. לדוגמא: תחזוקת מכונות Windows Desktop או תחזוקת שרתי Windows – יש מספיק בשוק שיציעו מחירים של 70-150 לשעה. אם אני אבקש "מאות" שקלים לשעה, ההצעה תידחה ולכן בדברים כאלו צריך לוותר ולכוון לדברים היותר רווחיים – קונטיינריזציה, עננים ציבוריים, כלי CI/CD, אוטומציה, אינטגרציית לינוקס, מערכות  משובצות, HPC, Scale Out, אחסונים גדולים (מעל פטה) ועוד.

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

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

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

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

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

עוד נקודה לשכירים – להכיר תחומים או דברים מסויימים ברמת ה-Overview וברמת תפעול כלשהי: כשכיר, יש סיכוי שהולך וגודל כל הזמן שתצטרך לעבוד (בין אם ב-IT או ב-Devops) מול ענן ציבורי כלשהו, ורוב החברות עובדות מול ענן ציבורי אחד. יחד עם זאת, יש סיכוי לא קטן שבחברה אחרת שתעבוד, הם עובדים עם ענן ציבורי אחר, ולכן, בזמן שאתה עובד באותה חברה נוכחית, תתחיל להכיר את העננים Azure, GCP, AWS ואם אתה צריך הדרכה אונליין, הנה קישור Referral שיכול לעזור לך להכיר את העננים האחרים, כך שאם ישאלו אותך אם יש לך נסיון ב-AWS לדוגמא, תוכל לענות "כן".

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

תכירו: vCompute Server של NVidia

במסגרת כנס VMWorld שנערך השבוע, חשפה NVidia את המוצר החדש שלה שהוא vCompute Server (נקרא לזה בקצרה VCS) שמתאים לאלו שצריכים להריץ עומסי AI, DL בסביבות וירטואליות.

עד היום, חברות שרצו להריץ למטרות Training ופיתוח עומסי AI בסביבה וירטואלית, היו צריכים לעשות זאת עם ה-vGPU ש-Nvidia מוכרת. בשיטה הזו מקצים חלק מכרטיס ה-GPU שיושב בשרת לכל VM (אגב, לידיעה: vSphere 6.7 U3 מאפשר לראשונה להצמיד מספר vGPU למכונת VM, לא רק vGPU יחיד).

לשיטה הזו יש כמה חסרונות רציניים:

  • ה-vGPU לא תוכנן מראש עם ה-CUDA לשימושי AI,DL. כן, הוא יכול להריץ זאת (גם מעבד גרפי נמוך מאוד כמו MX150 בלאפטופ יכול להריץ זאת), אך לא בצורה אופטימלית.
  • אם אתם משתמשים בקונטיינרים עם ה-Runtime Container של NVidia, זה לא היה מנצל את היכולות האמיתיות של הכרטיס (TCC, nVLink וכו') אלא היה מתייחס ל-vGPU בלבד.
  • אין תמיכת NVLink
  • אין אפשרות אגרגציה טבעית (מעבר למה שה-vGPU נותן).

הפתרון של NVidia הוא ה-VCS, מערכת חלופית שנותנת "vGPU" אבל למערכות AI,DL (כל עוד ה-VM לא מריץ שום דבר גרפי כי .. אין דרייבר גרפי).

מערכת ה-VCS פותרת את החסרונות של ה-vGPU ה"קלאסי" ונותנת את הפוקנציונאליות הבאה (אפשר לקרוא מעט יותר בהרחבה על כך בקובץ ה-PDF הזה):

  • אפשרות לחלק את ה-GPU לחלקים (Fraction) או לבצע אגרגציה של מספר v-GPU מכרטיסים שונים ובגדלים שונים.
  • מהירות עבודה יותר גבוהה (כי אין צורך לכרטיס לבצע רינדורי גרפיקה של מסכים וירטואליים/תלת מימד/וידאו וכו')
  • שימוש ב-NVLink בחיבור Peer to peer.
  • מיגרציה – מעתה אפשר לבצע vMotion (באשכולות לדוגמא) גם כשהמכונה רצה, לבצע suspend, resume.
  • תמיכה ב-Multi Tenant.
  • שימוש מ-NRC לקונטיינרים יהיה מהיר יותר, הואיל והמודול בלינוקס יודע להשתמש בכל היכולות של ה-GPU בשרת.

החסרונות:

  • אין דרייברים לגרפיקה (אז תשכחו מאובונטו גרפי – ואם אתם עדיין רוצים סביבה גרפית, תכירו את NoMachine)
  • אין דרייברים ל-Windows (כן, לכל גרסאות Windows)
  • אין יותר פרופילים קטנים, הן ברמת זכרון (המינימום הוא 4 ג'יגה, המקסימום הוא 48 ג'יגה) והן ברמת CPU (מינימום 4 ליבות, מקסימום 48 ליבות).
  • אין תמיכה ב-Quadro הישנים (יש תמיכה ב-Quadro RTX)

מבחינת רישוי: תצטרכו רישוי בתשלום שנתי, פר GPU.

פתרון ה-VCS בהחלט מתאים כמובן (ומומלץ) לשימוש עם Kubernetes, קונטיינרים וכו'.

ובעניין מעט שונה: נודע לי כי רוב החברות שרוכשות GPU בשרתים לצרכי AI – רוכשות RTX 2080TI ובכמויות נכבדות. כפי שציינתי בעבר, כרטיסים אלו אינם מתאימים לשרתים, הואיל והם צריכים כניסת אויר מצד שמאל ואילו כל הכרטיסי GPU לשרתים מצריכים איוורור מאחורי הכרטיס (בגלל זה הכרטיסים אטומים מצד שמאל). מהרגע שאתם מכניסים RTX 2080TI, אתם צריכים לקחת בחשבון שהכרטיס מהר מאוד יבצע שנמוך מהירות שעון הואיל ואין לו קירור מספק ואתם יכולים להגיע למהירות עיבוד של .. RTX 2070.

מעבר לכך, עם ה-VCS יש סוף סוף ניצול לחיבור ה-NVLink והעברת המידע ב-GPU בין הכרטיסים במהירות של 100 ג'יגהביט לשניה. ב-RTX 2080TI יש רק חיבור אחד כך שניתן לצוות מקסימום זוג כרטיסים. אם נכניס 8 כרטיסים כאלו לשרת וננסה להשתמש בכולם (הגדרת TCC), המערכת תצטרך לעבוד יותר לאט הואיל וה-DATA צריך לעבור הלוך ושוב בין ה-GPU (דרך המעבד וה-RAM בשרת) לדיסק וההיפך, ואילו עם כרטיסי Tesla וכרטיסים אחרים לשרתים (Quadro RTX) ה-DATA עובר בין כרטיסי ה-GPU דרך ה-NVLINK כך שהדברים רצים הרבה יותר, ועוד לא הזכרתי שמבחינה חוקית NVidia אוסרת על הפעלת כרטיסי RTX 2080TI (או כל RTX "ביתי") על שרתים והם יכולים מחר בבוקר בעדכון CUDA ודרייבר פשוט לבטל אפשרות שימוש בכרטיסים ביתיים בשרתים, כך שחשוב לקחת זאת בחשבון.

עוד נקודה ש-NVidia הכריזו היא הקמה של Repo חדש לקונטיינרים שמשתמש ביכולות CUDA ונקרא NGC. זה לא ממש חדש (ומשתמשים בו ב-DGX שלהם), אבל הפעם זה פתוח לקהל. לתשומת לב צה"ל, חברות בטחוניות וכו' שלא ממש מוכנים/יכולים לעבוד באופן ישיר מול האינטרנט – אין שום בעיה להוריד מה-REPO של NGC (ואחרים למען האמת) ולאכסן זאת דרך Registry משלכם. הנה לינק איך עושים זאת עם לינוקס.

לסיכום: אם אתם צריכים/משתמשים במערכת וירטואליזציה לצורך AI/DL או לשימוש עם קונטיינרים, הפתרון החדש של NVidia יכול בהחלט להתאים לכם. קחו בחשבון שאם אתם צריכים מקסימום מהירות, עדיף לרכוש את כרטיסי ה-Tesla או כרטיסי ה-Quadro (או כרטיסים עם האות V) עם חיבור NVLink כפול בכל GPU.

עדכונים בנושאי וירטואליזציה ו-VDI

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

אתחיל בנושא VDI.

תודות לחברת CRG שהשאילה לי כרטיס AMD S7150 לצרכי בדיקות VDI – התחלתי לבדוק את הנושא. לצערי הכרטיס הזה לא ממש עובד על מעבדי Xeon ישנים (סידרה V1-V2). הזמנתי לוחות אם של Supermicro יד שניה מסוחר ישראלי ו… גיליתי להפתעתי שהלוחות פגומים (פגומים במובן שכאילו מישהו העביר פטיש על תושבות המעבדים ועיקם את רוב הפינים!). מכיוון ששילמתי ב-Paypal, הצלחתי להחזיר את הלוחות ולקבל את הכסף בחזרה, כך שלא יכלתי להתקדם הרבה עם הכרטיס והחלטתי להחזיר אותו ל-CRG.

לא הרמתי ידיים, החלטתי לבצע בדיקות סימולציות משתמשי דסקטופ (כלי מצוין לכך: LoginVSI, יש גירסת התנסות בחינם) במובנים הבסיסיים לצרכי רואה חשבון ועורכי דין שמדי פעם גם צופים פה ושם בוידאו. התברר לי שכשמדובר בכמות קטנה (5-8 תחנות) של משתמשים, ואם משתמשים ב-RDP בלבד – לא יהיה צורך בכרטיס GPU לצרכי VDI. המעבדים בשרת מודרני יכולים לעמוד יפה בעומס. (אני ביצעתי את הניסויים על מעבד דסקטופ AMD Ryzen 7 2700X, כך שמעבדי Xeon יכולים לעשות זאת בקלות).

מכאן נעבור לברזלים: אני ממליץ על שרת בתצורת TOWER מהסיבה הפשוטה שלרבים אין מקום להכניס שרת 1U/2U רגילים מבלי לרכוש ארון תקשורת בעומק 80 ס"מ, מה גם שהוא מרעיש. שרת במארז Tower בדרך כלל הרבה יותר שקט והאיוורור בו הרבה יותר טוב ויעיל.

מבחינת אחסון, אני ממליץ להשתמש ב-Synology. אפשר כמובן להכניס דיסקים מכניים בשרת, אבל היתרון הגדול של Synology הוא שניתן לגבות גם מכונות ב-ESXI החופשי (כן, רוב התוכנות מאפשרות גיבוי רק אם יש לך את הסט שכולל vCenter וכו', התוכנה של Synology יודעת לעקוף זאת), כך שניתן להחליט אם להשתמש בדיסקים בשרת או ב-NAS (ולגבות לענן לדוגמא). עלות תוכנת הגיבוי כלולה ב-NAS עצמו, כך שאין צורך לשלם בנפרד, יש גיבויים מלאים, אינקרמנטליים, ואפשרות גם להריץ במקרה חרום VM מגובה מה-NAS עצמו אם VM ב-ESXI נדפק ואין זמן לשחזור מלא (את האופציה הזו מומלץ להשתמש אך ורק במקרה חרום. זה איטי).

מבחינת תקשורת: אני ממליץ  חיבור 10 ג'יגהביט בין השרת ל-Switch (לרוב המתגים יש Uplink של 10 ג'יגה בחיבור +SFP) – אם כל המשתמשים צופים בוידאו – קידוד ה-RDP + קידוד H.264 + תעבורה של הדסקטופ לוקחים לא מעט.

אסכם את הנושא כך: עם ESXI חינמי, עם מכונה בתצורת Tower שכוללת 2 מעבדים של 8 ליבות כל אחד, 128 ג'יגהבייט זכרון, דיסקים מקומיים, NAS של Synology ומתג נורמלי – אפשר לייצר "סביבת VDI". הפתרון, כמובן, לא VDI כמו Horizon או Terminal Services והוא גם לא מתיימר לכך, הוא בסך הכל נועד להעביר כמות קטנה של מכונות פיזיות ישנות ולהמירן ל-VM ולעבוד עליהן. אם מדובר על עשרות של מכונות פיזיות וכו' – אז כדאי בהחלט לחשוב על פתרון VDI מלא.

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

ומכאן – לוירטואליזציה (אצלי לפחות): עד היום עבדתי הן עם KVM והן עם oVirt/RHV (שמבוסס על KVM). ברמת המאקרו – הפתרון הזה הוא פתרון מעולה לוירטואליזציה, אבל ברמת המיקרו, יש כמה באגים וחוסרים קטנים שיכולים לשגע פילים: נסיון הוספה של Nodes שאינם מבוססים על מעבדי Intel מפיל את התהליך, כי התהליך לא יודע לזהות מעבדים אחרים ויש צורך להגדיר הכל ידנית ועוד כל מיני דברים קטנים. אפשר כמובן לדווח על באגים, אולם כל עוד אינך לקוח משלם – אולי תזכה ליחס ואולי לא. מכיוון שאני צריך להריץ על מספר מכונות כאשכולות, אני צריך פתרון רציני ולכן אני חוזר ל-vSphere, עם כל הצער שבכך.

עננים: במהלך השבועות הקרובים אתחיל להעלות קליפים נוספים הקשורים בתכנון מכונות על AWS, על שימוש ב-VPC (תתפלאו כמה חברות כלל לא מגדירות VPC ומשתמשות ב-Default), על Load Balacing ועוד.

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

ה"היצמדות" ל-CUDA והעתיד

כפרילאנסר, אני מציע שרות שלא מעט חברות ועסקים זקוקים לו בהתחלה – והוא קשור ל-CUDA, הדרייבר של nVidia, והשבב הגרפי הפנימי שנמצאים במעבדים של אינטל (בתחנות עבודה). הצירוף של ה-GPU המובנה במעבד של אינטל וה-GPU של Nvidia לא תמיד יודעים "לעבוד" יחד, במיוחד בכל מה שקשור ל-OpenGL ו-Xorg וצריך לדעת איך "לפשר" ביניהם. מעבר לכך, ה-CUDA של Nvidia יכול לעבוד רק מגרסאות מסויימות בכרטיסי ה-GPU החדשים של NVidia כמו Tesla מסידרה T. כתוצאה מכך אני עוקב בזמני הפנוי אחרי גרסאות CUDA, דרייברים הן של אינטל והן של Nvidia.

מבחינת השוק כיום – בין אם מדובר בסטארטאפים, עצמאים וחברות שעובדים בתחומים הקשורים ל-AI, Deep learning וכו', כרטיסי ה-GPU המועדפים בצורה חד משמעית הם הכרטיסים של NVidia וכמובן הכל הולך לפי התקציב: למי שאין תקציב, רוכש כרטיסי RTX (כרטיסי ה-GTX כבר "מתו"), ולמי שיש תקציב – רוכש כרטיסי Tesla או Quadro. כשזה מגיע לשרתים, ההמלצה החד משמעית היא כרטיסי Tesla הואיל והאיוורור שיש בשרתים אינו מתאים לכרטיסי RTX (זה יעבוד, אבל הכרטיס יוריד עצמאית את מהירות העיבוד בצורה דרסטית בהתאם לטמפרטורות בכרטיס).

כתוצאה מכך, כל פלטפורמות הפיתוח (TensorFlow, Caffe וכו' וכו') תומכות בצורה מלאה ב-CUDA, כמו שהן תומכות בכרטיסי GPU אחרים (אם אין לך GPU של NVidia, אין שום בעיה לעבוד עם כרטיס GPU אחר, או עם ה-GPU המובנה או עם המעבד עצמו – הביצועים יהיו בהתאם). אם ביצועי GPU יחיד של NVidia אינם מספקים אותך (ורכשת כרטיס RTX 2080 ומעלה), תוכל להוסיף GPU נוסף (ויותר) ולחבר ביניהם עם מחבר NVLink שנמצא בחלק העליון של הכרטיס. פלטפורמת CUDA יודעת לזהות מיידית את הכרטיס ולחלק את העבודה ביניהם, תוך כדי שהיא נותנת "ציון" לכל GPU ובהתאם לכך היא מחלקת את העומסים.

כשזה מגיע לעננים ציבוריים, התמונה משתנה במעט. אם אתם משתמשים בעננים של אמזון או מיקרוסופט, אתם יכולים לשכור Instance הכולל GPU של Nvidia (מיקרוסופט מאפשרת כיום גם לשכור GPU של AMD, תיכף אתייחס לכך) ואילו גוגל מציעה ללקוחותיה לשכור Instance עם GPU של NVidia או עם פתרון משלהם שנקרא TPU (שנותן ביצועים שאינם נמוכים ממה ש-NVidia יכולה להציע גם עם הכרטיס הכי חזק שלה).

כאן מתחיל העניין שנקרא תחרות, ואת התחרות מייצג פתרון שנקרא OpenCL. פתרון OpenCL זקוק למימוש בדרייבר עצמו וכל יצרן (כולל NVidia) כותב זאת ומציע זאת ללקוחותיו. היתרון המוחץ של OpenCL על CUDA, הוא בכך שהוא מזכיר את OpenGL ו-DirectX – אתה יכול להשתמש באיזה GPU שתרצה, ובהתאם למימוש בדרייבר – התוצאות יהיו בהתאם. גם ה-TPU של גוגל וגם הפתרון GPU של AMD משתמשים ב-OpenCL במימושים שונים על מנת לאפשר למפתחים ולפלטפורמות את תמיכת ה-OpenCL שהן דורשות. (למעוניינים, להלן לינק המשווה בין OpenCL לבין CUDA. מי שמחפש את הגירסה המקוצרת: CUDA = פתרון סגור, OpenCL = פתרון פתוח לחלוטין שנתמך בכל GPU)

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

  • אינטל הכריזה לאחרונה על שני פתרונות ל-AI (גאווה ישראלית: הם פותחו כאן בארץ). הפתרונות הללו לא רק תומכים ב-OpenCL אלא במגוון פלטפורמות וכמיטב המסורת של אינטל בקטע הזה, הכל בקוד פתוח. זהו הכרטיס הראשון ל-AI ו-DL שמשתמש ב-PCIe 4 X16. הקטע האירוני: בשביל להשתמש בכל רוחב הפס, תצטרך כיום .. מעבד ולוח של AMD..
  • עוד פתרון חומרה כחול לבן הוא של חברת Habana שמציעים את GOYA ככרטיס למחשב ושרת, ואת GAUDI כפתרון כחלק ממערכת מלאה (כרטיס יעודי). גם כאן, יש תמיכה מלאה ל-OpenCL ומגוון פלטפורמות AI ו-DL.
  • עוד פתרון מגיע מסין מחברה מאוד ידועה – Huawei, אם כי בניגוד לשאר, החברה הציגה מעבד בלבד (כלומר לא פתרון קצר) בשם Ascend 910 שהחברה טוענת שהוא מעבד ה-AI הכי מהיר בעולם.
  • ל-AMD יש כרגע את כרטיסי ה-GPU מסידרת Instinct ל-AI ו-DL. החברה מתעתדת בחודשים הקרובים להכריז על הדור הבא.
  • אינטל (כן, שוב) – מתעתדת בשנה הקרובה להוציא משפחת כרטיסי GPU חדשים שתתחרה הן ב-GPU הרגילים של NVidia ו-AMD והן GPU למטרות AI ו-DL – הם יהיו תחת משפחה בשם "Xe".

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

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

עוד נקודה חשובה: ישנם כל מיני אנשים שממליצים לבצע את ה-Inference על מעבדים. אם אתם רוצים לעשות זאת על מעבדים, קחו את המעבדי EPYC החדשים של AMD – גם תחסכו 40-70% במחיר (תלוי בכמות הליבות) ותוכלו לבחור מעבד עם עד 64 ליבות או 2 מעבדים עם 128 ליבות (שימו לב: אתם צריכים את הסידרה החדשה 7XX2, לא את הישנה 7XX1).

לסיכום: כמו תמיד, אינני ממליץ לשים את כל הביצים בסל אחד. כן, הפתרון של NVidia הוא פתרון מעולה אך הוא פתרון סגור שרץ רק על הכרטיסים של Nvidia. אם אתם מפתחים פלטפורמה או קוד בפלטפורמה או אפליקציה משלכם, תבדקו אם היא עובדת עם OpenCL. אחרי הכל – אינכם יודעים מה הלקוח שלכם ירצה להריץ וחבל למצוא את עצמכם בדקה ה-90 מציעים פתרון שלא יכול לרוץ בתשתית של הלקוח. השוק ישתנה ב-2020 ועוד יותר ב-2021 (לכל החברות "נפתחו העיניים" וכולם רוצים את הרווחים המאוד נאים ממכירות כרטיסים ופתרונות כאלו).

שינוי רישוי JAVA SE

חברת אורקל רכשה את חברת SUN לפני מס' שנים ובעקבות הרכישה, פלטפורמת JAVA עברה לידי חברת אורקל. עד לשנה שעברה, הרישוי של חברת אורקל לגבי JAVA SE ומעלה (JAVA EE) היה די ברור וחברות רבות פשוט העדיפו לעבוד עם Java SE (כלומר: Java Stanadrd Edition) לפיתוח ולהתקין את ה-JRE (כלומר Java Runtime Edition) בשרתים, דסקטופים שצריכים זאת וכו'. מי שרצה להשתמש ב-JAVA הרשמי ב-Embedded היה צריך (ועדיין צריך) לשלם את המחיר המלא.

החל מהשנה, חברת אורקל שינתה את הרשיונות של JAVA (ואפשר לקרוא את ה-FAQ שלהם כאן). לאלו שרוצים לחסוך את הקריאה, אקצר את הדברים: כל עוד אתם צריכים את ה-JDK או ה-JRE מגירסה 8 ומעלה לשימוש שאינו מסחרי (כמו בבית), לאורקל אין שום בעיה איתכם ואתם יכולים להוריד ולהשתמש. אם לעומת זאת אתם חברה, או שהרמתם אתר מסחרי – אורקל רוצה מכם כסף, וכן, גם על JRE הם דורשים כסף.

כמה כסף? אם מדובר במכונת דסקטופ (צריך עדיין JRE לדוגמא כדי לנהל שרתים ישנים עם iLO-3 או iDrac) – תצטרכו לשלם מחיר של 2.5$ לחודש. אם אתם צריכים להתקין על שרתים, אז אתם צריכים לשלם על כל הליבות שיש בשרת, בהתאם לליבות הפיזיות שיש בשרת, לפי הטבלה הזו. כלומר אם יש לדוגמא יש לכם שרת שבו יש שני מעבדי Xeon כשלכל אחד מהם יש 8 ליבות, אז סך הכל יש בשרת 16 ליבות, וה-Core Factor הוא 0.5. נכפיל במחיר הרשמי של 25$ לחודש, ונראה שאנחנו צריכים לשלם על כל שרת כזה 200$ לחודש. נקודה שחשוב לציין: אם אתם משתמשים בוירטואליזציה שאינה Oracle VM (כמו VMWare) ואם הקמתם בשרת הזה רק מכונת VM אחת עם 4 ליבות וירטואליות שמשתמשת ב-JAVA, אתם עדיין צריכים לשלם על כל הליבות שבשרת. (אם הבנתי זאת נכון, צרו קשר עם נציג המכירות של אורקל כדי להיות בטוחים). אם אתם רוצים את קבצי ה-MSI, אגב, אתם נכללים בקטגוריה המסחרית ותצטרכו לשלם את מה שציינתי לעיל, כל חודש.

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

הפתרון הוא OpenJDK.

OpenJDK הוא מימוש קוד פתוח (שאורקל גם משתתפת בו) של ה-JDK בגירסת ה-Standard Edtition (אין גירסת OpenJDK ל-Enterprise Edition – זהו מוצר נפרד של אורקל שאין לו מתחרה בקוד פתוח) וברוב המקרים הוא משוחרר בסמיכות לגירסת JDK/JRE המסחרית שאורקל משחררת. אפשר לקרוא על ההבדלים כאן. בעקרון, לא אמור להיות הבדל בין גירסת OpenJDK לגירסת SE, רק שחשוב לציין – OpenJDK משוחרר תחת רשיון GPL, וכל שינוי שנעשה ב-JDK – יש לשחרר בחזרה לציבור.

על OpenJDK אין צורך לשלם וניתן להוריד גרסאות בינאריות לכל הפלטפורמות (כולל Docker) מהלינק הבא.

אם בחרתם להשתמש ב-OpenJDK, כדאי מאוד לבדוק פנימית אם האפליקציות שלכם רצים ומגיבים כמו ה-JDK/JRE הרשמי של אורקל. הדברים אמורים לעבוד בדיוק אותו דבר למעט שימוש בכל מיני Applets להשתלטות מרחוק על ציוד ישן (שרתים) – שם יש לא מעט מקרים שמקשים לא עובדים טוב (במיוחד קיצורי מקשים). אתם יכולים לנסות להשתמש ב-OpenJDK כדי לבדוק אם יש תאימות, בכך שתתקינו את החלק שנקרא IcedTea (כן, שם "מתחרה" ל-Hotspot) וכדאי לשים לב למגבלות שלו.

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

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

 

הבדלים בין Snapshot לגיבוי

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

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

  • מימוש ראשון VMWare Snapshot
  • מימוש שני – AWS Snapshot

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

עכשיו נעקוב אחר התהליך הנ"ל מקרוב. ברגע שיצרנו את ה-Snapshot לאותו VM, הוא מתחיל בגודל 0 בתים (או משהו קרוב לכך, יכול להיות שה-snapshot יכלול בתים ספורים בהתחלה). ברגע שערכנו את אותו קובץ טקסט ושמרנו אותו, הוא אינו שומר את השינוי לדיסק הקשיח הוירטואלי, אלא שומר אותו לתוך ה-snapshot. אם נבדוק, נוכל לראות שגודל ה-snapshot גדל בכמות הבתים שהוספנו לאותו קובץ טקסט (את הדברים הרבה יותר קל לראות "מבפנים" אם משתמשים במערכת ZFS, שהיווה "השראה" ל-VMWare כיצד ליצור snapshots). אם לאחר שיצרנו קובץ Snapshot, עבר זמן ויצרנו קובץ snapshot חדש, כל השינויים שניצור מעתה ישמרו ב-Snapshot החדש, וה-snapshot הקודם יעבור למצב read only.

המימוש השני של snapshot לשם הדוגמא יהיה AWS EBS Snapshot: הקמנו Instance (כלומר VM) עם מערכת ההפעלה שבחרנו, ולאחר מכן ביצענו מספר שינויים בהגדרות, הוספנו אפליקציות ועוד, וכעת אנחנו יוצרים Snapshot ב-AWS. ה-Snapshot הראשון שניצור ישמור את השינויים מהקמת ה-VM עד לרגע זה. אם ניצור Snapshot נוסף, הוא ישמור את השינויים שנוצרו מאז ה-Snapshot הראשון, כלומר כל שינוי שביצענו אחר ה-Snapshot הראשון ישמר בדיסק EBS ולא ב-snapshot ורק אם ניצור snapshot נוסף, השינויים יועתקו אליו.

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

מכאן נעבור לנקודה היותר "פילוסופית" – האם snapshot יכול להחליף את מקומו של הגיבוי? זה תלוי.

במקרים כמו VMWare התשובה היא "לא ממש" הואיל ויצירת Snapshot הוא דבר שצריך לבצע "ידנית". המערכת לא תיצור עבורך snapshot אוטומטית (למרות שלמערכת יש בהחלט דבר שנקרא Changed Block Tracking שמופעל אוטומטית ובכך המערכת יודעת לזהות כל שינוי שבוצע בדיסק, ואין זה משנה איזו מערכת הפעלה מדובר, כי אותה מערכת עובדת בבלוקים, לא ב-File system) ולכן גיבוי של המערכת ע"י תוכנת גיבוי (Veeam, Arcserve ושאר תוכנות) היא דבר חשוב ואף הכרחי.

בעננים ציבוריים כמו AWS לעומת זאת, יש צורך לעבוד בשיטה שונה (שלצערי יש לא מעט שמתחילים לעבוד עם AWS ולא מפנימים זאת): ב-AWS כדאי לבנות את מכונות ה-VM כ"שלדים" (templates) ולשמור את הקבצים המשתנים ב-EFS או ב-S3. כך, בונים VM, מגדירים את הדברים הקבועים, מוסיפים סקריפט שידע להעתיק את הקבצים הנחוצים מ-S3 או EFS, יוצרים snapshot ולאחר מכן ממירים את זה ל-Image בפורמט AMI סגור. נדפק ה-VM? פשוט מקימים חדש מה-AMI כשאחד הפרמטרים הוא בעצם הרצה של הסקריפט שיצרנו כך שלאחר הקמת ה-VM/Instance – הוא יעתיק את הקבצים וידווח לנו מה כתובת ה-IP הפנימית של ה-VM החדש.

ב-ZFS הדברים שונים. מכיוון ש-Snapshot ב-ZFS אינו תופס מקום בדיסק (0 בתים), ישנה שיטה פשוטה ליצור אוטומטית snapshots כל זמן שתרצה. אני לדוגמא עובד עם ZFS שיוצר snapshots כל שעה, כל יום, כל שבוע, כל חודש, כל שנה – ומגדיר את המערכת שתשמור לי 50 snapshots אחורה. מבחינת שרידות, ZFS תומך במערך RAID (שנקרא RAIDZ) עד רמה שלישית (כלומר: המערכת יכולה לתפקד עד למצב שבו יש שלושה דיסקים תקולים) עם תמיכה מלאה ב-Hot Spare. מעבר לכך, מערכת ZFS נותנת גם "להשתולל" עם מערכי RAIDZ כך שניתן להקים שתי מערכות RAIDZ3 ולצוות אותן יחד כ-RAIDZ1. בזבוז מטורף של דיסקים? בהחלט, אבל למי שיש תקציב – בכיף. מה עם גיבוי לטייפ? יש כאלו שמגבים אחת לזמן מה לטייפ ויש כאלו שפשוט מעדיפים להשתמש בתשתית ה-ZFS ופקודות ה-send/receive המובנות על מנת לגבות את ה-ZFS למערכת מרוחקת. (אפשר כך לבנות אחסון DR בזול. אגב, מקומות רבים בחו"ל משתמשים בשיטה הזו).

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

שינויים בעולם ה-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. אותם פתרונות מקומיים יכולים להתאים אם מישהו מחפש תמיכה בעברית או שהרגולטור אוסר על הלקוח להריץ תשתית בחו"ל.

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

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