תכירו: משפחת ה-Ryzen 5000

חברת AMD הכריזה לפני כשבועיים על מעבדי ה-Ryzen דור רביעי לדסקטופ (מבחינת מספרי הדגמים, הם החליטו לקפוץ מ-3000 ל-5000 לאחר שהם הצליחו ליצור סלט שלם בדגמי ה-4000). בפוסט זה אתייחס הן לדגמי הדסקטופ והן למעבדי ה-EPYC לשרתים שיצאו כבר בקרוב.

מעבדי Desktop לשרתים

מבחינת מעבדי הדסקטופ, ב-AMD ממשיכים להוציא את אותם מספרי דגמים שהוציאו בגירסה הקודמת, בקצה הגבוה נמצא 5950X עם 16 ליבות, 5900X עם 12 ליבות, 5800X עם 8 ליבות ו-5600X עם 6 ליבות, בדיוק כמו שהיה עם ה-3950X, 3900X, 3800X, 3600X, רק שהפעם אין בשלב זה דגמים ללא X כמו שהיו בדגמי ה-3000 (אלו יצאו בשנה הבאה). המחירים – עלו במעט, בממוצע כ-50$ בהשוואה למעבדים מסידרה 3000.

מבחינת ביצועים (שזה כמובן הדבר הכי חשוב למשתמשים) – AMD הציגה עליה משמעותית בביצועים של עד 19% – במיוחד בעבודות Single Threaded, ולראשונה במבחנים סינטתיים – AMD עוקפת את כל המעבדים שאינטל מוכרת בגיזרת הדסקטופ (שוב, בעבודות Single Threaded, ב-Multi Threaded המעבדים של AMD עוקפים ממזמן את המעבדים של אינטל). במבחן כמו Cinebench, מעבד כמו ה-5950X מגיע ל-640 ב-Single Threaded ומעבד 5900X מציג באותו מבחן את המספר 631. לשם השוואה, מעבד ה-10900K מגיע ל-539 באותו מבחן ומעבד כמו ה-Tiger Lake החדש לדסקטופ (דגם: Core i7-1185G7) מגיע ל-598 (אך זהו אינו מעבד לדסקטופ, זהו מעבד למחשב נייד).

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

ישנם לא מעט אנשים שכבר יש ברשותם מעבדי Ryzen והם מעוניינים לשדרג – הנה מספר נקודות לגבי הנושא:

  • אם יש לכם לוח אם מבוסס Chipset כמו X570 או B550 – תוכלו כבר בחודש הבא לרכוש את המעבד, לשדרג את ה-BIOS, להחליף את המעבד ולהמשיך לעבוד כרגיל.
  • אם יש לכם לוח אם מבוסס Chipset כמו X470 או B450 – לרוב הדגמים יצא שדרוג BIOS במהלך חודש ינואר אשר יוסיף תאימות למעבדים החדשים (אך יסיר תאימות ממעבדים ישנים כמו Ryzen מסידרה 1000 ו-2000, פשוט אין מקום בשבב הפלאש לכל העדכונים).
  • רשמית – המעבדים יצאו לשוק ב-5/11. הסיכוי שלכם לרכוש ולקבל מעבד כזה בארץ בתאריך הנ"ל – די טוב (נודע לי לאחרונה כי כבר יש מלאי בארץ, אך המכירה אסורה עד ה-5/11).
  • לאלו שאין ברשותם מעבד Ryzen וחושבים לרכוש (במסגרת בניה עצמית של מחשב) לוח אם ואז את המעבד, אני ממליץ להמתין: בהשקה הרשמית יכריזו יצרני לוח האם על לוחות אם חדשים עם תכנונים משופרים.

חשוב לזכור: כמו שזה נראה כרגע, כנראה שסידרת ה-Ryzen מסידרה 5000 הם "תחנה אחרונה", וכשיצאו מעבדי ה-Ryzen 6000 יהיה צורך בלוח אם חדש וכנראה זכרונות חדשים (DDR5), ולכן אם חושבים להשקיע סכום מהותי ברכישת לוח אם חדש ובמעבד, כדאי לקחת בחשבון שכנראה לא ניתן יהיה לשדרג את המערכת למעבדי Ryzen עתידיים.

מעבדי EPYC לשרתים

