קצת על Guacamole, כניסה מורשית ואבטחה

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

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

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

הנה שיטה שאני משתמש בה ואולי היא יכולה להיות ישימה גם אצלכם.

קצת רקע: עבדכם הנאמן נותן שרותי יעוץ ואינטגרציה למגוון פלטפורמות. חלקן פופולריות ומוכרות (כמו vSphere) וחלקן קצת פחות – כמו oVirt, OpenShift, OpenStack, Ceph, Gluster, Kubernetes (ויש עוד לא מעט תוכנות) וכמובן מערכות לינוקס שונות. כל המערכות הללו רצות נון סטופ אצלי ב-LAB מסיבות שונות:

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

וכאן אולי אפתיע אתכם: אני לא משתמש ב-VPN או תוכנות שליטה מרחוק מבחוץ. זה לא בעיה של רשיונות או בעיה של התקנת VPN.

אני משתמש ב-Guacamole.

למי שלא מכיר, Guacamole היא אפליקציית Java שרצה תחת Appplication Server כמו Tomcat או Wildfly (או JBOSS) המאפשרת חיבור מכשירים, תחנות ושרתים לממשק Web מאוחד, הגדרת משתמשים והרשאות וכניסה דרך הדפדפן לתוך כל חיבור. יש כמובן מספר תוכנות כאלו שנמצאות בכל חברה המאפשרות להתחבר ב-SSH/Telnet/RDP/VNC, רק שאת Guacamole לא צריך להתקין על כל מכונה. מספיק שיש דפדפן סטנדרטי ומודרני.

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

  • הראשון הוא עניין TOTP (כלומר Time-based One-time Password) – כך שמי שמתחבר מבחוץ יצטרך להשתמש ב-MFA בכל פעם שהוא מתחבר (בנוסף לשם משתמש וסיסמא)
  • הגישה שהוא מקבל – היא למכשיר/מכונה אחת או יותר שהוא צריך. אם הוא ינסה להיכנס למכונות אחרות – אני יוכל לראות זאת.
  • המכונה שהוא ניגש אליה – שמורה ב-snapshot ב-ZFS כך שאם הוא יגרום נזק, אפשר תוך שניות ספורות לחזור אחורה.
  • וכמובן הכל מוקלט – ל-Guacamole יש אפשרות "הקלטת session" שמקליט כל מקש שהמשתמש מבחוץ מקיש ומה הוא רואה על המסך, כך שאני יכול לראות בזמן אמת מה הוא מקיש ומאוחר יותר אני יכול להמיר את ההקלטה לקובץ MP4 כדי לראות בבירור מה בוצע במכונה.
  • מכונות קריטיות ב-LAB – אינן זמינות דרך ה-session.
  • הגישה מבחוץ זמינה רק לאחר שהפעלתי זאת. כברירת מחדל, אין גישה מבחוץ לשום דבר.

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

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

    • מקימים מכונת VM עם לינוקס ועליה מתקינים את Guacamole ומוסיפים את תוסף ה-TOTP (לחובבי אובונטו, יש בלינק הזה סקריפט מוכן להתקנת האפליקציה באופן אוטומטי)
    • מגדירים משתמשים (אפשר לחבר את זה ל-Active Directory לפי ההוראות בקובץ PDF זה. זה קצת מורכב) ומגדירים סשנים למכונות או ציוד שיש צורך בגישה אליהם. שימו לב – כל סשן למעט עם חיבור VNC מתנתק ברגע שסוגרים את ה-TAB, כך שאם רוצים להשאיר דברים רצים בלינוקס לדוגמא, אפשר להשתמש ב-nohup או להשתמש ב-screen או TMUX.
    • מגדירים אלו סשנים יהיו זמינים לאלו משתמשים
    • על מנת שסשן יוקלט, בכל הגדרת חיבור יש בסוף הדף הגדרות להקלטה. בד"כ יספיק path ושם כלשהו כדי להפעיל את ההקלטה (ההקלטה תישמר בתוך שרת ה-Guacamole, לא במכונה שמתחברים אליה דרך ה-Guacamole). חשוב לזכור, ההקלטה היא בפורמט דחוס שיש צורך בהמרה, ואותו כדאי לשמור בסטורג' או ב-NAS כך שמומלץ לחבר את שרת ה-Guacamole לאיזה NFS share על מנת לשמור הקלטות לעתיד לצרכי אבטחת מידע. כל הקלטה כזו ניתן מאוחר יותר להמיר לקובץ MP4 על מנת שלא לתפוס יותר מדי מקום באחסון.
    • ב-Firewall מגדירים Static NAT בין IP חיצוני ל-IP פנימי שמריץ את ה-Guacamole. את החוק הזה מכבים ומפעילים לפי צורך. (למתוחכמים – אפשר לכתוב סקריפט פשוט שמשתמש ב-CURL ומתחבר ל-API של ה-Firewall על מנת להפעיל/לכבות את החוק הספציפי).

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

טיפ: כשרוצים להוסיף דיסקים SSD מקומיים בשרת

בעולם השרתים, יש סוג מסוים שמיועד לאינטגרטורים ולא ללקוחות קצה. הקטגוריה של השרתים הללו נקראת "שרתי Tier 1".

