ב- 10 לספטמבר תשוחרר רישמית הגירסא החדשה של ה- Presentation Server (שכבר הספיק להחליף את השם ל- XenApp). זהו למעשה סופו של של פרוייקט Delaware שיצא לדרכו אי שם בתחילת 2006.

עם יותר מ- 50 חידושים ושינויים ולראשונה תמיכה ב Windows Server 2008, ה- XenApp 5  נראה מבטיח למדי. כמה features מרכזיים:

• שיפור במנגון ה- streaming application. מנגנון האפליקציות הוירטואליות שהוצג לראשונה בגירסא הקודמת (4.5) מאפשר ליצור אפליקציות אשר עובדות במאין בועה משל עצמן, מבלי להיות מותקנות פיזית על השרת או התחנה ומבלי להשפיע – או להיות מושפעות - על המערכת ה"מארחת" אותן, וכך למשל ניתן להריץ כמה גירסאות של אותה התוכנה (למשל Microsoft Office) ב session או מחשב אחד. בסביבות XenApp זה איפשר להחזיק חווה בה על השרתים לא היה מותקן דבר מלבד אפליקציית הבסיס של XenApp, כל האפליקציות להן המשתמש היה זקוק היו משוייכות לו, במקום להיות מותקנות פיזית על השרת.
  בנוסף על אלה, זאת היתה הפעם הראשונה בהCitrix סיפקה למשתמשים את היכולות להשתמש באפליקציות אשר הם מקבלים מחוות ה XenApp גם כאשר הם לא מחוברים לרשת.
  בגירסא הקודמת אם לקוח היה רוצה ליצור אפליקציה וירטואלית שתוכל להשתמש באפליקציות אחרות, לדוגמא אפליקציה וירטואלית של SAP שתוכל להשתמש ב Microsoft Office 2007, הוא היה צריך ליצור אפליקציה וירטואלית "גדולה" אשר מכילה גם SAP וגם Microsoft Office 2007, בלאגן לא קטן בניהול (למשל במקרה של עידכון ל Office, צריך לעדכן כל פעם גם את אותה האפליקציה הוירטואלית ה"גדולה" וכן את האפליקציה הוירטואלית הרגילה של ה Office). בגירסא החדשה נוספה האפשרות לקשר בין האפליקציות הוירטואליות, כלומר שאפליקציה וירטואליות תוכל "לדבר" עם אפליקציה וירטואלית נוספת (Inter-Isolation Communication).
  
• כדי לשפר את השימושיות, Web Interface שונה לחלוטין, ועכשיו הוא קיבל מראה web 2.0 עם יכולות כמו קוסטומיזציה כמעט מלאה של של ממשק המשתמש, מנגנון חיפוש ועוד.

• מנגון עדיפויות לפי משתמשים. מערכתית, אולי ה- Feature המעניין ביותר. עכשיו ניתן לתעדף משתמשים בחיבור ובעבודה בחווה (Preferential Load Balancing). משתמשים להם תוגדר חשיבות גבוהה יותר מאחרים, יקבלו עדיפות בהתחברות לשרתים וחיבור לשרתים הפנויים והמהירים ביותר בחווה.
  לדוגמא, רופא יוגדר עם עדיפות גבוהה יותר מאשר מזכירה בחוות XenApp בבית חולים מסוים, זאת כדי לספק לאותו הרופא את חווית המשתמש הטובה ביותר כדי שהוא יוכל לסיים את מטלותיו במהירות הרבה ביותר.
  

נוסף על אלה, תמיכה ב XPS, ClearType ועוד כ- 45 features נוספים נמצאים גם הם בין ה- Features החדשים של- XenApp 5.

עוד פרטים - כאן

פעם ראשונה שאני מוחק פוסט שלי, אבל כתבתי דברים שלא עזרו לאף אחד - וכתוצאה מכך לא תרמו לאף אחד שום דבר - והחלטתי לשכתב הכל מאפס. אז הנה,  הולך נושא הרישוי של שרתי Windows Server 2003\2008 ווירטואליזציה.
תיקונים והבהרות יתקבלו באושר גדול.

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