באופן רשמי, ב-AMD עדיין לא מדברים/מספרים על מעבדי ה-EPYC מסידרה 7003 (שם קוד: Milan), והדברים יפורסמו באופן רשמי במהלך השבועות הקרובים (אני מאמין שבמהלך נובמבר), אבל עד אז – הנה כמה נקודות מעניינות:

  • שיפור ביצועים משמעותי בהשוואה ל-EPYC דור קודם (7002): כמו ב-Ryzen, גם כאן יש תכנון חדש לזכרון המטמון ברמות 1 ו-2, כך שבפועל ה-Latency נחתך בצורה משמעותית, מה שמתורגם לביצועים גבוהים, כאשר ברוב המקרים מדובר על שיפור דו ספרתי.
  • מבחינת וירטואליזציה – מעבד EPYC דור 7002 (הדור הנוכחי) נתנו מספר יתרונות מבחינת אבטחת וירטואליזציה בהשוואה למה שאינטל נותנים (אינטל תתן פתרון מועתק במשפחת מעבדי ה-Xeon הבאים בשנה הבאה, ע.ע. TME) ולאחרונה התבשרנו כי vSpehre 7 עדכון 1 יתן תמיכה בפונקציות החדשות להצפנת מכונות וירטואליות, דבר שיתקבל בהחלט בברכה במקומות שאבטחה היא במקום הראשון. במעבדי EPYC דור 7003 אנחנו צפויים לקבל עוד מספר שיפורים חדשים באבטחת וירטואליזציה (אם כי מבחינת תמיכה, זה אולי יהיה ב-vSphere 7U2 או בגירסה 8, אך אם משתמשים בוירטואליזציה מבוססת KVM – התמיכה תגיע בחודשים הקרובים)
  • אחת הנקודות שעולות שוב ושוב בפורומים שונים של משתמשי EPYC היא תאימות לאפליקציות שאינטל מבצעת בהם אופטימיזציה, כמו הוספת תמיכה ב-AVX 512. ובכן, בדגמי ה-EPYC החדשים יש תמיכה ל-AVX 512 ולעוד מספר טכנולוגיות ידועות.
  • תאימות לאחור – גם הפעם, יהיה אפשר להשתמש במעבד EPYC מסידרה 7003 על שרתים ישנים יותר (3 דורות אחורה). חשוב לציין כי את התמיכה לכך יש צורך לקבל מיצרן השרתים (בד"כ זה יהיה במסגרת KIT הכולל מעבד חדש או במסגרת עדכונים שהיצרן מוציא לשרתים). כל היצרנים יתמכו בשדרוג ממעבדי EPYC דור 7002 לדור 7003, אולם רק חלק מהם יתנו תמיכה לשדרוג מ-EPYC דור 7001.
  • שיפור ביצועים משמעותי בכל הקשור ללינוקס: ב-AMD הוסיפו פקודות חדשות, והוסיפו שיפורים למהדר כמו GCC (זה נקרא Znver3), כך שאם רוצים שיפורים מעבר לשיפורים שמקבלים כברירת מחדל, אפשר לקמפל עם הפרמטרים החדשים ולקבל ביצועים עוד יותר גבוהים

חשוב לציין: גם כאן, כמו עם מעבדי Ryzen, המעבדים שיצאו יהיו כנראה בחזקת "תחנה אחרונה". ב-AMD עובדים במרץ על EPYC דור 7004 (שם קוד: Genoa) שיתן תמיכה ב-PCIe 5, זכרון DDR5, תמיכה ב-CXL, וטכנולוגיות רבות אחרות, כולל שינוי כל ה"שיחה" בין ה-CPU לכרטיסי GPU (בהצלחה ל-NVIDIA עם NVLINK), ומעבדים אלו לא יהיו תואמים אחורה.

לסיכום: AMD פתחה את הרבעון האחרון של 2020 בהכרזה על מעבדי Ryzen, בהמשך החודש על כרטיסי ה-GPU לדסקטופ, ולאחר מכן יגיעו ההכרזות על מעבדי EPYC לשרתים, כרטיסי GPU לצרכי ML/DL. התחרות בתחומי ה-GPU – בשיאה (NVIDIA כבר הכריזה על הכרטיסים שלה, AMD יכריזו בחודש הקרוב, ואינטל במחצית הראשונה של השנה הבאה) והתחרות בתחום המעבדים תתחיל החודש הבא ואילו אינטל תתן מענה הן בתחילת שנה הבאה (ICE Lake, מעבדים שאני לא ממליץ לרכוש, הואיל ואלו מעבדים שיהיו רלוונטיים אולי במשך חצי שנה) והן במחצית השניה של 2021 שבה היא תציג את מעבדי ה-Sapphire Rapids שיהיו מבוססים ארכיטקטורה חדשה (ביי ביי, Skylake), ויהיו שונים מהותית ממה שאינטל מוכרת כיום, ועם שיפורים מדהימים ורעיונות.. יצירתיים.

תכירו: ESXi למעבדי ARM

בכל מה שקשור לוירטואליזציה, עד היום שלטו ללא עוררין מעבדי ה-X86 ובסקטור ה-Enterprise שולטת ללא עוררין חברת VMware, עם פלטפורמת ה-vSphere. אינטל ו-AMD משקיעות מאמצים רבים בפיתוח ושיפור התמיכה בוירטואליזציה במעבדים (ה-"שוס" האחרון: הצפנת מכונות וירטואליות, דבר שקיים זמן רב במעבדי EPYC ויהיה זמין במעבדים בדור הבא בשנה הבאה במעבדים של אינטל).

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

בעולם השרתים ב-On Prem, כפי שציינתי, מעבדי X86 שולטים, ובשוליים אפשר למצוא גם מעבדי Power של IBM (שתומכים בוירטואליזציה הרבה לפני שאינטל בכלל חשבו על VT-X לדוגמא) ולאחרונה יש יותר ויותר התעניינות גם במעבדי ARM מבחינת הרצת מכונות וירטואליות, קונטיינרים וכו', והפעם מדובר לא רק בגלל המחיר – מספר מעבדים מבוססי ARM לשרתים שיצאו בשנה הבאה הבאה ידעו לתת פייט רציני מבחינת ביצועים גם מול מעבדי Xeon המובילים של אינטל.

ב-VMware היו מודעים לנושא ובשנים האחרונות ישנו צוות שכל מטרתו היה לגייר את קוד ה-ESXi וכל השכבות והחלקים של הפלטפורמה – למעבדי ARM השונים הפופולריים בשוק, וכעת סוף סוף החברה חושפת את המוצר לציבור ומאפשרת הורדה למספר מערכות עם מעבדי ARM שונים:

  • מערכת Raspberry Pi 4 (תצטרכו 8 ג'יגה זכרון, על גירסת ה-4 ג'יגהבייט בקושי תצליח להריץ משהו ותשכחו מ-Raspberry Pi 3 וגרסאות קודמות)
  • מספר מערכות הכוללות מעבדים Ampere eMAG (אין קשר ל-NVidia)
  • Solidrun Honeycomb LX2
  • לוחות המבוססים על LS1046A של NXP (מי שחושב לרכוש ולא מכיר את הלוחות האלו – מומלץ לפני כן לפנות ליבואן של NXP, המערכות שלהם די מורכבות ולא מומלץ לרכוש ישירות מהאתר)

לאלו שכבר רוצים להוריד את ה-ISO – הוא זמין להורדה כאן, רק לפני שרצים להוריד ולהשתמש, אתם מוזמנים לקרוא את ההערות הבאות:

  • הגירסה שזמינה היא נסיונית ומוגבלת בזמן. הגירסה תפעל ל-180 יום ולאחר מכן תצטרכו להקים אותה מחדש.
  • יש קובץ ISO להורדה, אבל בניגוד לגירסת ה-X86, ההתקנה עצמה יותר מורכבת ומי שלא מכיר לינוקס יצטרך להיאזר בסבלנות ולעקוב אחר ההוראות (המעולות) שהם סיפקו. ככלל, ידע בלינוקס מאוד יעזור עם הגירסה הזו (אגב, בגירסה הזו VMWare עושים "אחורה פנה" וחוזרים להיות מבוססי לינוקס)
  • מכיוון שיש עשרות (אם לא מאות) לוחות/SBC מבוססי ARM, רבים יתהו האם ESXi גירסת ARM תרוץ על לוחות אלו. התשובה לכך קשורה בתשובה לגבי הלוח/SBC אם הוא תואם SystemReady SR ופלטפורמת ה-ARM היא V8 ומעלה. אם כן, יש סיכוי שה-ESXi ירוץ. מעבדי ALTRA או Jetson של NVIDIA – לא נתמכים כרגע.
  • מבחינת מערכות הפעלה שניתן להריץ כ-Guest: כרגע אפשר להריץ אובונטו 20, פדורה ועוד כמה הפצות לינוקס. כרגע גרסאות Windows ל-ARM אינן נתמכות.
  • מבחינת Storage – אפשר להשתמש ב-SSD מקומי או לחבר iSCSI. אין תמיכה כרגע ב-NFS.
  • אם אתם מתקינים הפצה בלתי נתמכת וצריך לבחור מהו כרטיס הרשת, זה vmnic128 (לקח לי קצת זמן למצוא את זה)
  • אפשר לנהל את ה-ESXi מ-vCenter כמו כל שרת רגיל – כל עוד אתם משתמשים ב-VCSA 7.0D ומעלה.
  • אם אתם רוצים להריץ כמה וכמה קונטיינרים ומכונות VM – אני ממליץ לרכוש לוח אם או תחנה מבוססת eMAG של Ampere + מעבד, זכרונות וכרטיס רשת שמופיע בתיעוד (לא מלאנוקס וכו')
  • אל תנסו להתקין VMWare Tools דרך ה-vSphere. השתמשו ב-Open VM Tools (קיים לכל ההפצות)
  • יש יכולות של Live Migration, רק שכדאי לשים לב לפני כן להגדרות כרטיס רשת וכו', אחרת אתם עלולים לתקוע את המחשב.
  • אל תחברו ותנתקו ציוד USB מהמחשב, זה יכול לגרום לקריסה.
  • אם אתם רוצים להקים Cluster של ESXi מבוסס Raspberry Pi, אז מומלץ להשתמש ב-HAT ו-PoE במקום ערימת ספקי כח. במסמך של VMWare ל-Pi יש המלצות ספציפיות.
  • אל תנסו להקים VDI על זה 🙂

לסיכום: ESXi על מעבדי ARM יכול להיות פתרון מעולה אם רוצים לנסות מכונות VM שלא מצריכות כח מחשוב מאסיבי, וזה יכול להיות גם פתרון מעולה להרצת קונטיינרים לטסטים/Dev וכו', רק חשוב לזכור שזוהי גירסה ציבורית ראשונה ונסיונית, וחשוב לעקוב אחר ההוראות הניתנות בתיעוד ה-PDF ש-VMware פרסמו.

קונטיינרים ו-Windows – מאמר עדכון (2020)

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

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

וזה חתיכת כאב ראש..

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

העניין הוא שחברות רוצות לא רק קונטיינרים, אלא את כל ה"מסביב", אורקסטרציה, תמיכת Plugins שונים, HA ועוד ועוד – כל מה ש-Kuberentes נותן. את זה לא היה באותו זמן, ו-K8S החל להיתמך באופן רשמי ויחסית יציב – בגירסה 1.14 (אם כי יש תיקוני באגים בכל הקשור לתמיכת Windows ולכן כדאי להסתכל על גירסה 1.17 האחרונה).

בחודשים האחרונים החלו יצרני "הפצות" K8S כמו PKS של VMWare להציע גירסת בטא לתמיכת Windows Containers וגירסת Openshift הבאה תציע זאת גם. אם אתם מתכוננים להיפגש עם נציג של VMWare לגבי PKS, הוא בוודאי יציג לכם מצגת עם שקופית שמזכירה לכם ש-Windows 2008/2008R2 מסיים לקבל תמיכה רשמית השנה ולכן כדאי לנצל את העניין לעבור לקונטיינרים (אכן התמיכה מסתיימת אבל יש שמירה לאחור די רצינית בכל הקשור לתאימות בינארית, כך שאפשר להריץ את אותן אפליקציות ב-Windows 2012/2016/2019, המקסימום – תצטרכו לקמפל מול ספריות סטנדרטיות, כך שהטענה שגירסת OS הסתיימה ולכן עכשיו עכשיו חשוב לעבור לקונטיינרים – לא ממש "מחזיקה מים").

אז מה המצב כיום?

טכנית, אין בעיה להריץ K8S תחת Windows, אך כרגע Windows נתמך כ-Workers Node באופן רשמי ולכן עדיין תצטרכו מכונת לינוקס שתשמש כ-Master. אם אתם רוצים להריץ K8S מהקוד הקיים הפתוח, אתם צריכים לעבור תהליך התקנה די ארוך ומורכב שאפשר לקרוא עליו כאן (יש עוד 2 חלקים בצד שמאל, אל תדלגו עליהם). אם אתם חושבים להשתמש ב-Rancher, גירסה 2.3 תומכת ב-Windows Containers, לגבי השאר – ציינתי לעיל.

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

הדברים החשובים לזכור ולבדוק (אם אתם מריצים K8S ב-On prem):

  • לא לשדרג את ה-Windows אוטומטית. אם מיקרוסופט מוציאה מחר Service Pack או עדכון שמעלה את גירסת ה-Windows (דוגמא: 1709 ל-1903) יכול לשבור דברים בקלות, ויכול להיות מצב שלא תוכלו להריץ קונטיינרים.
  • תמיכת Plugins – ל-K8S יש מאות Plugins שונים בתחומים שונים. ב-Windows רק חלק קטן נתמך ורץ (הם מופיעים בקישור שנתתי בפיסקת תהליך ההתקנה לעיל). כך לדוגמא, חלק מיצרני הסטורג'ים שחררו Plugins ל-K8S בכל הקשור ל-Volumes, צרו איתם קשר לראות אם הם שחררו את ה-Plugins שלהם ל-Windows. כמו כן, תמיכת CSI (כלומר: Containers Storage Interface) היא עדיין ברמת אלפא/בטא.
  • יכול להיות שה-IPS/IDS שלכם לא יאהבו את K8S ל-Windows, הואיל ובחלק מהמקרים נעשים שינויים לפאקטות. כמו כן התמיכה ב-NAT היא קצת בעייתית (תסתכלו בחלק של ה-Networking באותו קישור) – קחו את זה בחשבון לטיפול.
  • קונטיינרים ברמת privileged (אלו בדרך כלל קונטיינרים שמשפיעים על כל ה-K8S) לא יכולים כרגע לרוץ תחת Windows.
  • ניהול זכרון: בלינוקס יש תהליך (שנוא אבל הכרחי) שנקרא OOMKiller שהורג תהליכים בעת מצבים שמסתיים הזכרון. ב-Windows זה אחרת, וברגע שמסתיים הזכרון, המערכת משתמשת ב-pagefile כך שאין משהו שיהרוג תהליכים אם הזכרון מסתיים ולכן יכול להיות מצב שה-Node "יזחל" רק בגלל שאין זכרון. התיעוד מציע מספר אפשרויות, אבל כדאי לעקוב היטב במערכת הניטור לגבי זכרון במכונות Windows המריצות PKS.
  • אם אתם משתמשים ב-Flannel פלאגין לרשת K8S, כדאי לזכור שאין אפשרות לתקשורת בין Node ל-POD.
  • אבטחה – בכל מה שקשור ל-Secrets – דברים נכתבים כ-clear text ב-Node Volume. יש שתי המלצות בתיעוד – או ACL או Bitlocker, שתי פתרונות שלדעתי די עקומים אבל זה מה שיש. בנוסף – האבטחה ל-POD שהפצות K8S שונות מאפשרות תחת לינוקס (SELinux, AppArmor וכו') – לא נתמכות ב-Windows בכלל ויכול להיות שבעתיד יפותח משהו.

כל הנקודות לעיל נלקחו מהמסמך בקישור לעיל והם רלוונטיים לגירסה האחרונה (שברוב המקרים לא כלולה בהפצות K8S השונות), ולכן אני עדיין טוען: התמיכה ב-Windows היא עדיין Work In progress, זה יכול להספיק להריץ דברים פנימית שאינם פתוחים/חשופים לאינטרנט, בסביבות Testing, Staging ואפילו PROD מצומצם, אבל מומלץ לעבור עם מחלקת אבטחת מידע על כל המגבלות במסמך המקורי ולהחליט אלו קונטיינרים ל-Windows להקים ולהריץ ב-K8S, מה ממירים להרצה על לינוקס (כדאי לזכור: בתוך POD אי אפשר להריץ קונטיינרים גם מ-Windows וגם מלינוקס), ועל מה כרגע מדלגים.

לסיכום: K8S ל-Windows, למרות יצרני הפצות K8S שונות, הוא עדיין Work In Progress. יש את כל החלקים הבסיסיים, אבל חסרים לא מעט דברים חיצוניים ויש לא מעט אורות אדומים בכל מה שקשור לאבטחת מידע, ניהול זכרון, Plugins וכו' וכו'. אין שום בעיה ואפילו מומלץ – להקים מערכת K8S ולצוות אליה מכונות Windows לשרת Linux שישמש כ-Master ולהתחיל תהליכי המרה, טסטים והרצות שונות, אבל כשזה מגיע לפרודקשן, ממליץ "לעשות חושבים", גם אם מדובר בהרצת קונטיינרים לפרודקשן במערכות קונטיינרים מנוהלות ע"י ספקי ענן ציבורי.

אבטחת מידע: קצת על Cloud Hopper

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

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

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

אחד הדברים המייחדים את הסינים בכל הקשור לריגול, גניבות, פריצות וכו' – זה הסדר שהם עובדים. אין "קפריזות". יש צוותים (שמוזכרים בקצרה בפוסט של Fox Business) וכל צוות אחראי על משהו אחר: צוות שאחראי על בדיקת הפריצות, על שמות משתמשים וסיסמאות שלא שונו, צוות שאחראי על מיפוי חוזר ונשנה של תשתיות החברות הנפרצות, צוות (גדול) שאחראי על התמודדויות מול אנטי-וירוסים, IPS/IDS, צוות שאחראי על כתיבת סקריפטים וכלים שונים כמו C&C, צוות שבודק פריצות חדשות שלא ידועות ציבורית, צוות שאחראי על קבלת Payload, רישומי דומיינים – ויש בוודאי עוד כמה צוותים.

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

פרויקט Cloud Hopper הוא פרויקט של הפורצים שמימן המשרד לבטחון הפנים הסיני. הקבוצה העיקרית שהיתה אחראית על הפרויקט נקראת APT10 וזו קבוצה סופר מתוחכמת שלא רק מכירה למי הם פורצים, הם בדרך כלל מכירים גם את רמת הידע של חברות שמנסות להגן על הלקוחות נגד פריצות וה-APT10 לא ממש ביישנים: הם יודעים מי מנסה "לצוד" אותם והם משאירים strings בכלים המותקנים על המכונות הפרוצות עם כל מיני הקנטות, כולל רמזים ללמוד איך עובד אנטי וירוס והמעקפים בכך שהם הפנו את ה-C&C לדומיין: gostudyantivirus.com ועוד (הטריק הזה אקסלוסיבי לא רק לסינים כמובן, גם החבר'ה ב-8200 ואחרים משתמשים בו)

קבוצת APT10 במסגרת Cloud Hopper החליטה למצוא לה אי שם ב-2014 מטרה חדשה: ספקי Cloud (או CSP כפי שזה מוכר יותר בשוק), לחדור אל תשתיות ה-CSP, להשיג הרשאות לתשתיות הוירטואליות של הלקוחות ופשוט להיכנס, לגנוב מידע, ולקפוץ (Hopping) מלקוח ללקוח באותה תשתית, כאשר לא מדובר בגניבה חד פעמית אלא מתמשכת.

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

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

על ה-Cloud Hopper תוכלו לקרוא באתרים שונים, אבל אם יש משהו אחד שלא תמצאו שם – זה פריצה לשלושת האמיגוס. אין ספק שתוכלו למצוא מאמרים על פריצות לכל מיני מאגרים שהיו שמורים בתוך S3 Buckets שטיפשים לא הגדירו להם אבטחה מספקת, לתשתיות וירטואליות של לקוחות שהגדרות האבטחה בהן היו בדיחה – אבל לא תמצאו מאמרים על פריצות לתשתיות הפיזיות של AWS, GCP או Azure או לחלקים המאפשרים כניסה לתשתיות וירטואליות של לקוחות, מכיוון שאותה שלישיה בונה את הדברים בצורה שונה לחלוטין, משקיעה הרבה יותר מכל CSP שהחליט שזה אחלה רעיון לקרוא לעצמו "ענן", כולל השקעה בצוותים שאשכרה מנסים לפרוץ בכל דרך מבחוץ פנימה נון סטופ ומיישמים מיידית את הלקחים, במקום לסמוך על כל מיני חומות אש, IPS/IDS ו-MFA (להלן החדשות: רוב שיטות ה-MFA כבר נפרצו עוד לפני שנתיים!).

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

  • Firewall, IPS/IDS, Antivirus, Malware protection, עדכוני אבטחה – כל הדברים הללו נחמדים, אבל פורצים מקצועיים יודעים לעקוף את אותם כלים. אף אחד לא ינסה להיכנס ל-Firewall שלך ולשנות פורטים כי אין צורך בכך, וכל כלי שפורצים כותבים עובר בדיקה מול כל אנטיוירוס מסחרי אם הכלי מתגלה או לא (ואם כן אז משנים את הקוד), ולגבי IPS/IDS – ארמוז בעדינות שיש מספר דרכים לנצל חולשות שלו בתוך ה-LAN, ומדובר על רוב המוצרים המסחריים המצויים בשוק. לא קשה כל כך לזייף ב-Stream פיסות Headers.
  • כמו שמחליפים גירסת לינוקס או Windows, כדאי אחת לתקופה להחליף חלקים גדולים ממערך האבטחה – כלים, מתודות וכו'. תתחילו בשני דברים פשוטים: Zero Trust (זה מה שהשלישיה משתמשים), ו-U2F.
  • אתם מרימים תשתית וירטואלית בענן מקומי? (גם אם זה DR) – אל תתנו לאף אחד גישה ועדיף שזה יהיה על ברזלים ותשתית נפרדת שלכם, ואם צריך קו יעודי לכך שלא מחובר לתשתית של הספק בתוך ה-DC. לחשוב ש-VLAN מגן על משהו – זו בדיחה במקרה הטוב, לא מסובך לפורץ מקצועי להיכנס למתג. רק קחו בחשבון שספקים מקומיים ינתקו לכם את התקשורת אם אתם מותקפים ב-DDoS.
  • אם אתם מקימים תשתית וירטואלית אצל אחד משלישיית האמיגוס, תשתמשו בכלי אבטחה שלהם ולא בכלים צד ג'. הכלים של אותם ספקי ענן ציבורי הרבה יותר רציניים, מעודכנים תדיר (לא רק כשמגלים חור אבטחה וסוגרים אותו כמה ימים אחרי זה כמו אצל רוב הכלים המסחריים!), יכולים לבצע Scaling רציני ומנוסים שוב ושוב על ידי מאות אלפי לקוחות. להגדיר Security Groups ולחשוב שאתם מאובטחים – אתם ממש לא.
  • "התקמצנות" במפתחות פרטים/ציבוריים. רוצים לבצע Passwordless SSH? תשאירו את זה בצורה סופר מצומצמת לצרכי אוטומציה. בשאר המקרים – תקנו Yubikey ותשתמשו בו או מפתח Titan מ-גוגל. אפשר גם 2FA אבל תיזהרו לא ליפול לטריקים כאלו. זיכרו: העצלנות היא הגורם מספר אחד לפריצות קלות.
  • בעננים ציבוריים במיוחד – אף ספק ענן ציבורי לא נותן לך אבטחה כברירת מחדל ולכן תצטרך להשתמש בשרותים שלהם לצרכים אלו, ב-AWS יש רשימה שלמה, תעברו עליה, תבחרו ותגדירו את מה שאתם צריכים (הנה גם ל-Azure, אל תאכלו לי את הראש)
  • אני ממליץ לחשוב מחדש (לכיוון ויתור) על שירותי ניהול מרוחקים. אתם יכולים להגן על התשתית שלכם כמה שתרצו אבל אם עובד משרותי הניהול הוא סופר אהבל ופורצים למחשב הנייד/נייח שלו – ההגנות שלכם לא שוות כלום ומכיוון שיש לו הרשאות admin ברוב המקרים (כי הם מנהלים את התשתית) – יהיו לפורץ את אותן ההרשאות.
  • בדיקות Pen testing זה נחמד, אבל זה עובד מול שורת פריצות ופרמטרים ידועים מראש בתוך הכלי. רוצים להיות יותר בטוחים שאתם מוגנים? תשכרו מישהו שאשכרה ינסה לפרוץ בצורות קצת יותר .. מקוריות.

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

עננים ציבוריים מקומיים מול עננים ציבוריים אמיתיים

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

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

נדמיין עתה מצב תיאורתי שבו החלטתי להתחרות בכולם. אני משיג VC נחמדים ומשכנע אותם להשקיע בעסק שלי סכום נחמד של 8 ספרות (בדולרים). אני רוכש כמה עשרות ארונות, מפזר אותם בין ספקי האינטרנט השונים בארץ, "מפוצץ" את כולם בשרתים חדשים ואני מקים בדרך SDN ו-Software defined storage מפלצתי. על כל התשתית הזו אני מקים מערכת שתתן ללקוחות דרך ממשק WEB ודרך API את השרותים הבאים:

וירטואליזציה, קונטיינרים (עצמאית, ללא צורך בהקמת מכונות וירטואליות), Serverless, הקמת "ברזלים" יעודיים ללקוח, שרותי Object Storage ו-Block Storage, שרותי NFS/CIFS יעודיים לרשת שלך בלבד, שרות רשת פרטית משלך (כמו VPC), שרותי Load Balancer, שרותי DNS, שרותי identity, שרותי Imaging למכונות VM שלך, שרותי אורקסטרציה, שרותי Messaging, שרותי התראות, שמירת משאבים וחלוקתם על ידי הלקוח, אורקסטרציית קונטיינרים, ביג דאטה, שירותי גיבוי, שחזור ו-DR, תאימות ל-EC2 (כפרוקסי), מטריקות, ניטור מלא של הכל, שרותי Event (כמו Cloud trail), שרותי Governance ושרות יחודי של Benchmarks, וכמובן – שרותי Billing ו-Chargeback – וכל זה זמין ביום הראשון. תירשם, תכניס פרטי כרטיס אשראי וצא לדרך.

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

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

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

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

לסיכום, אני ממליץ לחשוב על 2 דברים חשובים:

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

כמה מילים על קונטיינרים "מבחוץ"

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

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

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

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

הפצות לינוקס כמו רד-האט, CentOS, SuSE, אורקל לינוקס, דביאן, אובונטו וכו' – נבנית בכל פעם מאפס על ידי הידור קוד של חבילות שונות עד שנבנית הפצה בסיסית לחלוטין. להפצה הזו המערכת תעשה Boot, ומשם היא תמשיך להדר את הקוד של כל החבילות שונות (ב-רד-האט, או כל הפצה מבוססת RPM יש חבילות מיוחדות שנקראות SRPM שמכילות קוד מקור + טלאים וסקריפטים כדי לקמפל אותה). ההפצה כוללת חבילות שונות מבחוץ שעברו בתוך יצרן ההפצה בדיקת קוד וברוב המקרים גם שינויים על מנת לרוץ על אותה הפצת לינוקס ספציפית.

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

בחברות גדולות (כמו בנקים וכו') בדרך כלל לא פותחים את חומת האש להורדת חבילות מיצרן ההפצה באופן ישיר ומשתמשים בתוכנת-אמצע (Middleware) כמו Red Hat Satellite כדי להתקין את ההפצות ועדכונים על שרתים ומחשבים נוספים. ברוב המקומות האחרים שאינם עובדים ישירות מול רד-האט או עובדים עם הפצות אחרות, יש כלי אחר חינמי ובקוד פתוח כמו SpaceWalk שמאפשר להפיץ פנימית בשרתי החברה (ובחשבון הפרטי בענן הציבורי של החברה) עדכוני תוכנה בצורה מאובטחת ומוצפנת (אפשר לשלב בתוך הכלי גם את ה-CA של החברה).

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

איך? די פשוט. כמעט בכל קונטיינר שמופיע ב-Repository ציבורי (כמו Docker Hub) אנחנו נמצא קישור ל-Github שמכיל את קוד ה-Dockerfile. נוריד את קבצי ה-Dockerfile ואחרים מה-git (פקודת git checkout) ואז פשוט נבנה את הקונטיינר מחדש. היתרון הגדול בבניית הקונטיינר מחדש הוא בכך שחבילות רבות מקבלות עדכוני אבטחה וקונטיינרים הזמינים ב-repo ציבורי לא תמיד מעודכנים, וכך נוכל לבנות אותם עם הגרסאות המעודכנות עם תיקוני אבטחה ומה שיותר חשוב – החבילות מגיעות ממקום ידוע (אם משתמשים ב-spacewalk – אז הם מגיעים משרת פנימי בחברה שהוריד את החבילות ממקור בטוח), ואפשר כמובן לאחסן את אותם קונטיינרים ב-Registry פרטי פנימי (הנה הוראות איך להקים אחד באובונטו).

במקרים מסויימים ה-Dockerfile כולל פקודת COPY וקבצי המקור אינם נמצאים ב-repo באותו git. התייחסו במשנה זהירות לקונטיינרים מסוג זה, ובמקרים כאלו אם אתם ממש צריכים את הקונטיינר הספציפי, אולי כדאי להריץ עליו סריקה עם אחד הכלים שהזכרתי לעיל.

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

הפתרון למעבר מ-VM לקונטיינר: Kubevirt

(הערה: לפני כשנתיים כתבתי את הפוסט הזה על Kubevirt. מאז דברים רבים השתנו ופוסט זה הוא פוסט עדכון לכלי).

כל מי שהתחיל ומשתמש בקונטיינרים, Kubernetes וכו' – מבין בוודאי שקונטיינרים אינם מכונות וירטואליות. בניגוד ל-VM, קונטיינר מקבל שרותי OS ממערכת ההפעלה המותקנת על ה-VM (או על הברזל) שמריץ את הקונטיינר, ולפיכך קונטיינרים ברוב המקרים הם דברים די קטנים בהשוואה למערכת הפעלה מלאה שמותקנת ב-VM, גם כשהיא מותקנת כ-Minimal.

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

ישנם גם מקרים שאי אפשר להמיר מכונת VM לקונטיינרים חדשים. מקרים כמו:

  • האפליקציה רצה ומבוססת על Windows
  • האפליקציה רצה על גירסת לינוקס מאוד ישנה
  • האפליקציה רצה על מערכת הפעלה שאינה מבוססת לינוקס
  • ה-VM נבנה ע"י מומחה חיצוני ולאף אחד אין מושג ירוק איך הדברים מוגדרים ב-VM (לדוגמא: Cobol ישן)

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

וכאן נכנסת לתמונה אפליקציית Kubevirt.

אפליקציית Kubevirt מרחיבה בעצם את Kubernetes/OpenShift ומוסיפה למערכת תמיכה בקונטיינרים מסוג נוסף: קונטיינר שמריץ VM. כך בעצם אפשר לקחת VM מהדוגמאות לעיל ו"להכניס" אותו לתוך קונטיינר, כך שנוכל להריץ אותו כמו שאנחנו מפעילים קונטיינרים נוספים, ובכך נוכל להשתמש באפליקציה שרצה ב-VM, נוכל לשכפל את הקונטיינר לפי פרמטרים שנרצה, נוכל לשדרג את הקונטיינר ועוד ועוד.

מאחורי הקלעים, מה ש-Kubevirt עושה, הוא להשתמש ב-KVM (הוירטואליזציה המצויה בכל לינוקס) ובספריית Libvirt וספריות נוספות בכדי ליצור POD ובתוך ה-POD להריץ VM. את אותו VM אנחנו נגדיר בעזרת קבצי YAML, כמו שמגדירים כל דבר ב-Kubernetes, וכך נוכל להגדיר כמות זכרון, היכן הדיסק הוירטואלי יושב, האם ה-VM יהיה בעצם Immutable (כלומר שכל שינוי ל-VM ימחק ברגע שה-VM "כובה"), ועוד פונקציות נוספות. הגישה ל-VM תוכל להתבצע בכלים הרגילים (SSH, RDP) או VNC וחיבור סריאלי וירטואלי (במקרה שמדובר בלינוקס או כל מערכת תואמת UNIX אחרת).

מכיוון שב-Kubernetes אפשר להשתמש בכל מיני "דרייברים" (Storage Classes, Volumes), נצטרך להמיר בשלב ראשון את הדיסקים הוירטואליים של ה-VM מהפורמט הנוכחי (VMDK ב-vSphere) לפורמט ש-KVM ו-libvirt יכולים להבין ולהשתמש. סוג הדיסק שאנחנו נצטרך יהיה RAW וכלי ההמרה (שצריך לרוץ תחת לינוקס) הוא virt-v2v (זה קצת יותר מורכב ממה שהקישור מראה). מהרגע שביצענו זאת, אנחנו "מנתקים" בעצם את ה-VM מהוירטואליזציה הנוכחית (נניח vSphere), אבל ה-VM עדיין נשאר ב-vSphere. ברגע שיש לנו את הקובץ בפורמט RAW, נוכל להשתמש בכלי כמו CDI כדי לבצע Import של ה-Image לתוך Volume שנגדיר. אחרי שהצלחנו (שוב, לא דבר כל כך קל, אלא אם אתם משתמשים ב-Openshift דרך ה-WEB UI), אנחנו נגדיר POD עם ה-VM ושם אנחנו נבחר דברים כמו כמות זכרון, מערכת הפעלה, וכו'. בזמן ההגדרות נוכל להוסיף דיסקים וירטואליים חדשים ל-VM ועוד. לאחר שהתהליך מסתיים ונפעיל את ה-VM, תופיע כתובת IP שדרכה נוכל להתחבר אל ה-VM.

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

  • Kubevirt עובד על כל גירסת Kubernetes מ-1.10 ומעלה, ו-OpenShift 3.11 ומעלה.
  • בשביל לקבל ביצועים טובים עם ה-VM, יש צורך בתמיכת Nested Virtualization (אם ה-Kubernetes שלכם רץ כמכונה וירטואלית).
  • עננים ציבוריים: אם אתם רוצים להריץ Kubevirt על ענן ציבורי, תצטרכו לבחור Instances שכוללים תמיכת Nested Virtualization. גם לאז'ור וגם לגוגל יש מכונות כאלו, ב-AWS אין ולפיכך ב-AWS מכונות VM כאלו ירוצו יותר לאט מאחר ומדובר באמולציית X86-64 בתוכנה.
  • דיסקים וירטואליים: מכיוון שאין Thin Provisioning בשיטה כזו, הווליומים יהיו גדולים (כמה שהגדרתם ב-VM בהתחלה תחת vSphere), לכן אם הגדרתם את ה-VM עם דיסק של 100 ג'יגה אבל השתמשתם רק ב-15 ג'יגה, הקטינו את הדיסק (הוראות נמצאות כאן אם מדובר ב-vSphere).
    נקודה נוספת חשובה לגבי דיסקים וירטואליים: אפשר לצרף אותם ישירות ל-Image של הקונטיינר אך הדבר אינו מומלץ (אלא אם אתם רוצים להפיץ את ה-Image החוצה).
  • קישוריות ל-VM ותקשורת: במקור כברירת מחדל יש ל-VM חיבור רשת יחיד. יחד עם זאת ניתן להשתמש ב-Multus או Genie כדי להוסיף דברים רבים הקשורים לרשת: VLAN, Bridges, אפילו PXE Boot – תשתוללו חופשי.
  • ניתן לשכפל את ה-VM לפי כל פרמטר שתרצו כדי לעמוד בעומסים. לשם כך תצטרכו להגדיר בקובץ YAML את ה-AccessModes לפי הצרכים שלכם.
  • KVM – מכיוון שה-VM שלכם ירוץ תחת KVM, כדאי להכיר את KVM. תרימו מכונת לינוקס, תפעילו Nested Virtualization ותריצו את Virt Manager (נקרא גם VMM). יש המון פונקציות והגדרות וכדאי להכיר אותם לפני כן, אחרת תקבלו הפתעות (במיוחד אם מכונת ה-VM שלכם משתמשת ב-UEFI. יש תמיכה ל-UEFI אבל תצטרכו להגדיר כמה דברים לשם כך).

רוצים לשחק עם זה פה ועכשיו מבלי להקים Kubernetes שלם? בשמחה! כנסו ללינק הזה ואתם מוזמנים לאחר מכן להיכנס ללינק הזה כדי להכיר את לשדרג מכונות VM בתוך קונטיינרים.

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

לסיכום: אם אתם רוצים לעבור לקונטיינרים והדבר היחיד שמפריע זה מכונה אחת (או מספר מכונות) שבעייתי להמיר אותן ידנית לקבצי Docker Images ושירוצו כקונטיינרים טבעיים, Kubevirt יכול לסייע בכך. חברות כמו SAP, nVidia, Cloudflare כבר משתמשות ב-Kubevirt. חשוב לציין: Kubevirt עדיין לא מוגדר כגירסה סופית (מצד שני, גם Kubernetes לא מוגדר כך). אם אתם משתמשים ב-OpenShift מגירסה 3.10 ומעלה (גם בגירסת OKD – גירסת הקוד הפתוח) – קל מאוד לשלב את Kubevirt והחל מגירסה 4.2 – ה-Kubevirt יהיה חלק אינטגרלי (בגירסה הנ"ל תוכלו להתחבר ישירות ל-vCenter ולהמיר את ה-VM בכמה קליקים).
מיקרוסופט וגוגל כבר מזמן הבינו שאם רוצים למשוך את הלקוחות אליהם כדי שישתמשו בשרותי ה-Kubernetes שלהם, צריך לעזור ללקוחות בכך שיציעו המרה של מכונות VM להרצה בתוך קונטיינרים, וזה יהיה כנראה ה"גל" הבא.

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

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

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

בעבר, לאלו שעובדים כשכירים, בתחום ה-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.