VMWare – עמוד 2 – הבלוג של חץ ביז

תכירו: 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.

שינוי רישוי JAVA SE

חברת אורקל רכשה את חברת SUN לפני מס' שנים ובעקבות הרכישה, פלטפורמת JAVA עברה לידי חברת אורקל. עד לשנה שעברה, הרישוי של חברת אורקל לגבי JAVA SE ומעלה (JAVA EE) היה די ברור וחברות רבות פשוט העדיפו לעבוד עם Java SE (כלומר: Java Stanadrd Edition) לפיתוח ולהתקין את ה-JRE (כלומר Java Runtime Edition) בשרתים, דסקטופים שצריכים זאת וכו'. מי שרצה להשתמש ב-JAVA הרשמי ב-Embedded היה צריך (ועדיין צריך) לשלם את המחיר המלא.

החל מהשנה, חברת אורקל שינתה את הרשיונות של JAVA (ואפשר לקרוא את ה-FAQ שלהם כאן). לאלו שרוצים לחסוך את הקריאה, אקצר את הדברים: כל עוד אתם צריכים את ה-JDK או ה-JRE מגירסה 8 ומעלה לשימוש שאינו מסחרי (כמו בבית), לאורקל אין שום בעיה איתכם ואתם יכולים להוריד ולהשתמש. אם לעומת זאת אתם חברה, או שהרמתם אתר מסחרי – אורקל רוצה מכם כסף, וכן, גם על JRE הם דורשים כסף.

כמה כסף? אם מדובר במכונת דסקטופ (צריך עדיין JRE לדוגמא כדי לנהל שרתים ישנים עם iLO-3 או iDrac) – תצטרכו לשלם מחיר של 2.5$ לחודש. אם אתם צריכים להתקין על שרתים, אז אתם צריכים לשלם על כל הליבות שיש בשרת, בהתאם לליבות הפיזיות שיש בשרת, לפי הטבלה הזו. כלומר אם יש לדוגמא יש לכם שרת שבו יש שני מעבדי Xeon כשלכל אחד מהם יש 8 ליבות, אז סך הכל יש בשרת 16 ליבות, וה-Core Factor הוא 0.5. נכפיל במחיר הרשמי של 25$ לחודש, ונראה שאנחנו צריכים לשלם על כל שרת כזה 200$ לחודש. נקודה שחשוב לציין: אם אתם משתמשים בוירטואליזציה שאינה Oracle VM (כמו VMWare) ואם הקמתם בשרת הזה רק מכונת VM אחת עם 4 ליבות וירטואליות שמשתמשת ב-JAVA, אתם עדיין צריכים לשלם על כל הליבות שבשרת. (אם הבנתי זאת נכון, צרו קשר עם נציג המכירות של אורקל כדי להיות בטוחים). אם אתם רוצים את קבצי ה-MSI, אגב, אתם נכללים בקטגוריה המסחרית ותצטרכו לשלם את מה שציינתי לעיל, כל חודש.

מכיוון שחברות רבות, כולל בנקים, ביטוח, טלקום ושאר חברות שמשתמשות ב-JAVA ואינן ששות לשלם (כן, גם חברות עשירות לא ממש אוהבות שפתאום מחייבים אותן ברשיונות חודשיים) – עולה תהיה מה ניתן לעשות בנידון, חוץ מאשר לשלם.

הפתרון הוא OpenJDK.

OpenJDK הוא מימוש קוד פתוח (שאורקל גם משתתפת בו) של ה-JDK בגירסת ה-Standard Edtition (אין גירסת OpenJDK ל-Enterprise Edition – זהו מוצר נפרד של אורקל שאין לו מתחרה בקוד פתוח) וברוב המקרים הוא משוחרר בסמיכות לגירסת JDK/JRE המסחרית שאורקל משחררת. אפשר לקרוא על ההבדלים כאן. בעקרון, לא אמור להיות הבדל בין גירסת OpenJDK לגירסת SE, רק שחשוב לציין – OpenJDK משוחרר תחת רשיון GPL, וכל שינוי שנעשה ב-JDK – יש לשחרר בחזרה לציבור.

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

אם בחרתם להשתמש ב-OpenJDK, כדאי מאוד לבדוק פנימית אם האפליקציות שלכם רצים ומגיבים כמו ה-JDK/JRE הרשמי של אורקל. הדברים אמורים לעבוד בדיוק אותו דבר למעט שימוש בכל מיני Applets להשתלטות מרחוק על ציוד ישן (שרתים) – שם יש לא מעט מקרים שמקשים לא עובדים טוב (במיוחד קיצורי מקשים). אתם יכולים לנסות להשתמש ב-OpenJDK כדי לבדוק אם יש תאימות, בכך שתתקינו את החלק שנקרא IcedTea (כן, שם "מתחרה" ל-Hotspot) וכדאי לשים לב למגבלות שלו.

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

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

