לפני רכישה – כדאי לחשוב קדימה

כאן בארץ, לא חסרים ארגונים ועסקים שההתמחות שלהם היא בשיווק מוצרים לעסקים וחברות בכל מה שקשור ל-IT – בין אם מדובר בתוכנה, חומרה, שרותי אינטגרציה, תמיכה וכו'. זה הביזנס שלהם ומרביתם יכולים למכור לך כמעט כל מה שתרצה – בין אם זה כונן דיסקטים 5.25" ועד Mainframe – כולל שילוב ואינטגרציה של מה שהם מוכרים. לגטימי? בהחלט.

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

המקרה הראשון התרחש לפני מס' חודשים: קורא נאמן של הבלוג פנה אל עבדכם הנאמן בשאלה פשוטה: החברה הגדולה שהוא עובד שם מתכננים לרכוש 4 דיסקים Optane של אינטל מסוג P4800X דרך יצרן השרתים של החברה. הסיבה לרכישת הדיסקים האלו? מצגת שהראתה להם שבביצועי SQL – הדיסקים הללו יהיו מעולים לצרכיהם, הרבה יותר מכל סטורג' שהם יחברו (בקטע הזה המצגת צודקת. דגם ה-Optane הזה בהחלט מתאים ונותן ביצועים מטורפים!). הדיסקים האלו יכנסו לתוך שרת R740 של DELL, ימופו לתוך VM שיריץ שרת Windows Server 2016 ו-SQL Server. אמרתי לו שלדעתי תהיה בעיית ביצועים, אבל אם הם מעוניינים, אשמח לבדוק להם את העניין – בתשלום. החברה הסכימה. (בכל זאת, 2500$ פר SSD, כלומר $10000 דולר במחירי ארה"ב…)

תודות לכמה יבואנים הצלחתי להשיג את הציוד להשאלה אליי ל-LAB. השרת פורק, חיברתי את ה-backplane עם כניסות U.2, הצמדתי לדיסקים חיישני חום, הפעלתי והתחלתי להריץ בדיקות עומסים שונים. לקח 10 דקות עד שאחד ה-SSD הגיע ל-95 מעלות חום. כמה דקות אחרי זה שאר ה-SSD הגיעו בערך לאותו חום – והביצועים החלו לצלול. סיכום הדו"ח שלי ללקוח הצביע על הבעיה הפשוטה: הן שרתי ה-R740 (וגם כל שרת 2U של HPE או לנובו לצורך העניין) אינם מתאימים בתצורה זו ל-SSD מבוסס Optane של אינטל. הדיסקים הללו מפיקים הרבה יותר חום מדיסקים מכניים או SSD מתחרים. הדרך היחידה להכניס 4 כרטיסים כאלו היא לרכוש 4 SSD כאלו בתצורת AIC (כלומר כרטיס PCIe) ואז למפות אותם. עדיף במקום שרת 2U להשתמש בשרת 3U (אבל אז גם מחיר השרת מטפס הואיל ומה ש-DELL מוכרת בגירסת 3U זה שרת עם 4 מעבדים).

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

  • אבטחה – עם כל הכבוד ל-Kubernetes, הפלטפורמה עדיין אינה מאובטחת כמו OpenShift (תודות ל-SELinux ועוד מספר רכיבים).
  • Auditing, Compliance – בחברות גדולות ומשרדים ממשלתיים מאוד רוצים את זה.
  • מיגרציה בהמשך – תחשבו 4 שנים קדימה, אם Kubernetes עדיין תהיה קיימת, יהיה קשה מאוד להעביר אליה דברים שבנינו השנה לגירסה שתצא אז. במוצר כמו OpenShift היצרן מציע כלים לבצע מיגרציה.

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

המקרה השלישי קשור יותר ל"התלהבות" הולכת וגודלת לכל ה-Hyper Converge בוירטואליזציה (למי שלא מכיר: מערכות כמו vSAN, Simplivity, Nutanix מציעות להקים שרתים שיתנו את כל השרותים הכוללים Storage, Network, Compute – ללא צורך בסטורג' מאסיבי, סוויצ'ים יקרים וכו').

כמו תמיד, חברות כמו VMWare ואחרות לא המציאו מאפס את עניין ה-Scale Out הזה. מערכות File System ל-Scale Out קיימות זמן רב, כמו Lustre FS, מערכת Open Vswitch לצרכי Network, ופתרונות וירטואליזציה שונים הציעו זאת בסביבת HPC כבר זמן רב.  החולשה שיש ב-HPC קיימת בדיוק אותו דבר גם בפתרונות וירטואליזציה Scale Out: אם אתה צריך כמות IOPS מאסיבית של 7 ספרות ומעלה, תצטרך או לרכוש סטורג' יעודי או לרכוש הרבה יותר שרתים פיזיים מכפי שאתה צריך עבור Compute. אם אין לך צרכים כאלו, אז כן, פתרון Hyper Converge יכול להיות פתרון טוב.

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

קצת על 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 עם מפרט נמוך ולהריץ את הדברים הדורשים ביצועים בשרת אחר.

תחום ה-VDI וענן – עדכון מצב

יש משהו אחד שקשה מאוד למצוא אצל ספקי ענן ציבורי – וזהו כמובן שרות VDI, שרות מבוסס SaaS וזה מפתיע לא מעט אנשים. מדוע שספקי ענן ציבורי לא יציעו שרות כזה? הרי הם מציעים שרותים מכאן ועד הודעה חדשה…

על מנת להבין את הבעיה, נתחיל בהתחלה הפשוטה: כל ספקי הענן ישמחו לאפשר לך לשכור מכונה (Instance או VM) מבוססת Windows, בין אם מדובר על Windows Server 2012, 2016 או אפילו 2019. אין שום בעיה. רוצה משהו כמו Windows 10 או גירסה מתחת? תשכח מזה. ספקית ענן כמו אמזון שמחה להציע משהו "דומה ל-Windows 10" לדוגמא. מה שתקבל בעצם זה Windows Server 2016 ששינו לו מספר גדול של ערכים ב-Registry, שהותקן עליו Windows Experience וגם מספר אפליקציות בסיסיות. יש גם את חבילת ה"פלוס" שכוללת אופיס, אבל אז אתה משלם תוספת שכוללת תשלום חודשי למיקרוסופט לא רק על ה-OS, אלא גם על ה-Office שמותקן ב-Instance. למכונה כזו אתה יכול להתחבר עם כלים שונים שמתאימים לכל מערכת הפעלה קיימת, כולל סלולרי/טאבלט/כרומבוק וכו'.

אז מדוע אף אחד לא מציע מכונה מבוססת Windows 10? אחרי הכל, שרות שידע להקים מכונה כזו מ-אפס או אפילו לקחת Sysprep שלך ו"להלביש" אותו על ה-OS זה לא משהו כזה מסובך לכתוב…

הבעיה מגיעה מכיוון רדמונד. מיקרוסופט לא רוצה (ולפעמים גם נלחמת באמצעים משפטיים) ששום ספק יציע שרות כזה, ולא חשוב אם מדובר בספק ענן ענק, או בחברת Hosting פצפונת. מבחינת מיקרוסופט, המוצרים היחידים מבחינת OS המוצעים לספקי Hosting וענן כאחד – הם אלו הכלולים תחת רשיון SPLA בהם הספק משלם למיקרוסופט כל חודש על רשיונות ה-Windows Servers (וכלים אחרים) ואת המחיר הוא מגלגל על הלקוח. במסגרת הדברים המוצעים ב-SPLA, אין שום הצעה/שורה למערכת דסקטופ כלשהי, ולא חשוב אם מדובר בגירסת Home או Enterprise.

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

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

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

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

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

בקיצור: אם ספקי הענן יציעו שרות של מכונות וירטואליות עם Windows 10 כ-שרות VDI והם יגבו כמו שהם גובים כיום על Instances, המחיר הכולל פשוט לא יהיה שווה מכיוון שעלויות התקשורת יהיו אסטרונומיות. החברות יצטרכו להציע חבילות Bundle הכוללות מספר טרהבייט תעבורה בחודש עם שרות VDI.

לסיכום: VDI בענן במחשבה ראשונה יכול להישמע רעיון לא רע, אבל כשמתחילים לחשוב על העלויות של Instances ובמיוחד העלויות של תקשורת בין הענן אל המשתמשים בארגון, ואם מוסיפים לכך ענייני רגולציה ובעיות תקשורת עקב כך שהכתובות IP אינן ישראליות – הרעיון כרגע אינו שווה כל כך פיננסית. אם לעומת זאת ספקי הענן יתנו חבילות תקשורת עם מחיר טוב בכל הקשור לתעבורת VDI וניתן יהיה לקשר כתובות IP ישראליות מספק מקומי אל ספק הענן (כמו שרות BYOIP שאמזון מציעים) – יכול להיות שזה יהיה משתלם. האם ניתן יהיה להעביר הכל לענן? לא. כל דבר שמצריך VPN לא ניתן יהיה להעביר (מכיוון שמשתמשים בתקשורת אל ה-VM ש"נופלת" ברגע שיש שכבת VPN, ובמקרים של VPN כמו של סיסקו המערכת פשוט לא נותנת להתחבר) ויש כמובן את המכונות המקומיות שקשורות לכל מיני ציודים שיש בהם צורך מקומית (GPU, תקשורת לסטורג' מקומי וכו').

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

נקודות למחשבה לגבי מעבר לענן (2019)

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

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

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

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

נניח וירון בוחר את השיטה להחליף "ברזלים" – נניח R710/R720 ב-R740 – העלות שלו תהיה Fixed ומשולמת מראש. נניח לשם הדוגמא ש-R740 עולה 10,000$ ויש לו 3 שרתים ישנים והוא מעוניין להחליף את כולם, אז העלות תהיה בעצם 30,000$. במחיר הזה ירון מקבל את האפשרות להביר מכונות VM לתשתית החדשה תוך שימוש ברשיונות קיימים (בדרך כלל, קיימות גם חריגות) והוא יכול בהמשך להוסיף עוד מכונות VM ללא עלות נוספת (שוב, למעט מקרים של רשיונות ל-OS וכו').

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

אז בואו נחשב מחיר: יש לנו 50 מכונות VM שפרוסים על 3 שרתים והם יתנו שרות לפחות ל-3 שנים הקרובות. מחיר פר VM יצא 600$. אפשר כמובן לקצץ ולרדת ל-2 שרתים עם מעבדים חזקים מרובי ליבות וכמות זכרון משמעותית (נניח 256 ג'יגה פר שרת פיזי). חושבים שזה יעזור? מהרגע שעוברים ממעבדים כמו Xeon SP Silver למשהו יותר רציני – המחיר יטפס בכמה אלפי דולרים, כך שלא בטוח שאם נרד בכמות השרתים (אך נשדרג במעמד ההזמנה את אלו שאנחנו רוצים לרכוש במפרט יותר "כבד") זה יעזור. אנחנו יכולים לרדת במחיר VM מ-600$ נניח ל-500$ ואפילו $400. המחיר ירד יותר אם אותן מכונות VM יעבדו יותר שנים, כמו לדוגמא 5 שנים – אז אנחנו יכולים לרדת ל-$133 פר VM.

נניח עתה שירון רוצה להסתכל על הפתרונות בענן. שיהיה מה להשוות.

אז בואו נאמר שב-AWS ניקח מכונה צנועה, 2 ליבות, 8 ג'יגה זכרון, תעבורת תקשורת נמוכה ו-80 ג'יגה דיסק (EBS). המחיר לחודש – 80$. את המחיר הזה ניתן "לחתוך" אם ירון מוכן לשלם לשנה מראש או 3 שנים מראש על אותו VM. אם זה לשנה, הוא יצטרך לשלם $1740 ואם זה ל-3 שנים, אז הוא יצטרך לשלם $1159 (כלומר אפקטיבית הוא כביכול ישלם 32.20$ לחודש) – אז בתכל'ס ניתן להגיע למחירים טובים פר VM (זה קיים אצל כל ספקי הענן הגדולים, אגב). יש,אגב, מסלולים שונים, תלוי בספק הענן.

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

  • רוצים קו יעודי (MPLS) של 100 מגה נניח מחברתכם אל אמזון? זה יעלה כמה אלפי דולרים, לאמזון ולספק התשתיות שלכם.
  • לא רוצים פתרון MPLS אלא VPN? אין בעיה. התשלום יהיה על ה-Instance שיריץ את פתרון ה-VPN ועל התעבורה היוצאת מאמזון אליכם (משלמים על הכיוון מאמזון החוצה, לא להיפך)
  • יציאה לאינטרנט – אתם משלמים על כל ביט שיוצא החוצה לאינטרנט מהתשתית שלכם בענן, ותלוי גם לאן התקשורת יוצאת – כל אזור והמחיר שלו (המחיר הולך פר ג'יגהבייט)
  • רוצים לגבות את התכנים? רעיון מעולה! כל ספקי הענן מציעים שרותי אחסון שונים (כמו S3 ועוד) ויש עלויות של כמה סנטים פר ג'יגהבייט (תלוי בענן, ובסוג שרידות שאתם מחפשים עבור הגיבוי).
  • כתובות IP אמיתיות – כל כתובת עולה כסף ואם ביקשתם הקצאת כתובות ולא השתמשתם – המחיר פר IP קופץ פי 3-4 (המחיר הוא בדרך כלל ל-IP אמיתי בשימוש בסביבות 1-2$ לחודש)
  • החלטתם להשתמש בשירותים שונים כדי לחסוך הקמה ותחזוקה של שרות דומה? יש מחירים Pay as you go ויש מקרים שאפשר לשלם מראש ולחסוך. ככל שיש יותר שימוש, המחיר עולה.

(עכשיו אתם מבינים מדוע אני מתייחס לעננים המקומיים שמציעות חברות תקשורת מקומיות שונות שמריצות תשתית של VMWare או Hyper-V כבדיחה?)

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

  • ב-On Prem אתה משלם על הציוד פעם אחת ואם אתה רוצה להוסיף נניח עוד מכונות VM, העלות תהיה אפסית (למעט במקרים שצריך שדרוג ציוד).
  • ב-On Prem כשיש תקלה, אפשר לטפל בה מקומית 24X7 ולא תלוים בספק הענן (אם משתמשים בשרותים של ספק הענן לדוגמא) עד שיתקנו את התקלה.
  • בענן אפשר תוך דקות ספורות להתחבר לשרותים שונים שחוסכים הקמת שרתים/הגדרות/תחזוקה ואפשר להשתמש ישירות בשירות. כך לדוגמא, במקום להחזיק Cluster של SQL, אפשר להשתמש בשרותי RDS.
  • בענן מחירי ה-VM יותר זולים – אם מוכנים לשלם מראש.
  • בענן אתה תמיד רץ על תשתית חזקה ואף אחד לא מכניס את ה-Instances שלך למכונות שכבר עמוסות. במקרים רבים ה-Instances רצים על מעבדים יחודיים חזקים שלא זמינים לשוק הרחב.
  • שרותי תמיכה בענן ישירות מספק הענן – אינם זולים.
  • נקודה חשובה: ב-On Prem אין לך הפתעות במחיר או בחשבונית חודשית.
  • כשזה מגיע לתשלום – בענן אין "שוטף/שוטף פלוס". התשלום הוא בתחילת החודש הבא.

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

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

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

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

השלב הבא בוירטואליזציה של Oracle

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

אחת הבעיות שחברת Oracle ניצבת בפניהם, כמו אצל ארגונים אחרים שמשתמשים ב-Xen Server, זה שפיתוח המוצר די "קפא" וחברת Citrix איחדה את המוצר עם מוצרים אחרים מתוצרתה. הגירסה החופשית מתפתחת בקצב איטי מאוד וכשמשווים להתפתחות של וירטואליזציה אחרת כמו KVM/QEMU – אז האחרון מוביל בכל פיתוח אפשרי, הן מבחינת תמיכת וירטואליזציה במעבדים אחרים (כולל מעבדי Power של IBM), ממשקים (API), ושל פונקציונאליות נוספת.

ואורקל .. בהחלט מודעת לכך.

אז מה אורקל עושה בנידון? מפתחת מוצר חדש.

(הערה: את כל הדברים אני כותב מתוך מעקב אחרי Mailing lists שונים שאני עוקב אחריהם בכל מה שקשור לפיתוח וירטואליזציה).

באורקל מודעים לכך שישנה אי תאימות בין Xen, מכונות וירטואליות שניבנו על הפתרון לבין KVM ופתרונות ניהול וירטואליזציה המבוססים על KVM כמו RHV/oVirt, עוד מהרמה הבסיסית של דרייברים. הדברים פשוט שונים, ולכן ב-Oracle מפתחים טלאים חדשים כך שניתן יהיה להריץ מכונות Xen באופן "טבעי" על KVM מבלי לשנות את ה-VM. הטלאים שפורסמו הם בבחינה RFC בלבד ולא מיועדים בשלב זה לאינטגרציה עם ה-Kernel אולם אני מאמין שבמהלך החודשים הקרובים לאחר שאורקל תאסוף פידבק מספק, הם יוציאו טלאים לשילוב ב-Kernel הרשמי וכמובן ישולבו במוצר העתידי של אורקל.

Xen, בסופו של דבר, הוא רק מנוע, Xen Server היא הפלטפורמה, כמו ש-KVM הוא בעצם המנוע של QEMU, ולכן צריך גם פלטפורמה חדשה, וכאן – למרות שאין שום הכרזה, ניתן לראות ב-Mailing Lists של oVirt – מיילים של עובדי אורקל (יש לא מעט מהם, מעובדים שונים) שמנסים לבדוק את ה-Oracle Linux ומריצים טסטים אוטומטיים שונים שהם כותבים.

המסקנה שלי לאחר מעקב של מס' חודשים אחרי המיילים: אורקל הולכת לבצע מעין "Fork" ל-oVirt ולהוציא מוצר מסחרי שבעצם מבוסס oVirt אך אני מהמר שעם ממשק משתמש אחר ועם תוספות שלא יהיו קיימים ב-RHV (הגירסה המסחרית של רד-האט) כמ יבוא מ-Xen Server של הגדרות ו-VM ללא צורך בהמרת המכונה לפורמט KVM ואני בטוח שיהיו גם תוספות אחרות שכבר קיימות ב-KVM ועדיין לא קיימות ב-Xen.

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

אני פחות שמח לראות חברות כמו רד-האט שעדיין אינה מבינה את הלקוח שמוציא את הצ'ק לרכוש את המוצר ואת צרכיו. לא מעט פעמים "נדנדתי" למנהלים שונים ברד-האט לבצע שינויים שאני בטוח שלקוחות שמעוניינים להתנסות במוצר ירצו – ולשווא (לדוגמא: להריץ מערכת מלאה של oVirt כ-Nested Virtualization, דבר ש-VMWare תמכה עוד בגירסה 3 שנקראה ESX-Server. דוגמא אחרת: כיבוי כל המערכת, מבלי שהלקוח יתחיל ללמוד Ansible, התאוששות מהירה מקריסת חשמל ועוד).

חבל ש-SuSE לא נכנסת לזירה, היה יכול להיות בהחלט מעניין.

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

להתקדם בתחום

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

בהצלחה.

קונטיינרים וגדילה, צרכים מול מציאות

עבדכם הנאמן ממשיך בביקורים בחברות גדולות במשק הישראלי בנסיון להסביר יותר לגבי קונטיינרים, מערכות אורקסטרציה לקונטיינרים (מה שמבוסס Kubernetes), תמיכה ב-CI/CD וכו', אך אחד הדברים שקשה להעביר להנהלות השונות, הוא עניין ה-Scaling הרוחבי, שהוא אחד ההבדלים המהותיים בין עבודה עם מכונות VM ו-Scale קבוע, לבין קונטיינרים עם Scale דינמי.

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

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

אם היינו לוקחים אתר מסחרי ו"ממירים" אותו לעבודה כקונטיינרים על ענן ציבורי כלשהו, רוב התקלות היו נמנעות, כי מערכת כמו Kubernetes/OpenShift יודעות לבצע Scaling אוטומטית אם פשוט מגדירים זאת, בין אם מדובר בגדילה או בהקטנה, בהתאם לעומסים. אתם עובדים עם אמזון וצריכים עכשיו להרים 500 קונטיינרים וכבר הגדרתם את הכל באותו ענן? תוך דקות ספורות הכל יהיה למעלה ואם תצטרכו יותר קונטיינרים עקב עומסים, יקח למערכת שניות ספורות להוסיף קונטיינרים, וזה אחד ההבדלים הגדולים בין קונטיינרים ל-VM (או EC2 Instance): ל-VM לוקח מספר דקות כדי להיווצר ולהיות מוגדר לעבודה יחד עם השאר. גרוע מכך: אם המערכת רצה On Premise, אז בעצם צריך לנחש כמה מכונות להקים ומערכות וירטואליה אינן טובות בהוספה אוטומטית של מכונות VM (וכמובן – בענן ציבורי יש הרבה יותר משאבים ממה שיש On Premise או בכל ספק Hosting מקומי).

קונטיינרים הם דברים חד פעמיים, שנהרסים בתום עבודה (או כשהם קורסים עקב שגיאה/באג), וכשמתחילים להשתמש בכלי CI/CD עם קונטיינרים, כמות הקונטיינרים שתרוץ במקביל מתחילה לטפס במהירות. אם לדוגמא נשתמש בכלי כמו Jenkins עם תמיכה בקונטיינרים ונגדיר את Jenkins לעקוב אחרי כל מיני Repositories של קוד שמפתחים כותבים, ברגע שמבצעים Commit, מערכת Jenkins תקים קונטיינר ותבנה בתוכו את הקוד. נניח שיש לנו מספר Repositories ומספר עבודות ב-Jenkins שזה מה שהן עושות, נראה שהמערכת מהר מאוד תקים מספר קונטיינרים, ואם נגדיר את המערכת להריץ טסטים על קונטיינרים שנבנו מ-Build אחרון, נקבל מספר כפול ותוך זמן קצר כולם יכולים לראות שמשאבים מנוצלים במהירות, הן מבחינת Compute וכמובן מבחינת אחסון (תסתכלו על הגרפים של ה-VM שמריצים את ה-Kubernetes/OpenShift). היתרון הגדול כמובן בקונטיינרים, זה שהכל נבנה מאפס, ואין יותר "אצלי זה עובד אז אם לך לא עובד, זו בעיה שלך".

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

אבל הבעיה מתחילה שצריכים להריץ קונטיינרים ומערכת כמו OpenShift/Kubernetes – כדי לשרת את הקהל בחוץ. כמות הגולשים היא דינמית, והמערכת צריכה להיות בנויה בצורה שונה בהשוואה לעבודה מול מערכות VM או EC2 Instances. דוגמא פשוטה: אם אנחנו רוצים לכתוב תכנים החוצה מהקונטיינר (שוב, קונטיינר הוא דבר חד פעמי וכשהוא נהרס, המערכת מוחקת הכל אלא אם הקונטיינר נבנה עם הגדרות של כתיבה חיצונית בדרכים מסויימות), זה שלאותו VM יהיה גם 10 טרהבייט דיסק קשיח וירטואלי לא יעזור במאומה כי שיטת אחסון הנתונים היא שונה, יהיה צורך במקרים רבים וכשיש כמות גדולה של כתיבה ודרישה לשרידות רצינית – להשתמש ב-Object Storage שמבוצע ב-Scale Out שאינו בנוי על VM שמאוחסן על איזה Datastore ב-vSphere, וכאן כבר יש צורך או בסטורג' Scale Out קנייני שיודע לתמוך ב-Object Storage או להקים מערכת שתרוץ כ-VM על הברזלים וגם הקונטיינרים ירוצו על הברזלים עצמם ללא וירטואליזציה (למעט קונטיינרים מסויימים שאיננו סומכים עליהם ונוכל להריץ אותם עם וירטואליזציה קטנה כמו עם Kata Containers) ומעל זה יכול להיות שנצטרך להריץ איזה Load Balancer כלשהו (אם כי מערכות Kubernetes/OpenShift נותנות פתרון Load Balancing אבל לא בטוח שחברות ירצו להשתמש בו לצרכים של אתרים חשופים). פתרונות כאלו לא יתנו לנו גמישות מקסימלית כמו שרות הרצת קונטיינרים שספקי הענן מציעים (בגלל שלהם יש הרבה יותר משאבים).

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

  • ענן פרטי עם OpenStack: הפתרון הזה יכול לתת לנו את הכל ביחד. אנחנו יכולים להשתמש בסטורג' קנייני כלשהו ולחבר אותו ל-OpenStack כדי לקבל שרותים כמו Object Storage, Block Storage וכו' או שאנחנו יכולים להקים VM בכל שרת ולהריץ עליו Ceph.
  • עבודה במצב Hybrid: יש לנו מקומית מערכת OpenShift או Kubernetes פנימית שעליה אנחנו מבצעים פיתוח וכו', ואת האתרים הציבוריים אנחנו נשתמש בשרותי הקונטיינרים שספק הענן שבחרנו מציע. אם לדוגמא החברה משתמשת ב-Azure, אז הם יכולים להשתמש בשרות AKS. באמזון יש את אותו שרות (בערך) שנקרא EKS (או Fargate ששם אמזון מנהלת את ה-Kubernetes ואתה מריץ את הקונטיינרים) ובענן של גוגל יש את GKE. ה-Hybrid מומלץ לחברות שהרגולטור אוסר עליהן להוציא הכל החוצה.
  • עבודה "באותו ענן" – במקומות בהן בחרו לעבוד לדוגמא עם Azure, ניתן לרכוש מיצרן השרתים המועדף עליכם את Azure Stack – זהו פתרון שרץ על הברזלים אצלכם מקומית עם חיבור ל-Azure, כך שאפשר להשתמש באותם שרותים, מקומית או בענן בחוץ. עם עננים אחרים, אתם משתמשים בשרותי ה-Kubernetes של ספק הענן כך שהשינויים להריץ דברים מקומית או בענן הם די מינוריים וניתן להפריד את ההגדרות לקבצים שונים. בהמשך השנה, גם אמזון וגם גוגל יציעו לכם ברזלים ותוכנה להריץ את השרותים שאתם מריצים בענן – מקומית ובענן, כמו ה-Azure Stack.
  • שימוש ב-OpenShift – מערכת OpenShift קיימת לשימוש מקומי בשרתים שלכם או ב-OpenShift בענן שקיים אצל כל ספקיות הענן.

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

אם יש לכם שאלות, אתם מוזמנים לפנות אליי.

סקירה: מיקרו שרת של HPE דור 10

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

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

נתחיל במפרט הטכני:

  • מעבדים – AMD Opteron (קיימים 3 דגמים: X3216, X3418, X3421). הדגם שמיובא לארץ הוא הדגם הנמוך עם מעבד X3216 עם 2 ליבות, 1 מגה זכרון מטמון, APU מובנה, ומבחינת כח – הוא הכי נמוך עם הספק של 12-15 וואט). שאר הדגמים הם עם 4 ליבות, 2 מגה זכרון מטמון, כח גרפי מעט יותר חזק, והספק של 12-35 וואט.
  • זכרון – עד 32 ג'יגהבייט (ECC).
  • אחסון: 4 דיסקים קשיחים בגודל 3.5 אינטש ללא תמיכה להחלפה חמה, ואפשרות להוסיף דיסק 2.5 אינטש בחיבור SATA (לצרכים של Boot או Cache עם SSD).
  • חיבור PCIe: ישנם 2 תושבות, הראשונה היא PCIe X8 והשניה היא PCIe X1 בחיבור של PCIe X4.
  • חיבורי רשת – 2 חיבורים של 1 ג'יגה עם LOM
  • חיבורי תצוגה – 2 חיבורי Display Port כולל תמיכה ברזולוציית 4K.
  • חיבורי USB – כ-2 חיבורי USB 2.0 ו-2 חיבורי USB 3.0.

נתחיל בקהל היעד: קהל היעד למכונה זו (בשימוש כ-NAS) הם אלו שמעוניינים ליצור לעצמם גיבויים – הן מבחינת תכנים שקיימים להם, גיבוי מכונות Windows או לינוקס. HPE רשמית ממליצה על מערכת הפעלה ClearOS שמתאימה ל-SMB/SOHO אבל כמובן כל מערכת הפעלה מודרנית תרוץ ללא בעיות על מכונה כזו. (שימו לב: המערכות שנמכרות בארץ עם X3216 יהיו איטיות בהרבה מ-2 האופציות האחרות ש-HPE מוכרת ולכן לא כדאי "להשתולל" עם התקנת שרותים רבים על המכונה).

למי שמעוניין להקים LAB קטן לעצמו ורוצה את המכונה הזו כשרת NFS או iSCSI או SMB/CIFS – כדאי שיקח בחשבון שהביצועים שהמערכת שנמכרת בארץ, מנפיקה ביצועים די איטיים, כך שאם אתה רוצה להרים מספר דו ספרתי של VM, אולי עדיף שתחפש פתרון אחר או … תצטייד בסבלנות (או שתכניס כרטיסי 10 ג'יגהביט ו-SSD ל-NAS וכרטיסי 10 ג'יגה לשרתים האחרים שלך).

מבחינת המעבד עצמו, HPE ו-AMD עשו בסופו של דבר עיסקה לא רעה בכלל: ל-AMD יש מלאי רציני של מעבדי Opteron ישנים שהם רוצים להיפטר מהם (לטובת ה-Ryzen V1000 ו-EPYC Embedded), ו-HP חיפשו מעבדים לשרתים בקצה הנמוך מאוד ובמחיר זול מאוד. AMD, לפי השמועות, מוכרים את המעבדים בכחמישית מהמחיר שאינטל מבקשת על אותו מפרט וה-Opteron (לפחות ה-X3421) נותן פייט די רציני למעבדי ה-Atom C3000 של אינטל. התוצאה: הלקוח מקבל מכונה עם ביצועים די מכובדים כ-NAS (שוב, לא הגירסה שנמכרת בארץ) במחיר מאוד נמוך של כמה מאות דולרים. אגב, אחד השימושים הכי מעניינים שיצא לי לשמוע עליו בשימוש מכונות כאלו, אגב, הם מקומות עם תקציב די קטן שמריצים קונטיינרים. לפחות מ-2 מקומות (בחו"ל) שמעתי שהם מרוצים מהתוצאות.

מבחינתי, הבעיה המרכזית במכונות הללו היא התכנון שלהם. ב-HPE יכלו לדוגמא לוותר על יציאת Display Port אחת ולהחליף את חיבורי הרשת הקבועים בחיבור של מודול, כך שהלקוח היה יכול להחליף בין 2 חיבורי 1 ג'יגה ל-2 חיבורי 10 ג'יגה, ובנוסף הם יכלו להוסיף ללוח האם כניסת M.2 PCIe X4. הוספת 2 הדברים הללו היו יכולים לשדרג מכונה כזו לביצועי NAS מכובדים מאוד, לשמש כ-Storage למספר קטן של מכונות פיזיות המריצות וירטואליזציה ועוד, אבל כנראה ש-HPE מעדיפים שאם אתה רוצה משהו עם ביצועים קצת יותר גבוהים – תכיר את המכונות שלנו שמבוססות Xeon SP או AMD EPYC – שהן כמובן הרבה הרבה יותר יקרות.

לסיכום: האם הייתי ממליץ לאחרים לרכוש את המכונה הזו? כן, אם הצרכים שלהם הם מה שציינתי לעיל. אם הם צריכים משהו יותר חזק, אז עדיף שיחפשו את הגירסה עם מעבד X3421 או שיחפש פתרון NAS אחר או שיבנה לעצמו NAS. אישית, אני מקווה בזמן הקרוב לבחון לוח אם חדש (שעדיין לא יצא – מחברת ASRock Rack) המבוסס על מעבד EPYC Embedded ושתומך בהרבה יותר דיסקים קשיחים, יש בו כניסת M.2, תושבת PCIe X16 ו-2 כניסות 10 ג'יגהביט מובנות – ואת זה להכניס למארז 2U.