המעבר ל-DPU

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

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

  • סיבוב ראשון – פתרונות כמו ESX/ESXI ופתרונות וירטואליזציה של מתחרים התמקדו בכך שישנם חלקים פיזיים שונים שמרכיבים את פתרון הוירטואליזציה: יש פתרון אחסון יעודי, יש מתגים ונתבים, יש חומת אש יעודית ועוד מספר "ברזלים" שנותנים שרותים משלימים – ויש את כל שרותי ה-Compute שמתקבלים מהשרתים. כל דבר – בנפרד.
  • סיבוב שני – קונסולידציה – פתרונות כמו vSAN של VMware ופתרונות מתחרים – מעבירים את השרותים המשלימים ל-Compute – אל תוך ה-Nodes עצמם. אחסון? הכנס דיסקים ונקים. רשת? יש NSX ופתרונות אחרים שייתרו פתרונות "ברזלים" יעודיים לטובת פתרון וירטואלי, כך שבסופו של יום, מערכת כזו תהיה בנויה משרתים עם דיסקים, כרטיסי רשת ומספר מתגים פשוטים ותו לא. הכל מוקם, מוגדר ומתוחזק בתוך פתרון הוירטואליזציה.

הסיבוב הנוסף הוא בעצם "חצי סיבוב". השינוי העיקרי הפעם הוא שאנחנו מוציאים החוצה מעבודת המעבד כל מה שקשור לאבטחה, תעבורת רשת, אחסון, הצפנה וכו' – ואנחנו מעבירים את הכל לדבר שנקרא SmartNIC (או כפי ש-NVIDIA ו-AMD ואחרים רוצים שתקראו לזה: DPU. אינטל רוצים שתקראו לזה: IPU).

להלן תרשים שיפשט את הדברים:

(קרדיט: The Next Platform)

כפי שאנו רואים, ה-DPU (מצד שמאל למטה בתרשים לעיל) הוא זה שיריץ את שרותי ה-ESXI וכל שרותי ה-Management (לשם כך ה-DPU מכיל מעבד ARM עם מספר ליבות וזכרון) והשרת עצמו יריץ מערכת מינימלית שמכילה Hypervisor או כל מערכת הפעלה יעודית "על הברזל" – והמערכת תתממשק  אל ה-DPU, כך שה-DPU בעצם ינהל את השרת והשרותים.

