בזמן האחרון שב ועולה נושא ה- Desktop as a Service ללקוחות פרטיים וארגונים. כולם מדברים על כמה שזה טוב ועל זה שממש עוד מעט כולנו נעבוד ממחשב שיוספק לנו מספק זה או אחר.

ישנן אפילו כבר כמה חברות שמציעות לספק את ה- Desktop כשירות מרוחק. ביניהן אפשר למצוא את nivio, nasstar, tuCloud, ITfarm ו- desktone שעד לא מכבר היתה חברת אפליקציה בלבד ונהיתה בצעד לא ממש מפתיע (מאין אם אין אני לא, מי לי) ספק DaaS ממש לא מזמן. חלקן עושות את זה ע”י אספקת Windows 7 מלא למשתמשים שלהן (כלומר, VDI מלא) וחלקן מספקות סביבת עבודה מבוססת TS\XenApp. הדרך פחות משנה לענייננו, מה שחשוב זה שכולן מספקות Desktop מלא.

 

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

אין משפט שמסביר את זה טוב יותר מאשר, “סבבה והכל, אבל…”. או בעצם… סבבה והכל, אבל… למה בכלל אני צריך לקבל את מערכת ההפעלה שלי מהספק? אני בסך הכל רוצה אפליקציות!

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

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

 

אז… סבבה והכל, אבל זה לא ילך. או בעצם, אולי באמת יהיו לכם משתמשים פה ושם כי אי אפשר להתווכח על זה שכל העניין של לקבל את Desktop של Windows 7 לתוך הטאבלט זה מגניב. אבל מעבר למגניב, לא יותר מדי משתמשים באמת יצטרכו את זה. כדי לקרוא מיילים יש לי אפליקציה שנועדה במיוחד עבור זה לטלפון החכם ולטאבלט, אין שום היגיון שאני אכנס ל- Desktop הוירטואלי שלי שיושב לו אי שם אצל הספק וממנו אפתח Outlook, האפליקציה המקומית תעשה את זה לא פחות טוב. לעבוד על אפליקציות web-יות אני יכול גם מהדפדפן המקומי.

 

לפני שלוש שנים כולנו דיברנו על Application Delivery ולא על Desktop Virtualization או Client Virtualization כמו שקוראים לאותו הדבר בדיוק היום. את רוב המשתמשים לא באמת מעניינת מערכת ההפעלה, הם עובדים באפליקציות והן היחידות שמעניינות אותן. אם כבר לספק משהו מרחוק, תספקו אפליקציות, את אותן האפליקציות שלא זמינות בתצורה web-ית, או שמא יש צורך להגן על הנתונים שלהן יותר טוב (במקרה של אפליקציות ארגוניות). לפחות במקרה של משתמשים ביתיים (בארגונים כל הסיפור מסתבך הרבה יותר ושם דווקא יש במקרים מסוימים הגיון מאוד גדול ללכת לכיוון הזה), זה מה שהמשתמשים רוצים, תנו להם את זה.

עבור האפשרות להדליק ולכבות מכונות וירטואליות לפי שעות מסוימות ביום, כברירת מחדל XenDesktop 5 מחלק את השבוע לימי עבודה וסוף שבוע (Weekdays ו- Weekend) וקביעת מספר המכונות שיחכו זמינות למשתמשים בכל שעה מהיום נעשית לפי אותן קבוצות ימים.

זה נראה משהו בסגנון הזה:

 

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

 

כל קבוצת ימים כזאת נקראת Scheme וכדי לראות את ה- Schemes שמוגדרים במערכת מריצים את פקודת ה- PowerShell הבאה: Get-BrokerPowerTimeScheme.

הפלט שלה הוא ימי השבוע שמוגדרים בכל Scheme, שם, UID וה- UID של ה- Desktop Group שמשויך אליו (משתנה DesktopGroupUid). את שם ה- Desktop Group וה- UID של כל אחד מהם אפשר למצוא עם Get-BrokerDesktopGroup.