רשיון Windows Server Standard מאפשר הרצת מכונה פיזית/וירטואלית על גבי שרת פיזי אחד. למעשה לא שונה מאיך שכולנו מכירים את זה, רשיון לכל שרת. כדי להקל עוד יותר את ההבנה... מכיוון שכל רשיון משוייך למכונה פיזית למעשה כל רשיון מאפשר לנו הרצת instance אחד של Windows Server Standard על ה- hypervisor.

רשיון Windows Server Enterprise מאפשר הרצת ארבעה מכונות וירטואליות עם Windows Server Enterprise או גירסא נמוכה יותר על גבי ה hypervisor. אם מוצר הוירטואליזציה רץ על גבי Windows Server, למשל Virtual Server או VMware Server אז גם כאן, רשיון ה Enterprise שמשמש את מערכת ההפעלה "המארחת" מאפשר הרצת ארבעה מכונות וירטואליות נוספות על גבי השרת (כאמור, גירסת Enterprise ומעלה).

רשיון Windows Server Datacenter מאפשר הרצת מספר מכונות וירטואליות בלתי מוגבל (גירסת datacenter ומטה), כל קונסטלציה הולכת, כולן נמצאות על hypervisor שלא צריך מערכת הפעלה של Windows Server כבסיס או מצב בו מוצר הוירטואליזציה הוא Virtual Server או VMserver ודומיהם אשר צריכים מערכת הפעלה כדי לעבוד.

שוב פעם, מכיוון שהרישוי מתייחס ל instance על גבי השרת הפיזי, ניתן להחזיק מספר בלתי מוגבל של מכונות וירטואליות מכובות על גבי השרת הפיזי היחיד, הרשיון "ייתפס" רק ברגע בו הן יהיו דלוקות (תרתי משמע :) ). מכאן גם שאם אנחנו רוצים פיתרון של High Availabilty שיאפשר לנו "להזיז" מכונות וירטואליות בין שרתי hypervisors (לדוגמא XenMotion או Vmotion) נצטרך לדאוג מבעוד מועד לכך שהרשיון מתאים יחכה לאותו instance שאולי ירוץ על כל אחד מהשרתים. לדוגמא, אם יש לי שני שרתי פיזיים ושרת פיזי A מריץ עליו 3 מכונות וירטואליות של Windows Server Standard, אני צריך שיהיה לי רשיון מתאים אשר ישוייך לשרת פיזי B (שלוש Instances של standard).

