עדכונים בנושאי וירטואליזציה ו-VDI

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

אתחיל בנושא VDI.

תודות לחברת CRG שהשאילה לי כרטיס AMD S7150 לצרכי בדיקות VDI – התחלתי לבדוק את הנושא. לצערי הכרטיס הזה לא ממש עובד על מעבדי Xeon ישנים (סידרה V1-V2). הזמנתי לוחות אם של Supermicro יד שניה מסוחר ישראלי ו… גיליתי להפתעתי שהלוחות פגומים (פגומים במובן שכאילו מישהו העביר פטיש על תושבות המעבדים ועיקם את רוב הפינים!). מכיוון ששילמתי ב-Paypal, הצלחתי להחזיר את הלוחות ולקבל את הכסף בחזרה, כך שלא יכלתי להתקדם הרבה עם הכרטיס והחלטתי להחזיר אותו ל-CRG.

לא הרמתי ידיים, החלטתי לבצע בדיקות סימולציות משתמשי דסקטופ (כלי מצוין לכך: LoginVSI, יש גירסת התנסות בחינם) במובנים הבסיסיים לצרכי רואה חשבון ועורכי דין שמדי פעם גם צופים פה ושם בוידאו. התברר לי שכשמדובר בכמות קטנה (5-8 תחנות) של משתמשים, ואם משתמשים ב-RDP בלבד – לא יהיה צורך בכרטיס GPU לצרכי VDI. המעבדים בשרת מודרני יכולים לעמוד יפה בעומס. (אני ביצעתי את הניסויים על מעבד דסקטופ AMD Ryzen 7 2700X, כך שמעבדי Xeon יכולים לעשות זאת בקלות).

מכאן נעבור לברזלים: אני ממליץ על שרת בתצורת TOWER מהסיבה הפשוטה שלרבים אין מקום להכניס שרת 1U/2U רגילים מבלי לרכוש ארון תקשורת בעומק 80 ס"מ, מה גם שהוא מרעיש. שרת במארז Tower בדרך כלל הרבה יותר שקט והאיוורור בו הרבה יותר טוב ויעיל.

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

מבחינת תקשורת: אני ממליץ  חיבור 10 ג'יגהביט בין השרת ל-Switch (לרוב המתגים יש Uplink של 10 ג'יגה בחיבור +SFP) – אם כל המשתמשים צופים בוידאו – קידוד ה-RDP + קידוד H.264 + תעבורה של הדסקטופ לוקחים לא מעט.

אסכם את הנושא כך: עם ESXI חינמי, עם מכונה בתצורת Tower שכוללת 2 מעבדים של 8 ליבות כל אחד, 128 ג'יגהבייט זכרון, דיסקים מקומיים, NAS של Synology ומתג נורמלי – אפשר לייצר "סביבת VDI". הפתרון, כמובן, לא VDI כמו Horizon או Terminal Services והוא גם לא מתיימר לכך, הוא בסך הכל נועד להעביר כמות קטנה של מכונות פיזיות ישנות ולהמירן ל-VM ולעבוד עליהן. אם מדובר על עשרות של מכונות פיזיות וכו' – אז כדאי בהחלט לחשוב על פתרון VDI מלא.

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

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

עננים: במהלך השבועות הקרובים אתחיל להעלות קליפים נוספים הקשורים בתכנון מכונות על AWS, על שימוש ב-VPC (תתפלאו כמה חברות כלל לא מגדירות VPC ומשתמשות ב-Default), על Load Balacing ועוד.

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

כמה מילים על SR-IOV

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

  • יש סטורג' שמאחסן את ה-Datastore (יכול להיות סטורג' חיצוני, יכול להיות דיסקים מקומיים עם RAID-חומרה בתצורה כלשהי)
  • חיבורי רשת – או חיבור של 10 ג'יגה או חיבור של מס' פורטים 1 ג'יגה (בנפרד, ב-Teaming/Bonding)
  • מעבד יחיד או זוג Xeon פר מכונה
  • זכרון

