עננים ציבוריים: להתחיל בקטן ולגדול

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

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

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

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

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

ה-Lightsail של אמזון נועד להתחרות בחברות כמו Digital Ocean, Linode ואחרים, אולם המטרה העיקרית שלו היא לתת ללקוחות פתרונות מוכנים לאלו שאינם מכירים את הפלטפורמות של עננים ציבוריים ואותם סטארטאפים מעדיפים להשקיע את הזמן שלהם בבניית משהו שאפשר להדגים כ-PoC ואולי אפילו לגייס כמה לקוחות Beta ולהשתמש בשמם בהמשך כדי להשיג לקוחות משלמים.

במקרים כאלו ה-Lightsail הוא פתרון מעולה. השימוש בו ממש קל: אתה יכול להרים לך מספר מכונות, אתה יכול להשתמש בשרותי ה-DB המנוהלים של אמזון גם ללא הכרה של ה-RDS המורכב, אתה יכול להשתמש ב-Load Balancer הפשוט שאמזון מציעה כדי לנתב את התעבורה, ואתה יכול להשתמש בשרותי ה-Snapshot כדי לשכפל מכונות תוך דקות ספורות, ויש דברים נוספים שלא עולים לך כמעט כלום: אתה יכול להשתמש בשרות ה-SMS לשם משלוח מיילים החוצה (בכמויות שסטארטאפים קטנים מתחילים – הם לא ישלמו כלום), אתה יכול להרים GIT פרטי (5 משתמשים ראשונים זה בחינם), אתה יכול גם להשתמש בשרות ה-DB המנוהל עם אפשרות Cluster שיעבוד כ-Active/Passive עם גיבוי אוטומטי כל 5 דקות, ויש לך מגוון שרותים שאתה יכול להשתמש עם ה-Lightsail מבלי להכאיב לארנק.

ברגע שהסטארטאפ רוצה לגדול, Lightsail מאפשר לך להעביר את התשתית שלך כמו שהיא ל-AWS המלא. צור Snapshot למכונות, ותוכל להקים אותם כ-Instances ב-EC2 ואותו דבר לגבי ה-DB – תוכל להעביר אותו בקלות ל-RDS ולהשתמש בשרותים מתקדמים כמו רפליקות וכו'.

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

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

תכירו: 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 ועוד.

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

שינוי רישוי 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 נהיה דבר מובן מאליו בתוך החברה.

המעבר לענן ציבורי – התהליכים המקדימים

