התקציב השנתי ורכישת ציוד

יש חברות שכבר הספיקו לתכנן את תקציב ה-IT לשנה הקרובה, יש כאלו שעדיין יושבים על המספרים. כמובן שאצל כל חברה הדברים שונים, יהיו כאלו שירצו בשנה הקרובה להחליף שרתים, להחליף סטורג', אולי לרכוש PC חדשים, לשדרג ל-SSD, לעבור לתקשורת פנימית יותר מהירה (10/40/50/100 ג'יגהביט), וכמובן שיש את כל עניין הפלטפורמות: לעבור לקונטיינרים, הטמעת CI/CD, להתחיל לעבוד בתצורת AGILE, לשכור אנשים/חברות ללמד את העובדים טכנולוגיות חדשות וכו'.

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

נתחיל בסטורג' SDS.

את עולם הסטורג' לקצה התחתון עד הבינוני ניתן לחלק ל-2: סטורג' קנייני (כזה שמגיע עם "ראש", מדפים), וסטורג' מבוסס תוכנה (SDS – כלומר Software Defined Storage). אם תשאלו את אנשי השיווק של הסטורג' הקנייני, תקבלו הילולים מכאן עד הודעה חדשה כמה הוא יציב, וכמה "לא כדאי" לרכוש SDS. המצב במציאות – די הפוך. בואו נאמר שאתם הולכים להוציא $50,000 על פתרון סטורג' ואתם מבקשים מכל העולם והחתול שלו הצעות מחיר לסטורג'. רוב ההצעות שתקבלו – הם SDS, גם אם הם לא יקראו כך בכותרת.