אי אפשר ליצור Scheme חדש מבלי לשייך אותו ל- Desktop Group כזה או אחר, אז כדי שנוכל ליצור נצטרך למחוק Power Time Scheme. במקרה שלי זה יהיה גם אותו אחד עליו אני אשייך את ה- Scheme החדש.
נגיד ומצאתי שה- UID של ה- Desktop Group שאני רוצה לשנות בו את ה- Power Scheme הוא 4, אז כדי לראות את ה- Schemes המוגדרים לו נריץ
Get-BrokerPowerTimeScheme –DesktopGroupUid 4.

הפלט יהיה:

DaysOfWeek             : Weekdays
DesktopGroupUid       : 4
DisplayName             : Weekdays
Name                        : Gadis_Weekdays
PeakHours                : {False, False, False, False...}
PoolSize                   : {0, 0, 0, 0...}
PoolUsingPercentage : False
Uid                            : 7

DaysOfWeek : Weekend
DesktopGroupUid : 4
DisplayName : Weekend
Name : Gadis_Weekend
PeakHours : {False, False, False, False...}
PoolSize                   : {0, 0, 0, 0...}
PoolUsingPercentage : False
Uid : 8

כאמור, לכל Desktop Group מוגדרים שני Power Schemes, אחד לימי העבודה (Weekdays) ואחד עבור סוף השבוע (Weekend).

נמחק את ה- Power Schemes שמשויך ל- Desktop Group שלי:

Remove-BrokerPowerTimeScheme -Name Gadis_Weekend
Remove-BrokerPowerTimeScheme -Name Gadis_Weekdays

וניצור Power Schemes חדשים לפי ימי העבודה הנכונים לישראל:

New-BrokerPowerTimeScheme -Name IL_Weekdays -DaysOfWeek Sunday,Monday,Tuesday,Wednesday,Thursday -DesktopGroupUid 4

New-BrokerPowerTimeScheme -Name IL_Weekend -DaysOfWeek Friday,Saturday -DesktopGroupUid 4

לאחר מכן, כשנלך ל- Power Management ב- Desktop Group הלרוונטי נוכל לראות את ה- Power Scheme החדשים שיצרנו.

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

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

 

אחת התוספות היותר משמעותיות – פרט לאפשרויות הניהול המשופרות – היא ה- Machine Creation Services, או MCS בקיצור, מערכת ניהול ה- Base Images החדשה שהתווספה ל- Provisioning Services (או ה- PVS בקצרה) המוכר מהגירסאות הקודמות של XenDesktop.

השוני הגדול בין ה- PVS ול- MCS הוא שה- MCS עובד ישירות על מערכת האחסון של סביבת הוירטואליזציה ע”י יצירת מכונות עם דיסקים אשר נוצרו מה- Base Image, כשה- PVS למעשה יוצר הפרדה בין שכבת ניהול ה- Base Images למערכת האחסון של הסביבה. למטיבי לכת, קצת יותר מידע על איך PVS עובד.

 

ה- MCS מצידו נוצר כדי לפשט את נושא ניהול ה- Images בסביבת ה- VDI, כדי לנצל בצורה טובה יותר את סביבת הוירטואליזציה (Hyper-V\XenServer\vSphere) ע”י התממשקות לרובד האחסון שלהן וכל זה תוך כדי שמירה על חלק מהיכולות של ה- PVS. סיבה אחת אחרונה בגללה נוצר ה- MCS היא מענה למערכת ניהול ה- Images של VMware View, הלא היא ה- Linked Clone. מערכת הרבה יותר פשוטה לניהול והקמה – ונניח בצד את ההבדלים הטכנולוגיים – מאשר ה- PVS.

 

מערכת ה- MCS מורכבת למעשה משלושה תת-שירותים:

1. Citrix Machine Creation Service – שירות האמון על יצירת ה- Base Image מתוך מכונה וירטואלית כזאת או אחרת ויציתר המכונות הוירטואליות בסביבת הוירטואליזציה (ה- Hypervisor) מתוך אותו Base Image.

התהליך עובד בצורה הבאה, מכינים מכונה וירטואלית אשר ממנה נרצה להכין Base Image ומכבים את את המכונה. כאשר נרצה ליצור מכונות וירטואליות על סמך אותו VM, ה- MCS ייקח snapshot מה- VM, יעתיק אותו ל- LUN\S עליהם בחרנו ליצור את המכונות ומה- snapshot הזה ייצור VMs עם שני דיסקים בכל אחד. הראשון יהיה דיסק Identity בגודל של 16MB, אשר ישמור את זהות ה- VM (שם המכונה למשל) ודיסק נוסף בשם Diff Disk, שנוצר מ- Thin Provisioning של- Base Image ובו יישמרו כל השינויים מה- Base Image.

2. Citrix AD Identity Service – שירות אשר מנהל את ה- Computer Accounts של המכונות הוירטואליות ב- Active Directory. מכיוון שבסגירת ה- Base Image אנחנו לא סוגרים את המכונה עם sysprep למעשה יש צורך לנהל חשבונות המכונות הוירטואליות שנוצרו מאותו ה- Base Image ב- Active Directory. השירות אחראי על יצירת אותם חשבונות, ניהול הסיסמא של המכונות ומחיקתם במקרה הצורך.

3. Citrix Machine Identity Service – מנהל את הדיסקים של המכונות הוירטואליות. למעשה מה שהוא הוא עושה הוא די פשוט. במכונות אשר הוגדרו שיעבדו בתצורת Pooled VMs, השירות אחראי לאפס את ה- Diff Disk בכל הפעלה מחודשת של המכונה הוירטואלית, כך שמשתמש חדש שיתחבר אליה יקבל סביבה נקיה לחלוטין.
לעומת זאת, במכונות אשר הוגדרו כ- Dedicated VMs, השירות למעשה לא יעשה דבר מכיוון שבמכונות אלה ה- Diff Disk נשמר בין ההפעלות.

 

פרט לשוני בניהול ה- Images ה- MCS שונה מה- PVS מבחינת שיקולי ביצועים על מערכת האחסון.
ב- PVS מכיוון שהדיסק הגיע משרת יעודי ברשת, כל הקריאות מה- Base Image היו מתבצעות באותו השרת (ע”י העלאת ה- Base Image לזיכרון ואספקת הבלוקים הרלוונטיים לתחנות הוירטואליות על הרשת) כך שעל מערכת האחסון (הדיסק אשר חובר ל- VMs) בוצעו בעיקר הכתיבות של כל מה ששונה מה- Base Image. היחס הוא משהו בסביבות ה- 90% כתיבות לעומת רק 10% קריאות.
ב- MCS ה- Base Image וה- Diff Disks נמצאים שניהם על מערכת האחסון, כך שהיא צריכה “לספוג” גם את הכתיבות (ל- Diff Disk) וגם את הקריאות (מה- Base Image). ביחס של סביבות ה- 50/50. בנוסף, הקריאות שאנחנו “מעמיסים” עכשיו על האחסון עולות לנו כמובן ב- IOPS. לפי הנתונים הקיימים כרגע, בעבודה עם MCS אנחנו נצטרך משהו כמו פי 1.5 יותר IOPS לכל מכונה לעומת מה שהינו צריכים עם ה- PVS.

 

לסיכומו של עניין, ה- MCS היא מערכת פשוטה וקלה יחסית לניהול ה- Base Images והדיסקים של המכונות הוירטואליות של המשתמשים, אבל יש לבנות את כל הסביבה (ובייחוד את מערך האחסון) בהתאם כך שיתמוך בצורה הטובה ביותר את התצורה החדשה.