כמה מילים על מעבדי Power

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

אבל יש עוד אופציה שחלק קטן מהאנשים מכירים – אלו מעבדי ה-Power של IBM, ספציפית מעבדי Power8 ו-Power9.

קצת היסטוריה: אפל, IBM ומוטורולה החליטו אי שם בשנות ה-90 להתחרות באינטל ולהוציא מעבדים משל עצמם תחת השם PowerPC. מוטורולה הוציאה את המעבדים, אפל השתמשה בהם בשמחה ו-IBM גם השתמשו בהם בחלק מהשרתים והיה אפילו מחשב ThinkPad יחיד שיצא עם מעבד PowerPC שהריץ OS/2 (וזמן קצת לאחר מכן שיווקו הופסק כי לא היתה לו דרישה).

עם הזמן אפל נטשה את ה-PowerPC, ומוטורולה המשיכו ליצור למשך זמן מה מעבדים כאלו לשווקים נישתיים כמו Embedded. ב-IBM הבינו שאם הם רוצים להתחרות באינטל, הם צריכים לעבוד ולפתח את המעבדים בעצמם וכך IBM שחררה במשך השנים מספר מעבדי Power שונים. בהתחלה המעבדים הללו היו עמוסים בתקנים קנייניים שלא תמכו טוב בסטנדרטים כמו זכרון ECC רגיל, אך החל מ-2015 ב-IBM הבינו שכדאי לרדת מהעניין ולהשתמש בחומרה סטנדרטית, וכך מעבדי ה-Power8 ו-Power9 החלו לתמוך בזכרון רגיל לשרתים, תקן PCIe לכרטיסים (ב-Power9 התקן הוא PCIe 4.0 שכרגע לא נמצא באף שרת מבוסס מעבדי אינטל, זה רק יחל להופיע בשנה שנתיים הבאות, אם כי רוב הסיכויים שהחברות יקפצו ישר ל-PCIe 5.0) ועוד.

מבחינת ארכיטקטורת מעבד, הארכיטקטורה של Power9 היא מורכבת ולא אכנס לפרטי פרטים בפוסט זה (למעוניינים, דף ה-WIKI הזה מסביר יותר), אך נאמר כך: במעבדים כמו EPYC או Xeon, אנחנו רגילים למצוא Cores ו-Threads, כאשר הכלל הקבוע הוא שכל 2 Threads תופסים בעצם ליבה אחת. ב-Power9 זה שונה: ה-Threads נקראים Slices ועל כל Core ניתן לפנות ל-שמונה Slices. ישנם 2 סוגי מעבדי Power9, ה-SMT4 ו-SMT8 כאשר SMT4 מכיל 12 slices ו-SMT8 מכיל 24 slices. מבחינת ליבות, המעבד קיים במספר גרסאות, החל מ-4 ליבות ועד 22 ליבות.

המעבדים הללו יכולים להיות ב-2 תצורות: אחת בשיטה הידועה והפופולרית של Scale Up (נקראת: SU) והשניה היא Scale OUT (נקראת: SO). מערכות שמשתמשות ב-Power9 SU לדוגמא הינן מערכות עם 4 מעבדים ואילו מערכות SO הינן מערכות עם 2 מעבדים. מערכות SU כוללות תמיכה בזכרון ישיר למעבד (Directly Attached) מסוג DDR4 ואילו מערכות SO משתמשות בזכרון כזכרון חוצץ. מהירות הגישה לזכרון ב-SO היא עד 120 ג'יגהבייט לשניה ואילו ב-SU היא 230 ג'יגהבייט לשניה (הרבה יותר מכל מעבד מבוסס X86-64).

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

IBM משווקים מספר מכונות, כאשר חלק מהמכונות מגיעות עם מערכת קניינית של IBM ומתוכה בעזרת תוכנת PowerVM אפשר לבנות מכונות VM שמריצות לינוקס ויש ל-IBM גם מכונות שמריצות ישר לינוקס עוד מה-Boot (כמו L922, S914,AC922 ועוד). למעוניינים (יש כאלו?) אפשר להריץ על המערכות הללו גם .. AIX. מבחינת מערכות לינוקס הקיימות ל-Power9, המבחר הוא: SLE של SuSE ו-RHEL של רד-האט. ניתן להריץ גם גירסת Debian על Power9 אבל רק מה"עץ" של ה-Unstable עם מינימום Kernel 4.15 ומעלה.
אה, ואי אפשר להקים מכונות VM עם Windows על מכונות כאלו. אין תאימות ל-X86-64..