הגיע הזמן להסתכל על מספרים... ניקח מקרה של חברה בעלת 6 שרתים פיזיים (נניח שהם מריצים Windows 2003 Server standard) ואשר מעוניינת להמיר את כולם לשרתים וירטואליים (גם פה אני מניח שנקנו שני שרתים חדשים לטובת העניין). כדי לפשט את העניין אני מניח שכל הרשיונות נקנו מחדש (רק לידע הכללי, במקרה של P2V אנחנו עושים את עצמנו שבאמת ישנו כשל חמור מאוד בחומרה של השרת הישן ומעבירים את הרשיון למכונה הוירטואלית החדשה גם בלי לחכות את מלוא תקופת ההפשרה, כאמור 90 יום, וזאת בהנחה שאנחנו באמת נפתרים מהשרת הפיזי הישן, או לפחות כבר לא מריצים עליו windows server).
אופציה ראשונה, כל 12 הרשיונות - כאמור, 6 כפול 2 בשביל HA - נקנו בגירסת ה Standard. מחיר לרשיון הוא משהו בסביבות ה 750$, מכאן שההוצאה לרישוי עומדת על 9000$. אני אחזור על זה, הרישוי הנ"ל מאפשר הרצת 6 "מופעים" של windows server standard על גבי כל אחד משני השרתים הפיזיים.
אופציה שניה, קונים רק 4 רשיונות windows server enterprise (שתיים לכל שרת) אשר מאפשרים הרצת עד 8 "מופעים" של windows server enterprise\standard על כל אחד משני השרתים הפיזיים.
2500$ לכל רשיון, ומכאן ההוצאה לרישוי היא כ- 10000$, אבל כאן אנחנו מקבלים את האפשרות להריץ עד ל 8 "מופעים" של windows server על כל שרת פיזי, כלומר מחיר הרשיון לכל שרת וירטואלי דווקא יורד יחסית לאם הינו רוכשים שמונה רשיונות standard נפרדים (625$ לכל אחד לעומת 750$), ומה עוד שכאן אנחנו יכולים להריץ גם 8 "מופעים" של windows server enterprise.
האופציה השלישית והאחרונה היא לקנות רשיון windows server datacenter לכל אחד משני השרתים הפיזיים שלו אשר יאפשר להריץ מספר בלתי מוגבל של שרתים וירטואליים על גבי כל אחד
מה hypervisors. רשיון datacenter עולה משהו כמו 2500$ לכל cpu socket - אין התחשבות בכמה cores יש לכל מעבד פיזי - ומכאן שאם אצל אותה החברה שני השרתים הפיזיים עם שני מעבדי quad, קניית רשיון datacenter לשני sockets לכל אחד מהם יעלה כמו קניית ארבעה רשיונות enterprise (להלן האופציה השניה) והפלוס המאוד גדול כאן הוא שאין שום הגבלה על מספר השרתים הוירטואליים שהיא תוכל להריץ על גבי כל אחד מהם, לא רע.

מכונות וירטואליות נעשות שכיחות יותר ויותר במרכזי המחשוב השונים, בהתאם לכך אנחנו עדים להתפתחות חזקה מאוד בתחום שרתי הוירטואליזציה, למעשה שרתי ה Hypervisor. סקירה קצרצרה של החבורה - VMware עם משפחת ה ESX, מיקרוסופט עם ה Hyper-V הדנדש, Citrix עם XenServer, אורקל, Sun, Parallels ועוד. פרט ל Citrix ומיקרוסופט אשר החליטו על אימוץ פורמט ה VHD של המכונות הוירטואליות במוצרים של שתי החברות - כהמשך ישיר של שיתוף הפעולה הרחב שלהן גם ככה - לא קיימת שום תאימות בין המוצרים השונים וככה מי שרוצה להטמיע מוצרי וירטואליזציה שונים בסביבה שלו נאלץ להשתמש בכלים צד שלישי בכדי לעשות את ההמרה בין הפורמטים השונים (זאת בהנחה כמובן שיש כלי להמרה בין הפורמטים הרלוונטיים וההמרה באמת גם עובדת בסופו של דבר).

