בשעה טובה אתמול
סופסוף שוחררה גירסת 4.6 של מוצר ה- Application Virtualization של מיקרוסופט.
כמה מהיכולות המרכזיות של הגירסא החדשה הן התמיכה במערכות הפעלה x64 – כולל Windows Server 2008 R2 – והתמיכה ב- Windows 7 (גם גירסת 32 ביט וגם 64), כולל תמיכה ב- Jump Lists החדש.
שתי יכולות נוספות שעניינו אותי יותר היו דווקא התמיכה ב- Windows 7 Branch Cache
ו- Read Only Cache Mode עבור הטמעות בסביבות VDI.
יכולת ה-
Branch Cache שהוצגה ב- Windows Server 2008 R2 וב- Windows 7 מאפשרת למשתמשי הסניפים המרוחקים של הארגון “לשתף” את המידע שהגיע מהסניף הראשי, למעשה כאשר משתמש מסוים פונה לסניף הראשי כדי לקבל קובץ מסוים, אותו ה- Branch Cache בודק האם אותו הקובץ כבר עבר לפני לאחד מהמשתמשים האחרים באותו הסניף, ואם כן, אותו משתמש מופנה לעותק המקומי של הקובץ, ללא צורך לעשות את הדרך הארוכה עד למשרד הראשי. מה שנחמד בעניין שזה יכול לעבוד בשתי צורות, Hosted Cache Mode – מצב בו יש שרת בסניף המרוחק ששומר למעשה את ה- Cache. ו- Distibuted Cache Mode – מצב בו המחשבים בסניף משתפים למעשה את התוכן שהורידו מהסניף הראשי לטובת שימושם של משתמשים אחרים בסניף (למתעמקים).
כדי לאפשר לארגונים להטמיע App-V גם בסניפים המרוחקים שלהם, ה- App-V 4.6 מוסיף לעצמו את היכולת לעבוד עם ה- Branch Cache (שימו לב, רק לקוחות עם Windows 7), כלומר כל תוכן שימשך מהסניף המרכזי ע”י פרוטוקול RTSP של App-V ישמר ב- Branch Cache לטובת שימושם של משתמשים נוספים מאותו הסניף.
ה- Read Only Cache Mode מאפשר להחזיק Cache משותף של האפליקציות למספר משתמשים שונים,
ללא אותו Cache משותף ה- Streaming Cache נשמר לכל משתמש במחשב ממנו הופעלה האפליקציה.
אבל אופן העבודה הזה לא מתאים לסביבות VDI, שם לכלל המשתמשים יש אימג’ מרכזי שלא ניתן לשינוי על ידם ועוד שטח אחסון לשמירת הפרופילים שלהם.
אם כל משתמש ישמור את ה- Streaming Cache בפרופיל שלו תיווצר למעשה סוג של חוסר יעילות (מספר רב של משתמשים שומרים מידע זהה בפרופיל שלהם). ה- Read Only Cache בא לפתור הפלונטר, הוא מאפשר ליצור את ה- Cache פעם אחת לכל האפליקציות, להעתיק אותו למקום מרכזי ברשת ולהגדיר לקליינטים בתוך מכונות ה- VDI לקרוא את ה- Cache מאותו מקום מרכזי. זה לא יתאים לכולם – למשל אי אפשר למשתמשים לעשות שינוי באפליקציה (FSD) – אבל עדיין feature נחמד.
ואם כבר ב- App-V עסקינן, אז איכשהו פיספסתי את ההכרזה של מיקרוסופט על כך שרשיונות ה- App-V CAL כלולים ברשיונות ה- RDS\TS CAL של Windows 2008 ו- Windows 2008 R2, מה שזה אומר בעצם זה שכל מי שקונה RDS CAL לטובת עבודה בתצורת TS מקבל יחד איתו את הרישיון עבור הפעלת אפליקציות App-V בתוך ה- Sessions (
עוד על העניין).
עד אותו שינוי (למעשה רלוונטי ל- TS 2003 CAL) אם הינו רוצים לעבוד עם App-V על שרתי ה- TS, הינו צריכים לרכוש App-V CAL.
השינוי בעצם “מעבה” עוד יותר את הפיתרון ה- TS של מיקרוסופט שכבר יכולות כמו
Seamless Applications, Web Access, Load Balancing ואחרות, ועל ידי כך מאפשר ללקוחות נקודת פתיחה טובה יותר לפני חיפוש יכולות משלימות בחברות אחרות. ד”א, מבין אלו שמייצרות פיתרון משלים ל- Windows TS, רק Citrix מציעה אפשרות של Application Virtualization בתוך המוצר – יכולת ה- Streaming Application של
XenApp – כל השאר (
Jetro Cockpit\
Quest vWorkspace\
Ericom\
2X ואחרות) מסתמכות על App-V או לא מציעות פיתרון כלל.
סיסקו מכריזה מלחמה:
למעשה מאז הכרזת קו השרתים של סיסקו – ה-
UCS – ועוד יותר
החבירה של VMware, EMC וסיסקו ביחד היה ברור לכולם שהברית המשולשת (ברית אקאדיה) וכל חברה בה לחוד נמצאת בבעיה עם השותפות הגדולות שלה, הלא הן Dell, IBM ו- HP. למעשה אם נהיה יותר מדויקים, VMware וסיסקו היו בבעיה הגדולה ביותר.
בואו נסתכל על
HP כדוגמא, שנכון לעכשיו היו השותפה הגדולה ביותר של
VMware ושל
סיסקו. היא מוכרת רשיונות ומוצרים של שתי החברות, מטמיעה את המוצרים ונמצאת בקשר הדוק מאוד עם השתיים
(Rodmaps וכו’), הקשר ההדוק הזה מהווה למעשה בעיה לברית אקאדיה ש- HP נהיתה המתחרה הישירה שלה – הרי ה- UCS מתחרה ישירות בפתרונות השרתים, האחסון והתקשורת של HP – וזה אכן מצב לא ממש רצוי שהמתחרה שלך יהיה מודע ל- Roadmap של המוצרים שלך.
עקב זאת, סיסקו החליטו לצנן משהו את היחסים ולהתאים אותם למצב היחסים החדש שנוצר – דרך אגב, אני חושב שמי שעושה שם את כל הבלגן זוהי EMC שלה אין שום דבר להפסיד בתצורה הנוכחית – HP עדיין תיהיה שותפה של סיסקו, אבל הסטאטוס שלה ירד, זאת כמובן כדי לשמור על הערוץ הזה עדיין פתוח, לפחות עד החיבור של
3com לתוך HP.
המעניין הוא זה לווא דווקא הצעד הנוכחי של סיסקו (למרות שהוא מעניין מאוד כשלעצמו), אלה השאלה האם זה תקדים למה שאנחנו צפויים לראות גם מהצד של VMware בעתיד, האם גם VMware תעשה דרך דומה ותיפרד מ- HP.
להזכירכם
לפני כחודש HP ומיקרוסופט חתמו על הסכם שיתוף פעולה בתחום הוירטואליזציה, סוג של מענה לברית אקאדיה המפורסמת (למרות שהן לא יודו בזה בפה מלא). ההסכם אמור לחזק מאוד את שיתוף הפעולה בין שתי החברות בכל תחום הוירטואליזציה ומחשוב ענן. מוצרים משותפים, צוותים שעובדים בשיתוף פעולה, תכנון Roadmaps משותפים וכו’, you name it.
אבל, מהצד השני HP גם שותפה של VMware, כזאת שעל השרתים שלה מותקנים רוב שרתי VMware בעולם ואשר מוכרת את רוב הרשיונות של VMware. כמובן שלכל זה נלווה קשר מיוחד בין שתי החברות – עבודה של צוותי הפיתוח לאינטגרציה מלאה של הפתרונות וכמובן גישה ל- Roadmap של המוצרים – והנה, הגענו לאותו נקודה שבה סיסקו היתה כשקיבלה את ההחלטה, שלא הגיוני לאפשר למתחרה הישיר שלך גישה רבה כ”כ למה שמתרחש אצלך בבית.
וכן, ההסכם עם מיקרוסופט יכול להתפרש – אולי לא עכשיו, אבל בטוח בעתיד - ככזה שנותן ל- HP יכולות שמתחרות ישירות באלה של VMware.
המצב שנראה בעוד זמן לא רב כ”כ לפי דעתי זה התכנסות של ברית האקאדיה בתוך עצמה (תוך “שריפת” שותפויות עבר) ומהצד השני הרחבת הפורטפוליו של HP ודומיה לכזה שיוכל להיות תחרותי במצב החדש.
מהצד של VMware-EMC-Cisco נראה את ה- vBlock המפורסם (לא איטונג, לא קונה!) עם וירטואליזציה של VMware, שרתים ותקשורת של Cisco ואחסון של EMC.
ומהצד של HP נראה הפתרון שלה (נראה לי שקוראים לזה Matrix, אבל אל תתפסו אותי במילה) עם השרתים שלה, התקשורת שתיעשה עם Procurve,Qlogic ו- 3Com בעתיד הקרוב ופיתרון וירטואליזציה שנכון לעכשיו נראה שיהיה של מיקרוסופט (למרות שיש לי הרגשה שתיהיה לנו הפתעה בעניין והולכת להיעשות רכישה – או פיתוח - של מוצר לתחום הזה).
העיקר שלא משעמם :)
כולנו מכירים כבר את
החידושים של RDP 7 (או RDC אם תרצו) שהוכנסו כחלק מ- Windows 7 ו- Windows Server 2008 R2.
לפני כמה שבועות מיקרוסופט הוציאה מסמך אשר משווה בין הביצועים של RDP 6.1 לבין האח הבכור שלו, הלא הוא כאמור ה- RDP 7.
מה אפשר ללמוד מהנתונים?
-
כ- 25% פחות שימוש ברוחב ב- Session של RDP7 עם 32-bit צבעים. משום מה 27% ו- 8% אחוז יותר שימוש ברוחב פס ב- RDP 7 לעומת 6.1 בעבודה על קובץ וורד וגלישה עם Internet Explorer באיכות צבעים של 16-bit.
-
Session עם Font smoothing (האפשרות להצגה חדה יותר על גבי צגי LCD) צורך כמעט פי 2 יותר רוחב פס מאשר Session רגיל. החדשות הטובות הן שב- RDP7 העליה היא “רק” בסביבות ה- 80% יותר ברוחב פס.
-
יכולת ה- Desktop Composition שהוצגה עוד ב- Vista לתצוגה חלקה יותר של ה- Session (בגדול, התצוגה המגיעה מה- Session המרוחק לא מוצגת ישירות על המסך, אלה עוברת קודם כל דרך ה- DWM אשר אוגר את כל השינויים ומציג אותם ביחד) לא ממש משנה את כמות רוחב הפס בו עושה ה- Session שימוש.
-
תצוגת Silverlight נראת כדורשת מעט יותר רוחב פס מתצוגת Flash, אולי זה מסביר את זה שב- Silverlight נראים יותר Frames לשניה (17.3 באיכות צבעים של 32 ביט, ו- 13 ב-16 ביט) מאשר בפלאש (11.7 ו-9.3 בהתאמה).
-
משהו שהיה די ברור, אבל טוב שהוא הובהר. אין הבדל באיכות התצוגה כאשר נעשה Redirection של תצוגת המולטימדיה (במקרה הזה סרט במדיה פלייר) לתחנת העבודה ונעשה שימוש ב- Codec המקומי של ה- Client.
-
השפעות של Latency אמורות להשפיע פחות על RDP7 מאיך שהן השפיעו על 6.1. למרות שנבקד רק Latency של 100mSec, ה- delay שהיה ב- session של RDP7 היה נמוך בכ- 8% מאשר ב- RDP6.1. בסה”כ נרשם delay של אחוזים בודדים (סביבות ה- 5%) בין session עם latency של 100msec לבין session ללא latency בכלל.
אז אכן, נראה שנעשה שיפור משהו ב- RDP, אבל מה זה אומר בעצם? שזה אמור לתת סוג של אישור לארגונים להשתמש ב- RDS של מיקרוסופט ללא השלמות של Citrix\Quest\Ericom? או האם זה אומר שעכשיו כולנם ינהרו להטמיע את ה- VDI של מיקרוסופט? מממ… לא. בעיקר מכיוון שהתחרות בשני השווקים האלה (נגיד ונקרא להם TS ו- VDI) היא לא למי יש את הפרוטוקול הטוב ביותר – בכל מקרה בסביבות LAN הם כולם פחות או יותר זהים – אלה למי יש את היכולות הטובות ביותר בנושאים כמו ניהול מרכזי, ניהול פרופילים, ניהול עידכונים, הפצות, דיסק מרכזי, הקשר בין המערכות השונות ועוד. בעצם כל אותם הרכיבים/יכולות שמיקרוסופט משאירה לשותפים שלה להשלים.
אבל בכל זאת, ה- RDP 7 נראה הרבה יותר טוב מקודמיו, כבר טוב.
למסמך המלא