VDI – עמוד 5 – הבלוג של חץ ביז

העתיד: דיסקים, Storage ו-NVME-OF

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

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

התשובה: במקרים של דיסקים מכניים – בהחלט. במקרים של SSD – זה יוצא ההיפך. קחו דיסק SSD בחיבור SATA ותקבלו לדוגמא מהירות קריאה של 550 מגהבייט לשניה. לזה, שום SAS לא הגיע עם דיסקים מכניים (אלא אם מכניסים את ה-Cache של הבקר אבל זה יפה במבחנים, לא לעבודה במציאות) וכך עולם הדיסקים חזר "אחורה" ל-SATA ופורמט ה-SAS די "מת" למרות מאמצים מצד יצרני בקרים ושרתים להוציא (מאוחר מדי, LSI היו הראשונים להוציא מוצרים ב-2013) את SAS-12G, וכך המצב בשנתיים האחרונות בשוק הוא שדיסקים SSD קיימים בגירסאות SATA בלבד – אבל הדיסקים עצמם מכילים את כל תכונות ה-Enterprise כמו תיקון תקלות אוטומטי, שמירת מידע עצמאית בעת הפסקת חשמל, שרידות גבוהה בעבודות כבדות ועוד.

דיסקים SSD מבוססים SATA מאפשרים לחברות להמשיך לעבוד כאילו הם עובדים עם דיסקים מכניים או דיסקים SSD ישנים, ורבים נוטים עדיין לעשות את הטעות לעבוד כ-RAID-5,50,60 כשהם שוכחים 2 דברים מאוד חשובים:

ה-RAID-5 וה"אחים" שלו 50,60 ביצעו 2 דברים חשובים: נתנו ביצועים גבוהים הנובעים מעבודה עם ריבוי דיסקים וחלוקת העבודה בין הדיסקים, ושרידות יותר גבוהה מכיוון שאם הולך דיסק אחד או 2 (בהתאם לשלב ה-RAID) – המערכת היתה ניתנת לשיקום לאחר החלפת הדיסקים. עם SSD לעומת זאת (גירסת Enterprise!) הביצועים שהדיסקים האלו מוציאים די "חונקים" כל כרטיס רשת. תחשבו על כך: 2 דיסקים SSD ב-RAID-0 מוציאים מהירות תיאורתית של 1100 מגהבייט לשניה (בקריאה). נתרגם זאת לג'יגהביט ונקבל .. 8 ג'יגהביט, כלומר כרטיס רשת של 10 ג'יגהביט יהיה תפוס ב-80% בזמן שהוא משדר את ה-DATA מצמד הדיסקים, ושוב – אני מדבר על 2 דיסקים בלבד. אז מה בעצם נותן בקר דיסקים? ביצועים? יש כבר לדיסקים, לא צריך גם Cache. שרידות? ב-SSD ל-Enterprise יש יכולות הרבה יותר מרשימות של שרידות פנימית מאשר כמעט כל בקר RAID בשוק. ובכל זאת, חברות ממשיכות לעבוד כך. מדוע? אני חושב שזה עניין של הרגל.