למי מתאים OpenStack?

"היי חץ, אנחנו שוקלים מעבר מפלטפורמת VMWare למשהו אחר, עדיף יותר זול. האם OpenStack יכול להתאים לנו?"

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

אז כ-שרות לקוראי בלוג זה אתאר מספר נקודות פשוטות, ואת ההצעה שלי בסוף.

נניח ויש לכם מערכת VMWare ואתם צריכים לבצע את אחד (או יותר) מהדברים הבאים:

הקמת והגדרת Cluster
ביצוע Live Migration למספר מכונות VM בין Clusters
ביצוע Live Migration בין 2 Datastores
הגדרות Fault Tolerance

איך אתם תבצעו את הדברים?

דרך ה-Vcenter web client (הממשק הוובי) או ה-vcenter client שרץ על מכונת Windows
דרך PowerShell או דרך סקריפטים שכתבתם בפייתון או בשפה אחרת

התוצאות:

אם אתם משתמשים אך ורק בכלי ה-GUI/WEB ש-VMWare מספקת – תרדו מהמחשבה על מעבר ל-OpenStack.
אם אתם "פוחדים"/מתעצלים/לא מעוניינים להשתמש ב-API או לכתוב סקריפטים לאוטומציה או שימוש On Demand במקרה הצורך – רדו מ-OpenStack.

בקיצור – אם אתם הטיפוסים של "קליק קליק קליק" – OpenStack לחלוטין אינו מתאים לכם.

ברכותיי, חסכתם כמה מאות שקלים של דמי יעוץ 🙂

אחד הדברים שבגינם אני כותב את הפוסט הזה, זו המחשבה המוטעית ש-OpenStack הוא איזה פתרון CSN (כלומר Compute, Storage, Network) שמהווה תחליף ל-VMware. מבחינה טכנית "על הנייר" – הוא מסוגל בהחלט לתת שרותי CSN, אבל לא בשביל זה קונים ומטמיעים את OpenStack, כמו שלא מקימים מערכת Kubernetes בשביל להריץ 2-3 קונטיינרים.

