עננים: מעבר לענן ושרידות מאוד גבוהה

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

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

מכאן נעבור לחברות שרוצות להעביר את התשתית שלהן לענן: חברות הענן אינן מנסות למכור לכם VM גדולים בזול. הן תמיד תהיינה יותר יקרות מכל ספק אחר שאינו ענן. מה שכן הן מנסות – זה למכור לכם את השירותים שהן מציעות במקום שתרים אותם על השרתים שלך אצל אותו ענן. לדוגמא: צריך SQL כלשהו? (לא חשוב אם זה MySQL או מיקרוסופט SQL או DB של אורקל) כמובן! אז במקום שתרים אחד כזה, אמזון מציעה לך שרות RDS (כן, גם ל-SQL Server וגם לאורקל), וישנם המון סוגי שרותים אחרים שהיתרון שלהם הוא מחיר (יחסית) זול, ושאתה לא צריך לתחזק כלום (ובין כה הם עושים שרות תחזוקה הרבה יותר מקצועי ממה שרבים עושים). אתה תשלם רק על הדברים שתגדיר ותשתמש, אין תשלום מינימום ואין תשלום מראש.

לכן, עם שרותים אלו, כמות ה-VM שתצטרך תצטמצם משמעותית. יכול להיות כמובן שתצטרך VM חזק בשביל שרת אפליקציות שלך, אבל לא תצטרך שרת בכלל עבור DB. יש לך מספר משתמשים גדול? אתה לא צריך קופסאות Load Balancing, אתה פשוט משתמש בשרותים של אותו ספק ענן לביצוע איזון עומסים. מתעקש על חומת אש מה-Brand האהוב עליך? יש לך VM מוכן יחד איתו, בחר, תקים ותשתמש, תשלם פר שעה עליו, ומה שהכי חשוב – אין יותר צורך בתחזוקת חומרה, סוויצ'ים, וכו'. הכל כבר מטופל ולבחירתך מגוון מסלולי תמיכה, כך שגם אם יש תקלות ביום כיפור – יש מי שיענה לך.

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

  • איזו מערכת הפעלה רצה על ה-VM אצלך שאתה רוצה להעביר? כל ספקי הענן הגדולים טוענים כי הם תומכים בכל מערכות ההפעלה. זה נכון בצורה חלקית. רשמית מה שהם מצהירים הוא נכון אולם בתכל'ס אם רוב ה-VM שלך מבוססים לינוקס, אין לך מה לעשות בענן של מיקרוסופט. לך לגוגל או אמזון. אישית, צמחו לי מספיק שערות לבנות מהתמיכת לינוקס של מיקרוסופט.
  • מי נותן לך קרדיט ראשוני (וכמה)? ספקי ענן שונים נותנים קרדיט ראשוני שנע בין כמה מאות דולדרים לכמה אלפי (או עשרות אלפי) דולרים. כמה ספק הענן מוכן לתת לך כדי להתחיל לעבור?
  • ניהול, תחזוקה, הגירה, הגדרות וכו' של השרותים וה-VM אצל ספקי ענן לא מבוצעים בד"כ דרך ממשק GUI אלא דרך כתיבת סקריפטים או אפליקציות תוך שימוש ב-API של ספק הענן. האם הספק תומך בשפות שאנשי ה-IT שלך מכירים או שהם רק יודעים PowerShell והספק מצריך ידע ב-Python/PERL? נכון, ספקי הענן ברוב המקרים נותנים תמיכה גם וגם, אולם ישנם לא מעט עניינים של פתרונות תקלות המצריכות שימוש בשפות ש"חביבים" אצל ספק הענן.
  • מעבר לענן מצריך שינויים מאסיביים בכל תכנון התשתית כולל דברים כמו Storage, Networking ועוד. פה יש לך NetApp/EMC שעליו אתם זורקים הכל, בענן אם תנסה לבצע את אותו טריק, תקבל חשבונית חודשית מבהילה! יש צורך בהפרדה של תכנים סטטיים ודינמיים, אפליקציות ו-VM שצריכים IOPS גבוה וכאלו שיכולים להסתדר עם כל דבר שתזרוק עליהם – לכן חובה לקחת בחישוב השכרת יעוץ/פרילאנסרים שיסייעו לך בתכנון המעבר ולאחר מכן ביישומו.
  • האם לספק הענן יש נציגות טכנית מקומית שנציגיה יכולים להגיע למשרדכם? טלפון/מייל זה טוב, אבל לפעמים פגישה פרונטלית יכולה לסגור קצוות רבים בפגישה אחת.

מכאן נעבור לשרידות: אצל ספק ענן אתה יכול לקבל שרידות גבוהה יותר ממה שאתה מקבל אצל ספק VM/VPS כלשהו. אפשר להשתמש בשרותים שונים כדי להרים VM מוכנים במקרה ויש עומסים פתאומיים (ולשרשר אותם מיידית ל-Load Balancer), והשרתים מתוחזקים בצורה כזו שגם אם VM נופל, הוא מיד קם על מכונה אחרת מיידית ללא צורך בהתערבות ידנית. ככלל, כל ספקי הענן נותנים לך תיעוד איך להקים את האפליקציה שלך/שרות שלך כ-Fault Tolerance.

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

לשם כך מומלץ לחשוב על אחד מהפתרונות הבאים:

  • כל ספק ענן מכובד (במיוחד השלישיה) מציע את השרותים במספר אזורים שונים בעולם. מה שאתם יכולים לעשות הוא להקים את התשתית שלכם בתצורה המינימלית בעוד אזור (Region) עם סינכרון דו כיווני (או רב כיווני, בהתאם לתשתית שלכם) בין האזורים וכל מה שצריך הוא מכונת VM קטנה מאוד שתדגום את האזורים כל הזמן. היה ואזור עיקרי לא מגיב, ה-VM הקטן ישנה את ה-DNS ושאר פרמטרים כדי שלקוחותיכם יקבלו שרות מהאזור המשני שהקמתם. (האזורים מופרדים מבחינת מערכות כך שנפילה באזור 1 אינה משפיעה על אזור 2)
  • ישנן מספר ספריות שונות (כולן בקוד פתוח) המאפשרות לך לעבוד דרכן ולהקים את השרותים שלך אצל יותר מספק ענן יחיד, כך שתוכל לקבל שרידות יוצאת מן הכלל. החסרונות בשיטה זו:
    • אתה צריך לשלם על התעבורת סנכרון בין ספקי הענן
    • ספריות אלו לא תמיד מעודכנות ולעומת זאת ספקי הענן משנים API במקרים רבים כך שהספריה לא כל כך תעזור.
    • יש הרבה יותר עבודה לעשות בהקמה/הגדרות וגם תחזוקה.

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

חג שמח 🙂

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

האם VSAN יכול לשמש כתחליף ל-Storage יעודי?

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

השאלה פשוטה: האם VSAN יכול להחליף פתרון Storage יעודי?