כתגובה לדרישות הלקוחות - כן, אהה... - התאספו להן VMware, Xen Source, Dell, HP, IBM ומיקרוסופט כדי לחשוב מה אפשר לעשות בסוגיה, אחרי דיונים מרתוניים (ביל, שוב פעם הבאת בורקסים תפוח אדמה, כבר פעמיים אמרנו שאנחנו אוהבים גבינה) נולד לו ה OVF או Open Virtualization Format. אבל ניקח את הדברים בריצנות לשניה, סטנדרטיזציה של פורמט כזה היתה חייבת להיעשות בעיקר עקב הגדילה של ה Virtual Appliances.
Virtual Appliance הוא עוד תת תחום של הוירטואליזציה שהולך וגודל ויש הטוענים שהולך לשנות את איך שארגונים יעשו שימוש באפליקציות הארגוניות שלהן ואיך שספקי האפליקציות יספקו את אותן האפליקציות.
התצורה הוירטואלית של ה- Appliance שכולנו מכירים עכשיו - אותו רכיב חומרה המכיל אפליצקיה מסוימת אחת (או כמה) אשר רצה על מערכת הפעלה מותאמת במיוחד לאפליקציה (בד"כ היא בעיקר מופשטת מ features שאין בהם צורך) -  מאפשר לארגונים לא להתעסק יותר מדי בהטמעות מיוחדות לשם הפעלת האפליקציות וכמובן גם מאפשר לספקי האפליקציה להכין את הבסיס הטוב ביותר לאפליקציות שלהן.

קצת סדר בדברים, אותה ההחלטה של Citrix ומיקרוסופט על שימוש בפורמט ה VHD במוצרי הוירטואליצזיה של שתי החברות מתייחסת על פורמט הדיסקים הוירטואליים שנעשים בשימוש במוצרים, ממש כמו VMDK במוצרי VMware ו- VDI ב- Sun. ה OVF מתייחס לפורמט המכונה הוירטואלית כולה, או למעשה להגדרות השונות של המכונה, שדיסקים הוירטואליים הם רק אחד המאפיינים הכלולים בה.
הפורמט החדש מכיל את כל הגדרות החומרה של המכונה הוירטואלית. מעבד, זיכרון, רשת, התקני איחסון וכו'. כל ההגדרות האלה נשמרות בפורמט xml (קטע, ממש כמו במוצרים של Sun) אשר ייקרא על ידי אותם המוצרים אשר ייתמכו ב OVF ולאט לאט כל חברה מתחילה לתמוך בעניין.
לדוגמא Citrix הכריזה לא מזמן על פרוייקט קנשו (Project Kensho) אשר מיועד לנהל את אותן ה Virtual Appliances וכמובן יעבוד עם ה OVF, חלק מהיכולות שלו הן אופציה ל export של המכונות הוירטואליות מ- VMware, XenServer ו- Hyper-V ולעשות import ל XenServer ול- Hyper-V, והוא אפילו הולך להיות חינמי לגמרי.

ואם בתאימויות בין ה Hypervisors השונים עסקינן אז אין כמו לדבר על הניהול של כל הסביבה הוירטואלית, בייחוד כשמדובר על סביבות וירטואליות הטרוגניות, או בעצם סביבות בעלות יותר ממוצר Hypervisor אחד. והרי ברור שזה מה שהולך להיות בסופו של דבר, רוב הארגונים יבחרו לעבוד לפחות עם שני מוצרי וירטואליזציה שונים בסביבה שלהם. ואם ממשיכים בקו הזה - שיהיה צורך לנהל לפחות שני מוצרי וירטואליציה - הארגונים יידרשו מוצרי ניהול התומכים בכל אותן הסביבות - ד"א משהו לא כ"כ נפוץ עד עכשיו, עד כה כל חברה סיפקה מוצר ניהול לאפליקציות שלה וככה כל מנהל רשת ממוצע היה צריך להחזיק עשרות מוצרי ניהול לכל מוצר העובד אצלו בארגון - אז לפחות במוצרי הוירטואליזציה נעשה ניסיון לעשות שינוי, XenCenter של Citrix וגם SCVMM של מיקרוסופט תומכים גם ב Hyper-V גם ב XenServer וגם ב VMware ESX. מה שמעניין בכל הסיפור הזה שדווקא VMware לא מספקת שום מוצר ניהול שתומך במוצרים נוספים פרט ל ESX, לא מפתיע כ"כ, כולנו מכירים את היהירות המסויימת שלהם (מה שמפחיד קצת יותר שהיא נדבקת גם באלה המנסים לקדם אותם) והעמדה הרשמית שלהם היא שבנתיים הם לא רואים את הצורך הזה אצל הלקוחות שלהם. נו באמת, תעשו לי טובה.
אז כל עוד אין מענה לסוגיה מצד VMware הלקוחות שלה (כן, אלה בדיוק שאין להם את הצורך לפי VMware) הולכים לחפש את הפתרונות במקומות אחרים, אם זה SCVMM שנמצא בנתיים בבטא, אם זה XenCenter של Citrix ואם זה חברות קטנות יותר כדוגמת Hyper9 שנכון לעכשיו מספקים מוצר ניהול רק ל ESX אבל כבר עובדים על מוצר שיעבוד עם שלושת הגדולים.