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

על אחסון וגדילה

כשמדברים על אחסון (כ-Storage), רובנו נתייחס למכונה הגדולה שנמצאת בחברה, ה-Storage הזה שברוב מוחלט של המקרים הוא קופסא של יצרן כלשהו. זה יכול להיות של NetApp, של EMC, של IBM, של HP ושלל חברות גדולות וקטנות, כל חברה בד"כ תקנה לפני הצרכים או לפי ההמלצות, ואצל רובן תהיה "קופסא" אחת כזו שאליה משורשרים "מגשים" של דיסקים. זה יכול להיות דיסקים מכניים מבוססי SAS, דיסקים שהם SSD, דיסקים שהם NL-SAS או אפילו במקרים מסויימים – SATA.

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

מה קורה כשכמות המקום הפנוי היא קטנה? בד"כ מוסיפים עוד "מגש" (במקרים מסויימים זה נקרא גם JBOD) והדיסקים שיהיו בפנים יכולים להיות מסוגים שונים, בהתאם לתקציב ולביצועים שמעוניינים לקבל. הגישה הזו נקראת Scale Up.

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

בנוסף – ישנם 2 בעיות רציניות:

הבעיה הראשונה נקראת SPOF (או Single Point Of Failure): הגדרות שגויות, מעבד שמתקלגל, זכרון שנדפק, בקר שהפסיק לעבוד בצורה תקינה – והפתרון אחסון שלך יתן ביצועים גרועים או שבמקרה הגרוע – יפסיק לעבוד. נכון, יש SLA שסביר להניח שרכשתם ובו טכנאי של החברה המייצרת/יבואן הפתרון יתחבר אליכם מרחוק או יגיע אליכם תוך זמן קצר, אך עדיין, גם אם הוא יתקן את התקלה, תצטרך ברוב המקרים להפעיל את כל המכונות הוירטואליות מחדש, לוודא שכל השרותים למעלה, לוודא שהגדרות שביצעו אנשי ה-IT באמת נשמרו ולא צריכים להגדיר מחדש כדי ששרותים יעלו ובקיצור – כמעט שום תקלה שקשורה לתיקון האחסון אינה מסתיימת בדקות ספורות אלא יותר בשעות.

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

הבעיה השניה שהיא יותר מהותית באותם אחסונים כמו NetApp ואחרים – היא "קניינות" של הפתרון, כלומר שהכל סגור מבחינת ה"ברזל", הדיסקים והמערכות שעובדות בתוכו. אם מחר יפנה אליך לדוגמא יבואן דיסקים ויציע לך מבצע-משוגע של דיסקים מבוססי SAS גדולים במחיר של 3 ותקבל 4 (לדוגמא) – לא תוכל להכניס את הדיסקים הללו לאחסונים הנ"ל. ישנו קוד מיוחד שבודק את הדיסק שהכנסת ל"מגש" וברגע שהוא מוצא שהדיסק אינו מאותו יצרן/סוג מסויים שיצרן האחסון עובד איתו – המערכת פשוט לא תהיה מוכנה להכניס את הדיסקים החדשים שקנית לשימוש. אתה גם לא יכול להכניס JBOD שאינם של אותו יצרן אחסון לשימוש עם פתרון האחסון. בקיצור – הכל צריך לעבור דרך השיווק של יצרן פתרון האחסון שיש לך, והוא כמובן נוקב במחירים הרבה יותר גבוהים ממה שאתה יכול לקנות בשוק החופשי. (אם כי אסייג שבחלק מהפתרון לקצה היותר נמוך, במיוחד פתרונות NAS – אין בעיה להכניס דיסק של כל יצרן, אבל הבעיות של פתרונות כאלו הם עדיין ה-Scaling).

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

מ-Scale Up נעבור למושג שמוכר יותר בתחום ה-High Performance Computing ותחום הענן – זהו תחום ה-Scale Out בפתרונות אחסון.

סביר להניח שלקוראי פוסט זה יש חשבון אחד או יותר אצל אחד מספקי פתרון ענן כלשהו, בין אם זה אמזון , או Google Compute Platform או Azure של מיקרוסופט – ונגזרותיהם: לאמזון יש את S3, לגוגל יש את ה-Google Drive, למיקרוסופט יש את OneDrive ויש גם פתרונות אחרים כמו DropBox ואחרים.

