תגית: VMWare

על Virtual Flash Cache ב-ESXI 5.5

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

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

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

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

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

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

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

vfrc

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

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

vfrc2

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

vfrc3

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

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

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

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

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

כמה מילים על VDI

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

למי שלא מכיר את רעיון ה-VDI, הנה הסבר בכמה מילים: VDI (ר"ת Virtual Desktop infrastructure) היא בעצם דרך/שיטה חדשה לתת למשתמשים דסקטופ משלהם. בניגוד לדרך שרוב החברות והארגונים משתמשים כיום, עם VDI למשתמש הפשוט אין יותר PC (או שיש לו Thin Client או שה-PC שלו "מומר" למערכת הפעלה שכל תפקידה הוא להפוך ל-Thin Client), וכל ה-Windows רצים כמכונות וירטואליות על שרתים שמריצים Hypervisor כמו vSphere, Hyper-V או Xen (וגם KVM שאליו אתייחס בהמשך). אין יותר טכנאים שרצים בין המשתמשים להחליף דיסקים קשיחים או תקלות חומרה אחרות וכל האחסון של המכונות הוירטואליות נמצא על NAS או SAN חזקים מבוססי SSD.

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

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

מנהלי רשתות ותיקים יכולים להרגיש תחושה של Deja Vu. כבר היינו ב"סרט" הזה בעבר. חברה כמו Citrix מוכרת קרוב ל-20 שנה פתרונות קרובים לכך (פתרונות כמו XenDesktop ו-XenApp לדוגמא) ומיקרוסופט מוכרת פתרון די דומה (שברובו בין כה נמכר למיקרוסופט ע"י Citrix) ב-8 שנים האחרונות לפחות. נכון, לא היתה וירטואליזציה כמו שיש כיום והכל רץ על שרתים עם שרותי Remote Desktop Service (מה שהיה בעבר Terminal Services). אצל 2 החברות, הפתרון היה שרת Windows Server שהמשתמש היה מקבל עליו Session עם אפליקציות שהיו מותקנות בצורה מרוכזת והמשתמשים היו מקבלים מעין Shortcuts. אגב, הפתרון הזה קיים יותר מ-30 שנה בעולם היוניקס עם X server/Client.

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

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

  • מיקרוסופט כוללת פתרון VDI בתוך Windows Server 2012, כאשר הפתרון יכול להיות כמו המצב ה"קלאסי" (שרת שמריץ אפליקציות והמשתמשים מתחברים רק לסשן עם אפליקציה) או מצב VDI מלא כאשר מכונת Windows וירטואלית רצה פר משתמש עם Hyper-V, והמשתמש מתחבר דרך Thin Client עם RDP למכונה הוירטואלית שלו. לפתרון הזה יש יתרון שעקומת ההקמה/מעבר הוא די קטן (כל עוד יש לך ברזלים או תקציב לערימת ברזלים ואחסון רציניים). המחיר הנוסף (חוץ מהשרתים והאחסון) הוא על רשיונות ל-RDS (פר משתמש).
  • ל-VMWare יש את VMWare View (שנקרא כיום VMWare Horizon). בפתרון הזה ישנו פתרון PCOIP והיתרון שלו הוא שאפשר לחבר יותר מסכים (עד 4) עם רזולוציה יותר גבוהה פר מסך (עד 2560X1600), ויש תמיכה ב-OpenGL (שלא קיימת בפתרון של מיקרוסופט). הפתרון של VMWare מצריך תשתית של vSphere שעליה ירוץ Horizon. הפתרון גם תומך ב-RDP, אם כי התמיכה אינה כוללת תמיכה מתקדמת של RDP כמו RemoteFX (וגם על כך יש סייג – VMWare View 6 יכול "לתפוס טרמפ" על שרת RDS ולשמש בעצם כ-Gateway).
  • הפתרון של Citrix הוא XenDesktop (שמורכב מכמה חלקים) והוא מאפשר פתרון די זהה למה שמיקרוסופט מציעה, רק שהפתרון של Citrix יכול לרוץ על HyperVisor מסוגים שונים כולל Hyper-V, vSphere ו-Xen.

מבחינת דרישות חומרה – כל הפתרונות הנ"ל דורשים כמו תשתית וירטואליזציה מאוד גדולה עם עדיפות לאחסון ב-SSD. (מה לעשות, כל VM דסקטופי בממוצע כותב 75% מהזמן שהוא חי וקורא 25% לערך), כך שיש צורך לא רק בשרתים חזקים אלא גם בפתרון אחסון גדול מאוד, ומאוד מומלץ שהשרתים יחוברו בתשתית של 10 ג'יגהביט (VDI מצריך המון משאבי רשת).

דרישה נוספת ויחודית בתחום ה-VDI זה GPU Hardware Accelerator. אם המשתמש גולש הרבה או שיש לו המון פעילות בדסקטופ (ומה לעשות, אתרים ישראליים "טוחנים" את ה-CPU עם פרסומות Flash) – השרתים שלך יהיו עמוסים (חשוב לזכור: 30 פריימים לשניה ברזולוציה ממוצעת של 1280X1024 דורשת לא מעט משאבים, במיוחד אם המשתמש השאיר אתר חדשות ישראלי ממוצע ב-TAB או חלון פתוח – ה-Flash "יטחן" את מעבדי ה-Xeon שלכם, ועוד לא דיברתי על ניגון וידאו!). במקרה של מיקרוסופט, החברה ממליצה בחום להכניס כמה כרטיסי GPU לשרתים על מנת להוריד את העומס שקשור ל-Display (כך שהכרטיס הגרפי בשרת יבצע את עבודת רינדור המסך וישלח את התוצאה ב-RemoteFX [שהוא חלק מ-RDP] ל-Thin Client).

ב-VMware Horizon אין אמנם דרישה לכרטיסי GPU שישבו על השרת אלא אם המכונות הוירטואליות יריצו אפליקציות גרפיות כבדות כמו פוטושופ/עריכת וידאו/3D ועוד או במקרים בהם יש לך יותר מ-100 מכונות דסקטופ וירטואליות. במקרים כאלו תצטרך או להכניס כרטיסים מבוססי OpenGL כמו Quadro של nVidia או להסתכל על פתרון ה-Teradici PCoIP Hardware Accelerator. במקרים בהם יש לך אלפי מכונות וירטואליות שצריכות עבודה גרפית אינטיסיבית, תצטרך לשוחח עם nVidia לגבי פתרון קופסאות ה-GRiD שלהם. זול – זה לא.

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

מוצר שהיה עד לפני חודשיים ל-Citrix (לצערי הם הרגו את המוצר) שנקרא VDI-in-a-box. המוצר היה Appliance וירטואלי שרץ על התשתית הוירטואלית שלך, היה קל מאוד להגדרה (לוקח משהו כמו 20 דקות להגדיר ולהכין הכל) והיה מאוד מתאים להרצה במקומות קטנים (כמה עשרות דסקטופים וירטואליים עד מאות בודדים). ב-Citrix הודיעו שאת הטכנולוגיה הם ישלבו בפתרון Xen Desktop בעתיד.

KVM: ל-KVM יש פתרון שהוא "בדרך". ניתן כיום להקים פתרון VDI מבוסס KVM כל עוד יש לך כלי ניהול ל-KVM שידע להעביר מכונות בזמן עומסים לשרתים פנויים יותר (כמו Convirt). הבעיה המרכזית עם KVM היא שאין אפשרות להכניס GPU לשרתים ולבצע offload של פעילות גרפית לכרטיסי GPU כמו המתחרים, ושוב – יש Flash פועל אצל המשתמש – תראו את ה-Xeon "מזיע" ממאמץ ולכן KVM כיום יכול להתאים לפתרון VDI אם מדובר ב-pilot/POC כשמדובר בכמות קטנה (כמה עשרות מקסימום) של מכונות דסקטופ וירטואליות.

אחת השאלות שנשאלתי לא פעם בעבר לגבי עניין ה-VDI היא מדוע לא קיים פתרון שיודע להשתמש במעבד הגרפי שקיים ב-Client. אחרי הכל, אפילו טאבלטים ומחשבים שהם Low end ממוצעים כיום יכולים לנגן וידאו ולהראות גרפיקה בצורה חלקה ויפה. התשובה לכך היא שפעילות כזו תצטרך תקשורת ישירה ורצופה 30 פעם בשניה בין הכרטיס הגרפי ב-thin client ל-CPU שנמצא בשרת, מה שמצריך המון רוחב פס ו-Latency נמוך ואת זה לא ניתן בקלות לפתור. הפתרונות של Citrix ושל VMWare נותנים פתרון עקיף, וברוב הזמן למשתמש ממוצע בחברה זה יספיק, אבל במקרים של שימוש גרפי רציני, הפתרון מגיע מפרוטוקולים קנייניים שמשתמשים ב-GPU שרץ על השרתים במקום להשתמש שימוש מלא ב-GPU שקיים ב-Thin Client.

אז האם כדאי לעבור ל-VDI? לעניות דעתי – תלוי.

אם יש בארגון שלכם סניפים – פתרון VDI יכול לסייע (במיוחד כתחליף ל-Terminal Services, לתשומת לב חברות תקשורת סלולריות מסויימות…), פרטוקולים כמו HDX או RDP או PCOIP יודעים להתמודד להתמודד עם Latency תלת ספרתי. אם יש לכם קבוצה גדולה של משתמשים שמריצים אופיס ודפדפן – אפשר בהחלט לשקול להעביר אותם לפתרון VDI (לא לשכוח לבטל להם Flash, בין כה השימוש העיקרי בו היום הוא פרסומות). לעומת זאת, אם יש לכם בארגון כמה מאות/אלפי משתמשים ואתם חושבים על מעבר ל-VDI, אני ממליץ לבדוק את השיקול הכלכלי שוב, אני אישית מתקשה להאמין שתמצאו לכך הצדקה כלכלית רצינית.

עוד קצת על KVM

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

לכן בפוסט זה אני אדבר על KVM מחוץ ל-Scope של Open Stack.

הדבר הראשון שחשוב להבין לגבי KVM הוא שבניגוד לפתרונות וירטואליזציה אחרים, KVM אינו פתרון רק עבור X86/X86-64. טכנית, KVM מבוסס על אפליקציה שנקראת QEMU (שאגב, ממשיכה להיות מפותחת וגרסאות חדשות יוצאות תדיר, רק לפני 10 ימים יצאה גירסת RC3 לגירסה 2.3). היחוד של QEMU הוא שאפליקציה מאפשרת לך להריץ מערכות שונות על מעבדים שונים. הדוגמא הכי פשוטה וידועה היא הרצה של מערכת מבוססת ARM על PC (כפי שהיא קיימת באנדרואיד SDK), אבל אתה יכול להריץ גם מערכת Solaris של 64 ביט על אמולציה של מעבד Sparc (במקרה זה Niagra T1) על ה-PC שלך. אתה יכול להריץ גם מערכות שונות של MIPS (שוב, על ה-PC שלך דרך QEMU), ואפשר גם להריץ אפילו מערכת S390s עם Debian לדוגמא. גמישות היא הצד החזק של QEMU.

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

הדוגמא הכי פשוטה היא שימוש במעבדים שאינם X86-64, כמו ARM. בזמן הקרוב יצאו שרתים שמבוססים לא על מעבדי Xeon אלא על מעבדים של חברות שונות המבוססים ARM. אחת הפונקציות שחברות רבות רוצות הן וירטואליזציה על אותו מעבד ARM כדי להריץ מערכות הפעלה שונות (נכון, טכנולוגיית קונטיינרים קיימת גם ל-ARM אבל לפעמים יש צורך להריץ מערכת הפעלה עם Kernel שונה), במקרים כאלו ישנה גירסת KVM ל-ARM שרצה על ה"ברזל" ואיתה מריצים מערכות הפעלה אחרות שמבוססות ARM. גם למעבדי MIPS יש KVM.

מהצד היותר "גבוה" יש גירסת KVM למערכות הענקיות של IBM מסידרת System Z (ה-Main Frame), ושוב, גם כאן, ה-KVM נותן לך אפשרות להריץ מערכות לינוקס שונות כאשר כל אחת מהן עצמאית לחלוטין עם Kernel וספריות משלה.

אחד הדברים שאנשים רבים לא מודעים לכך, הוא ש-KVM אינו מתחרה ישירות בפתרונות וירטואליזציה מתחרות כמו vSphere או Hyper-V כפתרון מלא. KVM יכול לרוץ מתוך סקריפט Shell פשוט, וכל עוד יש איזה Image לעשות ממנו Boot (או PXE) וכרטיס רשת (אפשר להשתמש ב-Bridge) בצורה יפה, ללא צורך בניהול כלשהו. אם אתה לעומת זאת מחפש להריץ מספר מערכות KVM על שרת, אז כדאי להשתמש בשרות משלים שמבוסס על ספריה בשם libvirt עם אפליקציות כמו Virt-Manager ועם ספריה כמו libguestfs שמאפשרת לך לבצע פעולות שונות למכונה הוירטואלית ול"דיסק" שלה. ישנן עוד עשרות פתרונות פתוחים או סגורים לניהול מערכות KVM, אך KVM עצמו אינו תלוי בהן, כלומר KVM הוא רק כלי, ולא הפתרון כולו.

הנה נקודה שאולי תעניין אנשים שמתעניינים בהרצה של אפליקציות כבדות כמו פוטושופ, עריכת וידאו או הרצת משחקים: כשזה מגיע לוירטואליזציה ודימוי (Emulate) של כרטיס מסך, הפתרון של KVM הוא פתרון די גרוע בהשוואה לפתרונות כמו VirtualBox או VMWare Workstation או Hyper-V. יחד עם זאת, היתרון הגדול של KVM הוא האפשרות למפות כרטיס גרפי רציני ישירות ל-VM (זה קיים גם בפתרונות וירטואליזציה אחרים, אולם ב-ESXi לדוגמא המערכת לא מאפשרת להשתמש בכרטיסים גרפיים ביתיים למיפוי ל-VM אלא אך ורק את הכרטיסים הגרפיים היקרים), כך שאם לדוגמא יש לך 2 מסכים גדולים שאתה רוצה להריץ עליהם מעת לעת עריכה גרפית או משחק ב-2 מסכים, אתה יכול לחבר מסך שלישי זול לחיבור ה-On-board בלוח האם, ולמפות את הכרטיס הגרפי היותר יקר עם 2 המסכים שמחוברים אליו אל ה-VM. מבחינת ביצועים, ההפרש נמדד באחוזים בודדים בלבד, כך שתוכל להנות מביצועים מעולים, ולאחר שתסיים עם ה-VM, תוכל להמשיך ולהשתמש במסכים לעבודה עם הלינוקס (שימו לב, בשיטה זו ה-VM רץ רק כמסך מלא או מסכים מלאים, לא כ-Window). את אותו טריק, אגב, ניתן לבצע גם עם 2 מסכים בלבד כל עוד מסך אחד מחובר לעיבוד הגרפי שקיים בלוח האם והשני לכרטיס הגרפי העצמאי.

אינני ממליץ לחברות להסתכל על KVM כפתרון חלופי (במובן של Drop-In) למערכות כמו vSphere או Hyper-V. פתרון מבוסס KVM יכול להתאים למוסדות גדולים אם הם משתמשים ב-KVM יחד עם מערכת כמו Open Stack, או שיש להם אנשי לינוקס שיכתבו את הסקריפטים/קוד שידעו להתממשק ל-libvirt ושאר ספריות. KVM יכול בהחלט להריץ מערכות לינוקס ו-Windows Server בלי שום בעיה, אולם אם משווים את זה לפתרונות כמו vSphere, ישנם חלקים רבים מהפצת הלינוקס שאתה משתמש שתצטרך להטמיע אותם כדי לקבל פתרון קרוב וזו לא עבודה שאנשים עם נסיון מועט בלינוקס ידעו לבצע אותה. אם אתם רוצים להטמיע KVM בארגון שלכם, מומלץ להתחיל עם משהו פשוט (וזה לוקח זמן) ורק לאחר שאתם מרוצים, אפשר להתחיל לחשוב על הטמעה של יותר ויותר חלקים (וכן, אפשר להמיר די בקלות מכונות VM מבוססות ESXi ל-KVM. מכונות מבוססות Hyper-V – קצת יותר מסובך). אם אתם רוצים להטמיע פתרון מבוסס KVM ויותר מסחרי מרד-האט, אתם יכולים להסתכל על RHEV (ובגירסת קוד פתוח – oVirt). אם אתם בעניין של Hyper Converge, אז מומלץ להסתכל על הפתרון של חברת Scale Computing.

נקודה נוספת שהח"מ נשאל עליה שוב ושוב: VDI עם KVM. יש התקדמות בנושא (ובמיוחד בפרוטוקול העברת התצוגה SPICE) אבל עדיין – זה לא מתאים (לעניות דעתי) לפרודקשן.

לסיכום: KVM הוא רק כלי. כלי טוב ועוצמתי להרצת VM, אך זהו כלי שצריך להשקיע לא מעט כדי ללמוד אותו ולהתנסות איתו ובתמורה אתה יכול לקבל ביצועים ששווים למה שמקבלים עם ESXi. מכיוון שמדובר רק בכלי ולא בסביבה שלמה, מומלץ להשקיע (למעוניינים) להסתכל על הספריות בקישורים לעיל כדי להיכנס לעולם ה-KVM.

הכנת VM מבוסס לינוקס לשימוש אצל ספקי ענן

חברות רבות משתמשות כיום בשרותיהן של ספקי ענן (אמזון, גוגל, Azure, Rack Space, Digital-Ocean ועוד) ובמקרים רבים אנשים מקימים לעצמם את השרתים בשיטה הקלאסית: בוחרים מערכת הפעלה מהתפריט שהספק מציע (או משתמשים ב-Image שהספק מציע), ולאחר מכן הם מבצעים כניסת SSH, ומשם הם ממשיכים להתקין חבילות, לבצע הגדרות, להעלות סקריפטים, להוסיף משתמשים וכו' וכו'.

שיטה זו היא שיטה מעולה – אם כל מה שיש לך זה שרת יחיד או כמות Fixed של שרתי VM. אחרי הכל, חברות רבות מעדיפות להקים מספר קבוע של X שרתים ועם זה הם יתמודדו, יגדירו Flow וכו'.

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

הבעיה בהקמת שרת נוסף היא הזמן שלוקח לשרת כזה "לקום". הבלוג של חברת Flycops נותן דוגמא מצוינת לכך. במקרה שלהם, כל שרת חדש שהיה מוקם במסגרת ה-Scale Up לקח לו לא פחות מ-6 דקות עד שהוא היה מסוגל לקבל גולשים. זה אולי נשמע זמן קצר, אבל אלו 6 דקות שאתם כחברה תפסידו גולשים שמגיעים מכל מיני מקומות שונים (גוגל, בלוגים, אתרים שמפנים אליכם, לינקים מאימיילים וכו') וחבל.

לכן, במקרים של Scale Up שהמערכת שתשתמשו תרים עוד ועוד שרתים בהתאם לקריטריונים של עומס – כדאי לתכנן מראש Image שתבנו שהוא יעלה, שימשוך הגדרות מסויימות ושיהיה זמין לקבל גולשים.

איך עושים זאת? די פשוט:

  • בשלב ראשון נשתמש במערכת וירטואליזציה שיש לנו מקומית. זה יכול להיות ESXi, זה יכול להיות VMWare לדסקטופ, זה יכול להיות VirtualBox או יכול להיות (ומה שהח"מ משתמש) KVM.
  • נקים Guest חדש ונשתמש ב-ISO של הפצת הלינוקס המועדפת עלינו. מבחינת גודל דיסק, לא מומלץ "להשתולל" (במיוחד לאלו שאינם יכולים להקים מכונה עם Thin Provisioning) – ברוב המקרים 8-10 ג'יגה אמורים להספיק בהחלט. מבחינת Partitions, כל אחד יכול להחליט באיזה שיטה ללכת, עם או בלי LVM. אני ממליץ לבצע Partition יחיד (flat) שהכל ישב שם. חשוב: מבחינת חבילות לא מומלץ להתקין GUI גרפי, זה סתם יתפוס מקום ומשאבים.
  • לאחר שסיימנו עם ההתקנה נפעיל את המכונה הוירטואלית, נתחבר אליה (ב-SSH) ונוודא שיש לה חיבור לאינטרנט.
  • בשלב הבא אנחנו צריכים להתקין את האפליקציות שאנחנו צריכים שיהיו ב-VM. אני ממליץ לבחור באחת מהפתרונות הבאים:
    • יש את Packer (שכתובה ב-Go – תודה לעמוס על התיקון) שאיתה אפשר לבנות את כל ההתקנה שאתם צריכים על ה-VM. היא מתאימה מאוד לחובבי JSON.
    • יש את Cloud-Init שכתבו קנוניקל ורד-האט "אימצה" בשמחה. היתרון שלו שהוא הרבה יותר ידידותי לאנשי סיסטם שלא מעוניינים להתעסק יותר מדי "בקרביים". עם Cloud-init מגדירים מה המשתמשים שיהיו, מה החבילות שצריך, וב-reboot הבא המערכת כבר תעשה את הכל לבד.
      שימו לב: את Cloud-init יש להתקין בתוך ה-VM. מכיוון שהוא נמצא ב-REPO של EPEL, יש לבצע yum install epel-release (לא צריך את ה-URL עם הגירסה האחרונה אם אתם משתמשים ב-CentOS, זה אוטומטי), ולאחר מכן yum install cloud-init.
    • אפשרי לעבוד עם Puppet – כל עוד אתה יודע לעבוד ללא Puppet Master.
    • חשוב מאוד – בצעו update לאחר שהתקנתם את מה שרציתם. המכונות שיבוססו על ה-image הזה ישרתו אנשים מבחוץ ולא נעים לחטוף פריצה רק בגלל ששכחנו לעדכן את כל ה-DEB/RPM.

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

  • כבו את המכונה הוירטואלית וגשו למחיצה שבה היא נמצאת.
  • התקינו את חבילת libguestfs בהתאם להפצת לינוקס שאתם משתמשים בה (מחוץ ל-VM)
  • מכיוון שיכול להיות שהמכונה כוללת דברים שאין לנו צורך בהם (מפתחות שונים שהשתמשנו כדי להעתיק ממקומות אחרים, תעודות SSL, קבצי מטמון וכו') נשתמש בפקודה virt-sysprep כדי לנקות את ה-Image. הריצו את הפקודה virt-sysprep -a image.vmdk (כאשר image.vmdk זהו שם ה-image של ה-VM שלכם). פעולת ה-virt-sysprep תנקה את כל מה שלא צריך וגם תמחק את כל ה-MAC Address שיש לכרטיסי רשת.

לפני שאנחנו מעלים את ה-image לענן, חשוב לבדוק שאתם מגדירים partitions ודברים נוספים (kernel modules, הגדרות שונות) לפי מה שהספק ענן שלכם מבקש, וכל ספק עם השטיקים שלו.

אם אתם משתמשים ב-Ravello (כדי לבצע testing, PoC):
אנחנו צריכים להקטין את ה-image לגודל קטן (מכיוון שהתקנות יוצרות קבצים זמניים שנמחקים, ה-image בעקרון אינו קטן בצורה אוטומטית). לשם כך נשתמש בפקודה virt-sparsify (שוב, לשים לב שהמכונת VM כבויה) בפורמט הבא:
virt-sparsify image.qcow2 final.qcow2
(שוב, image.qcow2 הוא שם המכונה שלכם כרגע, final.qcow2 זה השם image לאחר ההקטנה).

אם אתם משתמשים ב-Google Compute Engine
במקרה זה מומלץ לעקוב אחר ההוראות כאן כיצד להעלות את ה-image ומה מומלץ שיהיה בו.

אם אתם משתמשים בשרות של אמזון
במקרה של שרות באמזון, לצערי בשלב זה הם אינם מקבלים קבצי qcow2 ולכן תצטרכו להמיר את ה-image שלכם ל-VMDK (ההוראות הן כמו הקישור לעיל, רק שבמקום O qcow2- תצטרכו לכתוב
O vmdk- ).

כעת נוכל להשתמש ב-image שהעלינו כ-Template. מומלץ לשמור את ה-image היכן שהוא ולעדכן אותו אחת לתקופה ולהעלות אותו שוב (לאחר שעבר virt-sysprep) לענן ולהשתמש ב-image החדש כ-template.

בעניין Hyper Converged

מי שקורא חדשות טכנולוגיה המיועדות ל-IT/CTO/CIO בוודאי שמע בשנתיים-שלוש האחרונות את המושג Hyper Converged (או HC בקיצור), מושג שיותר ויותר חברות משתמשות בו כדי להציע משהו חדש למנהלי ה-IT.

על מנת להבין את עניין ה-HC, כדאי שנראה מה יש ברוב החברות כיום:

כשזה מגיע לוירטואליזציה (ואין זה משנה איזה פתרון Hypervisor אתם משתמשים), בד"כ יש מספר שרתים שהם ה-Host, והם מחוברים ל-Storage כלשהו ומשתמשים בשרותים כמו NFS או iSCSI (או SMB במקרה של Hyper-V) כדי לאחסן קבצים של המערכות הוירטואליות. במקרים מסויימים משתמשים בדיסקים שנמצאים מקומית בשרת עצמו כשמדובר על שרת (Host) שמריץ מערכות וירטואליות עצמאיות או במקרים שאין Storage גדול רציני.

כשאנחנו מעוניינים ליצור אשכול לצרכים שונים (High Availability, Fault Tolerance וכו'), אנו צריכים 2 שרתים (במינימום) שהם זהים מבחינת החומרה ו-Storage חיצוני שיהיה מחובר ל-2 השרתים, ואנו מגדירים דרך הפאנל של הויראטואליזציה (כמו vCenter או VSA/VCSA) את 2 השרתים כאשכול. יש כמובן "ערימה" של דברים להגדיר כמו סוג האשכול, הגדרות אחסון, כתובות, קבוצות פורטים וכו' – אבל זה בעקרון Cluster.

בשיטת ה-HC הדברים שונים לחלוטין: בשיטה זו אין לנו צורך יותר ב-Storage חיצוני. במקום זה השרתים יהיו עם דיסקים מסוגים שונים (SSD, דיסקים מכניים מבוססי SAS/NL-SAS/SATA) וכל השרתים יהיו מחוברים באשכול למתג של 10 ג'יגהביט (מינימום, כאשר כל הכניסות במתג הם 10 ג'יגהביט). על השרתים מותקנת מערכת וירטואליזציה (בד"כ vSphere אך גם KVM נתמך בחלק מהמקרים) ובנוסף מותקן VM מיוחד בכל שרת פיזי שמתחבר ישירות לדיסקים והוא מנהל אותם (ולא ה-vSphere). בשיטה זו הנתונים נכתבים לכל הדיסקים בכל השרתים והמערכות הוירטואליות רצות על השרתים כאשר האחסון הוא על הדיסקים המקומיים וכש-VM "עובר דירה", חלק מהנתונים עובר מהדיסקים המכניים (האיטיים ויתר) ל-SSD וכך ניתנת לנו האפשרות לבצע Live Migration או כל פעולת High Availability אחרת שנרצה (HA, FT וכו'). במצב כזה (וברוב מערכות ה-HC) אנחנו יכולים לסבול מצב ששרת פיזי אחד נופל מבלי שאף מערכת וירטואלית תיפול.

ישנן מספר חברות שמוכרות מוצרי HC, נתמקד בשלישיה המובילה: Nutanix, Simplivity ו-EVO:Rail.

ל-Nutanix יש פתרונות מ-2 סוגים: הפתרון המבוסס תוכנה (אתה מתקין על השרת שלך) או פתרון חומרה (אתה קונה את השרת מהם), כאשר בפתרון שלהם חייבים לפחות 3 שרתים. ההתקנה עצמה היא קלה (לוקח בערך רבע שעה) ויש לך ממשק GUI נחמד ובנוסף יש לך CLI (שהוא בעצם לינוקס עם אובונטו, ככלל – כל המערכת היא בעצם סקריפטים של לינוקס + מודולים קנייניים שלהם) ויש גם ממשק RESTful API למפתחים. המערכת קלה (יחסית) ללימוד, אך היא אינה מחליפה את הצורך ב-vCenter/VSA אם אתה משתמש בפתרון מבוסס VMWare. ניתן במקום vSphere להשתמש בוירטואליזציה הפתוחה KVM אם כי בשלב זה הם עדיין לא מאפשרים להריץ מכונות VM מבוססות Windows (וגם ה-KVM שיש להם די ישן למען האמת, מגירסת CentOS 6.5).

הפתרון השני הוא של Simplivity וגם הוא מאפשר לך לבצע Cluster אך עם טוויסט מעניין: אתה יכול להוסיף את הענן של אמזון כ"חווה" (DC) משלך ואתה יכול להעביר מכונות הלוך ושוב בין DC שונים, ובנוסף יש לך את הדברים שאתה רגיל אליהם מעולם ה-Storage כמו DeDup, Replication, Snapshots וכו' כאשר הדגש הוא בעצם לא "לחנוק" לך את רוחב הפס בין השרתים שיושבים אצלך בבניין לבין ה-DC האחרים. בניגוד לפתרונות המתחרים, הכמות המינימלית שאתה צריך זה שרת אחד.

הפתרון השלישי הוא של VMWare שנקרא EVO:Rail והוא מתבסס על פתרון ה-vSAN ש-VMWare מוכרת, רק שכאן מדובר על שרתים פיזיים שאתה רוכש מיצרנים שונים כקופסא סגורה. גם כאן, יש צורך ברכישה של מינימום 4 שרתים שישמשו כ-Block אחד.

למי שמעוניין להיכנס יותר לעומק ולקרוא על ההתקנה, השימוש, מה נתמך במה, אני ממליץ לקרוא את המאמר המעולה של בריאן סור על הפתרונות הנ"ל.

אז מה? להתחיל לארגן מכרז למכור את ה-Storage הגדול שלכם? ממש לא.

תחום ה-HC כרגע "שורץ" בפתרונות מחברות צעירות וחברות סטארט-אפ. Nutanix כרגע מובילה את שוק ה-HC עם שיווק מאוד אגרסיבי, אבל הפתרונות שלהם גם מאוד יקרים. כמה יקרים? 6 ספרות במונחים ישראלים ואם תרצה משהו יותר רציני כמו ארון שלם – 7 ספרות. החברות הגדולות המייצרות מוצרי Storage כבר לוטשות עיניים לעבר החברות הקטנות וסביר להניח שנשמע בקרוב על כמה רכישות, ומכיוון שתחום ה-IT הוא תחום שמרני, מומלץ לא לסגור עסקאות עתה אלא להמתין.

תחום ה-HC נותן פתרונות שיכולים מצד אחד לחסוך הרבה עבודה (תקים פעם אחת, תוסיף ניטור משלך ועדכונים מעת לעת – ואתה מסודר. תיאורתית לפחות), אבל מי שוותיק בתחום הזה יכול להיזכר בתקופות קודמות בהן גם חברות מכרו ל-IT מוצרים שנתנו "HC" בתחומים אחרים (זוכרים Self Healing?) וכעבור מספר שנים אותן קופסאות ישבו בחוות השרתים ו… צברו אבק. פתרונות ה-Storage שיש לנו כיום מלכתחילה לא תוכננו לאחסון דיסקים של VM והפתרונות שיש הם (בלי שאף אחד יודה בצורה רשמית) הם "hacks" רציניים (פתרון כמו iSCSI היה בכלל מדובר להתחברות ל-initiator יחיד, בינו ל-LUN שמוגדר ב-Storage, והשינויים ב-VMFS ש-VMWare עשו איפשרו לו להתחבר ל-2 שרתים במקביל, ו-NFS היה צריך גם שינויים ברמת ה-Storage בקוד על מנת לאפשר לו לעבוד טוב מול Hypervisor). פתרון טוב, לעניות דעתי, הוא פתרון Cluster אך מופרד ועדיף פתרון שמקובל על רובם או כולם: פתרון שיתן לנו לייצא מ-Cluster שמיועד ל-Storage איזה Block Device, אבל שיהיה בצורה טבעית ניתן לשיתוף בין Clients שונים לדוגמא, פתרון שאם אני מחבר אותו למערכת וירטואליזציה, שאינו צריך להמתין ל-Acknowledge שהתוכן נכתב לפני שהוא מאפשר למכונה הוירטואלית להמשיך לעבוד כרגיל.  אלו פתרונות שעדיין לא קיימים כיום בצורה יציבה ומלאה (הכי קרוב שידוע לי שקיים – זה Ceph). בעיה נוספת שקיימת עם פתרונות ה-HC הוא עניין הבטחון לגבי העתיד – מה תעשה אם אותה חברה שרכשת ממנה קופסאות מחר תיעלם או שיתגלעו ביניכם חילוקי דעות לגבי מחירי חידוש תמיכה?

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

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

טכנולוגיה אינה דת

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

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

ישנם דברים שיכולים מאוד להתאים לאיש IT מקצועי עם שנים רבות של נסיון שפשוט לא יכולים להתאים למשתמשים רבים. אני יכול לתת דוגמא פשוטה: אני כותב את הפוסט הזה עם מחשב ASUS ChromeBox שמריץ את ChromeOS שרוב הזמן אני עובד עליו. מדוע? כי אני מקבל את החוויה של שימוש בכרום תוך 6 שניות מהפעלת המכשיר, אין לי חשש מבעיה של תקלת אחסון (הכל בענן או ברשת) ואין שום דבר שיכול לגרום למכונה הקטנה הזו "להיתקע". אם אני צריך דברים יותר מורכבים, אז אני משתמש ב-Crouton באותה מכונה ואז יש לי בנוסף ל-ChromeOS אובונטו או Debian ובלחיצה על צירוף מקשים יש לי Shell כדי לעשות דברים פשוטים או מורכבים ואני אפילו יכול להריץ אפליקציות Android על ה-ChromeBox הזה ללא צורך במכשיר סלולרי או טאבלט.

האם אני ממליץ את הקונפיגורציה הזו לאנשי IT? אם הם הטיפוסים שאוהבים "לחטט" ו"לשחק" עם דברים – אז כן, בהחלט. האם אני ממליץ להעביר תחנות של מזכירות ומשתמשים קלים אחרים ל-ChromeBox? לא, כי אין עדיין ב-ChromeOS שום תמיכה פנימית ל-Active Directory, לניהול מרוכז עם כלי System Center של מיקרוסופט (שחברות רבות משתמשות בו), אין עדיין מספיק כלים שיכולים להחליף או לתת חוויית שימוש דומה בכלים שיש בעולם של מיקרוסופט למשתמש הסופי. היכן כן אמליץ להטמיע אותו למשתמשי קצה? באותן חברות קטנות שהחליטו להשתמש בשרותי Google Apps (או מה שנקרא היום Google for Work) ושכל העבודה מתבצעת דרך דפדפן. עלויות התחזוקה שם הן מאוד קטנות וגם אם מתקלקלת קופסא כלשהי, שום מידע לא הולך לאיבוד.

דוגמא אחרת היא בתחום הוירטואליזציה. התחום הזה נחלק בין 2 חברות גדולות (VMWare, מיקרוסופט) ויש גם את המתחרים כמו Xen, אורקל (VM Server). בעולם חברות רבות החלו במעבר מוירטואליזציות שרצות מקומית על השרתים של החברה לשרותי ענן כמו Amazon, Azure וגם ל-Google Cloud. בישראל, לעומת זאת, המעבר לשרותים הנ"ל עדיין איטי וחלק גדול מהחברות לא חושבות לעבור (אם כי כן להשתמש בשרותים אחרים כמו אחסון, DNS וכו')

אם אנחנו מדברים על וירטואליזציה, ושוב – אנשי ה-IT שאוהבים "לשחק", אני ממליץ להם על הכרות עם KVM. זו וירטואליזציה בקוד פתוח שנותנת ביצועים כמו ESXI. למי שמצפה ל-GUI כמו שיש עם vCenter (או VCSA/VSA) או כמו כלים של מיקרוסופט – יתאכזב. ה-GUI שיש מהרגע הראשון הוא מאוד פשוט. KVM נבנה יותר לכיוון אנשים שאוהבים Command Line ומכיוון שהוא נכתב כך, ישנם עשרות כלים, חלקם חינמיים וחלקם בתשלום – שמאפשרים לך ניהול של שרתים פיזיים שמריצים KVM. אפשרות שתעניין אתכם אולי זה להריץ את oVirt (המנהל הרשמי להרצת מכונות KVM, זה יותר מזכיר את ה-vCenter). אפשרות נוספת בבית שלכם (אם יש לכם כרטיס nVidia במחשב וגם כרטיס onboard) היא להריץ Windows עם משחקים בביצועים של בערך 95-99% בהשוואה ל-Native. הנה הדגמה:

אגב, ספריה טובה שאני ממליץ עליה (לאלו שכותבים ב-Python, PHP וכו') היא ספריית libvirt. בעזרת ספריה זו אתם יכולים להתחבר גם ל-ESXi, גם ל-Hyper-V, גם ל-Xen, ל-VirtualBox ועוד כמה מערכות וירטואליזציה ולהריץ עליהם אפליקציות שאתם תכתבו, כך שאם יש לכם סביבה מעורבת, ספריה זו יכולה לעזור לכם לכתוב כלים לנהל, לדגום ביתר קלות.

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

כמה עדכונים על וירטואליזציות שונות

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

העדכון הראשון נוגע ל-vSphere גירסה 6 שאמורה לצאת בשנה הבאה. ישנם לא מעט חידושים (כל אחד יכול להצטרף לבטא) ואחד מהחידושים שכבר נכנס בגירסה 5.5 הוא NDDK חדש (ר"ת של Native Driver Development Kit). מי שמעוניין לקרוא קצת יותר מה שכתבו על כך, אפשר לקרוא כאן. אני אתייחס לאספקט טיפה שונה.

טכנית, עד גירסה 5.5 חברת VMWare די "תפסה טרמפ" על הדרייברים שיש ללינוקס. לא, ESXI אינו בנוי עם קרנל של לינוקס, אך ישנה מעין "שכבה" (vmkernel) שמתרגמת בין לקרנל הקנייני של ESXI לדרייברים שכתובים עבור לינוקס. היתרון: כבר ביום הראשון, היה אפשר להתקין את ESXI על כל דבר, כל עוד שזה היה מעבד X86 עם 64 סיביות ותמיכת VT. החסרון: שכבת ה"תרגום" הורידה חלק מהביצועים.

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

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

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

אחת הבעיות הגדולות בגרפיקה עם וירטואליזציה – היא המהירות של הגרפיקה. היא פשוט א-י-ט-י-ת. אינטל הוציאה את תמיכת ה-VT-D שמאפשרת לך (תאורתית) למפות כרטיס PCi-E (כמו כרטיס מסך) למערכת הפעלה אורחת. לצערי, התמיכה של אינטל בתוספת הזו היא כמו הליכה בשדה מוקשים: יכול להיות שהמעבד החדש שלך תומך בכך, אבל אתה צריך לבדוק שגם ה-Chipset בלוח האם שלך תומך ושגם ה-UEFI/BIOS בלוח האם שלך תומך, אחרת לא תוכל להשתמש ב-VT-D.

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

אז זהו, שגם אם תעשה את השמיניות באוויר הללו, אתה תמצא שאתה לא יכול למפות כרטיס GTX מבוסס nVidia אלא רק כרטיסי Quadro יוקרתיים (יש אפשרות "להמיר" כרטיסים ישנים יותר שיהיו Quadro אבל זה לא לבעלי לב חלש, בחלק מהמקרים תצטרך להלחים..). עם כרטיסי Radeon יהיה לך יותר מזל אבל גם לכך תצטרך לשחק עם כל מיני הגדרות (כמו למפות את הזכרון שהמכונה תיקח כזכרון שלא ניתן למיפוי ל-VM אחר, אחרת הכל יתקע, מנסיון…), אבל תוכל לעשות משהו, שכמובן לא נתמך ע"י אף אחד.

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

לתוך הבעיה הזו אינטל נכנסה לאחרונה, עם גישה מאוד מעניינת: עד היום, הפתרונות שיש נתנו לך להריץ רק מכונה וירטואלית אחת עם האצה גרפית אמיתית (במקרה של Hyper-V אפשר מספר מכונות עם RemoteFX אך התמיכה הזו מאוד מוגבלת ולא כוללת דברים כמו OpenGL כך ששום אפליקציה רצינית לא תרוץ בצורה מואצת). מדוע שלא נבנה מחדש את כל רעיון ה-vGPU כך שכל מכונה וירטואלית תוכל לגשת למעבד הגרפי (של אינטל, לא מעבדים גרפיים אחרים) ותקבל ביצועים מעולים? אז 3 מהנדסים באינטל עובדים על כך והפרויקט נקרא KVMGT. תוכלו לראות מצגת (PDF) על כך כאן.

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

graph

אינטל כמובן לוקחת את הצד הניטרלי והשינויים יכנסו גם ל-QEMU, גם ל-XEN וגם ל-KVM. זה עדיין כמובן לא אומר שתוכל לרנדר פוטשופ עם כמה מאות שכבות בשניות, וכמובן זה לא ממש יתאים להריץ את המשחקים האחרונים שחונקים את המעבד הגרפי עד שהוא מתחנן לטישו, אבל זהו צעד ענק שאין ספק שיאומץ על ידי פתרונות וירטואליזציה אחרים כמו VirtualBox ואולי גם ע"י VMWare ומיקרוסופט (מי יודע..). בשלב זה המתחרים (AMD ו-nVidia) לא מציגים פתרונות מתחרים, אולם אני מאמין שלחץ מהמשתמשים יגרום להם לחשוב מחדש לגבי פיתוח פתרונות שיאומצו ע"י יצרני פתרונות הוירטואליזציה השונים.

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

עוד עדכונים – בקרוב.

הבעיות של VCSA

קצת היסטוריה על VMWare ו-ESX: כש-VMWare החליטו בזמנו לצאת עם גירסת שרת מלאה (לפני כן היתה “גירסת שרת” אבל שהיתה רצה על מערכת ההפעלה שמותקנת במחשב שלך) הם יצאו עם 2 גרסאות: האחת נקראה ESX והשניה ESXi. גירסת ה-ESX נראתה כמו הפצת לינוקס (מה שגרם לרבים להתבלבל ולחשוב שמדובר בהפצת לינוקס מטעם VMWare עם קרנל לינוקס. המציאות היא שהקרנל הוא כולו של VMWare והם השתמשו בממשק תאימות בינארית ללינוקס (ABI) על מנת להריץ שרותי לינוקס שונים על ה-ESX וגם שמנהל השרת יוכל להתקין שרותים נוספים מלינוקסים אחרים על המכונה (זה היה תואם רד-האט). גירסת ESXi לעומת זאת היתה גירסה רזה שכללה רק את הקרנל + Shell מינימלי ועוד כמה כלים, רק בלי חומת אש, שרותי לינוקס וכו’.כיום יש רק גירסת ESXi.

אחד הדברים שהפתיע אנשי לינוקס רבים היה כלי הניהול של VMWare, מה שמוכר בתור ה-vCenter (לשעבר Virtual Center) שהיה כלי על טהרת ה-Windows שנכתב בדוט-נט ושגם שילב בתוכו חלקים מאינטרנט אקספלורר. VMWare גם הוציאה כלי וובי אבל שלא נתן הרבה פונקציונאליות (כלומר הוא לא יכל להחליף את ה-vCenter). מנהלי רשת רבים התלוננו מדוע אין כלי לינוקסאי כזה והתשובה של VMWare היתה שחרור של SDK וגם מכונה וירטואלית לינוקסאית קטנה שכללה סקריפטים שאפשרו לחברות שמשתמשות בלינוקס – להתממשק עם ה-vCenter.

בגירסה 5 הדברים התחילו להשנות (והשתנו יותר בגירסה 5.1) כאשר VMWare שחררו את ה-VCSA (ר”ת של VMWare vCenter Server Appliance) – זו מכונת לינוקס וירטואלית שאמורה להחליף את הגירסה החלונאית בגירסת לינוקס. היא עדיין לא כוללת את כל הפונקציונאליות של הכלי החלונאי (כך לדוגמא עדיין לא ניתן להתקין תוספים/Plugins ב-VCSA עצמו), אבל VMWare נתנה רמז עבה מאוד שזו דרכה – היא חוזרת ללינוקס ובגרסאות עתידיות היא תשקיע יותר ב-Appliance הלינוקסאי מאשר בכלי החלונאי.

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

הבעיה הראשית מתחילה בזה ש-VMWare לא שחררה אותו כקובץ ISO להתקנה שמזכירה לינוקס (כמו שהיה ב-ESX 3.X) אלא שחררה אותו כקופסא סגורה עם קבצי OVF, VMDK וכו’, ומה ששחררו קיימות בו כל מיני בעיות הקשורות לרשת שפוסט זה יתייחס אליהם.

כאן אצלי בבית ב-LAB שלי, יש לי 2 שרתי DNS (מאסטר/סלייב) וסביר להניח שאם אתה מתעסק עם VMWare בחברה, יש לכם איזה שרת DNS, בין אם זה לינוקס או (סביר להניח) הפתרון של מיקרוסופט שמשולב Active Directory. אני מניח שהכנת לך שם hostname יחודי עבור ה-VCSA עם כתובת IP יחודית משלו ושלא ממש הלכת ל-Go Daddy או ספקים אחרים כדי לרכוש לשרת תעודת SSL, וכאן מתחילה הבעיה (לא באי רכישה) – ה-VCSA מגיע עם שם מכונה localhost שזה לא בדיוק דבר שתרצה.

אתה יכול להיכנס לממשק הוובי, להגדיר כתובת IP ושם hostname, להתחבר ל-AD ואולי להשתמש ב-DB חיצוני (אורקל או DB2 של IBM, עוד לא SQL של מיקרוסופט וגם משום מה לא MySQL, קצת מפתיע ש-VMWare משתמשים ב-JAVA ב-VCSA והם משתמשים ב-JDBC ב-Tomcat אבל הם לא כוללים תמיכה ל-DB אחרים. אם אתם רוצים להוסיף תמיכה למיקרוסופט SQL נסו את הלינק הזה [אגב, הלינק כרגע מת, אבל תודות לגוגל אפשר לראות את הגירסה הטקסטואלית כאן]), אבל ברגע שתשנו כתובת IP ואת ה-hostname ושאר פרמטרים (לא לשכוח ללחוץ על Toggle certificate settings שישתנה ל-yes) – תצטרכו להפעיל את המכונה מחדש (דרך החוצץ System)

ואז המכונה תיתקע בעליה, אם תסתכלו בקונסולה, תראו שהוא נתקע בשורה שכתוב:

waiting for the embedded database to startup [ok]

מה קרה? אוה, טוב ששאלתם…

ה-VCSA הבין שצריך ליצור תעודת SSL חדשה, והוא יצר, אבל הסקריפט של ה-DB לא יודע מה לעשות הלאה, אז הוא פשוט נתקע. אם תעשו Reboot למחשב, זה לא יעזור. זה יחזור שוב. מה שצריך לעשות הוא לבטל את האופציה ליצור תעודות SSL, אבל … אין לכם גישה לא לממשק הוובי ולא ל-SSH. תצטרכו לטפל בזה כמו שמטפלים בתקלה בשרת לינוקס (לא חשבתם שתתחמקו מלינוקס, נכון?)

אז איך מטפלים? כרגיל עם VCSA, מי שבנה את ה-Appliance בנה בצורה מחורבנת לגמרי. Safe mode לא יעזור לכם, ולכן עקבו אחר ההוראות הבאות:

  1. הפעילו את השרת מחדש והיכנסו מיד ל-Console ולחצו על מקש (לדוגמא רווח) כדי לעצור את הטיימר.
  2. לחצו על מקש p ואז ה-grub יבקש סיסמא. הסיסמא היא סיסמת ה-root שלכם (אם לא שיניתם אותה עדיין, היא vmware באותיות קטנות)
  3. לאחר הקשת הסיסמא תחזרו שוב ל-GRUB. בחרו בשורה הראשונה ולחצו על מקש e
  4. כעת יופיעו לכם השורות ש-grub אמור להריץ. לחצו על החץ למטה ובחרו בשורה השניה ושוב לחצו על מקש e
  5. לכו עם החיצים עד סוף השורה והוסיפו את הטקסט הבא: init=/bin/sh ולחצו על מקש enter
  6. כעת לחצו על מקש b והלינוקס יתחיל להיטען ולאחר מספר שניות הוא יעצר עם סימן #
  7. כעת עלינו למחוק קובץ. כל עוד הקובץ קיים, המערכת תנסה ליצור תעודות חדשות והמערכת תיתקע ב-boot רגיל, לכן הכניסו את הפקודה:
    rm /etc/vmware-vpx/ssl/allow_regeneration
  8. הקישו את הפקודה reboot ולחצו enter. המערכת תיתן אולי מספר הודעות שגיאה. תתעלמו.
  9. המערכת תעלה מחדש ובהצלחה. לאחר שתקבלו את המסך הכחול (אחלה בחירת צבעים יש להם), תמתינו עוד מספר שניות (או דקות, תלוי במעבד וכמה חזקה המכונה) ואז היכנסו לממשק הוובי

ברכותיי. נגמרה הבעיה.

אני ממליץ בחום לא להשתמש ב-VCSA במערכות פרודקשן! כותב שורות אליו מצא המון סקריפטים בתוך ה-VCSA שיש להם באגים ומי שכתב אותם כנראה למד לינוקס מתוך ספר ולא מתוך התנסות מלאה (שורות של סקריפטים שחוזרות במקום להשתמש ב-while וכו’) ויש גם לא מעט שגיאות במימוש התחברות ל-NFS – עקבו אחר ההוראות כאן) ואני משער שהדברים ישתפרו בעתיד (ואולי, מי יודע, אולי הם יוסיפו איזה משהו שמראה הורדת גירסה בזמן שמשדרגים במקום מסך סטטי שאין לך אפשרות לדעת אם יורד משהו וכמה ירד!), אבל עד אז, שימו את ה-VCSA כ-VM על מכונה צדדית (אגב, בניגוד להגדרות שם, אין צורך ב-8 ג’יגה זכרון, גם 4 יספיקו בשביל הטסטים). אני גם מקווה שבעתיד הם יוציאו גירסת ISO נורמלית ואולי, רק אולי, יהיה פורום או מקום כלשהו לדווח על באגים ואולי לתת להם תיקוני סקריפטים, גם למי שאין לו מנוי בתשלום (היי, אני יכול לקוות, לא?).

טיפ ל-VMWARE ESX/I: סיסמת root

כל איש סיסטם/Devops שמשתמש ב-VMWare ESXI יודע שהחיים עם VMWare הם יחסית לא רעים. החברה מנפיקה כלים לנהל/להקים/לתחזק את המערכות הוירטאוליות וחברות צד שלישי כותבות כל מיני אפליקציות שנותנות ערך מוסף (כמו VEEAM עם הגיבויים והמיגרציה שלהם וכו’).

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

אחת הסיטואציות שקורות גם עם VMWare אבל גם עם כל מערכת הפעלה רגילה אחרת, זה ששוכחים את סיסמת מנהל השרת (ה-root או ה-Administrator) לשרת מסוים. ב-Windows אם אתה משתמש ב-Active Directory והשרת משוייך ל-AD, אתה יכול להתחמק מכך בכך שתבחר את ה-AD, תכניס שם משתמש וסיסמא של בעל הרשאות אדמיניסטרציה ותגמור עם זה. בלינוקס אתה יכול פשוט לעשות boot במצב Single mode (במערכות אובונטו או דביאן תצטרך לבצע שינוי זמני ב-GRUB בזמן שאתה מפעיל את השרת), ולאחר שנכנסת למצב המינימלי תוכל להריץ פקודת passwd לשנות סיסמא, ולהפעיל את השרת מחדש (reboot) או לעבור ל-mode אחר (telinit 2 דביאן, telinit 3 ב-CentOS לדוגמא).

ב-VMWare אין לך אף לוקסוס כזה. שכחת את סיסמת ה-root, אין אפשרות לבצע rescue boot ולשכתב סיסמא מחדש. הפתרון הרשמי של VMWare זה שתעשה vmotion לכל המכונות שלך לשרתים פיזיים אחרים, תפרמט ותתקין את ה-ISO מחדש. לאחר ההתקנה תבצע שוב vmotion מהשרתים האחרים לשרת שהתקנת הרגע ונגמרה הבעיה.

הכל טוב ויפה, אבל מה אם אין לך Storage? מה אם שכרת שרת או 2 בחוות שרתים וזה מה שיש לך? אתה יכול לשכור עוד שרתים פיזיים ולהעביר אליהם את המכונות הוירטואליות, אבל אז ה-Migration הוא מה שנקרא Cold, כלומר העברת המכונה תהיה בתהליך של יצירת snapshot, העברת כל ה-VMDK ושאר קבצים, עוד snapshot, העברת ה-Delta, והפעלה מחדש (אם כמובן כל ההגדרות רשת תואמות וכו’, אחרת תצטרך לשנות ידנית כל מכונה). כל התהליך הזה כרוך ב-Down time, אבל הוא כרוך בהמון עבודה, תלוי כמה מכונות יש לך על כל שרת – אתה יכול לצפות לעבודה של לפחות כמה שעות טובות או לפחות יום (שוב, תלוי בכמות שרתים, תעבורת תקשורת וכו’).

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

להלן הצעדים לביצוע התהליך (הכל דרך vcenter).

  • ודא כי המכונה הנ”ל מחוברת ל-vcenter שלך, בלעדי זה אי אפשר לבצע את התהליך כי אין לך כניסה ב-SSH למכונה (אין לך סיסמת root זוכר?).
  • כבה את כל המכונות הוירטואליות
  • בחר לעבור למצב Maintenance mode (לחיצה ימנית על השרת, ובחירת האופציה הנ”ל)
  • בתפריט ה-Host profile (שמופיע עם לחיצה ימנית על השרת הפיזי) בחר Create Profile from host – תן לזה שם שתכיר שזו המכונה הנ”ל ועדיף שתכתוב קצת תיאור ב-Description, אם תצטרך זאת יום אחד.
  • לאחר שיצרנו פרופיל – נערוך אותו: לחץ על ה-Home משמאל למעלה, ובחר Host Profiles (בד”כ מופיע בשורה שלישית)
  • מצד שמאל יופיעו לנו הפרופילים. בחר את הפרופיל שיצרת, לחץ כפתור ימני עליו ובחר Edit profile
  • יופיע חלון חדש עם “עץ”, בתוך ה”עץ” בחר את Security configuration ובתוכו את Administrator Password
  • לאחר שלחץ על Administrator Password מצד ימין, החלק הימני של החלון יעודכן, בחר מתוך ה-Drop Down את האפשרות Configure a fixed administrator password, כך אנחנו בעצם נקבע סיסמא חדשה
  • כעת החלק החשוב: הקש סיסמא מורכבת, הווה אומר לפחות 8 סימנים המורכבים מאותיות ומספרים (אפשר גם סימנים אחרים). סיסמאות של 6 אותיות או 6 מספרים יכשילו את התהליך. כתוב שוב את הסיסמא בקוביית ה-confirm.
  • לחץ על OK
  • כעת חזור אל העמוד עם פירוט השרתים (לחץ על Home למעלה משמאל ועל Host & Clusters)
  • בחר את השרת הפיזי, לחץ על כפתור ימני, ובחר Manage Profile. אם תקבל אזהרה על כך שכבר מוצמד פרופיל למכונה, לחץ על Cancel. אם תקבל חלון עם רשימת הפרופילים, בחר את הפרופיל שיצרת
  • אם השרת הפיזי אינו נבחר כרגע בחלון ה-vcenter, בחר אותו ותסתכל על חוצץ ה-Summary. כמעט בסוף המלבן השמאלי מופיע Profile Compliance – ואם הכל תקין, אמור להופיע עיגול ירוק עם סימון V. אם לא, משהו בהגדרות פרופיל שלך אינו נכון, חזור אחורה וערוך את הפרופיל עם סיסמא מורכבת.
  • לחץ כפתור ימני על השרת הפיזי, ובחר ב-Host profile את Apply Profile. התהליך יקח כמה שניות ותוכל לעקוב אחריו בחלונית ה-Tasks. אם הכל תקין, אתה תראה ב-Tasks הודעת Completed. אם לא, תקבל שגיאה, סביר להניח שקשורה לסיסמא. סיסמא מורכבת, כבר אמרתי?
  • הפעל את שרות SSH (בחירה מתוך חוצץ Configuration, בחר Security Profile, לחץ על Propteries למעלה מימין, בחר את SSH, לחץ על Options ולחץ על Start ואחר כך כפתור OK. אתה תראה את SSH כ-running.
  • פתח תוכנת טרמינל כמו Putty (או terminal במק או לינוקס), הכנס את כתובת ה-IP של השרת, פורט 22 (על מק או לינוקס יש לכתוב ssh root@ip-address כאשר ה-ip-address זו כתובת ה-IP של השרת הפיזי). אם תתבקש להכניס שם משתמש, הוא כמובן root והסיסמא היא אותה סיסמא שבחרת מקודם. הקש אותה ואם קיבלת את סימן ה-# אז אתה יכול לנשום לרווחה, הכל תקין.
  • חזור ל-vCenter, לחץ על כפתור ימני על השרת הפיזי, ובחר Exit Maintenance mode ולאחר מכן הפעל את המכונות הוירטואליות.
  • ברכותיי, לא צריך לפרמט את השרת. אל תשכח לחזור ל-Security Profile ולבטל את שרות ה-SSH (כמו שהפעלת רק שהפעם בחר Stop).

זהו, אפשר להמשיך לעבוד עם המכונה, רק שהפעם מומלץ לרשום את סיסמת ה-root היכן שהוא  Smile