בניגוד לשרתים רגילים שרוכשים מ-HP/לנובו/DELL ששם אתם מקבלים שרות מהקצה עד הקצה, בשרתי Tier 1 אתה מקבל אפס תמיכה טכנית (הדבר היחיד שכן מוכנים לעשות עבורך הוא להחליף ציוד תקול) והתשובה הקבועה שתקבל מהתמיכה הטכנית היא משהו כמו: זה שרת Tier-1, אין תמיכה טכנית, כך שאם מישהו רוצה לרכוש שרת כזה, עדיף שיכיר היטב איך לזהות חולשות ובעיות תכנוניות של לוח אם, איוורור, נתיבי PCIe מבחינה לוגית (לא רק פיזית) ועוד, אחרת בקלות אפשר לרכוש "פיל לבן". כך לדוגמא השרת בתמונה למעלה היה אמור להירכש על ידי חברה מסויימת בארץ – למטרת הקמת "סטורג'" מאוד מהיר (כל הדיסקים שנכנסים מקדימה הם SSD NVME בלבד). הם פנו לכל מיני אינטגרטורים שנתנו המלצה חיובית לרכישה ואז הם פנו אל עבדכם הנאמן דרך בלוג זה והמלצתי היתה שלא לרכוש מהסיבות הבאות:

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

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

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

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

טכנית, אני ממליץ לרכוש מיצרן השרת דיסקים SSD מבוססי SATA ולא SAS מכיוון ש-SATA Enterprise עבר כברת דרך ארוכה באמינות, ויתרון הערוץ הכפול לא רלוונטי בשרתים מודרניים הואיל ובקר ה-RAID הראשי מוטמע בלוח האם, כך שאם יש תקלה, השרת מושבת בכל מקרה. מבחינת ביצועים – כיום SATA עוקף SAS (ב-SSD).

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

יש לכם כבר 8 ורוצים להוסיף עוד? סביר להניח שתצטרכו בנוסף לדיסקים SSD לרכוש "Extension Kit" לשרת עצמו. אצל חלק מהיצרנים מדובר על מספר כבלים וכרטיס SAS Expander שאותו יש לחבר אל כניסות בקר ה-RAID ומה-SAS Expander לחבר את כל הכבלים אל ה-Backplane. יש מקרים שאתם תצטרכו לעשות זאת ויש מקרים שטכנאי מטעם היצרן יבוא ויעשה זאת (תלוי בחוזה שלכם מול יצרן השרתים). אם מדובר לעומת זאת בשרת ישן (נניח G7/G8 של HPE או R710/R720 של DELL או M2/M3 של IBM) – תהיה לכם בעיה כלשהי, ההסבר לגביה – בהמשך הפוסט.

יהיו מקרים, כמובן, שבחברה מסויימת ירצו להרחיב מעבר ל-16 דיסקים. במקרים כאלו בדרך כלל היצרן ימכור ללקוח כרטיס SAS Expander בערך כמו שיש פה בתמונה משמאל שמאפשר חיבור של 24 דיסקים. מבחינת חיבוריות – אין שום בעיה לחבר את הכל כמו במקרה של הרחבה מ-8 ל-16.

הבעיה – צוואר בקבוק.כמעט כל בקר RAID, בין אם מדובר בכרטיס ובין אם מדובר בשבב שנמצא על לוח האם, תופס 8 נתיבי PCIe (כלומר PCIe X8) ו-PCIe 3.0 X8 (שנמצאים בשרתים מודרניים) יכול להעביר ברוטו עד 8 ג'יגהבייט (קצת פחות בפועל). אם נזכור ש-SSD כשקורא נתונים – מעביר אותם במהירות של 450-550 מגהבייט לשניה, ונכפיל את זה כפול כמות ה-SSD בשרת (אני לא ממליץ על RAID-5 כמו שכתבתי לעיל, אבל מי באמת מקשיב?) – ואנחנו יכולים להגיע למצב שבקר ה-RAID "יחנק" עוד במצב של 16 דיסקים. אם כל הדיסקים (24) מחוברים ל-RAID והמערכת מוגדרת כ-RAID-5 על כל הדיסקים – הביצועים פשוט יצנחו בכל מה שקשור לקריאת נתונים. המצב חמור יותר בשרתים ישנים ששם בקר ה-RAID משתמש ב-PCIe 2.0 X8 שאז יש מחצית מרוחב הפס והבקר "יחנק" מ-8 דיסקים SSD אם המערכת קוראת וכותבת מכל הדיסקים במקביל.

לכן – אם מתעקשים להכניס לדוגמא 24 דיסקים SSD בשרת אחד (או בשרת ישן לעבוד עם יותר מ-8 דיסקים SSD), יש לשקול את האפשרויות הבאות:

  • להוסיף בקר RAID עם 2 כניסות SFF 8087 ולחבר אליו את ה-8 דיסקים SSD (אחרי 16). בשרתים ישנים אפשר לרכוש 2 בקרי RAID עם 2 כניסות SFF 8087 ולחבר אליהם את הדיסקים. החסרון בשיטה זו: אין RAID "המשכי" לכל הדיסקים, אבל גם לכך יש פתרון, המשיכו לקרוא.
  • לעצור ב-16 דיסקים.
  • לרכוש במקום בקר RAID – כרטיסי HBA (או כרטיס RAID במצב IT MODE) ולהקים RAID מבוסס תוכנה (כל מערכת הפעלה מאפשרת זאת, ויש גם תוכנות יעודיות לכך כמו FreeNAS, UnRaid, XPEnology ועוד). שימו לב – החלפת בקרים אינה דבר מומלץ ואינו נתמך רשמית על ידי יצרני השרתים.
  • לפצל לשרתים נפרדים. 2 שרתים עם 8 דיסקים SSD יתנו עבודה יותר מהירה.