המכנה המשותף לכל אותם פתרונות אחסון קבצים בענן – זה מערכות האחסון שלהם. אף אחד מספקי הענן לא משתמש ב-NetApp או EMC והם לא משתמשים בדיסקים SAS במהירות 15K RPM כדי לאחסן את הקבצים שאתה מעלה (אינני מדבר על אחסון של מכונות וירטואליות או EBS – לזה נגיע בהמשך). במה הם משתמשים? בדיסקים הכי פשוטים שיש (כן, גם דיסקים איטיים). מהי מערכת האחסון שלהם? לכל אחד מספקי הענן יש פתרון In House משלו שהמתכנתים שלו כתבו או השתמשו בפתרון קוד פתוח אחר (אף אחד מהספקים לא מפרט) וברוב המקרים זה רץ על לינוקס. הם כמובן משתמשים בדיסקים של SSD כחלק מהפתרון, ואת השרידות הם מבצעים בכך שהם כותבים את אותו הקובץ למספר מקומות אחרים באותו Data Center. מכיוון שמדובר בפתרון שמכיל מאות אלפי (ויותר) דיסקים קשיחים – הפתרון מבחינה טכנית אצלהם שונה לחלוטין ממה שיש ב-Corporate. אין RAID ברמה כלשהי, ואין מעבדים קניינים מיוחדים בתוך שרתי האחסון (שאליו מחוברים כמות רצינית של JBOD). כך מצד אחד הם חוסכים בהשקעה ומצד שני הם יכולים לתת רמת שרידות מעולה. אחרי הכל, במחיר של דיסק אחד ל-Enterprise אפשר לקנות 3 דיסקים הרבה יותר גדולים מבוססי SATA פשוטים.

כשזה מגיע לאחסון מכונות וירטואליות או אחסון שיותר מוכר כ-Raw Storage – לדוגמא EBS, PD, Drives – בהתאם לספק ענן, גם כאן ספקי הענן לא "רצים" לקנות את פתרונות ה-Enterprise והם מעדיפים פתרונות SSD שהם זולים, גם אם חיי המוצר יהיו קצרים, והספקים משתמשים בכל טריק אפשרי כדי לתת למכונות שלך בענן ביצועים גבוהים (יחסית), אבל שוב -אין שימוש בפתרונות אחסון קנייניים מבחוץ כמו של EMC ואחרים. זה פשוט לא שווה להם פיננסית, במיוחד בתחרות האכזרית כיום שכל ספק חותך בעשרות אחוזים את המחיר והשאר "נגררים" אחריו בחיתוכי מחיר לאחר מספר ימים.

הפתרונות שתיארתי מבחינת ספקי הענן – הם נכללים בקטגוריות ה-Scale Out, כלומר הפתרונות לא מבוססים על שרת אחסון יחיד ואולי עוד Mirror, אלא הם מתחילים ב-3 שרתים ומעלה כאשר העומס מחולק בין השרתים. במקרה של ספקי הענן מדובר כמובן בהרבה יותר מ-3, ומכיוון שהכל נכתב בכמה וכמה עותקים, גם אם יפלו שרתים שמחזיקים מאות דיסקים, אתה לא תרגיש בכלום, כי אתה תקבל את השרות משרתי אחסון שכנים שיושבים באותו Data Center.

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

בפוסט הבא אתאר כיצד פתרון Scale Out יכול להתאים ל-Enterprise/Corporate, מהם ה"מועמדים", יתרונות וחסרונות ובמיוחד – על Ceph.

עתיד אמצעי אחסון ב-Enterprise

הערה
מאמר זה מדבר על הדיסקים/כוננים המשמשים לאחסון ולא על פתרונות כמו NAS/SAN וכו'.