בשנתיים האחרונות נכנסנו לעידן חדש של דיסקים SSD, מה שבהתחלה נקרא PCI SSD והיום פשוט נקרא NVME SSD. לדיסקים הללו לא תמצאו שום RAID כי הדיסק מחובר ישירות לתושבת PCIE X4 (בחיבור שנקרא כיום U.2, חלק מהיצרנים לצערי עדיין משתמשים בחיבור קנייני משלהם, לרווחתם של יצרני הדיסקים והשרתים, לצערם של הלקוחות ש"ננעלים" בכך שלא ניתן להכניס דיסקים יותר טובים מצד ג'). הדיסקים הללו כיחידות עצמאיות נותנות יותר ביצועים מכל מה שתשיג עם SSD ו-RAID, מהירויות של 2-4 ג'יגהבייט לשניה בקריאה ועד 2 ג'יגהבייט בכתיבה עם עשרות עד מאות אלפי IOPS (וכמובן את המילה האחרונה בשרידות, ושוב – שרידות הרבה יותר גבוהה מכל דיסק מכני שאתם מכירים) ושם כבר אין RAID (ואם רוצים RAID 0,1,10 – עושים זאת בתוכנה. הביצועים לא יהיו נמוכים יותר בהשוואה לבקר יעודי, האמינו לי, גם אם תנסו את זה על מעבד i5 פשוט [ניסיתי בעצמי מול בקר יוקרתי של LSI ]).

מי שבתחום כבר בוודאי מכיר את כל מה שכתבתי, אבל מה בעצם הלאה?

אם נסתכל מבחינת דיסקים, בשנה הנוכחית השוק מנסה להסתגל למצב חדש שבו יש הרבה יותר ביקוש מהיצע. דיסקים NVME SSD של 3-4 טרהבייט, גם אם תנפנף מול היצרן בכרטיס אשראי פלטיניום, תשלום מיידי או ערימת מזומנים – תיאלץ במקרים רבים לחכות וזה כרגע עדיין "מכה" ב-HP, DELL וגם ב-Lenovo. היצרנים נתפסו "במערומיהם" עם דרישות היסטריות לשבבי Flash מצד כל יצרני המחשבים והטלפונים. כולם רוצים שבבי NAND ועכשיו. יצרני השבבים גדלים (חברת TSMC לדוגמא, אחת החברות הגדולות ליצור שבבים – מתכננת בניה של FAB נוסף בסין בדיוק בשביל זה) ושבבי ה-3D NAND החדשים מאפשרים ליצור שבבים עם כמות אחסון יותר גדלה בליטוגרפיה בשיטות יותר "ישנות" כך שניתן פר Waffer ליצור יותר שבבים. שלבים אלו ואחרים יתורגמו לשחרור לחץ בשוק במהלך השנה שנתיים הקרובות.

אבל גם אם הבעיה תיפתר, נמצא את עצמנו בבעיה אחרת: בשביל ביצועים רציניים צריך NVME SSD וגם אם יש לך דיסקים חדשים וגדולים כאלו, איך בדיוק תשתמש בהם? זה לא שיש לך בקר RAID להגדיר Virtual Disk שעל זה אתה מתקין Windows, Linux, vSphere וכו'.. אפשר כמובן להוסיף דיסק קשיח כלשהו (ולהשתמש בבקר הפנימי כדי לבנות RAID-1 מדיסקים פשוטים) כדי להתקין את מערכת ההפעלה וכו', אבל הדבר הבא שהיצרנים ידחפו נקרא NVME-OF (זהירות, לינק לקובץ PDF). זהו הסטנדרט חדש שנבנה ע"י החברות שבנו את סטנדרט NVME, ועם הסטנדרט הזה אנחנו משתמשים בכמה מושגים שבוודאי שמעתם עליהם:

ה-AFA (כלומר All Flash Array) – מערכת סטורג' (או שרת) שבנוי כולו מדיסקים NVME SSD.
על מה נעביר את הנתונים? זוכרים ROCE? אז הוא חוזר לסיבוב נוסף, ולאלו שאוהבים לשפוך כסף כאילו אין מחר (בנקים, מכוני מחקר יוקרתיים וכו') – Infiniband.
ובאיזו שיטה? זוכרים iSCSI? אז נגזור משם את ה-Target ו-Initiator, שיהיה לכם חיים יותר קלים.
אבל מה עם כתובות IP וכו'? זה ישאר, רק שהפעם זה "נעקר" מה-OS ומועבר לביצוע ע"י כרטיס הרשת (כלומר TCP Offload).

עכשיו נשלב את הכל ביחד: נבנה שרת מבוסס Dual Xeon עם 128 ג'יגה (עדיף יותר, תלוי בכמות ה-Clients וכו') מבוסס לינוקס עם קרנל 4.8.7 ומעלה, עליו נרים מערכת שתהווה בעצם Target ובה ישבו לא רק הדיסקים אלא גם מספר כרטיסי רשת עם פס רחב (25 ג'יגה ומעלה או Infiniband). הכרטיסים יחוברו למתג תואם ומשם יחוברו לשאר השרתים שאנו מעוניינים. את חלוקת ה-Volumes וכו' נעשה על ה-Linux והמערכת בלינוקס תשדר זאת דרך ה-ROCE כבלוקים (אפשר עם שילוב TCP/IP, אפשר גם בלי אבל אז יתחילו הצרחות ממחלקת ה-IT) וה-Initiator בשרתים יתחבר ל-Target (יהיו גם אפשרויות אותנטיקציה, הצפנה וכו'). שרתים ישנים יוכלו להעלות את ה-Initiator לדוגמא דרך IPXE (או PXE לחובבי טכנולוגיה קלאסית) ומשם ה-OS יעלה ויקבל תמיכה מלאה כאילו מדובר בדיסקים מקומיים.

והביצועים? אם נשווה זאת לדיסקים NVME מקומיים, ההבדל יהיה באחוזים בודדים. מכיוון שכל השיטה מעיפה כל דבר שמוסיף Latency, הביצועים נראים כאילו מדובר בדיסקים מקומיים, רק שאין צורך לבצע תחזוקת דיסקים פר שרת והכל מבוצע ממקום אחד (ומנסיון, התחזוקה לא כזו מורכבת). סתם דוגמא: גם אם שפכתם כסף והפכתם את המערכת תקשורת שלכם ל-100 ג'יגהביט, תקבלו (במספר חיבורים במקביל) קצב של 93 ג'יגהביט בקריאה, ו-40 ג'יגהביט בכתיבה. עכשיו תנסו לדמיין מערכת VDI לאלפי משתמשים ואיך זה יעבוד, וכן – יש Initiators ללינוקס, Windows ול-VMWare כבר כיום.

כמובן שחובבי מיקרוסופט לא ישארו בצד ואם הם רוצים להקים לעצמם Target מבוסס Windows Storage Server אז הם יצטרכו להמתין קצת לגירסה הבאה.

לסיכום: דיברתי כאן על דיסקים SSD, על תקשורת שגבוהה בהרבה מ-10 ג'יגהביט, על NVME-OF (ממש על קצה המזלג). הטכנולוגיה קיימת כבר כיום (חברת Mellanox כבר דוחפת ומדגימה אותה), אבל שום חברה לא עוברת מהיום למחר לטכנולוגיה חדשה שמצריכה החלפת מתגים וכרטיסי רשת ורכישה רצינית של NVME SSD ושרתים לכך. אלו דברים שלוקחים זמן, לפעמים שנים – אבל זהו הכיוון שהשוק ל-Data Center עובר אליו. חברות סטורג' רבות ישמחו למכור לכם את הפתרון לאחסון מחר בבוקר, אבל לפחות מבחינת TCO ו-ROI (ואם החברה מוכנה לאמץ מעט ראש פתוח) אני ממליץ לחשוב על פתרון בניה עצמית. הוא הרבה יותר קל ממה שרבים נוטים לחשוב (סתם דוגמא: הוא הרבה יותר קל מאשר הקמה וניהול של שרת ZFS) והוא פתרון שיכול להיות Scale Out די בקלות וזול בהרבה אם חושבים להרחיב – מאשר פתרון קנייני.

מוגש כחומר למחשבה 🙂

שאלות ותשובות על Cloudforms/ManageIQ

מאז שפירסמתי את הפוסט לגבי Cloudforms/ManageIQ קיבלתי במייל מספר שאלות והחלטתי שזו הזדמנות טובה לפרסם את השאלות והתשובות בפוסט אחד (שאני אעדכן לפי הצורך). הסימון, כרגיל הוא ש: (שאלה) ת: (תשובה). למען היעילות, בכל מקום שאכתוב CF/MIQ אני מתכוון כמובן ל-Cloudforms/ManageIQ

ש: האם CF/MIQ מתאים להחליף את הממשק ה-Windows/Flash/Web של vSphere?
ת: באופן עקרוני CF/MIQ בהחלט יכולים להחליף הממשק הקנייני של vSphere (או vCenter כפי רבים מכירים זאת), כמו שהוא יכול להחליף את ממשק ה-SCVMM בכל מה שקשור למכונות VM, אבל שימוש בכלי כזה רק לשם החלפת ממשק כמוהו כחיסול זבוב עם תותח 🙂

חשוב – שימוש ב-CF/MIQ אינו מייתר רכישת vSphere. ה-CF/MIQ מתממשק ישירות ל-CF/MIQ ולפיכך יש צורך ברכישת הרשיון vSphere.

המטרה העיקרית של CF/MIQ היא לנהל Life Cycle מלא של מכונות VM, וכדי לייעל תהליכים להקמת VM שאינם קשורים ישירות לפלטפורמת ה-VM שלך (פרטית או ענן). תהליכים הקשורים לבירוקרטיה בחברה, אורך חיי VM, פורטל בקשות הקמת VM ע"י הצוותים השונים בחברה, מימוש נהלים, עדכוני אבטחה (בשלב זה במכונות Linux Guest) ועוד. אם נשווה את זה לכלים המוכרים בתחום VMWare למשל, אז זה משהו כמו vRealize Orchestrator + vCenter Server – רק ש-CF/MIQ לוקחים את זה צעד קדימה לאפשר לך להתחבר גם לפלטפורמות VM אחרות ולעננים פרטיים וציבוריים.

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

ש: האם ניתן להשתמש בחלק מה-Appliances גם בגירסה הפתוחה (MIQ) וגם בגירסה המסחרית (CF)
ת: ברוב המקרים התשובה היא "כן", אבל אז אינך יכול לקבל תמיכה רשמית למערכות CF/MIQ. חברות שמעוניינות בפתרון, צריכות או להשתמש בגירסה המסחרית או בגירסה החופשיה (ללא תמיכה רשמית).

ש: האם ישנה פלטפורמת אוטומציה ב-CF/MIQ?
ת: בהחלט! בברירת המחדל CF/MIQ תומכת ב-Puppet יחד עם Foreman, ניתן להשתמש גם ב-Chef וב-Ansible.

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

ש: איזו גירסה יותר מעודכנת ועם יותר Features ואיזו גירסה נחשבת יציבה?
ת: ה-ManageIQ כולל את "המילה האחרונה" מבחינת תכונות המערכת. זו המערכת שמפותחת מדי יום (לתוך GIT מרכזי פתוח) וניתן לשלוף את הגירסה האחרונה או גרסאות קודמות. האם מערכת כזו נחשבת יציבה? כל עוד לא הולכים ל-Bleeding Edge (או ה-Master ב-GIT) – אז יחסית כן, אם כי יכולים לצוץ באגים פה ושם.

לעומת זאת ה-Cloudform זו מערכת שמבוססת על ManageIQ אם כי לא על הגירסה האחרונה של ManageIQ. לגירסה זו נערכים בדיקות ומתוקנים באגים ורק למוצר הרשמי ניתנת התמיכה הרשמית של רד-האט.

ש: מה המחיר של Cloudforms?
ת: עניין המחיר הוא דינמי, זה תלוי על איזו מכונה אתה מריץ את CF, כמה Appliances אתה צריך, מהו סוג השרות שאתה מחפש (NBD, 24/7 וכו'), האם אתם משתמשים בעוד מוצרי רד-האט וכו'. אינני יכול לתת מספרים אבל אני כן יכול לרמוז שהמחיר נמוך ממחיר vRealize Operations (ואתה מקבל יותר, ואף אחד לא "יושב לך על הצוואר" מבחינת כמות VM) 🙂

ש: אנחנו משתמשים באובונטו במערכות שלנו, האם המוצר (המסחרי או הפתוח) יכול לרוץ על VM אובונטו?
ת: מכיוון שה-CF הוא Appliance, הוא מגיע כ-VM מוכן שצריך רק לבצע לו Deploy, להגדיר כתובת IP (או DHCP), להיכנס למסך הניהול ולהגדיר את שאר הדברים משם (ניתן כמובן לבצע SSH ולהשתמש במכונה כמכונת לינוקס אם רוצים לשנות דברים, לא מומלץ אם לא מכירים CF/MIQ).
יחד עם זאת, אם אתם משתמשים בגירסת ManageIQ, ישנם הוראות ברשת איך להקים זאת על VM מבוסס אובונטו (ולכך כמובן לא ניתן לקבל תמיכה מרד-האט).

ש: היכן ניתן לראות רשימת Features שקיימים בגירסה האחרונה?
ת: הנה (לחצו להגדלה)

ש: בחברתנו חוששים להכניס מוצרים כאלו מכיוון שבמקרים רבים התיעוד לוקה בחסר. האם למוצר יש תיעוד מלא שנגיש ללקוחות?
ת: במקרה של Cloudforms כלקוח אתה מקבל גישה מלאה ואתה יכול להוריד את ההסברים וההוראות כקבצי PDF. בנוסף יש גם ספרות רשמית שניתנת להורדה.
גם ל-ManageIQ יש תיעוד (ברובו אותו תיעוד של Cloudforms) אולם יש לשים לב לשינויים שיש פה ושם בין ManageIQ לבין Cloudforms.

ש: האם למעט מחיר ה-Appliance (אם החלטנו לרכוש אותו) יש עלות נוספת שצריך לשלם לפלטפורמת ה-VM?
ת: במקרים של ספקי ענן ציבוריים, תצטרך לשלם לספק הענן הציבורי על Instance של מכונת לינוקס (לא ניתן בשלב זה לרכוש מכונה מוכנה + רשיון דרך ה-AWS Marketplace לדוגמא) + הדיסק והתעבורה.

ש: האם יש תמיכה ב-Cluster/High Availability?
ת: בהחלט! זה אחד הדברים הראשונים שהתיעוד מסביר איך לעשות אם אתה רוצה להשתמש במערכת כ-Cluster.

ש: כמה זמן לוקח לאינטגרטור מטעם רד-האט בארץ להקים PoC של Cloudform מקומית? האם יש גירסת Trial?
ת: זה מאוד תלוי ב-Scope של ה-PoC ותלוי במסמך ה-SoW. לדוגמא: הקמה של Appliance וחיבור לפלטפורמת ה-VM הנוכחית שלכם אפשר לבצע תוך יום עבודה. קאסטומיזציה, טפסים, כתיבת תוספים – אלו דברים שלוקחים זמן נוסף. כל פרויקט לגופו.

לגבי Trial – בהחלט יש.

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

ש: יש לנו שרתים פיזיים רבים (שאינם מריצים VM אלא אפליקציות יעודיות). האם CF/MIQ יכול לסייע בהקמה/ניהול?
ת: כן. ה-CF/MIQ כולל התחברות לשרת PXE וניתן גם להתממשק ל-IPMI שיש בשרת, כך שהוא יכול להתקין מערכת עם Kickstart ולהריץ עליה אוטומציה לבצע דברים שדרושים לשרת.

ש: יש תמיכה ב-LDAP/Active Directory?
ת: בהחלט. מטרת המערכת בסופו של דבר לתת למספר אנשים גדול בחברה להיכנס ולמלא בקשות שונות ולמנהלים לתת הוראות ואישורים.

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

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

על דיסקים SSD בתצורת NVMe/PCIe

בשנתיים האחרונות נכנסה טכנולוגיית דיסקים (SSD) חדשה לשוק – טכנולוגיית ה-NVMe SSD (או PCI SSD – זה אותו דבר). רבים לקחו את עניין ה-SSD הנ"ל כמשהו שהוא יותר אבולוציה מאשר רבולוציה. עד היום היה לנו דיסקים SATA, NL-SAS, SAS ועכשיו יש לנו PCI/NVMe. לא?

זהו, שלא כל כך.

טכנולוגיית ה-NVMe משנה את כל עניין התקשורת של הדיסק SSD עם המחשב. בעבר בכל שרת שמכבד את עצמו היה בקר RAID שאליו היו מחוברים דיסקים. בחלק מהמקרים הדיסקים היו מחוברים ל-2 בקרי RAID, בחלק מהמקרים חצי מהדיסקים בשרת היו מחוברים לבקר אחד והחצי השני לבקר אחר, כל יצרן והשטיקים שלו.

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

בקרי RAID נועדו בראש ובראשונה ליצור לנו "אשכולות" של דיסקים שיחדיו יוכרו כ-RAID Volume. קח לדוגמא אנו יכולים לקחת מספר דיסקים ולבנות RAID 5, או 2 דיסקים ולבנות מהם RAID-1 או RAID-0 אם אנחנו רוצים לאכסן דברים שלא אכפת לנו שימחקו אם דיסק נפל (לדוגמא: Cache לאפליקציות). בקר ה-RAID גם "לקח אחריות" על כל מה שקורה מבחינת חיי ותקינות הדיסקים: בעיות כתיבה/קריאה? הוא יקרא מדיסק אחר. צריך לשמור נתונים בעת הפסקת חשמל? יש זכרון וסוללה על בקר ה-RAID וכך הנתונים ישמרו עד שיחזור החשמל וכשהוא יחזור הבקר יכתוב את הנתונים בצורה נכונה לדיסקים. זה הרעיון המרכזי של בקר RAID.

ב-NVMe לעומת זאת, הדיסק לא מדבר לשום בקר. הדיסק, כמו כל כרטיס PCIe, מדבר ישירות למערכת דרך ה-DMI, כלומר הנתונים עוברים ישירות אל הזכרון (RAM) בשרת וכך נחסך כל ה"תיווך" של הבקר.

אבל עדיין – כמו שכולנו יודעים – צריך בקר לאמצעי אחסון. יש תקלות קריאה/כתיבה, צריך לשמור נתונים בעת הפסקת חשמל, וכאן בדיוק הסיבה מדוע דיסק NVMe הוא דיסק שהוא יקר מדיסק SATA SSD או SAS SSD. בתוך הדיסק עצמו יש בקר (בחלק מהמקרים עם מעבד ARM בעל 2 או 3 ליבות) שכבר מטפל בכל עניין תעבורה ותחזוקת הנתונים. הדיסק עצמו מחולק פנימית ל-RAID-0 (רק בניגוד ל-RAID-0 רגיל, במקרה ויש תקלה בנתונים, הבקר יודע לטפל בה מבלי שהנתונים ינזקו), יש "סופר כבלים" (Super Capacitors) שיודעים לשמור נתונים במקרה של הפסקת חשמל, ומבחינת ביצועים – ה-NVMe ל-Enterprise נע בסביבות ה-2.4 ג'יגהבייט כתיבה לשניה ו-3 ג'יגהבייט קריאה לשניה. יותר זריז מכל SSD RAID שתכינו!

ומה לגבי עמידות/שרידות? הרי לא תסכימו לזרוק את כל הנתונים על דיסק אחד מבלי שיהיה לכך איזה סוג של בטחון, והתשובה לכך נקראת DWPD או Endurance (תלוי ביצרן דיסקים). ה-DWPD מציין כמה פעמים אתה יכול לכתוב על כל הדיסק נתונים ביום והדיסק עדיין יהיה תקין. קחו לדוגמא את ה-DC P3600 של אינטל, שמתאים ל-Enterprise: אם נניח מדובר בגירסת 2 טרהבייט, אז אתה יכול לכתוב עליו עד 6 טרהבייט ליום (מחיקה וכתיבה) והדיסק יעבוד טוב ויעמוד באחריות יצרן.

אז כפי שניתן להבין – אין כיום שום בקר RAID לדיסקים PCI SSD ושיטת העבודה צריכה להיות שונה. חושבים לדוגמא להרים ESXI על מערכת עם 2+ דיסקים כאלו? בהצלחה, תצטרכו לפרמט כל דיסק כ-Datastore בפני עצמו. לעומת זאת, אם אתם מרימים מערכת הפעלה Windows, ודאו שמדובר ב-Windows 2012 ואם זה לינוקס אז Ubuntu LTD האחרון או RedHat/CentOS 7 ומעלה. בתוך מערכת ההפעלה תוכלו לבחור את הדיסקים ולהקים את ה-RAID שרציתם (ותרו על RAID-0 – לא תקבלו ביצועים יותר גבוהים בגלל הארכיטקטורה של NVMe ו-RAID-5 יהווה בזבוז ושחיקת דיסקים לשווא). כמובן שלשם כך יהיה כדאי לצרף לשרת דיסק SSD שאינו NVMe/PCIe כדי להתקין עליו את מערכת ההפעלה.

באם אתם חושבים להרים שרת קבצים (לא חשוב איזו מערכת הפעלה) שתהיה מאוד מהירה וניתנת לגידול בהוספת דיסקים או JBOF – אז מערכת מבוססת דיסקים כאלו (ועדיף שתהיה מחוברת לכרטיסי רשת 10 ג'יגהביט ומעלה בלבד!) תהיה פתרון מעולה. אם אתם רוצים פונקציות כמו הסטורג'ים הגדולים (טוב, לפחות חלק מהפונקציות) כמו DeDup, Compression וכו' – כדאי לחשוב על ZFS.

לסיכום: דיסקים PCIe SSD הם ההווה והעתיד בכל מה שקשור לביצועים. זה לא אומר שצריך לזרוק את כל הדיסקים SAS לפח (מגנטי או SSD) אבל אם משלבים את ה-NVMe SSD כדאי לקחת בחשבון את היתרונות שלו ולהיערך בהתאם ואם אתם קונים שרתים חדשים, אני ממליץ לוודא כי ניתן להכניס אליהם דיסקים של יצרנים אחרים (במיוחד סמסונג, סאנדיסק ואינטל – כולם מאוד אמינים, מנסיון) ואתם לא "נעולים" רק על הדיסקים שמשווק יצרן השרתים שלכם (כמו HPE דור 9) מכיוון שהתחרות בשוק כיום מאוד אגרסיבית והמחירים צונחים משנה לשנה בעשרות אחוזים. דיסקים כאלו גם יכולים להוות בסיס טוב אם אתם רוצים להרים אשכולות (Clusters) מכיוון שכל דיסק נחשב כמספר דיסקים+בקר RAID. השמיים הם הגבול.

אהההמ.. ואם אתם רוצים להקים "חייה" של דיסקים NVMe, תכירו את המכונות האלו של SuperMicro 🙂

כשרוכשים SSD לשרתים

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

אחת הבעיות שיש כיום היא שלרבים אין כל כך מושג מה זה אומר SSD. כולם כמובן יודעים שדיסק קשיח מכני הוא דיסק המורכב ממספר פלטות, ראשים מגנטיים, ובקר בתוך הדיסק עם זכרון מטמון קטן (בין 16 ל-256 מגהבייט, תלוי בדיסק ולאיזה שוק הוא משוייך כמובן). כולם יודעים שכשזה מגיע לשרתים – אתה צריך בקר RAID טוב, חלקם ירכשו בקר עם סוללת גיבוי וזכרון מטמון נוסף – והעיקר כשרוכשים דיסקים מכניים – חשובה מהירות הסיבוב (10,15K RPM), חשוב סוג החיבור (SAS, SATA) ועוד כמה פרמטרים קטנים כמו PMP, Dual Connection וכו'.

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

מאמר זה יתן מספר מושגים לגבי תכנון ורכישה של דיסקים SSD. בכדי להתחיל אני ממליץ לקרוא את המאמר הזה באתר של Seagate. המאמר הזה מסביר איך מאוחסנים הנתונים, מה זה "איסוף זבל" (Garbage Collection), מה זה Over Provision (בקיצור: OP) ומה היתרונות. המאמר קצת ישן וחלקו לא עדכני לגבי הטכנולוגיות כיום, אבל הוא מצליח להעביר את המידע בצורה קלה ולפיכך הוא מומלץ לקריאה ע"י כל איש IT/איש סיסטם ללא קשר למערכת ההפעלה.

[stextbox id="info" caption="הבהרה"]במאמר זה אני משתדל לתת כמה שיותר הסברים. יחד עם זאת, חלק מהשרותים שעבדכם הנאמן מוכר הוא יעוץ בחומרה ולכן בפוסט זה לא אפרט שמות, דגמים, מחירים, נציגים בארץ וכו'. מקווה שהדבר יתקבל בהבנה מצד הקוראים.[/stextbox]

תכנון ראשוני

כשאנחנו רוצים לקנות שרת עם דיסקים מכניים, ההחלטה על כמות הדיסקים היא די קלה. אנחנו מחליטים איזו תצורת RAID נשתמש (1,10,5,50 וכו') וכמות המקום הרצויה לפי חישוב ה-RAID. אחרי שאנו יודעים על כמות המקום שאנו רוצים, אנחנו בוחרים בהתאם לתקציב את גודל הדיסקים, מהירות, סוג חיבור, בקר RAID יעודי בחלק מהמקרים וכו'. מכאן אנחנו ממשיכים בבחירת חלקים אחרים (מעבדים, זכרון, תקשורת, גודל שרת מבחינ U וכו')

כשזה מגיע ל-SSD, התהליך הוא שונה לחלוטין.

הדבר הראשון שאנחנו צריכים לדעת זה מה השרת עומד להריץ וגם מהו יחס הכתיבה/קריאה. לא חשוב אם אתה צריך 2 טרה מקום או 50 טרה מקום – זה הנתון הכי חשוב. מדוע? מכיוון שישנם 3 סוגי SSD בכל הקשור לעומס העבודה.

Read Intensive

ב-Read Intensive מדובר על כך שהשרת יותר יקרא מידע מה-SSD מאשר יכתוב ביחס של 70% קריאה, 30% כתיבה. לדוגמא: אם יש לנו שרת SQL מפלצתי שמכונות אחרות מחוברות אליו ורוב הזמן קוראות ממנו מידע ופה ושם גם כותבות מדי פעם רשומות – אנחנו נבחר SSD שהוא Read Intensive (רוב דגמי ה-SSD בשוק שיותר זולים הם Read Intensive)

Mixed Intensive

כשיש לנו שרת שמבצע כתיבה וקריאה (ביחס של 50% קריאה 50% כתיבה) אנחנו נבחר SSD שהוא Mixed Intensive. דיסקים כאלו מתאימים למצבים שבהם אנו לא רק קוראים הרבה, אנחנו גם כותבים הרבה. לדוגמא: אם יש לך מכונת ESXi עם דיסקים SSD מקומיים ואתה בכל יום מוחק כמה VM ויוצר VM חדשים (Full Clone או מ-אפס) אז דיסקים כאלו יתאימו לסיטואציה הזו.

Write Intensive

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

כמות המקום שאנחנו צריכים

כפי שציינתי לעיל, בדיסקים מכניים כמות הדיסקים שנצטרך לרכוש תלויה לפי חישוב ה-RAID ולפי חישוב הדיסקים. נניח שבדיסקים מכניים אנחנו צריכים RAID 5 ו-10 טרהבייט מקום, אנחנו נרכוש 6 דיסקים שכל אחד מהם הוא 2 טרה או 11 דיסקים של 1 טרה (פחות או יותר, דיסקים SAS מגיעים בגדלים ש"קופצים" ב-300 ג'יגה, אז אנחנו בעצם נרכוש 12 דיסקים של 900 ג'יגה שיתנו לנו ברוטו של 9.9 טרה).

גם כאן, ב-SSD החישוב שונה. כשיצרן מצהיר על גודל דיסק SSD לדוגמא בגודל 1.2 טרהבייט, הדיסק בעצם בגודלו האמיתי הוא 1.4 (בערך) טרהבייט, רק שהיצרן שומר מקום ל-Over Provisioning (אזור בדיסק שבו אנחנו לא נשתמש אך הבקר הפנימי ב-SSD כן ישתמש לצרכיו), אולם יש יצרנים שמציינים את הגודל כ"ברוטו", כלומר דיסק SSD של 500 ג'יגהבייט אולם הכמות כוללת את ה-OP.

כלל האצבע שאני ממליץ הוא "לחתוך" מהדיסק בערך כ-10-20% כך שמתוך 1 טרהבייט, ישארו למערכת 800-900 ג'יגהבייט. כך אנחנו נמשיך לקבל לאורך זמן ביצועים טובים מה-SSD. במבט ראשון זה נראה כמו "מכה" (בכל זאת, אם קנית 10 דיסקים של 1 טרהבייט, אז "זרקת" 2 טרהבייט וזה עוד לפני חישובי RAID!), אבל ה"מכה" הזו משתלמת לאורך זמן.

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

כמות כתיבה יומית

דיסקים SSD אינם כמו דיסקים מכניים שאפשר לכתוב עליהם חופשי כמה שרוצים. הבקר שב-SSD לא רץ כל שניה לכתוב את קובץ ה-10K שכתבתם כרגע. הקובץ ישב בזכרון (DRAM) של ה-SSD ובפעילות הכתיבה הגדולה הבאה הוא יכתב, כך שבקר ה-SSD עושה את הכל כדי לחסוך בפעולות הכתיבה. לעיתים הוא דוחס מידע, ולעיתים הוא עושה פעולות אחרות (תלוי בבקר SSD). לפיכך, אחד הפרמטרים החשובים שאנחנו צריכים לדעת הוא כמה בהערכה גסה אנחנו הולכים לכתוב על הדיסק ביום. האם אנחנו הולכים לזרוק על דיסק 500 ג'יגהבייט כ-300-400 ג'יגהבייט ליום? או שאנחנו אולי נכתוב כמה עשרות ג'יגהבייט מקסימום ליום? המושג נקרא DWPD והוא ר"ת של Disk Write Per Day, והוא מציין במספרים כמה פעמים אתה יכול לכתוב על כל הדיסק ביום. דיסקים SSD פשוטים נותנים לדוגמא משהו כמו 0.3. שימו לב: אם אתם "חונקים" מדי יום את הדיסק בכתיבות, אתם עלולים לגרום לאחריות שלכם להסתיים הרבה יותר מוקדם ולכן חשוב לבדוק את הנושא כשבוחרים דיסקים SSD.

SAS? SATA? NVME?

כמו בדיסקים מכניים, גם דיסקים SSD מגיעים במספר חיבורים אם כי כמו שציינתי, SAS כבת "מת" בדיסקים SSD מהסיבה הפשוטה שהחיבור עצמו איטי מדי בהשוואה למה ש-SSD נותן, לכן נשארנו עם SATA או NVME.

אני מניח שחלק מהקוראים כרגע כבר אומרים לעצמם "בשום מצב לא SATA". אין לו Queue לפקודות SCSI, ויש הרבה דברים של-SAS יש ושלא קיימים בפרוטוקול SATA וזה נכון אבל אם תסכלו בקטלוגים של SSD ל-Enterprise תמצאו שחלק נכבד מהדיסקים הוא בחיבור SATA (במהירות של .. 6 ג'יגהביט). מדוע? מכיוון שאותו "תור" וריבוי ערוצים שנמצא ב-SAS מתאים לדיסקים מכניים שבהם כמות ה-IOPS שאנחנו מקבלים היא מקסימום תלת ספרתית מאוד נמוכה (סביב ה-120-150 IOPS) וריבוי ערוצים מעלה את זה ל-300 IOPS ויותר – אבל עדיין תלת ספרית, אך דיסק SSD בחיבור ה-SATA הפשוט נותן IOPS של 5 ספרות, כלומר מה שלא מקבלים בריבוי ערוצים, מקבלים במהירות.

דיסקים מבוססי NVME הם בעצם כרטיסים שמתחברים בחיבור מיוחד שנקרא U.2 (לשעבר SFF-8639) ל-PCIe בלוח האם, כלומר אלו דיסקים עצמאיים (תיכף נגיע לזה) שאין בינם לבין SSD אחרים מבוססי חיבור NVME – שום דבר. נסו לדמיין שאתם מכניסים 2 כרטיסים גרפיים ללא SLI. אותו דבר.

מה שמביא אותנו ל….

RAID

כשזה מגיע לדיסקים SSD מבוססי SATA, הסיפור פשוט. מחברים ל-RAID שבלוח האם או לכרטיס בקר יעודי (שימו לב להגדרות Cache בבקר, בחלק מהמקרים עם דיסקים SSD SATA שונים יתכן ותצטרכו לבטל את ה-Cache). מגדירים את הדיסקים לפני כן ל-OP שאנחנו קובעים (אני ממליץ לחשוף את הדיסקים כ-JBOD ב-RAID, להעלות לינוקס מ-CD או כרטיס SD ולעשות זאת עם פקודת hdparm ורק אז לבנות בבקר RAID את ה-RAID שאתם רוצים תוך כדי שמוודאים שהבקר "רואה" את הדיסק בניכוי ה-OP שהגדרתם) ומתחילים התקנה של המערכת שאתם רוצים.

הנה טיפ קטן: לא להגדיר דיסקים SSD כ-RAID-5,6,50,60 אלא אם אתם רוצים נחיתה מאסיבית בביצועים. היצרנים ממליצים RAID-0, RAID 1 או מקסימום RAID-10 (לעשירים מביניכם).

כשזה מגיע ל-NVME לעומת זאת תצפה לכם הפתעה. אין RAID. גם אם ממש תרצו, אין RAID בחומרה (למען האמת יהיה בקרוב, חברת AVAGO מוציאה צ'יפ לזה אבל גם אז אל תצפו לביצועים משהו, דיסקים SSD בחיבור NVME יודעים לחנוק DMI בקלילות). מדוע אין? כי אלו SSD שיכולים "לחנוק" את ה-DMI בקלילות. SSD מבוסס NVME מעביר בממוצע כ-2 ג'יגהבייט בשניה (אם תתנו לו סיבה) וה-DMI 3.0 שקיים בשרתים מודרניים יכול מקסימום להעביר 3.93 ג'יגהבייט בשניה, כלומר מספיק 2 דיסקים SSD בחיבור NVME "לחנוק" את השרת.

אז מה עושים עם השרידות? חושבים קצת אחרת. בדיסק SSD בחיבור NVME ל-Enterprise יש שרידות הרבה יותר גבוהה בהשוואה לדיסקים מכניים. "סקטורים" פגומים? הבקר ידע להעביר לבד את הנתונים לאזור תקין. יש Fragment? הבקר ידע להעביר בזמנו החופשי את הנתונים ולסדר אותם (במסגרת ה-Garbage Collection). הפסקת חשמל? יש "סופר קבלים" על ה-SSD ששומרים את המידע על ה-DRAM עד שהחשמל חוזר. בקיצור (ואני אומר את זה מנסיון) – יקח לכם המון המון מאמץ להרוס SSD מבוסס NVME שמיועד ל-Enterprise. בגלל זה האחריות עליהם היא ל-5 ולחלקם 10 שנים.

נקודה חשובה נוספת: הפופולריות של NVME עברה "מתחת לרדאר" של יצרני שרתים. (הח"מ סיים לפני מספר ימים שיחות עם נציגי חברת SuperMicro כדי שיוציאו כרטיס PCIe עם PLX כך שניתן יהיה לחבר 4 דיסקים SSD עם NVME למכונת PC. בשרתים זה יותר מסובך כי ה-Backplane לא "יודע" מה זה חיבור U.2) ולכן רובם מאפשרים גם במכונות החדשים מספר קטן של כונני SSD בחיבור NVME. ב-DELL ו-HP כמדומני המקסימום הוא 4 דיסקים והשאר SAS מכני או SATA מכני או SSD. לכן אם אתם רוצים מכונה שתהיה "מפוצצת" ב-SSD בחיבור NVME, צרו קשר עם חברת SuperMicro לדוגמא.

לכן, אם אתם מתכננים לדוגמא להרים ESXi עם NVMe, תשכחו מ-RAID. (מה לעשות, ESXi לא תומך אפילו ב-RAID תוכנה, לא חשוב כמה תנסו). או שתשתמשו בדיסקים SSD בחיבור SATA או שתבנו Datastores שונים על כל NVMe ומשם תרפלקו לכם עם Veeam או כל תוכנה אחרת VM חשובים.

חסכון

(הנה מילה ששומעים הרבה ב-IT ומצווים לכך … ותמיד אפשר לשמוע על איזה מנהל שהחליט לקנות מפלצת שהניצול שלה יהיה 10% ממה שהיא יכולה לנפק)

הבדל המחירים בין SSD לצרכן לבין SSD ל-Enterprise הוא הבדל שנע בין 50-300%. עם SSD שהוא NVME בחיבור PCIe אתם בקלות מגיעים לאלפי דולרים עד עשרות אלפי דולרים וכמובן שהדיסקים האלו נותנים ביצועים מהממים – IOPS של 6-7 ספרות, אבל מה לעשות שברוב המקרים תגישו הצעת מחיר כזו והמנהל יתהה לגבי בריאותכם הנפשית.

ה"סוד" הגדול וההבדלים לדוגמא ב-SSD בין גירסת הצרכן לגירסת ה-Enterprise נעוץ במספר דברים:

גירסת ה-Enterprise כוללת "סופר קבלים" לשמירת הנתונים שעדיין לא נכתבו – בעת נפילת מתח
בגירסת ה-Enterprise – השבבים שעליהם נשמרים המידע הם בתצורת MLC (למי שלא ידע, SLC כבר מת) או eMLC.
בגירסת ה-Enterprise – הבקר הוא הרבה יותר חכם
בגירסת ה-Enterprise – הם מוצעים גם בחיבור SATA וגם כ-NVME (כאשר יש תהום של ביצועים בין ה-2)
בגירסת ה-Enterprise – האחריות היא בין 5 ל-10 שנים.

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

כדאי ללכת על שבבים שהם 3D NAND (כמו של סמסונג או טושיבה) כל עוד מדובר על MLC. ליצרן זה חוסך שבבים והמחיר יורד. אם מדובר על מכונה שרוב הזמן יקראו ממנה, אפשר גם לבחור SSD שיהיה מבוסס על צ'יפים שהם TLC אך כדאי לזכור – במקרים כאלו הכתיבה תהיה איטית (יחסית).
אם יש UPS – אז נוכל לוותר על ה"סופר קבלים"
אפשר להסתפק גם ב-1-3 שנים של אחריות במקרים מסויימים.
חיבור SATA מספיק

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

העתיד

כשזה מגיע להתפתחות טכנולוגיית ה-SSD, אפשר לאמר שהיא מתפתחת בקצב מהיר. אינטל וחברת מיקרון עובדות על XPoint – טכנולוגיה שתתן ביצועים פי כמה וכמה מהירים מכל SSD שקיים כיום. סמסונג עובדת גם על פתרון שתחשוף אותו בסוף השנה או בתחילת השנה הבאה (עקב NDA אינני יכול לפרט), וגם טושיבה, WD/Sandisk עובדות על טכנולוגיות אחרות לשמירה/קריאת נתונים הרבה יותר מהירות מכל שבב FLASH NAND שקיים כיום. כל החברות במקביל עובדות על טכנולוגיות תלת מימד (3D) עם מספר דו ותלת ספרתי של שכבות על מנת להוציא SSD עם הרבה יותר מקום (סמסונג הוציאה לאחרונה דיסק של 15 טרהבייט במחיר "עגול" של … $10000).

אחת הטכנולוגיות החדשות שבקרוב "תסתער" על השוק (במיוחד שוק הוירטואליזציה, קונטיינרים ועוד) היא טכנולוגיית ה-MVMEoF (כלומר NVME Over Fabrics). כיום, כשאנחנו רוצים לייצא חלק מהדיסקים לשרתים, אנחנו עושים זאת בעזרת טכנולוגיות כמו NFS, SMB או iSCSI אך איננו מקבלים את כל המהירות ש-SSD בחיבור NVME מקבלים. עם NVMEoF המהירות שנגיע לנתונים תימדד בננו שניות, כאילו הדיסק יושב פיזית במכונה (כמובן שלשם כך יהיה צורך בהחלפת תשתיות – 40 ג'יגה Ethernet כמינימום, כרטיסי רשת שמבצעים Offload ל-TCP כמו של מלאנוקס ואחרים) ויש עוד כמה דברים בצינור.

עוד תחום נוסף מעניין הם דיסקים SSD חדשים ש"ישתפו פעולה" עם מערכת ההפעלה ויתנו למערכת ההפעלה בעצם לנהל את הדיסק ובכך להעביר את רוב הלוגיקה של הבקר – למערכת ההפעלה. הפרויקט נקרא Open Channel SSD והמימוש שלו נמצא בקרנל 4.4 בלינוקס (עדיין לא ב-Windows). עדיין אין כוננים כאלו אך כל היצרנים משתתפים בפרויקט.

לסיכום

דיסקים SSD הם ההווה ועתיד. זה כמובן לא אומר שדיסקים מכניים הולכים למות (רחוק מכך, הם מצטיינים בגדלים ובמחירים זולים יותר מ-SSD, כרגע לפחות) אבל מצד שני טכנולוגיית ה-SSD עברה את סף ה"נסיון" והיא יציבה יותר מדיסקים מכניים, שלא לדבר על כך שמבחינת מהירות כתיבה וקריאת נתונים – היא עוקפת כל דיסק מכני גם בחיבור SAS. ה-SSD גרם לטכנולוגיה חדשה כבר למות (SATA Express) וטכנולוגיית ה-NVME מחברת את ה-SSD (דרך U.2 או ככרטיס PCIe או בחיבור M.2 – פוסט על M.2 יופיע בקרוב) ישירות ללוח אם תוך עקיפת צורך בבקר כלשהו או בצורך "מנהל" כלשהו – ה-SSD מבוסס NVME עושה הכל, (רק כדאי לוודא שה-BIOS/UEFI תומך ב-NVME) – והיא נותנת ביצועים שנמדדים בג'יגהבייטים תוך מתן עשרות אלפי IOPS.

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

עדכון: לאחר פרסום המאמר הופנו אליי שאלות שנענו בפוסט ההמשך כאן.

כמה מילים על Thin Client ל-Citrix

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

ל-2 סוגי הפתרונות הנ"ל יש יתרון בכך שקל יחסית לנהל אותן, הן מבחינת הגדרות מערכת, והן מבחינת נעילה וכו', אולם ישנן כמה נקודות שכדאי לתת עליהן את הדעת:

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

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

כיום ישנו גם פתרון שהוא יותר זול.

למי שלא מכיר – זהו ה-Raspberry Pi-3 (מודל B). זהו מחשב בגודל קטן מאוד עם כמות זכרון של 1 ג'יגהבייט והוא מריץ מערכת Linux ויש לו גם Client מלא ל-Citrix עם כל הפונקציות פעילות. הוא יכול לשמש בעקרון כ-Thin Client מאוד זול ולהתאים לחברות…

… בערך …

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

HDX-READY-Pi

תכירו את Viewsonic SC-T25: זהו המוצר של חברת Viewsonic ובתוכו יש בדיוק את אותו Raspberry Pi-3 Model B, אך כאן מדובר למוצר שמיועד לחברות. יש לו מערכת הפעלה לינוקסאית הכוללת ניהול מרכזי והמכשיר תומך בכל הפונקציות של Citrix. המכשיר ישווק בקרוב במחיר הכרות של 89$ לקופסא (בחו"ל).

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

דוגמא אחרת שחשובה לאבטחה וקשה לבצע בקופסאות סגורות אחרות: רוב הקופסאות מגיעות עם 4 כניסות USB אבל המשתמש מנצל רק 2 (מקלדת, עכבר) או 3 (כרטיס חכם או מתאם USB->Serial). נשארה כניסה אחת או יותר פתוחה ואנו רוצים לנעול על מנת שהמשתש לא יכניס ציוד לא מורשה. בעזרת סקריפט פשוט (דוגמא: כאן) אפשר לכבות את הכניסות האלו כך שגם אם יוכנס ציוד, המערכת לא "תראה" אותו ולא ניתן יהיה להפעיל אותו, וניתן להוסיף עוד 1001 דברים שירוצו על הקופסא או מחוץ לקופסא כדי להרחיב את השימוש בהתאם לצרכי החברה. (אגב, בקרוב ל-Pi תהיה תמיכת PXE כך שלא יהיה צורך לעדכן שום דבר בקופסא. מכבים, מדליקים, הקופסא מוכנה לשימוש).

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

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

[stextbox id="info" caption="הבהרה"]לי אין קשר ל-Viewsonic או ליבואן ופוסט זה נכתב מהאספקטים של לינוקס, אבטחה וניהול יותר קל של Citrix Clients.[/stextbox]

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

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

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

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

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

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

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

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

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

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

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

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

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

על 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. להלן דוגמא ממערכת טסטים בביתי (לחצו להגדלה):

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

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

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