לסיכום: זה שיש 24 מקומות לדיסקים SSD בשרת, לא אומר שהשרת באמת בנוי להפעיל 24 דיסקים SSD (ובשרתים ישנים – יותר מ-8 SSD במקביל, גם אם מדובר בבקר עם 4 כניסות SFF-8087), בדיוק כמו שרוב מוחלט של השרתים שנמכרים לחברות לא יכולים להפעיל 24 דיסקים SSD NVME (אל תנסו. תכנון הקירור, גם בדגמים הכי חדשים של DELL/HPE/לנובו לא מתאים לכך). עדיף לחלק את הדיסקים בין 2 מכונות פיזיות, ואם אתם מתעקשים "להפציץ" מכונה אחת בדיסקים SSD – עדיף לייעד אותה לשימוש כ-NAS עם מפרט נמוך ולהריץ את הדברים הדורשים ביצועים בשרת אחר.

המלצות וטיפים לגבי רכישת ציוד ל-AI/Deep learning

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

אז אני קודם כל רוצות להודות לחברת CRG שהשאילה לי ציודים (כרטיסי GPU ומכונות) כדי לבדוק פה ב-LAB את הדברים לפני שאני כותב את הפוסט הזה.

נתחיל במקרים פשוטים ונמשיך ביותר מורכבים.