מבחינת דיסקים/כוננים קשיחים, אנחנו נמצאים בתקופה מאוד מעניינת. ב-15 שנים האחרונות היו שינויים בתחום זה, אך לא שינויים כה מהותיים. רוב החברות בעשור האחרון השתמשו בכונני SAS (ולפני כן SCSI לגרסאותיו) בשרתים, וההתקדמות בכל הקשור לתחום הכוננים המגנטיים – היתה מועטה. היתה קפיצת מהירות סיבוב לדקה מ-10K ל-15K, היו הכפלות כמות אחסון (144G ל-300G ברוטו, 300 ל-600 ומשם ל-900) ופה ושם ראינו גם "נגיעות" של יצרניות הדיסקים בהטמעת פתרון Cache קטן כלשהו בדיסקים.

מבחינת כוננים מבוססי טכנולוגיית Flash, ראינו התפתחות ממצב של "1 ביט בתא" (SLC) ל-2 ביטים ויותר בתא (MLC) (היתה גם קפיצה ל-TLC – של 3 ביטים בתא, אולם הם היו מיועדים לשימוש ביתי/דסקטופ) וגם קומבינציות שיותר מתאימות ל-Corporate כמו eMLC, ואפשר לקרוא על כך בקצרה כאן.

אחד הדברים שחברות רצו בכל הקשור לדיסקים מגנטיים – היו גדלים יותר רציניים. זה נחמד שיש גדלים כמו 150 או 300 ג'יגה, אבל במחשב שלך יושב לו בנחת דיסק של 2-4 טרהבייט. הוא בהחלט לא מתאים ל-Enterprise והיצרניות החלו לקבל שאלות לגבי דיסקים גדולים ב-Enterprise. מכיוון שאי אפשר להכניס פלטות כמו שיש דיסקים של דסקטופ ל-Enterprise SAS ולהאיץ את מהירות הסביבוב ל-15K, הגו היצרניות סטנדרט חדש שנקרא Nearline Storage SAS ובקיצור: NL-SAS.

מהו NL-SAS? אלו דיסקים SATA שמיוצרים בטכנולוגיה שונה במעט מטכנולוגיית הדיסקים לדסקטופ, אך הבקר שיש לאותו דיסק הוא בקר SAS, כך שדברים כמו Command Queue, ערוץ תעבורה כפול ועוד יתרונות שיש ל-SAS – קיימים לדיסקים הללו, אך האמינות שלהם אינה כמו האמינות של דיסקים SAS "אמיתיים" (תוכלו לקרוא על כך יותר כאן). אז נכון, יש פחות אמינות מבחינת שגיאות כתיבה וטיפול בהן בהשוואה ל-SAS, ואין מהירות של 15K סיבובים לשניה (יש דיסקים SATA עם מהירות 10K, אגב, והם יקרים), אבל מצד שני – יש הרבה יותר שטח אחסון בדיסק.

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