מדוע בעצם עושים זאת? הסיבה לכך די פשוטה: אין זה משנה איזה מעבד X86-64 קיים לך בשרת, בין אם מדובר ב-Xeon של אינטל או ב-EPYC של AMD, המעבדים הללו טובים בדברים מסויימים כמו Compute, אך פחות טובים בכל מה שקשור לתקשורת, הצפנות, תעבורת רשת גבוהה, אחסון ברמה ובביצועים של SAN וכו', ודברים אלו יכולים להתבצע ביעילות עם שבבים יעודיים (ASIC או FPGA, תלוי ביצרן, בפתרון וכו') ולשם גם VMWare וגם היצרניות האחרות (חוץ מ-AMD, אינטל ו-NVIDIA, גם חברות אחרות מתכוונות להציע DPU משלהן, כמו Marvell, ברודקום וכו') רוצות להיכנס, ובמילים אחרות – מה שהיה פרויקט Project Monterey בעבר, עכשיו זה חלק אינטגרלי מ-vSphere 8 שיוצא.

מאיפה בעצם הגיע הרעיון לכך? התשובה די פשוטה: ספקי ענן ציבורי, ובמיוחד AWS. רוב השרתים ב-AWS (הסתכלו לדוגמא על AWS Nitro) כוללים בעצם מערכת שמכילה KVM לינוקסי מינימלי שמריץ רק מכונות וירטואליות, וכל שאר השרותים מתקבלים דרך כרטיסי PCIe Express בעלי שבבים יעודיים (דוגמת Pensando של AMD) שנותנים שרותים יעודיים כמו אחסון, תקשורת, הצפנה ושרותים נוספים לפי הצורך, כך שבעצם המעבדים בשרת לא מריצים כמעט מאומה – זולת ה-Compute של הלקוחות וה-Hypervisor המינימלי. בשיטה זו רמת האבטחה היא הרבה יותר גבוהה, וגם אם מאן דהוא יצליח לפרוץ לשרת, אין שרות אחסון שרץ מקומית בשרת שניתן להתחבר אליו ולגנוב ממנו מידע (כל התחברות בין VM לאחסון  דרך הכרטיס היעודי מבוססת הצפנה עם מפתח יעודי פר VM ויש עוד מספר אלמנטים לאבטחה).

יש גם נקודת לינוקס בכל העניין: מכיוון ש-DPU מכיל במקרים רבים מעבדי ARM עם אחסון וזכרון עצמאיים נפרדים מהשרת, אפשר לתכנת אותם, ו-Linux Foundation, יחד עם יצרני חומרה נוספים הקימו פרויקט שנקרא Open Programmable Infrastracture Project (ובקיצור – OPI) כדי לעודד חברות תוכנה לכתוב אפליקציות ודברים נוספים עבור אותם DPU.

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

… שלא מתאים לכולם.

למען האמת – אפילו לא לרוב אלו שיש להם מספר קטן עד בינוני של שרתי ESXI.

אני חושבת שיש צורך לספר משהו אחד פשוט לגבי אותם IPU/DPU שהולכים להיות מוצעים: כל הפתרונות הללו נבנו בראש ובראשונה עבור ספקי ענן ציבורי (אז'ור, AWS, GCP, אני בספק אם אורקל משתמשת בכך), ואותן יצרניות החלו להוסיף ולשנות את הפתרונות כך שיוכלו לעבוד עם Project Monterey, כך שבסופו של יום – מדובר על פתרון שהוא מאוד חדש, ואינני בטוחה אם אפשר לקרוא לו "יציב", ובכל מקרה – מחירי כרטיסים כאלו – גבוהים מאוד, ויש צורך גם במתגים עם תמיכה במהירויות גבוהות (25 או 50 ג'יגהביט כמינימום!) – כך שגם אלו שרוצים פתרונות DPU כאלו, לא בטוח שזה יתאים להם.

לסיכום: DPU הוא פתרון מעולה, כאשר יש לארגון עשרות רבות, מאות או אלפי שרתי ESXi. לשאר הארגונים, מעבדי X86-64 כמו Xeon או EPYC – יתנו עבודה כלל לא רעה, ובמיוחד במעבדים העתידיים של שתי החברות ששואפות להכניס רכיבי האצה שונים לתוך מעבדיהן – ואת התוצאות לכך נוכל לראות בחודשים הקרובים.

השוואת Proxmox למתחרים

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

קצת מידע על Proxmox – מדובר מערכת ותיקה שהחלה את חייה עוד לפני שלמעבדי X86 היו יכולות וירטואליות בחומרה כמו שיש להם כיום, ולפיכך המערכת תמכה בפתרון וירטואליזציה כמו OpenVZ – הרצת מערכת לינוקס (ומערכות אחרות, אך לא Windows) בקונטיינר (אם כי פורמט הקונטיינר שונה מפורמט כמו של Docker וכו'). מאוחר יותר, כש-KVM בלינוקס צבר עם QEMU פופולריות, הוא הוטמע בפתרונות רבים (כל ספקי הענן הציבורי משתמשים ב-KVM הלינוקסי, מיקרוסופט ב-Azure משתמשת ב-KVM ב-Instances המאפשרים Nested Virtualization) וגם ב-Proxmox וכיום כשמקימים מכונה וירטואלית ב-Proxmox, היא תרוץ עם KVM.

כשזה מגיע לוירטואליזציה, Proxmox עומד בכבוד מול המתחרים ויש לו כמעט את כל מה שיש בפתרונות Hypervisor מתחרים. אין בעיה להצמיד ב-VM חומרה מסוגים וחיבורים שונים, המערכת תקבל בשמחה כל דיסק עם כל File system כ-Storage, כולל ext3, ext4,btrfs, zfs,ceph, glusterfs, והמערכת גם כוללת תמיכה שיתופית באחסון: יש לך דיסקים במכונה אחת אך לא במכונה אחרת? אין בעיה! בהגדרת ה-Storage, בחר ב-All Nodes (ראו תמונה לעיל, לחצו להגדלה) והמערכת תייצר עבורך NBD מבלי שתצטרך להרים NFS או CIFS עם כל ההגדרות. גם כשזה מגיע לשרידות, יש ל-Proxmox מה להציע (כל עוד יש לך 3 מכונות פיזיות) – הגדר את המכונות הוירטואליות שאתה מעוניין שישרדו, והמערכת תבצע להן מיגרציית Live אם אחד השרתים יורד בצורה מסודרת, או שהיא תריץ את ה-VM מחדש במכונה אחרת (כל עוד האחסון מבוסס על NFS או CIFS. קצת בעייתי לבצע שרידות שכל הדיסקים יושבים על שרת אחד שבדיוק מכבים אותו)…

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

מה קורה אם ניקח את Proxmox ונשווה אותו לפתרונות יותר גדולים כמו oVirt/RHV או vSphere של VMware? התשובה פשוטה: אין ל-Proxmox סיכוי להתחרות, הואיל ו-Proxmox לא כולל חלקים רבים. קחו לדוגמא עניין כמו איזון עומסים של מכונות VM בשרתים (ב-VMWare זה נקרא DRS, ב-oVirt/RHV זה נקרא Scheduling Policies) – זה לא קיים ב-Proxmox. עוד דוגמא קשורה לניצול כל הדיסקים הקיימים בשרתים ליצירת מערך אחסון גדול ושורד. נכון, יש GlusterFS שנתמך ב-Proxmox, אולם ל-Proxmox אין מושג ירוק מה קורה עם ה-GlusteFS – אתה יכול לבצע Mount וזהו. ב-VMware לעומת זאת, פתרון vSAN ליצירת אחסון מדיסקים – נלקח הרבה יותר ברצינות (ב-oVirt/RHV היה פתרון Hyperconverged מבוסס GlusterFS אולם הוא היה פתרון חצי אפוי והוחלט בשקט לבעוט אותו החוצה). אם נבחן לדוגמא את עניין הרשתות ושימוש ברשתות וירטואליות, הממשק ב-Proxmox מאוד אנמי (אין לך אפשר להגדיר דברים כמו VLAN, Slaves ודברים רבים דרך הממשק, אין לך אפילו אפשרות לראות אם החיבור נפל או לא, ואם אתה מתעקש להגדיר, אתה צריך לעבוד בדרכים הישנות, כמו לפני ש-NetworkManager או Netplan היו קיימים) ואילו ב-vSphere או RHV הדברים נלקחים בצורה הרבה יותר רצינית (הנה דוגמא ב-oVirt), ועוד לא דיברנו על ההתעקשות של מפתחי Proxmox לא לשלב את libvirt – ה-API הגדול והמשמעותי ביותר לכל ענייני וירטואליזציה בלינוקס ובמערכות הפעלה אחרות.

לסיכום: Proxmox הוא פתרון מעולה, למצבים מסוימים – אם רוצים להעביר משרד קטן P2V לשימוש ב-Thin clients כשהכל רץ על שרת אחד או שניים, לסטארט אפ קטן שאין לו תקציבים כרגע להשקיע בתשתית והוא לא רוצה/לא יכול להתחיל לעבוד בענן ציבורי ועוד, אך מעבר לכך – ארגונים גדולים, חברות גדולות, מוסדות ועוד – מומלץ שימשיכו להשתמש בפתרונות של VMware (או Nutanix) ומומלץ גם להכיר מה הולך לקרות ב"גל" הבא – ועל כך אפרסם פוסט נפרד.

עדכונים בנושאי וירטואליזציה ו-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 ועוד.

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

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

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

תכירו את Kubevirt

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

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

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

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

אחת הבעיות שנוצרות מהכנסת קונטיינרים ומערכת ניהול/אורקסטרציה (כמו Kubernetes, OpenShift, Docker-swarm ואחרים) היא שמעתה צריך לנהל 2 מערכות שונות. האחת לניהול השרתים הוירטואליים שלכם (Hyper-V, vSphere) ואחד לניהול הקונטיינרים שלכם ולמרות שברמה העקרונית שתיהן מרימות דברים שהם מופרדים (קונטיינרים, VM), יש תהום של הבדלים ביניהם:

  • ב-Kubernetes הרשת מנוהלת בצורה אחרת לגמרי
  • כל עניין ה-Clustering הוא משהו שונה וחדש שלא קיים בשום פתרון וירטואליזציה
  • דיסקים בכלל מוגדרים בצורה שונה ואין אפשרות לנהל את ה"דיסקים" בפתרון כמו Kubernetes (להגדיל, להקטין דברים שקיימים)
  • שיטת העבודה עם Kubernetes (ו-OpenShift) היא בכלל שיטה "הצהרתית" (כלומר אתה מצהיר מה אתה רוצה שיקרה, המערכת עובדת על לקיים את רצונך. Genie כזו 🙂 ).

יחד עם זאת, לא היה נחמד יותר להשתמש ב-Kubernetes (או OpenShift או CAAS של SuSE)?

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

תכירו את Kubevirt.

הרעיון של Kubevirt הוא די פשוט: בתוך Kubernetes יש דבר שנקרא CRI (ר"ת Container Runtime Interface). פרויקט oVirt מרחיב את ה-CRI ואת Kubernetes עצמו כך שיוכל להפעיל גם מכונות וירטואליות כאילו מדובר בהפעלת קונטיינרים. בד"כ ע"מ ליצור POD עם קונטיינר, אנחנו יוצרים קובץ בפורמט YAML (או JSON, בהתאם להעדפות), וכאן הדברים יהיו דומים. הנה דוגמא לקובץ YAML כזה.

אם נשתמש ב-kubevirt עם קובץ ה-YAML הזה, תקום לנו מכונה וירטואלית קטנה (64 מגה זכרון) והדיסק שלה יהיה iSCSI. כך נוכל לערב בין קונטיינרים למכונות VM, לפי הצורך.

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

לאלו שמעוניינים להבין מה קורה מאחורי הקלעים, הוידאו הפעם מכנס KVM פורום יוכל לסייע:

עדכונים לגבי ESXI

זמן רב לא כתבתי על VMWare ESXI והגיע הזמן אולי לפרסם כמה דברים שחלק מהקוראים יודעים וחלק לא וגם לתת לכם זמן לחשוב לגבי גירסה עתידית של ESXI והאם כדאי יהיה לעבור אליה.

נתחיל בהווה: אם יש לכם גרסאות 4, 5, 5.1, 5.5 אז אולי הגיע הזמן יהיה לחשוב על שדרוג. לפי המסמך הזה של VMWare, גרסאות 4, 5.0, 5.1 כבר סיימו את חייהם מבחינת תמיכה ואם אתם מריצים גירסה 5.5 – היא תסיים את חייה ב-19/9/2018 כך שכדאי בתכנון התקציבי להכניס הוצאת שדרוג.

אם אתם משתמשים בגירסה 6.0 של ESXI אז מאוד מומלץ לשדרג לגירסה 6.5U1. השינויים בין 6.0 ל-6.5 הם רבים וכוללים שינויים ועדכונים ל-vSAN, עדכוני דרייברים רבים, מעבר ל-VSCA (ב-VMware ממש רוצים שתעבור ל-VCSA והם נותנים "הטבות" ב-VCSA כמו כלי מיגרציה, High Availability "טבעי", וגיבוי ושחזור "טבעיים" (של ה-Appliance, לגיבוי מכונות VM תמשיכו להשתמש ב-Veeam). ההתקנה של VCSA הרבה יותר קלה ואתם יכולים לקרוא על מגוון התכונות החדשות במסמך הארוך והרשמי כאן או בגירסה המקוצרת כאן. השדרוג מ-6.0 ל-6.5U1 עולה לכם … 0 שקלים מבחינת רישוי.

אם יש לכם גירסה 6.5, מאוד מומלץ לשדרג ל-6.5U1 בגלל כמה סיבות, להלן חלק מהן:

  • גירסת VSAN שודרגה ל-6.6 (והיא מצריכה ESXI 6.5 כולל VCSA 6.5 או אם אתם עדיין בגירסת Windows – אז vCenter Server 6.5 – מומלץ בחום לעבור ל-VCSA, הוא יעביר לכם את הנתונים אוטומטית) ואם אתם עובדים All Flash תקבלו הפתעה נחמדה – שיפור של 50% בביצועים. בנוסף תכנון גדילה עובר עתה תהליך Pre-check כך שהדברים יהיו יותר בטוחים ולא יפלו עקב חישוב שגוי מצד מנהל המערכת. בנוסף מקבלים את vRealize Operation Management, תהליך ה-Deploy יותר קל, תהליך בדיקת התקינות שופר מאוד, אין יותר צורך ב-Multicast (אני יכול לדמיין אנחת רווחה מאנשי התקשורת), שיפורים ב-Cross Site Protection (לאלו שמשתמשים בזה, לא מכיר כאלו) ועוד. אפשר לקרוא מה חדש כאן.
  • אם אתם חושבים לרכוש ברזלים חדשים כמו שרתים מבוססי מעבדי EPYC (שאפו!) או שרתים מבוססי דור 5 של Xeon – תצטרכו את ה-Update 1 של גירסה 6.5, אחרת תקבלו מסך סגול והמון עצבים. לאלו שרוצים להריץ בביתם כ-LAB את גירסה 6.5 על מעבדי Ryzen או Threadripper או Skylake-X – גם אתם תצטרכו את גירסת 6.5U1. (לא מומלץ לנסות על Kabylake-X – ניסיתי, זה נופל לאחר זמן מה מבחינת ביצועים ו-VMware אפילו לא מוכנים להתייחס לכך).
  • עדכוני דרייברים – ישנם עדכונים לכל כרטיסי הרשתות, החל מכרטיסים בסיסיים כמו כרטיסים מבוססי אינטל של 1 ג'יגהביט ועד לכרטיסים של 40/50 ג'יגהביט (למיטב ידיעתי כרטיסים של 100 ג'יגה תצטרכו דרייבר יצרן עדיין).
  • ה-vCenter יכול להיות ב-High Availability באופן טבעי ללא צורך בקפיצת ראש לבריכה בעומק חצי מטר. מגדירים Active, Passive ו-Witness ויאללה – יש HA. פונקציה זו אינה קיימת בגירסת Windows. כמו שאמרתי – VMWare מאוד רוצים שתעופו מגירסת ה-Windows לטובת גירסת ה-Appliance.
  • שדרוג מכונות ESXI הרבה יותר קל וברוב המקרים אוטומטי לגירסה אחרונה עם VCSA. שימו לב: קודם משדרגים Appliance ורק אז את ה-Hosts.
  • גם VUM עבר שדרוגים בכל הקשור לעדכונים ומעתה הוא יכול גם לשדרג אוטומטית (אם תרצו) מכונות VM לגירסה אחרונה (או גירסה שתקבעו) של תאימות VM.
  • בכל הקשור ל-Auto Deploy, מי שמנהל את ה-vSphere בחברה אולי ישמח לדעת שהוא פחות יצטרך להשתמש ב-PowerCLI ועכשיו יש ניהול גרפי מלא של הדברים וגם בניית Image חדש של ESXI Boot תוך כדי הוספה והעפה של דרייברים.
  • ויש עוד ערימות של תכונות חדשות…

אחד הדברים החשובים לגבי תשתית vSphere מהגירסאות הקיימות לגירסה 7 העתידית – זה שגירסה 7 העתידית תהיה שונה מאוד ממה שהיה עד כה. זה לא סוד ש-VMWare עובדים לאט (רק בגירסה 6.5 הם התחילו לתמוך ב-VMWare tools חתומים והתקנה של מערכות הפעלה עם Secure Boot), אבל בגירסה 7 הם רוצים לסגור פערים. העולם עובר לקונטיינרים וכרגע ל-VMware אין תשובה ב-vSphere באופן רשמי, כנ"ל לגבי פתרון תחרותי ל-OpenStack או Azure Stack של מיקרוסופט (אם כי יש להם כלי להקים OpenStack בתוך vSphere – ראו למטה), כך שגירסה 7 תהיה שונה לחלוטין מכל הגרסאות הקודמות. אי אפשר למסור עליה פרטים (אין לי הסכם NDA עם VMware אבל מצד שני אין לי חשק מחר לקום בבוקר ולקבל טלפון וצעקות מאנשים שם) אך מה שכן אפשר לאמר – שהיא בהחלט תקל על חברות גדולות שרוצות לעבור להשתמש בקונטיינרים (ויש לה כבר פרויקטים בקוד פתוח בנושא, אפשר לראות אותם כאן – ויש המון). משהו אחד שאני יכול להמר (אין לי בסיס משמועות לכך) זה ש-VMWare גם תבצע אינטגרציה של VMWare Integrated Openstack לתוך vSphere בעזרת מוצרים משלימים שיש כבר ל-VMware ובעזרת חלקים בקוד פתוח (שהיא תשחרר שינויים תחת אותם רשיונות). אגב, למי שלא מכיר את התוכנה – מוזמן לעקוב אחר המצגת הנחמדה כאן.

לסיכום: ישנם לא מעט חברות גדולות שרוצות להישאר רק על VM, לא ענן מבוסס OpenStack, לא קונטיינרים (אולי בעתיד) וחברות רבות הן גם מאוד שמרניות, לכן אני חושב שנראה כאן מעין "קו" וירטואלי בין מוצרים והטמעות שחברות יבחרו. עד גירסה 6.5U1 ה-vSphere סובב כולו סביב VM והתשתיות לספק את הדרישות ל-VM (רשתות, סטורג' וכו'). מגירסה 7 המוצר יהיה הרבה יותר גדול ומורכב בהרבה מהיום ולא בטוח שחברות ירצו לקפוץ אליו  ויש מצב שיותר ויותר חברות יחליטו להישאר עם 6.5U1 ואת השאר להעביר לעננים ציבוריים במקום לשדרג לגירסה 7 (ודרך אגב, אני מאמין שגירסה מוקדמת שלה אנו נראה ב-VMWorld שתתרחש עוד 18 יום ולאחר מכן ב-VMWare Europe. אגב, בכנס הזה נראה את התשובה של VMWare לאינטגרציה עם עננים ציבוריים, לא רק של אמזון).

הולך להיות מעניין…

על Virtual Flash Cache ב-ESXI 5.5

אחת הפונקציות המעניינות שקיימות ב-vSphere נקראת Virtual Flash Cache. ב-VMWare התחילו להטמיע את זה אמנם מגירסת vSphere 5.0 אולם רק בגירסה 5.5 עניין ה-Cache עובד בצורה טובה ומלאה. ב-VMWare קוראים לזה בקצרה vFRC, נשתמש בפוסט זה במושג המקוצר.

נתחיל בהסבר של מה זה vFRC: זו בעצם טכנולוגיה שקיימת גם בשאר מערכות הפעלה שונות (כמו לינוקס לדוגמא) המאפשרת לנו להשתמש ב-SSD שיושב מקומית בתור שרת ה-ESXi (ולא ב-Storage המרכזי) ובעצם הוא מאחסן חלק מהנתונים שנקראים תדיר ע"י מערכת ההפעלה ומאפשר בעצם Read & Write Cache. ה-Cache אינו בא להחליף את ה-Storage שלכם וכל ביט שיכתב ב-Cache יכתב גם ב-Storage, כך שאם ה-SSD המקומי מתקלקל, אפשר להחליף, לפרמט ולחזור להשתמש בפונקציונאליות.

מערכת ה-Cache נמצאת ב-2 מקומות מרכזיים: במקום אחד שבו אתם יכולים להגדיר כמות X ג'יגהבייטים שהמערכת תשתמש בעת מצב שהיא תהיה עמוסה ואז אותם X ג'יגהבייטים ישמשו כ-Swap (ואם אתם משתמשים ב-Swap, הגיע הזמן לשוחח עם הקודקודים למעלה על שדרוג מהיר)

המקום השני הוא שבו משתמשים ב-vFRC הוא על המכונות הוירטואליות, וכאן אני צריך להסביר משהו חשוב: לא חשוב מה ה-Storage שיש לכם, בכל פעם שה-VM צריך מידע לקרוא או לכתוב על ה"דיסק" – ה-VM צריך לעשות "טיול" ל-Storage שלכם דרך ה-Datastore, ובין אם ה-Datastore שלכם מבוסס על iSCSI, NFS או FC, מדובר (פחות או יותר) ב"טיול" שלוקח זמן. נכון, זמן קצר, אך בכל זאת.

אם ניקח דיסק SSD מקומי על ESXI ונתקין עליו VM, הביצועים שלו יהיו מעולים בהשוואה למה ש-Storage נותן (למעט בתקשורת של 10Gbit), אבל אז כמובן לא תוכלו להשתמש בפונקציות מתקדמות כמו HA, DRS וכו'.

עם vFRC, זה לא חשוב מה ה-Storage שיש לך, בין אם הוא מורכב מכמה דיסקים SATA שהצלחת לקושש או שמדובר על מערכת EMC או כל מערכת יוקרתית בטירוף – ל-vFRC זה לא משנה. ה-vFRC שומר חלק מהנתונים (בהתאם לגודל שהגדרת) מקומית על SSD שקיים בתוך ה-ESXI והוא מזין את הנתונים שנכתבו בחזרה ל-Storage "מאחורי הקלעים" כך שמבחינת ה-VM, המערכת ממשיכה לפעול גם אם הכתיבה בין ה-vFRC ל-Storage מתבצעת כרגע. כנ"ל לגבי קריאה – קטעים שהמערכת מוצאת שנקראים שוב ושוב (נניח אפליקציה גדולה שרצה על ה-VM ומטעינה ספריות שונות) מאוחסנים ב-SSD המקומיים ומוזנים ל-VM ישירות ברגע שה-VM צריך את אותם קטעים. המערכת גם מספיק חכמה להעיף חלקים ישנים מה-Cache שאין צורך או שנגמר המיקום שמוגדר ל-Cache ויש צורך לכתוב מקטעים חדשים.

הקמת ה-vFRC היא פשוטה: לאחר שהכנסתם SSD ל-ESXI, הפעילו את ה-vCenter (ה-WEB, לא ה-Client הישן), לחצו על ה-HOST שהוספתם, לחצו על Settings, ולמטה אתם תמצאו את ה-Virtual Flash. להלן דוגמא ממערכת טסטים בביתי (לחצו להגדלה):

vfrc

המלבנים האודמים מציינים מה ללחוץ, המלבנים הכחולים מציינים את הכונן שנבחר והגודל שזמין ל-Cache עבור VM (במקרה הספציפי הזה הגדרתי 20 ג'יגה ל-Swap). המלבן הירוק מציין סה"כ כמות מקום פנוי במידה והכנסת יותר מ-SSD אחד (חשוב לציין: Virtual Flash עובד ברמה של RAID-0 מכיוון שכל ה-DATA הוא זמני)

כפי שציינתי, הגדרות Cache ל-VM נעשות פר VM (אם כי יש כל מיני כלים לעשות זה באופן קבוצתי, אני פשוט משתמש ב-BASH ו-sed לשם כך 😉 ) על מנת להגדיר כמות ג'יגהבייט Cache. כך זה נראה (לחצו להגדלה):

vfrc2

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

vfrc3

רואים את ה-Block Size? הגודל עצמו חשוב מאוד וזה תלוי ב-VM, גודל ה-DATA שהוא כותב וכו'. חישוב לא נכון יתן מה שנקרא Cache Miss מה שיוריד מהביצועים. החישוב אינו כל כך פשוט אך ב-VMWare הכינו מסמך שמסביר את ה-vFRC מבחינת ביצועים, חישובים שצריך לבצע וכו'. להלן המסמך.

[scribd id=268003224 key=key-UjCvDIBCgd52bjCNMHWt mode=scroll]

לסיכום: vFRC יכול לעזור הרבה (לפעמים עד מצב של 300% שיפור) בביצועים, אם עושים את זה נכון. אני לא ממליץ לרוץ מיד לקנות SSD מבוסס PCIe אלא להתחיל בטסטים עם SSD פשוט מבוסס SATA. יש שיפור? עכשיו אפשר לחשוב להוסיף דיסקים SSD בין אם הם מבוססים SAS או SATA או PCIe (אם יש לכם מקום פנוי בשרת). אפשר כמובן להכניס יותר מאחד.

vFRC עוזר בכל מיני סוגי VM ואין צורך בשום שינוי ב-VM עצמו (ב-Guest), וזה בהחלט יכול לעזור אם מקימים VDI, רק חשוב לשים לב לגודל הבלוקים. גדלים כמו 1024 (המקסימום) קילובייט יבטיח לכם Cache Miss וירידה בביצועים, ומצד שני כמות בלוקים קטנה (4-8K) לא ממש תיתן ביצועים רציניים. קראו את המסמך, ותנסו (אין צורך לכבות ולהפעיל את ה-VM מחדש כשמשנים, אם כי מומלץ לסגור את האפליקציה ב-VM ולהפעיל אותה מחדש).