באופן עקרוני, סטורג' SDS מבוסס בעצם על חלקים COTS (כלומר Common Off The Shelf), כלומר שרת SDS אינו שונה מהותית מכל שרת שיש לכם בחדר/חוות שרתים שלכם. יש בו זכרון, מעבדים, בקר דיסקים, דיסקים קשיחים, וכרטיסי רשת. 2 הדברים ששונים בין סטורג' SDS לשרת רגיל הם בקר דיסקים (בחלק מהמקרים יש SAS Expander ו/או בקר RAID יותר יוקרתי הכולל תמיכה ל-SSD Caching) וכרטיסי רשת לחיבור מהיר (10/40/50 ג'יגה). הדבר העיקרי שהופך את השרת ל-סטורג', זו בעצם התוכנה שרצה עליו.

אחת השאלות הראשונות שאני נשאל לגבי פתרונות כאלו זה "האם יש תמיכה מהיצרן שרתים"? והתשובה בדרך כלל היא "כן", כלומר אם תבקשו מ-HP או DELL או LENOVO פתרון תוכנה של סטורג', הם ישמחו למכור לכם את התוכנה, עם או בלי שרת שלהם. היתרון הגדול בשיטה זו הוא שאם ציוד כלשהו בשרת נדפק, אתה נמצא תחת אחריות מלאה וטכנאי יגיע אליך תוך 4 שעות או ביום העסקים הבא (בהתאם לחוזה שרות שחתמת), ואם יש לך שאלות או תקלות עם תוכנת הסטורג', תוכל לקבל תמיכה מהיצרן שרתים או מיצרן התוכנה, כך שאתה מכוסה מכל צד. אפשר להשוות זאת לרכישת ברזלים + רשיונות של vSphere – אני לא מכיר מקרים שלקוח נשאר ללא מענה לתקלות אם הוא תחת אחריות של יצרן השרת והתוכנה.

מבחינת ביצועים – אחת השאלות שאני תמיד מקבל מצד כל מיני חברות שמתעניינות בסטורג' זה משהו בסגנון "אני צריך פתרון סטורג' עם X טרהבייט ועם כמות Y של IOPS רציפים". עם SDS אין בכלל את העניין הזה. רוצה X טרהבייט? תכניס כך וכך דיסקים ואם נגמר המקום, חבר JBOD בחיבור SAS-HD2. רוצה IOPS? תגדיל כמות זכרון ותוודא שיש לך SSD מהירים כמו P4800X או 905P של אינטל או Z-SSD של סמסונג (זה במקרה הקיצוני שצריכים IOPS גבוה בכל מחיר) או כל SSD שהוא Mixed והוא נמכר לך ע"י יצרן השרתים שלך. סמסונג, אינטל, מיקרון, טושיבה – כולם מייצרים כאלו.

שרידות – אחת הבעיות הקשורות במחיר – היא שרידות High Availability בסטורג' קנייני, כלומר כשצריכים "2 ראשים" לקבל שרידות. המחיר של ראש שני – יקר מאוד! לעומת זאת, בסטורג' SDS, מדובר בעצם על עוד שרת, רכישת JBOD לדיסקים וחיבור ה-JBOD ל-2 השרתים והפעלת פונקציית HA בתוכנת הסטורג'.

מה עם ביצועי רשת ב-SDS? שרת חזק יחיד עם כרטיסי רשת במהירות גבוהה, יתן ביצועים גבוהים ומענה לחיבור כל התשתית שצריך. מנסיון אישי על שרתים שהקמתי, הגעתי ל-250 ג'יגהביט תוך חיבור 150 שרתים, חלקם ב-NFS, חלקם ב-iSCSI וחלקם ב-CIFS (הייתי יכול להגיע ליותר אם היתה לי מכונה יותר חזקה ויותר כרטיסי רשת), כך שפתרון SDS יכול לעמוד בעומסים בלי שום בעיה.

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

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

עוד על SDS כתבתי כאן וכאן.

על ליבות, נימים, אינטל, AMD

בשבוע האחרון נשאלתי ע"י מס' אנשים לגבי ליבות, נימים לאחר שפירסמתי לינק (שאפרסם אותו שוב בהמשך פוסט זה) מבחינת ביצועים. למען פוסט זה, אבהיר שכשאני מדבר על "נימים", אני מדבר על Threads, אינטל קוראת לזה HT (או Hyper Threading) ו-AMD קוראת לזה SMT (או Simultaneous multithreading).

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

מדוע אינטל מציעה את אותם HT מזה שנים רבות? התשובה לכך פשוטה: מחיר. במשך שנים רבות אינטל היתה די בודדה בצמרת (אם נשכח לרגע את Sun, אבל המכירות של Sun לשעבר היו קטנות לעומת המכירות של אינטל, לפחות ב-15 השנים האחרונות) ואינטל גבתה מחירים גבוהים מאוד על מעבדים שהיו בסופו של דבר קצת יותר משופרים ממעבדי הדסקטופ שלה (כשאני מדבר על "קצת יותר משופרים" אני מדבר על כך שיש יותר זכרון מטמון ועוד מס' דברים שאינטל לא רצתה שיהיו במעבדי הדסקטופ, כמו תמיכת זכרון ECC, או RAS וכו'). אינטל תמיד ציינה שיצור מעבדים מעל 4 ליבות הוא תהליך יקר עם תפוקה יותר נמוכה, ובכך הם צודקים, אז אינטל ניסתה בעצם "להיפגש באמצע" עם לקוחות, בכך שהם הציעו את ה-HT. אינטל נקטה עוד כמה צעדים שיווקיים כמו "עידוד" היצרנים לייצר לוחות אם בעלי תושבת מעבד כפולה גם אם הלקוח רוצה מעבד יחיד ואין לו כוונה להוסיף מעבד (כיום זה מעט פחות רלוונטי מכיוון שיצרני השרתים מייצרים גם דגמים עם תושבת אחת).

אינטל, בשונה מ-AMD, מייצרת את המעבדים שלה כך שכל הליבות יושבות על פיסת סיליקון בודדת (במעבדי Xeon ישנים בעלי 3 ספרות, היו 2 פיסות סיליקון). ב-AMD לעומת זאת, הלכו על שיטה שונה לגמרי: בכל פיסת סיליקון ישנם 8 ליבות (בגרסאות מעבדים עם פחות מ-8 ליבות הם מבטלים ליבות עם מיקרוקוד), ובמעבדים כמו Threadripper ו-EPYC הם פשוט שמים עד 4 פיסות סיליקון (שנקראים CCX) ומשתמשים בטכנולוגיה שנקראת Infinity Fabric כדי לקשר בין הליבות במהירות של 100 ג'יגהביט לשניה. כך AMD יכולה למכור ברבע עד חצי מחיר מעבדים עם אותה כמות ליבות כמו אינטל.

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

עוד מקום שיש לו יתרון קטן ל-HT/SMT הוא דווקא בתחום ה-VDI. אם ניקח לדוגמא מערכת Windows ונפעיל אותה על VM, הליבה תהיה עמוסה (יחסית) בזמן ש-Windows עושה Boot, מעלה דרייברים, שרותים, ואפליקציות שונות, אולם מהרגע שהמשתמש ביצע Login והפעיל את האפליקציות שלו, הליבות די "משתחררות" והעומס יורד. מדוע ציינתי "יתרון קטן"? כי אם נרים פתרון VDI של מאות מכונות וירטואליות, שרתים עם כמות ליבות קטנה (פחות מ-16 ליבות פיזיות בכל השרת) ו-HT יתנו ביצועים נמוכים יותר בעת הפעלת מכונות ה-Windows הוירטואליות, וצריכת החשמל תהיה יותר גבוהה.

באתר Phoronix ישנו מאמר שמראה מה קורה אם אנחנו רוצים להריץ אפליקציות Multi Threaded על כמות ליבות שונה, החל מ-2 ליבות (ללא HT) ועד 64 ליבות פיזיות – והשוואה של התוצאות כשמפעילים HT/SMT. המבחנים בוצעו על שרת R7425 של DELL עם 2 מעבדי EPYC  של AMD והפצת לינוקס, אך התוצאות יהיו פחות או יותר זהות על מערכת עם מעבדי אינטל.

לסיכום: האם כדאי לכבות את ה-HT? כן, אם יש לכם מכונות VM עם ליבות מרובות או שאתם מריצים דברים "על הברזל" ואותן אפליקציות הן Multi Threaded. אם לעומת זאת, מכונות VM לא ממש מנצלות את הליבות עד תום או שהאפליקציות הן Single Threaded, אז HT לא ממש יפריע. בתחום ה-VDI לעומת זאת, כדאי לשקול לבטל את ה-HT – אחרי בדיקות ביצועים (יש הבדלים שונים בין פתרונות VDI הקיימים בשוק).

על vSphere ועל החלפת שרתים

יוצא לי מדי פעם לקבל תגובות נלהבות לגבי וידאו קליפים שאני מוציא על תוכנות מסויימות, בין אם זה על וירטואליזציה, על קונטיינרים וכו'. בחלק מהמקרים, כשאני מקבל תגובות נלהבות מצד מנמ"ר או CTO ורצון להטמיע אצלם דבר כזה, אני נאלץ "לצנן" את התלהבותו בכך שאני מסביר שמה שאני מדגים זה יותר לצורך שיתוף ידע ופחות לצרכי קידום מכירות (מה לעשות, אני נותן שרותי יעוץ ואינטגרציה, לא שרותי מכירות) ובחלק מהמקרים התוכנות הללו פשוט לא מספיק בשלות לפרודקשן לחברות גדולות. אני לדוגמא הייתי מאוד שמח "לדחוף" את RHV/oVirt כפתרון תחליף ל-vSphere אבל יש כמה באגים מעצבנים ופונקציונאליות שחסרה שפניתי בגינם ועד שהם לא יתוקנו, אני לא יכול להמליץ על פתרון זה ל-Enterprise.

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

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

אבל אחד הדברים שעדיין מתרחשים בארץ זה חוסר עדכון גרסאות. לא מעט מהחברות עדיין משתמשות בגירסאות 5.5 (הן מבחינת ESXI והן מבחינת vCenter) למרות שנשארו שבועיים בלבד לחיי התוכנה. ב-19 לחודש זה, המוצר "ימות" רשמית ולא יצאו לו כל עדכונים, גם לא עדכוני אבטחה קלים או קריטיים, ולכן חשוב לשדרג גירסה כמה שיותר מהר.

כאן מתקיים איזה משהו מוזר: חברות רבות שכן משתמשות בגירסה 6, אינן משדרגות לגירסה האחרונה (6.7) למרות שאין עלות נוספת מבחינת רשיון (אם כי יש צורך לשנות מספר סידורי – המספר הסריאלי שונה בין 6, 6.5 ו-6.7 ומספר של 6.0 לדוגמא לא יאפשר הפעלה של Schedule DRS על גירסה 6.5 ומעלה). כיום גירסה 6.7 היא גירסה בהחלט יציבה עם פונקציות רבות ותמיכה מתקדמת בדברים כמו NVME 1.3 (המאפשרת לקבל הרבה יותר מידע והתראות על SSD NVME) ודברים רבים נוספים.

וכאן מגיע עניין שדרוג שרתים.

בגירסה 6.7 של ESXI החליטו ב-VMWare להתחיל לנופף את גרזן התאימות אחורה. יש לך שרתים של HP מדור 6 לדוגמא או שרתים אחרים עם Xeon 55XX, Xeon 56xx, ויש עוד רשימה ארוכה של מעבדים שבהם גירסה 6.7 לא תעבוד. מדוע? אין לי גישה לקוד או ל-VMware עצמם, אך אני יכול לנחש שבשביל לתמוך בפונקציונאליות של ה-VT, כתבו ב-VMware הרבה קוד "בעייתי" שהם מתים להעיף, גם במחיר הסרת תאימות למעבדים מסויימים.

מטבע הדברים, מי שקורא את הרשימה ויש לו מעבדים ישנים המוזכרים ברשימה, יעדיף להתקין גירסה יותר ישנה של ESXi כמו 6.0 או 6.5. שם עדיין כמובן נשמרת התאימות.

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

PPW – או Performance Per Watt.

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

אם נשווה מעבד Xeon ישן מסידרה 55XX (בלי ה-V) או 56XX בדגמים L או E, למעבדי Xeon E5 V4 לדוגמא (או למשפחה החדשה של ברונזה, כסף, זהב, פלטינום במעבדי Xeon-SP) נראה שצריכת החשמל היא כמעט אותה צריכה, רק שרמת הביצועים שונה לחלוטין. מעבד V4 או SP יתן ביצועים שנעים בין פי 3 ל-פי 10 (תלוי בפלטפורמה, תוכנה וכו') בהשוואה למעבדים הישנים. פלטפורמות כמו vSphere גם יודעות לנצל את הפונקציונאליות החדשה במעבדים כדי לתת HA יותר טוב ודברים נוספים (PCI Pass-through משופר, תמיכה יותר טובה ב-SR-IOV ועוד).

יוצא מכך, שאם תשקיעו חד פעמית בהחלפת השרתים, תוכלו לקבל הרבה יותר (יותר מכונות VM פר ברזל, תמיכה של יותר זכרון, תמיכה בציודים מודרניים ועוד) , וצריכת החשמל שלכם תישאר פחות או יותר אותו דבר (סביר להניח שזה יהיה פחות, המעבדים כיום יותר חכמים ומתחשבים יותר בצריכת חשמל, במיוחד מעבדי EPYC של AMD בוירטואליזציה). נכון, תצטרכו להקים Clusters חדשים (אחרת אין HA), אבל זהו דבר שקל לעשות והעברת מכונות VM בין השרתים הישנים לחדשים מצריכה בסך הכל חיבור ל-Datastore השונים, כיבוי המכונה הוירטואלית והפעלתה מחדש ב-Cluster החדש (יכול להיות שתצטרכו לשנות אולי גם את ה-Network אם חיברתם ל-VLAN אחר).

אישית אני יכול לאמר שאני מפעיל LAB ואני זה שמשלם את החשמל על ה-LAB ומצאתי שהחזקת שרתים ישנים והרצת מכונות VM עליהם פשוט אינה כדאית, במיוחד אם אני משווה את הביצועים וצריכת החשמל למעבדים מודרניים. בשבילי עדיף לי לקנות 2 מכונות עם מעבדי EPYC במקום הפעלה של 4 שרתים ישנים עם מעבדי Xeon 56XX. כך אוכל גם להשתמש ב-NVME, גם אוכל להכניס כרטיסי PCIe 3.0, וכך אוכל להנות מ-יותר ליבות פר מעבד וכל זאת מבלי להפריש עוד כספים לחברת החשמל. אני חושב שהגיון כזה יכול לפעול גם אצל חברות.

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

הדברים המסוכנים בבחירת פתרונות VDI מסוימים

תחום ה-VDI נדחף חזק מאוד ע"י חברות רבות מאוד, החל מיצרני שרתים, יצרני GPU, חברות כמו מיקרוסופט, VMWare, Red Hat, Citrix וחברות רבות נוספות. הסיבה לכך היא שמדובר בסכומים מאוד רציניים שחברות ישלמו פר העברת מחשבי משתמשים ל-VDI, ולכן חברות רבות שמחות להציע את מרוכלתן בתחום ה-VDI, והאמת היא שחלק מהפתרונות מסוכנים מבחינת אבטחת מידע.

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

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

מה הסיכון? הסיכון כרוך בבעיה מושרשת שקיימת ב-RDS ובפתרון הדומה שיש ל-Citrix וב-RDSH של VMware: ל-Windows יש יכולת גרועה לנטר ולהגביל תהליכים (Process). אם Process כלשהו יפעיל את עצמו 100 פעם, למכונת ה-Windows לא תהיה שום בעיה עם זה. אם ה-Process בולע זכרון כאילו אין מחר – גם עם זה ל-Windows אין בעיה. תוסיפו לזה את העובדה שמעתה יש עשרות סשנים כאלו פתוחים ע"י משתמשים שלא ממש מבינים במחשבים, ומספיק שאחד מהם הוריד משהו מסוכן שמתחיל לעשות Spawn ל-Process שהוא מקים ו"לשתות" זכרון, ותוך כמה דקות כולם סובלים. אם לעומת זאת הסשן דסקטופ היה מגיע ממכונה וירטואלית מיועדת, אז רק אותו משתמש היה סובל (טוב, למעט אם מדובר בנוזקה שיודעת להשתמש ברשת וחולשות אבטחה של Windows שלא עודכנו באותה חברה). זה די עצוב שבשנת 2018 לפתרונות שמבוססים על סשנים ולא על VM אין מספיק מגבלות על הדברים הללו. אפילו קונטיינרים מכילים את ההגנות הנ"ל.

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

לכן, ההמלצה שלי כשמקימים VDI, ולא משנה על איזו טכנולוגיה היא עובדת, היא VM פר משתמש, כלומר אם יש לנו 50 משתמשים, יהיה לנו Pool של מינימום 50 מכונות וירטואליות שינוהלו ע"י אותו פתרון שנבחר, עם Portal וכו' פר משתמש ואם צריך – גם Published App/Xen App או ThinApp וכו' של אפליקציות שמוצגות עצמאית.

פוסטים קודמים שכתבתי בנושא:

השורה התחתונה בעניין הטמעת VDI

כשרוצים להטמיע VDI, בין אם מדובר על כמות של כמה עשרות מכונות VDI בלבד או אלפים, יש צורך במעבר כמה שלבים.

השלב הראשון, עוד לפני שבכלל חושבים על תקציב וטכנולוגיה, היא עניין הכדאיות ואצל רבים אחרים זה לשכנע שלא מדובר באיזה "טרנד" חולף (זוכרים את טרנד ה-Diskless עם PXE בעבר הרחוק? כן, זה היה טרנד שנדחף ע"י Sun וכיום יש בו שימוש פה ושם. אישית אני משתמש בו ב-LAB בשרתי ESXi כשאני לא מעוניין להכניס דיסקים או דיסק-און-קי כדי לבצע Boot מהם).

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

החסרון: המחיר. צריך Storage יותר מהיר ממה שיש אצל רוב החברות (בעברית פשוטה: בלי דיסקים מכניים, עם SSD שהוא Mixed Intense) כי כשיום העבודה מתחיל והעובד יושב ליד המחשב אחרי שהכין לעצמו שתיה והוא מפעיל את ההתחברות ל-VM שלו, הוא רוצה זמן תגובה מהיר, ול-Windows יש Profile וזה צריך לעלות, מה שיוצר עומס עצום על ה-Storage (או מה שנקרא "סופה"/Storm) ועל השרתים שמריצים את מכונות ה-VM. בנוסף יש צורך במספר כרטיסי GPU כשעולים כל אחד כמה אלפי דולרים ושרתים מודרניים מהשנתיים שלוש האחרונים בשביל להריץ את כל העסק. בקיצור: ההוצאה הראשונית היא הוצאה גדולה (ועוד לא דיברנו על רשיונות תוכנה, להיכן לגבות, אם לרכוש Thin Clients או להשתמש ב-PC הקיימים עם לינוקס וכו').

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

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

סטורג'

לא חשוב איזה סטורג' יש לכם, כל עוד יש בו דיסקים מכניים עם 2-4 SSD לצרכי Cache – הוא לא יספק בשביל להריץ מערכת VDI רצינית. מערכות Windows לדסקטופ "טוחנות" דיסקים עם הפרופילים, ודיסקים מכניים פשוט איטיים לזה וה-Cache קטן מדי. יכול להיות שתצטרכו או להוסיף מדף של SSD Mixed או סטורג' שהוא נטו SSD Mixed. אני מדגיש את Mixed כי Windows דסקטופ אוהב "להשתולל" עם הקריאה וכתיבה. זה לא Windows Server.

פתרונות וירטואליזציה מבוססי HCI

ב-HCI אפשר להוסיף כמובן דיסקים, אבל רוב הסיכויים שתצטרכו לרכוש עוד כמה שרתים בשביל VDI חוץ ממה שיש לכם כרגע. ב-HCI, מהירות ה-IOPS הכה חשובה מגיעה מריבוי שרתים ופחות מריבוי קבוצות דיסקים.

שרתים

כאן העניין די פשוט: תצטרכו שרתים מדור קודם או דור נוכחי, בהתאם לדגמים המועדפים עליכם. אפשר שרתים של 1U אבל עדיף 2U שאפשר לדחוף לתוכם יותר מ-GPU יחיד.

חיבור לסטורג'

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

סוויצ'ים

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

רשיונות לוירטואליזציה

מיקרוסופט: כדאי לדלג. עוד ילמדו יום אחד בבתי הספר לעסקים על השגיאה הגדולה שמיקרוסופט עשתה בכך שתמחרה את מחירי ה-Windows Server 2016 מחוץ לשוק (ב-VMWare מודים למיקרוסופט, תוצאות הרבעון האחרון והקודמים מראים על הגירה מהפתרון של מיקרוסופט ל-VMware). אתם תצטרכו לשלם פר ליבה ומכיוון שפתרון VDI מצריך מכונות מרובות ליבות (יותר מ-4 פר מעבד), המחיר שתשלמו יהיה גבוה בהרבה מכל פתרון אחר, אלא אם יש לכם הסדר מיוחד עם מיקרוסופט. חושבים להשתמש ב-Windows Server 2012R2? תצטרכו רשיון Data Center וגם אז התמיכה ב-VDI (למעט RDS) היא די חלקית, השיפורים הרציניים קיימים רק ב-Windows Server 2016.

VMWare: לא זול. תצטרכו את Enterprise Plus ואת Horizon 7.

Citrix: רוצים פורטל מסודר? נתחיל ב-3000$ על Xen Server (רשיון Enterprise ל-2 מעבדים פר שרת) ועל כך נוסיף את Xen App ואת Net Scaler (כתשלום נוסף כמובן). לא בטוח שהפתרון הזה זול ממש בהשוואה ל-VMWare.

Oracle VM Server: כבר עדיף ללכת על הפתרון של Citrix.

RHV של רד-האט: 900$ פר שרת (לתמיכה בשעות עסקיות+ או 1500$ לתמיכה 24/7). לפתרון של רד-האט יש חסרון כלשהו בכך שה-GUI אינו הכי "משופשף", כך שזה יותר מתאים לצוות הוירטואליזציה לנהל בשיתוף צוות לינוקס.

"תצורת ערימה"

יש כאלו שלא ירצו פתרון VDI עם פורטל אלא סתם פשוט "ערימה" של מכונות VM לדסקטופ. כאן גם פתרונות HCI יכולים להתאים (vSAN, Nutanix, Simplivity) אבל חשוב לזכור שכל פתרון HCI יחייב רכישת עוד שרתים בהטמעה גדולה על מנת לקבל תצורת IOPS מאסיבית. אפשר כמובן גם להרים זאת בתצורה הזו (ללא פורטל) בכל פתרון וירטואליזציה רגיל עם דיסקים מקומיים (לא HCI), אבל תצטרכו SSD Mixed וכרטיסי GPU לשרתים.

רשיונות Windows

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

חסכון

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

אם הולכים ב"תצורת ערימה" ורוצים להשתמש בדיסקים מקומיים, ההצעה הראשונה שלי היא להשתמש במה שנקרא JBOF (כמו JBOD, רק Flash). כרגע היצרן היחידי שמציע זאת זו חברת SuperMicro, והפתרון הוא בעצם קופסא שאליה מכניסים את ה-SSD ומאחורה יש לה יציאות PCIe מיוחדות. מחברים את היציאות האלו (אחת פר שרת) לכרטיס HBA עם כבל יעודי ומנהלים את הדיסקים מה"שרת" של SuperMicro. כך אתם מקבלים ביצועי SSD גבוהים מאוד ומבלי המגבלה של רכישת דיסקים ספציפיים של יצרן השרתים שלכם. בכל קופסא כזו אפשר להכניס כמות "צנועה" של עד 1 פטהבייט של אחסון. ההצעה הזו יכולה לחסוך המון הואיל ואינכם תלויים בדיסקים שיצרן השרתים מוכר (בעשרות אחוזים מעל מחיר השוק, גם אם מדובר באותו דגם אחד לאחד שהיצרן שרתים מוכר. אף אחד מיצרני השרתים לא מייצר דיסקים).

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

ישנן עוד אפשרויות שעבדכם הנאמן שוקד על נסיון איתן אך הן עדיין לא בשלות ל-Enterprise.

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

על VDI ועל GPU בשרתים

כשאנחנו מקימים פתרון וירטואליזציה, ברוב המקרים אנחנו מקימים מערכות VM עם מערכת הפעלה לשרתים, כמו הפצות לינוקס למיניהן, גרסאות Windows Server, אולי FreeBSD וגם Appliances וירטואליים למיניהן. המכנה המשותף לכל אלו – אנחנו לא צריכים כרטיס גרפי יעודי בשרת בשביל להשתמש באותן מכונות וירטואליות.

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

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

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

התפקיד המרכזי של GPU בפתרון וירטואליזציה (וזה לא משנה איזו וירטואליזציה) הוא בעצם לקחת את כל העניין של "ציור" המסך הוירטואלי ולהזרים אותו אל ה-Client שרץ על המכונה הקטנה שנמצאת אצל המשתמש הסופי. לשם כך, כשאנחנו מתקינים GPU המיועד לשרתים, אנחנו מתקינים על כל VM תוספת שנקרא vGPU או Virtual GPU. במערכת זה יופיע כמעין "כרטיס" נוסף ב-Device Manager ואנחנו נצטרך Client יעודי (למעט במקרים של מיקרוסופט ששם RDP עדכני נותן את הפתרון עם תמיכה ל-RemoteFX. שימו לב ש-RemoteFX עובד טוב עם תוכנות תלת מימד רק ב-Windows Server 2016 ומעלה) להתחבר אליו ומשם נקבל את ההאצה.

מהי בעצם אותה האצה? ה-GPU בשרת הוירטואליזציה יוצר בעצם מסך (כמו המסך שמולכם) כרגע ועליו הוא "מצייר" את החלונות, הגרפיקה ואלמנטים ויזואליים נוספים. ברגע שהוא מסיים ליצור Frame של המסך, הוא משדר זאת בזרימת (Stream) וידאו אל ה-Client, כאשר ה-Client יכול להיות PC פשוט, מק, מכונת לינוקס מקומית, iPAD, iPhone או טלפון/טאבלט עם אנדרואיד. לא חשוב מה היכולות הגרפיות של מכשיר הקצה.

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

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

וכאן מגיעים כרטיסי GPU שונים.

בניגוד לפתרונות וירטואליזציה ששם אפשר "לדחוף" כמה שיותר מכונות וירטואליות, כל עוד יש מספיק משאבי זכרון ומעבד פנויים, ב-GPU הדברים מוגבלים. כמה מוגבלים? בד"כ GPU לשרתים יכול לשרת מקסימום בין 16 ל-32 משתמשים על אותו GPU. לכל מכונה וירטואלית אנחנו מגדירים כמות זכרון מה-GPU (בין חצי ג'יגה לדסקטופ בסיסי ועד 4 או 8 ג'יגה לדסקטופ וירטואלי שמריץ מערכות גרפיקה כבדות) ואין אפשרות ל-Over Provision, כלומר אם נרצה להרים 60 מכונות וירטואליות כ-VDI למשתמשי קצה, נצטרך בעצם 2 כרטיסי GPU יקרים שאת הזכרון שלהם בין המכונות הוירטואליות.

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

אז מה יש לשוק להציע מבחינת GPU?

אם נסתכל בפתרונות של nVidia המוצעים לשוק, יש את כרטיסי ה-GRID K1 ו-K2. אלו כרטיסים שיכולים להעביר סשנים של דסקטופ בסיסי (שוב – אופיס, דפדפן) בצורה לא רעה, אך אלו כרטיסים ישנים. כיום ל-nVidia יש כרטיסי TESLA, כאשר סידרה M מתאימה לדסקטופ בסיסי וסידרה P יותר מתאימה למשתמשים כבדים ואילו סידרה V מתאימה למשתמשים ממש כבדים (עריכת וידאו, פוטושופ בצורה מסחרית וכו').

מהצד של AMD יש את משפחת ה-Radeon Pro ודגמי S7150 (שמתאים עד ל-16 משתמשים) ו-S7150 X2 שמתאים עד ל-32 משתמשים כולל עבודות תלת מימד. כרטיס נוסף ש-AMD מוציאה בקרוב הוא ה-Radeon Pro V340 שמתאים למשתמשים כבדים (עד 32 משתמשים). היתרון של AMD מול nVidia הם מחירים נמוכים (לעיתים חצי מהמחיר ש-nVidia מבקשת) בלי להתפשר על ביצועים.

מי ממערכות הוירטואליזציה הקיימות צריך GPU למכונות VM דסקטופ? התשובה פשוטה: כולם.

ומה בדבר הכנסת כרטיסים "ביתיים" פשוטים לשרת כמו Geforce GTX 1080TI או VEGA 56/64 כפתרון זול? את זה לא תוכלו לעשות מכיוון שהדרייברים מזהים את הכרטיסים ומסרבים לעבוד איתם. פתרון של כרטיסים ביתיים בוירטואליזציה מתאים רק כשממפים (PCI Passthrough) את הכרטיס למכונת VM יחידה (רק מי בדיוק ירצה לעבוד מול שרת רועש?). פתרון של כרטיס ביתי יכול להתאים אם מריצים פתרון וירטואליזציה מקומי כמו KVM על לינוקס בתחנת עבודה כאשר מכונת VM של Windows משתמשת ב-KVM עם מיפוי לכרטיס ה-GPU. העניין קצת מורכב (ולא קיים בפתרונות כמו VMWare workstation, VirtualBox).

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

בפוסט הבא נדבר על השורה התחתונה, הכסף.

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

על VDI: מה הפתרון שיכול להתאים?

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

מבחינת מתחרים, יש כמה ש"תפורים" ל-VDI (בצורה מלאה):

  • מיקרוסופט RDS
  • חבילת המוצרים של Citrix
  • VMWare Horizon
  • RHV/oVirt * (כמעט מלאה)

יהיו כמובן אלו שיציצו ברשימה הקטנה ויטענו שחסרים המון פתרונות אחרים, החל מ-Hyper-V ובוודאי יש עוד כמה. התשובה לכך היא שכשאני מדבר על "צורה מלאה" הכוונה מוצר שכבר יש בו פורטל עבור משתמש הקצה להריץ אפליקציות או להיכנס לתוך VM דסקטופי ולהתחיל לעבוד. על oVirt/RHV שמתי כוכבית כי לפתרון חסר מספר "תפירות" בשביל לתת פתרון מלא. כמו כן לא ציינתי מוצרים לדסקטופ כמו VirtualBox, VMWare workstation, Fusion, KVM מכיוון שאלו פתרונות שרצים על דסקטופ, לא על שרתים.

מבחינה טכנית, אין פתרון אחד שיכול להתאים לכולם, וברשותכם אדגים על משרד עו"ד קטן, 10 מחשבים (כולל פקידות ועו"ד). אם מחר משרד כזה היה פונה אליי ומבקש יעוץ לגבי VDI, השאלה הראשונה שהייתי שואל אותו היא פשוטה: מה יותר חשוב לך? מחיר נמוך או שרידות גבוהה? אם מדובר בלקוח ש-2 שרתים, NAS וסוויטצ' ורשיון Essentials של VMWare יקר לו, אז השרידות יורדת מהפרק ובמקרים כאלו שרת ESXI חופשי עם דיסקים מקומיים (נניח RAID-1 ועוד RAID-1 לצרכי גיבוי) יכול להיות פתרון VDI בשבילו (זיכרו, אין לו כסף מעבר לברזל יחיד), כאשר כל המכונות המקומיות עוברות P2V ולאחר העבודה כל העובדים מתחברים ב-RDP. מחיר הרשיונות? אפס (ה-Windows עובר מכונה, לא נשאר מקומית) ויכול להיות שהדבר היחיד שיצטרך לשלם (מעבר לעבודה ולברזל) הוא על תוכנת גיבוי. נכון, בפתרון כזה אין שום פורטל, אבל מצד שני הלקוח לא מוכן להוציא כסף. פתרון Xen או Hyper-V יכולים גם להתאים אך ברוב המקרים פתרון של ESXI יהיה הכי מהיר להקמה (ברוב המקרים אפשר להוריד את ה-ISO מהיצרן שרת, להירשם ל-VMWare לקבל מפתח חינמי ולהתחיל בעבודה).

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

ב-RDS ובמקרה של Citrix (לא XEN Server) הפתרון בגדול הוא כמעט אותו דבר (למען האמת Citrix בנו את הפתרון עוד ב-Windows NT ומיקרוסופט סיכמו עיסקה עם Citrix להשתמש בבסיס לצרכי RDS אך עם פרוטקולים שונים וכו' וכו'): אתה מרים שרתים (ב-RDS לדוגמא זה Windows 2012/2016 Data Center), מגדיר את הדברים (במקרה של Citrix מתקין עוד כמה תוכנות) ואז כל משתמש מקבל בעצם Session, ה-Session יכול להיות דסקטופ מלא או אפליקציה ספציפית. ב-Citrix יש יתרון שיש לך Portal קל להבנה והוא יכול להכיל גם אפליקציות עצמאיות וגם Session של דסקטופ (קופ"ח מכבי משתמשת בכך לדוגמא, הרופאים שביקרתי אצלם והשתמשו בזה לא ממש מתפעלים).

וכאן גם נעוצה הבעיה המרכזית גם בפתרון של Citrix וגם בפתרון RDS: ניהול משאבי החומרה. ב-VM אני מגדיר כמות ליבות, כמות זכרון, כמות דיסק, חיבור רשת וכו', ואם המשתמש לדוגמא גולש לאיזה אתר והאתר נפרץ ומישהו הזריק לשם Coinhive, אותו משתמש ספציפי יתלונן שה-VM שלו איטי (טוב, הוא לא יאמר "VM" 🙂 ) אבל הדברים לא ישפיעו על מכונות VM אחרון (למעט בנוזקה שיודעת להשתמש ברשת). בפתרונות שאינם מבוססי VM, סביר להניח שגם אחרים יושפעו, כי אין הפרדה מוחלטת של משאבי CPU וכו'. יהיו כמובן אלו שיאמרו שהם משתמשים בסביבה סגורה ללא אינטרנט, ושם יכולים להיות באגים של תוכנות שונות שיש בהן Memory Leak – בהצלחה למצוא זאת. יחד עם זאת, ל-RDS ולפתרון של Citrix יש יתרון נוסף בכך שמבחינת חומרה, אין צורך להשקיע בסטורג' סופר יוקרתי (בניגוד לפתרון VDI מבוסס על מכונות VM).

ומה עם Horizon? ל-Horizon יש יתרון של גם וגם וגם. הוא תומך בפתרונות RDS, הוא תומך באפליקציות כ-Session (מה שנקרא ThinApp) וגם במכונות VM מלאות והכל נגיש למשתמש בפורטל נחמד. החסרון? בניגוד ל-RDS "רגיל" או הפתרון של CItrix שיכולים לרוץ על סטורג' די פשוט (שבנוי מדיסקים מכניים) – פתרון של Horizon עם מאות או אלפי מכונות יצריך סטורג' מבוסס SSD.

מה עם פתרון מבוסס קוד פתוח? עם oVirt יש פורטל (אך לא ניתן להשתמש באפליקציות כ-Session), ואפשר לעבוד איתו כפתרון VDI (הוא גם תומך בכרטיסי Tesla כמאיצים). העבודה עם RHV/oVirt מצריכה הכרת מושגים מעט שונים. RHV הוא הפתרון המסחרי.

ומה עם עננים ציבוריים? כאן כדאי לזכור שאנחנו חיים בישראל, וה-Latency מחו"ל לארץ (למעט אם רכשת חיבור יעודי ב-7500$ ומעלה!) מתחיל ב-100 מילישניות וזה די יגרום למשתמשים סבל, במיוחד כאשר יש משתמשים רבים.

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

חומרה ל-VDI: מציאות מול חומר שיווקי

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

כאן צריך לקחת בחשבון 2 נקודות מאוד חשובות:

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

בואו ניקח דוגמא מתחום הוירטואליזציה: אינטל רוצה לדחוף את משפחת מעבדי ה-Xeon-SP שלה (תחת שם קוד: Purley) ומוציאה דו"ח איך המעבדים שלה מנצחים בנוק-אאוט את המתחרים, מעבדי ה-EPYC של AMD. כך הם מציגים גרף שבו מעבד ה-Xeon 8160 שלהם מהיר ב-37% מהמעבד 7601 EPYC של AMD.

נשמע מרשים, לא? שליש יותר! רק שבאותיות הקטנות רואים את הבדיקה המוטעה: אינטל הקימה 58 מכונות וירטואליות על ה-Xeon 8160 ועל ה-EPYC 7601 הם הקימו .. 42 מכונות וירטואליות. חשוב לזכור: בניגוד למצב שבו יש לנו שרת ללא וירטואליזציה ואנחנו מריצים אפליקציית Multi Threaded – לאפליקציה זמינים כל משאבי השרת, ואילו במכונה וירטואלית, המשאבים הזמינים לאפליקציה הם רק המשאבים שהגדרנו ל-VM. במילים אחרות: מעבד ה-EPYC במדידה ישב עם 16 ליבות פיזיות בלתי משומשות במבחן (מתוך הנחה שהם הגדירו 2 ליבות וירטואליות פר VM כאשר המכונה שהם משתמשים לבחינה מכילה 2 מעבדי EPYC 7601), כך שאם הם היו מקימים עוד מכונות וירטואליות על אותה מכונה, התוצאה היתה מתהפכת!

וכך בעצם מטעים לקוחות.

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

בשביל להקים תשתית VDI, אנחנו צריכים להחליט מה תהיה תצורת ה-VM. סביר להניח שנגדיר 2 ליבות, 4-8 ג'יגהבייט זכרון, ו-50-100 ג'יגהבייט דיסק. המכונה עצמה תהיה Linked Clone למכונת Master VM (אני לא מדבר כרגע על הפתרון RDS של מיקרוסופט, אלא מכונות VM).

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

ועל מה ירוצו כל מכונות ה-VM הללו? כמובן, על שרתים פיזיים. כאן בעצם חברות מתחלקות ל-3:

  • יש חברות שיקימו את ה-VDI על שרתים שקיימים בחברה תוך הסבתם לסביבת VDI חדשה.
  • יש חברות שיבחרו לרכוש שרתים חדשים ולהקים זאת כ-Hyper Converged (או HCI)
  • יש חברות שיקנו שרתים חדשים מבוססי מעבדי אינטל, סטורג', סוויצ'ים ויקימו עליה את תשתית ה-VDI.

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

  • שימוש בתשתית קיימת: למעבדי Xeon מהראשונים עד V4 (לא כולל) כמות ה-Cache היא קטנה והביצועים הם לא רעים – אם בונים VDI לכמות משתמשים של עשרות בודדות. צריכים כמה אלפי מכונות VM ל-VDI? המעבדים הללו יהיו חלשים מדי. (כמות Cache רצינית נמצאת במעבדים כמו Xeon E5 v4 2998/2999 אבל אינטל די מתחמנת עם המספרים ומכלילה אותם כ-"Smart Cache" מבלי לפרט רמות L1, L2, L3 – והמעבדים הללו סופר יקרים – 4000$ לחתיכה וזה במחיר של אמזון. בארץ – זה הרבה יותר גבוה).
  • שימוש ב-HCI: על פניו הרעיון הוא טוב, אולם בניגוד ל-VM אחרים, VDI מחייב IOPS גבוה, ובשביל להשיג IOPS גבוה, אתה צריך לרכוש המון (תחשבו במושג של ארונות) שרתים, כך שזה לא ממש משתלם, במיוחד במחירים בארץ שגבוהים מאוד בהשוואה לארה"ב לדוגמא.

שרתים חדשים מבוססי אינטל Xeon SP: המחירים של אינטל גבוהים (במיוחד כאן בארץ, ולא חשוב מי היצרן/ספק), ואם לדוגמא אתה רוכש מכונה עם 2 מעבדים בעלי 8 ליבות (כלומר 16 ליבות במכונה), אתה יכול לרכוש מכונה עם 2 מעבדי EPYC בעלי 16 ליבות באותו מחיר ולקבל בעצם 16 ליבות בחינם. במקרים של מעבדים עם יותר ליבות, המחיר של מכונה עם אותו מפרט אך עם מעבדי EPYC יהיה זול בהרבה וזה מגיע למצב של מעבדי הפלטינום של אינטל ששם אתה יכול לחסוך מינימום 6000$ פר מעבד ולקבל במקום 28 ליבות בקצה הכי גבוה של אינטל – 32 ליבות במערכת מבוססת EPYC.

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

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

התוצאה (המחירים הם של Dell ארה"ב אחרי הנחה של 250$, המחיר בארץ יהיה גבוה בהרבה, לא חשוב איזה יצרן):

  • שרת DELL R7425 עם 2 מעבדי EPYC 7601 (כל מעבד עם 32 ליבות) ו-512 ג'יגהבייט זכרון: מחיר של 24,079 דולר.
  • שרת DELL R740 עם 2 מעבדי Xeon 8180 (כל מעבד מכיל 28 ליבות) ו-512 ג'יגהבייט זכרון: המחיר הוא: 37,834 דולר

במילים אחרות: אתה תשלם 13,755 דולר על פחות ליבות (8 פחות), פחות Cache (באינטל תקבל 38.5 מגה למעבד, ב-AMD תקבל 64 מגה למעבד), פחות ערוצי זכרון ישירים (אינטל: 6, מול AMD: 8) ופחות נתיבי PCIe (אינטל: 48, ואצל AMD: 128), ועוד לא דיברנו על כך שמבחינת Performance Per Dollar ומבחינת Performance Per Watt ההצעה של אינטל לא משתלמת בהשוואה להצעה של AMD.

זו ההצעה של הקצה העליון, ברמות היותר נמוכות ההפרש יורד אולם עדיין ההצעות של AMD יהיו יותר זולות מההצעות של אינטל Xeon SP. אפילו מנכ"ל אינטל לשעבר (בריאן קרזניץ) מודה בראיון שהמעבד של AMD הולך לכבוש חלקים רציניים בשוק ואינטל תנסה לעצור את זה ב-20% מהשוק.

מבחינת תצורת VDI, יש 2 דרכים לממש זאת: בתצורת "מפלצות" ואז כמות השרתים קטנה, או בתצורה של שרתים יותר קטנים. אישית הייתי ממליץ לקחת את שיטת ה"מפלצות" מכיוון שכמות השרתים במחיר הגבוה היא קטנה וניתן לדחוס אליה מאות מכונות VDI (תלוי כמובן בכמות הזכרון). כך לדוגמא: אם יש צורך ב-500 מכונות VM ל-VDI, אפשר בקלות להכניס אותם ל-2 מכונות (או 3 בשביל שרידות והתרחבות עתידית). אגב, אם תלכו לפי המחירים של VMWare ומעבדי EPYC, תשלמו פחות פר מכונה (ב-VMWare אין חשיבות לכמות ליבות פר מעבד, במיקרוסופט בהחלט יש!).

בכל מה שקשור ל-GPU, רבים אצים רצים לרכוש את הכרטיסים של nVIDIA כדי להכניס לפתרונות VDI, אולם כרטיס כמו AMD FirePro S7150 X2 שנותן ביצועים לא פחות מ-Tesla בכל הקשור ל-vGPU רק בפחות ממחצית המחיר. אפשר לרכוש אותו ישירות מיצרן השרתים או מיבואן AMD בארץ.

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

  • האם הפלטפורמה יציבה? בהחלט.
  • האם היצרנים כבר מכרו כאלו פה בארץ לחברות גדולות? בהחלט (בדקתי)
  • האם ציודים קיימים (כרטיסים שונים, דיסקים, GPU וכו') נתמכים? בהחלט.
  • האם בארץ ליצרנים יש שרתים כאלו שאפשר לבדוק במשרדיהם? ל-Dell ו-HPE כן. לנובו – לא. לחברת Cisco יש שרתים עם מעבדי EPYC (שרתי Cisco UCS C4200 ו-Cisco UCS C125 M5 Rack Server Node שניתן להכניס 8 כאלו בשרת 2U) אך לא ידוע לי אם יש להם שרת כזה בארץ לבדיקות/הדגמה. במידה ואתם מעדיפים שרתים מיצרנים אחרים (Asus, ASRock Rack, SuperMicro, TYAN) – לכולם יש משפחות שרתים עם EPYC.
  • האם יש תמיכה במערכות הפעלה? כולן עובדות ללא צורך בטלאים מיוחדים, כולל RHEL, VMware 6.5U3, Windows Server 2012R2/2016, CentOS 7.5.
  • האם מעבדים עתידיים יתאמו לשרתים הנוכחיים? כן. תושבת ה-SP3 של AMD תומכת במעבד הנוכחי ובדור שיצא אחריו לפחות (שיכלול עד 48 ליבות) כך שאם תרצו לשדרג את השרת למעבד עתידי, כל מה שתצטרכו לעשות זה לעדכן BIOS/UEFI ולרכוש את ה-Kit מהיצרן שרתים. AMD בדרך כלל שומרת תאימות ל-5 שנים קדימה מהופעת התושבת לראשונה.

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

האם לעבור ל-vSAN/Nutanix/HCI?

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

ואז הגיעה חברת VMware עם vSAN ואחריה Nutanix שהחלה "לגנוב" ל-VMWare לקוחות, וגם Simplivity ואפילו רד-האט עם פתרון ה-RHV בגירסאות האחרונות. בקיצור – ב-4 שנים האחרונות חברות החלו יותר ויותר להציע פתרונות עם העדפה ל-Scale Out מאשר Scale Up. פה בישראל Nutanix כובשת יותר ויותר לקוחות מכיוון שהמערכת שלה גמישה כדי להריץ את הוירטואליזציה הנוכחית שלך או את פתרון הוירטואליזציה שלהם (KVM).

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

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

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

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

נתחיל ב-Scale Up ונתייחס לבחירה הפופולרית בארץ לוירטואליזציה – של VMWare. נניח שיש לי כאן 10 שרתים שמריצים ESXi, ועל 2 מכונות רץ VCSA ומכונה שלישית משמשת כ-Witness ("עד") על מנת ש-VCSA ירוץ תמיד (בבקשה, תיפטרו כבר מה-vCenter שרץ על Windows). מה עושים כל שאר השרתים? מריצים מכונות וירטואליות. הם שרתים "טיפשים" וחוץ מהשרותים ש-ESXi שמריץ, המכונה כמעט ולא מריצה שום דבר אחר אלא את המכונות הוירטואליות שלכם. כל מה שקשור לדיסקים לדוגמא "נזרק" לביצוע ע"י הסטורג' עצמו (אם הוא תומך ב-VAAI וכו'), ועבודת ה-Network בקושי לוקחת משאבים, והיא מנוהלת ע"י ה-vCenter/VCSA (כשמדובר ב-DVSwitch) או ה-ESXi (כשמדובר ב-vSwitch רגיל). כל עניין ה-Compute רץ על המעבדים והזכרון.

ב-Scale Out לעומת זאת, הכל הפוך. בפתרון של VMWare יש לנו מודול נוסף של vSAN שיוצר לנו Datastore מבוסס על הדיסקים המקומיים (בקבוצות של SSD+זוג מכניים) וגם על הדיסקים של השרתים השכנים, כלומר בשרתים מוקצה זכרון ו-CPU לניהול האחסון, שרידות וכו' וכו'. במקרים של Nutanix/Simplivity – יש ערימה שלמה של שרותים נוספים שרצים פר שרת. נקודה חשובה נוספת: בשביל לקבל IOPS גבוה, חייבים לרכוש מספר גדול של שרתים, אין דרך להתחמק מכך.

העניין החשוב שצריך לקחת בחשבון הוא לא הקניה של ה-3-5 מכונות בשביל Nutanix/Simplivity, או הרשיונות והדיסקים שצריכים לקנות עבור ה-vSAN, אלא הגדילה העתידית.

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

בסיטואציית Scale Out לעומת זאת, כמעט הכל הוא פי כמה וכמה, כלומר אם אנחנו רוצים אחסון נוסף, אז עם vSAN אנחנו צריכים זוג מכניים+SSD מהיר כפול כמות המכונות שיש לנו (לפחות לפי ה-Groups שהגדרנו). צריכים עוד זכרון? אפשר כמובן להרחיב בצורה יחידנית וכנ"ל לגבי מעבדים, אבל ההמלצה היא לא לעשות כך אלא להוסיף עוד שרתים פיזיים עם כמות מסויימת של דיסקים זכרון ומעבדים, כך שכל פעם כשאנחנו צריכים משאבים נוספים, אנחנו מזמינים שרתים נוספים. טכנית אין שום בעיה להגדיל אחסון מ-2 טרה ל-20 טרהבייט באחד מהשרתים, רק שאותה מכונה שהגדלנו תהיה בקושי מסונכרנת עם האחרים כי היא תצטרך לעבוד הרבה יותר קשה מהשרתים האחרים.

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

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

  • כמה סטורג' אנחנו באמת משתמשים?
  • האם את מס' ה-VM שיש לנו אנחנו יכולים לשים בכמות השרתים שנקנה לצרכי Scale Out?
  • מה לגבי מכונות VM שאינן פרודקשן? האם כדאי לחשוב על פתרון וירטואליזציה חינמית כדי להריץ אותם שם על המכונות הקיימות?
  • האם החברה מתכננת פרויקטים נוספים שיצריכו רכישת שרתים נוספים עם פתרון Scale Out?
  • האם החברה חושבת על פתרון סטורג' מבוסס קוד פתוח שישרת מכונות שאינן פרודקשן או פרויקטים פנימיים אחרים?

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

וירטואליזציה כקוד פתוח – כפתרון טוב

לפני כשבועיים פרסמתי את הפוסט הזה שמדבר על פתרונות אלטרנטיביים ל-vSphere של VMWare. הפעם אני רוצה לדבר על פתרונות קוד פתוח כפתרונות טובים לוירטואליזציה ומדוע RHV/oVirt הוא פתרון שעולה על רוב פתרונות הקוד הפתוח.

פתרונות וירטואליזציה בקוד פתוח מתחלקים בעצם ל-2: אלו שמעוניינים לנהל מספר קטן של שרתים פיזיים וצרכי הוירטואליזציה שלהם בסיסיים, ואלו שמעוניינים בפתרון וירטואליזציה מלא כולל הדברים המתקדמים, משהו כתחליף ל-Hyper-V (עם הניהול המרכזי) או תחליף ל-ESXI+vCenter.

כשמדובר בצרכים בסיסיים לוירטואליזציה ומדובר בכמות קטנה של שרתים (נניח 2-5), ומדובר, לשם השוואה, בדברים ש-ESXi עצמאי (ללא vCenter) יכול לתת – אז הפתרונות שהצעתי בפוסט הקודם יכולים לתת זאת ללא בעיה. יותר מכך, כל הפתרונות (למעט שימוש ב-KVM וב-libvirt עם סקריפטים) שהצעתי גם יכולים לתת לכם ניהול מרוכז של השרתים שלכם בממשק Web.

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

  • שימוש ב-vSwitch (בגירסת הקוד הפתוח – Open vSwitch) כ-SDN
  • הקמה אוטומטית של מכונות VM
  • שימוש ב-Grafana לתצוגת מצבי מכונות, דיסקים, מעבדים וכו'
  • High Availability מלא
  • אופטימיזציה לשימוש ב-NVME SSD תוך הגדלת I/O Threads
  • תמיכה מובנית ב-DR
  • יצוא/יבוא OVA/OVF
  • תמיכה במעבדי Power של IBM
  • תמיכה בכל פרוטוקולי הסטורג' (NFS, iSCSI, Fiber) + דיסקים מקומיים ו-GlusterFS
  • תמיכה במעבדים חדשים (EPYC, Xeon SP – ברוב הפתרונות המוצעים זה לא יעבוד טוב, במיוחד כשמדובר ב-HA).
  • ניהול מרוכז של כמות שרתים גדולה (עד 400 מכונות פיזיות)
  • פרופילים (סוגי מכונות, גדלים ועוד) כולל High Performance VMs.
  • תמיכה מורחבת ל-Over Commit
  • יבוא/יצוא של Images מ-OpenStack Glance (לא חייבים OpenStack מותקן בחברה).
  • פורטל למשתמשים (לאלו שצריכים לגשת למספר מכונות VM, ולנהל את אותן מכונות VM)
  • תמיכה במספר סוגי LDAP (כולל AD)
  • התממשקות ל-vCenter ויבוא מכונות VM
  • אפשרות לעבוד במצב הרגיל או במצב HCI.
  • תמיכה מלאה ב-GPU וב-VDI.
  • ועוד הרבה פונקציות אחרות.

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

האם פתרון כמו RHV/oVirt יכול להיות תחליף מלא ל-vSphere? התשובה היא: עדיין לא. העניין קשור יותר ל-Kernel ולדברים מתקדמים אחרים שלא קיימים ב-RHEL-7/CentOS-7 (שעליהם oVirt/RHV רץ):

  • Fault Tolerance עדיין לא זמין בגירסה הנוכחית (4.2)
  • VAAI/VVol – יש תמיכה ב-Kernel 4.X כך שנצטרך להמתין ל-RHEL-8/CentOS-8.
  • תוספים כמו vRealize ואחרים (שהם בתשלום) – יש להם חלופות. חלקם בחינם, חלקם בתשלום.

בכל הקשור לפתרונות וירטואליזציה, הגענו לזמנים טובים, למען האמת. רק לפני 3 שנים אם חברה גדולה היתה שואלת אותי לגבי פתרונות אחרים ל-VMWare או Hyper-V, הייתי ממליץ להם לנהל מו"מ בינם לבין מיקרוסופט ו-VMWare כי הפתרונות לא היו מספיק לדעתי טובים לשום Enterprise. פתרונות כמו Proxmox או פתרונות מבוססי Xen היו קיימים, אך לדעתי הם אינם נותנים מענה מספק ל-Enterprise (אם כי הם היו בהחלט יכולים לתת מענה לעסקים קטנים). בשנים האחרונות, החברה שהשקיעה הכי הרבה בפיתוח פתרון וירטואליזציה טוב היתה דווקא רד-האט. המצב בשוק פשוט התהפך: מיקרוסופט ו-VMWare היו עסוקים בפתרונות וירטואליזציה ואילו רד-האט היו עסוקים בפיתוח פתרונות מבוססי קונטיינרים (OpenShift) וב-3 השנים האחרונות רד-האט משקיעה הרבה יותר בפיתוח פתרון וירטואליזציה וגם בשיפור OpenShift, בשעה שמיקרוסופט ו-VMWare בשנתיים האחרונות יותר מתעסקים בפתרונות קונטיינרים.

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