אז למי מיועדות המערכות הללו?

הקהל הראשון שירצה לשמוע על המערכות הללו הן חברות שמעוניינות לפתח AI או Deep Learning. בכל מכונה כזו ניתן להכניס 4-6 כרטיסי GPU מסוג Tesla של nVidia, ואם נבדוק את הביצועים של GPU כזה על מערכות Xeon בהשוואה למערכות Power9, נקבל שהביצועים של Power9 מבחינת קישוריות הם פי 7-10 יותר גבוהים. אם נתרגם זאת לתוכנות המקובלות, אז TensorFlow רץ פי 2.3 יותר מהר, Caffe פי 3.7 יותר מהר, ו-Chainer פי 3.8 יותר מהר על מערכות Power9 בהשוואה למעבדי Xeon החדשים ביותר.

הקהל האחר שגם יעניין אותו המכונות הללו הם חברות שרוצות להריץ קונטיינרים והרבה. כאשר כל מעבד תומך בעד 2 טרהבייט זכרון ויש לך 96 Threads/Slices, אתה יכול להריץ המון קונטיינרים, גדולים כקטנים – על מכונה אחת (ואין שום בעיה לעבוד עם מס' מכונות). IBM מציעים את תוכנת ה-Cloud Private שמיועדת לניהול קונטיינרים והיא רצה על בסיס שכולם מכירים – Kubernetes. אם כבר מדברים על קונטיינרים – כלים ומתודות של CI/CD עובדים יפה מאוד על מערכות Power9.

קהל נוסף שדווקא כן מכיר את ה-Power9 הם אלו שרוצים להקים HPC גדול. ל-IBM כבר יש פרויקטים של HPC שרצים כבר עם Scale גדול כמו Summit, Sierra, MareNostrum 4.

כמו תמיד, יהיו מי שירצו לדעת מי משתמש במערכות כאלו – הרבה מאוד חברות בחו"ל, וחברה שאולי שמעתם עליה.. Google.

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

לסיכום: מערכות Power9 הן מפלצות עבודה לכל דבר ועניין והן נותנות תפוקה הרבה יותר גבוהה בהשוואה למערכות מבוססות Xeon/EPYC. הארכיטקטורה שונה, המאיצים שונים, המעבדים שונים, אבל אם אתם מחפשים את המהירות והביצועים הגבוהים – כדאי לדבר עם IBM ולקבל הדגמות ואולי כדאי שתשקלו לרכוש מכונות כאלו.

השורה התחתונה בעניין הטמעת 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: מה הפתרון שיכול להתאים?

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

סקירה כללית: מעבד AMD Threadripper 2990WX

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

ככה זה. (יש כמובן יוצאים מן הכלל).

ל-AMD יש היסטוריה שאינה כל כך "זוהרת". תמיד הם הציעו מעבדים, אבל ההצעות שלהם בד"כ הגיעו עם יתרון אחד: מחיר נמוך יותר. ביצועים כמו של אינטל? אפילו לא קרוב. כל זה השתנה עם ארכיקטורת ZEN. בהתחלה עם מעבדי ה-Ryzen 1XXX ועם מעבדי ה-Threadripper (המעבד הראשון בעולם שהציע 16 ליבות במחיר שלא קורע את הארנק והכיס) וכעת עם ארכיקטורת +ZEN שמשפרת מספר דברים הן במשפחת מעבדי ה-Ryzen 2XXX והן ב-Threadripper 2XXX ושוב – מחיר נמוך יותר מהמעבדים של אינטל ועם ביצועים שלפעמים עוקפים את המעבדים של אינטל ולפעמים לא.

ואז יש לנו את מעבד ה-Threadripper 2990WX. בפעם הראשונה מוצע לצרכנים הכבדים שמחפשים תחנות עבודה רציניות (או שרתים ל-LAB) מעבד עם 32 ליבות, 64 נימים, תמיכת זכרון 128 ג'יגהבייט (או עד 1 טרהבייט ECC) במחיר של $1800!

למי המעבד הזה מיועד? הוא מיועד למספר סקטורים:

  • ה-Pixel Pushers – אלו שעובדים בתוכנות תלת מימד, החל מ-Blender, Maya ועוד כלים שיודעים לנצל כמה שיותר ליבות.

ה-Multi Taskers – אותם אלו שעובדים בתלת מימד אבל גם עובדים עם עריכת וידאו במקביל. אחד החסרונות במעבדים של אינטל (עם 10 ליבות לדוגמא) זה כשאתה מרנדר דברים מקומית (אפטר, פרמייר, דה וינצ'י) – קשה להמשיך לעבוד עם אפליקציות כבדות אחרות במקביל. ה-2990WX לא מגיע לביצועי קידוד וידאו של המעבדים מרובי ליבות (10 ומעלה) של אינטל, הוא נותן בערך אותה תוצאה אבל מכיון שרוב תוכנות העריכה/אפקטים בקושי משתמשים בכמות של 4-8 ליבות, יש לך מספיק ליבות פנויות לעבוד על דברים אחרים מבלי שהביצועים יהיו גרועים.

  • לינוקס – מכיוון שתוכנות רבות ללינוקס לא בנויות עם מגבלת ליבות ויכולות לנצל כמה שתתן להן, ה-2990WX פשוט "בועט" בכל מעבד אחר. כאן תוכלו לראות סקירה ארוכה עם Benchmark לגבי כמעט כל דבר שמשתמשים בלינוקס ולראות איך ה-2990WX משאיר אבק לאינטל.
    במילים אחרים: צריכים לבנות מערכת Build רצינית שמקמפלת קרנל שלם (ללא שימוש ב-ccache) ב-30 שניות? צריכים מערכת Jenkins שתבנה המון חבילות במקביל? זה המעבד עבורכם.
  • וירטואליזציה – ה-2990WX מציע בעצם לראשונה מערכת חזקה לצרכי וירטואליזציה למחלקות הפיתוח מבלי לקרוע את הכיס, כל פתרונות הוירטואליזציה נתמכים.

אם נחזור לאותן חברות שלא ממש מוכנות (במידה מסויימת של צדק) לרכוש ציוד חדש למחלקות הפיתוח, אז ה-2990WX יכול לראשונה להציע פתרון מאוד חזק, אך יחסית זול (בהשוואה לתחנת עבודה של חברות כמו HP, DELL,Lenovo) שיכול להתאים הן כתחנת עבודה והן כשרת לא-פרודקשן.

מה תהיה התשובה של אינטל? סביר להניח שנשמע עליה בחודשים הקרובים, אבל אם אינטל תוציא מעבד 32 ליבות, תהיו בטוחים שהוא יעלה הרבה הרבה יותר מ-1800$.

לסיכום: ב-Anandtech, ב-Toms Hardware, ב-OC3D, ובאתרים אחרים יש סקירות על ה-2990WX וכולם מסכימים עם אותם דברים: אם אתה צריך להריץ דברים כבדים ב-Multi task, אם אתה מריץ אפליקציות שיודעות לנצל כל ליבה – המעבד הזה יכול להתאים לך. אני מוסיף שכאן בחברות, ה-2990WX יכול לעזור היכן שצריך ביצועים אבל אין תקציב לשרתים רציניים.

נקודות למחשבה כשרוצים לרכוש סטורג' חדש

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

לא מעט חברות בארץ משווקים (או Reseller) של מוצרי סטורג'. חלק מהמוצרים הם סטורג' "אמיתי" וחלק מהמוצרים הם לא יותר מאשר שרת סטנדרטי שהוכנסו לתוכו דיסקים, מערכת הפעלה קניינית הכוללת פתרון סטורג' בתוכנה – והרי לכם סטורג' מבוסס תוכנה. כמעט אף אחד, אגב, לא יאמר לכם שזה SDS (כלומר Software Defined Storage) למרות שרוב הסטורג'ים שמוכרים בקצה התחתון עד בינוני הם SDS לכל דבר ועניין, רק שאתם תשלמו מחיר הרבה יותר גבוה ממחיר שרת רגיל שיש בו דיסקים ואיזו תוכנה. מדוע? וולקאם טו איזראל!

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

  • 22 דיסקים של סמסונג מסוג PM883 בגודל 1 טרהבייט מסוג Mixed Intensive
  • 2 דיסקים של אינטל 900P (לצרכי Cache, ZIL, Logs) בגודל 280 ג'יגהבייט
  • 256 ג'יגהבייט זכרון DDR4 ECC במהירות 2666 מגהרץ
  • מעבד יחיד Xeon V4 עם 4 ליבות
  • מערכת הפעלה: Fedora 28 עם ZFS
  • חיבורי רשת של 25 ג'יגהביט

המערכת הזו עבדה במשך חודשיים תוך כדי שהיא מחוברת ל-15 שרתי ESXi ונתנה הן שרותי iSCSI והן שרותי NFS (נפרדים, ישירות ל-VM). מבחינת IOPS – זה נע בין חצי מיליון ל-מיליון.

מערכת כזו אינה בנויה כפי שניתן לראות ל-Enterprise. אין בה בקרי RAID כפולים והשרידות שלה היא לא משהו (אין שום שרת נוסף זהה לצרכי HA), אבל אני מראה כאן את Elsa כדי ללמוד משהו חשוב, על Tiering שמאוד חשוב בכל סטורג' שקונים.

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

  • ה-256 ג'יגהבייט זכרון – זה ה-RAM של המערכת, זה הדבר הכי מהיר שיש
  • 2 הדיסקים 900P של אינטל – יש להם Latency יותר גבוה מ-RAM אבל יותר נמוך מכל דיסק אחר
  • דיסקים SSD

בסטורג' קנייני לעומת זאת (StorWiz של IBM, או VNX של EMC לדוגמא) ה-Tiering מעט שונה:

  • שכבת ה-RAM
  • שכבת NVRAM – זהו זכרון מסוג מיוחד שאינו נמחק ברגע שאין חשמל
  • שכבת ה-SSD
  • שכבת הדיסקים המכניים / SSD שליפים (במדפים)

בשרתי סטורג' שהם SDS אין שכבת NVRAM ובמקרים רבים גם אין בקרי RAID כפולים, כך שה-Tiering הוא כמו זכרון, SSD, ודיסקים. כאן, חשוב לדרוש שיהיו SSD שלא מותקנת עליהם מערכת ההפעלה, ה-Cache אמור לשבת ב-SSD נפרדים ושיהיו Mixed Intensive. ברוב ההצעות מחיר שתקבלו, ה-SSD יהיו Read Intensive ויש הבדל ניכר במחיר.

דבר נוסף שחשוב הוא עניין החיבוריות: כמעט כל מי שמוכר פתרון סטורג', מוכר אותו עם פתרון FC (כלומר Fiber Channel) במהירות 16 ג'יגהביט. זהו פתרון טוב לדיסקים בחיבור SAS ו-SAS2 או SATA למדפים/JBOD או בדיסקים שיושבים בשרת, אבל אם אתם חושבים על NVME – פתרון ה-FC יהווה צוואר בקבוק – חיבור 16 ג'יגהביט מאפשר ברוטו 2 ג'יגהבייט לשניה, ו-NVME מעביר בין 1.5 ל-2.5 ג'יגהבייט לשניה ואני מדבר על דיסק יחיד, ומכיוון שלעולם לא תכניסו SSD NVME יחיד, החיבור יחנק, ולכן אולי כדאי לחשוב על פתרונות Infiniband או Ethernet מהירים במהירות 25 ג'יגהביט ומעלה (ובקשר ל-Latency – ישנם מס' פתרונות עם Latency נמוך, כולל RDMA וחבריו).

אם כבר דיברנו על FC, לא מומלץ לסמוך על 4 חיבורי ה-FC שקיימים ותמיד מומלץ לקנות מתג לחיבור המהיר, במיוחד אם יש לכם רק 3 שרתים ואתם חושבים לגדול בהמשך. יש תחרות, נצלו אותה לשם מו"מ כדי להשיג מחירים טובים.

נקודה נוספת שחשוב לקחת בחשבון היא גיבוי הסטורג' עצמו. כן, יש Veeam שמגבה מכונות וירטואליות (והוא מגבה ל.. סטורג') אך תקלה רצינית בסטורג' (ותקלות תמיד קורות, תשאלו את מרפי) לא תאפשר לכם לא לשחזר מכונות VM או דברים אחרים, ולכן כדאי לגבות את הסטורג' לקלטות גיבוי או למכונת NAS זולה אחרת (במכונות שהן אינן G8/G9/G10 של HPE שהן אינן ביצור/פרודקשן אפשר גם להכניס SATA "ביתיים" גדולים זולים, רק חשוב להוסיף SSD לשם Cache). כאן, אגב, אני רוצה להזהיר בהזדמנות שדיסקים SSD של אינטל ש-HPE משווקת, במקרים רבים הקושחה כזו גרועה, שדיסקים נופלים גם בצוותים!

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

ומה לגבי כל ההתלהבות לגבי HCI עם vSAN/Nutanix/Simplivity במקום סטורג' יעודי? הם טובים, אבל הבעיה האמיתית שלא תמיד שמים לב אליה היא עניין גדילת כמות הסטורג': במקרים כמו vSAN לדוגמא תצטרכו להוסיף 3 דיסקים (2 מכניים או SSD Read פלוס SSD מהיר) פר שרת שמשתתף ב-HCI, ומהירות IOPS גבוהה מקבלים רק כשכמות השרתים המשתתפים ב-HCI היא גדולה (ארון פלוס). נוסיף לכך שבניגוד לדיסקים ביתיים, דיסקים ל-Enterprise יקרים והמחירים בקושי יורדים (וחברה כמו HPE לוקחת עשרות אחוזים יותר בגלל … מדבקה ושינוי כמה ביטים בקושחה) – זה יכול להוות בעיה בטווח הארוך.

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

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

וירטואליזציה ודיסקים מקומיים. כדאי?

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

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

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

ל-NAS יש יתרון אחד שדווקא לא קיים במרבית פתרונות הוירטואליזציה והוא קשור לאופטימיזציה. הדרייברים שנמצאים בתוכנת הוירטואליזציה הם דרייברים בסיסיים. הם מאפשרים עבודה רציפה עם הדיסקים ותו לא. כך לדוגמא אינך יכול להכניס לשרת וירטואליזציה 1-2 דיסקים SSD ולהגדיר אותם כ-Cache (ה-Read Cache במקרה של vSphere לדוגמא, מיועד להאצת עבודה חוזרת של מכונות VM, לא לשמש כ-Cache ל-Datastore). לעומת זאת, אם נרים NAS על שרת ישן (זה יכול להיות גם PC עם דיסקים במקרים שאין תקציב) ונכניס לו 1-2 דיסקים SSD, נוכל בעזרת התוכנה ב-NAS להגדיר אותם כ-Cache. בנוסף, אם אנחנו רוצים מהירות גישה רצינית אל/מאת ה-NAS ולא להיות "חנוקים" במהירות של 1 ג'יגהביט – אפשר לרכוש בזול כרטיסי רשת QSFP (או +SFP) שנותנים חיבור במהירות 10 ג'יגהביט עם פורטים כפולים וכבלי DAC ולחבר אותם בין ה-NAS ל-2 שרתים שמריצים מכונות וירטואליות. כך הדברים ירוצו הרבה יותר מהר ואין צורך לרכוש סוויצ' 10 ג'יגהביט יקר לשם כך (אגב, התוספת מחיר על כך מגיעה בד"כ בסביבות ה-300$).

מצד שני, יש בהחלט מקום בשימוש בדיסקים מקומיים כאשר אנחנו משתמשים בתצורת Hyper Converge. בקונפיגורציה כזו, המערכת צריכה לפחות SSD אחד על מספר קטן של דיסקים מכניים והיא משתמשת ב-SSD לשם כתיבה/קריאה מואצת וכמובן כ-Cache (רק שחשוב לשים לב איזה SSD Intense אתם רוכשים, אם רכשתם את הלא נכון, הביצועים יהיו מופחתים) אך גם כאן חשוב לשים לב לא רק לסוג ה-Intense אלא גם לסוג החיבור של ה-SSD. חיבור SATA לדוגמא "נחנק" במהירות 560 מגהבייט ואילו SSD בחיבור U.2/NVME יתן ביצועים ורוחב פס עד פי 4-5 בהשוואה ל-SATA.

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

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

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

חושבים לעבור לפתרון וירטואליזציה אחר?

עדכון על Hyper-V מופיע לקראת סוף המאמר.

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

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

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

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

  • לקוח רוצה להריץ מס' חד ספרתי של מכונות וירטואליות, אבל מצד שני הוא רוצה HA (כלומר High Availability) כך שאם נפל שרת אחד – השרת השני עושה pick up והמכונות ממשיכות לעבוד
  • לקוח אחר רוצה לתת שרותי Hosting ללקוחות שלו, יש לו אלפי מכונות וירטואליות אבל אין לו תקציב לרכוש מ-VMWare (אגב, רק לידיעה: VMWare דורשת 50$ פר מכונה וירטואלית מחברות Hosting, גם אם מריצים רק את ESXi החופשי).
  • לקוח אחר מעוניין בפתרון קוד פתוח ולא משהו קנייני להריץ כמה עשרות מכונות וירטואליות עבור העסק שלו.
  • לקוח אחר רוצה את הכל: תתחיל ב-FT, תכלול DR, תכלול HA, סוויצ'ים וירטואליים מורכבים, תמיכה ב-RDMA, NFS, iSCSI, templates ועוד ערימת דברים – אבל לא מוכן לשלם את המחיר ש-VMWare רוצים פר שרת פיזי.
  • לקוח אחר "להוט" מאוד על HCI – הוא רוצה המלצה אם ללכת על vSAN, Nutanix, Simplivity (אחד מהם).
  • ולקוח אחר מעוניין פה ועכשיו בהצעה על OpenStack כפתרון וירטואליזציה חלופי/משלים למה שיש לו כיום.

הבה נכיר את הפתרונות:

VMware
ה"מלכה" הבלתי מעורערת לפתרונות וירטואליזציה. בין אם יש לך בתשתית שרת אחד או 5000 שרתים פיזיים –  המערכת תומכת בצורה מעולה. יש אלפי פונקציות ואפשרויות להתרחב לכל דבר הקשור לוירטואליזציה.
הבעיה העיקרית: המחיר. גירסת ה-ESXi שמותקנת על השרת קיימת כגירסה חינמית, אך כמות הפונקציונאליות מוגבלת ולשם ההרחבה יש לרכוש את vCenter שקיימת במספר גרסאות, ואם יש לך עד 3 שרתים – תוכל לרכוש את רשיון ה-Essentials של vCenter ולנהל במרוכז את השרתים במחיר של 500$, אבל גם אז הפונקציונאליות די מוגבלת. רוצה יותר? תתחיל לשלם פר מעבד אלפי דולרים וגם לרשיון היותר מתקדם של vCenter תצטרך לשלשל עוד כמה אלפי דולרים, ועוד לא דיברנו על תמיכה שנתית – שגם היא עולה כמה אלפי דולרים. בקיצור – הסיבה שרבים מחפשים אלטרנטיבות היא לאו דווקא בגלל מגבלות טכניות, אלא בגלל מגבלות תקציביות.

OpenStack
דמיינו לכם את הדבר הבא: אתם נכנסים לסופרמרקט הקרוב ורוכשים לכם 3-4 קרטונים של חלב, אתם משלמים ויוצאים. מה יש לכם בשקית? 3-4 קרטונים של חלב וזהו. עם OpenStack, אתם מקבלים לא רק את הקרטונים של החלב, אלא גם את המחלבה, הרפת והפרות!

טכנית, OpenStack עושה המון דברים (תסתכלו כאן כדי לראות כמה פרויקטים יש בתוך OpenStack), וירטואליזציה זה רק אחד מהדברים, ואם אתה רוצה אחסון – אז יש לך 3 חלקים (Object, File, Block כל אחד מהם שונה). נכון, אפשר להתקין רק חלקים מסויימים (או להתקין הכל ולהשאיר לכל מה שצריכים ברירות מחדל), אך עקומת הלימוד בהשוואה לשימוש ב-Hyper-V או VMWare – מאוד גבוהה. יהיו כמובן חברות שיש להם את הצוותים שיכולים להתעסק בכך (ויש במה להתעסק, כיום OpenStack מורכב מיותר מ-1800 חבילות!), אבל אז מגיעות 2 נקודות שכדאי לתת עליהן את הדעת:

  1. גירסת OpenStack משתחררת כל חצי שנה עד שנה בערך. מכיוון שבחברות נהוג לעדכן כל 3 שנים, השדרוג לגירסה האחרונה יהיה קשה עד בלתי אפשרי כי בדרך כבר עברו כמה גרסאות (ואף אחד לא מבטיח תאימות).
  2. חברות מסחריות ירצו את ה-OpenStack המסחרי שהגירסה שמשוחררת ונתמכת ל-5 שנים, יצטרכו להתכונן למחיר ממש לא זול. גירסת רד-האט לדוגמא עולה כ-10,000$ לשרת עם 2 מעבדים (הממ, פתאום המחיר של VMWare לא נראה כזה יקר). חברות כמו SuSE וקנוניקל מוכרות במחירים יותר זולים, ואכן – אם חברה מחליטה ללכת לרכוש OpenStack אני ממליץ לה לרכוש זאת מ-SuSE (התמיכה של קנוניקל לא משהו, בלשון המעטה). במילים אחרות – אם אתה מחפש OpenStack שיחזיק כמה שנים טובות ובחינם – לא ממש תמצא זאת. זה לא CentOS.

Xen
טכנית, Xen הוא פתרון וירטואליזציה טוב כשמדובר על כמות שרתים פיזית קטנה. הוא נותן ביצועים טובים, יש ממשק Windows (למעוניינים, אפשר לעשות כמובן הכל בלינוקס ישירות). הבעיה המרכזית עם Xen הוא שהפרויקט עצמו בקושי "חי". Xen יוצא בגרסאות יותר חדשות (4.10.1 זו הגירסה האחרונה), אבל כשזה מגיע לחברות, הן רוצות תמיכה. Citrix מוכרת את Xen ונותנת שרות, אבל זול – הוא לא (3,000 דולר פר מכונה עם 2 מעבדים). הסיבה שאני לא ממליץ על Xen של Citrix היא שהחברה פיטרה מחצית מהעובדים שעבדו על Xen ונתנו לו שרות ולא נראה ש-Citrix תמשיך לקדם ולפתח את מוצר ה-Xen שלה. חברה אחרת שמוכרת את Xen תחת שם אחר היא חברת Oracle (היא לא מזכירה את השם "Xen" בשום מקום בתיעוד השיווקי) והמוצר נקרא Oracle VM Server.

Proxmox
תוכנת Proxmox היא אחת מהוותיקות בשוק שהלכה וגדלה עם השנים, הוסיפה תמיכה למכונות וירטואליות (מבוססות KVM, כמו רוב הפתרונות מבוססי קוד פתוח שמוזכרים כאן), תמיכה לקונטיינרים (לא Docker אלא LXC), תמיכה ל-ZFS, NFS, iSCSI, GlusterFS ועוד. זו תוכנה שמומלצת לאלו שרוצים לנטוש את Xen, לעסקים קטנים שיש להם שרות מאינטגרטור בארץ (השרות המקורי ניתן רק ב-tickets ואין אפשרות SLA, רק NBD מיצרנית התוכנה עצמה). התוכנה גם יכולה להתאים לעסקים קטנים והקהל שהכי "אוהב" את התוכנה אלו חברות ה-Hosting ששם דברים כמו Live Migration, HA וכו' אינם כה חשובים.

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

oVirt
תוכנת oVirt שנכתבת ע"י רד-האט היא אחת התוכנות שמכוונת ישירות להתחרות ב-vSphere. (שימו לב: גירסת הקוד החופשי נקראת oVirt, הגירסה המסחרית [שמבוססת על אותו קוד] נקראת RHV). ב-oVirt יש בעצם כמעט את כל מה שאתם מקבלים ב-ESXi עם vCenter, היא יכולה לעבוד גם בתצורות של מאות ואלפי שרתים פיזיים מצד אחד, אבל היא גם יודעת להתרחב לאזורים "קרובים" לוירטואליזציה (כמו הרצת Images מ-OpenStack ובגירסה הקרובה כנראה תהיה גם תמיכה לקונטיינרים). היא יודעת להתממשק לפרטוקולי הסטורג' הידועים (NFS, iSCSI וגם GlusterFS ו-Ceph [דרך Cinder]) וגם להתחבר ישירות אל שרתי ה-ESXi או אל ה-vCenter שלכם כדי להמיר מכונות ל-oVirt/RHV. בנוסף, oVirt/RHV היא התוכנה היחידה מתוכנות הקוד הפתוח שיכולה לעבוד גם במצב קלאסי (התקנה של התוכנה במכונה אחת, בשאר מתקינים גירסת Node) או במצב Hyper Converge. בנוסף, זו התוכנה היחידה שיש לה גם Client לאנדרואיד כדי לבדוק מה קורה ולטפל בתקלה מרחוק ללא צורך במחשב.

לחברות המעוניינות ב-RHV (כלומר בגירסה המסחרית), המחיר די זול (יחסית): 1000$ לשנה למכונה עם 2 מעבדים ותמיכה בשעות העסקים או 1500$ לתמיכה של רד-האט 24/7.

פתרונות HCI
מוצרים כמו Nutanix/Simplivity/VSAN/RHV מציעים בעצם שרתים עצמאיים שלא זקוקים ל-Storage חיצוני והם נותנים הכל בפתרון אחד. אלו יכולים להיות פתרונות מעולים, אולם חשוב לזכור שבמרבית המקרים תצטרכו להחליף שרתים (אם יש לכם שרתים ישנים) ובמקרה של vSAN אם תרצו תוצאות ממש גבוהות, תצטרכו דיסקים SSD NVME מסוג Mixed Intense (מה שאומר שתצטרכו לרכוש Backplane נוסף לשרת ל-4 כוננים, שרתים נמכרו בשנים האחרונות ללא Backplane ל-NVME וזה "אקסטרה") כחלק מכל קבוצת דיסקים. בפתרון של VMWare ניתן לעבוד "גם וגם" כך ששרתים ישנים שעובדים מול סטורג' יוכלו להמשיך לעבוד כרגיל. החסרון העיקרי של VMware vSAN הוא המחיר: תוספת של 5000$ פר שרת עם 2 מעבדים – וזה לפני המחיר של הציודים ובנוסף למחירי הרשיון האחרים ש-VMWare מבקשת.

פתרונות ל-VDI
גם מיקרוסופט, גם VMWare, גם Citrix וגם חברות אחרות מציעות פתרון VDI. את הפתרונות הללו אני מגדיר כלא יותר מ"בסדר". אלו פתרונות טובים לעובדי משרד, שמריצים דפדפן, אופיס, ואולי עוד כמה אפליקציות משרדיות, אבל כשזה מגיע לוידאו ותלת מימד – הפתרונות האלו כיום אינם משהו לרוץ לספר לחבר'ה. הסיבה לכך שמי שקובע את הדברים הם יצרניות ה-GPU והפתרונות שהם מציעים מתאימים לדברים שתיארתי לעיל ותו לא. מי שלדוגמא ישתמש ב-RemoteFX יגלה שמבחינת תמיכת OpenGL התמיכה היא חלקית ועל עריכת וידאו או דברים כאלו כבדים – תשכחו מזה. לאמזון יש פתרון שהוא יותר מתקדם ממה שהחברות שציינתי נותנות אבל גם הפתרון שלהם הוא לא בדיוק העלית שבעלית.

מבחינת קוד פתוח, ישנם כמה פרויקטים שמפותחים (והם ישולבו בעתיד במוצרים כמו ProxMox, oVirt ואולי Xen). אחד מהם לדוגמא הוא פרויקט VirGL שמרנדר על GPU בשרת ומעביר דרך הרשת את הפלט למסך. כרגע הוא תומך רק בלינוקס אולם מישהו אחר כרגע עובד על תמיכת Windows. עוד פרויקט (דווקא מחברת אינטל) הוא פרויקט GVT שמשתמש ב-GPU של המכונה כדי לרנדר עבור מכונות וירטואליות. בפרויקט עדיין חסר פלט רינדור לתצוגה רחוקה אבל אני מאמין שאינטל שומרת את החלק הזה ל-GPU שהם עובדים עליו כרגע.

מה עם Hyper-V?
מבחינה טכנית, Hyper-V נותן פתרון טוב לוירטואליזציה ששווה פחות או יותר לפתרון של VMWare (יש פונקציות שיש בפתרון אחד שאין בשני וההיפך). גם מיקרוסופט מציעה גירסה "חינמית" שמגיעה עם גירסת Windows Server (כ-Role) והפתרון הזה יכול להתאים למי שרוצה פונקציות ניהול (די מוגבלות) פר שרת, כך שכל שרת מנוהל בנפרד. ברגע שרוצים לנהל את הכל בצורה מסודרת, יש צורך ב-System Center ויש גם תשלום עבור Operating System Environment (או OSE) ורשיון ה-Windows Server צריך להיות רשיון Data Center. בגירסת Windows Server 2016 מיקרוסופט די החמירה את דרישות הרשיון ואם במקרה של VMWare למערכת לא ממש משנה כמה ליבות יש לך במעבד, במיקרוסופט רוצים תשלום פר ליבה ולא פר מעבד. חברת TAG Provision כתבה פוסט המשווה את המחירים בין המתחרים העיקריים וניתן לראות כל הנתונים כאן וכפי שניתן לראות, עם המחירים הללו, אין שום סיבה לעבור ל-Hyper-V, אלא אם מחפשים את הפתרון המינימלי ה"חינמי" ללא ניהול מרוכז. בנוסף, אם אתה מחפש פתרון HCI, ה-Hyper-V אינו מתאים לכך.

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