תחנות עבודה
בלא מעט מקרים יש צורך בתחנות עבודה למפתחים ואחד הדברים שצריך להחליט הוא כמובן סוג ה-GPU וכמה כרטיסי GPU. במידה ומדובר בכרטיס אחד ולא ממש מחפשים ביצועים אלא יותר לנסיונות – מומלץ לרכוש כרטיס כמו RTX 2080 או RTX 2080TI, אך לא מומלץ לרכוש RTX 2070 ומטה. הסיבה לכך שכרטיסים כמו RTX 2070 ומטה אינם כוללים חיבור NVLINK (שהוא חיבור מהיר בין הכרטיסים – 100 ג'יגהביט לשניה) כך ש-2 כרטיסי RTX 2070 יעבדו יותר לאט בהשוואה לכרטיסים כמו RTX 2080 או RTX 2080TI עם חיבור NVLINK ביניהם (ניתן לחבר מקסימום 2 כרטיסים). אם מעוניינים בכרטיסים יותר מהירים אך עדיין לא להיכנס לתחומי ה-Quadro וה-Tesla, ניתן לרכוש את ה-Titan RTX.

כמות ה-GPU המקסימלית המומלצת בתחנת עבודה היא עד 3 ויש לכך מספר סיבות:

  1. אם רוצים לעבוד מקומית על התחנה (הכוונה לחבר אליה מסך מקלדת ועכבר), יש צורך ב-GPU כמו RTX כדי לחבר אליו מסך. בחלק מתחנות העבודה יש חיבור VGA אולם זהו חיבור שמיועד לניהול התחנה מבחינת סיסטם ולא לעבודה רציפה (העבודה כדסקטופ לינוקס גרפי תהיה איטית, ויש פה ושם מספר באגים בקוד התצוגה של שבבי הניהול).
  2. הכרטיסים הללו מפיקים המון חום וצריכת החשמל גבוהה – עם 4 כרטיסי GPU ו-2 מעבדים מגיעים בקלות ל-1400 וואט ומעלה.
  3. זה מרעיש.
  4. לפעמים צריכים את התושבת להכנסת ציוד אחר – כרטיסי רשת 10 ג'יגה, חיבור לסטורג' ועוד.

בקיצור – צריכים להכניס מעל 3 כרטיסים לצורך AI/DL? תחשבו על שרתים.

לרכוש כרטיסי TESLA?
כרטיסי ה-Tesla הם כרטיסים מאוד יקרים. החסרון שלהם בהשוואה לכרטיסי RTX היא המהירות שהם עובדים (בערך חצי ממהירות השעון בהשוואה לכרטיס RTX 2080TI), אבל היתרון שלהם הוא בכך שיש להם זכרון בדרגה גבוהה יותר (ECC), אחריות יותר ארוכה, ויותר זכרון מכרטיסי RTX (למעט RTX TITAN שמכיל 24 ג'יגה זכרון בהשוואה ל-11 ב-RTX 2080TI) וניתן לשרשר אותם כדי לקבל מהירות תעבורת נתונים מאוד גבוהה (למעט כרטיס Tesla T4 שאינו כולל NVLink).

שרתים לצרכי AI/DL
כל יצרן שמייצר שרתים (כולל כאלו שפחות ידועים כמו ASUS ו-PNY) מייצר שרתים מיוחדים למטרה זו. המפרטים מגוונים ומבחינת גדלים – מתחיל ב-1U ונגמר גם ב-20U. הפופולריים בד"כ הם 2U או 4U. בדרך כלל ב-2U תוכלו להכניס עד 4 כרטיסים וב-4U תוכלו להכניס (תלוי בדגם וביצרן) עד 16 כרטיסי GPU Dual Slot. בשרתי 1U-2U לא מומלץ להכניס כרטיסי GTX/RTX מכיוון שבעת עבודה רצינית, האיוורור שמגיע דרך המפוח אינו מספיק חזק ולפיכך ה-GPU מאט את פעילותו ומהירות השעון יורדת. כרטיסים כמו Quadro (שאגב, הוא פחות מתאים ל-AI/DL, הוא יותר לתלת מימד ווידאו) ו-RTX לפיכך יותר מתאימים לתחנות עבודה ואילו הכרטיסים לשרתים אינם כוללים מאוורר.

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

לינוקס וכרטיסים ל-AI/DL
באופן עקרוני, הורדת גירסת ה-CUDA מאתר nVidia (בגירסת הקובץ run) מכילה בתוכה כבר את הדרייבר היציב שתומך בכל הכרטיסים, כך שאין צורך להתקין בנוסף דרייבר של nvidia. יחד עם זאת, שימוש במעבד הגרפי הפנימי של אינטל או בממשק הניהול של המכונה בתצורה גרפית והתקנת ה-CUDA יכולים ליצור קונפליקטים שלא יאפשרו למכונה יותר להיכנס למצב גרפי. ניתן בהתקנת ה-CUDA לבטל התקנת OpenGL, אך לפעמים גם זה אינו עוזר (במיוחד כשיש שבב ניהול במכונה של ASpeed) ולכן חשוב להתקין את הפצת הלינוקס ללא סביבה גרפית אלא טרמינל בלבד. אם מעוניינים לעבוד עם שרת מרחוק ובכל זאת רוצים להשתמש בסביבה גרפית, עדיף להתקין תוכנה כמו NX Server של חברת NoMachine או להתקין VNC. אם אתם צריכים גם סביבה גרפית וגם להשתמש בדברים כמו TensorFlow עם OpenGL, מומלץ לרכוש את Nomachine Workstation שכוללת קידוד חומרה של H.264 כך שהדסקטופ הגרפי המרוחק יהיה מהיר מאוד עם תצוגה מעולה.

תחרות
זה לא סוד שכרטיסי Tesla של nVidia החזקים ממש לא זולים וגם כשחברות גדולות מעוניינות לרכוש והם מקבלים את הצעת המחיר – יש לפעמים היסוסים ומעוניינים לשמוע הצעות אחרות. גם ל-AMD יש מה להציע בתחום, אולם אינה ההחלטה כה פשוטה של אי רכישת Tesla ובמקומה לרכוש Instinct של AMD. יש עוד פרמטרים לקחת בחשבון (סוג ה-FP למשל). יש כמובן גם מקרים שרוצים להכניס מספר גדול של כרטיסי RTX בשרת, האם זה עובד? יעיל? על כך אפרסם פוסט בקרוב.

בניה עצמית
בלא מעט מקרים רוצים להשמיש ציוד קיים ופשוט רוצים לרכוש את הכרטיסים ולהכניס אותם פנימה לשרת או תחנת עבודה שקיימת בחברה. אחרי הכל – תושבות פנויות יש, אז פשוט נרכוש ונגמור עניין.
וכאן צצה בעיה: לא כל תושבת PCIe X16 היא באמת כזו. בחלק מהמקרים החיבור הפיזי הוא X16 אולם אם יש כרטיס נוסף במחשב, החיבור ירד מבחינה אלקטרונית ל-X8, ואם מכניסים GPU נוסף (שלישי) אותו חיבור ירד ל-X4. בניקוד למשחקים ועריכת וידאו, ב-AI/DL מהירות ה-PCIe חשובה (גם אם אתם משתמשים ב-NVLink – החומר צריך לעבור דרך ה-CPU) ולכן רק לוחות מסויימים או תחנות עבודה מסויימות שכוללות במפרט נתיבי X16 אלקטרוניים (ויותר מתושבת אחת, ובלי "תנאים") יכולים להתאים לכך.

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

עדכון ליבה בשרתי לינוקס – ללא Reboot

כשזה מגיע לתחזוקת שרתים, אחד הדברים שאנשי IT פחות אוהבים – הוא עניין העדכון. כשזה מגיע לשרתים שמריצים Windows Server, אתה לא תמיד תדע אם העדכון באמת עבר בדיקות איכות רציניות ומיקרוסופט "נתפסת" שוב ושוב עם בעיות עדכונים ששוברות תאימות. מילא זה – הבעיה הכי גדולה היא שבמקרים רבים – צריך לעשות Reboot ואינך יכול לדעת בוודאות של 100% שהמכונה תעלה והכל יפעל כשורה.

בלינוקס – ברוב המקרים אינך צריך לעשות Reboot לשרת גם לאחר שביצעת עדכונים. במקרה הכי גרוע אתה פשוט יכול להפעיל מחדש את השרותים שרצים על השרות – לאחר התקנת העדכונים. חברות כמו רד-האט ו-SuSE עושות את הכל כדי לשמור תאימות בינארית של 100% כך שקונפיגורציות ודברים אחרים פשוט אינם משתנים (ב-2 ההפצות, כשמתקינים גירסה חדשה של תוכנה על הגירסה הישנה, המערכת תייצר קבצי rpmsave באותה תיקיה שנשמרות בה ההגדרות של האפליקציה, כך שתוכל לראות מה השתנה).

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

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

לאחר זמן מה יצאה רד-האט עם kpatch וחברת SuSE יצאה עם Live patching. קנוניקל לא נשארה מאחור והם הכריזו על שרות שנקרא livepatch.

כל השרותים לעיל – הם בתשלום בלבד, כלומר העדכונים צריכים לעבור דרך מערכת עדכונים מורשית של ההפצה בלבד. לא מדובר באיזו חבילת RPM או DEB שאפשר להוריד ולהתקין חופשי על כל השרתים בחברה. ב-רד האט יש צורך לעשות זאת דרך שרות Satellite וב-SuSE דרך SuSE Manager. באובונטו נותנים בונוס למשתמשים – מי שנרשם, יכול לעדכן דרך שרות livepatch עד כ-3 מכונות דסקטופ בלבד (לא שרתים, זה כבר בתשלום).

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

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

לסיכום: אם יש לכם שרתי לינוקס בפרודקשן והם שרתים מבוססים על Red Hat או SuSE או אובונטו בתשלום – כדאי להשתמש בשרות ה-Live Patching ותחסכו לעצמכם דאגות על אבטחה וענייני Reboot.

עדכון מערכות לינוקס ו-Windows ממקום אחד

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

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

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

האם יש פתרון טוב לכך?

כן, ל-SuSE יש פתרון: SuSE Manager

תוכנת SuSE Manager מאפשרת מספר דברים:

  • לעדכן הפצות לינוקס חופשיות (CentOS, Scientific Linux, OpenSuSE, Fedora, Ubuntu)
  • לעדכן הפצות לינוקס מסחריות (Red Hat, Oracle Linux, SuSE SLE)
  • להתממשק ל-SCOM כך שניתן יהיה לעדכן את הפצות הלינוקס ישירות דרך ה-SCOM
  • לנטר את כל המערכות המבוססות לינוקס.
  • לבצע Provision ולהתקין לינוקס על מכונות פיזיות ווירטואליות (בשימוש AutoYast/Kickstart)
  • ועוד

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

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

ומה עם אלו שמעוניינים במשהו חופשי?

SuSE Manager ו-Red Hat Satellite מבוססות על תוכנה בשם Spacewalk, כאשר SuSE ו-רד-האט מוסיפים הרחבות משלהם, כך ש-Spacewalk לדוגמא לא מתממשק ל-SCOM ולא יאפשר עדכון מרוכז של מכונות לינוקס ו-Windows כך שניתן לעדכן רק מכונות לינוקס.

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

להתקדם בתחום

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

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

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

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

אז מה אתה יכול לעשות כדי לשפר את סיכוייך למצוא עבודה טובה בעתיד?

יש כמה דברים.

אם אתה רוצה להישאר בתחום ה-IT הקלאסי (לפני כניסת הענן) אז מה שמומלץ לך זה ללמוד את התחומים "השכנים": אתה איש סיסטם מיקרוסופט? תכיר יותר את תחום הסטורג' הרגיל, תכיר יותר נטוורק לעומק (אתה יכול להשתמש בכלי כמו GNS3 לבצע סימולציות), והכי חשוב – להכיר את מערכת ההפעלה ה"מתחרה" לינוקס במובן הטרמינל (לא במובן הגרפי. ברוב המקרים אתה לא תעבוד מול תצוגה גרפית במכונות לינוקס) – מה זה לינוקס, איך הוא בנוי, פקודות לינוקס בסיסיות, כתיבת סקריפטים בסיסיים ב-BASH, הגדרות ציודים שונים, ניתובים, ניהול חבילות תוכנה, ועוד. אם אתה רוצה, יש אתר בשם Linux Academy שמלמד את הדברים (יש מנוי חודשים שעולה 50$ לחודש, שבוע ראשון בחינם). אם אתה יותר טיפוס של ספרים – יש לא מעט ספרים שמלמדים על לינוקס ויש כמובן גם קורסים בבתי הספר המקצועיים השונים שמלמדים לינוקס. לגבי סטורג' ונטוורקינג – אני ממליץ ללמוד לבד.

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

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

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

איש ה-Devops טוב צריך לדעת כמה דברים חשובים:

  • הוא צריך להכיר טוב לינוקס, ברמה של כתיבת סקריפטים, הגדרות לינוקס, ניהול חבילות
  • הוא צריך להכיר את עולם הקונטיינרים – החל משימוש ב-Docker כדי לבנות Images, והוא צריך להכיר Kubernetes (או OpenShift או Caas) כדי לבצע אורקסטרציה בין הקונטיינרים השונים שירוצו, שרותים, רשתות, Scaling ועוד.
  • הוא צריך להכיר כלי CI/CD על מנת לאפשר ביצוע Build אוטומטי דרך כלים כמו Jenkins או Teamcity לדוגמא.
  • הוא צריך להכיר כלי ניהול קוד טוב. כל כלי שיודע לעבוד עם GIT זה טוב, בין אם מדובר ב-Bit Bucket או GitLab או כלי אחר, וכדאי להכיר את הדברים לא רק ברמת ממשק הווב אלא גם להכיר את GIT עצמו.
  • "קוד כתשתית" – אחד הדברים ש"רצים חזק" כיום הם כלים שכותבים איתם "קוד" לניהול תשתית כמו הענן הפנימי שלכם בענן הציבורי, כלי כמו Terraform או Ansible או SALT הם כלים מעולים לכך.
  • שפות – BASH מאוד יעזור לכתיבת סקריפטים פשוטים, מומלץ להכיר גם Python.
  • שרותים – כל ספק ענן ציבורי מספק מאות שרותים שונים. תצטרכו עם הכלים הנ"ל להגדיר ולהשתמש בשרותים הנ"ל ואצל כל ספק ענן זה שונה. כן. Not Fun.
  • ניטור באופן שונה – מכיוון שיש הרבה שרותים שספק הענן מציע ולך אין גישה לתשתית השרותים, תצטרך להשתמש בכלים שונים לניטור, סביר להניח דרך כלי הניטור של ספק הענן.

כמו שאתם רואים – ערימה לא קטנה של דברים. אגב, כמעט את כולם ניתן ללמוד ב-Linux Academy בלינק שנתתי לעיל.

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

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

בהצלחה.

על תחנות עבודה/שרתים ל-AI/DL

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

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

לפני שניגש לעניין התחנות, נסתכל על ה-GPU והשאלה הראשונה שצריכה להישאל היא: האם בחברה משתמשים ב-CUDA או ב-OpenCL? אם מדובר ב-CUDA, אז כרטיסים של חברת nVidia יכולים להיכלל. אם מדובר לעומת זאת ב-OpenCL, אז כרטיסים של AMD מסידרת Instinct (דרך פלטפורמת ROCm), ה-GPU הפנימי של מעבדי אינטל (לחישובים קטנים, או ב-CPU עצמו, זה גם עובד על מעבדים של AMD) או לכרטיסים שאינטל תוציא בשנה הבאה.

השאלה הבאה צריכה להישאל היא לגבי "שרשור" כרטיסי GPU. ל-nVidia יש את ה-NVLink שמאפשר להצמיד זוג כרטיסים ולקבל תקשורת ביניהם במהירות 100 ג'יגהביט לשניה. ל-AMD עם כרטיסי MI50 ו-MI60 יש את AMD Infinity Fabric לחבר בין זוג כרטיסים ולקבל מהירות של 200 ג'יגהביט לשניה. לכן חשוב לדעת מראש כמה כרטיסי GPU יהיו בתחנה, והאם אתם רוצים להצמיד כל זוג.

השאלה הבאה: כמה כרטיסים יהיו במכונה?

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

אם אנחנו מדברים על 3 כרטיסים ואנחנו מתכוונים גם להשתמש גם באחסון בתצורת חיבור M.2 – מומלץ להסתכל על פתרון מבוסס AMD Threadripper מהסיבה הפשוטה שמעבד זה מציע יותר נתיבי PCIe (כ-64 נתיבים) בהשוואה לכל מעבד דסקטופ של אינטל. מעבד זה הוא היחיד שמאפשר לחבר 3 כרטיסים. לגבי כמות ליבות – יש מספר דגמים, כמו 2950X עם 16 ליבות, 2970WX עם 24 ליבות ו-2990WX עם 32 ליבות. ההבדל בינם מבחינת מחיר – כמה מאות בודדות של דולרים.

אם אנחנו מדברים על 4 כרטיסים (עם או בלי הצמדה) אני ממליץ להסתכל על פתרון מבוסס AMD EPYC. מעבד זה נותן לנו לא פחות מ-128 נתיבי PCIe, כך שאפשר "להשתולל" מבחינת מפרט מבלי "לחטוף" במחיר, הואיל ומעבד EPYC נחשב מעבד זול מבחינת מחיר (אבל הוא מעולה מבחינת ביצעים). מכיוון ש-EPYC הוא מעבד לתחנות עבודה יעודיות ושרתים, נזכיר גם את מעבדי Xeon SP של אינטל, ובמקרה כזה נצטרך פתרון של 2 מעבדים (תלוי בכמות הליבות שאנחנו רוצים). אם אנחנו מעוניינים בכמות גדולה של ליבות (16 ומעלה) עדיף לבחור את הפתרון של AMD מבחינת מחיר זול יותר.

אחרי שדיברנו על ה-GPU, השאלה הבאה תהיה: איזו מערכת הפעלה רוצים להריץ על המכונה? גם ב-AI וגם ב-DL רוב הדברים הזמינים ונתמכים – רצים על לינוקס, פחות על Windows. יש הרבה דברים פופולריים כמו TensorFlow שירוצו על Windows, אך יש פחות תמיכה על כך מהקהילה.

השאלה הבאה: מחשב בניה עצמית או מותג? אפשר לרכוש את החלקים ולהרכיב, או שאפשר לרכוש מכונות מותג. כל אחד והעדפותיו. אם אתם מחפשים מכונות מבוססות EPYC, ל-Gigabyte יש את W291-Z00 ואת SuperMicro עם השם המאוד-קליט A+ Server 4023S-TRT. מכונות מבוססות Xeon או מעבדי אינטל – תמצאו אצל כל יצרן.

דברים שכדאי לבדוק לפני הקניה:

  • כרטיס רשת 10 ג'יגהביט – אם יש לכם כמות גדולה של תכנים שצריכה להיות מוזרמת אל התחנה, מומלץ להשתמש בכרטיס 10 ג'יגהביט בין האחסון המרוכז לתחנת העבודה. אם מדובר על מאות קבצי BLOB (תמונות וכו') בדקה, כדאי לשדרג ל-25/40/50 ג'יגהביט.
  • כמה סשן של פעילות צורך זכרון GPU? כרטיסי RTX מעל 2080TI יקרים מאוד, כדאי אולי לרכוש זוג כרטיסים "ביתיים" מאשר כרטיס אחד שעולה הרבה יותר.
  • אם כל התוכן שצריך לעבור "אימון" לא עולה על 2 טרהבייט ויש מכונה אחת – כדאי לרכוש 2 מקלות אחסון כמו סמסונג 970 PRO (או EVO 860) ולהגדיר אותם כ-RAID-0 ולאחסן את התוכן עליהם.

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

הסברים והבהרות לגבי Scale Out בתחום אחסון

אחת למספר שנים מתרחשים שינויים מהותיים בתחום הסטורג'. לפני מס' שנים נכנס דבר שנקרא Object Storage – זו צורה שונה לאחסון קבצים ונתונים שבמקרים רבים אינה משתמשת ב-File system רגיל. חברות כמו Seagate לדוגמא הוציאו מספר דיסקים קשיחים ובנו חיבור חדש לדיסקים – חיבור Ethernet ישירות לדיסק, מה שמחייב כמובן מערכת אחסון אחרת. (נכון להרגע, הפתרון הזה יותר מתאים לחברות כמו אמזון, גוגל ומיקרוסופט, או לחברות שבונות את ה-Object Storage שלהם, גם מבחינת חומרה).

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

אך מהו בעצם פתרון Scale Out?

חברות אחסון רבות לקחו את המושג "Scale Out" לכיוון שהם רוצים. יש חברות שמייצרות HCI (כלומר Hyper Converged) שלקחו את המושג Scale Out לכיוון הוספת שרתים שיתנו לך יותר משאבי מחשוב/רשת/אחסון. חברות אחרות לוקחות את זה לכיוון שאם אתה מרים ערימת שרתים, אתה מתקין VM בכל אחד מהם שמחובר לדיסקים המקומיים בכל שרת וישנה תוכנה שמתחברת לכולם ובכך נוצר Storage (אין Networking גודל בכל מכונה והמכונה לאו דווקא מריצה מכונות VM אחרות) ויש כמובן את ה-Scale Out שעליו דיברתי בפוסט הקודם – ערימת שרתים מלאים דיסקים שלא מריצים מכונות VM או Payload משלך אלא תוכנה יעודית של יצרן הפתרון בלבד.

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

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

לא כל פתרון Scale Out מתאים לכל הסיטואציות. בתחום HCI לדוגמא, אתה יכול להוסיף עוד כמה טרהבייט בחישוב הכולל בכך שתוסיף עוד כמה דיסקים (מכניים/SSD) פר מכונה ובכך תקבל יותר אחסון ויותר IOPS, אבל פתרון כזה אינו מתאים אם לדוגמא אתה צריך מאות טרהבייטים עד פטהבייטים (ומעלה) של אחסון ואין לך צורך בהרבה מקום נוסף למכונות VM. בסיטואציה כזו אתה חייב פתרון אחסון Scale Out שידע לעמוד בשרידות של שרת אחד או 2 שנופלים ולא פתרון Scale Up (למרות שרוב פתרונות ה-Scale Up מתהדרים בכך שהם יכולים לגדול לפטהבייטים).

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

  • אם מדובר במערכת HCI שתהווה אלטרנטיבה ל-VSAN/Simplivity/Nutanix – אז יש את GlusterFS והוא מגיע יחד עם RHV.
  • אם מדובר במערכת Scale Out שלא הולכת לגדול מעבר למספר קטן של שרתים (כמה עשרות) – ניתן לרכוש את GlusterFS בנפרד.
  • אם צריכים מערכת אחסון שתורכב מעשרות שרתים ואחסון בגדלים של מאות טרהבייט ומעלה, או שתריץ מערכת ענן פרטי כמו OpenStack בחברה – מערכת SES של SuSE או Red Hat Ceph Storage יתנו לכם מערכת מבוססת CEPH שבנויה לדברים הללו (הפתרון של SuSE בארץ זול משמעותית בהשוואה למחיר שרד-האט מבקשים, ויש את אותה פונקציונאליות בשתיהן).
  • גם Ceph וגם GlusterFS מתאימות אם אתם הולכים להריץ קונטיינרים/Kubernetes/OpenShift על הברזלים.

לסיכום: פתרון Scale Out טוב (שאינו מבוסס HCI) הוא פתרון שנותן:

  • להגדיל את כמות האחסון למימדים גדולים (מאות טרהבייט ומעלה)
  • שרידות הרבה יותר גבוהה מפתרון Scale Up (מערכת ששורדת גם כששרת אחד או יותר המאחסנים את הפתרון נופלים)
  • תמיכה בסטנדרטים אחרונים (Object Storage, Persistent Volume, ,Cinder וכו')

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

קונטיינרים ומכונות וירטואליות – השילוב הנחוץ

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

הפעם נדבר על דבר הפוך וחדש.

סיפור קטן: לפני מס' חודשים ישבתי בישיבה אצל חברה פיננסית גדולה מאוד שכולם מכירים. מטרת הישיבה – שיחה על מעבר עתידי לתצורת עבודה של Devops, שימוש ב-CI/CD, קונטיינרים, מתודות וכו'. בדרך כלל בישיבה כזו אני מבקש לדעת מה הכלים שהם משתמשים כרגע, כמו שרתי אפליקציות, קומפיילרים, מערכות הפעלה וכלים אחרים, ולפי זה ניתן להעריך בהערכה גסה מה יהיה קל להעביר לקונטיינרים ול-Micro Services. במקרה של אותה חברה, מבלי לפרט דברים, היו כמה דברים שלהעביר אותם לקונטיינרים יהיה סיפור סופר-מורכב, ובחלק מהמקרים כנראה שלא אפשרי מכל מיני סיבות שלא אכנס אליהם כדי לא לחשוף פרטים. אלו הדברים שבדרך כלל אני רושם לעצמי בצד לבדוק מה ניתן לעשות עבור הלקוח.

אצל חברות רבות (במיוחד אצל הגדולות) יש אלפי מכונות וירטואליות שמריצים דברים שונים, שלא קל להעביר או שאין תקציב/כח אדם להעביר לקונטיינרים, או שלא ממש אפשרי: מה עושים שהאפליקציה רצה כמכונת Windows וירטואלית עם 1001 תלויות לדוגמא? מה אם מדובר ב-VM שאין לאף אחד קוד להעביר לקונטיינר? אלו אינן בעיות תיאורתיות, אלו בעיות אמיתיות שמקשות מאוד על מעבר לקונטיינרים. אחרי הכל, אף חברה גדולה לא הולכת לזרוק את תשתית הוירטואליזציה ועוברת לקונטיינרים.

כאן נכנס לתמונה כלי חדש של רד-האט שנקרא Kubevirt.

Kubevirt בעקרון עושה משהו הפוך ממה ש-CRI-O עם Kata containers עושה: עם CRI-O אנחנו מריצים קונטיינרים בתוך VM מינימלי, ואילו Kubevirt מריץ מכונה וירטואלית בתוך POD, וכן, אני מדבר על המכונה הוירטואלית המלאה – עם OS ואפליקציות משלה, שמתורגמת ישירות מ-VMWare או מ-OVA.

במילים אחרות – אנחנו נריץ VM כ-קונטיינר! (וכן, נקבל את האבטחה המלאה של ה-VM).

כך ניתן בעצם עם Kubevirt לקחת את אותן מכונות וירטואליות שלא ניתן להמיר לקונטיינרים ולהריץ אותן ישירות בתוך Kubernetes או OpenShift ובדרך להנות מדברים כמו Scaling ועוד תופינים שמערכת Kubernetes/OpenShift נותנת, מבלי שנהיה תקועים עם דברים שאי אפשר להמיר לקונטיינרים. כך לדוגמא אצל אותה חברה פיננסית גדולה, כל מה שאצטרך בעצם לעשות, זה להמיר את ה-VM (ליתר דיוק את הדיסק) ל-Persistent Volume ובקובץ ה-YAML להשתמש ב-PVC על מנת "לחבר" את ה"דיסק") לאותו VM.

יש גם מגבלות נכון לגירסה הנוכחית כמו:

  • אפשר להשתמש רק בדיסק קשיח יחיד
  • יש רק כרטיס רשת אחד, וגם איתו אי אפשר לשחק הרבה הואיל והמערכת מבצעת Proxy בין ה-VM לתקשורת של ה-POD.

רד-האט, מפתחת Kubevirt, פרסמה לאחרונה פוסט בנושא.

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

למעוניינים, באתר Kubevirt יש מספר דוגמאות איך ניתן להשתמש בכלי הן עם Minikube, הן בתוך Cluster של Kubernetes, הן בתוך AWS, והן בתוך GCP.

לסיכום: Kubevirt נותן סוף סוף את האפשרות לחברות לקחת מכונות וירטואליות ולהעביר אותן לעבוד יחד עם Kubernetes או OpenShift. אינני מדבר על ההעברה של כל תשתית הוירטואליזציה ל-Kubernetes (אני לא מוצא יתרון בהעברת מכונת SAP), אלא לדברים שאנחנו צריכים כחלק מעבודות מתודת Devops, CI/CD וכו'. במקרים שקשה או לא ניתן להעביר מכונות וירטואליות לפורמט קונטיינרים, הרבה יותר קל להעביר מכונה וירטואלית מפורמט VMware לפורמט KVM ולהריץ את אותה מכונה וירטואלית כמו שהיא – כקונטיינר.

הערה: הכלי נמצא במצב Preview והוא עדיין בפיתוח.

 

וירטואליזציה: לחזור לברזלים?

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

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

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

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

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

  • עלויות מטפסות: אם נניח יש לנו כיום 10 שרתים שמריצים את כל הדברים בוירטואליזציה ועתה נוסיף 10 שרתים נוספים שיריצו דברים "על הברזל", הדברים מסביב יעלו יותר: קירור, חשמל, תחזוקת השרת (מבחינת תוכנה וחומרה). בהתחלה זה נשמע כאילו מדובר בעלות קטנה, אולם מכיוון שאנחנו צריכים לאמץ את השרתים (כי לשם כך אנחנו מבצעים V2P) – עלויות החשמל והקירור יעלו באופן רציני.
  • שדרוג חומרה: תעיפו מבט בחומרת השרתים. לעיתים השקעה של כמה מאות או אלפי דולרים חד פעמית בשדרוג מעבדים ו/או זכרון יכולה להאיץ את הביצועים של המכונות הוירטואליות ולחסוך מעבר מוירטואלי ל"ברזל".
  • להתראות לדברים הנחמדים: וירטואליזציה נותנת לנו פונקציואנליות שקצת קשה להשגה כשדברים רצים ישירות "על הברזל". קחו לדוגמא Snapshot – סביר להניח שאינכם משתמשים ב-ZFS על הברזל, כך שיצירת Snapshot של הברזל היא קצת בעייתית (במיוחד אם אין לכם LVM או שלא הגדרתם ווליום לוגי שיאחסן את ה-Snapshots בנפרד). רוצים HA? לא תוכלו להשתמש ב-HA שהוירטואליזציה מספקת, תצטרכו פתרון נפרד, ובהצלחה בבניית Fault tollerance על ברזלים, ואלו רק חלק קטן מהפונקציונאליות שוירטואליזציה נותנת וריצה "על הברזל" לא נותנת.
  • גיבוי ושחזור – הרבה יותר איטיים מאשר גיבוי ושחזור מכונות וירטואליות.

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