ברוב מוחץ של אותם מקרים, כל ה"ציוד" בכל מכונה וירטואלית – הוא ציוד Paravirtualized, כלומר זהו ציוד "מדומה" חלקית, כאשר מאחורי הקלעים יש ציוד אמיתי שעושה את העבודה. כך לדוגמא אם אתם משתמשים בכרטיס רשת ב-vSphere, סביר להניח שאתם משתמשים ב-VMXNET3, זהו ציוד Paravirtualized שבעצם מתממשק לחלק ה-Network של ESXI (ה-VMKERNEL) ומשם הוא מתחבר לציוד הפיזי ופאקטים יוצאים ונכנסים. אם נשתמש לעומת זאת ב-E1000 (או e1000e שקיים בפתרונות וירטואליזציה אחרים כמו RHV/KVM) – כאן מדובר באמולציה מלאה של כרטיס הרשת של אינטל והאמולציה מדמה את הכרטיס (כמעט) אחד לאחד ובסופו של דבר מעבירה את הנתונים מ/אל ה-STACK רשת של פתרון הוירטואליזציה. אותו דבר קורה עם דיסקים, תצוגה וכו' וכו'.

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

SR-IOV (ר"ת של Single Root Input Output Virtualization) היא טכנולוגיה שפותחה ע"י הקבוצה שאחראית על פיתוח PCI, PCIe ועוד (PCI-SIG) ומטרת הטכנולוגיה הזו היא לפתח כרטיסים שמיועדים לשימוש בפתרונות וירטואליזציה.

כרטיס PCIe רגיל, בדרך כלל מיועד לפעילות אחת ולמערכת אחת. קחו לדוגמא כרטיס RAID או HBA, הוא מיועד לשבת ולתת שרותים למערכת אחת שרצה בשרת. אם לדוגמא אתם משתמשים בוירטואליזציה על אותו שרת, ה-OS (ה-ESXI לדוגמא) "יחטוף" את הכרטיס לשימושו האישי, ואתם לא תוכלו להשתמש בכרטיס ה-RAID ישירות במכונה וירטואלית. אנחנו כאן יכולים "לבדל" את כרטיס ה-RAID (כלומר Exclude) מה-ESXI אם לדוגמא נבצע Boot מ-USB או כרטיס SD ונגדיר ב-ESXI לעשות "Passthrough" לכרטיס ה-RAID לפי מספר ה-PCI ID שלו (כפי שניתן לראות כאן) ולאחר ביצוע Reboot לשרת, נוכל לבצע "מיפוי" של כרטיס ה-RAID למכונה וירטואלית אחת. למיפוי הזה יש מגבלות: אנחנו חייבים לתת מראש את כל משאבי הזכרון שאנחנו מגדירים ב-VM, לא ניתן לבצע Live Migration וכמובן – יש כרטיסים שלא ממש "מחבבים" את הרעיון של PCI Passthrough כמו כרטיסי GTX של nVidia (אם כי יש גם לכך פתרון).

עם SR-IOV הדברים שונים.

בכרטיסים המכילים פונקציונאליות SR-IOV (הכרטיסים האלו יכולים לתת את הפעילות הזו רק עם מעבדי Xeon E5 v3 ומעלה ומעבדי AMD EPYC), ישנם 2 חלקים חשובים: PF ו-VF.

ה-PF (כלומר Physical Function) מייצג פונקציונאליות פיזית שהכרטיס יכול לתת ואותה ניתן להגדיר. אם ניקח לדוגמא כרטיסים כמו GRID או Tesla של nVidia, אנחנו יכולים להגדיר כמה זכרון תצוגה יהיה לכל vGPU. מכיוון שיש לנו יכולת להכניס כמה כרטיסים בשרת אחד, יהיו לנו בעצם מספר PF, ואותם נוכל להגדיר כבודדים או כקבוצה עם הפרמטרים הרלוונטיים.

ה-VF הוא בעצם מעין "תת כרטיס PCIe" וירטואלי (Virtual Function) שאותו אי אפשר להגדיר (זהו בעצם "כרטיס טיפש") שאת הפונקציונאליות שלו מממש הכרטיס הפיזי. ברגע שהגדרנו את ה-PF בוירטואליזציה (לכל כרטיס יש כלים והגדרות אבל כולם משתמשים ב-PF, ו-VF), במערכת "יצוצו" כמות של כרטיסים וירטואליים חדשים שנראים כמו כרטיסי PCIe רגילים, ואותם אנחנו ממפים פר VM. ברגע שמיפינו והפעלנו את ה-VM, נצטרך להתקין את הדרייברים היעודיים לאותו כרטיס (במקרה של nVIdia ו-AMD – הדרייברים של ה-vGPU, לא לבלבל בין אלו לבין הדרייברים לוירטואליזציה) ואז נוכל להשתמש בפונקציונאליות החדשה.

בתחום ה-Network, כל יצרני כרטיסי הרשת (אינטל, Mellanox, Solarflare, ואחרים) נותנים פונקציונאליות SR-IOV בכרטיסים שלהם. אם לדוגמא אתם משתמשים בכרטיסי רשת של אינטל, אתם יכולים להסתכל ברשימה הזו ולראות אם יש תמיכת SR-IOV. חשוב לזכור: גם אם כתוב שיש תמיכת SR-IOV, במקרה של אינטל אין תמיכת SR-IOV בכרטיסים עם חיבורי 1 ג'יגהביט, או FCoE ו-SR-IOV.

עד כמה הביצועים שונים בין VNXNET3 ל-SR-IOV של כרטיס רשת? להלן גרף לדוגמא:

הגרף הוא מתוך מסמך  ש-VMWare שחררה בכתובת: http://delivery.acm.org/10.1145/2900000/2892256/p65-xu.pdf

עם כל הדברים הטובים שיש ל-SR-IOV להציע, יש גם כמה מגבלות:

  • נכון להרגע, ב-ESXI אין אפשרות לבצע Live Migration למכונה עם כרטיס וירטואלי ממופה (שזה קצת מוזר, בהתחשב בכך שבלינוקס עם KVM זה דווקא כן אפשרי).
  • אם אתם רוצים "לפוצץ" את המכונה בכרטיסים שיש להם יכולת SR-IOV, תוודאו שלמעבדים יש הרבה ליבות או שתרכשו שרתים עם EPYC, אחרת – תכירו את התקלה הזו. תזכרו שכל VF דורש Interrupt משל עצמו.
  • בחלק מהשרתים תצטרכו לעבור למצב Performance בשביל שפעילות SR-IOV תהיה פעילה (ניסיתי על Dell R740).
  • הגדרתם ל-VM כ-16 ג'יגהבייט זכרון וה-VM משתמש ב-2? הלכו ה-14 ג'יגהבייט זכרון הנוספים (יש להגדיר מראש במכונה להשתמש בכל הזכרון שמוגדר אחרת ה-VF מייצר תקלות), כך שיכול להיות ויהיה צורך לחשב מחדש את כמות מכונות ה-VM פר שרת. כמו כן, משחקי/הגדרות Balooning לא מומלצים על מכונות VM כאלו.

לסיכום: SR-IOV זו טכנולוגיה מעולה כשמעוניינים בביצועים גבוהים של פונקציונאליות מסויימת כמו רשת, GPU ועוד. אם יש לכם שרתים מה-4-5 שנים האחרונות (ויש בהם מעבדי Xeon V3 ומעלה) תצטרכו להפעיל ב-BIOS את ה-SR-IOV ותוכלו להנות מהפונקציונאליות המשופרת ומביצועים גבוהים. יחד עם זאת, ישנם מגבלות שחייבים לקחת מראש, כך שלא מומלץ מחר בבוקר להעביר את כל ל-SR-IOV.

סטטוס וירטואליזציה מבוססת קוד פתוח – סוף 2018

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

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

אני מודה שעד לאחרונה כל עניין הוירטואליזציה בקוד פתוח לא ממש תפס אחוז גדול בתחום ההטמעות ב-Enterprise. כמעט כולם הולכים ל-VMware, חברות שכמעט כל התשתית שלהם מבוססת מיקרוסופט משתמשים ב-Hyper-V ואלו שרוצים Hyper Converged הולכים על Nutanix או Simplivity. אחרי הכל – למוצרים האלו יש תמיכה, יש בארץ אינטגרטורים, לא צריך לקנות מחו"ל רשיונות, יצרני החומרה מאשרים שהמוצרים עובדים עם הברזלים. בקיצור, סבבה אגוזים.

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

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

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

נתחיל במערכת שמתאימה יותר לחברה קטנה או ל-LAB מקומי: Proxmox.

תוכנת Proxmox מתאימה ליישומי וירטואליזציה הן על מערכות ישנות (כן, אותו שרת G7 של HP שיושב שם בצד) והן על מערכות חדשות. המערכת עצמה היא יחסית קלה ללימוד, ומי שעבד על ESXi עם vCenter בצורה לא מקצועית (כלומר לא עבר קורסים והכשרות של VMware) יוכל להקים תוך דקות ספורות מכונות וירטואליות על דיסקים מקומיים, לחבר NFS או iSCSI וגם להשתמש ב-HA ולבצע Live Migration (כל עוד יש אחסון משותף, זו לפחות הדרך המומלצת). בקיצור -אם אתם צריכים להקים מערכת וירטואליזציה על מספר קטן של שרתים, ללא הקמה של רשתות וירטואליות מורכבות או דברים הרבה יותר מורכבים (DVSwitch?) – אז Proxmox יכול להתאים למשימה.

המערכת הבאה יותר מתאימה לחברות שמריצות מערכות וירטואליזציה מורכבות עם רשתות וירטואליות שונות (המערכת משתמשת ב-Open Virtual Network ו-Open vSwitch, וכן רשתות SDN), סטורג'ים בפרוטוקולים שונים, חיבור ל-OpenStack, ודברים נוספים. המערכת היא oVirt. טכנית, oVirt נבנתה מגירסה 4 להריץ מערכות גדולות וכשאני מציין גדולות, אני מדבר על אלפי ועשרות אלפי מכונות וירטואליות. בשעה שפתרונות כמו ProxMox מתרכזים ב-Bridge Networking, מערכת oVirt תומכת במספר פתרונות רשתות וירטואליות, והיא בין המערכות היחידות שתומכות גם בפלטפורמות שאינן X86-64 כמו מערכות Power ו-S390 של IBM. מבחינת HA, היא בין המערכות המובילות בדיקות ברמת חומרה (דרך ILO/IMM/IDRAC) מה קורה לברזל והיא יודעת להעביר את ה-VM אם יש תקלה ולטפל בשרתים פיזיים בעייתיים – החל מהקמה של חדשים, שדרוג קיימים ועוד. מערכת oVirt מבוססת על מערכת KVM האחרונה (כן, אותה חברה שמפתחת את oVirt היא אותה חברה שמפתחת את KVM – זו רד-האט) כך שיש תמיכה בציודים וירטואליים חדשים, מערכות UEFI וירטואליות מודרניות ועוד), התממשקות ל-VCenter, המרה יעילה של מכונות וירטואליות ל-oVirt, תמיכה ב-AD/LDAP ועוד שורה ארוכה של פונקציות. בהשוואה ל-Proxmox, מערכת oVirt היא מפלצת ולכן היא פחות מתאימה לרוץ על שרתים עם מכונות וירטואליות שמאוחסנות על דיסקים מקומיים. oVirt, אגב, מגיעה מוכנה לשימוש הן כשרת שיתחבר לסטורג' והן כ-Hyper Converged.

oVirt מתאימה להטמעות גדולות הן כ-PoC והן כפרודקשן כל עוד יש בחברה ידע פנימי (או יועץ חיצוני) שיכול לתת תמיכה. מנהלים שמנוסים עם VMWare או Hyper-V ואינם מנוסים מספיק או בעלי ידע רציני בלינוקס יתקשו בניהול מערכת כזו ללא השקעה בלימוד הדברים, והסיבה לכך פשוטה: oVirt אינה מנסה להיות העתק של VMware והדגש של oVirt הוא יותר על פונקציונאליות מאשר חזותיות (אם כי חל שיפור ניכר בחלק הזה בגירסה 4.2 ובגירסה 4.3 שתצא במהלך 2019). חברות שמעוניינות במוצר ארוז ובתמיכה רשמית עם רשיונות – ניתן לרכוש את מוצר ה-RHV עם תמיכה.

ומכאן – למפלצת הגדולה: OpenStack.

אם oVirt היא מערכת גדולה, OpenStack היא גודזילה לכל דבר ועניין. ההבדל הגדול בין oVirt ל-OpenStack הוא ש-OpenStack מנסה לתת לך הכל מהכל. וירטואליזציה? יש. קונטיינרים? יש את Zun שמאפשר להריץ קונטיינרים כ-שרות. DB כ-שרות? יש. אחסון תואם S3? יש. אחסון Images ודברים אחרים? יש. צריך Load Balancer? תכיר את Octavia, ויש עוד עשרות חלקים. עם oVirt לעומת זאת – המיקוד הוא לכיוון מתן שרותי וירטואליזציה והשרותים מסביב, לא יותר מכך.

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

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

ומה העתיד?

פתרונות הוירטואליזציה ממשיכים להתקדם, גם הפתרונות המסחריים הסגורים אך גם הפתרונות מבוססי הקוד הפתוח. ב-VMWare הכריזו בכנס האחרון על ESXI ל-ARM, פלטפורמה שנכנסת יותר ויותר לספקי הענן הציבורי ו"זוחלת" לכיוון ה-Enterprise (תסתכלו על Ampere). פתרון הוירטואליזציה KVM ו-QEMU (שבהם כל מערכת בנייה כמו Yocto משתמשות) יש תמיכה בעשרות מעבדי ARM כבר 6 שנים ומעלה, מערכת OpenStack תומכת ב-ARM, ו-oVirt תתמוך כנראה בגירסה הבאה (אם לא תהיה גירסה כזו, אני כנראה בשנה הבאה ארכוש שרת ARM ואבצע BUILD לכך. מהנדסי רד-האט ישראל – תתכוננו להצקות ממני 🙂 ). עוד ארכיטקטורה שהולכת להיתמך היא מעבדים זולים מבוססי MIPS החדשים.

מבחינת תקשורת – רשתות 100, 200 ו-400 ג'יגה יהפכו לאט לאט לנורמה והמתגים עצמם יהיו מבוססים שבב מרכזי קנייני ושבב ARM שמריץ לינוקס, ומי שינהל את המתג – זו מערכת הוירטואליזציה (דרך הלינוקס שרץ על המתג).

מבחינת אחסון: ישנו תהליך יחסית די חדש שיכנס לאט דרך יצרני ה-SSD והוא "העפה" של מערכת הבקר מה-SSD כך שמערכת הוירטואליזציה תחליט איך לנהל את ה-SSD, איך לבצע Garbage Collection לפי העומסים במכונה, לפי המכונות הוירטואליות שירוצו ועוד. אינטל גם תוציא את ה-Optane DC Persistent Memory – מקלות אחסון שיושבים היכן שמקלות הזכרון יושבים, מכילים הרבה יותר אחסון ממקלות זכרון ECC רגילים ועם ביצועים קרובים לביצועי זכרון. תמיכה לכך ב-OpenStack תהיה קיימת בקרוב (להלן השקפים), רק שמחכים למעבדים ושרתים מבוססי Cannon Lake SP.
עוד תחום אחסון שיקבל Boost רציני בוירטואליזציה הוא NVMEoF שיתן Latency מאוד נמוך.

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

אם יש לכם שאלות לגבי המוצרים, אתם מוזמנים ליצור קשר.

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

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