הדברים שצריך להבין לגבי ה-OpenStack ומדוע הוא ה"דארלינג" של כל עסק HyperScale (כלומר עסק גדול שנותן שרותי ענן – כמו רוב חברות התקשורת הגדולות בחו"ל – AT&T, Verizon, SK-Telecom ועוד רבים אחרים) הם דברים מהותיים כמו:

OpenStack מאפשר לך להקים שרותים כמו Object ו-Block storage מצד אחד, אבל מצד שני, OpenStack יכול להתחבר בקלות לסטורג' שלך ולקבל את השרותים מהסטורג', וכל יצרני הסטורג' הגדולים (והיקרים) תומכים ב-OpenStack. שלח מייל ליצרן הסטורג' שרכשתם ותקבל בחזרה קובץ PDF או קישור איך לחבר ביניהם, כך ש-OpenStack לא מנסה להתחרות ביצרניות האחרות, אבל מצד שני אם אין לך את המשאבים/תקציב – הוא מאפשר לך להקים פתרון.
אותו דבר מבחינת שרותי וירטואליזציה – אתה יכול להשתמש בשרותי ה-KVM של OpenStack או לחבר את ה-vSphere אל ה-OpenStack כך שמערכות ESXI יריצו את המכונות הוירטואליות. הנה התיעוד.
מבחינת רשתות (סיבה עיקרית שחברות הטלקום אוהבות אותו) ה-NFV (כלומר Network Functions Virtualized) של OpenStack מאפשר להתרחב למימדים מפלצתיים! גם כאן, אפשר או להקים או פשוט לפנות ליצרן ציוד התקשורת שלך שכבר תומך מספר שנים ב-OpenStack (כן, כל הגדולים תומכים).
שרותים, שרותים, שרותים: OpenStack התחילה את חייה כמערכת IAAS קלאסית, אבל כיום OpenStack מציעה מאות שרותים שאתה יכול לשלב ל-OpenStack ולתת/למכור את השרותים הללו ללקוחות. הלקוח רוצה שרותי ניהול DNS? אולי DB? להריץ קונטיינרים ב-Kubernetes או OpenShift? ניהול, הקמת והגדרות ברזלים (Provisioning)? שרותי Identity? שרותי Telemetry ועוד? יש, רק תגדיר במערכת ותתחיל להשתמש ולהציע ללקוחות – ולמנמר"ים שכמובן חושבים על תקציבים ותשלומים בראש ובראשונה – אני רוצה להכיר לכם את … CloudKitty.

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

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

ה"חסרון" של OpenStack – הוא שמדובר במערכת שאינה "קליק קליק קליק". כן, יש ממשק Web אך הוא יחסית די בסיסי (במיוחד אם מנסים להשוות אותו לממשקים כמו של VMWare) ורוב העבודה נעשית מול API או binding עם שפות כמו Python. זו מערכת מסובכת, מורכבת, אבל לאחרונה (בגירסת Stein) קיימת תת-מערכת חדשה, AirShip שמאפשרת הקמה והגדרת דברים בצורה קצת יותר קלה – עם YAML (אגב, למי שרוצה לשחק עם Airship על מכונת לינוקס, אפשר להריץ את הפקודות כאן ולהתרשם בעצמכם).

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

קליפים על הקמה/שימוש ב-OpenStack – בקרוב.

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

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

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

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

על לינוקס, VMWare וטעות הקשורה לחיישנים

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

עד לגירסה 5 (גם 5.5) ב-VMware השתמשו בד"כ בדרייברים מבוססי לינוקס כדי להפעיל ציודים, בין אם מדובר בציוד זול או בבקרים יקרים מאוד. בגירסה 6 החליטו ב-VMWare לעבור לדרייברים שהם כותבים (או שהיצרן כותב) עם שינויים מהותיים בקוד כך שלא כל כך קל לקחת דרייבר של לינוקס ולזרוק אותו לגירסה 6 (ולפי השמועות, זה הולך להשתנות שוב בגירסה 7, אבל בינתיים אלו רק שמועות).

אם יש לכם שרתים שמריצים VMWare, אחד הדברים החשובים שתרצו לדעת הוא מה מצב החיישנים במערכת. מה הטמפרטורה של המעבד, דיסקים, ספק כח, חום פנימי בשרת, מצב תקלות זכרון ודברים כאלו ואכן, עד גירסה 6 של vCenter קיבלתם את המידע כולו בתצורת עץ. המידע הזה חשוב (וגם ניתן לקריאה על ידי תוכנת הניטור שלכם דרך SNMP). עד גירסה 6 ה-vCenter עשה משהו פשוט מאוד: הוא פנה לכל שרת ESXi שרשום ב-vCenter וקרא ממנו את הערכים. איך ESXi קורא את הערכים? בעזרת חבילה שכלולה בכל הפצת לינוקס שנקראת lm-sesors והיא קיימת בכל התקנה של שרת ESXi. החבילה הזו מעודכנת כל הזמן וכל עוד הקרנל בלינוקס מעודכן, תוכל לקרוא את כל החיישנים במערכת, וזה רץ על כל מערכת, בין אם מדובר במחשב נייד, בדסקטופ, תחנת עבודה או שרת מפלצתי.

בגירסה 6.5 ל-VMware "קפץ הפיוז" והם החליטו שה-vCenter (בין בגירסת Windows או VCSA) לא יקרא יותר את החיישנים מה-ESXi (שכבר יש לו את הנתונים שמתעדכנים כל 90 שניות), אלא יפנה אל ה-IPMI. למי שלא מכיר – בכל לוח אם של שרת יש רכיבים שנותנים ניהול מרחוק, אתם אולי מכירים את זה בשמות כמו ILO, IMM, iDRAC – וכולם בעצם מממשים פחות או יותר את סטנדרט IPMI לשליטה מרחוק על המכונה. הבעיה, כמו תמיד, שיש לא מעט מקרים שהמימושים הם לא ממש משהו או שהיצרן החליט להתעלם מחלק מסטנדרט ה-IPMI. אחרי הכל, למשתמש יש גישת CLI או גישת Web לניהול מרחוק, אז אפשר להחביא את המימוש העקום מתחת לשטיח.

וזה משהו שב-VMWare לא ממש התעמקו כנראה. מבחינתם, החל מגירסה 6.5, יש שרות שנקרא wbem ויש API לפונקציה שנקראת HostConfigManager.healthStatusSystem והיצרן צריך לכלול (או לשחרר) VIB שכולל את הגישה לניהול מרחוק של השרת, כך שבתאוריה המנהל יצטרך רק להכניס פרטי התחברות ל-IMM/IDRAC/ILO והמערכת תתחיל לקרוא את החיישנים ישירות מהניהול הרחוק.

במציאות .. זה לא ממש עובד. כך לדוגמא אחד השרתים שלי (גם אחרי התקנת ה-VIB) מראה תצוגה של החיישנים בכל שרת (לחצו להגדלה):

איפה כל הטמפרטורות? הציודים? אה, ב-VMWare החליטו לצמצם את הרשימה רק לכאלו שנותנים מידע ב-Status. כמו שאתם רואים, יש פה לא מעט דברים מיותרים אבל גם לא מעט דברים חסרים (וכן, ה-VIB מותקן).

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

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

כמה מילים על VMWare on AWS

(תודה לניצן וייסברג שהעיר את תשומת ליבי לגבי השרות החדש)

בכנס Re:Invent האחרון של אמזון, חברת VMWare הכריזה על שרות חדש בשיתוף אמזון שנקרא VMWare on AWS – שרות שנותן לך להרים SDDC (כלומר Software Defined Data Center). עם שרות זה, הלקוח מקבל מינימום 4 שרתים פיזיים שמותקנים עליהם ESXI יחד עם VSAN ו-NSX וכמובן כל השרותים של vSphere שמגיעים ברשיון Enterprise Plus. הלכתי לקרוא בכמה מקומות על השרות ולהלן התרשמותי:

מבחינת המכונות – אין מה לאמר, מפלצות אחת אחת. בכל מכונה תקבל 36 ליבות (מהמעבדים האחרונים – Xeon-SP של אינטל), 512 ג'יגהבייט זכרון, ו-8 דיסקים SSD NVME (כל אחד בגודל של 2 טרה, כאשר 2 מתוכם משמשים כ-Cache, כך שמבחינת Storage בחישוב כולל, יש לך בערך 20 טרהבייט, לפי הדף באתר של אמזון) והרשת היא ברוחב פס רציני של 25 ג'יגהביט. אין מה לאמר – הלוואי על כולנו!

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

איך נאמר בפרסומת: סבבה אגוזים!

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

הכל טוב ויפה, עד שמגיעים … למחיר, וכפי שאתם יכולים להסתכל על מפרט הברזלים לעיל – זול זה לא הולך להיות!

המחיר מתחיל ב-8.3681 דולר לשעה פר ברזל ומכיוון שצריך מינימום 4 ברזלים (אי אפשר פחות), אז אנחנו מדברים על 33.47 דולר לשעה. נכפיל ב-720 שעות לחודש ונגיע ל-24,100 דולר לחודש, או 289,201 דולר לשנה. המחיר כמובן לא נגמר פה, על כך יש להוסיף מחיר תעבורה מהתשתית של אמזון החוצה (רוצים להתחבר ב-Remote? להוריד VM לארץ? להוריד DATA לארץ? סינכרוניזציה או רפליקציה בין VMים משם לכאן? אז תוסיפו בבקשה, 5 סנט פר ג'יגהבייט) וכרגע אם אתם רוצים Latency נמוך, אתם יכולים לשכוח מזה – בשלב זה השרות זמין בצפון אמריקה בלבד (אלא אם יש לכם קו יעודי לארה"ב, שזה סיפור אחר כמובן).

רוצים הנחה? בשמחה! תתחייבו לשנה מראש, ותשלמו פר הוסט סכום של 51,987 דולר, נכפיל ב-4 וכך נרד למחיר "מציאה" של 208,000 דולר לערך או 437,464 דולר בהתחייבות ל-3 שנים. אין שוטף+30 או 60, זה תשלום מיידי ואין אפשרות לצאת מהמחויבות באמצע התקופה.

אבל בואו נעזוב את המחיר. יש לא מעט חברות גדולות מאוד ששרפו מיליוני דולרים באגפי המחשוב בצעדים תמוהים (אל תאמינו לי, תראו מה קרה עם 600 מיליון שקל וביטוח לאומי) שבשבילם Money is not a object ואין להם בעיה להוציא מאות אלפי דולרים בשנה – האם להם זה שווה?

מבחינה טכנית גרידא, התשובה היא לא רבתי, מהסיבות הבאות:

השרידות היא אשלייתית. באמזון לדוגמא, אם תשתמש בשרות Aurura להקים שרות MySQL, אתה מגדיר שם Availability Zone, כלומר השרות שיוקם עבורך מבוזר על פני שרתים שנמצאים ב-Zones שונים שנמצאים באותו Region, כך שאם Zone נופל (הנה דוגמא) אז Zone אחר תופס פיקוד ואתה אפילו לא מרגיש נפילה. עם השרות החדש הזה – כל השרתים שלך נמצאים באותו Zone, ואם ה-Zone נופל, הכל נופל בתשתית המרוחקת. מעבר לכך, לא ניתן לפרוס את ה-Hosts על פני Regions שונים של אמזון (אם כי ניתן להקים SDDC שונים ב-Regions שונים, אך כרגע רק בצפון אמריקה).
גדילה של Storage היא בעייתית בהשוואה למחיר. זה שתוסיף עוד Host לא תקבל עוד 20 טרה אחסון, אלא סביר להניח שתקבל בערך 5 טרהבייט נטו (הסיבה לכך שעם VSAN, ה-DATA של מכונות ה-VM או DATA שאתה מייצא כ-iSCSI החוצה – מתרפלק בין המכונות כולן, כך שאם מכונה אחת נופלת, ה-Cluster ממשיך לעבוד כי ה-DATA נמצא. אפשר לעשות את החישובים כאן). הדבר המוזר בכל השרות הזה הוא שלא ניתן לחבר EBS מסוג io1 (או כל סוג EBS) כ-Datastore לתשתית.
חייבים 4 מכונות, למרות ש-VSAN יכול לעבוד גם בתצורות של 2 ו-3 מכונות פיזיות.

אבל שוב, אם יש לחברה את התקציבים, יש גם יתרונות:

הקמה של SDDC מלא עם מכונות מאוד חזקות בשעות ספורות במקום לבזבז מס' חודשים על בדיקת הצעות מחיר, ישיבות תקציב, הזמנות, הגעת ציוד, הגדרות והכנה לעבודה.
גדילה של התשתית הרחוקה תוך דקות ספורות. צריך עוד 2 ברזלים? זה יקח מס' דקות והברזלים יהיו מחוברים לתשתית ה-SDDC שלך. Host נפל? לא נורא, תוך דקות תקום מכונה אחרת ואתה יכול לגדול ל-עד 32 מכונות פיזיות (כרגע).
עבודה שקופה – מנהלי תשתית ה-vSphere שלך יכולים להקים מכונות פה או שם (או פה ושם) בצורה מהירה, מבלי להכיר לעומק איך לעבוד עם AWS (למעט החלק הראשוני של הקמת ה-SDDC).
גיבויים – הקץ ל"אין מקום לגבות". עובדים עם Veeam? מעכשיו תוכלו להשתמש באמולציית ה-VTL שלו ולגבות ל-S3 של אמזון. גם זול, גם שרידות סופר גבוהה, וזה תמיד זמין. (כעקרון אפשר לעבוד עם כל תוכנת גיבוי שיודעת לעבוד עם S3).
אחריות ושרות – אתה מקבל ניהול תשתית ומענה לכל בעיה ישירות מ-VMWare.
תשלום פר שימוש – אפשר לנסות את זה לכמה שעות או כמה ימים מבלי להתחייב על כלום ולשלם רק על השעות שניצלת.

לסיכום: אם בחברה שלכם יש תקציבים כמו מים זורמים, ואתם משתמשים בתשתית vSphere, אז בהחלט כדאי להסתכל בהצעה החדשה של אמזון/VMware. אם לעומת זאת כל שרת נרכש אצלכם בדם-ויזע, אז עדיף לוותר על השרות ומבחינה כספית – יהיה יותר זול לרכוש שרתים חזקים + רשיונות ולהכניס אותם ל-Data Center שלכם או באחת החוות של ספקי האינטרנט.

וירטואליזציה והעתיד

עולם הוירטואליזציה ידע ב-30+ שנים האחרונות תהפוכות רבות. זה התחיל ב-IBM עם המיינפריים, המשך למערכות יוניקס השונות עם פתרונות מסוגים שונים (רובם מבוססי חומרה), המשיך בצעדים קטנים בעולם ה-PC (בדסקטופ, לא בשרתים), ובשרתים מודרניים זה התחיל עם "מעין וירטואליזציה" כמו chroot, jails ובסולאריס עם Zones.

עד שהגיעו VMWare שגם הם התחילו בהתחלה בדסקטופ (ה-Workstation, אחרי זה ה-GSX, אחרי זה ESX ולבסוף ESXI) והם "לקחו את הקופה" בכל הקשור להצעת וירטואליזציה מלאה. מה שהיית יכול (בד"כ) להריץ על שרת בודד, אתה יכול להריץ בשרת וירטואלי ללא שינויים. VMware נכנסה לשוק די ריק וכבשה אותו ורק לאחר מספר שנים נכנסה מיקרוסופט עם ה-Hyper-V ולאחריה נכנסו אחרים כמו אורקל עם ה-VM Server שלהם וגם רד האט עם RHEV (כיום זה נקרא RHV), ופתרונות אחרים כמו Proxmox ואחרים.

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

פתרון וירטואליזציה רגיל – ערימת שרתים שכל התוכן נשמר בדיסקים מקומיים.
פתרון וירטואליזציה רגיל – עם NAS או SAN כאשר ה-DATA נשמר על אותו פתרון אחסון.
פתרון וירטואליזציה hyperconvergence – שבו הכל יושב בארון אחד ובלוגיקה מאוחדת – ה-storage, הרשת (נהיית כמעט כולה וירטואלית – SDN ), וה-Compute – כמו פתרונות של Nutanix, או Simplivity או RHV (לשעבר RHEV, בגירסה החדשה 4.2 שתצא בקרוב).
פתרון וירטואליזציה משולב קונטיינרים – מכונות ה-VM משמשות כ-nodes והקונטיינרים רצים בתוך ה-Nodes.
פתרון של קונטיינרים בלבד – ה-Nodes יושבים על מכונות פיזיות (ללא וירטואליזציה) והקונטיינרים רצים על המכונות הפיזיות (פתרון לא מומלץ, הואיל וכך קשה לנטר ולטפל בשרתים).

קונטיינרים נכנסו בסערה לשוק ב-4 שנים האחרונות כאשר Docker הוביל בשוק שהיה עד כה עם פתרון Zones של Solaris ומספר פתרונות לא-ממש-משוייפים בלינוקס כמו LXC והפשוטים כמו chroot ו-jails (שקיים לגרסאות BSD). פתרון הקונטיינרים הראה לעולם מה שמנהלי Solaris ולינוקס ידעו ממזמן – אתה יכול להרים קונטיינר ב-2-3 שניות ולהריץ עליו אפליקציות. הפתרון היה מוגבל, אבל הוא בהחלט הצית את הדמיון ומספר אנשים החלו לעבוד על פתרון משלים בגוגל ולאחר זמן מה גוגל החליטו להוציא את הפתרון שלהם שמשתלב עם Docker ונקרא Kubernetes (או בקיצור: K8S ובתרגום השם מיוונית: טייס – pilot) ו-K8S נותן לך פתרון כמעט מלא לקונטיינרים – החל בשרידות, גדילה דינמית, בדיקת "בריאות" קונטיינרים, תקשורת ביניהם (באמצעות תוסף צד ג' – יש מספר פתרונות מובילים) ועוד ועוד.

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

זה המצב כרגע בשוק.

ומה העתיד צופה לנו?

מי שנמצא בתחום המחשבים עשרות שנים יכול בוודאי לראות שפתרונות ישנים תמיד עושים "סיבוב" נוסף וחוזרים כפתרונות מודרניים. קחו Mainframe מלפני 30+ שנה, דברים עתיקים כמו System/360 של IBM ונוכל לראות שם ש-IBM הריצו מערכות נפרדות כ… קונטיינרים, בשמות אחרים, במושגים שונים, אבל במבט על – אפשר להשוות זאת לקונטיינרים והנה כיום השוק חוזר ל.. קונטיינרים. אותו דבר בוירטואליזציה (גם שם ל-IBM יש הרבה קרדיט ו.. אלפי פטנטים. אם IBM היתה רוצה להתנהג כמו שמיקרוסופט התנהגה בשנות ה-90 – הייתם משלמים היום הרבה הרבה יותר על פתרונות וירוטאליזציה וקונטיינרים).

לעניות דעתי, הדבר הבא שיכנס – יהיו הקונטיינרים VC (לא, אני לא מדבר על vCenter שבין כה הולך למות לטובת VCSA לשמחתי). מה זה קונטיינרים VC? התשובה לכך היא Virtualized Containers ויש מספר חברות (הכי גדולה היא אינטל עם ה-Clear Containers) שיציעו זאת.

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

כאן נכנסים ה-VC. ה-Virtualized Containers הם בעצם מכונות וירטואליות לכל דבר ועניין שיריצו את האפליקציה שלכם, רק שהם בנוים בצורה אחרת. לדוגמא עניין ה-BIOS ותצורת ה-PC הקלאסית – הועפו החוצה ודברים רבים שונו כך שה-VC לא יצרכו משאבים כמו VM רגיל, אבל מצד שני תקבל את ההגנות של וירטואליזציה כך שגם אם יש לך root ל-host עצמו, זה לא אומר שתוכל לראות תהליכים רצים (תוכל לראות מכונות וירטואליות שרצות אבל די קל גם להגן עליהן עם פתרונות הצפנה, שימוש ב-HSM וכו' וכו').

אפשר לקבל מעט יותר פרטים על כך ב-Kata Containers , הגירסה הבאה של OpenStack כאן שתתמוך בפתרון VC, ואני משער ש-Kubernetes יתמכו בהמשך גם ב-VC של חברות אחרות ושל אינטל.

ומה עם הפתרונות של VMware? ל-VMWare כיום יש את vSphere integrated containers אבל אני מאמין שב-vSphere 7 הפתרון יהיה שונה, וגם ב-VMWare יבינו שרעיון ה-VC הוא רעיון לא רע בכלל להטמעה ושימוש, ומכיוון שב-VMWare יש צוות ענק של אנשי לינוקס, הם יכינו פתרון כזה (הימור שלי: פתרון ה-VC שלהם יתאם ללינוקס, לא ממש ל-Windows, לפחות לא בגירסה הראשונה) כך שתוכל להרים לך קונטיינר או VM, וזה לא ישנה הרבה, והפתרון יכלול גם Scale Out דינמי. (אין לי NDA מול VMWare וידע פנימי רשמי מה שקורה שם ולכן אני מסייג את הדברים, אלו רק שמועות ששמעתי).

עוד תחום שלדעתי יקבל יותר ויותר מקום (אך הדבר יקח זמן עקב שמרנות של חברות) הם מעבדי ARM. חברות כמו Qualcomm, Cavium ואחרות מתחילות להוציא מעבדי ARM V8-A עם 16/32/64 ליבות, מיקרוסופט עובדת ותשחרר בקרוב Windows 2016 לשרתי ARM ויש שמועות שגם ב-VMware וחברות אחרות עובדים על כך (הפצות לינוקס לשרתי ARM כבר קיימים כיום (גירסת SuSE קיימת כאן, וכאן ההכרזה של רד-האט, וכאן של Ubuntu). הרעיון עצמו הוא פשוט: בשרתים כאלו יש לך עשרות ליבות ואתה לא צריך לשלם 10000$ על מעבד כזה, והליבות הללו יכולות להריץ דברים קטנים ביעילות מופלאה. קונטיינרים הם (יחסית) קטנים, אז למה שלא תריץ את הקונטיינרים שלך על מעבדי ARM? צריך ברזלים? HPE הכריזו על כמה דגמים, DELL ו-Lenovo ממלאים את פיהם מים כרגע, אבל בוודאות אני יכול לאמר לכם – הם בונים כאלו בימים אלו לקראת הכרזה בקרוב.

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

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

יהיה בהחלט מעניין 🙂

על VMWare VSAN

[stextbox id="info"]בפוסט זה אינני מדבר על VSAN 6.0 ועל גירסה זו יפורסם בעתיד פוסט נפרד.[/stextbox]

בחברות רבות, תצורת השימוש ב-vSphere היא כדלהלן: יש X שרתים שהם מהווים את ה-Compute (ועליהם בעצם רצים המכונות הוירטואליות), יש Storage של חברה כלשהי (NetApp/EMC/HP/IBM וכו'), ויש כמובן מתג או 2.

התצורה הזו היא תצורה טובה, אולם אחת הבעיות היא ביצירת תלות מוחלטת ב-Storage. יש כשל ב-Storage? סביר להניח שחלק או כל ה-VM יפלו. רוצים להרחיב את ה-Storage? שלם מחירי פרימיום על מדפים ודיסקים. בנוסף, ישנם מקומות שמעדיפים להשתמש בדיסקים מקומיים במקום עם Storage.

ב-VMWare עבדו ב-3 שנים האחרונות על פתרון אחר שנקרא VSAN שמתאים במיוחד לחברות קטנות עד בינוניות, כאלו שלא יכולים להרשות לעצמם Storage יוקרתי, או כאלו שמעוניינים בפתרון Storage אחר.

השיטה של VSAN היא די פשוטה: בכל שרת יהיו מינימום 2 דיסקים, כאשר אחד מהם הוא דיסק מגנטי (בין אם זה SATA, NL-SAS או SAS) ודיסק אחד מבוסס Flash (שוב – SATA או SAS, אפשר גם PCIe או nVME). יש צורך בלפחות 3 שרתים (ליצירת "רוב" – Quorum) ושהם יהיו בתצורת אשכול (Cluster) וכמובן שיש צורך בסוויצ' טוב עם עדיפות ל-Switch במהירות 10 ג'יגהביט וכמובן – יותר מכניסת רשת אחת פר שרת.

ה-VSAN מאחסן את ה-VM בדיסק המגנטי וה-Flash משמש כ-Cache (הן לקריאה והן לכתיבה כאשר הנתונים מועברים לדיסק המגנטי מהדיסק FLASH ברקע) והוא גם משכפל את הנתונים לדיסקים האחרים בשרתים באשכול. אחד הדברים שיש צורך לתת את הדעת עליו הוא שאין RAID בתצורה כזו. הדיסק בשרת A משוכפל לדיסק בשרת B ולשרת C (זה קצת יותר מורכב מזה) ולכן אם לדוגמא מחליטים להוסיף דיסק, מומלץ להוסיף גם דיסקים בשאר המכונות ועדיף שיהיו כמות זהה של דיסקים.

מבחינת נפילה – כאשר נופל שרת, 2 השרתים האחרים "לוקחים פיקוד" היכן שהשרת האחר נפל ומכיוון שהנתונים נמצאים בשאר הדיסקים שקיימים באשכול, הנפילה כמעט לא תשנה למעט העניין שהמכונה תצטרך להיות מופעלת מחדש (אוטומטית). עם VSAN לא ניתן להשתמש בפונקציית Fault Tolerance. אם יפלו 2 שרתים לעומת זאת, ברוב המקרים המכונות שהיו ב-2 השרתים הנופלים לא יעלו (אגב, ניתן להרחיב את ה-VSAN גם לשרתים נוספים שאינם כוללים דיסקים מגנטיים או דיסקים בכלל, אולם אז המהירות לא תהיה גבוהה). ניתן "לעקוף" מגבלה זו בשימוש Storage Policies שתיכף ארחיב לגביו.

אחד הדברים ש-VMWare עושה בשנים האחרונות בכל הקשור ל-Storage הוא "לזרוק" משימות שונות שה-Storage יעשה בעצמו ולא שרתי ה-Compute שלך, מה שנקרא גם "האצה". בעבר הרחוק דבר כזה לא היה קיים ודבר כמו Snapshot היה מתבצע ע"י ה-vCenter תוך שימוש במשאבי השרת למרות שכל Storage שמכבד את עצמו כולל פונקציונאליות זו. בגירת vSphere 5 הציגה VMWare את ה-VAAI, שגם נקרא "Hardware Acceleration" שבו פעולות מסויימות נעשות ע"י ה-Storage מבלי לקחת משאבים מהשרתים. טכנולוגיה נוספת ש-VMWare הציגה היתה ה-VASA, כך שפונקציות כמו thin provisioning או Deduplication ופונקציונאליות נוספות היו ניתנות לביצוע ישירות מה-vCenter כאשר בסופו של דבר הן היו מבוצעות ב-Storage עצמו ללא לקיחת משאבים מה-Compute.

ב-VSAN ישנה גם פונקציונאליות כזו, אם כי היא בעצם חלקית. כך לדוגמא אתה יכול לקבוע שהתוכן שלך שמאוד חשוב לך ישוכפל על פעמיים או יותר על הדיסקים ב-Cluster, וזה מבוצע ע"י שימוש ב-Storage Policies. כל מה שעליך לעשות הוא להחליט מה הם ה-VM החשובים לך, ולבנות Policy שיאמר למערכת כמה שרתים נופלים המערכת תהיה מסוגלת "לסבול" ולהמשיך להריץ את אותו VM, כמה פעמים לשכפל את הנתונים, כמה מקום לשמור גם במצב של Thin Provisioning ועוד, ואת ה-Policy אתה מחיל.

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

כעת נעבור לשלב הפחות טכני ויותר "מכירתי" – את VSAN לא צריך להוריד. אם יש לך vSphere 5.5 U1 ומעלה – הוא כבר שם ויש צורך להפעיל אותו במספר נקודות מבלי להוסיף שום דבר ל-vCenter. מה שכן תצטרך, זה רשיונות, והרשיונות נמכרים פר CPU פיזי בשרת במחיר של $2495 (לפני מו"מ), כך שאם יש לך לדוגמא 3 שרתים ולכל אחד מהם 2 מעבדים, תצטרך לשלם (שוב, לפני מו"מ) סכום מוערך של 15,000 דולר (המחיר הוא רק ל-VSAN, יש צורך גם ברשיונות ESXI ו-vCenter, ואגב – בלי vCenter אין VSAN), וכאן מתחילה ההתלבטות של חברות: לא שווה לקנות Storage פשוט-בינוני במחיר כזה?

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

מצד שני, אם ה-Storage שלך משרת גם אחרים לשרותים כמו SMB/NFS, אז השיקול משתנה, מכיוון ש-VSAN לא בנוי לתת שרותים כאלו מכיוון שלא מדובר על מכונת VM שנותנת שרותי NFS/iSCSI לשרתים ושיטת האחסון שונה שם לחלוטין (ועל כך תוכלו לקרוא בהרחבה כאן). כמובן שאתה יכול להרים לך VM מבוסס לינוקס או Windows ודרכו לשתף קבצים הן דרך NFS והן דרך SMB, אבל לא לכולם זה נוח.

והנקודה הכי חשובה היא: מה אתה מייעד עבור המערכת? אם לדוגמא עבור VDI, אז הביצועים לא יהיו "מזהירים" למרות שיש שימוש מאסיבי ב-Flash כ-Cache (ולא, אי אפשר להכניס 2 דיסקים SSD בגרסאות VSAN קודמות ל-6, רק דיסק מגנטי ודיסק SSD, ובגירסה 6 אם תרצה להשתמש ב-All Flash, תצטרך להוסיף $1500 פר מעבד באשכול). אם אתה לעומת זאת צריך ערימה של VM שיעבדו בנפרד מה-Storage של החברה עקב ענייני אבטחה וכו' – VSAN יכול להוות פתרון די טוב.