תכירו: vCompute Server של NVidia

במסגרת כנס VMWorld שנערך השבוע, חשפה NVidia את המוצר החדש שלה שהוא vCompute Server (נקרא לזה בקצרה VCS) שמתאים לאלו שצריכים להריץ עומסי AI, DL בסביבות וירטואליות.

עד היום, חברות שרצו להריץ למטרות Training ופיתוח עומסי AI בסביבה וירטואלית, היו צריכים לעשות זאת עם ה-vGPU ש-Nvidia מוכרת. בשיטה הזו מקצים חלק מכרטיס ה-GPU שיושב בשרת לכל VM (אגב, לידיעה: vSphere 6.7 U3 מאפשר לראשונה להצמיד מספר vGPU למכונת VM, לא רק vGPU יחיד).

לשיטה הזו יש כמה חסרונות רציניים:

  • ה-vGPU לא תוכנן מראש עם ה-CUDA לשימושי AI,DL. כן, הוא יכול להריץ זאת (גם מעבד גרפי נמוך מאוד כמו MX150 בלאפטופ יכול להריץ זאת), אך לא בצורה אופטימלית.
  • אם אתם משתמשים בקונטיינרים עם ה-Runtime Container של NVidia, זה לא היה מנצל את היכולות האמיתיות של הכרטיס (TCC, nVLink וכו') אלא היה מתייחס ל-vGPU בלבד.
  • אין תמיכת NVLink
  • אין אפשרות אגרגציה טבעית (מעבר למה שה-vGPU נותן).

הפתרון של NVidia הוא ה-VCS, מערכת חלופית שנותנת "vGPU" אבל למערכות AI,DL (כל עוד ה-VM לא מריץ שום דבר גרפי כי .. אין דרייבר גרפי).

מערכת ה-VCS פותרת את החסרונות של ה-vGPU ה"קלאסי" ונותנת את הפוקנציונאליות הבאה (אפשר לקרוא מעט יותר בהרחבה על כך בקובץ ה-PDF הזה):

  • אפשרות לחלק את ה-GPU לחלקים (Fraction) או לבצע אגרגציה של מספר v-GPU מכרטיסים שונים ובגדלים שונים.
  • מהירות עבודה יותר גבוהה (כי אין צורך לכרטיס לבצע רינדורי גרפיקה של מסכים וירטואליים/תלת מימד/וידאו וכו')
  • שימוש ב-NVLink בחיבור Peer to peer.
  • מיגרציה – מעתה אפשר לבצע vMotion (באשכולות לדוגמא) גם כשהמכונה רצה, לבצע suspend, resume.
  • תמיכה ב-Multi Tenant.
  • שימוש מ-NRC לקונטיינרים יהיה מהיר יותר, הואיל והמודול בלינוקס יודע להשתמש בכל היכולות של ה-GPU בשרת.

החסרונות:

  • אין דרייברים לגרפיקה (אז תשכחו מאובונטו גרפי – ואם אתם עדיין רוצים סביבה גרפית, תכירו את NoMachine)
  • אין דרייברים ל-Windows (כן, לכל גרסאות Windows)
  • אין יותר פרופילים קטנים, הן ברמת זכרון (המינימום הוא 4 ג'יגה, המקסימום הוא 48 ג'יגה) והן ברמת CPU (מינימום 4 ליבות, מקסימום 48 ליבות).
  • אין תמיכה ב-Quadro הישנים (יש תמיכה ב-Quadro RTX)

מבחינת רישוי: תצטרכו רישוי בתשלום שנתי, פר GPU.

פתרון ה-VCS בהחלט מתאים כמובן (ומומלץ) לשימוש עם Kubernetes, קונטיינרים וכו'.

ובעניין מעט שונה: נודע לי כי רוב החברות שרוכשות GPU בשרתים לצרכי AI – רוכשות RTX 2080TI ובכמויות נכבדות. כפי שציינתי בעבר, כרטיסים אלו אינם מתאימים לשרתים, הואיל והם צריכים כניסת אויר מצד שמאל ואילו כל הכרטיסי GPU לשרתים מצריכים איוורור מאחורי הכרטיס (בגלל זה הכרטיסים אטומים מצד שמאל). מהרגע שאתם מכניסים RTX 2080TI, אתם צריכים לקחת בחשבון שהכרטיס מהר מאוד יבצע שנמוך מהירות שעון הואיל ואין לו קירור מספק ואתם יכולים להגיע למהירות עיבוד של .. RTX 2070.

מעבר לכך, עם ה-VCS יש סוף סוף ניצול לחיבור ה-NVLink והעברת המידע ב-GPU בין הכרטיסים במהירות של 100 ג'יגהביט לשניה. ב-RTX 2080TI יש רק חיבור אחד כך שניתן לצוות מקסימום זוג כרטיסים. אם נכניס 8 כרטיסים כאלו לשרת וננסה להשתמש בכולם (הגדרת TCC), המערכת תצטרך לעבוד יותר לאט הואיל וה-DATA צריך לעבור הלוך ושוב בין ה-GPU (דרך המעבד וה-RAM בשרת) לדיסק וההיפך, ואילו עם כרטיסי Tesla וכרטיסים אחרים לשרתים (Quadro RTX) ה-DATA עובר בין כרטיסי ה-GPU דרך ה-NVLINK כך שהדברים רצים הרבה יותר, ועוד לא הזכרתי שמבחינה חוקית NVidia אוסרת על הפעלת כרטיסי RTX 2080TI (או כל RTX "ביתי") על שרתים והם יכולים מחר בבוקר בעדכון CUDA ודרייבר פשוט לבטל אפשרות שימוש בכרטיסים ביתיים בשרתים, כך שחשוב לקחת זאת בחשבון.

עוד נקודה ש-NVidia הכריזו היא הקמה של Repo חדש לקונטיינרים שמשתמש ביכולות CUDA ונקרא NGC. זה לא ממש חדש (ומשתמשים בו ב-DGX שלהם), אבל הפעם זה פתוח לקהל. לתשומת לב צה"ל, חברות בטחוניות וכו' שלא ממש מוכנים/יכולים לעבוד באופן ישיר מול האינטרנט – אין שום בעיה להוריד מה-REPO של NGC (ואחרים למען האמת) ולאכסן זאת דרך Registry משלכם. הנה לינק איך עושים זאת עם לינוקס.

לסיכום: אם אתם צריכים/משתמשים במערכת וירטואליזציה לצורך AI/DL או לשימוש עם קונטיינרים, הפתרון החדש של NVidia יכול בהחלט להתאים לכם. קחו בחשבון שאם אתם צריכים מקסימום מהירות, עדיף לרכוש את כרטיסי ה-Tesla או כרטיסי ה-Quadro (או כרטיסים עם האות V) עם חיבור NVLink כפול בכל GPU.

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

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

האם ה-Nvidia Grid עדיין רלוונטי?

כל מי שמתכנן וכל מי שהתחיל לעבוד עם מכונות וירטואליות בתצורת VDI בוודאי שמע ומכיר את ה-Grid של nvidia. פתרון ה-Grid מבוסס על מספר חלקים כמו ה-GPU, שרת רשיונות וכמובן חלקים נוספים הקשורים לפתרון ה-VDI עצמו בשרת וב-Client.

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

הבעיה קשורה יותר לכסף. בעבר הרחוק היית רוכש את פתרון התוכנה, את כרטיסי ה-GPU, מגדיר את הדברים ומתחיל לתת לעובדים שלך לעבוד, אבל כיום הדברים כרוכים בתשלום חודשי, והדברים מגיעים לכך שבחישובים של תשלום ל-3 שנים לדוגמא, עדיף לרכוש את הפתרונות של AMD המתחרה. שם אין תשלום חודשי והביצועים אינם פוחתים בהשוואה למה ש-nvidia נותנת, כולל פתרונות הדורשים OpenGL או DirectX 11/12 לעבודה, ויש תמיכה מלאה בפרוטוקולי Client של VMWare, של Citrix ושל מיקרוסופט.

אחד הנושאים שעולים לאחרונה בכל הקשור ל-Virtual GPU/Grid ותמיכה – קשור ל-AI ו-Deep learning. יותר ויותר חברות גדולות מגלות פלטפורמות כמו Tensor Flow או Caffe ומעוניינים לרתום את תשתית ה-Grid שלהם לשימוש עם אותם פלטפורמות.

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

אבל מבחינת ביצועים – כל כרטיסי ה-GPU מסידרה K,M,P במשפחת ה-GRID או Tesla או Quadro לא יתנו ביצועים גבוהים, במיוחד אם משתמשים בכרטיסים אלו לצרכי VDI – או אז במקרים כאלו המכונה מקבלת רק חלק קטן מה-GPU והביצועים .. בהתאם. כרטיסי Tesla או Quadro מסידרה V או T הרבה יותר מתאימים ליישומים אלו, אולם אם מדובר בכמות עבודה רצינית שאינה חד פעמית, אני ממליץ לנטוש מערכת GRID ולרכוש שרתים שיכולים להכיל מספר כרטיסי GPU ואז למפות מספר כרטיסים למכונה וירטואלית או מיפוי 1:1 בין GPU למכונה וירטואלית. יש כמובן גם אפשרות לרכוש כרטיסי RTX אולם כרטיסים אלו אינם מתאימים כל כך לשרתים הואיל והאיוורור שלהם הוא מהצד (Blower) ובמקרים רבים השרתים אינם בנויים לאיוורור כרטיסי GPU מהצד אלא מאחור.

נקודה חשובה לסיום: CUDA היא טכנולוגיה של Nvidia וחברות רבות משתמשות בטכנולוגיה זו במקום ב-OpenCL שנתמכת על ידי כל החברות האחרות. כבר בשנה הקרובה, אינטל הולכת להיכנס בסערה לשוק כרטיסי ה-GPU והיא תעשה את כל המאמצים לשכנע עסקים וחברות לרדת מ-CUDA ולהשתמש באותן פלטפורמות פיתוח עם OpenCL וכמובן – עם הכרטיסים שהיא תציע.

לסיכום: אם אצלכם בחברה חושבים להשתמש/לפתח בתחומי ה-AI או ה-Deep Learning, כדאי לחשוב על הנקודות שצוינו בפוסט זה. פתרונות ישנים לא תמיד מתאימים ולמרות הפתרונות של Nvidia – היא אינה השחקן היחיד בשוק ואין צורך לוותר על תאימות פלטפורמות כדי לעבוד לכרטיסי GPU אחרים או ל-OpenCL.

כמה מילים על 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.

קצת על אחסון נתונים ונקודות חשובות לפני החלטה

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

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

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

לפני שאמשיך – הערה קטנה: תודות לחברות שונות (CRG, ווסטרן-דיגיטל, סופר-מיקרו ואחרות) השאלתי ציוד כדי להעביד אותו בפרך (Stress Testing) למשך חודש או חודשיים, 24/7 עם תעבורה רציפה מקסימלית (תקשורת/דיסקים, מעבדים, מאווררים, תלוי בטסטים המתבקשים) בהתאם לסטנדרטים של IEEE וארגונים אחרים על מנת לבדוק לחברות וארגונים שונים אם המפרט שהם מבקשים יכול לעמוד בעומסים שונים. כך שהדברים שיכתבו כאן – נוסו.

(בתמונה למעלה: לקוח שרצה לבדוק LACP של 12 פורטים עם תעבורת נתונים של 16 פטהבייט. המבחן עלה לו יותר מסוויצ' 10 ג'יגהביט Low End, אבל – הלקוח דורש ומשלם, אני לא אומר "לא".)

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

הבה נתחיל.

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

  • כמה אחסון נטו אתם צריכים? עזבו חישובים של RAID כזה או אחר, דחיסה, dedup ושאר ירקות. 2 האחרונים הם נחמדים, אך לא תמיד יתנו לכם את מה שאתם מבקשים (זה תלוי בתכנים).
  • כמה לקוחות (clients) הולכים להשתמש בזה? יש הבדל ענק בין אחסון שמשמש לכמה עשרות/מאות מכונות וירטואליות, כמה אלפי משתמשים פיזיים שמשתמשים באחסון כ-File Server או עשרות/מאות אלפי משתמשים דרך האינטרנט.
  • האם החיבור בין האחסון למכונות אחרות ישתמש בתקשורת מהירה? (FC במהירות 8/16 ג'יגהביט, תקשורת 10 ג'יגהביט קואקסיאלית, TwinAX, סיב, Infiniband וכו') והאם אתה צריך ציוד חדש לחבר את הכל ביחד (גם בצד של השרתים, גם מתגים, חיבור לסטורג' עצמו וכו')
  • אחריות, SLA ושאר נושאים פרוצדורליים.
  • והכי חשוב – יחס הקריאה/כתיבה וסוג התוכן.
  • דיסקים SSD שישמשו כ-Cache, שימוש ב-Cache כ-Tiering וכו'.
  • פתרונות של Synology או QNAP.
  • הרחבת אחסון, זכרון.

להלן הנקודות בפירוט:

  • אחסון נטו: נניח ואתה צריך 40 טרהבייט אחסון נטו. אם נשתמש במחשבון הזה תוכלו לראות ש-5 דיסקים של 10 טרהבייט יתנו לנו 40 טרהבייט אחסון נטו עם שרידות של דיסק אחד (כלומר RAID-5). מצד אחד זה יכול "לסגור פינות" שיש לנו כמות אחסון מספקת, וגם שרידות. הבעיה המרכזית: מהירות כתיבת נתונים ושליפתם. אין לנו שום האצה בכתיבת הנתונים, יש לנו האצה בקריאת הנתונים (שזה אידיאלי אולי לארכיבאות לדוגמא). בשביל לקבל האצה פי 4 בכתיבה ופי 8 (בהשוואה לקריאה/כתיבה מדיסק בודד) נצטרך 8 דיסקים של 10 טרהבייט ב-RAID-10. אם אנחנו רוצים מהירות קריאה/כתיבה יותר גבוהה בהרבה (X10 בכתיבה, X20 בקריאה) נצטרך לעבור מדיסקים של 10 טרה לדיסקים של 4 טרה בייט ולרכוש 20 כאלו (תגידו "היי" למארזי 4U). ככל שנבחר דיסקים יותר גדולים, כמות ההאצה שהמערכת תתן – היא יותר קטנה (לדוגמא: 10 דיסקים של 8 טרהבייט יתנו X5 בכתיבה, X10 בקריאה – הדוגמאות הם ב-RAID-10). טעות נפוצה, אגב, היא שימוש ב-RAID-5: הגדרות RAID-5 נותנת אפס האצה בכתיבה לאחסון.
  • לקוחות שהולכים להשתמש בסטורג'. אם מדובר על שרת קבצים לדוגמא, עניין המהירות הוא יחסית די שולי כי כולם משתמשים בתקשורת 1 ג'יגהביט שברוב הזמן מנוצלת חלקית, ואם מישהו יחכה עוד חצי שניה לשמירת קובץ האקסל שלו, השמיים לא יפלו.
    לעומת זאת – מכונות וירטואליות זה סיפור אחר לגמרי. פרוטקול כמו iSCSI הוא פרוטוקול "מפונק" ומערכת כמו VMWare לדוגמא דורשת אישור מהסטורג' על כל קבוצת נתונים שנרשמת, כך שאם אין איזה מנגנון ש"יאמר" ל-VMWare "קיבלתי, מאשר" בכל פעם ובאופן מהיר – המכונות הוירטואליות פשוט יזחלו בכל כתיבה. כיום ברוב פתרונות הסטורג' (סגורים ופתוחים) יש מנגנון שמטפל בכך, אבל אם תרימו מכונת לינוקס עם MDADM ל-RAID, זה לא יתן פתרון (אפשר לעקוף זאת על ידי ביטול ה-sync ב-ZFS לדוגמא, אבל זה מסוכן, במיוחד אם אין UPS למכונה).
    לכן, כשמדובר בסטורג' שיטפל בכל הקשור לאחסון מכונות וירטואליות, חשוב לבדוק שהסטורג' תומך ב-Sync On write, reclaim space, תמיכה ב-VAAI, VVOL ואחרים.
  • חיבור בין הסטורג' למכונות אחרת. הנה נקודה שרבים יתווכחו עליה מתוך איזה נסיון שיש להם, מתוך אמונות, מתוך שמועות, אך כמו שכתבתי למעלה – הנקודות נוסו על ידי הח"מ בתנאי Extreme.
    חיבורי ה-FC היו מעולים לזמנים שהתקשורת נחושת היתה במהירות 1 ג'יגהביט וחיבורי 10 ג'יגהביט היו יקרים מאוד. כיום, לעומת זאת, ישנם 5 אפשרויות פופולריות:

    • CAT6/CAT-6E – חיבורי נחושת של 10 ג'יגהביט, עובדים מעולה ואם רוצים, אפשר לעבוד עם LACP (או Bridge) בצוותים של 2 חיבורים לדוגמא לקבל מהירות יותר גבוהה. היתרון: עלות זולה יותר של כבלים וסוויצ'ים.
    • +SFP עם TwinAx (נקרא גם DAC) – עובד מעולה למרחקים קצרים (עד 5 מטר). חשוב לשים לב שהחיבורים יהיו מאותו מותג של הסוויצ' (בסוויצ'ים 10 ג'יגהביט בקצה הנמוך זה לא רלוונטי, הם מתעלמים מה-Branding Tag).
    • +SFP עם סיבים אופטיים – את זה כולם ימליצו. לא חוכמה 🙂
    • +QSFP – כמו ה-+SFP רק למהירות 40 ג'יגהביט. מדובר בחיבור פיזי גדול יותר כך שהוא אינו תואם אחורה. קיים גם כגירסת DAC/TwinAX וגם כחיבור עצמאי שאליו מחברים סיב אופטי.
  • אחריות, SLA וכו' – כל יצרניות השרתים מוכרות כיום פתרונות סטורג' (ברזלים יעודיים או תוכנה לשימוש בשרתים עצמם) משלהם, אך יחד עם זאת הן גם "מכשירות" (Certified) תוכנות אחרות, ובדרך כלל ביקור באתר יצרן תוכנת הסטורג' יראה את הלוגואים של היצרנים שנתנו "הכשרה" לתוכנת הסטורג', כלומר אם תפנו לתמיכת יצרן השרתים, אף אחד לא יעקם את האף מדוע אתם משתמשים בתוכנת סטורג' X. בחלק מהמקרים (תלוי בחוזה התמיכה) אולי יסייעו לכם עם תוכנת הסטורג' צד ג' או יפנו את בקשת התמיכה ליצרן התוכנה (במקרים בהם יצרן השרתים [כמו HPE] מכר לכם חוזה תמיכה על כל הציוד והתוכנות שברשותכם).
  • SSD, Caching: בכל סטורג' המשלב דיסקים מכניים ודיסקים SSD – המערכת תורכב מ"שכבות" (או במושג המקצועי: Tiering), כאשר השכבה המהירה מורכבת מהדיסקים SSD והשכבה האיטית יותר מדיסקים מכניים (SAS או SATA). ישנם כמובן סוגי סטורג' שונים שבהם יש עוד שכבות כמו מדף זכרון מגובה סוללות, NVRAM, או שכבות של דיסקים מכניים מהירים ובשכבה מתחת דיסקים SATA במהירות 7200 RPM.
    בכל המקרים הללו, ה-SSD נועד "להחביא" את הדברים הקשורים לכתיבה. הוא מקבל את ה-DATA ולאחר מכן ה-DATA מופץ לשכבות היותר איטיות, והוא גם מאחסן נתונים שנקראים תדיר (נניח יש לך 10 מכונות לינוקס, כולן רפליקציות מלאות או משורשרות – רוב הסיכויים שה-DATA יקרא מה-SSD). ה-DATA עצמו לא נכתב ישר אל הדיסקים המכניים, אבל הסטורג' מציג את הדברים כאלו שהנתונים כן נכתבו למכניים, והסטורג' ברקע עושה זאת.
    במערכות יקרות יותר (מילת קסם: AFA או All Flash Array) ישנם גם שכבות אם כי טיפה שונות: רוב הדיסקים הם Read Intense וחלק קטן מהם Write Intense או Mixed Intense ולפעמים יש שימוש ב-NVRAM או בזכרון מגובה סוללה (נדיר). במערכות הסופר-סופר-יקרות, מכניסים גם Optane, גם כרטיסי FPGA ודברים נוספים כדי להאיץ את הכל (ועוברים בדרך לפרוטוקול ה-RDMA הוותיק) – כמו במערכות NVMEoF לדוגמא.
  • פתרונות של Synology או QNAP: אלו פתרונות שאני יכול להמליץ עליהם בלב שלם כפתרונות לשמירה/קריאה של מידע, פחות למכונות וירטואליות (אם כי ל-LAB קטן הם בהחלט יכולים להספיק). כיום בכל QNAP או Synology ניתן להוסיף דיסק SSD לקבלת Cache בסיסי, אבל אל תנסו להכניס לשם SSD מסוג Optane  לדוגמא (כמו שינוי QD) – בשביל זה יש צורך לשנות כמה וכמה דברים בלינוקס ואין במכשירים הללו לא את הספריות ולא את האפשרויות לשנות פרמטרים.
  • הרחבת אחסון, זכרון: בכל מה שקשור לזכרון, רוב הסטורג'ים שמבוססים לינוקס/BSD/סולאריס ו/או ZFS ישתמשו בזכרון כ"מאיץ ראשי" לקבלת הנתונים ולשחרר את צוואר הבקבוק, כך שאם אתם יכולים להשקיע ברכישת RAM – מה טוב.
    לגבי הרחבת האחסון עצמו: בסטורג' סגור הפתרון תמיד יגיע עם "מדפים" לאחסון הדיסקים. בסטורג' פתוח לעומת זאת, חשוב לבדוק שיש חיבור מאחורה המאפשר לחבר JBOD אחד או יותר על מנת להוסיף קופסת JBOD או יותר עם דיסקים ומומלץ לבדוק שהחיבור הוא SAS-3 (נקרא גם HD MINI-SAS או בשמו המקצועי: SFF-8644). לפני שנתיים שוחרר סטנדרט שנקרא SAS-24G אך אני לא ממליץ לרכוש אותו הואיל ודיסקים קשיחים עתידיים (כמו אלו עם 2 מנועים שאמורים לצאת בשנה הקרובה/שנה הבאה) עוברים להשתמש בחיבור NVME. ה-24G פיספס את הרכבת.

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

יותר ליבות בפחות כסף

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

וכך יצא מצב שרוב החברות בארץ קונות שרתים כשכמות הליבות הרצויה מבחינתם – מחולקת ל-2. רוצים 16 ליבות? שלמו על 2 מעבדים של 8 ליבות, לדוגמא. אינטל הרוויחה מזה יפה מאוד.

ואז AMD הוציאה את EPYC עם הצעה מאוד מפתה (שרבים לא מודעים לה): קנה שרתים מהיצרנים מוכרים עם המעבדים שלנו, ותחסוך 40-60% בהשוואה למעבד עם כמות זהה של ליבות – של אינטל. אבל כאן זה לא נגמר: AMD הוציאה במקביל משפחה נוספת של מעבדים לשרתים עם האות P – ועם מעבדים אלו אתה משלם מחצית בהשוואה למעבד זהה ללא האות P.

אז אם לדוגמא אתם רוצים לרכוש מעבד Xeon Scalable 8180 עם 28 ליבות (מחיר – $17600 בשוק), מעבד EPYC 7551P עם 32 ליבות – עולה 2232$. אמרתי רבע מחיר? זה יותר כמו תשיעית מהמחיר. המחירים כמובן שונים כשקונים את השרת עם כל החלקים כבר מורכבים מיצרן השרתים המועדף עליכם, אבל עדיין – יש הבדל ניכר במחיר גם שם.

ההבדל בין השתיים? מעבד עם האות P יכול לעבוד כמעבד יחיד בלבד, גם אם תכניס אותו ללוח אם עם 2 תושבות למעבדים. בניגוד לאינטל, עם מעבד EPYC אתה מקבל גישה לכל המשאבים גם עם מעבד יחיד.

ב-HPE לדוגמא בנו שרת, ה-DL 325 Gen 10 מבוסס מעבד יחיד, ויש להם כמה דברים לאמר בנידון:

תנחשו מי מאוד התלהב מהרעיון? המתחרים. אינטל.

אינטל תוציא בקרוב 3 מעבדים חדשים בסידרת ה-Cascade Lake שלהם, וכמו ש-AMD השתמשה באות P לבדל את המעבדים, אינטל תשתמש באות U. בשאר הדברים אינטל די העתיקה את AMD – רוצה לדוגמא שרת עם 20 ליבות סה"כ? רכוש את ה-Xeon Gold 6210U, תקבל 20 ליבות במחצית המחיר בהשוואה ל-2 מעבדים של 10 ליבות כל אחד. המעבדים הנוספים שיהיו הם: Gold 6212U (עם 24 ליבות) ו-Gold 6209U עם 20 ליבות במהירות נמוכה ב-400 מגהרץ בהשוואה ל-Gold 6210U.

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

לסיכום: כבר בקרוב יהיה ניתן לחסוך במחיר עלות שרתים אם תבחרו במעבדי סידרת U, אם אתם מתעקשים לעבוד עם המעבדים של אינטל. אני מאמין שאינטל תוציא עוד דגמי U שמתאימים יותר לאלו שמעוניינים בכמות של 8 או 16 ליבות (כמות כוללת).

מתי כדאי לרכוש את ה-Optane SSD של אינטל?

כל איש IT שמבין משהו בדיסקים, מכיר בוודאי את הכלל הפשוט הבא: דיסקים מכניים מיועדים  לאחסון גדול, דיסקים SSD מיועדים לביצועים. שילוב של השניים נותן בעצם ביצועים די טובים, והקונפיגרציה הזו "מאיצה" את הקריאה/כתיבה לדיסקים. עד כאן הכל טוב ויפה. יצרני ה-SSD כמובן מנסים להתחרות בגיזרת הגודל SSD מול הדיסקים המכניים, אך המחיר שלהם מרתיע. לפני מספר שבועות קיבלתי דיסק SSD מסוג Nytro של Seagate לבדיקה, דיסק SSD בגודל 15.3 טרהבייט. מנמ"ר שקפץ לביקור אליי ראה את הביצועים והתרשם (לעניות דעתי הביצועים אינם משהו הואיל וזה דיסק שמתחבר ב-SAS ולא U.2) – אך כשהראתי לו את המחיר של הדיסק (6,500 דולר – בחו"ל) – ההתלהבות ירדה במהירות.

כל פתרון אחסון, בין אם מדובר באחסון סגור או אחסון בניה עצמית – עובד פחות או יותר באותה שיטה של "פירמידה" – מהאמצעי הכי מהיר לאמצעי הכי איטי: זכרון RAM כ-Cache ראשוני (או במקרים של אחסון קנייני כמו EMC לדוגמא – NVRAM), מתחתיו SSD שבנויים משבבי NAND SLC או MLC, ובשכבה האחרונה – הדיסקים המכניים. כל שלב ב"פירמידה" מאיץ בעצם את החלק מתחתיו (כשמסתכלים מלמעלה כלפי מטה).

הפירמידה הזו בשנתיים האחרונות "התרחבה" מעט כשאינטל וסמסונג הוציאו את ה-SSD שלהם (Optane בדגמים שציינתי לעיל) שמיועדים יותר ל-Cache. אינטל הוציאה את ה-900/905P לשוק הסמי-מקצועי ואת ה-DC P4800X לשוק ה-Enterprise ואילו סמסונג הוציאה 2 דגמים תחת המותג Z-NAND. הפתרונות הללו יושבים בין ה-RAM (או ה-NVRAM) של פתרון האחסון, לבין ה-SSD מכיוון שהם הרבה יותר מהירים מ-SSD אך אינם מגיעים למהירות של RAM. היתרון ב-Optane בדגמים לעיל הוא שהאחסון מתאים לרוב העומסים של Enterprise או בשימוש מקצועי (תיכף ארחיב), ואילו היתרון של Z-NAND מגיע כשצריכים מידע במהירות מאוד גבוהה (מ-100 ג'יגהביט ומעלה) או ב-Queue Depth מעל 128.

נשאלת השאלה: האם כדאי לרכוש בעצם את ה-Optane DC לצורך סטורג' כתחליף ל-SSD שרוכשים לשרתים (Read Intense/Mixed Intense/Write Intense)?

כדי להחליט אם לרכוש, צריכים להכיר את הטכנולוגיה. ה-Optane DC (ומשפחת ה-900) אינם מכילים שבבי NAND כמו כל דיסק SSD אחר. הם מכילים שבבי אחסון אחרים שאינטל מתעקשת לא לגלות מה יש בתוכם ואינטל קוראת להם 3D XPoint. ב-SSD הללו כל הכללים של SSD רגיל עפים מהחלון. אין צורך ב-Over Provisioning, אין צורך ב-TRIM, ב-SSD אין זכרון שמשמש כ-Cache עד שה-DATA יכתב לשבבים, ומבחינת DWPD (כלומר כמות הפעמים שמותר לכתוב על כל הדיסק ביום) – אינטל מציינת את המספר כ-30 בגירסת ה-P4800X (אני קיבלתי דיסק כזה ל-Torture testing וגם אחרי שכתבתי על כולו 50 פעם בחצי יום – הוא עדיין עבד מעולה. הצעקות שקיבלתי מהנציג באינטל – זה סיפור אחר 🙂 ). מבחינת ביצועי קריאה כתיבה – הוא עוקף את כל מה שיש בשוק (למעט ב-Queue Depth סופר גבוה – שם Z-NAND עוקף אותו). ככלל – היתרון הגדול של Optane DC זה ה-Latency המאוד נמוך שלו בהשוואה למתחרים.

הבעיה המרכזית קשורה למחיר מול ביצועים. שאל את עצמך – האם חברתכם מוכנה לשלם 3000$ על דיסק בודד בגודל 750 ג'יגהבייט? נניח שאנחנו מקימים מערכת וירטואליזציה מבוססת HCI עם VSAN. אנחנו צריכים לכל הפחות 3 דיסקים – 2 איטיים והשלישי מהיר. נאמר ש-2 ה"איטיים" יהיו SSD מבוססי Read Intense והמהיר יהיה Optane DC. יוצא מכך שרק על השלישיה הזו נוציא כמעט 4000$. לא דיברנו על רשיונות, על החומרה הנוספת בשרת, על דיסקים נוספים וכו'. מישהו שפוי ירצה לשלם מחיר כזה?

אישית, כשאני מקים פתרון סטורג' עבור לקוח – אחד הדרישות הראשונות שלי זה דיסק Optane 900P (ואם זה ל-Enterprise – אז DC P4800X) בגלל ה-Latency הנמוך. דיסק כזה משמש אותי אך ורק ל-Caching כשאני צריך לכתוב/לקרוא נתונים ממכונות/אל מכונות אחרות, כאשר החיבוריות היא לפחות 10 ג'יגהביט. במקומות אחרים, כשיש צורך ב-DB לפרודקשן שאמור לתת ביצועים מאוד גבוהים – אותו Optane DC מתאים כ-Cache בלבד, במיוחד אם מדובר ב-In memory Database, ואפילו שרת MySQL/MariaDB יכול לתת ביצועים גבוהים בהרבה בהשוואה לדיסקים SSD אחרים, אבל במקומות אחרים ה-Optane לא יתן לי הרבה בהשוואה למתחרים ופשוט לא יהיה שווה את הכסף.

אם כן חושבים לרכוש את הציוד הזה, חשוב לזכור איזו גירסה לרכוש מיצרן השרתים: AIC (מדובר בכרטיס PCIe) או U.2 (שנכנס מקדימה). בשרתים מודרניים כמו R740, DL380 וכו' לא מומלץ לרכוש מספר דיסקים כאלו להכנסה מקדימה, הואיל והקירור/איוורור אינו מספק (כן, ה-Optane דורש יותר, לכן הוא בין היחידים שכוללים צלעות קירור, לא שזה עוזר הרבה..), ועדיף לרכוש את גירסת ה-AIC. אגב, ה-Endurance של זה כזה גבוה שלעניות דעתי RAID מיותר. אתם לא תקבלו מהירות קריאה כפולה/מהירות כתיבה כפולה (בשביל זה תצטרכו לעשות Overclock לזכרון ולמעבד – דבר בלתי אפשרי במעבדי Xeon).

לסיכום: Optane 900p/DC P4800X הם דיסקים SSD בתצורה שונה, חיה אחרת שהכללים הרגילים שחלים על SSD לא חלים עליהם. הם נותנים ביצועים מטורפים, אך יחד עם זאת, הדיסקים הללו לא בנויים להחליף אחסון של SSD רגיל/מעורב. הם יותר מתאימים ל-Cache או כל דבר אחר שצריך Latency מאוד נמוך, כך שהם מתאימים רק לצרכים ספציפיים. אם יש לך צרכים כאלו, אז הדיסקים הללו יכולים לשמש כפתרון מעולה.

על VDI ולקוחות שונים

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

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

בהינתן החומרה הנכונה וההגדרות הנכונות, כל הפתרונות יכולים לתת תוצאות מעולות בכל מה שקשור ל-VDI, החל מרמת הפקידה שמשתמשת באופיס ודפדפן וכלה במשתמשים שצריכים להריץ אפליקציות תלת מימד. כולם תומכים בהאצת GPU (למעט מיקרוסופט שירדה מ-RemoteFX ב-Windows Server 2016 והולכת להוציא משהו בקרוב שיקרא GPU-P לצרכים של גרפיקה למשתמש מרוחק).

כל החברות הגדולות במשק משתמשות כבר בפתרון VDI או "מעין VDI". לכו לכל נציגות סלולרית בקניון ואתם תוכלו לראות במסכים של המוכרים חיבור RDP לחוות השרתים של אותה חברת סלולר. על המחשב המקומי לא רץ כמעט כלום (אגב, בלא מעט מקרים אותן חברות גדולות מוותרות על רכישת Thin Client יעודי מכיוון שזה יותר זול להן לרכוש PC בקצה המאוד נמוך עם Windows). רוב המשרדים הממשלתיים, חברת החשמל וכו' משתמשים ב-Citrix לצרכי VDI. חברות גדולות אחרות שלא ממש משתמשות ב-VDI הן חברות השיווק הגדולות (שופרסל, רמי לוי וכו') בקופות הרושמות (כולל הקופות החדשות לשרות עצמי) – שם עדיין יש PC עם דיסק קשיח שמטעין שורת אפליקציות לאחר שה-Windows עולה. אחד הדברים שגיליתי לאחרונה זה שכשבמשרד ממשלתי (נניח רשות המסים) אם ה-Thin Client שלהם (שמשום מה מטעין Windows 10 בזמן Boot, כך שאני לא בדיוק יודע למה הם צריכים Thin Client) לא מצליח להתחבר ל-Store Front של Citrix וזה קורה לכולם באותו סניף – אז הם פשוט מפסיקים לקבל לקוחות ובאותו יום אין עבודה. ברשת שיווק שמרוויחה כסף מכל לקוח, סיטואציה כזו היא הסיוט הכי שחור להנהלה, ולכן לא נראה לי שבעתיד הקרוב הם יעברו למשהו כמו VDI.

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

מדוע שהם בעצם ירכשו? בגלל ש-PC יכול להתקלקל? כיום אפשר ב-500-700$ להשיג PC פשוט בקצה הנמוך (כולל זכרון ו-SSD במקום דיסק מכני), וכל מה שנותר לעשות זאת להעביר את ה-DATA (כולל OS) ממערכת ישנה לחדשה ואולי להתקין דרייברים. בגלל גיבויים? אפשר לקנות NAS קטן, להתקין תוכנה כמו Macrium Reflect שתגבה את כל המכונות לאותו NAS. העלות של כל העניין ממש שולית.

היכן עסקים קטנים כן ירצו להקשיב ליתרונות VDI ולהטמעתם? רק כשהדברים הבאים ימולאו:

  • מחיר – זול. הפתרונות של Citrix ו-VMWare עפים ישר מהחלון. של מיקרוסופט – אולי.
  • שקט – תתפלאו בכמה משרדים אין ממש בידוד למחסן שאפשר להכניס שם שרת 1U או 2U, ובמשרד די שקט, רעש כזה בולט (יש לי כמה כאלו פה בבית, מנסיון!)
  • שרות ותחזוקה ל-3-5 שנים, בלי זה אין על מה לדבר.
  • עלות חד פעמית – לא רשיונות בתשלום חודשי. (ביי ביי nVidia ו-Grid!)
  • שרות ותמיכה מקומיים ובעברית.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קונטיינרים ומכונות וירטואליות – השילוב הנחוץ

בפוסט הקודם שכתבתי על קונטיינרים ומכונות VM, דיברתי על עניין אבטחת מידע, וכיצד כלי כמו CRI-O יכול להחליף את Docker ובאותו זמן גם מאפשר לנו להריץ קונטיינרים שאיננו בוטחים בהם (Untrusted) בתוך QEMU – מכונה וירטואלית קטנה שמעלה לינוקס קטן ובתוך אותו VM "מולבש" הקונטיינר שלנו, וכך אנחנו נהנים מ-2 העולמות: לא צריכים לבנות את הקונטיינרים מחדש, ומצד שני האבטחה הרבה יותר רצינית.

הפעם נדבר על דבר הפוך וחדש.

סיפור קטן: לפני מס' חודשים ישבתי בישיבה אצל חברה פיננסית גדולה מאוד שכולם מכירים. מטרת הישיבה – שיחה על מעבר עתידי לתצורת עבודה של Devops, שימוש ב-CI/CD, קונטיינרים, מתודות וכו'. בדרך כלל בישיבה כזו אני מבקש לדעת מה הכלים שהם משתמשים כרגע, כמו שרתי אפליקציות, קומפיילרים, מערכות הפעלה וכלים אחרים, ולפי זה ניתן להעריך בהערכה גסה מה יהיה קל להעביר לקונטיינרים ול-Micro Services. במקרה של אותה חברה, מבלי לפרט דברים, היו כמה דברים שלהעביר אותם לקונטיינרים יהיה סיפור סופר-מורכב, ובחלק מהמקרים כנראה שלא אפשרי מכל מיני סיבות שלא אכנס אליהם כדי לא לחשוף פרטים. אלו הדברים שבדרך כלל אני רושם לעצמי בצד לבדוק מה ניתן לעשות עבור הלקוח.

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

כאן נכנס לתמונה כלי חדש של רד-האט שנקרא Kubevirt.

Kubevirt בעקרון עושה משהו הפוך ממה ש-CRI-O עם Kata containers עושה: עם CRI-O אנחנו מריצים קונטיינרים בתוך VM מינימלי, ואילו Kubevirt מריץ מכונה וירטואלית בתוך POD, וכן, אני מדבר על המכונה הוירטואלית המלאה – עם OS ואפליקציות משלה, שמתורגמת ישירות מ-VMWare או מ-OVA.

במילים אחרות – אנחנו נריץ VM כ-קונטיינר! (וכן, נקבל את האבטחה המלאה של ה-VM).

כך ניתן בעצם עם Kubevirt לקחת את אותן מכונות וירטואליות שלא ניתן להמיר לקונטיינרים ולהריץ אותן ישירות בתוך Kubernetes או OpenShift ובדרך להנות מדברים כמו Scaling ועוד תופינים שמערכת Kubernetes/OpenShift נותנת, מבלי שנהיה תקועים עם דברים שאי אפשר להמיר לקונטיינרים. כך לדוגמא אצל אותה חברה פיננסית גדולה, כל מה שאצטרך בעצם לעשות, זה להמיר את ה-VM (ליתר דיוק את הדיסק) ל-Persistent Volume ובקובץ ה-YAML להשתמש ב-PVC על מנת "לחבר" את ה"דיסק") לאותו VM.

יש גם מגבלות נכון לגירסה הנוכחית כמו:

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

רד-האט, מפתחת Kubevirt, פרסמה לאחרונה פוסט בנושא.

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

למעוניינים, באתר Kubevirt יש מספר דוגמאות איך ניתן להשתמש בכלי הן עם Minikube, הן בתוך Cluster של Kubernetes, הן בתוך AWS, והן בתוך GCP.

לסיכום: Kubevirt נותן סוף סוף את האפשרות לחברות לקחת מכונות וירטואליות ולהעביר אותן לעבוד יחד עם Kubernetes או OpenShift. אינני מדבר על ההעברה של כל תשתית הוירטואליזציה ל-Kubernetes (אני לא מוצא יתרון בהעברת מכונת SAP), אלא לדברים שאנחנו צריכים כחלק מעבודות מתודת Devops, CI/CD וכו'. במקרים שקשה או לא ניתן להעביר מכונות וירטואליות לפורמט קונטיינרים, הרבה יותר קל להעביר מכונה וירטואלית מפורמט VMware לפורמט KVM ולהריץ את אותה מכונה וירטואלית כמו שהיא – כקונטיינר.

הערה: הכלי נמצא במצב Preview והוא עדיין בפיתוח.