דמיינו לעצמכם סיטואציה פשוטה: יש לכם 20 שרתים בחברה (פיזיים) שמערכת vSphere רצה עליהם. הכל מתקתק ועובד טוב עד שיום אחד האחראי על ה-vSphere בחברה מפוטר עקב סיבה כלשהי. האם יהיה קשה למצוא עובד חלופי לאותה משרה? לא ממש, השאלה למה אתה מצפה: אם לדוגמא העובד שפוטר היה כותב סקריפטים ב-Powershell או ב-PERL לאוטומציה של ה-vSphere ורוב העבודה היתה נעשית באוטומציה כלשהי ללא שימוש ב-GUI – אז כן, אתה תתקשה למצוא מחליף (וגם אם תמצא, תצטרך לשלם לו הרבה יותר ממה שחשבת). אם לעומת זאת אתה מחפש מישהו שינהל רק ברמת הממשק Web, תמצא לא מעט כאלו בקלות ותוכל לשלם להם משכורת יותר נמוכה אפילו (תלוי בכישורי המו"מ שלך והבטחון העצמי של המועמד). מצד שני, אם יש לך תקלות שמתאפיינות במסך סגול וגוגל לא ממש עוזר – תתכונן לשלם והרבה, בין אם זה ל-VMware או למישהו מומחה.

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

מה בעצם העבודה שהרוב יציעו ויעשו? הם יעשו מה שאני קורא "Copy Paste". נניח שיש 10 מכונות VM, הם פשוט יעלו אותן לענן כ-Instances, יקצו להן כתובות IP חיצוניות פר Instance (תתפלאו כמה חוסר מקצועיות יש בנושא), יגדירו Security Group שנושאת מטוסים יכולה לעבור דרכו, חס ושלום VPC חדש ונורמלי, או ניתובים קצת יותר מוקשחים. אם הלקוח מתעקש על Firewall, אז יתקינו איזה משהו שקיים ב-Market עם חוקים מאוד "רפים". אני לא מנסה "ללכלך", אני בדרך כלל מי שמגיע אחרי כן לבדוק מדוע הדברים לא עובדים טוב וזה מה שאני מוצא. אני כמובן שלא אומר שכולם כך, יש דווקא לא מעט אנשים מקצועיים בתחום.

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

בהעברת התשתית לענן יש לנו 3 מטרות חשובות:

  • הורדת המחיר פר מכונה
  • קבלת ביצועים יותר גבוהים
  • הגנה יותר נאותה.

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

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

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

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

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

בניית מכונות VM בצורה יותר טובה

תחום הקונטיינרים קיבל בשנים האחרונות דחיפה רצינית תודות לפתרונות כמו Docker, OpenShift, Kubernetes ומערכות רבות נוספות, ואחד הדברים הראשונים שכל מי שנכנס לעולם הקונטיינרים לומד הוא שקונטיינרים זה דבר זמני – אתה מפעיל, מכבה, וכל התוכן שבקונטיינר עצמו – נעלם, ולכן משתמשים בפונקציות כמו Volume (במערכות כמו Kubernetes יש לנו את PV/PVC) כדי למפות משאב חיצוני (כמו תיקייה במכונה) אל קונטיינר ושם יאוחסן המידע, כך שגם אם הקונטיינר נמחק, ה-DATA נשאר.

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

הדבר שאני מדבר עליו – חלוקה.

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

אבל הבעיה הכי גדולה במכונות VM כאלו שבונים – קשורה לשחזור נתונים. נניח שהקמנו שרת Gitlab או שרת MySQL או שרת SQL וכל הזמן זורמים אליו נתונים חדשים ועדכוני נתונים. לפתע מכונת ה-VM מפסיקה לפעול או שיש תקלה שיקח זמן לתקן אותה. מכיוון שזו מכונת VM, בדרך כלל אפשר פשוט לשחזר אותה מגיבוי (או אם בוצע snapshot לאחרונה).

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

איך נמנעים? די פשוט: מתחילים להשתמש בשרותי ה-Network File שקיימים, דוגמאות:

  • אם אנחנו מרימים MySQL או SQL של מיקרוסופט על לינוקס, אפשר למפות את התיקיות DATA שהשרות נזקק להן – למפות ל-NFS Share (אם אתם מריצים SQL של מיקרוסופט על לינוקס עם NFS, ודאו כי מדובר ב-NFS 4.2 וה-mount צריך לכלול את הפרמטר nolock)
  • אם אתם מרימים שרת אפליקציית GIT או שרת WEB – אפשר למפות ל-NFS את התיקיה שה-DATA עצמו (כמו קבצי php,html, גרפיקה וככו') יאוחסן. כל מה שצריך זה פשוט ליצור בסטורג' את ה-NFS Share ולבצע mount שיוגדר בקובץ fstab.
  • ב-Windows נשתמש באותן שיטות, רק עם SMB במקום NFS.

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

אני מניח שיהיו לא מעט מתנגדים לשיטה (במיוחד מנהלי סטורג' שפתאום מגיעים אליהם עם דרישות ליצור עוד ועוד NFS/CIFS Share) אך זו השיטה שבין כה תצטרכו להשתמש בה עם קונטיינרים בעתיד, ובסופו של יום – שיטה זו חוסכת זמן רב אם מכונה שנותנת שרות למשתמשים רבים נופלת באמצע היום ואין הרבה זמן לבדוק ולטפל בבעיה (במיוחד אם אין ידע מספק בחברה על התקלה ואיך לטפל בה), וזו בדיוק הסיבה שאני ממליץ לחברות ועסקים "להמיר" מכונות VM לעבוד בשיטה כזו ולחסוך זמן התאוששות. אגב, אחד המקומות שבהם גם תוכלו להשתמש בשיטה כזו היא בעננים ציבוריים (באמזון זהו שרות EFS שמספק NFS לכל ה-Instances שלך לדוגמא).

לסיכום: מכונות VM לא צריכות להיות "מפלצות VM" עם דיסקים בגדלים של מאות ג'יגה עד טרהבייטים. בדרך כלל אין צורך ש-VM מבוסס לינוקס לדוגמא יהיה בגודל של יותר מ-10-20 ג'יגהבייט. אם ה-VM נותן שרותים, אני ממליץ פשוט לאחסן את הנתונים לשרותים דרך NFS/CIFS, כך גם תקבלו מהירות read/write יותר גבוהה (דיסקים וירטואליים עדיין יותר איטיים בהשוואה ל-NFS "טבעי", אגב), וגם כשתצטרכו לשחזר מ-snapshot או גיבוי, לא תצטרכו לדאוג לגבי עניין האם ה-DATA החשוב מעודכן.

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

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

anan

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

  1. אחד הדברים הבולטים לטובה במסמך הוא התייחסות למחשוב ענן כמו שספקי הענן הציבורי מציגים ומוכרים ולא כל מיני "ענני צעצוע" שכל מיני חברות בארץ מציעות/מוכרות. התנאים עצמם ישר פוסלים את אותם "ענני צעצוע" בכך שיש דרישות שלספקים בארץ אין אותם, הן מבחינת הכנסות והן מבחינת Availability Zones (שמשום מה במסמך הם נקראים "Domains"), מיקומים גיאוגרפים וכו' ואף אחד מהספקים בארץ גם לא מציע 500+ שרותים שונים באותו ענן.
  2. אני שמח לראות שבמשרד האוצר מחפשים שהזוכה יקים בעצם Region אחד ובתוכו Availability Zones אולם לעניות דעתי, חשוב שבמשרד יתעקשו על כך שה-AZ יהיו במרחק רב אחד מהשני.
  3. נקודה שלדעתי חסרה במסמך וחשוב שתצוין (ושהמשרד יעמוד על כך) – שה-AZ יהיה מחובר בחיבורי תקשורת מספקי אינטרנט שונים ולא מספק יחיד. רק לפני חודשים ספורים אלפי אתרים נותקו מהאינטרנט עקב "תקלת תקשורת" של ספק אינטרנט מרכזי. האם משרד האוצר רוצה לחוות חוויה כזו?
  4. אם המתמודדים הם בעצם ספקי הענן הציבורי, מומלץ לבקש לדעתי במסמכי המכרז כי הספק הזוכה ייבא וישתמש בציוד שלהם ולא בציוד COTS. הציוד של ספקי הענן שונה לחלוטין מציוד שחברות רוכשות החל ברמת המעבדים, זכרונות, לוחות, אחסון, תשתיות תקשורת וכו' ויש סיבה טובה לכך – ביצועים הרבה יותר גבוהים.
  5. בבקשה, בבקשה – בלי Azure Stack. כתבתי כאן מדוע לא.
  6. נקודה נוספת שאולי כדאי שמשרד האוצר יחשוב לגביה – שה-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 בארץ זהו צעד מבורך, אולם כדאי לשים לב לדברים שונים כדי שהפרויקט יצליח, ובמיוחד כדאי כבר מעכשיו לחשוב איך להעביר את כל הצוותים במשרדי הממשלה וביחידות הסמך לעבוד לעבור במתודות מודרניות.

האם ה-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.