השעה היתה סביבות שתיים עשרה בלילה.
בחוץ ירד גשם קפוא.
צלליתו של רון קופמן צועק בפעם המי יודע כמה על שלמה שרף ריצדה בטלוויזיה.
אני ישבתי מכונס בתוך עצמי ובדקתי מה חדש בפייסבוק.
בין כל התמונות וההגיגים השנונים – ואם נהיה כנים עם עצמו לרגע, בעיקר הפחות שנונים – נפלתי על הפניה לכתבה בעלת הכותרת הבא: "לאלטיריס סיכויים גבוהים להפוך לכלי המרכזי לניהול ותחזוקה של כל מערך המחשוב הארגוני". שיפשתי את העיניים. פתחתי את היומן ווידאתי שהשנה היא אכן 2012 ולא חזרנו במקרה ל- 2004. למרבה ההפתעה, הכל היה נראה סטנדרטי לחלוטין. פתחתי את הלינק כדי לבדוק אולי ההפניה מגיעה לכתבה ישנה שמצאה את עצמה באורך פלא לימינו אנו. אבל גם שם, התאריך הראה על ינואר 2012. מוזר.
התעמקתי עוד יותר והתחלתי לקרוא. המשפט שקידם את פני היה, "ג’ טכנולוגיות (השם המלא שמור במערכת) הציבה לעצמה יעד להפחית את העלות והמורכבות של מערכי המחשוב של לקוחתיה, לשפר את רמת האבטחה וליצור זיקה הדוקה יותר בין יעדי השירות של המחשוב ליעדים העסקיים של החברה", נשמע מעולה לכל הדעות. לאחר מכן, הכותב – אני מניח – שאל את עצמו “מהו הביטוי לגמישות שמציעה סוויטת הפתרונות של אלטיריס?” וענה – "הסוויטה נותנת מענה מושלם לניהול מחזור-החיים של תחנות הקצה בארגון, משלב ההתקנה של מערכות הפעלה, דרך עדכונים שוטפים וביצוע גיבויים, וכלה בניהול מלא של תקלות, שינויים, חוזים ועוד. המנהל רואה תמונה מלאה של כל התוכנות המותקנות במחשבי הקצה בארגון, ובאמצעות המודולים השונים של אלטיריס יכול לבצע עדכוני תוכנה בתפוצה רחבה, מבלי להודיע למשתמשי הקצה ומבלי לעכב את עבודתם".
כן, אני יודע, גם לי היה קשה. ואחרי שכמעט סגרתי את המחשב בעצבים, אמרתי לעצמי אולי בכל זאת הכותב יתאפס על עצמו בהמשך ושווה להשקיע את המאמץ.
אחרי קטע קצר על מודלים ושאר ירקות, הגיעה השאלה הטרנדית כ”כ, “כיצד סוויטת הפתרונות אלטיריס מתיישבת עם מודל מחשוב ענן?”. אופּה, אמרתי לעצמי, אולי ייצא מזה משהו חיובי בכל זאת.
וזאת היתה התשובה, "למשל, מודול ה-Application Virtualization מאפשר גישה של משתמשי הקצה לאפליקציות, ללא התקנת תוכנה על המחשבים עצמם. כך, כל תהליכי ההתקנה והעדכונים הוירטואלים על גבי מחשבי הקצה, נעשים פשוטים ומהירים יותר. מודול זה נותן למנהלים תמונת מצב ושליטה בכל האפליקציות המותקנות בכל אחת מתחנות הקצה, כולל מידע מדוייק לגבי היקף ומועדי השימוש באפליקציה, הגדרת כמות הרישיונות שהארגון צריך עבור כל אפליקציה ועוד. מידע מסוג זה תורם לצמצום ניכר בזמני ההתקנה ובעלויות".
תבינו, אני מאוד אוהב את הפיתרון של Altiris Symantec בתחום ה- Application Virtualization, ובכלל אני מעודד כבר כמה שנים טובות את כל מי שאני רק מכיר, ללכת לכיוון של וירטואליזציה של אפליקציות, ככה שלראות משפט שמדבר על וירטואליזציה של אפליקציות תוך כדי התקנה של אותן האפליקציות הוירטואליות, עושה לי לא נעים בבטן.
אני מאמין שהתפקיד שלנו כיועצים, הוא לקדם את הארגונים איתם אנחנו עובדים קדימה. להשתמש בטכנולוגיות החדשות כדי לאפשר ליחידות ה- IT להיות יעילות יותר, חדשניות יותר ולאפשר למשתמשים שלהן סביבת עבודה טובה יותר. הטמעה של שיטות עבודה וטכנולוגיות ישנות אולי תביא את כולם לעולם הנוח והמוכר כ”כ של התקנה-הפצה-תיקון-הפצה (וחוזר חלילה כל X שנים), אבל בטוח לא תוביל את הארגון קדימה.
נראה לי שהדרך הטובה ביותר להגדיר את ההרגשה שלי לכתבה היא, “הפוך גוטה, הפוך”.
אם כבר מדברים על דברים שיהפכו לכלים מרכזיים - או ה-מרכזיים, אם נלך לפי הכתבה המדוברת – לניהול מערך המחשוב הארגוני, אז תרשו לי להביא כאן את התזה שלי בעניין.
דווקא Desktop Virtualization (על כליה/טכנולוגיה השונות) תהפוך לטכנולוגיה המרכזית בניהול סביבות העבודה הארגוניות. שלא תטעו, אני לא אומר שרוב סביבות העבודה הארגוניות יהיו בתצורת Hosted VM-Based Desktop (או VDI אם תרצו), גם לא שרובן יהיה TS-Based Desktop (מבוססת Terminal Server) וכנראה שגם לא כאלה המבוססות על Client-Side Hypervisor. זה יהיה שילוב. כל ארגון יבחר את הטכנולוגיות המתאימות לצרכים של המשתמשים השונים בו.
לענייננו, הטכנולוגיה הספציפית פחות חשובה, מה שחשוב הרבה יותר היא המהות. והיא זאת שמשותפת לכלל הטכנולוגיות המרכיבות את ה- Desktop Virtualization. בכולן, ניהול סביבת העבודה נעשה באופן מרכזי, פעם אחת לכל תצורה, ללא קשר לחומרת הקצה עליה רצה סביבת העבודה. ולא, לא מפיצים לתחנות השונות ומתפללים שההפצה תצליח לכסות כמה שיותר מהמחשבים ברשת, כמו שמציעים לנו בכתבה המדוברת.
משאירים את המידע (ו/או את כל סביבת העבודה) בתוך הרשת הארגונית ומאפשרים למשתמשים לעבוד עליו מכל מקום שהם בוחרים. במקרים מסוימים (מי אמר
Wanova?!) תצורה מעין זאת, תאפשר ל- IT לספק הרבה יותר חופש למשתמש הקצה ע”י הפרדת סביבת העבודה לשתי תתי סביבות. אחת באחריות וניהול ה- IT, והשניה של כל שינויי המשתמש, באחריות המשתמש. ה- IT ימשיך לנהל את מערכת ההפעלה – עם נספחיה השונים, כגון אנטיוירוס ואפליקציות ארגוניות שונות - על שלל תיקוניה ותחזוקותיה, וזאת מבלי לפגוע בחופש של המשתמש להתקין אפליקציות נוספות, ליצור תכנים – שיעלו ישירות לרשת - ולעבוד ללא תלות בחיבור זמין לארגון.
תרצו או לא, עולם המחשוב הארגוני משתנה לנגד עיננו. ישנה כניסה של התקנים ניידים כאלה ואחרים (טאבלטים, טלפונים חכמים), עובדים הרבה יותר ניידים מבעבר, הרבה יותר עובדים מהבית (והבית שלהם לווא דווקא נמצא באותה המדינה בה נמצאים המשרדים הראשיים של הארגון), לעובדים ישנן דרישות וצרכים שלא היו מוכרים – או אולי מוכרים, אבל זניחים יחסית – לפני כמה שנים.
ניהול סביבות העבודה – אני לא מת על ההגדרה, אבל, מערך המחשוב הארגוני – פשוט לא יכול להיעשות בדרכים הישנות.
תסתכלו על הצרכים האמיתיים של הארגון שלכם היום וישר אחרי זה תעשו את אותו הדבר בחשיבה של 5 שנים קדימה. האם באמת אתם רוצים להיות תלויים בהפצות ובחומרה. האם זה מה שייאפשר לארגון שלכם להיות חדשני יותר, ייעיל יותר וגמיש יותר?
פורסם במקור בבלוג של HP.
בכנס שערכנו בשבוע שעבר, דיברתי קצת על איפה אנחנו עומדים היום בתחום ה- Desktop Virtualization. עברו כבר יותר משלוש שנים מאז שהתחום הזה פרץ מחדש לתודעתנו עם בשורת ה- VDI, מעניין לראות מה השתנה, מה למדנו ואיך כל זה יכול לתרום לנו.
כמה נקודות, המצגת המלאה מצורפת:
1. המוצרים והטכנולוגיות התפתחו לא מעט עם הזמן, הגירסאות הקיימות של שלל המוצרים בתחום – ומספיק רק אם ניקח את XenDesktop ו- XenApp של Citrix או את View של VMware כדוגמא – כולם מספקים יכולות שבכלל לא חשבנו עליהן לפני שלוש שנים.
למעשה, הדוגמא הכי טובה לזה היא העובדה שרוב הפיתוחים וההתקדמות הטכנולוגית הבאה של רוב המוצרים היא בטכנולוגיות משלימות שונות. התמודדות עם צריכת משאבי Storage, מענה לניידות וכו’.
2. ללא צל של ספק, ארגונים מבינים הרבה יותר את הטכנולוגיה. ומה שלפי דעתי הרבה יותר חשוב, הם מבינים איפה, מתי והאם בכלל היא יכולה לעזור להם. רק לפני שנה שמעתי מנמ”ר של ארגון לא קטן עונה ברצינות תהומית לשאלה למה הוא בכלל צריך VDI, ב-“כי לארגון המתחרה יש”. עכשיו, הם מתייחסים ל- Desktop Virtualization ככלי שיכולים להשתמש בו כדי לפתור בעיות מוגדרות למשתמשים מוגדרים.
ופה מגיע החלק הכי יפה, הארגונים התחילו להבין שה- Desktop Virtualization הוא לא רק VDI, וישנן אפשרויות נוספות לאספקת סביבת עבודה מלאה או לא מלאה למשתמשים שלהם בצורה מאובטחת ממקום מרכזי. סביבות מבוססות Terminal Server מצאו את מקומן מחדש לאספקת סביבת עבודה לקבוצות משתמשים מסוימות שלא צריכות שום דבר מעבר לזה. יותר ויותר ארגונים עוברים לאפליקציות וירטואליות. וגם פיתרונות עבור משתמשים ניידים (כדוגמת XenClient בצד אחד או Wanova מהצד השני) נהיים יותר ויותר בשלים.
אחת הדוגמאות היותר מגניבות שניתן לתת כאן היא על בנק בארגנטינה שבוחן להעביר את כל המחשבים המותקנים בכספומטים שלו לתצורת VDI. לאותו בנק ישנם עשרות אלפים של כספומטים שפזורים ברחבי המדינה, ובכל אחד מהם מותקן מחשב עם Windows XP. נושא הטיפול בתקלות והתחזוקה של אותם המחשבים הוא נושא בעייתי (טכנאי צריך להגיע פיזית לכל אחד מאותם עשרות אלפי המחשבים), אבל לא הנושא הבעייתי העיקרי. מסתבר שפרט לנסיונות המוכרים לגניבה של הכסף מהכספומטים, ישנם לא מעט נסיונות לגניבת המחשבים שבהם, עליהם יושבים נתוני כרטיסי האשראי, הקודים, והסכומים שהוצאו מהכספומט. מידע בעל ערך רב לפחות כמו הכסף המזומן ששוכן בתוכו.
יותר מכך, מסתבר שישנן גם נסיונות להתקפות Man in the Middle בתווך שבין הכספומט לבין השרת של הבנק, בנסיון ללכוד את פרטי חשבונות הבנק, כרטיסי האשראי והקודים שלהם.
מעבר לתצורה של אספקת סביבת VDI ל- Zero Client שיותקן בכספומט יחסוך לא מעט כאב ראש לאותו הבנק. שום דבר לא נשמר בצד של ה- Zero Client, ככה שהוא נהיה חסר כל ערך במקרה של גניבתו. אין צורך שטכנאי יגיע לכספומט, מקרה של תקלה, אפשר לשלוח קופסא חדשה עם שירות הבלדרות שמגיע להטעין כסף בכספומט. וגם התקפות של Man in the Middle פחות בעיותיות מכיוון שכל מה שעובר בתווך שבין הכספומט לבין השרת זה הפרוטוקול המוצפן של סביבת ה- VDI.
3. בהמשך ישיר לסעיף הקודם, ישנם הטמעות לא מעטות של אלפים ועשרות אלפים של משתמשים שעברו לעבוד בתצורה מלאה של Desktop Vitrualization. וגם כאן, הדוגמא היפה ביותר היא על פרוייקט עבור יותר מ- 30,000 משתמשים עבור חברה בהודו (באופן לא מפתיע בעליל) שעושה בימים אלו את צעדיו הראשונים.
אחרי שעברנו הטמעות של 12,000 סביבות באיטליה, 15,000 בגרמניה ויותר מעשרים אלף בארה”ב - וזה רק על קצה קצהו של המזלג – נראה שכולם סופסוף השתכנעו שהשד הוא לא נורא כל כך.
4. אחד הדברים שפחות רואים כרגע, אבל אני בטוח שעם הזמן נראה יותר ויותר, הוא מימוש של Charge Back פנימי של הארגון עבור שימוש בסביבות עבודה והאפליקציות. ה- IT יהפוך למאין נותן שירות ויספק שירותים אותם המחלקות יוכלו “לקנות” לפי רמות שירות שונות שיוגדרו מראש. כך למשל סביבת VDI של Windows 7 תתומכר ב- 100 שקל למשתמש לחודש וסביבה של Terminal Server תתומכר ב- 50 שקל לחודש. ההתחשבנות תיהיה פנימית בין המחלקות השונות של הארגון לבין ה- IT. כניסה של מודל כזה תאפשר ל- IT להיות מקצועי, חדשני ומודע הרבה יותר לצרכים של הלקוחות שלו. ויכניס את תחום ה- Consumerization of IT (ארחיב עליו בפוסטים הבאים) לארגון.
בהמשך לשאלה שנשאלתי אודות ההבדל בין ה- compressions השונים שאפשר לעשות לתמונות ואשר ניתנים להגדרה בפרוקוטול ה- HDX\ICA, החלטתי לבדוק את העניין לעומק.
ערכתי בסך הכל 12 בדיקות, כשכל אחת עם הגדרה מעט שונה. כל הבדיקות נערכו על תמונות דוממות מהאתר
הזה. ביטלתי את אפשרות ה- Off Screen Surface כדי שה- agent המקומי שלי לא יקח את התמונות מה- Cache, אלה יביא אותם כל פעם מהסביבה המרוחקת.
הבדיקה כללה פתיחה של IE על אתר הדגימה (כל האתר נטען מבעוד מועד בכל אחת מהבדיקות) וגלילה – עם page down בקצב איטי יחסית – עד סוף הדף.
ועוד דבר קטן, כל הבדיקות בוצעו ע”י התחברות לסביבה עם Latecny גבוה יחסית של 200ms וקו של 1.5M.
מי שמעוניין להגיע ישר לסיכום התוצאות, מוזמן לגלול לסוף הדף.
בדיקה 1: Still Images Lossy Compression - High
התמונות עלו בצורה מהירה, ראו ירידה מסוימת באיכות התמונות.
תקשורת – ממוצע של 109Kbits/sec של תקשורת יוצאת מהסביבה הוירטואלית לעמדה הפיזית, עם פיק של 201Kbits/sec.
עבודה מול הדיסק – ממוצע של 1.3IOPS (כולם כתיבה)
השפעה על מעבד ו- RAM – ממוצע של 40% שימוש במעבד ו- 1.2GB של RAM פנוי (מתוך 2GB).
בדיקה 2: Still Images Lossy Compression – Medium
התמונות עלו בצורה מהירה, באיכות יותר טובה יחסית ל- High Compression, אבל עדיין, באיכות פחות טובה מהמקור.
תקשורת – ממוצע של 217Kbits/sec של תקשורת יוצאת מהסביבה הוירטואלית לעמדה הפיזית ו- 4Kbits/sec של תקשורת נכנסת. פיק של 414Kbits/sec של תקשורת יוצאת ו- 5Kbits/sec של נכנסת.
עבודה מול הדיסק – ממוצע של 5IOPS (כ- 4 כתיבה וכ- 1 קריאה) במשך הבדיקה.
השפעה על מעבד ו- RAM – ממוצע של 36% שימוש במעבד ו- 1.2GB של RAM פנוי.
בדיקה 3: Still Images Lossy Compression – Low
התמונות עלו בצורה איטית יותר מאשר בשתי הבדיקות הקודמות, אך איכותן היתה טובה מאוד ועדיפה מאשר בבדיקות הקודמות.
תקשורת – ממוצע של 307Kbits/sec של תקשורת יוצאת מהסביבה הוירטואלית לעמדה הפיזית ו- 3Kbits/sec של תקשורת נכנסת. פיק של 530Kbits/sec של תקשורת יוצאת ו- 4Kbits/sec של נכנסת.
עבודה מול הדיסק – ממוצע של 2IOPS (כולם כתיבה) במשך הבדיקה. העליה בסוף, היא בגלל סגירת חלון הדפדפן.
השפעה על מעבד ו- RAM – ממוצע של 34% שימוש במעבד ו- 1.2GB של RAM פנוי. העליה בסוף, היא בגלל סגירת חלון הדפדפן.
בדיקה 4: Still Images Lossy Compression – None
התמונות עלו בצורה איטית ומייגעת מאוד, מה שכן, האיכות שלהן – אחרי שהן כבר הופיעו – היתה מצוינת.
תקשורת – ממוצע של 500Kbits\sec של תקשורת יוצאת מהסביבה הוירטואלית לעמדה הפיזית ו- 3Kbits\sec של תקשורת נכנסת. פיק של 863Kbits\sec של תקשורת יוצאת – 4Kbits\sec של תקשורת נכנסת.
עבודה מול הדיסק – ממוצע של 1.5IOPS (כולם כתיבה) במשך הבדיקה.
השפעה על מעבד ו- RAM – ממוצע של 33% שימוש ובמעבד ו- 1.2GB של RAM פנוי.
בדיקה 5: Still Images Lossy Compression – High; Heavyweight Compression – Enabled
התמונות עלו בצורה מהירה, ראו ירידה מסוימת באיכות התמונות.
תקשורת – ממוצע של 160Kbits\sec של תקשורת יוצאת מהסביבה הוירטואלית לעמדה הפיזית וממוצע של 2.5Kbits\sec של תעבורה נכנסת. פיקים של 280Kbits\sec ו- 3.9Kbits\sec של תעבורה יוצאת ונכנסת.
עבודה מול הדיסק – ממוצע של 3IOPS (כולם כתיבה) לאורך הבדיקה.
שימוש במעבד ו- RAM – ממוצע של 35% שימוש במעבד, כמעט ללא השפעה על ה- RAM.
בדיקה 6: Still Images Lossy Compression – Medium; Heavyweight Compression – Enabled
תקשורת – ממוצע של 208Kbits\sec של תקשורת יוצאת ו- 3Kbits\sec של נכנסת. פיקים של 286Kbits\sec ו- 3Kbits\sec של יוצאת ונכנסת.
עבודה מול הדיסק – ממוצע של 2IOPS (כמעט כולן כתיבה).
שימוש במעבד ו- RAM – ממוצע של 37% שימוש במעבד, השפעה מועטה על ה- RAM.
בדיקה 7: Still Images Lossy Compression – Low; Heavyweight Compression – Enabled
תקשורת – ממוצע של 328Kbits\sec תעבורה יוצאת ו- 3Kbits\sec של נכנסת. פיק של 502Kbits\sec ו- 4Kbits\sec של תעבורה יוצאת ונכנסת.
עבודה מול הדיסק – ממוצע של 1.7IOPS (כולם כתיבה).
השפעה על מעבד ו- RAM – ממוצע של 33% שימוש במעבד.
בדיקה 8: Still Images Lossy Compression – None; Heavyweight Compression – Enabled
קצב העברת התמונות היה איטי להחריד…
תקשורת – ממוצע של 577Kbits\sec תעבורה יוצאת ו- 3Kbits\sec נכנסת. פיק של 932Kbits\sec ו- 4.4Kbits\sec של יוצאת ונכנסת בהתאמה.
עבודה מול הדיסק – ממוצע של 1.5IOPS (כולם כתיבה).
השפעה על המעבד ו- RAM – ממוצע של 34% שימוש במעבד.
בדיקה 9: Still Images Lossy Compression – High; Heavyweight Compression - Enabled; Extra Color Compression – Enbaled
תקשורת – ממוצע של 188Kbits\sec יוצאת ו- 3Kbits\sec נכנסת. פיק של 310Kbits\sec ו- 4Kbits\sec תעבור יוצאת ונכנסת בהתאמה.
עבודה מול הדיסק – 3.6IOPS בממוצע (כולם כתיבה).
השפעה על מעבד ו- RAM -
בדיקה 10: Still Images Lossy Compression – Medium; Heavyweight Compression - Enabled; Extra Color Compression – Enbaled
מהירות העברת התמונות היתה מעט איטית.
תקשורת – ממוצע של 177Kbits\sec של תקשורת יוצאת ו- 2.5 נכנסת. פיק של 305Kbits\sec של תעבורה יוצאת.
עבודה מול הדיסק -
השפעה על המעבד וה- RAM -
בדיקה 11: Still Images Lossy Compression – Low; Heavyweight Compression - Enabled; Extra Color Compression – Enbaled
מהירות העברת התמונות היתה איטית.
תקשורת – ממוצע של 336Kbits\sec תעבורה יוצאת עם פיק של 532Kbits\sec.
עבודה מול הדיסק -
השפעה על המעבד ו- RAM -
בדיקה 12: Still Images Lossy Compression – None; Heavyweight Compression - Enabled; Extra Color Compression – Enbaled
מהירות העברת התמונות איטית מאוד.
תקשורת – ממוצע של 608Kbits\sec תעבורה יוצאת עם פיק 979Kbits\sec.
עבודה מול הדיסק -
השפעה על המעבד ו- RAM -
לסיכומו של עניין, טבלה קצרה שמרכזת את נתוני התקשורת היוצאת הממוצעת (כפי שאפשר לראות בתוצאות, זה הנתון שהכי הושפע מהשינויים בהגדרת ה- compression) בכל אחת מהבדיקות.
| None | Low | Medium | High | |
| 500 | 307 | 217 | 109 | |
| 577 | 328 | 208 | 160 | Heavyweight Compression |
| 608 | 336 | 177 | 188 | Extra Color Compression |
מסקנות. באופן מעט מפתיע, Heavyweight Compression למרות שהיה אמור לצרוך פחות רוחב פס, דווקא צרך יותר (פרט לכאשר ה- Lossy Compression היה מוגדר ל- Medium). כנ”ל גם בקשר ל- Extra Color Compression, גם כאן בכל הבדיקות פרט לכאשר ה- Lossy Compression הוגדר ל- Medium, צריכת רוחב הפס דווקא גדלה.
עוד נתון שלא ממש הפתיע אותי, אלה רק הראה את זה בצורה מאוד ברורה, הוא נתון העבודה מול הדיסק.
כמעט בכל אחת מהבדיקות, לא היתה שום קריאה מהדיסק בזמן השהייה בדף האינטרנט, גם הכתיבות אליו היו מועטות (ולא הושפע כלל מהגדרות ה- compression). אם מקשרים את הנתונים האלה לנתוני העבודה מול הדיסק שפירסמתי בבדיקות הקודמות, אפשר לראות באופן מאוד ברור כי רוב העבודה של תחנת ה- VDI מול האחסון (אחרי שהיא עלתה והמשתמש נכנס כבר לסביבה, שם הנתונים פחות או יותר הפוכים) היא דווקא בכתיבה.
בהמשך לפגישה מעניינת שהיתה לי היום עם ארגון מאוד מבוזר (סביבות ה- 200 סניפים ברחבי העולם) שחושב על אספקת סביבת עבודה וירטואלית מבוססת Windows 7 בתצורת VDI, חשבתי לבדוק כמה רוחב פס נדרש עבור סריקה של מסמך מתחנת VDI. כלומר, הסורק מחובר ב- USB לתחנה הפיזית ממנה מבוצע החיבור לסביבה הוירטואלית וממופה לסביבה הוירטואלית.
כמו שכבר
התלוננתי, ה- Latency שלי לסביבה הוירטואלית הוא בסביבות ה- 200ms, בדומה ל- Latency בין ישראל לחוף המזרחי של ארה”ב, ככה שהבדקתי דימתה – פחות או יותר – חיבור של משתמש בחוף המזרחי של ארה”ב לסביבה וירטואלית אשר רצה בישראל. לפחות משהו טוב יצא מכל העניין הזה.
סרקתי ארבעה מסמכים, כולם כתובים בשחור לבן, בגודל דף של A4 (אף אחד מהם לא היה מלא לחלוטין).
שני המסמכים הראשונים נסרקו עם ההגדרות: JPEG, 200 DPI, color.
הסריקה ראשונה התחילה ב- 17:42 והסתיימה ב- 17:44.
הסריקה השניה התחילה ב- 17:45 והסתיימה ב- 17:48.
שני המסמכים האחרונים נסרקו עם ההגדרות: JPEG, 200 DPI, black & white.
הסריקה השלישית התחילה ב- 17:50 והסתיימה ב- 17:52.
הסריקה הרביעית התחילה ב- 17:54 והסתיימה ב- 17:55.
כמו שאפשר לראות, הסריקות לקחו יחסית יותר זמן מאשר במחשב מקומי, אבל אני תולה את האשם ב- Latency “המכובד”, בעיקר בגלל שבפעם האחרונה שסרקתי באותה הצורה (בימים בהם ההתחברות לסביבה המרוחקת עבדה הרבה יותר טוב), סריקת מסמכים זהים יחסית לקחו פחות זמן מעכשיו.
בכל אופן, איכות הסריקה לא נפגעה.
תעבורה נכנסת (Input Kbits, מהתחנה הפיזית לסביבה הוירטואלית) ותעבורה יוצאת (Output Kbits, מהסביבה הוירטואלית לתחנה הפיזית). ממוצע (של 18 הדקות בהן ביצעתי סריקות) תעבורה נכנסת 30Kbits/sec, ממוצע תעבורה יוצאת 36Kbits/sec.
עבודה מול הדיסק, ממוצע של 0.5 קריאות לשניה וממוצע של 3.2 כתיבות לשניה. ממוצע סה”כ IOPS של 3.7 כתיבות וקריאות.
שימוש במעבד (ציר שמאל) וזיכרון RAM פנוי (ציר ימין)
אפשר לראות כי מה שהכי הושפע מהסריקה זאת תעבורת הרשת בין התחנה הפיזית לסביבה הוירטואלית, עם עליה לפיקים של סביבת ה- 140Kbit\sec של תעבורה נכנסת, גבוה יחסית למספרים שרואים ללא סריקה. קיימת גם השפעה קטנה יחסית על ה- IOPS (הגיוני מאוד, כי הסריקה נכתבת לדיסק) ועל המעבד והזיכרון שלוקחים חלק במאמץ.
כמעט חודש שלא עדכנתי על ההתפחויות בניסוי, ושלל סיבות יש לעניין. האחת הוסיפה עוד נדבך קטן ומעניין לניסוי והשניה הולכת לשנות – לפחות לעכשיו – את התצורה עליה אני עובד.
אז כאמור, הסיבה הראשונה היתה נסיעה ארוכה לחוף המזרחי של ארה”ב, מה שעזר לי לבדוק את ההתחברות לסביבה שלי גם מיבשת אחרת עם latency של סביבות ה- 200ms. עבד טוב בצורה מפתיעה וזה עוד לפני שעשיתי איזשהי אופטימיזציה בצד ה- XenDesktop. אחת הבדיקות היתה שיחת אודיו עם Lync (קליינט על תחנת ה- VDI ושיחה לטלפון קווי בישראל) שעברה בצורה מפתיעה לטובה. למרות ה- Latency הגבוה יחסית, ה- HDX ידע להשתמש בדרייבר האודיו והמיקרופון המקומי של המחשב, והשיחה נשמעה (בשני הצדדים) בצורה טובה מאוד.
הסיבה השניה היא בעיית Latency חמורה בהתחברות לסביבה שלי ב- HP שהתחילה לקרות, כך נראה לפחות, לפני כשבועיים. בהתחברות מהבית – או כל wifi אחר – אני מגיע לסביבות 180ms, בהתחברות דרך המודם הסלולרי המספרים מטפסים לכיוון ה- 300ms. הסביבה שלי נמצאת גם היא בישראל, ככה שהמספרים האלה מטורפים ולא הגיוניים בעליל. ד”א, לפני זה, ה- Latency עמד על 40ms מהבית מ- 100ms מהמודם הסלולרי.
כל עוד טובי המוחות בהודו - או בסרי לנקה, או בעצם בכל מקום אקזוטי אחר אליו עשו outsourcing - עובדים על העניין, החלטתי לעשות שינוי בסביבה עליה אני אעבוד וממנה יילקחו הנתונים.
הסביבה החדשה היא XenDesktop 5 FP1 (כמו הקודמת), וגם היא עובדת בתצורת MCS. השוני המרכזי שלה הוא בזה שבצד ה- hypervisor נמצא VMware vSphere 4.1 והסטורג’ כבר לא מקומי, אלה הוא דווקא vmax מרכזי. עוד שינוי חשוב הוא שההתחברות לסביבה היא על גבי LAN.
כל השאר זהה לתצורה הקודמת, התחנה הוירטואלית היא Windows 7 SP1, עם vCPU אחד ו- 2GB של RAM. היא עובדת בתצורת Dedicated (לא נמחקת בכל אתחול) והקליינט בתחנה ממנה מבוצע החיבור הוא Citrix Receiver 3.
רק כמה מילים לפני המספרים עצמם. הסביבה עליה אני עובד מאוד עמוסה (בגללי) עם שלל אפליקציות פתוחות ומספר טאבים פתוחים של IE (בד”כ סביבות 8), אפשר לראות את זה טוב בכמות ה- RAM הפנוי שנשאר לי. (ככה נראה ה- taskbar שלי במהלך רוב היום)
נתוני הרשת חסרים – למרות שבגלל שמדובר בסביבת LAN הם לא ממש רלוונטיים, אבל עדיין… – כי לקחתי בטעות counter לא נכון. העניין סודר, ככה שפוסטים הבאים יכילו גם נתוני תקשורת.
אחרי כל ההקדמה הארוכה הזאת, הנה נתוני צריכת המשאבים שלי.
אחסון:
קריאה, Read IOPS עם ממוצע של 3.54 קריאות לשניה.
כתיבה, Write IOPS עם ממוצע של 4.34 כתיבות לשניה.
סה"כ IOPS (ממוצע של 7.88 קריאות וכתיבות לשניה).![clip_image002[7]](http://blogs.microsoft.co.il/blogs/gadifeldman/clip_image0027_thumb_15369888.png "clip_image002[7]")
התפלגות צריכת Read IOPS ו- Write IOPS באחוזים (בממוצע 17.7% עבור Read IOPS ו- 82.3% עבור Write IOPS).![clip_image002[9]](http://blogs.microsoft.co.il/blogs/gadifeldman/clip_image0029_thumb_689D42D4.png "clip_image002[9]")
שימוש במעבד, vCPU אחד, ממוצע של 8.76%.![clip_image002[11]](http://blogs.microsoft.co.il/blogs/gadifeldman/clip_image00211_thumb_68C9A03C.png "clip_image002[11]")
זיכרון RAM פנוי מ- 2GB שמוקצים למכונה הוירטואלית.![clip_image002[15]](http://blogs.microsoft.co.il/blogs/gadifeldman/clip_image00215_thumb_2ECA3783.png "clip_image002[15]")
ביום הזה, העבודה שלי התאפיינה בעיקר במיילים, אינטרנט (רק Firefox), עבודה אינטנסיבית באקסל (גרפים וכו’) ועריכה מנימלית של תמונות (הזזה, שינוי גדלים וכו’).
תעבורה יוצאת מהסביבה הוירטואלית לתחנה (ממוצע של 34Kbits/sec)
תעבורה נכנסת מהתחנה לסביבה הוירטואלית (ממוצע של 0.3Kbits/sec)
קריאה, Read IOPS (ממוצע של 1.26 קריאות לשניה)
כתיבה, Write IOPS (ממוצע של 3.2 כתיבות לשניה)
סה”כ IOPS (ממוצע של 4.46 לשניה)
שימוש במעבד, vCPU אחד (5.86% בממוצע)
זיכרון RAM פנוי מ- 2GB שהוקצו למכונה הוירטואלית
בהמשך ל
זה ול
זה, סיכום צריכת משאבים ליום 10/7/2011.
העבודה שלי התאפיינה בעיקר במיילים, וורד, ואינטרנט. רוב הזמן היו פתוחות כ- 4 אפליקציות במקביל.
תקשורת, בין הלפטופ שלי לסביבה הוירטואלית:
עד 16:15 היתי מחובר מהמודם הסלולרי. מ- 21:30 ואילך היתי מחובר מהאינטרנט בבית.
כמו שאפשר לראות, לא עבדתי באופן רציף על התחנה הוירטואלית במשך היום.
הערה קטנה, העליה בצריכת הרשת בסביבות 23:45 (הגיעה בפיק עד לסביבות 3,000Kb) נבעה כנראה עקב הניסיון לראות סרטון פלאש באיכות HD (איכות 1080p) מ- youtube ללא flash redirection. למעשה הפעלתי את הסרטון מ- Firefox.
תעבורה יוצאת מהסביבה הוירטואלית לתחנה (ממוצע של 41Kbits/sec)
תעבורה נכנסת מהתחנה לסביבה הוירטואלית (ממוצע של 0.33Kbits/sec)
גישה לאחסון (דיסקים מקומיים של שרת ה- Hyper-V):
קריאה, Read IOPS (ממוצע של 0.39 קריאות לשניה)
כתיבה, Write IOPS (ממוצע של 2.4 קריאות לשניה)
סה”כ IOPS (ממוצע של 2.77 קריאות וכתיבות לשניה)
התפלגות צריכת Read IOPS ו- Write IOPS באחוזים (בממוצע רק 2.7% עבור Write IOPS לעומת 97.3% עבור Read IOPS). תזכורת, אני עובד בתצורת MCS.
שימוש במעבד, vCPU אחד. ממוצע של 6.2%:
זיכרון RAM פנוי מ- 2GB שמוקצים למכונה הוירטואלית, Dynamic Memory לא מופעל
מה הספקתי לעשות בזמן הזה:
בשבוע האחרון היתי בתקופת מבחנים, ככה שלא היתי מחובר לסביבה הוירטואלית שלי באופן רציף. עשיתי הפסקות מדי פעם עבור גיחות ללימודים. אבל עדיין, יצא לי לנסות כמה דברים:
-
הדפסות מהסביבה המרוחקת – הגדרתי שכל המדפסות שמוגדרות על הלפטופ שלי יעברו לסביבה הוירטואלית ויעשו שימוש ב- Citrix Universal Driver.
המדפסת הביתית שלי היא HP DeskJet F4500 והיא מחוברת עם כתובת IP לנייד. הדפסתי הדפסות בצבע ובשחור לבן, כולן הדפיסו ללא בעיות.
הדפסתי גם למדפסת וירטואלית מקומית (בנייד) של Bullzip PDF - יצירת קבצי PDF – וגם כאן, נוצר קובץ PDF תקין על הלפטופ שלי.
-
סריקות – כדי שאני אוכל לסרוק, אני צריך לחבר קודם לכן את המדפסת/סורק שלי ב- USB למחשב. חיברתי, הסביבה הוירטואלית זיהתה התקן חדש. היתי צריך להוריד ולהתקין את הדרייבר של הסורק. אחרי זה, הסריקה התבצעה ללא כל בעיות מיוחדות.
-
עבודה באופיס, מיילים, PDFs וכו’ – לא נתקלתי בשום דבר מיוחד. וכן, הרצתי גם כמה מצגות.
הדבר היחידי שמעט מציק לי זה שכל קבצי ה- PST שלי נמצאים על הלפטופ, ככה שמתוך הסביבה הוירטואלית אין לי את היכולת לארכב מיילים ישנים לתוך אותם ה- PSTs.
-
גלישה באינטרנט ופלאש – בנוסף ל- IE, התקנתי בסביבת העבודה שלי גם Firefox. בגלישה ב- Firefox הכל עובד ממש מעולה. חוץ מזה שהוא לא עושה Redirection לפלאש.
כשאני מחובר מהבית, בסרטוני youtube באיכות 360p, כמעט – אם בכלל – לא רואים שום הבדל. איכות האודיו אבל קצת יותר ירודה לעומת המקור. לעומת זאת, בניגון סרטוני פלאש באיכות HD, נגיד 1080p ו- 720p, האיכות בפיירפוקס היא לא מין המשובחות.
בפתיחה של אותם הסרטונים ב- IE, ה- Flash Redirection נכנס לתמונה ומציג את כל הסרטונים באיכות מעולה, גם איכויות HD של 1080p ומטה (מסך מלא או לא). גם איכות האודיו חוזרת למצבה המקורי כמו שרגילים ממחשב פיזי.
-
שמיעת מוזיקה מאתרי סטרימינג – כבר לפני כמה שנים עברתי לצרוך את המוזיקה שלי מאתרי סטרימינג כאלה ואחרים. כשנכון לעכשיו,
grooveshark.com הוא המועדף עלי.
למרות שהיתי בטוח כל הזמן שהאתרים האלה משדרים את המוזיקה דרך פלאש, נראה שלא כך הדבר, ובשני הדפדפנים ישנה ירידה די ניכרת באיכות האודיו.
-
שמיעת גלגצ מהאינטרנט – אולי בגלל האיכות הירודה מלכתחילה של הרדיו, השידור נשמע לא כ”כ שונה לעומת מה ששמעתי כשהפעלתי את אותו הדבר מקומית מהלפטופ.
-
ניגון קבצי MP3 – אחרי שהתייאשתי מעט מזה שהשירים מ- grooveshark לא נשמעים משהו, שמתי את ידי על כמה קבצי mp3 (שנשמרו על אחד השרתים ברשת המעבדה). האיכות שלהם בנגינה היתה בדיוק כמו ניגון מהמחשב מקומית. באופן מאוד לא מפתיע, וזאת בגלל ה- Audio Redirection שעבד ברקע.
-
ניגון קבצי Video – בדיוק כמו בסעיף הקודם. ה- Media Redirection נכנס לתמונה וכך ראיתי את הסרט באיכות מצויינת.
כמה קטנות לסיום:
כמו שכבר ציינתי בפוסט הפותח את הפרוייקט, החיבור שלי לסביבה הוא מעט בעייתי. חיבור ה- VPN שלי ל- HP מעביר את ה- connection באופן מאוד “יעיל” דרך גרמניה ורק אז לשרת אשר נמצא בישראל. ככה שה- Latency שלי לסביבה בהתחברות מהבית נע בסביבות ה- 50-60ms. כשאני מתחבר דרך המודם הסלולרי, כל העניין נהיה גרוע הרבה יותר, וה- Latency מגיע לסביבות ה- 100-150ms.
למרות כל זה, החיבור לסביבה המרוחקת עובד טוב מאוד בשני המקרים. ובאופן מפתיע – או שלא, בזכות העידכון לטכנולוגיית ה- Flash Redirection של XenDesktop 5 FP1 – הפלאש, כאמור, כל עוד מנגנים אותו מה- IE, עובד מעולה.
בפוסטים הבאים אני אתמקד יותר ברוחב הפס ומשאבי השרת וה- storage שכל התענוג הזה צורך.
Stay Tuned.
אחרי שסידרתי – סופסוף - חיבור ראוי מהאינטרנט לסביבת המעבדה שלי, החלטתי שזה הרגע. הרגע שגם אני אעבוד, ולא רק אדבר על זה כל הזמן, בסביבת VDI.
כלומר, בזמן הקרוב אני אעשה את כל עבודתי על גבי סביבת ה- VDI שרצה אצלי במעבדה. במקום לפתוח Outlook מקומי, הוא יפתח על סביבת ה- VDI. במקום Word מקומי אני אכתוב את העניינים שלי בסביבת ה- VDI. וכך הלאה, נראה לי שהבנתם את הרעיון. למעשה את הפוסט הזה נכתב כבר מהסביבה הוירטואלית.
הלפטופ שלי יהפוך בזה הרגע ל- Device טיפש שכל יעודו הוא לספק לי תשתית להתחברות לסביבת העבודה הוירטואלית שלי וכמובן שימוש במשאבים המקומיים שלו (Codecs, Flash וכו’) במקרה הצורך. כמובן, שאחזור לעדכן כאן בחוויות בהתפתחויות.
בצר לי – או שלא, תלוי את מי שואלים – ההתחברות לסביבת העבודה שלי לא כ”כ פשוטה כמו שהיתי רוצה. רשת המעבדה היא רשת וירטואלית אשר רצה על שרת Hyper-V שנמצא אצלי במעבדה. השרת מחובר לאחד הסגמנטים של HP.
Citrix Secure Gateway (לצערי Access Gateway VPX עדיין לא זמין ל- Hyper-V) אחראי על התיווך בין שתי הרשתות. מהבית (או מכל מקום אחר פרט למשרד) העניין קצת מסתבך. כאמור, אני לא יכול להגיע לסביבה כל עוד אני לא נמצא ברשת של HP. וכדי להתחבר אליה מחוץ למשרד אני צריך להתחבר עם VPN. הזדהות עם Token. כלומר, אני יכול לגשת רק מעמדה בה מותקן הקורא הרלוונטי. ככה שאני די נעול על עבודה מהלפטופ שלי בלבד.
כדי להיות מסוגל להתחבר לסביבת העבודה ולעבוד גם ממקומות בהם אין WiFi זמין, הצטיידתי במעוד מועד במודם סלולרי. ככה שבעיקרון אני אמור להיות מסוגל להתחבר מכל מקום שרק אחפוץ.
קצת על הסביבה שלי. Citrix XenDesktop 5 FP1 (ניהול Images בתצורת MCS על הסטורג’ המקומי של ה- Hypervisor), תחנת Windows 7 SP1 עם vCPU אחד ו- 2GB של זיכרון. אני עובד על תחנה בתצורת Dedicated, כלומר, השינויים (התקנות וכאלה) לא נמחקים אחרי Restart. הפרופיל מנוהל ע”י Citrix User Profile Management 4. הכל רץ שרת Hyper-V R2 SP1 אחד.
הלפטופ שלי הוא Windows 7 SP1 עם Citrix Reciever 3 וכמובן כל הקודקים הרלוונטיים ו- Flash Player עדכני.
שיהיה לי בהצלחה.
-------------------------------------------------------------------------------------------------------------------------------------
לפי סקר שנערך השנה ע”י
גרטנר ו-
FEI בקרב 344 מנהלי כספים (CFO) של חברות אמריקאיות וקנדיות ממגוון תחומים, נמצא כי רק
רבע מאותם מנהלי כספים אכן מאמינים שארגון ה-IT של החברה שלהם הוא בעל יכולות ארגוניות וטכנולוגיות גמישות מספיק כדי להגיב לעדיפויות העיסקיות המשתנות של הארגון. רק כרבע אכן מביעים את ביטחונם המלא ב- IT של הארגון שלהם. וזה רע. רע מאוד.
ורק כדי להוסיף עוד שמן למדורה, פחות מרבע מאותם CFOs חושבים שגוף ה- IT מספק את החדשנות הטכנולוגית אשר נדרשת לארגון או שיש לו את האנשים המתאימים כדי לעמוד בדרישות העסקיות של הארגון. ואם חשבתם שזה הכל, אז חכו, רק כ- 18% מה- CFOs חושבים שרמת השירות שגוף ה- IT שלהם מספק עומדת בציפיות הארגון, או עוברת אותם.
תשימו את עצמכם לרגע בנעליים של אותם מנהלי כספים. אתם אחראים על ההכנסות וההוצאות של הארגון שלכם, הוא יכול להיות קטן, בינוני או גדול. גוף ה- IT שלו יכול להיות צוות קטן או חטיבה גדולה עם מאות עובדים. זה פחות רוולנטי לענייננו. אם נלך לפי התוצאות של הסקר, שלושת רבעים מכם יסתובבו בהרגשה שלמרות שאתם נותנים תקציבים גדולים מאוד לאותו הגוף שאחראי על כל נושא המחשוב של הארגון -שבלעדיו כמו שהשכלתם ללמוד, קשה עד בלתי אפשרי לארגון להתקיים - משהו מתנהל לא נכון. לא עוזר לארגון לעמוד ביעדיו ולעתים אף מקשה על ביצוע המשימות השונות.
אם נדמה את גוף ה- IT לאחד העובדים שלכם, אז לפי אותם מנהלי כספים, יש לנו עובד לא יעיל שרק מבקש כל הזמן עוד ועוד משאבים, ולמרות שאתם נותנים לו אותם, שום דבר לא משתנה באמת. מה היתם עושים במקרה כזה? אני די בטוח שאחרי תקופה מסוימת היה לכם נמאס והיתם מפטרים אותו.
אולי בגלל זה יותר ויותר גופי IT (לפחות הקטנים והבינוניים שביניהם) עוברים להיות כפופים לאותם CFOs. בסקר נמצא כי כ- 42% מגופי ה- IT שנשאלו בסקר מדווחים ישירות ל- CFO. ולפי הערכת גרטנר, המספר הזה הולך לעלות עוד יותר בעתיד.
גם באישור ההשקעות שמבצעים גופי ה- IT, ה- CIO מקבל חופש פעולה רק ב- 11% מהארגונים שנשאלו. בכל שאר המקרים, החלטת ההשקעה נעשית ע”י ה- CFO וה- CIO ביחד או ע”י ה- CFO בלבד.
כל זה מתקשר לנתון שהוא אולי אחד הבעייתים ביותר, לפחות עבורי, בכל הסקר הזה. רק כ- 35% מה- CFOs רואים את ה- IT כגוף אסטרטגי אשר יכול להשפיע על ביצועי הארגון בזירה העסקית שלו.
ה- CFOs פשוט איבדו – או מאבדים עם הזמן – את אמונם בגוף ה- IT של הארגון שלהם. ורוצים להיות עם היד על הדופק כשמדובר בהוצאות – כמובן שאנחנו אוהבים לקרוא לזה השקעות, אבל מסתבר שה- CFOs לא רואים איתנו באותה העין – גדולות יחסית על כל מיני פרוייקטים כאלה ואחרים. הם אולי מכניסים לארגון טכנולוגיה חדשה ומגניבה, אבל לפחות בעיניהם של ה- CFOs, הם לא תמיד מביאים איתם איזשהי חדשנות ו/או התייעלות אשר יכולה לעזור לארגון ברמה העסקית. ובל נשכח זאת, הרמה החשובה ביותר לכל ארגון.
אני לא הולך להגיד לכם שמהלך או פרוייקט כזה או אחר יעשה את הקסם שלו ויחזיר את האמון של ה- CFO, ואני מאמין שהוא משקף את הרגשת הארגון כולו, בגוף ה- IT הפנימי שלו. אבל נראה שהמצב כמו שהוא מצטייר מהסקר, לא יכול להימשך לאורך זמן. חוסר האמון הזה יזיק בסופו של דבר לשני הצדדים.
הארגונים משוועים לכך שגוף ה- IT יעזור להם לבצע את עבודתם טוב יותר, ייתן להם את הכלים לעמוד ביעדים העסקיים – שבשנים האחרונות משתנים תדיר כל כמה חודשים - ואולי החשוב ביותר, יוכל להיות גוף אסטרטגי, כזה שמספק יתרון תחרותי אמיתי עבור הארגון.
אתם רק צריכים להרים את הכפפה.
לפני כמה ימים, Citrix עדכנו את המסמך אשר מכיל את כל הפיקסים המומלצים (של עצמם ושל מיקרוסופט) עבור סביבות XenApp 6 על גבי Windows Server 2008 R2. לא יש אופציה אחרת.
ביניהם אפשר למצוא גם את XA600W2K8R2X64062 שיצא לפני כשבוע ומתקן את בעיית ה- BSOD ב- Shadow על sessions. ועוד כמה תיקונים אקזוטיים אחרים.
לרשימה המלאה.
בזמן האחרון שמעתי הרבה שאלות בדבר Windows Server 2008 R2 SP1 והאם הוא נתמך עם XenApp 6. אחרי שהיו השערות על כך שה- SP1 דופק את ה- Database של החווה, ושלל האשמות אחרות, עם הזמן התברר שלא ב- SP1 הבעיה, ונכון לעכשיו XenApp 6 תומך ב- SP1.
קיימת רק בעיה אחת ידועה וגם לה יצא תיקון עבור ה- XenApp 6.
כאן.
1. עליה איטית של אתר ה- Desktop Director
ההתנהגות מזכירה את ההתנהגות של Web Interface שם גם יש מקרים בהם זמן העליה של האתר הוא איטי יחסי. הדבר נובע עקב בדיקות CRL שמעקבות את עליית האפליקציה. למטיבי לכת, קצת יותר
פרטים.
אפשר לבטל את הבדיקה ע”י הוספה של השורה <generatePublisherEvidence enabled="false"/> תחת runtime לקובץ aspnet.config אשר נמצא ב- C:\Windows\Microsoft.NET\Framework64\v2.050727. לפי
CTX117273.
2. זמן לוגין ארוך בהזדהות ל- Desktop Director
בכניסה עם שם משתמש מסוים, ה- Desktop Director מחפש את המשתמש שניסה להזדהות אליו ב- Forest בו חבר המשתמש וב- Forest בו נמצא השרת (במקרה כמובן והוא לא זהה לזה של המשתמש).
לעיתים החיפוש הזה יכול לקחת זמן. במקרה שיש רק דומיין, בו חברים גם המשתמשים, גם תחנות העבודה הוירטואליות וגם שרת ה- DDC, אפשר להפנות את ה- Director ישירות לדומיין הרלוונטי ולחסוך את זמן החיפוש.
הולכים ל- Application Settings תחת IIS Manager->Server Name->Sites->Default Web Site->DesktopDirector וב- Connector.ActiveDirectory.Domains במקום מה שכתוב שם, כותבים את השם ה- NETBIOS-י של הדומיין.
לפי זה.
3. הוספת שם דומיין למסך ההזדהות של ה- Desktop Director
כברירת מחדל, מסך ההזדהות של ה- Director לא מציג את שם הדומיין איתו רוצים להזדהות, ויש להזין אותו ידנית. כדי להקל על המשתמשים, אפשר לקבע את שם הדומיין והמשתמש יצטרך להזין שם משתמש וסיסמא בלבד.
פותחים את הקובץ LogOn.aspx שנמצא ב- C:\inetpub\wwwroot\DesktopDirector, הולכים לשורה 213 ומוסיפים “Text=”DomainName. בסופו של תהליך, השורה צריכה להיראות כך (כמובן עם הדומיין הרלוונטי):
<asp:TextBox ID="Domain" runat="server" Text="DomainName" CssClass="text-box"></asp:TextBox>
בזמן האחרון שב ועולה נושא ה- 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 החדשים שיצרנו.
נותר רק להגדיר את כמות המכונות שנרצה להשאיר דלוקות בכל שעה מהיום וזהו.
בהצלחה.
ממש קצת לפני פסח, מתקיים כנס משותף של HP עם Citrix ומיקרוסופט בנושא Desktop Virtualization.
בכנס נתעסק קצת בשאלות המה ולמה, אבל עיקר תשומות הלב תוקדש לשאלת האיך. או, איך גורמים לזה לקרות בארגוניים אמיתיים עם משתמשים אמיתיים ובעיות אמיתיות.
הקטע המגניב באמת בכנס – או שזה רק אני?! – יתרחש דווקא לקראת סיומו, אז נעשה סוג של פאנל עם שאלות/תשובות, דעות והעברת חוויות על הנעשה בעולם ה- Desktop Virtualization. מאין “כל מה שרצית לדעת ולא היה לך את מי לשאול”.
אה… ויהיה גם דמו של XenDesktop 5, על שלל החידושים בו. שווה ביותר.
תבואו, יהיה כיף.
להרשמה ומנהלות שונות, לחצו על ההזמנה.
More Posts
Next page »