טכנולוגיות ה-SSD הלכו והתפתחו יותר ויותר. מהירות ה-SAS (של 6 ג'יגהביט בשניה) נהפכה לצוואר בקבוק ואז הגיעה טכנולוגיית ה-SAS במהירות 12 ג'יגהביט. אם היינו חיים בעולם של דיסקים מגנטיים בלבד, הסטנדרט הזה היה נשאר למספר שנים, אך הסטנדרט הנ"ל לא מחזיק מעמד והיצרנים החלו לפנות לפתרון אחר: ערוץ ה-PCIe X4 (ברוב המקרים הכרטיס הוא בחיבור פיזי של PCIe X8 שהוא יותר סטנדרטי) והכונן כפי שהכרנו אותו הפך לכרטיס PCIe ומכיוון שהחיבור ב-PCIe הוא הרבה יותר מהיר מ-SAS (עם Latency מאוד נמוך), מהירות הכתיבה והקריאה זינקה בפראות למהירויות בג'יגהבייטים, אך אז צצה בעיה אחרת: כמה כרטיסים אתה יכול להכניס בשרת 1U? אולי 2 במקרה הטוב, ואולי 3-4 בשרתי 2U.

NVM_Express_logoהיה צריך פתרון אחר והוא הגיע. הפתרון הוא NVME. טכנולוגיית ה-NVMe בעצם "מורידה" את הפתרון מהצורך ב-Slot פיזי של PCIe ומעבירה אותו בחיבור חוטי על בקר MVNe שיושב בכונן עצמו.

Samsung-XS1715-1.6GB-NVMe-SSD-Connectorכך נראה חיבור NVMe (בתמונה מימין) בכונן של סמסונג בדגם XS1715. כפי שאתם יכולים לראות, מדובר בחיבור שונה לחלוטין מ-SAS או SATA. זהו חיבור בסטנדרט חדש שנקרא SFF-8639 (הוא דומה מאוד לחיבור SFF-8482). היתרונות של חיבור כזה הוא שהוא תואם אחורה ל-SAS ול-SATA והוא משתמש בכל הפינים ה"מיותרים" למימוש חיבור PCIe. (כמובן שיש צורך בכך שלוח האם ידע לתמוך בחיבור SFF-8639). חיבור זה, בשלב זה, יודע לתמוך רק בכונני SSD בתצורה של 2.5 אינטש בעובי 15 מ"מ.

הבה נסתכל על המפרט של ה-XS1715. זהו כונן שמתחרה בדגמים ל-Enterprise כמו של אינטל P3700 או כונן אחר של חברת Micron. להלן הטבלה:

SamsungXS1715-Specs

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

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

סמסונג היתה הראשונה להציג כונן עם נתונים מטורפים כאלו, אך המתחרים לא נמצאים מאחור. אינטל תכריז כבר בקרוב על סידרה P3800 (השמועות מדברות כבר על סידרה P4XXX עם שינויים רציניים וכפי הנראה שגם אינטל תרד מגירסת הכרטיסים) שתתן את אותם ביצועים כמו של סמסונג. סאנדיסק ומיקרון גם יוציאו מוצרים עם IOPS פחות או יותר באותה רמה במחצית השניה של השנה ובינתיים מדברים על כך שלקראת סוף השנה נתחיל לראות כוננים בטכנולוגיית NVMe עם IOPS של 7 ספרות. כל הכוננים הנ"ל מגיעים עם כמות אחסון החל מ-300 ג'יגהבייט ועד 3.2 טרהבייט, וזה עוד לפני שאותן חברות מתחילות להכניס את טכנולוגיית יצור צ'יפים בתלת מימד (שכבה על שכבה, סמסונג משווקת כיום לדוגמא את ה-Pro 850 שמיועד לשימוש Semi Enterprise/Workstation ב-32 שכבות, [גירסא הבאה תהיה כבר לפי השמועות – 128 שכבות] מה שיתן גם ביצועים יותר טובים מכונני SSD מבוססים SLC, וגם אין צורך בליטוגרפיה כה נמוכה – מה שסמסונג משתמשת זה 40 ננומטר)

כך שהמירוץ – בעיצומו, ועוד לא דיברנו על פתרון יותר מדהים – פתרונות SSD שיושבים על .. תושבות הזכרון בשרת. (שוב – Latency הרבה יותר נמוך מ-NVMe של משהו כמו 2-3 ננו-שניות).

אז לאן אנחנו מתקדמים בעצם? לפיצול.

מבחינת עלויות/אחסון – כוננים מגנטיים מבוססי SAS במהירות 10-15K סיבובים לשניה יופסקו להיות מיוצרים במהלך השנים הקרובות (לא השנה או השנה הבאה כמובן) מכיוון שלטכנולוגיה הזו אין ממש המשך. אפשר להאריך לה את החיים באופן מלאכותי בכך שהיצרנים יטמיעו Cache יותר גדול, אך בעידן שחברות רוצות שטחי אחסון יותר ויותר גדולים, ה-NL-SAS וגם כונני SATA יתפסו יותר מקום כשמדובר על אחסון שלא מצריך IOPS מטורף (לוגים, ארכיבאות, גיבויים, וידאו בזרימה). כיום המחיר להרים Cluster לצורך אחסון יורד כל הזמן וישנן מספר מערכות בקוד פתוח (וגם קנייניות כמובן) המאפשרות לך לקבל ביצועים טובים במחיר די זול תוך שילוב כונני SSD להאצת גישה, מהם תוכל לייצא החוצה iSCSI או NFS או SMB לשימושי החברה.

מבחינת עלויות/ביצועים (כן, IOPS) התחרות עושה את שלה ולחברות/יצרני Storage יש מגוון אפשרויות חדשות לבנות מערכות שנותנות IOPS גבוה בהתאם לתקציב של הלקוח, החל מ-SAS, המשך ב-NVMe ועד ULLtraDimm, ורובן יאפשרו ללקוח לשלב מודולים שונים כך שאפשר תמיד לגדול ולקבל IOPS יותר גבוה. שילוב טכנולוגיית התלת מימד ביצור רכיבי Flash מוזילה משמעותית את עלות היצור וכמות הצ'יפים שיש צורך בכונן SSD כזה, ואני משער שכבר ב-3 השנים הקרובות נתחיל לראות תחרות רצינית שתתן גם לחברות הקטנות פתרונות IOPS מכובדים.

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

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

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

על NFS v3 מול NFS v4.1 ו-pNFS

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

בעולם היוניקס, פרוטוקול שיתוף הקבצים הכי ידוע הוא NFS (שפותח ע"י SUN) וספציפית גירסה 3 (כלומר NFS v3) וגירסה זו היתה שיפור של דברים ישנים יותר כמו DFS ו-AFS. בפרוטוקול זה, כל יצרני היוניקס/BSD ולינוקס השתמשו ומשתמשים עד היום, למרות שהפרוטוקול עצמו די ותיק (השנה ימלאו לו 20).

גירסה 3 של NFS הומצאה בזמנים שכמות התעבורה וכמויות המידע שהיו לחברות, היו נמוכות (במושגים של היום) ובהתחלה גירסה 3 תמכה רק בהרשאות של מה שקיים בשרת עצמו, כלומר אם משתמש X לא קיים במערכת, אז משתמש X לא היה יכול להשתמש/לקרוא/לכתוב קבצים ששותפו ע"י ה-NFS. במשך הזמן אותה גירסה 3 "שופצה" והתווספו לה (בעקיפין) תמיכה לדברים כמו NIS, LDAP, AD ואחרים, בין באמצעות שימוש ב-Mapping (במקרים של משתמשים בודדים עם הגדרות ידניות ללא שרת אותנטיקציה) ובין בשימוש ב-Translation שהשתמש ב-nsswitch ואותו nsswitch היה מתממשק לשרות האותנטיקציה.

כפי שאתם יכולים להבין, NFS v3 אינו פרוטוקול ממש נוח והוא למען האמת מאוד "בזבזני". כך לדוגמא מבחינת פורטים, הוא צריך לא מעט מהם (תריצו rpcinfo -p על שרת NFS ותראו). בנוסף, מבחינת תעבורה, הוא היה זקוק למידע מהשרת על כל פיפס. כך לדוגמא, מספיקה פקודת ls פשוטה בשביל "לתזז" את ה-NFS שישאל את השרת לגבי שמות קבצים, הרשאות, וכו' וכל הבקשות האלו היו טוריות ונפרדות, בלי שום אופטימיזציה. יצרני ה-Storage למיניהם שרצו למכור מוצרי Storage לחברות היו צריכים לבצע שמיניות באויר כדי לתת לשרתים ותחנות שרותי NFS v3 ולהתמודד עם הבעיות שלו.

ב-SUN היו מודעים לבעיות והם שחררו ב-2000 לפתח את גירסה 4 (וגירסה זו זכתה לשיפוצים ב-2003). מכיוון שהם רצו שזה יהיה סטנדרט, הם עבדו עם ארגון ה-IETF וב-2010 יצאה גירסה 4.1 בצורה רשמית כסטנדרט.

אנחנו נמצאים בשנת 2015 והשימוש ב-NFS 4.1 אינו גדול בעולם. מדוע? ישנן מספר סיבות:

  • אחת הסיבות שלא משתמשים (או שמשתמשים ב"עירוב" של גירסה 3 ו-4, מה שלא ממש מקל על צוות ה-IT) היא חוסר תמיכה לגירסה 4.1. כל חברה שמכבדת את עצמה משתמשת בוירטואליזציה ואם רצית להשתמש בוירטואליזציה עם NFS, האפשרות היחידה שהיתה לך – זה להשתמש ב-NFS 3 (או iSCSI).
  • סיבה נוספת ודי עיקרית – אין Clients, במיוחד שלא היה שום Client רשמי ללינוקס, כיום רוב השרתים שאינם מבוססי Windows הם לינוקס, ומכיוון שלא היתה תמיכה (עד גירסת Red Hat 6.4 וגם אז זה היה מוגדר כ-Technology Preview) – חברות העדיפו להשתמש ב-NFS 3 או בפרוטוקולים אחרים.

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

אולם אחד היתרונות הגדולים של גירסה 4.1, היא שאין יותר מצב של שרת אחד שמשרת את כולם. מעתה אפשר לשים כמה שרתי נתונים (Data Storage) שעליהם מאוחסנים הנתונים (בשכפול או בכל תצורה אחרת) וישנו שרת שמנהל את ה-Meta Data (וגם נקרא כך – MDS – Meta Data Server), כך שהתחנות שפונות וצריכות שרותי NFS, מדברות בהתחלה עם ה-MDS וה-MDS מפנה אותם לשרתי DS שעליהם מאוחסן המידע. זה, אגב, ה-pNFS שהוא בעצם חלק מ-NFS 4.1.

בנוסף, יתרון גדול מאוד שיש לגירסה 4.1, זה שעתה במקום לתת רק שרותי קבצים, השרת יכול להגיש עוד 2 סוגים של אחסון: האחד הוא Object Storage והשני (שסביר להניח שרבים יאהבו) הוא Block Storage – כמו iSCSI, FC, FCoE וכו'. כלומר, אפשר להכין כמה LUN נחמדים, לתת ל-MDS לעשות Discovery מול ה-iSCSI Target ולשתף אותם, דבר שבעייתי לבצע עם iSCSI Initiator שונים (למעט במקרים של Cluster Aware כמו ב-ESXi, Hyper-V וכו').

ויש עוד יתרונות רבים ל-NFS v4.1.

נשמע נחמד, לא?

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

הבעיה הגדולה היא שמה שרד-האט והפצות אחרות נותנים, זה רק Client. אסייג בדבריי ואומר שאין מניעה מלהרים שרת NFS 4.1, אולם בגירסת רד-האט 7 האחרונה, יש תמיכה בשיתוף קבצים, אולם תמיכה ב-Object Storage וב-Block Storage מוגדרת כ-Technology Preview (גם בגירסת רד האט/סנטוס 7.1 שתצא בקרוב). התמיכה הרצינית ש-pNFS (כ-שרת) צריך תגיע רק בקרנל 4.0, וגם אז התמיכה היא ל-XFS בלבד.

אבל הבעיות לא עוצרות כאן. גם אם נורא בא לך לקמפל קרנל, לשדרג את חבילות ה-nfs-utils ואחרות (שנמצאות ב-Fedora 22 שעוד לא יצא), אתה תמצא מהר מאוד שקיימת בעיה רצינית של תיעוד. הוא פשוט כמעט ולא קיים ומה שקיים כתוב בצורה שקשה להבין מי נגד מה ואיך, כמו איך להגדיר שרת קבצים כ-DS, מה צריך להיות בשרת MDS, איך משתפים בלוק של iSCSI ועוד ועוד. דווקא ניסיתי לשלוח מספר מיילים ולצ'וטט ב-IRC בערוץ linux-nfs, אך עד כה לא קיבלתי כל תשובה..

עם כל הבעיות, יש בהחלט מקום לאופטימיות. אני מאמין שהדברים ישתנו בחודשים הקרובים וישנם גם שיפורים שהחבר'ה מאורקל (לשעבר SUN) גם ירצו לאמץ כמו 21 הטלאים שהוצעו כ-RFC אתמול ל-Linux-NFS שמאפשרים דבר חדש: RichACL, כלומר ACL שיתן תאימות מלאה גם ל-SMB וגם ל-NFS, דבר שיכול להקל מאוד לסביבות מעורבות (ויכול להחליף את ה-POSIX ACL).