אסביר: במקרים רבים לחברות יש Storage יעודי שנקנה לפני מס' שנים ועלות חידוש חוזה תמיכה/תחזוקה גורמת להרהורים לגבי פתרון חלופי. יש מקרים שה-Storage מגיע ל-End Of Life ויש גם מקרים שמוצאים שמי שהחליט לרכוש Storage החליט להקשיב יותר לנציג השיווק מאשר לבדוק מספרים טכנית לגבי מה ה-Storage יכול להנפיק והתוצאות כרגע לא מספקות.

אם תקשיבו לתשובה מנציגי המכירות של VMWare (או ריסלרים שלהם) אז במקרים רבים התשובה תהיה ש"כן", בוודאי ש-VSAN יכול להחליף קופסת Storage.

החלק שהם לא כל כך ישימו עליו דגש – זה המחיר שצריך לשלם כדי להגיע לביצועים של Storage רציני מודרני מהשנתיים האחרונות. אם לדוגמא יש לך 10 ברזלים ואתה מחפש מקסימום IOPS, תצטרך למלא כל תושבת PCI וכל כניסת SAS ב-SSD מבוססי PCIe או SAS (מה-12 ג'יגהביט) מהקצה העליון כלומר שכל SSD כזה עולה לך כמה אלפי דולרים טובים. כך תקבל באמת מקסימום Performance ומיליוני IOPS אבל אתה כבר מדבר על עשרות אלפי דולרים ומעלה, ובמקרים כאלו, לעיתים הכדאיות הכלכלית נוטה לכיוון הארכת חוזה על ה-Storage הקיים ושדרוגו. אחרי הכל, קל יותר לדחוף מגש SSD, לשדרג/להוסיף SP (כל זה אם האפשרויות קיימות) מאשר להתחיל מאפס.

גם במקרים בהם ה-CEO וה-CTO מחייכים ומוכנים לממן VSAN עם כל הציוד שתיארתי בלינק ועם מילוי כל חור ב-SSD מהקצה הגבוה – ישנה בעיה מהותית אחת.

כפי שאנו יודעים, ב-Corporate טיפוסי במקרים רבים הוירטואליזציה אינה אחידה. פה הכניסו Hyper-V שנשאר כ"ירושה" מה-CTO הקודם שהחליט לעבור לפתרונות מבוססי מיקרוסופט בלבד, שם החבר'ה שמפתחים בלינוקס הכניסו Docker, ובל נשכח כל מיני שרתי ESXi ישנים שקיימים פה ושם כי מישהו הנחית הוראה מגבוה לא לשדרג כי אין יותר דרייברים חדשים לכרטיסים שבתוך ה-ESXi והמערכת עובדת ו"נא לא לנגוע" (כן, ראיתי גם מקרים כאלו). במקרים של Storage רגיל – אין בעיה, לכאן אתה מוציא SMB, לכאן אתה מוציא NFS ולשם אתה מכין כמה LUNs ומייצא כ-iSCSI ונגמרה הבעיה.

אבל VSAN לא יודע לעבוד כך. VSAN מכין Datastore ענק שהוא מיועד עבור ה-VM שרצים ב-hosts שמשתתפים ב-VSAN. יש לך ערימת שרתי ESXi שלא משתתפים ב-VSAN או שהם עם וירטואליזציה אחרת? הפתרון היחיד שיש לך הוא הקמה של VM באשכול השרתים שמשתתפים ב-VSAN ומשם לייצא החוצה CIFS/NFS/iSCSI. כמה זה מהיר וטוב? זה מאוד תלוי מה רץ על ה-VM שמייצא את השרותים הללו החוצה, אבל בכל מקרה אני מהמר שמול Storage מודרני מול VM כזה, ה-Storage המודרני ינצח עם יד קשורה מאחור מכיוון שיש לו הרבה יותר פונקציונאליות ממה ש-VSAN בתוספת ה-VM שמייצא – נותנים. בל נשכח של-VM עם VSAN אין גישה ישירות לבקר או לדיסקים, את זה יש רק ל-VSAN כך שאין לך דברים כמו dedup, tiering וכו'.

היתרון הגדול של VSAN הוא רק כשאתה מריץ ESXi וכל השרתים משתתפים ב-VSAN (אגב, לא חובה "לפוצץ" את כל הברזלים ב-VSAN, אפשר למלא את רובם ולחבר עוד כמה ללא SSD/דיסקים מכניים ואותם שרתים ישמשו כ-Compute Only). אז באותם מקרים אפשר לקבל שרידות מעולה ואין מקרים של "Storage נופל וכל ה-VMs למטה". גם אם שרת פיזי יקרוס אז המכונות VM שרצו עליו יעשו reboot בשרתי ESXi האחרים ואפשר גם להגדיר ש-2-3 שרתים נופלים, אז ה-VM החשוב יעלה במכונה תקינה (מה שנקרא FTT ולזה כמובן יש מחיר מבחינת כמות נמוכה יותר של Free space בדיסקים).

כל מה שתיארתי לעיל מדבר על גירסת VSAN הנוכחית (6.0). ב-VMWare החליטו שעם כל הכבוד לחברה האחות (EMC) – הם יתחרו בשוק ה-Software Defined Storage ואין לי ספק שהם יוסיפו הרבה מאוד פונקציונאליות ל-VSAN כדי לפתור גם את הבעיות שתיארתי לעיל, כך שכדאי לעקוב. כנס VMWorld יתחיל ביום שלישי כך שסביר להניח שביום שני והלאה יצאו הכרזות מצד VMWare ושותפים לגבי גרסאות חדשות למוצרים. אני אפרסם את ההודעות החשובות בפורום VMWare בפייסבוק ואתם מוזמנים להצטרף.

[stextbox id="info"]גילוי נאות: הח"מ מספק שרותי הטמעה גם ל-VSAN :-)[/stextbox]

פתרונות קוד פתוח כתחליף ל-Hypervisor מסחרי

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

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

האם קוד פתוח יכול לתת פתרון הולם כתחליף לדברים כמו ESXI?

ישנן לא מעט חברות שחושבות על פתרון כמו Open Stack כתחליף ל-ESXI. הרעיון עצמו על פניו נשמע הגיוני, אחרי הכל Open Stack מאפשר לך גם Network, גם Compute וגם Storage, אבל כשבודקים בפונקציות ההכרחיות שצריכים מה ESXI נותן ומה Open Stack נותן, התוצאות לעיתים מעודדות ולעיתים לא.

אך הבעיה המרכזית של Open Stack היא כמות הידע הנדרש על מנת להפעיל ולתחזק אותו. טכנית, ניתן להרים מערכת Open Stack שלמה תוך דקות ספורות (אם יש לך את המשאבים) מכל מיני חברות, אך ברגע שמשהו לא עובד – תצטרך או תמיכה מסחרית של חברה, או מישהו שיודע ממש ממש טוב לינוקס ורשתות, ולהסתפק בתמיכה של Mailing list או אולי IRC. איש סיסטם עם ידע בהפצת לינוקס כלשהי במקרים רבים פשוט לא יספק מכיוון שמדובר במערכת מאוד מורכבת ומסובכת (וכמובן תלוי בכל מיני קומפוננטות אם הן צד ג' קוד פתוח או מוצרים סגורים).

בנוסף – Open Stack עדיין מתאים לחברות ממש גדולות והוא לא ממש מתאים לחברה שיש לה מספר קטן של שרתים פיזיים.

פתרון אחר הוא Xen שמוכרות חברות שונות כמו Citrix או Oracle או להריץ את הגירסה הפתוחה ב-Xen Project ולחבר לזה את ה-Client של Citrix דרך Windows או להשתמש בכלים אחרים. אם יש לך כמות VM קטנה יחסית, הפתרון הזה יכול לעבוד לא רע בכלל. הפתרון של Citrix דווקא נותן "פייט" לא רע לפתרון של ESXi אבל אם אתה צריך תמיכה – תצטרך לרכוש את המוצר המסחרי.

עוד פתרון שחלק חושבים שיכול לסייע להם (אך הוא לא) הוא KVM. בעקרון KVM הוא בעצם "מנוע" וירטואליזציה, הוא זה שבסופו של דבר גורם ל-VM לפעול. הוא לא יודע ליצור דיסק ל-VM, הוא לא יודע להגדיר שום דבר ל-VM, אתם צריכים להזין לו את כל הדברים ידנית (או דרך סקריפט) ולכן KVM בד"כ לא מומלץ לשימוש "ידני", אלא מומלץ לשימוש בשילוב כלים, לדוגמא virsh שנותן command line לנהל את כל ה-VM או libvirt שזו ספריה שתומכת ב-binding בשפות רבות כך שניתן בשפה החביבה עליך להרים מכונות מבוססות KVM, לכבות, לעשות מיגרציה, ופעולות רבות אחרות.

אבל כמו שרובינו יודעים, אנשי IT אוהבים GUI, תן להם GUI גרפי, והם מחייכים, ואם אפשר שאת אותו GUI לממשק אותו דרך API לשפה החביבה על אנשי הלינוקס בחברה -אז כולם יכולים לחייך.

פה נכנס כלי שרד-האט מפתחת שנקרא oVirt. הכלי הזה יודע לנהל יפה שרתים שמריצים את Ovirt Node (שזו גירסת לינוקס מאוד מקוצצת שמותקנת "על הברזל") ומאפשרת פונקציות רבות שקיימות במערכות vSphere. למי שרוצה, יש גם גירסת LIVE שלא מצריכה התקנה, רק להוריד ISO, לעשות Boot ולשחק עם זה (רק כדאי שיהיה מחשב נוסף שישמש כ-Node). גם כאן, אם אתם צריכים תמיכה, תצטרכו את זה מ-רד-האט בתשלום לפי תושבת, או דרך ה-Mailing list / IRC אם אתם בוחרים באופציית החינם. שימו לב ש-oVirt הוא כלי שמצריך השקעה בלימוד.

עוד אופציה שיש בקוד פתוח היא מערכת שנקראת  ProxMox, ודרכה אתה יכול להרים VM, ולבצע ניהול ודברים נוספים. היתרון של Proxmox על פני פתרונות אחרים הוא קלות השימוש בכלי. הוא לא מציע פונקציות רבות כמו oVirt אולם אם יש לכם מספר שרתים קטן והרשת הולכת להיות די פשוטה, Proxmox יכול להוות פתרון לא רע.

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

ולבסוף – הנה קישור שאני מציע לכולם לראות – טבלה המשווה בין הוירטואליזציות השונות.

תחום האחסון בעוד 5 שנים

אני רוצה שנחזור אחורה בזמן (לותיקים מאיתנו) בערך 20 שנה אחורה, לתחילת שנות ה-90. אם היית צריך שרת "עצבני" – היו לך מספר פתרונות, כולם קנייניים – בין אם זה HP-UX, או IBM AIX, או כמובן Solaris של Sun. אם רצית להריץ UNIX טוב על מערכת מבוססת X86, הפתרון המסחרי שהיה לך הוא של SCO ואם חיפשת לחסוך בכך שתלך ל-X86, היית מוצא מהר מאוד שטעות בידך – SCO דרשה בזמנו סכום של בערך $4500 דולר עבור רשיון ל.. TCP/IP, וזה פר שרת. היית יכול כמובן לנסות את גרסאות ה-BSD או את המערכת הצעירה שנקראת Linux, אבל אם היית מראה את זה ב-Corporate, היית מסתכן בצרות. אם היית שואל חברות אחרות על Linux, הן היו אומרות לך שזו מערכת "נחמדה" אבל לא יציבה ולא חזקה ולא תומכת בהרבה דברים וכדאי שתשכח ממנה ותתרכז בפתרון הקנייני שישאר איתך "לשנים רבות" ורק ישתפר.

נחזור חזרה ל-2015, וכיום אם אתה מרים מערכת שאינה Windows, סביר מאוד להניח שהיא תהיה Linux. איפה SCO? נעלמה. איפה AIX או HP-UX? נמצאים במקומות בודדים מסויימים, ושאר מערכות ה-UNIX המסחריות למיניהן מתו. נשארו הגרסאות בקוד פתוח כמו BSD לסוגיו וכמובן הפצות הלינוקס. כיום ב-Corporate (לפחות הבינלאומי, הרבה פחות בישראל) אינו נראה כדבר נורא וחברות למדו לאמץ את מערכת ההפעלה, במיוחד שחברה כמו Red Hat נותנת להם שקט לעשור שנים פר גירסה, והיצרנים מקבלים את ה"הכשר" של Red Hat שה-Corporate מאוד רוצה לראות. יש גם תמיכה 24/7 וגם הגנה נגד תביעות של פטנטים. כיום אם תרצה להכניס Solaris במקום Linux, זה יהיה לך הרבה יותר קשה, כמו שלפני 2 עשורים מאוד היה קשה להכניס Linux.

גם תחום הוירטואליזציה עבר פחות או יותר את אותו מסלול אם כי בפחות זמן. ל-IBM היו פתרונות "וירטואליזציה" עוד משנות ה-70 (DISCO) ולחברות אחרות היו גם פתרונות של "וירטואליזציה" (אתם יכולים לראות רשימה מלאה, אם כי לא עדכנית – המסמך נכתב ב-2004 כאן) כך שחברות שהריצו מערכות MainFrame יכלו להריץ עוד עותקים של אותה מערכת הפעלה כתהליך (Process) עצמאי (פחות או יותר) וב-2004 חברת Sun הציגה את Solaris Container, שנתן פחות או יותר את מה ש-IBM נתנו 30 שנים לפני כן. בערך באותו זמן החלה חברה צעירה בשם VMWare להציע פתרון וירטואליזציה מעניין – בהתחלה בדסקטופ ואחר כך לאט לאט בשרתים – את ה-ESX (שנהפך במשך הזמן למשפחה ענקית [ולפעמים ענקית מדי] של מוצרים).

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

אז עברנו בשנים האחרונות מ-UNIX ל-Linux, ומשרתים פיזיים שמריצים מערכת הפעלה יחידה לשרתים שמריצים מערכת וירטואליזציה ועליהם רצים עשרות או מאות שרתים וירטואליים.

אנחנו נמצאים עכשיו בתקופת מעבר מעט שונה שאני מאמין שתחל להיות מיושמת בשנה שנתיים הקרובות וביתר שאר ב-4-5 שנים הקרובות, והיא – מעבר ל-Storage שאינו "ארון".

אם נסתכל היום על Storage ממוצע, נמצא שהוא מורכב מהרבה "מדפים" (Shelves), אולי מתג לסיב אופטי, (Storage Processor(s (שעושים בעצם את כל העבודה) ואולי עוד כמה מודולים, בהתאם ליצרן ה-Storage, דגם וכו'.

נסו לדמיין את ה-Storage שיש לכם ב-Corporate. ה"מפלצת" הזו, עתירת הטרהבייטים שנותנת שרותי קבצים, NFS, iSCSI ואולי עוד שרותים – היא היא ה"לב" של ה-Data Center והיא מאחסנת את המידע החשוב שלכם. את הדבר הזה אתם צריכים שיהיה הכי יציב שיש. אם זה נופל – שרותים רבים לא יהיה זמינים למשתמשים שלכם. אם יפול לכם מתג (Switch) בחברה, תוכלו להתגבר בכך שתנתבו חלק מהכניסות למתגים אחרים. אם שרת פיזי יפסיק לפעול, אתם תבצעו העברה/הפעלה של המכונות הוירטואליות במכונה פיזית אחרת, אבל אם כל השרתים מקבלים שרותי Storage מאותה קופסא ענקית והיא מושבתת – אף VM לא יעלה.

הותיקים מבינינו יקבלו אולי תחושת Deja-Vu קלה – ככה בדיוק מכרו ל-Corporate שרתים של Sun וחברות גדולות אחרות לפני 20 שנה. מפלצת גדולה, חייבת להיות יציבה ואם היא מפסיקה לתת שרותים – הצרות יגיעו (כולל כמה מאות טלפונים  ו-SMS בהולים).

כיום – שרתי ה-Solaris הגדולים של SUN נזרקו מרוב החברות ואותם שרתים הוחלפו במכונות Linux שמאוחר יותר עברו P2V להיות VM, וכיום יש לנו מספיק פתרונות טכנולוגיים לתת שרידות ל-VM כדי שגם אם יפול מתג, או Storage או שרת פיזי – ה-VM ימשיך לעבוד. אחרי הכל, להכין FT או HA ב-ESXI זה לא בדיוק מסובך כמו להטיס חלליות…

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

האם אתם יודעים על איזה שרת אתם רצים? (מבחינת Brand), האם אתם יודעים איזה דיסקים יש בפנים? האם יש דיסקים בשרת הפיזי או שזה מחובר לארון שמריץ שרותים שנותן שרותי דיסק ב-LAN עם דברים כמו LUN/iSCSI? התשובה לכל השאלות האלו היא פשוטה והיא: לא, אתם לא יודעים. אם תתהו מה יש מאחורי הקלעים, אמזון יאמרו לכם שהם עושים כל מיני דברים סודיים שלא אמורים לשנות לכם כלום – מבחינתם, הם צריכים לתת לך VM עם תכונות X,Y,Z שרצית וזהו. לא אמזון, לא גוגל ולא מיקרוסופט – אף אחד מהם לא מפרט לעומק מה ה"נוסחה" שהם בונים את התשתית שנותנת את ה-VM שאנחנו מקבלים בסוף. יש לנו רמזים על חלקים מסויימים (אמזון משתמשת ב-Xen, גוגל ב-KVM ומיקרוסופט ב-Hyper-V), אבל לא על הדיסקים, לא על הרשת, ולא על רפליקציות וכו'.

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

נחזור ל-Data Center שיש ב-Corporate ונדמיין לעצמנו שאנחנו לוקחים מברג ומחליטים לפתוח את אותו פתרון Storage קנייני גדול (טיפ: לא לנסות בחברה, מתכון בטוח לפיטורים מהירים) ולראות מהו אותו "קסם" שהם עושים בפנים. מבלי להיכנס ליותר מדי פרטים טכניים, אנחנו נמצא שישנה מערכת הפעלה קניינית של היצרן, מעבדים, זכרונות ועוד כמה חלקים, כך שה-Storage עצמו בנוי בצורה שלא ממש רחוקה משרת ממוצע שיש לנו (כמובן שאין שם מעבדי X86). אם נסתכל ונכיר קצת יותר את ה-Storage Processor ונשווה אותו למעבדים גנריים אחרים, אולי נופתע מכך שהמעבד עצמו הוא חלש בהשוואה לאחרים. כמה חלש? מעבד Xeon ישן מאוד שיש לך בשרת ישן – הרבה יותר חזק מה-SP עצמו ומסוגל לעשות את אותם פעולות מבלי להתאמץ ממש (כן, גם אם ניתן לו לעשות את החישובים של דחיסה, RAID וכו' במקביל).

זו בדיוק הנקודה שספקי הענן הפופולריים הבינו מזמן. אתה ממש לא צריך את הפתרון הקנייני המפלצתי כדי לבנות משהו שיתן שרותי בלוק/קבצים בצורה מהירה מאוד ובדרך גם לנהל מאות דיסקים, וכן – אתה יכול גם לקנות דיסקים איטיים (ואפילו SATA – וכן, אמזון קונים SATA בערימות) וגם SSD מהירים מאוד ובעזרת הפתרון שהם בונים, הם משלבים את הדיסקים כך שאחד לא "יחנוק" את השני. כך לדוגמא אם אתה עושה רפליקציה כל כמה שעות בין 2 ארונות, אפשר להכניס בארון שמקבל את הרפליקציה מספר דיסקים SSD גדולים שמשמשים רק כ-Cache ל-Write ולאחר שהם מקבלים את ה-DATA יש תהליך איטי של כתיבה מה-SSD לדיסקים SATA (לא יכול לאמר מי ספק הענן שעושה זאת, אבל אחד מהם בהחלט עושה זאת כך).

כאן מגיע דבר שנקרא במקומות רבים SDS ר"ת של Software Defined Storage. ב-SDS אתה הוא מי שבעצם מתכנן ובונה את ה-Storage ואתה יכול להקים עליו איזו תוכנה שתרצה כדי לנהל את ה-Storage וכאן יש לך מגוון של תוכנות, החל מקוד פתוח ועד פתרונות סמי-קוד-פתוח כמו של EMC ScaleIO  ופתרונות קוד סגור אחרים. גם מבחינת גדילה אתה יכול להתחיל במסלול של Scale UP ולחבר JBOD או יותר ועד למצב של Scale Out עם 3 שרתים ומעלה (ומומלץ רשת של 10 ג'יגה בין אותם שרתי Storage). אפשרות נוספת שיש לך היא בעצם להשתמש במשהו שכבר קיים אצלך, כך לדוגמא אם כל השרתים הפיזיים שלך מריצים ESXI, אתה יכול להשתמש ב-VSAN ולהכניס דיסקים מגנטיים ו-SSD לכל אחד מהשרתים ולבנות בעצם Storage מתוך אותם משאבים (בין כה VSAN לעולם לא עובר את קו ה-10% שימוש במשאבי מעבד/זכרון כך שהוא לא יחנוק לך את השרתים).

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

האם ב-Corporate יעברו לפתרון כזה? כשחשבתי על כך בעבר, תשובתי היתה "לא", אולם כיום כשחברות מוצאות את עצמן צריכות לשלם על הארכת חוזה תמיכה סכומים רציניים מאוד, ומאות אחוזים נוספים על דיסקים, נראה לי שחברות יהיו מוכנות יותר לשמוע על הרעיון. לא לעבור אליו מחר, אבל עצם הרעיון נשמע להם "מעניין". אני מאמין שבמהלך ה-5 השנים הקרובות נראה יותר ויותר חברות עוברות ל-SBS. אם מסתכלים על הדוחות הפיננסיים של חברות יצרני Storage כבר כיום רואים חברות כמו EMC שלא מראות ממש צמיחה והם מתכננים קיצוץ כ"א, וכנ"ל ב-NetApp כך שנראה שחברות פחות ופחות רוצות לקנות את הקופסאות הענקיות הללו.

על רשיון VDA ועל פתרונות עוקפים

אחת הבעיות המהותיות ביותר בהטמעת כמעט כל פתרון VDI, הוא עניין הרישוי מערכות הפעלה של מיקרוסופט. למיקרוסופט יש פתרונות ה-VDI משלה וכל פתרון אחר שאינו משלה מצריך תוספת כספית רצינית. מישהו עשה חישוב ומצא שאם אתה רוצה להרים פתרון VDI שאינו מבוסס על טכנולוגיית מיקרוסופט, תצטרך לשלם משהו כמו $100 פר תחנה, ולא מדובר על תשלום חד פעמי אלא מנוי שנתי.

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

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

פתרון 1
הפתרון הראשון הוא שימוש במערכת הפעלה של מיקרוסופט המיועדת לשרתים, ו"הפיכתה" למערכת דסקטופ. אפשר לבצע זאת הן על מערכת 2008/2008R2 והן על 2012/2012R2 בגרסאות Standard. מיקרוסופט עצמה מאשרת כי למערכת ש"הומרה" לדסקטופ, אין צורך רשיון VDA (אבל מצד שני גם לא תוכלו להשתמש במערכת הזו למשתמשים רבים אלא אך ורק מכונה פר משתמש). הנה מה שמיקרוסופט כותבת (מתוך ה-FAQ לגבי VDI – לחצו להגדלה)

vdaמי משתמש בטריק הזה? חברה אחת שאולי שמעתם עליה בשם .. אמזון, שמציעה שרותי דסקטופ תחת השם Amazon Workspaces. לפחות ממה ששמעתי מכל מיני אנשים שביצעו זאת, אין שום בעיה להריץ כל אפליקציה של Corporate.

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

הרבה, הרבה מאוד חברות לא אוהבות רעיון ה-VDA. תחשבו על זה לרגע – הדסקטופים שלכם והלאפטופים – בכולם יש Windows ששולם פעם אחת בלבד, וגם הרשיונות למערכות Windows 2012/2012R2/2008 שולמו באופן חד פעמי, ואילו VDA מצריך תשלום כל שנה, ולכן החברות הללו שהיו מעוניינות לחשוב על פתרון VDI פנו הן ל-Citrix והן ל-VMWare למצוא פתרונות חלופיים.

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

ה-VDI שיופעל עבור המשתמש הוא לינוקס לכל דבר ועניין, בין אם זו הפצת RHEL או Centos (גירסאות 6.6 ומעלה) או אובונטו 12 (שאר ההפצות לא נתמכות באופן רשמי אבל מנסיון – אין שום בעיה להשתמש בהן, כולל סביבות כמו KDE, XFCE ואחרות). ההטמעה בלינוקס (במקרה ומדובר ב-Horizon View של VMware, ב-Citrix זה שונה) כוללת התקנת VMWare Tools (ואני ממליץ לא להתקין את החבילה ש-VMWare נותנת אלא את Open VM Tools שזו גירסת הקוד הפתוח שהיא הרבה יותר יציבה, מעודכנת, וגם המהנדסים של VMWare משתתפים בפרויקט והחבילה כלולה בתוך ה-REPO ברירת המחדל של ההפצה), התקנת JRE (כן, ב-VMWare עדיין חושבים שלהריץ JAVA על דסקטופ זה דבר חכם…) ואת ה-View Agent והגדרות נוספות שונות שאיש הלינוקס יצטרך להוסיף. אגב, את עניין הרפליקציה של המכונות (בין אם Linked Clones או Full Clones יש צורך לבצע עם סקריפט שכתוב ב.. Power Shell. לך תבין מדוע..)

לאחר שהמשתמש מקבל את המסך הלינוקס (אחרי שהוא התחבר ל"פורטל"), הוא מבצע Login למערכת (אין שום בעיה שיבצע Login מול AD של מיקרוסופט) והוא יקבל סביבה גרפית שאיש הלינוקס בחברה בנה/שינה כדי שתיראה כמה שיותר "ווינדוזית". מכאן והלאה, שמשתמש יבצע Double Click על אייקון כלשהו (דפדפן, וורד וכו' וכו') הוא יקבל בעצם את האפליקציה משרת 2012/2008 כך שהלינוקס הוא רק "מעטפת", אתם לא תתחילו להריץ תוכנות לינוקסיות בחברה (אלא אם אתם רוצים, אבל זה משהו אחר. זו לדוגמא יכולה להיות הזדמנות מעולה להטמיע כרום ולשכוח מוירוסים)

בשיטה זו – אתם משלמים 0 פר VDI למיקרוסופט (שוב, למעט רשיונות שאתם צריכים לשלם על Published Apps)

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

 

כמה נקודות חשובות לגבי תכנון הטמעת VMWare VSAN 6

יצא לי לאחרונה להיתקל במה שאני קורא "סקרנות" של כל מיני חברות לגבי VSAN-6 של VMWare וראיתי פה שם כל מיני תכנונים והצעות שחברות הציעו כדי להטמיע לנסיון את VSAN ב-DC של החברות ובחלק מהמקרים היו מספר דברים שאינם נכונים או אינם מומלצים. לפיכך, הנה המלצות שנוסו ואינם רק "פרי" של הסתכלות במצגות השיווקיות של VMWare.

אחלק זאת למספר חלקים:

דיסקים
בגירסה 6 של VSAN ישנה תמיכה של All Flash, כלומר גם הדיסקים שאמורים לשמש כתכולה (Capacity) וגם הדיסקים שמשמשים לביצועים (Performance) יכולים להיות SSD. זה מעולה, אבל המחיר של דיסקים SSD מבוססי SAS (שלא לדבר על NVME) מאוד יקרים, ולכן VMWare ממליצה שתבחרו בסקאלה בין דיסקים שיכולים להכיל טרהבייטים של מידע אך אינם מהירים לבין דיסקים מגנטיים מהירים אך שאינם יכולים להכיל הרבה מידע.

האמת היא שהדיסקים המהירות במהירות 15000 RPM לא יסייעו לכם הרבה מכמה סיבות:

  • כל דיסק SSD הכי פשוט (כל עוד הוא מבוסס SAS) יתן לכם IOPS הרבה יותר גבוה מדיסק של 15000 RPM.
  • הכתיבה לדיסקים האלו בין כה נעשית ברקע וגם דיסקים NL-SAS במהירות 7200 RPM יתנו תוצאות שנמוכות באחוזים בודדים מדיסקים במהירות 15000 RPM
  • בדיסק מבוסס NL-SAS תוכל להכניס הרבה יותר מידע, חשוב לזכור – מידע של VM נשמר במספר שרתים במקביל כך שבכל מקרה לא תקבל 4 טרהבייט אם הכנסת 4 דיסקים של 1 טרהבייט (לדוגמא)

נקודה נוספת שמאוד חשובה בתכנון – VSAN אינו תומך בשום RAID וגם כמות הדיסקים שהוא תומך כקבוצות (קבוצה = דיסק SSD + לפחות דיסק מגנטי אחד) היא קטנה, עד 7 דיסקים מגנטיים בקבוצה, כך שאינך יכול לבוא ולחבר JBOD עם 20-60 דיסקים לדוגמא. תצטרך לכל קבוצת דיסקים להוסיף דיסק SSD (בחברות – SAS או NVME או PCIe, ב-LAB גם SATA יספיק), כך שאם לדוגמא אתה מתכנן להכניס 24 דיסקים של 1.2 טרהבייט מבוססים SAS, תצטרך לפחות 4 דיסקים SSD. נקודה חשובה נוספת – גודל ה-SSD המומלץ הוא לפחות 10% מגודל הדיסקים בקבוצה (כלומר אם הקבוצה מכילה 4 דיסקים של 1 טרה, תצטרך SSD בגודל של לפחות 400GB).

עוד נקודה ש-VMWare מאוד ממליצה עליה היא חלוקה קטנה של דיסקים, כלומר אם יש לך 4 דיסקים, חלק אותם ל-2 קבוצות כאשר לכל קבוצה יהיו 2 דיסקים ודיסק SSD. עוד המלצה של VMWare (שבחלק מהמקרים היא פרקטית ובחלק לא, תלוי בגודל השרת) – היא שכל קבוצת דיסקים יהיה בקר דיסקים יעודי (אגב, אם אתם קונים שרתים מוכנים ל-VSAN, מה שנקרא Node Ready, ברוב המקרים לא תמצאו 2 בקרי דיסקים אלא רק אחד). כמובן שקבוצות קטנות נותנות יותר ביצועים – אבל הכל תלוי בתקציב שלך.

רשת ב-VSAN
כשזה מגיע לרשת, לא מומלץ לעבוד במהירות של 1 ג'יגהביט (ו-LAG בין כה לא יעזור הרבה, מנסיון..) ומומלץ לעבוד עם חיבורי 10 ג'יגהביט בזוגות, כאשר ההמלצה האישית שלי היא להשתמש בסה"כ ב-6 פורטים לפי הפירוט הבא:

  • זוג 10 ג'יגהביט לתעבורת VSAN – אין מה לעשות, VSAN מעביר המון מידע נון סטופ (ואגב, לידיעת מנהלי הסוויצ'ים, הוא משתמש ב-Multicast כדי "להכריז" על שרתים) בין השרתים. את הזוג מומלץ להגדיר כ-Fail Over.
  • זוג 10 ג'יגהביט לתעבורת VM – חובה אם אתם חושבים להשתמש ב-SAN בשילוב Horizon לשם VDI. גם כאן – Fail Over.
  • זוג 1 ג'יגהביט – ל-Management. גם כאן – תצורת Fail Over.

שימוש ב-vCenter
לא מומלץ להקים את תשתית ה-vCenter על תשתית ה-VSAN, מכיוון שאם השרתים יפלו (יותר מ-1) – לא יהיה לך vCenter, ולכן מומלץ להשתמש ב-vCenter שרץ על ESXI שלא קשורים למערך VSAN. לחוצים במקום ובמשאבים? תקימו ESXI קטן ועליו vCenter Appliance לינוקסי כ-VM, זה יספיק.

הוספת ESXI כ-Compute Only
אם אתם רוצים להוסיף שרתי ESXI שישמשו כ-Compute Only (ללא דיסקים בתוכם) זה בהחלט אפשרי, אבל לא מומלץ להקים VSAN Cluster עם 3 שרתים שכוללים דיסקים ועוד 4 שרתים שלא כי אז העומס יזרק על כל השלישיה הראשונה. מומלץ להוסיף קבוצות דיסקים קטנות לשרתים שאתם מייעדים ל-Compute Only אם כמות השרתים הנ"ל תהיה גדולה, כך שהעומס יתפזר.

שימוש מאסיבי ב-Storage Profiles
בעקרון VSAN מאפשר לכם להגדיר כל מיני פרופילי Storage עם מאפיינים שונים כמו כמות שכפולים (Replications), או FTT (ר"ת failures to tolerate – כמה ה-VM ישאר חי אם X שרתים פיזיים נופלים) ועוד, אבל כדאי לתכנן זאת בחוכמה, ככל שתגדילו את ה-FTT וכמות הרפליקציות, כך ישאר לכם פחות מקום בדיסקים וכל מערכת הדיסקים תעבוד הרבה יותר אגרסיבי. אז כן, אם הרמתם VM שמריץ DB פרודקשן של אורקל או של מיקרוסופט, כדאי להגדיר לו FTT של 2 (לדוגמא), אבל אם אתם מריצים VDI ויש לכם 20 VM של Windows 7, במקרה ושרת ימות וה-VM יפלו – לא יפול העולם.

צורך ב-DEDUP וכו'.
ישנן מספר חברות שמוכרות Appliance VM שנותנים שרותים כמו File Server, DeDup, דחיסה ועוד. לגבי File Server, אם אין לכם רשיון 2012 פנוי, תמיד אתם יכולים להרים לינוקס עם SAMBA, לחבר אותו ל-AD שלכם ולתת שרותים כאו. לגבי שאר הפונקציונאליות – חכו להכרזות בסוף חודש הבא 🙂

רכישת SSD מאוד יקרים
ישנם כרטיסי SSD PCIe מאוד יקרים שנותנים יותר מ-100K IOPS בכתיבה וקריאה. הם מעולים, אבל הם לא נתמכים רשמית ב-6 VSAN, כך שלא מומלץ לבצע השקעה כזו.

כרטיסי בקר
אם אתם מסבים שרת קיים לשימוש ב-VSAN, ודאו שיש לבקר Queue Depth כמה שיותר גבוה (256 זה לא רע בתור התחלה, כמה שיותר – יותר טוב). כרטיסים פשוטים כמו LSI 9211 ומעלה נותנים Queue Depth של 640 וכרטיסים יותר מעודכנים נותנים 1024. בדקו את הבקר אם הוא ב-HCL כאן.

לסיכום: זה מאוד מאכזב לבנות מערכת VSAN, להרים עליה כמה עשרות VM בתור התחלה ואז לראות שהיא בקושי "סוחבת". הסיבה לכך בד"כ היא תכנון לא נכון מבחינת דיסקים (או שימוש ברשת של 1 ג'יגה). הכל תלוי מה ה-VMs שהולכים לרוץ עליה. VM של דסקטופים מצריכים קבוצות קטנות של דיסקים עם SSD מהירים (מומלץ PCIe או NVME) מכיוון שמדובר בד"כ בהרבה יותר כתיבה מאשר קריאה, בשעה ש-VM של שרתים בד"כ מצריך הרבה יותר קריאה מאשר כתיבה, ולכן חשוב לתכנן מראש לפני שקונים ציוד. מתחילים בקטן (3 שרתים מינימום) ומשם גודלים.

איך לרכוש את המוצרים של VMWare בזול

אני זוכר עוד ב-2005 כשהיה לי "רומן" עם VMWare GSX, אחת הבעיות שהיו לי כדי להכיר אותו, היה העניין ה"פעוט" שפשוט לא היה לי כסף לרכוש רשיון. אתה יכול להרים מערכת כזו ולהתנסות איתה וללמוד אותה, אבל אחרי חודשיים – טראח, המערכת לא מוכנה לתת לך לבצע Login, וכך יצא מצב של חתול ועכבר – אם אין לך מספיק נסיון, אתה לא תתקבל אצל חברות שמחפשות עובד שמכיר את המערכת טוב, אבל מצד שני – כשאין לך מערכת כזו ואתה לא יכול להתנסות, אתה לא תהיה מספיק מקצועי (אלא אם כמובן אתה משתמש ברשיון של התוכנה מהעבודה – בבית)

המצב כיום ב-2015 שונה מהמצב ב-2005. יותר ויותר חברות גדולות מחפשות מומחה לוירטואליזציה שזו תהיה העבודה העיקרית שלו (אפשר לראות בנקל אם מדובר בחברות גדולות או קטנות – אם הם מחפשים מישהו עם ידע בוירטואליזציה, אבל בדרך שידע גם סטורג', Windows, Linux, והטסת חלליות..). כיום מנהלים רבים או שמשתמשים ברשיון שהם "השיגו" מעבודה או דרך חבר שלקח מהעבודה או שבדרך הידועה של הורדת טורנט ושימוש באיזה keygen/keymaker..

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

אז כן, אם אתה צריך להקים אצלך למטרת טסטים או למטרת מעבדה בבית מערכת כמו vSphere עם vCenter, אז אתה יכול למצוא לך פתרון כלשהו.

אבל מה עם המוצרים האחרים? נניח ואתה רוצה להשתמש ב-VSAN בבית שלך, או שאתה מעוניין להשתמש ב-VMWare Horizon, או להכיר מה זה לכל הרוחות ה-vRealize, למה משמש vCloud? טכנית אתה יכול לקבל 30-60 יום רשיון Evaluation, אבל אחרי זה המערכת לא תתן לך להיכנס (אלא אם תתקין אותה מחדש). חושבים שטורנטים יעזרו לכם כאן? כי סביר להניח שלא תמצאו שום keygen שיוצר לזה מפתחות.

ב-VMWare החליטו לתת לזה פתרון.

הפתרון נקרא VMUG Advantage. מדובר בעצם בקבוצות (User Groups) שמדברות ונפגשות בכל העולם ומשוחחות על מוצרי VMWare וב-VMWare מעוניינים לצ'פר את המצטרפים. לשם כך יש לשלם סכום של 200$ לשנה.

ומה נותן לך המנוי הזה? טוב ששאלת 🙂

המנוי הזה נותן לך דבר שנקרא EVALExperience ועם EVALExperience אתה מקבל רשיון ל-365 יום למגוון מוצרים:

vmug

(שימו לב – כל המוצרים הם הגרסאות האחרונות – כך שאין vSphere 5.5 וגם אם תורידו מאתר VMWare, המפתח לצערי לא ממש יעבוד)

בנוסף, המנוי מעניק לך מספר דברים מעניינים נוספים כמו:

  1. 20% הנחה על קורסים (Online או offline)
  2. 20% הנחה על עלות הבחינות
  3. 50% הנחה על VMWare Fusion או VMWare Workstation האחרון
  4. נוסע לכנס של VMWorld? יש לך $100 הנחה לכנס
  5. גישה בחינם לתכנים מ-VMWorld 2015 (ללא VMUG Advantage המחיר הוא $699)
  6. 35% הנחה על VMWare Lab Connect (בשביל לנסות א הארכיטקטורה שאתם מתכננים)
  7. וכמובן הזמנות לכנסים של VMWare בישראל (מתי שהם יקיימו אותם…)

שווה $200? לדעתי כן

כל זה כמובן מגיע עם הגבלות די פשוטות:

  1. אין להשתמש ברשיון למטרות פרודקשן. רוצה להקים LAB בבית? בכיף. למטרת טסטים? אהלן וסהלן. פרודקשן? VMWare אוסרים על כך.
  2. אתה לא זכאי לקבל תמיכה, לא טלפונית ולא דרך מערכת הטיקטים שלהם. יש לך בעיה? תעבור דרך הפורומים השונים.
  3. אין אפשרות לקבל גרסאות מוצרים קודמות או מפתחות למוצרים ישנים. (בעסה!)
  4. כמות ה-Hosts מוגבלת ל-3 שרתים (עד 2 מעבדים פר שרת).

ויש גם הנחה שמתאימה ל-Corporates: אם החברה שלכם מחליטה ככה ברגע שהיא חטפה מצב רוח של נתינה – לקנות מספר מנויים ל-VMUG, אז אפשר לקבל הנחות כמו 2 משתמשים – המחיר יורד ל-180$, 3 משתמשים זה יורד ל-170$, אז אולי כדאי לדבר עם הבוס…

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

משהו אחד לסיום: לא, אני לא מקבל שקל מכל הפוסט הזה ומההפניה הזו, כך שאני לא מרוויח מזה כלום. תהנו 🙂

על 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 יכול להוות פתרון די טוב.

על 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 ולהפעיל אותה מחדש).

כמה דברים על VDI – תוספות

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

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

  • תמיכה הרבה יותר גדולה ב-Clients מסוגים שונים (מטלפון סלולרי ועד כרומבוק, כולל הפצות לינוקס שונות, אנדרואיד, iOS וכו')
  • תמיכה בדסקטופים שאינם מיקרוסופט (דסקטופ מבוסס לינוקס)
  • מוצרים משלימים מהחברה עצמה שנותנים בעצם פתרון יותר "בוגר" כפתרון VDI
  • לא חשוב מה פתרון הוירטואליזציה שתשתמש – בין אם זה Hyper-V, XenServer או ESXi (ואפילו KVM) – ל-Citrix זה לא ממש משנה (אם כי תמיכה רשמית תקבל רק לשלישיה שציינתי לעיל)

מבחינת הפתרון של מיקרוסופט, הפתרון שלהם מתבסס על כך שתריץ את הכל אך ורק תחת הכלים שלהם. וירטואליזציה? Hyper-V. אפליקציות ודסקטופים? תחת שרות RDS בלבד. פרוטוקול תצוגה? RDP בלבד, כך שאם אתם חברה שכבר בין כה מריצים את כל הוירטואליזציה שלכם רק ב-Hyper-V, מעבר לפתרון VDI יהיה קל יותר לכם אם תשתמשו בפתרון VDI של מיקרוסופט (כמובן שתצטרכו תשתית הרבה יותר רצינית מבחינת דיסקים, מכונות ל-compute ועוד – אבל את זה תצטרכו בכל פתרון VDI), כך שהפתרון של מיקרוסופט יותר קל למימוש ללא צורך ברכישת אפליקציות נוספות וכך מיקרוסופט יוצרת "נעילה" אצל הלקוחות והיציאה מה"נעילה" הזו אינה קלה. (אם כי קשה גם לצאת מהפתרונות של המתחרים).

גם לפתרון של VMWare יש יתרונות לא רעים כלל וכלל. יש לך כבר שרתים שמריצים RDS? מצוין, תתקין עליהם Agent של VMWare View והמשתמשים שלך יוכלו להתחבר ישירות לכל האפליקציות שביצעת להן Publish, או למכונות דסקטופ וירטואליות קיימות (אם כי את המכונות דסקטופ הוירטואליות מומלץ לך להקים מחדש עם ה-View). בפתרון של VMWare הקמת מכונות וירטואליות יכולה להתבצע במגוון אפשרויות, החל בהקמת מספר מכונות וירטואליות סטטיות שמשתמשים מתחברים אליהן בצורה קבועה, ועד מצב שהמערכת משתמשת ב-Golden Image שאליו היא מחברת דיסקים זמניים ובכך היא תקים VM חדש בכל פעם שמשתמש עוזב (וישנן אופציות נוספות כמובן) תוך שניות ספורות. גם תהליך העדכון למכונות הוא קל מאוד ותהליך הלימוד של View לא יקח יותר מיומיים (כל עוד יש למנהל פתרון הוירטואליזציה ידע ברמה של VCP). אם יש לחברה סניפים, פתרון ה-PCoIP נותן פתרון יעיל ודינמי (בהשוואה ל-RDP) שיודע להתמודד יפה עם רוחב פס משתנה, עם הצפנה מובנית בפרוטוקול עצמו (גם RDP תומך בהצפנה, PCoIP מוגדר עם הצפנה כברירת מחדל), אין צורך ב-Wan Optimizer (אפשר לקרוא עוד על כך ואפשרויות נוספות כאן), ומבחינת כמות השרתים הנוספת שצריך כדי להקים ולנהל את ה-View עצמו (לא כולל ה-VM של הדסקטופ) – הכמות היא קטנה (יחסית, יחסית).

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

  • מבחינת מחיר (שוב, אינני מדבר על מחירי ברזל מבחינת compute ו-storage – את זה תצטרכו לרכוש בכל פתרון שתבחרו) – הפתרון של מיקרוסופט הוא הכי זול (תצטרכו CAL פר משתמש או ציוד). סביר להניח שתצטרכו לשלם על רשיון מערכת הפעלה לדסקטופ (רשיון ה-OEM לא יעזור למיטב ידיעתי, אבל את הרשיון הזה תצטרכו לשלם בכל פתרון VDI.
  • מבחינת קלות תפעול והקמה, הפתרון של מיקרוסופט קל למימוש, אך גם הפתרון של View קל למימוש ואם אתם כבר משתמשים ב-ESXi, אז תוכלו לבקש ממי שמוכר לכם את הרשיונות מחיר מיוחד (עם האיום של לעבור לשכנים ממול 🙂 ) ובכל מקרה אם תרצו לרכוש את הפתרון של VMWare אל תרכשו את הרשיונות בחנות של VMWare, מנסיון – המחיר יכול להיות נמוך בהרבה מהמחיר המוצג באתר (3000 יורו ל-10 משתמשים בגירסת ה-Enterprise).
  • אם אתם מקום שמשתמש ב-Clients שונים (או חושבים להכניס Clients נוספים חוץ מעמדות PC שיהיו "טיפשות") – אז מומלץ להסתכל על הפתרונות של VMWare ושל Citrix. נכון, הרוב תומך היום ב-RDP, אבל המתחרים למיקרוסופט משקיעים הרבה יותר ב-Clients ממיקרוסופט עצמה, במיוחד בתמיכה בציודים כמו Zero Client או כרומבוקים (פוסט על כרומבוקים בחברות יופיע כאן בקרוב).
  • אם אתם רוצים להעביר סביבות לינוקס ל-VDI (יעיל במיוחד לפיתוח, תוכנות CAD וכו') – גירסה 6 של View והגירסה הקרובה של Citrix תומכות בכך, הפתרון של מיקרוסופט לא תומך בכך.
  • אם אתם רוצים להעביר/להקים מכונות VM שמריצות תלת מימד/עריכת וידאו ל-VDI, הפתרון של Citrix ושל VMWare יתאימו לכך (יהיה צורך ב-GRiD של nVidia לשם כך). הפתרון של מיקרוסופט לא תומך בכך (זה יתמך בגירסה הבאה).
  • אם יש לכם סניפים מרוחקים שמחוברים ב-DSL או בפתרון תקשורת אחרת, פתרון PCoIP יכול להוות יתרון הואיל ואין צורך בפתרונות WAN Optimization.
  • נקודה חשובה: ראיתי את העניין הזה בקופות חולים, בחברות אשראי, בחברות ביטוח, בבנקים וכו' – אם אתם נותנים פתרון VDI, תעיפו את ה-PC והטמיעו Thin Client. מחשב PC צורך יותר חשמל מ-Thin Cliernt במיוחד כשמדובר במאות מחשבי PC בבניין. פתרון Thin Client מבוסס ARM צורך פחות מעשירית ממה ש-PC צריך מבחינת חשמל, ואין צורך בהחלפת מאווררים.
  • אם אתם חושבים על מעבר ל-VDI, כדאי לשקול פתרון מבוסס Hyper Converged, כך שלא תצטרכו להשקיע עוד מאות אלפי דולרים על Storage חדש. ישנם מספר פתרונות כאלו (כתבתי על כך כאן), וכל עוד אינכם "נעולים" אך ורק על Hyper-V, תוכלו להרים 2-3 שרתים כאלו ולראות איך זה עובד מבחינת מחיר וביצועים. אגב, VSAN 6 של VMWare יצא לאחרונה, והתמיכה שלו ב-Flash הרבה יותר טובה (עכשיו הוא תומך ב-Flash לא רק כ-Cache).

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